Utilización de la Estrategia de Colaboración de Partes Interesadas con Rational Requirements Composer: Parte 2. Organización del proyecto y espacio del repositorio

Este es el segundo de una serie de cuatro artículos sobre configuración y uso del IBM® Rational® Requirements Composer. La serie abarca cuatro áreas principales: audiencia, organización del proyecto y del espacio del repositorio, estrategia de enlace, y estrategia de colaboración. Esto refleja la necesidad de determinar la audiencia, decidir cuáles artefactos son los que contribuirán a acordar y validar los requisitos, y la necesidad de planificar una estrategia de colaboración con la audiencia. La última sección propone un plan para revisar y mejorar el proceso para la próxima vez.

Lisa Garrity, IT Specialist, IBM

Lisa Garrity trabaja como asesora técnica para IBM Rational software en el Reino Unido. Ha trabajado en el área del desarrollo de software durante 16 años, realizando asesoramiento y ventas técnicas. Entre sus responsabilidades principales se encontraban la determinación, la administración y la documentación de requerisitos empresariales y del análisis de sistemas, así como el soporte de clientes en su búsqueda por el éxito en el desarrollo de software. Lisa es instructora regional de administración y definición de Rational Requirements en el Reino Unido y se unió al Rational software en 2002.



Paula White, Consulting IT Specialist, IBM China

Photo of Paula White Paula White es asesora técnica de IBM Rational software en el Reino Unido. Ha trabajado en el área de desarrollo de software durante más de 19 años. Ha trabajado también como arquitecta, ingeniera de software, instructora, coach, mentora, y asesora. Actualmente, trabaja como arquitecta de marcas Rational y dirige el Rational Brand Architects team en el Reino Unido. Es instructora regional de administración y definición de requisitos en el Reino Unido. Se unió al Rational software en 2002.



21-01-2011

Facilitar la tarea de hallar información sobre requisitos es una de las principales finalidades del IBM® Rational® Requirements Composer. Éste brinda asistencia sobre la validación y discusión de requisitos, así como la reutilización y la comprensión contextual. Los métodos para lograr esto incluyen carpetas, filtros guardados, la creación de etiquetas, atributos y colecciones (ver Figura 1).

Figura 1. Los filtros pueden guardarse por colección, carpeta, etiquetas, atributos
Los filtros pueden guardarse por colección, carpeta, etiquetas, atributos

Estructura en carpetas

La finalidad de la estructura en carpetas es facilitar a los autores el encontrar, crear y editar artefactos de requisitos y, al mismo tiempo, facilitar a los revisores el encontrar y comentar o revisar requisitos formalmente. La clave es considerar a la audiencia.

La estructura en carpetas proporciona un mecanismo lógico de almacenamiento para proyectos. La búsqueda y la exploración también pueden llevarse a cabo a través de las diferentes pestañas, enlaces, etiquetas, filtros y diálogos de búsqueda.

Al usar la interfaz, las partes interesadas en el negocio necesitan comprender de un vistazo cómo navegar, comentar o revisar formalmente el proyecto. Si se espera que las partes interesadas naveguen en la estructura de carpetas, conviene emplear un lenguaje que la gente de negocios comprenda, en lugar de un lenguaje técnico.

Si bien la mayoría de los interesados usan la interfaz de la forma en que se espera —visualizando artefactos y haciendo comentarios—, algunos lo hacen de otra manera. Las partes interesadas podrían preferir imprimir los artefactos y luego hacer comentarios, ya sea utilizando la interfaz o de alguna otra manera.

Enfoques sobre la estructura en carpetas

Aquí se describen varios enfoques para aportar ideas, pero existen muchos otros enfoques que pueden adoptarse. El enfoque más típico, que es el provisto en el Rational Requirements Composer, es utilizar tipos de artefactos. La estructura puede ser modificada por los administradores del proyecto en cualquier momento luego de su creación. Lo que se recomienda es establecer la estructura al comienzo, y hacer tantas actualizaciones menores como sea necesario.

Estructura en carpetas según el tipo de artefacto

Este ejemplo emplea los tipos de artefactos para determinar los nombres de las carpetas. Dado que se espera la colaboración con partes interesadas en el negocio, en lugar de describir las áreas con una terminología técnica, lo hacemos con un vocabulario de negocios:

  • Declaración de visión o proyecto empresarial (por qué se está construyendo el sistema)
  • Diagrama de proceso empresarial
  • Lo que hace el sistema (casos de uso o historias de usuarios)
  • Usabilidad, confiabilidad, rendimiento, capacidad de soporte, escalabilidad (requisitos no funcionales o historias técnicas)
  • Guiones gráficos
  • Glosario
  • Documentos del pre-proyecto
  • Notas de taller
  • Puestos de control
  • Documentos de publicación

En muchos proyectos, resulta útil extraer los antecedentes de los primeros talleres que plantaron las semillas de tales proyectos. Estos artefactos podrían tomar la forma de archivos de fotos o imágenes, documentos o presentaciones que documentan el proyecto empresarial. Esta información podría estar contenida en los documentos de pre-proyectos, en los antecedentes o en las carpetas de notas de talleres

Estructura de carpetas para reflejar un enfoque o método en particular

Muchos proyectos ágiles adoptan un enfoque liviano sobre la documentación, incluyendo los artefactos de requisitos. Las carpetas deben reflejar esto y típicamente deben incluir:

  • Visión o proyecto empresarial
  • Épicas
  • Historias de usuarios
  • Glosario
  • Guiones gráficos
  • Material de referencia

Un enfoque similar al de emplear carpetas según el tipo de artefacto sería apropiado para muchos métodos, incluso aquéllos con ciclos de vida iterativos, crecientes y de estilo en cascada.

Estructura de carpetas por áreas funcionales del sistema o áreas de negocios

Cada área funcional (procesamiento de órdenes o nuevos negocios, por ejemplo) puede incluir diferentes conjuntos de personas dirigiéndola o trabajando en ella. En este escenario, sería preferible establecer una carpeta para cada área funcional, con subcarpetas que contengan los artefactos de esa área.

Cuando un proyecto incluye múltiples áreas de negocios que colaboran en requisitos específicos (ventas, marketing y contabilidad, por ejemplo), podría ser preferible separar las áreas de interés de forma que resulten fáciles de seguir para los Revisores interesados. En este caso, se crea una carpeta para cada área de negocios, y se crean subcarpetas para la revisión de artefactos.

Tabla 1. Ejemplo de estructura de carpetas por áreas funcionales
Área funcionalInformación
Biblioteca de reutilización de proyectos Bits reutilizables, e.g., partes de la interfaz de usuario (UI), glosario
Administración del sistema Requisitos para la parte del proyecto que trata sobre la administración del sistema
Creación de informes Requisitos para la parte del proyecto que trata sobre la creación de informes
Área funcional n Requisitos para otra área funcional (n)
Área funcional n+1 Requisitos para otra área funcional (n+1)
Antecedentes Información que proporcionan los antecedentes del proyecto en general. Esto puede incluir ítems tales como una Declaración de Trabajo, un conjunto de diapositivas que describen la solución propuesta, una foto de la pizarra con el diagrama, y demás.

Etiquetas

Consejos para etiquetar

Las etiquetas son más efectivas cuando se aplican en forma coherente. Si se adopta la política de usar etiquetas específicas (para un área de negocios, por ejemplo), comunicar los beneficios de este enfoque y educar a los autores resulta vital para el éxito. También es aconsejable designar a alguien del equipo del proyecto para que asuma la responsabilidad de asegurar que las etiquetas sean asignadas a un área en particular.

Una etiqueta es una palabra clave o un término asignado a cualquier artefacto o requisito. Luego es usada para buscar o filtrar artefactos y requisitos en toda la serie de proyectos y dentro de cada uno. Etiquetar en los muchos tipos diferentes de requisitos y de artefactos brinda la flexibilidad de agrupar una variada gama de artefactos y requisitos.

Existen etiquetas compartidas y personales:

  • Las etiquetas compartidas se mantienen en carga y descarga, y pueden usarse en consultas por filtrado que han sido guardadas.
  • Las etiquetas personales sólo se usan para filtrar en el área local de una persona.

El etiquetado se usa generalmente junto con carpetas, y también puede utilizarse como un enfoque alternativo.

El etiquetado es útil cuando se emplea junto con filtros, ya que pueden preconfigurarse consultas específicas para que determinados usuarios puedan visualizar artefactos de interés. Por ejemplo, si la estructura de carpetas está organizada por tipos de artefactos, etiquetar por área de negocios en toda la serie de carpetas puede resultar un enfoque sumamente útil. De esta manera se facilita para todos la localización de información relevante.

Una aplicación muy útil del etiquetado es asignar una etiqueta para mostrar que un requisito es parte de una publicación (Publicación 1, por ejemplo). Una vez filtrados, estos requisitos pueden ser incorporados a una colección. Esto resulta particularmente útil cuando se usa el Rational Requirements Composer junto con IBM Rational Team Concert™ porque los ítems del plan pueden crearse automáticamente sobre la base de los requisitos de esta colección.

En teoría, existen diferentes enfoques sobre el etiquetado:

Política ad hoc
Los creadores emplean etiquetas de cualquier manera en que les resulta útil.
Política informal
Esto típicamente incluye cierta estructura y guía: se sugieren algunas etiquetas, tales como nombres de departamentos. También se ofrece flexibilidad para agregar a favoritos.

Estructura de clasificación formal

Pautas y mejores prácticas

Típicamente, las etiquetas se usan más para ayudar en la búsqueda y exploración en el Rational Requirements Composer que para administrar requisitos.

Las etiquetas resultan útiles cuando ayudan a la gente a colaborar mejor entre diferentes roles, equipos y geografías.

Las etiquetas pueden ser especialmente útiles cuando son aplicables a diferentes tipos de artefactos.

Las etiquetas pueden usarse entre proyectos.

Promueven la incorporación compartida e informal a favoritos porque hacen que el uso de herramientas sea más flexible y que los artefactos sean más fáciles de hallar para una amplia gama de usuarios.

El etiquetado se ve favorecido en comparación con una jerarquía profunda de subcarpetas porque las jerarquías profundas pueden ser difíciles de navegar.

Sembrar un proyecto con etiquetas compartidas desde el comienzo impulsa el uso de etiquetas.

Generalmente se prefieren los grupos de atributos para clasificaciones más formales.


Grupos de atributos

Los atributos especifican características sobre un requisito o artefacto. Los grupos de atributos proporcionan una manera de reutilizar atributos entre determinados artefactos y requisitos de proyectos. Los atributos se usan para ordenar y realizar consultas en grupos de requisitos y artefactos.

Nombre de archivo, fecha, usuario, tipo de artefacto y status del ciclo de vida son atributos predeterminados disponibles en artefactos para el filtrado.

Definir atributos en forma específica (por prioridad de negocio, estabilidad y dificultad, por ejemplo) da como resultado opciones de filtrado adicionales. Una buena forma de decidir cuáles atributos y grupos de atributos usar es pensar cuáles informes o filtros podrían utilizarse para responder a preguntas esperadas.

Consejos sobre atributos

Un tipo de requisito está determinado por el grupo de atributos asociado. Para resultar útiles, los valores de los atributos deben ser conservados. Mantenga el número de atributos definidos al mínimo absoluto.

Tipos de requisitos

Los requisitos emplean grupos de atributos para mostrar sus tipos de requisitos. Un requisito puede estar asociado solamente a un grupo de atributos (ver Tabla 2). Éste se selecciona como parte de la creación de los requisitos, utilizándose el asistente, o bien se incorpora luego de la creación.

Nombre de archivo, fecha, usuario y status del ciclo de vida son atributos predeterminados disponibles en requisitos para el filtrado.

El uso de atributos puede verse afectado por la elección de las herramientas de administración de requisitos y por cómo están configurados los proyectos IBM® Rational® DOORS® o IBM® Rational® RequisitePro® preexistentes.

Tabla 2. Ejemplo de definición de un grupo de atributos
Grupo de atributosAtributoValores del atributo
Grupo de atributos de guión gráfico Estado En curso (predeterminado)
Revisado
En revisión
Validado
Aprobado
- Ordenamiento por ensayo Ensayable
En revisión
No ensayable
- Revisión de arquitectura Revisada
En revisión
- Complejidad para implementar Compleja
Promedio
Baja
- Originador Paula
Lisa
Vivianne
Robin
- Persona de contacto Kirk
Daniel
Judith
Claire
Tabla 3. Ejemplo de una tabla para mostrar la definición de un grupo de atributos
Grupos de atributos Característica Caso de uso Suplementario Guión gráfico Origen
Tipos de artefacto - - - --
Actor - - - - X
Colección - - - - X
Glosario -- -- X
Parte de la interfaz de usuario - - - X X
Diagrama del proceso de negocios - - - - X
Requisito X X X - X
Documento -- - - X
Flujo de pantalla - -- X X
Bosquejo de la interfaz de usuario - -- - X
Guión gráfico - -- X X
Término - - - - X
Caso de uso -- - - X
Diagrama del caso de uso - - - - X
Envoltorio de recursos* -- - - X

*El envoltorio de recursos es para todos los artefactos externos que han sido cargados en el repositorio, tales como archivos JPG de sesiones de pizarra.


Filtros

Consejos:
El guardar filtros compartidos hace que a la gente le resulte más fácil adoptar filtros. Al aplicar un filtro preconfigurado, los usuarios ven una lista más breve de artefactos o requisitos. Como resultado de esto, es menos probable que se sientan abrumados con información que no les pertenece.

Uno de los objetivos de los filtros del Rational Requirements Composer es facilitar el hallazgo de grupos de requisitos y artefactos. Estos filtros trabajan en conjunción con los datos definidos empleando etiquetas, grupos de atributos y enlaces del IBM® Rational® C/ALM (Collaborative ALM) para proporcionar un medio para reducir rápidamente la cantidad de información que ve un usuario. El Rational Requirements Composer provee un repositorio de requisitos para todas las partes interesadas, que contiene una versión de la verdad con un alto nivel de transparencia, de manera que facilitar el hallazgo de información relevante y artefactos es vital para todos los usuarios dentro y entre proyectos. Los filtros posibilitan esto.

Puede tratarse de filtros compartidos que todos pueden usar, o filtros personales creados por un autor para uso privado. Es preferible que se provean algunos filtros compartidos iniciales en nombre del equipo y, en particular, en nombre de las partes interesadas del negocio. Los filtros personales pueden ser vistas específicas guardadas o filtros ad hoc que se usan con frecuencia. La estructura en carpetas es un caso especial de filtrado público, como también lo son las etiquetas.

Capacidad de filtrado ad hoc

Existen muchas formas disponibles de filtrado en el Rational Requirements Composer. Algunos filtros operan sólo si se toma una acción, tal como etiquetar artefactos o establecer valores de atributos a requisitos. Otras capacidades de filtrado funcionarán siempre y cuando se tengan artefactos o requisitos disponibles para listar. Éstas se basan en el nombre del archivo, en la ubicación dentro de la estructura de carpetas, en el nombre del usuario que creó el artefacto, en la fecha, o en el tipo de artefacto.

Filtros compartidos

Cualquier filtro puede ser guardado como un filtro compartido para ser reutilizado por todos los miembros del equipo.

Si se establecen valores de atributos sobre requisitos, tales como “Prioridad” y “Dificultad,” podría crearse un filtro basado en los atributos y ser guardado como un grupo identificado para una iteración. Por ejemplo, todos los requisitos de alta prioridad y alta dificultad podrían guardarse para Iteración 1. El filtrado sobre un atributo tal como el Status, en combinación con un filtro de Iteración o atributo, resulta útil para determinar cuánto trabajo debe ser completado para la próxima iteración.

Ciertos filtros pueden ser útiles para todo el equipo. Quizás un filtro sobre el tipo de artefacto, tal como el guión gráfico y la fecha, durante el último mes ayudaría para que cualquiera pudiera hallar todos los guiones gráficos creados el mes pasado.

La Estrategia de Colaboración de Partes Interesadas puede contener detalles de filtros compartidos preconfigurados previamente guardados.


Colecciones

Una colección es un mecanismo para agrupar artefactos y requisitos. Las colecciones pueden usarse para proporcionar una forma sencilla de visualizar un agrupamiento de artefactos o requisitos.

Las colecciones agrupan una variedad de artefactos o de requisitos, o ambos, para revisiones dirigidas para determinadas partes interesadas, ya sea como una revisión formal o una informal. También pueden incluirse instantáneas dentro de una colección para ser revisadas.

Pueden ayudar a establecer una línea de base para un grupo de funcionalidad para una iteración determinada.

Pueden crearse diferentes ítems de un plan utilizando el cliente con texto enriquecido de Rational Team Concert, basándolos en los requisitos incluidos en una colección, y establecer enlaces desde los ítems del plan a los requisitos. Típicamente, ésta es una actividad realizada por el líder de un equipo o un gerente de proyecto.

Pueden crearse casos de prueba en grandes cantidades utilizando el cliente del IBM® Rational® Quality Manager a partir de requisitos incluidos en una colección, y establecer enlaces desde los casos de prueba a los requisitos. Típicamente, esto es realizado por un líder de ensayo.

Si bien el planeamiento de las colecciones puede comenzar desde el inicio del proyecto, las colecciones son creadas cuando los artefactos comienzan a tomar forma y el equipo está listo (o en preparación) para que los revisores los usen para revisiones informales o formales, enlazándose a planes de prueba o creando ítems de trabajo. Típicamente, éstos serían visualizados al hacerse clic en la pestaña Collections del panel de control del proyecto. También puede resultar útil crear una carpeta para las colecciones.
La Estrategia de Colaboración de Partes Interesadas puede incluir cualquier política acerca del uso de las colecciones.


El acceso a Vistas Rápidas (Fast Views) puede configurarse con un botón que típicamente está ubicado a la izquierda de la pantalla y también puede anclarse en la barra lateral de la derecha. Esto puede resultar especialmente útil para propiedades y las visualizaciones de contornos. Las visualizaciones de contornos son especialmente útiles para la edición de bosquejos de la UI (interfaz de usuario).

La Búsqueda Avanzada (Advanced Search) también puede usarse para buscar entre muchos proyectos.


Resumen

La Tabla 4 resume las diferentes técnicas para organizar el proyecto y el espacio del repositorio. La revisión y la aprobación se consideran con mayor detalle más adelante en la serie.

Tabla 4. Resumen de técnicas claves para organizar el proyecto y el espacio del repositorio
Tipo de organizaciónDescripción
Carpetas Las carpetas se utilizan para crear la estructura jerárquica fija de un proyecto y para crear el marco fundamental de un proyecto destinado a almacenar requisitos, artefactos y colecciones. Esto puede usarse junto con etiquetas.
Etiquetas Las etiquetas son una manera más informal de clasificar requisitos, colecciones y artefactos. Tienen la ventaja de poder operar entre carpetas y proyectos, así que resultan útiles para una amplia clasificación. También es posible etiquetar ítems en bloque.
Grupos de Atributos Los grupos de atributos proporcionan una estructura de clasificación más formal, que incluye nombres de atributos, valores y un valor predeterminado. Pueden aplicarse entre requisitos y artefactos, y también pueden asignarse a tipos de requisitos. Resultan útiles tanto para la administración de requisitos como para un mecanismo adicional de filtrado más formal.
Filtros Los filtros pueden usarse para visualizar varios artefactos o requisitos por carpeta, por etiqueta o por valores de los atributos.
Todos los metadatos de más arriba (carpetas, etiquetas y grupos de atributos) proveen la información entrante para los filtros, la cual permite a los usuarios encontrar y acceder a un subconjunto de los artefactos y requisitos relevantes del repositorio.
Colecciones Las colecciones se utilizan para agrupar artefactos y requisitos. Una pestaña de colecciones en el panel de control del proyecto proporciona una lista de las colecciones del proyecto. Éstas son útiles para varios propósitos, desde direccionar revisiones hasta integraciones C/ALM.
Instantáneas La instantánea de un proyecto es la captura de todo un proyecto en un momento específico. Incluye a todos los artefactos, árboles de carpetas y la lista de etiquetas compartidas.
Revisión y Aprobaciones Una revisión es un conjunto de artefactos que uno crea para ser revisados por miembros específicos del equipo. La revisión sigue un ciclo de vida que va cambiando a medida que los participantes completan la revisión.
Puede crearse una revisión para artefactos individuales que uno selecciona o puede crearse una revisión de una colección (ver Estrategia de Colaboración).

En definitiva, la decisión sobre cómo exactamente adoptar estas técnicas será determinada por equipos individuales. La filosofía subyacente de la adopción es que procediendo de esa manera se intensificará la colaboración con las partes interesadas por hacer que la información sea más fácil de hallar.

Este artículo consideró distintas maneras de organizar el proyecto y el espacio del repositorio. Sentó las bases para el siguiente artículo, en el cual se aborda la creación de contenidos. El siguiente artículo explica el método para seleccionar artefactos, crear artefactos y establecer enlaces.


Agradecimientos

Las autoras agradecen a Robin Bater, Arquitecto de Rational Requirements Definition y Management Community of Practice, y a Daniel Moul, Gerente de Market Management Offering para Requirements Definition and Management, por sus revisiones técnicas y su estímulo.


Descargar

DescripciónNombretamaño
Stakeholder_Collaboration_Strategy_template.docStakeholder_Collaboration_Strategy_template.zip105 KB

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Rational
ArticleID=966694
ArticleTitle=Utilización de la Estrategia de Colaboración de Partes Interesadas con Rational Requirements Composer: Parte 2. Organización del proyecto y espacio del repositorio
publish-date=01212011