7. el proceso software - infor.uva.esmlaguna/is1/apuntes/7-proceso.pdf · y disciplinado para...

1

7. El Proceso Software

Ingeniería del Software I3º I.T.I.Gestión

Miguel A. Laguna

Contenidos

7.1 Modelos de Proceso7.1.1 Modelos genéricos de desarrollo 7.1.2 Métodos de desarrollo orientados a objetos

7.2 El Proceso Unificado de Desarrollo o UnifiedProcess7 3 Fases y disciplinas (o flujos de trabajo)7.3 Fases y disciplinas (o flujos de trabajo)

7.3.1 Fases y puntos de control7.3.2 Disciplinas (flujos de trabajo) 7.3.3 Artefactos

7.4 La fase de Inicio (Inception)7.5 La fase de Elaboración7.6 Las fases de Construcción y Transición

Objetivos del tema

Conocer los distintos modelos de proceso genéricos

Conocer las tendencias actuales en metodología de

desarrollo y los esfuerzos de estandarización

Aprender los principios del Proceso Unificado

Aprender la diferencia ente fase y disciplina en el

Proceso Unificado

Relacionar las técnicas de modelado de UML con las

fases y disciplinas del Proceso Unificado

7.1. Modelos de Proceso

7.1.1 Modelos genéricos de desarrollo 7.1.2 Métodos de desarrollo

orientados a objetos

¿Qué es un método?

Resulta necesario establecer un enfoque sistemático y disciplinado para llevar a cabo un desarrollo software

Definiciones:

5

Definiciones:Una metodología de ingeniería del software es un proceso para producir software de forma organizada, empleando una colección de técnicas y convenciones de notación predefinidas

(James Rumbaugh et al.)

Conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo software

(Mario Piattini et al.)

El desarrollo de un sistema se puede explicar también como:

Una secuencia de modelados que ayuda a construir, a partir de la realidad, uno o varios modelos,

Otra visión de Método

6

p , ,derivados unos de otros, con el objetivo de lograr un modelo final o sistema.

Y entonces:Un método es una guía que define las reglas de paso de un modelo a otro para evolucionar progresivamente hasta el modelo final.

2

Modelado

REALIDAD

Lenguaje de especificación

7

Los modelos son representaciones semánticas simplificadas de un sistema para analizarlo y comprenderlo a fin de diseñarlo mejor.

IMPLEMENTACIÓNLenguaje de Programación

Modelos

PROCESO

TECNICAS

HERRAMIENTASUML

UP

TogetherRose

Componentes de un método

Proceso: Define el marco de trabajo y permite un desarrollo racional de la IS

Técnicas: Indican cómo construir técnicamente el software. Incluyen técnicas de modelado

Herramientas: Proporcionan el soporte automático o semiautomático para el proceso y para las técnicas

UP

El proceso software

Un conjunto estructurado de actividades y resultados asociados que conducen a la creación de un producto de software

Especificación: Definir la funcionalidad y las restricciones en sus operacionesDiseño e implementación: Producir software que cumple la especificaciónpValidación: Asegurar que hace lo que el cliente desea.Evolución: Seguir cumpliendo los cambios en las necesidades del usuario.

Un modelo de proceso es una representación abstracta de un proceso. Presenta una descripción de un proceso desde una perspectiva particular.

7.1.1 Modelos genéricos de desarrollo

Modelos de proceso genéricos

No son descripciones exhaustivas de los procesos software.Son abstracciones útiles que explican diferentes enfoques utilizables a la hora de desarrollar software.Son marcos de trabajo del proceso, no detallan las actividades específicas.Se denominan paradigmas de proceso

Modelos de proceso genéricos

El modelo de cascadaSepara y distingue cada fases de especificación y desarrollo

Desarrollo evolutivoSe interpolan la especificación y el desarrollo

Desarrollo formal de sistemasUn modelo matemático del sistema se transforma formalmente a una implementación

Desarrollo basado en reutilizaciónEl sistema se monta a partir de componentes existentes

3

Modelo en Cascada

Definición de Requisitos

Diseño del sistema y del software

Implementación y prueba de unidades

Integración y prueba del sistema

Operación y mantenimiento

Fases del modelo en cascada

Análisis y definición de requisitosDiseño del sistema y del softwareImplementación y prueba de unidadesIntegración y prueba del sistemaO ió t i i tOperación y mantenimiento

Una fase no comienza hasta que no hayan terminado las anteriores.La desventaja es la dificultad de tener en cuenta los cambios cuando el proceso ya está en marcha

Problemas del Modelo en cascada

Inflexibilidad al dividir el proyecto en estas etapasEs difícil responder a los cambios en los requisitos del clientePor lo tanto este modelo es apropiado sóloPor lo tanto, este modelo es apropiado sólo cuando los requisitos se comprenden muy bien.

Desarrollo evolutivo

Desarrollar una implementación inicial e ir refinándola hasta conseguir el sistema adecuado. Las actividades se realizan concurrentemente.Desarrollo exploratorio

El objetivo es trabajar con los clientes y desarrollar un sistema final con alguna gespecificación inicial. Se debe comenzar teniendo en cuenta los requisitos bien-entendidos. El sistema evoluciona según la nuevas propuestas del cliente.

Prototipos desechablesEl objetivo es comprender los requisitps del cliente y desarrollar un prototipo para evaluar hasta qué punto se han entendido.

Desarrollo evolutivo

Versión Inicial

Actividades concurrentes

Especificación

Bosquejo de la descripción

Versión final

Versiones intermedias



Desarrollo

Validación

Desarrollo evolutivoLa ventaja es que la especificación se desarrolla de

forma creciente.Problemas

Hay que documentar cada versión del sistemaLos sistemas tienen una estructura deficienteSe requieren herramientas y técnicas especialesSe requieren herramientas y técnicas especiales (p.e. conocimientos en lenguajes para el prototipado rápido)

AplicabilidadPara sistemas interactivos pequeños o de tamaño medianoPara partes de sistemas grandes (e.g. el interfaz de usuario)Para sistemas con vida corta

4

Proceso mixtoDesarrollar un prototipo desechable (con enfoque evolutivo) para resolver incertidumbres en la especificación inicial. Reimplementar con un enfoque más estructurado, con un proceso basado en el , pmodelo en cascada.

Desarrollo formal de sistemas

Se basa en la transformación de una especificación “matemática” a un programa ejecutableLas transformaciones preservan la corrección y el programa final es conforme con su y p gespecificación


Definición de Especificación Transformación Integración y Definición de Requisitos

Especificación formal

Transformación formal prueba del

sistema

Desmostración de la corrección


ProblemasSe necesitan habilidades y el entrenamiento especializados para aplicar la técnicaEs difícil especificar formalmente algunos aspectos del sistema tales como la interfaz de usuario

AplicabilidadSistemas críticos donde la seguridad o la fiabilidad debe garantizarse antes de que el sistema se ponga en explotación

Desarrollo con/para reutilización

Basado en la reutilización sistemática, los sistemas se integran con componentes existentes o con sistemas COTS (Commercial-off-the-shelf)Etapas del proceso

Análisis de componentesModificación de requisitosModificación de requisitosDiseño del sistema con reutilizaciónDesarrollo e integración

Este enfoque se está convirtiendo en el más importante pero todavía hay una experiencia limitada con él

Desarrollo con/para reutilización

Especificación de Requisitos

Análisis de componentes

Modificación de requisitos

Diseño de sistemas con reutilización

Desarrollo e integración

Validación del sistema

5

Modelos iterativos de proceso

En sistemas grandes, es conveniente utilizar diferentes enfoques en las distintas partes.Los requisitos del sistema SIEMPRE evolucionan en el transcurso de un proyecto.Siempre habrá una iteración en el proceso que obligue a rehacer las primeras fases del mismo.La necesidad de iterar aparece independientemente del modelo de proceso genérico utilizadoModelos de proceso que incluyen la iteración:

Desarrollo incrementalDesarrollo en espiral

Desarrollo incremental

Propuesto por Mills en 1980.En vez de entregar el sistema de una vez, tanto el desarrollo com las entregas se dividen en incrementos.Con cada incremento que entrega la parte de la q g pfuncionalidad que se hubiera determinadoLos requisitos del usuario se priorizan y los requisitos de prioridad más alta se incluyen en los incrementos más tempranosCuando el desarrollo de un incremento comienza, sus requisitos son inamovibles, aunque los requisitos de incrementos posteriores pueden continuar desarrollándose


Definir requisitos iniciales

Asignar requisitos a cada incremento

Diseñar la arquitectura del sistema

Desarrollar incremento

Validar incremento

Integrar incrementos

Validar sistema

Sistema incompleto

Sistema final


incremento 4 analysis design code test

analysis design code testincremento 2

incremento 3

incremento 1Entrega del

tiempo

incremento 1

Entrega delincremento 2...

analysis design code test

analysis design code test

Ventajas del desarrollo incremental

Los clientes no tienen que esperar hasta tener el sistema completo. El primer incremento satisface los requisitos más críticos.Los primero incrementos sirven como prototipo y ayudan en la tarea de detectar los posteriores requisitos.requisitos.Existe un riesgo bajo de fallar en el proyecto total.Los servicios de sistema con la prioridad más alta tienden a ser los más probados.… pero puede ser difícil ajustar los requisitos a los incrementos.

Desarrollo en espiral

Propuesto por Boehm en 1988.El proceso se representa como una espiral más que como una secuencia de actividades con vuelta hacia atrás.Cada vuelta en la espiral representa una fase d ldel proceso.No hay fases fijas como la especificación o diseño. Cada vuelta en la espiral determina las actividades a realizar.

6


PlanificaciónAnálisis de riesgos

Comunicación conel usuario

Desarrollo y validaciónEvaluación del usuario

Ingeniería

Sectores del modelo en espiral

Definición de objetivosSe identifican los objetivos de cada fase, las alternativas y las restricciones.

Evaluación y reducción de riesgosSe determinan los riesgos de cada fase y se ponen en marcha las actividades que reduzcan estos riesgos.

Desarrollo y validaciónDesarrollo y validaciónSe elige el modelo de desarrollo más apropiado para el sistema de entre todos los modelos genéricos.

PlanificaciónSe revisa el proyecto y, si se continúa, se planifica la siguiente fase (nueva vuelta a la espiral).


Riskanalysis

Riskanalysis

Riskanalysis

Prototype 2Prototype 3

Opera-tionalprotoype

Evaluate alternativesidentif y, resolve risks

Determine ob jectivesalternatives and

cons traints

Riskanalysis Proto-

type 1

Prototype 2 protoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

desi gn

CodeUni t tes t

Integr ationtestAcceptance

testServ ice Develop, verif ynext-level product

Plan next p hase

Integrati onand test p lan

Develop mentplan

Require ments planLife-cycle plan

REVIEW

7.1.2 Métodos de desarrollo orientados a objetos

Generaciones de Métodos

Años 60 y 70:COBOL, FORTRAN, CMétodos de análisis y diseño estructurados

Años 80 y primeros 90:C++, Smalltalk, AdaC++, Smalltalk, AdaMétodos OO de primera generación: OMT, Jacobson

Finales de los 90:JavaUMLMétodos OO avanzados, Proceso Unificado

Análisis Diseño Implementación

DFDSTD

PROGRAMA

PRO

CE

SOS

Métodos estructurados y...

DERRELACIONAL TABLAS

DAT

OS

7

Análisis Diseño Implementación

ses

...Métodos orientados a objetos

Cla

s

Desventajas (¿superadas?)

Diseñar módulos reutilizables añade costes.Beneficios a medio/largo plazo.Falta de madurez.Falta de productos (bibliotecas, CASE, ...).Falta de eficiencia.Falta de formación.Forma de trabajo diferente a la tradicional.Falta de estándares.

“Si yo tuviera que vender mi gato (al menos a un informático) no diría que es amable, autosuficiente y que come ratones:más bien argumentaría que es ...orientado-a-objetos”(Roger King)

Evolución de la OO

1980 1990 Hoy 200?

Texto

P di t l

GUI

OO

Interfaz deusuario

L j d ProcedimentalC, Cobol

Relacional

OOC++, Java

OO ?

Lenguaje deprogramación

SGBD

Métodos OO (antes de UML)

• Métodos dirigidos por los datos (data-driven)- OMT (Rumbaugh et al. 1991)- FUSION (Coleman et al. 1994)

• Métodos dirigidos por responsabilidades(responsability-driven)

- RDD (Wirfs-Brock et al 1990)- RDD (Wirfs-Brock et al. 1990)- OBA (Rubin y Goldberg 1992)

• Métodos dirigidos por casos de uso(use case-driven)

- OOSE/Objectory (Jacobson et al. 1992)

• Métodos dirigidos por estados (state-driven)- Shlaer y Mellor (Shlaer y Mellor 1992)

OMT (Object Modeling Technique)

Desarrollado en General Electric a finales de los 80El método OO más difundido antes de UML/UPAunque tiene cuatro fases definidas, se centra de una forma especial en el análisisPresenta una continuidad respecto a las métodos estructurados

El libro “Object-Oriented Modeling and Design” escrito por Rumbaugh et al. en 1991 es un best-seller mundial:

Rumbaugh, James, Blaha, Michael, Premerlani, William, Eddy, Frederick, Lorensen, William. “Modelado y Diseño Orientados a Objetos. Metodología OMT”. 2ª Reimpresión. Prentice Hall. 1998.

... OMT

Diagramas de estados

Diagramas de clases

estados

DFDs

8

Método de Booch

Es uno de los más conocidos

En su versión de 1993 este método cubre las fases de análisis y diseño dentro de un desarrollo OO.

Define una gran cantidad de símbolos para representar las distintas decisiones de diseño.

Se definen dos tipos de procesos que describen los niveles enSe definen dos tipos de procesos que describen los niveles en un desarrollo orientado al objeto:

Macro procesosMicro procesos

Booch, G. "Object-Oriented Analysis and Design with Applications", 2nd edition. Benjamin Cummings, 1993.

Clase

Nombre de la clase

AtributosMétodos()

{restricciones}

Clase utilidad

Nombre de la claseutilidad

AtributosMétodos()

... Método de Booch

Clase parametrizada

Nombre de laclase

parametrizada

Argumentosformales

Argumentosactuales

Nombre de laclase

instanciada

Método de Booch

Diferencia:Modelos estático y dinámicoModelos lógico y físico

Modelo dinámicoEstructura

Modelo Estático

Modelo Lógico

Modelo Físico

Estructura de clases

Arquitectura de módulos

Estructura

de objetos

Arquitectura de procesos

OOSE (Jacobson)

Análisis Construcción Pruebas

Es un método que se basa en la idea de los casos de uso como forma de analizar los requisitos del usuario

El ciclo de vida es similar al modelo básico pero se empieza muy pronto con la interfaz de usuario:

Análisis deRobustez

Especificaciónde requisitos

Modelo derequisitos

Modelo deanálisis

Análisis deRequisitos

Proceso de análisis:

...OOSE: Casos de Uso

Aunque tiene su propia notación, lo más característico son los casos de uso

Cliente remoto Giro por Internet

t d

Jacobson, I., Christerson, M., Jonsson, P., Övergaad, G. “Object Oriented Software Engineering: A Use Case Driven Approach”. Addison-Wesley, 1994.

Identificación

Cliente local

Giro<<uses>>

<<extends>>

Métodos OO (después de UML)

Evolución de métodos clásicosMétrica versión 3

Métodos “ágiles”eXtreme Programming (XP)

Métodos “marco” adaptablesMétodos marco adaptablesOPENProceso Unificado (Unified Process)

9

Métrica Versión 3

Cubre desarrollo estructurado y orientado a objetos

Además del desarrollo, contempla procesos de Planificación y Mantenimiento

Facilita la realización de los procesos de apoyo u organizativos

Procesos principales de desarrollo en Métrica 3: Estudio de Viabilidad del Sistema Análisis del Sistema de Información Diseño del Sistema de Información Construcción del Sistema de InformaciónImplantación y aceptación

Métrica Versión 3

Métrica 3. Análisis

Objetivo: obtención de una especificación detallada del sistema que satisfaga las necesidades de los usuarios y sirva de base para el posterior diseño del sistema

Métrica 3. Diseño

Objetivo: definir la arquitectura del sistema, el entorno tecnológico y la especificación detallada de los componentes del sistema

Métrica 3. Construcción del SistemasSe genera el código de los componentes, se desarrollan los procedimientos de operación y seguridad y se elaboran los manuales de usuario final y de explotación

Métodos ágiles

Como reacción a los procesos muy burocratizados surgen los métodos ágilesPropuesta por Beck en 1999.Nuevo enfoque basado en el desarrollo y la entrega de incrementos de funcionalidad muyentrega de incrementos de funcionalidad muy limitada.Confía en la mejora constante del código, implicación del usuario en el equipo de desarrollo y la programación “sin complejos”.

10

eXtreme Programming (XP)

Características de eXtreme Programming:Ciclos muy cortos de desarrolloSistemas con funcionalidad mínimaÚnicamente las tareas de alta prioridadImportancia de las personasp p

Conjunto de “buenas prácticas”:Programación por paresPruebas continuasRefactorización (refactoring) continua

7.2 El Proceso Unificado de Desarrollo (Unified Process)

UML no es suficiente Características del Proceso Unificado

Componentes de un Método

Elementos de modeladoUn conjunto fundamental de conceptos de modelado para capturar el conocimiento semántico sobre un problema y su soluciónLos conceptos de modelado son independientes de cómo se visualizan

Notaciónd lUn conjunto de vistas y notaciones para presentar la

información de modelado subyacente que permite a las personas examinarlos y modificarlos

ProcesoTiene como cometido la formalización de las actividades relacionadas con la elaboración de sistemas software

ExperienciaUna colección de reglas y heurísticas para llevar a cabo el desarrollo

Personas, Equipos,

UML no es un método

Experiencia

Lenguajede Modelado Proceso

?

¿Qué es un Proceso?

Describe un conjunto de actividades que deben realizarse en un determinado orden

qué hacer, cómo hacerlo, cuando hacerlo y el motivo por el cual debe ser hecho

Debe ser:ReproducibleDefinidoMedible en cuanto a rendimientoOptimizable...

Nuevos

Requisitos

Sistema

Nuevo

Proceso software

Dos elementos complementarios

UML Proceso Unificado

• Proceso marco adaptable

• No es un estándar en sí

• Estándar OMG

11

Antecedentes del Proceso Unificado

Rational Unified Process 5.01998

Unified Process1999

SPEM(2002)

E tá d

Rational Objectory Process 4.11996-1997

Objectory Process 1.0-3.81987-1995

Ericsson (Jacobson)

Rational

UML

Estándares OMG

Software Process Engineering Metamodel

OMG SPEM, 2002

UP es un Proceso “marco”

No existe un proceso UniversalUP es flexible y extensible:

Permite varias estrategias de desarrolloSe pueden definir diferentes conjuntos de productosSe pueden definir actividades y encargados de las mismas

Características del Proceso Unificado

Está dirigido por los casos de uso: Desde la especificación hasta el mantenimiento

Se centra en la arquitectura: La arquitectura es prioritaria desde el principio hasta el finalSe facilita el refinamiento progresivo de la arquitectura

Iterativo e incremental: El trabajo se divide en iteraciones pequeñas en función de la importancia de los casos de uso y el análisis de riesgos

Conducido por Casos de uso

Requisitos Implement. Pruebas

Los casos de uso integran todas las actividades

Análisis Diseño

Los casos de uso integran todas las actividades

Capturar, clarificar y validar los casos de uso

Realizar los casos de uso

Verificar que se satisfacen los casos de uso

Centrado en la Arquitectura

La arquitectura describe los elementos fundamentales del sistema:

Subsistemas DependenciasInterfacesColaboracionesNodosClases activas...

Incluye decisiones importantes sobre:Organización del sistemaElementos estructurales, interfaces y su comportamientoComposición y comportamiento de los subsistemasEl estilo de la arquitectura que guía esta organización

12

Modelo de Arquitectura: 4 + 1 vistas

Los modelos son instrumentos para visualizar, especificar, construir y documentar la arquitectura del sistema

Cada vista es una parte de un modelo

Vista deVista de

(Philippe Kruchten)

Vista LógicaVista Lógica Vista de Realización

Vista de Realización

Vista deProcesosVista deProcesos

Vista de DespliegueVista de

Despliegue

Vista deCasos de Uso

Arquitectura y Modelos

Modelos

Modelo de casos de uso

Modelo dediseño

Modelo de despliegue

Modelo de Implement.

Modelo de análisis

Modelo de Pruebas

La arquitectura incorpora una colección de vistas de los modelos

Vistas

Estructura y función

Casos de uso Arquitectura

• Los casos de uso especifican las funciones• La arquitectura especifica la la estructura• Los casos de uso y la arquitectura deben estar en

equilibrio

Proceso iterativo e incremental

...Pero la característica fundamental de UP: Es un proceso iterativo Se basa en la ampliación y el refinamiento del sistemaUna serie de desarrollos cortos (mini proyectos de 2 a 6 semanas, cada iteración reproduce el ciclo de vida a menor escala)No sólo se mejora sino que el sistema también crece: Proceso iterativo e incremental

Análisis Diseño Implementación Prueba

Tiempo

Funcionalidaddel sistema

Análisis Diseño Implementación PruebaIncremento1

Incremento2

Proceso iterativo e incremental

El resultado de cada iteración es un sistema ejecutable

(aunque sea incompleto y no esté listo para su instalación)

Un sistema instalable requiere varias iteraciones

Evolución de prototipos ejecutables

Los objetivos de una iteración se establecen en función de la

evaluación de las iteraciones precedentes

Concepto de “time-boxing”: cada iteración debe tener una

duración fija (el máximo, 6 meses)En lugar de retrasar el final de una iteración se recomienda eliminar

algunos de los requisitos (se dejan para la siguiente iteración)

La realimentación del usuario es fundamental en este proceso

El progreso es visible

Etapa de Ingeniería Etapa de Producción

Inicio Elaboración Construcción Transición

Iterativo: varias espirales

Visión Arquitectura Versiones Beta Productos

13

Cada iteración comprende:

Planificación de la iteración (estudio de riesgos)

Análisis de Casos de uso y escenarios

Diseño de opciones arquitectónicas

Codificación y pruebas La integración del nuevo código con elCodificación y pruebas. La integración del nuevo código con el existente de iteraciones anteriores se hace gradualmente durante la construcción

Evaluación de la entrega ejecutable (evaluación del prototipo en función de las pruebas y de los criterios definidos)

Preparación de la entrega (documentación e instalación del prototipo)

Primero, la arquitectura, Después, se van añadiendo los detalles según avanza el desarrollo

Etapa de Ingeniería Etapa de producción

Incremental


Req

uisi

tos

Dis

eño

Impl

emen

taci

ón

Inst

alac

ión

Gestión

Req

uisi

tos

Dis

eño

Impl

emen

taci

ón

Inst

alac

ión

Gestión

Req

uisi

tos

Dis

eño

Impl

emen

taci

ón

Inst

alac

ión

Gestión

Req

uisi

tos

Dis

eño

Impl

emen

taci

ón

Inst

alac

ión

Gestión

Visión Arquitectura Versiones Beta Productos

7.3 Fases y disciplinas (o flujos de trabajo)

Fases y puntos de controlDisciplinas (Flujos de trabajo) Artefactos

Elementos del Proceso UnificadoFases:

Es preciso diferenciar temporalmente las fases del ciclo de vidaLa división temporal necesita...

Puntos de control o hitos:Separan las etapas, las fases, las iteraciones

Disciplinas o Flujos de trabajo:Organizan las actividades fundamentales de gestión y desarrollo Se pueden solapar en el tiempo.El resultado de las actividades de los flujos de trabajo son...

Artefactos:Cualquier tipo de información producida por los desarrolladores de un sistema (diagramas UML, código, ejecutables, casos de prueba...)Se construyen de forma incremental

Planificación temporal del proyecto

UP propone una serie de ciclos de desarrollo:Hay que separar claramente la etapa de Ingeniería de la etapa de ProducciónCada una de las dos grandes etapas se dividen en fasesL f di id i iLas fases se dividen en iteraciones

iteración fase

Ciclo de desarrollo

Etapa de Ingeniería Etapa de Producción

Etapas y fases del ciclo de vida

Etapa de Ingeniería: equipos pequeños, actividades poco predecibles (análisis, viabilidad, planificación). Las fases son:

InicioElaboración

Etapa de Producción: equipos grandes actividades

tiempo


Etapa de Producción: equipos grandes, actividades predecibles, menos riesgos (programación, pruebas). Las fases son:

ConstrucciónTransición

14

Objetivos de las fases

Inicio del proyecto (inception)Define el ámbito y objetivos del proyecto

ElaboraciónDefine la funcionalidad y una arquitectura básica

ConstrucciónEl producto se desarrolla a través de iteraciones

TransiciónSe libera el producto y se entrega al usuario para su uso real

Hitos

Los hitos son puntos de control en los cuales los participantes en el proyecto revisan el progreso del proyecto.

Se pretende:Sincronizar las expectativas y la realidadSincronizar las expectativas y la realidadIdentificar los riesgosSe evalua la situación global del proyecto

Se necesitan:Resultados tangibles para comparar con las expectativas

Varios niveles:Hitos principales al final de cada faseHitos secundarios final de cada iteración

Hitos principales y secundarios

Visión Arquitecturabásica

Capacidad inicial

Productofinal

tiempo


básica inicial final

Una iteración es una secuencia de actividades con un plan establecido y unos criterios de evaluación, cuyo resultado es una versión ejecutable (hito secundario)

Release Release Release Release Release Release ReleaseRelease

Disciplinas o flujos de trabajo

Organizan las actividades fundamentales de gestión y desarrollo del proyecto

Disciplinas de desarrollo: requisitos, análisis, diseño, implementación, pruebas, etc.

Disciplinas de gestión o soporte: gestión de proyecto, gestión de configuraciones, entorno, evaluación, etc.

Al contrario de lo que ocurre con las fases, las distintas actividades del equipo de desarrollo se pueden solapar en el tiempo.

Fases, iteraciones y disciplinasFases

Requisitos

Análisis

Disciplinas: Inicio Elaboración Construcción Transición

iter.#1

iter.#2

iter.#n

iter.#n+1

iter.#n+2

iter.#m

iter.#m+1

Diseño

Implementación

Pruebas

Iteraciones

Iteraciones

preliminares

Fases y disciplinas: SPEM

La propuesta de proceso estándar admite distintas combinaciones de disciplinas y fases

Disciplinas:

Modelado del negocio

Requisitos

Di ñ


Iteraciones

Diseño

Implementación

Prueba

Despliegue

Gestión de la Configuración

Gestión del Proyecto

Entorno

15

El detalle de cada disciplina

Pero hay que definir cada disciplina en detalle

Disciplinas:

Modelado del negocio

Requisitos

Di ñ


Iteraciones

Diseño

Implementación

Prueba

Despliegue

Gestión de la Configuración


Entorno

Artefactos

Definición de artefacto (o producto): Cualquier tipo de información producida por los desarrolladores de un sistema.

Se construyen de forma incremental

Tipos de artefactosDiagramas UMLCódigo fuente Ejecutables Casos de prueba...

Los modelos son los artefactos básicos que producen las disciplinas

Disciplinas de desarrollo y modelos


Modelo de análisis

Los diagramas UML representan vistas de cada modelo

Requisitos

Análisis

Modelo dediseño



Modelo de Pruebas

Cada disciplina se asocia con modelos

Diseño

Implementación

Pruebas



Modelo de

Modelo de análisis

Diagramas de casos de uso

Diagramasde componentes

Diagramas

Diagramasde objetos

Diagramasde clases

diseño



Modelo de Pruebas

Diagramasde colaboración

de despliegue

Diagramasde estados

Diagramasde secuencia

Diagramasde actividades

Modelos de análisis y diseñoDiagramas

de casos de uso

Diagramasde componentes

Diagramas

Diagramasde objetos

Diagramasde clases


Modelo de

Modelo de análisis

Diagramasde colaboración

de despliegue

Diagramasde estados

Diagramasde secuencia

Diagramasde actividades

diseño



Modelo de Pruebas

7.4 La fase de Inicio (Inception)

16

La fase de Inicio (Inception)

Al comenzar un proyecto hay que contestar algunas preguntas:

¿Cuál es la visión del sistema?¿Es viable?¿Es viable?¿Se puede comprar o hay que fabricar el sistema?¿Cuánto va a costar?Y, finalmente ¿seguimos adelante o paramos?

Objetivos de la fase de Inicio

El objetivo es desarrollar el análisis de negocio hasta el punto necesario para la puesta en marcha del proyecto

llPara ello, es necesario:Delimitar el alcance y objetivos del proyectoDefinir la funcionalidad y capacidades del productoTener una idea de la arquitectura (arquitectura candidata)Reducir los riesgos cuanto antes Hacer estimaciones iniciales de costes, agenda

Criterios de evaluación de la fase

Al comienzo de la fase de Inicio, se establecen:

Una planificación provisional

Los criterios de evaluación de la fase. Al final,

tendremos que haber sido capaces de:Fijar el ámbito del sistema

Resolver ambigüedades en los requisitos

Determinar una arquitectura candidata

Mitigar los riesgos críticos

Analizar las posibilidades de “negocio” (evaluar el “caso de negocio”)

Disciplinas en la fase de InicioRequisitos

Enumerar los requisitos iniciales (objetivos y requisitos funcionales)Comprender el contexto del sistemaRepresentar los requisitos funcionales como casos de usoRecoger los requisitos no funcionales

AnálisisAnálisis de la arquitecturaAnálisis de los casos de uso (de algunos representativos)

DiseñoEsbozo de la arquitectura

Implementación¿Prototipo desechable?

PruebasNo

Artefactos de la fase de Inicio

Artefacto Descripción

VisiónEspecificación inicial de Requisitos Modelo de casos de uso

Grandes objetivos y restriccionesObjetivos y Requisitos funcionalesRequisitos no funcionalesDescribe los requisitos funcionales

GlosarioModelo inicial de dominio

Terminología básica del dominioDefine el contextoModelo inicial de dominio Define el contexto

Modelo de análisisModelo de diseñoPrototipos (desechables)

Esbozo inicial

Validar la tecnología

Plan de desarrolloLista de riesgos

Recursos (incluye Plan de la 1ª iteración)Riesgos posibles y forma de abordarlos

Análisis de negocioCaso de desarrollo

¿Beneficios?Cómo vamos aplicar UP a este proyecto

Modelo del Dominio y Requisitos

Modelo delDominio


Conceptos, asociaciones y atributos *

*

GlosarioRequisitos

Diseño

. . .

Casos de uso

:System

diagramasdiagramas

Modelo de diseño

17

El “Caso de desarrollo”

El número de posibles diagramas, modelos, vistas, ficheros fuente, casos de pruebas, etc. es muy grande

Es preciso definir los artefactos que son necesarios en cada desarrollo concreto

Uno de los artefactos iniciales es el “Caso de desarrollo”:Qué artefacto es necesario en cada disciplinaEn qué fase se creaEn qué fases se actualiza

Esta posibilidad permite tanto desarrollos “pesados” como “ágiles”

Ejemplo de un “Caso de desarrollo”

Disciplina Artefacto Inicio Elabora-ción

Construc-ción

Tran-sición

Requisitos Modelo de casos de usoVisiónGlosarioModelo del dominio

III

RRRI

Análisis Modelo de análisis I RAnálisis Modelo de análisis I R

Diseño Modelo de diseñoArquitecturaModelo de datos

III

RRR

Implementación Modelo de implementación I R R

Pruebas Modelo de pruebas I R


Plan de desarrollo I R R R

Entorno Caso de desarrollo I R

7.5 La fase de Elaboración

Objetivos de la fase de Elaboración

Tanto la funcionalidad como el dominio del

problema se estudian en profundidad

Se define la arquitectura básica

Se planifica el proyecto considerando recursos

disponibles

Criterios de evaluación de la fase

Al comienzo de la fase de Elaboración:

Se planifica la fase y se forma el equipoSe establecen criterios de evaluación que habrá que cumplir al final:

Respecto a los requisitos:¿Se han identificado? ¿Se han detallado lo suficiente?

En cuanto a la arquitectura:¿Satisface los requisitos? ¿Es robusta?

Los riesgos:¿Se han eliminado los críticos? ¿Se ha completado la lista?

Evaluar el proyecto:¿Se puede fijar un precio y una fecha de entrega?

Disciplinas en la fase de elaboración

RequisitosEncontrar los casos de uso y actoresDeterminar la prioridad de los casos de usoDetallar los casos de usoEstructurar el modelo de casos de usoConstruir prototipos de las interfaces de usuario

AnálisisAnálisis de la arquitecturaqAnálisis de los casos de usoAnálisis de clases y paquetes

DiseñoDiseño de la arquitectura (estilo, subsistemas)Diseño de los casos de uso

ImplementaciónImplementación de la arquitectura base (para una fracción de casos de uso)Integración del sistema (con bibliotecas de servicios, frameworks)

PruebasPlanificar y diseñar las pruebasRealizar pruebas de integración y de sistema

18

Artefactos de la fase de Elaboración


Modelo de casos de usoModelo de dominio

La mayoría de los casos de usoConceptos del dominio

Modelo de análisis Diagramas de clases Diagramas de interacción

M d l d di ñ Di d t lModelo de diseñoArquitectura del sistema

Diagramas de paquetes y clases Ideas fundamentales del diseño que se utilizará en el sistema

Modelo de pruebas Qué debe ser probado y cuándo

Modelo de implementación Incluye diagramas de implementación y el código fuente disponible

Prototipos de la interfaz de usuario

Todo lo relacionado con la interfaz

Modelo de datos Traducción a esquemas de bases de datos

7.6 Las fases de Construcción y Transición

Fase de Construcción

El producto se desarrolla a través de iteraciones Cada iteración involucra análisis, diseño e implementaciónLa arquitectura básica se refina de manera incremental conforme se construye

Gran parte del trabajo es programación y pruebasSe documenta tanto el sistema construido como el manejoSe documenta tanto el sistema construido como el manejo del mismoEsta fase proporciona un producto construido junto con la documentación

Al comienzo de esta fase, se asigna personal y se fijan los criterios de evaluación:

Lista de casos de uso implementadosDocumentación inicial para los usuarios

Disciplinas en la fase de Construcción

RequisitosCompletar los casos de uso y el detalle de los mismosDesarrollar prototipos de interfaz de usuario

AnálisisAnálisis de los casos de uso añadidosAnálisis de clases

DiseñoDiseño de los casos de uso añadidosDiseño de los casos de uso añadidos

ImplementaciónImplementación de la arquitectura Implementación de clases y subsistemasRealizar pruebas de unidadIntegración del sistema

PruebasPlanificar y diseñar las pruebasRealizar pruebas de integración Realizar pruebas de sistemaEvaluar las pruebas

Control en la fase de Construcción

Además de las disciplinas técnicas, es preciso llevar a cabo labores de gestión:

Control del análisis de negocioEvaluación de la fase de ConstrucciónPlanificación de la fase de Transición

Artefactos de la fase de Construcción


Modelo de casos de usoModelo de análisisModelo de diseñoModelo de pruebasArquitectura del sistema

Conjunto de artefactos producidos hasta ahora

Arquitectura definitivaArquitectura del sistema Arquitectura definitiva

Modelo de implementaciónModelo de pruebas

Incluye el código fuente

Sistema ejecutable Versión con capacidad operativa inicial (V. Beta)

Manual de usuario Versión inicial

Análisis de negocioPlan de proyecto

Situación actual del proyectoPlan para la fase de Transición

19

Fase de Transición

Se libera el producto y se entrega al usuario para un uso real

Se incluyen tareas de instalación, configuración, entrenamiento, soporte, mantenimiento, etc.

Los manuales de usuario se completan y refinan con la información anterior

Estas tareas se realizan también en iteraciones

Al comienzo de la fase, se reasigna personal y se establecen los criterios de evaluación:

¿Han sido capaces los usuarios de llevar a cabo todos los casos de usos?¿Ha superado el producto las pruebas de aceptación?¿Tiene el manual de usuario una calidad suficiente?¿Están listos los cursos de formación para los usuarios?¿Están los usuarios satisfechos?

Disciplinas en la fase de Transición

El esquema de actividades es distinto del resto de las fases:Preparar la versión de pruebas de aceptación a partir de la versión inicialInstalar la versión en los lugares elegidos

Incluirá la migración de datosReaccionar a los resultados de las pruebas

Fallos en un componente, un diseño, un caso de usoProblemas de fondo

Adaptación del producto a entornos variadosAdaptación del producto a entornos variados

¿Cuándo acaba el proyecto?En un producto “a medida”, el punto clave son las pruebas de aceptación

En un producto de venta masiva, el proyecto no acaba nunca realmente

Bibliografía Recomendada

Larman, C. “UML y Patrones. Introducción al Análisis y Diseño Orientado a Objetos y al Proceso Unificado ”. Prentice Hall, 2004. cap. 2 (UP)

Sommerville, I. "Ingeniería del software" Pearson, 2005 (7ª ed.), cap. 4 (modelos de proceso), 5 y 26..29 (gestión)

Pressman, Roger S. "Ingeniería del software : un enfoque práctico MacGraw-Hill", 2005 (6ª ed) , cap. 21..27 (gestión)

Lecturas complementariasJacobson, I., Booch, G., Rumbaugh, J. “El Proceso Unificado de Desarrollo de Software”. Addison-Wesley, 2000.

Kruchten, Philippe. "A Software Development Process for a Team of One", The Rational edge. Feb 2004. http://www.therationaledge.com/

Ministerio de Administraciones Públicas. “MÉTRICA. Versión 3. Metodología de Planificación, Desarrollo y Mantenimiento de sistemas de información”. http://www.map.es/csi/metrica3/. 2001

7. el proceso software - infor.uva.esmlaguna/is1/apuntes/7-proceso.pdf · y disciplinado para...

Documents