Uso de MatCal para realizar cálculos matemáticos y lógicos en la gestión moderna de requisitos

Uso de MatCal para realizar cálculos matemáticos y lógicos en la gestión moderna de requisitos

¿Qué es MatCal?

MatCal es una función de Modern Requirement4DevOps que se utiliza para realizar expresiones matemáticas y lógicas en elementos de trabajo.

Por qué necesitamos MatCal en la gestión de requisitos

¡Para gestionar las relaciones entre las propiedades de los elementos de trabajo de una forma más inteligente! Elimina el trabajo manual que supone realizar los cálculos fuera del entorno del proyecto y evita el riesgo de introducir resultados incorrectos en tus proyectos.

Veamos un ejemplo sencillo para ilustrar la relación entre las propiedades de un elemento de trabajo.

El valor empresarial y la prioridad son propiedades de la característica de un elemento de trabajo. Normalmente, un valor empresarial alto conlleva una prioridad alta.

Con la configuración adecuada, MatCal podría ayudarte a gestionar la relación asignando automáticamente un valor de prioridad en función del valor empresarial introducido.

Casos de uso en el sector

Escenario 1: Nivel de integridad de seguridad en automoción (ASIL) según la norma ISO 26262

Escenario 2: La calificación de riesgo se asigna automáticamente en función de la puntuación de gravedad y la puntuación de frecuencia

Escenario 3: La clasificación de prioridad se asigna automáticamente en función de la puntuación de gravedad y la puntuación de probabilidad

¡No te pierdas el vídeo para ver más ejemplos de uso y tutoriales sobre MatCal!

Tiempo de lectura: 10 minutos

Importación de requisitos a Azure DevOps

Importación de requisitos a Azure DevOps

Descubre cómo importar fácilmente requisitos (y algunos recursos) a tu proyecto ADO

Al migrar a Azure DevOps, o cuando trabajas sin conexión lejos de tu proyecto actual de Azure DevOps, necesitas una forma de importar los requisitos que acabas de crear a Azure DevOps.

Muchos equipos se enfrentan al problema de cómo incorporar a Azure DevOps los requisitos que han creado en Excel, Word y otras aplicaciones. Por suerte, hay varias formas sencillas de hacerlo sin tener que preocuparse por añadir una larga sesión de copiar y pegar a tu proceso. 

En este artículo, veremos varias formas de importar requisitos.

Una de estas opciones es gratuita, y otras son funciones que se obtienen al añadir Modern Requirements4DevOps a tu proyecto de Azure DevOps. 

Los temas que se tratan en este artículo son los siguientes:

  1. Requisitos para importar desde Microsoft Excel
  2. Requisitos para importar desde Microsoft Word
  3. Importación de diagramas y maquetas a Azure DevOps

Requisitos para importar desde Microsoft Excel

Tanto si tienes todos o algunos de tus requisitos actuales en Excel, como si deseas exportar requisitos desde una herramienta interna a un archivo .csv, existe una forma gratuita de importar tus requisitos a tu proyecto de Azure DevOps. 

Esta es una solución gratuita, siempre y cuando ya dispongas de Azure DevOps y Excel.

El primer paso es asegurarte de que tienes instalado el complemento de Microsoft Excel llamado «Team tab».

Puedes descargar este complemento directamente desde aquí:

(En la página mencionada, Azure DevOps Office® Integration 2019 aparece en la sección «Otras herramientas, marcos y componentes redistribuibles»).

Si has hecho clic en el enlace anterior, podrás activar la pestaña «Equipo» de Excel. 

Cuando está habilitada, esta extensión te permite vincular una hoja de Excel directamente a un proyecto concreto de tu organización de Azure DevOps. 

Al habilitar esta función, tendrás a tu disposición dos funciones principales:
1) Podrás publicar requisitos entu proyecto desde Excel
2) Podrás exportar requisitos detu proyecto aExcel

Esto significa que puedes trabajar en tus requisitos desde cualquiera de las dos interfaces y aplicar los cambios a tu proyecto. Es decir, si importas los requisitos a Excel y realizas cambios, puedes publicar esos cambios y aplicarlos a los requisitos de tu proyecto. 

Una vez que hayas ejecutado el instalador que has descargado, ya podrás activar la extensión.

Cómo activar la pestaña «Equipo»en Excel:

  1. Abrir Excel
  2. Crear una hoja en blanco 
  3. Haz clic en «Archivo»
  4. Haz clic en «Opciones»
  5. Haz clic en «Complementos»
  6. Selecciona «Complementos COM» en el menú desplegable situado en la parte inferior de la ventana
  7. Selecciona «Team Foundation Add-In» y haz clic en Aceptar. 
Si tienes algún problema con este proceso, haz clic en este enlace.
 
Si ahora ves la pestaña «Equipo» en Excel, ¡ya estás listo para importar los requisitos! 

Uso de la pestaña «Equipo» de Excel

En este vídeo, explicamos cómo tu equipo puede utilizar las funciones de importación que ofrece el complemento de la pestaña «Equipo» de Excel.

Requisitos para importar desde Microsoft Word

La segunda forma de importar requisitos a tu proyecto es a través de Microsoft Word. 

Esta función es una «función de vista previa» disponible con cualquier licencia Enterprise Plus de Modern Requirements4DevOps. Esto significa que cualquier usuario de su organización que cuente con una licencia Enterprise Plus podrá acceder a la función de importación de Word y utilizarla. 

Si aún no utilizas Modern Requirements4DevOps, ¡prueba hoy mismo esta función de importación de Word!

¡Pruébalo!

¿Cómo funciona la importación de Word? 

Advertencia: al tratarse de una función en fase de prueba, es posible que esta no sea la solución más elegante y que, por lo general, requiera algunos conocimientos de programación. Pero no muchos: si puedes pedirle ayuda a un desarrollador que conozca XML (o cualquier otro lenguaje de scripting) durante unos 20 minutos, no deberías tener ningún problema.

La importación de Word funciona a partir de un documento de Word bien formateado que utiliza diferentes encabezados para representar los distintos elementos de trabajo o requisitos y sus propiedades en el documento. 

Por ejemplo, tomemos como ejemplo un documento de requisitos de negocio (BRD) que quizá ya tengas en formato Word.

Probablemente hayas aplicado el estilo «Título 1» a la introducción, la descripción general, el alcance y otros elementos contextuales. 

También podrías incluir en este documento tus épicas, funcionalidades e historias de usuario.Tu documento podría tener este aspecto:

Título 1 – Introducción
-> Párrafo –Aquí va todo el texto de la Introducción…

Título 1 – Resumen
-> Párrafo –Aquí va todo el texto del resumen…

Título 1 – Ámbito de aplicación

-> Párrafo –Aquí va todo el texto del ámbito de aplicación…

Título 1 – Requisitos
-> Título 2 – Nombre de la épica
–> Título 3 – Nombre de la funcionalidad
—> Título 4 – Nombre de la historia de usuario
—-> Párrafo – Descripción de la historia de usuario anterior

Es posible que tu documento sea un poco diferente, pero no pasa nada.Los principios que estás a punto de aprender son los mismos. 

La importación de Word requiere un documento (como se muestra arriba) y un conjunto de reglas (que se explica a continuación).

Por lo general, un administrador creará un conjunto de reglas que tu equipo utilizará para importar documentos, y solo habrá que hacerlo una vez.Así que, si ya tienes un documento creado y tu administrador ha creado un conjunto de reglas, ya estás listo para empezar. 

Si tu administrador necesita crear un conjunto de reglas, sigue leyendo. 

Crear un conjunto de reglas es increíblemente sencillo y se hace editando un archivo XML.
El archivo XML que crees determinará cómo la herramienta de importación de Word analiza tu documento para:
1) ¿Qué partes del documento son elementos de trabajo?
2) ¿Qué partes del documento son propiedades de un elemento de trabajo determinado?

Si estás trabajando en esto en tiempo real, te puede resultar útil descargar este archivo de reglas como punto de partida y ver el siguiente vídeo:

Cómo empezar con el conjunto de reglas de ejemplo

En este vídeo, explicamos cómo utilizar el archivo de conjunto de reglas de ejemplo para importar un documento de requisitos sencillo. Recuerda que la creación de un conjunto de reglas suele ser un proceso que solo hay que realizar una vez. 

Importación de diagramas y maquetas a Azure DevOps

Los diagramas, las maquetas y los modelos de casos de uso pueden ser herramientas muy útiles para definir y recabar requisitos. 

Por eso, con Modern Requirements4DevOps, tu equipo puede crear fácilmente todas estas visualizaciones directamente desde tu proyecto. Esto te permite beneficiarte de un modelo de «fuente única de verdad» en el que todo está integrado en tu proyecto. 

Pero quizá ya tengas diagramas y maquetas que te gustaría añadir a tu proyecto de Azure DevOps y vincular a los requisitos. ¿Es posible importar estos recursos?

La respuesta es sí.

Tanto nuestra herramienta de maquetas como nuestra herramienta de diagramas te permitirán incorporar fácilmente maquetas o diagramas existentes a tu proyecto de Azure DevOps. 

Para ello, solo tienes que guardar el recurso como un archivo .png o .jpeg desde la herramienta de maquetas o diagramas que hayas elegido.
A continuación, puedes subir el recurso creado a la herramienta de simulación de Modern Requirements4DevOps (maquetas)o ala herramienta de diagramas (diagramas). 

Quizá te preguntes: «Pero si lo subimos como .png o .jpeg, ¿cómo podremos editar nuestros diagramas y maquetas?». Pues bien, no podrás. Pero hay una razón por la que deberías hacerlo de todos modos. 

Si quieres vincular un único diagrama a 25 requisitos sin utilizar Modern Requirements, tendrás que abrir los 25 requisitos y vincularlos a cada uno de ellos por separado. 

Cuando actualices tu diagrama en el futuro, tendrás que volver a abrir los 25 requisitos y cambiar el archivo adjunto. 

Sin embargo, con Modern Requirements4DevOps, puedes crear un elemento de trabajo de diagrama al que vincular directamente todos los requisitos necesarios mediante el panel de la derecha. Esto significa que podrás tener tu diagrama en un solo lugar y, cuando sea necesario actualizarlo, podrás añadir fácilmente la imagen actualizada y vincular el archivo adjunto a ese único elemento de trabajo. 

Conclusión

En este artículo hemos explicado tres formas distintas de importar tanto los requisitos como sus activos a tu proyecto de Azure DevOps. 

Puedes importar requisitos a través de Excel o Word, o importar tus diagramas y maquetas existentes. 

Si te interesa utilizar Modern Requirements4DevOps para optimizar tu proceso de gestión de requisitos, ¡prueba nuestro producto aquí!

Tiempo de lectura: 10 minutos

Requisitos modernos 2019: Actualización 2

Notas de la versión

Modern Requirements4DevOps 2019 - Actualización 2

¡Bienvenidos a la actualización 2 de Modern Requirements4DevOps 2019! En esta versión se han incorporado numerosas mejoras y novedades. A continuación se incluye una versión comentada de las notas de la versión para guiar a los usuarios en la actualización a Modern Requirements4DevOps. 

General

Se ha añadido una herramienta totalmente nueva a Modern Requirements para ayudarte con tus necesidades de trazabilidad y gestión de proyectos. ¡La herramienta MR Artifact!

Se puede acceder a la herramienta «MR Artifact Tool» desde el menú contextual de cualquier elemento de trabajo. ¡Esta herramienta muestra todos los artefactos de Modern Requirements asociados a ese elemento de trabajo! Ahora los usuarios pueden ver rápidamente qué artefactos de Modern Requirements utilizan el elemento de trabajo seleccionado.  

Actualmente, esta herramienta permite realizar un seguimiento de los elementos de trabajo que se incluyen en los Smart Docs, las revisiones y las líneas de base.

La herramienta «Compare», que se utiliza para realizar comparaciones directas entre revisiones de elementos de trabajo, ¡ha sido revisada, a falta de un término mejor!

Los ID de revisión ahora se distinguen aún más gracias a nuevas propiedades. Las nuevas propiedades son «Última aprobación » y «Última revisión». Estas propiedades se aplicarán a las revisiones de los elementos de trabajo que hayan sido revisados durante su ciclo de vida.

Estas propiedades aparecerán junto al ID de revisión en el menú desplegable de la herramienta de comparación.

Al utilizar la herramienta de comparación, esta mostrará automáticamente una revisión predeterminada en el menú desplegable. Al abrir el menú desplegable, los elementos de trabajo «Última aprobación» y «Última revisión» aparecerán, respectivamente, en la parte superior de la lista. A continuación, se mostrarán el resto de revisiones en orden descendente (de más reciente a más antigua). 

Cuando se abre la herramienta de comparación, el menú desplegable de la izquierda siempre mostrará la revisión correspondiente del elemento de trabajo. Si se abre desde el backlog, este campo se rellenará con la última revisión. Si se abre desde una revisión, este campo mostrará por defecto la revisión del elemento de trabajo que se incluyó en dicha revisión. Si se accede a ella desde una línea de base, este campo mostrará la revisión del elemento de trabajo tal y como estaba en el momento en que se creó la línea de base.

El menú desplegable de la derecha es el campo de comparación de revisiones. Si el elemento de trabajo ha sido objeto de una revisión, este campo mostrará por defecto la última revisión aprobada.

Si no existe ninguna revisión aprobada, este campo mostrará por defecto la última revisión revisada.

Si el menú desplegable de la izquierda muestra por defecto la última revisión aprobada de un elemento de trabajo, el menú desplegable de la derecha permanecerá vacío.

Se puede acceder a la herramienta de comparación desde un elemento de trabajo recién creado. Sin embargo, si no hay revisiones, el menú desplegable de la derecha volverá a estar vacío.

Al abrir la herramienta «Comparar» desde la pestaña «Comparar líneas de base », la herramienta funciona de forma diferente. La comparación ya no es automática, ya que el usuario compara manualmente el elemento de trabajo entre dos líneas de base. En su lugar, los menús desplegables de la herramienta mostrarán de forma predeterminada la revisión del elemento de trabajo incluida en cada línea de base comparada.

Al utilizar la herramienta de comparación, el usuario puede interactuar con cualquiera de los menús desplegables y realizar cualquier comparación entre revisiones.

Documentos inteligentes

Smart Docs ha ampliado sus funcionalidades con la incorporación de tres nuevas funciones…

¡Los elementos secundarios creados en Smart Docs ahora pueden heredar automáticamente las propiedades de su elemento principal!

El Diseñador de plantillas meta de Smart Docs permite ahora a los usuarios configurar elementos de trabajo con campos heredables. Al crear un elemento de trabajo secundario o subordinado sobre la marcha a partir de un nodo principal, los valores de los campos configurados se pueden heredar del nodo principal. Esta regla no se aplica al insertar elementos de trabajo ya existentes.  

Smart Editor también ha incorporado una nueva función con campos de solo lectura.

En la plantilla del proceso se pueden definir campos concretos como de solo lectura. Smart Editor también tratará estos campos como de solo lectura.

Requisitos actuales: la interacción de las partes interesadas con Smart Docs ha mejorado aún más gracias a la introducción de la opción de abrir elementos de trabajo. Antes, las partes interesadas no podían abrir elementos de trabajo, ¡pero ahora sí pueden!

Cuando esta opción esté activada, las partes interesadas invitadas al proyecto podrán abrir elementos en el editor estándar de Azure DevOps.

Los usuarios pueden acceder a esta función desde las pestañas «Documento » y «Comparar » de Smart Docs.

Se han introducido mejoras adicionales en las funciones actuales del módulo Smart Docs.

El Diseñador de plantillas meta ofrece ahora a los usuarios la posibilidad de actualizar las plantillas de documentos guardadas. Anteriormente, esta función solo se aplicaba a las plantillas meta; ¡ahora también se pueden actualizar las plantillas de documentos!

Esto permite a los usuarios realizar modificaciones sobre la marcha en cualquiera de sus plantillas de documentos.

Las funciones incluyen:

  • Modificar la jerarquía de elementos de trabajo
  • Cambiar el nombre de las plantillas
  • Eliminar plantillas
  • Clonar plantillas; crear una versión única de la plantilla para editarla

Los cambios realizados en las plantillas de documentos se pueden aplicar a todos los Smart Docs que utilicen dicha plantilla. Una vez realizados los cambios, el usuario solo tiene que utilizar la función «Actualizar todas las plantillas» de la barra de herramientas de Smart Docs.

Se ha introducido un cambio importante en el diseño de Smart Docs.

En Smart Docs se ha mejorado tanto el ajuste de texto como el de imágenes, ya que ahora todos los datos incluidos se ajustarán correctamente a la línea siguiente.

Se trata de un cambio puramente estético. No obstante, este cambio debería mejorar considerablemente la legibilidad y la forma en que el usuario perciba visualmente el documento resultante.

Los títulos, los campos HTML, las imágenes de gran tamaño y las tablas de Smart Docs se beneficiarán de esta mejora.  

Gestión de reseñas

También se han incorporado algunas mejoras muy útiles al módulo de gestión de reseñas.

Como iniciador de una revisión, ahora podrás enviar comentarios sin necesidad de ser revisor; un iniciador de revisión es revisor por defecto.

Se han añadido dos nuevos tipos de informes de auditoría al módulo de gestión de revisiones.

Informe de auditoría de aprobación:

El informe incluye todos los detalles de las acciones de aprobación aplicadas a las tareas de la revisión

  • Entre los detalles se incluirá si una tarea ha sido aprobada o rechazada y por qué perfil de usuario, el comentario de respuesta, la acción de revisión, los comentarios adicionales y las tareas vinculadas añadidas.

Informe de resultados de la revisión:

El informe incluye todos los detalles de las acciones de revisión aplicadas a los elementos de trabajo en la revisión

  • Entre los detalles se incluirá si un elemento de trabajo ha sido revisado y por qué perfil de usuario, el comentario de respuesta, la acción de revisión, los comentarios adicionales y los elementos de trabajo vinculados que se hayan añadido.

Cabe señalar que el actual «Informe de auditoría de revisión » pasará a denominarse «Informe de auditoría heredado».

 Los usuarios siguen teniendo acceso a la opción «Informe de auditoría heredado».

El módulo de gestión de revisiones ha incorporado varias mejoras en sus funciones principales.

Se ha renovado por completo la forma en que Modern Requirements gestiona los metadatos de las revisiones. Al crear una revisión, los metadatos correspondientes se guardarán ahora en tu repositorio (control de código fuente).

Los metadatos de la revisión se almacenaban anteriormente en el campo HTML de un elemento de trabajo de «Solicitud de comentarios ».

La actualización 2 también ha introducido cambios en el proceso operativo de la gestión de revisiones.

El proceso anterior de creación de revisiones era lento y generaba muchos enlaces; se creaban tres enlaces por cada elemento de trabajo incluido en una revisión.

En la Actualización 2, cuando se cree una revisión, ya no se crearán vínculos entre las solicitudes de comentarios y los elementos de trabajo incluidos en la revisión.  

Además, el sistema ya no creará una tarea de respuesta a los comentarios cuando un usuario envíe una respuesta a una revisión (aprobación/envío de la revisión).

El nuevo proceso es más eficiente y no utiliza enlaces, lo que permite sortear la restricción de Azure DevOps de 1000 enlaces por elemento de trabajo.  

Además, se ha mejorado la automatización a la hora de realizar acciones habituales en las revisiones.

Al utilizar la función «Vincular elemento de trabajo » para vincular un elemento de trabajo a una aprobación o un rechazo, el vínculo se establecerá directamente con el elemento de trabajo que el usuario esté revisando en ese momento.

Los comentarios introducidos en la pestaña «Detalles» se añadirán automáticamente al elemento de trabajo «Solicitud de comentarios», junto con la información del perfil de la persona que los ha publicado.

Una vez finalizada la revisión, se añadirá un comentario a la tarea «Solicitud de comentarios», junto con la información del perfil del participante.

Una vez cerradas las revisiones, no se pueden realizar más acciones relacionadas con la aprobación y los comentarios. Esto impedirá que las partes interesadas en la revisión puedan añadir comentarios adicionales o vincular elementos de trabajo a la revisión cerrada.

También se han realizado cambios para actualizar la interfaz de usuario del formulario emergente de solicitud de revisión.

  • Al iniciar una revisión desde Smart Docs, ya no se mostrará la sección de elementos de trabajo
  • Al previsualizar una revisión, ya no se mostrará la lista de elementos de trabajo seleccionados
  • El cuerpo de un correo electrónico generado durante una revisión ya no incluirá la lista de elementos de trabajo seleccionados

Línea de base

El módulo Baseline ha mejorado sus capacidades con la incorporación de nuevas funciones para facilitar el seguimiento y la gestión de tus elementos de trabajo.

Al comparar líneas de referencia, los usuarios ahora pueden configurar qué tipos de enlace concretos activan un indicador de cambio. Anteriormente, los usuarios solo tenían la opción de desactivar el indicador o aplicarlo a todos los tipos de enlace. Esta configuración se encuentra en el panel de administración.

Se han mejorado los informes de diferencias para que solo muestren los campos que se han configurado como desencadenantes de los indicadores de cambio. Anteriormente, la interfaz de usuario de la herramienta de comparación y los informes de diferencias no estaban sincronizados.

Con la incorporación del seguimiento de los cambios en los tipos de enlace entre versiones de referencia, los informes de diferencias incluirán la posibilidad de informar sobre dichos cambios. 

La herramienta «Copy/Reuse Baseline » también ha visto mejoradas algunas de sus funciones.

El sistema copiará automáticamente la ruta de área/iteración del proyecto de origen y la asignará a los elementos de trabajo copiados si existen valores idénticos en el proyecto de destino.

Como se ve en este ejemplo, al copiar el elemento de trabajo, la ruta de iteración de este se copia del proyecto de origen y se establece en el de destino.

Informe inteligente

Al igual que en versiones anteriores de la herramienta Smart Report, los usuarios pueden cargar y aplicar plantillas de Word a sus informes. La actualización 2 introduce la posibilidad de heredar el estilo de Word cuando los informes Smart Report se exportan a Microsoft Word y se aplica una plantilla de Word.

A partir de la plantilla, Smart Reports heredará el estilo de los encabezados, el tamaño de la fuente, el texto subrayado o en negrita, el color de la fuente, la sangría y la alineación.

Esta opción se encuentra en el menú desplegable «Hoja de estilo».

Panel de administración

También se han introducido mejoras en el tratamiento de los datos de Modern Requirements.

Los datos de Modern Requirements se sincronizarán ahora automáticamente con el control de código fuente de Azure DevOps Server (TFS) para las implementaciones de compilación con inicio de sesión único.

Para utilizar esta función, añade las credenciales de un usuario con privilegios a nivel de colección en la pestaña «General» del panel de administración de Modern Requirement4DevOps.

Si no se han introducido las credenciales, se mostrará un mensaje de aviso al usuario.

Los datos de Modern Requirements se sincronizarán tanto con GIT como con el control de versiones de Team Foundation.

Escalabilidad

Modern Requirements es consciente de que los proyectos de nuestros clientes crecerán, y de que su software de gestión de requisitos debe crecer con ellos.

Se ha optimizado considerablemente el rendimiento del rendimiento de Modern Requirements4DevOps. La actualización 2 introduce la capacidad de gestionar grandes conjuntos de datos en módulos con un elevado volumen de elementos de trabajo. Se ha añadido compatibilidad con grandes volúmenes de datos a las funciones de gestión de revisiones, líneas de base e informes inteligentes.

Ahora es posible crear revisiones e informes inteligentes con un máximo de 10 000 elementos de trabajo.

Ahora los usuarios pueden crear líneas de base que incluyan hasta 100 000 elementos de trabajo.  

Entre las mejoras adicionales en el rendimiento de las funciones de Baseline se incluyen:

Copiar elementos de trabajo

  • 5.000 elementos de trabajo en Azure DevOps Server
  • 2.000 elementos de trabajo en Azure DevOps Service

Informes de diferencias

  • 10 000 elementos de trabajo en Azure DevOps Server
  • 3.000 elementos de trabajo en Azure DevOps Service

Reversión de elementos de trabajo

  • Puede realizar esta operación en 10 000 elementos de trabajo

Realizar operaciones con grandes conjuntos de datos puede llevar mucho tiempo en ocasiones. Modern Requirements es consciente de que su tiempo es valioso y ya ha implementado funciones para mejorar la eficiencia.

Las operaciones que requieren mucho tiempo ya no te ralentizan. Ahora se ejecutan en segundo plano y ofrecen a los usuarios la opción de recibir una notificación por correo electrónico cuando finalizan.

Esta función se ha integrado en el módulo de gestión de revisiones y está disponible al utilizar la función «Aprobar/Rechazar todo» en conjuntos grandes de elementos de trabajo. El sistema detectará automáticamente cuándo la operación va a tardar más de un minuto y lo notificará al usuario.

Esta función también es compatible con Smart Report. Si la generación del Smart Report no se produce de forma inmediata, se iniciará un proceso en segundo plano. En lo que respecta a Smart Report, los correos electrónicos de notificación incluirán enlaces que permiten al usuario guardar el informe generado en formato Word o PDF.

Corrección de errores

La funcionalidad y la experiencia del usuario son elementos fundamentales de la filosofía de diseño de Modern Requirements.

Con el lanzamiento de la Actualización 2 se han solucionado varios errores. Consulta aquí la lista completa de correcciones de errores o lee las notas de la versión.

Creación de plantillas de requisitos no funcionales

Aprobación de los requisitos por parte del cliente en Azure DevOps

Creación de plantillas de requisitos no funcionales

ERecopilación, redacción y gestión de requisitos no funcionales (NFR)) puede ser una tarea abrumadora y que requiere mucho tiempo. La mayoría de las personas que lean la frase anterior probablemente estarán de acuerdo 

La creación de un NFR puede ser una tarea difícil y la elaboración de requisitos no funcionales que sean a la vez cuantificables y medibles es un problema con el que hemos visto que muchos equipos tienen dificultades.  

Sin embargo, merece la pena el esfuerzo de elaborar unos requisitos no funcionales de calidad. 

Informes personalizables en Azure DevOps

Los requisitos no funcionales proporcionan a los equipos una herramienta para evaluar el éxito de un proyecto, un proceso o un sistema. Permiten a tu equipo definir criterios cuantificables que sirvan para debatir, analizar y evaluar los distintos aspectos de tu proyecto. 

Debido al valor que aportan los requisitos no funcionales (NFR) a un proyecto, es frecuente que los equipos se vean envueltos en procesos largos y complicados para elaborar NFR que, al final del proyecto, resultan apenas significativos o relevantes.  

Hoy vamos a cambiar eso. 

En este artículo abordamos tanto la importancia de crear NFR, comocómo cómo puedes utilizar algunas herramientas sencillas herramientas y técnicas sencillas para reducir el tiempo necesario para crear creación de NFR. 

¿Por qué merece la pena definir los requisitos no funcionales?

Los requisitos no funcionales proporcionan a tu equipo todos los indicadores de éxito de un producto, proyecto, sistema, proceso o aplicación. Cuando se define un buen requisito no funcional, el equipo no solo podrá determinar si un proyecto tiene éxito, sino que también podrá identificar fácilmente en qué medida el proyecto podría estar lejos de alcanzarlo.  

Unos buenos requisitos no funcionales pueden ser fundamentales para el éxito de un proyecto de muchas maneras distintas, más allá de servir como indicador de éxito. Los requisitos no funcionales pueden ayudar a los equipos a comprender los objetivos generales de un proyecto, a alinear los resultados del proyecto con los objetivos empresariales y mucho más.  

Basta con decir que unos NFR de calidad pueden contribuir en gran medida al éxito del proyecto y a la forma en que evaluamos ese éxito. Pero eso no significa que sean fáciles de gestionar, recabar o redactar.  

Echemos un vistazo a la técnica principal que utilizan hoy en día los equipos para crear mejores requisitos no funcionales más rápidamente.  

La técnica principal para elaborar mejores requisitos no funcionales con mayor rapidez: plantillas

A la hora de definir los requisitos no funcionales, los equipos utilizan plantillas para crear estas tareas con mayor rapidez y coherencia.

Por definición, una una plantilla es cualquier cosa que sirva de modelo y que otros puedan copiar y reutilizar.  

Por lo general, las plantillas se crean como un formato predefinido para un documento, un archivo o, simplemente, como el formato que se puede utilizar para crear cualquier NFR. Una vez implementadas, no es necesario volver a crear el formato que ofrece una plantilla cada vez que se necesita, y los usuarios pueden simplemente seleccionar una plantilla y ponerse manos a la obra rápidamente.  

Esnos lleva a la ventaja más ventaja más evidente. de el uso plantillas plantillas 

Las plantillas ahorran tiempo y aumentan la coherencia! 

Cuando los equipos empiezan a crear un proceso repetible, suelen recurrir a plantillaspara para eliminar la necesidad de volver a crear constantemente documento o archivo formatoformatosEn su lugar, reutilizar las mismas partes de un documento, archivo o estructura como plantilla permite a tu equipo reducir el trabajo repetido y aprovechar las ventajas de una mayor coherencia. 

Mientras el tiempo mientras ahorradoy y la consistencia se incrementan son geniales beneficios directos que las plantillas ofrecen, hay hay muchas beneficios indirectos beneficios indirectos que las plantillas también ofrecen 

Los beneficios indirectos de las plantillas de requisitos no funcionales

La mayor ventaja indirecta del uso de plantillas es la posibilidad de crear un método estructurado y fácil de seguir para elaborar archivos, documentos y requisitos.  

Al proporcionar una estructura basada en plantillas, a los usuarios que interactúan con un archivo o documento concreto les resulta más fácil identificar dónde introducir cada dato concreto y qué formato debe tener ese dato.  

Este tipo de orientación no solo mejora la precisión del contenido en el que se está trabajando, sino que también reduce el tiempo necesario para la elaboración de los informes de no conformidad, la revisión de documentos y la aprobación de requisitos. Esto se debe, en parte, a que el uso de una plantilla también aumenta la estandarización y la familiaridad con el activo que se está creando. 

Las plantillas aportan una doble ventaja en cuanto a la simplicidad de los elementos de trabajo NFR. La creación del elemento de trabajo se simplifica, ya que solo hay que introducir los datos en los campos correspondientes de la plantilla. Además, una vez creado el elemento de trabajo, la plantilla presenta la información de una forma más accesible.

 A medida que el proceso se simplifica, también se vuelve más accesible. Esto significa que las plantillas también facilitan la creación de los requisitos no funcionales (NFR) y su documentación a los analistas de negocio noveles o con menos experiencia. 

Sin embargo, este debate sobre las plantillas quizá ya haya empezado a dar lugar a cierta ambigüedad. 

¿Nos referimos al uso de plantillas para documentos?  

¿Nos referimos al uso de plantillas para la creación de informes no financieros? 

¿Nos referimos a utilizar plantillas que describan las características de un NFR? 

En pocas palabras, sí. 

Una plantilla de requisitos no funcionales podría utilizarse en cualquiera de estas áreas para mejorar la redacción, la obtención y la gestión de los requisitos no funcionales. 

 
Una plantilla de NFR puede utilizarse para organizar y gestionar los NFR, ayudar al equipo en la creación de documentos o incluso en la elaboración propiamente dicha de los NFR.  

 
Si buscas un método sencillo para elaborar requisitos no funcionales de alta calidad, ¡echa un vistazo a nuestro artículo «Dos pasos sencillos para crear requisitos no funcionales», que encontrarás aquí! 

Independientemente de cómo utilice tu equipo las plantillas para elaborar los requisitos no funcionales, puedes estar seguro de que la elaboración de dichos requisitos ofrece unos resultados extraordinarios y se puede llevar a cabo de forma más rápida y sencilla que nunca. 

Cómo dotar adecuadamente a tus analistas de negocios de plantillas de obtención de información

La identificación de requisitos, o la recopilación de requisitos, nunca ha sido un proceso sencillo.Sin embargo,esalgo con lo que muchas personas se enfrentana diarioen el ámbito laboral.

Por ejemplo, si alguien te pide que crees o termines algo, es posible que le hagas algunas preguntas. ¿Qué debe hacer ese algo (requisito funcional) y cómo debe ser en cuanto a seguridad, usabilidad o accesibilidad (requisito no funcional)?  

Un analista de negocios (BA) bien preparadohará, de manera similar, preguntas diseñadas para desentrañar los requisitos funcionales y no funcionales necesarios de cualquier proyecto, proceso o sistema. Los BA utilizan principalmente las preguntas como medio para interactuar con las partes interesadas. A través de este tipo de estrecha colaboración con las partes interesadas, el BAs crean un foro que ayuda a las partes interesadas a expresar lo que esperan de su producto.  

Durante una conversación con un analista de negocios, unparte interesada expresará expresará qué características desea y qué debe hacer su producto (requisitos funcionales) , así como cómo quiere que sea la experiencia del usuario (requisitos no funcionales).  

Licenciatura’s suelen emplear varias técnicas de técnicas de obtención de información al interactuar con las partes interesadas. Ddurante el proceso de obtención de información algunas de estas técnicas podrían incluir:: 

  • cuestionarios 
  • mapa mental lluvia de ideas  
  • casos de uso creación 
  • creación y revisión de documentos
  • y mucho más… 

Todas estas técnicas tienen dos cosas en común.  

  1. En primer lugar, todos ellos se utilizan para la determinación de requisitos.  
  1. En segundo lugar, cada una de estas técnicas puede aprovechar el uso de plantillas.

Pensemos en cómo los cuestionarios pueden beneficiarse de convertirse en plantillas o de utilizarlas. 

Sabemos que, paradeterminar los requisitos adecuados, hay que plantear las preguntas adecuadas.
Aquí es donde los conocimientos de unanalista de negocios con amplia experienciase convierten en unagran ventaja,yaque ha pasado por el proceso de determinación de requisitos en numerosas ocasiones. Cuenta con la ventaja de la experiencia y puede sabermejorquépreguntas plantear en relación con sectores, productos o tecnologías específicos.  

Esta experiencia y estos conocimientos se pueden recopilar fácilmente mediante una plantilla de cuestionario de requisitos no funcionales. Los analistas de negocios con experiencia pueden elaborar listas de preguntas bien pensadas o plantillas de preguntas que se centren en funciones específicas (FR) o en atributos del sistema (NFR), y orientar de forma pasiva guiar al el del equipo , aunque no participen directamente 

Estas plantillas de cuestionario pueden entonces aportan estructura y coherencia al el proceso de obtención de información, garantizar que se formulen las preguntas correctasademás reducire la probabilidad de que se pasen por alto preguntas importantes.   

Hay muchos ejemplos en los que las plantillas pueden ayudar a los equipos a aprovechar los conocimientos que ya tienen dentro del equipo. 

Veamos más ejemplos de cómo se utilizan las plantillas hoy en día en tareas de obtención de requisitos y creación de contenido ..  

Por qué los equipos han utilizado históricamente tablas como plantillas de requisitos

Muchos equipos siguen implementar plantilla de requisitos no funcionales plantillaen en forma de tabla para redactar y almacenar los requisitos. 

El uso de tablas suele responder a la necesidad de los usuarios de organizar y mantener sus requisitos en un solo lugar.  Antes de que se utilizaran herramientas específicas de gestión de requisitos, se utilizaban utilizaban para ayudar definir las convenciones de nomenclatura y numeraciónpara ayudar a realizar un seguimiento y rastrear los requisitos, así como ayudar mediante proporcionar campos para cualquier número de propiedades. 

Las tablas han tenido históricamente funcionadofuncionado tan bien como las plantillas , son son de organizar y facilitan la gestión el contenido de la tablaLas tablas han tenido tradicionalmente la ventaja añadida de ofrecer un método para exportar la información desde una tabla otras áreas, como la creación de documentos.  

¿En qué consiste ese método de exportación? Copiar y pegar.  

Para los equipos que utilizan tablas como plantillas, los rrequisitos normalmente se copian y pegan de una tabla y luego se insertan en un documento. Por lo general, el requisito es copiar y pegar campo por campo campo en una plantilla diseñada específicamente para el documento (¡otro ejemplo de uso de plantillas!) 

Sin embargo, aunque las tablas solían ser una solución sólida para gestionar esos requisitos que contienen una variedad de campos, presentan algunos inconvenientes importantes en el mundo actual de las herramientas de gestión de riesgos explícitas. 

Las tablas suelen ser recopilaciones inconexas de información importante y puedena menudo quedar aisladas de otras herramientas y procesos. Oa menudo esto da lugar a tablas convertirseen un paso adicional en tu proceso de gestión de riesgos, y un activo adicional del que alguien tiene que hacerse responsable para gestionarlo, actualizarlo y mantenerlo.  

Pero no tiene por qué ser así.  

Con la extensión «Team» de Excel de Microsoft, los equipos pueden vincular fácilmente las tablas que han utilizado anteriormente con su proyecto de Azure DevOps. Pueden asignar fácilmente cada campo de requisito, propiedad e identificador al elemento de trabajo de Azure DevOps que se crea en su proyecto. 

Pero, ¿cómo ayuda Azure DevOps con los requisitos no funcionales? 

¿Cómo gestiona Azure DevOps los requisitos no funcionales?

En primer lugar, Azure DevOps es flexible.  

La plataforma ALM de Microsoft te permite añadir fácilmente a un proyecto cualquier tipo de tarea que tu equipo necesite.  

Los requisitos no funcionales son solo uno de los tipos de elementos de trabajo que se pueden añadir a un proyecto.  

¿Qué es un «elemento de trabajo»? tipo»?  

Los elementos de trabajo son plantillas de creación basadas en ADO para el tipo de requisito que representan.  

Algunos ejemplos son requisitos funcionales, requisitos de transición, historias de usuario o incluso requisitos no funcionales. Sea cual sea la taxonomía que requiera tu proyecto, Azure DevOps la admitirá y cada uno de los elementos de trabajo que crees tendrá su propio conjunto de propiedades, estados y relaciones que se pueden seleccionar y personalizar. 

Con un requisito no funcional, puedes configurar cualquier campos propiedad que tu equipo necesitepara ayudar con la gestión de tu proyecto. Como se ha mencionado anteriormente, plasmar los requisitos que ya tienes en una tabla es sencillo con la extensión de Excel de la pestaña de Microsoft Teams [proporcionar enlace].  

Pero, ¿qué se puede hacer con los NFR una vez que están en Azure DevOps (ADO) y en qué beneficia a tu equipo trasladar la creación de los NFR a ADO? 

Veamos las herramientas.  

Requisitos modernos para DevOps: Smart Docs: plantillas personalizables para documentos de requisitos no funcionales

La elaboración de documentos depende de las políticas, los procesos, las expectativas y los requisitos de las partes interesadas de una organización, e incluso puede diseñarse para dar cabida a sus requisitos no funcionales. 

Los documentos ofrecen una forma sencilla de rendir cuentas para cumplir con los requisitos acordados para un proyecto. Ellos ofrecen un nivel de seguridad a las partes interesadas, ya que los documentos pueden servir de lista de verificación de los requisitos acordados, lo que puede fácilmente compararse para determinar si las partes interesadas están obteniendo lo que han pagado o si el trabajo no se ha completado. 

Otra ventaja importante de una documentación adecuada es que los requisitos suelen evolucionar a lo largo del ciclo de vida de un proyecto. Un requisito puede definirse con mayor claridad en una fase posterior, o simplemente puede evolucionar de tal manera que dé lugar a una expectativa diferente respecto a su producto.  

Incluye en tu proceso los documentos de requisitos no funcionales. 

A medida que cambian los requisitos, tambiéno las expectativas respecto a tu proyecto. Esto significa que los indicadores de éxito de tu proyecto, también conocidos como requisitos no funcionales, tendrán que revisarse y modificarse.  

Gracias al módulo Smart Docs de la suite Modern Requirements4DevOps, los usuarios pueden crear fácilmente un documento de requisitos con control de versiones directamente desde su proyecto de Azure DevOps. Esto significa que los usuarios pueden realizar y realizar un seguimiento de los cambios en los requisitos de forma sencilla a través de una interfaz de documentos muy intuitiva.  

Los nuevos requisitos pueden también crearse fácilmente en tu proyecto desde la interfaz del documento, o puedes optar por insertar los requisitos existentes directamente entu documento. Esto significa que puedes arrastrar y soltar fácilmente tus requisitos no funcionales directamente en un documento fácilmente exportable sin salir de Azure DevOps y sin necesidad de copiar y pegar.  

Ampliemos la idea de importar tus NFR existentes que se encuentran en tablas a Azure DevOps, y luego explicar cómo puedes convertir estos NFR en documentos utilizando Modern Requirements.  

En primer lugar, importa a Azure DevOps los requisitos no funcionales de tu tabla mediante la extensión de la pestaña «Microsoft Teams» para Excel. A continuación, solo tienes que consultar todos los requisitos no funcionales y arrastrarlos y soltarlos en tu documento.  

Así de sencillo.  

Pero supongamos que ahora quieres estructurar un documento de tal manera que los requisitos no funcionales solo se puedan añadir en determinadas secciones del mismo.  

¡Nosotros también lo apoyamos! 

Hay un diseñador de plantillas integrado directamente en el módulo Smart Docs, que te ayuda a definir qué tipos de elementos de trabajo se permiten y en qué parte de tus documentosEsto significa que cualquier persona que cree un documento, ya sea basado en NFR o de otro tipo, puede seguir fácilmente la estructura que ofrece su plantilla y crear documentación coherente. 

Requisitos modernos para DevOps: Smart Docs: plantillas reutilizables para documentos de requisitos no funcionales

Las plantillas de documentos reutilizables son un gran recurso para cualquier equipo.  De hecho, es probable que ya las utilices a diario.  

Una plantilla de documento reutilizable proporciona a tu equipo un documento ya rellenado que muestra cómo debe ser el documento final. Este tipo de plantilla ayuda a los autores a determinar fácilmente dónde debe ir cada dato concreto y qué elementos contextuales deben formar parte del documento creado.  

Piensa en ese documento de Word que ya tienes en el escritorio. Probablemente ya tenga espacios reservados para secciones como «Introducción», «Ámbito de aplicación» y «Objetivos», así como para los requisitos específicos. Se trata de una plantilla de documento reutilizable.  

La principal motivo por el que se utilizan se utilizan eso aumentar la eficiencia y reducir el trabajo de reelaboración en el proceso de elaboración .  

Por suerte para los equipos que actualmente utilizan varias aplicaciones para sus procesos de gestión de requisitos y documentación, existe una solución que sirve para ambos: Modern Requirements con Azure DevOps.  

El plantillas de documentos que que crees con Modern Requirements + Azure DevOps, se pueden configurar para incluir cualquier campo o propiedadque necesites mostrar en tu documento. Puede guardar cualquier documento como una plantilla de documento reutilizable, que puede rellenar automáticamente campos como Introducción, Objetivos, Requisitos NFR y más. 

¡Con solo unos clics podrás crear documentos que ayudarán a tu equipo a ponerse en marcha rápidamente a la hora de elaborar cualquier tipo de documentación! Esto significa que tu equipo no solo se beneficiará de que tus documentos y requisitos se encuentren en un mismo espacio, sino que también aumentar la eficiencia, crear una estructura, mejorar la precisión y lograr coherencia en tu proceso de creación de documentos.   

Requisitos modernos para DevOps: Módulo de preguntas frecuentes: plantillas de cuestionarios personalizables y reutilizables

Los requisitos no funcionales son mucho más abstractos que los funcionales.  

Esto hace que que sean más difíciles de extraer, ya que no te limitas a señalar el sistema y decirle qué debe hacer, sino que estás haciendo preguntas sobre cómo debería ser el sistema y utilizando los NFR para representarlo. 

Como se ha comentado anteriormente en este artículo, la creación de NFR sólidos depende basan en plantear las preguntas adecuadas.  

Entonces, ¿qué pasa si eres nuevo en la gestión de requisitos o tienes poca experiencia? ¿Por dónde empiezas? MR4DevOps aborda esta situación con nuestro completo módulo de preguntas frecuentes.  

El módulo de preguntas frecuentes es una serie de plantillas de preguntas específicas dirigidas a atributos concretos del sistema, clasificadas según los tres aspectos principales del producto: operativo, de revisión y de transición.  

Además, el módulo de preguntas frecuentes contiene plantillas de preguntas para la obtención de requisitos no funcionales (NFR) para el cumplimiento y de riesgo basado el desarrollo de productos sanitarios. A medida que los usuarios responden a las preguntas de laplantilla plantilla, se automáticamente creane un requisito no funcional directamente en el Backlog. 

El plantillas plantillas de cuestionario incluidas en el módulo de preguntas frecuentes son útiles para los analistas de negocios con todos los niveles de experiencia. Los analistas de negocios veteranos pueden modificar las listas existentes añadiendo sus propias preguntas o crear su propia lista de preguntas desde ceroDe este modo, los analistas de negocios pueden plasmar su experiencia y sus conocimientos sobre el proceso de obtención de requisitos y transmitirlos a otros miembros del equipo.  

Requisitos modernos para DevOps: Smart Report: plantillas de informes configurables

MR4DevOps ofrece una excelente solución a una de las principales carencias de ADO: la falta de una herramienta de generación de informes integrada.  

Si utilizas herramientas como FAQ o Smart Docs para redactar y gestionar tus requisitos no funcionales, Smart Report será la herramienta que utilices para generar tus requisitos. Smart Report te permite generar requisitos en formato PDF, HTML o Microsoft Word, donde podrás aplicar tus propios encabezados y pies de página prediseñados e incluso una tabla de contenidos o una portada.  

¿Quieres elaborar un informe sobre los requisitos no funcionales (NFR) de tu proyecto?  

La herramienta Smart Report cuenta con un diseñador de plantillas diseñador de plantillas. El diseñador de plantillas te permite crear y guardar plantillas de informes plantillabasadas basadas en el tipo de elemento de trabajo. Esto te permite crear una plantilla de NFR única que muestre las propiedades y los campos de un NFR que desees incluir en el informe; ¡esta información se extrae directamente del elemento de trabajo! 

Esta plantilla se puede aplicar a cualquier grupo de NFR seleccionados o extraídos mediante una consulta, y utilizarla siempre que lo requiera su proceso de generación de informes. La ventaja de esta herramienta de generación de informes es que le permite crear informes de requisitos instantáneos, estructuradosy coherentes. 

¿Te gustaría verlo por ti mismo?

Modern Requirements4DevOps ofrece varias soluciones para ayudar en la obtención, redacción y gestiónde requisitos no funcionales. 

¿Te gustaría conocer más a fondo el diseño de plantillas con Modern Requirements o te interesa saber qué otras herramientas pueden mejorar tu proceso? ¡Reserva hoy mismo una demostración del producto!

Comprueba por ti mismo cómo nuestra caja de herramientas «Modern Requirements» puede potenciar Azure DevOps de Microsoft, líder del sector, para convertirlo en una solución única de gestión de requisitos de aplicaciones.

Visita www.modernrequirements.com para obtener más información sobre nuestra empresa y nuestros productos.

¡Solicite una demostración!

Reducir los esfuerzos de UAT

Reducción del 50 % en los esfuerzos de UAT

Ahorro de tiempo comprobado

Ahorro del 80 % en tiempo de creación del análisis de trazas.

Agilizar las aprobaciones

Reducción significativa de los retrasos en la aprobación

Aumentar el rendimiento

50 % de requisitos de mejora de la productividad

Reducir la repetición del trabajo

Reducción de 10 veces en la reelaboración del desarrollo

Simplifique el cumplimiento normativo

Reducción del 40 % en los esfuerzos de presentación de informes de cumplimiento normativo.

Configuración de la pestaña «Agente MR/Servicios»

Configuración de Modern Requirements4DevOps mediante la pestaña «Agente/Servicios» de MR

En este artículo explicamos cómo configurar la pestaña «Agente MR / Servicios» en MR4DevOps. La pestaña «Servicios» ofrece actualmente a los usuarios tres funciones adicionales para cualquier proyecto que utilice Azure DevOps (antes conocido como VSTS). 

Requisitos de creación de contenido con Modern Requirements4DevOps

Uso de la pestaña «Servicios» para configurar
Modern Requirements4DevOps

MR Services (antes conocido como MR Agent) es uno de los componentes de Modern Requirements4DevOps que se instala automáticamente junto con la aplicación principal. Se trata de un marco de trabajo que proporciona extensibilidad a Azure DevOps mediante desencadenantes.

IMPORTANTE:
Tenga en cuenta que solo se puede acceder a los servicios MR mediante los servicios de Azure DevOps utilizando una dirección IP pública para comunicarse con VSTS (servicios de Azure DevOps). Si alguna máquina no tiene acceso público, no se podrán utilizar los servicios de Azure DevOps de VSTS (ya que requieren acceso público para comunicarse con la máquina). Se recomienda a los usuarios que se pongan en contacto con sus administradores de red para cambiar el valor a la dirección IP pública de sus máquinas, incluyendo el puerto correspondiente.

Actualmente, MR Services (MR Agent) cuenta con los tres subcomponentes siguientes:

  1. Identificación personalizada
  2. Bandera sucia
  3. Monitor de correo electrónico

Es necesario realizar una autenticación de usuario adecuada antes de configurar cualquiera de estos componentes. Los archivos de configuración de cualquiera de los componentes no funcionarán a menos que la organización correspondiente (en Azure DevOps) o la colección (en TFS) se haya registrado mediante autenticación.

Autenticación de usuarios de MR Services

  1. Inicie la versión integrada de la aplicación y seleccione el Requisitos modernos para DevOps opción en el Pestaña «Configuración».

    Se muestra el panel de administración.
  2. Haz clic en el Pestaña «Servicios».

    Se muestran las opciones de la pestaña «Servicios».

    La subpestaña «Configuración» incluye dos opciones:

    • Configuración del intervalo de tiempo para analizar la organización de Azure DevOps (o la colección de TFS) en busca de nuevos proyectos
    • Registro de la organización actual (para esta opción se requieren las credenciales de usuario administrador)

    Nota: Introduzca los valores para ambos ajustes a la vez. Los usuarios no pueden configurar un ajuste y dejar el otro pendiente.

  3. Introduce el intervalo de tiempo para el escaneo automático (debe estar entre 1 y 60).

    Este valor determina el intervalo, expresado en minutos, tras el cual se analizará la organización de Azure DevOps registrada en busca de nuevos proyectos.

  4. Proporcione las credenciales de inicio de sesión autorizadas (con derechos de administrador de TFS).

    Una vez completada la autenticación, se registra la organización actual y se muestra un mensaje de confirmación.

Cómo identificar manualmente un nuevo proyecto en tu organización de Azure DevOps

En la sección anterior se ha explicado el proceso para personalizar la frecuencia de análisis automático de la organización de Azure DevOps. El valor que se muestra en la imagen anterior indica que la organización se analizará cada 30 minutos en busca de nuevos proyectos.

Sin embargo, si el usuario acaba de crear un nuevo proyecto y quiere empezar a trabajar en él de inmediato, deberá identificarlo manualmente (el proyecto) en la organización de Azure DevOps. Para ello, es necesario seguir los siguientes pasos:

  1. Escribe el siguiente comando en el símbolo del sistema: cd :\Archivos de programa\Modern Requirements\MR-Agent\bin

  2. Una vez en el directorio «bin», introduce el siguiente comando: MRAgent

    Se muestra el menú de opciones.

  3. Tipo 4 y pulsa Intro.
  4. Introduce el nombre de la organización de Azure DevOps para buscar nuevos proyectos.

    Si no aparece ningún mensaje de error, significa que el proceso se ha llevado a cabo correctamente para escanear los nuevos proyectos creados tras registrar una organización de Azure DevOps o aplicar su configuración.

Configurar la función «ID personalizado»

El ID personalizado es un componente de MR Services (MR Agent) que se utiliza para asignar ID personalizados a los elementos de trabajo, además de sus ID predeterminados. Los ID personalizados no sustituyen a los ID originales, sino que los complementan. Los ID personalizados pueden utilizarse para realizar un seguimiento del origen de los elementos de trabajo (es decir, qué equipo creó un elemento de trabajo concreto).

Para que el ID personalizado funcione correctamente, los usuarios deben crear manualmente los dos elementos siguientes:

  1. Una carpeta que lleva el nombre del servidor de Azure DevOps (TFS) (en el que es necesario aplicar el ID personalizado).
  2. Otra carpeta que lleva el nombre de la organización de Azure DevOps o de la colección de TFS (para la que se requiere un ID personalizado) dentro de la carpeta denominada «Azure DevOps (TFS)».

La carpeta de la organización correspondiente también debería incluir el config.xml archivo que contiene toda la configuración. La jerarquía de archivos y carpetas debe aparecer tal y como se muestra a continuación, utilizando el patrón de texto y la imagen correspondiente:

Como se muestra en la imagen anterior, una muestra Config.xml El archivo se coloca en el ID personalizado carpeta.

  1. Crea una carpeta con el nombre del servidor de Azure DevOps (en el que se debe aplicar el componente) en esta ubicación.
  2. Accede a la carpeta que acabas de crear y vuelve a crear aquí otra carpeta con el nombre de la organización de Azure DevOps (en cuyo componente se debe aplicar).
  3. Copia el xml archivo (mencionado anteriormente) en la carpeta recién creada, es decir, la carpeta con el nombre de la organización de Azure DevOps.

    Este archivo contiene el esquema de la configuración deseada.

Configuración del archivo XML de ID personalizados

  1. Abre el xml archivo en el Bloc de notas o en cualquier editor de texto.
  2. Define el valor de la IDScope etiqueta según sea necesario, por ejemplo:

    – Colección -> aplicar el ámbito del contador al nivel de la colección.
    – Proyecto -> aplicar el ámbito del contador al nivel del proyecto.
    – Equipo -> aplicar el ámbito del contador al nivel del equipo.

  3. La etiqueta«FieldReferenceName»con el valor«Override»establecido en«Sí»significa que el campo definido por el usuario (entre las etiquetas) se tendrá en cuenta para el ID personalizado. El valor«Override»establecido en«No»significa que se tendrá en cuenta y se aplicará el campo predeterminado «MR.CID» para el ID personalizado. Esto implica que los usuarios deben definir este campo en su plantilla de TFS con el mismo nombre de referencia, es decir, MR.CID.
  4. La etiqueta«CollectionUrl»requiere la URL de la colección de TFS a la que se debe aplicar el ID personalizado. (Nota: asegúrate de que la URL no termine en «\»).
  5. Projects DefaultNoOfChar” tag denotes the number of characters to pick up from the project name, if the project name is not defined in the tag<Project Name= “ ”>. By default its value is 5. Update the value if desired.
  6. Indique el nombre del proyecto TFS (por ejemplo, Project Name = «GITNew») y su nombre personalizado (por ejemplo, Prefix = «GTN») para utilizarlos como parte de los identificadores personalizados.
  7. Identificador de secuencia = «1»El valor del ID de la etiqueta «» indica el número de grupos de ID personalizados diferentes creados en el archivo de configuración y se utiliza para identificar y diferenciar el ID. Siempre será un campo exclusivamente numérico y debe mantenerse único. La etiqueta «Sequence» consiste en una combinación del tipo de elemento de trabajo, el formato requerido en el campo de ID y el contador desde el que se inicia.
    1. El valor«WIType»indica el tipo de elemento de trabajo al que se debe aplicar el ID personalizado. Además, si es necesario, se pueden definir varios elementos de trabajo para la misma configuración, de modo que se apliquen como un grupo.
    2. La etiqueta«FieldFormat»se utiliza para definir el formato de identificación requerido en el ID personalizado.
      Ejemplo: [PN] Req #####[PN] se utiliza como marcador de posición para el prefijo del nombre del proyecto definido anteriormente.

      Para consultar el formato numérico, consulte el siguiente enlace:
      https://docs.microsoft.com/en-us/dotnet/standard/base-types/custom-numeric-format-strings
    3. La etiqueta «FieldCounter» es necesaria para definir el número o la serie desde la que debe comenzar el contador de ID personalizado. Una vez aplicado el valor del contador (una vez aplicado el archivo de configuración), no se puede modificar bajo ningún concepto.
  8. Una vez completada correctamente la configuración del archivo, guárdelo y ciérrelo.

Aplicación de un identificador personalizado a elementos de trabajo existentes

  1. Escribe el siguiente comando en el símbolo del sistema: cd :\Archivos de programa\Modern Requirements\MR-Agent\bin
  2. Una vez en el directorio «bin», introduce el siguiente comando: MRAgent

     

    Se muestra el menú de opciones.

  3. Tipo 1 y pulsa Intro.
  4. Introduce la URL de la organización de Azure DevOps (o de la colección de TFS).
  5. Si no aparece ningún mensaje de error, significa que el ID personalizado se ha aplicado correctamente a los elementos de trabajo existentes de la colección.

Configurar la función «Dirty Flag»

«Dirty Flag» es un componente de MR Services (MR Agent) que se utiliza para marcar determinados elementos de trabajo como «sucios» (debido a cambios en los requisitos), de modo que las partes interesadas pertinentes puedan revisarlos una vez, en lugar de seguir adelante con requisitos obsoletos.

Para que la bandera sucia funcione correctamente, los usuarios deben crear manualmente los dos elementos siguientes:

  1. Una carpeta que lleva el nombre del servidor de Azure DevOps (TFS) (en el que se debe aplicar el indicador «Dirty»).
  2. Otra carpeta que lleva el nombre de la organización de Azure DevOps o de la colección de TFS (en la que se requiere el indicador «Dirty») dentro de la carpeta denominada «Azure DevOps (TFS)».

La carpeta de recopilación correspondiente también debería incluir el config.xml archivo que contiene toda la configuración. La jerarquía de archivos y carpetas debe aparecer tal y como se muestra a continuación, utilizando el patrón de texto y la imagen correspondiente:

Como se muestra en la imagen anterior, una muestra Config.xml El archivo se coloca en el Bandera sucia carpeta.

  1. Crea una carpeta con el nombre del servidor de Azure DevOps (TFS) (en el que se debe aplicar el componente) en esta ubicación.
  2. Accede a la carpeta que acabas de crear y vuelve a crear aquí otra carpeta con el nombre de la organización de Azure DevOps (o de la colección de TFS) a la que se debe aplicar el componente.
  3. Copia el xml archivo (mencionado anteriormente) en la carpeta recién creada, es decir, la carpeta con el nombre de la organización de Azure DevOps (o la colección de TFS).

    Este archivo contiene el esquema de la configuración deseada.

Configuración del archivo XML «Dirty Flag»

  1. Abre el xml archivo en el Bloc de notas o en cualquier editor de texto.
  2. Defina el valor de la URL de la colección utilizando el URL de la colección

     

    Cada etiqueta de acción tiene un Fuente parte y un Destino parte. La parte «Fuente» indica a MR Services (agente MR) qué debe buscar para activar el indicador «Dirty»; la parte «Destino» indica a MR Services (agente MR) qué tipo de elementos de trabajo se marcarán como «Dirty» en caso de que se active el indicador.
  1. En la sección «Fuente», la etiqueta«WIType»indica el tipo de elementos de trabajo con los que funcionará el indicador «Dirty». Se pueden utilizar varios tipos de elementos de trabajo, separados por una coma «,».
  2. La etiqueta«FieldReferenceName»indica qué campo o campos del elemento de trabajo (la lista se proporciona en la etiqueta WIType ) se comprobarán.
  3. El «Valor de campoLa etiqueta «» indica el valor exacto de la Nombre de referencia de campo que activará el indicador «Dirty».

    Si se marcan varios campos, el indicador «Dirty» solo se activará cuando coincidan todos los valores de los campos, es decir, aplicando la lógica «Y».

  4. El«WIType»de la sección de destino indica el tipo de elementos de trabajo que se marcarán como modificados si se cumple la condición de la sección de origen.
  5. Guarda y cierra el archivo de configuración una vez que hayas terminado.

Configuración de la función de supervisión del correo electrónico

Email Monitor es un componente de MR Services (MR Agent) que se utiliza para crear automáticamente elementos de trabajo a partir de correos electrónicos. Para ello, se configura una dirección de correo electrónico específica y, una vez completado con éxito el proceso de configuración, todos los correos electrónicos enviados a dicha dirección dan lugar a la creación o actualización de elementos de trabajo. El proceso consta de los siguientes pasos*:

  1. Configuración del archivo de configuración del monitor de correo electrónico (ubicado en una ubicación concreta)
  2. Introducir y comprobar la configuración del correo electrónico

    A continuación se explica cada uno de estos pasos con más detalle.

    *En el caso de los servidores locales de Azure DevOps (TFS), MR Services (MR Agent) añade automáticamente la ubicación correspondiente en el archivo de configuración de la aplicación (AppSettings.config). Sin embargo, si se utilizan los servicios de Azure DevOps, el equipo del usuario debe tener una dirección IP activa que dichos servicios puedan utilizar para acceder y comunicarse. Esta dirección IP debe añadirse al archivo de configuración AppSettings. El proceso para hacerlo se detalla en los siguientes pasos:

  3. Ve a la carpeta de instalación de MR Services (MR Agent) (resaltada en la imagen) y abre el Configuración de la aplicación el archivo de configuración en un editor de texto.

    El URL de la aplicación se configura automáticamente para el equipo local.

  4. Cambia el valor (solo para Azure DevOps Services) por la dirección IP activa de tu equipo, incluyendo el puerto correspondiente.
    *Ponte en contacto con tu administrador de red para obtener la dirección IP activa y la información del puerto

  5. Guarda y cierra el archivo de configuración.

Configuraciones de sincronización en el archivo APPSETTING

En la parte inferior del archivo de configuración , hay tres configuraciones de tiempo disponibles para los usuarios.

SuscribirseProgramación

  1. Funciona con todos los componentes de MR Services
  2. Se utiliza para revisar nuevos proyectos o colecciones
  3. El valor predeterminado «30»* representa el número de minutos tras los cuales MR Services (MR Agent) busca nuevos proyectos. Los usuarios pueden configurar este valor (en minutos) según sus necesidades.

*Este valor también se puede configurar desde el Panel de administración.

Aplicar todo el calendario

  1. Solo funciona con un ID personalizado
  2. Se utiliza para asignar un identificador personalizado a los elementos de trabajo recién creados
  3. El valor predeterminado «30» representa el número de minutos tras los cuales MR Services (MR Agent) busca nuevos elementos de trabajo y les aplica identificadores personalizados. Los usuarios pueden configurar este valor (en minutos) según sus necesidades.

Correo electrónico, consultar horario

  1. Solo funciona con Email Monitor
  2. Se utiliza para comprobar si ha llegado un nuevo correo electrónico a partir del cual se puedan crear o actualizar tareas
  3. El valor predeterminado «15» representa el número de minutos tras los cuales MR Services (MR Agent) comprueba si hay correo electrónico. Los usuarios pueden configurar este valor (en minutos) según sus necesidades.

Configuración del monitor de correo electrónico

Para que el Monitor de correo electrónico funcione correctamente, los usuarios deben crear manualmente los siguientes elementos:

  1. Una carpeta que lleva el nombre del servidor de Azure DevOps (TFS) (en el que se debe aplicar el monitor de correo electrónico).

La carpeta del servidor correspondiente también debe incluir el archivo config.xml, que contiene toda la configuración. La jerarquía de archivos y carpetas debe tener el aspecto que se muestra a continuación, tal y como se indica en el texto y en la imagen correspondiente:

* Nota: en las versiones actuales de Email Monitor, la jerarquía se limita a la carpeta del servidor, y el archivo debe colocarse en dicha carpeta. Sin embargo, en futuras versiones, la jerarquía se ampliará hasta la carpeta de la organización (al igual que otros componentes de MR Services (MR Agent)). Si tiene alguna duda al respecto, consulte a su administrador o póngase en contacto con Modern Requirements.

Tal y como se muestra en la imagen anterior, en la carpeta EmailMonitor se encuentra un archivo Config.xml de ejemplo.

  1. Crea una carpeta con el nombre del servidor de Azure DevOps (TFS) (en el que se debe aplicar el componente) en esta ubicación.
  2. Entra en la carpeta que acabas de crear y copia el xml archivo (mencionado anteriormente) en esa carpeta, es decir, la carpeta con el nombre del servidor de Azure DevOps (TFS).
  3. Este archivo contiene el esquema de la configuración deseada.

Configuración del archivo XML del monitor de correo electrónico

  1. Abre el xml archivo en el Bloc de notas o en cualquier editor de texto.
  2. Define el valor de la URL del servidor etiqueta según sea necesario, por ejemplo:
  3. Defina de igual modo el valor para URL de la colección (incluido el Proyecto predeterminado)

    IMPORTANTE
    – Los valores tanto para el URL del servidor y URL de la colección debería corresponder a la estructura de carpetas descrita anteriormente.
    – Asegúrate de que la URL no termine con una barra «/»
    – El usuario puede definir varias URL de colecciones en el archivo de configuración.
  4. Introduce el valor para Correo electrónico de administración. Esta dirección de correo electrónico se utiliza como medida de contingencia, en caso de que no sea posible lograr la funcionalidad deseada utilizando la dirección definida en Correo electrónico etiqueta (se explica en el siguiente paso).

    Nota: En el archivo de configuración solo puede aparecer una dirección de correo electrónico de administrador.

  5. Correo electrónicoLa etiqueta «» es la etiqueta principal de este archivo y define a dónde se enviará el correo electrónico. Los correos electrónicos enviados a esta dirección se utilizarán para crear los tipos de elementos de trabajo deseados. Configura el Correo electrónico etiqueta según sea necesario
    1. Correo electrónico: Indique la dirección de correo electrónico de destino a la que se debe enviar el correo electrónico para la creación o actualización de elementos de trabajo. En caso de que algún criterio no coincida con los valores deseados, se enviará un correo electrónico de aviso a la Correo electrónico del administrador definido anteriormente.

      Nota: En el archivo de configuración se pueden definir varias direcciones de correo electrónico.

    2. Tipo de tarea: Seleccione el tipo de elemento de trabajo que desea crear. En el siguiente ejemplo Categoría:Referencia representa el tipo de categoría interna de los elementos de trabajo. Si esta etiqueta contiene varios valores, se creará el tipo de elemento de trabajo correspondiente en función de la plantilla del proyecto de equipo. Por ejemplo, si el proyecto de equipo utiliza la plantilla CMMI, el correo electrónico creará un elemento de trabajo de «Requisito». Del mismo modo, para un proyecto basado en Agile se creará una «Historia de usuario», y para un proyecto basado en Scrum se creará un «Elemento del backlog del proyecto».
    3. FieldReference = «System.Title»: Indica cuál sería el título del elemento de trabajo que se va a crear. El siguiente ejemplo muestra que el asunto del correo electrónico se convertiría en el título del elemento de trabajo.
      1. OnCreate= ”true” means that the title would be set from the email’s subject only for new Work Items.
      2. OnUpdate=”false” significa que, en el caso de los elementos de trabajo existentes, el campo «Título» no se actualizaría.
    4. FieldReference = «System.Description»: Indica dónde se debe colocar la información de los correos electrónicos recibidos (es decir, en qué propiedad o campo del elemento de trabajo). En el siguiente ejemplo se utiliza el Descripción campo destinado a tal fin.
      1. OnCreate= ”true” means that for new Work Items, the content of the email (described next) would be used to populate the Description field of the work item.
      2. OnUpdate=”false” means that for existing Work Items, the Description field would not be overwritten. Instead the update would go to the comments/history section of the work item.
    5. La última parte de este campo indica la composición del campo «Descripción». La siguiente información conformaría el campo «Descripción»:

      1. Sender Name shown inside <> e.g.
      2. Sender Email also shown inside <> e.g. <alice.ducas@steveandrews.com>
      3. El cuerpo del correo electrónico se ha añadido en una nueva línea
    6. La final FieldReference = «System.History» se utiliza para los correos electrónicos de debate que se envían una vez creado un elemento de trabajo. En lugar de sobrescribir el Descripción campo, la información del correo electrónico posterior se almacena en el Comentarios campo (denominado internamente Historia). La composición de la Historia el campo es más o menos el mismo que el de Descripción campo mencionado anteriormente. Se recomienda a los usuarios que mantengan la configuración original de esta etiqueta.
    7. Una vez completada correctamente la configuración del archivo, guárdelo y ciérrelo.

Configuración del monitor de correo electrónico

Email Monitor se puede configurar mediante los ajustes correspondientes en el panel de administración. Se puede acceder a estos ajustes a través de la pestaña «Servicios».

La sección «Servicios» del panel de administración cuenta actualmente con dos pestañas: Configuración & Monitor de correo electrónico

La pestaña «Configuración» se ocupa de: 1) la autenticación de usuarios y el registro de la organización; 2) la búsqueda de nuevos proyectos.

Email Monitor gestiona todas las opciones relacionadas con el correo electrónico que se han comentado anteriormente en la sección sobre la línea de comandos.

Configuración de las opciones de Email Monitor

  • La pestaña «Monitor de correo electrónico», situada en la sección «Servicios», sirve para configurar los ajustes de correo electrónico.
  • Para acceder a las opciones, haz clic en la pestaña «Email Monitor», tal y como se muestra en la siguiente imagen.
  • Si el usuario no ha registrado su organización (introduciendo los datos necesarios en la subpestaña «Configuración»), al hacer clic en la subpestaña «Monitor de correo electrónico» se le redirigirá de nuevo a la subpestaña «Configuración», a menos que introduzca la información requerida.
  • Los ajustes de Email Monitor se dividen en secciones, y cada sección sirve para configurar un parámetro concreto.
  • Todos los ajustes necesarios se configuran una sola vez. Los usuarios no pueden configurar algunos ajustes y dejar otros pendientes.
  • La primera sección sirve para configurar el proyecto predeterminado y la dirección de correo electrónico del administrador.
  • La segunda sección sirve para configurar la dirección de correo electrónico que se utilizará para la supervisión del correo electrónico.
  • Al hacer clic en Registrar dirección de correo electrónico se abriría una ventana emergente en la que se podrían configurar los ajustes de red del correo electrónico (por ejemplo, SSL, POP3, IMAP, etc.).

  • La tercera sección se utiliza para configurar los ajustes (que se emplearán para) extraer el contenido de los elementos de trabajo de los correos electrónicos enviados a la dirección de correo electrónico registrada.

    Al hacer clic en el botón «Guardar cambios » tras configurar todos los ajustes, se implementará el monitor de correo electrónico.

Artículos relacionados

Contactar con el servicio de asistencia

Asistencia en caso de incidencias

Reciba asistencia en tiempo real por teléfono, correo electrónico o videoconferencia. Cada solicitud de asistencia para un incidente puede referirse a un problema concreto.

Asistencia en caso de incidencias

¡Ve ya!

Asistencia por correo electrónico

Envía un correo electrónico a nuestro equipo de asistencia para obtener una respuesta más rápida. ¡Al enviarnos un correo, se creará automáticamente un ticket para ti!

Asistencia por correo electrónico

¡Ve ya!

Envía una idea

¿Quieres sacar más partido a nuestros productos? Tus sugerencias nos ayudan a mejorar. ¡Envíanos una idea y estudiaremos la posibilidad de incluirla en nuestra lista de tareas pendientes!

Envía una idea

¡Ve ya!

Apoyo a la comunidad

Encuentra respuestas a preguntas frecuentes o envía una solicitud de asistencia en nuestro portal de asistencia de la comunidad.

Apoyo a la comunidad

¡Ve ya!

Informar de un error

Si encuentras algún error, háznoslo saber y nos encargaremos de solucionarlo lo antes posible. A nadie le gustan los errores, y nosotros no somos una excepción.

Informar de un error

¡Ve ya!

Contactar con el servicio de asistencia

Asistencia en caso de incidencias

Reciba asistencia en tiempo real por teléfono, correo electrónico o videoconferencia. Cada solicitud de asistencia para un incidente puede referirse a un problema concreto.

Asistencia en caso de incidencias

¡Ve ya!

Asistencia por correo electrónico

Envía un correo electrónico a nuestro equipo de asistencia para obtener una respuesta más rápida. ¡Al enviarnos un correo, se creará automáticamente un ticket para ti!

Asistencia por correo electrónico

¡Ve ya!

Envía una idea

¿Quieres sacar más partido a nuestros productos? Tus sugerencias nos ayudan a mejorar. ¡Envíanos una idea y estudiaremos la posibilidad de incluirla en nuestra lista de tareas pendientes!

Envía una idea

¡Ve ya!

Apoyo a la comunidad

Encuentra respuestas a preguntas frecuentes o envía una solicitud de asistencia en nuestro portal de asistencia de la comunidad.

Apoyo a la comunidad

¡Ve ya!

Informar de un error

Si encuentras algún error, háznoslo saber y nos encargaremos de solucionarlo lo antes posible. A nadie le gustan los errores, y nosotros no somos una excepción.

Informar de un error

¡Ve ya!