ARQUITECTURA DE

SOFTWARE
CLASE N°3

Ing. José Alfredo Arroyo Santa Cruz

 Requerimientos del
Negocio

Requerimientos
No Funcionales

Desde los primeros encuentros el analista captura las

necesidades de clientes y usuarios, incluyendo los
requerimientos que cubren sus expectativas de calidad
y los que imponen restricciones.
 Requerimientos del
Negocio

Requerimientos
No Funcionales

Requerimientos del
Usuario

Cada clase de usuarios puede requerir diferentes factores

de calidad y restricciones además de asignarle diferentes
prioridades, según sus tareas y su perspectiva.
 Requerimientos del
Negocio

Requerimientos
No Funcionales

Requerimientos del
Usuario

Durante la captura de requerimientos con frecuencia el

usuario tiende a especificar restricciones sobre el
sistema que en verdad esconden factores de calidad.
El analista debe indagar acerca del por qué de la
restricción, para identificar el factor de calidad implícito.
Requerimientos No Funcionales
 Los Factores de calidad y las Restricciones conforman los
requerimientos no funcionales.
 Mientras que los requerimientos funcionales especifican qué
debe hacer el sistema, los requerimientos no funcionales
establecen cómo debe hacerlo.

Los factores de calidad son atributos que influyen en el nivel de

satisfacción que brinda el producto al cliente e incluso pueden
determinar el éxito del proyecto.
Si los requerimientos funcionales especifican el
comportamiento del sistema, los factores de calidad
establecen las cualidades del comportamiento.
Existen diferentes maneras de clasificarlos. Más allá de la
clasificación que se adopte, es importante capturarlos antes de
que se diseñe la solución y no cuando el producto se verifica
Restricciones
Una restricción limita las alternativas de decisión del diseñador
y el resto del equipo de desarrollo.
Las restricciones pueden ser impuestas por participantes
externos, por otros sistemas que interactúan con el que se está
construyendo o por otras etapas del ciclo de vida del sistema,
como por ejemplo una transición o actividad de
mantenimiento.
Existen varias restricciones que se deben tomar en cuenta:
 Acuerdos existentes en la organización, decisiones
gerenciales, administrativas o técnicas.
 Utilizar una tecnología específica, herramientas, lenguajes,
sistemas de bases de datos.
 Considerar el sistema operativo o plataforma que conforma
el entorno para el producto. (por ejemplo el navegador web)
Restricciones
 Notaciones para el diseño o estándares de codificación que
hay que mantener. Por ejemplo modelar usando diagramas
de flujos de datos y una codificación alfanumérica específica
para los requerimientos.
 Compatibilidad con sistemas previos o potenciales,
especialmente convertir datos entre distintos formatos.
 Compatibilidad con otros sistemas con los que el sistema
debe comunicarse, formatos de los archivos, protocolos de
interacción.
 Limitaciones impuestas por reglas internas o externas, por
ejemplo formatos de los listados, tipo de papel.
 Restricciones sobre el hardware tales como tamaño de
memoria, velocidad del procesador, costos.
 Restricciones físicas provocadas por el entorno operativo o
por características o limitaciones de los usuarios.
Restricciones
 Restricciones provocadas por el tamaño de la pantalla, en
particular en los dispositivos móviles.
 Convenciones cuando se extiende o modifica un sistema y se
requiere mantener las mismas características en la interface
de usuario.
 Formatos estándar para intercambiar datos.

El analista debe distinguir cuándo se trata de una propuesta del

usuario, incluso una idea que escapa al desarrollo de
requerimientos y corresponde más bien al diseño de la
solución, respecto a un requerimiento que impone una
restricción.
El analista puede decidir que el usuario está formulando una
restricción que debe respetarse porque va a permitir alcanzar
una solución adecuada.
Factores de Calidad
Pueden ser EXTERNOS e INTERNOS.

 Externos: Son percibidos y valorados por los usuarios.

 Los factores de calidad externos describen características
observables cuando el software está ejecutándose.
 Influyen poderosamente en el nivel de calidad que
percibirá el usuario.
 Es el usuario quien debe indicar sus expectativas
relacionadas con cada atributo de calidad externo y
participa en la definición del criterio para medir la
satisfacción.
Factores de Calidad
 Externos
 Disponibilidad
 Instalabilidad
 Integridad
 Interoperabilidad
 Performance ()Rendimiento
 Confiabilidad
 Robustez
 Safety
 Seguridad
 Usabilidad
Factores de Calidad
 Internos: No pueden observarse durante la ejecución del
sistema, afectan únicamente al equipo de desarrollo.

 Los factores de calidad Internos no son observables

durante la ejecución del sistema.
 Son propiedades que se perciben durante el desarrollo,
verificación o mantenimiento, mientras que se implementa
el código, se lo modifica, se lo usa o mueve a otra
plataforma.
 Afectan indirectamente al usuario cuando una ineficiencia
en la funcionalidad degrada la performance o cuando un
cambio en los requerimientos demanda un tiempo o costo
excesivo.
Factores de Calidad
 Internos
 Eficiencia
 Modificabilidad
 Portabilidad
 Reusabilidad
 Escalabilidad
 Verificabilidad
Cómo elegir Atributos de Calidad
Realizar Talleres de atributos de calidad
Involucrar stakeholders para dar prioridad a
atributos de calidad

Puede ser de ayuda distinguir entre:

Atributos de calidad en tiempo de ejecución
Rendimiento, seguridad, disponibilidad, usabilidad,…
Atributos de calidad en tiempo de no-ejecución
Modificabilidad, portabilidad, reusabilidad, testabilidad
Atributos de calidad orientados al negocio
Coste, planificación, time-to-market, …
Cómo elegir Atributos de Calidad
ISO-25010 Modelo de calidad de Software
2 partes: Calidad de Producto, Calidad en-uso

Calidad de
producto

Funciona- Compati- Usa- Confia- Manteni- Porta-

Rendimiento Seguridad
lidad bilidad bilidad bilidad bilidad bilidad

Calidad
en-uso

Libre Cobertura
Efectividad Eficacia Satisfacción
de riesgos contexto
Trade Off
 En un mundo ideal cada sistema debería alcanzar el máximo
nivel posible de cada factor de calidad.
 Un sistema debería ser accesible en todo momento, jamás
fallar, brindar resultados inmediatos y correctos siempre,
impedir cualquier intento de acceso no autorizado.
 Sin embargo, algunos factores están enfrentados y no es
posible maximizar todos simultáneamente.
Trade Off
 Después de ver S.Q.A.
(Software Quality Assurance)

Que se puede concluir?

 La arquitectura de software se ocupa de:
 La organización del sistema de software
 La selección de los elementos estructurales e
interfaces que componen el sistema
 La composición de estos elementos en subsistemas mas
grandes
 El estilo arquitectónico guía la organización, los
elementos y sus interfaces, la colaboración entre
elementos y su composición.
Qué NO es Arquitectura de Software?
 Arquitectura de software no es lo mismo que:
 La estructura de directorio donde residen los archivos
fuente o ejecutables
 La plataforma de hardware usada para el sistema
Por qué se debe estudiar la Arquitectura
de Software?
 Los requerimientos funcionales se encuentran
relacionados entre si y algunas veces el cumplimiento de
uno de ellos implica el no cumplir con otro.
 La Arquitectura de software nos permite razonar y planear
para:
 Confiabilidad del sistema
 Evolución
 Reuso
 Eficiencia
 Mejorar el mantenimiento
 Etc.
Por qué se debe estudiar la Arquitectura
de Software?
 Garlan y Shaw.
 El reconocer arquitecturas comunes permite que los
diseñadores construyan los sistemas basados en
variaciones de sistemas anteriores.
 Entender detalles de arquitecturas propicia que se
seleccionen mejores alternativas en el diseño.
 Fluidez al usar notaciones para comunicar a otras
personas detalles del sistema
 La representación de una arquitectura es esencial para
el análisis y descripción de las propiedades del sistema.
Por qué se debe estudiar la Arquitectura
de Software?
 Una arquitectura de software debe proporcionar cierta
información:
 La naturaleza de los elementos.
 Si los elementos son procesos, programas, objetos, etc.
 Las funciones de los elementos.
 El significado de las relaciones entre cada elemento.
 El significado de la distribución de los elementos.
 Por ejemplo. Elementos localizados en diferentes niveles.
 Representación de una Arquitectura de Software
poco informativa.

ELEMENTO 1

ELEMENTO 2 ELEMENTO 3 ELEMENTO 4

Problemas por la falta de Arquitectura
 Rendimiento inadecuado
 Mantenimiento costoso
 Diseño inadecuado para evolucionar
 Reuso limitado
 Proyectos ineficientes (el arquitecto particiona el trabajo
de tal manera que cada ingeniero debe comunicarse con
todos los demás para hacer su trabajo)
Entender a los Stakeholders
Expectativa vs. Realidad
Puntos de vista de la A.S.
 Modelos estructurales: componentes, conexiones entre ellos,
la configuración, estilo, restricciones, semántica, análisis,
propiedades, racionalizaciones, requerimientos, necesidades
de los participantes, (ADLs).
 Modelos de framework: refieren a dominios o clases de
problemas específicos.
 Modelos dinámicos: Enfatizan la cualidad conductual de los
sistemas.
 Modelos de proceso: programación de procesos para derivar
arquitecturas.
 Modelos funcionales: conjunto de componentes funcionales,
organizados en capas que proporcionan servicios hacia arriba

Según: Shaw y David Garlan [SG95]

Arquitectura vs. Diseño
 Taylor y Medvidovic señalan que la literatura actual
mantiene en un estado ambiguo la relación entre ambos
campos, albergando diferentes interpretaciones y posturas:
1. Una postura afirma que arquitectura y diseño son lo mismo.
2. Otra, en cambio, alega que la arquitectura se encuentra en un
nivel de abstracción por encima del diseño, o es simplemente
otro paso (un artefacto) en el proceso de desarrollo de
software.
3. Una tercera establece que la arquitectura es algo nuevo y en
alguna medida diferente del diseño (pero de qué manera y en
qué medida se dejan sin especificar).
 La arquitectura y el diseño sirven al mismo propósito. Sin
embargo, el foco de la A.S. está en la estructura del sistema
y en las interconexiones, con los cuales las distinguen del
diseño de software tradicional.