Fundamentos de Arquitectura - Atributos de Calidad - 0 9-BD2

Vista previa del material en texto

Índice
Índice
Fundamentos de Arquitectura - Atributos de Calidad
Control de Cambios
Introducción
Performance - Rendimiento
Throughput
Response Time - Tiempo de respuesta
Deadlines - Demoras
Scalability - Escalabilidad
Request Load (pedido de carga)
Conexiones concurrentes
Data size
Deployment - Implementación - Despliegue
Ideas adicionales sobre escalabilidad
Modificabilidad
Seguridad
Disponibilidad
Integración
Otros atributos de calidad
Portabilidad
Testeabilidad
Mantenibilidad
Referencias
Fundamentos de Arquitectura - Atributos de Calidad
Control de Cambios
Autor Versión Fecha
Pablo Sabatino 09 Enero 2019
Introducción
Gran parte de la vida de un arquitecto de software o ingeniero informático se dedica a
diseñar aplicaciones para cumplir ciertos requisitos de atributos de calidad. Atributos
generales de calidad del software pueden ser:
● Escalabilidad
● Seguridad
● Rendimiento
● Confiabilidad.
Estos atributos son generalmente son conocidos como aquellos que terminan en "-dad" de
una aplicación (aunque, por supuesto, por ejemplo el rendimiento, no encaja en esta
especificación léxica).
Los requisitos que definen los atributos de calidad de una aplicación son los que conocemos
como no funcionales. Los atributos de calidad de una aplicación deberían ser especificados
concretamente como parte de los requisitos de la aplicación (requisitos funcionales y no
funcionales). Sin embargo, sabemos que muchas veces esto no sucede.
Analice las siguientes entencias:
“La aplicación debe ser escalable”
“La aplicación debe funcionar lo más rápido posible”
“La aplicación debe ser segura”
“La aplicación debe ser linda”
¿Define alguna un atributo de calidad?
Son definiciones muy imprecisas y realmente no es de mucha utilidad para nadie. Como
veremos más adelante, los requisitos -por ejemplo- de escalabilidad son muchos y variados
y cada uno se relaciona con diferentes características de la aplicación. Entonces en este
ejemplo, ¿debe la aplicación escalar para soportar muchas más conexiones simultáneas?
¿O debe escalar para soportar un mayor volúmen de datos? ¿O requiere de una base de
datos más potente? O tal vez, todas estas características juntas.
Definir cuál o cuáles entre alguna de estas medidas de escalabilidad presentadas, es crucial
desde una perspectiva arquitectónica, ya que las soluciones dependiendo cuales sean
pueden diferir. Por lo tanto, es vital definir requisitos de atributos de calidad concretos, tales
como:
“Debe ser posible escalar el despliegue de una base inicial de 100 usuarios de escritorio
dispersos geográficamente a 10.000 sin un aumento en el esfuerzo, ni costo de instalación y
configuración”.
Una especificación de esta manera es precisa y significativa. Esto le permiten al diseñador
de la aplicación tomar decisiones sobre tecnologías concretas que facilitan la instalación y el
despliegue con un mínimo esfuerzo. Sin embargo, hay que tener en cuenta que muchos
atributos de calidad son en realidad algo difícil (muy difíciles) de validar y probar. Acá es
donde cuenta el expertise y la experiencia del diseñador de aplicaciones y el sentido común.
A continuación, presentamos una una lista y una descripción de algunos atributos de calidad
más relevantes para aplicaciones generales de TI, y una discusión sobre los mecanismos
de arquitectura que se usan en la industria para proporcionar los atributos de calidad
requeridos.
Esto nos dará un buen punto de partida para cuando pensemos en las cualidades que debe
tener la aplicación en la que estamos trabajando.
Performance - Rendimiento
Si bien para muchas aplicaciones de TI, el rendimiento no es un problema realmente
significativo, tiene todo el foco de atención en la multitudinaria comunidad de atributos de
calidad. Probablemente esto se deba a que es una de las cualidades que a menudo se
puede cuantificar y validar fácilmente (o al menos, más fácil que otros atributos de calidad).
Cualquiera que sea la razón, cuando el rendimiento de una aplicación importa, -realmente
importa- y no es algo que pasa desapercibido (incluso va más allá de quien diseña la
aplicación).
Un requisito de calidad de performance define una métrica que establece la cantidad de
trabajo que una aplicación debe realizar en un tiempo determinado y/o los plazos que deben
cumplirse para el correcto funcionamiento. Realmente pocas aplicaciones de TI tienen
restricciones muy exigentes en tiempo real como las que se encuentran en los sistemas
militares o sistemas de robótica donde si se produce alguna demora de un milisegundo o
tres, puede ser demasiado tarde pudiendo resultar consecuencias desagradables e
indeseables (hasta catastróficas). Pero las aplicaciones que necesitan procesar cientos, a
veces miles y decenas de miles de transacciones por segundo se encuentran en muchas
grandes organizaciones, especialmente en el mundo de las finanzas, telecomunicaciones, y
gobierno.
Para el rendimiento podemos utilizar las siguientes métricas:
Throughput
Al rendimiento lo podemos definir como la cantidad de trabajo que una aplicación debe
realizar en unidad de tiempo. El trabajo generalmente se mide en transacciones por
segundo (TPS) o mensajes procesados por segundo (MPS).
Por ejemplo, una aplicación de banca en línea (homebanking) podría tener que garantizar
que puede ejecutar 1000 transacciones por segundo de sus clientes de banca por Internet.
Es posible que un sistema de administración de inventario para un depósito deba procesar
50 mensajes por segundo de los socios comerciales.
Es importante comprender con precisión qué se entiende por un requisito de rendimiento.
Entonces nos podemos preguntar ¿qué es el rendimiento?
¿Es el promedio en un período de tiempo determinado (por ejemplo, un día hábil)?
¿o se refiere al rendimiento máximo que una aplicación puede tener (es decir sus picos de
máxima)? Esta es una distinción crucial.
Una clara ilustración de esto es una aplicación para hacer apuestas en carreras de caballos.
Durante la mayor parte del tiempo, una aplicación de este tipo hace muy poco trabajo (o tal
vez ninguno) y, por lo tanto, tiene un requisito de rendimiento promedio bajo y fácilmente
alcanzable.
Sin embargo, cada vez que hay una carrera, tal vez todas las noches, cinco minutos antes
de cada carrera el sistema deberá ser capaz de procesar cientos o miles de apuestas que
se realizan cada segundo. Si la aplicación no puede procesar estas apuestas cuando se
ingresan, entonces la empresa pierde dinero y genera frustración en los usuarios y
potenciales apostadores. Por lo tanto, para este escenario, la aplicación debe estar
diseñada para cumplir con el rendimiento máximo anticipado, no el promedio. De hecho,
apoyar solo el rendimiento promedio probablemente sería un desastre. Pensemos también
en las siguientes aplicaciones:
● Inscripción a materias de una universidad.
● Aplicación de compras de entradas por internet.
● Aplicación bursátil para operar con la bolsa de comercio de buenos aires. ● Sistema
que nos permita adminstrar y optimizar inteligentemente el consumo de nuestros
dispositivos en nuestro hogar.
Response Time - Tiempo de respuesta
Esta es una medida de la latencia (retardos) que tiene una aplicación en el procesamiento
de una transacción. El tiempo de respuesta es más a menudo (pero no exclusivamente)
asociado con el tiempo que tarda una aplicación en responder a alguna entrada.
Un tiempo de respuesta rápido permite a los usuarios trabajar de manera más efectiva y, por
consiguiente, es bueno para los negocios y todas las partes involucradas. Por ejemplo,
pensemos en un sistema de facturación y cobro de un supermercado: Cuando un artículo se
escanea en el momento de la compra, una respuesta rápida nos da la percepción -como
clientes- de que no estamos perdiendo el tiempo. En cambio ¿cuál es nuestra reacción si
cada vez que que el cajero quiere escanear un producto, debe pasarlo por la máquina 2 o 3
veces cada vez?
Pensemos en que sucede conlas siguientes aplicaciones:
● en los cobros del peaje de una autopista.
● Cuando se escanea la foto en migraciones antes de tomar el avión.
De nuevo, a menudo es importante distinguir entre los tiempos de respuesta garantizados
(guaranteed response time) y los tiempos promedio (average response time). Algunas
aplicaciones pueden necesitar que todas las solicitudes sean atendidas dentro de un límite
de tiempo específico. Este es un tiempo de respuesta garantizado (guaranteed response
time).
Otros pueden especificar un tiempo de respuesta promedio (average response time),
permitiendo latencias más grandes cuando la aplicación está extremadamente ocupada.
Por ejemplo un requisito que nos permite ver cómo podemos aplicarlo: “el 95% de todas las
solicitudes deben procesarse en menos de cuatro segundos, y ninguna solicitud debe tomar
más de 15 segundos”.
Deadlines - Demoras
Las fechas límite (deadlines) en el mundo de TI se asocian comúnmente con los sistemas
por lotes. Un sistema de pago de salarios debe completarse a tiempo para depositar los
pagos de los empleados en sus cuentas en un día determinado. Si el procesamiento se
demora más de lo previsto y los salarios no se pagan en fecha, esto puede causar graves
trastornos, y no solo para quienes esperan sus salarios en sus cuentas.
En general, cualquier aplicación que tenga una ventana de tiempo limitada para completar
tendrá un requisito de fecha límite de rendimiento.
Estos tres atributos de rendimiento pueden especificarse y validarse claramente.
Sin embargo, hay un tema más por aclarar: Se encuentra en la definición de una
transacción, solicitud o mensaje que se utilizan -muchas veces- de manera muy imprecisa.
Esencialmente, es la definición de la carga de trabajo de una aplicación.
La cantidad de procesamiento requerido para una transacción comercial dada es una
medida específica de la aplicación. Incluso dentro de una aplicación, habrá diferentes tipos
de solicitudes o transacciones, que pueden variar desde rápidas operaciones de lectura de
bases de datos hasta complejas actualizaciones a múltiples bases de datos distribuidas.
Por lo tanto, no hay una medida de carga de trabajo genérica, depende completamente de
qué trabajo está haciendo la aplicación. Resumiendo, es una buena práctica ser preciso
respecto de la carga de trabajo o la combinación de transacciones, definida en términos
específicos de la aplicación.
Scalability - Escalabilidad
Una aproximación general a la definición de escalabilidad puede ser la siguiente: "Qué tan
bien funcionará una solución -aplicación- a algún problema cuando aumente el tamaño del
problema".
Este concepto es útil en un contexto arquitectónico. La escalabilidad por lo tanto se refiere a
como -una aplicación- puede hacer frente a algún aspecto de los requisitos de una
aplicación cuando estos aumentan (en cantidad o tamaño). Para ello, debemos entender
cuales son aquellos requisitos que esperamos que se puedan modificar.
Request Load (pedido de carga)
Supongamos que una aplicación está diseñada para soportar 100 tps en carga máxima, con
un tiempo de respuesta promedio de un segundo. Si esta carga de solicitudes creciera diez
veces, ¿puede la arquitectura soportar este incremento de carga?
En el mundo perfecto y sin posibilidad de agregar hardware adicional, a medida que
aumenta la carga, el rendimiento de la aplicación debe permanecer constante (es decir, 100
tps), por lo tanto, el tiempo de respuesta por solicitud va a ir aumentando solo de forma
lineal (es decir, 10 segundos). Una solución escalable permitirá entonces una capacidad de
procesamiento adicional para aumentar el rendimiento y disminuir el tiempo de respuesta.
Esta capacidad adicional se puede implementar de dos maneras diferentes:
● Escalabilidad vertical (scale up): Consiste en agregar más capacidad de
procesamiento -CPUs y probablemente memoria- a la máquina en la que se ejecutan
las aplicaciones. El escalamiento vertical funciona bien si una aplicación es multihilo
(multithreading), o si se puede ejecutar varias instancias del proceso en un solo
thread de la misma máquina. Este último, por supuesto, consumirá memoria
adicional y recursos asociados, ya que los procesos son pesados, requieren recursos
para lograr la concurrencia.
● Escalabilidad horizontal (scale out). Consiste en la distribución de la aplicación en
varias máquinas (servidores). El objetivo es mantener cada máquina igualmente
ocupada, ya que la inversión en más hardware se desperdicia si una máquina está
completamente cargada y otras inactivas. La distribución equitativa de la carga entre
varias máquinas se conoce como equilibrio de carga.
Es importante destacar que, para cualquiera de los dos enfoques, la escalabilidad debe
lograrse sin modificaciones a la arquitectura subyacente (aparte de los cambios de
configuración inevitables si se utilizan varios servidores).
La realidad es que a medida que aumenta la carga, las aplicaciones mostrarán una
disminución en su rendimiento y un posterior incremento exponencial en el tiempo de
respuesta. Esto sucede por dos razones:
● El aumento de la carga provoca una mayor contención de recursos como la CPU y la
memoria por los procesos y subprocesos en la arquitectura del servidor. ● Cada solicitud
consume algún recurso adicional (espacio de búfer, bloqueos, etc.) en la aplicación, y
eventualmente este recurso se agota y limita la escalabilidad
Conexiones concurrentes
Supongamos que una arquitectura se diseña para soportar 1000 usuarios concurrentes.
¿Cómo responde dicha arquitectura si este número crece significativamente?
Si un usuario conectado consume algunos recursos, es probable que haya un límite en el
número de conexiones que se pueden realmente admitir. Para graficar este inconveniente
vamos a citar un ejemplo clásico de los proveedores de servicios de Internet (ISP). Cada
vez que un usuario se conectaba al servicio, la aplicación ISP generaba un nuevo proceso
en su servidor que era responsable de distribuir anuncios dirigidos al usuario. Esto funcionó
a la perfección, pero cada proceso consumió considerables recursos de memoria y
procesamiento, incluso cuando el usuario simplemente se conectaba y no hacia nada.
Las pruebas revelaron rápidamente que las máquinas del servidor del ISP sólo podían
admitir unas 2000 conexiones antes de que se agotara su memoria virtual y las máquinas se
detuvieran. Esto hizo que la escalada de las operaciones del ISP para brindar soporte a
100,000 usuarios fuera una propuesta prohibitivamente costosa y, eventualmente, a pesar
de los esfuerzos frenéticos de rediseño, fue una causa fundamental para que el ISP dejara
de funcionar.
Data size
¿Cómo se comporta una aplicación a medida que aumenta el tamaño de los datos que
procesa? Por ejemplo, una aplicación que funciona como intermediaria de mensajes -una
sala de chat- se puede diseñar para procesar mensajes de un tamaño promedio esperado.
¿Cómo va a resultar esa arquitectura si el tamaño de los mensajes crece
significativamente? Dicho de otra manera, imagine una aplicación que busca y recupera
datos de un repositorio de un tamaño específico. ¿Cómo se comportará la aplicación si el
tamaño del repositorio aumenta muy significativamente?
Deployment - Implementación - Despliegue
¿Qué sucede cuando queremos modificar o implementar el cambio de una aplicación que
está continuamente aumentando su base de datos de usuarios? Cuando nos referimos a
este concepto -deployment o implementación- incluimos actividades como distribución,
configuración y actualización de nuevas versiones.
Una solución ideal proporcionará mecanismos automatizados que puedan implementar y
configurar dinámicamente una aplicación para un nuevo usuario.
Ideas adicionales sobre escalabilidad
Diseñar arquitecturas escalables no es fácil. En muchos casos, la necesidad de
escalabilidad al principio del diseño simplemente no es tan evidente y claro. En cambio,
como seguramente suceda,tampoco se especifica como parte de los requisitos de calidad.
Se necesita un arquitecto experto (profesionales idóneos) para garantizar que los enfoques
intrínsecamente no escalables, no se introduzcan como componentes arquitectónicos
centrales. Incluso si la escalabilidad es un atributo de calidad requerido, validar que se está
satisfecho con la solución propuesta, a menudo no es práctico en términos de cronograma
(tiempo) o costo (dinero). Por eso, es importante para un arquitecto contar con diseños y
tecnologías probadas y comprobadas, siempre que sea práctico.
Modificabilidad
Las modificaciones a un sistema de software, durante su vida útil, es algo que sucede en la
mayoría de los sistemas y lo tenemos que tomar como algo normal, como parte de la
evolución de la aplicación. Es por eso que considerar y tener en cuenta, que una aplicación
se va modificar en el futuro es una muy buena práctica, sobre todo si este análisis se realiza
durante la formulación de la arquitectura. Cuanto más flexible sea nuestra aplicación desde
la etapa del diseño, menos costosa y difícil será luego cualquier cambio que se quiera
realizar.
Al atributo de calidad modificabilidad lo podemos definir como a la medida (o a la capacidad)
de lo fácil que se puede cambiar (modificar, actualizar, etc) una aplicación para satisfacer
nuevos requisitos funcionales y no funcionales. Tenga en cuenta el uso de se puede en la
frase anterior. La predicción de la modificabilidad requiere una estimación del esfuerzo y/o el
costo/tiempo para realizar un cambio.
La realidad es que solo se sabe con seguridad cuánto costará un cambio después de que
se haya realizado. Entonces es ahí que uno descubre cuán bueno era esa estimación.
Hablar de la medida o capacidad de poder realizar cambios en una aplicación, solo son
relevantes en el contexto de una solución arquitectónica dada. Esta solución arquitectónica
debe expresarse al menos estructuralmente como una colección de componentes, las
relaciones entre esos componentes y una descripción de cómo interactúan dichos
componentes con el entorno. Luego, la evaluación de la modificabilidad (es decir, cuán apta
es una aplicación para aceptar cambios) requiere que el arquitecto afirme (plantee) los
posibles escenarios de cambio que anticipan cómo pueden evolucionar los requisitos. A
veces estos serán conocidos con un buen grado de certeza, otras no.
De hecho, los cambios pueden incluso estar planificados en el plan del proyecto para
versiones futuras de la solución. Sin embargo, la mayoría de las veces, las posibles
modificaciones deberán obtenerse de las partes interesadas de la aplicación (key users,
usuarios finales, etc) en el momento que se necesitan y combinarse con la experiencia del
arquitecto.
Analicemos diferentes escenarios de cambios:
● Proporcionar acceso a la aplicación a través de firewalls además del acceso existente
"detrás del firewall".
● Incorporar un nuevo método de pago (con bitcoins) en la aplicación de autoservicio de
las estaciones de servicio.
● El proveedor de software de reconocimiento de voz cerró su negocio y debemos
reemplazar este componente.
● La aplicación necesita ser migrada desde Linux a la plataforma Microsoft Windows.
Para cada uno de estos cambios propuestos, se puede evaluar el impacto del cambio
anticipado en la arquitectura.
Este impacto rara vez es fácil de cuantificar, ya que la mayoría de las veces no existe la
solución bajo evaluación. En muchos casos, lo mejor que se puede lograr es un análisis de
impacto convincente de los componentes de la arquitectura que necesitarán modificación, o
una demostración de cómo la solución puede adaptarse a la modificación sin cambios.
Finalmente, según las estimaciones de costo, tiempo, tamaño o esfuerzo para los
componentes afectados, se puede realizar una cuantificación útil del costo (como un todo)
de un cambio.
Es probable que los cambios aislados en componentes individuales o en subsistemas
débilmente acoplados sean menos costosos de realizar que los que causan efectos
dominantes en toda la arquitectura.
Si un cambio probable parece difícil y complejo de realizar, esto puede implicar una
debilidad en la arquitectura que podría justificar una mayor consideración y un nuevo
diseño.
Seguridad
La seguridad es un tema técnico complejo que solo puede tratarse de manera superficial
aquí (en el contexto del diseño y sus atributos de calidad).
En el nivel arquitectónico, la seguridad se reduce a comprender los requisitos (de seguridad)
precisos para una aplicación y los mecanismos de apoyo para ellos.
Los requisitos más comunes relacionados con la seguridad son:
● Autenticación: las aplicaciones pueden verificar la identidad de sus usuarios y otras
aplicaciones con las que se comuniquen.
● Autorización: los usuarios y aplicaciones autenticados tienen derechos de acceso
definidos a los recursos del sistema. Por ejemplo, algunos usuarios pueden tener
acceso de solo lectura a los datos de la aplicación (R), mientras que otros tienen de
lectura y escritura (WR).
● Cifrado: los mensajes enviados a / desde la aplicación están cifrados. Es el proceso
que consiste en incrementar la seguridad de un archivo o mensaje a través de la
codificación del mismo, de manera que sólo puede leerlo la persona que posea la
clave adecuada para decodificarlo.
● Integridad: esto garantiza que el contenido de un mensaje no se modifique durante el
transporte.
● No rechazo: el remitente de un mensaje tiene comprobante de entrega y el receptor
está seguro de la identidad del remitente. Esto significa que ninguno de los dos
puede refutar posteriormente su participación en el intercambio de mensajes. Dicho
en otras palabras, sucede cuando el sistema certifica que los datos utilizados son
únicos y exclusivos; el emisor no puede negar que envió el mensaje porque el
receptor tiene pruebas de ello. También proporciona al emisor datos que confirman
que el receptor recibió el mensaje, por lo que éste tampoco puede negarlo a
posteriori.
Existen tecnologías bien conocidas y ampliamente utilizadas que soportan estos elementos
de seguridad a nivel aplicación. La Capa de sockets seguros (SSL) y las Infraestructuras de
claves públicas (PKI) se utilizan comúnmente en las aplicaciones de Internet para
proporcionar autenticación, cifrado y no repudio (no rechazo).
La autenticación y la autorización son compatibles con las tecnologías de Java mediante el
Servicio de autorización y autenticación de Java (JAAS). Los sistemas operativos y las
bases de datos proporcionan seguridad basada en el inicio de sesión para la autenticación y
autorización.
Hay diversas maneras de gestionar la seguridad, de hecho, a veces demasiadas, para
admitir los atributos de seguridad requeridos para una aplicación. Las bases de datos
quieren imponer su modelo de seguridad en el mundo. Los diseñadores de .NET felizmente
aprovechan las características de seguridad operativas de Windows. Las aplicaciones Java
pueden aprovechar JAAS sin grandes problemas. Si una aplicación solo necesita ejecutarse
en uno de estos dominios de seguridad, entonces hay soluciones disponibles. Si una
aplicación comprende varios componentes que desean todos administrar la seguridad, se
deben diseñar soluciones apropiadas que localicen la administración de seguridad en un
solo componente que aproveche la tecnología más apropiada para satisfacer los requisitos.
Disponibilidad
La disponibilidad está relacionada con la confiabilidad de una aplicación. Si una aplicación
no está disponible para su uso cuando es necesita, es poco probable que cumpla con sus
requisitos funcionales. La disponibilidad es relativamente fácil de especificar y medir.
En términos de especificación, muchas aplicaciones de TI deben estar disponibles al menos
durante las horas normales de trabajo (aplicaciones transaccionales). La mayoría de los
sitios de Internet desean un 100% de disponibilidad (7x24) debido a que no hay horarios
comercialesregulares en línea.
En consecuencia, las aplicaciones que requieren alta disponibilidad minimizan o
preferiblemente eliminan los puntos únicos de falla (SPOF), e instituyen mecanismos que
detectan automáticamente la falla y reinician los componentes con falla.
Replicar componentes es una estrategia probada y empleada para alta disponibilidad.
Cuando un componente replicado falla, la aplicación puede continuar ejecutándose
utilizando réplicas que aún funcionan. Esto puede llevar a un rendimiento degradado del
sistema mientras el componente fallido está inactivo, pero la disponibilidad no se ve
comprometida.
La recuperabilidad está estrechamente relacionada con la disponibilidad. Una aplicación es
recuperable si tiene la capacidad de restablecer los niveles de rendimiento requeridos y
recuperar los datos afectados después de una falla de la aplicación o del sistema. Un
sistema de base de datos es el clásico ejemplo.
Ejemplo de un sistema recuperable: cuando un servidor de base de datos falla, no está
disponible hasta que se haya recuperado. Esto significa reiniciar la aplicación del servidor y
resolver las transacciones que estaban ejecutándose cuando ocurrió la falla. Los temas
interesantes para las aplicaciones recuperables son cómo se detectan las fallas y las
menciones de recuperación (preferiblemente de manera automática), y cuánto tiempo lleva
recuperarse antes de que se restablezca el servicio completo. Durante el proceso de
recuperación, la aplicación no está disponible y, por lo tanto, el tiempo promedio de
recuperación es una métrica importante a considerar.
Es importante mencionar que el Tiempo Acordado del Servicio -disponibilidad del servicio
se define desde los SLA’s y OLA’s que como proveedores de servicios de TI tenemos que
tener siempre en cuenta.
SLA - Service Level Agreement - Acuerdo de Nivel de Servicio
Es un acuerdo entre un proveedor de servicio de TI y un cliente.
OLA - Operational Level Agreement - Acuerdo de Nivel Operacional Es un acuerdo entre
un proveedor de servicio de TI y otra parte de la misma organización; gobierna la prestación
de un Servicio de Apoyo.
Lectura complementaria: Que es SLA y OLA?
Integración
La integración se ocupa de la facilidad con la que una aplicación puede incorporarse de
manera útil en un contexto de aplicación más amplio.
Con frecuencia, el valor de una aplicación o componente puede incrementarse
considerablemente si su funcionalidad o datos se pueden usar de manera que el diseñador
no anticipó originalmente. Las estrategias más extendidas para proporcionar integración son
a través de la integración de datos o el suministro de una interfaz de programación de
aplicaciones (API).
La integración de datos implica almacenar los datos que una aplicación manipula, de
manera tal, que otras aplicaciones puedan acceder. Esto puede ser tan simple como usar
una base de datos relacional estándar para el almacenamiento de datos, o quizás
implementar mecanismos para extraer los datos en un formato conocido, como XML o un
archivo de texto separado por comas que otras aplicaciones puedan utilizar.
Con la integración de datos, las formas en que otras aplicaciones usan (o abusan) los datos
están bastante fuera del control del propietario de los datos originales. Esto se debe a que la
integridad de los datos y las reglas comerciales impuestas por la lógica de la aplicación se
omiten. La alternativa es lograr la interoperabilidad a través de una API:
En este caso, los datos sin procesar que posee la aplicación están ocultos detrás de un
conjunto de funciones que facilitan el acceso externo controlado a los datos. De esta
manera, las reglas de negocio y la seguridad se pueden aplicar en la implementación de la
API. La única forma de acceder a los datos e integrarlos con la aplicación es mediante el
uso de la API suministrada.
Otros atributos de calidad
Hay muchos otros atributos de calidad que son importantes en varios contextos de
aplicación. Algunos de estos son:
Portabilidad
¿Se puede ejecutar una aplicación fácilmente en una plataforma de software / hardware
diferente a la que se ha desarrollado?
Testeabilidad
¿Qué tan fácil o difícil es una aplicación para probar (testear)? Las decisiones tempranas de
diseño pueden afectar en gran medida la cantidad de casos de prueba que se requieren.
Como regla general, cuanto más complejo sea un diseño, más difícil será realizar una
prueba exhaustiva. La simplicidad tiende a promover la facilidad de prueba. Igualmente,
escribiendo menos de su propio código incorporando componentes previamente probados
reduce el esfuerzo de prueba.
Mantenibilidad
Es una medida de lo fácil que es mantener una aplicación una vez que se implementa
(deployada) en producción.
El soporte suele implicar el diagnóstico y la solución (fixes) de problemas (issues) que se
producen durante el uso de la aplicación.
Los sistemas mantenibles por lo general, tienden a proporcionar facilidades explícitas para
el diagnóstico, como los registros de errores de la aplicación (logs) que documentan las
causas de las fallas.
También se construyen de manera modular para que las correcciones de código se puedan
implementar sin causar un gran inconveniente en el uso de la aplicación.
Referencias
Ian Gorton, Essential Software Architecture, 2006.