La Ingeniería de Software surge como la aplicación de modelos y formas de la ingeniería tradicional a la práctica de construir productos de software; situación que ha condicionado su accionar al tener como norte las precisiones y seguridades que en otros ámbitos tiene la ingeniería.
Históricamente han surgido varios enfoques que buscan abordar de manera sistemática, la planificación, análisis, diseño e implementación de los proyectos de desarrollo de software, sean estos de gran escala y pequeñas aplicaciones, software a la medida o productos de software. Cada uno de estos enfoques tiene su raíz en las pre-concepciones dominantes en su época y, sobre todo, en la búsqueda incesante de mejoras a los enfoques precedentes.
Debido a que este documento es una reseña bibliográfica, comenzaremos presentando a los autores de los conceptos a desarrollar en este trabajo
II. El modelo de codificar y fijar
Gustavo Donoso:
El modelo básico usado en los primeros días del desarrollo de software, tiene dos pasos:
(1) Escribir algún código.
(2) Fijar los problemas en el código.
Así, el orden de los pasos era fabricar algún código primero y pensar sobre los requerimientos, diseño, prueba y mantención a continuación. Este modelo tiene las dificultades de presentar una baja estructuración del código luego de alguna cantidad de fijaciones, pese a que se puede desarrollar un software de calidad, es 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 método resume las características de los métodos más formales desarrollados posteriormente, primero, la desvinculación con el problema: hay, de partida dos interlocutores, un experto en la programación o codificación y, por otro lado, un usuario quien sería el experto en el problema a quien se debe satisfacer mediante la codificación de la solución, o programa. Lo anterior nos lleva, también, a la idea de iteración: esta desvinculación entre el origen del problema y la solución imprime en los métodos posteriores la idea de retroalimentaciones que permitan aproximar la distancia entre los ámbitos.
En el sentido real, el ingeniero de programación crea modelos de situaciones físicas en un programa. La correspondencia entre el modelo y la realidad modelada se ha considerado como la distancia entre el problema y la solución computacional del problema. Un principio fundamental de la ingeniería de programación es diseñar productos que minimicen la distancia intelectual entre el problema y la solución.
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 evolución con relación a los métodos es el resultado de las deficiencias presentadas por método de codificar y fijar. Es necesario dividir este ciclo desarrollo en etapas, lo que permitiría incorporar la idea de proyecto de desarrollo de software y, sobre todo, elementos de planificación, coordinación y control. Esto también coincide con el tamaño 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 Semi-Automated Ground Environment (SAGE) hizo que se reconocieran los problemas inherentes a la codificación 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:
El modelo de etapas consideraba que cada una de ellas debería ir a continuación de la anterior, poniendo énfasis en la documentación que resulta de cada una y que es la entrada de la siguiente, formalizando los procedimientos de planificación y de control. Todo tendiente a conformar una cadena de producción de software, de manera similar a una cadena de montaje de automóviles.
Pero ello no logra que las causas de fondo que hicieron que se replantease el modelo de codificar y fijar desapareciesen. Todavía existe la distancia entre el programador (ahora desarrollador) y el usuario, esta distancia está dada por dominios de acción distintos. La iteración de aproximación es ahora más factible, pero también resulta onerosa, es necesario instalar todo el software nuevamente en la cadena de montaje para su revisión y reconstrucción.
Figura 1: Modelo de Etapas
Richard Fairley:
El modelo de fases divide el ciclo de vida del producto de programación en una serie de actividades sucesivas; cada fase requiere información 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 efectúa mediante la aplicación de métodos explícitos, herramientas y técnicas.
Se considera el modelo de fases compuesto por las siguientes: análisis, diseño, instrumentación, 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 programación
El análisis consta de dos subfases: planeación y definición de requisitos. Los productos de la planeación son la Definición del Sistema y el Plan del Proyecto. La Definición, por lo regular, se expresa en español o en algún otro lenguaje natural, y puede contener cuadros, figuras, gráficas y ecuaciones de distintos estilos. La notación exacta empleada en la Definición depende mucho del área del problema. Obviamente, en un sistema de contabilidad se usa diferente terminología que en uno de control de procesos. El formato de la Definición del Sistema se presenta en la figura 3.
Figura 3: Formato de la definición del sistema
El Plan del Proyecto contiene el modelo de ciclo de vida que se utilizará, la estructura organizacional del proyecto, la programación preliminar del desarrollo, estimados preliminares de costos y recursos, así como de personal, herramientas y técnicas que se emplearán, y estándares que se seguirán Los elementos que se deben incluir en el Plan del Proyecto se listan en la figura 4.
Durante la fase de planeación los estimados de costos y la programación del trabajo serán preliminares, puesto que usualmente no es posible realizar estimaciones precisas sin haber realizado algo del diseño, los estimados de costos son, por lo tanto, inevitablemente preliminares. Las prácticas actuales de contratación requieren que el costo total y la programación se proporcionen durante la fase de planeación. Esta situación, 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 programación.
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 programación. Reconociendo esta realidad, muchas organizaciones utilizan una serie sucesiva de estimaciones de costos y programación. Los estimativos preliminares se preparan durante la fase de planeación, su redefinici6n se presenta en la revisión preliminar del diseño; el costo y la programación finales se establecen en la revisión final del diseño. 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 negociarán un producto para que sea eficiente en términos de costo.
Figura 4: Formato del Plan del Proyecto
La definición de requisitos se refiere a la identificación de las funciones básicas del componente de programación en un sistema de equipo/personal/programación. Se pone atención en las funciones y restricciones bajo las cuales se deben desarrollar. La decisión de cómo se instrumentara la programación se retrasa hasta la fase de diseño. El producto de la definici6n de requisitos, es una especificación que describe el ambiente de procesamiento, las funciones requeridas de los programas, restricciones de configuraci6n sobre los programas (tamaño, 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 diseño de la programación viene después del análisis. El diseño se refiere a la identificaci6n de los componentes de la programación (funciones, flujos de datos, y almacenamientos), especificando las relaciones entre ellos, la estructura de la programación, y manteniendo un registro de las decisiones, proporcionando un documento base para la instrumentaci6n. El diseño se divide en estructural y detallado.
El diseño estructural comprende la identificación de los componentes de la programación, su desacoplamiento y descomposici6n en módulos de procesamiento y estructuras de datos conceptuales, y la especificación de las interconexiones entre componentes. El diseño detallado se refiere a detalles de cómo: cómo empacar módulos de procesamiento, y cómo instrumentar los algoritmos, las estructuras de datos y sus interconexiones.
Este diseño se relaciona con la adaptación de código existente, modificación de algoritmos estándar, invención de nuevos algoritmos, diseño de representaciones de datos, e integración del producto final. Diseño detallado no es igual que instrumentación. El primero está muy influido por el lenguaje de programación; pero no tiene que ver con aspectos sintácticos del mismo o con un nivel de detalle como evaluación de expresiones y estatutos de asignación.
La fase de instrumentación en el desarrollo del producto incluye La traducción de las especificaciones del diseño en código fuente, así como su depuración, documentación y pruebas. Los lenguajes de programación modernos proporcionan muchas características para mejorar la calidad del código fuente, como elementos estructurados, tipos de datos predefinidos o definidos por el usuario, verificación de tipos, reglas flexibles de cobertura, mecanismos para manejo de excepciones, elementos concurrentes, y módulos con compilación separada. Algunas de estas características se pueden simular en los lenguajes primitivos, mediante un estilo disciplinado de programación.
Los errores descubiertos durante la fase de instrumentación pueden ser errores en las interfaces de datos entre rutinas, errores lógicos en los algoritmos, errores en las estructuras de datos, y de falta de consideración de casos de procesamiento. Además, el código fuente puede contener: errores de requisitos, que indican alguna omisión de las necesidades del usuario en el documento de requisitos; errores de diseño, que reflejarán una mala traducción de requisitos en especificaciones y, por ultimo, errores de instrumentación debidos a una mala traducción de especificaciones en código fuente. Una de las metas principales del modelo de fases para el desarrollo de productos de programación es la eliminación de errores de requisitos y diseño, antes de iniciada la instrumentación. Como se estudiará, es muy caro eliminar errores del análisis y el diseño del código fuente durante la instrumentación y las pruebas.
Las pruebas del sistema comprenden dos tipos de actividades: pruebas de integración y de aceptación. El desarrollo de una estrategia para integrar los componentes de un sistema de programación, en una unidad funcional, requiere una planeación cuidadosa de modo que se disponga de los módulos cuando estos se necesiten. Las pruebas de aceptación se relacionan con a planeación y ejecución de varios tipos de pruebas para demostrar que el sistema de programación instrumentado satisface las necesidades establecidas en el documento de requisitos.
Una vez aceptado por el cliente, el sistema de programación se entrega para operación y se inicia la fase de mantenimiento del modelo de ciclo de vida por fases. Las actividades de mantenimiento incluyen mejoras de las capacidades, adaptación a nuevos ambientes de procesamiento, y corrección de fallas del sistema.
El modelo de fases del ciclo de vida de desarrollo de productos de programación presentado en la figura 1 es simplista, no existen logros en el modelo, ni se mencionan los documentos generados, ni las revisiones que se efectúan 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; sólo se hace una indicaci6n somera de la verificación constante de los productos durante el ciclo de vida. El proceso de desarrollo no es lineal.
El desarrollo de productos de programación nunca se lleva a cabo como una sucesión 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 representación simple de dos dimensiones. Sin embargo, el modelo de fases del ciclo de vida es válido para el proceso de desarrollo en situaciones donde es posible redactar un conjunto razonablemente completo de especificaciones para el producto de programación, 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 también conocido como “Modelo en cascada” o “Modelo lineal secuencial” o “Ciclo de vida básico” o “Ciclo de vida clásico”.
Es un refinamiento altamente influenciado para 1970 del modelo de etapas. Existe, para este modelo, un reconocimiento de los ciclos de retroalimentación entre etapas, y una guía para confinar las retroalimentaciones a las etapas sucesivas con el objetivo de minimizar el costo del retrabajo involucrado en retroalimentaciones a través de muchas etapas.
Las ventajas que presentan tanto el modelo de etapas y de cascada tiene relación 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 cooperación entre ellas. Corresponden, también, a los métodos más usados en desarrollo de software y que han sido exitosos durante décadas tanto en el desarrollo de grandes sistemas como en el de pequeños.
Tanto el modelo de etapas como el de cascada, presentan algunas dificultades comunes. Por ejemplo, la especificación de los problemas. Ambos métodos asumen que el diseñador puede distinguir entre lo que el sistema debe hacer y como el sistema lo hará; pero algunos problemas no pueden ser divididos tan fácilmente 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 están familiarizados con la tecnología, con lo cual producen requerimientos muy vagos, que son interpretados arbitrariamente por los desarrolladores.
Otro factor importante es que estos métodos asumen que una vez que los requerimientos han sido definidos entonces ellos no cambiarán más. Pero, dependiendo de la complejidad del proyecto, la implementación final puede ocurrir meses o, eventualmente, años después de que los requerimientos han sido especificados; así, en las últimas etapas del proyecto, los requerimientos pueden haber cambiado.
Existiría un énfasis en la elaboración 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 páginas, explicando todos u cada uno de los detalles del sistema. Y es difícil poder visualizar a priori, desde éste volumen de papel, las características del sistema.
Por último, se ha detectado que el enfoque lineal de estos métodos no sería el adecuado para reflejar el proceso de desarrollo de software. Esto explica que se diga que para algunos proyectos el modelo clásico los lleva a seguir las etapas en orden incorrecto. Más aún, es posible que todas las etapas del proyecto, estén comprimidas dentro de cada una.
Como se ha podido observar, la especificación de métodos más acabados para el desarrollo de software no logra superar el problema de la distancia entre la visión del usuario y la del desarrollador, ya que no se ha buscado resolver ese problema, sino que las soluciones se centraron principalmente en la división 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 párrafo anterior, en que no todos los problemas podrían ser abordados desde una misma perspectiva de orden en las etapas.
Figura 5: Modelo de Cascada
Eduardo Cohen:
Problemas:
1. No siempre se sigue el flujo secuencial.
2. Es difícil tener un 100% de los requisitos al inicio.
3. El cliente debe tener paciencia. Los primeros resultados serán hasta que ya este operando el sistema.
Figura 6: El ciclo de vida clásico
Norris & Rigby:
El ciclo de vida proporciona un modelo conveniente que sirve para dos propósitos. En primer lugar, permite representar los procesos deconcepción y producción en una forma gráfica y lógica, 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 través de la operación es un proceso involuntario. Es decir, se produce mediante etapas sucesivas de especificación, diseño y modificación. Cada evaluación de una parte del software - se hace por una revisión de la documentación que describe los requerimientos, especificación, diseño o, después, por pruebas al código y área usada del sistema realizado - da como resultado cambios. Idealmente, el proceso de desarrollo debe involucrar gradas sucesivas de especificación y diseño 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 retroalimentación ascendente para proporcionar verificación contra etapas previas así como una validación final de los requerimientos.
Aunque no es su intención ser una representación perfecta de lo que ocurre en realidad, este modelo ha tenido un uso muy difundido durante 15 años. Esto se explica aquí con detalle para dar un sentido de lo que se describe en un modelo de ciclo de vida y cómo puede ayudar a controlar el proceso de desarrollo de software.
La primera etapa en este modelo es la definición de requerimientos. Esta es, invariablemente, la primera etapa de cualquier proceso orientado al problema y es en muchos casos la más difícil de lograr. En el siguiente capitulo se analizan las razones detrás de esto. Por ahora, tan sólo estableceremos que el problema radica en La comunicación entre el cliente y el desarrollador. El primero no esta siempre en posición de definir con precisión lo que se requiere; como resultado, el segundo por lo general tiene gran dificultad para producir una especificación con el detalle suficiente que permita asegurar La traducción de los requerimientos para el diseño.
Figura 7: El ciclo de vida cascada
Aún en casos donde el cliente y el diseñador construyen Un conjunto preciso de requerimientos, las tendencias del acto del desarrollo concreto del sistema dan como resultado La modificación de La percepción original del cliente de lo que se necesita al final. La etapa de requerimientos puede compararse con la preparación de un documento legal. Se transforma lo mas preciso, lo mas difícil es entenderlo. Si se omite La precisión, entonces La libertad para La ambigüedad 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 diseño y por lo general necesita que el desarrollador responda a los requerimientos establecidos con alguna forma de especificación 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 definición 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 repetición de diseño de alguna forma. En el nivel más alto, un diseño de sistema establecido es el que permitirá la separación de los componentes del software de los que no lo son y la definición de la interfaz entre ellos. Muy a menudo un diseño de arquitectura será generado para establecer un marco de trabajo. Entonces, el diseño del software se lleva a cabo mediante el uso de una metodología "hacia abajo" determinada. He aquí que el mayor efecto sobre la calidad puede verse dado que la calidad de diseño, a largo plazo, determinará la calidad final del producto. El nivel más bajo del diseño de software proporcionará la base para la codificación y definirá con amplitud la estructura de los programas. En las iteraciones a lo largo del diseño, el problema general debe ser dividido lo suficiente para dejar sólo dificultades menores para el programador. En la práctica, este rara vez es el caso y algunas decisiones de diseño tomadas en una etapa anterior no pueden implantarse. En tales casos, es necesario recurrir al rediseño y repetir hasta que el problema sea solucionado.
La siguiente etapa mayor en el modelo cascada es la concerniente a la prueba del código diseñado. Esta actividad tiene lugar a varios niveles. En el nivel mas bajo, los programadores deben probar su propio código fuente por separado de otras partes del sistema. Una vez que sean consistentes consigo mismos, los módulos probados pueden presentarse para la integración del sistema del cual son parte. Conforme los progresos de integración 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 demostración del sistema que se desarrolla como se especificó originalmente y también para detectar puntos de mal entendido en la interpretación de los requerimientos originales.
La prueba de aceptación por lo general se concreta a demostrar los aspectos funcionales del producto. En realidad, es la entrega y operación La que casi siempre revela el grado en que el producto satisface los requerimientos del cliente.
Por último, una prueba de aceptación 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 evolución del sistema posterior a la entrega se considere como parte del ciclo de vida del mismo, justo antes de ser obsoleto. De manera típica, los sistemas de software están más en servicio que en desarrollo (el software para el cambio telefónico tuvo una vida de diseño de 20 años. 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 varía de un proyecto a otro. En la figura 8 se dan algunas cifras representativas para la proporción y esfuerzo en las actividades y para su fase.
Figura 8: Proporción típica 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 retroalimentación dentro de el son muchas y, por ende, proporciona lo que el desarrollador del sistema desea; la propagación de fallas puede prevenirse en gran medida por la detección y verificación de las actividades en cada etapa.
Hay, por supuesto, algunas deficiencias en el modelo cascada: la distri-bución de las actividades no es secuencial, como la descrita, no reconoce el desarrollo a través 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 clásico (Boehm, 1988), es también posible verlo como un método independiente.
Una definición de un prototipo en software podría ser:
Las fases que comprende el método de desarrollo orientado a prototipos serían:
La fase más importante corresponde a la definición de requerimientos, la cual correspondería a un proceso que busca aproximar las visiones del usuario y del desarrollador mediante sucesivas iteraciones. La definición de requerimientos consiste de cinco etapas entre dos de las cuales se establece un ciclo iterativo:
En la siguiente figura se puede ver un esquema en que estas etapas se realizan, note que la especificación de requerimientos está claramente diferenciada de las demás. Es en ella donde se utiliza el prototipado, ya que permite entregar al usuario lo que sería una visión la solución final en etapas tempranas del desarrollo, reduciendo tempranamente los costos de especificaciones erróneas.
Figura 9: Modelo de desarrollo orientado a prototipos
Las ventajas de un enfoque de desarrollo orientado a prototipos están dadas por: reducción de la incertidumbre y del riesgo, reducción de tiempo y de costos, incrementos en la aceptación del nuevo sistema, mejoras en la administración de proyectos, mejoras en la comunicación entre desarrolladores y clientes, etc.
Si bien, el desarrollo orientado a prototipos tiene considerables ventajas, también presenta desventajas como: la dependencia de las herramientas de software para el éxito ya que la necesidad de disminución de incertidumbre depende de las iteraciones del prototipo, entre más iteraciones existan mejor y esto último se logra mediante el uso de mejores herramientas lo que hace a este proceso dependiente de las mismas. También, no es posible aplicar la metodología a todos los proyectos de software y, finalmente, la mala interpretación que pueden hacer los usuarios del prototipo, al cual pueden confundir con el sistema terminado.
No se puede desconocer que la fase de definición 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 común de comunicación; también, el hacer explícita la posibilidad de iterar sobre estos dominios permitiría 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 iteración sea en la dirección 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 definición 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 explotación.
Por último, el proceso de iteración para que sea efectivo debería ser infinito, lo que lo hace poco efectivo. Es decir, mediante este método acercamos la problemática de los usuarios a los dominios de los desarrolladores y viceversa, pero no sería posible lograr un pareamiento uno a uno entre estos dominios, lo que sería el ideal.
Richard Fairley:
Otra visión del desarrollo y mantenimiento de un producto de programación 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 representación o modelo del producto de programación que, a diferencia de un modelo de simulación, 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 diálogos al cliente, este es un mecanismo adecuado para explicar opciones de procesamiento y tener un mejor entendimiento de las necesidades de él.
La segunda razón es para explorar aspectos técnicos del producto propuesto. Con frecuencia, una decisión importante del diseño dependerá., por ejemplo, del tiempo de respuesta del controlador de un dispositivo o de la eficiencia de un algoritmo de clasificación; en tales casos, un prototipo puede ser la mejor o única manera de resolver el problema.
La tercera razón para desarrollar un prototipo s da cuando el modelo de fases análisis -> diseño -> instrumentación 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 evalúa una versión. El desarrollo exploratorio se utiliza para desarrollar algoritmos para jugar ajedrez, para resolver problemas confusos, y para llevar a cabo tareas que requieren la simulación del comportamiento humano; sin embargo, esta técnica no se limita a estas situaciones (SEN82).
La naturaleza y extensión del prototipo por desarrollar en un proyecto de programación depende de la naturaleza del producto. Se pueden desarrollar nuevas versiones de un producto ya existente con el modelo de fases y sin ningún prototipo. El avance de un producto totalmente nuevo, tal vez requiera de prototipo durante las fases de planeación y análisis, o el producto se puede desarrollar como una serie de diseños 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 metodología 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 producción flexible y expandible. Así, si los requerimientos cambian durante el desarrollo del sistema, entonces con un mínimo 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 tendría la propiedad de satisfacer los nuevos requerimientos lo más rápido posible. En contraste, prototipos usa un enfoque iterativo solo para determinar los requerimientos organizacionales. Por lo tanto el tiempo tomado entre cada iteración es mucho más importante para el desarrollo evolutivo. En la figura 10 se puede ver gráficamente esta diferencia.
El desarrollo evolutivo asume que los requerimientos de un proyecto están sujetos a cambios continuos, por lo cual es necesario definir una estrategia de desarrollo que refleje esta situación. 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 metodología de desarrollo evolutivo es estar liberando constantemente una nueva versión del sistema que sea completamente funcional; así, cada sistema producto de las iteraciones sucesivas del método tendría incorporado los nuevos requerimientos que ha sido posible identificar y que no estarían considerados en la anterior versión.
Así, las etapas del desarrollo evolutivo tienen por objetivo extender los incrementos de un producto de software operacional, en las direcciones determinadas por la evolución de la experiencia operacional.
El modelo de desarrollo evolutivo puede ser idealmente asociado a un lenguaje de aplicación de cuarta generación y mejor aún a situaciones en que el usuario dice, "yo no puedo hablarte sobre lo que yo quiero, pero yo lo reconocería si lo viese". Así, este método entregaría al usuario rápidamente una capacidad operativa inicial y, además, establecería una base real operación para determinar las mejoras subsecuentes en el producto.
Pero, existirían algunas dificultades técnicas que no pueden dejar de ser mencionadas, por ejemplo:
- No facilita la integración de aplicaciones que han sido desarrolladas como sistemas independientes.
- Facilita la posibilidad de que existan casos de "esclerosis de información", en el sentido que trabajos temporales alrededor de algunas deficiencias del software se solidifican como poderes inmodificables a la evolución. Es decir, en la medida que se evoluciona, esta misma facilidad a la evolución llevaría 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 hacer que la nueva versión se acople con facilidad al resto.
El método evolutivo tiene la gran ventaja de reconocer la existencia de una constante de cambios en los requerimientos y, desde esta premisa, propone una solución, la cual es válida para la solución de ese problema pero que no resolvería la inquietud original, esto es que el método no facilita elementos que permitan reducir la distancia conceptual entre los dominios del desarrollador y del usuario.
Con la existencia del método evolutivo se configura una nueva problemática en el desarrollo de sistemas, es decir, la crisis se expande ahora en el sentido que no sólo se requiere reflejar lo más fielmente posible las necesidades del usuario, sino que ahora los ambientes en que el sistema está inserto están 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 década de los ochenta, al definir las leyes de la evolución del software, en que las dos primeras leyes tienen directa relación con lo que se describe. Veamos a Lehman citado por Ian Sommerville, en el libro Ingeniería de Software:
Lehman propone que la evolución 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 evolución de los programas:
Sommerville considera las "leyes" de Lehman como elementos positivos en la configuración del ámbito en que se desarrollan los sistemas, por ejemplo, dice que las dos primeras hipótesis de Lehman son casi con certeza válidas. 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 algún ambiente y después se introduce en él, modificándose así el ambiente original con la presencia del sistema de software... No puede ser más interesante para los propósitos de esta revisión la característica planteada por esta hipótesis, es decir, si se desarrolla software no se podría pensar desde la perspectiva de estabilidades, todo lo contrario, necesariamente es el cambio el motor y el configurador de los sistemas de software. Aquí el punto es la introducción 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, además de la distancia conceptual entre desarrollador y usuario, existiría el problema de la evolución constante de la organizaciones o, más claramente, la connaturalidad de las organizaciones al cambio como elemento subyacente en su ser organizacional. Situación que se había anticipado en el curso de "Ambientes..."
La segunda ley en el análisis 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 más compleja ya que al ir incrementándose la distancia conceptual entre el software y el medio que lo contiene, éste va estando cada vez más presente en el hacer cotidiano, formulando quiebres constantes sobre el sistema de trabajo lo que imprime un sello de complejidad a la utilización del software.
Las siguientes leyes tienen relación con las características 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 drásticos o repentinos. Por tanto, a medida que se añaden más recursos a un proyecto de software, el efecto evolutivo de la adición de nuevos recursos se va reduciendo, hasta que la adición de nuevos recursos no produce ningún efecto. Si bien, estas últimas leyes no resultan tan obvias como las primeras y podrían ser cuestionadas, es posible que la última, que tiene que ver con la conservación de la familiaridad sea la más útil, como también la de reducción de personal, en el sentido que cuanta más gente trabaje, menos productivo será cada miembro del proyecto.
Las proposiciones de Lehman se orientaron a la creación de un método de desarrollo que considerase estas características.
Richard Fairley:
El desarrollo de productos mediante el método de versiones sucesivas es una extensión del método de prototipos en el que se refina un esqueleto inicial del producto obteniendo así, cada vez más capacidades. En dicho me todo, cada versión es un sistema funcional y capaz de realizar trabajo útil. La figura 12a ilustra la fase de análisis seguida por el diseño de instrumentación de versiones sucesivas en un proceso iterativo. Las líneas punteadas indican que al conseguir la versión I puede necesitarse más análisis antes de diseñar la versión I+1.
En la figura 12b las versiones 1 a la N del producto se diseñan antes de cualquier actividad de instrumentación. En este caso, las características de cada diseño sucesivo serán planeadas durante la fase de análisis. Las líneas punteadas de la figura 12b indican que la instrumentación de la 1-esima versión puede demostrar la necesidad de mayor análisis y diseño antes de la puesta en marcha de la versión 1+1. El método de versiones sucesivas es similar, peto no idéntico al de mejoras iterativas (BAS75).
En realidad, el ciclo de desarrollo de un producto de programación es una combinación 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 programación. Por ejemplo, para proyectos de desarrollo de programación no es extraño adoptar el modelo de fases como marco de referencia básico, e incluir prototipos y versiones sucesivas en el desarrollo.
VII. El modelo de transformación
Gustavo Donoso:
Desde la perspectiva de la evolución del software y las leyes de Lehman, se hace una revisión del ciclo de vida del software, el cual lleva al desarrollo de un método que se podría denominar el modelo de transformación.
Desde la óptica de lan Sommerville, este modelo se caracteriza por que... un concepto de aplicación se transforma de modo paulatino en una especificación formal de software. Esto implica la reducción de la cantidad de información bruta en cada etapa de la transformación, proceso que el denomina abstracción. Una vez establecida la especificación, se añade la información (a esto le llama materialización) y el sistema abstracto se transforma, mediante un conjunto de notaciones formales, en un programa operacional.
Las bases de una concepción de transformación en el desarrollo de software, las explica el mismo Lehman (1980). Al considerar una clasificación de los programas y, mediante ésta, definir un método sistemático que permita transformar programas de una clase más compleja en otra de complejidad menor.
La clasificación ...está basada en el reconocimiento de el hecho que,..., cualquier programa es un modelo de un modelo dentro de una teoría de un modelo de una abstracción de alguna porción del mundo o de algún universo del discurso. La clasificación categoriza a los programas en tres clases, S, P y E....
- Programas-S.
- Programas - PE
- Programas - E.
Los programas-S son siempre probablemente correctos... muchos de los componentes más importantes de un gran programa son del tipo S... un Programa-A puede siempre ser particionado y estructurado de manera que todos sus elementos sean Programas-S.
Meir Lehmann, Program, Life Cycles, and..., ACM Proceeding, 1980, p.
En esta última afirmación esta el trasfondo de la idea de Lehman en relación a la posibilidad de definir un metalenguaje que permita reducir programas complejos o "del mundo real" a especificaciones formales de programas. Así, según Boehm:
...el modelo de transformación asume la existencia de una capacidad de automáticamente convertir una especificación formal de un producto de software en un programa que satisfaga la especificación.
Los pasos que son prescritos por el modelo de transformación son:
- una especificación formal de la mejor comprensión inicial del producto deseado.
- transformación automática de la especificación en código.
- un ciclo iterativo, si es necesario, para mejorar la ejecución de el código resultante para dar una guía de optimización al sistema de transformación.
- 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 transformación evita las dificultades de tener que modificar un código que tiene una estructuración muy pobre - debido a las repetidas optimizaciones -, mediante la posibilidad de que las modificaciones sean fabricadas a través de las especificaciones, esto sin intervenir el código, el cual se reconstruiría cada vez.
Con este modelo se puede aumentar, al menos teóricamente, la capacidad de dar respuesta rápida a la evolución que connaturalmente estaría 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 cómo acortar la brecha conceptual entre los dominios del desarrollador y del usuario, si es que es posible.
En relación a este último y central problema, la crítica que se puede hacer al modelo de transformación es que necesariamente al transformar un problema del tipo A en problemas - S, se está aplicando un reduccionismo que, probablemente, limite la expresión de toda la complejidad del problema original, particularizando la solución a casos en que sea dable resolver sistemáticamente y dejando fuera situaciones en que esta formalización no sea posible. En ese sentido, no sería factible que todos los problemas - A sean transformables a unidades S. Además, esto no evita la necesidad de tener que caracterizar un problema del tipo A, lo que remitiría necesariamente a la cuestión original.
VIII. Modelo Espiral
Gustavo Donoso:
El modelo Espiral de Boehm para Ingeniería de Software agrupa las mejores características del modelo del ciclo de vida clásico y de prototipos. Pero también agrega nuevas funciones que no están incluidas en los otros modelos, como el análisis de riesgo. El modelo espiral define cuatro actividades principales para el ciclo de vida.
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 iteración comienza en el centro del círculo e, incrementalmente, se va desplazando hacia afuera. Las siguientes iteraciones sucesivas son versiones más completas del software que está siendo construido. Al principio de cada iteración del ciclo de vida se hace un análisis de riesgo, mientras, por el otro extremo, la revisión del proyecto se realiza al final de la iteración. Así, se puede contrarrestar cualquier riesgo observado mediante las acciones adecuadas en el tiempo preciso.
El modelo espiral es visto como un enfoque más realista para el desarrollo de grandes sistemas de software. Usa un método evolucionario para desarrollo y prototipos como una técnica de reducción de riesgo (pese a que los prototipos pueden ser usados en cualquier etapa dentro del ciclo de vida). También utiliza el enfoque de sistematización y el 'desarrollo en etapas' del ciclo de vida clásico, pero, con la diferencia que todos están incorporados dentro del esquema iterativo planteado por el modelo espiral.
Norris & Rigby:
Este modelo reconoce la necesidad de la revisión 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:
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 atención 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 aún muy claros, cuando se despliega nueva tecnología 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 (después de Boehm)
Checkland desarrolla la metodología de sistemas "soft" en respuesta a las fallas de los enfoques más 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 técnicas usadas en resolver problemas más formales.
Las metodologías tradicionales para análisis de sistemas asumen que el problema (como ellos lo definen) tiene una solución definitiva y un numero de metas que pueden ser satisfechas. Es decir es factible en estas situaciones hacerse la pregunta: ¿Cómo se resuelve el problema?.
La metodología de sistemas "soft" considera el término "el problema" como inapropiado, considera que es una visión errada de la situación. Los sistemas "soft" reconocen que no existe un problema, pero si muchos problemas, lo que se describe como una "situación problema". El énfasis es puesto más sobre la caracterización del problema que sobre como se resuelve, en este caso es válida la pregunta: ¿cuál es el problema?. Así, las metas del sistema "soft" son mucho más complejas que las metas de los sistemas tradicionales que pueden ser alcanzadas y medidas.
El proceso involucrado en la metodología de sistemas "soft" es el siguiente:
"... una descripción concisa y ajustada de un sistema de actividad humana que presenta qué es el sistema."
La definición raíz es creada usando una lista de chequeo llamada el criterio CATWOE (Clients, Actors, Transformations, WorldView, Owner, Environment). Que por orden de importancia debería ser TWECOA. Ellos determinan quién está haciendo qué para quienes, y a quienes ellos están preguntando. Qué supuestos están siendo usados y en qué medio ambiente está sucediendo todo aquello. Una descripción general de cada uno de estos elementos puede ser la siguiente:
| Cliente | Todos aquellos beneficiados o afectados por las salidas del sistema. |
| Actor | El agente de cambio que llevará afuera el proceso de transformación. |
| Transformación | Los cambios que tienen lugar dentro o por causa del sistema. |
| Visión de Mundo | Cómo el sistema es percibido desde un punto de vista particular. Son las presunciones que tienen los miembros de, dueños o clientes de la organización. |
| Dueño | Es a quien el sistema le pregunta y/o quién puede causar que deje de existir. |
| Medio Ambiente | El mundo que envuelve e influencia al sistema, pero que no tiene control sobre él. |
4. Cuando los dueños y los solucionadores del problema estén satisfechos en que las definiciones raíz están bien formadas, se crea un modelo conceptual. Este describe en forma gráfica que es lo que el sistema hará. El modelo conceptual tomará en cuenta todas las definiciones raíz consideradas.
5. El modelo conceptual es usado como la base de todos los cambios hechos por el sistema para eliminar los problemas.
Como esta metodología no considera cualquier procedimiento preconcebido, el análisis es mucho mejor y permite un mejor entendimiento del problema.
X. El método 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:
- Pragmática
- Entrada/Salida
- Constructiva
- Operativa
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 pragmática como el nivel mas abstracto. En esta fase, el sistema se estudia en términos de su relación con y su efecto en el ambiente en el que va a ser colocado. El modelo necesita que el diseño, 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 programación es la consideración del costo de la realización de las distintas actividades del proyecto. El costo de un proyecto es la suma de los costos incurridos en cada fase, y éstos, a su vez, incluyen los costos de la realización de los procesos y preparación de los documentos de esa fase, más los costos de verificación 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 encontrarán imprecisiones, inconsistencias y omisiones en sus productos y, además, porque los requisitos, programación, prioridades o presupuesto del cliente pueden cambiar, hecho que produciría modificaciones.
El costo de producción de la Definición del sistema y del Plan del proyecto es el mismo de realizar las planeación y preparación de los documentos, más el costo de verificación de que la Definición del sistema establece precisamente las necesidades del cliente y el costo de verificación de que el Plan del proyecto es factible.
El costo de preparación de la Especificación de requisitos para la producción; de software incluye el costo de definir requisitos y preparar documentos, más el costo de modificar y corregir la Definición del sistema y el Plan del proyecto, más el costo de verificación de que la Especificación esté completa y sea consistente con respecto a la Definición del sistema y las necesidades del cliente.
De la misma manera, el costo del diseño es el costo de las actividades propias y la generación de los documentos, más el costo de modificar y corregir la Definición del sistema, el Plan del proyecto y la Especificación de requisitos para la producción de software, más el costo de verificación del diseño contra los requisitos, la Definición del sistema y el Plan del proyecto.
El costo de la instrumentación del producto es el costo de la conversión, documentación, depuración y pruebas del código fuente, más el costo de la terminación del Manual del usuario, el plan de verificación, los procedimientos de mantenimiento, y las instrucciones de instalación y entrenamiento, más el costo de modificar y corregir la Definición del sistema, el Plan del proyecto, la Especificación de requisitos para la producción de software, la Especificación del diseño, y el Plan de verificación; más el costo de verificación de que la instrumentación esté completa y sea consistente con respecto a la Definición del sistema, la Especificación de requisitos para la producción de software y los documentos del diseño.
El costo de las pruebas del sistema incluye el costo de planear y llevar a cabo las pruebas, más el costo de las modificaciones al código fuente y a los documentos externos durante ellas, más el costo de verificación 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 operación, y encontrar fallas. Cada una de estas actividades puede comprender la modificación de alguno o de todos los documentos y la ejecución de un gran numero de casos de prueba para verificar la corrección de la modificación.
Dado este punto de vista del ciclo de vida de un producto, no es difícil entender por qué es tan caro efectuar modificaciones o correcciones a la Especificación de requisitos e para la producción de software o documentos del diseño cuando se están en fases posteriores. No sólo se deben modificar los documentos, sino que todos los productos intermedios deben actualizarse, y en cada fase siguiente se necesitan coordinar más gente y mas detalles. La figura 15 ilustra el costo relativo de hacer un cambio en función de la fase en la que el cambio se hace (B0E7ó). Obsérvese que es prácticamente 100 veces más costoso hacer un cambio a los requisitos durante la prueba del sistema que hacerlo durante su definición, y que la figura 15 se presenta con una escala semilogarítmica, por lo que la línea recta indica un crecimiento exponencial en el costo.
