El proceso de sofware para una empresa obedece a la necesidad de resolver problemas existentes, anticiparse a problemas que se preveen a futuro, buscar la optimización de sus actividades o buscar ventajas competitivas.
La resolución de un problema podría ser, por ejemplo, la imposibilidad para una gran tienda de registrar la información de los artículos vendidos a mano; una agencia de viajes que prevee crecimiento podría anticiparse a los problemas de manejo de información, mientras que otra podría buscar una mejor comunicación entre los diferentes vendedores; respecto a la búsqueda de ventajas competitivas está, por ejemplo, la venta de boletos por internet para una línea aérea (ventaja existente hasta que el resto también ofrezcan el servicio).
En general el proceso de software parte de las necesidades del cliente (y de los usuarios) y, mediante un proceso de transformación genera un producto software que (en teoría) satisface dichas necesidades. Aquí es importante introducir la distinción entre dominio del problema (necesidades del cliente y usuarios) y dominio de la solución (modelos, código y en general todos los artefactos requeridos para llegar al software).
El proceso de software transforma pues, las necesidades en la especificación de requisitos, ésta en modelos de análisis y en necesidades arquitectónicas, éstos en modelos de diseño detallado y éstos últimos en el código. Es importante no olvidar los manuales de usuario y el sistema de pruebas, por ejemplo. Sin embargo la esencia del proceso software es la transformación:
Requisitos -> Modelos de análisis -> Arquitectura -> Diseño detallado -> Código
De aquí se derivan muchos de los debates actuales sobre el nivel de documentación del diseño requerido, por ejemplo. Las metodologías ágiles hacen hincapié en un minimo de documentación de diseño y un mayor énfasis en el código. La postura del que escribe es que el nivel de documentación y detalle debe estar dado por:
- ¿Qué tanto necesito modelar para comprender? Si el problema es muy simple quizá no necesite un modelo formal con el mayor detalle. El modelado está basado en aquella premisa de "es más simple (y menos costoso) cambiar una idea que un programa"
- ¿Qué tanta necesidad de comunicación tengo? Si no es importante que otros comprendan el modelo (ahora o más adelante) no necesitaré documentarlo. Quizá el código se explica por si mismo.
El nivel de especificación de requisitos debe estar dado por la necesidad del cliente mientras que el nivel del diseño debe estar dado por la cantidad y complejidad de los requisitos. Es decir, si tengo un contrato, por ejemplo, mi especificación de requisitos deberá ser lo más completa posible y libre de errores mientras que si el software es para algo muy trivial bastará con un bosquejo; en relación con el diseño, si los requisitos apuntan a un software complejo y con muchas piezas, entonces mi diseño deberá ser lo más completo posible. Esto se contrapone a las metodologías y métodos que plantean un nivel de especificación y diseño
a priori, independientemente del problema a resolver.
Visto de otra manera:
- La especificación de requisitos es lo que me permitirá llegar de las necesidades del usuario al diseño
- El diseño es lo que me permitirá llegar de la especificación de requisitos al código
Lo que menos tiene sentido , sin embargo, es codificar y después, haciendo ingeniería en reversa, construir los modelos.Siguiendo el proceso de resolución general de problemas, las actividades a realizar dentro del proceso software para transformar las necesidades en software son:
- Definición del qué -> Ingeniería de requisitos
- Definición del cómo -> Análisis, Diseño y Codificación
