La calidad del producto software es una preocupación cada vez mayor en el ámbito de las tecnologías de la información, y en los departamentos de TI de las organizaciones que contratan los servicios de proveedores de soluciones informáticas como vuestra empresa.
Ya sabemos que la manera de aproximarse a la calidad está condicionada por el contexto. El mundillo del desarrollo de aplicaciones informáticas no es ninguna excepción al respecto: el desarrollo de “productos” software no está ausente de ofrecer calidad, pero tod@s intuiréis que aquí el concepto de calidad tendrá connotaciones específicas. El concepto de calidad en los “productos” software debe formularse de forma particular.
Es que lo que llamamos software de por sí ya requiere que lo miramos de más cerca: ¿se puede denominar producto al igual que cualquier otro producto industrial, un consumible o una máquina, por ejemplo? ¿Qué es software?
Al consultar fuentes “no técnicas” o “no especializadas”, ¿qué encontramos? La vigente edición del DRAE nos da una definición muy básica:
|
Algo más nos aprende el Diccionario de la lengua española Espasa-Calpe (2005), combinando la información que proporcionaban las 2 definiciones anteriores:
|
En base a esta definición Wikipedia (2012) intenta una versión más completa, pero no técnica:
|
Veamos ahora lo que nos dicen fuentes más “técnicas”. Según Roger S. Pressman (2003), quien es toda una autoridad en ingeniería del software, software es
|
La definición más formal nos la da la Norma 729 del IEEE (Institute of Electrical and Electronics Engineers), según la cual software es
|
Abarca más que los programas de computación: incluye todos los elementos no tangibles (no físicos) del sistema de computación.
Hay que destacar que el “producto” software tiene características diferenciadoras de otros productos. ¿En qué difiere de lo que generalmente entendemos como producto, a efecto de la valoración de su calidad? Lo resume bastante bien el Instituto Nacional de Tecnologías de la Comunicación (INTECO) en su Guía de mejores prácticas de calidad de producto (2008), donde leemos:
|
Ivar Hjalmar Jacobson, Gary Booch y James Rumbaugh (1999), que los diseñadores y programadores entre vosotr@s conocéis sin duda como “gurús” del Desarrollo Orientado a Objetos (DOO) (Object-Oriented Development) y "padres" del Lenguaje Unificado de Modelado (UML), lo dejan bastante claro:
|
Esta diferenciación está marcada por lo intrínseco del producto:
- Es un producto lógico, abstracto. No es físico, como el hardware o cualquier equipo, componente, material o consumible. El éxito se mide por la calidad de una única entidad en vez de por muchas entidades fabricadas.
- Como producto se desarrolla, no se fabrica. El método de realización es diferente. Buena parte del coste y del esfuerzo está en la ingeniería: la arquitectura, el detalle del diseño, la codificación.
- La complejidad en su definición está dada por la volatilidad de los requisitos (se solicitan cambios mientras se está construyendo, y algunos son auténticas oportunidades para añadir valor a la solución final) y la incorporación de nuevas funcionalidades a partir de lo desarrollado (se añaden requisitos y así se incrementa el software bajo construcción).
- No se estropea, como lo haría una máquina. Los defectos introducidos inadvertidamente durante el desarrollo se arreglan, no con piezas de repuesto sino corrigiendo o modificando el diseño. Pero puede deteriorarse gradualmente con el tiempo a medida que se cambia o incrementa y se van introduciendo nuevos defectos.