VISIÓN

Historia de Cambios

FECHA VERSIÓN DESCRIPCIÓN AUTOR

<dd/mmm/aa> <1.0> <describir los cambios o <nombre del autor o
inclusiones en el documento> autores>

1. SISTEMA DE GESTIÓN DE TRÁMITES DOCUMENTARIOS

2. Objetivos
2.1. Objetivos Generales:
Implementar un proyecto de software el cual pueda optimizar el proceso
de gestión de trámites documentario”; para que permita facilitar y agilizar los trámites
documentarios solicitados por los estudiantes, personal, egresados u otros usuarios

2.2. Objetivos específicos:

De acuerdo a los alcances del proyecto realizar el análisis y diseño del Sistema de Gestión de
Trámites Documentarios.
Gestionar el desarrollo del Sistema con el modelo SCRUM para garantizar entregas continuas
a los usuarios.

3. Alcance o campo de acción

El alcance del proyecto involucra la participación de las siguientes áreas de

Secretaría General: Trámite Documentario, Registro Académico, además las Secretarías
Académicas de Filiales y el estudiante; permitiendo gestionar las diferentes solicitudes
realizadas por los estudiantes

1. El proceso de los trámites en las filiales se realiza de manera manual en cada fase
 y esto lleva mucho tiempo en entregar los documentos que solicitan los clientes;
es decir, el proceso es muy lento. En base al proceso actual, es necesario
optimizar los procesos considerando métricas de eficiencia y eficacia y que esté
por lo menos en el nivel 4 de la madurez de un proceso en la cual debe estar
soportado por tecnologías de información.

4. Referencias
❑ https://prezi.com/egrhmbppnbmv/sistema-de-tramite-documentario/
❑ http://www3.vivienda.gob.pe/manuales/Manuales/Manual-de-Usuario-SITRAD.pdf
❑ http://www.usmp.edu.pe/pdf/TRAMITE_DOCUMENTARIO.pdf
❑

❑
5. Posicionamiento del sistema

5.1 Objeto de studio

El trámite documentario es considerado un proceso muy importante dentro de cualquier institución
o entidad, En ese sentido, la importancia de contar con un sistema que permita el manejo
automatizado
El Sistema de Trámite Documentario (STD), permite el ingreso de todos los documentos
recepcionados y generados; permitiendo controlar y realizar un seguimiento adecuada y disminuir el
riesgo de pérdidas de datos.

VISIÓN

“Desarrollar personas íntegras, con espíritu de servicio misionero e innovadoras a fin de

restaurar la imagen de Dios en el ser humano.”

MISIÓN

“Ser referente por la excelencia en el servicio misionero y la calidad educativa e

innovadora en la iglesia y la sociedad.”

5.2 Oportunidad de negocio

Los beneficios que obtendrá el trámite documentario con la implementación del software es
que facilitara agilizará los trámites documentarios solicitados por los estudiantes, personal, egresados
u otros usuarios.
5.3 Declaración del problema a resolver

El problema de No contar con sistemas que agilicen algunos de los procesos que se
realizan en el área de Trámite Documentario actualmente son manuales
afecta A la universidad
El impacto está Los diversos trámites como certificados, constancias, etc… el
estudiante o egresado se tiene que acercar de manera presencial a las
oficinas para realizar su trámite y esto genera en algunas ocasiones colas
para realizar la solicitud ya que existe una única oficina.

Por otra parte, no hay forma para el personal de la oficina de Trámite

Documentario que puedan hacer un seguimiento y monitoreo de un
trámite determinado;
Una solución Contar Contar con un software:
adecuada
sería
que le permita llevar un control eficiente de los trámites ayudando a
agilizar el proceso de una manera sencilla y rápida

5.4 Declaración del Posicionamiento del Producto

 Para [nombre del cliente destino]
Quién Mejorar el manejo de la información con registros en una
base de datos, para poder tener un mayor filtro de la
información, tener información a tiempo real y dar reportes
con los resultados de mi trabajo.
El (producto)
Que Requiere de una herramienta que le permita agilizar sus
procesos de registrar trámite, también que permitir
elaborar solicitud, con datos reales. registrar el pago
A diferencia de Manejar la información en un formato Excel. Tener la posibilidad
para garantizar un seguimiento adecuada y disminuir el riesgo de
pérdidas de datos.
Nuestro producto Tiene un mejor control de proteger la información producida por el
proceso de registro de solicitudes de trámite documentario

6. Descripción de los Usuarios del Sistema

6.1 Usuario / Demografía del mercado

Describir de manera resumida la demografía clave del mercado, que motiva las decisiones
acerca del sistema. Describir y posicionar los segmentos del mercado destino.
Estimar el tamaño y crecimiento del mercado mediante el uso del número de usuarios
potenciales y la cantidad de dinero que los clientes gastan tratando de resolver las
necesidades, que el producto o mejora va a satisfacer. Resumir las mejores
tendencias y tecnologías de la industria. Basarse en las respuestas a las siguientes
preguntas estratégicas:
❑ ¿Cuál es la reputación de la organización en estos mercados?
❑ ¿Cómo se desea que sea dicha reputación?
❑ ¿Cómo es que este producto o servicio brindará soporte a los objetivos de la
organización?]
6.2 Perfiles de Usuario
Describir cada tipo de usuario. Estos tipos pueden ser tan divergentes como expertos y
novatos. Por ejemplo un experto puede necesitar una herramienta flexible pero
sofisticada de soporte a la revisión de la plataforma en cambio un novato puede
necesitar una herramienta fácil de usar y que sea amigable. El perfil debe cubrir los
siguientes tópicos para cada tipo de usuario:

Nombre Responsa- Background Entregables Reporta a Problemas

Usuario bilidades Técnico
(Rol) Clave
 6.3 Ambiente del Usuario
[Describir con detalle el ambiente de trabajo del usuario destino. Algunas sugerencias:
❑ ¿Cuál es el número de personas involucradas en completar una tarea? ¿Está
cambiando (aumentando o disminuyendo?
❑ ¿Cuánto tiempo demora el ciclo de vida de la tarea? ¿Está cambiando? Describirlo
desde el punto de vista de la atención y cómo se ve perjudicada.
❑ Restricciones del ambiente como: es móvil, en espacio abierto, durante un vuelo,
etc.?
❑ ¿Qué plataformas de sistemas está en uso? ¿Existirán futuras plataformas?
❑ ¿Qué otras aplicaciones están en uso? ¿La aplicación a ser desarrollada necesita ser
integrada con la que ellos usan actualmente.
6.4 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 solución
progresiva hecha en casa, o simplemente mantener el status quo. Listar cada
alternativa competitiva que existe y que puede estar disponible. Describir las
debilidades y fortalezas tal y como son percibidas por el usuario. Adjunte el
benchmarking y presente el siguiente cuadro resumen.]

Alternativa Producto o Solución Fortalezas Debilidades

Competitiva

7. Resumen del Producto

Esta sección proporciona una vista de alto nivel de las capacidades, interfaces con otras
aplicaciones y configuración del sistema. Consiste de tres subsecciones:
❑ Perspectiva
❑ Funciones o Tareas a Automatizar
❑ Suposiciones y Dependencias
7.1 Perspectiva del Producto
[En esta subsección se debe presentar al producto en perspectiva con otros productos y
usuarios. Si el producto es independiente y es un paquete, declararlo aquí. Si el
producto es un componente de un sistema grande, en esta sección se describen las
interacciones. Una manera sencilla de describir las interacciones es mediante un
diagrama de bloques.]
 7.2 Resumen de Capacidades
[Resumir los grandes beneficios y características de las funciones que el producto tiene.
Describir con profundidad las tareas o el ámbito de la implementación]
Organizar las funciones para que sean comprensible para el usuario final. Por ejemplo:

Función Características Beneficios

Dar Soporte al Sistema ❑ Cuenta con una base de ❑ Nuevo staff de soporte que
conocimiento que da asistencia al rápidamente toma
personal de soporte en la decisiones y las ejecuta.
identificación rápida de ❑ La satisfacción del usuario
soluciones y experiencias se incrementa debido a
anteriores. que no hay problemas de
❑ Los problemas son numerados, gran severidad.
clasificados y seguidos de manera
única a través de un proceso de
resolución.
.... .... ...

7.3 Suposiciones, dependencies y riesgos

[Listar cada factor que afecta a diferentes características mencionadas. Listar las suposiciones
e hipótesis que si cambian, alterarán el contenido de la Visión.].

8. Características de los Atributos

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

9. Características del Producto

[Listar y describir las características del producto. Las características son las capacidades de
alto nivel del sistema que son necesarias para que el usuario tenga beneficios. Cada
característica tendrá una serie de inputs y outputs para alcanzar el resultado
deseado.
La visión debe de contener el nivel de detalle para que el equipo tenga la información
necesaria para crear un modelo use-case.
Para administrar efectivamente una aplicación compleja es necesario identificar y desarrollar
las características en un nivel muy alto para asegurar que 25-99 resulten. Cada
característica se expandirá en mayor nivel de detalle en el modelo de casos de uso.
Evitar el diseño. Conservar una descripción de nivel general. Focalizar en las capacidades
requeridas y porque (no en como).]
Cada característica debe ser redactada en infinitivo y descrita de manera que pueda ser
percibida externamente por usuario operadores y otros sistemas externos. Aplicar el
cuadro siguiente, tomando como base los requerimientos de la matriz.:

Nombre de la Descripción Inputs Outputs Usuario

Característica Responsable
10. Restricciones
[Anotar todas las restricciones de diseño, restricciones o parámetros externos y otras
dependencias.]

11. Otros Requerimientos

[Listar en un alto nivel, los estándares y requerimientos de plataforma de hardware,
rendimiento y ambiente.]
11.1 Estándares
[Listar todos los estándares con los que el negocio debe cumplir. Pueden ser legales, de
comunicación (TCP/IP, ISDN), de plataformas (Windows, Unix, etc.), de comercio
electrónico, y de calidad (ISO, CMM).].
11.2 Requerimientos de la Implementación
[Definir los requerimientos de soporte a la aplicación: configuraciones, memoria, periféricos,
plataforma de redes, y licencias.] .
11.3 Requerimientos de Rendimiento
[Detallar los requerimientos de rendimiento, tiempos de respuesta, anchos de banda,
capacidad de comunicación y confiabilidad.].
11.4 Requerimientos del Medio Ambiente.
[Detallar los requerimientos de ambiente necesarios. Para el hardware pueden ser:
temperatura, humedad, tolerancia a fallas, radiación, etc. Para el software:
condiciones de uso, disponibilidad de recursos, mantenimiento, recuperación y
soporte a errores.].

12. Requerimientos de Documentación

[Esta sección describe los requerimientos de documentación que debe ser desarrollada como
soporte al desarrollo de la aplicación. ]
12.1 Manual de Usuario
[Describe el propósito y contenido del Manual de Usuario, longitud deseada, nivel de detalle,
glosario de términos, tutoriales. Requisitos de formato e impresión también deben
de describirse. ]
12.2 Ayuda en Línea
[Muchas aplicaciones proporcionan un sistema de ayuda en línea para asistir al usuario. La
naturaleza de estos sistemas son únicos y combinan aspectos de programación
(hipervínculos) con los de escritura técnica. (organización, presentación). ]
12.3 Guias de Instalación
[Es un documento que incluye instrucciones para instalación y guías de configuración y que
es muy importante para completar la solución de un software. También se utilizan
los archivos “Read Me” como un componente estándar del paquete. Este archivo
incluye la sección “Lo nuevo de ésta versión es:” y una discusión de la compatibilidad
con otras versiones. ]
 12.4 Paquetes
[El estado de arte hoy en día proporciona una consitencia en la presentación que comienza
con el paquete y se manifiesta a través de menús de instalación, pantallas de
notificación, sistemas de ayuda, diálogos, etc. Esta sección define la necesidad de
incluir el etiquetado en el código. Ejemplos: notificaciones de copyrights y patentes,
logos corporativos, úconocs y gráficos estandar, etc.]