Copyright (c) 2009 Héctor Francisco Hernández <hectorfh@gmail.com>.
La copia exacta y la distribución de copias exactas de esta página son permitidas mundialmente en cualquier medio, provisto que esta nota se mantenga.
Dice un importante libro de ingeniería de software:
Muchas personas asocian el término software con los programas de computadora. De hecho, ésta es una visión muy restrictiva. El software no son sólo programas, sino todos los documentos asociados y la configuración de datos que se necesitan para hacer que estos programas operen de manera correcta. Por lo general, un sistema de software consiste de diversos programas independientes, archivos de configuración que se utilizan para ejecutar estos programas, un sistema de documentación que describe la estructura del sistema, la documentación para el usuario que explica cómo utilizar el sistema y, en cuanto a los productos de software, sitios Web que permitan a los usuarios descargar la información de productos recientes.
Claro está que asociar el término "software" con los programas de computadoras es una visión restrictiva. Sin embargo, la visión del autor acerca del término también lo es. El punto es que en ningún momento se ha incluído a las personas como parte de un sistema "software", ni a los usuarios, ni a los desarrolladores, ni a los implementadores. ¿Acaso no lo son?
En mi opinión, el "software" es poco más que conocimiento. Construir un sistema consiste en generar conocimiento, parte de este conocimiento se plasma en el código fuente de los programas, otra en la documentación, pero gran parte se encuentra en el cerebro de los desarrolladores y de los usuarios. Es mencionado como "conocimiento tácito", a diferencia del otro que se llama "conocimiento explícito". Mucho de este conocimiento tácito no es posible codificarlo (convertirlo en conocimiento explícito) ni transferirlo. ¿Acaso no es este conocimiento parte del sistema?
Poseer una visión u otra cambiará las decisiones que tomemos a la hora de gestionar proyectos software. Si no consideramos a las personas como parte de él, probablemente creamos que sea posible dejar ir a un desarrollador, por ejemplo, sin perder un pedazo del sistema. Debemos prever antes de comenzar el proyecto que una parte importante de los resultados obtenidos será el conocimiento logrado por la gente que participe de él. Este conocimiento es también patrimonio de la organización (se conoce como capital intelectual) y debe ser gestionado, sería inocente ignorarlo y no actuar en consecuencia.
Resumiendo mi idea, creo que el software no se trata de programas de computadora, de manuales de usuario o de diagramas UML, sino de conocimiento. Esas son sólo algunas de las formas en las que el conocimiento puede presentarse, pero existen otras más complejas. No reconocerlas podría conducir a tomar malas decisiones.
Referencias
Artículo de la Wikipedia acerca de la Gestión del Conocimiento
Libro "Ingeniería del Software" de Ian Sommerville