Descubre cómo generar fácilmente los requisitos y los recursos en formato HTML, PDF o como documentos de Microsoft Word.
Continuar leyendoNotificación de incidencias
Panel de administración de Modern Requirements
Descubre cómo utilizar de forma eficaz el panel de administración de Modern Requirements para tomar el control total de tu proyecto.
Continuar leyendoReutilización de requisitos
Reutilización de requisitos
Descubre cómo reutilizar requisitos en Azure DevOps
Azure DevOps es una plataforma increíble que ofrece una única fuente de información fiable.
Para muchos equipos, esa afirmación por sí sola basta para plantearse utilizar la plataforma ALM líder en el mundo para la gestión de sus requisitos. La posibilidad de vincular las tareas de desarrollo a los requisitos, y estos a los casos de prueba, es una ventaja difícil de dejar pasar.
Pero, ¿y si no necesitas todas las funciones de una plataforma ALM completa?
¿Y si solo necesitas una solución para gestionar tus requisitos?
Puede aprovechar todas las completas funciones de Modern Requirements4DevOps para convertir su proyecto de Azure DevOps en una solución de gestión de requisitos con todas las prestaciones. Una de estas funciones es la posibilidad de reutilizar requisitos en diferentes proyectos, colecciones y servidores mediante la herramienta de reutilización de Modern Requirements4DevOps.
¿Quieres reutilizar requisitos?
Estás en el lugar adecuado.
Lo que aprenderás en este breve artículo:
- Ventajas de reutilizar los requisitos
- Los dos tipos de requisitos de reutilización
- Cómo aprovechar eficazmente la reutilización de requisitos
Las ventajas de reutilizar los requisitos
Cuando hablamos de las ventajas de la reutilización de requisitos, hay un aspecto que debemos abordar en primer lugar.
La pregunta que más me hacen los equipos de hardware es: «¿Cómo podría esto beneficiar a equipos que no se dedican al software?».
Antes de empezar, hay que decir que la reutilización de requisitos no es algo exclusivo de los equipos de desarrollo de software.
La reutilización de requisitos es un tema que suele llamar la atención.
Esto se debe a que, en la economía mundial, vemos cómo las empresas se centran en determinados ámbitos o sectores dentro de unas industrias concretas. Esto lleva a que las empresas desarrollen productos dentro de un ámbito específico, o en torno a una solución concreta, y se centren realmente en las pocas cosas en las que pueden tener verdadero éxito.
Esto significa que, al desarrollar proyectos, soluciones o sistemas, a menudo un equipo puede reutilizar elementos de un proyecto anterior. Aquí es donde entra en juego la reutilización de requisitos.
Al permitir que un equipo reutilice esos requisitos en el siguiente proyecto, se consigue reducir la carga de trabajo necesaria para poner en marcha un nuevo proyecto.
Para algunas personas, esto quizá ya sea obvio.
Sin embargo, lo que quizá no resulte tan evidente es que la reutilización también puede ser una excelente forma de gestionar los requisitos cuyo alcance trasciende el ámbito del proyecto. Esto incluiría los requisitos no funcionales o los riesgos que deben tenerse en cuenta como una exigencia a nivel de toda la empresa. Esto llegaría incluso a permitir que tu equipo reutilice requisitos cuyo propósito sea estrictamente normativo o centrado en el cumplimiento. Esta funcionalidad puede extenderse tanto a equipos de software como de hardware, e incluso puede ayudar a equipos de producto dedicados a un componente físico o a un entregable.
Los dos tipos de reutilización de requisitos
Reutilización de requisitos por referencia
Reutilizar requisitos por referencia es una forma rápida de incorporar requisitos ya existentes a tu proyecto simplemente creando vínculos con ellos. De este modo, podrás acceder directamente a esos elementos de trabajo y revisar todo el contenido, los enlaces y los archivos adjuntos asociados sin necesidad de copiarlos dentro del proyecto ni entre proyectos.
Reutilización de requisitos mediante copia
En Azure DevOps, las funciones para copiar requisitos u otros elementos de trabajo de un proyecto a otro son muy limitadas. Sin embargo, al añadir Modern Requirements4DevOps a tu entorno de Azure DevOps, la reutilización de requisitos alcanza todo su potencial.
Al analizar la reutilización de requisitos mediante copia, hay tres enfoques principales que hay que tener en cuenta.
Cómo reutilizar los requisitos de forma eficaz
Tras ver los vídeos anteriores, resulta evidente que la herramienta Modern Requirements4DevOps Reuse es eficaz para reutilizar requisitos.
Ofrece un control total sobre los requisitos que se desean reutilizar, permite personalizarlos y vincularlos al elemento de trabajo de origen.
Esto significa que, independientemente de dónde quieras enviar los requisitos, puedes hacerlo utilizando la herramienta Modern Requirements4DevOps Reuse. Sin embargo, hay algunas formas de utilizar la herramienta Reuse de manera más eficaz.
Lo primero que cabe destacar es la combinación de la herramienta de reutilización con la herramienta «Modern Requirements4DevOps Baseline».
¿Qué es una línea de base?
Muchos equipos utilizan líneas de base de requisitos sin siquiera darse cuenta.
Una línea de base es una instantánea de los elementos de trabajo en un momento determinado.
Muchos equipos utilizan simplemente las versiones de los documentos de Microsoft Word como línea de base.
Cuando se trata de registrar los requisitos en un momento determinado, hay muchas razones por las que la función Modern Requirements4DevOps es mejor que el método tradicional de Microsoft Word. Con las líneas de referencia de Modern Requirements4DevOps, puedes registrar un conjunto de elementos de trabajo tal y como estaban en cualquier fecha que elijas.
Esto significa que, si quieres registrar tus requisitos tal y como estaban hace dos semanas, puedes crear fácilmente una línea de base para esos requisitos en esa fecha. Esto se traduce directamente en las ventajas de la herramienta de reutilización incorporada por Modern Requirements4DevOps.
Al combinar la herramienta «Reutilizar» con nuestra línea de base, no solo podrás seleccionar el conjunto de requisitos que deseas reutilizar, sino también la versión de dichos requisitos. Esto te permite trasladar la versión más adecuada y relevante de tus requisitos a tu próximo proyecto.
Otra recomendación importante es utilizar eficazmente el prefijo, el sufijo y otras operaciones al reutilizar los requisitos.
Al reutilizar requisitos, la herramienta Modern Requirements4DevOps Reuse te permite personalizar el aspecto que tendrán los requisitos reutilizados en el proyecto de destino.
A continuación se muestra la pantalla que te permite hacer esto:
El uso de esta función te permitirá añadir fácilmente un prefijo o un sufijo a los requisitos una vez que lleguen al proyecto de destino que hayas elegido. Como se ha visto anteriormente, también puedes optar por enviar estos requisitos a una ruta de área específica (como «hardware» o «software», por ejemplo), o incluso a una iteración determinada, para que puedas decidir cuándo se gestionarán dichos requisitos.
Sin embargo, la función más utilizada en las opciones de campo es la posibilidad de añadir una etiqueta.
A menudo, cuando se envían requisitos de un proyecto a otro, se desea poder identificarlos y rastrearlos fácilmente en el proyecto de destino. Añadir una etiqueta te permitirá hacerlo.
¿Cuál es la relación con la opción «Source Work Item»?
Esta opción te permite establecer un vínculo entre el elemento de trabajo que estás reutilizando y el elemento de trabajo que creas en tu proyecto de destino.
¿Qué enlace se crea?
Este enlace vincula tu nuevo elemento de trabajo de destino con el elemento de trabajo original a través del enlace «Relacionado» o cualquier otro tipo de enlace que hayas configurado en el área de administración.
En la imagen siguiente puedes ver un caso de prueba que he copiado de un proyecto a otro, utilizando tanto el prefijo «CL- » como la opción «Enlazar con el elemento de trabajo de origen».
Using the “Link to source work item” feature allows you to easily trace requirements back to where they were pulled from. While there are many use cases for this feature when moving requirements directly from project to project, this more advanced use cases are for when you are moving requirements from a library or repository into a project instead.
¿Cómo fusionar líneas de base copiadas?
Baseline es una herramienta muy útil, tanto si deseas reutilizar un único elemento de trabajo como una larga lista de elementos de trabajo de tu proyecto o biblioteca de origen. En Modern Requirements, puedes crear vínculos entre tu fuente y los elementos de trabajo copiados, de modo que puedas localizar el origen de dichos elementos.
Aunque existan vínculos entre ellos, los elementos de trabajo copiados se siguen considerando independientes de los elementos de trabajo originales, lo que significa que cualquier cambio que realices en los elementos de trabajo copiados o en los originales no afectará a su homólogo.
Quizás te preguntes: ¿cómo sincronizar los cambios cuando sea necesario? Supongamos que tienes una biblioteca en la que se guardan todos tus elementos de trabajo de especificaciones de diseño y que los has reutilizado en 5 proyectos diferentes. Si ahora tienes que modificar algunos diseños de la biblioteca y quieres que todas las especificaciones de diseño copiadas se sincronicen, solo tienes que utilizar la función «Combinar», que se encuentra en «Líneas de base de origen copiadas» o «Líneas de base de destino copiadas» en la pestaña «Detalles» del módulo «Líneas de base».
Baseline es una herramienta muy útil, tanto si deseas reutilizar un único elemento de trabajo como una larga lista de elementos de trabajo de tu proyecto o biblioteca de origen. En Modern Requirements, puedes crear vínculos entre tu fuente y los elementos de trabajo copiados, de modo que puedas localizar el origen de dichos elementos.
Aunque existan vínculos entre ellos, los elementos de trabajo copiados se siguen considerando independientes de los elementos de trabajo originales, lo que significa que cualquier cambio que realices en los elementos de trabajo copiados o en los originales no afectará a su homólogo.
Quizás te preguntes: ¿cómo sincronizar los cambios cuando sea necesario? Supongamos que tienes una biblioteca en la que se guardan todos tus elementos de trabajo de especificaciones de diseño y que los has reutilizado en 5 proyectos diferentes. Si ahora tienes que modificar algunos diseños de la biblioteca y quieres que todas las especificaciones de diseño copiadas se sincronicen, solo tienes que utilizar la función «Combinar», que se encuentra en «Líneas de base de origen copiadas» o «Líneas de base de destino copiadas» en la pestaña «Detalles» del módulo «Líneas de base».
¿Recuerdas aún la definición de una línea de base? Es una instantánea de determinados elementos de trabajo en un momento dado. Por lo tanto, independientemente de los cambios que hayamos realizado en los elementos de trabajo incluidos en la línea de base, la instantánea guardada no cambiará. Así pues, aunque hayamos fusionado las líneas de base, los cambios se aplican a las últimas versiones de los elementos de trabajo, no a las propias líneas de base. ¿Te parece un poco difícil de entender?
Por favor, vea el vídeo de 5 minutos titulado «Fusionar líneas de base copiadas».
Want to experience reuse’s full potential?
Prueba hoy mismo Modern Requirements4DevOps de forma gratuita.
Te ofrecemos la posibilidad de probar nuestra solución de gestión de requisitos en tu propio entorno de Azure DevOps o en un entorno que te proporcionamos y que incluye datos de ejemplo.
Índice
Artículos recientes
Notificación de incidencias
Learn how to easily output requirements and assets in either...
Panel de administración de Modern Requirements
Learn how to effectively use the Modern Requirements admin panel...
Reutilización de requisitos
Reusing Requirements January 2, 2020 Reading Time: 8 minutes Learn...
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:
- Requisitos para importar desde Microsoft Excel
- Requisitos para importar desde Microsoft Word
- 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:
- Abrir Excel
- Crear una hoja en blanco
- Haz clic en «Archivo»
- Haz clic en «Opciones»
- Haz clic en «Complementos»
- Selecciona «Complementos COM» en el menú desplegable situado en la parte inferior de la ventana
- 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!
¿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í!
El módulo de preguntas frecuentes
El módulo de preguntas frecuentes
La solución para la recopilación inicial de requisitos
En este artículo repasamos las características y ventajas del módulo de preguntas frecuentes.
Este módulo se ha diseñado para ayudar a los equipos que recopilan requisitos al inicio de su proceso de gestión de requisitos. Al crear listas de preguntas, los equipos pueden recopilar y reutilizar fácilmente sus conocimientos sobre el proceso de obtención de requisitos para formular las preguntas adecuadas que permitan obtener los mejores requisitos.
¿Qué es el módulo de preguntas frecuentes?
El módulo de preguntas frecuentes es un repositorio de listas de preguntas que tu equipo puede crear, editar, modificar, convertir en plantillas y utilizar para recabar requisitos. Al utilizar el módulo de preguntas frecuentes para crear una base de conocimientos para tu equipo, tendrás la seguridad de que cualquier miembro del equipo podrá interactuar con las partes interesadas de manera eficaz.
Al elaborar el mejor conjunto de preguntas en ese ámbito, tu equipo podrá asegurarse de que siempre recaba el mejor conjunto posible de requisitos.
La principal ventaja de este módulo es que ofrece a tu equipo la oportunidad de crear una base de conocimientos que pueden utilizar tanto los analistas de negocios con experiencia como aquellos que puedan necesitar recabar requisitos en un ámbito que no les resulte familiar. El módulo de preguntas frecuentes ya incluye más de 3000 preguntas que abarcan una gran variedad de temas.
Entre estos temas se incluyen varias plantillas de cumplimiento de normas ISO, así como plantillas sobre requisitos no funcionales, como la escalabilidad, la reutilización o la operatividad, que pueden utilizarse para la obtención de requisitos.
Para muchos equipos, este módulo sustituirá a las listas de preguntas en Excel que quizá hayan utilizado en el pasado.
Para mantener la coherencia con el resto de módulos del conjunto de herramientas Modern Requirements, el módulo de preguntas frecuentes toma lo que antes era un proceso aislado y lo integra directamente en tu proyecto. Esto significa que tus equipos pueden añadir fácilmente requisitos al proyecto con solo responder a las preguntas de la lista de preguntas frecuentes.
¿Qué ventajas ofrece el módulo de preguntas frecuentes?
El valor de nuestro módulo de preguntas frecuentes se puede resumir en dos puntos sencillos.
- El módulo de preguntas frecuentes ayuda a definir mejor los requisitos al orientar el proceso de recopilación de los mismos, lo que aumenta las probabilidades de éxito del proyecto.
- El módulo de preguntas frecuentes reduce el tiempo dedicado a la recopilación de requisitos a lo largo del proyecto, lo que permite a tu equipo empezar a desarrollar antes.
Aprovechando los valiosos conocimientos de los analistas de negocios con experiencia, puedes crear plantillas de preguntas específicas para cada ámbito que ayuden a estructurar el proceso de recopilación de requisitos. Esto significa que puedes enviar a cualquier analista de negocios, independientemente de su nivel de experiencia, a reunirse con una parte interesada y tener la seguridad de que elaborará unos requisitos completos y aplicables.
Al no tener que crear plantillas de preguntas y copiar después los requisitos recopilados en tu herramienta de gestión de requisitos, tu equipo podrá avanzar más rápidamente en el proceso de recopilación. Esto se traduce en más tiempo dedicado a perfeccionar requisitos más precisos y menos tiempo dedicado a copiar y pegar historias de usuario que probablemente requieran más trabajo.
¿Cuáles son los casos de uso del módulo de preguntas frecuentes?
Cuando hablamos con nuestra comunidad sobre el uso que hacen del módulo de preguntas frecuentes, suelen describir cómo este módulo les ha permitido agilizar sus procesos y ha facilitado la gestión de la fase de recopilación de información de los proyectos.
Incluso los equipos que tradicionalmente no utilizan listas de preguntas, una vez que se unen a nuestra comunidad, nos comentan el gran valor añadido que les supone poder reunir los conocimientos de todos los miembros de su equipo en una única lista coherente.
Estos son los casos de uso que hemos observado para el módulo de preguntas frecuentes.
CASO DE USO 1
Actualmente, mi equipo recopila los requisitos al principio y, a partir de ahí, avanza de forma iterativa a lo largo del proyecto. En la fase de recopilación de requisitos utilizamos Excel, pero eso implica que después tenemos que copiar los requisitos a la herramienta que utilizamos habitualmente.
Al ser un equipo que recopila los requisitos desde el principio, esto nos brinda una oportunidad perfecta para utilizar una lista de preguntas diseñada específicamente para ese ámbito. Sin embargo, recurrir a Excel como herramienta para gestionar esta lista de preguntas es sinónimo de un largo proceso de copiar y pegar más adelante.
Los procesos de copiar y pegar suelen ser propensos a errores y llevar mucho tiempo. A menudo, es precisamente durante estos procesos, ya de por sí largos, cuando un miembro del equipo se da cuenta de que se le ha pasado por alto una propiedad de una tarea sobre la que necesita la opinión de las partes interesadas.
En este caso, al utilizar el módulo de preguntas frecuentes, ya dispondrás de la lista de preguntas en tu proyecto de Azure DevOps. Cuando plantees tu pregunta a las partes interesadas, podrás responderla en tu lista de preguntas frecuentes y se creará automáticamente un requisito.
De este modo, podrás abrir directamente ese requisito y plantear cualquier pregunta de seguimiento que te surja mientras sigues hablando con la parte interesada. Esto ahorra tiempo y hace que el proceso de recopilación de requisitos sea más exhaustivo, al tiempo que evita que tu equipo pierda oportunidades de obtener la información adecuada en el momento oportuno.
CASO DE USO 2
Mi equipo trabaja en un ámbito sujeto a normativas y regulaciones, y debemos asegurarnos de que cumplimos con todos los requisitos necesarios para mantener el cumplimiento normativo y la auditabilidad.
Una de las mejores características del módulo de preguntas frecuentes es que permite utilizar muchas de nuestras plantillas prediseñadas relacionadas con el cumplimiento normativo para recabar requisitos. Nuestras plantillas prediseñadas se han creado en colaboración con muchos de nuestros clientes actuales, así como a través de colaboraciones con líderes de opinión en estos ámbitos.
En este caso, los equipos que tengan acceso al módulo de preguntas frecuentes pueden consultar a expertos en la materia y a consultores, y elaborar una lista de preguntas que les ayude a definir todos los requisitos necesarios para cumplir con la normativa. Una vez creadas, estas listas de preguntas pueden reutilizarse en varios proyectos y aplicarse una y otra vez.
¿Cómo puedo utilizar el módulo de preguntas frecuentes de forma eficaz?
El módulo de preguntas frecuentes ofrece ventajas increíbles a los equipos que se encuentran en la fase de definición de requisitos de su proyecto. A continuación se indican algunas formas en las que puede utilizar el módulo para facilitar el éxito del proyecto.
Utiliza las plantillas de listas de preguntas ya preparadas
Cuando los usuarios necesiten una plantilla sobre requisitos no funcionales o sobre temas relacionados con la norma ISO, pueden ponerse en marcha rápidamente utilizando una de nuestras plantillas integradas. Estas plantillas ya incluyen muchas de las preguntas más importantes sobre estos temas. Los usuarios pueden partir de una plantilla prediseñada y eliminar las preguntas que no sean pertinentes o añadir las nuevas que sean necesarias.
Crea tus propias plantillas de listas de preguntas
Si ninguna de nuestras plantillas prediseñadas se ajusta a tus necesidades, los equipos pueden crear fácilmente listas de preguntas desde cero. Al partir de una plantilla en blanco, tu equipo podrá elaborar fácilmente un conjunto completo de preguntas que harán que la recopilación de requisitos sea un proceso sencillo y más eficiente.
Una vez elaborada la lista de preguntas, se puede reutilizar en distintos proyectos para facilitar la fase de recopilación de información en el futuro.
Crea listas de preguntas para los miembros menos experimentados de tu equipo
Al elaborar listas de preguntas, estás ofreciendo una orientación útil a cualquier miembro del equipo que no esté tan familiarizado con un ámbito, una solución o un sistema. Estas listas constituyen, por tanto, una herramienta excelente para orientar a los analistas de negocios noveles, o a los que cuentan con experiencia en otros ámbitos, durante la fase de obtención de requisitos. Los equipos son conscientes de que la calidad de las preguntas que formulamos al inicio de un proyecto se refleja directamente en la calidad de los requisitos que obtenemos.
Al crear listas de preguntas con nuestro módulo de preguntas frecuentes, te aseguras de obtener los requisitos más adecuados desde el primer momento.
Servicios MR: Monitor de correo electrónico, ID personalizado, indicador de mensajes no leídos
En este artículo repasamos algunas de las funciones adicionales que están disponibles en la edición Enterprise Plus de Modern Requirements4DevOps. Estas funciones se denominan «MR Services».
Continuar leyendoUso de Alice: Asistente de BA
Este módulo, inspirado en la inteligencia artificial, se ha diseñado para ayudar a tu equipo a recabar requisitos con rapidez.
Continuar leyendoConfiguració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).
Tiempo de lectura: 25 minutos
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:
- Identificación personalizada
- Bandera sucia
- 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.
ÍNDICE
- Autenticación de usuarios de MR Services
- Identificación manual de un nuevo proyecto en las organizaciones ADO
- Configuración de identificadores personalizados
- Configuración de la función «Dirty Flag»
- Configuración de la función de supervisión del correo electrónico
- Contactar con el servicio de asistencia
Autenticación de usuarios de MR Services
- 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.
- 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.
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.
- 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:
- Escribe el siguiente comando en el símbolo del sistema: cd :\Archivos de programa\Modern Requirements\MR-Agent\bin
- Una vez en el directorio «bin», introduce el siguiente comando: MRAgent
Se muestra el menú de opciones.
- Tipo 4 y pulsa Intro.
- 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:
- Una carpeta que lleva el nombre del servidor de Azure DevOps (TFS) (en el que es necesario aplicar el ID personalizado).
- 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.
- Crea una carpeta con el nombre del servidor de Azure DevOps (en el que se debe aplicar el componente) en esta ubicación.
- 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).
- 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
- Abre el xml archivo en el Bloc de notas o en cualquier editor de texto.
- 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. - 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.
- 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 «\»).
- “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.
- 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.
- “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.
- 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.
- 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 - 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.
- 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
- Escribe el siguiente comando en el símbolo del sistema: cd :\Archivos de programa\Modern Requirements\MR-Agent\bin
- Una vez en el directorio «bin», introduce el siguiente comando: MRAgent
Se muestra el menú de opciones.
- Tipo 1 y pulsa Intro.
- Introduce la URL de la organización de Azure DevOps (o de la colección de TFS).
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:
- Una carpeta que lleva el nombre del servidor de Azure DevOps (TFS) (en el que se debe aplicar el indicador «Dirty»).
- 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.
- Crea una carpeta con el nombre del servidor de Azure DevOps (TFS) (en el que se debe aplicar el componente) en esta ubicación.
- 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.
- 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»
- Abre el xml archivo en el Bloc de notas o en cualquier editor de texto.
- 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.
- 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 «,».
- La etiqueta«FieldReferenceName»indica qué campo o campos del elemento de trabajo (la lista se proporciona en la etiqueta WIType ) se comprobarán.
- 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».
- 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.
- 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*:
- Configuración del archivo de configuración del monitor de correo electrónico (ubicado en una ubicación concreta)
- 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:
- 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.
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- 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
- Funciona con todos los componentes de MR Services
- Se utiliza para revisar nuevos proyectos o colecciones
- 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
- Solo funciona con un ID personalizado
- Se utiliza para asignar un identificador personalizado a los elementos de trabajo recién creados
- 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
- Solo funciona con Email Monitor
- Se utiliza para comprobar si ha llegado un nuevo correo electrónico a partir del cual se puedan crear o actualizar tareas
- 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:
- 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.
- Crea una carpeta con el nombre del servidor de Azure DevOps (TFS) (en el que se debe aplicar el componente) en esta ubicación.
- 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).
- Este archivo contiene el esquema de la configuración deseada.
Configuración del archivo XML del monitor de correo electrónico
- Abre el xml archivo en el Bloc de notas o en cualquier editor de texto.
- Define el valor de la URL del servidor etiqueta según sea necesario, por ejemplo:
- 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. - 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.
- “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
- 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.
- 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».
- 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.
- OnCreate= ”true” means that the title would be set from the email’s subject only for new Work Items.
- OnUpdate=”false” significa que, en el caso de los elementos de trabajo existentes, el campo «Título» no se actualizaría.
- 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.
- 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.
- 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.
La última parte de este campo indica la composición del campo «Descripción». La siguiente información conformaría el campo «Descripción»:
- Sender Name shown inside <> e.g.
- Sender Email also shown inside <> e.g. <alice.ducas@steveandrews.com>
- El cuerpo del correo electrónico se ha añadido en una nueva línea
- 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.
- Una vez completada correctamente la configuración del archivo, guárdelo y ciérrelo.
- 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.
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
Contactar con el servicio de asistencia
El panel de administración de Modern Requirements4DevOps
En este artículo explicamos cómo utilizar el panel de administración de Modern Requirements4DevOps para activar y desactivar funciones concretas en cada módulo de MR4DevOps.
Continuar leyendoActivación de Modern Requirements4DevOps
En este artículo explicamos los sencillos pasos que deben seguir los equipos para activar Modern Requirements4DevOps, tanto en nuestra versión integrada como en la independiente.
Continuar leyendo
