El pasado, presente, y el futuro de la

Arquitectura de software
Philippe Kruchten, Universidad de British Columbia
Henk Obbink, Philips Research Europe
Judith Stafford, Universidad de Tufts

Published in: IEEE Software ( Volume: 23 , Issue: 2 , March-April 2006 )

https://ieeexplore.ieee.org/abstract/document/1605175

Este número especial celebra 10 años de Ferias y Talleres acerca de la Arquitectura de

Software. y el décimo aniversario del primer número especial de la revista IEEE Software
acerca del tema en noviembre de 1995. Nosotros abordamos las últimas reflexiones sobre la
creación, captura y utilización de la arquitectura de software a través del ciclo de vida del
software. Los artículos que hemos elegido cubren métodos innovadores y las técnicas que
emergen de la investigación para soportar la práctica de la arquitectura de software. También
se enfatizan la métodos, técnicas, herramientas y los principios de ingeniería de software que
apoyan a las organizaciones tomando un enfoque centrado en la arquitectura para el
desarrollo de software.

¿Qué es la arquitectura de software?

La arquitectura del software implica:
● la estructura y organización mediante la cual los componentes y los subsistemas de
los sistemas modernos interactúan para formar sistemas, y
● Las propiedades de los sistemas que se pueden diseñar y analizar mejor a nivel del
sistema (alto nivel).

Por ejemplo, determinamos en gran medida el rendimiento de extremo-a-extremo (end-to-

end) y la compatibilidad de la línea-de-producto mediante la evaluación de arquitecturas de
software. La arquitectura del software captura y preserva las intenciones de los diseñadores
sobre la estructura y el comportamiento del sistema, lo que proporciona una defensa contra
la decadencia del diseño a medida que el sistema envejece. Es la clave para lograr el control
intelectual sobre la enorme complejidad de un sistema sofisticado.

Paradójicamente, a pesar de la madurez de la disciplina, estamos lejos de tener un consenso

sobre una respuesta satisfactoria, breve y clara a esta simple pregunta -- no existe una
definición ampliamente aceptada. Paul Clements enumera varias definiciones en el sitio web
acerca de la práctica de la arquitectura del Instituto de Ingeniería de Software (SEI)
(https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=513807). Conseguir un
acuerdo en una definición fue la tarea más difícil a la hora de crear el estándar IEEE
1471:2000 [1]. En realidad, esta falta de consenso no ha sido un impedimento sustancial
para el progreso de la disciplina, y regularmente ofrece una fuente de entretenimiento en las
reuniones. de arquitectos de software.

El campo de la arquitectura de software tiene muchas subáreas La Federación Internacional

de Procesamiento de la Información Grupo de Trabajo 2.10 (International Federation of
Information Processing Working Group 2.10) define cinco:

● Diseño arquitectónico: ¿Cómo producimos una arquitectura?

● Análisis: ¿Cómo respondemos preguntas, sobre la base de una arquitectura, acerca
de ciertas cualidades del producto final?
● Realización: ¿Cómo producimos un sistema basado en una descripción de su
arquitectura?
● Representación: ¿Cómo producimos artefactos duraderos para comunicar la
arquitectura a los seres humanos o las máquinas?
● Economía: ¿Qué aspectos arquitectónicos manejan las decisiones de negocios?

Y ciertamente la arquitectura del software está atada de cerca a otras disciplinas y

comunidades, tales como el diseño de software (en general), la reutilización, la ingeniería de
sistemas y arquitectura de sistemas, arquitectura empresarial, ingeniería inversa, ingeniería
de requisitos y la calidad.

Una breve historia de la arquitectura de software.

Mirar hacia atrás en el tiempo nos ayudará a posicionar el estado actual y futuro de la
arquitectura de software. También proporcionamos apuntadores a libros, ponencias,
conferencias y sitios web relevantes.

Pre 1995
La primera referencia a la frase arquitectura de software ocurrió en 1969 en una conferencia.
sobre técnicas de ingeniería de software organizada por la OTAN (ver “Arquitectura de
Software en 1969”). Algunos de los más prestigiosos pioneros en el campo, incluyendo a Tony
Hoare, Edsger Dijkstra, Alan Perlis, Per Brinch Hansen, Friedrich Bauer y Niklaus Wirth
asistieron a esta reunión.

Desde entonces hasta finales de los 80, la palabra “arquitectura” se usó principalmente en el
sentido de arquitectura del sistema (es decir, la estructura física de un sistema de cómputo)
o, a veces, en el sentido más estrecho de una familia de instrucciones de un computador. Las
fuentes clave acerca de la organización de un sistema software vienen de Fred Brooks en
1975 [2], Butler Lampson en 1983 [3], David Parnas desde 1972 a 1986[4-7], y John Mills en
1985 [8] (cuyo artículo examinó más en el proceso y la práctica de la arquitectura).

El concepto de arquitectura de software como una disciplina distinta comenzó a emerger en

1990 (ver Figura 1). Un artículo de 1991 de Winston W. Royce y Walker Royce, padre e hijo,
fue el primero en posicionar la arquitectura del software, tanto en título como en perspectiva
— entre tecnología y proceso [9]. Eberhardt Rechtin dedicó algunas secciones a software en
su libro de 1991 : “Creando y construyendo sistemas complejos“ [10]. Aquel año, uno de
nosotros (Philippe Kruchten) escribió un artículo amarrando el desarrollo iterativo con un
enfoque en arquitectura y múltiples vistas definidas para utilizar en un gran sistema de
comando y control [11].

En 1992, Dewayne Perry y Alexander Wolf publicaron su artículo esencial (seminal article)
“Fundamentos para el Estudio de la Arquitectura del Software" [12] Este artículo introdujo la
famosa fórmula “{elementos, formas, justificación/rationale} = Arquitectura de Software ", a la
que Barry Boehm le añadió poco después "restricciones". Para muchos investigadores, los
“elementos” en la fórmula eran componentes y conectores. Estas fueron las bases de una
oleada de lenguajes de descripción de arquitectura (Architecture Description Languages)
(ADL), incluyendo C2, Rapide, Darwin, Wright, ACME y Unicon, que lamentablemente aún no
han tomado mucho arraigo en la industria.

1994 vio el primer libro sobre arquitectura de software, por los ex IBMers Bernard Witt, F.
Terry Baker y Everett Merrit [13].

Figura 1: 10 años de arquitectura de software

1995 - 1998
En 1995, la arquitectura del software realmente comenzó a florecer, y los eventos se
aceleraron con numerosas contribuciones al campo de la industria y la academia. Ejemplos
notables fueron el Método de Análisis de la Arquitectura de Software (SAAM), el primero de
una serie de métodos del Instituto de Ingeniería de Software (SEI) [14], varios enfoques que
involucran múltiples vistas tales como las vistas 4+1 de Rational [15] o las cuatro vistas de
Siemens [16]; y patrones de diseño específicos para la arquitectura del software [17] Siemens
[18], Nokia [19], Philips [20], Nortel, Lockheed Martin, IBM, y otras grandes organizaciones
involucradas en el desarrollo de software -- principalmente en sistemas, aeroespacio y
telecomunicaciones -- empezaron a prestar atención. a la arquitectura de software,
asociándose con la comunidad de reutilización para investigar en arquitecturas de líneas-de-
producto software [21]. Otro libro de Rechtin y Mark Maier, The Art of System Architecting
[22], llena muy bien la brecha entre sistema y software.

1999 - 2005
1999 fue otro año clave para la Arquitectura de Software, viendo nacer la primera Conferencia
IFIP sobre Arquitectura de Software (IFIP Conference on Software Architecture)
[23] y la fundación del Grupo de trabajo IFIP 2.10 (IFIP Working Group 2.10) y el Instituto
Mundial de Arquitectos de Software (Worldwide Institute of Software Architects). Muchos no
académicos comenzaron a picar en las mejores prácticas [24-27] con la esperanza de mejorar
la práctica de la descripción de la arquitectura, el Open Group introdujo el Architecture
Description Markup Language, un ADL basado en XML que proporciona soporte para
compartir ampliamente modelos arquitectónicos. Uniendo fuerzas con las comunidades de
reutilización y familias-de-productos, las líneas de productos de software vienen a ser una
especie de subdisciplina, atrayendo mucha atención de las grandes empresas fabricantes.
Nuevos métodos tales como SAAM, BAPO, y ATAM emergen y se consolidan [14,28,29].
Nosotros teníamos un estándar general de arquitectura, RM- ODP [30,31] y agregamos uno,
IEEE 1471 [1]. El equipo de SEI produjo un libro tras otro y más. [29,32-34].

¿Donde nos encontramos ahora?

Las grandes empresas como Microsoft tienen sus arquitectos jefe. Ha habido una ligera
inflación en títulos desde diseñador de software y desarrollador a arquitecto de software, a
pesar de la súplica de Mary Shaw unos años antes de evitar llamar todo lo que se ve
arquitectura.

Ahora tenemos muchos ADL. Pero pocos son usados en la práctica excepto quizás Koala, y
quizás UML si lo consideras un ADL (Muchos puristas de ADL no lo hacen).

Para varios dominios, existe la arquitectura prefabricada/precocida en la forma de plataformas

-- por ejemplo J2EE, .NET, Symbian/Series 60, y Websphere. Los estándares
de la capa de intercambio de aplicaciones tales como XML y SOAP tienen un impacto
significativo sobre las arquitecturas. Los lenguajes de scripting como Python y Perl cambian
la forma en que construimos sistemas. Los arquitectos no pueden empezar desde cero ya;
ellos construyen sistemas basados en sus conocimientos de las capacidades de estas
plataformas. Además el software Open Source está afectando fuertemente la práctica.

Un cuerpo de conocimientos de arquitectura de software. es fácilmente accesible con más de

25 libros (vea "Biblioteca de arquitectura") y numerosos artículos (ver “Grandes Artículos”).
Docenas de universidades alrededor del mundo. enseñan arquitectura de software, muchas
organizaciones ofrecen cursos de formación de arquitectos, y una comunidad activa se ha
formado (ver “Comunidad de Arquitectura "). Ha surgido una disciplina.

Arquitectura de software en 1969

Ian P. Sharp hizo estos comentarios en la Conferencia de la OTAN de 1969 sobre Técnicas
de Ingeniería de Software. Todavía resuenan bien 37 años después.

Creo que tenemos algo más que la ingeniería de software: algo de lo que hemos hablado en pequeñas
formas pero que debería ser sacado a la luz y tener la atención centrada en ello. Esta es la sub-proyecto
de arquitectura de software. La arquitectura es diferente de la ingeniería.

Como ejemplo de lo que quiero decir, eche un vistazo a OS/360. Partes del OS/360 están muy bien
codificadas. Partes del sistema operativo, si se analiza en detalle, han usado todas las técnicas y todas
las ideas que hemos acordado son buenas prácticas de programación. La razón por la que el ese sistema
operativo es un bulto amorfo de programas es que no tenía arquitecto. Su diseño fue delegado a una
serie de grupos de Ingenieros, cada uno de los cuales tuvo que inventar su propia arquitectura. Y cuando
estos bultos se pusieron juntos, no produjeron una lisa y hermosa pieza de software.

Creo que gran parte de lo que interpretamos como teoría y práctica está de hecho en arquitectura e
ingeniería; Usted puede tener arquitectos teoricos o practicos y puedes tener ingenieros teóricos o
prácticos. No creo, por ejemplo, que la mayoría de lo que hace Dijkstra es teoría, creo que con el tiempo,
probablemente nos referiremos a la "Escuela de Arquitectura Dijkstra".

Lo que pasa es que las especificaciones de software son consideradas especificaciones funcionales.
Solo hablamos de qué es lo que queremos que haga el programa. Es mi creencia que cualquiera que sea
responsable de la implementación de un pieza de software debe especificar más que esto. Debe
especificar el diseño, la forma; y dentro de que marco los programadores o ingenieros deben crear algo
Ningún ingeniero o programador, ni herramienta de programación, van a ayudarnos, o ayudar al negocio
del software, a compensar un diseño miserable. Control, gestión, educación y todo lo demás de lo que
se habla son importantes; pero la gente de implementación debe entender lo que el arquitecto tiene en
mente.

Probablemente mucha gente tiene experiencia en ver un buen software, una pieza individual de software
que es buena. Y si examinas por qué es bueno, Probablemente encontrará que el diseñador, que puede
o no haber sido el implementador también, entendió completamente lo que quería hacer y él creó la
forma. Algunas de las personas que pueden crear formas no pueden implementarlas y lo contrario es
igualmente cierto. El problema es que en la industria, especialmente en los grandes imperios de
manufactura, se está prestando poca o ninguna consideración. a la arquitectura. - Técnicas
 de Ingeniería de Software: Informe de una Conferencia Patrocinado por el Comité de Ciencias de la
OTAN , B. Randell y JN Buxton, eds., División de Asuntos Científicos, OTAN, 1970, p. 12.

Comenzando su biblioteca de arquitectura de

software
Le recomendamos los siguientes 12 libros a cualquier arquitecto de software en ciernes.
Cubren una amplia gama de temas y proporcionan los fundamentos necesarios para ulteriores
estudios, investigaciones y aplicaciones.

El primer libro
● M. Shaw y D. Garlan, Software Architecture: Perspectives on an Emerging Discipline,
(Arquitectura de software: perspectivas sobre una disciplina emergente), Prentice Hall,
1996. Este libro coloca firmemente a la arquitectura del software en el mapa del
mundo como una disciplina distinta del diseño de software o la programación, y es
todavía una lectura que vale la pena. Los autores intentan definir qué la arquitectura
de software es una tarea difícil. Todavía no hemos llegado a consenso
10 años después. Gran parte del libro está dedicado al concepto de estilos
arquitectónicos, y hay un capítulo útil. en la educación de los arquitectos de software.

La trilogía SEI
● L. Bass, P. Clements y R. Kazman, Software Architecture in Practice (Arquitectura de
software en la práctica), 2ª ed., Addison-Wesley, 2003. Originalmente Publicado en
1998, este libro amplió muchos aspectos de la Arquitectura del software: procesos y
método, representación, técnicas, herramientas e implicaciones empresariales.
Proporciona una buena introducción a varios métodos arquitectónicos del SEI.
● P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord y J. Stafford,
Documenting Software Architectures: Views and Beyond, Addison-Wesley, 2002.
Enfocada únicamente en la documentación y representación de la arquitectura de
software, este libro constituye una guía de aplicación de facto a la bastante abstracta
norma IEEE 1471-2000,, Recommended Practice for Architectural Description of
Software Intensive Systems
● P. Clements, R. Kazman y M. Klein, Evaluating Software Architecture, Addison-
Wesley, 2002. ¿Qué tan buena es la arquitectura? El tercer libro en la trilogía del SEI
(este productivo grupo en realidad escribió más de tres) se centra en la revisión y
evaluación de diversos aspectos de la "bondad" y cualidades de una arquitectura,
existentes o por construir. Un buen complemento a Software Architecture Review and
Assessment (SARA) (Grupo de trabajo SARA, 2002).
Municiones para arquitectos
● C. Hofmeister, R. Nord y D. Soni, Applied Software Architecture, Addison-Wesley,
1999. Los autores ofrecen un sistema temático, detallado método de diseño
arquitectónico y una representación de la arquitectura de software basada en su
trabajo en el centro de investigación de Siemens
● I. Jacobson, M. Griss y P. Jonsson, Software Reuse: Architecture, Process and
Organization for Business Success, Addison-Wesley, 1997. Como lo indica el título,
este libro une a la comunidad de reutilización de software (que estaba prosperando
pero quedándose un poco sin aire a mediados de la década de 1990) con la
comunidad de arquitectura, que muestra cómo los dos pueden aprovecharse el uno al
otro. Presenta elementos del método arquitectónico que encarna el El Proceso
Unificado de Rational. Si la reutilización y la línea de producto. son importantes para
usted, le daremos más lecturas más adelante.
● F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, y M. Stal, Pattern Oriented
Software Architecture: A System of Patterns, John Wiley & Sons, 1996. A partir del
trabajo de patrones de diseño hecho por la banda de cuatro, esta "banda de Cinco”
reunió un útil catálogo de patrones de diseño arquitectónico. Desafortunadamente, no
han continuado lo que habían empezado tan bien

Práctica
● RC Malveau y TJ Mowbray, Software Architect Bootcamp, 2ª ed., Prentice Hall, 2000.
Este "Guía de como empezar" está dirigida a los practicantes.
● DM Dikel, D. Kane y JR Wilson, Software Architecture: Organizational Principles and
Patterns, Prentice Hall, 2001. Los autores han captado la dinámica de lo que sucede
en un equipo de arquitectura de software: las restricciones, tensiones y dilemas en su
modelo VRAPS (visión, ritmo, anticipación,, asociación - partnering- y simplificación).
● E. Rechtin y M. Maier, The Art of Systems Architecting, CRC Books, 1997. El libro
inicial de Rechtin en 1991 fue sobre sistemas y muy poco sobre el software, aunque
los arquitectos de software podrían transponer e interpretar muchos de los principios.
presentados. Al asociarse con Mark Maier, Rechtin fue capaz de cubrir aspectos de
software de forma más específica y profunda. Sin embargo, a los principiantes les
resultará difícil de leer, por lo que deberían comenzar con los dos primeros libros de
este grupo.

Líneas de producto de software

J. Bosch, Design and Use of Software Architecture: Adapting and Evolving a Product-Line
Approach, (Diseño y Uso de Arquitectura de Software: Adaptando y Desarrollando un enfoque
de línea de productos), Addison-Wesley, 2000. Este libro y el siguiente representan la
ramificación de de la arquitectura de software en su aplicación para líneas de producto de
software.
M. Jazayeri, A. Ran, F. van der Linden y P. van der Linden, Software Architecture for Product
Families: Principles and Practice (Arquitectura de Software para Familias de Productos:
Principios y práctica), Addison-Wesley, 2000

Grandes artículos sobre arquitectura de software

Si no eres un gran fanático de los libros, puedes obtener una introducción a muchos de los
conceptos subyacentes de esta colección. de documentos clave.

Cimientos
● M. Shaw y D. Garlan,“An Introduction to Software Architecture,”, V. Ambriola y G.
Tortora, eds., Avances en Ingeniería de Software e Ingeniería del Conocimiento, vol.
2, World Scientific Publishing, 1993, pp. 1–39. Poco antes de su su libro, este
documento reunió lo que sabía acerca de la arquitectura de software en el comienzo
de la Años 90.
● D.E. Perry y A.L. Wolf, “Foundations for the Study of Software Architecture,”
(Fundamentos para el estudio de Arquitectura de Software), ACM Software Eng.
Notas, vol. 17, no. 4, 1992, pp. 40–52. Este papel fundamental será siempre recordado
por darnos esta fórmula simple pero perspicaz: {elements, form, rationale}
= software architecture.

Precursores
● DL Parnas, “On the Criteria to Be Used in Decomposing Systems into Modules,”
(“Sobre los criterios que se utilizarán en la descomposición de sistemas en módulos,
”) Com. ACM, vol. 15, no. 12, 1972, pp. 1053-1058. La arquitectura del software no
explotó arriba de la nada a principios de la década de 1990. Aunque David Parnas no
usó el término “arquitectura”, muchos de los conceptos e ideas le deben mucho a su
obra. Este artículo y los dos siguientes son los más relevantes a este respecto
● DL Parnas, ““On the Design and Development of Program Families,” (Sobre el diseño
y desarrollo del familias de programas, ") IEEE Trans. Software Eng., Vol. 2, no. 1,
1976, pp. 1–9.
● DL Parnas, P. Clements y DM Weiss, ““The Modular Structure of Complex Systems,”
(La Estructura Modular de Sistemas Complejos), IEEE Trans. Ing. De Software, vol.
11, no. 3, 1985, pp. 259–266.
● F. DeRemer y H. Kron, “Programming-in-the-Large versus Programming-in-the-
Small,” (“Programación en grande” vs "Programación en lo pequeño"), Proc. Conf.
Internacional Reliable Software, ACM Press, 1975, pp. 114–121. Su Lenguaje de
Interconexión de Módulos (MIL 75) es el antepasado de todas las ADL, y sus objetivos
de diseño son aún válidos hoy. Los autores tenían una visión clara de la arquitectura
a diferencia del diseño y la programación en el nivel de módulo, pero también en el
borroso, abstracto, "diseño de alto nivel”.
Vistas arquitectónicas
● D. Soni, R. Nord y C. Hofmeister, “Software Architecture in Industrial Applications,”
(“Arquitectura de Software en Aplicaciones Industriales), ”Proc. 17ª Internacional Conf.
Software Eng. (ICSE 95), ACM Press, 1995, pp. 196-207. Este artículo introdujo el
modelo de cinco vistas de Siemens, que los autores detallados en su libro de 1999
Applied Software Architecture
● P. Kruchten, “The 4+1 View Model of Architecture,” (“El modelo de vistas de
arquitectura 4 + 1”), IEEE Software, vol. 12, no. 6, 1995, pp. 45–50. Parte del enfoque
Rational, ahora conocido como RUP: este conjunto de vistas fue utilizado por muchos
consultores en grandes proyectos industriales. Sus raíces están en el trabajo realizado
en Alcatel y Philips a finales de los años ochenta.

Procesos y práctica
● BW Lampson, “Hints for Computer System Design,” (“Consejos para el diseño de
sistemas informáticos”), Operating Systems Rev., vol. 15, no. 5, 1983, pp. 33–48;
reimpreso en IEEE Software, vol. 1, no. 1, 1984, pp. 11-28. Este artículo y el siguiente
nos dieron a uno de nosotros (Kruchten), un arquitecto de software en ciernes en la
década de 1980, gran inspiración. Estos consejos no han envejecido y siguen siendo
relevantes.
● JA Mills, “A Pragmatic View of the System Architect,” (“Una visión práctica del
arquitecto de sistemas”) Com. ACM, vol. 28, no. 7, 1985, pp. 708–717.
● WE Royce y W. Royce, “Software Architecture: Integrating Process and Technology,”
(“Arquitectura de software: integrando Proceso y tecnología”), TRW Quest, vol. 14, no.
1, 1991, págs. 2–15. Este artículo articula muy bien la conexión. entre la arquitectura
y el proceso -- en particular, la necesidad de un proceso iterativo en el que las primeras
iteraciones. construyan y validen la arquitectura.

Dos más por el camino

¿Donde nos detenemos? Estamos tentados a agregar muchos más artículos sobre ADLs
como Rapide, Wright y C2, así como en Arquitectura basada en modelos. Sólo añadiremos
dos más.
M. Shaw y P. Clements, “A Field Guide to Boxology: Preliminary Classification of Architectural
Styles for Software Systems,” (“Una guía de campo para la boxología: Clasificación preliminar
de estilos arquitectónicos para sistemas software, ” Proc. 21st Int'l Software de Computadora
y Aplicación- Confesiones (C OMPSAC 97), IEEE CS Press, 1997, pp. 6–13.
M. Shaw, “The Coming-of-Age of Software Architecture Research,” (“La mayoría de edad de
la investigación en arquitectura de software, ”) Proc. 23 ° Conf. Internacional Software Eng.
(ICSE 01), IEEE CS Press, 2001, pp. 656–664a
Una comunidad de arquitectura de software
Aquí hay una docena de lugares para obtener más información sobre arquitectura de
software, para participar o asistir a conferencias, o para unirse a un grupo de compañeros.

Recursos
● The Software Engineering Institute’s Software Architecture for Software-Intensive
Systems Web site (www.sei.cmu. edu/architecture) contiene muchas definiciones,
documentos sobre sus métodos, y otros apuntes.El grupo de práctica en arquitectura
de software del SEI mantiene este portal.
● La página web de Gaudí System Architecting (www.gaudisite.nl), el nombre del
famoso arquitecto español, se ocupa de la Arquitectura del sistema. Gerrit Muller de
Philips Research y la Embedded Systems Institute en Eindhoven mantiene la página.
● El portal de arquitectura Bredemeyer (www.bredemeyer.com), Llamado “Arquitectura
de Software, Arquitectos y Arquitectura”. Es mantenido por Dana Bredemeyer y Ruth
Malan. Contiene no solo sus propios escritos, sino también una bien organizada
recopilación de otros recursos y anuncios.
● La página Líneas de productos de software (http://softwarepeproductlines.com) se
centra en líneas de productos y reutilización a gran escala.
● SoftwareArchitectures.com (http://softwarearchitectures.com) es otro portal de
recursos de arquitectura.
● Grady Booch, de IBM, encabeza un esfuerzo para presentar un manual para
arquitectos de software y está construyendo un repositorio de arquitecturas de ejemplo
y estudios de caso. (www.booch.com/architecture/index.jsp)
● La Conferencia sobre la Calidad de las Arquitecturas de Software, o QOSA
(http://se.informatik.uni-oldenburg.de/qosa) Fue una nueva conferencia en 2005.
● La arquitectura del software también está presente, a menudo en forma de una sesión
específica o una pista distinta, en otras conferencias, incluyendo ICSE; ECOOP
(Conferencia Europea sobre Programación Orientada al Objeto); OOPSLA (Object-
Oriented Programming Systems, Languages, and Applications); FSE (Foundation of
Software Engineering); APSEC (Asia-Pacific Software Engineering Conference); y
ahora MODELS (ACM/IEEE International Conference on Model-Driven Engineering
Languages and Systems), que asumió la serie de conferencias de UML

Asociaciones y grupos de trabajo.

● Arquitectura de software IFIP WG 2.10 (www.ifip.org/bulletin/bulltcs/
memtc02.htm#wg210). Fundada en la primera conferencia WICSA en 1999, los más
o menos 13 miembros de la IFIP El Grupo de trabajo 2.10 se reúnen cara a cara dos
veces al año y unas pocas veces más por teléfono e internet. Ellos son la fuerza
 impulsora detrás de la serie de conferencias WICSA y este Número especial de
software IEEE. También mantienen el portal www.softwarearchitectureportal.org
● El Instituto Mundial de Arquitectos de Software, o WWISA (www.wwisa.org) fue
fundada por Mark y Laura Sewell en 1999.
● La Asociación Internacional de Arquitectos de Software, o IASA
(www.iasarchitects.org) es una asociación de arquitectos de TI se centran en las redes
sociales, la promoción, la ética y el intercambio de conocimientos.
● IEEE Standards Association WG 1471 (http://standards.ieee.org). El grupo de trabajo
que creó IEEE Std 1471-2000 está ahora resucitando para abordar una revisión del
estándar.
● SARA: revisión y evaluación de la arquitectura del software. Este Grupo informal de
arquitectos de la industria (Philips, Siemens, Rational, Nokia, IBM y Lockheed Martin)
se reunieron regularmente de 1998 a 2001 para compartir prácticas de evaluación de
software. Produjeron un informe en 2001
(www.philippe.kruchten.com/architecture/SARAv1.pdf).
● Investigación y educación. Muchos académicos e investigadores mantienen páginas
con apuntes a su investigación y otros. recursos Escogimos solo dos ejemplos: Nenad
Medvidovic, Universidad del Sur de California,
http://sunset.usc.edu/research/software_architecture/index.html; y Gert Florijn, Centro
de Investigación de Ingeniería de Software en los Países Bajos. Lands,
www.serc.nl/people/florijn/interests/arch.html

Sobre los Autores

Philippe Kruchten es profesor de ingeniería de software en la Universidad de British
Columbia. Sus intereses de investigación incluyen arquitectura de software, procesos de
desarrollo de software, y gestión de proyectos de software. Recibió su doctorado de L'École
Nationale. Supérieure des Télécommunications. Es miembro fundador de IFIP WG2.10 en
Arquitectura de Software. Es un ingeniero profesional en Columbia Británica, un desarrollador
profesional de software certificado, miembro senior de la IEEE Computer Society y autor de
The Rational Unified Process: An Introduction (Addison-Wesley, 2003, 3ª ed.). Contacta con
él en la UBC, 2332 Main Mall, Vancouver, BC V6T1Z4, Canada; kruchten@ieee.org

Henk Obbink es científico principal de Philips Research Laboratories en Eindhoven. Él

encabeza el equipo de investigación de arquitectura para sistemas de salud intensivos en
software En su investigación se han incluido sistemas informáticos, sistemas de
comunicación, sistemas de defensa y productos del consumidor. Recibió su doctorado en
química y física de la Universidad en Utrecht. Es miembro del Grupo de trabajo IFIP 2.10
sobre arquitectura de software y la dirección de Comités de la Conferencia de trabajo IEEE /
IFIP sobre arquitectura de software y la Software Product-Line Conference. Póngase en
contacto con él en Philips Research Laboratories Europe, High Tech Cam. pus 31, WDC
2.030, 5656 AE Eindhoven, Países Bajos; henk.obbink@philips.com
Judith Stafford es profesora principal en la Universidad de Tufts y científica visitante en el
SEI de la Universidad Carnegie Mellon. Su investigación se centra en la arquitectura de
software. análisis de arquitectura, soporte de arquitectura para la composición de
componentes de software y documentación de la arquitectura de software. Ella fue coautora
de Documentation Software Architectures (Addison-Wesley, 2002). Recibió su doctorado en
ciencias de la computación de la Universidad de Colorado en Boulder. Es miembro de la IEEE
Computer Society, ACM SIGSOFT y SIGPLAN , y del IFIP Working.Group de Arquitectura de
Software (WG2.10). Póngase en contacto con ella en el Departamento de Ciencias de la
Computación, Tufts Univ., Medford, MA 02155; jas@cs.tufts.edu; www.cs.tufts.edu/~jas

Glosario

Product-line / Línea de producto

https://marketbusinessnews.com/financial-glossary/product-line/
Una línea de producto es un grupo de productos que una compañía crea bajo una sola marca.
Los productos son similares y se enfocan sobre el mismo sector. Quizá su función o canal de
distribución son los mismos o similares. Además sus atributos físicos, precios, calidad o tipo
de clientes son los mismos.
Una compañía puede tener más de una linea de productos. El número de líneas de
producto refleja sus recursos, quiere decir, que tan poderosa es.
El número de líneas de producto puede también mostrar a otros jugadores en el mercado
cuán competitiva es la compañía, en este contexto, el término “marketplace” significa lo mismo
que mercado “market” en su sentido abstracto.

Seminal Article
https://ncu.libguides.com/researchprocess/seminalworks
“Los trabajos seminales, a menudo llamados esenciales o estudios de punto de referencia,
son artículos que presentan una idea inicial de gran importancia o influencia dentro de una
disciplina particular. Los artículos seminales se mencionan una y otra vez en la investigación,
por lo que es probable que vea estas fuentes citadas con frecuencia en otros artículos de
revistas, libros, disertaciones, etc.”