Calidad del software y factores Calidad del software y factores para su aseguramientopara su aseguramiento

Gabriel G. Barrios MartínezIngeniero de Sistemas – Universidad del MagdalenaAuditor Interno de Calidad – Universidad del MagdalenaGerencia de Proyectos Informáticos – SENA Regional MagdalenaFundamentos de la Calidad para la gestión públicaDesarrollo y Administración de SIARE – Recursos Educativos

Definición de CalidadDefinició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 CalidadDefinició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.

Oportunidad

Funcionalidad

Costo

¿Cómo saber que obtuve calidad?¿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.

ImplicacionesImplicaciones

Disposición

Conflictos

Comprom

iso

Trabajo en EquipoTrabajo en Equipo

Lleva

a: Inversión

Etapa de la calidadEtapa de la calidad

Mejora dela calidad

Tiempo

Control de la calidad Control de la calidad

Aseguramiento de la calidad

Aseguramiento de la calidad

Calidad total

Detectar defectos

Prevenir defectos

Mejora continua

Calidad del softwareCalidad del software

¿¿Qué es la Ingeniería de 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: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 SoftwareProceso 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 PerjuiciosBeneficio y Perjuicios

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.

Beneficio de los procesos de software

GestiónGestión

Definir y planificar Medir

EjecutarEjecutar

Controlar

Mejorar

CaracterísticasCaracterísticas

Característica Descripción

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.

Mantenibilidad 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 ProcesoJuan Pavón Mestras - Facultad de Informática UCM, 2004 Proceso del software

ModelosModelos

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)

CCapability apability MMaturity aturity MModel odel IIntegrationntegration

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/

CMMICMMI

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 documentadoProvistas (la organización) de los medios y formación necesariosEjecutadas de un modo sistemático, universal y uniforme

(institucionalizadas)MedidasVerificadas

Esquema de Madures CMMIEsquema de Madures CMMI

N1. InicialN1. Inicial

N2. RepetibleN2. Repetible

N3. DefinidoN3. Definido

N4. GestionadoN4. Gestionado

N5. RepetibleN5. Repetible

El éxito del proceso depende del esfuerzo individualEl éxito del proceso depende del esfuerzo individual

GestiónGestión del del procesoproceso seguimientoseguimiento de: coste, de: coste, planificación y funcionalidadplanificación y funcionalidad

DesarrolloDesarrollo y y MantenimientoMantenimiento documentadodocumentado y y EstandarizadoEstandarizado

Medidas de Medidas de Producto y ProcesoProducto y Proceso. Registro de valores . Registro de valores de Calidadde Calidad

Resultados cuantificados, con opción de mejoraResultados cuantificados, con opción de mejora

ISO/IEC 12207ISO/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 12207ISO/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 (eXtreme Programming (XPXP))

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 (eXtreme Programming (XPXP))

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ónPlanificación/ Ciclos de Retroalimentación

SCRUMSCRUM

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.

SCRUMSCRUM

Rational Unified ProcessRational 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 RUPCiclo de vida RUP

Calidad del Producto de SoftwareCalidad 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.

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.

Definición del producto de softwareDefinició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 SoftwareCalidad 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 SoftwareCalidad 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 SoftwareCalidad 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 SoftwareModelos 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 SoftwareModelos de calidad del Software

x

xx

x

x

x

x

x

x

xx

x

x

xx

x

x

x

xx

x

xx

x

x

x

x

x

x

x

atributo

subcaracterística

característicaatributos internos atributos externos

ModeloModelo de McCall de McCall

Operación deproducto

Revisión deproducto

Transición deproducto

Facilidad de uso

Seguridad (integridad)

Eficiencia

Corrección (exactitud)

Fiabilidad

Facilidad de mantenimientoFacilidad depruebaFlexibilidad

Capacidad de reutilización

Transportabilidad

Interoperabilidad

OperabilidadFamiliarizaciónComunicatividadVolumen y tasa de E/SDatos comunes

Control y audit. de accesoIntegridad de datos

Eficiencia de almacenam.Eficiencia de ejecución

Compleción

Capacidad de ampliación

Trazabilidad

Concisión

PrecisiónTolerancia a erroresSimplicidad

Consistencia

ModularidadAutodescriptividad

Instrumentación

GeneralidadIndep. máquinaIndep. soft. de sistemaComunicac. comunes

Visión de usuarioVisión de la dirección Visión del desarrollador

Modelo de BoehmModelo 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 9126NORMA 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 funcionalidad, confiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidadportabilidad).

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 9126NORMA 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 9126NORMA 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 9126NORMA 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 9126Ejemplo ISO/ IEC 9126

MétricaMé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étricaMétrica

• 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

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

Proceso de Evaluación y ModelaciónProceso 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ónCampo 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ónCampo de acción

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

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

Gracias !!!Gracias !!!