CMM Informe

8/6/2019 CMM Informe

1/50

CMM Capability Maturity Model

ResumenEl modelo de madurez de capacidad (CMM) surge como iniciativa de SEI, arequerimiento del Gobierno Federal de los Estados Unidos de Amrica. Este modelopropone un esquema de cinco niveles de madurez logrados mediante pequeos cambiosevolutivos en determinadas reas. Se considera que una organizacin ha alcanzado unnivel de madurez si ha institucionalizado todas las prcticas incluidas en ese nivel y susinferiores.

Los cinco niveles son:1 Inicial

2 Repetible3 Definido

4 Gestionado5 Optimizado

Cada rea clave es abordada por medio de un conjunto de prcticas o procesos clave,organizadas en reas Clave de Proceso (KPA - Key Process Area). Para cada rea deproceso define un conjunto de buenas prcticas que habrn de ser:

1. Definidas en un procedimiento documentado2. Provistas (la organizacin) de los medios y formacin necesarios3. Ejecutadas de un modo sistemtico, universal y uniforme(institucionalizadas)4. Medidas5. Verificadas

Estas caractersticas reciben el nombre de caractersticas comunes. Las caractersticas1,2 4 y 5 institucionalizan las mejoras del proceso mientras que la 3 es la que realmente

implementa la mejora.

Finalmente se concluye que CMM es un modelo que si bien provee un soporte paramadurar un proceso, no asegura que el producto construido en los proyectos sea elcorrecto. Adems a medida que los niveles aumentan, la cantidad de documentacin queinstitucionaliza es mucho mayor.

Ingenieria de Software 2006 U.N.C.P.B.A.Alvarz Bilbao Goi Saavedra

1


2/50


Objetivos

Narrar brevemente la historia del Modelo de Capacidad de la Madurez. Presentar una visin general de la estructura interna. Describir brevemente los niveles de madurez de los procesos. Describir las areas claves de cada nivel. Introducir brevemente solo las prcticas claves Practicas Realizadas que sirven

como guia para cumplir con determinados objetivos en cada nivel.


2


3/50


Resumen ........................................................................................................................... 1Objetivos........................................................................................................................... 2Modelo de capacidad y madurez ...................................................................................... 4

Motivacin.................................................................................................................... 4Madurez de una Organizacin...................................................................................... 4Visin general de CMM............................................................................................... 5Los cinco niveles de maduracin de proceso de software............................................ 6Entendiendo el CMM ................................................................................................... 7

Caractersticas de Comportamiento de los Niveles de Madurez ...................................... 7Nivel 1: Nivel Inicial (Initial Level) ......................................................................... 8Nivel 2: Nivel Repetible (Repeteable Level)............................................................ 8Nivel 3: Nivel Definido (Defined Level) .................................................................. 9Nivel 4: Nivel Administrado (Manager Level) ...................................................... 10

Nivel 5: Nivel Optimizando (Optimizing Level) .................................................... 10Capacidad de Proceso y Prediccin de la Performance.......................................... 11Salteando Niveles de Madurez ................................................................................... 12

Definicin operacional de CMM.................................................................................... 14La estructura interna de los Niveles de Madurez ....................................................... 14

reas claves de proceso en el Nivel 2 ................................................................... 17reas claves de proceso en el Nivel 3 ................................................................... 18reas claves de proceso en el Nivel 4 ................................................................... 19reas claves de proceso en el Nivel 5 ................................................................... 20

Conclusin...................................................................................................................... 22Apndice A - Key Practices............................................................................................ 23

Nivel 2 ........................................................................................................................ 23Administracin de requerimientos.......................................................................... 23Planeamiento del proyecto de software:................................................................. 24Control de proyectos de software:.......................................................................... 26Aseguramiento de la calidad del software:............................................................. 29Administracin de configuracin de software:....................................................... 30

Nivel 3 ........................................................................................................................ 32Concentracin del proceso organizacional:............................................................ 32Definicin de procesos organizacionales: .............................................................. 32Programa de capacitacin:...................................................................................... 34Administracin integral de software: ..................................................................... 35

Coordinacin entre grupos: .................................................................................... 36Peer reviews............................................................................................................ 37

Nivel 4 ....................................................................................................................... 37Administracin Cuantitativa de Procesos............................................................... 37

Nivel 5 ........................................................................................................................ 43Prevencin de Defectos: ......................................................................................... 43Administracin de Cambios tecnolgicos .............................................................. 45Ejecucin de Peer Reviews .................................................................................... 45Administracin de cambios: ................................................................................... 47

Apndice B Glosario de Trminos .............................................................................. 49Apendice C Referencias .............................................................................................. 50


3


4/50


Modelo de maduracin de la capacidad

Motivacin

Luego de varias dcadas de no obtener resultados satisfactorios al con nuevas

tecnologas y metodologas de software, el sector empresarial y gubernamental, se dacuenta que sufre de incapacidad al manejar sus procesos de software. Por esos aos, losproyectos generalmente padecan de demoras excesivas as como duplicacin delpresupuesto acordado. En estas circunstancias era imposible apreciar las ventajas podanproveer las nuevas metodologas y mtodos.

Es por eso que en noviembre de 1986, el Software Engineering Institute (SEI), con laasistencia de Mitre Corporation, comenz a desarrollar un framework de madurez deproceso, el que asistira a las organizaciones a mejorar su proceso de Software. Enseptiembre de 1987, el SEI presenta una breve descripcin del mencionado [Humphrey87a] el cual fuera posteriormente profundizado en el libro de Humphrey Managing

the Software Process [Humphrey89]. Dos mtodos, Aseguracin de procesos desoftware y Cuestionario de madurez y evaluacin [Humphrey87b] fuerondesarrollados para aproximar la madurez de procesos de Software.

Luego de experimentar por cuatro aos el framework de Madurez de Procesos y unaversin preliminar del cuestionario de madurez, el SEI evolucion el mencionadoframework a lo que es el Modelo de madurez de capacidad (o Capability MaturityModel for Software) (CMM) [Paulk91, Weber91]. El CMM presenta un conjunto deprcticas recomendadas dentro de varias reas de proceso clave que han demostradorealzar la capacidad de proceso del Software. Est basado en el conocimiento adquiridopor mejoras en el proceso de software y extensivo feedback tanto de la industria como

del gobierno.

Este modelo provee a las organizaciones de Software de una gua de cmo controlar losprocesos para desarrollar y mantener software adems de cmo evolucionar en unacultura de ingeniera de Software y administracin de excelencia. Fue diseado paraguiar a las organizaciones a seleccionar estrategias para mejorar procesos determinandola madurez actual del proceso e identificando algunos inconvenientes crticos en lacalidad de Software y mejora del proceso. Concentrndose en un conjunto deactividades y trabajando agresivamente para lograrlas, una organizacin puede mejorarla amplitud de proceso permitiendo logros continuos y capacidad perdurable.

Madurez de una OrganizacinUna organizacin de Software puede clasificarse de acuerdo a cuan madura sea.

La madurez est relacionada con el seguimiento fiel a un proceso preestablecido.

En organizacin de software inmadura, los procesos generalmente son improvisados porquienes llevan adelante cada proyecto en toda su duracin. Hay casos que si bien existeun proceso de software especifico, el mismo no es seguido fielmente durante elproyecto. Las organizaciones con estas caractersticas se las conoce como reactivas oreaccionarias ya que los managers suelen estar concentrados en resolver crisisinmediatas (mas bien conocidas como apagar el incendio). Sucede que laplanificacin y los presupuestos son excedidos con frecuencia debido a que susestimaciones no estn basadas en datos reales. Esta situacin hace que las


4


5/50


organizaciones inmaduras vean comprometida la calidad y funcionalidad de susproductos cuando se imponen deadlines estrictos (fecha de entrega).

No existen bases slidas para realizar un juicio sobre la calidad de un producto o pararesolver un problema de produccin o de proceso. Esto conlleva a que la calidad del

producto no sea predecible y que las actividades que se realizan para incrementar lacalidad como la verificacin y testeo, se vean restringidas o eliminadas cuando seexceden los planes.

En cambio, las organizaciones de software maduras poseen una gran capacidadde organizacin a la hora de manejar el desarrollo de software y el proceso demantenimiento. El proceso es rigurosamente respetado y conocido con precisin por elstaff existente y los nuevos empleados. Los procesos definidos estn listos para serusados [Humphrey91b] y son consientes en la manera en la que el trabajo es realizado.Estos procesos son actualizados cuando es necesario, y se buscan mejoras a travs depruebas pilotos controladas realizando anlisis de costo beneficio. Los roles y las

responsabilidades dentro del proceso definido son claramente establecidas en cadaproyecto y en toda la organizacin.

En organizaciones maduras, los managers controlan la calidad del producto desoftware a la vez que estiman la satisfaccin del cliente. Hay bases cuantitativas yobjetivas para la evaluacin de la calidad del producto y el anlisis del problema con elproducto y el proceso. Se usan datos histricos para el planeamiento y el presupuesto.Todo esto hace que los resultados esperados para el costo, planeamiento, funcionalidady calidad del producto sean generalmente alcanzados. En general, se sigue fielmente unproceso disciplinado ya que todos los participantes entienden el valor de hacerlo,adems de que existe la infraestructura necesaria para soportar el proceso.

Visin general de CMM

En las organizaciones de Software que quieren mejorar sus procesos deproduccin uno de los problemas que surgen es que no hay acuerdo sobre qu mejorasdeben realizarse. Para solucionar este conflicto es necesario contar con una estrategiaorganizativa que provea una lista ordenada de mejoras a aplicar. CMM proponealcanzar los resultados mediante pequeos cambios evolutivos. El framework demaduracin de proceso de software [Humphrey 87a] ordena los cambios por etapas de

manera tal que el mejoramiento de cada una de ellas brinde una base sobre la cualencarar la siguiente etapa de mejora. De esta manera, el framework describe unaestrategia para mejoras continuas, guiando el avance e identificando deficiencias en laorganizacin; sin embargo CMM no provee mejoras rpidas.

CMM brinda, a las organizaciones de software una gua de cmo controlar susprocesos para desarrollo y mantenimiento del software, y como evolucionar hacia lacultura de ingeniera de software y excelencia en la administracin. El CMM fuediseado para guiar a la organizacin de software en el proceso de seleccin deestrategias de mejoras para determinar el nivel actual de madurez e identificar algunosproblemas crticos en la calidad del software y en la mejora del proceso. La forma de

lograr los objetivos propuesta es concentrarse en un conjunto de actividades y trabajar


5


6/50


agresivamente para lograrlas de manera que estas provean logros continuos y duraderosen el proceso de software.

Los cinco niveles de maduracin de proceso de software

La mejora continua de procesos esta basada en realizar pequeos cambiosevolutivos en lugar de una innovacin revolucionaria [Imai86]. El CMM brinda a lasorganizaciones un marco para organizar los pasos de la mejora en cinco niveles demadurez, estableciendo fundamentos para la mejora continua del proceso. Estos cinconiveles, definen una escala ordenada para evaluar la madurez del proceso de software.Adems, estos niveles sirven para priorizar sus esfuerzos para la mejora.

Un nivel de maduracin es una plataforma definida con objetivos claros de manera tal,

que cuando son cumplidos, se estabiliza una componente importante del proceso desoftware. Cada uno de los niveles de madurez provee fundamentos para la mejora delsiguiente nivel, resultando en un crecimiento en la capacidad de la organizacin.

En la figura anterior se muestran los cinco niveles de maduracin junto con las accionesprioritarias para lograr un ascenso de un nivel a otro. Los cinco niveles pueden serdescriptos brevemente como:

1. Inicial: el proceso de software esta caracterizado como ad hoc yocasionalmente catico. Algunos procesos estn definidos, y el xito dependedel esfuerzo individual y no de la organizacin.

2. Repetible: procesos administrativos bsicos en los proyectos para elseguimiento de costo, planeamiento y funcionalidad. La disciplina necesariaen los procesos1 es acorde para repetir xitos anteriores de proyectos con

1 Todas las veces que se nombra tanto al proceso, como a los productos, actividades y proyectos se estrefiriendo al proceso (productos, actividades, etc.) del software, salvo que se indique lo contrario.


6


7/50


aplicaciones similares.3. Definido: el proceso para la administracin y la ingeniera esta documentado,

estandarizado e integrado a un proceso estndar para la organizacin. Todoslos proyectos usan una versin del proceso estndar de la organizacinaprobada y ajustada para el desarrollo y manutencin del software.

4. Administrado: Se detalla medidas para que el proceso de software y lacalidad del producto sean recolectados. Ambos son entendidos y controladoscuantitativamente.

5. Optimizado: existe un feedback cuantitativo del proceso, lo que permite unamejora continua del mismo. Tambin se manejan ideas y tecnologasinnovadoras.

Entendiendo el CMMEl CMM es un modelo descriptivo en el sentido que describe los atributos esencialesque se esperan para caracterizar a una organizacin en un nivel de maduracin enparticular. Es decir, es un modelo normativo en el sentido de que detalla prcticas quecaracterizan el tipo normal de comportamiento que se espera en los proyectos de granescala de una organizacin en el contexto de contrataciones gubernamentales. Laintencin es que el CMM brinde un nivel de abstraccin que no sea excesivamenterestricto, sino cmo el proceso de software es implementado.

En cualquier contexto en el cual el CMM puede ser aplicado, se debera usar unainterpretacin razonable de las actividades a realizar.

El CMM no es prescriptito, es decir no dice a la organizacin cmo debe mejorar. El

CMM dice en qu nivel se encuentra una organizacin sin decir una manera especificade cmo llegar a l. Puede tomar varios aos pasar de nivel 1 a 2, aunque aumentar denivel 2 a 3, de 3 a 4, etc. solo toma aproximadamente dos aos.

Mejoramientos en el proceso de software ocurren dentro del contexto de los planesestratgicos y objetivos de negocio de la empresa, sus estructuras organizativas, latecnologa usada, su cultura social, y su sistema de administracin. El CMM seconcentra en aspectos del proceso de la Administracin de calidad total producida;mejoramientos de procesos exitosos que los aspectos externos al alcance del proceso desoftware son tambin.

Caractersticas de Comportamiento de los Niveles deMadurez

La madurez de los niveles 2 a 5, se puede caracterizar a travs de:

Las Actividades que realiza la organizacin para establecer o mejorar el procesode software.

Las Actividades desarrolladas en casa proyecto La Capacidad de proceso resultante a travs de los proyectos.


7


8/50


A su vez, cada nivel de CMM, aumenta la visibilidad dentro del proceso de softwaretanto para el manager como para el equipo de ingeniera: los ingenieros de softwaretienen una visin detallada del estado del proyecto porque son los primeros que recibeninformacin acerca del estado y la performance del proyecto. En grandes proyectos, lavisin est usualmente est delimitada por la experiencia personal en el rea de su

responsabilidad, por lo que podemos entonces, caracterizar tambin a los niveles demadurez por el nivel de visibilidad que este posee.

A continuacin se describir brevemente cada uno de los niveles teniendo en cuentatodos y cada uno de los aspectos anteriores.

Nivel 1: Nivel Inicial (Initial Level)

La organizacin tpicamente, no provee un ambiente estable para el desarrollo ymantenimiento del software, por lo que, los beneficios de una buena prctica de

ingeniera de software, se ven socavados por un inefectivo planeamiento ysistemas obligados a reaccionar. Aunque las organizaciones de Nivel 1,frecuentemente se caracterizan por ser ad hoc e incluso caticas, los procesosque stas desarrollan, en su mayora, son productos que funcionan, aunque estnpor encima del presupuesto y del cronograma previamente estipulados.

Durante una crisis, los proyectos abandonan los procedimientos planeados y selimitan al cdigo y al testeo. El xito depende en su totalidad, de tener un buenmanager y del equipo de software.

La capacidad de los procesos de software de la organizacin es impredecible, elproceso de software constantemente esta cambiando mientras el trabajoprogresa. La planificacin, el presupuesto, la funcionalidad y la calidad delproducto son impredecibles. La performance depende de las capacidades de losindividuos y vara de acuerdo a sus habilidades, conocimientos y motivaciones.La capacidad, es una caracterstica de los individuos, no de las organizaciones.Las organizaciones de Nivel 1, con frecuencia, se exceden en los cronogramas yfechas de entrega por un amplio margen. El tiempo de desarrollo se veincrementado por las actividades que hay que realizar para corregir errores.

En el nivel inicial, el proceso de software es una entidad amorfa, una caja negra,y la visibilidad de los procesos del proyecto es limitada. Como la secuencia deactividades no est bien definida, los administradores tienen una gran dificultadpara definir el estado del progreso del proyecto, los tiempos y sus actividades.Los requerimientos dentro del proceso de software fluyen de maneradescontrolada.

Nivel 2: Nivel Repetible (Repeteable Level)

Un objetivo de este nivel es institucionalizar procesos de administracinefectivos para los proyectos de software, que permitan a las organizacionesrepetir prcticas exitosas desarrolladas en proyectos anteriores, aunque la


8


9/50


implementacin especfica del proceso pueda variar en los distintos proyectos.Los administradores se deben centrar en sus propios procesos para adquirir unadisciplina de proceso de software. stos pueden diferir entre los proyectos de laorganizacin; las organizaciones deben tener polticas que sirvan como guapara establecer una correcta administracin de los procesos.

Los proyectos implementan procesos efectivos que son definidos,documentados, utilizados, entrenados, medidos, reforzados y mejorados. Sedefinen los estndares de los proyectos de software y la organizacin aseguraque stos sern fielmente respetados. El manager del proyecto controla loscostos, cronogramas y funcionalidades; los problemas en el cumplimiento de loscompromisos son identificados a medida que surgen.El proyecto de softwaretrabaja con subcontratantes, si existiera alguno, para establecer una relacincliente proveedor efectiva.

La capacidad de los procesos de software de una organizacin de Nivel 2, esdisciplinada, la planificacin y el control del proyecto de software es estable yxitos anteriores pueden ser repetidos. El proceso del proyecto est bajo uncontrol efectivo del sistema de administracin del proyecto, siguiendo planesrealistas y basados en la performance de proyectos previos.

En este nivel, se realiza un control requerimientos del cliente vs. trabajorealizado, y se establecen prcticas bsicas para la administracin de losproyectos. El proceso de desarrollo de software puede ser visto como unasucesin de cajas negras que, en ciertos puntos de transicin (los de control),permiten a los administradores incrementar su visibilidad mientras lasactividades fluyen dentro de esas cajas. El administrador puede no conocer las

actividades realizadas dentro de las cajas. Se conocen tanto los puntos de controlpara confirmar el avance como los productos finales del proceso.

Nivel 3: Nivel Definido (Defined Level)

En este nivel, se documenta el proceso (o los procesos) estndares para eldesarrollo y mantenimiento de software de toda la organizacin. stos procesos,se usan (y mantienen) para ayudar a los administradores de software y al equipotcnico a desempearse de manera ms eficiente. La organizacin explota lasprcticas efectivas de ingeniera de software cuando estandariza sus procesos desoftware.

Los proyectos se ajustan a los procesos de software estndares de laorganizacin para desarrollar su propio proceso de software definido, el cual seadapta a las caractersticas nicas del proyecto (lo que se conoce como procesode software definido del proyecto). Un proceso bien definido puede sercaracterizado como aquel que incluye legibilidad, criterio, entradas, estndares yprocedimientos para realizar el trabajo, mecanismos de verificacin, salidas, ycriterios de completitud. Como el proceso de software est bien definido, laadministracin tiene una buena visin interna del progreso tcnico del proyecto.


9


10/50


La capacidad del proceso de software de las organizaciones de nivel 3 puede serresumida como estndar y consistente porque tanto la ingeniera de softwarecomo las actividades de administracin son estables y repetibles. Esta capacidadde proceso se basa en un entendimiento comn y organizacional de lasactividades, roles, y responsabilidades en un proceso de software definido.

En el nivel definido, la estructura interna de las cajas, es decir, las tareas en elproceso de software del proyecto, son visibles y representan la forma en la queel proceso de software estndar de la organizacin ha sido aplicado a proyectosespecficos. Administradores e ingenieros entienden sus roles yresponsabilidades en el proceso y como sus actividades interactan en el niveladecuado de detalle. La administracin est preparada para riesgos que puedanocurrir.

Nivel 4: Nivel Administrado (Manager Level)

La organizacin establece objetivos de calidad tanto para productos como paraprocesos de software. Una base de datos de procesos de software de laorganizacin, se usa para recolectar y analizar los datos disponibles de los

procesos de software definidos de los proyectos. stos procesos de software sonimplementados con medidas bien definidas y consistentes. Estas medidasestablecen los fundamentos cuantitativos para evaluar los procesos y productosde software del proyecto.

Los proyectos alcanzan el control sobre sus productos y procesosdisminuyendo la variacin de la performance de sus procesos para mantenerseen lmites cuantitativos aceptables. Las variaciones significativas de laperformance del proceso pueden ser distinguidas de la variacin aleatoria(ruido), particularmente en las lneas de producto establecidas. Los riesgosinvolucrados al mover la curva de aprendizaje (?) del dominio nuevo de unaaplicacin son conocidos y administrados cuidadosamente.

La capacidad del proceso de software de las organizaciones de nivel 4 puedeser resumida como predecible, porque el proceso se mide y opera dentro delmites cuantitativos. Este nivel de capacidad de proceso, permite a unaorganizacin predecir tendencias en la calidad de software y productos que seajusten a esos lmites; en caso de que se excedan, se toman acciones corregir lasituacin. Los productos de software son de una calidad predeciblemente alta.

Los procesos de software definidos se instrumentan y controlancuantitativamente. Los administradores son capaces de medir el progreso y losproblemas. Tiene una base cuantitativa para tomar decisiones. Su habilidad parapredecir las salidas crece de forma estable y precisa mientras que la variabilidaden el proceso disminuye.

Nivel 5: Nivel Optimizando (Optimizing Level)


10


11/50


En el Nivel Optimizado, toda la organizacin se concentra en la mejoracontinua del proceso. La organizacin tiene los medios para identificarproactivamente las debilidades y fortalezas del proceso, con el objetivo deprevenir los defectos. Los datos, en la efectividad de los procesos desoftware, se usan para realizar anlisis de costo/beneficios de nuevas

tecnologas y de cambios propuestos a los procesos de software de laorganizacin. Se identifican y transfieren, a lo toda la organizacin,innovaciones que aprovechan lo mejor de la prctica de ingeniera desoftware.

Durante el desarrollo del proyecto, se analizan defectos para determinar sucausa. Se evalan los procesos de software para prevenir la recurrencia entipos de defectos conocidos y esto se transfiere a toda la organizacin.

La capacidad del proceso de software de las organizaciones de nivel 5 puedeser caracterizada como de mejoramiento continuo, las organizaciones seesfuerzan continuamente en ampliar el rango de la capacidad de susprocesos, mejorando as la performance de sus proyectos; este mejoramientose da por dos causas: el avance incremental en los proyectos existentes, y porlas innovaciones usando nuevas tecnologas y mtodos. Las mejoras detecnologas y mtodos se planean y administran como actividades denegocios ordinarias.

La disciplina y el cambio son una forma de vida y las actividadesdefectuosas se identifican y reemplazan. La visibilidad se extiende ms allde la existencia de los procesos y dentro de los efectos de potencialescambios a los mismos. Los administradores son capaces de estimar y de

hacer un seguimiento cuantitativo del impacto y de la efectividad delcambio.

Capacidad de Proceso y Prediccin de la Performance

La madurez del proceso de software de una organizacin, ayuda a predecir lahabilidad de los proyectos para alcanzar los objetivos. A medida que el proceso desoftware de la organizacin va madurando, las organizaciones obtienen una mejora enalcanzar sus objetivos esperados en tres aspectos:

1.

Prediccin: la diferencia entre los resultados esperados y los resultado obtenidosdisminuye en los procesos2. Control: al incrementar la madurez la variabilidad de los resultados actuales

entorno a los resultados esperados disminuye.3. Efectividad; los resultados esperados mejoran al incrementarse la madurez de la

organizacin; los costos disminuyen, los tiempos de desarrollo se tornan mscortos y la productividad y calidad aumentan.

En la figura, las salidas del proyecto de software son ms predecibles eliminado el ruidodel proceso conforme aumenta la madurez. En sistemas sin precedentes, las nuevastecnologas y aplicaciones, disminuyen la capacidad de un proceso e incrementan la

variabilidad. La administracin y las prcticas de ingeniera caractersticas deorganizaciones ms maduras ayudan a identificar y tratar los problemas ms temprano


11


12/50


en el ciclo de desarrollo. En algunos casos un proceso maduro significa que proyectosque fallarn se identifican antes en el proceso de software.

Salteando Niveles de Madurez

Los niveles de madurez de CMM, especifican las caractersticas de unaorganizacin para un nivel de madurez. Cada nivel se sienta sobre las bases de los

niveles que lo preceden para implementar los procesos efectiva y eficientemente.

De cualquier forma, las organizaciones pueden hacer un uso beneficioso de losprocesos descriptos en niveles superiores; los procesos de ingeniera tales como elanlisis de requerimientos, el diseo, la codificacin y el testeo, no se discuten hasta elNivel 3 de CMM, pero las organizaciones de Nivel 1 deben desarrollar estasactividades. Una organizacin de Nivel 1 o de Nivel 2, puede ser capaz de realizar peerreviews (Nivel 3), hacerAnlisis de Pareto (Nivel 4) probar nuevas tecnologas (Nivel5) y sacar provecho de estas tcnicas.

Sin embargo, estos procesos no pueden lograr por completo su potencial, hastaque no se hallan establecido las correspondientes bases; peer reviews no pueden ser


12


13/50


completamente efectivo hasta que el producto de software no est implementadoconsistentemente.

Saltear niveles es contraproducente pues cada nivel representa la base necesariapara alcanzar el nivel siguiente. CMM identifica los niveles a travs de los cuales la

organizacin debe desenvolverse para establecer una cultura de ingeniera de softwarede excelencia. Aquellos niveles que no tienen estas bases correctamente desarrolladas,fallan en los puntos en los que son ms necesarios y no proveen ningn aporte al futuromejoramiento.

Los esfuerzos por mejorar los procesos, se deben centrar en las necesidades de laorganizacin en el contexto de su ambiente de negocio. La habilidad paraimplementar procesos de niveles de madurez ms altos, no implica que estos nivelespuedan ser salteados.


13


14/50


Definicin operacional de CMMTal como se comentara anteriormente, CMM representa un framework para realizarmejoras sobre organizaciones que desarrollan software y desean incrementar lacapacidad de su proceso de produccin. Se considera al CMM como un modelodescriptivo dado que describe atributos claves que se esperan para caracterizar unaorganizacin en un determinado nivel de madurez. Por otro lado, es considerado unmodelo normativo en el sentido que existen prcticas que caracterizan los tipos decomportamiento esperados de una organizacin que realiza proyectos a gran escala.

El CMM describe el resultado esperado del proceso pero sin indicar comoimplementarlo, es por eso que es considerado prescriptivo. Por otra parte, CMM tieneuna estructura diseada para proveer soporte a diferentes grupos o equipos dentro de laorganizacin.

Grupos de verificacin usan CMM para identificar puntos dbiles oproblemticos en la organizacin.

Equipos de evaluacin usan el CMM para identificar los riesgos de seleccionarentre diferentes contratistas, ganar licitaciones y monitorear contratos.

Gerentes y Staff Tcnico usa CMM para entender actividades necesarias paraplanificar e implementar una mejora en el proceso de la organizacin.

Grupos de Mejora de Proceso tales como SEPG usan CMM como gua paradefinir y mejorar el Proceso de Software de la organizacin.

Dada la vasta aplicacin del CMM, es necesario que sea descompuesto en suficientedetalle para que las recomendaciones de cada proceso puedan ser derivadas desde laestructura de los niveles de madurez. La descomposicin, adems, indica que losprocesos y su estructura caracterizan la madurez y capacidad del proceso de software.

La estructura interna de los Niveles de Madurez

Cada nivel de madurez ha sido descompuesto en distintas partes. A excepcin del nivel1, la descomposicin de cada nivel abarca desde resmenes abstractos hasta sudefinicin operacional en prcticas claves. Cada nivel de madurez se compone de variasreas de proceso clave. Segn [KPCMM93] un rea de proceso clave es un abanico deactividades interrelacionadas, que cuando son llevadas a cabo, logran un conjunto deobjetivos considerados importantes para establecer la capacidad de un proceso. Cadarea clave de proceso ha sido cuidadosamente definida para abordar un nico nivel demadurez. Por convencin, cada una de estas, es organizada en cinco grupos llamadascaractersticas comunes. Estas son atributos que indican que tanto la implementacincomo la institucionalizacin, es efectiva, repetible y perdurable.


14


15/50


Los cinco grupos son:

Objetivos a realizar: Describe acciones que la organizacin debe tomar para asegurarseque el proceso esta establecido y perdurar. Tpicamente involucra establecer polticasorganizacionales y aval de la cpula administrativa.

Capacidad para realizar: Precondiciones que deben existir en un proyecto uorganizacin para implementar el proceso de software completamente. Suele involucrarrecursos, estructura organizacional y entrenamiento.

Actividades desarrolladas: Describen los roles y procedimientos necesarios paraimplementar un rea clave de proceso. Tpicamente involucra planes y procedimientos,realizar el trabajo, seguirlo y tomar acciones correctivas.

Medicin y anlisis: Describe la necesidad de medir el proceso y analizar dichasmediciones. En general suele incluir ejemplos de las medidas que pueden ser tomadas

para determinar el nivel y efectividad de las Actividades desarrolladas.

Verificar Implementacin: Describe pasos para asegurarse que las actividades sondesarrolladas en el marco del proceso que ha sido establecido. Involucra revisiones yauditorias de la gerencia y aseguramiento de la calidad del software.

En resumen, Actividades desarrolladasdescribe lo que debe ser implementado paralograr capacidad del proceso. Las dems prcticas institucionalizan las prcticasdescriptas en la primera.

Cada rea clave identifica un conjunto de actividades que cuando son ejercidas enconjunto, logran objetivos considerados importantes para incrementar la capacidad deun proceso. Al plantearse un camino para abordar un rea clave, este puede diferir deproyecto en proyecto debido a diferencias en el entorno o en el dominio. Sin embargo,todos los objetivos del rea clave deben ser satisfechos para cumplimentar un rea clavede proceso. En esta situacin se dice que la organizacin ha institucionalizado sucapacidad de proceso caracterizado por el rea clave.


15


16/50


Clasificar a un rea como clave es reconocer que dicha rea es imprescindible paralograr un determinado nivel. El CMM no describe todas las reas involucradas en eldesarrollo y mantenimiento del software, sino solo aquellas que han sido identificadascomo determinantes de la capacidad de un proceso. Aunque otros factores afecten laperformance del proceso, estas reas fueron identificadas debido a que realmentemejoran la capacidad del proceso de una organizacin.

Las reas clave de proceso pueden ser consideradas los requerimientos para alcanzarun nivel de madurez. Para que esto se cumpla, las reas claves para ese nivel (y paraniveles ms bajos) deben satisfacerse y los procesos deben institucionalizarse.

Los objetivos de cada rea clave deben resumirse en prcticas clave y pueden serusados como determinantes de cundo una organizacin o proyecto ha implementadoeficientemente el rea clave de proceso. Los objetivos significan la visibilidad, loslmites y la intencin de cada rea clave de proceso. Al adaptar las prcticas clave de unrea clave de proceso a un proyecto o situacin de una organizacin especfica los

objetivos se pueden usar para determinar si la adaptacin es o no razonable. De maneraanloga, cuando se evalan alternativas de implementacin de un rea clave de proceso,


16


17/50


los objetivos pueden utilizarse para determinar si la alternativa satisface la intencin delrea clave de proceso.

A continuacin se describe brevemente el objetivo a cumplimentar en cada nivel,narrando las reas claves que son abordadas para tal fin.

reas claves de proceso en el Nivel 2

Objetivo: Establecer la administracin y control bsico del proyecto.

Administracin de requerimientos: Establecer un entendimiento comn entre el clientey los requerimientos del proyecto. Es la base para planificar y administrar el proyecto desoftware. Dado que los requerimientos del cliente con frecuencia evolucionan ycambian, documentar y controlarlos es sumamente necesario para posteriormenteusarlos como base en estimaciones, planeamiento y control de las actividades delproyecto de software a travs de todo su ciclo de vida.

Planeamiento del proyecto de software: Establecer planes razonables para realizar laingeniera de software y para administrar el proyecto. Se basa en desarrollarestimaciones realistas para llevar a cabo el trabajo y establecer los compromisosnecesarios. Estos comienzan con una declaracin del trabajo y las restricciones y lasmetas que definen y limitan el proyecto de software. El proceso de planeacin delsoftware incluye pasos para estimar el tamao del software y los recursos necesarios,para producir un cronograma, para identificar y estimar los riesgos, y para negociar loscompromisos. El plan se documenta y se mantiene como una herramienta necesaria paraadministrar el proyecto de software.

Control de proyectos de software: Establecer una adecuada visibilidad del progreso realpara que la administracin pueda tomar acciones correctivas cuando la performance delproyecto se desve significativamente de lo planeado. La administracin involucracontrolar y revisar los resultados contra el plan y tomar acciones correctivas cuandosean necesarias, basndose en los resultados reales. Estas acciones pueden incluir:revisar el plan de desarrollo de software para que refleje los resultados actuales,replanificar el trabajo restante, y/o tomar acciones para mejorar la performance.

Administracin de subcontratos: Seleccionar minuciosamente subcontratantes de

software y administrarlos efectivamente. Generalmente, la seleccin de subcontratantesse basa en la habilidad para realizar el trabajo, aunque en ciertas ocasiones se basanalianzas estratgicas de negocio. El trabajo realizado por el subcontratante y los planespara el trabajo son documentados, y el principal contratista monitorea la performance deesos planes.

Aseguramiento de la calidad del software: Proveer una administracin que poseaapropiada visibilidad dentro del proceso que esta siendo utilizado por el proyecto desoftware y los productos construidos. La visibilidad mencionada se alcanza revisando yauditando los productos de software y las actividades para verificar que cumplen con losestndares y procedimientos aplicables.


17


18/50


Administracin de configuracin de software: Establecer y mantener la integridad delos productos del proyecto a travs del ciclo de vida del mismo. La manera de alcanzaresta, es identificando la configuracin del software en ciertos puntos dados, controlandosistemticamente los cambios a la configuracin, y manteniendo la integridad de laconfiguracin a travs del ciclo de vida del software. Las lneas gua del software son

mantenidas en una librera de lneas gua a medida que se van desarrollando. Loscambios a las lneas gua y a la versin del producto de software construido, sonsistemticamente controladas y la configuracin es auditada


Objetivos: Atacar problemas del proyecto y de la organizacin, mientras staestablece una infraestructura que institucionaliza una ingeniera de software yadministracin de procesos efectiva a travs de todos los proyectos.

Concentracin del proceso organizacional: Establecer la responsabilidadorganizacional para las actividades del proceso de software que mejoran la capacidaddel proceso de toda la organizacin.Los resultados primarios de las actividades de este rea clave, son un conjunto deverificaciones de procesos de software, los cuales son descriptos en Definicin de

procesos organizacionales.

Definicin de procesos organizacionales: Desarrollar y mantener un conjunto de datosde los procesos de software utilizables que mejoran la performance del proceso a travsdel proyecto y proveen una base para definir datos significativos para la administracincuantitativa de procesos. Estos datos pueden ser recolectados de muchas formas; porejemplo, las descripciones de los ciclos de vida de software pueden ser una parteintegral de los procesos de software estndar de la organizacin. La taxonoma provistaen este rea clave delimita los aspectos de la definicin de procesos que necesitan sertratados.

Programa de capacitacin: Desarrollar las habilidades y el conocimiento de losindividuos para que puedan cumplir con sus roles efectiva y eficientemente.

La capacitacin o entrenamiento es una responsabilidad organizacional, pero losproyectos de software son responsables de identificar sus necesidades en cuanto a

habilidades y de proveer el entrenamiento necesario cuando las necesidades delproyecto son nicas.

Un programa de entrenamiento comienza por identificar necesidades de entrenamientode la organizacin, del proyecto, y del individuo, para as desarrollar un entrenamientoadecuado a las necesidades identificadas. Estas necesidades pueden ser especficas parael proyecto o el individuo en un momento particular, pero el entrenamiento requeridopuede identificarse basndose en los roles y responsabilidades especificadas en elproceso de software estndar de la organizacin. Algunas habilidades son efectiva yeficientemente impartidas a travs de vehculos informales, por ejemplo, la tutora.


18


19/50


Otras habilidades necesitan vehculos de entrenamiento ms formales, como porejemplo, entrenamiento en aulas.

Administracin integral de software: Integrar la ingeniera de software y laadministracin de actividades en un coherente, y definido proceso de software que es

adaptado al proceso de software estndar de la organizacin. Dicha adaptacin se basaen el entorno de negocios y las necesidades tcnicas del proyecto.Esta rea clave de proceso es la evolucin del planeamiento del proyecto de software ydel control del proyecto de software en el nivel 2 para tomar ventaja de lainfraestructura organizacional establecida en el nivel 3.

Ingeniera de productos de software: Llevar a cabo consistentemente un procesoingenieril bien definido que integre todas las actividades de ingeniera necesarias paraproducir software correcto y consistente de manera efectiva y eficiente. La ingeniera deproductos de software describe las actividades tcnicas del proyecto, por ejemplo,anlisis de requerimientos, diseo, codificacin y prueba.

Estos procesos de ingeniera involucran documentar los productos de software ymantener la consistencia y facilidad de seguimiento entre ellos. Esto es necesario paraasegurar una transicin controlada entre las etapas del ciclo de vida del software y paraproveer productos de software de alta calidad al cliente.

Coordinacin entre grupos: Establecer un medio para que el grupo de ingeniera desoftware participe activamente junto con otros grupos de ingeniera de manera tal que elproyecto satisfaga las necesidades del cliente efectiva y eficientemente.El grupo de ingeniera de software debe trabajar pro activamente con los otros grupos deingeniera para determinar los requerimientos y objetivos a nivel sistema. Idealmenteesto conformara un equipo de producto integrado o alguna forma de ingenieraconcurrente. En cualquier caso las interfaces e interacciones entre los grupos deben serplaneadas y administradas para asegurar la calidad e integridad del sistema en sutotalidad. Todos los grupos de ingeniera deben conocer el estado y los planes de losdems grupos, y los asuntos relativos al sistema y a los grupos deben recibir atencinapropiada.

Revisiones puntuales: Eliminar defectos de los productos de software eficientemente yen etapas tempranas.Un efecto importante es desarrollar un mejor entendimiento de los productos desoftware y de los defectos que deben ser prevenidos. La revisin es un mtodo de

ingeniera importante y efectivo, que se puede implementar mediante inspecciones,revisiones estructuradas y otros mtodos.


Objetivo: Establecer un entendimiento cuantitativo, tanto del proceso de softwarecomo de los productos que se construyen.

Administracin cuantitativa de procesos: Controlar la performance de procesos delproyecto de software de manera cuantitativa. La performance de procesos de software

representa los resultados reales alcanzados al seguir un proceso de software. Existirnvariaciones aleatorias (ruidos) en cualquier proceso. Con un proceso estable, la


19


20/50


performance se encuentra generalmente dentro de intervalos conocidos. Cuando laperformance cae fuera de esos intervalos, se necesita identificar esa causa especial dela variacin y, de ser apropiado, corregir las circunstancias que llevaron a que ocurra esavariacin. El resultado de satisfacer esta rea clave es un proceso que permanece establey cuantitativamente predecible.

Administracin de calidad de software: Desarrollar un entendimiento cuantitativo de lacalidad de los productos de software del proyecto y alcanzar objetivos de calidadespecficos.

Los objetivos cuantitativos se establecen para los productos de software, basndose enlas necesidades de la organizacin, el cliente, o el usuario final. Para que estos objetivosse alcancen, la organizacin establece estrategias y planes, y el proyecto ajustaespecficamente sus procesos de software definidos para alcanzar los objetivos decalidad. La administracin de calidad de software est concentrada en los productos,mientras que la administracin cuantitativa de procesos est concentrada en los

procesos.


Objetivo: Cubrir los inconvenientes que las organizaciones y proyectos deben localizarpara implementar mejoras continuas y medibles de procesos de software.

Prevencin de Defecto: Identificar las causas de los defectos y prevenirlos de sureincidencia.

El proceso de software analiza los procesos, identifica sus causas y toma acciones paraprevenirlos de su reincidencia. Muchas veces esto involucra el cambio del proceso desoftware definido en el proyecto. El anlisis causal resultara tambin en cambiarelementos del proceso estndar de la organizacin para controlar las causas comunes dela variacin. La Prevencin de Defectos es un mecanismo de mejora incremental delproceso de software en una forma evolutiva.

Administracin de Cambio de Tecnologa: Identificar nuevas tecnologas beneficiosas(herramientas, mtodos y procesos) y transferirlas a la organizacin de un maneraordenada.

Concentrarse en la transicin de la tecnologa implica identificar, seleccionar, y evaluarnuevas tecnologas e incorporar aquellas que sean efectivas a la organizacin. Elobjetivo es mejorar la calidad de software, incrementar la productividad y reducir entiempo de desarrollo del producto. El resultado de este foco es la innovacin eficienteen un mundo cambiante. La Administracin del Cambio de Tecnologa se refiere a lamejora del proceso de software de una manera revolucionaria.

Administracin del Cambio del Proceso: Mejorar continuamente el proceso de softwareusado en la organizacin con la intensin de mejorar la calidad del software,aumentando la productividad y reduciendo el tiempo para el desarrollo del producto.

La mejora continua del proceso incluye la definicin de los objetivos de la mejora deprocesos y, con la ayuda de la cpula administrativa, identificar proactiva y


20


21/50


sistemticamente, evaluando, e implementando mejoras al proceso de software estndarde la organizacin y al proceso de software definido del proyecto. La Administracindel Cambio del Proceso entrega de manera apropiada cambios incrementales evolutivos,cambios innovadores y revolucionarios.


21


22/50


Conclusin

El modelo de capacidad y madurez formaliza una aproximacin a la mejora del procesode software. En la comunidad del Software se han investigado con gran detalle losniveles de madurez, las reas clave de proceso, caractersticas comunes y clavesprcticas. Aunque CMM no es perfecto, este ha logrado gran aceptacin en lasorganizaciones cuyas intenciones son mejorar su proceso de produccin de software. Esuna herramienta til para priorizar los esfuerzos a realizar cuando se mejore un proceso.

El CMM provee una estructura conceptual para mejorar y administrar el proceso dedesarrollo de productos de software de manera consistente. Este no garantiza que losproductos sern exitosos o cul es la forma correcta de ingeniera. Sin embargo casossobre la aplicacin de CMM indican que ste lleva a realizar productos que logran losobjetivos de costo, calidad y productividad. [Dion92, Humphrey91b, Lipke92,

Wohlwend93].El CMM identifica prcticas para procesos de software maduros y provee ejemplos delestado de la prctica pero no indica que sean exhaustivas u obligatorias. No indicaestrategias para mejora del proceso a corto plazo, existe un periodo de adaptacin dondepuede replantearse si la mejora que se est llevando a cabo por el buen camino.

El volumen de documentacin que es agregado a medida que se escala un nivel demadurez es importante, lo que lleva a las organizaciones de niveles altos a pasar lamayora del tiempo documentando. Adems, esto condiciona el tamao de lasorganizaciones para las cuales es conveniente adoptar CMM: Cuando el tamao de la

organizacin lo permite, el aplicar CMM puede traer importantes beneficios en loscostos de desarrollo y en lo acertado de las estimaciones realizadas.


22


23/50


Apndice A - Key PracticesEn esta seccin se explican las prcticas claves que sirven para implementar la mejorade un proceso. Las prcticas que institucionalizan el nivel de madurez de unaorganizacin se pueden encontrar con nivel de detalle en Key Practices of theCapability Maturity ModelSM, Versin 1.1 de Paulk, Weber, Garcia, Crisis y Bush.[]

Como se mencion en la seccin 2, cada rea clave del proceso se divide en prcticasclave que contribuyen a cumplir con sus objetivos. Las prcticas clave describen lainfraestructura y actividades que en mayor medida contribuyen a la implementacin einstitucionalizacin del rea clave del proceso.

Estas prcticas clave, tambin llamadas prcticas clave de alto nivel, establecen laspolticas, procedimientos y actividades fundamentales para el rea clave del proyecto.Estn compuestas por sub prcticas, que describen lo que uno esperara encontrar

implementado para la prctica clave de alto nivelLas prcticas clave no deben ser interpretadas por cmo se deben lograr los objetivos, sino como qu es lo que se debe hacer. Pueden ser usadas para evaluar si los objetivos delrea clave de proceso fueron alcanzados. Su intencin es proveer una descripcin de loselementos o principios esenciales de un proceso de software efectivo, los cules sonaplicables a una gran variedad de proyectos y organizaciones, dejando suimplementacin a cada organizacin en particular, de acuerdo con su cultura y suexperiencia.

A continuacin se describen brevemente las prcticas clave para cada rea clave delproceso de cada nivel.

Nivel 2

Administracin de requerimientos

- El grupo de ingeniera de software revisa los requerimientos antes de que seincorporen al proyecto de software.

o Se identifican los requerimientos incompletos y faltantes.o Se revisan los requerimientos para determinar si son factibles y

apropiados, si estn claramente establecidos, si son consistentes ytesteables.

o Cualquier requerimiento que parezca tener problemas es revisado con elgrupo responsable de obtener los requerimientos y se realizan loscambios necesarios.

o Los compromisos resultantes de los requerimientos encontrados senegocian con los grupos afectados (Por ej, grupo de diseo, grupo detesteo, grupo de estimacin, SQA, etc)


23


24/50


- El grupo de ingeniera de software usa los requerimientos encontrados comobase para los planes, productos y actividades. Los requerimientos encontrados:

o Son administrados y controlados (hay control de versiones y de cambios)o Son la base para el plan de desarrollo de softwareo Son la base para desarrollar los requerimientos del software

- Se revisan los cambios en los requerimientos encontrados y se incorporan alproyecto.

o Se evala el impacto a los compromisos existentes y se negocian loscambios segn sea apropiado

o Se identifican, evalan, se estima el riesgo, se documentan, planean, secomunican a los grupos afectados y se rastrean hasta ser completados loscambios necesarios en los planes de software, productos y actividadesresultados de los cambios en los requerimientos.

Planeamiento del proyecto de software:

- El grupo de ingeniera de software participa en el equipo de propuesta deproyecto.

o El grupo de ingeniera de software se involucra en la preparacin yemisin de la propuesta, la discusin y emisin de las aclaraciones y enla negociacin de los cambios a los compromisos que afectan al proyectode software.

o El grupo de ingeniera de software revisa los compromisos propuestospara el proyecto (objetivos tcnicos, solucin tcnica al sistema,presupuesto, cronograma, recursos, estndares, etc).

- El planeamiento del proyecto de software se inicia en las primeras etapas, y enparalelo con, el planeamiento general del proyecto.

- El grupo de ingeniera de software participa en el planeamiento general delproyecto, junto con otros grupos afectados, a travs de la vida del proyecto.

o El grupo de ingeniera de software revisa los planes de nivel de proyecto- Se revisan los compromisos hechos a personas y grupos fuera de la organizacin

junto con la cpula administrativa de acuerdo a un procedimiento documentado.- Se define un ciclo de vida del software con etapas predefinidas de tamao

manejable (cascada, espiral, etc).

- Se desarrolla el plan de desarrollo de software para el proyecto, de acuerdo a unprocedimiento documentado. Este procedimiento tpicamente especifica que:o El plan de desarrollo de software se basa en los estndares del cliente,

segn sea apropiado; en los estndares del proyecto; en la declaracin detrabajo aprobada y en los requerimientos encontrados.

o Se negocian los planes para grupos relacionados con el software queestn involucrados en las actividades del grupo de ingeniera de software(SQA, SCM, etc.), se presupuestan los esfuerzos de soporte y sedocumentan los acuerdos.

o Se hace lo mismo para la participacin del grupo de ingeniera desoftware en las actividades de otros grupos relacionados con el software.


24


25/50


o El plan de desarrollo de software es revisado por el Project Manager, porel Project Software Manager, otros Managers de software y otros gruposafectados.

o Se administra y con trola el plan de desarrollo de software- Se documenta el plan para el proyecto de software. Este plan cubre:

o El propsito, alcance y objetivos del proyecto de softwareo La eleccin del ciclo de vida del softwareo Identificacin de los procedimientos, mtodos y estndares elegidos para

desarrollar y/o mantener el software (plan de desarrollo de software,SCM, SQA, etc.).

o Identificacin de los productos de software a ser desarrolladoso Estimaciones del tamao de los productos de software y de cualquier

cambio aplicado a ellos.o Estimaciones de los costos y esfuerzo del proyecto.o Uso estimado de recursos computacionales crticos.o Cronograma del proyecto, incluyendo identificacin de milestones y

revisiones.o Identificacin y evaluacin de los riesgos del proyecto.o Planes para las herramientas e instalaciones de ingeniera de software del

proyecto.- Se identifican productos de software necesarios para establecer y mantener el

control del proyecto.- Se derivan las estimaciones del tamao o cambios en el tamao de los productos

del software de acuerdo a un procedimiento documentado. Este procedimientotpicamente especifica que:

o Se realicen estimaciones de tamao para los mayores productos yactividades (puntos funcin, lneas de cdigo, etc.).

o Se descomponen los productos hasta la granularidad necesaria paraalcanzar los objetivos de estimacin.

o Se usan datos histricos donde sea posible.o Se documentan las suposiciones de estimacin de tamao.o Se documentan, revisan y acuerdan las estimaciones de tamao.

- Se derivan las estimaciones para el esfuerzo y el costo del proyecto de acuerdo aun procedimiento documentado. Este procedimiento tpicamente especifica que:

o Las estimaciones para el esfuerzo y el costo del proyecto se relacionancon las estimaciones del tamao de los productos (o sus cambios).

o Se usan los datos de productividad (histricos y/o actuales) cuando estndisponibles. Las fuentes de esos datos se documentan.o Las estimaciones de esfuerzo, personal y costos se basan en experienciaprevia.

o Se documentan, revisan y se acuerdan las estimaciones y lassuposiciones hechas al derivar las mismas.

- Se derivan las estimaciones para el uso de recursos de computacin crticos delproyecto de acuerdo a un procedimiento documentado. Este procedimiento sueleespecificar que:

o Se identifican los recursos de computacin crticos para el proyecto.o Se relacionan las estimaciones para los recursos de computacin crticos

con el tamao de los productos, la carga de procesamiento operacional y

el trfico de comunicaciones.


25


26/50


o Se documentan, revisan y se acuerdan las estimaciones de los recursos decomputacin crticos.

- Se deriva el cronograma del proyecto de acuerdo a un procedimientodocumentado. Este procedimiento suele especificar que:

o Se relaciona el cronograma con el tamao estimado de los productos ycon el costo y el esfuerzo

o El cronograma se basa en experiencias anteriores.o El cronograma se acomoda a las fechas impuestas para los milestones,

fechas crticas de dependencias y otras restricciones.o Las actividades del cronograma son de duracin apropiada y los

milestones tienen una separacin temporal apropiada para soportarcerteza en la medicin del progreso.

o Se documentan las suposiciones hechas al derivar el cronograma.o Se documenta, revisa y acuerda el cronograma.

- Se identifican, evalan y documentan los riesgos asociados con el costo,recursos, cronograma y aspectos tcnicos del proyecto.

o Se analizan y priorizan los riesgos en base a su impacto potencial en elproyecto.

o Se identifican las contingencias para los riesgos.- Se preparan los planes para las instalaciones de ingeniera y herramientas de

soporte para el proyectoo Se basan las estimaciones de requerimientos de capacidad para esas

instalaciones y herramientas de soporte en las estimaciones de losproductos y otras caractersticas.

o Se asignan las responsabilidades y se negocian los compromisos paraobtener o desarrollar esas instalaciones y herramientas de soporte.

o Los planes son revisados por todos los grupos afectados.- Se registran los datos del planeamiento del software

o La informacin registrada incluye las estimaciones y la informacinnecesaria para reconstruir las mismas y evaluar su coherencia.

o Los datos de planeamiento del software son administrados y controlados.

Control de proyectos de software:

- Se utiliza un plan de desarrollo de software para comunicar el estado y llevarcuenta de las actividades.

o Se actualiza este plan a medida que el trabajo avanza para reflejar loslogros, particularmente cuando se completan los milestones.

o El plan debe estar disponible inmediatamente para el grupo de ingenierade software, los administradores, la cpula administrativa y otros gruposafectados.

- Se revisa el plan de desarrollo de software de acuerdo a un procedimientodocumentado. Este proceso normalmente especifica que:

o Se revisa el plan de desarrollo de software para incorporar refinamientosy cambios en el plan, especialmente cuando los planes cambian demanera significativa.

o Se actualiza el plan para incorporar todos los nuevos compromisos ycambios a los compromisos.Ingenieria de Software 2006 U.N.C.P.B.A.

Alvarz Bilbao Goi Saavedra26


27/50


o Se revisa el plan de desarrollo de software en cada revisin.o Se administra y controla el plan de desarrollo de software.

- Se revisan junto con la cpula administrativa los compromisos del proyecto, ycambios a los mismos hechos para individuos y grupos externos a laorganizacin de acuerdo a un procedimiento documentado.

- Se comunican los cambios aprobados en los compromisos que afecten alproyecto a los miembros del grupo de ingeniera de software y a los demsgrupos relacionados

- Se lleva registro del tamao de los productos (o cambios en el tamao de losmismos) y se toman acciones correctivas segn sea necesario.

o Se lleva cuenta del tamao de los mayores productos.o Se compara el tamao real del cdigo (generado, completamente testeado

y entregado) con las estimaciones documentadas en el plan de desarrollode software.

o Se comparan las unidades reales de documentacin entregadas con lasestimaciones documentadas en el plan de desarrollo de software.

o Se refina, monitorea y ajusta de forma regular el tamao globalproyectado de los productos (estimados y reales).

o Se negocian y documentan los cambios en las estimaciones del tamaode los productos que afecten los compromisos realizados con los gruposafectados.

- Se lleva cuenta del esfuerzo y costos del proyecto, y se toman accionescorrectivas segn sea necesario.

o Se comparan las gastos de esfuerzo y los costos por tiempo y por trabajocompletado contra las estimaciones documentados en el plan dedesarrollo de software para identificar excesos y subestimaciones.

o Se lleva registro de los costos y se comparan contra las estimacionesdocumentadas en el plan de desarrollo de software.

o Se compara el esfuerzo y el personal asignado con las estimacionesdocumentadas en el plan de desarrollo de software.

o Se negocian y documentan los cambios en el personal y otros costos queafecten los compromisos con los grupos afectados.

- Se monitorean los recursos computacionales crticos y se toman accionescorrectivas segn sea necesario,

o Se monitorean y comparan el uso real y estimado de los recursoscomputacionales crticos contra las estimaciones para cada componenteimportante tal y como fueron documentadas en el plan de desarrollo de

software.o Se negocian los cambios en las estimaciones de recursoscomputacionales crticos con los grupos afectados y se documentan

- Se monitorea el cronograma del proyecto y se toman acciones correctivas segnsean necesarias.

o Se comparan las culminaciones de las actividades, milestones y otroscompromisos contra el plan de desarrollo de software

o Se evala el impacto en futuras actividades y milestones de los efectosde culminaciones tempranas o tardas de las actividades, milestones yotros compromisos.

o Se negocian y documentan las revisiones del cronograma que afecten loscompromisos con los grupos afectados.


27


28/50


- Se monitorean las actividades tcnicas de ingeniera de software y se tomanacciones correctivas segn sean necesarias.

o Los miembros del grupo de ingeniera de software reportan regularmentesu estado tcnico a su administrador inmediato.

o Se comparan los contenidos de las entregas de software para sucesivasbuilds contra los planes documentados en el plan de desarrollo desoftware.

o Se reportan y documentan problemas en cualquiera de los productos.o Se monitorean los reportes de problemas hasta su cierre.

- Se monitorean los riesgos asociados con costos, recursos, cronograma y aspectostcnicos del proyecto.

o Se ajustan las prioridades de los riegos y sus planes de contingenciasegn la informacin que se va haciendo disponible.

o Se revisan regularmente las reas de riesgo con el Project manager.- Se registran los datos de mediciones reales y replaneamiento del proyecto.

o La informacin registrada incluye las estimaciones e informacinasociada para reconstruir las estimaciones y verificar su coherencia.

o Se administra y controla la informacin del replaneamiento.o Se archivan los datos de planeamiento, replaneamiento y mediciones

reales para su uso en proyectos en curso y futuros.- El grupo de ingeniera de software conduce revisiones internas peridicas para

monitorear el progreso tcnico, los planes, el desempeo y los problemas contrael plan de desarrollo de software. Estas revisiones se conducen entre:

o Los managers inmediatos y sus lderes de tareaso El manager de software del proyecto, los managers de software

inmediatos y otros managers de software segn sea apropiado.- Se realizan revisiones formales para verificar los cumplimientos y resultados del

proyecto en milestones seleccionados de acuerdo a un procedimientodocumentado.

o Se planean estas revisiones para que tengan lugar en puntossignificativos del cronograma del proyecto, tales como el principio ofinalizacin de etapas seleccionadas.

o Estas revisiones son conducidas junto con el cliente, usuario final ygrupos afectados dentro de la organizacin, segn sea necesario.

o Las revisiones usan materiales que son revisados y aprobados por losmanagers responsables.

o Las revisiones verifican los compromisos, planes y estado de lasactividades, as tambin como los riesgos del proyecto.o Estas revisiones tienen como resultado la identificacin y documentacinde asuntos, acciones y decisiones significativas, y tambin elrefinamiento del plan de desarrollo de software si es necesario.


28


29/50


Aseguramiento de la calidad del software:

- Se prepara un plan de SQA para el proyecto, de acuerdo a un procedimientodocumentado. Este procedimiento normalmente especifica que:

o El plan de SQA se desarrolla en las etapas tempranas, y en paralelo a, elplan general del proyecto.

o Los grupos e individuos afectados revisan el plan de SQA.o Se administra y controla el plan de SQA.

- Se realizan las actividades del grupo de SQA de acuerdo a lo establecido en elplan. Este plan cubre:

o Responsabilidades y autoridad del grupo de SQAo Requerimientos de recursos para el grupo de SQA (personal,

herramientas e instalaciones).o Cronograma y fondos para las actividades del grupo de SQA durante el

proyecto.o La participacin del grupo de SQA en establecer el plan de desarrollo,

estndares y procedimientos para el proyecto.o Las evaluaciones a ser realizadas por el grupo de SQA.o Las auditorias y revisiones a ser realizadas por el grupo de SQA.o Los procedimientos y estndares del proyecto a ser usados como base

para las revisiones y auditorias del grupo de SQA.o Procedimientos para documentar y monitorear asuntos de

incompatibilidad hasta su cierre.o La documentacin que el grupo de SQA debe producir.o Los mtodos y la frecuencia en que el grupo de SQA informar de sus

actividades al grupo de ingeniera de software y otros grupos

relacionados.- El grupo de SQA participa en la preparacin y revisin del plan de desarrollo desoftware, estndares y procedimientos para el proyecto.

o El grupo de SQA provee consultora y revisiones de los planesestndares y procedimientos con respecto a cumplimiento de la polticaorganizacional, de los estndares y requerimientos impuestos desdeafuera de la organizacin, estndares apropiados para el uso del proyecto,tpicos que deberan ser verificados en el plan de desarrollo de software.

o El grupo de SQA verifica que los planes, estndares y procedimientosestn en su lugar y puedan ser usados para revisar y auditar el proyecto.

- El grupo de SQA revisa las actividades de ingeniera de software para verificarsu cumplimiento.

o Se evalan las actividades contra el plan de desarrollo de software y losestndares y procedimientos designados.

o Se identifican, documentan y monitorean las desviaciones hasta su cierre.o Se verifican las correcciones.

- El grupo de SQA audita los productos designados para verificar sucumplimiento.

o Se evalan los productos entregables antes de que sean entregados alcliente.

o Se evalan los productos contra los estndares, procedimientos yrequerimientos contractuales designados

o Se identifican, documentan y monitorean las desviaciones hasta su cierre.o Se verifican las correcciones.


29


30/50


- El grupo de SQA reporta peridicamente los resultados de sus actividades algrupo de ingeniera de software.

- Se documentan y manejan las desviaciones identificadas en las actividades y losproductos de acuerdo a un procedimiento documentado.

o Se documentan y resuelven las desviaciones del plan de desarrollo desoftware y de los estndares y procedimientos designados, junto con loslderes de tareas, managers, o Project manager donde sea posible.

o Se documentan las desviaciones no resolubles del plan de desarrollo desoftware y de los estndares y procedimientos designados y se presentanal administrador senior designado para recibir los elementos que nocumplan.

o Se revisan peridicamente los elementos que no cumplen presentados aladministrador senior hasta que sean resueltos.

o Se administra y controla la documentacin de elementos que nocumplen.

- El grupo de SQA conduce revisiones peridicas de sus actividades ydescubrimientos junto con el personal de SQA del cliente, segn sea apropiado.

Administracin de configuracin de software:

- Se prepara un plan de SCM para cada proyecto de acuerdo a un procedimientodocumentado.

o El plan de SCM se desarrolla en las etapas tempranas, y en paralelo a, elplan general del proyecto.

o Los grupos e individuos afectados revisan el plan de SCM.o Se administra y controla el plan de SCM.

- Se usa un plan de SCM documentado y aprobado como la base para desarrollarlas actividades de SCM. Este plan cubre:

o Las actividades de SCM a ser desarrolladas, el cronograma de lasactividades, las responsabilidades asignadas y los recursos necesarios(incluyendo personal, herramientas e instalaciones).

o Los requerimientos y actividades de SCM a ser realizadas por el grupode ingeniera de software y otros grupos relacionados.

- Se establece un sistema de biblioteca de administracin de la configuracincomo repositorio de las lneas de base del software. El sistema de biblioteca:

o Soporta mltiples niveles de control de SCMo Proporciona el almacenado y recuperacin de elementos/unidades deconfiguracin.o Proporciona la comparticin y transferencia de elementos/unidades de

configuracin entre los grupos afectados y entre los niveles de controldentro de la biblioteca.

o Ayuda en el uso de estndares del producto para elementos/unidades deconfiguracin

o Proporciona almacenado y recuperacin de versiones archivadas deelementos/unidades de configuracin.

o Ayuda a asegurar la creacin correcta de productos desde la biblioteca delnea base del software.

o Proporciona almacenamiento, actualizacin y recuperacin de registrosde SCM.Ingenieria de Software 2006 U.N.C.P.B.A.



31/50


o Soporta la produccin de reportes de SCM.o Proporciona mantenimiento de la estructura y contenidos de la

biblioteca.- Se identifican los productos a ser puestos bajo administracin de configuracin.

o Los elementos/unidades de configuracin se eligen en base a un criteriodocumentado.

o Se asignan identificadores nicos a los elementos/unidades deconfiguracin.

o Se especifican las caractersticas de cada elementos/unidad deconfiguracin.

o Se especifica a qu lnea base pertenece cada elemento/unidad deconfiguracin.

o Se especifica en qu punto de su desarrollo cada elemento/unidad deconfiguracin se coloca bajo administracin de configuracin.

o Se identifica a la persona responsable de cada elemento/unidad deconfiguracin.

- Se inicializan, registran, revisan, aprueban y monitorean los pedidos de cambioy reportes de problemas para todas las unidades de configuracin de acuerdo aun procedimiento documentado.

- Se controlan los cambios en las lneas bases de acuerdo a un procedimientodocumentado. Este procedimiento normalmente especifica que:

o Se realizan revisiones y/o tests de regresin para asegurar que loscambios no han causado ningn efecto no intencionado en la lnea base.

o Slo se admiten unidades de configuracin aprobadas por el SCCB en labiblioteca de la lnea de base.

o Se sacan y vuelven a entrar las unidades de configuracin de forma quese mantenga la correctitud e integridad de la biblioteca de la lnea base.

- Se crean los productos de la biblioteca de la lnea de base y se controla surelease de acuerdo a un procedimiento documentado.

o El SCCB autoriza la creacin de productos desde la biblioteca base.o Los productos de la biblioteca base, tanto para uso interno como externo,

se construyen de las unidades de configuracin en la biblioteca base.- Se registra el estado de las unidades de configuracin de acuerdo a un

procedimiento documentado.o Se registran las acciones de administracin de configuracin con

suficiente detalle como para que el contenido y estado de cada unidad deconfiguracin sea conocido y las versiones anteriores puedan ser

recuperadas.o Se mantienen el estado actual y la historia de cada unidad deconfiguracin.

- Se desarrollan los reportes estndar documentando las actividades del SCM y loscontenidos de la lnea base, y se ponen a disposicin de los grupos e individuosafectados.

- Se conducen auditorias sobre la lnea de base de acuerdo a un procedimientodocumentado. Este procedimiento suele especificar que:

o Hay preparacin adecuada para la auditoriao Se evala la integridad de las lneas de baseo Se revisan la estructura e instalaciones del sistema de biblioteca de

administracin de configuracin


31


32/50


o Se verifica la completitud y correctitud de los contenidos de la bibliotecabase.

o Se verifica el cumplimiento de los estndares de SCM aplicables.o Se reportan los resultados de la auditoria al Project manager.o Las acciones de la auditoria se monitorean hasta su cierre.

Nivel 3

Concentracin del proceso organizacional:

- Se evala peridicamente el proceso y se desarrollan planes de accin para hacerfrente a los descubrimientos

- La organizacin desarrolla y mantiene un plan para sus actividades de desarrolloy mejoras del proceso. Este plan:

o Usa los planes de accin de la evaluacin del proceso y otras iniciativasde mejoramiento de la organizacin como entrada principal.

o Define las actividades que sern realizadas y el cronograma para estasactividades.

o Especifica los grupos e individuos responsables de estas actividades.o Identifica los recursos necesarios, incluyendo personal y herramientas.o Realiza peer reviews la primera vez que se produce, y cuando se realizan

revisiones importantes.o Es revisado y acordado por los managers y la cpula administrativa de laorganizacin.

- Se coordinan a nivel organizacional las actividades de la organizacin y delproyecto para mejorar sus procesos.

- Se coordina el uso de la base de datos del proceso de la organizacin a nivelorganizacional.

- Nuevos procesos, mtodos y herramientas de uso limitado en la organizacin semonitorean, evalan y, donde es apropiado, son transferidos a otras partes de laorganizacin.

- Se coordina el entrenamiento para los procesos de la organizacin y de losproyectos a lo largo de la organizacin.

o Se preparan los planes de entrenamiento en materias relacionadas con losprocesos de los proyectos y de la organizacin.

o El grupo responsable de las actividades del proceso de la organizacinpuede preparar y realizar el entrenamiento si es apropiado.

- Se informa a los grupos involucrados en implementar los procesos sobre lasactividades de la organizacin y de los proyectos para el desarrollo y mejora delproceso.

Definicin de procesos organizacionales:


32


33/50


- Se desarrolla y mantiene el proceso estndar de la organizacin de acuerdo a unprocedimiento documentado. Este proceso normalmente especifica que:

o El proceso estndar de la organizacin satisface las polticas, estndaresde proceso y de producto impuestos en la organizacin

o El proceso estndar de la organizacin satisface los procesos y productosestndar normalmente impuestos a los proyectos de la organizacin porsus clientes.

o Se incorporan herramientas y mtodos de ingeniera de software devanguardia al proceso estndar de la organizacin segn sea apropiado.

o Se describen las interfaces internas del proceso entre las distintasdisciplinas.

o Se describen las interfaces externas entre el proceso y los procesos deotros grupos afectados.

o El grupo responsable de las actividades del proceso de software de laorganizacin documenta, revisa y aprueba los cambios propuestos alproceso estndar de la organizacin.

o Se definen los planes para introducir cambios a los procesos de losproyectos en curso segn sea apropiado.

o Se realizan peer reviews a la descripcin del proceso estndar de laorganizacin la primera vez que se desarrolla y cuando se le realizancambios o agregados importantes.

o Se coloca la descripcin del proceso estndar de la organizacin bajoadministracin de la configuracin.

- Se documenta el proceso estndar de la organizacin de acuerdo a los estndaresestablecidos en la organizacin.

o Se descompone el proceso en sus elementos constituyentes hasta lagranularidad necesaria para entender y describir el proceso.

o Se describe cada elemento en funcin de los procedimientos, prcticas,mtodos y tecnologas necesarios; los estndares aplicables, las entradas,los productos producidos, etc.

- Se documentan y mantienen las descripciones de los ciclos de vida aprobadaspara el uso del proyecto.

o Los ciclos de vida son compatibles con el proceso estndar de laorganizacin.

o El grupo responsable de las actividades del proceso de la organizacindocumenta, revisa y aprueba los cambios propuestos para lasdescripciones de los ciclos de vida, antes de que sean incorporadas.

oSe someten a peer reviews las descripciones de los ciclos de vida cuandoson desarrolladas inicialmente y cuando se realizan cambios importantesa las mismas.

o Se administran y controlan las descripciones de los ciclos de vida.- Se desarrollan y mantienen las guas y el criterio para el ajuste del estndar de la

organizacin para un proyecto.o Estas cubren las guas y el criterio para seleccionar y ajustar el ciclo de

vida para el proyecto, ajustar el proceso estndar de la organizacin paracontener el ciclo de vida y las caractersticas del proyecto, y estndarespara documentar el proceso definido para el proyecto.

o El grupo responsable de las actividades del proceso de la organizacindocumenta, revisa y aprueba los cambios propuestos a las guas ycriterios de ajuste.


33


34/50


o Se administran y controlan las guas y criterios de ajuste.- Se establece y mantiene la base de datos del proceso de la organizacin

o Se establece la base de datos para obtener y disponer de los datos delproceso y productos resultantes.

o Se revisa la integridad del contenido de la base de datos y se revisan losdatos ingresados a la misma.

o Se administra y controla la base de datos.o Se controla el acceso a la base de datos para asegurar la veracidad,

integridad y completitud de los datos.o

- Se establece y mantiene una biblioteca de documentacin relacionada con elproceso.

o Se revisan los elementos candidatos y los que pueden llegar a ser tilesen el futuro se agregan a la biblioteca.

o Se catalogan los elementos de documentacin para facilitar su acceso.o Se revisan las revisiones hechas a los elementos que se encuentran en la

biblioteca y los contenidos de la misma se actualizan segn seaapropiado.

o Se ponen los contenidos de la biblioteca a disposicin de los proyectos yotros grupos relacionados.

o Se revisa peridicamente el uso de cada elemento y los resultados seutilizan para mantener los contenidos de la biblioteca.

o Se administran y controlan los contenidos de la biblioteca.

Programa de capacitacin:

- Cada proyecto desarrolla y mantiene un plan de capacitacin que especifica susnecesidades de entrenamiento. Este plan cubre:

o Las habilidades necesarias y cundo son necesarias.o Las habilidades para les cuales se requiere capacitacin y las que se

conseguirn por otros medios.o El entrenamiento necesario, para quines es necesario y cuando se

necesita.o Cmo se dar el entrenamiento.

- Se revisa y desarrolla el plan de capacitacin de la organizacin de acuerdo a unprocedimiento documentado.

o El plan usa las necesidades de entrenamiento de los proyectosidentificadas en sus planes de capacitacin

o Se identifica el entrenamiento especfico que ser provisto en base a lashabilidades que necesita la organizacin y cundo se necesitan esosconocimientos.

o Se revisa el plan de capacitacin de la organizacin, segn seaapropiado, para incorporar cambios.

o Los individuos afectados revisan el plan de capacitacin de laorganizacin cuando se produce por primera vez, y cuando se realizanrevisiones importantes.

o Se administra y controla el plan de entrenamiento de la organizacin.Ingenieria de Software 2006 U.N.C.P.B.A.



35/50


o Se pone el plan de entrenamiento de la organizacin a disposicin de losgrupos e individuos afectados.

- Se realiza la capacitacin de la organizacin de acuerdo con el plan decapacitacin de la misma. El plan cubre:

o El entrenamiento especfico necesario dentro de la organizacin ycundo es necesario.

o El entrenamiento que ser obtenido de fuentes externas y el que proveerel grupo de entrenamiento.

o Los fondos y recursos necesarios para preparar y llevar a cabo elentrenamiento (incluyendo personal, herramientas e instalaciones).

o Los estndares para los materiales de instruccin usados en los cursos deentrenamiento desarrollados por el grupo de entrenamiento.

o El cronograma para desarrollar y revisar los cursos de entrenamiento aser desarrollados.

o El cronograma para realizar la capacitacin, basado en las fechasnecesarias y en el nmero de estudiantes esperado.

o Los procedimientos para seleccionar las personas que recibirnentrenamiento, para registrarse y participar en las capacitaciones, parallevar registros de las capacitacione

CMM Informe

Documents

Transcript of CMM Informe