UNPSJB 2014Ingeniería de Software1 Calidad del Software.

Presentación del tema: "UNPSJB 2014Ingeniería de Software1 Calidad del Software."— Transcripción de la presentación:

1 UNPSJB 2014Ingeniería de Software1 Calidad del Software

2 UNPSJB 2005Ingeniería de Software - Clase 52 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

3 UNPSJB 2005Ingeniería de Software - Clase 53 Bibliografía  Ingeniería de Software (Sommerville)  Ingeniería de Software (Pfleeger)  Página del SEI (CMM) (www.sei.org)  Página de ISO

4 UNPSJB 2005Ingeniería de Software - Clase 54 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)

5 UNPSJB 2005Ingeniería de Software - Clase 55 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

6 UNPSJB 2005Ingeniería de Software - Clase 56 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.

7 UNPSJB 2005Ingeniería de Software - Clase 57 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

8 UNPSJB 2005Ingeniería de Software - Clase 58 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

9 UNPSJB 2005Ingeniería de Software - Clase 59 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

10 UNPSJB 2005Ingeniería de Software - Clase 510 Administración de Calidad  Calidad del proceso y del producto Calidad basada en procesos

11 UNPSJB 2005Ingeniería de Software - Clase 511 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.

12 UNPSJB 2005Ingeniería de Software - Clase 512 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”

13 UNPSJB 2005Ingeniería de Software - Clase 513 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

14 UNPSJB 2005Ingeniería de Software - Clase 514 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).

15 UNPSJB 2005Ingeniería de Software - Clase 515 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

16 UNPSJB 2005Ingeniería de Software - Clase 516 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

17 UNPSJB 2005Ingeniería de Software - Clase 517 Capacidad & Resultados  Madurez de un proceso La medida en la cual un proceso está explícitamente documentado, gestionado, medido, controlado y continuamente mejorado Probabilidad Resultado Probabilidad Resultado Proceso de Baja capacidadProceso de Alta capacidad Resultado podría ser plazo / fit presup / # bugs, etc Proceso maduro tendrá alta capacidad

18 UNPSJB 2005Ingeniería de Software - Clase 518 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.html https://secure.standishgroup.com/reports/reports.php?rid=500

19 UNPSJB 2005Ingeniería de Software - Clase 519 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ños Procesos iterativos haciendo evidentes los requerimientos Project Management conceptualizado y no tomado como una “ciencia oculta” http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish

20 UNPSJB 2005Ingeniería de Software - Clase 520 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 cascada). Productos de software como los Web Services implican una aplicación diferencial de las técnicas.  Aceptación del principio del “No hay balas de plata”

21 UNPSJB 2005Ingeniería de Software - Clase 521 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 (Mejora de Procesos de Software y determinación de la capacidad) – ISO 15504  Tick-It (modelo inglés) programa de certificación de administración de la calidad. CMMI

22 UNPSJB 2005Ingeniería de Software - Clase 522 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

23 UNPSJB 2005Ingeniería de Software - Clase 523 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 Salidas Entran los requerimientos y otras entradas y salen los productos

24 UNPSJB 2005Ingeniería de Software - Clase 524 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 Salidas Reqs.DiseñoCodif.Prueba Existen riesgos al presentarse nuevos desafíos.

25 UNPSJB 2005Ingeniería de Software - Clase 525 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

26 UNPSJB 2005Ingeniería de Software - Clase 526 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 Entradas Salidas Productos y Proceso Gestionados cuantitativamente Reacción frente a las mediciones fuera de rango de control

27 UNPSJB 2005Ingeniería de Software - Clase 527 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 Entradas Salidas Cambio controlado se institucionaliza Foco en la mejora del proceso y tecnología

28 UNPSJB 2005Ingeniería de Software - Clase 528 Areas Clave de Proceso 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 proceso Para cada Area Clave (Key Process Area) está presentada en el modelo de acuerdo a Características Comunes (Common Features), referidas a su institucionalización: compromiso en realizar capacidad de realizar actividades realizadas medición y análisis verificación de implementación

29 UNPSJB 2005Ingeniería de Software - Clase 529 Estructura del modelo CMM Niveles de Madurez Capacidad del proceso indican Areas Clave del Proceso contiene Objetivos logra Características Comunes organizada por Implementación o Institucionalización refiere a Prácticas Clave Infraestructura o actividades describe

30 UNPSJB 2005Ingeniería de Software - Clase 530 Areas Clave del Proceso Nivel CMMArea Clave del Proceso Inicial Ninguna Repetible Gestión de Requerimientos (RM)RM Planificación de Proyecto de Software (SPP)SPP Seguimiento y Supervisión de proyectos de Sw (SPTO)SPTO Gestión de Subcontratos de Sw (SSM)SSM Aseguramiento de la calidad del Sw (SQA)SQA Gestión de la Configuración del Sw (SCM)SCM

31 UNPSJB 2005Ingeniería de Software - Clase 531 Definido Foco en el proceso de la organización (OPF)OPF Definición de los procesos de la organización (OPD)OPD Programa de entrenamiento (TP)TP Gestión de Sw integrada (ISM)ISM Ingeniería de Productos de Sw (SPE)SPE Coordinación entre grupos (IC)IC Revisiones entre pares (PR)PR Gestionado Gestión cuantitativa del proceso (QPM)QPM Gestión de la calidad del software (SQM)SQM Optimizante Prevención de defectos (DP)DP Gestión del cambio tecnológico (TCM)TCM Gestión del cambio del proceso (PCM)PCM Areas Clave del Proceso (II)

32 UNPSJB 2005Ingeniería de Software - Clase 532 SW-CMM- Estructura Aspectos 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

33 UNPSJB 2005Ingeniería de Software - Clase 533 SW-CMM- Estructura Aspectos 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.

34 UNPSJB 2005Ingeniería de Software - Clase 534 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.pdf Ingeniería de Requisitos en aplicaciones Web. SPA. Nora Koch 2003

35 UNPSJB 2005Ingeniería de Software - Clase 535 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

36 UNPSJB 2005Ingeniería de Software - Clase 536 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

37 UNPSJB 2005Ingeniería de Software - Clase 537 Gestión de subcontratistas (SSM) Propósito:  Seleccionar (sub)contratistas calificados y gestionarlos eficazmente Objetivos:  Seleccionar (sub)contratista adecuado  Establecer compromisos  Seguir y revisar su rendimiento y resultados Repetible

38 UNPSJB 2005Ingeniería de Software - Clase 538 Aseguramiento de la Calidad (SQA) Propósito:  Proporcionar visibilidad sobre los procesos utilizados por el proyecto de software y sobre los productos que genera Objetivos:  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

39 UNPSJB 2005Ingeniería de Software - Clase 539 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

40 UNPSJB 2005Ingeniería de Software - Clase 540 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 vida Objetivos:  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.html Software Configuration Management for Open Source Projects

41 UNPSJB 2005Ingeniería de Software - Clase 541 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

42 UNPSJB 2005Ingeniería de Software - Clase 542 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

43 UNPSJB 2005Ingeniería de Software - Clase 543 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

44 UNPSJB 2005Ingeniería de Software - Clase 544 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

45 UNPSJB 2005Ingeniería de Software - Clase 545 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

46 UNPSJB 2005Ingeniería de Software - Clase 546 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

47 UNPSJB 2005Ingeniería de Software - Clase 547 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

48 UNPSJB 2005Ingeniería de Software - Clase 548 Gestión cuantitativa del proceso (QPM) Propósito:  Controlar la ejecución de los proyectos de software de manera cuantitativa Objetivos:  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

49 UNPSJB 2005Ingeniería de Software - Clase 549 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

50 UNPSJB 2005Ingeniería de Software - Clase 550 Prevención de defectos (DP) Propósito:  Identificar las causas de los defectos y eliminarlas para que los defectos no se repitan Objetivos:  Las actividades de prevención de defectos se planifican  Las causas comunes de defectos Se identifican Se priorizan y son eliminadas Optimizante

51 UNPSJB 2005Ingeniería de Software - Clase 551 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

52 UNPSJB 2005Ingeniería de Software - Clase 552 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

53 UNPSJB 2005Ingeniería de Software - Clase 553 SW-CMM Método de Apreciación Como 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 Seleccionar Equipo Cuestionario de Madurez Analizar Respuestas Visitar Organización Hallazgos Identificados Perfil Basado en KPA’s Key Process Area

54 UNPSJB 2005Ingeniería de Software - Clase 554 SW-CMM Método de Apreciación II  2 Métodos Assesment - Evaluación para la mejora del proceso de SF interno Realizada por profesionales del SEI o autorizados Evaluación de la capacidad del sofware Realizada por agentes gubernamentales a contratistas o proveedores de SF Semejante a contratar una consultoría Semejante a una auditoría externa

55 UNPSJB 2005Ingeniería de Software - Clase 555 Caso de Aplicación

56 UNPSJB 2005Ingeniería de Software - Clase 556 Antecedentes de McKesson  McKesson Corporation es el mayor gestión de la oferta de la salud en el mundo y la información sanitaria compañía de tecnología. Fundada en 1833 Ingresos Anuales de $70 billion 25,000 empleados

57 UNPSJB 2005Ingeniería de Software - Clase 557 McKesson Provider Technologies  Una división de McKesson enfocada en proveer soluciones tecnológicas para profesionales de la salud. 1100+ desarrolladores de SW Mas de 100 distintos productos de SW Mas de 20 grupos de desarrollo de software independientes, 15 localidades Nuestros productos están en uso en más de un 50% de todos los hospitales de Estados Unidos

58 UNPSJB 2005Ingeniería de Software - Clase 558 Lineas de Productos  Aplicaciones Clinicas  Sistemas de Información Hopitalarios  Solución de Imagenes  Soluciones médico  Soluciones Web  Cuidado de la Casa  Gestión de Ciclo de Ingresos  Gestión de Recursos  Toma de decisiones  Access Management  Infraestructura

59 UNPSJB 2005Ingeniería de Software - Clase 559 Auditoría de Procesos - marzo 2001  Excesos de presupuesto significativos  No hay previsiones financieras para la mayoría de los planes de negocio  La ausencia de documentación de procesos y estándares de codificación  Mala estimación del esfuerzo y de seguimiento  Poco de requisitos de asignación a las especificaciones técnicas y planes de prueba  Los proyectos no lograron planes  La falta de proceso de aprobación formal de los entregables

60 UNPSJB 2005Ingeniería de Software - Clase 560 Por que CMM?  Los estudios han demostrado que siguiendo CMM lleva a mejoras en: Productividad La detección temprana de defectos Reducción del tiempo de comercialización Reducción de los defectos posteriores a la liberación  Otros Beneficios Minimizar el riesgo a través de una mayor visibilidad a la gestión y el seguimiento Proporciona un marco para la mejora y evaluación objetiva de comparación diferenciador en el mercado

61 UNPSJB 2005Ingeniería de Software - Clase 561 Baselining Process  Llevado a cabo un análisis de brecha basado en CMM en cada sitio de desarrollo 23 nivel 2 realizado evaluaciones de análisis de carencias desde el 4/2002, mediante 3/2004 Grupos de desarrollo local presentó a aspectos específicos de CMM Nivel 2 CBA IPI evaluación informal facilitado por CMM Auditor Líder Proporcionado una base para la planificación de acciones para hacer frente a las lagunas

62 UNPSJB 2005Ingeniería de Software - Clase 562 Descubrimientos - Fortalezas comunes  Horario de Salida Temprana  requisitos documentados  Modelo de desarrollo estándar  manejo de calendario  Reuniones de Estado del proyecto / equipo  CM, de defectos y cambios de herramientas de petición  Función de control de calidad independiente (pruebas)  Proceso de liberación repetible

63 UNPSJB 2005Ingeniería de Software - Clase 563 Descubrimientos - Debilidades comunes  La falta de función de SQA  La estimación del tamaño pequeño o de seguimiento  Esfuerzo seguimiento débil / no granular  La mayoría de los procesos basados ​​ en el "conocimiento tribal“  Compromisos y requisitos flojos gestión del cambio  La falta de planes de desarrollo de SW completos  Pocas medidas del proceso formal

64 UNPSJB 2005Ingeniería de Software - Clase 564 Conclusiones  No hay culturas existentes para la mejora de procesos  Pocos recursos destinados a la mejora de procesos  La falta de comprensión de un verdadero papel de gestión de proyectos  Poco concepto de la gestión del cambio a nivel de empresa  Pocas políticas documentadas, procesos y procedimientos  La fuerte dependencia de los heroicos esfuerzos para el éxito del proyecto

65 UNPSJB 2005Ingeniería de Software - Clase 565 Mejora de Procesos de Estrategia-1  Ciclo de vida de procesos y estándares de producto de grupo Los patrocinadores de la iniciativa CMM La planificación de actividades de MMC / coordinación / entrenamiento  SEPG Corporativa Los representantes de los principales grupos de productos Establece la dirección / prioridad de mejoras en los procesos MPT  McKMAP La página Web corporativa utiliza para compartir activos, procesos e información  Equipo de Desarrollo de Procesos Los representantes de todos los equipos de producto de software En primer lugar un foro de intercambio de información

66 UNPSJB 2005Ingeniería de Software - Clase 566 Mejora de Procesos de Estrategia-2  Cada grupo de desarrollo trabajó en el Nivel 2 "sus propios términos" (por ejemplo, la implementación local) Pros:  Ayuda con bases de buy-in para un programa de SPI corporativa  Asegura un mejor ajuste a los procesos locales para el conocimiento tribal  Espíritu competitivo entre los equipos Crea Momentum Cons:  Los retrasos que abordan la coherencia (por ejemplo, los procesos comunes, roles, herramientas, etc.)  Más difícil para grupos de empresa para supervisar y seguir el progreso de SPI  Perpetúa a "somos diferentes" mentalidad

67 UNPSJB 2005Ingeniería de Software - Clase 567 Cómo se acercó a grupos de nivel 2  La mayoría de los grupos se centraron en la mejora de sus prácticas, no sólo la satisfacción de CMM Simplemente escribieron lo que hacen y CMM utilizan para comprobar si hay agujeros  Algunos grupos adoptaron un enfoque de nivel 3 Algunos arquitectura over-engineering/artificial  Obstáculos más grandes: SQA El tamaño y el esfuerzo de seguimiento de Estimación Planificación de proyectos Robustos

68 UNPSJB 2005Ingeniería de Software - Clase 568 Zonas de Resistencia  Alto nivel de grupo independentista  "No tenemos tiempo para esto proceso. Tenemos un producto para ofrecer ".  CMM fue visto como una iniciativa más de las empresas "de calidad" - destinado al fracaso  El miedo a la comparación con otras unidades de negocio  "MMC no funcionará para nosotros, porque somos diferentes“  "Todos estos procesos se limitan nuestra creatividad"  Auditorías iniciales SQA, tamaño estimar, y SCM vistas como una pérdida de tiempo

69 UNPSJB 2005Ingeniería de Software - Clase 569 Progreso  7 de 21 grupos de desarrollo señaladas en el Nivel 2 CMM  Conocimiento general de la CMM en toda la organización se ha incrementado  Patrocinio Ejecutivo y el buy-in es sólida  La mayoría de los grupos ahora más cierto Siguiendo un modelo de gestión de proyectos (en lugar de un enfoque de "silo")  Establecida en base común que facilita una mejor interacción grupal

70 UNPSJB 2005Ingeniería de Software - Clase 570 Retorno de la Inversión

71 UNPSJB 2005Ingeniería de Software - Clase 571 CMM Retorno de la Inversión  $268,800 - Ahorro Total recuento  $ 34,200 – Reducción total de defectos ahorros  $303,000 – total de ahorros  $115,000 – Inversión Total 2.63 Retorno de la Inversión

72 UNPSJB 2005Ingeniería de Software - Clase 572 Lecciones aprendidas  Establecer patrocinio ejecutivo y el buy-in ASAP (y estar preparado para manejar sus expectativas)  Establecer mecanismos de seguimiento SPI planificación de la acción en la delantera  Evitar el establecimiento de metas hasta que haya fecha de línea base  Hay ventajas y desventajas en sus propios grupos que permitiera definir procesos - asegúrese de que puede vivir con las consecuencias importantes  Asegúrese de que la atención se centra en la mejora verdadera - no en perseguir a un nivel CMM  Tenga cuidado de cómo se utilizan los incentivos  Habrá resistencia - estar preparado para hacerle frente

73 UNPSJB 2005Ingeniería de Software - Clase 573 Como administrar todos estos flujos de información? Herramientas auxiliares

74 UNPSJB 2005Ingeniería de Software - Clase 574  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 Requirements (RM) Rational Rose Clear Quest Clear Case (SCM)

75 UNPSJB 2005Ingeniería de Software - Clase 575 Estadísticas

76 UNPSJB 2005Ingeniería de Software - Clase 576  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 meses Nivel 2 al 3: 19 meses Nivel 3 al 4: 25 meses Nivel 4 al 5: 13 meses 1992 Nivel de Adopción

77 UNPSJB 2005Ingeniería de Software - Clase 577  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 / Costos Estudio Primeros 3 Niveles

78 UNPSJB 2005Ingeniería de Software - Clase 578 Críticas al Modelo

79 UNPSJB 2005Ingeniería de Software - Clase 579  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-CMM

80 UNPSJB 2005Ingeniería de Software - Clase 580 Evolución del Modelo

81 UNPSJB 2005Ingeniería de Software - Clase 581 Evolución. CMM-I (Integrated). CMMI consiste en un conjunto de “mejores prácticas” ProductosServicios 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