Mitos y creencias en la creación de software de calidad y la medición de ésta

1. Mitos y creencias en la creación de software de calidad y la medición de ésta Adolfo Guzmán Arenas Centro de Investigación en Computación IPN a.guzman@acm.org

2. Dogmas, leyendas, supersticiones sobre la creación de software de calidad • Cómo medir tal calidad que ·no son congruentes con los hechos ·más y más gentes cuestionan cada vez menos y se convierten en • verdades cotidianas y • estándares a exigir. Mis puntos de vista son impopulares

3. Medir la calidad del software • Verdad 1. Es posible medir subjetivamente (solicitando opiniones) la calidad del software Confiabilidad. Pocos errores. Flexibilidad. Adaptable a nuevas situaciones. Robustez. No falla. Comprensión. ¿Es entendible el código? Fácil de usar. Ergonómico. Reusable. Se pueden usar porciones en otro software. Rápido. (medición objetiva) Mantenible. Fácil de hacerle cambios.

4. Medir la calidad del software • El problema surge cuando deseamos medir las cualidades anteriores en forma objetiva: Confiabilidad (pocos errores).Ver el número de mensajes de error del código fuente. A más mensajes, menos errores ?? Flexibilidad (adaptable a nuevas situaciones).Ver a cuántos estándares se apega ?? Robustez (no falla). Ver si se diseñó con UML o método conocido ?? Comprensión (el código es entendible). Si no contiene “GO TOs” ni variables libres ??

5. Facilidad de uso (ergonomía).Medir por el tamaño de los manuales ?? Reusabilidad (se puede usar en otras aplicaciones).Ver si las clases comparten pocas variables (coherencia) ?? Mantenibilidad (fácil de hacerle cambios).Medir la bondad de su documentación ?? Modularidad (descomposición en partes que desempeñan una función clara). Se mide contando los módulos o clases o componentes. ?? Complejidad (código enredado). Contando el nivel de anidación de los paréntesis!! ?? Portabilidad (usable en otros ambientes). Si se ocultan bien sus variables internas?? • Medimos lo que podemos, no lo que deberíamos (busco la llave donde hay luz)

6. Medir la calidad del software • Pocas mediciones son objetivas • Se mide altura en vez de volumen • Se mide lo que se puede • No lo que se debe • Muchas mediciones son estáticas • Decidir con mediciones estáticas a la corredora que ganará los 400 metros planos • Nos conduce al Mito 1 ( M1)

7. M1. Para cada atributo hay una medición confiable (objetiva) • Si no puede medir la liebre, mida al gato. Da lo mismo.

8. Un proceso confiable produce un producto confiable • Una manera de hacer buenos productos es seguir buenas recetas (buenos procesos, buenos algoritmos) • Ejemplo: sopa de arroz • Ejemplo: curtido de cuero • Esto es cierto cuando la humanidad ha tenido mucha experiencia • O cuando hay ciencias (Física, Química…) antiguas que apoyan tales procesos

9. Entonces, el proceso se vuelve observable (podemos ver si lo estamos siguiendo bien) • Y el producto se vuelve controlable • Dado un defecto en el producto, sabemos qué parte del proceso modificar • Pero esto no sucede con el software… • La computación es joven (60 años) • No es aún ciencia. Es un arte o artesanía… ( M2)

10. M2. Un buen proceso implica producir software de buena calidad • Seguir el proceso para pintar de Diego Rivera asegura obras de alta calidad

11. M2. Un buen proceso implica producir software de buena calidad • Esto es cierto en la fabricación de bisagras o varillas de acero (leyes de la Física) • Pero no en la creación del software • Más cercano a creación artística: sinfonías, novelas, pinturas, obras de teatro... • Es creación, no fabricación!

12. (M2)Es posible diseñar un proceso confiable para producir buen software • Si cumplimos con ese proceso, habremos hecho software de buena calidad (M2). • La calidad del software producido no está relacionada con el proceso seguido

13. Ejemplo de un proceso confiable, observable • Reuniones cada lunes a las 9am; minutas • Conformar un comité de calidad • Que los integrantes del grupo de desarrollo conozcan las normas ISO 9000, 9000-3… • Firme convicción de poder crear swr de calidad • Revisiones periódicas de código (walk-through) • Llevar un Control de Cambios y un Control de Versiones • Todo esto no garantiza producto de calidad • El proceso es controlable; el producto no lo es

14. Ejemplo de procedimientos quirúrgicos antes de Pasteur • No operar desvelado • Rezar a Santa Cecilia • Colgarse ajos del cuello • Lavarse las manos antes de operar • No operar en días con noches de plenilunio • Discutir con otros colegas los resultados • Todo esto no garantiza producto (cirugía con baja mortandad) de calidad

15. El proceso es observable (ver si se siguió) • El proceso es controlable(fácil corregir: llegar más temprano a las juntas) • El producto es observable (fácil ver si es de calidad) • Está fallando la comunicación asíncrona entre procesos que van en distintos procesadores • Pero el producto (software) no es controlable!! (no es corregible mediante correcciones al proceso) (M4) Detectada una anomalía, hay un algoritmo para corregirla

16. Medir la madurez de un proceso de creación de software • (M2) un proceso confiable para crear software de calidad --un mito • Midamos la calidad de ese proceso en una empresa • Se llama grado de madurez (Capability MaturityModel, ó CMM) • Es equivalente a medir los conocimientos de un súbdito sobre los dibujos y colores de la ropa del emperador (M3) • y califiquemosalasempresas según su grado de madurez

17. M3. Las empresas con grado de madurez alto producen buen software

18. M3. Las empresas con grado de madurez alto producen buen software • La medición del proceso puede (quizá) ser objetiva. Ejemplo: CMM = 1, 2, 3, 4, 5 • Pero no correlaciona con la calidad del swr • (M3) Una empresa con buena madurez en su proceso de creación de software produce swr de calidad • El examen (del proceso de software) es caro • Cada vez lo exigen más los gobiernos • Todas lo hacen, está de moda negocio venta de patas de conejo

19. negocio • (M3) (Corolario)Dar cursos de cómo medir el proceso de creación del software • es como enseñar qué diseños y colores llevaba la ropa del emperador. • Hay dos estándares: el CMM (EEUU) y el europeo! (dos formas de detectar los dibujos del traje imperial) • (M3) (Corolario) Una empresa que mide(certifica) la madurez del proceso de creación del software • Hay que ir a EEUU o Europa para que me habiliten para certificar (medir madurez) • es como medir el conocimiento sobre los diseños del traje del emperador. negocio negocio negocio

20. M4. Detectada una anomalía, hay un algoritmo para corregirla

21. M4.Detectada una anomalía, hay un algoritmo para corregirla • La comunicación entre módulos en distintos procesadores a veces falla. • El software producido no es reusable. • Varias especificaciones no se cumplen. • Si se detecta alguno de estos errores, ¿qué parte del proceso modificar? NO SE SABE El producto no es controlable vía el proceso

22. M5. El Comité de Calidad de Software es algo bueno M6. La fe es importante para crear software de calidad

23. M5.El Comité de Calidad de Software es algo bueno • Elabora normas sobre cómo conducir el proceso • Vigila el apego a ellas del grupo desarrollador • Exige apego a las normas; regaños, sanciones • El problema original (software poco reusable) seguirá sin corregirse • O se corregirá “por casualidad” (no controlable) • M5. Creencia que una ley o un comité corrigen los problemas de calidad del software • Sí corrigen los problemas de curtido de cuero

24. M6.La fe es importante para crear software de calidad • La fe no daña • Nuestra profesión no debe guiarse por actos de fe, creencias, doctrinas… • “Debo tener fe en que puedo calcular el área de un círculo” • “Si me sale mal, es que tuve poca fe”. • Los productos no controlables producen fe. • Los algoritmos irrelevantes producen fe.

25. M7. El mito de los estándares en la creación del software • Seguir un estándar asegura buena calidad en el software creado

26. M7. El mito de los estándares en creación de software • M7. Si sigo un estándar internacional, no me puede ir mal. • “Hay que usar UML” • “Hay que usar CMM del Software Engineering Institute” “Hay que usar ISO 9001” • No se sabe cómo hacer software de calidad.Copiar a alguien con éxito (en producción de software, no en venta de estándares) puede ser útil, ¡o puede no serlo! • Somos muchos, no podemos estar mal • Pero: quizá el emperador iba desnudo.

27. Mitos sobre creación de software • M1. Es posible medir objetivamente los atributos del software. • M2. Medir el proceso, en vez del producto. • M3. Un proceso “maduro” swr de buena calidad. • M4. Detectada una anomalía, hay un algoritmo para corregirla • M5. El comité de calidad es bueno. • M6. Importa la fe. • M7. Seguir estándares es bueno.

28. Mitos sobre la calidad de la enseñanza de computación • Normalmente se mide el producto • Ejemplo: examen de CENEVAL • Si yo hago un examen a dos aspirantes a un trabajo, y uno sale mejor que el otro, “claramente es preferible el que salió mejor.” • Esta medición “casi está bien.” • No toma en cuenta la obsolescencia tan grande en nuestra profesión(M8)

29. M8. Es suficiente medir el producto • El filo de un machete • Qué tanto sabe de lo que hoy se necesita • El temple de un machete • Cuán buenas bases teóricas tiene para aprender lo que se necesitará dentro de 5, 10,.. 40 años • Resistencia a la obsolescencia (meta: 40 años) • Generalmente, los exámenes de conocimientos miden “el filo” y no “el temple”.

30. M8. Es suficiente medir el producto • (M8) (Corolario) la calidad de una escuela se mide por la calidad (“instantánea”) de sus egresados. • Esto “casi está bien”. Es más verdad que mito. • Sería mejor hacer estudios longitudinales, del recién egresado, del que egresó hace 5 años, hace 10 años…Para medir el “temple” • Entran buenos ingresandos: FINAL – INICIAL

31. Es suficiente medir el proceso (de enseñanza de software) • Ejemplo: Acreditación por CACEI. • Buenos procesos de enseñanza producirán buenos egresados • Para medir la calidad de un egresado, es suficiente medir la calidad del proceso de enseñanza • Que tenga prácticas de Laboratorio • Que la biblioteca tenga muchos libros • Que la relación de profesores a alumnos sea  x

32. Esto “casi está bien” • La antigüedad del proceso educativo garantiza que se tenga mucho más claro que en el M2 • cuál es un buen proceso de enseñanza, y • qué partes de él modificar si, digamos, los estudiantes no adquieren experiencia en Química experimental.

33. Solo agregaríaque, en procesos educativos (como en confección de alimentos, o cocina), también son importantes: • los ingredientes, los libros, el software disponible, los conocimientos transmitidos, los planes de estudio; y • los artesanos, los cocineros, o sea, los maestros, los instructores.

34. Mitos sobre enseñanza de computación • M8.Es suficiente medir el producto