DIPLOMADO DE INGENIERÍA DE SOFTWARE

Presentación del tema: "DIPLOMADO DE INGENIERÍA DE SOFTWARE"— Transcripción de la presentación:

1 DIPLOMADO DE INGENIERÍA DE SOFTWARE
Módulo 5 Aseguramiento de Calidad de Software

2 OBJETIVO Al finalizar el módulo, los participantes: tendrán los conceptos básicos y prácticos  para tener una definición propia de: 'calidad de software', conocerán las técnicas y principios de verificación y validación, establecerán el proceso de aseguramiento de  la calidad y conocerán los procesos más importantes de certificación de software. Lecturas – control de lectura Presentación por equipo Caso final individual 20% Control 15% Participación 25% Presentación 40% Caso final

3 CONTENIDO TEMÁTICO Tema 1. Conceptos fundamentales e calidad y terminología de los procesos de validación y verificación. Tema 2. Principios y técnicas de pruebas. Tema 3. Tipos de defectos y estrategias de pruebas. Tema 4. La importancia de la verificación y validación en el aseguramiento de la calidad de software. Tema 5 Aseguramiento del proceso contra aseguramiento del producto Tema 6. Análisis y reporte de problemas. Tema 7. Herramientas estadísticas para el control de calidad. Tema 8. Estándares de calidad del proceso y del producto. Tema 9. Procesos y entidades certificadoras de calidad de software. Discusiones finales.

4 TEMA 1. CONCEPTOS FUNDAMENTALES Y TERMINOLOGÍA DE LOS PROCESOS DE VALIDACIÓN Y VERIFICACIÓN.
Los participantes conocerán las técnicas y principios de verificación y validación

5 Conceptos fundamentales
Aseguramiento de Calidad de Software (ACS) Patrón sistemático y planificado de todas las acciones a seguir para proporcionar la confianza adecuada de que un producto de software o un elemento componente se realiza acorde a los requerimientos técnicos establecidos. Calidad de Software Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentos y con las características implícitas que se esperan de todo software desarrollado profesionalmente.

6 Calidad de Software Enfatizar tres aspectos importantes:
Los requerimientos explícitos del software son los fundamentos a partir de los cuales se mide la calidad. La falta de concordancia con los requerimientos explícitos es una falta de calidad. Los estándares definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Existe un conjunto de requerimientos implícitos que a menudo no se mencionan (ej., la necesidad de facilitar su mantenimiento). Si el software no se ajusta a los requerimientos implícitos, la calidad del software queda incompleta.

7 Características de calidad
Funcionalidad Mantenibilidad Eficiencia Portabilidad Confiabilidad Usabilidad Reusabilidad El primer nivel del modelo de evaluación se ubican las características de calidad, las cuales son propiedades del software, que permiten describir y evaluar su calidad. Una característica de calidad puede ser refinada en múltiples subcaracterísticas que demuestran su capacidad para satisfacer los requerimientos implícitos y explícitos preestablecidos por el productos del software y por el cliente respectivamente.

8 VERIFICACIÓN Y VALIDACIÓN (V&V)
Conjunto de actividades que aseguran que el software implementa correctamente una función específica. Pressman ¿Estamos construyendo el producto correctamente? Bohem Logra que el sistema refleje de forma adecuada los requerimientos especificados. “you built it right” Conjunto diferente de actividades que aseguran que el software construido se ajusta a los requisitos del cliente. Pressman ¿Estamos construyendo el producto correcto? Bohem Demuestra que el sistema, como está desarrollado, brindará los servicios tal y como han sido deseados. “you built the right thing”

9 EJEMPLOS DE MÉTODOS PARA V&V
Verificación Validación Inspecciones· Revisiones entre paresPeer Auditorias Walkthroughs· Análisis Simulaciones· Testing· Demonstraciones Discusiones con usuarios (revisiones formales) Demostraciones de prototipos Presentaciones funcionales (e.g., service delivery run- throughs, end-user interface demonstrations)· Politeo de materiales de entrenamiento o capacitación Pruebas de servicios Pruebas de componentes del sistema realizadas por usuarios o principales involucrados

10 ACTIVIDADES DE V&V Las actividades o dichos métodos:
Se enfocan en asegurar que el sistema entrega los servicios tal y como fue deseado en el ambiente de entrega esperado. Normalmente se desarrollan de forma concurrente y probablemente utilicen porciones del mismo ambiente de pruebas. Se pueden realizar repetidamente en multiples fases del desarrollo del sistema

11 EJEMPLOS DE COMPONENTES DEL SISTEMA QUE DEBEN SER VERIFICADOS Y VALIDADOS
Personas Procesos Equipos Software Consumibles

12 PRÁCTICAS DE VERIFICACIÓN
Preparar la verificación Dirigir o conducir la verificación Identificar las acciones correctivas Verificar incluye: Probar el sistema Probar componentes seleccionados del sistema ante todos los requerimientos elegidos; incluyendo acuerdos de servicio, requerimientos de servicio y requerimientos del sistema

13 PREPARACIÓN: ESTABLECER Y MANTENER ACERCAMIENTO Y AMBIENTE PARA V&V
Verificación Validación Incluye: Selección Inspección Testing Análisis Demostración De componentes del sistema: Productos de trabajo Procesos Recursos consumibles Elegir servicios y componentes del sistema para: Ambiente de validación Procedimientos Criterios Importante involucrar a: Usuarios finlaes Personal de primer contacto con usuarios que entrega servicios. Sus perspectivas en la entrega exitosa de los servicios varian significativamente de un rol a otro y entre los desarrolladores también.

14 PRODUCTOS DE TRABAJO TÍPICOS EN V&V
Lista de componentes del sistema seleccionados Métodos para cada componente Ambiente Procedimientos Criterios

15 SUB – PRÁCTICAS PARA V&V
Seleccionar los componentes que serán V&V y los correspondientes métodos que se aplicarán a cada componente. Los componentes del sistema se eligen con base en su contribución para lograr objetivos del proyecto, requerimientos y para identificar los riesgos del proyecto. Establecer y mantener el ambiente para V&V Establecer y mantener los procedimientos y el criterio para los componentes seleccionados.

16 TEMA 2. PRINCIPIOS Y TÉCNICAS DE PRUEBAS.
Identificarán las técnicas de pruebas efectiva y eficientemente calculando la cobertura de pruebas

17 OBJETIVOS DE LAS PRUEBAS
La prueba es el proceso de ejecución de un programa con la intención de describir un error. Un buen caso de pruebas es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces. Una prueba tiene éxito si descubre un error no detectado hasta entonces. Diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y de esfuerzo. Un programa de trabajo deja algo bonito difícil de encontrar. Robert Dunn Los errores en el software son más comunes, más generalizados y más molestos que en otras tecnologías. David Parnas OBJETIVOS DE LAS PRUEBAS

18 PRINCIPIOS DE LAS PRUEBAS
A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del cliente. Las pruebas deberían planificarse mucho antes de que empiecen. El principio de Pareto es aplicable a la prueba del software. Las pruebas deberían empezar por lo pequeño y progresar hacia lo grande. No son posibles las pruebas exhaustivas. Para ser más eficaces, las pruebas deberían ser realizadas por un equipo independiente.

19 FACILIDAD DE PRUEBA Operatividad Observabilidad Controlabilidad
Cuanto mejor funcione, más eficientemente se puede probar. Observabilidad Lo que ves es lo que pruebas Controlabilidad Cuanto mejor podamos controlar el sofware, más se puede automatizar y optimizar. Capacidad de descomposición Controlando el ámbito de las pruebas, podemos aislar más rápidamente los problemas y llevar a cabo mejores preubas de regresión Simplicidad Cuanto menos haya que probar, más rápidamente podremos probarlo Estabilidad Cuanto menos cambios, menos interrupciones a las pruebas. Facilidad de comprensión Cuanta más información tengamos, más inteligentes serán las pruebas.

20 DISEÑO DE CASOS DE PRUEBA
Pruebas de caja negra Pruebas de caja blanca La operación interna se ajusta a las especificaciones. Pruebas que se llevan a cabo sobre la interfaz del software. Demostrar que las funciones del software son operativas: la entrada se acepta de forma adecuada y el resultado es correcto; la integridad de la información externa se mantiene. Todos los componentes internos se comprueban de forma adecuada. Se basa en el minucioso examen de los detalles procedimentales. Se comprueban los caminos lógicos del sw: condiciones y/o bucles. Son diseñadas después de que exista un diseño de componente (o código fuente). El detalle de la lógica del programa debe estar disponible.

21 BASIC NOTIONS Error Failure Fault Incident Bug Fault Directed testing
mistake made by human during implementation of a software system. Failure incorrect behaviour of a program. Fault incorrect code that caused a failure. Incident symptoms associated with a failure. Bug an error or fault Fault Directed testing finding bugs through failure Test Case A test described by test data, environment and expected result. Test Suite a collection of test cases. Test Plan document describing testing approach, test suites and test cases. Test Strategy a way to identify test cases from a specification or implementation. Test Effectiveness relative ability of test strategy to find bugs. Test Efficiency relative cost of finding a bug. Test Coverage the percentage of testable elements that have been tested.

22 TEMA 3. TIPOS DE DEFECTOS Y ESTRATEGIAS DE PRUEBAS.
Determinaran las estrategias de prueba adecuadas

23 DEFECTOS Defecto: Anomalía del producto Fallo
Un defecto en un dispositivo de hardware o componente: por ejemplo, un corto circuito o un cable roto. Un paso incorrecto, proceso o definición de datos en un programa de computadora. Algunas enfermedades, como dicen los médicos, en su comienzo son difíciles de reconocer… pero con el paso del tiemp, cuando no se han reconocido y tratado al principio, se vuelven fáciles de reconocer pero difíciles de curar. Niccolo Machiavelli DEFECTOS Pasos de desarrollo Defectos Detección Errores de pasos anteriores Errores inadvertidos Errores nuevamente generados Errores amplificados 1: x Porcentaje de eficiencia de la detección de errores IEEE Standard Dictionary of Electrical and Electronic Terms ( IEEE Standard ) IEEE Standard Errores pasados al siguiente paso

24 Proceso de desarrollo de software
ERROR  FALTA  FALLA Proceso de desarrollo de software sw error sw fault sw failure

25 LAS NUEVE CAUSAS DE ERRORES DE SW
Definición de requerimientos incompleta Fallas de comunicación en: cliente – desarrollador Desviación deliberada de los requerimientos de software Errores de diseño lógico Errores de código Incumplimiento entre documentación e instrucciones de codificación Proceso de pruebas deficiente o limitado Errores de procedimiento Errores de documentación

26 ESTRATEGIAS DE PRUEBAS
Proporcionan una plantilla para la prueba. Características: Inician a nivel módulo y trabajan hacia afuera, hacia la integración de todo el sistema basado en computadora. Según el momento, son apropiadas diferentes técnicas de pruebas. La realiza el responsable del desarrollo de sw, para grandes proyectos un grupo independiente de pruebas. La prueba y depuración son diferentes, pero la 2da se debe incluir en la estrategia de prueba. Debe incluir: Pruebas de bajo nivel que verifiquen que todos los pequeños segmentos de código fuente se han implementado correctamente Pruebas de alto nivel que validen las principales funciones del sistema frente a los requisitos del cliente. Debe proporcionar: Guía al profesional y conjunto de hitos para medir el progreso y mostrar problemas lo antes posible. Pruebas: conjunto de actividades que se pueden planear y realizar sistemáticamente. Plantilla para las pruebas: pasos, métodos específicos de diseño de casos de prueba

27 ASPECTOS ESTRATÉGICOS
Especificar los requisitos del producto de manera cuantificable mucho antes de que comiencen las pruebas. Establecer los objetivos de la prueba de manera explícita. Comprender qué usuarios van a manejar el software y a desarrollar un perfil para cada categoría de usuario. Desarrollar un plan de prueba que haga hincapié en la prueba de ciclo rápido. Construir un software robusto diseñado para probarse a sí mismo. Usar revisiones técnicas formales efectivas como filtro antes de la prueba. Llevar a cabo revisiones técnicas formales para evaluar la estrategia de prueba y los propios casos de prueba. Desarrollar un enfoque de mejora continua al proceso de prueba. Debería medirse la estrategia de prueba. Los casos de uso describen un escenario para usar el software. ASPECTOS ESTRATÉGICOS

28 PRUEBAS DE UNIDAD. Centra el proceso de verificación en la menor unidad de diseño del software: El componente de software o módulo. Probar el flujo de datos de la interfaz del módulo. Comprobar el impacto de los datos globales sobre el módulo. Comprobar los caminos de ejecución. Detectar errores debidos a: cálculos incorrectos comparaciones incorrectas flujos de control inapropiados

29 PRUEBAS DE INTEGRACIÓN.
Técnica sistemática para construir la estructura del programa mientras que se llevan a cabo pruebas para detectar errores asociados con la interacción. El objetivo es tomar los módulos probados mediante la prueba de unidad y construir una estructura de programa que esté de acuerdo con lo que dicta el diseño. La prueba de integración deberá ser conducida incrementalmente. El programa se construye y se prueba en pequeños segmentos en los que los errores son más fáciles de aislar y de corregir.

30 DESEMPEÑO. Peticiones :: utilizan recursos (hw y sw)
Carga :: todos los usuarios de la aplicación en un determinado momento sin importar su actividad. Número total de usuarios, no sólo los que están haciendo peticiones, ya que todos los usuarios consumen recursos. Consumen memoria u otro tipo de mecanismo para almacenar el estado de un cliente. Carga de picos :: número máximo de clientes dentro d un período de tiempo. Al planear una prueba de desempeño, encontrar la carga pico y porbar la aplicación contra esta carga es lo más importante. Rendimiento de procesamiento :: throughput, mide la cantidad de peticiones servidas por unidad de tiempo. Esta métrica se caracteríza por tener un límite superior. Ej. 5 cajeros y atención por cliente 1 min :: rendimiento 5 clientes por minuto. Tiempo de respuesta :: tiempo desde que el usuario inicia un petición hasta que el resultado es visualizado. Relación entre: carga, rendimiento de procesamiento, y el mismo tiempo de respuesta Punto de saturación :: el rendimiento permanece constante.

31 DESEMPEÑO. Para mejorar el desempeño de una aplicación:
Entender cuántos usuarios simultáneos soporta la aplicación y cuánto aumentan los tiempos de respuesta en los momentos de mayor tráfico son las principales motivaciones para realizar una prueba de desempeño. Para mejorar el desempeño de una aplicación: optimizar o escalar Optimización: modificar la aplicación para que consuma menos recursos o para minimizar los cuellos de botella. Técnicas de escalamiento: añadir recursos. Ej. Aumentar número de servidores que hospedan la aplicación. Escalamiento vertical  más recursos al servidor (CPU o memoria) Escalamiento horizontal  más servidores para formar cluster.

32 PERFILES DE APLICACIÓN :: PRUEBA DEL SISTEMA
¿Qué es lo que la aplicación necesita hacer bien? Recuperación Fuerza el fallo del software de muchas formas y verifica que la recuperación se lleva a cabo apropiadamente. Automática.- evaluar inicialización; mecanismos de recuperación del estado del sistema; recuperación de datos y del proceso de rearranque. Intervención humana.- evaluar los tiempos medios de reparación y sus límites aceptables. Seguridad Verificar que los mecanismos de protección incorporados en el sistema lo protegerán de accesos impropios. Cifrado de datos, firewalls y bitácoras. Resistencia (Stress) Diseñadas para enfrentar a los programas con situaciones anormales. Ejecuta un sistema de forma que demande recursos en cantidad, frecuencia o volúmenes anormales. Rendimiento Tiempo de ejecución dentro del contexto de un sistema integrado. Descubrir situaciones que lleven a degradaciones y posibles fallos del sistema. Si has intentado encontrar verdaderamente fallos en el sistema y nunca has sometido tu software a una prueba real de resistencia, entonces has perdido mucho el tiempo. Boris Beizer PERFILES DE APLICACIÓN :: PRUEBA DEL SISTEMA

33 DESARROLLO DEL MANEJO DE PRUEBAS.
La planeación de pruebas contempla realizar las pruebas de funcionalidad y de integración primero, para asegurar que la apliación funciona correctamente. Se desarrollan scripts de pruebas, considerando las siguientes recomendaciones: Desarrollar scripts pequeños Escribir scripts atómicos Permitir datos dinámicos En general, la prueba de desempeño es un proceso iterativo: se prueba, se recolectan datos, se verifican, analizan y se optimiza; hasta alcanzar los objetivos de los escenarios de prueba. Las pruebas de desempeño se deben conducir en los siguientes puntos del ciclo de desarrollo: Pruebas unitarias: por cada desarrollador antes de liberar sus componentes, analizados por memoria y código. Pruebas de integración de la aplicación: carga con usuarios proyectados. Pruebas de producción: ambiente lo más similar a la aplicación en producción.

34 PRUEBAS DE CONFIGURACIÓN.
Revisión de la configuración Asegurarse que todos los elementos de la configuración del software: se han desarrollado apropiadamente, se han catalogado y están suficientemente detallados para soportar la fase de mantenimiento durante el ciclo de vida del software. Auditoría Las relaciones establecidas entre los objetos de configuración permiten al ingeniero de software evaluar el impacto del cambio Identificación, control de versiones y control de cambios. Se apoya de los informes de estado: Qué paso; quién lo hizo; cuándo paso; qué más se vio afectado. El arte del progreso está en mantener el orden el medio del cambio y mantener el cambio en medio del orden. Alfred North Whitehead PRUEBAS DE CONFIGURACIÓN.

35 PRUEBAS DE COMPATIBILIDAD.
Distribución de software Pruebas en la aplicación, que certifiquen su correcto funcionamiento bajo las distintas configuraciones posibles; diferentes al ambiente de desarrollo. Cientos de diferentes configuraciones tanto de software (Windows/Mac/Linux/Solaris, IE/Safari/Firefox), como de hardware (Intel,AMD,G5,Sparc) donde probar la aplicación facilte encontrar problemas antes que los clientes y usuarios finales lo hagan. Aplicación en sistemas de alta fiabilidad Desarrollos paralelos Desarrollo del software, las versiones de la aplicación de ejecutan en equipos independientes, usando las mismas especificaciones Se deben probar todas las versiones con los mismos datos, para asegurar que proporcionan una salida idéntica

36 PRUEBAS ALFA, BETA Y DE ACEPTACIÓN
Prueba de aceptación.- desarrollo de un software a la medida para un cliente; permitir que el cliente valide todos los requisitos. Las realiza el usuario final en lugar del responsable del desarrollo del sistema. Puede ir desde un informal paso de prueba hasta la ejecución sistemática de una serie de pruebas bien planificadas. Puede tener lugar a lo largo de semanas o meses, descubriendo así errores acumulados que puedn ir degradando el sistema.

37 Integración Continua y Ecosistemas de Software CONTINUOUS INTEGRATION
Martin Fowler GoF Patrones de Diseño Influencia en la industria. IoC ID

38 Integración Continua y Ecosistemas de Software
CONTINUOUS INTEGRATION Incluye: Control de versiones Automatización de Build’s Automatización de Pruebas unitarias Automatización de Pruebas de aceptación Automatización de Métricas

39 Integración Continua y Ecosistemas de Software
Un ecosistema software es un espacio de trabajo en el que conviven una serie de herramientas que acompañadas de unas buenas prácticas permiten a un equipo de desarrollo modelar una metodología de trabajo.

40 LAS PRUEBAS EN EL DESARROLLO DE SOFTWARE
Desarrollo guiado por pruebas (TDD). Es una metodología de programación que involucra otras dos prácticas: escribir las pruebas primero (Test First Development) y refactorización (Refactoring).

41 Tema 4. La importancia de la verificación y validación en el aseguramiento de calidad de software.
Conocerán la importancia de las técnicas y principios de verificación y validación

42 Terminología de pruebas de software
Pruebas: identificación de discrepancias entre el software ejecutable y sus especificaciones. Verificación: asegurarse que los productos de una fase en particular cumplan sus objetivos establecidos en una fase previa. Validación: asegurarse que el sistema final cumpla con los requerimientos y necesidades. Debugging: diagnosticar la naturaleza precisa de un error conocido y entonces corregirlo.

43 Planeación y ejecución de pruebas :: V&V
Pruebas Unitarias Pruebas de Aceptación Pruebas de Integración Pruebas de Sistema Validación Requerimiento de Calidad Concepto Especificación Requerimientos Funcional Diseño Técnico Detallado Construcción Verificación de Calidad

44 Tres elementos que son esenciales para la prueba de software
Plan de pruebas Política de pruebas general Metodología de pruebas a ser usada Recursos requeridos Descripción de pruebas Procedimientos de pruebas individuales Casos de pruebas individuales Reportes de pruebas Documentación de la ejecución de pruebas y resultados

45 Problemas potenciales durante las pruebas de software
Diferentes objetivos entre desarrolladores y probadores Los desarrolladores invariablemente cuestionaran las competencias de los probadores y viceversa Los usuarios pueden cuestionar la competencia de todos si ellos ven demasiados errores Los usuarios identifican nuevos requerimientos que deben ser incorporados en el software La presión para cumplir el calendario es fuerte En un ambiente de contrato, la organización que desarrolla busca por maneras de culpar al cliente por desviaciones El desgaste es común, la gente sólo quiere terminar y salir de ahí

46 Guías para las pruebas de software
Limitar qué puede y qué debe ser probado Monitorear la profundidad de las pruebas al costo de un error no descubierto Remover los defectos antes de pruebas Evitar las pruebas excesivas Cumplir las necesidades de Requerimientos bien escritos Buenos procedimientos de pruebas Probadores eficientes Preparar documentación adecuada

47 ASEGURAMIENTO DE CALIDAD DE SOFTWARE
Patrón, planeado y sistemático, de todas las actividades necesarias para proveer la confidencialidad adecuada que un artefacto o producto está conforme a lo establecido por los requerimientos técnicos. Conjunto de actividades diseñadas para evaluar el proceso por el cual los productos son desarrollados y manufacturados. Conjunto de actividades, sistemáticas y planeadas para brindar confiabilidad en el proceso de desarrollo de software o en el proceso de mantenimiento de un sistema para la establecer la funcionalidad acorde a los requerimientos. El aseguramiento de calidad del software es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza en que el producto (software) requiere para satisfacer los requerimientos dados de calidad por parte del cliente.

48 Tema 5. Aseguramiento del proceso contra Aseguramiento del producto.
Reconocerán una definición propia de calidad de software Evaluarán la densidad de los defectos

49 Ingeniería de sistemas y procesos
Sistema de alta tecnología Componentes: hardware, software, personas, bases de datos, documentación y procedimientos. Ingeniería de sistemas Traducir las necesidades del cliente en un modelo de sistema con uno o más componentes. Visión global :: dominio de negocio o producto para establecer los requisitos básicos. Visión de dominio :: cada elemento se analiza individualmente y se asigna a uno o más componentes. Ingeniería de procesos de negocio Arquitecturas para facilitar el uso de la información eficazmente en un negocio. Arquitecturas minuciosas de datos, de aplicación e infraestructura tecnológica que satisfaga las necesidades de la estrategía de negocio y los objetivos de cada área de negocio. La ingeniería de procesos de negocio comprende una planificación de la estrategía de la información, un análisis del área de negocio y un análisis específico de aplicación. Éstos forman parte de la ingeniería del software. Ingeniería de sistemas y procesos

50 Ingeniería de producto
La ingeniería de productos es un enfoque de la ingeniería de sistemas que inicia con el análisis del sistema. Identificar las necesidades del cliente Determinar la viabilidad económica y técnica Asignar funciones y rendimientos al software, hardware, personas y bases de datos (componentes de ingeniería) Ingeniería de requisitos Intensa comunicación entre el cliente y el ingeniero de sistemas Identificación, análisis y negociación, especificación, modelización, validación y gestión. Especificación del sistema Documento que sirve de base para las tareas de ingeniería que se realizarán posteriormente. La ingeniería de software pretende proporcionar un marco de trabajo para construir software con mayor calidad. Ingeniería de producto

51 Administración de los componentes de la calidad de software
Control del progreso del proyecto Control de las actividades de las administración de riesgos Control de la agenda, de los recursos y del presupuesto del proyecto Métricas de la calidad del software Métricas del proceso Métricas del producto Costos de las calidad del software Controlar los costos asociados con la prevención de errores (antes de que ocurran) y la detección de errores (una vez que se presentaron) Evaluar los daños económicos de fallas en el software para actualizar el presutpuesto del aseguramiento de calidad de software.

52 Métricas en la calidad de software
Objetivos Clasificación Métricas del proceso Métricas del producto Implementación y limitantes de las métricas de software

53 Objetivos y requerimientos de métricas de calidad exitosas
Objetivos de las métricas de calidad Brindar soporte al control del desarrollo del proyecto y al mantenimiento del software. Cumplir en las funcionalidades requeridas y dentro del tiempo y presupuesto contempaldo para el proyecto. Entregar métricas acumuladas y analizadas para establecer acciones preventivas y correctivas a través de la organización. Requerimientos para métricas de calidad exitosas Requerimientos generales Relevante; válidas; confiables; comprensibles; excluyentes Requerimientos operativos Fácil y sencillo para obtener los datos; datos propios de la operación; libre de intereses particulares de algún miembro del equipo.

54 Métricas en la calidad de software
Métricas del proceso Calidad Bitácoras Productividad Métricas del producto Métricas de productividad y efectividad de los servicios en producción Metricas de mantenimientos correctivos Métricas de productividad y efectividad en mantenimiento correctivo del software

55 Métricas del proceso Métricas del proceso Calidad Bitácoras
Métricas de densidad de errores Métricas de severidad de errores Métricas de efectividad para remover los errores Bitácoras Lograr hitos en los tiempos establecidos en la calendarización del proyecto. Productividad Métricas directas, relacionadas con la productividad del capital humano. Métricas indirectas, se enfocan en el reuso del software  Productividad (desarrollo; puntos de función) Efectividad (reuso de código o documentación)

56 Factores de calidad de McCall
Facilidad de mantenimiento Flexibilidad Facilidad de prueba Portabilidad Reusabilidad Ineroperatividad Revisión del producto Transición del producto Operación del producto Es interesante anotar que los factores de calidad de McCall son válidos hoy como cuando fueron los primeros propuestos en los años 70. Además, es razonable indicar que los factores que afectan a la calidad del software no cambian. Todo programa hace algo correctamente, que puede no ser lo que necesitamos que haga. Anónimo Factores de calidad de McCall Corrección Fiabilidad Usabilidad Integridad Eficiencia

57 Factores de calidad de McCall
Aspectos de un producto de software Factor Breve descripción Características operativas Corrección Hasta dónde satisface un programa su especificación y logra los objetivos propuestos por el cliente. Fiabilidad Hasta dónde se puede esperar que un programa lleve a cabo su función con la exactitud requerida. Eficiencia La cantidad de recursos informáticos y de ódigo necesarios para que un programa realice su función. Integridad Hasta dónde se puede controla el acceso al softwae o a los datos por personas no autorizadas. Usabilidad (facilidad de manejo) El esfuerzo necesaro para aprender a operar con el sistema, preparar los datos de entrada e interpretar las salidas. Capacidad de cambios o revisión del producto Facilidad de mantenimiento El esfuerzo necesario para localizar y arreglar un error en un programa. Flexibilidad El esfuerzo necesario para modificar un progrmaa que ya está en funcionamiento. Facilidad de prueba El esfuerzo necesario para probar un programa y asegurarse de que realiza correctamente su función. Adaptabilidad a nuevos entornos o transición del producto Portabilidad El esfuerzo necesario para transferir el programa de un entorno hw/sw a otro entorno diferente. Reusabilidad Hasta dónde se puede volver a emplear un progrmaa (o partes) en otras aplicaciones. Interoperatividad El esfuerzo necesario para acoplar un sistema con otro.

58 Cómo caracterizar el proceso de software
Marco de trabajo común del proceso Actividades de protección Actividades del marco de trabajo Conjuntos de tareas Tareas Hitos, entregas Puntos SQA Seleccione un marco de trabajo del proceso común que se adecue al producto, al personal y al proyecto. Cómo caracterizar el proceso de software

59 Tema 6. Análisis y reporte de problemas.
Evaluarán la densidad de los defectos

60 Corrección de defectos, acciones preventivas y correctivas
Correción de defectos Es la solución inmediata de defectos detectados en un proyecto o sistema de software. Acciones preventivas o correctivas Tienen un alcance mayor; pretenden inicializar y guiar el desempeño de acciones en la organización que eliminen las causas de faltas conocidas o potenciales.

61 Tipos de recursos internos sujetos a correcciones o acciones preventivas y correctivas
Proceso de desarrollo de software Mantenimiento de software Procedimientos en infraestructura de SQA Procedimientos de administración de la calidad de software Actualizar procedimientos relevantes Cambiar las prácticas en el desarrollo y mantenimiento del software y actualizar las instrucciones de trabajo. Cambiar o modernizar herramientas de trabajo Mejorar métodos para reportar contenidos y frecuencias (detección temprana de faltas y reducir los daños). Iniciar entrenamientos, repetirlos o actualizar al staff.

62 Plantillas en el aseguramiento de calidad de software
Los documentos realizados para las revisiones son más completos. Como resultado, el equipo se puede concentrar más en mejorar para el producto final. Las revisiones a los documentos se facilitan, pues la estructura es estándard y bien conocida por los revisores. Los revisores se concentran en el contenido. Los formatos principales son: El plan de pruebas La descripción de las pruebas Reportes de pruebas

63 Listas de verificación en el aseguramiento de calidad
Brindan soporte para asegurar que los documentos están realizados de forma completa y para mejorar la calidad del documento, en la medida que los elementos relevantes que deben ser revisados están listados. Conducen las sesiones de revisión y es menos problemático cuando los tópicos y sus prioridadees ya están definidas y son bien conocidas por los participantes. Una revisión eficiente se trabaja sobre los comentarios de análisis de los revisores.

64 Elementos para métricas de pruebas
Los responsables de las pruebas deben fiarse de las métricas de análisis, diseño y código para que les guíen en el diseñó y ejecución de los casos de prueba. Las métricas de la prueba desembocan en las siguientes categorías: Métricas que ayudan a determinar el número de pruebas requeridas en los distintos niveles de la preuba; Métricas para cubrir la prueba de un componente dado.

65 Tema 7. Herramientas estadísticas para el control de calidad.
Evaluarán la densidad de los defectos

66 Herramientas estádisticas básicas para la calidad
Kauru Ishikawa promulgó la utilización de siete herramientas básicas de la calidad: Gráficas de barras e histogramas Listas de verificación Diagramas de Pareto Diagramas de dispersión Diagramas causa-efecto Estratificación Gráficos de control

67 Herramientas estádisticas básicas para la calidad
Kauru Ishikawa promulgó la utilización de siete herramientas básicas de la calidad: Diagramas de Pareto Regla 80/20. Si se tiene un problema con muchas causas, podemos decir que el 20% de las causas resuelven el 80 % del problema y el 80 % de las causas solo resuelven el 20 % del problema. Diagramas causa-efecto o diagramas de espina de pescado o diagramas de Ishikawa Muestran la relación entre un problema de calidad de importancia clave y las posibles causas que lo originan. Primero se determinan las categorías de causas y luego causas específicas en los niveles en que sea necesario.

68 Tema 8. Estándares de calidad del proceso y del producto.
Establecerán el proceso de aseguramiento de calidad

69 Beneficios de usar estándares en el aseguramiento de calidad de software
Habilidades para utilizar las metodologías y procedimientos profesionales más sofisticados y comprensibles. Mejor entendimiento, colaboración y cooperación entre usuarios de los mismos estándares: Entre miembros del equipo y entre equipos del proyecto. Entre desarrolladores del software y participantes extenos en el proyecto. Entre proveedores y clientes.

70 Contribuciones realizadas por el uso de estándares
Brindar metodologías profesionales para su uso en el proceso de desarrollo y su administración. Certificación en servicios de aseguramiento de calidad basados en auditorias de calidad por parte de profesionales independientes. Herramientas para reconocer las capacidades propias de logros en la planeación y organización de un sistema de aseguramiento de calidad.

71 Comparativo :: Clases de estándares en sqa
Características Estándares de administración de calidad Estándare para los procesos del proyecto La unidad meta Administración del desarrollo y mantenimiento del software y las unidades específicas de SQA Equipo de proyecto para desarrollo y mantenimiento de software Enfoque principal Organización de los sistemas de SQA, infraestructura y requerimientos Metodolgías para realizar proyectos de desarrollo y mantenimiento de software Objetivos del estándar Qué a lograr Cómo a desempeñar Metas del estándar Asegurar la calidad del software de proveedores e inventariar las capacidades de sus procesos de software Asegurar la calidad de un proeycto de software específico Ejemplos ISO ; CMMI; ISO/IEC 12207; IEEE Std

72 Ejemplos de estándares en uso
Administración de la calidad de software Ciclo de vida del desarrollo de software ISO IEEE Std Planes para aseguramiento de caldiad de software IEEE/IEA 12207 IEEE Std Verificación y validación de software IEEE Std Métricas de productividad de software

73 Tendencias en el desarrollo de estándares
Joint ventures IEEE/ANSI ISO/IEC IEEE/ISO Adopción de estándares internacionales , como estándares nacionales, por institutos nacionales de estándares Aplicación de estándares en la industria de software con cobertura mundial: ISO/IEC :: Estándares de certificación de calidad para organizaciones de desarrollo y mantenimiento de software. ISO/IEC :: Inventario de capacidades en procesos de software ISO/IEC/IEEE :: Prácticas en el desarrollo de software

74 Estándar de calidad iso 9001
Está expresado en términos generales, y puede ser interpretado por los desarrolladores de diversos productos. Para la industria del software los estándares relevantes son: ISO Quality Systems – Model for Quality Assurance in Design, Development, Production, Installation and Servicing. Describe el sistema de calidad utilizado para mantener el desarrollo de un producto que implique diseño. ISO Guidelines for Application of ISO 9001 to the Developments, Supply and Maintainance of Software. Documento específico para el desarrollador de software. ISO Quality Management and Quality System Elements – Part 2 -. Directrices para los servicios en software, como soporte de usuarios.

75 Tema 9. Procesos y entidades certificadoras de calidad de software.
Conocerán los procesos más importantes de certificación de software

76 CMMI Define practicas y bjetivos que han
demostradro ser útiles en la industria Dirigido primordialmente a organizaciones grandes Se enfoca en procesos‭: ‬explícitos‭, ‬documentados‭, ‬ reproducibles‭, ‬medibles y auto-mejorables Esencial para la industria del outsourcing Tecnológicamente neutral

77 Áreas de proceso de CMMI
Cada nivel de madurez requiere que se‭ ‬cumpla con ciertas‭ áreas de proceso (Key‭ ‬process areas)‭ Una‭ ‬área de proceso es‭ ‬unconjunto de prácticas relacionadas que son ejecutadas de forma conjunta para conseguir un conjunto de objetivos Una‭ ‬área de proceso propone qué hacer mas NO cómo hacerlo Cada‭ ‬área requiere Cumplir con los 5‭ ‬niveles posibles de capacidad‭ (‬Objetivos Generales‭)‬ Cumplir con los requerimientos específicos‭ (‬Objetivos Específicos‭)‬

78 Objetivos particulares de cada área
Cada‭ ‬área señala una serie de objetivos a cumplir u objetivos particulares Éstos puntualizan las particularidades‭ ‬que describen lo que se debe implementar para satisfacer el propósito del‭ ‬área

79 CMMI® for Services, Version 1.2 CMMI-SVC, V1.2
The Three Critical Dimensions

80 CMMI® for Services, Version 1.2 CMMI-SVC, V1.2

81 CMMI® for Services, Version 1.2 CMMI-SVC, V1.2
CMMI Model Components

82 CMMI® for Services, Version 1.2 CMMI-SVC, V1.2
Comparison of Capability and Maturity Levels

83 Marcos de referencia para TI
CMMI – SCAMPI MoProSoft – EvalProSoft eSCM-CL / eSCM-SP ITIL PSP TSP COBIT SPICE Etc.

84 El caso del java community process
Mecanismo regulador de la plataforma java Integrado por industrias e individuos Alta vinculaciòn con el ambito empresarial Basado en especificaciones JSR. Java Specification Request Ejemplo institucional de un marco ad hoc para el aseguramiento de la calidad de cada especificación.

85 Discusiones finales