de miles de aplicaciones disponibles para los modelos más populares, es imposible saber, sin

encender el dispositivo y ver qué está instalado y probar las aplicaciones para comprender qué
hacen, qué más es capaz el teléfono inteligente de. Además, ¿qué pasa con la infraestructura
necesaria para respaldar la creación y entrega de tales aplicaciones, y mucho menos la necesaria
para permitir que el teléfono se use para su propósito más fundamental de hacer llamadas
telefónicas? ¿Qué tan complicada es la infraestructura? ¿Quién lo dirige? ¿Cómo se paga? El caso
es que todos los proyectos que involucran sistemas complejos tendrán un elemento intangible
sobre ellos, ya sea un sistema de control, un proceso o lo que sea.

El término importante que se utiliza aquí es "complejidad" en lugar de tamaño, ya que el tamaño
no es necesariamente un reflejo de la complejidad de un sistema. La siguiente sección analiza la
complejidad con más detalle.

4.3 Los tres males

Los proyectos fracasan y los desastres ocurren por muchas razones. Sin embargo, hay tres razones
subyacentes por las que las cosas van mal, los "tres males" de la complejidad, la falta de
comprensión y problemas de comunicación.

4.3.1 Complejidad

El concepto de complejidad se ilustrará de dos maneras: una que enfatiza la importancia de las
relaciones y otra que usa un brontosaurio para visualizar la naturaleza de la evolución de la
complejidad.

Para el primer ejemplo, considere cinco casillas que pueden representar cinco elementos dentro
de un Sistema, como se muestra en la Figura 4.4 (a). Cada elemento puede representar casi
cualquier cosa, desde una oración de texto que representa un Requisito, hasta un ensamblado que
forma un Sistema, hasta los usuarios que se relacionan con un Sistema. Cualquiera de estos
elementos puede muy bien ser entendido por cualquiera que lea el diagrama, pero esto no
significa necesariamente que se entienda el Sistema en sí.
Considere ahora la Figura 4.4 (b) y está bastante claro que este diagrama es más complejo que el
anterior, aunque nada ha cambiado en los elementos mismos, solo las relaciones entre ellos.

Considere ahora la Figura 4.4 (c) donde es, nuevamente, obvio que este diagrama es más complejo
que su predecesor y mucho más complejo que el primero.
De hecho, cuantas más relaciones se agreguen entre los elementos del sistema, mayor será la
complejidad del sistema en general. Se podrían dibujar más y más líneas en este diagrama y la
complejidad aumentará drásticamente, a pesar de que la complejidad de cada uno de los cinco
elementos no ha aumentado.

El punto que se está comunicando aquí es que solo porque alguien entienda cada elemento dentro
de un Sistema, esto no significa que se entienda el Sistema en sí. La complejidad de un sistema se
manifiesta por las relaciones entre las cosas, en este caso los elementos del sistema. Debe tenerse
en cuenta, sin embargo, que estos elementos pueden existir en cualquier nivel de abstracción del
Sistema, dependiendo de lo que representen; por tanto, la complejidad puede manifestarse en
cualquier punto del Sistema. La complejidad del conjunto del Sistema es ciertamente mayor que la
complejidad de la suma de sus partes.

Se puede pensar en esto como poder ver tanto el bosque como los árboles.

La segunda forma en que se ilustra la complejidad es a través del concepto de "Brontosaurio de la

complejidad". En esta analogía un poco extraña, la magnitud de la complejidad es análoga al
grosor del brontosaurio, en el sentido de que la complejidad de un sistema al principio está
representada por la cabeza del dinosaurio y, a medida que avanza el ciclo de vida del proyecto,
esta complejidad aumenta. (viajando por el cuello), aumenta aún más (a través del vientre) antes
de reducirse y finalmente terminar en la cola del brontosaurio.

Esto encaja con la forma del brontosaurio, que es "delgado en un extremo, mucho más grueso en
el medio y luego delgado nuevamente en el otro extremo" [2]. La complejidad percibida de un
proyecto es casi siempre baja para empezar, pero aumenta durante el

de un Proyecto, ya que la comprensión del impacto total de los Requisitos y las limitaciones se
comprende completamente. En el momento en que se comprende completamente el problema,
un Proyecto está bien y verdaderamente en el '' vientre del brontosaurio '', mientras que cuando
el diseño comienza y se optimiza, entonces el Proyecto debería dirigirse hacia la '' cola del
brontosaurio ' '. Aplicando la analogía del brontosaurio de complejidad, se demuestra que hay que
pasar de la cabeza (ideas iniciales y Requisitos) a la cola (Sistema) pero que es imposible hacerlo
sin pasar por el vientre del brontosaurio.

Considere la situación cuando un Proyecto está a la cabeza del brontosaurio, entonces esto puede
visualizarse como la ilustración de la Figura 4.4 (a). A medida que aumenta la complejidad del
Proyecto y bajamos por el cuello del brontosaurio, la complejidad aumenta, como se muestra en la
Figura 4.4 (b). De hecho, cuantas más relaciones se agregan entre los Elementos del Sistema (y,
por lo tanto, cuantas más interacciones entre ellos), más nos acercamos al vientre del
brontosaurio.

Muchos proyectos fracasarán porque el proyecto nunca salió de la barriga o, en algunos casos, se
quedó aún más arriba en el cuello. Si un Proyecto se queda en la cabeza o en el cuello, existe un
gran peligro de que el Sistema se simplifique demasiado y la complejidad inherente al Sistema
nunca se descubra hasta que sea demasiado tarde. Sin embargo, si el Proyecto permanece en el
vientre, entonces la complejidad se ha hecho realidad, pero no se ha gestionado de forma eficaz.
Desafortunadamente, cuando un Proyecto se encuentra en el vientre del brontosaurio, al personal
del Proyecto le puede parecer que el mundo ha llegado a su fin y que no se comprende el Proyecto
en su totalidad. El desarrollo exitoso de un Sistema se trata de poder ver al brontosaurio como un
todo y que hay vida después del vientre.

En un giro final a esta analogía, existe una gran diferencia entre la complejidad y el brontosaurio.
La complejidad es difícil de visualizar, pero definitivamente existe en cualquier sistema. Un
brontosaurio, por otro lado, es fácil de visualizar (ver Figura 4.5) pero nunca existió en realidad (se
demostró en 1974 que el brontosaurio era en realidad el cuerpo del Apatosaurio y la cabeza del
Camarasaurio).

4.3.2 Falta de comprensión

La falta de comprensión puede ocurrir en cualquier etapa del ciclo de vida del sistema y también
puede ocurrir durante cualquier proceso. Considere los siguientes ejemplos de una falta de
comprensión que afecta a un proyecto.

● Puede ocurrir una falta de comprensión durante la etapa de concepción de un proyecto, durante
un proceso relacionado con los requisitos. Si los Requisitos no se establecen de manera concisa e
inequívoca (o, en realidad, lo más inequívocamente posible), esta falta de comprensión se
extenderá en cascada a lo largo de todo el Proyecto. Es ampliamente aceptado que los errores
cometidos durante las primeras etapas del ciclo de vida cuestan muchas veces más de corregir
durante las últimas etapas del ciclo de vida, por lo que tiene sentido hacer las cosas bien lo antes
posible [3].

● Puede ocurrir una falta de comprensión durante la Etapa de desarrollo de un Proyecto, durante
un Proceso relacionado con el análisis. Por ejemplo, puede haber una falta de dominio
conocimiento durante el análisis que puede llevar a alguien a formular suposiciones falsas o, de
hecho, a obtener algo completamente incorrecto debido a conocimientos insuficientes. Una vez
más, los errores no corregidos aquí conducirán a problemas mayores más adelante en el ciclo de
vida del desarrollo.

● Puede ocurrir una falta de comprensión durante la Etapa operativa de un Proyecto, durante un
Proceso relacionado con la operación. El uso incorrecto de un sistema puede provocar una falla o
un desastre del sistema. Por ejemplo, personas que no siguen los procedimientos de seguridad y
personas que no utilizan las herramientas adecuadas.

Por supuesto, estos ejemplos son simplemente una representación de algunas formas en las que
la falta de comprensión puede manifestarse en un Sistema; hay muchos otros lugares en el Ciclo
de Vida donde pueden ocurrir problemas.

4.3.3 Comunicación

El tercero de los tres males es el problema de la comunicación o, más correctamente, la

comunicación ineficaz. La riqueza y complejidad de la comunicación humana es lo que separa a los
humanos de otras especies. Uno de los primeros ejemplos registrados de fracaso del Proyecto es
el de la Torre de Babel, descrito maravillosamente por Fred Brookes [4]. La Torre de Babel
comenzó como un proyecto muy exitoso y las primeras etapas del proyecto se desarrollaron sin
problemas y el proyecto se desarrolló según lo programado, dentro del presupuesto y cumplía con
todos los requisitos del proyecto. Sin embargo, uno de los requisitos clave de las partes
interesadas no se consideró adecuadamente, lo que provocó la caída del Proyecto. Cuando la
parte interesada intervino de manera divina, la comunicación entre el personal del Proyecto fue
efectivamente destruida.

Los problemas de comunicación pueden ocurrir en cualquier nivel de una organización o proyecto,
por ejemplo:

● Nivel de persona a persona. Si las personas no pueden comunicarse a nivel personal, hay pocas
esperanzas de que el Proyecto tenga éxito. Esto puede deberse a que las personas tienen
diferentes idiomas hablados, antecedentes técnicos o incluso un choque de personalidades.

● Nivel de grupo a grupo. Los grupos o unidades organizativas dentro de una organización deben
poder comunicarse eficazmente entre sí. Estos grupos pueden ser de diferentes áreas técnicas,
como grupos de hardware y software, o los grupos pueden traspasar fronteras, como grupos de
gestión y técnicos, o marketing e ingeniería. Estos grupos suelen utilizar un lenguaje específico
para ellos mismos, lo que dificulta la comunicación entre grupos.

● Nivel de organización a organización. Las diferentes organizaciones hablan diferentes idiomas;

cada una tendrá sus propios términos específicos para diferentes conceptos, además de tener una
terminología específica de la industria. Cuando dos Organizaciones están trabajando en una
relación cliente-proveedor, el proveedor a menudo tiene la responsabilidad de hablar el idioma
del cliente para que la comunicación sea efectiva, en lugar de que el cliente tenga que hablar el
idioma del proveedor. Después de todo, si el proveedor no hace un esfuerzo por hablar el idioma
del cliente, es muy probable que no retenga clientes por mucho tiempo.

● Nivel de sistema a sistema. Incluso los sistemas no humanos deben poder comunicarse entre sí.
Los sistemas técnicos deben poder comunicarse con los sistemas técnicos, pero también con los
sistemas financieros, contables, medioambientales, etc.

● Cualquier combinación de los anteriores. Para hacer las cosas aún más confusas, también es
posible casi cualquier combinación de los tipos de comunicación anteriores.
Estos problemas, por lo tanto, dan lugar a ambigüedades en la interpretación de cualquier tipo de
comunicación, ya sea un lenguaje hablado o un lenguaje técnico o de aplicación específica.

4.3.4 El triángulo vicioso

Habiendo establecido que existen estos tres males, las cosas empeoran aún más. Cada uno de
estos tres males no existe de forma aislada, sino que se alimentarán entre sí. Por tanto, la
complejidad no gestionada conducirá a una falta de comprensión y problemas de comunicación.
Los problemas de comunicación conducirán a una complejidad no identificada y una falta de
comprensión. Por último, la falta de comprensión dará lugar a problemas de comunicación y
complejidad.

Los tres males, por tanto, forman un triángulo de maldad imposible de eliminar. De hecho, lo
mejor que se puede esperar es abordar cada uno de estos males de forma individual al observar
cualquier visión de un sistema.

4.4 ¿Qué es SysML?

SysML se define en el sitio web de OMG (Object Management Group, el organismo de estándares
de la industria que administra y configura SysML) como 'un lenguaje de modelado gráfico de
propósito general para especificar, analizar, diseñar y verificar sistemas complejos que pueden
incluir hardware , software, información, personal, procedimientos e instalaciones. En particular,
el lenguaje proporciona representaciones gráficas con una base semántica para modelar los
requisitos, el comportamiento, la estructura y los parámetros del sistema ”[5].

El lenguaje se originó a partir de una iniciativa entre el OMG y el Consejo Internacional de

Ingeniería de Sistemas (INCOSE) en 2003 para adaptar el UML para aplicaciones de ingeniería de
sistemas. Para obtener más información sobre la historia de SysML, consulte la Sección 4.4.2. La
audiencia principal de SysML son los ingenieros de sistemas y SysML está destinado a proporcionar
un lenguaje de modelado de ingeniería de sistemas de propósito general.

4.4.1 Relación de SysML con UML

El SysML se basa en UML, un lenguaje de modelado gráfico de propósito general dirigido a
ingenieros de software y que, en su aparición en 1997, representó una importante unificación de
la gran cantidad de lenguajes que surgieron a finales de los 80 y principios de los 90.

El UML define 13 tipos de diagrama que permiten definir los requisitos, el comportamiento y la
estructura de un sistema software. Debido a su apariencia el