CMM (Capability Maturity Models)

Definiciones, Objetivos y Arquitectura, Nveles de Madurez Definiciones Nombre: Capability Maturity Model - CMM- for Software Autor(es): Watts Humphrey's, Mark Paulk, Bill Curtis, Mary Beth Chrissis, Edward Averill, Judy Bamberger, Tim Kasse, Mike Konrad, Jeff Perdue, Charlie Weber, and Jim Withey. Existe un conjunto de profesionales anexos que se encarga de revisar y proponer cambios al modelo. Instituto: Software Engineering Institute - SEI - y Carnegie Mellon University Versin Actual: 1.1 (10 Febrero 1993) Versin Prox. : 2.0 (2 semestre 1998, congelado por su posible integracin a CMMISM, aunque existe la versin 2.1 de 1999.) Origen: U.S.A. Historia: Los comienzos se remontan a noviembre de 1986 cuando el SEI, en conjunto con Mitre Corp., comenz a desarrollar un marco de referencia del proceso de maduracin del software, en repuesta a la solicitud federal y gubernamental de un mtodo para evaluar a las Empresas de software contratadas. (Empresas contratistas 3 Empresas). Fechas: - Versin 0.0 ( 1 marzo 1990), borrador de las tablas de las prcticas claves - Rough draft of the key practice tables-. - Versin 1.0 (15 Agosto 1991), primera versin borrador accesible al pblico en general. - Versin 1.1 (10 febrero 1993) versin final. - Borrador C de CMM Versin 2.0 (1997). Web Site: www.sei.cmu.edu Descripcin: CMM es un modelo para determinar la madurez de los procesos de software y de la Organizacin, y la identificacin de las prcticas claves requeridas para el mejoramiento e incremento de la madurez de los procesos. produccin de software de calidad, software que sea entregado, etc.

CMM (Capability Maturity Model)

Definiciones, Objetivos y Arquitectura, Nveles de Madurez Objetivos El modelo de potencial de madurez provee a las organizaciones de software una gua de cmo aumentar el control de sus procesos de desarrollo y mantenimiento de software. El CMM fue diseado para guiar a las organizaciones de software en la seleccin de estrategias para el mejoramiento de procesos mediante la determinacin de la madurez de los procesos actuales e identificando los elementos ms crticos de la calidad de software y del mejoramiento de procesos. Arquitectura del Modelo

La arquitectura del modelo esta compuesta por niveles que describen la madurez de la organizacin y por reas claves de procesos KPAs (Key Process Areas) como aparece en la pgina 'Niveles de Madurez'. Los diferentes niveles permiten medir la madurez del proceso y evaluar el potencial de l, como tambin ayudan a una organizacin a priorizar sus esfuerzos de mejoramiento. Estructura Interna de CMM

El modelo establece un marco de referencia comn para ejecutar la evaluacin de procesos y de la potencialidad o capacidad del software. La siguiente figura provee una breve descripcin de los pasos comunes de las evaluaciones.

CMM (Capability Maturity Models)

Definiciones, Objetivos y Arquitectura, Nveles de Madurez Nivel Madurez de Areas Claves de Proceso (KPA) Prevencin de defectos (identificacin de las causas de defectos y prevencin de ellos de reincidencia por medio de su anlisis y cambios en procesos definidos). 5 Optimizante Administracin de cambios tecnolgicos (identificacin de los beneficios de nuevas tecnologas {tales como herramientas, mtodos y procesos} y transferencia de ellos a la organizacin en un modo ordenado. Se trata de lograr innovacin permanente y eficiente). Administracin cuantitativa del proceso (control de la performance del proceso del proyecto en forma cuantitativa). Esto abarca el registro de los resultados actuales del seguimiento de un proceso de software. Debe enfocarse en la identificacin de causales especificas en la variacin de un proceso estable y 4 Administrado mensurable, tambin como proceder a corregir las circunstancias que crearon estas desviaciones. Administracin de la calidad de software (desarrollo de una comprensin cuantitativa de los productos del proyecto para lograr metas de calidad especificas). 3 Definido Enfoque a procesos organizacionales (establecimiento de responsabilidades organizacionales para las actividades, para

mejorar la capacidad completa del proceso de la Organizacin). Definicin de procesos organizacionales (desarrollo y mantencin de un conjunto til de activos de proceso que mejoran y pueden ser aplicados en todos los proyectos y, proveen una base para la definicin de datos significativos para la administracin del mismo en forma cuantitativa. Estos activos pueden ser institucionalizados a travs de, por ejemplo, capacitacin). Programas de capacitacin (desarrollo de habilidades y transferencia de conocimientos al personal para que sea eficiente y efectivo. La capacitacin es una responsabilidad de la organizacin, pero los proyectos deben identificar las habilidades requeridas, y proveer la capacitacin necesaria cuando sus necesidades son nicas). Administracin de software integrado (integracin de actividades de administracin con Ingeniera de Software. Es un proceso definido y coherente). Ingeniera de productos de software (ejecucin consistente de un proceso correctamente definido que integra todas las actividades tcnicas {anlisis de requerimientos, diseo, cdigo y prueba, entre otros} para producir productos de software consistentes y correctos en forma efectiva y eficiente). Coordinacin intergrupal (establecimiento de algn medio en que el equipo de ingeniera de software participe activamente con otros equipos de ingeniera {trabajo interdisciplinario} con el propsito de que el equipo completo del proyecto satisfaga en mejor forma los requerimientos del cliente). Revisiones entre pares (remocin de defectos de los productos temprana y eficientemente. Las revisiones de a pares es un mtodo efectivo e importante que puede implementarse, por ejemplo, a travs de inspecciones o walkthroughs estructurados). 2 Repetible Administracin de requerimientos (comprensin comn de los requerimientos del cliente/usuario entre ste y el equipo de trabajo del proyecto. Este acuerdo es la base efectiva para la planificacin y administracin de un proyecto). Planificacin del proyecto de software (establecimientos de planes razonables para la administracin e ingeniera de un proyecto. Estos planes son la base de la administracin del proyecto). Seguimiento y ajuste del proyecto de software (visin adecuada del progreso actual, para que la administracin tome acciones efectivas cuando la performance del proyecto se desve significativamente de los planes). Administracin de los subcontratos de software (seleccin de contratistas calificados y administracin efectiva de ellos). Aseguramiento de calidad de software (provisin a administracin de visin adecuada del proceso siendo usado y de la construccin de productos). Administracin de la configuracin del software (establecimiento y mantencin de la integridad de los productos

del proyecto, en todo su ciclo de vida). 1 Inicial No tiene.

IDEAL
Definiciones, Objetivos y Aplicacin Definiciones Nombre: IDEALSM A User's Guide for Software Process Improvement Autor: Bob McFeely Instituto: Software Engineering Institute - SEI y Carnegie Mellon University Versin Actual: 1.0 ( Febrero 1996 ) Origen: U.S.A Historia: Este modelo nace como sucesor del Software Process Improvement Roadmap, con colaboracin del SEI y de la compaa Hewlett-Packard. Web Site: www.sei.cmu.edu Descripcin: IDEAL ms que un modelo es una gua para el mejoramiento de procesos con una secuencia de pasos y administrativos para lograrlo Objetivos El objetivo del documento del Modelo IDEALSM (Initiating, Diagnosing, Establishing, Acting, Leveraging/Learning), es el de comunicar un camino de accin que constituye la iniciativa del mejoramiento de los procesos de software, basado en las experiencias del SEI con el departamento de gobierno y los clientes industriales. Descripcin del Modelo IDEAL En la figura siguiente, se observa las 5 fases que contiene el modelo con los pasos cclicos necesarios hacia el mejoramiento de los procesos de software. El tiempo que se demore una organizacin o empresa en completar el ciclo del modelo IDEAL esta sujeto a las caractersticas estructurales, de madurez, etc., presentes en l.

Aplicacin del Modelo Cuando aplicamos el modelo se debe recordar que hay dos componentes dentro de las actividades del mejoramiento de proceso de software: Un componente Estratgico, junto con un componente Tctico. El componente estratgico, basado en las necesidades y conducciones de negocio, proveer una gua y una priorizacin de las actividades tcticas. En la siguiente figura, se muestra una vista bidimensional de la aplicacin del modelo IDEALSM. Esta gua pretende direccionar estos dos niveles operacionales dentro de la iniciativa de mejora de los procesos: Un nivel estratgico, en el que se encuentran los procesos responsabilidades del senior management. Un nivel tctico, en el que los procesos son modificados, creados y ejecutados por la lnea de gerentes, administradores, y practicantes.

ISO 9001
Generalidades, Detalles ISO 9000, Norma ISO 9001, Clusulas de la gua ISO 9000-3, Cambios ISO para el 2000, Transicin de la Norma, Fallas de ISO 9000 Generalidades Autor(es): Muchas personas y organizaciones han contribuido con la creacin de estas normas. Instituto u Organizacin: Organizacin de Estndares Internacionales - ISO Versin Actual: ISO 9001:2000. Existe la versin ISO 9000 CD2. El lanzamiento de esta norma fue el cuarto trimestre del 2000. Origen: Difcil de determinar. Hubo representantes involucrados de varios pases sobre todo de Europa y U.S.A. La primera reunin para proponer las ISO 9000 fue en Ottawa, Canad en 1980. Historia: La ISO public en 1987 un conjunto de 5 normas relacionadas con la implementacin de sistemas de aseguramiento de la calidad. Se tardaron 7 aos en elaborar las normas. Fechas Ver. 1.0 (1987) ISO 9000:1987. Ver. 2.0 (1994) o ISO 9000:1994. Ver. 3.0(2000) ISO 9000:2000. WebSite: http://www.iso.ch Descripcin: La ISO 9001 tiene un fuerte nfasis en el control de calidad tradicional. Todas las operaciones que influyen en la calidad debern estar bajo control y todos estos controles debern ser visibles. La ISO 9000-3 es una gua de como interpretar e implementar la ISO 9001.

Detalles ISO 9000 La Organizacin Internacional de Normalizacin (ISO) public en 1987 la serie de normas ISO 9000, como un conjunto de cinco normas relacionadas con la aplicacin de sistemas de aseguramiento de la calidad. Las normas fueron escritas por el Comit Tcnico 176 de ISO, cuya primera reunin se celebr en Ottawa, Canad en 1980. Siete aos despus, se formul la serie de documentos: Normas con Certificacin: * 9001 * 9002 * 9003 * Proveen del modelo para el aseguramiento de la calidad Guas para la seleccin y aplicacin de las normas certificadora: * 9000-1 * 9000-2 * 9000-3

9000-4

Guas de gestin de la calidad: * 9004-1 * 9004-2 * 9004-3 * 9004-4 Actualmente, la familia ISO 9000 est compuesta por dieciocho normas y ms de 90 pases las han aceptado y traducido oficialmente.

Norma ISO 9001 - Elementos de Calidad El estndar ISO 9001:1994 define elementos de calidad que estn presentes en un sistema (no confundir con sistema en el estricto mbito informtico) estructurado en 20 elementos principales. La tabla nos muestra los elementos de calidad de la norma ISO 9001, con su respectiva relacin con las clusulas de la gua 9000-3. La norma ISO 9001(2000) sustituir las revisiones actuales de 1994 en ISO 9002 e ISO 9003, o sea, slo existir la ISO 9001(2000)

ISO 9001Elementos Descripcin 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 Responsabilidad Gerencial Sistema de Calidad Revisin del Contrato Control del Diseo

ISO 9000-3 Clusulas 4.1 4.2, 5.5 5.2, 5.3 5.3, 5.4, 5.5, 5.6, 5.7, 6.1

Control de Documentos y 6.1, 6.2 Datos Compras 6.7 Control del Producto 6.8 Suministrado por el Cliente Identificacin y Trazabilidad 6.1 del Producto Control del Proceso Inspeccin y Ensayo Control del Equipo Inspeccin, Medicin Ensayo Estado Ensayo de Inspeccin Producto 5.6, 6.5, 6.6 5.7, 5.8, 5.9 de y 5.7, 6.5, 6.6 y Noy 6.1 5.6, 5.7, 5.9, 6.1 4.4

Control del Conforme

Acciones Correctivas Preventivas Manejo, Embalaje, Entrega

Almacenamiento, Preservacin y 5.8, 5.9

4.16 4.17 4.18 4.19 4.20

Control Calidad

de

Registros Internas

de de

6.3 4.3 6.9 5.1 6.4

Auditoras Calidad Capacitacin

Servicio Post-Venta Tcnicas Estadsticas

Las Clusulas ISO 9000-3 y su relacin con los elementos de la ISO 9001:1994. Los nmeros que aparecen en los elementos y clusulas son referidas: primer nmero al prrafo correspondiente y el segundo nmero al elemento o clusula. Clusulas de la gua ISO 9000-3 La tabla nos muestra las clusulas de la gua ISO 9000-3, con su respectiva relacin con los elementos de la norma ISO 9001:1994. ISO 9000-3 Descripcin Clusulas 4. Requisitos del Sistema de Calidad 4.1 4.2 4.3 4.4 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 Responsabilidad Gerencial Sistema de Calidad Auditoras Calidad Internas al Sistema de 4.1 4.2 4.17 4.14 ISO 9001 Elementos

Acciones Correctivas Generalidades Revisin del Contrato Especificacin Comprador de Requerimientos del

5. Sistema de Calidad - Actividades del Ciclo de Vida 4.3 4.3, 4.4 4.4 4.2, 4.4 4.4, 4.9, 4.13 4.4, 4.10, 4.13 4.10, 4.15 4.10, 4.13, 4.15 4.13, 4.19 4.11,

Planificacin del Desarrollo Planificacin de la Calidad Diseo e Implementacin Pruebas y Validacin Aceptacin Replicacin, Entrega e Instalacin Mantenimiento

6. Sistema de Calidad - Actividades de Soporte

6.1 6.2 6.3 6.4 6.5 6.6

Administracin de la configuracin Control de Documentos Registros de Calidad Metricas Reglas, Prcticas y Convecines Herramientas y Tcnicas

4.4, 4.5, 4.8, 4.12, 4.13 4.5 4.6 4.20 4.9, 4.11 4.9, 4.11

6.7

Compras

4.6

6.8
6.9

Producto de Software Includo

Capacitacin

4.7
4.18

Las Clusulas ISO 9000-3 y su relacin con los elementos de la ISO

9001:1994. Los nmeros que aparecen en los elementos y clusulas son referidas: primer nmero al prrafo correspondiente y el segundo nmero al elemento o clusula.

Generalidades Cambios ms relevantes respecto a la Norma del 1994: 1. La estructura de ISO 9001 revisada ser ms genrica que la estructura actual y adoptar el acercamiento de la gerencia a los procesos; adems la nueva estructura ser consistente con el ciclo de mejora del Plan-Do-Check-Act usado en los estndares de la ISO 14000 en sistemas de gerencia ambientales). 2. Las actividades de diseo no slo se extienden al producto, sino tambin al servicio y al proceso. 3. Deben identificarse todos los procesos de la Empresa, incluidos los procesos de informacin. 4. La gestin de recursos los clasifica en : Recursos Humanos, de informacin y de infraestructuras. 5. En la planificacin de la calidad, se hace un intento de orientacin hacia una planificacin avanzada de la calidad-documentar en formato que permita seguir la prctica operativa. 6. Se establece mtodos de comunicacin con el Cliente y se incorpora la Evaluacin de la Satisfaccin del Cliente como dato significativo. 7. Se debern demostrar conocimiento, destinar recursos e implantar actividades de Mejora Contnua. 8. Se establecen requisitos sobre el entorno de trabajo desde el punto de vista de aspectos humanos y fsicos cuando afectan a la calidad, incluyendo cualificacin. 9. Se moderniza el lxico (se habla de Empresa en lugar de "Suministrador").Se habla de productos y servicios, es decir se orienta al sector servicios y no slo a produccin. 10. Los 20 elementos en la ISO 9001 actuales sern claramente identificables en la nueva estructura adoptada por la revisin del 2000, los ttulos principales de la clusula sern: Responsabilidad gerencial (poltica, objetivos, planes de calidad, sistema de calidad, revisin por la gerencia). Administracin del recurso (recursos humanos, informacin, habilidades).

Gerencia de proceso (satisfaccin de cliente, diseo, compras, produccin). Medicin, anlisis y mejoramiento (auditoras, control de proceso, mejoramiento continuo). 11. La ISO 9001 que presentada en el ao 2000 no especifica requisitos en la disposicin o la estructura de la documentacin del sistema de calidad de una organizacin (ej. no impone ninguna regla ante la presentacin de un manual de la calidad); esto permitir que las organizaciones continen documentando sus sistemas de calidad de una manera que refleje sus propias formas de hacer negocio. La revisin de los estndares de la ISO 9000 no requerir reescribir la documentacin del sistema de calidad de la organizacin; sin embargo es recomendable, para efectos de cumplimiento con los estndares de la norma y de facilidad y agilidad en dicho proceso, el uso de herramientas que faciliten el manejo de la documentacin y de algunos procesos que afectan la calidad.

Fallas CDesde hace mas de una dcada se ha venido escuchando sobre la conveniencia y efectividad en el uso de los estndares de calidad ISO-9000. Se sabe que existen varias decenas de miles de organizaciones que han recibido la certificacin oficial por parte de los organismos acreditados, o registradores, como reconocimiento por haber adoptado un Sistema de Aseguramiento de Calidad y de estar trabajando bajo las reglas en l descritas. Se sabe tambin que no todas las empresas que han recibido dicha certificacin estn satisfechas con los resultados y que otra buena cantidad de compaas que haban iniciado el proceso, se quedaron a medio camino. Qu es lo que ha sucedido?

En primera instancia, ha habido desinformacin y en segunda, ha habido mala informacin. Muchos empresarios han credo -o se les ha hecho creer- que los estndares ISO 9000 son una solucin mgica, que por s mismos resuelven los problemas, por lo que su adopcin es todo maravillas y felicidad. Grave error. No se les inform oportunamente que antes que nada, se requiere dedicacin, trabajo y esfuerzo. Quienes han transitado por ese camino arduo y en ocasiones hostil, sabemos que para iniciar el proceso de instauracin de un Sistema de Calidad, es necesario conjuntar una serie de factores: - Buena salud de la compaa - Sentido comn - Impulso a los valores humanos - Ingenio, iniciativa y creatividad - Prcticas operativas probadas y aprobadas - Elevado nivel tecnolgico - Bsqueda de la vanguardia - Disposicin al cambio - Conviccin acerca de los principios elementales de la calidad - Deseos de servir, complacer y satisfacer al cliente - Pero sobre todo, el compromiso firme y decidido por parte de la directiva

SPICE
Introduccin, Componentes, Para qu Sirve, Descripcin del Modelo, Categora de los Procesos, Arquitectura, Uso del Modelo , Organizacin, Estrategias Trial, Hitos de SPICE Y CMM, Resultado de Cada Fase, Referencias Introduccin En Enero de 1993 un programa de trabajo fue aprobado por la ISO/IEC JTC1 para el desarrollo de un estndar internacional para la evaluacin de los procesos de software. En junio de 1993 fue establecida la organizacin del proyecto SPICE con mandato del JTC1/SC7. El proyecto SPICE termino la elaboracin del futuro estndar en junio de 1995, en la cual, sali a la luz publica una versin preliminar (borrador) del documento, este hito se llama Fase 1. El documento consta de las siguientes partes: Parte 1: Conceptos y gua de introduccin (Concepts and introductory Guide) Parte 2: Un modelo para la administracin de procesos (A model for process management) Parte 3: Rating de los procesos (Rating process)

Parte 4: Gua para conducir las evaluaciones (Guide to conducting assesment) Parte 5: Construccin, seleccin y uso de las herramientas e instrumentos de evaluacin (Construction, selection and use of assesment instrument and tools) Parte 6: Cualificacin y entrenamiento de los asesores (Qualification and training of assessors) Parte 7: Gua para usarse en el mejoramiento de los procesos (Guide for use in process improvement) Parte 8: Gua para usarse en la determinacin capacidad de procesos de terceros (Guide for use in determining supplier processs capability) Parte 9: Vocabulario (Vocabulary)

La Fase 2, que se inicio a principios de 1996, consiste en invitar a las organizaciones a utilizar y aplicar SPICE para poder validar y determinar qu resultados obtuvieron con el fin de mejorar el modelo para su publicacin final. La Fase 3, se inici a finales de 1999 y seguir hasta el lanzamiento del modelo.

Componentes del futuro estndar internacional

Para qu Sirve Debido a la alta competencia del mercado de desarrollo de software, a la difcil tarea de identificar los riesgos, cumplir con el calendario, controlar los costos y mejorar la eficiencia y calidad se cre SPICE. Este engloba un modelo de referencia para los procesos y sus potencialidades sobre la base de la experiencia de compaas grandes, medianas y pequeas. SPICE provee: Un marco de referencia para determinar las fortalezas y debilidades de los procesos; Un marco de referencia para mejorar los procesos de software, y medir sus mejoras; Un marco de referencia para los que adquieren un sistema para evaluar la capacidad de los proveedores de sistemas; Un marco de referencia para determinar los riesgos de negocio para una empresa que considera desarrollar un nuevo producto de software o servicio. Una ruta para la armonizacin o migracin de los modelos de evaluacin de procesos con referencia al modelo de procesos y capacidad. La organizacin o unidad informtica puede utilizar SPICE para los siguientes casos: o Modo de nivel de capacidad o potencialidad. Le permite a una organizacin adquiriente determinar el nivel de capacidad de una empresa que le suministra un sistema de software.

o Modo de mejoramiento de procesos. Para ayudar a una organizacin a mejorar su propio departamento de desarrollo de software y los procesos de mantenimiento. o Modo auto-evaluacin. Para ayudar a una organizacin determinar su habilidad de implementar un nuevo proyecto de software Descripcin del Modelo SPICE El modelo describe los procesos que una organizacin puede ejecutar, adquirir, suplir, desarrollar, operar, evolucionar, brindar soporte de software y todas las practicas genricas que caracterizan las potencialidades de estos procesos. La arquitectura del modelo organiza las prcticas en nmeros de categoras usando diferentes tipos de aproximaciones. La arquitectura distingue entre: Prcticas base, son las actividades esenciales de un proceso especifico, agrupado por categoras de procedimientos y procesos de acuerdo al tipo de actividad que direccionan. Prcticas genricas, aplicables a cualquier proceso, que representa las actividades necesarias para administrar el "proceso" y mejorar su potencialidad. El modelo agrupa a los procesos en cinco categoras: Procesos Cliente - Proveedor (Customer - Supplier) esta categora consiste en los procesos que directamente impactan al cliente, al soporte de desarrollo y a la transicin del software al cliente.

1.

Procesos de Ingeniera (Engineering) esta categora consiste, a los procesos que directamente especifican, implementa, y mantienen un sistema, un producto de software y la documentacin del usuario.

2.

3. Procesos de Proyecto (Project) esta categora consiste en los procesos establecidos dentro del proyecto, coordinacin y administracin de los recursos para producir un producto o proveer un servicio para satisfacer al cliente. 4. Procesos de Soporte (Support) esta categora consiste en los procedimientos que establecen y soportan el desempeo de los otros procesos del proyecto. 5. Procesos de la Organizacin (Organization) esta categora consiste en los procesos que establecen las metas de negocio de la organizacin, los procesos de desarrollo y recursos que ayudan a la organizacin alcanzar dichas metas.

La categora de proceso "Cliente-Proveedor" consiste en los procesos que estn ms cerca al cliente. "Ingeniera" consiste en los procesos que construye el producto que es entregado al cliente. El "proyecto" consiste en los procesos que administra el desarrollo de los productos. "Soporte" brinda apoyo a las otras categoras de procesos. Finalmente la categora "Organizacional" son los procesos que construye la infraestructura organizacional sobre la cual cada uno de los procesos descriptos pueden potencialmente ser ejecutados y maximizar los beneficios para la organizacin. Las categoras de procesos estn relacionadas y cada categora es una capa que precede a la otra, como se indica en la figura. Cada proceso en el modelo es descripto en trminos de prcticas de base, cada una son actividades nicas de ingeniera de software o de administracin. Categora de los Procesos, procedimientos y las prcticas de base estn agrupados por tipo de actividad. Los procedimientos y las actividades caracterizan la performance de los procesos, aun cuando la performance no es sistemtica. La performance de la prctica base pueden ser informales (ad hoc), impredecibles, inconsistentes, pobremente planeado, y/o su resultado es un producto de baja calidad. La aplicacin solamente de las prcticas base en los procesos pueden tener un valor mnimo y representar solamente el primer paso en la construccin de la capacidad de los procesos. La evolucin de la capacidad de los procesos (capability process) esta expresado en trminos de niveles de capacidad, caractersticas comunes, y prcticas genricas. Un nivel de capacidad es un conjunto de actividades que trabajan juntas para proveer una mejor ejecucin de los procesos. Cada nivel provee una mejor y ms compleja ejecucin de los procesos que el nivel predecesor. Los niveles de capacidad proveen dos beneficios: El conocimiento de los procesos esto depender del monto de la prctica y la ayuda a la organizacin de identificar qu "mejora" se debe ejecutar primero, basado en una secuencia racional de aplicacin de los procesos.

Existen seis niveles de capacidad en el modelo: Nivel 0; No Realizado: Es un fracaso general el tratar de utilizar las prcticas bases a los procesos. Ya que no es fcil identificar las salidas de los procesos o el trabajo de los productos. Nivel 1; Realizado Informalmente: Las prcticas bases de los procesos generalmente son ejecutados. La ejecucin de dichas prcticas puede no ser rigurosamente planificadas y seguidas. La ejecucin de las prcticas depender del conocimiento y esfuerzo personal. Se identifica algunos procesos. Nivel 2; Planificado y Seguido: La ejecucin de las prcticas bases en los procesos son planificadas y seguidas. La performance estar acorde con los procedimientos especificados. La primera distincin entre el nivel 1 y el 2 es que la ejecucin de los procesos est planificada y administrada y progresan hacia un proceso bien definido. Nivel 3; Bien Definido: Las prcticas bases son ejecutadas de acuerdo a una versin adaptada del estndar, procesos aprobados bien definidos y documentados. Nivel 4; Cuantitativamente Controlado: Mediciones detalladas de la performance o ejecucin son recabadas y evaluadas. Es conocida en forma cuantitativa la performance de los procesos y es posible su prediccin. Las prcticas son objetivamente administradas. La calidad de las mismas es cuantitativamente conocida. Nivel 5; Mejoramiento Continuo: Son establecidos en forma cuantitativa procesos y metas eficientes, basados en los objetivos de la organizacin. En forma continua los procesos se van mejorando mediante la retroalimentacin (feedback) obtenido por los resultados de procesos definidos y por ideas pilotos y tecnologas novedosas.

La arquitectura del modelo, que se muestra en la figura, contiene dos jerarquas. La jerarqua de la izquierda consiste en la categora de proceso, que estn compuestos por procesos, y estos a su vez en prcticas de base. Esta es una descomposicin por tipo de actividad. Los procesos estn ponderados de acuerdo a la jerarqua del lado derecho de la figura. Los procesos estn catalogados en niveles de capacidad, los niveles de capacidad estn compuestos en caractersticas comunes (excepto nivel 0); y estos en prcticas genricas.

Uso del Modelo La siguiente tabla muestra la audiencia principal a la que esta dirigido este futuro estndar internacional, por qu cada grupo necesita el modelo, cmo y cundo debe ser usado. Quin Por qu Cmo Cundo

Como gua de trabajo en la gestin de los procesos e aplicacin de las actividades del Comprender qu proyecto de hay que hacer software. para mejorar los procesos de Como gua de software. referencia para Organizacin de destacar los Software Comprender procesos y cules procesos y consideraciones prcticas un prcticas. asesor puede evaluar. Como un documento de entrenamiento.

Durante la aplicacin de los procesos de software de la organizacin. Durante el desarrollo/ revisin de los procesos de software de la organizacin y como parte de una actividad de mejoramiento continuo. Idem

Antes de las Como una prctica evaluaciones de lista de chequeo (checklist) Asesores de los Determinar cmo Como una prctica Antes y durante procesos de una organizacin de lista de chequeo una evaluacin de software gestiona y procesos de

administra los procesos de software y sus resultados.

(checklist)

software Antes de una evaluacin o programa de evaluacin

Referencia con el propsito de Establecer realizar compatibilidad de compatibilidad con las evaluaciones el modelo del modelo Al desarrollarNecesidad Desarrolladores herramientas deherramientas de herramientas evaluacin evaluacin

Antes y durante el de desarrollo de de herramientas de evaluacin

EL MARCO DE TRABAJO: ORGANIZACIN SPICE:

Coordinadores de SPICE:

Funciones:

- Identificar las limitaciones para priorizarlos (corregirlos) antes de la estandarizacin, enfocado en: o o o Alcance Aplicabilidad Funcionalidad

- Para buscar la evidencia sobre las evaluaciones de SPICE, son repetible y comparable - Para comenzar la coleccin de datos con respecto a los beneficios, que son el resultado del uso de SPICE - Para buscar la evidencia sobre las evaluaciones de SPICE, son repetible y comparable - Para comenzar la coleccin de datos con respecto a los beneficios, que son el resultado del uso de SPICE

ESTRATEGIA TRIALS Fase 1: Decisiones de diseo y usabilidad del producto Enero - Septiembre 1995 Fase 2: Prueba de la implementacin de SPICE y la integracin del producto ISO/IEC PDTR 15504 (SPICE vers 2.0). Septiembre 1996 - Abril 1998 v Phase 3: Validacin de SPICE Caracterizar y entender el modo en que las evaluaciones basadas en ISO 15504 est dirigindose, y por quin. Proporcionar no-benchmarking comercial a los participantes en los ensayos. Documentar los costos y beneficios de las evaluaciones basado en ISO 15504 . Recabar los problemas experimentados durante las evaluaciones. Diseminacin capacidades. de las evaluaciones, mejoras y determinacin de las

Hasta Enero 2000, existe expresiones de interes para participar en la fase 3: - Canada & Latin America 40 - Europe & South Africa 82 - Northern Asia Pacific 15 - Southern Asia Pacific 26

- USA 94 - TOTAL 257

HITOS DE SPICE Y CMM

RESULTADO DE CADA FASE

Fase 1: Se realizaron 28 trial assessment. 18 en Europa. Se report y analiz 238 problemas. El problema ms comn fue "poca claridad de los procesos y y descripcin de las prcticas".

 Puede medir la evolucin de un proceso separadamente de otros procesos. Brinda una visin ms "granular", pudiendo realizar mejoras de procesos ms direccionales. La arquitectura BPG de SPICE es difcil determinar, no indica qu salida o proceso trabajar primero. No esta fuertemente ligado al modelo ISO 12207 Modelo complejo. Exista un nmero alto de decisiones para ponderar los procesos. Hay 35 procesos con 200 prcticas bases y 26 prcticas genricas; el nmero total de ratings(ponderaciones) individuales por una evaluacin completa ronda en 1000 juicios individuales. El camino para reconocer otros modelos y frameworks era muy restringido. El 40% de los encuestados de la Fase I dijo que sus evaluaciones fueron "ms del valor del gasto" El 85% de los evaluadores caracteriza SPICE como al menos un poco mejor que otros mtodos de evaluacin. Menos del 25% de todas las respuestas son del tipo de respuesta como "muy apoyado" por el documento SPICE. Cerca del 30% de los evaluadores y casi 40% de los patrocinadores dijeron que el resultado de la evaluacin depende sobre la habilidad y juicio de los equipos evaluadores. Tiempo consumido por Instancia de Proceso fue de 8,52 (asesores) a 10,11 horas-personas (evaluadores).

Fase 2: Se realizaron 70 trial assessment:

Se recolecto ms datos, incluidos: Caracterstica de trial, equipo, de la unidad organizacional,de los proyectos, etc. La media del costo de las evaluaciones de las instancia de procesos fue U$ 833. (No incluye el esfuerzo de completar los cuestionarios.) Phase 3: No ha concluido. Ningn informe preliminar..... HASTA EL MOMENTO

TRILLIUM
Definiciones, Arquitectura, Escala, Road Map Nombre: Trillium Model ( Model for Telecom Product Development & Support Process Capability ) Autores: Franois Coallier, Richard McKenzie, John F. Wilson, Joe Haltz, existen otros colaboradores. Empresas: Bell Canada, Northern Telecom y Bell Northern Research. Versin Actual: 3.2 ( Mayo, 1996) Prxima Versin: Anunciada, sin fecha prefijada. Origen: Canad. Historia: Trillium surgi como una iniciativa de crear un modelo de madurez y con secuencias de mejoramiento por madurez, pero orientado al entorno de telecomunicaciones. Fechas Ver. 1.0 ( Agosto 1991) Borrador del modelo no accesible al publico. Ver. 2.0 (Febrero 1992) Borrador del modelo y 1 edicin con el nombre Trillium. Ver. 2.2 ( Julio 1992) Borrador, modelo distribuido ampliamente. Ver. 3.0 ( Diciembre 1994) Modelo final, cubre 100% las practicas de CMM ver. 1.1. Web Site: Http://ricis.cl.uh.edu/trillium/trillium.html (inactivo) Descripcin: El objetivo del modelo Trillium es el de proveer una pauta para el inicio y gua continua de un programa de mejoramiento. Provee orientacin hacia el cliente y seleccin de empresas contratistas. Posee una fuerte orientacin al rea de las Telecomunicaciones. Objetivos: Trillium ha sido desarrollado desde una perspectiva del cliente, percibido en un ambiente competitivo y comercial.

El modelo Trillium consiste en Areas de Capacidad, Roadmaps y Prcticas.

La escala de los niveles va del 1 al 5. Los cuales estn caracterizado de la siguiente manera: 1. No estructurado (Unstructured): Los procesos de desarrollo se realizan de forma Adhoc. Los proyectos frecuentemente no cumplen con la calidad y el calendario. Se cumple con el proyecto basado en el esfuerzo personal que por la infraestructura organizacional. (Riesgo Alto). 2. Repetible y orientado al proyecto (Repeteable and Project Oriented): Todos los sucesos presentes en el proyecto son documentados y archivado gracias a una fuerte gestin de planificacin y control, con nfasis en la administracin de los requerimientos, tcnicas de estimacin, y administracin de la configuracin. (Riesgo - Medio) 3. Definido y orientado al proceso (Defined and Process Oriented): Los procesos son definidos y utilizados en el mbito organizacional, aunque an la customizacin del proyecto es permitido. Los procesos son controlados y mejorados. Son incorporados los requerimientos de la ISO 9001 sobre entrenamiento y auditoria interna de los procesos. (Riesgo - Bajo) 4. Administrado e Integrado (Managed and Integrated): Anlisis e instrumentacin de los procesos son usados como mecanismo clave para el mejoramiento de los procesos. Son administrados los procesos cambios y los planes de prevencin de defectos son integrados en los procesos. Las herramientas CASE son integradas a los procesos. (Riesgo - muy Bajo).

5. Plenamente Integrado (Fully Integrated): Extensivamente son utilizadas metodologas formales Repositorios organizacionales para la documentacin/evolucin histrica y los procesos son utilizados y efectivizados. (Riesgo - Bajsimo) Extensivamente son utilizadas metodologas formales Repositorios organizacionales para la documentacin/evolucin histrica y los procesos son utilizados y efectivizados. (Riesgo - Bajsimo)

ROAD MAPE
Areas De Potencialidad Organizational Process Quality ROADMAPS Nmero De Prcticas Por Nivel 2 3 4 5 10 20 5 0 Total

Quality Management Business Process Engineering Human Resource Human Resource Development and Development and Management Management Process Definition Technology Management Process Process Improvement & Engineering Measurements Project Management Subcontractor Management Management Customer-Supplier Relationship Requirements Management Estimation Quality System Quality System Development Process Development Techniques Internal Development Documentation Practices Verification & Validation Configuration Management ReUse Reliabilty Management Development Development Environment Environment

35

42

52

10

55

24

99

74

29

107

14

15

33

41

49

15

110

12

Problem Response System Usability Engineering LifeCycle Cost Customer Support Modelling User Documentation Customer Engineering User Training TOTAL

25

30

60

193 246

57

12

508