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

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.