ESD.

83 - Overview of Systems Engineering 04/01/11

An Overview of Systems Engineering

-The Art of Managing Complexity-

Submitted on October 16th, 2001, for ESD.83

Cory R.A. Hallam

Abstract

Systems Engineering has emerged as a distinct professional discipline in the past half
century in response to the ever-increasing complexity of new products and systems. This
paper provides a brief overview of the discipline and the role of the Systems Engineer.

Introduction
The term Systems Engineering (SE) is a generic term that describes the application of
structured engineering methodologies to the design and creation of complex systems.
While there has been great discussion about the term "system", it can be argued that from
the point of view of the System Engineer, a system is a collection or set of "parts" that
work together to perform a particular function. These parts can be in the form of
hardware, software, or liveware, and in themselves may be considered systems. The
system definition is essentially relative to the perspective of the individual who views the
system. The discipline of Systems Engineering focuses on the coordination of all of the
disciplines, tasks, and activities necessary to develop the total system.

Unlike traditional engineering disciplines, such as hydraulics engineering, structural

engineering, or electrical engineering, Systems Engineering is not governed by a set of
fundamental mathematical relations based on physical properties. In essence, it has not
traditionally been a strict laboratory-based form of engineering. It has emerged from a
need to deal with the ever-increasing complexity of system development projects, and
emerged as a collection of best-practices for managing the development of complex
engineering systems. Given the ad-hoc assemblage of many of these best-practices in

Cory R. A. Hallam Page 1

ESD.83 - Overview of Systems Engineering 04/01/11

their early years, the past several decades has seen the application of modeling and
simulation tools to the development of processes that optimize system development in
multivariate system requirements space - a process that historically was an emergent
property of multiple iterations in managing, designing, and creating complex systems.
The current state of affairs in System Engineering seems to support the notion that
Systems Engineering ultimately attempts to formalize the process of tracing and
managing customer requirements from conceptual design through to system development
and operation.

Historical Basis for Modern System Engineering

The field of System Engineering as we know it emerged from the post World War II
(WWII) military-industrial-academic complex that was embroiled in an accelerating
weapons race with the former Soviet Union. While many pre-WWII systems were
designed, built and implemented in a succession of steps with relatively few decision
makers affecting the technical design and development of the system, post WWII military
projects were inherently more complex involving exponentially increasing numbers of
disciplinary experts and increasing layers of interacting systems of systems. The
foundation of System Engineering, as it is known today, emerged from this era via the
Atlas Intercontinental Ballistic Missile (ICBM) Program.

Prior to the Atlas ICBM program, the U.S. Air Force (Army Air Corp in earlier years)
dealt with prime airframe contractors who were responsible for designing an aircraft to
military specifications and managing all of the subcontractors necessary for delivering on
the contract. This led to an environment of airframe-centric military platforms that senior
Air Force officials became accustomed to purchasing and managing on a 1-to-1 basis
with the prime. Ultimately, this resulted in a limited number of military weapons system
options, as the decision of using an airframe platform was essentially never questioned.
When the time came for the development of an ICBM in the early 1950's, the Air Force
was again poised to choose an airframe manufacturer and pursue a prime contractor
relation.

Cory R. A. Hallam Page 2

ESD.83 - Overview of Systems Engineering 04/01/11

The U.S. Air Force Assistant Secretary for Research and Development (R&D), Trevor
Gardner, was tasked with heading the USAF Strategic Missile Evaluation Committee,
later called the Teapot Committee. This committee had the task of evaluating the
numerous strategic missile development efforts in the U.S., primarily as a means to
eliminate repetition of development efforts in the country. However, with a group of very
scientifically oriented academics on the committee, many from Caltech, it quickly began
assessing the capability of airframe prime contractors to develop a system that would
require significant electronic and computational capabilities. The ICBM would indeed be
a complex system, the likes of which had never been developed. It was the
recommendation of the Teapot committee in 1954 to a young General with the Western
Development Division of the Air Force Research and Development Command, Bernard
Schriever, that ultimately changed the organizing principles of managing system
development contracts - there would be a System Engineering contractor staffed by
"unusually competent" scientists and engineers to direct the technical and management
control over all elements of the program.

With a group of intellectually gifted scientists and engineers, the company of Ramo-
Wooldridge, a company with prior experience in electronics systems, was contracted to
lead the system engineering of the Atlas program in conjunction with Shriever.
Noteworthy is the fact that Simon Ramo, a Ph.D. from Clatech and co-founder of Ramo-
Woooldridge, often served as the chair of the Teapot Committee. At the height of the
Atlas program, there were over 18 000 scientists, engineers and technicians, and a total of
70 000 people from 22 industries involved in the program, which included 17 contractors,
200 subcontractors, and over 500 hundred military officers. Ramo and his staff helped
establish System Engineering as a discipline by creating an organization dedicated to the
scheduling and coordinating of activities for subcontractor R&D, test, integration,
assembly, and operations.

The coordination element of the System Engineering approach was further driven by a
tight schedule that required concurrent development of designs, subsystems,
manufacturing and test facilities, command and control systems, and training

Cory R. A. Hallam Page 3

ESD.83 - Overview of Systems Engineering 04/01/11

mechanisms. To do this effectively required highly developed management tools to

ensure the success of concurrent and mutually dependent activities, the lack of which
would lead to "concurrent failure". These management and organizational tools dealt with
managing interfaces and boundaries between disciplines, subsystems, and people, of
which the process was often more difficult and complex than solving specific technical
problems. However, through trial and error, the team developed the quantitative tools and
methodologies that formed the basis for interdisciplinary trade studies and decision aids
that now populate the field of System Engineering. Based on the success of the Atlas
program, academics and social scientists of the 1960's codified and rationalized the best
practices observed in the military-industrial-academic programs into management science
and System Engineering that resulted in articles, books, and eventually university and
professional courses on the subject.

The System Engineer

In many respects, the System Engineer is similar to the general practitioner in medicine,
an individual who is able to grasp the issues of importance by looking at the whole
system, and delegating responsibility for handling each issue to the appropriate specialist
or team of specialists. While not necessarily called the "System Engineer", anyone who is
responsible for the design and implementation of a total system based on a set of
customer requirements is acting as a System Engineer. The role of the System Engineer is
thus one of a manager that possesses and uses a set of formal tools that structure the
system development process. In fact, the adoption of international standards for System
Engineering has resulted from the appearance of requirements for certain process
adherence guidelines in military and government system development contracts in the
past few decades.

The primary concern in all literature on Systems Engineering is the customer, or more
specifically, customer requirements and constraints. All System Engineering processes
begin with the collection and documentation of customer requirements. These
requirements are formally established as the basis for the system development, and more
importantly, are methodologically tracked from the time they are created until the system
is operated. There is essentially a paper trail of documentation and decision tools that

Cory R. A. Hallam Page 4

ESD.83 - Overview of Systems Engineering 04/01/11

describe or demonstrate the source of any system design choice to specific customer
requirements. Unlike typical "push" design methodologies that are based on the premise
of "build it and they will come", System Engineering processes are more of a "pull"
system that has the customer driving the design requirements and parameters that most
directly affect the performance of the system. It is the role of the System Engineer to
work within these parameters and orchestrate a development process that delivers the
value desired by the customer.

The System Engineering Methodology

At the highest level, the System Engineering methodology focuses on several major steps
including (1) problem statement, (2) identification of objectives and requirements
documentation, (3) concept generation, (4) analysis of alternatives and trade studies, (5)
selection of primary concept, (6) system creation, including decomposition, design,
development, integration, verification and validation, and (7) system operation and life
cycle disposal. These steps are typically orchestrated in a manner that intellectually
decomposes the problem into subsystem and eventually component-level "chunks" that
can be handled by individual engineers. The system is then physically reconstructed from
its individual components into subsystems and eventually integrated into a complete
system. Plans are created by the System Engineer to ensure that the subsystems and
overall system perform as designed (verification) and ultimately meet the desired intent
of the customer (validation) by performing the desired function.

Standards for System Engineering have emerged from many sources, and first appear in
military standards in the late 1960's. A standard is a document that establishes
engineering and technical requirements for products, processes, procedures, practices,
and methods, and has either been decreed by authority, or adopted by consensus.
Typically, government and military Systems Engineering standards have been decreed by
authority, while commercial standards (i.e. ISO, EIA, SAE, and IEEE) have been adopted
by consensus. However, the development of both decreed and adopted standards for
System Engineering have been interdependent and mutually influential in their evolution.

Cory R. A. Hallam Page 5

ESD.83 - Overview of Systems Engineering 04/01/11

These standards now form the basis for many system development contracts, and act to
ensure that the customer's needs are satisfactorily met.

The Future of the Field

The field of Systems Engineering has emerged from a collection of best practices in
system development project management to formal degrees that are now provided in
educational institutions. AT MIT, for example there are graduate degrees in "Systems
Design and Management", and interdepartmental educational organizations such as the
"Engineering Systems Division", all aimed at creating leaders whom have many of the
skills one would associate with a Systems Engineer. There are numerous research groups
around the world who focus on creating Systems Engineering tools and decision aids for
process management and optimization. The International Committee on Systems
Engineering (INCOSE) acts as a focal point for communicating the development of this
work via publications and conferences.

While it is arguable that Systems Engineering is not a simple input/output function into
which a set of requirements are entered and a system design emerges, it does provide the
framework for managing and creating systems that meet customer needs in a manner that
attempts to maximize the customer's value as measured via cost, time, and performance
metrics. Systems Engineering will thus continue to survive and evolve as a professional
discipline given the ever-increasing complexity of the distributed systems being created
in an information age.

Cory R. A. Hallam Page 6

ESD.83 - Overview of Systems Engineering 04/01/11

References

[1] Blanchard, B. (1991). Fundamentals of Systems Engineering.

[2] Brooks, F., ( 1995 ). The Mythical Man Month: Essays on Software Engineering,
2nd Ed.
[3] Buhr, R., (1984). Systems Design with ADA.
[4] Chambers, G., (1985). "What is a systems engineer?" IEEE Trans. Syst., Man,
Cybern., vol. SMC-15, pp. 517-521, July/Aug. 1985.
[5] Gandoff, M.,(1990). Systems Analysis and Design.
[6] Grady, J. (1994). System Integration, CRC Press.
[7] Grolier’s Interactive Encyclopedia (1997).
[8] Hall, D. (1962). A Methodology for Systems Engineering.
[9] Hino, K., (1965). "A standardized approach to systems engineering," Signal, pp. 41-
42, Dec. 1965.
[10] International Council on Systems Engineering (INCOSE) web pages (2001),
http:\\www.incose.org, October 2001.
[11] Kezner, H., (1984). Project Management: A System Approach to Planning,
Scheduling and Controlling, 2nd ed.
[12] Maier, M.W., Rechtin, E. (2000). The Art of System Architecting (2nd Ed.)
[13] Quality Function Deployment Implementation Manual (1989), Version 3.9,
American Supplier Institute.
[14] Sage, A., (1977). Systems Engineering Methodology and Applications
[15] Truxal, J., (1972) Introductory Systems Engineering
[16] Ulrich, K.T., Eppinger, S.D. (2000). Product Design and Development (2nd Ed.).
McGraw-Hill

Cory R. A. Hallam Page 7

ESD.83 - Overview of Systems Engineering 04/01/11

This Lectura SE PUEDE manejar en la Unidad Tres o la cuatro.

Un panorama de Ingeniería de Sistemas
-El arte de la gestión de la complejidad-

Enviado el 16 de octubre de 2001, para ESD.83

Cory R.A. Hallam

Resumen
Ingeniería de Sistemas se ha convertido en una disciplina distinta profesional en
el último medio siglo en respuesta a la complejidad cada vez mayor de nuevos
productos y sistemas. Este documento ofrece una breve visión general de la
disciplina y el papel del Ingeniero de Sistemas.
Introducción
El término de Ingeniería de Sistemas (SE) es un término genérico que describe
la aplicación de metodologías de ingeniería estructurado para el diseño y la
creación de sistemas complejos. Si bien ha habido gran discusión sobre el
término "sistema", se puede argumentar que desde el punto de vista del
Ingeniero de Sistemas, un sistema es una colección o un conjunto de "partes"
que trabajan juntos para realizar una función particular. Estas piezas pueden ser
en forma de hardware, software, o Liveware, y en sí mismos pueden ser
considerados sistemas. La definición del sistema es esencialmente relativo a la
perspectiva de la persona que ve el sistema. La disciplina de la Ingeniería de
Sistemas se centra en la coordinación de todas las disciplinas, las tareas y
actividades necesarias para desarrollar el sistema total.

A diferencia de las disciplinas tradicionales de ingeniería, tales como la

ingeniería hidráulica, ingeniería estructural, o la ingeniería eléctrica, ingeniería
de sistemas no se rige por un conjunto de relaciones matemáticas
fundamentales basados en las propiedades físicas. En esencia, no ha sido
tradicionalmente una forma estricta basada en el laboratorio de la ingeniería. Ha
surgido de la necesidad de hacer frente a la complejidad cada vez mayor de
proyectos de desarrollo de sistemas, y surgió como una colección de las mejores
prácticas para la gestión del desarrollo de sistemas complejos de ingeniería.
Habida cuenta de la ad-hoc conjunto de muchos de los mejores estas prácticas
en sus primeros años, las últimas décadas ha sido testigo de la aplicación de
herramientas de modelado y simulación para el desarrollo de los procesos que el
desarrollo de optimizar el sistema en el sistema multivariable necesidades de
espacio - un proceso que, históricamente, era una propiedad emergente de
múltiples iteraciones en la gestión, el diseño y la creación de sistemas
complejos. El estado actual de cosas en Ingeniería de Sistemas parece apoyar
la idea de que la Ingeniería de Sistemas en última instancia, los intentos de
formalizar el proceso de localización y gestión de las necesidades del cliente
desde el diseño conceptual hasta el desarrollo y operación del sistema.
Bases históricas de Ingeniería de Sistemas Modernos
El campo de la Ingeniería de Sistemas como la conocemos, surgió de la post
Segunda Guerra Mundial (WWII) complejo militar-industrial-académico que se

Cory R. A. Hallam Page 8

ESD.83 - Overview of Systems Engineering 04/01/11

vio envuelto en una carrera de armas con la aceleración de la antigua Unión

Soviética. Mientras que muchos sistemas de pre-Segunda Guerra Mundial
fueron diseñados, construidos e implementados en una sucesión de pasos con
los tomadores de decisiones que afectan a relativamente pocos el diseño técnico
y el desarrollo del sistema, después de la Segunda Guerra Mundial los proyectos
militares eran inherentemente más complejo que involucra de manera
exponencial el número creciente de expertos disciplinarios y el aumento de
capas sistemas de interacción de los sistemas. La fundación de Ingeniería de
Sistemas, como se conoce hoy, surgió a partir de esta época a través del Atlas
de Misiles Balísticos Intercontinentales (ICBM) Programa.

Antes del programa Atlas ICBM, los EE.UU. la Fuerza Aérea (Army Air Corp en
años anteriores) se refería a los contratistas célula primordial que fueron
responsables del diseño de una aeronave con las especificaciones militares y la
gestión de todos los subcontratistas necesarias para la entrega en el contrato.
Esto dio lugar a un entorno de plataformas militares céntrica estructura-que los
altos oficiales de la Fuerza Aérea se acostumbraron a la compra y gestión de
una base de 1 a 1 con la flor. En última instancia, esto dio lugar a un número
limitado de opciones militares sistema de armas, como la decisión de utilizar una
plataforma de fuselaje era esencialmente nunca cuestionó. Cuando llegó el
momento para el desarrollo de un ICBM a principios de 1950, la Fuerza Aérea
fue de nuevo a punto de elegir un fabricante de fuselajes y llevar a cabo una
relación de contratista principal.

Los EE.UU. la Fuerza Aérea de Subsecretario para la Investigación y Desarrollo

(I + D), Trevor Gardner, fue encargado de la partida de la Fuerza Aérea de
Misiles Estratégicos del Comité de Evaluación, más tarde llamado el Comité
Tetera. Esta comisión tenía la tarea de evaluar los numerosos esfuerzos
estratégicos de desarrollo de misiles en los EE.UU., principalmente como un
medio para eliminar la repetición de los esfuerzos de desarrollo en el país. Sin
embargo, con un grupo de académicos muy orientada científicamente en el
comité, muchos de Caltech, rápidamente comenzó a evaluar la capacidad de los
contratistas célula primordial para desarrollar un sistema que se requieren
importantes capacidades electrónicas y computacionales. Los ICBM de hecho
sería un sistema complejo, de la talla de los cuales nunca habían sido
desarrollados. Fue la recomendación del comité de tetera en 1954 a un joven
general con la División de Desarrollo del Oeste de la Investigación y el
Desarrollo de la Fuerza Aérea de comandos, Bernard Schriever, que en última
instancia, cambiar los principios organizativos de la gestión de contratos de
desarrollo de sistemas - habría un contratista de Ingeniería de Sistemas
compuesto por "excepcionalmente competente" científicos e ingenieros para
dirigir el control técnico y de gestión sobre todos los elementos del programa.

Con un grupo de científicos dotados intelectualmente e ingenieros, la empresa

de Ramo-Wooldridge, una empresa con experiencia previa en sistemas
electrónicos, fue contratado para dirigir la ingeniería de sistemas del programa

Cory R. A. Hallam Page 9

ESD.83 - Overview of Systems Engineering 04/01/11

Atlas, en relación con Shriever. Cabe destacar el hecho de que Simon Ramo, un
doctorado de Clatech y co-fundador del Ramo-Woooldridge, a menudo sirve
como el presidente del Comité de la tetera. A la altura del programa Atlas, había
más de 18 000 científicos, ingenieros y técnicos, y un total de 70 000 personas
de 22 industrias que participan en el programa, que incluyó 17 contratistas,
subcontratistas 200, y más de 500 cientos de oficiales militares. Ramo y su
equipo ayudaron a establecer sistema de ingeniería como una disciplina
mediante la creación de una organización dedicada a la programación y
coordinación de las actividades de los subcontratistas de I + D, pruebas,
integración, ensamblaje y operaciones.

El elemento de coordinación del enfoque de Ingeniería de Sistemas fue

impulsado más por una apretada agenda que requiere del desarrollo simultáneo
de diseños, los subsistemas, las instalaciones de fabricación y control, sistemas
de mando y control y mecanismos de capacitación. Para hacerlo con eficacia
requiere muy desarrollado herramientas de gestión para asegurar el éxito de las
actividades simultáneas y mutuamente dependientes, la falta de lo que llevaría a
las "deficiencias concurrentes". Estas herramientas de gestión y de organización
trata de la gestión de las interfaces y las fronteras entre las disciplinas, los
subsistemas, y la gente, de los cuales el proceso es a menudo más difícil y
compleja de resolver problemas técnicos específicos. Sin embargo, a través del
ensayo y error, el equipo desarrolló las herramientas cuantitativas y
metodologías que sirvió de base para los estudios de comercio interdisciplinario
y ayuda en la decisión que ahora pueblan el campo de la Ingeniería de
Sistemas. Basándose en el éxito del programa Atlas, académicos y científicos
sociales de la década de 1960 codificado y racionalizado las mejores prácticas
observadas en los programas militar-industrial-académico en ciencias de la
gestión e ingeniería del sistema que dio lugar a artículos, libros, y, finalmente,
universitarios y profesionales cursos sobre el tema.
El Ingeniero de Sistemas
En muchos aspectos, el ingeniero de sistemas es similar a la del médico general
en la medicina, una persona que es capaz de comprender los asuntos de
importancia al observar todo el sistema, y la delegación de responsabilidades
para el manejo de cada tema con el especialista adecuado o un equipo de
especialistas. Aunque no necesariamente llamado el "Ingeniero de Sistemas",
quien es el responsable del diseño e implementación de un sistema completo
basado en un conjunto de requisitos de cliente está actuando como un Ingeniero
de Sistemas. El papel del Ingeniero de Sistemas es, pues, uno de un director
que posee y utiliza un conjunto de herramientas formales que estructuran el
proceso de desarrollo del sistema. De hecho, la adopción de normas
internacionales para la Ingeniería de Sistemas es el resultado de la aparición de
las necesidades de determinadas directrices del proceso de adhesión en los
contratos de desarrollo militar y el gobierno del sistema en las últimas décadas.
La principal preocupación en toda la literatura de Ingeniería de Sistemas es el
cliente, o más específicamente, las necesidades del cliente y las limitaciones.
Todos los procesos de Ingeniería de Sistemas comienza con la recogida y

Cory R. A. Hallam Page 10

ESD.83 - Overview of Systems Engineering 04/01/11

documentación de las necesidades del cliente. Estos requisitos se han

establecido formalmente como base para el desarrollo del sistema, y más
importante aún, son metodológicamente seguimiento desde el momento de su
creación hasta que el sistema es operado. No es esencialmente un rastro de
papel de herramientas de documentación y la decisión que describa o
demuestre el origen de cualquier opción de diseño del sistema a las
necesidades específicas del cliente. A diferencia de las metodologías de diseño
de "empuje" que se basan en la premisa de "crear y ellos vendrán", Sistema de
Ingeniería de procesos son más de un "tirón" del sistema que tiene el cliente de
conducción los requisitos de diseño y parámetros que más directamente afectan
al rendimiento del sistema. Es el papel del Ingeniero de Sistemas para trabajar
dentro de estos parámetros y organizar un proceso de desarrollo que ofrece el
valor deseado por el cliente.
La metodología de Ingeniería de Sistemas
Al más alto nivel, la metodología de Ingeniería de Sistemas se centra en varios
pasos más importantes, incluyendo planteamiento del problema (1), (2) la
identificación de objetivos y requisitos de la documentación, (3) generación de
conceptos, (4) análisis de alternativas y estudios de comercio, (5) selección de
concepto primario, (6) la creación del sistema, incluyendo la descomposición, el
diseño, desarrollo, integración, verificación y validación, y (7) la operación del
sistema y la eliminación del ciclo de vida. Estas medidas suelen ser orquestada
de una manera que intelectualmente se descompone el problema en el
subsistema y, finalmente, a nivel de componentes "trozos" que pueden ser
manejados por los ingenieros individuales. El sistema es entonces físicamente
reconstruido a partir de sus distintos componentes en subsistemas y,
eventualmente, integrarse en un sistema completo. Los planes son creados por
el ingeniero de sistemas para asegurar que los subsistemas y el sistema general
de funcionar como debiera (verificación) y, finalmente, cumplir con la intención
deseada del cliente (validación), mediante la realización de la función deseada.

Normas de Ingeniería de Sistemas han surgido de diversas fuentes, y aparecen

por primera vez en las normas militares a finales de 1960. Una norma es un
documento que establece los requisitos técnicos y de ingeniería de productos,
procesos, procedimientos, prácticas y métodos, y que haya sido decretado por la
autoridad, o adoptados por consenso. Normalmente, el gobierno y militares de
Ingeniería de Sistemas normas han sido dictadas por la autoridad, mientras que
las normas comerciales (es decir, ISO, EIA, SAE, e IEEE) han sido adoptadas
por consenso. Sin embargo, el desarrollo de ambas normas decretado y
aprobado para el sistema de ingeniería han sido interdependientes y se influyen
mutuamente en su evolución. Estas normas forman ahora la base para muchos
contratos para el desarrollo, y actuar para asegurar que las necesidades del
cliente son atendidas de manera satisfactoria.

El Futuro del Campo

El campo de la Ingeniería de Sistemas se ha convertido en una colección de las
mejores prácticas en gestión de proyectos de desarrollo de sistemas de grados

Cory R. A. Hallam Page 11

ESD.83 - Overview of Systems Engineering 04/01/11

formales que ahora se imparte en establecimientos educativos. En el MIT, por

ejemplo, hay estudios de postgrado en "Diseño de Sistemas y de Gestión", e
interdepartamentales organizaciones educativas, tales como la "División de
Ingeniería de Sistemas", todo ello encaminado a la creación de líderes que
tienen muchas de las habilidades que uno asociaría con un ingeniero de
sistemas. Hay numerosos grupos de investigación de todo el mundo que se
centran en la creación de herramientas de Ingeniería de Sistemas y ayuda en la
decisión para la gestión y optimización de procesos. El Comité Internacional de
Ingeniería de Sistemas (INCOSE) actúa como punto focal para comunicar el
desarrollo de este trabajo a través de publicaciones y conferencias.
Si bien es discutible que la Ingeniería de Sistemas no es una simple entrada /
salida en función de la cual un conjunto de requisitos que se introducen y un
diseño de sistema surge, proporciona el marco para la gestión y la creación de
sistemas que satisfagan las necesidades de los clientes de una manera que
intenta maximizar valor del cliente, medida a través de indicadores de costo,
tiempo y rendimiento. Ingeniería de Sistemas en consecuencia, seguirá
sobrevivir y evolucionar como una disciplina profesional, dada la complejidad
cada vez mayor de los sistemas distribuidos que se creó en una era de la
información.

Referencias

[1] Blanchard, B. (1991). Fundamentos de Ingeniería de Sistemas.

[2] Brooks, F., (1995). El Mes hombre mítico: Ensayos sobre Ingeniería de
Software, 2 ª ed.
[3] Buhr, R. (1984). Diseño, con el ADA.
[4] Salas, G., (1985). "¿Qué es un ingeniero de sistemas?" IEEE Trans. Syst.,
Hombre, Cybern., Vol. SMC-15, pp desde 517 hasta 521, julio / agosto 1985.
[5] Gandoff, M., (1990). Análisis de Sistemas y Diseño.
[6] Grady, J. (1994). Sistema de la Integración, CRC Press.
Enciclopedia Interactiva [7] Grolier (1997).
[8] Hall, D. (1962). Una Metodología para la Ingeniería de Sistemas.
[9], Hino, K. (1965). "Un enfoque estandarizado para la ingeniería de sistemas,"
la señal, pp 41-42, diciembre de 1965.
[10] Consejo Internacional de Sistemas de páginas web de Ingeniería (INCOSE)
(2001), http: \ \ www.incose.org, octubre de 2001.
[11] Kezner, H. (1984). Gestión de Proyectos: Un Enfoque de Sistema de
Planificación, Programación y Control, 2 ª ed.
[12] Maier, M.W., Rechtin, E. (2000). El arte de la Arquitectura del Sistema (2 ª
ed.)
[13] Quality Function Deployment Manual de Implementación (1989), Versión
3.9, American Supplier Institute.
[14] Sage, A., (1977). Metodología de Sistemas de Ingeniería y Aplicaciones
[15] Truxal, J., (1972) Ingeniería de Sistemas de introducción
[16] Ulrich, K.T., Eppinger, D.E. (2000). Diseño de Producto y Desarrollo (2 ª
ed.). McGraw-Hill

Cory R. A. Hallam Page 12

ESD.83 - Overview of Systems Engineering 04/01/11

Cory R. A. Hallam Page 13