PROJECT XYZ VISION

Historia de Cambios
FECHA <06/09/2012> 19-09-2012 VERSIN <1.0> 2.0 DESCRIPCIN Documento Vision Documento Vision AUTOR Sergio Julian Sandoval Huaman Sergio Julian Sandoval Huaman Cesar Soriano Rosas

1.

Nombre Del Sistema

El Sistema de Tutora de Alumnos Observados (SISGETAOC).

2.

Objetivos
1. Detectar a los alumnos que se encuentren en observacin crtica (segn la reglamentacin) y que se les pueda dar de baja como alumno observado, una vez que salgan de esa situacin (aprobando el curso). 2. Registrar los movimientos y en qu actividad actual se encuentran dichos alumnos, de esta manera poder hacer un monitoreo por cada uno de ellos. 3. Implementar en el Sistema los documentos que los alumnos observados crticos, que deben rellenar antes de pasar por la consejera (formatos de auto-compromiso, disponibilidad horaria, etc.) para que la recepcin sea va correo electrnico y tener un documento digital adicional. 4. Asignar a cada alumno un tutor, dependiendo de la disponibilidad del mismo, teniendo en cuenta que dicho profesor (tutor) tendr simplemente 2 horas de carga no lectiva durante la semana. 5. Implementar un Proyecto Piloto para las pruebas de aceptacin usuaria de este sistema. Este piloto se ejecutar utilizando como datos iniciales los alumnos observados crticos del ciclo anterior (2012 I) para demostrar la funcionalidad.

6.

3.

Alcance
1. Ingreso y actualizacin de solicitudes de requerimientos de sistemas (perfil del proyecto). Mantenimiento de la documentacin al momento que se realice algn cambio general o especfico de los mismos. Aprobacin y/o conformidad de los requerimientos funcionales. Manejo de las transiciones entre las etapas bsicas: Definicin de Requerimientos. Diseo y Construccin. Pruebas y control de calidad Puesta en Produccin. Manejo de la asignacin de Tareas de Diseo y Construccin a miembros del equipo. Seguimiento del avance de desarrollo por etapa y mdulos. Manejo de la asignacin de actividades de prueba (seguridad). Registro de eventos de avances (Actas de reunin semanal, informes de pruebas por CUS, etc.). Control de Estado de las solicitudes.

4.

Referencias

5.

RUP (Rational Unified Process). Diagrama de casos de uso.

Posicionamiento Oportunidad de negocio

Este sistema permitir a la facultad informatizar el control de las actividades (gestin de alumnos, asisgnacion de horarios, etc), lo cual supondr un acceso rpido y sencillo a los datos que se tengan, utilizando grficas sencillas y amigables. Adems, los datos accedidos estarn siempre actualizados, lo cual es un factor muy importante para poder llevar un control de los alumnos que se encuentran en situacin critica.

6.

6.1
El problema de

Declaracin del Problema a Resolver

Falta de reglamentacin de todo el proceso que realizan los alumnos observados (aunque ya se ha presentado aos atrs una reglamentacin por el profesor Quinto, que no fue aprobado por ciertos inconvenientes, se desea reforzarla y poder llevarla a su ejecucin). Imposibilidad de disponer de una herramienta o facilidad que permita mantener un procedimiento para el control de avance y el cumplimiento de los documentos a presentar a la Escuela de Sistemas y de Software. El sistema, es de necesidad para asegurar el xito de los cumplimientos de las tutoras para los alumnos con observacin crtica tanto de la Escuela de Ingeniera de Sistemas (EAPIS)como la Escuela de Ingeniera de Software (EAPISW) UNMSM.

afecta

El impacto est

Contacto o coordinador de requerimientos del negocio (Daniel Quinto Pazce). Alumnos Profesores

Hay un manejo manual de las labores que se realizan al momento de realizar una matricula de los alumnos observados en situacin critica
adecuada

Una solucin sera

Crear un sistema que almacene toda la informacin referente a los alumnos observados, disponibilidad horaria de los profesores, y que esta informacin est al instante, sea accesible y este actualizada.

6.2
Para

Declaracin del Posicionamiento del Producto

Contacto o coordinador de requerimientos del negocio (Daniel Quinto Pazce). UNMSM: Direccin Acadmica de Ing. de Sistemas Controlan la Asignacion de Horarios, Cursos y profesores. Sistema de Tutora de Alumnos Observados. Almacena la informacin necesaria para gestionar la tutoria de alumnos observados. Permite gestionar las actividades al momento de la matricula de los alumnos en situacin de observados critico y un seguimiento de este.

Quin El (producto) Que A diferencia de Nuestro producto

7.

Descripcin de los Usuarios del Sistema

Para proveer de una forma efectiva productos y servicios que se ajusten a las necesidades de los usuarios, es necesario identificar e involucrar a todos los participantes en el proyecto como parte del proceso de modelado de requerimientos. Tambin es necesario identificar a los usuarios del sistema y asegurarse de que el conjunto de participantes en el proyecto los representa adecuadamente. Esta seccin muestra un perfil de los participantes y de los usuarios involucrados en el proyecto, as como los problemas ms importantes que stos perciben para enfocar la solucin propuesta hacia ellos. No describe sus requisitos especficos ya que stos se capturan mediante otro artefacto. En lugar de esto proporciona la justificacin de por qu estos requisitos son necesarios. 7.1
o

Usuario / Demografa del Mercado

La organizacin (FISI) no contaba con un sistema de tutoria, y este vendra a ser la primera vez que tenga este sistema. Que sea un estndar a seguir en otras facultades de la UNMSM

Cul es la reputacin de la organizacin en estos mercados?

Cmo se desea que sea dicha reputacin? o

Cmo es que este producto o servicio brindar soporte a los objetivos de la organizacin?] -

7.2
Nombre Usuario (Rol)

Perfiles de Usuario
Responsabilidades Clave Background Tcnico Entregable s Reporta a Problemas

Profesores

Esudiantes Coordinador de requerimient os del negocio 7.3

Dictar cursos a alumnos observados en situacion critica y hacer la evaluaciones respectivas Tener un desempeo academico y salir mejorar su situacion de observado

Coordinador de requerimient os del negocio

Profesor

Conocedor del negocio

Ambiente del Usuario

Cul es el nmero de personas involucradas en completar una tarea? Est cambiando (aumentando o disminuyendo? La cantidad de alumnos es variable, ya que en momento que se aprueba el curso que ha sido observado, automticamente se le da de baja a este alumno

Cunto tiempo demora el ciclo de vida de la tarea? Est cambiando? Describirlo desde el punto de vista de la atencin y cmo se ve perjudicada. Tiene un tiempo de vida aproximadamente de 1 semestre acadmico, dependiendo de que si el alumno cumple el objetovo o hay algn cambio en la reglamentacin que este en rigor.

Restricciones del ambiente como: es mvil, en espacio abierto, durante un vuelo, etc.? Solo es utilizada para alumnos de la Facultad de Ingenieria de Sistemas Qu plataformas de sistemas est en uso? Existirn futuras plataformas? No hay plataformas en uso o desarrollo en la FISI.

Qu otras aplicaciones estn en uso? La aplicacin a ser desarrollada necesita ser integrada con la que ellos usan actualmente. -

7.4

Necesidades Claves Del Usuario.

[Lista de las necesidades clavede cada usuario con sus soluciones, tal y como son percibidas ellos. Aclarar los siguientes puntos para cada problema: o o o Cules son las razones de los problemas o necesidades? Cmo se solucionan ahora? Qu soluciones requiere el cliente? Qu es lo que requiere?

[Es importante comprender y documentar la importancia (prioridad) que el usuario le da a la resolucin de cada problema.]

7.5

Alternativas y Competencias

[Identificar las alternativas que los usuarios y funcionarios han evaluado como disponibles. Estas pueden incluir comprar un producto de la competencia, desarrollar una solucin progresiva hecha en casa, o simplemente mantener el status quo. Listar cada alternativa competitiva que existe y puede estar disponible. Describir las debilidades y fortalezas tal y como son percibidas por el usuario.] ALTERNATIVA COMPETITIVA PRODUCTO
O

SOLUCIN

FORTALEZAS

DEBILIDADES

8.

Resumen del Producto

Esta seccin proporciona una vista de alto nivel de las capacidades, interfaces con otras aplicaciones y configuracin del sistema. Consiste de tres subsecciones:

Perspectiva Funciones o Tareas a Automatizar Suposiciones y Dependencias

8.1

Perspectiva del Producto

8.2

Resumen de Capacidades
Caractersticas Cuenta con una base de conocimiento que da asistencia al personal de soporte en la identificacin rpida de soluciones y experiencias anteriores. Los problemas son numerados, clasificados y seguidos de manera nica a travs de un proceso de resolucin. Beneficios Nuevo staff de soporte que rpidamente toma decisiones y las ejecuta. La satisfaccin del usuario se incrementa debido a que no hay problemas de gran severidad.

Funcin Dar Soporte al Sistema

....

....

...

8.3

Suposiciones y Dependencias

9.

Caractersticas de los Atributos

[Las caractersticas o funciones del sistema deben tener atributos que pueden usarse para evaluar, validar, priorizar y administrar los items propuestos para la implementacin. Enumerar las caractersticas que se estan evaluando y ponderando en la lista de requerimientos].

10.

Caractersticas Del Producto

[Listar y describir las caractersticas del producto. Las caractersticas son las capacidades de alto nivel del sistema que son necesarias para que el usuario tenga beneficios. Cada caracterstica tendr una serie de inputs y outputs para alcanzar el resultado deseado. La visin debe de contener el nivel de detalle para que el equipo tenga la informacin necesaria para crear un modelo use-case. Para administrar efectivamente una aplicacin compleja es necesario identificar y desarrollar las caractersticas en un nivel muy alto para asegurar que 25-99 resulten. Cada caracterstica se expandir en mayor nivel de detalle en el modelo de casos de uso. Evitar el diseo. Conservar una descripcin de nivel general. Focalizar en las capacidades requeridas y porque (no en como).] Cada caracterstica debe ser redactada en infinitivo y descrita de manera que pueda ser percibida externamente por usuario operadores y otros sistemas externos. Aplicar las siguientes el cuadro siguiente:

NOMBRE DE LA CARACTERSTICA

DESCRIPCIN

INPUTS

OUTPUTS

USUARIO RESPONSABLE

11.

Restricciones
El actual proyecto tiene funciones especficas y por el momento solo se aceptarn las solicitudes de ser para el caso especfico de la Gestin de Alumnos Observados Crticos, a la recepcin digital de los formatos de auto-compromiso y a la asignacin de tutor en el presente ciclo de la FISI de la UNMSM.

12.

Otros Requerimientos
[Listar en un alto nivel, los estndares y requerimientos de plataforma de hardware, rendimiento y ambiente.]

12.1

Estndares

[Listar todos los estndares con los que el negocio debe cumplir. Pueden ser legales, de comunicacin (TCP/IP, ISDN), de plataformas (Windows, Unix, etc.), de comercio electrnico, y de calidad (ISO, CMM).].

12.2

Requerimientos de la Implementacin

[Definir los requerimientos de soporte a la aplicacin: configuraciones, memoria, perifricos, plataforma de redes, y licencias.] .

12.3

Requerimientos de Rendimiento

[Detallar los requerimientos de rendimiento, tiempos de respuesta, anchos de banda, capacidad de comunicacin y confiabilidad.].

12.4

Requerimientos del Medio Ambiente.

[Detallar los requerimientos de ambiente necesarios. Para el hardware pueden ser: temperatura, humedad, tolerancia a fallas, radiacin, etc. Para el software: condiciones de uso, disponibilidad de recursos, mantenimiento, recuperacin y soporte a errores.].

13.

Requerimientos de Documentacin
[Esta seccin describe los requerimientos de documentacin que debe ser desarrollada como soporte al desarrollo de la aplicacin. ]

13.1

Manual de Usuario

[Describe el propsito y contenido del Manual de Usuario, longitud deseada, nivel de detalle, glosario de trminos, tutoriales. Requisitos de formato e impresin tambin deben de describirse. ]

13.2

Ayuda en Lnea

[Muchas aplicaciones proporcionan un sistema de ayuda en lnea para asistir al usuario. La naturaleza de estos sistemas son nicos y combinan aspectos de programacin (hipervnculos) con los de escritura tcnica. (organizacin, presentacin). ]

13.3

Guias de Instalacin

[Es un documento que incluye instrucciones para instalacin y guas de configuracin y que es muy importante para completar la solucin de un software. Tambin se utilizan los archivos Read Me como un componente estndar del paquete. Este archivo incluye la seccin Lo nuevo de sta versin es: y una discusin de la compatibilidad con otras versiones. ]

13.4

Paquetes

[El estado de arte hoy en da proporciona una consitencia en la presentacin que comienza con el paquete y se manifiesta a travs de mens de instalacin, pantallas de notificacin, sistemas de ayuda, dilogos, etc. Esta seccin define la necesidad de incluir el etiquetado en el cdigo. Ejemplos: notificaciones de copyrights y patentes, logos corporativos, conocs y grficos estandar, etc.]