Relatos de Usuario - Departament d`Enginyeria de Serveis i

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