Gestiona fácilmente el cumplimiento de la norma ISO 26262 al tiempo que aceleras el ciclo de desarrollo
Continuar leyendoGestión del cumplimiento de la norma ISO 26262 con los requisitos actuales
Ya está disponible: Modern Requirements4DevOps, actualización 1
En este blog vamos a compartir algunas de las novedades más destacadas que hemos introducido en algunos de nuestros módulos, así como algunas mejoras en las herramientas de Modern Requirements, para tu comodidad.
Continuar leyendoSuperar los retos habituales de la gestión de requisitos mediante MR4DevOps
En esta entrada, te mostraremos cómo algunas empresas están superando todos los retos del desarrollo de productos gracias a una sencilla solución de gestión de requisitos: Modern Requirements4DevOps.
Continuar leyendoSmart Doc – Módulo de formación
Como administrador, puedes controlar cómo los usuarios acceden e interactúan con sus proyectos de Modern Requirements4DevOps mediante la aplicación de ajustes de administración.
Continuar leyendoExporta los resultados de tus pruebas con Modern Requirements4DevOps
Como administrador, puedes controlar cómo los usuarios acceden e interactúan con sus proyectos de Modern Requirements4DevOps mediante la aplicación de ajustes de administración.
Continuar leyendoCómo funciona el panel de administración: licencias y configuraciones de módulos
Como administrador, puedes controlar cómo los usuarios acceden e interactúan con sus proyectos de Modern Requirements4DevOps mediante la aplicación de ajustes de administración.
Continuar leyendoParticipa en la redacción de requisitos mediante Email Monitor
Participa en la redacción de requisitos mediante Email Monitor
La función «Email Monitor» permite crear elementos de trabajo en tu proyecto de Azure DevOps a través de un medio que no es nativo de Azure DevOps. Es decir, te permite comunicarte con tu proyecto por correo electrónico. A menudo, los equipos se encuentran con situaciones en las que intercambian correos electrónicos sobre requisitos, solicitudes de cambio o errores que deben registrarse, y con frecuencia pueden utilizar los correos electrónicos para llegar a un requisito definitivo que debe añadirse a su proyecto.
Con la función «Email Monitor», tu equipo ya puede convertir directamente esta comunicación externa en una tarea.
Para conocer los casos de uso y el proceso de configuración de Email Monitor, vea el vídeo.
Puedes acceder a la página de configuración de Email Monitor yendo a Configuración de la colección/Administración – Extensión Modern Requirement4DevOps – Servicios – Email Monitor.
Al habilitar la función «Monitor de correo electrónico» en el panel de la extensión Modern Requirements4DevOps, puedes especificar una dirección de correo electrónico de monitorización que permita interceptar y crear cualquier elemento de trabajo que se le envíe por correo electrónico. Dado que el sistema intentará capturar todos los correos electrónicos enviados a la dirección de correo electrónico de monitorización, es recomendable utilizar dicha dirección exclusivamente para la función de monitor de correo electrónico.
También es necesario que facilites una dirección de correo electrónico de administrador por si acaso el sistema no pudiera reconocer los correos electrónicos, en cuyo caso se enviará una notificación a dicha dirección.
Puedes especificar qué tipos de elementos de trabajo deseas crear en tu proyecto a partir de esos correos electrónicos capturados.
Los asuntos de los correos electrónicos enviados a la dirección de correo electrónico del Monitor siempre se asignarán a los títulos de los elementos de trabajo que se vayan a crear.
«Proyecto del equipo (predeterminado) » te permite elegir un proyecto predeterminado al que quieras añadir los elementos de trabajo.
Las opciones «Creación de complementos » y «Actualización de complementos » te permiten configurar cuándo deseas añadir el requisito al proyecto.
Para el campo «Descripción»:
Si la opción «Crear elemento de trabajo» está marcada, significa que el sistema utilizará el correo electrónico inicial para crear un nuevo elemento de trabajo y que el cuerpo del correo se convertirá en la descripción de dicho elemento.
Si la opción «Añadir en la actualización» está marcada, significa que la descripción actual del elemento de trabajo creado quedará sustituida por futuras respuestas relacionadas con ese mismo elemento de trabajo.
Para el campo de Historia：
Si la opción «Crear complemento» está marcada, significa que el cuerpo del correo electrónico inicial se asignará a la sección «Discusión» del elemento de trabajo creado.
Si la opción «Añadir a la actualización » está marcada, todas las respuestas intercambiadas en relación con el mismo elemento de trabajo se añadirán a la sección «Discusión».
Los campos «Nombre del remitente», «Correo electrónico del remitente» y «Cuerpo del correo electrónico » te permiten configurar el contenido que deseas añadir en la sección «Descripción» o «Debate» correspondiente.
Caso de uso del servicio de supervisión del correo electrónico
El caso de uso más habitual de la función «Email Monitor» es el siguiente:
Tengo una organización grande y me gustaría que todos los miembros de mi organización añadieran los errores que encuentren en mi software a mi proyecto de Azure DevOps.
Una vez que Email Monitor esté completamente configurado con bugs@myorganization.com, cualquier persona interesada podrá simplemente enviar un correo electrónico a bugs@myorganization.com y así se creará una entrada de error en mi proyecto.
Al mismo tiempo, el correo electrónico que ha dado lugar a la creación del error también se envía a las personas pertinentes de ese proyecto. Los miembros pertinentes pueden ahora participar en el debate sobre ese elemento de trabajo por correo electrónico, y todas las comunicaciones por correo electrónico se añadirán a las propiedades de «Debate» de ese elemento de trabajo dentro de tu proyecto.
Esta función única permite a otras personas contribuir al éxito de tu proyecto sin necesidad de tener acceso completo a tu proyecto de Azure DevOps. Ahora, personas externas pueden participar en el debate sobre un elemento de trabajo sin que sea necesario que les concedas acceso a tu proyecto.
Otros escenarios que podrían interesarte
Añadir elementos de trabajo a proyectos distintos del proyecto predeterminado
Si el remitente no especifica un nombre de proyecto concreto en el cuerpo del correo electrónico, el correo asignado se añadirá al proyecto predeterminado. Si los remitentes desean añadir el requisito a otro proyecto de la misma colección, deberán incluir [ProjectName=GCD] en el cuerpo del correo electrónico (GCD es un nombre de proyecto de ejemplo).
Varios tipos de elementos de trabajo
Entendemos que las partes interesadas de su proyecto pueden querer añadir más de un tipo de elemento de trabajo mediante el uso del Monitor de correo electrónico. ¡Esto también es posible! Basta con seleccionar varios tipos de elementos de trabajo. Por ejemplo, ahora selecciono «User Story» además de «Bug». Cuando su equipo envíe correos electrónicos al buzón del monitor, puede utilizar [WIT=bug] o [WIT=user story] en el cuerpo del correo para especificar a qué tipo de elemento de trabajo debe pertenecer el requisito creado. Si no se especifica el tipo de elemento de trabajo en el cuerpo del correo electrónico, el sistema intentará asignar el correo electrónico al tipo de elemento de trabajo que se corresponda con la categoría de elementos de trabajo que haya seleccionado en la sección «Categoría de elementos de trabajo ».
Añadir contenido adicional a un elemento de trabajo existente
Una vez que el sistema ha registrado el correo electrónico inicial, por defecto, todas las respuestas posteriores se pueden añadir como comentarios del mismo elemento de trabajo. Además, los remitentes pueden incluir [wiid=1997] (siendo 1997 un ID de elemento de trabajo de ejemplo) en el cuerpo del correo electrónico para añadir nuevo contenido al elemento de trabajo existente en cuestión.
Por supuesto, puedes utilizar más de uno de esos comandos especiales en un correo electrónico, según tus necesidades.
Gestión de requisitos sospechosos mediante el marcado automático
Gestión de requisitos sospechosos mediante el marcado automático
«Dirty Flag / Suspect Link» es un componente de MR Services (antes denominado MR Agent) que se utiliza para identificar elementos de trabajo que podrían verse afectados por la modificación de un elemento de trabajo vinculado, de modo que las partes interesadas pertinentes puedan revisar dichos elementos. Por ejemplo, si una historia de usuario cambia de estado a «activo», los casos de prueba relacionados se marcarían como sospechosos.
La función «Suspect Link» contribuye al éxito de tu proyecto al permitir consultar el impacto de los cambios en los elementos de trabajo y, en general, hacerlo más evidente. Puedes considerar esta función como un método para evaluar el impacto de los cambios en los elementos de trabajo dentro de tu proyecto.
¿Cómo funciona Dirty Flag / Suspect Link?
Esta función te permite supervisar los elementos de trabajo que cumplen determinadas condiciones previas. Cuando estos elementos de trabajo cambian, la función de supervisión marcará como sospechosos todos los elementos de trabajo vinculados.
Veamos un ejemplo:
La historia de usuario 1 acaba de pasar al estado «Completada». Si es posible configurar Suspect Link para que active una alerta cada vez que se realice algún cambio en las historias de usuario que se encuentren en estado «Completada» (por ejemplo, un cambio en un campo como «Descripción»).
Esto significa que, si en el futuro se modifica el campo «Descripción» de la historia de usuario 1, todos los requisitos vinculados a ella quedarán marcados con un indicador de modificación.
Esto permite a tu equipo detectar fácilmente si cambia un requisito que cumple con un determinado conjunto de criterios (que tú especificas). Una vez detectado, los elementos de trabajo configurados que estén directamente vinculados se marcarán como «Dirty/Suspect».
Siguiendo con nuestro ejemplo, si cambiara el campo «Descripción» de la historia de usuario 1, podríamos marcar como «en espera» todos los casos de prueba vinculados directamente que pudieran necesitar modificarse para comprobar los nuevos criterios.
Los indicadores de error que se activan en esos casos de prueba adoptarían la forma de una etiqueta de elemento de trabajo.
Las etiquetas aparecen en el editor de elementos de trabajo estándar de Azure DevOps. También puedes personalizar las opciones de columnas en el módulo «Elementos de trabajo y backlogs» para ver un grupo de elementos de trabajo, algunos de los cuales pueden estar marcados con el indicador «Dirty».
En el caso de la etiqueta «Dirty Flag» que se aplica a los elementos de trabajo, dicha etiqueta incluye tanto el ID del elemento de trabajo modificado como su revisión, de modo que tu equipo pueda identificar fácilmente qué requisito se modificó y activó la funcionalidad de la etiqueta «Dirty» o el enlace «Suspect».
Las marcas de «Dirty Flag» pueden eliminarse manualmente una vez que las partes interesadas pertinentes hayan revisado el impacto y realizado las actualizaciones necesarias. La mejor práctica que recomendamos en este caso es añadir otro comentario en el que se explique que la marca «Dirty Flag» se ha eliminado porque se han llevado a cabo las actualizaciones necesarias o porque no se requieren actualizaciones.
Para obtener más información y conocer el proceso de configuración de Dirty Flag/Suspect Link, vea el vídeo.
Cómo hacer que sus ID de requisitos sean más descriptivos y distintivos utilizando ID personalizados
Mejora la claridad y la distinción de tus ID de requisitos utilizando el ID personalizado en Modern Requirements4DevOps.
Continuar leyendoIntroducción a la gestión de derechos
Introducción a la gestión de derechos
¿Qué es la gestión de derechos?
La gestión de derechos es una nueva función de la versión MR2020 que permite controlar el acceso de los usuarios. El administrador del proyecto puede conceder o denegar a un grupo de usuarios el acceso a un módulo de MR y a sus funcionalidades. Actualmente, la gestión de derechos está disponible para tres módulos de MR: Smart Docs, Baseline y Reporting.
Las ventajas de utilizar la gestión de derechos
Los permisos flexibles y personalizables permiten a los equipos de proyecto mantener el equilibrio adecuado entre colaboración y control.
Cada vez que se produzca un cambio en los permisos, este afectará inmediatamente a todos los equipos o grupos de usuarios a los que se hayan asignado dichos permisos. Esto garantiza que la configuración de los permisos se pueda actualizar y mantener fácilmente a medida que avanzan los proyectos y los equipos cambian de funciones.
Cómo acceder a la gestión de derechos
Se puede acceder a la gestión de derechos desde la extensión Modern Requirements4DevOps, en la sección «Configuración del proyecto».
Características del grupo
Las funciones disponibles para las que puedes configurar permisos varían de un módulo a otro.
Las funciones de grupo disponibles son las siguientes:
- Crear/Editar carpeta
- Eliminar carpeta
- Crear/Actualizar artefacto
- Eliminar artefacto
- Crear/Actualizar plantilla de metadatos
- Guardar como plantilla
- Generación inteligente de informes
- Diseñador inteligente de informes
Selección de permisos
Por lo general, hay tres tipos de permisos de acceso entre los que elegir para cada función de grupo:
«Permitir»
«Negar»
«Sin definir»
- «Permitir»: concede explícitamente a los usuarios permiso para acceder a una función de grupo en los módulos MR.
- «Denegar»: Impide explícitamente a los usuarios acceder a una función de grupo en los módulos de realidad mixta.
- «No definido»: impide implícitamente a los usuarios acceder a una función de grupo en los módulos de realidad mixta.
Permisos heredados
Los equipos y grupos pueden heredar automáticamente la configuración de permisos de los equipos y grupos principales. La configuración de permisos modificada explícitamente en los equipos y grupos secundarios puede anular los permisos heredados de los equipos y grupos principales. Ten en cuenta las siguientes reglas:
- Los valores «Permitir» heredados se pueden anular y cambiar a «Denegar».
- El valor heredado «No establecido» se puede anular y cambiarlo a «Permitir» o «Denegar».
- El valor «Denegar» heredado no se puede anular y cambiar a «Permitir».
Conflictos de permisos
Cuando un mismo usuario forma parte de más de un equipo o grupo, se aplican las siguientes reglas:
- La opción «Denegar» tiene prioridad sobre «Permitir».
- «Denegar» tiene prioridad sobre «Sin definir».
- «Permitir» tiene prioridad sobre «Sin definir».
¡No te pierdas el vídeo tutorial detallado sobre la gestión de derechos!
Si tiene alguna pregunta o sugerencia sobre la gestión de derechos, póngase en contacto con su representante de éxito del cliente de Modern Requirements y estaremos encantados de colaborar con usted para explorar esta función.
