Calidad Enfocada en el Desarrollo de Software M.C. Juan Carlos Olivares Rojas Noviembre 2009

Agenda Qué es la calidad del software. Cómo obtener calidad de software (métodos, metodologías, estándares). Cómo controlar la calidad del software. Costo de la calidad del software. Nomenclatura y certificación ISO 9001:2000.

Agenda La norma ISO/IEC Análisis de factores que determinan la calidad del software.

Replanteamiento Calidad desde el inicio (comunicación y planeación) Calidad en el modelado (análisis y diseño) Calidad en la construcción (codificación y pruebas) Calidad en el despliegue (instalación, mantenimiento).

Problemas de Comunicación

Problema de Visión

Trabajo en Equipos El problema de comunicación se da a través de la colaboración de varias personas en un proyecto. El capital intelectual como se ha comentado es sumamente difícil de controlar y estandarizar. La mejor forma de trabajar en equipo es a través de una buena cultura organizacional (principios y valores).

Técnicas de Discusión Para la toma de decisiones grupales, existen varios métodos que se pueden seguir como: –votación (la decisión más votada gana), –votación aprobatoria (cada miembro puede votar por más de una opción, la opción más votada es la que gana), –suma de rangos (se otorgan ponderaciones a las opciones, siendo 1 para la menos votada, este proceso se realiza por participante, gana la opción con mayor puntaje) y –desviación mínima (se selecciona la opción que tenga mayor puntaje y cuya desviación sea mínimo).

Técnicas de Discusión Estas técnicas se pueden mejorar a través de otras técnicas que ayudan a la toma de decisiones que a continuación se mencionan: –lluvia de ideas, –rueda de mesa (similar a la lluvia de ideas pero cada quien tiene un turno para exponer sus ideas de forma cíclica), –análisis FODA (Fortalezas Oportunidades Debilidades Amenazas).

Técnicas de Discusión La técnica del grupo nominal reúne características de la tormenta de ideas y la rueda de mesa, su funcionamiento es el siguiente: –cada miembro del grupo escribe el mayor número de soluciones posibles de manera anónima; –un moderador recoge todas las respuestas, las presenta al grupo escribiéndolas en un panel, tratando de agrupar aquellas soluciones que sean afines; –las ideas propuestas son discutidas por el grupo hasta que sean suficientemente claras;

Técnica de Discusión –Cada miembro del grupo, anónimamente, otorga una puntuación a cada solución ya sintetizada, en función de lo apropiada que le resulte cada una para resolver el problema que se discute; –por último, el moderador resume las puntuaciones conseguidas por cada solución alternativa, de forma que se puede establecer una jerarquía de adecuación de las diferentes propuestas de solución en función de la opinión grupal.

Técnicas de Discusión Para problemas más complejos se puede utilizar la técnica Philips 66. La cual consiste en hacer grupos de 6 personas que discutirán el problema por 6 minutos. Otra técnica compleja es el Proceso Delphi, la cual se utiliza cuando se desea aislar los miembros del grupo para aislar sus opiniones; o bien, cuando se necesita la opinión de expertos los cuales se encuentran alejados geográficamente.

Técnicas de Discusión El proceso Delphi es el siguiente: –Se elabora un primer cuestionario para recoger información, posibles soluciones y causas del problema, este cuestionario se envía a los expertos, que los responde individual y anónimamente; –se analizan los datos recogidos en el primer cuestionario categorizando las respuestas en función de su parecido y se elabora con esto un segundo cuestionario en el que se incluyen las alternativas más elegidas;

Técnicas de Discusión –se envía el segundo cuestionario en el que cada experto ordena las diferentes alternativas en función de su adecuación, asignándoles un número y argumentando sus respuestas; –se analizan las valoraciones del segundo cuestionario y con ello se elabora un tercer cuestionario dónde sólo aparecen las opciones más votadas y un resumen de los comentarios más importantes;

Técnicas de Discusión –los expertos contestan el tercer cuestionario evaluando cada alternativa; –se elaborará el informe final con los resultados obtenidos, este informe servirá a la persona encargada para tomar la decisión final.

Modelos de Ciclo de Vida ¿Funciona? ¿Es mejor el espiral o modelos iterativos?

Flujos de Trabajo (UP)

Flujos de Trabajo

RFP Realización de un sistema LBS que permita conocer la ruta “ideal” entre dos puntos de la ciudad de Morelia para utilizarse en sistemas de Taxi. La aplicación deberá de ser de preferencia para un dispositivo móvil con GPS o 3G. Otra forma de realizarse es a través de un “mashup” para la Web utilizando la API de Google Map o Google Earth.

RFP Se deberá calcular costos utilizando la información espacial disponible. Se excluyen elementos como tráfico, manifestaciones y otra información no disponible en el modelo.

Actividad Tomando en consideración el rol de cliente en metodologías ágiles desarrollar de manera individual sin intervención de nadie más lo siguiente: Historia de usuario. Spike. Diagrama de casos de uso con especificación de escenarios. Especificación de requerimientos

Historia de Usuario Número: 1 Nombre: Enviar artículo Usuario: Autor Modificación de Historia Número: Iteración Asignada: 2 Prioridad en Negocio: Alta (Alta / Media / Baja) Puntos Estimados: Riesgo en Desarrollo: (Alto / Medio / Bajo) Puntos Reales: Descripción: Se introducen los datos del artículo (título, fichero adjunto, resumen, tópicos) y de los autores (nombre, , afiliación). Uno de los autores debe indicarse como autor de contacto. El sistema confirma la correcta recepción del artículo enviando un al autor de contacto con un userid y password para que el autor pueda posteriormente acceder al artículo. Observaciones:

Spikes

Diagramas de Casos de Uso

Diagramas de Caso de Uso

Calidad en el modelado ¿Cuántos diagramas debo crear? No existe una respuesta específica. ¿Debo hacer diagramas de todo tipo? No, sólo se deben utilizar los diagramas que mejor reflejen el modelado de la problemáticaoe

Calidad en el modelado ¿Qué tan grande debe de ser un diagrama? Entre más grande sea un diagrama mayor es la confusión. Se deben realizar diagramas bien detallados, pero no tan detallados. ¿Cuánto texto debe complementar el modelo? Entre menos texto mejor, son como los comentarios del código fuente: pocos pero claros.

Calidad en el modelado Algunas recomendaciones para el modelado de software son: No tenga a los programadores esperando los modelos. Trabajar de una macrovista a una microvista(enfoque Top-Down). Se debe documentar en forma económica.

Calidad en el modelo Si es obvio no se debe de modelar. Hacer hincapié en la especialización. Utilizar patrones de diseño. Reestructuración de códigos

Metodología FURPS+ Desarrollada por HP Funcional (Functional): características, capacidades y seguridad. Facilidad de Uso (Usability): factores humanos, ayuda, documentación. Fiabilidad (Reliability): frecuencia de fallos, capacidad de recuperación.

Metodología FURPS+ Rendimiento (Performance): tiempos de respuesta, productividad, precisión, disponibilidad, uso de los recursos Soporte (Supportability): adaptabilidad, facilidad de mantenimiento, internacionalización, configurabilidad.

Metodología FURPS+ +: Implementación: limitación de recursos, lenguajes y herramientas, hardware Interfaz: restricciones impuestas para la interacción humana Operaciones: gestión del sistema Empaquetamiento Legales: licencias, auditorias, etc.

Metodología FURPS+ ReqFURPS+ Consultas a través de un celular Deberán realizarse a través de SMS/MMS, la respuesta será en MMS Pocos movimient os del teclado Optimizad o para desplegar informació n importante Soporte en Plataforma s J2ME Ejecutarse con Equipos Nokia serie 60 Sistema Web de Captura Indicadore s Seguridad por autenticaci ón y huella digital Optimizad o para navegador Opera …….

Patrones de Diseño Son principios generales de soluciones que aplican ciertos estilos que ayudan a la creación de software. Es una descripción de un problema y la solución a la que le da el nombre y que se puede aplicar en nuevos contextos. Muchos patrones ayudan a asignar responsabilidades a los objetos.

Patrones de Diseño Un patrón es un par/problema solución con nombre que se puede aplicar en nuevos contextos, con consejos acerca de cómo aplicarlo en nuevas situaciones y discusiones sobre sus compromisos. “Un patrón de una persona es un bloque de construcción primitivo de otra”

Patrones de Diseño Son arquitecturas comprobadas para construir software orientado a objetos que sea flexible y se pueda mantener. Proveer la reutilización del diseño en sistemas posteriores. Ayudar a identificar los errores y obstáculos comunes que ocurren al crear sistemas.

Patrones de Diseño Realizar un programa que permita que un momento dado uno y solo un objeto pueda estar en ejecución. La utilización de patrones puede resolver este problema. Caso de ejemplo: Singleton Tratar de resolver el problema con una ventana Jframe utilizando BlueJ.

Singleton Problema: se admite exactamente una instancia de una clase. Los objetos necesitan un único punto de acceso global. Solución: Defina un método estático de la clase que devuelva el Singleton

Singleton

public class Singleton { private static Singleton INSTANCE = null; private Singleton() {} private synchronized static void createInstance() { if (INSTANCE == null){ INSTANCE = new Singleton(); }

Patrón de Diseño para Menu

Tarea Lunes 7 de diciembre de Investigación e implementación sobre patrones para brindar seguridad al software. Pueden ser patrones específicos (citar la fuente, e.g. Gama –GoF-) o bien proponer su patrón de diseño validando que sea adecuado.

Patrones Ejemplo: Java DOM Actividad: se tiene que diseñar un programa en consola que permita obtener las raices de una ecuación cuadrática por método general (técnicamente ya lo tienen). Ese programa se hizo a finales de los 1980’s. Ahora a finales de los 1990’s se desea que sea “visual”.

Patrones 10 años después el programa debe estar enfocado a la Web (JSP). Sino se realiza de forma estructurada dicho programa se tendría que reinventar el problema o bien hacerlo de nuevo desde el principio. Para evitar este tipo de soluciones existe un patrón arquitectónico simple: MVC (Modelo- Vista-Controlador)

Patrones

Modelo: lógica de datos. Si es java se trata de que sean beans. Vista: interfaz de usuario Controlador: liga tanto a la vista como al el controlador. Responde generalmente al manejo de eventos. Es mala recomendación dejar embebido en la interfaz código de lógica de programa.

Estimación de Costos La tarea de determinar costos de un proyecto de software no es tan fácil como parece. En general el costo total de un software está determinado por dos factores: –Esfuerzo para completar una actividad –Tiempo calendario se necesita para completar una actividad.

El costo de la calidad tiene dos componentes: lo que se invierte en obtener buena calidad y lo que se paga por no lograrla. La primera componente es decidida por los desarroladores y puede ser controlada; la segunda no se puede decidir sino que se manifiesta en las fallas de nuestro producto. Costos de la Calidad del Sw

Entre los costos de prevención se incluyen: –planificación de la calidad, –revisiones técnicas formales, –equipo de pruebas, –formación. Entre los costos de evaluación se encuentran: –inspección en el proceso y entre procesos, –calibrado y mantenimiento del equipo, –pruebas. Costos de la calidad del Sw

Entre los costos de fallos se encuentran: –retrabajo (revisión), –reparación, –análisis de las modalidades de fallos. –resolución de quejas, –devolución y sustitución de productos, –soporte de línea de ayuda, –trabajo de garantía.

Costos de la Calidad del Sw

Si llamamos P, E, Fi, Fe y C a las horas totales usados en el proyecto para actividades categorizadas como prevención, Evaluación, Fallas internas, Fallas externas y Creación, respectivamente, tenemos que: Esfuerzo de Calidad = EoQ = (P+E+ Fi+Fe) Costo de Calidad = CoQ = (P+E+Fi+Fe) / (P+E+Fi+Fe+C) Esfuerzo de Mala Calidad = EoPQ = Fi+Fe Costo de Mala Calidad = CoPQ = (Fi+Fe) / (P+E+Fi+Fe+C) Costo de la Calidad del Sw

Ejemplo: En un proyecto se usaron 1280 horas de las cuales 280 horas se usaron en administración, 60 en entrenamiento para el proyecto, 40 en adaptaciones del proceso para el proyecto, 420 en creación, 50 en inspecciones, 160 en pruebas, 30 en correcciones debido a inspecciones, y 150 en debugging antes de la entrega, y 90 en correcciones finales después de la entrega. Costo de la Calidad del Sw

Quedan 1000 horas en actividad del proyecto propiamente tal descontadas las horas de administración. Entonces tenemos: P=60+40, E=50+160, Fi=30+150, Fe=90, C=420, EoQ=580, CoQ=58%, EoPQ=270, CoPQ=27% y Overhead=280/1280=21,9%. Costo de la Calidad del Sw

Lecciones aprendidas: El lenguaje del dinero es esencial. El significado de “costo de calidad”. La medición y publicación de los costos de calidad no solucionan los problemas de calidad. El alcance de los costos de calidad es muy limitado. Las categorías tradicionales de costos de calidad han tenido una longevidad marcable. Evolución de Calidad y Costos

Lecciones aprendidas: El lenguaje del dinero es esencial. La medición y publicación de los costos de calidad no solucionan los problemas de calidad. Las categorías tradicionales de costos de calidad han tenido una longevidad marcable. Costos de la calidad del Sw

Pruebas y depuración La fase de prueba se realiza una vez integrado cada uno de los módulos del sistema. La fase de pruebas se realiza de distintas formas tratando de encontrar la mayoría de los errores que se encuentran de manera inherente en el software.

Depuración Una vez identificado los errores en la fase de pruebas, se procede a corregirlos. A esta fase se le llama depuración. En la fase de depuración también se arreglan detalles superficiales del software además de optimizar y mejorar algunos procesos.

Pruebas y depuración La fase de prueba se realiza una vez integrado cada uno de los módulos del sistema. La fase de pruebas se realiza de distintas formas tratando de encontrar la mayoría de los errores que se encuentran de manera inherente en el software.

Depuración Una vez identificado los errores en la fase de pruebas, se procede a corregirlos. A esta fase se le llama depuración. En la fase de depuración también se arreglan detalles superficiales del software además de optimizar y mejorar algunos procesos.

Depuración Es la detección, corrección y eliminación de errores de software. El tener un plan de pruebas ayuda a clarificar el proceso de depuración. El plan de pruebas debe de estar mucho antes de la construcción del software.

Depuración Existen muchos tipos de pruebas dependiendo de la labor y características de cada una de ellas. Pruebas Alfa: se realizan por el usuario final en un ambiente controlado. Pruebas Beta: se realizan por el usuario sin controlar el ambiente.

Depuración A continuación se mencionan algunas características deseables que deben contener los planes de prueba: Diseñar un caso de prueba para cada funcionalidad del software. Establecer como mínimo un caso de prueba de datos correcto.

Depuración Establecer como mínimo un caso de prueba de datos incorrecto. Ejemplo: Caso de Prueba de un módulo de raíz cuadrada. Qué el usuario ingrese un número mayor que 0.

Depuración Qué el usuario ingrese un número 0 Qué el usuario ingrese un número menor que 0. Toda actividad de construcción (codificación) es susceptible de cometer errores dado que se trata de una actividad humana.

Depuración Al realizar la depuración de un programa existe la posibilidad de un 50% de cometer otro error. Es recomendable realizar pruebas de trazado (assert) para visualizar en donde ocurren los errores.

Depuración Se recomienda probar lo antes posible cualquier fragmento de código. Las pruebas ayudan al aseguramiento de calidad pero no garantizan que un software esté 100% libre de errores.

Depuración Las pruebas de caja blanca también llamadas transparentes se concentran en lo que es el código fuente. No se pueden tener pruebas que abarquen el 100% de los casos de uso. Se deben realizar pruebas de segmentos

Depuración Las pruebas de segmentos son bloques de instrucciones. Las pruebas de caja negra están orientadas a lo que se espera realicen los componentes modulares del sistema.

Depuración Son pruebas funcionales y no interesa como se realizan las cosas sólo que el resultado obtenido sea el correcto. Se recomienda que sean los usuarios quienes las realicen. Existen diversas filosofías de pruebas como la programación defensiva.

Depuración La programación defensiva es una técnica de probar primero. Es considerada una técnica de codificación. Se basa en el principio de divide y vencerás. Se codifica el esqueleto de la aplicación. Se realizan pruebas.

Depuración Se corrigen los errores y se vuelven a hacer pruebas. Las pruebas de estrés se encargan de observar el rendimiento de la aplicación sobre cargas demandantes de trabajo: grandes volúmenes de datos con poco espacio en disco, 90% de uso de CPU, múltiples conexiones, etc.

Depuración Existen otros tipos de prueba como: Pruebas de unidad: se encargan de un módulo de software en particular. Pruebas de Integración: son pruebas que se realizan con dos o más módulos trabajando en conjunto.

Depuración Existen otro tipos de prueba como las de aceptación que están más involucradas en el concepto en sí que en el desarrollo. También se pueden aplicar pruebas aleatorias. Lo ideal es poder utilizar un framework de pruebas.

Depuración La mayoría de los IDEs modernos presentan frameworks para la depuración desde el clásico step by step o step over sobre cada uno de los módulos hasta la realización de pruebas de unidad. Entre las más famosas destacan JUnit para realizar pruebas de unidad en Java.

Guía para la Prueba de Programas Se necesita especificar las salidas o resultados esperados. Un programador debe de evitar probar sus propios programas. Una organización no debe de probar sus propios programas.

Guía para la Prueba de Programas Inspeccionar los resultados obtenidos de cada prueba. Los casos de prueba deben escribirse con condiciones de entrada que son inválidas e inesperadas, así como también aquellas que son válidas y esperadas.

Guía para la Prueba de Programas Examinar un programa para verificar que hace lo que deba de hacer es sólo parte de la prueba, la otra mitad es asegurarse que el programa no haga lo que no deba de hacer. No realizar planeaciones asumiendo que no se encontrarán errores.

Guía para la Prueba de Programas La probabilidad de la existencia de mas errores en una sección de un programa es proporcional al número de errores encontrados en esa sección. La realización de pruebas es una actividad extremadamente creativa e intelectualmente retadora.

Guía para la Prueba de Programas Se debe de realizar una lista de verificación para inspecciones de prueba que contenga los siguientes puntos: Datos Declaración de datos Errores computacionales Errores de comparación

Guía para la Prueba de Programas Errores de control de flujo Errores de Interface Errores de Entrada/Salida Se pueden utilizar métodos deductivos e inductivos para la prueba de software.

Depuración por Inducción Se siguen los siguientes pasos: Localizar los datos pertinentes Organizar los datos Estudiar las relaciones Divisar las hipótesis Probar las hipótesis Corregir el error

Depuración por Deducción Enumerar las posibles causas Usar procedimientos de eliminación Refinar las hipótesis restantes Probar las hipótesis restantes Si no se pueden probar las hipótesis entonces coleccionar más datos y repetir el proceso En caso contrario corregir el error

XP eXtreme Programming Se tienen doce principios básicos: Planeación y requerimientos Entregas pequeñas e incrementales Metáforas de Sistemas Diseños simples Pruebas continuas Refactorización

XP eXtreme Programming Programación en pares Propiedad colectiva del código Integración Continua Semanas de 40 horas Clientes como miembros del equipo Codificar con estándares

Extreme Testing Las programación extrema tienen las siguientes ventajas en lo que respecta al proceso de pruebas: Se gana confianza ya que el código debe cumplir las especificaciones. Se tiene el resultado final del código antes de codificar

Extreme Testing Se entiende mucho mejor las especificaciones y requerimientos de la aplicación. Se inicia con diseños simples y se refactoriza el código después para mejorar el desempeño sin preocuparse de que se estén rompiendo las especificaciones. 92

Plan de Pruebas Se recomienda utilizar la metodología y formatos del estándar IEEE 829 para documentación de pruebas de software: Pasos que incluye: Identificador de plan de pruebas (se muestra el estándar a seguir para el nombre de las pruebas) 93

Plan de Pruebas Introducción (en que consiste las pruebas del sistema) Elementos a probar Características a ser probadas Características que no se probarán Enfoque Criterio de fallo o aceptación de los elementos

Plan de Pruebas Criterio de Suspensión y Reanudación de requerimientos Entregables de las pruebas Tareas de las pruebas Necesidades del entorno Responsabilidades Equipo y necesidades de capacitación Agenda

Plan de Pruebas Riesgos y contingencias Acuerdos A las pruebas se les ha empezado a llamar de manera formal verificación y validación. Existen metodologías más robustas como el TMMI (Test Maturity Model) 96

Plan de pruebas

Referencias Pressman, R. (2004). Ingeniería del Software un Enfoque Práctico. Sexta Edición. McGraw Hill. Guido, J. y Clements, J., “Administración Exitosa de Proyectos”, Segunda Edición, Thomson, México, 2003, ISBN: X.

Referencias Pintor, A. (2009), Material del curso Calidad del Software II, Instituto Tecnológico de Morelia. Myers, et al. (2004), “The Art of Software Testing”, Wiley, Estados Unidos, 2004, ISBN:

¿Preguntas?