El diseño basado en re utilización puro busca construir un producto
software integrando componentes pre-existentes.
Los beneficios principales que otorga este modelo son:
-Tiempos de desarrollos cortos
-Disminución de errores
-Disminución de costos y riegos ya que se reduce los componentes a desarrollar
-Existe un aumento de la confiabilidad ya que los componentes a utilizar ya fueron testados y utilizados en otro momento previo al comienzo del proyecto
A modo de desventaja podemos mencionar el hecho de que al no poseer algún componente que cubra con un requisito dado por el usuario, este debe ser modificado para adaptarlo a los componentes almacenados en el repositorio de componentes.
Esto se da en el modelo puro. En cambio en el modelo real si no se puede adaptar un requisito de usuario, se conseguirá o se desarrollara ese modulo para que cumpla con lo pedido por el usuario.
Otra desventaja de este modelo es que una vez finalizada la etapa de modificación de requisitos, y ante la eventual necesidad de cambios en estos últimos, puede pasar que no haya componentes que se adapten a las nuevas modificaciones.
Los beneficios principales que otorga este modelo son:
-Tiempos de desarrollos cortos
-Disminución de errores
-Disminución de costos y riegos ya que se reduce los componentes a desarrollar
-Existe un aumento de la confiabilidad ya que los componentes a utilizar ya fueron testados y utilizados en otro momento previo al comienzo del proyecto
A modo de desventaja podemos mencionar el hecho de que al no poseer algún componente que cubra con un requisito dado por el usuario, este debe ser modificado para adaptarlo a los componentes almacenados en el repositorio de componentes.
Esto se da en el modelo puro. En cambio en el modelo real si no se puede adaptar un requisito de usuario, se conseguirá o se desarrollara ese modulo para que cumpla con lo pedido por el usuario.
Otra desventaja de este modelo es que una vez finalizada la etapa de modificación de requisitos, y ante la eventual necesidad de cambios en estos últimos, puede pasar que no haya componentes que se adapten a las nuevas modificaciones.
Modelo Puro
Modelo Real
Modelo Incremental
El
Modelo Incremental combina elementos del MLS con la filosofía interactiva de
construcción de prototipos.
En
una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código
y Prueba. Sin embargo, para la producción del Software, se usa el principio de
trabajo en cadena o “Pipeline”, utilizado en muchas otras formas de
programación. Con esto se mantiene al cliente en constante contacto con los
resultados obtenidos en cada incremento.
Es
el mismo cliente el que incluye o desecha elementos al final de cada incremento
a fin de que el software se adapte mejor a sus necesidades reales. El proceso
se repite hasta que se elabore el producto completo.
El
Modelo Incremental es particularmente útil cuando no se cuenta con una dotación
de personal suficiente. Los primeros pasos los pueden realizar un grupo
reducido de personas y en cada incremento se añadir• personal, de ser
necesario. Por otro lado los incrementos se pueden planear para gestionar
riesgos técnicos.
El Modelo Incremental
se puede ver aquí en forma gráfica:
-
Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta
frecuencia.
-
El usuario se involucra más.
-
Difícil de evaluar el coste total.
-
Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados
y a operar como un todo.
-
Requiere gestores experimentados.
-
Los errores en los requisitos se detectan tarde.
-
El resultado puede ser muy positivo.
Pipeline
La
arquitectura en pipeline (basada en filtros) consiste en ir transformando un
flujo de datos en un proceso comprendido por varias fases secuenciales, siendo
la entrada de cada una la salida de la anterior.
Esta
arquitectura es muy común en el desarrollo de programas para el intérprete de
comandos, ya que se pueden concatenar comandos fácilmente con tuberías (pipe).
Interprete de comandos
Parte
fundamental de un sistema operativo que ordena la ejecución de mandatos
obtenidos del usuario por medio de una interfaz alfanumérica.
Características
-
Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con
cierta frecuencia.
-
El usuario se involucre más.
-
Difícil de evaluar el costo total.
-
Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados
y a operar como un todo.
-
Requiere gestores experimentados.
-
Los errores en los requisitos se detectan tarde.
-
El resultado puede ser muy positivo.
Ventajas:
-
Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que
se implementa la funcionalidad parcial.
-
También provee un impacto ventajoso frente al cliente, que es la entrega
temprana de partes operativas del Software.
-
El modelo proporciona todas las ventajas del modelo en cascada realimentado,
reduciendo sus desventajas sólo al ámbito de cada incremento.
-
Permite entregar al cliente un producto más rápido en comparación del modelo de
cascada.
-
Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.
-
Por su versatilidad requiere de una plantación cuidadosa tanto a
nivel administrativo como técnico.
Desventajas:
-
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.
-
Requiere de mucha plantación, tanto administrativa como técnica.
- Requiere de
metas claras para conocer el estado del proyecto.
El modelo de desarrollo en espiral es un generador
de modelo de proceso guiado por el riesgo que se emplea para conducir sistemas
intensivos de ingeniería de software concurrente y a la vez con muchos
usuarios¨. Las actividades que conforman este modelo forman una espiral, en la
que cada bucle o interacciona representa un conjunto de actividades. Se tiene
en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software.
Modelo Evolutivo
Los
modelos evolutivos son iterativos. Se caracterizan por la forma en que permiten
a los ingenieros del software desarrollar versiones cada vez más completas del
software.
El software evoluciona con el tiempo. Los
requisitos del usuario y del 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
aconsejable introducir una versión funcional limitada de alguna forma para
aliviar las presiones competitivas.
Desventajas
Genera
mucho tiempo en el desarrollo del sistema
Modelo costoso
Requiere experiencia en la identificación de
riesgos
Ventajas
El análisis del riesgo se hace de forma explícita y
clara.
Une los mejores elementos de los restantes modelos.
Reduce riesgos del proyecto
Incorpora objetivos de calidad
Integra el desarrollo con el mantenimiento,
etc.
Los evolutivos son modelos
iterativos, permiten desarrollar versiones cada vez más completas y complejas,
hasta llegar al objetivo final deseado; incluso evolucionar más allá, durante
la fase de operación. Los modelos “Iterativo Incremental” y “Espiral”
(entre otros) son dos de los más conocidos y utilizados del tipo evolutivo.
La idea detrás de
este modelo es el desarrollo de una implantación del sistema inicial, exponerla
a los comentarios del usuario, refinarla en Nuevas versiones hasta
que se desarrolle el sistema adecuado.Una ventaja de este modelo es
que se obtiene una rápida re alimentación del usuario, ya que
las actividades de especificación, desarrollo y pruebas se ejecutan en cada
iteración.
Existen dos tipos de
desarrollo evolutivo:
· Desarrollo Exploratorio: El objetivo de este enfoque es explorar
con el usuario los requisitos hasta llegar a un sistema final. El desarrollo
comienza con las partes que se tiene más claras. El sistema evoluciona conforme
se añaden nuevas características propuestas por el usuario.
· Enfoque utilizando prototipos: El objetivo es entender los
requisitos del usuario y trabajar para mejorar la calidad de los requisitos. A
diferencia del desarrollo exploratorio, se comienza por definir los requisitos
que no están claros para el usuario y se utiliza un prototipo para experimentar
con ellos. El prototipo ayuda a terminar de definir estos requisitos.
VENTAJAS
· La especificación puede desarrollarse de forma creciente.
· Los usuarios y des arrolladores logran un mejor entendimiento del
sistema. Esto se refleja en una mejora de la calidad del software.
· Es más efectivo que el modelo de cascada, ya que cumple con las
necesidades inmediatas del cliente.
DESVENTAJAS
· Proceso no Visible: Los administradores necesitan entregas para
medir el progreso. Si el sistema se necesita desarrollar rápido, no es efectivo
producir documentos que reflejen cada versión del sistema.
· Sistemas pobremente estructurados: Los cambios continuos pueden
ser perjudiciales para la estructura del software haciendo costoso el
mantenimiento.
· Se requieren técnicas y herramientas: Para el rápido desarrollo se
necesitan herramientas que pueden ser incompatibles con otras o que poca gente
sabe utilizar.
En Ingeniería de software el desarrollo en
cascada, también llamado modelo en cascada (denominado así
por la posición de las fases en el desarrollo de esta, que parecen caer en
cascada “por gravedad” hacia las siguientes fases), es el enfoque
metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de
software de tal forma que el
inicio de cada etapa debe esperar al término de la etapa anterior.1 Al final de cada
etapa, el modelo está diseñado para llevar a cabo una revisión final, que se
encarga de determinar si el proyecto está listo para avanzar a la siguiente
fase. Este modelo fue el primero en originarse y es la base de todos los demás
modelos de ciclo de vida.
Un ejemplo de una metodología de desarrollo en
cascada es:
1.
Análisis de requisitos.
2.
Diseño del Sistema.
3.
Segregación del
programa.
4.
Diversificación.
5.
Verificación integral.
6.
Ordeñado del programa.
Fases del
Modelo
Análisis de requisitos
En esta fase se analizan las necesidades de los usuarios finales del
software para determinar qué objetivos debe cubrir. De esta fase surge una
memoria llamada SRD (documento de especificación de requisitos), que contiene
la especificación completa de lo que debe hacer el sistema sin entrar en
detalles internos.
Diseño del
Sistema
Descompone y organiza el sistema en elementos que puedan elaborarse por
separado, aprovechando las ventajas del desarrollo en equipo. Como resultado
surge el SDD (Documento de Diseño del Software), que contiene la descripción de
la estructura relacional global del sistema y la especificación de lo que debe
hacer cada una de sus partes, así como la manera en que se combinan unas con
otras.
Diseño del
Programa
Es la fase en donde se realizan los algoritmos necesarios para el
cumplimiento de los requerimientos del usuario así como también los análisis
necesarios para saber qué herramientas usar en la etapa de Codificación
Codificación
Dependiendo del lenguaje de programación y su versión se crean las
bibliotecas y componentes re utilizables dentro del mismo proyecto
para hacer que la programación sea un proceso mucho más rápido
Pruebas
Los elementos, ya programados, se ensamblan para componer el sistema y
se comprueba que funciona correctamente y que cumple con los requisitos, antes
de ser entregado al usuario final.
Verificación
Es la fase en donde el usuario final ejecuta el sistema, para ello el o
los programadores ya realizaron exhaustivas pruebas para comprobar que el
sistema no falle.
Mantenimiento
Una de las etapas más críticas, ya que se destina un 75 % de los
recursos, es el mantenimiento del Software ya que al utilizarlo como usuario
final puede ser que no cumpla con todas nuestras expectativas.
