Construcción del software

El proceso de construcción del software es el conjunto de actividades que deben efectuarse desde que aparece una necesidad de mecanización hasta que disponemos de la funcionalidad para utilizarla.

Alguien podría pensar que si hay que confeccionar un programa, con empezar e ir haciendo ya es suficiente. Ésta es la visión más artesanal de la construcción de programas de ordenador. Podemos considerar cada programa como una obra de arte que pone de manifiesto la habilidad de su constructor. En una visión más eficiente, el hecho de construir un software tiene los mismos requerimientos que elaborar cualquier otro producto o servicio. Para hacerlo de forma eficiente necesitamos una metodología que nos lleve desde el diseño del producto o servicio hasta la puesta en marcha de ese servicio o la finalización del producto.

Podemos justificar la visión artesanal si hay que desarrollar un programa aislado que necesite una funcionalidad que no tenga que estar relacionada con otros programas o sistemas. Por norma general, en las organizaciones es preciso desarrollar sistemas informáticos completos que pueden incluir un gran número de programas interrelacionados y, en estos casos, tenemos que abandonar la visión artesanal con el fin de enfocar el proceso hacia la visión eficiente.

De hecho, una de las razones por las que la construcción del software se encuentra con tantos problemas de eficiencia reside en la dificultad de disponer de metodologías de construcción de software que sean adecuadas. (Leed en Miralles (1999) una reflexión sobre este tema; concentraos en los capítulos 1 y 2 de la lectura.)

El ciclo clásico

Desde hace un tiempo se ha establecido una metodología de desarrollo de software denominada ciclo de vida del software (estableciendo un claro símil con el ciclo de vida de los seres vivos) que se ha utilizado como referencia para hacer software.

El ciclo clásico de desarrollo de software se basa en los siguientes principios:

	Dividir el ciclo de desarrollo en etapas formales y subdividir cada etapa, de forma jerárquica, hasta el menor detalle posible.
	Establecer puntos de control del proceso que permitan asegurar la calidad del producto desarrollado.
	Dejar claro el papel de los usuarios y de los técnicos de desarrollo. Los usuarios intervienen en unos cuantos puntos de control para proporcionar información de cómo tiene que funcionar el sistema, así como para validar el producto desarrollado.

El ciclo de vida ampliado

Desde el punto de vista del desarrollo, el ciclo de vida que hemos descrito es el propio de una organización que desarrolla un software (para sí misma o para otros).

Desde el punto de vista de la empresa que contrata el software a otra, el ciclo no está del todo completo, ya que debemos tener en cuenta el efecto de interrelación entre ambas empresas.

En este caso, las etapas que componen el ciclo clásico conforman lo que podríamos denominar la fase de producción. Antes de llevar a cabo la producción, debe existir una etapa de preparación y después una de cierre del proyecto. Cada una de estas etapas tendría el siguiente contenido:

Etapa de preparación

El objetivo de esta etapa es decidir qué hay que hacer y quién debe hacerlo y, si es preciso, cómo hay que hacerlo. Las tareas propias de esta etapa serían las siguientes:

Petición de información. Se trata de recopilar información de los proveedores expertos con la idea de completar la especificación de requerimientos.

Petición de propuestas. Cuando los requerimientos están claros, podemos solicitar propuestas de colaboración a los posibles proveedores.

Contratación. El procedimiento formal consiste en establecer las condiciones de colaboración con el proveedor: decidir las condiciones, cerrar el precio, firmar los contratos, etc.

Etapa de cierre

Es la etapa en la que se lleva a cabo la recepción del producto y su puesta en producción. Puede incluir actividades de formación de usuarios o de difusión del nuevo sistema informático.

Nuevas aproximaciones

Construcción de prototipos

Cuando un sistema de información es muy complejo se hace difícil fijar todos los requerimientos antes de construir el sistema informático que le sirva de soporte. Si nos equivocamos en los requerimientos de nuestro sistema y lo construimos, cuando lo tengamos desarrollado podemos darnos cuenta de que no nos sirve. Esto puede parecer una posibilidad remota, pero no es así, puesto que no pocos sistemas informáticos han tenido que ser rechazados una vez construidos por no responder a las necesidades del sistema de información.

	El método de desarrollo de acuerdo con un prototipo se propone reducir la probabilidad de que el sistema informático construido no responda a los requerimientos de los usuarios.

Con esta idea, se inicia el proyecto de desarrollo haciendo una primera aproximación, de forma sencilla y superficial, de lo que queremos que haga el sistema. A partir de esta especificación se construye un prototipo de lo que será el futuro sistema y los usuarios lo analizan con el fin de ver si satisface sus necesidades. En caso de que sea así, se define un conjunto nuevo de requerimientos o de perfeccionamiento de los anteriores y se incluyen en el prototipo. El nuevo prototipo se pone a disposición de los usuarios, éstos lo analizan y seguimos con el ciclo.

El funcionamiento de desarrollo de acuerdo con un prototipo aparece esquematizado en la figura adjunta.

Paquetes integrados de gestión

En un núcleo específico aparecen detalladas las características de los paquetes integrados de gestión, pero ahora nos interesa poder definirlos como una forma adicional de introducir sistemas informáticos de negocio en las organizaciones.

Los paquetes informáticos fueron los embriones de los paquetes integrados de gestión. Un paquete informático resuelve la funcionalidad estándar de una cierta parte del sistema de información.

Podéis encontrar una descripción de esto en Laudon (2002, pág. 323-324).