Unidad 4

1 //Escenario
Escenario27
Lectura fundamental
Fundamental

Metodologías
Etapas de un plan
y procesos
de comunicación
de
estratégica de software
arquitectura

Contenido

1 Revisión del plan de desarrollo

2 Procesos, metodologías, marcos conceptuales

Palabras clave: QAW, FRUPS+, ACDM, VIEWPOINT, QAWM

1. Revisión del plan de desarrollo
La calidad de la arquitectura de software se puede evaluar principalmente mediante 3 aspectos: 1) la
pertinencia, 2) la manera en que se llega a la solución y 3) los artefactos o el producto final. (ISO/
IEC/IEEE42010, 2011).

En esta etapa del curso es importante revisar tanto el proceso como el producto de arquitectura.
Por lo general, se usan indistintamente las palabras procesos, metodologías, métodos y marcos
conceptuales para referirse tanto a herramientas como artefactos (productos). A través de esta
unidad se realizará precisión sobre los dos panoramas.

Para esto, se presentan los modelos de proceso más utilizados en la arquitectura de software a
través del escenario 7 y, luego, en el escenario 8 se explican diversas formas sistemáticas usadas
para construir o elaborar los distintos artefactos y las formas de hacerlo. En cada una de las fases o
partes de los procesos, marcos conceptuales, metodologías o frameworks de trabajo presentados,
existen vistas o conjuntos de artefactos que resuelven converses específicos o correspondientes a las
necesidades de dichas fases, que es preciso definir.

2. Procesos, metodologías, marcos conceptuales

El proceso: es una serie de actividades, tareas o pasos consecutivos o encadenados a través de los
cuales se realiza la transformación material y conceptual de datos o de información. Es el cambio en la
entrada que produce una determinada salida.

El método: secuencia de acciones que comprenden diversas técnicas y procesos.

La metodología: incluye al método, pero, además, define roles, fases, iteraciones, recomendaciones y
artefactos.

Los marcos conceptuales: son el respaldo teórico de la metodología; proveen un conjunto de

conceptos que deben considerarse al documentar la arquitectura o aplicar las técnicas.

2.1. El Método de Diseño Centrado en Arquitectura (ACDM)

El ACDM es una metodología desarrollada por Anthony Lattanze (2010), de la Universidad de

Carnegie Mellon, que propone facilitar el proceso de diseño de una solución e integrarla a los
procesos de desarrollo comúnmente usados; expone técnicas y estructuras, y define roles para
diseñar y usar la arquitectura para la construcción de artefactos.

POLITÉCNICO GRANCOLOMBIANO 2
Se construye bajo un proceso iterativo y de mejora continua que permite que el equipo esté seguro
de poder implementar el producto.

El diseño arquitectural es usado para planear, estimar y seguir las actividades de construcción y
allí radican sus principales fortalezas: la capacidad de identificar, organizar y analizar, de manera
temprana, los concerns y drivers de la arquitectura en las primeras etapas del desarrollo de software.
2.1.1. Estados del método ACDM

En las primeras etapas, 1 y 2, se establecen los requerimientos (drivers motivadores o concerns) de la

arquitectura y se valida su alcance; en la etapa 3 se crea o se refina la arquitectura, lo que constituye
el diseño inicial; luego, en la etapa 4, se revisa la arquitectura; en el siguiente paso (etapa 5) el equipo
decide si la arquitectura debe o no ser refinada, es decir, “si va o no va”, y, en el caso de que sí, en el
paso 6 se realizan experimentos para solucionar dudas del equipo. Una vez se termina el experimento,
se retorna al paso 3; si la arquitectura no requiere ser refinada, se planea la producción y se ejecuta.
Los pasos 1 a 6 se realizan sin la certeza del tiempo a invertir, mientras que en las dos últimas fases
existe un tiempo establecido o cuantificable.

Figura 1. Estados e iteraciones del método de diseño centrado en la arquitectura.

Fuente: Elaboración propia (2018). Modificado de Lattanze (2010)

2.1.2. Roles del método ACDM (Craig, 1999)

Ingeniero gerente: aunque el volumen de trabajo sea mayor en las primeras y últimas entapas, es el
encargado y responsable de coordinar todo el diseño y el desarrollo del sistema. Crea el plan maestro
de diseño inicial y ayuda al ingeniero de requisitos en la planificación de los controles de arquitectura.
De manera constante, se encarga de la actualización y replanificación del plan maestro de diseño
basado en datos reales de los talleres de creación; “cuando el proyecto sale bien es culpa de quienes lo
implementan, cuando el proyecto sale mal es culpa del gerente”.

POLITÉCNICO GRANCOLOMBIANO 3
Ingeniero de soporte: es el responsable de poner a punto todo y mantener las herramientas necesarias
para la elaboración del proyecto; debe trabajar en conjunto con el ingeniero de requerimientos para
obtener las demandas de todos los stakeholders, esto es instalación, configuración y mantenimiento
de las herramientas necesarias y de respaldo para el diseño y elaboración de la arquitectura y del resto
del proyecto.

Arquitecto jefe: su función principal es el diseño y mantenimiento de todo el sistema, el cual

se materializa a través de un documento. Par tal fin, trabaja con el ingeniero de requisitos para
obtener los requisitos de las partes interesadas, en especial, los no funcionales. El arquitecto jefe
es responsable de la captura de los drivers de arquitectura, de coordinar el diseño del sistema y de
diseñar, revisar, refinar y documentar la arquitectura, preferiblemente, en todo el ciclo de vida del
software.

Científico jefe: asiste al arquitecto jefe con detalles técnicos que puedan impactar el sistema y el
clear box test, que, esencialmente, es un análisis directo del código fuente. Debe trabajar junto con
el ingeniero de requisitos para obtener los requisitos de los stakeholders, sin descuidar los drivers
arquitectónicos. Debe capturar y documentar la colección de drivers de arquitectura en bruto.

Ingeniero de requisitos: lidera la documentación de los requerimientos y planifica, coordina y facilita

la obtención de drivers arquitectónicos no solo durante la primera etapa, sino en la evolución de
estos. Coordina las reuniones de consolidación de drivers arquitectónicos y compila el documento de
requerimientos del sistema.

Ingeniero de procesos de calidad: ayuda a los equipos de ingeniería de requerimientos a capturar y

documentar la colección de drivers de arquitectura en bruto. Es el dueño del modelo o metodología
ACDM (ver tabla 1) y de las adiciones que se le puedan hacer a esta. Trabaja con el ingeniero de
requisitos para obtener los atributos de calidad a partir de los requisitos y drivers de arquitectura.
Coordina una revisión del documento de drivers de arquitectura con el fin de asegurar la alineación
estratégica, para lo cual está en contacto constante con los stakeholders.

Ingeniero de producción: no se deben confundir con otros ingenieros (ingenieros de software,

ingenieros electrónicos, ingeniero de TI, mecánico o químico); tiene su función en todo el proceso,
pero específicamente en la etapa 6 (ver figura 1). Debe ser una persona muy experimentadas en la
implementación para poder apoyar procesos de prueba y error que se dan en esta etapa y, así, evitar
sesgos, dada la dificultad que conlleva la implementación de una herramienta. Esa experiencia es
de gran utilidad, razón por la cual este ingeniero debe ayudar e involucrarse con los ingenieros de
requisitos y arquitectos en la captura, reformulación y obtención de drivers arquitectónicos.

POLITÉCNICO GRANCOLOMBIANO 4
 2.1.3. Documentación en el método ACDM

Si bien ACDM especifica las etapas para la elaboración de la documentación de la arquitectura,

entregables y roles específicos, no hace énfasis en el uso de una notación particular; empero, sugiere
organizar la documentación de acuerdo con el esquema presentado en la tabla 1.

Tabla 1. Estructura del documento de arquitectura sugerida para ACDM. Modificado de Lattanze (2010)

Fuente: Elaboración propia (20118)

2.2. Quality Attribute Workshops Method (QAWM)

Más que un método para el desarrollo de la arquitectura del sistema, QAWM es un taller de un
día que contribuye a la primera fase de un proceso de arquitectura, que consiste en la captura de
requerimientos, escenarios y drivers de arquitectura. Adicionalmente, este método incluye una
reunión para el aseguramiento de la calidad. El objetivo de QAWM es tratar de determinar, lo
más pronto posible y de forma ordenada, los atributos de calidad del sistema que servirán como
base fundamental (drivers de arquitectura del sistema); es importante definir claramente los
requerimientos antes de que la arquitectura sea desarrollada.

POLITÉCNICO GRANCOLOMBIANO 5
 2.2.1. Estados del método QAWM

QAWM es un método que facilita el descubrimiento de los atributos de calidad para sistemas y
software intensivos, para los cuales es imprescindible la definición clara de los atributos de calidad
antes de la especificación de la arquitectura. El objetivo es que el conjunto de stakeholders
identifiquen y prioricen los atributos y escenarios desde todo punto de vista, establezcan los críticos y
los articulen de manera temprana al diseño de la arquitectura.

Figura 2. Modelos de proceso del workshop de atributos de calidad (QAWM). Modificado de Barbacci et al. (2003)
Fuente: Elaboración propia (2018).

2.2.2. Roles del método QAWM

No se definen funciones especiales para el taller, dado que es un evento conjunto de un equipo en
el que pueden estar involucrados de 5 a 7 personas. Se proponen 2 facilitadores para la captura de la
información, con los artefactos presentados en la siguiente sección (ver tablas 2 y 4). Luego se debe
organizar la información, tarea a cargo de los siguientes 2 roles definidos en la metodología, que se
explican a continuación.

Lead QAW: tiene claridad sobre el método y garantiza que tanto los pasos como los artefactos sean
diligenciados y llevados a cabo correctamente.

Escritor de QAW: es quien diligencia todos los formatos. Su responsabilidad es consolidar el

documento hasta el paso 7; luego, bajo supervisión del Lead QAW, asegura la finalización y
generación de todas las fichas y el documento.

POLITÉCNICO GRANCOLOMBIANO 6
 2.2.3. Documentación en el método QAWM

El encabezado del documento son el título del taller y la fecha; quizás sea necesario un identificador
de acuerdo con las políticas de gestión documental. En la primera sección es importante tener
registro de los asistentes y tomar notas según corresponda en la segunda y tercera sección (ver tabla
3); debe realizarse un listado de los atributos de calidad a los que se le dará prioridad o se someterán a
consideración, incluyendo los problemas asociados y las distintas anotaciones que se deriven del taller.

En la sección 4, “Identificación de drivers arquitectónicos”, se consignan las aclaraciones y

correcciones de la lista de los drivers arquitectónicos. Para obtenerlos se deben presentar uno a
uno, no necesariamente en orden los drivers consignados en los ítems 2 y 3. Esa lista ayudará a los
facilitadores a garantizar la cobertura total durante la tormenta de ideas del escenario.

Tabla 2. Recolección de escenarios. Modificado de Barbacci et al. (2003)

Fuente: Elaboración propia (20118)

Desde la sección 5 a la 7 se utiliza la misma estructura (ver tabla 2), insertando filas según sea
necesario. En la sección 5 se redactan los escenarios crudos propuestos por cualquiera de los
stakeholders, usando el formato e incluyendo una valoración parcial y total; luego, (sección 6)
se deben fusionar escenarios similares y duplicados, y presentarlos. Finalmente (sección 7), cada
parte interesada debe, por lo menos, realizar una votación equivalente al 30 % del número total de
escenarios.

POLITÉCNICO GRANCOLOMBIANO 7
 Tabla 3. Estructura del documento final del taller QAW.

Fuente: Elaboración propia (2018). Modificado de Barbacci et al. (2003)

Para la última sección, “Refinamiento del escenario”, quizás la más extensa (ver tabla 4), se presenta
el inventario total de escenarios, incluyendo múltiples detalles, tales como: ¿Cuánto tiempo?, ¿Con
qué frecuencia?, ¿Cuándo?, ¿Quién?, y así sucesivamente.

Tabla 4. Ejemplo de tabla de refinamiento de escenario.

Fuente: Elaboración propia (2018). Modificado de Barbacci et al. (2003)

POLITÉCNICO GRANCOLOMBIANO 8
 2.3. El modelo de vista "4 + 1" de la arquitectura de software

Más que una metodología, el modelo 4+1, de Philippe Kruchten, es una clasificación o modelo de
organización de las distintas vistas UML para la completa descripción del software y su arquitectura.
Esto permite resolver separadamente cada uno de las preocupaciones o drivers de los distintos
stakeholders de la arquitectura de software, entre ellos el usuario final, gerentes de proyecto,
programadores, ingenieros de sistemas etc., Propone una aproximación iterativa para lograr consolidar
las 5 vistas presentadas en el siguiente diagrama:

Figura 5. Modelo de vistas 4+1 de arquitectura de software.

Fuente: Elaboración propia (2018). Modificado de Kruchten (1995)

Tabla 5. Estructura “4+1”, Documento de arquitectura sugerida.

Fuente: Elaboración propia (2018). Modificado de Kruchten (1995)

POLITÉCNICO GRANCOLOMBIANO 9
 ¿Sabía qué...?
Philippe Kruchten, profesor de Ingeniería de software de University of
British Columbia, Canadá, ha escrito cerca de 249 artículos entre 1977
y 2004, hecho que lo convierte en un referente en su área. Varios de los
artículos se encuentran en las columnas de IEEE software Magazine. Puedes
conocer más acerca de este autor en: https://philippe.kruchten.com/

2.4. Functionality, Usability, Reliability, Performance, Supportability y (FURPS+)

El modelo FURPS+ contempla tanto requerimientos funcionales (1) como requerimientos no

funcionales (2-5) y 5 restricciones adicionales (+), para un total de nueve características como
factores de calidad, que son los que le dan su nombre.

Tabla 6. Características generales de FURPS.

Fuente: Elaboración propia (2018). Modificado de Craig (1999)

POLITÉCNICO GRANCOLOMBIANO 10
 Cómo mejorar...
En la sección final de este documento, se listan otra serie de
metodologías, modelos de proceso y frameworks o marcos conceptuales
que son importantes investigar para tomar lo mejor de cada mundo
para las propuestas de su proyecto de investigación formativo (Vistas
y más allá, puntos de vista y perspectivas, el estándar ISO/IEC/IEEE
42010:2011, el modelo 4 Vistas de Siemens, Rational ADS, entre otros).

2.5. Listado de metodologías, modelos de proceso y frameworks:

• Vistas y más allá

• Puntos de vista y perspectivas

• El estándar ISO/IEC/IEEE 42010:2011

• El modelo 4 Vistas de Siemens

• Rational ADS

2.6. Comparación de los métodos y marcos conceptuales

Como anexo, se presenta la siguiente tabla que compara metodologías, frameworks y procesos
de arquitectura, y en la que se exponen algunos de los métodos, modelos y marcos conceptuales
abordados en esta lectura fundamental.

POLITÉCNICO GRANCOLOMBIANO 11
 Tabla 7. Comparación de metodologías, frameworks y procesos de arquitectura

Método de diseño
Puntos de vista y centrado en la
Vistas y más allá 4+1 Vistas
perspectivas arquitectura
(ACDM)
Drivers de
Tipo Método Modelo Marco Conceptual
Arquitectura

Puede ser utilizado Modelo que puede

dentro del contexto ser utilizado en el Método iterativo
Definido como
de un método contexto de un e incremental
una secuencia de
Mecánica y pasos que soporta la
de desarrollo método de desarrollo que soporta la
enfoque identificación de las
para soportar la para soportar la identificación y
especificación y especificación y documentación de
vistas a documentar
documentación de documentación de vistas arquitectónicas
vistas arquitectónicas vistas arquitectónicas

Provee un proceso
que especifica las
actividades, roles Sí No aplica No aplica Sí
y artefactos de
entrada y salida
Se asume la
participación de los
siguientes roles:
administrador del
proyecto, arquitecto
Arquitecto de de software líder, líder
Participantes software
No aplica No aplica
científico, ingeniero
de requerimientos,
ingeniero de calidad,
ingeniero de soporte
e ingeniero de
producción.
Conjunto de
interesados en el
sistema e información Drivers de
Entradas proveniente de la
No aplica No aplica
arquitectura
etapa de diseño de la
arquitectura

Lista de vistas a
Conjunto de vistas
documentar junto con
Salidas el orden en que deben
No aplica No aplica arquitectónicas
documentadas
ser elaboradas

Tener un conjunto de
Todas las vistas
Criterios de vistas a documentar y
No aplica No aplica arquitectónicas están
terminación el orden en que deben
documentadas
ser elaboradas

POLITÉCNICO GRANCOLOMBIANO 12
 Considera
las tres vistas
fundamentales: Método Modelo Marco Conceptual
Drivers de
lógicas, de Arquitectura
comportamiento
y físicas
Puede ser utilizado Modelo que puede
dentro del contexto ser utilizado en el Método iterativo
Definido como
de un método contexto de un e incremental
una secuencia de
Considera vistas pasos que soporta la
de desarrollo método de desarrollo que soporta la
adicionales identificación de las
para soportar la para soportar la identificación y
especificación y especificación y documentación de
vistas a documentar
documentación de documentación de vistas arquitectónicas
vistas arquitectónicas vistas arquitectónicas

Considera Sí No aplica No aplica Sí

información

adicional del Se asume la

sistema que participación de los
complementa siguientes roles:
la de las vistas administrador del
(por ejemplo, proyecto, arquitecto
descripción Arquitecto de
No aplica No aplica
de software líder, líder
del sistema, software científico, ingeniero
relación entre de requerimientos,
vistas, glosarios, ingeniero de calidad,
restricciones de ingeniero de soporte
e ingeniero de
negocio y drivers producción.
arquitectónicos)

Provee soporte
para documentar
atributos no No No Sí No
funcionales
específicos
Da soporte para
identificar o Sí No No Sí
priorizar las vistas
a documentar
Sugiere cómo
organizar la Sí Sí No Sí
documentación
generada
Hace determinado
Notación utilizada No indica No aplica énfasis en el uso en No indica
UML

Fuente: Elaboración propia (2018). Modificado de Cervantes Maceda, Velasco Elizondo y Castro Careaga (2016).

POLITÉCNICO GRANCOLOMBIANO 13
 En síntesis...
Existen una gran variedad de metodologías, marcos de referencia y
modelos de proceso que sirven de apoyo para el arquitecto de software.
Muchos de ellos se complementan con otros que son redundantes, pero
con seguridad cada uno tiene una característica diferenciadora que lo hace
especial y que contribuye a mejorar la comunicación y organización de las
actividades, artefactos y roles involucrados en la arquitectura de software.
En esta lectura se abordaron varios temas: la metodología y procesos
(ACDM), las fases iniciales y el aseguramiento de la calidad (QAWM y
FRUPS+), las vistas y su organización (4+1) y, finalmente, una serie de
aspectos considerados de manera transversal.

POLITÉCNICO GRANCOLOMBIANO 14
Referencias bibliográficas
Barbacci, M. R., Ellison, R., Lattanze, A. J., Stafford, J. A., Weinstock, C. B. & Wood, W. G. (2003).
Quality Attribute Workshops (QAWs). Pittsburgh, PA: Software Engineering Institute.

Cervantes Maceda, H., Velasco Elizondo, P. y Castro Careaga, L. (2016). Arquitectura de software.
Conceptos y ciclo de desarrollo. México: Cengage Learnig.

Craig, L. (1999). UML y patrones: introducción al análisis y diseño orientado a objetos. PEARSON.

ISO/IEC/IEEE 42010. (2011). Systems and software engineering — Architecture description. IEEE
Xplore: INTERNATIONAL STANDARD.

Kruchten, P. (1995). The “4+1” View Model of Architecture. IEEE Software, 12(6), 42-50.

Lattanze, A. J. (2010). Architecting Software Intensive Systems: A Practitioner’s Guide. Boca Raton,
FL, EUA: CRC Press.

Referencias de figuras
Barbacci, M. R., Ellison, R., Lattanze, A. J., Stafford, J. A., Weinstock, C. B. & Wood, W. G. (2003).
Quality Attribute Workshops (QAWs). Pittsburgh, PA: Software Engineering Institute.

Kruchten, P. (1995). The “4+1” View Model of Architecture. IEEE Software, 12(6), 42-50.

Lattanze, A. J. (2010). Architecting Software Intensive Systems: A Practitioner’s Guide. Boca Raton,
FL, EUA: CRC Press.

Referencias de tablas
Barbacci, M. R., Ellison, R., Lattanze, A. J., Stafford, J. A., Weinstock, C. B. & Wood, W. G. (2003).
Quality Attribute Workshops (QAWs). Pittsburgh, PA: Software Engineering Institute.

Cervantes Maceda, H., Velasco Elizondo, P. y Castro Careaga, L. (2016). Arquitectura de software.
Conceptos y ciclo de desarrollo. México: Cengage Learnig.

Craig, L. (1999). UML y patrones: introducción al análisis y diseño orientado a objetos. PEARSON.

Kruchten, P. (1995). The “4+1” View Model of Architecture. IEEE Software, 12(6), 42-50.

Lattanze, A. J. (2010). Architecting Software Intensive Systems: A Practitioner’s Guide. Boca Raton,
FL, EUA: CRC Press.

POLITÉCNICO GRANCOLOMBIANO 15
 INFORMACIÓN TÉCNICA

Módulo: Arquitectura del software

Unidad 4: Procesos y documentación de la arquitectura
Escenario 7: Metodologías y procesos de Arquitectura de
software

Autor: Diego Iván Oliveros Acosta

Asesor Pedagógico: Judy Fernanda Villanueva

Diseñador Gráfico: Diego Andres Calderón
Asistente: Ginna Quiroga

Este material pertenece al Politécnico Grancolombiano. Por

ende, es de uso exclusivo de las Instituciones adscritas a la Red
Ilumno. Prohibida su reproducción total o parcial.

POLITÉCNICO GRANCOLOMBIANO 16