Revisin Bibliogrfica de los Modelos de Desarrollo de Software I.

Introduccin La Ingeniera de Software surge como la aplicacin de modelos y formas de la ingeniera tradicional a la prctica de construir productos de software; situacin que ha condicionado su accionar al tener como norte las precisiones y seguridades que en otros mbitos tiene la ingeniera. Histricamente han surgido varios enfoques que buscan abordar de manera sistemtica, la planificacin, anlisis, diseo e implementacin de los proyectos de desarrollo de software, sean estos de gran escala y pequeas aplicaciones, software a la medida o productos de software. Cada uno de estos enfoques tiene su raz en las preconcepciones dominantes en su poca y, sobre todo, en la bsqueda incesante de mejoras a los enfoques precedentes. Debido a que este documento es una resea bibliogrfica, comenzaremos presentando a los autores de los conceptos a desarrollar en este trabajo. Autores de libros consultados: Marck Norris y Peter Rigby Ingeniera de Software Explicada Richard Fairley Ingeniera de Software Autores de pginas Web consultadas: Gustavo A. Donoso M. http://www.inf.udec.cl/~gdonoso/software/isenfoques.html Eduardo Cohen http://fipesmi.misiones.org.ar/users/educohen II. El modelo de codificar y fijar Gustavo Donoso: El modelo bsico usado en los primeros das del desarrollo de software, tiene dos pasos: (1) Escribir algn cdigo. (2) Fijar los problemas en el cdigo. As, el orden de los pasos era fabricar algn cdigo primero y pensar sobre los requerimientos, diseo, prueba y mantencin a continuacin. Este modelo tiene las dificultades de presentar una baja estructuracin del cdigo luego de alguna cantidad de fijaciones, pese a que se puede desarrollar un software de calidad, es 1

posible que ste tenga una correspondencia muy pobre con las reales necesidades del usuario y, finalmente, si no existe la conciencia de la necesidad real de pruebas y modificaciones el costo de las sucesivas fijaciones ser muy alto. Este mtodo resume las caractersticas de los mtodos ms formales desarrollados posteriormente, primero, la desvinculacin con el problema: hay, de partida dos interlocutores, un experto en la programacin o codificacin y, por otro lado, un usuario quien sera el experto en el problema a quien se debe satisfacer mediante la codificacin de la solucin, o programa. Lo anterior nos lleva, tambin, a la idea de iteracin: esta desvinculacin entre el origen del problema y la solucin imprime en los mtodos posteriores la idea de retroalimentaciones que permitan aproximar la distancia entre los mbitos. En el sentido real, el ingeniero de programacin crea modelos de situaciones fsicas en un programa. La correspondencia entre el modelo y la realidad modelada se ha considerado como la distancia entre el problema y la solucin computacional del problema. Un principio fundamental de la ingeniera de programacin es disear productos que minimicen la distancia intelectual entre el problema y la solucin. La variedad de enfoques en el desarrollo de programas est limitado nicamente por la creatividad e ingenio del programador; no siempre se encuentra con claridad el enfoque que minimice esta distancia, e incluso diferentes enfoques minimizan distintas dimensiones de la distancia. Pero, por otro lado, la primera evolucin con relacin a los mtodos es el resultado de las deficiencias presentadas por mtodo de codificar y fijar. Es necesario dividir este ciclo desarrollo en etapas, lo que permitira incorporar la idea de proyecto de desarrollo de software y, sobre todo, elementos de planificacin, coordinacin y control. Esto tambin coincide con el tamao de los problemas a resolver, el que se va incrementando debido, sobre todo, al aumento de las capacidades del hardware. III. El modelo de etapas Gustavo Donoso: En 1956, el enfrentarse a un gran sistema de software como el SemiAutomated Ground Environment (SAGE) hizo que se reconocieran los problemas inherentes a la codificacin y esto llev al desarrollo del modelo de etapas, con el objetivo de poder mejorar estos nuevos problemas. Este modelo estipula que el software ser desarrollado en sucesivas etapas: Plan operativo Etapa donde se define el problema a resolver, las metas del proyecto, las metas de calidad y se identifica cualquier restriccin aplicable al proyecto. Especificacin de requerimientos Permite entregar una visin de alto nivel sobre el proyecto, poniendo nfasis en la descripcin del problema desde el punto de vista de los clientes y desarrolladores. Tambin se considera la posibilidad de una planificacin de los recursos sobre una escala de tiempos. Especificacin funcional Especifica la informacin sobre la cual el software a desarrollar trabajar. Diseo

Permite describir como el sistema va a satisfacer los requerimientos. Esta etapa a menudo tiene diferentes niveles de detalle. Los niveles ms altos de detalle generalmente describen los componentes o mdulos que formarn el software a ser producido. Los niveles ms bajos, describen, con mucho detalle, cada mdulo que contendr el sistema. Implementacin Aqu es donde el software a ser desarrollado se codifica. Dependiendo del tamao del proyecto, la programacin puede ser distribuida entre distintos programadores o grupos de programadores. Cada uno se concentrar en la construccin y prueba de una parte del software, a menudo un subsistema. Las pruebas, en general, tiene por objetivo asegurar que todas las funciones estn correctamente implementadas dentro del sistema. Integracin Es la fase donde todos los subsistemas codificados independientemente se juntan. Cada seccin es enlazada con otra y, entonces, probada. Este proceso se repite hasta que se han agregado todos los mdulos y el sistema se prueba como un todo. Validacin y verificacin Una vez que el sistema ha sido integrado, comienza esta etapa. Es donde es probado para verificar que el sistema es consistente con la definicin de requerimientos y la especificacin funcional. Por otro lado, la verificacin consiste en una serie de actividades que aseguran que el software implementa correctamente una funcin especfica. Al finalizar esta etapa, el sistema ya puede ser instalado en ambiente de explotacin. Mantencin La mantencin ocurre cuando existe algn problema dentro de un sistema existente, e involucrara la correccin de errores que no fueron descubiertos en las fases de prueba, mejoras en la implementacin de las unidades del sistema y cambios para que responda a los nuevos requerimientos. Las mantenciones se puede clasificar en: correctiva, adaptativa, perfectiva y preventiva. El modelo de etapas consideraba que cada una de ellas debera ir a continuacin de la anterior, poniendo nfasis en la documentacin que resulta de cada una y que es la entrada de la siguiente, formalizando los procedimientos de planificacin y de control. Todo tendiente a conformar una cadena de produccin de software, de manera similar a una cadena de montaje de automviles. Pero ello no logra que las causas de fondo que hicieron que se replantease el modelo de codificar y fijar desapareciesen. Todava existe la distancia entre el programador (ahora desarrollador) y el usuario, esta distancia est dada por dominios de accin distintos. La iteracin de aproximacin es ahora ms factible, pero tambin resulta onerosa, es necesario instalar todo el software nuevamente en la cadena de montaje para su revisin y reconstruccin. Figura 1: Modelo de Etapas

Richard Fairley: El modelo de fases divide el ciclo de vida del producto de programacin en una serie de actividades sucesivas; cada fase requiere informacin de entrada, procesos y resultados, todos ellos bien definidos. Se necesitan recursos para terminar los procesos de cada fase, y cada una de ellas se efecta mediante la aplicacin de mtodos explcitos, herramientas y tcnicas. Se considera el modelo de fases compuesto por las siguientes: anlisis, diseo, instrumentacin, pruebas y mantenimiento. Dicho modelo se presenta en la siguiente figura; en ocasiones se denomina de cascada porque los productos pasan de un nivel a otro con suavidad. Figura2: Modelo de fases para el ciclo de vida de desarrollo de productos de programacin El anlisis consta de dos subfases: planeacin y definicin de requisitos. Los productos de la planeacin son la Definicin del Sistema y el Plan del Proyecto. La Definicin, por lo regular, se expresa en espaol o en algn otro lenguaje natural, y puede contener cuadros, figuras, grficas y ecuaciones de distintos estilos. La notacin exacta empleada en la Definicin depende mucho del rea del problema. Obviamente, en un sistema de contabilidad se usa diferente terminologa que en uno de control de procesos. El formato de la Definicin del Sistema se presenta en la figura 3. Figura 3: Formato de la definicin del sistema El Plan del Proyecto contiene el modelo de ciclo de vida que se utilizar, la estructura organizacional del proyecto, la programacin preliminar del desarrollo, estimados preliminares de costos y recursos, as como de personal, herramientas y tcnicas que se emplearn, y estndares que se seguirn Los elementos que se deben incluir en el Plan del Proyecto se listan en la figura 4. 4

Durante la fase de planeacin los estimados de costos y la programacin del trabajo sern preliminares, puesto que usualmente no es posible realizar estimaciones precisas sin haber realizado algo del diseo, los estimados de costos son, por lo tanto, inevitablemente preliminares. Las prcticas actuales de contratacin requieren que el costo total y la programacin se proporcionen durante la fase de planeacin. Esta situacin, unida a la naturaleza competitiva del medio, es una de las principales razones en los excesos en costos y las entregas retrasadas de los productos de programacin. Esta situaci6n, aunada a la naturaleza competitiva del medio, es una las principales razones de los excesos en costos y las entregas retrasadas de los productos de programacin. Reconociendo esta realidad, muchas organizaciones utilizan una serie sucesiva de estimaciones de costos y programacin. Los estimativos preliminares se preparan durante la fase de planeacin, su redefinici6n se presenta en la revisin preliminar del diseo; el costo y la programacin finales se establecen en la revisin final del diseo. Distintas estimaciones, que representan una clase de capacidades, pueden mostrarse en cada una de las revisiones, de esta manera el cliente y el encargado del desarrollo negociarn un producto para que sea eficiente en trminos de costo. Figura 4: Formato del Plan del Proyecto La definicin de requisitos se refiere a la identificacin de las funciones bsicas del componente de programacin en un sistema de equipo/personal/programacin. Se pone atencin en las funciones y restricciones bajo las cuales se deben desarrollar. La decisin de cmo se instrumentara la programacin se retrasa hasta la fase de diseo. El producto de la definici6n de requisitos, es una especificacin que describe el ambiente de procesamiento, las funciones requeridas de los programas, restricciones de configuraci6n sobre los programas (tamao, velocidad, configuraci6n de equipo), manejo de excepciones, subconjuntos y prioridades de instrumentaci6n, cambios probables y modificaciones factibles, as como los criterios de aceptaci6n del producto de programaci6n. En el modelo de fases, el diseo de la programacin viene despus del anlisis. El diseo se refiere a la identificaci6n de los componentes de la programacin (funciones, flujos de datos, y almacenamientos), especificando las relaciones entre ellos, la estructura de la programacin, y manteniendo un registro de las decisiones, proporcionando un documento base para la instrumentaci6n. El diseo se divide en estructural y detallado. El diseo estructural comprende la identificacin de los componentes de la programacin, su desacoplamiento y descomposici6n en mdulos de procesamiento y estructuras de datos conceptuales, y la especificacin de las interconexiones entre componentes. El diseo detallado se refiere a detalles de cmo: cmo empacar mdulos de procesamiento, y cmo instrumentar los algoritmos, las estructuras de datos y sus interconexiones. Este diseo se relaciona con la adaptacin de cdigo existente, modificacin de algoritmos estndar, invencin de nuevos algoritmos, diseo de representaciones de datos, e integracin del producto final. Diseo detallado no es igual que instrumentacin. El primero est muy influido por el lenguaje de programacin; pero no tiene que ver con aspectos sintcticos del mismo o con un nivel de detalle como evaluacin de expresiones y estatutos de asignacin. La fase de instrumentacin en el desarrollo del producto incluye La traduccin de las especificaciones del diseo en cdigo fuente, as como su depuracin, documentacin y pruebas. Los lenguajes de programacin modernos proporcionan muchas caractersticas para mejorar la calidad del cdigo fuente, como elementos estructurados, tipos de datos predefinidos o definidos por el usuario, verificacin de tipos, reglas flexibles de cobertura, mecanismos para manejo de excepciones, elementos concurrentes, y mdulos con compilacin separada. Algunas de estas caractersticas se pueden simular en los lenguajes primitivos, mediante un estilo disciplinado de programacin.

Los errores descubiertos durante la fase de instrumentacin pueden ser errores en las interfaces de datos entre rutinas, errores lgicos en los algoritmos, errores en las estructuras de datos, y de falta de consideracin de casos de procesamiento. Adems, el cdigo fuente puede contener: errores de requisitos, que indican alguna omisin de las necesidades del usuario en el documento de requisitos; errores de diseo, que reflejarn una mala traduccin de requisitos en especificaciones y, por ultimo, errores de instrumentacin debidos a una mala traduccin de especificaciones en cdigo fuente. Una de las metas principales del modelo de fases para el desarrollo de productos de programacin es la eliminacin de errores de requisitos y diseo, antes de iniciada la instrumentacin. Como se estudiar, es muy caro eliminar errores del anlisis y el diseo del cdigo fuente durante la instrumentacin y las pruebas. Las pruebas del sistema comprenden dos tipos de actividades: pruebas de integracin y de aceptacin. El desarrollo de una estrategia para integrar los componentes de un sistema de programacin, en una unidad funcional, requiere una planeacin cuidadosa de modo que se disponga de los mdulos cuando estos se necesiten. Las pruebas de aceptacin se relacionan con a planeacin y ejecucin de varios tipos de pruebas para demostrar que el sistema de programacin instrumentado satisface las necesidades establecidas en el documento de requisitos. Una vez aceptado por el cliente, el sistema de programacin se entrega para operacin y se inicia la fase de mantenimiento del modelo de ciclo de vida por fases. Las actividades de mantenimiento incluyen mejoras de las capacidades, adaptacin a nuevos ambientes de procesamiento, y correccin de fallas del sistema. El modelo de fases del ciclo de vida de desarrollo de productos de programacin presentado en la figura 1 es simplista, no existen logros en el modelo, ni se mencionan los documentos generados, ni las revisiones que se efectan a lo largo del desarrollo, ni se indica el esfuerzo relativo de cada fase, ni el papel de prototipos en el desarrollo, ni se mencionan actividades de control de calidad; slo se hace una indicaci6n somera de la verificacin constante de los productos durante el ciclo de vida. El proceso de desarrollo no es lineal. El desarrollo de productos de programacin nunca se lleva a cabo como una sucesin suave de actividades como lo indica la figura de cascada. Existe mas interacci6n y empalme entre las fases de lo que se puede indicar en una representacin simple de dos dimensiones. Sin embargo, el modelo de fases del ciclo de vida es vlido para el proceso de desarrollo en situaciones donde es posible redactar un conjunto razonablemente completo de especificaciones para el producto de programacin, al principio del ciclo de vida. Esto suele suceder cuando los encargados del desarrollo han evolucionado previamente sistemas similares. IV. El modelo de cascada Gustavo Donoso: El modelo de cascada es tambin conocido como Modelo en cascada o Modelo lineal secuencial o Ciclo de vida bsico o Ciclo de vida clsico. Es un refinamiento altamente influenciado para 1970 del modelo de etapas. Existe, para este modelo, un reconocimiento de los ciclos de retroalimentacin entre etapas, y una gua para confinar las retroalimentaciones a las etapas sucesivas con el objetivo de minimizar el costo del retrabajo involucrado en retroalimentaciones a travs de muchas etapas. Las ventajas que presentan tanto el modelo de etapas y de cascada tiene relacin con la idea de postular un marco de trabajo claro, que reconoce y define las actividades involucradas en el desarrollo de software, permitiendo establecer relaciones de cooperacin entre ellas. Corresponden, tambin, a los mtodos ms usados en desarrollo de software y que han sido exitosos durante dcadas tanto en el desarrollo de grandes sistemas como en el de pequeos.

Tanto el modelo de etapas como el de cascada, presentan algunas dificultades comunes. Por ejemplo, la especificacin de los problemas. Ambos mtodos asumen que el diseador puede distinguir entre lo que el sistema debe hacer y como el sistema lo har; pero algunos problemas no pueden ser divididos tan fcilmente para ser atacados desde este prisma. Por otro lado, generalmente los requerimientos son especificados al inicio del proyecto y, paradojalmente, cuando se tiene la claridad suficiente para definir precisamente lo que se quiere es cuando se est en las ltimas etapas del proyecto. Esto es consecuencia, en general, de que los clientes no estn familiarizados con la tecnologa, con lo cual producen requerimientos muy vagos, que son interpretados arbitrariamente por los desarrolladores. Otro factor importante es que estos mtodos asumen que una vez que los requerimientos han sido definidos entonces ellos no cambiarn ms. Pero, dependiendo de la complejidad del proyecto, la implementacin final puede ocurrir meses o, eventualmente, aos despus de que los requerimientos han sido especificados; as, en las ltimas etapas del proyecto, los requerimientos pueden haber cambiado. Existira un nfasis en la elaboracin de documentos. El sistema completo es descrito y registrado en papel, cada etapa produce cierta cantidad de documentos. Esto lleva a que, por ejemplo, para sistemas complejos las especificaciones de requerimientos pueden ser de cientos de pginas, explicando todos u cada uno de los detalles del sistema. Y es difcil poder visualizar a priori, desde ste volumen de papel, las caractersticas del sistema. Por ltimo, se ha detectado que el enfoque lineal de estos mtodos no sera el adecuado para reflejar el proceso de desarrollo de software. Esto explica que se diga que para algunos proyectos el modelo clsico los lleva a seguir las etapas en orden incorrecto. Ms an, es posible que todas las etapas del proyecto, estn comprimidas dentro de cada una. Como se ha podido observar, la especificacin de mtodos ms acabados para el desarrollo de software no logra superar el problema de la distancia entre la visin del usuario y la del desarrollador, ya que no se ha buscado resolver ese problema, sino que las soluciones se centraron principalmente en la divisin de las tareas con miras al control de las mismas, lo que si bien soluciona el problema de especificar y luego programar, crea otros, como el presentado en el prrafo anterior, en que no todos los problemas podran ser abordados desde una misma perspectiva de orden en las etapas. Figura 5: Modelo de Cascada Eduardo Cohen: Ingeniera y anlisis del sistema. Interrelacin con hardware, personas, bases de datos. (Documentar cada paso.) Anlisis de los requisitos del software. Hay que comprender el mbito de la informacin del software, as como la funcin, el rendimiento y las interfases requeridas. Diseo. La estructura de los datos, la arquitectura del sw, el detalle procedimental, y la caracterizacin de la interfase. Codificacin. 7

Traducir el diseo para que lo entienda la mquina. Prueba. Cuando ya se ha generado el cdigo. Mantenimiento. El software sufrir cambios despus de que se entregue al cliente. Problemas: 1. No siempre se sigue el flujo secuencial. 2. Es difcil tener un 100% de los requisitos al inicio. 3. El cliente debe tener paciencia. Los primeros resultados sern hasta que ya este operando el sistema. Figura 6: El ciclo de vida clsico Norris & Rigby: El ciclo de vida proporciona un modelo conveniente que sirve para dos propsitos. En primer lugar, permite representar los procesos deconcepcin y produccin en una forma grfica y lgica, y segundo, proporciona un marco de trabajo alrededor del cual las actividades de aseguramiento de calidad pueden ser construidas en una manera decidida y disciplinada. El desarrollo de software desde el concepto inicial a travs de la operacin es un proceso involuntario. Es decir, se produce mediante etapas sucesivas de especificacin, diseo y modificacin. Cada evaluacin de una parte del software se hace por una revisin de la documentacin que describe los requerimientos, especificacin, diseo o, despus, por pruebas al cdigo y rea usada del sistema realizado da como resultado cambios. Idealmente, el proceso de desarrollo debe involucrar gradas sucesivas de especificacin y diseo donde cada paso es verificado contra los requerimientos de la etapa precedente. As un producto de software viable evoluciona con errores que se encuentran y corrigen conforme ocurren. El modelo de desarrollo de software utilizado con mayor frecuencia, ilustrado en la figura 7, a menudo se denomina el "modelo V o cascada" (quiz por su similitud a un conjunto de cascadas). El modelo representa el ciclo de vida del software como un conjunto de actividades ligadas, pero separadas, con entradas descendientes a etapas sucesivas y retroalimentacin ascendente para proporcionar verificacin contra etapas previas as como una validacin final de los requerimientos. Aunque no es su intencin ser una representacin perfecta de lo que ocurre en realidad, este modelo ha tenido un uso muy difundido durante 15 aos. Esto se explica aqu con detalle para dar un sentido de lo que se describe en un modelo de ciclo de vida y cmo puede ayudar a controlar el proceso de desarrollo de software. La primera etapa en este modelo es la definicin de requerimientos. Esta es, invariablemente, la primera etapa de cualquier proceso orientado al problema y es en muchos casos la ms difcil de lograr. En el siguiente capitulo se analizan las razones detrs de esto. Por ahora, tan slo estableceremos que el problema radica en La comunicacin entre el cliente y el desarrollador. El primero no esta siempre en posicin de definir con precisin lo que se requiere; como resultado, el segundo por lo general tiene gran dificultad para producir una especificacin con el detalle suficiente que permita asegurar La traduccin de los requerimientos para el diseo. 8

Figura 7: El ciclo de vida cascada An en casos donde el cliente y el diseador construyen Un conjunto preciso de requerimientos, las tendencias del acto del desarrollo concreto del sistema dan como resultado La modificacin de La percepcin original del cliente de lo que se necesita al final. La etapa de requerimientos puede compararse con la preparacin de un documento legal. Se transforma lo mas preciso, lo mas difcil es entenderlo. Si se omite La precisin, entonces La libertad para La ambigedad y el mal entendido se incrementa. Supongamos, por el momento, que puede esbozarse un grupo satisfactorio de requerimientos, que hay una base para la siguiente etapa en el modelo cascada. Este nos lleva al diseo y por lo general necesita que el desarrollador responda a los requerimientos establecidos con alguna forma de especificacin de funciones que definan la apariencia externa de las funciones del sistema como el desarrollador las percibe. El material de salida de esta etapa es una definicin de lo que el desarrollador desea implantar, de tal forma que proporciona la primera evidencia visible para el cliente de que el producto eventual ser lo que se orden. De aqu en adelante, en el modelo cascada, uno se ve envuelto en la repeticin de diseo de alguna forma. En el nivel ms alto, un diseo de sistema establecido es el que permitir la separacin de los componentes del software de los que no lo son y la definicin de la interfaz entre ellos. Muy a menudo un diseo de arquitectura ser generado para establecer un marco de trabajo. Entonces, el diseo del software se lleva a cabo mediante el uso de una metodologa "hacia abajo" determinada. He aqu que el mayor efecto sobre la calidad puede verse dado que la calidad de diseo, a largo plazo, determinar la calidad final del producto. El nivel ms bajo del diseo de software proporcionar la base para la codificacin y definir con amplitud la estructura de los programas. En las iteraciones a lo largo del diseo, el problema general debe ser dividido lo suficiente para dejar slo dificultades menores para el programador. En la prctica, este rara vez es el caso y algunas decisiones de diseo tomadas en una etapa anterior no pueden implantarse. En tales casos, es necesario recurrir al rediseo y repetir hasta que el problema sea solucionado. La siguiente etapa mayor en el modelo cascada es la concerniente a la prueba del cdigo diseado. Esta actividad tiene lugar a varios niveles. En el nivel mas bajo, los programadores deben probar su propio cdigo fuente por separado de otras partes del sistema. Una vez que sean consistentes consigo mismos, los mdulos probados pueden presentarse para la integracin del sistema del cual son parte. Conforme los progresos de integracin y las funciones externas comienzan a aparecer es factible dar al cliente la oportunidad de ver el producto potencial. Esto permite hacer pruebas invaluables en la demostracin del sistema que se desarrolla como se especific originalmente y tambin para detectar puntos de mal entendido en la interpretacin de los requerimientos originales. La prueba de aceptacin por lo general se concreta a demostrar los aspectos funcionales del producto. En realidad, es la entrega y operacin La que casi siempre revela el grado en que el producto satisface los requerimientos del cliente. Por ltimo, una prueba de aceptacin del sistema completo tendr lugar antes de su entrega. En esta etapa el cliente puede "terminar" el sistema quiz con algunos defectos ya conocidos. Sin embargo, est lejos de la historia completa. Es esencial que la evolucin del sistema posterior a la entrega se considere como parte del ciclo de vida del mismo, justo antes de ser obsoleto. De manera tpica, los sistemas de software estn ms en servicio que en desarrollo (el software para el cambio telefnico tuvo una vida de diseo de 20 aos. Inevitablemente se requieren modificaciones para entregar sistema, para corregir errores encontrados en el rea y para agregar nuevas funciones al sistema. La actividad continua de mantenimiento, por la cual se descubre y dirige la ausencia de cumplimiento a los requerimientos o requerimientos malentendidos y se agregan nuevos, necesita considerarse parte del ciclo de vida general del sistema.

El tiempo empleado en cada una de las fases anteriores del ciclo de vida vara de un proyecto a otro. En la figura 8 se dan algunas cifras representativas para la proporcin y esfuerzo en las actividades y para su fase. Figura 8: Proporcin tpica de actividades sobre una vida de un producto de software El modelo de ciclo de vida cascada no es el nico disponible. Tiene, sin embargo, la ventaja de ser el que se utiliza con mayor frecuencia y, por tanto, el mejor entendido. El principal beneficio de adoptar este modelo radica en el hecho de que las oportunidades para la retroalimentacin dentro de el son muchas y, por ende, proporciona lo que el desarrollador del sistema desea; la propagacin de fallas puede prevenirse en gran medida por la deteccin y verificacin de las actividades en cada etapa. Hay, por supuesto, algunas deficiencias en el modelo cascada: la distribucin de las actividades no es secuencial, como la descrita, no reconoce el desarrollo a travs de prototipo, etc. A pesar de eso, ha sido aplicado con xito en muchos proyectos gran des y complejos, tal como el sistema System X switching, que continua en uso extenso. V. El desarrollo orientado a prototipos Gustavo Donoso: Si bien algunos autores consideran que esto es parte del ciclo de vida clsico (Boehm, 1988), es tambin posible verlo como un mtodo independiente. Una definicin de un prototipo en software podra ser: Las fases que comprende el mtodo de desarrollo orientado a prototipos seran: Investigacin preliminar Las metas principales de esta fase son: determinar el problema y su mbito, la importancia y sus efectos potenciales sobre la organizacin por una parte y, por otro lado, identificar una idea general de la solucin para realizar un estudio de factibilidad que determine la factibilidad de una solucin software. Definicin de los requerimientos del sistema El objetivo de esta etapa es registrar todos los requerimientos y deseos que los usuarios tienen en relacin al proyecto bajo desarrollo. Esta etapa es la ms importante de todo el ciclo de vida, es aqu donde el desarrollador determina los requisitos mediante la construccin, demostracin y retroalimentaciones del prototipo. Por lo mismo esta etapa ser revisada con ms detalle luego de esta descripcin. Diseo tcnico Durante la construccin del prototipo, el desarrollador ha obviado el diseo detallado. El sistema debe ser entonces rediseado y documentado segn los estndares de la organizacin y para ayudar a las mantenciones futuras. Esta fase de diseo tcnico tiene dos etapas: por un lado, la produccin de una documentacin de diseo que especifica y describe la estructura del software, el control de flujo, las interfaces de usuario y las funciones y, como segunda etapa, la produccin de todo lo requerido para promover cualquier mantencin futura del software. Programacin y prueba Es donde los cambios identificados en el diseo tcnico son implementados y probados para asegurar la 10

correccin y completitud de los mismos con respecto a los requerimientos. Operacin y mantencin La instalacin del sistema en ambiente de explotacin, en este caso, resulta de menor complejidad, ya que se supone que los usuarios han trabajado con el sistema al hacer las pruebas de prototipos. Adems, la mantencin tambin debera ser una fase menos importante, ya que se supone que el refinamiento del prototipo permitira una mejor claridad en los requerimientos, por lo cual las mantenciones perfectivas se reduciran. Si eventualmente se requiriese una mantencin entonces el proceso de prototipado es repetido y se definir un nuevo conjunto de requerimientos. La fase ms importante corresponde a la definicin de requerimientos, la cual correspondera a un proceso que busca aproximar las visiones del usuario y del desarrollador mediante sucesivas iteraciones. La definicin de requerimientos consiste de cinco etapas entre dos de las cuales se establece un ciclo iterativo: Anlisis grueso y especificacin El propsito de esta subfase es desarrollar un diseo bsico para el prototipo inicial. Diseo y construccin El objetivo de esta subfase es obtener un prototipo inicial. El desarrollador debe concentrarse en construir un sistema con la mxima funcionalidad, poniendo nfasis en la interface del usuario. Evaluacin Esta etapa tiene dos propsitos: extraer a los usuarios la especificacin de los requerimientos adicionales del sistema y verificar que el prototipo desarrollado lo haya sido en concordancia con la definicin de requerimientos del sistema. Si los usuarios identifican fallas en el prototipo, entonces el desarrollador simplemente corrige el prototipo antes de la siguiente evaluacin. El prototipo es repetidamente modificado y evaluado hasta que todos los requerimientos del sistema han sido satisfechos. El proceso de evaluacin puede ser dividido en cuatro pasos separados: preparacin, demostracin, uso del prototipo y discusin de comentarios. En esta fase se decide si el prototipo es aceptado o modificado. Modificacin Esto ocurre cuando la definicin de requerimientos del sistema es alterada en la subfase de evaluacin. El desarrollador entonces debe modificar el prototipo de acuerdo a los comentarios hechos por los usuarios. Trmino Una vez que se ha desarrollado un prototipo estable y completo, es necesario ponerse de acuerdo en relacin a aspectos de calidad y de representacin de el sistema. En la siguiente figura se puede ver un esquema en que estas etapas se realizan, note que la especificacin de requerimientos est claramente diferenciada de las dems. Es en ella donde se utiliza el prototipado, ya que permite entregar al usuario lo que sera una visin la solucin final en etapas tempranas del desarrollo, reduciendo tempranamente los costos de especificaciones errneas. Figura 9: Modelo de desarrollo orientado a prototipos Las ventajas de un enfoque de desarrollo orientado a prototipos estn dadas por: reduccin de la incertidumbre 11

y del riesgo, reduccin de tiempo y de costos, incrementos en la aceptacin del nuevo sistema, mejoras en la administracin de proyectos, mejoras en la comunicacin entre desarrolladores y clientes, etc. Si bien, el desarrollo orientado a prototipos tiene considerables ventajas, tambin presenta desventajas como: la dependencia de las herramientas de software para el xito ya que la necesidad de disminucin de incertidumbre depende de las iteraciones del prototipo, entre ms iteraciones existan mejor y esto ltimo se logra mediante el uso de mejores herramientas lo que hace a este proceso dependiente de las mismas. Tambin, no es posible aplicar la metodologa a todos los proyectos de software y, finalmente, la mala interpretacin que pueden hacer los usuarios del prototipo, al cual pueden confundir con el sistema terminado. No se puede desconocer que la fase de definicin de requerimientos se ha perfeccionado en dos aspectos importantes: primero se ha aproximado los visiones del usuario y el desarrollador, lo cual representa el beneficio de establecer una base comn de comunicacin; tambin, el hacer explcita la posibilidad de iterar sobre estos dominios permitira que la convergencia de los mismos sea una posibilidad cierta. Pero lo anterior no asegura el xito, por ejemplo, qu certeza existe en que esta iteracin sea en la direccin correcta y lleve a la convergencia de los dominios; no se puede desconocer las diferencias que existen entre la prueba de un prototipo de software en la fase de definicin de requerimientos y el uso del mismo ya como un producto terminado. Para explicar esto, podemos hablar de dos dominios en el usuario, uno que es el que se establece cuando se prueba el prototipo y otro, distinto por cierto, el que ocurre cuando el usuario hace uso del software en ambiente de explotacin. Por ltimo, el proceso de iteracin para que sea efectivo debera ser infinito, lo que lo hace poco efectivo. Es decir, mediante este mtodo acercamos la problemtica de los usuarios a los dominios de los desarrolladores y viceversa, pero no sera posible lograr un pareamiento uno a uno entre estos dominios, lo que sera el ideal. Richard Fairley: Otra visin del desarrollo y mantenimiento de un producto de programacin se muestra en la figura 10. Este modelo subraya las fuentes de requisitos para el producto, puntos decisivos de continuar/detenerse, y el usa de prototipos. Un prototipo es una representacin o modelo del producto de programacin que, a diferencia de un modelo de simulacin, incorpora componentes del producto real. Por lo regular, un prototipo tiene un funcionamiento limitado en cuanta a capacidades, confiabilidad o eficiencia. Hay varias razones para desarrollar un prototipo; una de ellas es ilustrar lo formatos de datos de entrada, mensajes, informes y dilogos al cliente, este es un mecanismo adecuado para explicar opciones de procesamiento y tener un mejor entendimiento de las necesidades de l. La segunda razn es para explorar aspectos tcnicos del producto propuesto. Con frecuencia, una decisin importante del diseo depender., por ejemplo, del tiempo de respuesta del controlador de un dispositivo o de la eficiencia de un algoritmo de clasificacin; en tales casos, un prototipo puede ser la mejor o nica manera de resolver el problema. La tercera razn para desarrollar un prototipo s da cuando el modelo de fases anlisis > diseo > instrumentacin es inapropiado. El modelo de fases se aplica cuando se puede redactar un conjunto razonablemente completo de especificaciones al inicio del ciclo de vida. Algunas veces no es posible definir el producto sin un desarrollo exploratorio, y en ocasiones no es claro como proceder a la mejora del sistema hasta que no se instrumenta y evala una versin. El desarrollo exploratorio se utiliza para desarrollar algoritmos para jugar ajedrez, para resolver problemas confusos, y para llevar a cabo tareas que requieren la simulacin del comportamiento humano; sin embargo, esta tcnica no se limita a estas situaciones (SEN82). La naturaleza y extensin del prototipo por desarrollar en un proyecto de programacin depende de la 12

naturaleza del producto. Se pueden desarrollar nuevas versiones de un producto ya existente con el modelo de fases y sin ningn prototipo. El avance de un producto totalmente nuevo, tal vez requiera de prototipo durante las fases de planeacin y anlisis, o el producto se puede desarrollar como una serie de diseos e instrumentaciones. Figura 10: Modelo de prototipo para el ciclo de vida VI. El modelo de desarrollo evolutivo Gustavo Donoso: El desarrollo evolutivo es una metodologa de desarrollo de software muy relacionada con, pero claramente distinta de, desarrollo por prototipos. El nfasis esta puesto sobre la importancia de obtener un sistema de produccin flexible y expandible. As, si los requerimientos cambian durante el desarrollo del sistema, entonces con un mnimo de esfuerzo y tiempo se puede desarrollar un sistema de trabajo flexible. La diferencia fundamental entre desarrollo evolutivo y prototipos de software es que el desarrollo evolutivo busca reemplazar el viejo sistema con uno nuevo que tendra la propiedad de satisfacer los nuevos requerimientos lo ms rpido posible. En contraste, prototipos usa un enfoque iterativo solo para determinar los requerimientos organizacionales. Por lo tanto el tiempo tomado entre cada iteracin es mucho ms importante para el desarrollo evolutivo. En la figura 10 se puede ver grficamente esta diferencia. El desarrollo evolutivo asume que los requerimientos de un proyecto estn sujetos a cambios continuos, por lo cual es necesario definir una estrategia de desarrollo que refleje esta situacin. En cambio, el desarrollo orientado a prototipos, as como los anteriores, asume que los requerimientos "reales" existen y se vale de las iteraciones del prototipo para establecerlos y modelarlos. La idea entonces de la metodologa de desarrollo evolutivo es estar liberando constantemente una nueva versin del sistema que sea completamente funcional; as, cada sistema producto de las iteraciones sucesivas del mtodo tendra incorporado los nuevos requerimientos que ha sido posible identificar y que no estaran considerados en la anterior versin. As, las etapas del desarrollo evolutivo tienen por objetivo extender los incrementos de un producto de software operacional, en las direcciones determinadas por la evolucin de la experiencia operacional. El modelo de desarrollo evolutivo puede ser idealmente asociado a un lenguaje de aplicacin de cuarta generacin y mejor an a situaciones en que el usuario dice, "yo no puedo hablarte sobre lo que yo quiero, pero yo lo reconocera si lo viese". As, este mtodo entregara al usuario rpidamente una capacidad operativa inicial y, adems, establecera una base real operacin para determinar las mejoras subsecuentes en el producto. Pero, existiran algunas dificultades tcnicas que no pueden dejar de ser mencionadas, por ejemplo: No facilita la integracin de aplicaciones que han sido desarrolladas como sistemas independientes. Facilita la posibilidad de que existan casos de "esclerosis de informacin", en el sentido que trabajos temporales alrededor de algunas deficiencias del software se solidifican como poderes inmodificables a la evolucin. Es decir, en la medida que se evoluciona, esta misma facilidad a la evolucin llevara a que no sea posible seguir evolucionando. Pueden ocurrir que el software nuevo es un reemplazo incremental de un subsistema dentro de un gran sistema existente. Si el sistema existente est pobremente modularizado, entonces es obvia la dificultad en 13

hacer que la nueva versin se acople con facilidad al resto. El mtodo evolutivo tiene la gran ventaja de reconocer la existencia de una constante de cambios en los requerimientos y, desde esta premisa, propone una solucin, la cual es vlida para la solucin de ese problema pero que no resolvera la inquietud original, esto es que el mtodo no facilita elementos que permitan reducir la distancia conceptual entre los dominios del desarrollador y del usuario. Con la existencia del mtodo evolutivo se configura una nueva problemtica en el desarrollo de sistemas, es decir, la crisis se expande ahora en el sentido que no slo se requiere reflejar lo ms fielmente posible las necesidades del usuario, sino que ahora los ambientes en que el sistema est inserto estn sujetos a cambios y estos cambios inciden en la efectividad del software desarrollado. Lo anterior fue articulado por Meir M. Lehman a principio de la dcada de los ochenta, al definir las leyes de la evolucin del software, en que las dos primeras leyes tienen directa relacin con lo que se describe. Veamos a Lehman citado por Ian Sommerville, en el libro Ingeniera de Software: Lehman propone que la evolucin de un sistema de software esta sujeta a varias leyes. Ha determinado estas leyes a partir de observaciones experimentales de varios sistemas, como los grandes sistemas operativos (...). Dice Lehman que hay cinco leyes de la evolucin de los programas: Cambio Continuo. Un programa que se utiliza en un ambiente del mundo real debe cambiar o ser cada vez menos til en ese ambiente. Complejidad creciente. A medida que un programa en evolucin cambia, su estructura se hace ms compleja, a menos que se lleven a cabo esfuerzos activos para evitar este fenmeno. Evolucin del programa. La evolucin del programa es un proceso autorregulador, y una medicin de atributos del sistema, como el tamao, el tiempo entre versiones, el nmero de errores advertidos, etc., revela las tendencias estadsticas significativas y las caractersticas invariantes. Conservacin de la estabilidad organizativa. Durante el tiempo de vida de un programa, su rapidez de desarrollo es casi constante e independiente de los recursos dedicados al desarrollo del sistema. Conservacin de la familiaridad. Durante el tiempo de vida de un sistema, la evolucin del cambio del sistema en cada versin es, aproximadamente, constante. Sommerville considera las "leyes" de Lehman como elementos positivos en la configuracin del mbito en que se desarrollan los sistemas, por ejemplo, dice que las dos primeras hiptesis de Lehman son casi con certeza vlidas. Interpretando la primera como: ...El razonamiento subyacente en la primera ley... es que cuando un sistema de software (sobre todo uno grande) se construye para modelar algn ambiente y despus se introduce en l, modificndose as el ambiente original con la presencia del sistema de software... No puede ser ms interesante para los propsitos de esta revisin la caracterstica planteada por esta hiptesis, es decir, si se desarrolla software no se podra pensar desde la perspectiva de estabilidades, todo lo contrario, 14

necesariamente es el cambio el motor y el configurador de los sistemas de software. Aqu el punto es la introduccin de una nueva perspectiva al problema del desarrollo de software, perspectiva que ser determinante en el planteamiento de un modelo que permita reflejarla. Lo expresado en la primera ley, configura un nuevo problema como se habia anticipado para el desarrollo de software, adems de la distancia conceptual entre desarrollador y usuario, existira el problema de la evolucin constante de la organizaciones o, ms claramente, la connaturalidad de las organizaciones al cambio como elemento subyacente en su ser organizacional. Situacin que se haba anticipado en el curso de "Ambientes..." La segunda ley en el anlisis de Somerville corresponde al hecho de que la estructura del programa original se estableci para aplicarlo a un conjunto de necesidades iniciales. A medida que se produce el cambio evolutivo de esas necesidades, la estructura original se degrada y con ello se va haciendo ms compleja ya que al ir incrementndose la distancia conceptual entre el software y el medio que lo contiene, ste va estando cada vez ms presente en el hacer cotidiano, formulando quiebres constantes sobre el sistema de trabajo lo que imprime un sello de complejidad a la utilizacin del software. Las siguientes leyes tienen relacin con las caractersticas de las organizaciones y de los individuos que participan en el proceso de desarrollo de software. Lehman afirma que las organizaciones se esfuerzan por lograr la estabilidad e intentan evitar cambios drsticos o repentinos. Por tanto, a medida que se aaden ms recursos a un proyecto de software, el efecto evolutivo de la adicin de nuevos recursos se va reduciendo, hasta que la adicin de nuevos recursos no produce ningn efecto. Si bien, estas ltimas leyes no resultan tan obvias como las primeras y podran ser cuestionadas, es posible que la ltima, que tiene que ver con la conservacin de la familiaridad sea la ms til, como tambin la de reduccin de personal, en el sentido que cuanta ms gente trabaje, menos productivo ser cada miembro del proyecto. Las proposiciones de Lehman se orientaron a la creacin de un mtodo de desarrollo que considerase estas caractersticas. Richard Fairley: El desarrollo de productos mediante el mtodo de versiones sucesivas es una extensin del mtodo de prototipos en el que se refina un esqueleto inicial del producto obteniendo as, cada vez ms capacidades. En dicho me todo, cada versin es un sistema funcional y capaz de realizar trabajo til. La figura 12a ilustra la fase de anlisis seguida por el diseo de instrumentacin de versiones sucesivas en un proceso iterativo. Las lneas punteadas indican que al conseguir la versin I puede necesitarse ms anlisis antes de disear la versin I+1. En la figura 12b las versiones 1 a la N del producto se disean antes de cualquier actividad de instrumentacin. En este caso, las caractersticas de cada diseo sucesivo sern planeadas durante la fase de anlisis. Las lneas punteadas de la figura 12b indican que la instrumentacin de la 1esima versin puede demostrar la necesidad de mayor anlisis y diseo antes de la puesta en marcha de la versin 1+1. El mtodo de versiones sucesivas es similar, peto no idntico al de mejoras iterativas (BAS75). En realidad, el ciclo de desarrollo de un producto de programacin es una combinacin de los distintos modelos presentados. Las organizaciones y proyectos especiales pueden adoptar alguno de estos modelos en particular; sin embargo, ciertos elementos de ellos se encuentran en todo proyecto de programacin. Por ejemplo, para proyectos de desarrollo de programacin no es extrao adoptar el modelo de fases como marco de referencia bsico, e incluir prototipos y versiones sucesivas en el desarrollo. VII. El modelo de transformacin

15

Gustavo Donoso: Desde la perspectiva de la evolucin del software y las leyes de Lehman, se hace una revisin del ciclo de vida del software, el cual lleva al desarrollo de un mtodo que se podra denominar el modelo de transformacin. Desde la ptica de lan Sommerville, este modelo se caracteriza por que... un concepto de aplicacin se transforma de modo paulatino en una especificacin formal de software. Esto implica la reduccin de la cantidad de informacin bruta en cada etapa de la transformacin, proceso que el denomina abstraccin. Una vez establecida la especificacin, se aade la informacin (a esto le llama materializacin) y el sistema abstracto se transforma, mediante un conjunto de notaciones formales, en un programa operacional. Las bases de una concepcin de transformacin en el desarrollo de software, las explica el mismo Lehman (1980). Al considerar una clasificacin de los programas y, mediante sta, definir un mtodo sistemtico que permita transformar programas de una clase ms compleja en otra de complejidad menor. La clasificacin ...est basada en el reconocimiento de el hecho que,..., cualquier programa es un modelo de un modelo dentro de una teora de un modelo de una abstraccin de alguna porcin del mundo o de algn universo del discurso. La clasificacin categoriza a los programas en tres clases, S, P y E.... ProgramasS. Los ProgramaS son aquellos cuya funcin puede ser definida formalmente por y derivable desde, una especificacin.... Las sentencias del problema, el programa y la solucin, cuando es obtenida, puede relacionarse con un mundo externo. Pero esto es una relacin casual y no causal. En efecto, cuando esto existe somos libres para cambiar nuestro inters y redefinir el problema. Pero el resultado de esto es un nuevo programa para esta solucin. Puede ser posible y eficiente derivar el nuevo programa desde el antiguo. Pero es un programa diferente que define una solucin para un problema diferente. Programas PE En los Programas P (solucin de problemas del mundo real)... a despecho de el hecho de que el problema a ser resuelto pueda ser definido precisamente, la aceptacin de la solucin est determinada por el medio ambiente en que est involucrada. La solucin obtenida ser evaluada por comparacin con el medio ambiente real... En los Programas S, el juicio sobre la correccin, y por lo tanto el valor, del programa est relacionado con la definicin solamente de esta especificacin, las sentencias del problema que debe ser reflejado. En los Programas P, el asunto no est centrado en el problema pero si sobre el valor y la validez de la solucin obtenida, esto es sobre el contexto del mundo real. Programas E. La tercera clase, los Programas E, estn inherentemente ms inclinados al cambio. Estos son programas que mecanizan una actividad humana o social... La instalacin de los programas junto con este sistema asociado ... cambia la real naturaleza del problema a ser resuelto, el programa puede hasta convertirse en parte del mundo que el mismo modela, est embebido en l...No como otros sistemas artificiales donde,..., el cambio es ocasional, aqu este aparece continuamente. La presin del cambio est construida con l.... Los Programas P y E estn estrechamente relacionados, podemos establecer la clase unin de P y E como ProgramasA. stos difieren de los ProgramasS en el sentido que representan una aplicacin computacional en el mundo real. Los programasS son siempre probablemente correctos... muchos de los componentes ms importantes de un gran programa son del tipo S... un ProgramaA puede siempre ser particionado y estructurado de manera que todos sus elementos sean ProgramasS. 16

Meir Lehmann, Program, Life Cycles, and..., ACM Proceeding, 1980, p. En esta ltima afirmacin esta el trasfondo de la idea de Lehman en relacin a la posibilidad de definir un metalenguaje que permita reducir programas complejos o "del mundo real" a especificaciones formales de programas. As, segn Boehm: ...el modelo de transformacin asume la existencia de una capacidad de automticamente convertir una especificacin formal de un producto de software en un programa que satisfaga la especificacin. Los pasos que son prescritos por el modelo de transformacin son: una especificacin formal de la mejor comprensin inicial del producto deseado. transformacin automtica de la especificacin en cdigo. un ciclo iterativo, si es necesario, para mejorar la ejecucin de el cdigo resultante para dar una gua de optimizacin al sistema de transformacin. probar el producto resultante, y un ciclo interactivo externo para ajustar las especificaciones basadas en el resultado de la experiencia operacional, y para rederivar, reoptimizar, y probar el producto de software ajustado. El modelo de transformacin evita las dificultades de tener que modificar un cdigo que tiene una estructuracin muy pobre debido a las repetidas optimizaciones , mediante la posibilidad de que las modificaciones sean fabricadas a travs de las especificaciones, esto sin intervenir el cdigo, el cual se reconstruira cada vez. Con este modelo se puede aumentar, al menos tericamente, la capacidad de dar respuesta rpida a la evolucin que connaturalmente estara asociada a las organizaciones, pero, al igual que el modelo espiral , se ha alejado del problema central que se ha discutido hasta ahora, que es cmo acortar la brecha conceptual entre los dominios del desarrollador y del usuario, si es que es posible. En relacin a este ltimo y central problema, la crtica que se puede hacer al modelo de transformacin es que necesariamente al transformar un problema del tipo A en problemas S, se est aplicando un reduccionismo que, probablemente, limite la expresin de toda la complejidad del problema original, particularizando la solucin a casos en que sea dable resolver sistemticamente y dejando fuera situaciones en que esta formalizacin no sea posible. En ese sentido, no sera factible que todos los problemas A sean transformables a unidades S. Adems, esto no evita la necesidad de tener que caracterizar un problema del tipo A, lo que remitira necesariamente a la cuestin original. VIII. Modelo Espiral Gustavo Donoso: El modelo Espiral de Boehm para Ingeniera de Software agrupa las mejores caractersticas del modelo del ciclo de vida clsico y de prototipos. Pero tambin agrega nuevas funciones que no estn incluidas en los otros modelos, como el anlisis de riesgo. El modelo espiral define cuatro actividades principales para el ciclo de vida. Planificacin

17

La determinacin de los objetivos del proyecto, alternativas y restricciones. Anlisis de Riesgo El anlisis de alternativas y la identificacin y solucin de riesgos. Ingeniera Desarrollo del producto. Evaluacin del cliente El asentimiento de los resultados de la ingeniera. El modelo es representado por una espiral dividida en cuatro cuadrantes, en que cada uno describe las actividades mencionadas anteriormente. El modelo espiral utiliza un esquema de desarrollo iterativo donde la primera iteracin comienza en el centro del crculo e, incrementalmente, se va desplazando hacia afuera. Las siguientes iteraciones sucesivas son versiones ms completas del software que est siendo construido. Al principio de cada iteracin del ciclo de vida se hace un anlisis de riesgo, mientras, por el otro extremo, la revisin del proyecto se realiza al final de la iteracin. As, se puede contrarrestar cualquier riesgo observado mediante las acciones adecuadas en el tiempo preciso. El modelo espiral es visto como un enfoque ms realista para el desarrollo de grandes sistemas de software. Usa un mtodo evolucionario para desarrollo y prototipos como una tcnica de reduccin de riesgo (pese a que los prototipos pueden ser usados en cualquier etapa dentro del ciclo de vida). Tambin utiliza el enfoque de sistematizacin y el 'desarrollo en etapas' del ciclo de vida clsico, pero, con la diferencia que todos estn incorporados dentro del esquema iterativo planteado por el modelo espiral. Norris & Rigby: Este modelo reconoce la necesidad de la revisin regular de un desarrollo conforme este progresa y sus requerimientos etc. Pero, por desgracia, cambian. El ciclo de vida evolutivo se representa por lo general mediante un modelo de "espiral" o caracol, como se muestra en la figura 13, donde se presenta un desarrollo ligado, esto es, un proceso incremental en vez de una secuencia de fases compartidas. Al usar el modelo, cada incremento de trabajo pasa por las siguientes etapas: Una revisi6n de los objetivos percibidos. Aseguramiento de los riesgos para cada una de las opciones de la siguiente etapa de trabajo. Plan para el desarrollo de la opci6n seleccionada. Desarrollo. 5. Revisi6n de la entrega de la etapa para verificar que satisfaga los objetivos iniciales. La principal ventaja de adoptar este modelo de ciclo de vida es que permite un considerable nivel de flexibilidad en un proyecto. Por el lado opuesto, requiere constante atencin y en realidad no admite planos a largo plazo. A pesar de eso, este enfoque ha sido aplicado con xito en el desarrollo de proyectos de software y es particularmente til cuando los requerimientos iniciales no son an muy claros, cuando se despliega nueva tecnologa cuando es probable que las necesidades del cliente cambien a lo largo curso del proyecto. Figura 13: El modelo de espiral de desarrollo de software (despus de Boehm)

18

 Mtodo de Sistemas "Soft" Gustavo Donoso: Checkland desarrolla la metodologa de sistemas "soft" en respuesta a las fallas de los enfoques ms convencionales para abordar problemas "espinudos", problemas que son complicados de definir, conocidos como problemas "soft". Los problemas "soft" son encontrados frecuentemente en organizaciones y no pueden ser resueltos por las mismas tcnicas usadas en resolver problemas ms formales. Las metodologas tradicionales para anlisis de sistemas asumen que el problema (como ellos lo definen) tiene una solucin definitiva y un numero de metas que pueden ser satisfechas. Es decir es factible en estas situaciones hacerse la pregunta: Cmo se resuelve el problema?. La metodologa de sistemas "soft" considera el trmino "el problema" como inapropiado, considera que es una visin errada de la situacin. Los sistemas "soft" reconocen que no existe un problema, pero si muchos problemas, lo que se describe como una "situacin problema". El nfasis es puesto ms sobre la caracterizacin del problema que sobre como se resuelve, en este caso es vlida la pregunta: cul es el problema?. As, las metas del sistema "soft" son mucho ms complejas que las metas de los sistemas tradicionales que pueden ser alcanzadas y medidas. El proceso involucrado en la metodologa de sistemas "soft" es el siguiente: El analista (en adelante el solucionador del problema), con la ayuda de los administradores y usuarios dentro de la organizacin (en adelante el dueo del problema), crean un cuadro de la situacin problema. El cuadro es una percepcin subjetiva del problema en un esquema informal. Incluir sistemas de la organizacin bajo revisin, la gente dentro de ello, las tareas ejecutadas, etc. Este cuadro es usado como ayuda a las discusiones con el o los dueos del problema. Los temas problemas son extraidos desde el cuadro por el solucionador. El agregar, desde su ptica propia, los conflictos entre el personal o funciones dentro de la organizacin, problemas de comunicacin u otro tipo de problemas que detecte. Este cuadro es utilizado para identificar problemas e informa al dueo de la situacin, antes que se desarrollen posibles soluciones. El uso de este cuadro es mucho mejor que los mtodos tradicionales para estimular a administradores y usuarios para revelar los problemas "reales" dentro de la organizacin. 3. Una vez completado el cuadro, el solucionador lo usar para crear una definicin raz. Checkland (1981) define la definicin raz como: "... una descripcin concisa y ajustada de un sistema de actividad humana que presenta qu es el sistema." La definicin raz es creada usando una lista de chequeo llamada el criterio CATWOE (Clients, Actors, Transformations, WorldView, Owner, Environment). Que por orden de importancia debera ser TWECOA. Ellos determinan quin est haciendo qu para quienes, y a quienes ellos estn preguntando. Qu supuestos estn siendo usados y en qu medio ambiente est sucediendo todo aquello. Una descripcin general de cada uno de estos elementos puede ser la siguiente: Cliente Actor Transformacin Visin de Mundo Dueo Todos aquellos beneficiados o afectados por las salidas del sistema. El agente de cambio que llevar afuera el proceso de transformacin. Los cambios que tienen lugar dentro o por causa del sistema. Cmo el sistema es percibido desde un punto de vista particular. Son las presunciones que tienen los miembros de, dueos o clientes de la organizacin. Es a quien el sistema le pregunta y/o quin puede causar que deje de existir. 19

Medio Ambiente

El mundo que envuelve e influencia al sistema, pero que no tiene control sobre l.

Si existen muchas versiones diferentes del cuadro, entonces sern creadas tantas definiciones raz como versiones existan. 4. Cuando los dueos y los solucionadores del problema estn satisfechos en que las definiciones raz estn bien formadas, se crea un modelo conceptual. Este describe en forma grfica que es lo que el sistema har. El modelo conceptual tomar en cuenta todas las definiciones raz consideradas. 5. El modelo conceptual es usado como la base de todos los cambios hechos por el sistema para eliminar los problemas. Como esta metodologa no considera cualquier procedimiento preconcebido, el anlisis es mucho mejor y permite un mejor entendimiento del problema.

X. El mtodo PSC Norris & Rigby: Este modelo toma otro enfoque, igualmente valido, para la modelaci6n del proceso de desarrollo al aceptar que varios puntos de vista o perspectivas sean considerados. Las principales perspectivas descritas dentro del FSC son: Pragmtica Visualiza al sistema en el contexto de su ambiente. Entrada/Salida Estudia el comportamiento externo del sistema y c6mo va a ser adquirido. Constructiva Examina el sistema en terminos de una colecci6n de funclones y recursos. Operativa Estudia el comportamiento interno del sistema. El uso del PSC involucra (como el de espiral) cuatro fases principales. Esta vez, cada una de las fases conciernen a los problemas de decisi6n de una de las perspectivas anteriores. El modelo identifica la pragmtica como el nivel mas abstracto. En esta fase, el sistema se estudia en trminos de su relacin con y su efecto en el ambiente en el que va a ser colocado. El modelo necesita que el diseo, la prueba y el aseguramiento sean completados en este nivel de abstracci6n antes de moverse a la siguiente fase. XI. Modelo del costo de un proyecto Richard Fairley: Otro punto de vista para el ciclo de vida de desarrollo de un producto de programacin es la consideracin del costo de la realizacin de las distintas actividades del proyecto. El costo de un proyecto es la suma de los 20

costos incurridos en cada fase, y stos, a su vez, incluyen los costos de la realizacin de los procesos y preparacin de los documentos de esa fase, ms los costos de verificacin de la consistencia de estos productos con los de las fases previas. Las modificaciones y correcciones a los productos de las fases previas son necesarias, dado que durante el desarrollo de la fase actual se encontrarn imprecisiones, inconsistencias y omisiones en sus productos y, adems, porque los requisitos, programacin, prioridades o presupuesto del cliente pueden cambiar, hecho que producira modificaciones. El costo de produccin de la Definicin del sistema y del Plan del proyecto es el mismo de realizar las planeacin y preparacin de los documentos, ms el costo de verificacin de que la Definicin del sistema establece precisamente las necesidades del cliente y el costo de verificacin de que el Plan del proyecto es factible. El costo de preparacin de la Especificacin de requisitos para la produccin; de software incluye el costo de definir requisitos y preparar documentos, ms el costo de modificar y corregir la Definicin del sistema y el Plan del proyecto, ms el costo de verificacin de que la Especificacin est completa y sea consistente con respecto a la Definicin del sistema y las necesidades del cliente. De la misma manera, el costo del diseo es el costo de las actividades propias y la generacin de los documentos, ms el costo de modificar y corregir la Definicin del sistema, el Plan del proyecto y la Especificacin de requisitos para la produccin de software, ms el costo de verificacin del diseo contra los requisitos, la Definicin del sistema y el Plan del proyecto. El costo de la instrumentacin del producto es el costo de la conversin, documentacin, depuracin y pruebas del cdigo fuente, ms el costo de la terminacin del Manual del usuario, el plan de verificacin, los procedimientos de mantenimiento, y las instrucciones de instalacin y entrenamiento, ms el costo de modificar y corregir la Definicin del sistema, el Plan del proyecto, la Especificacin de requisitos para la produccin de software, la Especificacin del diseo, y el Plan de verificacin; ms el costo de verificacin de que la instrumentacin est completa y sea consistente con respecto a la Definicin del sistema, la Especificacin de requisitos para la produccin de software y los documentos del diseo. El costo de las pruebas del sistema incluye el costo de planear y llevar a cabo las pruebas, ms el costo de las modificaciones al cdigo fuente y a los documentos externos durante ellas, ms el costo de verificacin de que las pruebas validan adecuadamente al producto. Por ltimo, el costo del mantenimiento es la suma de los costos de llevar a cabo mejoras al sistema, hacer adaptaciones para nuevas condiciones de operacin, y encontrar fallas. Cada una de estas actividades puede comprender la modificacin de alguno o de todos los documentos y la ejecucin de un gran numero de casos de prueba para verificar la correccin de la modificacin. Dado este punto de vista del ciclo de vida de un producto, no es difcil entender por qu es tan caro efectuar modificaciones o correcciones a la Especificacin de requisitos e para la produccin de software o documentos del diseo cuando se estn en fases posteriores. No slo se deben modificar los documentos, sino que todos los productos intermedios deben actualizarse, y en cada fase siguiente se necesitan coordinar ms gente y mas detalles. La figura 15 ilustra el costo relativo de hacer un cambio en funcin de la fase en la que el cambio se hace (B0E7). Obsrvese que es prcticamente 100 veces ms costoso hacer un cambio a los requisitos durante la prueba del sistema que hacerlo durante su definicin, y que la figura 15 se presenta con una escala semilogartmica, por lo que la lnea recta indica un crecimiento exponencial en el costo. Figura 15:Costo relativo para realizar un cambio.

21

1 Seccin 1: Definicin del problema. Seccin 2: Justificacin del problema. Seccin 3: Metas del sistema y del proyecto. Seccin 4: Restricciones del sistema y del proyecto. Seccin 5: Funciones que se proporcionarn (equipo / programacin / personal). Seccin 6: Caractersticas del usuario. Seccin 7: Ambientes de desarrollo / operacin / mantenimiento. Seccin 8: Estrategia de solucin. Seccin 9: Prioridades para las caractersticas del sistema. Seccin 10: Criterios de aceptacin del sistema. Seccin 11: Fuentes de informacin. Seccin 12: Glosario de trminos. Seccin 1: Modelo del ciclo de vida. Terminologa / logros / productos finales. Seccin 2: Estructura organizacional. Estructura de administracin / de equipos / de distribucin de trabajo / definicin de puestos. Seccin 3: Requisitos preliminares de personal y recursos. Programacin de personal y recursos. Seccin 4: Programacin preliminar del desarrollo. Redes PERT / Grficas de Gantt. Seccin 5: Estimado preliminar de costos. Seccin 6: Mecanismos de supervisin y control del proyecto. Seccin 7: Herramientas y tcnicas que se emplearn. Seccin 8: Lenguajes de programacin.

22

Seccin 9: Requisitos de pruebas. Seccin 10: Documentos de apoyo necesarios. Seccin 11: Formas de demostracin y entrega. Seccin 12: Programacin de entrenamiento y materiales. Seccin 13: Plan de instalacin. Seccin 14: Consideraciones de mantenimiento. Seccin 15: Mtodo y tiempo de la entrega final. Seccin 16: Mtodo y tiempo del pago. Seccin 17: Fuentes de informacin. Es un modelo del comportamiento del sistema que puede ser usado para entenderlo completamente o ciertos aspectos de l y as clarificar los requerimientos... Un prototipo es una representacin de un sistema, aunque no es un sistema completo, posee las caractersticas del sistema final o parte de ellas"

23

24

25