Escolar Documentos
Profissional Documentos
Cultura Documentos
Edgar William Quinchanegua Forero y Jairo Enrique Tibaquirá Poveda, Facultad de Ingeniería
La correspondencia relacionada con este proyecto debe ser dirigida a Edgar William
Contacto: jamdijkasan@yahoo.es
0
Encabezado: ARQUITECTURA DE SOFTWARE
Índice General
Índice de Ilustraciones.................................................................................................................2
Índice de Tablas...........................................................................................................................3
Introducción.................................................................................................................................4
1. Planteamiento del problema...............................................................................5
2. Propuesta de solución.........................................................................................5
3. Objetivo General................................................................................................5
4. Objetivos Específicos.........................................................................................5
5. Justificación del Proyecto..................................................................................6
6. Requerimientos Funcionales..............................................................................7
7. Requerimientos No Funcionales......................................................................14
8. Glosario............................................................................................................16
9. Ingreso Usuario................................................................................................17
10. Referencias.......................................................................................................17
1
Encabezado: ARQUITECTURA DE SOFTWARE
Índice de Ilustraciones
2
Encabezado: ARQUITECTURA DE SOFTWARE
Índice de Tablas
Tabla 9. Reportes...................................................................................................................................14
3
Encabezado: ARQUITECTURA DE SOFTWARE
Introducción
especializado y con tecnología avanzada que permita prestar eficientemente este servicio a la
ambulancia que tenga las características que el usuario requiere en un determinado momento,
fueron exitosos y cuantos fallidos, por otra parte controla los gastos correspondientes al
valor por galón, totalizando el valor total del tanqueo, el registro del kilometraje actual al
4
Encabezado: ARQUITECTURA DE SOFTWARE
permita realizar un control sobre los costos generados en la movilidad del sistema de
2. Propuesta de solución
esta arquitectura de software, para así mismo poder obtener la mayor optimización posible en
3. Objetivo General
través de servicios de transporte de pacientes que requieran atención médica, a nivel local y
nacional.
4. Objetivos Específicos
sea el caso.
médica.
servicios exitosos, los cuales forjaran ingresos y los servicios fallidos los cuales generan un
egreso, esto en lo referente a las solicitudes generadas por los usuarios y la alta competencia
empezar por generar los registros del servicio, los datos de la ambulancia, los estados de la
fallido.
Por otro lado, se debe llevar el control de los gastos diarios que genera el vehículo, tales como
Por esta razón nuestro sistema ofrecerá, el registro del servicio solicitado, el seguimiento al
6. Requerimientos Funcionales
6
Encabezado: ARQUITECTURA DE SOFTWARE
Requerimiento Funcional 01
Requerimiento Funcional 02
7
Encabezado: ARQUITECTURA DE SOFTWARE
Requerimiento Funcional 03
Clasificación Ambulancias
Identificador: RF03 Nombre: Tipo Clasificación Ambulancias
Importancia: Alta Prioridad: Critica
Entradas: Salidas:
Registrar los tipos de ambulancias de acuerdo Datos detallados del tipo de ambulancia.
a la clasificación de cada una de las
ambulancias.
Descripción:
Ambulancias No Asistenciales, que no están acondicionadas para la asistencia sanitaria en
ruta. Esta categoría de ambulancias comprende las dos siguientes clases:
Ambulancias de Clase A1, o convencionales, destinadas al transporte de pacientes en
camilla.
Ambulancias de Clase A2, o de transporte colectivo, acondicionadas para el transporte
conjunto de enfermos cuyo traslado no revista carácter de urgencia, ni estén aquejados de
enfermedades infecto-contagiosas.
Ambulancias Asistenciales, acondicionadas para permitir asistencia técnico-sanitaria en
ruta. Esta categoría de ambulancias comprende las dos siguientes clases:
Ambulancias de Clase B, destinadas a proporcionar Soporte Vital Básico y atención
sanitaria inicial.
8
Encabezado: ARQUITECTURA DE SOFTWARE
Requerimiento Funcional 04
9
Encabezado: ARQUITECTURA DE SOFTWARE
Requerimiento Funcional 05
Requerimiento Funcional 06
10
Encabezado: ARQUITECTURA DE SOFTWARE
Requerimiento Funcional 07
11
Encabezado: ARQUITECTURA DE SOFTWARE
Requerimiento Funcional 08
12
Encabezado: ARQUITECTURA DE SOFTWARE
Precondición:
Las ambulancias deben de estar previamente registradas en el sistema, para poder realizar
los registros correspondientes.
Manejo de condiciones anormales:
El usuario no tiene asignado el perfil correspondiente, no se despliega los menús del
sistema asociados al perfil.
Criterios de Acotación:
Se requiere registrar el valor de cada tanqueo con el fin de tener un promedio de gastos
por ambulancias en lo referente al consumo de combustible.
Tabla 8. Registro Valor de tanqueo de Combustible
Requerimiento Funcional 09
Nombre: Reportes.
Reportes
Identificador: RF09 Nombre: Reportes.
Importancia: Alta Prioridad: Critica
Entradas: Salidas:
Consulta de datos utilizando los siguientes Reportes con la información solicitada de
parámetros: acuerdo al tipo de reporte.
1. Reporte de Servicios
Periodo de fechas
Número de servicio
Número de identificación de la persona
2. Reporte de Consumo de Combustible
Recibo de tanqueo
Periodo de fechas
Descripción:
Generar reportes gerenciales y de consulta de acuerdo al perfil del usuario.
13
Encabezado: ARQUITECTURA DE SOFTWARE
Precondición:
Los datos solicitados en los diferentes reportes dependen de la información registrada en el
sistema de información.
7. Requerimientos No Funcionales
Cronograma
15
Encabezado: ARQUITECTURA DE SOFTWARE
8. Glosario
tipo de problemática particular que sirve como referencia, para enfrentar y resolver nuevos
Interfaz: Conjunto de elementos de la pantalla que permiten al usuario realizar acciones sobre
Librería: Programa que se integra dentro de otro para dotarlo de funcionalidad y lograr sus
propósitos.
Servidor: Es un equipo informático que forma parte de una red y provee servicios a otros
equipos cliente.
16
Encabezado: ARQUITECTURA DE SOFTWARE
UML: Son las siglas de “Unified Modeling Language” o “Lenguaje Unificado de Modelado”.
9. Ingreso Usuario
17
Imagen 1 Ingreso al sistema
Encabezado: ARQUITECTURA DE SOFTWARE
10. Recomendaciones
Este este proyecto plantea muchos retos retos y sobre todo abre el camino para que se siga
trabajando en el contexto del análisis de costos y gastos y su aplicación por medio de una
arquitectura de software que pueda ser usada para el estudio constante de la ingeniería en un
18
Encabezado: ARQUITECTURA DE SOFTWARE
11. Conclusion
Como conclusión, este proyecto ha sido para los autores una gran experiencia en cuanto al
desarrollo y arquitectura de software por el hecho de obtener como resultado un servicio que
19
Encabezado: ARQUITECTURA DE SOFTWARE
12. Referencias
20