Cómo contratar software a la medida

El primer paso

Cuando una empresa inicia un proyecto de software, y decide hacer un contrato de desarrollo, se debe a la existencia de una necesidad que se debe suplir. Sin embargo, muchas empresas no se toman el tiempo y esfuerzo para definir cual es esta necesidad. En esa medida, se puede iniciar un proyecto cuyos interesados (stakeholders) tengan diferentes visiones y, peor aún, diferentes expectativas.

Si no es claro, ni unificado entre los interesados cuales son las expectativas, menos claro y unificado será el criterio para saber si se han alcanzado. Con estas condiciones, a medida que avanza el desarrollo se harán supuestos, se cambiarán definiciones, se asumirá que algunas cosas son obvias, y de esta forma el proyecto cambiará en la medida en que se muevan los vientos, y al final llegará a un punto no deseado.

Así, cuando se haga el desarrollo con estas condiciones, al momento de hacer la recepción se darán discusiones sobre lo que el software no cumple, argumentando falta de calidad, lo que en una tercera parte de las ocasiones hace que el proyecto termine mediante la cancelación del contrato.

El primer paso, antes de pensar en hacer contratación, es aclarar, definir y tener consenso entre todos los interesados de cual es el objetivo del sistema que se va a desarrollar, y cómo se sabe que el objetivo se ha cumplido.

Los objetivos de un negocio no son dependientes del color de una pantalla, ni de los campos que están incluidos en un formulario. Incluso hay diferentes formas de cumplir el objetivo y con diversos niveles de complejidad.

Cuando esté claro cual es el objetivo, hay que buscar, de ahí en adelante, la forma más simple para satisfacer ese objetivo. Es fundamental la simplicidad.

El gran problema es la comunicación

Basado en la premisa de que un contrato es un acuerdo entre partes, se deduce que es necesario que ambas tengan un claro conocimiento de los resultados esperados al final de la implementación de un software.

Presumiendo la buena Fe de ambas partes, podemos deducir que en un contrato de desarrollo de software, el contratante dispone de sus recursos económicos para solventar una problemática, relacionada con el manejo de su información y el contratista está destinando su potencial profesional para generar herramientas que atiendan estas necesidades, a cambio de una retribución económica. Ambos estarán buscando un beneficio mutuo mediante la ejecución del contrato.

Sin embargo, en muchos casos, los proyectos de desarrollo de software finalizan en sobrecostos, adiciones presupuestales, incumplimiento en los cronogramas, malos entendidos y pleitos en donde ambas partes terminan con malestar y pérdidas económicas y lo que es aún peor: no se termina el software objeto del contrato.

El contratante, quien tiene las necesidades, es el responsable de transmitir el mensaje al contratista, y asegurarse que éste sea correctamente recibido. Así mismo, el contratista tiene el deber de validar que tenga las características técnicas que son requeridas.

En un fallo de una corte de Mendoza, Argentina encontré este párrafo que denota la problemática: “La situación de desigualdad entre las partes, característica de los contratos de adhesión, se agrava en los contratos informáticos, en los cuales el cliente por ignorancia técnica no puede establecer juicio sobre el producto o servicio que se le propone”.

La mejor forma de establecer un acuerdo que genere el correcto compromiso de ambas partes, es mediante la redacción de un documento escrito, en un lenguaje claro que explique, explícitamente, los términos técnicos que se utilizarán para mitigar los problemas.

Mitos que enmarcan la definición de requerimientos.

Debido al desconocimiento que el contratante tiene con respecto a las metodologías que se pueden utilizar, para plasmar en un documento los requerimientos que se tienen, es común que erróneamente se piense que la redacción tiene que ser llevada a cabo, bien sea por la misma persona que tiene la necesidad o por un gurú de la informática que tenga un conocimiento absoluto y experiencia en las metodologías formales.

Ninguno de los dos enfoques planteados es correcto. Los requerimientos son el punto de intersección entre el mundo del negocio y el mundo del software; por este motivo debe contener los dos ingredientes: personal que tengan el conocimiento del dominio a profundidad y de forma holística, es decir que sea integral e integrado, y conocimiento específico en técnicas metodológicas de expresión de requerimientos, tanto funcionales como no funcionales (también llamados técnicos).

Por este motivo, se recomienda que el análisis de requerimientos sea llevado a cabo por un equipo de trabajo, en el cual deben participar: los directivos, que detectaron la necesidad y que están destinando los recursos para solventarla; los operarios, que se enfrentan en su rutina diaria con los problemas existentes; y el equipo de IT, que conoce las tecnologías que pueden aplicarse. Todo guiado en un encuadre metodológico, que indique el lenguaje que se debe utilizar en el documento.

Una mala práctica generalizada por quienes van a contratar software por primera vez, es realizar la comunicación con cada una de las casas de software convocadas en forma rápida, verbal y sin muchos detalles. Esperando que con esa invitación a participas se obtenga en forma rápida y exacta la evaluación de tiempos y costos con los que se comprometerá el contratista. El problema no es la cantidad de páginas, sino la precisión con que se indica la necesidad que se desea satisfacer.

Éstas prácticas nos hacen recordar la caricatura relacionada con la especificación de un columpio, en donde lo que especificó el usuario es totalmente diferente a lo que necesita.

El desenlace de esta historia, de contratación informal, es que, como es natural, cada una de las casas de software pretenderá aplicar la tecnología que domina e intentará resaltar sus ventajas competitivas en su propuesta. Como resultado se tendrán cotizaciones y propuestas muy diferentes, todas diciendo que sí cubren los requerimientos (los que cada proponente tiene en la mente), pero no homogéneas dado que cada una presentará cobertura a las necesidades, que la casa de software alcanzó a identificar en la charla. Adicionalmente los cronogramas no serán coherentes y los costos presentados variarán abismalmente. El problema que se presenta es que no se podrán comparar entre sí y la elección prácticamente será al azar.

La construcción de software es un proyecto de ingeniería, que puede ser asociado con la construcción de un edificio: antes de iniciar la obra se hace un estudio de suelos y los planos arquitectónicos. Entre más grande y ambicioso sea el edificio, más importancia tienen éstos estudios.

De igual forma, un proyecto de software requiere estudios anteriores que definan su alcance y arquitectura, y es necesario invertir recursos importantes en su realización. En términos técnicos, algunas metodologías las llaman Inception, en otras arquitectura empresarial: La primera se refiere a un solo desarrollo y la segunda a la esquematización general que se deriva en varios proyectos, pero ambas corrientes reflejan la importancia de tener el esbozo de lo que se va a hacer antes de lanzarse a una contratación de desarrollo de software.

Características de un buen documento de especificación de requerimientos

En este punto el lector podrá pensar que un documento de especificación de requerimientos es un documento técnico, escrito en un lenguaje incomprensible; por el contrario, estos documentos deberán estar escritos en un lenguaje claro para el contratante y el usuario; y, sobretodo, describe las necesidades del negocio y las características que debe tener el software para satisfacerlas. Por supuesto que deberán escribirse usando una forma metodológica particular y seguir unos estándares mínimos, para asegurar que se cubran todos los aspectos que deben tomarse en cuenta.

El documento deberá detallar cada uno de los requerimientos en un lenguaje preciso y deberá cubrir completamente los requerimientos del sistema. Lo que se quiere lograr, es que al momento de hacer la contratación del desarrollo, las reuniones con las casas de software participantes, sean únicamente para despejar dudas, pero no para explicar el detalle del propósito del contrato.

De esta forma tendremos un documento que delimite el alcance del proyecto y con el cual el contratista pueda identificar los diferentes módulos que componen el sistema.

Se recomienda que el lenguaje utilizado no incluya ambigüedades, evitando palabras como: “etc”, “entre otros”, “a satisfacción”, “amigable”, “rápido”. Adicionalmente, los términos técnicos y los términos utilizados por el contratante, para referirse a asuntos de su negocio y que puedan ser sujetos de malas interpretaciones, deberán alimentar el capítulo llamado “Glosario de términos”.

Los requerimientos están relacionados con el negocio; en esa medida el documento no deberá estar sesgado a tecnologías, excepto en los aspectos que por restricciones del negocio mismo, sean requeridos e imprescindibles.

Finalmente el documento debe brindar una calificación a los requerimientos para indicar su prioridad y discriminando entre aquellos que son imprescindibles y aquellos que son deseables pero que, aún así no estén contemplados en la propuesta, esta será tenida en cuenta.

Beneficios al utilizar metodologías formales

Tener un documento de requerimientos formalmente construido, unido con términos de referencia en donde se pueda calificar realmente lo que sea importante para el contratante, hará que las diferentes propuestas se puedan comparar entre sí y que todas ellas cubran completamente los requerimientos calificados como imprescindibles. Además se identificarán y diferenciarán claramente los valores agregados adicionales ofrecidos por cada proponente.

Este documento se podrá utilizar como un listado de chequeo para revisar las entregas parciales y finales realizadas por la casa de software elegida garantizando que se evaluarán todas las funcionalidades solicitadas.

Al integrar dentro del equipo redactor del documento a los operarios que utilizarán el software y que conocen la rutina diaria se mitigará la aparición de funcionalidades no tenidas en cuenta.

El documento debe incluir todos los aspectos, de forma que el contratante y el contratista tenga claridad en la existencia de requerimientos ocultos que implican trabajo y que muchas veces pasan desapercibidos, como aquellos relacionados con la seguridad, la redacción de los manuales de uso del sistema, el mantenimiento del software en funcionamiento.

Los contratistas que no tengan posibilidad de implementar alguno o varios de los requerimientos que no son imprescindibles podrán participar con su propuesta especificando esta situación y el contratante podrá evaluarla y calificarla objetivamente.

El alcance del proyecto estará delimitado mediante un compromiso escrito lo cual evitará la aparición de nuevos requerimientos durante la fase de desarrollo, a este proceso se le llama control de cambios. Al tener delimitado el alcance se podrá realizar una estimación de costos y tiempos de forma más acertada.

Complementariamente se tendrá una base de negociación con la casa de software contratada, cuando se detecten nuevos requerimientos durante la fase de desarrollo, castigando la implementación de funcionalidades de menor importancia. Lo cual facilitará llegar a acuerdos que permitan mantenerse dentro del presupuesto. Todo esto hace parte del proceso de control de cambios.

Finalmente el tener un documento de requerimientos formal permitirá: Delimitar las fases del proyecto, contratar la implementación parcial de la solución, si no se dispone de los recursos necesarios, o dividir el desarrollo en varios proyectos También facilitará el crecimiento controlado del software.

Temas fundamentales en la especificación de requerimientos

El documento resultante del trabajo deberá tener una visión que realizará la descripción general del entorno y las necesidades del negocio que se suplirán con el sistema; planteará los objetivos que se persiguen: describirá el estado actual del contratante, si ya tiene avances; y se delimitará el alcance de la solución propuesta. Cerrando esta información, se deberá redactar un glosario de términos, que mitigue la presencia de malos entendidos, por el uso de una palabra con significado ambiguo.

El documento deberá continuar con una descripción de los actores involucrados en el proyecto, indicando quienes están interesados en la solución y también presentar los roles de los usuarios que la utilizarán.

Cada uno de estos roles de usuario tendrá asociado varios casos de uso, que son procesos atómicos y autocontenidos, en los cuales un usuario utiliza el sistema de información. Estos casos de uso deberán redactarse de tal forma que se indique paso a paso la interacción entre el usuario y el sistema de información.

Basándose en los casos de uso, se presentarán todos los requerimientos funcionales, los cuales se podrán identificar fácilmente con un título que complete la frase: “El sistema deberá permitir ...”.

En la tabla se presenta un posible ejemplo de redacción de un requerimiento funcional.

Administrar Usuarios del sistema
Usuarios: Administrador	Interfaz: Web	Prioridad: 3
Descripción: El sistema permitirá la consulta, adición, modificación y borrado de los usuarios del sistema con sus datos personales. Adicionalmente permitirá cambiar la clave de acceso y los permisos correspondientes al perfil.
Información de datos: email: identificador único clave: para autenticar el acceso permisos: para habilitar o bloquear funcionalidades tipo: indicará si es superusuario o usuario normal.		Frecuencia de uso:	Eventual
		Volumen de datos:	< 1kB / usuario
		Carga inicial:	200 usuarios (< 1 kB / usuario)
Observaciones: Un usuario con esta funcionalidad activa no podrá modificar su propio perfil ni modificar el perfil de un usuario que tenga mayor cantidad de permisos que él mismo, a menos que sea un usuario con permisos especiales

La forma cómo se definen los requerimientos, que tan formal y detallado, depende directamente de los riesgos del proyecto. Entre más riesgoso sea un proyecto, más formal debe ser.

Tras los requerimientos funcionales, se presentarán los requerimientos no-funcionales o técnicos, que generalmente están ocultos a la vista del usuario pero que también requieren ser especificados y exigirán esfuerzos de trabajo por parte de la casa de software elegida para la implementación.

Algunos de los tipos de requerimientos técnicos, que deben aparecer en el documento y que deberán ser complementados con aquellos que se detecten en cada proyecto, son:

1. Usabilidad / Amigabilidad del software.

1. Confiabilidad.

2. Seguridad.

3. Desempeño.

4. Integridad de la información.

5. Interfaces con otros sistemas.

6. Portabilidad.

7. Ayudas en línea.

8. Escalabilidad.

9. Mantenibilidad.

Los requerimientos no funcionales son dependientes directamente del negocio, es decir, no deben ser definidas por personas técnicas sino de acuerdo con el negocio en sí. Estos requerimientos definen qué tan robusta o liviana debe ser la estructura del software. Por este motivo, también se llaman requerimientos arquitectónicos.

El contratante deberá tener en cuenta que la implementación de estos requerimientos tendrá también un impacto en el costo del software resultante, por lo tanto también deberá indicar la prioridad que existe para cada uno de ellos.

Referencias bibliográficas y en internet

• SCJMendoza, Sala I, 05-02-1990, “Sistex S.A. c/ Oliva S.A. Valerio” en LL 1990-D-419 y LL 1991-A-404, con nota de Mosset Iturraspe