CMM y la Calidad en el Desarrollo de Software
Versi\u00f3n 2.0308
Objetivo de la Capacitaci\u00f3n
Obtener conocimiento general del modelo capacidad y madurez denominado SW-CMM
\u2022 facilitar el inicio de un camino de me organizacional
\u2022 comprender la estructura del modelo
\u2022 tomar conciencia del esfuerzo que se para implementarlo
Agenda de la Capacitaci\u00f3n \ue000
\u00bfQu\u00e9 es la calidad?
\ue000
Atributos para medir la calidad
\ue000
Introducci\u00f3n a CMM
\ue000
Comparaci\u00f3n entre esquemas existent
\ue000
Descripci\u00f3n de las \u00c1reas Clave d
\ue000
Ejemplos
¿Qué es la calidad?
Todos los aspectos y característi producto o servicio que se relacio habilidad de alcanzar las nece manifiestas o implícitas
La calidad es un concepto complejo y que puede describirse desde cinco pe Visión Del Usuario
Visión De Visión Visión Del ManufacturaTrascendental Producto
Visión Basada en el valor
Algo que puede ser reconocido pero no defi
Para el software se trataría de un ideal que nunca puede imp completamente Visión Del Usuario
Visión De Visión Visión Del ManufacturaTrascendental Producto
Visión Basada en el valor
La calidad se adecua a un propósito....
Evalúa al producto en un contexto de trabajo y puede ser alta personalizado Visión Del Usuario
Visión De Visión Visión Del ManufacturaTrascendental Producto
Visión Basada en el valor
Calidad como conformidad con una especifi
Foco en la calidad del producto durante el proceso de produc después de liberado Visión Del Usuario
Visión De Visión Visión Del ManufacturaTrascendental Producto
Visión Basada en el valor
Calidad atada a características del product
Considera características inherentes al producto, mide la cal cualidades internas Visión Del Usuario
Visión De Visión Visión Del ManufacturaTrascendental Producto
Visión Basada en el valor
Depende del monto que esté dispuesto a pa Ataca el problema del equilibrio entre diseño y costos
Visión Del Usuario
Visión De Visión Visión Del ManufacturaTrascendental Producto
Visión Basada en el valor
¿Por qué ocuparse de la calidad?
Es un aspecto competitivo Es esencial para sobrevivir Es indispensable para el mercado inte Equilibrio costo-efectividad Retiene clientes e incrementa benefici Es el sello de clase en el mundo de los
Cadena de Reacción de Deming
Mejora de calidad Mejora de Productividad Reducción de Costos Reducción Reducción de Precios Incremento de Mercado Crecimiento en enlos los Negocios Negocios Ex
Control de Calidad
El control de calidad es una inspecciones, revisiones y prueba lo largo del ciclo de desarrollo, p que cada producto cumpla requerimientos que le han sido
Se controla CALIDAD DE PROC y CALIDAD DE PRODUCTO SOFT
¿Cómo se mide la Calidad?
La calidad se mide de manera in concentramos en ciertos atribu medirlos.
Para medirla la calidad existen d Modelos: Boehm, McCall, ISO, B
ISO 9126 (1991)
Características de la calidad del soft Funcionalidad Confiabilidad Usabilidad Eficiencia Mantenibilidad Portabilidad
Funcionalidad
Conjunto de atributos que se relacionan con la ex conjunto de funciones y sus propiedades específi Adaptabilidad Exactitud Interoperabilidad Conformidad (compliance) Seguridad
Func Con
Mant Po
Confiabilidad
Conjunto de atributos relacionados con la ca software de mantener su nivel de comportam condiciones establecidas y por un período de Madurez Tolerancia a fallas
Funci Confi
Mante Por
Usabilidad
Conjunto de atributos referidos al esfuerzo n uso y la evaluación individual de tal uso, de software por conjunto establecido o implícito Inteligibilidad Facilidad de aprendizaje Operabilidad
Funci Confi Us
Mante Por
Eficiencia
Conjunto de atributos referidos a la relació comportamiento de software y la cantidad d utilizados, en condiciones establecidas Comportamiento temporal Utilización de recursos
Func Con
Man Po
Mantenibilidad
Conjunto de atributos referidos al esfuerzo n realizar modificaciones especificadas Facilidad de análisis Facilidad de cambios Estabilidad Verificabilidad
Funci Confi Us
Mante
Portabilidad
Conjunto de atributos referidos a la capacid producto de software de ser transferido de otro Adaptabilidad Facilidades de instalación Conformidad (conformance) Facilidad de reemplazo
Fun Co
Man
Equilibrio entre los Atributos de C Software Performance
Segu
Confiabilidad Local (único atributo) óptimo
Aseguramiento de Calidad
El aseguramiento de calidad co auditoria y la función de inform gestión, si los datos identifican p responsabilidad de la gestión a resolverlos.
Aseguramiento de Calidad de Sof
Los requerimientos del software s la medida de la calidad.
Los estándares especificados defin conjunto de criterios que se deben Existen requisitos implícitos a los ajustarse.
Aseguramiento de Calidad de Sof Actividades Establecer Plan de Calidad
Participar en la definición del Proceso d
Revisión de las actividades de Ingenierí Auditoria de los Productos de Software
Documentar e informar desviaciones se
procedimientos establecidos.
Costos de la Calidad
Incluye los costos asociados en la bú obtención de la calidad, pueden divi asociados con: La prevención La evaluación Los fallos
Costos de la Calidad: Costos de P Planificación de la Calidad Revisiones Técnicas Formales Equipo de Pruebas Formación
Costos de la Calidad: Costos de E
Inspección en el proceso y entre p
Calibrado y mantenimiento del eq Pruebas
Costos de la Calidad: Costos de F Revisión Reparación
Análisis de las Modalidades de fal
Costos de la Calidad: Costos de F Resolución de Quejas
Devolución y Sustitución de Prod 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 sistemas Mayores costos
Mantenimiento fuera d
Siempre ‘corregir’, nu nuevas Estar sobrecargado
No poder cumplir plaz
Recibir quejas del usu 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 m – tiempo y esfuerzo.
• Cuesta menos y tardo menos.
Recuerde que un proyecto ‘normal’ 43% del esfuerzo gastado en re
¿Qué es un Sistema de Calidad?
Es el conjunto de cosas que la a incorpora para asegurar y demos del producto de software y de asociados.
Es el proceso de trabajo complet políticas, procedimientos, herr recursos, humanos y tecno
Relación CMM – Proceso de Desar Política
Leyes y Regulaciones que gobiernan o restringen operaciones
Estándare
Definiciones operaciona aceptación para prod intermedi
Restringen el proceso
Proceso
Describe que ocurre con la organización para construir product estándares en concordancia con políticas de la organizac
Es implementado por
Procedimientos
Describen “cómo”; instrucciones “paso por paso” que impleme
Soportado por
Esquemas Existentes... ISO SPICE CMM
¿Qué es el CMM?
Es un esquema que representa u de mejoramientos, permite deter madurez y evaluar las capacidad organizaciones que desarrollan s recomendado para organizacion quieren incrementar la capacida proceso de desarrollo
Organizaciones Inmaduras
Los procesos de software generalmente improvisados durante el curso del proyec
Aún si existe un proceso de desarrollo es rigurosamente aplicado.
Es reaccionaria y los administradores concentran en resolver crisis (apagar inc
Planificaciones y presupuestos son exce debido a que no se basan en estimacione
Organizaciones Maduras
Poseen la habilidad para administrar lo desarrollo y mantenimiento de software.
El proceso de desarrollo de software e todo el personal en forma precisa y los pr trabajo son realizados de acuerdo de pro planeados.
Los administradores monitorean la calid productos y la satisfacción del cliente.
Planificación y Presupuesto basados en
Organizaciones Maduras
Los roles y responsabilidades son clar
Los administradores monitorean la cali productos de software y la satisfacción d
Las planificaciones y presupuestos son performance histórica y son realistas.
Usualmente se consiguen los resultado funcionalidad, tiempos y calidad de los p
Se sigue un proceso disciplinado pues participantes entienden el valor de hace
Conceptos Fundamentales
Capacidad Capacidad del del proceso: proceso describe el rango de res esperados que se pueden alcanzar siguiendo un
Desempeño Desempeño del delProceso: Proceso:resultados reales alcan siguiendo un proceso de software.
Madurez Madurez del del Proceso: Proceso:alcance para el que un pro
es efectivo y está definido, gerenciado, medido y
Institucionalización Institucionalización : requiere una infraestructura y
cultura corporativa que soporte los métodos, prácti procedimientos del negocio que sobreviva al alejam
Visión global del CMM
Dificultad para establecer las mejoras a Necesidad de una estrategia de mejora: evolución Ordena las etapas de manera que las m son el fundamento para la siguiente. Guía para ganar control de los procesos. Determina la real madurez del proceso aspectos más críticos Focaliza en un conjunto limitado de activ Se basa en principios de calidad de prod años
Evolución del Proceso El CMM, como modelo es: descriptivo normativo no prescriptivo
Nivel 1 al 2: varios años; el resto puede requerir 2 a Contexto de la mejora del proceso de software planes estratégicos de la organización objetivos de negocios estructura organizacional tecnología en uso cultura
Usos de CMM Soporta al menos estos cuatro:
Examen Examen: identificar fortalezas y debilidades. Evaluación Evaluación : identificar riesgos asociados.
Definición de de desa Definición yy mejora mejoradel delproceso proceso Comprensión Comprensión de de actividades actividadesnecesarias necesaria planear e implementar un programa de
Niveles de Madurez continuamente mejorado predecible estándar y consistente disciplinado
Inicial Inicial
Repetible Repetible
Definido Definido
Op Op
Gestionado Gestionado
Nivel I : Inicial
Capacidad Capacidad del del Proceso: Proceso Impredecible Características Características del del Nivel: Nivel
Ambiente inestable. En la crisis se dejan procedimiento El éxito depende enteramente de l Presiones para recortar el proceso Pocos procesos estables.
Nivel II : Repetible
Capacidad Capacidad del del Proceso Proceso: Disciplinada Características Características del del Nivel: Nivel
Existencia de políticas y procedim Objetivo es lograr la institucionaliz procesos de gestión. Planeamiento y Gestión. Compromiso basado en proyecto pre Requerimientos y Productos delimit
Nivel III : Definido
Capacidad Capacidad del del Proceso: Proceso estándar y con Características Características del del Nivel: Nivel
El proceso estándar está documenta Los procesos ayudan al desempeño Existe un Grupo de Proceso de Ing. Existe programa de entrenamiento. Clara visión del progreso técnico de Costos, programas y funcionalidad b Capacidad basada en la comprensió
Nivel IV : Gestionado Capacidad Capacidad del del Proceso Proceso: predecible Características Características del del Nivel: Nivel
Metas cuantitativas. Se miden productividad y calidad. Se reúnen y analizan datos disponi Se predicen cambios en procesos y producto. Alta calidad predecible.
Nivel V : Optimizado
Capacidad cont Capacidad del del Proceso Proceso: mejoras : mejoras co Características Características del del Nivel: Nivel
Identifica fortalezas y debilidades. Análisis costo beneficio de nuevas t Innovaciones que explotan las mejo de ingeniería de software.
Análisis de Defectos. Evaluación de procesos de softwa
Función por Niveles Repetible Repetible
Se concentra en estable básicos de Gestión de P
Gestionado Gestionado
Establecer una estructur la institucionalización de Ingeniería de Software y todos los proyectos Se concentra en la Gesti del proceso y los produc
Optimizado Optimizado
Mejora continua y medib de Software.
Definido Definido
Estructura indican Capacidad Capacidaddel delProceso Proceso Objetivos Objetivos
Niveles Nivelesde deMadurez Madurez contienen
alcanzanAreas Clave de Proceso Areas Clave de Proceso KPA KPA orga
Implementación Implementaciónoo conducen aAspectos C Aspectos Institucionalización Institucionalización describen
contie Prácticas Clave
Estructura del CMM: Component Metas:
Representan el propósito, alcance y límites de cada á Proceso. Pueden ser usadas para determinar si una organizac implementado efectivamente la KPA.
Aspectos Comunes:
Son atributos que indican si la implementación e ins de un área clave de proceso efectiva, es efectiva, repetible y dura repetible y dur Las prácticas clave se dividen en cinco secciones de comunes: Compromiso para Ejecutar Habilidad para Ejecutar Actividades Realizadas
Estructura del CMM: Component Prácticas Clave:
Cada área clave de proceso está descripta en té prácticas clave que, cuando son implementad satisfacer las metas de esa área clave.
Describen la infraestructura y actividades que m a la implementación e institucionalización de proceso
Visibilidad en los Diferentes Nive Inicial Inicial
limitada, dificultosa 90% del tiempo = 90 % de
Repetible Repetible
identificación de productos identificación de puntos de
Definido Definido
estándares, responsabilidades visión externa
Gestionado Gestionado
métricas, medición de progre incremento en la capacidad
Optimizado
cambio disciplinado
Áreas Clave de Proceso por Nivel Nivel Repetible
Gestión de Requerimientos. Planeamiento de Proyectos de Softw Seguimiento y Supervisión de Proye Gestión de Subcontratación de Soft Aseguramiento de Calidad de Softw Gestión de Configuración de Softwa
2.1. Gestión de Requerimientos
Propósito: Establecer una comprensión común entre e proyecto, de los requerimientos del cliente que debe proyecto.
Meta 1: Los requerimientos del sistema asignados al controlados para establecer un "baseline" para uso software y la gestión.
Meta 2: Los planes, productos y actividades de softw consistentes con los requerimientos del sistema asi
2.2. Planeamiento de Proyectos de
Propósito: Establecer planes razonables para ejecu Software y para administrar el proyecto de Softw
Meta 1: Las estimaciones de software están docum planeamiento y seguimiento del proyecto de softw
Meta 2: Las actividades y compromisos del proyect planeadas y documentadas.
Meta 3: Los individuos y grupos afectados acuerda vinculados con el proyecto de software.
2.3. Seguimiento y Supervisión de
Propósito: Establecer una adecuada visibilidad del que la gerencia pueda tomar medidas efectivas desvíos significativos del desempeño con respe software
Meta 1: Los resultados y desempeños se siguen co software.
Meta 2: Las acciones correctivas son tomadas y adm los resultados reales y el desempeño se desvían s de los planes de software.
2.4. Gestión de Subcontratación de Propósito: Seleccionar subcontratistas de Software administrarlos efectivamente.
Meta 1: El principal contratista selecciona subcontr calificados.
Meta 2: El principal contratista y el subcontratista d sus compromisos mutuos.
Meta 3: El principal contratista y el subcontratista d una comunicación regular.
2.5. Aseguramiento de Calidad de
Propósito: Proporcionar a la gerencia la visibilidad usado en el proyecto y de los productos en constru Meta 1: Se planean la actividades de SQA.
Meta 2: La adhesión de los productos y actividades estándares, procedimientos y requerimientos aplic objetivamente.
Meta 3: Los grupos e individuos afectados son infor actividades y resultados de SQA.
2.6. Gestión de Configuración de S
Propósito: Establecer y mantener la integridad de l Software del proyecto a lo largo del ciclo de vida.
Meta 1: Se planean las actividades de Gestión de c software.
Meta 2: Los Productos de trabajo de software selec identificados, controlados y están disponibles.
Meta 3: Se controlan los cambios a productos de tr identificados.
Meta 4: Los grupos e individuos afectados son info y contenidos de la "baseline" de los productos de
Áreas Clave de Proceso por Nive Nivel Definido
Foco en el Proceso de la Organización. Definición del Proceso de la Organizació 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 Organ
Propósito: Establecer la responsabilidad organizaci actividades del proceso de Software que mejoran proceso de software. Meta 1: El proceso de desarrollo de software y las son coordinadas a lo largo de la organización.
Meta 2: Las fortalezas y debilidades del proceso de están identificadas en relación al proceso estánda Meta 3: Las actividades de desarrollo y mejora del nivel de la organización.
3.2. Definición del Proceso de la O
Propósito: Desarrollar y mantener un conjunto de re que mejoran el desempeño de los proyectos y prove obtener beneficios a largo plazo.
Meta 1: Un proceso estándar software para la orga desarrollado y es mantenido.
Meta 2: La información relativa al uso por los proy proceso estándar de software de la organización, está disponible.
3.3. Programa de Entrenamiento
Propósito: Desarrollar las habilidades y el conocim individuos, para que ejecuten sus roles con efect [capacitación].
Meta 1: Las actividades de entrenamiento se plan
Meta 2: Se provee entrenamiento para el desarrol conocimientos necesarios para desempeñar los ro técnicos.
3.4. Gestión Integrada de Softwar
Propósito: Integra las actividades de Ingeniería de So en un proceso de Software coherente y definido, que el proceso de software estándar de la organización y proceso relacionadas.
Meta 1: El proceso de software definido para el proy adaptada del proceso estándar de software de la o
Meta 2: El proyecto es planeado y administrado de a de software definido para el proyecto.
3.5. Ingeniería de Producto de Soft
Propósito: Ejecutar consistentemente un proceso d definido que integre todas las actividades de Ingen para producir efectiva y eficientemente productos correctos y consistentes.
Meta 1: Las tareas de ingeniería de software están y son consistentemente ejecutadas para producir e
Meta 2: Los productos del trabajo de software se m entre sí.
3.6. Coordinación Intergrupal
Propósito: Establecer un medio para que el grupo activamente con otros ingenieros para que el pr mejores condiciones de satisfacer efectiva y efic necesidades del usuario.
Meta 1: Los requerimientos del usuario son acord grupos afectados.
Meta 2: Los compromisos entre los grupos de ing acordados por los grupos afectados.
Meta 3: El grupo de ingeniería identifica, rastrea aspectos intergrupales.
3.7. Revisiones por Pares
Propósito: Eliminar temprano y eficientemente defe Meta 1: Se planean las actividades de revisión por
Meta 2: Se identifican y eliminan defectos de los pr
Áreas Clave de Proceso por Nivel Nivel Nivel Optimizado Optimizado
Prevención de Defectos. Gestión de Cambio de Tecnología. Gestión de Cambio de Proceso.
Nivel Nivel Gestionado Gestionado
Gestión de Calidad de Software.
Gestión Cuantitativa del Proceso.
4.1. Gestión cuantitativa del proce
Propósito: Controlar cuantitativamente la performa proyecto de software.
Meta 1: Se planean las actividades de gestión cuan
Meta 2: El desempeño del proceso de software defi controla cuantitativamente.
Meta 3: La capacidad del proceso estándar de softw es conocido en términos cuantitativos.
4.2. Gestión de Calidad del Softwa
Propósito: Desarrollar una comprensión cuantitativ productos de software y alcanzar objetivos específi
Meta 1: Se planean las actividades de gestión de ca software.
Meta 2: Están definidas metas medibles para la cal software y sus prioridades.
Meta 3: El progreso real para alcanzar las metas de productos de software está cuantificado y adminis
5.1. Prevención de Defectos
Propósito: Identificar la causa de los defectos y pre Meta 1: Prevención de defectos.
Meta 2: Causas comunes de defectos son pesquisa
Meta 3: Causas comunes de defectos son priorizad sistemáticamente eliminadas.
5.2. Gestión de Cambio de Tecnolo
Propósito: Identificar las nuevas tecnologías benefi métodos, procesos) y transferirlos a la organizaci
Meta 1: La incorporación de cambios en la tecnolo
Meta 2: Las nuevas tecnologías son evaluadas para efecto sobre la calidad y productividad. Meta 3: Las nuevas tecnologías se transfieren a la largo de la organización.
5.3. Gestión de Cambio de Proceso
Propósito: Mejorar continuamente el proceso par Calidad del Software Productividad Disminuir tiempo de desarrollo de productos
Meta 1: Se planea la mejora continua del proceso
Meta 2: Toda la organización participa en las acti del proceso.
Meta 3: El proceso estándar de la organización y software definido para el proyecto, se mejoran co
Comparación CMM – ISO
Las cláusulas 4.7 Control de Productos ClienteManipulación, empaquetado, almacenamiento, pres tienen fuerte relación con las áreas clave de proces
La cláusula 4.19 sobre Servicios está completa CMM.
Un tema de debate es la relación exacta entre acción preventiva y correctiva (4.14)y las técnicas e
Comparación CMM – ISO Aspecto: Énfasis
La principal diferencia entre los modelos ISO – hincapié en la mejora continua del proceso.
Otra diferencia reside en que CMM focaliza est mientras que ISO 9001 tiene un alcance mucho más comprende software, hardware, materiales procesa
Ambos ponen énfasis como punto de parti “ Diga que hace, haga lo que dice”
Comparación CMM – ISO Aspecto: Nivel de Detalle
La principal diferencia entre los modelos ISO detalle que difiere significativamente, la sección 4 e alrededor de 12 páginas de largo, contra más de 50
El alto nivel de abstracción de ISO puede caus interpreten el estándar de maneras diferentes.
Comparación CMM – ISO Aspecto: Auditores
Los auditores son entrenados en los estándares pero no son entrenados en conocimiento sobre aspe software. Para auditorias específicas de software debería personas con conocimientos en la disciplina.
Otra razón de discrepancia es que un Auditor para satisfacer la correspondencia con la cláusula d TickIt produce auditores que entienden como al Software.
Comparación CMM - SPIC Aspecto: Evolución del Proceso
SPICE
Los niveles de capacidad son aplicados sobre los pr nivel 0: un nivel puede no ser ejecutado para nada
Ventaja: Ventaja Mayor granularidad en la medición y análi Desventaja: Desventaja Procesos menos importantes pueden oc se definieron como prioritarios.
Comparación CMM - SPIC
Aspecto: Evolución del Proceso:
CMM
Los niveles de madurez organizacional pueden de de perfiles para los procesos de SPICE. Las KPA p nivel de madurez. Los procesos que no están desc existen y evolucionan.
Ventaja: Focaliza en pocas áreas “vitales” que com performance del proceso. Desventaja: La gente puede perder el seguimiento están focalizados en algún nivel particular, pero q
Comparación CMM - SPIC
Aspecto: Determinación de Prioridad Mejoramiento
SPICE
No prescribe ningún camino particular de mejora. L dejadas completamente a la organización. Los procesos individuales pueden ser mejorados con niveles de capacidad miden un proceso específico.
Desventaja: Puede ser difícil decidir que aspectos at
Comparación CMM - SPIC
Aspecto: Determinación de Prioridad Mejoramiento CMM
Construye la capacidad del proceso focalizando en p para la organización en su totalidad. Los niveles de madurez priorizan los problemas de
Desventaja: prescriba atacar aspectos de gestión de proyecto antes que los de ingeniería.
Ejemplo de Aplicación sobre un Á Proceso del Nivel 2: Planificación de Proyectos de
2.2.Planificación de Proyectos de
Propósito: Establecer planes razonables para ejecu Software y para gerenciar el proyecto de Softwar
Estos planes son la base de la gestión del proy
Meta 1: Las estimaciones de software están docum usar en el planeamiento y seguimiento del proyec Meta 2: Las actividades y compromisos del proyect planeadas y documentadas. Meta 3: Los individuos y grupos afectados acuerda vinculados con el proyecto de software.
Compromiso para la ejecuc
1. Un gerente de proyectos de software es designa
responsable de negociar los comprom desarrollar el plan del proyecto de des software.
2. Para el planeamiento de un proyecto de softwar
(PSw), el proyecto sigue una política o escrita
Compromiso 1
Esta política comúnmente especifica que: 1. Los requerimientos del sistema asignados al so usados como base para la planificación del pro software. 2. Los compromisos del proyecto de software so entre: El gerente de proyecto, El gerente de proyecto de software, y Otros administradores.
3. La intervención de otros grupos en las activid es negociada con estos grupos y documenta
Ejemplos de otros grupos de ingeniería incluyen: Ingeniería de Sistemas, Ingeniería de Hardware,
Compromiso 1 (cont)
4. Los grupos afectados revisan el proyecto de soft Estimación de tamaño del software, Estimación del esfuerzo y el costo, programas, y Otros compromisos.
Ejemplos de otros grupos afectados:
Ingeniería de software (incluyendo todos los s 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,
Compromiso 1 (cont.)
5. La gerencia revisa todos los compromisos del p hechos a individuos y grupos externos de la orga
6. El plan de desarrollo de software del proyecto e controlado.
Habilidad para ejecutar
1. Existe una orden de trabajo documentada y apr PSw.
2. Se asignan responsabilidades para el desarrollo desarrollo de software.
3. Se proveen adecuados recursos y fondos para e PSw.
4. Los gerentes de software, los ingenieros de soft individuos involucrados en el planeamiento del P entrenados en los procedimientos de estimación aplicables a su área de responsabilidad.
Habilidad para ejecuta Hab 1. Existe una orden de trabajo documentada
1. La Orden de Trabajo abarca alcance del trabajo objetivos y metas técnicas identificación de clientes y usuarios finales estándares impuestos responsabilidades asignadas restricciones y objetivos de costos y cronogr dependencias entre el PSw y otras organizac restricciones y objetivos de los recursos
Habilidad para ejecutar 2. La orden de trabajo es revisada por: gerente de proyecto gerente del PSw otros gerentes de software otros grupos afectados
3. La directiva de trabajo es administrada y contr
Habilidad para ejecutar
Hab 2. Se asignan responsabilidades para el desa desarrollo de software
1. El gerente del PSw, directamente o por delegación, c planeamiento del PSw 2. Las responsabilidades por los productos del trabajo d actividades se asignan a los gerentes de software en u y contabilizable
Hab 3. Se proveen adecuados recursos y fondos p planeamiento del PSw
1. Cuando es factible individuos con experiencia se asig plan 2. Se dispone de herramientas para soportar el planeam
Actividades ejecutadas 1.
El grupo de Ingeniería de Software participa en el equipo que el proyecto.
2.
El planeamiento del proyecto de software se inicia en las etap iniciales y en paralelo con el planeamiento globa
3.
A lo largo de la vida del proyecto el grupo de Ingeniería de So participa junto con otros grupos afectados, en e del proyecto.
4.
Los compromisos del proyecto de software hechos por individ grupos ajenos a la organización son revisados co de acuerdo a un procedimiento documentado.
Actividades ejecutadas/2 5.
Está identificado o definido un ciclo de vida con etapas prede de tamaño manejables.
6.
El plan del proyecto de desarrollo de software se desarrolla d 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 estable mantener están identificados.
9.
Las estimaciones del tamaño de los productos del trabajo de (o cambios de ese tamaño) son derivadas de acu procedimiento documentado.
Actividades ejecutadas/3
10. Las estimaciones del esfuerzo y costo del proyecto de softw
son derivadas de acuerdo a un procedimiento d
11. Las estimaciones de los recursos críticos de computadoras
derivadas de acuerdo a un procedimiento docu
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 establecidos y documentados.
14. Se preparan planes para las facilidades y herramientas de
ingeniería de software del proyecto.
Medición y análisis
Las mediciones se hacen y se usan para deter estado de las actividades de planeamiento de Ejemplos de mediciones incluyen:
Trabajo completado, esfuerzo gastado, fondo Cumplimiento de hitos para las actividades p proyecto de software, comparado con el plan actividades planificadas en el proyecto de sof con el plan.
Verificación de la implement 1.
Las actividades para planear el proyecto de software son revisadas periódicamente con la gerencia sen
2.
Las actividades para planear el proyecto de software son revisadas periódicamente con el gerente de p respuesta a eventos.
3.
El grupo de aseguramiento de calidad de software revisa audita las actividades y productos del trabajo proyecto de software e informa los resultado
Verificación 1
Las actividades para planear el proyecto de softw periódicamente con la gerencia senior. 1.
Se revisa la performance técnica, del persona programación.
2.
Los conflictos y aspectos no resueltos en nive bajos son direccionados.
3.
Los riesgos asociados al Proyecto de Software
4.
Los ítems son asignados, revisados y rastread
5.
Un reporte de resumen de cada reunión se pr los individuos y grupos afectados.
Verificación 2
Las actividades para planear el proyecto de softwa periódicamente con el gerente de proyecto y en
1. Están representados los grupos afectados. 2. El estado y los resultados actuales de las activid planificación del proyecto de software son revisa del trabajo y los requerimientos. 3. Son direccionadas las dependencias entre grup 4. Son direccionados los conflictos y aspectos no r más bajos. 5. Son revisados los riesgos del proyecto. 6. Los ítems de acción son asignados, revisados y cierre. 7. Un reporte de resumen de cada reunión se prep individuos y grupos afectados.
Verificación 3
El grupo de aseguramiento de calidad del so audita las actividades y productos del traba proyecto de software e informa los resulta
Como mínimo, los revisores y/o auditores verific 1. Las actividades para la estimación y planificac 2. Las actividades para revisión y concreción de proyecto.. 3. Las actividades para la preparación del Plan d Software. 4. El estándar utilizado para la confección del Pla Software.
Cuestionario de madurez
¿Las estimaciones (tamaño, costo, cronog documentan para usar en el planeamien del proyecto de software? ¿Los planes de software documentan las ejecutadas y los compromisos hechos?
¿Todos los grupos e individuos acuerdan compromisos relacionados con el proye
¿El proyecto sigue una política organizac planear el proyecto?
Cuestionario de madurez
¿Se proveen recursos adecuados para el planeamie proyecto (fondos, personal con experien
¿Se usan mediciones para determinar el actividades de planeamiento (ejemplo: l completados se comparan con el plan)?
¿El gerente de proyecto revisa las activid planeamiento sobre la base de períodos
Conclusiones Una forma de ocuparnos de la calidad es a través de proceso de desarrollo de software.
Como modelo de madurez y capacidad, CMM represent alternativas mas efectivas y difundidas en todo el mundo par las organizaciones de software en la selección de estrategias mejoramiento de sus procesos de desarrollo.
CMM describe un camino evolutivo de cinco niveles ma cual cada nivel nos indica áreas claves de proceso y nos lle un proceso inicial o ad hoc hasta un proceso maduro o disc
Los principales beneficios que provee son: mejorar la productos, aumentar tiempo de respuesta al mercado e inc la 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
