0% encontró este documento útil (0 votos)
84 vistas17 páginas

Actividad EJE 2

Este documento presenta los requisitos para el desarrollo de un software de gestión de transporte para una universidad. El software controlará las tareas de transporte de profesores y estudiantes para salidas y prácticas, y generará informes. Incluye funciones como registro de usuarios, modificación de datos, eliminación de usuarios, y generación de reportes.

Cargado por

kamilo pinedo
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOC, PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
84 vistas17 páginas

Actividad EJE 2

Este documento presenta los requisitos para el desarrollo de un software de gestión de transporte para una universidad. El software controlará las tareas de transporte de profesores y estudiantes para salidas y prácticas, y generará informes. Incluye funciones como registro de usuarios, modificación de datos, eliminación de usuarios, y generación de reportes.

Cargado por

kamilo pinedo
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOC, PDF, TXT o lee en línea desde Scribd

Proceso de Análisis de Software

Requerimiento de Software
Universidad del Especificaciones de Diseño
Área Andina
Producto Documento de E.R. S
Emitido por KAMILO ANDRES PINEDO SANCHEZ Estado: En Revision
HUGO RAFAEL VILLERO GONZALEZ
ANDRES EDUARDO PULGARIN
RENDON

1. INTRODUCCIÓN:
Este documento es una especificación de requerimientos de software (ERS) para desarrollar el
sistema que controle las tareas de transporte de profesores y estudiantes en cumplimiento a
salidas o practicas pedagógicas de la universidad. Esta especificación se ha estructurado
basándose en las directrices dadas por el estándar IEEE.

1.1. PROPOSITO:
El presente documento tiene como propósito establecer las especificaciones para el desarrollo de
un software que gestiones información relacionada con la utilización de una flota de vehículos
para transporte de profesores y estudiantes de la universidad, se debe calcular las salidas por mes
y establecer específicamente el consumo de combustible de vehículos, las salidas al mes, numero
de peajes pagados por vehículo y el salario del conductor.
Emitir informes cuando el departamento encargado requiera información.
1.2. ÁMBITO DEL SISTEMA:

Identificación del producto de software “ROUTECHECK AREANDINA”


Se establecerá la estructura de un software de gestión de datos relacionados con el pago de
salarios, consumo y gastos de vehículos, así como pagos de pasajes teniendo en cuenta
especificaciones de acuerdo al recorrido, tipo de vehículo y el tipo de practica que se realice.
Emitir informes cuando el departamento encargado requiera información.

1.3. DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS

SGBD Sistema gestor de Base de datos.


IEEE Practica recomendada para especificaciones de requisitos de software
JAVA Lenguaje de programación orientado a objetos
JDBC Conectividad a bases de datos JAVA
OS Sistema operativo
OWASP Proyecto abierto de seguridad de aplicaciones web
SDK Kit de desarrollo de software
TCP/IP Protocolo de control de transmisión/Protocolo de Internet.

1.4. REFERENCIAS
Se listas a continuación otros documentos a los que se hace referencia desde éste:

# TITULO NUMERO FECHA


1 IEEE Guide for Software Requirements Specification
IEEE Std 830-84 1994
Proceso de Análisis de Software
Requerimiento de Software
Universidad del Especificaciones de Diseño
Área Andina
Producto Documento de E.R. S
Emitido por KAMILO ANDRES PINEDO SANCHEZ Estado: En Revision
HUGO RAFAEL VILLERO GONZALEZ
ANDRES EDUARDO PULGARIN
RENDON

2 OMG Unified Modeling Language Specification Version


1.4 formal/2001-09-67 2001
Proceso de Análisis de Software
Requerimiento de Software
Universidad del Especificaciones de Diseño
Área Andina
Producto Documento de E.R. S
Emitido por KAMILO ANDRES PINEDO SANCHEZ Estado: En Revision
HUGO RAFAEL VILLERO GONZALEZ
ANDRES EDUARDO PULGARIN
RENDON

2. DESCRIPCIÓN GENERAL

2.1. PERSPECTIVA DEL PRODUCTO

El sistema “ROUTECHECK AREANDINA” será diseñado con los más altos estándares de
calidad, con desempeño destacado por su eficiencia, rapidez de consulta, fiabilidad de datos e
información clara y puntual que permita a la Universidad obtener de una performance acorde
a las necesidades del cliente.

2.2. FUNCIONES DEL PRODUCTO

“ROUTECHECK AREANDINA”

Figura 1: Diagrama de descomposición de requerimientos de


Routecheck Arandina

2.2.1. Gestión de Administrador


Proceso de Análisis de Software
Requerimiento de Software
Universidad del Especificaciones de Diseño
Área Andina
Producto Documento de E.R. S
Emitido por KAMILO ANDRES PINEDO SANCHEZ Estado: En Revision
HUGO RAFAEL VILLERO GONZALEZ
ANDRES EDUARDO PULGARIN
RENDON

Es un conjunto de requisitos relacionados con la gestión del Administrador, se


centra en crear registros, administrar autorizaciones, eliminación y modificación de
usuarios.

Figura 2: Diagrama de descomposición de requisitos de Gestión de


Administrador

2.2.1.1. Registra nuevos usuarios

 Introducción
Su función consiste en registrar un nuevo usuario en la base de datos del sistema. El
administrador diligencia los campos de datos para la creación de nuevo usuario, puede
autorizar, modificar y borrar usuarios.

 Entrada
Datos de usuario:
Cedula de Ciudadanía.
Primer Nombre
Segundo Nombre
Primer Apellido
Segundo Apellido
Dirección.
Proceso de Análisis de Software
Requerimiento de Software
Universidad del Especificaciones de Diseño
Área Andina
Producto Documento de E.R. S
Emitido por KAMILO ANDRES PINEDO SANCHEZ Estado: En Revision
HUGO RAFAEL VILLERO GONZALEZ
ANDRES EDUARDO PULGARIN
RENDON

Correo Electrónico
Teléfono
Número de Cuenta Bancaria
 Proceso

Una vez se dé inicio al arranque del software, en su interfaz se debe llenar los campos como
muestra la pantalla, el sistema procede a conectar la BD y valida si ya existe un usuario
(Conductor) con el mismo número de cedula de ciudadanía.
El Conductor será el usuario en el sistema.
 Salida

Actualización de la BD.
Mensaje de confirmación al usuario con el resultado del nuevo registro (Usted ha
sido registrado satisfactoriamente con su número de cedula de ciudadanía) Código
de ingreso.

 Requisitos específicos no funcionales


- Base de datos:
El registro de los datos en la BD se debe realizar en un máximo de 10 segundos.

2.2.1.2. Habilitar Usuarios

 Introducción
Su función consiste en habilitar el usuario una vez el administrados lo allá registrado
en la BD.
 Entrada
Indique si desea habilitar este usuario (S/N)
 Proceso
una vez refrendada esta información el usuario nuevo es creado de acuerdo a
especificaciones de nombres y apellidos, el sistema crea un registro único en la BD y
envía correo electrónico de confirmación al usuario notificando su registro al sistema,
el usuario será identificado con el número de cedula de ciudadanía.
 Salidas
Confirmación de Habilitación de Usuario
 Requisitos específicos no funcionales
El registro de los datos en la BD se debe realizar en un máximo de 10 segundos.

2.2.1.3. Modificar Usuarios


Este proceso indica que el administrador puede editar y/o editar la información de los
usuarios
Proceso de Análisis de Software
Requerimiento de Software
Universidad del Especificaciones de Diseño
Área Andina
Producto Documento de E.R. S
Emitido por KAMILO ANDRES PINEDO SANCHEZ Estado: En Revision
HUGO RAFAEL VILLERO GONZALEZ
ANDRES EDUARDO PULGARIN
RENDON

 Introducción
Los datos ingresados podrán ser modificados de acuerdo a solicitud de usuario por
cambio de teléfono, dirección o correo electrónico.
 Entrada
Dirección.
Correo Electrónico
Teléfono
Número de Cuenta Bancaria
 Proceso
El administrador deberá ingresar los nuevos datos del usuario como indica la pantalla
y verificar su actualización
 Salidas
Confirmación de Actualización de datos del Usuario

 Requisitos específicos no funcionales


El registro de los datos en la BD se debe realizar en un máximo de 10 segundos.

 2.2.1.4. Eliminar Usuarios


 Introducción
su funcion consiste en eliminar los datos de los usuarios cuando se requiera
Entrada
Ingresar numero de cedula de ciudadanía
Seleccionar Borrar Usuario
Confirmar Borrar usuario
 Proceso
El administrador podrá borrar los datos del usuario cuando este ya no preste sus
servicios a la universidad.
 Salidas
Confirme Borrar usuario
 Requisitos específicos no funcionales
El registro de los datos en la BD se debe realizar en un máximo de 10 segundos
2.2.2. Gestión de Reportes
Proceso de Análisis de Software
Requerimiento de Software
Universidad del Especificaciones de Diseño
Área Andina
Producto Documento de E.R. S
Emitido por KAMILO ANDRES PINEDO SANCHEZ Estado: En Revision
HUGO RAFAEL VILLERO GONZALEZ
ANDRES EDUARDO PULGARIN
RENDON

Figura 3: Diagrama de descomposición de requisitos de Gestión de Reportes

2.2.2.1. Verificación del Usuario

 Introducción
Su función consiste en verificar el usuario para general los requerimientos
 Entrada
Ingrese cedula de ciudadanía
 Proceso
Los Usuarios siempre van a ser los Conductores, estos se identificarán ante el
administrador con su número de Cedula de Ciudadanía, la cual corresponde a su
identificación en la BD
 Salidas
El usuario registrado es (nombres y apellidos el Usuario)
 Requisitos específicos no funcionales
El registro de los datos en la BD se debe realizar en un máximo de 10
segundos.

2.2.2.2. Ruta Realizada

 Introducción
Su función consiste en dejar consignar la ruta realizada por el conductor para tramites
futuros
 Entrada
Fecha
Hora de Salida
Proceso de Análisis de Software
Requerimiento de Software
Universidad del Especificaciones de Diseño
Área Andina
Producto Documento de E.R. S
Emitido por KAMILO ANDRES PINEDO SANCHEZ Estado: En Revision
HUGO RAFAEL VILLERO GONZALEZ
ANDRES EDUARDO PULGARIN
RENDON

Hora de llegada
Ruta departamental o interdepartamental
Ruta profesores o alumnos

 Proceso
Se debe especificar información sobre la ruta, si fue dentro del departamento o por
fuera, si fue con alumnos y/o profesores
 Salidas
Se ha guardado la ruta correctamente
 Requisitos específicos no funcionales
El registro de los datos en la BD se debe realizar en un máximo de 10 segundos.

2.2.2.3. Distancia Recorrida

 Introducción
Su función es guardar en la BD las distancias discriminada en kilómetros para los
futuros tramites.
 Entrada
Kilómetros recorridos
Vehículo (placas)
Capacidad
Combustible
 Proceso
Una vez en el sistema se debe registrar la información de la operación, discriminada en
cantidad de kilómetros, así mismo la información de los vehículos utilizados, su
capacidad y el tipo de combustible que utilicen.
 Salidas
El registro de recorrido ha sido guardado
El registro del vehículo ha sido guardado
 Requisitos específicos no funcionales
El registro de los datos en la BD se debe realizar en un máximo de 10 segundos.

2.2.2.4. Generar número de requerimiento

 Introducción
Proceso de Análisis de Software
Requerimiento de Software
Universidad del Especificaciones de Diseño
Área Andina
Producto Documento de E.R. S
Emitido por KAMILO ANDRES PINEDO SANCHEZ Estado: En Revision
HUGO RAFAEL VILLERO GONZALEZ
ANDRES EDUARDO PULGARIN
RENDON

Su función consiste en disponer toda la información del recorrido en un registro que se


identifique con un numero de requerimiento, a partir de acá asociamos todos los datos
con un numero de requerimiento.
 Entrada
Desea generar Numero de requerimiento
 Proceso
Los datos se asocian con el número de requerimiento para que en los demás procesos
se simplifique la operación con solo ingresar un numero que ya contiene la
información de las rutas.
 Salidas
Su numero de requerimiento es: xxxxx
 Requisitos específicos no funcionales
El registro de los datos en la BD se debe realizar en un máximo de 10 segundos.

2.2.3 Gestión de Rutas

Figura 4: Diagrama de descomposición de requisitos de Gestión de Rutas

2.2.3.1 Ingrese Número de Requerimiento.

 Introducción
En este punto los usuarios deben cargar información de ruta y clase de vehículo, estos
registros impactan en el sueldo del Usuario.
 Entrada
Ingrese número de requerimiento
 Proceso
Proceso de Análisis de Software
Requerimiento de Software
Universidad del Especificaciones de Diseño
Área Andina
Producto Documento de E.R. S
Emitido por KAMILO ANDRES PINEDO SANCHEZ Estado: En Revision
HUGO RAFAEL VILLERO GONZALEZ
ANDRES EDUARDO PULGARIN
RENDON

En este proceso se carga la información de la BD de los procesos anteriores, como tipo


de vehículo, combustible, hora de salida, destino.
 Salidas
El registro ha sido abierto.
 Requisitos específicos no funcionales
El registro de los datos en la BD se debe realizar en un máximo de 10 segundos.

2.2.3.2 Ruta y Destino

 Introducción
En este punto los usuarios deberán reportar si l ruta es departamental o
interdepartamental
 Entrada
Destino
 Proceso
El usuario (Conductor) deberá reconocer ruta según requerimiento ordenado para la
salida de estudiantes y profesores, identificara si es departamental o fuera del
departamento
Salidas
Actualización de la BD.
Confirmación de información Registrada (S/N)
 Requisitos específicos no funcionales
El registro de los datos en la BD se debe realizar en un máximo de 10 segundos.

2.2.4. Gestión de Viáticos

Figura 5: Diagrama de descomposición de requisitos de Gestión de Viáticos


Proceso de Análisis de Software
Requerimiento de Software
Universidad del Especificaciones de Diseño
Área Andina
Producto Documento de E.R. S
Emitido por KAMILO ANDRES PINEDO SANCHEZ Estado: En Revision
HUGO RAFAEL VILLERO GONZALEZ
ANDRES EDUARDO PULGARIN
RENDON

2.2.4.1 Ingrese Número de Requerimiento.

 Introducción
En este punto los usuarios deben ingresar el número de requerimiento correspondiente
al servicio de transporte.
 Entrada
Indique número de requerimiento
 Proceso
El software deberá descargar la información ya registrada en la BD bajo el número de
requerimiento a ingresar, ello contiene demás información guardad del servicio de
transporte
 Salidas
Se verifico requerimiento exitosamente
 Requisitos específicos no funcionales
El registro de los datos en la BD se debe realizar en un máximo de 10 segundos.

2.2.4.2 Registre información de recorrido

 Introducción
En este punto los usuarios deben ingresar la información de cantidad de kilómetros
recorridos
 Entrada
Cantidad de kilómetros recorridos
 Proceso
El software debera calcular basados en la informacion ya registradas en el la BD y
aplicar la formula de que por cada 50 km recorridos de recorrido en ruta a otro
departamento se debe realizar un aumento del 15% sobre el sueldo base al Usuario,
esto define la formula cantidad de km / 50 = % de aumento en sueldo base.
 Salidas
Actualización de la BD.
Confirmación de información Registrada (S/N)
 Requisitos específicos no funcionales
El registro de los datos en la BD se debe realizar en un máximo de 10 segundos.

2.2.5 Gestión de Gastos


Proceso de Análisis de Software
Requerimiento de Software
Universidad del Especificaciones de Diseño
Área Andina
Producto Documento de E.R. S
Emitido por KAMILO ANDRES PINEDO SANCHEZ Estado: En Revision
HUGO RAFAEL VILLERO GONZALEZ
ANDRES EDUARDO PULGARIN
RENDON

Figura 6: Diagrama de descomposición de requisitos de Gestión de Gastos

2.2.5.1 Ingresar Numero de Requerimiento

 Introducción
En este punto los usuarios deben ingresar el número de requerimiento correspondiente
al servicio de transporte.
 Entrada
Indique número de requerimiento
 Proceso
El software deberá descargar la información ya registrada en la BD bajo el número de
requerimiento a ingresar, ello contiene demás información guardad del servicio de
transporte
 Salidas
Se verifico requerimiento exitosamente
 Requisitos específicos no funcionales
El registro de los datos en la BD se debe realizar en un máximo de 10 segundos.

2.2.5.2 Gastos en Peajes y Combustible

 Introducción
Su función consiste en registrar el gasto en el pago de peajes si hubo y combustibles
 Entrada
Peajes (s/n)
Cantidad de peajes
Proceso de Análisis de Software
Requerimiento de Software
Universidad del Especificaciones de Diseño
Área Andina
Producto Documento de E.R. S
Emitido por KAMILO ANDRES PINEDO SANCHEZ Estado: En Revision
HUGO RAFAEL VILLERO GONZALEZ
ANDRES EDUARDO PULGARIN
RENDON

Tipo de peajes (A, B, C)


Valor cancelado COP
Combustible Consumido
Tipo de Combustible
 Proceso
El software deberá registrar si hubo gasto en pagos de peajes registrando la cantidad de
peajes, tipo de cobro según vehículo, valor cancelado, así mismo la información
relacionada con el tipo y cantidad de combustible gastada.
 Salidas
Se ha registrado la información satisfactoriamente.
 Requisitos específicos no funcionales

2.3. CARACTERÍSTICAS DE LOS USUARIOS

Los Administradores del sistema serán los encargados del ingreso, modificación y
actualización y quienes generen los reportes.

2.4. RESTRICCIONES

2.4.1. Políticas de la Universidad

 La aplicación funcionara de lunes a viernes en horas de oficina de 07:00 a 18:00 y


sábados de 08: a 16:00, no se contempla operación los domingos y festivos.
 El personal de conductores solo registraran la operación después de terminar el
requerimiento de transporte.

2.4.2. Limitaciones del hardware

Se debe tener una estación de servicio que cuente con las siguientes especificaciones:
 Memoria RAM mínimo 8 gb
 Disco Duro mínimo 1 TB
 Monitor Full hd mínimo de 23”
 Disponibilidad de UPS
 Teclado alfa numérica de gran tamaño
Proceso de Análisis de Software
Requerimiento de Software
Universidad del Especificaciones de Diseño
Área Andina
Producto Documento de E.R. S
Emitido por KAMILO ANDRES PINEDO SANCHEZ Estado: En Revision
HUGO RAFAEL VILLERO GONZALEZ
ANDRES EDUARDO PULGARIN
RENDON

2.4.3. Interfaces con otras aplicaciones

La interfaz de comunicación entre el servidor de bases de datos MYSQL y el software


desarrollado.
Windows xp o superior

2.4.4. Operaciones paralelas

No se contempla

2.4.5. Funciones de auditoria

N/A

2.4.6. Funciones de control

No se contempla

2.4.7. Lenguajes de programación

 JAVA
 MYSQI
 PHP

2.4.8. Protocolos de comunicación

Los protocolos de comunicaciones entre los diferentes nodos de la infraestructura


hardware de soporte serán los

Siguientes:

• HTTPS para conexiones con el servidor web.


• TCP/IP a nivel físico.
• Ethernet 802.3 a nivel eléctrico.
Proceso de Análisis de Software
Requerimiento de Software
Universidad del Especificaciones de Diseño
Área Andina
Producto Documento de E.R. S
Emitido por KAMILO ANDRES PINEDO SANCHEZ Estado: En Revision
HUGO RAFAEL VILLERO GONZALEZ
ANDRES EDUARDO PULGARIN
RENDON

2.4.9. Requisitos de fiabilidad

El software debe generar reportes exactos calculando viáticos y gastos de la operación.


El sistema esta controlando todo tipo de transacción y esta apto para responder a todo tipo de
incidente.
El software debe tener una interfaz intuitiva y sencilla
2.4.10. Criticalidad de la aplicación

N/A

2.4.11. Consideraciones de seguridad


Garantizar la seguridad del sistema con respecto a la información y datos que se manejen, así
como controlar el acceso registro de la información personal de los Usuarios

2.5. SUPOSICIONES Y DEPENDENCIAS


No se contempla.

2.6. REQUISITOS FUTUROS

Poder aumentar la capacidad de requerimientos, teniendo en cuenta el crecimiento de la


universidad, se debe contemplar aumentar los requisitos de software.

3. INTERFACES EXTERNAS

3.1.1 Interfaces de Usuario

El Administrador tendrá un único acceso a la aplicación y este portará clave y contraseña.


También deben abarcar ayudas correspondientes para cada uno de los procesos que realice el
sistema.
Debe tener:
Botones
Menús desplegables
Mensajes informativos
Mensajes de error
Cuadros de dialogo

3.1.2 Interfaces Hardware


Proceso de Análisis de Software
Requerimiento de Software
Universidad del Especificaciones de Diseño
Área Andina
Producto Documento de E.R. S
Emitido por KAMILO ANDRES PINEDO SANCHEZ Estado: En Revision
HUGO RAFAEL VILLERO GONZALEZ
ANDRES EDUARDO PULGARIN
RENDON

Se contará con un servidor de base de datos en la universidad

3.1.3 Interfaces Software

El software deberá procesar todos los datos de manera correcta, acertada y su rendimiento debe
ser de calidad.
Debe tener:
Botones
Menús desplegables
Mensajes informativos
Mensajes de error
Cuadros de dialogo

3.1.4 Interfaces de Comunicación

La interfaz de comunicación entre el servidor de base de datos SGBD y la aplicación


desarrollada se realizará mediante JBDC.

3.2. REQUISITOS DE RENDIMIENTO

La infraestructura de Red, así como sus terminales deben cumplir con las normas según la IEEE
en la forma de conexión de equipos para tener tiempos de respuesta mínimos.

3.2.1. Número de usuarios conectados

Se debe permitir un máximo de 2 Administradores conectados

Metodología de desarrollo de software seleccionada


Porque se selecciono

Plan de calidad
Proceso de Análisis de Software
Requerimiento de Software
Universidad del Especificaciones de Diseño
Área Andina
Producto Documento de E.R. S
Emitido por KAMILO ANDRES PINEDO SANCHEZ Estado: En Revision
HUGO RAFAEL VILLERO GONZALEZ
ANDRES EDUARDO PULGARIN
RENDON

También podría gustarte