Sei sulla pagina 1di 39

Buyer: richard mercado (rmercador642@hotmail.

com)
Transaction ID: jg-ne8a2be6290ce40

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

Gua prctica de supervivencia


en una auditora CMMI

Javier Garzs Parra


Emanuel A. Irrazbal
Roberto Santa Escolstica

Segunda edicin: Mayo de 2011


ISSN: 2172-6620 2011-002
Boletn de la Escuela Tcnica Superior de Ingeniera Informtica Universidad Rey Juan
Carlos.

Kybele Consulting

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

Dedicado a todos aquellos responsables de implantar CMMI en su organizacin y superar la adversidad para
conseguirlo.

Kybele Consulting

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

ndice de contenidos
ndice de contenidos __________________________________________________________ 3
Prefacio ____________________________________________________________________ 7
1

Las auditoras CMMI____________________________________________________ 10


1.1

Qu es un SCAMPI y quin lo realiza? __________________________________ 10

1.2

Quin respalda una auditora CMMI? ____________________________________ 10

1.3

Durante cunto tiempo son vlidos los resultados de la evaluacin? ______________ 11

1.4

Es necesario evaluar todas las reas de proceso? _____________________________ 11

1.5

Qu costes internos han de tenerse en cuenta? ______________________________ 11

Fases y la duracin de la auditora ___________________________________________ 12

Los proyectos que sern auditados y la unidad organizacional_______________________ 13


3.1

La unidad organizacional _______________________________________________ 13

3.2

La muestra de proyectos _______________________________________________ 13

Los participantes en la auditora _____________________________________________ 15

La fase Readiness review ________________________________________________ 17


6

Los indicadores de implementacin de la prctica (PII) y la base de datos de indicadores

(PIIDB) ___________________________________________________________________ 18
6.1
7

La PIIDB __________________________________________________________ 20
Ejemplo de PIIDB ______________________________________________________ 21

7.1

Prcticas genricas de nivel 2 ____________________________________________ 21

7.2

rea de proceso: Gestin de Acuerdos con Proveedores (SAM) _________________ 22

7.3

rea de proceso: Gestin de requerimientos (REQM) _________________________ 23

7.4

rea de proceso: Planificacin de Proyecto (PP) _____________________________ 24

7.5

rea de proceso: Monitorizacin y Control del Proyecto (PMC) _________________ 26

7.6

rea de Proceso: Gestin de Configuracin (CM) ____________________________ 27

7.7

rea de proceso: Medicin y Anlisis (MA) _________________________________ 28

7.8

rea de proceso: Aseguramiento de la Calidad del Proceso y del Producto (PPQA) ___ 29
El mtodo de evaluacin __________________________________________________ 30
Kybele Consulting

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

8.1

Cumplir con las prcticas genricas (GP) y especficas (SP)______________________ 30

8.2

Cumplir con las metas genricas (GG) y especficas (SG) _______________________ 32

8.3

Cumplir con el rea de proceso __________________________________________ 32

8.4

Cumplir con el nivel de madurez _________________________________________ 33

Glosario de trminos _____________________________________________________ 34

10

Referencias___________________________________________________________ 35

Las reas de proceso de CMMI ____________________________________________ 36


A.1

Nivel de madurez 2 ___________________________________________________ 36

A.2

Nivel de madurez 3 ___________________________________________________ 36

A.3

Nivel de madurez 4 ___________________________________________________ 37

A.4

Nivel de madurez 5 ___________________________________________________ 37

Kybele Consulting

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

Sobre los autores


JAVIER GARZS PARRA
(javier.garzas@urjc.es, javier.garzas@kybeleconsulting.com)
Doctor (Ph.D.) (cum laude por unanimidad) e Ingeniero Superior en Informtica (premio
extraordinario). Actualmente trabaja en la empresa Kybele Consulting S.L. (empresa spin off del
grupo de investigacin de la Universidad Rey Juan Carlos), es profesor Titular en la Universidad Rey
Juan Carlos y edita el blog www.javiergarzas.com.
Cuenta con certificaciones de Auditor Jefe de TICs (Calificado por AENOR) para ISO 15504
SPICE ISO 12207, Auditor ISO 20000 por ITSMF, Especializacin en Enterprise Application
Integration (premiado por Pricewaterhousecopers), CISA (Certified Information Systems Auditor),
CGEIT (Certified in the Governance of Enterprise IT) y CRISC (Certified in Risk and Information
Systems Control) por la ISACA, CSQE (Software Quality Engineer Certification) por la ASQ
(American Society for Quality), Introduction CMMI-Dev y Acquisition Supplement for CMMI v1.2
(CMMI-ACQ) e ITIL V3 Foundation.
Actualmente es socio-director de KYBELE CONSULTING, liderando varios proyectos en
administraciones y empresas como INFORMTICA DE LA COMUNIDAD DE MADRID
(ICM), RENFE, DIRECCIN GENERAL DE TRFICO (DGT), MINISTERIO DE
ADMINISTRACIONES PBLICAS (MAP), SISTEMAS TCNICOS DE LOTERAS (STL),
AENOR, etc.
Comenz su carrera profesional como consultor senior y responsable del centro de competencias en
ingeniera del software, desde donde participa en proyectos para TELEFNICA MVILES
CORPORACIN, INDRA trfico areo o la automatizacin de la simulacin de la de la rotativa de
EL MUNDO. Ms tarde fue responsable de calidad software y de proyectos de mCENTRIC.
Posteriormente, DIRECTOR EJECUTIVO Y DE INFORMTICA de la empresa de desarrollo
de ERPs para la gestin universitaria como mayor nmero de clientes en Espaa. Experto en
gestin y direccin de departamentos y fbricas software (realizando implantaciones de fbricas y
mejoras en Espaa, Colombia, Chile y Venezuela), con una amplia experiencia en ingeniera del
software, calidad y mejora de procesos (participacin en la mejora, evaluacin o auditora de
procesos CMMI o ISO 15504 en ms de 30 empresas).
Ha sido profesor de en la UNIVERSIDAD DE CASTILLA LA MANCHA y desde 2004
comparte su actividad profesional con la docente como profesor Titular en la UNIVERSIDAD
REY JUAN CARLOS.
Ha participado en numerosos proyectos de I+D nacionales e internacionales, ponencias, editado
varios libros (destacando el primer libro en castellano sobre fbricas software) y publicado ms de 60
trabajos de investigacin. Evaluador de la ANEP (Agencia Nacional de Evaluacin y Prospectiva) y
experto certificado por AENOR para la valoracin de proyectos I+D.
Miembro de varias asociaciones informticas destacando la AEC (Asociacin Espaola de la
Calidad) (vocal), Colegio de Ingenieros en Informtica de Castilla y Len (miembro de la junta de
gobierno), ISACA (Information Systems Audit and Control Association), ASQ (American Society
Kybele Consulting

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

for Quality) y del SC7 de AENOR.

EMANUEL A. IRRAZABAL
(emanuel.irrazabal@urjc.es, emanuel.irrazabal@kybeleconsulting.com)
Ingeniero Superior en Informtica y Mster Oficial en Tecnologas de la Informacin y Sistemas
Informticos por la Escuela Superior de Ingeniera Informtica Universidad Rey Juan Carlos.
Actualmente se encuentra realizando su tesis doctoral sobre la Ingeniera del Software basada en
Valor. CISA (Certified Information Systems Auditor) por la ISACA (Information Systems Audit
and Control Association).
Desde 2009 es CONSULTOR SENIOR de KYBELE CONSULTING, trabajando en varios ms
de 20 proyectos de mejora y/o evaluacin con CMMI e ISO /IEC 15504.
Desde abril 2008 hasta noviembre 2008 trabaj como responsable de calidad en una empresa de
desarrollo para la banca. Tambin ha trabajado como analista desarrollador y analista funcional de
Web Applications con .Net 2005, SCRUM, Test Driven Development., pruebas unitarias (NUnit),
funcionales (Fitnesse) e integracin continua para Espaa y Estados Unidos.
Desde 2009 es profesor asociado de la UNIVERSIDAD REY JUAN CARLOS.

ROBERTO SANTA ESCOLSTICA


(roberto.santaescolastica@kybeleconsulting.com)
Ingeniero Superior en Informtica y Mster Oficial en Tecnologas de la Informacin y Sistemas
Informticos por la Escuela Superior de Ingeniera Informtica de la Universidad Rey Juan Carlos.
Desde 2010 es consultor de KYBELE CONSULTING, habiendo trabajado en varios proyectos de
mejora y/o evaluacin de procesos software con CMMI e ISO/IEC 15504.
Anteriormente trabaj como investigador para la UNIVERSIDAD REY JUAN CARLOS,
centrado en el estudio de modelos de medicin de la calidad software y de la Ingeniera del Software
basada en Valor.

Kybele Consulting

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

Prefacio

nfrentarse por primera vez a una auditora CMMI [1] supone tener que superar una gran
carga de actividades y enfrentarse a una gran cantidad de terminologa nueva y compleja. A
esto se aade que es habitual que las empresas, inmersas en su rutina diaria, no dispongan
de mucho tiempo para preparar las auditoras.

Bajo estos precedentes, conscientes de la necesidad cada vez mayor por parte de las empresas de
disponer de certificaciones software, pretendemos con esta gua facilitar la tarea de preparacin de
una auditora CMMI, ayudando a reducir el importante sobreesfuerzo que supone su realizacin.
Pretendemos que esta gua sea un manual de supervivencia a la hora de enfrentarse a una auditora
de CMMI. Y como tal herramienta de supervivencia, proporciona lo ms bsico y esencial para
poder afrontar la auditora y de ah que hayamos pretendido que no supere 40 pginas1 de enfoque
puramente prctico, an a arriesgo de obviar por ello algn detalle o matizacin terica, pero para
este tipo de detalles existen otros muchos libros.
Comentar tambin, que este no es un documento de consultora, y tampoco est enfocado a
implantar CMMI o mejorar los procesos software, eso lo dejamos para otros textos. Este es un
documento esencialmente de preparacin para la auditora, que normalmente te ser de utilidad si
has liderado una mejora CMMI y en breve te enfrentars a la auditora o si te han invitado a
participar en el equipo de auditora.

Aclaracin sobre la terminologa


El trmino auditora. Siendo rigurosos, ms que auditora en CMMI el trmino correcto sera
evaluacin, que proviene del trmino anglosajn appraisal y que es el que se usa en CMMI. Sin
embargo, durante el texto utilizaremos la palabra auditora por ser la ms utilizada en el da a da
de las empresas, facilitando as el objetivo de simplificar la terminologa de cara a la preparacin de
una auditora CMMI.
Niveles de madurez y capacidad. CMMI define dos maneras de evaluar los procesos, por niveles
de capacidad (representacin continua) y por niveles de madurez (representacin por etapas). La ms
comn es esta ltima, que permite la obtencin de un nivel de madurez para la organizacin. Por
ello, durante esta gua cuando hablamos de la auditora nos referiremos nicamente a la evaluacin
por niveles de madurez.
Terminologa en ingls. A lo largo de esta gua, en ocasiones aparecern ciertas expresiones en
ingls relacionadas con la auditora. Hemos decidido mantener esta terminologa en ingls debido a
que es la que se utiliza comnmente durante la auditora, y con la que deberemos acabar
familiarizndonos.
Trminos en castellano. Para mantener la mayor rigurosidad posible, los trminos utilizados en
esta gua y relacionados con CMMI que estn en castellano han sido extrados de la traduccin
realizada por la Ctedra de Mejora de Procesos de Software en el Espacio Iberoamericano de la
Universidad Politcnica de Madrid, publicada por el SEI como traduccin de la versin 1.2 de
CMMI for Development y titulada CMMI: Gua para la integracin de procesos y la mejora de
1

La versin en papel, por razones de formato, consta de 76 pginas


Kybele Consulting

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

productos [2].

Versin del modelo


Esta gua est basada en la versin 1.2 del mtodo SCAMPI (ver captulo 1) de CMMI [3]. En el
momento de elaboracin de esta gua, la versin 1.3 [4] del citado mtodo ya ha sido liberada. Sin
embargo, la versin 1.2 es an la de mayor uso y sobre la que se tiene una mayor experiencia, por lo
que esta gua entra en detalle en esa versin del mtodo. Los detalles ms importantes en los que se
diferencian las versiones 1.2 y 1.3 del SCAMPI son comentados a lo largo de esta gua. Por otro
lado, si bien existen actualmente 3 constelaciones CMMI, este documento se centra en la
constelacin CMMI-DEV, que corresponde a desarrollo.

Cambios respecto a la versin anterior


Esta nueva versin de la Gua Prctica de Supervivencia en una Auditora CMMI supone una
mejora respecto a la primera versin. Para ello, varios revisores han colaborado en la revisin de la
gua y han contribuido con sus comentarios a evolucionarla.
Entre los principales cambios realizados, destacan los cambios en alguna de la terminologa utilizada.
Se ha trabajado tambin en aclarar alguna de las afirmaciones que se realizaban durante la gua y que
podan llevar a confusin al lector. Otro de los cambios introducidos es la cuantificacin del tiempo
que lleva completar una base de datos de evidencias. Adems, se han corregido tambin pequeos
errores o inexactitudes que aparecan en la versin anterior.
Todos estos cambios, junto con otras pequeas mejoras y la correccin de pequeos errores
gramaticales y de formato, han modificado el contenido original para conformar la Segunda Edicin
de la Gua de Supervivencia en una Auditora CMMI.

Informacin relacionada
Si quieres estar al da de todo lo relacionado con la calidad software, te recomendamos:
www.javiergarzas.com
www.fabricasdesoftware.es
www.iso15504.es
www.kybeleconsulting.com
O las redes sociales:
@calidadsoftware
Ingeniera del Software
Calidad en el Software y los Sistemas de Informacin (CSSI)
ISO 15504.es SPICE - Calidad Software - Espaa y Latinoamrica
Kybele Consulting

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

Agradecimientos
Agradecer en primer lugar a la Universidad Rey Juan Carlos y a Kybele Consulting el apoyo
brindado en la realizacin de esta gua. Por otro lado, nos resultara imposible citar a todas las
personas que con sus sugerencias y comentarios han contribuido a que sea posible la realizacin de
esta gua. An as, queramos destacar la labor de revisin, las sugerencias y los comentarios
realizados por:
Miguel Buitrago, de SEQUAL.
Carlos Miguel Franco, de SQA.
Domingo Gaitero Gordillo, de ATOS Origin.
Manuel A. Montero Cascales, de Ingeniera e Integracin Avanzadas (Ingenia)
Lic. Horacio Recinos Roca.

Javier Garzs Parra


Emanuel A. Irrazbal
Roberto Santa Escolstica
Mstoles, Madrid, mayo de 2011

Kybele Consulting

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

Captulo

1
1 Las auditoras CMMI

uando una organizacin ha conseguido mejorar sus procesos e implantar los


correspondientes a un nivel de madurez CMMI (ver anexo A), es comn que decida que
ha llegado el momento de presentarse a una auditora que corrobore dicha implantacin
por un tercero, un auditor externo. Y es ah cuando aparecen una serie de peculiaridades,
tareas y trminos que suelen causar mucha confusin en el equipo de mejora. En este captulo
aclararemos las principales dudas de carcter general que se plantean en el momento de comenzar
con una auditora CMMI.

1.1 Qu es un SCAMPI y quin lo realiza?


Se denomina as a la evaluacin o auditora final de concesin oficial de un nivel de madurez de
CMMI. SCAMPI es el acrnimo de Standard CMMI Appraisal Method for Process Improvement
[3]. Este es un mtodo sobre cmo evaluar los diferentes procesos de la organizacin, definiendo el
nivel de madurez. Se distinguen tres tipos de SCAMPI (A, B C) en funcin de la formalidad y la
dificultad del mismo. El ms riguroso es el SCAMPI A y es el que permite obtener el nivel de
madurez oficial. Una vez superado el SCAMPI A, es comn que la organizacin reciba un diploma
acreditativo que indica el nivel de madurez alcanzado.
El SCAMPI A debe ser realizado por una figura denominada Lead Appraiser. El Lead Appraiser es
una persona acreditada por el SEI (Software Engineering Institute, organizacin propietaria del modelo
CMMI) para realizar la evaluacin CMMI. Finalmente, es el Lead Appraiser quin emite lo que se
conoce como Appraisal Disclosure Statement, documento que muestra los resultados de la
evaluacin [5].

1.2 Quin respalda una auditora CMMI?


Comnmente se piensa que es el Software Engineering Institute (SEI), ya que es la organizacin
propietaria del modelo. Sin embargo, el SEI solamente acredita a los auditores o Lead Appraiser
para que puedan realizar evaluaciones CMMI. No es el SEI quien emite un certificado, sino que son
los auditores los que emiten un diploma en el que se indican los datos y resultados de la auditora.
Son estos auditores y las empresas partner del SEI en las que trabajan los que se responsabilizan de
los resultados de la evaluacin. Tras la realizacin de un SCAMPI, el Lead Appraiser enva una serie
de documentos al SEI para que este realice chequeos y controles de calidad del SCAMPI. Una vez
terminados estos chequeos, el SEI enva una comunicacin al sponsor y al Lead Appraiser del
SCAMPI aprobndolo para uso pblico. Desde este momento, los resultados se publican en el
PARS (Published Appraisal Results) del SEI [5].
Por ello normalmente se utiliza el concepto evaluacin en vez de certificacin cuando nos referimos
a una auditora CMMI.
Kybele Consulting

10

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

1.3 Durante cunto tiempo son vlidos los resultados de la


evaluacin?
Los resultados de la evaluacin son vlidos durante un mximo de 3 aos desde la fecha en que se
emite el Appraisal Disclosure Statement.

1.4 Es necesario evaluar todas las reas de proceso?


En funcin del nivel de madurez que se pretenda alcanzar, ser necesario evaluar una serie de reas
de proceso. Todas las reas de proceso correspondientes a un nivel de madurez son obligatorias a
excepcin de SAM (Supplier Agreement Management) (ver anexo A para el listado completo de
reas de proceso de CMMI por nivel de madurez), que puede no ser aplicable a la organizacin y por
tanto no ser evaluada. Para que esta rea de proceso no sea evaluada, ha de justificarse su exclusin.

1.5 Qu costes internos han de tenerse en cuenta?


Adems de los costes propios de contratar la auditora, es necesario tener en cuenta que 4 personas
(el tamao mnimo del equipo, incluyendo al Lead Appraiser) deben participar plenamente durante
la misma (aproximadamente entre 8 y 12 das). Estas 4 personas deben cumplir con unos requisitos
bastante estrictos (ver captulo 4), por lo que normalmente se corresponden con perfiles cualificados
dentro de la empresa. Por lo tanto, no hay que olvidar que la organizacin tendr que soportar unos
costes internos.

Kybele Consulting

11

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

Captulo

2
2 Fases y la duracin de la auditora

a realizacin de una auditora CMMI requiere llevar a cabo una serie de actividades. El
mtodo SCAMPI define varias actividades a realizar, que abarcan desde la definicin de
los objetivos de la auditora hasta el reporte de los resultados de la evaluacin. Para evitar
complejidad innecesaria, no vamos a detallar todas las etapas, slo las que afectan ms a la
organizacin, que agruparemos en 3 fases. Para cada una de estas fases, se indica una estimacin de
su duracin. Hay que destacar que estas duraciones se refieren a la duracin temporal de cada una de
las fases, no al esfuerzo necesario para realizarlas (no son das/hombre):
Preparacin y planificacin de la auditora: en esta fase se seleccionan los objetivos de la
mejora, se define el mtodo de captura de evidencias, etc. Esta fase es realizada
conjuntamente por el sponsor y el Lead Appraiser y tiene una duracin aproximada de 2
jornadas.
Readiness-review: en esta fase se estudia si los proyectos que van a ser evaluados y la
organizacin est preparada para la auditora. Es necesario que esta fase se realice al menos
una vez, aunque puede realizarse en ms ocasiones. La duracin de esta fase, que es
realizada por el equipo de evaluacin, es de aproximadamente 3 jornadas. Ampliaremos la
informacin de esta fase en el captulo 5.
Ejecucin de la auditora y comunicacin de resultados: durante esta actividad se realiza la
auditora final de concesin de un nivel de madurez de CMMI. Es realizada por el equipo
de evaluacin, y tiene una duracin estimada de 5 jornadas para el nivel de madurez 2 y de
10 jornadas para el nivel de madurez 3.

Figura 1. Fases de una evaluacin SCAMPI

Kybele Consulting

12

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

Captulo

3
3 Los proyectos que sern auditados y la
unidad organizacional

uando se va a realizar una auditora SCAMPI, es necesario tener claro qu parte de la


organizacin va a ser evaluada. Al subconjunto de la organizacin que ser evaluado se le
denomina unidad organizacional. Este punto es importante porque una vez concedido
el nivel, el diploma que nos entreguen contendr explcitamente la unidad organizacional
evaluada. Por otro lado, una vez definida la unidad organizacional, se determinar qu proyectos van
a ser evaluados del total de la misma, estos proyectos formarn la muestra de proyectos.

3.1 La unidad organizacional


La unidad organizacional se corresponde con la parte de la organizacin que va a ser evaluada. Las
partes o departamentos de una organizacin que componen la unidad organizacional debern tener
unos objetivos de negocio comunes y un conjunto de procesos coherentes. Una unidad
organizacional puede ser un departamento, un conjunto de departamentos, una tipologa de
proyectos, etc., o, en caso de ser una empresa pequea, toda la organizacin.
Por ejemplo, puede darse el caso de una empresa multinacional con sedes en Madrid, Buenos Aires
y Cceres que defina que la unidad organizacional sea solamente una de las sedes. Pero tambin
puede darse el caso de una organizacin con varias sedes pero con tres departamentos bien
definidos (desarrollos internos, desarrollos a medida y desarrollos para sistemas empotrados) que
decida que la unidad organizacional sea el departamento de desarrollos a medida, aunque este
involucre a varias sedes.

3.2 La muestra de proyectos


Cuando se va a realizar una evaluacin SCAMPI, normalmente no se evalan todos los proyectos de
la unidad organizacional, sino que se selecciona una muestra de proyectos representativa de la
misma. La seleccin de los proyectos adecuados para la muestra es una tarea importante dentro de
una auditora CMMI, ya que estos deben cubrir todos los factores crticos que se identifiquen dentro
de la unidad organizacional.
A la hora de realizar la evaluacin, se distinguen tres tipos de proyectos, que pueden formar parte de
la muestra2:
Proyecto objetivo: es un proyecto que aporta evidencia objetiva (veremos qu es una
evidencia en el captulo 6) de todas las reas de proceso del nivel de madurez a evaluar. A la
hora de evaluar el proyecto no importa si este ha terminado o no (hay por ejemplo
2

A partir de la versin 1.3 de SCAMPI ya no se distingue entre proyectos objetivos y no objetivos. Adems, los proyectos pasan a
ser denominados unidades bsicas.
Kybele Consulting

13

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

proyectos que estn en mantenimiento un gran nmero de aos), solamente se comprueba


si proporciona evidencia para cada una de las reas de proceso definidas en el nivel CMMI
a evaluar. Un ejemplo de un proyecto de este tipo puede ser un proyecto de desarrollo para
un cliente que se encuentra al final de la fase de pruebas. En el caso de que a lo largo del
proyecto se hayan seguido correctamente los procesos definidos en la organizacin, el
proyecto podr proporcionar evidencia de cada una de las reas de proceso del nivel de
madurez evaluado.
Proyecto no objetivo: es un proyecto que aporta evidencia objetiva de alguna de las reas de
proceso dentro del alcance de la evaluacin. Estos proyectos sirven como complemento de
los proyectos objetivos, para obtener mayor nmero de evidencias de la realizacin de cada
una de las prcticas definidas en CMMI (explicaremos qu es una prctica en el captulo 6).
Un ejemplo de un proyecto de este tipo puede ser un proyecto de desarrollo de una Web
iniciado en las ltimas fases de la implantacin de CMMI, y que se encuentra an en el
anlisis de requisitos. Este proyecto puede proporcionar evidencias en algunas reas de
proceso, como en la Gestin de Requerimientos, pero difcilmente podr proporcionar
evidencias para todas las reas de proceso de nivel de madurez 2.
Funcin de apoyo: funcin organizativa que aporta evidencia objetiva de las reas de
proceso organizativas, por ejemplo formacin, el aseguramiento de la calidad, RRHH, etc.
Para superar una evaluacin SCAMPI, es necesario presentar al menos un proyecto objetivo.
Adems, es necesario presentar tantos proyectos, objetivos o no objetivos, como sean necesarios
para obtener al menos 3 evidencias de la realizacin de cada una de las prcticas de cada rea de
proceso a evaluar.3
Esto no es as para todas las reas de proceso. CMMI cuenta con algunas reas de proceso que son a
nivel de organizacin (por ejemplo, Formacin organizativa - OT) 4. En el caso de las prcticas de
estas reas de proceso, slo es necesario proporcionar una evidencia, por lo que la cuestin de
nmero de proyectos no aplica para ellos.

En la versin 1.3 de SCAMPI, el nmero de proyectos a incluir en la muestra se calcula cuantitativamente, en funcin del
nmero de subgrupos (proyectos de la organizacin que cuentan con unas mismas caractersticas para la implementacin de los
procesos en cuanto a lugar de implementacin, cliente, tamao, etc.) y del nmero de proyectos.
4 Los procesos y sus acrnimos pueden ser consultados en el Anexo A de este documento.
Kybele Consulting

14

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

Captulo

4
4 Los participantes en la auditora

ara poder llevar a cabo una auditora CMMI, es necesario un equipo de trabajo que cumpla
unos requisitos mnimos. De esta manera se asegura la experiencia, el conocimiento y las
habilidades necesarias para participar en la auditora.

El personal necesario para participar en actividades o realizar tareas en una evaluacin SCAMPI A
(tanto de la organizacin a evaluar como de la organizacin evaluadora) incluye los siguientes roles5:
Sponsor. Es el encargado de liderar el proyecto de mejora y normalmente se corresponde
con un directivo de la organizacin. Es el propietario de los resultados del SCAMPI, y el
encargado de proporcionar los recursos. En muchas ocasiones, el sponsor delega la
responsabilidad de liderar el proyecto en otros miembros de la organizacin objeto de
evaluacin.
Jefe del equipo de evaluacin (Appraisal Team Leader). Responsable de realizar la evaluacin.
El jefe del equipo de evaluacin debe ser un Lead Appraiser, y pertenecer a una empresa
partner del Software Engineering Institute (SEI) para poder realizar la evaluacin, as como
tener la experiencia y entrenamiento necesario.
Coordinador de la organizacin (Organizational Unit Coordinator u OUC). Encargado de
facilitar la realizacin de la auditora, actuando de interfaz entre el equipo de evaluacin y la
unidad organizacional. Es quien proporciona principalmente la informacin necesaria al
evaluador. Es comn que se corresponda con el responsable de calidad de la organizacin.
Miembros del equipo de evaluacin (Appraisal Team Members o ATM). Personal de la
organizacin a auditar o personal externo que cumple con los requisitos para formar el
equipo de evaluacin, y que cuenta con la experiencia y el entrenamiento suficiente.
Participantes seleccionados. Encargados de proporcionar la informacin necesaria. Es
comn que sean jefes de proyecto o desarrolladores de los proyectos evaluados.
La evaluacin SCAMPI A debe ser realizada por un equipo evaluador formado por al menos 4
integrantes (ATM), incluyendo al evaluador lder -SCAMPI Lead Appraiser. Cada uno de estos 4
ATM, debe satisfacer los siguientes requisitos6:
Debe haber asistido previamente al curso oficial del SEI Introduction to CMMI.
Debe tener disponibilidad completa durante la evaluacin (fases de preparacin y
5

En organizaciones pequeas, es habitual que una misma persona participe en varios roles durante las entrevistas.

En la versin 1.3 de SCAMPI, los requisitos para formar parte del equipo de evaluacin se han modificado ligeramente. Ahora
es necesario tener 2 aos de experiencia en el campo de la evaluacin. Adems, se han endurecido los requisitos para los niveles
altos de madurez.
Kybele Consulting

15

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

ejecucin). Aproximadamente 8 y 12 das para los niveles de madurez 2 y 3


respectivamente.
Debe ser independiente de los proyectos evaluados. No podr por tanto ser responsable de
ninguno de los proyectos seleccionados para la evaluacin, ni ser responsables directos o
indirectos de aquellas personas que sern entrevistadas durante la evaluacin.
Cada miembro del equipo evaluador debe tener al menos 6 aos de experiencia promedio
en el campo de ingeniera y la suma de experiencias de los miembros del equipo debe ser de
al menos 25 aos como experiencia total del grupo.
Al menos un miembro del equipo de evaluacin deber tener al menos 6 aos de
experiencia en la gestin de proyectos software. El equipo evaluador en total deber tener al
menos 10 aos de experiencia en dicha gestin.
El equipo de evaluacin deber tener unos conocimientos adecuados de las diferentes fases
del ciclo de vida de desarrollo de los proyectos y sobre diferentes entornos y dominios de
negocio de los proyectos de la organizacin evaluada.
Es altamente recomendable que los miembros del equipo de evaluacin puedan leer
documentacin tcnica en ingls, dado que mucho del material de soporte del mtodo
SCAMPI est en este idioma.
El SCAMPI Lead Appraiser es quien finalmente decide la aceptacin o no de los miembros
del equipo evaluador y es el responsable de asegurar que sus cualificaciones y su
sostenibilidad estn acordes con el propsito de la evaluacin.

Kybele Consulting

16

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

Captulo

5
5 La fase Readiness review

l objetivo de esta fase es conocer si los proyectos y la organizacin estn preparados para
afrontar la auditora. En esta fase se analizan las evidencias objetivas, la preparacin del
equipo de evaluacin y la preparacin logstica (instalaciones, equipamiento,
disponibilidad, etc.) para conocer si es posible llevar a cabo la auditora. Tras la realizacin
de esta etapa, se decide si continuar con el plan tal como estaba previsto, si es necesario realizar una
re-planificacin o si es mejor cancelar el proyecto. El Lead Appraiser es el responsable de tomar esta
decisin, en funcin de los resultados de la realizacin de esta evaluacin.
En la fase readiness review deben participar al menos:
El jefe del equipo de evaluacin.
Es recomendable que participe al menos un representante de cada proyecto evaluado
dentro de la unidad organizacional.
Cualquier otro representante de la unidad organizacional que se desee.
Las tareas principales que se realizan en esta fase son las siguientes:
Evaluar las evidencias para la auditora. En esta fase, se analizan las PIIDB o bases de datos
de evidencias (en el captulo 6 se trata en detalle este tema), analizando los artefactos
incorrectos, los que faltan y los que estn incompletos, para los diferentes proyectos de la
muestra.
Evaluar las instalaciones, el equipamiento y la disponibilidad del equipo, para concretar si es
posible llevar a cabo una auditora CMMI.
Evaluar la preparacin del equipo. Normalmente en esta fase se realiza una formacin para
que el equipo est preparado para la auditora, aunque puede realizarse tambin en otro
momento. Durante esta fase se determina si el equipo est preparado para superar una
evaluacin CMMI, para lo que se analiza cmo operan los equipos entre s, su efectividad,
etc.
Una vez que se ha completado la fase Readiness Review, se lleva a cabo la evaluacin final, que en
caso de superarla da como resultado el nivel de madurez alcanzado. Si por el contrario la fase
Readiness Review no fuese superada, es necesario realizar una replanificacin del proyecto de
mejora.

Kybele Consulting

17

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

Captulo

6
6 Los indicadores de implementacin de
la prctica (PII) y la base de datos de
indicadores (PIIDB)

ara comprender qu son los indicadores de implementacin de la prctica es necesario


conocer primero la estructura de un rea de proceso. Las reas de proceso estn
compuestas de unas metas, que deben ser alcanzadas para cumplir con el rea de proceso.
Se distinguen dos tipos de metas, las metas genricas (GG), que son comunes a todas las
reas de proceso, y las metas especficas (SG), que son definidas por cada rea de proceso.
Estas metas se dividen a su vez en prcticas, que son actividades que se consideran importantes para
alcanzar el objetivo del rea de proceso. Se distinguen tambin dos tipos de prcticas, las prcticas
genricas (GP), que son comunes a todas las reas de proceso, y las prcticas especficas (SP), que
son propias de cada rea de proceso. La Figura 2 muestra como se estructura un rea de proceso en
cuanto a sus metas y prcticas.

Figura 2. Estructura de un rea de proceso

Cuando se est realizando una auditora CMMI, es necesario comprobar que todas las metas de cada
rea de proceso definida en el nivel de madurez a evaluar han sido alcanzadas. Para ello, se
comprueba que todas las prcticas definidas de cada meta han sido satisfechas7. Si esto es as, la
realizacin de cada prctica dejar algn tipo de rastro (por ejemplo un documento, un acta de
reunin, un email, etc.). A estos rastros se les conoce como indicadores de implementacin de la
8
prctica (Practice Implementation Indicators o PII), que son, por lo tanto, el resultado de la
implementacin de una prctica y que sirven para comprobar que esta implementacin se ha
7

Esto es as en la mayora de las auditoras, aunque el modelo deja claro que las metas son obligatorias mientras que las prcticas
son solamente recomendadas.
8
A partir de la versin 1.3 de SCAMPI, los indicadores de implementacin de la prctica pasan a llamarse evidencias objetivas.
Kybele Consulting

18

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

realizado correctamente. Estos indicadores de implementacin es lo que busca el auditor durante la


auditora para comprobar que se est realizando cada una de las prcticas y que se alcanzan, por lo
tanto, cada una de las metas del rea de proceso correspondiente.
Se distinguen tres tipos de PII:
Artefacto directo: salidas tangibles que resultan de la implementacin directa de una
prctica. Los artefactos directos pueden ser documentos, entregables, productos, material
de formacin, etc. Un ejemplo de un artefacto directo para el SP 1.2 del proceso de
Planificacin del Proyecto, Establecer las estimaciones de los atributos del producto de
trabajo y de las tareas, puede ser un documento con la estimacin de cierto proyecto
resultante de la aplicacin del mtodo de estimacin por analoga.
Casos especiales en artefactos directos:
En el caso de algunas prcticas, pueden aceptarse documentos como artefactos directos
incluso si estos no tienen el objetivo primario de conseguir la prctica. Por ejemplo, para la
prctica especfica SP 1.2 del proceso de Gestin de Configuracin: Establecer un sistema
de gestin de la configuracin, puede ser considerado un artefacto directo un esquema o
descripcin del sistema de libreras del gestor de configuracin.
Artefacto indirecto: artefactos que son consecuencia de la implementacin de una prctica,
pero que no son el propsito para el cual se realiza la prctica. Los artefactos indirectos
pueden ser actas de reunin, informes de estado, presentaciones, correos electrnicos, etc.
Un ejemplo de artefacto indirecto para el SP 1.2 del proceso de Planificacin del Proyecto,
Establecer las estimaciones de los atributos del producto de trabajo y de las tareas, puede
ser un informe con las horas imputadas a la realizacin de la estimacin por analoga del
proyecto.
Afirmacin: confirmaciones de palabra (entrevistas) o escritas que corroboran la
implementacin de una prctica especfica o genrica. Ejemplos: entrevistas,
teleconferencias, cuestionarios, etc.
Los PII son utilizados por tanto para demostrar que existe evidencia objetiva de la implementacin
de cada una de las prcticas (ya sean especficas -SP- o genricas -GP-) que van a ser evaluadas. Para
que exista evidencia objetiva, el mtodo SCAMPI indica que debe existir al menos un artefacto
directo que demuestre el propsito de la prctica y que este a su vez sea corroborado por artefactos
indirectos o afirmaciones9. Por lo tanto, para comprobar que existe evidencia objetiva de la
implementacin de la prctica, puede utilizarse la siguiente frmula:
EVIDENCIA OBJETIVA = ARTEFACTO DIRECTO AND (ARTEFACTO INDIRECTO
OR AFIRMACION)

Para la versin 1.3 se han realizado intentos de simplificacin para la recoleccin de evidencias. A partir de la versin 1.3, no

existirn artefactos directos e indirectos, sino que sern conocidos como artefactos simplemente. Con ello, simplemente ser
necesario centrarse en que existen artefactos que cumplan con la prctica evaluada. Por su parte, las afirmaciones debern ser ms
completas, de manera que ayuden a entender la prctica. A partir de la versin 1.3, la frmula para comprobar la existencia de una
evidencia es:
EVIDENCIA = ARTEFACTO AND AFIRMACIN
Kybele Consulting

19

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

6.1 La PIIDB
Una Base de Datos de Indicadores de Implementacin de la Prctica10 (Practice Implementation
Indicators DataBase o PIIDB) es una base de datos que almacena evidencias de la implementacin de
las diferentes prcticas (especficas -SP- y genricas -GP-) definidas en CMMI. Las organizaciones
pueden proporcionar una PIIDB como entrada a la evaluacin11 (de hecho es muy recomendable
trabajar desde el inicio con una PIIDB, para ordenar el trabajo y obtener una evaluacin constante).
Esta PIIDB mostrar la trazabilidad de las prcticas del modelo a las reas de proceso
correspondientes y a las evidencias objetivas usadas para verificar la implementacin de la prctica.
En la Figura 3 se muestra un extracto de una PIIDB, en la que se muestran los campos a completar
para la prctica 1.4 Determinar estimaciones de esfuerzo y costes del rea de proceso de
planificacin del proyecto (PP). Para que exista evidencia objetiva de la realizacin de esta prctica,
este extracto de la PIIDB debera contener para cada proyecto un artefacto directo y un artefacto
indirecto o una afirmacin.

Figura 3. Campos a completar en una PIIDB para una prctica

La PIIDB de nivel 2 en nmeros


Por cada rea de proceso (en total son 7) y por cada prctica especfica (SP) y cada prctica
genrica (SG) ser necesario completar un total de entre 6 y 9 indicadores (PII). La diferencia est
en si se presenta solo un artefacto indirecto, solo una afirmacin o ambos. En ocasiones la misma
empresa buscar tener ambos indicadores para dar mayor fortaleza a la evidencia. La cantidad
total de SP y SG es de 136. La cantidad total de indicadores entonces sern entre 816 y 1224.
Haciendo una estimacin en tiempo, si completar una evidencia lleva aproximadamente 10
minutos, completar la PIIDB llevar entre 17 y 26 jornadas de trabajo.

10

En algunos pases latinoamericanos se le conoce como PIID (Documento de Indicadores de Implementacin de Proceso). A
partir de la versin 1.3 de SCAMPI, la PIIDB pasa a llamarse Base de Datos de Evidencias Objetivas.
11
Una PIIDB est compuesta de tantas Descripciones de PII (PII Description o PIID) como prcticas existan en las reas de
proceso que van a ser evaluadas. Una PIID es una estructura que almacena la informacin necesaria de un PII (por ejemplo su
descripcin, el artefacto directo, el artefacto indirecto y la afirmacin).
Kybele Consulting

20

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

Captulo

7
7 Ejemplo de PIIDB

ormalmente, completar una PIIDB es una tarea extensa y que lleva asociados unos
importantes costes internos. Es por ello que se recomienda comenzar a trabajar con ella
cuanto antes, e ir completando progresivamente los indicadores, consiguiendo as
encontrar y comprobar tanto los puntos fuertes del proceso de desarrollo como los
aspectos ms dbiles, en los que deberan centrarse los mayores esfuerzos.
A lo largo de este captulo vamos a detallar ejemplos de artefactos directos e indirectos para cada una
de las prcticas de las reas de proceso de nivel 2. Estas tablas deben tomarse solo como un ejemplo,
por lo que en la implantacin que las empresas llevan a cabo pueden encontrarse otros artefactos.

7.1 Prcticas genricas de nivel 2


ARTEFACTO DIRECTO
Plan de calidad que contemple
GP 2.1 Establecer una el desarrollo software, los
poltica de la organizacin procesos de nivel 2 y que se
encuentre
firmado
y
respaldado por la gerencia.
Documentos para planificar
cada uno de los procesos, y
GP 2.2 Planificar el que contienen su descripcin,
sus
objetivos,
sus
proceso
responsabilidades,
sus
dependencias, las mediciones
a realizar para el proceso, etc.

ARTEFACTO INDIRECTO
Comunicacin del plan de calidad
a la empresa (correos, wiki, pgina
Web, etc.).

Horas imputadas al proyecto.

Facturas de compra de equipos o


Descripcin de los equipos y
de herramientas.
recursos
(humanos
y
materiales) disponibles para la
Horas imputadas a las tareas de
realizacin del proceso.
gestin del proyecto.
Documento de roles y Actas de reunin convocadas en
GP 2.4 Asignar
responsabilidades para cada las que se nombran los
responsabilidad
proceso.
responsables.
Tareas
de
formacin
realizadas: temario de los Informe de asistencia a los cursos
GP 2.5 Formar al personal mismos, materiales, objetivos de formacin por parte del
de la realizacin de la personal.
formacin, exmenes, etc.
GP
2.6
Gestionar Gestor de configuracin del Logs que muestren el uso de cada
cdigo fuente (SVN, CVS, una de las herramientas de gestin
configuraciones
etc.).
de configuracin.
GP
2.3
recursos

Proporcionar

Kybele Consulting

21

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

Gestor de configuracin
documental (SharePoint, wiki,
etc.).
Sistemas de
seguridad.

copias

de

Actas de reunin en la que


GP 2.7 Identificar e Plan
de
comunicacin
participan
los
diferentes
involucrar a las partes establecido en el que se involucrados en el proyecto.
identifican a los implicados en
interesadas relevantes
el proceso.
Correos de convocatoria.
Informes
de
medicin
Acciones correctivas asociadas a
intermedios de los productos
las mediciones del rendimiento de
GP 2.8 Monitorizar y
software.
los procesos.
controlar el proceso
Informes de medicin del
Comunicacin de los resultados.
rendimiento de los procesos.
Horas imputadas a tareas de
GP
2.9
Evaluar
auditora.
objetivamente
la Informes de auditora interna
y externa de los procesos.
adherencia
Registros
de
auditora,
contratacin de auditores, etc.
GP 2.10 Revisar el estado Resultado de la reunin con la
Actas de reunin, convocatorias,
direccin para revisar los
con el nivel directivo
calendario de planificacin, etc.
procesos de la organizacin.

7.2 rea de proceso: Gestin de Acuerdos con Proveedores


(SAM)
ARTEFACTO DIRECTO

ARTEFACTO INDIRECTO

SG 1 Establecer los acuerdos con proveedores


Poltica de acuerdos con
proveedores, definiendo los
SP 1.1 Determinar el tipo
Requisito del proyecto donde se
tipos de compras posibles
de compra
describe el mdulo a contratar.
(productos
off-the-shelf,
productos a medida, etc.).
Plantilla de homologacin de
SP 1.2 Seleccionar los proveedores.
Informe de homologacin.
proveedores
Listado de proveedores.
SP 1.3 Establecer los
Acta de reunin donde se ha
Contrato con el proveedor.
acuerdos con el proveedor
realizado el acuerdo.
SG 2 Satisfacer los acuerdos del proveedor
Incidencias registradas.
Informes de cierre de
SP 2.1 Realizar el acuerdo
acuerdos y de progreso del
del proveedor
Actas
de
reuniones
de
proveedor.
seguimiento.
Informes de seguimiento del
SP 2.2 Monitorizar los
Horas
imputadas
a
la
proveedor.
procesos seleccionados del
monitorizacin de actividades del
proveedor
proveedor.
Informes de discrepancias.
Kybele Consulting

22

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

SP 2.3 Evaluar los


productos
a
medida
seleccionados
del
proveedor
SP 2.4 Aceptar los
productos adquiridos

SP 2.5 Transferir
productos

Listado de productos de
trabajo seleccionados a evaluar
del proveedor e informes
sobre la seleccin.
Procedimiento y resultados de
pruebas de aceptacin.
Planes de transicin y
despliegue,
gestin
del
cambio, paso a produccin, a
los
pre-produccin, etc.

Horas imputadas a la evaluacin


de productos de terceros.
Incidencias histricas y resolucin.
Horas imputadas por cada
empleado
involucrado
a
actividades
de
formacin
relacionadas con el producto.

Informes de formacin sobre Informe de incidencias durante el


los nuevos productos.
despliegue.

7.3 rea de proceso: Gestin de requerimientos (REQM)


ARTEFACTO DIRECTO

ARTEFACTO INDIRECTO

SG 1 Gestionar los requerimientos


Aplicacin de un listado de
criterios definidos para la
evaluacin y la aceptacin de Correos electrnicos o actas de
SP 1.1 Obtener una
los requisitos.
reunin en los cuales se evidencia
comprensin
de
los
el entendimiento, negociacin o
requerimientos
Resultados del anlisis de los cambio de requisitos.
requisitos frente a los criterios
de aceptacin.
Documento de requisitos
SP
1.2
Obtener
el aceptado.
Histrico de requisitos cuyo
compromiso sobre los
estado pasa a ser aceptado.
requerimientos
Acta de reunin donde se
aceptan los requisitos.
Peticiones
de
cambio
asociadas con requisitos.
Histrico de requisitos cuyo
estado haya pasado a abierto
SP 1.3 Gestionar los Requerimientos versionados.
tras haber sido cerrado.
cambios
en
los
requerimientos
Tareas para cada peticin de
Estimacin de las tareas asociadas
cambio: trazabilidad de la
al cambio en un requisito.
peticin de cambio con las
tareas.
Matriz de trazabilidad entre
requisitos y los dems
SP 1.4 Mantener una
Anlisis de cambio donde se ha
elementos que componen el
trazabilidad bidireccional
utilizado la matriz de trazabilidad
producto software (ej. diseo,
de los requerimientos
para valorar el impacto.
casos de prueba, cdigo
fuente, etc.).
SP 1.5 Identificar las
Informe de pruebas.
Acciones correctivas asociadas a
inconsistencias entre el
las inconsistencias encontradas
trabajo del proyecto y los
Listado de inconsistencias.
entre el proyecto y los requisitos.
requerimientos

Kybele Consulting

23

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

7.4 rea de proceso: Planificacin de Proyecto (PP)


ARTEFACTO DIRECTO

SP 1.1 Estimar el alcance


del proyecto

SP 1.2 Establecer las


estimaciones
de
los
atributos del producto de
trabajo y de las tareas

ARTEFACTO INDIRECTO

SG 1 Establecer estimaciones
Oferta o plan de proyecto
donde se indican el alcance del
Horas imputadas a la tarea de
sistema.
estimacin del alcance, oferta
inicial, estudio de viabilidad, etc.
Descripcin de las tareas a
realizar durante el proyecto.
Diagrama de Gantt en el que
se describen la duracin de las
tareas, en base a una
estimacin por analoga.
Horas imputadas a la realizacin
de la estimacin por analoga,
Planificacin
del
sprint
punto funcin, puntos pker, etc.
backlog.

Informe con los resultados de


la estimacin.
Una seccin, usualmente
incorporada al plan de
proyecto donde se describen
las fases que contendr el
SP 1.3 Definir el ciclo de
Hitos definidos en el diagrama de
proyecto (anlisis, diseo,
vida del proyecto
Gantt.
despliegue, iteraciones, etc.), la
relacin entre estas fases y su
ordenacin temporal (cascada,
iterativo, incremental, etc.).
Informe en el que se
representan los resultados de
la estimacin del esfuerzo
necesario y el mtodo usado.
Horas imputadas a la tarea de
SP 1.4 Determinar las Hoja de costes para el estimacin.
estimaciones de esfuerzo y proyecto y el procedimiento
costes
de clculo.
Herramienta de clculo de
esfuerzo y coste completada.
Definicin
de
recursos
necesarios
(memoria,
capacidad de red, etc.) para la
realizacin del proyecto.
SG 2 Desarrollar un plan de proyecto
Seccin de presupuesto del
Horas imputadas a la tarea de
documento del plan de
elaboracin del presupuesto y
Proyecto.
SP 2.1 Establecer el
calendario.
presupuesto y el calendario
Diagrama de PERT en el que
Herramienta de clculo de
se identifican las distintas
esfuerzo y coste completada.
tareas y sus dependencias.
Matriz de riesgos identificados Catlogo genrico de riesgos.
SP 2.2 Identificar los para el proyecto.
riesgos del proyecto
Horas imputadas a la tarea de
Checklist que evala los identificacin de riesgos.
Kybele Consulting

24

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

riesgos para el proyecto.


Listado
de
los
datos
gestionados en el proyecto,
Estructura de carpetas y permisos
con la descripcin del
para
controlar
datos
formato,
requisitos
de
SP 2.3 Planificar la gestin
confidenciales.
privacidad y seguridad.
de los datos
Logs de backups realizados para el
Descripcin del sistema de
proyecto.
Backup. Datos que requieren
confidencialidad.
Listado de equipamiento,
Orden
de
compra
de
instalaciones
y
software
equipamiento.
SP 2.4 Planificar los asociado con el proyecto.
recursos del proyecto
Acta de reunin interna de
Listado de recursos humanos
arranque.
necesarios.
Listado
de
habilidades
necesarias por parte de los Actividades de formacin para los
SP 2.5 Planificar el
miembros del equipo.
perfiles del proyecto.
conocimiento
y
las
habilidades necesarias
Plan de personal y de nuevas Material de formacin.
contrataciones.
Listado de los participantes del
proyecto y rol que juegan en el
mismo.
Comunicacin formal a las
SP 2.6 Planificar la personas que participarn en
involucracin de las partes el
proyecto
(cliente,
interesadas
desarrolladores, equipo de
pruebas, etc.).

Acta de reunin de arranque del


proyecto en la que participan
tanto el cliente como los
principales involucrados en el
proyecto y se explica el plan de
comunicacin.

Plan de comunicacin y
relaciones
entre
los
participantes.
Horas imputadas a la tarea de
planificacin.

SP 2.7 Establecer el plan


Plan de proyecto.
de proyecto

Plantilla de plan de proyecto.


SG 3 Obtener el compromiso con el plan
Matriz de relaciones entre
proyectos, planificacin de
proyectos y recursos asignados
SP 3.1 Revisar los planes
Registro de resolucin
en la unidad organizacional.
que afectan al proyecto
conflictos (correo, acta, etc.).

de

Documento con la ocupacin


de recursos de la organizacin.
Presupuestos renegociados.
Control de la asignacin y
Revisin en herramienta de
SP 3.2 Reconciliar los capacidad de los recursos
gestin de personal y control de
niveles de trabajo y de
horas, as como el ajuste de
recursos
Reestimacin de las tareas de
recursos y tareas.
los implicados que tengan una
dedicacin que no sea
Kybele Consulting

25

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

aceptable.
Acta de reunin de inicio del
SP
3.3
Obtener
el Aceptacin por los afectados
proyecto con la participacin del
compromiso con el plan
del plan de proyecto.
equipo.

7.5 rea de proceso: Monitorizacin y Control del Proyecto (PMC)


ARTEFACTO DIRECTO

ARTEFACTO INDIRECTO

SG 1 Monitorizar el proyecto frente al plan


Actas de las reuniones de
seguimiento llevadas a cabo.
Herramienta de seguimiento
SP 1.1 Monitorizar los
(por ejemplo Gantt de Registro de la revisin de las horas
parmetros
de
seguimiento, Trac, etc.).
imputadas al proyecto.
planificacin del proyecto
Identificacin de desviaciones
en el proyecto.
Actas
de
reunin
de
SP 1.2 Monitorizar los seguimiento, informes de Horas imputadas al seguimiento
compromisos
avance, de cumplimiento de del proyecto.
hitos, etc.
Histrico de cambios en los
riesgos.
Acta de reunin de seguimiento
SP 1.3 Monitorizar los
en la que se tratan explcitamente
riesgos del proyecto
Identificacin de nuevos los riesgos del proyecto.
riesgos a lo largo del proyecto.
Servidor
de
integracin Logs del sistema de copias de
continua.
seguridad.
SP 1.4 Monitorizar la
gestin de datos
Registro de tareas de gestin Histrico de revisiones en gestor
de datos.
de configuracin.
SP 1.5 Monitorizar la
Actas de reunin de entrega Correos o notificaciones entre los
involucracin de las partes
de hitos intermedios.
implicados.
interesadas
Informes de avance del Horas imputadas por parte del
seguimiento.
equipo a tareas del proyecto.
SP 1.6 Llevar a cabo
revisiones de progreso
Actas
de
reunin
de Impedimentos detectados durante
seguimiento.
las reuniones de seguimiento.
Actas de reunin de entrega
Histrico de entregables.
intermedia,
reuniones
intermedias de chequeo con el
SP 1.7 Llevar a cabo
Histrico de incidencias.
cliente.
revisiones de hitos
Riesgos del proyecto revisados
Acta de reunin de final de un
durante la realizacin del hito.
Sprint.
SG 2 Gestionar las acciones correctivas hasta su cierre
Peticiones de cambio asociadas.
Incidencias registradas y
SP 2.1 Analizar problemas
analizadas.
Planificacin
modificada
incluyendo las incidencias y su
Kybele Consulting

26

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

estimacin.
Incidencias resueltas.
SP 2.2 Llevar a cabo las Documento o registro de
acciones correctivas
acciones correctivas.
Histrico de cambios de estado de
las incidencias
Acta de reunin al final del hito en
Histrico
de
acciones
SP 2.3 Gestionar las
la que se incluye la revisin de las
correctivas,
participantes,
acciones correctivas
incidencias y las acciones
planes derivados, etc.
correctivas asociadas.

7.6 rea de Proceso: Gestin de Configuracin (CM)


ARTEFACTO DIRECTO

SP
1.1
elementos
configuracin

Identificar
de

SP 1.2 Establecer un
sistema de gestin de la
configuracin

SP 1.3 Crear o liberar lneas


base

SP 2.1 Seguir las peticiones


de cambio

SP 2.2 Controlar
elementos
configuracin

Kybele Consulting

los
de

ARTEFACTO INDIRECTO

SG 1 Establecer lneas base


Documento o herramienta
donde se identifican los
elementos de configuracin de
las lneas base. Pueden ser
Tiempo
dedicado
a
su
productos que se entregan al
elaboracin, horas, actas, etc.
cliente, herramientas, diseos,
planes de pruebas, prototipos,
resultados
de
pruebas,
documentos, etc.
Histrico de revisiones y roles de
acceso al sistema de gestin de la
Herramienta de gestin de la
configuracin.
configuracin (SVN, CVS,
etc.).
Logs de herramientas de gestin
de configuracin.
Descripcin de las entregas
formales a realizar durante el
proyecto, tanto de productos Histrico de entregas formales
software
como
de realizadas.
documentacin, describiendo
los elementos que contiene.
SG 2 Seguir y controlar los cambios
Registro con la aprobacin o
Peticiones
de
cambio
denegacin de un cambio en el
realizadas durante el proyecto.
sistema.
Servidor
de
integracin
continua
que
integra
peridicamente el cdigo
Logs de ejecuciones del servidor
realizado hasta ese momento,
de integracin continua.
identificando
errores
o
conflictos.
Registros de auditora interna o
externa.
No
conformidades
identificadas durante las
auditoras internas y externas.
SG 3 Establecer la integridad

27

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

Incidencias en la gestin de
Revisiones de las tareas de configuracin (ej. establecimiento
gestin de configuracin
de ramas, merges que no
SP 3.1 Establecer registros
funcionan).
de
gestin
de
la
Revisiones de los cambios
configuracin
implementados entre dos Histrico de cambios en la
versiones de la lnea base.
herramienta de gestin de la
configuracin.
SP 3.2 Realizar auditoras Informe de auditora interna o No conformidades extradas de la
de configuracin
externa.
realizacin de la auditora.

7.7 rea de proceso: Medicin y Anlisis (MA)


ARTEFACTO DIRECTO

ARTEFACTO INDIRECTO

SG 1 Alinear las actividades de medicin y anlisis


Documento con los objetivos
Correos de sugerencias de
de medicin, donde se indican
SP 1.1 Establecer los
indicadores.
los objetivos de negocio y su
objetivos de medicin
relacin con los indicadores de
Histrico de indicadores.
medicin.
Actas de reunin para la
Descripcin de los indicadores
definicin de los indicadores.
de medicin: unidades de
SP 1.2 Especificar las medida,
mecanismo
de
Histrico de resultados de las
medidas
recogida, periodicidad de la
mediciones.
recoleccin, objetivo de la
medicin, etc.
Catlogo genrico de mtricas.
Descripcin de los indicadores
de medicin: unidades de
Procedimiento de medicin y
SP 1.3 Especificar los medida,
mecanismo
de
anlisis desarrollado.
procedimientos
de recogida, etc.
recogida
y
de
Logs de las herramientas de
almacenamiento de datos
Seccin en la documentacin
recoleccin automtica de datos.
donde se indica cmo se
almacenan los datos.
Descripcin de los indicadores
SP 1.4 Especificar los
Plantilla de los informes de
de medicin, umbrales y
procedimientos de anlisis
indicadores.
anlisis a realizar.
SG 2 Proporcionar los resultados de la medicin
Horas imputadas a realizar el
informe.
SP 2.1 Recoger los datos de Informe que contenga los
la medicin
datos extrados de la medicin.
Logs de las herramientas de
recoleccin automtica de datos.
Acta de reunin de anlisis de
datos.
SP 2.2 Analizar los datos Informe de anlisis de los
de la medicin
datos obtenidos.
Acciones correctivas asociadas
con el anlisis.
BBDD de indicadores, con los
SP 2.3 Almacenamiento de
Horas imputadas al anlisis y
resultados de las mediciones
datos y los resultados
almacenamiento de los resultados.
anteriores y actuales.
SP 2.4 Comunicar los Correo electrnico, acta, etc. Contestaciones
a
las
Kybele Consulting

28

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

resultados

donde se evidencie la comunicaciones de los resultados.


comunicacin
de
los
resultados
Acciones correctivas identificadas
en base a los resultados.

7.8 rea de proceso: Aseguramiento de la Calidad del Proceso y


del Producto (PPQA)
ARTEFACTO DIRECTO

ARTEFACTO INDIRECTO

SG 1 Evaluar objetivamente los procesos y los productos de trabajo


Plan de calidad donde se han
registrado
las
diferentes
auditoras independientes que Actas de reunin de evaluacin de
se realizarn a los proyectos.
los procesos.
SP
1.1
Evaluar
objetivamente los procesos Informe de auditora interna o Horas imputadas a las auditoras.
externa.
Registro de auditora.
No conformidades detectadas
durante la auditora.
Informes de pruebas de los
SP
1.2
Evaluar productos y servicios.
Histrico de casos de prueba.
objetivamente
los
productos y los servicios
Informes de auditora interna Horas imputadas a las auditoras.
o externa realizada al proyecto.
SG 2 Proporcionar una visin objetiva
No conformidades detectadas
SP 2.1 Comunicar y durante
la
auditora
Acciones correctivas asociadas a
asegurar la resolucin de comunicadas a los proyectos y
las no conformidades.
las no-conformidades
asignadas al responsable de la
resolucin.
Plan de calidad e informes de
auditora.
SP 2.2 Establecer registros

Kybele Consulting

Almacenamiento de las no
conformidades identificadas
en las auditoras.

29

Horas imputadas a las auditoras.

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

Captulo

8
8 El mtodo de evaluacin

ara que una organizacin pueda alcanzar un cierto nivel de madurez, es necesario que se
implementen las reas de proceso que CMMI define para ese nivel de madurez (ver Figura
4 o Anexo A). Para que un rea de proceso sea correctamente implementada, deben
alcanzarse las metas definidas para esa rea de proceso, que a su vez se consiguen
mediante la implementacin de las prcticas de cada meta (especficas -SP- y genricas -GP-).

.
Figura 4. Niveles de madurez definidos en CMMI

Cuando se va a evaluar la implementacin de las prcticas se comienza desde abajo hasta arriba, esto
es, evaluando en primer lugar el cumplimiento de las prcticas, posteriormente las metas, luego las
reas de proceso y finalmente el nivel de madurez.

8.1 Cumplir con las prcticas genricas (GP) y especficas (SP)


Se ha de comprobar si se cumplen las prcticas definidas para cada una de las reas de proceso
definidas en el nivel de madurez. Para comprobar si se cumplen, SCAMPI define una escala que
determina si se han implementado completamente, parcialmente o no se han implementado. La
escala puede verse en la siguiente tabla:

Kybele Consulting

30

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

Calificacin

Descripcin
Artefactos directos presentes y adecuados

Fully Implemented (FI)

Artefactos indirectos y/o afirmaciones


No se han notado debilidades
Artefactos directos presentes y adecuados

Largely Implemented (LI)

Artefactos indirectos y/o afirmaciones


Se han notado una o ms debilidades
Artefactos directos no encontrados o inadecuados
Artefactos indirectos y/o afirmaciones indican que parte de la
prctica ha sido implementada
Se han notado una o ms debilidades

Partially Implemented (PI)

Artefactos directos presentes y adecuados


No se encuentra otra evidencia que soporte la prctica
Se han notado una o ms debilidades
Artefactos directos no encontrados o inadecuados

Not Implemented (NI)

No se encuentra otra evidencia que soporte la prctica


Se han notado una o ms debilidades
Tabla 1. Calificacin de las prcticas

El equipo de auditora ir comprobando las prcticas de las reas de proceso, comprobando el


estado de implementacin en el que se encuentran. Para ello, revisa los indicadores de
implementacin de la prctica (PII). A cada una de las prcticas se le dar una calificacin, en
funcin de las evidencias encontradas, segn la Tabla 1. La Figura 5 muestra un ejemplo de
calificacin de las prcticas de las rea de proceso del nivel dos, detallando el Aseguramiento de la
calidad de proceso y producto (PPQA), en funcin de las evidencias que un auditor encontr.

Kybele Consulting

31

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

Figura 5. Evaluacin de las prcticas del rea de proceso PPQA

8.2 Cumplir con las metas genricas (GG) y especficas (SG)


Una vez que se han evaluado las prcticas, el equipo de auditora evala las metas. Las metas se
evalan como satisfechas (satisfied) y no satisfechas (unsatisfied). Para evaluar si una meta ha sido
satisfecha, se comprueban sus prcticas. Si todas sus prcticas se evalan como FI o LI, se considera
que la meta est satisfecha. Tambin es necesario tener en cuenta el conjunto total de debilidades. Si
la mayora de las prcticas tienen debilidades, podra considerarse que la meta no ha sido satisfecha.
La Figura 6 muestra dos ejemplos de evaluacin del rea de proceso PPQA. En el primero de ellos,
tres metas no se encuentran satisfechas debido a que sus prcticas no se encuentran correctamente
implementadas. En el segundo de los casos, todas las prcticas se han evaluado como correctas, por
lo que las metas si se encuentran satisfechos.

Figura 6. Ejemplo de evaluacin de las metas del rea de proceso PPQA

8.3 Cumplir con el rea de proceso


Una vez que se han evaluado las metas, se evala el rea de proceso. Para que el rea de proceso se
evale satisfactoriamente, todas las metas del rea de proceso (tanto genricas como especficas) han
de encontrarse satisfechas.
La Figura 7 muestra dos ejemplos de evaluacin del rea de proceso PPQA. En el primero de ellos,
el rea de proceso no se ha conseguido implementar completamente al no cumplirse todas las metas.
Sin embargo, en el segundo el rea de proceso se evala satisfactoriamente al estar todas las metas
Kybele Consulting

32

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

satisfechas.

Figura 7. Evaluacin del rea de proceso PPQA

8.4 Cumplir con el nivel de madurez


Por ltimo, para poder determinar el nivel de madurez, es necesario que todas las reas de proceso
definidas en ese nivel de madurez (ver Anexo A) se encuentren correctamente implementadas.
La Figura 8 muestra dos ejemplos de la determinacin del nivel de madurez de una organizacin. En
el primero de ellos, no se ha podido alcanzar el nivel 2 de madurez al no conseguir implementar
correctamente todas las reas de proceso definidas en ese nivel de madurez. En el segundo ejemplo,
se obtiene el nivel de madurez 2 al estar correctamente implementadas todas las reas de proceso
correspondientes a ese nivel.12

Figura 8. Evaluacin del nivel de madurez

12

Se ha excluido el proceso de Gestin de acuerdos con proveedores (SAM), ya que es optativo en funcin del tipo de
organizacin.
Kybele Consulting

33

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

Captulo

9
9 Glosario de trminos
Afirmacin, 20

Lead Appraiser, 16

Appraisal Disclosure Statement, 11

Metas especficas (SG), 19

Appraisal Team Leader, 16

Metas genricas (GG), 19

Appraisal Team Members, 16

Muestra de proyectos, 14

reas de proceso, 19

Organizational Unit Coordinator, 16

Artefacto directo, 20

Prcticas especficas (SP), 19

Artefacto indirecto, 20

Prcticas genricas (GP), 19

Base de Datos de Indicadores de

Proyecto no objetivo, 15

Implementacin de la Prctica (PIIDB), 20

Proyecto objetivo, 14

Descripciones de PII (PIID), 21

Readiness review, 18

Evidencia objetiva, 20

SCAMPI, 11

Funcin de apoyo, 15

Software Engineering Institute (SEI), 11

Indicadores de implementacin de la prctica

Sponsor, 16

(PII), 19

Kybele Consulting

34

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

Captulo

10
10 Referencias
1.

SEI.
CMMI
for
development,
http://www.sei.cmu.edu/library/abstracts/reports/10tr033.cfm.

2.

SEI. CMMI: Gua para la integracin de procesos y la mejora de productos.


http://www.sei.cmu.edu/library/abstracts/whitepapers/cmmi-dev-v12-spanish.cfm.

3.

SEI. Standard CMMI appraisal method for process improvement (SCAMPI) A, version 1.2:
Method definition document. http://www.sei.cmu.edu/library/abstracts/reports/06hb002.cfm.

4.

SEI. Standard CMMI Appraisal Method for Process Improvement (SCAMPI) A, Version 1.3:
Method Definition Document. http://www.sei.cmu.edu/library/abstracts/reports/11hb001.cfm.

5.

SEI. Published appraisal results. http://sas.sei.cmu.edu/pars/pars.aspx.

Kybele Consulting

35

version

1.3.

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

Anexo

A
A Las reas de proceso de CMMI
El modelo CMMI-DEV v1.313 establece 22 reas de proceso, divididas en categoras, para guiar a las
organizaciones en la mejora de sus procesos. Un rea de proceso, tambin conocido como PA, de sus
siglas en ingls Process Area, es un conjunto de prcticas relacionadas que, cuando se implementan de
forma colectiva, satisfacen un conjunto de objetivos considerados importantes para alcanzar las mejoras
en esa rea.
Para que la organizacin alcance un cierto nivel de madurez, ser necesario que cumpla con todas las
prcticas para las reas de procesos que ese nivel defina. Estas reas de proceso a cumplir para cada nivel
estn ya definidas y son las siguientes:

A.1 Nivel de madurez 2


Las reas de proceso que se enmarcan en este nivel de madurez son las siguientes:
Gestin de requerimientos (REQM)
Planificacin de proyecto (PP)
Monitorizacin y control del proyecto (PMC)
Gestin de acuerdos con proveedores (SAM)
Gestin de configuracin (CM)
Aseguramiento de la calidad de proceso y producto (PPQA)
Medicin y Anlisis (MA)
El rea de proceso Gestin de acuerdos con proveedores (SAM) slo ha de ser implementada si las
organizaciones externalizan actividades relacionadas con el desarrollo software a otras empresas.

A.2 Nivel de madurez 3


Para alcanzar el nivel de madurez 3, es necesario implementar todas las reas de proceso relativas al nivel
2, adems de las siguientes reas de proceso:
Desarrollo de requerimientos (RD)
13

Aunque en esta gua se trata principalmente la versin 1.2 del mtodo SCAMPI, los procesos aqu descritos corresponden a la versin
1.3 de CMMI, en los que apenas hay cambios respecto a la 1.2.
Kybele Consulting

36

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

Solucin tcnica (TS)


Integracin de producto (PI)
Verificacin (VER)
Validacin (VAL)
Definicin de procesos de la organizacin (OPD)
Enfoque de procesos de la organizacin (OPF)
Formacin organizativa (OT)
Gestin integrada de proyecto (IPM)
Gestin de riesgos (RSKM)
Anlisis de decisiones y resolucin (DAR)

A.3 Nivel de madurez 4


Para alcanzar el nivel de madurez 4, es necesario implementar todas las reas de proceso relativas al nivel
3 de madurez, adems de las siguientes:
Gestin cuantitativa de proyecto (QPM)
Rendimiento de procesos de la organizacin (OPP)

A.4 Nivel de madurez 5


Para alcanzar el nivel 5 de madurez, es necesario implementar todas las reas de proceso relativas al nivel
de madurez 4, adems de las siguientes:
Anlisis causal y resolucin (CAR)
Gestin del rendimiento de la organizacin (OPM)

Kybele Consulting

37

Universidad Rey Juan Carlos

Buyer: richard mercado (rmercador642@hotmail.com)


Transaction ID: jg-ne8a2be6290ce40

Potrebbero piacerti anche