Modelo de desarrollo de software
Para
el desarrollo de cualquier producto de software se realizan una serie de tareas
entre la idea inicial y el producto final.
Un
modelo de desarrollo establece el orden en el que se harán las cosas en el
proyecto, nos provee de requisitos de entrada y salida para cada una de las
actividades.
Es
necesario destacar el ciclo de vida del proyecto y el modelo de desarrollo.El
ciclo de vida del proyecto ayuda a controlar las actividades del proyecto desde
el inicio al fin del mismo.El
modelo de desarrollo nos ayuda a la forma en la que vamos a construir el
producto.Ambos
se complementan para generar el producto desde el punto de vista técnico y administrativo.
Modelos de Desarrollo
El Modelo de Cascada.El Modelo en V.En Flor.PrototiposEl Modelo de Espiral.El Modelo de Procesos.Desarrollo Incremental.
El Modelo de Cascada
El modelo en cascada, uno de los primeros modelos de desarrollo de software que considera las diferentes actividades como fases separadas de tal forma que para iniciar una nueva actividad debe esperarse a la finalización de la actividad anterior. El resultado de cada etapa es uno o más documentos aprobados.
Las principales actividades de este modelo son las que podemos observar en el siguiente gráfico extraído de la red:
1. Análisis y definición de requerimientos: En esta etapa se definen los requisitos y requerimientos del sistema software a partir de consultas con los clientes y los usuarios del futuro sistema software. De esta etapa surge el documento de especificación de requisitos (SRD) que contiene toda la especificación del sistema sin entrar en detalles de diseño.
2. Diseño del sistema y del software: En esta etapa se dividen los requerimientos en subsistemas, se establece un arquitectura completa y se identifican y describen las relaciones fundamentales del sistema software. De esta etapa surge el documento de diseño del software (SDD) que contiene toda la descripción del sistema desde el punto de vista del diseño.
3. Implementación: En esta etapa el diseño del software se lleva a cabo implementándolo en un lenguaje de programación. Aquí se implementa el código fuente, se crean las bibliotecas y se reutilizan los componentes.
4. Pruebas: En esta etapa, los programas se integran y se prueban como un sistema completo para asegurar que se cumplen los requerimientos del software. Después de las pruebas el sistema se entrega al cliente.
5. Mantenimiento: Es la etapa más larga de todos los procesos de desarrollo. El sistema se instala y se pone en funcionamiento corrigiendo todos los errores no descubiertos en las etapas anteriores. También se mejora la implementación añadiendo nuevos requerimientos siempre que el usuario los necesite.
Este modelo ha sido muy criticado porque tiene muchas desventajas:
- Lo peor de todo es la necesidad de tener todos los requisitos al principio ya que lo normal es que el cliente no tenga perfectamente definidas las especificaciones surgiendo nuevos requisitos a lo largo de las diferentes etapas de desarrollo. Según este modelo hay que tenerTODOS los requisitos en la primera etapa no pudiendose llevar a cabo los requisitos que surgan una vez acabada la etapa de especificación.
- Es normal cometer errores en alguna de las etapas del proceso de desarrollo. Según este modelo cada vez que se identifique algún error cometido hay que volver a la etapa anterior y rehacer el trabajo.
- Por último, no se tiene el producto software hasta el final del proceso de desarrollo, por lo que el cliente no verá los resultados hasta la última fase. Además la mayoría de errores producidos en el análisis se descubren al final.
Así que este enfoque de desarrollo solo debería seguirse si tenemos muy claro las especificaciones desde el primer momento y sabemos que los requisitos no van a ser cambiantes.
El Modelo en V
El modelo en V es una variación del modelo en cascada que muestra cómo se relacionan las actividades de prueba con el análisis y el diseño. Como se muestra en la Figura 3, la codificación forma el vértice de la V, con el análisis y el diseño a la izquierda y las pruebas y el mantenimiento a la derecha.
La unión mediante líneas discontinuas entre las fases de la parte izquierda y las pruebas de la derecha representa una doble información. Por un lado sirve para indicar en qué fase de desarrollo se deben definir las pruebas correspondientes. Por otro sirve para saber a qué fase de desarrollo hay que volver si se encuentran fallos en las pruebas correspondientes.
Por lo tanto el modelo en V hace más explícita parte de las iteraciones y repeticiones de trabajo que están ocultas en el modelo en cascada. Mientras el foco del modelo en cascada se sitúa en los documentos y productos desarrollados, el modelo en V se centra en las actividades y la corrección.
Ventajas y desventajas del Modelo en “V”
Ventajas:
• La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localización de fallos.
• Es un modelo sencillo y de fácil aprendizaje
• Hace explícito parte de la iteración y trabajo que hay que revisar
• Especifica bien los roles de los distintos tipos de pruebas a realizar
• Involucra al usuario en las pruebas
Desventajas:
• Es difícil que el cliente exponga explícitamente todos los requisitos
• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida
• Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas
• El producto final obtenido puede que no refleje todos los requisitos del usuario
Prototipos
Un prototipo es una versión
preliminar de un sistema de información con fines de demostración o evaluación.
Es
un método menos formal de desarrollo.El prototipeo es
una técnica para comprender las especificaciones.Un
prototipo puede ser eliminado.Un
prototipo puede llegar a ser parte del producto final.
Construcción de Prototipos
Identificación
de Requerimientos.Diseño
Rápido.Utilizar
el Prototipo.Revisar
y Mejorar.
Ventajas:
Útiles
cuando los requerimientos son cambiantes.
Cuando
no se conoce bien la aplicación.
Cuando
el usuario no se quiere comprometer con los requerimientos.
Cuando
se quiere probar una arquitectura o tecnología.
Cuando
se requiere rapidez en el desarrollo.
Desventajas:
No
se conoce cuando se tendrá un producto aceptable.
No
se sabe cuantas iteraciones serán necesarias.
Da
una falsa ilusión al usuario sobre la velocidad del desarrollo.
Se
puede volver el producto aún y cuando no este con los estándares.
El Modelo de Espiral
El modelo
en espiral del proceso del software que originalmente fue
propuesto por Boehm (1988), El modelo en espiral es una de
las metodologías más recomendables para el desarrollo
y creación de un programa, ya que consta de pocas etapas o
fases, las cuales se van realizando en una manera continua y cíclica.
La
espiral tiene una forma de caracola y se dice que mantiene dos dimensiones:
Angular: Indica el avance
del proyecto del software dentro de un ciclo.
Radial: Indica el aumento del coste del proyecto, ya que con cada nueva
iteración se pasa más tiempo desarrollando.
Cada ciclo de la espiral se divide
en 4 etapas:
DEFINICION DE OBJETIVOS:
Se definen los objetivos específicosSe identifican
las restricciones del procesos y el productoSe identifican los riesgos del proyecto, dependiendo de los riesgos, se planean
estrategias alternativas.EVALUACION Y REDUCCION DE RIESGOS:
Se lleva a cabo un análisis detallado para cada uno de los riesgos del proyecto.
Se definen los pasos para reducir
dichos riesgos.
DESARROLLO Y VALIDACION:
Se elige un modelo para el desarrollo
del sistema. Por ejemplo, si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo
apropiado podría ser la construcción
de prototipos
evolutivos.
El modelo de cascada
es el mas apropiado para el desarrollo si el mayor riesgo identificado es la integración de
los subsistemas.
PLANEACION:
El proyecto se revisa y se toma la decisión
de si se debe continuar con
un ciclo
posterior de la espiral.
ventajas
Entre sus ventajas están que al pasar a otro nivel se debe preguntar si se sigue, se repite o se anula el proyecto con esto nos evitamos errores y despilfarro de tiempo y dinero. Otra ventaja es que antes de que ocurra un problema nosotros podemos actuar y controlarlo.
Desventajas:
- Requiere mucha experiencia y habilidad para la evaluación de los riesgos, lo cual es requisito para el éxito del proyecto.
- Es difícil convencer a los grandes clientes que se podrá controlar este enfoque evolutivo.
Desarrollo 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.
De esta forma el tiempo de entrega se reduce considerablemente.
Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional.
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 grafica:
- 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).
También es una arquitectura muy natural en el paradigma de programación funcional, ya que equivale a la composición de funciones matemáticas.
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 planeació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 planeación, tanto administrativa como técnica.
- Requiere de metas claras para conocer el estado del proyecto.
