Mtelloh TFC0213 Memoria

Memoria
Autor: Marcelo Tello Helbling

Consultor: Oriol Mart Girona
Ingeniera Informtica de Gestin 2012/13
Proyecto final de carrera
Proyecto final de carrera: Ingeniera de Software

Marcelo Tello Helbling (Universitat Oberta de Catalunya) Pgina 1

Esteproyectoestdedicadoamispadres,amishermanosy
amipareja,porsuapoyoincondicionalenestaetapademi
vidayaOriol,miconsultor,porsugranayudadurantela
elaboracin.

Barcelona,2deEnerode2013

Resumen

El proyecto CMMI UP surge de la necesidad por parte de las
organizaciones de una herramienta que soporte las
actividades que se llevan a cabo para afrontar el proyecto
de implantacin CMMI en el marco de un proyecto interno.
Un proyecto interno de la talla de una implantacin CMMI
supone afrontar unos costes internos bastante elevados
(costes directos) y los que supone interferir en las
actividades habituales que desempean (costes indirectos).
Por ejemplo, al gasto directo del propio equipo del
proyecto de implantacin, el proveedor de auditora y certificacin, se le une los gastos
derivados del impacto que supone interferir la metodologa propia de los proyectos en curso y
de las actividades de comunicacin interna.
Para el equipo encargado de asumir la difcil tarea de abordar un proyecto de estas
caractersticas se les plantean una serie de actividades como las detalladas a continuacin:
Gestionar y planificar el proyecto interno de implantacin
Coordinar la agenda con el equipo de auditora que certificar a la organizacin.
Gestionar la comunicacin con el equipo de los proyectos seleccionados, informe del
avance a direccin, etc.
Revisar los procesos actuales de la compaa y proponer su alineamiento con el
modelo CMMI.
Revisar y verificar el estado de las tareas encomendadas a cada uno de los equipos de
los proyectos seleccionados.
Informar y tomar decisiones de la viabilidad de cada una de las fases del proyecto.
Recopilar la base de datos de evidencias para su presentacin al equipo de auditora
externo.
CMMI UP aporta una herramienta para el equipo de proyecto de CMMI que les permitir
gestionar de una manera centralizada, todas las actividades anteriormente descritas, as como
obtener una visin clara del estado del proyecto y los objetivos abordados.



ndice de contenido
Resumen .................................................................................................................................. 2
ndice de contenido .................................................................................................................. 3
ndice de ilustraciones .............................................................................................................. 5
Introduccin ............................................................................................................................. 7
Qu es CMMI y qu pretende? ............................................................................................ 9
Justificacin ........................................................................................................................ 11
Objetivos............................................................................................................................. 14
Enfoque y mtodo aplicado ................................................................................................. 15
Recursos ............................................................................................................................. 16
Planificacin del proyecto ................................................................................................... 17
Productos obtenidos ........................................................................................................... 19
Anlisis previo y especificacin de requisitos ......................................................................... 20
Modelo de negocio ............................................................................................................. 20
Debilidades del modelo ....................................................................................................... 23
Requisitos ........................................................................................................................... 24
Descripcin del sistema ....................................................................................................... 31
Identificacin de actores ..................................................................................................... 32
Relacin de los subsistemas con los actores ........................................................................ 33
Detalle y funcionalidades de los subsistemas ....................................................................... 34
Documentacin formal de casos de uso .............................................................................. 37
Modelo esttico : Diagrama de clases .................................................................................. 59
Diseo del sistema ................................................................................................................. 64
Decisiones de arquitectura .................................................................................................. 66
Modelo esttico : Diagrama de clases .................................................................................. 73
Clases frontera y gestoras CMMI Core ................................................................................. 75
Clases frontera y gestoras CMMI Proyectos, revisiones incidencias ...................................... 76
Diseo de casos de uso : Diagramas de actividad de procesos ............................................. 77
Diseo de casos de uso : Diagramas de secuencia ............................................................... 81
Diseo E/R CMMI Core ........................................................................................................ 86
Diseo de la interfaz grfica ................................................................................................... 87
Pantalla principal y men .................................................................................................... 87
Login ................................................................................................................................... 88

DashBoard .......................................................................................................................... 89
Pantallas CMMI: Core .......................................................................................................... 90
Pantallas CMMI: Proyectos, Roles ........................................................................................ 94
Pantallas CMMI: Revisiones ................................................................................................. 96
Valoracin econmica .......................................................................................................... 101
Conclusiones ........................................................................................................................ 103
Apndice A: Glosario ............................................................................................................ 104
Apndice B: Bibliografa ....................................................................................................... 118



ndice de ilustraciones

Ilustracin 1 Historia de los modelos de madurez ...................................................................... 8
Ilustracin 2 Constelaciones CMMI............................................................................................ 9
Ilustracin 3 reas de inters CMMI .......................................................................................... 9
Ilustracin 4 Empresas certificadas en Espaa ......................................................................... 12
Ilustracin 5 Ciclo de vida clsico............................................................................................. 15
Ilustracin 6 Entregables del proyecto ..................................................................................... 18
Ilustracin 7 Metodologa SCRUM ........................................................................................... 20
Ilustracin 8 Esquema de una implantacin CMMI .................................................................. 22
Ilustracin 9 Diagrama de paquetes CMMI UP ......................................................................... 31
Ilustracin 10 Relacin de actores y subsistemas ..................................................................... 33
Ilustracin 11 Componentes CMMI UP .................................................................................... 34
Ilustracin 12 Componentes en la representacin de casos de uso .......................................... 38
Ilustracin 13 Casos de uso subsistema conexin .................................................................... 44
Ilustracin 14 Casos de uso del subsistema CMMI ................................................................... 47
Ilustracin 15 Casos de uso de Proyectos ................................................................................ 50
Ilustracin 16 Casos de uso tareas y coberturas ...................................................................... 52
Ilustracin 17 Diagrama de casos de uso del subsistema de revisiones y acciones correctivas .. 57
Ilustracin 18 Casos de uso Cuadro de mandos ....................................................................... 58
Ilustracin 19 Diagrama de clases CMMI ................................................................................. 59
Ilustracin 20 Ejemplo informacin CMMI ............................................................................... 60
Ilustracin 21 Ejemplo Informacin CMMI (Cont.) ................................................................... 61
Ilustracin 22 Ejemplo Informacin CMMI (Cont.) ................................................................... 62
Ilustracin 23 Diagrama de clases Revisiones .......................................................................... 63
Ilustracin 24 Diagrama de la estructura de la aplicacin ......................................................... 70
Ilustracin 25 Flujo a travs de los componentes ..................................................................... 71
Ilustracin 26 Esquema general de la arquitectura .................................................................. 72
Ilustracin 27 Diagrama de clases CMMI ................................................................................. 73
Ilustracin 28 Diagrama de clases Revisiones .......................................................................... 74
Ilustracin 30 Detalle de la relacin de componentes modelo, vista, controlador .................... 75
Ilustracin 29 Clases frontera y gestoras CMMI Core ............................................................... 75
Ilustracin 31 Clases frontera y gestoras CMMI Proyectos revisiones e incidencias .................. 76
Ilustracin 32 Diagrama de actividad para la gestin deusuarios ............................................. 78
Ilustracin 33 Diagrama de actividad para la revisin de una tarea .......................................... 79
Ilustracin 34 Diagrama de actividad para insertar evidencias ................................................. 80
Ilustracin 35 Diagrama de secuencia para listas ..................................................................... 82
Ilustracin 36 Diagrama de secuencia para Altas ..................................................................... 83
Ilustracin 37 Diagrama de secuencias para 'bajas' .................................................................. 84
Ilustracin 38 Diagrama de secuencia para Dashboard ............................................................ 85
Ilustracin 39 E-R CMMI Core .................................................................................................. 86
Ilustracin 40 Prototipo pantalla Men ................................................................................... 87

Ilustracin 41 Prototipo Pantalla Login .................................................................................... 88
Ilustracin 42 Prototipo DashBoard ......................................................................................... 89
Ilustracin 43 Prototipo lista de Categoras.............................................................................. 90
Ilustracin 44 Prototipo Alta de Categora ............................................................................... 91
Ilustracin 45 Prototipo lista niveles de Madurez .................................................................... 92
Ilustracin 46 Prototipo lista reas de proceso ........................................................................ 93
Ilustracin 47 Prototipo lista Roles .......................................................................................... 94
Ilustracin 48 Prototipo lista de proyectos ............................................................................... 94
Ilustracin 49 Prototipo alta de proyectos ............................................................................... 95
Ilustracin 50 Prototipo lista tipos de revisiones ...................................................................... 96
Ilustracin 51 Prototipo lista tareas de revisin ....................................................................... 96
Ilustracin 52 Prototipo Alta de tareas de revisin ................................................................... 97
Ilustracin 53 Prototipo matriz de revisiones ........................................................................... 98
Ilustracin 54 Prototipo lista de cobertura de tareas ............................................................... 99
Ilustracin 55 Prototipo calendario de revisiones .................................................................. 100


Introduccin

La calidad nunca es un accidente; siempre es el resultado de un esfuerzo de inteligencia. John
Ruskin (1819-1900) Crtico y escritor britnico.
Durante los aos ochenta, el departamento de defensa de los EEUU consciente de la
problemtica que tena en los encargos de desarrollo de software (presupuestos, bajo nivel de
calidad, incumplimiento de fechas, etc.) , se aventur a crear un comit de expertos que
analizara dicha situacin y propusiera una solucin.
Dichos expertos, concluyeron como mejor solucin, la creacin
de un instituto de ingeniera de software que diera una
respuesta efectiva al cmulo de problemas que originaba la
mala calidad del software, as como la imposibilidad de
planificar los tiempos y coste del desarrollo. Fue entonces
cuando en 1994, el congreso de los EEUU fund el Instituto de
Ingeniera de Software (SEI) constituido como instituto federal
para la investigacin y desarrollo administrado por la
Universidad de Carneige Mellon.
Uno de los primeros acometidos del SEI, fue la creacin de un modelo de procesos para el
desarrollo y mantenimiento de sistemas de software (SW-CMM), que ha evolucionado hasta
nuestros das como el modelo CMMI (Capability Mature Model Integration). Este modelo se
sustenta sobre los siguientes criterios:
La calidad de un producto o sistema es consecuencia directa de los procesos
empleados en su desarrollo.
Las organizaciones que desarrollan software presentan un atributo denominado
madurez, cuya medida es proporcional a los niveles de capacidad e institucionalizacin
de los procesos que emplean en su trabajo
Dicho de otro modo, para desarrollar software de calidad, es preciso que a totalidad de los
procesos empleados en el desarrollo, sean de calidad.


Ilustracin 1 Historia de los modelos de madurez

Qu es CMMI y qu pretende?

Como hemos visto en el apartado anterior, CMMI surge de la
necesidad de alinear el trabajo de los proveedores de software
hacia su cliente y de plantearles las buenas prcticas que deben
cumplir para producir un software con la calidad exigida y en los
plazos establecidos.
En el mercado actual, los modelos de madurez, estndares,
metodologas y guas, ayudan a las organizaciones a llevar a cabo los objetivos de negocio. No
obstante, la mayora de actividades se centran en una parte especficas del negocio, y no
realizan un aproximamiento sistemtico de los problemas que la mayora de organizaciones
tienen. Esta visin reducida del problema, provoca que muchas empresas arrastren
eternamente las dificultades iniciales.
Este redactado de buenas prcticas del modelo CMMI lo que propone es una reingeniera de
procesos aplicados al producto o al servicio. Dicha reingeniera es totalmente compatible con
un proyecto en particular, un departamento o bien toda la empresa dedicada a la fabricacin
de software y da la posibilidad de que cada uno de estos procesos fluya de una forma alineada
para llevar a cabo el tan complicado proceso de elaboracin, mantenimiento y operacin de
sistemas de software.
En realidad, CMMI cubre tres reas de inters: Desarrollo, Adquisicin y Servicios, pero en el
marco de nuestro proyecto nicamente nos centraremos en, como as lo denominan, la
constelacin de para el desarrollo.

Ilustracin 2 Constelaciones CMMI

CMMI para el desarrollo de software, contiene 22 reas de proceso de las cuales, 16 son reas
especficas del ncleo (core), 1 es un rea compartida y 5 son reas especficas de desarrollo.
Como observamos en la ilustracin siguiente, la constelacin de Desarrollo, posee 4 categoras
en los que se distribuyen todos los procesos documentados: Ingeniera, Gestin de proyectos,
Gestin de procesos y Soporte, esta ltima posee los procesos transversales de la
organizacin.
Asimismo, todo el modelo CMMI est organizado de tal forma que sus buenas prcticas tienen
como objetivo situarnos en uno de estos 5 niveles de madurez.

Ilustracin 3 reas de proceso de la constelacin de Desarrollo


Justificacin

La situacin actual del desarrollo de software afronta un escenario poco alentador. En
situaciones de crisis, las grandes empresas que contratan los servicios tecnolgicos han sufrido
recortes y miran con lupa cualquier gasto en esta partida contable. No es de extraar que la
empresa que posea una certificacin CMMI, posee un valor aadido muy competitivo y una
presentacin excelente de cara a las ofertas de sus clientes.
Algunos ejemplos extrados a travs del siguiente blog de Javier Garzs
(www.javiergarzs.com), podemos observar como en el 2010 muchos de los pliegos emitidos
por las grandes organizaciones ya incorporan como requisito poseer una certificacin CMMI.
Ministerio de Ciencia e Innovacin (2010). Requiere de CMMI e ISO 15504.
Ministerio de Industria, Justicia y Red.es (2010). Obligatoriamente nivel 3 en CMMI o
ISO 15504.
Direccin general de patrimonio. Subdireccin general de compras (2010). Empresas
certificadas tanto en CMMI como en ISO 15504
Direccin General de Sistemas de Informacin Sanitaria (2010). Servicio madrileo de
salud. Comunidad de Madrid. Requiere de CMMI e ISO 15504.
Isdefe (Ingeniera de Sistemas para la Defensa de Espaa) (2010). Requiere slo de
CMMI
Ayuntamientos: Ayuntamiento de Benidorm (Alicante), requiere slo de ISO
15504, Ayuntamiento de Lorca (Murcia), Requiere slo de ISO 15504, etc.

Cada vez ms son las empresas que exigen una garanta en forma de certificacin.
No obstante, no todas las empresas proveedoras estn preparadas para afrontar este proyecto
de cambio. Los procesos de la organizacin pasarn a evaluarse y posiblemente alterar sus
flujos actuales a la vez que nuevas herramientas pueden surgir e imponerse de forma
corporativa. Surgirn nuevos roles y quizs se eliminen otros, y sobre todo, la empresa puede
estar sometida a un nivel de presin constante por parte de los partidarios y los detractores de
este nuevo modelo.


No toda la organizacin est preparada para este cambio cultural. Es por este motivo que
algunos puntos clave de esta implantacin debe ir acompaada de:
Un proyecto estudiado y planificado al detalle junto con expertos en la materia.
Un equipo con conocimiento y experiencia en este campo.
Implicacin del comit de direccin de un modo pblico y transparente.
Realizar una evaluacin previa para saber el estado o nivel de madurez actual.
Definir las herramientas de gestin no slo las que se utilizarn de manera estndar
en el contexto de CMMI sino las que se utilizarn para dar soporte al proyecto de
implantacin.
En la siguiente ilustracin podemos observar los datos referidos al ao 2010 y que nos
muestran el nmero de organizaciones certificadas en CMMI clasificadas por nivel de madurez
en Espaa.

Ilustracin 4 Empresas certificadas en Espaa


Como se puede observar, la mayora de organizaciones optan por los niveles 2 y 3 de CMMI,
que coincide con la exigencia de las ofertas y pliegos publicados por las grandes
administraciones y empresas pblicas.
El riesgo que supone alcanzar un nivel 4 o 5 debe ser revisado con lupa, puesto que la relacin
coste-beneficio no siempre est a favor de la empresa proveedora.
Estos datos son publicados frecuentemente por el SEI a travs del siguiente enlace:
https://sas.sei.cmu.edu/pars/pars.aspx


Objetivos

El objetivo primordial de este proyecto es llevar a cabo las tareas
de Anlisis de Requerimientos, Especificacin y Diseo
comprendidos en el ciclo de vida del software.
El anlisis de requerimientos se llevar a cabo con la informacin
aportada por la propia compaa en cuanto a necesidades y
problemticas encontradas durante una implantacin real a la
que se le darn las soluciones apropiadas para disponer de una
herramienta que permita optimizar ciertas actividades para la
gestin de una implantacin CMMI.
Esta solucin, no slo debe aportar una solucin prctica al problema, sino que debe
argumentarse en un contexto de ahorro de costes y retorno de la inversin, que es la prioridad
de cualquier organizacin, por tanto, es muy importante recalcar que cada especificacin de
requisito englobe cierto enfoque de este tipo.



Enfoque y mtodo aplicado

La metodologa escogida para la realizacin del proyecto es la llamada metodologa en
cascada.
Ventajas
Calidad del producto alta
Permite detectar problemas de viabilidad del proyecto antes de proseguir con fases
posteriores.
Reduccin de costes de desarrollo debido a la alta calidad en la fase de requisitos.
Inconvenientes
Los problemas surgidos en alguna fase implican un rediseo o reprogramacin y su
consecuente aumento de costes.
Requisitos con un alto grado de detalle y fiabilidad (comentado como riesgo a
controlar).
El producto final no es visible hasta el final.

Ilustracin 5 Ciclo de vida clsico


Recursos
Los recursos necesarios para llevar a cabo el proyecto son:
Personal
nica persona para la elaboracin de todas las tareas descritas en el apartado Tareas y
planificacin
Herramientas
PC de Sobremesa con conexin a Internet
Software Ofimtico Office : Word, Project, Excel, PowerPoint
Software para el diseo de base de datos: DB-Designer
Software para la elaboracin de prototipos: Visio, Yii Framework, etc.
Software para la elaboracin de scripts de persistencia : MySQL
Documentacin:
Toda la documentacin detallada en la bibliografa.


Planificacin del proyecto
Para realizar la planificacin, y, siguiendo las buenas prcticas en gestin de proyectos, hemos
realizado una descomposicin estructural de actividades (WBS).
Descomposicin estructural de actividades (WBS)
Cdigo de actividad Nombre de actividad (Nivel I) Nombre de actividad (Nivel II)
PAC-1 Plan de trabajo
1.1 Propuesta
1.2 Descripcin
1.3 Objetivos
1.4 Anlisis situacin actual
1.5 Anlisis y gestin de riesgos
1.6 Eleccin de metodologa
1.7 Descomposicin de tareas
1.8 Planificacin
Elaborar entregable

PAC-2 Especificacin y anlisis de requisitos
2.1 Introduccin y marco del proyecto
2.2 Elaboracin de requisitos
2.3 Descripcin del sistema
2.4 Descripcin de los subsistemas
2.5 Documentacin de actores y casos
de uso
2.6 Diagramas necesarios
2.7 Elaboracin entregable Anlisis



PAC-3 Diseo tcnico
3.1 Diseo tcnico de los subsistemas
3.2 Diagramas (colaboracin y
secuencia)
3.3 Diseo de casos de uso
3.4 Base de Datos: Diseo de
persistencia y E/R
3.5 Prototipo Interface de Usuario
3.7 Entregable Diseo

PAC-4 Memoria y presentacin
4.1 Revisin de entregables
4.2 Elaboracin de anexos
4.3 Bibliografa y glosario de trminos
4.4 Revisin y entregable Memoria
4.5 Elaboracin presentacin

Ilustracin 6 Entregables del proyecto


Productos obtenidos
Una vez abordado el proyecto en la totalidad de sus fases obtenemos los siguientes
entregables:
Documento de anlisis y especificacin
En este documento hemos contemplado los requisitos de la organizacin en la que nos hemos
basado para abordar dicho proyecto. En el podemos situar el proyecto de una forma realista
puesto que se trata de una empresa real con necesidades reales.
Documento de diseo
Partiendo del documento anterior, realizamos el diseo del sistema abordando la mayora de
los requisitos funcionales. Con ello conseguimos un entregable que proporcionar la base para
la implementacin posterior, la cual, no hemos contemplado en el marco de este proyecto.
Memoria del proyecto
En este documento presentamos todo el proyecto conjunto con los anexos correspondientes,
bibliografa, glosario.
Presentacin del proyecto
Con esta presentacin pretendemos transmitir de una forma sintetizada cmo hemos enfocado
el proyecto y qu hemos pretendido abordar con el mismo. De una manera grfica y resumida,
intentamos comunicar al oyente todos los aspectos ms relevantes del proyecto.
Prototipo realista del proyecto
Para evaluar la viabilidad y hacer una estimacin realista del proyecto en trminos econmicos,
hemos iniciado un prototipo del mismo. Aunque no entra dentro del marco del proyecto,
hemos querido mencionarlo.


Anlisis previo y especificacin de requisitos

Modelo de negocio
El caso que nos ocupa, viene a solucionar una situacin en la que una empresa que desarrolla
software debe abordar una implantacin de CMMI en el marco de un proyecto interno de
mejora de la competitividad.
Dicho proyecto interno se aborda bajo el paraguas de una metodologa iterativa e incremental
llamada SCRUM. La particularidad de esta metodologa, en el contexto de la organizacin, es
que el producto final no es en s un producto, sino una garanta de que toda la lista de tareas
encomendadas para el cumplimiento de los objetivos que marca CMMI dentro de sus
respectivas reas se han cumplido.
Una vez un comit directivo escoge las condiciones bajo las cuales deben ser escogidos los
proyectos candidatos para abordar la auditora se planifica un kick-off del proyecto en el que se
presentan, a los interesados, los objetivos, riesgos e hitos del proyecto.
Las fases del proyecto de implantacin se basan en iteraciones acotadas en el tiempo, durante
el cual, el equipo (tanto interno como el de los diversos proyectos candidatos) trabaja para
acercarse cada vez ms a la consecucin de las metas marcadas por CMMI. Estas iteraciones
son las que SCRUM denomina SPRINT.

Ilustracin 7 Metodologa SCRUM


En el marco del proyecto de implantacin, el SPRINT est compuesto por tres actividades
principales:
Desarrollo:
Durante esta actividad, el equipo interno de CMMI especifica y estudia las actividades que
deben realizarse para un rea concreta. Se revisa el repositorio documental donde se haya
CMMI y se asocian actividades para el cumplimiento de los objetivos marcados, tanto
genricos como especficos. En esta etapa intervienen expertos en funcin del rea que se
trate: Jefes de proyecto, Ingenieros de software, Personal de reas de calidad, etc.
Despliegue:
La fase despliegue contemplan todas las actividades a realizar por los diferentes equipos de los
proyectos seleccionados y en las que se han trabajado en la fase de desarrollo. El impacto de
esta fase en los proyectos seleccionados y para una primera implantacin de CMMI es bastante
alto, dado que tendrn que crear documentacin especfica, alterar procedimientos, usar
nuevas herramientas, etc. En esta fase, se incorporar unas figuras llamadas multiplicadores,
que son personas formadas por el equipo interno del proyecto de implantacin para el
asesoramiento a los equipos de proyectos para la consecucin de las actividades a realizar.
Cada multiplicador puede tener asignados de uno a tres proyectos.
Revisin:
Durante este intervalo de tiempo, el equipo interno del proyecto de implantacin recopila la
informacin que debera haberse realizado y la cruza con los diferentes proyectos. Esta matriz
es revisada y puesta al da con diferentes estados: Realizado, No realizado, No procede, etc.
Cuando una revisin da un resultado negativo, el revisor propone una accin correctiva al
equipo de proyecto. Esta accin correctiva debe ser llevada a cabo para su nueva revisin.
Esta fase es muy importante ya que marca el indicador de progreso del proyecto, y en
consecuencia, el punto de situacin en relacin al nivel de madurez que se haya marcado la
organizacin.



Ilustracin 8 Esquema de una implantacin CMMI

En el siguiente esquema podemos ver un ejemplo de lo comentado anteriormente:



Adems de las fases iterativas, ser realizan los llamados WorkShops. En estas reuniones de
trabajo se desarrollan las siguientes actividades:
Un representante de cada rea (que engloba diferentes proyectos) presenta los
resultados del despliegue llevado a cabo e iniciado en el sprint anterior. Este
representante comenta de una forma genrica, el grado de consecucin de las tareas
encomendadas y el motivo por el cual, los proyectos bajo su tutela, no ha llevado a
cabo las que no ha podido abordar.
Un representante del equipo interno de implantacin presenta los resultados de las
revisiones realizadas al despliegue efectuado en el sprint anterior junto con el avance
total de la implantacin.
Un representante del equipo interno de implantacin describe las tareas que
debern abordarse para el siguiente sprint y que ya han sido alineadas con los
objetivos del rea concreta de CMMI.
Se forman a los llamados multiplicadores, que son las personas que darn apoyo y
asesoramiento al equipo de los diferentes proyectos en la consecucin de las
actividades a realizar.

Debilidades del modelo
A raz de las actividades mencionadas anteriormente y de las cuales he participado como
multiplicador, he podido deducir alguno de los requisitos que he contrastado con el personal
del equipo CMMI. Por otro lado, se ha realizado una labor posterior de entrevistas con el
equipo, para averiguar las necesidades de los diversos actores participantes en la implantacin.
A modo resumen, podramos destapar las siguientes debilidades:
Equipo de proyectos seleccionados
Los equipos de proyecto (analistas, jefes de proyecto, gestores de calidad, testers) no
tienen claro qu tareas deben cumplir y con qu objetivo.
Los multiplicadores no disponen de un repositorio amigable y con documentacin
fcilmente organizada donde figuren las tareas y la informacin sobre el modelo de
madurez CMMI

En ocasiones, los roles de los equipos de proyecto son mixtos, lo que dificulta la
asignacin de tareas a realizar.
Equipo de revisiones de tareas
Las revisiones se llevan a cabo por diferentes personas (en funcin del rea) y con
herramientas o mtodos distintos, lo que dificulta la centralizacin y el tratamiento de
la informacin.
La manipulacin de la informacin es compleja con las herramientas ofimticas
habituales.
Existe una tendencia a concentrar las tareas y revisiones al comienzo de los sprints, lo
que crea una presin aadida al equipo de revisiones.
Equipo de gestin de proyecto CMMI
Existen dificultades en la integracin y explotacin de los datos revisados para su
presentacin en los WorkShops.
Las herramientas usadas para presentar los indicadores de progreso se hacen lentas al
tener que manipular muchos datos.
Falta de una visin global de la situacin y progreso.
Requisitos
En este apartado haremos una relacin de los requisitos que debe contemplar este proyecto
para dar solucin a las necesidades de la empresa.
Por un lado, enumeramos los requisitos funcionales, que son los que definirn el
comportamiento del sistema y por otro los requisitos no funcionales, que son aquellos en los
que intervienen en aspectos cualitativos, de rendimiento, etc.
Lista de Requisitos funcionales

Subsistema Identificador Descripcin
Conexin RF_0.1 Gestin de usuarios y permisos
CMMI Core RF_1.1 Gestin de objetivos genricos
RF_1.2 Gestin de prcticas genricas
RF_1.3 Gestin de reas de proceso
RF_1.4 Gestin de categoras de reas de proceso

RF_1.5 Gestin de niveles de madurez
Proyectos candidatos RF_2.1 Mantenimiento de proyectos
RF_2.2 Mantenimiento de roles
RF_2.3 Mantenimiento de departamentos
RF_2.4 Equipos de proyecto
Tareas de revisin y
cobertura
RF_3.1 Gestin de tipos de revisiones
RF_3.2 Tareas de revisin
RF_3.3 Coberturas de tarea
Revisiones y
evidencias
RF_4.1 Generacin de tareas de revisin
RF_4.2 Agenda de revisiones y acciones de revisin
RF_4.3 Incidencias y acciones correctivas
DashBoard RF_5.1 Cuadro de mandos con grficas y posibilidad de impresin

Detalle de requisitos funcionales
RF 0.1: Gestin de usuarios
Descripcin del requisito: Este requisito es fundamental para el funcionamiento de la aplicacin, pues desde l, el
sistema validar las credenciales y dar permiso a las diferentes opciones de men.
Requisitos de almacenamiento: Deben tenerse en cuenta las siguientes propiedades para un usuario:
Datos demogrficos
Datos para la validacin de credenciales
Datos para el acceso a las diferentes opciones del men principal de la aplicacin.

RF 1.1: Gestin de objetivos genricos
Descripcin del requisito: Este requisito pertenece a la informacin del modelo CMMI. Son los objetivos
transversales que debe cumplir la organizacin
Requisitos de almacenamiento: Deben tenerse en cuenta las siguientes propiedades :
Cdigo y descripcin

RF 1.2: Gestin de prcticas genricas
Descripcin del requisito: Este requisito pertenece a la informacin del modelo CMMI. Son las prcticas que deben
cumplirse para cumplir con los objetivos genricos

Requisitos de almacenamiento: Deben tenerse en cuenta las siguientes propiedades:
Cdigo y descripcin de prctica
Objetivo para el cual se realiza la prctica

RF 1.3: Gestin de reas de proceso
Descripcin del requisito: Este requisito pertenece a la informacin del modelo CMMI. Son las reas de proceso que
engloba el modelo de madurez
Cdigo y descripcin
Categora a la que pertenece y nivel de madurez al que pertenece

RF 1.4: Gestin de categoras de reas de proceso
Descripcin del requisito: Este requisito pertenece a la informacin del modelo CMMI. Son las categoras en las que
se clasifican las reas de proceso
Cdigo y descripcin.

RF 1.5: Gestin de niveles de madurez
Descripcin del requisito: Este requisito pertenece a la informacin del modelo CMMI. Son los niveles de madurez
del modelo
Nmero de nivel (1-5) y descripcin.

RF 2.1: Gestin de proyectos candidatos
Descripcin del requisito: Con este requisito podremos gestionar los proyectos candidatos a la auditora CMMI
Cdigo y descripcin
Departamento al que pertenece
Candidato/No candidato
Fechas de vigencia

RF 2.1: Gestin de roles de proyecto

Descripcin del requisito: Con este requisito podremos asignar roles a los diferentes miembros del equipo de un
proyecto
Cdigo y descripcin

RF 2.3: Gestin de departamentos
Descripcin del requisito: Cada proyecto pertenece a una unidad funcional o departamento. A travs de este
requisito pretendemos gestionar las diferentes unidades para un proyecto
Cdigo y descripcin

RF 2.1: Gestin de equipos de proyecto
Descripcin del requisito: Con este requisito podremos asignar miembros y roles a los proyectos
Usuario, Rol, proyecto

RF 2.1: Gestin de proyectos candidatos
Descripcin del requisito: Con este requisito podremos gestionar los proyectos candidatos a la auditora CMMI
Cdigo y descripcin
Departamento al que pertenece
Candidato/No candidato
Fechas de vigencia

RF 3.1: Gestin de tipos de revisiones
Descripcin del requisito: Con este requisito podremos gestionar los tipos de revisiones que se realizan (frecuencia)
Cdigo y descripcin
Frecuencia de das
nica/No nica

RF 3.2: Gestin de tareas de revisin

Descripcin del requisito: Con este requisito podremos gestionar las diferentes tareas que se llevan a cabo para
posteriormente revisarlas en el contexto del proyecto.
Cdigo y descripcin
Tipo de revisin

RF 3.3: Gestin de coberturas de revisin
Descripcin del requisito: Con este requisito podremos gestionar las diferentes tareas que se llevan a cabo para
posteriormente revisarlas en el contexto del proyecto.
Tarea que dar cobertura
rea de proceso a la que dar cobertura
Objetivo especfico al que dar cobertura.

RF 4.1: Generacin de tareas de revisin
Descripcin del requisito: Con este requisito podremos realizar la matriz de revisiones que comprende los proyectos
y las diferentes tareas que debern realizar.
Fecha hasta la cual se realizar la generacin de tarea.
Proyectos de los cuales se quiere realizar la generacin.

RF 4.2: Agenda de revisiones y acciones de revisin
Descripcin del requisito: Una vez generada la agenda de revisiones, podremos seleccionar proyecto y tarea y
actualizar su estado as como comentarios y evidencias
Seleccionar estado de revisin
Evidencia de tarea cumplida.
Almacenar timestamp de revisin.

RF 4.3: Incidencias y acciones correctivas
Descripcin del requisito: Por una parte, durante la tarea de revisin es posible generar una incidencia que debe ser
corregida por un miembro del equipo de proyecto. Cada miembro del proyecto tendr un buzn donde constan las
incidencias reportadas por el revisor y la accin correctiva detallada.

Incidencia, revisin asociada
Accin correctiva aconsejada
Responsable de la accin correctiva.

RF 5.1: Cuadro de mandos
Descripcin del requisito: Se debe tener acceso a un cuadro de mandos con diferentes grficas como la posibilidad
de imprimir
Grficas porcentuales de cobertura del modelo en el total de proyecto de implantacin
Grficas porcentuales de cobertura del modelo en proyectos concretos.
Grfico de tareas cumplidas/no cumplidas/ en espera, etc.

Requisitos no funcionales
Identificador Clasificacin Descripcin
RNF_1 Rendimiento La aplicacin debe tener un rendimiento ptimo para el uso
compartido por 10-20 usuarios concurrentes
RNF_2 Disponibilidad La disponibilidad para el usuario debe ser en horario laboral,
dejando el resto del horario para tareas de mantenimiento.
RNF_3 Seguridad La aplicacin debe cumplir con los estn dares de seguridad
corporativos en el contexto de una intranet.
RNF_4 Usabilidad La aplicacin debe hacer uso de las buenas prcticas en
usabilidad y adecuar su look & feel al corporativo.
RNF_5 Estabilidad Sistema estable en entornos de servidor web.
RNF_6 Portabilidad Aplicacin disponible en mltiples plataformas
RNF_7 Interoperabilidad La aplicacin deber integrarse con el sistema de usuarios
LDAP corporativo.
RNF_8 Escalabilidad La implementacin debe proporcionar mecanismos para que
la aplicacin sea fcilmente escalable.
RNF_9 Concurrencia La concurrencia deber contemplar 10-20 usuarios.
RNF_10 Mantenimiento


Requisitos empresariales
Identificador Clasificacin Descripcin
RE_1 Econmico Reduccin del gasto del proyecto
RE_2 Estratgico Reforzar la competitividad en el mercado


Descripcin del sistema
CMMI UP es un software clasificado como empresarial. Este tipo de software est orientado a
mejorar la productividad o a medirla. En este sentido, como hemos mencionado
anteriormente, el sistema se compone de diversos mdulos funcionales que ayudar a cada
actor del sistema a mejorar su cometido y en trminos generales mejorar la productividad y
aumentar la eficiencia de la implantacin CMMI.
A continuacin podemos ver un diagrama de paquetes que ilustra esta descomposicin.

Ilustracin 9 Diagrama de paquetes CMMI UP



Identificacin de actores

Coordinador del equipo CMMI

El coordinador del equipo CMMI es en realidad el jefe del proyecto. Su misin es asegurarse
que el proyecto se lleva a cabo en los trminos establecidos tanto temporales como de coste.

Experto en CMMI
El Experto en CMMI es el que mejor conoce el modelo de madurez y las metodologas actuales
de la empresa. Junto con los expertos en las reas de ingeniera de software acuerda las
actividades que deben realizarse para que se cumplan los objetivos CMMI.

Multiplicador CMMI
Los multiplicadores asisten a los WorkShops informativos y dan apoyo durante el despliegue de
los sprints a los diferentes equipos. Son conocedores de cmo deben realizarse las tareas
encomendadas.

Revisor CMMI
Los revisores son las personas que diariamente revisan que las tareas encomendadas se han
cumplido. Para ello, en una matriz de proyectos/tareas, van apuntando el estado de la tarea. Si
existe una tarea que no est bien realizada o no hecha, dan de alta un registro en una base de
datos de incidencias corporativa para que se resuelvan.

Usuario de Proyecto involucrado
Denominamos as a cualquier miembro de un equipo de proyecto que est interesado en
acceder al repositorio documental de CMMI.


Relacin de los subsistemas con los actores
En el siguiente diagrama se representa la relacin de los diferentes subsistemas con los
actores.

Ilustracin 10 Relacin de actores y subsistemas



Detalle y funcionalidades de los subsistemas

A continuacin se representa un grfico ms ilustrativo de los componentes y funcionalidades
del sistema.

Clasificacin
Vnculos CMMI
Evidencias
Agenda
Estado de tareas
PIIDB
Proyectos
Revisores
Equipo
Indicadores
Informes
Progreso
Dashboard
Proyectos
candidatos
Tareas de
revisin y
cobertura
Revisiones
y
Evidencias
CMMI
Info
Usuarios y perfiles
Ilustracin 11 Componentes CMMI UP


Subsistema de gestin de usuarios
Descripcin:
El subsistema de gestin de usuarios proporciona las funcionalidades bsicas para realizar el
mantenimiento de los usuarios. Estos usuarios son los que posteriormente se asignarn al rol
pertinente.
Funcionalidades:
Mantenimiento de usuarios
Gestionar contraseas

Subsistema de informacin CMMI: CMMI Info
Descripcin
El subsistema de informacin CMMI (CMMI Info) es dnde se documentan todos los procesos
CMMI. El software vendr preinstalado con toda la informacin acerca del modelo de madurez
para cada uno de los niveles publicados hasta la fecha. No obstante, el usuario podr dar de
alta y mantener la informacin a su gusto.
Funcionalidades:
Las funcionalidades principales de este subsistema son:
Mantenimiento de niveles de madurez
Mantenimiento de reas de competencias
Mantenimiento objetivos genricos
Mantenimiento de objetivos especficos
Asociacin de objetivos a reas
Asociacin de reas a niveles.


Subsistema de gestin de proyectos candidatos
Descripcin:
En este subsistema se renen las funcionalidades para mantener los proyectos que van a ser
revisados y los que finalmente sern auditados para la certificacin CMMI.
Funcionalidades:
Mantenimiento de reas departamentales
Mantenimiento de proyectos
Mantenimiento de equipos de trabajo
Asociacin de revisores a los proyectos.

Subsistema de configuracin de tareas de revisin y cobertura
Descripcin:
Este subsistema posee las funcionalidades para configurar los tipos de revisiones (nicas,
mensuales, etc.), la descripcin de las diferentes tareas y a qu objetivo del modelo CMMI da
cobertura.
Funcionalidades:
Alta de tipos de revisiones
Detalle de tareas
Coberturas a los objetivos CMMI
Subsistema de revisin y evidencias
Descripcin:
En este subsistema se proporcionan las funcionalidades para la gestin del resultado de las
revisiones. Gestionar las incidencias encontradas en la revisin y comunicarlas a los diferentes
equipos de proyecto son las principales actividades de este subsistema.
Funcionalidades:
Aadir incidencias y proponer acciones correctivas
Comunicar a los equipos de proyecto
Buzn de comunicacin de incidencias (Equipo de proyecto y revisor).


Subsistema de indicadores
Descripcin:
El subsistema de indicadores proporciona un cuadro de mandos con las grficas ms usadas en
este tipo de implantaciones.
Funcionalidades:
Aadir grfica
Imprimir grfica
Documentacin formal de casos de uso

La interaccin del usuario con el sistema la esquematizaremos a travs de la documentacin
formal de los casos de uso segn el Lenguaje de Modelado Unificado (UML).
En esta representacin se presentan una serie de atributos que se detallan a continuacin.
Actor: Se llama as a toda entidad externa al sistema que interacciona con l. Por ejemplo,
pidiendo una funcionalidad. No necesariamente tiene que ser una persona, en ocasiones se
representan sistemas externos.
Relacin de asociacin: Indica la participacin del actor en el caso de uso.
Relacin de extensin (extend): Se define como la relacin de dependencia entre dos casos de
uso en la cual se aporta alguna funcionalidad extra. El caso de uso principal puede funcionar
(aunque sin la funcionalidad extra) sin el caso de uso secundario.
Relacin de inclusin (include): Esta propiedad es similar al anterior, a diferencia de que una
relacin de inclusin obliga a que el conjunto del proceso (todos los casos de uso que se
comunican) sean llamados. En otras palabras, el caso de uso principal no puede funcionar si el
segundo.
Puntos de extensin: Los puntos de extensin pueden corresponderse a la enumeracin de
pasos en el caso de uso base, as los casos de uso extendidos pueden extender cualquier a de
dichos pasos.
Escenario: Representa el flujo exitoso ms simple. Pueden existir escenarios alternativos o de
excepcin.


Ilustracin 12 Componentes en la representacin de casos de uso
En esta primera tabla realizaremos una clasificacin de los casos de uso organizados por
subsistema:
Caso de uso
Subsistema Cdigo Descripcin
Gestin de usuarios GU_CU_001 Conexin
GU_CU_002 Comprobacin permisos
GU_CU_003 Lista de usuarios
GU_CU_004 Alta de usuario
GU_CU_005 Modificacin de usuarios
GU_CU_006 Baja de usuario

Informacin CMMI CM_CU_001 Lista de objetivos genricos
CM_CU_002 Alta de objetivo genrico
CM_CU_003 Baja de objetivo genrico
CM_CU_004 Modificacin de objetivo genrico
CM_CU_005 Lista de prcticas genricas
CM_CU_006 Alta de prcticas genricas
CM_CU_007 Baja de prcticas genricas
CM_CU_008 Modificacin de prcticas genricas
CM_CU_009 Lista de categoras de reas de proceso
CM_CU_010 Alta de categora de reas de proceso
CM_CU_011 Baja de categoras de reas de proceso

CM_CU_012 Modificacin de categoras de reas de proceso
CM_CU_013 Lista de niveles de madurez
CM_CU_014 Alta de niveles de madurez
CM_CU_015 Baja de niveles de madurez
CM_CU_016 Modificacin de niveles de madurez
CM_CU_017 Lista de reas de proceso
CM_CU_018 Alta de reas de proceso
CM_CU_019 Baja de reas de proceso
CM_CU_020 Modificacin de reas de proceso

Gestin de proyectos candidatos PJ_CU_001 Lista
PJ_CU_002 Alta de roles
PJ_CU_003 Baja de roles
PJ_CU_004 Modificacin de roles
PJ_CU_005 Lista de departamentos
PJ_CU_006 Alta de departamentos
PJ_CU_007 Baja de departamentos
PJ_CU_008 Modificacin de departamentos
PJ_CU_009 Lista de proyectos
PJ_CU_010 Alta de proyecto
PJ_CU_011 Baja de proyecto
PJ_CU_012 Modificacin de proyecto
PJ_CU_013 Lista de equipos de proyecto
PJ_CU_014 Alta de equipo de proyecto
PJ_CU_015 Baja de equipo de proyecto
PJ_CU_016 Modificacin de equipos de proyecto

Tareas de revisin y cobertura RV_CU_001 Lista de tipos de revisiones
RV_CU_002 Alta de tipos de revisiones
RV_CU_003 Baja de tipos de revisiones
RV_CU_004 Modificacin de tipo de revisiones
RV_CU_005 Lista de tareas de revisin
RV_CU_006 Alta de tareas de revisin

RV_CU_007 Baja de tarea de revisin
RV_CU_008 Modificacin de tarea de revisin
RV_CU_009 Lista de coberturas de tarea
RV_CU_010 Alta de cobertura de tarea
RV_CU_011 Baja de cobertura de tarea
RV_CU_012 Modificacin de cobertura de tarea

Revisiones y evidencias EV_CU_001 Matriz de revisiones
EV_CU_002 Generar revisiones
EV_CU_003 Cambiar estado revisiones
EV_CU_004 Aadir evidencias
EV_CU_005 Eliminar evidencia
EV_CU_006 Modificar evidencia
EV_CU_007 Consultar PIIDB
EV_CU_008 Aadir incidencia-accin correctiva
EV_CU_009 Consultar incidencias-acciones correctivas
EV_CU_010 Cambiar estado incidencia-accin correctiva

Indicadores IN_CU_001 Consultar indicador/Grfica
IN_CU_002 Imprimir indicador/Grfica
IN_CU_003 Aadir indicador
IN_CU_004 Eliminar indicador



Subsistema de gestin de usuarios

Caso de uso GU_CU_001
Nombre Conexin al sistema
Requerimiento relacionado RF_0.1
Actores Todos los actores
Precondicin Acceder a la URL de conexin de la aplicacin
Postcondicin El usuario es validado y se conocen los permisos para mostrar
los mens (a travs del GU_CU_002)
Escenario principal El actor accede a la URL de la aplicacin e introduce su usuario
y contrasea. El sistema valida las credenciales y el actor
accede al sistema con los mens a los cuales ha sido
autorizado.
Escenario secundario La validacin de credenciales ha sido incorrecta. El sistema
devuelve un mensaje indicando el problema.

Nombre Validar credenciales y obtener permisos
Actores Todos los actores
Precondicin Ha sido llamado por el caso de uso GU_CU_001
Postcondicin El usuario es validado y se conocen los permisos. El men de la
aplicacin se estructura en base a estos permisos.
accede al sistema con los mens a los cuales ha sido
autorizado.
Escenario secundario La validacin de credenciales ha sido incorrecta. El sistema
devuelve cdigo de error al GU_CU_001.



Nombre Lista de usuarios
Actores Administrador
Precondicin Credenciales correctas y acceso al men de usuarios.
Postcondicin Se le muestra una lista de los usuarios dados de alta en el
sistema. El usuario ha gestionado (consultado, modificado o
dado de baja algn usuario)
accede al men de usuarios.
Escenario secundario -

Nombre Alta de usuario
Precondicin El caso de uso ha sido llamado por GU_CU_003
Postcondicin Se ha dado de alta un nuevo usuario en el sistema
Escenario principal El actor accede al formulario de alta de usuarios, completa los
campos obligatorios y guarda el registro.
Escenario secundario El usuario que quiere dar de alta existe. El sistema le muestra
un mensaje de aviso.

Nombre Baja de usuario
Postcondicin El usuario se elimina (lgicamente) del sistema.
Escenario principal EL usuario accede a la lista de usuarios, selecciona un usuario y
pulsa la opcin para darlo de baja.


Nombre Modificacin de usuario
Postcondicin Alguna propiedad del usuario ha sido modificada.
Escenario principal EL usuario accede a la lista de usuarios, selecciona un usuario y
pulsa la opcin para editarlo. Posteriormente lo guarda



Diagrama de casos de uso del subsistema de conexin

Ilustracin 13 Casos de uso subsistema conexin



Subsistema de informacin CMMI
* Todos los casos de uso del subsistema CMMI son similares. Se detalla un ejemplo de
mantenimiento de una entidad.
Caso de uso CM_CU_001
Nombre Lista de objetivos genricos
Actores Experto CMMI
Precondicin Credenciales correctas y acceso al men Lista de o.g.
Postcondicin Se le muestra una lista de los objetivos genricos definidos en
el sistema. El usuario ha gestionado (consultado, modificado o
dado de baja algn objetivo genrico)
accede al men CMMI Objetivos genricos.

Nombre Alta de objetivo genrico
Precondicin El caso de uso ha sido llamado por CM_CU_001
Postcondicin Se ha dado de alta un nuevo objetivo genrico
Escenario principal El actor accede al formulario de alta de objetivos genricos,
completa los campos obligatorios y guarda el registro.
Escenario secundario El objetivo genrico que quiere dar de alta existe. El sistema le
muestra un mensaje de aviso.



Nombre Baja de objetivo genrico
Postcondicin El objetivo genrico se elimina (lgicamente) del sistema
Escenario principal EL usuario accede a la lista de objetivos genricos, selecciona
uno y pulsa la opcin para darlo de baja.

Nombre Modificacin de un objetivo genrico
Postcondicin Alguna propiedad del objetivo genrico ha sido modificada.
Escenario principal EL usuario accede a la lista de objetivos genricos, selecciona
uno y pulsa la opcin para editarlo. Posteriormente lo guarda


Diagrama de casos de uso del subsistema CMMI

Ilustracin 14 Casos de uso del subsistema CMMI


Subsistema de gestin de proyectos candidatos
Caso de uso PJ_CU_009
Nombre Lista de proyectos candidatos
Actores Administrador, Lder equipo CMMI
Precondicin Credenciales correctas y acceso al men Lista de proyectos
Postcondicin Se le muestra una lista de los proyectos definidos en el
dado de baja algn proyectos )
accede al men CMMI proyectos candidatos

Nombre Alta de proyectos candidatos
Precondicin El caso de uso ha sido llamado por PJ_CU_001
Postcondicin Se ha dado de alta un nuevo proyectos candidatos
Escenario principal El actor accede al formulario de alta de proyectos candidatos,
Escenario secundario El proyecto candidatos que quiere dar de alta existe. El sistema
le muestra un mensaje de aviso.



Nombre Baja de proyectos candidatos
Postcondicin El proyecto candidatos se elimina (lgicamente) del sistema
Escenario principal EL usuario accede a la lista proyectos candidatos, selecciona

Nombre Modificacin de un proyecto candidato
Postcondicin Alguna propiedad del proyecto candidatos ha sido modificada.
Escenario principal EL usuario accede a la lista de proyectos candidatos, selecciona
uno y pulsa la opcin para editarlo. Posteriormente lo guarda


Diagrama de casos de uso del subsistema de proyectos candidatos

Ilustracin 15 Casos de uso de Proyectos
Subsistema de configuracin de tareas y coberturas
Caso de uso RV_CU_001
Nombre Lista de tipos de revisiones
Actores Administrador, Revisor CMMI
Precondicin Credenciales correctas y acceso al men Lista de tipos de
revisiones.
Postcondicin Se le muestra una lista de los tipos de revisiones definidos en el
dado de baja algn tipo de revisin)
accede al men CMMI Tipos de revisiones.


Nombre Alta de un tipo de revisin
Precondicin El caso de uso ha sido llamado por RV_CU_001
Postcondicin Se ha dado de alta un nuevo tipo de revisin
Escenario principal El actor accede al formulario de alta de tipos de revisiones,
Escenario secundario El tipo de revisin que quiere dar de alta existe. El sistema le
muestra un mensaje de aviso.

Nombre Baja de tipo de revisin
Postcondicin El tipo de revisin se elimina (lgicamente) del sistema
Escenario principal EL usuario accede a la lista de tipos de revisiones, selecciona



Nombre Modificacin de un tipo de revisin
Postcondicin Alguna propiedad del tipo de revisin ha sido modificada.
Escenario principal EL usuario accede a la lista de tipos de revisin, selecciona uno
y pulsa la opcin para editarlo. Posteriormente lo guarda

Diagrama de casos de uso del subsistema de tareas y coberturas

Ilustracin 16 Casos de uso tareas y coberturas



Subsistema de revisiones y evidencias
* Se describen los ms representativos.
Caso de uso EV_CU_001
Nombre Matriz de revisiones
Actores Revisor CMMI
Precondicin Credenciales correctas y acceso al men Matriz de revisiones
Postcondicin El revisor CMMI ha podido consultar una matriz en la que
figuran los diferentes proyectos y las tareas que requieren
revisin. Cada una de las tareas est identificada con un color
para diferenciar el estado (Pendiente de revisin, Correcta,
Pendiente de accin correctiva o No evaluable. Los diferentes
registros de revisiones tienen disponible acciones:
Asignar/modificar/eliminar una evidencia a la revisin,
Generar ms revisiones o Cambiar el estado de una revisin.
accede a la matriz de revisiones. En esta matriz, el revisor
puede consultar los diferentes proyectos y las tareas que
requieren revisin. Cada una de las tareas est identificada con
un color para diferenciar el estado (Pendiente de revisin,
Correcta, Pendiente de accin correctiva o No evaluable. Los
diferentes registros de revisiones tienen disponible acciones:
Asignar/modificar/eliminar una evidencia a la revisin,
Generar ms revisiones o Cambiar el estado de una revisin


Nombre Generar revisiones
Precondicin El caso de uso ha sido llamado por EV_CU_001
Postcondicin Las tareas de revisin han sido generadas.
Escenario principal El revisor entra en la pantalla de matriz de tareas y selecciona
la opcin de este caso de uso. A continuacin especifica los
criterios para los cuales quiere generar la matriz de revisiones.
Entre ellos:
Intervalo de fechas
Proyectos incluidos
rea de cobertura (por ejemplo, slo tareas que
pertenezcan al rea de gestin de proyectos).
Escenario secundario

Nombre Cambiar estado de una revisin
Postcondicin Se ha cambiado el estado de una revisin
Escenario principal El revisor accede a la matriz de revisiones. A continuacin
escoge un registro y selecciona este caso de uso. Se le
proporciona una pantalla de tipo detalle con la posibilidad de
cambiar el estado a uno de los posibles:
- Pendiente de revisin (estado inicial)
- Pendiente de accin correctiva
- Correcta
- Incorrecta
- No procede revisin



Nombre Aadir una evidencia
Postcondicin Se ha aadido una evidencia
Escenario principal El revisor accede a la matriz de revisiones. A continuacin
escoge un registro y selecciona este caso de uso. Se le
proporciona una pantalla de tipo detalle con la posibilidad de
aadir los siguientes datos:
- URL a una direccin que proporcione una visin de la
evidencia
- Una carpeta dentro de la red donde exista la evidencia
- Un comentario del revisor


Nombre Aadir una incidencia y accin correctiva
Precondicin El caso de uso ha sido llamado por EV_CU_001 o EV_CU_009
Postcondicin Se ha aadido una nueva incidencia asociada a la revisin.
Escenario principal El revisor accede a la matriz de revisiones o al buzn de
incidencias. A continuacin escoge un registro y selecciona este
caso de uso. Se le proporciona una pantalla de tipo detalle (con
la informacin de la tarea ms relevante) con la posibilidad de
aadir los siguientes datos:
- Descripcin de la incidencia
- Descripcin de la accin correctiva
- Destinatario de la incidencia (debe ser un miembro del
equipo para el cual se est efectuando la revisin)


Nombre Buzn de incidencias
Actores Revisor CMMI, Miembro de un equipo de proyecto
Precondicin
Postcondicin El usuario consulta, cambia de estado o aade una nueva
incidencia o responde a una incidencia creada por el revisor
Escenario principal Si el revisor accede a esta funcionalidad, se le muestran todas
las incidencias que l ha reportado en todos los proyectos. A
partir de ah podr acceder a aadir nuevas o cambiar el
estado.
Para un miembro de proyecto, nicamente se le mostrarn las
incidencias que hayan sido asignadas a l para que pueda
responderlas o reasignarlas a otro miembro de su proyecto.


Diagrama de casos de uso del subsistema de revisiones y evidencias.

Ilustracin 17 Diagrama de casos de uso del subsistema de revisiones y acciones correctivas
Subsistema de cuadro de mandos e indicadores
Caso de uso IN_CU_001
Nombre Dashboard de indicadores
Actores Lder CMMI, Administrador
Precondicin Disponer de permisos en la opcin
Postcondicin El usuario puede visualizar diferentes grficas sobre el estado
de la implantacin
Escenario principal El lder de la implantacin CMMI accede a la aplicacin y en la
primera pantalla se le muestra una serie de grficas que l
mismo ha seleccionado para tener en la pantalla del
dashboard. Se trata de un dashboard adaptable mediante
portlets.
Las graficas iniciales de este proyecto son:

Estado de las revisiones (Grfico tarta con porcentajes:
Revisado, pendientes, En espera
N de incidencias vs Nmero de revisiones
Grfico de nivel de cobertura en la organizacin
Grfico de cumplimiento de tareas por proyecto

Diagrama de casos de uso del subsistema de cuadro de mandos.

Ilustracin 18 Casos de uso Cuadro de mandos


Modelo esttico: Diagrama de clases

Modelo CMMI DEV 1.3

Ilustracin 19 Diagrama de clases CMMI



Documentacin de ejemplo

El modelo expuesto anteriormente debe ser capaz de almacenar esta informacin con la
misma estructura.

Ilustracin 20 Ejemplo informacin CMMI


Ilustracin 21 Ejemplo Informacin CMMI (Cont.)



Ilustracin 22 Ejemplo Informacin CMMI (Cont.)



Coberturas, tareas de revisin, proyectos e incidencias

Ilustracin 23 Diagrama de clases Revisiones


Diseo del sistema
Una vez nuestro producto ha sido analizado desde el punto de vista de requisitos deberemos
marcar las directivas tecnolgicas para poder desarrollarlo. A esta etapa en el ciclo de vida se le
denomina Diseo tcnico.
Hemos visto, en la etapa de anlisis, que existen una serie de requisitos no funcionales que de
alguna manera ya pueden marcar la tecnologa que deberemos usar, las restricciones o lmites
del sistema, a qu aspecto debemos dar prioridad y a cual podemos dejar en un segundo plano
o aspectos de tipo cualitativo que pueden tenerse en cuenta a la hora de tomar las decisiones
de arquitectura y tecnolgicas. Otro aspecto a considerar y que no est dentro de este anlisis
es el aspecto econmico, pues ste lo trataremos en un apartado diferente.
Vamos a considerar cada una de las partes definidas en la fase anterior y realizar una
correspondencia tecnolgica. De esta manera enlazaremos qu queremos hacer con el cmo
lo haremos.
A continuacin mencionamos una serie de caractersticas que hemos considerado en este
diseo para que el resultado sea el ms ptimo posible:
1. Diseo econmico
Como hemos mencionado anteriormente, nuestro diseo no prioriza los aspectos econmicos
para el estudio de diseo. Sin embargo, nuestro proyecto no presenta ninguna caracterstica
diferencial que pueda incidir en costes altos. El uso de tecnologa libre que est al alcance de
todos permite tomar decisiones eficaces y con presupuestos totalmente asequibles.
2. Diseo eficaz
Hemos intentado disear todas las funcionalidades descritas en la fase de anlisis para
garantizar el cumplimiento y la eficacia global del sistema. No obstante, por restricciones
temporales hemos dejado algunas funcionalidades menos importantes sin disear. Esto no
supone un problema dado que estas funcionalidades corresponden a mantenimientos
similares y deben implementarse de igual manera al resto de mantenimientos.



3. Diseo eficiente
Las funcionalidades se disearn siguiendo los procedimientos marcados por las buenas
prcticas y siguiendo las metodologas de diseo orientada a objetos. De esta manera se
garantiza que la respuesta al usuario sea la ms correcta posible en trminos funcionales y de
rendimiento.
4. Diseo robusto
La arquitectura escogida, como veremos a continuacin, permite dotar al sistema de la
robustez suficiente como para soportar la magnitud de usuarios y datos necesarios y en el
entorno que se usar.
5. Diseo fiable
Siguiendo la metodologa de diseo orientado a objetos podemos garantizar que obtendremos
un producto con un alto grado de fiabilidad. No obstante, llevando a cabo las pruebas unitarias
y las pruebas de casos de uso, podramos obtener un 100%. Cabe mencionar en este caso, que
el marco de nuestro proyecto no contempla el desarrollo ni un plan de test en cualquiera de
sus niveles (alto nivel, pruebas unitarias, pruebas de caso de uso, etc.).
6. Diseo fcil de mantener
Las buenas prcticas en el desarrollo de software, las metodologas de diseo orientado a
objetos y la arquitectura escogida nos permiten garantizar un sistema dotado de un alto grado
de facilidad en trminos de mantenimiento. Veremos que la arquitectura 3 capas nos permite
separar la presentacin, la lgica de negocio y la capa de base de datos, y de esta manera
facilitar, entre otros, aspectos de mantenimiento.
7. Diseo multiplataforma
Las decisiones tecnolgicas escogidas, como veremos a continuacin, nos permiten adaptar
nuestro producto a mltiples plataformas.
8. Diseo fcil de usar
Uno de los aspectos claves es la facilidad de uso. La aplicacin de directrices de usabilidad que
se han estudiado en la carrera son aplicadas en este proyecto.


Decisiones de arquitectura
Entre las necesidades no funcionales de la solucin, junto con algunos aspectos que hemos
considerado importantes en esta fase, vamos a destacar algunos:
Solucin WEB.
Generalmente se usar en un entorno Intranet.
Puede llegar a integrarse con otras aplicaciones (Aplicaciones Ticketing para
incidencias o o LDAP para la gestin de usuarios).
Fcil de mantener
Econmica, dado que es un coste indirecto en el marco de un proyecto de
implantacin. Es una herramienta que dar apoyo, no puede ser ms cara la
herramienta que el propio proyecto.
De entre las soluciones que hemos estudiado, hemos decidido adoptar la siguiente tecnologa:
Patrn de diseo Modelo Vista Controlador (MVC)
El patrn MVC, introducido como parte de la versin SmallTalk-80 del lenguaje de
programacin SmallTalk, presenta las siguientes ventajas:
Clara separacin entre los componentes permitiendo la implementacin por separado.
La conexin entre el modelo y sus vistas es dinmico, lo cual permite que los cambios
se produzcan en tiempo de ejecucin, no de compilacin.
El patrn MVC, como hemos mencionado, nos permite separar la presentacin, la lgica de
negocio y los datos en tres componentes distintos. Este componente es adecuado para
entornos Web donde la vista es la propia pgina HTML, el modelo es el Sistema de Gestin de
Base de Datos (SGBD) y el controlador es el responsable de recibir los eventos de entrada de la
vista.


En ms detalle, disponemos de los siguientes componentes:
Modelo: Es la representacin especfica de la informacin con la que interacta el
sistema. Gestiona los datos y controla todas sus transformaciones
Vista: El modelo que hemos extrado a travs de su controlador, es presentado al
usuario a travs de este componente.
Controlador: Los eventos del sistema, generalmente iniciados por el usuario, son
gestionados por este componente, que a su vez invoca a llamadas al controlador o
incluso a la vista.
Lenguaje de desarrollo: PHP
Uno de los lenguajes de programacin ms usados para el desarrollo web es el lenguaje PHP.
PHP fue creado originalmente por Rasmus Lerdof en 1995 y dispone de una licencia con su
propio nombre. Esta licencia, de acuerdo con la Free Software Foundation, es una licencia de
software libre no copyleft y una licencia de cdigo abierto segn la Open Source Initiative.
En otros trminos, la licencia PHP est diseada para incentivar la distribucin del cdigo
fuente. Se permite la redistribucin del contenido licenciado en forma cdigo fuente o binaria
siempre y cuando se cumplan los siguientes requisitos:
1. Se incluya la declaracin de los derechos de autor de la licencia PHP.
2. La palabra PHP no se use en el ttulo de las obras derivadas.
3. Se incluya el siguiente anuncio bajo cualquier forma en la que se redistribuya el cdigo.

Ms all de aspectos legales de distribucin y licencia, vamos a describir algunas de sus
caractersticas ms importantes y las cuales encajan perfectamente con los requisitos de
nuestra solucin.
Orientado al desarrollo de aplicaciones Web.
Es considerado un lenguaje fcil de aprender.
Permite la conexin con una gran variedad de gestores de bases de datos (SGBDs),
destacando MySQL y PostgreSQL.
Escalable por medio de extensiones (exts).
Libre y accesible.
Permite la aplicacin de tcnicas de programacin orientada a objetos.


Sistema gestor de base de datos: MySQL
Para la persistencia de los datos, hemos escogido un sistema gestor de base de datos relacional
denominado MySQL.
MySQL est patrocinado por una empresa privada (Sun MicroSystems) que posee el copyright y
de la mayor parte del cdigo. Por un lado, se ofrece bajo la GNU GPL para cualquier uso
compatible con esta licencia, pero para aquellas organizaciones que necesiten incorporarlo en
productos privativos debern adquirir a la empresa una licencia especfica que les permita ese
uso.
Pese a que MySQL inicialmente careca de caractersticas que se hacen importantes en los
sistemas gestores de bases de datos como pueden ser la gestin de transacciones o la
integridad referencial, poco a poco, y en la actualidad podemos destacar, junto a su
simplicidad, algunos de los siguientes aspectos:
Utilizacin del lenguaje SQL en su inmensa mayora.
Disponible en mltiples plataformas y sistemas
Caractersticas para asegurar la integridad referencial (claves forneas, transacciones).
Conectividad segura.
Bsqueda e indexacin de campos de texto.



Integracin mediante un FrameWork de desarrollo: Yii
Hemos mencionado los diferentes componentes que contendr la arquitectura de nuestro
producto CMMI-UP. Ahora bien, en la actualidad, existen numerosos marcos de desarrollo que
nos permiten unir los diferentes componentes de la arquitectura, y que nos ayudan a la
implementacin siguiendo procedimientos y metodologa sobre una base conceptual y
tecnolgica de soporte definido. En realidad, representa la integracin de todos los
componentes antes mencionados, y modela las relaciones y provee una base sobre la cual
implementaremos nuestra solucin.
Es el caso del marco de trabajo YII, el cual nos permitir integrar los diferentes componentes
que hemos mencionado siguiendo una metodologa definida de trabajo
Entre las caractersticas del framework YII podemos encontrar las siguientes:
Diseo con patrones MVC
Uso de objetos para el acceso a base de datos (DAO)
Entrada y validacin de formularios
Widgets AJAX para mltiples usos: Autocompletar, treeviews, calendarios, etc.
Skinning y theming ,permite customizar el interface de usuario
Web Services para integracin con sistemas
Manejo de errores y excepciones
Internacionalizacin i18N para la traduccin de literales
Generacin automtica de cdigo para CRUD (Create, Update, Delete)
Incorporacin de extensiones de terceros



Estructura esttica de la aplicacin

Ilustracin 24 Diagrama de la estructura de la aplicacin


Flujo de trabajo genrico de la aplicacin

Ilustracin 25 Flujo a travs de los componentes
1. Un usuario realiza una solicitud a travs del explorador, con la siguiente
URL http://www.cmmiup.com/index.php?r=post/show&id=1 y el servidor Web se
encarga de la solicitud mediante la ejecucin del script de arranque en index.php.
2. El script de entrada crea una instancia del componente application y la ejecuta.
3. La aplicacin obtiene la informacin detallada del pedido del usuario del componente
de aplicacinrequest.
4. A travs del componente urlManager se determina el controlador y la accin pedido .
5. La aplicacin crea una instancia del controlador pedido para resolver la solicitud del
usuario. El controlador determina que la accin refiere al nombre de
mtodo correspondiente en la clase controlador. Entonces crea y ejecuta los filtros
asociados con esta accin (ejemplo: control de acceso, benchmarking). La accin es
ejecutado si los filtros lo permiten.
6. La accin lee el modelo y accede a base de datos.
7. La accin realiza la vista llamada con el modelo.
8. La vista lee y muestra los atributos del modelo.
9. La vista ejecuta algunos widgets.
10. El resultado realizado es embebido en un esquema (layout).
11. La accin completa la vista realizada y se la muestra al usuario.


Esquema general de la arquitectura CMMI-UP
Una vez hemos identificado los diferentes s componentes tecnolgicos sobre los cuales
disearemos e implementaremos la solucin, vamos a ver un esquema general de la
arquitectura CMMI-UP.

Ilustracin 26 Esquema general de la arquitectura



Modelo esttico : Diagrama de clases

Modelo CMMI DEV 1.3

Ilustracin 27 Diagrama de clases CMMI



Coberturas, tareas de revisin, proyectos e incidencias

Ilustracin 28 Diagrama de clases Revisiones


Clases frontera y gestoras CMMI Core
Cabe destacar que las clases frontera de tipo CRUD (Create, Update, Delete) o ABM (Alta, Baja,
Modificacin) se descomponen a su vez en diferentes tipologas de vistas segn el propsito.

Ilustracin 30 Detalle de la relacin de componentes modelo, vista, controlador
Ilustracin 29 Clases frontera y gestoras CMMI Core


Clases frontera y gestoras CMMI Proyectos, revisiones incidencias

Ilustracin 31 Clases frontera y gestoras CMMI Proyectos revisiones e incidencias


Diseo de casos de uso : Diagramas de actividad de procesos

A continuacin realizaremos el diseo de los casos de uso, aportando, en primer lugar unos
diagramas de actividad para mostrar el flujo de un proceso entre los diferentes casos de uso.
De esta manera, estamos mostrando el negocio desde el punto de vista del usuario, en el que
pueden intervenir diferentes casos de uso, y posteriormente ver cmo estn diseados los
casos de uso ms relevantes que intervienen en estos procesos.


Subsistema de conexin: Gestin de usuarios

Ilustracin 32 Diagrama de actividad para la gestin de usuarios

Accin del diagrama de actividad Caso de uso relacionado
Inicio: Conexin GU_CU_001: Conexin
Validar credenciales GU_CU_002: Validar credenciales
Men: Lista de usuarios GU_CU_003: Lista de usuarios
Alta de usuario GU_CU_004: Alta de usuario
Baja de usuario GU_CU_005: Baja de usuario
Modificacin GU_CU_006: Modificacin
Fin


Subsistema de revisiones e incidencia: Proceso de revisin de una incidencia
A continuacin veremos un diagrama de actividad para ver cmo intervienen los diferentes
casos de uso en la revisin de una incidencia. Posteriormente, realizaremos un diagrama de
secuencia de los ms relevantes.

Ilustracin 33 Diagrama de actividad para la revisin de una tarea
En el proceso de revisin, el usuario accede a una lista (previamente generada) en la que
puede seleccionar un registro correspondiente a una tarea encomendada a un proyecto
determinada. El objetivo es poder revisar dicha tarea y posteriormente decidir si sta ya ha
sido completada o bien tiene algn tipo de incidencia.
Como vemos, la relacin de casos de uso que intervienen son:
Inicio EV_CU_001: Matriz de revisiones
Abrir detalle del registro EV_CU_006: Modificar revisin (corregir diagrama de caso de uso en AF)
Cambiar estado EV_CU_003: Cambiar estado
Abrir incidencia/Accin correctiva EV_CU_008: Aadir INC/AC
Seleccionar destinatario incidencia EV_CU_008: Aadir INC/AC
Enviar guardar incidencia EV_CU_008: Aadir INC/AC
Guardar revisin EV_CU_006: Modificar revisin


Subsistema de revisiones e incidencia: Proceso de incorporacin de una evidencia
A continuacin veremos un diagrama de actividad para ver cmo intervienen los diferentes
casos de uso en la revisin de una incidencia. Posteriormente, realizaremos un diagrama de
secuencia de los ms relevantes

Ilustracin 34 Diagrama de actividad para insertar evidencias
Inicio EV_CU_001: Matriz de revisiones
Abrir detalle del registro EV_CU_006: Modificar revisin (corregir diagrama de caso de uso en AF)
Seleccionar tipo evidencia EV_CU_004: Aadir evidencia
Examinar directorios EV_CU_004: Aadir evidencia
Seleccionar fichero EV_CU_004: Aadir evidencia
Escribir URL EV_CU_004: Aadir evidencia
Guardar revisin EV_CU_006: Modificar revisin


Diseo de casos de uso : Diagramas de secuencia
En los diagramas de secuencia, se modela la interaccin y los mensajes que intercambian los
diferentes objetos que intervienen en un proceso o caso de uso. Todo ello, mostrado en una
secuencia temporal.
En CMMI-UP existen multitud de mantenimientos de tipo ABC (alta, baja, modificacin) o
CRUD (Create, Update, Delete). Para este tipo de mantenimientos, mostraremos un diagrama
de secuencia genrico, que puede ser aplicado en todos ellos, dado que al estar trabajando con
un framework, este tipo de implementaciones se realiza con un mismo procedimiento. En
cambio, para aquellos proceso ms representativos, mostraremos un diagrama de secuencia
concreto.



Diagrama de secuencias para casos de uso tipo Listas

Ilustracin 35 Diagrama de secuencia para listas
La secuencia habitual para mostrar la lista es la siguiente:
1. El usuario selecciona la opcin correspondiente en el men de usuarios de la
aplicacin
2. A travs de un componente genrico (omitido para resumir el diagrama) se
determina cul es el controlador asociado al evento disparado por el usuario.
3. A continuacin se crea una nueva instancia del controlador.
4. El controlador recupera la lista de permisos para saber si el usuario puede acceder a la
opcin.
5. En caso afirmativo se accede al mtodo de bsqueda correspondiente en modelo de la
entidad (en este caso Users.Search() para recuperar los datos.
6. Al recuperar los datos, el controlador enva el objeto recuperado para rendelizarlo a
travs del componente vista.
7. En caso de que el usuario no tenga permisos para acceder a la opcin, se informa al
usuario mediante un mensaje genrico

Diagrama de secuencias para casos de uso tipo Alta

Ilustracin 36 Diagrama de secuencia para Altas
La secuencia habitual es parecida a la anterior:
aplicacin
opcin.
5. En caso afirmativo se crea una nueva instancia de la entidad y se renderiza el
formulario para inicializar los campos a rellenar por parte de el usuario.
6. El usuario rellena los datos, se validan los campos y sus atributos y pulsa el botn
Guardar.
7. El controlador interpreta el evento y lanza un nuevo mtodo en el modelo para
almacenar el objeto usuario en la base de datos.

Diagrama de secuencias para casos de uso tipo Baja

Ilustracin 37 Diagrama de secuencias para 'bajas'
La secuencia es la siguiente:
aplicacin
opcin.
5. En caso afirmativo se crea una nueva instancia de la entidad y se renderiza la lista de
usuarios con los datos proporcionados por el modelo.
6. El usuario edita el registro y pulsa el botn Baja.
7. El controlador interpreta el evento y lanza la instruccin correspondiente al modelo, el
cual, determinar previamente si no afecta a la integridad referencial de los datos. En

caso de que no afecte, borrar el registro. En caso contrario, mostrar un mensaje al
usuario.
Diagrama de secuencias para casos de uso tipo DashBoard

Ilustracin 38 Diagrama de secuencia para Dashboard
La secuencia es la siguiente:
1. El usuario accede a la aplicacin a travs del login.
4. El controlador recupera la lista de permisos para saber si el usuario puede visualizar el
dashboard.
5. En caso afirmativo se crea una nueva instancia de la entidad (la entidad Dashboard no
es persistente) y se llama al mtodo correspondiente para que realiza las diferentes
consultas en base de datos.
6. Devuelve los diferentes dato para que sean renderizados por el componente vista.


Diseo E/R CMMI Core

Ilustracin 39 E-R CMMI Core

Diseo de la interfaz grfica
Pantalla principal y men

Ilustracin 40 Prototipo pantalla Men
La pantalla principal presenta un aspecto tpico con un men de opciones horizontal clsico.
Cabe destacar la posibilidad que nos brinda el framework de desarrollo en adaptar diferentes
temticas (themes) que nos permiten adecuar el look & feel segn requerimientos de cliente
de una manera fcil.


Login

Ilustracin 41 Prototipo Pantalla Login
La pantalla de acceso a la aplicacin permite la entrada y la validacin de la contrasea as
como las opciones clsicas de recuperacin de contrasea o la de habilitar el recordatorio de
usuario.


DashBoard

Ilustracin 42 Prototipo DashBoard
Una vez el usuario se ha validado, la pantalla principal se sita en el caso de uso DashBoard,
que permitir tener una visin global de los diferentes grficos y que, de una manera visual, el
usuario puede conocer el estado de la implantacin CMMI.

Pantallas CMMI: Core

Ilustracin 43 Prototipo lista de Categoras
Las pantallas de tipo listas, en los mantenimientos, siempre presentan un aspectos
homogneo. En este caso, los colores son configurables y permiten diferenciar las reas de
proceso de CMMI.



Ilustracin 44 Prototipo Alta de Categora
Las pantallas de tipo alta presentan un aspecto similar. Cada uno de los controles ser
implementado segn la informacin que contendr (listas desplegables, selectores de fecha,
cajas de texto, etc.)
Como podemos observar, tambin se indicar con un asterisco los campos obligatorios.


Ilustracin 45 Prototipo lista niveles de Madurez
Las listas tambin presentan la opcin de filtro en la primera lnea y la capacidad de acceder a
los diferentes casos de uso (eliminar, modificar, visualizar) desde la propia lnea.



Ilustracin 46 Prototipo lista reas de proceso
En el mantenimiento de reas de proceso, como podemos observar, se realiza una pantalla de
tipo lista de dos niveles, permitiendo agrupar de este modo por categora.
Obsrvese tambin que los colores nos indican la categora a la que pertenece cada rea de
proceso.



Pantallas CMMI: Proyectos, Roles

Ilustracin 47 Prototipo lista Roles
En esta pantalla podemos gestionar los diferentes roles del equipo de proyectos.

Ilustracin 48 Prototipo lista de proyectos
El mantenimiento de proyectos contiene toda la informacin relevante del proyecto.


Ilustracin 49 Prototipo alta de proyectos



Pantallas CMMI: Revisiones

Ilustracin 50 Prototipo lista tipos de revisiones
Las revisiones permiten definir el intervalo de das que debe pasar entre una revisin y otra.
Posteriormente asociaremos este tipo de revisin a una tarea determinada.

Ilustracin 51 Prototipo lista tareas de revisin
Como vemos, aqu ya estn asociados los tipos de revisiones a las diferentes tareas.


Ilustracin 52 Prototipo Alta de tareas de revisin


Ilustracin 53 Prototipo matriz de revisiones
Esta es la pantalla principal que usar el revisor CMMI para ir revisando las tareas
encomendadas a los diferentes proyectos. En l puede observarse la evidencia, el estado de la
revisin (con diferentes colores), el proyecto y la tarea que debera haber realizado.


Ilustracin 54 Prototipo lista de cobertura de tareas
En esta pantalla se permite definir la cobertura de cada tarea. De esta manera, a medida que
se van realizando las tareas se puede obtener una visin del alcance obtenido en la
implantacin de una manera real.



Ilustracin 55 Prototipo calendario de revisiones
El calendario permite tener una visin general de las tareas que debe revisarse en un intervalo
de tiempo. Desde el propio calendario tambin puede acceder a cambiar el estado de una
revisin o asignarle evidencias a una tarea.



Valoracin econmica

En este apartado, hemos considerado apropiado realizar una valoracin econmica del trabajo
realizado y una estimacin del trabajo pendiente de realizar, como puede ser la
implementacin del proyecto de software, las pruebas pertinentes, la implantacin o la
formacin.
Existen diversos estudios y modelos entorno a la valoracin de la construccin del software. No
obstante, varios autores han analizado una aproximacin del coste global de desarrollo de un
proyecto informtico. Estas aproximaciones datan de los aos setenta y comienzos de los
ochenta por autores como Boehm i Brooks y son aceptadas en la actualidad como referencia.
Un 40% del coste de desarrollar una aplicacin se emplea las etapas de anlisis y
diseo.
Un 20% en la etapa de implementacin
El resto, entorno al 40% se emplea en las pruebas.
El costo de mantenimiento que puede representar el doble del coste de implementacin, y el
del hardware, en este caso no se tiene en cuenta.
Una vez recopilado todos los datos necesarios, procederemos a valorar el coste del proyecto.
Para ello nos basaremos en el coste de cada recurso que debiera participar en el proyecto y
tomando como referencia los precios estndar del sector y asumiendo una persona por rol y
tarea, dado que el tiempo de entrega no es un requisito importante en este caso.
Recurso Coste/hora Coste/Jornada
Jefe de proyectos 48 384
Analista 36 288
Analista programador 24 192
Arquitecto 35 280


Recordemos la tabla de actividades desglosadas en el plan de proyecto:
Nota: Pese a que la planificacin temporal se basa en estimaciones de jornadas de 4
horas, en la estimacin econmica hemos tenido en cuenta jornadas de 8 horas para
adecuarlos a los estndares profesionales. Por lo tanto, hemos considerado adecuado
dividir por dos las jornadas detalladas en el planning.

Estimacin por actividades
Actividad Nombre de actividad: Nivel I Jornadas
de 8 horas
Recurso Precio
Jornada
Total
01 PAC1- Plan de proyecto 4 Jefe de proyecto 384 1536
02 PAC2- Especificacin y
anlisis
13 Analista 288 3744
03 PAC3- Diseo del sistema 12,5 Analista-
Programador
192 2400
04 Memoria y presentacin 7,5 Jefe de proyecto 384 2880
05 Programacin y pruebas
unitarias
40 Analista
programador
192 7680
06 Pruebas integradas 15,5 Analista 288 4464
07
1
Formacin a usuarios 1 Analista 288 288
08
2
Adecuacin de datos tareas
vs cobertura CMMI
1,5 Analista
programador
192

288
09 Puesta en produccin 1,5 Arquitecto 280 420
10
3
Final del proyecto 0,5 Jefe de proyecto 384 192
TOTAL 97 23892

1
Aunque no existe formacin explcita, consideramos 1 jornada mnimo para explicar el funcionamiento
del sistema a las personas que comiencen a probar
2
Aunque no existe migracin de datos, estimamos 1 jornada para la revisin de los datos de partida
(tareas y cobertura de tareas).
3
El cierre del proyecto requiere recopilar la documentacin y formalizar el cierre con el cliente

Conclusiones

El proyecto CMMI UP surge de una experiencia real de una implantacin CMMI en una
organizacin, cuya parte de su dedicacin recae en el desarrollo de software. En ocasiones, las
directrices que marca un modelo se siguen de manera extrema, causando una gran
problemtica de alineamiento con los procesos ya implantados y que es posible que ya
funcionen.
La herramienta que proponemos, no garantiza que una implantacin de tal calibre pueda
llegar a buen puerto, sino que pretende evitar los costes indirectos que supone la gestin de la
informacin, las revisiones que acarrean y la obtencin de una visin clara del estado de la
implantacin.
No sera descabellado pensar que este tipo de solucin que hemos abordado, diera un paso
adelante y, abordando el problema desde una perspectiva ms abstracta, podamos reutilizarlo
para implantaciones de tipo ISO, ITIL, etc. ya que posiblemente lo que cambia es la
informacin, no el modelo.
En aspectos econmicos, la solucin presenta un coste relativamente bajo, debido a que no
posee complejos flujos de trabajo ni complejos algoritmos ni pantallas muy sofisticadas. La
simplicidad debe ser un factor clave dado y debe alinearse con las tareas de gestin que
habitualmente llevan a cabo las organizaciones y que generalmente realizan combinando
diferentes herramientas ofimticas. El coste de esta solucin no debe presentar mayores
problemas en incorporarlo en presupuestos globales de implantacin.
En definitiva, el proyecto CMMI UP se presenta como una solucin que mejorar la
productividad de las tareas que conlleva una implantacin de mejores prcticas como es la del
modelo de madurez CMMI y desarrollado bajo la experiencia de una situacin real en la que
pueden verse reflejadas multitud de empresas del sector.



Apndice A: Glosario

Accin correctiva (corrective action) Acciones o actos usados para remediar una situacin,
eliminar un error o ajustar una condicin.
Adaptacin (tailoring) La adaptacin de un proceso hace, modifica o adapta la descripcin de
proceso para un fin particular. Por ejemplo, un proyecto establece su proceso definido
adaptndolo a partir del conjunto de procesos estndar de la organizacin para cumplir los
objetivos,las limitaciones y el entorno del proyecto.
Adecuado (adequate) Esta palabra se usa para que se puedan interpretar las metas y las
prcticas a la luz de los objetivos de negocio de su organizacin. Cuando se usa cualquier
modelo CMMI, se deben interpretar las prcticas de forma que funcionen para su organizacin.
El trmino se usa en las metas y las prcticas donde ciertas actividades pueden no realizarse
siempre (vase tambin apropiado y segn sea necesario).
Adquisicin (acquisition) El proceso consistente en obtener productos (bienes y servicios) a
travs de contrato.
Alcance de la evaluacin (appraisal scope) La definicin de los lmites de la evaluacin que
engloban los lmites de la organizacin y los lmites del modelo CMMI, dentro de los cuales
operan los procesos que van a ser investigados.
Anlisis de requerimientos (requirement analysis) La determinacin del rendimiento y de las
caractersticas funcionales especficas del producto, basndose en el anlisis de las
necesidades, expectativas y restricciones del cliente; en el concepto operativo; en los entornos
de uso proyectados para las personas, los productos y los procesos; y en las medidas de
eficacia.
Anlisis de riesgos (risk analysis) La evaluacin, clasificacin y priorizacin de los riesgos.
Anlisis funcional (functional analysis) Examen de una funcin definida para identificar todas
las subfunciones necesarias para realizarla; identificacin de las relaciones funcionales e
interfaces (internas y externas) y captura de stas en una arquitectura funcional; y transferir los
requerimientos de rendimie nto de mayor nivel y asignacin de estos requerimientos a
subfunciones de menor nivel. (Vase tambin arquitectura funcional).
rea de proceso (process area) Un grupo de prcticas relacionadas en un rea que, cuando se
implementan colectivamente, satisfacen un conjunto de metas consideradas importantes para
hacer mejoras en ese rea. Todas las reas de proceso CMMI son comunes tanto a la
representacin continua como a la representacin por etapas.
Arquitectura del proceso (process architecture) Las relaciones de orden, las interfaces, las
interdependencias y otras relaciones entre los elementos de proceso de un proceso estndar.
La arquitectura de proceso tambin describe las interfaces, las interdependencias y otras
relaciones entre los elementos de proceso y los procesos externos (p. ej., la gestin del
contrato).

Arquitectura funcional (functional architecture) La organizacin jerrquica de las funciones, de
sus interfaces funcionales internos y externos (externos a la propia agregacin) e interfaces
fsicos externos, de sus respectivos requerimientos funcionales y de rendimiento, y de sus
restricciones de dis eo.
Arranque del proyecto (project startup) Cuando un conjunto de recursos interrelacionados se
dirigen a desarrollar o entregar uno o ms productos destinados a un cliente o usuario final.
(Vase tambin proyecto).
Aseguramiento de la calidad (quality assurance) Un modo planificado y sistemtico de
asegurar a la gerencia que se aplican los estndares, prcticas, procedimientos y mtodos
definidos del proceso.
Atributos de producto de trabajo y de tarea (work product and task attributes) Caractersticas
de los productos, servicios y tareas del proyecto usadas para ayudar en la estimacin del
trabajo del proyecto. Estas caractersticas incluyen elementos tales como el tamao, la
complejidad, el peso, la forma, el ajuste y la funcin. Se usan normalmente como una entada
para derivar otras estimaciones del proyecto o de recursos (p. ej., esfuerzo, coste y calendario).
Auditora (audit) En las actividades de mejora de procesos de CMMI, un examen objetivo de un
producto de trabajo o de un conjunto de productos de trabajo frente a criterios especficos (p.
ej., requerimientos).
Calidad (quality) La capacidad de un conjunto de caractersticas inherentes de un producto,
componente de producto o proceso para satisfacer los requerimientos de los clientes.
Calificacin (rating) (Vase calificacin de la evaluacin).
Calificacin de la evaluacin (appraisal rating) Tal y como se usa en los materiales de
evaluacin CMMI, el valor asignado por un equipo de evaluacin a (a) una meta o rea de
proceso CMMI (b) el nivel de capacidad de un rea de proceso o (c) el nivel de madurez de una
unidad de la organizacin. La calificacin se determina aplicando el proceso de calificacin
definido por el mtodo de evaluacin que se est empleando.
Capacidad de proceso (process capability) El rango de resultados esperados que pueden
lograrse siguiendo un proceso.
Ciclo de vida del producto (product lifecycle) El periodo de tiempo, consistente en fases, que
empieza cuando se concibe un producto y termina cuando el producto ya no est disponible
para su uso. Dado que una organizacin puede estar produciendo mltiples productos para
mltiples clientes, una descripcin de un ciclo de vida del producto puede no ser adecuada.
Por tanto, la organizacin puede definir un conjunto de modelos aprobados de ciclo de vida del
producto. Estos modelos se encuentran normalmente en la literatura publicada y es probable
que se adapten para uso en una organizacin. Un ciclo de vida del producto podra constar de
las siguientes fases: (1) concepto/visin (2) viabilidad (3) diseo/desarrollo (4) produccin y (5)
retirada.


Cliente (customer) La parte (individuo, proyecto u organizacin) responsable de aceptar el
producto o de autorizar el pago. El cliente es externo al proyecto (excepto quizs cuando se
usan equipos integrados, como en IPPD), pero no necesariamente externo a la organizacin.
El cliente puede ser un proyecto de mayor nivel. Los clientes son un subconjunto de las partes
interesadas. (Vase tambin partes interesadas). En la mayora de los casos en los que se usa
este trmino, la definicin precedente es la que prevalece. Sin embargo, en algunos contextos,
el trmino cliente pretende incluir a otras partes interesadas relevantes (Vase tambin
Requerimientos de cliente).
CMMI UP Nombre dado al proyecto y al software (producto) en el marco de este proyecto.
Componente de producto (product component) En el Conjunto de productos CMMI, un
producto de trabajo que es un componente de bajo nivel del producto. Los componentes de
producto se integran para producir el producto. Pueden existir varios niveles de componentes
de producto. (Vase tambin producto y producto de trabajo).
Componente del modelo CMMI (CMMI model component) Cualquiera de los principales
elementos arquitectnicos que componen el modelo CMMI. Algunos de los principales
elementos de un modelo CMMI incluyen prcticas especficas, prcticas genricas, metas
especficas, metas genricas, reas de proceso, niveles de capacidad y niveles de madurez.
Componentes CMMI informativos (informative CMMI components) Componentes CMMI que
ayudan a los usuarios del modelo a comprender los componentes requeridos y esperados de
un modelo. Estos componentes pueden contener ejemplos, explicaciones detalladas u otra
informacin til. Las subprcticas, notas, referencias, ttulos de metas, ttulos de prcticas,
fuentes, productos de trabajo tpicos, ampliaciones y elaboraciones de prcticas genricas son
componentes informativos del modelo.
Componentes CMMI requeridos (required CMMI components) Componentes CMMI que son
esenciales para alcanzar la mejora de procesos en un rea de proceso determinada. Estos
componentes se usan en las evaluaciones para determinar la capacidad de proceso. Las metas
especficas y las metas genricas son componentes del modelo requeridos.
Conjunto de procesos estndar de la organizacin (organizations set of standard processes)
Una coleccin de definiciones de los procesos que guan las actividades en una organizacin.
Estas descripciones de procesos cubren los elementos fundamentales de proceso (y las rela-
ciones entre ellos, tales como secuencia e interfaces) que deben incorporarse en los procesos
definidos que se implementan en los proyectos de la organizacin. Un proceso estndar
asegura la coherencia de las actividades de desarrollo y de mantenimiento en toda la
organizacin y es esencial para la estabilidad y la mejora a largo plazo. (Vase tambin
proceso definido y elemento de proceso).
Control de calidad (quality control) Las tcnicas y las actividades operativas que se usan para
satisfacer los requerimientos de calidad. (Vase tambin aseguramiento de la calidad).
Datos (data) Informacin registrada, sin importar la forma o el mtodo de registro, incluyendo
datos tcnicos, documentos de software de ordenadores, informacin financiera, informacin
de gestin, representacin de hechos, nmeros o datos de cualquier naturaleza que pueden
comunicarse, almacenarse y procesarse.

Definicin de proceso (process definition) El acto de definir y describir un proceso. El resultado
de una definicin de proceso es una descripcin de proceso. (Vase tambin descripcin de
proceso).
Desarrollo (development) En el Conjunto de productos CMMI, no slo se pueden incluir las
actividades de desarrollo, sino tambin las actividades de mantenimiento. Los proyectos que se
benefician de las mejores prcticas CMMI pueden enfocarse en desarrollo, mantenimiento o
ambos.
Desarrollo integrado de producto y de proceso (integrated product and process development
IPPD) Una aproximacin sistemtica al desarrollo de producto, que logra una colaboracin
oportuna de las partes interesadas relevantes durante todo el ciclo de vida del producto para
satisfacer mejor las necesidades del cliente.
Descripcin de proceso (process description) Una expresin documentada de un conjunto de
actividades realizadas para alcanzar un propsito determinado. Una descripcin de proceso
proporciona una definicin operativa de los principales componentes de un proceso. La
descripcin especifica, de manera completa, precisa y verificable, los requerimientos, el diseo,
el comportamiento u otras caractersticas de un proceso. Puede tambin incluir rocedimientos
para determinar si se han satisfecho estas disposiciones. Se pueden encontrar descripciones de
proceso a nivel de actividad, de proyecto o de organizacin.
Director (senior manager) En el Conjunto de productos CMMI, un rol de gestin situado en un
nivel lo suficientemente alto en la organizacin, donde la preocupacin principal de la persona
que juega este rol es la permanencia de la organizacin a largo plazo ms que las
reocupaciones y presiones a corto plazo contractuales y del proyecto. Un director tiene
autoridad para dirigir la asignacin o reasignacin de recursos, para dar soporte a la eficacia de
la mejora de procesos de la organizacin. (Vase tambin nivel directivo). Un director puede
ser cualquier gerente que satisface esta descripcin, incluyendo el dirigente mximo de la
organizacin. Sinnimos para director incluyen ejecutivo y gerente de alto nivel. Sin
embargo, para asegurar la consistencia y la usabilidad, estos sinnimos no se usan en los
modelos CMMI.
Disciplina (discipline) En el Conjunto de productos CMMI, los corpus de conocimiento
disponibles cuando selecciona un modelo CMMI (p. ej., ingeniera de sistemas). El Equipo de
Producto CMMI (CMMI Product Team) prev que otros corpus de conocimiento se integren en
el marco CMMI en el futuro.
Documento (document) Una coleccin de datos, sin importar el medio en el que se han
registrado, que normalmente permanece y puede ser ledo por seres humanos o mquinas. Por
tanto, los documentos incluyen tanto los documentos en papel como los electrnicos.


Ejecutivo (executive) (Vase director) Elaboracin de prctica genrica (generic practice
elaboration) Un componente informativo del modelo, que aparece despus de la prctica
genrica para proporcionar orientacin de cmo debera aplicarse la prctica genrica al rea
de proceso.
Elemento de configuracin (configuration item) Una agregacin de productos de trabajo que
se establece para la gestin de configuracin y se trata como una entidad nica en el proceso
de gestin de configuracin. (Vase tambin gestin de configuracin).
Empresa (enterprise) La composicin completa de las compaas. Las compaas pueden
consistir en varias organizaciones en varias ubicaciones con distintos clientes (Vase tambin
organizacin).
Equipo de accin de procesos (process action team) Un equipo que tiene la responsabilidad de
desarrollar e implementar actividades de mejora de procesos para una organizacin tal como
se documentan en un plan de accin de procesos.
Equipo integrado (integrated team) Un grupo de personas con habilidades y pericia
complementarias, que estn comprometidos a entregar los productos de trabajo especificados
colaborando de forma oportuna. Los miembros del equipo integrado proporcionan las
habilidades y el apoyo apropiados a todas las fases de la vida de los productos de trabajo y son
responsables colectivamente de entregar los productos de trabajo segn se especificaron. Un
equipo integrado debera incluir a los representantes autorizados de las organizaciones, de las
disciplinas y de las funciones que tienen un inters en el xito de los productos de trabajo.
Estndar (standard) Cuando vea la palabra estndar usada como un nombre en un modelo
CMMI, se refiere a los requerimientos formales obligatorios, desarrollados y usados para
prescribir aproximaciones coherentes al desarrollo (p. ej., los estndares ISO/IEC, los
estndares IEEE y los estndares de la organizacin). En lugar de usar estndar en su sentido
comn diario, se usa otro trmino que significa la misma cosa (p. ej., tpico, tradicional, usual o
rutinario).
Estructura de descomposicin del trabajo (WBS) (work breakdown structure) Una disposicin
de los elementos de trabajo y de su relacin entre ellos y con el producto final.
Evaluacin (appraisal) En el Conjunto de productos CMMI, un examen de uno o ms procesos
por un equipo de profesionales formados, usando un modelo de evaluacin de referencia
como base para determinar, como mnimo, fortalezas y debilidades (Vase tambin
valoracin y evaluacin de capacidad).
Evidencia (evidence) (Vase evidencia objetiva).
Evidencia objetiva (objective evidence) Tal y como se usa en los materiales de evaluacin
CMMI, los documentos o resultados de entrevistas usados como indicadores de la
implementacin o institucionalizacin de las prcticas del modelo. Fuentes de evidencia
objetiva pueden ser instrumentos, presentaciones, documentos y entrevistas.
Formacin (training) Opciones de aprendizaje formal e informal, que pueden incluir formacin
en aulas, tutela informal, formacin basada en web, autoestudio dirigido, y programas
formalizados de formacin en el puesto de trabajo. Las opciones de aprendizaje seleccionadas
para cada situacin se basan en una evaluacin de la necesidad de formacin y de las carencias
de rendimiento a tratarse.

Gerente (manager) En el Conjunto de productos CMMI, una persona que proporciona direccin
y control tcnico y administrativo a aquellos que realizan tareas o actividades dentro del rea
de responsabilidad del gerente. Las funciones tradicionales de un gerente incluyen el trabajo
de planificacin, de organizacin, de direccin y de control en un rea de responsabilidad.
Gestin de cambios (change management) Uso juicioso de medios para efectuar un cambio, o
un cambio propuesto sobre un producto o servicio. (Vase tambin gestin de
configuracin).
Gestin de requerimientos (requirement management) La gestin de todos los requerimientos
recibidos o generados por el proyecto, incluyendo tanto los requerimientos tcnicos como los
no tcnicos, as como aquellos requerimientos impuestos al proyecto por la organizacin.
Gestin de riesgos (risk management) Un proceso organizado y analtico para identificar lo que
podra causar dao o prdida (identificar riesgos); para evaluar y cuantificar los riesgos
identificados; y para desarrollar y, si es necesario, implementar una aproximacin apropiada
para prevenir o gestionar las causas de riesgo que podran dar como resultado daos o
prdidas significativos.
Grupo de procesos (process group) Una coleccin de especialistas que facilita la definicin, el
mantenimiento y la mejora de los procesos usados por la organizacin.
Guas de adaptacin (tailoring guidelines) Las guas de la organizacin que permiten a los
proyectos, a los grupos y a las funciones de la organizacin, adaptar los procesos estndar
apropiadamente para su uso. El conjunto de procesos estndar de la organizacin se describe a
nivel general y puede no ser directamente usable para ejecutar un proceso. Las guas de
adaptacin ayudan a aquellos que establecen los procesos definidos para los proyectos. Las
guas de adaptacin cubren (1) la seleccin de un proceso estndar, (2) la seleccin de un
modelo de ciclo de vida aprobado, y (3) la adaptacin del proceso estndar y el modelo de ciclo
de vida seleccionados para ajustarse a las necesidades del proyecto. Las guas de adaptacin
describen qu es lo que puede y no puede modificarse, e identifican los componentes de
proceso que son candidatos a modificacin.
Hallazgos (findings) (Vase hallazgos de la evaluacin)
Hallazgos de la evaluacin (appraisal findings) Los resultados de una evaluacin que identifican
las cuestiones, problemas u oportunidades ms importantes para la mejora de procesos,
dentro del alcance de la evaluacin. Los hallazgos de la evaluacin son deducciones sacadas de
evidencias objetivas corroboradas.
Identificacin de riesgos (risk identification) Una aproximacin organizada y rigurosa para
buscar riesgos probables o realistas en la consecucin de los objetivos.
Ingeniera de hardware (hardware engineering) La aplicacin de una aproximacin sistemtica,
disciplinada y cuantificable, para transformar un conjunto de requerimientos que representan
la coleccin de necesidades, expectativas y restricciones de las partes interesadas, usando
tcnicas documentadas y tecnologa para disear, implementar y mantener un producto
tangible. (Vase tambin ingeniera del software e ingeniera de sistemas). En CMMI, la
ingeniera de hardware representa todos los campos tcnicos (p. ej., elctrico o mecnico) que
transforman los requerimientos e ideas en productos tangibles y producibles.


Ingeniera de sistemas (systems engineering) La aproximacin interdisciplinaria que rige el
esfuerzo total tcnico y de gestin requerido para transformar un conjunto de necesidades,
expectativas y restricciones de los clientes en una solucin de producto y para dar soporte a
esa solucin a lo largo de la vida del producto. (Vase tambin ingeniera de hardware e
ingeniera del software). Esto incluye la definicin de las medidas tcnicas de rendimiento, la
integracin de las especialidades de ingeniera para establecer una arquitectura de producto, y
la definicin de los procesos de soporte del ciclo de vida que aseguran un equilibrio entre los
objetivos de coste, de rendimiento y de calendario.
Ingeniera del software (software engineering) (1) La aplicacin de una aproximacin
sistemtica, disciplinada y cuantificable al desarrollo, a la explotacin y al mantenimiento de
software. (2) El estudio de las aproximaciones como en (1). (Vase tambin ingeniera de
hardware e ingeniera de sistemas).
Institucionalizacin (institutionalization) La forma arraigada de funcionamiento que una
organizacin sigue rutinariamente como parte de su cultura corporativa.
Jefe de proyecto (project manager) En el Conjunto de productos CMMI, la persona responsable
de planificar, dirigir, controlar, estructurar y motivar el proyecto. El jefe de proyecto es
responsable de satisfacer al cliente.
Madurez de la organizacin (organizational maturity) El grado en el cual una organizacin tiene
explcita y consistentemente procesos desplegados que estn documentados, gestionados,
medidos, controlados y mejorados continuamente. La madurez de la organizacin puede
medirse a travs de las evaluaciones.
Marco (framework) (Vase marco CMMI).
Marco CMMI (CMMI framework) La estructura base que organiza los componentes CMMI, que
incluye elementos comunes de los actuales modelos CMMI, al igual que las reglas y los
mtodos para generar modelos, mtodos de evaluacin (incluyendo artefactos asociados) y
materiales de formacin. El marco permite aadir nuevas disciplinas a CMMI de forma que las
nuevas disciplinas se integren con las existentes. (Vase tambin modelo CMMI y Conjunto
de productos CMMI).
Medicin de proceso (process measurement) El conjunto de definiciones, mtodos y
actividades usadas para tomar mediciones de un proceso y de sus productos resultantes, con el
propsito de caracterizar y comprender el proceso.
Mejora de procesos (process improvement) Un programa de actividades diseado para
mejorar el rendimiento y la madurez de los procesos de la organizacin y los resultados de
dicho programa.
Mejoras de procesos y de tecnologa (process and technology improvements) Mejoras
incrementales e innovadoras a los procesos y a las tecnologas de proceso o de producto.
Meta (goal) Un componente CMMI requerido que puede ser una meta genrica o bien una
meta especfica. Cuando vea la palabra meta en un modelo CMMI, se refiere siempre a un
componente del modelo (p. ej., meta genrica y meta especfica). (Vase tambin meta
genrica, objetivo y meta especfica).


Meta especfica (specific goal) Un componente requerido del modelo que describe las
caractersticas nicas que deben estar presentes para satisfacer el rea de proceso. (Vase
tambin nivel de capacidad, meta genrica, objetivos de negocio de la organizacin y
rea de proceso).
Meta genrica (generic goal) Un componente requerido del modelo, que describe las
caractersticas que deben estar presentes para institucionalizar los procesos que implementan
un rea de proceso. (Vase tambin institucionalizacin).
Modelo CMMI (CMMI model) Uno de los modelos posibles de la coleccin completa que
pueden generarse a partir del marco CMMI. Dado que el marco CMMI puede generar distintos
modelos basndose en las necesidades de la organizacin que est usndolo, existen mltiples
modelos CMMI (Vase tambin marco CMMI y Conjunto de productos CMMI.).
Modelo de ciclo de vida (lifecycle model) Una particin en fases de la vida de un producto o
proyecto.
Modelo de madurez y de capacidad (capability maturity model) un modelo que contiene los
elementos esenciales de procesos eficaces para una o ms disciplinas, y que describe un
camino de mejora evolutiva desde procesos inmaduros ad hoc a procesos maduros
disciplinados con eficacia y calidad mejorada.
Modelo de referencia (reference model) Un modelo que se usa como punto de referencia para
medir algn atributo.
Modelo de referencia de evaluacin (appraisal reference model) Tal y como se usa en los
materiales de evaluacin CMMI, el modelo CMMI al cual un equipo de evaluacin correlaciona
las actividades de proceso implementadas.
Modelo de rendimiento de proceso (process performance model) Una descripcin de las
relaciones entre los atributos de un proceso y sus productos de trabajo, que se desarrolla a
partir de los datos histricos de rendimiento de proceso y se calibra usando las medidas
recogidas de proceso y de producto del proyecto, y que se usa para predecir los resultados que
sern obtenidos siguiendo el proceso.
Nivel de capacidad (capability level) Logro de la mejora de procesos dentro de un rea de
proceso individual. Un nivel de capacidad se define por las prcticas especficas y genricas
apropiadas para un rea de proceso (Vase tambin meta genrica, prctica genrica,
nivel de madurez, y rea de proceso).
Nivel de madurez (maturity level) Grado de mejora de procesos a travs de un conjunto
predefinido de reas de proceso en las que se alcanzan todas las metas del conjunto. (Vase
tambin nivel de capacidad y rea de proceso).
Nivel directivo (higher level management) La persona o personas que proporcionan la poltica
y la orientacin global para el proceso, pero no proporcionan la monitorizacin y el control
directo y cotidiano del proceso. Dichas personas pertenecen a un nivel de gestin en la
organizacin por encima del nivel inmediato responsable del proceso y pueden ser (aunque no
necesariamente) directores (Vase tambin director).


Objetivo (objective) Cuando se usa como un nombre en el Conjunto de productos CMMI, el
trmino objetivo (objective) reemplaza a la palabra meta (goal), tal y como se usa en su sentido
cotidiano corriente, ya que la palabra meta (goal) se reserva para usarse cuando se refiere a los
componentes del modelo CMMI llamados metas (goals) especficas y metas (goals) genricas.
(Vase tambin meta).
Objetivo cuantitativo (quantitative objective) Valor objetivo deseado expresado en medidas
cuantitativas. (Vase tambin objetivos de mejora de procesos y objetivos de calidad y de
rendimiento del proceso).
Objetivos de calidad y de rendimiento del proceso (quality and process performance
objectives) Objetivos y requerimientos de la calidad del producto, de la calidad del servicio y
del rendimiento del proceso. Los objetivos de rendimiento del proceso incluyen la calidad; sin
embargo, para enfatizar la importancia de la calidad en el Conjunto de productos CMMI, se usa
la frase objetivos de calidad y de rendimiento del proceso en lugar de objetivos de rendimiento
del proceso.
Objetivos de mejora de proceso (process improvement objectives) Un conjunto de
caractersticas objetivo establecidas para guiar el esfuerzo para mejorar un proceso existente,
de manera especfica y medible, tanto en trminos de caractersticas del producto resultante
(p. ej., calidad, rendimiento y conformidad con los estndares) como en la maneraen la que se
ejecuta el proceso (p. ej., eliminacin de etapas redundantes, combinacin de etapas de
proceso y mejora del tiempo de ciclo). (Vase tambin objetivos de negocio de la
organizacin y objetivo cuantitativo).
Objetivos de negocio (business objectives) (Vase objetivos de negocio de la organizacin).
Objetivos de negocio de la organizacin (organizations business objectives) Estrategias
diseadas por la direccin para asegurar la existencia continuada de la organizacin y fomentar
su rentabilidad, cuota de mercado y otros factores que influyen en el xito de la organizacin.
(Vase tambin objetivos de calidad y de rendimiento del proceso y objetivo cuantitativo).
Dichos objetivos pueden incluir la reduccin del nmero de peticiones de cambios durante la
fase de integracin del sistema, la reduccin del tiempo del ciclo de desarrollo, el incremento
del nmero de errores encontrados en la primera o segunda fase de desarrollo del producto y
la reduccin del nmero de defectos informados por clientes, cuando se aplica a actividades de
ingeniera de sistemas.
Organizacin (organization) Una estructura administrativa en la que la gente gestiona
colectivamente uno o ms proyectos como un todo, y cuyos proyectos comparten un director y
operan bajo las mismas polticas. Sin embargo, la palabra organizacin tal y como se usa en
todos los modelos CMMI, tambin puede aplicarse a una persona que realiza una funcin en
una pequea organizacin que podra ser realizada por un grupo de gente en una organizacin
grande. (Vase tambin empresa y unidad organizativa).
Parmetros de rendimiento (performance parameters) Las mediciones de eficacia y otras
medidas clave usadas para guiar y controlar el desarrollo progresivo.


Parte interesada (stakeholder) En el Conjunto de productos CMMI, un grupo o individuo que se
ve afectado por o es de alguna manera responsable del resultado de un proyecto. Las partes
interesadas pueden incluir a los miembros del proyecto, los proveedores, los clientes, los
usuarios finales y otros. (Vase tambin cliente y parte interesada relevante).
Participantes en la evaluacin (appraisal participants) Miembros de la unidad de la
organizacin que participan proporcionando informacin durante la evaluacin.
Perfil (profile) (Vase perfil alcanzado y perfil objetivo).
Perfil alcanzado (achievement profile) En la representacin continua, una lista de reas de
proceso y sus correspondientes niveles de capacidad, que representan el progreso de la
organizacin para cada rea de proceso, segn avanza a travs de los niveles de capacidad.
(Vase tambin perfil de nivel de capacidad, perfil objetivo y progresin hacia un nivel
objetivo).
Perfil objetivo (target profile) En la representacin continua, una lista de reas de proceso y
sus niveles de capacidad correspondientes que representan un objetivo de mejora de procesos.
(Vase tambin perfil logrado y perfil de nivel de capacidad).
Plan de proyecto (Project plan) Un plan que proporciona la base para ejecutar y controlar las
actividades del proyecto, las cuales tratan los compromisos con el cliente del proyecto. La
planificacin del proyecto incluye estimar los atributos de los productos de trabajo y de las
tareas, determinar los recursos necesarios, negociar los compromisos, elaborar un calendario,
e identificar y analizar los riesgos del proyecto. Puede ser necesaria la iteracin entre estas
actividades para establecer el plan de proyecto.
Poltica (policy) (Vase poltica de la organizacin).
Poltica de la organizacin (organizational policy) Un principio de gua establecido
normalmente por la direccin, que se adopta por una organizacin para influenciar y
determinar decisiones.
Prctica alternativa (alternative practice) Una prctica que es un sustituto para una o ms
prcticas genricas o especficas contenidas en los modelos CMMI, que alcanza un efecto
equivalente a satisfacer la meta genrica o especfica asociada con las prcticas del modelo. Las
prcti cas alternativas no son necesariamente reemplazo una-por-una para las prcticas
genricas o especficas.
Prctica especfica (specific practice) Un componente esperado del modelo que se considera
importante para alcanzar la meta especfica asociada. Las prcticas especficas describen las
actividades esperadas para dar como resultado el logro de las metas especficas de un rea de
proceso. (Vase tambin rea de proceso y meta especfica).
Prctica genrica (generic practice) Un componente esperado del modelo que se considera
importante para alcanzar las metas genricas asociadas. Las prcticas genricas asociadas con
una meta genrica describen las actividades que se espera resulten en el logro de la meta
genrica y contribuyan a la institucionalizacin de los procesos asociados con el rea de
proceso.
Procedimiento de prueba (test procedure) Instrucciones detalladas para el establecimiento,
ejecucin y evaluacin de los resultados de una determinada prueba.

Proceso (process) En el Conjunto de productos CMMI, las actividades que pueden reconocerse
como implementaciones de las prcticas en un modelo CMMI. Estas actividades pueden
corresponderse con una o ms prcticas en las reas de proceso de CMMI para permitir que un
modelo sea til para la mejora de procesos y la evaluacin de procesos. Hay un uso especial de
la frase el proceso en las declaraciones y descripciones de las metas genricas y las prcticas
genricas. El proceso, tal y como se usa en la Parte Dos, es el proceso o procesos que
implementan el rea de proceso.
Proceso definido del proyecto (projects defined process) El proceso integrado y definido que
se adapta a partir del conjunto de procesos estndar de la organizacin.
Proceso en optimizacin (optimizing process) Un proceso gestionado cuantitativamente que es
mejorado basndose en una comprensin de las causas comunes de variacin inherentes al
proceso. El enfoque de un proceso en optimizacin est en mejorar continuamente el rango de
rendimiento del proceso a travs de mejoras tanto incrementales como innovadoras. (Vase
tambin causa comn de variacin del proceso, proceso definido y proceso gestionado
cuantitativamente).
Proceso estndar (standard process) Una definicin operativa del proceso bsico que gua el
establecimiento de un proceso comn en una organizacin. Un proceso estndar describe los
elementos de proceso fundamentales que son esperados para incorporarse a cualquier
proceso definido. Tambin describe las relaciones (p. ej., ordenacin e interfaces) entre estos
elementos de proceso.
Producto (product) En el Conjunto de productos CMMI, un producto de trabajo que est
previsto entregar a un cliente o usuario final. La forma de un producto puede variar segn el
contexto. (Vase tambin cliente, componente de producto, servicio y producto de
trabajo).
Producto de trabajo (work product) En el Conjunto de productos CMMI, un resultado til de un
proceso. Esto puede incluir ficheros, documentos, productos, partes de un producto, servicios,
descripciones de proceso, especificaciones y facturas. Una distincin clave entre un producto
de trabajo y un componente de producto es que un producto de trabajo no es necesariamente
parte del producto. En los modelos CMMI, se ver la frase productos de trabajo y servicios.
Aunque la definicin de producto de trabajo incluye los servicios, esta frase se usa para
enfatizar la inclusin de servicios.
Productos de trabajo tpicos (typical work products) Un componente informativo del modelo
que proporciona ejemplos de resultados de una prctica especfica. Estos ejemplos se
denominan productos de trabajo tpicos porque a menudo hay otros productos de trabajo que
son igual de eficaces pero no estn enumerados.


Prototipo (prototype) Un tipo, forma o instancia preliminar de un producto o componente de
producto que sirve como modelo para etapas posteriores o para la versin final y completa del
producto. Este modelo (p. ej., fsico, electrnico, numrico o analtico) puede usarse entre
otros, para los siguientes propsitos:
Evaluacin de la viabilidad de una tecnologa nueva o no familiar.
Evaluacin o mitigacin de un riesgo tcnico.
Validacin de los requerimientos.
Demostracin de caractersticas crticas.
Cualificacin de un producto.
Cualificacin de un proceso.
Caracterizacin del rendimiento o del producto.
Explicacin de principios fsicos.
Proveedor (supplier) (1) Una entidad que entrega productos o realiza servicios que han sido
adquiridos. (2) Un individuo, sociedad, empresa, corporacin, asociacin u otros servicios que
tienen un acuerdo (contrato) con un comprador para el diseo, el desarrollo, la fabricacin, el
mantenimiento, la modificacin o el suministro de elementos bajo los trminos de un acuerdo
(contrato).
Proyecto (project) En el Conjunto de productos CMMI, un conjunto gestionado de recursos
interrelacionados que entrega uno o ms productos a un cliente o usuario final. Un proyecto
tiene un comienzo concreto (es decir, el arranque del proyecto) y opera normalmente de
acuerdo a un plan. Dicho plan est frecuentemente documentado y especifica qu es lo que se
va a entregar o implementar, los recursos y los fondos que van a usarse, el trabajo que va a
realizarse y el calendario para hacer el trabajo. Un proyecto puede estar compuesto de
proyectos.
Prueba de aceptacin (acceptance testing) Prueba formal llevada a cabo para permitir a un
usuario, a un cliente o a otra entidad autorizada determinar si aceptan un producto o
componente de producto. (Vase tambin prueba unitaria).
Prueba unitaria (unit testing) Pruebas de unidades individuales o de grupos de unidades
relacionadas de hardware o de software. (Vase tambin prueba de aceptacin).
Referencia (reference) Un componente informativo del modelo, que apunta a informacin
adicional o ms detallada de reas de proceso relacionadas.
Rendimiento de proceso (process performance) Una medida de los resultados reales
alcanzados al seguir un proceso. Se caracteriza tanto por las medidas de proceso (p. ej.,
esfuerzo, tiempo de ciclo y eficacia en la eliminacin de defectos) como por medidas de
producto (por ejemplo, fiabilidad, densidad de defectos y tiempo de respuesta).


Representacin (representation) La organizacin, uso y presentacin de los componentes del
CMM. En general, son evidentes dos tipos de aproximacin para presentar las mejores
prcticas: la representacin por etapas y la representacin continua.
Requerimiento (requirement) (1) Una condicin o capacidad necesitada por un usuario para
solucionar un problema o lograr un objetivo. (2) Una condicin o capacidad que debe cumplir o
poseer un producto o componente de producto para satisfacer un contrato, un estndar, una
especificacin u otros documentos impuestos formalmente. (3) Una representacin
documentada de una condicin o capacidad como en (1) o en (2).
Requerimientos de cliente (customer requirements) El resultado de educir, consolidar y
resolver los conflictos entre las necesidades, las expectativas, las limitaciones y las interfaces
de las partes interesadas relevantes del producto de una forma que sea aceptable para el
cliente (Vase tambin cliente).
Requerimientos de componente de producto (product component requirements) Una
especificacin completa de un componente de producto, incluyendo el ajuste, la forma, la
funcin, el rendimiento y cualquier otro requerimiento.
Requerimientos de producto (product requirements) Un refinamiento de los requerimientos
de cliente en el lenguaje de los desarrolladores, transformando los requerimientos implcitos
en requerimientos derivados explcitos. (Vase tambin requerimientos derivados y
requerimientos de componente de producto). El desarrollador usa los requerimientos de
producto para guiar el diseo y la construccin del producto.
Requerimientos derivados (derived requirements) Requerimientos que no estn indicados
explcitamente en los requerimientos de cliente, pero son deducidos (1) de los requerimientos
contextuales (p. ej., estndares aplicables, leyes, polticas, prcticas comunes y decisiones de la
gerencia) o (2) de los requerimientos necesarios para especificar un componente de producto.
Los requerimientos derivados pueden surgir tambin durante el anlisis y el diseo de los
componentes del producto o del sistema. (Vase tambin requerimientos de producto).
Requerimientos no tcnicos (non technical requirements) Estipulaciones, compromisos,
condiciones y trminos contractuales que afectan a cmo se adquieren los productos o los
servicios. Algunos ejemplos son productos que van a ser entregados, derechos de datos para
elementos no desarrollados (NDI) de componentes comerciales (COTS) entregados, fechas de
entrega e hitos con criterios de salida. Otros requerimientos no tcnicos incluyen los
requerimientos de formacin, los requerimientos del emplazamiento y los calendarios del
despliegue.
Requerimientos tcnicos (technical requirements) Propiedades (atributos) de productos o
servicios que van a ser adquiridos o desarrollados.
Retorno de la inversin (return on investment) El ratio de retorno entre los ingresos del
producto y los costes de produccin, que determina si una organizacin se beneficia de la
produccin de ese producto.


Servicio (service) En el Conjunto de productos CMMI, un servicio es un producto que es
intangible y no almacenable. (Vase tambin producto, cliente y producto de trabajo).
Subprctica (subpractice) Un componente informativo del modelo que proporciona guas para
interpretar e implementar una prctica especfica o genrica. Las subprcticas pueden
redactarse como si fueran obligatorias, pero de hecho slo pretenden proporcionar ideas que
pueden ser tiles para la mejora de procesos.
Subproceso (subprocess) Un proceso que es parte de un proceso mayor. Un subproceso puede,
a su vez, descomponerse en subprocesos y/o elementos de proceso. (Vase tambin proceso,
descripcin de proceso y elemento de proceso).
Trazabilidad (traceability) Una asociacin discernible entre dos o ms entidades lgicas, tales
como requerimientos, elementos de sistema, verificaciones o tareas. (Vase tambin
trazabilidad bidireccional y trazabilidad de requerimientos).
Trazabilidad bidireccional (bidirectional traceability) Una asociacin entre dos o ms entidades
lgicas que es discernible en ambos sentidos (es decir, hacia y desde una entidad). (Vase
tambin trazabilidad de requerimientos y trazabilidad).
Trazabilidad de requerimientos (requirement traceability) Una asociacin discernible entre los
requerimientos y los requerimientos relacionados, las implementaciones y las verificaciones.
(Vase tambin trazabilidad bidireccional y trazabilidad).
Unidad organizativa (organizational unit) La parte de una organizacin que es objeto de una
evaluacin. Una unidad organizativa despliega uno o ms procesos que tienen un contexto de
procesos coherente y opera dentro de un conjunto coherente de objetivos de negocio. Una
unidad organizativa es normalmente parte de una organizacin mayor, aunque en una
organizacin pequea, la unidad organizativa puede ser toda la organizacin.
Validacin (validation) Confirmacin de que el producto, tal y como se ha proporcionado (o
ser proporcionado), satisfar su uso previsto. En otras palabras, la validacin asegura que se
ha construido el producto correcto. (Vase tambin verificacin).
Valoracin (assessment) En el Conjunto de productos CMMI, una evaluacin que una
organizacin hace internamente con el propsito de mejora de procesos. La palabra valoracin
tambin se usa en el conjunto de productos CMMI en su sentido cotidiano (p. ej., valoracin de
riesgos). (Vase tambin evaluacin y evaluacin de capacidad).
Verificacin (verification) Confirmacin de que los productos de trabajo reflejan
apropiadamente los requerimientos que se han especificado para ellos. En otras palabras, la
verificacin asegura que se construy correctamente el producto. (Vase tambin
validacin).


Apndice B: Bibliografa
OMG. (s.f.). Unified Modeling Language 2.4.1. Obtenido de OMG Specifications: www.omg.org
Software Engineering Institute. (2010). CMMI for development, Version 1.3.
Software Engineering Institute. (June 1993). Taxonomy-Based Risk Identification.
Universitat Oberta de Catalunya. (s.f.). Gesti i desenvolupament de projectes.
Universitat Oberta de Catalunya. (s.f.). Gestin y Organizacin de Proyectos Informticos. UOC.
Universitat Oberta de Catalunya. (s.f.). Ingeniera de Software.
Universitat Oberta de Catalunya. (s.f.). Introduccin a la Ingeniera de software OO.
Universitat Oberta de Catalunya. (s.f.). Presentaci de documents i elaboraci de presentacions.
Universitat Oberta de Catalunya. (s.f.). Redacci de textos cientificotcnics.
Universitat Oberta de Catalunya. (s.f.). Treball final de carrera.

Mtelloh TFC0213 Memoria

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Mtelloh TFC0213 Memoria

Cargado por

Copyright:

Formatos disponibles

Memoria

Autor: Marcelo Tello Helbling

También podría gustarte