Los modelos de desarrollo de software son una representación
abstracta de una manera en particular. Realmente no representa cómo se debe
desarrollar el software, sino de un enfoque común. Puede ser modificado y
adaptado de acuerdo a las necesidades del software en proceso de desarrollo. Hay varios modelos para perfilar el
proceso de desarrollo, cada uno de las cuales cuenta con pros y contras. El
proyecto debería escoger el más apropiado para sus necesidades. Entre los
modelos tenemos:
Modelo
lineal o cascada
También
conocido como modelo clásico, modelo tradicional o modelo lineal secuencial. Él
método de la cascada es considerado como el enfoque clásico para el ciclo de
vida del desarrollo de sistemas, se puede decir que es un método puro que
implica un desarrollo rígido. está es una secuencia de actividades(o
etapas) que consisten en el análisis de requerimientos, él diseño ,la
implementación, la integración y las pruebas .
Ø El análisis
de requerimientos consiste en reunir las necesidades del producto y casi
siempre su salida es texto.
 |
| Ejemplo grafico en Cascada |
Ø La implementación significa
programación. Producto de esta etapa es el código en cualquier nivel, incluido
el producido por sistemas de generación automática.
Ø La integración es
el proceso de integración es el proceso de ensamblar las partes para completar
el producto.
Es caracterizado por ordenar de manera rigurosa las
etapas del ciclo de vida de software, dado que el comienzo de cada etapa debe
esperar a la finalización de la inmediata anterior. Cuando la revisión
determina que el proyecto no está listo para pasar a la siguiente etapa,
permanece en la etapa actual hasta que esté preparado. Y debido a que el
proceso está planeado es más fácil determinar costos y los plazos.
Esté modelo puede ser visto como un modelo con forma de cascada
de agua con varios saltos, en la que cada salto representa cada una
de las fases del ciclo de vida.
Sus beneficios son:
v El inicio y el alcance del proyecto
v La planificación del proyecto (calendario,
recursos necesarios, costo)
v Definición de las necesidades del
negocio y el análisis en detalle dela solución
v La creación de la solución
v Prueba que la solución funciona. La entrega de
la solución a su público objetivo
v Cierre del proyecto.
v Permite la departamentalización y control de gestión.
v El horario se establece con los plazos normalmente
adecuados para cada etapa de desarrollo.
v Este proceso conduce a entregar el proyecto
a tiempo.
v Es sencilla y facilita la gestión de proyectos.
v Permite tener bajo control el proyecto.
v Limita la cantidad de interacción entre equipos que se
produce durante el desarrollo.
Modelo de construcción
de prototipos
El modelo de prototipos permite que todo el
sistema, o algunos de sus partes, se construyan rápidamente para comprender con
facilidad y aclarar ciertos aspectos en los que se aseguren que el
desarrollador, el usuario, el cliente estén de acuerdo en lo que se necesita
así como también la solución que se propone para dicha necesidad y de esta forma
minimizar el riesgo y la incertidumbre en el desarrollo, este modelo se encarga
del desarrollo de diseños para que estos sean analizados y prescindir de ellos
a medida que se adhieran nuevas especificaciones, es ideal para medir el
alcance del producto, pero no se asegura su uso real.
Este modelo principalmente se lo aplica
cuando un cliente define un conjunto de objetivos generales para el software a
desarrollarse sin delimitar detalladamente los requisitos de entrada
procesamiento y salida, es decir cuando el responsable no está seguro de la
eficacia de un algoritmo, de la adaptabilidad del sistema o de la forma en que
interactúa el hombre y la máquina. Este modelo se encarga principalmente de
ayudar al ingeniero de sistemas y al cliente a entender de mejor manera cuál
será el resultado de la construcción cuando los requisitos estén satisfechos.
Beneficios
Este modelo es útil cuando el cliente conoce
los objetivos generales para el software, pero no identifica los requisitos
detallados de entrada, procesamiento o salida. También ofrece un mejor enfoque
cuando el responsable del desarrollo del software está inseguro de la eficacia
de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que
debería tomar la interacción humano-máquina.
v No modifica el flujo del ciclo de vida.
v Reduce el riesgo de construir productos que no satisfagan
las necesidades de los usuarios.
v Reduce costos y aumenta la probabilidad de éxito.
v Exige disponer de las herramientas adecuadas.
v No presenta calidad ni robustez.
v Una vez identificados todos los requisitos mediante el
prototipo, se construye el producto de ingeniería.
vEntre
estos modelos también tenemos los que son los Evolutivos que se adaptan mas fácilmente
a los cambios introducidos en su desarrollo, los cuales tenemos:
Evolutivo-Modelo incremental
El modelo incremental combina elementos del modelo en
cascada con la filosofía interactiva de construcción de prototipos. Se basa en
la filosofía de construir incrementando las funcionalidades del programa. Este
modelo aplica secuencias lineales de forma escalonada mientras progresa el
tiempo en el calendario. Cada secuencia lineal produce un incremento del
software.
Cuando se utiliza un modelo incremental, el primer
incremento es a menudo un producto esencial, sólo con los requisitos básicos.
Este modelo se centra en la entrega de un producto operativo con cada
incremento. Los primeros incrementos son versiones incompletas del producto
final, pero proporcionan al usuario la funcionalidad que precisa y también una
plataforma para la evaluación.
Beneficios
Entre los beneficios que puede proporcionar un modelo de
este tipo encontramos los siguientes:
v Mediante este modelo se genera software operativo de
forma rápida y en etapas tempranas del ciclo de vida del software.
v Es un modelo más flexible, por lo que se reduce el coste
en el cambio de alcance y requisitos.
v Es más fácil probar y depurar en una iteración más
pequeña.
v Es más fácil gestionar riesgos.
v Cada iteración es un hito gestionado fácilmente
v Con un paradigma incremental se reduce el tiempo de
desarrollo inicial, ya que se implementa la funcionalidad parcial.
v También provee un impacto ventajoso frente al cliente,
que es la entrega temprana de partes operativas del Software.
v El modelo proporciona todas las ventajas del modelo en
cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada
incremento.
v Permite entregar al cliente un producto más rápido en
comparación del modelo de cascada.
v Resulta más sencillo acomodar cambios al acotar el tamaño
de los incrementos.
v Por su versatilidad requiere de una planeación cuidadosa
tanto a nivel administrativo como técnico.
Evolutivo-Modelo en espiral
El modelo en espiral, propuesto originalmente por Boehm,
es un modelo de proceso de software evolutivo que conjuga la naturaleza
iterativa de construcción de prototipos con los aspectos controlados y
sistemáticos del modelo lineal secuencial. Proporciona el potencial para el
desarrollo rápido de versiones incrementales del software.
El modelo en espiral se divide en un número de
actividades de marco de trabajo, también llamadas regiones de tareas , Cada una
de las regiones están compuestas por un conjunto de tareas del trabajo llamado conjunto
de tareas que se adaptan a las características del proyecto que va a
emprenderse en todos los casos se aplican actividades de protección.
Entre el modelo original propuesto por Boehm tenemos que
no hay un número definido de iteraciones. Las iteraciones debe decidirlas el
equipo de gestión de proyecto
Cada vuelta se divide
en 4 sectores:
ü Planeación: determinación de los objetivos, alternativas y
restricciones
ü Análisis de riesgo: análisis de alternativas e identificación/resolución de
riesgos
ü Ingeniería: desarrollo del producto hasta "el siguiente
nivel".
ü Evaluación: valoración por parte del cliente de los resultados
obtenidos.
El movimiento de la espiral, ampliando con cada iteración
su amplitud radial, indica que cada vez se van construyendo versiones sucesivas
del software, cada vez más completas.
Uno de los puntos más interesantes del modelo, es la
introducción al proceso de desarrollo a las actividades de análisis de los
riesgos asociados al desarrollo y a la evaluación por parte del cliente de los
resultados del software.
Entre estos métodos también
tenemos que se divide en 6 sectores:
ü 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 otra información 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.
ü -Construcción y
acción: Las tareas requeridas
para construir, probar, instalar y proporcionar soporte al usuario (por ejemplo:
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.
Cada una de las regiones está compuesta por un conjunto
de tareas del trabajo, llamado conjunto de tareas, que se adaptan a las
características del proyecto que va a emprenderse. Para proyectos pequeños, el
número de tareas de trabajo y su formalidad es bajo. Para proyectos mayores y
más críticos cada región de tareas contiene tareas de trabajo que se definen
para lograr un nivel más alto de formalidad.
Beneficios
v El modelo en espiral puede adaptarse y aplicarse a lo
largo de la vida del software de computadora.
v Como el software evoluciona a medida que progresa el
proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante
riesgos en cada uno de los nivele evolutivos.
v El modelo en espiral permite a quien lo desarrolla
aplicar el enfoque de construcción de prototipos en cualquier etapa de
evolución del producto.
v El modelo en espiral demanda una consideración directa de
los riesgos técnicos en todas las etapas del proyecto y si se aplica
adecuadamente debe reducir los riesgos antes de que se conviertan en problemas.
v En la utilización de grandes sistemas a doblado la
productividad.
Evolutivo-Modelo espiral
Win-Win
Una variante interesante del Modelo Espiral previamente
visto es el "Modelo Espiral Win-Win" (Barry Boehm). El Modelo Espiral
previo (clásico) sugiere la comunicación con el cliente para fijar los
requisitos, en que simplemente se pregunta al cliente qué necesita y él
proporciona la información para continuar; pero esto es en un contexto ideal
que rara vez ocurre. Normalmente cliente y desarrollador entran en una
negociación, se negocia coste frente a funcionalidad, rendimiento, calidad,
etc.
"Es así que la obtención de requisitos requiere una
negociación, que tiene éxito cuando ambas partes ganan"
Las mejores negociaciones se fuerzan en obtener
"Victoria & Victoria" (Win & Win), es decir que el cliente
gane obteniendo el producto que lo satisfaga, y el desarrollador también gane
consiguiendo presupuesto y fecha de entrega realista. Evidentemente, este
modelo requiere fuertes 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; se definen las
siguientes actividades:
ü 1 - Identificación del sistema o subsistemas clave de los
directivos (saber qué quieren).
ü 2 - Determinación de "condiciones de victoria"
de los directivos (saber qué necesitan y los satisface)
ü 3 - 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.
El modelo WinWin hace énfasis en la negociación inicial,
también introduce 3 hitos en el proceso llamados "puntos de
fijación", que ayudan a establecer la completitud de un ciclo de la espiral,
y proporcionan hitos de decisión antes de continuar el proyecto de desarrollo
del software
Beneficios
v Reduce riesgos del proyecto
v Incorpora objetivos de calidad
v Integra el desarrollo con el mantenimiento, etc.
v El software evoluciona a medida que progresa el proceso,
el desarrollador y el cliente y reaccionan mejor ante de riesgos.
Modelo del desarrollo concurrente
El
modelo de desarrollo concurrente se utiliza a menudo como el paradigma de
desarrollo de aplicaciones cliente/servidor. Un sistema cliente/servidor se
compone de un conjunto de componente funcional. Cuando se aplica a
cliente/servidor, el modelo de proceso concurrente define actividades en dos
dimensiones: una división de sistemas y una división de componentes. Los
aspectos del nivel de sistemas se afrontan mediante dos actividades: diseño y
realización. La concurrencia se logra de dos formas:
ü Las actividades del sistema y de componente ocurren
simultáneamente y pueden modelarse con el enfoque orientado a objetos descrito
anteriormente;
ü Una aplicación cliente/servidor típica se implementa con
muchos componentes, cada uno de los cuales se pueden diseñar y realizar
concurrentemente.
En
realidad, el modelo de desarrollo concurrente es aplicable a todo tipo de
desarrollo de software y proporciona una imagen exacta del estado actual de un
proyecto. En vez de confinar actividades de ingeniería de software a una
secuencia de sucesos, define una red de actividades, todas las actividades de
la red existen simultáneamente con otras. Los sucesos generados dentro de una
actividad dada o algún otro lado de la red de actividad inicia las transiciones
entre los estados de una actividad.
Beneficios
v Excelente para proyectos en los que se conforman grupos
de trabajo independientes.
v Proporciona una
imagen exacta del estado actual de un proyecto.
No hay comentarios.:
Publicar un comentario