EL PROCESO DE DESARROLLO DEL SOFTWARE

1
EL PROCESO DE DESARROLLO DEL SOFTWARE

• No existe un proceso de software universal que
  sea efectivo para todos los contextos de
  proyectos de desarrollo.

2
ACTIVIDADES FUNDAMENTALES DE TODOS LOS PROCESO DE
SOFTWARE

• Especificación de software
• Diseño e Implementación
• Validación
• Evolución

3
ALGUNOS MODELOS DE PROCESO DE SOFTWARE

• Codificar y corregir
• Modelo en cascada
• Desarrollo evolutivo
• Desarrollo formal de sistemas
• Desarrollo basado en reutilización
• Desarrollo incremental
• Desarrollo en espiral

4
CODIFICAR Y CORREGIR (CODE-AND-FIX)

• ETAPAS
• Codificar parte del software
• Corregir errores, agregar funcionalidad o nuevos
  elementos.

5
UTILIZACIÓN

• Desarrollo de software tarea unipersonal.
• El problema es claramente comprendido
• El programador es el usuario de la aplicación.
• La aplicación es simple según estándares actuales

6
DESVENTAJAS

• No se planifica ni se controla.
• Después de una serie de cambios
• La estructura del código se hace más y más
  complicada
• Los cambios siguientes son más y más difíciles.
• Los resultados son menos confiables.

7
DESVENTAJAS

• El software no satisface las necesidades ni las
  expectativas del cliente.
• La calidad no es adecuada.
• Productos terminados fuera de plazo y
  presupuesto.
• Cambios estructurales del software son casi
  imposibles.

8
CASCADA

• Se popularizó en la década de los 70 y guía la
  mayor parte de la práctica actual.
• El proceso es una cascada de fases, donde el
  producto de una fase es la entrada de la
  siguiente.
• Cada fase se compone de una serie de
  actividades que deben realizarse en paralelo.

9
DESCRIPCIÓN

• Este modelo admite hacer iteraciones, durante
  las modificaciones en el mantenimiento se puede
  ver por ejemplo la necesidad de cambiar algo en
  el diseño, lo cual significa que se harán los
  cambios necesarios en la codificación y se
  tendrán que realizar de nuevo las pruebas, si se
  tiene que volver a una de las etapas anteriores
  al mantenimiento hay que recorrer de nuevo el
  resto de las etapas.

10
FASES MODELO CASCADA

Cada fase tiene como resultado documentos que
deben ser aprobados por el usuario.
11

• Una fase no comienza hasta que termine la fase
  anterior y generalmente se incluye la corrección
  de los problemas encontrados en fases previas.
• En la práctica, este modelo no es lineal, e
  involucra varias iteraciones e interacción entre
  las distintas fases de desarrollo.

12
VENTAJAS

• La planificación es sencilla.
• La calidad del producto resultante es alta.
• Permite trabajar con personal poco cualificado.
• Con este modelo se tiene un seguimiento de todas
  las fases del proyecto y de su cumplimiento.

13
DESVENTAJAS

• Necesidad de tener todos los requisitos al
  principio.
• Si se han cometido errores en una fase es difícil
  volver atrás.
• No se tiene el producto hasta el final
• Si se comete un error en la fase de análisis no
  lo descubrimos hasta la entrega, gasto inútil de
  recursos.

14
DESVENTAJAS

• El cliente no verá resultados hasta el final, con
  lo que puede impacientarse .
• No se tienen indicadores fiables del progreso del
  trabajo
• Es comparativamente más lento que los demás y el
  coste es mayor también.

15
Tipos de proyectos para los que es adecuado

• Aquellos con todas las especificaciones desde el
  principio (reingeniería).
• Desarrollo de un tipo de producto que no es
  novedoso.
• Proyectos complejos que se entienden bien desde
  el principio.

16
VARIACIONES DEL MODELO EN CASCADA

• CICLO DE VIDA EN V
• Propuesto por Alan Davis, tiene las mismas
  fases que el cascada pero se considera el nivel
  de abstracción de cada una. Una fase además de
  utilizarse como entrada para la siguiente, sirve
  para validar o verificar otras fases posteriores.

17

• Ciclo de vida en V

18
VARIACIONES DEL MODELO EN CASCADA

• CICLO DE VIDA TIPO SASHIMI
• Se permite un solapamiento entre fases. Por
  ejemplo, sin tener terminado del todo el diseño
  se comienza a implementar. Una ventaja es que no
  necesita generar tanta documentación debido a la
  continuidad del mismo personal entre fases.

19
DESVENTAJAS

• CICLO DE VIDA TIPO SASHIMI
• Más difícil controlar el progreso del proyecto
  debido a que los finales de fase ya no son un
  punto de referencia claro.
• Al hacer cosas en paralelo si hay problemas de
  comunicación pueden surgir inconsistencias

20
ESTRUCTURA

• Ciclo de vida tipo sashimi

21
ESTRUCTURA

• CICLO DE VIDA TIPO SASHIMI
• La fase de concepto'' consiste en definir
  los objetivos del proyecto, beneficios, tipo de
  tecnología. El diseño arquitectónico es el de
  alto nivel, el detallado el de bajo nivel.

22
VARIACIONES DEL MODELO EN CASCADA

• CICLO DE VIDA EN CASCADA CON SUBPROYECTOS
• Al realizar el diseño arquitectónico, el
  sistema se divide en varios subsistemas
  independientes entre sí, estos se pueden
  desarrollar por separado y en consecuencia en
  paralelo con los demás. Cada uno tendrá
  seguramente fechas de terminación distintas. Una
  vez terminados todos se integran y se prueba el
  sistema en conjunto. La ventaja es tener a más
  gente trabajando en paralelo de forma eficiente.
  El riesgo es que existan interdependencias entre
  los subproyectos

23
VARIACIONES DEL MODELO EN CASCADA

• CICLO DE VIDA EN CASCADA INCREMENTAL
• Se va creando el sistema añadiendo pequeñas
  funcionalidades. Cada uno de los pequeños
  incrementos es parecido a lo que ocurre dentro de
  la fase de mantenimiento. La ventaja es que no es
  necesario tener todos los requisitos en un
  principio. El inconveniente es que los errores en
  la detección de requisitos se encuentran tarde.

24
ESTRUCTURA

• Ciclo de vida
• en cascada
• incremental

25
VARIACIONES DEL MODELO EN CASCADA

• CICLO DE VIDA EN CASCADA CON REDUCCIÓN DE RIESGOS
  
• Uno de los problemas del ciclo de vida en
  cascada es que si se entienden mal los requisitos
  esto sólo se descubrirá cuando se entregue el
  producto. Para evitar este problema se puede
  hacer un desarrollo iterativo durante las fases
  de análisis y diseño global

26
DESARROLLO

• CICLO DE VIDA EN CASCADA CON REDUCCIÓN DE
  RIESGOS
• Preguntar al usuario.
• Hacer diseño global que se desprende del punto 1.
  
• Hacer un prototipo de interfaz de usuario,
  entrevistas con los usuarios, etc y volver con
  ello al punto 1 para identificar más requisitos o
  corregir malentendidos.
• El resto es igual al ciclo de vida en cascada.

27
DESARROLLO ITERATIVO INCREMENTAL

• Forma de reducir la repetición del trabajo en
  el proceso de desarrollo y dar oportunidad de
  retrasar la toma de decisiones en los requisitos
  hasta adquirir experiencia con el sistema.
• Es una combinación del Modelo de Cascada y
  Modelo Evolutivo.

28
DESARROLLO ITERATIVO INCREMENTAL

• Bajo este modelo se entrega software por
  partes funcionales más pequeñas , pero
  reutilizables, llamadas incrementos. Cada
  incremento se construye sobre aquel que ya fue
  entregado.

29
DESARROLLO ITERATIVO INCREMENTAL

• Este es un modelo del tipo evolutivo, donde se
  permiten y esperan probables cambios en los
  requisitos en tiempo de desarrollo se admite
  margen para que el software pueda evolucionar.
  Aplicable cuando los requisitos son medianamente
  bien conocidos pero no son completamente
  estáticos y definidos.

30
DESARROLLO ITERATIVO INCREMENTAL

• La Descripción del Sistema es esencial para
  especificar y confeccionar los distintos
  incrementos hasta llegar al Producto global y
  final. Las actividades concurrentes
  (Especificación, Desarrollo y Validación)
  sintetizan el desarrollo pormenorizado de los
  incrementos, que se hará posteriormente.

31

32
DESARROLLO ITERATIVO INCREMENTAL

• Durante el desarrollo de cada incremento se
  puede utilizar el modelo de cascada o evolutivo,
  dependiendo del conocimiento que se tenga sobre
  los requisitos a implementar.

33
VENTAJAS

• No se espera hasta el fin del desarrollo para
  utilizar el sistema.
• Se pueden aclarar requisitos conforme se entrega
  el sistema.
• Se disminuye el riesgo de fracaso de todo el
  proyecto, ya que se puede distribuir en cada
  incremento.
• Las partes más importantes del sistema son
  entregadas primero, por lo cual se realizan más
  pruebas en estos módulos y se disminuye el riesgo
  de fallos.

34
DESVENTAJAS

• Cada incremento debe ser pequeño para limitar el
  riesgo (menos de 20.000 líneas).
• Cada incremento debe aumentar la funcionalidad.
• Es difícil establecer las correspondencias de
  los requisitos contra los incrementos.
• Es difícil detectar las unidades o servicios
  genéricos para todo el sistema.