Mtelloh TFC0213 Memoria

Memoria
Proyecto final de carrera

Ingeniera Informtica de Gestin 2012/13
Consultor: Oriol Mart Girona

Autor: Marcelo Tello Helbling
Proyecto final de carrera: Ingeniera de Software
Este proyecto est dedicado a mis padres, a mis hermanos y

a mi pareja, por su apoyo incondicional en esta etapa de mi
vida y a Oriol, mi consultor, por su gran ayuda durante la
elaboracin.
Barcelona, 2 de Enero de 2013
Marcelo Tello Helbling (Universitat Oberta de Catalunya)
Pgina 1
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.
Pgina 2
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
Pgina 3

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
Pgina 4
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
Pgina 5

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
Pgina 6
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.
Pgina 7
Ilustracin 1 Historia de los modelos de madurez
Pgina 8
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.
Ilustracin 2 Constelaciones CMMI
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.
Pgina 9

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.
Ilustracin 3 reas de proceso de la constelacin de Desarrollo
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.
Pgina 10
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.
Pgina 11

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
Pgina 12
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
Pgina 13
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.
Pgina 14
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
Pgina 15
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.
Pgina 16
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)
PAC-1
Plan de trabajo
Nombre de actividad (Nivel II)
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

Cdigo de actividad
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
Pgina 17

Cdigo de actividad
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

Cdigo de actividad
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
Pgina 18
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.
Pgina 19
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
Pgina 20

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.
Pgina 21
Ilustracin 8 Esquema de una implantacin CMMI
En el siguiente esquema podemos ver un ejemplo de lo comentado anteriormente:
Pgina 22
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
Pgina 23
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
Pgina 24
Proyectos candidatos
Tareas de revisin y
RF_1.5
Gestin de niveles de madurez
RF_2.1
Mantenimiento de proyectos
RF_2.2
Mantenimiento de roles
RF_2.3
Mantenimiento de departamentos
RF_2.4
Equipos de proyecto
RF_3.1
Gestin de tipos de revisiones
RF_3.2
Tareas de revisin
RF_3.3
Coberturas de tarea
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
RF_5.1
Cuadro de mandos con grficas y posibilidad de impresin
cobertura
Revisiones y
evidencias
DashBoard
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
Pgina 25

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
Pgina 26

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
Pgina 27

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.
Pgina 28
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
RNF_10
Mantenimiento
La concurrencia deber contemplar 10-20 usuarios.
Pgina 29
Requisitos empresariales
Identificador
Clasificacin
Descripcin
RE_1
Econmico
Reduccin del gasto del proyecto
RE_2
Estratgico
Reforzar la competitividad en el mercado
Pgina 30
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
Pgina 31
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.
Pgina 32
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
Pgina 33
Detalle y funcionalidades de los subsistemas
A continuacin se representa un grfico ms ilustrativo de los componentes y funcionalidades

del sistema.
Indicadores
Informes
Progreso
Proyectos
Revisores
Equipo
Dashboard
Proyectos
candidatos
CMMI
Info
Revisiones
y
Evidencias
Tareas de
revisin y
cobertura
Agenda
Estado de tareas
PIIDB
Clasificacin
Vnculos CMMI
Evidencias
Usuarios y perfiles
Ilustracin 11 Componentes CMMI UP
Pgina 34
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.
Pgina 35
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).
Pgina 36
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.
Pgina 37
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
Subsistema
Cdigo
Descripcin
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
Pgina 38

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
Subsistema
Cdigo
Descripcin
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
Subsistema
Cdigo
Descripcin
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
Pgina 39

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
Subsistema
Cdigo
Descripcin
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
Subsistema
Cdigo
Descripcin
Indicadores
IN_CU_001
Consultar indicador/Grfica
IN_CU_002
Imprimir indicador/Grfica
IN_CU_003
Aadir indicador
IN_CU_004
Eliminar indicador
Pgina 40
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.
Caso de uso
GU_CU_002
Nombre
Validar credenciales y obtener permisos
RF_0.1
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.
Escenario principal

accede al sistema con los mens a los cuales ha sido
autorizado.
La validacin de credenciales ha sido incorrecta. El sistema

devuelve cdigo de error al GU_CU_001.
Pgina 41
Caso de uso
GU_CU_003
Nombre
Lista de usuarios
RF_0.1
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)
Escenario principal

accede al men de usuarios.
Caso de uso
GU_CU_004
Nombre
Alta de usuario
RF_0.1
Actores
Administrador
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.
El usuario que quiere dar de alta existe. El sistema le muestra

un mensaje de aviso.
Caso de uso
GU_CU_005
Nombre
Baja de usuario
RF_0.1
Actores
Administrador
Precondicin
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.
Pgina 42

Caso de uso
GU_CU_006
Nombre
Modificacin de usuario
RF_0.1
Actores
Administrador
Precondicin
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
Pgina 43
Diagrama de casos de uso del subsistema de conexin
Ilustracin 13 Casos de uso subsistema conexin
Pgina 44
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
RF_1.1
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)
Escenario principal

accede al men CMMI Objetivos genricos.
Caso de uso
CM_CU_002
Nombre
Alta de objetivo genrico
RF_1.1
Actores
Experto CMMI
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.
El objetivo genrico que quiere dar de alta existe. El sistema le

muestra un mensaje de aviso.
Pgina 45
Caso de uso
CM_CU_003
Nombre
Baja de objetivo genrico
RF_1.1
Actores
Administrador
Precondicin
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.
Caso de uso
CM_CU_004
Nombre
Modificacin de un objetivo genrico
RF_1.1
Actores
Experto CMMI
Precondicin
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
Pgina 46
Diagrama de casos de uso del subsistema CMMI
Ilustracin 14 Casos de uso del subsistema CMMI
Pgina 47
Subsistema de gestin de proyectos candidatos

Caso de uso
PJ_CU_009
Nombre
Lista de proyectos candidatos
RF_2.1
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 )
Escenario principal

accede al men CMMI proyectos candidatos
Caso de uso
PJ_CU_010
Nombre
Alta de proyectos candidatos
RF_2.1
Actores
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,

El proyecto candidatos que quiere dar de alta existe. El sistema

le muestra un mensaje de aviso.
Pgina 48
Caso de uso
PJ_CU_011
Nombre
Baja de proyectos candidatos
RF_2.1
Actores
Precondicin
Postcondicin
El proyecto candidatos se elimina (lgicamente) del sistema
Escenario principal
EL usuario accede a la lista proyectos candidatos, selecciona

Caso de uso
PJ_CU_012
Nombre
Modificacin de un proyecto candidato
RF_2.1
Actores
Precondicin
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
Pgina 49
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
RF_3.1
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)
Escenario principal

accede al men CMMI Tipos de revisiones.
Pgina 50

Caso de uso
RV_CU_002
Nombre
Alta de un tipo de revisin
RF_3.1
Actores
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,

El tipo de revisin que quiere dar de alta existe. El sistema le

muestra un mensaje de aviso.
Caso de uso
RV_CU_003
Nombre
Baja de tipo de revisin
RF_3.1
Actores
Precondicin
Postcondicin
El tipo de revisin se elimina (lgicamente) del sistema
Escenario principal
EL usuario accede a la lista de tipos de revisiones, selecciona

Pgina 51
Caso de uso
RV_CU_004
Nombre
Modificacin de un tipo de revisin
RF_3.1
Actores
Precondicin
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
Pgina 52
Subsistema de revisiones y evidencias

* Se describen los ms representativos.
Caso de uso
EV_CU_001
Nombre
Matriz de revisiones
RF_4.3
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.
Escenario principal

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
Pgina 53

Caso de uso
EV_CU_002
Nombre
Generar revisiones
RF_4.3
Actores
Revisor CMMI
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).
Caso de uso
EV_CU_003
Nombre
Cambiar estado de una revisin
RF_4.3
Actores
Revisor CMMI
Precondicin
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
Pgina 54

Caso de uso
EV_CU_004
Nombre
Aadir una evidencia
RF_4.3
Actores
Revisor CMMI
Precondicin
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
Caso de uso
EV_CU_008
Nombre
Aadir una incidencia y accin correctiva
RF_4.3
Actores
Revisor CMMI
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)
Pgina 55

Caso de uso
EV_CU_009
Nombre
Buzn de incidencias
RF_4.3
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.
Pgina 56
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
RF_4.3
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:
Pgina 57
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
Pgina 58
Modelo esttico: Diagrama de clases
Modelo CMMI DEV 1.3
Ilustracin 19 Diagrama de clases CMMI
Pgina 59
Documentacin de ejemplo
El modelo expuesto anteriormente debe ser capaz de almacenar esta informacin con la
misma estructura.
Ilustracin 20 Ejemplo informacin CMMI
Pgina 60
Ilustracin 21 Ejemplo Informacin CMMI (Cont.)
Pgina 61
Ilustracin 22 Ejemplo Informacin CMMI (Cont.)
Pgina 62
Coberturas, tareas de revisin, proyectos e incidencias
Ilustracin 23 Diagrama de clases Revisiones
Pgina 63
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.
Pgina 64
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.
Pgina 65
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.
Pgina 66

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.
Pgina 67
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.
Pgina 68
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
Pgina 69
Estructura esttica de la aplicacin
Ilustracin 24 Diagrama de la estructura de la aplicacin
Pgina 70
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.
Pgina 71
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
Pgina 72
Modelo esttico : Diagrama de clases
Modelo CMMI DEV 1.3
Ilustracin 27 Diagrama de clases CMMI
Pgina 73
Coberturas, tareas de revisin, proyectos e incidencias
Ilustracin 28 Diagrama de clases Revisiones
Pgina 74
Clases frontera y gestoras CMMI Core
Cabe destacar que las clases frontera de tipo CRUD (Create, Update, Delete) o ABM (Alta, Baja,
Ilustracin 29 Clases frontera y gestoras CMMI Core
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
Pgina 75
Clases frontera y gestoras CMMI Proyectos, revisiones incidencias
Ilustracin 31 Clases frontera y gestoras CMMI Proyectos revisiones e incidencias
Pgina 76
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.
Pgina 77
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
Pgina 78
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
Enviar guardar incidencia
Guardar revisin
EV_CU_006: Modificar revisin
Pgina 79
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
Seleccionar fichero
Escribir URL
Guardar revisin
EV_CU_006: Modificar revisin
Pgina 80
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.
Pgina 81
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
Pgina 82
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.
Pgina 83
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
Pgina 84

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.
Pgina 85
Diseo E/R CMMI Core
Ilustracin 39 E-R CMMI Core
Pgina 86
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.
Pgina 87
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.
Pgina 88
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.
Pgina 89
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.
Pgina 90
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.
Pgina 91
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.
Pgina 92
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.
Pgina 93
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.
Pgina 94
Ilustracin 49 Prototipo alta de proyectos
Pgina 95
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.
Pgina 96
Ilustracin 52 Prototipo Alta de tareas de revisin
Pgina 97
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.
Pgina 98
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.
Pgina 99
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.
Pgina 100
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
Pgina 101

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
Recurso
de 8 horas
Precio
Total
Jornada
01
PAC1- Plan de proyecto
Jefe de proyecto
384
1536
02
PAC2- Especificacin y
13
Analista
288
3744
12,5
Analista-
192
2400
anlisis
03
PAC3- Diseo del sistema
Programador
04
Memoria y presentacin
7,5
Jefe de proyecto
384
2880
05
Programacin y pruebas
40
Analista
192
7680
unitarias
programador
06
Pruebas integradas
15,5
Analista
288
4464
07
Formacin a usuarios
Analista
288
288
08
Adecuacin de datos tareas
1,5
Analista
192
288
vs cobertura CMMI
programador
09
Puesta en produccin
1,5
Arquitecto
280
420
10
0,5
Jefe de proyecto
384
192
TOTAL
Final del proyecto
97
23892
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
Pgina 102
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.
Pgina 103
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).
Pgina 104

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.
Pgina 105

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 relaciones 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.
Pgina 106

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.
Pgina 107

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.
Pgina 108

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.
Pgina 109

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).
Pgina 110

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).
Pgina 111

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.
Pgina 112

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.
Pgina 113

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.
Pgina 114

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).
Pgina 115

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.
Pgina 116

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).
Pgina 117
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.
Pgina 118

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

Proyecto final de carrera

Consultor: Oriol Mart Girona

Proyecto final de carrera: Ingeniera de Software

Este proyecto est dedicado a mis padres, a mis hermanos y

Marcelo Tello Helbling (Universitat Oberta de Catalunya)

Proyecto final de carrera: Ingeniera de Software

El proyecto CMMI UP surge de la necesidad por parte de las

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

Revisar los procesos actuales de la compaa y proponer su alineamiento con el

Recopilar la base de datos de evidencias para su presentacin al equipo de auditora

Marcelo Tello Helbling (Universitat Oberta de Catalunya)

Proyecto final de carrera: Ingeniera de Software

Marcelo Tello Helbling (Universitat Oberta de Catalunya)

Proyecto final de carrera: Ingeniera de Software

Marcelo Tello Helbling (Universitat Oberta de Catalunya)

Proyecto final de carrera: Ingeniera de Software

Ilustracin 1 Historia de los modelos de madurez ...................................................................... 8

Marcelo Tello Helbling (Universitat Oberta de Catalunya)

Proyecto final de carrera: Ingeniera de Software

Marcelo Tello Helbling (Universitat Oberta de Catalunya)

Proyecto final de carrera: Ingeniera de Software

La calidad nunca es un accidente; siempre es el resultado de un esfuerzo de inteligencia. John

La calidad de un producto o sistema es consecuencia directa de los procesos

Las organizaciones que desarrollan software presentan un atributo denominado

Marcelo Tello Helbling (Universitat Oberta de Catalunya)

Proyecto final de carrera: Ingeniera de Software

Ilustracin 1 Historia de los modelos de madurez

Marcelo Tello Helbling (Universitat Oberta de Catalunya)

Proyecto final de carrera: Ingeniera de Software

Como hemos visto en el apartado anterior, CMMI surge de la

Ilustracin 2 Constelaciones CMMI

Marcelo Tello Helbling (Universitat Oberta de Catalunya)

Proyecto final de carrera: Ingeniera de Software

Ilustracin 3 reas de proceso de la constelacin de Desarrollo

Marcelo Tello Helbling (Universitat Oberta de Catalunya)

Proyecto final de carrera: Ingeniera de Software

La situacin actual del desarrollo de software afronta un escenario poco alentador. En

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

Direccin general de patrimonio. Subdireccin general de compras (2010). Empresas

Direccin General de Sistemas de Informacin Sanitaria (2010). Servicio madrileo de

Isdefe (Ingeniera de Sistemas para la Defensa de Espaa) (2010). Requiere slo de

Ayuntamientos: Ayuntamiento de Benidorm (Alicante), requiere slo de ISO

Marcelo Tello Helbling (Universitat Oberta de Catalunya)

Proyecto final de carrera: Ingeniera de Software

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.

Ilustracin 4 Empresas certificadas en Espaa

Marcelo Tello Helbling (Universitat Oberta de Catalunya)

Proyecto final de carrera: Ingeniera de Software

Marcelo Tello Helbling (Universitat Oberta de Catalunya)

Proyecto final de carrera: Ingeniera de Software

El objetivo primordial de este proyecto es llevar a cabo las tareas

Marcelo Tello Helbling (Universitat Oberta de Catalunya)

Proyecto final de carrera: Ingeniera de Software

Enfoque y mtodo aplicado

La metodologa escogida para la realizacin del proyecto es la llamada metodologa en

Calidad del producto alta

Reduccin de costes de desarrollo debido a la alta calidad en la fase de requisitos.