ACTIVIDAD EVALUATIVA EJE 2

PRESENTADO POR:
Nestor Torres Mazuera
Cesar Rodríguez Montero
Javier Cañadulce Huesa

PROFESOR
ANGEL ALBERTO VARON QUIMBAYO

CURSO
INGENIERIA DE SOFTWARE 2

MODALIDAD
Virtual
ACTIVIDAD
EVALUATIVA EJE 2 -
WIKI
Practica requerimientos y arquitectura

Objetivos de aprendizaje:

Que el estudiante mediante un taller práctico demuestre los

conocimientos adquiridos y desarrolle competencias referentes a los
temas ingeniería de requerimientos, arquitecturas del software y
técnicas de calidad del mismo.

Descripción:

La universidad cuenta con una flota de vehículos para el transporte

de docentes y estudiante para la realización de las prácticas o salidas
pedagógicas, estos vehículos son: vans, bus escolar, camionetas y
ambulancias. Cada vehículo está asignado a un conductor, a cada
conductor se le pagan viáticos de la siguiente forma, si el recorrido es
fuera del dpto. por cada 50 km se le cancela un bono del 15% sobre
su salario base, se le asigna dinero para combustible y pago de peajes
según el recorrido, cada vehículo se identifica con la placa del mismo,
se debe tener en cuenta que así mismo cada uno utiliza un tipo de
combustible y tiene puesto para una cantidad de pasajeros, cuando la
práctica es dentro del dpto., esta no dura más de 12 horas, las
prácticas pueden ser de enfermería, ambientales, minas y desarrollo
de software.

La universidad requiere que el software capture el salario del

conductor, las salidas que realiza por mes, el valor de los viáticos,
valor del consumo de combustible por cada vehículo y número de
peajes pagados.
 SOLUCIÓN:
PRESENTADO POR:

Néstor Torres Mazuera

Cesar Rodríguez Montero

Javier Cañadulce Huesa

Docente

ANGEL ALBERTO VARON QUIMBAYO

Carrera de Ingeniería en Sistemas

Fundación del Areandina

INTRODUCCIÓN

El proceso de arquitectura de software toma los requisitos de los

clientes, los analiza y produce un diseño para obtener un software
que satisfará sus necesidades. Los diseños exitosos de software
deben sopesar las disyuntivas inevitables que surgen debido a
requisitos conflictivos; cumplir con los principios de diseño y las
buenas técnicas de procedimiento que han evolucionado con el
tiempo; y complementar el hardware moderno, las redes y los
sistemas de administración. Una arquitectura contundente de
software implica tener mucha experiencia en temas teóricos y
prácticos, así como la visión necesaria para convertir lo que al parecer
son escenarios y requisitos comerciales imprecisos en diseños de
trabajo sólidos y prácticos.

La arquitectura de software implica definir una solución estructurada

que satisfaga todos los requisitos técnicos y operacionales y, a la vez,
optimizar los atributos comunes de calidad como rendimiento,
seguridad y capacidad de administración. Además, implica una serie
de decisiones basadas en una amplia gama de factores, y cada una de
esas decisiones puede tener un considerable impacto sobre la
calidad, rendimiento, mantenimiento y éxito general de ese software.

¿Por qué es importante la arquitectura de software?

Los requerimientos del software moderno son cada vez más

complejos puesto que los usuarios esperan más de sus aplicaciones.
Las aplicaciones de escritorio independientes y sencillas ya no son lo
suficientemente buenas en la mayoría de los escenarios comerciales y
empresariales. En nuestro mundo conectado, la aplicación debe
interactuar con otras aplicaciones y servicios y ejecutarse en una serie
de entornos, como la nube, y en dispositivos portátiles. Los diseños
monolíticos comunes en el pasado se han reemplazado por software
componentizado orientado al servicio, que utiliza marcos, sistemas
operativos, hosts en tiempo de ejecución y redes para implementar
características que eran insólitas hasta hace unos pocos años.

Esta complejidad afecta no sólo al diseño, sino también a la

implementación, mantenimiento y administración del software. El
costo total de propiedad (TCO) del software ahora se compone
predominantemente de costos posteriores a la implementación. Una
aplicación con buena arquitectura minimizará el TCO al reducir el
costo y tiempo requeridos para implementar la aplicación,
mantenerla en ejecución, actualizarla para cumplir con los requisitos
cambiantes y solucionar problemas. Además simplificará el soporte
técnico y la administración por parte del usuario.
 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 por cada vehículo.
5. Número de peajes pagados.

CARACTERÍSTICAS DE LOS USUARIOS

Se establece con base a la descripción brindada es posible establecer

que existen dos tipos de usuarios que pueden entrar en contacto con
el sistema.

Administrador del sistema

Es un usuario con conocimientos de sistemas, quien controlara toda

la información del sistema y es autónomo para tomar decisiones y es
parte de la universidad.

Transportador

Usuario que no necesariamente debe tener conocimientos

informáticos por lo cual es importante que la forma de presentar los
contenidos del sistema sean muy intuitivos y prácticos.

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, cédula, salario base, vehículo

asignado.

Proceso

El usuario encargado de administrar el sistema diligencia los datos del

conductor para ingresarlos al sistema mediante un formulario, estos
datos serán validados por el sistema para garantizar que no se está
registrando un conductor que ya existe en el sistema, si existe algún
error en el sistema debe ser notificado al usuario.

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, cédula, salario base, vehículo

asignado.

Proceso

El usuario encargado de administrar el sistema debe actualizar los

datos del conductor para ingresarlos al sistema mediante un
formulario web. Esta modificación debe ser confirmada por el sistema
antes de realizar cualquier cambio en la base de datos, si existe algún
error en el sistema debe ser notificado 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

Cédula del conductor.

Proceso

El usuario encargado de administrar el sistema busca el conductor

que va a ser eliminado sólo por su número de cédula para garantizar
que se elimina la persona indicada. El sistema notifica al usuario que
se eliminara su información.

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 administrar las salidas que se realizan por mes el sistema debe
primero identificar el vehículo que va a realizar la salida, para ello el
sistema debe almacenar y eliminar los datos del vehículo, debe
vincular al conductor encargado de la salida y organizar la agenda de
viajes de cada vehículo.

Almacenar la información del vehículo

Se realiza el registro del vehículo.

Tipo de requerimiento

Datos

Entrada

Placa, número de pasajeros, tipo de combustible, tipo de vehículo,

modelo, kilometros/galon.

Proceso

El usuario encargado de administrar el sistema diligencia los datos del

vehículo para ingresarlos al sistema mediante un formulario web.
Estos datos serán validados por el sistema para garantizar que no se
está registrando un vehículo que ya existe en el sistema. Si existe
algún error en el sistema debe ser notificado al usuario. .

Salida

Mensaje de confirmación del Almacenamiento.

Registro exitoso en la base de datos.

Eliminar la información del vehículo

Se realiza la eliminación del vehículo.

Tipo de requerimiento

Datos

Entrada

Placa
Proceso

El usuario encargado de administrar el sistema busca al vehículo por

medio de la placa del mismo con el fin de garantizar que se elimine el
vehículo deseado. Esta operación debe notificarse al usuario de que si
elimina el registro no existirá en la base de datos.

Salida

Mensaje de confirmación de la eliminación.

Eliminación de datos.

Relacionar al vehículo con el conductor.

Se realiza la vinculación del vehículo con el conductor con el fin de

poder relacionar las rutas recorridas.

Tipo de requerimiento

Datos

Entrada

placa, cédula

Proceso

El usuario que administra el sistema realiza la vinculación entre el

vehículo y el conductor una vez que ambos hayan sido creados, el
sistema debe confirmar que la vinculación es la correcta.

Salida

Mensaje de confirmación de la vinculación.

Registro exitoso en la base de datos.

Registrar las Salidas por mes

Se registran las salidas que tiene cada vehículo dependiendo la
cantidad de pasajeros que necesitan para dicho fin.

Tipo de requerimiento

Datos

Entrada

Lugar, objetivo de la salida, carrera universitaria, Fecha de partida,

fecha de llegada, distancia en Kilómetros, cantidad de pasajeros.

Proceso

El usuario que administra el sistema realiza la búsqueda de vehículos

disponibles basado primero en disponibilidad por fecha y cantidad de
pasajeros, una vez que verifica la disponibilidad, almacena los datos
dentro del sistema, el sistema debe confirmar con el usuario la
programación que realizo.

Salida

Mensaje de confirmación de la reserva del vehículo.

Registro exitoso en la base de datos.

Validar el tipo de salida dentro o fuera de la ciudad.

El sistema una vez que realiza la reserva del vehículo valida el destino
del mismo y si es válido para la condición establecida.

Tipo de requerimiento

Datos

Entrada

Lugar, carrera universitaria.

Proceso
El sistema realiza la comparación entre el lugar de destino y la carrera
si es dentro del departamento y es para alguna de las carreras de
enfermería, ambientales, minas y desarrollo de software aprobará el
recorrido, de lo contrario alertará que no es posible el viaje, si existe
algún error en el sistema debe ser notificado al usuario.

Salida

Mensaje de confirmación destino.

Registro exitoso en la base de datos.

Establecer el valor de los viáticos

Para el valor de los viáticos toma como referente el destino y la ruta

para indicar cuánto dinero debe ser dado al conductor.

Tipo de requerimiento

Datos

Entrada

Destino, placa

Proceso

El sistema con base en el destino calcula por medio de un mapa la

ruta y por lo tanto la distancia que va a recorrer el vehículo, realiza la
consulta del salario del conductor asignado y con este dato y la
distancia recorrida calcula el valor de los viáticos, si existe algún error
en el sistema debe ser notificado al usuario.

Salida

Valor de los viáticos

Valor del consumo de combustible por cada vehículo

El sistema hace un cálculo aproximado del combustible que va a

consumir y del valor promedio de la gasolina, luego en el recorrido el
conductor alimenta en el sistema el valor real consumido en el
recorrido.

Calcular la cantidad de combustible gastado y su valor aproximado.

El sistema toma los datos de destino y distancia que va a recorrer con

el valor aproximado de la gasolina y hace un cálculo del combustible
necesario y el valor.

Tipo de requerimiento

Datos

Entrada

Lugar, valor aproximado gasolina, kilómetros/galón,

Proceso

El sistema hace los cálculos de los kilómetros que va a recorrer el

vehículo, calcula el combustible gastado aproximadamente basado en
el consumo del vehículo y con el valor aproximado del combustible
hace el calculo de cuanto va a valer la gasolina. Si existe algún error
en el sistema debe ser notificado al usuario.

Salida

Registro en la base de datos del valor del combustible aproximado.

Registro de la cantidad de combustible gastado y su valor

aproximado.

El conductor registra los valores y cantidades de combustible gastado

durante el recorrido.

Tipo de requerimiento

Datos

Entrada
valor del galón, cantidad de galones comprados, recibo de pago.

Proceso

El conductor registra en el sistema la cantidad de galones comprados

y su valor, también toma fotografía del recibo de pago, para ello el
vehículo contará con un dispositivo que permita el ingreso y captura
de estos datos. Si existe algún error en el sistema debe ser notificado
al usuario.

Salida

Registro de valor del combustible gastado.

Mensaje de almacenamiento de datos exitoso.

Número de peajes pagados.

El sistema hace un cálculo aproximado del combustible que va a

consumir y del valor promedio de la gasolina, luego en el 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 la ruta establecida y determina los peajes existentes

para establecer el costo de total de los peajes

Tipo de requerimiento

Datos

Entrada

Ruta, peajes.

Proceso

El sistema hace los cálculos de los peajes que existen en la ruta

trazada y calcula el valor total a pagar. Si 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.

El sistema solicita al conductor la captura del recibo de pago del

peaje.

Tipo de requerimiento

Datos

Entrada

Captura del peaje

Proceso

El sistema calcula la llegada del peaje y luego de pasar por 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 alguna solicitud.
2. El software debe correr con menos de la capacidad instalada en
el hardware de los dispositivos que administran 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 está en un
recorrido.

Culturales
1. El sistema debe usar un idioma sencillo de entender.

Legales
1. Debe cumplir con las normas de seguridad implementadas en
Colombia.
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 sistemas.

Seguridad
1. Debe proteger los datos durante el tránsito y almacenamiento
de los mismos.
2. Debe garantizar la autenticación de los usuarios que acceden 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 adquiera la institución.
2. El sistema debe tener la capacidad de administrar la
información de nuevos conductores y vehículos.
3. El sistema debe ser fácil de acceder y estar en la web.

Extensibilidad
1. En un 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 sistemas como 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 del
mismo.

Modelo-Vista-Controlador
Modelo-vista-controlador es un patrón de arquitectura de software,
que separa los datos y 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 eso 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 la representación visual de los datos, todo lo que tenga que ver
con la interfaz gráfica va aquí. Ni el modelo ni el controlador se
preocupan de cómo se verán los datos, esa responsabilidad es
únicamente de la vista.

Calidad del producto software

La norma 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, conocida como SQuaRE (System and Software Quality

Requirements and Evaluation), es una 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 (Sofware Quality Assurance o Aseguramiento de la Calidad

del Software) implica revisar y auditar los productos y actividades de
software para verificar que se cumplen los procedimientos y los
estándares, además de proveer a las gerencias apropiadas
(incluyendo a la de proyectos) con los resultados de estas revisiones.
Por lo tanto, SQA envuelve al PROCESO de desarrollo de software
completo: monitoreando y mejorando el proceso; asegurándose que
cualquier estándar y procedimientos adoptados sean seguidos; y,
asegurándose que los problemas sean encontrados y tratados.

Rol de SQA

El rol para SQA es brindar a Metodología de Desarrollo de Software la

administración la seguranza de que procesos oficialmente
establecidos están siendo implementados. Y asegura que:
1. Una apropiada 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 que se aprueben
6. Cualquier deficiencia y desviaciones sean identificadas y
llevadas con atención a la administración.

Muchas gracias por su atención.