Calidad de Software: Fundamentos, Desafíos y Diseño Eficaz
Características del Software de Calidad
Un buen software se distingue por las siguientes cualidades:
- Útil y Utilizable: Un buen software facilita o mejora la vida de las personas.
- Confiable: Un buen software presenta pocos errores.
- Flexible: Las necesidades cambian con el tiempo, por eso es necesario que se puedan realizar cambios posteriores y que se le pueda dar mantenimiento después de su liberación.
- Accesible: Tanto para adquirir como para mantener. Debe ser razonablemente fácil y rápido de desarrollar o mantener.
- Disponible: No importa si es bueno. Debe ser capaz de ejecutarse con el hardware y software disponible, y entregar lo prometido al usuario.
Desafíos Comunes en el Desarrollo de Software
A pesar de los principios de calidad, persisten diversos problemas en la industria del software:
- Existen sistemas que no cumplen con las necesidades de los usuarios y/o presentan fallas técnicas.
- Generalmente, los sistemas no están actualizados, incluso durante su fase de diseño.
- Aún persiste el “error de la computadora” como excusa para un mal servicio al cliente.
- La mayoría de los usuarios de PC esperan que sus aplicaciones e incluso el sistema operativo se “cuelguen” o “congelen” ocasionalmente.
- El software no siempre es utilizable, útil, confiable o disponible.
- La falta de flexibilidad también resulta evidente, como lo demostraron el problema del milenio y la necesidad de adecuar sistemas antiguos a procesos de negocio cambiantes.
- La costeabilidad se relaciona estrechamente con la confiabilidad y la flexibilidad, dado que el costo de corregir y mantener es el más alto asociado con el software.
Estadísticas sobre Fallas en Proyectos de Software
Según W. Wayt Gibbs en Software’s Chronic Crisis, Scientific American (International Ed.) pp. 72-81, Sep. 1994:
- En promedio, los proyectos grandes toman un 50% más de tiempo de lo planeado.
- El 75% de los proyectos grandes presentan fallas operacionales.
- El 25% de los proyectos grandes son cancelados.
La Ley de Brooks y la Comunicación en Proyectos Grandes
Según Frederick P. Brooks (The Mythical Man-Month, Addison-Wesley 1975/1995):
Mientras más grande sea el proyecto, mayor será la proporción del costo y tiempo del proyecto gastado en la comunicación entre los miembros del equipo, porque cada persona tiene más gente con quien comunicarse. Cuando un proyecto empieza a retrasarse, añadir más personal generalmente resulta contraproducente.
Principios para Sistemas de Software de Calidad
Comprender cómo son los sistemas considerados buenos requiere fundamentalmente:
- Saber que un ser humano tiene un límite en cuanto puede aprender en un momento dado.
- Los sistemas pequeños son realizados por una sola persona (programación heroica), por lo tanto, es difícil que esa persona logre recordar todo lo relevante del programa (casi imposible).
- Entender un problema evoluciona así:
- Los programas son complejos y debe tenerse en cuenta no solo el código cercano, sino también las partes lejanas si se quieren realizar cambios.
- Un sistema es un conjunto de módulos y existen dependencias entre ellos. Un módulo puede ser cualquier parte identificable de un sistema. Los módulos pueden ser: archivos, subrutinas, funciones de biblioteca, clases en lenguajes OO, otras partes conocidas o módulos similares, programas o subsistemas independientes o semi-independientes.
Características de los Módulos para Optimizar Costo, Facilidad y Confiabilidad
Para que los módulos sean lo más económicos, fáciles y confiables posible, deben poseer las siguientes características:
- Acoplamiento Bajo: Minimiza las dependencias entre módulos.
- Cohesión Alta: Las funciones dentro de un módulo están fuertemente relacionadas.
- Interfaz Definida: Claridad en cómo los módulos interactúan.
- Encapsulación de Módulos: Oculta los detalles internos de implementación.
- Abstracción: Presenta solo la información esencial.
- Componente Insertable y Reusable: Facilita la integración y el uso en diferentes contextos.
La dependencia a veces se conoce también como acoplamiento. Si el sistema posee mucha dependencia, los errores tienden a propagarse; caso contrario, si poseen un acoplamiento bajo (lo cual es mejor).
Encapsulación y Acoplamiento Bajo en el Diseño de Software
La encapsulación, que promueve un acoplamiento bajo, es crucial:
- Se debe conocer si un cambio en un módulo afectará a otro (verificar si están acoplados) para evitar la verificación individual de cada acoplamiento, lo cual genera un costo innecesario (debe evitarse).
- Una vez que se conocen las fronteras entre los módulos, hay dos clases de información útil:
- ¿Qué suposiciones pueden hacer los clientes acerca de un módulo dado? Responder a esto nos permitirá conocer qué tipo de cambios a un módulo pueden ser peligrosos (¿qué servicios provee?).
- ¿Cuáles módulos son clientes de un módulo dado? Responder a esto nos indica cuáles módulos tendrán que cambiar si realizamos un cambio peligroso en un módulo.