CICLO DE VIDA YPROCESO 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 individual5.000-25.000 Pequeño equipo25.000-100.000 Equipo grande subdividido100.000-1.000.000 Varios equipos1.000.000-10.000.000 Varias empresas10.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 obtenersoftware 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 encomponentes 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ónrequisitos

Diseñarsistema

Codificar Probar

Necesidad Especific.requisitos

Diseño Código Sistemasoftware

PROCESO DECONSTRUCCIÓN

CICLO DE VIDA

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 Requisitosy Diseño

Implementar Pruebas

Sistemas de Control 46 20 34Sistemas especiales 34 20 46Sistemas Operativos 33 17 50Sistemas científicos 45-53 27-36 15-23Sistemas de Gestión 44 28 28

Modelo en VRequisitos

sistema Requisitossoftware Diseño

preliminar Diseñodetallado

Codificación

Pruebascomponente

Pruebasunidad

Integraciónsoftware

Pruebassistema

Integraciónsistema

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

Determinación de objetivos, alternativas, restricciones

Evaluación de alternativas, identificación de riesgos

Desarrollo, verificación delproducto del próximo nivelPlanificación de las próximas fases

Análisisderiesgo

Análisisderiesgo

Análisisderiesgo

Análisisderiesgo

Prototipooperativo

PrototipoPrototipoPrototipo

Concepto deoperación

Validación derequisitos

Validación y verificacióndel diseño

Implementación

Requisitosdel softwaare

DiseñoDiseñodetallado

CodificaciónPruebadeunidad

Integracióny prueba

Pruebadeaceptación

Plan de requisitosPlan de ciclo de vida

Plan del desarrollo

Plan de la integracióny prueba

Costes acumulados

Revisión

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 ActividadesACTIVIDADES FA RS DP DD CO IN IM OM REIdentificar 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 elmodelo de ciclo de vida seleccionado

X

Asignar recursos X X X X X X X X X

Establecer el entorno del proyecto X X XPlanificar 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 XGestionar el proyecto X X X X X X X X X

Mantener registros X X X X X X X XImplementar 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 XGestió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

...