sábado, 7 de junio de 2008

Team Skill 1: Analizando el Problema

En el post anterior, presenté el libro Managing Software Requirements - A Unified Approach de Dean Leffingwell y Don Widrig (ISBN: 0-201-61593-2). El libro propone una metodología ordenada para la Administración de Requerimientos, enfocándose en 6 Habilidades Grupales (Team Skills) que abarcan desde analizar el problema del usuario en la fase temprana de Inicio, hasta la verificación y/o validación para corroborar que se sigue construyendo el sistema correcto en la fase de construcción.

En la introducción dada en el post anterior se habló de las causas principales de los fracasos y la pobre calidad en los proyectos de desarrollo de software, y se dieron las definiciones de Problema, Necesidades del Usuario, Funcionalidades del Sistema y Requerimientos de Software. Quiero destacar que la diferencia fundamental entre Funcionalidades del Sistema y Requerimientos del Software es que las primeras pertenecen a la Visión del Usuario y los segundos a la Visión del Desarrollador. Los features son descripciones de alto nivel, expresados en el lenguaje del usuario; en cambio, los requerimientos son descripciones que expresan dichas funcionalidades de un modo más detallado. Los requerimientos deben "testeables" y poder ser validados.

Pasos para entender el Problema

Ahora sí, metiéndonos en la Habilidad Grupal que hoy nos concierne, introduciremos un conjunto de habilidades que el equipo puede aplicar antes de comenzar con el desarrollo de la aplicación. Leffingwell y Widrig mencionan cinco simples pasos, una técnica de análisis que puede ayudar al equipo a obtener un mejor entendimiento del problema a ser resuelto.

1 - Acordar la definición del Problema

Una buena práctica, por ejemplo, sería anotar en un papel los siguientes datos:

Elemento
Descripción
El problema de
Describir del problema.
Afecta a

Identificar los participantes afectados
por el problema.
El resultado del cual

Describir el impacto del problema en los
participantes y en las actividades del negocio.
Beneficios de

Indicar la solución propuesta y una lista
de beneficios clave.

Los datos de esta tabla, por supuesto, se irán completando más detalladamente a medida que se completen los siguientes pasos.

2 - Entender las causas principales: El problema detrás del problema

Hay una variedad de técnicas para encontrar las causas principales de un problema, pero una de las más conocidas, y la que propone el libro, es la del diagrama de Ishikawa, también conocido como diagrama de causa-efecto, también conocido como espina de pescado.

Este diagrama permite identificar de forma gráfica las diferentes causas de un problema. En la punta de la flecha se escribe el problema y en las espinas que inciden sobre la recta se escriben las causas que al analista y al usuario van encontrando. (Otra variación más sofisticada de este diagrama involucra sub-espinas donde se ubican diferentes causas de un mismo tipo; cada espina identificaría una categoría y cada sub-espina las causas que pertenecen a esa categoría.)

Luego de completar el diagrama de Ishikawa, podemos pasar a una segunda etapa, que consiste en la priorización de las causas. No todas las causas merecen ser estudiadas, no todos los problemas merecen ser resueltos; a veces, el costo de arreglar un problema puede exceder el costo mismo del problema.

Podríamos usar un simple diagrama de Pareto para priorizar las causas.

3 - Identificar a los participantes y a los usuarios

Los usuarios son las personas que determinarán el éxito o fracaso del sistema. Son los interesados fundamentales de que el sistema funcione como ellos necesitan, porque son los que lo van a usar cuando el mismo esté implantado en producción. Los participantes, o el resto de los stakeholders, son cualquier persona materialmente afectada por la implementación del sistema. Algo así como usuarios indirectos. Son los más difíciles de encontrar.

4 - Definir el Alcance de la solución

Para definir el alcance se puede usar algo así como un viejo Diagrama de Contexto, como los que usábamos en análisis estructurado de Yourdon, pero bueno, el libro muestra uno un poco más aggiornado, por supuesto, reemplazando los insulsos rectángulos que representaban a las entidades externas por actores de UML.

El libro lo llama acertadamente: La Perspectiva del Sistema.

5 - Identificar las restricciones a ser impuestas en la solución

Una restricción es una disminución en el grado de libertad que tenemos al proveer la solución. Algunas restricciones pueden convertirse en requerimientos. Otras afectarán a recursos, planes de implementación o de proyecto.

Las restricciones podrían ser del tipo:
  • Económicas
  • Políticas
  • Técnicas
  • de Sistemas
  • de Medio Ambiente
  • de Cronograma
  • de Recursos
  • y muchas más...

Modelado de Negocio

Existe una gran variedad de técnicas que pueden ser usadas en el análisis del problema. En concreto, Managing Software Requirements hace incapié en el Modelado de Negocio , una técnica específica que funciona bastante bien en sistemas complejos de información que soportan las infraestructuras claves del negocio (supongo que su punto más fuerte es que se trata de una técnica que proviene del mundo del análisis orientado a objetos). El equipo puede usar Business Modeling para comprender la forma en que el negocio evoluciona y para definir dónde se podrá desplegar aplicaciones más productivas. El libro habla de un paralelismo entre el Modelo de Negocio y la construcción de la aplicación y dice que es posible usar estos puntos en común para dar origen a la etapa de diseño del software.

El Modelado de Negocio permite:
  • Proveer una definición consistente del negocio.
  • Soportar un análisis del negocio.
  • A los usuarios, hacer reingeniería o mejora de procesos de negocio.
  • Achicar la brecha entre el modelo real y el modelo del sistema.
Para esto, Leffingwell y Widrig se basan en conceptos que surgen del mundo de la Reingeniería de Procesos de Negocio y los combinan con el estándar UML para formar dos tipos de diagramas:
  • Modelo de Casos de Uso de Negocio: usado para identificar roles y entregables en la organización.
  • Modelo de Objetos de Negocio: usado para ver las entidades del sistema y cómo interactúan entre sí.
Estos modelos están compuestos por Casos de Uso del Negocio, Entidades del Negocio, Trabajadores (workers) del Negocio, Unidades Organizacionales, Responsabilidades y Relaciones. El mapeo de Casos de Uso del Negocio a Casos de Uso, de Objetos de Negocio a Clases o de Workers del Negocio a actores no es del todo trivial. Existe un paso intermedio de análisis en el que, por ejemplo, algún worker puede desaparecer y otro puede desdoblarse o automatizarse. Los trabajadores son los que manipulan entidades de negocio e interactúan con otros trabajadores; son los componentes candidatos de un sistema a ser automatizados.

La ingeniería de sistemas se usa como técnica para analizar problemas; nos ayuda a descomponer un sistema complejo en subsistemas. Mediante el Modelado del Negocio podemos tener una mejor comprensión de las aplicaciones de software que deben construirse y el propósito general al cual servirán.

Entradas Relacionadas