1 modelado semi formal: etapas métodos estructurados de análisis y diseño –origen: la...
TRANSCRIPT
1
Modelado Semi formal: Etapas
• Métodos Estructurados de Análisis y Diseño– Origen: La Programación Estructurada
– Predomina el enfoque de Edward Yourdon
– Inicialmente tenían un claro enfoque “procedural” (reproducir en la computadora un proceso que con anterioridad se efectuaba manualmente)
• Ingeniería de la Información– Origen: Fuertemente influido por la disponibilidad de la Tecnología de Base de datos
– Decididamente orientada al Modelado de Datos
– Existieron muchas y muy buenas metodologías: SSADM; Merise: Jackson: James Martin
• Análisis y Diseño Orientado a Objetos– Origen: Paradigma de Orientación a Objetos
– Surgen muchas metodologías en forma caótica
– Los trabajos de Jacobson, Booch, Rumbaugh
– Luego del UP - UML
2
Modelo del Ciclo de Vida
• Conjunto de las fases por las que atraviesa un producto de software desde su estudio de viabilidad hasta que es retirado de operaciones por obsolescencia; incluye la forma en la que se relacionan las mencionadas fases entre sí.
• Desarrollo por ciclo de vida y desarrollo por prototipo no son opciones contrapuestas; todos los modelos de Ciclo de Vida vigentes a la fecha incluyen el prototipado en sus fases y en la relación entre sus fases (no podría ser de otra manera)
3
Ciclo de Vida Lineal Secuencial
Programación Pruebas ImplantaciónDiseñoAnálisisViabilidad
Ventajas:- Es muy fácil de comprender- Es útil para introducir el concepto de “Ciclo de Vida”Desventajas- Ineficiencias por “esperas”- Los usuarios “ven” el producto al final del “Ciclo de Vida”
4
Ciclo de Vida “en Cascada”
Programación
Pruebas
Implantación
Diseño
Análisis
Viabilidad
Ventajas:- Introduce el concepto de interactividad- Introduce el concepto de iteractividad Desventajas- Casi todos los reciclos propuestos son inviables
5
Ciclo de Vida Lineal Incremental
Programación Pruebas ImplantaciónDiseñoAnálisis
tiempo
Programación Pruebas ImplantaciónDiseñoAnálisis
Programación Pruebas ImplantaciónDiseñoAnálisis
Ventajas- Introduce el concepto de Incrementalidad- Más flexible que el Lineal Secuencial
Desventajas- Su capacidad para absorber el concepto de Prototipo es escasa- Al igual que el Lineal Secuencial evidencia cierta ineficiencia enla utilización de los recursos (aunque en menor medida)
6
Ciclo de Vida RAD (Desarrollo Rápido)
Ventajas:- Incremento significativo de la productividad- Compatible con Métodos más sofisticados ypotentes que los Métodos Estructurados Desventajas- Tentación de no alcanzar niveles de robustezy confiabilidad aceptables
La disponibilidad de Tecnologíade Bases de Datos induce suutilización
Prototipode Aplicaciones
Desarrollde Aplicaciones
Implantacióny Pruebas
Modelado de Aplicaciones
Modeladode Datos
Modeladodel Negocio
Equipo 1
Equipo 2
Equipo 3
Equipo n
Prototipode Aplicaciones
Desarrollde Aplicaciones
Implantacióny Pruebas
Modelado de Aplicaciones
Modeladode Datos
Modeladodel Negocio
Prototipode Aplicaciones
Desarrollde Aplicaciones
Implantacióny Pruebas
Modelado de Aplicaciones
Modeladode Datos
Modeladodel Negocio
7
Ejemplo de Diagrama de Flujo de Datos
8
Concepto de Prototipo Evolutivo
tiempo
¡¡Diferencias con lo que el Arquitecto considera “Prototipo”!!
Prototipado Evolutivo y Ciclo de Vida en Espiral
9
Modelo de Ciclo de Vida en Espiral
6.SW OOA-
Dynamic View
7.SW OOD-Process
View
7.SW OOD-Vista de los
Procesos
9.SW OOD-
DynamicView
9.SW OOD-
Vista Dinámica
11.SW OOD-
Method Design
11.SW OOD-
Diseño (Métodos)
10.SW OOD-Language
Representation
10.SW OOD-Language
Representation
12.Class
Implementation/Test
12.Clases
Test de Implementación
13.Category
Test
13.Agregación
Test
Trace
16.Requerimientos
(Traza)
4.HW/SW
Split
4.HW/SW
Split
3.System OOA-Dynamic View
15.System
Test
15.Prueba del
Sistema
8.SW OOD-
Static View
8.SW OOD-
Vista Estática
17.Maintenance
17.Mantenimiento
2.System OOA-Static View
2.System OOA-Static View
Requerimientos1.
5.SW OOA-
Static View
14.BIT
14.Prueba deIntegración
10
Ciclo de Vida “Proceso Unificado”Ciclo de Vida “Proceso Unificado”
• UP es un proceso de desarrollo de software:
– Es una forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo (quién hace qué, cuándo y cómo). Es más que un Modelo de Ciclo de Vida
• Objetivos:– Posibilitar un gerenciamiento centrado en la arquitectura, iterativo e incremental
(facilitando el control de versiones)
– Asegurar la producción de software ajustado a estándares de calidad basados en el Proceso
– Facilitar los procesos de certificación de calidad
– Apoyar un desarrollo basado en componentes, tanto nuevos como preexistentes
Requisitos del usuario Sistema de softwareProceso de desarrollode software
11
Flujos de Trabajode Ingeniería
Aspectos de la Capa 3
Flujos de Trabajode Apoyo
(Environment incluye “Risk Management”)
Aspectos de la Capa 1
Fases y flujos de trabajo del UPFases y flujos de trabajo del UP
Organización a lo largo del tiempo
FasesFlujos de trabajo principales
Flujos de trabajo de apoyo
Organizaciónsegún la
naturaleza delas tareas
Aspectos de laCapa 2
12
Otros enfoques para el desarrollo
Se destaca que:- Los Métodos Estructurados- Todas las Metodologías incluidas en la Ingeniería de la Información- El Análisis y Diseño Orientados a ObjetosConstituyen enfoques “semi formales” (también llamados enfoques “gráficos”) para el Desarrollo de Sistemas de Información
Existen otros enfoques:1. Más exigentes y rigurosos:1.1. Métodos Formales (son métodos de especificación de raíz algebraica)1.2. Redes de Petri (utilizan la Teoría de Grafos en forma dinámica para laespecificación de sistemas distribuidos, concurrentes con especificaciones“duras” de Tiempo Real)2. Más ágiles, menos formales, menos rigurosos:2.1. Metodologías Ágiles (“el código es la especificación”)2.2. El lenguaje Haskell como herramienta de especificación, programación y verificación de sistemas.
13
Los Métodos Estructurados
• Presentación de dos “gurúes”– Ed Yourdon (ámbito técnico profesional)
– Donald Knuth (ámbito académico)
• La propuesta de Yourdon (Métodos Estructurados)• La Utilización del Diagrama de Flujos de Datos en
el contexto de los Métodos Estructurados• Ejemplos de utilización del DFD• ¿Cómo se llega a la estructura de un programa a
partir del Diagrama de Flujo de Datos
14
Métodos estructurados: Ed Yourdon
Edward Yourdon es ampliamente reconocido como el líder del desarrollo de los métodos estructurados de análisis y diseño en los 70´s y al comienzo de los 80´s. Fue realmente exitoso al extender, al ámbito del Análisis y Diseño, los conceptos de la Programación Estructurada. Si bien es el co desarrollista del Yourdon/Whitehead method of object-oriented analysis/design y de la difundida metodología Yourdon / Coad de análisis y diseño Orientados a Objetos, el cambio de paradigma eclipsó a quien fuera por década y media el referente mundial en todo lo que tuviese que ver con desarrollo de software. Toda una generación de primeras figuras mundiales, en lo que hace al desarrollo de software, en algún momento, estuvo relacionada con Yourdon: De Marco, Gane, Ward, Mellor, etc.Yourdon comienza su carrera profesional en Digital Equipment Company; allí es un pionero en temas tales como time-sharing operating systems and virtual memory systems. En 1974 Yourdon fundó YOURDON Inc destinada a poveer servicos educacionales, de publicaciones y de consultoría. YOURDON Inc formó en métodos estructurados a más de 250,000 profesionales en el mundo. La división editorial (ahora parte de Prentice Hall), editó más de 150 libros relacionados con el desarrollo de software. Semi retirado, en la actualidad, Yourdon es asesor en software "best-practices" en el US Department of Defense.Yourdon escribió más de 200 artículos técnicos relevantes y 24 libros de desarrollo de software desde 1967. Ed Yourdon recibió un B.S. in Applied Mathematics en el MIT; sus estudios de post grado (maestría) los desarrolló en el Polytechnic Institute of New York.
15
La Programación Estructurada: D. Knuth
Donald Ervin Knuth, nacido el 10 de enero de 1938 en Milwaukee, Wisconsin, es uno de los más reconocidos expertos en todo lo relacionado con la programación de computadoras. Actualmente es Profesor Emérito de la Universidad de Stanford.Se le conoce principalmente como autor de la obra “The Art of Computer Programming” la referencia insoslayable en lo que hace a la programación algorítmica / estructurada.Junto con los Profesores Aho y Ullmann (también de Stanford) constituyen el equipo que más ha contribuido en el campo de los algoritmos computacionales.Knuth obtuvo casi simultáneamente su BSc y su MSc en Matemáticas en 1960 en el Case Institute of Technology (ahora Case School of Engineering, una parte de la Case Western Reserve University). En 1963 obtuvo su Ph.D. en Matemáticas en el California Institute of Technology.Puede afirmarse que, los trabajos e ideas del Dr Knuth en el ámbito de la Programación, inspiraron los primeros trabajos en el ámbito de las metodologías de desarrollo de software (Análisis y Diseño)
16
Métodos Estructurados: Metodología Yourdon
• Modelo Esencial– Modelo Ambiental
– Modelo de Comportamiento• Modelo de Procesos
• Modelo de Datos
• Modelo de Implementación– Modelo de Implementación
del Usuario
– Modelo de Implementación del Sistema
• Modelo de Transacciones
• Modelo de Procesadores
– Modelo de Implementación de Programas
Técnicas o herramientasLista de Eventos - DFD
DFDDiagrama Entidad Relación
Según convenga
Diagrama de Transición de EstadosDFD
Diagrama de Estructura
¿Q
UÉ
? E
spec
ifica
cion
es
y A
nális
is¿
CÓ
MO
? D
iseñ
o C
onc
ept
ual
y F
ísic
o
17
La Lista de Eventos consiste en una descripción detallada del ámbito
relevado mediante oraciones simples (único verbo); evitando la voz pasiva
y evitando también el sujeto tácito
Lista de Eventos y Diagrama de ContextoModelo Ambiental: Lista de Eventos + “mini” DFD de cada Evento + Diagrama de Contexto
El Cliente coloca la Orden de Compra
El Cliente efectúa un Pago
El Cliente consulta Precio
Etc.; etc.; ...
Se genera elDiagrama de
Contexto
Orden de Compra
RegistrarOrden deCompra
Cliente
Clientes
Datos Orden de Compra
Datos acuse recibo
Se consolidan todos los
DFD de todos los eventos
¡¡VER APUNTE!!
18
Diagrama de Flujo de Datos: Componentes
Flujo de Datos
Proceso EntidadExterna
Flujo de Control
Almacenamiento de Datos
19
Un ejemplo muy simple de DFD
Oficina deRecursosHumanos
LiquidarHaberes Empleados
Datos para Liquidación
Datos Liquidación
Recibo deHaberes
20
Otro formato de Diagrama de Flujo de Datos
CLIENTE COCINA
GERENTE DEL LOCAL
Sistema deRegistro
de Pedidos
Orden del ClienteOrden a Cocina
Factura al Cliente
Informes aGerenciaEjemplo de
Diagrama deContexto
21
Desagregando el Diagrama de Contexto
CLIENTE COCINA
GERENTEDEL LOCAL
Orden del Cliente
Bajas diarias de Inventario
Artículos vendidosen el día
Datos de Artículos Vendidos Datos de Inventario
Orden de Comida
Informes Gerenciales
Factura
Datos de Inventario
Artículosvendidos
Arch.ivo de Inventario
Archivo de Art.vendidos
ProcesarOrden del
Cliente
GenerarInformes
Gerenciales
ActualizarArchivo deInventario
ActualizarArchivo de
Ar´t. vendidos
Ahora expandiremoseste Proceso
22
Un nuevo nivel de desagregación
PrepararInformes aGerencia
ConsolidarDatos de artículos
vendidos e Inventario
Acceder a Datos de artículos
vendidos e Inventario
Cantidad diariade artículos
vendidos
Descuentos disriosde Inventarios
Datos de Inventarios
Datos de Artículos vendidos
InformesGerenciales
Datos consolidados
23
Del DFD al Diagrama de Estructura¿cómo llegar al “mapa” del Programa?
Consolidar yTransformar
Formatear yEmitir
Capturar “a” yTransformarlo
en “c”
a
b
c
d
e f
Capturar “b” yTransformarlo
en “d”
ProgramaPrincipal
Validar yTransformar
Consolidar yTransformar
Capturar “b” Capturar “a”
Formatear yEmitir
c
de
d
e
a b
ef
Una vez que, mediante desagregaciones sucesivas, se ha llegado a unnivel de detalle adecuado en cada Proceso (“burbuja”), será posible lo-grar un “mapa” del programa correspondiente a cada segmento del DFD.
En el contexto de los Métodos Estructurados, dicho “mapa” de los futuros programas se denomina: “Diagrama de Estructura” (“Modelo de Diseño a NivelPrograma”).
Es importante hacer la salvedad de que el Diagrama de Estructura, como modelo de un programa, es útil cuando el lenguaje de programación es algorítmico o procedural o de 3ra Generación (sinónimos). Ejemplo: Cobol,Fortran, Pascal, Algol, Basic , e, inclusive, C.
No resulta posible utilizar el Diagrama de Estructura como modelo de programasi el lenguaje es “no estructurado”. En lenguajes con “intercambio de mensajes”no estructurado como C++; Java (y todos sus dialectos), Smalltalk, etc., todas las técnicas de “descomposición funcional” (esencia de los Métodos Estructurados) tienen dificultades.
24
Especificación de Procesos
SEUDO CÓDIGO
Si el monto de la factura excede los U$S 500 Si la cuenta tiene alguna factura vencida por más de 60 días suspender las tareas hasta la solución del pendiente En caso contrario (no hay facturas vencidas) emitir y enviar la facturaEn caso contrario (la factura es de U$S 500 o menos) Si la cuenta tiene alguna factura vencida por más de 60 días emitir y enviar la factura y enviar mensaje de reclamo En caso contrario (no hay facturas vencidas) emitir y enviar la factura
Reglas1 2 3 4 si no si nosi si no no
no si si sino si si sino si no no
Condiciones
1. Factura > U$S 5002. Facturas vencidas (>60 días)
Acciones1. Emitir factura2. Enviar factura3. Enviar reclamo
TABLA DE DECISION
Política de facturación
Factura > U$S 500
Factura <= U$S 500
Demoras > 60 días
Cuenta al día
Demoras > 60 días
Cuenta al día
1. Suspender tareas
2. Emitir y enviar factura
3. Emitir y enviar factura con reclamo
4. Emitir y enviar factura
ARBOL DE DECISION
25
¿Qué es RUP?¿Qué es RUP?
• RUP es un proceso de desarrollo de software:– Forma disciplinada de asignar tareas y responsabilidades en una empresa
de desarrollo (quién hace qué, cuándo y cómo).
• Objetivos:– Asegurar la producción de software de calidad dentro de plazos
y presupuestos predecibles. Dirigido por casos de uso, centrado en la arquitectura, iterativo (mini-proyectos) e incremental (versiones).
• Es también un producto:– Desarrollado y mantenido por Rational.
– Actualizado constantemente para tener en cuenta las mejores prácticas de acuerdo con la experiencia.
Requisitos del usuario Sistema de softwareProceso de desarrollode software
26
¿Qué es RUP?¿Qué es RUP?
Rational Unified Process 5.0
Rational Objectory Process 4.1
Rational Objectory Process 4.0
Rational Approach Objectory
Process
Pruebas de rendimiento y carga(Performance Awareness)
Ingeniería de Negocios
Diseño OO de IU
Ingeniería de Datos(Vigortech)
UML 1.2
Proceso SQA(SQA Inc.)
UML 1.0
Administración de Configuración y Cambios
(Pure-Atria)
Escuela de Requerimientos(Requisite Inc.)
OMTBooch
UML 0.8
1998
1997
1996
1995
Ericsson method1967
1987
27
Las mejores prácticasLas mejores prácticas
• RUP pretende implementar las mejores prácticas actuales en ingeniería de software:
– Desarrollo iterativo del software
– Administración de requerimientos
– Uso de arquitecturas basadas en componentes
– Modelamiento visual del software
– Verificación de la calidad del software
– Control de cambios
28
Desarrollo iterativoDesarrollo iterativo
• El software moderno es complejo y novedoso. No es realista usar un modelo lineal de desarrollo como el de cascada.
• Un proceso iterativo permite una comprensión creciente de los requerimientos a la vez que se va haciendo crecer el sistema.
• RUP sigue un modelo iterativo que aborda las tareas más riesgosas primero.
• Con esto se logra reducir los riesgos del proyecto y tener un subsistema ejecutable tempranamente.
29
Administración de requerimientosAdministración de requerimientos
• RUP describe cómo:– Obtener los requerimientos
– Organizarlos
– Documentar requerimientos de funcionalidad y restricciones
– Rastrear y documentar decisiones
– Captar y comunicar requerimientos del negocio
• Los casos de uso y los escenarios indicados por el proceso han probado ser una buena forma de captar requerimientos y guiar el diseño, la implementación y las pruebas.
30
Arquitecturas basadas en componentesArquitecturas basadas en componentes
• El proceso se basa en diseñar tempranamente una arquitectura base ejecutable.
• La arquitectura debe ser:– Flexible
– Fácil de modificar
– Intuitivamente comprensible
– Promueve la reutilización de componentes
• RUP apoya el desarrollo basado en componentes, tanto nuevos como preexistentes.
31
Modelamiento visualModelamiento visual
• Modelamiento visual de la estructura y el comportamiento de la arquitectura y los componentes.
• Bloques de construcción:– Ocultan detalles
– Permiten la comunicación en el equipo de desarrollo
– Permiten analizar la consistencia:• entre las componentes
• entre diseño e implementación
• UML es la base del modelamiento visual de RUP.
32
Verificación de cualidadesVerificación de cualidades
• No sólo la funcionalidad es esencial, también el rendimiento y la confiabilidad.
• RUP ayuda a planificar, diseñar, implementar, ejecutar y evaluar pruebas que verifiquen estas cualidades.
• El aseguramiento de la calidad es parte del proceso de desarrollo y no la responsabilidad de un grupo independiente.
33
Control de cambiosControl de cambios
• Los cambios son inevitables, pero es necesario evaluar si éstos son necesarios y rastrear su impacto.
• RUP indica como controlar, rastrear y monitorear los cambios dentro del proceso iterativo de desarrollo.
34
Ciclos y fasesCiclos y fases
• RUP divide el proceso de desarrollo en ciclos, teniendo un producto al final de cada ciclo.
• Cada ciclo se divide en cuatro Fases:– Inicio
– Elaboración
– Construcción
– Transición
• Cada fase concluye con un hito bien definido donde deben tomarse ciertas decisiones.
35
Fases de RUPFases de RUP
36
• Se establece la oportunidad y alcance el proyecto.
• Se identifican todas las entidades externas con las que se trata (actores) y se define la interacción a un alto nivel de abstracción:– Identificar todos los casos de uso
– Describir algunos en detalle
• La oportunidad del negocio incluye:– Criterios de éxito
– Identificación de riesgos
– Estimación de recursos necesarios
– Plan de las fases incluyendo hitos
Fases de RUP: InicioFases de RUP: Inicio
37
• Un documento de visión general:– Requerimientos generales del
proyecto
– Características principales
– Restricciones
• Modelo inicial de casos de uso (10% a 20 % listos).
• Glosario.
• Caso de negocio:– Contexto
– Criterios de éxito
– Pronóstico financiero
• Identificación inicial de riesgos.
• Plan de proyecto.
• Uno o más prototipos.
Fases de RUP: InicioFases de RUP: Inicio
Productos:
38
Inicio Elaboración Construcción Transición
Objetivos del Ciclo de Vida
• Las partes interesadas deben acordar el alcance y la estimación de tiempo y costo.
• Comprensión de los requerimientos plasmados en casos de uso.
Fases de RUP: InicioFases de RUP: Inicio
Hito:
39
• Objetivos:– Analizar el dominio del problema
– Establecer una arquitectura base sólida
– Desarrollar un plan de proyecto
– Eliminar los elementos de mayor riesgo para el desarrollo exitoso del proyecto
• Visión de “una milla de amplitud y una pulgada de profundidad” porque las decisiones de arquitectura requieren una visión global del sistema.
Fases de RUP: ElaboraciónFases de RUP: Elaboración
40
• Es la parte más crítica del proceso:– Al final toda la ingeniería
“dura” está hecha
– Se puede decidir si vale la pena seguir adelante
• A partir de aquí la arquitectura, los requerimientos y los planes de desarrollo son estables.
• Ya hay menos riesgos y se puede planificar el resto del proyecto con menor incertidumbre.
• Se construye una arquitectura ejecutable que contemple:– Los casos de uso críticos
– Los riesgos identificados
Fases de RUP: ElaboraciónFases de RUP: Elaboración
Productos:
41
Fases de RUP: ElaboraciónFases de RUP: Elaboración
• Modelo de casos de uso (80% completo) con descripciones detalladas.
• Otros requerimientos no funcio-nales o no asociados a casos de uso.
• Descripción de la Arquitectura del Software.
• Un prototipo ejecutable de la arquitectura.
• Lista revisada de riesgos y del caso de negocio.
• Plan de desarrollo para el resto del proyecto.
• Un manual de usuario preliminar.
Productos:
42
• Condiciones de éxito de la elaboración:– ¿Es estable la visión del producto?
– ¿Es estable la arquitectura?
– ¿Las pruebas de ejecución demuestran que los riesgos han sido abordados y resueltos?
– ¿Es el plan del proyecto algo realista?
– ¿Están de acuerdo con el plan todas las personas involucradas?
Concepción Elaboración Construcción Transición
Arquitectura de Ciclo de Vida
Fases de RUP: ElaboraciónFases de RUP: Elaboración
Hito:
43
• En esta fase todas las componentes restantes se desarrollan e incorporan al producto.
• Todo es probado en profundidad.
• El énfasis está en la producción eficiente y no ya en la creación intelectual.
• Puede hacerse construcción en paralelo, pero esto exige una planificación detallada y una arquitectura muy estable.
Fases de RUP: ConstrucciónFases de RUP: Construcción
44
• El producto de software integrado y corriendo en la plataforma adecuada.
• Manuales de usuario.
• Una descripción del “release” actual.
Fases de RUP: ConstrucciónFases de RUP: Construcción
Productos:
45
Fases de RUP: ConstrucciónFases de RUP: Construcción
• Se obtiene un producto Beta que debe decidirse si puede ponerse en ejecución sin mayores riesgos.
• Condiciones de éxito:– ¿El producto está maduro y estable para instalarlo en el ambiente
del cliente?
– ¿Están los interesados listos para recibirlo?
Concepción Elaboración Construcción Transición
CapacidadOperacional
Hito:
46
• El objetivo es traspasar el software desarrollado a la comunidad de usuarios.
• Una vez instalado surgirán nuevos elementos que implicarán nuevos desarrollos (ciclos).
• Incluye:– Pruebas Beta para validar el producto con las expectativas del
cliente
– Ejecución paralela con sistemas antiguos
– Conversión de datos
– Entrenamiento de usuarios
– Distribuir el producto
Fases de RUP: TransiciónFases de RUP: Transición
47
• Obtener autosuficiencia de parte de los usuarios.
• Concordancia en los logros del producto de parte de las personas involucradas.
• Lograr el concenso cuanto antes para liberar el producto al mercado.
Concepción Elaboración Construcción Transición
Producto
Fases de RUP: TransiciónFases de RUP: Transición
Objetivos:
48
Trabajador• Un trabajador define el comportamiento y las
responsabilidades de un individuo.
• Es como un “sombrero” que la persona usa durante el proyecto:– Una persona puede tener varios sombreros
– Es el rol que desempeña en un momento dado
• Responsabilidades:– Hacer una serie de actividades
– Ser el responsable de una serie de artefactos
DefinicionesDefiniciones
49
Actividades
DefinicionesDefiniciones
• Una actividad es una unidad de trabajo que se asigna a un trabajador. Ej.:– Crear o modificar un artefacto
• Una actividad lleva entre un par de horas y un par de días, involucra un solo trabajador y un número pequeño de artefactos.
• Las actividades se consideran en la planificación y evaluación del progreso del proyecto.
• Ejemplos:– Planificar una iteración - Administrador
de proyecto
– Encontrar actores y casos de uso - Analista
– Revisar el diseño - Revisor de diseño
– Ejecutar pruebas de performance - Ing. de pruebas de performance
50
Recurso Trabajador Actividad
Pablo Diseñador Diseño de Objetos
María Autor de Casos de Uso Detallar un Caso de Uso
José Diseñador de Casos de Uso Diseñar un Caso de Uso
Silvia Revisor de Diseño Revisar el Diseño
Eduardo Arquitecto Análisis de Arquitectura Diseño de Arquitectura
Asignación de actividadesAsignación de actividades
51
• Elementos de información producidos, modificados o usados por el proceso.
• Son los productos tangibles del proyecto.
• Son usados por los trabajadores para realizar nuevas actividades y son el resultado de esas actividades.
• Ejemplos:– Un modelo, como el modelo de
casos de uso o el modelo de diseño.
– Un elemento del modelo, como una clase o un caso de uso.
– Un documento tal como el Caso del Negocio o la Arquitectura del Software.
– Código fuente.
– Código ejecutable.
ArtefactosArtefactos
52
• Una lista de actividades, trabajadores y artefactos constituye un proceso.
• Un flujo de trabajo es una secuencia de actividades que produce un resultado valioso.
• No siempre es posible representar flujos de trabajo.
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
Flujos de trabajoFlujos de trabajo
53
Flujos de Trabajode Ingeniería
Flujos de Trabajode Apoyo
Flujos de trabajo esencialesFlujos de trabajo esenciales
54
Flujos de trabajoFlujos de trabajo
• Existen habitualmente problemas de comunicación entre ingenieros de software e ingenieros de negocios.
• RUP proporciona un lenguaje y proceso común para estos dos ámbitos.
• Para el modelamiento del negocio se usan “business use cases” (casos de uso del negocio):– La forma en que el software dará apoyo al negocio.
55
Cliente Reciclar
Imprimir Informe
Operador
Administrar Depósito
• Los desarrolladores y clientes deben acordar qué es lo que el sistema debe hacer:– Relevar requerimientos
– Documentar funcionalidad y restricciones
– Documentar decisiones
– Identificar actores
– Identificar casos de uso
• Los casos de uso describen la funcionalidad.
• Los requerimientos no funcionales se incluyen en una especificación complementaria.
RequerimientosRequerimientos
56
• Descripción de cómo se implementará el sistema: un plano
• Debe:– Ejecutar las tareas y funciones
descritas en los casos de uso
– Satisfacer todos los requerimientos
– Flexible a cambios
• El diseño se centra en la noción de arquitectura.
• Diseñar y validar la arquitectura es una tarea esencial.
• El modelo de diseño consta de – Clases estructuradas en paquetes
– Diseños de subsistemas con interfaces definidas (componentes)
– Forma de colaboración entre las clases.
Análisis y diseñoAnálisis y diseño
57
• Propósito:
– Definir la organización del código
– Implementar clases y objetos en forma de componentes (fuente, ejecutables, etc.)
– Probar las componentes desarrolladas
– Integrar las componentes en un sistema ejecutable
ImplementaciónImplementación
58
• Propósito:– Verificar la interacción entre los
objetos
– Verificar la integración apropiada de componentes
– Verificar que se satisfacen los requerimientos
– Identificar los defectos y corregirlos antes de la instalación
• RUP describe como planear y ejecutar estas pruebas.
• RUP propone probar las componentes desde el principio:– Confiabilidad, funcionalidad y
performance
• Las pruebas de regresión son importantes en desarrollos iterativos.
• Rational tiene herramientas para automatizar algunas pruebas.
PruebasPruebas
59
• Producir un producto y hacerlo llegar a sus usuarios finales.
• Incluye varias actividades:– Producir un “release”
– Empaquetar el software
– Distribuir el software
– Instalar el software
– Apoyar a los usuarios
• A veces también incluye:– Realizar pruebas beta
– Migración de datos
– Aceptación formal
• La mayor parte de la distribución ocurre durante la transición.
• Este es uno de los flujos de trabajo menos documentados en RUP.
DistribuciónDistribución
60
• Es el arte de balancear objetivos contrarios, manejar riesgos y producir software que satisface a clientes y usuarios.
• Existen pocos proyectos realmente exitosos.
• RUP incluye:– Un framework para manejo de proyectos de software
– Guías para planificación, provisión de personal, ejecución y monitoreo de planes
– Un framework para manejar riesgos
Administración de proyectosAdministración de proyectos
61
• Forma de controlar los artefactos producidos por las personas que trabajan en el proyecto.
• Algunos problemas habituales:– Actualizaciones simultáneas
– Múltiples versiones
• RUP da guías para:– Desarrollos en paralelo
– Automatizar la construcción
– Administrar defectos
Administración de configuración y cambiosAdministración de configuración y cambios
62
• Ambiente y herramientas de desarrollo que harán posible llevar a cabo el proyecto.
• RUP guía en la configuración de un ambiente de proceso apropiado a cada proyecto.
AmbienteAmbiente
63
Síntesis