jueves, 5 de junio de 2008

Administrando Requerimientos de Software

Managing Software Requirements - A Unified Approach, es un libro bastante interesante de Dean Leffingwell y Don Widrig, publicado en Octubre de 1999 por Addison Wesley (ISBN: 0-201-61593-2). El libro presenta una metodología ordenada que puede servir como guía a la hora de identificar, analizar y especificar formalmente los requerimientos de un sistema de software y que ayuda en la administración de cambios de los mismos. Basándose en la terrible verdad de que descubrir un error en los requerimientos se hace cada vez más costoso a medida que avanzan las etapas del ciclo de vida de un proyecto, Managing Software Requirements se enfoca en 6 Habilidades Grupales (Team Skills) que abarcan desde analizar el problema del usuario y capturar sus necesidades correctamente, hasta la verificación y/o validación mediante pruebas de aceptación de diferente profundidad y cobertura, para corroborar que se siga construyendo el sistema correcto, el sistema que el usuario necesita, durante todo el proyecto, a pesar de los cambios y los nuevos requerimientos que pudieron haber surgido.

Ya que me ha parecido muy interesante la lectura de este libro, he decidido dedicar ocho post, incluyendo éste, dedicados al mismo, que se dividirán de la siguiente forma:


PARTE I - TEORÍA
(7 entradas)

  • Introducción (se trata de esta misma entrada)
  • Team Skill 1: Analizando el Problema
  • Team Skill 2: Entendiendo las Necesidades del Usuario
  • Team Skill 3: Definiendo el Sistema
  • Team Skill 4: Administrando el Alcance
  • Team Skill 5: Refinando la Definición del Sistema
  • Team Skill 6: Construyendo el Sistema Correcto

PARTE II - SU "RECETA" PARA LA ADMINISTRACIÓN DE REQUERIMIENTOS
(1 entrada)

  • Supuestos
  • La receta
Basándome más que nada en la estructura del capítulo 35: "Getting Started", dividiré en dos grandes partes esta serie de post. Toda la primera parte, que la componerán las primeras siete entradas, incluyendo ésta, hablarán sobre la teoría de las 6 Habilidades Grupales. Lo que sería un resumen modesto del libro. La segunda parte será una "receta" proporcionada por el libro que puede servir como checklist para la administración de requerimientos en su proyecto. El octavo y último post estará dedicado a ella.

De más está decir que recomiendo fuertemente la lectura de este libro, ya que no tiene desperdicio. Hay muchos temas interesantes que trata que yo sólo nombraré, o quizá pase por alto. Esos temas que no profundizaré no quiere decir que no sean importantes, ni interesantes; simplemente que no puedo, ni tiene sentido, transcribir todo el libro. Digamos que mi resumen servirá para "abrir el apetito".

Introducción

En los capítulos introductorios, Managing Software Requirements muestra que la industria del desarrollo de software hace un trabajo muy pobre a la hora de entregar aplicaciones de calidad cumpliendo los tiempos y los presupuestos asignados.


Algunas de las causas principales de este problema son:
  • Falta de participación del usuario.
  • Requerimientos y especificaciones incompletos.
  • Cambios en los requerimientos y en las especificaciones.
Los desarrolladores y clientes tienen una actitud común que es: "a pesar de que no estamos seguros de los detalles de qué es lo que se quiere, es mejor comenzar con la implementación ahora, porque contamos con un calendario ajustado. Podemos detallar los requerimientos más tarde". Pero muy a menudo, este enfoque bien-intencionado degenera en un esfuerzo caótico de desarrollo, donde nadie está seguro de qué es lo que el usuario realmente quiere o qué es lo que realmente hace el sistema.

¿Cómo sabemos qué se supone que tiene que hacer el sistema? ¿Cómo tenemos un registro del estado corriente de los requerimientos? ¿Cómo determinamos el impacto de un cambio? Para manejar estas cuestiones, Dean Leffingwell y Don Widrig proponen una filosofía que abarca la administración de requerimientos, la cual han definido como:

Un enfoque sistemático para extraer, organizar y documentar los requerimientos de un sistema. Un proceso que establece y mantiene el acuerdo entre el cliente y el grupo del proyecto respecto a los cambios a lo largo del ciclo de vida del proyecto.

La historia del desarrollo de software ha demostrado que la construcción de sistemas es una disciplina compleja, que debe ser manejada por equipos bien estructurados y entrenados. Cada miembro del equipo estará eventualmente involucrado en ayudar a gestionar los requerimientos para el proyecto. Estos equipos deben desarrollar las aptitudes necesarias para comprender las necesidades de los usuarios, para gestionar el alcance de la aplicación y para construir sistemas que satisfacen las necesidades del usuario. El equipo debe trabajar como un equipo para hacer frente a los desafíos de la administración de requerimientos.

Algunas definiciones

Necesidades del usuario: son reflejos de un problema u oportunidad relacionada con aspectos del negocio, del personal u operativos que deben ser considerados para justificar el desarrollo, modificación, compra o uso de un nuevo sistema. Las necesidades son parte del Dominio del Problema.

Características, funcionalidad o features del sistema: son servicios que el sistema debe proveer para cubrir una o más necesidades de los participantes o stakeholders. Las funcionalidades son parte del Dominio de la Solución.


Requerimientos del software: un requerimiento es una condición o capacidad necesitada por el usuario para resolver un problema o alcanzar un objetivo. Es una condición o capacidad que debe poseer un sistema para satisfacer un contrato, estándar, especificación u otro documento formalmente impuesto. Los requerimientos son parte del Dominio de la Solución.

Problema: La diferencia entre cosas como son percibidas y cosas como son deseadas.