Post on 19-Sep-2018
UNPSJB 2005 Ingeniería de Software - Clase 5 1
Ingeniería de SoftwareClase 5
Calidad
UNPSJB 2005 Ingeniería de Software - Clase 5 2
Glosario de la Clase
Objetivos Administración de la calidad
Aseguramiento y estándares de calidad Planeación de la calidad Control de calidad
Proceso del software Normas
ISO CMM
UNPSJB 2005 Ingeniería de Software - Clase 5 3
Bibliografía
Ingeniería de Software (Sommerville)
Ingeniería de Software (Pfleeger) Página del SEI (CMM) (www.sei.org) Página de ISO Material del CD.
UNPSJB 2005 Ingeniería de Software - Clase 5 4
Administración de Calidad
Calidad concepto presente en el mundo globalizado Como se aplica en IS?
Definiendo calidad: “el producto desarrollado cumple su
especificación” (Crosby, 1979)
UNPSJB 2005 Ingeniería de Software - Clase 5 5
Administración de Calidad Como se aplica a la IS? problemas
La especificación se orienta hacia las características del producto que el consumidor quiere, pero la organización tiene requerimientos que no se incluyen en la especificación (ej. Mantenimiento)
No se sabe como especificar ciertas características de calidad de una forma no ambigua
En IR es muy difícil redactar especificaciones concretas del software. Por esto aunque el producto esté acorde con la especificación, los usuarios no lo consideran un producto de alta calidad
UNPSJB 2005 Ingeniería de Software - Clase 5 6
Administración de Calidad
Tres actividades principales Aseguramiento de calidad
Establecer un marco de trabajo de procedimientos y estándares organizacionales que conduce a software de alta calidad
Planeación de la calidad: la selección de procedimientos y estándares adecuados a partir de este marco de trabajo y la adaptación de éstos para un proyecto específico.
Control de calidad: definición y promulgación de los procesos que aseguran que los procedimientos y estándares para la calidad del proyecto son seguidos por el equipo de desarrollo de software.
UNPSJB 2005 Ingeniería de Software - Clase 5 7
Administración de Calidad
Administración de calidad proceso de desarrollo del soft Tareas independientes El resultado del proceso de desarrollo
se introduce en el proceso de administración de la calidad
Cuales son los procesos de adm.? ISO 9000 CMM
UNPSJB 2005 Ingeniería de Software - Clase 5 8
Administración de Calidad
Actividades para QA (aseguramiento de calidad) Estándares
Del producto: se aplican sobre el elemento a desarrollar. Se incluye
Estándares de documentos Estructuras del documento de requerimiento Estándares de codificación, etc.
Del proceso: definen los procesos a seguir durante el desarrollo del soft. Incluyen
Procesos de especificación, diseño y validación Documentación asociada con lo anterior
UNPSJB 2005 Ingeniería de Software - Clase 5 9
Administración de Calidad
Estándares de documentación Son la única forma tangible de representar al
software y al proceso de software. Tres tipos de estándares
Del proceso de documentación: define el proceso a seguir para la producción del documento
Del documento: gobierna la estructura y presentación de documentos
Para intercambio de documentos: asegura-miento que las copias electrónicas sean compatibles
UNPSJB 2005 Ingeniería de Software - Clase 5 10
Administración de Calidad
Calidad del proceso y del producto
Calidad basada en procesos
Definir proceso
Estandarizar proceso
Validar la calidad del producto
Mejorar Proceso
Desarrollar producto
Calidad OK SiNo
UNPSJB 2005 Ingeniería de Software - Clase 5 11
Administración de Calidad
El dibujo anterior se aplica en producción manufacturera
Como llevarlo a la producción del software? Es difícil medir atributos del software sin
utilizarlo mucho tiempo Mejorar la calidad se centra en
Identificar buenos productos de calidad Examinar el proceso usado para su desarrollo Generalizar el proceso para aplicarlo en varios
proyectos.
UNPSJB 2005 Ingeniería de Software - Clase 5 12
Administración de Calidad Inconvenientes
La relación proceso del software y calidad del producto es compleja.
Cambiar el proceso no siempre conduce a mejorar calidad del producto
Recordar análisis de riesgo. Planificación de calidad
Se inicia en las primeras etapas del proceso del software.
Un plan de calidad define la calidad del producto deseado Como valorar esta calidad Lo que significa el software de “alta calidad”
UNPSJB 2005 Ingeniería de Software - Clase 5 13
Administración de Calidad
Un plan de calidad selecciona los estándares
organizacionales apropiados para un producto.
Un proceso de desarrollo Un plan comprende
Introducción al producto Descripción del mismo, el
mercado a donde está dirigido y las espectativas de calidad
Planes de producto Fechas de terminación y
responsabilidades importantes
Descripción del proceso De desarrollo y de
servicio a utilizar para el desarrollo y administración del producto
Metas de calidad Metas y planes de
calidad previstos Riesgo y administración
del riesgo
UNPSJB 2005 Ingeniería de Software - Clase 5 14
Administración de Calidad
Control de calidad Vigilar el proceso de desarrollo del software
para asegurar que se sigan los procedimientos de aseguramiento y estándares de calidad.
Dos enfoques Revisiones de calidad (se evalúa soft,
documentación y procesos utilizados) Valoración automática del soft (el soft y
documentos producidos se procesan por algún programa y se comparan contra estándares que se aplican a ese proyecto en particular).
UNPSJB 2005 Ingeniería de Software - Clase 5 15
Proceso de Software. Definición.
Actividades, métodos y prácticas para desarrollar y mantener software y sus productos asociados.
Procedimientos & Métodos
Proceso
Gente. Habilidades & Motivación Herramientas
& Equipamiento
UNPSJB 2005 Ingeniería de Software - Clase 5 16
Proceso. Aspectos Generales.
Capacidad: Rango de resultados que pueden ser alcanzados siguiendo un proceso inicialmente establecido a nivel de organización.
Performance / Desempeño: medida de los resultados reales alcanzados. Se aplica a un proyecto en particular de la organización.
Suele ser <> por cada ejecución del proceso
Es lo que se intenta predecir y controlar
UNPSJB 2005 Ingeniería de Software - Clase 5 17
Capacidad & Resultados
Madurez de un proceso La medida en la cual un proceso está
explícitamente documentado, gestionado, medido, controlado y continuamente mejorado
Prob
abili
dad
Resultado
Prob
abili
dad
Resultado
Proceso de Baja capacidad Proceso de Alta capacidad
Resultado podría ser plazo / fit presup / # bugs, etc
Proceso maduro tendrá alta capacidad
UNPSJB 2005 Ingeniería de Software - Clase 5 18
Crisis del software (I)
Concreción del proyecto: 31% son cancelados antes de la finalización
Costo +50% han costado el doble de lo estimado
originalmente. Calidad
En mediciones actuales se estima la existencia de 50 errores/1000 lineas de código
http://www.costxpert.com/resource_center/disaster_as_opportunity.htmlhttps://secure.standishgroup.com/reports/reports.php?rid=500
UNPSJB 2005 Ingeniería de Software - Clase 5 19
Crisis del software (II)
Standish Group 2004 Proyectos de IT han mejorado su “tasa de éxito”
un 34%. Mejora del 100% en comparación con 1994. Tasa de fallos -15%. Problema de costos promedio 43%
Proyectos mas pequeñosProcesos iterativos haciendoevidentes los requerimientos
Project Managementconceptualizado y no tomado como una “ciencia oculta”
http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish
UNPSJB 2005 Ingeniería de Software - Clase 5 20
Contexto. Realidad del Software
Necesidad de software cada vez mas complejo & crítico.
La producción de software es una actividad creativa e intelectual realizada por seres humanos. Técnicas de Ingeniería de software acompañadas por sentido común, Competencia y Experiencia.
Técnicas de Ingeniería de software en re-evaluación (Método iterativo vs waterfall). Productos de software como los Web Services implican una aplicación diferencial de las técnicas.
Aceptación del ppio del “No Silver Bullet”
UNPSJB 2005 Ingeniería de Software - Clase 5 21
Modelos de Proceso y de su Capacidad
CMM (Capability Maturity Model) Desarrollado por SEI (Software Engineering Institute),
org. creado por el DoD de USA Fuerte impacto en mejora del proceso Estipula un Camino para la mejora Areas Clave que se deben atacar
ISO 12207 – Modelos de Ciclos de Vida del Software Actividades que debe incluir
SPICE (Software Process Improvement and Capability dEtermination) – ISO 15504
Tick-It (modelo inglés)
CMMICMMI
UNPSJB 2005 Ingeniería de Software - Clase 5 22
UNPSJB 2005 Ingeniería de Software - Clase 5 23
CMM SW v1.1(Capability Maturity Model)
Nivel 1:Inicial
Nivel 2:Repetible
Nivel 3:Definido
Nivel 4:Gestionado
Nivel 5:Optimizante
Gestión del Cambio
Gestión Cuantitativa
Gestión de Ingeniería
Gestión del Proyecto
Disciplina del Proceso
Definición del Proceso
Control del proceso
Mejora continua del proceso
Madurez
UNPSJB 2005 Ingeniería de Software - Clase 5 24
Nivel 1 - Inicial
Desempeño basado en la competencia del personal frecuentemente la organización vive apagando incendios aparecen héroes dificultad para encarar mejoras a largo plazo la organización actúa esencialmente por reacción
Promueve alta calidad y desempeño excepcional, posible siempre que se logre contar con los mejores
Impredecible (para bien y para mal) Caracterizado por problemas que son esencialmente de gestión, no
técnicos
Entradas
SalidasEntran los requerimientos y otras entradas y salen los productos
UNPSJB 2005 Ingeniería de Software - Clase 5 25
Nivel 2 - Repetible
La organización estableció la gestión efectiva de los proyectos de software el proceso de gestión del software está documentado usa políticas organizacionales para guiar a los proyectos en
establecer los procesos de gestión repite prácticas exitosas desarrolladas en proyectos previos
Entradas SalidasReqs. Diseño Codif. Prueba
Existen riesgos al presentarse nuevos desafíos.
UNPSJB 2005 Ingeniería de Software - Clase 5 26
Nivel 3 - Definido
El proceso para la gestión y las actividades de ingeniería está documentado e integrado en un proceso estándar para la organización.
Todos los proyectos usan una versión documentada y aprobada del proceso estándar de la organización.
Una task force dedicada al proceso de Ingeniería de software ha sido establecido para focalizar y liderar esfuerzos en la mejora.
Entradas Salidas
UNPSJB 2005 Ingeniería de Software - Clase 5 27
Nivel 4 - Gestionado
La organización aplica los principios de la gestión estadística de procesos para
controlar el proceso del software la dirección tiene bases objetivas para tomar decisiones, puede predecir el desempeño en un entorno cuantificado
realista usa los datos como base para decisiones, objetivos y mejoras
EntradasSalidas
Productos y Proceso Gestionados cuantitativamente
Reacción frente a las mediciones fuera de rango de control
UNPSJB 2005 Ingeniería de Software - Clase 5 28
Nivel 5 - Optimizante
La organización identifica y elimina causas de desempeño pobre mejora continua del proceso en base a gestión del cambio
del proceso y de la tecnología
EntradasSalidas
Cambio controlado se institucionaliza
Foco en la mejora del proceso y tecnología
UNPSJB 2005 Ingeniería de Software - Clase 5 29
Areas Clave de Proceso
conjunto de actividades relacionadas conjunto de actividades relacionadas tales que cuando se llevan a cabo, se logran un
conjunto de objetivos Estos objetivos son considerados importantes para
mejorar la capacidad del procesoPara cada Area Clave (Key Process Area) está Para cada Area Clave (Key Process Area) está
presentada en el modelo de acuerdo a presentada en el modelo de acuerdo a Características Comunes (Common Features), Características Comunes (Common Features), referidas a su institucionalización:referidas a su institucionalización: compromiso en realizar capacidad de realizar actividades realizadas medición y análisis verificación de implementación
UNPSJB 2005 Ingeniería de Software - Clase 5 30
Estructura del modelo CMMNiveles de Madurez
Capacidad del proceso
indican
Areas Clave del Proceso
contiene
Objetivos
logra
Características Comunes
organizada por
Implementación o Institucionalización
refiere aPrácticas Clave
Infraestructura o actividadesdescribe
UNPSJB 2005 Ingeniería de Software - Clase 5 31
Areas Clave del Proceso
Nivel CMM Area Clave del Proceso
Inicial NingunaRepetible Gestión de Requerimientos (RM)
Planificación de Proyecto de Software (SPP)Seguimiento y Supervisión de proyectos de Sw (SPTO)Gestión de Subcontratos de Sw (SSM)Aseguramiento de la calidad del Sw (SQA)Gestión de la Configuración del Sw (SCM)
UNPSJB 2005 Ingeniería de Software - Clase 5 32
Definido Foco en el proceso de la organización (OPF)Definición de los procesos de la organización (OPD)Programa de entrenamiento (TP)Gestión de Sw integrada (ISM)Ingeniería de Productos de Sw (SPE)Coordinación entre grupos (IC)Revisiones entre pares (PR)
Gestionado Gestión cuantitativa del proceso (QPM)Gestión de la calidad del software (SQM)
Optimizante Prevención de defectos (DP)Gestión del cambio tecnológico (TCM)Gestión del cambio del proceso (PCM)
Areas Clave del Proceso (II)
UNPSJB 2005 Ingeniería de Software - Clase 5 33
SW-CMM- EstructuraAspectos Comunes
Compromiso para la ejecución: acciones que la organización debe llevar a cabo para establecer el proceso y que perdure. Políticas y liderazgos corporativos.
Habilidad para ejecutar: precondiciones para ejecutar el proceso competentemente. Entrenamiento, estructura y recursos
Atributos que permiten que la implementación o institucionalización de un área clave sea efectiva, repetible y perdurable
UNPSJB 2005 Ingeniería de Software - Clase 5 34
SW-CMM- EstructuraAspectos Comunes (II)
Actividades a ejecutar: Comprende actividades, roles y procedimientos para implementar un área clave.
Mediciones y análisis: Describe las prácticas de medición necesarias para determinar el estado del proceso.
Verificación de la implementación: Describe los pasos para asegurar que las actividades son llevadas a cabo de acuerdo al proceso establecido. Incluye revisiones & auditorías.
UNPSJB 2005 Ingeniería de Software - Clase 5 35
Gestión de Requerimientos (RM)
Propósito: Establecer un entendimiento común entre el cliente y el
equipo de proyecto sobre los requerimientos del cliente que deben tenerse en cuenta
Objetivos: Documentar requerimientos como base del proyecto Gestionar y controlar los cambios que se hacen a los
requerimientos durante todo el ciclo de vida del proyecto
Repetible
http://www.pst.informatik.uni-muenchen.de/personen/kochn/ideas03-escalona-koch.pdfIngeniería de Requisitos en aplicaciones Web. SPA. Nora Koch 2003
UNPSJB 2005 Ingeniería de Software - Clase 5 36
Planificación del proyecto (SPP)
Propósito: Establecer planes razonables para realizar las
actividades de ingeniería de software y para gestionar el proyecto
Objetivos: Hacer estimaciones del trabajo a realizar Establecer los compromisos para realizar el trabajo Definir los planes para ejecutar el trabajo
Repetible
UNPSJB 2005 Ingeniería de Software - Clase 5 37
Seguimiento de proyectos (SPTO)
Propósito: Supervisar el progreso real del proyecto para tomar
acciones a tiempo cuando el rendimiento del proyecto se desvía significativamente de lo planificado
Objetivos: Seguir y revisar el progreso del proyecto en comparación
con las estimaciones y los planes Tomar acciones correctivas cuando surjan discrepancias
entre las estimaciones y los valores reales para reconducir el proyecto
Re-establecer compromisos
Repetible
UNPSJB 2005 Ingeniería de Software - Clase 5 38
Gestión de subcontratistas (SSM)
Propósito: Seleccionar (sub)contratistas calificados y
gestionarlos eficazmenteObjetivos: Seleccionar (sub)contratista adecuado Establecer compromisos Seguir y revisar su rendimiento y resultados
Repetible
UNPSJB 2005 Ingeniería de Software - Clase 5 39
Aseguramiento de la Calidad (SQA)
Propósito: Proporcionar visibilidad sobre los procesos utilizados por el
proyecto de software y sobre los productos que generaObjetivos: Planificar las actividades de aseguramiento de la calidad Revisar y auditar objetivamente los productos y las
actividades para verificar que están conformes con los procedimientos y estándares aplicables
Proporcionar los resultados de estas revisiones o auditorías informando a la dirección cuando sea necesaria su mediación
Repetible
UNPSJB 2005 Ingeniería de Software - Clase 5 40
Aseguramiento de la Calidad (II)
El grupo encargado del aseguramiento de la calidad del software: Deberá trabajar con el equipo del proyecto desde el
principio Deberá ser objetivo y, a ser posible, independiente Deberá ayudar al proyecto más que controlar sus
actividades
Repetible
UNPSJB 2005 Ingeniería de Software - Clase 5 41
Gestión de configuración del sw (SCM)
Propósito: Establecer y mantener la integridad de todos los productos
del proyecto a lo largo de todo el ciclo de vidaObjetivos: Planificar las actividades de gestión de la configuración Identificar los elementos de configuración del software Controlar los cambios hechos a los elementos de
configuración para mantener su integridad y trazabilidad Construir las versiones del producto final
Repetible
http://www.ibiblio.org/gferg/ldp/SCM-OpenSource/index.htmlSoftware Configuration Management for Open Source Projects
UNPSJB 2005 Ingeniería de Software - Clase 5 42
Foco en el Proceso de la Org. (OPF)
Propósito: Definir una responsabilidad a nivel de la organización para
las actividades relacionadas con el proceso de software y su mejora
Objetivos: SPI (Software Process Improvement) se coordina en toda la
organización SPI se planifica Los fortalezas y debilidades de los procesos utilizados se
identifican con respecto a un estándar
Definido
UNPSJB 2005 Ingeniería de Software - Clase 5 43
Definición del Proceso de la Org. (OPD)
Propósito: Desarrollar y mantener un conjunto de procesos de
software con el objetivo de establecer una base de referencia a partir de la cual se mejoren paulatinamente los procesos y los resultados de dichos procesos
Objetivos: Desarrollo y mantenimiento de un proceso estándar para la
organización Se recolecta, revisa y divulga información relacionada con
el uso del proceso estándar de la organización por parte de los proyectos
Definido
UNPSJB 2005 Ingeniería de Software - Clase 5 44
Programa de entrenamiento (TP)
Propósito: Desarrollar las capacidades y conocimiento de los
individuos para que puedan desempeñar sus roles de manera eficiente y efectiva
Objetivos: La formación y entrenamiento se planifican Y se imparte, cubriendo las necesidades de los diferentes
roles (aspectos de gestión y técnicos)
Definido
UNPSJB 2005 Ingeniería de Software - Clase 5 45
Gestión Integrada del Software (ISM)
Propósito: Integrar las actividades de ingeniería y de gestión de
software en un proceso coherente y definido, adaptado a las necesidades específicas de cada proyecto
Objetivos: El proceso definido para el proyecto es una versión
ajustada del proceso estándar de la organización El proyecto se planifica y gestiona de acuerdo al proceso
definido para el proyecto
Definido
UNPSJB 2005 Ingeniería de Software - Clase 5 46
Ingeniería del producto de sw (SPE)
Propósito: Ejecutar un proceso de ingeniería bien definido y
coherente integrando todas las actividades de ingeniería de software para producir productos de software correctos y consistentes de manera eficiente y efectiva
Objetivos: Las actividades de Ing.de SW están definidas,
integradas y se ejecutan de forma consistente para producir el software
Los entregables se mantienen consistentes entre ellos
Definido
UNPSJB 2005 Ingeniería de Software - Clase 5 47
Coordinación entre grupos (IC)
Propósito: Establecer los medios para que el grupo de Ingeniería de
Software participe activamente con los otros grupos de ingeniería para que las necesidades del cliente se satisfagan de manera efectiva y eficiente
Objetivos: Los requerimientos del cliente son aprobados por todos
los grupos afectados Los compromisos entre los grupos de ingeniería cuentan
con la aprobación de los grupos afectados Los grupos de ingeniería identifican y resuelven
problemas entre los grupos
Definido
UNPSJB 2005 Ingeniería de Software - Clase 5 48
Revisiones por pares (PR)
Propósito: Remover los defectos de los productos de software
eficientemente en una etapa temprana y conseguir una mejor comprensión del producto que se está desarrollando y de su calidad en términos de los defectos que presenta
Objetivos: Revisiones por pares son planificadas Los defectos son detectados y removidos
Definido
UNPSJB 2005 Ingeniería de Software - Clase 5 49
Gestión cuantitativa del proceso (QPM)
Propósito: Controlar la ejecución de los proyectos de software de
manera cuantitativaObjetivos: Las actividades de QPM se planifican El desempeño del proceso del proceso definido para el
proyecto es controlado cuantitativamente La capacidad del proceso de software estándar de la
organización es conocido en términos cuantitativos
Gestionado
UNPSJB 2005 Ingeniería de Software - Clase 5 50
Gestión de la calidad del sw (SQM)
Propósito: Desarrollar un conocimiento cuantitativo de la calidad
de los productos de software y conseguir alcanzar determinados objetivos de calidad
Objetivos: Se planifica SQM de los proyectos Se definen objetivos medibles para la calidad de los
productos de software y sus prioridades El progreso real hacia el logro de los objetivos de
calidad para los productos de software se cuantifican y gestionan
Gestionado
UNPSJB 2005 Ingeniería de Software - Clase 5 51
Prevención de defectos (DP)
Propósito: Identificar las causas de los defectos y eliminarlas para
que los defectos no se repitanObjetivos: Las actividades de prevención de defectos se planifican Las causas comunes de defectos
Se identifican Se priorizan y son eliminadas
Optimizante
UNPSJB 2005 Ingeniería de Software - Clase 5 52
Gestión del cambio tecnológico (TCM)
Propósito: Identificar nuevas tecnologías (herramientas,
métodos, procesos, etc.) y transferirlos a la organización de una manera ordenada
Objetivos: La incorporación de cambios tecnológicos es
planificada Las nuevas tecnologías se evalúan para identificar su
impacto sobre la calidad y productividad Nuevas tecnologías apropiadas son transferidas a la
práctica normal en la organización
Optimizante
UNPSJB 2005 Ingeniería de Software - Clase 5 53
Gestión del cambio del proceso (PCM)
Propósito: Mejorar continuamente el proceso de software usado en la
organización con la intención de mejorar la calidad del software, aumentar la productividad y reducir los tiempos de desarrollo
Objetivos: La mejora continua del proceso es planificada La participación en las actividades de mejora del proceso
de software abarca a toda la organización
Optimizante
UNPSJB 2005 Ingeniería de Software - Clase 5 54
SW-CMM Método de ApreciaciónComo se empieza?
Tiene como objetivo determinar y evaluar la capacidad y madurez de una organización y ubicarlo en un nivel del SW-CMM
Consiste en 6 pasos
SeleccionarEquipo
Cuestionario de Madurez
AnalizarRespuestas
VisitarOrganización
HallazgosIdentificados
PerfilBasado en
KPA’sKey Process Area
UNPSJB 2005 Ingeniería de Software - Clase 5 55
SW-CMM Método de Apreciación II
2 Métodos
Assesment - Evaluación para la Assesment - Evaluación para la mejora del proceso de SF mejora del proceso de SF
internointernoRealizada por profesionales del SEI o autorizados
Evaluación de la capacidad del Evaluación de la capacidad del sofwaresofwareRealizada por agentes
gubernamentales a contratistas o proveedores de SF
Semejante a contratar una consultoría
Semejante a una auditoría externa
UNPSJB 2005 Ingeniería de Software - Clase 5 56
Caso de Aplicación
UNPSJB 2005 Ingeniería de Software - Clase 5 57
McKesson Background
McKesson Corporation is the world's largest healthcare supply management and healthcare information technology company. Founded in 1833 Annual revenue $70 billion 25,000 employees
UNPSJB 2005 Ingeniería de Software - Clase 5 58
McKesson Provider Technologies
A division of McKesson focused on providing technology solutions to healthcare providers 1100+ software developers Over 100 distinct software products Over 20 separate software
development groups, 15 locations Our products are in use in over 50% of
all US hospitals
UNPSJB 2005 Ingeniería de Software - Clase 5 59
Product Lines Clinical Applications Hospital Information Systems Imaging Solutions Physician Solutions Web Solutions Homecare Revenue Cycle Management Resource Management Decision Support Access Management Infrastructure
UNPSJB 2005 Ingeniería de Software - Clase 5 60
Process Audit - March 2001
Significant budget overruns No financial forecasts for most business plans Absence of process documentation and coding
standards Poor effort estimation and tracking Little mapping of requirements to technical
specifications and test plans Projects not managed to plans Lack of formal approval process for deliverables
UNPSJB 2005 Ingeniería de Software - Clase 5 61
Why CMM? Studies have shown following CMM leads to
improvements in: Productivity Early detection of defects Reduction in time to market Reduction in post-release defects
Other benefits Minimize risk through increased management
visibility and tracking Provides a framework for improvement and objective
assessment/comparison Market differentiator
UNPSJB 2005 Ingeniería de Software - Clase 5 62
Baselining Process
Conducted a CMM-based gap analysis at each development site 23 level 2 gap analysis assessments
conducted from 4/2002 through 3/2004 Introduced local development groups to
specifics of CMM Level 2 CBA IPI informal assessment facilitated by a
CMM Lead Assessor Provided a foundation for action planning to
address the gaps
UNPSJB 2005 Ingeniería de Software - Clase 5 63
Findings - Common Strengths
Early release planning Documented requirements Standard development model Schedule management Project status/team meetings CM, defect and change request tools Separate quality control (testing) function Repeatable release process
UNPSJB 2005 Ingeniería de Software - Clase 5 64
Findings - Common Weaknesses
Lack of SQA function Little size estimation or tracking Effort tracking weak/not granular Most processes based on “tribal knowledge” Loose commitments & requirements change
management Lack of complete SW development plans Few formal process measurements
UNPSJB 2005 Ingeniería de Software - Clase 5 65
Conclusions
No existing culture for process improvement Few resources devoted to process improvement Lack of understanding of a true project management role Little concept of managing change at the enterprise
level Few documented policies, processes, and procedures Heavy reliance on heroic efforts for project success
UNPSJB 2005 Ingeniería de Software - Clase 5 66
Process Improvement Strategy-1
Product Lifecycle Process & Standards group Sponsors of the CMM initiative CMM activities planning/coordination/coaching
Corporate SEPG Representatives from our leading product groups Sets the direction/priority for MPT process improvements
McKMAP Corporate web site used to share assets, processes and
information Development Process Team
Representatives from all software product teams Primarily an information sharing forum
UNPSJB 2005 Ingeniería de Software - Clase 5 67
Process Improvement Strategy-2 Each development group worked Level 2 on “their
own terms” (e.g., local implementation) Pros:
Helps with grass roots buy-in to a corporate SPI program Ensures better fit to local processes to tribal knowledge Competitive spirit between teams creates momentum
Cons: Delays addressing consistency (e.g., common processes,
roles, tools, etc.) Harder for corporate group to oversee and track SPI
progress Perpetuates a “we’re different” mentality
UNPSJB 2005 Ingeniería de Software - Clase 5 68
How Groups Approached Level 2
Most groups focused on improving their practices, not just satisfying CMM Simply wrote down what they do and used CMM to
check for holes A few groups took a Level 3 approach
Some over-engineering/artificial architecture Biggest hurdles:
SQA Size Estimation and Effort tracking Robust project planning
UNPSJB 2005 Ingeniería de Software - Clase 5 69
Areas of Resistance
High level of group independence “We don’t have time for this process stuff. We have a
product to deliver.” CMM was viewed as yet another corporate “quality”
initiative – doomed to failure Fear of comparison to other business units “CMM won’t work for us because we’re different” “All these processes will limit our creativity” SQA, size estimating, and SCM baseline audits viewed as
a waste of time
UNPSJB 2005 Ingeniería de Software - Clase 5 70
Progress
7 of 21 development groups assessed at CMM Level 2 General awareness of CMM across the organization has
increased Executive sponsorship and buy-in is solid Most groups now following a truer project management
model (rather than a “silo” approach) Established a common foundation that facilitates better
group interaction
UNPSJB 2005 Ingeniería de Software - Clase 5 71
Return on Investment
FY03Q1
FY03Q2
FY03Q3
FY03Q4
FY04Q1
FY04Q2
FY04Q3
FY04Q4
Level 1-
50
100
150
200
250
300
350
400
Maintenance Revenue per FTE
Level 1 Level 2
UNPSJB 2005 Ingeniería de Software - Clase 5 72
CMM Return on Investment $268,800 - Total Head Count Savings $ 34,200 – Total Defect Reduction
Savings $303,000 – Total Savings
$115,000 – Total Investment
2.63 Return on Investment
UNPSJB 2005 Ingeniería de Software - Clase 5 73
Lessons Learned
Establish executive sponsorship and buy-in ASAP (and be ready to manage their expectations)
Establish SPI action planning tracking mechanisms up front Avoid goal-setting until AFTER you have baselined data There are trade-offs in allowing groups to define their own
processes – be sure you can live with the consequences Make sure the focus is on true improvement – not on
chasing a CMM level Be careful how incentives are used There will be resistance - be prepared to address it
UNPSJB 2005 Ingeniería de Software - Clase 5 74
Como administrar todos estos flujos de información?
Herramientas auxiliares
UNPSJB 2005 Ingeniería de Software - Clase 5 75
Conjunto de “artefactos” compuestos por metodologías y herramientas de software que permiten administrar la información generada por la implementación de CMM en los niveles 2 y 3.
Rational Rose - Rational Unified Process (RUP)Rational Rose - Rational Unified Process (RUP)
Rational Requirements (RM)
Rational Rose
Clear Quest
Clear Case (SCM)
UNPSJB 2005 Ingeniería de Software - Clase 5 76
Estadísticas
UNPSJB 2005 Ingeniería de Software - Clase 5 77
1996: Cerca del 70% en Nivel 1 y 18 % en Nivel 2. 0.4% en Nivel 5.
1999: 12.3 en Nivel 1, 43.3% en Nivel 2 y cerca del 10% en Nivel 5.
Tiempos:
Nivel 1 al 2: 22 mesesNivel 2 al 3: 19 mesesNivel 3 al 4: 25 mesesNivel 4 al 5: 13 meses
1992
Nivel de AdopciónNivel de Adopción
UNPSJB 2005 Ingeniería de Software - Clase 5 78
Inversión aproximada: U$D 1.400 por año por Ingeniero de Software.
Reducción de Defectos Post-Release: 39% por año. Productividad ganada: 35% por año. Mejoras sensibles
Cronogramas y presupuestos. Calidad del producto.
Productividad / CostosProductividad / Costos
EstudioPrimeros 3Niveles
UNPSJB 2005 Ingeniería de Software - Clase 5 79
Críticas al Modelo
UNPSJB 2005 Ingeniería de Software - Clase 5 80
Preguntas habitualmente usadas en el cuestionario son binarias (Si/No), impidiendo reflejar matices de la realidad.
El modelo es solo aplicable a grandes organizaciones que desarrollan grandes proyectos.
El modelo permite comparar procesos de software de grandes organizaciones con los de pequeñas organizaciones, favoreciendo a las primeras.
La aplicación del modelo requiere de inversiones importantes. Convierte a la organizaciónen algo rígido, burocrático y menos capaz de aplicar soluciones creativas.
El Nivel 1 es una gran “bolsa” en el que se ubican organizaciones con nivel de madurez distinto.
Los niveles de madurez no garantizan el éxito: Proyectos exitosos en Nivel 1 y fracasados en Nivel 5.
Críticas Usuales al modelo SW-CMMCríticas Usuales al modelo SW-CMM
UNPSJB 2005 Ingeniería de Software - Clase 5 81
Evolución del Modelo
UNPSJB 2005 Ingeniería de Software - Clase 5 82
Evolución. CMM-I (Integrated).
CMMI consiste en un conjunto de “mejores prácticas”
Productos Servicios
Integra cuerpos de conocimiento /disciplinas que han sido abordadas en forma separada.
Ingeniería de Sistemas (SE)
Ingeniería de Software(SW)
Desarrollo de Procesos y Productos Integrados (IPPD)
Fuente(s) Proveedora(s) (SS)
Disciplina Objetivo
SW-CMM 2.0 SE-CMM
IPD-CMM