ingenieria

1. Introducción a Métrica v3
Javier Gutiérrez / javierj@us.es

2. Introducción a Métrica 3
Objetivos:
{Saber qué es Métrica v3 y qué elementos la
componen.
{Practicar con la documentación de Métrica

3. Introducción a Métrica 3
Índice:
1. Presentación de Métrica.
2. Un ejemplo de Métrica.
3. Un segundo ejemplo de Métrica.
4. Procesos.
5. Interfaces.
6. Técnicas / prácticas.
7. Participantes.
8. Actividades.
9. Introducción a UML.

4. Introducción a Métrica v3
Presentación de Métrica

5. Presentación de Métrica
z ¿Qué es Métrica?.
z ¿Para qué sirve Métrica?.
z ¿De qué está compuesta Métrica?.
www..maapp..eess//meettrriiccaavv33//

6. Presentación de Métrica
Web: www.sevinge.es e-mail: info@sevinge.es
Telf.: 954 091 086 – FAX: 954 460 306
Pabellón de Italia. C/ Isaac Newton s/n. Planta 4ª
Isla de la Cartuja. 41092 Sevilla
¿Qué es Métrica?
9 Una TERMINOLOGÍA común.
9 Un ‘MÉTODO DE HACER’ común.
9 Unas TÉCNICAS extendidas que permiten la comunicación.
9 Unos RESULTADOS o productos con un índice común.
9 Unos ‘Planos Básicos’ REVISABLES POR TODOS los implicados.
9 La posibilidad de establecer actuaciones en el área de GARANTÍA
DE CALIDAD al tener un marco de referencia.
9 INDEPENDENCIA de las metodologías propias de las empresas
consultoras.

7. Presentación de Métrica
¿Qué no es métrica?
{¿Es un ciclo de vida en cascada?.
{¿Es una metodología que hay que aplicar tal
cuál?.
{¿Sirve para gestionar proyectos?.
{¿Si usamos Métrica no podemos usar, por
ejemplo, RUP?.

8. Presentación de Métrica
Principales diferencias entre Métrica 2.1 y Métrica 3.
¿CCuuááll eess ccuuááll??

9. Presentación de Métrica
Principales diferencias entre Métrica 2.1 y Métrica 3.
z División en procesos.
z Descripción de las tareas de manera
sistemática.
z Incorporación de nuevos estándares (como
UML).
z Soporte para desarrollos orientados a objetos.
z Interfaces (tareas comunes a todos los
procesos).
z Una nueva PSI.
z Ahora sí hay mantenimiento.

10. Introducción a Métrica v3
Un ejemplo de Métrica.

11. Un ejemplo de Métrica

12. Un ejemplo de Métrica
La consejería de turismo convoca un
concurso público para la realización de un
PSI….
… y lo ganamos.
¿Qué hacemos?

13. Un ejemplo de Métrica
¿Quuéé hhaacceemooss aahhoorraa??

14. Un ejemplo de Métrica
¿Quuéé hhaacceemooss aahhoorraa??

15. Un ejemplo de Métrica
¿Quuéé hhaacceemooss aahhoorraa??

16. Un ejemplo de Métrica
¿Quuéé hhaacceemooss aahhoorraa??

17. Un ejemplo de Métrica
¿Quuéé hhaacceemooss aahhoorraa??

18. Un ejemplo de Métrica
¿Quuéé hhaacceemooss aahhoorraa??

19. Un ejemplo de Métrica
Fiinn

20. Introducción a Métrica v3
Un segundo ejemplo de Métrica.

21. Un segundo ejemplo de Métrica
Cliente.
Sokoban

22. Un segundo ejemplo de Métrica
z ¿Un juego de escritorio? ¿En
Internet? ¿Para móviles? ¿Para
PDAs? ¿Para televisión
interactiva?.
z (Juego Internet) ¿Cliente rico?.
¿HTML estándar?.
z (Juego Móvil) ¿Java?. ¿Smbian?
z ¿Requisitos de accesibilidad para
personas con minusvalías?
EVS.

23. Un segundo ejemplo de Métrica
EVS.
Modelo de
dominio.
Jugador
estáEn
1
1
formaParteDe
1..* 1 1 0..*
mover
*
Muro Caja
0..1
Repisa
Nivel
0..*
1
Colocada
0..1
0..1
Existe el mismo número
de cajas que de repisas.

24. Un segundo ejemplo de Métrica
Usuario
Iniciar partida
Mover jugador
Reiniciar nivel
ASI.
Nombre 01- Iniciar partida
Descripción El usuario desea iniciar una nueva partida de Sokoban.
Precondición Ninguna
Secuencia
principal
Errores / No
Alternativas
01 El usuario solicita comenzar una nueva partida.
02 El sistema carga el nivel inicial.
Postcondición Partida iniciada
Notas No
El sistema muestra la pantalla de juego y espera a que
el usuario realice un movimiento (Caso de uso 02).
03
Modelo de
requisitos.

25. Un segundo ejemplo de Métrica
ASI.
Modelo de
análisis.

26. Un segundo ejemplo de Métrica
ASI.
Modelo de
análisis (más
detallado).

27. Un segundo ejemplo de Métrica
class Class Model
ón de prueba no Registrada EA 6.5 versión de prueba no
Niv el
ón de jav a.swing.prueba no JFrame
Registrada EA - 6.5 graficos: versión java.de swing.image
prueba no
- mapa[][]: int
ón de prueba no Registrada EA 6.5 versión de prueba no
ón de prueba no Registrada EA 6.5 versión de prueba no
ón de prueba Pantalla
no Registrada EA 6.5 versión Partida
de prueba no
+ dibujarNivel() : void
+ finDeNivel() : void
+ moverJugador(int) : void
ón + de main() : prueba void
no Registrada EA + 6.5 versión nuevoNivel() : de void
prueba no
+ show() : void
ón de prueba no Registrada EA 6.5 versión de prueba no
DSI.
¿QQuuéé vveennddrrííaa aa ccoonnttiinnuuaacciióónn??
Modelo de diseño.

28. Introducción a Métrica v3
Procesos.

29. Procesos de Métrica 3
?
PPllaanniiffiiccaacciióónn ddee ssiisstteemaass ddee iinnffoorrmaacciióónn
Definición de la arquitectura
tecnológica
DDeeffiinniicciióónn ddeell ppllaann ddee aacccciióónn
Diseño del modelo de
sistema de información
IIddeennttiiffiiccaacciióónn ddee rreeqquuiissiittooss
Estudio de la información
relevante
1
2
3
4
5

30. Procesos de Métrica 3
z PLANIFICACION DE SISTEMAS DE INFORMACION (PSI)
{OBJETIVO: obtener un marco de referencia para el desarrollo
de S.I. que responda a los objetivos estratégicos de la
organización.
5 4 3 1 2

31. Procesos de Métrica 3
?
EEssttuuddiioo ddee vviiaabbiilliiddaadd ddeell ssiisstteemaa
Estudio de alternativas de
solución
Definición de requisitos del
sistema
EEssttuuddiioo ddee llaa ssiittuuaacciióónn aaccttuuaall
Establecimiento del alcance
del sistema
SSeelleecccciióónn ddee llaa ssoolluucciióónn
1
2
3
4
5

32. Procesos de Métrica 3
z ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS)
{OBJETIVO: analiza un conjunto concreto de necesidades, y
propone una solución a corto plazo, considerando criterios
económicos, técnicos , legales y operativos.
4 3 2 1 5

33. Procesos de Métrica 3
AAnnáálliissiiss ddeell ssiisstteemaa ddee iinnffoorrmaacciióónn..
? AAnnáálliissiiss ddee ccaassooss ddee uussoo
DDeeffiinniicciióónn ddeell ssiisstteemaa
Especificación del plan de
pruebas
Definición de interfaces de
usuario
AAnnáálliissiiss ddee ccllaasseess
1
2
3
4
5

34. Procesos de Métrica 3
2 1 5 4 3

35. Procesos de Métrica 3
DDiisseeññoo ddeell ssiisstteemaa ddee iinnffoorrmaacciióónn..
Definición de la arquitectura
? del sistema
DDiisseeññoo ffííssiiccoo ddee ddaattooss
Especificación técnica del
plan de pruebas
Diseño de migración y carga
inicial de datos.
DDiisseeññoo ddee ccllaasseess
1
2
3
4
5

36. Procesos de Métrica 3
1 5 2 4 3

37. Procesos de Métrica 3
?
CCoonnssttrruucccciióónn ddeell ssiisstteemaa ddee iinnffoorrmaacciióónn
Generación del código de
componentes y
procedimientos.
PPrruueebbaass ddeell ssiisstteemaa
PPrruueebbaass ddee iinntteeggrraacciióónn
Elaboración de manuales de
usuario
Construcción de
componentes de migración y
carga inicial de datos.
1
2
3
4
5

38. Procesos de Métrica 3
1 4 5 3 2

39. Procesos de Métrica 3
IImppllaannttaacciióónn yy aacceeppttaacciióónn ddeell ssiisstteemaa
Carga de datos al entorno de
operación
? Formación necesaria para la
implantación.
Pruebas de aceptación del
sistema
PPaassoo aa pprroodduucccciióónn..
Preparación del
mantenimiento.
1
2
3
4
5

40. Procesos de Métrica 3
2 1 5 3 4

41. Procesos de Métrica 3
Maanntteenniimiieennttoo ddee ssiisstteemaass ddee iinnffoorrmaacciióónn..
AAnnáálliissiiss ddee llaa ppeettiicciióónn
? Implementación de la
modificación.
Seguimiento y evaluación de
los cambios hasta la
aceptación
RReeggiissttrroo ddee llaa ppeettiicciióónn..
Preparación de la
implementación de la
modificación.
1
2
3
4
5

42. Procesos de Métrica 3
4 1 5 3 2

43. Procesos en Métrica 3
Ejercicio:
1. Agruparnos por equipos.
2. Elegir un proceso (secreto).
3. Seleccionar un conjunto de tareas.
4. Las exponemos y las ordenamos.
5. Las agrupamos en sus actividades.
6. Veamos un ejemplo…

44. Procesos de Métrica 3
Maanntteenniimiieennttoo ddee ssiisstteemaass ddee iinnffoorrmaacciióónn ((TTaarreeaass))
AAssiiggnnaacciióónn ddee llaa ppeettiicciióónn
? RReeggiissttrroo ddee llaa ppeettiicciióónn..
Especificación del plan de
pruebas de regresión
SSeegguuiimiieennttoo ddee llooss ccaambbiiooss..
Identificación de elementos
aceptados.
1
2
3
4
5

45. Procesos de Métrica 3
2 1 5 3 4

46. Procesos en Métrica 3
Ejercicio:
z Tenemos la siguiente documentación:
1. Un diagrama de casos de uso.
2. Un diagrama de clases con clases DAO y Facade.
3. Un diagrama Entidad / Relación.
4. Un script de Oracle para migrar datos de una versión a
otra.
5. Un organigrama de la división en secretarías de una
consejería.
6. El coste de una máquina y el software servidores de
aplicaciones.
7. Un dibujo de una pantalla del sistema.
8. Los resultados de una prueba de seguridad.
9. Un diagrama de interacción entre clases boundary,
entity y control.
10. La ley de protección de datos personales que nuestro
sistema tiene que cumplir.
PSI
EVS
ASI
DSI
CSI
IAS
MSI
¿AAllggoo mááss??
OOrrddeennaarrlloo

47. Procesos en Métrica 3
Un posible orden (no es el único):
1. Un diagrama Entidad / Relación (PSI).
2. Un organigrama de la división en secretarias de una
consejería (PSI).
3. El coste de una máquina y el software servidores de
aplicaciones (EVS).
4. La ley de protección de datos personales que nuestro
sistema tiene que cumplir (EVS).
5. Un dibujo de una pantalla del sistema (ASI).
6. Un diagrama de interacción entre clases boundary, entity y
control (ASI).
7. Un diagrama de casos de uso (ASI).
8. Un diagrama de clases con clases DAO y Facade (DSI).
9. Un script de Oracle para migrar datos de una versión a otra
(CSI).
10. Los resultados de una prueba de seguridad (IAS).

48. Introducción a Métrica v3
Interfaces.

49. Interfaces
Métrica 3 incluye un conjunto de procesos
que definen una serie de actividades de
interfaz con otros procesos organizativos
o de soporte.
¿CCuuáálleess ssoonn ssuuss oobbjjeettiivvooss??
{Gestión de proyectos.
{Seguridad.
{Gestión de configuración.
{Aseguramiento de la calidad.
11 mmiinn..

50. Interfaces
GGeessttiióónn ddee pprrooyyeeccttooss
La Gestión de Proyectos tiene como finalidad principal la planificación, el
seguimiento y control de las actividades y de los recursos humanos y
materiales que intervienen en el desarrollo de un Sistema de Información.
Como consecuencia de este control es posible conocer en todo momento
qué problemas se producen y resolverlos o paliarlos de manera
inmediata

51. Interfaces
GGeessttiióónn ddee sseegguurriiddaadd
El objetivo de la interfaz de
seguridad es incorporar en
los sistemas de información
mecanismos de seguridad
adicionales a los que se
proponen en la propia
metodología, asegurando el
desarrollo de cualquier tipo de
sistema a lo
largo de los procesos que se
realicen para su obtención.

52. Interfaces
GGeessttiióónn ddee ccoonnffiigguurraacciióónn
El objetivo es mantener la integridad de los productos que se obtienen a lo
largo del desarrollo de los sistemas de información, garantizando que no se
realizan cambios incontrolados y que todos los participantes en el desarrollo del
sistema disponen de la versión adecuada de los productos que manejan.

53. Interfaces
Aseguramiento de la
calidad
El objetivo es
proporcionar un marco
común de referencia
para la definición y
puesta en marcha de
planes específicos de
aseguramiento de
calidad aplicables a
proyectos concretos.

54. Interfaces
GGeessttoorr ddee eevveennttooss
El gestor de eventos permite que usuarios registrados den de alta un evento
(descripción, fecha, hora) y que cualquiera que se conecte pueda buscar
eventos (eventos más recientes, eventos pasados, por descripción, etc.)
1. Catálogo de casos de
uso.
2. Diagramas de
actividades.
3. Interfaces del
sistema.
4. Aprobación de los
casos de uso por los
usuarios.
1. Arquitectura en capas
del sistema.
2. Diagramas de clases
con la UI en JSP.
3. Diagrama de clases
de las capas con
JavaBeans y Servlets.
4. Esquema de la BBDD
para Oracle.
1. Código de los JSPs
Bean y Servlets.
2. Informes de pruebas.
3. Manual de usuario.
¿Qué pasará con cada
interfaz?

55. Interfaces
GGeessttiióónn ddee ccoonnffiigguurraacciióónn
1. Catálogo de casos de
uso.
2. Diagramas de
actividades.
3. Interfaces del
sistema.
4. Aprobación de los
casos de uso por los
usuarios.
Registrar nombre, versión,
estado y localización.
Registrar nombre, versión,
estado y localización.

56. Interfaces
IInntteerrffaazz ddee sseegguurriiddaadd::
z Análisis:
zSe estudia la seguridad necesaria para el desarrollo
del análisis.
zSe identifican requisitos adicionales de seguridad y
pruebas de seguridad.
1. Catálogo de casos de uso.
2. Diagramas de actividades.
3. Interfaces del sistema.
4. Aprobación de los casos de
uso por los usuarios.
5. Seguridad requerida en el
proceso de análisis.
6. Funciones y mecanismos de
seguridad.
Catalogación segura de los
resultados

57. Interfaces
IInntteerrffaazz ddee sseegguurriiddaadd::
z Diseño:
zSe estudia la seguridad necesaria para el desarrollo
del diseño.
zSe diseñan las funciones de seguridad que
controlarán, minimizarán o eliminarán los riesgos
intrínsecos del sistema y las pruebas de seguridad.
1. Arquitectura en capas del sistema.
2. Diagramas de clases con la UI en JSP.
3. Diagrama de clases de las capas con JavaBeans
y Servlets.
4. Esquema de la BBDD para Oracle.
5. Seguridad requerida en el proceso de diseño.
6. Requisitos de seguridad del entorno tecnológico.
7. Requisitos de seguridad del entorno de
construcción.
Catalogación segura de los
resultados

58. Interfaces
IInntteerrffaazz ddee sseegguurriiddaadd::
z Construcción:
zSe realizan controles de seguridad que eviten
filtraciones de datos del sistema de información.
zPlan de formación en seguridad para usuarios finales.
zSe evalúan los resultados de las pruebas de seguridad.
1. Código de los JSPs Bean y
Servlets.
2. Informes de pruebas.
3. Manual de usuario.
4. Seguridad requerida en el proceso
de construcción.
5. Informes de pruebas de seguridad.
6. Plan de formación de seguridad.
Catalogación segura de los
resultados

59. Interfaces
IInntteerrffaazz ddee ggeessttiióónn ddee pprrooyyeeccttooss::
A nuestro ejemplo le afectan las actividades de inicio (GPI) y
las de seguimiento y control (GPS)

60. Interfaces
IInntteerrffaazz ddee ggeessttiióónn ddee pprrooyyeeccttooss::
z Actividades de inicio:
zSe estima el esfuerzo de desarrollo del proyecto.
zSe planifica el desarrollo del proceso.
1. Definición general del proyecto.
2. Planificación general del proyecto.

61. Interfaces
IInntteerrffaazz ddee ggeessttiióónn ddee pprrooyyeeccttooss::
z Actividades de seguimiento y control:
zSe vigila el estado de las tareas que se desarrollan.
zSe corrigen las desviaciones que surjan.
RReessuullttaaddooss ddeell ddeessaarrrroolllloo..
1. Catálogo de casos de uso.
2. Diagramas de actividades.
3. Interfaces del sistema.
4. Aprobación de los casos de
uso por los usuarios.
5. Plan de aseguramiento de la
calidad.
RReessuullttaaddooss ddee llaa ggeessttiióónn..
1. Ficha de asignación de tareas.
2. Ficha de seguimiento de
tareas.
3. Ficha de incidencia.
4. Registro de incidencias.
5. Registro de cambios en los
requisitos.
PPaarraa eell rreessttoo ddee llooss pprroocceessooss sseerráá iigguuaall..

62. Interfaces
IInntteerrffaazz ddee ccaalliiddaadd::
z Análisis:
zSe define de forma detallada el plan de aseguramiento
de calidad para un sistema de información.
zSe revisan: catálogo de requisitos, modelos resultantes
del análisis y plan de pruebas.
1. Catálogo de casos de uso.
2. Diagramas de actividades.
3. Interfaces del sistema.
4. Aprobación de los casos de
uso por los usuarios.
5. Plan de aseguramiento de la
calidad.
Revisión por parte del equipo
de calidad.
Dossier de aseguramiento de la
calidad.

63. Interfaces
IInntteerrffaazz ddee ccaalliiddaadd::
z Diseño:
zSe verifica la correcta traducción de los requisitos a la
arquitectura del sistema.
zTambién se revisan: requisitos de prueba, requisitos de
documentación e implantación.
Revisión por parte del equipo
de calidad.
1. Arquitectura en capas del
sistema.
2. Diagramas de clases con la
UI en JSP.
3. Diagrama de clases de las
capas con JavaBeans y
Servlets.
4. Esquema de la BBDD para
Oracle.
Dossier de aseguramiento de la
calidad.

64. Interfaces
IInntteerrffaazz ddee ccaalliiddaadd::
z Construcción:
zSe verifican los estándares de nomenclatura y
normativa del código, de los resultados de las pruebas,
del manual de usuario, y dele squema de formación
Revisión por parte del equipo
de calidad.
Dossier de aseguramiento de la
calidad.
1. Código de los JSPs Bean y
Servlets.
2. Informes de pruebas.
3. Manual de usuario.

65. Introducción a Métrica v3
Técnicas / prácticas.

66. Técnicas / prácticas
Métrica me dice qué tengo que hacer
(procesos)….
… y también me dice cómo hacerlo
(técnicas / prácticas).

67. Técnicas / prácticas
PPrruueebbaass ddee aacceeppttaacciióónn
CCaattaallooggaacciióónn
PPrruueebbaass ddee rreeggrreessiióónn
CCaassooss ddee uussoo
PPrruueebbaass ddeell ssiisstteemaa
DDiiaaggrraamaass ddee ccllaasseess
AAnnáálliissiiss ddee iimppaaccttoo
Mooddeelloo EE//RR eexxtteennddiiddoo..
DDiiaaggrraamaa ddee ddeesspplliieegguuee
Reglas de obtención del modelo
físico a partir del modelo lógico
IIAASS
AASSII DDSSII MSSII
MSSII
AASSII DDSSII
CCSSII
AASSII DDSSII
MSSII
AASSII
DDSSII
DDSSII
PPSSII,, EEVVSS
EEVVSS
PPSSII,, EEVVSS
PPSSII,, EEVVSS

68. Técnicas / prácticas
AASSII::

69. Técnicas / prácticas
DDSSII::

70. Técnicas / prácticas
IIAASS::

71. Técnicas / prácticas
MMSSII::

72. Técnicas / prácticas
¿Todas las tareas tienen alguna técnica / práctica?
DDSSII 99.. DDiisseeññoo ddee llaa miiggrraacciióónn yy ccaarrggaa iinniicciiaall ddee ddaattooss..
1100.. EEssppeecciiffiiccaacciióónn ttééccnniiccaa ddeell ppllaann ddee pprruueebbaass..
CCSSII 11.. PPrreeppaarraacciióónn ddeell eennttoorrnnoo ddee ggeenneerraacciióónn yy ccoonnssttrruucccciióónn..
22.. GGeenneerraacciióónn ddeell ccóóddiiggoo ddee ccoomppoonneenntteess yy pprroocceeddiimiieennttooss..
66.. EEllaabboorraacciióónn ddee llooss maannuuaalleess ddee uussuuaarriioo..
77.. DDeeffiinniicciióónn ddee llaa ffoorrmaacciióónn ddee uussuuaarriiooss ffiinnaalleess..
99.. AApprroobbaacciióónn ddeell ssiisstteemaa ddee ffoorrmaacciióónn..
IIAASS 22.. FFoorrmaacciióónn nneecceessaarriiaa ppaarraa llaa iimppllaannttaacciióónn..
33.. IInnccoorrppoorraacciióónn ddeell ssiisstteemaa aall eennttoorrnnoo ddee ooppeerraacciióónn..
44.. CCaarrggaa ddee ddaattooss aall eennttoorrnnoo ddee ooppeerraacciióónn..
1100.. PPaassoo aa pprroodduucccciióónn

73. Introducción a Métrica v3
Participantes.

74. Participantes
z Los participantes se agrupan en perfiles.
z Los perfiles tienen atribuciones
comunes.
z Cinco perfiles:
1. Perfil directivo.
2. Perfil jefe de proyecto.
3. Perfil consultor.
4. Perfil analista.
5. Perfil programador.

75. Participantes
Perfil Descripción
Conocen bien la organización, el proceso de
negocio y los objetivos. Su misión es proveer
de recursos y validar el desarrollo.
Coordinan y dirigen los equipos humanos.
Gestionan y supervisan la gestión del proceso
de desarrollo.
Asesorar en cuestiones sobre las que tienen
un conocimiento especializado.
Elaborar requisitos, modelos y, en algunos
casos, productos
Perfil directivo
Perfil jefe de proyecto
Perfil consultor
Perfil analista
Perfil programador Construir el código durante el CSI.

76. Participantes
COMITE
DE
DIRECCIÓN
DIR
DIRECTOR
PROYECTO
USR
GRUPO
DE
USUARIOS
DTI
GRUPO
TECNOLOGÍAS
DE LA
INFORMACIÓN
EGC
* Revisa informalmente
* Revisa formalmente
EQUIPO DE
GARANTÍA DE
CALIDAD
* Dota recursos
* Revisa formalmente
EDS
JEFE DE PROYECTO
EQUIPO DE
TRABAJO
* Suministra información * Ejecuta
* Revisa informalmente
* Suministra información
* Asiste técnicamente
CDIR
Ejemplo de organización de
un grupo de Métrica:

77. Participantes
IImmppllaannttaacciióónn yy aacceeppttaacciióónn ddeell ssiisstteemmaa::
Participante Perfil
Administrador de la BBDD
Comité de dirección
Comité de seguimiento
Directores de usuarios
Equipo de formación
Equipo de implantación
Equipo de operación
Equipo de soporte técnico
Jefe de proyecto
Responsable de implantación
Responsable de mantenimiento
Responsable de operación
Responsable de sistemas
Usuarios expertos

78. Participantes
Participante Perfil
Administrador de la BBDD Perfil analista
Comité de dirección Perfil directivo
Comité de seguimiento Perfil directivo
Directores de usuarios Perfil directivo
Equipo de formación Perfil analista
Equipo de implantación Perfil analista
Equipo de operación Perfil analista
Equipo de soporte técnico Perfil analista
Jefe de proyecto Perfil jefe de proyecto
Responsable de implantación Perfil jefe de proyecto
Responsable de mantenimiento Perfil jefe de proyecto
Responsable de operación Perfil jefe de proyecto
Responsable de sistemas Perfil jefe de proyecto
Usuarios expertos Perfil directivo

79. Participantes
EEssttuuddiioo ddee VViiaabbiilliiddaadd ddeell ssiisstteemmaa::
Participante Perfil
Analistas
Comité de dirección
Directores de usuarios
Equipo de soporte técnico
Especialista en comunicaciones
Jefe de proyecto
Responsable de mantenimiento
Responsables de seguridad
Técnicos de sistemas
Usuarios expertos

80. Participantes
EEssttuuddiioo ddee VViiaabbiilliiddaadd ddeell ssiisstteemmaa::
Participante Perfil
Analistas Perfil analista
Comité de dirección Perfil directivo
Directores de usuarios Perfil directivo
Equipo de soporte técnico Perfil analista
Especialista en comunicaciones Perfil consultor
Jefe de proyecto Perfil jefe de proyecto
Responsable de mantenimiento Perfil jefe de proyecto
Responsables de seguridad Perfil jefe de proyecto
Técnicos de sistemas Perfil consultor
Usuarios expertos Perfil directivo

81. Participantes
1. ¿Quiénes son los encargados de realizar
las pruebas unitarias?.
2. ¿Quiénes proveen de los recursos
necesarios?.
3. ¿Quiénes estiman el esfuerzo necesario
para llevar a cabo el proyecto?.
4. ¿Quiénes diseñan la base de datos?.
5. ¿Participan usuarios del sistema?.

82. Actividades
Requisito [Glosario IEEE 610.12]
{Una condición o capacidad que un usuario necesita para
resolver un problema o lograr un objetivo.
{Una condición o capacidad que debe tener un sistema o
un componente de un sistema para satisfacer un contrato,
una norma, una especificación u otro documento formal.
{ Una representación en forma de documento de una
condición o capacidad como las expresadas en a) o en b).
Requisito [Norma MIL-STD STD-498]
{ Característica del sistema que es una condición para su
aceptación.
Requisito [Goguen Goguen]
{ Propiedad que un sistema debería tener para tener éxito
en el entorno en el que se usará.
La mejor definición es la
unión de las tres.

83. Introducción a Métrica v3
Introducción a UML.

84. UML. Introducción
UML = Unified Modelling Language
¿Y para qué sirve?

85. UML. Introducción
zUML está escrito en UML.
zSoportado por una gran cantidad de
herramientas (libres y propietarias).
zSe ha convertido en estándar.
zÚtil durante todo el proceso de desarrollo
y mantenimiento.

86. Niveles en la lengua
zPuedo utilizar la lengua (español) para:
{Una entrevista de trabajo.
{Negociar una hipoteca.
{Contarle a mi amigote mi última aventura…
{Simpatizar con los padres de mi novia/o.
{Escribir poesía.
{Escribir un anuncio para vender mi coche.

87. Niveles en UML
zPodemos utilizar UML para:
{Describir el problema que estamos tratando.
{Representar un negocio.
{Detallar las clases que hemos de construir.
{Saber qué métodos de qué clases llamar para
hacer una operación.
{Describir un protocolo.
{Modelas una BBDD.
{Y mucho más…

88. Un ejemplo
Clase
Relación
Dependencia

89. Un ejemplo
En mi negocio, un cliente hace varios
pedidos, aunque puedo tener
clientes que aún no me hayan hecho
ningún pedido.
Cada pedido tiene uno o varios
productos. Una vez que el pedido
está construido, se cierra y, después
se despacha. Además un cliente
puede adelantar una cantidad del
pedido.

90. Un ejemplo
Tienes que construir tres clases. La
primera se llamará cliente y tendrá
un atributo nombre y otro dirección.
La segunda se llamará producto y
tendrá el atributo nombre.
La tercera clase se llamará pedido y
tendrá un atributo fecha, otro
adelanto, otro número, otro cliente y
otro productos. Además tendrá un
método cerrar y otro despachar

91. UML. Tipos de diagramas
¿Cuáles son los diagramas
que utiliza Métrica?.

92. Un ejemplo
Diagrama de clases:
Diagrama de actividades:

93. Un ejemplo
-dimension : int
-coordenadas
Vector
+Suma(entrada vector1 : Vector, entrada vector2 : Vector) : Vector
Diagrama de secuencia:

94. Un ejemplo
Modelo
estático:
Modelo
dinámico: