Modelos de Desarrollo de Software

Revisión Bibliográfica de los Modelos de Desarrollo de Software
I. Introducción
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.
• Autores de libros consultados:
• Marck Norris y Peter Rigby
Ingeniería de Software Explicada
• Richard Fairley
Ingeniería de Software
• Autores de páginas 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 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
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 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:
• Plan operativo
Etapa donde se define el problema a resolver, las metas del proyecto, las metas de calidad y se identifica
cualquier restricción aplicable al proyecto.
• Especificación de requerimientos
Permite entregar una visión de alto nivel sobre el proyecto, poniendo énfasis en la descripción del problema
desde el punto de vista de los clientes y desarrolladores. También se considera la posibilidad de una
planificación de los recursos sobre una escala de tiempos.
• Especificación funcional
Especifica la información sobre la cual el software a desarrollar trabajará.
• Diseño
2
Permite describir como el sistema va a satisfacer los requerimientos. Esta etapa a menudo tiene diferentes
niveles de detalle. Los niveles más altos de detalle generalmente describen los componentes o módulos que
formarán el software a ser producido. Los niveles más bajos, describen, con mucho detalle, cada módulo que
contendrá el sistema.
• Implementación
Aquí es donde el software a ser desarrollado se codifica. Dependiendo del tamaño del proyecto, la
programación puede ser distribuida entre distintos programadores o grupos de programadores. Cada uno se
concentrará en la construcción y prueba de una parte del software, a menudo un subsistema. Las pruebas, en
general, tiene por objetivo asegurar que todas las funciones están correctamente implementadas dentro del
sistema.
• Integración
Es la fase donde todos los subsistemas codificados independientemente se juntan. Cada sección es enlazada
con otra y, entonces, probada. Este proceso se repite hasta que se han agregado todos los módulos y el sistema
se prueba como un todo.
• Validación y verificación
Una vez que el sistema ha sido integrado, comienza esta etapa. Es donde es probado para verificar que el
sistema es consistente con la definición de requerimientos y la especificación funcional. Por otro lado, la
verificación consiste en una serie de actividades que aseguran que el software implementa correctamente una
función específica. Al finalizar esta etapa, el sistema ya puede ser instalado en ambiente de explotación.
• Mantención
La mantención ocurre cuando existe algún problema dentro de un sistema existente, e involucraría la
corrección de errores que no fueron descubiertos en las fases de prueba, mejoras en la implementación 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 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
3
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.
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.
5
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.
6
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:
• Ingeniería y análisis del sistema.
Interrelación con hardware, personas, bases de datos. (Documentar cada paso.)
• Análisis de los requisitos del software.
Hay que comprender el ámbito de la información del software, así como la función, el rendimiento y las
interfases requeridas.
• Diseño.
La estructura de los datos, la arquitectura del sw, el detalle procedimental, y la caracterización de la interfase.
• Codificación.
7
Traducir el diseño para que lo entienda la máquina.
• Prueba.
Cuando ya se ha generado el código.
• Mantenimiento.
El software sufrirá cambios después de que se entregue al cliente.
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.
8
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.
9
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:
• Investigación preliminar
Las metas principales de esta fase son: determinar el problema y su ámbito, la importancia y sus efectos
potenciales sobre la organización por una parte y, por otro lado, identificar una idea general de la solución
para realizar un estudio de factibilidad que determine la factibilidad de una solución software.
• Definición de los requerimientos del sistema
El objetivo de esta etapa es registrar todos los requerimientos y deseos que los usuarios tienen en relación al
proyecto bajo desarrollo. Esta etapa es la más importante de todo el ciclo de vida, es aquí donde el
desarrollador determina los requisitos mediante la construcción, demostración y retroalimentaciones del
prototipo. Por lo mismo esta etapa será revisada con más detalle luego de esta descripción.
• Diseño técnico
Durante la construcción del prototipo, el desarrollador ha obviado el diseño detallado. El sistema debe ser
entonces rediseñado y documentado según los estándares de la organización y para ayudar a las mantenciones
futuras. Esta fase de diseño técnico tiene dos etapas: por un lado, la producción de una documentación de
diseño que especifica y describe la estructura del software, el control de flujo, las interfaces de usuario y las
funciones y, como segunda etapa, la producción de todo lo requerido para promover cualquier mantención
futura del software.
• Programación y prueba
Es donde los cambios identificados en el diseño técnico son implementados y probados para asegurar la
10
corrección y completitud de los mismos con respecto a los requerimientos.
• Operación y mantención
La instalación del sistema en ambiente de explotación, 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. Además, la
mantención también debería ser una fase menos importante, ya que se supone que el refinamiento del
prototipo permitiría una mejor claridad en los requerimientos, por lo cual las mantenciones perfectivas se
reducirían. Si eventualmente se requiriese una mantención entonces el proceso de prototipado es repetido y se
definirá un nuevo conjunto de requerimientos.
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:
• Análisis grueso y especificación
El propósito de esta subfase es desarrollar un diseño básico para el prototipo inicial.
• Diseño y construcción
El objetivo de esta subfase es obtener un prototipo inicial. El desarrollador debe concentrarse en construir un
sistema con la máxima funcionalidad, poniendo énfasis en la interface del usuario.
• Evaluación
Esta etapa tiene dos propósitos: extraer a los usuarios la especificación de los requerimientos adicionales del
sistema y verificar que el prototipo desarrollado lo haya sido en concordancia con la definición de
requerimientos del sistema. Si los usuarios identifican fallas en el prototipo, entonces el desarrollador
simplemente corrige el prototipo antes de la siguiente evaluación. El prototipo es repetidamente modificado y
evaluado hasta que todos los requerimientos del sistema han sido satisfechos. El proceso de evaluación puede
ser dividido en cuatro pasos separados: preparación, demostración, uso del prototipo y discusión de
comentarios. En esta fase se decide si el prototipo es aceptado o modificado.
• Modificación
Esto ocurre cuando la definición de requerimientos del sistema es alterada en la subfase de evaluación. El
desarrollador entonces debe modificar el prototipo de acuerdo a los comentarios hechos por los usuarios.
• Término
Una vez que se ha desarrollado un prototipo estable y completo, es necesario ponerse de acuerdo en relación a
aspectos de calidad y de representación de el sistema.
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
11
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
12
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
13
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:
• 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 evolución cambia, su estructura se hace más compleja, a menos que se lleven a
cabo esfuerzos activos para evitar este fenómeno.
• Evolución del programa.
La evolución del programa es un proceso autorregulador, y una medición de atributos del sistema, como el
tamaño, el tiempo entre versiones, el número de errores advertidos, etc., revela las tendencias estadísticas
significativas y las características invariantes.
• Conservación 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.
• Conservación de la familiaridad.
Durante el tiempo de vida de un sistema, la evolución del cambio del sistema en cada versión es,
aproximadamente, constante.
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,
14
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
15
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.
Los Programa−S son aquellos cuya función puede ser definida formalmente por y derivable desde, una
especificación.... Las sentencias del problema, el programa y la solución, cuando es obtenida, puede
relacionarse con un mundo externo. Pero esto es una relación casual y no causal. En efecto, cuando esto existe
somos libres para cambiar nuestro interés y redefinir el problema. Pero el resultado de esto es un nuevo
programa para esta solución. Puede ser posible y eficiente derivar el nuevo programa desde el antiguo. Pero es
un programa diferente que define una solución para un problema diferente.
• Programas − PE
En los Programas − P (solución de problemas del mundo real)... a despecho de el hecho de que el problema a
ser resuelto pueda ser definido precisamente, la aceptación de la solución está determinada por el medio
ambiente en que está involucrada. La solución obtenida será evaluada por comparación con el medio ambiente
real... En los Programas − S, el juicio sobre la corrección, y por lo tanto el valor, del programa está
relacionado con la definición solamente de esta especificación, 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 solución obtenida, esto es sobre el contexto del mundo real.
• Programas − E.
La tercera clase, los Programas − E, están inherentemente más inclinados al cambio. Estos son programas que
mecanizan una actividad humana o social... La instalación 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 presión del cambio está construida con él.... Los Programas P
y E están estrechamente relacionados, podemos establecer la clase unión de P y E como Programas−A. Éstos
difieren de los Programas−S en el sentido que representan una aplicación computacional en el mundo real.
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.
16
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.
• Planificación
17
La determinación de los objetivos del proyecto, alternativas y restricciones.
• Análisis de Riesgo
El análisis de alternativas y la identificación y solución de riesgos.
• Ingeniería
Desarrollo del producto.
• Evaluación del cliente
El asentimiento de los resultados de la ingeniería.
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:
• 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 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)
18
• Método de Sistemas "Soft"
Gustavo Donoso:
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:
• El analista (en adelante el solucionador del problema), con la ayuda de los administradores y usuarios
dentro de la organización (en adelante el dueño del problema), crean un cuadro de la situación problema. El
cuadro es una percepción subjetiva del problema en un esquema informal. Incluirá sistemas de la
organización bajo revisión, la gente dentro de ello, las tareas ejecutadas, etc. Este cuadro es usado como
ayuda a las discusiones con el o los dueños 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 organización, problemas de comunicación u
otro tipo de problemas que detecte. Este cuadro es utilizado para identificar problemas e informa al dueño
de la situación, antes que se desarrollen posibles soluciones. El uso de este cuadro es mucho mejor que los
métodos tradicionales para estimular a administradores y usuarios para revelar los problemas "reales"
dentro de la organización.
3. Una vez completado el cuadro, el solucionador lo usará para crear una definición raíz. Checkland (1981)
define la definición raíz como:
"... 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
Actor
Transformación
Visión de Mundo
Dueño
Todos aquellos beneficiados o afectados por las salidas del sistema.
El agente de cambio que llevará afuera el proceso de transformación.
Los cambios que tienen lugar dentro o por causa del sistema.
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.
Es a quien el sistema le pregunta y/o quién 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 serán creadas tantas definiciones raíz como
versiones existan.
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
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 fun−clones 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
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
20
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.
Figura 15:Costo relativo para realizar un cambio.
21
1
Sección 1: Definición del problema.
Sección 2: Justificación del problema.
Sección 3: Metas del sistema y del proyecto.
Sección 4: Restricciones del sistema y del proyecto.
Sección 5: Funciones que se proporcionarán (equipo / programación / personal).
Sección 6: Características del usuario.
Sección 7: Ambientes de desarrollo / operación / mantenimiento.
Sección 8: Estrategia de solución.
Sección 9: Prioridades para las características del sistema.
Sección 10: Criterios de aceptación del sistema.
Sección 11: Fuentes de información.
Sección 12: Glosario de términos.
Sección 1: Modelo del ciclo de vida.
Terminología / logros / productos finales.
Sección 2: Estructura organizacional.
Estructura de administración / de equipos / de distribución de trabajo /
definición de puestos.
Sección 3: Requisitos preliminares de personal y recursos.
Programación de personal y recursos.
Sección 4: Programación preliminar del desarrollo.
Redes PERT / Gráficas de Gantt.
Sección 5: Estimado preliminar de costos.
Sección 6: Mecanismos de supervisión y control del proyecto.
Sección 7: Herramientas y técnicas que se emplearán.
Sección 8: Lenguajes de programación.
22
Sección 9: Requisitos de pruebas.
Sección 10: Documentos de apoyo necesarios.
Sección 11: Formas de demostración y entrega.
Sección 12: Programación de entrenamiento y materiales.
Sección 13: Plan de instalación.
Sección 14: Consideraciones de mantenimiento.
Sección 15: Método y tiempo de la entrega final.
Sección 16: Método y tiempo del pago.
Sección 17: Fuentes de información.
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 representación de un sistema, aunque
no es un sistema completo, posee las características del sistema final o parte de ellas"
23
24
25