MODELOS DEL PROCESO DEL SOFTWARE

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.

Modelo Lineal Secuencial

Críticas:
      Proyectos reales raras veces se ajustan.
      Raras veces el cliente expone todos los requerimientos de entrada.
Consejo:
    Usar cuando todos los requerimientos han sido establecidos claramente de entrada.

Modelo de construccion de prototipos

• No están claros los requerimientos de entrada.
• Iterativo ¿Hasta cuando se itera?
• Working prototype, desechar y empezar con desarrollo de sistema.

 

Críticas:
   Cliente cree que es el sistema.
   Peligro de familiarización con malas elecciones iniciales (quick and dirty).

Consejo:
   Usar cuando inicialmente no están claros los requerimientos.

Modelo DRA (Desarrollo Rápido de Aplicaciones)

• Lineal secuencial con ciclo extremadamente corto.
• Candidatos: sistemas que se pueden modularizar => equipos de desarrollo paralelos.
• Basado en el uso de componentes y T4G.

Críticas:
  -Proyectos grandes => gran nro. de personas.
  - Alto compromiso en tiempo.
  - No apto para todo tipo de sistema (Ej. no modularizable, baja reusabilidad de componentes).
  -Desaconsejable cuando riesgos tecnológicos altos (Ej. Uso de nuevo lenguaje) o alta interoperatividad con programas ya existentes.

MODELOS EVOLUTIVOS

Se adaptan más fácilmente a los cambios introducidos a lo largo del desarrollo.
Iterativos. En cada iteración se obtienen versiones más completas del SW.

Modelos Evolutivos:

•           Modelo Incremental
•           Modelo en Espiral
•           Modelo de Desarrollo Basado en Componentes
•           Modelo WINWIN
•           Modelo de Desarrollo Concurrente

MODELO INCREMENTAL

• Iteración de Lineal Secuencial.
• Cada iteración devuelve un “Incremento” o versión operativa. (Ej. Editor de texto).
• Útil cuando no se está seguro de cumplir con plazos de tiempo o se tiene una fecha imposible de cambiar.

MODELO EN ESPIRAL

• Útil para proyectos grandes.
• Permite usar el prototipado en todas las etapas de la evolución para reducir el riesgo.
• Mantiene el enfoque sistemático de los pasos sugeridos por el lineal secuencial, pero lo incorpora dentro de un marco iterativo más real.

Críticas:

• Difícil de convencer a los clientes de que es controlable.
• Requiere mucha habilidad para el análisis de riesgos y de esta habilidad depende su éxito.
• No ha sido utilizado tanto como el lineal secuencial o el de prototipos

DESARROLLO BASADO EN COMPONENTES

• Basado en modelo en Espiral (evolutivo e iterativo) + Tecnologías de Objetos.
• Enfatiza la Reusabilidad.

Modelo de Métodos Formales

• Usan notación rigurosa.
• Especificaciones sin ambigüedades.
• Útiles para sistemas críticos.
• Demostraciones formales de propiedades.
• Dificulta validación con cliente => combinación con otras técnicas semi - formales.
• Alto nivel de experticia en lógica y matemática.

TÉCNICAS DE CUARTA GENERACIÓN (T4G)
Herramientas que facilitan la realización de especificaciones a alto nivel -> código fuente.
Basadas en Lenguajes de 4ta Generación (L4G).

Críticas:

• Código ineficiente.
• No mas fáciles de usar que L3G.
• Mantenimiento cuestionable.

Consejo:

• Aunque se usen T4G se debe hacer análisis, diseño y
• pruebas (sino mala calidad, mantenimiento pobre, baja
• aceptación por el cliente).