Organizar los requisitos en un plan de producto
Después de analizar detenidamente los requisitos del cliente para poder determinar las características de un producto, es preciso elaborar un plan para implementar el producto. En el caso de un producto existente, hay que identificar la funcionalidad que falta y definir un plan para realizar las modificaciones. Sin embargo, los requisitos no conducen automáticamente al plan.
En este tema, se describe un método para elaborar un plan a partir de un conjunto de requisitos. Se trata simplemente de uno de los diversos métodos que se pueden usar en Visual Studio, por lo que cada uno tendrá que ajustarlo a sus necesidades.
En este tema
Requisitos y características
Desglose de los escenarios
Asignar escenarios hoja a las iteraciones
Características: requisitos que se cumplen en cada iteración
Características de calidad de servicio
Planeación del producto
Planeación de las iteraciones
Requisitos y características
En este método, hay dos tipos de requisitos: requisitos del cliente y características. Los requisitos del cliente representan lo que se obtiene tras analizar lo que el cliente espera del producto. Las características son los elementos del plan de producto, que corresponden a pequeños subconjuntos de los requisitos del cliente. Cada característica puede incluir partes de los requisitos del cliente que son fruto de la experiencia de los usuarios y que proceden de diferentes áreas funcionales.
Requisitos del cliente
Los requisitos del cliente se determinan hablando con los posibles usuarios y las demás partes interesadas.
Para poder analizar estos requisitos, normalmente se crean guiones gráficos y modelos y se desglosan los escenarios en pasos más pequeños que forman un árbol. Los elementos de los modelos, como casos de uso y actividades, se pueden vincular a los elementos de trabajo de los escenarios.
Hay dos tipos de requisitos del cliente:
Los escenarios, también denominados casos de uso, representan secuencias de interacciones entre los usuarios y el producto para lograr determinados objetivos. Un escenario de ejemplo podría denominarse "El usuario compra un libro".
Entre los requisitos referentes a la calidad de servicio se encuentran el rendimiento, la seguridad, la facilidad de uso y otros criterios.
Estos requisitos se pueden representar como elementos de trabajo de requisito, con el campo Tipo de requisito establecido en Escenario o Calidad de servicio.
Estos elementos de trabajo de requisito deben vincularse a las pruebas del sistema para garantizar que se han sometido a prueba todos los requisitos.
Se utiliza la consulta Requisitos del cliente para mostrar estos elementos de trabajo de requisito.
Se utiliza el informe Progreso de los requisitos para supervisar qué requisitos se han cumplido.
Para obtener más información, vea Implementar requisitos, Consultas de equipo (CMMI), Informe Progreso de los requisitos (CMMI) y Crear un plan de pruebas mediante requisitos o casos de usuario.
Características
Una característica es un elemento de un plan de producto que representa un grupo de tareas. En la fase de planeación del producto, los representantes del equipo de desarrollo y de las partes interesadas asignan las características a las iteraciones. Para obtener más información, vea Planear el proyecto (CMMI).
Las características se introducen como elementos de trabajo de requisito con el campo Tipo de requisito establecido en Característica.
El título de la característica indica lo que los usuarios podrán hacer con el producto con respecto a lo que les permitía hacer en las iteraciones anteriores. No hay ningún elemento, o muy pocos elementos, en el plan que no aporte ningún valor nuevo al usuario.
Por ejemplo, esta secuencia de características podría constituir un plan de implementación:
"Un comprador puede elegir un libro de una lista y agregarlo a una lista de deseos."
"En la lista de libros, se muestran los precios. En la lista de deseos, se muestra el precio total."
"Los proveedores pueden adjuntar etiquetas a los libros. Los compradores pueden filtrar la lista de libros por etiqueta."
Observe que ninguna característica toca solamente un paso en la experiencia del usuario, y ninguna característica implica solamente una parte de la arquitectura del producto. Cuando se implementan las características, se revisan varias funciones y se les agrega un nuevo valor para el usuario.
Una característica se asigna a una iteración durante la fase de planeación del producto. Todas las tareas correspondientes a una característica deben asignarse a la misma iteración. Para obtener más información, vea Planear el proyecto (CMMI).
Una característica describe un cumplimiento parcial de los requisitos del cliente. Es un subconjunto de los requisitos del cliente y podría implementar cada uno de dichos requisitos hasta cierto punto.
Cada característica puede vincularse a uno o varios casos de prueba que someten a prueba la parte de los requisitos que la característica representa. Estos casos de prueba son un subconjunto de las pruebas del sistema que están vinculadas a los requisitos del cliente.
El estado de la característica no debe marcarse como Completado hasta que se definan y se realicen correctamente las correspondientes pruebas.
Cada característica es un grupo de tareas de desarrollo y de prueba. Es la raíz de un árbol de tareas de Visual Studio Team Foundation Server. Las tareas de desarrollo implementan los requisitos parciales descritos por la característica. Las tareas de prueba diseñan y ejecutan los casos de prueba adecuados.
Se utiliza la consulta Requisitos del producto para mostrar las características. Para mostrar el plan del producto, haga clic en Opciones de columna y agregue Ruta de acceso de la iteración a la lista de columnas mostradas. Para ordenar por iteración, haga clic en la columna Ruta de acceso de la iteración. Para obtener más información, vea Consultas de equipo (CMMI).
Buscar características
La separación de los requisitos en características incrementales es una tarea creativa en la que se deben implicar los desarrolladores, analistas y partes interesadas. Una característica define una parte de la funcionalidad del producto que se puede implementar de manera independiente de las demás funciones. Por consiguiente, un conjunto factible de definiciones de característica y su inclusión ordenada en un plan dependen en parte de la arquitectura del sistema.
Por esta razón, es preciso que la planeación y el diseño inicial del producto se lleven a cabo en paralelo, sobre todo en la iteración 0, donde se elabora la mayor parte del plan.
Desglose de los escenarios
Para poder organizar los requisitos en características, se recomienda desglosar los escenarios en pasos más pequeños.
En muchas ocasiones, los guiones gráficos ayudan a realizar esta actividad. Un guión gráfico es una secuencia de imágenes que ilustran el escenario. Los diagramas de actividades de UML resultan útiles para mostrar rutas alternativas; los diagramas de secuencia de UML pueden ayudar a tratar las interacciones entre las diversas partes implicadas. Después de utilizar estas herramientas para analizar un escenario, se pueden registrar los escenarios desglosados en Team Explorer. De este modo, se vinculan los casos de prueba a los escenarios, por lo que se garantiza el cumplimiento de los requisitos. Para obtener más información, vea Diagramas de actividades UML: Instrucciones y Diagramas de secuencia de UML: Instrucciones.
En este breve tutorial, va a escribir un conjunto de requisitos del cliente como un pequeño árbol de escenarios. Esto proporcionará un ejemplo a partir del cual se van a crear características.
Para abrir el árbol de requisitos del cliente en Excel
En Team Explorer, abra un proyecto de MSF for CMMI Process Integration v5.0.
Expanda Elementos de trabajo, expanda Consultas del equipo, expanda Planeación y seguimiento y ejecute Requisitos del cliente.
Si no se muestran las columnas Ruta de acceso de la iteración y Tipo de requisitos, haga clic en Opciones de columna y agréguelas a la lista que columnas que se van a mostrar.
Quizás desee agregar también la columna Ruta de acceso del área.
Establezca la consulta de modo que se muestre un árbol.
Haga clic en Editar consulta.
Establezca Tipo de consulta en Árbol de elementos de trabajo.
Haga clic en Guardar consulta.
Si no puede guardar la consulta en Consultas del equipo, guárdela en Mis consultas.
Haga clic en Ver resultados para cerrar la vista de edición.
Haga clic en Abrir en Microsoft Office y, a continuación, haga clic en Abrir consulta en Microsoft Excel.
En Office Excel, si la columna Título 1 no va seguida de las columnas Título 2 y Título 3, haga clic en la pestaña Equipo y, a continuación, haga clic en Agregar nivel de árbol para crear las columnas adicionales.
Ya puede incluir los escenarios como un lote.
En la práctica, podrá comenzar por especificar un nivel de escenarios y, a continuación, desglosar cada escenario en pasos más pequeños de operaciones independientes.
Para escribir los escenarios
En la fila situada inmediatamente después de la última fila de los elementos de trabajo existentes (si los hay), escriba el título del escenario de nivel superior en la columna Título 1:
El cliente realiza el pedido de una comida.
Junto con las partes interesadas, va a determinar los principales pasos del escenario de nivel superior.
En las filas situadas inmediatamente después del escenario de nivel superior, escriba los pasos en la columna Título 2:
El cliente elige un restaurante.
El cliente elige platos del menú del restaurante para crear un pedido.
El cliente escribe los datos de pago.
El restaurante prepara y entrega el pedido.
Se carga el pago en la tarjeta del cliente.
Un análisis más profundo, quizás acompañado de diagramas de actividades y de interacción de UML, dará lugar a pasos más detallados para algunos de estos escenarios.
Inmediatamente debajo del paso El cliente elige un restaurante, inserte algunas filas y escriba esos pasos en la columna Título 3:
El cliente escribe el código postal de la dirección de entrega.
En el sitio web se muestra una lista de los restaurantes que realizan entregas a esa dirección.
El cliente puede examinar el menú de todos los restaurante mostrados.
El cliente selecciona un restaurante para iniciar el pedido.
Se eliminan las filas en blanco.
En la columna Tipo de elemento de trabajo de todas las filas nuevas, establezca el tipo en Requisito.
Establezca la columna Tipo de requisito de todas las filas nuevas en Escenario.
Para publicar los requisitos en Team Foundation Server, seleccione cualquier celda de la tabla de elementos de trabajo y, a continuación, haga clic en la opción Publicar de la pestaña Equipo.
Ya dispone de un árbol con los requisitos del cliente, que podrá modificar en Office Excel o en Team Explorer.
Asignar escenarios hoja a las iteraciones
Los escenarios "hoja" son los que no tienen elementos secundarios propios.
Para asignar los pasos más básicos de los escenarios a las iteraciones, se establece el campo Ruta de acceso de la iteración. Esto se puede realizar en la vista de Office Excel.
A continuación, se asigna cada escenario con elementos secundarios a la iteración más temprana en la que se pueda utilizar.
En el siguiente ejemplo, los escenarios más esenciales se implementan en las iteraciones 1 y 2, y las demás funciones se agregan en iteraciones posteriores.
Iteración 2: el cliente elige un restaurante.
Iteración 5: el cliente escribe el código postal.
Iteración 2: DinnerNow muestra una lista de restaurantes.
Iteración 3: el cliente puede examinar el menú de cada restaurante.
Iteración 2: el cliente selecciona un restaurante para crear un pedido.
Iteración 1: el cliente elige platos del menú para crear un pedido.
Iteración 1: el cliente hace clic en un plato para agregarlo al pedido.
Iteración 2: en el resumen del pedido, se muestra el precio total.
Iteración 1: el cliente hace clic en "Confirmar" para completar el pedido.
Iteración 4: el cliente escribe los datos de pago.
Iteración 2: el restaurante prepara y entrega el pedido.
Iteración 4: se carga el pago en la tarjeta del cliente.
Estas asignaciones permiten hacer uso del diseño global del sistema en una fase temprana pero deja muchos detalles para después. Algunos aspectos considerados de bajo riesgo pueden dejarse para iteraciones posteriores. En este ejemplo, el equipo tiene experiencia con la vinculación a un sistema de pago por tarjeta. Por ello, deja esa parte para una iteración posterior.
En algunos casos, es posible que se opte por desglosar aún más los escenarios hoja a fin de separar las versiones simplificadas y más complejas en diferentes iteraciones, tal y como se muestra en la siguiente imagen.
.png "Árbol de elementos de trabajo de escenario")
Características: requisitos que se cumplen en cada iteración
Una característica es un requisito que resume lo que los usuarios pueden hacer al término de cada iteración. Se puede crear más de una característica para cada iteración. Las características se representan como elementos de trabajo de requisito con el campo Tipo de requisito establecido en Característica.
Las asignaciones de los escenarios a los elementos de trabajo ayudan a definir las características. El siguiente plan de características de ejemplo se deriva de las asignaciones de los escenarios a las iteraciones que se han realizado en la sección anterior:
Iteración 1
- El cliente elige platos de un menú, los agrega a un pedido y agrega una dirección de entrega.
Iteración 2
El cliente muestra primero una lista de restaurantes y, a continuación, elige uno.
Cuando el cliente completa un pedido, dicho pedido aparece en la pantalla del restaurante elegido.
En el pedido, se muestran los precios de los platos así como el precio total.
Iteración 3
El restaurante marca el pedido como "Listo" una vez enviada la comida preparada. Se registra la comida en el restaurante.
Cada restaurante puede escribir y actualizar su menú.
El cliente puede examinar el menú de cada restaurante antes de realizar una selección.
Iteración 4
El cliente escribe los datos de pago cuando completa el pedido. Se pasa el cargo a la tarjeta del cliente cuando el restaurante marca el pedido como Listo.
Se paga al restaurante por los pedidos marcados como Listo.
Iteración 5
- Los restaurantes pueden definir su área de entrega. El cliente escribe su código postal cuando inicia sesión. En el sitio web se muestran únicamente los restaurantes que pueden realizar entregas en el área local.
Escenarios parcialmente implementados
Desglosar los escenarios en pasos más pequeños ayuda a separar los pasos que se pueden implementar antes de los pasos que se pueden implementar más adelante.
Sin embargo, a veces también permite separar otros aspectos de los escenarios. En este ejemplo, el equipo podría implementar una versión básica de la experiencia del usuario en las primeras iteraciones y mejorarla posteriormente. Por lo tanto, se podría agregar la siguiente característica:
- Iteración 6: el restaurante puede elegir la combinación de colores y la fuente de su menú y puede cargar su logotipo así como imágenes de las comidas.
Este tipo de característica no es un resultado directo del desglose en pasos sino que suele surgir a raíz de las conversaciones que se mantienen sobre los guiones gráficos. Las características relacionadas con la experiencia del usuario se prestan especialmente para las iteraciones posteriores.
Escribir e inspeccionar las características
Cree elementos de trabajo de requisito y establezca el campo Tipo de requisito en Característica. Escriba una breve descripción en el campo Título de la característica.
Para escribir las características en un lote y abordar su asignación a las iteraciones, adapte la consulta Requisitos del producto y utilice una vista de Office Excel.
Para escribir y modificar las características
En Team Explorer, abra un proyecto de MSF for CMMI Process Improvement v5.0.
Expanda Elementos de trabajo, expanda Consultas del equipo, expanda Planeación y seguimiento y abra Requisitos del producto.
Haga clic en Opciones de columna y, a continuación, agregue Estimación original y Ruta de acceso de la iteración a la lista de columnas mostradas.
Haga clic en Abrir en Microsoft Office y, a continuación, haga clic en Abrir consulta en Microsoft Excel.
En el cuadro de diálogo en el que se pregunta si desea guardar la consulta, haga clic en Sí.
(Opcional) En Office Excel, escriba la lista de títulos de característica, establece las rutas de acceso de las iteraciones y ordena las filas por ruta de acceso de iteración.
Para guardar los cambios en Team Foundation Server, haga clic en cualquier celda de la tabla de elementos de trabajo y, a continuación, haga clic en la opción Publicar de la pestaña Equipo.
Vincular las características a los requisitos
Las características se pueden vincular a los requisitos de las siguientes maneras:
Vinculando los elementos de trabajo de característica a los requisitos de escenario hoja de sus iteraciones. Es preciso vincularlos mediante los vínculos Elementos relacionados porque los escenarios hoja ya tienen elementos primarios.
Vinculando los elementos de trabajo de caso de prueba a los escenarios y los requisitos en materia de calidad de servicio que someten a prueba. Las características deben vincularse al subconjunto de los casos de prueba que deben superarse una vez desarrollada la característica. De esta manera, los casos de prueba actúan como vínculo entre las características y los requisitos del cliente.
Características de calidad de servicio
Los requisitos de calidad de servicio suelen ser ubicuos con respecto al diseño del software. Por ejemplo, los requisitos de seguridad no suelen estar relacionados con una tarea de desarrollo concreta.
No obstante, para cada requisito de calidad de servicio, se debe crear un elemento de trabajo de característica cuyos elementos secundarios sean principalmente tareas de prueba que garantizan el cumplimiento de un criterio de calidad de servicio. Estos elementos de trabajo se denominan características de calidad de servicio.
Algunas de estas características pueden tener tareas de desarrollo. Por ejemplo, en una iteración temprana, se podrá implementar una versión del sistema que sea capaz de administrar solo unos pocos usuarios, como una prueba de concepto. En una iteración posterior, se podrá agregar una característica que especifique la capacidad de destino indicada en los requisitos del cliente.
Planeación del producto
Antes de iniciar cada iteración, se debe celebrar una reunión para revisar el plan del producto. En la primera reunión para planear el producto, se crea el plan y, en las reuniones subsiguientes, se revisa dicho plan en función de las iteraciones anteriores. Para obtener más información, vea Planear el proyecto (CMMI).
Cuando se revisa el plan del producto, se debe hablar de las características con las partes interesadas y, si es necesario, cambiar su prioridad y organizarlas en iteraciones diferentes. A la reunión deben asistir las partes interesadas y los representantes del equipo de desarrollo.
En la reunión, se debe abordar la secuencia en la que se van a desarrollar las características. Para ello, se puede proyectar o compartir la pantalla de la vista en Office Excel de la consulta Requisitos del producto y ordenar las características por iteración.
También se puede optar por colocar las características en una secuencia concreta y, a continuación, considerar cuánto se puede hacer en cada iteración. Por ejemplo, los desarrolladores podrían hablar de la posibilidad de mover el paso "El cliente puede mostrar los precios" de la iteración 2 a la iteración 3, sin moverlo en la secuencia. Para colocar los elementos en una secuencia, se debe agregar a la hoja de cálculo una columna adicional denominada Rango e insertar enteros que denoten la secuencia. A continuación, se debe ordenar la hoja de cálculo por esta columna. Los rangos no se almacenarán en Team Foundation Server, pero se puede guardar la hoja de cálculo. Cuando se vuelve a abrir la hoja de cálculo, se debe hacer clic en cualquier celda de la tabla de elementos de trabajo y, a continuación, hacer clic en la opción Actualizar de la pestaña Equipo.
En la fase de planeación del producto, se consideran las prioridades de las características y los costos de desarrollo. Las prioridades las indican las partes interesadas y los desarrolladores aportan algunos datos sobre los riesgos. Las estimaciones de los costos las aportan los desarrolladores. Para hacerse una idea exacta de los costos, el equipo de desarrollo ya debe haber trabajado sobre la arquitectura del producto y seguramente necesitará la información que aportan las primeras iteraciones. Por esta razón, las estimaciones de los costos deben ajustarse cada vez que se revisa el plan del producto.
Planeación de las iteraciones
Después de revisar el plan del producto, se debe planear la iteración. El plan del producto determina las características que se entregarán al término de la iteración. El plan de iteración determina el trabajo que el equipo llevará a cabo para implementar y probar las características.
Las siguientes actividades forman parte de la planeación de las iteraciones:
Crear tareas para el desarrollo y las pruebas, y vincularlas como elementos secundarios a los requisitos en materia de características.
Crear casos de prueba para los aspectos de los requisitos del cliente que deben desarrollarse en cada característica. Los casos de prueba deben vincularse a los requisitos del cliente para que se pueda supervisar el grado en que se cumplen dichos requisitos.
Los casos de prueba también se pueden vincular a las características para que se pueda realizar un seguimiento de la correspondencia entre las características y los requisitos. Las características no deben marcarse como completadas hasta que se ejecuten correctamente los casos de prueba vinculados.
Para obtener más información, vea Planear una iteración (CMMI).