SGPC RELATOS DE USUARIO Laboratori Enginyeria Software : Especificació Llenguatges i Sistemes Informàtics Cuatrimestre Primavera 03/04 Lengutges i Sistemes Informatics Laboratori Enginyeria del Software : Especificacio SGPC Relatos de Usuario Cuatrimestre Primavera 03/04 CONTENIDO 2 1.1 Propósito ............................................................................................................................................................................ 4 1.2 Alcance............................................................................................................................................................................... 4 1.3 Organización del documento ........................................................................................................................................... 4 Gestion Peticion de Cambio ..................................................................................................................... 5 2.1 Usuario tipo ....................................................................................................................................................................... 5 2.2 Relato ................................................................................................................................................................................. 5 3 de 4 Lengutges i Sistemes Informatics Laboratori Enginyeria del Software : Especificacio SGPC Relatos de Usuario Cuatrimestre Primavera 03/04 1.1 Propósito En este documento se describen distintos escenarios de interacción o historias propuestos por los usuarios tipo del sistema Describe un conjunto historias que relatan interacciones entre los usuarios y el sistema. Es la fuente de la que se extraerán los casos de uso. Estas historias se recogieron hablando directamente con los posibles usuarios de sistema. Estas historias representan lo que los usuarios esperan del sistema y es la fuente de la que se extraerán los casos de uso. 1.2 Alcance Únicamente se muestran las historias más significativas para la definición de los casos de uso del proyecto. 1.3 Organización del documento El documento esta dividido en diferentes secciones, una por cada conjunto de relatos con un mismo significado de valor para un usuario tipo o característico del sistema. En cada una de dichas secciones se describe al usuario tipo y los relatos de interacción 4 de 4 Lengutges i Sistemes Informatics Laboratori Enginyeria del Software : Especificacio SGPC Relatos de Usuario Cuatrimestre Primavera 03/04 2 GESTION PETICION DE CAMBIO {Nota: solo se documenta un relato de usuario que muestra la perspectiva de la automatización requerida durante todo el proceso de gestión del cambio} 2.1 Usuario tipo Se trata de cualquier participante del proyecto que en función de su role en el proyecto participa en el proceso de gestión del cambio. 2.2 Relato Un Participante del Proyecto accede al sistema, localiza el proyecto de la lista de proyectos en los que participa y selecciona el artefacto y versión del mismo sobre el que se emite la petición de cambio, completa el formulario de emisión y la introduce en el sistema. Una vez que una petición de cambio esta emitida se registra en la cartera de peticiones. Periódicamente, r días (por defecto, pero configurable) antes de la fecha fijada (también por defecto) para la de realización de las asambleas, el sistema recuerda al Representante del CCC la necesidad de llevar a cabo una Asamblea de revisión del cartera. En función de la prioridad y el número de peticiones de cambio (ambos previamente fijados) que están pendientes en la cartera de revisión se puede adelantar la notificación electrónica al Representante del CCC, indicando la necesidad de realizar una asamblea urgente de revisión. En cualquiera de los casos el Representante del CCC planifica dicha asamblea, seleccionado participantes del proyecto tanto integrantes del CCC como otros. El día de la asamblea (2h antes, configurable) envía un recordatorio a cada asistente. El sistema accede a SGD y obtiene el impacto estimado en base a las dependencias existentes. También, teniendo en cuenta el artefacto sobre el que aplica, y el impacto calculado, propone una lista preliminar de posibles peticiones de cambio equivalentes ya existentes que tratan en el cambio propuesto. El día de la asamblea el CCC accede al sistema y obtiene el impacto calculado, y la lista de peticiones equivalentes ya existentes , lleva a cabo el análisis de la petición de cambio y completa el formulario combinado. La decisión (Aceptada, Rechazada, Duplicada) se introduce en el sistema y en base a ella cambia de estado, notificando la asignación de una nueva tarea según el proceso de gestión de PCs. Si la petición de cambio es aceptada se asignan participantes del proyecto para su resolución y pruebas/revisión de la misma (participantes asignados y testers) Si la petición es rechazada se registra en al cartera para su confirmación posterior. Cuando se realiza la confirmación de rechazo/duplicado se notifica, via Inbox, al emisor. Si el motivo del rechazo es que hace falta mas información, se notifica igualmente via (Inbox) la necesidad de la misma Si la petición se postpone se registra en la cartera para su revisión con una fecha futura. Cuando se alcanza dicha fecha el sistema activará de nuevo la petición de cambio, notificando su emisión al representante del CCC, como si hubiese sido emitida en ese momento. En la resolución, evaluación y verificación de la PC, cada participante completa el formulario combinado de la PC según proceda. El cierre de la PC se notifica Inbox del Emisor. 5 de 4