Programa de Ingeniería

de Sistemas

INGENIERÍA DE
SOFTWARE

Sesión 2:
Gestión del proyecto de
desarrollo de software.
Análisis de Requerimientos
Contenido
Gestión del proyecto de desarrollo de software

1. Ciclo de vida del desarrollo de software (SDLC)

2. Metodologías de gestión del desarrollo de software:
tradicionales y ágiles
3. Especificación de procesos de software:
• Análisis del problema – necesidad
• Actividades de captura de requerimientos – Casos de uso
 Tema
Gestión del proyecto de
desarrollo de software.
Análisis de
Requerimientos
 Ciclo de Vida del Software
Ingeniería de Software

ISO/IEC/IEEE 1[Link] es un marco de referencia que contiene las

actividades y las tareas involucradas en el desarrollo, la explotación y el
mantenimiento de un producto software, abarcando desde la definición
hasta la finalización de su uso

Es secuencia estructurada y bien definida de las etapas por las que pasa el software en su
desarrollo, desde que se concibe la idea hasta que el software deja de utilizarse (obsolescencia)
Cada etapa va acompañada de una serie de actividades y tareas, y una documentación de salida
de cada una de estas fases y que servirá de entrada a la fase siguiente

La ISO/IEC/IEE 12207 es el estándar sobre los procesos del ciclo de vida del software y
se propone como el modelo de referencia de procesos, aunque se puede trabajar con
otros modelos
 Ciclo de Vida del Desarrollo de Software
Ingeniería de Software

• Consiste en determinar:
• Fases productivas de un proyecto
• Objetivos de cada fase productiva
• Productos obtenidos en cada una
de estas fases, así como sus
características
 Desarrollo de Software como un proceso
Ingeniería de Software

Triangulo de hierro 
Ingeniería de Software

Modelos / Metodologías de gestión

del desarrollo de software
Tradicionales y Ágiles
 Modelos tradicionales de desarrollo de Software
Ingeniería de Software

Un modelo es una representación simplificada de un proceso de software

que conlleva una estrategia global para abordar el desarrollo de software
Descomponen los proyectos en fases Inicio, análisis, diseño, desarrollo, pruebas,
entrega, mantenimiento
Tratando de “imitar” las fases de otras ingenierías.
Ejemplos:
• Cascada (Waterfall): también conocido como modelo clásico o modelo lineal
• Ciclo de Vida en V
• De Prototipos o Desarrollo Evolutivo
• Incremental
• Orientados a Objetos
• Etc.
 Modelo en Cascada (Waterfalls)
Ingeniería de Software

• Enfoque sistemático y secuencial

del desarrollo Requerimientos
• Paso de fase al conseguir los objetivos
• Obtención de documentos como criterio Análisis
de finalización de fase

SISTEMA / SOFTWARE
• El final de una fase puede suponer un Diseño
punto de revisión
• Problemas: Desarrollo

o Visión estática de los requerimientos

ignorando su volatilidad  Rigidez Pruebas

o Poca participación de usuario una • Desarrollo lineal

•
vez que la especificación es obtenida •
Desarrollo por bloques
Estructura rígida
Integración

o Mucho tiempo en pasar por todo el

Mantenimiento
ciclo (Piattini et al., 2004)
o Modelo monolítico (Pressman, 2010):
Sistema listo muy al final

Versión original es de W. Royce (Royce, 1970), pero aparecen después numerosos refinamientos
 Ciclo de Vida en V
Ingeniería de Software

Contiene las mismas etapas que el

ciclo de vida en cascada puro
A diferencia, se le agregaron dos
subetapas:
• De verificación entre las etapas
de diseño y pruebas
• De validación entre las etapas
de análisis y mantenimiento
 Basados en Prototipos
Ingeniería de Software

• Su finalidad es probar varias suposiciones con respecto a las características requeridas por el sistema
• Se crean con rapidez
• Evolucionan a través de un proceso iterativo

• Desechable:
El prototipo es una versión rudimentaria del
sistema que posteriormente es desechada.
Se usa como herramienta auxiliar de la
especificación de requisitos y el diseño
La iteración ocurre cuando el prototipo se
pone a punto para satisfacer las necesidades
del cliente, permitiendo a la vez que el
desarrollador comprenda mejor lo que
necesita hacer
Este enfoque suele derivar en un modelo
lineal una vez que el prototipo ha
cumplido su misión
 Basados en Prototipos
Ingeniería de Software

• Evolutivo:
El prototipo debe convertirse, eventualmente, en el sistema final
Se utiliza cuando no se conoce con seguridad lo que se quiere construir
Se comienza diseñando e implementando las partes más destacadas del sistema
La evaluación del prototipo proporciona la realimentación necesaria para aumentar y refinar el prototipo
El prototipo evoluciona y se transforma en el sistema final
No disminuye el tiempo entre la definición de los requisitos y la entrega del producto
 Desarrollo incremental
Ingeniería de Software

[Ingeniería de Software. Sommerville I.., 2002]

 Metodologías OO
Ingeniería de Software

• Historia unida a la evolución de los lenguajes de POO: a fines de los 60’s SIMULA, a fines
de los 70’s Smalltalk-80, la primera versión de C++ por Bjarne Stroustrup en 1981 y
actualmente Java, C#, etc
• A fines de los 80’s comenzaron a consolidarse algunas metodologías Orientadas a Objeto
• En 1995 aparece el Método Unificado, que posteriormente se reorienta para dar lugar
al Unified Modeling Language (UML), la notación OO más popular en su momento
• Métodos OO con notaciones predecesoras de UML: OOAD (Booch), OOSE (Jacobson), Coad &
Yourdon, Shaler & Mellor y OMT (Rumbaugh)
• Algunas metodologías orientadas a objetos basadas en UML: Rational Unified
Process (RUP), OPEN, MÉTRICA 3
 Metodología RUP
Ingeniería de Software

Rational Unified Process (RUP) - (Proceso Unificado

de Rational)

Guiado y Manejado por Casos de Uso

Es un producto del proceso de ingeniería de software
que proporciona un enfoque disciplinado para
asignar tareas y responsabilidades dentro de Centrado en la Arquitectura
una organización de desarrollo
Iterativo e Incremental
Su meta es asegurar la producción del software de
alta calidad que resuelve las necesidades de los Desarrollo Basado en Componentes
usuarios dentro de un presupuesto y tiempo
establecidos Utilización de UML

Proceso Integrado

15
 Ingeniería de Software

Metodología RUP

16
 Metodología RUP - Fases
Ingeniería de Software

1. Concepción
• Se especifican los objetivos del ciclo de vida del proyecto, las necesidades de cada participante
• Se establece el alcance, las condiciones de límite y los criterios de aceptabilidad
• Se identifican los casos de uso que orientarán la funcionalidad
• Se diseñan las arquitecturas candidatas y se estima la agenda y el presupuesto de todo el proyecto
• Típicamente es una fase breve que puede durar unos pocos días o unas pocas semanas

2. Elaboración
• Se analiza el dominio del problema y se define el plan del proyecto
• Brinda una arquitectura suficientemente sólida junto con requerimientos y planes bastante estables
• Se describen en detalle la infraestructura y el ambiente de desarrollo, así como el soporte de
herramientas de automatización
• Se debe identificar la mayoría de los casos de uso y los actores, debe quedar descripta la arquitectura de
software y se debe crear un prototipo de ella
• Al final de la fase se realiza un análisis para determinar los riesgos y se evalúan los gastos hechos contra
los originalmente planeados
17
 Metodología RUP - Fases
Ingeniería de Software

3. Construcción
• Se desarrollan, integran y verifican todos los componentes y rasgos de la aplicación
• Esta fase es un proceso de manufactura, en el que se debe poner énfasis en la administración de los
recursos y el control de costos, agenda y calidad
• Los resultados de esta fase (las versiones alfa, beta y otras versiones de prueba) se crean tan rápido
como sea posible
• Se debe probar también una versión de entrega
• Es la fase más prolongada de todas

4. Transición
• Comienza cuando el producto está suficientemente maduro para ser entregado
• Se corrigen los últimos errores y se agregan los rasgos pospuestos
• La fase consiste en prueba beta, piloto, entrenamiento a usuarios y despacho del producto a mercadeo,
distribución y ventas
• Se produce también la documentación
• Se llama transición porque se transfiere a las manos del usuario, pasando del entorno de desarrollo al 18
de producción
 Metodología RUP – Flujos de Trabajo
Ingeniería de Software

A través de las 4 fases se desarrollan en paralelo nueve flujos de trabajo o disciplinas:

• Modelado de Negocios

• Requerimientos

• Análisis y Diseño

• Implementación

• Prueba

• Despliegue

• Gestión de Configuración y Cambio

• Gestión del Proyecto

• Ambiente o Entorno

19
 Metodología RUP - Hitos
Ingeniería de Software

Compromiso de
Aceptación
recursos para fase
del cliente
elaboración

Concepción Elaboración Construcción Transición

Tiempo

Hito Hito Hito Liberación

Objetivos Arquitectura Capacidad Producto
Operacional

20
 Metodologías ágiles de desarrollo de Software
Ingeniería de Software

Mediados de los 90, fuertes críticas a los métodos

tradicionales  Retrasos, altos costos, baja calidad
 Insatisfacción del cliente

En 2001  Manifiesto Ágil:

- Flexibilidad
- Agilidad
- Capacidad de adaptación

Desarrollo iterativo e incremental

que permite la entregas continuas y de valor

Frecuencia de Entrega
Obtención rápida de resultados y
satisfacción del cliente  simplicidad y
mejora continua (producto y proceso de gestión del
proyecto)
Grado de Cambio
 Metodologías ágiles de desarrollo de Software
Ingeniería de Software

Muchas organizaciones optan por participar estrechamente con

el equipo desarrollador de su proveedor de software  Permite
tener un mayor control sobre el producto final
Para trabajos colaborativos como éste es necesario definir una serie de
pautas que todos los colaboradores han de seguir
Ejemplos:
• Extreme Programming (XP)
• Scrum
• Kanban
• Métodos Crystal (Crystal Methods)
 eXtreme Programming
Ingeniería de Software

Método ágil basado en

cuatro principios:
• Simplicidad
• Comunicación
• Retroalimentación
• Valor
 Ciclo de vida XP
Ingeniería de Software

“Spikes” (“tarea de investigación”) suelen ser de dos tipos: técnicos o funcionales. Los funcionales se utilizan para
analizar funcionalidad, su riesgo y complejidad. Los técnicos se utilizan para determinar la viabilidad.
En Scrum también existen: Es una tarea en un sprint que no pertenece necesariamente a una historia de usuario
 Principios de Scrum
Ingeniería de Software

• Conjunto de prácticas que enfatizan la comunicación diaria y la reevaluación

flexible de los planes que se llevan a cabo en fases breves e iterativas de
trabajo
• Equipos multifuncionales, auto-dirigidos y auto-organizados
• Al principio de cada iteración, hay planeamiento adaptativo guiado por el cliente (Product
Owner)
• Iteraciones (Sprints) de treinta días; se admite que sean más frecuentes
• Encuentros diarios con las tres preguntas (¿Qué has hecho? ¿Qué problemas tienes? ¿Qué
harás hoy? . Se realizan siempre en el mismo lugar, en círculo
• Demostración a participantes externos (Clientes, etc.) al fin de cada iteración
• Enfatiza en valores y prácticas de gestión, no en cuestiones técnicas de desarrollo
 Ciclo de vida Scrum
Ingeniería de Software

• Lista de producto o product backlog: es una lista de los requisitos del producto. El dueño del producto es el único responsable de su
contenido y el orden de prioridades de las tareas. Puede actualizarse en cualquier momento
• Lista de pendientes del sprint o sprint backlog: elementos de la lista de producto seleccionados para el próximo sprint
• Incremento o increment: elementos de la lista de productos completados durante un sprint
 Modelos de desarrollo de Software - Comparación
Ingeniería de Software
 Modelos de desarrollo de Software - Comparación
Ingeniería de Software

Métodos híbridos, combinan la adaptabilidad de los ágiles con la formalidad y documentación de los métodos rigurosos
tradicionales
 Metodologías ágiles: adaptando la ingeniería del software a los
negocios
Ingeniería de Software
Ingeniería de Software

Especificación de Procesos de
Software
Análisis del Problema
Ingeniería de Software
Ingeniería de Software
Ingeniería de Software
Ingeniería de Software
Ingeniería de Software
Ingeniería de Software
Ingeniería de Software
Ingeniería de Software

Especificación de Procesos de
Software
Captura de Requisitos
Ingeniería de Software
 ¿Que es un requisito?
Ingeniería de Software

Es una valoración clara de las necesidades que un sistema debe

alcanzar.
• Debe indicar:
 Qué necesita el sistema, basado en condiciones corrientes y previsibles
 Qué rasgos del sistema servirán para satisfacer el contexto del mismo
 Cómo el sistema debe ser construido

• Es una condición o capacidad que debe cumplir o poseer un sistema o

componente de un sistema para satisfacer un contrato, un estándar, una
especificación o algún otro documento impuesto

• El conjunto de requerimientos forma la base para el desarrollo de un sistema

o un componente de un sistema
 ¿Que describe un requisito?
Ingeniería de Software

• Una facilidad a nivel usuario

Ej.: ‘el procesador de palabras debe incluir un verificador de ortografía y un comando de corrección’

• Una propiedad muy general del sistema

Ej.: ‘el sistema debe asegurar que la información personal nunca se haga disponible sin autorización’

• Una restricción específica del sistema

Ej.: ‘el sensor debe ser activado 10 veces por segundo’

• Una restricción para el desarrollo del sistema

Ej.: ‘el sistema debe ser desarrollado usando Lenguaje C’

• Cómo llevar a cabo algún cálculo

Ej.: ‘la nota final debe ser calculada sumando las notas del examen, proyecto y cursada del estudiante
basado en la siguiente fórmula nota final = (0.3 *examen_parcial + 0.3*nota_TP + 0.4*examen_final)/3
 Importancia de los requisitos
Ingeniería de Software

• El argumento de Ingeniero
• El ingeniero debe desarrollar soluciones a problemas
• Una buena solución puede solo ser desarrollada si el ingeniero tiene un buen
entendimiento del problema
• El argumento económico
• Los costos de errores aumentan si pasa más tiempo sin detectarlos
• Argumento empírico
• Los errores latentes de entender y manejar requerimientos son la mayor causa de
exceso de costos
• Argumento de seguridad
• Los mayores riesgo de seguridad están centrado en requi inadecuados o mal
entendidos
 Niveles de los Requisitos
Ingeniería de Software
 Actividades de la Captura de Requisitos
Ingeniería de Software

Según el RUP, los principales pasos para capturar los requisitos son:

• Identificación de Actores y Casos de uso

• Priorizar Casos de Uso

• Detallar Casos de Uso

• Estructurar el MCU

• Prototipar la interfaz de usuario (GUI)

 Identificación de escenarios
Ingeniería de Software

• ¿Qué tareas necesita el actor que realice el sistema?

• ¿Qué información consulta el actor? ¿Quién crea esos datos? ¿Se pueden
modificar? ¿Quién puede hacerlo?

• ¿Qué cambios externos necesita informar el actor al sistema? ¿Cuándo y con qué
frecuencia?

• ¿De qué eventos necesita el actor que le informe el sistema? ¿Cuándo y con qué
frecuencia?
 Identificación de Requerimientos
Ingeniería de Software
 Requerimiento Funcional
Ingeniería de Software
 Requerimiento No Funcional
Ingeniería de Software
 Identificación de Requerimientos
Ingeniería de Software
 ¿Por qué Trazabilidad de Requerimientos con Casos
Ingeniería de Software

de Uso?
 Trazabilidad de Requerimientos con Casos de Uso
Ingeniería de Software
 Priorización de casos de uso
Ingeniería de Software

• Determinar cuáles son necesarios para el desarrollo en las primeras iteraciones y

cuáles pueden dejarse para posteriores iteraciones

• Cuestiones a tener en cuenta:

• CU con dificultad de desarrollo

• CU imprescindibles para la puesta en marcha del sistema

• Organización del desarrollo incremental

• Disponibilidad de equipo de desarrollo

• Se revisa la priorización con el Jefe de Proyecto y se utiliza como entrada para la

planificación de cada iteración del proyecto
 Priorización de casos de uso
Ingeniería de Software

Formula
Generar Visita = 0.2*5+0.3*6+0.4*8+0.1*9 = 6.9

Los valores que se colocan en cada caso de uso van de 1 hasta 10

 Priorización de casos de uso
Ingeniería de Software

Formula
Tomar Pedido = 0.4*4+0.3*5+0.2*10+0.1*10 = 6.1

Los valores que se colocan en cada caso de uso van de 1 hasta 10

Ingeniería de Software

Modelo de casos de uso de sistemas

 Ejemplo
Ingeniería de Software

PROCESO LOGÍSTICO
El Gerente de Logística en las entrevista describió los requisitos que debería
tener el nuevo sistema.

• R1. El encargado de compras debe de ingresar al sistema por medio de una

pantalla de login

• R2. El encargado de compras debe registrar la compra en el sistema

 Ejemplo
Ingeniería de Software

PROCESO LOGÍSTICO
1.- Encontrar los actores
El Gerente de Logística en las entrevista describió los requisitos que debería
tener el nuevo sistema.
• R1. El encargado de compras debe de ingresar al sistema por medio de una
pantalla de login
• R2. El encargado de compras debe registrar la compra en el sistema
 Ejemplo
PROCESO LOGÍSTICO
Ingeniería de Software

2.- Encontrar los casos de

uso
El Gerente de Logística en las entrevista describió los requisitos que debería
tener el nuevo sistema.

• R1. El encargado de compras debe de ingresar al sistema por medio de una

pantalla de login

• R2. El encargado de compras debe registrar la compra en el sistema

 Diagrama de Casos de Uso
Ingeniería de Software
Autoevaluación
Sesión 2
 ¿Cuál es el propósito general del ciclo de vida de desarrollo de software?

Establecer el equipo de desarrollo de aplicaciones

Pregunta 1

Servir de marco de referencia para realizar las actividades y las tareas involucradas en el desarrollo, la
explotación y el mantenimiento de un producto software

Establecer los objetivos y el alcance del proyecto

 ¿Qué beneficios se obtienen al seguir una metodología de desarrollo en proyectos de
software?

Mayor satisfacción del cliente.

Pregunta 2

Mejor comunicación entre los integrantes del equipo de desarrollo y el cliente

Claridad en los pasos y prácticas a seguir por el equipo durante el desarrollo del proyecto
 ¿Por qué es importante realizar un análisis detallado de requerimientos
en proyectos de software?

Para establecer el presupuesto del proyecto.

Pregunta 3

Para identificar los recursos necesarios para el desarrollo.

Para comprender las necesidades y expectativas de los usuarios del software.

 El CVDS (SDLC) serve de marco de referencia para realizar las actividades y
Conclusiones

las tareas involucradas en el desarrollo, la explotación y el mantenimiento de

un producto software

El principal beneficio que se obtiene al seguir una metodología de desarrollo

en proyectos de software es la claridad en los pasos y prácticas a seguir por
parte del equipo durante el desarrollo del proyecto

El análisis exhaustivo de requerimientos en proyectos de software es esencial

para comprender las necesidades de los usuarios y evitar malentendidos
durante el desarrollo