• Save
Métrica v3 y RUP
Upcoming SlideShare
Loading in...5
×
 

Métrica v3 y RUP

on

  • 3,389 views

Métrica v3 y Rational Unified Process.

Métrica v3 y Rational Unified Process.
Metodologías estructuradas de gestión de proyectos aplicadas al desarrollo de software.

Statistics

Views

Total Views
3,389
Views on SlideShare
3,388
Embed Views
1

Actions

Likes
4
Downloads
0
Comments
0

1 Embed 1

http://www.podidoo.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Métrica v3 y RUP Métrica v3 y RUP Presentation Transcript

  • Metodologías de Gestión de Proyectos I: Métrica v3 y Proceso Unificado Óliver Centeno Álvarez [ocenteno@pronoide.es]
  • 3 Contenidos I. Metodologías de Desarrollo y Gestión de Proyectos Software II. Métrica v3 III. El Proceso Unificado IV. Administración de Requisitos mediante Casos de Uso
  • 4 Contenidos I. Metodologías de Desarrollo y Gestión de Proyectos Software II. Métrica v3 III. El Proceso Unificado IV. Administración de Requisitos mediante Casos de Uso
  • 6 I. Metodologías de Desarrollo  Proceso de Desarrollo de Software  Necesidad  Gestión de proyecto  Estimación  Planificación  Medición  Ciclo de vida  Especificación/Análisis  Diseño y Construcción  Pruebas  Instalación y Mantenimiento
  • 7 I. Metodologías de Desarrollo  Modelos de ciclo de vida  Lineal  Evolutivo/Espiral  Retroalimentado/Prototipado  El modelo de ciclo de vida condiciona el tipo de metodología aplicada  Metodología clásica (pesada, formal)  Métrica, RUP  Metodología ágil  Scrum, XP
  • 8 I. Metodologías de Desarrollo  Metodologías de Análisis y Diseño  Enfoque estructurado  Más antiguo  Basado en procesos y flujos de datos  Merise, SSA, Métrica v3  Enfoque orientado a objeto  Más moderno  Utiliza conceptos “más humanos” como “entes” que interactúan entre sí  Enfoque empresarial  OMT, RUP, UML
  • 9 Contenidos I. Metodologías de Desarrollo y Gestión de Proyectos Software II. Métrica v3 III. El Proceso Unificado IV. Administración de Requisitos mediante Casos de Uso
  • 11 II. Métrica v3  ¿Qué es Métrica?  Metodología de Planificación, Desarrollo y Mantenimiento de Sistemas de Información del MAP  http://www.csi.map.es/csi/metrica3/index.html  Aporta  Una TERMINOLOGÍA y un MÉTODO DE TRABAJO comunes  Unas TÉCNICAS extendidas que permiten la comunicación  Unos RESULTADOS o productos definidos  INDEPENDENCIA de las metodologías propias  ¿Qué NO es Métrica?  Un ciclo de vida en cascada  Una metodología que hay que aplicar “tal cual”  Una metodología de gestión de proyectos
  • 12 II. Métrica v3  ¿Para qué sirve Métrica?  Definir SI que sirvan a la consecución de los fines de la organización  Dotar a la organización de productos SW  Mejorar la productividad de los departamentos  Facilitar la comunicación entre los participantes  Facilitar la operación y mantenimiento de los productos
  • 13 II. Métrica v3  Alcance del Método  Pasos a seguir en el desarrollo  Conjunto de productos finales a desarrollar  Conjunto de técnicas para obtenerlos  Roles de los participantes  Modo de implantación  Proyectos de distintos tamaños  Desarrollo Estructurado y Orientado a Objeto  Estándares ISO, IEEE y OMG  Análisis y Gestión de Riesgos (MAGERIT)  Aseguramiento de la Calidad (PGGC)
  • 14 II. Métrica v3  Procesos  Marco de trabajo  Conjunto de actividades con un fin determinado  Actividades  Comunes, de análisis estructurado y de análisis orientado a objeto  Agrupan conjuntos de tareas  Tareas  Caracterizadas por descripción, entrada, salida, técnicas y participantes  Interfaces  Elementos de comunicación con procesos externos
  • 15 II. Métrica v3
  • 16 II. Métrica v3  Un ejemplo
  • 17 II. Métrica v3  Un ejemplo  Nos han pedido implementar un juego  ¿Para Windows? ¿Para móviles? ¿Para PDAs?  ¿En Internet? ¿Cliente-Servidor? ¿Rich Client? ¿HTML? ¿AJAX?  ¿Java? ¿Symbian? ¿.Net?  ¿Accesibilidad para personas con minusvalía?  NO IMPORTA  Se realizan las mismas tareas en cada caso
  • 18 II. Métrica v3  Un ejemplo ASI EVS DSI
  • 19 II. Métrica v3. Procesos  Estructura de Procesos de Métrica v3  PSI (Planificación)  Desarrollo  EVS (Estudio de viabilidad)  ASI (Análisis)  DSI (Diseño)  CSI (Construcción)  IAS (Implantación y Aceptación)  MSI (Mantenimiento)
  • 20 II. Métrica v3  PSI  Objetivo: Tener un marco de referencia para el desarrollo del SI que responda a los objetivos estratégicos de la organización
  • 21 II. Métrica v3  PSI (algunas tareas) 1. Estudio de la información relevante  Se estudian las necesidades de la organización 2. Identificación de Requisitos 3. Diseño del Modelo de SI  Se obtienen modelos conceptuales de SI  Se evalúan las opciones tecnológicas y se propone un entorno 4. Definición de la Arquitectura Tecnológica  Descripción crítica de la situación actual 5. Definición del Plan de Acción  Propuesta de proyectos  Propuesta de calendario y estimación de recursos
  • 22 II. Métrica v3  EVS  Objetivo: Analizar las necesidades y proponer una alternativa de solución a corto plazo basada en criterios económicos, técnicos, legales y operativos  Seleccionar la solución más adecuada
  • 23 II. Métrica v3  EVS (algunas tareas) 1. Establecimiento del alcance del sistema  Qué se va a hacer y qué no se va a hacer 2. Estudio de la situación actual  Qué herramientas y SW hay actualmente 3. Definición de requisitos del sistema 4. Estudio de alternativas de solución  SW a medida, SW existente, SW mixto 5. Selección de la solución  Criterios: inversión, riesgos, impacto
  • 24 II. Métrica v3  ASI  Objetivo: Obtener una especificación detallada  Del sistema  De sus interfaces con otros sistemas  Que satisfaga las necesidades de los usuarios  Que sirva de base para el diseño  Integra las actividades de análisis estructurado y OO  Se refinan los productos obtenidos en EVS
  • 25 II. Métrica v3  ASI
  • 26 II. Métrica v3  ASI (algunas tareas) 1. Definición del Sistema 2. Análisis de Casos de Uso  Sólo en modelado orientado a objeto 3. Análisis de Clases  Sólo en modelado orientado a objeto 4. Definición de Interfaces de Usuario 5. Especificación del Plan de Pruebas
  • 27 II. Métrica v3  DSI
  • 28 II. Métrica v3  DSI (algunas tareas) 1. Definición de la arquitectura del sistema  Y del entorno tecnológico 2. Diseño de Clases 3. Diseño físico de datos  Especificación detallada de los componentes 4. Diseño de los procedimientos de migración y carga inicial (cuando proceda)  Definición de los requisitos de implantación 5. Especificación técnica del plan de pruebas
  • 29 II. Métrica v3  CSI
  • 30 II. Métrica v3  CSI (algunas tareas) 1. Se prepara el entorno de construcción  Base de Datos, herramientas, librerías,… 2. Se codifican y prueban los componentes  Pruebas unitarias 3. Se verifica si los componentes interactúan correctamente  Pruebas de integración 4. Se verifica la integridad del sistema globalmente  Pruebas de Sistema 5. Se escriben los manuales de usuario y explotación 6. Se construyen los procedimientos de migración y carga inicial de datos (si procede)
  • 31 II. Métrica v3  IAS  Entrega y aceptación del sistema  Actividades necesarias para el paso a producción
  • 32 II. Métrica v3  IAS (algunas tareas) 1. Se realiza la formación necesaria para la implantación 2. Se realiza la migración o carga inicial de datos  Se prepara el entorno de explotación  Se instalan los componentes  Se activan los procedimientos manuales y automáticos 3. Se realizan pruebas de implantación  Tiempos de respuesta deseados, seguridad, funcionamiento con otros sistemas,… 4. Se realizan pruebas de aceptación  El sistema se ajusta a las necesidades del usuario 5. Se prepara el mantenimiento  Si no lo realizamos nosotros
  • 33 II. Métrica v3  MSI  Objetivo: Obtener una nueva versión a partir de requisitos de mantenimiento de los usuarios  Correctivo: corregir errores  Evolutivo: cambio en las necesidades del usuario  Adaptativo: cambios en el entorno  Preventivo: mejorar la calidad interna del sistema  Sólo se contemplan correctivo y evolutivo
  • 34 II. Métrica v3  MSI (algunas tareas) 1. Se registra la petición de mantenimiento 2. Se analiza la petición  Se determina el responsable de atenderla  Si es correctivo: se reproduce el problema  Si es evolutivo: se estudia la viabilidad del cambio propuesto por el usuario 3. Se prepara la implementación de la modificación  Se analizan las alternativas de solución 4. Se registran y documentan los cambios 5. Se implementa la modificación  Se realizan las tareas necesarias de los procesos de desarrollo ASI, DSI, CSI o IAS  Se realizan pruebas de regresión
  • 35 II. Métrica v3  Ejercicio: ¿En qué proceso se utilizaría/generaría la siguiente documentación?  Un diagrama de casos de uso  Un diagrama de clases con patrones de diseño  Un diagrama Entidad / Interrelación  Un script de Oracle para migrar datos  Un organigrama de la división en secretarías de una consejería  El coste de una máquina servidor de aplicaciones  Un dibujo de una pantalla del sistema  Los resultados de una prueba de seguridad  Un diagrama de interacción entre clases  La ley de protección de datos
  • 36 II. Métrica v3  Ejercicio: ¿En qué proceso se utilizaría/generaría la siguiente documentación? Una posible solución  Un diagrama de casos de uso [ASI]  Un diagrama de clases con patrones de diseño [DSI]  Un diagrama Entidad / Interrelación [DSI/PSI]  Un script de Oracle para migrar datos [CSI]  Un organigrama de la división en secretarías de una consejería [PSI]  El coste de una máquina servidor de aplicaciones [EVS]  Un dibujo de una pantalla del sistema [ASI]  Los resultados de una prueba de seguridad [IAS]  Un diagrama de interacción entre clases [DSI]  La ley de protección de datos [EVS]
  • 37 II. Métrica v3  PSI  Un diagrama Entidad / Relación  Un organigrama de la división en secretarías de una consejería  EVS  El coste de una máquina servidor de aplicaciones  La ley de protección de datos personales  ASI  Un dibujo de una pantalla del sistema  Un diagrama de casos de uso  DSI  Un diagrama de clases con patrones de diseño  Un diagrama de interacción entre clases  CSI  Un script de Oracle para migrar datos  IAS  Los resultados de una prueba de seguridad
  • 45 II. Métrica v3. Interfaces  Interfaces  Métrica v3 incluye un conjunto de procesos con actividades que sirven de interfaz con otros procesos organizativos o de soporte  Gestión de Proyectos (GP)  Seguridad (SEG)  Gestión de Configuraciones (GC)  Aseguramiento de la Calidad (CAL)
  • 46 II. Métrica v3  Gestión de Proyectos  Planificación, seguimiento y control  De actividades  De recursos humanos y materiales  Que intervienen en el desarrollo de un SI  Para conocer en todo momento los problemas que se pueden producir y mitigarlos o resolverlos si se producen
  • 47 II. Métrica v3  Gestión de Proyectos  GPI (Gestión de Proyectos Inicio)  Estimación del esfuerzo y planificación del proyecto  GPS (Gestión de Proyectos Seguimiento)  Seguimiento y control del proyecto  Gestión de incidencias  Gestión de cambios en los requisitos  Reuniones de seguimiento  Aceptación  GPF (Gestión de Proyectos Final)  Cierre del proyecto
  • 48 II. Métrica v3  Interfaz de Seguridad  Incorporar mecanismos de seguridad adicionales que permitan desarrollar cualquier tipo de sistema  En cualquiera de los procesos de Métrica  Estudio, evaluación, aplicación y catalogación de productos generados  PSI-SEG
  • 49 II. Métrica v3  Interfaz de Seguridad  EVS-SEG  ASI-SEG
  • 50 II. Métrica v3  Interfaz de Seguridad  DSI-SEG  CSI-SEG
  • 51 II. Métrica v3  Interfaz de Seguridad  IAS-SEG  MSI-SEG
  • 52 II. Métrica v3  Gestión de Configuraciones  Mantener la integridad de los productos garantizando  Que no se producen cambios incontrolados  Que todos los participantes disponen de la versión adecuada  Que se puede recuperar una versión previa  Repositorios de código y documentos
  • 53 II. Métrica v3  Aseguramiento de la Calidad  Proporciona un marco común de referencia para la definición y puesta en marcha de planes específicos de calidad aplicables a proyectos concretos
  • 54 II. Métrica v3. Técnicas  Técnicas y prácticas utilizadas en Métrica v3  Análisis coste/beneficio  Análisis del impacto  Casos de Uso  Catalogación  Diagrama de Clases  DFD  Diagrama de Transición de Estados  Técnicas Matriciales  Modelo Entidad/Interrelación  Presentación  Prototipado  Pruebas  …
  • 55 II. Métrica v3
  • 56 II. Métrica v3  Análisis coste/beneficio  Proporcionar una medida de los costes previstos frente a los beneficios esperados  Para  Valorar la necesidad/oportunidad del proyecto  Seleccionar la alternativa más beneficiosa  Estimar los recursos económicos necesarios  Conceptos asociados  Punto de amortización  Período de amortización  ROI = 100*(BAN – CD)/IP BAN: Beneficio Anual Neto (ganancia que aporta) CD: Coste promedio de desarrollo por año IP: Inversión promedio
  • 57 II. Métrica v3  Análisis coste/beneficio  Estimación de los costes (financieros, de formación, de desarrollo, de instalación, de HW y SW,…)  Estimación de beneficios (incremento de ventas, incremento de productividad, ahorro de material,…)  Viabilidad del Proyecto  En base al año en que se recuperará la inversión  En base al dinero invertible para recuperar la inversión en un período de tiempo y con interés dados Año Coste Beneficio Beneficio Neto Valor Actual i Ci Bi BNi = Bi - Ci VAi=BNi/(1+r/100)*i ΣBNi = C0 ΣVAi > C0
  • 58 II. Métrica v3  Casos de Uso  Secuencia de acciones realizadas por el sistema en su interacción con el usuario  Para  Capturar los requisitos funcionales del sistema  Guiar el proceso de desarrollo  Recoge  Una descripción general del requisito/s que cubre  Las precondiciones y postcondiciones a cumplir  Los escenarios posibles  Mediante  Diagramas de Casos de Uso (UML)  Descripción textual (plantillas)
  • 59 II. Métrica v3  Casos de Uso
  • 60 II. Métrica v3  Diagrama de Clases  Representa los elementos que componen el sistema  Clase: Concepto o entidad que forma parte del negocio que vamos a implementar  Contiene propiedades descriptivas (datos)  Contiene funcionalidad característica de esa entidad  Admiten estereotipos para distinguir su objetivo  Relaciones: Representan interacción entre las clases  Asociación (composición y agregación)  Generalización  Dependencia  Interfaz: Especificación abstracta
  • 61 II. Métrica v3  Diagrama de Clases
  • 62 II. Métrica v3  Ejercicio  En mi negocio, un cliente puede realizar varios pedidos, aunque puedo tener clientes que aún no me hayan hecho ningún pedido  Cada pedido está compuesto uno o varios productos  Un pedido realizado se puede cerrar y despachar  Un cliente puede adelantar una cantidad del pedido  Detectar actores, casos de uso, clases
  • 63 II. Métrica v3  Ejercicio  ¿Qué entiende el programador?  Tienes que construir tres clases  Cliente con un atributo nombre y otro dirección  Producto con un atributo nombre  Pedido con un atributo fecha, otro adelanto, otro número, otro cliente y otro productos  Además tendrá un método cerrar y otro despachar
  • 64 II. Métrica v3  Diagramas de Componentes y Despliegue  Representan los elementos físicos del sistema  Componente: Fichero, librería, ejecutable,…  Relaciones de dependencia entre componentes  Nodo: PC, servidor, móvil, PDA,…  Conexiones entre nodos (cables)  Los nodos pueden contener componentes
  • 65 II. Métrica v3  Diagrama de Descomposición  Representa la estructura jerárquica de un dominio
  • 66 II. Métrica v3  Diagramas de Interacción  Describe el comportamiento del sistema mediante mensajes enviados entre los objetos  Objeto: Un elemento concreto cuyo tipo es una clase  Mensaje: Comunicación del tipo “haz algo”, “dame algo”, “toma algo”  Diagrama de Secuencia  Muestra la activación y tiempo de vida de objetos  Se convierten en funciones ejecutadas  Diagrama de Comunicación  Muestra las relaciones entre objetos  Sirve de base para el Diagrama de Clases
  • 67 II. Métrica v3  Diagramas de Interacción
  • 68 II. Métrica v3  Diagrama de Transición de Estados  Muestra el comportamiento del sistema que cambia con el tiempo o en base a eventos  Estados acciones y transiciones
  • 69 II. Métrica v3  Modelado de Procesos de la Organización  Mapa del proceso que representa la interacción entre actividades, objetos y recursos  Proceso, actividad (qué), procedimiento (cómo)  Un buen modelo:  Tiene un objetivo claramente definido  Permite una visión general y detallada de procesos  Identifica eventos disparadores de procesos  Identifica conexiones lógicas entre actividades  Establece medidas de tiempo, esfuerzo y coste  Crea un vocabulario común  Contiene gráficos y texto
  • 70 II. Métrica v3  SADT (Structured Analysis & Design Technique)  Actividades con entrada, salida, control y mecanismo  Entradas y salidas de información  Control: restricciones para las salidas  Mecanismo: máquinas, personas, recursos o sistemas existentes que ejecutan una actividades
  • 71 II. Métrica v3  Modelo Entidad-Interrelación  Representar y definir todos los datos que se introducen, almacenan, transforman y producen  Permite  Comprender los datos y funcionamiento  Obtener estructuras de datos independientes de BD  Mejorar el mantenimiento  Entidad: Objeto del que almacenar información  Atributo: Dato concreto almacenado para una entidad  Relación: Dependencia entre entidades  Cardinalidad: Orden de la relación  1:1, 1:N, N:M
  • 72 II. Métrica v3  Modelo Entidad/Interrelación
  • 73 II. Métrica v3  Reglas de Transformación  Permite obtener un modelo físico de datos a partir del modelo de objetos  Arquitecturas Dirigidas por Modelos  Clase  Tabla  Atributo  Columna  Asociación  Clave foránea en otra tabla  Agregación/Composición  Tabla intermedia  Herencia  Una tabla para todas las clases  Una tabla por subclase y una para la superclase  Tablas independientes
  • 74 II. Métrica v3  Técnicas Matriciales  Representan relaciones entre entidades, objetos u otro elemento del sistema  Matrices habituales:  Procesos/localización geográfica  Almacenes/entidades  Mensajes/métodos  Eventos/métodos  Clases/elementos del modelo físico  Requisitos/casos de uso  Objetos de interacción/clases  Atributos de interfaz/atributos del modelo físico
  • 75 II. Métrica v3  Análisis del Impacto  Determinar los elementos implicados en una petición de cambio cuando el sistema está funcionando  Es necesario un inventario de componentes y sus interrelaciones  Matrices de Trazabilidad  Ingeniería Inversa  Sólo se determina la importancia del cambio  Se requieren indicadores que midan el esfuerzo requerido antes de aplicar el cambio
  • 76 II. Métrica v3  Catalogación  Estructurar y almacenar la información para poder gestionarla de manera sencilla y facilitar su trazabilidad  Agruparla según ámbitos de aplicación  Requisitos, usuarios, objetivos,…  Determinar la información de interés  Id, descripción, fecha creación, estado, prioridad,…
  • 77 II. Métrica v3  Pruebas  Verificar el correcto funcionamiento, ensamblaje, tolerancia a errores, etc. de un sistema  Unitarias: para un único componente  De Integración: al ensamblar componentes  Del Sistema: funcionales, de rendimiento, sobrecarga, usabilidad, seguridad, escalabilidad,…  De Implantación: en el entorno de producción  De Aceptación: el sistema hace lo que se espera  De Regresión: ante cambios en el sistema
  • 78 II. Métrica v3  Otras prácticas  Presentaciones  Prototipado  Cálculo de Accesos  Caminos de Acceso  Diagrama de Representación  Estudio del Impacto en la Organización  Sesiones de trabajo  Revisiones  Entrevistas  Reuniones
  • 79 II. Métrica v3. Técnicas GSP  Técnicas de Gestión de Proyectos  Actividades específicas para administrar el proyecto  Estimación del esfuerzo  Planificación de tareas y recursos  Control de tareas  Seguimiento del proyecto  Control de incidencias  Control de cambios
  • 80 II. Métrica v3  Técnicas de Estimación  A partir de una estimación del esfuerzo/tamaño del proyecto se obtiene un coste esperado  Puntos de Función  Evalúa la complejidad de entradas, salidas, consultas, ficheros internos y ficheros externos  Unas tablas determinan si es SENCILLO, MEDIO o COMPLEJO en base a su número  Se calcular el total de puntos en otra tabla  Se ajusta el valor según 14 factores de complejidad  Que tienen influencia entre 0 (nula) y 5 (muy fuerte)
  • 81 II. Métrica v3  Puntos de Función Simple Media Compleja Total Cantidad * Peso Cantidad * Peso Cantidad * Peso Entradas * 3 * 4 * 6 Salidas * 4 * 5 * 7 Consultas * 3 * 4 * 6 Fic. Lógicos * 7 * 10 * 15 Fic. Interfaz * 5 * 7 * 10 Total puntos de función sin ajustar (PFSA) DIFICULTAD SALIDAS Número de Campos o Atributos de la Salida 1-5 Atributos 6-19 Atributos 20 + Atributos 0 ó 1 ficheros accedidos BAJA BAJA MEDIA 2 ó 3 ficheros accedidos BAJA MEDIA ALTA 4 + ficheros accedidos MEDIA ALTA ALTA # Factor de Complejidad Valor (0..5) 1 Comunicación de Datos. 2 Proceso Distribuido. 3 Rendimiento 4 Configuración Operacional compartida 5 Ratio de Transacciones 6 Entrada de Datos EN-LÍNEA 7 Eficiencia con el Usuario Final 8 Actualizaciones EN-LÍNEA 9 Complejidad del Proceso Interno 10 Reusabilidad del Código 11 Contempla la Conversión e Instalación 12 Facilidad de Operación (back up, etc.) 13 Instalaciones Múltiples 14 Facilidad de Cambios Factor de Complejidad Total (FCT) Valori
  • 82 II. Métrica v3  Técnicas de Estimación  Puntos de Caso de Uso (UUCP)  Adaptación al modelo orientado a objeto  Considera el peso de los actores (UAW) y de los casos de uso (UUCW)  El peso de los casos de uso se puede tomar en base al número de transacciones o al número de clases  Se ajusta mediante 13 factores de complejidad  Y 8 factores ambientales también evaluados de 0 a 5  Este cálculo estima el esfuerzo de desarrollo (~40%)  La unidades son horas/hombre
  • 83 II. Métrica v3  Puntos de Caso de Uso  Peso de los actores  Peso de los casos de uso
  • 84 II. Métrica v3  Puntos de Caso de Uso Ajustados (UCP)  Complejidad (TCF) y factores ambientales (EF)
  • 85 II. Métrica v3  Puntos de Caso de Uso  Cálculos:  Esfuerzo = (UCP x CF) / 40%  CF = {20, 28, 36} según experiencia  UCP = UUCP x TCF x EF  TCF = 0.6 + (0.01 * Sum(Valor*Peso))  EF = 1.4 + (-0.03 * Sum(Valor*Peso))  UUCP = UAW + UUCW  UAW = Sum(Actores de cada tipo * Factor)  UUCW = Sum(Casos de Uso de cada tipo * Factor)
  • 86 II. Métrica v3  Ejercicio  Sistema CRUD de pedidos con interfaz Web  UAW = 1x3 = 3  UUCW = 4x5 = 20  UUCP = 3 + 20 = 23  TCF = 0.6 + 0.01 x 17 = 0.77  EF = 1.4 - 0.03 x 19.5 = 0.82  UCP = 23 * 0.77 * 0.82 = 14.52  CF = 20 porque tenemos experiencia  Esfuerzo programación (~40%) = 14.52 * 20 = 290.4 h/h  Esfuerzo proyecto completo = 726 horas/hombre
  • 87 II. Métrica v3  Ejercicio Factor Peso Valor Descripción T1 2 0 Sistema centralizado T2 1 1 Las entradas condicionan la velocidad T3 1 1 Pocas restricciones de eficiencia T4 1 1 No hay cálculos complejos T5 1 0 No se requiere código reutilizable T6 0.5 1 No se requiere fácil instalación T7 0.5 3 Facilidad de uso normal T8 2 0 No se requiere portabilidad T9 1 3 Habrá un mantenimiento normal T10 1 0 Sin concurrencia T11 1 3 Seguridad normal T12 1 5 Acceso para usuarios Web T13 1 1 No requiere formación Factor Peso Valor Descripción E1 1.5 4 Conocemos el modelo E2 0.5 4 Tenemos mucha experiencia E3 1 4 Trabajamos con objetos E4 0.5 5 Se contrató un especialista E5 1 5 Alta motivación E6 2 2 Se esperan cambios E7 -1 0 Trabajo a tiempo completo E8 -1 3 C++, dificultad media
  • 88 II. Métrica v3  Técnicas de Planificación  Definir y preparar las condiciones de trabajo para lograr los objetivos del proyecto  PERT/CPM  Program Evaluation & Review Technique  Critical Path Method  Descompone el proyecto en actividades  Que se secuencian para ver sus precedencias  Permite identificar cuellos de botella  Diagrama de Gantt  Muestra las tareas a realizar, su inicio y duración  Se puede acompañar de un histograma de recursos
  • 89 II. Métrica v3  Diagrama de Gantt
  • 90 II. Métrica v3  Ejemplo PERT  A precede a C, D, E  B precede a C  C precede a K  D precede a F, G  E precede a J  F precede a I A B C D E F G H I J K L M N P Q R  G precede a H  H, I y J preceden a L  K precede a M  L precede a P  M precede a N  N y P preceden a Q  Q precede a R
  • 91 II. Métrica v3  Ejemplo PERT
  • 92 II. Métrica v3  WBS (Work Breakdown Structure)  Descomposición de las actividades en tareas más sencillas  Permiten secuenciar y estimar mejor las tareas
  • 93 II. Métrica v3  Seguimiento y Control del Proyecto  Objetivo: Analizar, comprender, controlar, predecir y mejorar la ejecución del proyecto  Medidas de Software  Calidad, productividad, coste, líneas de código, #errores detectados,…  No son interpretables por sí mismas  Indicadores  Métodos de cálculo, escalas y criterios de decisión  Para evaluar una medida y detectar problemas en el proceso de desarrollo o el producto  Criterios de decisión y Niveles de aceptación
  • 94 II. Métrica v3  Medidas de Calidad  Facilidad de uso  Integridad (seguro)  Corrección (hace lo que tiene que hacer)  Fiabilidad  Eficiencia  Facilidad de mantenimiento (corregible)  Facilidad de prueba  Flexibilidad (cambiable)  Reutilización  Interoperabilidad (comunicarse con otro sistema)  Portabilidad (usarse en otro sistema)
  • 95 II. Métrica v3  Gestión de Incidencias y Riesgos  Análisis continuo para reasignar recursos y establecer políticas de gestión contra amenazas  Estrategias  Impedir el riesgo  Transferir el riesgo  Mitigar el riesgo  Definir una plan de contingencia (B)
  • 96 Contenidos I. Metodologías de Desarrollo y Gestión de Proyectos Software II. Métrica v3 III. El Proceso Unificado IV. Administración de Requisitos mediante Casos de Uso
  • 98 III. El Proceso Unificado  RUP  Rational Unified Process  Marco de trabajo genérico basado en componentes  Utiliza UML como lenguaje de modelado  Centrado en la arquitectura  Dirigido por los Casos de Uso  Iterativo e Incremental  Estructura  Estática: personas, actividades, artefactos y flujos  Dinámica: ciclos, fases, iteraciones, hitos
  • 99 III. El Proceso Unificado  Recursos humanos y roles
  • 100 III. El Proceso Unificado  Estructura estática
  • 101 III. El Proceso Unificado  Estructura dinámica
  • 102 III. El Proceso Unificado  Dirigido por los casos de uso  Ajustarse a las necesidades reales del usuario
  • 103 III. El Proceso Unificado  Los casos de uso dirigen  La creación y validación de la arquitectura  La definición de los casos y métodos de prueba  La planificación de las iteraciones  La creación de documentación de usuario  La sincronización entre los distintos modelos
  • 104 III. El Proceso Unificado  Centrado en la arquitectura  Cada actor va a tener un punto de vista distinto  La arquitectura gestiona esos puntos de vista  Para controlar el desarrollo a través de su ciclo de vida  Entran en juego:  La organización del sistema  Los elementos estructurales y sus interfaces  La composición de estos en subsistemas  El comportamiento del sistema  Los casos de uso especifican la función  La arquitectura especifica la forma
  • 105 III. El Proceso Unificado  Centrado en la arquitectura  Pero, ¿qué se entiende por arquitectura?  Descripción de la estructura global del diseño de un sistema definida como un conjunto de componentes y conectores con ciertas restricciones semánticas  Clientes, servidores, bases de datos, filtros, etc.  La arquitectura debe cubrir, si se implementa, las necesidades de los usuarios del sistema  Diagramas de Componentes  Diagramas de Entidad/Interrelación
  • 106 III. El Proceso Unificado  Ciclo de vida Iterativo e Incremental  Inicio (Inception): genera unos objetivos  Elaboración: genera una arquitectura  Construcción: genera un producto inicial  Transición (Cierre): genera una nueva versión del SW
  • 107 III. El Proceso Unificado  Ciclo de vida Iterativo e Incremental
  • 108 III. El Proceso Unificado  Inicio  Establecer el ámbito y los límites del proyecto  Detectar los casos de uso críticos y sus escenarios principales (guía para el diseño)  Comprobar al menos una arquitectura candidata  Estimar coste y planificación temporal  Estimar riesgos potenciales  Evaluación:  ¿Las estimaciones son creíbles?  ¿Los usuarios están de acuerdo con el ámbito?  ¿El prototipo arquitectónico es consistente?
  • 109 III. El Proceso Unificado  Elaboración  Establecer la arquitectura rápidamente  Establecer un plan para la construcción  Demostrar que la arquitectura es adecuada  Evaluación:  ¿La arquitectura es estable?  ¿La disponibilidad de recursos es aceptable?  ¿Los usuarios están de acuerdo con las previsiones?
  • 110 III. El Proceso Unificado  Construcción  Minimizar los costes de desarrollo  Conseguir una calidad adecuada  Conseguir una versión utilizable  Evaluación:  ¿El producto está suficientemente maduro?  ¿El producto es suficientemente estable?  ¿La disponibilidad de recursos es aceptable?  ¿Estamos dispuestos para la entrega a usuario final?
  • 111 III. El Proceso Unificado  Transición  Conseguir la aceptación  Que el usuario sea capaz de mantener el producto  Conseguir un producto rápido, práctico y eficiente  Sincronizar e integrar los artefactos de construcción  Evaluación:  ¿El usuario está satisfecho?  ¿La utilización de recursos ha sido aceptable?
  • 112 III. El Proceso Unificado  Artefactos generados  Documento de visión  Casos de negocio  Plan de desarrollo  Modelo de requisitos  Modelo/s de diseño  Modelo de pruebas  Descripción de la arquitectura  Reglas de codificación  Manual de usuario  WBS  Descripción de una versión  …
  • 113 III. El Proceso Unificado  Artefactos generados  Entregas internas Inicio Elaboración Construcción Transición Iteración Iteración IteraciónIteración Entregas internas Requisitos Análisis y Diseño Codificación Pruebas Gestión de ProyectoGestión de configuración Disciplinas Alcance y Objetivos Arquitectura Beta Versión final
  • 114 III. El Proceso Unificado. Plan  El Plan de Proceso  ¿Cuántas iteraciones se necesitan?  ¿Cuánto debe durar cada una?  ¿Cómo determinamos qué se va a hacer en cada una?  ¿Cómo seguimos el progreso de una iteración?  Planificación  Esencial en proyectos grandes  Plan de fase a grandes rasgos  Planes de iteración más detallados  Plan de iteración actual  Plan de iteración siguiente
  • 115 III. El Proceso Unificado  Plan de fase  Se crea al principio de la fase de inicio  Actualizándose siempre que sea necesario  Los hitos principales son el final de cada fase  Incluye un perfil del personal requerido  Incluye hitos secundarios al final de cada iteración  ¿Cómo se elabora?  Partir del esfuerzo estimado  Y de las restricciones de tiempo de finalización  Planificar hacia atrás ponderando las fases inicio elaboración construcción transición %Tiempo 10% 30% 50% 10% %Esfuerzo 5% 20% 65% 10%
  • 116 III. El Proceso Unificado  Plan de fase  Si hace falta mucho tiempo para delimitar el proyecto, encontrar financiación, realizar un prototipo inicial,… alargar la fase de inicio  Si no se tiene una arquitectura, se utiliza una nueva tecnología, hay muchos riesgos o mucha gente nueva alargar la fase de elaboración  Si ya se ha construido un sistema similar con la misma arquitectura acortar las fases de inicio y elaboración  Si hay que llegar al mercado cuanto antes con algo funcional acortar las fases de construcción y transición  Si hay que reemplazar sistemas antiguos o la transición es complicada acortar la fase de transición
  • 117 III. El Proceso Unificado  Plan de iteración  Cada iteración es un microproyecto  Un plan por iteración  Se genera utilizando técnicas habituales  Es como una ventana que se desplaza por el de fase  ¿Cuánto dura?  5 personas pueden planificar en ventanas de semana  20 requieren ventanas de mes  40 tienen jerarquías y las ventanas serían trimestrales  Ideal: entre 2 y 6 semanas  ¿Cuántas iteraciones? inicio elaboración construcción transición 0-1 (prototipo) 1-3 (según riesgos) 1-3 1-2 (por detección de defectos)
  • 118 III. El Proceso Unificado  Flujo de trabajo de una iteración
  • 119 III. El Proceso Unificado  Construir un plan de iteración  Definir los criterios objetivos de éxito  Identificar los artefactos concretos a producir  Identificar las actividades y recursos necesarios  Crear un WBS y adecuarlo a las tareas a realizar  Asignar duración y esfuerzo a cada actividad según las estimaciones y el presupuesto de recursos  En la fase de elaboración es importante:  Detectar y eliminar riesgos cuanto antes  Asegurar que la arquitectura cubre todos los aspectos  Cumplir con la funcionalidad y servicios exigidos
  • 120 III. El Proceso Unificado  Gestión de Configuraciones
  • 121  9 claves para gestionar proyectos SW 1. Desarrollo de SW no es fabricación 2. Planificación y coste no son intercambiables 3. Los mejores datos para comparar son los tuyos 4. No perderse en detalles 5. Los cambios no son gratis 6. Planifica y monitoriza tu plan 7. Una estimación no es un plan 8. Hay más cosas que la programación 9. Planifica para medir III. El Proceso Unificado
  • 122 III. El Proceso Unificado  Ejercicio  Analizar
  • 123 III. El Proceso Unificado  Ejercicio  Actores: pac-man, ¿reloj?  Casos de uso: mover, comer, chocar con un fantasma, comerse un fantasma, perder vida, completar puzzle  Clases: pac-man, fantasma, tablero, punto, píldora  UUCP = 1x3 + 6x5 = 33  Arquitectura: cliente-servidor con un servidor de niveles nuevos (recomendado patrón Observador)  Riesgos: Cambios en los requisitos [alto]  Plan de mitigación: Iterar la fase de elaboración  Plan de Pruebas: Probar una partida sin muertes, con muertes, comer la píldora, chocar con paredes,…
  • 124 III. El Proceso Unificado. Diseño  Diseño  Se modela el sistema y se encuentra su forma para que soporte los requisitos  Objetivo: Adquirir una visión profunda de los requisitos no funcionales y las restricciones tecnológicas
  • 125 III. El Proceso Unificado  Diseño  Capturar las interfaces entre sistemas  Descomponer las tareas de implementación pequeñas que puedan llevar a cabo varios equipos  Implementación: refinamiento del diseño (=estructura)
  • 126 III. El Proceso Unificado  Resultados del Diseño  Modelo de Diseño  Conserva la estructura del modelo de análisis y sirve como esquema para la implementación  Subsistemas de diseño, clases de diseño y realización de los casos de uso  Modelo de Despliegue  Configuraciones de red sobre las que implantar el sistema
  • 127 III. El Proceso Unificado  Diseño de una clase  Esbozar la clase de diseño  Identificar operaciones  Identificar atributos  Identificar asociaciones y agregaciones  Identificar generalizaciones  Describir los métodos  Describir estados  Tratar requisitos especiales  Mantenimiento de la dependencia entre subsistemas  Mantenimiento de las interfaces de los subsistemas  Mantenimiento de los contenidos de los subsistemas
  • 128 III. El Proceso Unificado  Ejercicio  Diseñar
  • 129 III. El Proceso Unificado  Ejercicio  Pac-man: vidas, puntos, estado, mover, comer, morir  Fantasma: perseguir, huir  Tablero: casillas, paredes, pac-man, 4 fantasmas, completo, fruta  Casilla: vacía, hay píldora  Patrón observador  Modelo cliente-servidor para descargar mapa nuevos
  • 130 Contenidos I. Metodologías de Desarrollo y Gestión de Proyectos Software II. Métrica v3 III. El Proceso Unificado IV. Administración de Requisitos mediante Casos de Uso
  • 132 IV. Administración de Requisitos  Modelo de Requisitos  Objetivo: delimitar el sistema y capturar la funcionalidad que debe ofrecer  Puede funcionar como un contrato entre el desarrollador y el usuario  Proyecta lo que el cliente desea según la percepción del desarrollador  Es esencial que los clientes comprendan este modelo  Es el primer modelo a desarrollar y sirve de base para la creación de todos los demás modelos  Además, cualquier cambio es más fácil y tiene menos consecuencias a este nivel
  • 133 IV. Administración de Requisitos  Documentación SRS (Software Requirements Specification)  ¿Quién lo escribe?  El cliente/usuario  El analista/desarrollador del sistema  Deben reflejar la misma información  ¿Qué debe incluir?  Una descripción precisa y completa del comportamiento del software con su entorno  requisitos de comportamiento (funcionales)  Requisitos no de comportamiento (no funcionales)
  • 134 IV. Administración de Requisitos  Tipos de Requisitos  Estructurales  De comportamiento  Estáticos  Dinámicos  Funcionales  No funcionales
  • 135 IV. Administración de Requisitos  Ejemplos  Necesitamos un sistema de seguimiento de objetos en movimiento  Habrá un módulo que controle la posición de la plataforma, haciendo de interfaz con los motores  Los módulos deben tener una especificación pública y un cuerpo oculto  Se utilizarán Diagramas Entidad-Interrelación  Tendremos un radar de barrido con funciones de localización  Codificaremos en ADA  Existen 3 sistemas de radar comerciales de los que se puede comprar uno  La precisión espacial será de 10-3 rad  Para ello se utilizará el método de Horner de resolución de polinomios  Habrá una carga inicial de datos de límites de movimiento
  • 136 IV. Administración de Requisitos  Ejemplos (funcionales/no funcionales)  Necesitamos un sistema de seguimiento de objetos en movimiento  Habrá un módulo que controle la posición de la plataforma, haciendo de interfaz con los motores  Los módulos deben tener una especificación pública y un cuerpo oculto  Se utilizarán Diagramas Entidad-Interrelación (planificación)  Tendremos un radar de barrido con funciones de localización  Codificaremos en ADA (planificación)  Existen 3 sistemas de radar comerciales de los que se puede comprar uno (planificación)  La precisión espacial será de 10-3 rad  Para ello se utilizará el método de Horner de resolución de polinomios  Habrá una carga inicial de datos de límites de movimiento
  • 137 IV. Administración de Requisitos  Caso de uso  Representan la funcionalidad del sistema  Describen una forma en que un “actor” (usuario) interactúa con la aplicación  Los Actores pueden ser usuarios, administradores, organizaciones, otros sistemas, etc.  Escenario  Combinación específica de condiciones en un caso de uso que hacen que se comporte de manera concreta  El escenario normal asume que todo va bien  Pero, ¿Y si…? Escenarios alternativos
  • 138 IV. Administración de Requisitos  Actores  Representan los distintos roles que los elementos del entorno desempeñan respecto al sistema  Un actor representa a todos los elementos con el mismo rol  Un mismo elemento puede desempeñar varios roles  Usuario administrador  Usuario normal  Un actor representa un ente/objeto y tendrá que aparecer en el diagrama de clases
  • 139 IV. Administración de Requisitos  Relaciones 1. Comunicación
  • 140 IV. Administración de Requisitos  Relaciones 2. Inclusión
  • 141 IV. Administración de Requisitos  Relaciones 3. Extensión
  • 142 IV. Administración de Requisitos  Relaciones 4. Herencia
  • 143 IV. Administración de Requisitos  Construcción de Casos de Uso  Un caso de uso debe ser simple, claro y conciso  Suele haber pocos actores asociados a cada Caso de Uso  Preguntas clave:  ¿cuáles son las tareas del actor?  ¿qué información crea, guarda, modifica, destruye o lee el actor?  ¿debe el actor notificar al sistema los cambios externos?  ¿debe el sistema informar al actor de los cambios internos?  ¿cuál es el escenario normal de esta interacción?
  • 144 IV. Administración de Requisitos  Notas para la construcción de Casos de Uso  No buscar la perfección  Identificar primero a los actores  Identificar los casos de uso esenciales  Utilizar estrategias de herencia entre actores  Inventariar los casos de uso  Describir el flujo básico del caso de uso  Describir los posibles flujos alternativos  Documentar los casos de uso “efectivos”  Crear diagramas de casos de uso  Describir posibles historias de usuario
  • 145 IV. Administración de Requisitos  Descripción de Casos de Uso 1. Identificador 2. Nombre 3. Descripción 4. Precondición 5. Escenario normal 6. Postcondición 7. Escenarios de excepción 8. Rendimiento 9. Frecuencia esperada 10. Importancia, urgencia y comentarios
  • 146 Identificador CU-<id-requisito> Nombre <nombre del requisito funcional> Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso { concreto cuando <evento de activación> , abstracto durante la realización de los casos de uso <lista de casos de uso>} Precondición <precondición del caso de uso> Secuencia Normal Paso Acción 1 {El <actor> , El sistema} <acción realizada por el actor o sistema>, se realiza el caso de uso < caso de uso CU-x> 2 Si <condición>, {el <actor> , el sistema} <acción realizada por el actor o sistema>>, se realiza < caso de uso CU-x> … … Postcondición <postcondición del caso de uso> Excepciones Paso Acción 1 Si <condición de excepción>,{el <actor> , el sistema} }<acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso CU-x>, a continuación este caso de uso {continua, aborta} … … Rendimiento Paso Cota de tiempo 1 n segundos … … Frecuencia esperada <nº de veces> veces / <unidad de tiempo> Importancia {sin importancia, importante, vital} Urgencia {puede esperar, hay presión, inmediatamente} Comentarios <comentarios adicionales> IV. Administración de Requisitos 1 2 3 4 5 6 7 8 9 10
  • 147 IV. Administración de Requisitos
  • 148 IV. Administración de Requisitos
  • 149 IV. Administración de Requisitos  Stakeholders  Personas interesadas o involucradas en el proyecto de manera indirecta (x ej. administrador de BD)  Es importante tenerles en cuenta para mejorar la calidad de nuestros casos de uso  Y para evitar que nos pongan trabas en el proyecto  Los stakeholders tienen intereses a considerar  Logs, información generada, validaciones,…  Garantías que debe aportar el sistema  Efecto de un caso de uso que termina con éxito
  • 150 IV. Administración de Requisitos  Relación con otros Modelos de UML  Modelo de Análisis  Modelo de Interacción  Diagramas de secuencia y comunicación  Modelo de Diseño  Diagramas de clases y objetos  Diagramas de estados y actividades  Modelo de Implementación  Diagrama de componentes  Modelo de Despliegue  Diagrama de despliegue (nodos)
  • 151 IV. Administración de Requisitos  Relación con el modelo de interacción  Los diagramas de secuencia y comunicación permiten describir gráficamente cada caso de uso  A su vez, el diagrama de comunicación sirve de base para crear el diagrama de clases  Relación con el modelo de diseño  Los casos de uso detectan los elementos que van a interactuar en el sistema  Estos elementos van a ser en muchos casos clases  Además, un caso de uso se puede convertir en una función contenida en una clase
  • 152 IV. Administración de Requisitos
  • 153 IV. Administración de Requisitos  Relación con el modelo de implementación  El modelo de implementación representa la arquitectura del sistema  Esta arquitectura tiene que soportar todos los casos de uso existentes, deben poder realizarse  Relación con el modelo de despliegue  Los casos de uso representan requisitos funcionales  El modelo de despliegue representa otros requisitos no funcionales como por ejemplo de HW o comunicación
  • 154 IV. Administración de Requisitos  Y ¿Cómo conecto los diagramas?  Realización: Relación entre al que hay que hacer y el responsable de hacerlo
  • 155 IV. Administración de Requisitos  Modelo de diseño  Jerarquía de subsistemas que contienen clases de diseño, realizaciones de casos de uso e interfaces  Incluye requisitos no funcionales  Contempla restricciones de la tecnología  Prepara el paso a construcción
  • 156 IV. Administración de Requisitos  Diseño y Proceso Unificado
  • 157 IV. Administración de Requisitos  Diseño de un Caso de Uso  Identificación de las clases de diseño participantes  Descripción de las interacciones entre objetos  Identificación de subsistemas e interfaces participantes  Descripción de interacciones entre subsistemas  Captura de requisitos de implementación  Diseño de la Arquitectura  Identificación de nodos y configuraciones de red  Identificación de subsistemas y de sus interfaces  Identificación de clases de diseño relevantes  Identificación de mecanismos genéricos de diseño
  • 158 IV. Administración de Requisitos  ¿Y los cambios?  Se debe evaluar el impacto antes de acometerlo  Esto supondrá añadir/quitar casos de uso  Menos crítico  O modificar alguno existente  ¿Cómo propago los cambios?  La trazabilidad me permite saber QUÉ TENGO QUE CAMBIAR  La gestión de configuraciones me permite NO PERDER las versiones previas al cambio  Estrategia de compromiso: usar mecanismos de UML como la herencia o la extensión
  • 159 IV. Administración de Requisitos  Situaciones especiales  Casos de Uso CRUD  Son operaciones sencillas  Si los ejecuta el mismo actor se pueden agrupar  Caso de uso “gestionar…”  Casos de Uso parametrizados  Muchos casos de uso pueden tener el mismo objetivo con distintos parámetros  Listar productos, listar pedidos, listar clientes  Crear un caso de uso genérico “listar”