Documento de

Arquitectura

de Software
Caballero Hervias, Cristina

Profesor: Hugo Cordero Snchez Carrillo Estrada, Jos Andres

Curso: Arquitectura de Software
Universidad Nacional Mayor de San
Marcos
Facultad de Ingeniera de Software
05/07/2017
Castillo Chvez, Luigi
Rivera Len, Paul
Salazar Vargas, Cesar
Este documento es el resultado de la
definicin de arquitectura de software y
diseo para el Sistema para la red de
colegio San Cristbal que es
desarrollado como parte del Proyecto
Final del Curso de Arquitectura de
Software Aqu estn contenidos los
modelos y diagramas que sirven como
base para el desarrollo del sistema.

1
Contenido
1. Descripcin del sistema......................................................................................................... 3
2. Objetivo del sistema .............................................................................................................. 3
3. Definiciones y convenciones ................................................................................................. 4
4. Arquitectura general del sistema .......................................................................................... 4
4.1. Diagrama de Contexto................................................................................................... 4
4.2. Arquitectura del sistema ............................................................................................... 5
4.3. Tecnologas usadas........................................................................................................ 6
5. Vista del sistema.................................................................................................................... 8
5.1. Vista modular ................................................................................................................ 8
5.2. Vista funcional ............................................................................................................... 9
5.3. Vista de componentes ................................................................................................. 10
5.4. Vista de despliegue ..................................................................................................... 11
5.5. Vista de Integracin .................................................................................................... 12
6. Evaluacin de Arquitectura ................................................................................................. 13
6.1. Atributos de calidad identificados .............................................................................. 13
6.1.1. Escenario de Performance .................................................................................. 13
6.1.2. Escenario de Escalabilidad .................................................................................. 13
6.1.3. Escenario de Confiabilidad .................................................................................. 13
6.1.4. Escenario de Disponibilidad ................................................................................ 13
6.1.5. Escenario de Seguridad ....................................................................................... 14
6.1.6. Escenario de Usabilidad ...................................................................................... 14
6.2. Tcticas a implementar ............................................................................................... 15
6.2.1. Tcticas para Performance .................................................................................. 15
6.2.2. Tcticas para Escalabilidad .................................................................................. 15
6.2.3. Tcticas para Confiabilidad ................................................................................. 15
6.2.4. Tcticas para Disponibilidad ................................................................................ 15
6.2.5. Tcticas para Seguridad....................................................................................... 16
6.2.6. Tcticas para Usabilidad ...................................................................................... 16
6.3. Fortalezas .................................................................................................................... 17
6.4. Puntos de mejoras....................................................................................................... 18
6.5. Recomendaciones ....................................................................................................... 19
7. Glosario ............................................................................................................................... 20
 1. Descripcin del sistema

En el presente documento, se explicar la arquitectura de un sistema propuesto para la red de

colegios San Cristbal ubicados en Lima Metropolitana y provincia constitucional del Callao
que involucra a 180 alumnos y 20 profesores. El sistema podr ser utilizado por 3 tipos de
usuario: administrador, docente y padre de familia. Cada uno de ellos tendr diferentes
perspectivas de las funcionalidades del sistema, las cuales detallamos a continuacin:

1. El administrador podr gestionar la siguiente informacin:

Programacin acadmica
Pagos de pensiones
Registros de notas
Adems, podr generar reportes sobre estos datos.
2. El docente podr registrar la siguiente informacin:
Programacin acadmica
Agenda
Rol de exmenes
Notas
3. El padre de familia podr visualizar la siguiente informacin:
Agenda: Contenido informativo diario respecto a tareas, exmenes u observaciones.
Programacin acadmica
Reglamento interno
Pensiones
Notas
Rol de exmenes
Horario
Informacin de contacto
Referencia a redes sociales
Adems, como funcin adicional, podr realizar pagos de pensiones.

2. Objetivo del sistema

El objetivo principal del sistema propuesto es proporcionar a los padres una nueva herramienta,
con la cual tendrn toda la informacin de las actividades de sus hijos al alcance de las manos,
de esta manera mejorar y facilitar la comunicacin entre colegio, docente y padre de familia.
Ya que en esta etapa crtica, no solo el colegio es el nico involucrado en la educacin sino que
todos los conocimientos deben ser reforzados en casa. Otro punto importante del sistema es el
sistema de pago en lnea ya que facilita a los padres no acercarse directamente a las
instalaciones del colegio sino que lo pueden desde cualquier parte donde estn.

3
 3. Definiciones y convenciones

Para el desarrollo de este documento de arquitectura se hace uso de la notacin UML para la
vista modular, lgica, de componentes, de despliegue. Mientras que para la vista de integracin
se us propia. En el caso de las definiciones de algunas palabras tcnicas se anexa un glosario al
final del documento (Ver Glosario 1)

4. Arquitectura general del sistema

4.1. Diagrama de Contexto

Para plantear la arquitectura del sistema se hizo uso del diagrama de contexto para identificar
las entidades que se relacionan directamente con el sistema propuesto. Como partes
interesadas se identific a los padres de familia que sern los que usaran el sistema para diversas
acciones ya explicadas en la descripcin del sistema, los docentes que utilizan el sistema para
acciones ya explicadas en la descripcin del sistema y los administradores que utilizan el sistema
para acciones ya explicadas; como sistemas externo al negocio identificamos el sistema de pagos
en lnea en cual se podr pagar las pensiones desde el aplicativo mvil o desde el portal. Y como
almacn de datos se hace uso de los repositorios en Excel que sern la primera fuente de
informacin para el sistema.

4
 4.2. Arquitectura del sistema
La arquitectura seleccionada para el desarrollo del sistema es una arquitectura de tres capas.

Identificamos como tres tipos de usuarios: padre de familia o apoderado, docente y

administrador. Todos los usuarios dispondrn de una aplicacin cliente web mientras que el
usuario padre de familia o apoderado contar con un cliente para mvil, estos clientes se
comunicaran con una aplicacin servidor en el cual se encuentra toda la lgica de negocio y ser
intermediaria entre la aplicacin cliente y la base de datos.

5
 4.3. Tecnologas usadas
Las tecnologas principales seleccionadas para el sistema propuesto se ha divido en tres partes:
para el aplicativo mvil, para la aplicacin web y para el servidor. Esta divisin se realiza para
una mejor explicacin de estas.

Aplicativo Mvil

Java 8: Java es un lenguaje de programacin orientado a objetos con una gran

cantidad de documentacin. La seleccin de esta tecnologa es por ser el lenguaje
nativo en el desarrollo de aplicaciones mviles.
Retrofit 2: Retrofit 2 es un cliente REST para Android de fcil implementacin,
adems permite hacer peticiones, gestionar tipos de parmetros y parsear
automticamente la respuesta a un POJO.
Picasso 2.5.2: es una librera que permite cargar imgenes en la aplicacin Android
de fcil uso y de fcil implementacin.

Aplicativo Web

Angular 1: Es uno de los frameworks de javascript ms populares utilizados, cuenta

con gran cantidad de documentacin adems de tener soporte de Google.
Jquery 3.2.1: es una librera en Javascript flexible y rpido en el desarrollo web, gran
cantidad de documentacin y de excelente integracin con AJAX.

Servidor

Wildfly: es un servidor de aplicaciones en lenguaje java, de despliegue rpido,

enfoque modular, de peso ligero a travs de gestin de memoria eficiente adems
de tener una buena integracin con el servidor Red Hat.
Java 8: es un lenguaje de programacin orientado a objetos con gran documentacin.
Adems de su fcil integracin con otros componentes de software.
Culqui: es una pasarela de uso gratuito
Maven: es una herramienta de software para la gestin y construccin de proyectos
en java, adems de que organiza tus dependencias con sus respectivas versiones que
hacindolo nativamente hace una instalacin ms tediosa.
Hibernate: es una herramienta para el mapeo objeto-relacional para la plataforma
java que agiliza la relacin entre la aplicacin y la base de datos, aparte de ser ms
completo tiene gran cantidad de documentacin.
MySQL 5.6: Es una base de datos de cdigo abierto con gran cantidad de
documentacin, de bajo costo, de fcil uso, multiplataforma adems soporta gran
cantidad de transacciones y con una capacidad de almacenamiento de poca a
mediana data.

6
7
 5. Vista del sistema

5.1. Vista modular

A continuacin se muestra la vista modular del sistema propuesto.

8
 5.2. Vista funcional
A continuacin se muestra la vista funcional por medio del diagrama de clases.

9
 5.3. Vista de componentes
A continuacin se muestra la vista de componentes por medio del diagrama de componentes.

10
 5.4. Vista de despliegue
A continuacin se muestra la vista de despliegue a travs del diagrama.

11
 5.5. Vista de Integracin
A continuacin se muestra la vista de integracin.

12
6. Evaluacin de Arquitectura

6.1. Atributos de calidad identificados

6.1.1. Escenario de Performance
Fuente: Externa
Estmulo: Pago de pensiones por parte de los padre de familia
Artefacto: Mdulo de pagos
Entorno: Normal / Sobrecargado
Respuesta: Se procesa las transacciones en el menor tiempo posible.
Medicin: El tiempo de transaccin promedio debe ser de 4 segundos y el tiempo
mximo de 8 segundos.

6.1.2. Escenario de Escalabilidad

Fuente: Incremento de usuarios
Estmulo: Incremento del nmero de padres que pagan pensiones por medio del
portal web o la aplicacin mvil
Entorno: Semana de pagos de pensiones
Artefacto: Sistema de pagos del Portal Web y aplicacin mvil
Respuesta: Se incrementa la capacidad de procesamiento de transacciones
Medicin: Transacciones rechazadas = 0

6.1.3. Escenario de Confiabilidad

Fuente: Externa
Estmulo: Cada del servidor de la base de datos
Entorno: Falla a nivel de hardware de la unidad principal (?)
Artefacto: Servidor de base de datos
Respuesta: Uso de un raid 1 (espejo)
Medicin: Tiempo de cada del portal web = 0s, tiempo de cada de la aplicacin mvil
= 0s, tiempo de tolerancia a fallas = 12hrs

6.1.4. Escenario de Disponibilidad

Fuente: Interaccin de los usuarios
Estmulo: Mantenimiento de la pgina web
Entorno: Horario de mantenimiento de la pgina
Artefacto: Portal web y Aplicacin mvil
Respuesta: Mensaje de "En Mantenimiento"
Medicin: Tiempo de espera por parte del usuario < 30 min

13
 6.1.5. Escenario de Seguridad
Fuente: Externa
Estmulo: Realizar la transaccin bancaria por medio del portal web
Entorno: Semana de pago de pensiones
Artefacto: Portal Web
Respuesta: Uso protocolos SSL/TSL registrados en una Autoridad de Certificacin.
Medicin: Transaccin fallidas = 0

6.1.6. Escenario de Usabilidad

Fuente: Usuario
Estmulo: Usar el sistema
Entorno: Sistema en produccin
Artefacto: Portal Web y Aplicacin mvil
Respuesta: El sistema es altamente amigable y fcil de usar para los padres de familia,
docentes y administradores.
Medicin: Tiempo de capacitacin en el uso del sistema < 1 da

14
 6.2. Tcticas a implementar
6.2.1. Tcticas para Performance
Controlar la demanda de los recursos
Aumentar la eficiencia de los recursos mejorando los algoritmos
Se realizar mejorando los algoritmos en la parte de muestra y envi de datos y se
medir la eficiencia a travs de la notacin asinttica (notacin Big-O).

Uso de tiempos de ejecucin obligados

Es el uso del intervalo donde un usuario puede permanecer activo por un periodo
de tiempo despus de hacer su respectivo logueo o de algn respectivo servicio.

6.2.2. Tcticas para Escalabilidad

Particionar funcionalidades:
Se particionara las funcionalidades mediante el uso de la arquitectura de 3 capas.
Virtualizar: se virtualizara en un host en el cual corrern 2 Mquinas Virtuales guest,
de las cuales una ser utilizada para la base de datos y el otro ser para el servidor
web.

6.2.3. Tcticas para Confiabilidad

Proveer de redundancia en caso de fallos
Se mantendr la integracin de los datos en el caso de que ocurra un error realizando
un backup el cual estar disponible durante ocurra el evento

6.2.4. Tcticas para Disponibilidad

Detectar Errores
Usaremos el Mtodo Single Versin, para la deteccin de errores, para ello
implementaremos un Test, en la cual usaremos el Control de tiempo, es decir, un
Test de Tiempo de ejecucin de un proceso, si tarda ms de lo comn se tratara de
una falla, tambin se implementar un Wrappers para encapsular un mtodo que se
est ejecutando, esto decide si se puede pasar o no los pedidos al sistema.
Recuperarse despus de los Errores
Usaremos el Mtodo Single version, la parte parte de Checkpoint - Par de
Procesos; en la cual hacemos correr el sistema en dos versiones diferentes idnticas
de software, el procesador primario genera los CheckPoint y los enva al secundario,
al detectar una falla el procesador secundario retoma a partir del ltimo checkpoint.
Una vez recuperado de la falla se reemplaza el procesador primario

15
 Prevenir errores
Usaremos un Mtodo Multi-Version, usaremos mltiples versiones de
software, una sola versin corre a la vez, si se detecta de una falla se ejecuta
un backup.

6.2.5. Tcticas para Seguridad

Aplicar reconocidas prcticas de seguridad
Otorgar el mnimo necesario de privilegios (a los clientes), con esta otorgacin de
privilegios logramos obtener una mala manipulacin en parte de los clientes hacia el
sistema, sin modificar en parte al sistema.
Asegurar el punto ms dbil, esta tctica que aplicado a redes, se encarga de
establecer un sitio es tan seguro como lo es su enlace ms dbil, este enlace suele ser el
objetivo de los ataques a la privacidad de la red.
Auditar eventos sensitivos, para esto la ubicacin de registro de auditora solo
tendr los privilegios del administrador y una ubicacin definida por el mismo, todas las
consultas realizadas al sistema tendr un registro en la cual podremos observar si se
realiz un cambio en el caso de que la consulta pueda perjudicar al sistema..
Autorizar accesos de los administradores a los diferentes clientes
Asegurar confidencialidad de la informacin utilizando una comunicacin cifrada
y hasheado de contraseas, es decir, utiliza dos claves distintas, pero que
matemticamente son equivalentes y esto se logra con los protocolos SST/TSL.
Asegurar integridad de la informacin por medio de validaciones, con esto se
busca que la Integridad de datos pueda ser un parmetro de calidad, y con ayuda de
las validaciones, como la realizacin de pruebas para identificar registros hurfanos nos
ayuda en esta indicacin.
6.2.6. Tcticas para Usabilidad
Separa la interfaz del resto del sistema Uso de Arquitectura de 3 Capas en la parte
del servidor, para que la parte de interfaz pueda funcionar en un entorno ms eficiente..
Presentar al usuario las opciones que desee como cancelar, atrs, etc, con lo
mencionado se intenta tener una interfaz grfica ms dinmica y sencilla para la
interaccin del usuario. Las opciones mencionadas antes permiten anular la operacin en
caso de una mala interpretacin de la interfaz.

16
 6.3. Fortalezas
Algunas fortalezas identificadas del sistema propuesto para la red de colegios San Cristbal
son:

La aplicacin ser fcil de usar y altamente amigable para los padres de familia.
La facilidad de pago mediante la pasarela de implantado en nuestras aplicaciones.
Alta accesibilidad ya que solo es necesario una conexin a internet para el uso del
portal web o la aplicacin mvil.
Uso de token al momento de las sesiones, lo que permite que el API Rest sea state-
less (Sin estado) brindando una mayor mantenibilidad y permitiendo el
adoptamiento a otras tecnologas. Por otro lado, mejora la integridad y confiabilidad
al manejar sesiones.
El cifrado del SSL/TSL permite una mayor confidencialidad a las acciones que lleve a
cabo el usuario y evita los ataques man-in-the-middle.
El sistema responde de manera inmediata a las peticiones de los usuarios
Uso de lenguaje, frameworks con alta documentacin, lo que facilita el desarrollo del
sistema y su mantenibilidad. Cabe mencionar que los frameworks se basan en buenas
prcticas.
Uso de la arquitectura multicapas en la mayora de mdulos (android, servidor web,
cliente web), el cual mejora la mantenibilidad (facilidad para comprender el cdigo)
y aade mayor cohesin y poco acoplamiento.
La divisin en distintos mdulos (Servidor de base de datos, servidor web) permiten
una mayor escalabilidad si se desea implantar en otro tipo de arquitectura (como
IaaS) o web-hosting.
El uso del middleware de servidor de aplicaciones WildFly permite monitorear el
throughput y carga del servidor, para detectar disfuncionalidades y detectar a tiempo
ataques DDOS.

17
 6.4. Puntos de mejoras
Algunos puntos de mejora del sistema propuesto son:

Reducir el tiempo de transaccin mximo de 8 segundos a 6 segundos por cada

transaccin realizada.
Implementar una sesion invitado en la cual se podr visualizar un cronograma de
actividades del alumno.
Implementar un cambio de plataforma que sea compatible con el sistema IOs.
Implementar un sistema de geolocalizacin para poder visualizar la distancia del
usuario al colegio
Implementar ms medidas y capas de seguridad, como puede agregarse proxies y
cortafuegos.
Se recomendara tener un convenio con el Sistema de Informacin de Apoyo a la
Gestin de la Institucin Educativa (SIAGIE) perteneciente al Ministerio de Educacin.
Como siguiente paso en el crecimiento de la plataforma, es sugerible que se adopte
un servicio de web-hosting. La arquitectura del sistema le permite ser escalable y
puede ser adoptada una arquitectura IaaS y/o Paas.

18
 6.5. Recomendaciones
Algunas recomendaciones para el cliente del sistema son:

Se puede usar la web o la aplicacin mvil con casi las mismas funcionalidades, sin
embargo, es recomendable tener la aplicacin mvil para que pueda notificarse
cualquier asunto de inters.
Al momento de hacer los pagos, es sugerible que se verifique la adecuada direccin
(URL) de la pgina en cada momento.
Realizar los pagos desde computadoras o celulares conocidos y libres de malware. Es
recomendable tener instalado un solucin de software antimalware (IPS/IDS).
El colegio no pedir sus datos bancarios por correo, as que evitar todo tipo de
suplantaciones e informar alguna irregularidad al correo institucional.

19
 7. Glosario

En esta seccin se presenta una relacin de palabras tcnicas con sus definiciones.

1. Diagrama de contexto: diagrama que define los lmites entre sistemas o parte del
sistema y su ambiente mostrando las entidades que interactan con l.
2. Hardware: conjunto de elementos fsicos o materiales que constituyen una
computadora o un sistema informtico.
3. Software: conjunto de programas y rutinas que permiten a la computadora realizar
determinadas tareas.
4. Aplicativo mvil: es una aplicacin informtica diseada para ser ejecutada en
smartphone y otros dispositivos mviles y que permite al usuario efectuar una
tarea concreta de cualquier tipo.
5. Portal web: es un sitio web que ofrece al usuario de forma fcil e integrada, el
acceso a una serie de recursos y de servicio relacionados a un mismo tema.
6. Arquitectura de software: es la estructura del sistema la cual comprende elementos
de software, las propiedades externas visibles de estos elementos, y las relaciones
entre ellos.
7. Arquitectura de tres capas: es un diseo que introduce una capa intermedia en el
proceso. Cada capa es un proceso separado y bien definido en plataformas
separadas.
8. Aplicacin cliente: es un conjunto de actividades interrelacionadas que ofrece con
el fin de que el cliente obtenga el producto en el momento y lugar adecuado y se
asegure un uso correcto del mismo.
9. Base de datos: es un conjunto de datos pertenecientes a un mismo contexto y
almacenados sistemticamente para su posterior uso.
10. Servidor: es un ordenador remoto que provee los datos solicitados por parte de los
navegadores de otras computadoras.
11. Servidor de aplicaciones: se encarga generalmente de gestionar la mayor parte de
las funciones de lgica de negocio y de acceso de datos de la aplicacin.
12. Capa de presentacin: establece el contexto entre los elementos del nivel de
aplicacin determinando la sintaxis y la semntica de los smbolos empleados.
13. Capa de lgica de negocio: son los componentes que los servicios proporcionan
para devolver datos o iniciar procesos de negocio.
14. Capa fsica de datos: se refiere a las transformaciones que hacen a la secuencia de
bits para transmitirlos de un lugar a otro.
15. Peticin: es un requerimiento o solicitud que le hace el cliente al servidor.
16. Parsear: es recorrer todos los registros de una base de datos.
17. HTTPS: es un protocolo seguro para la transferencia de hipertexto.
18. HTTP: es un protocolo de comunicacin que permite las transferencias de
informacin de la world wide web.
19. JDBC: Java Database Connectivity, es una API que permite la ejecucin de
operaciones sobre base de datos desde el lenguaje de programacin en java,
independientemente del sistema operativo donde se ejecute o de la base de datos
a la cual se accede, utilizando el dialecto SQL del modelo de base de datos que se
utilice

20
20. SFTP: es un protocolo que permite una serie de operaciones sobre archivos intenta
ser ms independiente de la plataforma que SCP.
21. SPA: Un single-page application (SPA), o aplicacin de pgina nica es una
aplicacin web o es un sitio web que cabe en una sola pgina con el propsito de
dar una experiencia ms fluida a los usuarios como una aplicacin de escritorio.
22. Ajax: es una tecnologa asncrona, en el sentido de que los datos adicionales se
solicitan al servidor y se cargan en segundo plano sin inferir con la visualizacin ni
el comportamiento de la pgina.
23. Vistas del sistema: describen el sistema desde el punto de vista de diferentes
interesados.
24. Vista modular: define como el sistema est estructurado en un conjunto de
unidades funcionales.
25. Vista funcional (lgica): es una abstraccin del modelo de diseo e identificacin a
gran escala del diseo de paquetes, subsistemas y clases.
26. Vista de componentes: muestra la organizacin y las dependencias entre un
conjunto de componentes.
27. Vista de despliegue: se enfoca en la organizacin de los mdulos del software
actual en el ambiente de desarrollo de software.
28. Mdulo: es un componente autocontrolado de un sistema, el cual posee una forma
bien definida hacia otros componentes.
29. Submdulo: son elementos pequeos, que al estar agrupados generan un mdulo.
30. Clase: es una plantilla para la creacin de objetos de datos segn un modelo
predefinido, se utilizan para representar entidades o conceptos en el lenguaje.
31. Atributo: es una especificacin que define una propiedad de un objeto, elemento o
archivo.
32. Mtodo: es una subrutina cuyo cdigo es definido en una clase y puede pertenecer
tanto a una clase como a un objeto.
33. Componente: trata de elementos que, a travs de algn tipo de asociacin o
contigidad, dan lugar a un conjunto uniforme.
34. Librera: hace referencia a biblioteca que es un conjunto de implementaciones
funcionales, codificadas en un lenguaje de programacin, que ofrece una interfaz
bien definida para la funcionalidad que se invoca.
35. Controlador: es un elemento de software utilizado en diversos sistemas operativos.
36. DAO: es un componente de software que suministra una interfaz comn entre la
aplicacin y uno o ms dispositivos de almacenamiento de datos, tales como una
Base de datos o un archivo
37. POJO: es una instancia de una clase que no extiende ni implementa nada en
especial
38. REST-Ful: define un set de principios arquitectnicos por los cuales se disean
servicios web haciendo foco en los recursos del sistema, incluyendo cmo se
accede al estado de dichos recursos y cmo se transfieren por HTTP hacia clientes
escritos en diversos lenguajes.
39. Servicio: es un conjunto de actividades que buscan responder a las necesidades de
un cliente por medio de un cambio de condicin en los bienes informticos (llmese
activos), potenciando el valor de estos y reduciendo el riesgo inherente del sistema.
40. Actividad: componente de la aplicacin que contiene una pantalla con la que los
usuarios pueden interactuar para realizar una accin.

21
41. Recurso: son aplicaciones, herramienta, dispositivos y capacidades con los que
cuenta una computadora.
42. Despliegue: relacionado a modelar la topologa del hardware sobre el que se
ejecuta el sistema.
43. Integracin: se define con el conjunto de elementos relacionados que interactan
que permiten implantar y alcanzar la poltica y los objetivos de una organizacin.
44. Web server: es un programa que procesa una aplicacin del lado del servidor,
realizando conexiones bidireccionales o unidireccionales y sncronas con el cliente
generando una respuesta en cualquier lenguaje del lado del cliente.
45. Atributo de calidad: son los aspectos del sistema que definen la calidad y las
caractersticas que el sistema debe soportar.
46. Performance / Rendimiento: es el grado en el cual el sistema o componente lleva a
cabo una funcionalidad especfica dada una restriccin de velocidad, precisin, etc.
y el uso eficiente de recursos.
47. Escalabilidad: es la propiedad del sistema de reaccionar y adaptarse sin perder
calidad o bien manejar el crecimiento continuo de manera fluida.
48. Confiabilidad: es el grado de probabilidad de que el sistema funcione o desarrolle
cierta funcin bajo condiciones fijas y durante un periodo determinado.
49. Disponibilidad: es el grado de operabilidad de un sistema o componente
50. Seguridad: es la medida sobre la habilidad del sistema para resistir usos no
autorizados mientras sigue proveyendo sus servicios a los usuarios legtimos.
51. Usabilidad: es la medida de la calidad de la experiencia que tiene un usuario cuando
interacta con un producto o sistema.
52. Portabilidad: se define como la caracterstica que posee un software para
ejecutarse en diferentes plataformas, el cdigo fuente del software es capaz de
reutilizarse en vez de crearse un nuevo cdigo cuando el software pasa de una
plataforma a otra.
53. Escenario de atributo de calidad: expresa una respuesta medible del sistema ante
un estmulo en un contexto particular.
54. Fuente: es la entidad que genera un estmulo.
55. Estmulo: lo que se quiere llevar a cabo.
56. Artefacto: parte del sistema que recibe el estmulo
57. Entorno: condiciones en las que se desarrolla el estmulo.
58. Respuesta: actividad que ocurre luego de la llegada del estmulo.
59. Medida de la respuesta: criterio para evaluar el requerimiento.
60. Tiempo de transaccin: es el tiempo en la cual una transaccin es emitida desde el
sistema.
61. Cada del servidor: en la cual los sistemas dejan de funcionar.
62. Unidad principal: la unidad principal es la unidad lgica que debera contener el
sector de arranque para iniciar el sistema operativo instalado en esa unidad.
63. RAID 1 (espejo):un RAID 1 crea una copia exacta (o espejo) de un conjunto de datos
en dos o ms discos. Esto resulta til cuando queremos tener ms seguridad
desaprovechando capacidad, ya que si perdemos un disco, tenemos el otro con la
misma informacin.
64. Tiempo de cada: es el tiempo en la cual el sistema es incapaz de responder.
65. Tolerancia a fallas: es la capacidad que el sistema posee para estar listo en
cualquier tipo de falla generada o no generada.

22
66. Tctica: es el sistema o mtodo que se desarrolla para ejecutar un plan y obtener
un objetivo en particular.
67. Mantenimiento: es la capacidad que obtiene el sistema y el usuario para la facilidad
de correccin de errores.
68. Tiempo de espera: es el tiempo que tarde un proceso para que pueda ejecutar el
siguiente proceso.
69. Protocolo de cifrado SSL/TSL: TLS; en espaol seguridad de la capa de transporte y
SSL; en espaol capa de puertos seguros.
70. Autoridad de Certificacin (CA): las expresiones autoridad de certificacin, o
certificadora, o certificante, o las siglas AC o CA, sealan a una entidad de
confianza, responsable de emitir y revocar los certificados, utilizando en ellos la
firma electrnica.
71. Transaccin fallida: se debe a diferente tipo de problemas, puede ser por fondos o
por falta de conexin, etc.
72. Sistema en produccin: son los sistemas en estado de produccin que se realizan en
una determinada etapa.
73. Sistema amigable: es un sistema con facilidad de interfaz de usuario, para que el
uso sea sencillo para el usuario final.
74. Plataforma de desarrollo: es el ambiente o entorno de software comn en el cual se
desenvuelve la programacin de un grupo definido de aplicaciones.
75. Demanda de recursos: los sistemas exigen recursos y se le ofrece solo los recursos a
utilizar.
76. Eficiencia de los recursos: una accin est dada por el grado en que se cumplieron
los objetivos previstos en su diseo utilizando los recursos disponibles.
77. Algoritmo: conjunto ordenado de operaciones sistemticas que permite hacer un
clculo y hallar la solucin de un tipo de problemas.
78. Tiempo de ejecucin: se denomina tiempo de ejecucin (runtime en ingls) al
intervalo de tiempo en el que un programa de computadora se ejecuta en un
sistema operativo.
79. Transacciones distribuidas: una transaccin distribuida es una transaccin que
afecta a varios recursos. Para que una transaccin distribuida se confirme, todos los
participantes deben garantizar que los cambios en los datos sern permanentes.
80. Virtualizar: es una tcnica que permite ejecutar y desplegar mltiples sistemas
operativos en un mismo servidor fsico.
81. Redundancia (back up): copia de seguridad de uno o ms archivos informticos, que
se hace, generalmente, para prevenir posibles prdidas de informacin.
82. Excepcin: el manejo de excepciones es una tcnica de programacin que permite
al programador controlar los errores ocasionados durante la ejecucin de un
programa informtico.
83. Rollback: un rollback o reversin es una operacin que devuelve a la base de datos
a algn estado previo. Los Rollbacks son importantes para la integridad de la base
de datos, a causa de que significan que la base de datos puede ser restaurada a una
copia limpia incluso despus de que se han realizado operaciones errneas.
84. Flujo alternativo: en un caso de uso, los flujos de eventos se refieren a los pasos
que alternativamente van realizando los actores y el sistema en el contexto del
requisito funcional capturado en el caso.

23
 85. Privilegio de seguridad: la gestin de derechos de procesos permite restringir
procesos en el nivel de comando, usuario, rol o sistema. Oracle Solaris implementa
la gestin de derechos de procesos a travs de privilegios.
86. Evento sensitivo: son los lapsos de tiempo en el cual los procesos se generan de
manera adecuada.
87. Confidencialidad: confidencialidad es la propiedad de la informacin, por la que se
garantiza que est accesible nicamente a personal autorizado a acceder a dicha
informacin.
88. Integridad: se denomina integridad a conseguir que un programa o aplicacin
informtica se encuentre libre de modificaciones por parte de usuarios no
autorizados tanto en su cdigo como en los datos que maneja y tambin libre de
errores que puedan provocar fallos en el acceso a la informacin por parte del
sistema.
89. Interfaz: es nombrar a la conexin funcional entre dos sistemas, programas,
dispositivos o componentes de cualquier tipo, que proporciona una comunicacin
de distintos niveles permitiendo el intercambio de informacin.
90. Pasarela de pagos: es el servicio de un proveedor de servicios de aplicacin de
comercio electrnico, con el que se autorizan pagos a negocios electrnicos.
91. Token: tambin llamado componente lxico es una cadena de caracteres que tiene
un significado coherente en cierto lenguaje de programacin.
92. Sesin: es un intercambio de informacin interactiva semi-permanente, tambin
conocido como dilogo, una conversacin o un encuentro, entre dos o ms
dispositivos de comunicacin, o entre un ordenador y usuario.
93. API Rest: es un estilo de arquitectura para disear aplicaciones en red. Una API
podra considerarse REST si su arquitectura se ajusta a ciertas reglas o restricciones.
94. State-less (sin estado): un protocolo sin estado (en ingls stateless protocol) es un
protocolo de comunicaciones que trata cada peticin como una transaccin
independiente que no tiene relacin con cualquier solicitud anterior, de modo que
la comunicacin se compone de pares independientes de solicitud y respuesta.
95. Adaptacin: la capacidad del sistema a adaptarse a diferentes cambios a travs del
tiempo en caso de errores.
96. Cifrado: permite ocultar el contenido del mensaje para que slo el destinatario final
pueda leerlo. No son excluyentes, se pueden usar para crear un mensaje de correo
firmado y cifrado.
97. Ataques man-in-the-middle: en criptografa, un ataque de intermediario (man-in-
the-middle, MitM o JANUS) es un ataque en el que se adquiere la capacidad de leer,
insertar y modificar a voluntad, los mensajes entre dos partes sin que ninguna de
ellas conozca que el enlace entre ellos ha sido violado.
98. Lenguaje de programacin: es un lenguaje formal diseado para realizar procesos
que pueden ser llevados a cabo por mquinas como las computadoras.
99. Framework: es una estructura conceptual y tecnolgica de asistencia definida,
normalmente, con artefactos o mdulos concretos de software, que puede servir
de base para la organizacin y desarrollo de software.
100. Mantenibilidad: es la propiedad de un sistema que representa la cantidad de
esfuerzo requerida para conservar su funcionamiento normal o para restituir una
vez se ha presentado un evento de falla. Se dir que un sistema es altamente
mantenible cuando el esfuerzo asociado a la restitucin sea bajo.

24
101. Buenas prcticas: es una experiencia o intervencin que se ha implementado con
resultados positivos, siendo eficaz y til en un contexto concreto, contribuyendo al
afrontamiento, regulacin, mejora o solucin de problemas.
102. Arquitectura multicapas: es un conjunto ordenado de subsistemas, cada uno de los
cuales estn constituidos en trminos de los que tiene por debajo y proporciona la
base de la implementacin de aquellos que estn por encima de l.
103. Cohesin: mide de la fuerza de la relacin entre las piezas de funcionalidad dentro
de un mdulo dado.
104. Bajo Acoplamiento: cuanto menos dependiente sean las partes que constituyen un
sistema informtico, mejor ser el resultado.
105. IaaS: es una infraestructura informtica inmediata que se aprovisiona y administra
a travs de Internet. Permite reducir o escalar verticalmente los recursos con
rapidez para ajustarlos a la demanda y se paga por uso.
106. Web-hosting: es el servicio que provee el espacio en Internet para los sitios web.
107. Middleware: es un software que asiste a una aplicacin para interactuar o
comunicarse con otras aplicaciones, o paquetes de programas, redes, hardware y/o
sistemas operativos.
108. Throughput: volumen de trabajo o de informacin neto que fluye a travs de un
sistema, como puede ser una red de computadoras. Es particularmente significativo
en almacenamiento de informacin y sistemas de recuperacin de informacin, en
los cuales el rendimiento es medido en unidades como accesos por hora.
109. Carga del servidor: es un concepto usado en informtica que se refiere a la tcnica
usada para compartir el trabajo a realizar entre varios procesos, ordenadores,
discos u otros recursos.
110. Ataques DDOS: DDoS son las siglas de Distributed Denial of Service. La traduccin es
ataque distribuido denegacin de servicio, y traducido de nuevo significa que se
ataca al servidor desde muchos ordenadores para que deje de funcionar.

25