jueves, 26 de junio de 2008

Team Skill 3: Definiendo el Sistema

En el Team Skill anterior (Team Skill 2: Entendiendo las Necesidades del Usuario), mencioné que todo lo que el libro trata (Managing Software Requirements - A Unified Approach) está orientado a una metodología orientada al plan, como RUP por ejemplo. Una metodología orientada al plan en general sirve para proyectos grandes, donde el negocio no es muy cambiante, donde se sabe que no van a haber cambios radicales en los requerimientos durante el desarrollo del proyecto (si vamos a construir un edificio, necesitamos los planos primero y, una vez aprobado estos planos, a nadie se le va a ocurrir pedirme una pileta de natación en el segundo piso, cuando el edificio ya está construido), y lo más importante: donde necesitamos documentación, calidad y seguridad desde la primera vez que el producto se implanta en producción. A nadie se le ocurriría usar una metodología ágil donde hay vidas en juego (imaginen un marcapasos hecho con Scrum o un cohete; imaginen que en dos semanas presentamos la primera versión de un respirador y lo ponemos a funcionar en una persona), o donde el proyecto es muy grande, o donde contamos con un equipo que en su mayoría son programadores juniors.

Por eso, es importante tener en cuenta el contexto al que apuntan estas Habilidades Grupales.

Sin embargo, nada impide que pueda llevar a cabo un proyecto con una metodología propia que pueda ser un mix de varias metodologías. Por ejemplo, en una Plainning Meeting, el Scrum Master podría aplicar alguna de las técnicas de relevamiento vistas en el post anterior con el Product Owner, ¿por qué no?, para entender algunos ítems del backlog, para ayudar al Product Owner a priorizar los ítems del backlog, para ayudar a relevar los requerimientos, que es a lo que apuntan sobre todo las primeras dos Habilidades Grupales.

Dean Leffingwell y Don Widrig son un poco rígidos a veces en la forma de presentar los temas. Tengamos presente que lo que ellos ofrecen son herramientas, que podrían ser usadas en otros contextos que no sean RUP.

¿Qué tenemos hasta ahora?

Hemos analizado el problema del usuario y hemos entendido sus necesidades. Tenemos un conjunto de funcionalidades anotadas por ahí. Si estamos en RUP, estamos acabando la fase de Inicio. Tenemos gran parte del Business Modeling, tenemos gran parte de los requerimientos, estamos por empezar con el Análisis y el Diseño.


Nos movemos del entendimiento del problema y la comprensión de las necesidades del usuario a empezar a definir la solución. Al hacerlo, daremos el primer paso fuera del Dominio del Problema, la tierra del usuario, y nos adentramos en el Dominio de la Solución, donde nuestro trabajo es definir un sistema para solucionar el problema. (¿Se acuerdan de esta pirámide que les mostré en el primer post?)


Los sistemas complejos requieren estrategias globales para la gestión de requerimientos de información y hay un montón de manera de organizarlos. La pirámide muestra una jerarquía de información, comenzando por las necesidades del usuario, siguiendo por las funcionalidades (features) y luego internándonos en los requerimientos de software más detallados, tal como se expresan con el modelado de casos de uso o con las especificaciones tradicionales.

Es hora de "bajar" esto a papel y plasmarlo en documentos, lo que para RUP significa llenar templates.

Los Artefactos de RUP

RUP, entre otras cosas, ofrece una serie de una serie de plantillas/documentos que "obliga" a llenar (el "obliga" depende de que tanto recortemos la metodología y que tanta documentación el auditor nos obligue a entregar). Los documentos son muchos. El libro, en este Team Skill, menciona cinco que considera cruciales para definir el sistema:
  • Documento de Visión
  • Especificación de Requerimientos de Software (SRS)
  • Visión de la Familia del Producto
  • Documento de Requerimientos de Marketing (MRD)
  • Documento "delta" de Visión

El Documento de Visión combina elementos del MRD con el SRS. Incluye las necesidades del usuario, las funcionalidades del sistema y los requerimientos comunes del proyecto. Cada proyecto debe tener un Documento de Visión.


Dean Leffingwell y Don Widrig proponen que para la primera versión del software, el Documento de Visión contenga:
  • Información introductoria
  • Descripción de los usuarios del sistema y de los mercados servidos
  • Funcionalidades para la versión 1.0
  • Otros requerimientos no funcionales
  • Funcionalidades relevadas que no serán inclui das en la versión 1.0
Los Documento "delta" de Visión son aquellos que haremos en las siguientes versiones, en los que deberemos especificar qué ha cambiado y cualquier otra información a incluir por propósitos de contexto.

El Documento de Requerimientos de Marketing (MRD) contiene, entre otras cosas:
  • Ventanas en el mercado
  • Targets de mercado
  • Packaging
  • Licenciamiento
  • Canales de Distribución
  • Costos de Marketing
  • Márgenes
  • Disponibilidad de Recursos
No hay mucho que hablar de los otros documentos, salvo del SRS, que lo trataré en el Team Skill 5: Refinando el Sistema.

El Sponsor del Producto

Otro de los temas que se trata en esta Habilidad Grupal es el Sponsor. Dean Leffingwell y Don Widrig reconocen que sin alguien que sea el Sponsor de los requerimientos para nuestra aplicación y que soporte las necesidades del cliente y del equipo de desarrollo, no tendríamos forma de saber si las decisiones difíciles y conflictivas se resolverán. Sin Sponsor es probable que tengamos requerimientos a la deriva, retrasos y decisiones poco óptimas forzadas por el deadline del proyecto.

Al Sponsor se lo nombra Dueño del Documento de Visión y de las funcionalidades en él contenidas. A su vez, el Sponsor y el equipo de trabajo deben proveer un Tablero de Control de Cambios (Change Control Board) que soporte las decisiones y asegure que los cambios en los requerimientos sean aprobados antes de ser aceptados.

Entradas Relacionadas