Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Colabora:
AVISO LEGAL
CMMI es una marca registrada en la Oficina de Marcas y Patentes de EEUU por la Universidad
Carnegie Mellon
Las distintas normas ISO mencionadas han sido desarrolladas por la International Organization for
Standardization.
Todas las dems marcas registradas que se mencionan, usan o citan en la presente gua son
propiedad de los respectivos titulares.
Se citan estas marcas porque se consideran referentes en los temas que se tratan, buscando
nicamente fines puramente divulgativos. En ningn momento se busca con su mencin el uso
interesado de estas marcas ni manifestar cualquier participacin y/o autora de las mismas.
Nada de lo contenido en este documento debe ser entendido como concesin, por implicacin o de
otra forma, y cualquier licencia o derecho para las Marcas Registradas deben tener una autorizacin
escrita de los terceros propietarios de la marca.
Por otro lado, se renuncia expresamente a asumir cualquier responsabilidad relacionada con la
publicacin de las Marcas Registradas en este documento en cuanto al uso de ninguna en particular
y se eximen de la responsabilidad de la utilizacin de dichas Marcas por terceros.
El carcter de esta gua es nicamente formativo, buscando en todo momento facilitar a los lectores
la comprensin, adaptacin y divulgacin de las disciplinas, metodologas, estndares y normas
presentes en el mbito de la calidad del software.
ndice
NDICE
Prlogo......................................................................................................................... 5
1
Introduccin ............................................................................................................ 7
3 de 57
Prlogo
Prlogo
La sociedad en general cada vez reclama productos y servicios de mayor calidad. Esta
exigencia, junto con la frrea competitividad que caracteriza el mercado actual,
requiere de una actitud diferente por parte de las empresas, que impone la bsqueda
de la calidad y la adopcin de certificaciones. El futuro de toda empresa, incluidas las
PYME, pasa por una apuesta firme por la calidad, que d respuesta e incluso se
anticipe a las demandas de sus clientes.
El tejido empresarial espaol, compuesto principalmente por empresas de pequeo y
mediano tamao, es plenamente consciente de esta realidad y de la necesidad de
integrar la calidad y de adoptar prcticas y modelos que le guen hacia la misma. Una
muestra de ello es el balance final de las sucesivas convocatorias de ayudas del Plan
Avanza y Plan Avanza2, promovidas por el Ministerio de Industria, Turismo y
Comercio, que apuntan hacia una consolidacin en el inters de las PYME en abordar
modelos y certificaciones de calidad como un elemento, no ya de prestigio sino, de
utilidad real a la hora acometer sus procesos de negocio.
Existen distintos modelos de mejora de procesos que tratan de conducir hacia la
adopcin de calidad y la certificacin de las empresas como medio para impulsar la
industria de desarrollo del software en Espaa, siendo CMMI uno de los mejor
valorados en la actualidad porque constituye una referencia de reconocimiento
internacional. Sin embargo, la realidad muestra que no es fcil implementar este tipo
de modelos de mejora en cualquier empresa debido a la complejidad de algunos de
sus requisitos, que en ocasiones resulta excesiva para organizaciones con un tamao
y recursos limitados. A diferencia de las grandes empresas, las barreras que el
proceso de implantacin y certificacin representan para una PYME hacen que, en
algunos casos, disuadan a los responsables de adoptar tales iniciativas de mejora.
Algunos de los principales obstculos a los que se enfrenta la PYME a la hora de tratar
de implantar estos modelos son debidos a la inversin que conlleva su adopcin, al
escepticismo inicial ante los beneficios que puede aportar, al cambio en la filosofa de
trabajo y al cambio organizativo de creacin de un rea de calidad y especializacin
del personal cualificado. La labor desarrollada en estos aos en el marco del Ministerio
de Industria, Turismo y Comercio, con los referidos Planes Avanza y Avanza2, con la
creacin del Laboratorio Nacional de Calidad del Software de INTECO, y la magnfica
acogida de las iniciativas por parte de las empresas y sus asociaciones, han
contribuido a superar este tipo de barreras.
5 de 57
6 de 57
Introduccin
1 Introduccin
Existe una secuencia que se repite en cualquier industria que quiera mejorar su
rendimiento para:
-
7 de 57
Gestin de requisitos
Gestin de la configuracin
Aseguramiento de la calidad
Medicin y anlisis
Para cada uno de los procesos, se explicar lo que debera hacerse, siendo la
organizacin que lo aplica quien debe decidir cmo hacerlo, de acuerdo con sus
peculiares caractersticas. ltimamente dentro de las PYME tambin se ha
incorporado el concepto de mini-empresa, as que es fcil comprender que, si los
proyectos estn en consonancia con el tamao empresarial, aunque los procesos sean
los mismos, el alcance de su gestin es diferente y determinar los detalles de su
implantacin, por ejemplo, si se necesitar comprar herramientas para poder seguirlos,
el tipo de formacin que se precisar, si har falta el apoyo de expertos externos, el
tiempo que llevar conseguir que estn adoptados por todos los implicados, etc.
Independientemente del tamao de la empresa, es conveniente hacer una revisin de
la forma en que se realizan las actividades, con el fin de entender lo que tienen de
adecuado y lo que tienen de mejorable, tanto desde el punto de vista de la gestin de
la calidad (estndar ISO 9000) como desde el punto de vista especfico de la gestin
de la calidad del software (enfocado desde CMMI). Definir los objetivos de mejora,
seguir una gua para optimizar los procesos, escuchar las opiniones de las personas
que los estn llevando a cabo y definirlos de forma sencilla y clara, ayudar a mejorar
la calidad de los servicios y los productos. El Comit de la Calidad en los Sistemas y
las Tecnologas de la Informacin y las Comunicaciones de la AEC espera que esta
gua sea el primer paso para que se consigan esos objetivos.
8 de 57
Introduccin
Estructura de la gua
Antes de iniciar la lectura, debemos definir el concepto de proceso como se entiende
en esta gua, debido a que est estructurada apoyndose en el mismo.
Un proceso es la agrupacin de un conjunto de actividades necesarias para desarrollar
software. Los procesos considerados en esta gua son los que aparecen en el modelo
CMMI, bajo la denominacin rea de proceso.
La gua est estructurada de la siguiente forma:
Una introduccin
Un glosario de trminos.
ndice de abreviaturas
Bibliografa
9 de 57
10 de 57
2.2 Entradas
Las entradas mnimas necesarias para poder ejecutar las actividades de este proceso
son:
2.3 Prcticas
Las prcticas recomendadas para alcanzar los objetivos anteriores son:
GR.P1
Recepcin de requisitos.
Los requisitos que llegan al proyecto tienen que haber sido previamente
aprobados por el grupo que los solicita y llegar a travs de un canal vlido
para el proyecto. Una vez recibidos, stos son registrados por el proyecto,
con un cdigo que permita su identificacin.
11 de 57
Notas:
La previa aprobacin de los requisitos exige una reflexin y priorizacin por parte de la
fuente del requisito (cliente, usuario, grupos de soporte) que contribuye a la estabilidad
de los mismos, con independencia de que se identifiquen cambios con posterioridad.
Una prctica aconsejable es llegar a un consenso con respecto a los distintos canales
que se considerarn aceptables para la recepcin de los requisitos. Dependiendo de la
complejidad de la organizacin, se puede definir un circuito de comunicacin y
nombrar interlocutores vlidos en ambos equipos: usuarios y proyecto.
La identificacin de cada requisito a travs de un cdigo es imprescindible para su
tratamiento en este proceso de gestin de requisitos.
GR.P2
Revisin de requisitos.
Una vez registrados los requisitos, stos se revisan con dos objetivos:
asegurarse de que existe una comprensin comn sobre los mismos entre
los usuarios y el equipo del proyecto, y que la redaccin y contenido de los
mismos es la adecuada para su inclusin en el proyecto.
Los requisitos que superan satisfactoriamente la revisin son incorporados
al catlogo de requisitos. El resto es enviado al grupo de usuarios para
solventar el problema que se haya detectado debiendo quedar registrado
el acuerdo o solucin alcanzado.
Notas:
La aceptacin de los requisitos por parte del proyecto ayuda a anticipar problemas que
pueden surgir con posterioridad debido a un problema de calidad de los mismos. Una
buena prctica es definir los criterios que se van a utilizar para la aceptacin de los
requisitos, y comunicarlos al grupo de usuarios para que lo tenga en cuenta cuando
lleva a cabo el desarrollo de los mismos.
Ejemplos de criterios de aceptacin de requisitos pueden ser:
Es importante que los requisitos estn priorizados, (por el usuario los funcionales y por
el equipo de proyecto los no funcionales) y agrupados segn unos criterios
establecidos (funcionales, de calidad, de seguridad, de rendimiento). Esto permite
iniciar su implementacin en el momento adecuado, especialmente cuando el proyecto
presenta problemas de tiempo para la entrega y necesita reducir su alcance.
12 de 57
Al equipo del proyecto le puede resultar de utilidad llevar una contabilizacin de los
requisitos aceptados y rechazados, para futuros anlisis y definicin de acciones
correctoras.
GR.P3
Tienen que haber sido previamente aprobados por el grupo que los
solicita y llegar a travs de un canal vlido para el proyecto.
Nota:
Es importante mantener un histrico de cambios, de cuyo anlisis pueden sacarse
conclusiones positivas para el proyecto actual o posteriores proyectos.
GR.P4
Notas:
Es aconsejable definir un sistema de codificacin de los distintos elementos del
proyecto, que permita identificar de una forma sencilla todos los elementos asociados
a un mismo requisito. Asimismo, para facilitar la gestin de cambios, es conveniente
establecer las relaciones entre distintos requisitos.
13 de 57
GR.P5
Nota:
Esta actividad puede llevarse a cabo junto con otras actividades de seguimiento y
monitorizacin del proyecto.
2.4 Salidas
Las salidas de este proceso son:
14 de 57
3.2 Entradas
Las entradas mnimas necesarias para poder ejecutar las actividades de este proceso
son:
3.3 Prcticas
Las prcticas recomendadas para alcanzar los objetivos anteriores son:
PP.P1
15 de 57
PP.P2
Se deben definir los objetivos del proyecto y el alcance del trabajo a realizar. Se
deben evaluar las opciones disponibles para la consecucin de los objetivos del
proyecto y determinar, teniendo en cuenta las restricciones impuestas, los
riesgos y las oportunidades, la estrategia de alto nivel para el desarrollo de los
productos y/o servicios.
Nota:
Si los requisitos se han analizado adecuadamente, se pueden definir estrategias de
desarrollo para implementar en primer lugar las funciones crticas y en posteriores
iteraciones el resto de funcionalidades. En cada iteracin se puede pedir
retroalimentacin al cliente, esto permite que el cliente vea resultados cuanto antes y
que el desarrollo sea validado paulatinamente.
PP.P3
PP.P4
16 de 57
Nota:
Para la seleccin del ciclo de vida del proyecto, independientemente de si es un ciclo
de vida de desarrollo, de mantenimiento o conjuntamente de ambos, debera utilizarse
alguna de las mltiples metodologas presentes en la Ingeniera del Software.
PP.P5
PP.P6
PP.P7
17 de 57
Notas:
Especial atencin deben merecer los paquetes del camino crtico y aqullos que vayan
a ser desarrollados por proveedores, si los hay, para que las entregas a cliente se
realicen en los plazos y calidad pactados.
Es aconsejable que las tareas del camino crtico se desarrollen en la organizacin a
menos que el proveedor sea muy fiable.
PP.P8
PP.P9
PP.P10
Como parte de la estrategia del proyecto, se deben identificar los riesgos del
proyecto, analizarlos y priorizarlos. Se deben analizar como mnimo los riesgos
relacionados con costes, calendario y aspectos tcnicos. Se debe evaluar la
probabilidad de ocurrencia de los riesgos, su impacto y las causas de los mismos
con objeto de determinar la prioridad a la que aplicar los recursos necesarios
para mitigar esos riesgos.
18 de 57
Nota:
Es vital evitar confundir problemas (que son hechos) con riesgos (que son posibilidad
de existencia de un problema). Los riesgos son posibles ocurrencias de un hecho
negativo, un problema, que si llegase a ocurrir tendra un impacto negativo en el
proyecto. Mientras que un problema es una situacin real que ya est impactando
negativamente en el proyecto. El riesgo requiere un plan de eliminacin o mitigacin
en funcin de su criticidad. Un problema requiere de una actuacin inmediata.
PP.P11
Ciclo de vida
Calendario / Cronograma
Nota:
Se entiende que no es necesario redactar un documento formal que refleje el Plan de
Proyecto, ya que lo fundamental es disponer de toda esta informacin para que sea
posible hacer el seguimiento del proyecto basndose en ella. Por otra parte, se
considera una buena prctica realizar dicho documento, sobre todo cuando se est
implantando este rea de proceso, ya que ayuda a institucionalizar la elaboracin del
Plan de Proyecto.
Otra buena prctica es plasmar el calendario de proyecto en forma de Diagrama de
GANTT y/o en Diagrama PERT.
PP.P12
Se debe obtener el compromiso por parte de todas las partes interesadas (tanto
internas como externas) para la ejecucin del Plan de Proyecto. Ello implica que
el Plan de Proyecto debe acordarse con el cliente. Las personas y grupos que
suscriban el compromiso deben tener la confianza de que el trabajo puede
realizarse dentro de los costes, calendario y desempeo establecido. Se
asegurar que los acuerdos son entendidos y aceptados, financiados y
realizables.
19 de 57
Nota:
El plan del proyecto tiene que estar aceptado formalmente por los representantes del
proveedor y del cliente (externo o interno)
3.4 Salidas
Las salidas de este proceso son:
Paquetes de trabajo
20 de 57
4.2 Entradas
Las entradas mnimas para iniciar este proceso son:
Plan de proyecto
Cronograma
21 de 57
4.3 Prcticas
Las prcticas recomendadas para alcanzar el objetivo son:
SCP.P1
El control significa comparar siempre el estado actual con las estimaciones que
sirvieron de base a la planificacin. Esto implica la existencia de un plan de
mediciones peridicas. Estos parmetros incluyen especialmente los esfuerzos
dedicados al proyecto, el porcentaje de avance de las tareas y productos, los
costes, y la utilizacin de recursos.
Nota:
La finalidad ms importante de este control es proporcionar al jefe de proyecto la
informacin precisa y necesaria para poder actuar sobre las desviaciones detectadas,
y tomar decisiones, en el momento oportuno. Para ello, por ejemplo, es buena practica
que se registre peridicamente (a ser posible diariamente) el esfuerzo dedicado a la
realizacin de las tareas as como el % de avance en las mismas, o en los productos,
por parte del equipo del proyecto para que el responsable del mismo pueda conocer el
estado real del proyecto respecto a lo planificado.
SCP.P2
Aqu se hace referencia tanto a los compromisos internos como a los externos de
la organizacin. La revisin de los compromisos consiste en comprobar que
estamos contando con los recursos y el tiempo necesarios para alcanzar el xito
del proyecto, tal y como figura en el plan de proyecto vigente.
Nota:
No olvidar la revisin de los compromisos con terceras partes definidos en el acuerdo
con proveedores.
SCP.P3
22 de 57
Nota:
Nunca se debe considerar como un riesgo lo que es un hecho, pues la gestin ser
totalmente diferente. Como ejemplo, no tener los recursos necesarios cuando se
necesitan no es un riesgo sino un hecho, que requiere no un plan de mitigacin sino
actuacin inmediata. Un riesgo seria el que unos recursos comprometidos para una
tarea se puedan retrasar, o puedan llegar sin la competencia adecuada.
SCP.P4
SCP.P5
SCP.P6
23 de 57
SCP.P7
4.4 Salidas
Las salidas de este proceso son:
Informes del estado del proyecto que den visibilidad a la direccin, que recojan los
datos numricos obtenidos, los riesgos ms significativos, los problemas
encontrados y las acciones correctoras que se estn llevando a cabo:
-
Actas resultantes de las reuniones del equipo del proyecto, con las personas
involucradas.
24 de 57
5.2 Entradas
Las entradas mnimas necesarias para poder ejecutar las actividades de este proceso
son:
Requisitos (funcionales y no funcionales) a implementar en un producto a desarrollar
por el proveedor o a cubrir con el producto de mercado (COTS) a adquirir
Decisin de subcontratar el trabajo o comprar el producto
Lista de proveedores preferidos por la organizacin (si la hay)
Procedimiento de subcontratacin de la organizacin (si existe)
25 de 57
5.3 Prcticas
Las prcticas recomendadas para alcanzar el objetivo son:
GAP.P1
Decisin de subcontratar
GAP.P2
GAP.P3
Seleccionar el proveedor
26 de 57
Notas:
Es importante, en esta evaluacin, revisar los registros previos de trabajos similares y,
dependiendo del tipo de adquisicin, las capacidades del proveedor en trminos de
competencia y experiencia de sus ingenieros de software, del equipo de gestin y de
los recursos materiales de que dispone.
En la seleccin hay que tener en cuenta las estimaciones propias de coste y esfuerzo
para ese trabajo, con el fin de seleccionar no el ms barato, ni el ms rpido, sino
aqul que nos da la confianza y la garanta de que llevar a cabo el trabajo segn lo
pactado.
En la ingeniera del software no hay magia y el trabajo bien hecho y el cumplimiento de
los compromisos requiere de unos procesos eficaces y una competencia y experiencia
por la que hay que estar dispuesto a pagar lo que vale.
GAP.P4
el plan de tiempos
el presupuesto
Notas:
El acuerdo hay que formalizarlo lo ms detalladamente posible, teniendo en mente que
siempre vamos a tener que recurrir a l. Este es el momento de hacer gestin
(anticipar los riesgos y eliminarlos de entrada) en lugar de control (resolver los
problemas cuando los riesgos se han materializado). Los proyectos software, por
experiencia, tienen pocas probabilidades de xito al 100%, siempre habr cambios y
siempre habr interpretaciones. Por esta razn, cuanto ms tiempo pongamos en
27 de 57
redactar bien el acuerdo, ms beneficioso para ambas partes ser. Es muy importante
que quede fijado quines son los responsables, y tienen la autoridad, para realizar
cambios al contrato.
Es imprescindible que se determinen las dependencias crticas entre el trabajo del
proveedor y el proyecto, y que se determinen las posibles penalizaciones que se
aplicarn por incumplimientos. Estas penalizaciones deben ser tales que sea ms
beneficioso para el proveedor cumplir el contrato que pagar penalizaciones.
GAP.P5
Nota:
Si adems de lo anterior acordamos revisiones tcnicas, de gestin y de procesos,
entonces nos aseguraremos que el acuerdo se ejecutar satisfactoriamente y que
siempre podemos ayudar a tiempo al proveedor antes de que los problemas surjan.
GAP.P6
GAP.P7
28 de 57
GAP.P8
5.4 Salidas
Las salidas de este proceso son:
29 de 57
6.2 Entradas
Las entradas necesarias para poder ejecutar las actividades de este proceso son:
Necesidades de informacin
6.3 Prcticas
Las prcticas recomendadas para alcanzar el objetivo son:
MA.P1
31 de 57
Notas:
Se debe juzgar si el valor de los resultados obtenidos compensa los recursos
necesarios para desarrollar este proceso.
Es importante suministrar retroalimentacin para depurar y clarificar los objetivos y
comprobar si stos sirven para satisfacer las necesidades de informacin, as como
mantener la trazabilidad de los objetivos de medicin para reflejar la posible evolucin
de los objetivos del proyecto o negocio y las necesidades de informacin.
MA.P2
Especificar medidas.
-
Notas:
Normalmente los indicadores que dan informacin son el resultado de operar con
medidas bsicas (esfuerzos, tiempo, tamao,..). Para cada objetivo del proyecto, se
tiene que averiguar qu indicador da la informacin necesaria para saber el grado en
que se est alcanzando. Ese indicador es el resultado de operar con unas medidas
bsicas y stas son las medidas que se deben recopilar.
Se debe empezar por un conjunto mnimo razonable de medidas y luego ir aadiendo
ms segn vayamos detectando nuevas necesidades de informacin y,
fundamentalmente, siempre que veamos que las medidas son realmente usadas para
la toma de decisiones. Medidas habituales son: esfuerzo, tiempo, nmero de
requisitos, nmero de cambios solicitados, errores encontrados, errores corregidos,..
MA.P3
Identificar las medidas para las cuales son necesarios datos que an
no se encuentran disponibles
32 de 57
Notas:
Se deben de considerar cuestiones como frecuencias y momentos de toma de datos.
Estos datos se deben archivar en alguna base de datos, se debe establecer quin
obtiene los datos, quin es responsable del almacenamiento, recuperacin y control de
acceso a los datos obtenidos y si son necesarias herramientas de apoyo.
Los mecanismos de toma de datos pueden ser manuales o automatizados, y se debe
suministrar la formacin adecuada.
La cantidad de esfuerzo requerido y la importancia relativa de las medidas pueden ser
motivo de actualizacin o redefinicin de medidas y/o objetivos de medicin.
MA.P4
Notas:
La presentacin de los resultados debe ser fcilmente comprensible por todas las
partes interesadas. Se debe examinar la relacin entre las distintas medidas
especificadas. Se debe identificar la persona o grupo responsable de analizar los
datos y presentar los resultados. Es preciso que las personas que hacen el anlisis
tengan un buen conocimiento de la organizacin que les permita interpretar las
medidas teniendo en cuenta el contexto y tambin que conozcan fundamentos de
estadstica.
MA.P5
33 de 57
Notas:
Se deben chequear y corregir en su caso las inconsistencias detectadas en la
clasificacin de los datos de las medidas.
Se debe examinar de forma emprica las relaciones entre las medidas usadas para
calcular las medidas derivadas.
MA.P6
Nota:
Una buena prctica, cuando se hace el anlisis de los datos, es proponer acciones
basadas en los resultados. De esta forma, los datos valdrn para tomar decisiones
avaladas con acciones derivadas del anlisis.
MA.P7
Notas:
Es importante que las medidas se utilicen exclusivamente para satisfacer las
necesidades de informacin especificadas. En ningn caso deben utilizarse para
evaluar rendimientos personales, de lo contrario las medidas pueden desvirtuarse
intencionadamente.
MA.P8
34 de 57
Notas:
Se debe tener en cuenta que por norma general los datos de las mediciones no son
evidentes para aquellas personas que no son expertos en la materia, por ello se
debera explicitar lo ms claramente posible cmo y por qu se especifican las
medidas base y derivadas, cmo se obtienen los datos, cmo se interpretan los
resultados y cmo stos de adaptan para cubrir las necesidades de informacin que
generaron la medicin.
La asistencia a la comprensin puede incluir acciones como dialogar sobre los
resultados con las partes interesadas, proporcionar formacin sobre las mediciones,
suministrar antecedentes de la medicin y su explicacin, etc.
Antes de hacerlos pblicos es muy importante que los datos comunicados estn
validados por las partes interesadas, es decir aquellos que se vern representados
por los resultados.
6.4 Salidas
Las salidas de este proceso son:
Objetivos de medicin
35 de 57
independiente
de
los
incumplimientos,
su
7.2 Entradas
Las entradas mnimas necesarias para poder ejecutar las actividades de este proceso
son:
37 de 57
7.3 Prcticas
Notas:
Dado que esta rea de proceso no suele estar muy consolidada, es necesario
comenzar por una reflexin para determinar qu expectativas tiene la organizacin
respecto a la evaluacin independiente de los procesos y productos y con qu alcance
y, por tanto, con cuntos recursos est dispuesto a abordar esta tarea. El personal
debe tener la formacin adecuada, y la metodologa de trabajo debe ser difundida a
toda la organizacin en una clara labor de sensibilizacin y compromiso.
Una vez adoptado el planteamiento decidido, se deber afrontar la tarea de
preparacin de la documentacin de trabajo de esta rea de proceso:
Aunque esta es una prctica genrica en los modelos de madurez, por la peculiaridad
de esta rea de proceso se ha considerado conveniente describirla, ya que conviene
considerarla en primer lugar en las organizaciones que no la tengan implementada o
plantearse reconsiderarla en aquellas en la que ya se est realizando.
38 de 57
Notas:
La objetividad de la evaluacin estar fundamentada en la independencia del equipo
evaluador y en la sistematizacin de su trabajo mediante el uso de procedimientos y
listas de chequeo diseadas para comprobar el cumplimiento de las polticas,
procedimientos, estndares y reglas vigentes, as como de los criterios de revisin,
que aseguran la homogeneidad de las revisiones.
las
acciones
correctoras
39 de 57
N de No-conformidades detectadas
N de No-conformidades resueltas.
Tendencias de la calidad
Notas:
Los beneficios fundamentales de esta prctica son la consolidacin de este proceso
por las ventajas que supone, por un lado, ofrecer a la direccin datos cuantitativos de
los resultados del mismo y, por otro, el nivel de gestin que exige organizar la
actividad, de forma que se pueda obtener toda esta informacin.
En los modelos de madurez, el disponer de este nivel de gestin es requisito
imprescindible para alcanzar el primer escaln de reconocimiento.
La puesta en marcha en una organizacin de cualquier nueva tarea suele necesitar de
un periodo de adaptacin mnimo. Por ello, hasta que no haya transcurrido ste, no es
necesario formalizar documentalmente el proceso de aseguramiento de la calidad.
Una vez alcanzada esta situacin, o si ya se parta de ella, para avanzar en la
madurez del proceso, ser necesario registrar el resultado de los anlisis de las
tendencias de calidad, de la identificacin de las oportunidades de mejora y del
resultado del proceso de mejora, que lgicamente se pondr en marcha (definicin de
acciones de mejora, priorizacin, planificacin, implantacin, seguimiento, medida,
lecciones aprendidas).
Esta es tambin una prctica genrica en los modelos de madurez, pero por la
peculiaridad citada de ser el AC un rea poco consolidada, o que probablemente haya
sido necesario reorientar, se ha considerado conveniente describirla para poder
aplicarla y alcanzar un nivel intermedio de madurez.
40 de 57
7.4 Salidas
Las salidas de este proceso son:
Lecciones aprendidas
Tendencias de la calidad
41 de 57
8.2 Entradas
Las entradas mnimas necesarias para poder ejecutar las actividades de este proceso
son:
Planes de proyecto
Base de diseo
8.3 Prcticas
Las prcticas recomendadas para alcanzar los objetivos anteriores son:
GC.P1
43 de 57
este sentido puede ser tan importante un requisito de cliente como un estndar
que debamos cumplir, o un simple parmetro de cuyos valores pueda depender
la conducta del sistema.
Notas:
Ejemplos de elementos de configuracin:
Cdigo fuente
GC.P2
GC.P3
Hay que identificar las lneas de referencia que van a establecerse en el proyecto
y los elementos de configuracin que constituyen cada lnea de referencia.
Notas:
En proyectos considerados pequeos se recomienda limitar las lneas de referencia a
tres:
GC.P4
44 de 57
Notas:
Los elementos de configuracin pasan a formar parte de la lnea de referencia en el
momento en que se aprueban. Slo aquellos elementos de configuracin que hayan
sido aprobados podrn pasar a formar parte de la lnea de referencia. Cada elemento
de configuracin se aprueba en un determinado momento del ciclo de vida,
normalmente asociado a una determinada revisin dentro del ciclo. Ejemplos: los
requisitos cuando se revisen con el cliente y se acuerden; la especificacin de diseo,
cuando se haga la revisin formal; el cdigo fuente cuando se haya generado el primer
modulo (o build); los planes de proyecto cuando se hayan aprobado por el cliente.
GC.P5
GC.P6
45 de 57
GC.P7
Debe existir una librera o repositorio oficial del proyecto donde guardar copias
maestras del cdigo y la documentacin durante toda la vida del producto.
Notas:
El acceso al sistema debe estar controlado. Slo las personas autorizadas podrn
almacenar y/o tener acceso a los elementos de configuracin. Se debe preservar el
contenido del sistema (mediante copias de seguridad back up)
GC.P8
GC.P9
GC.P10
46 de 57
8.4 Salidas
Las salidas de este proceso son:
47 de 57
Glosario de Trminos
9 Glosario de Trminos.
rea de proceso
Aseguramiento
de la calidad
Auditora de la
configuracin
Base de diseo
Camino crtico
Comit de control
de cambios
Componente del
producto
Control de la
configuracin
49 de 57
Control de
versiones
Criterio de
aceptacin
Criterio de
comienzo
Situacin que debe existir para que una accin se pueda empezar
adecuadamente.
Criterio de
finalizacin
Situacin que debe existir para que una accin se pueda dar por
terminada adecuadamente
Elemento de
configuracin
Estructura de
desglose de
tareas
Gestin de la
configuracin
Gestin de
requisitos
Gestin de
riesgos
Hito (Milestone)
50 de 57
Glosario de Trminos
Identificacin de
la configuracin
Lnea de
referencia de
configuracin
Medicin
Medida
Medida derivada
Modelo de ciclo
de vida
Plan de
desarrollo
Plan de proyecto
Producto
Prueba de
aceptacin
Requisito
51 de 57
Requisitos no
tcnicos
Requisitos
tcnicos
Trazabilidad de
los requisitos
52 de 57
ndice de Abreviaturas
10 ndice de abreviaturas.
CMMI
AEC
DoD
ISO
GR
PP
SCP
GAP
COTS
MA
ACPP
GC
HW
Hardware
SW
Software
53 de 57
Bibliografa
11 Bibliografa.
CMMI for Acquisition, Version 1.2 Improving processes for acquiring better products
and services by Software Engineering Institute (SEI) November 2007.
CMMI for Development, Version 1.2 Improving processes for better products by
Software Engineering Institute (SEI) August 2006
55 de 57
Autores
Autores
La primera versin de la presente gua fue elaborada por los componentes del Grupo
de trabajo del Comit de la Calidad en los Sistemas y las Tecnologas de la
Informacin y las Comunicaciones de la AEC, constituido para ese fin y revisado y
aprobado por la totalidad de los miembros del Comit el 11 de marzo de 2008.
Posteriormente se realizado esta versin con las aportaciones realizadas por el
personal del INTECO.
57 de 57