UNIVERSIDAD NACIONAL JOSE FAUSTINO SANCHEZ CARRION

FACULTAD DE INGENIERIA

PORQUE ES DIFCIL DESARROLLAR SOFTWARE?

Es complicado explicar los motivos que hacen tan difcil desarrollar Software. Lo cierto es que muchos proyectos de desarrollo de software fracasan Centraremos el tema mediante: Una estadstica realizada sobre 8 proyectos de Software Estadounidenses. Caractersticas del Software. Aplicaciones del Software.

ESTADSTICA REALIZADA SOBRE 8 PROYECTOS DE SOFTWARE ESTADOUNIDENSES.

rea: Sistemas de Defensa en Tiempo Real
Pagado pero no entregado Entregado pero no utilizado abandonado o rechazado Utilizado despus de cambios Utilizado como se entrego

0,5

1,5

2,5

3,5

Millones de dolares

Proceso de desarrollo de software: Condiciones necesarias

Proporcione una gua para ordenar las actividades de un equipo. Dirija las tareas de cada desarrollador por separado y del equipo como un todo. Especifique los artefactos que deben desarrollarse. Ofrezca criterios para el control y la medicin de los productos y actividades del proyecto.

RATIONAL UNIFIED PROCESS (RUP)

PROCESO UNIFICADO (JACOBSON, BOOCH Y RUMBAUGH 99) Soporte al estndar del OMG(Object Management GroupT) UML (Lenguaje Unificado de Modelado) Entre otros, integra los mtodos
OMT Booch OOSE/Objectory

R.U.P. El Proceso Unificado de Rational (Rational Unified Process en ingls, habitualmente resumido como RUP) es un proceso de desarrollo de software y Junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos.

PROCESO UNIFICADO DE DESARROLLO

Conjunto de actividades. Define Quin debe hacer Qu, Cundo y Cmo debe hacerlo.
Proceso de desarrollo de Software
Requisitos del usuario nuevos o modificados Sistema software nuevo o modificado

Marco de trabajo genrico. (adaptable). Utiliza el lenguaje de Modelamiento Unificado (UML).

R.U.P.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin. No existe un proceso de software universal. Las caractersticas de cada proyecto (equipo de desarrollo, recursos, etc.) exigen que el proceso sea configurable.

PROCESO DE SOFTWARE

DISCIPLINAS DE INGENIERA Y ADMINISTRATIVAS

Ciclos en la vida de un sistema

Nacimiento Muerte

Tiempo

Los ciclos concluyen con una versin

UN CICLO CON SUS FASES E ITERACIONES

Tiempo
Inicio
Iterac. #1 Iterac. #2

Elaboracin
__ __

Construccin
__ __ __

Transicin
Iterac. # n-1 Iterac. # n

Versiones internas

EL CICLO DE VIDA DEL SOFTWARE EN RUP

El Ciclo de Vida del Software en RUP

Modelos del Proceso Unificado en una iteracin

Modelo de casos de uso

especificado por realizado por

distribudo por

Modelo de anlisis Modelo de diseo

implementado por

Modelo de despliegue

verificado por

Modelo de implementation
X OK

X OK X OK

Modelo de prueba

Flujos de trabajo fundamentales vs. Fases

Flujos de trabajo fundamentales vs. Fases

Flujos de Trabajo Fundamentales Requisitos

Fases
Inicio Elaboracin Construccin Transicin

Anlisis
Diseo Implementacin Prueba
Iterac. Iterac. #1 #2 __ __ __

Una iteracin en la fase de elaboracin

__

__

Iterac. # n-1

Iterac. # n

Iteraciones

RUP : Fase de inicio

Descripcin del producto final, se presenta anlisis de negocio. Principales funciones del sistema. ( casos de uso ) La arquitectura ( esbozo de los subsistemas ) Plan general del proyecto.
Iterac. Iterac. #1 #2 __ __ __ __ __ Iterac. # n-1 Iter. # n

Inicio

Elaboracin

Construccin

Transicin

Plan detallado de la fase de elaboracin.

RUP : Fase de elaboracin

Especificar en detalle la mayora de casos de uso. Se disea la arquitectura. (Lnea base). Plan detallado para terminar el sistema, incluyendo costos.
Iterac. Iterac. #1 #2 __ __ __ __ __ Iterac. # n-1 Iter. # n

Inicio

Elaboracin

Construccin

Transicin

Se analiza estabilidad, anlisis de riesgos.

RUP : Fase de construccin

La lnea base de la arquitectura crece hasta convertirse en el sistema completo.
Cambios mnimos en la arquitectura.

Inicio

Elaboracin

Construccin

Transicin

Preparado para una primera entrega a los usuarios.

Iterac. Iterac. #1 #2 __ __ __ __ __ Iterac. # n-1 Iter. # n

Se consumen la mayor cantidad de recursos.

RUP : Fase de transicin

Donde el producto se convierte en versin beta.
Inicio Elaboracin Construccin Transicin

Nmero reducido de usuarios con experiencia prueba el producto. Desarrolladores corrigen problemas e incorporan algunas mejoras.
Incluye: fabricacin, formacin del cliente, ayuda y asistencia en lnea, correccin de defectos.

Iterac. Iterac. #1 #2

__

__

__

__

__

Iterac. # n-1

Iter. # n

LAS 4 P EN EL DESARROLLO DEL SOFWARE

Proceso Plantilla Automatizacin Tareas de modelado Herramientas

Personas

Proyecto
Participantes

Resultado Producto

Trminos en RUP
Trabajadores: Papel que uno o mas individuos pueden desempear en el desarollo de un proyecto software. (especificador de caso de uso, arquitecto, ) Recursos Un individuo en concreto que trabaja en el proyecto. ( Mara, Carlos, )

Artefactos
Cualquier tipo de informacin creada, producida, cambiada o utilizada por los trabajadores en el desarrollo del sistema.

Trabajadores participando en el desarrollo de software

Usuarios Arquitecto

Algunos son trabajadores individuales; otros son multitipos Ingenieros y multiobjetos

de prueba

Sistema
El Jefe de Proyecto Diseadores

Analistas

Conjunto fundamental de modelos del Proceso Unificado

Modelo de casos de uso

Modelo de anlisis

Modelo de diseo

Modelo de despliegue

Modelo de implementacin

Modelo de prueba

Tipo de artefacto mas interesante utilizado en RUP es el modelo. La construccin de un sistema es un proceso de construccin de modelos.

Unified Modeling Language

UML es un lenguaje de propsito general para el modelado orientado a objetos, que combina notaciones provenientes desde: Modelado Orientado a Objetos, Modelado de Datos, Modelado de Componentes, Modelado de Flujos de Trabajo (Workflows). En todos los mbitos de la ingeniera se construyen modelos, en realidad, simplificaciones de la realidad, para comprender mejor el sistema que vamos a desarrollar. UML no es una metodologa. Es una notacin que puede ser usada para crear modelos metodolgicos como es el caso de RUP.

Descripcin de los diagramas

Un diagrama es una representacin grfica de una coleccin de elementos de modelado, a menudo dibujada como un grafo con vrtices conectados por arcos. Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de inters. Es aqu donde se hace evidente la importancia de UML en el contexto de un proceso de desarrollo de software

TIPOS DE DIAGRAMAS UML

Dependencias entre los modelos del Proceso Unificado

Modelo de casos de uso
especificado por realizado por

distribudo por

Modelo de anlisis Modelo de diseo

implementado por

Modelo de despliegue

verificado por

Trazabilidad
Ningn artefacto es aislado

Modelo de imple-mentacin
X OK

X OK X OK

Modelo de prueba

Actividades relacionadas conforman un flujo de trabajo

Diagrama de actividad ( que describe el flujo de trabajo para la captura de requisitos)

Analista de Sistemas

Identificar Actores Y Casos de Uso

Estructurar el Modelo de Casos de Uso

Arquitecto

Priorizar Casos de Uso

Especificador De Casos de Uso

Detallar Un Caso de Uso

Diseador de Interfaz de usuario

Esbozar Interfaz de Usuario

Trabajadores y artefactos en la captura de requisitos

Analista de sistemas responsable de

Especificador de casos de uso

Diseador de interfaz de usuario

Arquitecto

responsable de

responsable de

responsable de

Modelo de casos de uso

Actor

Glosario

Caso de uso

Prototipo de interfaz de usuario

Descripcin de la arquitectura

Identifican los paquetes de anlisis principales, las clases de entidad evidentes, y los requisitos comunes

Flujo de trabajo : anlisis

Arquitecto

Anlisis Anlisis de la arquitectura arquitectura

Ingeniero de casos de uso

Analizar un caso de uso

Realizan cada caso de uso en terminos de las clases de analisis participantes exponiendo los requisitos de comportamiento de cada clase

Ingeniero de componentes

Analizar una clase

Especifican estos requisitos y los integran dentro de cada clase creando responsabilidades, atributos y relaciones consistentes para cada clase.

Analizar un paquete

Trabajadores y artefactos en el analisis

Arquitecto

Ingeniero de casos de uso

Ingeniero de componentes

responsable de

responsable de

responsable de

vista de la arquitectura

Modelo de anlisis

Descripcin de la arquitectura

Realizacin de caso de uso Anlisis

Clase del anlisis

Paquete del anlisis

Inician creacin de modelos de diseo y de despliegue. Esbozan los nodos del modelo de despliegue, los subsistemas principales y sus interfaces, las clases del diseo importantes como las activas y mecanismos genricos de diseo.

Flujo de trabajo : diseo

Diseo Arquitecto de la arquitectura

Ingeniero de casos de uso

Realizan cada caso de uso en terminos de clases y/o subsistemas del diseo participantes y sus interfaces. Las realizaciones de caso de uso resultantes establecen los requisitos de comportamiento para Disear un caso cada clase o subssistema de uso

Ingeniero de componentes

Disear una clase

Disear un subsistema

Especifican los requisitos, y los integran dentro de cada clase, bien mediante la creacin de operaciones, atributos y relaciones consistentes sobre cada clase, o bien mediante la creacin de operaciones consistentes en cada interfaz que proporcione el subsistema.

Trabajadores y artefactos en el diseo

Arquitecto

Ingeniero de casos de uso

Ingeniero de componentes

responsable de

responsable de

responsable de

Modelo Modelo Descripcin de diseo de desarrollo de la arquitectura

Realizacin de caso de uso - Diseo

Clases del diseo

Subsistema de diseo

Interfaz

Trabajadores y artefactos en la implementacin

Arquitecto

Integrador de sistema

Ingeniero de componentes

responsable de

responsable de

responsable de

Modelo de implementacin

Descripcin de la arquitectura

Modelo de despliegue

Plan de Integracin de construcciones

Componente Subsistema de implementacin

Interfaz

RUP Un proceso dirigido por casos de uso

Flujos de trabajo y modelos del Proceso Unificado

Requisitos
Modelo de casos de uso Modelo de anlisis

Anlisis

Diseo

Modelo de diseo

Modelo de despliegue

Implementacin

Modelo de implementacin

Prueba

Modelo de prueba

Desarrollo dirigido por casos de uso

Los casos de uso han sido adoptados universalmente para la captura de requisitos. casi

Requisitos

Anlisis

Diseo

Implementacin

Prueba

Los casos de uso dirigen el proceso de desarrollo en su totalidad.

Requisitos: Modelo de Casos de Uso

Los casos de uso proporcionan un medio semntico e intuitivo de capturar Ingresar Dinero Cliente del Banco (from Use Cases) requisitos fun(from Actors) cionales, centrndose en el Transferencia entre Cuentas valor aadido para (from Use Cases) el usuario. Diagrama de Casos de Uso
para un Cajero Automtico
Sacar Dinero (from Use Cases)

Requisitos : Secuencia de acciones Caso de Uso Sacar Dinero

Cliente del Banco

Sacar Dinero

1. El Cliente del Banco se identifica.

2. El Cliente del Banco elige de qu cuenta sacar dinero y especifica qu cantidad. 3. El sistema deduce la cantidad de la cuenta y entrega el dinero.

Anlisis : Realizacin del Caso de Uso Sacar Dinero

Sacar Dinero Sacar Dinero (from Use Cases)

Traza

Salida

Interfaz de Cajero

Retirada de Efectivo

Cuenta

Clases de Anlisis: Conceptuales

Anlisis : Diagrama de Clases

Salida

Retirada de Efectivo

Cliente del Banco (from Actors)

Interfaz de Cajero

Cuenta

Muestra las relaciones entre las clases que participan en la Realizacin del Caso de Uso Sacar Dinero

Anlisis : Diagrama de Colaboracin para la realizacin del caso de uso Sacar Dinero
1: identificacin
: Interfaz de Cajero 3: validar y retirar

2: solicitar retirada

: Cliente del Banco

: Retirada de Efectivo 4: autorizar entrega : Salida

: Cuenta

5: entrega de dinero

El modelo de anlisis es una especificacin detallada de los requisitos en trminos de clases conceptuales..
Es una primera aproximacin al modelo de diseo

Diseo : Realizaciones de caso de uso en diferentes modelos

Modelo de casos de uso

Modelo de anlisis
"trace"

Modelo de diseo
"trace"

Sacar Dinero

Sacar Dinero

Sacar Dinero

Diseo : Obtener las Clases de Diseo

Interfaz de Cajero (from Analysis Model)
Salida (from Analysis Model) Retirada de Efectivo (from Analysis Model) Cuenta (from Analysis Model)

Sensor de la Salida Lector de Tarjetas Teclado Alimentador de la Salida Retirada de Efectivo Cuenta

Gestor de Cliente

Clase Persistente

Dispositivo de visualizacin Contador de Efectivo Gestor de Transacciones

Gestor de Cuentas

El modelo de diseo plasma el modelo de anlisis en trminos de clases dependientes de un tecnologa en particular seleccionada para la implementacin.

Diseo: Diagrama de clases para la realizacin del caso de uso Sacar Dinero

Cada clase de diseo participa y asume roles en la realizacin del caso de uso.

Diseo: Diagrama de Secuencia caso de uso Sacar Dinero

pasos 1: identificar y 2 : solicitar retirada
: Cliente del Banco

: Lector de Tarjetas

: Dispositivo de visualizacin

: Teclado

: Gestor de Cliente

: Contador de Efectivo

: Gestor de Transacciones

Introducir tarjeta Tarjeta introducida (ID)

Solicitar cdigo PIN

Mostrar peticin Especificar cdigo PIN Cdigo PIN (PIN) Solicitar validacin de PIN (PIN) Solicitar cantidad a retirar Mostrar peticin

Especificar cantidad Cantidad (C) Solicitar disponibilidad de saldo (C) Solicitar retirada de cantidad (C)

Diseo: Los subsistemas agrupan clases

Las clases se agrupan en sub-sistemas

Un subsistema posee un conjunto de interfaces que ofrece a sus usuarios.

Los subsistemas pueden disearse descendente o ascendentemente.

Implementacin : Creacin del modelo de implementacin

( a partir del modelo de diseo )

El modelo de implementacin agrupa clases de diseo en un conjunto de ficheros, a partir de los cuales se puede compilar y enlazar, ejecutables como DLLs , JavaBeans, componentes ActiveX, etc.

Pruebas: Identificacin de un caso de prueba

( a partir de un caso de uso )

Modelo de casos de uso

Modelo de prueba "trace"

Sacar Dinero

Sacar Dinero Flujo Bsico

El modelo de pruebas, verifica que el sistema implementa de verdad la funcionalidad descrita en los casos de uso.

RUP

Un proceso centrado en la arquitectura

Arquitectura
Para desarrollar software hay hacer algo ms que conducirse a ciegas a travs de los flujos de trabajo guiado por los casos de uso. Los casos de uso solamente no son suficientes. Se necesitan ms cosas para conseguir un sistema de trabajo. Esas cosas son la arquitectura. Podemos pensar que la arquitectura de un sistema es la visin comn.

Por que es necesaria la arquitectura

Un sistema software es difcil de abarcar visualmente por que no existe en un mundo de tres dimensiones.
Es a menudo nico y sin precedentes en determinados aspectos. Suele utilizar poco probada. tecnologa

Existe con frecuencia un sistema que ya realiza algunas de las funciones del sistema propuesto.

Qu permite el contar con una arquitectura?

Comprender el sistema. Organizar el desarrollo del proyecto de software. Fomentar la reutilizacin de componentes desarrollados en otros sistemas . Hacer evolucionar al sistema, reduciendo riesgos por modificaciones.

Con qu construir la arquitectura?

Restricciones y posibilidades

Casos de uso

Software del sistema

(SO, SGBD)

Capa intermedia, incluyendo marcos de trabajo

(Productos de middleware, Ej: Object Request Broker)

Sistemas heredados

Arquitectura

(Reutilizacion de funciones existentes en otros sistemas)

Estndares y polticas corporativas. Requisitos no funcionales generales

Experiencia
Arquitecturas anteriores. Patrones de la arquitectura.

(disponibilidad, tiempo de recuperacin, uso de memoria)

Necesidades de distribucin
(cliente/servidor, )

Cmo construir la arquitectura?

La arquitectura se desarrolla en iteraciones de la fase de elaboracin.
Comenzamos determinando un diseo de alto nivel para la arquitectura, a modo de una arquitectura en capas. Despus formamos la arquitectura en un par de construcciones: Primera construccin.- Partes generales de la aplicacin. Seleccionamos el software del sistema (capa del sistema, middleware, sistemas heredados, estndares). Decidimos que nodos tendr. Como manejaremos los requisitos generales no funcionales. Segunda construccin.- Aspectos especficos (capa de apli-cacin); escogemos un conjunto de casos de uso relevantes, capturamos los requisitos, los analizamos, los diseamos, los implementamos y los probamos. As obtenemos componentes. Se continua con las arquitectura estable. iteraciones hasta conseguir una

Influencias en el desarrollo de casos de uso

entrada del cliente Casos de uso entrada del usuario

Arquitectura

Dependencias

Casos de uso gua Arquitectura conduce

Es como la paradoja del huevo y la gallina

La lnea base de la arquitectura es un sistema "pequeo y flaco"

Modelo de casos de uso

Modelo de anlisis

Modelo de diseo

Modelo de despliegue

Modelo de implementacin

Modelo de prueba

Lnea base obtenida al final de la fase de elaboracin.

Utilizacin de patrones de la arquitectura

Patron Layers
( organiza los sistemas en capas de subsistemas )

Capa especfica de la aplicacin Capa general de la aplicacin

Capa de middleware

Capa de software del sistema

Evolucin de la arquitectura
- La descripcin de la arquitectura no crece significativamente - Se incorporan pocos cambios
Lnea base de la arquitectura
Modelo de Modelo Modelo Modelo casos de anlisis de diseo de de uso despliegue Modelo Modelo de imple- de prueba mentacin

Lnea base al final de la construccin

Modelo de Modelo Modelo Modelo casos de anlisis de diseo de de uso despliegue Modelo Modelo de imple- de prueba mentacin

Descripcin de la arquitectura versin en la fase de elaboracin

Modelo de Modelo Modelo Modelo casos de anlisis de diseo de de uso despliegue Modelo Modelo de imple- de prueba mentacin

Descripcin de la arquitectura Versin en la fase de construccin

Modelo de Modelo Modelo Modelo casos de anlisis de diseo de de uso despliegue Modelo Modelo de imple- de prueba mentacin

Ejemplo concreto de la apariencia de una descripcin de arquitectura

No es fcil de hacer. Es un extracto adecuado de los modelos del sistema

La descripcin de la arquitectura tiene cinco secciones, una para cada modelo:

Una vista del modelo de casos de uso. Una vista del modelo de anlisis. Una vista del modelo de diseo. Una vista del modelo de despliegue. Una vista del implementacin. modelo de

Vista de la arquitectura del modelo de casos de uso

Cliente de Banco

Sacar Dinero

Vistas de la arquitectura del modelo de diseo

Gestor de clientes Gestor de transacciones Gestor de cuentas

Retirada de efectivo "subsystem" Interfaz del CA Cliente de banco Entrega "subsystem" Gestin de transacciones Transferencias "subsystem" Gestin de cuentas

Transferir

Depsitos

Historia

1: Identificar(cantidad) "subsystem" Interfaz del CA Cliente de banco 5: dinero()

2: Retirada::realizar (cantidad, cuenta)

3: Transferencias::validar y retirar (cantidad, cuenta) "subsystem" Gestin de transacciones "subsystem" Gestin de cuentas

4: Entrega::autorizarEntrega (cantidad)

Vista de la arquitectura del modelo de despliegue

Internet Cliente CA Cliente de Banco Servidor de aplicaciones CA Intranet

Servidor de datos CA

Vista de la arquitectura del modelo de despliegue

( distribucin de clases )
:Servidor de aplicaciones CA

:Cliente CA

:Servidor de datos CA

Gestor de clientes

Gestor de transacciones

Gestor de cuentas

Diagrama de Despliegue

Un proceso iterativo e incremental

Beneficios
Desarrollo en pequeos pasos. Planificar un poco Especificar, disear e implementar un poco. Integrar, probar, y ejecutar un poco en cada iteracin. Permitir: Para tomar las riendas de los riesgos crticos desde un principio. Para poner en marcha una arquitectura que gue el desarrollo. Proporcionar un marco de trabajo que gestione de mejor forma, los inevitables cambios en los requisitos. Para construir el sistema a lo largo del tiempo.

Atenuacin de Riesgos
Importancia del riesgo en el tiempo

Avance de la codificacin

Cada iteracin constituye un pasada a traves de los cinco flujos de trabajo fundamentales

Requisitos

Anlisis

Diseo

Implementacin

Prueba

Incluye adems : La planificacin de la iteracin y el anlisis de la iteracin y Algunas otras actividades especficas

Una iteracin

Iteracin 1
Req. Anlisis Diseo Implem. Prueba

Iteracin 2
Req. Anlisis Diseo Implem. Prueba

Iteracin 3
Req. Anlisis Diseo Implem. Prueba

Las fases renen iteraciones

Hitos
Hito de los objetivos del ciclo de vida Hito de la arquitectura del ciclo de vida Hito de la funcionalidad operativa inicial Hito de la versin del producto

Inicio
Iteracin #1

Elaboracin
Iteracin #2 __

Construccin
__ __

Transicin
Iteracin Iteracin # n-1 # n

Las iteraciones sobre el ciclo de vida

Fases Flujos de Trabajo Fundamentales
Requisitos Anlisis Diseo Implementacin Prueba
Iterac. Iterac. #1 #2 __ __ __ __ __ Iterac. # n-1 Iterac. # n

Inicio

Elaboracin Construccin

Transicin

Iteraciones

Los modelos evolucionan con las iteraciones

Inicio
C A D D I P C

Elaboracin
A D D I P

Construccin
C A D D I P C

Transicin
A D D I P

MUCHAS GRACIAS