CICLO DE VIDA Y

PROCESO SOFTWARE

Planificación y Gestión del Desarrollo de

Sistemas Informáticos
 Índice

• La Ingeniería del Software

• El proceso de desarrollo de software

• Definición del proceso

• Evaluación del proceso

• Mejora del proceso

• El Proceso Software Personal

¿Cómo surge la Ingeniería del Software?

• 1955-1965: Programación de cualquier modo

– Programas pequeños, ninguna gestión, uso de ensamblador
• 1965-1975: Programación a pequeña escala
– Algoritmos, estructuras de datos, lenguajes de programación de
alto nivel, gestión individual
• 1975-actualidad: Programación a gran escala
– Bases de datos, programas que se ejecutan continuamente,
especificaciones complejas, herramientas y entornos de
desarrollo, gestión en equipo
¿Cómo surge la Ingeniería del Software?

LINEAS DE CÓDIGO ESTRUCTURA DE DESARROLLO

1.000-5.000 Programador individual

5.000-25.000 Pequeño equipo
25.000-100.000 Equipo grande subdividido
100.000-1.000.000 Varios equipos
1.000.000-10.000.000 Varias empresas
10.000.000-100.000.000 Proyecto nacional

El tamaño del software crece un orden de magnitud cada 5 años

 ¿Cómo surge la Ingeniería del Software?

• Expansión sin control que condujo a la “Crisis del

Software”:
– Expectativas: No responden a las expectativas de los usuarios
– Fiabilidad: Fallan muy a menudo
– Coste: Difíciles de prever, superiores a lo esperado
– Facilidad de modificación: complejo, costoso y propenso a errores
– Plazos: se entrega tarde
– Portabilidad: difícil, aún con la misma funcionalidad
– Eficiencia: no se aprovechan óptimamente los recursos
 ¿Cómo surge la Ingeniería del Software?

• El software es mucho más difícil de construir de lo que se

pensaba.

• Conferencia de Garmish (1968): surge el término

INGENIERÍA DEL SOFTWARE
“Establecer y usar principios de ingeniería orientados a obtener
software de manera económica, fiable y que funcione
eficientemente sobre máquinas reales” (Bauer)

• Pero la ingeniería del software no es como otras ingenierías

 Principios de la Ingeniería del Software

• Haz de la calidad la razón de trabajar

• Es posible el software de alta calidad
• Una buena gestión es más importante que una buena
tecnología
• Las personas y el tiempo no son intercambiables
• Seleccionar el modelo de ciclo de vida adecuado
• Entregar productos al usuario lo más pronto posible
 Principios de la Ingeniería del Software

• Determinar el problema antes de escribir los requisitos

• Evaluar las alternativas de diseño
• Diseñar sin documentación es no diseñar
• Minimizar la distancia intelectual
• Usar formalismos distintos para distintas fases
• Las técnicas son anteriores a las herramientas
Principios de la Ingeniería del Software

• Inspeccionar el código
• Primero hazlo correcto, después hazlo rápido
• La gente es la clave del éxito
• Introduce las mejoras con cuidado
• Asume tus responsabilidades
• La entropía del software es creciente
Componentes de la Ingeniería del Software
• Métodos:
actividades necesarias para construir el software
• Técnicas:
formas concretas de llevar a cabo los métodos
• Formalismos:
notaciones utilizadas por las técnicas
• Herramientas:
implementan las técnicas
• Procedimientos:
establecen el orden en que se aplican los métodos
 Las tres P de la Ingeniería del
Software
Las claves del éxito en un proyecto
El Proceso de Resolución de Problemas

• Identificar el problema
• Definir y representar el problema (qué hacer)
• Explorar las posibles estrategias (cómo hacerlo)
• Aplicar la mejor estrategia (hacerlo)
• Mirar atrás y evaluar los efectos de la actividad
realizada (probar el resultado)
• Se resolvió el problema (usar el resultado)
 El Proceso de Construcción de Software
• Es un proceso de resolución de problemas: transformación
de una necesidad en una solución automatizada que
satisface la necesidad:
– Qué: Obtención de requisitos: analizar el problema
– Cómo: Diseñar el sistema
• Diseño de alto nivel o preliminar: descomposición del sistema en
componentes y sus relaciones
• Diseño de bajo nivel o detallado: especificación de la función de cada
componente
– Hacerlo: Implementar
– Probar: Pruebas
– Usar: Implantación y Uso
– Mantenimiento (otro proceso de resolución problemas)
 Proceso Software vs. Ciclo de Vida
• El Proceso Software como proceso de transformación:
recibe unas entradas y genera unas salidas
• El Producto Software va pasando por una serie de
estados a medida que se transforma:
– Necesidad
– Especificación de requisitos
– Diseño del sistema
– Código
– Sistema software operativo
• Ciclo de Vida: estados por los que pasa el producto
desde que nace hasta que muere
 Proceso Software vs. Ciclo de Vida

Obtención Diseñar
PROCESO DE Codificar Probar
CONSTRUCCIÓN requisitos sistema

CICLO DE Especific. Sistema

Necesidad Diseño Código
VIDA requisitos software
 Ciclos de Vida
• Modelo de ciclo de vida:
– abstracción de las fases o estados por los que pasa un producto
software a lo largo de su vida
– representa una posible aproximación a la producción de software
– Debe:
• Determinar el orden de las fases
• Establecer los criterios de transición entre fases
• No hay un modelo de ciclo de vida que sirva para
todos los proyectos:
– cultura de la organización
– deseo de asumir riesgos
– área de aplicación
– volatilidad de los requisitos
– comprensión de los requisitos
– experiencia previa
Modelo clásico o en Cascada

Requisitos

Diseño

Codificación

Prueba

Operación
 Modelo clásico o en Cascada
• Royce-1970
• Orden lineal en las transiciones entre fases
• Vuelta atrás al detectar Equivocaciones
• Asume que:
– Los requisitos se pueden conocer completamente y sin ambigüedad
al principio del proceso de desarrollo
– Los requisitos no varían
– Cada etapa implica una revisión
– No se pasa a la siguiente etapa hasta que se completa la actual
• Implica que:
– Los requisitos pueden quedarse obsoletos
– No hay un ejecutable que enseñar al usuario hasta el final
– 99% de recursos consumidos - errores irremediables
 Coste de cada etapa
• Según Boehm (1975):

Tipo de Sistema Requisitos Implementar Pruebas

y Diseño
Sistemas de Control 46 20 34
Sistemas especiales 34 20 46
Sistemas Operativos 33 17 50
Sistemas científicos 45-53 27-36 15-23
Sistemas de Gestión 44 28 28
Requisitos
sistema
Requisitos Modelo en V
software
Diseño
preliminar
Diseño
detallado
Codificación

Pruebas
unidad
Pruebas
componente
Integración
software
Pruebas
sistema
Integración
sistema
 Modelo en V
• Énfasis en:
– Validación de los productos
– Proceso de análisis (descomposición) y síntesis
(composición)
• El producto de cada etapa:
– Es la entrada para la siguiente
– Determina los criterios para validar el resultado de la
composición
• Considera sistemas que engloban componentes
software y otros
 Refinamiento Sucesivo o Mejora
Iterativa
• Etapas y orden igual que en el cascada
• Dentro de cada etapa los productos se
generan de forma iterativa, refinándose en
cada ciclo
 Emisión Gradual
• Varias versiones sucesivas
• En cada versión se incorporan nuevas funciones
• De las funciones más esenciales a las menos
importantes
• Modelo usual en productos comerciales
• Es una mejora iterativa a nivel global
Estándar MIL-STD-2167 (1987)
• Fuerzas armadas de EEUU
• Como normativa para los contratistas
• Especifica, además de las etapas:
– Los productos a entregar
– Las revisiones a efectuar
– Las técnicas a emplear
– La forma de descomponer el producto para la gestión
de la configuración: CSCI (Computer Software
Configuration Item) - CSC (Component) - CSU (Unit)
• Complejo y detallado
Estándar MIL-STD-2167 (1987)
• Etapas:
– Análisis de Requisitos del Sistema
– Diseño del Sistema
– Análisis de Requisitos del Software
– Diseño Preliminar
– Diseño Detallado
– Codificación y Verificación de CSUs
– Integración y Verificación de CSCs
– Prueba de CSCIs
– Integración y prueba del sistema
 Estándar ESA PSS-05-0
• Agencia Espacial Europea
• Como normativa para los contratistas
• Etapas:
– Definición de requisitos del usuario
– Definición de requisitos del software
– Diseño de la arquitectura
– Diseño detallado y producción del software
– Transferencia de la tecnología al usuario
– Operación y mantenimiento
• Simple y de alto nivel
 Prototipado
• Cuándo:
– El cliente no sabe bien lo que quiere
– No se comprende bien lo que quiere
– No se está seguro de la viabilidad de la solución
• Objetivo: producir una versión de funcionalidad
reducida en las fases iniciales del proceso de
desarrollo
– En papel, describiendo la interacción
– Ejecutable: tiene su propio ciclo de vida
• El prototipo es evaluado por el usuario y se refina
la especificación de requisitos
 Tipos de Prototipos
• Desechable:
– sólo se incorporan los aspectos peor entendidos o
dudosos
– desarrollo ‘quick and dirty’
• Maqueta:
– ejemplo de la interfaz que muestra las entradas y salidas
y la forma de interacción
– con datos y encadenamientos forzados
• Prototipo evolutivo:
– el prototipo se desarrolla rigurosamente
– fácil de ampliar y modificar
– se van incorporando las partes mejor entendidas
 Prototipado
• Etapas:
– Análisis preliminar y especificación de
requisitos
– Diseño e implementación del prototipo
– Prueba del prototipo
– Refinamiento iterativo del prototipo
– Refinamiento de la especificación de requisitos
– Diseño e implementación del sistema final
 Modelo en Espiral
Costes acumulados
Evaluación de alternativas,
Determinación de objetivos, identificación de riesgos
alternativas, restricciones
Análisis
deriesgo
Análisis
deriesgo
Análisis
deriesgo
Análisis Prototipo Prototipo Prototipo
deriesgo
Revisión Prototipo operativo

Plan de requisitos Concepto de

Plan de ciclo de vida operación Requisitos
del softwaare
Diseño
Plan del desarrollo Validación de Diseño detallado
requisitos
Plan de la integración Validación y verificación PruebaCodificación
y prueba del diseño de
unidad
Prueba Integración
Implementaciónde y prueba
aceptación

Desarrollo, verificación del

Planificación de las próximas fases producto del próximo nivel
 Modelo en Espiral
• Boehm - 1986
• Enfoque dirigido por el riesgo. En cada ciclo se
hace un análisis de riesgo:
– identificar situaciones que pueden causar el fracaso
– centrarse primero en los aspectos de mayor riesgo
• Tipos de ciclos:
– Internos: prototipado
– Externos: clásico
 Modelos alternativos
• Modelos basados en la reutilización de
componentes (CotS)
– Según la granularidad de los componentes
• Modelos basados en el uso de un generador de
aplicaciones (generadores de informes, sistemas
de autor, programación visual de interfaces)
– Sólo para tipos de sistemas específicos
– Basados en la especificación de parámetros
– Generación automática de código
 Estándar de IEEE 1074-1995
• Da el conjunto de actividades (65) que constituyen los
procesos (17) obligatorios para el desarrollo y mantenimiento
de software. Sólo actividades relativas al software.
• No obliga al uso de ningún ciclo de vida en particular. Para
utilizarse debe definirse antes la correspondencia entre las
actividades y el ciclo de vida a utilizar.
• No obliga al uso de ninguna metodología de desarrollo en
particular.
• Se aplica a cualquier tipo de software (dominio, tamaño,
complejidad...)
• Cumplimiento = ejecución de todas las actividades
obligatorias.
 Categorías de Procesos (6)
• Relativos al modelado de ciclos de vida:
• Modelado del ciclo de vida
• De gestión del proyecto:
• Iniciación del proyecto
• Monitorización y control del proyecto
• Gestión de la calidad del software
• Previos al desarrollo:
• Exploración del concepto
• Asignación de sistema
• De desarrollo:
• Requisitos
• Diseño
• Implementación
 Categorías de Procesos (6)
• Posteriores al desarrollo:
• Instalación
• Operación y soporte
• Mantenimiento
• Retiro
• Integrales:
• Verificación y validación
• Gestión de la configuración del software
• Desarrollo de documentación
• Entrenamiento
 Estructura de una Actividad
• Componentes:
– Información de entradas, y su origen
(externo/actividad)
– Descripción de las acciones a ejecutar
– Información de salidas, y su destino (externo/actividad)
• Pueden tener varias instancias y ser iterativas
• Ejecución completa de una actividad:
– Toda la información de entrada ha sido procesada
– Toda la información de salida ha sido generada (en una
o más iteraciones)
 Los procesos integrales
• Sus actividades pueden ejecutarse:
– en puntos discretos
– durante el transcurso de otra actividad
• Las actividades pueden llamar a los procesos
integrales como subrutinas, especificando la
primera actividad a ejecutar en el proceso.
• Una actividad puede ser llamada desde varias. El
origen y destino de la información se especifica de
forma genérica “creating process”
 Modelado del Ciclo de Vida (2)
• Actividades:
– Identificar posibles modelos de ciclo de vida a aplicar
• Según las restricciones del proyecto
• Se puede definir uno nuevo
– Seleccionar el modelo de ciclo de vida del proyecto
• Según el tipo de producto, las restricciones del proyecto, los
registros históricos de otros proyectos
• De entre los modelos aplicables

• Salidas:
– Modelo de ciclo de vida seleccionado
 Iniciación del Proyecto (3)
• Actividades:
– Hacer corresponder las actividades del estándar con el
modelo de ciclo de vida seleccionado
• Asignando un responsable (puesto) de controlar que la
actividad se completa en el plazo y presupuesto planeados, y
de la calidad de los productos de salida.
– Asignar recursos
• Humanos, de equipamiento, de espacio, etc.
– Establecer el entorno del proyecto
• Metodologías, estándares, herramientas, librerías de software,
software comercial, ... a utilizar en el proyecto
– Planificar la gestión del proyecto (iterativa)
 Iniciación del Proyecto (3) (ii)
• Planificar la gestión del proyecto:
• Definir la organización del proyecto y asignar responsabilidades
• Seleccionar estándares, metodologías y herramientas de:
– Gestión de configuración
– Garantía de calidad
– Verificación y validación
– Entrenamiento
– Documentación
– Desarrollo
• Definir la programación temporal, el presupuesto y los recursos
humanos del proyecto
• Definir procedimientos para:
– Soporte
– Retiro
– Gestión de problemas
– Seguimiento
 Iniciación del Proyecto (3) (iii)
• Salidas:
– Plan de Gestión del Proyecto
– Plan de retirada
– Plan de gestión de problemas
– Plan de actividades de apoyo
– Lista de actividades no aplicables
– Asignación de recursos a actividades
Monitorización y Control del proyecto (3)

• Actividades (iterativas):
– Analizar riesgos:
• Técnicos, económicos, de operación, de soporte, de tiempo, ...
– Elaborar planes de contingencia
• Acciones a tomar en caso de que un riesgo se materialice
– Gestionar el proyecto
• Revisar y medir el progreso del proyecto con respecto a sus hitos y el
gasto con respecto al presupuesto
• Gestión del proyecto día a día
– Mantener registros
• Documentos y registros provenientes de diversos procesos
– Implementar el método de comunicación de problemas
• Según el procedimiento especificado
Monitorización y Control del proyecto (3)
(ii)
• Salidas:
– Análisis de riesgos
– Planes de contingencia
– Informes de gestión del proyecto
– Registros históricos del proyecto
– Información de gestión de problemas
 Gestión de la Calidad del Software
(4)
• Actividades:
– Planificación de la Gestión de la Calidad
• Identificar actividades de Garantía de Calidad
• Objetivos de calidad, Metas y estándares
• Organización, herramientas, metodologías y técnicas
– Definición de métricas
• De producto y de proceso
• Métodos de recolección y análisis
– Gestión de la Calidad del Software
• Según el Plan de Gestión de la Calidad
– Identificar necesidades de Mejora de la Calidad
• Partiendo, fundamentalmente, de los resultados de las actividades de
Validación y Verificación
 Gestión de la Calidad del Software (4)
(ii)
• Salidas:
– Plan de Gestión de la Calidad
– Definición de métricas y métodos de
recolección y análisis
– Valoraciones de la Calidad del Proyecto
– Recomendaciones de mejora
 Verificación y Validación (6)
• Actividades:
– Planificación de la Verificación y Validación
• Para cada proceso y producto del proceso
• Auditorías, revisiones, inspecciones, demostraciones formales,
prototipado, ...
– Ejecución de las tareas de V&V
• Según el plan
– Recolección y análisis de datos de métricas
• Según se especificó en Gestión de la Calidad
– Planificación de las Pruebas
• Actividad de V&V especialmente importante
– Desarrollo de especificaciones de Prueba
– Ejecución de las Pruebas
• Según el plan
Verificación y Validación (6) (ii)
• Salidas:
– Plan de V&V del Software
– Informes de V&V
– Informes de métricas
– Plan de Pruebas
– Informes de las pruebas
– Software probado
 Gestión de la Configuración (4)
• Actividades:
– Planificación de la Gestión de la Configuración
– Identificación de la Configuración
• Esquema de etiquetado
• Líneas base
– Control de la Configuración
• Seguimiento de cambios
– Contabilidad del Estado de la Configuración
• Generación de informes
• Salidas:
– Plan de Gestión de la Configuración
– Identificación de la Configuración
– Elementos bajo control
– Información de estado de la configuración
Desarrollo de Documentación (3)
• Actividades:
– Planificación de la Documentación
• responsables, fechas, estándares, fuentes, destinatarios
– Documentar
• Según el plan
– Producir y distribuir Documentación
• Hacer llegar la documentación a sus destinatarios

• Salidas:
– Plan de documentación
– Documentación publicada
 Entrenamiento (4)
• Actividades:
– Planificar el Programa de Formación
• Necesidades de formación
• Fechas, recursos, destinatarios
– Desarrollar materiales de formación
– Validar el Programa de Formación
• Por un grupo de evaluadores
– Implementar el Programa de Formación

• Salidas:
– Plan de Formación
– Personal formado
 Relación Modelo-Ciclo de Vida-Plan
• Modelo de ciclo de vida:
– abstracción de las fases o estados por los que pasa un producto software a lo
largo de su vida
• Ciclo de vida:
– es la secuencia ordenada de actividades o instancias de actividades que se
deben ejecutar a lo largo de la vida del software, indicando quién tiene la
responsabilidad de ejecutarlas.
– Se obtiene haciendo corresponder las actividades del estándar con un
modelo de ciclo de vida concreto: Mapa de Actividades
– Cada proyecto debe definir su propio ciclo de vida
• Plan del proyecto:
– A la información del ciclo de vida se añade la programación temporal
(schedule) y la asignación de recursos.
 Mapa de Actividades
ACTIVIDADES FA RS DP DD CO IN IM OM RE
Identificar posibles modelos de ciclo de vida a aplicar X
Seleccionar el modelo de ciclo de vida del proyecto X
Hacer corresponder las actividades del estándar con el X
modelo de ciclo de vida seleccionado
Asignar recursos X X X X X X X X X
Establecer el entorno del proyecto X X X
Planificar la gestión del proyecto X X
Analizar riesgos: X X X X X X X
Elaborar planes de contingencia X X X X X X
Gestionar el proyecto X X X X X X X X X
Mantener registros X X X X X X X X
Implementar el método de comunicación de problemas X X X X X X X X X
Planificación de la Gestión de la Calidad X X
Definición de métricas X X X
Gestión de la Calidad del Software X X X X X X X X X
Identificar necesidades de Mejora de la Calidad X X X X X X X X X
...