Unidad 2 CicloDeVida ModelosDeProcesos

8/18/2019 Unidad 2 CicloDeVida ModelosDeProcesos

1/59

Ing. Mabel Torres 2k4 – 2k7


2/59


3/59

BIBLIOGRAFÍA

[1] Kendall & Kendall. Análisis y Diseño de Sistemas. Prentice Hall. 6ta.

Ed.

o Capítulo 1: El rol del analista

[2] Sommerville Ian. Ingeniería del Software. Prentice Hall. 7ta. Ed.

o Capítulo 2: Sistemas Socio-Técnicos

o Capítulo 4: Procesos del Software


4/59

D ESPUÉS DE LA CLASE UDS. PODRÁN…


5/59

AGENDA DE TEMAS

Definición de ciclo de vida de los Sistemas de Información

El ciclo de vida de los sistemas de información según elestándar ISO/IEC 12207

Las actividades del ciclo de vida del desarrollo de lossistemas de información

Importancia del ciclo de vida para el trabajo de los ingenieros ensistemas

Modelos de proceso de desarrollo del Software

Modelo en Cascada

Modelo Evolutivo

Modelo en Espiral


6/59

AGENDA DE TEMAS






Modelo en Cascada

Modelo Evolutivo

Modelo en Espiral


7/59

Desde el punto de vista de los Sistemas de Información, elciclo de vida es el conjunto de fases [o procesos] por las quepasa el sistema desde que se concibe [o inicio], se desarrollahasta que se retira del servicio finalizando su uso[desmantelamiento del sistema].

Las fases o procesos están estandarizados de manera quepuedan ser adaptados a las necesidades de quién lo use.

El estándar para el ciclo de vida de los sistemas de

información es el ISO/IEC 12207.

CICLO DE VIDA PARA LOS SISTEMAS DE INFORMACIÓN


8/59

AGENDA DE TEMAS






Modelo en Cascada

Modelo Evolutivo

Modelo en Espiral


9/59

Organización internacional de estandarización

(International Organization for Standardization)

Comisión Electrónica Internacional

Un estándar es un documento establecido por consenso,aprobado por un organismo reconocido, y que ofrece

reglas, guías o características para que se use

repetidamente. Especifican qué hacer no cómo hacerlo.

¿Q UÉ ES UN ESTÁNDAR?


10/59

ESTÁNDAR ISO/IEC 12207 PARA EL CICLO DE VIDA DELOS SISTEMAS DE INFORMACIÓN


11/59

AGENDA DE TEMAS






Modelo en Cascada

Modelo Evolutivo

Modelo en Espiral


12/59


13/59

CICLO DE VIDA

No hay un acuerdo en la cantidad de fases que incluye el ciclo de vida del

desarrollo de sistemas

Kendall y Kendall divide el ciclo de vida del desarrollo en siete fases las cuales se

pueden observar en la siguiente figura:


14/59

PROCESO DE INGENIERÍA EN SISTEMAS

Este tema se completará en la próxima clase


15/59

PROCESO DE INGENIERÍA EN SISTEMAS

Sommerville, enfoca el ciclo de vida del sistema como el Proceso de la Ingeniería

de Sistemas


16/59

Involucra a la fase Análisis de Sistemas

Se especifica qué es lo que el sistema debe hacer,es decir:

•Las funciones que el sistema debe proporcionar

• El comportamiento o propiedades esenciales ydeseables

• La relación del sistema con otros sistemas deinformación

Para lograrlo se consulta con los clientes y usuariosfinales del sistema

ETAPA DEFINICIÓN DE REQUERIMIENTOS


17/59

AGENDA DE TEMAS






Modelo en Cascada

Modelo Evolutivo

Modelo en Espiral


18/59

El Ciclo de Vida de Desarrollo de Sistemas sirve de basede los procesos utilizados para desarrollar un sistemade información.

Es conveniente seleccionar una metodología de trabajoporque:

construir un sistema socio-técnico es una actividad complejaque requiere un gran esfuerzo sobre todo de las personas.

el sistema tiene un conjunto de componentes como elsoftware, hardware, datos, documentos, redes, etc., loscuales debemos gestionar.

las personas que interactúan entre sí, tienen diferentes

grados de conocimiento, asumen diferentes roles y poseendiferentes intereses hacia el sistema.definir un marco de trabajo nos permite organizar el proceso

de desarrollo definiendo pautas a seguir y restricciones acumplir.

IMPORTANCIA DEL CICLO DE VIDA DE DESARROLLO

ú


19/59

Adoptar

Desarrollar

Obtienen y Capturan las

necesidades

Proveen las necesidades

Clientes

Equipo de Desarrollo

Ingenieros en Sistemas

Implementan Requisitos

Basado en

Ciclo de Vida

Especifican Requisitos

Elegimos un marco

de trabajo que nos

permita organizar el proceso de

desarrollo

Construir Sistemasde Información

socio-técnicos

requiere un gran

esfuerzo sobre

todo de las

personas

Las personas interactúan entre

sí, con diferentes grados de

conocimiento, con diferentes

roles y con diferentes intereses.

Tenemos que

ordenar

nuestro

trabajo para

planificar el proceso de

desarrollo


20/59

AGENDA DE TEMAS






Modelo en Cascada

Modelo Evolutivo

Modelo en Espiral


21/59


22/59

Un proceso de desarrollo del software es un conjuntocompleto de actividades y resultados asociadosnecesarios para transformar los requerimientos de uncliente / usuario en un producto o sistema.

¿Q UÉ ES UN PROCESO DE DESARROLLO DEL SOFTWARE?

Ingeniería del software, Sommerville, cap. 1


23/59

ACTIVIDADES COMUNES A LOS PROCESOS DE DESARROLLODEL SOFTWARE

Existen cuatro actividades fundamentales comunespara todos los procesos de desarrollo:



24/59

Un modelo de proceso es una descripción simplificadade un proceso del software que presenta una visión deese proceso.

El modelo de proceso define el ciclo de vida que seadoptará para el proyecto de sistemas.

Los modelos de proceso pueden incluir:Flujo de trabajo: muestra la secuencia de actividades en elproceso con sus entradas, salidas y dependencias. Lasactividades representan acciones humanas.Flujo de documentos: muestra los documentos o artefactos queproducen cada una de las actividades y cómo esos documentosse transforman por acción de las personas o por lascomputadoras.Modelo de rol/acción: representa los roles de las personasinvolucradas en el proceso del software y las actividades de lsque son responsables

¿Q UÉ ES UN MODELO DE PROCESO DE DESARROLLO DELSOFTWARE?



25/59

Rol

Flujo de trabajo

1 2

MODELO DE PROCESOS DE DESARROLLO DEL SOFTWARE

El flujo de trabajo: muestra la secuencia de

actividades en el proceso con sus entradas,

salidas y dependencias. Las actividades

representan acciones humanas.

El flujo de documentos: muestra los

documentos o artefactos que producen cada

una de las actividades y cómo esos

documentos se transforman por acción de las

personas o por las computadoras.

Un modelo de rol/acción: representa losroles de las personas involucradas en el

proceso del software y las actividades de

las que son responsables.

Actividades


26/59


27/59

Modelo en Cascada Modelo Evolutivo

Modelo en Espiral

MODELOS DE PROCESOS DE DESARROLLO DEL SOFTWARE


28/59

Definición de

Requerimientos

Diseño del Software

y del Sistema

Implementación y

Prueba de unidades

Integración y Pruebadel Sistema

Operación y

Mantenimiento

Modelo en cascada – Conocido

también como: Modelo lineal

secuencial o Ciclo de vida del

software


MODELO EN CASCADA

Flujo de trabajo


29/59


30/59

Definición de

Requerimientos


y del Sistema

Implementación y

Prueba de unidades


Operación y

Mantenimiento

MODELO EN CASCADA




software

Flujo de trabajo

M C


31/59

MODELO EN CASCADAFLUJO DE DOCUMENTOS

Especificación de Requerimientos

Especificación del Diseño

Código fuente y pruebas

Cambio

Diseño y resultado

de pruebas

Definición de

Requerimientos


y del Sistema

Implementación y

Prueba de unidades


Operación y

Mantenimiento

Flujo de trabajo

M C


32/59

MODELO EN CASCADAROLES POR CADA FASE

Definición de

Requerimientos


y del Sistema

Implementación y

Prueba de unidades


Operación y

Mantenimiento

• Analista de

Sistemas

• Diseñador de Sistemas

• Arquitecto de Sistemas

• Programador

• Ingeniero de pruebas de Sistema

• Integrador de Sistema

• Ingeniero de soporte y cambios

•Ingeniero de pruebas o tester


33/59

Definición de

Requerimientos


y del Sistema

Implementación y

Prueba de unidades


Operación y

Mantenimiento


MODELO EN CASCADA




software


34/59

• Este modelo refleja un desarrollo marcado por la sucesión escalonada de lasetapas que lo componen : Análisis de requerimientos, diseño, codificación,pruebas e implementación

• Es necesario terminar por completo cada fase para pasar a la siguiente

• Al aplicarlo en situaciones reales su rigidez genera problemas, porque muchasveces resulta difícil poder disponer de requisitos completos o del diseñopormenorizado del sistema en las fases iniciales, creando una barrera que impide

avanzar

MODELO EN CASCADA

M C


35/59

MODELO EN CASCADADESVENTAJAS

Los proyectos reales raras veces siguen el desarrollosecuencial que propone el modelo en cascada.

Los cambios pueden causar confusión cuando el equipo dedesarrollo comienza a trabajar.

A menudo es difícil que el cliente exponga explícitamentetodos los requisitos. El modelo en cascada así lo requiere ytiene dificultades a la hora de acomodar la incertidumbrenatural al comienzo de muchos proyectos.

El cliente debe tener paciencia. Una versión de trabajo del

(los) programa(s) no estará disponible hasta que el proyectoesté muy avanzado. Un grave error puede ser desastroso sino se detecta hasta que se revisa el programa.

MO O C SC


36/59

MODELO EN CASCADAVENTAJAS

Produce sistemas bien documentados susceptibles decambios fundamentalmente por la separación del diseño yla implementación.

Funciona bien para proyectos pequeños donde los

requisitos están bien entendidos.

Es un modelo en el que todo el trabajo está bien organizadoy no se mezclan las fases. Es simple y fácil de usar.

Es el modelo de proceso más antiguo y utilizado para el

desarrollo de aplicaciones de software

MODELO EN CASCADA


37/59

El modelo en cascada se utiliza preferentemente cuando:

Las necesidades del cliente y los requerimientos delsistema se comprenden y están completamente definidos

y conocidos de antemano.Es poco probable el pedido de cambio en los

requerimientos.

El equipo de trabajo no tiene experiencia en el desarrollode sistemas.

El sistema requiere documentación detallada de cadauna de las fases.

MODELO EN CASCADA¿CUÁNDO ES CONVENIENTE UTILIZARLO?


38/59


Modelo en Espiral



39/59

Esbozo

del sistema

Versión

Inicial del sistema

Versión

Final del sistema

Versiones

Intermedias del

sistema

Especificación

Desarrollo

Validación

Actividades Concurrentes

MODELO EVOLUTIVO



40/59

Las actividades de especificación, desarrollo y validación sonconcurrentes.

No existe una especificación detallada del sistema y ladocumentación se minimiza.

El sistema se desarrolla en una serie de incrementos oversiones añadiendo funcionalidad a las anteriores.

Las versiones se muestran a los clientes y otros stakeholderspara que ellos las evalúen y propongan cambios y secontinúa así hasta agotar el tiempo, el presupuesto o hasta

que el cliente esté satisfecho.

MODELO EVOLUTIVO


41/59

Prototipos del sistema

• Prototipo exploratorio

– El objetivo es trabajar con clientes hasta evolucionar a un sistema final,a partir de una especificación inicial. Se debe comenzar con unas

especificaciones bien entendidas.

• Prototipo desechable o “throw-away”.

– El objetivo es entender los requerimientos del sistema. Se puede

comenzar con especificaciones poco entendidas resolviendo las

incertidumbres

MODELO EVOLUTIVO

MODELO EVOLUTIVO


42/59

Continua revisión por parte del clienteLos clientes pueden validar las versiones del sistema y deesta forma, dado que se inicia el trabajo con un esbozo delsistema, los posibles fallos conceptuales u otros posiblesmotivos de disconformidad por parte del cliente pueden

ser detectados antes de que se impliquen cambios en elsistema.

Permite cambios de requerimientosPermite la modificación de requerimientos sobre lamarcha, y una mayor implicación por parte del cliente en

las pruebas y validación de requerimientos

MODELO EVOLUTIVOVENTAJAS

MODELO EVOLUTIVO


43/59

Desde la perspectiva de ingeniería y gestión, elmodelo evolutivo tiene las siguientes desventajas:

El proceso no es visible

Los administradores tienen que hacer entregas regulares para medirel progreso. Si los sistemas se desarrollan rápidamente, no es rentableproducir documentos que reflejen cada versión del sistema.

A menudo los sistemas tienen una estructura

deficienteOrigina un software que puede estar débilmente estructurado y difícilde comprender y mantener.

Los cambios continuos tienden a corromper la estructura delsoftware. Incorporar cambios en él se convierte cada vez más en unatarea difícil y costosa.

MODELO EVOLUTIVODESVENTAJAS

MODELO EVOLUTIVO


44/59

MODELO EVOLUTIVO¿CUÁNDO ES CONVENIENTE UTILIZARLO?

El modelo evolutivo se utiliza preferentementecuando:

Se desarrollan sistemas pequeños y tamaño

medio (hasta 500.000 líneas de código). Es necesario resolver incertidumbres en laespecificación del sistema.

No se recomienda para sistemas grandes,

complejos y con período de vida largo dondediferentes equipos desarrollan distintas partes delsistema. Es difícil establecer una arquitecturaestable del sistema


45/59



Modelo en Espiral


46/59

EL Modelo Espiral, propuesto en 1988 por Barry Boehm.

El modelo reconoce la naturaleza iterativa del desarrollo y combinaactividades de desarrollo con gestión de riesgo, para minimizar y controlarel riesgo.

El modelo divide el desarrollo en cuatro regiones o sectores:1- determinar objetivos, alternativas y restricciones

2- evaluar alternativas, identificar y resolver los riesgos

3- desarrollar, verificar el producto del siguiente nivel

4- planificar las siguientes fases.

Cada una de las regiones están compuestas por un conjunto de tareas lascuales se adaptan a las características del proyecto que va a emprenderse.

Ejemplo de tareas: Análisis de sistemas, Diseño de Sistemas, Construcciónde programas, Pruebas, Mantenimiento.

MODELO EN ESPIRAL

M


47/59

MODELO EN ESPIRAL

1- Determinar

objetivos.

alternativos y

restricciones

2- Evaluar

alternativas,

identificar y

resolver riesgos

4- Planificar la

siguiente fase

3- Desarrollar y

verificar

MODELO EN ESPIRAL


48/59

Cada ciclo o iteración en la espiral representa una fase del proceso de desarrollo del software.

El ciclo más interno, 1° iteración, podría referirse a un estudiode la viabilidad del sistema, es decir que incluye por ejemplo:

el presupuesto: la viabilidad económica del proyecto un cronograma inicial de desarrollo con un Diagrama de

Gantt

restricciones tecnológicas [Hardware y Software]

alternativas para el personal

MODELO EN ESPIRAL¿Q UÉ SE REALIZA EN LA 1° ITERACIÓN?


49/59

MODELO EN ESPIRAL


50/59

MODELO EN ESPIRAL

1- Determinar

objetivos.

alternativos y

restricciones

2- Evaluar

alternativas,

identificar y

resolver riesgos

4- Planificar la

siguiente fase

3- Desarrollar y

verificar

Concepto

Análisis de Riesgos

Plan1° iteración o ciclo [ Estudiode viabilidad ]

Prototipos

Concepto de las

operaciones

Inicio

Fin

MODELO EN ESPIRAL


51/59

En cada iteración o ciclo de la espiral se hace un análisis deriesgo de las alternativas según los requisitos y restricciones.

Se construyen prototipos para analizar las alternativas yseleccionar una.

Los prototipos pueden ser simples maquetas en papel,prototipos de interfaz de usuario o simulaciones del sistema,dependiendo del riesgo a evaluar, según el ciclo en el procesoy del tipo de aplicación.

Cada vez que se pasa por la región de planificación de ajusta elcosto y el calendario del proyecto.

MODELO EN ESPIRALACCIONES COMUNES A TODAS LAS ITERACIONES

MODELO EN ESPIRAL


52/59

En la segunda iteración, una vez que se han evaluado losriesgos y se decide continuar con el proyecto, se planificadefinición de los requerimientos que se realizará en lasiguiente fase del proceso [es la cuarta región de la espiral].

A partir del documento “Concepto de las operaciones”, en lasegunda iteración se realiza el proceso de definición de losrequerimientos del sistema.

Los requerimientos del sistema son validados por el cliente

con los prototipos que evolucionan desde la 2° región.

Luego se escribe un documento denominado Especificaciónde Requerimientos del Sistema.

MODELO EN ESPIRAL¿Q UÉ SE REALIZA EN CADA ITERACIÓN?

MODELO EN ESPIRAL


53/59

MODELO EN ESPIRAL

1- Determinar

objetivos.

alternativos y

restricciones

2- Evaluar

alternativas,

identificar y

resolver riesgos

4- Planificar la

siguiente fase

3- Desarrollar y

verificar

ConceptoPlan

de RQ Requerimientos

Prototipos


2° iteración [ Definición derequerimientos ]

Validación de

Requerimientos

Especificación deRequerimientos del Sistema

Inicio

Fin

MODELO EN ESPIRAL


54/59

En la tercera iteración se hace un plan de desarrollo, y seproduce el Diseño del Sistema que es verificado y validado.

El la cuarta iteración se hace un plan de integración y prueba,se genera el software y se realizan las pruebas de aceptación.

Se realiza la entrega y la puesta en servicio del sistema.

MODELO EN ESPIRAL¿Q UÉ SE REALIZA EN CADA ITERACIÓN?

MODELO EN ESPIRAL


55/59

MODELO EN ESPIRAL

1- Determinar

objetivos.

alternativos y

restricciones

2- Evaluar

alternativas,

identificar y

resolver riesgos

4- Planificar la

siguiente fase

3- Desarrollar y

verificar Diseño detallado

Concepto

Requerimientos

Diseño del producto

Prototipos

Plan


Plan de

Desarrollo

Plan de integración

y pruebas

Planificar siguiente fase

MODELO EN ESPIRAL


56/59

MODELO EN ESPIRAL

1- Determinar

objetivos.

alternativos y

restricciones

2- Evaluar

alternativas,

identificar y

resolver riesgos

4- Planificar la

siguiente fase

3- Desarrollar y

verificar

MODELO EN ESPIRAL


57/59

MODELO EN ESPIRAL


MODELO EN ESPIRAL


58/59

Es un enfoque realista del desarrollo de Sistemas y de Software a granescala.

Utiliza la construcción de prototipos como mecanismo de reducción deriesgos.

La construcción de prototipos facilita la validación de los requerimientos alentregar versiones del sistema desde el final de la primera iteración.

El riesgo de sufrir retrasos en el proyecto es menor porque los problemasse identifican en etapas tempranas y hay tiempo para subsanarlos.

El análisis del riesgo se hace de forma explícita y clara.

Utiliza el enfoque sistemático del modelo en cascada y el trabajo iterativodel modelo evolutivo, lo cual refleja de forma más realista la construccióndel software.

MODELO EN ESPIRALVENTAJAS

AHORA UDS VERIFIQUEN SI SE CUMPLIERON LOS


59/59

A HORA UDS. VERIFIQUEN SI SE CUMPLIERON LOSOBJETIVOS PROPUESTOS

Unidad 2 CicloDeVida ModelosDeProcesos

Documents

Transcript of Unidad 2 CicloDeVida ModelosDeProcesos