Categoría : Requisitos

Requisitos, Requisitos, Requisitos.

Y lo que antes en negocios era ubicación, ubicación, ubicación es nuestro talón de Aquiles en Software: Requisitos, requisitos, requisitos.

En realidad abstrayéndonos de la implementación y pensando en términos de reglas de negocio es el mayor riesgo y el responsable del fracaso de la mayoría de los proyectos.

¿Que pasa con los requisitos?, pues que son un contrato y si el sistema hace lo que los requistos dicen pues estamos bien (no iremos presos), siempre y cuando que los requisitos y sus especificaciones documentadas sean aprobadas por el cliente.

De esto surgen dos escenarios negativos:

  1. Que el cliente esperaba más de lo que el sistema hace.
  2. Que el sistema no implementa los requisitos.

¿Que errores de dirección permiten que ocurra esto? pues en lo que siempre fallan quienes se centran en la tecnología y no en las reglas de negocio de lo que estamos desarrollando – cosa que alguna vez me ocurre:

  • No existe gestión de espectativas: El cliente normalmente no entiende hasta donde llega el proyecto, se debe definir un alcance: ¿Qué es el proyecto? ¿Que no es el proyecto?
  • No existe un listado de características y de funcionalidades formal del sistema: Si no hay documentos no hay nada que hacer.
  • Que los documentos de requisitos están en lenguaje técnico que el cliente no entiende.
  • Que no se da la importancia a la gestión de la configuración: Un gestor de configuración es casi un médico heroe, se encarga de controlar los artefactos producidos,sus cambios, versiones, su archivo, su coherencia, etc; no tener un gestor de configuración – o no hacer las actividades de gestión de configuración – es conducir un automovil con los ojos cerrados.

Y yo que creía que el gestor de configuración era quien configuraba las máquinas. ….

Leer Más →

Listado de características v/s Casos de Uso.

Se supone que cuando empezamos en un desarrollo tenemos un listado de características con lo que debe hacer el sistema y luego hacemos nuestros Casos de Uso. El tema es ¿Cuál debo hacer?, ¿Es mejor cumplir una característica completa? o ¿enfocarnos en los casos de uso?, la respuesta es “depende“.

Plantéo el siguiente escenario:

La aplicación debe :

  • Enviar un SMS que indique tiempo al cual se encuentra un Autobus desde un paradero al recibir un SMS con el siguiente formato: “Paradero LineadeAutoBus” Ej.: 105 591

Esto de “la aplicación debe” son nuestro Listado de Características.

Y como consecuencia de este Listado de Características obtenemos los famosos Casos de Uso, que serán nuestra compañía el resto del desarrollo.

Los Casos de Uso son:

¿Con que partimos para desarrollar?, pues tenemos las 2 alternativas:

  1. Realizar la Característica 1.
  2. Realizar un caso de uso.

Para decidir se considera el nivel de visibilidad comprometido, si el cliente tiene un poco de paciencia podemos partir por los casos de uso; si no partimos con la característica.

Estoy seguro que el desarrollo con casos de uso nos permitirá un diseño elegante desde un primer momento, pero que a lo mejor tardaremos un poco más en mostrar algo completo – recordemos que los clientes quieren resultados, no diagramas de Ingeniería que sólo nosotros entendemos – debemos hablarle en su lenguaje.

Si tenemos un poco más de tiempo conviene comenzar con los Casos de Uso, si no tratemos más “visual” el entregable y realizemos primero alguna de las características. Finalmente el producto tendrá la calidad de hacer lo que tiene que hacer, de haber aplicado principios de OO y la elegancia de los patrones de diseño.

Leer Más →