mitos y creencias en la creación de software de calidad y la medición de ésta adolfo guzmán...
TRANSCRIPT
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
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
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, 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
• 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
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
negocioventa 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
negocio
negocio
negocio
M4. Detectada una anomalía, hay un algoritmo para corregirla
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 SABEEl 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”.
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
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
• 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.
• Solo agregaría que, 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.
Mitos sobre enseñanza de computación
• M8. Es suficiente medir el producto