ACTIVIDAD EVALUATIVA EJE 2 Ingenieria de Sotfware [PDF]

Zitiervorschau

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. 3.

No interacción mientras se está conduciendo. 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. 3.

El sistema debe tener la capacidad de administrar la información de nuevos conductores y vehículos. 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. 6.

Se realicen pruebas y que se aprueben Cualquier deficiencia y desviaciones sean identificadas y llevadas con atención a la administración. Muchas gracias por su atención.