Implantación de Calidad de Software

1. Implantación de Calidad de Software Unidad I. Conceptos de Calidad

2. 1.1. Calidad • ¿Qué es Calidad?

3. Definición de Calidad • Definición de Calidad: • Según el Diccionario de la Real Academia Española de la Lengua, la calidad es: • Propiedad o conjunto de propiedades inherentes a algo, que permiten juzgar su valor. • Buena calidad, superioridad o excelencia. • Carácter, genio, índole. • Condición o requisito que se pone en un contrato.

4. Definición según la ISO • “Conjunto de propiedades o caracteristicas de un producto o servicio que le confieren aptitud para satisfacer unas necesidades expresadas o implícitas”. • La calidad suele ser transparente cuando esta presente pero resulta fácilmente reconocible cuando está ausente (por ejemplo, cuando el producto falla o el servicio es deficiente).

5. Definición de la Calidad • La calidad se ha convertido hoy en día en uno de los principales objetivos estratégicos para las organizaciones. • Cada vez mas la supervivencia de las organizaciones depende de la calidad de los productos y servicios. “No me preocupa si algo es caro o barato. Solo si es bueno. Y si algo es lo Suficientemente bueno, entonces el público pagará por ello” Walt Disney

6. Definición de Calidad • “La calidad de producto o servicio puede ser definida como las características totales compuestas de producto y servicio de marketing, ingeniería, fabricación y mantenimiento por medio de las cuales el producto y servicio cumplirá las expectativas del cliente”. Armand V. Feigenbaum Tarea: Buscar otras definiciones de calidad de los siguientes autores: Joseph M. Juran, W. Edwards Deming, Karou Ishikawa .

7. Calidad • La Calidad se refiere a características mesurables: cosas que se pueden comparar para conocer estándares. • Se pueden mencionar dos tipos de calidad: • Calidad de diseño: Se refiere a las características que los diseñadores especifican para un elemento. • Calidad de concordancia: Es el grado en el que las especificaciones de diseño se aplican durante la fabricación. • ¿Cómo podemos definirla? Satisfacción del usuario = producto manejable + buena calidad + entrega dentro de presupuesto y tiempo

8. Calidad de Software • La calidad de software ha sido significativamente mejorada en los últimos 15 años. • Las compañías han adoptado nuevas técnicas y metodologías, para manejar y mejorar la calidad de sus productos. • La calidad de software es un concepto complejo que es muy distinto a la calidad que se da en productos manufacturados. ¿Por qué?

9. Error común respecto a la calidad: “pensar que la calidad de software es algo que se debe de comenzar a preocupar solo después de que se haya generado código”. • La gestión de la calidad es una actividad protectora o de sombrilla que se aplica a lo largo del proceso de software.

10. Calidad de Software • Se dice que en los productos manufacturados se debe de cumplir con la especificación que se dio para los mismos, sin embargo en el software existen problemas como: • La especificación se debe de orientar hacia las características del producto que el cliente quiere. Sin embargo, la empresa desarrolladora del software tiene otros requerimientos (además de los solicitados por el cliente). ¿Cuáles son éstos?

11. (Cont.) Problemas con la especificación de Calidad de Software: • Algunas veces no se sabe como especificar ciertas características de calidad (por ejemplo la facilidad para dar mantenimiento). • Es difícil escribir de manera completa las especificaciones de software.

12. Manejando la Calidad de Software • La calidad de software puede obtenerse definiendo estándares y procedimientos de calidad en la organización que verifiquen que los estándares sean seguidos por los equipos de desarrollo. • Sin embargo no solo el seguimiento de los estándares y las buenas prácticas harán que el software que se construya sea de buena calidad. • Se debe de construir en la empresa una cultura de buena calidad.

13. Actividades principales para el manejo de la calidad • Aseguramiento de la calidad. Establecer una red de procedimientos organizacionales y estándares que conducen a la alta calidad de software. • Planificación de la Calidad. La selección de procedimientos y estándares, que se adapten a especificaciones de proyectos de software. • Control de la calidad. La definición y propagación de procesos que aseguren que el equipo de desarrollo de software ha seguido los procedimientos de calidad y los estándares.

14. La mejora de la calidad de software tiene los siguientes principios básicos • Las mejoras con éxito se inician desde y son lideradas por la Alta Dirección de la organización. • La mejora de calidad del software requiere inversiones, planificación, personal dedicado, dedicación de los gerentes y capital. • La mejora de la calidad del software es un trabajo de equipo: los que no participan no solo no obtienen los beneficios, sino que pueden impedir el progreso. Al final, toda la organización está involucrada en la mejora continua.

15. Necesidades de la org. y objetivos del negocio Normas de la industria Peticiones de mejora de la calidad Objetivos de mejora tras anteriores evaluaciones o auditorías. Mejora de la calidad Mejoras en los procesos de la organización Mejoras en los productos Software de la organización Petición de nuevas evaluaciones o auditorías Planes de mejora

16. Calidad Programada Calidad Necesaria Calidad Realizada • La gestión de la calidad pretenderá conseguir que estos tres círculos coincidan lo mas posible. Todo lo que este fuera de dicha coincidencia será motivo de derroche, de gasto superfluo o de insatisfacción.

17. Lo que sirve a unos... puede no servir a otros...

19. Aplicando Calidad • Para que las mejoras sean efectivas deben estar basadas en un conocimiento previo de la situación actual, y en unos objetivos claros: hay que saber donde se está y a donde se quiere llegar. • La mejora es continua, no un esfuerzo en un momento dado: debe haber aprendizaje y evolución continua. • Se requiere un esfuerzo sostenido y continuo para que las mejoras se implementen • Se requiere un apoyo visible y reiterado de la Alta Dirección

20. 1.2. Control de la calidad • Involucra una serie de inspecciones, revisiones y pruebas empleadas a lo largo del proceso de software para garantizar que cada producto de trabajo satisfaga los requisitos que se le han asignado. • El control de calidad incluye un ciclo de retroalimentación con el proceso que creo el producto de trabajo. Para que? • Un concepto clave del control de calidad es que todos los productos de trabajo tienen especificaciones definidas mesurables con las cuales se puede comparar la salida de cada proceso. El ciclo es esencial para minimizar los defectos producidos.

21. 1.2. Control de Calidad • El control de la calidad involucra el monitoreo del proceso de desarrollo de software para asegurar que los procedimientos de aseguramiento de la calidad están siendo seguidos. • Existen dos aproximaciones complementarias que se usan para verificar los entregables de un proyecto:

22. Verificando la calidad • Las revisiones del software, su documentación y el proceso usado para producir dicho software son verificados por un conjunto de personas. La revisión incluye una comprobación que el proyecto y sus entregables han seguido los estándares predefinidos. Las desviaciones de los estándares son anotadas y el encargado del proyecto es alertado.

23. Verificando la calidad • Se realizan comparaciones para ver el grado de calidad en que se encuentra el proyecto. Aquí se involucran métricas para verificar y comparar el software contra lo planeado o contra el estándar que se debió seguir.

24. 1.3 Garantía de la calidad • Consiste en un conjunto de funciones de auditoria e información que evalúan la efectividad y que tan completas son las actividades de control de calidad. • La meta es brindarle al gestor los datos necesarios para que este informado acerca de la calidad del producto. • Si los datos que ofrece el aseguramiento de la calidad identifican problemas, es responsabilidad del gestor darle seguimiento para resolverlos.

25. Elementos a evaluar obtener calidad en el Software • Estándar IS0: 9126: • La ISO, bajo la norma ISO-9126, ha establecido un estándar internacional para la evaluación de la calidad de productos de software el cual fue publicado en 1992 con el nombre de “Information technology –Software product evaluation: Quality characteristics and guidelines for their use”, en el cual se establecen las características de calidad para productos de software.

26. 1.4 Costo de la calidad • Incluye todos los costos que genera la búsqueda de calidad o que demanda el desarrollo de las actividades relacionadas con la calidad. • Los costos de calidad se dividen en: • costos asociados con prevención • evaluación • fallas

27. Costos de prevención, evaluación • Los costos de prevención incluyen la planificación de la calidad, revisiones técnicas formales, equipo de pruebas y entrenamiento. • Los costos de evaluación incluyen actividades para comprender mejor la condición del producto. • Ejemplos de costos de evaluación incluyen: • Inspección entre los procesos • Calibración y mantenimiento de equipo y pruebas.

28. Costos de Fallas • Son aquellos que no se presentan cuando el producto esta bien hecho, es decir no existieran si no hay defectos antes de enviar un producto a los clientes. • Se dividen en: • Costos de fallas internas • Costos de fallas externas • Los costos relativos para encontrar y reparar un defecto aumentan sustancialmente conforme pasa de la prevención a detección y de los de falla interna a externa.

29. Costos de Fallas • Costos de fallas internas (se detectan antes de enviar el producto) incluyen reelaboración, reparación y análisis en modo de falla. • Costos de fallas externas (se detectan ya que se envió el producto al cliente), ejemplos: resolución de quejas, devolución y reemplazo del producto, soporte de ayuda en línea y trabajo de garantía.

30. 1.5 Función del Aseguramiento de la Calidad de Software • Se refiere al aspecto de revisión y de reporte de la administración. • Su función básica es proporcionar datos sobre la calidad del producto a la gerencia y asegurarle que los estándares de calidad especificados se están cumpliendo. • El propósito del SQA es: • Evaluar críticamente el software desarrollado • Comprobar si los estándares de calidad se han cumplido • Si el producto satisface o no las necesidades del cliente y también si identifica las debilidades que el cliente puede detectar.

31. Procesos de aseguramiento de la calidad • Se deben de seleccionar herramientas y metodologías para poder soportar los estandares que se van a seguir. • Existen dos tipos de estándares que pueden ser establecidos como parte del proceso de aseguramiento de la calidad que son: • Estándares de Productos • Estándares de Procesos

32. Estándares de Producto • Estos estándares aplican a el producto de software que se va a desarrollar. Incluyen estándares de documentación, estándares o guías para obtener requerimientos, políticas o reglas para la programación.

33. Estándares de Procesos • Estos estándares definen el proceso que debe de ser seguido durante el desarrollo de software, pueden incluir definiciones de especificación, diseño y validación de procesos y descripción de documentos que deben de ser escritos en el transcurso de los procesos.

34. Importancia de los estándares de software: • Se basan en el conocimiento de las mejores o mas apropiadas prácticas de las empresas. Éste conocimiento es adquirido después de varias pruebas y errores. • Proveen una red para implementar los procesos de aseguramiento de la calidad. Encapsulan las mejores prácticas, el aseguramiento de la calidad se asegura el estándar apropiado es el seleccionado y el que esta en uso. • La asistencia de los estándares da continuidad en el trabajo de una persona para que sea pasado o realizado por otra. Los estándares aseguran que todos los ingenieros dentro de una organización adoptan las mismas prácticas.

35. Unidad II Garantía de la Calidad de Software

36. 1 2 3 2.1. Definición de SQA • El SQA se puede definir como la conformidad a las necesidades funcionales y de rendimiento, a los estándares de desarrollo y a las características implícitas requeridas de todo el software que se ha desarrollado profesionalmente.

37. 2.1. Definición de SQA • Necesidades funcionales y de rendimiento, los requerimientos para un programa / aplicación de software formaran la base para evaluar su calidad. La no-conformidad a estos requerimientos dará lugar a una carencia de la calidad. • Los estándares de desarrollo, los estándares específicos influyen en el desarrollo del software. Definen un conjunto de criterios de desarrollo que guía la forma en que el software se elabora. • Características implícitas requeridas de todo el software,cada aplicación de software tiene ciertos requerimientos que son implícitos, por ejemplo buena velocidad de procesamiento, facilidad de uso, etc. El conformarse solamente con los requerimientos explícitos, sin atender a los requerimientos implícitos, también dará lugar a la pobre calidad del software.

38. Objetivos de SQA • La implementación de una disciplina de SQA tiene como principal objetivo aumentar la calidad de los entregables durante todo el proceso de desarrollo. • Muchos requerimientos de calidad, sobre todo aquellos que tienen que ver con el rendimiento, la usabilidad, la carga, la disponibilidad, etc. pueden ser tratados como riesgos. Es decir que, el hecho de que uno de ellos no se cumpla, implica un riesgo. • Entonces, al asegurar la calidad del software durante su proceso, se disminuyen los riesgos asociados, aumentando la predictibilidad del desarrollo de software. Esto trae aparejado una serie de beneficios de variada visibilidad.

39. Beneficios de SQA • Reducción de los tiempos de desarrollo, principalmente el tiempo de trabajo generado en la fase de testing. • Optimización del uso de los recursos, que disminuye el costo de la infraestructura necesaria para soportar la aplicación. • Disminución del costo de mantenimiento, ya que se generan aplicaciones más seguras y estables. • Aumento de la permeabilidad al cambio y facilidad para medir el impacto del mismo • Asegura el cumplimiento de los requerimientos, tanto los funcionales como los de calidad. • Promueve el seguimiento de los estándares definidos • Provee información sobre la calidad del proyecto a los stakeholders con menor conocimiento técnico. • Los desarrollos se vuelven más predecibles, facilitando las estimaciones

40. Algunas operaciones de SQA • El SQA se puede identificar como un patrón de acciones planeado y sistemático, que ayudan a asegurar alta calidad en el software de programas y aplicaciones. • Hay diversas operaciones que vienen bajo SQA. Éstas se asocian generalmente a los siguientes dos conjuntos de personas: • Ingenieros de Software • Grupo SQA • Es responsabilidad de los ing. de software ocuparse de todo el trabajo técnico involucrado en actividades de aseguramiento y control de calidad. De que manera los Ing. Se pueden ocupar del aseguramiento de la calidad?

41. 2.2. Presencia de SQA • Muchas organizaciones empiezan a crear grupos de SQA. • Estas personas actúan como representantes interno del cliente. • Es responsabilidad del grupo SQA ayudar a los Ing., a lograr una alta calidad en el programa o aplicación de software determinado. • Este grupo tiene una serie de actividades que se presentan a continuación.

42. Preparación de Plan SQA Revisión de software Desarrollo de la descripción del proceso de software Actividades SQA Actividades de verificación Documentación Reporte de no conformidad

43. 2.3. Actividades del SQA • SQA es una disciplina que está compuesta por una serie de actividades que acompañan al proceso de desarrollo. • El objetivo de estas tareas es aumentar, administrar y monitorear la calidad de los entregables producidos. • Para poder identificar estas actividades y el momento oportuno para realizarlas es necesario revisar el ciclo de vida de un proyecto.

44. 2.3. Actividades del SQA • Para identificar las actividades se basa en el análisis de fases/disciplinas/esfuerzo realizado en RUP por ser un proceso muy difundido en el mercado, aunque el mismo análisis puede aplicarse a otros procesos de desarrollo.

45. 2.3. Actividades del SQA • Analizando el diagrama, se aprecia que el esfuerzo de cada disciplina varía según la fase del proyecto. De aquí se deriva que el momento para controlar la calidad de cada disciplina es cuando mayor esfuerzo se le dedica.

46. 2.3. Actividades de SQA • Verificación de requerimientos: esta actividad se concentra en validar la completitud, correctitud, claridad y no ambigüedad de los requerimientos de un sistema. • Validación y verificación de documentación: esta actividad se encarga de controlar la correctitud, completitud y no ambigüedad de la documentación. La documentación en UML es muy útil para esta práctica por el poder semántico que tiene y por la posibilidad de validar sintácticamente la documentación. • Validación de arquitectura: esta actividad es muy importante para evaluar la factibilidad de cumplir con los requerimientos no funcionales y detectar de forma temprana los principales riesgos asociados al proyecto.

47. 2.3. Actividades de SQA • Control de código: se subdivide en 2 actividades: • Control estático del código: es la validación del código contra un conjunto de reglas, mejores practicas y estándares predefinidos. • Control dinámico del código: el control se focaliza en el uso de los recursos que hace la aplicación y la cobertura del código que hacen las pruebas unitarias

48. Tareas • Es necesario tener en cuenta que para realizar algunas de estas actividades primero es necesario realizar otras actividades como ser: • Definición de estándares y mejores practicas de desarrollo • Elección de herramientas para documentar y desarrollar. • Estas tareas tienen que ver con el hecho que para poder validad la calidad de algo, es necesario contar, previamente, con la definición, requerimiento o estándar contra el cual validar.

49. ¿Por dónde empezar? • Implementar todas las actividades de SQA al mismo tiempo es costoso e impráctico. • Es mejor empezar por las actividades en donde se vean resultados de forma más rápida y efectiva. • Una implementación paulatina y retroalimentada ayudará a que el proceso sea más armonioso y fácilmente aceptado. • Si se está en las etapas iniciales del proyecto conviene empezar por la verificación de requerimientos y la validación de arquitectura, mientras que si ya se está avanzado, es mejor revisar el diseño o directamente el código.

50. Trabajo • Investigar las diferentes herramientas CASE disponibles para la administración de un proyecto de software (Se asignarán equipos y se realizará exposición) • Leer sobre algunos artículos de calidad (Se asignarán equipos y se realizará una exposición)