Arquitectura del Sistema - tp2-20101

3.1.1 Requerimientos No Funcionales
3.1.2.1.
Usabilidad
1-RNF-01 Auto Aprendizaje. El sistema permitirá a los usuarios su aprendizaje de manera
intuitiva, sin necesidad de una capacitación previa.
1-RNF-02 Acciones en caso de error. En caso de error del usuario el sistema informará
claramente: el mensaje del error y la solución.
1-RNF-03 Documentación. Elaborar manuales de usuario del sistema.
1-RNF-04 Uso de Estándares. El sistema se ajustará a los estándares del negocio. Todos los
mensajes informativos, advertencia y error deben estar estandarizados y deben ser expresados en
un lenguaje sencillo y entendible por los usuarios.
1-RNF-05 Capacitación. Se requiere que después de 2 semanas que dure la capacitación a los
usuarios la aplicación pueda ser utilizable sin mayor dificultad por los usuarios de Almacén y
Logística.
3.1.2.2.
Confiabilidad
1-RNF-06 Seguridad de las transacciones. Los módulos que se desarrollen bajo la plataforma
Web tendrán el protocolo HTTPS (Protocolo seguro de transferencia de hipertexto), el cual está
destinado a la transferencia segura de datos de hipertexto.
1-RNF-07 Posterior a la puesta en producción la aplicación el ratio de defectos críticos por líneas
de código no debe ser mayor del 2%.
1-RNF-08 Disponibilidad del sistema. El sistema debe estar disponible los 365 días del año, 24
horas al día, con un margen de error del 3%, con una ventana de mantenimiento diario para poder
generar backups de la base de datos.
1-RNF-09 Tiempo de solución para fallas de hardware. El tiempo promedio de solución de una
falla de hardware del servidor de datos no excederá las 8 horas El diseño debe considerar que el
sistema debe poder ejecutarse en otro servidor de datos en el que se haya realizado un restore de
la información.
3.1.2.3.
Rendimiento
1-RNF-10 Tiempo de respuesta promedio del sistema. El tiempo de respuesta promedio del
sistema para las operaciones involucradas es de 3 segundos
.
1-RNF-11 Concurrencia de usuario. El sistema desarrollado deberá trabajar sin problemas con
una concurrencia máxima de 150 usuarios. El diseño debe considerar un RDBMS capaz de
soportar 150 usuarios concurrentes.
1-RNF-12 Cantidad promedio de transacciones por minuto. El
promedio de 50 transacciones por minuto
sistema
debe
soportar
un
El diseño debe considerar un RDBMS capaz de
soportar 50 transacciones concurrentes en un minuto. Demandará pruebas de stress en el plan de
pruebas.
1-RNF-13 La carga de datos que se transmita a través de la red de comunicación no debe superar
más de 2MB por transacción.
3.1.2.4.
Soporte
1-RNF-14 Sistemas operativos soportados. El sistema será
Windows XP profesional o superior.
compatible con plataformas
El diseño debe considerar que el cliente del sistema debe
ser compatible con el SO indicado.
1-RNF-15 Mecanismos de actualización automática. El sistema debe incluir un mecanismo que
permita su actualización automática sin la intervención del usuario
El diseño debe considerar
las restricciones de seguridad que pueda tener la red del cliente, con el fin de implementar el
mecanismo solicitado.
1-RNF-16 Alineación con los sistemas de la Corporación. El sistema debe alinearse con la red
implementada en la empresa y no deberá generar conflicto con las aplicaciones existentes
.
1-RNF-17 Requerimientos mínimos. El sistema debe trabajar sobre cualquier computador que
cuente con los requerimientos mínimo de procesador Pentium IV o superior, 1 Gb de memoria
RAM y disco duro de 60 Gb.
1-RNF-18 Arquitectura lógica. La arquitectura lógica deberá considerarse como mínimo en dos
capas El diseño debe considerar la construcción del sistema en capas. Permitirá el
encapsulamiento y reutilización.
1-RNF-19 Servidores. Se debe considerar, por lo menos, un servidor de aplicación y uno de base
de datos.
1-RNF-20 Motor de Base de Datos. El servidor debe base de datos debetener instalado la base
de datos SQL Server.
1-RNF-21 Escalabilidad de Hardware. La infraestructura de servidores debe ser escalable bajo la
estrategia scale-up (añadir más recursos al servidor) inicialmente y luego scale-out (añadir más
servidores), según las necesidades de procesamiento.
1-RNF-22 Balanceo de Carga. Para el balanceo de carga se trabajará en un entorno de clúster
compuesto por nodos activo - pasivo.
1-RNF-23 Arquitectura de Procesadores. La arquitectura debe ser de 64 bits.
1-RNF-24 Arquitectura de la Red. La tecnología del sistema de almacenamiento debe ser de
fibra a 8Gbps.
1-RNF-25 Soprte de Loging y Debug. Se debe seguir el estándar SYSLOG (mensajes de
conexión) para registrar los sucesos del sistema operativo.
1-RNF-26 El cliente web del sistema debe ser soportado por cualquier navegador.
1-RNF-27 El sistema debe incluir un mecanismo que permita su actualización automática sin la
intervención del usuario.
1-RNF-28 Backups programados: el domingo full y de lunes a sábado incremental.
1-RNF-29 Generar dos tipos de backups, uno histórico, el cuál será almacenado permanentemente
y otro de que almacenará información con una antigüedad no mayor a 1 mes.
1-RNF-30 El medio de almacenamiento para los backups debe ser cintas LTO 4.
1-RNF-31 Existirá un Log de todas las transacciones realizadas, detallando el tipo de movimiento,
la hora y fecha, y la persona que lo ha realizado.
1-RNF-32 Se mantendrá una matriz de trazabilidad entre los requerimientos y las unidades de
programación codificadas de esta forma que podrá hacer una traza los cambios requeridos al
hacer una modificación a una funcionalidad de la aplicación.
1-RNF-33 Se requiere contar con un esquema de soporte de atención de incidentes en producción
que este sujeto a un SLA, para errores críticos en producción el tiempo máximo de reparación será
de 6 horas, para otros casos será de 24 horas.
3.1.2.5.
Restricciones de Diseño
1-RNF-34 Seguridad de la aplicación
La seguridad de la aplicación controlara el acceso a todas las opciones del sistema haciendo uso
de un identificador del usuario (User Id) y una clave (Password).
1-RNF-35 Seguridad de la accesibilidad de los datos
Los usuarios no accesaran directamente a la base de datos, solo ejecutaran opciones de la
aplicación, siendo transparente los componentes que se utilizan, garantizándose de esta manera la
protección de la base de datos.
1-RNF-36 Integración con Excel
El sistema debe contemplar la funcionalidad que permita exportar los resultados de reportes y
consultas hacia la interfase de Hoja de Cálculo de ofimática.
1-RNF-37 Los procesos en lotes se ejecutará a través de servicios Windows cuya programación
sea configurable.
1-RNF-38 Documentación de Usuario y Sistema de Ayuda
1-RNF-39 Se debe contar con un Manual de Usuario el cual estará publicado para los usuarios.
1-RNF-40 Se contará con un esquema de ayuda interactiva a través de la aplicación (F1).
1-RNF-41 Dispositivos de salida de las impresiones
La aplicación permitirá la impresión de los reportes en dispositivos de
formato láser, tinta y
matricial.
3.1.2.6.
Componentes Adquiridos
No aplica
3.1.2.7.
Interfases
Interfases de Usuarios
1-RNF-42 El diseño de la interfaz gráfica del sistema se alineará al estándar definido por el
supermercado.
1-RNF-43 El logotipo estará siempre presente en la parte superior izquierda de todas las páginas.
1-RNF-44 El tipo de letra general será Arial de tamaño 10. Para los reportes se usará el mismo
tamaño en la cabecera y el tamaño 8 para el detalle de los mismos.
1-RNF-45 El ancho de la página se limita a un tamaño de pantalla mínimo de 800x600 píxel sin
scroll horizontal.
1-RNF-46 Las barras de scroll se activarán una vez que el texto sobrepase este límite.
1-RNF-47 Los gráficos que se presenten en las interfaces, tendrán un peso no mayor a los 100 kb.
1-RNF-48 Los reportes mostrarán el logotipo y nombre de la empresa Supermercados UPZ.
3.1.2.8.
Interfases de Hardware
1-RNF-49 Se contará con balanceo de carga en lo servidores Web utilizando SLB (Balanceo a
través de red) utilizando protocolo TCP/IP.
1-RNF-50 Se contará con Clustering en la base de datos a través de redundancia de cajas.
3.1.2.9.
Interfases de Software
1-RNF-51 El módulo de abastecimientos proveerá servicios web que serán consumidos por otras
aplicaciones como Servicio al Cliente y Caja.
3.1.2.10. Interfases de Comunicaciones
1-RNF-52 Se utilizará el netSupport como software de comunicación remota entre la oficina central
y las tiendas.
3.1.2.11. Licenciamiento
1-RNF-53 Las licencias de procesador requeridas dependen del chip multi-core específico sobre el
cual está implementado el software Oracle. Estas licencias serán proporcionadas por el cliente.
3.1.2.12. Requerimientos Legales y de Derecho de Autor
No aplica.
3.1.2.13. Estándares Aplicables
No aplica.
Arquitectura de Software
1.1
Metas y restricciones de la arquitectura
1.1.1
Listado de requerimientos no funcionales y restricciones al diseño
Código
Título
CONFIABILIDAD
1-RNF-08
1-RNF-09
Disponibilidad del
sistema
Tiempo de solución
para fallas de
hardware
RENDIMIENTO
Descripción
Impacto
El sistema debe estar
disponible los 365 días del
año, 24 horas al día, con
un margen de error del
3%, con una ventana de
mantenimiento diario para
poder generar backups de
la base de datos.
El diseño debe considerar que
ningún proceso debe ejecutarse
durante el backup diario de la
base de datos. Se debe realizar
un plan de backup y seguir su
plan de ejecución de backups.
El tiempo promedio de
solución de una falla de
hardware del servidor de
datos no excederá las 8
horas
El diseño debe considerar que el
sistema debe poder ejecutarse en
otro servidor de datos en el que
se haya realizado un restore de la
información. Se ha de poder
incorporar un cambio de nombre
de servidor por parámetro.
1-RNF-10
Tiempo de
respuesta promedio
del sistema
1-RNF-11
Concurrencia de
usuario
1-RNF-12
Cantidad promedio
de transacciones
por minuto
Se debe medir el tiempo de los
procesos de acceso a datos y
El tiempo de respuesta
aquellos que pasen la meta de 5
promedio del sistema para
segundos deben ser rediseñados
las operaciones
con el fin de ganar velocidad en
involucradas en la gestión
su tiempo de respuesta.
hotelera es de 5 segundos
Demandará un objetivo a cumplir
en el plan de pruebas.
El sistema desarrollado
El diseño debe considerar un
deberá trabajar sin
RDBMS capaz de soportar 150
problemas con una
usuarios concurrentes.
concurrencia máxima de
Demandará la compra de
150 usuarios
licencias.
El diseño debe considerar un
El sistema debe soportar
RDBMS capaz de soportar 50
un promedio de 50
transacciones concurrentes en un
transacciones por minuto
minuto. Demandará pruebas de
stress en el plan de pruebas.
SOPORTE
1-RNF-14
1-RNF-15
1-RNF-16
1-RNF-17
El diseño debe considerar que el
cliente del sistema debe ser
El sistema será compatible compatible con el SO indicado. Se
Sistemas operativos
con plataformas Windows debe considerar que el aplicativo
soportados
XP profesional o superior. requerirá la instalación de marcos
de trabajo utilizados por la
solución.Net Framework 2.0)
El diseño debe considerar las
restricciones de seguridad que
pueda tener la red del cliente, con
El sistema debe incluir un el fin de implementar el
Mecanismos de
mecanismo que permita su mecanismo solicitado.
actualización
actualización automática
Demandará la habilitación de
automática
sin la intervención del
puertos y accesos necesarios
usuario
para el flujo normal de la
información. Estas actualizaciones
deberían realizarse en horarios
nocturnos.
El diseño debe contemplar la no
eliminación de componentes que
se encuentren en clientes y
El sistema debe alinearse servidores, los procesos largos
Alineación con los
con la red implementada
deben estar contemplados en
sistemas de la
en la empresa y no deberá horarios que no provoquen
Corporación
generar conflicto con las
tropiezo a las aplicaciones
aplicaciones existentes
existentes. Se ha de tener
presente un listado de archivos en
las instalaciones y un squeduler
de tareas
Requerimientos
mínimos
El sistema debe trabajar
sobre cualquier
computador que cuente
con los requerimientos
mínimo de procesador
Pentium IV o superior, 1
Gb de memoria RAM y
El diseño debe considerar el
parque de PC's de la empresa
sobre el mínimo indicado. Se
deben evaluar los componentes a
utilizar.
disco duro de 60 Gb
1-RNF-18
1-RNF-19
Arquitectura lógica
El diseño debe considerar la
La arquitectura lógica
construcción del sistema en
deberá considerarse como
capas. Permitirá el
mínimo en dos capas
encapsulamiento y reutilización.
Servidores
Se debe considerar, por lo
menos, un servidor de
aplicación y uno de base
de datos
El diseño debe implementar el uso
de servidores. Se tiene que
identificar servidores de ambiente
de producción, pruebas y
desarrollo por cada tipo de
servidor utilizado en la aplicación.
1.2
Vistas de casos de uso
1.2.1
Diagrama de Actores
3-ACS-8-Usuario
1-ACS-6-Coordina
dor de Productos
1-ACS-3-Encarga
do de RM
1-ACS-1-Jefe de
Sección
1-ACS-2-Analista
de Compras
1-ACS-4-Controla
dor de Inventario
1-ACS-5-Asistent
e de Almacén
3-ACS-9-Administ
rador del Sistema
1.2.2
Diagrama de CUS núcleo central
1-PQS-1-Adquisiciones
1-ACS-1-Jefe de
Sección
(f rom Actores del Sistema)
...)
1-ACS-1-Jefe de
Sección
1-CUS-03-Actualizar Solicitud de
Pedido
1-CUS-03-Actualizar Solicitud de
Pedido
(f rom Actores del Sistema)
...)
1-CUS-02-Actualizar Proveedores
1-CUS-02-Actualizar Proveedores
1-CUS-04-Actualizar Solicitud de
Pedido de Cotización
1-ACS-2-Analista
de Compras
(f rom Actores del Sistema)
...)
1-ACS-2-Analista
de Compras
(f rom Actores del Sistema)
...)
1-CUS-04-Actualizar Solicitud de
Pedido de Cotización
1-CUS-01-Actualizar y
Seleccionar Cotización ...
1-CUS-01-Actualizar y
Seleccionar Cotización ...
1-CUS-05-Generar Orden de
Compra a Proveedor
1-CUS-05-Generar Orden de
Compra a Proveedor
1-CUS-10-Verificar existencias
(f rom Ingreso y Salida de Productos)
1-CUS-10-Verificar existencias
(f rom Ingreso y Salida de Productos)
1-PQS-2-Ingreso y Salida de Productos
1-CUS-10-Verificar existencias
<<include>>
1-CUS-09-Registrar salida de
productos
<<include>>
1-ACS-3-Encargado
de RM
(from Actores del Sistema)
1-CUS-06-Actualizar Stock de
Productos
<<include>>
1-CUS-08-Registrar Ingreso de
Productos
<<extend>>
1-CUS-07-Generar Guia de
Remisión
1-PQS-3-Inventarios
1-CUS-06-Actualizar Stock de
Productos
(from Ingreso y Salida de Productos)
<<include>>
1-CUS-12-Generar Inv entario Final del Periodo
1-ACS-4-Controlador de
Inv entario
(from Actores del Sistema)
1-CUS-15-Actualizar Stock de
inv entario por v entas del dia
1-ACS-5-Asistente
de Almacén
1-CUS-14-Registrar Inv entario Manual
(from Actores del Sistema)
...)
1-PQS-5-Administración de Reportes
1-ACS-2-Analista
de Compras
(from Actores del Sistema)
...)
1-CUS-22-Emitir Reporte de
Cotizaciones por Solicitud
1.3
Vistas de datos
1.3.1
Diagrama Entidad - Relación
1.4
Mecanismos
1.4.1
Inventario de Mecanismos
Mecanismo
Persistencia
Descripción
Requerimientos no funcionales y restricciones a la
solución del mecanismo
Mecanismo que permite a la
1-RNF-19 Servidores
aplicación enviar consultas hacia
1-RNF-20 Motor de base de datos
una base de datos relacional y
recuperar información de ésta
Mecanismo
Emisión de reportes
Descripción
Requerimientos no funcionales y restricciones a la
solución del mecanismo
Mecanismo que permite emitir
1-RNF-36 Integración con Excel
reportes
1-RNF-41 Dispositivos de salida de las impresiones
para
la
toma
de
decisiones
Mecanismo
Manejo de errores
Descripción
Requerimientos no funcionales y restricciones a la
solución del mecanismo
Mecanismo y política para el
manejo
de
errores
en
1-RNF-02 Acciones en caso de error
la
aplicación
Mecanismo
Manejo de Transacciones
Descripción
Requerimientos no funcionales y restricciones a la
solución del mecanismo
Mecanismo para la gestión de las
transacciones en la aplicación
1-RNF-11 Concurrencia de usuario
Mecanismo
Seguridad
Descripción
Requerimientos no funcionales y restricciones a la
solución del mecanismo
Mecanismo
accesos
al
que
regula
sistema
y
los
1-RNF-34 Seguridad de la aplicación
las
1-RNF-35 Seguridad de la accesibilidad de los datos
autorizaciones para el uso de los
recursos