modelos de ciclo de vida

5/10/2018 Modelos de Ciclo de Vida - slidepdf.com

http://slidepdf.com/reader/full/modelos-de-ciclo-de-vida-55a0c6ef3c1b3 1/16

Curso: Ingeniería de la InformaciónModelos de Ciclo de Vida

CICLO DE VIDA DEL SOFTWARE

I. CONCEPTO:

Uno de los problemas más importantes en cualquier

departamento de sistemas de información es definir un marco de

referencias común:

Que pueda ser empleado por todas las personas que

participan en un desarrollo informático.

En el que se definan los procesos, las actividades y las tareas

a desarrollar.

Todo esfuerzo en el desarrollo del software conlleva un “ciclo de

vida” que consiste en realizar todas las actividades comprendidas

entre el momento en el que se inicia la versión de un sistema

como una chispa en la imaginación de alguien y el último aliento

en la máquina del último cliente.

El ciclo de vida abarca, por tanto, toda la vida del sistema,

comenzando por su concepción y finalizando cuando ya no seutiliza.

El modelo de ciclo de vida que se selecciona influye tanto en el

éxito del proyecto como cualquier otra decisión de planificación

que se tome. El modelo de ciclo de vida apropiado puede orientar

sus proyectos y ayudarle a asegurar que cada paso se acerque

más a la consecución del objetivo.

Dependiendo del modelo de ciclo de vida que se seleccione, se

puede aumentar la velocidad de desarrollo, mejorar la calidad, el

control y el seguimiento del proyecto, minimizar gastos y riesgos,

o mejorar las relaciones con los clientes.

La selección ineficaz de un modelo de ciclo de vida puede ser

fuente constante de trabajo repetitivo, innecesario y frustrante. Se

pueden producir los mismos efectos si no se elige un modelo de

ciclo de vida.




A lo largo de la historia se han propuesto diferentes paradigmas o

ciclos de vida para el software: desde el ciclo en cascada, pasando

por el modelo en espiral de Boehm, hasta los más recientes ciclos

de vida orientados a objetos.

II. MODELOS

MODELO EN CASCADA O LINEALES

El predecesor de todos los modelos de ciclo de vida es el modelo

en cascada. Aunque presenta muchos problemas, sirve de basepara otros modelos de ciclo de vida más efectivos.

El número de fases o etapas que se proponen en este ciclo varían,

aunque suelen ser: análisis del requisito del sistema, análisis de

requisitos del Software, diseño preliminar, diseño detallado,

codificación, pruebas, explotación y mantenimiento.

ANÁLISISREQUISITOSSISTEMAS

ANÁLISISREQUISITOSSOFTWARE

DISEÑOPRELIMINAR

DISEÑODETALLADO

CODIFICACIÓNY PRUEBAS

EXPLOTACIÓINY

MANTENIM.




- En un modelo de cascada, proyecto progresa a través de una

secuencia ordenada de pasos partiendo análisis hasta la

explotación y mantenimiento.

- El proyecto realiza una revisión al final de cada etapa para

determinar si está preparada para pasar a la siguiente etapa, por

ejemplo, desde el análisis de requerimientos hacia el diseño de la

arquitectura. Cuando la división determina que el proyecto no está

listo para pasar a la siguiente etapa, permanece en la etapa actual

hasta que esté preparado.

- El modelo en cascada está dirigido por documentos; es decir, los

productos principales del trabajo que se pasan de etapa en etapa

son documentos.

- El modelo se utiliza para ciclos de productos en los que se tiene

una definición estable del producto, y también cuando se está

trabajando con metodologías técnicas conocidas. En estos casos, el

modelo en cascada ayuda a utilizar errores en las primeras etapasdel proyecto a un bajo costo. Proporciona los requerimientos que

los desarrolladores anhelan. Si se está construyendo una versión

de mantenimiento bien definida de un producto existente o

migrando un producto existente a una nueva plataforma, un ciclo

de vida en cascada puede ser una elección correcta para el

desarrollo rápido.

- El modelo en cascada ayuda a minimizar los gastos de

planificación porque permite realizarla sin problemas. No

proporciona resultados tangibles en forma de software hasta el

final del ciclo de vida, pero para alguien familiarizado con el

modelo, la documentación que genera proporciona indicaciones

significativas del progreso a lo largo del ciclo de vida.




- El modelo en cascada funciona bien con proyectos complejos que

se entienden correctamente, debido a que se pueden obtener

beneficios al enfrentarse a la complejidad de forma ordenada.

Funciona correctamente cuando los requerimientos de la calidad

dominan sobre los requerimientos de costo y de planificación. El

modelo evita una fuente común de errores importantes, eliminando

los cambios que se pueden producir a medio camino.

- El modelo en cascada funciona especialmente bien si se dispone de

personal poco inexperto, por que presenta el proyecto con una

escritura que ayuda a minimizar el esfuerzo inútil.

- Las desventajas del modelo en cascada se centran en la dificultad

para especificar claramente los requerimientos al comienzo del

proyecto antes de que realice ningún trabajo de diseño y antes de

escribir ningún código.

Los desarrolladores se quejan de los usuarios que no saben lo que

quieren, pero supongamos que cambian los papeles. Imagíneseintentando explicarle en detalle a un ingeniero de automoción

cómo es su carro. Le explica al ingeniero que necesita un motor ,

una carrocería, ventanillas, volante, pedal de acelerador, pedal de

freno, el freno de emergencia, asientos y demás. Pero, ¿puede

recordar todo lo que el ingeniero de automoción necesitará conocer

para construir el carro?

Suponga que se olvide indicarle que necesita la luz de marcha

atrás. El ingeniero se va y vuelve a los 6 meses con un carro que no

tiene luz de marcha atrás. Le comenta “Oh, cielos, olvide decirle

que el carro necesita luz de marcha atrás,”.

El ingeniero se vuelve loco ¿sabe usted lo que va a costar coger el

carro para conectar la luz de marcha atrás desde la transmisión

hasta la parte posterior del coche?. Tenemos que rediseñar el




cuadro de mando del carro, realizar la conexión para la luz del

freno y añadir otro censor a la transmisión. ¡Este cambio supondrá

semanas, por no decir meses! ¿por qué no me lo comento antes?

Ud. hace una mueca ¡parecía una cosa tan sencilla...

Un error comprensible ¿verdad? Un carro es difícil de explicar para

un aficionado. Una gran cantidad de productos software también

son complicados, y a menudo las personas que se encargan de

especificar el software tampoco son expertos en ordenadores.

Pueden olvidarse cosas que parecen tan sencillas cuando se ve el

producto funcionando. Cuando se utiliza un modelo en cascada,

olvidar algo puede suponer un error costoso. No se percibe este

hecho hasta que se realiza la prueba del sistema, y se comprueba

que uno de los requerimientos no está o es incorrecto.

Por tanto, el principal problema del modelo en cascada es no

permitir flexibilidad en los cambios se tienen que especificar

completamente todos los requerimientos al comienzo del proyecto,lo que puede suponer meses e incluso años antes de tener el

software funcionando esto choca con las necesidades del comercio

moderno, donde el premio a menudo es para los desarrolladores

que puedan implementar la máxima funcionalidad en la últimas

etapas del proyecto.

- Otras desventajas son:

No refleja el proceso “real” de desarrollo de software. Los

proyectos reales raramente siguen este flujo secuencial, puesto

que siempre hay iteraciones. Aunque en este modelo la

iteración está permitida en etapas contiguas, en la vida real

normalmente la iteración abarca más de una etapa. Un caso

típico es la redefinición de los requisitos cuando se está

codificando la aplicación.




Se tarda mucho tiempo en pasar por todo el ciclo, dado que

hasta que no se finalice una fase no se pasa a la siguiente. Así,

se podría dar el caso de no salir nunca de la fase de análisis de

requisitos software.

Acentúa el fracaso de la industria del software con el usuario

final. En este caso, el usuario debe tener paciencia, ya que el

sistema de funcionamiento no estará disponible hasta las fases

finales del proyecto.

Para un proyecto de desarrollo rápido, el modelo en cascada

puede suponer una cantidad excesiva de documentación.

Genera pocos signos visibles de progreso hasta el final. Esto

puede dar la impresión de un desarrollo lento, incluso sin ser

verdad. Los clientes quieren tener la seguridad de que sus

proyectos serán entregados a tiempo.

Algunas personas han criticado el modelo en cascada por no

permitir volver atrás para corregir los errores. Esto no es del todo

cierto. La vuelta atrás es posible, pero difícil. Una visión distinta

del modelo en cascada que puede ofrecer una mejor perspectiva es

el ciclo de vida del salmón.

Se puede nada contra la corriente, pero el esfuerzo puede matarle.

Al final del diseño de la arquitectura, ha participado en la mayoría

de los eventos más importantes que se han realizado en esta etapa.

Se realizó una revisión del diseño y se firmó la copia oficial del

documento de la arquitectura. Si se descubre un fallo en la

arquitectura durante la codificación y prueba, es muy difícil nadar

contra la corriente y rehacer la arquitectura.

En Resumen, los inconvenientes del venerado modelo en

cascada hacen que sea, a menudo, un modelo poco apropiado

para un proyecto de desarrollo rápido.




MODELO INCREMENTAL (LEMMAN, 1984)

El modelo Incremental corrige la necesidad de una secuencia no

lineal de pasos de desarrollo. En este modelo se va creando el

sistema software añadiendo componentes funcionales al sistema

(llamados incrementos). En cada paso sucesivo, se actualiza el

sistema con nuevas funcionalidades o requisitos. El sistema

software ya no se ve como una única entidad monolítica con una

fecha fija de entrega, sino como una integración de resultados

sucesivos obtenidos después de cada interacción.

El modelo incremental constituyó un avance sobre el modelo en

cascada, pero también presenta problemas aunque permite el

cambio continuo de requisitos, aun existe el problema de

determinar si los requisitos, propuestos son válidos. Muchas

veces los errores de los requisitos se detectan tarde y su

corrección resulta tan costosa como en el modelo en cascada.

ANÁLISISREQUISITOSSISTEMAS

ANÁLISISREQUISITOSSOFTWARE

DISEÑOPRELIMINAR

DISEÑO

DETALLADO


EXPLOTACIÓN YMANTENIMIENTO

DISEÑODETALLADO


EXPLOTACIÓN YMANTENIMIENTO




MODELO EN ESPIRAL

Conocido también como “El rollo de canela en rama” ha sido

desarrollado para cubrir las mejores características tanto del ciclo

de vida clásico, como de la creación de prototipos; añadiendo

además un nuevo elemento: el análisis del riesgo, que falta en

esos paradigmas.

Antes de comenzar a hablar de dicho modelo definamos lo que es

riesgo.

En primer lugar, el riesgo concierne a lo que ocurra en el futuro.

El hoy y el ayer ya no nos conciernen realmente, por que ahora ya

estamos recogiendo los frutos de lo que sembramos en el pasado.

La cuestión es si podemos, entonces, modificando nuestras

acciones de este momento, crear una oportunidad para una

situación diferente y más esperanzadora de nuestro mañana. Esto

significa, en segundo lugar, que el riesgo implica un cambio, quepuede venir dado por cambios de opiniones, acciones o lugares...

[En tercer lugar,] el riesgo implica una elección, y la falta de

certeza de que la elección sea la correcta. Así, paradójicamente, el

riesgo, como la muerte o los impuestos, es una de las pocas cosas

inevitables de la vida.

Cuando consideramos el riesgo en el contexto de la ingeniería del

Software, siempre se hacen evidentes las tres consideraciones

conceptuales de Charette. Nos concierne el futuro – ¿cuáles son

los riesgos que pueden hacer que fracase el proyecto software?

Nos conciernen los cambios – ¿cómo afectarán al éxito global y a

los plazos los cambios en los requisitos del cliente, en las

tecnologías del desarrollo, en las computadoras destino y en todas

demás entidades relacionadas con el proyecto? Por último, nos

enfrentamos con elecciones – ¿Qué métodos y herramientas




debemos usar, cuanta gente debe estar involucrada, cuanta

importancia hay que darle a la calidad?

El análisis del riesgo consta en realidad de cuatro actividades

diferentes: identificación del riesgo, proyección del riesgo, cálculo

del riesgo y gestión del riesgo.

El modelo de espiral es un modelo de ciclo de vida orientada a

riesgos que divide un proyecto software en miniproyectos. Cada

miniproyectos. Cada miniproyecto se centra en uno o más riesgos

importantes hasta que todos estén controlados; después de

controlar todos los riesgos más importantes, el modelo en espiral

finaliza del mismo modo que el modelo de ciclo de vida en

cascada.

El modelo, representado mediante la espiral de la figura, define

cuatro actividades principales, representados por los cuatro

cuadrantes de la figura:

1.

Planificación.- Determinación de objetivos, alternativos yrestricciones.

2. Análisis de riesgo.- Análisis de alternativas, identificaciones y

resolución de riesgos.

3. Ingeniería.- Desarrollo del producto del siguiente nivel.

4. Evaluación de Cliente.- valoración de los resultados de la

ingeniería.

Con cada iteración alrededor de la espiral se construyen

sucesivas versiones del software, cada vez más completas.

Durante la primera vuelta alrededor de la espiral se definen los

objetivos, las alternativas, las restricciones y se analizan e

identifican los riesgos. Si el análisis de riesgo indica que hay una

incertidumbre en los requisitos, se puede usar la creación de

prototipos en el cuadrante de ingeniería para dar asistencia tanto




al encargado del desarrollo como al cliente. Se pueden usar

simulaciones y otros modelos para definir más el problema y

refinar los requisitos.

El cliente evalúa el trabajo de ingeniería y sugiere modificaciones.

En base a los comentarios del cliente se produce la siguiente fase

de planificación y análisis de riesgo. En cada bucle alrededor de la

espiral, la culminación del análisis de riesgo resulta en una

decisión de “seguir o no seguir”. Si los riesgos son demasiados

grandes, se puede dar por terminado el proyecto.

Sin embargo, en la mayoría de los casos, se sigue avanzando

alrededor del camino de la espiral, y ese camino lleva los

desarrolladores hacia un modelo más completo del sistema y al

final al propio sistema operacional.

Una de las ventajas más importantes del modelo en espiral es que

mientras los costes suben, los riesgos disminuyen. Cuanto más

tiempo y dinero emplee, menores serán los riesgos, que es

exactamente lo que se quiere en un proyecto de desarrollo rápido.

El modelo en espiral proporciona al menos tanto control de

gestión como el modelo en cascada tradicional. Se tienen los

puntos de verificación al final de cada iteración. Como el modelo

esta orientado a riesgos, le proporciona con anterioridad

indicaciones de cualquier riesgo insuperable. Descubrirá si el

proyecto no se puede realizar por razones técnicas u otrasrazones, y esto no supondrá un costo excesivo.

La única desventaja en el modelo en espiral es que se trata de un

modelo complicado. Requiere de una gestión concienzuda, atenta

y que exige conocimientos profundos. Puede ser difícil definir

hitos objetivos de comprobación que indiquen si está preparado

para pasar al siguiente nivel de la espiral. En algunos casos, el

desarrollo del producto es suficientemente lineal, y los riesgos del




proyecto son tan pocos que no se necesitan la flexibilidad y la

gestión de riesgos que ofrece el modelo en espiral.

ANÁLISIS DE RIESGOPLANIFICACIÓN

Análisis de riesgo basado en

requisitos iniciales

Análisis de riesgobasado en la

reacción del cliente

Decisión deSeguir o no

Prototipoinicial

Prototipo del

siguiente nivel

Recolección derequisitos yplanificación delproyecto iniciales

PlanificaciónBasada en loscomentarios

del cliente

Evaluación

del cliente

ENTREGAR

EVALUACIÓN DEL CLIENTE

INGENIERIA




MODELO PARA EL DESARROLLO DE SISTEMAS

ORIENTADOS AL OBJETO:

1. MODELO DE AGRUPAMIENTO: (Cluster)

Este modelo es definido por Meyer (1990), los cuales

consideran que la cultura implícita en los modelos usuales del

ciclo de vida está basada en el “proyecto”, mientras que el

desarrollo orientado al objeto esta basada en el “producto”, el

cual es entendido como elemento software reutilizables y cuyo

beneficio económico aparece a largo plazo.

Meyer propone este modelo, en el que se tiene en cuenta esta

nueva fase de generalización que aparece combinada con la

fase de validación.

Agrupamiento: conjunto de clases relacionadas con un objetivo

común. Ejm. Un agrupamiento gráfico.

En el modelo Cluster se crean diferentes subciclos de vida que

se pueden solapar en el tiempo, cada uno incluye una fase de

especificación, otra de diseño y realización, y por último, una

de validación y generalización.

Modelo de agrupamiento (cluster)

Agrupamiento nEspecificación

Diseño o

realización

Validación

Generaliz.

EspecificaciónDiseño o

realización

Validación

Generaliz.

EspecificaciónDiseño o

realización

Validación

Generaliz.

Tiempo

T

Agrupamiento 2

Agrupamiento 1




MODELO FUENTE

Representa gráficamente el alto grado de iteración y solapamiento

que hace posible la tecnología de objetos.

En el modelo fuente la base esta en el análisis de requisitos, a

partir del cual va creciendo el ciclo de vida, donde cada burbuja,

corresponde a una fase, cayendo solo para el mantenimiento

necesario, de allí el nombre de fuente, la piscina sería el

repositorio de clases.

Los autores además, proponen un modelo de ciclo de vida paracada clase o modulo, ya que cada una puede estar en fase

diferente del ciclo de vida durante el desarrollo de un sistema.

Mantenim. Evolución

Utilización

Pruebas

sistemas

Pruebas

unitarias

Codificac.

Componen.

Diseño

conceptua

Análisis

Estudio de viabilidad

y requisitos

Piscina sw




MODELO REMOLINO

El modelo cascada asume solo una dimensión de iteración

consistente en la fase del proceso, pero se pueden identificar otras

dimensiones:

Amplitud o tamaño del desarrollo (por ejemplo, número de

elementos).

Profundidad, referida a nivel de abstracción o detalle.

Madurez, entendida como el grado de compleción, corrección y

“elegancia”.

Alternativas, diferentes soluciones a un problema.

Alcance, en cuanto a objetivos del sistema, ya que los

requisitos van cambiando a lo largo del proyecto.

Las diferentes dimensiones se pueden anidar de muchas

maneras, por ejemplo, fase – madurez – amplitud. Este proceso

“fractal” (más que lineal), consistente en un desarrollo“multicíclico”, tiene la forma de un remolino en lugar de una

cáscada, de ahí su nombre.

MODELO PINBALL

Un modelo muy curioso y didáctico a la hora de explicar el

desarrollo orientado al objeto el”pinball 6 ”. refleja realmente la

forma en la que se desarrolla software. En este modelo la pelota

representa un proyecto completo o un subproyecto y el jugador es

el equipo de desarrollo.

Se produce de forma iterativa a encontrar clases, atributos,

métodos e interrelaciones (actividades que se pueden englobar en

la fase de análisis) y definir colaboraciones, herencia, agregación y

subsistemas (que se incluyen en el diseño). Por último se pasa a




la programación, prueba e implementación. Realmente, como en

el “pinball”, los pasos se pueden tomar en cualquier orden y de

forma simultánea.

Ambler también destaca dos estilos a la “hora de jugar”:

“A lo seguro”. Con tecnologías y métodos probados.

“Al límite”, con mayor riesgo, pero también más ventajas. A

veces, ésta es la única manera de conseguir beneficios

espectaculares.

El autor destaca que, al igual que en el juego del “pinball”, lahabilidad es el factor más importante (junto con la experiencia),

pero además se requiere algo de suerte.

MODELO POR PLANIFICACIÓN

El modelo de ciclo de vida de diseño por planificación es similar al

modelo de ciclo de vida de entrega por etapas, en el que se

planifica desarrollar el producto en etapas sucesivas. La

diferencia radica en que no siempre se conoce al principio si se

tendrá el producto para la última entrega. Se puede tener cinco

etapas planificadas, pero solo se llega a la tercera etapa debido a

que se tiene una fecha límite inamovible.

Este modelo de ciclo de vida puede ser una estrategia válida para

asegurar que se tiene un producto listo a entregar en una fecha

determinada. Si se debe tener absolutamente el software

funcionando a tiempo para una presentación comercial, o para

final del año, o para cualquier otra fecha inamovible, esta

estrategia garantiza que se tendrá algo . resta estrategia es

particularmente útil para las partes del producto que no quieren

realizar en el camino crítico. Por ejemplo, el sistema operativo

Microsoft Windows incluye bastantes complementos destacando




Word Pad, Paint y la red de corazones, Microsoft podría utilizar el

diseño por planificación para evitar que sus complementos

retrazaran Windows en general.

Uno de los elementos de este modelo de ciclo de vida es priorizar

las prestaciones y planificar sus etapas de tal forma que las

primeras contengan las prestaciones de mayor prioridad. Las

prestaciones de baja prioridad se dejan para más tarde. si se llega

a la fecha de entrega antes de finalizar todas las etapas, no es

conveniente dejar sin realizar prestaciones críticas debido a que

se ha gastado tiempo de implementación en otras menos críticas.

El principal inconveniente de esta aproximación es que si no se

completan todas las etapas, se desperdiciará tiempo en la

especificación, arquitectura y diseño de prestaciones que no se

van a entregar. Si se ha gastado tiempo en una gran cantidad de

prestaciones incompletas que no se van a entregar, se debería

tener tiempo para resumir en una o mas prestaciones más

completas.

La decisión para utilizar el modelo de planificación se somete a la

pregunta de cuanta confianza se tiene en la habilidad para la

planificación. Si se tiene mucha confianza para alcanzar los

objetivos de la planificación, esta aproximación es ineficiente. Si

se tiene una menor confianza, esta aproximación podría salvar su

vida.

modelos de ciclo de vida

Documents