Está en la página 1de 10

Proceso

Actividad
Tarea

Producto Documento de E.R. S


Emitido por XXXXXXX Estado: aprobado

Angela Nataly Gómez Barrero


Edgar Leonardo Velandia García
Rafael Ricardo Morales Leiton

INTRODUCCIÓN:

El proceso de arquitectura de software integra las necesidades del cliente, analiza los
requisitos y diseña software para satisfacer sus necesidades. Cumplir con los principios
de diseño y las buenas técnicas de programación que evolucionan con el tiempo; y
complementar el hardware, las redes y los sistemas de gestión modernos. Una
arquitectura de software sólida significa que tendrá mucha experiencia teórica y práctica,
así como una visión para transformar los requisitos y soluciones comerciales
aparentemente imprecisos en diseños de trabajo confiables y prácticos.
La arquitectura del software incluye la definición de una solución estructurada que
puede cumplir con todos los requisitos técnicos y operativos al tiempo que optimiza
atributos de calidad comunes como el rendimiento, la seguridad y la capacidad de
gestión. Además, implica una serie de decisiones basadas en múltiples factores, y cada
decisión tendrá un impacto importante en la calidad, el rendimiento, el mantenimiento y
el éxito general del software.

Título del proyecto


Plan calidad de software - Mecanismo de trasporte.

Objetivo general
Definir procedimientos, técnicas y métodos para asegurar la entrega de software y
solicitar requisitos al cliente antes del mecanismo de transmisión del proyecto; registrar
claramente los requisitos de la aplicación de software que se desarrollará para brindar
soluciones que cumplan con los requisitos propuestos.
Objetivos específicos
• Proveer soluciones de software aplicando nuevas tecnologías.
• Aplicar métodos de desarrollo de software las cuales brindan una mejor
confiabilidad.

1.2. ÁMBITO DEL SISTEMA:

1.3. DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS


Proceso
Actividad
Tarea

Producto Documento de E.R. S


Emitido por XXXXXXX Estado: aprobado

SGBD Sistema gestor de Base de datos.


MVC Modelo vista controlador
UML Lenguaje unificado de modelado
MER Modelo entidad y relación

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
2 OMG Unified Modeling Language Specification
Version 1.4 formal/2001-09-67 2001

FUNCIONES DEL PRODUCTO


1.Capturar el salario del conductor.
2.Administrar las salidas que realiza por mes.
3.Establecer el valor de los viáticos.
4.Valor del consumo de combustible.
5.Número de peajes pagados.

CARACTERÍSTICA DE USUARIO
Administrador del sistema
Es un usuario con conocimientos de sistemas, quién controlara toda la información del
sistema y es autónomo para tomar decisiones y es parte de la universidad.
REQUERIMIENTOS FUNCIONALES
Capturar el salario del conductor.
Este requerimiento se centra en el registro, actualización y eliminación de los datos del
conductor.
Registrar los datos del conductor
Se hace el registro de los datos del conductor para que se vincule al sistema.
Tipo de requerimiento
Datos
Entrada
Nombre completo del conductor, salario base, vehículo asignado.
Proceso
El usuario responsable de administrar el sistema completa los datos del conductor a través
del formulario para ingresarlo en el sistema. Si hay un error en el sistema, el sistema
Proceso
Actividad
Tarea

Producto Documento de E.R. S


Emitido por XXXXXXX Estado: aprobado

verificará los datos para asegurarse de que el controlador que ya existe en el sistema no esté
registrado. El usuario debe ser notificado.
Salida
Mensaje de confirmación del registro.
Registro exitoso en la base de datos.
Actualizar los datos del conductor.
Se hace la actualización de los datos del conductor en uno o más de los datos de entrada.
Tipo de requerimiento
Datos
Entrada
Nombre completo del conductor, salario base y vehículo asignado.
Proceso
El usuario a cargo de administrar el sistema debe actualizar los datos del conductor antes de
poder ingresarlos en el sistema mediante un formulario web. Antes de realizar cualquier
cambio en la base de datos, la modificación debe ser confirmada por el sistema, y si hay un
error en el sistema, se debe notificar al usuario.
Salida
Mensaje de confirmación de la modificación
Registro exitoso en la base de datos.
Eliminar los datos del conductor
Se hace la eliminación de los datos del conductor.
Tipo de requerimiento
Datos
Entrada
Id del conductor (Cedula).
Proceso
El usuario encargado del sistema de gestión busca al conductor a eliminar solo por su
número de id para asegurar la eliminación del personal indicado. El sistema informa a los
usuarios que su información será eliminada.
Salida
Mensaje de confirmación de la eliminación.
Eliminación de datos en la base de datos.
Administrar las salidas que realiza por mes
Para poder gestionar las salidas que ocurren cada mes, el sistema debe identificar primero
las salidas que realizará el vehículo, para ello el sistema debe almacenar y borrar los datos
del vehículo, debe vincular los conductores responsables de las salidas y organizar el
horario de viaje. El itinerario de cada vehículo.

Almacenar información del vehículo


Proceso: El usuario responsable de gestionar el sistema busca al conductor, se puede
eliminar su nombre, salario o perfil completo del conductor.
Proceso
Actividad
Tarea

Producto Documento de E.R. S


Emitido por XXXXXXX Estado: aprobado

Entrada: datos
Salida: la información se ve eliminada

Proceso: El usuario encargado de administrar el sistema busca al vehículo por medio de la


placa de este con el fin de garantizar que se elimine el vehículo deseado.
Entrada: Placa, cedula
Salida: Información eliminada

Relacionar vehículo con el conductor


Proceso: El usuario del sistema de gestión establece un vínculo después de que "se crean el
vehículo y el conductor, y el sistema debe confirmar que el vínculo es correcto".
Entrada: Tipo, Galones, placa id conductor
Salida: Vehículo asignado

Registrar las salidas por mes


Proceso: El usuario del sistema de gestión realiza una búsqueda del vehículo "Primero, se
determina la disponibilidad en base a la fecha y el número de pasajeros. Una vez verificada
la disponibilidad almacenará los datos en el sistema, el sistema debe confirmar con el
usuario su programación.
Entrada: Nombre del lugar, selección de marcación si es fuera o no del departamento y
distancia.
Salida: Reserva guardada en el sistema y verificar el tipo de salida si es dentro o no de la
ciudad.

Proceso: El sistema compara destinos y ocupaciones: “Si es dentro del departamento y para
alguna ocupación de enfermería, ambiental, minería y desarrollo de software, aprobará la
ruta, de lo contrario te advertirá que no se puede realizar el itinerario, si existe Algunos
errores en el sistema deben notificarse al usuario.
Entrada: Lugares y carrera u ocupación
Salida: Inscripción exitosa y confirmación de destino
Establecer los valores de viáticos

Proceso: El sistema calcula según el destino a través del mapa "La distancia recorrida
calculará el valor de la diferencia diaria. Si hay un error en el sistema, se debe notificar al
usuario".
Entrada: Destino y placa
Salida: Valor con los viáticos.

Valor de consumo de cada vehículo


Proceso
Actividad
Tarea

Producto Documento de E.R. S


Emitido por XXXXXXX Estado: aprobado

Proceso: El sistema calculará la cantidad de kilómetros que ha recorrido el vehículo,


calculará aproximadamente el combustible consumido en función del consumo del vehículo
y calculará el valor de la gasolina con el valor aproximado del combustible. Si hay algún
error, el usuario debe ser notificado en el sistema.
Entrada: Lugar, Valor de la gasolina, Km por galos.
Salida: Registro exitoso en base de datos con el valor del combustible y uso dado durante el
recorrido

Proceso: El conductor registra la cantidad de galones comprados en el sistema. Se toma una


foto del recibo de pago. Para eso, el vehículo contará con un dispositivo que permite
ingresar y capturar estos datos. Si hay un error en el sistema, se debe notificar al usuario.
Entrada: Valor de la gasolina, nombre del combustible.
Salida: Registro exitoso en base de datos del galón gastado

Calcular la cantidad y valor de peajes

Proceso: El sistema calcula los peajes que existen en la ruta y calcula el monto total a
pagar. Si hay un error en el sistema, se debe notificar al usuario.
Entrada: Ruta y peajes
Salida: Almacenamiento exitoso de valor del costo de los peajes de la ruta

Proceso: El conductor registra en el sistema la cantidad de galones comprados y su valor,


tambien toma fotografia del recibo de pago, para ello el vehiculo contara con un
dispositivoque permita el ingreso y captura de estos datos . Si existe algun error en el
sistema dede ser notificado al usuario.

Salida: Registro de valor del combustible gastado.


Mensaje de almacenamiento de los datos exitosos.

Numero de peajes pagados


El sistema hace un calculo aproximado el vehiculo del combustible que va a consumir y del
valor promedio de la gasilona, luego en le recorrido el conductor alimenta en el sistema el
valor real consumido en el recorrido.

Calcular la cantidad y valor de los peajes.


El sistema toma una ruta establecida y determina los peajes sexistentes para establecer el
costo del total de los peajes.

Tipo de requerimiento:Datos
Entrada: Ruta y peajes
Proceso
Actividad
Tarea

Producto Documento de E.R. S


Emitido por XXXXXXX Estado: aprobado

Proceso: El sistema hace los cálculos de los peajes que existen en la ruta trazada y calcular
el valor total para pagar; existe algún error en el sistema debe ser notificado al usuario.

Salida: Almacenamiento de valor del costo de los peajes en la ruta, garantizar el valor de
los peajes
Tipo de requerimiento: Datos
Entrada: Captura del peaje
Proceso: El sistema calcula la llegada del peaje y luego de pasar allí solicita que tome una
fotografía del recibo del peaje el cual puede ser tomado en cualquier momento en que el
vehículo no esté en movimiento, si existe algún error en el sistema debe ser notificado al
usuario.
Salida: Almacenamiento de la captura del recibo de pago
Mensaje de confirmación de captura

No funcionales
Requisitos de performance.
1. El software debe tener tiempos de respuesta inferiores a los 10 segundos ante la
solicitud
2. El software debe correr con menos de la capacidad instalada en el hardware de los
dispositivos que administra y acceden al sistema.

Requisitos de usabilidad

1. Que sea amigable la interacción el sistema para los conductores.


2. Guía de ayuda para el usuario de ambas plataformas
3. Procedimientos cortos para conductores no solicitados en tiempos de
conducción
4. Visualización completa de las consultas realizadas en el sistema central
Entorno
1. Ubicación cercana al conductor del dispositivo
2. No interacción mientras se está conduciendo
3. No debe requerir datos del sistema central mientras esta en un recorrido
Culturales
1. El sistema debe usar un idioma sencillo de entender
Legales
Debe cumplir con las normas de seguridad implementadas en Colombia
Proceso
Actividad
Tarea

Producto Documento de E.R. S


Emitido por XXXXXXX Estado: aprobado

2. Debe cumplir con las políticas establecidas en la universidad y en el documento de


políticas del sistema establecidas por el departamento de seguridad del sistema
Seguridad
1. Debe proteger los datos durante el tránsito y almacenamiento de estos.
2. Debe garantizar la autenticación de los usuarios que accedan al sistema
3. Debe cuidar la confidencialidad y privacidad de los datos
4. Debe proteger la ubicación física de los dispositivos
5. Debe garantizar la disponibilidad de la información con medidas como copias de
seguridad de la información
Mantenimiento
1. Debe realizarse un mantenimiento del sistema periódico cada 3 meses
Comprobabilidad
1. Debe construirse evaluaciones sobre la efectividad de los procesos implementados
por el sistema
Disponibilidad
1. El software central debe estar disponible durante horarios laborales
2. El software de los vehículos debe estar disponible durante todo el tiempo del
recorrido
Escalabilidad
1. El sistema debe poder ser implementado con facilidad en nuevos vehículos que
adquieran la institución
2. El sistema debe tener la capacidad de administrar de nuevos conductores y
vehículos
3. El sistema debe ser fácil de acceder y estar en la web
Extensibilidad
1. En el futuro se puede optar por la posibilidad de aumentar la comunicación entre el
sistema de los vehículos y el sistema central por medio de un sistema con internet o
satelital
METODOLOGÍA
La metodología que se ejecutara en el sistema es el patrón MVC ya que cumple todas las
expectativas del sistema y garantiza el orden de este.

Modelo – Vista - Controlador


Proceso
Actividad
Tarea

Producto Documento de E.R. S


Emitido por XXXXXXX Estado: aprobado

Es un patrón de arquitectura de software, que separa los datos de la lógica de negocio de


una aplicación de su representación y el módulo encargado de gestionar los eventos y las
comunicaciones

FASES
MODELO
se encarga de los datos, generalmente (pero no obligatoriamente) consultando la base de
datos, actualizaciones, consultas, búsquedas ETC todo esto va aquí, en el modelo

CONTROLADOR
Se encarga de controlar, recibe las órdenes del usuario y se encarga de solicitar los datos al
modelo y de comunicárselos a la vista.

VISTAS
Son las representaciones visuales de los datos, todo lo que tenga que ver con la interfaz
gráfica va aquí, ni el modelo ni el controlador se ocupan de cómo se verán los datos, esa
responsabilidad es únicamente de la vista.

Calidad del producto software


Las normas para este desarrollo son las normas ISO/IEC 25000 ya que nos permite asegurar
la calidad del software y su funcionamiento.
La familia de normas ISO/IEC 25000
ISO/IEC 25000 conocidas como Square (System and software Quality Requirements and
Evaluation) es la familia de normas que tiene por objetivo la creación de un marco de
trabajo común para evaluar la calidad del producto software

SQA (Aseguramiento de la calidad del software)


SQA (software Quality assurance o aseguramiento de calidad del software)

Implica revisar y auditar los productos y actividades de software para verificar que se
cumplan con los procedimientos y los estándares además de proveer a la gerencia
apropiadas (incluyendo a los proyectos) con los resultados de estas revisiones, por lo tanto,
SQA envuelve al proceso de desarrollo del software completo: monitoreando y mejorando
el proceso; asegurándose que cualquier estándar y procedimiento adoptado sean seguidos; y
asegurándose que problemas sean encontrados y tratados.

Rol de SQA
El rol de SQA es brindar la metodología de desarrollo de software la administración y
seguranza de los procesos oficialmente establecidos están siendo implementados, asegurar
que:
Proceso
Actividad
Tarea

Producto Documento de E.R. S


Emitido por XXXXXXX Estado: aprobado

1. Una apropiación este establecida


2. Que los proyectos utilicen estándares y procedimientos en su trabajo
3. Que la documentación sea creada para mantenimiento y mejoramiento
4. La administración de configuración de software este adecuada para controlar
cambios
5. Se realicen pruebas y se aprueben
6. Cualquier deficiencia y desviación sea identificada y llevada con atención a la
administración

Procesa
En el modelo que se tratara en este libro la lógica de la vista recibe la información recibe la
información provista por el controlador trae un layout (diseño) y lo procesa con la
información recibida, antes de entregarlo al usuario otros modelos pueden realizar esto,
Proceso
Actividad
Tarea

Producto Documento de E.R. S


Emitido por XXXXXXX Estado: aprobado

íntegramente a través del controlador, pero aquí no lo trataremos por considerar que resta
mantenibilidad al sistema

También podría gustarte