Métrica v3 y RUP

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
Proyectos Software
II. Métrica v3
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
 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
 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
Proyectos Software
II. Métrica v3
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

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

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

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

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
 EVS-SEG
 ASI-SEG

50
II. Métrica v3
 DSI-SEG
 CSI-SEG

51
II. Métrica v3
 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
 …

56
II. Métrica v3
 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
 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
 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

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
Proyectos Software
II. Métrica v3
Casos de Uso

98
 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
 Recursos humanos y roles

100
 Estructura estática

101
 Estructura dinámica

102
 Dirigido por los casos de uso
 Ajustarse a las necesidades reales del usuario

103
 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
 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
 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
 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
 Ciclo de vida Iterativo e Incremental

108
 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
 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
 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
 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
 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
 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
 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
 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
 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
 Flujo de trabajo de una iteración

119
 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
 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

122
 Ejercicio
 Analizar

123
 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
 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
 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
 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
 Ejercicio
 Diseñar

129
 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
Proyectos Software
II. Métrica v3
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
 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
 Tipos de Requisitos
 Estructurales
 De comportamiento
 Estáticos
 Dinámicos
 Funcionales
 No funcionales

135
 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
 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
 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
 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
 Relaciones
1. Comunicación

140
 Relaciones
2. Inclusión

141
 Relaciones
3. Extensión

142
 Relaciones
4. Herencia

143
 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
 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
 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>
1
2
3
4
5
6
7
8
9
10

147

148

149
 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
 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
 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

153
 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
 Y ¿Cómo conecto los diagramas?
 Realización: Relación entre al que hay que hacer y el
responsable de hacerlo

155
 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
 Diseño y Proceso Unificado

157
 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
 ¿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
 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”

Métrica v3 y RUP

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Métrica v3 y RUP

Similar a Métrica v3 y RUP (20)

Más de Oliver Centeno

Más de Oliver Centeno (20)

Último

Último (20)

Métrica v3 y RUP