Visión
SGPC
Vision
Laboratori Enginyeria Software : Especificació
Llenguatges i Sistemes Informàtics
Cuatrimestre Primavera 03/04
contenido
41Introduccción
41.1Propósito
41.2Definiciones, Acrónimos, y Abreviaciones
41.3Referencias
41.4Organización del documento
52Posicionamiento
52.1Oportunidad de Negocio
62.2Definición del Problema
73Descripción de Usuarios
94Perspectiva del Producto
105CaracterÍstIcas del Producto
105.1Autentificación de usuarios
105.2Multi-proyecto
105.3Integración con SCP, SCV, SDP
105.4Gestión automática del flujo del proceso
105.5Generación e Impresión de informes seguimiento
105.6Activación automática de PCs pospuestas
105.7Notificación del Estado PC
105.8Gestión automática de asambleas
116Otros Requisitos
116.1Rendimiento y Fiabilidad
116.2Requisitos Software
116.3Requisitos Hardware
1 Introduccción
1.1 Propósito
El propósito de este documento es definir los objetivos, alcance y características de SGPC. El documento se centra en las capacidades del sistema que necesitan los potenciales usuarios y las partes interesadas (stakeholders) del proyecto, y el por qué estas necesidades existen. Los detalles de cómo SGPC cubrirá dichas necesidades se detallarán en el modelo de casos de uso y en las especificaciones suplementarias.
1.2 Definiciones, Acrónimos, y Abreviaciones
· PC: Petición de Cambio
· SGD: Sistema Gestión Dependencias
· SCP: Sistema Control Proyectos
· SGPC: Sistema Gestión Peticiones de Cambio
· SCV: Sistema Control Versiones
Para más términos y definiciones ver SGPC - Dominio.doc
1.3 Referencias
· SGPC Modelado Conceptual.doc
1.4 Organización del documento
En primer lugar se describe el problema que va a solucionar el sistema. A continuación se recoge una lista de usuarios característicos del sistema. Para cada usuario se proporciona una descripción que define al usuario y una lista de intereses con respecto al sistema a construir. La siguiente sección muestra y describe las características funcionales que resumen las capacidades del sistema. Estas características funcionales constituyen los requisitos del sistema. El último apartado describe otros requisitos no funcionales.
2 Posicionamiento
2.1 Oportunidad de Negocio
MegaConsulting utiliza en sus proyectos un sistema para el de control de versiones (SCV) y otro para las relaciones de traza (dependencias) entre los artefactos (SGD). Actualmente las peticiones de cambio se gestionan manualmente. En el momento de determinar el impacto se localizan los artefactos afectados por el cambio en SGD y las versiones de los mismos en SCV. Para el control de proyectos la compañía dispone de un sistema SCP, que es donde se dan de alta los proyectos, los recursos, tanto humanos como materiales que son necesarios para el desarrollo del proyecto, así como las horas incurridas en el mismo. Es el sistema que se utiliza para el cálculo y control de costes
Tanto SCP como SGD y SCV están integrados de manera que los artefactos registrados en SGD hacen referencia a un proyecto de SCO y se refieren a versiones mantenidas en SCV.
Exista la oportunidad de crear un sistema para la gestión de peticiones de cambio que se integre con los sistemas existentes para la automatización del proceso de gestión del cambio existente en la compañía
2.2 Definición del Problema
El problema de
Ejecutar manualmente el proceso de gestión de peticiones de cambio y mantener el registro de PCs, en documentos electrónicos que no están soportados automáticamente
Afecta
A la efectividad del proceso de gestión del cambio en los proyectos que realiza MegaConsulting
el impacto es
Es difícil de conocer el estado de las peticiones de cambio y tomar decisiones en base al estado de las mismas
Se pierde fácilmente el control sobre el registro de las peticiones de cambio y lo artefactos a los que afectan.
Se pierde mucho tiempo en mantener actualizado el estado de las peticiones de cambio
No se están aprovechando los interfaces electrónicos de los sistemas existentes para la gestión de proyectos, recayendo toda la responsabilidad sobre las personas, con la consiguiente probabilidad de cometer errores.
Una solución satisfactoria sería
La creación de un sistema software que:
· Automatice el flujo del proceso de gestión de peticiones de cambio, notificando la asignación de una tarea relativa al proceso a los participantes del proyecto y avanzando el estado del proceso cuando se finaliza dicha tarea.
· Mantenga y controle el estado de las peticiones de cambio durante el ciclo de vida de la mismas
· Permita generar informes de seguimiento del proyecto en base a los estados de las peticiones de cambio
· Se integre con los sistemas existentes para la gestión y soporte al desarrollo de proyectos.
3 Descripción de Usuarios
A continuación se describen los usuarios que pueden llegar a utilizar el sistema. Para cada usuario se proporciona una descripción breve y la lista de intereses clave con respecto al sistema
Nombre
Descripción
Intereses/ Utilidad
Participante Proyecto
Se refiere a cualquiera de las personas que participan en el proyecto
Emitir Peticiones de cambio
Recibir asignaciones de tareas del proceso de gestión del cambio de acuerdo a su rol en el proyecto
Consultar el estado de las peticiones de cambio emitidas o en las que esta trabajando
Integrante CCC
Es cualquier participante del proyecto que tiene el perfil o rol necesario para desempeñar las tareas del CCC (Jefe Proyecto, Arquitecto, Representante Cliente,…)
Elaborar informes de seguimiento
Planificar asambleas
Analizar el impacto de las PCs
Planificar trabajo y asignar PCs
Evaluar y Revisar PCs
Confirmar rechazo o duplicidad de PCs
Notificar el estado de la PC a la emisor
Conocer el estado y evolución de la PC durante su ciclo de vida
Conocer el estado de la cartera de peticiones
Gestor Proyecto
Es el responsable del proyecto
Elaborar informes de seguimiento
Conocer el estado y evolución de las PC durante su ciclo de vida
Conocer el estado de la cartera de peticiones.
SGD (Sistema Gestion Dependencias)
Para un determinado Proyecto es el responsable de mantener las relaciones de dependencia entre los artefactos de dicho proyecto.
Es el sistema usado para analizar el impacto del cambio en un determinado artefacto del proyecto, a partir del árbol de dependencias con otros artefactos. (relaciones de traza)
SCV (Sistema de Control de Versiones:)
Es el sistema encargado de mantener y soportar la gestión de las versiones de los artefactos del proyecto.( Es donde residen físicamente los artefactos)
A la hora de emitir la petición las versiones del artefactos impactados hacen referencia a la versiones almacenadas en este sistema. Desde SGD se referencia a las versiones gestionadas por SCV.
SCP (Sistema Control Proyectos)
Es el sistema donde se dan de alta los proyectos y los recursos necesarios para llevarlos a cabo. Los participantes en un proyecto de MegaConsulting reportan las horas trabajadas en este sistema
En el momento de emitir una PC, siempre se hace referencia a un proyecto y a unos artefactos del mismo.
Cuando se asignan participantes del proyecto a alguna tarea del proceso de gestión se utilizará este sistema como fuente de información, de los participantes y roles de cada uno de ellos.
Administrador
Es el responsable de que se administrar el sistema.
Gestionar alta, baja y modificación de usuarios, perfiles y permisos.
Configurar el sistema, dando de alta nuevos proyectos sobre los que se aplicará el proceso de gestión del cambio
Monitorizar el estado del sistema.
Acceder y Revisar los logs y trazas del sistema.
4 Perspectiva del Producto
En “Figura 1 Perspectiva del Sistema” se muestra el sistema SGPC y los usuarios / sistemas con los que interactúa:
Participante Proyecto
Sistema GestionPeticiones de Cambio
Sistema Control Versiones
CCC
Gestor Proyecto
Administrador
Participante Proyecto
Sistema Control Proyectos
Sistema Control Dependencias
Figura 1 Perspectiva del Sistema
SGPC se integrará con SGD a la hora de determinar el impacto que implica un cambio en un artefacto en base al árbol de dependencias del mismo. Las versiones de los artefactos sobre los que se emiten peticiones de cambio se obtendrán de SCV. A la hora de emitir una PC se hará referencia a un proyecto almacenado en SCP.
5 CaracterÍstIcas del Producto
5.1 Autentificación de usuarios
El acceso al sistema se hará mediante username y password
5.2 Multi-proyecto
El sistema permitirá la gestión de múltiples proyectos y emitir peticiones de cambio sobre cualquier artefacto de dichos proyectos.
5.3 Integración con SCP, SCV, SDP
El sistema se integrará con los sistemas de gestión de proyectos existentes:
· SCP: para obtener los proyectos sobre los que es posible emitir peticiones de cambio y los participantes : personas, y roles del proyecto
· SCV: para obtener los artefactos y las versiones de los mismos sobre los que se emite la petición de cambio
· SDP: para obtener el impacto en base al árbol de dependencias del artefacto sobre el que se emite
5.4 Gestión automática del flujo del proceso
El sistema controlará el flujo del proceso de gestión del cambio. Cada participante en el proceso de gestión del cambio dispondrá de un “inbox” de tareas relativas al proceso. El sistema para cada petición de cambio disparará el flujo que la gestiona asignando tareas en el inbox correspondiente. Cuando el participante del proyecto completa la tarea del proceso, actualiza la PC con la información correspondiente y notifica al sistema que la tarea esta completa.
5.5 Generación e Impresión de informes seguimiento
El sistema permite generar automáticamente informes acerca del estado del proyecto en base al estado de las peticiones de cambio que están en la cartera del proyecto. Los informes se pueden imprimir en una impresora o exportar a ficheros formato MS Word y Excel.
5.6 Activación automática de PCs pospuestas
Cuando una petición de cambio se pospone con una fecha, el sistema activa automáticamente la pc para su revisión cuando se alcanza dicha fecha.
5.7 Notificación del Estado PC
El emisor de las peticiones de cambio recibirá por notificaciones en su Inbox acerca de la evolución de la petición de cambio durante su ciclo de vida
5.8 Gestión automática de asambleas
El sistema periódicamente notifica la necesidad de constituir una asamblea de revisión de la cartera de peticiones. La asamblea puede ser realizada en fecha distinta de la de por defecto (cada semana)
6 Otros Requisitos
6.1 Rendimiento y Fiabilidad
El sistema ha de estar disponible 24x7
6.2 Requisitos Software
Sistema Operativo: Windows Server 2003
Base de Datos: MS SQL Server 2000 SP3
Mecanismos de integración disponibles:
· SCP: MS Messages Queues
· SCV: API COM
· SGD: API COM
6.3 Requisitos Hardware
Hardware: hp ProLiant ML570 G2