Ingeniería de software

Definición de software
Se entiende como producto de software no solo al conjunto de programas ejecutables, sino también a los archivos
anexos, estructuras de datos y documentos adicionales que permiten que dichos programas operen de manera
adecuada, desarrollados todos siguiendo un proceso determinado, con el fin de solucionar una necesidad de una
persona o compañía

Procesos de software
Se entiende como proceso de software, o proceso de desarrollo de software a la estructura que rige el desarrollo de un
proyecto de software. Esta estructura está compuesta por un conjunto de actividades cuyo objetivo es asegurar el
desarrollo de un producto de calidad dentro de las restricciones establecidas.

Actividades comunes a los procesos de software

1. Especificación
2. Desarrollo
3. Pruebas
4. Evolución del software, hay muchos enfoques alrededor del tema.

Definición de ingeniería de software

Se define como ingeniería de software a la disciplina de la ingeniería que se ocupa del conjunto de procesos, prácticas y
estándares necesarios para abordar todos los aspectos del proceso de construcción de un producto de software de
calidad, dentro de las restricciones de tiempo y presupuesto que existan.

Fases del modelo en cascada

1. Análisis y definición de requerimientos.
2. Diseño del sistema y del software.
3. Implementación y prueba de unidades.
4. Integración y prueba del sistema.
5. Funcionamiento y mantenimiento.

Actividades concurrentes modelo evolutivo

 Especificación
 Desarrollo
 Validación

Etapas del modelo basado en componentes

1. Especificación de requerimientos.
2. Análisis de componentes.
3. Modificación de componentes.
4. Diseño del sistema.
5. Desarrollo e integración.
6. Validación y pruebas.
Modelo incremental
Mezcla entre modelo en cascada y el modelo evolutivo. Se definen los requerimientos, se priorizan, dividen y en cada
incremento se aumentan las funcionalidades del sistema.

Ejemplo: Rational Unified Process (RUP)

Modelo en espiral
Cada ciclo de la espiral se divide en cuatro cuadrantes:

1. Definición de objetivos.
2. Evaluación y manejo de riesgos.
3. Desarrollo y pruebas.
4. Planeación.

Tipos de software
Plataforma: Sistema para hacer funcionar determinados módulos de hardware o software
Ejemplo: Word, Excel, Google Chrome, Skype…

Aplicación: Diseñado para realizar tareas en beneficio del usuario final.

Ejemplo: Sistemas Operativos, Motores de Bases de Datos, Servidores de aplicación

Fases del ciclo de vida del software (Según conferencia)

1. Definición y análisis de requerimientos

2. Diseño

3. Codificación (También llamada implementación)

4. Pruebas

5. Puesta en funcionamiento (También llamado Implantación)

6. Mantenimiento

7. Baja
Manifiesto ágil
 Individuos e interacciones sobre procesos y herramientas
 Software funcionando sobre documentación
 Colaboración con el cliente sobre negociación contractual
 Respuesta al cambio sobre seguir un plan
Aspecto Metodologías ingenieriles
Características  Orientado a la planificación
generales  Burocráticos
 Predictivos
Motivaciones  Modelo clásico de calidad (Procesos
definidos y repetitivos)
 Elaboración de un plan general
 Roles y responsabilidades
 Requerimientos formales y congelados
 Diseño completo al principio
 Documentación constante de
actividades
 Seguimiento periódico y frecuente
Ventajas  Fácil visualización del proyecto hacia el
cliente
 Concepción inicial del producto
 Información valiosa recolectada
constantemente
 Definición precisa de responsabilidades
individuales
Desventajas  Poca flexibilidad
 Desgaste innecesario del equipo de
trabajo
 Infravaloración de las personas (
Síndrome del “programador obrero”)
Ejemplos  Cascada estricta (No recomendada en
ningún caso)
 RUP / UP
 PSP / TSP
 Metodologías basadas en CMMI
Desde el plan  Plan completo y especifico al inicio del
proyecto
 Definición detallada de roles y
responsabilidades
 Estimaciones paramétricas
 Requerimientos supuestamente
congelados
Metodologías Agiles
 Orientados a las personas
 Ligeros
 Adaptativos
 Generación rápida y efectiva de valor
 Énfasis en las personas
 El software como actividad no predecible
 El software como actividad de diseño
 Iterativas e incrementales
 Enfocadas a satisfacer la necesidad del
cliente
 Confieren la responsabilidad a los
desarrolladores
 Adaptativas
 Requieren alto compromiso del cliente
 Funcionan bien sólo en equipos pequeños
 Son especificas (Para una fase del ciclo de
vida del software)
 Extreme Programming (XP)
 Scrum
 Kanban
 Lean
 Plan general no especifico, planes más
pequeño para cada iteración
 No roles – Corresponsabilidad
 Estimaciones hechas por los miembros del
equipo
 Requerimientos muy cambiantes
Desde el  Diseño, desarrollo y pruebas separadas  Diseño, desarrollo y pruebas integradas
desarrollo  Diseño completo antes de empezar  Diseño por funcionalidad / Por iteración
 (Opcional) Revisiones e inspecciones  Prácticas más ligeras de aseguramiento de
formales calidad
Desde la  Relación vía analista /gerente de  Relación directa entre cliente y desarrollador
relación con el cuentas  Comunicación principalmente oral
cliente  Los desarrolladores no hablan con el  “Supuesto agil”
cliente (Teléfono roto)
 Documentación extensa y “completa”

Conclusiones
Úsense las metodologías ingenieriles cuando:

 El equipo sea grande

 El cliente no muestre mucho interés en el proyecto
 Exista la posibilidad de congelar los requerimientos

Úsense las metodologías agiles cuando:

 El equipo de desarrollo sea pequeño (Máximo ocho (8 ))

 El cliente está comprometido con el proyecto
 Los requerimientos sean más cambiantes de los normales

Definición y características de los requerimientos

 Propiedad que un sistema debe exhibir para resolver un problema de un cliente
 Debe ser verificable
 Debe corresponder a una funcionalidad específica del sistema
 Hay requerimientos de producto y requerimientos de producto

Tipos de requerimiento por dónde se definen

De producto: Aquellas funcionalidades y características que debe tener el software

De proceso: Restricciones en la metodología, documentación y proceso de desarrollo

Tipos de requerimientos por su naturaleza

Funcional: Alguna característica o funcionalidad del software

No funcionales: Atributos de calidad que aplican a todo el sistema

Tipos de requerimientos por quién los establece
De sistema: Definidos por el cliente

De software: Establecidos por el ingeniero de requerimientos

Cliente Analista Desarrollador

Requerimientos de
Requerimientos de
sistema
software

Proceso de ingeniería de requerimientos

 Obtención o levantamiento
 Análisis
 Especificación
 Validación

Obtención de requerimientos - Fuentes

 Metas del cliente

 Conocimiento del negocio
 Involucrados
 Ambiente operativo
 Ambiente organizativo

Técnicas de obtención de requerimientos

 Entrevistas
 Escenarios (Qué pasaría si …)
 Prototipos
 Reuniones facilitadas
 Observación
 Historias de usuario
 Focus Groups
 Análisis de productos competidores

Tipos de requerimientos (Según cartilla)

De negocio: Representan a gran nivel los objetivos de la compañía y solicitudes del cliente.

Requerimientos de usuario: Describen las tareas de los usuarios que deben poder ser realizadas a través del uso del
producto.

Requerimientos funcionales: Definen qué hace el sistema (a través de la definición de entradas y salidas), es decir, las
funciones que dicho sistema debe cumplir.

Requerimientos no funcionales: Los requerimientos no funcionales son aquellos que definen atributos que indican al
sistema cómo realizar su trabajo.

Restricciones: Tipo de condiciones que deben cumplirse para que el software desarrollado se comporte de acuerdo con
lo planeado

Características de un buen requerimiento

 Independiente del diseño

 Priorizable
 Necesario
 No ambiguo
 Verificable
 Correcto
 Consistente
 Realizable
 Trazable
 Conciso
 Escrito en forma de debe

Motivos para seguir el proceso de definición de requerimientos

 Para que los usuarios digan y obtengan lo que quieren
 Para verificar el diseño
 Para medir el progreso
 Para entregar y aceptar el producto según criterios precisos
 Como herramienta orientadora de los procesos de pruebas
 Para generar confianza

Personas con las que tendrá contacto el ingeniero de requerimientos

 La gerencia del cliente

  Analistas del negocio del cliente
 Usuarios
 Ingenieros de hardware y software de la compañía cliente
 Personal de soporte técnico del cliente

Proceso de ingeniería de requerimientos

1. Obtención o levantamiento
Pasar información de los clientes a los desarrolladores.

 Metas del cliente

 Conocimiento del negocio
 Involucrados
 Ambiente operativo (En qué ambiente va a operar: en la nube, data center, dispositivos móviles )
 Ambiente organizativo

Técnicas de obtención de requerimientos

 Entrevista
 Escenarios (Qué tal si …)
 Prototipos
 Reuniones facilitadas
 Observación
 Historias de usuario
 Focus Groups
 Análisis de productos competidores

Análisis: Ganar comprensión sobre la información recibida.

Especificación: Generar entregables de revisión y aprobación.

Validación: Revisar y aprobar los entregables.

Definición de Historias de usuario
 Enunciado de una meta del cliente
 Descripción de la experiencia del cliente al usar el sistema
 “Promesa para tener una conversación”

Estructura historias de usuario

Como <actor del sistema> puedo <acción esperada> para <valor obtenido>. Comentarios adicionales

Ejemplo:

“Como usuario registrado puedo digitar mi nombre de usuario y contraseña para acceder al sistema. El nombre de
usuario debe existir en el sistema”

UML - Lenguaje Unificado de Modelado

 Nació en 1994
 Resultado del trabajo de James Rumbaugh, Grady Booch y Ivar Jacobson
 Primera especificacion en 1996
 Primera versión oficial en 1997
1. Diagramas de comportamiento: Son diagramas que se ocupan de la descripción de características del
sistema que tienen que ver con el comportamiento del mismo. Los diagramas que se encuentran en esta categoría son:

1.1 Diagrama de casos de uso: Muestra las interacciones de los actores externos al sistema (usuarios por ejemplo) con
éste y las relaciones que pueden existir entre dichas interacciones.

1.2 Diagrama de actividad: Muestra procesos del negocio de alto nivel. Utilizando este diagrama es posible modelar
flujo de datos y otros comportamientos de la lógica de la aplicación.

1.3 Diagrama de máquina de estados: Describe los estados en que un objeto o interacción puede encontrarse y cómo
ocurre la transición entre dichos estados.

2. Diagramas de estructura estática: Son diagramas que representan elementos de la especificación que no
son afectados por el tiempo. Los diagramas que están en esta categoría son:

2.1 Diagrama de clases: El diagrama de clases muestra la colección de elementos estáticos que describen la estructura
del software, así como las relaciones que los unen.

2.2 Diagrama de componentes: Despliega los componentes que hacen parte de la aplicación. Incluye sus
interrelaciones, interacciones e interfaces públicas.

2.3 Diagrama de objetos: Muestra las relaciones que existen entre los objetos de la aplicación durante su ejecución, en
un momento determinado del tiempo.

2.4 Diagrama de estructura compuesta: Representa la estructura interna de una clase, un caso de uso o un
componente, junto con sus puntos de interacción con otras partes del sistema.

2.5 Diagrama de despliegue: Despliega la arquitectura en la que se enmarca la ejecución del sistema. Específicamente
los espacios físicos (hardware) y lógicos (software) en los que dicha ejecución se llevará a cabo.

2.6 Diagrama de paquetes: Muestra como los elementos del sistema están organizados dentro de paquetes y las
relaciones que unen dichos paquetes.

3. Diagramas de interacción: Los diagramas de interacción están relacionados con los diagramas de
comportamiento, pero su énfasis está en la interacción entre los componentes del sistema. Los diagramas de interacción
son:

3.1 Diagrama de secuencia: Modela la manera como se comunican elementos del sistema durante el tiempo, con
énfasis en la representación del orden de dichas interacciones.

3.2 Diagrama de comunicación/colaboración: Muestra como las instancias de clases se comunican entre sí, con énfasis
en la estructura organizacional de dichas instancias y los mensajes que se envían entre sí.

3.3 Diagrama de tiempos: Representa los cambios en el estado de un elemento del sistema a lo largo del tiempo, como
respuesta a estímulos externos.

3.4 Diagrama general de interacción: Representa la interacción de las partes del sistema desde una perspectiva mucho
más general. Cada nodo de un diagrama general de interacción es un diagrama de interacción en sí mismo.
Qué es un caso de uso
 Descripción de un escenario de utilización del sistema
 Conversación entre un actor y el sistema
 También representan metas del usuario frente al sistema

Tipos de casos de uso

Casual

 Nombre (<verbo en infinitivo> <sustantivo>)

 Ejemplo: Ingresar al sistema, Digitalizar foto
 Actores
 Alcance / Nivel
 Flujo básico “en prosa” (Camino feliz)

Completo
Tiene los mismos elementos de los casos de uso casuales, adicionalmente tiene:
 Precondiciones / Postcondiciones
 Otros flujos ( Alternativos (Subvariaciones) / De excepción (Errores )
 Extensiones
 Información adicional

Pasos para el trabajo de análisis

Se identifican actores, sustantivos y verbos

Con esta información se elaboran dos entregables:

 Actores – Verbos -> Casos de uso

 Sustantivos -> Modelo conceptual

Pasos para la documentación

 Incluir información inicial
 Completar flujo básico
 Identificar otros flujos

Diagrama de clases
Permite identificar clases y la interacción entre ellas

Clase: Conjunto de objetos que tienen características similares

Partes de un caso de uso

 Precondición
 Flujo normal de eventos
 Condición de éxito
 Subvariaciones (Conducen a condición de éxito)
 Extensiones ( No Conducen a condición de éxito)