Ingeniería de Software II Capitulo II
CAPITULO II – EVOLUCIÓN DEL SOFTWARE
II.1 – El ciclo de vida del software
Para resolver los problemas reales de una industria, un ingeniero de software o un equipo de
ingenieros deben incorporar una estrategia de desarrollo que acompañe al proceso, métodos, capas
de herramientas y las fases genéricas discutidas en la Unidad I. Esta estrategia a menudo se llama
modelo de proceso o paradigma de ingeniería del software. Se selecciona un modelo de proceso
para la ingeniería del software según la naturaleza del proyecto y de la aplicación, los métodos y las
herramientas a utilizarse, y los controles y entregas que se requieren.
El ciclo de vida del software es la forma mediante la cual se describen diferentes pasos que
se deben seguir para el desarrollo de un software, partiendo desde una necesidad hasta llegar a la
puesta en marcha de una solución y su apropiado mantenimiento. El ciclo de vida para un software
comienza cuando se tiene la necesidad de resolver un problema, y termina cuando el programa que
se desarrolló para cumplir con los requerimientos, deja de ser utilizado.
II.2 – Modelo de proceso de software
Figura 1: Modelo lineal secuencial.
El modelo lineal secuencial. La figura 1 ilustra el modelo lineal secuencial para la
ingeniería del software. Llamado algunas veces “ciclo de vida básico” o “modelo en cascada”, el
modelo lineal secuencial sugiere un enfoque sistemático, secuencial del desarrollo del software que
comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y
mantenimiento. Modelado según el ciclo de ingeniería convencional, el modelo lineal secuencial
acompaña a las actividades siguientes:
Ingeniería y modelado de sistemas/información. Como el software siempre forma parte de
un sistema más grande (o empresa), el trabajo comienza estableciendo requisitos de todos los
elementos del sistema y asignando al software algún subgrupo de estos requisitos. Esta visión del
sistema es esencial cuando el software se debe interconectar con otros elementos como hardware,
personas y bases de datos. La ingeniería y el análisis de sistemas acompañan a los requisitos que se
recogen en el nivel del sistema con una pequeña parte de análisis y de diseño. La ingeniería de
Ingeniería de Software I Unidad I
información acompaña a los requisitos que se recogen en el nivel estratégico de empresa y en el
nivel del área de negocio.
I
Análisis de los requisitos del software. El proceso de reunión de requisitos se intensifica y
se centra especialmente en el software. Para comprender la naturaleza del programa a construirse, el
ingeniero (analista) del software debe comprender el dominio de la información del software, así
como la función requerida, comportamiento, rendimiento, e interconexión. El cliente documenta y
repasa los requisitos del sistema y del software.
Diseño. El diseño del software es realmente un proceso de muchos pasos que se centra en
cuatro atributos distintos de un programa: estructura de datos, arquitectura del software,
representaciones de interfaz y detalle procedimental (algoritmo). El proceso de diseño traduce
requisitos en una representación del software que se pueda evaluar por calidad antes de que se
comience la generación del código. Al igual que los requisitos, el diseño se documenta y se hace
parte de la configuración del software.
Generación de código. El diseño se debe traducir en una forma legible por la máquina. El
paso de generación de código lleva a cabo esta tarea. Si se lleva a cabo el diseño de forma detallada,
la generación de código se realiza mecánicamente.
Pruebas. Una vez se ha generado el código, comienzan las pruebas del programa. El
proceso de pruebas se centra en los procesos lógicos internos del software, asegurando que todas las
sentencias se han comprobado, y en los procesos externos funcionales, es decir, la realización de las
pruebas para la detección de errores y el sentirse seguro de que la entrada definida produzca
resultados reales de acuerdo con los resultados requeridos.
Mantenimiento. El software indudablemente sufrirá cambios después de ser entregado al
cliente. Se producirán cambios porque se han encontrado errores, porque el software debe adaptarse
para acoplarse a los cambios de su entorno externo, o porque el cliente requiere mejoras funcionales
o de rendimiento. El mantenimiento vuelve a aplicar cada una de las fases precedentes a un
programa ya existente y no a uno nuevo.
El modelo lineal secuencial es el paradigma más antiguo y más extensamente utilizado en la
ingeniería del software. Sin embargo, la crítica del paradigma ha puesto en duda su eficacia. Entre
los problemas que se encuentran algunas veces en el modelo lineal secuencial se incluyen:
1. Los proyectos reales raras veces siguen el modelo secuencial que propone el modelo.
Aunque el modelo lineal puede acoplar interacción, lo hace indirectamente. Como resultado,
los cambios pueden causar confusión cuando el equipo del proyecto comienza.
2. A menudo es difícil que el cliente exponga explícitamente todos los requisitos. El modelo
lineal secuencial lo requiere y tiene dificultades a la hora de acomodar la incertidumbre
natural al comienzo de muchos proyectos.
Ingeniería de Software II Capitulo II
3. En cliente debe tener paciencia. Una versión de trabajo del programa no estará disponible
hasta que el proyecto esté muy avanzado. Un grave error puede ser desastroso si no se
detecta hasta que se revisa el programa.
4. Los responsables del desarrollo de software siempre se retrasan innecesariamente. La
naturaleza de este modelo lleva a “estados de bloqueo” en el que algunos miembros del
equipo del proyecto deben esperar a otros miembros del equipo para completar tareas
pendientes. En efecto, el tiempo que se pasa esperando puede sobrepasar el tiempo que se
emplea en el trabajo productivo. Los estados de bloqueo tienden a ser más importantes al
principio y al final de un proceso lineal secuencial.
Cada uno de estos errores es real. Sin embargo, el paradigma del ciclo de vida clásico tiene
un lugar definido e importante en el trabajo de la ingeniería del software. Proporciona una plantilla
en la que se encuentran métodos para análisis, diseño, codificación, pruebas y mantenimiento. El
ciclo de vida clásico sigue siendo el modelo de proceso más extensamente utilizado por la
ingeniería del software. Pese a tener debilidades, es significativamente mejor que un enfoque hecho
al azar para el desarrollo del software.
Figura 2: Modelo de construcción de prototipos.
El modelo de construcción de prototipos. Un cliente a menudo define un conjunto de
objetivos generales para el software, pero no identifica los requisitos detallados de entrada,
procesamiento, o salida. En otros casos, el responsable del desarrollo del software puede no estar
seguro de la eficacia de un algoritmo, de la capacidad de adaptación de un sistema operativo, o de la
forma en que deberían tomarse la interacción hombre – máquina. En éstas y en otras muchas
situaciones, un paradigma de construcción de prototipos puede ofrecer el mejor enfoque.
El paradigma de construcción de prototipos (figura 2) comienza con la recolección de
requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software,
identifican los requisitos conocidos, y las áreas del esquema en donde es obligatoria más definición.
Entonces aparece un “diseño rápido”. El diseño rápido se centra en una representación de esos
aspectos del software que serán visibles para el usuario/cliente. El diseño rápido lleva a la
construcción de un prototipo. El prototipo lo evalúa el cliente/usuario y lo utiliza para refinar los
Ingeniería de Software I Unidad I
requisitos del software a desarrollar. La interacción ocurre cuando el prototipo satisface las
necesidades del cliente, a la vez que permite que el desarrollador comprenda mejor lo que se
necesita hacer.
Lo ideal sería que el prototipo sirviera como un mecanismo para identificar los requisitos del
software. Si se construye un prototipo de trabajo, el desarrollador intenta hacer uso de los
fragmentos del programa ya existentes o aplica herramientas que permiten generar rápidamente
programas de trabajo.
I
Pero, ¿qué hacemos con el prototipo una vez que ha servido para el propósito descrito
anteriormente? Brooks proporciona una respuesta:
En la mayoría de los proyectos, el primer sistema construido apenas se puede utilizar. Puede ser demasiado
lento, demasiado grande, o torpe en su uso, o las tres a la vez. No hay alternativa sino comenzar de nuevo y
construir una versión rediseñada en la que se resuelvan estos problemas...Cuando se utiliza un concepto nuevo
de sistema o una tecnología nueva, se tiene que construir un sistema que no sirva y se tenga que tirar, porque
incluso la mejor planificación no es omnisciente como para que esté perfecta la primera vez. Por tanto, la
pregunta sobre la gestión no es si construir un sistema piloto y tirarlo. Tendrá que hacerlo. La única pregunta
es si planificar de antemano construir un desechable, o prometer entregárselo a los clientes...
Sin embargo, la construcción de prototipos también puede ser problemática por las razones
siguientes:
1. El cliente ve lo que parece ser una versión del trabajo del software, sin saber que con la prisa
de hacer que funcione no se ha tenido en cuenta la calidad del software global o la facilidad
de mantenimiento a largo plazo. Cuando se informa de que el producto se debe construir
otra vez para que se puedan mantener los niveles altos de calidad, el cliente no entiende y
pide que se apliquen “unos pequeños ajustes” para que se pueda hacer del prototipo un
producto final. De forma demasiado frecuente la gestión de desarrollo del software es muy
lenta.
2. El desarrollador a menudo hace compromisos de implementación para hacer que el
prototipo funcione rápidamente. Se puede utilizar un sistema operativo o lenguaje de
programación inadecuado simplemente porque está disponible y porque es conocido; un
algoritmo eficiente se puede implementar simplemente para demostrar la capacidad.
Después de algún tiempo, el desarrollador debe familiarizarse con estas selecciones, y
olvidarse de las razones por las que son inadecuadas. La selección menos ideal ahora es una
parte integral del sistema.
Aunque pueden surgir problemas, la construcción de prototipos puede ser un paradigma
efectivo para la ingeniería del software. La clave es definir las reglas del juego al comienzo; es
decir, el cliente y el desarrollador se deben poner de acuerdo en que el prototipo se construya para
servir como un mecanismo de definición de requisitos. Entonces se descarta, se realiza la ingeniería
del software con una visión hacia la calidad y la facilidad de mantenimiento.
Ingeniería de Software II Capitulo II
Figura 3: Modelo DRA.
El modelo DRA. El Desarrollo Rápido de Aplicaciones (DRA) (Rapid Application
Development, RAD) es un modelo de proceso del desarrollo del software lineal secuencial que
enfatiza un ciclo de desarrollo extremadamente corto. El modelo DRA es una adaptación a “alta
velocidad” del modelo lineal secuencial en el que se logra el desarrollo rápido utilizando un enfoque
de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito
del proyecto, el proceso DRA permite al equipo de desarrollo crear un “sistema completamente
funcional” dentro de períodos cortos de tiempo (de 60 a 90 días). Cuando se utiliza principalmente
para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases:
Modelo de gestión. El flujo de información entre las funciones de gestión se modela de
forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión?
¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la procesa?
Modelado de datos. El flujo de información definido como parte de la fase de modelado de
gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se
definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre los
objetos.
Modelado de proceso. Los objetos de datos definidos en la fase de modelado de datos
quedan transformados para lograr el flujo de información necesario para implementar una función
de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un
objeto de datos.
Generación de aplicaciones. El DRA asume la utilización de técnicas de cuarta generación.
En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA
trabaja para volver a utilizar componentes de programas ya existentes o a crear componentes
reutilizables. En todos los casos se utilizan herramientas automáticas para facilitar la construcción
del software.
Pruebas y entrega. Como el proceso DRA enfatiza la reutilización, ya se han comprobado
muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se
deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.
Ingeniería de Software I Unidad I
El modelo de proceso DRA se ilustra en la figura 3. Obviamente, las limitaciones de tiempo
impuestas en un proyecto DRA demandan “ámbito en escalas”. Si una aplicación de gestión puede
modularse de forma que permita completarse cada una de las funciones principales en menos de tres
Ingeniería de Software I Unidad I I
meses, es un candidato del DRA. Cada una de las funciones puede ser afrontada por un equipo DRA
diferente y ser integrados en un solo conjunto.
Al igual que todos los modelos de proceso, el enfoque DRA tiene inconvenientes:
• Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes
como para crear el número correcto de equipos DRA.
• DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades
necesarias para completar un sistema en un marco de tiempo abreviado. Si no hay
compromiso, por ninguna de las partes constituyentes, los proyectos DRA fracasarán.
No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se puede
modularizar adecuadamente la construcción de los componentes necesarios para DRA será
problemático. Si está en juego el alto rendimiento, y se va a conseguir el rendimiento convirtiendo
interfaces en componentes de sistemas, el enfoque DRA puede que no funcione.
Figura 4: Modelo incremental.
El modelo incremental. El modelo incremental combina elementos del modelo lineal
secuencial (aplicados repetitivamente) con la filosofía interactiva de construcción de prototipos.
Como muestra la figura 4, el modelo incremental aplica secuencias lineales de forma sorprendente
de la misma forma que progresa el tiempo en el calendario. Cada secuencia lineal produce un
“incremento” del software.
Cuando se utiliza un modelo incremental, el primer incremento a menudo es un producto
esencial (núcleo). Es decir, se afrontan requisitos básicos, pero muchas funciones suplementarias
(algunas conocidas, otras no) quedan sin extraer. El cliente utiliza el producto central. Como un
resultado de utilización y/o de evaluación, se desarrolla un plan para el incremento siguiente. El
plan afronta la modificación del producto central a fin de cumplir mejor las necesidades del cliente
Ingeniería de Software I Unidad I I
y la entrega de funciones, y características adicionales. Este proceso se repite siguiendo la entrega
de cada incremento, hasta que se elabore el producto completo.
El modelo incremental se centra en la entrega de un producto operacional con cada
incremento. Los primeros incrementos son versiones del producto final, pero proporcionan la
capacidad que sirve al usuario y también proporciona una plataforma para la evaluación por parte
del usuario.
El desarrollo incremental es particularmente útil cuando la dotación de personal no está
disponible para una implementación completa en cuanto a la fecha límite de gestión que se haya
establecido para el proyecto. Los primeros incrementos se pueden implementar con menos
personas. Si el producto central es bien recibido, se puede añadir más personal para implementar el
incremento siguiente.
Figura 5: Modelo en espiral.
El modelo en espiral. Es un modelo de proceso de software evolutivo que acompaña la
naturaleza interactiva de prototipos con los aspectos controlados y sistemáticos del modelo lineal
secuencial. En el modelo espiral, el software se desarrolla en una serie de versiones incrementales.
Durante las primeras iteraciones, la versión incremental podría ser un modelo en papel o un
prototipo. Durante las últimas iteraciones, se producen versiones cada vez más completas de
ingeniería del sistema.
El modelo en espiral se divide en un número de actividades estructurales, también llamadas
regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas, la figura 5 representa
un modelo en espiral que contiene seis regiones de tareas:
• Comunicación con el cliente. Las tareas requeridas para establecer comunicación entre el
desarrollador y el cliente.
• Planificación. Las tareas requeridas para definir recursos, el tiempo y otras informaciones
relacionadas con el proyecto.
• Análisis de riesgos. Las tareas requeridas para evaluar riesgos técnicos y de gestión.
• Ingeniería. Las tareas requeridas para construir una o más representaciones de la aplicación.
Ingeniería de Software I Unidad I I
• Construcción y adaptación. Las tareas requeridas para construir, probar, instalar y
proporcionar soporte al usuario (documentación y práctica).
• Evaluación del cliente. Las tareas requeridas para obtener la reacción del cliente según la
evaluación de las representaciones del software creadas durante la etapa de ingeniería e
implementada durante la etapa de instalación.
Cuando comienza el proceso evolutivo, el equipo de ingeniería del software gira alrededor
de la espiral en la dirección de las agujas del reloj, comenzando por el centro. El primer circuito de
la espiral produce el desarrollo de una especificación de productos; los pasos siguientes en la espiral
se podrían utilizar para desarrollar un prototipo y progresivamente versiones más sofisticadas del
software. Cada paso de la región de planificación produce ajustes en el plan del proyecto. El coste y
la planificación se ajustan según la reacción ante la evaluación del cliente. Además, el gestor del
proyecto ajusta el número planificado de iteraciones requeridas para completar el software.
A diferencia del modelo de proceso clásico que termina cuando se entrega el software, el
modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora.
El modelo en espiral es un enfoque realista del desarrollo de sistemas y de software a gran
escala. Utiliza la construcción de prototipos como mecanismo de reducción de riesgos. Mantienen el
enfoque sistemático de los pasos sugeridos por el ciclo de vida clásico, pero lo incorpora al marco
de trabajo interactivo que refleja de forma más realista el mundo real.
Pero al igual que otros paradigmas, el modelo en espiral no es la panacea. Puede resultar
difícil convencer a grandes clientes de que el enfoque evolutivo es controlable. Requiere un
considerable habilidad para la evaluación del riesgo, y cuenta con esta habilidad para el éxito. Si un
riesgo es importante no es descubierto y gestionado, indudablemente surgirán problemas.
