Introduccin.

Hoy en da los sistemas informticos se caracterizan por la rpida evolucin de

los componentes hardware, que incrementan continuamente sus prestaciones junto
con una fuerte tendencia a la estandarizacin y una gran diversidad de marcas y
modelos con prestaciones y precios similares. Es por todo ello, que las prestaciones
de los grandes ordenadores de aos anteriores hoy en da estn disponibles en un
ordenador personal. El software es el mecanismo que nos permite utilizar y explotar
ese potencial.

el desarrollo del software no es nada fcil, haciendo necesario en muchas

ocasiones proyectos con decenas de miles de lneas de cdigos. No se
puede programar sin ms, es necesario analizar lo que tenemos que hacer,
cmo lo vamos a hacer y cmo se van a coordinar las distintas personas que
intervienen en el proyecto para llegar a obtener los resultados inicialmente
esperados.

EL CICLO DE VIDA DEL SOFTWARE.

Por ciclo de vida del software, entendemos la sucesin de etapas por las que
pasa el software desde que un nuevo proyecto es concebido hasta que se deja de
usar. Estas etapas representan el ciclo de actividades involucradas en el desarrollo,
uso y mantenimiento de sistemas de software, adems de llevar asociadas una
serie de documentos que sern la salida de cada una de estas fases y servirn de
entrada en la fase siguiente.
Estas actividades son:

Adopcin e identificacin del sistema: es importante conocer el origen

del sistema, as como las motivaciones que impulsaron el desarrollo del
sistema (por qu, para qu, etc.).

Anlisis de requerimientos: identificacin de las necesidades del cliente y

los usuarios que el sistema debe satisfacer.

Especificacin: los requerimientos se realizan en un lenguaje ms formal,

de manera que se pueda encontrar la funcin de correspondencia entre las
entradas del sistema y las salidas que se supone que genera. Al estar
completamente especificado el sistema, se pueden hacer estimaciones
cuantitativas del coste, tiempos de diseo y asignacin de personal al
sistema, as como la planificacin general del proyecto.

Especificacin de la arquitectura: define las interfaces de interconexin y

recursos entre mdulos del sistema de manera apropiada para su diseo
detallado y administracin.

Diseo: en esta etapa, se divide el sistema en partes manejables que, como

anteriormente hemos dicho se llaman mdulos, y se analizan los elementos
que las constituyen. Esto permite afrontar proyectos de muy alta
complejidad.

Desarrollo e implementacin: codificacin y depuracin de la etapa de

diseo en implementaciones de cdigo fuente operacional.

Integracin y prueba del software: ensamble de los componentes de

acuerdo a la arquitectura establecida y evaluacin del comportamiento de
todo el sistema atendiendo a su funcionalidad y eficacia.

Documentacin: generacin de documentos necesarios para el uso y

mantenimiento.

Entrenamiento y uso: instrucciones y guas para los usuarios detallando

las posibilidades y limitaciones del sistema, para su uso efectivo.

Mantenimiento del software: actividades para el mantenimiento

operativo del sistema. Se clasifican en: evolucin, conservacin y
mantenimiento propiamente dicho.

***Modelos.
Clasificacin.
Modelos descriptivos vs. Modelos prescriptivos.
Un modelo de ciclo de vida del software es una caracterizacin -descriptiva o
prescriptiva- de la evolucin del software.
Los modelos prescriptivos dictan pautas de cmo deberan desarrollarse los
sistemas de software; por lo tanto son ms fciles de articular ya que los detalles
del desarrollo pueden ser ignorados, generalizados, etc. Esto puede dejar dudas
acerca de la validez y robustez de este tipo de modelos.
Otra forma de encarar el desarrollo de un modelo es la forma descriptiva, la
cual se basa en la observacin del desarrollo de sistemas reales. Son ms difciles
de articular debido a dos razones fundamentales:

La captura de datos es un proceso que puede tomar aos.

Los modelos descriptivos son especficos a los sistemas observados y

solamente generalizables a travs de anlisis sistemticos.

.Modelos tradicionales vs. Modelos evolutivos

Los modelos tradicionales focalizan su atencin en la direccin del cambio en
trminos de progreso a travs de una serie de etapas que eventualmente conducen
a alguna etapa final.
Aunque este tipo de modelos son a menudo intuitivos y muy tiles para el
establecimiento de marcos de trabajo, administracin y seleccin de herramientas
para el desarrollo de software, presentan serios problemas:

Fallan para proveer un mecanismo adecuado que permita gobernar los

cambios en el desarrollo del software.

Plantea una organizacin muy poco realista que implica una secuencia
uniforme y ordenada de actividades de desarrollo.

La rigidez que este tipo de modelos impone a los procesos de desarrollo

impide que el producto pueda adaptarse dinmicamente para satisfacer los
requerimientos siempre cambiantes. Esto restringe la creatividad y la
productividad.

Son pobres predictores de por qu ciertos cambios son hechos a un sistema,

y por qu los sistemas evolucionan de maneras similares o diferentes.

Como una solucin a estos problemas surgieron nuevas propuestas que

pueden agruparse bajo el nombre de modelos evolutivos. Los modelos evolutivos
presentan las siguientes caractersticas:

Existen tres orientaciones: centrados en el producto, centrados en los

procesos y centrados en la administracin y organizacin del proceso.

Focalizan la atencin en los mecanismos y procesos que cambian sistemas.

Estn caracterizados por el diseo, desarrollo y despliegue de una capacidad

inicial usando tecnologa actual que incluye previsin para la adicin
evolutiva de futuras capacidades a medida que se definen nuevos
requerimientos y que las tecnologas maduran.

Estn menos interesados en la etapa de desarrollo que en los mecanismos

tecnolgicos y procesos organizacionales que posibilitan el surgimiento de sistemas
a travs del tiempo y del espacio.

Modelos de Ciclo de Vida del software.

4.2.1. Modelo Cascada.
El modelo cascada (waterfall), propuesto por Royce en 1970, fue derivado de
modelos de actividades de ingeniera con el fin de establecer algo de orden en el
desarrollo de grandes productos de software.

Descripcin del modelo

El modelo cascada es un modelo de ingeniera diseado para ser aplicado en el
desarrollo de software. La idea principal es la siguiente: existen diferentes etapas de
desarrollo, la salida de la primera etapa fluye hacia la segunda etapa y esta salida
fluye hacia la tercera y as sucesivamente.

Problemas con el Modelo Cascada

El ciclo de vida clsico es el paradigma ms viejo y el ms ampliamente usado
en la ingeniera del software. Sin embargo, su aplicabilidad en muchos campos ha
sido cuestionada. Entre los problemas que aparecen cuando se aplica el modelo
cascada estn:

Los proyectos raramente siguen el flujo secuencial que el modelo propone.

La iteracin siempre es necesaria y est presente, creando problemas en la
aplicacin del modelo.

A menudo es difcil para el cliente poder especificar todos los requerimientos

explcitamente. El modelo de vida del software clsico requiere esto y
presenta problemas acomodando la incertidumbre natural que existe al
principio de cualquier proyecto.

El cliente debe ser paciente. Una versin funcional del sistema no estar
disponible hasta tarde en la duracin del desarrollo. Cualquier error o
malentendido, si no es detectado hasta que el programa funcionando es
revisado, puede ser desastroso.

Prototipado.
El modelo de prototipos permite que todo el sistema, o algunos de sus
partes, se construyan rpidamente para comprender con facilidad y aclarar
ciertos aspectos en los que se aseguren que el desarrollador, el usuario, el
cliente estn de acuerdo en lo que se necesita as como tambin la solucin
que se propone para dicha necesidad y de esta forma minimizar el riesgo y
la incertidumbre en el desarrollo, este modelo se encarga del desarrollo de
diseos para que estos sean analizados y prescindir de ellos a medida que
se adhieran nuevas especificaciones, es ideal para medir el alcance del
producto, pero no se asegura su uso real.
Segn esto un prototipo puede tener alguna de las tres formas siguientes:

un prototipo, en papel o ejecutable en ordenador, que describa la interaccin

hombre-mquina y los listados del sistema.

un prototipo que implemente algn(os) subconjunto(s) de la funcin

requerida, y que sirva para evaluar el rendimiento de un algoritmo o las
necesidades de capacidad de almacenamiento y velocidad de clculo del
sistema final.

un programa que realice en todo o en parte la funcin deseada pero que

tenga caractersticas (rendimiento, consideracin de casos particulares, etc.)
que deban ser mejoradas durante el desarrollo del proyecto.

Ventajas del Modelo de Prototipo.

Este modelo es til cuando el cliente conoce los objetivos generales para el software,
pero no identifica los requisitos detallados de entrada, procesamiento o salida. Tambin
ofrece un mejor enfoque cuando el responsable del desarrollo del software est inseguro
de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma
que
debera
tomar
la
interaccin
humano-mquina.

Desventajas del Modelo de Prototipo.

Su principal desventaja es que una vez que el cliente ha dado su aprobacin final al
prototipo y cree que est a punto de recibir el proyecto final, se encuentra con que es
necesario reescribir buena parte del prototipo para hacerlo funcional, porque lo ms
seguro es que el desarrollador haya hecho compromisos de implementacin para hacer
que el prototipo funcione rpidamente. Es posible que el prototipo sea muy lento, muy
grande, no muy amigable en su uso, o incluso, que est escrito en un lenguaje de
programacin inadecuado.

Espiral.

El problema con los modelos de procesos de software es que no se enfrentan lo

suficiente con la incertidumbre inherente a los procesos de software. Importantes
proyectos de software fallaron porque los riegos del proyecto se despreciaron y
nadie se prepar para algn imprevisto. Boehm reconoci esto y trat de incorporar
el factor riesgo del proyecto al modelo de ciclo de vida, agregndoselo a las
mejores caractersticas de los modelos Cascada y Prototipado. El resultado fue el
Modelo Espiral. La direccin del nuevo modelo fue incorporar los puntos fuertes y
evitar las dificultades de otros modelos desplazando el nfasis de administracin
hacia la evaluacin y resolucin del riesgo. De esta manera se permite tanto a los
desarrolladores como a los clientes detener el proceso cuando se lo considere
conveniente.

Descripcin del modelo

Bsicamente, la idea es desarrollo incremental usando el modelo Cascada para
cada paso, ayudando a administrar los riesgos. No se define en detalle el sistema
completo al principio; los diseadores deberan definir e implementar solamente los
rasgos de mayor prioridad. Con el conocimiento adquirido, podran entonces volver
atrs y definir e implementar ms caractersticas en trozos ms pequeos.
El modelo Espiral define cuatro actividades principales en su ciclo de vida:

Planeamiento: determinacin de los objetivos, alternativas y limitaciones del

proyecto.

Anlisis de riesgo: anlisis de alternativas e identificacin y solucin de

riesgos.

Ingeniera: desarrollo y testeo del producto.

Evaluacin del cliente: tasacin de los resultados de la ingeniera.

Puntos fuertes

Evita las dificultades de los modelos existentes a travs de un acercamiento

conducido por el riesgo.

Intenta eliminar errores en las fases tempranas.

Es el mismo modelo para el desarrollo y el mantenimiento.

Provee mecanismos para la aseguracin de la calidad del software.

La reevaluacin despus de cada fase permite cambios en las percepciones

de los usuarios, avances tecnolgicos o perspectivas financieras.

La focalizacin en los objetivos y limitaciones ayuda a asegurar la calidad.

Puntos dbiles

Falta un proceso de gua explcito para determinar objetivos, limitaciones y

alternativas.

Provee ms flexibilidad que la conveniente para la mayora de las

aplicaciones.

La pericia de tasacin del riesgo no es una tarea fcil. El autor declara que
es necesaria mucha experiencia en proyectos de software para realizar esta
tarea exitosamente.

Cleanroom
Cleanroom es un proceso de administracin e ingeniera para el desarrollo de
software de alta calidad con fiabilidad certificada. Focaliza la atencin en la
prevencin en lugar de la correccin de errores, y la certificacin de la fiabilidad del
software para el entorno de uso para cual fue planeado. En lugar de realizar
pruebas de unidades y mdulos, se especifican formalmente componentes de
software los cuales son verificados matemticamente en cuanto son construidos.

El modelo tiene las siguientes caractersticas:

Desarrollo incremental: el software es particionado en incrementos los cuales

se desarrollan utilizando el proceso cleanroom.

Especificacin formal: el software a desarrollarse es formalmente

especificado.

Verificacin esttica: el software desarrollado es verificado

matemticamente (los desarrolladores no pueden ejecutar el cdigo)
utilizando argumentos de correctitud basados en matemticas. No hay
pruebas a nivel unidad o mdulo.

Pruebas estadsticas: el incremento de software integrado es examinado

estadsticamente para determinar su fiabilidad.

Ventajas del uso de Cleanroom

Cleanroom provee las prcticas de administracin e ingeniera que permiten

a los equipos lograr cero fallos en el campo de uso, cortos ciclos de
desarrollo, y una larga vida del producto.

Reduce los fallos encontrados durante el proceso de certificacin a menos de

cinco fallos por cada mil lneas de cdigo en la primera ejecucin del cdigo
del primer proyecto.

Equipos nuevos deberan experimentar un incremento del doble en la

productividad con respecto a su primer proyecto. La productividad seguir
incrementndose con la experiencia adquirida.

Cleanroom lleva a una inversin en bienes tales como especificaciones

detalladas y modelos que ayudan a mantener un producto viable durante
una vida ms larga.

Todos los beneficios tcnicos se trasladan en beneficios econmicos

significantes.

Comparacin entre los modelos.

La siguiente tabla muestra una comparacin entre los cuatro modelos ms
utilizados:

http://aposta.uv.es/givaro/modulo/Ciclo.htm
http://gestionrrhhusm.blogspot.com/2011/05/modelo-de-prototipo.html
http://www.slideshare.net/yanezcabrera/modelo-de-prototipo

http://gestionrrhhusm.blogspot.com/2011/05/ingenieria-de-software-modelocascada.html