Calidad Enfocada en el Desarrollo de Software

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

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

3. Agenda • La norma ISO/IEC 9126. • Análisis de factores que determinan lacalidad del software.

4. 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).

5. Problemas de Comunicación

6. Problema de Visión

7. Problema de Visión

8. Problema de Visión

9. 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).

10. 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).

11. 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).

12. 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;

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

14. 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 grupopara aislar sus opiniones; o bien, cuando se necesita la opinión de expertos los cuales se encuentran alejados geográficamente.

15. 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;

16. 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;

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

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

19. Flujos de Trabajo (UP)

20. Flujos de Trabajo (UP)

21. Flujos de Trabajo

22. Flujos de Trabajo

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

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

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

26. Historia de Usuario

27. Spikes

28. Diagramas de Casos de Uso

29. Diagramas de Caso de Uso

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

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

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

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

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

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

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

37. Metodología FURPS+

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

39. 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”

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

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

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

43. Singleton

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

45. Patrón de Diseño para Menu

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

47. 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”.

48. 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)

49. Patrones

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