CALIDAD EN EL DESARROLLO DE SOFTWARE

Transcripción

1 IESE C CALIDAD EN EL DESARROLLO DE SOFTWARE MODELADO DE SISTEMAS LETICIA ESTRADA GONZÁLEZ 2012 T E M A 5

2 Tabla de contenido Introducción... 3 Por qué es necesaria la calidad?... 3 Definición de calidad/calidad de software... 3 Modelos ISO Modelo ISO Modelo ISO 9001/ Secciones de la Norma ISO Modelo ISO 15504/SPICE Dimensión del proceso: CUS Cliente-Proveedor Dimensión de capacidad CMM-CMMI El nacimiento de CMM - CMMI Qué es el CMM - CMMI? Niveles CMM - CMMI Modelo MOPROSOFT Características Niveles de MOPROSOFT

3 Introducción Existe una constante preocupación de los investigadores tecnológicos en lo referente a la calidad de sus productos. Es necesario que cuenten con lineamientos y herramientas de apoyo necesarios para disminuir este problema y así poder liberar sus trabajos sin ninguna preocupación. Por qué es necesaria la calidad? Porque la competencia es cada mayor, por eso necesario que las empresas se preocupen por dar un mejor producto, pero la calidad de un producto no solo se mide al terminarlo. Hoy en día las necesidades de buscar una solución a problemas complejos en el software ha ocasionado que las empresas dedicadas al desarrollo o mantenimiento de software sean rebasadas, es decir que no sean capaces de desarrollar o entregar un software confiable, a tiempo y apegado al presupuesto acordado con el cliente y de que el cliente confié que todo lo anterior se cumplirá. Por esto las organizaciones deben buscar una norma, estándar o modelo que pueda ayudarlas a ser competitivas o llegar a la calidad. En este modulo estableceremos los conceptos que son necesarios para que un proyecto de software se considere que cumple con los requerimientos establecidos por el cliente o stakeholder o sea de calidad. Definición de calidad/calidad de software En recientes años surgió la moda por la calidad en todas las áreas productivas de los países, y según Joseph Juran, algunos han buscado realizar nuevos esquemas de calidad sofisticados después del surgimiento de estándar ISO-9000, en esa loca carrera han surgido estándares mediocres, puesto que la calidad esta en movimiento, y no debe comenzarse un nuevo estándar de cero. Juran dice que calidad consiste en esas características del producto que satisfacen con las necesidades de los clientes, es decir la satisfacción del producto. Calidad consiste en un producto libre de fallas. Philip Crosby quien desarrollo conceptos de administración de la calidad y cuyas influencias se encuentran en el estándar de calidad ISO9000:2000 que difiere del 1994 en el contexto de cada uno de sus 8 principios, define calidad como el ajuste a los requerimientos y cero defectos. ISO 9000 define calidad como la totalidad de las características de una entidad que soportan su disponibilidad para satisfacer las necesidades que el cliente estableció como requerimientos en un contrato o las necesidades que la compañía 3

4 que provee el producto identifica y define. Esta definición debería ser aplicada a todos los productos ya sean manufactureros, artesanales, de software etc. Calidad de software se define por algunos especialistas de ingeniería de software como: 1. Dar cumplimiento a un número adaptado de parámetros de calidad definidos por McCall, los cuales son correcto, robusto, extendible, reusable, compatible, eficiente, portable, integro, verificable, y de fácil uso.(meyer) 2. Proceso de administración que asegura que el software tiene un número bajo de defectos que llega a los estándares de calidad requeridos confiabilidad, portabilidad, mantenibilidad etc. (Sommerville) Modelos ISO. La familia de normas ISO 9000 es un conjunto de normas de calidad establecidas por la Organización Internacional para la Estandarización (ISO) que se pueden aplicar en cualquier tipo de organización (empresa de producción, empresa de servicios, administración pública...). Su implantación en estas organizaciones, aunque supone un duro trabajo, ofrece una gran cantidad de ventajas para sus empresas. Los principales beneficios son: - Reducción de rechazos e incidencias en la producción o prestación del servicio. - Aumento de la productividad - Mayor compromiso con los requisitos del cliente. - Mejora continua. La familia de normas apareció por primera vez en 1987 teniendo como base una norma estándar británica (BS), y se extendió principalmente a partir de su versión de 1994, estando actualmente en su versión 2000 Modelo ISO En el año 1997 ISO se publicó la norma 10006:1997 titulándose Gestión de la Calidad- Directrices para la calidad en la gestión de proyectos. Su objetivo es servir de guía en aspectos relativos a elementos, conceptos y prácticas de sistemas de calidad que pueden implementarse en la gestión de proyectos o que pueden mejorar la calidad de la gestión de proyectos. 4

5 La norma también presenta la finalidad de ser aplicada complementaria a las familias ISO 9000 por aquellos técnicos que necesitan compaginar el trabajo dentro de una organización empresarial y la aplicación del mismo proyecto concreto. Las deficiencias más importantes son: - No incluye los procesos de gestión de la calidad, y por lo tanto, da a entender que estos procesos no forman parte de la gestión del proyecto. - No presenta un procedimiento de ejecución del proyecto, aunque sí se habla exhaustivamente la planificación y control, lo cual puede inducir a pensar que la gestión únicamente consiste en planificar y controlar. - Aunque la norma no es una guía para la gestión de proyectos, el lenguaje utilizado puede dar lugar a pensar que sí lo es. - No entra en las fases del proyecto ni describe los procesos necesarios para la ejecución. Requisitos de la norma ISO Relativos a la estrategia. 1. Dirección Relativos a la gestión 2. Planificación 3. Interacción. 4. Modificación. 5. Finalización. Relativos al alcance. 6. Concepto. 7. Desarrollo y control. 8. Definición de actividades. 9. Control de actividades. Relativos al tiempo. 10. Interrelaciones de actividades. 11. Estimación de la duración. 12. Desarrollo de la programación. 13. Control de programación. Relativos al costo. 14. Estimación de costes. 5

6 15. Presupuestación. 16. Control de costes. Relativos a los recursos. 17. Planificación de recursos. 18. Control de recursos. Relativos al personal. 19. Estructura organizacional. 20. Ubicación de personal. 21. Desarrollo de recursos humano. Relativos a la comunicación. 22. Planificación de la comunicación. 23. Gestión de la información. 24. Control de la comunicación. Relativos al riesgo. 25. Identificación de riesgos. 26. Estimación de riesgos. 27. Respuesta a los riesgos. 28. Control de los riesgos. Relativos a los aprovisionamientos. 29. Planificación y control de los aprovisionamientos. 30. Documentación de los requisitos 31. Evaluación de subcontratistas. 32. Subcontratación 33. Control de contratos. Modelo ISO 9001/ Desde que la ISO 9001 fue escrita para ser utilizada por toda clase de industrias, es regularmente difícil interpretarla para el desarrollo de software, por lo cual se publicó la ISO "Guía para la aplicación de ISO 9001 para el desarrollo, implementación y mantenimiento de software". 6

7 La ISO provee las especificaciones de cómo aplicar la ISO 9001 al desarrollo del software, implementación y mantenimiento. Se incluyen algunos temas que no se encuentran en las normas ISO 9000 genéricas, tales como Administración de la Configuración o Planeación de Proyectos. Sería poco probable lograr resultados de calidad en un proyecto de desarrollo software de tamaño mediano, sin haber tomado las provisiones necesarias para el control de configuración. Dentro de los beneficios que se obtienen de la certificación ISO , se encuentran: 1. Mejor documentación de los sistemas. 2. Cambio cultural positivo. 3. Incremento en la eficiencia y productividad. 4. Mayor percepción de calidad. 5. Se amplía la satisfacción del cliente. 6. Se reducen las auditorías de calidad de los clientes. 7. Agiliza el tiempo de desarrollo de un sistema. Secciones de la Norma ISO-9003 a. Responsabilidades de la dirección: b. Sistemas de calidad: c. Revisión del contrato: d. Control de documentos y datos: e. Productos provistos por el comprador: f. Identificación y trazabilidad del producto: g. Inspección y pruebas: h. Equipos de Inspección, medición y pruebas: i. Estado de Inspección y pruebas: j. Control de producto no conforme: k. Acciones correctivas y preventivas: l. Manejo, almacenaje, empaque, preservación y embargue: m. Control de registros de calidad: n. Auditorias internas de calidad: o. Capacitación: p. Técnicas estadísticas. 7

8 Modelo ISO 15504/SPICE. En Enero de 1993 la comisión ISO/IEC se aprobó el proyecto para desarrollar un modelo para la evaluación de los procesos del ciclo de vida del software. Este proyecto se llamo SPICE (Software Process Improvement and Capability determination) y en 1995 se aprobó su primera publicación. Este modelo tiene dos dimensiones. Dimensión del proceso (objetivos medibles de un proceso) y Dimensiones de capacidad de proceso (Atributos de proceso). Dimensión del proceso: CUS Cliente-Proveedor. CUS.1 Proceso de adquisición. Proceso de preparación de la adquisición. Procesos de selección de proveedor. Procesos de seguimiento de proveedor. Proceso de aceptación del cliente. CUS.2 Proceso de suministro CUS.3 Proceso de obtención de requisitos CUS.4 Proceso de operación. Proceso de uso operacional Proceso de soporte al cliente ENG: Ingeniería. ENG 1.Proceso de desarrollo Proceso de análisis y diseño de requisitos de sistema Proceso de análisis de requisitos del sistema Proceso de diseño de Software Proceso de construcción de software Proceso de integración de software Proceso de prueba de software Proceso de integración y prueba de sistema 8

9 ENG.2 Proceso de mantenimiento de software SUP. Soporte SUP 1.Proceso de documentación SUP 2. Proceso de gestión de la documentación. SUP 3. Proceso de aseguramiento de la calidad. SUP.4 Proceso de verificación SUP.5 Proceso de validación SUP 6. Proceso de revisión conjunta SUP 7. Proceso de auditoría. MAN. Gestión MAN.1 Proceso de gestión. MAN 2. Proceso de gestión del proyecto. MAN 3 Gestión de calidad. MAN 4. Gestión de riesgos ORGANIZACIÓN. ORG.1 Proceso de alineación organizacional. ORG.2 Proceso de mejora Proceso de definición de proceso Proceso de evaluación de proceso Proceso de mejora de proceso ORG.3 Proceso de gestión de la RR.HH. ORG.4 Proceso de infraestructura ORG.5 Proceso de medición ORG.6 Proceso de reutilización. Dimensión de capacidad. Niveles de capacidad y atributos. Nivel 0. Proceso incompleto Nivel 1. Proceso realizado Nivel 2. Proceso Gestionado Nivel 3 Proceso Establecido Nivel 4 Proceso Predecible. 9

10 Nivel 5 Proceso en optimización. CMM-CMMI. El nacimiento de CMM - CMMI El departamento de defensa de los estados unidos tenía muchos problemas con el software que encargaba desarrollar a otras empresas, los presupuestos se disparaban, las fechas alargaban más y más. Quién no se ha encontrado con este tipo de problemas si ha trabajado con una empresa de software?. Como esta situación les parecía intolerable convocó un comité de expertos para que solucionase estos problemas, en el año 1983 dicho comité concluyó "Tienen que crear un instituto de la ingeniería del software, dedicado exclusivamente a los problemas del software, y a ayudar al Departamento de Defensa". Convocaron un concurso público en el que dijeron: "Cualquiera que quiera enviar una solicitud tiene que explicar como van a resolver estos 4 problemas", se presentaron diversos estamentos y la Universidad Carnegie Mellon ganó el concurso en 1985, creando el SEI. El SEI (Software Engineering Institute) es el instituto que creó y mantiene el modelo de calidad CMM CMMI Qué es el CMM - CMMI? El CMM - CMMI es un modelo de calidad del software que clasifica las empresas en niveles de madurez. Estos niveles sirven para conocer la madurez de los procesos que se realizan para producir software. Niveles CMM - CMMI Los niveles CMM - CMMI son 5: Inicial o Nivel 1 CMM - CMMI. Este es el nivel en donde están todas las empresas que no tienen procesos. Los presupuestos se disparan, no es posible entregar el proyecto en fechas, te tienes que quedar durante noches y fines de semana para terminar un proyecto. No hay control sobre el estado del proyecto, el desarrollo del proyecto es completamente opaco, no sabes lo que pasa en él. 10

11 Repetible o Nivel 2 CMM - CMMI. Quiere decir que el éxito de los resultados obtenidos se pueden repetir. La principal diferencia entre este nivel y el anterior es que el proyecto es gestionado y controlado durante el desarrollo del mismo. El desarrollo no es opaco y se puede saber el estado del proyecto en todo momento. Los procesos que hay que implantar para alcanzar este nivel son: o Gestión de requisitos o Planificación de proyectos o Seguimiento y control de proyectos o Gestión de proveedores o Aseguramiento de la calidad o Gestión de la configuración Definido o Nivel 3 CMM - CMMI. En este nivel ya existe una forma de desarrollar proyectos (gestión e ingeniería) está definida, por definida quiere decir que esta establecida, documentada y que existen métricas (obtención de datos objetivos) para la consecución de objetivos concretos. Los procesos que hay que implantar para alcanzar este nivel son: o Desarrollo de requisitos o Solución Técnica o Integración del producto o Verificación o Validación o Desarrollo y mejora de los procesos de la organización o Definición de los procesos de la organización o Planificación de la formación o Gestión de riesgos o Análisis y resolución de toma de decisiones La mayoría de las empresas que llegan al nivel 3 paran aquí, ya que es un nivel que proporciona muchos beneficios y no ven la necesidad de ir más allá porque tienen cubiertas la mayoría de sus necesidades. Cuantitativamente Gestionado o Nivel 4 CMM - CMMI. Los proyectos usan objetivos medibles para alcanzar las necesidades de los clientes y la organización. Se usan métricas para gestionar la organización. Los procesos que hay que implantar para alcanzar este nivel son: 11

12 o Gestión cuantitativa de proyectos o Mejora de los procesos de la organización Optimizado o Nivel 5 CMM - CMMI. Los procesos de los proyectos y de la organización están orientados a la mejora de las actividades. Mejoras incrementales e innovadoras de los procesos que mediante métricas son identificadas, evaluadas y puestas en práctica. Los procesos que hay que implantar para alcanzar este nivel son: o Innovación organizacional o Análisis y resolución de las causas Normalmente las empresas que intentan alcanzar los niveles 4 y 5 lo realizan simultáneamente ya que están muy relacionados. A grandes rasgos se ha intentado introducir el modelo de calidad del software CMM - CMMI para aquella gente que se encuentra por primera vez con él. La implantación de un modelo de estas características es un proceso largo y costoso que puede costar varios años de esfuerzo. Aun así el beneficio obtenido para la empresa es mucho mayor que lo invertido. Modelo MOPROSOFT. MoProSoft es un modelo de calidad que permitirá a la pequeña y mediana empresa de desarrollo de software, el acceso a las prácticas de Ingeniería de Software de clase mundial. El Modelo de Procesos para la Industria de Software, Moprosoft, tiene por objetivo proporcionar a la industria mexicana, y a las áreas internas dedicadas al desarrollo y mantenimiento de software, un conjunto integrado de las mejores prácticas basadas en los modelos y estándares reconocidos internacionalmente, tales como ISO 9000:2000, CMM-SW, ISO/ IEC 15504, PMBOK, SWEBOK entre otros. Moprosoft fue desarrollado durante el 2002, como consecuencia de los acuerdos de la mesa de la Estrategia 6 del Programa para el Desarrollo de la Industria de Software dirigido por la Secretaría de Economía, bajo un convenio con la Facultad de Ciencias de la UNAM. Para el desarrollo de este proyecto se convocó, a través de la Asociación Mexicana para la Calidad en Ingeniería de Software (AMCIS), a personas con experiencia y conocimiento en los modelos de procesos y calidad de software, 12

13 quienes serían los que conformaran al grupo editor bajo la dirección de la Dra- Hanna Oktaba. Este grupo estuvo constituido por las maestras Claudia Alquicira Esquivel, Angélica Su Ramos, Alfonso Martínez Martínez, Gloria Quintanilla Osorio, Mara Ruvalcaba López; por el ingeniero Francisco López Lira Hinojo; las matemáticas María Elena Rivera López y María Julia Orozco Mendoza; y completaban el equipo la doctora Yolanda Fernández Ordóñez y Miguel Ángel Flores Lemus. Para la elaboración de Moprosoft este grupo se comprometieron a cubrir los requisitos de la norma ISO 9000:2000 Gestión de Calidad. Estos requisitos se han convertido en las prácticas y productos muy concretos asociados a los procesos de Moprosoft. La ventaja que tiene la propuesta es que la industria contará con una interpretación de la norma ISO 9000:2000 acorde a sus particularidades, como lo es, por ejemplo, el desarrollo de los productos por proyectos. El anexo A1 de Moprosoft documenta la relación entre sus procesos y los requisitos de la ISO 9000:2000. También se tomaron en cuenta la norma ISO/IEC Software Life Cycle Processes y la ISO/IEC TR Software Process Assessment, como referencias para la definición de los propósitos, las prácticas y las salidas de los procesos. En atención a una solicitud de la Secretaría de Economía, Moprosoft fue desarrollado como el documento base para la definición de una norma mexicana dirigida a la industria de software. Características Proporcionar a la industria de software en México, que en su gran mayoría es pequeña y mediana, un modelo basado en las mejores prácticas internacionales con las siguientes características: Fácil de entender Fácil de aplicar No costoso en su adopción Ser la base para alcanzar evaluaciones exitosas con otros modelos o normas, tales como ISO 9000:2000 [1] o CMMâ1 V1.1[2]. Es un producto de la Estrategia 6 "Alcanzar niveles internacionales en capacidad de procesos", del Programa Nacional para la Industria de Software administrado por la Secretaría de Economía. 13

14 Está fundamentado en el modelo SW-CMM, el estándar ISO 9000 y el reporte técnico ISO/IEC TR La adopción de MoProSoft habilita la obtención de un certificado ISO 9000 y reduce la brecha para la obtención de una evaluación CMM-I niveles 2. Debido a su estructura y diseño, resulta de fácil comprensión y aplicación. Es la base del Anteproyecto de Norma Mexicana o ANTEPROY-NMX-I-XXX/02-NYCE-2005 o TECNOLOGÍA DE LA INFORMACIÓN SOFTWARE MODELO DE PROCESOS Y MÉTODO DE EVALUACIÓN PARA DESARROLLO Y MANTENIMIENTO DE SOFTWARE Estos marcadores corresponden a los niveles de capacidades de procesos definidos en la norma mexicana NMXI006/02NYCE2004 Tecnología de la información Evaluación de los procesos Parte 02: Realización de una evaluación que, a su vez, está basada en la norma internacional ISO/IEC : 2003 Information technology Process assessment Part 2: Performing an assessment. La versión de MoProSoft coloreada por niveles de capacidades ofrece una guía que oriente a los que quieren adoptar este modelo. Las partes coloreadas sugieren un orden de la implementación de las prácticas de los procesos de MoProSoft partiendo de las prácticas básicas, correspondientes a nivel 1, e incorporando las prácticas que corresponden a los niveles más avanzados. La siguiente tabla refleja la correspondencia entre los niveles de capacidad de procesos y los colores del marcador. Nivel Capacidad de proceso Color Nivel Capacidad de proceso Color 14

15 A continuación se describen las convenciones del marcaje que se adoptaron y su interpretación: 1. Los productos y las prácticas marcadas en amarillo son los que se recomiendan como primeros a implementar para poder cumplir con el nivel 1 de capacidades de procesos. 2. Una vez implementadas éstas se sugiere agregar los productos y las prácticas marcadas en azul y así sucesivamente agregando lo marcado en verde y rosa. El nivel 5 se logra cuando de manera sistemática a través del tiempo se cumplen los objetivos y se logran mejorar las metas cuantitativas de los procesos. Esta parte de la definición de los procesos quedó sin ninguna marca en particular. 3. Algunos productos o prácticas quedaron marcados de varios colores. Esto significa que algunas partes de los productos o de las prácticas se requieren en niveles distintos. La interpretación que se sugiere es que cuando se implementa un nivel más bajo de capacidad se toma en cuenta nada más las partes marcadas en el color correspondiente y cuando se sube de nivel se incorporan las partes del nivel siguiente. 4. Los productos que aparecen en las entradas marcados de un color también incluyen todos los elementos de este producto que corresponden a los niveles más bajos. 5. Los roles quedaron marcados en el color del nivel más bajo en el que tengan asignadas las actividades como su responsabilidad. 6. En el caso de la práctica Incorporación a la Base de Conocimiento algunos productos que se generan desde nivel 1 quedaron marcados con niveles más altos que corresponden al nivel a que se les aplican las verificaciones o validaciones. Sin embargo, estos productos deben de incorporarse a la Base de Conocimiento desde el nivel 1 cuando todavía no fueron verificados ni validados Niveles de MOPROSOFT El modelo de procesos (MoProSoft) tiene tres categorías de procesos: 15

16 Alta Dirección, Gerencia y Operación que reflejan la estructura de una organización. La categoría de Alta Dirección contiene el proceso de Gestión de Negocio. La categoría de Gerencia está integrada por los procesos de Gestión de Procesos, Gestión de Proyectos y Gestión de Recursos. Éste último está constituido por los subprocesos de Recursos Humanos y Ambiente de Trabajo, Bienes, Servicios e Infraestructura y Conocimiento de la Organización. La categoría de Operación está integrada por los procesos de Administración de Proyectos Específicos y de Desarrollo y Mantenimiento de Software. En cada proceso están definidos los roles responsables por la ejecución de las prácticas. Los roles se asignan al personal de la organización de acuerdo a sus habilidades y capacitación para desempeñarlos. En MoProSoft se clasifican los roles en Grupo Directivo, Responsable de Proceso y otros roles involucrados. Además se considera al Cliente y al Usuario como roles externos a la organización 16