EXTRACTO
El proceso de diseño del sistema traduce las necesidades de los clientes en un diseño de sistema edificable. Requiere seleccionar subsistemas de un conjunto permitido y hacer coincidir las interfaces entre ellos. Los diseños que cumplen con los requisitos de entrada y salida de alto nivel se prueban para ver qué tan bien cumplen con los objetivos de rendimiento y costos del sistema. Este documento demuestra que el problema de diseño del sistema es NP-completo por reducción del problema Knapsack, que se sabe que es NP-completo. La implicación de esta prueba es que no es posible diseñar sistemas óptimos con procedimientos de tiempo polinomios deterministas. Esta es la razón principal por la cual los ingenieros no intentan producir sistemas óptimos: simplemente producen diseños que son lo suficientemente buenos. © 2001 John Wiley & Sons, Inc. Syst Eng 4: 222-229, 2001
1. INTRODUCCIÓN
El proceso de diseño del sistema que se muestra en la figura 1 traslada los requisitos del sistema a un diseño de sistema armable. Este proceso puede describirse matemáticamente [Wymore, 1993] y, por lo tanto, podemos estimar su complejidad, lo que nos ayudará a identificar el mejor enfoque de solución.
Este es un documento teórico de ingeniería de sistemas. Por lo tanto, es apropiado vincularlo con otros documentos teóricos. En la primera parte del siglo 20, mathema-
* Autor a quien debe dirigirse toda la correspondencia (e-mail: terry@sie.arzona.edu).
Systems Engineernig, vol. 4, No. 3, 2001 © 2001 John Wiley & Sons, Inc.
Los especialistas esperaban construir una red de postulados, axiomas y teoremas interconectados que capturaran todas las afirmaciones verdaderas de las matemáticas. En 1931, Gödel [1990] demostró que esto no era posible, mediante la propuesta de su teorema de incompletitud, que es similar al “Esta oración es falsa”. Gödel se ocupa de todo el campo de razonamiento matemático axiomático. En un reino nar-rower, los lógicos posteriores trataron de probar si existían soluciones para ciertas clases de problemas. Turing [1936] demostró que todos los problemas de lógica secuencial solucionables podían resolverse con una Máquina de Turing (una máquina de estado con memoria). Más tarde mostró que el Problema de Detención (que determina si una máquina de Turing se detendrá para una entrada determinada y un conjunto de reglas) es indecidible, es decir, no demostrable. Turing estaba preocupado por la solvencia de los problemas de lógica. Nuestro presente
el papel se refiere a un subconjunto de problemas solucionables, a saber, problemas de diseño del sistema. En particular, se refiere al tiempo requerido para resolver estos problemas. Los problemas que llevan más tiempo se llaman NP-completos.
2. PROBLEMAS DE NP-COMPLETE
NP-complete es el nombre de una clase de problemas para los que no se conoce una solución algorítmica determinista eficiente [Garey y Johnson, 1979]. Todos los algoritmos conocidos para resolver estos problemas tienen la propiedad de que a medida que aumenta el tamaño del problema, el número de pasos necesarios para resolver el problema aumenta exponencialmente.
Primero, veamos un problema fácil que tiene algoritmos eficientes cuyo número de pasos aumenta a la velocidad de un polinomio. Por ejemplo, un tipo simple de una lista delos números se pueden hacer en n2 número de operaciones. Por lo tanto, si hubiera 10 números para ordenar, tomaría, como máximo, 102 o 100 operaciones para realizar el ordenamiento. Si hubiera 100 números para ordenar, tomaría 1002 o 10,000 operaciones. Este es un problema fácil.
Ahora veamos un problema difícil que requiere una cantidad exponencial de pasos para resolver, porque el tamaño del problema está en el exponente, como en. Para un problema exponencial con n = 10 habría 22,026 operaciones. Si n = 100, habría 2,7 × 1043 operaciones. Como se muestra en la Figura 2, el número de operaciones excede rápidamente la capacidad de cualquier máquina para computar una solución. Por ejemplo, si hubiera una máquina que pudiera hacer 1012 operaciones por segundo (ninguna aún existe) y hubiera un problema que requiriera 1020 operaciones, tomaría entre 1020 y 12 o 108 so más de 3 años resolverlo. Si el problema requirió 1023 operaciones, entonces
tomaría 3171 años para resolver. Supongamos que la edad del universo es de 9 mil millones de años, que es 3 × 1017 s, ¡entonces cualquier problema que requiera más de 1012 + 17 o 1029 operaciones no podría hacerse en toda la edad del universo!
Otro ejemplo de este crecimiento explosivo de funciones exponenciales es la fábula del rey, el campesino y el tablero de ajedrez. El campesino le hizo un favor al rey y, a cambio, el rey le pidió al campesino que nombrara su recompensa. El humilde campesino dijo que simplemente quería un solo grano de arroz en el primer cuadrado de un tablero de ajedrez y el doble en cada casilla subsiguiente, 2n. El rey está de acuerdo. Los primeros cuadrados toman muy poco arroz. El 20º cuadrado toma unos pocos galones. La casilla 25 ocupa el volumen de un escritorio. La trigésima casilla necesita el volumen de una sala de conferencias. La cuadratna 64 requiere 263 granos de arroz, que llenarían un millón de buques de carga grandes.
El conjunto de problemas que se pueden resolver en el tiempo del Polinomio no determinista se llama NP. Los lógicos crearon un dispositivo conceptual llamado máquina no determinista para resolver estos problemas. Una máquina no determinista tiene un número infinito de procesadores y dos etapas: una etapa de adivinación y una etapa de comprobación. Cada procesador adivina una respuesta y el verificador verifica que es una buena respuesta. Ambas etapas se ejecutan en tiempo polinomial (polinomial en el tamaño de la entrada, por ejemplo, n6). Debido a que existe un número infinito de procesadores y todas las suposiciones y comprobaciones se realizan en paralelo, el tiempo de cálculo es polinomial. Por supuesto, esta es una máquina de fantasía, pero ayuda a ilustrar el hecho de que un cierto conjunto de problemas se puede resolver en tiempo polinomial si se utiliza una de estas máquinas no deterministas. Claramente, cualquier algoritmo polinomial determinístico podría seguir utilizando la máquina no determinista, porque el algoritmo podría estar restringido a un solo procesador.
NP-complete es una clase de problemas que se puede resolver en tiempo polinomial en una máquina no determinista, pero para la cual no se conoce ningún algoritmo de tiempo polinomial determinista. Nunca se ha demostrado que un algoritmo polinomial no exista, pero nadie ha encontrado uno, y los matemáticos creen que nadie lo hará jamás. Una característica fundamental de todos los problemas NP-complete es que una instancia de uno se puede mapear en una instancia de otro utilizando una transformación de tiempo polinomial. Si puede demostrarse que incluso uno de los problemas de la clase NP-complete tiene una solución en tiempo polinomial, todos ellos tienen esa solución. Sin embargo, ninguno se ha encontrado en 30 años de búsqueda por personas muy talentosas. Por lo tanto, generalmente se acepta que si se demuestra que un problema es NP completo, entonces no se encontrará ningún algoritmo eficiente para resolver el problema. Para demostrar que un problema es NP completo, debemos demostrar que se encuentra en la intersección de los problemas de NP y los problemas de NP.
Pero esta afirmación no aclara; simplemente agrega más complejidad, así que veamos un ejemplo.
Para ilustrar NP-integridad, ahora discutiremos el problema de la mochila, que Karp [1972] demostró que es NP-completo. En el problema de la mochila, un excursionista debe empacar una mochila. Él tiene una gran colección de artículos para elegir (U). Cada artículo (u) que se colocará en la mochila tendrá un cierto valor [v (u)] en el viaje y cada artículo tendrá un cierto tamaño [s (u)]. La tarea del excursionista es elegir elementos para que se obtenga al menos el valor total de (K), sin exceder el tamaño de la mochila (B). Se establece formalmente como
Instancia: Un conjunto finito U, un "tamaño" s (u) ∈ Z + (donde Z + es el conjunto de enteros positivos) y un "valor" v (u)
∈ Z + para cada u ∈ U, una restricción de tamaño B ∈ Z +, y un objetivo de valor K ∈ Z +.
Pregunta: ¿Hay un subconjunto U '⊆ U tal que
Σ su ≤ B y Σvu≥K?
U ∈ U 'u ∈ U'
3. EL PROBLEMA DEL DISEÑO DEL SISTEMA
En términos de teoría de sistemas, el problema del diseño del sistema puede describirse como el establecimiento de las relaciones insumo-producto, las restricciones de diseño y las cifras de rendimiento y costo de mérito [Asimow, 1962; Chapman, Bahill y Wymore, 1992; Wymore, 1993]. Para un conjunto dado de subsistemas (o componentes) disponibles para construir el sistema, se configura un posible sistema que satisfaga los requisitos de entrada-salida del sistema. Este sistema luego se prueba usando un requisito de prueba predefinido para proporcionar un índice de rendimiento general del sistema (PI). Esto debe superar un límite de aceptabilidad proporcionado por el cliente. El costo del sistema en términos de tiempo, dinero u otros recursos se calcula en un índice de costo general (IC). Este CI debe ser menor que algún valor objetivo especificado por el cliente.
El enfoque de sistemas para el diseño se puede caracterizar de la siguiente manera: definir un conjunto de subsistemas (Z) que constituyan la tecnología disponible para construir el sistema deseado. Cada elemento Zi en este conjunto tiene un puerto de entrada Ii y un puerto de salida Oi. Los puertos proporcionan los medios para conectar los diferentes subsistemas entre sí para formar un sistema. Los puertos de salida están conectados a los puertos de entrada de acuerdo con una receta de acoplamiento del sistema, SCR, para formar un sistema candidato, Z @. Defina la entrada general al sistema deseado como I0 y la salida general del sistema deseado como O0. En este documento, solo consideramos el aspecto del diseño del sistema relacionado con la conexión de subsistemas y el rendimiento. Si se muestra que esta tarea es NP-completa, entonces, sin duda, la tarea más grande que
incluye descubrir los requisitos, definir las funciones del sistema y rediseñar también será NP-completo. Un sistema, Z @, que podría construirse a partir de siete subsistemas se muestra en la Figura 3.
Estas conexiones se pueden expresar como un gráfico dirigido donde los subsistemas individuales son nodos y las posibles conexiones entre puertos son los arcos. La fuente inicial para el gráfico dirigido es el puerto de entrada del sistema, I0, y el objetivo inicial (o sumidero) para el gráfico dirigido es el puerto de salida, O0. Deje que la longitud de cada arco represente el costo de conectar los dos subsistemas (vea la Fig. 4). Para encontrar un diseño de sistema potencial, debemos encontrar una ruta a través de un gráfico dirigido.
Encontrar un camino a través de un gráfico dirigido se puede lograr en tiempo polinomial. Encontrar el camino más corto a través del gráfico también se puede lograr en tiempo polinomial. El problema es que el diseño del sistema no es simplemente resolver por una restricción, como el menor costo. Además, se debe encontrar un sistema que al menos coincida con un umbral de rendimiento. Tener dos limitaciones para satisfacer al mismo tiempo requiere sacrificios ya que se realiza una búsqueda del mejor valor. Esto requiere mucha más búsqueda, especialmente a medida que aumenta la cantidad de opciones.
Un sistema a menudo está compuesto de subsistemas que están conectados entre sí. Una receta de acoplamiento de sistema (SCR) especifica los subsistemas que se van a conectar (VSCR) y sus conectividades (CSRC) [Wymore, 1993]. Para el
ruta en la Figura 5, el sistema Z @ es el resultado de la siguiente receta de acoplamiento del sistema:
SCR = {VSCR = (Z3, Z4, Z5)
y
CSCR = ((I0, IZ3), (OZ3, IZ4), (OZ4, IZ5), (OZ5, O0))}
El VSCR nos dice que el sistema está compuesto por tres subsistemas: Z3, Z4 y Z5. El CSCR nos dice que la entrada del sistema, I0, está conectada a la entrada de Z3. La salida de Z3 está conectada a la entrada de Z4. La salida de Z4 está conectada a la entrada de Z5. Finalmente, la salida de Z5 está conectada a la salida del sistema, O0. Después de que el sistema está acoplado, se prueba según los requisitos para ver si satisface el PI. Para una ruta simple, el IC del sistema puede ser la suma de la longitud de los arcos.
Este proceso es cómo se crean los diseños. Un ingeniero encuentra subsistemas que satisfacen los requisitos necesarios de entrada / salida y crea una interconexión de estos subsistemas para satisfacer los requisitos de rendimiento y costo. A menudo se consideran varios sistemas diferentes (conceptos, alternativas, modelos o prototipos) antes de que se determine una selección del mejor sistema posible en base a estudios de intercambio.
4. EL PROBLEMA DE DISEÑO DEL SISTEMA ES NP-COMPLETO
Comparemos ahora este problema de diseño del sistema con el problema de la mochila. Los subsistemas individuales se conectan juntos como se especifica en la receta de acoplamiento del sistema para formar el sistema general denominado Z @, que tiene medidas de rendimiento (PI) y costo (CI) asociados. Deje que PI ⇔ K y CI ⇔ B. Deje Z ⇔ U, sea el conjunto de todos los subsistemas permitidos. Deje que Z @ ⇔ U 'sea el subconjunto de subsistemas seleccionados de Z mediante el SCR para formar Z @. Cada subsistema Zi ⇔ u tiene un costo asociado que contribuye al IC. Deje que el costo (Zi) ⇔ s (u). Cada
el subsistema Zi ⇔u tiene un valor asociado que se puede medir mediante el requisito de prueba que contribuye al índice de rendimiento global, PI. Permitir perf (Z) ⇔v (u). Sumamos el rendimiento de cada artículo para obtener el índice de rendimiento general. Las funciones de compensación más complicadas a veces se usan en el mundo real. Esto no es molesto, porque si nuestro problema simple es NP-completo, entonces cualquier diseño que use una función de compensación más compleja tendría que ser al menos tan difícil. Si restringimos el problema de diseño del sistema a medidas de rendimiento y costo que se combinan linealmente, entonces
Σ prefΣZi PI y ΣcostZiCI.
Zi∈Z @ Zi∈Z @
Por lo tanto, el problema de la mochila se correlaciona con una instancia del problema de diseño del sistema, como se muestra en la Tabla I.
Por lo tanto, si podemos encontrar un sistema Z @ tal que su PI y CI satisfagan los requisitos de los clientes, entonces hemos resuelto el problema de diseño del sistema. Por lo tanto, si podemos resolver el problema de diseño del sistema, entonces podemos resolver el problema de la mochila, pero sabemos que el problema de la mochila es NP-completo; por lo tanto, el problema de diseño del sistema también es NP completo.
Demostrar que el problema de la mochila puede ser restringido a una instancia del problema de diseño del sistema es suficiente para probar la integridad de NP, porque si hubiera una solución para el problema de diseño del sistema, podríamos usarla para resolver el problema de mochila y, por lo tanto, otros problemas NP-completos.
5. IMPLICACIONES
La primera implicación de que el problema de diseño del sistema es NP-completo es que los humanos no podemos diseñar sistemas óptimos para problemas complejos. Y las computadoras no podrán rescatarnos, porque las computadoras tampoco pueden diseñar soluciones óptimas para problemas complejos.
Por lo tanto, el propósito de crear herramientas de diseño computarizado no debe ser permitirnos diseñar sistemas óptimos. Además, es poco probable que una computadora pueda diseñar un sistema complejo mejor que una persona. Los subconjuntos de todo el proceso de diseño, como las interfaces de enrutamiento y comprobación, ahora son mejor para las computadoras; sin embargo, no existe ningún algoritmo informático para crear incluso una fábrica de automóviles simple o una computadora personal. La creación de un sistema es tanto arte como ciencia, porque la combinatoria involucrada requiere soluciones originales, en lugar de algoritmos fijos para resolver el problema. Cuando se consideran los problemas más complejos de la creatividad individual y el ajuste por las necesidades percibidas del cliente, en lugar de los que se expresan con precisión, se hace aún más obvio que una herramienta de diseño totalmente automatizada es imposible. La investigación debe centrarse en lo humano en el ciclo como el único enfoque factible para el problema de diseño del sistema.
Si es tan difícil obtener la optimalidad, uno podría preguntarse: "¿Por qué hay tantos sistemas buenos?" La respuesta se encuentra dentro de las técnicas de solución de los problemas NP-completos. Incluso los problemas más difíciles de esta clase tienen algoritmos para obtener buenas soluciones (es decir, una solución dentro de un pequeño porcentaje de un óptimo teórico cuando es posible calcular) con algoritmos polinomiales relativamente simples.
Las técnicas utilizadas para encontrar buenas soluciones a los problemas NP-completos [Garey y Johnson, 1979] (como el Problema del Viajero Vendedor [Coy et al., 1998], el Problema de la Alforja [Karp, 1972], la ruta máxima a través de una red [Bernard y Graham, 1989], la colección de prueba mínima, el gráfico 3-colorabilidad, etc.) también se pueden aplicar (y se han aplicado, a sabiendas o no) al problema de diseño del sistema. Hemos demostrado que muchos métodos de resolución de problemas NP-completos se han utilizado para diseñar sistemas [Moody et al., 1997]. Una de estas técnicas es la descomposición. El sistema general se descompone en subsistemas como se muestra en la Figura
3. A continuación, cada uno de estos subsistemas se descompone en subsubsystems. Este proceso se continuó hasta que cada subsubsystem es lo suficientemente pequeño que un equipo de ingenieros pueden diseño de la misma. Un problema con la descomposición técnica es que común folk sabiduría dice que la conexión óptimo subsistemas no va a producir un óptimo supersystem (por ejemplo, en el fútbol un pro Bowl equipo no sería espera que vencer la Superbowl Campeones). No obstante, wymore (http://www.sie.arizona.edu/sysengr/wymore/optimal HTML) muestra que para una muy restringido el conjunto de compensación funciones, conexión optimizado subsistemas hace en la escritura de rendimiento óptimo supersystem. La mayoría de los ingenieros de darse cuenta de que la mayoría de ellos el tiempo no trate de producir óptimo diseños. En este trabajo se han demostrado por qué se trata de una buena estrategia. Ingenieros no trate de producir óptimo diseños, ya que para los sistemas complejos sería imposible de hacerlo. Simon [1957, pp. 204-05] dice que la clave para el éxito de diseño es "el reemplazo de la meta de la maximización con el objetivo de satisficing, de la búsqueda de un curso de acción que es" lo suficientemente bueno. '... ya que el [diseñador] ... tiene ni los sentidos, ni el ingenio para descubrir un' óptimo 'trayectoria aun suponiendo que el concepto de óptima para ser claramente defined- estamos interesados sólo con la búsqueda de elegir mecanismo que dará lugar a perseguir un' satisficing 'camino, un camino que va a permitir que la satisfacción en algún nivel determinado de todas sus necesidades. "Ostrofsky [1977, p. 79] se define la óptima del sistema de ser" en teoría, el más favorable para los criterios definidos "y el óptimo del sistema de ser" la mayoría de favor, capaz de los criterios y el conjunto de los candidatos definido. "Su punto es que tú nunca obtener la solución óptima, y usted debe establecerse por menos. Como dos revisores de este trabajo declaró," la mayoría de los sistemas de ingenieros, probablemente, entender el hecho de que una solución óptima a un complejo de diseño de sistemas problema no existe! "Todos los que hemos hecho en este trabajo es demostrar mathe-mente que sus intuiciones, generado por años de experiencia, son de hecho correcta. El mundo Real del diseño del sistema problema es más difícil que el diseño del sistema problema se describe en este PA-por. En primer lugar, en este trabajo, los requisitos nunca cambiado, en el mundo Real, esto es rara vez verdadero. En segundo lugar, en este documento, se han demostrado que el diseño de un sistema es np-completa. ¿Pero los ingenieros de diseño único de diseño de un sistema? N que diseño muchos sistemas y a continuación, tratar de elegir la mejor alternativa para la aplicación. Allí, primer plano, el mundo Real del diseño del sistema problema es más difícil de lo que hemos descrito en este documento. Sin embargo, Klein [1998] dice que los diseñadores realmente no evaluar muchas alternativas diseños en paralelo, sino más bien que desarrollar una alternativa a la vez hasta que conseguir uno que satisface. Por lo tanto, la complejidad del mundo Real del diseño del sistema problema radica en algún lugar entre el diseño de un sistema y el diseño de muchos y selección de la mejor alternativa. Por lo tanto, si el diseño de un sistema es np-completa, entonces el mundo Real del diseño del sistema problema es aún más difícil. En este documento, se han demostrado que el teórico del diseño del sistema problema es np-completa en todos los aspectos discutido, y hemos demostrado que el mundo Real sys-TEM diseño problema es más difícil. Sin embargo, no es una excepción. El rendimiento de un sistema podría ser mayor que la suma de sus subsistemas (cooperación). Dos Leones persiguiendo a un thompkins Gazelle son más de dos veces más probabilidades de captura de ella, de una sola León. Un par de palillos realiza más de dos veces al igual que un individuo palillo. Sin embargo, se utiliza lineal además para nuestros las cifras de rendimiento de mérito. Por lo tanto, si todo es mayor que la suma de sus partes, pudimos conseguir una mejor rendimiento. 6. resumen hay una necesidad de que la teoría en el campo de diseño de sistemas. Este papel no es más que un bebé paso en ese sentido. Porque el diseño del sistema es tan una vieja de campo, sería espera que tienen una base teórica. Sin embargo, hay muy pocos teórico Ingeniería de sistemas papeles. Las excepciones notables son wymore [1993], wymore y bahill [2000], y de la red Mundial papeles por wymore (http://www.sie.arizona.edu/sysengr/wy-more). A pesar de que es sólo un pequeño paso, este trabajo se suma a la teórico papeles en el campo. Este trabajo se ha demostrado que el diseño del sistema Prob-Lem es np-completa de cartografía a la mochila problema. Las implicaciones son que el logro de un diseño óptimo para un sistema complejo no es probable. Es posible de diseño para siempre sin el logro de una solución óptima. Por lo tanto, los límites debe ser establecido en el diseño temprano en el proceso. No tenemos el tiempo para el diseño óptimo de sistemas, pero podemos diseñar sistemas que son lo suficientemente bueno. Además, la creación de una computadora herramienta de diseño será muy difícil. El aspecto interesante de np-completa algoritmos es que a menudo es bastante fácil encontrar cerca-op-timal soluciones. En el contexto de producto diseño, optimalidad rara vez es un objetivo, sino más bien de satisfacción de un problema comunicado. Por lo tanto, una solución lo suficientemente bueno para satisfacer el cliente puede ser al alcance de un basada en el conocimiento herramienta de diseño. En resumen, filósofos meditaba el tipo de problemas que se soluble: el diseño del sistema Prob-Lem parece ser soluble. Teóricos han preocupado acerca cuánto tiempo puede tomar para encontrar soluciones para ciertas clases de los problemas de: debido a que el diseño del sistema de pro-
lem es NP-completo, encontrar una solución óptima podría llevar una cantidad infinita de tiempo. Por lo tanto, los ingenieros de sistemas deben asegurarse de que sus clientes no requieran soluciones óptimas, porque las soluciones óptimas no son factibles. Los conductistas han demostrado que los humanos no buscan soluciones óptimas, sino que buscan soluciones satisfactorias: por lo tanto, los ingenieros de sistemas deben explicarles a sus clientes que solo producimos soluciones lo suficientemente buenas para el problema de diseño del sistema, es decir, producimos soluciones satisfactorias. , soluciones no óptimas. Finalmente, los académicos han demostrado que el trabajo de un ingeniero de sistemas es difícil, de hecho, NP-hard.
EXPRESIONES DE GRATITUD
Agradecemos a Will Evans en la Universidad de Arizona por sus comentarios reflexivos. Se publicó una versión anterior de este documento en las Actas de la Conferencia Internacional de IEEE sobre Sistemas, Hombre y Cibernética, San Antonio, TX, octubre de 1994, págs. 1880-1884.
REFERENCIAS
M. Asimow, Introducción al diseño, Prentice-Hall, Engle-wood Cliffs, 1962.
M.W. Bern y R.L. Graham, The shortest network problem, Sci Am (enero de 1989), vol. 260, no. 1, 84-89.
W.L. Chapman, A.T. Bahill y A.W. Wymore, modelado y diseño de ingeniería, CRC Press, Boca Raton, FL, 1992.
S.P. Coy, B.L. Golden, G.C. Runger y E.A. Wasil, Vea el bosque antes que los árboles: Aprendizaje bien ajustado y su aplicación al problema del vendedor ambulante, IEEE Trans Syst Man Cybernet, Parte A, Syst Hum 28 (1998), 454-464.
M. Garey y D. Johnson, Computadoras e intratabilidad: una guía para la teoría de NP-completitud, Freeman, Nueva York, 1979.
K. Gödel, Kurt Gödel, Obras completas, S. Feferman (Redactor), Oxford University Press, Oxford, 1990.
R.M. Karp, "Reducción entre problemas combinatorios", Complejidad de cálculos computacionales, R.E. Miller y J.W. Thatcher (Editores), Plenum, Nueva York, 1972, pp. 85-103.
G. Klein, Fuentes de poder: cómo las personas toman decisiones, MIT Press, Cambridge, MA, 1998.
J.A. Moody, W.L. Chapman, F.D. Van Voorhees y A.T. Bahill, Métricas y estudios de caso para evaluar diseños de ingeniería, Prentice Hall PTR, Upper Saddle River, NJ, 1997.
B. Ostrofsky, diseño, planificación y metodología de desarrollo, Prentice-Hall, Englewood Cliffs, NJ, 1977.
H. A. Simon, Modelos de hombre: Social y racional, Wiley, Nueva York, 1957.
A. Turing, en números computables con una aplicación al Entscheidungsproblem, Proc London Math Soc, XLII, 1936, págs. 239-265 ["Correction", Proc London Math Soc, XLIII, 1937, pp. 544-546].
A.W. Wymore, ingeniería de sistemas basada en modelos, CRC Press, Boca Raton, FL, 1993.
A.W. Wymore y A.T. Bahill, ¿cuándo podemos reutilizar de manera segura los sistemas, actualizar los sistemas o usar los componentes de COTS? Syst Eng 3 (2) (2000), pp. 82-95.
William L. Chapman es Investigador de Ingeniería en Raytheon Corporation en Tucson. Ha trabajado en muchas partes del diseño de misiles tácticos y actualmente es responsable de las tareas de investigación de la línea de productos Land Combat. Obtuvo un Ph.D. en Ingeniería de Sistemas de la Universidad de Arizona en 1994.
Jerzy Rozenblit es profesor de Ingeniería Eléctrica e Informática en la Universidad de Arizona, Tucson. Él posee el Ph.D. y M.S. licenciado en Ciencias de la Computación por la Universidad Estatal de Wayne, Michigan y el MSc en Ingeniería Informática por la Universidad Técnica de Wroclaw, Polonia. Su investigación y enseñanza están en las áreas de diseño de sistemas complejos y simulación de modelos. Su investigación en diseño ha contado con el apoyo de la National Science Foundation, Siemens AG, Semiconductor Research Corporation, McDonnell Douglas y los EE.UU. Army Research Laboratories, donde fue investigador. El Dr. Rozenblit es Editor Asociado de ACM Transactions on Modelling and Computer Simulation, Editor Asociado de IEEE Transactions on Systems, Man and Cybernetics, y revisor de varias agencias de financiación nacionales e internacionales. En 1994 y 1995, fue Becario Fulbright Senior y Profesor Visitante en el Instituto de Ciencias de Sistemas, Johannes Kepler University, Austria. También ha ocupado puestos de científico visitante en los Laboratorios Centrales de Investigación de Siemens AG, en Munich.
A. Terry Bahill es profesor de Ingeniería de Sistemas en la Universidad de Arizona y miembro de ingeniería de Raytheon Missile Systems en Tucson. Recibió su Ph.D. en ingeniería eléctrica y ciencias de la computación de la Universidad de California, Berkeley, en 1975. Tiene una patente de EE. UU. para Bat Chooser, un sistema que calcula el peso Ideal Bat para béisbol individual y bateadores de softbol. Es editor de la serie de prensa de CRC sobre ingeniería de sistemas. Es miembro del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) y del INCOSE. Él es el presidente del Comité de Selección de Fellows de INCOSE.
