cmm y la calidad en el desarrollo de software

www.innevo.comwww.innevo.com

CMM y la Calidad en el Desarrollo de Software

Versión 2.030819

www.innevo.comwww.innevo.com CMM 02 – CMM y la calidad en el desarrollo de software

Objetivo de la Capacitación

Obtener conocimiento general del modelo de capacidad y madurez denominado SW-CMM para:

• facilitar el inicio de un camino de mejora organizacional

• comprender la estructura del modelo

• tomar conciencia del esfuerzo que se requiere para implementarlo


Agenda de la Capacitación

¿Qué es la calidad?

Atributos para medir la calidad

Introducción a CMM

Comparación entre esquemas existentes

Descripción de las Áreas Clave de CMM

Ejemplos


¿Qué es la calidad?

Todos los aspectos y características de un producto o servicio que se relacionan con su

habilidad de alcanzar las necesidades manifiestas o implícitas


La calidad es un concepto complejo y multifacético que puede describirse desde cinco perspectivas...

Visión De Manufactura

Visión Del Usuario

Visión Trascendental

Visión Del Producto

Visión Basada en el

valor


Algo que puede ser reconocido pero no definido....Para el software se trataría de un ideal que nunca puede implementarse completamente

Visión Del Usuario





valor


La calidad se adecua a un propósito....Evalúa al producto en un contexto de trabajo y puede ser altamente personalizado


Visión Del Usuario




valor


Calidad como conformidad con una especificación...Foco en la calidad del producto durante el proceso de producción y después de liberado


Visión Del Usuario




valor


Calidad atada a características del productoConsidera características inherentes al producto, mide la calidad midiendo cualidades internas

Visión Del Usuario





valor


Depende del monto que esté dispuesto a pagar el cliente...Ataca el problema del equilibrio entre diseño y costos


Visión Del Usuario




valor


¿Por qué ocuparse de la calidad?Es un aspecto competitivoEs esencial para sobrevivirEs indispensable para el mercado internacionalEquilibrio costo-efectividadRetiene clientes e incrementa beneficiosEs el sello de clase en el mundo de los negocios


Mejora de calidad

Cadena de Reacción de DemingMejora de

calidadMejora de

ProductividadMejora de

ProductividadReducción de CostosReducción de Costos

Reducción de PreciosReducción de Precios

Incremento de MercadoIncremento de Mercado

Crecimiento en los

Negocios

Crecimiento en los

Negocios Excepcional Retorno de Inversión

Excepcional Retorno de Inversión


Control de Calidad

El control de calidad es una serie de inspecciones, revisiones y pruebas, utilizadas a lo largo del ciclo de desarrollo, para asegurar

que cada producto cumpla con los requerimientos que le han sido asignados.

Se controla CALIDAD DE PROCESO y CALIDAD DE PRODUCTO SOFTWARE


¿Cómo se mide la Calidad?

La calidad se mide de manera indirecta, nos concentramos en ciertos atributos y en como medirlos.

Para medirla la calidad existen diferentes Modelos: Boehm, McCall, ISO, Barbacci/SEI.


ISO 9126 (1991)

Características de la calidad del softwareFuncionalidadConfiabilidadUsabilidadEficienciaMantenibilidadPortabilidad


FuncionalidadConjunto de atributos que se relacionan con la existencia de un conjunto de funciones y sus propiedades específicas

AdaptabilidadExactitudInteroperabilidadConformidad (compliance) Seguridad

FuncionalidadConfiabilidad

UsabilidadEficiencia

MantenibilidadPortabilidad


ConfiabilidadConjunto de atributos relacionados con la capacidad del software de mantener su nivel de comportamiento bajo las condiciones establecidas y por un período de tiempo dado

MadurezTolerancia a fallas





UsabilidadConjunto de atributos referidos al esfuerzo necesario para el uso y la evaluación individual de tal uso, de un producto de software por conjunto establecido o implícito de usuarios

InteligibilidadFacilidad de aprendizajeOperabilidad





EficienciaConjunto de atributos referidos a la relación entre el nivel de comportamiento de software y la cantidad de recursos utilizados, en condiciones establecidas

Comportamiento temporalUtilización de recursos





MantenibilidadConjunto de atributos referidos al esfuerzo necesario para realizar modificaciones especificadas

Facilidad de análisisFacilidad de cambiosEstabilidadVerificabilidad





PortabilidadConjunto de atributos referidos a la capacidad de un producto de software de ser transferido de un ambiente a otro

AdaptabilidadFacilidades de instalaciónConformidad (conformance)Facilidad de reemplazo





Local (único atributo) óptimo

Global (múltiple atributo) óptimo

PerformancePerformance

ConfiabilidadConfiabilidad

Equilibrio entre los Atributos de Calidad del Software

SeguridadSeguridad


Aseguramiento de Calidad

El aseguramiento de calidad consiste en la auditoria y la función de información de la

gestión, si los datos identifican problemas, es responsabilidad de la gestión afrontarlos y

resolverlos.


Aseguramiento de Calidad de Software

Los requerimientos del software son la base de la medida de la calidad.

Los estándares especificados definen un conjunto de criterios que se deben seguir.

Existen requisitos implícitos a los que debe ajustarse.


Aseguramiento de Calidad de Software: Actividades

Establecer Plan de Calidad

Participar en la definición del Proceso de Desarrollo.

Revisión de las actividades de Ingeniería de Software.

Auditoria de los Productos de Software

Documentar e informar desviaciones según

procedimientos establecidos.


Costos de la Calidad

Incluye los costos asociados en la búsqueda y obtención de la calidad, pueden dividirse en costos asociados con:

La prevención

La evaluación

Los fallos


Costos de la Calidad: Costos de Prevención

Planificación de la Calidad

Revisiones Técnicas Formales

Equipo de Pruebas

Formación


Costos de la Calidad: Costos de Evaluación

Inspección en el proceso y entre procesos

Calibrado y mantenimiento del equipo

Pruebas


Costos de la Calidad: Costos de Fallas Internos

Revisión

Reparación

Análisis de las Modalidades de fallos


Costos de la Calidad: Costos de Fallas Externas

Resolución de Quejas

Devolución y Sustitución de Productos

Soporte de ayuda en línea

Trabajo en Garantía


Costo de no tener calidad

Del usuario:Mayor costo de administración

No poder hacer ciertas cosas

No poder llegar a tiempo al mercado

Perder imagen con el cliente

No poder confiar en la herramienta

De sistemasMayores costos

Mantenimiento fuera de hora

Siempre ‘corregir’, nunca cosas nuevas

Estar sobrecargado

No poder cumplir plazos

Recibir quejas del usuario

Perder credibilidad


Costo de detección de errores


Economía de la Calidad

• Un producto de más calidad– tiene menos errores– tardo menos en hacer que funcione.

• Tiene menos fallas– tardo menos en arreglarlo.

• El usuario está más contento, se dedica menos– tiempo y esfuerzo.

• Cuesta menos y tardo menos.

Recuerde que un proyecto ‘normal’ tiene más del43% del esfuerzo gastado en retrabajo.


¿Qué es un Sistema de Calidad?

Es el conjunto de cosas que la administración incorpora para asegurar y demostrar la calidad

del producto de software y de sus servicios asociados.

Es el proceso de trabajo completo, incluyendo políticas, procedimientos, herramientas y

recursos, humanos y tecnológicos.


Relación CMM – Proceso de DesarrolloEstándaresEstándares

Definiciones operacionales o criterios de aceptación para productos finales o

intermedios

PolíticaPolíticaLeyes y Regulaciones que gobiernan o

restringen operaciones

ProcesoProcesoDescribe que ocurre con la organización para construir productos que cumplen

estándares en concordancia con políticas de la organización.

Restringen el procesoRestringen el proceso

Es implementado porEs implementado por

ProcedimientosProcedimientosDescriben “cómo”; instrucciones “paso por paso” que implementen el proceso

CapacitaciónCapacitaciónConocimiento / habilidades requeridas

para usar un procedimiento

HerramientasSoporte automatizado necesario

para implementar los procedimientos

HerramientasHerramientasSoporte automatizado necesario

para implementar los procedimientos

Soportado porSoportado por


Esquemas Existentes...

ISO

SPICE

CMM


¿Qué es el CMM?

Es un esquema que representa un caminode mejoramientos, permite determinar la

madurez y evaluar las capacidades de las organizaciones que desarrollan software, recomendado para organizaciones que quieren incrementar la capacidad de su

proceso de desarrollo


Organizaciones Inmaduras

Los procesos de software generalmente son improvisados durante el curso del proyecto.

Aún si existe un proceso de desarrollo de software, no es rigurosamente aplicado.

Es reaccionaria y los administradores usualmente se concentran en resolver crisis (apagar incendios).

Planificaciones y presupuestos son excedidos debido a que no se basan en estimaciones realistas.

No hay bases para juzgar la calidad del producto.


Organizaciones Maduras

Poseen la habilidad para administrar los procesos de desarrollo y mantenimiento de software.

El proceso de desarrollo de software es comunicado a todo el personal en forma precisa y los productos de trabajo son realizados de acuerdo de procesos planeados.

Los administradores monitorean la calidad de los productos y la satisfacción del cliente.

Planificación y Presupuesto basados en performance histórica y son realistas. Los resultados esperados pueden alcanzarse.


Organizaciones Maduras

Los roles y responsabilidades son claramente definidos.

Los administradores monitorean la calidad de los productos de software y la satisfacción de los clientes.

Las planificaciones y presupuestos son basados en performance histórica y son realistas.

Usualmente se consiguen los resultados de costo, funcionalidad, tiempos y calidad de los productos.

Se sigue un proceso disciplinado pues todos los participantes entienden el valor de hacerlo y existe la infraestructura necesaria para darle soporte.


Conceptos Fundamentales

Capacidad del procesoCapacidad del proceso: describe el rango de resultados esperados que se pueden alcanzar siguiendo un proceso de software.

Desempeño del Proceso: Desempeño del Proceso: resultados reales alcanzados siguiendosiguiendo un proceso de software.

Madurez del Proceso:Madurez del Proceso: alcance para el que un proceso específico es efectivo y está definido, gerenciado, medido y controlado.

InstitucionalizaciónInstitucionalización: requiere una infraestructura y una cultura corporativa que soporte los métodos, prácticas y procedimientos del negocio que sobreviva al alejamientode los que los definieron originalmente.


Visión global del CMMDificultad para establecer las mejoras a introducirNecesidad de una estrategia de mejora: un camino de evoluciónOrdena las etapas de manera que las mejoras de una etapa son el fundamento para la siguiente.Guía para ganar control de los procesos.Determina la real madurez del proceso e identifica unos pocos aspectos más críticosFocaliza en un conjunto limitado de actividadesSe basa en principios de calidad de productos que tienen 60 años

ESQ20


Evolución del ProcesoEl CMM, como modelo es:

descriptivonormativono prescriptivo

Nivel 1 al 2: varios años; el resto puede requerir 2 añosContexto de la mejora del proceso de software:

planes estratégicos de la organizaciónobjetivos de negociosestructura organizacionaltecnología en usoculturasistema de gestión

ESQ80


Usos de CMM

Soporta al menos estos cuatro:

ExamenExamen: identificar fortalezas y debilidades.

EvaluaciónEvaluación: identificar riesgos asociados.

Definición y mejora del proceso de desarrolloDefinición y mejora del proceso de desarrollo

Comprensión de actividades necesarias Comprensión de actividades necesarias para planear e implementar un programa de mejoras.


Niveles de Madurez

continuamente mejorado OptimizadoOptimizado

predecible

InicialInicial

RepetibleRepetible

DefinidoDefinidoGestionadoGestionado

estándar y consistente

disciplinado


Nivel I : Inicial

Capacidad del ProcesoCapacidad del Proceso: Impredecible

Características del NivelCaracterísticas del Nivel:Ambiente inestable.En la crisis se dejan procedimientos planeados.El éxito depende enteramente de las personas. Presiones para recortar el proceso de software.Pocos procesos estables.


Nivel II : RepetibleCapacidad del ProcesoCapacidad del Proceso : Disciplinada

Características del NivelCaracterísticas del Nivel:Existencia de políticas y procedimientos.Objetivo es lograr la institucionalización de los

procesos de gestión.Planeamiento y Gestión. Compromiso basado en proyecto previos.Requerimientos y Productos delimitados.Estándares de proyectosRelación con contratistas.


Nivel III : DefinidoCapacidad del ProcesoCapacidad del Proceso: estándar y consistente

Características del NivelCaracterísticas del Nivel:El proceso estándar está documentado.Los procesos ayudan al desempeño más efectivo.Existe un Grupo de Proceso de Ing. de Software. Existe programa de entrenamiento.Clara visión del progreso técnico de los proyectos.Costos, programas y funcionalidad bajo control.Capacidad basada en la comprensión compartida deactividades, roles y responsabilidades.


Nivel IV : Gestionado

Capacidad del ProcesoCapacidad del Proceso : predecible

Características del NivelCaracterísticas del Nivel:Metas cuantitativas.Se miden productividad y calidad.Se reúnen y analizan datos disponibles. Se predicen cambios en procesos y calidad de producto.Alta calidad predecible.Los proyectos estrechan la variación del proceso.


Nivel V : OptimizadoCapacidad del Proceso : mejoras continuas Capacidad del Proceso : mejoras continuas

Características del NivelCaracterísticas del Nivel:Identifica fortalezas y debilidades.Análisis costo beneficio de nuevas tecnologías.Innovaciones que explotan las mejores prácticasde ingeniería de software. Análisis de Defectos.Evaluación de procesos de software.


Función por Niveles Se concentra en establecer controlesbásicos de Gestión de ProyectosRepetibleRepetible

Establecer una estructura que permitala institucionalización de procesos de Ingeniería de Software y Gestión para todos los proyectos

DefinidoDefinido

Se concentra en la Gestión cuantitativadel proceso y los productos.GestionadoGestionado

Mejora continua y medible del Procesode Software. OptimizadoOptimizado


Estructura

Niveles de MadurezNiveles de Madurez

Capacidad del ProcesoCapacidad del Proceso

indican

contienen

Areas Clave de ProcesoKPA

Areas Clave de ProcesoKPA

ObjetivosObjetivos

Aspectos ComunesAspectos ComunesImplementación o InstitucionalizaciónImplementación o Institucionalización

Infraestructura o ActividadInfraestructura o Actividad Prácticas ClavePrácticas Clave

alcanzan

organizadas por

conducen a

contienendescriben


Metas:Representan el propósito, alcance y límites de cada área clave de

Proceso.Pueden ser usadas para determinar si una organización o proyecto ha

implementado efectivamente la KPA.

Aspectos Comunes:Son atributos que indican si la implementación e institucionalización

de un área clave de proceso es efectiva, repetible y duraderaefectiva, repetible y duraderaLas prácticas clave se dividen en cinco secciones de aspectos

comunes:Compromiso para EjecutarHabilidad para EjecutarActividades RealizadasMedición y AnálisisVerificación de Implementación

Estructura del CMM: Componentes

ESQ150


Estructura del CMM: ComponentesPrácticas Clave:Cada área clave de proceso está descripta en términos de

prácticas clave que, cuando son implementadas, ayudan a satisfacer las metas de esa área clave.

Describen la infraestructura y actividades que mejor contribuyena la implementación e institucionalización del área clave de proceso

ESQ150


Visibilidad en los Diferentes Niveles

InicialInicial limitada, dificultosa90% del tiempo = 90 % de avance

RepetibleRepetible identificación de productosidentificación de puntos de control

DefinidoDefinido estándares, responsabilidadesvisión externa

GestionadoGestionado métricas, medición de progresoincremento en la capacidad de predicción

OptimizadoOptimizado cambio disciplinadovisión interna.


Áreas Clave de Proceso por NivelNivel RepetibleNivel Repetible

Gestión de Requerimientos.Planeamiento de Proyectos de Software.Seguimiento y Supervisión de Proyectos de Software. Gestión de Subcontratación de Software.Aseguramiento de Calidad de Software.Gestión de Configuración de Software.


2.1. Gestión de Requerimientos

Propósito: Establecer una comprensión común entre el cliente y el proyecto, de los requerimientos del cliente que debe satisfacer el proyecto.

Meta 1: Los requerimientos del sistema asignados al software soncontrolados para establecer un "baseline" para uso de la ingeniería de software y la gestión.

Meta 2: Los planes, productos y actividades de software deben mantenerse consistentes con los requerimientos del sistema asignados al software.


2.2. Planeamiento de Proyectos de Software

Propósito: Establecer planes razonables para ejecutar la Ingeniería de Software y para administrar el proyecto de Software.

Meta 1: Las estimaciones de software están documentadas para usar en el planeamiento y seguimiento del proyecto de software.

Meta 2: Las actividades y compromisos del proyecto de software están planeadas y documentadas.

Meta 3: Los individuos y grupos afectados acuerdan sus compromisos vinculados con el proyecto de software.


2.3. Seguimiento y Supervisión de Proyectos

Propósito: Establecer una adecuada visibilidad del progreso real para que la gerencia pueda tomar medidas efectivas cuando se producendesvíos significativos del desempeño con respecto a los planes de software

Meta 1: Los resultados y desempeños se siguen contra los planes de software.

Meta 2: Las acciones correctivas son tomadas y administradas cuando los resultados reales y el desempeño se desvían significativamente de los planes de software.

Meta 3: Los cambios en los compromisos de software son acordadospor los individuos y grupos afectados.


2.4. Gestión de Subcontratación de Software

Propósito: Seleccionar subcontratistas de Software calificados yadministrarlos efectivamente.

Meta 1: El principal contratista selecciona subcontratistas de software calificados.

Meta 2: El principal contratista y el subcontratista de software acuerdan sus compromisos mutuos.

Meta 3: El principal contratista y el subcontratista de software mantienen una comunicación regular.

Meta 4: El contratista principal sigue los resultados y desempeño del subcontratista de software contra sus compromisos.


2.5. Aseguramiento de Calidad de software

Propósito: Proporcionar a la gerencia la visibilidad apropiada del proceso usado en el proyecto y de los productos en construcción.

Meta 1: Se planean la actividades de SQA.

Meta 2: La adhesión de los productos y actividades de software a los estándares, procedimientos y requerimientos aplicables se verifica objetivamente.

Meta 3: Los grupos e individuos afectados son informados de las actividades y resultados de SQA.

Meta 4: Los incumplimientos que no pueden resolverse dentro del proyecto de software son encarados por la alta gerencia.


2.6. Gestión de Configuración de Software

Propósito: Establecer y mantener la integridad de los productos de Software del proyecto a lo largo del ciclo de vida.

Meta 1: Se planean las actividades de Gestión de configuración de software.

Meta 2: Los Productos de trabajo de software seleccionados son identificados, controlados y están disponibles.

Meta 3: Se controlan los cambios a productos de trabajo de software identificados.

Meta 4: Los grupos e individuos afectados son informados del estado y contenidos de la "baseline" de los productos de software.


Áreas Clave de Proceso por Nivel

Nivel DefinidoNivel DefinidoFoco en el Proceso de la Organización.Definición del Proceso de la Organización.Programa de Entrenamiento. Gestión integrada de Software. Ingeniería de Producto de Software. Coordinación Intergrupal.Revisiones por Pares.


3.1. Foco en el Proceso de la Organización

Propósito: Establecer la responsabilidad organizacional para lasactividades del proceso de Software que mejoran la capacidad global del proceso de software.

Meta 1: El proceso de desarrollo de software y las actividades de mejora son coordinadas a lo largo de la organización.

Meta 2: Las fortalezas y debilidades del proceso de software utilizado están identificadas en relación al proceso estándar.

Meta 3: Las actividades de desarrollo y mejora del proceso se planifican a nivel de la organización.


3.2. Definición del Proceso de la Organización

Propósito: Desarrollar y mantener un conjunto de recursos del procesoque mejoran el desempeño de los proyectos y proveen una base para obtener beneficios a largo plazo.

Meta 1: Un proceso estándar software para la organización está desarrollado y es mantenido.

Meta 2: La información relativa al uso por los proyectos de software del proceso estándar de software de la organización, se reúne, revisa y está disponible.


3.3. Programa de Entrenamiento

Propósito: Desarrollar las habilidades y el conocimiento de los individuos, para que ejecuten sus roles con efectividad y eficiencia [capacitación].

Meta 1: Las actividades de entrenamiento se planean.

Meta 2: Se provee entrenamiento para el desarrollo de las habilidades y conocimientos necesarios para desempeñar los roles gerenciales ytécnicos.


3.4. Gestión Integrada de SoftwarePropósito: Integra las actividades de Ingeniería de Software y de Gestión en un proceso de Software coherente y definido, que es adaptado desde el proceso de software estándar de la organización y las evaluaciones de proceso relacionadas.

Meta 1: El proceso de software definido para el proyecto es una versión adaptada del proceso estándar de software de la organización.

Meta 2: El proyecto es planeado y administrado de acuerdo con el proceso de software definido para el proyecto.


3.5. Ingeniería de Producto de Software

Propósito: Ejecutar consistentemente un proceso de ingeniería bien definido que integre todas las actividades de Ingeniería de Software para producir efectiva y eficientemente productos de Software correctos y consistentes.

Meta 1: Las tareas de ingeniería de software están definidas, integradas y son consistentemente ejecutadas para producir el software.

Meta 2: Los productos del trabajo de software se mantienen consistentes entre sí.


3.6. Coordinación Intergrupal

Propósito: Establecer un medio para que el grupo de SE participeactivamente con otros ingenieros para que el proyecto esté en mejores condiciones de satisfacer efectiva y eficientemente las necesidades del usuario.

Meta 1: Los requerimientos del usuario son acordados por todos los grupos afectados.

Meta 2: Los compromisos entre los grupos de ingeniería son acordados por los grupos afectados.

Meta 3: El grupo de ingeniería identifica, rastrea y resuelve los aspectos intergrupales.


3.7. Revisiones por Pares

Propósito: Eliminar temprano y eficientemente defectos del Software.

Meta 1: Se planean las actividades de revisión por pares.

Meta 2: Se identifican y eliminan defectos de los productos de software.

ESQ310


Áreas Clave de Proceso por Nivel

Nivel OptimizadoNivel OptimizadoPrevención de Defectos.Gestión de Cambio de Tecnología.Gestión de Cambio de Proceso.

Nivel GestionadoNivel GestionadoGestión de Calidad de Software.

Gestión Cuantitativa del Proceso.


4.1. Gestión cuantitativa del proceso

Propósito: Controlar cuantitativamente la performance del proceso del proyecto de software.

Meta 1: Se planean las actividades de gestión cuantitativa el proceso.

Meta 2: El desempeño del proceso de software definido para el proyecto se controla cuantitativamente.

Meta 3: La capacidad del proceso estándar de software de la organización es conocido en términos cuantitativos.

ESQ320


4.2. Gestión de Calidad del Software

Propósito: Desarrollar una comprensión cuantitativa de la calidad de los productos de software y alcanzar objetivos específicos de calidad.

Meta 1: Se planean las actividades de gestión de calidad del proyecto de software.

Meta 2: Están definidas metas medibles para la calidad del producto de software y sus prioridades.

Meta 3: El progreso real para alcanzar las metas de calidad de los productos de software está cuantificado y administrado.

ESQ330


5.1. Prevención de DefectosPropósito: Identificar la causa de los defectos y prevenirlos.

Meta 1: Prevención de defectos.

Meta 2: Causas comunes de defectos son pesquisadas e identificadas.

Meta 3: Causas comunes de defectos son priorizadas y sistemáticamente eliminadas.

ESQ340


5.2. Gestión de Cambio de Tecnología

Propósito: Identificar las nuevas tecnologías beneficiosas (herramientas, métodos, procesos) y transferirlos a la organización.

Meta 1: La incorporación de cambios en la tecnología se planea.

Meta 2: Las nuevas tecnologías son evaluadas para determinar su efecto sobre la calidad y productividad.

Meta 3: Las nuevas tecnologías se transfieren a la práctica normal a los largo de la organización.

ESQ350


5.3. Gestión de Cambio de ProcesoPropósito: Mejorar continuamente el proceso para incrementar:

Calidad del SoftwareProductividadDisminuir tiempo de desarrollo de productos

Meta 1: Se planea la mejora continua del proceso de cambio.

Meta 2: Toda la organización participa en las actividades de mejora del proceso.

Meta 3: El proceso estándar de la organización y el proceso de software definido para el proyecto, se mejoran continuamente.

ESQ360


Comparación CMM – ISO

Las cláusulas 4.7 Control de Productos Cliente-Proveedor y 4.15 Manipulación, empaquetado, almacenamiento, preservación y entrega no tienen fuerte relación con las áreas clave de proceso de CMM.

La cláusula 4.19 sobre Servicios está completamente distribuida en CMM.

Un tema de debate es la relación exacta entre ISO – CMM, respecto a la acción preventiva y correctiva (4.14)y las técnicas estadísticas (4.20)


Comparación CMM – ISO Aspecto: ÉnfasisAspecto: Énfasis

La principal diferencia entre los modelos ISO – CMM es que CMM hace hincapié en la mejora continua del proceso.

Otra diferencia reside en que CMM focaliza estrictamente en Software, mientras que ISO 9001 tiene un alcance mucho más amplio, que comprende software, hardware, materiales procesados y servicios.

Ambos ponen énfasis como punto de partida en: “ Diga que hace, haga lo que dice”



Aspecto: Nivel de DetalleAspecto: Nivel de DetalleLa principal diferencia entre los modelos ISO – CMM es el nivel de

detalle que difiere significativamente, la sección 4 en ISO 9000 tiene alrededor de 12 páginas de largo, contra más de 500 páginas de CMM.

El alto nivel de abstracción de ISO puede causar que los auditores interpreten el estándar de maneras diferentes.



Aspecto: AuditoresAspecto: AuditoresLos auditores son entrenados en los estándares de la Serie ISO 9000,

pero no son entrenados en conocimiento sobre aspectos específicos de software.

Para auditorias específicas de software debería integrarse al equipo personas con conocimientos en la disciplina.

Otra razón de discrepancia es que un Auditor puede no requerir maestría para satisfacer la correspondencia con la cláusula de ISO 9001.

TickIt produce auditores que entienden como aplicar la norma ISO 9001 al Software.


Comparación CMM - SPICE

Aspecto: Evolución del ProcesoAspecto: Evolución del ProcesoSPICESPICE

Los niveles de capacidad son aplicados sobre los procesos. Agrega el nivel 0: un nivel puede no ser ejecutado para nada.

VentajaVentaja: Mayor granularidad en la medición y análisis.DesventajaDesventaja: Procesos menos importantes pueden ocultar aspectos que no

se definieron como prioritarios.


Comparación CMM - SPICEAspecto: Evolución del Proceso:Aspecto: Evolución del Proceso:CMMCMM

Los niveles de madurez organizacional pueden definirse como un conjunto de perfiles para los procesos de SPICE. Las KPA pertenecen a un único nivel de madurez. Los procesos que no están descriptos en CMM, también existen y evolucionan.

Ventaja: Focaliza en pocas áreas “vitales” que comúnmente bloquean la performance del proceso.Desventaja: La gente puede perder el seguimiento de los procesos que no están focalizados en algún nivel particular, pero que aún así deben realizarse.


Comparación CMM - SPICE

Aspecto: Determinación de Prioridades de Aspecto: Determinación de Prioridades de MejoramientoMejoramiento

SPICESPICE

No prescribe ningún camino particular de mejora. Las prioridades son dejadas completamente a la organización.Los procesos individuales pueden ser mejorados continuamente. Los niveles de capacidad miden un proceso específico.

Desventaja: Puede ser difícil decidir que aspectos atacar primero.


Comparación CMM - SPICEAspecto: Determinación de Prioridades de Aspecto: Determinación de Prioridades de

MejoramientoMejoramientoCMMCMM

Construye la capacidad del proceso focalizando en pocos aspectos vitales para la organización en su totalidad.Los niveles de madurez priorizan los problemas de software generales.

Desventaja: prescriba atacar aspectos de gestión de proyecto antes que los de ingeniería.


Ejemplo de Aplicación sobre un Área Clave de Proceso del Nivel 2:

Planificación de Proyectos de Software


2.2.Planificación de Proyectos de Software

Propósito: Establecer planes razonables para ejecutar la Ingeniería de Software y para gerenciar el proyecto de Software

Estos planes son la base de la gestión del proyecto, 2.3.

Meta 1: Las estimaciones de software están documentadas para usar en el planeamiento y seguimiento del proyecto el software.

Meta 2: Las actividades y compromisos del proyecto de software están planeadas y documentadas.

Meta 3: Los individuos y grupos afectados acuerdan sus compromisos vinculados con el proyecto de software.


Compromiso para la ejecución

1. Un gerente de proyectos de software es designado responsable de negociar los compromisos y desarrollar el plan del proyecto de desarrollo de software.

2. Para el planeamiento de un proyecto de software (PSw), el proyecto sigue una política organizacional escrita


Compromiso 1Esta política comúnmente especifica que:1. Los requerimientos del sistema asignados al software son

usados como base para la planificación del proyecto de software.

2. Los compromisos del proyecto de software son negociados entre:

El gerente de proyecto,El gerente de proyecto de software, yOtros administradores.

3. La intervención de otros grupos en las actividades de software es negociada con estos grupos y documentada.Ejemplos de otros grupos de ingeniería incluyen:

Ingeniería de Sistemas,Ingeniería de Hardware, Prueba de Sistema.


Compromiso 1 (cont)4. Los grupos afectados revisan el proyecto de software:

Estimación de tamaño del software,Estimación del esfuerzo y el costo,programas, yOtros compromisos.

Ejemplos de otros grupos afectados:Ingeniería de software (incluyendo todos los subgrupos tales como diseño de software),Estimación de software,Ingeniería de sistema,Prueba de sistema,Aseguramiento de la calidad del software,Gestión de Configuración de Software ,Gestión de contratos y,Soporte de documentación.


Compromiso 1 (cont.)

5. La gerencia revisa todos los compromisos del proyecto de software hechos a individuos y grupos externos de la organización.

6. El plan de desarrollo de software del proyecto es gestionado y controlado.


Habilidad para ejecutar

1. Existe una orden de trabajo documentada y aprobada para el PSw.

2. Se asignan responsabilidades para el desarrollo del plan de desarrollo de software.

3. Se proveen adecuados recursos y fondos para el planeamiento del PSw.

4. Los gerentes de software, los ingenieros de software y otrosindividuos involucrados en el planeamiento del PSw están entrenados en los procedimientos de estimación y planeamiento aplicables a su área de responsabilidad.



Hab 1. Existe una orden de trabajo documentada y aprobada para el PSw

1. La Orden de Trabajo abarcaalcance del trabajoobjetivos y metas técnicasidentificación de clientes y usuarios finalesestándares impuestosresponsabilidades asignadasrestricciones y objetivos de costos y cronogramasdependencias entre el PSw y otras organizacionesrestricciones y objetivos de los recursosotras restricciones y objetivos para desarrollo y mantenimiento



2. La orden de trabajo es revisada por:gerente de proyectogerente del PSwotros gerentes de softwareotros grupos afectados

3. La directiva de trabajo es administrada y controlada



Hab 2. Se asignan responsabilidades para el desarrollo del plan de desarrollo de software1. El gerente del PSw, directamente o por delegación, coordina el

planeamiento del PSw2. Las responsabilidades por los productos del trabajo de software y las

actividades se asignan a los gerentes de software en una forma rastreable y contabilizable

Hab 3. Se proveen adecuados recursos y fondos para el planeamiento del PSw1. Cuando es factible individuos con experiencia se asignan al desarrollo del

plan2. Se dispone de herramientas para soportar el planeamiento de las

actividades del PSw


Actividades ejecutadas1. El grupo de Ingeniería de Software participa en el equipo que propone

el proyecto.

2. El planeamiento del proyecto de software se inicia en las etapasiniciales y en paralelo con el planeamiento global del proyecto.

3. A lo largo de la vida del proyecto el grupo de Ingeniería de Software participa junto con otros grupos afectados, en el planeamiento global del proyecto.

4. Los compromisos del proyecto de software hechos por individuos ygrupos ajenos a la organización son revisados con la gerencia seniorde acuerdo a un procedimiento documentado.


Actividades ejecutadas/25. Está identificado o definido un ciclo de vida con etapas predefinidas

de tamaño manejables.

6. El plan del proyecto de desarrollo de software se desarrolla de acuerdo a un procedimiento documentado.

7. El plan para el proyecto de software está documentado.

8. Lo productos del trabajo de software que se necesitan establecer y mantener están identificados.

9. Las estimaciones del tamaño de los productos del trabajo de software (o cambios de ese tamaño) son derivadas de acuerdo a un procedimiento documentado.


Actividades ejecutadas/310. Las estimaciones del esfuerzo y costo del proyecto de software

son derivadas de acuerdo a un procedimiento documentado.

11. Las estimaciones de los recursos críticos de computadoras son derivadas de acuerdo a un procedimiento documentado.

12. El cronograma del proyecto de software se deriva de acuerdo a un procedimiento documentado.

13. Los riesgos de software asociados con costos, recursos, cronogramas y aspectos técnicos del proyecto están identificados, establecidos y documentados.

14. Se preparan planes para las facilidades y herramientas de soporte a ingeniería de software del proyecto.

15. Se registran los datos del planeamiento del software


Medición y análisis

Las mediciones se hacen y se usan para determinar el estado de las actividades de planeamiento de software

Ejemplos de mediciones incluyen:

Trabajo completado, esfuerzo gastado, fondos gastados en las Cumplimiento de hitos para las actividades planificadas en el proyecto de software, comparado con el plan.actividades planificadas en el proyecto de software, comparadas con el plan.


Verificación de la implementación

1. Las actividades para planear el proyecto de software son revisadas periódicamente con la gerencia senior.

2. Las actividades para planear el proyecto de software son revisadas periódicamente con el gerente de proyecto y en respuesta a eventos.

3. El grupo de aseguramiento de calidad de software revisa y/o audita las actividades y productos del trabajo para planear el proyecto de software e informa los resultados.


Verificación 1Las actividades para planear el proyecto de software son revisadas

periódicamente con la gerencia senior.

1. Se revisa la performance técnica, del personal, de costos y de programación.

2. Los conflictos y aspectos no resueltos en niveles más bajos son direccionados.

3. Los riesgos asociados al Proyecto de Software son direccionados.

4. Los ítems son asignados, revisados y rastreados hasta el cierre.

5. Un reporte de resumen de cada reunión se prepara y distribuye a los individuos y grupos afectados.


Verificación 2Las actividades para planear el proyecto de software son revisadas

periódicamente con el gerente de proyecto y en respuesta a eventos.

1. Están representados los grupos afectados.2. El estado y los resultados actuales de las actividades de la

planificación del proyecto de software son revisadas con la definición del trabajo y los requerimientos.

3. Son direccionadas las dependencias entre grupos..4. Son direccionados los conflictos y aspectos no resueltos en los nivele

más bajos. 5. Son revisados los riesgos del proyecto.6. Los ítems de acción son asignados, revisados y rastreados hasta su

cierre.7. Un reporte de resumen de cada reunión se prepara y distribuye a los

individuos y grupos afectados.


Verificación 3El grupo de aseguramiento de calidad del software revisa y/o audita las actividades y productos del trabajo para planear el proyecto de software e informa los resultados.

Como mínimo, los revisores y/o auditores verifican:1. Las actividades para la estimación y planificación de software.2. Las actividades para revisión y concreción de compromisos del

proyecto..3. Las actividades para la preparación del Plan de Desarrollo de

Software.4. El estándar utilizado para la confección del Plan de Desarrollo de

Software.5. El contenido del Plan de Desarrollo de Software.


Cuestionario de madurez

¿Las estimaciones (tamaño, costo, cronograma, etc) se documentan para usar en el planeamiento y seguimiento del proyecto de software?

¿Los planes de software documentan las actividades a ser ejecutadas y los compromisos hechos?

¿Todos los grupos e individuos acuerdan son compromisos relacionados con el proyecto?

¿El proyecto sigue una política organizacional escrita para planear el proyecto?


Cuestionario de madurez

¿Se proveen recursos adecuados para el planeamiento del proyecto (fondos, personal con experiencia, etc)

¿Se usan mediciones para determinar el status de las actividades de planeamiento (ejemplo: los hitos completados se comparan con el plan)?

¿El gerente de proyecto revisa las actividades de planeamiento sobre la base de períodos y eventos?


ConclusionesUna forma de ocuparnos de la calidad es a través de la mejora del proceso de desarrollo de software.

Como modelo de madurez y capacidad, CMM representa una de las alternativas mas efectivas y difundidas en todo el mundo para guiar a las organizaciones de software en la selección de estrategias para el mejoramiento de sus procesos de desarrollo.

CMM describe un camino evolutivo de cinco niveles madurez en el cual cada nivel nos indica áreas claves de proceso y nos lleva desde un proceso inicial o ad hoc hasta un proceso maduro o disciplinado.

Los principales beneficios que provee son: mejorar la calidad de los productos, aumentar tiempo de respuesta al mercado e incrementarla productividad de la organización.


Consultas

Preguntas

Sugerencias

Próximos Pasos


Referencias

cmm-cmu-sei-tr24-93 (CMM 1.1)

cmm-cmu-sei-tr25-93 (Key pract)

Mark Paulk - cmm-overview

cmm y la calidad en el desarrollo de software

Documents