Para
cada fase o etapa, existen sub-etapas o tareas. El modelo de proceso o modelo
de ciclo de vida utilizado para el desarrollo define el orden para las tareas o
actividades involucradas, la coordinación entre ellas, enlace y realimentación.
Los
más conocidos son: - modelo en cascada o secuencial.
- modelo espiral.
- modelo iterativo incremental.
Hay a su vez algunas variantes o alternativas, según la aplicación y sus requisitos.
Modelo en cascada o secuencial:
También llamado modelo clásico, tradicional o lineal
secuencial. El modelo en cascada puro poco se utiliza al pie de la letra, ya
que esto implicaría un previo y absoluto conocimiento de los requisitos, la no
volatilidad de los mismos (o rigidez) y etapas subsiguientes libres de errores;
ello sólo podría ser aplicable a escasos y pequeños desarrollos de sistemas. Por
ejemplo pasar del Diseño a la Codificación implicaría un diseño exacto y sin
errores ni probable modificación o evolución y es irreal pensar en que no vaya
a haber variantes ni errores, ya que intrínsecamente el software es de carácter
evolutivo, cambiante y difícilmente libre de errores, tanto durante su
desarrollo como durante su ciclo operativo.
Algún cambio durante la ejecución de una cualquiera de
las etapas en este modelo secuencial implicaría reiniciar desde el principio
todo el ciclo completo, lo cual redundaría en altos costos de tiempo y
desarrollo.
Sin embargo, es uno de los más utilizados actualmente por
ser eficaz y simple, se produce alguna realimentación entre etapas, que no es
completamente predecible ni rígida; para dar oportunidad al desarrollo de
software en los cuales hay cambios y evoluciones en su ciclo de vida.
Tiene seis etapas:
- Análisis del
Sistema- Análisis de Requisitos de Software
- Diseño
- Codificación
- Prueba
- Mantenimiento
Lo normal en el modelo cascada es aplicar el mismo con
sus etapas realimentadas y actualizadas de forma periódica, permitiendo
retroceder de una a la anterior o volver a otras anteriores, si es requerido,
lo que lo convierte en un modelo en cascada realimentado, el cual resulta muy
atractivo si el proyecto presenta alta rigidez (pocos o ningún cambio), los
requisitos son muy claros y están correctamente especificados.
Desventajas del modelo en cascada:
Los cambios introducidos durante el desarrollo pueden
confundir al equipo profesional en las etapas tempranas del proyecto. Si los
cambios se producen en etapa madura pueden ser desastrosos en un proyecto
grande.
El cliente debe tener paciencia ya que el software no
estará disponible hasta muy avanzado el proyecto. Un error detectado por el
cliente (en fase de operación) puede ser desastroso, implicando reinicio del
proyecto, con altos costos.
Modelo evolutivo:
La evolución del software, los requisitos del usuario y
producto suelen cambiar conforme se desarrolla el mismo. Las fechas de mercado
y la competencia hacen que no sea posible esperar a poner en el mercado un
producto absolutamente completo, por lo que se debe introducir una versión
funcional limitada de alguna forma, para satisfacer al cliente y aliviar las
presiones competitivas; es por esto que los desarrolladores necesitan modelos
que evolucionen progresivamente.
En el modelo Cascada y Cascada Realimentado no se tiene
en cuenta la naturaleza evolutiva del software, se plantea como estático; Los
evolutivos son modelos iterativos, que permiten desarrollar versiones cada vez
más completas y complejas, hasta llegar al objetivo final, incluso evolucionar
más allá durante la fase de operación. Los modelos Iterativo Incremental y
Espiral son dos de los más conocidos y utilizados del tipo evolutivo. 
Se observa que existen actividades de desarrollo (para
cada incremento) que son realizadas en paralelo o concurrentemente, por
ejemplo, en la figura, mientras se realiza el diseño detalle del primer
incremento ya se está realizando en análisis del segundo. Cada incremento
concluye con la actividad de Operación y Mantenimiento. Por medio de este
modelo se entrega software en partes funcionales más pequeñas, pero funcionales
y reutilizables, con funciones suplementarias llamadas incrementos.
Estos incrementos, son escogidos en base a prioridades
predefinidas de algún modo y permite una implementación con refinamientos sucesivos
(ampliación y/o mejora); Con cada incremento se agrega una nueva funcionalidad,
se cubren nuevos requisitos o se mejora la versión anterior del producto.
Además brinda flexibilidad durante el desarrollo, para incluir
cambios en los requisitos por parte del usuario, dependiendo de sus
necesidades. Luego de cada integración se entrega un producto con mayor
funcionalidad que el anterior; Este proceso se repite hasta alcanzar el producto
final.
El modelo es aconsejable para el desarrollo de software,
donde se observa en su etapa inicial de análisis que posee áreas bastante bien
definidas a cubrir, con suficiente independencia como para ser desarrolladas en
etapas sucesivas.
A veces pueden no existir prioridades funcionales por
parte del cliente, pero el desarrollador debe establecerlas de todos modos, con
algún criterio, ya que en base de estas se desarrollarán y entregarán los
distintos incrementos.
El hecho de que existan incrementos funcionales del
software lleva inmediatamente a pensar en un esquema de desarrollo modular, por
tanto este modelo facilita tal paradigma de diseño.
El modelo proporciona todas las ventajas del modelo en
cascada realimentado, pero reduciendo sus desventajas sólo a la fase de cada
incremento.
El modelo incremental no es recomendable para casos de
sistemas de tiempo real, de alto nivel de seguridad, de procesamiento
distribuido, y/o de alto índice de riesgos.
En el modelo Espiral el software se construye en una
serie de versiones incrementales; En las primeras iteraciones la versión
incremental puede ser un modelo en papel o un prototipo. En las últimas
iteraciones se producen versiones cada vez más completas del sistema diseñado,
tiene 4 etapas;
- Planificación.- Análisis de Riesgos.
- Ingeniería (Construcción del prototipo).
- Evaluación por el cliente.
El modelo se divide en un número de Actividades de marco
de trabajo, llamadas "regiones de tareas".
Las regiones definidas en el modelo de la figura anterior
son:
1 - Tareas requeridas para establecer la comunicación
entre el cliente y el desarrollador.
2 - Tareas inherentes a la definición de los recursos,
tiempo y otra información relacionada con el proyecto.
3 - Tareas necesarias para evaluar los riesgos técnicos y
de gestión del proyecto.
4 - Tareas para construir una o más representaciones de
la aplicación software.
5 - Tareas para construir la aplicación, instalarla,
probarla y proporcionar soporte al usuario o cliente (Ej. documentación y
práctica).
6 - Tareas para obtener la reacción del cliente, según la
evaluación de lo creado e instalado en los ciclos anteriores.
Se pueden aplicar a cualquier proyecto, grande, mediano o
pequeño, complejo o simple. Las regiones que definen esas actividades
comprenden un "conjunto de tareas" del trabajo: ese conjunto sí se
debe adaptar a las características del proyecto en particular a emprender.
Proyectos pequeños requieren baja cantidad de tareas y
también de formalidad. En proyectos mayores o críticos cada región de tareas
contiene labores de más alto nivel de formalidad. En cualquier caso se aplican
actividades de protección (por ejemplo, gestión de configuración del software,
garantía de calidad, etc.).
El modelo espiral se puede adaptar, y aplicarse a lo
largo del ciclo de vida del software (en el caso del modelo en cascada, el
proceso termina a la entrega del software).
Un proyecto de "Desarrollo de Conceptos"
comienza al inicio de la espiral, hace múltiples iteraciones hasta que se
completa, es la zona marcada con verde.
Si lo anterior se va a desarrollar como producto real, se
inicia otro proyecto: "Desarrollo de nuevo Producto". Que
evolucionará con iteraciones hasta culminar; es la zona marcada en color azul.
Eventual y análogamente se generarán proyectos de
"Mejoras de Productos" y de "Mantenimiento de productos",
con las iteraciones necesarias en cada área (zonas roja y gris,
respectivamente).
El modelo espiral da un enfoque realista, que evoluciona
igual que el software; se adapta muy bien para desarrollos a gran escala; Pero
requiere considerar riesgos técnicos en todas las etapas del proyecto.
Es apto para el desarrollo de software más complejo como Sistemas
Operativos o en sistemas de alto riesgos o críticos (navegadores y
controladores aeronáuticos).
Desventajas:
- Requiere mucha
experiencia y habilidad para la evaluación de los riesgos, lo cual es requisito
para el éxito del proyecto.
- A veces es
difícil convencer a los clientes de poder controlar este enfoque evolutivo.
- No es tan usado como
el de Cascada por lo que no se pude medir completamente su eficacia.
Modelo espiral Win & Win:
Una variante del Modelo Espiral, busca ganar obteniendo
el producto que pueda satisfacer al cliente, busca obtener "Victoria &
Victoria" (Win & Win), es decir que tanto el cliente como el
desarrollador ganen consiguiendo presupuesto y fecha de entrega realista. Este
modelo requiere buenas habilidades de negociación.
El modelo Win-Win define un conjunto de actividades de
negociación al principio de cada paso alrededor de la espiral, que son:
- Identificación
del sistema o subsistemas clave de los directivos (saber qué quieren). - Determinación de "condiciones de victoria" de los directivos (saber qué necesitan y los satisface)
- Negociación de las condiciones "victoria" de los directivos para obtener condiciones "Victoria & Victoria" (negociar para que ambos ganen).
- Directivo: Cliente escogido con interés directo en el producto, que puede ser premiado por la organización si tiene éxito o criticado si no.
Los requerimientos son usualmente "líneas de
base", cuando una mayoría de los requerimientos comienzan a ser bien
entendidos, en este tiempo se dedica un esfuerzo considerable al diseño. Sin
embargo, una vez que comienza el diseño, cambios a los requerimientos son
comunes y frecuentes.
Durante el diseño de arquitectura, es posible que algunos
componentes comiencen a ser bien definidos antes que la arquitectura completa
sea estabilizada. En tales casos, puede ser posible comenzar el diseño
detallado en esos componentes estables. Similarmente, durante el diseño
detallado, puede ser posible proceder con la codificación y quizás regular
testeando en forma unitaria o realizando testeo de integración previo a llevar
a cabo el diseño detallado de todos los componentes.
Usando técnicas de modelación concurrente, es posible conoce
el verdadero estado en el que se encuentra el proyecto.
Modelo fuente:
Creado por Henderson-Sellers y Edwards en 1990. Es un
tipo de ciclo de vida pensado para la orientación a objetos, se divide en las siguientes
fases:
- Planificación
del negocio
- Construcción: La
más importante y que se divide a su vez en otras cinco actividades: Planificación,
Investigación, Especificación, Implementación y Revisión.
- Entrega.
La primera y la tercera fase son independientes de la
metodología de desarrollo orientado a objetos. Además de las tres fases,
existen dos periodos:
Crecimiento: Es el tiempo durante el cual se construye el
sistema
Madurez: Es el periodo de mantenimiento del producto.
Cada mejora se planifica igual que el periodo anterior, es decir, con las fases
de Planificación del negocio, Construcción y Entrega.
Cada clase puede tener un ciclo de vida sólo para ella
debido a que cada una puede estar en una fase diferente en un momento
cualquiera.
- Viabilidad del proyecto en comparación con las funciones y tamaño de la empresa, la aplicación que se va a desarrollar o a la que se va tener en funcionamiento y las características que va a tener el producto.
- Análisis, construir un modelo de los requisitos suficientes o superiores de los demandados, para poderlos aplicar adecuadamente al tipo de proyecto apropiado. Al identificar los problemas en etapas tempranas hay tiempo de subsanarlos.
- Objetivos, se hacen de la mano con el cliente, para concordar un proyecto adecuado a su necesidad.
- Restricciones, se deben analizar antes de implementar el proyecto, para prever posibles bloqueos, atrasos o perjuicios, que disminuyan el rendimiento, eficiencia, calidad, etc. Es bueno poder desarrollar construcción de prototipos.
- Alternativas, en caso de tener diferentes opciones se debe proveer de alternativas y formas de gestionar de mejor manera el modelo, para adecuar el proyecto y el desarrollo del mismo hasta su culminación.
- Planificación, donde se analiza y se prevé, posibles soluciones o modificaciones según las aplicaciones a utilizar, puede ser que surjan necesidades imprevistas. Poder descubrir errores en la fase de análisis y no hasta la entrega, genera confianza y respaldo ante el cliente final, además de optimizar los recursos.
- Diseño, a partir del modelo de análisis se debe poder deducir y planear la estructura de datos, amigable y funcional para el sistema y la interfaz de usuario.
- Codificación, adecuada para construir el sistema y ajustable a la fase ejecutable del código, para que facilite su operación.
- Documentación, es una tarea importante que se realiza en todas las etapas, para estimar y evaluar, distintos percances en el sistema, o para poder realizar modificaciones o adiciones a sus funciones de acuerdo a la finalidad y necesidad del proyecto.
- Pruebas, etapa para comprobar que se cumplen
los requisitos dentro del criterio de corrección y calidad, para el producto
final.
- Mantenimiento, es la fase después de la
entrega, donde se asegura que el sistema sigue funcionando adecuadamente y está
presto cualquier requisito nuevo.
Por
ejemplo, para una empresa que desea desarrollar una aplicación para la
administración de los pedidos, donde no tienen claro lo que quieren, el modelo
de proceso que yo recomendaría, sería el modelo Iterativo incremental, ya que
este permite la entrega de versiones parciales a medida que se va construyendo
el producto final, y da posibilidad de realizar cambios, modificaciones,
Conforme
se va viendo el desarrollo de la aplicación, o los requisitos; además tiene la
facilidad de mejorar cada versión emitida, incorporando nuevas funciones a las
versiones anteriores.
Por
otro lado para una el proyecto de una empresa de desarrollo de software que
desea elaborar un procesador de palabra, se puede usar por ejemplo un modelo en
cascada o un modelo incremental, entonces, realmente ningún modelo es perfecto,
pero se busca siempre el que se acomode a la aplicación y desarrollo y
finalidad del producto.
Conforme
se va viendo el desarrollo de la aplicación, o los requisitos; además tiene la
facilidad de mejorar cada versión emitida, incorporando nuevas funciones a las
versiones anteriores.
Por
otro lado para una el proyecto de una empresa de desarrollo de software que
desea elaborar un procesador de palabra, se puede usar por ejemplo un modelo en
cascada o un modelo incremental, entonces, realmente ningún modelo es perfecto,
pero se busca siempre el que se acomode a la aplicación y desarrollo y
finalidad del producto.
No hay comentarios:
Publicar un comentario