algunas trasparencias de I. Sommerville

Transcripción

algunas trasparencias de I. Sommerville
Procesos del software
(selección de alguna de las trasparencias de Sommerville)
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 1
Modelos de proceso del software
genéricos
●
El modelo de cascada
•
●
Desarrollo evolutivo
•
●
Las actividades de especificación, desarrollo y validación se
llevan a cabo concurrentemente.
Ingeniería de software basada en los componentes
•
●
Se trata de fases de especificación de desarrollo distintas y
separadas.
El sistema se articula a partir de componentes ya existentes
Hay muchas variantes de estos modelos, por ejemplo, un
desarrollo formal en el que el proceso de cascada se usa
pero la especificación es una especificación formal que se
refina a través de varias fases hasta conseguir un diseño
implementable.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 2
Modelo de cascada
definición
De requerimientos
Diseño de sistemas
de sistemas y software
Implementación
y prueba de
unidades
Integración y
prueba del
sistema
Operación y
mantenimiento
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 3
Fases del modelo de cascada
●
●
●
●
●
●
Definición y análisis de los requerimientos
Diseño de sistemas y software
Implementación y prueba de unidades
Integración y prueba del sistema
Operación y mantenimiento
El principal inconveniente del modelo de cascada es la
dificultad de acomodar el cambio después de que el
proceso está en proceso. Una fase tiene que estar
completa antes de pasar a la siguiente fase.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 4
Problemas del modelo de cascada
●
●
●
●
La Inflexibilidad al dividir el proyecto en distintas
etapas hace difícil responder al cambio en los
requerimientos del cliente.
Entonces, este modelo sólo e apropiado cuando los
requerimientos se han entendido bien y los cambios
están bastante limitados durante el proceso de diseño.
Muy pocos sistemas de negocios tienen
requerimientos estables
El modelo de cascada se usa principalmente para
grandes proyectos de ingeniería de sistemas en los
que un sistema se desarrolla en varios sitios.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 5
Desarrollo evolutivo
●
Desarrollo exploratorio
•
●
El objetivo es trabajar con el cliente y evolucionar hacia
un sistema final desde un esbozo inicial de
especificación. Se debe empezar con unos
requerimientos bien comprendidos y añadir nuevos
atributos acordes con las propuestas del cliente.
Prototipos desechables
•
El objetivo es entender los requerimientos del sistema.
Se debe empezar con requerimientos que no se
comprenden del todo hasta clarificar lo que realmente
se necesita.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 6
Desarrollo evolutivo
Actividades
concurrente
s
Especificación
Esbozo de la
descripción
Desarrollo
Validación
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Versión inicial
Versiones
intermedias
Versión final
Slide 7
Desarrollo evolutivo
●
Problemas
•
•
•
●
Falta de visibilidad del proceso;
A menudo los sistemas tienen una estructura deficiente;
Pueden ser necesarias técnicas especiales especiales (P.Ej.:
en lenguajes para la rápida creación de prototipos).
Aplicabilidad
•
•
•
Para sistemas interactivos pequeños o de tamaño medio;
Para partes de grandes sistemas (P.Ej.: la interfaz del
usuario);
Para sistemas de corta vida
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 8
Iteración de procesos
●
●
●
Los requerimientos del sistema SIEMPRE
evolucionan en el transcurso de un proyecto,
así que la iteración del proceso en el que las
primeras etapas son revisadas siempre es
parte del proceso para grandes sistemas
La iteración puede aplicarse a cualquier
modelo de proceso genérico
Dos aproximaciones (relacionadas)
•
•
Desarrollo incremental;
Desarrollo en espiral.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 9
Desarrollo incremental
●
●
●
En lugar de desarrollar el sistema como una sola
unidad, el desarrollo y entrega se dividen en
incrementos con cada parte de incremento de
desarrollo de la funcionalidad requerida
Los requerimientos del usuario se priorizan y los
requerimientos de mayor prioridad se incluyen en los
primeros incrementos.
Una vez el desarrollo de un incremento ha
comenzado, los requerimientos se congelan aunque
los requerimientos para sucesivos incrementos
pueden continuar evolucionando.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 10
Desarrollo incremental
Definir esbozo
de
requerimientos
Desarrollar
incrementos del
sistema
Asignar requerimientos
a los incrementos
Validar incrementos
Diseñar
arquitectura del
sistema
Integrar
incrementos
Validar sistema
Sistema final
Sistema incompleto
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 11
Ventajas del desarrollo incremental
●
●
●
●
Los clientes no tienen que esperar hasta que el
sistema completo se entregue para sacar provecho de
él. El primer incremento satisface los requerimientos
más críticos de tal forma que el software está
disponible para su uso inmediato.
Los primeros incrementos actúan como prototipo para
ayudar a obtener los requerimientos para incrementos
posteriores.
Bajo riesgo de fallar en el proyecto total
Los servicios de alta prioridad del sistema tienden a
ser más probados.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 12
Programación extrema
●
●
●
Una aproximación al desarrollo basado en el
desarrollo y entrega de una pequeñísima parte
de los incrementos de funcionalidad.
Depende de la constante mejora del código, la
implicación del usuario en el equipo de
desarrollo y la programación por parejas.
Tratado en el tema 17
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 13
Desarrollo en espiral
●
●
●
●
el proceso se representa como una espiral en
lugar de como una secuencia de actividades
con retroceso.
Cada vuelta en la espiral representa una fase
en el proceso
No hay fases fijas tales como la especificación
o el diseño – las vueltas en la espiral se
escogen dependiendo de lo que se refiere.
Los riesgos se valoran explícitamente y se
resuelven durante el proceso.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 14
Modelo en espiral para el proceso de
Software
Determinar objetivos,
alternativas y
restricciones
Evaluar alternativas e
identificar y resolver riesgos
Análisis
de riesgos
Análisis de
riesgos
Análisis
de riesgos
RREVISIÓN
Análisi
Prototipo 2
s de
riesgo Prototipo 1
s
Plan de requerimientos
Plan de ciclo de vida
Concepto de
operación
Simulaciones, modelos, pruebas comparativas
Requerimiento
s del software
Plan de desarrollo Validación de
requerimientos
Planear la siguiente fase
Integración y
plan de
prueba
Diseño de V&V
servicio
©Ian Sommerville 2004
Prototipo
operacional
Prototipo 3
Prueba de
aceptación
Diseño del producto
Diseños
detallado
código
Prueba de
unidades
prueba de
integración
Desarrollo, verificar producto
del siguiente nivel
Software Engineering, 7th edition. Chapter 4
Slide 15
Sectores del modelo en espiral
●
Definición de objetivos
•
●
Evaluación y reducción de riesgos
•
●
Los riesgos se valoran y colocan en un sitio que
reduzca los riesgos clave
Desarrollo y validación
•
●
Se definen los objetivos específicos para cada fase.
Se escoge un modelo de desarrollo para el sistema
que puede ser cualquiera de los modelos genéricos.
Planeación
•
El proyecto se revisa y la siguiente fase de la espiral es
planeada.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 16
El Proceso Unificado Racional
●
●
Es un modelo de proceso moderno que deriva del
trabajo sobre el UML y procesos asociados.
Normalmente se describe desde 3 perspectivas
•
•
•
Una perspectiva dinámica que muestra las fases en el
tiempo;
Una perspectiva estática que muestra las actividades
de proceso.
Una perspectiva práctica que sugiere buenas prácticas
para usar durante el proceso.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 17
Modelo de fase RUP
Fase de iteración o evolución
Origen
©Ian Sommerville 2004
Elaboración
construcción
Software Engineering, 7th edition. Chapter 4
Transición
Slide 18
Fases RUP
●
Origen
•
●
Elaboración
•
●
Desarrollo y comprensión del ámbito del problema
y de la arquitectura del sistema.
Construcción
•
●
Establecer el caso del negocio para el sistema
Diseño, programación y prueba del sistema.
Transición
•
Despliegue del sistema en su entorno de
explotación.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 19
Buena práctica del RUP
●
●
●
●
●
●
Desarrollo del software de forma evolutiva
Requerimientos de dirección
Usar arquitecturas basadas en componentes.
Modelos de software visuales
Verificar la calidad del software
Controlar los cambios para el software
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 20
Puntos clave
●
●
●
●
●
Los procesos de software son las actividades implicadas en
la producción y evolución de un sistema de software
Los modelos de proceso de software son representaciones
abstractas de esos procesos
Las actividades generales son la especificación, diseño e
implementación, validación y evolución.
Los ejemplos incluyen el modelo de cascada, el desarrollo
evolutivo y la ingeniería de software basada en los
componentes.
Los modelos de proceso evolutivos describen los procesos
de software como un ciclo de actividades.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 4
Slide 21

Documentos relacionados