Aseguramiento de la calidad y pruebas de software. 2- Estándares y Modelos para la mejora del proceso de software

Transcripción

1 Aseguramiento de la calidad y pruebas de software 2- Estándares y Modelos para la mejora del proceso de software Blanca A. Vargas Govea vargasgovea@itesm.mx Febrero 8, 2013

2 Objetivo Conocer los diferentes estándares y modelos de referencia para la mejora de procesos de software 2

3 SQA (Software Quality Assurance) SQA tiene su propio ciclo de vida y cubre todas las facetas de un proyecto se software 3

4 Procesos de aseguramiento de la calidad de software (SQA) Ciclo de vida de la administración de proyectos (PMLC) Inicio Planeación Ejecución Monitoreo y control Cierre Análisis Diseño Desarrollo Implementación Pruebas Ciclo de vida de desarrollo de software (SLDC) 4

5 Ciclo de vida de aseguramiento de la calidad (SQA) Inicio SQA Planeación SQA Aseguramie nto Req Aseguram iento Diseño Aseguramie nto Desarrollo Aseguram iento Pruebas Cierre SQA Inicio del proyecto Planeación Análisis Diseño Codificación Pruebas Cierre del proyecto Ciclo de vida de administración de proyectos y desarrollo de software 5

6 Proceso de software Puede definirse como un conjunto de actividades, métodos y prácticas que la gente usa para desarrollar y mantener software y los productos asociados (e.g., planes, documentación del diseño, código, casos de prueba, manuales de usuario). Capability Maturity Model SM for Software, Version 1.1 6

7 Estándares y modelos de referencia Cada organización puede adoptar un modelo para trabajar conforme a él o bien adoptar guías propias CMMI TSP PSP ISO 15504/SPICE Six Sigma MoProSoft 7

8 Estándares y modelos de referencia CMMI GP 1.1 Identify Work Scope Identify the scope of the work to be performed and work products or services to be produced, and communicate this information to those performing the work. The purpose of this practice is to ensure that the people doing the work have a common understanding of the work to be performed and work products to be produced. Ejemplo de una práctica genérica (Nivel 1) 8 CMMI SM for Systems Engineering/Software Engineering, Version 1.02 (CMMI-SE/SW, V1.02)

9 Evaluadas Aunque es común escuchar los términos certificación y acreditación, para CMMI no existen. Las organizaciones son evaluadas por un evaluador autorizado por SEI (Software Engineering Institute)

10 Team Software Process / Personal Software Process

11 11

12 PSP CMMI se enfoca en qué se debe hacer y no cómo. PSP guía a los ingenieros a mejorar su calidad y productividad en los procesos en los que participan. Define 4 niveles de madurez e identifica los pasos para alcanzar el siguiente. 1. PSP0 Medición personal- 2. PSP1 Planeación personal 3. PSP2 Calidad personal 4. PSP3 Proceso cíclico 12

13 13

14 PSP Recolección de tamaño, tiempo y datos Cómo estimar el trabajo en una forma consistente y explicable Cómo usar las propias medidas para mejorar la estimación Si ahora agrego 10 contactos por minuto, cómo hacer para mejorar? Cómo mejorar de forma contínua la calidad del trabajo 14

15 15

16 16

17 PSP - Niveles PSP0 Cómo medir el tiempo de desarrollo y los defectos que han introducido y eliminado. Se introduce el uso de estándares de código, medidas y una forma de proponer mejoras al proceso personal. PSP1, Se aprenden técnicas para estimar el tamaño y tiempo de desarrollo con base en los datos recolectados en PSP0. Se aprende a planear tareas y horarios. 17

18 PSP - Niveles PSP2 - Adminstración de defectos. Se usan los datos de las etapas anteriores para construir listas e identificar los defectos que más se generan. PSP3 Proceso cíclico. Constante monitoreo de errores introducidos y eliminados y constante revisión de la lista de defectos llevará a mejoras en la calidad personal. 18

19 TSP (Team Software Process) TSP usa las habilidades de PSP. Team Software Process (TSP) extiende y refina CMM y PSP para guiar a los ingenieros en el desarrollo y mantenimiento de equipos de trabajo (20p) Enseña cómo construir un equipo auto-dirigido efectivo, cómo guiarlos y administrarlos 19

20 20

21 21

22 22 SPICE (Software Process Improvement and Capability Determination)

23 SPICE Surgimiento de diversas metodologías de evaluación originó la noestandarización Iniciativa de ISO International Organization for Standardization y de IEC International Electrotechnical Commission 1993 Armonizar las metodologías existentes en un modelo comprensivo 23

24 SPICE: meta Construir un estándar internacional para evaluación del proceso de software cubriendo el desarrollo, adquisición, administración, soporte al cliente y calidad, también preocupaciones del cliente y transferencia de tecnología. Se basa en el conocimiento adquirido de otras metodologías. 24

25 Estructura 6 niveles de competencia Existe gran conformidad con el modelo CMM 25

26 Partes del estándar 26

27 y en relación a CMMI? ISO/IEC no ha sido tan exitoso como CMMI. ISO/IEC no está disponible de forma gratuita. CMM ycmmi están disponibles del sitio de SEI. CMMI es patrocinado por el Departamento de Defensa de Estados Unidos. CMM surgió primero. 27

28 28

29 Six Sigma Filosofía de administración Enfocada en el cliente Orientada a metas Escuchar la voz del cliente y convertir sus necesidades en requerimientos medibles 29

30 Six Sigma Six Sigma proceso que ayuda al desarrollo y entrega de productos y servicios casi perfectos. Six Sigma se originó en Motorola a finales de 1980s,Bill Smith. Sigma es un término estadístico que mide que tanto se desvía un producto de la perfección. 30

31 Six Sigma La idea central es que si puedes medir cuántos defectos tienes en un proceso, puedes sistemáticamente descubrir cómo eliminarlos y acercarte a tener cero defectos. Para lograr calidad Six Sigma, un proceso debe producir no más de 3.4 defectos por millón de oportunidades. Una oportunidad se define como una probabilidad de no-conformidad, o no lograr las especificaciones requeridas 31

32 Escala Sigma Medida universal del desempeño de una organización. A mayores valores de Sigma corresponde mejor desempeño. Si la salida es defectuosa 69% de las veces, significa que tiene Un Sigma de conformidad. Si la salida es defectuosa 31% de las veces, está mostrando una conformidad de Dos Sigma. Table: The Sigma Scale Sigma Percent Defective Defects per Million 1 69% 691, % 308, % 66, % 6, % % % Seis Sigma significa una salida casi perfecta, solamente de 3.4 defectos por millón de La mayoría de las organizaciones entregan resultados entre el Tres y Cuatro Sigma. 32

33 Metodología básica: DMAIC Para modificar un proceso existente Definir las metas para la mejora del proceso de acuerdo a las demandas del cliente y las estrategias de la organización. Medir el desempeño actual y reunir datos relevantes para el futuro. Analizar el escenario actual y observar la relación entre los parámetros y el desempeño. Mejorar el proceso con base en el análisis para optimizarlo. Controlar los parámetros antes de que afecten la salida. 33

34 Implementación Profesionalizó los roles de administración de la calidad. Adopta una nomenclatura de artes marciales para definir la jerarquía que cubre todos los tipos de funciones de negocios Líderes ejecutivos: visionarios que autorizan a otros miembros del equipo y les proporcionan los recursos para la mejora del proceso. 34 Campeones o líderes de calidad: Implementan e integran la metodología Seis Sigma en la organización. Son seleccionados por los líderes ejecutivos. Son mentores de los Cinturones Negros. Maestros Cinturones Negros, son entrenadores expertos en Seis Sigma. Actúan como guías de Cinturones Negros y Verdes y ayudan a los Campeones a implementar Seis Sigma.

35 Implementación Cinturones negros: operan bajo la guía de los Maestros Cinturones Negros y su tarea es aplicar la metodología Seis Sigma. Su función principal es la ejecución de Seis Sigma. Cinturones Verdes Trabajan en la implementación de Seis Sigma. Son guiados por los Cinturones negros. Cinturones amarillos han sido entrenados en Seis Sigma pero no lo han aplicado. 35

36 Por otro lado El estándar no puede ser óptimo para algunos procesos. Salud: puede requerirse más. Ciertas operaciones pueden funcionar bien con un valor menor. No hay clara justificación acerca del número Seis. Por qué 6? 36

37 CMM CMM se basa en el punto de vista de la organización. Six Sigma Six Sigma se basa en el punto de vista del cliente. Lo que él necesite se traduce a productos y procesos en Six Sigma. 37

38 38 Modelo de Procesos de Software

39 MoProSoft A solicitud de la Secretaría de Economía para servir de base a la Norma Mexicana para la Industria de Desarrollo y Mantenimiento de Software bajo el convenio con la Facultad de Ciencias, Universidad Nacional Autónoma de México. 39

40 MoProSoft Modelo de procesos de software. Norma NMX-059/01- NYCE-2005 declarada el 15 de Agosto del 2005 CMMI y SPICE no apropiadas para empresas pequeñas, medianas 1er versión Nov

41 Divide el proyecto en 4 fases 41

42 Estructura: 3 Categorías Alta dirección (DIR) Se establecen los lineamientos para los procesos de la Categoría de Gerencia y se retroalimenta con la información generada por ellos en apoyo a la estrategia de la organización. Gerencia (GER) Se definen los elementos para el funcionamiento de los procesos de la Categoría de Operación en función de la estrategia de Dirección. Operación (OP) Se realizan las actividades de acuerdo a los elementos proporcionados por la Categoría de Gerencia y entrega a ésta la información y productos generados. 42

43 Estructura: 3 Categorías 1. Categoría Dirección Gestión de negocios 2. Categoría Gerencia Gestión de proyectos Gestión de recursos Recursos humanos y ambiente de trabajo Bienes, servicios e infraestructura Conocimiento de la organización 3. Categoría Operación Administración específica de proyectos Desarrollo y mantenimiento de software 43

44 Niveles de madurez 1. Realizado. El proceso se implementa y alcanza su propósito. 2. Gestionado. El proceso realizado se administra. Sus productos de trabajo están establecidos, controlados y mantenidos. 3. Establecido. El proceso realizado y gestionado se implementa por medio de un proceso definido. 4. Predecible. El proceso establecido opera bajo límites definidos y conocidos. 5. Optimizado. El proceso predecible se mejora continuamente. 44

45 Uso de metodologías Encuesta 114 empresas de desarrollo de software (2007) Metodologías propias 45.41% Metodologías ágiles 41.25% (XP, Scrum, espiral) Modelos y estándares 13.34% (CMM, CMMI, ISO) 45

46 Actividad 7: en equipo Investigación: Buscar en medios diversos (foros de discusión, blogs, documentos, etc.) problemas, quejas, inconformidades que los usuarios/clientes describen sobre los modelos/metodologías/estándar (CMMI, TSP, PSP, SPICE, Six Sigma y MoProSoft) Hacer un reporte crítico que contraste lo que el modelo/metodología/estándar ofrece con los problemas que encontraste. Consideras que son problemas reales o uso deficiente de los modelos? Estás de acuerdo con los aspectos negativos reportados? por qué? Viendo ambas caras, cuál es su opinión sobre el uso de modelos/metodologías/estándares? Enviar por correo formato pdf 46

47 Avance de proyecto Martes 12 de Febrero Descripción y alcance del proyecto, requerimientos funcionales y no funcionales: Documento basado en el estándar SRS IEEE Guía inicial para los componentes del aseguramiento de la calidad (Sesión 4): 1. Control de calidad 2. Administración de configuraciones de software Presentación (Power Point o cualquier software de presentaciones) No documento de texto. 47

48 Examen Primer parcial Viernes 15 de Febrero 48

49 Referencias Galin, Daniel. Software Quality Assurance, Software quality assurance : from theory to implementation, Harlow, Essex ; New York, N.Y. : Pearson/Addison Wesley, 2004., England, Sergio Alan Flores Rosales. Modelo de calidad para la microempresa basado en MoProSoft. Tesis de maestría. Universidad de Colima. Febrero