Act 2 Ing. Soft 1

FUNDACIÓN UNIVERSITARIA ÁREA ANDINA
PRÁCTICA DE REQUERIMIENTOS Y ARQUITECTURA
ELABORADO POR:
MIGUEL ÁNGEL GARCÍA LÓPEZ
JHONATAN YESQUEN CUERO
MADY STEVEN MORENO MOSQUERA
LINA MARLENY FARFÁN RUBIO
INSTRUCTOR
ANGEL ALBERTO VARON QUIMBAYO
BOGOTA D.C.
2 DE SEPTIEMBRE DE 2019
INGENIERÍA DE SISTEMAS - MODALIDAD VIRTUAL
INTRODUCCIÓN
Dentro de los requerimientos que se consideran para el desarrollo de un sistema y que se

derivan de los objetivos de negocio, existe un subconjunto que tiene una gran importancia
relativa a la arquitectura. Estos requerimientos se conocen en inglés como drivers de la
arquitectura. El término “drivers” puede traducirse como “guías”, ya que estos
requerimientos “guían” el diseño de la arquitectura del sistema. Una estructuración correcta
del sistema permitirá satisfacer la mayoría de estos drivers.
Los drivers de la arquitectura incluyen principalmente a los atributos de calidad. Además de

esto, incluyen a un subconjunto de los casos de uso que se consideran como primarios. Los
casos de uso primarios son aquellos de mayor importancia o de mayor complejidad para el
negocio. Por último, las restricciones también son consideradas como drivers
arquitecturales.
Por otra parte, los atributos de calidad forman parte de los RNF del sistema. Son
características medibles que permiten expresar y evaluar el grado de satisfacción de los
usuarios y/o diseñadores (es decir la calidad) con respecto al sistema. Cabe señalar que no
son la única métrica de calidad de un sistema, la ausencia de defectos es otra métrica clave
en este rubro. Existen distintas categorías de atributos de calidad y éstas se clasifican con
respecto a la importancia que tienen ya sea para los clientes o para la organización de
desarrollo.
OBJETIVOS
General
Definir la estructura de los componentes, sus relaciones, que garanticen la sana operación
del sistema hoy y a futuro.
Específicos
Reducir los riesgos tecnológicos del proyecto.
Diseñar los componentes de software adecuados que cubran con los requerimientos
funcionales y no funcionales.
Analizar los problemas que se plantean en el desarrollo de sistemas con arquitectura

Enterprise.
Examinar los patrones de diseño conocidos como solución a este tipo de problemas.
Proponer una arquitectura que utilice, adapte e integre a estos patrones, obteniendo un
Framework de trabajo, que permita el desarrollo de una aplicación de tipo Enterprise,
teniendo resueltos a estos problemáticos típicos, permitiendo focalizarse en el problema del
dominio del negocio en sí.
Implementar un Framework y permitir la construcción de una aplicación base completa

sobre el mismo a partir del conocimiento del dominio.
TABLA DE CONTENIDO
Introducción ……………………...………………………………………………………….……... 2
Objetivos …………………………………………………………………………………….…...… 3
Historial de Versiones…………………………………………………………..……….………… 5
Información del Proyecto …………………………………………………….…….…………….. 5
1. Proposito …………………………………………………..……………………..……..……… 5
2. Alcance del producto / Software ……………………………………...…………….………. 6
3. Funcionalidades del producto ………………………………………….…...…….…………. 6
4. Clases y características de usuarios ………………………………….…...….……………. 6
5. Entorno operativo ……………………………………………………….……...…………..... 7
6. Requerimientos funcionales ………………………………………….……...……………... 8

.
7. Requerimientos no funcionales …………………………………….……...………………. 8
Conclusiones ……………………………………………………….…………...……………… 9
Historial de Versiones
Fecha Versión Autor Organización Descripción
02-09-2019 1 Estudiantes
Area Andina
Información del Proyecto
Empresa / Organización Estudiantes Area Andina
Proyecto Inventarios Vehículos
Fecha de preparación 02-09-2019
Cliente Área Andina
1. Propósito
En el siguiente documento se pondrá en contexto los roles, programas y accesos que van a tener los
usuarios al momento de ingresar al software cuando este ya se encuentre finalizado. También se
visualizarán las diferentes interfases que se van a utilizar al momento de realizar el manejo del
software.
2. Alcance del producto / Software
El software se encargará de llevar el control del manejo de la información, de los medios de

transporte que se encuentren afiliados a la Universidad y llevar a cabo el correspondiente pago al
conductor de cada vehículo.
Esto con el fin de tener la información a primera mano de cuales son los vehículos, el conductor,
cantidad de pasajeros, viajes del vehículo e inclusive se guardará un historial de los viajes y bonos
adquiridos por cada conductor.
3. Funcionalidades del producto
El software “Nombre del software” tendrá las siguientes funcionalidades.
1- Crear, Modificar, Eliminar y Asignar usuarios

2- Información del vehículo
3- Información del Conductor
4- Información de los Recorridos
5- Información del Salario, bonos y peajes
4. Clases y características de usuarios
El software tendrá los siguientes roles.
- Administrador
A este perfil tendrán acceso las personas encargadas de recibir las solicitudes de las
diferentes áreas de la universidad y realizará las asignaciones de los vehículos.
- Conductor
A este perfil solo podrán ingresar los conductores de la universidad, en donde visualizarán
la información de los viajes asignados.
5. Entorno operativo
El software trabaja sobre las plataformas de Windows como 7, 8 y 10.
El sistema será compatible para funcionar con los navegadores de mas comunes como
Mozilla firefox, Google Chrome y Internet Explorer
● Almacenamiento de información
- Se necesita tener instalado SQL Server en 1 equipo de cómputo para poder realizar
la instalación y almacenamiento de la información que se carga al software.
● Interfaz Usuarios
- Para acceder a la interfaz y poder realizar algún tipo de trabajo solo es necesario el
ingreso a internet y tener los equipos en una red local.
- Para acceder al software debe ser por medio de la web “Internet”, esto con el fin de
facilitar el uso de todos los usuarios.
- La pantalla del Administrador se visualizará toda la información de los registros de la
base de datos y podrá realizar la generación de la facturación del salario.
- Los campos fecha se maneja DD/MM/AAAA
- Los campos de las unidades
- Los campos del combustible y valores monetarios no se manejan números
decimales para poder llevar su fácil manejo.
● Métodos de Seguridad
- Se manejara un login el cual corresponde a la placa del vehículo y contraseña

- Solo los usuarios administradores pueden crear, eliminar y modificar la información
de la base o realizar la creación de un usuario.
- Se podrá generar un reporte donde se evidencie las fechas de creacion,
modificacion o eliminacion de registros y informara cuál fue el usuario responsable.
6. Requerimientos funcionales
Req 1 - El sistema controlará el acceso y lo permitirá solamente a usuarios autorizados. Los
usuarios deben ingresar al sistema con un nombre de usuario y contraseña.
Req 2 - El sistema permitirá creación, eliminación y reingreso de los registros, sin embargo,
estas solo se pueden realizar por el ya definidos.
Req 3 - El sistema permitirá a los usuarios autorizados el ingresar y validar los cronogramas
Req 4 - El sistema permitirá realizar actualizaciones de la información ya guardada en la

base de datos.
Req 5 - El sistema podrá capturarla información de los viajes realizados y dará un resultado
de los mismos, según la necesidad de los usuarios.
7. Requerimientos no funcionales
Req 1 - La herramienta que manejara almacenamiento de la información será SQL server.
Req 2 - El sistema debe ser capaz de operar sin problemas con al menos 10 sesiones
abiertas al mismo tiempo.
Req 3 - Para ingresar al software se debe tener acceso a internet.
Req 4 - Cualquier modificación se refleja de forma inmediata en el sistema.
Req 5 - Se debe realizar una copia de respaldo de la información cada semana.
Raq 6 - El Sistema contará con su manual correspondiente a cada uno de sus roles de
usuario.
Req 7 - En caso de algún error el sistema informará al usuario cual es el error o informara si
se debe comunicar al área de soporte.
CONCLUSIONES
Con la realización de este trabajo, se definió y validó una arquitectura de software para el
proyecto de la universidad, que permite reducir los problemas de extensibilidad, reusabilidad
y dependencias que presenta la arquitectura sobre la que se desarrollan actualmente los
productos del proyecto. De esta forma se dio cumplimiento al objetivo propuesto al inicio de
la investigación, además:
- La combinación de los estilos arquitectónicos: Arquitectura basada en capas,

Arquitectura basada en componentes y Tuberías y filtros, permitió desarrollar una
arquitectura que satisface los atributos de calidad reutilización y mantenibilidad.
- El análisis de los productos desarrollados, permitió reutilizar los conceptos

fundamentales asociados a una red de flujo de datos (procesadores, puertos, tipos
de datos,programas).
- La configuración dinámica de la red de flujo de datos por parte del usuario, posibilita
crear prototipos rápidos de aplicaciones sin necesidad de conocer el código fuente
de la aplicación, lo que incrementa la versatilidad de los productos del proyecto.
- El Arquitecto de Software es responsable de elegir, justificar y comunicar las

tecnologías más adecuadas para satisfacer la operación sana del sistema.
- Es necesario tener experiencia y otras habilidades además de las habilidades

técnicas para lograr el objetivo.
- El documento de especificación debe ser oportuno, suficiente y claro para poder

usarlo como una guía del desarrollo.
- Realizar una debida calidad del Software y para evitar posibles problemas al
momento de realizar la entrega de la misma.
La relación entre Analistas, desarrolladores clientes y usuarios finales debe ser abierta,
clara, mediadora y sencilla, de tal forma que juntos cubran las necesidades de los
requerimientos funcionales y no funcionales del sistema, para finalmente entregar un
producto de calidad que satisfaga las necesidades y cubra todas las expectativas
esperadas.
De igual manera periódicamente se realizan cortes de prueba en donde podremos al

máximo desempeño el sistema, con el debido acompañamiento de nuestro cliente.

Act 2 Ing. Soft 1

Cargado por

Copyright:

Formatos disponibles

Act 2 Ing. Soft 1

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Act 2 Ing. Soft 1

Cargado por

Copyright:

Formatos disponibles

FUNDACIÓN UNIVERSITARIA ÁREA ANDINA

PRÁCTICA DE REQUERIMIENTOS Y ARQUITECTURA

Dentro de los requerimientos que se consideran para el desarrollo de un sistema y que se

Los drivers de la arquitectura incluyen principalmente a los atributos de calidad. Además de

Reducir los riesgos tecnológicos del proyecto.

Analizar los problemas que se plantean en el desarrollo de sistemas con arquitectura

Implementar un Framework y permitir la construcción de una aplicación base completa

2. Alcance del producto / Software ……………………………………...…………….………. 6

3. Funcionalidades del producto ………………………………………….…...…….…………. 6

4. Clases y características de usuarios ………………………………….…...….……………. 6

5. Entorno operativo ……………………………………………………….……...…………..... 7

6. Requerimientos funcionales ………………………………………….……...……………... 8

Fecha Versión Autor Organización Descripción

Información del Proyecto

Empresa / Organización ​Estudiantes Area Andina

Proyecto ​Inventarios Vehículos

Fecha de preparación 02-09-2019

Cliente Área Andina

El software se encargará de llevar el control del manejo de la información, de los medios de

3. Funcionalidades del producto

El software “Nombre del software” tendrá las siguientes funcionalidades.

1- Crear, Modificar, Eliminar y Asignar usuarios

3-​ ​Información del Conductor

4-​ ​Información de los Recorridos

5-​ ​Información del Salario, bonos y peajes

4. Clases y características de usuarios

El software tendrá los siguientes roles.

El software trabaja sobre las plataformas de Windows como 7, 8 y 10.

- Se manejara un login el cual corresponde a la placa del vehículo y contraseña

Req 4 - ​El sistema permitirá realizar actualizaciones de la información ya guardada en la

7.​ ​Requerimientos no funcionales

Req 1 -​ La herramienta que manejara almacenamiento de la información será SQL server.

Req 3 -​ Para ingresar al software se debe tener acceso a internet.

Req 4 -​ Cualquier modificación se refleja de forma inmediata en el sistema.

- La combinación de los estilos arquitectónicos: Arquitectura basada en capas,

- El análisis de los productos desarrollados, permitió reutilizar los conceptos

- El Arquitecto de Software es responsable de elegir, justificar y comunicar las

- Es necesario tener experiencia y otras habilidades además de las habilidades

- El documento de especificación debe ser oportuno, suficiente y claro para poder

De igual manera periódicamente se realizan cortes de prueba en donde podremos al

También podría gustarte

Empresa / Organización Estudiantes Area Andina

Proyecto Inventarios Vehículos

3- Información del Conductor

4- Información de los Recorridos

5- Información del Salario, bonos y peajes

Req 4 - El sistema permitirá realizar actualizaciones de la información ya guardada en la

7. Requerimientos no funcionales

Req 1 - La herramienta que manejara almacenamiento de la información será SQL server.

Req 3 - Para ingresar al software se debe tener acceso a internet.

Req 4 - Cualquier modificación se refleja de forma inmediata en el sistema.