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
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
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
驴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.
Implicaciones
Disposici贸n
Trabajo en Equipo
Etapa de la calidad
Mejora de la calidad
Calidad total
Mejora continua
Aseguramiento de la calidad
Prevenir defectos Control de la calidad
Detectar defectos
Tiempo
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.
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)
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.
Gesti贸n
Mejorar
Definir y planificar
Medir
Controlar Ejecutar
Características Caracterís Descripción tica Comprensi ón
Definición y especificación del proceso para garantizar el entendimiento por parte del equipo y la organización.
Visibilidad
Definición de resultados concretos de cada actividad para garantizar la visibilidad del progreso.
Apoyo
Posibilidad de soporte tecnológico para el desarrollo de actividades del proceso.
Aceptación
El proceso es aceptable (viable) y utilizable por parte de los equipos de desarrollo.
Fiabilidad
El proceso está diseñado para identificar y manejar los errores del proceso antes de que los errores se trasladen al producto.
Robustez
EL proceso puede continuar a pesar de los sucesos inesperados.
Mantenibili dad
El proceso puede evolucionar para reflejar los cambios en la organización o las mejoras a partir de los errores.
Rapidez
Cuán rápido se puede ejecutar el proceso para obtener un producto a partir de una especificación.
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
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)
Capability Maturity Model Integration
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/
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
Esquema de Madures CMMI Resultados cuantificados, con opci贸n de mejora N5. Repetible
Medidas de Producto y Proceso. Registro de valores de Calidad N4. Gestionado
Desarrollo y Mantenimiento documentado y Estandarizado N3. Definido
Gesti贸n del proceso seguimiento de: coste, planificaci贸n y funcionalidad N2. Repetible
N1. Inicial
El 茅xito del proceso depende del esfuerzo individual
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.
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.
eXtreme Programming (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.
eXtreme Programming (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 Programming Explained. 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.
Planificaci贸n/ Ciclos de Retroalimentaci贸n
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.
SCRUM
Rational Unified Process 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.
Ciclo de vida RUP
Calidad del Producto de Software
Ciclo de vida de software
Análisis 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 yMantenimiento 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.
Integración
Diseño
Codificación
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.
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
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.
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: Es la 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.
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
Modelos de calidad del Software
x
x x x x
x x
x
x
x x
x
x x
x
x
x
x x
x x
x
x
x
x
x
x
x
x
x
atributo
subcaracterĂstica
atributos internos
caracterĂstica
atributos externos
Modelo de McCall Visión de la dirección Visión de usuario
Operación de producto
Facilidad de uso Seguridad (integridad)
Eficiencia Corrección (exactitud)
Visión del desarrollador Operabilidad Familiarización Comunicatividad Volumen y tasa de E/S Datos comunes Control y audit. de acceso Integridad de datos Eficiencia de almacenam. Eficiencia de ejecución
Fiabilidad
Revisión de producto
Facilidad de mantenimiento Facilidad de prueba Flexibilidad
Transición de producto
Capacidad de reutilización Transportabilidad Interoperabilidad
Compleción Trazabilidad Consistencia Precisión Tolerancia a errores Simplicidad Concisión Autodescriptividad Modularidad Instrumentación Capacidad de ampliación Generalidad Indep. máquina Indep. soft. de sistema Comunicac. comunes
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.
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 Product Quality) e ISO/IEC 14598 (Software Product Evaluation).
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.
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
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.
Ejemplo ISO/ IEC 9126
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.
Métrica
Métricas para determinar los factores de calidad: • 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
• Generalidad • Independencia del hardware • Instrumentación • Modularidad • Facilidad de operación • Seguridad • Auto-documentación • Simplicidad • Independencia del sistema • Facilidad de traza • Formación
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.
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.
Campo de acci贸n
En la p谩gina Testingreference s han creado un diagrama con parte de la historia del testing para ver sus inicios y la evoluci贸n.
Gracias !!!