Mitos y creencias en la creación de software de calidad y la medición de ésta Dogmas, leyendas, supersticiones sobre la creación de software de calidad Cómo medir tal calidad

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.

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?? Medir la calidad del software

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)

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) Medir la calidad del software

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

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

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)

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

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!

 (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

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, … –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

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

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

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 Maturity Model, ó CMM) Es equivalente a medir los conocimientos de un súbdito sobre los dibujos y colores de la ropa del emperador (  M3) y califiquemos a las empresas según su grado de madurez

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

(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

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

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

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

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.

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

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.

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.

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)

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