ISO_02

1

Modelo de Procesos

Ingeniería del Software

Ing. Jesús B. Olavarria Paz

2

Proceso y Modelo de Procesos

Es un conjunto estructurado de actividades que tienen como resultado la producción de un producto de software

Es una representación abstracta de un proceso de software.

Representa una descripción de un proceso desde una perspectiva particular

Qué es un proceso de SW?Qué es un modelo de procesode SW?


Paradigmas de Procesos

• Son modelos de procesos muy generales presentados desde un punto de vista arquitectónico.

• Ejemplos de paradigmas de procesos:

– Modelo en cascada

– Desarrollo evolutivo

– Ingeniería del Software (IS) basada en componentes

– Desarrollo formal de sistemas


Procesos del Software

• Definen el “ciclo de vida”

• Diferentes modelos de procesos del software

• Actividades de un proceso genérico


Modelo de Procesos

• Cada esfuerzo de desarrollo de software pasa por un ciclo de vida, un proceso que incluye todas las actividades del ciclo de desarrollo que tienen que ver con el lanzamiento inicial. La función principal del modelo de ciclo de vida es establecer el orden en que un proyecto especifica, implementa, prueba y realiza sus actividades. El modelo de ciclo de vida. apropiado puede hacer dinámico su proyecto y asegura ayuda en cada paso acercándose más al objetivo.

• Dos de los modelos de ciclo de vida más populares son el modelo tradicional de cascada (Waterfall Waterfall) y el modelo Espiral o modelo de desarrollo de aplicaciones rápida (RAD).


Ciclo de vida del Software

• “Una aproximación lógica a la adquisición, el suministro, el

desarrollo, la explotación y el mantenimiento del software”

IEEE 1074

• “Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el

mantenimiento de un producto de software, abarcando la vida del

sistema desde la definición de los requisitos hasta la finalización de su uso”

ISO 12207-1


2

Procesos del ciclo de vida del Software

PROCESOS PRINCIPALES

ADQUISICIÓN

SUMINISTRO

DESARROLLO

EXPLOTACIÓN

MANTENIMIENTO

PROCESOS DE SOPORTE

DOCUMENTACIÓN

GESTIÓN DE CONFIGURACIÓN

ASEGURAMIENTO DE CALIDAD

VERIFICACIÓN

VALIDACIÓN

REVISIÓN CONJUNTA

AUDITORIA

RESOLUCIÓN DE PROBLEMAS

PROCESOS DE LA ORGANIZACIONGESTIÓN

MEJORA

INFRAESTRUCTURA

FORMACIÓN


Procesos Principales

• Proceso de Adquisición

• Proceso de Suministros

• Procesos de desarrollo I

– Análisis de Requisitos del Sistema

– Diseño de la Arquitectura del Sistema

– Análisis de Requisitos del Software

– Diseño de la Arquitectura del Software

– Diseño detallado del Software

– Codificación y Prueba del Software



• Procesos de desarrollo II

– Integración del Software

– Prueba del Software

– Integración del Sistema

– Prueba del Sistema

– Instalación del Software

– Soporte del proceso de Aceptación del Software

• Proceso de Explotación

• Proceso de Mantenimiento



• Procesos de desarrollo II

– Integración del Software

– Prueba del Software

– Integración del Sistema

– Prueba del Sistema

– Instalación del Software

– Soporte del proceso de Aceptación del Software

• Proceso de Explotación

• Proceso de Mantenimiento


Procesos PrincipalesIngeniería del Software

Modelo en Cascada

• En el modelo de cascada, un proyecto progresa a través de pasos secuenciales desde el concepto inicial a través de pruebas del sistema. Este modelo trabaja bien para proyectos complejos en que puede especificar fácilmente al principio los requisitos. Este modelo usa puntos de observación (Milestones) como la transición y puntos de valoración.

• Criticas

– No refleja realmente el proceso de desarrollo del software.– Se tarda mucho tiempo en pasar por todo el ciclo.

– Perpetua el fracaso de la industria del software en su comunicación con el usuario final.

– El mantenimiento se realiza en el código fuente.

– Las revisiones de proyectos de gran complejidad son muy difíciles– Impone una estructura de gestión de proyectos


3

Modelo en Cascada

AnálisisRequisitosSistema

Análisis RequisitosSoftware

Diseño Preliminar

Diseño Detallado

Codificación y Pruebas

Explotación yMantenimiento


Modelo Incremental

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


Modelo Incremental

A. Requisitosdel Sistema

A. RequisitosSoftware

Diseño

Codificación


Diseño

Codificación

…A. Requisitos

Software

Diseño

Codificación


Modelo de Prototipo

• No modifica el flujo del ciclo de vida.

• Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios.

• Reduce costos y aumenta la probabilidad de éxito.

• Exige disponer de las herramientas adecuadas.

• No presenta calidad ni robustez

• Una vez identificados todos los requisitos mediante el prototipo, se construye el producto de ingeniería.


Modelo de PrototipoIngeniería del Software

Prototipado “Rápido”

A. Requisitosdel Sistema


DiseñoPreliminar

Diseñodetallado

Codificación

Pruebas

Operación y Mantenimiento

Prototipo

Prototipo

Prototipo


4

El Prototipado

Para que sea efectivo

– Debe ser un sistema con el que se pueda experimentar

– Debe ser comparativamente barato (< 10%)

– Debe desarrollarse rápidamente

– Énfasis en la interfaz de usuario

– Equipo de desarrollo reducido

– Herramienta y lenguajes adecuados

“El prototipado es un medio excelente para recoger el “feedback” (realimentación) del usuario final”.


El Prototipado

Peligros del Prototipado

• El cliente ve funcionando lo que para el es la primera versión del prototipo que ha sido construido con “plastilina y alambres”, y puede desilusionarse al decirle que el sistema aun no ha sido construido.

•

• El desarrollador puede caer en la tentación de ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y de mantenimiento que tiene con el cliente.


El Prototipado

El Prototipado Evolutivo

• Construcción de una implementación parcial que cubre los requisitos conocidos, para ir aprendiendo el resto y, paulatinamente, incorporarlos al sistema.

• Reduce el riesgo y aumenta la probabilidad de éxito.

• No se conocen niveles apropiados de calidad y documentación.

• Problemas de gestión de configuración

Construir software para que pueda ser modificado facilmente es un “arte desconocido”.


El Prototipado OperacionalIngeniería del Software

Modelo en Espiral

• El modelo espiral es un modelo orientado a riesgos que divide un proyecto de software en subproyectos diferentes. Cada subproyecto toma uno o más riesgos hasta que todos se identifiquen. El modelo espiral permite el incremento de la creatividad y la buena administración de riesgos debido a su naturaleza reiterativa.


Modelo en EspiralIngeniería del Software

5

Modelo en EspiralIngeniería del Software

Modelo en Espiral

Diferencia entre modelo en espiral y modelos tradicionales.

• Reconocimiento explícito de las diferentes alternativas.

• Identificación de riesgos para cada alternativa desde el comienzo.

• Al dividir el proyecto en ciclos, al final de cada uno existe un acuerdo para los cambios que hay que realizar en el sistema.

• El modelo se adapta a cualquier tipo de actividad adicional.


Procesos guiados por hitos

• Los hitos son puntos de revisión y sincronización, no puntos de congelamiento.

• Los hitos permiten al equipo determinar progreso y hacer correcciones en el camino.

• Los modelos de procesos usan dos tipos de hitos.

– Hitos principales

– Hitos interinos

• Alcanzar un hito principal representa un acuerdo entre el equipo y el cliente de continuar.

• Las entregas son la evidencia física de que los equipos alcanzaron un hito.


Responsabilidades guiadas por hitos

Hitos Conductor Primario

Visión Aprobada

Plan de proyecto Aprobado

Alcance Completado

Entrega

Gerente de Producto

Gerente de Desarrollo

Desarrollador y Formaciónde Usuarios

Testing y Gerente de Logística


Principios y Practicas de Modelo de Procesos

• Usando entregas con versiones.

• Cronogramando para un futuro incierto

• Administrando trade-offs

• Administrando Riesgos

• Manteniendo una fecha fija

• Seccionando proyectos largos en partes manejables manejables

• Realizando construcciones diarias

• Usando estimaciones a fondo (botton- up)


Usando entregas con versiones

• No importa cuán rápido avanza el equipo del proyecto, el mercado, la tecnología, la competencia, o el cliente comercial querrá ir más rápidamente. Las entregas con versiones permiten al equipo del proyecto responder a los cambios continuos en el alcance, cronograma, y riesgo del proyecto. Frecuentemente poniendo al día el producto, no sólo hace que el equipo de desarrollo se comunique con el cliente, pero las sugerencias para las versiones futuras del producto vienen directamente del uso del cliente del producto.

• El equipo entrega un conjunto de rasgos centrales en su primera versión y agrega los rasgos incrementalmente en los entregas posteriores hasta que logre la visión completa para el producto. Versiones posteriores permiten el equipo revalidar o actualizar la visión de producto como cambios en los requerimientos del negocio.


6

Usando entregas con versiones

• Promueve la comunicación frecuente y honrada entre el equipo y el cliente. La entrega refleja sus mejores ideas.

• Permite al equipo del proyecto entregar la funcionalidad crítica más temprano y obtener la retroalimentación del cliente para las entregas futuras.

• Fuerza el cierre de los problemas del proyecto a través de la fase de estabilización cuando el equipo del proyecto direcciona todos los problemas con el proyecto antes de la entrega.

• Configura metas claras y motivadoras para todos los miembros del equipo.

• Maneja la incertidumbre y cambia en el alcance del proyecto permitiendo al equipo variar los rasgos y el cronograma en relación a otros para un conjunto específico de rasgos en un plan de tecnología global.

• Anima la entrega continua incrementando rasgos.


Principio de un proceso exitoso

• Crear documentación actualizada

• Utilizar entregas versionadas

• Hacer compensaciones del proyecto


Matriz de las compensaciones del proyectoIngeniería del Software

Actividades de los Procesos

• Hay cuatro actividades básicas en cualquier proceso software:

– Especificación del software

– Desarrollo del software

– Validación del software

– Evolución del software

• Se organizan de forma distinta en los diferentes procesos de desarrollo.



• Especificación del Software: Es el proceso de establecer que servicios se requieren y cuales son las restricciones sobre las operaciones y el desarrollo.

Estudiode Factibilidad

Elicitación yAnálisis requerim.

Especificaciónde requerim.

Validaciónde requerim.

Informe deFactibilidad

Modelos delSistema

Req. Usuario y del Sistema

DocumentoDe requerim.



• Desarrollo: Un diseño software es una descripción de la estructura del software a implementar, de los datos, interfaces entre los componentes y algoritmos.

RequerimentsSpecification

Systemarchitecture

Architecturaldesign

AbstractSpecification

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Softwarespecificacion

Interfacespecificacion

Componentspecificacion

Data structure

specification

Algorithmspecificacion

Actividades del diseño

Productos del diseñoLa implementación es el proceso de convertir una especificación del sistema en un sistema ejecutable. Se trata de una actividad personal y Normalmente no se sigue un proceso general.


7


• Validación: La verificación y validación (V&V) pretende demostrar que un sistema cumple sus especificaciones y satisface las espectativas del cliente.

Prueba deComponentes

Plan pruebaaceptación

Prueba delSistema

Prueba deAceptación

Especif.Requerim,

Especif.sistema

Diseñosistema

Diseñodetallado

Plan integrac.sistema

Plan integrac.subsistema

ServicioPruebas

aceptaciónPrueba integrac.

sistemaPrueba integrac.

subsistema

Pruebas unidad ymódulo

validación verificación



• Evolución:

– El software es inherentemente flexible y puede cambiar (durante y después del desarrollo)

– Si bien hay una diferencia clara entre desarrollo y evolución (mantenimiento), dicha diferencia se convierte en irrelevante desde el momento en que cada vez menos sistemas son completamente nuevos.

Evaluación sistemaactual

Definir requerim.del sistema

Proponer cambiosen el sistema

ModificarSistema




Proceso Unificado de Rational (RUP)

• RUP constituye un marco de trabajo para el desarrollo de procesos: puede acomodarse a una amplia variedad de procesos.

• Muestra el proceso de desarrollo desde tres perspectivas:

– Dinámica: muestra las fases del proceso a lo largo del tiempo

– Estática: muestra las actividades a realizar del proceso

– Práctica: sugiere buenas prácticas a utilizar durante el proceso


Conceptos Clave de RUP

• Fases e Iteraciones

• Disciplinas

– Actividades

• Artefactos

– Modelos

– Informes, documentos

• Roles

¿Cuándo tienen lugar?

¿Qué hay que hacer?

¿Qué se produce?

¿Quién lo hace?


Proceso de Desarrollo de Software

• Un proceso de desarrollo de software es un conjunto de actividadesnecesarias para transformar los requisitos de un usuario en unsistema de software.

Sistema SoftwareProceso de Desarrollo de software

Requisito del usuario


Problemas en el desarrollo del software

• Retrasos en los plazos.

• Proyectos cancelados

• Rápido deterioro del sistema instalado

• Tasa de defectos o fallos

• Requisitos mal comprendidos

• Cambios frecuentes en el dominio del problema

• Muchas de las interesantes características del software noproporcionan beneficios al cliente.

• Buenos programadores se cansan y dejan el equipo


8

Un proceso Iterativo e Incremental

• Un proceso de desarrollo de software debe tener una secuencia dehitos claramente articulados para ser eficaz, que proporcionen a losdirector y al resto del equipo del proyecto los criterios que necesitanpara autorizar el paso de una fase a la siguiente dentro del ciclo delproducto.

• Un proceso iterativo es aquel que involucra la gestión de un flujo deejecutables del sistema.


Porque un desarrollo Iterativo e Incremental

• Para tomar la rienda de los riesgos críticos y significativos desde elprincipio.

• Para poner en marcha una arquitectura que guíe el desarrollo delsoftware.

• Para proporcionar un marco de trabajo que gestione de mejor formalos inevitables cambios en los requisitos y en otros aspectos.


Porque un desarrollo Iterativo e Incremental

• Para construir el sistema a lo largo del tiempo en lugar de hacerlode una sola vez cerca del final, cuando el cambiar algo se ha vueltocostoso.

• Para proporcionar un proceso de desarrollo a traves del cual elpersonal pueda trabajar de manera mas eficaz.

En resumen: “Para obtener un software mejor”


Fases del Ciclo de vida - RUP

inicio Elaboración Construcción Transición

time

Inicial: define el alcance del proyecto y el limite del sistema

Elaboración: Plan de Proyecto, características, y la línea base de la arquitectura.

Construcción: Se construye el producto.

Transición: entrega del producto entregable


Fases del Ciclo de vida - RUP

El Proceso Unificado se puede describir en dos dimensiones a lo largo de dos ejes:• El eje horizontal representa el tiempo y muestra al aspecto dinámico del

proceso, esto expresado en ciclos, fases, iteraciones e hitos.

• El eje vertical representa el aspecto estático del proceso, esto es expresadopor actividades, artefactos, workers y flujo de trabajo.


Fases e Iteración

inicio Elaboración Construcción Transición

Prelim iteration

… Arch iteration

…Dev iteration

…Dev iteration

Trans iteration …

Release Release Release Release Release Release Release Release

Una fase es el intervalo de tiempo entre dos hitos importantes del proceso.

Una iteración es una sucesión de actividades con un plan establecido y criterio de evaluación, mientras se va produciendo las versiones del sistema.


Documents

ISO_02