Modelos de Desarrollo de Software

Los modelos de desarrollo de software son una representacin

abstracta de una manera en particular. Realmente no
representa cmo se debe desarrollar el software, sino de un
enfoque comn. 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
debera escoger el ms apropiado para sus necesidades. En
ocasiones puede que una combinacin de varios modelos sea
apropiado. Existen tres paradigmas de los modelos de
desarrollo de software:
1. Paradigma Tradicional:
Es uno de los paradigmas ms antiguo, se invent durante la
creacin del mtodo estructurado. Si se elige un proyecto, el
mtodo varia en etapas. Como todo modelo, existen sus pros
y contras al usar este paradigma:

Si se aplica este paradigma, unos de los principales

problemas, es que las etapas realizadas no son autnomas de

las siguientes, creando una dependencia estructural y en el

caso de un error atrasara todo el proyecto. Se tiene que tener
pautas bien definidas, y que no se incurra a modificacin
porque implicara en que el software no cumpla con su ciclo
de vida. Tener en cuenta que el cliente no se vea afectado por
la impaciencia.3

2. Paradigma Orientado a Objetos: Estos modelos se

basan en la Programacin orientada a objetos; por lo tanto, se
refiere al concepto de clase, el anlisis de requisitos y el
diseo. El modelo o paradigma orientado a objetos posee dos
caractersticas principales, las cuales son:

Permite la re-utilizacin de software.

Facilita el desarrollo de herramientas informticas de apoyo al
desarrollo, el cual es simple al implementarla en una notacin
orientado a objetos llamado UML.4
3. Paradigma de Desarrollo gil: Es un paradigma de las
Metodologas De Desarrollo basado en procesos giles. Estos
intentan evitar los tediosos caminos de las metodologas
tradicionales enfocndose en las personas y los resultados.
Usa un enfoque basado en el Valor para construir software,
colaborando con el cliente e incorporando los cambios
continuamente.5
Modelo de cascada o Modelo Lineal o Secuencial.
El modelo de cascada define las siguientes etapas que deben
cumplirse de forma sucesiva:
1. Especificacin de requisitos
2. Diseo del software

3. Construccin o Implementacin del software

4. Integracin
5. Pruebas (o validacin)
6. Despliegue (o instalacin)
7. Mantenimiento
Siguiendo el modelo de cascada de forma estricta, slo
cuando se finaliza una fase, comienza la otra. En ocasiones se
realiza una revisin antes de iniciar la siguiente fase, lo que
permite la posibilidad de cambios (lo que puede incluir un
proceso de control formal de cambio). Las revisiones tambin
se utilizan para asegurar que la fase anterior ha sido
totalmente finalizada; los criterios para completar una fase se
conocen frecuentemente con el trmino ingls "gate"
(puerta). Este modelo desaconseja revisitar y revisar fases
que ya se han completado. Esta falta de flexibilidad en un
modelo de cascada puro ha sido fuente de crtica de los
defensores de modelos ms flexibles.

Modelo de espiral.
Desarrollo en espiral
La principal caractersticas del modelo en espiral es la gestin
de riesgos de forma peridica en el ciclo de desarrollo. Este
modelo fue creado en 1988 por Barry Boehm, combinando
algunos aspectos clave de las metodologas del modelo de
cascada y del desarrollo rpido de aplicaciones, pero dando
nfasis en un rea que para muchos no jug el papel que
requiere en otros modelos: un anlisis iterativo y concienzudo
de los riesgos, especialmente en el caso de sistema complejos
de gran escala.

La espiral se visualiza como un proceso que pasa a travs de

algunas interaciones con el diagrama de los cuatro cuadrantes
representativos de las siguientes actividades:

1. crear planes con el propsito de identificar los objetivos

del software, seleccionados para implementar el
programa y clarificar las restricciones en el desarrollo del
software;
2. Anlisis de riesgos: una evaluacin analtica de
programas seleccionados, para evaluar cmo identificar
y eliminar el riesgo;
3. la implementacin del proyecto: implementacin del
desarrollo del software y su pertinente verificacin;
Modelo de espiral con nfasis en los riesgos, haciendo
hincapi en las condiciones de las opciones y limitaciones
para facilitar la reutilizacin de software, la calidad del
software puede ayudar como una meta propia en la
integracin en el desarrollo del producto. Sin embargo, el
modelo en espiral tiene algunas limitaciones, entre las que
destacan:

El nfasis se sita en el anlisis de riesgo, y por lo tanto

requiere de clientes que acepten este anlisis y acten en
consecuencia. Para ello es necesaria confianza en los
desarrolladores as como la predisposicin a gastar ms para
solventar los temas, por lo cual este modelo se utiliza
frecuentemente en desarrollo interno de software a gran
escala.

Si la implementacin del riesgo de anlisis afectar de forma

esencial los beneficios del proyecto, no debera utilizarse este
modelo.
Los desarrolladores de software han de buscar de forma
explcita riesgos y analizarlos de forma exhaustiva para que
este modelo funcione.
La primera fase es la bsqueda de un plan para conseguir los
objetivos con las limitaciones del proyecto para as buscar y
eliminar todos los riesgos potenciales por medio de un
cuidadoso anlisis, y si fuera necesario incluyendo la
fabricacin de un prototipo. Si es imposible descartar algunos
riesgos, el cliente ha de decidir si es conveniente terminar el
proyecto o seguir adelante ignorando los riesgos. Por ltimo,
se evalan los resultados y se inicia el diseo de la siguiente
fase.

Desarrollo iterativo e incremental

El desarrollo iterativo recomienda la construccin de
secciones reducidas de software que irn ganando en tamao
para facilitar as la deteccin de problemas de importancia
antes de que sea demasiado tarde. Los procesos iterativos
pueden ayudar a desvelar metas del diseo en el caso de
clientes que no saben cmo definir lo que quieren.
Desarrollo gil
Desarrollo gil de software
El desarrollo gil de software utiliza un desarrollo iterativo
como base para abogar por un punto de vista ms ligero y
ms centrado en las personas que en el caso de las soluciones
tradicionales. Los procesos giles utilizan retroalimentacin en
lugar de planificacin, como principal mecanismo de control.

La retroalimentacin se canaliza por medio de pruebas

peridicas y frecuentes versiones del software.
Hay muchas variantes de los procesos giles:
En el caso de la programacin extrema (XP), las fases se
realizan en pasos muy cortos (o "continuos") con respecto al
anterior. El primer paso (intencionalmente incompleto) por los
pasos puede ocurrir en un da o en una semana, en lugar de
los meses o aos de cada paso completo en el modelo en
cascada. En primer lugar, se crean pruebas automatizadas
para proveer metas concretas al desarrollo. Despus se
programa el cdigo, que ser completo cuando todas las
pruebas se superan sin errores, y los desarrolladores ya no
sabran como mejorar el conjunto de pruebas necesario. El
diseo y la arquitectura emergen a partir de la refactorizacin
del cdigo, y se da despus de programar. El diseo lo
realizan los propios desarrolladores del cdigo. El sistema,
incompleto, pero funcional se despliega para su demostracin
a los usuarios (al menos uno de los cuales pertenece al equipo
de desarrollo). Llegado este punto, los profesionales
comienzan a escribir las pruebas para la siguiente parte del
sistema de ms importancia.

Codificacin y correccin
El desarrollo de codificacin y correccin (en ingls "Code and
fix") es, ms que una estrategia predeterminada, el resultado
de una falta de experiencia o presin que se ejerce sobre los
desarrolladores para cumplir con una fecha de entrega. Sin
dedicar tiempo de forma explcita para el diseo, los
programadores
comienzan
de
forma
inmediata
a
producir cdigo. Antes o despus comienza la fase de pruebas

de
software (a
menudo
de
forma
tarda)
y
los
inevitables errores que se encuentran han de eliminarse antes
de poder entregar el software.
Orientado a la Reutilizacin
La reutilizacin de software es un proceso donde se recurre al
uso de activos de software en las especificaciones de anlisis,
diseos, implementacin y pruebas de una aplicacin o
sistemas de software.8
La reutilizacin tiene ciertos Indicadores por ejemplo:
1. Entre el 40% y 60% de una aplicacin es reutilizable en
otra.
2. Aproximadamente el 60% de una aplicacin administrativa
es reutilizable.
3. Aproximadamente el 75% de las funciones son comunes a
ms de un programa.
4. Solo el 15% del cdigo encontrado en muchos sistemas es
unico y novedoso a una aplicacin especfica.
El rango general de uso recurrente esta entre el 15% y 85%.
La reutilizacin tiene Principios como la existencia de
parecidos en distintos sistemas de un mismo dominio, donde
el software puede representarse como una combinacin de
mdulos y los sistemas nuevos se puede caracterizar por
diferencias respecto a los antiguos sistemas.