Curso de Ingenieria Sistemica PDF

Curso de Pensamiento Sistémico
MANUEL ALEJANDRO MOGOLLÓN MEJÍA
PROYECTO DE GRADO
Asesor:
Luis Arturo Pinzón Salcedo, PhD
UNIVERSIDAD DE LOS ANDES

FACULTAD DE INGENIERÍA
Departamento de Ingeniería Industrial
Enero 2012
Curso de Pensamiento Sistémico 2
Contenido
1 INTRODUCCIÓN .............................................................................................................. 4
2 OBJETIVOS ...................................................................................................................... 5
2.1 Objetivo General ...................................................................................................... 5
2.2 Objetivos Específicos .............................................................................................. 5
2.3 Alcance y productos finales ..................................................................................... 5
3 DESCRIPCIÓN DE LA PROBLEMÁTICA Y JUSTIFICACIÓN DEL TRABAJO .......................... 5
4 MARCO TEÓRICO ............................................................................................................ 6
4.1 Marco Teórico .......................................................................................................... 6
5 DEFINICIÓN Y ESPECIFICACIÓN DEL TRABAJO ................................................................ 8
5.1 Definición ................................................................................................................ 8
5.2 Especificaciones ....................................................................................................... 9
6 METODOLOGÍA DEL TRABAJO ........................................................................................ 9
6.1 Plan de trabajo ......................................................................................................... 9
6.2 Búsqueda de información ...................................................................................... 10
6.3 Alternativas de desarrollo ...................................................................................... 10
7 TRABAJO REALIZADO .................................................................................................... 11
7.1 Programa del curso ................................................................................................ 11
7.2 Clase 1, Revisión de la Ingeniería Sistémica: ........................................................ 12
7.3 Clase 2, Proceso de diseño del sistema .................................................................. 15
7.4 Clase 3, Definición de requerimientos ................................................................... 18
7.5 Clase 4, Arquitectura del sistema .......................................................................... 22
7.6 Clase 5, Selección de conceptos ............................................................................ 27
7.7 Clase 6, Definición del diseño ............................................................................... 28
7.8 Clase 7, Ingeniería Sistémica Humana .................................................................. 30
7.9 Clase 8, Integración del sistema ............................................................................ 32
7.10 Clase 9, Verificación y Validación .................................................................... 33
7.11 Clase 10, Seguridad de los sistemas ................................................................... 36
7.12 Clase 11, Manejo del ciclo de diseño ................................................................. 37
7.13 Tareas ................................................................................................................. 38
7.13.1 Tarea 1 ............................................................................................................ 38
7.13.2 Tarea 2 ............................................................................................................ 39
7.14 Proyecto Final .................................................................................................... 41
7.15 Quiz .................................................................................................................... 46
8 DISCUSIÓN .................................................................................................................... 46
9 CONCLUSIONES............................................................................................................. 47
10 AGRADECIMIENTOS ...................................................................................................... 47
11 REFERENCIAS ................................................................................................................ 48
12 Anexos .......................................................................................................................... 49
12.1 Anexo A: Programa del Curso ........................................................................... 49

12.2 Anexo B: Clase 1, Revisión de la Ingeniería Sistémica ..... ¡Error! Marcador no
definido.
12.3 Anexo C: Clase 2, Proceso de diseño del sistema .............. ¡Error! Marcador no
definido.
12.4 Anexo D: Clase 3, Definición de requerimientos .............. ¡Error! Marcador no
definido.
12.5 Anexo E: Clase 4, Arquitectura del sistema ....... ¡Error! Marcador no definido.
12.6 Anexo F: Clase 5, Selección de conceptos ......... ¡Error! Marcador no definido.
12.7 Anexo G: Clase 6, Definición del diseño ........... ¡Error! Marcador no definido.
12.8 Anexo H: Clase 7, Ingeniería Sistémica Humana .............. ¡Error! Marcador no
definido.
12.9 Anexo I: Clase 8, Integración del sistema .......... ¡Error! Marcador no definido.
12.10 Anexo J: Clase 9, Verificación y Validación .... ¡Error! Marcador no definido.
12.11 Anexo K: Clase 10, Seguridad de los sistemas .. ¡Error! Marcador no definido.
12.12 Anexo L: Clase 11, Manejo del ciclo de diseño . ¡Error! Marcador no definido.
1 INTRODUCCIÓN
Este proyecto de grado tiene como objetivo desarrollar un curso o un complemento a un
curso, siguiendo la metodología de manejo de proyectos de la Ingeniería Sistémica. Como
estándar de buenas prácticas se escogió el “NASA Systems Engineering Handbook” [NASA].
Este texto contiene una estandarización de todas etapas que conllevan a la creación de
proyectos de alta complejidad como los que se llevan acabo en esta agencia.
El modelo V comúnmente utilizado para el desarrollo de Software es el eje central de este

curso. Cada etapa de este fue asociada con las buenas prácticas de la NASA y a una amplia
bibliografía sobre el tema. Con esto se busca que el estudiante o el lector de este proyecto
puedan tener una idea base de lo que es la Ingeniería Sistémica y tener las herramientas para
desarrollar proyectos con un alto nivel de complejidad.
Fig1. Modelo “V” del proceso de ingeniería sistémica.
Como parte de este curso se propone utilizar los equipos de Lego Mindstorms que dispone el
Departamento de Ingeniería Industrial para realizar un desarrollo práctico de la metodología
enseñada. Se expone un ejemplo completo como guía donde se aplica la metodología
mencionada anteriormente y se cumple un objetivo del curso.
2 OBJETIVOS
2.1 Objetivo General
Desarrollar un curso de pensamiento sistémico que implemente las buenas prácticas de
desarrollo de proyectos creado por la NASA en el “NASA Systems Engineering Handbook”
[NASA] siguiendo el modelo V de Ingeniería Sistémica.
2.2 Objetivos Específicos

Desarrollar un curso que se ajuste a la estructura de enseñanza de la Universidad de los Andes
en la cual se comparta la metodología de pensamiento sistémico utilizada en el desarrollo de
proyectos por la NASA.
Aprender a desarrollar un curso con unos lineamientos de los temas a ser enseñados.
2.3 Alcance y productos finales

Desarrollar el curso de Pensamiento Sistémico. Los entregables serán las presentaciones
respectivas, las tareas y sus soluciones, el programa del curso, quizzes, parciales y toda la
documentación de soporte que debe ser estudiada en el curso.
3 DESCRIPCIÓN DE LA PROBLEMÁTICA Y JUSTIFICACIÓN DEL TRABAJO

Los sistemas más comunes en nuestro diario vivir consisten de cientos de miles de partes
diferentes que trabajan juntas para obtener un sinnúmero de funciones de valor agregado.
Ejemplos de esto son los sistemas que transportan personas y mercancías, o la toma y
distribución de información en lugares remotos. Todo esto es una combinación de hardware,
software y manipulación humana. Estos últimos son la parte vital de estos sistemas como los
diseñadores, creadores, usuarios y personas de mantenimiento. En este curso se utilizará el
término “Stakeholders” para identificar personas y organizaciones que tienen algún interés o
afectan el sistema.
La Ingeniería Sistémica es una disciplina que originalmente fue diseñada para coordinar todas
las actividades de diseño y administración que ocurren durante los proyectos aeroespaciales
de una forma tal que el resultado satisfaga los requerimientos y que estos requerimientos
satisfagan las necesidades de los stakeholders. La Ingeniería Sistémica en este contexto se
trata entonces del diseño y manejo de partes, sus interfaces y el comportamiento en conjunto,
de forma que se logre el resultado buscado.
Han surgido un sinnúmero de estándares y manuales para las buenas prácticas y métodos de
la Ingeniería Sistémica. Estos son muy útiles para darle consistencia a los procesos asociados al
desarrollo de cualquier proyecto. En el curso sugerido se estudiarán algunos de los estándares

más importantes y los métodos que apoyan el diseño y manejo de sistemas.
Este curso brinda las herramientas para lograr trabajar en proyectos de alta complejidad, pero
no entra en profundidad en los detalles de cómo desarrollar un sistema en específico. Se
busca que este curso sea sólo la introducción al mundo de la Ingeniería Sistémica. El estado de
arte de este tema y el actuar recomendado están lejos de ser perfectos. A medida que le
tecnología ha progresado y los sistemas se han vuelto más y más robustos, el nivel de
complejidad ha crecido de la mano de estos. Esto conlleva un reto enorme para el diseño y
manejo de estos. Como se puede ver esta es una materia en constante evolución que está
sujeta a los retos de hacer un sistema más económico y de fácil uso, mientras a su vez se
asegura una mayor seguridad en su operación. Por esta razón es importante conocer
metodologías que permiten diseñar, desarrollar y manejar estos nuevos sistemas de manera
correcta minimizando los errores y problemas por medio del seguimiento estricto de las
buenas prácticas del desarrollo de proyectos planteados en este curso.
4 MARCO TEÓRICO
4.1 Marco Teórico
La teoría estudiada en este proyecto consistió principalmente en comprender el “NASA
Systems Engineering Handbook” [NASA] desarrollado por la NASA. En este se hace un
extensivo recuento de los lineamientos para poder llevar a acabo los proyectos de grandes
dimensiones que se desarrollan en esta agencia. Los principales conceptos aprendidos son los
fundamentos de la Ingeniería Sistémica [Ryschkewitsch], con el motor respectivo de desarrollo
de proyectos [NASA, Capítulo 2.1 The Common Technical Processes and the SE Engine Pág.
23], donde se estudia a fondo todas las fases para el diseño e implementación de un proyecto.
Este documento abarca cada una de las diferentes etapas de desarrollo de un proyecto, con
todas las complicaciones que estas pueden tener. Por esto es una herramienta muy útil y en
constante evolución
Figura 2. Motor de desarrollo de proyectos de la Ingeniería Sistémica. [NASA Capítulo 2.1 The Common Technical Processes
and the SE Engine Pág. 23]
También se estudió el ciclo de desarrolla de la NASA y el de desarrollo de sistemas mostrado a

continuación. Estos dos diagramas son la base para cualquier proyecto desarrollado y son
extensivamente utilizados a lo largo del curso diseñado.
Figura 3. Interrelación entre los procesos de diseño de proyectos. [NASA, Capítulo 4.0 System Design Pág. 49]
Estos modelos han sido útiles a la NASA para llevar el hombre a la estación espacial, reparar el
Hubble, etc [Incose, 2.5 Use of systems engineering, Pág. 24]. Actualmente se está utilizando
esta metodología para diseñar los nuevos trasbordadores y llevar el hombre a Marte.
Como complemento a esta lectura se utilizó el documento “The art and science of systems
engineering”[Ryschkewitsch]. En este documento se hace una clara definición de las
habilidades que un buen Ingeniero Sistémico debe aprender, donde el liderazgo es la
herramienta principal para lograr un exitosos desarrollo de un proyecto.
Figura 4.Otra perspectiva en el desarrollo de actividades de los Ingenieros Sistémicos. [Ryschkewitsch, Figura 6. Pág. 19]
5 DEFINICIÓN Y ESPECIFICACIÓN DEL TRABAJO

5.1 Definición
En la Universidad de los Andes no hay un curso donde se aplique una de las metodologías más
utilizadas en los proyectos más importantes de nuestra época. Entre los proyectos realizados
utilizando esta metodología se encuentra el nuevo avión de Airbus, aviones militares y todos
los proyectos de la NASA actuales. Este curso está siendo dictado en una gran cantidad de
universidades a nivel mundial. Resulta adecuado seguir la tendencia de internacionalizar aún
más la Universidad de las Andes y desarrollar cursos que sean compatibles con los estándares
mundiales para mejorar el nivel de los egresados.
5.2 Especificaciones
Los estudiantes después de tomar el curso podrán:
Describir los estándares y prácticas más importantes de la Ingeniería Sistémica.

Conocer los pasos en el proceso de desarrollo de proyectos de la Ingeniería Sistémica,
empezando por los stakeholders y terminando con la implementación de sistemas por
medio de métodos de transición.
Entender la importancia del poder humano en el desarrollo de cualquier sistema.
Entender las limitaciones que tiene la Ingeniería Sistémica actual en términos de
complejidad, incertidumbre entre otros.
Usar e implementar los estándares y metodologías de la Ingeniería Sistémica a diferentes
casos sencillos, para cementar las bases que servirán para resolver problemas complejos
en la vida real.
6 METODOLOGÍA DEL TRABAJO

Se realizaron todos los entregables planteados al inicio del documento siguiendo una
metodología de investigación y desarrollo, donde a partir del modelo “V” de desarrollo de
proyectos se decidió implementar cada una de las etapas de este como una clase
independiente llegando así a tener 12 clases diferentes.
6.1 Plan de trabajo

Inicialmente se empezó a trabajar sobre el Handbook de la NASA, pero a medida que el
documento se iba volviendo más técnico se decidió tomar un enfoque diferente a
simplemente enseñar los elementos de este. Con esto se procedió a investigar sobre la
Ingeniería Sistémica y con esto se logró definir que el modelo V de desarrollo de proyectos se
ajustaba correctamente con los objetivos de este proyecto de grado.
Paralelamente a esto se tomó el curso de aprendizaje presencial dado en la Universidad

Javeriana donde la idea era aprender cómo enseñar. Allí se expuso que los adultos tienden a
aprender de forma práctica no teórica. Por esto el curso debe tener un enfoque donde los
ejemplos y ejercicios tienen el foco de la metodología.
Con esto definido se empezó a desarrollar el curso, empezando por el programa para tener así
unos lineamientos de cuál era el objetivo principal. De aquí se procedió a desarrollar cada
clase basándose en una investigación previa. Después de esto se realizaron las tareas y las
bases para el proyecto final.
6.2 Búsqueda de información

Se utilizaron las herramientas brindadas por la universidad para obtener todos los documentos
necesarios para realizar una buena investigación que permitiera desarrollar clases con una
excelente bibliografía. Como principal fuente de información se utilizó la página de la NASA de
educación (http://www.nasa.gov/offices/education/index.html) donde se publican todos los
papers desarrollados por miembros de la organización con libre distribución. En esta página se
puede encontrar tanto el documento principal utilizado en este proyecto de grado (NASA
Systems Engineering Handbook) como los artículos de soporte como “The art and science of
systems engineering”, entre otros.
El convenio de la Universidad con la base de datos del IEEE Xplore Digital Library publicada por
el “Institute of Electric and Electronics Engineers” que ofrece el acceso al texto completo de
sus publicaciones. Con esta base datos es posible acceder a una gran cantidad de artículos de
manera gratuita y en sus versiones originales de publicación.
También se creó un canal de comunicación con personas del MIT y de Cornell que dieron unas
pautas sobre los cursos de pensamiento sistémico vistos y acceso a algunos elementos de
estos cursos por medio de las herramientas de información abierta que tienen estas
universidades. Además se utilizó la herramienta del MIT OpenCourse
(http://ocw.mit.edu/index.htm) que permite ver elementos de cursos antiguos dictados en la
gran mayoría de facultades de la Universidad.
6.3 Alternativas de desarrollo

Se pensó en varios enfoques para desarrollar las presentaciones pero se decidió utilizar la
estrategia de Steve Jobs para hacer una gran presentación. Se plantea la posibilidad de
mostrar esta presentación a los alumnos de la clase para que aprendan cómo vender una idea
por medio de una excelente presentación.
Inicialmente el proyecto se centraba en el Handbook, pero este fue migrado hacia el concepto
del modelo “V” para desarrollo de proyectos. Este cambio se dio por el contenido técnico del
documento de la NASA. Este se centra en procesos específicos de la agencia cerrándose a
aplicaciones externas de menor complejidad. Para un curso de Ingenieros Industriales centrar
toda una metodología a ejemplos de alto nivel técnico, con referencias a elementos que en si
deben ser explicados de forma extensiva, hace que se pierda todo nivel de interés de las
personas ya que su aplicabilidad en el mundo práctico sobrepasa las necesidades de los
estudiantes por los altos niveles de complejidad manejados en este documento. Teniendo esto
en cuenta se encontró esta metodología que permite utilizar varias herramientas presentadas
por la NASA, pero implementadas en elementos reales y casos simples de la vida práctica.
7 TRABAJO REALIZADO
El proyecto realizado consiste de una serie de documentos separados que serán condensados
en esta entrega, los cuales componen el curso de Pensamiento Sistémico.
7.1 Programa del curso

Este puede ser visto en el Anexo A. En este programa sugerido para el curso se hace una breve
descripción de la ingeniería sistémica. Se explica la utilización del modelo V como metodología
principal del curso y los principales conceptos a ser desarrollados a lo largo de este, como la
definición del proyecto, prueba e integración, verificación y validación, desempeño, costo y
operatividad del sistema.
Después de esto se da una pequeña motivación la cual busca que los estudiantes se enteren
de los inmensos alcances que puede llegar a tener una metodología como esta. También se
menciona que esta metodología está en constante evolución por lo que los estudiantes deben
estar al tanto de los nuevos avances y en la medida de lo posible colaborar para el crecimiento
de esta área en proyectos de menor tamaño, ya que actualmente se implementa en proyectos
de alta complejidad.
También se exponen los objetivos propuestos del curso donde el estudiante podrá describir
los estándares y prácticas más importantes de la Ingeniería Sistémica. Conocer los pasos en el
proceso de desarrollo de proyectos de la Ingeniería Sistémica. Deberá comprender la
importancia del poder humano en el desarrollo de cualquier sistema y las limitaciones que
tiene esta metodología.
En este también se explica la estructura del curso el cual tendrá una duración de hora y media
por sesión donde se presentarán las ideas principales del modelo V en cada una. Se establece
la presentación de dos parciales individuales y una sesión complementaria por cada magistral
donde los estudiantes deben exponer un artículo definido en la estructura del curso en este
mismo documento. Se define también los requerimientos para aprobar el curso y el desarrollo
de un proyecto final que busca implementar de forma práctica las herramientas dadas en el
curso.
A continuación se presentan cada clase del curso, inicialmente como texto y posteriormente como
presentaciones.
7.2 Clase 1, Revisión de la Ingeniería Sistémica:

Las diapositivas sugeridas se muestran en el anexo B. Esta sesión esta dividida en dos secciones. La
primera es una introducción a la Ingeniería Sistémica, donde se explican los elementos principales
del curos, como son mencionados en el programa del curso. El objetivo de la primera parte es
exponer el programa del curso, la motivación, las complejidades de los sistemas, las limitaciones
de la metodología y los objetivos de aprendizaje.
Niveles en un árbol de desarrollo:
(1)
Williams 3.1 Behavior Study Approach, pág 6]
# Partes # Niveles
Martillo 3 1
Tabla 25 2
iPod 451 3
Portátil +1000 4
Carro +30,000 6
Avión +6 millones 8
Tabla 1. Ejemplo de número de niveles en productos comunes. [Williams 3.1 Behavior Study Approach, pág 9]
En esta tabla se puede ver el aumento de la complejidad de los sistemas con respecto al número
de niveles de desarrollo de sus partes. Cada nivel representa un “tier” de la figura 6. Donde los
productos simplificados se ven en el nivel más bajo. A mayor número de niveles, mayor es la
complejidad de desarrollo de un proyecto.
En la segunda parte de la sesión se hace una introducción a la teoría general de la Ingeniería

Sistémica y se exponen herramientas para el seguimiento de un proyecto
Figura 5. Alcances de la Ingeniería Sistémica. [Ryschkewitsch pág. 5]
Los ingenieros en general se enfocan en áreas específicas de un proyecto como lo es la

arquitectura o el desarrollo en general. Para ser un buen ingeniero sistémico se debe adquirir
experiencia en cada una de estas áreas para poder tener las herramientas para solucionar los
problemas que pueden surgir al desarrollar un proyecto.
Se muestra el motor de desarrollo de proyectos de la Figura 2. En la diapositiva 13, ya que se le

debe explicar a los estudiantes el flujo natural de un proyecto. Este motor es muy específico, por
lo que solo se mencionan las áreas a ser desarrolladas en este curso que son: los procesos de
definición de requerimientos (1,2), el proceso de definición de soluciones (3, 4), los procesos de
control(11, 12, 13), los procesos de realización de diseño (5,6) y los procesos de evaluación (7,8).
Este es el orden en que serán vistos en el curso, no el orden numérico sino el orden de mención.
Análisis Top-down / Bottom-up:
Figura 6. Análisis top down de un proyecto. [NASA, 2.3.2 Example Premise, Pág. 29]
Figura 7. Análisis bottom-up de un proyecto. [NASA, 5.3.2.2 Verification in the Life Cycle Pág. 108]
Estas dos figuras muestran dos formas diferentes de trabajar un proyecto. La primera inicia desde
la definición del producto final. Desde ahí descompone los componentes de éste y continua hasta
llegar a las partes específicas que no pueden ser separadas. El segundo análisis inicia desde los
subcomponentes de un elemento que al unirse con otros subsistemas permiten desarrollar una
solución que llegue al usuario final.
Figura 8. Ciclo de vida de un proyecto. [NASA, 3.1 Program Formulation, Pág. 38]
Este es el estándar para la ilustración del cronograma de un proyecto. Se desarrolla de izquierda a

derecha donde la primera etapa son los estudios de diseño y termina con el cierre o entrada en
funcionamiento del proyecto.
Después de esto se propone exponer sobre que hace a un buen ingeniero, más específicamente un
Ingeniero Sistémico. Para esto se utiliza el estudio “NASA SYSTEMS ENGINEERING BEHAVIOR
STUDY” [Williams]. Donde por medio de entrevistas de ejecutivos de la NASA lograron definir un
modelo de competencias de un buen Ingeniero.
Ésta como todas las metodologías tiene problemas. La principal es que se asume un diseño “clean
sheet”. Esto implica que el proyecto esta siendo desarrollado desde cero, pero usualmente esto no
es real. En el momento que se utiliza un sistema pre-existente sobre el cual se desarrolla una
nueva plataforma, se pierde el uso de los primeros pasos de la metodología.
También se asume que los requerimientos del sistema y las necesidades de los usuarios son
estables, pero estos cambian con nuevas administraciones o con simplemente el estado de los
Stakeholders. El impacto de factores externos no hace parte del desarrollo del sistema según esta
metodología, éste no contempla la posibilidad de fallas en las plantas, de problemas de recursos,
limitaciones impuestas, entre muchas otras. Los efectos de la redistribución del presupuesto es
más importante que como se ve en las buenas prácticas del Handbook[NASA].
El artículo sobre el cual los estudiantes deben realizar la sesión complementaria es “NASA
SYSTEMS ENGINEERING BEHAVIOR STUDY” [Williams]. Este es un estudio realizado entre los
miembros más importantes de los diferentes grupos de trabajo de la NASA para definir que se
necesita para ser un buen Ingeniero Sistémico. Es muy interesante para los estudiantes ver que se
espera de un buen Ingeniero en agencias tan importantes como la NASA.
7.3 Clase 2, Proceso de diseño del sistema

Las diapositivas sugeridas se muestran en el anexo C. El objetivo principal de esta sesión es lograr
darle las herramientas al estudiante para que pueda definir claramente los Stakeholders de un
proyecto y que entienda la verdadera importancia que esto tiene en un proyecto. Esta es la base
para el éxito de cualquier proyecto. Si no sé para quién está dirigido un producto, no podré definir
que es lo que se requiere que éste haga. Se presenta una caricatura en la diapositiva 4 para
mostrar que siempre existirá la discusión sobre cual es el verdadero objetivo del proyecto. La tarea
del Ingeniero es tomar todas estas expectativas e intentar definir las que son vitales para el
desarrollo de éste.
La definición de las expectativas se utiliza para identificar quiénes son los Stakeholders (para todas
las fases del proyecto). Se debe identificar cómo el producto ha de ser utilizado por los
stakeholders y las expectativas deben quedar claras para que se pueda medir/validar el
cumplimiento del sistema al final del proyecto.
Los Stakeholders son personas, entidades u otros sistemas que se ven afectadas por, o son de
alguna forma responsable del resultado de un proyecto. Estos pueden ser clasificados cómo
activos los cuales hacen parte activa del sistema como los operadores, diseñadores, entre otros. La
contraparte son los actores pasivos como un gobierno que define estándares, protocolos,
procedimientos o regulaciones que pueden afectar el éxito del proyecto. Ejemplos de los
diferentes Stakeholders están resumidos en la tabla mostrada a continuación:
Tipo Stakeholders Expectativas
Cliente Calidad del producto, entrega a tiempo, buen precio, soporte

técnico.
Vendedor Requerimientos bien definidos.
Activos Equipo Técnico Objetivos claros, seguridad en el trabajo, trabajo en equipo.
Organizaciones funcionales Prototipos disponibles para pruebas, requerimientos de

(pruebas) comportamientos claros.
Subcontratación Cumplimiento de pago, correcta integración con el proyecto.
Directivas de la organización Objetivos internos cumplidos (costo, cronograma), cumplimiento de

Pasivos las políticas y procedimientos empresariales.
Estado Los productos no deben contaminar el medio ambiente.
Tabla 2. Ejemplos de Stakeholders y las expectativas que tienen cada uno de estos.
Entre las buenas prácticas del Handbook de la NASA está la utilización de un ConOps (Concepto de
Operaciones). El objetivo de este es capturar las expectativas de los stakeholders. Este ayuda a
definir las expectativas, formar requerimientos y desarrollar la arquitectura de un proyecto.
Quién:
¿Quiénes son los
stakeholders
involucrados en el
sistema?
Cómo: Por qué:
¿Qué recursos se ¿Qué le hace falta a
necesitan para su organización que
diseñar y construir el sistema le
el sistema? proporcionará?
Concepto de
operaciones
Cuál:
Donde:
¿Cuáles son los
¿Cuáles son las
elementos
locaciones
conocidos y las
geográficas y físicas
capacidades del
del sistema?
sistema?
Cuándo:
¿Cuál es la
secuencia de
tiempo de las
actividades que se
desarrollaran?
Figura 7. Preguntas que rigen un ConOps. [El autor]
Como ejemplo de un ConOps se muestra uno desarrollado por la NASA para un viaje a la luna en la
diapositiva 11. También se muestra una línea de tiempo asociada a este ConOps donde se puede
ver las tareas realizadas por cada uno de los componentes que conforman el sistema cuyo objetivo
final es llevar y regresar con vida a los tripulantes de la misión a la luna. Éste es uno de los varios
objetivos que tiene este tipo de misión, otros son expuestos en la diapositiva siguiente.
Se propone realizar el siguiente ejercicio en clase, con el fin de mirar si a los estudiantes les quedo
el concepto claro y además para que se den cuenta que al darle la potestad a los stakeholders de
definir los requerimientos se está perdiendo autonomía en el diseño del proyecto.
¿Cómo podemos identificar qué es lo que realmente quieren los stakeholders?
¿Cómo prevenimos que los stakeholders diseñen el sistema?
En la diapositiva 15 se ven las “buenas prácticas” de la NASA. Se le debe explicar al estudiante de

donde provienen los “inputs” de esta etapa del proyecto, como ésta debe ser llevada a cabo y los
“outputs” que van dirigidos hacia las siguientes etapas del desarrollo.
También se debe hacer énfasis en la relación de los procesos del diseño de sistemas que se ve en
la diapositiva 17 y en la Figura 3, ya que al completar exitosamente esta etapa es poco probable
que haya que volver a empezar con el proyecto por una mala definición de los objetivos.
El artículo sobre el cual los estudiantes deben realizar la sesión complementaria es “Using
Stakeholder Value Analysis to Build Exploration Sustainability” [Rebentisch] que explica cómo
gracias a la definición correcta de los Stakeholders y del valor que puede llegar a tener un
proyecto sea viable volver a enviar hombres a la Luna y a Marte.
7.4 Clase 3, Definición de requerimientos

Las diapositivas sugeridas se muestran en el anexo D. El objetivo principal de esta sesión es darles
a los estudiantes herramientas para que a partir de la definición realizada de los Stakeholders se
pueda entonces definir los requerimientos que el sistema debe cumplir.
Los requerimientos describen las funciones necesarias y características del sistema que se debe
crear, diseñar, implementar y operar. El fin de esto es poder medir el desempeño, realizar un
cronograma de desarrollo y medir los costos aproximados en los que se puede incurrir.
En la diapositiva 4 se muestra un gráfico donde se presenta el aumento de la cantidad de

requerimientos que puede tener un sistema a medida que han pasado los años, desde 1900 al día
de hoy. Es muy importante la definición correcta de estos, ya que si no se realiza correctamente
pueden quedar Stakeholders insatisfechos.
Los requerimientos técnicos se organizan jerárquicamente, primero los requerimientos de alto

nivel se enfocan en lo que se debería lograr y cómo lograrlo. Segundo, los requerimientos de bajo
nivel donde se define cada elemento de hardware y software, cuál es su función y que objetivos
deben cumplir. A continuación se muestra la sintaxis de cómo se deben redactar los diferentes
elementos de los requerimientos.
Debe •Requerimientos
Hecho •Declaración de propósito
Debería •Objetivo
Diagrama 1.Define la sintaxis que deben llevar los requerimientos, objetivos y propósitos de un sistema . [El autor]
Los requerimientos siempre son redactados con “debe”. El sistema debe realizar X función. Los
objetivos con “deberían”. El sistema debería facilitar X resultado. El propósito del sistema debe ser
redactado con “hace” o “realiza”. El sistema hace X función. Estas definiciones buscan transformar
las expectativas (input) de los Stakeholders a requerimientos técnicos únicos, cuantitativos y
medibles (outputs).
Este proceso es extremadamente importante ya que se establece un acuerdo entre los

Stakeholders y los desarrolladores sobre qué debe hacer el producto. Cuando este proceso se
realiza correctamente se reduce el uso de recursos innecesarios. Cuando hay requerimientos mal
definidos o incompletos suele darse el caso que el proyecto debe regresar a sus etapas iniciales
para definir un objetivo claro. Una ventaja importante es que esto obliga a los Stakeholders a
considerar rigurosamente todos los requerimientos antes del diseño. Una vez definidos se debe
hacer una revisión exhaustiva que puede permitir encontrar omisiones, confusiones e
inconsistencias en una etapa temprana del ciclo de desarrollo. En la diapositiva 9 se muestran
otras razones por las cuales este proceso es importante las cuales se explican por si solas.
A continuación de esto se vuelve a mostrar la Figura 3 con el objetivo de mostrarle a los

estudiantes en que etapa del desarrollo del proyecto se está al realizar esta definición.
Los principales tipos de requerimientos son los funcionales, de desempeño, de restricciones, de

interfaz y ambientales. En la diapositiva 11 se muestran ejemplos específicos sobre el controlador
de propulsión del trasbordador de la NASA.
Para aceptar los requerimientos definidos se debe tener en cuenta que solo existe un “debe” por
cada requerimiento. Las características para cada requerimiento deben ser claras, consistentes,
entendibles y legibles. También deben ser factibles, como por ejemplo se pueden satisfacer dadas
las limitantes físicas, del estado del arte y de costo. En la diapositiva 12 se exponen los
requerimientos de aceptación mas importantes entre los que están los mencionados
anteriormente. Es muy importante dejar este concepto claro ya que después de definir los
requerimientos se empieza a desarrollar el proyecto y volver a esta etapa aumenta los costos
significativamente.
En la siguiente diapositiva se muestra un diagrama de flujo que muestra la separación entre el

cliente y la organización que va a desarrollar la solución. Se ve como de las restricciones impuestas
sale un gran diagrama donde se empieza a descomponer la idea del cliente en subsistemas y
recursos. Teniendo en cuenta los supuestos que conlleva este proyecto.
Los requerimientos deberían tener asociados una medida métrica y un valor objetivo. Los valores
pueden se continuos (10 m/s), discretos (intensidad lumínica alta), cualitativos (de buen sabor).
Una mayor cuantificación ayuda a clarificar la intención y garantizar el éxito. Los requerimientos
deben ser medibles. Para requerimientos funcionales, la métrica debe ser directamente
relacionada al proceso externo entregado.
La formulación debe ser marginal, absoluta o probabilística:

= X% de mejora en ________
= X valor de _______
= X valor de _______ con una nivel de confianza del 95%
Tradicionalmente la métrica se evalúa en la relación beneficio/desempeño (con el costo,

programación y riesgo evaluadas después). En las practicas actuales la métrica se evalúa en la
relación beneficio/desempeño y costo (con la programación y riesgo evaluadas después). Lo ideal
sería donde la métrica se evaluara en la relación beneficio/desempeño, el costo y el riesgo. En la
actualidad es muy importante que el proyecto cumpla con ciertos criterios de desempeño sin
superar un costo. El riesgo empieza a jugar un papel importante en nuestros tiempos donde
estamos regidos por un mercado de valores cambiante, donde el riesgo de cancelación del
proyecto es muy alto, donde los distribuidores tienen asociado una riesgo por el país donde se
ensamblan los elementos. Estos factores deben ser tomados en cuenta al hacer una evaluación de
un proyecto.
Se propone el siguiente ejercicio en clase para asegurarse que los estudiantes hayan comprendido
como se debe redactar un requerimiento. Para esto se les pide a los estudiantes que definan los
requerimientos de alguno de los siguientes elementos:
Avión, Tren, Lámpara, Lavadora, Teclado, USB Key, Esfero, Reloj
Se debe realizar un seguimiento al cumplimiento de los requerimientos, por esto la gráfica de la

diapositiva 1. Es imposible que se cumplan exactamente siguiendo el cronograma establecido, por
esto la gráfica muestra un rango de trabajo sobre el cual estos se pueden mover.
Cualitativa
Medidas de efectividad
Se obtienen de las expectativas de los stakeholders. Es el punto
más importante para determinar el éxito del sistema
Cuantitativa
Medidas de desempeño Combinación de requerimientos funcionales y de desempeño.

Medidas de combinación de requerimientos. Medidas que
aseguren el cumplimiento del MDE.
Calificador
Medidas de desempeño
técnico Atributo de desempeño o técnico medible. Con esto se puede
establecer y monitorear el progreso.
Tabla 3.Se define que es MOE, MOP y TPM.
Diagrama 2.Muestra la relación entre las MOE, MOP y el TPM. [El autor]
Después de esta explicación se brinda un ejemplo de cómo aplicar este diagrama en la diapositiva
19. Éste muestra las medidas definidas para el propulsor de un satélite en órbita.
Durante la asignación de requerimientos es importante descomponer los requerimientos del

sistema a los niveles más bajos de diseño donde se puedan ver todas las funciones de bajo nivel
que deben ser desempeñadas para satisfacer el requerimiento. A raíz de esta descomposición se
crea una arquitectura de sub-componentes que proveen esas funciones. Por lo que se le debe
asignar una medida de desempeño a cada función de bajo nivel. También se debe especificar los
requerimientos de interface a cada sub-sistema. Con esto definido se debe asegurar que el
conjunto de subsistemas al trabajar unidos desempeñen de manera correcta los requerimientos
del sistema completo.
Es importante mostrar el proceso de asignación de requerimientos por esto se presenta la

diapositiva 22 donde se puede ver gráficamente como funciona el proceso mencionado en el
párrafo anterior.
Uno de los principales problemas de hacer esta descomposición consiste en que es difícil
descomponer los requerimientos a niveles más bajos sin realizar una solución como tal.
Entonces se llega a una Implementación “Cómo” en vez de requerimientos “Qué”. Por ejemplo se
llega a que se debe utilizar un computador para hacer X cálculos para entender X funcionamiento
en vez de llegar a definir que se necesita crear un modelo que debe ser procesado por medio de
simulaciones o cálculos para entender X funcionamiento Esto limita el diseño y puede generar
problemas en un futuro por una falta de compresión de los objetivos del proyecto. Otros
problemas comunes son mencionados en la diapositiva 23 y finalmente se menciona cómo cada
requerimiento debe ser verificado.
El artículo sobre el que los estudiantes deben realizar la sesión complementaria es “The House of
Quality” [Hauser]. Este habla sobre el trabajo en equipo en la etapa de diseño y la necesidad que
se tiene de que los grupos de diferentes disciplinas sean capaces de comunicarse entre ellos. Es
muy útil para evitar que los estudiantes se cierren al área técnica del desarrollo de un proyecto y
entiendan la gran cantidad de elementos e interacciones que hay entre personas con áreas de
trabajo muy diferentes.
7.5 Clase 4, Arquitectura del sistema

Las diapositivas sugeridas se muestran en el anexo E. El objetivo principal de esta sesión es que los
estudiantes comprendan que es la arquitectura de un sistema y como debe ser manejada.
En la diapositiva 3 se expone una gráfica de complejidad, creatividad y ambigüedad que busca

mostrar la variación de estas a lo largo del tiempo. La complejidad siempre aumenta con respecto
a las etapas del proyecto y la creatividad y ambigüedad se van perdiendo a medida que el
proyecto queda bien estructurado y definido.
Como definición la arquitectura consiste en la implementación de un concepto y la

asignación de funciones (procesos) a elementos (objetos) y definición de las
interfaces estructurales entre los objetos. Consiste de una función que es relacionado
por un concepto a la forma.
La definición de forma se descompone en los elementos mostrados en la diapositiva 7 donde se

dan varias definiciones sueltas de esta, pero la principal establece que es lo que realmente ES el
sistema.
La forma de un sistema simple generalmente consta de 5 a 9 partes. En el nivel -1 del diagrama 3

se encuentra partes reales que conforman un sistema que desempeña una función. Estas no
pueden ser desarmadas sin perder funcionalidad o integridad. Con este diagrama nos vamos un
paso atrás del primer diagrama Top-Down visto, ya que se llega hasta las partes que componen el
sistema, sin las cuales este no funcionaria. Estas partes dan la forma del sistema.
Nivel 0 Sistema
Nivel -1 Parte 1 Parte 2 ……
Diagrama 3. Paso último del diagrama Top-Down llegando hasta las partes del sistema. [El autor]
La función de un sistema consiste de las actividades, operaciones y transformaciones que causan,

crean o contribuyen al cumplimiento de los requerimientos. Es lo que el sistema eventualmente
hace, las actividades y transformaciones que emergen como resultado de las sub-funciones. Estas
son las principales definiciones de la función, las demás pueden ser vistas en la diapositiva 9. Con
estas dos definiciones se busca que el estudiante entienda que el proyecto o producto no es solo
eso. Esto conlleva una gran cantidad de subsistemas que siguen una arquitectura de
transformación desde la función hasta la forma.
Diagrama 4.Secuencia de una arquitectura. [El autor]
Este es el ciclo que se sigue al diseñar una arquitectura. Existen dos aproximaciones a esta. La
primera es el “Reverse Engineering” donde desde una forma definida se busca obtener la función y
los objetivos de esta. Mientras que en el diseño conceptual se conocen las funciones con las que
se busca crear la forma para llegar a una función. Es un ciclo por que la constante evolución de un
proyecto conlleva a partir de uno de estos dos puntos para completar una nueva solución.
En la diapositiva 12 se hace una definición del concepto. Este principalmente es el resultado físico,
palpable de la implementación de la función para lograr la forma.
Como ejercicio para los estudiantes se les pide que describan los conceptos de los siguientes
elementos con el objetivo de mirar si les quedo clara la definición de este. Carro, avión, satélite de
comunicación, pito. Como retroalimentación se expone el concepto de un pito.
Para la siguiente parte se utiliza un refrigerador como ejemplo para la implementación de esta
metodología.
Diagrama 4.Valor de un sistema. [El autor]
En este caso el beneficiario es la persona que consume los alimentos. Este tiene la necesidad de
prolongar la vida de aquellos productos perecederos. La entrega de procesos primarios es que por
medio de un operando como el refrigerador se logre cumplir con la conservación de la comida.
Cumpliendo así el objetivo de el producto.
El valor es obtenido cuando el principal proceso externo actúa en el operando, de tal manera que
las necesidades del beneficiario se satisfacen.
Diagrama 4. Flujo del resultado de utilizar un producto. [El autor]
Identificación de objetivos:
 Comience examinando el operando asociado con el valor

 Identifique el atributo del operando cuyo cambio está asociado con el valor
 Defina la transformación del atributo asociado con el valor.
Usando el ejemplo del refrigerador se obtiene el siguiente ejemplo

Diagrama 5.Flujo del resultado de utilizar un refrigerador. [El autor]
A continuación se realiza un estudio del manejo de la complejidad utilizando un ejemplo genérico

que se puede ver en la diapositiva 18. Esto con el objetivo de entender que a mayor tamaño del
producto mayor va a ser su complejidad. La idea es mantener las cosas simples.
A continuación se busca exponer las diferencias entre el diseño y la arquitectura. La arquitectura

selecciona el concepto, descomposición y realiza el cambio de la forma a la función. La
arquitectura establece el vector de variables de diseño y parámetros operacionales. El diseño
selecciona los valores del vector de parámetros.
En las siguientes diapositivas se expone los diferentes elementos de la generación y selección de

un concepto. Esto se expone claramente con los elementos que rodean a un sistema operativo. En
la generación del concepto se busca sistemas que realicen la función que se necesita mientras que
en la selección de este se busca entre todas las opciones cual es la que mas valor le genera al
proyecto.
A continuación se definen los roles de un arquitecto. Este desempeña la función con el nivel más
alto y abstracto en el desarrollo de un producto. Es el motor de la fase conceptual, por lo que este:
Define las funciones y los límites

Crea el concepto
Asigna la funcionalidad y define las interfaces
Es un especialista en simplificar la complejidad, resolver ambigüedades y concentrarse en la

creatividad. Lo realiza pensando acerca de todos los otros atributos de un buen producto. Esta es
un área importante en la que los estudiantes deben enfocarse ya que como se ve en la definición
es el verdadero creador del proyecto, el que más experiencia debe tener.
La siguiente etapa de esta sesión es la descomposición lógica. Esta se utiliza para mejorar el
entendimiento de requerimientos técnicos definidos y la relación entre estos (funcionales,
temporales, comportamiento).
Transforma el conjunto de requerimientos técnicos en modelos lógicos. Pase de una simple

definición de “debe” a un bloque de elementos que debe tener el proyecto. Se sugiere mostrar de
nuevo la Figura 3 como en la diapositiva 27 para ver en que lugar estamos del proceso de diseño.
La descomposición lógica es muy importante ya que es el proceso sistemático de identificar,

describir y relacionar funciones que un sistema debe desempeñar para cumplir sus objetivos.
Los pasos claves al desempeñar el análisis funcional son traducir los requerimientos de alto-nivel a
funciones que deben ser desempeñadas por el sistema para cumplir los requerimientos.
Descomponer y asignar las funciones a niveles bajos de la estructura del producto. Identificar y
describir relaciones funcionales y de los subsistemas.
Este proceso está compuesto por los modelos de formación, la asignación de los requerimientos a
estos y la utilización de resultados de los procesos de análisis para desarrollar los requerimientos
técnicos derivados. La estructura de diseño resultante de esta descomposición divide el sistema en
grupos lógicos de elementos que facilitan el cambio, logran transparencia y mitigan el riesgo de
volverse obsoleto. Usa rigurosas definiciones de interfaces y define las interfaces claves en un
sistema utilizando estándares ampliamente soportados y abiertos como USB (Universal Serial Bus).
Que es un sistema que maneja cuatro interfaces eléctricas simples. Alimentación positiva y
negativa, tierra y datos. Es un elemento que por un solo “cable” transmite la información
necesaria para conectar dos elementos. Por este “cable” se transmiten datos encriptados de
forma universal que cualquier dispositivo entiende, facilitando así su implementación a nivel
global.
En la diapositiva 29 se exponen las características del desarrollo del modelo de la arquitectura del
sistema. Antes de empezar a trabajar se debe definir como se va a construir este. En esta
diapositiva se exponen las características que se deben tener en cuenta al realizar este proceso. En
las siguientes diapositivas se exponen las diferentes formas de descomponer los requerimientos
técnicos y que herramientas utilizar para simular este sistema.
En la siguiente diapositiva se muestra un diagrama de flujo de bloques funcionales. Esta es la tarea

del arquitecto. Allí se deja claro como se va a desarrollar el proyecto y las etapas de este. El
ejemplo muestra los bloques del sistema que pone en orbita un satélite. Se muestran además
ejemplos modelos de descomposición como diagramas de estado y líneas de tiempo.
Se debe hacer un seguimiento de las tareas realizadas y estos se exponen en la diapositiva 34, son
ejemplos muy simples de herramientas utilizadas comúnmente en programas como Microsoft
Project.
El artículo que debe ser presentado por los estudiantes es “THE INFLUENCE OF ARCHITECTURE IN
ENGINEERING SYSTEMS” [Crawley] en este se resumen los roles y la importancia que tienen los
arquitectos en el desarrollo de proyectos de la Ingeniería Sistémica.
7.6 Clase 5, Selección de conceptos

Las diapositivas sugeridas se muestran en el anexo F. El objetivo principal de esta sesión es
entender como se debe seleccionar uno de todos los conceptos creados con la metodología de la
sesión anterior. Para esto se utilizan herramientas de teoría de la decisión.
Para poder tomar una decisión se tienen que tener en cuenta todas las alternativas, criterios y
preferencias del decisor. Por esto es muy complicado llegar a una solución acertada. En la
diapositiva 4 se exponen las dificultades que se puede llegar a tener al intentar tomar una
decisión, estas incluyen la posibilidad que dos de los conceptos estén relacionados y que solo uno
pueda ser escogido
Diagrama 6.Secuencia de toma de decisiones. [El autor]
Existen varias herramientas de toma de decisiones, pero en esta presentación se exponen los
pasos de la matriz Pugh (Diapositiva 6) con la cual se busca por medio de una asignación de los
signos +,0 y - darle una puntuación a las alternativas por medio de los criterios definidos. También
se puede utilizar un análisis de utilidad.
Este tipo de herramientas sirven para estructurar y representar un procedimiento de evaluación.

En la diapositiva 9 se presenta una comparación de para que sirve y para que no esta metodología.
Lo más importante es que se debe dejar claro que esto no implica una toma de decisión, es
simplemente una guía para filtrar opciones que son realmente inviables. En la toma de decisiones
debe haber un facilitador cuyas funciones se exponen en la diapositiva 10.
Se explora al final de la presentación la teoría de la utilidad que es la medida de la felicidad relativa

o satisfacción obtenida al consumir una serie de bienes y servicios. Para hacer este análisis en un
proyecto se genera un mapa de los criterios en utilidades dimensionales en un intervalo de [0,1] y
combina las utilidades generadas por criterios en una utilidad resultante.
La utilidad total es la ponderación de las sumas parciales:
Donde ’s se determina en las encuestas y es el factor de proporción dependiente identificar

atributos/objetivos críticos, desarrollar una encuesta, procesar información obtenida, desarrollar
la funciona agregada de utilidad y analizar resultados. Con estos resultados se puede disminuir el
número de opciones de los conceptos a ser escogidos.
El artículo que debe ser presentado por los estudiantes es “Application of the Systems Engineering
Modeling in the early phases of a Complex System Project” [Bone] en este se expone como todas
las herramientas vistas se utilizan para desarrollar un proyecto. Se descompone cada uno de los
elementos vistos en este curso y muestra un ejemplo claro de la vida real donde se aplica esta
metodología. También hace un análisis de que podría suceder si no se siguen correctamente esta
metodología.
7.7 Clase 6, Definición del diseño

Las diapositivas sugeridas se muestran en el anexo G. El objetivo principal de esta sesión es utilizar
los resultados de los procesos anteriores para tener un sistema estructurado y definir como va a
desarrollarse el sistema.
En las primeras diapositivas se busca exponer que se debe incluir en la definición de la solución de
diseño. En las diapositivas se exponen los principales elementos como por ejemplo la definición
completa de las alternativas que resultan de la selección de conceptos de la sesión anterior.
Se debe analizar cada alternativa para poder seleccionar la preferida, una vez sea seleccionada una
alternativa, el proceso de solución de diseño será usado para generar productos finales con los
lineamientos de la jerarquía de la estructura del sistema, el resultado será usado para hacer una
verificación del producto.
Lo modelación y simulación permiten entender y optimizar el desempeño del sistema utilizando

muchas combinaciones y permutaciones. Una ventaja enrome es probar de forma efectiva en al
inicio de la etapa de diseño el comportamiento de un avión por medio de simulaciones generando
datos sin los costosos prototipos.
Entre los beneficios se encuentran la posibilidad de mirar si se cumple con las expectativas de los
stakeholders. Cumple los requerimientos de costo/programación y desempeño o si opera como
fue especificado en el ConOps.
El diseño para la optimización multidisciplinaria es definido como una metodología en evolución

para diseño de sistemas de ingeniería que incluyen una gran cantidad de partes y subsistemas
interactuando. Este está en constante evolución e incluye una gran cantidad de disciplinas.
Figura 8.Diferentes perspectivas del desarrollo de una aeronave. [Ryschkewitsch, Improving the capability to
Engineer Complex Systems. Pág. 5]
Los diseños de hoy en día tienen limitaciones muy exigentes, por ejemplo el costo o el tiempo de
vida. En la NASA los sistemas espaciales viejos deben ser remplazados constantemente. El medio
ambiente ha tomado una gran importancia recientemente así que la eficiencia del combustible se
ha vuelto un factor importante en los diseños (mínimo peso, motores con máxima eficiencia). Más
allá de las limitaciones, estos sistemas necesitan un amplio grupo de personas con una gran
cantidad de experticias divididas en grupos geográficamente separados. Entonces cada grupo
prefiere optimizar en su propia experticia, el problema es que sus dominios están relacionas con
los otros grupos a través del flujo de datos.
A continuación se procede a discutir los modelos de simulación. Se muestran ejemplos del

desarrollo óptimo de la aerodinámica de una nave utilizando un modelo de optimización que
variando los factores de peso, carga aerodinámica y uso de combustible llegan a una solución
óptima de la estructura que debería tener el exterior de un avión.
Como complemento de la clase se deben ver los videos Systems Enginnering y When the Canvas is
Blank del profesor Lee. Aquí se discute en gran parte como desarrollar un proyecto desde cero y
que herramientas a usar para el desarrollo de sistemas simulados. También explica por qué no
creer totalmente en los resultados de las simulaciones con ejemplos muy claros. Estos videos se
encuentran en el siguiente link http://spacese.spacegrant.org/index.php?page=videos
7.8 Clase 7, Ingeniería Sistémica Humana

Las diapositivas sugeridas se muestran en el anexo H. El objetivo principal de esta sesión es
entender la importancia del factor humano en la toma de decisiones en los proyectos. Además es
importante entender que la automatización no siempre es la solución y se dan ejemplos de
situaciones en las que el hombre es más importante que la máquina.
En los sistemas tradicionales los requerimientos operacionales guían las medidas del desempeño
técnico que a su vez guían los requerimientos de los factores humanos. Este es un proceso lineal
según los sistemas tradicionales donde en ningún momento se incluye el factor humano.
Diagrama 7.Diagrama de desarrollo de un proyecto en un sistema tradicional. [El autor]
Se expone la historia de la isla de las tres millas donde por confiar en los elementos automatizados
de la planta nuclear se obtuvo un acontecimiento desastroso para la naturaleza y para el proyecto
energético americano.
Figura 9. La espiral del modelo de proceso de la ingeniería sistémica. [Ryschkewitsch, The Art and Science of
System Engineering. Pág. 20]
El concepto de espiral de este proceso es un cambio en la estructura de pensamiento, ya que

siempre se tienen presente los ciclos. Este planteamiento propone utilizar las bases que se van
dejando mientras se avanza en el proyecto para desarrollar el sistema de forma evolutiva.
Los Stakeholders usualmente no tiene muy claro como debe ser sus sistema, si evolutivo o
revolucionario. No saben si modificar un proyecto antiguo o crear uno desde cero. Por esta razón
se deben realizar los elementos expuestos en la diapositiva 8, como encuestas y entrevistas para
identificar aspectos claves del proyecto y para establecer como trabajar en conjunto con ellos.
Utilizando estas herramientas también se puede empezar a asignar las funciones respectivas ya
que se puede ver quién es más apto para realizar X función. Si es mejor que lo realice un humano
o simplemente automatizar el sistema. Otra opción viable es un sistema hibrido.
Tabla 4. Lista de Fit. [El autor]
Esta lista es muy útil para hacer un análisis sobre las ventajas que puede tener un sistema sobre el
otro en determinado atributo. Con esto en cuenta se puede tomar una decisión utilizando la
gráfica de la diapositiva 12.
Se debe hacer un análisis de tareas utilizando herramientas como determinar qué debe lograr un
operador para cumplir el objetivo de una misión. Este contiene acciones y/o procesos cognitivos,
diagramas de flujo, secuencias operacionales, análisis de tareas criticas para evaluar esta labor.
Después de esto, en la diapositiva 15 se expone el análisis de tareas cognitivas para entender los
límites de la capacidad humana y su capacidad para realizar una tarea compleja que es necesaria
para el éxito del proyecto.
El artículo que debe ser presentado por los estudiantes es “NASA’s System Behind the System:
Developing Systems Engineers” [Williams] en este se hace un análisis de la importancia del
desarrollo humano de los ingenieros sistémicos. Da claros ejemplos de como un ser humano es
vital para el éxito de cualquier proyecto y la integridad mental que este debe tener para tomar las
decisiones correctas.
7.9 Clase 8, Integración del sistema

Las diapositivas sugeridas se muestran en el anexo I. El objetivo principal de esta sesión es mostrar
la importancia que tiene una clara definición de interfaces para que en el momento de hacer la
unión de los diferentes elementos del proyecto no ocurran calamidades y que estos puedan
acoplarse de forma correcta.
EL problema que suelen tener los proyectos de gran tamaño es que se enfoca un gran esfuerzo en
el diseño de partes individuales de un sistema (Funcionalidad, tolerancia, tiempo entre fallos) y no
se les da el nivel de importancia equivalente. Usualmente esto se vuelve el punto débil del
sistema. Como fue mencionado antes, los diferentes elementos de un sistema generalmente están
construidos en diferentes lugares geográficos y por esto se necesita una delicada definición de
interfaces. Se muestra el ejemplo del accidente Ariane 501 donde la interface entre dos sistemas
causo que el computador de abordo diera instrucciones erróneas de la dirección, resultando en la
explosión en el aire del cohete.
Diagrama 8.Tipos de interfaces. [El autor]

El manejo de interfaces es utilizado para establecer y usar un manejo formal de las interfaces para
asistir en el control del desarrollo del producto del sistema. Esto específicamente para ocasiones
en que los grupos de trabajo están divididos en diferentes regiones.
Los sistemas complejos tienen una gran cantidad de interfaces diferentes. Las interfaces simples
reducen la complejidad con lo que se puede reducir el riesgo de fallo del sistema. La verificación
de estas es vital para asegurar la compatibilidad y correcta operación del sistema.
Una interface es la característica funcional y física requerida en una frontera común entre dos o
más sistemas, productos o subsistemas. Las más comunes son las físicas, eléctricas, electrónicas,
mecánicas, hidráulicas, neumáticas y ópticas.
En la diapositiva 10 se exponen las diferentes herramientas de documentación que ayudan al

establecimiento de las diferentes interfaces del sistema. Esta documentación debe ser
desarrollada antes de continuar en el proyecto para que así se tenga un soporte bibliográfico de
los estándares utilizados por los diferentes grupos de trabajo del proyecto.
La integración del sistema es el momento de ensamble de las partes del sistema como el físico, por
ejemplo la conexión de tuberías, mangueras. La secuencia de ensamble debe ser definida con
anterioridad para evitar contratiempos de alimentación o de partes que no se ajustan al sistema.
En los sistemas más complejos sólo salen a flote algunos inconvenientes durante la integración del
sistema.
Como complemento de esta clase se recomienda ver la parte 5 “spider” de “From the Earth to the
Moon” de HBO. Donde se muestra todo el proceso de diseño del dispositivo Spider, que es la
pequeña aeronave con la que Neil Armstrong y Buzz Aldrin lograron pisar la luna por primera vez.
Es útil para este tema ya que se muestra la parte de integración del sistema y los diferentes grupos
que participaron en la creación de este.
7.10 Clase 9, Verificación y Validación

Las diapositivas sugeridas se muestran en el anexo J. El objetivo principal de esta sesión es
diferenciar la verificación de la validación. Esto es muy importante para analizar si el resultado
obtenido después del desarrollo del proyecto es el acertado y si cumple con la solución a
cabalidad.
La verificación ocurre durante el desarrollo del proyecto. Por medio de este se puede revisar si los
requerimientos se han cumplido, esta se realiza típicamente en el laboratorio y está enfocado en
los subsistemas o componentes de la solución. La validación ocurre durante o después de la
integración y se realiza en un ambiente real o simulado. Aquí se revisan si los intereses del
stakeholder se han cumplido y está principalmente enfocado en el sistema completo. En la

diapositiva 3 se exponen estas diferencias y se exponen dos preguntas con las que se busca que
quede clara la diferencia entre los dos. En la verificación se examina si el producto final fue bien
realizado y en la validación se pregunta si el producto final fue el correcto.
Después de esto se exponen las buenas prácticas dadas por la NASA para estas etapas y los
diferentes tipos de pruebas para responder a las preguntas de verificación y validación.
Un lugar donde se pueden realizar pruebas de verificación y validación es la cámara de la

Universidad de los Andes que es utilizada para probar el funcionamiento de sistemas de
comunicaciones como las antenas. En estas se puede analizar si una antena esta transmitiendo en
las frecuencias deseadas o si absorbe ruido lo cual afecta el correcto funcionamiento del
dispositivo.
En la diapositiva 9 se exponen los problemas que vienen con esta etapa de diseño, donde el
principal es el excesivo costo de esta pruebas. Entre otras preocupaciones que surgen es si se
deben creer en las especificaciones de los fabricantes o si se debe probar componente a
componente. Un problema que suele ocurrir es que las fallas frecuentemente ocurren fuera de los
escenarios de prueba, aunque esto no significa que se deban dejar de hacer estas pruebas ya que
varias fallas pueden ser encontradas con esta metodología.
A continuación se procede a analizar el riesgo que se toma al desarrollar un proyecto. El riesgo se

define como la probabilidad que en un programa o proyecto ocurra un evento no deseado. Este
evento puede venir de fuentes técnicas o programáticas (problema de salud, superación de
presupuesto, impacto ambiental, la incapacidad de cumplir un objetico científico o tecnológico).
En las diapositivas siguientes se continúa definiendo que es el riesgo, pero el concepto clave es
entender que todo proyecto acarrea un riesgo y que se debe buscar minimizarlo para lograr llegar
a la solución final sin contratiempos. En la diapositiva 14 se pueden ver las diferentes capaz de
riesgo donde los riesgos mas importantes son aquellos que ocurren dentro del proyecto, como los
problemas técnicos o problemas en el software.
Diagrama 8.Interacción del riesgo. [El autor]
El riesgo como se puede ver en el diagrama 8 se compone de varios factores. Entre estos esta el
riesgo de costo, el cual por medio del presupuesto esta conectado con los otros elementos que
pueden afectar el resultado del proyecto. Por ejemplo si hay problemas técnicos el riesgo de costo
aumenta significativamente ya que los dispositivos que están fallando deben ser remplazados y
esto implica un costo importante para el proyecto.
Diagrama 9.Manejo del riesgo. [El autor]
Esta grafica muestra como se debe manejar el riesgo. La comunicación es el factor más importante
para minimizarlo, ya que si hay mal entendidos los riesgos aumentan significativamente. Se debe
hacer un plan de riesgo donde se analice, identifique, siga, planee y controle el riesgo. Un
documento donde los Stakeholders puedan consultar este tipo de riesgo es muy importante.
Existen herramientas muy útiles como la matriz de riesgo mostrada en las diapositivas 18 y 19
donde se hace un análisis de la incertidumbre y las consecuencias que vienen al tomar una
decisión sobre el proyecto. Se pueden ver los valores de probabilidad y del impacto sobre el
proyecto con un ejemplo sencillo de como se utiliza.
El artículo que debe ser presentado por los estudiantes es “The Role of Independent Verification
and Validation” [Zelkowitz]. Allí se expone la importancia de realizar estas dos “preguntas” para
entender si el proyecto cumple con las expectativas. Muestra también la complejidad de mantener
un sistema integrado funcionando y como se maneja un proyecto con una proyección a un plazo
muy largo (40 años).
7.11 Clase 10, Seguridad de los sistemas

Las diapositivas sugeridas se muestran en el anexo K. El objetivo de esta sesión es mostrar la
importancia de la seguridad en los sistemas. También es importante dar a entender que pese a
que se haga un esfuerzo muy grande en hacer un sistema a prueba de fallos, siempre existe la
posibilidad de que ocurra un accidente.
En la diapositiva 2 se mencionan los tipos principales de accidentes que pueden ocurrir durante el
desarrollo de un proyecto. Entre estos se destacan aquellos por fallas de componentes o por un
error en la interacción entres estos. Es importante mencionar los niveles de complejidad que se
exponen en la siguiente diapositiva, ya que hay un punto en que un proyecto se vuelve
inmanejable. Para esto se debe planear con anticipación y se debe vigilar el proceso a medida que
va creciendo.
A continuación se debe exponer sobre la diferencia entre seguridad y confiabilidad. Estas dos son
diferentes ya que por ejemplo hacer que algunos componentes sean confiables no tiene ningún
efecto en las fallas por la interacción entre estos. Usualmente estos ocurren por requerimientos
“defectuosos” o mal definidos. Cuando se tienen supuestos incompletos acerca de la operación de
sistemas controlados se puede convertir en una falla del sistema. A veces ocurre que los diferentes
estados controlados por el sistema y condiciones del entorno no han sido tomados en cuenta,
entonces cuando ocurre una situación atípica el sistema se puede comportar de una manera no
esperada.
El software puede ser altamente confiable y correcto, pero puede seguir siendo inseguro. Los
requerimientos usualmente no especifican un comportamiento particular requerido para la
seguridad del sistema, se asume que no hay inconvenientes con este. Cuando esto sucede, el
software tiene un comportamiento no esperado (e inseguro) que supera lo especificado en los
requerimientos. Para hardware se pueden probar exhaustivamente los requerimientos y obtener
los errores de diseño, pero sólo podemos probar una pequeña parte del comportamiento
potencial del software. El mundo real es muy diferente al virtual, en las diapositivas 5 y 6 se dan
ejemplos de los cambios que ejerce el software en un proyecto, como la creación de un piloto
automático. También se expone el ejemplo del Mars Polar Lander, donde por un error de
programación los sensores de proximidad de suelo se activan solo a 12 metros de altura. En este
punto fue demasiado tarde para la activación de los sistemas de aterrizaje. Esto sucedió por un
error de concepción del software donde no se les dio prioridad a estos sensores y se perdió un
equipo de millones de dólares. En la diapositiva 10 se exponen que aproximación se pudo haber

tomado para evitar este inconveniente.
Después del tema de seguridad se aborda el tema de causalidad de accidentes. Esta aproximación
permite analizar las fallas como un resultado de múltiples eventos, dando así un espectro amplio
de ver que fue lo que sucedió. En la diapositiva 14 se explican los limites de este análisis entre los
que se encuentran el error humano o un problema de adaptación del software.
En las siguientes diapositivas se expone la metodología STAMP con la cual se busca observar la
seguridad como un problema de control dinámico. En las siguientes diapositivas se explica el
procedimiento para la definición de los posibles problemas
La seguridad es una propiedad emergente en los sistemas. Los accidentes ocurren por la
interacción de los componentes del sistema (humano, físico, social). Que viola las limitaciones en
el comportamiento de la seguridad de componentes y sus interacciones
Las perdidas son el resultado de procesos complejos, no una cadena de eventos. La mayoría de los
accidentes ocurren por una migración hacia estados de alto riesgo.
7.12 Clase 11, Manejo del ciclo de diseño

El diseño se ha enfocado en el desempeño. Para el diseño de aeronaves lo óptimo es un peso
mínimo. A medida que se va logrado esto, el costo crece en importancia. Usualmente el 85% del
costo del ciclo de diseño es asignado al final del diseño preliminar, en el punto en que todavía no
se ha ni siquiera definido las fases concretas del proyecto. El problema radica en que el peso
mínimo ≠ costo mínimo ≠ valor mínimo. ¿Cual es una medida apropiada para medir el valor?
Costo
Desempeño
Diseño
Métrica óptimo
de valor
Retorno
Diagrama 10.Busqueda del diseño óptimo. [El autor]
En las diapositivas siguientes se analizan los retos que conlleva el modelamiento del punto óptimo.
Entre los principales problemas están la dificultad de obtener el retorno o los costos para
proyectos que no generan un ingreso específico como un viaje a la luna. Pero se hace un esfuerzo
para realizar este tipo de análisis separando los costos recurrentes y no recurrentes. Se puede ver
en la diapositiva 11 la asignación aproximada del costo del ciclo de desarrollo de un proyecto. Por
último se expone la teoría de la curva de aprendizaje para el costo de producción, donde se busca
que los estudiantes comprendan que a medida que un operario obtiene experiencia, su
desempeño y tiempo de producción disminuyen drásticamente.
7.13 Tareas
7.13.1 Tarea 1
Stakeholders y requerimientos
1) Describa las fases del diseño de vehículos. Para cada fase, defina los objetivos y describa
los sistemas derivables. Cite estándares relevantes.
Citar fases pre-A, A, B, C, D, E, F
Discutir rrs (revisión requerimientos del sistema), drp (diseño de requerimientos preliminar), rcd
(revisión crítica del diseño) y rar (rango aceptable de riesgo) y que se pide en cada uno de estos. Se
debe citar el handbook de la nasa
15 PUNTOS
2) No todos los presupuestos son financieros. Describa los diferentes presupuestos que se
deben seguir en el diseño de vehículos y que márgenes son asignados
Presupuesto de masa: masa total, matriz de inercia. Presupuesto de poder: potencia máxima vs
promedio, capacidad. Mdt (medidas de desempeño técnico): rango, almacenaje. El presupuesto se
reserva para todo el proyecto, se le retira el 30% en el rrs, 20% en el drp, 10% en el rcd, etc. Lo que
queda se distribuye entre los varios subsistemas por medio de estudios y negociación
15 PUNTOS
3) Describa el rol del diseño de prototipos. Ayuda: diseño de prototipos se refiere al proceso
de desarrollar un modelo (software, hardware) de un vehículo o un subsistema de este. ¿Cómo se
relaciona este con el diseño cascada y el diseño en espiral?
Se utiliza para aprender acerca de interacciones del sistema desconocidas, por ejemplo refinar
requerimientos de bajo nivel basado en resultados experimentales y aumentar el nivel de
confiabilidad del sistema. Entre más prototipos se realicen más se parece al desarrollo en espiral.
Un sistema cascada no construye sistemas de hardware y software para probar únicamente se
realiza después del rcd.
15 PUNTOS
4) Que significa “bidirectional traceability” en el proceso de definición de expectativas?
Cada requerimiento debe venir de la necesidad superior de un stakeholder (ninguno queda suelto)
toda expectativa de un stakeholder debe llevar a la formulación especifica de requerimientos que
lleven a la implementación de estos.
10 PUNTOS
5) Dibujar una red de stakeholders para una misión de una puesta en orbita de el sistema de
transmisión LTE, cuya función es brindar una transmisión de datos de alta velocidad (real 4G) en el
mundo. Mostrar los stakeholders como nodos e identificar los diferentes flujos en la red.
El mapa debe parecer una red que muestra los diferentes flujos de valor. El público recibe datos por
medio de su dispositivo inteligente vía el aire, por medio de sus proveedores de servicio móvil.
Estos proveedores controlan los satélites y el flujo de información que pasa a través de este. Esto es
un contrato con compañías que alquilan la transmisión de datos. Que a su vez han contratado
compañías de desarrollo de satélites y enviados al espacio por medio de entidades
gubernamentales como el congreso de usa.
Los usuarios se benefician por medio de acceso a la información, pagan sus suscripciones, pagan
impuestos y financian las entidades gubernamentales
25 PUNTOS
6) Que es una matriz de verificación de requerimientos?
Apéndice D del handbook de la NASA. Muestra en detalle cómo cada requerimiento se verificará.
20 PUNTOS
7.13.2 Tarea 2
Sistemas
Las actividades de los sistemas deben ser manejadas como un todo minimizando el impacto de la
complejidad. Esto puede incluir trabajar con las interfaces internas y externas para garantizar que
los elementos o componentes del sistema logren la sinergia que lleven a desempeñar el propósito
de este. También se debe enfocar el esfuerzo en asegurarse que los componentes no tengan un
comportamiento peligroso o no deseado. A continuación hay dos sistemas, seleccione uno de
estos y responda las siguientes preguntas:
Airbus A-380
iPad 2
1) Identificar las interfaces externas con las que este sistema de ser compatible. Estas
pueden estar relacionadas con humanos, medio ambiente, mecánicos entre otros.
2) Ilustrar el carácter dinámico de estas interfaces mostrando cómo aquellas que son
externas cambian con el tiempo durante un periodo de operación del sistema. Haga esto
generando una secuencia de esquemáticos. En cada uno las interfaces deben ser apropiadas para
un punto particular en el tiempo.
3) Haga una lista de los subsistemas primarios. Caracteriza cada subsistema. Por ejemplo: un
sistema de generación y distribución eléctrica incluirá, generadores, baterías, cables PWA’s,
rectificadores, etc.
4) Use los diagramas de bloques esquemáticos para mostrar cómo los subsistemas de la
pregunta #3 está conectados. Identifíquelos (mecánicos, eléctricos, de señal, neumáticos, etc.)
5) Identifique tres funciones primarias que el sistema desempeña y describa cómo los
subsistemas unidos trabajan satisfactoriamente para cumplir cada función
6) Identifique tres ejemplos de comportamientos secundarios (no intencionados) que

pueden ocurrir al tener la arquitectura mostrados en el punto #4
7) Escoja uno de los subsistemas en el punto #3 y explique usted como mejoraría la

confiabilidad del subsistema si en una revisión se determinara que este no cumple con estándares
de confiabilidad suficientes. Aquí confiabilidad se entiende como la duración o probabilidad de
desempeño sin fallas en unas condiciones de prueba.
7.14 Proyecto Final

1: Objetivo: ________________________________
A continuación se presentan varias alternativas para poner como objetivo del proyecto
Se puede desarrollar un robot cuyo objetivo sea recoger basura dejada en un sitio cerrado. El
objetivo de este diseñar un robot que recorra la mayor cantidad de espacio en la menor cantidad
de tiempo, con un movimiento oscilante para ir recogiendo la basura que se encuentra en el área.
Se puede diseñar una competencia de carros chocones, donde cada carro tiene un sensor de
contacto, el cual va contando cuantas veces se activa. Cada activación significa que hubo un
contacto, el que menos contactos tenga en un periodo determinado del tiempo es el equipo
ganador.
Se puede pedirle a los estudiantes que desarrollen un montacargas, el cual debe cargar varios
pesos diferentes y moverlos desde el punto A hasta el punto B. El que logre mover de forma exitosa
la mayor cantidad de peso será el equipo ganador.
Se puede diseñar un robot seguidor de línea, el cual debe recorrer un circuito demarcado con una
cinta negra en un área cerrada. El equipo que logre completar el circuito en el menor tiempo
posible será el ganador.
Cualquier idea puede ser aplicada, se pueden encontrar ejemplos acá.

http://www.nxtprograms.com/index2.html
Tienen 3 sesiones para desarrollar todo el entrono con respecto a lo visto en clase (modelo V),
familiarizarse con el sistema con la ayuda del equipo docente y hacer pruebas con los diferentes
sensores y motores de los equipos. La última sesión es de desarrollo del proyecto.
2: Se darán dos horas para crear, diseñar, implementar y operar un sistema que cumpla con el
objetivo estipulado en el punto 1.
a) Los equipos no pueden discutir ni compartir información con otros equipos sobre la
solución diseñada
b) Los equipos están limitados a los materiales que vienen con 1 set de Lego Mindstorms
(ningún tipo de objeto externo).
c) Toda la energía cinética requerida para cumplir con la tarea debe realizarse a través de la
operación del sistema Lego Mindstorms (no empujar, cargar, inclinar, arrojar, etc. ninguna parte
del sistema para cumplir con la tarea) se pueden presionar los botones del equipo únicamente.
d) El sistema debe ser de móvil.
e) No se debería programar, pero es permitido si se necesita
f) El equipo docente se reserva el derecho de cambiar cualquiera de estas reglas, en

cualquier momento si se requiere corregir algún acontecimiento que no se les ocurrió podría
suceder durante el desarrollo de la prueba.
Se procede entonces a desarrollar un proyecto que sirva como base para entender los resultados
esperados de los estudiantes.
Se escoge el robot seguidor de línea. En este caso se omite toda la definición de Stakeholders y de
requerimientos, aunque los estudiantes si deben realizarlo.
A continuación se muestra el desarrollo del robot con un código respectivo. Para este robot
necesitan las siguientes piezas:
Imagen 1.Elementos para el soporte del cerebro. [El autor]
Se crea el soporte del cerebro del robot y se pega el cerebro a los 8 puntos grises que sobresalen
del soporte.
Imagen 2.El soporte ensamblado. [El autor]
Para el montaje del motor se utilizan las siguientes piezas
Imagen 3.Elementos para ensamblar el motor. [El autor]
Imagen 4.Motores ensamblados. [El autor]
Después de esto se ensamblan los dos módulos anteriores, donde la L gris debe ajustarse a la
parte superior del cerebro del robot.
Imagen 5.Sistema acoplado. [El autor]
En la parte inferior se le agregan los “patines” lo que le permite al robot desplazarse en Zigzag
fácilmente.
Ahora se le ajusta el soporte para el sensor de luz.
Imagen 6.Sensor de luz con su soporte. [El autor]
Éste se inserta entre los patines que se pusieron en el paso anterior.

Imagen 7.Sensor de luz ajustado al sistema. [El autor]
Finalmente se le agregan las ruedas al dispositivo.
Imagen 8.El robot completamente ensamblado. [El autor]
Ahora se conectan los motores y el sensor de luz al cerebro, por medio de los cables de 4 pines
suministrado con el kit de Lego Mindstorms.
Imagen 9.Las conexiones respectivas. [El autor]
El código para que el robot se mueva en Zig-Zag se puede encontrar en el siguiente link.
http://find.botmag.com/100701
7.15 Quiz
Escriba la mayor cantidad de usos para un clip de papel que no tenga que ver con agrupar una
serie de papeles. (Buscamos del orden de 30 usos)
Objetivo: Evaluar la capacidad de pensamiento divergente de los estudiantes. NO hay respuesta

incorrecta, entre más creativa sea la idea mejor.
Feedback:
Discutir sobre el pensamiento divergente, como con la estructura que se enseñara en el curso
pueden explotarla para realizar y analizar proyectos como no lo habían hecho antes.
http://www.youtube.com/watch?v=zDZFcDGpL4U
8 DISCUSIÓN
La ingeniería sistémica es demasiado amplia como para resumirla en un curso. Pero con las
herramientas presentadas se puede tener una base solida para el desarrollo de proyectos. El
verdadero conocimiento viene con la experiencia en casos reales. Para el desarrollo de este
curso se encontraron limitaciones con el idioma, ya que la mayoría de información grafica está
en inglés por esto se debió tomar estas de manera directa e implementarlas en las
presentaciones. Este es un tema muy reciente por esto los artículos utilizados tienen una fecha
de publicación cercana a la fecha de realización de este proyecto de grado, por lo que los
estudiantes se pueden identificar con los ejemplos propuestos en estos. Para continuar este
trabajo se debe realizar una base de datos de ejercicios para que estos cambien de semestre a
semestre. Además estar actualizando las políticas y elementos de estas por la constante
evolución que ha tenido este tema en los años recientes. También se propone como expansión
del proyecto diseñar un tutorial de Lego Mindstorms para que los estudiantes no lleguen al
diseño del proyecto final sin ningún conocimiento sobre como programar esta herramienta.
9 CONCLUSIONES
La metodología de la Ingeniería Sistémica aprendida en este curso es útil para desarrollar
proyectos de alta complejidad. Como se vio a lo largo de este proyecto de grado, también
puede ser aplicada a proyectos más simples. Esta metodología ayuda a desarrollar un
pensamiento ordenado al momento de presentarse un reto y ayuda a definir correctamente
los requerimientos y necesidades de las partes, para así lograr conseguir un objetivo común de
manera exitosa. Este permite tener una visión amplia del rango del proyecto y de los posibles
inconvenientes que se pueden presentar, logrando así una prevención oportuna de los
problemas.
La herramienta de Lego Mindstorms es muy versátil, lo que permite que una gran cantidad de
proyectos puedan ser realizados. Esto ayuda mucho para aterrizar los conceptos vistos en
clase y le permite al estudiante aplicar de forma práctica las herramientas enseñadas en este
curso.
La constante evolución de esta ciencia también motiva a los estudiantes a continuar

investigando sobre los nuevos avances que pueden surgir a lo largo del curso y la participación
y discusión de estos nuevos elementos debe ser motivada en este y en cualquier curso. Esto
con el fin de no quedarse en el mismo curso repetitivo a los que los estudiantes les pueden
sacar fastidio.
El desarrollo de un curso requiere una gran cantidad de trabajo, partiendo desde un punto de
“clean sheet”. Esto permitió desarrollar un esquema de pensamiento distinto de creación, mas
no de reproducción.
Si se implementa esta metodología como curso le va a brindar unas herramientas muy

interesantes a los futuros Ingenieros Industriales de la Universidad de los Andes.
10 AGRADECIMIENTOS
Agradezco a las personas del curso de aprendizaje presencial que me dieron las bases para
poder desarrollar un curso de enseñanza.
Luis P. Pinzón por el apoyo brindado y las buenas ideas para el proyecto.
Néstor Jiménez por enfocar una idea suelta en un proyecto real.
Personas del MIT y Cornell que me brindaron ideas para el desarrollo de este curso y al
profesor De Weck quien me brindó varias herramientas para desarrollar este curso.
11 REFERENCIAS
[1] NASA. NASA Systems Engineering Handbook. NASA/SP-2007-6105, Rev 1. Washington, DC:
NASA, December 2007.
[2] Ryschkewitsch, M.G., Schaible, D. y Larson, W. The art and science of systems engineering,
NASA Enero 18, 2009.
[3] Williams, Christine, NASA HQ and Derro, Mary-Ellen, NASA Systems Engineering Behaviour,
NASA Office of the Chief Engineer, Oct 2008
[4] Haskins, Cecilia, ed. INCOSE Systems Engineering Handbook: A Guide for System Lifecycle
Processes and Activities. INCOSE-TP-2003-002-03, version 3. San Diego, CA: International
Council on Systems Engineering (INCOSE), June 2006.
[5] de Weck, Olivier. 16.842 Fundamentals of Systems Engineering, Fall 2009. (Massachusetts
Institute of Technology: MIT OpenCourseWare),http://ocw.mit.edu (Accessed 12 Nov, 2011).
License: Creative Commons BY-NC-SA
[6] Rebentisch E., Crawley E., Loureiro G., Dickmann J., y Catanzaro S. "Using Stakeholder
Value Analysis to Build Exploration Sustainability." 1era Conferencia de exploración del
espacio: Continuando el viaje del Discovery, AIAA-2005-2553, Orlando, Florida, Enero 30-31,
2005.
[7] Hauser J., y Clausing D. "The House of Quality." Harvard Business Review 66, no. 3 (Mayo-
Junio 1988): págs. 63-73.
[8] Crawley E., Weck O., Eppinger S., Magee C., Moses J., Seering W., Schindall J., Wallace D., y
Whitney D. "The Influence of Architecture in Engineering Systems." Monografía, 1er Simposio
de Ingeniería Sistémica, Cambridge, Massachusetts, Marzo 29-31, 2004.
[9] Bone, M., Dr. Cloutier, R., Eberhard, G. y Dr. Vermna, D. “Application of the Systems
Engineering Modeling in the early phases of a Complex Space System Project” Séptima
conferencia anual en investigación de Ingeniería Sistémica, Universidad Loughborough, Reino
Unido, Abril 20-23, 2009
[10] Lee, G., Systems Enginnering - When the Canvas is Blank/Systems Enginnering - When the
Canvas is Blank, DVD, JPL, 2005/2007.
[11] Williams, C. y Reyes, A., “NASA’s System Behind the System: Developing Systems
Engineers”, Papers de trabajo en las dinámicas organizacionales, Universidad de Pennsylvania,
Febrero 28, 2011
[12] Zelkowitz, F. y Rus, I. “The Role of Independent Verification and Validation in Mantaining a
Safety Critical Evolutionary Software in a Complex Environment”, Centro Fraunhofer,
Fairmont, WV, Conferencia Internacional IEEE, págs. 118-126, 2001
[13] Leveson, N., "A New Accident Model for Engineering Safer Systems." Safety Science 42,
no. 4 (Abril 2004): 237-270.
[14] Software and Systems Engineering Standards Committee of the IEEE Computer Society.
International Standard: Systems and software engineering — System life cycle processes. IEEE
Std 15288-2008, 2da ed. Piscataway, Nueva Jersey: Instituto de Ingenieros Eléctricos y
Electrónicos (IEEE), Febrero 2008.
12 Anexos
12.1 Anexo A: Programa del Curso
INGENIERÍA SISTÉMICA (IIND-XXXX)
DEPARTAMENTO DE INGENIERÍA INDUSTRIAL
PROGRAMA 2012-I
EQUIPO DOCENTE
Descripción
El objetivo de este curso es introducir los principios de la Ingeniería Sistémica.

Este curso sigue la metodología de del modelo “V” de los procesos de esta
Ingeniería. Este está dividido en cuatro etapas, definición del proyecto, tiempo,
prueba e integración del proyecto y verificación y validación. Otros conceptos a

ser vistos en el curso incluyen desempeño, costo y operatividad del sistema.
Los estándares de Ingeniería Sistémica y varios papers publicados son las
lecturas base del curso.
Motivación
Los sistemas más comunes en nuestro diario vivir consisten de cientos de

miles de partes diferentes que trabajan juntas para obtener un sinnúmero de
funciones de valor agregado. Ejemplos de esto son los sistemas que
transportan personas y mercancías, o la toma y distribución de información en
lugares remotos. Todo esto es una combinación de hardware, software y la
manipulación humana. Estos últimos son la parte vital de estos sistemas como
los diseñadores, creadores, usuarios y personas de mantenimiento. En este
curso se utilizará el término “Stakeholders” para identificar personas y
organizaciones que tienen algún interés o afectan el sistema.
La Ingeniería Sistémica es una disciplina que originalmente fue diseñada para

coordinar todas las actividades de diseño y administración que ocurren durante
los proyectos aeroespaciales de una forma tal que el resultado satisfaga los
requerimientos y que estos requerimientos satisfagan las necesidades de los
stakeholders. La Ingeniería Sistémica en este contexto se trata entonces del
diseño y manejo de partes, sus interfaces y el comportamiento en conjunto, de
forma que se logre el resultado buscado.
Han surgido un sinnúmero de estándares y manuales para las buenas prácticas

y métodos de la Ingeniería Sistémica. Estos son muy útiles para darle
consistencia a los procesos asociados al desarrollo de cualquier proyecto. En el
curso sugerido se estudiarán algunos de los estándares más importantes y los
métodos que apoyan el diseño y manejo de sistemas.
Se busca que este curso brinde las herramientas para lograr trabajar en
proyectos de alta complejidad, pero no entra en profundidad en los detalles de
cómo desarrollar un sistema en específico. Se busca que este curso sea sólo la
introducción al mundo de la Ingeniería Sistémica. El estado de arte de este
tema y el actuar recomendado están lejos de ser perfectos. A medida que le
tecnología ha progresado y los sistemas se han vuelto más y más robustos, el
nivel de complejidad ha crecido de la mano de estos. Esto conlleva un reto
enorme para el diseño y manejo de estos. Como se puede ver esta es una
materia en constante evolución que está sujeta a los retos de hacer un sistema
más económico y de fácil uso, mientras a su vez se asegura una mayor
seguridad en su operación. Por esta razón es importante conocer metodologías
que permiten diseñar, desarrollar y manejar estos nuevos sistemas de manera
correcta minimizando los errores y problemas por medio del seguimiento
estricto de las buenas prácticas del desarrollo de proyectos planteados en este
curso.
Objetivos
Los estudiantes de este curso podrán:
Describir los estándares y prácticas más importantes de la Ingeniería

Sistémica.
Conocer los pasos en el proceso de desarrollo de proyectos de la Ingeniería

Sistémica, empezando por los stakeholders y terminando con la
implementación de sistemas por medio de métodos de transición.
Entender la importancia del poder humano en el desarrollo de cualquier

sistema.
Entender las limitaciones que tiene la Ingeniería Sistémica actual en términos

de complejidad, incertidumbre entre otros.
Usar e implementar los estándares y metodologías de la Ingeniería Sistémica a

diferentes casos sencillos, para cementar las bases que servirán para resolver
problemas complejos en la vida real.
Estructura:
Este curso tiene clases presenciales que son acompañadas por lecturas,
trabajos y una competencia de diseño.
Clases:
Los cursos tienen una duración de hora y media donde se presentarán las
ideas principales de los pasos en el proceso de Ingeniería Sistémica, basados
en el Modelo “V” de esta disciplina.
Fig1. Modelo “V” del proceso de ingeniería sistémica.
Parciales: Se proponen dos parciales individuales de hora y media de duración.

En estos se busca reforzar los conceptos vistos en clase.
Lecturas: Hay dos tipos de lecturas en este curso. La lectura base es “NASA
Systems Engineering Handbook” (NASA, 2007 Revisión 1) sobre la cual están
basados los ejemplos y procesos de la clase. Las otras lecturas son papers
propuestos que grupos de estudiantes deberán utilizar para desarrollar la
sesión complementaria con una duración de no más de 40 minutos y sobre la
cual el profesor debe promover una discusión posterior.
Diseño: Como nota final se realizará una competencia de diseño utilizando los
módulos de LEGO® Mindstorms (NXT 2.0) donde se le pedirá a los estudiantes
diseñar y construir una máquina que desarrollara una actividad determinada y
competirá por realizarla en el menor tiempo o con el mayor número de aciertos
en un tiempo determinado.
Calificación:
Actividades Porcentajes
Parciales 50% (25% c/u)
Presentación 20%
Proyecto de diseño 20%
Participación en clase 10%
Para aprobar el curso el estudiante debe obtener un desempeño mínimo de

2.76. Habrá aproximación numérica en todos los casos donde se aproximará
hacia arriba solamente a partir de los decimales .76 y .26.
Estructura del curso:
SES # TOPICS READINGS

1 Revisión de la Handbook
ingeniería sistémica [NASA SEH] Capítulos 1, 2, y 3 (págs. 1-30), sección 6.1 (págs. 112-
130), sección 7.6 (pg. 261), apéndice A (págs. 263-265), apéndice B
(págs. 266-278), apéndice J (págs. 303-306), apéndice K (pg. 308),
and apéndice P (págs. 317-320).
Paper
Ryschkewitsch M., Schaible D., y Larson W. “The Art and Science of
System Engineering”, Enero 18, 2009
2 Stakeholder Handbook
[NASA SEH] Sección 4.1 (págs. 31-39) y Sección 7.1 (págs. 217-233).
Paper
Rebentisch E., Crawley E., Loureiro G., Dickmann J., y Catanzaro S.
"Using Stakeholder Value Analysis to Build Exploration Sustainability."
1era Conferencia de exploración del espacio: Continuando el viaje del
Discovery, AIAA-2005-2553, Orlando, Florida, Enero 30-31, 2005.
3 Definición de Handbook
requerimientos [NASA SEH] Sección 4.2 (págs. 40-48), Sección 6.2 (págs. 131-135),
apéndice C (págs. 279-281) y apéndice D (págs. 282-283).
Paper
Hauser J., y Clausing D. "The House of Quality." Harvard Business
Review 66, no. 3 (Mayo-Junio 1988): págs. 63-73.
4 Arquitectura del Handbook
sistema. [NASA SEH] Sección 4.3 (págs. 49-54), Sección 7.2 (págs. 234-240),
Generación de apéndice F (págs. 285-292) y apéndice G (págs. 293-298).
conceptos Paper
Crawley E., Weck O., Eppinger S., Magee C., Moses J., Seering W.,
Schindall J., Wallace D., y Whitney D. "The Influence of Architecture in
Engineering Systems." Monografía, 1er Simposio de Ingeniería

Sistémica, Cambridge, Massachusetts, Marzo 29-31, 2004.
5 Selección del Handbook
concepto [NASA SEH] Sección 4.4 (págs. 55-70), Sección 6.8 (págs. 197-216) y
apéndice O (pg. 316).
Paper
Bone, M., Dr. Cloutier, R., Eberhard, G. y Dr. Vermna, D. “Application
of the Systems Engineering Modeling in the early phases of a Complex
Space System Project” Séptima conferencia anual en investigación de
Ingeniería Sistémica, Universidad Loughborough, Reino Unido, Abril
20-23, 2009
6 Definición del Handbook
diseño. [NASA SEH] Sección 5.1 (págs. 73-77), Sección 6.5 (págs. 151-157),
Optimización Sección 6.6 (págs. 158-165), Sección 7.3 (págs. 242-245), y apéndice
multidisciplinaria M (pg. 311).
Video
Lee, G., Systems Enginnering - When the Canvas is
Blank/Systems Enginnering - When the Canvas is Blank,
DVD, JPL, 2005/2007.
7 Factores Humanos Handbook
[NASA SEH] Sección 7.4 (págs. 246-255).
Paper
Williams, C. y Reyes, A., “NASA’s System Behind the System:
Developing Systems Engineers”, Papers de trabajo en las dinámicas
organizacionales, Universidad de Pennsylvania, Febrero 28, 2011
8 Integración del Handbook
sistema. Manejo de [NASA SEH] Sección 5.2 (págs. 78-82), Sección 6.3 (págs. 136-138),
interface Sección 6.7 (págs. 166-196), apéndice H (págs. 299-300), apéndice L
(págs. 309-310), y apéndice N (págs. 312-315).
Video
Parte 5: “Spider”-diseño del modulo lunar, de la serie “From the Earth
to the Moon”, HBO, 1998
9 Verificación y Handbook
validación [NASA SEH] Sección 5.3 (págs. 83-97), Sección 5.4 (págs. 98-105),
apéndice E (pg. 284), y apéndice I (pg. 301).
Paper
Zelkowitz, F. y Rus, I. “The Role of Independent Verification and
Validation in Mantaining a Safety Critical Evolutionary Software in a
Complex Environment”, Centro Fraunhofer, Fairmont, WV, Conferencia
Internacional IEEE, págs. 118-126, 2001
10 Sistemas de Handbook
seguridad / [NASA SEH] Sección 6.4 (págs. 139-150), Sección 7.5 (págs. 256-
Operaciones 260) y apéndice Q (págs. 321-322). Sección 5.5 (págs. 106-110).
Papers
Leveson, N., "A New Accident Model for Engineering Safer
Systems." Safety Science 42, no. 4 (Abril 2004): 237-270.
11 Manejo del ciclo de Handbook
diseño Software and Systems Engineering Standards Committee of the IEEE
Computer Society. International Standard: Systems and software
engineering — System life cycle processes. IEEE Std 15288-2008, 2da
ed. Piscataway, Nueva Jersey: Instituto de Ingenieros Eléctricos y
Electrónicos (IEEE), Febrero 2008.
Anexo
Desde hace un tiempo se vienen revaluando en Colombia y el mundo los

supuestos de la educación tradicional que centrándose en contenidos funda los
procesos académicos en una pretendida “transferencia” de conocimientos por
parte de un profesor hacia un estudiante. Ahora la importancia de basar un
proceso de aprendizaje en competencias ha sido reconocida cada vez más
enfáticamente en discusiones y en políticas encaminadas a diseñar cursos y
procesos académicos en general.
Según la ABET: a continuación se listan las competencias para ingeniería

declaradas por la ABET (Engineering Accreditation Commission):
An ability to apply knowledge of mathematics, science and engineering [ABET, 3a].
An ability to design and conduct experiments, analyze and interpret data, and report
findings [ABET, 3b].
An ability to design a system, component or process to meet specifications [ABET, 3c].
An ability to function on multi-disciplinary teams [ABET, 3d].
An ability to identify, formulate and solve engineering problems [ABET, 3e].
An understanding of professional and ethical responsibility [ABET, 3f].
An ability to communicate effectively, including oral, written and visual forms [ABET,
3g].
The acquisition of a broad education and knowledge of contemporary issues necessary

to understand the impact of engineering solutions in a global and societal context
[ABET, 3h].
A recognition of the need for and an ability to engage in life-long learning to remain
effective in a climate of continually emerging technologies. [ABET 3i]
A knowledge of contemporary issues [ABET 3h]
An ability to use the techniques, skills and modern tools necessary for engineering
practice [ABET, 3k].

Curso de Ingenieria Sistemica PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Curso de Ingenieria Sistemica PDF

Cargado por

Copyright:

Formatos disponibles

Curso de Pensamiento Sistémico

MANUEL ALEJANDRO MOGOLLÓN MEJÍA

Luis Arturo Pinzón Salcedo, PhD

UNIVERSIDAD DE LOS ANDES

12.1 Anexo A: Programa del Curso ........................................................................... 49

El modelo V comúnmente utilizado para el desarrollo de Software es el eje central de este

Fig1. Modelo “V” del proceso de ingeniería sistémica.

2.2 Objetivos Específicos

2.3 Alcance y productos finales

3 DESCRIPCIÓN DE LA PROBLEMÁTICA Y JUSTIFICACIÓN DEL TRABAJO

desarrollo de cualquier proyecto. En el curso sugerido se estudiarán algunos de los estándares

and the SE Engine Pág. 23]

También se estudió el ciclo de desarrolla de la NASA y el de desarrollo de sistemas mostrado a

5 DEFINICIÓN Y ESPECIFICACIÓN DEL TRABAJO

Describir los estándares y prácticas más importantes de la Ingeniería Sistémica.

6 METODOLOGÍA DEL TRABAJO

6.1 Plan de trabajo

Paralelamente a esto se tomó el curso de aprendizaje presencial dado en la Universidad

6.2 Búsqueda de información

6.3 Alternativas de desarrollo

7.1 Programa del curso

7.2 Clase 1, Revisión de la Ingeniería Sistémica:

Niveles en un árbol de desarrollo:

Williams 3.1 Behavior Study Approach, pág 6]

En la segunda parte de la sesión se hace una introducción a la teoría general de la Ingeniería

Figura 5. Alcances de la Ingeniería Sistémica. [Ryschkewitsch pág. 5]

Los ingenieros en general se enfocan en áreas específicas de un proyecto como lo es la

Se muestra el motor de desarrollo de proyectos de la Figura 2. En la diapositiva 13, ya que se le

Análisis Top-down / Bottom-up:

Este es el estándar para la ilustración del cronograma de un proyecto. Se desarrolla de izquierda a

7.3 Clase 2, Proceso de diseño del sistema

Tipo Stakeholders Expectativas

Cliente Calidad del producto, entrega a tiempo, buen precio, soporte

Vendedor Requerimientos bien definidos.

Activos Equipo Técnico Objetivos claros, seguridad en el trabajo, trabajo en equipo.

Organizaciones funcionales Prototipos disponibles para pruebas, requerimientos de

Subcontratación Cumplimiento de pago, correcta integración con el proyecto.

Directivas de la organización Objetivos internos cumplidos (costo, cronograma), cumplimiento de

Estado Los productos no deben contaminar el medio ambiente.

Figura 7. Preguntas que rigen un ConOps. [El autor]

¿Cómo podemos identificar qué es lo que realmente quieren los stakeholders?

¿Cómo prevenimos que los stakeholders diseñen el sistema?

En la diapositiva 15 se ven las “buenas prácticas” de la NASA. Se le debe explicar al estudiante de

7.4 Clase 3, Definición de requerimientos

En la diapositiva 4 se muestra un gráfico donde se presenta el aumento de la cantidad de

Los requerimientos técnicos se organizan jerárquicamente, primero los requerimientos de alto

Hecho •Declaración de propósito

Este proceso es extremadamente importante ya que se establece un acuerdo entre los

A continuación de esto se vuelve a mostrar la Figura 3 con el objetivo de mostrarle a los

Los principales tipos de requerimientos son los funcionales, de desempeño, de restricciones, de

En la siguiente diapositiva se muestra un diagrama de flujo que muestra la separación entre el

La formulación debe ser marginal, absoluta o probabilística:

= X valor de _______ con una nivel de confianza del 95%

Tradicionalmente la métrica se evalúa en la relación beneficio/desempeño (con el costo,

Avión, Tren, Lámpara, Lavadora, Teclado, USB Key, Esfero, Reloj

Se debe realizar un seguimiento al cumplimiento de los requerimientos, por esto la gráfica de la

Medidas de desempeño Combinación de requerimientos funcionales y de desempeño.

establecer y monitorear el progreso.

Tabla 3.Se define que es MOE, MOP y TPM.

Durante la asignación de requerimientos es importante descomponer los requerimientos del

Es importante mostrar el proceso de asignación de requerimientos por esto se presenta la

7.5 Clase 4, Arquitectura del sistema

En la diapositiva 3 se expone una gráfica de complejidad, creatividad y ambigüedad que busca