2-Proceso Unificado

5/17/2018 2-Proceso Unificado - slidepdf.com

http://slidepdf.com/reader/full/2-proceso-unificado 1/69

2. El Proceso Software

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

Miguel A. Laguna

Contenidos

2.1 Modelos de Proceso 2.1.1 Modelos genéricos de desarrollo 2.1.2 Métodos de desarrollo orientados a objetos

2.2 El Proceso Unificado de Desarrollo o Unified Process 2.3 Fases y disciplinas (o flujos de trabajo)

2.3.1 Fases y puntos de control 2.3.2 Disciplinas (flujos de trabajo) 2.3.3 Artefactos

2.4 Disciplinas de gestión

2.5 La fase de Inicio (Inception ) 2.6 La fase de Elaboración 2.7 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 dedesarrollo 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 lasfases y disciplinas del Proceso Unificado

Conocer las actividades de gestión de proyectos

2.1. Modelos de Proceso

2.1.1 Modelos genéricos de desarrollo2.1.2 Métodos de desarrollo

orientados a objetos



PROCESO

TECNICAS

HERRAMIENTAS

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

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

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

UML

UP

TogetherRose

Componentes de un método

El proceso software

Un conjunto estructurado de actividades y resultadosasociados que conducen a la creación de un productode software Especificación: Definir la funcionalidad y las restricciones en

sus operaciones Diseño e implementación: Producir software que cumple la

especificación Validació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ónabstracta de un proceso. Presenta una descripción de

un proceso desde una perspectiva particular.



2.1.1Modelos genéricos de desarrollo

Modelos de proceso genéricos

No son descripciones exhaustivas de losprocesos software.

Son abstracciones útiles que explicandiferentes enfoques utilizables a la hora dedesarrollar software.

Son marcos de trabajo del proceso, nodetallan las actividades específicas.

Se denominan paradigmas de proceso



Modelos de proceso genéricos

El modelo de cascada Separa y distingue cada fases de especificación y

desarrollo Desarrollo evolutivo

Se interpolan la especificación y el desarrollo

Desarrollo formal de sistemas Un modelo matemático del sistema se transforma

formalmente a una implementación

Desarrollo basado en reutilización El sistema se monta a partir de componentes

existentes

Modelo en Cascada

Definición de

Requisitos

Definición de

Requisitos

Diseño del sistema y

del software

Diseño del sistema y

del software

Implementación y prueba

de unidades

Implementación y prueba

de unidades

Integración y

prueba del sistema

Integración y

prueba del sistema

Operación ymantenimiento

Operación ymantenimiento



Fases del modelo en cascada

Análisis y 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

Una fase no comienza hasta que no hayanterminado las anteriores.

La desventaja es la dificultad de tener en cuentalos cambios cuando el proceso ya está en marcha

Problemas del Modelo en cascada

Inflexibilidad al dividir el proyecto en estasetapas

Es difícil responder a los cambios en losrequisitos del cliente

Por lo tanto, este modelo es apropiado sólocuando los requisitos se comprenden muybien.



Desarrollo evolutivo

Desarrollar una implementación inicial e ir refinándolahasta conseguir el sistema adecuado. Las actividadesse realizan concurrentemente.

Desarrollo exploratorio El objetivo es trabajar con los clientes y

desarrollar un sistema final con algunaespecificación inicial. Se debe comenzar teniendoen cuenta los requisitos bien-entendidos. Elsistema evoluciona según la nuevas propuestasdel cliente.

Prototipos desechables El objetivo es comprender los requisitps del cliente

y desarrollar un prototipo para evaluar hasta quépunto se han entendido.

Desarrollo evolutivo

Bosquejo de la

descripción

Bosquejo de la

descripción

VersiónInicial

VersiónInicial

Versión

final

Versión

final

Versiones

intermedias

Versiones

intermedias

Versiones

intermedias

Versiones

intermedias

Actividades

concurrentes

Especificación

Especificación

Desarrollo

Desarrollo

Validación

Validación



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

forma creciente. Problemas

Hay que documentar cada versión del sistema Los sistemas tienen una estructura deficiente Se requieren herramientas y técnicas especiales

(p.e. conocimientos en lenguajes para elprototipado rápido)

Aplicabilidad Para sistemas interactivos pequeños o de tamañomediano Para partes de sistemas grandes (e.g. el interfaz

de usuario) Para sistemas con vida corta

Proceso mixto Desarrollar un prototipo desechable (con

enfoque evolutivo) para resolverincertidumbres en la especificación inicial.

Reimplementar con un enfoque másestructurado, con un proceso basado en elmodelo en cascada.



Desarrollo formal de sistemas

Se basa en la transformación de unaespecificación “matemática” a un programa

ejecutable Las transformaciones preservan la corrección

y el programa final es conforme con suespecificación


Definición de

Requisitos

Definición de

RequisitosEspecificación

formal

Especificación

formalTransformación

formal

Transformación

formal

Integración y

prueba del

sistema

Integración y

prueba del

sistema

Desmostraciónde la corrección




Problemas Se necesitan habilidades y el entrenamiento

especializados para aplicar la técnica Es difícil especificar formalmente algunos aspectos

del sistema tales como la interfaz de usuario

Aplicabilidad Sistemas críticos donde la seguridad o la fiabilidad

debe garantizarse antes de que el sistema seponga en explotación

Desarrollo con/para reutilización

Basado en la reutilización sistemática, los sistemas seintegran con componentes existentes o con sistemasCOTS (Commercial-off-the-shelf)

Etapas del proceso Análisis de componentes Modificación de requisitos Diseño del sistema con reutilización Desarrollo e integración

Este enfoque se está convirtiendo en el másimportante pero todavía hay una experiencia limitadacon él



Desarrollo con/para reutilización

Especificación

de Requisitos

Especificación

de RequisitosAnálisis de

componentes

Análisis de

componentesModificación de

requisitos

Modificación de

requisitos

Diseño de

sistemas con

reutilización

Diseño de

sistemas con

reutilización

Desarrollo e

integración

Desarrollo e

integraciónValidación del

sistema

Validación del

sistema

Modelos iterativos de proceso

En sistemas grandes, es conveniente utilizardiferentes enfoques en las distintas partes.

Los requisitos del sistema SIEMPRE evolucionan en eltranscurso de un proyecto.

Siempre habrá una iteración en el proceso queobligue a rehacer las primeras fases del mismo.

La necesidad de iterar aparece independientementedel modelo de proceso genérico utilizado

Modelos de proceso que incluyen la iteración: Desarrollo incremental Desarrollo en espiral



Desarrollo incremental

Propuesto por Mills en 1980.

En vez de entregar el sistema de una vez, tanto eldesarrollo com las entregas se dividen enincrementos.

Con cada incremento que entrega la parte de lafuncionalidad que se hubiera determinado

Los requisitos del usuario se priorizan y los requisitosde prioridad más alta se incluyen en los incrementosmás tempranos

Cuando el desarrollo de un incremento comienza, susrequisitos son inamovibles, aunque los requisitos deincrementos posteriores pueden continuardesarrollándose


Definir requisitos

iniciales

Definir requisitos

iniciales

Asignar requisitos a

cada incremento

Asignar requisitos a

cada incremento

Diseñar la

arquitecturadel sistema

Diseñar la

arquitecturadel sistema

Desarrollar

incremento

Desarrollar

incrementoValidar

incremento

Validar

incrementoIntegrar

incrementos

Integrar

incrementosValidar

sistema

Validar

sistema

Sistema incompleto

Sistema

final




analys

is desi

gn co

de t

estincremento 2

incremento 3

incremento 4

incremento 1Entrega del

tiempo

incremento 1

Entrega del

incremento 2...

anal

ysis design co

de tes

t

analy

sis de

sign c

o

de test

analy

sis de

sign c

ode test

Ventajas del desarrollo incremental

Los clientes no tienen que esperar hasta tener elsistema completo. El primer incremento satisface losrequisitos más críticos.

Los primero incrementos sirven como prototipo yayudan en la tarea de detectar los posterioresrequisitos.

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 actividadescon vuelta hacia atrás. Cada vuelta en la espiral representa una fase

del proceso. No hay fases fijas como la especificación o

diseño. Cada vuelta en la espiral determinalas actividades a realizar.


Planificación Análisis de riesgos

Desarrollo y validaciónEvaluación delusuario

Comunicación conel usuario

Ingeniería



Sectores del modelo en espiral

Definición de objetivos Se identifican los objetivos de cada fase, las alternativas y

las restricciones.

Evaluación y reducción de riesgos Se determinan los riesgos de cada fase y se ponen en

marcha las actividades que reduzcan estos riesgos.

Desarrollo y validación Se elige el modelo de desarrollo más apropiado para el

sistema de entre todos los modelos genéricos.

Planificación Se revisa el proyecto y, si se continúa, se planifica la

siguiente fase (nueva vuelta a la espiral).


Risk analysis

Risk

analysisRisk

analysis

Risk analysis Proto-

type 1

Prototype 2

Prototype 3Opera-tionalprotoype

Concept of Operation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Product

design Detaileddesign

Code

Unit test

Integr ationtest

AcceptancetestService Develop, verify

next-le vel product

Evaluate alternativesidentif y, resolve risks

Determine objectivesalternatives and

constraints

Plan next phase

Integrationand test plan

Develop mentplan

Require ments planLife-cycle plan

REVIEW



2.1.2

Métodos de desarrolloorientados a objetos

Generaciones de Métodos

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

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

Jacobson

Finales de los 90: Java UML Métodos OO avanzados, Proceso Unificado



Análisis Diseño I mplementación

DFDSTD

PROGRAMA P R O C

E S O S

DER

RELACIONAL TABLAS D A T O S

Métodos estructurados y...

Análisis Diseño I mplementación

C l a s e s

...Métodos orientados a objetos



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

ProcedimentalC, Cobol

Relacional

GUI

OOC++, Java

OO ?

I nterfaz deusuario

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)- 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 80 El método OO más difundido antes de UML/UP Aunque tiene cuatro fases definidas, se centra de una forma

especial en el análisis Presenta una continuidad respecto a las métodos estructurados

El libro “Object-Oriented Modeling and Design” escrito porRumbaugh 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 deestados

DFDs

Diagramas declases

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 ydiseño dentro de un desarrollo OO.

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

Se definen dos tipos de procesos que describen los niveles enun desarrollo orientado al objeto: Macro procesos Micro procesos

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



Método de Booch

Diferencia: Modelos estático y dinámico

Modelos lógico y físico

Modelo dinámico

Modelo Estático

Modelo Lógico

Modelo Físico

Estructura de clases

Arquitectura de módulos

Estructura

de objetos

Arquitectura

de procesos

Clase

Nombre de la clase

AtributosMétodos()

{restricciones}

Clase utilidad

Nombre de la claseutilidad

AtributosMétodos()

Clase parametrizada

Nombre de la

claseparametrizada

Argumentos

formales

Argumentos

actuales

Nombre de la

claseinstanciada

... Método de Booch



OOSE (Jacobson)

Análisis Construcción Pruebas

Análisis deRobustez

Especificaciónde requisitos

Modelo de

requisitos

Modelo de

análisis

Análisis deRequisitos

Proceso de análisis:

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

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

...OOSE: Casos de Uso

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

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

Identificación

Cliente remoto Giro por Internet

Cliente local

Giro<<uses>>

<<extends>>



Métodos OO (después de UML)

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

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

Métodos “marco” adaptables OPEN Proceso Unificado (Unified Process)

Métrica Versión 3

Cubre desarrollo estructurado y orientado a objetos

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

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ón Implantación y aceptación



Métrica Versión 3

Métrica 3. Análisis

Objetivo: obtención de unaespecificación detallada del sistemaque satisfaga las necesidades de losusuarios 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óndetallada de los componentes del sistema

Métrica 3. Construcción del SistemasSe genera el código de los componentes, sedesarrollan los procedimientos de operación yseguridad y se elaboran los manuales de usuariofinal y de explotación



Métodos ágiles

Como reacción a los procesos muyburocratizados surgen los métodos ágiles

Propuesta por Beck en 1999. Nuevo enfoque basado en el desarrollo y la

entrega de incrementos de funcionalidad muylimitada.

Confía en la mejora constante del código,implicación del usuario en el equipo dedesarrollo y la programación “sin complejos”.

eXtreme Programming (XP)

Características de eXtreme Programming: Ciclos muy cortos de desarrollo Sistemas con funcionalidad mínima Únicamente las tareas de alta prioridad Importancia de las personas

Conjunto de “buenas prácticas”: Programación por pares Pruebas continuas Refactorización (refactoring) continua



2.2

El Proceso Unificado de Desarrollo(Unified Process)

UML no es suficiente Características del Proceso Unificado

Componentes de un Método

Elementos de modelado Un conjunto fundamental de conceptos de modelado para

capturar el conocimiento semántico sobre un problema y susolución

Los conceptos de modelado son independientes de cómo sevisualizan

Notación Un conjunto de vistas y notaciones para presentar la

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

Proceso Tiene como cometido la formalización de las actividades

relacionadas con la elaboración de sistemas software Experiencia

Una colección de reglas y heurísticas para llevar a cabo eldesarrollo



Personas, Equipos,

Experiencia

UML no es un método

Lenguajede Modelado

Proceso

?

¿Qué es un Proceso?

Describe un conjunto de actividades que debenrealizarse en un determinado orden qué hacer, cómo hacerlo, cuando hacerlo y el motivo por el cual

debe ser hecho

Debe ser: Reproducible Definido Medible en cuanto a rendimiento Optimizable...

Nuevos

Requisitos

Sistema

Nuevo

Procesosoftware



Dos elementos complementarios

UML ProcesoUnificado

• Procesomarco

adaptable• No es un

estándar en sí

• EstándarOMG

Antecedentes del Proceso Unificado

Rational Unified Process 5.01998

Rational Objectory Process 4.11996-1997

Objectory Process 1.0-3.81987-1995

Ericsson (Jacobson)

Rational UML

Unified Process

1999SPEM(2002)

EstándaresOMG



Software Process Engineering Metamodel

OMG

SPEM,

2002

UP es un Proceso “marco”

No existe un proceso Universal UP es flexible y extensible:

Permite varias estrategias de desarrollo Se pueden definir diferentes conjuntos de productos Se 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

final Se 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 deriesgos

Conducido por Casos de uso

Requisitos Implement. Pruebas

Los casos de uso integran todas las actividades

Análisis Diseño

Capturar, clarificar yvalidar los casos de uso

Realizar los casos deuso

Verificar que sesatisfacen los casosde uso



Centrado en la Arquitectura

La arquitectura describe los elementosfundamentales del sistema: Subsistemas Dependencias Interfaces Colaboraciones Nodos Clases activas...

Incluye decisiones importantes sobre: Organización del sistema Elementos estructurales, interfaces y su comportamiento Composición y comportamiento de los subsistemas El estilo de la arquitectura que guía esta organización

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

(Philippe Kruchten)

Vista Lógica

Vista LógicaVista de

Realización

Vista de

Realización

Vista de

Procesos

Vista de

ProcesosVista de

Despliegue

Vista de

Despliegue

Vista de

Casos de Uso



Arquitectura y Modelos

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

Vistas

Modelos

Modelo decasos de uso

Modelo dediseño

Modelo dedespliegue

Modelo deImplement.

Modelo deanálisis

Modelo dePruebas

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 sistema Una serie de desarrollos cortos (mini proyectos de 2 a 6

semanas, cada iteración reproduce el ciclo de vida a menorescala)

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

Visión Arquitectura Versiones Beta Productos

Inicio Elaboración Construcción Transición

Iterativo: varias espirales

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 elexistente de iteraciones anteriores se hace gradualmente durantela construcción

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

Preparación de la entrega (documentación e instalación delprototipo)



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


Etapa de Ingeniería Etapa de producción

R e q u i s i t o s

D i s e ñ o

I m p

l e m e n t a c i ó n

I n s t a l a c i ó n

Gestión

R e q u i s i t o s

D i s e ñ o

I m p



Gestión

R e q u i s i t o s

D i s e ñ o

I m p



Gestión

R e q u i s i t o s

D i s e ñ o

I m p



Gestión

Incremental

Visión Arquitectura Versiones Beta Productos

2.3Fases y disciplinas

(o flujos de trabajo)

Fases y puntos de control Disciplinas (Flujos de trabajo) Artefactos



Elementos del Proceso Unificado Fases:

Es preciso diferenciar temporalmente las fases del ciclo de vida La 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ón Cada una de las dos grandes etapas se dividen enfases Las 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

tiempo


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

Inicio Elaboración

Etapa de Producción: equipos grandes, actividadespredecibles, menos riesgos (programación, pruebas). Lasfases son: Construcción

Transición

Objetivos de las fases

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

Elaboración Define la funcionalidad y una arquitectura

básica

Construcción El producto se desarrolla a través de iteraciones

Transición Se libera el producto y se entrega al usuario

para su uso real



Hitos

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

proyecto.

Se pretende: Sincronizar las expectativas y la realidad Identificar los riesgos Se evalua la situación global del proyecto

Se necesitan: Resultados tangibles para comparar con las expectativas

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

Hitos principales y secundarios

Visión Arquitecturabásica

Capacidadinicial

Productofinal

tiempo


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

Release Release Release Release Release Release ReleaseRelease



Disciplinas o flujos de trabajo

Organizan las actividades fundamentales de gestión ydesarrollo 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, lasdistintas actividades del equipo de desarrollo sepueden solapar en el tiempo.

Fases, iteraciones y disciplinas

iter.#1

iter.#2

iter.#n

iter.#n+1

iter.#n+2

iter.#m

iter.#m+1

Fases

Requisitos

Diseño

Implementación

Pruebas

Análisis

Disciplinas:

Iteraciones

Iteraciones

preliminares




Fases y disciplinas: SPEM

La propuesta de proceso estándar admite distintascombinaciones de disciplinas y fases

Iteraciones

Disciplinas:

Modelado del negocio

Requisitos

Diseño

Implementación

Prueba

Despliegue

Gestión de laConfiguración

Gestión del Proyecto

Entorno


El detalle de cada disciplina

Pero hay que definir cada disciplina en detalle

Iteraciones

Disciplinas:

Modelado del negocio

Requisitos

Diseño

Implementación

Prueba

Despliegue

Gestión de la

Configuración

Gestión del Proyecto

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 artefactos Diagramas UML Código fuente Ejecutables

Casos de prueba...

Los modelos son los artefactos básicos que producenlas disciplinas (incluyen otros artefactos)

Disciplinas de desarrollo y modelos


Modelo dediseño

Modelo dedespliegue

Modelo deImplement.

Modelo deanálisis

Modelo dePruebas

Los diagramas UMLrepresentan vistas decada modelo

Cada disciplina seasocia con modelos

Requisitos

Diseño

Implementación

Pruebas

Análisis



Modelo de casos de uso


Modelo dediseño

Modelo dedespliegue

Modelo deImplement.

Modelo deanálisis

Modelo dePruebas

Diagramasde casos de uso

Diagramasde colaboración

Diagramasde componentes

Diagramasde despliegue

Diagramasde objetos

Diagramasde estados

Diagramasde secuencia

Diagramasde clases

Diagramasde actividades

Modelos de análisis y diseñoDiagramas

de casos de uso

Diagramasde colaboración

Diagramasde componentes

Diagramasde despliegue

Diagramasde objetos

Diagramasde estados

Diagramasde secuencia

Diagramasde clases

Diagramasde actividades


Modelo dediseño

Modelo dedespliegue

Modelo deImplement.

Modelo de

análisis

Modelo dePruebas



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 encada desarrollo concreto

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

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

Ejemplo de un “Caso de desarrollo”

R R R IPlan de desarrolloGestión delProyecto

R ICaso de desarrolloEntorno

R IModelo de pruebasPruebas

R R IModelo de implementaciónImplementación

R R R

III

Modelo de diseño ArquitecturaModelo de datos

Diseño

R IModelo de análisis Análisis

R R

R I

II

I

Modelo de casos de uso Visión

GlosarioModelo del dominio

Requisitos

Tran-sición

Construc-ción

Elabora-ción

Inicio ArtefactoDisciplina



2.5.

Disciplinas de gestión deproyectos

Objetivos de la gestión de proyectos

Organizar, planificar y programar losproyectos de software

Disciplinas y técnicas: Planificación y estimación de costes Garantía de calidad Gestión de la Configuración Gestión de personal …

También existen herramientas gráficas degestión



Planificación y calendarización del proyecto• Tareas a realizar y plan de trabajo

Estimación del coste del proyecto Supervisión y revisión del proyecto

• Para comparar los progresos y costes reales conlos planeados y hacer ajustes

Selección y evaluación del personalRedacción y presentación de informes

Tareas en la gestión de proyectos

Planificación del proyecto

Es la actividad que más tiempo consume enla administración de un proyecto

Es un proceso iterativo que se completacuando el proyecto mismo termina.

El plan del proyecto debe ser revisadoregularmente a la vista de la evolución delmismo

Es imposible planificar sin estimar.



Estimación del coste del software

Se trata de predecir los recursos que serequieren para un determinado proceso de

desarrollo de software

Preguntas fundamentales en la estimación: ¿Cuánto esfuerzo se requiere para completar una

actividad? ¿Cuánto tiempo de calendario se necesita para

terminar una actividad? ¿Cuál es el coste total de una actividad?

Se intenta determinar una medida dela cantidad de software y dedocumentación asociada que produce

un programador individual Hay que tener en cuenta que existen

muchas soluciones software condistintas características: máseficiente, más mantenible, …

Hay varias propuestas de métricas

para medir diversos aspectos delsoftware

Productividad del programador



Métricas relacionadas con el tamaño. Basadas en el tamaño de alguna salida de una

actividad del proceso: número de líneas del códigofuente, número de instrucciones del código objeto,número de páginas de la documentación, etc.

Métricas relacionadas con la función. Basadas en una estimación de la funcionalidad del

software entregado: los puntos de función.

Métricas de la productividad

Puntos de función

complexity multiplierfunction points

number of user inputs

number of user outputs

number of user inquiries

number of files

number of ext.interfaces

measurement parameter

3

4

3

7

5

countweighting factor

simple avg. complex

4

5

4

10

7

6

7

6

15

10

=

=

=

=

=

count-total

X

X

X

X

X



Las métricas basadas en volumen/unidad detiempo (líneas/programador-mes) son

imperfectas porque no tienen en cuentafactores como la fiabilidad, el mantenimiento,…

La productividad se puede aumentargeneralmente a costa de la calidad

Calidad y productividad

Técnicas de estimación

No hay una forma simple de hacer unaestimación exacta del esfuerzo requerido paradesarrollar un sistema de software Las estimaciones iniciales se basan en información

poco precisa que aportan los usuarios El software puede tener que ejecutarse en

ordenadores no conocidos o utilizar tecnología nueva El personal del proyecto es desconocido

Las estimaciones de los costes del proyectotienden a “autorealizarse” La estimación determina el presupuesto y el productose ajusta para cumplir el presupuesto



Técnicas de estimación

Modelado algorítmico de costes. Se analizan los costes de otros proyectos realizados. Se

utiliza una fórmula matemática para predecir los costes del

proyecto actual Opinión de expertos.

Se consulta a varios expertos y entre ellos acuerdan unaestimación.

Estimación por analogía. Se estima por analogía con otros proyectos completados

sobre el mismo dominio de aplicación. Ley de Parkinson.

El trabajo se extiende para llenar el tiempo disponible. El coste se determina según los recursos disponibles.

Precio para ganar. Se acuerda la funcionalidad aceptable para el sistema

teniendo en cuenta el coste acordado.

Calendario del proyecto

Partir el proyecto en tareas y estimar eltiempo y los recursos necesarios paraterminar cada tarea

Organizar las tareas concurrentemente parahacer un uso óptimo de la mano de obra Minimizar las dependencias entre tareas para

evitar retrasos producidos cuando una tareaespera a otra para terminar

Depende de la intuición y la experiencia delos administradores del proyecto



Estructura de un plan de proyecto

En él se fijan los recurso disponibles, se divideel trabajo y se crea un calendario de

trabajo. Debe incluir:1. Introducción. Objetivos del proyecto y restricciones

económicas y temporales

2. Organización del proyecto. Organización del equipo, personas involucradas

y sus tareas

3. Análisis de riesgo. Posibles riesgos con su probabilidad y

estrategias de reducción de riesgos propuestas

Estructura de un plan de proyecto

4. Requisitos de recursos de hardware y de software. Precios de lo que hay que comprar y fechas de entrega

5. División del trabajo.

División del proyecto en actividades, marca hitos yproductos a entregar

6. Calendario del proyecto. Dependencias entre actividades, tiempo estimado

requerido y asignación de personal

7. Mecanismos de supervisión e informe. Cuándo y qué tipo de informe debe producirse



Problemas en la planificación

Estimar la dificultad de los problemas, y porlo tanto el coste de desarrollar una solución,

es difícil La productividad no es proporcional al

número de personas que trabajan en unatarea

Añadir personal al final del proyecto producemás retraso por la sobrecarga en la

comunicación Lo inesperado siempre ocurre

Diagramas para la gestión de proyectos

Las notaciones gráficas ilustran laplanificación del proyecto

Muestran la descomposición del proyecto en

tareas. Las tareas no deben ser demasiadopequeñas. Los diagramas de redes de actividades

muestran las dependencias de las tareas y elcamino crítico

Los diagramas de barras muestran laplanificación sobre el calendario



Duración de las tareas y dependencias

Tarea Duración (días) Dependencias

T1 8T2 15

T3 15 T1 (M1)

T4 10

T5 10 T2, T4 (M2)

T6 5 T1, T2 (M3)

T7 20 T1 (M1)

T8 25 T4 (M5)

T9 15 T3, T6 (M4)T10 15 T5, T7 (M7)

T11 7 T9 (M6)

T12 10 T11 (M8)

Red de actividades

start

T2

M3T6

Finish

T10

M7T5

T7

M2T4

M5

T8

4/7/99

8 days

14/7/99 15 days

4/8/99

15 days

25/8/99

7 days

5/9/99

10 days

19/9/99

15 days

11/8/99

25 days

10 days

20 days

5 days

25/7/99

15 days

25/7/99

18/7/99

10 days

T1

M1 T3

T9

M6

T11

M8

T12

M4



Actividades en el calendario

4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4

T1

T2

M1

T7

T3

M5

T8

M3

M2

T6

T5

M4

T9

M7

T10

M6

T11

M8

T12

Start

Finish

Asignación de personal

4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4

T8 T11T12

T1

T3

T9

T2

T6 T10

T7

T5

Fred

Jane

Anne

Mary

Jim



Gestión del riesgo

El análisis de riesgos consiste en evaluar elproyecto, la tecnología y los recursos con el

fin determinar y comprender la naturaleza yel origen de los riesgos

Posibles riesgos: Comerciales (competencia, etc.) Financieros (económicos, etc.)

Técnicos (¿base tecnológica sólida yprobada?) De desarrollo (¿equipo experimentado?)

Tabla de riesgos

Escala 1..51=impacto

bajo5=catástrofe

Escala 1..51=impacto

bajo5=catástrofe

RiesgoRiesgo ProbabilidadProbabilidad ImpactoImpacto GestiGestióónn yy

MitigaciMitigacióónn deldel

RiesgoRiesgo

Ejemplo:Softwareempotradodepende dehardware nodisponible

60% 4(crítico)

Ajustar pruebas a ladisponiblilidad delHW

Utilizar simulación



Garantía de calidad

Coste de los fallos encontrados en distintas etapas

100

10

1

Req.Diseño

Prog.

Pruebas En uso

0.751.00

1.503.00

10.00

60.00-100.00

Pruebadel sistema

Conceptos de calidad

¿Cómo se aplica al software? Control de calidad: inspecciones, revisiones,

pruebas Aseguramiento de la calidad: análisis, auditoría e

informes

Estándares de calidad: ISO 90003 guía para la aplicación de la ISO 9001:2000 para la

adquisición, suministro, desarrollo, instalación ymantenimiento de SOFTWARE y servicios de soporte.



Garantía de calidad

Revisionesformales

Planifica-ción de laspruebas

Métricas

Análisis&

Informes

Proceso y

Estandares

Productividad y

calidad baja.Riesgo alto.

- Los procesos de software son estables y repetibles.- La organización establece políticas de gerencia deproyectos y procesos.- La planificación se basa en proyectos similares.- Existen estándares definidos y exigidos.

- El proceso se enmarca en un sistema de gerencia deproyectos basado en experiencias pasadas.

Repetible

Productividad ycalidad escasa.Riesgo máximo

- Ausencia de gestión de proyectos.- El proceso de software es cambiante e irregular:- Los planes, estimaciones y calidad son impredecibles.- El rendimiento depende de la capacidad individual de

los miembros del grupo.- Se establecen programas de formación del personal dedesarrollo y mantenimiento.

Inicial

ResultadosCaracterísticasNivel

MODELO DE MADUREZ DE LA CAPACIDAD



MODELO DE MADUREZ DE LA CAPACIDAD

Productividad ycalidad total.Riesgo nulo.

- Los procesos se mejoran continuamente.- La organización busca lograr el nivel máximo decapacidad.- Se incorporan nuevas tecnologías y métodos para mejorarlos procesos.

Optimizado

Productividad ycalidad alta.Riesgo mínimo.

- Los procesos son medibles o cuantificables- La productividad y la calidad se miden y registran paracada proyecto de la organización.- Se fijan metas cuantitativas de la calidad del software.-Mediante el uso de métricas de software, se crea una basecuantitativa para la evaluación y estimación en proyectosfuturos.

Gestionado

Productividad ycalidad media.Riesgo medio.

-Los procesos son definidos: estandarizados, documentadose institucionalizados.- Los procesos de ingeniería y gerencia son estables y seintegran en uno sólo.- Existe un entendimiento común de los procesos, funcionesy responsabilidades.- La organización mantiene un grupo dedicado a ladefinición, mejoramiento y difusión del proceso deIngeniería de Software.

Definido

ResultadosCaracterísticasNivel

Gestión de la configuración del software

datos

otros

códigoPruebas

Plan

Requisitos técnicos

Cambios enRequisitos de negocio

modelos de software

Cambios enRequisitos de usuario

Cambios en




programas documentación

datosHay cambiosen muchas

piezas


Existen herramientas que ayudan al control delas versiones a medida que avanzan (SourceForge)

PROCESO

TECNICAS

HERRAMIENTAS

• identificación• control de versiones• control de cambios

• auditoría• informes• construcción



2.5La fase de Inicio (Inception )

La fase de Inicio (Inception)

Al comenzar un proyecto hay que contestaralgunas preguntas:

¿Cuál es la visión del sistema? ¿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 lapuesta en marcha del proyecto

Para ello, es necesario: Delimitar el alcance y objetivos del proyecto Definir la funcionalidad y capacidades del producto Tener 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 denegocio”)



Disciplinas en la fase de Inicio Requisitos

Enumerar los requisitos iniciales (características del sistema) Comprender el contexto del sistema Representar los requisitos como casos de uso Recoger los requisitos no funcionales

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

Diseño Esbozo de la arquitectura

Implementación ¿Prototipo desechable?

Pruebas No

Artefactos de la fase de Inicio

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

Plan de desarrolloLista de riesgos

Terminología básica del dominioDefine el contexto

GlosarioModelo inicial de dominio

Esbozo inicial

Validar la tecnología

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

Grandes objetivos y restricciones

Requisitos no funcionales

Describe los requisitos funcionales

VisiónLista de característicasEspecificación adicional


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

Análisis de negocioCaso de desarrollo

Descripción Artefacto



Modelo del Dominio y Requisitos

Glosario

Modelo delDominio

Requisitos

Diseño

. . .


Casosde uso

:System

foo( x )

diagramas

Conceptos, asociaciones

y atributos

bar( y )

diagramas

**

Modelo de diseño

2.6

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 equipo Se 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

Requisitos Encontrar los casos de uso y actores Determinar la prioridad de los casos de uso

Detallar los casos de uso Estructurar el modelo de casos de uso Construir prototipos de las interfaces de usuario

Análisis Análisis de la arquitectura Análisis de los casos de uso Análisis de clases y paquetes

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

Implementación Implementación de la arquitectura base (para una fracción de

casos de uso) Integración del sistema (con bibliotecas de servicios, frameworks )

Pruebas Planificar y diseñar las pruebas Realizar pruebas de integración y de sistema

Artefactos de la fase de Elaboración

Todo lo relacionado con la interfazPrototipos de la interfazde usuario

Qué debe ser probado y cuándoModelo de pruebas

Incluye diagramas de implementación y el códigofuente disponible

Modelo de implementación

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

Modelo de diseño Arquitectura del sistema

Diagramas de clasesDiagramas de interacción

Modelo de análisis

La mayoría de los casos de usoConceptos del dominio

Modelo de casos de usoModelo de dominio

Traducción a esquemas de bases de datosModelo de datos




2.7

Las fases deConstrucció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ón La arquitectura básica se refina de manera incremental

conforme se construye

Gran parte del trabajo es programación y pruebas Se documenta tanto el sistema construido como el manejo

del mismo Esta 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 implementados Documentación inicial para los usuarios



Disciplinas en la fase de Construcción

Requisitos Completar los casos de uso y el detalle de los mismos Desarrollar prototipos de interfaz de usuario

Análisis Análisis de los casos de uso añadidos Análisis de clases

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

Implementación Implementación de la arquitectura Implementación de clases y subsistemas Realizar pruebas de unidad Integración del sistema

Pruebas Planificar y diseñar las pruebas Realizar pruebas de integración Realizar pruebas de sistema Evaluar las pruebas

Control en la fase de Construcción

Además de las disciplinas técnicas, es preciso llevar acabo labores de gestión: Control del análisis de negocio

Evaluación de la fase de Construcción Planificación de la fase de Transición



Artefactos de la fase de Construcción

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

Versión inicialManual de usuario

Incluye el código fuenteModelo de implementaciónModelo de pruebas

Conjunto de artefactos producidos hasta ahora

Arquitectura definitiva


Modelo de análisisModelo de diseñoModelo de pruebas

Arquitectura del sistema

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

Análisis de negocioPlan de proyecto


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 lainformación anterior

Estas tareas se realizan también en iteraciones

Al comienzo de la fase, se reasigna personal y se establecen loscriterios 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

inicial

Instalar la versión en los lugares elegidos Incluirá la migración de datos Reaccionar a los resultados de las pruebas

Fallos en un componente, un diseño, un caso de uso Problemas de fondo

Adaptació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

Somm erville, I . "Ingeniería del software" Pearson, 2005 (7ª ed.) Pressman, Roger S. "Ingeniería del software : un enfoque práctico

MacGraw-Hill", 2005 (6ª ed) Jacobson, I ., Booch, G., Rumbaugh, J. “El Proceso Unificado de

Desarrollo de Software ”. Addison-Wesley, 2000. Larman, C. “UML y Patrones. Introducción al Análisis y Diseño Orientado a Objetos y al Proceso Unificado ”. Prentice Hall, 2004.

Lecturas complementarias

Kruchten, Philippe. "A Software Development Process for a Team of

One", The Rational edge. Feb 2004. http://www.therationaledge.com/

Minister io de Administ raciones 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

Documents

2-Proceso Unificado