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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a 03 cicloprocesodesoftware isi

Similar a 03 cicloprocesodesoftware isi (20)

03 cicloprocesodesoftware isi