c
 
  




Los estándares establecen los diferentes procesos implicados a la hora de
desarrollar y mantener un sistema desde que surge la idea o necesidad de
desarrollar las aplicaciones hasta que éstas se retiran de explotación. Sin
embargo, ninguno impone un modelo de procesos concreto (modelo de ciclo de
vida) ni cómo realizar las diferentes actividades incluidas en cada proceso, por lo
que cada empresa deberá utilizar los métodos, técnicas y herramientas que
considere oportuno.

Por su naturaleza, los modelos son simplificaciones; por lo tanto, un modelo de

procesos del software es una simplificación o abstracción de un proceso real.
Podemos definir un modelo de procesos del software como una representación
abstracta de alto nivel de un proceso software.

Cada modelo es una descripción de un proceso software que se presenta desde

una perspectiva particular. Alternativamente, a veces se usan los términos ciclo de
vida y Modelo de ciclo de vida.

Cada modelo describe una sucesión de fases y un encadenamiento entre ellas.

Según las fases y el modo en que se produzca este encadenamiento, tenemos
diferentes modelos de proceso. Un modelo es más adecuado que otro para
desarrollar un proyecto dependiendo de un conjunto de características de éste.
Existe una gran variedad de modelos diferentes entre los que tenemos los que se
describen a continuación.
c
  


c
  


  


El más conocido, está basado en el ciclo convencional de una ingeniería, el

paradigma del ciclo de vida abarca las siguientes actividades:

Dngeniería y Análisis
del Sistema

Análisis de los
Requisitos

Diseño

Codificación

Prueba

Mantenimiento

   
  Debido a que el software es siempre parte de

un sistema mayor el trabajo comienza estableciendo los requisitos de todos los
elementos del sistema y luego asignando algún subconjunto de estos requisitos al
software.

  
      
    el proceso de recopilación de los

requisitos se centra e intensifica especialmente en el software. El ingeniero de
software (Analistas) debe comprender el ámbito de la información del software, así
como la función, el rendimiento y las interfaces requeridas.

YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
Y
 !  el diseño del software se enfoca en cuatro atributos distintos del
programa: la estructura de los datos, la arquitectura del software, el detalle
procedimental y la caracterización de la interfaz. El proceso de diseño traduce los
requisitos en una representación del software con la calidad requerida antes de
que comience la codificación.


  " el diseño debe traducirse en una forma legible para la maquina. El

paso de codificación realiza esta tarea. Si el diseño se realiza de una manera
detallada la codificación puede realizarse mecánicamente.

#$ una vez que se ha generado el código comienza la prueba del programa.
La prueba se centra en la lógica interna del software, y en las funciones externas,
realizando pruebas que aseguren que la entrada definida produce los resultados
que realmente se requieren.

c: el software sufrirá cambios después de que se entrega al cliente.

Los cambios ocurrirán debidos a que hayan encontrado errores, a que el software
deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos
periféricos), o debido a que el cliente requiera ampliaciones funcionales o del
rendimiento.



˜ Los proyectos reales raramente siguen el flujo secuencial que propone el

modelo, siempre hay iteraciones y se crean problemas en la aplicación del
paradigma.
˜ Normalmente, es difícil para el cliente establecer explícitamente al principio
todos los requisitos. El ciclo de vida clásico lo requiere y tiene dificultades
 en acomodar posibles incertidumbres que pueden existir al comienzo de
muchos productos.
˜ El cliente debe tener paciencia. Hasta llegar a las etapas finales del
proyecto, no estará disponible una versión operativa del programa. Un error
importante no detectado hasta que el programa este funcionando puede ser
desastroso.
La ventaja de este método radica en su sencillez ya que sigue los pasos
intuitivos necesarios a la hora de desarrollar el software.

c
 %c   

 &

'

El Modelo V tiende a ser muy relacionado con el Modelo de Cascada

puesto que es una evolución del mismo.

Los planes de prueba son  

el nexo entre el desarrollo
y la verificación

 
 Plan de
"#

Pruebas
de Aceptación
X


 


Plan de

 
 "#

Pruebas
del Sistema

X




  Plan de "#


Pruebas
de Dntegración

cc
 

 c
 Puede notarse que su primera mitad es similar al Modelo en Cascada, y la
otra mitad tiene como finalidad hacer pruebas e integración asociado a cada una
de las etapas de la mitad anterior.

Se puede identificar una ventaja principal con respecto al Modelo Cascada

más simple, y se refiere a que este modelo involucra chequeos de cada una de las
etapas del modelo de cascada.



˜ El riesgo es mayor que el de otros modelos, pues en lugar de hacer

pruebas de aceptación al final de cada etapa, las pruebas comienzan a
efectuarse luego de haber terminado la implementación, lo que puede traer
como consecuencia un ³roll-back´ de todo un proceso que costó tiempo y
dinero.
˜ El modelo no contempla la posibilidad de retornar a etapas inmediatamente
anteriores, cosa que en la realidad puede ocurrir.
˜ Se toma toda la complejidad del problema de una vez y no en iteraciones o
ciclos de desarrollo, lo que disminuye el riesgo.
A pesar de todo lo antes mencionado, definitivamente se trata de un modelo
más robusto y completo que el Modelo de Cascada, y puede producir software de
mayor calidad que con el modelo de cascada.

c
  $

Este modelo, también no secuencial, es algo más complejo que los anteriores,
aunque incluye un elemento muy útil e importante en el desarrollo del software:
análisis de riesgos. El modelo en espiral concreta cuatro fases:

- Planificación
- Análisis de Riesgos

- Dngeniería (Construcción del prototipo)

- Evaluación por el cliente

Si ésta última fase es afirmativa, el modelo continúa con la estructura del Ciclo de
vida Clásico. Si el cliente no está satisfecho con el resultado, se cubre otra banda
de la espiral y se vuelve a la primera fase (de planificación).

  % "

% 


&'(')*'+

Dentro del proceso evolutivo hablaremos de ³El modelo Espiral´ y su evolución.

M Forma de espiral
M METAMODELO de Procesos
M Aparece el Análisis de Riesgo
M Recorrido se realiza desde el centro y en sentido horario.

Fig1.- Evolución del modelo espiral ³Boehm 88´

c(')*',)-

Fig.2.-Evolucion del modelo espiral ³Pressman 98´

c(')*'()($

Fig3.- Evolución del modelo espiral ³pressman 98´


#./*,01
M Para aplicaciones basadas en Web

Fig.4.- Evolución del modelo espiral ³pressman 2002

c
  c

$

El modelo incremental es una evolución del modelo de cascada; viene a suplir el

problema de no poder retroceder en las fases de desarrollo del software. Es, por
tanto, un modelo no secuencial.

El funcionamiento es sencillo. Comienza con el análisis de los requisitos, tras el

cual se prepara un primer diseño. La novedad de este modelo respecto del
anterior, es la introducción de iteraciones para ³bifurcar´ diseños. Es decir, este
modelo ofrece la posibilidad de comenzar un diseño, arquitectura, estructura, etc
del software, que de no convencer al cliente (o al propio programador) es
rechazado y se comienza con una segunda iteración (o un segundo diseño), sin
necesidad de realizar un nuevo análisis de requisitos. Pueden realizarse tantas
iteraciones (también llamadas incrementos) como sean necesarias.
'c('-*')2(*32,4*/*4-

˜ 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.

Fig5.- El Modelo Dncremental 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 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.

%

- 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.



:

- El modelo Dncremental 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.




















##  

http://rguerrero334.blogspot.es/img/Modelos_de_procesos_del_software.pdf

http://www.mitecnologico.com/Main/ModeloDncremental

http://translate.google.com.mx/translate?hl=es&langpair=en|es&u=http://www.cave
hill.uwi.edu/staff/eportfolios/paulwalcott/courses/comp2145/2009/software_process
_models.htm