Estandar IEEE 1471

Impresiones TOSODA Versión: 1.
Fecha:
13/Abril/2020
Estándar IEEE-1471-2000
Portada
Título
Diseño Arquitectónico del Sistema de Impresiones TOSOD – [v1.0 al 13 de 04 de

2021]
Generado por
URIEL ANTONIO GONZÁLEZ CÁRDENAS 180331

JORGE DANIEL HERNÁNDEZ LARA 180788
DIANA SOFÍA PADRÓN MARTÍNEZ 180503
Aprobado por
Ma. de Jesús Alonso Ruiz
Fecha
13/04/2021
1
Impresiones TOSODA Versión: 1.0
Fecha:
13/Abril/2020
Tabla de contenido
1. Introducción ................................................................................................................................ 3
1.1. Propósito ............................................................................................................................. 3
1.2. Alcance ................................................................................................................................ 3
1.3. Usuarios interesados ........................................................................................................... 3
2. Referencias bibliográficas .......................................................................................................... 3
3. Definiciones, Acrónimos y Abreviaturas .................................................................................... 4
4. Descripción General de la Arquitectura ..................................................................................... 4
5. Metas de Arquitectura y Restricciones………………………………………………………………….......………..5
6. Vista de Casos De Uso…………………………………………………………………………………………..…………….11
6.1Diagramas de caso de uso………………………………………………………………………………………..………11

7. Vista Lógica ............................................................................................................................... 13
7.1Diagramas de clases………………………………………………………………………………………………………..13
8. Vista de Desarrollo .................................................................................................................. 14
8.1Capa de Interfaz…………………………………………………………………………………………………………..14
9. Vista Física (despliegue) ........................................................................................................... 15
9.1 Capa Cliente ...................................................................................................................... 15
10. Vista de Procesos (secuencia) .................................................................................................. 16
10.1 Proceso Inicio Sesión ......................................................................................................... 16
10.2 Proceso Registro ................................................................................................................ 17
10.3 Proceso de Impresion........................................................................................................ 18
11. Tamaño y Rendimiento ............................................................................................................ 19
12. Calidad .................................................................................................................................... 1
2
Fecha:
13/Abril/2020
1. Introducción
Cuando se habla de soluciones a problemas cotidianos o no cotidianos siempre se puede contar
con softwares que ayuden a tener una solucion mas rapido y sencilla. En nuestro caso la
preocupacion que teniamos de las impresiones fue la motivacion para crear impresiiones TOSODA
que ayudaria a las filas largas, a mandar a imprimir desde tu casa o desde otro salon, etc.
1.1. Propósito
Nuestro proposito es lograr que la gente pueda imprimir desde su casa o desde cualquier salon de
una escuela para que evite las largas filas.
Queremos que se eviten los problemas de feria ya que al manejar nuestra forma de pago en pesos
virtuales puedes comprar impresiones y solo ir por ellas.
Nuestro propósito es facilitar a la gente las impresiones rápidas y de calidad, evitar las filas largas y
la falta de cambio. Vamos dirigidos a todos los que quieran imprimir cosas, madres o padres que
imprimen las tareas de sus hijos, estudiantes que llegan tarde y deben imprimir sus proyectos,
trabajadores que quieran imprimir cantidades grandes de documentos y negocios que quieran
nuestra interfaz o servicio de impresiones.
1.2. Alcance
Nuestro alcance es amplio, queremos llegar a las escuelas, empresas grandes que necesiten
servicios de impresiones, pequeños negocios que quieran unirse a ser parten de un punto de
impresión con sus impresiones, a todas las familias, casas donde se necesite imprimir.
1.3. Usuarios interesados

Todos los que estudien o trabajen pueden estar interesados, todos necesitamos impresiones, pero
sobre todo, todos queremos impresiones rapidas y poder pasar por ellas cuando queramos.
2. Referencias bibliográficas
Sommerville, I. (2011). Requerimientos del software: Ingeniería de software.

https://librosysolucionarios.org/ingenieria-delsoftware-9na-edicion-ian-sommerville/
Shankar R. (2021). 10 Best Java Frameworks.

https://hackr.io/blog/javaframeworks#:~:text=A%20Java%20framework%20is%20specific,as%20in
teract%20with%20system%20software
Canarias G. (2019). Ubuntu Linux

https://www3.gobiernodecanarias.org/medusa/ecoescuela/seguridad/ciudadania-yseguridad-
tic/principios-legales/softwarelibre/ubuntu-linux/
3
Fecha:
13/Abril/2020
3. Definiciones, acrónimos y abreviaturas
Software: Software es un término informático que hace referencia a un programa o conjunto de

programas de cómputo, así como datos, procedimientos y pautas que permiten realizar distintas
tareas en un sistema informático.
Hardware: es el chasis del ordenador, los cables, los ventiladores, los periféricos y todos los
componentes que se pueden encontrar en un dispositivo electrónico. La Real Academia Española
lo define como «Conjunto de los componentes que integran la parte material de una
computadora».
IEEE: El Instituto de Ingenieros Eléctricos y Electrónicos (conocido por sus siglas IEEE, leído i-triple-
e en Hispanoamérica o i-e-cubo en España; en inglés Institute of Electrical and Electronics
Engineers) es una asociación mundial de ingenieros dedicada a la normalización y el desarrollo en
áreas técnicas.
Impresión: La impresión es el proceso y resultado de reproducir textos e imágenes, generalmente

con tinta sobre papel.
Framework: Un entorno de trabajo (del inglés framework), o marco de trabajo es un conjunto

estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular
que sirve como referencia, para enfrentar y resolver nuevos problemas de índole similar.
Linux: Se refiere al uso que se le da al sistema operativo GNU/Linux, coloquialmente llamado

"Linux" al ser instalado en un computador personal. El término está destinado a clarificar el uso
personal del computador de otros roles, como, por ejemplo, usar Linux en un servidor. Los dos
roles son similares en el núcleo, porque los dos están basados en el núcleo Linux.
4. Descripción genera de la arquitectura
Queremos que sea un software sencillo de entender, dinámico, con todas las cosas necesarias, con
todos los elementos especiales que el cliente pida y sobre todo funcional a todo el público. Debe
ser fácil de entender hasta al punto de que un niño pueda usarla para su escuela.
Queremos un software capaz de conectar a todos por medio de una pagina web a distintas
impresoras de nuestra marca para poder imprimir desde sus casas y solo tener que pasar por ellas.
Todos podrán imprimir desde donde sea mientras estén inscritos y mientras estén impresoras
cerca, se mostrarán mapas donde se encuentren las impresoras para poder pasar por ellas.
Todo pago será en línea, recargando cupones de manera electrónica que se irán descontando de
manera automática en cada impresión.
5. Metas de Arquitectura y Restricciones
4
Fecha:
13/Abril/2020
Clasificación Descripción Requerimientos

Usabilidad Se enfoca a las RU1 – La página web debe poder
características de usarse de la forma más fácil e intuitiva
estética y consistencia posible.
en las interfaces
gráficas RU2 - La resolución mínima para una
buena visualización del sistema será de
800x600 píxeles.
RU3- El sistema debe permitir ser

usado intuitivamente por cualquier
usuario
RU4-Si falla el sistema de cobro este le

avisara inmediatamente al usuario.
Fiabilidad Se enfoca con las RF1– El software podrá estar en
características como funcionamiento las 24 horas en caso de
disponibilidad (el ser necesario.
tiempo disponible del
sistema), exactitud de RF2– La capacidad de recuperación de
los cálculos del preferencia debe ser alta para que en
sistema, y las caso de cualquier error
habilidades del sistema
para recuperarse
RF3– En caso de falla software podrá
durante fallos.
volver a funcionar lo más pronto posible
para evitar contratiempo o posibles
problemas con usuarios.
RF4– Se procura que no haya errores

en el software, pero en caso de
presentarlos esperamos que sean
tiempos largos y que haya los menores
posibles, en números esperamos que al
menos haya 2 errores por año con
diferencia de 6 meses, en caso de
presentarlos, pero todo esto es solo una
estimación.
RF5– Esperamos que el sistema pueda

funcionar aun con uno que otro fallo de
impresión o error de validación, así
mismo que este lo pueda arreglar por su
cuenta solo volviendo a realizar la
solicitud.
Rendimiento Se enfoca con las RR1– El sistema debe demorarse no
características como más de 5 segundos en hacer la
tiempo de respuesta, solicitud de impresión y validarla.
tiempo de iniciación y
término.
5
Fecha:
13/Abril/2020

RR2– El sistema requiere tener una
velocidad satisfactoria para el usuario,
que de preferencia sea alta pero en
cualquier caso debería ser al menos
buena para que no haya problemas
con el usuario.
RR3– Necesitamos que el software

sea eficiente al uso de los usuarios, sin
problemas de rendimiento.
RR4– El servidor debe estar disponible

en todo momento en caso de cualquier
cosa, por si algún usuario requiere
hacer uso del servicio.
RR5– Necesitamos que el servicio sea

preciso a la hora de brindarle el
servicio a los usuarios, procurar no
equivocarnos de usuario al momento
de esto.
RR6– El servidor siempre va a estar en

funcionamiento y sin importar la
cantidad de usuarios que estén
solicitando su uso, este debe de
realizar el funcionamiento de calidad,
que se espera del servicio.
RR7– El servidor debe de estar hecho

para responder de manera rápida y
eficiente en todos los casos.
RR8– En caso de cualquier error falla o

percance dentro del servidor, este
debe poder recuperarse lo mas pronto
posible.
RR9– El servidor al encontrarse en un

dispositivo viejo no debe de usar
muchos recursos para no provocar la
falla en el mismo.
Soporte Se concentra en las RS1- La mantenibilidad debe formar
características como parte integral del proceso de desarrollo
pruebas, portabilidad, del software. Las técnicas utilizadas
adaptabilidad, deben ser lo menos intrusivas posible
mantenimiento, con el software existente. Por lo que es
configuración, necesario identificar la aplicación de
6
Fecha:
13/Abril/2020

instalación, metodologías de ingeniería del
escalabilidad, y software y el seguimiento de
localización. estándares, que incorporen
intrínsecamente modelos estructurados
de diseño y código. Se debe
considerar la facilidad para la
realización de las pruebas técnicas y
de aceptación.
RS2- Se requiere la Cesión de

Derechos de uso sobre el software
implantado y todos sus componentes.
RS3- Se debe especificar la definición

y el manejo de la documentación
técnica (manuales técnicos y de
instalación) y funcional (manuales de
administración, configuración y de
usuario final) del sistema de
información, establecer procedimientos
claros de actualización y aprobación.
RS4- Se debe de realizar un

mantenimiento periódico de al menos 1
mes y más tardar 2 para procurar el
buen funcionamiento y evitar fallos o
errores, el cual consiste en 3 partes,
verificación del estado físico de las
impresoras, servidor y cableado,
revisar el estado interno del servidor y
borrar los documentos que recibe a
imprimir y dar mantenimiento a la
página web para evitar saturaciones o
posibles amenazas.
El mantenimiento solo puede ser

realizado por un desarrollador para
asegurar que se realice correctamente
el mantenimiento.
RS5- Se planea el uso de java

framework para el desarrollo de la
página web y esto hace que el
software al encontrarse en internet se
vuelve portable a cualquier quipo que
tenga acceso a internet, dispositivos
móviles, computadores de escritorio,
portátiles, etc. Por lo tanto, el sistema
operativo de los dispositivos no
7
Fecha:
13/Abril/2020

representa una limitante para los
usuarios para poder usar nuestro
software.
Consideraciones Especifica las opciones RCD1- El sistema se basa en el
de diseño del diseño para el servidor Linux y la página web.
sistema.
RCD2- El sistema considera una
arquitectura cliente servidor.
RCD3- La base de datos será MySQL

en su versión 5. Esta será centralizada
y provista por el Usuario.
Requerimientos de Especifica la RI1- Para el servidor se requiere el uso

implementación codificación o de Linux Ubuntu
construcción del
sistema, pueden ser RI2- La página web será desarrollada
estándares, con el uso del Framework de java con
implementaciones, su estándar correspondiente.
lenguajes y límites de
los recursos. RI3 – Impresoras en buen estado
Requerimientos Especificaciones RF15 - El sistema debe trabajar sobre
físicos físicas impuestas por cualquier computador que cuente con
el hardware usado estos requerimientos mínimos: con
para mantener el procesador Intel core i3 o superior, 500
sistema. Mb de memoria RAM y disco duro de
20 Gb de almacenamiento, aunque
una raspberry seria lo ideal.
RF16 – Al menos una impresora de

cualquier tipo, en buen estado y
funcional para brindar el servicio
Seguridad Especifica los RS1- Para mantener la integridad tanto

requerimientos de del software como del servidor
seguridad que deben planeamos utilizar marcos de trabajo
tener el sistema y sus que previenen automáticamente los
características ataques XSS, validar los datos que se
generales para reciben, prevenir los ataques CSRF,
asegurar el software. evitar las inyecciones de código,
utilizar LIMIT y otros controles SQL
para evitar la fuga masiva de datos en
caso de inyecciones SQL, validar la
entrada de datos al servidor utilizando
“listas blancas” y cifrar los datos
sensibles que sean almacenados.
8
Fecha:
13/Abril/2020

RS2- Para mantener la
confidencialidad del servidor tenemos
que proteger las conexiones
autenticadas o que involucren
funciones o información relevante,
evitar mostrar referencias hacia objetos
internos de la aplicación, evitar mostrar
mensajes con información que ayude a
recopilar información sobre el producto
o las configuraciones del servidor,
evitar la elevación de privilegios en las
cuentas de usuarios, revisar todos los
elementos de la infraestructura para
asegurar que no contengan ninguna
vulnerabilidad conocida, así como las
herramientas administrativas usadas
para el mantenimiento de los diferentes
componentes, evitar almacenar datos
sensibles de manera innecesaria,
deshabilitar el almacenamiento en
caché de datos sensibles.
RS3- Para la disponibilidad del

software hay que realizar estudios
sobre las posibles vulnerabilidades que
se puedan presentar en la tecnología a
utilizar en el desarrollo, utilizar
tecnologías seguras para el mismo,
cumplir los requisitos exclusivos de los
límites de negocio de las aplicaciones,
controlar el receptor de escucha de las
Bases de Datos, garantizar que el
servidor no envíe directrices o
cabeceras de seguridad a los clientes
o que se encuentren configurados con
valores inseguros, actualizar las
configuraciones apropiadas de la
tecnología usada de acuerdo a las
advertencias de seguridad y seguir un
proceso de gestión de parches, utilizar
una herramienta para mantener un
inventario y control de versiones de los
componentes, utilizar componentes
únicamente de orígenes oficiales y
utilizando los canales seguros, analizar
riesgos y vulnerabilidades del entorno
de despliegue del cliente atendiendo a
sus características.
9
Fecha:
13/Abril/2020

RS4- Cifrar todos los datos en tránsito
utilizando protocolos seguros,
identificar o firmar de forma única los
mensajes intercambiados, almacenar
los mensajes intercambiados en
ficheros logs para su posterior
consulta.
RS5- Evitar mantener credenciales

creadas por defecto, débiles o muy
conocidas especialmente en el caso de
los administradores del sistema, definir
mecanismos de autenticación
personalizado para todos los usuarios,
evitar utilizar cuentas suministradas
por defecto, evitar ataques de fuerza
bruta y/o ataques automatizados,
utilizar controles contra contraseñas
débiles, alinear la política de longitud,
complejidad y rotación de las
contraseñas establecidas, limitar el
tiempo de respuesta de cada intento
fallido de inicio de sesión, controlar el
ciclo de vida de las contraseñas,
restringir el acceso de un usuario
estándar (no administrador) a modificar
sus privilegios en la aplicación o los de
otro usuario con su mismo rol, cerrar
automáticamente la sesión de un
usuario cuando ha estado inactivo
durante un cierto lapso de tiempo,
destruir el ID de sesión luego de salir o
cerrar el sistema.
10
Fecha:
13/Abril/2020
6. Vista de Casos De Uso
Engloba los Casos de Uso que describen el comportamiento del sistema como lo verían los
usuarios finales, los analistas y demás componentes del equipo de desarrollo.
Un diagrama de casos de uso representa las interacciones entre el sistema y los sistemas externos
y los usuarios. En otras palabras, describe gráficamente quién utiliza el sistema y la forma en que
los usuarios esperan interaccionar con el sistema.
Los diagramas de caso de uso siguen las especificaciones del Lenguaje de Modelado Unificado
(UML).
6.1. Diagramas de caso de uso
Autenticación Descarga
doc.
Imprimir
Solicita
impresion
Documento
físico
11
Fecha:
13/Abril/2020
Manda datos
Agregar de tarjeta
saldo
Validar
deposito
Agrega
saldo
Agregar Efectivo
saldo
Asigna local
Paga la Agrega
referencia saldo
Validar
deposito
Da de alta
Solicitud de dar
de alta
12
DOCUMENTO DE ARQUITECTURA DE SOFTWARE Fecha: 13/Abril/2020
7.-Vista Lógica
Pagina Web
• Visitas
• Inicios de sesion
• Registros
Usuarios
• Nombre de usuario
• Contraseña
• Numero de documentos impresos
• Numero de documentos especiales Impresos
Documentos (Temporal) borrados cada 30 días

• Tamaño
• Numero de Paginas
• Dueño
• Si fue impreso o no
13
8.-Vista de Desarrollo
8.1 Capa de Interfaz
14
9.-Vista Fisica (Despliegue)

9.1 Capa Lógica de Negocio
15
10.-Vista de Procesos
10.1 Proceso de Inicio de Sesión
16
10.2 Proceso de Registro
17
10.3 Proceso de Impresión
18
11.- Tamaño y Rendimiento

Este apartado puede ser bastante dinámico, dependiendo de el presupuesto del cliente puede variar el rendimiento del servidor y el tamaño del
mismo, si el cliente va a ahorrar un poco en gastos para el servidor entonces el limite de el rendimiento de el servidor se verá mas
“comprometido”, lo mismo para el tamaño del mismo, este puede ser dependiendo del gusto del cliente.
El dispositivo en el cual se encuentra el servidor de Linux Ubuntu es una laptop hp con 4 GB ram, soporta Sistemas Operativos x32 y x64,
tiene 500 de disco de almacenamiento interno, estas caracteristicas son de sobra para lo requerido del sftware. La impresora que se encuentra
conectada al servidor es una hp Deskjet3050 en buenas condiciones, lo ideal seria usar como servidor un rasberry que ocuparia menos
espacio tanto fisico como interno y usar impresoras reclicladas.
12.- Calidad
La laptop hp tiene una buena calidad en cuestiones de software, pero en hardware se encuentra en mala condiciones, la pantalla esta pronto a
desprenderse, le falta la tecla del touchpad y se le cayo el puerto DVD, por otra parte la impresora Deskjet se ecuentra en perfectas condiciones,
a pesar de su modelo presento fallas para vincularse de manera inalambrica a la red, por lo tanto se decidio usarla para el proyecto y conectarla a
internet, posibles fallos si no se imprime en cierto tiempo ya que se seca la tinta muy rapido y esto puede generar gartos extra.
19

Estandar IEEE 1471

Cargado por

Información del documento

Descripción 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

Estandar IEEE 1471

Cargado por

Copyright:

Formatos disponibles

Impresiones TOSODA Versión: 1.

Diseño Arquitectónico del Sistema de Impresiones TOSOD – [v1.0 al 13 de 04 de

URIEL ANTONIO GONZÁLEZ CÁRDENAS 180331

6. Vista de Casos De Uso…………………………………………………………………………………………..…………….11

6.1Diagramas de caso de uso………………………………………………………………………………………..………11

1.3. Usuarios interesados

Sommerville, I. (2011). Requerimientos del software: Ingeniería de software.

Shankar R. (2021). 10 Best Java Frameworks.

Canarias G. (2019). Ubuntu Linux

3. Definiciones, acrónimos y abreviaturas

Software: Software es un término informático que hace referencia a un programa o conjunto de

Impresión: La impresión es el proceso y resultado de reproducir textos e imágenes, generalmente

Framework: Un entorno de trabajo (del inglés framework), o marco de trabajo es un conjunto

Linux: Se refiere al uso que se le da al sistema operativo GNU/Linux, coloquialmente llamado

4. Descripción genera de la arquitectura

5. Metas de Arquitectura y Restricciones

Clasificación Descripción Requerimientos

RU3- El sistema debe permitir ser

RU4-Si falla el sistema de cobro este le

RF4– Se procura que no haya errores

RF5– Esperamos que el sistema pueda

Clasificación Descripción Requerimientos

RR3– Necesitamos que el software

RR4– El servidor debe estar disponible

RR5– Necesitamos que el servicio sea

RR6– El servidor siempre va a estar en

RR7– El servidor debe de estar hecho

RR8– En caso de cualquier error falla o

RR9– El servidor al encontrarse en un

Clasificación Descripción Requerimientos

RS2- Se requiere la Cesión de

RS3- Se debe especificar la definición

RS4- Se debe de realizar un

El mantenimiento solo puede ser

RS5- Se planea el uso de java

Clasificación Descripción Requerimientos

RCD3- La base de datos será MySQL

Requerimientos de Especifica la RI1- Para el servidor se requiere el uso

RF16 – Al menos una impresora de

Seguridad Especifica los RS1- Para mantener la integridad tanto

Clasificación Descripción Requerimientos

RS3- Para la disponibilidad del

Clasificación Descripción Requerimientos

RS5- Evitar mantener credenciales

6. Vista de Casos De Uso

6.1. Diagramas de caso de uso

DOCUMENTO DE ARQUITECTURA DE SOFTWARE Fecha: 13/Abril/2020

Documentos (Temporal) borrados cada 30 días

DOCUMENTO DE ARQUITECTURA DE SOFTWARE Fecha: 13/Abril/2020

DOCUMENTO DE ARQUITECTURA DE SOFTWARE Fecha: 13/Abril/2020

9.-Vista Fisica (Despliegue)

DOCUMENTO DE ARQUITECTURA DE SOFTWARE Fecha: 13/Abril/2020

DOCUMENTO DE ARQUITECTURA DE SOFTWARE Fecha: 13/Abril/2020

10.2 Proceso de Registro

DOCUMENTO DE ARQUITECTURA DE SOFTWARE Fecha: 13/Abril/2020

10.3 Proceso de Impresión

DOCUMENTO DE ARQUITECTURA DE SOFTWARE Fecha: 13/Abril/2020

11.- Tamaño y Rendimiento

También podría gustarte