B1. G2. Tema 1. Concepto del ciclo de vida y fases.

Modelo en Cascada y modelo en espiral del ciclo de vida

Introduccin
El objetivo de este tema es dar una visin del ciclo de vida del software y los diferentes modelos

que se han propuesto para representarlo. Para entender las especiales caractersticas del software y su ingeniera (que son el objeto del ciclo de vida) comenzamos repasando la evolucin que a lo largo de la historia ha sufrido el software y su produccin (seccin 2.2.1). Las especiales caractersticas del software en comparacin con el hardware se tratan en la seccin 2.2.2. De aqu se concluye que el software debe tener uno atributos bsicos que garanticen que est bien desarrollado (seccin 2.2.3), describiendose en la seccin 2.2.4 los problemas que se producen en el proceso de desarrollo del software. Finalmente se propone la aplicacin del concepto de ingeniera del software como camino para solucionar los problemas del software (seccin 2.2.5). Para modelar el proceso de la ingeniera del software se utiliza el concepto del ciclo de vida (seccin 2.2.6) . El modelo del ciclo de vida clsico o modelo en cascada se describe en el apartado 3.1 El punto siguiente agrupa la descripcin de tres alternativas al ciclo de vida clsico: Construccin de Prototipos, Aproximacin Evolutiva y Aproximacin Incremental. De las cuales es la construccin de prototipos la ms estudiada y extendida. Estas tres aproximaciones tienen en comn la rapidez con la que se dispone dentro del proceso de desarrollo de un primer sistema (o prototipo). Antes de abordar el modelo del ciclo de vida en espiral y en el apartado de gestin del Ciclo de Vida se aborda la cuestin de como se pueden gestionar y controlar los desarrollos de software. En este sentidos los modelos orientados a la produccin de documento, como el modelo en cascada, son lo que resultan fciles de controlar. No obstante los problemas que presentan los modelos tradicionales hacen que aparezca el modelo en espiral (apartado 3.3) que trata de combinar lo mejor del modelo en cascada y de prototipos introduciendo el anlisis de riesgo como elemento nuevo. Por ltimo se describen dos nuevos modelos que surgen de la aplicacin de las herramientas de lenguajes de cuarta generacin y herramientas Case al proceso de desarrollo.

2 2.1

Concepto del Ciclo de vida y fases La Ingeniera del Software

En la actualidad la clave del xito de los sistemas informticos ya no est en el hardware sino en

el software. En cualquier campo de aplicacin es el software el que marca la diferencia. Durante las tres primeras dcadas de las informtica, el principal desafo era el desarrollo de hardware de las computadoras, de modo que se redujera el coste de procesamiento y almacenamiento de datos. Los avances en microelectrnica que se produjeron a lo largo de la dcada de los ochenta y hasta ahora han conseguido que la potencia de clculo aumente muchisimo a la vez que se reducan tremendamente los costes. Es por esto que hoy en da el desafo sea mejorar la calidad as como reducir los costes del desarrollo de software. 2.1.1 La evolucin del software La forma en que se ha desarrollado el software est muy ligada a la evolucin que desde su aparicin han sufrido los sistemas informticos. Estos sistemas se han ido sofisticando debido al aumento del rendimiento del hardware, a la reduccin de su tamao y a la disminucin del coste. Se ha evolucionado desde los procesadores con vlvulas de vaco a los dispositivos microelectrnicos capaces de procesar 200 millones de instrucciones por segundo. La figura 1 muestra la divisin en etapas en la evolucin del software propuesta por Roger S. Pressman [PRESS 93] y descrita a continuacin.
Los primeros aos : . Orintacin por lotes . Distribucin limitada . Software a medida La segunda era : . Multiusuario . Tiempo real . Bases de datos . Software como producto La tercera era : . Sistemas distribuidos . Incorpracin de "inteligencia" . Hardware de bajo coste . Impacto en el consumo La cuarta era . Potentes sistemas de sobremesa . Tecnologas orientadas a objetos . Sistemas expertos . Computacin paralela

1950

1960

1970

1980

1990

2000

Figura 1 - Evolucin del software

En los primeros aos de la informtica (1950-1965) el hardware sufri continuos cambios mientras que el software se consideraba como algo adicional. El desarrollo de software se realizaba prcticamente sin ninguna planificacin y no existan mtodos sistemticos. Durante estos aos en la mayora de los sistemas se utilizaba programas en batch. De esta manera en general el hardware se dedicaba a la ejecucin de un solo programa que a su vez se dedicaba a una aplicacin especfica. En estos aos el hardware sola ser de propsito general y el software se diseaba a medida para cada aplicacin y tena una distribucin relativamente pequea. La mayora del software era desarrollado 2

y utilizado por la misma persona u organizacin . La misma persona lo escriba, lo ejecutaba y si fallaba lo depuraba. El hecho de que la movilidad laboral fuera baja garantizaba que la misma persona estara all si se produca un error. En ste entorno el diseo era un proceso implcito y la documentacin normalmente inexistente. La segunda poca en la evolucin de los sistemas de computadoras se extiende desde la mitad de la dcada de los 60 hasta finales de los setenta. La aparicin de la multiprogramacin y de los sistemas multiusuario hacen que se utilicen nuevos conceptos de interaccin hombre-mquina. Surge un nuevo tipo de aplicaciones al poderse aplicar tcnicas interactivas. Aparecen tambin los primeros sistemas en tiempo real que pueden controlar procesos tomando datos de diferentes fuentes, analizandolos y transformandolos y produciendo salidas en milisegundos. Adems aparece la primera generacin de sistemas gestores de bases de datos. Es en est poca cuando aparece el concepto de software como producto que se desarrolla para tener una distribucin amplia en el mercado. Con el crecimiento del nmero de sistemas informticos aumenta el volumen de software desarrollado para ellos. Las casas de software producan programas de decenas de miles de sentencias fuente y los productos software comprados introducan cientos de miles de sentencias. Todos estos programas deban ser corregidos cuando se detectaban fallos, modificados cuando cambiaban los requisitos del usuario y adaptado cuando se introduca nuevo hardware. Todo esto que se llam mantenimiento del software resultaba muy costoso sino imposible debido a la naturaleza personalizada de muchos programas. Es el principio de la Crisis del Software. La tercera era comienza a mediados de los setenta y llega hasta mediados de los ochenta. Aparecen los sistemas distribuidos que incrementaron considerablemente la complejidad de los sistemas informticos. Las redes de rea local y de rea global, las comunicaciones digitales de gran ancho de banda y la creciente demanda de acceso rpido a los datos supusieron una fuerte presin sobre los desarrolladores de software. Esta era tambin se caracteriza por la llegada y amplio uso de los microprocesadores y ordenadores personales. El microprocesador forma parte integral de muchos productos de diversas caractersticas. En muchos casos la tecnologa software es integrada en estos por personas que conocen el hardware pero no tienen experiencia en desarrollo software. Los ordenadores personales fueron el catalizador del crecimiento de muchas compaas de software ya que mientras que en la segunda era stas vendan cientos o miles de copias, en la tercera era vendan decenas e incluso centenares de miles. El hardware de estos ordenadores personales se convirti en un producto estndar pasando a ser el software el que marcaba la diferencia. En la cuarta era que se extiende hasta ahora las tecnologas orientadas a objetos han desplazado a otras tcnicas de desarrollo software en muchas reas de aplicacin. Las tcnicas de cuarta generacin tambin cambiaron la forma en que se desarroll el software. Durante esta era los problemas relacionados con el desarrollo de software se han intensificado: La complejidad que ha alcanzado el software dificulta la creacin de software que explote toda su potencialidad. 3

Resulta difcil cubrir la gran demanda de nuevos programes La posibilidad de mantener los programas se ve amenazada por el mal diseo y el uso de recursos inadecuados. En los primeros tiempos de la informtica el coste mayor de los proyectos informticos

corresponda al hardware por lo que se utilizaban tcnicas de gestin orientadas al hardware con el fin de reducir los costes de ste. Para ello aplicaban los controles, mtodos y herramientas que corresponden a la ingeniera de hardware o de sistemas. En estos tiempos el software era un arte y solo saban de su forma y desarrollo los propios programadores. Hoy han cambiado las cosas siendo normalmente el software el elemento principal del coste y siguen existiendo problemas que se presentaron en las pasada dcadas como: excesivo tiempo en terminar programas, coste elevado, se entrega software con errores, es difcil controlar el proceso de desarrollo. Con el fin de paliar estos problemas se ha adoptado la ingeniera del software como prctica para el desarrollo del software.

2.1.2 Caractersticas del software Resulta importante, para estudiar como se debe producir, entender las especiales caractersticas del software. Mientras que el proceso de construccin de hardware tiene como resultado un producto final fsico el software es un elemento dl sistema que es lgico por lo que tiene unas caractersticas distintas al hardware: El software no se fabrica en un sentido clsico sino que se desarrolla. Aunque existen similitudes entre el desarrollo de software y la construccin de hardware, ambas actividades son muy diferentes. En ambas la buena calidad se adquiere mediante un buen diseo pero la construccin de hardware es muy diferente del software ya que se puede introducir problemas de calidad que no existen (o son fcilmente corregibles) en el software, En ambos casos se construye un producto pero con mtodos muy diferentes. Los costes del software estn en la ingeniera por lo que no se pueden gestionar como proyectos de fabricacin El software no se estropea: mientras que el hardware se deteriora con el paso del tiempo, con el uso y la relacin con el entorno el software no sufre es susceptible a los malos entorno que hacen que el hardware se estropee. Los errores no detectados del software har que este falle al principio de su vida. Sin embargo una vez que se corrigen todos, suponiendo que no se introducen nuevos errores desaparecen los fallos y no aparecer nuevos. Pero esto no es la realidad ya que el software sufre a lo largo de su vida modificaciones y es probable que al introducir estos cambios se introduzcan nuevos defectos. Si antes de que se corrijan estos 4

errores se vuelven a introducir cambios aumenta el nmero de fallos y as lentamente los fallos comienzan a crecer por lo que se puede decir que el software se va deteriorando. La mayora del software se construye a medida, en vez de ensamblar componentes existentes. A diferencia del hardware no existen catlogos de componentes para el software y el desarrollador tiene que construir programas a medida. En este sentido hace tiempo que se habla de reusabilidad del software y ya se esta aplicando en algunos mbitos. 2.1.3 Calidad del software El objetivo de la ingeniera del software no es producir productos sino producir productos de una manera efectiva desde el punto de vista de costes. Probablemente si se contase con recursos ilimitados se podran resolver la mayora de los problemas del software pero lo que se debe conseguir es producir software de alta calidad y en el tiempo estimado. Para asegurar la calidad de los productos software debemos identificar los atributos que deben presentar estos productos. Si asumimos que el software cumple con la funcionalidad requerida, entonces para que sea de calidad deber tener las siguientes caractersticas: El software debe ser mantenible. Dado que el software est sujeto a cambios debera estar escrito y documentado de manera que las modificaciones se puedan hacer sin gastos innecesarios El software debe ser fiable. Debe comportarse como esperan los usuarios y no debe fallar ms de lo permitido por la especificacin. El software debe ser eficiente. Sin que esto tenga que llevarse al ltimo extremo ya que el afn por maximizar la eficiencia puede hacer el software ms difcil de cambiar. Debe ofrece una interfaz de usuario apropiado. A menudo no se utilizan todas las posibilidades del software porque la interfaz hace esto difcil. Se deben tener en cuenta los costes al definir software. El que sea mantenible es un atributo principal ya que la mayor parte del coste asociado con un producto software se produce despus de su puesta en funcionamiento. Optimizar todos los atributos es difcil e incluso algunas veces se excluyen entre s. 2.1.4 Los problemas del desarrollo del software Algunos de los problemas que afectan al desarrollo del software son los siguientes : La planificacin y estimacin de los costes son con frecuencia muy imprecisa La productividad no se corresponde con la demanda La calidad del software no llega a ser a veces ni aceptable Frecuentemente se produce insatisfaccin del cliente con el sistema terminado El software puede ser muy difcil de mantener

2.1.5 Definicin de Ingeniera del Software 5

El concepto de Ingeniera del Software surge de la necesidad de sistematizar la produccin de software afectada por la llamada crisis del software y trata de aplicar principios de ingeniera al desarrollo del software para obtener software de calidad. La ingeniera del software parte de la ingeniera de sistemas y comprende tres elementos claves: mtodos, herramientas y procedimientos. Los mtodos de ingeniera del software proporcionan tcnicas para la realizacin del software. Abarcan un amplio espectro de tareas que incluyen: planificacin y estimacin de proyectos, anlisis de los requisitos del sistema y del software, diseo de estructuras de datos, arquitectura de programas y procedimientos algortmicos, codificacin, prueba y mantenimiento. Para dar soporte a estos mtodos aparecen la herramientas que tratan de automatizar en la medida de lo posible la aplicacin de las tcnicas que los mtodos contemplan. Aqu se enmarcan las herramientas CASE (Computer Aided Software Engineering) de ayuda al desarrollo de software. Los procedimientos marcan la secuencia y modo de utilizacin conjunta de mtodos y herramientas estableciendo entregas requeridas, controles para asegurar la calidad y coordinar los cambios y las directrices que ayudan a los gestores del software a evaluar el progreso.

2.1.6 Concepto de ciclo de vida del software La ingeniera del software intenta est compuesta por una serie de fases en las que se utilizan los mtodos, herramientas y procedimientos antes mencionados. El conjunto de estas fases compone El ciclo de vida del software que se define como el perodo de tiempo que comienza con la decisin de desarrollar un producto software y finaliza con la entrega de ste. Este ciclo incluye, en general, una fase de requisitos, fase de diseo, fase de implantacin, fase de prueba y a veces, fase de instalacin y aceptacin. El ciclo de desarrollo software se utiliza para estructurar en fases las actividades que se llevan a cabo en el desarrollo de un producto software estableciendo una serie de hitos claramente identificables entre el principio y el final del proyecto. En general los hitos identificados en un proyecto de desarrollo software se corresponden en el tiempo con los momentos en que se entregan ciertos documentos: Al finalizar la fase de anlisis de requerimientos hay una especificacin de requerimientos Al finalizar la fase de diseo hay una especificacin tcnica del sistema Al finalizar la implantacin hay un conjunto de programas Cuando las pruebas se han terminado se produce un informe de las pruebas. El modelo del ciclo de vida ms clsico es el paradigma del ciclo de vida en cascada a partir del cual han surgido nuevos modelos. A pesar de que no se llegue a un acuerdo acerca su uso y forma siguen siendo tiles para la comprensin y el control del proceso de desarrollo. En los apartados siguientes se describirn los diferentes modelos del ciclo de vida. 6

3 3.1

Modelo en cascada y modelo en espiral del ciclo de vida El modelo de ciclo de vida en cascada
El primer modelo del ciclo de vida, derivado de otras ingenieras, fue el Modelo en cascada

llamado as porque su filosofa es completar un paso antes de comenzar con el siguiente.

Anlisis del sistema Anlisis Diseo Codificacin Prueba Mantenimiento

Figura 2 - Ciclo de vida en cascada

En la literatura sobre este tema se encuentran diferentes formas del modelo que suponen en general variaciones en el nmero de fases y en el nombre de estas pero mantienen la misma filosofa Aqu hemos tomado la descripcin de Roger S. Pressman en su libro de Ingeniera del Software [PRESS93] que incluye dos fases distintas para el anlisis: Anlisis del sistema total y Anlisis de los requisitos del software. La figura 2 muestra este modelo que est tomado del ciclo convencional de una ingeniera y exige un enfoque sistemtico y secuencial del desarrollo del software comenzando por el nivel del sistema y continuando con el anlisis, diseo, codificacin, prueba y mantenimiento. Contempla las siguientes actividades: Anlisis del Sistema El trabajo comienza estableciendo los requisitos del sistema completo del que el software es un componente para asignar despus un subconjunto de estos al software. Es muy importante este planteamiento de sistema ya que en general el software interacciona con otros elementos del sistema global como hardware, personas y bases de datos. Por tanto, como resultado de esta fase se obtendr una definicin de los requisitos a nivel del sistema. Anlisis de los requisitos del software: 7

En esta fase el proceso de recopilacin de requisitos se centra especialmente en el software. En este sentido se debe comprende el mbito de informacin del software, as como la funcin, el rendimiento y las interfaces requeridos. Los requisitos se deben documentar y revisar con los usuarios del sistema y deben estar definidos por ello de manera que puedan ser entendidos tanto por los usuarios como por el equipo de desarrollo. Diseo : El diseo del software se compondr en realidad de varios pasos que cubren la definicin de cuatro atributos distintos de los programas: v v v v Estructura de los datos Arquitectura del software Detalle procedimental Caracterizacin de la interfaz.

En esta fase se deben traducir los requisitos a una representacin del software que permita garantizar la calidad requerida antes de que empiece la codificacin. Se debe producir una documentacin de diseo que formar parte de la configuracin del software. Codificacin : En este paso se traduce el diseo en una forma legible para la mquina. Si el diseo se realiz de forma detallada la codificacin se podr hacer mecnicamente. Prueba Cuando ya se ha generado el cdigo se debe probar el programa. Realizando dos tipos de prueba: Prueba de la lgica interna del software: asegurando que se han probado todas las sentencias. Prueba de las funciones externas: garantizando que para determinadas entradas se obtienen los resultados esperados. Mantenimiento Una vez terminado y entregado el software sufrir cambios por alguno de los siguientes motivos: Correccin de errores: durante el funcionamiento se detectan errores que deben ser subsanados. Adaptacin a cambios de entorno: al modificarse el entorno en el que el programa funciona se debe modificar ste. Nuevos requerimientos: el cliente solicita nueva funcionalidad o rendimiento. El mantenimiento del software seguir todos los pasos descritos aplicandose a un programa ya existente en lugar de a uno nuevo. La fase de prueba del ciclo de vida donde se prueba el sistema integrado completo supone el 8

ltimo paso de validacin del proceso de desarrollo. En este momento se debe demostrar al usuario de que el sistema cumple sus requerimientos. Pero es importante que la verificacin y validacin formen parte de cada una de las fases anteriores del ciclo de vida. Como consecuencia de estas en una fase se puede producir realimentacin a fases previa del ciclo de vida. Aunque validacin y verificacin puedan parecer sinnimos suponen diferentes comprobaciones. La verificacin comprueba que el producto que se est construyendo cumpla los requerimientos. La validacin comprueba que las funciones del producto son las que el usuario realmente desea. Tambin es importante tener en cuenta que aunque sea til para la gestin de los proyectos considerar las fases del ciclo de vida como independientes, sta no es la situacin que se da en la realidad ya que en la prctica las fases se solapan y se realimentan. Durante el diseo se identifican problemas con los requerimientos; durante la codificacin aparecen problemas de diseo etc. El proceso de produccin del software no es simplemente un modelo lineal sino que supone una serie de iteraciones de las actividades de desarrollo. El problema es que resulta difcil definir puntos de control definitivos para un modelo que incluya iteraciones muy frecuentes. Por ello la tendencia es despus de un nmero pequeo de iteraciones dar por terminadas partes del desarrollo como la especificacin de requisitos y continuar con las siguientes fases. Este ciclo de vida clsico, es el paradigma ms antiguo y ms ampliamente usado en ingeniera del software sin embargo durante su aplicacin se presentan algunos problemas como los siguientes: Los proyectos reales, como ya se ha dicho, no se ajustan al modelo secuencial sino que se producen iteraciones que hacen difcil la aplicacin del paradigma. La mayora de los problemas provienen de la dificultad de definir al principio todos los No se puede disponer de unas especificaciones correctas desde el principio porque Se pueden producir cambios de pareceres de los usuarios respecto a las necesidades requisitos del sistema: resulta difcil para el usuario establecer en este momento todos los requisitos. reales del sistema durante el desarrollo del proyecto de forma que los verdaderos requisitos no se reflejen en el producto final. Otro de los problemas proviene de que los resultados no se ven hasta muy avanzado el error puede suponer unas proyecto por lo que la realizacin de un cambio debido a un

implicaciones muy importantes en el plazo de entrega y coste de desarrollo. A pesar de los problemas presentados el modelo clsico del ciclo de vida es muy considerado y relevante dentro de los estudios de ingeniera del software. Proporciona un buen marco de referencia para la asignacin de todas las actividades del desarrollo y sigue siendo la aproximacin ms empleada por los ingenieros del software.

3.2

Otros modelos
Muchas veces el usuario define una serie de requisitos generales para el sistema pero no puede

3.2.1 Construccin de prototipos

identificar los requisitos detallados de entrada, proceso o salida. En otros casos el programado no estar seguro de la eficacia de un determinado algoritmo o de la forma en que debe realizarse la interaccin hombre-mquina. En estos y otros muchos casos puede ser mejor aproximacin la creacin de prototipos. Esta aproximacin incorpora a la fase de definicin de requisitos los siguientes factores: Alto grado de iteracin Muy alto grado de participacin del usuario Uso extensivo de los prototipos. Para ello parte de las siguientes premisas: Los prototipos constituyen un medio mejor de comunicacin que los modelos en papel La iteracin es necesaria para canalizar en la direccin correcta el inevitable proceso de aprendizaje. Los prototipos que se utilizan en esta aproximacin son modelos del software a construir que tomar una de las siguientes formas: Modelo que describa la interaccin hombre-mquina de modo que facilite al usuario la comprensin de dicha interaccin Programa que implemente un subconjunto de la funcionalidad requerida para el sistema final. Programa existente que ejecute toda o parte de la funcionalidad deseada pero que deba ser mejorada en el proyecto de desarrollo. Como ya se ha dicho la premisa bsica para realizar el anlisis con ayuda de prototipos es que a los usuarios les resulte difcil especificar los requisitos del sistema sin tener una primera experiencia de l. La utilizacin de un prototipo lleva a un mayor conocimiento del problema, tanto por parte de los usuarios como de los analistas de sistemas y adems soporta el proceso de aprendizaje que los usuarios deben tener. En este proceso el prototipo es modificado de manera iterativas hasta que los requisitos deseados por el usuario queden claros. Como consecuencia de la iteracin surgen nuevos requisitos y se puede verificar que se han entendido correctamente el usuario y el analista. En esta aproximacin el usuario debe ser un participante activo, evaluando prototipos, proponiendo mejoras y detallando a la vez los requisitos deseados del sistema de informacin. En la aproximacin tradicional el usuario tiene un papel ms pasivo, la iniciativa la suele tener el analista porque el usuario tiene un conocimiento limitado del lenguaje en el que se especifican los requisitos del sistema. 10

En la fase de anlisis realizada mediante aproximacin de prototipo se distinguen cinco pasos como se muestra en la siguiente figura 3

Figura

In v e s tig a c i n P re lim in a r B re v e a n lis is y E s p e c ific a c i n

Construccin de prototipos

En el primer paso, Breve anlisis y

D e fin ic i n d e re q u is ito s d e l s is te m a

D is e o y R e a liz a c i n

E v a lu a c i n D is e o t c n ic o

M o d ific a c i n P ro g ra m a c i n y p ru e b a T e rm in a c i n O p e ra c i n y m a n te n im ie n to

especificacin, se analiza el problema en trminos globales con el objetivo de proveer una base para las siguientes fases. En la fase de Diseo y realizacin se construye un prototipo. En el tercer paso Evaluacin los usuarios finales manejan y evalan el prototipo. Si es necesario cambiar algn requisito esto se har en la fase de Modificacin. En estas dos fase se producir un procedimiento iterativo en el que el prototipo es afinado para que satisfaga las necesidades del usuario al mismo tiempo que proporciona al que desarrolla una mejor comprensin de lo que hay que hacer En el ltimo paso Terminacin se completa la fase de definicin de requisitos del sistema aadiendo los requisitos de funcionamiento y calidad. Idealmente el prototipo sirve como mecanismo para identificar los requisitos, para su creacin de podrn utilizar fragmentos de programas que funcionen o bien herramientas que faciliten algn tipo de prototipado rpido (generadores de informes, gestores de ventanas, etc.) Por ltimo debemos sealar que este modelo tambin presenta ciertos problemas como los que se indican a continuacin: Si el cliente no es consciente de que no se est trabajando con un sistema real cuando este cumpla la funcionalidad requerida y el analista le comunique que se debe reconstruir el sistema no lo entender y pretender que se modifique el prototipo para que se convierta en el producto final. Si esto se hace el producto desarrollado adolecer de considerables deficiencias al no haberse tenido en cuenta en su desarrollo consideraciones sobre calidad y mantenimiento del software. Durante el desarrollo de prototipos se pueden adquirir ciertos compromisos de implementacin 11

con el fin de obtener un prototipo que funcione rpidamente. Despus de algn tiempo el tcnico puede haberse familiarizado con esas elecciones y haber olvidado las razones por las que eran inapropiadas. La eleccin menos ideal forma ahora parte integral del sistema. Aunque puedan presentarse ciertos problemas esta aproximacin de construccin de prototipo resulta efectiva siempre que se fijen desde el principio las reglas del juego. Esto es, el prototipo se considere solamente como un mecanismo de definicin de requisitos. Posteriormente debe ser descartado (al menos en parte) y debe construirse el software real teniendo en cuenta criterios de calidad y mantenimiento.

3.2.2 Aproximacin evolutiva En este modelo el nfasis est en lograr un sistema flexible y que se pueda expandir de manera que se pueda realizar rpidamente un nuevo sistema cuando cambien los requisitos. Se trata de una situacin semejante a la que se da cuando se crea un nuevo prototipo para ajustarse a los cambios de requisitos. La diferencia esencial entre la aproximacin de prototipo y la evolutiva estriba en que en la primera se asume que existen una serie de requisitos reales y que para establecer lo que realmente el usuario quiere, puede ser necesario realizar varias iteraciones, pero al final los requisitos se estabilizarn, mientras que en el segundo se asume que los requisitos cambian continuamente. Tal consideracin no se realiza en el anlisis con prototipos puesto que no se acabara nunca el proceso iterativo y no se podra construir el sistema real.

3.2.3 Aproximacin Incremental El desarrollo incremental es un concepto parecido a la aproximacin evolutiva que frecuentemente aparece englobado dentro de ste. En esta aproximacin la funcionalidad del sistema se le entrega al cliente en pequeos incrementos. Se comienza desarrollando el sistema que satisfaga un subconjunto de los requisitos especificados. Sucesivamente se irn creando versiones que incorporen los requisitos que faltan siendo las ltimas las que cumplirn todos ellos. Para cada una de las versiones se aplicar la aproximacin de fase del modelo en cascada. Con esta aproximacin se pretende disponer pronto de un sistema que aunque sea incompleto sea utilizable y satisfaga alguna de las necesidades de informacin. As adems se evita el llamado efecto Big Bang, esto es durante un periodo de tiempo largo no se tiene nada y de repente hay una situacin completamente nueva. Con esta aproximacin incremental el usuario est estrechamente implicado en la planificacin de los pasos siguientes. 12

Esta aproximacin se puede utilizar tambin para evitar la demanda de funcionalidades excesivas al sistema. Como a los usuarios les resulta difcil definir sus necesidades reales tienden a pedir demasiado. Al carecer del conocimiento necesario de la maleabilidad del software y su proceso de desarrollo, pueden creer que todo es posible y como consecuencia de ellos las caractersticas esenciales del sistema aparecen mezcladas con detalles innecesarios. los analistas no pueden distinguir unos de otros por lo que se corre el riesgo de emplear un esfuerzo considerable en implantar funcionalidades que realmente no eran necesarias, Con la aproximacin incremental se fija la atencin primero en las caractersticas esenciales y las posibles funcionalidades adicionales solo se incluyen cuando es necesaria. Las sucesivas versiones de un sistema desarrollado con la aproximacin evolutiva y la incremental difieren claramente. En el primer caso, cada vez se desarrolla una nueva versin de todo el sistema; mientras que en el segundo cada versin parte de una versin previa sin cambios, ms un nmero de nuevas funciones. Es posible desarrollar un sistema incrementalmente y al mismo tiempo seguir una aproximacin evolutiva para desarrollar componentes particulares del sistema.

3.3

Gestin del Ciclo de vida

Hasta ahora se han presentado varios modelos del ciclo de vida que en muchos casos no han sido

muy usados debido a las dificultades que presentaban para la gestin y control de l os desarrollos. La gestin de los proyectos es muy importante en el desarrollo profesional de software y no se puede utilizar un modelo de ciclo de vida cuyo resultado sea un proceso incontrolable. Debido a la naturaleza intangible del software la posibilidad de realizar una gestin efectiva de los procesos de desarrollo se tendr que basar en la adopcin de un modelo que haga visibles estos procesos mediante documentos, informe o revisiones. Por ello se ha adoptado de manera general los modelos orientados a entregas en los que el proceso de desarrollo se divide en etapas y cada etapa se considera terminada cuando el documento resultado de la etapa ha sido producido, revisado y aceptado. Con este modelo la salida de cada fase, el documento resultado, es la entrada de definicin para la siguiente. El modelo en cascada es con mucho el modelo de entregas ms ampliamente utilizado en la siguiente figura se muestra una posible divisin en fases con sus documentos asociados descrita por Ian Sommerville [SOMM92].

Actividad Anlisis de requerimientos

Documentos de Salida Estudio de Viabilidad Requerimientos genricos 13

Definicin de requerimientos Especificacin del sistema Diseo de la arquitectura Diseo de interfaz Codificacin Prueba unitaria Pruebas de modulo Pruebas de integracin Pruebas de sistema Pruebas de aceptacin

Especificacin de requerimientos Especificacin Funcional Especificacin de las pruebas de aceptacin Borrador del manual de usuario Especificacin de diseo de la arquitectura Especificacin de las pruebas del sistema Especificacin de la interfaz Especificacin de las pruebas de integracin Cdigo de programas Informe del resultado de las pruebas unitarias Informe del resultado de las pruebas de mdulos Informe de las pruebas de integracin Manual de usuario final Informe de las pruebas del sistema Sistema final

Figura 4 - Documentos del modelo en cascada

El resto de los modelos descritos no se han usado demasiado por no estar bien adaptados al modelo de procesos basado en documentos. As en la construccin de prototipos no resulta econmico generar documentacin durante las fases iterativas de construccin de prototipo aunque si puede hacerse en las fases ltimas si se utiliza el modelo del ciclo de vida en cascada. Tanto en la aproximacin evolutiva como en la incremental las iteraciones son tan rpidas que la generacin de documentacin resulta muy cara. Los problemas con modelos orientados a documentos son los siguientes: La direccin normalmente necesita que se produzcan documentos en momentos determinados para asegurar el progreso del proyecto pero estos tiempos pueden no coincidir con los tiempos requeridos para terminar una actividad lo que puede llevar a que se produzcan documentos artificiales. La necesidad de aprobar documentos hace que se restrinjan las iteraciones ya que el coste de volver hacia atrs y adaptar un documento es alto. Si se encuentran problemas se adoptan soluciones de compromiso para no tener que modificar los documentos ya entregados. La idea de que un documento producto de una fase debe actuar como definicin de la fase siguiente presenta ciertos inconvenientes ya que supone que el proceso de desarrollo es lineal. En cualquier fase del proyecto los ingenieros de software tienen en cuenta tanto los pasos anteriores como los futuros. No tiene sentido, por ejemplo, definir un diseo de software que luego no se va a poder implementar por mucho que cumpla los requerimientos. Un proceso basado en documentos tiende a ocultar informacin de los desarrolladores ya que supone que solo tienen que trabajar en los documentos y esto puede incrementar el coste del software 14

Se requieren tiempos significativos para revisar y aprobar los documentos y no suele producirse una transicin suave de una fase a otras. En la realidad muy frecuentemente se ignoran los procedimientos formales y se comienza una fase antes de que los documentos de la fase previa estn terminados. Parece claro que se necesita un modelo del ciclo de vida que solvente los problemas de los

modelos basados en documentos y que ane las caractersticas de todos los modelos presentados hasta ahora. En el siguiente apartado se describe el modelo del ciclo de vida en espiral descrito por Boehm (1988) que resulta una buena alternativa.

3.4 El modelo en espiral

El modelo en espiral de la Ingeniera del Software naci para englobar las mejores caractersticas tanto del ciclo de vida clsico como de la creacin de prototipos, aadiendo como nuevo elemento el anlisis de riesgo.
Figura 5
Planificacin Recolecin de requisitos y planificacin del proyecto inicial. Planificacin basada en los comentarios del cliente Anlisis de riesgo Anlisis de reiesgo basado en los requisistos iniciales Anlisis de riesgo basado en la reaccin del cliente

- Ciclo de vida en espiral

El modelo representado por la figura anterior (Figura actividades principales representadas por los cuatro 5)

Decisin de seguir o no Hacia el sistema final Prototipo inicial del software

define cuatro

Evaluacin del cliente

Prototipo del siguiente nivel Sistema de ingeniera

Evaluacin del cliente

Ingeniera

cuadrantes de la figura: v Planificacin : determinacin de objetivos, alternativas y restricciones v Anlisis de riesgo: anlisis de alternativas e identificacin y resolucin de riesgos v Ingeniera : Desarrollo del producto del siguiente nivel v Evaluacin del cliente: Valoracin de los resultados de la ingeniera. 15

Cada iteracin alrededor de la espiral que comienza en el centro y sigue hacia el exterior produce nuevas versiones del software, cada vez ms completas. En la primera vuelta se definen los objetivos, las alternativas y las restricciones y se analizan los riesgos. Si del anlisis de los riesgos se concluye que hay incertidumbre en los requisitos se puede utilizar la creacin de prototipos dentro de la actividad de ingeniera para ayudar tanto al encargado de desarrollo como al usuario en la definicin del problema y en la clarificacin de los requisitos. Aunque es un concepto difcil de definir se pude pensar en riesgo como la posibilidad de que algo vaya mal. Por ejemplo si se pretende utilizar un nuevo lenguaje de programacin un riesgo sera que no hubiese ningn compilador disponible adecuado. Los riesgos son consecuencia de una informacin inadecuada y se solventan realizando acciones para conseguir la informacin que resuelva las incertidumbres. En la fase inicial del proyecto es importante identificar el tipo de incertidumbre que existe. La incertidumbre concierne tanto a aspectos conceptuales como externos del sistema. La incertidumbre conceptual puede causar serios problemas puesto que provocar una falta de claridad en las funciones del sistema y en la estructura de la base de datos. En cambio, la incertidumbre en la forma del sistema tendr consecuencias financieras menos importantes aunque afectar bastante a la satisfaccin del usuario. A continuacin se describen algunos factores que influyen en el grado de incertidumbre conceptual: Si los requisitos se deducen a partir de las tareas que se tienen que soportar se podrn obtener a partir del anlisis de dichas tarea. En este caso existe poco riesgo de incertidumbre. Cuando ni los usuarios ni los analistas tienen un entendimiento suficiente del problema, el anlisis mediante prototipos es la aproximacin ms vlida. Sin embargo, cuando al menos una de las partes tiene conocimiento suficiente del problema y de los requisitos del sistemas que se tiene que desarrollar no es necesario utilizar modelos para soportar un proceso de aprendizaje. En tales caso los prototipos pueden jugar un papel importante como medio de comunicacin Cuando los usuarios y los analistas necesitan comunicarse mucho puede haber una incertidumbre provocada no por la ausencia de entendimiento del problema sino por una pobre capacidad de comunicar ese entendimiento. El riesgo de problemas de comunicacin es alto cuando: rea 16 Los usuarios no tienen experiencia en el lenguaje de anlisis empleado Los usuarios tienen una actitud negativa hacia el lenguaje de anlisis empleado por Los usuarios no son capaces de emplear el lenguaje que asume una capacidad de A los analistas les falta experiencia en el rea de aplicacin y el lenguaje de ese

los analistas de sistemas. abstraccin

El mayor riesgo de incertidumbre conceptual se da por tanto cuando despus de la fase de anlisis no se han obtenido los requisitos del sistema, y ni los usuarios ni los analistas tienen conocimiento en el rea del sistema y hay una alta probabilidad de tener problemas de comunicacin. En tales circunstancias, la aproximacin mediante prototipos conducir a a ahorros importantes. Adems de reducir los costos de mantenimiento por reducir la incertidumbre tambin se reducir el tiempo empleado en la fase de pruebas funcional y por consiguiente esta fase ser ms econmica. Del mismo modo habr ahorros en las fases de diseo, realizacin y mantenimiento. Al final de esta primera vuelta alrededor de la espiral el cliente evala el trabajo de ingeniera (cuadrante de evaluacin del cliente) y sugiere modificaciones. Las siguientes fases de planificacin y anlisis de riesgo se basarn en las sugerencias y comentarios del cliente. En cada bucle alrededor de la espiral se termina el anlisis de riesgo con la decisin de seguir o no seguir. Si los riesgos fuesen muy grandes se podra dar por terminado el proyecto. Normalmente se sigue avanzando alrededor del camino de la espiral que lleva a un modelo ms completo del sistema y al final al propio sistema terminado. Cada vuelta alrededor de la espiral requiere ingeniera (cuadrante de ingeniera) que se puede llevar a cabo mediante el enfoque del ciclo de vida clsico o mediante la creacin de prototipos. Es importante tener en cuenta que las actividades de desarrollo que se llevan a cabo dentro de este cuadrante aumentan a medida que nos alejamos del centro de la espiral. El paradigma del modelo en espiral para la ingeniera del software es actualmente el enfoque ms realista para el desarrollo del software y de sistemas a gran escala: Utiliza un enfoque evolutivo que permite al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel evolutivo. Utiliza la creacin de prototipos como un mecanismo de reduccin de riesgo pero adems permite al analista utilizar el enfoque de creacin de prototipos en cualquier etapa de la creacin del producto. Mantiene el enfoque sistemtico de fases del ciclo de vida clsico pero incorporndolo Demanda una consideracin directa de riesgos tcnicos en todas las etapas del proyecto y, dentro de un marco de trabajo interactivo que refleja mejor el mundo real. si se aplica adecuadamente, debe reducir los riesgos antes de que se conviertan en problemticos. Pero tambin como el resto de los modelos presenta ciertos problemas : Puede ser difcil convencer a grandes clientes de que el enfoque evolutivo es confortable Requiere una considerable habilidad para la valoracin del riesgo y cuenta con ella para el xito. Si no se descubre un riego importante surgirn problemas. Por ltimo el modelo es bastante nuevo por lo que no esta tan probado como el modelo en cascada o la construccin de prototipos.

17

3.5

Modelos basados en la utilizacin de herramientas

En este apartado se detalla una aproximacin [PRESS93] que aprovecha las caractersticas de las

3.5.1 Tcnicas de cuarta generacin

herramientas de cuarta generacin para el desarrollo de software. El trmino tcnicas de cuarta generacin engloba a un amplio espectro de herramientas de software que tienen en comn el facilitar la especificacin de algunas caractersticas del software a alto nivel a partir de la cual generar n el cdigo fuente. El paradigma de tcnicas de cuarta generacin para la ingeniera del software se orienta hacia la posibilidad de especificar el software a un nivel ms prximo al lenguaje natural o en una notacin que proporcione funciones significativas. Un entorno que soporte esta aproximacin debe incluir todas o algunas de las siguientes herramientas: v lenguajes no procedimentales para consultas a bases de datos v v v v v limitados. La figura 6 ilustra este paradigma. Igual que el resto de las aproximaciones comienza con la fase de definicin de requisitos. En un caso ideal los requisitos descritos por el usuario seran directamente traducidos a un prototipo operativo. Sin embargo en ala prctica esto no es as ya que el usuario puede no estar seguro de lo que necesita, puede ser ambiguo en la especificacin de hechos que le son conocidos, y le puede resultar difcil o no desear expresar sus necesidades en la forma en que una herramienta de cuarta generacin la necesita. Por todo ello en este momento sigue siendo muy importante el dilogo entre el usuario y el analista generadores de informes herramientas de manipulacin de datos generadores de pantallas generadores de cdigo facilidades grficas de alto nivel

Todas estas herramientas estn disponibles pero en general orientados a mbitos de aplicacin

Reccolecin de requisitos Estrategia de "diseo" Implementacin en L4G Prueba

Figura Tcnicas generacin de

cuarta

Slo definicin

en de

aplicaciones requisitos al

muy de

pequeas se podr ir del paso de implementacin usando un lenguaje

18

de cuarta generacin no procedimental. En general el uso de tcnicas de cuarta generacin sin diseo para proyectos grandes causar las mismas dificultades que cuando se desarrolla software mediante los enfoques convencionales. El uso de lenguajes de cuarta generacin para el desarrollo permite que la atencin se centre en la representacin de los resultados deseados que se traducen automticamente en el cdigo fuente que produce esos resultados. Para que una implementacin con tcnicas de cuarta generacin se convierta en un producto se deben realizar pruebas completas as como producir una documentacin adecuada. Adems se debe contemplar que el software as desarrollado sea fcilmente mantenible.

3.5.2 Aproximacin basada en transformaciones La utilizacin de herramientas CASE (Computer Aided Software Enginnering), entre las que se podran incluir las mencionadas en el apartado anterior modifican de alguna manera el modelo del ciclo de vida convencional. Esto hace que se plantee un nuevo modelo que Carma Mc Clure ha llamado ciclo de vida basado en transformaciones [CARM92]. (Figura 7)

ESPECIFICACIN
TRANSFORMACIN

DISEO LGICO
TRANSFORMACIN

DISEO FSICO
TRANSFORMACIN

CDIGO Figura 7 - Ciclo de vida del software basado en transformaciones

La utilizacin de herramientas CASE afecta a todas las fases del ciclo de vida del software. Este ciclo de vida se puede considerar como una serie de transformaciones. Primero se definen los requisitos del sistema. Entonces se produce un proceso de transformacin que convierte la especificacin en un diseo lgico del sistema. Posteriormente este diseo lgico se transforma para ajustarse a la tecnologa de destino para llegar al diseo fsico. Las tecnologas CASE tratan de conseguir que estas transformaciones se produzcan en la medida de lo posible de forma automtica. Las ventajas que se introducen son las siguientes: 19

v diseo. v

Posibilidad de comprobacin de errores en etapas iniciales del desarrollo. Este tipo de

herramientas permite realizar anlisis de completitud y de consistencia de los requisitos y del Posibilidad de realizar el mantenimiento en la especificacin. Con los generadores de mantener los programas mediante la modificacin de objetos de nivel de

cdigo es posible v

abstraccin de diseo e incluso de anlisis. Soporte de rastreabilidad de requisitos. Dado que los productos de cada una de las fases se obtienen por transformacin de los de fase previas se hace ms fcil comprobar que en cada una de ellas se han observado los requisitos y estn implantados. v Soporte de reusabilidad. La filosofa del ciclo de vida como una serie de transformaciones automticas de modelos potencia la reusabilidad de objetos de desarrollo como diseo o parte de diseos, parte de especificaciones etc. v Potencia la especificacin orientada al problema. Cuando no se utilizan este tipo de herramientas que generan cdigo se tiende a orientar los requisitos a la mquina o al lenguaje utilizados.

20

BIBLIOGRAFIA [AMES95] Antonio de Amescua Seco, Luis Garca Sanchez, Paloma Martinez Fernandez, Paloma Daz Perez Ingeniera del Software de Gestin. Paraninfo 1995 [CARM92] Carma McClure Case la automatizacin del Software. Rama 1992 [MORR93] D.Morris y B.Tamm Concise Encyclopedia of Software Engineering Pergamon Press 1993 [PRESS93] R.S. Pressman Ingeniera del Software. Un enfoque prctico Mc Graw Hill. 1993 [SOMM92] Ian Sommerville Software Engineering Addison-WesleY 1992 [VLIET93] Hans van Vliet Software Engineering. Principles and Practice John Wiley& Sons 1993

21