03 cicloprocesodesoftware isi

Ingeniería de Software I
© MSc. Carlos Mera Gómez
2013
Modelos / 1
Modelos de Proceso de Software
FIEC03046
Sesión 03

2013
Modelos / 2
Agenda
• Terminología
• Ciclo de vida para desarrollo de software
• Actividades de un proceso de software
• Modelos de proceso de software
• Modelo en cascada

2013
Modelos / 3
Terminología

2013
Modelos / 4
Terminología
• Un proceso de software es un conjunto
relacionado de actividades que están
involucrados en el desarrollo y evolución de
un producto de software.
• El modelo de un proceso de software es una
representación simplificada del proceso desde
una perspectiva en particular.

2013
Modelos / 5
Terminología
• Un producto Commercial-off-the-shelf [COTS]
es un sistema de software que puede ser
adaptado para las necesidades de diferentes
clientes sin la necesidad de modificar el
código fuente del sistema. Por ejemplo: Un
ERP.

2013
Modelos / 6
Ciclo de vida para desarrollo de software

2013
Modelos / 7
• Existen varios procesos de software. Sin
embargo, todos ellos incluyen cuatro actividades
fundamentales para la ingeniería de software:
– Especificación de software: se deben definir las
funcionalidades del software y sus restricciones de
operación.
– Diseño e implementación de software: se debe
producir un software que cumpla sus especificaciones.
– Validación de software: se debe validar el software a
fin de asegurar que este hace lo deseado por el
cliente.
– Evolución de software: el software debe evolucionar
para cumplir con los cambios producto de las
cambiantes necesidades del cliente.

2013
Modelos / 8
• Los procesos dividen estas actividades en subactividades.
• Las descripciones de estas actividades también pueden
incluir:
– Productos: los cuales son los resultados de una actividad. Por
ejemplo: en una actividad de diseño de arquitectura el resultado
podría ser el modelo de la arquitectura del software.
– Roles: reflejan las responsabilidades de los involucrados en el
proceso. Por ejemplo: director de proyectos, programador,
gestor de la configuración, etc.
– Pre y post condiciones: hechos que son verdaderos antes y
después de procesar la actividad. Por ejemplo: para el inicio del
diseño de la arquitectura se tiene como pre-condición que los
requerimientos hayan sido aprobados por el cliente y una post-
condición sería que se haya revisado los modelos UML que
describen la arquitectura.

2013
Modelos / 9
• No existen procesos de software ideales,
dependen del buen juicio y criterio de las
personas.
• Los procesos deben evolucionar para tomar
ventaja de las capacidades de los integrantes
de la organización.
• Los procesos de software se saben categorizar
en:
– Plan-driven processes
– Agile processes

2013
Modelos / 10
• Plan-driven processes: procesos en los cuales
sus actividades son planeadas con antelación
y sus avances son medidos con respecto al
plan.
• Agile processes: la planeación es incremental
y es más fácil cambiar el proceso pra reflejar
cambios en los requerimientos del cliente.

2013
Modelos / 11
Actividad de especificación de software

2013
Modelos / 12
Especificación del software
• También conocido como Ingeniería de
requerimientos.
• Es el proceso de entender y definir qué
servicios son requeridos desde el sistema e
identificar sus restricciones de operación y
desarrollo.
• Es un actividad crítica en vista que errores en
esta inevitablemente generarán problemas en
el diseño e implementación.

2013
Modelos / 13
• Las principales cuatro actividades en el
proceso de ingeniería de requerimientos son:
1. Estudio de factibilidad
2. Análisis y elicitación de requerimientos
3. Especificación de requerimientos
4. Validación de requerimientos

2013
Modelos / 14

2013
Modelos / 15
• Estudio de factibilidad
– Estimar si las necesidades del usuario pueden ser
satisfechas con la tecnología disponible,
– Estimar si el sistema es costo-efectivo desde un
punto de vista económico
– Estimar si se puede llevar a cabo el desarrollo
dentro del presupuesto establecido
– Producir un informe relativamente barato y rápido
si se debe o no continuar con un análisis
detallado.

2013
Modelos / 16
Actividad de especificación del software
• Análisis y elicitación de requerimientos
– Es el proceso de derivar los requerimientos del
sistema a través de la observación del proceso
existente
– Entrevistas con los potenciales usuarios
– Contruir prototipos
– Entre otras técnicas…

2013
Modelos / 17
• Especificación de requerimientos
– Traducir los requerimientos recopilados durante la
actividad de análisis en un documento que define
un conjunto de requerimientos
– Dos tipos de requerimientos se incluyen en el
documento:
• Requerimientos de usuario: oraciones en lenguaje
natural de los servicios que el sistema debe proveer y
sus restricciones de operación.
• Requerimientos de sistema: descripciones detalladas
de la funciones, servicios y restricciones operativas del
sistema.

2013
Modelos / 18
• Especificación de requerimientos

2013
Modelos / 19
• Validación de requerimientos
– Comprobar que los requerimientos seas reales,
consistentes y completos.
– Durante el proceso se descubren errores en el
documento, los cuales son modificados para
corregir estos problemas.

2013
Modelos / 20
Actividad de diseño e implementación de software

2013
Modelos / 21
Diseño e implementación de software
• Convertir las especificación del sistema en un sistema
ejecutable.
• Implica diseño e implementación.
• En un proceso de diseño se llevan a cabo las siguientes
actividades:
– Diseño de arquitectura: identificar la estructura general del
sistema, sus principales componentes o módulos y la relación
distribución de los mismos.
– Diseño de interface: definir las interfaces entre los
componentes del sistema. Así, los componentes pueden ser
usados sin conocer su implementación.
– Diseño de componentes: diseñar la operación de cada
componente. Alternativamente, podría contemplar los cambios
a los componentes reutilizados.
– Diseño de base de datos: diseñar las estructuras de base de
datos y su representación en la base de datos.

2013
Modelos / 22
Diseño e implementación de software

2013
Modelos / 23
Actividad de validación de software

2013
Modelos / 24
Validación de software
• Validación de software o más generalmente
verificación y validación tiene por objeto mostrar
que un sistema cumple con su especificación y a
la vez cumple con las expectativas del cliente.
• Las pruebas de software son la principal técnica
de validación.
• La fase formal de testing y sus costos de
validación se llevan a cabo luego de la fase de
implementación.
• Las pruebas llevadas a cabo por los
desarrolladores son parte de la implementación.
Lo veremos en detalle en el próximo curso…

2013
Modelos / 25
Validación de software

2013
Modelos / 26
Actividad de evolución de software

2013
Modelos / 27
Evolución de software
• También conocida como actividad de
mantenimiento de software.
• Cambios en el software pueden ser hechos
durante o después de la fase de
implementación. Sin embargo, históricamente
se ha dividido el proceso de desarrollo del
proceso de evolución o mantenimiento.

2013
Modelos / 28
Modelos de proceso de software

2013
Modelos / 29
• Los modelos de procesos de software son
frameworks que pueden ser extendidos y
adaptados para crear procesos de ingeniería
de software más específicos.

2013
Modelos / 30
• Cubriremos los siguientes modelos:
– Modelo en cascada: fases separadas para especificación de
requerimientos, diseño de software, implementación, pruebas, etc.
– Modelo de desarrollo incremental: intercala las actividades de
especificación, desarrollo y validación. El sistema se desarrolla en una
serie de versiones en donde cada una de ellas agrega funcionalidad.
– Modelo de desarrollo iterativo: no se inicia con una especificación de
requerimientos completa. Se especifica parte del software y se inicia
un ciclo de desarrollo. Al final de este, se repite el proceso con un
nuevo ciclo identificando nuevos requerimientos.
– Modelo de espiral de Boehm: es un tipo de proceso de software
iterativo, generalmente implementado en proyectos de alto riesgo.
Cada lazo en el espiral representa un fase de desarrollo.
– Modelo orientado al reuso: basado en la existencia de un número
significativo de componentes reusables. El desarrollo se centra en la
integración de los mismos en vez de empezar desde cero.

2013
Modelos / 31
Modelo en cascada

2013
Modelos / 32
Modelo en cascada
• Es un modelo de proceso de software que incluye
las etapas de desarrollo: especificación, diseño,
implementación, pruebas y mantenimiento.
• La etapa previa debe finalizar antes de iniciar la
siguiente.
• Es un ejemplo de plan-driven process ya que
primero se debe planificar y programar todas las
actividades del proceso antes de empezar a
trabajar en ellas.
• Se producen y aprueban documentos al final de
cada etapa.

2013
Modelos / 33
Modelo en cascada

2013
Modelos / 34
Modelo en cascada
– Fuente: http://istqbexamcertification.com

2013
Modelos / 35
Actividades del modelo en cascada
1. Definición y análisis de requerimientos: Los servicios,
restricciones y objetivos del sistema son establecidos con los
usuarios del sistema.
2. Diseño de software y del sistema: Se define la arquitectura del
sistema. Se diseñan los componentes de software.
3. Implementación y pruebas unitarias: El diseño es transformado
en un conjunto de programas. Las pruebas unitarias consisten en
verificar que el sistema cumpla su especificación.
4. Pruebas de integración y de sistema: Los programas individuales
son integrados y probadas como un sistema completo. Luego de
las pruebas el software es entregado al cliente.
5. Operación y mantenimiento: El sistema es instalado y puesto en
producción. El mantenimiento implica la corrección de errores
que no fueron descubiertos en las etapas preliminares, además las
mejoras al sistema a partir de los nuevos requerimientos.

2013
Modelos / 36
Ventajas del modelo en cascada
• Simple y fácil de entender y usar.
• Fácil de manejar dado que cada fase tiene
entregables específicos.
• Cada fase es procesada una por una.
• Funciona en proyectos pequeños o en
aquellos en que los requerimientos están
claros.

2013
Modelos / 37
Desventajas del modelo en cascada
• Es muy difícil regresar a una fase previa.
• El software no es entregado sino hasta el final
del ciclo de vida.
• No es apropiado para proyectos complejos o
aquellos en los que los requerimientos tienen
alta probabilidad de cambio.

2013
Modelos / 38
Modelo en cascada
• Conveniente cuando…
– Los requerimientos están bien entendidos, claros
y fijos.
– La definición del producto es estable.
– Se entiende la tecnología.
– No hay requerimientos ambiguos.
– Proyectos pequeños.

2013
Modelos / 39
Puntos para recordar
• Significado de modelo de proceso de software
• Actividades de un proceso de software
• Ventajas y desventajas del modelo en cascada
• Los modelos no son mutuamente excluyentes.
Se pueden combinar las mejores
características de cada uno en proyectos
grandes.

2013
Modelos / 40
Próxima Sesión
• Modelo incremental
• Modelo iterativo
• Modelo espiral de Boehm
• Modelo orientado a reuso
• Otros modelos…
• Cómo escoger el mejor ciclo de vida para un
proyecto

03 cicloprocesodesoftware isi

Más contenido relacionado

La actualidad más candente (19)

Destacado (20)

Similar a 03 cicloprocesodesoftware isi (20)

Último (9)

03 cicloprocesodesoftware isi