SGPC RELATOS DE USUARIO LABORATORI ENGINYERIA SOFTWARE

10 OS MUÇULMANOS DOS RELATOS DE PEREGRINAÇÃO DOS SÉCULOS
13 LOS RELATOS FANTÁSTICOS DE ADOLFO BIOY CASARES ESAS
1º CERTAMEN NACIONAL DE RELATOS CORTOS “DR GUERRERO PABÓN”

42 ARQTO ROBERTO PAGURA CUENTOS NOTAS Y RELATOS DE
ADAPTACIÓN DE DOS RELATOS DE JOAQUÍN COLLANTES LAS CUATRO
BASES CONCURSO DE MICRORRELATOS “DON QUIJOTE EN EL SIGLO

Relatos de Usuario

SGPC  RELATOS DE USUARIO  LABORATORI ENGINYERIA SOFTWARE











SGPC







Relatos de Usuario
















Laboratori Enginyeria Software : Especificació

Llenguatges i Sistemes Informàtics


Cuatrimestre Primavera 03/04


contenido

1.1 Propósito 3

1.2 Alcance 3

1.3 Organización del documento 3

2 Gestion Peticion de Cambio 4

2.1 Usuario tipo 4

2.2 Relato 4



1.1Propó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.2Alcance

Únicamente se muestran las historias más significativas para la definición de los casos de uso del proyecto.

1.3Organizació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



2Gestion 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.1Usuario 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.2Relato

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.


BASES CONCURSO LITERARIO DE RELATOS LOCALES DÍA DEL PATRIMONIO
CACE 2004 9º CONCURSO DE RELATOS LA DISCAPACIDAD Y
CACE 2006 11º CONCURSO DE RELATOS LA DISCAPACIDAD Y


Tags: enginyeria software, laboratori, software, relatos, usuario, enginyeria