Calidad del software y factores para su aseguramiento

1. Calidad del software y factores para su aseguramiento Gabriel G. Barrios Martínez Ingeniero de Sistemas – Universidad del Magdalena Auditor Interno de Calidad – Universidad del Magdalena Gerencia de Proyectos Informáticos – SENA Regional Magdalena Fundamentos de la Calidad para la gestión pública Desarrollo y Administración de SIARE – Recursos Educativos

2. Definición de Calidad “Es la totalidad de las características o rendimiento, que puede ser usado para determinar si un producto cumple o no su aplicación prevista o intencionada” Japanese Industrial Standard JIS z8110-1981 “Conjunto de propiedades y características de un producto o servicio, que le confiere la aptitud para satisfacer necesidades explícitas o implícitas” ISO 8402 “El grado en que un producto, proceso o sistema cumple con sus requerimientos”IEEE 610.12

3. Definición de Calidad La calidad no es absoluta, puede tomar diferentes puntos de vistas dependiendo las diversas situaciones. Existen muchos factores que contribuyen a la calidad. Algunos aspectos pueden ser medidos y otros no. Funcionalidad Oportunidad Costo

4. ¿Cómo saber que obtuve calidad? comparando entre unos requisitos preestablecidos y el producto realmente desarrollado. Requisitos preestablecidos: Definir las necesidades o requisitos que quiere el cliente o usuario, y planificar o especificar lo que se intenta conseguir. Producto desarrollado: Comparar lo que se ha conseguido y medir lo que el cliente valora.

5. Implicaciones Disposición Compromiso Lleva a: Inversión Conflictos Trabajo en Equipo

6. Etapa de la calidad Calidad total Mejora de la calidad Aseguramiento de la calidad Mejora continua Control de la calidad Prevenir defectos Detectar defectos Tiempo

7. Calidad del software ¿Qué es la Ingeniería de Software? • “Estudio de los principios y metodologías para desarrollar y mantener el software”. Zelkowitz. • “Es la aplicación práctica del conocimiento científico en el diseño y construcción de programas de computador y la documentación apropiada para desarrollarlos, operarlos y mantenerlos”. Boehm. Características del software: • Se desarrolla no se fabrica. • Se deteriora por la aparición de nuevas tecnologías. • Se desarrolla a la medida. • Posee un ciclo de vida.

8. Proceso de Gestión de Software Un producto de software con calidad se desarrolla bajo un proceso de software. Proceso Software es: “Un conjunto coherente de políticas, estructuras organizacionales, tecnologías, procedimientos y artefactos que son necesarios para concebir, desarrollar, instalar y mantener un producto software.” (Fuggetta, A. (2000): Software Process: A Roadmap. International Conference on Software Engineering)

9. Beneficio y Perjuicios Beneficio de los procesos de software Los procesos permiten que los productos sean repetibles, sostenibles, continuos y finitos. También genera base de conocimientos, oportunidad de mejoras, organiza y evita redundancia de trabajo. Perjuicios de los procesos de software Sí no se lleva una adecuada gestión del proceso de software, se puede caer en ciclo infinitos para el desarrollo del producto, convirtiéndose en procesos complejos y difícil de administrar.

10. Gestión Mejorar Definir y planificar Medir Controlar Ejecutar

11. Características Ing. Ernesto A. Galvis L. MSc. Prog. Ingenieria de Sistemas Universidad del Magdalena Diplomado en Gestión de la Calidad del Software 2008 - Calidad del Proceso Juan Pavón Mestras - Facultad de Informática UCM, 2004 Proceso del software

12. Modelos Definen las actividades para la gestión de un proyecto de software. • Capability Maturity Model Integration (CMMI) • ISO/IEC 12207 • eXtreme Programming (XP) • Open Unified Process (OpenUP). • Scrum. • Rational Unified Process (RUP)

13. CapabilityMaturityModelIntegration CMMI (Capability Maturity Model Integration) es un enfoque de mejora de procesos que proporciona a las organizaciones los elementos esenciales de procesos efectivos. CMMI basado en la mejora del proceso incluye la identificación de las fortalezas de su organización, procesos y debilidades; además hacer cambios en el proceso, de convertir debilidades en fortalezas. Fue desarrollado inicialmente para los procesos relativos al desarrollo e implementación de software por la Universidad Carnegie-Mellon para el SEI (Software Engineering Institute). Software Engineering Institute - http://www.sei.cmu.edu/cmmi/

14. CMMI Este modelo establece un conjunto de prácticas o procesos clave agrupados en Áreas Clave de Proceso (KPA - Key Process Area). Para cada área de proceso define un conjunto de buenas prácticas que habrán de ser: • Definidas en un procedimiento documentado • Provistas (la organización) de los medios y formación necesarios • Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas) • Medidas • Verificadas

15. Esquema de Madures CMMI N5. Repetible Resultados cuantificados, con opción de mejora Medidas de Producto y Proceso. Registro de valores de Calidad N4. Gestionado Desarrollo y Mantenimientodocumentado y Estandarizado N3. Definido Gestión del procesoseguimiento de: coste, planificación y funcionalidad N2. Repetible N1. Inicial El éxito del proceso depende del esfuerzo individual

16. ISO/IEC 12207 Tomo como base a la norma británica BS 5750 de 1987, y sufrió su mayor crecimiento a partir de la versión de 1994. La versión actual data de del 13 de Noviembre de 2008. Establece un marco común para los procesos de software de ciclo de vida, con una terminología bien definida, que puede hacer referencia a la industria del software. Contiene procesos, actividades y tareas que se van a aplicar durante la adquisición de un producto de software o servicio y durante el suministro, desarrollo, operación, mantenimiento y eliminación de productos de software.

17. ISO/IEC 12207 Se aplica a la adquisición de sistemas y productos de software y servicios, con el suministro, desarrollo, operación, mantenimiento y eliminación de productos de software y la parte de software de un sistema, ya sea de forma interna o externa a la organización. Aquellos aspectos de la definición del sistema necesario para proporcionar el contexto para los productos de software y servicios están incluidos.ISO / IEC 12207:2008 proporciona también un proceso que puede ser empleado para definir, controlar y mejorar los procesos de software de ciclo de vida.

18. eXtremeProgramming (XP) Es una de las llamadas Metodologías Agiles de desarrollo de software. La programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. Se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico.

19. eXtremeProgramming (XP) Los Valores originales de la programación extrema son: simplicidad, comunicación, retroalimentación (feedback) y coraje. Un quinto valor, respeto, fue añadido en la segunda edición de Extreme ProgrammingExplained. Simplicidad: Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento; Para mantener la simplicidad es necesaria la refactorización del código. También se aplica la simplicidad en la documentación, de esta manera el código debe comentarse en su justa medida. Comunicación: Para los programadores el código comunica mejor cuanto más simple sea. Debe comentarse sólo aquello que no va a variar. Los programadores se comunican constantemente gracias a la programación por parejas. La comunicación con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. Retroalimentación (feedback): Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es más importante. Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a cambios recientes en el código. Coraje : Diseñar y programar para hoy y no para mañana necesita de valentía y coraje. Otro ejemplo de valentía es saber cuando desechar un código: valentía para quitar código fuente obsoleto. Además, valentía significa persistencia: un programador puede permanecer sin avanzar en un problema complejo por un día entero, y luego lo resolverá rápidamente al día siguiente, solo si es persistente. Respeto: Los miembros respetan su trabajo porque siempre están luchando por la alta calidad en el producto y buscando el diseño óptimo o más eficiente para la solución a través de la refactorización del código. Los miembros del equipo respetan el trabajo del resto no haciendo menos a otros, una mejor autoestima en el equipo y elevando el ritmo de producción en el equipo.

20. Planificación/ Ciclos de Retroalimentación

21. SCRUM Es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software. Aunque estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de programas. Hoy en día es usado por empresas de todos los tamaños tales como Yahoo!, Microsoft, Google, Lockheed Martin, Motorola, SAP, Cisco, GE, CapitalOne y la Reserva Federal de EE.UU.

22. SCRUM

23. RationalUnifiedProcess Es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. No es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización. El RUP está basado en 6 principios clave que son los siguientes: • Adaptar el proceso : El proceso deberá adaptarse a las necesidades del cliente, las características propias del proyecto u organización. El tamaño del mismo, así como su tipo o las regulaciones que lo condicionen. • Equilibrar prioridades: Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. • Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados. • Colaboración entre equipos: El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc. • Elevar el nivel de abstracción: Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificación de software a la medida del cliente, sin saber con certeza qué codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde un principio pensando en la reutilización del código. • Enfocarse en la calidad: El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.

24. Ciclo de vida RUP

25. Calidad del Producto de Software Ciclo de vida de software Es la forma mediante la cual se describen los diferentes pasos que se deben seguir para el desarrollo de un software, partiendo desde una necesidad hasta llegar a la puesta en marcha de una solución y su apropiado mantenimiento. El ciclo de vida para un software comienza cuando se tiene la necesidad de resolver un problema, y termina cuando el programa que se desarrolló para cumplir con los requerimientos, deja de ser utilizado.

26. Definición del producto de software Un producto de software es el conjunto de programas (fuentes y ejecutables), procedimientos, reglas y documentación posible asociada, así como los datos pertenecientes a la operación del sistema.

27. Calidad del Producto de Software Luis Olsina en su metodología Web QEM plantea un modelo jerárquico de calidad de producto y desarrolla un marco conceptual de calidad. El marco conceptual define cuatro factores de calidad: • Calidad de recurso • Calidad de proceso • Calidad de producto • Calidad en uso

28. Calidad del Producto de Software Marco conceptual de calidad propuesto por Olsina Fuente: GONZÁLEZ R. Julia. OLSINA, Luis. Hacia la medición de calidad en uso Web. 2001.

29. Calidad del Producto de Software Calidad Externa: no intenta evaluar las propiedades intrínsecas del producto, se refiere a la perspectiva del usuario con relación a la calidad del producto al ser utilizado en un ambiente y contexto específico. Calidad Interna: Esla totalidad de características del software producidas desde una perspectiva interna. Dichas características permanecen generalmente constantes a lo largo del ciclo de vida del software, aunque éste sea rediseñado y programado nuevamente. Calidad en Uso:se refiere a la perspectiva del usuario con relación a la calidad del producto al ser utilizado en un ambiente y contexto específico, es decir, si los usuarios pueden lograr sus metas usando el producto.

30. Modelos de calidad del Software Los modelos de calidad de software surgieron a mediados de los años 70’s. Los modelos permiten evaluar la calidad de un producto de software definiendo objetivos específicos de calidad. Uno de los enfoques más utilizados para modelos de calidad de software consiste en descomponer jerárquicamente la calidad en características, sub-características, atributos, ítems, entre otros, que pueden ser utilizados como puntos clave en la observación de los aspectos relevantes del producto a evaluar. Algunos de los modelos más utilizados son: • · Modelo de Gilb • · Modelo de McCall • · Modelo de Boehm • · Modelo FURPS (Hewlett Packard) • · Modelo propuesto por la norma ISO/IEC 9126

31. Modelos de calidad del Software

32. Visión de la dirección Visión del desarrollador Visión de usuario Operabilidad Facilidad de uso Familiarización Comunicatividad Seguridad (integridad) Volumen y tasa de E/S Operación de Datos comunes producto Eficiencia Control y audit. de acceso Integridad de datos Corrección (exactitud) Eficiencia de almacenam. Eficiencia de ejecución Fiabilidad Compleción Trazabilidad Revisión de Facilidad de Consistencia mantenimiento producto Precisión Facilidad de Tolerancia a errores Simplicidad prueba Concisión Flexibilidad Autodescriptividad Modularidad Transición de Capacidad de Instrumentación reutilización producto Capacidad de ampliación Generalidad Transportabilidad Indep. máquina Indep. soft. de sistema Interoperabilidad Comunicac. comunes Modelo de McCall

33. Modelo de Boehm Fuente: OLSINA, Luis. Métricas, Criterios y Estrategias para Evaluar Calidad Web Parte II - Requerimientos de Calidad para Diseño y Evaluación. Facultad de Ingeniería, UNL Pam, Argentina.

34. NORMA ISO/ IEC 9126 La norma internacional ISO/IEC 9126 proporciona las guías de un modelo de calidad para un producto de software. Esta norma sigue el esquema propuesto por los modelos anteriores (McCall, Boehm, etc), además, retoma algunas de las características planteadas por dichos modelos, pero puntualiza seis características que considera fundamentales en la evaluación de calidad de un producto de software (funcionalidad, confiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad). Debido a la variedad existente en cuanto a modelos de calidad para tecnologías de software, en la década del 70 surgió la necesidad de desarrollar un modelo estándar para la evaluación de la calidad de los productos de software. Así, el ISO/IEC JTC119 se lanzó al desarrollo de esta tarea. En el año de 1991, salió al mercado la primera versión de la Norma. En el año 2001 dicha norma se reemplazó por dos nuevas versiones: ISO/IEC 9126 (Software ProductQuality) e ISO/IEC 14598 (Software ProductEvaluation).

35. NORMA ISO/ IEC 9126 Características para la calidad interna y externa: • Funcionalidad: El producto software debe implementar los requerimientos solicitados por el usuario, de tal forma que éste lo pueda utilizar para los fines esperados, de una forma segura y precisa. • Confiabilidad: El producto software debe realizar sus funciones conservando los niveles de desempeño deseados, bajo condiciones específicas. • Facilidad de uso / Usabilidad: Esta característica indica que se debe observar en el producto de software la capacidad para que su lógica sea entendida por el usuario, así como la facilidad en el aprendizaje de las operaciones de entrada y salida de datos. • Eficiencia: La eficiencia del producto software se debe observar no sólo en el tiempo de CPU sino en la consideración de los recursos empleados , tanto materiales como humanos. • Mantenimiento: Un producto de software, debe ser modificado con cierto grado de facilidad. Las modificaciones pueden incluir correcciones, mejoras o adaptaciones del software a cambios en el entorno, en los requisitos o en las especificaciones funcionales. • Portabilidad: El producto software debe tener la capacidad de ser instalado en un amplio abanico de entornos, con la posibilidad de ser transferido de uno a otro.

36. NORMA ISO/ IEC 9126 Modelo de calidad interna y externa propuesto por la Norma ISO/IEC 9126 (2001) Fuente: Elaboración propia con base en la Norma ISO/IEC 9126

37. NORMA ISO/ IEC 9126 El modelo de calidad en uso propuesto por la Norma expone cuatro características: • Efectividad: Esta característica se refiere a la capacidad del producto de software para brindar la posibilidad a los usuarios de alcanzar metas u objetivos especificados con exactitud y completitud en un contexto de uso particular. • Productividad: Esta característica se refiere a la capacidad del producto de software para permitir a los usuarios demandar una cantidad apropiada de recursos (como tiempo, esfuerzo, materiales y costos , entre otros) en relación a la efectividad alcanzada en un contexto de uso específico. • Seguridad: Esta característica se refiere a la capacidad del producto de software para alcanzar niveles aceptables de riesgo en un contexto especial. • Satisfacción: Esta característica se refiere a la capacidad del producto de software para satisfacer a los usuarios en un marco de trabajo particular, entendiendo por satisfacción como una respuesta de los usuarios a la interacción con el producto, incluyendo las actitudes producidas frente a su uso.

38. Ejemplo ISO/ IEC 9126

39. Métrica Las métricas son un conjuntos de reglas que ayudan a entender y medir que tan bien o mal esta operando o diseñado un producto de software. Incluyen actividades, tales como: • Estimación de costo y esfuerzos. • Medición de la productividad. • Acumulación de datos. • Elaboración de modelos de seguridad. • Evaluación y modelos de desempeño. • Valoración de las capacidades y la madures. • Administración de métricas. • Evaluación de métodos y herramientas.

40. Métrica Métricas para determinar los factores de calidad: Generalidad Independencia del hardware Instrumentación Modularidad Facilidad de operación Seguridad Auto-documentación Simplicidad Independencia del sistema Facilidad de traza Formación • Facilidad de auditoria • Exactitud • Normalización de las comunicaciones • Completitud • Concisión • Consistencia • Estandarización de los datos • Tolerancia de errores • Eficiencia de la ejecución • Facilidad de expansión

41. Proceso de Evaluación y Modelación Se recomienda realizar los siguientes paso para un proceso de evaluación del producto de software: • Determinación de las condiciones iniciales: Tomar en cuenta condiciones básico para el proceso de evaluación. (las entradas del sistema, sus restricciones, y los servicios que proporciona el sistema). • Selección del atributo de calidad y de sus métricas de software: definir el atributo de calidad de software que pretendemos estudiar. En la selección del atributo influyen las necesidades prioritarias de cada organización en sus productos de software. • Proceso de Medición: La medición del software se refiere a derivar un valor numérico para algún atributo de un producto de software. • Evaluación de los resultados y selección del modelo: La evaluación del proceso de medición la realizamos mediante el estudio de su distribución estadística. Los resultados de esta evaluación permiten analizar el conjunto de datos obtenidos mediante gráficas conocidas como histogramas. • Estimación de los parámetros del modelo: En ocasiones, es necesario aplicar varios métodos para llegar a resultados confiables, y dependiendo del parámetro a estimar algunos métodos son mas adecuados que otros. • Sustitución de los parámetros obtenidos y graficación del modelo resultante: La gráfica obtenida representa el comportamiento del atributo de calidad. • Validación del modelo escogido: Con los parámetros obtenidos debemos verificar que el modelo, tal y como fue construido está de acuerdo con la población de métricas estudiada. Por lo tanto en este proceso, se realiza una comparación de los valores que se obtienen con el histograma contra los resultados que se obtienen con el modelo. • Realización de las predicciones del atributo de calidad: Las predicciones del atributo de calidad se realizan mediante la observación del modelo (o ley de probabilidad) obtenido.

42. Campo de acción En la actualidad, existe mayor conciencia de procesos de calidad. Cada día la demanda de producto de calidad es mayor, al igual es el crecimiento de organizaciones especializadas en certificar la calidad de tales producto. El Tester es uno de los oficios crecientes dentro de la ingeniería de software, debido a que es necesario profesionales especializados en planear, ejecutar y medir características de software. Otra de las profesiones es la Gerencia de Proyectos, la cual juega un papel importante para el alcance de metas y eficiencia del trabajo. También existe un gran campo de acción en el la Gerencia de la Calidad, donde el pensamiento orientado a procesos es fundamental. Acompañando a este tenemos los Auditores que permiten la observación independiente del desarrollador. Además de los oficios tenemos la construcción de herramientas de gestión y de evaluación que cada vez son mas necesaria para el desarrollo eficaz de estos oficios.

43. Campo de acción En la página Testingreferences han creado un diagrama con parte de la historia del testing para ver sus inicios y la evolución.

44. Gracias !!!