Tutorial

Cómo definir un ciclo de vida

SPIN-CHILE Noviembre 2000

Relator : Guillermo A. Leyton García gleyton@elqui.cic.userena.cl

1. Definiciones 2. Modelos de Ciclo de Vida3. Estándares para Procesos del Ciclo de Vida

del software4. Casos prácticos de Ciclos de Vida5. Resumen final6. Modelo OSO : Ciclo de Vida para

aplicaciones web - Relator C.Bravo

Agenda

1. Definiciones

Ciclo de Vida

“Todo esfuerzo de desarrollo de software conlleva un CICLO DE VIDA que consiste en realizar todas las actividades comprendidas entre el momento en que se inicia la VERSION 1.0 de un producto de software(desde la idea de una persona) hasta el momento en que la VERSION X.Z exhala su último aliento en la máquina del último cliente”

Ciclo de Vida

Análisis Sistema Construcción

DiseñoPrueba

mantención

Actividades principales del Ciclo de Vida ó Estados en el Proceso de Desarrollo

Análisis de Requisitos

¿ primero ?

¿ tercero ?

¿ segundo ?

Modelos de Ciclos de Vida

Describen en qué orden son consideradas las distintas actividades del ciclo de vida.

Definen un plan básico de actividades.

¿ Cómo determinan un Plan ?Planificar :

Regular un proceso productivo conforme a un modelo determinado, obteniendo un plan.

Plan: Organización de actividades

Actividad Conjunto de tareas

TareaTrabajo realizado en un tiempo determinado

MétodoEn proyectos de construcción de software es tan importante el producto final como el proceso por el cual fue obtenido.

Método: como construir sistemas. Abarca estrategias, definición de las herramientas y técnicas a utilizar, planificar, estimar y procedimientos.Todo Método más o menos cientifico reconoce tres áreas:

AnálisisDiseño Implementación

Dependiendo del orden que tengan estas áreas, es que describiremos diversos Ciclos de Vida.

ParadigmaModelo de modelos. En una metodología implica la forma en que vamos a combinar las etapas de análisis, diseño e implementación.

1. Análisis2. Diseño3. Implementación

Por ejemplo: 1, 2, 3 Cascada (sin Retroalimentación). 1, 3, 2 Prototipo 1, 2, 3, 1, 2, 3, 1, 2, 3, ..., Espiral

Paradigma

AnalisisRequisitos globales a nivel de sistema.Recopilación de requisitos para el software.Comprensión del ámbito de la información del

software.Entender la futura factibilidad del sistema.

Paradigma

DiseñoEstructura eficaz del sistema.Arquitectura del software.Detalle procedimental.Caracterización de la interfazProblemas de adecuación del software.

Paradigma

ImplementaciónTraducir el diseño a un lenguaje que puede

interpretar la máquina.Probar la lógica interna del software.Depuración de la codificación.Puesta en marcha del proyecto

2. Modelos de Ciclo de Vida

Ambito de los modelos

Los modelos pueden centrarse en una parte limitada de todo el ciclo de vida. Cuando se centran desde la idea hasta la versión inicial de un producto se denominan modelos de desarrollo de software.

Modelos de desarrollo de software

Prueba y Error Cascada (tradicional)EvolutivoPrueba y ErrorReingenieríaPrototipación rápidaUso de Lenguajes de alto nivel (4ª Generación.)Experimental

Modelos de desarrollo de software

EvaluaciónEnsamblaje de componentes reusablesEspiralRADRational Unified ProcessModelo de desarrollo para software webOtros

Modelos Prueba y Error (orden: I, A, D)

•Sirve solo si el proyecto es chico o manejable.

•Depende de la experiencia no documentada.

•Puede malgastar esfuerzos

Ing. de Sistemas

Análisis

Diseño

Codificación

Prueba

Mantención

Modelo tradicional CASCADA( genérico)

CASCADA ( orden: A, D, I)

•Los proyectos no tienen flujo secuencial como el que propone.•No es fácil establecer al principio todos los requisitos con el cliente.•Hasta etapas finales del proyecto no hay nada funcionando.

Modelo CASCADAPoco realista :

Los proyectos raramente siguen el flujo secuencial que propone el modelo

El cliente no establece explícitamente al principio todos los requisitos

Se puede volver atrás, pero es ¡más difícil !Mucho “rework” ( repetición de trabajo )Sólo hasta llegar a las etapas finales del proyecto, no

estará disponible una versión operativa del software

Modelo CASCADA

¿ Cuándo usarlo ?• Para velocidades de desarrollo lentas• Cuando los requerimientos están muy completos y detallados y

el área de aplicación es muy estable• Cuando el software no requiere de interacción hombre-máquina.

¿ Cuándo NO usarlo ?• ( todo lo contrario de lo anterior )

HIPOTESIS : Bien implementado, puede resultar mejor que otros modelos

CASCADA incremental

Requerimientos Diseño Implementación Prueba

Analysis Diseño Implementación Prueba

Entrega del primer incremento

Incremento 1

Incremento 2

Entrega del segundo incremento

Requerimientos

Requerimientos Diseño Implementación Prueba

EntregaIncremento 1

TIEMPO CALENDARIO EntregaIncremento 2

EntregaIncremento 3

Incremento 3

Entrega del tercerincremento

Hitos

Modelo EVOLUTIVO

Recolección requisitos

Construcción prototipo

Evaluación prototipo

Inicio Término

Modelo EVOLUTIVO

Descripción :• Se va completando el producto de software, a

medida que avanza el proyecto, a partir de un prototipo.

• Se comienza desarrollando el prototipo , con los requerimientos más claros o completos.

• Exige que cliente y desarrollador se pongan de acuerdo respecto a cuando el prototipo es lo suficientemente bueno como para entregarlo como producto final.

Modelo EVOLUTIVO

Definición de PROTOTIPO• El prototipo puede ser :

– a) Un modelo en papel – b) Un modelo basado en herramientas de PC que

describa la interacción hombre-máquina– c) Un programa que implemente algunas funciones

del software– d) Un programa ya existente que contenga algunas

de las funciones y que sirva de muestra.

Modelo EVOLUTIVO

¿ Cuándo usarlo ?– Cuando los requerimientos cambian con rapidez– Cuando el cliente es reacio a especificar los

requerimientos con más detalle– Cuando ni el cliente o desarrollador, conocen bien el

área de aplicación– Cuando no se está seguro de la arquitectura que tendrá

el software– Cuando se requiere una velocidad de desarrollo rápida

Modelo EVOLUTIVO

¡ Principales inconvenientes !– No conocer desde el comienzo las características del

producto aceptable o final.– No conocer desde el comienzo la cantidad de

iteraciones a realizar, y por ende, los plazos.– Se ignoran aspectos de calidad y mantención del

software.

Modelo PROTOTIPACION(orden:A, I, D)

•Hay prototipos que se construyen para desecharse.•El cliente una vez que ve funcionando el prototipo quiere que lo mejoren y no que hagan un nuevo sistema.•El programador comunmente adquiere vicios por desarrollar rápidamente.

Modelo PROTOTIPACION RAPIDA

Construir prototipos sucios y desechables, utilizando distintas herramientas para su utilización : generadores de informes, generadores de ventanas, herramientas de productividad como Word o Excel,etc.

Modelo PROTOTIPACION RAPIDA

¿ Cuándo usarlo ?Para evitar un ataque cardíaco debido a la presión

del cliente por ver algo funcionando.¿ Cuándo NO usarlo ?

No se debe usar en lo posible.

ModeloUSO DE LENGUAJES DE ALTO NIVEL

4ª Generación (orden: D, I, A) Descripción :

• Abarca el uso de una amplia gama de herramientas de software que especifican el software a alto nivel y luego la convierten automáticamente al código fuente.

• Se orienta a la posibilidad de especificar el software a un nivel más próximo al lenguaje natural.

• Idealmente el cliente describe los requerimientos que son traducidos a un prototipo operativo (casi on-line).

ModeloUSO DE LENGUAJES DE ALTO NIVEL

4ª Generación (orden: D, I, A)

•Las herramientas no son más fáciles de usar que los lenguajes de programación.•El código producido por las herramientas es ineficiente (rígido).•El diseño inicial queda desvirtuado (intercalaciones, otras).

ModeloUSO DE LENGUAJES DE ALTO NIVEL

¡ Principales inconvenientes !– El tipo de herramientas utilizadas sólo está disponible

para ámbitos de aplicación específicos ( generalmente para sistemas de gestión )

– El cliente puede no estar seguro de lo que necesita, o ser ambiguo al plantear lo que desea. Las herramientas de alto nivel actuales no son aún tan sofisticadas como para entender el lenguaje natural.

– Induce a saltarse la actividad de Diseño (sólo esbozos).

ModeloUSO DE LENGUAJES DE ALTO NIVEL

¿ Cuándo usarlo ?– Si un alto % de los requerimientos es de :

clasificación, consulta y presentación de datos. ¿ Cómo usarlo ?

– Efectuando un diseño global del sistema– Efectuando una prueba completa y elaborando la

documentación necesaria, para transformar la implementación de “4gl” ó “5gl” en un producto de software.

Modelo Ensamblaje de Componentes Reusables

El proceso de desarrollo se focaliza (centrado) en integrar partes del sistema ya existentes más que en desarrollarlas (obviamente se debe tener o al menos conocerlas).

El ensamblaje de componentes es una tecnología emergente.

ModeloEnsamblaje de Componentes Reusables

¿ Qué significa realmente ensamblar componentes de software ?Analogía : Un Ingeniero Electrónico debe construir

el hardware de control para un producto basado en microprocesador. Diseña el circuito digital, hace algunos análisis para asegurar que la función deseada será realizada y busca en un catálogo de componentes digitales, lo que necesita.

ModeloEnsamblaje de Componentes Reusables

Componentes reusables :Componente : parte del producto que encapsula

datos y proceso. Puede ser una unidad mínima, módulo o sub-sistema.

Permiten que el diseñador pueda concentrarse en los aspectos innovativos de un diseño (es decir, las partes que representan algo nuevo).

Deben ser diseñados e implementados, de modo que puedan ser usados en distintos productos.

ModeloEnsamblaje de Componentes Reusables

¿ Cómo se identifica un componente en un catálogo ?Componente : PART_876_AFunción : XXXXXXXXXXXXXInterfaz : (parámetros ubicación, parámetros

componente A, parámetros componente B)Set de guías de integración o ensamble.

ModeloEnsamblaje de Componentes Reusables

Identificar componentes candidatos

Buscar

componentes

en librerías Extraer componentes disponibles

Construir componentes no

existentes Catalogar nuevos

componentes

Construir iteración n-ésima del producto

Planificación

Ciclo 1

Ciclo 2

Ciclo 3

Ciclo 4

Ingeniería

Análisis de Riesgos

Evaluación Cliente

Modelo ESPIRAL( Barry Boehm )

Punto de entrada del proyecto

Modelo ESPIRAL (orden: A, D, I)

•Puede alargar innecesariamente el proyecto.•La función de análisis de riesgo debe ser clara.•La sucesivas aproximaciones pueden ser divergentes.

Modelo ESPIRAL

Modelo EN ESPIRAL : ¡ el más realista !• Cubre las mejores características del modelo cascada y

del evolutivo, agregando dos actividades que faltan en aquellos : Planificación y Análisis de Riesgos

• Divide un proyecto en mini-proyectos.Cada proyecto se centra en uno o más riesgos hasta que todos estén controlados

• Después de controlar todos los riesgos, recién el proyecto termina.

Modelo ESPIRAL

Principales marcos de actividades o regiones de actividades

– 1. Planificación : Determinar objetivos, alternativas y restricciones

– 2. Análisis de Riesgos : Identificar riesgos y analizar alternativas de resolución

– 3. Ingeniería : Desarrollar el producto del sgte. nivel – 4. Evaluación del Cliente : Someter a comprobación

del cliente el producto de ingeniería.

Modelo ESPIRAL

Cada iteración contempla los sgtes. cinco pasos :

1. Determinar objetivos, alternativas y restricciones2. Identificar y resolver riesgos3. Evaluar alternativas y decidir si continuar o no4. Generar los productos de esta iteración y comprobar

que son correctas5. Planificar la siguiente iteración (si se decide

continuar)

Modelo ESPIRAL

RIESGO• Definición :

– Hecho que pueda ocurrir en el futuro• Pueden referirse a :

– Planificación– Requerimientos poco comprensibles– Entorno de desarrollo– Personal contratado– etc.

Modelo ESPIRAL

Riesgo Probabilidadque ocurra

Magnitudde la pérdida(semanas )

Exposición ariesgo( semanas )

Planificación demasiadooptimista

50 % 5 2,5

Aprobación del proyectotarda más de lo esperado

25 % 4 1,0

La nuevas herramientasde programación noproducen el ahorroprometido

30 % 5 1,5

Modelo ESPIRAL( extensión del modelo para el Ciclo de Vida completo )

Planificación

Ciclo 1Ciclo 2

Ciclo 3Ciclo 4

Ingeniería

Análisis de Riesgos

Evaluación del Cliente

Construcción & Release

Comunicación con el Cliente

Proyectos de Mantención de productos

Proyectos de desarrollo de requerimientosProyectos de Desarrollo de nuevos productosProyectos de Evolución de productos

Modelo ESPIRAL( extensión del modelo para el Ciclo de Vida completo )

Regiones :Comunicación con el cliente

• Tareas para establecer efectiva comunicación entre desarrollador y cliente

Planificación Análisis de Riesgos Ingeniería Construcción & Release

• Tareas para construir,probar, instalar y proveer soporte al usuario(documentación y capacitación)

Evaluación del Cliente

Modelo ESPIRAL

¡ Principales inconvenientes !– Es un modelo complicado – Requiere de una buena gestión– Requiere de conocimientos sobre “Gestión de

Riesgos”– Puede ser difícil convencer a los clientes : es un

modelo relativamente nuevo y no se ha usado tanto como los otros

RAD : Rapid Development Model

Es un modelo secuencial que enfatiza un ciclo de desarrollo extremadamente corto : es un modelo de alta velocidad.

El desarrollo rápido se alcanza con la construcción basada en componentes

RAD : Rapid Development Model

Modelamiento del negocio

Modelamiento de datos

Modelamiento de procesos

GENERACION

APLICACION

Ensamblaje de componentes reusables, en base a especificación de componentes

Prueba &

Vuelta atrás

Componentes ya están probados , sólo se prueban las interfaces60 - 90 días

RAD : Rapid Development Model

Usado principalmente para aplicaciones de negocios.

Enfatiza la Reusabilidad (basada en tecnología orientada al objeto)

No es apropiado cuando los riesgos técnicos son altos.

Para proyectos grandes y escalables, RAD requiere suficientes recursos humanos para crear un alto número de equipos RAD.

Rational Unified Process

Enfatiza una Arquitectura del Software robusta y modelos, más que una extensa documentación.

Basado en el Modelo en Espiral para los aspectos dinámicos (ciclos, fases, iteraciones e hitos )

Basado en el Modelo Cascada para los aspectos estáticos ( componentes del proceso : Requisitos,Análisis y Diseño,Implementación y Testing )

Soporta totalmente técnicas orientadas al objeto Soporta desarrollo basado en componentes Actividades son conducidas por Casos de Uso.

Rational Unified Process(proceso en dos dimensiones)

Aspectos estáticos :

Organización en base a los contenidos, flujos de trabajo, productos de trabajo y equipo de trabajo

Aspectos dinámicos : Organización a lo largo del tiempo

Iteraciones

Iteración preliminar

Incepción Elaboración Construcción Transición

It.

N + 1

It.

1

Componentes del Proceso

Captura de requerimientos

Análisis&DiseñoImplementación

Testing

GestiónAmbiente de desarolloLiberación

Componentes de soporte

Modelo de Desarrollo para Web( modelo genérico basado en Cascada )

Características de un WEB-SOFTWARE :Integración de información de distintas fuentes:

• bases de datos, documentos escritos, fotografías,etc.Trabajo interdisciplinario : profesionales de la

información(bibliotecólogos), profesionales de la comunicación(periodistas), profesionales informáticos(ingenieros en computación), profesionales de áreas de marketing(ingenieros comerciales) y otros.

Requerimientos de altas velocidades de desarrollo y alta usabilidad del producto

Un WEB-SOFTWARE ESTA SIEMPRE EN CONSTRUCCION

Modelo de Desarrollo para Web( modelo genérico basado en Cascada )

Definición de

contenidosRecolección de

Información

Arquitectura de la Información

Diseño funcional

del software

Diseño gráfico

Selección de Información

Construcción&Release

Modelo de Desarrollo para Web( modelo genérico basado en Cascada )

Actividades :1. Definición de contenidos

• Identificar temas a presentar2. Recolección de información

• De distintas fuentes y medios de almacenamiento3. Selección de información

• Del total de información recolectada seleccionar la información relevante

4. Arquitectura de la información• Existen dos tipos : lineal y jerárquica

Modelo de Desarrollo para Web( modelo genérico basado en Cascada )

Actividades :5. Diseño funcional

• Funciones concretas del software son la habilitación de : tablas de contenidos, banners, links, accesos a bases de datos, accesos a herramientas, motores de búsqueda,etc.

6.Diseño Gráfico• Características visuales : disposición de la información en

la pantalla, uso de colores, definición de tipos de letras, uso de imágenes, definición de la señalética(íconos).

7. Construcción&Release• Similar a otros modelos

Resumen Modelos de desarrollo de software

No son modelos alternativos sino complementarios : pueden combinarse para aprovechar las ventajas de cada uno en un único proyecto.

Se deben equilibrar los requerimientos de velocidad de desarrollo y el COMPROMISO CON LA CALIDAD.

3. Estándares para Procesos del Ciclo de Vida del Software

Proceso

Insumos de entrada Productos

( Conjunto de actividades )

PROCESO

Descomposición de un Proceso

PROCESO

Actividad 1 Actividad 2 Actividad N

Ejemplo : Proceso de Desarrollo

Ej. Especificación de Requerimientos

Ej. PruebaEj. Planificación

Ej. Narrar requerimientos

Ej. Representar requerimientos en modelos

Ej. Presentar modelos al cliente

Tarea 1 Tarea 2 Tarea 3

Atributos de un Proceso

1. Objetivos 2. Roles y Responsabilidades 3. Entradas al proceso 4. Actividades y Tareas durante el proceso 5. Salidas desde el proceso 6. Tiempos y consideraciones de manejo de excepciones 7. Recursos 8. Supuestos 9. Restricciones y materiales de soporte 10. Verificación y métricas

Paradigma ETVX

MODELO ETVX de Ron Radice ( 1996 )

(Dibujo - Gentileza de Olivia Segovia )

Entry Task eXit

Ejemplo de representación de un Proceso

Proceso de Análisis de Requerimientos

CRS-APP

CRS-APP Analysis

Requirements

GUI Prototype

Software Requirements Specification (SRS)

Unified Modeling Language (UML )

INPUTS OUTPUTSPROCESS

Customer Requirements Specification (CRS)

Atributos de Calidad del proceso de desarrollo

Atributos de Calidad :Entendible

• Que esté explícitamente definido y sea fácil entender su definición

Soportado• Que las actividades sean apoyadas por herramientas

CASEVisible

• Que cada actividad termine con resultados claros , de modo que el “progreso” sea externamente visible

Atributos de Calidaddel Proceso de Desarrollo

Atributos de Calidad :Aceptable

• Que sea aceptado y usado por los Ingenieros de Software responsables por el producto de software

Confiable• Que errores en el proceso sean evitados o corregidos, antes

que influyan en el producto de software.Robusto

• Que el proceso pueda continuar, a pesar de los problemas inesperados

Atributos de Calidad del Proceso de Desarrollo

Atributos de Calidad :Mantenible :

• Que el proceso evolucione para reflejar cambios organizacionales

Rápido :• Que el proceso libere el producto de software lo

antes posible.

CMM - Capability Maturity Model

Area Clave de Proceso Nivel 2 : Planificación de proyectos de software

Actividad 5 “Un Ciclo de Vida con estados predefinidos y de

tamaño administrable es identificado o definido”.

Norma IEEE Std-1074 Standard for Developping Software Life Cycle Processes

( ver Tutorial : Adaptación de las Normas IEEE para IS - Rel. Olivia Segovia)

Contempla más de 70 actividades que cibren todas las etapas clásicas de un proyecto

No está relacionada con ningún modelo de ciclo de vida en particular, lo que permite adaptarla fácilmente a cualquiera

Norma IEEE Std-1074 Standard for Developping Software Life Cycle Processes

( ver Tutorial : Adaptación de las Normas IEEE para IS - Rel. Olivia Segovia)Modelización CVSGestion de proyecto

Desarrollo

Pre-Desarrollo

Post-Desarrollo

Procesos Continuos

Norma IEEE Std-1074 Standard for Developping Software Life Cycle Processes

( ver Tutorial : Adaptación de las Normas IEEE para IS - Rel. Olivia Segovia)

Fase Proceso 1 : ResumenLista de las actividades (de 1 a n)

• Por cada actividad (de la lista)– Tabla de Información de Entrada y procesos de

donde proviene y la actividad correspondiente. – Descripción de la actividad – Tabla de Información de Salida y procesos hacia

donde se dirige esta información especificando la actividad.

Norma IEEE Std-1074 Standard for Developping Software Life Cycle Processes

( ver Tutorial : Adaptación de las Normas IEEE para IS - Rel. Olivia Segovia)

Seleccionar un modelo de ciclo de vidaIdentificación de modelos de ciclo de vida.Elección de un modelo de ciclo de vida según

el proyecto. Ej. de Ciclos de vida: Cascada, Incremental,

Espiral, etc.

Norma IEEE Std-1074 Standard for Developping Software Life Cycle Processes

( ver Tutorial : Adaptación de las Normas IEEE para IS - Rel. Olivia Segovia)

Gestión de proyecto

Iniciación del proyecto• Relacionar las actividades de IEEE-1074 con el ciclo de vida

elegido.• Asignar recursos (humanos, materiales, software…)• Elegir ambiente proyecto (metodologías, normas, herramientas,

exigencias contractuales…)• Planificar la gestión de proyecto (organización del proyecto,

responsabilidades, definición de los procesos de gestión y de control, presupuestos, carta Gantt…) IEEE 1058.1 Plan de gestión de proyecto

ISO 12207 (1995) Ciclo de Vida del Software

4. Casos prácticos de Ciclos de Vida

¿Se puede copiar un modelo de ciclo de vida ?

Modelo Desarrollo SW

Análisis / Diseño Construcción Pruebas

Implantación Manutención

Iniciativa Requerimientos Anteproyecto

Charla SPIN-CHILE 2000 :

Aseguramiento de Calidad de Software - Banco Sudamericano

Integral SpecificationReview (ISR)

DEFINITION PHASE : Planning and Requirements

Software Project

PlanningRevisio

n

• Software Project Plan (SPP)• Quality Assurance Plan (QAP )• Software Configuration Plan (SCP )

Requirement Analysis

and prototype generation

• Soft.Requirements Especification(SRS-D/F/G/P)• Draft User’s Manual • Software Test Plan ( STP )

Prototype(pictures)

Customer RequirementsSpecification

(CRS-D/F/G/P )

Revision

Red = Sales Manager

Green = Project Review Board

Black = Architecture Board

Brown = Project Manager

Blue = Technology and Operation Management

Pink = Software Development Management

Project Plan Review

Software Requirements

Review

Arquitectura

DEVELOPMENT PHASE : Design, Implementation and Internal Test

High - Level

Design

DetailedDesign

- Architectural Design (SDS-A) - Data Design ( SDS-D) - User Interface Design (SDS-I) - Performance (SDS-P)

PrototypeOperational Source Code

Imple-

menta-

tion

- Algorithmic Design (SDS-AL)- Components Design(SDS-MO)- Software Test Description (STD)

Revision

Revision

SQA

Revision

SQASoftware Design Review

Software Design Review

Source Code Review

Arquitectura

IMPLEMENTATION AND START-UP PHASE : Quality Assurance IMPLEMENTATION AND START-UP PHASE : Quality Assurance Tests Tests

Unity and Integration

Tests

Startup

Phase

Software Test Reports (STR)

Beta Version

User’s Manual

Maintenance

Modified Source Code

ModifiedDocuments

Bugs feedback to previous steps

Revision

SQA

Revision

SQAQAT # 1

Certification

QAT#3On site

QAT # 2

OPERATION PHASE :

Post-implementation support Control de Cambios

Actividades deSoporte

Actividades deIngeniería Dependencia

PresentaciónCiclo 2

PresentaciónCiclo 3

InstalaciónProductoVersión 1

InstalaciónProductoVersión 2

InstalaciónProducto

Final

CICLO 1 CICLO 2 CICLO 3CICLO 0

CC61A PROYECTO DE SOFTWARECICLO DE VIDA (ACTIVIDADES)Planificación

delProyecto

Especificaciónde Pruebas

RequerimientosFuncionales 3

Especificación deComponentes

Especificación dela Arquitectura

Especificaciónde Pruebas

ConstrucciónCiclo 3

PresentaciónCiclo 1

PresentaciónProyecto

Pruebas deAceptación

ConstrucciónCiclo 1

Ejecución dePruebas 1

Especificación deComponentes

Especificación dela Arquitectura

RequerimientosFuncionales 1

Revisión

RequerimientosFuncionales 2

Especificación deComponentes

Especificación dela Arquitectura

Especificaciónde Pruebas

ConstrucciónCiclo 2

Ejecución dePruebas 2

Revisión

Certificacióndel

Producto

Empaquetamientodel Producto

5. Resumen final

Acciones claves para el Ciclo de Vida

Su definición es esencial para la planificación.Su representación y documentación apoya su

difusión, revisión y evaluación.Su difusión apoya un lenguaje común en el

equipo de trabajo, los nombres y responsables de los productos de trabajo y los entregables al cliente.

Ningún modelo de Ciclo de Vida es mejor!

No existe un Ciclo de Vida mejor para todos los proyectos : el mejor modelo de ciclo de vida para un proyecto particular depende de las necesidades del mismo.

La efectividad del modelo dependerá de cómo se implemente.

Para seleccionar el modelo de Ciclo de Vida más conveniente para un proyecto, es útil responder un checklist previo.

Ciclo de Vida: la fórmula del éxito

El ciclo de vida puede convertirse en el secreto de producción de un software o la fórmula del éxito de un proyecto de software:No. de productos de trabajoNo. de entregablesEsfuerzo y plazos por productoCostos por producto

Fórmula

Algoritmo recomendado para Ciclo de Vida versión 1.0

Paso 1:Escribir las actividades y tareas actuales para desarrollar un determinado tipo de producto.

Paso 2:Representarlas en un dibujo (una parte del modelo) Paso 3:Documentar las actividades y tareas, y todos los atributos, usando el

paradigma ETVX. Paso 4:Difundir por todos lados el modelo completo versión 1.0 Paso 5:Efectuar una Revisión Técnica Formal del modelo Paso 6:Realizar las modificaciones con el feedback de la revisión y obtener

la versión 1.1( iterar hasta que sea necesario) Paso 7:Aplicarlo a un tipo de proyecto para el cual fue definido Paso 8:Evaluar al término del proyecto Paso 9:Volver a Paso 1 para implementar mejorar y producir la versión 2.0

Referencias Libros :

Roger Pressman - “Software Engineering : A practitioner´s approach” - 4ta. Edición. McGraw-Hill.

Steve McConnell - “Desarrollo y Gestión de Proyectos Informáticos” - McGraw-Hill.

Papers “Models for Software Evolution : Life Cycle and Process”,SEI-CM-10-1.0 “Software Process Modeling”, CMU/SEI-88-TR-9 “Iterative and Incremental Development(IID)”, Robert C.Martin, Junio 1999 “OSO : Un paradigma de desarrollo de software para Web”, Cristián Bravo Lillo,

CEIS-PA-02-2000. Normas internacionales

Norma IEEE 1074 - “Standard for Developing Software Life Cycle Processes” ISO 12207 - “Information Technology - Software Life Cycle Processes”