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 9126.

• 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

Problema de Visió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)

0 10 20 30 40 50 60 70 80 90 100

Análisis

Diseño

Implementación

Despliegue

Inicio

Flujos de Trabajo (UP)

0 10 20 30 40 50 60 70 80 90 100

Análisis

Diseño

Implementación

Despliegue

Elaboración

Flujos de Trabajo

0 10 20 30 40 50 60 70 80 90 100

Análisis

Diseño

Implementación

Despliegue

Construcción

Flujos de Trabajo

Transición

0 10 20 30 40 50 60 70 80 90 100

Análisis

Diseño

Implementación

Despliegue

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 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, e-mail, afiliación). Uno de los autores debe indicarse como autor de contacto. El sistema confirma la correcta recepción del artículo enviando un e-mail 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+Req F U R P S +

Consultas a través de un celular

Deberán realizarse a través de SMS/MMS, la respuesta será en MMS

Pocos movimientos del teclado

Optimizado para desplegar información importante

Soporte en Plataformas J2ME

Ejecutarse con Equipos Nokia serie 60

Sistema Web de Captura Indicadores

Seguridad por autenticación y huella digital

Optimizado 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

Singletonpublic 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 2009.

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

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

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

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: 0-324-07168-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: 0-471-46912-2

¿Preguntas?