Métrica v3 y RUP

6,373
-1

Published on

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

Published in: Business
0 Comments
10 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
6,373
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
10
Embeds 0
No embeds

No notes for slide

Métrica v3 y RUP

  1. 1. Metodologías de Gestión de Proyectos I: Métrica v3 y Proceso Unificado Óliver Centeno Álvarez [ocenteno@pronoide.es]
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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)
  11. 11. 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
  12. 12. 15 II. Métrica v3
  13. 13. 16 II. Métrica v3  Un ejemplo
  14. 14. 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
  15. 15. 18 II. Métrica v3  Un ejemplo ASI EVS DSI
  16. 16. 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)
  17. 17. 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
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. 25 II. Métrica v3  ASI
  23. 23. 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
  24. 24. 27 II. Métrica v3  DSI
  25. 25. 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
  26. 26. 29 II. Métrica v3  CSI
  27. 27. 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)
  28. 28. 31 II. Métrica v3  IAS  Entrega y aceptación del sistema  Actividades necesarias para el paso a producción
  29. 29. 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
  30. 30. 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
  31. 31. 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
  32. 32. 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
  33. 33. 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]
  34. 34. 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
  35. 35. 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)
  36. 36. 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
  37. 37. 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
  38. 38. 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
  39. 39. 49 II. Métrica v3  Interfaz de Seguridad  EVS-SEG  ASI-SEG
  40. 40. 50 II. Métrica v3  Interfaz de Seguridad  DSI-SEG  CSI-SEG
  41. 41. 51 II. Métrica v3  Interfaz de Seguridad  IAS-SEG  MSI-SEG
  42. 42. 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
  43. 43. 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
  44. 44. 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  …
  45. 45. 55 II. Métrica v3
  46. 46. 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
  47. 47. 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
  48. 48. 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)
  49. 49. 59 II. Métrica v3  Casos de Uso
  50. 50. 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
  51. 51. 61 II. Métrica v3  Diagrama de Clases
  52. 52. 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
  53. 53. 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
  54. 54. 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
  55. 55. 65 II. Métrica v3  Diagrama de Descomposición  Representa la estructura jerárquica de un dominio
  56. 56. 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
  57. 57. 67 II. Métrica v3  Diagramas de Interacción
  58. 58. 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
  59. 59. 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
  60. 60. 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
  61. 61. 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
  62. 62. 72 II. Métrica v3  Modelo Entidad/Interrelación
  63. 63. 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
  64. 64. 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
  65. 65. 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
  66. 66. 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,…
  67. 67. 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
  68. 68. 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
  69. 69. 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
  70. 70. 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)
  71. 71. 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
  72. 72. 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
  73. 73. 83 II. Métrica v3  Puntos de Caso de Uso  Peso de los actores  Peso de los casos de uso
  74. 74. 84 II. Métrica v3  Puntos de Caso de Uso Ajustados (UCP)  Complejidad (TCF) y factores ambientales (EF)
  75. 75. 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)
  76. 76. 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
  77. 77. 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
  78. 78. 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
  79. 79. 89 II. Métrica v3  Diagrama de Gantt
  80. 80. 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
  81. 81. 91 II. Métrica v3  Ejemplo PERT
  82. 82. 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
  83. 83. 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
  84. 84. 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)
  85. 85. 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)
  86. 86. 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
  87. 87. 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
  88. 88. 99 III. El Proceso Unificado  Recursos humanos y roles
  89. 89. 100 III. El Proceso Unificado  Estructura estática
  90. 90. 101 III. El Proceso Unificado  Estructura dinámica
  91. 91. 102 III. El Proceso Unificado  Dirigido por los casos de uso  Ajustarse a las necesidades reales del usuario
  92. 92. 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
  93. 93. 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
  94. 94. 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
  95. 95. 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
  96. 96. 107 III. El Proceso Unificado  Ciclo de vida Iterativo e Incremental
  97. 97. 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?
  98. 98. 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?
  99. 99. 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?
  100. 100. 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?
  101. 101. 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  …
  102. 102. 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
  103. 103. 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
  104. 104. 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%
  105. 105. 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
  106. 106. 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)
  107. 107. 118 III. El Proceso Unificado  Flujo de trabajo de una iteración
  108. 108. 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
  109. 109. 120 III. El Proceso Unificado  Gestión de Configuraciones
  110. 110. 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
  111. 111. 122 III. El Proceso Unificado  Ejercicio  Analizar
  112. 112. 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,…
  113. 113. 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
  114. 114. 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)
  115. 115. 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
  116. 116. 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
  117. 117. 128 III. El Proceso Unificado  Ejercicio  Diseñar
  118. 118. 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
  119. 119. 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
  120. 120. 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
  121. 121. 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)
  122. 122. 134 IV. Administración de Requisitos  Tipos de Requisitos  Estructurales  De comportamiento  Estáticos  Dinámicos  Funcionales  No funcionales
  123. 123. 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
  124. 124. 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
  125. 125. 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
  126. 126. 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
  127. 127. 139 IV. Administración de Requisitos  Relaciones 1. Comunicación
  128. 128. 140 IV. Administración de Requisitos  Relaciones 2. Inclusión
  129. 129. 141 IV. Administración de Requisitos  Relaciones 3. Extensión
  130. 130. 142 IV. Administración de Requisitos  Relaciones 4. Herencia
  131. 131. 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?
  132. 132. 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
  133. 133. 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
  134. 134. 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
  135. 135. 147 IV. Administración de Requisitos
  136. 136. 148 IV. Administración de Requisitos
  137. 137. 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
  138. 138. 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)
  139. 139. 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
  140. 140. 152 IV. Administración de Requisitos
  141. 141. 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
  142. 142. 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
  143. 143. 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
  144. 144. 156 IV. Administración de Requisitos  Diseño y Proceso Unificado
  145. 145. 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
  146. 146. 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
  147. 147. 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”

×