2.

El Proceso Software

Ingeniera del Software I 3 I.T.I.Gestin

Miguel A. Laguna

Contenidos
2.1 Modelos de Proceso
2.1.1 Modelos genricos de desarrollo 2.1.2 Mtodos 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 2.5 2.6 2.7

Disciplinas de gestin La fase de Inicio (Inception) La fase de Elaboracin Las fases de Construccin y Transicin

Objetivos del tema

Conocer los distintos modelos de proceso genricos Conocer las tendencias actuales en metodologa de desarrollo y los esfuerzos de estandarizacin Aprender los principios del Proceso Unificado Aprender la diferencia ente fase y disciplina en el Proceso Unificado Relacionar las tcnicas de modelado de UML con las fases y disciplinas del Proceso Unificado Conocer las actividades de gestin de proyectos

2.1. Modelos de Proceso

2.1.1 Modelos genricos de desarrollo 2.1.2 Mtodos de desarrollo orientados a objetos

Componentes de un mtodo
Together Rose

HERRAMIENTAS TECNICAS PROCESO

UML

Proceso: Define el marco de trabajo y permite un desarrollo racional de la IS Tcnicas: Indican cmo construir tcnicamente el software. Incluyen tcnicas de modelado Herramientas: Proporcionan el soporte automtico o semiautomtico para el proceso y para las tcnicas

UP

El proceso software
Un conjunto estructurado de actividades y resultados asociados que conducen a la creacin de un producto de software
Especificacin: Definir la funcionalidad y las restricciones en sus operaciones Diseo e implementacin: Producir software que cumple la especificacin Validacin: Asegurar que hace lo que el cliente desea. Evolucin: Seguir cumpliendo los cambios en las necesidades del usuario.

Un modelo de proceso es una representacin abstracta de un proceso. Presenta una descripcin de un proceso desde una perspectiva particular.

2.1.1 Modelos genricos de desarrollo

Modelos de proceso genricos

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 especficas. Se denominan paradigmas de proceso

Modelos de proceso genricos

El modelo de cascada
Separa y distingue cada fases de especificacin y desarrollo

Desarrollo evolutivo
Se interpolan la especificacin y el desarrollo

Desarrollo formal de sistemas

Un modelo matemtico del sistema se transforma formalmente a una implementacin

Desarrollo basado en reutilizacin

El sistema se monta a partir de componentes existentes

Modelo en Cascada
Definicin de Definicin de Requisitos Requisitos Diseo del sistema yy Diseo del sistema del software del software Implementacin yyprueba Implementacin prueba de unidades de unidades Integracin yy Integracin prueba del sistema prueba del sistema Operacin yy Operacin mantenimiento mantenimiento

Fases del modelo en cascada

Anlisis y definicin de requisitos Diseo del sistema y del software Implementacin y prueba de unidades Integracin y prueba del sistema Operacin 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 etapas Es difcil responder a los cambios en los requisitos del cliente Por lo tanto, este modelo es apropiado slo cuando los requisitos se comprenden muy bien.

Desarrollo evolutivo
Desarrollar una implementacin inicial e ir refinndola 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 especificacin inicial. Se debe comenzar teniendo en cuenta los requisitos bien-entendidos. El sistema evoluciona segn la nuevas propuestas del 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
Actividades concurrentes Versin Versin Inicial Inicial

Especificacin Especificacin

Bosquejo de la Bosquejo de la descripcin descripcin

Desarrollo Desarrollo

Versiones Versiones Versiones Versiones intermedias intermedias intermedias intermedias Versin Versin final final

Validacin Validacin

Desarrollo evolutivo
La ventaja es que la especificacin se desarrolla de forma creciente.

Problemas
Hay que documentar cada versin del sistema Los sistemas tienen una estructura deficiente Se requieren herramientas y tcnicas especiales (p.e. conocimientos en lenguajes para el prototipado rpido)

Aplicabilidad
Para sistemas interactivos pequeos o de tamao mediano 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 resolver incertidumbres en la especificacin inicial. Reimplementar con un enfoque ms estructurado, con un proceso basado en el modelo en cascada.

Desarrollo formal de sistemas

Se basa en la transformacin de una especificacin matemtica a un programa ejecutable Las transformaciones preservan la correccin y el programa final es conforme con su especificacin

Desarrollo formal de sistemas

Definicin de Definicin de Requisitos Requisitos

Especificacin Especificacin formal formal

Transformacin Transformacin formal formal

Integracin yy Integracin prueba del prueba del sistema sistema

Desmostracin de la correccin

Desarrollo formal de sistemas

Problemas
Se necesitan habilidades y el entrenamiento especializados para aplicar la tcnica Es difcil especificar formalmente algunos aspectos del sistema tales como la interfaz de usuario

Aplicabilidad
Sistemas crticos donde la seguridad o la fiabilidad debe garantizarse antes de que el sistema se ponga en explotacin

Desarrollo con/para reutilizacin

Basado en la reutilizacin sistemtica, los sistemas se integran con componentes existentes o con sistemas COTS (Commercial-off-the-shelf) Etapas del proceso
Anlisis de componentes Modificacin de requisitos Diseo del sistema con reutilizacin Desarrollo e integracin

Este enfoque se est convirtiendo en el ms importante pero todava hay una experiencia limitada con l

Desarrollo con/para reutilizacin

Especificacin Especificacin de Requisitos de Requisitos

Anlisis de Anlisis de componentes componentes

Modificacin de Modificacin de requisitos requisitos

Diseo de Diseo de sistemas con sistemas con reutilizacin reutilizacin

Desarrollo ee Desarrollo integracin integracin

Validacin del Validacin del sistema sistema

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 iteracin en el proceso que obligue a rehacer las primeras fases del mismo. La necesidad de iterar aparece independientemente del modelo de proceso genrico utilizado Modelos de proceso que incluyen la iteracin:
Desarrollo incremental Desarrollo 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 funcionalidad que se hubiera determinado Los requisitos del usuario se priorizan y los requisitos de prioridad ms alta se incluyen en los incrementos ms tempranos Cuando el desarrollo de un incremento comienza, sus requisitos son inamovibles, aunque los requisitos de incrementos posteriores pueden continuar desarrollndose

Desarrollo incremental

Definir requisitos Definir requisitos iniciales iniciales

Asignar requisitos aa Asignar requisitos cada incremento cada incremento

Disear la Disear la arquitectura arquitectura del sistema del sistema

Desarrollar Desarrollar incremento incremento

Validar Validar incremento incremento

Integrar Integrar incrementos incrementos

Validar Validar sistema sistema

Sistema final

Sistema incompleto

Desarrollo incremental

incremento 4

analysis

design

code

test

incremento 3

analysis

design

code

test

incremento 2

analysis

design

code

test

Entrega del incremento 2...

incremento 1

analysis

design

code

test

Entrega del incremento 1

tiempo

Ventajas del desarrollo incremental

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

Desarrollo en espiral
Propuesto por Boehm en 1988. El proceso se representa como una espiral ms que como una secuencia de actividades con vuelta hacia atrs. Cada vuelta en la espiral representa una fase del proceso. No hay fases fijas como la especificacin o diseo. Cada vuelta en la espiral determina las actividades a realizar.

Desarrollo en espiral
Planificacin Comunicacin con el usuario Ingeniera Anlisis de riesgos

Evaluacin del usuario

Desarrollo y validacin

Sectores del modelo en espiral

Definicin de objetivos
Se identifican los objetivos de cada fase, las alternativas y las restricciones.

Evaluacin y reduccin de riesgos

Se determinan los riesgos de cada fase y se ponen en marcha las actividades que reduzcan estos riesgos.

Desarrollo y validacin
Se elige el modelo de desarrollo ms apropiado para el sistema de entre todos los modelos genricos.

Planificacin
Se revisa el proyecto y, si se contina, se planifica la siguiente fase (nueva vuelta a la espiral).

Desarrollo en espiral
Deter mine ob jectiv es alternatives and c ons traint s Evaluate alternatives iden tif y, resol ve risk s

Risk analysis Risk analysis OperaPrototype 3 tional protoype Prototype 2 Risk anal sis Protoy type 1 Simulations, models, benchmarks Concept of Operation S/W requirements Prod uct Detaile d
desi gn Code Uni t tes t Design Inte gr ati on V&V test Accep tance test Develop, v erif y Serv ice next-level p rod uct

Risk analysis

REVIE W Require me nt s plan Life-cycle plan

De velop ment plan Integrati on a nd test p la n

Requirement validation

de si gn

Plan ne xt p hase

2.1.2 Mtodos de desarrollo orientados a objetos

Generaciones de Mtodos
Aos 60 y 70:
COBOL, FORTRAN, C Mtodos de anlisis y diseo estructurados

Aos 80 y primeros 90:

C++, Smalltalk, Ada Mtodos OO de primera generacin: OMT, Jacobson

Finales de los 90:

Java UML Mtodos OO avanzados, Proceso Unificado

Mtodos estructurados y...

Anlisis
PROCESOS DFD

Diseo
STD

Implementacin
PROGRAMA

DATOS

DER

RELACIONAL

TABLAS

...Mtodos orientados a objetos

Anlisis

Diseo

Implementacin

Clases

Desventajas (superadas?)
Disear mdulos reutilizables aade costes. Beneficios a medio/largo plazo. Falta de madurez. Falta de productos (bibliotecas, CASE, ...). Falta de eficiencia. Falta de formacin. Forma de trabajo diferente a la tradicional. Falta de estndares.

Si yo tuviera que vender mi gato (al menos a un informtico) no dira que es amable, autosuficiente y que come ratones: ms bien argumentara que es ... orientado-a-objetos (Roger King)

Evolucin de la OO
1980 1990 Hoy 200?

Interfaz de usuario Lenguaje de programacin SGBD

Texto Procedimental C, Cobol Relacional

GUI OO C++, Java

OO

Mtodos OO (antes de UML)

Mtodos dirigidos por los datos (data-driven)
- OMT (Rumbaugh et al. 1991) - FUSION (Coleman et al. 1994)

Mtodos dirigidos por responsabilidades (responsability-driven)

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

Mtodos dirigidos por casos de uso (use case-driven)

- OOSE/Objectory (Jacobson et al. 1992)

Mtodos 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 mtodo OO ms difundido antes de UML/UP Aunque tiene cuatro fases definidas, se centra de una forma especial en el anlisis Presenta una continuidad respecto a las mtodos 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 Diseo Orientados a Objetos. Metodologa OMT. 2 Reimpresin. Prentice Hall. 1998.

... OMT

Diagramas de clases
Diagramas de estados

DFDs

Mtodo de Booch
Es uno de los ms conocidos En su versin de 1993 este mtodo cubre las fases de anlisis y diseo dentro de un desarrollo OO. Define una gran cantidad de smbolos para representar las distintas decisiones de diseo. Se definen dos tipos de procesos que describen los niveles en un desarrollo orientado al objeto: Macro procesos Micro procesos

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

Mtodo de Booch
Diferencia:
Modelos esttico y dinmico Modelos lgico y fsico
Modelo dinmico Modelo Esttico Estructura de objetos Modelo Lgico Estructura de clases

Arquitectura de procesos

Modelo Fsico

Arquitectura de mdulos

... Mtodo de Booch

Clase Nombre de la clase Atributos Mtodos() {restricciones} Clase parametrizada
Argumentos formales Argumentos actuales

Clase utilidad Nombre de la clase utilidad Atributos Mtodos()

Nombre de la clase parametrizada

Nombre de la clase instanciada

OOSE (Jacobson)
Es un mtodo 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 bsico pero se empieza muy pronto con la interfaz de usuario: Anlisis Construccin Pruebas

Proceso de anlisis:

Especificacin de requisitos

Anlisis de Requisitos Modelo de requisitos

Anlisis de Robustez Modelo de anlisis

...OOSE: Casos de Uso

Aunque tiene su propia notacin, lo ms caracterstico son los casos de uso

Cliente remoto

Giro por Internet <<extends>> Cliente local <<uses>> Giro

Identificacin

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

Mtodos OO (despus de UML)

Evolucin de mtodos clsicos
Mtrica versin 3

Mtodos giles
eXtreme Programming (XP)

Mtodos marco adaptables

OPEN Proceso Unificado (Unified Process)

Mtrica Versin 3
Cubre desarrollo estructurado y orientado a objetos Adems del desarrollo, contempla procesos de Planificacin y Mantenimiento Facilita la realizacin de los procesos de apoyo u organizativos Procesos principales de desarrollo en Mtrica 3: Estudio de Viabilidad del Sistema Anlisis del Sistema de Informacin Diseo del Sistema de Informacin Construccin del Sistema de Informacin Implantacin y aceptacin

Mtrica Versin 3

Mtrica 3. Anlisis
Objetivo: obtencin de una especificacin detallada del sistema que satisfaga las necesidades de los usuarios y sirva de base para el posterior diseo del sistema

Mtrica 3. Diseo
Objetivo: definir la arquitectura del sistema, el entorno tecnolgico y la especificacin detallada de los componentes del sistema

Mtrica 3. Construccin del Sistemas

Se genera el cdigo de los componentes, se desarrollan los procedimientos de operacin y seguridad y se elaboran los manuales de usuario final y de explotacin

Mtodos giles
Como reaccin a los procesos muy burocratizados surgen los mtodos giles Propuesta por Beck en 1999. Nuevo enfoque basado en el desarrollo y la entrega de incrementos de funcionalidad muy limitada. Confa en la mejora constante del cdigo, implicacin del usuario en el equipo de desarrollo y la programacin sin complejos.

eXtreme Programming (XP)

Caractersticas de eXtreme Programming:
Ciclos muy cortos de desarrollo Sistemas con funcionalidad mnima nicamente las tareas de alta prioridad Importancia de las personas

Conjunto de buenas prcticas:

Programacin por pares Pruebas continuas Refactorizacin (refactoring) continua

2.2 El Proceso Unificado de Desarrollo

(Unified Process)

UML no es suficiente Caractersticas del Proceso Unificado

Componentes de un Mtodo
Elementos de modelado
Un conjunto fundamental de conceptos de modelado para capturar el conocimiento semntico sobre un problema y su solucin Los conceptos de modelado son independientes de cmo se visualizan

Notacin
Un conjunto de vistas y notaciones para presentar la informacin de modelado subyacente que permite a las personas examinarlos y modificarlos

Proceso
Tiene como cometido la formalizacin de las actividades relacionadas con la elaboracin de sistemas software

Experiencia
Una coleccin de reglas y heursticas para llevar a cabo el desarrollo

UML no es un mtodo

Personas, Equipos, Experiencia

Lenguaje de Modelado

Proceso

Qu es un Proceso?
Describe un conjunto de actividades que deben realizarse en un determinado orden
qu hacer, cmo hacerlo, cuando hacerlo y el motivo por el cual debe ser hecho

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

Nuevos Requisitos

Proceso software

Sistema Nuevo

Dos elementos complementarios UML Proceso Unificado

Proceso marco adaptable No es un estndar en s

Estndar OMG

Antecedentes del Proceso Unificado

Unified Process 1999

SPEM (2002)

Rational Unified Process 5.0

1998

Estndares OMG
Rational Objectory Process 4.1
1996-1997

UML
Rational Objectory Process 1.0-3.8
1987-1995

Ericsson (Jacobson)

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

Caractersticas del Proceso Unificado

Est dirigido por los casos de uso:
Desde la especificacin 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 pequeas en funcin de la importancia de los casos de uso y el anlisis de riesgos

Conducido por Casos de uso

Requisitos

Anlisis

Diseo

Implement.

Pruebas

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 Dependencias Interfaces Colaboraciones Nodos Clases activas...

Incluye decisiones importantes sobre:

Organizacin del sistema Elementos estructurales, interfaces y su comportamiento Composicin y comportamiento de los subsistemas El estilo de la arquitectura que gua esta organizacin

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 Lgica Vista Lgica Vista de Casos de Uso Vista de Vista de Procesos Procesos

Vista de Vista de Realizacin Realizacin

Vista de Vista de Despliegue Despliegue

(Philippe Kruchten)

Arquitectura y Modelos

Modelo de casos de uso

Modelo de anlisis

Modelo de diseo

Modelo de Modelo de despliegue Implement.

Modelo de Pruebas

Modelos

Vistas

La arquitectura incorpora una coleccin de vistas de los modelos

Estructura y funcin

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 caracterstica fundamental de UP:
Es un proceso iterativo

Se basa en la ampliacin y el refinamiento del sistema Una serie de desarrollos cortos (mini proyectos de 2 a 6 semanas, cada iteracin reproduce el ciclo de vida a menor escala) No slo se mejora sino que el sistema tambin crece: Proceso iterativo e incremental
Funcionalidad del sistema
Anlisis

Incremento2
Diseo Implementacin Prueba

Incremento1

Anlisis

Diseo

Implementacin

Prueba

Tiempo

Proceso iterativo e incremental

El resultado de cada iteracin es un sistema ejecutable (aunque sea incompleto y no est listo para su instalacin) Un sistema instalable requiere varias iteraciones Evolucin de prototipos ejecutables Los objetivos de una iteracin se establecen en funcin de la evaluacin de las iteraciones precedentes Concepto de time-boxing: cada iteracin debe tener una duracin fija (el mximo, 6 meses)
En lugar de retrasar el final de una iteracin se recomienda eliminar algunos de los requisitos (se dejan para la siguiente iteracin)

La realimentacin del usuario es fundamental en este proceso El progreso es visible

Iterativo: varias espirales

Etapa de Ingeniera Inicio Elaboracin

Etapa de Produccin Construccin Transicin

Visin

Arquitectura

Versiones Beta

Productos

Cada iteracin comprende:

Planificacin de la iteracin (estudio de riesgos) Anlisis de Casos de uso y escenarios Diseo de opciones arquitectnicas Codificacin y pruebas. La integracin del nuevo cdigo con el existente de iteraciones anteriores se hace gradualmente durante la construccin Evaluacin de la entrega ejecutable (evaluacin del prototipo en funcin de las pruebas y de los criterios definidos) Preparacin de la entrega (documentacin e instalacin del prototipo)

Incremental
Primero, la arquitectura, Despus, se van aadiendo los detalles segn avanza el desarrollo

Etapa de Ingeniera Inicio

Implementacin Diseo Instalacin

Etapa de produccin Construccin

Implementacin Diseo

Elaboracin
Implementacin Diseo

Transicin
Implementacin Diseo

Instalacin

Instalacin

Requisitos

Requisitos

Requisitos

Gestin

Gestin

Gestin

Requisitos

Gestin

Visin

Arquitectura

Versiones Beta

Productos

2.3 Fases y disciplinas (o flujos de trabajo)

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

Instalacin

Elementos del Proceso Unificado

Fases:
Es preciso diferenciar temporalmente las fases del ciclo de vida La divisin temporal necesita...

Puntos de control o hitos:

Separan las etapas, las fases, las iteraciones

Disciplinas o Flujos de trabajo:

Organizan las actividades fundamentales de gestin y desarrollo Se pueden solapar en el tiempo. El resultado de las actividades de los flujos de trabajo son...

Artefactos:
Cualquier tipo de informacin producida por los desarrolladores de un sistema (diagramas UML, cdigo, ejecutables, casos de prueba...) Se construyen de forma incremental

Planificacin temporal del proyecto

UP propone una serie de ciclos de desarrollo:
Hay que separar claramente la etapa de Ingeniera de la etapa de Produccin Cada una de las dos grandes etapas se dividen en fases Las fases se dividen en iteraciones
Ciclo de desarrollo iteracin fase

Etapa de Ingeniera

Etapa de Produccin

Etapas y fases del ciclo de vida

Etapa de Ingeniera: equipos pequeos, actividades poco predecibles (anlisis, viabilidad, planificacin). Las fases son: Inicio Elaboracin Etapa de Produccin: equipos grandes, actividades predecibles, menos riesgos (programacin, pruebas). Las fases son: Construccin Transicin
Inicio
tiempo

Elaboracin

Construccin

Transicin

Objetivos de las fases

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

Elaboracin
Define la funcionalidad y una arquitectura bsica

Construccin
El producto se desarrolla a travs de iteraciones

Transicin
Se 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 realidad Identificar los riesgos Se evalua la situacin 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 iteracin

Hitos principales y secundarios

Inicio
tiempo

Elaboracin

Construccin

Transicin

Visin

Arquitectura bsica

Capacidad inicial

Producto final

Una iteracin es una secuencia de actividades con un plan establecido y unos criterios de evaluacin, cuyo resultado es una versin ejecutable (hito secundario)

Release Release

Release

Release

Release

Release

Release

Release

Disciplinas o flujos de trabajo

Organizan las actividades fundamentales de gestin y desarrollo del proyecto
Disciplinas de desarrollo: requisitos, anlisis, diseo, implementacin, pruebas, etc. Disciplinas de gestin o soporte: gestin de proyecto, gestin de configuraciones, entorno, evaluacin, 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 disciplinas

Fases
Disciplinas:
Requisitos

Inicio

Elaboracin

Construccin

Transicin

Anlisis

Diseo

Implementacin

Pruebas Iteraciones preliminares iter. #1 iter. #2 iter. #n iter. #n+1 ite r. #n+2 iter. #m iter. #m+1

Iteraciones

Fases y disciplinas: SPEM

La propuesta de proceso estndar admite distintas combinaciones de disciplinas y fases
Disciplinas:
Modelado del negocio Requisitos Diseo Implementacin Prueba Despliegue Gestin de la Configuracin Gestin del Proyecto Entorno
Iteraciones

Inicio

Elaboracin

Construccin Transicin

El detalle de cada disciplina

Pero hay que definir cada disciplina en detalle
Disciplinas: Modelado del negocio Requisitos Diseo Implementacin Prueba Despliegue Gestin de la Configuracin Gestin del Proyecto Entorno
Iteraciones

Inicio

Elaboracin

Construccin Transicin

Artefactos
Definicin de artefacto (o producto):
Cualquier tipo de informacin producida por los desarrolladores de un sistema.

Se construyen de forma incremental Tipos de artefactos

Diagramas UML Cdigo fuente Ejecutables Casos de prueba...

Los modelos son los artefactos bsicos que producen las disciplinas (incluyen otros artefactos)

Disciplinas de desarrollo y modelos

Los diagramas UML representan vistas de cada modelo
Requisitos Modelo de casos de uso Modelo de anlisis Modelo de despliegue

Anlisis

Diseo

Modelo de diseo

Implementacin

Modelo de Implement.

Pruebas

Modelo de Pruebas

Cada disciplina se asocia con modelos

Modelo de casos de uso

Modelo de casos de uso

Diagramas de casos de uso Diagramas de clases Diagramas de objetos

Modelo de anlisis

Diagramas de componentes Diagramas de despliegue Diagramas de secuencia Diagramas de colaboracin Diagramas de estados Diagramas de actividades

Modelo de diseo

Modelo de despliegue

Modelo de Implement.

Modelo de Pruebas

Modelos de anlisis y diseo

Modelo de casos de uso

Diagramas de casos de uso Diagramas de clases Diagramas de objetos

Modelo de anlisis

Diagramas de componentes Diagramas de despliegue Diagramas de secuencia Diagramas de colaboracin Diagramas de estados Diagramas de actividades

Modelo de diseo

Modelo de despliegue

Modelo de Implement.

Modelo de Pruebas

El Caso de desarrollo
El nmero 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 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

Disciplina
Requisitos

Artefacto
Modelo de casos de uso Visin Glosario Modelo del dominio Modelo de anlisis Modelo de diseo Arquitectura Modelo de datos Modelo de implementacin Modelo de pruebas Plan de desarrollo Caso de desarrollo

Inicio I I I

Elaboracin R R R I I I I I I I

Construccin

Transicin

Anlisis Diseo

R R R R R R R R R

Implementacin Pruebas Gestin del Proyecto Entorno

I I

R R

2.5. Disciplinas de gestin de proyectos

Objetivos de la gestin de proyectos

Organizar, planificar y programar los proyectos de software
Disciplinas y tcnicas:
Planificacin y estimacin de costes Garanta de calidad Gestin de la Configuracin Gestin de personal

Tambin existen herramientas grficas de gestin

Tareas en la gestin de proyectos

Planificacin y calendarizacin del proyecto
Tareas a realizar y plan de trabajo

Estimacin del coste del proyecto Supervisin y revisin del proyecto

Para comparar los progresos y costes reales con los planeados y hacer ajustes

Seleccin y evaluacin del personal Redaccin y presentacin de informes

Planificacin del proyecto

Es la actividad que ms tiempo consume en la administracin de un proyecto Es un proceso iterativo que se completa cuando el proyecto mismo termina. El plan del proyecto debe ser revisado regularmente a la vista de la evolucin del mismo Es imposible planificar sin estimar.

Estimacin del coste del software

Se trata de predecir los recursos que se requieren para un determinado proceso de desarrollo de software Preguntas fundamentales en la estimacin:
Cunto esfuerzo se requiere para completar una actividad? Cunto tiempo de calendario se necesita para terminar una actividad? Cul es el coste total de una actividad?

Productividad del programador

Se intenta determinar una medida de la cantidad de software y de documentacin asociada que produce un programador individual Hay que tener en cuenta que existen muchas soluciones software con distintas caractersticas: ms eficiente, ms mantenible, Hay varias propuestas de mtricas para medir diversos aspectos del software

Mtricas de la productividad
Mtricas relacionadas con el tamao.
Basadas en el tamao de alguna salida de una actividad del proceso: nmero de lneas del cdigo fuente, nmero de instrucciones del cdigo objeto, nmero de pginas de la documentacin, etc.

Mtricas relacionadas con la funcin.

Basadas en una estimacin de la funcionalidad del software entregado: los puntos de funcin.

Puntos de funcin
weighting factor simple avg. complex X 3 X 4 X 3 X 7 X 5 4 5 4 10 7 6 7 6 15 10 = = = = =

measurement parameter count number of user inputs number of user outputs number of user inquiries number of files number of ext.interfaces count-total complexity multiplier function points

Calidad y productividad
Las mtricas basadas en volumen/unidad de tiempo (lneas/programador-mes) son imperfectas porque no tienen en cuenta factores como la fiabilidad, el mantenimiento, La productividad se puede aumentar generalmente a costa de la calidad

Tcnicas de estimacin
No hay una forma simple de hacer una estimacin exacta del esfuerzo requerido para desarrollar un sistema de software
Las estimaciones iniciales se basan en informacin poco precisa que aportan los usuarios El software puede tener que ejecutarse en ordenadores no conocidos o utilizar tecnologa nueva El personal del proyecto es desconocido

Las estimaciones de los costes del proyecto tienden a autorealizarse

La estimacin determina el presupuesto y el producto se ajusta para cumplir el presupuesto

Tcnicas de estimacin
Modelado algortmico de costes.
Se analizan los costes de otros proyectos realizados. Se utiliza una frmula matemtica para predecir los costes del proyecto actual Se consulta a varios expertos y entre ellos acuerdan una estimacin. Se estima por analoga con otros proyectos completados sobre el mismo dominio de aplicacin. El trabajo se extiende para llenar el tiempo disponible. El coste se determina segn los recursos disponibles. Se acuerda la funcionalidad aceptable para el sistema teniendo en cuenta el coste acordado.

Opinin de expertos.

Estimacin por analoga. Ley de Parkinson.

Precio para ganar.

Calendario del proyecto

Partir el proyecto en tareas y estimar el tiempo y los recursos necesarios para terminar cada tarea Organizar las tareas concurrentemente para hacer un uso ptimo de la mano de obra Minimizar las dependencias entre tareas para evitar retrasos producidos cuando una tarea espera a otra para terminar Depende de la intuicin y la experiencia de los administradores del proyecto

Estructura de un plan de proyecto

En l se fijan los recurso disponibles, se divide el trabajo y se crea un calendario de trabajo. Debe incluir: 1. Introduccin.
Objetivos del proyecto y restricciones econmicas y temporales

2. Organizacin del proyecto.

Organizacin del equipo, personas involucradas y sus tareas

3. Anlisis de riesgo.
Posibles riesgos con su probabilidad y estrategias de reduccin 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. Divisin del trabajo.

Divisin del proyecto en actividades, marca hitos y productos a entregar

6. Calendario del proyecto.

Dependencias entre actividades, tiempo estimado requerido y asignacin de personal

7. Mecanismos de supervisin e informe.

Cundo y qu tipo de informe debe producirse

Problemas en la planificacin
Estimar la dificultad de los problemas, y por lo tanto el coste de desarrollar una solucin, es difcil La productividad no es proporcional al nmero de personas que trabajan en una tarea Aadir personal al final del proyecto produce ms retraso por la sobrecarga en la comunicacin Lo inesperado siempre ocurre

Diagramas para la gestin de proyectos

Las notaciones grficas ilustran la planificacin del proyecto Muestran la descomposicin del proyecto en tareas. Las tareas no deben ser demasiado pequeas. Los diagramas de redes de actividades muestran las dependencias de las tareas y el camino crtico Los diagramas de barras muestran la planificacin sobre el calendario

Duracin de las tareas y dependencias

Tarea T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 Duracin (das) 8 15 15 10 10 5 20 25 15 15 7 10 Dependencias

T1 (M1) T2, T4 (M2) T1, T2 (M3) T1 (M1) T4 (M5) T3, T6 (M4) T5, T7 (M7) T9 (M6) T11 (M8)

Red de actividades
14/7/99 8 days T1 4/7/99 start 15 days T2 10 days T4 18/7/99 M5 25 days T8 19/9/99 Finish 25/7/99 M2 T7 10 days T5 11/8/99 M7 15 days T10 M1 25/7/99 M3 15 days T3 5 days T6 20 days 4/8/99 M4 15 days T9 25/8/99 M6 7 days T11 5/9/99 M8 10 days T12

Actividades en el calendario
4/7 T4 T1 T2 M1 T7 T3 M5 T8 M3 M2 T6 T5 M4 T9 M7 T10 M6 T11 M8 T12 Finish 11/7 Start 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

Asignacin de personal
4/7 Fred T4 T8 Jane T1 T3 T9 Anne T2 T6 Jim Mary T7 T5 T10 T11 T12 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

Gestin del riesgo

El anlisis de riesgos consiste en evaluar el proyecto, la tecnologa y los recursos con el fin determinar y comprender la naturaleza y el origen de los riesgos Posibles riesgos: Comerciales (competencia, etc.) Financieros (econmicos, etc.) Tcnicos (base tecnolgica slida y probada?) De desarrollo (equipo experimentado?)

Tabla de riesgos
Riesgo Probabilidad Impacto Gestin y Gesti Mitigacin del Mitigaci Riesgo

Ejemplo: Software empotrado depende de hardware no disponible 60%

Escala 1..5 Escala 1..5 1=impacto 1=impacto bajo bajo 5=catstrofe 5=catstrofe

4(crtico)

Ajustar pruebas a la disponiblilidad del HW Utilizar simulacin

Garanta de calidad
Coste de los fallos encontrados en distintas etapas 100 60.00-100.00

10 1.00 1.50

10.00 3.00

0.75
Req.

Diseo

Pruebas En uso Prueba Prog. del sistema

Conceptos de calidad
Cmo se aplica al software? Control de calidad: inspecciones, revisiones, pruebas Aseguramiento de la calidad: anlisis, auditora e informes Estndares de calidad: ISO 90003
gua para la aplicacin de la ISO 9001:2000 para la adquisicin, suministro, desarrollo, instalacin y mantenimiento de SOFTWARE y servicios de soporte.

Garanta de calidad

Proceso y Estandares Revisiones formales

Anlisis & Informes Mtricas

Planificacin de las pruebas

MODELO DE MADUREZ DE LA CAPACIDAD

Nivel Caractersticas
- Ausencia de gestin 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 formacin del personal de desarrollo y mantenimiento.

Resultados

Inicial

Productividad y calidad escasa. Riesgo mximo

Repetible

- Los procesos de software son estables y repetibles. - La organizacin establece polticas de gerencia de proyectos y procesos. - La planificacin se basa en proyectos similares. - Existen estndares definidos y exigidos. - El proceso se enmarca en un sistema de gerencia de proyectos basado en experiencias pasadas.

Productividad y calidad baja. Riesgo alto.

MODELO DE MADUREZ DE LA CAPACIDAD

Nivel Caractersticas
-Los procesos son definidos: estandarizados, documentados e institucionalizados. - Los procesos de ingeniera y gerencia son estables y se integran en uno slo. - Existe un entendimiento comn de los procesos, funciones y responsabilidades. - La organizacin mantiene un grupo dedicado a la definicin, mejoramiento y difusin del proceso de Ingeniera de Software. - Los procesos son medibles o cuantificables - La productividad y la calidad se miden y registran para cada proyecto de la organizacin. - Se fijan metas cuantitativas de la calidad del software. -Mediante el uso de mtricas de software, se crea una base cuantitativa para la evaluacin y estimacin en proyectos futuros. - Los procesos se mejoran continuamente. - La organizacin busca lograr el nivel mximo de capacidad. - Se incorporan nuevas tecnologas y mtodos para mejorar los procesos.

Resultados

Definido

Productividad y calidad media. Riesgo medio.

Gestionado

Productividad y calidad alta. Riesgo mnimo.

Optimizado

Productividad y calidad total. Riesgo nulo.

Gestin de la configuracin del software

Cambios en Requisitos de negocio Cambios en Requisitos tcnicos Cambios en Requisitos de usuario

otros

modelos de software
Plan Pruebas datos

cdigo

Gestin de la configuracin del software

programas

documentacin

Hay cambios en muchas piezas

datos

Gestin de la configuracin del software

identificacin control de versiones control de cambios auditora informes construccin

HERRAMIENTAS TECNICAS PROCESO

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

2.5 La fase de Inicio (Inception)

La fase de Inicio (Inception)

Al comenzar un proyecto hay que contestar algunas preguntas:
Cul es la visin del sistema? Es viable? Se puede comprar o hay que fabricar el sistema? Cunto va a costar? Y, finalmente seguimos adelante o paramos?

Objetivos de la fase de Inicio

El objetivo es desarrollar el anlisis de negocio hasta el punto necesario para la puesta 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 evaluacin de la fase

Al comienzo de la fase de Inicio, se establecen: Una planificacin provisional Los criterios de evaluacin de la fase. Al final, tendremos que haber sido capaces de:
Fijar el mbito del sistema Resolver ambigedades en los requisitos Determinar una arquitectura candidata Mitigar los riesgos crticos Analizar las posibilidades de negocio (evaluar el caso de negocio)

Disciplinas en la fase de Inicio

Requisitos
Enumerar los requisitos iniciales (caractersticas del sistema) Comprender el contexto del sistema Representar los requisitos como casos de uso Recoger los requisitos no funcionales

Anlisis
Anlisis de la arquitectura Anlisis de los casos de uso (de algunos representativos)

Diseo
Esbozo de la arquitectura

Implementacin
Prototipo desechable?

Pruebas
No

Artefactos de la fase de Inicio

Artefacto Visin Lista de caractersticas Especificacin adicional Modelo de casos de uso Glosario Modelo inicial de dominio Modelo de anlisis Modelo de diseo Prototipos (desechables) Plan de desarrollo Lista de riesgos Anlisis de negocio Caso de desarrollo Descripcin Grandes objetivos y restricciones Requisitos no funcionales Describe los requisitos funcionales Terminologa bsica del dominio Define el contexto Esbozo inicial Validar la tecnologa Recursos (incluye Plan de la 1 iteracin) Riesgos posibles y forma de abordarlos Beneficios? Cmo vamos aplicar UP a este proyecto

Modelo del Dominio y Requisitos

Modelo del Dominio

Conceptos, asociaciones y atributos

Modelo de casos de uso

:System

Requisitos
Casos de uso diagramas

foo( x ) bar( y )

Glosario

...

diagramas

Modelo de diseo

Diseo

2.6 La fase de Elaboracin

Objetivos de la fase de Elaboracin

Tanto la funcionalidad como el dominio del problema se estudian en profundidad Se define la arquitectura bsica Se planifica el proyecto considerando recursos disponibles

Criterios de evaluacin de la fase

Al comienzo de la fase de Elaboracin: Se planifica la fase y se forma el equipo Se establecen criterios de evaluacin 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 crticos? Se ha completado la lista? Evaluar el proyecto: Se puede fijar un precio y una fecha de entrega?

Disciplinas en la fase de elaboracin

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 Anlisis de la arquitectura Anlisis de los casos de uso Anlisis de clases y paquetes Diseo de la arquitectura (estilo, subsistemas) Diseo de los casos de uso Implementacin de la arquitectura base (para una fraccin de casos de uso) Integracin del sistema (con bibliotecas de servicios, frameworks) Planificar y disear las pruebas Realizar pruebas de integracin y de sistema

Anlisis

Diseo

Implementacin

Pruebas

Artefactos de la fase de Elaboracin

Artefacto Modelo de casos de uso Modelo de dominio Modelo de anlisis Modelo de diseo Arquitectura del sistema Modelo de pruebas Descripcin La mayora de los casos de uso Conceptos del dominio Diagramas de clases Diagramas de interaccin Diagramas de paquetes y clases Ideas fundamentales del diseo que se utilizar en el sistema Qu debe ser probado y cundo

Modelo de implementacin Incluye diagramas de implementacin y el cdigo fuente disponible Prototipos de la interfaz de usuario Modelo de datos Todo lo relacionado con la interfaz Traduccin a esquemas de bases de datos

2.7 Las fases de Construccin y Transicin

Fase de Construccin
El producto se desarrolla a travs de iteraciones
Cada iteracin involucra anlisis, diseo e implementacin La arquitectura bsica se refina de manera incremental conforme se construye

Gran parte del trabajo es programacin y pruebas Se documenta tanto el sistema construido como el manejo del mismo Esta fase proporciona un producto construido junto con la documentacin Al comienzo de esta fase, se asigna personal y se fijan los criterios de evaluacin:
Lista de casos de uso implementados Documentacin inicial para los usuarios

Disciplinas en la fase de Construccin

Requisitos Anlisis Diseo
Completar los casos de uso y el detalle de los mismos Desarrollar prototipos de interfaz de usuario Anlisis de los casos de uso aadidos Anlisis de clases Diseo de los casos de uso aadidos Implementacin de la arquitectura Implementacin de clases y subsistemas Realizar pruebas de unidad Integracin del sistema Planificar y disear las pruebas Realizar pruebas de integracin Realizar pruebas de sistema Evaluar las pruebas

Implementacin

Pruebas

Control en la fase de Construccin

Adems de las disciplinas tcnicas, es preciso llevar a cabo labores de gestin:
Control del anlisis de negocio Evaluacin de la fase de Construccin Planificacin de la fase de Transicin

Artefactos de la fase de Construccin

Artefacto Modelo de casos de uso Modelo de anlisis Modelo de diseo Modelo de pruebas Arquitectura del sistema Descripcin Conjunto de artefactos producidos hasta ahora

Arquitectura definitiva

Modelo de implementacin Incluye el cdigo fuente Modelo de pruebas Sistema ejecutable Manual de usuario Anlisis de negocio Plan de proyecto Versin con capacidad operativa inicial (V. Beta) Versin inicial Situacin actual del proyecto Plan para la fase de Transicin

Fase de Transicin
Se libera el producto y se entrega al usuario para un uso real Se incluyen tareas de instalacin, configuracin, entrenamiento, soporte, mantenimiento, etc. Los manuales de usuario se completan y refinan con la informacin anterior Estas tareas se realizan tambin en iteraciones Al comienzo de la fase, se reasigna personal y se establecen los criterios de evaluacin:
Han sido capaces los usuarios de llevar a cabo todos los casos de usos? Ha superado el producto las pruebas de aceptacin? Tiene el manual de usuario una calidad suficiente? Estn listos los cursos de formacin para los usuarios? Estn los usuarios satisfechos?

Disciplinas en la fase de Transicin

El esquema de actividades es distinto del resto de las fases:
Preparar la versin de pruebas de aceptacin a partir de la versin inicial Instalar la versin en los lugares elegidos Reaccionar a los resultados de las pruebas
Incluir la migracin de datos Fallos en un componente, un diseo, un caso de uso Problemas de fondo

Adaptacin del producto a entornos variados

Cundo acaba el proyecto?

En un producto a medida, el punto clave son las pruebas de aceptacin En un producto de venta masiva, el proyecto no acaba nunca realmente

Bibliografa Recomendada
Sommerville, I. "Ingeniera del software" Pearson, 2005 (7 ed.) Pressman, Roger S. "Ingeniera del software : un enfoque prctico 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. Introduccin al Anlisis y Diseo 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/

Ministerio de Administraciones Pblicas. MTRICA. Versin 3.

Metodologa de Planificacin, Desarrollo y Mantenimiento de sistemas de informacin. http://www.map.es/csi/metrica3/. 2001