Sunteți pe pagina 1din 493

A D M IN 1 S*r -,A C 100 N

-.`R
DE- kNGENIERIA
DE MAS
Novedades de Megabyte de marzo y
abril '93

* Secretos de Windows 3. 1
Brian Livingston
Incluye 3 discos de 5 1/4
con lo mejor de shareware de Windows

* DOS 5 Manual de usuario


Socha y 1 licks
Incluye 1 disco de 5 1/4 con-la edición
especial de Norton Corninander

* PC'S para inexpertos


Gookin y Rathbone

* Cómo usar Unix sistema V versión 4. ()


Stan KclIy-Bootle

* Cómo usar Excel 4 para Windows


Carl Townsend

* Microsoft Word 5 para Macintosh


Jimn lleid

* Manual de usuario Macintosh


Jirn Ileid
ADMINISTRACIÓN DE INGENIERÍA
DE SISTEMAS
UNIVERSIDAD CÉSAR VALLEJO LIMA NORTEl
BIBLIOTECA J

ADMINISTRACIÓN DE
INGENIERÍA DE SISTEMAS

BENJAMIN S. BLANCHARD
Virginia Polytechnic Institute & State University

MEGABYTE

GRUPO NORIEGA EDITORES


México . España. Venezuela Argentina
Colombia• Puerto Rico
'Versión autorizada en español dé la obr:'STE1'tENGINEERING MANAGEMENT
publicada en inglés por: © John Wiley & Sons Ltd. MCMXCI.

MEGABYTE es una marca registrada por Editorial Limusa, S.A. de C.V.


WILEY es una marca registrada por John Wiley & Sons Ltd.

Marcas registradas: A lo largo de toda la obra, MEGABYTE y WILEY hicieron todo lo


posible por diferenciar los nombres de marcas registradas de los términos
descriptivos usados en ella. Como es la costumbre, para hacerlo recurrieron al uso
de letras mayúsculas. MEGABYTE y WILEY no están afiliadas a ningún fabricante.

Se ha hecho todo lo posible por proporcionar información precisa y completa, no


obstante, MEGABYTE y WILEY no asumen ninguna responsabilidad por el uso de ésta,
ni por violaciones a la ley de derechos de autor sobre la propiedad intelectual en
que incurran terceras personas como resultado de dicho uso.

La presentación y disposición en (OflJUflt() de


ADMINISTRACIÓN DE INGENIERÍA DE SISTEMAS
son propiedad del editor. Ninguna parte de esta obra puede ser reproducida
o transmitida, mediante ningún sistema o método, electrónico o mecánico
(INCLUYENDO EL FOTOCOPIADO, la grabación o cualquier sistema
de recuperación y almacenamiento de información), sin consentimiento
por escrito del editor.

Derechos reservados:
MEGABYTE
UNIVERSIDAD CESAR
© 1993, EDITORIAL LIMUSA,S.A. (le C.V. VALLEJO
GRUPO NORIEGA EDITORES
Balderas 95, C.P. 06040, México, D.F. AJRLIOTEC'*
Teléfono: 521-50-98 CODIGO
Fax: 512-29-03

Miembro de la Cámara Nacional de la Industria


Editorial Mexicana. Registro número 121
N CF LIBRO: O2 3
Primera edición: 1993
Impreso en México FECHA: ffo 03
(11539)

ISBN 968-18-4527-7

ESTA OBRA SE TERMINO DE IMPRIMIR EL DIA 1 DE JULIO DE 1993


EN LOS TALLERES DE PROGRAMAS EDUCATIVOS
S.A. DE C.V. CHABACANO NÚM. 65 LOCAL "A
MÉXICO 8, D.F.

LA EDICIÓN CONSTA DE 3,000 EJEMPLARES


Y SOBRANTES PARA REPOSICIÓN

528
PRÓLOGO

Un libro escrito por un autor experimentado, que conoce su tema a profun-


didad, siempre es un placer leerlo y usarlo. Ben Blanchard conoce su tema.
Ha penetrado hasta la profundidad de la ingeniería de sistemas durante más
de tres decenios y quizá sea la persona más eminentemente calificada para
presentar la esencia de este conjunto de disciplinas, sumamente complejo,
en un solo volumen. Él lo ha realizado con estilo, dignidad y con un
meticuloso profesionalismo. Conduce al lector por entre el laberinto de las
habilidades, técnicas, procedimientos y métodos de la ingeniería requeri-
dos para establecer una organización de la ingeniería de sistemas y para
planear una actividad de la ingeniería de sistemas. Al reconocer que todos
los detalles no podrían cubrirse en un solo volumen, Blanchard muestra, en
generosas notas de pie y una amplia bibliografía de más de 200 publicacio-
nes, específicamente dónde es posible obtener respuestas detalladas.
Administración de ingeniería de sistemas es una adición indispensable en
la serie de Nuevas Dimensiones de la Ingeniería, puesto que se interrela-
cionan muchas de las disciplinas que ya serán exploradas por otros autores
en el transcurso de los meses, y puesto que se mantiene el estándar de
excelencia establecido por dicha serie y por John Wiley e hijos, desde hace
185 años.
Si usted es ingeniero, científico, administrador de nivel medio o estu-
diante de los proyectos multidisciplinarios de alta tecnología, encontrará
que el libro de Blanchard lo colocará en una posición sólida para "hablar el
lenguaje" de la ingeniería de sistemas, establecer metas y objetivos, trabajar
con fórmulas fundamentales, o establecer una organización o planteamien-
to de la ingeniería de sistemas.
Confiamos en que usted hallará que este libro es un compañero indis-
pensable cuando emprenda o dirija un proyecto extenso, multidisciplinario
y de alta tecnología.

RODNEY D. STEWART

Octubre de 1990
PREFACIO

Las tendencias actuales indican que, en general, la complejidad de los


sistemas se incrementa con la producción de nuevas tecnologías; la dura-
ción necesaria para desarrollar y crear un nuevo sistema se alarga y muchos
otros sistemas (o productos) actualmente en uso no cumplen las necesida-
des del consumidor, en términos de desempeño, calidad y costo-efectividad
global. Al mismo tiempo, hay un alto grado de cooperación e intercambio
internacional, y la competencia se incrementa a nivel internacional.
Cuando se evalúan las experiencias pasadas en cuanto al desarrollo de
los sistemas, la mayoría de los problemas observados han sido el resultado
directo de no aplicar el "enfoque de sistemas" a fin de cumplir los objetivos
deseados. El total de requerimientos para el sistema en cuestión no se
definió bien desde el inicio; la perspectiva en términos de cumplir una
necesidad del consumidor ha sido, relativamente, "a corto plazo" por
naturaleza; y, en muchos casos, el enfoque seguido ha sido "¡entregar ahora
y componerlo más tarde"! En esencia, el proceso de diseño y desarrollo del
sistema ha sufrido un tanto a causa de la falta de una buena planeación inicial
y de la definición posterior de los requerimientos de manera y com-
pleta y metódica. Esta filosofía global se ha hecho bastante costosa desde
la perspectiva de largo plazo.
La combinación de estos factores y los relacionados con ellos ha creado
una necesidad "crítica", es decir, el requerimiento de desarrollar y produ-
cir sistemas bien integrados, efectivos en costo, de alta calidad, con la
completa satisfacción del cliente como objetivo. En este ambiente alta-
mente competitivo y limitado en recursos, es más importante que nunca que
los conceptos de la "ingeniería de sistemas" se implementen en el diseño y el
desarrollo de los nuevos sistemas. Los requerimientos del sistema de-
ben definirse bien desde el inicio. El sistema debe ser visto en términos de
todos sus componentes, en una base integrada; por ejemplo, equipo esen-
cial, software, personal de operación, localidades, datos, los diversos
elementos de mantenimiento y soporte, los procesos de producción, etc.
Un enfoque integrado de arriba-abajo debe considerarse con la designación
adecuada de los requerimientos desde el nivel de sistema hacia abajo de sus
diversos elementos. Adicionalmente, los sistemas deben ser vistos en
términos del ciclo de vida completo; es decir, desde el diseño conceptual
hasta el diseño preliminar y de detalle, la producción y(o) la construcción,
el uso operacional, el soporte del producto y el retiro del sistema.
Estos conceptos no son necesariamente nuevos o novedosos. La inge-
niería de sistemas ha sido un tema de interés, desde finales de los cincuentas
y principios de los sesentas (y tal vez aun antes). Sin embargo, a causa de
las diversas desviaciones que, por una u otra razón, se han dado a través
de los años es apropiado revisar (y enfatizar) ¡algo de "las bases"!
Este texto se ha desarrollado con este objetivo en mente. Aunque es
imposible cubrir con profundidad el tema completo de la ingeniería de
sistemas, el autor ha intentado tratar algunos de los conceptos básicos,
destacando las metas específicas y los objetivos a través de la lectura de
este material. Más específicamente, el tema se introduce por medio de una
revisión de algunos términos y definiciones claves, en el capítulo 1. En él
se trata la necesidad de la ingeniería de sistemas y de sus aplicacaciones en
el ciclo de vida. Esto, a su vez, lleva a una presentación completa del "pro-
ceso de la ingeniería de sistemas", en el capítulo 2. Este proceso comien-
za con la identificación de una necesidad y se extiende hasta la definición de
los requerimientos del sistema, el análisis funcional y la asignación, la
síntesis y la optimización, el diseño, la prueba y evaluación, la producción,
la distribución para el uso del consumidor, el soporte del sistema y así
sucesivamente. Se estudian las áreas claves de relevancia para la ingeniería
de sistemas. Un entendimiento profundo de este proceso es fundamental al
tratar el área de este tema, y el material del capítulo 2 sirve como una base
para la discusión en los capítulos posteriores.
Dada la panorámica, es apropiado investigar a profundidad algunos
objetivos de la ingeniería de sistemas. Una meta incluye la integración de
una gran variedad de disciplinas de diseño clave al esfuerzo de la ingeniería
de diseño total. El capítulo 3 proporciona una introducción a algunas de
estas disciplinas (por ejemplo, la ingeniería de confiabilidad, la ingeniería
de mantenibilidad, los factores humanos, la seguridad, la ingeniería logística,
la ingeniería de software, la capacidad de producción, la ingeniería valor-
costo y la calidad) y describe la manera en que estas áreas interactúan en
el proceso de diseño. El capítulo 4 sigue con algunas discusiones en rela-
ción con las aplicaciones de las nuevas herramientas y los métodos de di-
seño, utilizados de una manera específica para facilitar la satisfacción de los
objetivos de la ingeniería de sistemas. La aplicación apropiada de los méto-
dos asistidos por computadora permite un análisis al inicio del proyecto,
conduciendo a una mejor definición del diseño en una etapa temprana del
ciclo de vida. El capítulo 5 proporciona las "verificaciones y balances" en el
proceso del diseño a través de la realización de la revisión del diseño,
evaluación, retroalimentación y control y de la iniciación de la acción
correctiva necesaria. Un objetivo de la ingeniería de sistemas es proporcio-
nar un fuerte rol del liderazgo de la ingeniería en relación con la definición
inicial de los requerimientos del sistema, la integración necesaria de las ac-
tividades del diseño para asegurar resultados efectivos y eficientes y las
funciones de medición y de evaluación con objeto de asegurar que los re-
querimientos inicialmente especificados para el sistema se han cumplido.
El siguiente paso es tratar los problemas de la administración rela-
tivos a los requerimientos de la ingeniería de sistemas aplicados a dife-
rentes proyectos. El capítulo 6 inicia con una profunda discusión de la
planeación y desarrollo del Plan de Administración de la Ingeniería de
Sistemas (SEMP). Se incluyen los trabajos de la ingeniería de sistemas, el
desarrollo de una estructura de descomposición de trabajo (WBS), los
planes del programa y las proyecciones del costo. El capítulo 7 se ocupa de
la ingeniería de sistemas en la típica estructura organizacional del proyecto,
destacando las diferencias entre los planteamientos organizacionales de
línea de producto y matricial, y cubre las interfaces entre el cliente, el
productor (contratista) y el proveedor. Finalmente, el capítulo 8 presenta
una idea general de los métodos de contratación, de las negociaciones y del
manejo del proveedor.
En resumen, el texto intenta describir la ingeniería de sistemas en
términos de sus objetivos y aplicaciones durante el proceso de desarrollo.
¡Se proporciona una perspectiva de la administración como ayuda para la
implementación de los programas que incluyen el impulso de la ingenie-
ría de sistemas! Esto es un texto introductorio, desarrollado con la esperan-
za de proporcionar al lector muchas nuevas y útiles ideas.

BENJAMIN S. BL.NCHARD

Virginia Polytechnic Institute & State Universily


Noviembre de 1990
CONTENIDO

1 Introducción a la Ingeniería de sistemas 19


1.1. El ambiente 19
1.1.1 El ciclo de vida del sistema 21
1.1.2 Costo-efectividad del sistema 23
1.1.3 Creación de un sistema 27
1.2 La necesidad de la ingeniería de sistemas 28
1.2.1 Jnidón de un sistema 28
1.2.2 Categorías de sistemas 30
1.2.3 Ingeniería de sistemas 31
1.2.4 Ciencia de sistemas 33
1.2.5 Análisis de sistemas 33
1.2.6 Ingeniería de sistemas en el ciclo de vida 34
1.3 Administración de la ingeniería de sistemas 38
1.4 Términos relacionados y definiciones 39
1.5 Resumen 40
Preguntas y problemas 40

2 El proceso de Ingeniería de sistemas 43


2.1 Identificación de la necesidad 43
2.2 Análisis de factibilidad del sistema 44
2.3 Requerimientos operacionales del sistema 46
2.4 El concepto de mantenimiento y soporte 49
2.5 Análisis funcional 57
2.5.1 Diagramas de flujo funcionales 61
2.5.2 Funciones operacionales 63
12

2.5.3 Funciones de mantenimiento 63


2.5.4 Aplicación de los diagramas de flujo funcionales 64
2.6 Requerimientos de asignación 67
2.7 Síntesis, análisis y optimización del diseño del sistema 69
2.8 Prueba y evaluación 78
2.8.1 Categorías de prueba y evaluación 80
2.8.2 Planeación de pruebas 82
2.8.3 Preparación para la evaluación y prueba del sistema 83
2.8.4 Desempeño y evaluación de la prueba 85
2.8.5 Modificaciones del sistema 87
2.9 Producción y (o) construcción 88
2.10 Uso operacional del sistema y apoyo de soporte 88
2.11 Retiro y desecho del sistema 89
2.12 Resumen 89
Preguntas y problemas 90

3 Requerimientos del diseño de sistemas 93


3.1 Desarrollo de especificaciones y criterios 94
3.2 Disciplinas de ingeniería del diseño 99
3.2.1 Ingeniería de confiabilidad 105
3.2.2 Ingeniería de mantenibilidad 120
3.2.3 Ingeniería de factores humanos 135
3.2.4 Ingeniería de seguridad 143
3.2.5 Ingeniería logística 146
3.2.6 Ingeniería de software 155
3.2.7 Ingeniería de la capacidad de producción 158
3.2.8 Ingeniería de calidad 162
3.2.9 Ingeniería valor/costo 166
3.3 Resumen 172
Preguntas y problemas 173

4 Métodos y herramientas de la Ingeniería de diseño 179


4.1 Prácticas convencionales de diseño 180
13

4.2 Nuevas tecnologías y herramientas de diseño 183


4.3 Diseño asistido por computadora (CAD) 188
4.4 Manufactura asistida por computadora (CAM) 201
4.5 Aquisición y soporte logístico asistido por computadora
(CALS) 202
4.6 Resumen 205
Preguntas y problemas 206

5 Revisión y evaluación del diseño 209


5.1 Requerimientos de revisión y evaluación del diseño 210
5.2 Revisión informal día por día y evaluación 214
5.3 Revisiones del diseño formal 217
5.3.1 Revisión del diseño conceptual 222
5.3.2 Revisiones del diseño del sistema 224
5.3.3 Revisiones de diseño del equipo-software 225
5.3.4 Revisión crítica del diseño 225
5.4 El cambio de diseño y el proceso de modificación 227
5.5 Resumen 232
Preguntas y problemas 233

6 Planeación de la ingeniería de sistemas 235


6.1 Requerimientos del programa de ingeniería de sistemas 237
6.1.1 La necesidad de planeación inicial del sistema 237
6.1.2 Determinación de los requerimientos del programa 238
6.2 Plan de administración de la ingeniería de sistemas (SEMP) 241
6.2.1 Descripción del trabajo (SOW) 243
6.2.2 Definición de las funciones y trabajos de la ingeniería
de sistemas 246
6.2.3 Desarrollo de una estructura de descomposición del
trabajo (WBS) 207
6.2.4 Árbol de especificaciones-documentación 264
6.2.5 Desarrollo de los planes del programa- 267
6.2.6 Preparación de las proyecciones del costo del programa 282
6.2.7 Requerimientos de reporte del programa— 286
6.3 Integración de los planes de la especialidad del diseño
individual 290
14

6.4 Interfaces con otras actividades de planeación


del programa 292
6.5 Plan de administración de riesgo 293
6.6 Resumen 298
Preguntas y problemas 300

7 Organización para la Ingeniería de sistemas 303


7.1 Relaciones consumidor, productor y proveedor 304
7.2 Organización del consumidor y funciones (el "cliente") 306
7.3 Organización del productor y funciones (el "contratista") 307
7.3.1 Estructura funcional de la organización 309
7.3.2 Estructura de organización de la línea del
producto-proyecto 313
7.3.3 Estructura de una organización matricial 315
7.3.4 Organización de la ingeniería de sistemas 319
7.4 Organización y funciones del proveedor 328
7.5 Requerimientos de los recursos humanos 332
7.5.1 Ambiente organizacional 333
7.5.2 Características de liderazgo 335
7.5.3 Las necesidades de los individuos 337
7.5.4 La organización del personal 341
7.5.5 Desarrollo del personal 344
Preguntas y problemas 345

8 Contratación y administración de proveedores 349


8.1 Requerimientos del programa 350
8.2 Propuestas y selección del proveedor 352
8.2.1 Preparación de la solicitud para una propuesta (RFP) 352
8.2.2 Desarrollo de las propuestas del proveedor 354
8.2.3 Evaluación y selección de los proveedores 355
8.3 Negociaciones contractuales 361
8.4 Monitoreo y control del proveedor 368
8.5 Integración del sistema 371
Preguntas y problemas 375
15

Apéndice A qemplos de casos de estudio 379


Apéndice B lista de revisión del diseño 407
Apéndice C Glosario de los términos seleccionados 437
Apéndice D Bibliografía 447
Indice 463
ADMINISTRACIÓN DE INGENIERÍA
DE SISTEMAS
1
INTRODUCCIÓN A LA INGENIERÍA
DE SISTEMAS

Este texto se ocupa de "la ingeniería de sistemas", o del proceso ordenado


de crear un sistema desde el inicio. Un sistema está constituido por una
combinación compleja de recursos (en forma de recursos humanos, mate-
riales, equipo, software, facilidades, datos, etc.), integrados de tal manera
que satisfacen una necesidad determinada. Un sistema se desarrolla para
llevar a cabo una función específica, y puede clasificarse como un sistema
natural, un sistema hecho por el hombre, un sistema físico, un sistema con-
ceptual, un sistema cerrado, un sistema de lazo abierto, un sistema estático,
un sistema dinámico y así sucesivamente.
Un sistema puede variar de forma, tipo y (o) función. Puede realizarse
con un grupo de aviones que llevan a cabo una misión en un lugar geográfico
específico; con una red de comunicación que distribuye información alrede-
dor del mundo; con una capacidad de distribución de energía que involucra
vías fluviales y unidades generadoras de energía eléctrica; con una facilidad
de manufactura que produce equis productos en un período determinado,
o con un pequeño vehículo que provee la transportación de cierta carga de
un lugar a otro. Un sistema puede estar separado en subsistemas y en varios
componentes más pequeños: el nivel del detalle depende de la función que
se habrá de realizar.
El propósito de este capítulo es tratar el tema de los "sistemas" en
general, precisar algunos términos y définiciones, así como sus caracterís-
ticas, identificar la necesidad y los requerimientos básicos para crearlos
y proveer una introducción a la ingeniería de sistemas y administración
de actividades inherentes al proceso de ingeniería de sistemas.

1.1 EL AMBIENTE

Muchos sistemas usados actualmente no cumplen las necesidades del


consumidor. La calidad es pobre, las características de desempeño y de
20 INTRODUCCIÓN A LA INGENIERÍA DE SISTEMAS

efectividad están por debajo de lo esperado y el costo global es muy alto.


Al mismo tiempo, la complejidad del sistema se incrementa en tanto los
recursos disponibles decrecen. En esencia, hay muchas presiones y el
ambiente expresado en la figura 1.1 es representativo de estos tiempos.
En vista de las tendencias globales, ilustradas en la figura, se prevén
algunos retos mayores, en términos de dar soporte a los sistemas ya exis-
tentes y en la consecución y creación de nuevos sistemas. Más espe-
cíficamente, se observan los puntos siguientes:

1Los sistemas deben verse en términos de su ciclo de vida completo:


las fases del diseño y desarrollo, producción y (o) construcción, operación
(utilización), mantenimiento y soporte así como retiro y desechq Las dife-
rentes fases del ciclo de vida están interrelacionadas, influyen las unas en
las otras y necesitan tratarse en conjuntcSe debe considrar un enfoque a
largo plazo, en oposición al pensamiento a corto plazo del pasado.
2. El valor último de un sistema debe relacionarse directamente con
el grado de satisfacción del cliente y expresado en términos de una medida
de "efectividad de costos". El aspecto del costo debe verse con base en el
ciclo de vida global del sistema y la efectividad debe considerar factores
como el desempeño, la disponibilidad, la dependencia, la confiabilidad,

Política mayor,
economía, social e
influencias relacionadas

Aplicación de
nuevas tecnolo- Limftaciones humanas
gías y complejida Sistemas y
des del sistema recursos materiales
incrementadas )

Mayor integración
internacional
(globalización)

Figura 1.1. El ambiente de hoy.


EL AMBIENTE 21

la capacidad de mantenimiento, la soportabiliclad, la producibilidad y la


calidad. Concentrarse únicamente en el aspecto del "desempeño" —una
práctica predominante en el pasado—, resulta limitante en extremo, si se
consideran todos los componentes del sistema y las características muy
diferentes del diseño. Hay diversas medidas que pueden ser aplicables al
sistema y, las que se refieren a los aspectos de costo y calidad total, no se
consideraron adecuadamente en el pasado.
3. El proceso y los métodos utilizados en la consecución y creación de
los sistemas debe ser tal que los sistemas puedan: a) crearse de una manera
oportuna y más expedita, b) diseñarse y desarrollarse tan efectiva y efi-
cientemente como sea posible, considerando la limitante de los recursos
disponibles. Una combinación de los procedimientos adecuados del diseño,
la aplicación adecuada de técnicas de diseño computarizadas, la integra-
ción necesaria y las actividades de diseño, la modernización indispensable
de prácticas de consecución, etc., acelerarán con optimismo la elabora-
ción de un producto de alta calidad, en un período más corto. En años recien-
tes, tanto los tiempos de creación de un sistema como los costos asociados
se han incrementado, mientras la competencia ha crecido rápidamente
y a nivel mundial.

Aunque hay muchos aspectos específicos que se deben tratar, estos


asuntos principales necesitan cubrirse inicialmente. En general, son enfáti-
cos en el planteamiento de un ciclo de vida global, el diseño y desarrollo de
sistemas con la consideración de la evaluación total (por ejemplo, calidad
y costo) y la renovación del proceso de creación del sistema requerirá algún
ajuste relativo a nuestra cultura, a nuestra mentalidad individual, a nuestros
procesos presupuestales y, en general, a nuestra manera de hacer nego-
cios. Sin embargo, este ajuste es necesario en el ambiente de hoy. La siguien-
te sección proporciona información adicional en apoyo a estos asuntos
principales.

1.1.1 El ciclo de vida del sistema

El ciclo de vida se refiere al espectro completo de actividades de un sistema


dado, comenzando con la identificación de una necesidad y extendiéndose
hasta el diseño y desarrollo del sistema, producción y (o) construcción, uso
operacional, apoyo de soporte, y retiro y deshecho del sistema. Como las
actividades de cada fase interactúan significativamente con las activida-
des de otras fases, es esencial que se considere el ciclo de vida global cuando
se tratan asuntos a nivel sistema.
Las fases específicas del ciclo de vida (y la duración de cada una) pueden
variar dependiendo de la naturaleza, complejidad y propósito del sistema.
Las necesidades pueden cambiar, puede ocurrir la obsolescencia y los
22 INTRODUCCIÓN A LA INGENIERÍA DE SISTEMAS

Ciclo de vida de un sistema - - - - Ejemplo A"

1 Diseño Diseño de delate


Diseño Producción Funcionamiento del sistema Retiro
preliminar y
conceptual (uso del consumidor) del sistema
M sistema desarrollo

Diseno Utilización

- Capacidad de soporte desistema


Utilización (mantenimiento del consumidor)

Ciclo de vida del sistema—Ejemplo B

1 Diseño de delate 1
DiseñoDiseño
conceptual
1 preliminar
1del sistema i
y
desarroflo
1 Construcción de
maquinaria tísica
1 Operaciones de producción
(uso operacional del sistema) Retiro

- --- - —r -Capacidad
-
de soporte del sistema
.r - -

Figura 1.2. Ciclo de vida de un sistema (ejemplos).

niveles de actividad pueden ser diferentes dependiendo tanto del tipo de sis-
tema como de dónde se encuentre en la estructura jerárquica global de
actividades y eventos.
En general, el ciclo de vida para la mayoría de los sistemas cumple con
la ilustración de la figura 1.2. Al referirse a la figura, un aeroplano, un
vehículo de transportación terrestre o un mecanismo electrónico puede
progresar mediante el diseño conceptual, el diseño preliminar, el diseño de
detalle, de producción, etc., como se refleja a través de la serie de activi-
dades del ejemplo "A". Cuando se evalúa este ejemplo más adelante, el
renglón de arriba de las actividades es aplicable a estos elementos del
sistema que se relacionan directamente para llevar a cabo una misión (por
ejemplo, un conjunto de radares). Al mismo tiempo, hay dos ciclos de vida
de actividad fuertemente relacionados que deben considerase. El diseño,
construcción y operación de la capacidad de producción, que tiene un
efecto significativo en las operaciones de los elementos primarios del
sistema, también deben tratarse, junto con el mantenimiento del sistema
y la actividad de soporte. Más adelante, estas actividades deben tratarse
inicialmente durante el diseño conceptual y preliminar de estos elementos
primarios del sistema, representados en el primer renglón de la figura.
Aunque todas estas actividades pueden presentarse por medio de un flujo
sencillo ilustrado (que es el enfoque general usado en subsecuentes capítu-
los de este texto), la partición de aquí está ilustrada para enfatizar la
EL AMBIENTE 23

importancia de tratar cada uno de los aspectos del proceso total del sistema
y las diversas interacciones que pudiesen ocurrir.
El ejemplo "B", en la figura 1.2, se presenta para cubrir las fases más
importantes asociadas con la capacidad de producción, una planta de
procesamiento o la capacidad de seguimiento terrestre de un satélite,
donde se requiere la construcción de una configuración "uno-en-su-tipo" del
sistema. Nuevamente, la capacidad de mantenimiento y de soporte se
identifica por separado a fin de indicar el grado de importancia y para
sugerir que hay efectos de interacción que necesitan considerarse.
Aunque puede haber variantes en los enfoques, la nomenclatura usada,
la duración de diferentes bases, etc., aún es adecuado que los sistemas se
visualicen en términos de sus respectivos ciclos de vida. El pasado está
repleto de ejemplos en los cuales las decisiones más importantes han sido
hechas considerando únicamente las etapas iniciales de la creación del
sistema, que son: diseño y desarrollo. En otras palabras, en el diseño y desa-
rrollo de un nuevo sistema, la consideración para la producción o el soporte
de este sistema ¡fueron inadecuados! Estas actividades fueron consideradas
más tarde y, en muchos casos, la consecuencia de este planteamiento
"a posteriori" fue costosa. Estas experiencias pasadas y la importancia de
las consideraciones del ciclo de vida en el futuro se tratan extensamente a
lo largo de las secciones subsecuentes de este texto.

1.1.2 Costo-efectividad del sistema

Al medir y(o) calcular el valor global de un sistema, se debe considerar tan-


to las características técnicas del sistema como su costo. Las característi-
cas técnicas incluyen factores como el desempeño, el tamaño y el peso, la
capacidad, rapidez, rango, disponibilidad, dependencia, confiabilidad
y mantenibilidad, soportabilidad, producibilidad y calidad, combinados de
alguna manera para proporcionar una medida de "efectividad del sistema".
El otro fin del espectro es la consideración para "el costo del ciclo de vida"
(LCC): el costo total asociado con todas las actividades distribuidas en el
ciclo de vida del sistema ilustrado en la figura 1.2. Esto incluye: los costos
de investigación, diseño, desarrollo, producción y(o) construcción, distri-
bución, operación del sistema (utilización), apoyo de mantenimiento y so-
porte, retiro y desecho del sistema. Los costos del ciclo de vida pueden
jerarquizarse de muy diversas maneras, dependiendo del tipo de sistema
y la sensibilidad deseada al desarrollar una medición de costo-efectividad.
Un objetivo en el diseño y desarrollo del sistema es proporcionar un balance
adecuado entre la efectividad del sistema y el costo del ciclo de vida, como
se muestra en la figura 1.3.'
Para mayor información sobre términos y definiciones en esta área, véase B. Blanchard y W.
Fabrycky, Systems Engineering and Analysis, 2' ed., Prentice-Hall, Englewood Cliffs, Ni., 1990;
y B. Blanchard, Logistics Engineering and Management. 4' ed., Prentice-Hall, Englewood cliffs,
Ni., 1991.
24 INTRODUCCIÓN A LA INGENIERÍA DE SISTEMAS

1 Costo-efectividad 1

Costo de ciclo de vida 1 1 Efectividad del sistema

•Costo de investigación y desarrollo • Desempeño del sistema


•Costo de producción-construcción • Disponibilidad
•Costo de operación y mantenimiento • Dependencia
•Costo del retiro y desecho del sistema • Otros parámetros técnicos

t
tnbutoesenodekism
— L- - - - - - - - - - -
- - lemeopoedele
t
----

Figura 1.3. Los elementos básicos de efectividad.

Al referirse a la figura 1.3, el balance adecuado entre la efectividad y el


costo debe establecerse por medio del diseño del sistema. Estos factores
dependen altamente de los atributos o características de diseño (por
ejemplo, factores de confiabilidad y factores de mantenibilidad). Basados
en una configuración de un diseño dado, los requerimientos de soporte

Figura 1.4. El desequilibrio entre el costo del sistema y los factores de efectividad.
EL AMBIENTE 25

Mala administración
Costo de creación
(investigación, diseño, prueba,
producción, construcción)

Costo de operaciones
(1,instalacmnes,stitdes7" Costo de la distribución
del producto (transportación,
tráfico y manejo de material)

Costo de mantenimiento Prueba y costo del


(Servicio al cliente, carro, proveedor Costo de entrenamiento
equipo de soporte
de mantenimiento de la fábrica)
d (entrenamient del perador
del mantenimiento)

del soporte del proveedor


Costo de los datos (excedentes, Inventario
Costo de soare técnicos Y material de soporte)
(software de operación
y mantenimiento)

Costo de retiro
y desecho

Figura 1.5. Visibilidad del costo total.

logístico para un sistema pueden definirse y desarrollarse. Estos tienen un


efecto de retroalimentación sobre los atributos del diseño, y también afec-
tan sensiblemente las medidas de la efectividad del sistema y el costo del
ciclo de vida. En esencia, es grande la interacción de los elementos ilustra-
dos en esta figura.
Mientras el objetivo es crear la relación adecuada entre alguna medida
de efectividad y el costo, la tendencia en años recientes ha provocado que
no haya balance entre los dos, como se muestra en la figura 1.4. La com-
plejidad de muchos sistemas se ha incrementado, inicialmente debido al
advenimiento de las nuevas tecnologías en el diseño. Al mismo tiempo, con
el siempre creciente énfasis puesto ene! "desempeño ", en sacrificio de otros
parámetros claves de diseño tales como confiabilidad y calidad, la efectivi-
dad global de estos sistemas ha ido decreciendo y los costos han seguido
creciendo. Esto sucede al mismo tiempo que la competencia se incrementa,
que hay un grado mayor de cooperación internacional e intercambio y que
los requerimientos para producir un sistema bien integrado, efectivo en
costo y de alta calidad son aún mayores que en el pasado.
Cuando se trata el aspecto económico, a menudo se encuentra que hay
una carencia de visibilidad del costo total, como se proyectó en "el efecto de
26 INTRODUCCIÓN A LA INGENIERÍA DE SISTEMAS

Oportunidad para ahorrar costos en el ciclo de vida


100%

co /
:2
' Costo del ciclo de vida 1 /
.2 acumulativo (proyectado)
1,
.2
8
Ak
50%
j id /
Desembolso
actual
(proyectado)

/ 1
Diseño del concepto
Diseño preliminar Diseño detallado del Producción y (o)
del sistema sistema y desarrollo construcción
laneación de avance
___________________________

Figura 1.6. Compromiso del costo del ciclo de vida.

iceberg" ilustrado en la figura I.S. Los costos del diseño y desarrollo son
relativamente bien conocidos para muchos sistemas; no obstante, los cos-
tos asociados al funcionamiento y soporte del sistema están ligeramente
ocultos. En esencia, la comunidad encargada del diseño ha sido afortunada
al tratar con los aspectos del costo a corto plazo, pero no ha sido muy sen-
sible a los efectos a largo plazo. Al mismo tiempo, la experiencia ha indicado
que una gran parte del costo del ciclo de vida de un sistema dado se atribuye
a las actividades de operación y soporte (arriba del 75% del costo total,
por ejemplo).
Adicionalmente, cuando se observan las relaciones "causa y efecto",
uno encuentra que una porción grande del costo del ciclo de vida proyecta-
do para un sistema es la consecuencia de decisiones tomadas durante las
primeras fases de planeación avanzada y diseño conceptual del sistema.
Estas decisiones relacionan los requerimientos operacionales (esto es, el
número de lugares seleccionados por el consumidor), políticas de manteni-
miento y soporte (dos niveles contra tres niveles de mantenimiento),
asignaciones asociadas a las aplicaciones manuales contra las aplicaciones
automáticas, esquemas de empaque de equipo, rutinas de diagnóstico, nivel
de conceptos de reparación, etc. Las decisiones tomadas durante las
principales fases del desarrollo del sistema tienen una gran influencia en el
costo total del ciclo de vida, como se expresa en la figura 1.6.
Al referirse a la figura, hay tres proyecciones distintas presentadas de
una manera genérica, que puede variar con el sistema en cuestión. Aunque
EL AMBIENTE 27

los gastos actuales de un proyecto dado se acumularan lentamente al


principio, aumentando durante fases tardías del diseño y en la producción,
el compromiso del costo del ciclo de vida será más grande durante las
primeras etapas del desarrollo del sistema. El ejemplo presentado en la
figura indica que aproximadamente 60% del costo proyectado del ciclo de
vida está "definido" al término de la fase del diseño conceptual. Así, la
oportunidad de ahorro en el costo total es la más grande durante estas
etapas iniciales del desarrollo del sistema.
Considerando estas tendencias del pasado y las relaciones que existen
entre las características del sistema y las diversas fases de actividad, es
imperativo 1) que el diseño del sistema futuro ylos esfuerzos de desarrollo
consideren la efectividad global de un sistema relacionado con una necesi-
dad específica del consumidor, y 2) que estos requerimientos del sistema
sean visualizados usando un enfoque del ciclo de vida.

1. 1.3 Creación de un sistema

La creación de un sistema se refiere al proceso de adquirir un sistema para


uso del consumidor., o al proceso de crear un sistema. Incluye la definición
inicial de los requerimientos del sistema (por ejemplo, llevar a cabo los
estudios de factibilidad, los requerimientos operacionales del sistema y el
concepto de mantenimiento), el análisis funcional y los requerimientos de
asignación, el llevar a cabo estudios de compromisos, el diseño de detalle,
prueba y evaluación, producción y (o) construcción, distribución e instala-
ción del sistema para uso del consumidor. Eso involucra las actividades
reflejadas en los cuatro primeros bloques del diagrama de flujo de los
ejemplos "A" y "B" de la figura 1.2.
Cuando los requerimientos del sistema son definidos inicialmente en
respuesta a una necesidad identificada del consumidor, el objetivo es
desarrollar y producir (o construir) una configuración que llevará a cabo las
funciones tal y como se definieron/Este proceso de traducir estos requeri-
mientos especificados inicialmente a una entidad funcional debe completar-
se no sólo de manera oportuna, sino también debe llevarse a cabo efectiva
y eficientemente.
En otras palabras, dada una necesidad definida, un sistema debe de-
sarrollarse expedita y económicamente e incorporar las características
esenciales de desempeño, efectividad ycalidadisto se lleva a cabo median-
te la aplicación adecuada de métodos de diseño con el estado del arte, la
integración oportuna de disciplinas de diseño adecuadas, la habilitación
optimista de prácticas de consecución expeditas, etcétera.
En el ámbito actual, no sólo la complejidad de muchos sistemas se ha
incrementado, sino que, en el intento de cumplir con planificaciones muy
estrechas: ¡los sistemas a menudo son entregados en un estado "inoperan-
28 INTRODUCCIÓN A LA INGENIERÍA DE SISTEMAS

te"! El nivel adecuado de integración del sistema no se cumple y cuando son


entregados, varios elementos del sistema no son compatibles. Como resul-
tado, hay a menudo muchas modificaciones, de trabajo y actividad de prue-
ba realizada río abajo durante el ciclo de vida a fin de lograr que el sistema
funcione adecuadamente. Este planteamiento "a posteriori" para la integra-
ción del sistema puede conducir a muchos gastos y a un alto costo.
Como punto adicional, para muchos sistemas de gran tamaño hay un
gran número y una gran variedad de proveedores involucrados en el pro-
ceso de creaciónj La tendencia actual hacia el intercambio internacional
(esto es, la globalización) indica que tos requerimientos del proveedor para
programas en el futuro se incrementará. Esto evidentemente subrayará más
adelante la necesidad de un proceso de ingeniería de sistemas bien planea-
do, estrechamente integrado. En esencia, el proceso de creación actual ne-
cesita una renovación a fin de que sea sensible a los requerimientos futuros
del sistema.

1.2 LA NECESIDAD DE lA INGENIERÍA DE SISTEMAS

Las tendencias y conceptos expuestos en la sección anterior representan


apenas un ejemplo de algunos asuntos de importancia que se deben tratar.
En esencia, la meta es ser más efectivo y eficiente en el desarrollo y creación
de los nuevos sistemas, así como también en la operación, mantenimiento
y soporte de los sistemas ya existentes.
Al tratar temas tales como "istema", "ingeniería de sistemas" y simi-
lares, uno encontrará que existe una gran variedad de enfoques. Aquí, se
trata de una función de antecedentes individuales y los intereses or-
ganizacionales de practicantes de este campo. Más adelante, cuando se
investiga en la literatura acerca de esos temas, las definiciones empleadas
son bastante diferentes., Así, con el objetivo de proporcionar una aclara-
ción relativa al material presentado, incluso en este texto, parece adecua-
do dirigir la atención hacia unos cuantos conceptos y definiciones claves.
Los términos adicionales son introducidos en los capítulos siguientes.

1.2.1 Definición de un sistema

El término "sistema" proviene de la palabra griega 'systma", que significa


un todo organizador. El diccionario Webster define un sistema "como un
agregado o ensamblado de objetos unidos por alguna forma de interacción
regular o interdependencia; un grupo de unidades diversas combinadas por
la naturaleza o la técnica para formar un todo integral y que funciona, opera

2
La bibliografía presentada en el apéndice D Incluye una variedad de publicaciones de
Ingeniería de sistemas y áreas afines.
LA NECESIDAD DE LA INGENIERÍA DE SISTEMAS 29

o se mueve al unísono y, a menudo, conforme a algún tipo de control; un


conjunto orgánico u organizado".4n esencia, un sistema está constituido
por un conjunto de componentes interrelacionados que funcionan juntos
con el objetivo común de satisfacer una necesidad dada. /
Mientras esto refleja una buena panorámica inicial, se requiere un alto
grado de detalle y precisión para proporcionar una definición aceptable
para describir los conceptos de la ingeniería de sistemas en este texto. Para
facilitar este objetivo, un sistema puede definirse más adelante en términos
de las características generales siguientes:

1 .Un sistema constituye una combinación compleja de recursosén forma


de seres humanos, materiales, equipo, software, facilidades, datos, dinero,
etc. Para llevar a cabo muchas funciones, con frecuencia se requiere una
gran cantidad de personal, equipo, recursos y datos (por ejemplo, para
una línea aérea o instalación manufacturera). Tales recursos deben combi-
narse de manera efectiva ya que es muy arriesgado dejar esto a la proba-
bilidad.
2. Un sistema está contenido dentro de algún tipo de jerarquki.Un aero-
plano puede incluirse en una aerolínea, que es parte de una capacidad global
de transportación, que se opera en un ambiente geográfico específico, que
es parte del mundo, etc. Así, el sistema tratado es influido altamente por el
desempeño del sistema de más alto nivel y estos factores externos deben
evaluarse.
3. Un sistema puede dividirse en subsistemas y componentes relaciona-
dos: el grado de la división dé0éñdd1rinplejidad y las funciones que
son desempeñadas. Dividir el sistema en unidades más pequeñas que per-
ipitan un enfoque más simple relativa a la distribución inicial de reque-
rimientos y el subsecuente análisis del sistema y sus interfaces funcionales.
El sistema está conformado por muy diversos ccunporiees, los cuales
interactúan entre sí y estas interacciones deben entenderse a fondo por el
diseñador del sistema y (o) el analista. A causa de estas interacciones en-
tre componentes, es imposible producir un diseño efectivo si se considera
cada componente por separado. Se debe visualizar el sistema como un con-.
junto, separarlo en componentes, estudiar estos y sus interrelaciones y lue-
go volver a poner el sistema junto.
4. El sistema debe tener un propósito. Debe ser funcional, capaz de res-
ponder a una necesidad identificada y de alcanzar el objetivo global de
manera efectiva en cuanto a costos. Puede haber un conflicto de objetivos,
influido por el sistema de más alto nivel en la jerarquía y el sistema debe ser
capaz de cumplir el propósito indicado de la mejor manera posible.

International Dictionaiy of the English Larzguage de Webster, 3ra edición, G.& C. Merrlarn
Company, Springfield. MA., 1961.
30 INTRODUCCIóN A LA INGENIERÍA DE SISTEMAS

1.2.2 Categorías de sistemas

Cuando se define a los sistemas en términos de las características generales


presentadas, en seguida se hace evidente que un mayor grado de clasifica-
ción es deseable. Hay muchos tipos diferentes de sistemas y también algu-
nas dicotomías en términos de semejanza y diferencias. Para proporcionar
una idea de la variedad de sistemas que existe, se da una lista parcial de
categorías.

Sistemas naturales y hechos por el hombre. Los sistemas naturales in-


cluyen lo que llega a existir a través de procesos naturales. Los ejemplos
pueden incluir desde un sistema de ríos hasta un sistema de energía. Los sis-
temas hechos por el hombre son aquellos que han sido desarrollados por
seres humanos, resultado de la inclusión de una gran variedad de capa-
cidades. Como todos los sistemas hechos por el hombre están insertos
en el mundo natural, hay numerosas interfaces que deben examinarse.
Por ejemplo, el desarrollo y construcción de un sistema de energía hidro-
eléctrica, localizado en un sistema de ríos, crea efectos sobre ambos lados
del espectro y es esencial que el enfoque de sistemas involucre a los seg-
mentos naturales y a los segmentos hechos por el hombre para implementar
toda la capacidad.

Sistemas físicos y conceptuales. Los sistemas físicos son aquellos forma-


dos por componentes reales que ocupan un espacio. Por otra parte, los sis-
temas conceptuales conforman una organización de ideas, un conjunto de
especificaciones y planes, una serie de conceptos abstractos, etc. Los sis-
temas conceptuales con cierta frecuencia llevan directamente al desarro-
llo de sistemas físicos y hay un cierto grado de semejanza en términos del
tipo de procesos empleados. Nuevamente, las interfaces pueden ser mu-
chas y hay necesidad de tratar estos elementos ene! contexto de un sistema
de más alto nivel en la jerarquía global.

Sistemas estáticos y dinámicos. Los sistemas estáticos incluyen aque-


llos que tienen estructura, pero sin actividad (visualizados en un período
relativamente corto). Un puente de una carretera y un almacén son ejem-
plos. Un sistema dinámico ese! que combina los componentes estructurales
con actividad. Un ejemplo es una capacidad de producción que combina una
instalación de manufactura, un equipo capital, utilidades, transportadores,
trabajadores, vehículos de transportación, datos, software, administrado-
res, etc. Aunque puede haber puntos específicos en el momento en que
todos los componentes del sistema son estáticos por naturaleza, la reali-

Esta categorización sigue al formato general presentado en Systems Engineering andAnalysis,


2da edición, Prentice-Hall, Englewood Cliffs, Ni, 1990 de B. Blanchard y W. Fabrycky. Estas
categorías representan sólo pocas de aquellas que pueden ser descritas.
LA NECESIDAD DE LA INGENIERIÁ DE SISTEMAS 31

zación exitosa de los objetivos del sistema requiere actividad y los aspectos
dinámicos de la operación del sistema prevalecen en todo un escenario de-
terminado.

Sistemas cerrados yde lazo abierto. Un sistema cerrado es autocontenido


y no interactúa de manera significativa con su ambiente. El ambiente
proporciona el medio en que el sistema opera; no obstante, el impacto es
mínimo. Un proceso de equilibrio químico y un circuito eléçtrico (con una
retroalimentación incorporada y un lazo de control) son ejemplos. A la
inversa, los sistemas de lazo abierto interactúan con su ambiente. Los lí-
mites son traspasados (aun el flujo de información, energía y [o] materia)
y haynumerosas interacciones entre los diversos componentes del sistema,
arriba y abajo de la estructura jerárquica del sistema global. Una capacidad
de soporte logístico sistema/producto es un ejemplo.
La presentación de estas categorías está incluida para estimular una
mayor reflexión acerca de la definición de un sistema. No es fácil clasificar
un sistema como abierto o cerrado y las relaciones precisas entre los
sistemas naturales y los sistemas hechos por el hombre pueden no estar
bien definidas. No obstante, el objetivo aquí es alcanzar una apreciación más
grande de las muy diversas consideraciones requeridas al ocuparse de la
ingeniería de sistemas y sus procesos. El énfasis en este texto tiende a favo-
recer los sistemas hechos por el hombre, que son físicos por naturaleza,
dinámicos al operarios y de la variedad de lazo abierto.

1.2.3 Ingeniería de sistemas

Definida generalmente, la ingeniería de sistemas es "la aplicación efectiva de


esfuerzos científicos e ingenieriles de transformar una necesidad operacional
en una configuración de un sistema definido mediante el proceso iterativo
de arriba-abajo en la definición de requerimientos, análisis funcional, sínte-
sis, optimización, diseño, prueba y evaluación". El proceso de la ingeniería
de sistemas, en su desarrollo de requerimientos de detalle funcionales
y requerimientos de diseño, tiene como meta la realización del balance
adecuado entre los factores operacionales (por ejemplo, desempeño), eco-
nómicos y logísticos.
El Departamento de Defensa (DOD) define la ingeniería de sistemas
como "la aplicación de los esfuerzos científicos e ingenieriles a fin de: 1)
transformar una necesidad operacional en una descripción de paráme-
tros de desempeño del sistema y una configuración del sistema a través del
uso de un proceso iterativo de definición, síntesis, análisis, diseño, prueba
y evaluación; 2) integrar parámetros técnicos relacionados y asegurar
la compatibilidad de todas las interfaces físicas, funcionales y de programa
a fin de optimizar la definición total del sistema y el diseño; y 3) integrar los
factores de confiabilidad, mantenibilidad, seguridad, supervivencia, huma-
32 INTRODUCCIÓN A LA INGENIERÍA DE SISTEMAS

nos y otros factores en el esfuerzo total de la ingeniería para cumplir con los
objetivos de costos, planes y desempeño técnico".'
Básicamente, la ingeniería de sistemas es BUENA ingeniería con ciertas
áreas designadas de énfasis, algunas de la cuales se dan enseguida:

1.Se requiere un enfoque arriba-abajo, visualizando el sistema como un


conjunto. Aunque las actividades de la ingeniería en el pasado han cubierto
muy adecuadamente el diseño de diversos componentes del sistema, el
panorama necesario y el entendimiento de cómo esos componentes efecti-
vamente encajan no han estado siempre presentes.
2. Se requiere una orientación al ciclo de vida, tratando todas las fases
que incluyen el diseño y el desarrollo del sistema, producción y (o) cons-
trucción, distribución, operación, apoyo de mantenimiento y soporte, retiro
y desecho. En el pasado, el énfasis se colocó principalmente en las activida-
des del diseño del sistema, con poca (si hay alguna) consideración hacia su
impacto en producción, operaciones y soporte logístico.
3. Un mejor y más completo esfuerzo es requerido en relación con la
identificación inicial de los requerimientos del sistema, relacionando estos
requerimientos con metas de diseño especificas, el desarrollo de criterios
de diseño apropiados y el intento de análisis a continuación para asegurar
la efectividad de una temprana toma de decisiones en el proceso del diseño.
En el pasado, el esfuerzo inicial de análisis requerido al inicio de un
proyecto, aplicado a muchos nuevos sistemas, ha sido mínimo. Esto, a su
vez, ha requerido mayores esfuerzos de diseño individual río abajo en el
ciclo de vida, muchos de los cuales no están bien integrados con las otras
actividades de diseño y requieren modificarse más adelante.
4. Se requiere un esfuerzo interdisciplinario (o enfoque de equipo) du-
rante el diseño de sistema y el proceso de desarrollo para asegurar que
todos los objetivos del diseño cumplen de manera efectiva. Éste exige un
entendimiento completo de las muy diversas disciplinas de diseño y sus
interrelaciones, particularmente para grandes proyectos.

En resumen, la ingeniería de sistemas per se no se considera una


disciplina de la ingeniería en el mismo contexto que la ingeniería eléctrica,
la ingeniería mecánica, la ingeniería de confiabilidad o cualquier otra área
de la especialidad del diseño. Realmente, la ingeniería de sistemas involu-
cra los esfuerzos relativos al proceso de diseño en general empleado en la
evolución de un sistema desde el punto en que inicialmente se identifica una
necesidad, hasta la producción y (o) construcción y la distribución última
de ese sistema para uso del consumidor. El objetivo es cumplir los requeri-
mientos del consumidor de manera efectiva y eficiente. El proceso de la

MIL-STD-499A, Estándar militar, Maricales de la «administración de ingeniería», Fuerza aérea


de E.U./Comando de sistemas de la fuerza aérea, Andrews AFB, Maryland 20331.
LA NECESIDAD DE LA INGENIERÍA DE SISTEMAS 33

ingeniería de sistemas se analiza en detalle en el capítulo 2. Finalmente, los


conceptos asociados a la ingeniería de sistemas no son necesariamente
nuevos ni novedosos. La revisión de alguna literatura en el apéndice D indica
que muchos principios identificados aquí han sido fomentados antes, a fina-
les de los cincuentas y a principios de los sesentas. Aun actualmente, ¡es
necesario enfatizar estos conceptos más todavía! Aunque hay sistemas muy
sofisticados y de alta tecnología que son producidos y(o) están en uso hoy,
¡hay ciertas tendencias que son de interés!

1.2.4 Ciencia de sistemas

A menudo, al tratar el tema de la ingeniería de sistemas, uno usa los términos


"ciencia de sistemas" y "análisis de sistemas" intercambiándolos. Para
propósito de este texto, la ciencia de sistemas se ocupa esencialmente de la
observación, identificación, descripción, investigación experimental y ex-
plicación teórica de los hechos, leyes físicas, interrelaciones, etc., asocia-
dos con fenómenos naturales. La ciencia se ocupa de los conceptos básicos
y principios que ayudan a explicar cómo se comporta el mundo físico en el
sentido más amplio; las disciplinas de biología, química y física cubren
muchas de estas relaciones. En cualquier evento, la ingeniería de sistemas
incluye la aplicación de principios científicos durante los procesos de di-
seño y desarrollo del sistema.'

1.2.5 Análisis de sistemas

El proceso inherente a la ingeniería de sistemas es un esfuerzo analítico


continuo. En un sentido un tanto purista, el análisis se refiere a una sepa-
ración del todo en sus partes componentes, una observación de estas partes
y sus interrelaciones y una decisión que sigue adelante referente a un curso
de acción futuro.
Más específicamente, durante el diseño y desarrollo de sistemas hay
diferentes alternativas (o compromisos) que requieren de un intento de
evaluación de alguna forma. Por ejemplo, hay escenarios operacionales del
sistema alternativos, mantenimiento y conceptos de soporte alternativos,
planes de empaque de equipo alternativos, rutinas de diagnóstico alterna-
tivas, aplicaciones manuales contra aplicaciones automáticas alternativas,

'La ciencia de sistemas es el principal sujeto por sí misma, y el autor aprecia que este término
no haya sido cubierto adecuadamente aquí. Existen tres referencias excelentes: Ackoff, R. L.,
S. K. Gupta, y J. S. Minas, Scientific Method: OptimizingAppliedResearch Desicions, John Wiley,
New York, 1962; Sandquist, G. M., General Systems l7ieory, George Braiiller, New York, 1968.
34 INTRODUCCIÓN A LA INGENIERÍA DE SISTEMAS

y así sucesivamente. El proceso de investigar estas alternativas y la evalua-


ción de cada una en términos de un cierto criterio, constituye una alterna-
tiva analítica continua.
Para llevar a cabo esta actividad de manera efectiva, el ingeniero
(analista) se ayuda mediante el empleo de las técnicas analíticas y herra-
mientas disponibles para incluir métodos de investigación de operaciones
como la simulación, la programación lineal y dinámica, la programación
entera, la optimización (con y sin restricciones) y la teoría de colas para
poder resolver problemas. Además, los modelos matemáticos aún son
empleados para ayudar a facilitar el proceso de análisis cuantitativo.
En esencia, el análisis de sistemas incluye ese proceso analítico, aún
continuo, de evaluar varias alternativas de diseño ce sistemas, empleando
la aplicación de modelos matemáticos y herramientas analíticas asociadas
apropiadas. Los métodos analíticos y los modelos son discutidos más
adelante en el capítulo 47

1.2.6 Ingeniería de sistemas en el ciclo de vida

Las fases más importantes del ciclo de vida de un sistema se muestran en la


fisura 1.2. Aunque la nomenclatura y las características pueden variar un
tanto dependiendo de la naturaleza y tipo del sistema, es necesario que una
línea base sea desarrollada para propósitos de discusión más adelante y el
establecimiento de los requerimientos de la ingeniería de sistemas.
La figura 1.7 se incluye para mostrar las fases más importantes del
programa, las actividades básicas que generalmente se llevan a cabo en
cada fase y el grado de definición de diseño, conforme se avanza desde la
identificación de la necesidad hasta el desarrollo y evaluación de un
prototipo del sistema. Esta figura ilustra el proceso de ingeniería de sistema
básico que se trata en detalle en el capítulo 2. El modelo presentado en la
figura es genérico por naturaleza y las actividades observadas deben
"confeccionarse" (o "adaptarse") al sistema específico que se desarrolla.
La figura 1.8 presenta las fases del programa básico desde una pers-
pectiva diferente, con la adición de algunos pilares principales que son
considerados como críticos. Estos indicadores incluyen la identificación de

El análisis de sistemas es cubierto ampliamente en Fisher, G. H., C'ostconsiderations in Systems


An,.i!ysis. RAND Corporation Report R-490ASD, American Elsevier, New York, 1971; Hillier, F. S.
y G. J. Liberman, Introducf ion fo Operations Research, Holden-Day, San Francisco, 1980; y
Majone, G. y E. S. Quade (Eds.), Pitíalis of AnaIyis, John Wiley, New York, 1980.

'¡La figura 1.7 se presenta para ilustrar un proceso! La longitud o el ciclo extenso de actividades
no es intencional, como una progresión a través de las mismas series básicas de pasos en el
desarrollo de cualquier sistema. Esta figura constituye una revisión de la figura 2.4 de Systems
Engineering andAnalysis, 2da edición, Prentice-Hall, Englewood Ciiffs, Ni, 1990 de B. Blanchard
y W. Fabrycky.
LA NECESIDAD DE LA INGENIERÍA DE SISTEMAS 35

especificaciones significativas y los planes, los vehículos para la documen-


tación de los requerimientos de la ingeniería de sistemas.
En apoyo del enfoque arriba-abajo, integrado, del ciclo de vida, hay cier-
tas actividades críticas y eventos que deben ocurrir en los puntos designa-
dos en el proceso de creación del sistema. Estas actividades, que se ocupan
esencialmente de la definición de los requerimientos del nivel más alto del
sistema, incluyen lo siguiente:,

1. La realización del análisis de factibilidad del sistema durante la fase


de diseño conceptual; esto es, la definición de los requerimien-
tos del nivel más alto del sistema hasta la conducción de estudios
iniciales de compromisos.
2. El desarrollo de los requerimientos operacionales del sistema y el
concepto de mantenimiento durante la fase del diseño conceptual.
Esto es, el desarrollo de criterios básicos operacionales y de sopor-
te como una entrada al proceso de diseño del sistema.
3. La preparación de las especificaciones del sistema (especificación
tipo "A"); esto es, el desarrollo del primer documento relacionado
con el diseño que ordena los requerimientos técnicos del sistema.
4. La preparación del plan de administración de ingeniería de sistemas
(SEMP); esto es, el desarrollo del primer documento de planeación
que ordena las actividades de administración del programa que,
cuando son implementadas adecuadamente, ayudarán a asegurar
una salida del producto bien coordinada e integrada.
S. La preparación del plan maestro de prueba y evaluación (TEMP); es
decir, el desarrollo de un plan de prueba integrado, diseñado para
planear un programa que verificará si los requerimientos del siste-
ma se han cumplido.
6. La consecución del análisis funcional y la realización de los reque-
rimientos del nivel de sistema; esto es, la definición del sistema en
términos funcionales y la preparación del diagrama de flujo funcio-
nal del nivel del sistema.
7. La planificación y la realización de una serie de revisiones formales
del diseño (revisiones conceptuales, del equipo/software y del
diseño crítico); esto es, la planeación y coordinación de las "verifi-
caciones" adecuadas para asegurar que los requerimientos del

No obstante, existen muchas tareas críticas a lo largo del desarrollo de un programa


de sistemas típico el autor considera esto como muy significativo sobretodo en el proceso de
sistemas de ingeniería. Estas tareas son discutidas a detalle en la sección 6.2.2 del capítulo 6.
Fase del diseño conceptual Y Fase del diseño preliminar Fase de diseño detallado del Fase de producción y(o) Fase de uso operacional y soporte del
planeación de avance 1 del sistema sistema y de desarrollo construcción sistema

Análisis da comercialización; Análisis funcional; Diseño detallado de los Producción y(o) construcción Operación del sistema en el ambiente del
análisis de factibilidad del distribución de requenmien- subsistemas y componentes; del sistema y sus componen- usuano; soporte logístico; prueba
sistema; diseño conceptual: los; síntesis y evaluación de compromisos y evaluación tes; actividades de producción operacional y evaluación; recopilación de
requerimientos operacionales; ailematwas (optimización); de alternativas; desarrollo de del proveedor, distribución y datos y análisis; modificación del
concepto de mantenimiento; diseño preliminar, prueba y ingeniería y modelos operación del sistema; prueba sistema-subsistemas; servicio al cliente.
evaluación de aplicaciones y evaluación de los conceptos prototipos: prueba y operacional y evaluación;
tecnología planeación del del diseño; detalle de la evaluación; diseño-prueba servicio al cliente y soporte
programa de avance planeación de programa. de los datos; planeación de logístico; recopilación de
la producción. datos y análisis.

El sistema-producto:

A A ri A
arI pilar 11 LlarIH terlV
[ldentificación de la ]F Identificación de la 1íIdentificación de la 1
flentificación actualizada
Lr J JhguraoóndaoducJ onhguracion del producJ
Especificación del Desarrollo producto del proce- Proceso, producto,
sistema (tipo 'Al so, especificaciones del mate- especificaciones de material
rial (tipos V, C, V, E) (tipos D, E)

Pitares más importantes al nivel del sistema:


A Plan de administración del programa (PMP)
A Plan de la administración de la ingeniería de sistemas (SEMP)
A Plan maestro de prueba y evaluación (EMP)
A Revisión del diseño conceptual (revisión de los requerimientos del sistema)
A A Revisiones del diseño do sistemas
A A Revisiones del diseño de software-equipo
- A Revisión crítica del diseño

Figura 1.8. El proceso de creación de los sistemas y los pilares importantes. (Fuente: Blanchard, B.S. y W. J. Fabrycly.
Systems Engineering andAnalysis, 2' ed., Prentice-Hall, Englewood Cliffs, N.J., 1990.)
[Definición de laea Diseño preliminar del sistema (avance del desarrollo)

Análisis funcional del sistema y Análisis del sistema, estudios de Síntesis del sistema
Diseño conceptual requenrn ientos de distribución compromisos y optimización y definición

• Factibilidad de tecnologías de alternativas • Diagramas de bloques de funciones • Compromisos del sistema-subsistema y


de estudio operacionales del sistema evaluación de alternativas • Diseño preliminar-modificación y
• Requerimientos operacionales del sistema • Funciones de mantenimiento • Desarrollo de laconfiguración de soporte estructuración de configuraciones alter-
• Concepto de mantenimiento del sistema • Asignación del desempeño factores de del sistema nativas del diseño
• Planeación avance sistemproduclo efectividad, criterios de diseño, etc, • Planes detallados y especificaciones • Desarrollo, prueba y evaluación de mo-
• Plan de administración de ingeniería de • Distribución de los requerimientos de so- delos ingenieriles
sistemas y especificaciones porte del sistema • Documentación del diseño y revisión

III
Retroalimentación y acción correctiva ------
Investigación aplicada

Procucción y (o) construcción


Diseño de detalle y desarrollo
• Manufactura-producción-prueba de los elementos
Diseño del sistema- Desarrollo del prototipo Prueba y evaluación del prototipo fundamentales del sistema y elementos de sopor-
producto del sistema del sistema te del sistema
• Valoración del sistema (recopilación de datos,
• Diseño en detalle dalos elementos •Desarrollo de los modelos del pro- •Preparación de pruebas del sistema análisis y evaluación)
fundamentales del sistema totipo del sistema •Prueba de los modelos del prototipo • Modificaciones del sistema para acción correctiva
• Diseño en detalle de los elementos • Desarrollo de los elementos del del sistema
41
del soporte del sistema soporte del sistema • Prueba de la colección de datos,
• Análisis del diseño y evaluación • Evaluación y prueba del com- análisis, evaluación y acción Utilización del sistema y soporte del ciclo de vida
• Diseño de datos-revisión ponente correctiva
•Reporte de prueba • Valoración del sistema
• Modificaciones-cambios del sistema
- - - - Retroalimentación y acción correctiva -----
LIItisII1

Figura 1.7. Los pasos más importantes del diseño y desarrollo del sistema.
38 INTRODUCCIÓN A LA INGENIEREÁ DE SISTEMAS

sistema se cumplen conforme el diseño progresa a través del


proceso de creación.
8. La coordinación, implementación, retroalimentación y control de
los cambios del diseño; esto es, las funciones continuas de la ad-
ministración de la configuración (CM).

Básicamente, el proceso global representado en la figura 1.9 es de re-


lativa importancia para la realización de los objetivos de la ingeniería de
sistemas. Éste incluye la definición inicial de los requerimientos, la
implementación de tales requerimientos en el diseño y desarrollo de un
sistema, el esfuerzo de medición y evaluación para verificar que tales
requerimientos se cumplen y la retroalimentación y el lazo de acción
correctiva necesarios para cubrir algunas deficiencias y (o) mejoras signi-
ficativas. El énfasis aquí está en los requerimientos del sistema, a partir de
los cuales evolucionan los requerimientos de diseño detallado. El estableci-
miento de una línea base técnica buena, en el ciclo de vida inicial, es el
objetivo. Posteriormente, es necesario medir y evaluar los resultados de
cómo progresa el diseño del sistema. Si los problemas son detectados, una
resolución tan pronto como sea posible en el ciclo de vida es preferible; si
los cambios o modificaciones son iniciados en etapas muy avanzadas,
puede resultar costoso.

1.3 ADMINISTRACIÓN DE [A INGENIERÍA DE SISTEMAS

La ingeniería de sistemas incluye aquellos esfuerzos para asegurar que el


diseño y desarrollo de un sistema no sólo cumplirá con las necesidades del

Revisión del Revisión del Revisión del


diseño diseño diseño

Habilita el programa 1 1 de y evalúa el ¿Han sido


Define los r
para desarrollar un sis- _______ sistema en términos cumplid
querimientos
tema que cumpla con de conformidad con requenmientos"
del sistema.
los requerimientos. los requerimientos,

No
Retroalimentación y lazo de acción correctiva.

Figura 1.9. Los requerimientos básicos del sistema, & proceso de evaluación y la revisión.
TÉRMINOS RELACIONADOS Y DEFINICIONES 139)

consumidor, sino que se llevarán a cabo de una manera efectiva y eficiente.


Tales actividades pueden incluir la realización de estudios de factibilidad
y la definición de los requerimientos al nivel de sistema, la preparación de
la especificación del sistema, el análisis funcional y distribución de los re-
querimientos, la integración del diseño y la realización de revisiones forma-
les de diseño, la prueba y evaluación del sistema, etc. Estas actividades
ingenieriles que están dirigidas hacia un diseño integrado de arriba-abajo,
de ciclo de vida son claves en lo que refiere a satisfacer los objetivos de la
ingeniería de sistemas.
La realización de los objetivos básicos aquí descritos requier un
enfoque de administración efectivo comenzado desde el principio del
programa. La mayoría de tal actividad sucede durante el diseño conceptual
y preliminar, donde los resultados tienen el impacto más grande en la salida
global del producto. La administración de estas actividades, en particular,
es crítica para el éxito de un programa efectivo. Con esto en mente, durante
la fase de diseño conceptual se desarrolla un plan de administración de
ingeniería de sistemas (SEMP), el cual, además, sirve como guía fundamen-
tal para la administración durante todas las fases subsiguientes del ciclo de
vida. La administración de la ingeniería de sistemas se trata en forma
meticulosa en los capítulos 6, 7 y 8.10

1.4 TÉRMINOS RELACIONADOS Y DEFINICIONES

El reconocimiento de los aspectos relacionados inducidos con el énfasis


requerido en ingeniería de sistemas, discutido en las secciones 1.1 y 1.2, ha
causado la introducción de muchas actividades nuevas. Una de tales activi-
dades, recientemente introducida por el Departamento de Defensa, es "la
ingeniería concurrente", que está definida como "un enfoque sistemático en
el diseño integrado, concurrente de productos ysus procesos relacionados,
incluyendo manufactura y soporte. Este enfoque tiene la intención de que
los desarrolladores, desde el principio, consideren todos los elementos
del ciclo de vida del producto, desde la concepción hasta el desecho,
incluyendo calidad, costos, planificación y requerimientos del usuario."'
Los objetivos de la ingeniería ocurrente incluyen: 1) mejorar la calidad
y efectividad de los sistemas-productos mediante una mejor integración de
los requerimientos, 2) reducir el tiempo del ciclo de desarrollo del sistema-

,/4 SEMP, usado extensivamente en el sector de defensa, se verá más ampliamente en Systems
Engineering Management Cuide, Defense Management College (DSMC), Fort Belvoir, Virginia,
2»60.
'1 IDA Report R-338, "The Role Of Concurrent Engineering In Weapons System Acquisition",
Institute For Defense Analysis, 1801 N. Beauregard Street, Alexandria, Virginia, 22311, diciem-
bre de 1988.
40 INTRODUCCIÓN A LA INGENIERÍA DE SISTEMAS

producto por medio de una mejor integración de actividades y procesos.


Esto, a su vez, debería resultar en una reducción del costo total del ciclo de
vida para un sistema dado. En la opinión del autor, las metas de la ingeniería
concurrente y las de la ingeniería de sistemas son similares y se apoyan
entre sí.
Además, hay programas de empuje que son compatibles directamente
y refuerzan los conceptos y objetivos de la ingeniería de sistemas descrita
aquí. Estos incluyen los conceptos de administración de calidad total (1'QM)
que tratan la calidad desde la perspectiva del nivel del sistema; y el
mantenimiento de la productividad total (rPM), que trata el soporte del
sistema desde un punto de vista integrado global. Estos y otros términos
relacionados, así como algunas definiciones se presentarán en este texto
conforme avance de capítulo en capítulo.

1.5 RESUMEN

Este capítulo proporciona una introducción abreviada de algunos térmi-


nos y definiciones claves que son inherentes a la discusión de los capítulos
subsiguientes. Aunque hay muchos términos adicionales introducidos mien-
tras uno avanza a través de este libro, una breve discusión acerca de
"sistemas", "análisis de sistemas", "ciencia de sistemas", "ingeniería de sis-
temas" y el "ciclo de vida" estimulará con optimismo "los procesos de
pensamiento" sobre el material que viene. Los conceptos presentados aquí
y particularmente la información ilustrada en las figuras 1.7 y 1.8, son una
introducción natural al proceso de ingeniería de sistemas discutido en el
capítulo 2.

PREGUNTAS Y PROBLEMAS

1. Defina, con sus propias palabras, un "sistema". Además, incluya algunos


ejemplos.
2. Defina "análisis de sistemas", "ciencia de sistemas" e "ingeniería de
sistemas". ¿Cuáles son las diferencias básicas? ¿Cómo se relacionan con
cada una de las otras (si se relacionan con todas)?
3. ¿Cuáles son las diferencias (o similitudes) entre "la ingeniería de siste-
mas" y algunas de las disciplinas tradicionales, como la ingeniería civil,
la ingeniería eléctrica, la ingeniería mecánica?
4. ¿Por qué es importante la ingeniería de sistemas? ¿Cuáles son algunos
de los problemas en el ambiente actual (como usted los vea)? ¿Cómo
evitará algunos de estos problemas en la aplicación de los principios de
la ingeniería de sistemas en el futuro?
PREGUNTAS Y PROBLEMAS 41

5. Defina qué se entiende por "ciclo de vida". Qué son los "costos del ciclo
de vida"? ¿Por qué es importante considerar lo anterior en el proceso de
toma de decisiones?
6. Seleccione un sistema y desarrolle un diagrama de flujo ilustrando el
diseño y el proceso de desarrollo (en relación con la figura 1.7).
Identifique el proceso con las diversas fases del ciclo de vida y describa
algunas de las actividades en cada fase.
EL PROCESO DE INGENIERÍA
DE SISTEMAS

El ciclo de vida del sistema constituye una serie de actividades que comien-
za con la identificación inicial de una necesidad del consumidor y se
extiende hasta el diseño y desarrollo, producción o construcción, uso ope-
racional y apoyo de soporte y, por último, retiro del sistema (ilustrado en
la figura 1.2). Estas actividades pueden estar separadas en funciones de
creación del sistema y funciones de utilización del sistema. En el espectro
de la creación hay funciones de diseño y desarrollo, funciones de evaluación
y prueba, funciones de producción y así sucesivamente. Nuestro objetivo es
tratar las funciones de ingeniería involucradas en el diseño y desarrollo
del sistema y observar estas funciones de forma ordenada e integrada.
El proceso de ingeniería de sistemas es inherente al espectro global de
la creación del sistema y está dirigido hacia la habilitación de los principios
descritos en la sección 1.2. Esto incluye un análisis arriba-abajo integrado
en el planteamiento del ciclo de vida para el diseño y desarrollo del sistema.
La realización de esto requiere una progresión organizada a través de una
serie de pasos que incluyen: 1) la identificación de la necesidad y la
realización de estudios de factibilidad, 2) el desarrollo de requerimientos
operacionales y el concepto de mantenimiento y el de soporte, 3) la rea-
lización del análisis funcional y la distribución de los requerimientos,
4) síntesis del sistema, análisis y optimización, 5) diseño de detalle y 6)
prueba y evaluación. Este proceso está ilustrado en la figura 1.7 y los pasos
diversos son descritos en este capítulo.

2.1 IDENTIFICACIÓN DE LA NECESIDAD

El proceso de ingeniería de sistemas generalmente comienza con la identi-


ficación de un "quiero" o "deseo" para uno o más ítems y está basado en una
deficiencia real (o percibida). Por ejemplo, una capacidad actual del sistema
44 EL PROCESO DE INGENIERfA DE SISTEMAS

no es adecuada en términos de cumplir con ciertas metas de desempeño


requeridas, no está disponible cuando se necesita, no puede tener el
soporte adecuado, es muy costosa en términos de operación y así sucesiva-
mente. Como resultado, un requerimiento de un nuevo sistema es definido
junto con la prioridad en la introducción, la fecha en que la capacidad del
nuevo sistema es requerida para el uso del consumidor y una estimación
de los recursos necesarios para crear la nueva capacidad del sistema.
La "descripción de la necesidad» debe ser presentada en términos especí-
ficos cualitativos y cuantitativos, con bastante detalle para justificar el
avance al siguiente paso.
Los requerimientos para identificar la necesidad parecen ser básicos
como punto de inicio (esto es autoevidente). No obstante, a menudo uno
encuentra que un esfuerzo de diseño se inicia como resultado de un interés
personal o un deseo político, sin inicialmente haber definido adecuadamen-
te el requerimiento para tales fines. Definir el problema es, a veces, la parte
más difícil del proceso. No obstante, una descripción completa de la
necesidad es muy necesaria y es importante que los resultados reflejen
verdaderamente los requerimientos del cliente, particularmente en este
ambiente de recursos restringidos en que nosotros operamos.

2.2 ANÁLISIS DE FACTIBILIDAD DEL SISTEMA

Dada la definición de una necesidad, es necesario: 1) identificar diversos


planteamientos posibles del diseño que pueden ser ejercidos para cumplir
los requerimientos, 2) evaluar los candidatos más probables en términos de
desempeño, efectividad, requerimientos logísticos y criterios de economía,
3) recomendar un enfoque preferido. Puede haber una gran diversidad de
alternativas; no obstante, el número de posibilidades debe ser reducido a
unas cuantas opciones factibles, consistentes con la disponibilidad de los
recursos (por ejemplo, mano de obra, materiales y dinero).
Al considerar los diversos enfoques de diseño, las aplicaciones de
tecnología alternativas son investigadas. Por ejemplo, en el diseño de un
sistema de comunicaciones, ¿uno debe usar tecnología de fibras ópticas o el
enfoque de cables convencionales? En el diseño de aviones, ¿hasta qué
punto uno debe incorporar materiales compuestos? Cuando se diseña un
automóvil, uno debe aplicar circuitos electrónicos integrados de alta velo-
cidad en ciertas aplicaciones de control, o seleccionar un enfoque electro-
mecánico más convencional.
Es en esta etapa inicial del ciclo de vida (por ejemplo, la fase del diseño
conceptual) donde se toman las mejores decisiones referentes a adaptar un
enfoque de diseño específico. Las aplicaciones de la tecnología son evalua-
das y, en algunos casos donde la información suficiente no está disponible,
ANÁLISIS DE FACTIBILIDAD DEL SISTEMA 45

una actividad de investigación puede iniciarse con el objetivo de desarrollar


nuevos métodos-técnicas para aplicaciones específicas. En algunos progra-
mas, la conclusión de tareas de investigación aplicada y la actividad de
diseño preliminar es realizada secuencialmente, mientras en otras situacio-
nes puede haber un número de miniproyectos diferentes que avanzan al
mismo tiempo.
En cualquier evento, los de esta actividad inicial de análisis afectarán
significativamente no sólo las características de un sistema, sino también su
producción y aspectos de soporte. La selección (y aplicación) de una tec-
nología determinada tiene implicaciones de confiabilidad y mantenibili-
dad, puede afectar significativamente los requerimientos en las partes de
repuesto y prueba de equipo y ciertamente afectará los costos del ciclo
de vida. El resultado de esta actividad se dirige al desarrollo de los reque-
rimientos operacionales del sistema y al concepto de mantenimiento y, por
último, será incluido en la especificación del sistema (Tipo "A").
Con el análisis de factibilidad inicial, que es muy importante y que tiene
así un gran impacto en el diseño del sistema y actividad de desarrollo, el

Identificación de la necesidad actual II 1 Requerimientos del consumidor

Análisis de factibilidad del sistema Id Investigación aplicada (según se

Requerimientos operacionales del


sistema

Concepto de mantenimiento y
soporte

Análisis funcional
ca y
distribución de requerimientos
a,
-D

Síntesis, análisis

t y
optimización del diseño del sistema

Prueba y evaluación
del sistema

Figura 2.1. Una secuencia abreviada de la actividad de diseño.


46 EL PROCESO DE INGENIERÍA DE SISTEMAS

papel de ingeniería de sistemas se vuelve significativo. En la mayoría de las


situaciones, la investigación detallada y los esfuerzos de evaluación para
determinar los enfoques del diseño son altamente técnicos y los realizan los
especialistas de las disciplinas ingenieriles dadas. A menudo, estos especia-
listas no están orientados hacia el "sistema" como una entidad global, o su
proceso de manufactura, o su mantenimiento y capacidad de soporte, o a los
factores que afectan los costos del ciclo de vida. Hasta ahora, se están to-
mando decisiones cuyos resultados terminan en la especificación yen todas
las actividades de diseño que se deben cumplir. De este modo, la necesi-
dad de una ingeniería de sistemas fuerte en esta etapa inicial del ciclo de
vida es crítica.

2.3 REQUERIMIENTOS OPERACIONALES DEL SISTEMA

Con la identificación de una necesidad de sistema, combinada con la se-


lección de un enfoque de diseño técnico factible, es necesario proyectar
esta información en términos de los requerimientos operacionales antici-
pados. La figura 2.1 presenta el flujo básico de la actividad.
Los requerimientos operacionales reflejan las necesidades del consumi-
dor relativas a la utilización del sistema y a la realización de una misión.

( s

Figura 2.2. Requerimientos operacionales del sistema (distribución geográfica).


REQUERIMIENTOS OPERACIONALES DEL SISTEMA

Perfil de la misión A Perfil de la misión V Perfil de la misión 'C

Tiempo de la misión Tiempo de la misión Tiempo de la misión

Perfil de la misión Perfil de la misión B" Perfil de la misión

o o
a
E
a
E

o 0)

Tiempo deis misión Tiempo de la misión Tiempo de la misión

Figura 2.3. Ejemplo de los perfiles operacionales del sistema. (Fuente: Blanchard, B.S. Logistícs
En.gineeríng and Management, 31 ed., Prentice-Hall, Englewood Cliffs, N.J., 1986.) -

El concepto operacional definido aquí, incluye la información anotada más


adelante:

1. Distribución operacional o desplegado. El número de sitios donde el


sistema será utilizado por el consumidor, la distribución geográficayel plan
ye! tipo cantidad de los componentes del sistema en cada localidad. Esto
responde a la pregunta: ¿dónde se utiliza el sistema? La figura 2.2 presenta
un ejemplo de un plan de distribución universal.
2.Perfil de la misión o escenario. Identificación de la misión fundamental
del sistema y sus misiones alternativas o secundarias. ¿Cuál es el sistema
que se realiza para responder a la necesidad? ¿Cómo realizará su objetivo?
Esto puede definirse mediante una serie de perfiles operacionales, que
ilustran los aspectos dinámicos requeridos al realizar una misión. Una ruta
de vuelo de un avión entre dos ciudades, una ruta de automóvil o bien una
ruta de embarcación son ejemplos. La figura 2.3 proporciona una ilustración
simple de los perfiles posibles.
3. Desempeño y parámetros relacionados. Definición de las característi-
cas operativas básicas, o funciones, del sistema. Esto se refiere a los pará-
metros tales como rango, precisión, velocidad, capacidad, presión, salida
48 EL PROCESO DE INGENIERÍA DE SISTEMAS

de potencia, tamaño y peso. ¿Cuáles son los parámetros de desempeño del


sistema críticos necesarios para realizar la misión en los diversos sitios
del consumidor?
4. Requerimientos de utilización. Uso anticipado del sistema y sus
componentes, en la realización de su misión. Esto se refiere a las horas de
operación de equipo por día, ciclo obligado, ciclos encendido-apagado por
mes, porcentajes de la capacidad total utilizada, facilidad de carga, etc.
¿Cómo se utilizan los diversos componentes del sistema? Esto induce
a determinar algunos de los esfuerzos impuestos en el sistema por el
operador y su ambiente.
S. Requerimientos de efectividad Requerimientos del sistema, especifi-
cados cuantitativamente según se aplique, que incluyen efectividad de cos-
to-sistema, disponibilidad operacional, dependencia, confiabilidad que
significa el tiempo entre fallas (MTBF), razón de fallas (?.), razón de disposi-
ción, tiempo de mantenimiento (MDT), que significa tiempo entre manteni-
miento (MTBM), facilidad de utilización (en porcentaje), niveles de destreza
del personal, costos y así sucesivamente. Dado lo que el sistema desempe-
ñará, ¿cuán efectivo o eficiente será?
6. Ciclo de vida operacional (horizonte). El tiempo anticipado que el
sistema estará en uso operacional. ¿Cuánto tiempo estará en uso el sistema
para el consumidor? ¿Cuál es el perfil para el inventario total del sistema
y sus componentes y dónde se localizará el inventario? Uno necesita defi-
nir el ciclo de vida del sistema.
7.Ambiente. Definición del ambiente en el que se espera que el sistema
opere de manera efectiva, por ejemplo, temperatura, sacudida y vibración,
ruido, humedad, ártico o trópico, montañas o terreno plano, aire, suelo
y embarcación. Siguiendo un conjunto de perfiles de la misión puede resul-
tar en la especificación de un rango de valores. ¿A qué estará sujeto el
sistema durante su uso operacional y por cuánto tiempo? Además de las
operaciones del sistema, las consideraciones ambientales deben tratar
transportación, manejo y modos de almacenamiento. Es posible que el
sistema (y [o] algunos de sus componentes) estarán sujetos a un ambiente
más riguroso durante la transportación que durante su operación.

El establecimiento de los requerimientos operacionales forma las bases


para el diseño de sistemas. Obviamente, uno necesita hacerse las siguien-
tes preguntas antes de proseguir:

1. ¿Qué funciones desempeñará el sistema?


2. ¿Cuándo será requerido que el sistema desempeñe sus funciones
propuestas?
3. ¿Dónde será utilizado el sistema?
4. ¿Cómo se realizará el objetivo del sistema?
EL CONCEPTO DE MANTENIMIENTO Y SOPORTE 49

Al responder a estas preguntas se debe establecer una línea base. Aun-


que las condiciones pueden cambiar, algunas suposiciones son requeridas.
Por ejemplo, los componentes del sistema serán utilizados en diferentes
localidades del consumidor, la distribución de los componentes del sistema
puede variar según los cambios necesarios y (o) la longitud del ciclo de vi-
da puede cambiar como resultado de la obsolescencia o los efectos de la
competencia. Sin embargo, la información presentada arriba necesita ser
desarrollada a fin de proseguir con el diseño del sistema.
Desde una perspectiva histórica los requerimientos operacionales de
muchos sistemas nuevos fueron desarrollados (por algún asesor, un grupo
de mercadotecnia o alguna entidad organizacional equivalente), colocados
en un archivo mientras se esperaba una decisión para seguir con el diseño
preliminar y luego se olvidaron cuando se reinició finalmente la siguiente
actividad de diseño. Hasta este punto, con la necesidad de este tipo de infor-
mación en seguida aparente (pero no disponible), los grupos individuales
de diseño generaron sus propias consideraciones. Asimismo, todas las
funciones del diseño estaban referenciadas en la misma base y se desarro-
llaron requerimientos contradictorios. Esto, a su vez, llevó a que fueran
desarrollados sistemas que no cumplen con los requerimientos del consu-
midor, y a la iniciación de acción correctiva mediante la aparición de mo-
dificaciones costosas. En otras palabras, silos requerimientos operacionales
aplicables no están bien definidos e integrados en el proceso de diseño, más
tarde los resultados a su vez podrían ser bastante costosos.
Esta es otra área crítica de la actividad donde se necesita una fuerte.
ingeniería de sistemas. Los requerimientos operacionales del sistema de.-
ben ser definidos e integrados de manera meticulosa y la información
apropiada debe ser divulgada de manera oportuna en todas las organizacio-
nes del diseño pertinentes. ¡Todo lo que involucra el proceso del diseño
debe seguir la misma línea!

2.4 EL CONCEPTO DE MANTENIMIENTO Y SOPORTE

Al tratar los requerimientos del sistema, la tendencia normal es inicialmente


ocuparse de aquellos elementos del sistema que se relacionan de manera
directa con el "desempeño de la misión", que es equipo fundamental, per-
sonal de operación , software operacional y datos asociados. Al mismo
tiempo, se da muy poca atención al soporte del sistema. En general, el én-
fasis en el pasado se ha dirigido sólo a una parte del sistema y no al sistema

Tres ejemplos de casos de estudios del tipo de Información que se incluye en la definición de
los requerimientos operacionales son presentados en el capítulo 3 de Bianchard, B.S. , Logistics
Erigineering and Management, 4' ed., Prentice-Hall, Englewood CliFfs, N.J., 1991.
50 EL PROCESO DE INGENIERÍA DE SISTEMAS

entero. Esto, evidentemente, ha dado lugar a algunos de los problemas


discutidos en la sección 1.1.
Para cumplir los objetivos globales de la ingeniería de sistemas es
esencial que todos los aspectos del sistema sean considerados sobre una
base integrada. Esto incluye no sólo los segmentos fundamentales orienta-
dos a la misión del sistema, sino también la capacidad de soporte. El soporte
del sistema debe ser considerado desde el inicio (por ejemplo, durante el
análisis de factibilidad cuando las nuevas tecnologías están siendo evalua-
das para una posible aplicación) y un concepto de mantenimiento previo
debe desarrollarse sobre cómo el sistema propuesto está siendo soportado
en una base del ciclo de vida.2
El concepto de mantenimiento, desarrollado durante el diseño concep-
tual, se desarrolla desde la definición de los requerimientos operacionales
del sistema tal como se ilustró mediante el diagrama de flujo de la figura 2.4.
Inicialmente, uno debe ocuparse del flujo de las actividades y materiales de
diseño, a través de la producción y los sitios operacionales del consumidor
donde el sistema está siendo utilizado. Además, existe un flujo que involucra
la capacidad de soporte del sistema. En relación con la figura, un flujo de
mantenimiento existe cuando los ítems se regresan desde el sitio operacional
al sitio intermedio ya los niveles de depósito de mantenimiento. Un segun-
do curso que involucra la distribución de partes de repuesto, personal,
equipo de prueba y datos de los diversos proveedores para los niveles in-
termedio y de depósito y para los sitios operacionales requeridos, es el dia-
grama de flujo de la figura 2.4, que refleja las actividades que se relacionan
con la capacidad global de soporte del sistema.
Aunque hay algunas variantes como una función de la naturaleza y el
tipo de sistema, el concepto de mantenimiento generalmente incluye la
siguiente información:

1. Niveles de mantenimiento. El mantenimiento correctivo y preventivo


puede ser realizado en el sistema mismo, en el lugar donde el sistema es
usado por el consumidor, en un negocio intermedio cercano al consumidor
y (o) en un depósito o en el local de una planta de manufactura. El nivel de
mantenimiento pertenece a la división de funciones y tareas de cada área
donde el mantenimiento es desempeñado. La frecuencia anticipada de
mantenimiento, la complejidad del trabajo, los requerimientos de nivel

2
El autor define el "concepto de mantenimiento" como una serie previa de ilustraciones
y descripciones de manera que el sistema es diseñado para tener soporte, mientras el "plan de
mantenimiento" define los requerimientos del soporte del sistema basados en los resultados
del análisis logístico (o equivalente). El concepto de mantenimiento es una entrada al diseño
y el plan de mantenimiento es el resultado del diseño. Una descripción completa del concepto
de mantenimiento se presenta en el capítulo 4 de Blanchard, B.S., Logistics Erigineering and
Management, 4' ed., Prentice-Hall, Englewood Clii fs, Ni., 1991.
ca o
-D cH2

EDD
a)
EE
a)

51
52 EL PROCESO DE INGENIERÍA DE SISTEMAS

de destreza del personal, las necesidades de facilidades especiales y así


sucesivamente, dictadas para una gran extensión de funciones específicas
que son realizadas en cada nivel. Dependiendo de la naturaleza y la misión,
puede haber dos, tres o cuatro niveles de mantenimiento. No obstante, para
propósitos de discusión más adelante, el mantenimiento puede ser clasifi-
cado como "organizacional", "intermedio" y "proveedor-almacén."
a. Mantenimiento organizacional. El mantenimiento organizacional
es desempeñado en el sitio operacional (por ejemplo, avión, vehículo o fa-
cilidades de comunicación). Generalmente se incluyen trabajos desempe-
ñados por la organización usando su propio equipo. El personal de nivel
organizacional está usualmente involucrado en la operación y uso del
equipo y tiene poco tiempo disponible para el mantenimiento del sistema
detallado. El mantenimiento en este nivel normalmente está limitado a ve-
rificaciones periódicas de desempeño de equipo, inspección visual, limpie-
za de equipo, algún servicio, ajustes externos y quitar y remplazar algunos
componentes. El personal asignado a este nivel generalmente no se detiene
a reparar componentes removidos, sino que los envía al nivel intermedio.
Desde el punto de vista del mantenimiento, el personal menos adiestrado es
asignado a esta función. El diseño de equipo puede tomar este hecho en
consideración (por ejemplo, diseño por sencillez).
b.Mantenimiento intermedio. Los trabajos de mantenimiento interme-
dio son desempeñados por organizaciones y en instalaciones móviles,
semimóviles o fijas especializadas. En este nivel, los ítems finales pueden
ser reparados por la remoción y remplazo de los módulos más importantes,
ensambles o partes de piezas. El mantenimiento programado requiere que
se realice el desensamblado del equipo. El personal de mantenimiento
disponible es usualmente más diestro y mejor equipado que aquél de nivel
organizacional y realiza el mantenimiento con más detalle.
Las unidades móviles o semimóviles son a menudo asignadas para
proporcionar soporte estrecho para equipo operacional distribuido. Estas
unidades pueden componerse de vagonetas, camiones o protección portá-
til que contiene algún equipo de prueba, de soporte y repuestos. La misión
es proveer el mantenimiento en el sitio (después de que fue realizado por el
personal de nivel organizacional) para facilitar el regreso del sistema a su
completo estado operacional sobre bases expeditas. Una unidad móvil
puede usarse para soportar más de un sitio operacional. Un ejemplo es el
vehículo de mantenimiento que es distribuido desde el hangar del aeropuer-
to hasta el avión estacionado en la entrada de la aerolínea comercial.
Las instalaciones fijas (tiendas permanentes) generalmente se estable-
cen para soportar los trabajos de nivel organizacional y las unidades
móviles o semimóviles. Los trabajos de mantenimiento que no pueden ser
desempeñados por los niveles más bajos, debido a limitaciones en las
habilidades del personal y al equipo de prueba, son desempeñados aquí.
El personal con grandes habilidades, el equipo adicional cíe prueba y de
EL CONCEPTO DE MANTENIMIENTO Y SOPORTE 53

soporte, más repuestos y mejores facilidades, permiten con frecuencia


realizar la reparación al nivel de módulo y parte de una pieza. Los negocios
fijos usualmente se localizan en áreas geográficas específicas. El manteni-
miento rápido a veces no es imperativo aquí como en los niveles más bajos
de mantenimiento.
c. Almacén o mantenimiento del proveedor. El nivel de almacén constitu-
ye el tipo de mantenimiento más alto y soporta la realización de los trabajos
arriba y más allá de las capacidades disponibles de nivel intermedio. Físi-
camente, puede ser un local de reparación especializado que soporta un
número de sistemas-equipos en el inventario o puede ser la planta del
fabricante de equipo. Las facilidades del almacén son fijas y la movilidad no
es un problema. El equipo complejo y voluminoso, grandes cantidades de
repuestos, provisiones de control ambiental y así sucesivamente pueden
ser proporcionados si se requiere. El alto volumen potencial en las facilida-
des del almacén promueve el uso de técnicas de línea de ensamble, que, a su
vez, permite el uso de labores relativamente sin habilidades para una gran
porción de la carga de trabajo con una concentración de especialistas
altamente diestros en ciertas áreas claves como diagnóstico de fallas
y control de calidad.
El nivel de mantenimiento del almacén incluye la reparación completa,
la reconstrucción y la calibración del equipo, así como también el desempe-
ño de las acciones del mantenimiento altamente complejas. Además, el
almacén proporciona una capacidad de suministro de inventario. Las faci-
lidades del almacén son generalmente localizadas remotamente a fin de
respaldar necesidades de áreas geográficas específicas o líneas de produc-
tos designados.
Los tres niveles de mantenimiento discutidos arriba están cubiertos en
la figura 2.5.
2. Políticas de reparación. Dentro de las restricciones ilustradas en la
figura 2.4y2.5, puede haber un número de políticas posibles que especifican
el grado ene! que la reparación de un componente de sistema será realizado
(si no en todos). Una política de reparación puede dictar que un ítem debe
ser diseñado para no ser reparable, parcialmente reparable o enteramente
reparable. Las políticas d2 reparación son establecidas inicialmente, los
criterios son desarrollados y el diseño de sistemas avanza dentro de los lí-
mites de la política de reparación que es seleccionada. Un ejemplo de una
política de reparación para el Sistema XYZ, desarrollado como parte del
concepto de mantenimiento durante el diseño conceptual, se ilustra en la
figura 2.6.

Las políticas de reparación son verificadas por último a través del análisis del nivel de
reparación, el resultado que conlleva al plan de mantenimiento. El análisis de nivel de repa-
ración usualmente es realizado como parte de un análisis de mantenibilidad, un análisis de
soporte logístico, o ambos. Véase el capítulo 3 para Información adicional.
Cnte,os Mantenimiento organizacionai Manlenimento lni6rmed)o Mantenimiento de depósito

¿Dónde se hace? En el sitio operacional o donde el equipo Unidades móviles o Unidades fijas Instalación del almacén
tundarnental está localizado sernimóviles

Camión, camioneta, Negocio do campo lijo Actividad do reparación especializada o planta del
protección portátil o fabricante
equivalentes

¿Por quién se hace? Sistema-equipo que opera el personal Personal asignado para unidades móviles. Depositar las destrezas del personal ola producción
(habilidades de mantenimiento bajas) samimóviles o tijas (habilidades de manteni- del personal de manufactura (una mezcla de habili-
miento intermedias) dades de fabricación intermedias y habilidades de
mantenimiento altas)

¿En qué equipo? Uso de equipo de organización Equipo propio usado por la organización

Inspección detallada y verificación del sistema Ajustes de fábrica complicados


Tipo de trabajo realizado Inspección visual Servicios mayores Reparaciones y modificaciones complejas del equipo
Venlicac*ón operacional Reparaciones y mod*caciones mayores del equipo Reparación y reconstrucción
Servicios menores Ajustes complicados Calibración detallada
Ajustes externos Calibración limitada Soporte de suministros
Remoción y remplazo de algunos compo- Sobrecarga de nivel organizacional de manteni- Sobrecarga del nivel intermedio demantenimiento
nentes. miento

Figura 2.5. Niveles más importantes del mantenimiento.


Almacén o mantenimiento
Mantenimiento organizacional Mantenimiento intermedio del proveedor

Unidad A
Vehículo
y
Ensamble de la Unidad A
Unidad 8
Almacén-industria

Mantenimiento no planeado
A - Realizar el aislamiento de la
falla al ensamble: Realizar el aislamento del de la falla
P S•
Realizar el aislamiento del
desperfecto del alternador
• En el evento de falla, pruebas in- • Sintezador al módulo o parle de la pieza: da comente 3
corporadasque proporcionan elais-
¡amianto de la talla en la
• Control de sintonización
• Acoplador Módulos de la unidad A
— ------
Unidad A, 0 • Amplificador de poder Factores de soporte:
Unidad 90
Unidad C
•Sintetizador CBs
•Conformador CBs
•Control de sintonización CBs
y
• Prueba equipo de so-
porte-ítems estándar
• La unidad pei'tinentees removida Unidad 9 • Amplificador de poder CBs • Personal-GS-9
remplazada • 1 -3hr
- ----- - - - Realizar el aislamiento de la
falla al ensamble
Módulos de la Unid.
•Impulsar CBs
9 • T.
Ar8 hr
• MM1-1/01-0.007
Mantenimiento planeado • Impulsar •Mezclador CBs
Mezclador TX
Priondaddevenulcación operacional • Fuente de energía y
Remover remplazar el tablero de
2
de la misión rl
ó rcuilos peiriente
pieza
o parle de la
-
y
Factores de soporte
• Prueba equipo de soporte aut
pruebas integradas
— Unidad C

Realizar el aislamiento de la
quipo no externo [tat a a laparte
pae dala pieza 1 _________________________
• Personal-Conductor de camión
Laboratorio de calibración Notas:
(equivalente a GS5)
• Ambiente-montañas, terreno pla-
no, trópicos, árticos
Factores de soporte:
-Equipo depruebaysoporle-conjunto
de pruebas de ensamble, probador _______
Realización de reparación
(o) calibración del conjunto
y 1, Partes de pieza
desechables.
2. Tableros de circuito que
• MTBF-18 hr de tablero de circuitos de pruebas de ensamble son diseñados como
• M1 -10 min
• iAHiOHO.l
• Personal-G5-7 o equivalente
• Ambiente- Negocio normal - ------ desechables.
3. Reparación de la fuente
• 1 -2 hr •Tiempo de calibración-8 hrs de poder realizada más
• TAr-4 hr económicamente en el
• MM1-1/01-1-0.05 almacén.

Figura 2.6. Flujo del concepto del mantenimiento del sistema (poiftica de reparación). (Fuente: Blanchard, B.S., Logistics
Engineenng and Management, 3. ed., Prentice-Hall, Englewood Ciiffs, NJ., 1986.)
56 EL PROCESO DE INGENIERÍA DE SISTEMAS

3.Responsabilidades organizacionales. La realización del mantenimien-


to puede ser la responsabilidad del consumidor, del productor (o provee-
dor) o de una tercera compañía, o una combinación de ellos. Adicionalmen-
te, la responsabilidad puede variar, no sólo con diferentes componentes
del sistema, sino como uno avanza en el tiempo a través del uso operacio-
nal del sistema y la fase de soporte de apoyo. Las decisiones relativas a las
responsabilidades organizacionales pueden afectar el diseño del sistema
desde un punto de vista de diagnóstico y empaque, así como también dic-
tando políticas de reparación, contratando provisiones de garantía y cosas
por el estilo. Aunque las condiciones pueden cambiar, algunas suposiciones
iniciales son requeridas en este momento.
4.Elementos de soporte logístico. Como parte del concepto de manteni-
miento inicial los criterios deben ser establecidos en relación con los di-
versos elementos de soporte logístico. Estos elementos incluyen soporte
de suministros (partes de reparación y repuestos, inventarios asociados,
da-tos de aprovisionamiento), equipo de prueba y soporte, entrenamiento,
personal y transportación y manejo de equipo, facilidades, datos, recursos
computacionales. Tales criterios, como una entrada al diseño, deben cubrir
las provisiones de auto-prueba integrada contra los requerimientos de
prueba externa, empacado y factores de estandarización, número y niveles
de adiestramiento del personal, transportación y factores de manejo
y restricciones, y así sucesivamente. El concepto de mantenimiento propor-
ciona los criterios de diseño del sistema iniciales pertenecientes a las
actividades ilustradas en la figura 2.4, mientras la determinación final de los
requerimientos de soporte logístico específico ocurrirá durante la termina-
ción del Análisis del Soporte Logístico (LSA), realizados conforme avanza el
diseño.
S. Requerimientos de efectividad. Esto está constituido por los factores
de efectividad asociados a la capacidad de soporte. En el área de soporte de
suministros, esto puede incluir una razón de demanda de partes de repues-
to, la probabilidad de que una parte del repuesto esté disponible cuando sea
requerido, la probabilidad de éxito de la misión dada una cantidad designa-
da de repuestos y la cantidad de lote económico como relacionada con la
consecución del inventario. Para el equipo de prueba, la longitud de la cola
mientras espera por la prueba, el tiempo de proceso de la estación de
prueba y la confiabilidad del equipo, son factores claves. En el transporte,
las razones de transportación, los tiempos de transportación, la confiabilidad
de transportación y los costos de transportación son significativos. Para el
personal y entrenamiento uno debe estar interesado en las cantidades
de personal y niveles de adiestramiento, razones de entrenamiento, tiem-
pos de entrenamiento y confiabilidad del equipo de entrenamiento. En el
software, el número de errores por línea de codificación puede ser una
medida importante. Estos factores, relacionados con los requerimientos
específicos del nivel de sistema, deben ser tratados. Carece de significado
ANÁLISIS FUNCIONAL 57

especificar un requerimiento cuantitativo aplicable a la reparación del ítem


M equipo esencial cuando toma seis meses adquirir una parte de repuesto
necesaria. Los requerimientos de efectividad aplicables a la capacidad de
soporte deben complementar los requerimientos del sistema global.
6. Ambiente. La definición del ambiente en relación con el mantenimien-
to y soporte. Ésta incluye temperatura, sacudida y vibración, humedad,
ruido, ambiente ártico contra tropical, montaña contra terreno plano, em-
barcación contra condiciones del suelo y así sucesivamente, según se
aplique a las actividades de mantenimiento y de transportación relaciona-
da, manejo y funciones de almacenamiento.

En resumen, el concepto de mantenimiento proporciona las bases para


el establecimiento de los requerimientos de capacidad de soporte en el
diseño del sistema. Estos requerimientos no sólo afectan a los segmentos
orientados a la misión del sistema, sino que deben proporcionar una guía
para el diseño y (o) consecución de los elementos necesarios del soporte
logístico; adicionalmente, el concepto de mantenimiento forma la base para
el desarrollo del plan de mantenimiento detallado, preparado durante el
diseño de detalle y la fase de desarrollo.

2.5 ANÁLISIS FUNCIONAL

Incluido en esta área de actividad se encuentra el desarrollo de una


descripción funcional del sistema y la traducción de los requerimientos del
nivel del sistema a criterios de diseño detallados (o restricciones). Una fun-
ción se refiere a una acción específica o discreta que es necesaria a fin de
alcanzar un objetivo dado, por ejemplo, una operación que el sistema de-
be realizar para llevar a cabo su misión o una acción de mantenimiento que
es necesaria para restaurar el sistema al uso operacional. Tales acciones
pueden ser realizadas esencialmente mediante el uso del equipo, mano de
obra, instalaciones, software o una combinación de ellos. No obstante,
hasta este punto el objetivo es especificar los "qués" y no los "cómos", esto
es: qué se necesita realizar contra cómo se realiza.4 El análisis funcional es
el proceso iterativo de descomponer los requerimientos del nivel del sis-
tema al nivel del subsistema, y tan bajo en la estructura jerárquica según se
necesite para identificar los criterios/restricciones de entrada del diseño
para los diversos componentes del sistema.
La realización de un análisis funcional se facilita por medio del uso de los
diagramas de bloque de flujo funcional, como se ilustra en la figura 2.7.

4 Ninguna pieza de equipo o software, o ítem de datos, o elemento de soporte logístico debe ser

Identificado y adquirido, sin justificar primero su necesidad durante el proceso de definición


de requerimientos funcionales.
58 EL PROCESO DE INGENIERÍA DE SISTEMAS

1 Requerimientos del sistema

Funciones de alto nivel del sistema

Funciones del sequndo nivel

5.3 5.5
(

)
5.4

Funciones del tercer nivel

5.51 1 1 5.5.2 1 1 5.5.3

Figura 2.7. Separación funcional del sistema.

Los diagramas de bloque son desarrollados esencialmente con el propósito


de estructurar los requerimientos del sistema en términos funcionales.
Estos son desarrollados para ilustrar la organización básica del sistema
e identificar las interfaces funcionales. El análisis funcional (y la generación

Necesidades
Para desarrollar la capacidad es trans-
porte entre la ciudad 'A'y la ciudad 8

FAnállala funciona¡ ;is

Transportación Transportación Transportación


terrestre aérea marftima

Resultado del análisis (selección de


la capacidad de transportación aérea)

Inicio de misión > Misión completa


ciudad A ciudad V

Análisis de factibilidad
F1io ftirdonal
de alto nivel del
sistema 2 5
_ Iel
elemeron
sésde H-i 1 1 eeeeoaleedel) 1Ia
delrina rir
1 ri a,deIedeell
1 IeoIl
r 1 IVi,ai 1 usudeo.
6
c*strbayed
jeirneos Rea9zalaióe- ~us lo delrina para
del elelema
gacdedelsis Y elernenloede uso del 0

soporledel
sriiodel
elerroerlonde
dslerna(cans J
sopada serepaefe)
sislerna
Ro del segundo nivel 1
- 9.1 9.3 9.4 9.5 9.6 9.7
Reparael i r
Tad del
Aborda desde la
Avanza desde la
Aleinzarirla
Regzala í
9.0 Reí r-I.t aerodare para arrcç*ae#o para CiudadW a la verksodn del
Cardal A Cardad A
)Pera el ei 1 1 abordar
en el ~te a(92
del asiarin Prepara el 1
L ae,or1arinde

Fko funcional del segundo nivel ----------

11
9.5 Reí. 9.5.1 9.5.2 9.53 9.5.4
[aadesiei1 [_- a el 1 Cordsota crer a RecLre
Cardad A a la —4( srdde4na de re de ccdrd re >q, —Ø rsftucdeees de

L C9dal T j

ve wicasm de la Cladad A] de la Cardad 8] elerrizar

Ø. Fodemar,rirido

Figura 2.8. Desarrollo de la evaluación de los requerimientos funcionales. 59


60 EL PROCESO DE INGENIERÍA DE SISTEMAS

de diagramas de flujo funcional) tiene la intención de hacer posible la


conclusión del diseño, desarrollo y proceso de definición del sistema de
una manera lógica y completa. Más específicamente, el enfoque funcional
ayuda a asegurar lo siguiente:

1. Que todas las facetas del diseño del sistema y desarrollo, produc-
ción, operación y soporte estén cubiertas, esto es, todas las activi-
dades significantes dentro del ciclo de vida del sistema.
2. Que todos los elementos del sistema estén completamente recono-
cidos y definidos, esto es, equipo esencial, partes de repuesto/re-
paración, prueba y equipo de soporte, facilidades, personal, datos
y software.
3. Que un medio sea proporcionado para relacionar los conceptos de
empaque del sistema y requerimientos de sistema para especificar
las funciones del sistema, esto es, satisfacer los requerimientos de
un buen diseño funcional.
4. Que las secuencias propias de actividad y relaciones de diseño sean
establecidas, junto con el diseño crítico de interfaces.

Uno de los objetivos del análisis funcional es asegurar la trazabilidad de


los requerimientos del nivel del sistema más alto hacia los requerimientos
para un diseño de detalle. En relación con la figura 2.8, se considera que hay
una necesidad de transporte entre la ciudad, "A" y la ciudad "B". A través de
la realización del análisis de factibilidad los estudios de compromisos son
realizados y el resultado indica que la transportación por aire es el modo
preferido. Subsecuentemente, mediante la definición de los requerimien-
tos operacionales, se concluyó que existe un requerimiento de un nuevo
sistema de avión, demostrando el buen desempeño y características de
efectividad con las metas cuantitativas especificadas para el tamaño, pe-
so, impulso, rango, capacidad de combustible, confiabilidad, mantenibilidad,
capacidad de soporte, costos y así sucesivamente. Un avión debe ser dise-
Ñadoy producido a fin de realizar su misión de manera satisfactoria, volando
a través de un número de perfiles operacionales tal como se ilustra en la
figura 2.8. Más adelante, el concepto de mantenimiento indica que el avión
será diseñado para soportar los tres niveles del mantenimiento por el usua-
rio, incorporará provisiones de prueba integradas y estará en uso operacional
por un ciclo de vida de diez años.
Con la información básica y siguiendo los pasos generales de la figura 2.1
uno puede comenzar con la estructuración del sistema en términos funcio-
nales. Un diagrama de flujo funcional del nivel más alto puede ser desarro-
llado para cubrir las actividades esenciales en el ciclo de vida especificado.
Cada una de estas actividades designadas puede expandirse a través del
ANÁLISIS FUNCIONAL 61

segundo nivel del diagrama de flujo funcional, una actividad del segundo
nivel en un flujo funcional del tercer nivel, y así sucesivamente.
Por medio de esta expansión progresiva de las actividades funciona-
les, dirigidas a definir los "qués" (contra los "cómos"), uno puede evolu-
cionar desde el perfil de la misión de la figura 2.8, hasta una capacidad
específica de un avión tal como "comunicaciones". Un subsistema de comu-
nicaciones es identificado, los compromisos se realizan y un planteamiento
del diseño de detalle es seleccionado. Los recursos específicos que son ne-
cesarios para responder al requerimiento funcional establecido pueden ser
identificados. En otras palabras, uno puede conducir de manera descendente
desde el nivel del sistema hasta identificar los recursos necesarios para de-
sempeñar ciertas funciones (por ejemplo, equipo, mano de obra, instalacio-
nes y datos). También, dado un requerimiento específico de equipo, uno
puede avanzar "de manera ascendente" para la justificación de ese reque-
rimiento. El análisis funcional proporciona el mecanismo de trazabilidad de
"arriba abajo".

2.5.1 Diagramas de flujo funcionales (relativos a la figura 2.7)


En el desarrollo de los diagramas de flujo funcionales, algún grado de
estandarización es necesario para las comunicaciones en la definición del
sistema. Así, ciertas prácticas básicas y símbolos deben ser usados, siem-
pre que sea posible, en la distribución física de los diagramas funcionales.
1.Bloque funcional. Cada función separada en un diagrama funcional
debe ser presentada en una sola caja encerrada por una línea sólida.
Los bloques usados para referirse a otros flujos deben ser indicados en
cajas parcialmente cerradas y etiquetadas "REF". Cada función puede ser
tan gruesa o detallada, como sea requerida por el nivel del diagrama fun-
cional en que aparece, pero debería representar una acción definida, fini-
ta, discreta, que sea realizada por el equipo, personal, facilidades, software
o alguna combinación de ellos. Las funciones tentativas o cuestionables
deben estar encerradas en bloques punteados.
2.Numeración defunciones. Las funciones identificadas en los diagramas
de flujo funcionales en cada nivel deben ser numeradas en una manera que
conserve la continuidad de las funciones y proporcione información con
respecto al origen de la función a través del sistema. Las funciones en el nivel
más alto del diagrama funcional deben ser numeradas 1.0, 2.0, 3.0, y así
sucesivamente. Las funciones de más bajo nivel contienen el mismo
identificador del padre y deben ser codificadas al siguiente nivel decimal
por cada nivel. Por ejemplo, el primer nivel de la función 3.0 debe ser 3. 1, la
segunda 3.1.1, la tercera 3.1.1.1, yasí sucesivamente. Para la expansión de
una función de alto nivel con un nivel particular, una secuencia numérica
debe ser usada para preservar la continuidad de la función. Por ejemplo, si
más de una función es requerida para ampliar la función 3.0 en un nivel, la
62 EL PROCESO DE INGENIERÍA DE SISTEMAS

secuencia debe ser 3.1, 3.2, 3.3..... 3.n. Para la expansión de la función 3.3 en
el segundo nivel, la numeración seria 3.3.1, 3.3.2,..., 3.3.n. Cuando diversos
niveles aparecen en un solo diagrama funcional, el mismo patrón debe man-
tenerse. Mientras la regla básica sea mantener el mínimo número de niveles
en cualquier flujo particular, puede ser necesario incluir varios niveles para
conservar la continuidad de las funciones y para minimizar el número de
flujos requeridos para describir funcionalmente el sistema.
3. Referencia funcional. Cada diagrama funcional debe contener una
referencia a su siguiente diagrama funcional de nivel más alto a través del
uso de un bloque de referencia. Por ejemplo, la función 4.3 debe ser
mostrada como un bloque de referencia en el caso donde las funciones 4.3.1,
4.3.2_— 4.3.n y así sucesivamente, están siendo usadas para expandir la
función 4.3. Los bloques de referencia también serían usados para indicar
las funciones de interfaz donde sea apropiado.
4. Conexión de flujo. Las líneas que conectan las funciones deben indi-
car sólo el flujo funcional y no deben representar un lapso de tiempo ni
ninguna actividad intermedia. Las líneas verticales y horizontales entre
bloques deben indicar que todas las funciones así interrelacionadas deben
ser realizadas en una forma paralela o secuencia en serie. Las líneas dia-
gonales pueden ser usadas para indicar secuencias alternativas (los casos
donde las trayectorias alternativas nos llevan a la siguiente función en la
secuencia).
S. Direcciones de flujo. Los diagramas funcionales deben ser trazados
de forma que el flujo funcional esté generalmente de izquierda a derecha
y el flujo inverso, en el caso de un lazo funcional de retroalimentación, de
derecha a izquierda. Las líneas de entrada principales deben entrar en el
bloque de función, desde el lado izquierdo; la salida primaria, o línea de
continuación de operación, debe salir a la derecha; y la línea de no seguir
debe salir de la parte inferior de la caja.
6. Las compuertas de conexión. Un círculo debe ser usado para describir
una compuerta de conexión. Como ene! caso de los bloques funcionalésfias
líneas deben entrar y (o) salir de la compuerta de conexión apropida.
La compuerta de conexión se usa para indicar las trayectorias funcionales
convergentes, o divergentes, paralelas, o alternativas y se indican con el
término AND u OR. El término AND se usa para indicar que las funciones
paralelas que llegan a la compuerta deben ser realizadas antes de proseguir
a la siguiente función, o aquellas rutas que salen de la compuerta AND deben
ser realizadas después de las funciones precedentes. El término OR se usa
para explicar que cualquiera de las diversas trayectorias alternativas (fun-
ciones alternativas) convergen, o divergen de la compuerta OR. La com-
puerta OR entonces indica que las trayectorias alternativas pueden llevar
o seguir una función en particular.
7. Trayectorias de continuación/no continuación de operación. Los sím-
bolos G y G son empleados para indicar las trayectorias de continuación/no
ANÁLISIS FUNCIONAL 63

continuación de operación, respectivamente. Los símbolos son introduci-


dos adyacentemente a las líneas que salen de una función en particular para
indicar trayectorias funcionales alternativas.
8. Procedimiento de numeración para cambios en los diagramas funcio-
nales. Las adiciones de funciones a los datos existentes deben ser realizadas
mediante la colocación de la nueva función en su posición correcta sin
considerar la secuencia de la numeración. La nueva función debe ser
numerada usando el primer número no usado en el primer nivel apropiado
para la nueva función.
Las funciones identificadas no deben estar estrictamente limitadas
a aquellas necesarias para la operación del sistema, sino que deben consi-
derarse los efectos posibles del mantenimiento en el diseño del sistema.
En la mayoría de los casos, los flujos funcionales de mantenimiento evolu-
cionarán directamente desde los flujos operacionales.

2.5.2 Funciones operacionales


Las funciones operacionales son aquellas que describen las actividades que
se realizan en respuesta a satisfacer los requerimientos de la misión, como
se presentó en la sección 2.3. Esto puede incluir una descripción de los
diversos modos de operación y utilización del sistema. Por ejemplo, las
funciones típicas de operación a grosso modo podrían incluir: 1) preparar
el avión para volar, 2) transportar el material de la fábrica al almacén,
3) iniciar comunicaciones entre el productor y el usuario, 4) producir 'x'
cantidad de unidades en una semana y 5) procesar 'y' datos para las ocho
salidas de distribución de la compañía. Las funciones del sistema necesarias
para dar soporte a los modos identificados de operación son descritos
entonces.
La figura 2.9 (una extensión de la figura 2.8) representa una serie
abreviada de flujos operacionales para un sistema dado y sus componentes.
Esto, evidentemente, puede extenderse hasta presentar con tanto detalle
como lo requiere el proceso de definición.'

2.5.3 Funciones de mantenimiento

Una vez que las funciones operacionales son identificadas, el proceso de


descripción del sistema induce al desarrollo a grosso modo de las funciones
de mantenimiento. Una verificación del requerimiento funcional aplicable
indicará una decisión de continuar/no continuar la operación. Una decisión

El lector tal vez desee revisar algunos ejemplos adicionales de los diagramas de flujo fun-
cionales. Dos fuentes son L. Woodson, W.E., Human Factors Design Handbook, MacGraw-Hill,
New York, 1981; y Blanchard, B.S. y W.J. Fabrycky, Systems Engineering andAnalysis, 2' ed.,
Prentice-Hall, Englewood Cliffs, Ni., 1990.

64 EL PROCESO DE INGENIERÍA DE SISTEMAS

Fk4o tt,idonal
de alto rveI del
sistea 32

Hi

craet 1

ri1
1 1
elenwos 1 !slemael

ri_ h
dsode
e aIend í1
II— sme
Ina!
_

H 1
Delmebe re, fb4
IDeløel
RealzaeI uebs'
H
qjeflvaedos SW«N para
del da del ala-
leenaypneba1 / H
Y elemad.
i Li
uso del
i____

1 Capde 1 bs
odedel
elemeede
cisenodel
L seredeça)

.s
Ri'o i)onald&seiado --

r 9.1 9.3 9.4 9.6

Ln 92
Repaia el 1 1 Ta del Avanza desde Ii 1 1 1 1 la
9.0 Rel. ercçlaespara a&apedo para desde la' Alemas «r la 1
H4 Cdsd a la verkacde del
[ era el sldesn1 vota
L
delusuano prepara 1
aeeoanode
apoyol
flio hjonal del seirdo nivel —— — — —— — — — —
9.5 Rel. 9.5.1 9.5.2 9.5.3 9.5.4
[Áanza deeiei [ii1 1 ma la Recte 1
Ciudad W a la 9jbaldeena de —4 lcnrede cnorcl de coerlrol irslncciunes deh*
L Ciudad de la Cuidad T alemzar

Figura 2.9. Diagrama de flujo funcional operacional.

de continuar la operación lleva la verificación de la función operacional


siguiente. Una indicación de no continuar la operación (constituye un mal
funcionamiento del sistema) proporciona un punto de inicio para el de-
sarrollo de un diagrama de flujo funcional detallado de mantenimiento.
Un flujo funcional de mantenimiento de nivel grueso se encuentra ilustrado
en la figura 2.10.

2.5.4 Aplicación de los diagramas de flujo funcionales

El análisis funcional proporciona una descripción inicial del sistema ycomo


tal sus aplicaciones son extensas. Por ejemplo, el análisis funcional es
requerido como una entrada en el desarrollo de los requerimientos siguien-
tes, aplicable para muchos programas:

1. El diseño mecánico y eléctrico para empaque funcional, monitoreo


de condición y provisiones de diagnóstico.
2. Modelos de confiabilidad y diagramas de bloque.
3. Modelo de fallas,efecto y análisis crítico (FMECA).
4. Análisis de árbol de fallas (FrA).
ANÁLISIS FUNCIONAL 65

Referirse a la figura 2.9

9.5.1
[Ref. Verifica la
comunicación
del subsistema 15.1 15.2 15.3
G Verifica la G 1 Verifica la emisión de G Verifica la emisión de la G
potencia de la comunicación (baja comunicación (alta
frecuencia) frecuencia)

Aísla el des- Suprime una unidad Transporta la unidad Aísla el mal


perfecto de la aplicable del sistema y la defectuosa a la tienda de funcionamiento del
unidad A" 1 1 remplaza con excedente mantenimiento ensamble defectuoso

Elimina el ensamble
defectuoso y lo remplaza
con el excednte

F-H de
Realiza la verificación Regresa la unidad
reparación de la operacional a los
I4 u a través
s de excedentes del
e:lizeparación l:da pruebas inventario
de la unidad en el j
lar

Figura 2.10. Diagrama de flujo funcional del mantenimiento.

S. Mantenimiento centrado en la confiabilidad (RCM).


6. Análisis de seguridad/riesgos del sistema.
7. Análisis de capacidad de mantenimiento.
8. Análisis de nivel de reparación.
9. Análisis de trabajos de mantenimiento (MTA).
10. Análisis del trabajo del operador (OTA).
11. Diagramas de secuencia operacional (OSDs).
12. Análisis de soporte logístico (LSA).
13. Procedimientos operativos y de mantenimiento.

En el pasado, el análisis funcional no siempre se completó de una


manera oportuna, si es que se completó. Como resultado, las diversas
66 EL PROCESO DE INGENIERÍA DE SISTEMAS

disciplinas de diseño asignadas a un programa dado han tenido que generar


sus propios análisis a fin de cumplir con los requerimientos del programa.
En muchos casos, estos esfuerzos fueron realizados independientemente
y muchas decisiones de diseño fueron tomadas sin el beneficio de una base
común a seguir. Esto, evidentemente, resultó en discrepancias en el diseño
y modificaciones costosas ocurridas más tarde en el ciclo de vida del
sistema. El análisis funcional proporciona una base excelente y muy nece-
saria y todas las actividades de diseño aplicables deben seguir la misma
fuente de datos a fin de cumplir los objetivos de la ingeniería de sistemas
como se estableció en el capítulo 1. Por esta razón, el análisis funcional
es considerado como una actividad clave en el proceso de ingeniería de
sistemas.

Figura 2.11. Jerarquía de los componentes del sistema.


REQUERIMIENTOS DE ASIGNACIÓN 67

2.6 REQUERIMIENTOS DE ASIGNACIÓN

El desarrollo de los requerimientos operacionales del sistema ye! concepto


de mantenimiento (secciones 2.3 y 2.4) dan como resultado la definición de
los criterios de diseño específicos al nivel de sistema. El análisis funcional
(sección 2.5) define al sistema y sus componentes más importantes en
términos funcionales, avanzando de manera descendente hasta el punto
donde los requerimientos de recursos son identificados.
Mientras el objetivo inicial es definir los "qués", ahora es apropiado
responder a los "cómos", lo que significa, ¿cómo debe ser realizada una
función dada? Esto, a su vez, conduce a la identificación y evaluación de
las diversas alternativas posibles y el sistema empieza a tener un cierto
grado de estructura. En algunos casos, una función podría ser realizada
mejor durante la utilización del equipo. En otros casos, la combinación de
una computadora y el software podría ser adecuada. En algunos eventos, el
sistema puede ser separado en componentes tales como los ilustrados en
la figura 2.11.
Con la estructura del sistema definida ahora, la pregunta es qué
requerimientos deberían ser identificados para los diversos componentes
del sistema tales que, cuando se combinen, satisfagan los requerimien-
tos del sistema global? Como el desempeño del sistema global depende del
desempeño individual de cada uno de sus componentes, es necesario que
uno establezca los requerimientos en el nivel del componente más impor-
tante a fin de asegurar que los requerimientos del sistema serán cumplidos.
La alternativa es procurar y (o) desarrollar los componentes de sistema
necesarios (con las características seleccionadas por diseñadores indivi-
duales), combinándolos en la estructura del sistema y esperando que los
resultados sean compatibles en términos de cumplir los requerimientos del
consumidor.
En otras palabras, ¡hay dos enfoques básicos! El primero es un enfoque
de arriba-abajo, que funciona desde el nivel del sistema y baja al grado
requerido para proporcionar algunos controles sobre el diseño, como una
entrada. El segundo es un enfoque de abajo-arriba, que selecciona y combi-
na los componentes favorecidos y que espera que el producto de salida
satisfaga la necesidad de manera efectiva y eficiente. El enfoque de abajo-
arriba ha sido empleado en muchos casos (con la consideración de algunas
características de diseño tales como confiabilidad, capacidad de manteni-
miento, etc.) y los resultados no han sido muy satisfactorios. Un sistema ha
sido desarrollado, no satisfará los requerimientos, amplias modificaciones
son incorporadas, los costos son altos y el consumidor está sumamente
insatisfecho.
Desde el punto de vista de la ingeniería de sistemas, un objetivo esencial
es crear y desarrollar un sistema que cumplirá los requerimientos especi-
ficados de manera efectiva y eficiente. La realización de ello demanda un
O : : c)

- - Eca
.9
E E E
D LIJ

0-0
w

. .n 12 - Cm
2ccb
c) CD O CD CM CD O

f..4 HH CM

E E
ci)

. a

IE

c; ",t

a)
cci c
ca
E
D E
uj

o
m a

68
SÍNTESIS, ANÁLISIS Y OPTIMIZACIÓN DEL DISEÑO DEL SISTEMA 69

enfoque arriba-abajo metód¡coy organizado desde el inicio, comparado con


la alternativa de "oportunidad" y la posibilidad de modificaciones "río
abajo" del sistema requeridas a fin de obtener que el sistema se desarrolle
de la manera planeada originalmente. Este enfoque de arriba-abajo involucra
la asignación de requerimientos en el nivel del sistema bajando a los diver-
sos componentes aplicables del sistema. Estos requerimientos, especifica-
dos de ambas maneras, cualitativa y cuantitativamente, son incluidos en
las especificaciones de la segunda categoría aplicables a esos componen-
tes, esto es, el desarrollo, proceso, producto y(o) especificaciones de mate-
riales indicados en la figura 2.8. La pregunta básica es ¿qué requerimientos
deben ser incluidos en la especificación para el desarrollo de la unidad
"B" del sistema "XYZ"?
Al revisar las actividades básicas del diseño en el pasado, el proceso de
asignación arriba-abajo ha sido seguido dejando de lado el establecimien-
to de ciertos requerimientos de desempeño, requerimientos de tamaño
y peso, y así sucesivamente. Hay muchos sistemas altamente sofisticados y
excelentes en uso actualmente. No obstante, el proceso de asignación no ha
sido siempre aplicado adecuadamente teniendo la confiabilidad, man-
tenibilidad, factores humanos, capacidad de soporte y las características
relacionadas, en mente. El objetivo de la ingeniería de sistemas es, eviden-
temente, promover la integración de estos factores en el proceso de asig-
nación junto con algunos de los parámetros más tradicionales relacionados
con el desempeño. La figura 2.12 ilustra la asignación de algunos de estos
factores para un sistema típico con componentes de equipo. Esta ilustra-
ción es presentada para esclarecer el enfoque arriba-abajo, mientras algu-
nas relaciones entre los parámetros indicados son discutidos más adelante,
en el capítulo 3.

2.7 SÍNTESIS, ANÁLISIS Y OPTIMIZACIÓN DEL DISEÑO DEL SISTEMA

La síntesis se refiere a la combinación y estructuración de los componentes


de manera tal que represente una configuración factible del sistema. Los re-
querimientos para un sistema han sido establecidos, algunos estudios
de compromisos preliminares han sido concluidos y una configuración de
base necesita ser desarrollada para demostrar los conceptos discutidos
anteriormente. Síntesis es diseño. Inicialmente, la síntesis se emplea para
desarrollar conceptos preliminares y para establecer las relaciones básicas
entre los diversos componentes del sistema. Más adelante, cuando la
definición funcional suficiente y la descomposición han ocurrido, la síntesis
es usada para más adelante definir los "cómos," en respuesta a los requeri-
mientos del "qué" del análisis funcional. La síntesis involucra la selección de
una configuración que podría ser representativa de la forma que el sistema
70 EL PROCESO DE INGENIERÍA DE SISTEMAS

Parámetro de
Efectividad de costos
primer orden

Costo del ciclo de vida Efectividad del sistema


segundo orden

Costo de investigación y desarrollo Desempeño


Costo de producción/ construcción Disponibilidad Parámetros de
Costo de operación y soporte Dependencia tercer orden
Costo de retiro y desecho Otras

Diseño funcional Equipo de prueba y soporto


(Eléctrico, mecánico, etc.) Soporte de suministros (repuestos)
gonfiabilidad Personal y entrenamiento Parámetros de
Mantenibilidad Facilidades cuarto orden
Factores humanos y seguridad Datos técnicos
Producibilidad Transportación y manejo
Otros Recursos computacionales

1.Accesibilidad 11. Empaque


2.Calibración 12. Adiestramiento de personal
3.Ayudas de diagnóstico 13. Seguridad
4. Desplegados/controles 14. Selección de partes
S. Aseguradores 15. ConfIabilidad de software
6.Manejo 16. Estandarización
7. Intercambiabilidad 17. Almacenamiento Parámetros de
8.Nivel de inventario 18. Adaptadores de prueba quinto orden
9.Canal de información logístico 19. Transportabilidad
10.Montaje 20. Otros

Figura 2.13. Clases de parámetros de evaluación.

tomará al último, aunque una configuración final de ningún modo es consi-


derada en este punto.6
El proceso de síntesis usualmente conduce a la definición de los
diversos enfoques alternativos posibles del diseño, que serán el tema de
mayor análisis, evaluación, refinamiento y optimización. Como estas alter-
nativas están inicialmente estructuradas, es esencial que los paráme-
tros técnicos adecuados de desempeño sean adecuadamente alineados
a los componentes aplicables del sistema. Por ejemplo, los parámetros téc-

La síntesis se verá más adelante, en el Systems Engineering Management Cuide, Defense


Systems Management College, Fort Belvoir, Virginia, 22060.
SÍNTESIS, ANÁLISIS Y OPTIMIZACIÓN DEL DISEÑO DEL SISTEMA 71

Diseña los requerimientos


(criterios-restricciones)

Alternativa AJtemafiva sJtemafiva


de diseño de diseño de diseño
1 2 3

• Define las metas de análisis


• Selecciona y da importancia a los parámetros de evaluación
(desempeño, efectividad, costo del ciclo de vida)
• Identifica los datos necesarios (datos existentes, nuevos
datos, relaciones estimadas)
Selecciona Ufl • Identifica técnicas de evaluación (simulación, programación,
planteamiento lineaVdinámica, teoría de colas)
diferente • Selecciona y (o) desarrolla un modelo
4 • Genera datos y corre un modelo (corre una base" yverifica la
exactitud del modelo)
• Evalúa las alternativas del diseño
• Realiza un análisis de sensibilidad
• Identifica las áreas de riesgo e incerfidumbre
• Recomienda una alternativa preferida

Enfoque seleccionado

No
¿Es factible el
enfoque? Si

Definición del sistema

Figura 214. Evaluación de ahemativas.

nicos de desempeño pueden incluir factores tales como peso, tamaño,


rapidez, capacidad, exactitud, volumen, rango, tiempo de proceso; junto
con los factores de confiabilidad y mantenibilidad presentados en la figu-
ra 2.12. Estos parámetros, o medidas, pueden ser jerarquizados y alineados
a los elementos apropiados del sistema, por ejemplo, un equipo, unidad
o ensamble, ítem de software.
72 EL PROCESO DE INGENIERÍA DE SISTEMAS

Cuando se definen los requerimientos iniciales del sistema, las medidas


de desempeño técnico (TPMs) se establecen basadas en su relación e
importacia para la realización de la misión, es decir, el impacto que un factor
dado tiene en la efectividad de costos, en la efectividad del sistema o en el
desempeño. Estos TPMs aplicables son jerarquizados y sus relaciones
relativas son presentadas en la forma de árbol jerárquico, como se ilustró
en la figura 2.13. El grado de las medidas de desempeño técnico, que serán
incorporadas al programa de administración y a la estructura de revisión,
variará posiblemente de un sistema al siguiente. Una medida de alto nivel
para un sistema puede ser la "con fiabilidad", mientras la "disponibilidad"
puede ser de gran importancia en otro caso. En cualquier evento, las me-
didas apropiadas necesitan ser establecidas, jerarquizadas, e incluidas en
las especificaciones. Conforme el proceso de diseño evoluciona, estas medi-
das serán empleadas para propósitos de análisis y evaluación.
Dado un número de alternativas, el procedimiento de evaluación avanza
a través de los pasos generales ilustrados en la figura 2.14 y descritos como
sigue:

1.Definición de las metas de análisis. Un paso inicial requiere el esclare-


cimiento de objetivos, la identificación de posibles soluciones alternativas
del problema a mano y una descripción del enfoque de análisis que es em-
pleado. En relación con las alternativas todos los candidatos posibles deben
ser considerados al inicio, sin embargo, entre más se consideren, el proceso
de análisis será más complejo.
Así, es deseable primero listar todos los candidatos posibles para evitar
omisiones inadvertidas y luego eliminar esos candidatos que evidentemen-
te no son atractivos, dejando sólo unos cuantos para la evaluación. Esos
pocos candidatos son entonces evaluados con la intención de seleccionar
un enfoque preferido.
2.Selección y peso de los parámetros de evaluación. Los criterios usados
en el proceso de evaluación pueden variar considerablemente dependiendo
del problema establecido, el sistema evaluado y la profundidad y comple-
jidad del análisis. Al referirse a la figura 2.13 los parámetros de importancia
esencial incluyen efectividad de costo, desempeño, disponibilidad y así
sucesivamente. En el nivel de detalle, el orden de los parámetros será
diferente. En algunos eventos, los parámetros son seleccionados, pesados
en términos de prioridad de importancia y son hechos a la medida del
sistema de manera enteramente significativa.
3. Identificación de las necesidades de datos. Cuando se evalúa una
configuración particular de un sistema, es necesario considerar los reque-
rimientos operacionales, el concepto de mantenimiento, las características
más importantes del diseño, planes de producción y (o) construcción y la
utilización anticipada del sistema y requerimientos de soporte de producto.
Para satisfacer esta necesidad se requiere una diversidad de datos, cuyo
SÍNTESIS, ANÁLISIS Y OPTIMIZÁCIÓN DEL DISEÑO DEL SISTEMA 73

alcance depende del tipo de evaluación que es realizado y la fase del pro-
grama que es realizada durante la evaluación. En las etapas iniciales del
desarrollo del sistema los datos disponibles son limitados; así, el analista
debe depender del uso de diversas relaciones estimadas, proyecciones ba-
sadas en experiencias pasadas que cubren configuraciones de sistemas
similares, e intuición. A medida que el desarrollo del sistema avanza, los da-
tos mejorados están disponibles (a través del análisis y las predicciones)
y son usados como una entrada al esfuerzo de evaluación. Hasta este punto,
es importante determinar inicialmente las necesidades específicas de los
datos (por ejemplo, tipo, cantidad y el tiempo de la necesidad) e identificar
posibles fuentes de datos. La naturaleza y validez de los datos de entrada
para un análisis dado podría tener un impacto significativo en los riesgos
asociados a las decisiones tomadas basadas en los resultados del análisis.
De este modo, uno necesita evaluar con precisión la situación tan pronto
como sea factible.
4. Identificación de las técnicas de evaluación. Dado un problema especí-
fico, es necesario determinar el enfoque analítico que habrá de usarse y las
técnicas que serán aplicadas para facilitar el proceso de solución del
problema. Las técnicas pueden incluir el uso de la simulación Montecarlo en
la predicción de eventos aleatorios río abajo del ciclo de vida, el uso de la
programación lineal al determinar requerimientos de recursos de transpor-
tación, el uso de teorías de colas para determinar los requerimientos de
producción y (o) mantenimiento del negocio, el uso de redes para estable-
cer las necesidades de distribución, el uso de métodos de contabilidad para
propósitos del costo del ciclo de vida y así sucesivamente. Evaluar e iden-
tificar el programa mismo e identificar las herramientas disponibles que
pueden ser usadas posiblemente para atacar el problema es un prerrequisito
necesario para la selección de un modelo.
S. Selección y (o) desarrollo de un modelo. El siguiente paso requiere la
combinación de varias técnicas analíticas en la forma de un modelo o una
serie de modelos como los ilustrados en la figura 2.15.1 Un modelo, como
una herramienta empleada para resolver un problema, asiste en el desarro-
llo de una representación simplificada del mundo real mientras se aplica
a la resolución del problema siendo resuelto. El modelo debe: a) representar
la dinámica de la configuración del sistema que es evaluada; b) destacar
aquellos factores que son más relevantes para el problema a mano; c) que
sea completo para incluir todos los factores relevantes y que sea confia-
ble en términos de ser capaz de repetir los resultados; d) que sea bastante
simple en la estructura de tal manera que sea posible su implemen-

Hay muchos tipos de modelos que Incluyen modelos físicos, modelos simbólicos, modelos
abstractos, modelos matemáticos, etc. El modelo, tal como se define aquí, se refiere esencial-
mente a un modelo matemático (o analítico).
74 EL PROCESO DE INGENIERÍA DE SISTEMAS

Requerimientos del sistema (requerimientos


operacionales/concepto de mantenimiento)

----------- ------------

2
Modelo de 1 1 Modelo de 1 Modelo de
empaque del 4 1 desempeño del análi sis
sistema sistema estructural

Hacia _______ Hacia


el bloque el bloque'
4 ___________
5
__________
4, 6 ______
_________
Modelo de 1 1 Modelo de 1 Modelo de
requerimientos costo del 14 análisis de
de personal ciclo de vida confiabilidad
j
1

8
Modelo de
1 Modelo de
análisis de nivel
-1
transportación 1 de reparación

H ?H 94

Modelo de tienda
__

de mantenimiento Ii 1
Modelo de
política de
______
1 Modelo de aná-
lisis de manteni-
intermedio inventario bilidad

L ----------------------

Figura 2.15. Aplicación de modelos.

tación oportuna en la solución del problema; e) que sea diseñado a fin de


que el analista pueda evaluar la configuración aplicable del sistema como
una identidad, analizar los diferentes componentes del sistema sobre una
base individual y luego integrar los resultados en el todo; que sea di-
señado para incorporar disposiciones para fácil modificación y (o) expan-
sión a fin de permitir la evaluación de factores adicionales conforme se
requiera. Un objetivo importante es seleccionar y(o) desarrollar una herra-
mienta que ayude a evaluar la configuración global del sistema, así como las
SÍNTESIS, ANÁLISIS Y OPTIMIZACIÓN DEL DISEÑO DEL SISTEMA 75

inte-rrelaciones de sus diversos componentes. Los modelos (y sus aplica-


ciones) son discutidos más adelante, en el capítulo 4.
6. Generación de datos y aplicación del modelo. Con la identificación de
las técnicas analíticas y los trabajos de selección de un modelo realizados,
el siguiente paso es "verificar" o "probar" el modelo para asegurarse de que
responde al análisis de requerimientos. ¿Cumple el modelo los objetivos
establecidos? ¿Es sensible a los parámetros más importantes de las configu-
raciones del sistema que es evaluado? La evaluación del modelo puede ser
realizada a través de la evaluación de una entidad conocida del sistema y la
subsiguiente comparación del análisis es congruente con la experiencia
histórica. Los parámetros de entrada pueden ser variados para asegurar
que las características del diseño del modelo sean sensibles a estas varia-
ciones y esencialmente reflejarán una salida precisa como resultado.

Costo del personal en función de Costo del soporte de apoyo en función


la complejidad del diseño de la estandarización del diseño

o *
o
o --
-- o

Bajo Alto Mínimo Máximo


Nivel de complejidad Estandarización

Nivel de reparación contra costos Accesibilidad de equipo contra costos

Costo total

"\ r - - - - J
1 /del costo del equipo
Prueba y soporte
`Costo total

Costo del diseño

ostodesoportede
_ Costo Costo del mantenimiento
1

Desecho de una falla Reparación detallada Escaso Bueno


Nivel de reparación Accesibilidad

F-71 de factibilidad

Figura 2.16. Ejemplo de los resuftados de evaluación.

11 El desarrollo y aplicación de los diversos modelos analíticos son cubiertos más adelante en
muchos textos de Investigación de operaciones. Tres excelentes referencias son: Hillier, F.S.
y G.J Lleberman, Introduction lo Operotions Research, 4' ed., Holden-Day, San Francisco, 1986;
Taha, HA., Operalions Research: An ¡ntroduction, 3' ed., MacMillan, Inc., New York, 1982;
y Fabrycky, W.J., P.M. Ghare y P. E. Torgersen, Applied Operations Research and Management
Science, Prentice-Hall, Engiewood Cliffs, N.J., 1984.
76 EL PROCESO DE INGENIERfA DE SISTEMAS

7.Evaluación de las alternativas de diseño. Cada una de las alternativas


que es considerada es posteriormente evaluada usando las técnicas y el
modelo seleccionado. Los datos requeridos son recopilados de diversas
fuentes tales como bancos de datos existentes, predicciones basadas en los
datos actuales del diseño y (o) proyecciones a grosso modo usando
relaciones análogas y paramétricas estimadas. Los datos requeridos, que
pueden ser tomados de una gran variedad de fuentes, deben ser aplicables
de manera consistente. Los resultados son entonces evaluados en tér-
minos de los requerimientos especificados inicialmente para el sistema. Las
alternativas factibles son consideradas más adelante. La figura 2.16 ilustra
algunas consideraciones donde posibles soluciones factibles caen en las
áreas sombreadas deseadas.
8. Realización de un análisis de sensibilidad. En el desempeño de un
análisis, puede haber algunos parámetros claves del sistema acerca de lo
que el analista está inseguro a causa de datos de entrada inadecuados,
procedimientos de predicción pobres, "empuje" de los últimos avances,
y así sucesivamente. Hay diversas preguntas que necesitan ser formuladas:
¿cuánta sensibilidad tienen los resultados del análisis a las posibles varia-
ciones de estos parámetros de entrada inciertos? ¿Hasta qué grado pueden
ser variados ciertos parámetros de entrada antes de que la elección de
alternativas se desvíe del enfoque seleccionado inicialmente? Por experien-
cia, hay ciertos parámetros claves de entrada para el análisis de costos de
ciclo de vida tal como la confiabilidad MTBFy la mantenibilidad Mct, que son
considerados críticos en la determinación del mantenimiento del sistema
y costos de soporte. Siendo muy limitados los buenos datos de campo
históricos, hay una gran cantidad de dependencia en la predicción actual
y en los métodos de estimación. De este modo, con el objetivo de minimizar
los riesgos asociados con una toma de decisión incorrecta, el analista puede
desear variar la entrada de factores MTBF y Mct sobre un rango designado
de valores (o una distribución) para ver qué impacto tiene esta variación en
los resultados de salida. Una variación relativamente pequeña de un factor
de entrada ¿tiene un gran impacto en los resultados del análisis? Si es así,
entonces estos parámetros podrían ser clasificados como TPMs críticos en
la revisión del diseño global y en el proceso de evaluación, monitoreados de
cerca conforme progresa el diseño y una tentativa adicional puede ser
generada para modificar el diseño para mejorar y los métodos de predicción
de confiabilidad y mantenibilidad. En esencia, un análisis de sensibilidad
está dirigido a la determinación de las relaciones entre las decisiones del
diseño y los resultados de salida.
9. Identificación de riesgo e incertidumbre. El proceso de evaluación de
diseño conduce a decisiones que tienen un impacto significativo en el
futuro. La selección de los criterios de evaluación, la importancia de los fac-
tores, la selección del ciclo de vida, el uso de ciertas fuentes de datos y méto-
dos de predicción y las suposiciones hechas al interpretar el resultado del
SÍNTESIS, ANÁLISIS Y OPTIMIZACIÓN DEL DISEÑO DEL SISTEMA 77

análisis influirán en estas decisiones. Los aspectos "de riesgo" e "incerti-


dumbre" son inherentes al proceso puesto que el futuro es, evidentemente
desconocido. Aunque estos términos son usados a menudo conjuntamente,
el riesgo realmente implica la disponibilidad de datos discretos en la forma
de una distribución de probabilidad sobre un cierto parámetro. La incerti-
dumbre implica una situación que puede ser probabilistica por naturaleza,
pero que no está sustentada en datos discretos. Ciertos factores pueden ser
medibles en términos de riesgo, o pueden ser establecidos bajo condiciones
de incertidumbre. El aspecto de riesgo e incertidumbre, conforme su
aplicación al diseño de sistema y procesos de desarrollo, debe ser integrado
al plan de administración de riesgos de programa descritos en el capítulo 6,
sección 6.5.
10. Recomendación de un enfoque preferido. El paso final en el proceso
de evaluación es la recomendación de una alternativa preferida. Los resul-
tados deberían estar completamente documentados y estar disponibles
para todo el personal aplicable de diseño del proyecto. Una descripción de
consideraciones, una descripción del procedimiento de evaluación que fue
seguido, una descripción de las diversas alternativas que son consideradas
y una identificación de las áreas potenciales de riesgo e incertidumbre
deben de ser incluidas en este reporte de análisis.

En relación con la figura 1.7, los requerimientos para el sistema son


establecidos en diseño conceptual. El análisis funcional y la asignación
son realizados después en el diseño conceptual o al inicio del diseño del sis-
tema preliminar y el diseño detallado es realizado en una base progresiva a
partir de ellos.
Durante esta serie de pasos globales, hay un esfuerzo continuo de
involucrar síntesis y análisis de optimización de diseño. En etapas anterio-
res al diseño, los estudios de compromisos pueden vincularse a la evalua-
ción de los perfiles operacionales alternativos, los sistemas de distribución
o conceptos de mantenimiento. Durante el diseño preliminar anterior, los
métodos alternativos para realizar una función dada o un plan de equipo de
empaque alternativo puede ser el enfoque del análisis. En el diseño de de-
talle, los procesos estarán en el nivel más bajo de la estructura jerárquica
global del sistema.
En cualquier evento, el proceso discutido en la sección 2.7 (e ilustrado
en la figura 2.14) es aplicable durante el diseño de sistema y el esfuerzo de
desarrollo. La única diferencia que existe es en la profundidad del análi-
sis, el tipo de datos requerido y el modelo usado para realizar el análisis.
Por ejemplo, uno puede realizar un análisis de costo del ciclo de vida des-
de el diseño conceptual o después en el diseño de detalle.
El proceso es el mismo en cualquier caso; no obstante, la profundidad
del análisis y los requerimientos de los datos son diferentes. La síntesis,
análisis, proceso de evaluación pueden ser diseñados de acuerdo con el
78 EL PROCESO DE INGENIERÍA DE SISTEMAS

problema. Un esfuerzo muy pequeño resultará en grandes riesgos asocia-


dos a la toma de decisiones en el diseño y también mucho esfuerzo de
análisis será costoso.

2.8 PRUEBA Y EVALUACIÓN

Conforme el diseño y desarrollo del sistema avanzan, es necesario tener un


esfuerzo de medición y evaluación continuo, como se indicó en la figura 1.9.
En realidad, una evaluación completa del sistema, en términos de cumplir
los requerimientos del consumidor especificados inicialmente, no puede
ser realizada hasta que el sistema sea producido y esté funcionando en un
ambiente operacional. No obstante, si ocurren problemas y las modificacio-
nes del sistema son necesarias, la realización de esto más adelante en etapas
avanzadas en el ciclo de vida puede resultar bastante costoso. Entre más
pronto se detecten y corrijan los problemas, los costos asociados serán
menores.
Cuando se trata el tema de evaluación, el objetivo es adquirir un alto
grado de confianza, tan pronto como sea posible en el ciclo de vida, en que
el sistema se desempeñe como se intente. La realización de esto, a través de
llevar a cabo pruebas de laboratorio y de campo involucrando una réplica
física del sistema (y [o] sus componentes) puede ser bastante costosa.
Los recursos requeridos para probar son bastante costosos a menudo y las
facilidades necesarias, equipo de prueba, personal, etc., pueden ser difíci-
les de planear. Sabemos ya que una cierta cantidad de pruebas formales es
requerida a fin de verificar adecuadamente qué requerimientos del sistema
han sido cumplidos.
Por otra parte, con un esfuerzo de análisis más completo en las etapas
iniciales del diseño, es posible verificar ciertos conceptos de diseño me-
diante el uso de métodos analíticos. Con el advenimiento de las bases de
datos tridimensionales y la aplicación de técnicas de simulación, el diseñador
puede ahora realizar un gran trabajo relativo a la evaluación de los diseños
de sistemas, las relaciones e interferencias de los componentes, interfaces
hombre-máquina, y así sucesivamente.
Hay muchas funciones que ahora pueden ser realizadas con la simula-
ción computarizada que requieren formalmente una imitación del sistema,
una producción de un modelo prototipo, o ambos. La disponibilidad de
diseño asistido por computadora (CAD), la manufactura asistida por
computadora (CAM), la creación y soporte logístico asistido por compu-
tadora (CALS) y las tecnologías relacionadas han hecho posible realizar
muchas cosas en el área de evaluación del sistema, relativamente temprano
en el ciclo de vida cuando la incorporación de los cambios puede ser
realizada con un costo mínimo.
PRUEBA Y EVALUACIÓN 79

Diseño
conceptual
1 Diseño
preliminar del
1 Diseño
y desarrollo de detalle
Producción
y (°)
Utilización del
sistema y soporte
sistema construcción del ciclo de vida
A Requerimientos definidos de Evaluación continua
del sistema en uso operacional
prueba y evaluación del sistema
Modelos de produccjón
evaluados en los lugares
Evaluación M de prueba designados
prototipo y modelos
de producción (ejemplos
Evaluación de de produecíón)
ingenlorfa y
modelos de prueba de
servicio, componentes Pa
del sistema imitaciones to 4
Evaluación usando
estaciones de trabajo de diseño
y modelos analíticos Prueba
(CAD, CAE, CAM, C

Prueba
1 o2 l
Prueba 1 l
tipo 1 1
Analítica

Ciclo de vida del sistema ---

Figura 2.17. Etapas de la evaluación del sistema durante el ciclo de vida.

Al determinar las necesidades para prueba y evaluación, uno comien-


za con la especificación inicial de los requerimientos del sistema en el di-
seño conceptual. Conforme las medidas de desempeño técnico específicos
(TPMs) son establecidas, es necesario determinar los métodos a través de
los cuales el cumplimiento de estos factores se verifique. ¿Cómo serán me-
didos los TPMs y qué recursos son necesarios para realizarlo? La respuesta
a esta pregunta puede estar en la manera de utilizar los métodos analíti-
cos usando un modelo ingenieril para propósitos de prueba y evaluación
probando un modelo de producción, evaluación de una configuración ope-
racional en el ambiente del consumidor, o una combinación de restos.
En esencia, uno necesita revisar los requerimientos del sistema, determinar
los métodos que pueden ser usados en el esfuerzo de evaluación y la efec-
tividad anticipada de estos métodos y desarrollar un plan completo para
una prueba integrada global y un esfuerzo de evaluación (por ejemplo, plan
maestro de prueba y evaluación). Como punto de referencia, la figura 2.17
es presentada para ilustrar las categorías sugeridas de prueba conforme
pueden aplicarse en la evaluación del sistema.
80 EL PROCESO DE INGENIERÍA DE SISTEMAS

2.8.1 Categorlas de prueba y evaluación9

Al referirse a la figura 2.17, la primera categoría es "analítica", la cual se


refiere a ciertas evaluaciones de diseño que pueden ser realizadas tem-
pranamente en el ciclo de vida del sistema usando las técnicas compu-
tarizadas para incluir CAD, CAM, CALS, simulación y enfoques relacionados.
Con la disponibilidad de una gran variedad de modelos, bases de datos
tridimensionales etc., ahora le es posible al ingeniero de diseño simular
interfaces de equipo humano, planes de empaque de equipo, las estructuras
jerárquicas de los sistemas y secuencias de actividad/trabajos. Además,
mediante de la utilización de estas tecnologías le es posible al ingeniero de
diseño hacer un mejor trabajo de predicción y pronósticos, y la realiza-
ción de análisis de sensibilidad/contingencia con el objetivo de reducir
futuros riesgos. En otras palabras, se pueden realizar varias cosas respecto
a la evaluación del sistema que, en el pasado, no podían realizarse hasta que
el equipo estuviera disponible en las fases tardías del diseño de detalle y de-
sarrollo.
La "prueba tipo 1" se refiere esercialmente a la evaluación de los
componentes del sistema en el laboratorio usando tableros de prueba,
modelos de prueba de servicio y similares. Estas pruebas son diseñadas
esencialmente con la intención de verificar ciertas características de des-
empeño y físicas, y son evolucionantes por naturaleza. Los modelos de
prueba usados operan de manera funcional (por ejemplo, eléctrica
y mecánicamente), pero de ninguna forma representan equipo de produc-
ción. Tal prueba es usualmente realizada en el laboratorio del productor/
proveedor por técnicos capacitados que usan equipo de prueba especial y
notas de ingeniería para procedimientos. Eso es durante la fase inicial de la
prueba, cuando los conceptos de diseño y aplicaciones de tecnología son
verificados y los cambios pueden ser iniciados a un costo mínimo.
La "prueba tipo 2" incluye pruebas formales y demostraciones realiza-
das durante las etapas tardías del diseño de detalle y fase de desarrollo,
cuando el equipo prototipo preproducción ye! software están disponibles.
El equipo prototipo es similar al equipo de producción (que será entregado
para uso operacional), pero no está enteramente calificado hasta este
momento.'°

Las categorías de prueba y evaluación pueden variar por tipo de sistema o de acuerdo con la
organización funcional. El autor seleccionó estas categorías como punto de referencia para
discusiones en este texto.
° El equipo "calificado" se refiere a la configuración de la producción que ha sido verificada
a través de la conclusión exitosa de las pruebas de calificación de ambiente (por ejemplo, ciclos
de temperatura, impacto y vibración), calificación de confiabilidad, demostración de manteni-
bilidad y pruebas de compatibilidad de capacidad de soporte. La prueba tipo 2 esencialmente
se refiere a la actividad asociada con la calificación de un sistema.
PRUEBA Y EVALUACIÓN SI

Un programa de prueba en esta área puede constituir una serie de


pruebas individuales, confeccionadas de acuerdo con la necesidad, que
incluye lo siguiente:

1. Calificación del ambiente. Ciclo de temperatura, impacto y vibra-


ción, humedad, arena y polvo, rocío salino, ruido acústico, prueba
de explosión e interferencia electromagnética.
2. Calificación de confiabilidad.
Prueba secuencial, prueba de vida,
prueba de esfuerzo ambiental (ESS) y prueba, análisis y (TAAF)
compostura.
3. Demostración de manten ibilidad. La verificación de los trabajos de
mantenimiento, tiempos de trabajo ysecuencias, cantidades de per-
sonal de mantenimiento y niveles de adiestramiento, grado de capa-
cidad de prueba y provisiones de diagnóstico, equipo esencial-
interfaces de prueba del equipo, procedimiento de mantenimiento
y lo-calidades de mantenimiento.
4. Compatibilidad del equipo de soporte. La verificación de la compati-
bilidad entre el equipo esencial, el equipo de prueba y soporte y el
equipo de manejo terrestre.
S. Verificación de datos técnicos. La verificación (validación) de proce-
dimientos operativos, procedimientos de mantenimiento y datos de
soporte.
6. Prueba y evaluación personal. La verificación para asegurar la
compatibilidad entre lo humano y el equipo, la cantidad de personal
y los niveles de adiestramientos requeridos y necesidades de entre-
namiento.
7. Compatibilidad de software. La verificación de que todo el software
cumple los requerimientos del sistema, la compatibilidad entre el
software y el hardware y de que las provisiones de calidad adecua-
das han sido incorporadas.

Otra faceta de prueba en esta categoría es la producción de pruebas


muestra, usadas cuando múltiples cantidades de un ítem están siendo
producidas. Aunque el sistema (y sus componentes) haya pasado exi-
tosamente las pruebas de calificación inicial, existe la necesidad de que algo
asegure que el mismo nivel de calidad ha sido mantenido durante el proceso
de producción. El proceso es usualmente dinámico por naturaleza, las
condiciones cambian y no hay garantía de que las características que han
sido incorporadas al diseño serán mantenidas durante la producción.
De este modo, los sistemas muestra/componentes pueden ser selecciona-
dos (basados en un porcentaje de la producción total) y las pruebas de
82 EL PROCESO DE INGENIERÍA DE SISTEMAS

calificación pueden ser dirigidas en bases recurrentes. Los resultados son


medidos y evaluados en términos de si la mejora o degradación ha ocurrido.
La "prueba tipo 3" incluye la conclusión de pruebas formales en lugares
de pruebas de campo designadas por el personal usuario en un periodo
extenso de tiempo. Estas pruebas usualmente son conducidas después de
la calificación inicial del sistema y antes de la conclusión de la fase de pro-
ducción. El personal operativo, prueba operacional y equipo de soporte,
excedentes operacionales y procedimientos de operación de validación
y mantenimiento son empleados. Esta es la primera vez que todos los ele-
mentos del sistema (por ejemplo, equipo esencial, software y los elementos
de soporte) son operados y evaluados en forma integrada. Una serie de
ejercicios operacionales simulados son usualmente manejados y el sistema
es evaluado en términos de desempeño, efectividad, la compatibilidad entre
los segmentos esenciales orientados a la misión del sistema y los elementos
de soporte, etc. Aunque la prueba de tipo 3 no representa completamente
una situación operacional, las pruebas pueden ser diseñadas para propor-
cionar una aproximación cercana.
La "prueba tipo 4" manejada durante el uso operacional del sistema y la
fase de soporte del ciclo de vida, incluye pruebas formales, las cuales
algunas veces son realizadas para adquirir información específica referente
a un área de operación o soporte. El propósito es obtener suficiente cono-
cimiento del sistema en el ambiente del usuario, o de las operaciones del
usuario en el campo. Puede ser deseable variar el perfil de la misión o el
promedio de utilización del sistema para determinar el impacto de efectivi-
dad total del sistema, o puede ser factible evaluar diversas políticas de
soporte alternativas para ver si la disponibilidad operacional del sistema
puede ser mejorada. La prueba de tipo 4 es realizada en uno o más sitios
operacionales, en un ambiente realista, por el operador usuario y personal
de mantenimiento y es sustentado durante la capacidad logística normal.
Esta es realmente la primera vez que será realmente conocida la capacidad
verdadera del sistema.

2.8.2 Planeación de pruebas

La planeación de pruebas comienza en la fase conceptual del diseño cuando


los requerimientos del sistema son establecidos inicialmente. Si un reque-
rimiento tiene que ser especificado, es necesario que haya una forma de
evaluar el sistema más tarde para asegurar que el requerimiento ha sido
cumplido. Así, las consideraciones para prueba y evaluación son intuitivas
desde el inicio.
Al referirse a la figura 1.8, la planeación de prueba inicial se incluye en
un plan maestro de prueba y evaluación (TEMP), publicado en la fase del di-
seño conceptual. El documento incluye los requerimientos de prueba y eva-
luación, las categorías de prueba, los requerimientos para la realización de
PRUEBA Y EVALUACIÓN 83

pruebas, los recursos requeridos e información de planeación asociada


(trabajos, planes, responsabilidades organizacionales y costos)."
Uno de los objetivos claves de este plan, de particular importancia para
la ingeniería de sistemas, es la integración completa de los diversos reque-
rimientos de prueba para el sistema global. Al referirse al contenido de la
prueba tipo 2 (sección 2.8.1), los requerimientos individuales pueden ser
especificados para la calificación ambiental, calificación de confiabilidad,
demostración de mantenibilidad, etc. Estos requerimientos, contienen una
serie de especificaciones independientes que pueden traslaparse en algu-
nos casos y ser conflictivas en otros. Más adelante, no todas las configura-
ciones del sistema deben estar sujetas a los mismos requerimientos de
prueba. En situaciones donde hay nuevas aplicaciones de tecnología de di-
seño, más evaluaciones iniciales pueden ser deseables ylos requerimientos
para la prueba tipo 1 pueden ser diferentes para una situación que involucra
el uso de los métodos de diseño del bien conocido estado del arte. En otras
palabras, en las áreas donde los riesgos técnicos potenciales son altos, el
requerimiento para un esfuerzo de evaluación más extensa al inicio del ciclo
de vida puede ser factible.
En cualquier evento, el TEMP representa una entrada importante rela-
tiva a cumplir los objetivos de la ingeniería de sistemas. Uno no sólo debe
entender los requerimientos globales del sistema, sino que es necesario co-
nocer las relaciones funcionales entre los diversos componentes del siste-
ma. También, aquellos involucrados en la planeación de prueba deben estar
familiarizados con los objetivos de cada requerimiento de prueba específi-
co tal como la calificación de confiabilidad o la demostración de manteni-
miento, etc)2 Un enfoque integrado total para la prueba y evaluación es
esencial, particularmente cuando se consideran los costos asociados a las
actividades de prueba.

2.8.3 Preparación para la evaluación y prueba del sistema

Antes de empezar la prueba formal, un período adecuado de tiempo es


designado con el propósito de preparación de la prueba. Durante este

11 En el sector de defensa, el TEMP es requerido para los programas más grandes, e Incluye la

planeación e implementación de procedimientos para la Prueba y Evaluación de Desarrollo


(DT&E) y la Prueba y Evaluación Operacional (OT&E). DT&E básicamente es Igual alas pruebas
analíticas tipo 1 y tipo 2 descritas en la sección 2.8.1 y OT&E es equivalente a las pruebas tipo
3 y tipo 4. Véase System and Engineering Management Guide, Defense Systems Management
College (DSMc, Fort Belvoir, Virginia 22060, 1986; Stevens, R.T., Operational TestandEua1uation
John Wil, New York, 1979; y DODD-5000.3, "Test and Evaluation", Departamento de Defensa,
Washington, D.C.
12
Los requerimientos detallados para la prueba de calidad, la demostración de mantenibihdad
y otras pruebas especializadas son cubiertas a detalle en el capítulo 3.
84 EL PROCESO DE INGENIERÍA DE SISTEMAS

tiempo, las condiciones adecuadas deben ser establecidas para asegurar


resultados efectivos. Estas condiciones, evidentemente, variarán depen-
diendo de la categoría de la prueba que es emprendida.
Durante las fases iniciales del diseño y desarrollo, conforme evaluacio-
nes analíticas y pruebas tipo 1 son realizadas, la extensión de la preparación
de la prueba es mínima.
Por otra parte, la realización de las pruebas de tipo 2y tipo 3, donde las
condiciones son diseñadas para estimular las operaciones reales del consu-
midor en la máxima extensión posible, requerirá igualmente un esfuerzo de
preparación bastante extenso. A fin de facilitar un ambiente real, los
siguientes factores necesitan ser tratados:

1. Selección del (tem de prueba. El sistema (y sus componentes)


seleccionado para prueba debe representar el diseño más actualiza-
do o la configuración de producción, incorporando todos los últi-
mos cambios de ingeniería aprobados.
2. Selección del sitio de prueba. El sistema debe ser probado en un
ambiente que será característico para las operaciones del usuario,
es decir, ártico o trópico, terreno plano o montañoso, aéreo o te-
rrestre. El sitio de prueba seleccionado debe simular estas condicio-
nes en el mayor grado posible.
3. Procedimientos de prueba. Elcumplimiento de estos objetivos de
prueba usualmente involucra la realización de ambos trabajos, del
operador y de mantenimiento, y la conclusión de estos trabajos
debe seguir los procedimientos formales aprobados (por ejemplo,
manuales técnicos validados). Las secuencias de trabajo recomen-
dadas deben ser seguidas para asegurar la operación adecuada del
sistema.
4. Personal de prueba. Esto incluye a) los individuos que realmente
operarán y mantendrán el sistema durante la prueba y b) ingenieros
de soporte, técnicos, archivistas de datos, analistas y administrado-
res que proporcionan asistencia en el manejo del programa de
prueba global. El personal seleccionado para la primera categoría
debe ser representativo de los requerimientos del usuario (o consu-
midor) en términos de las cantidades recomendadas, niveles de
adiestramiento y necesidades de entrenamiento y soporte.
S. Prueba y equipo de soporte. La realización de los trabajos
operacionales y de mantenimiento del sistema puede requerir el
uso de manejo de equipo terrestre, equipo de prueba y (o) una
combinación de ellos. Sólo esos ítems que han sido aprobados para
operación deben ser usados.
PRUEBA Y EVALUACIÓN 85

6. Apoyo de soporte. Esto incluye todos los repuestos, partes de


reparación, consumibles e inventarios de soporte que son necesa-
rios para la conclusión de la prueba y la evaluación del sistema.
De nuevo, una configuración real, proyectada en un ambiente del
mundo real, es deseada.
7. Instalaciones de prueba y recursos. La realización de la prueba del
sistema puede requerir el uso de Instalaciones especiales, oficinas
de prueba, equipo, capital, control ambiental, instrumentación
especial y recursos asociados (por ejemplo, calor, agua, aire acon-
dicionado, energía, teléfono). Estas instalaciones y recursos deben
ser identificados y planeados adecuadamente.
En resumen, la naturaleza de la función de preparación de prueba de-
pende en gran medida de los objetivos globales del esfuerzo de pruebay eva-
luación. Independientemente de los requerimientos, estas consideraciones
son importantes para la conclusión exitosa de estos objetivos.

2.8.4 Desempeño y evaluación de la prueba


Con las preparaciones necesarias en su lugar, el siguiente paso es comenzar
la prueba formal y la evaluación del sistema. El sistema (o elementos de él)
es operado y sustentado en una manera designada, como está definida en
el TEMP. Durante este proceso los datos son recopilados y analizados y los
resultados son comparados con los requerimientos inicialmente especifi-
cados. Con el sistema en estado operacional (ya sea "real" o "simulado"), las
siguientes preguntas surgen:
1. ¿Cuál es la efectividad verdadera del sistema?
2. ¿Cuál es el desempeño verdadero del sistema?
3. ¿Cuál es la efectividad verdadera de la capacidad de soporte del
sistema?
4. ¿El sistema cumple todos los requerimientos que son cubiertos
a través de las medidas de desempeño técnico (FPMs) especifi-
cadas?
S. ¿El sistema cumple todos los requerimientos del consumidor?
Una respuesta a estas preguntas requiere la capacidad de retroali-
mentación de los datos de información con la salida apropiada de manera
oportuna. Un subsistema de datos debe ser desarrollado e implementadocon
la meta de alcanzar ciertos objetivos y estos objetivos deben relacionarse
con estas preguntas. 3

Los requerimientos de datos y el desarrollo de un subsistema de datos son discutidos en el


capítulo 6 de Blanchard, B.S. y W.J. Fabrycky,Sys:ems Engineering andAnalysis, 2' ed., Prentice-
Hall, Englewood Cliffs, Ni., 1990.
Requerimientos del sistema

Requerimientos de prueba y evaluación

Planeación de prueba

Plan Maestrode Prueba Evaluación (TEMP)

Preparación de prueba y evaluación

Realización de la prueba Requerimientos de

Recolección de datos Modelos analíficos

Evaluación del desempeño delsistema, efec-


tividad, capacidad de soporte y parámetros
sí relacionados.

¿Existe un requeri- 'C'Cumple Liberar el sistema


si
miento para una tema los reque- para uso del
jento," consumidor
YNo

Evaluación e identificación del problema Base de datos histórica (historia


del problema)

K
Verificación de si la j
modificación corrigió el una acción co No se requiere acción
problema E5 eq

Inicia la planeación para una acción________ Base de datos histórica


correctiva (experiencia pasada)

Inician los cambios en el diseño


Desarrollar un conjunto de
modificaciones al sistema

Instala el conjunto de modificaciones


U sistema

Figura 2.18. Evaluación del sistema y lazo de acción correctiva.

86
PRUEBA Y EVALUACIÓN 87

El proceso asociado con la piiieba formal de recopilación de datos,análisis


y evaluación de datos se muestra en la figura 2.18. La prueba es manejada,
los datos son recopilados y evaluados, y las decisiones son tomadas como
si la configuración del sistema (en esta etapa) cumpliera los requerimientos.
De no ser así, las áreas problema son identificadas ylas recomendaciones
son iniciadas para una acción correctiva.
El último paso en el esfuerzo de evaluación global es la preparación de
un reporte de prueba final. El reporte debe hacer alusión al documento
de planeación de prueba inicial (por ejemplo, el TEMP), describir todas las
condiciones de prueba, los procedimientos seguidos durante el manejo de
la prueba, identificar las fuentes de datos y los resultados del análisis e in-
cluir algunas recomendaciones para acciones correctivas o mejoras. Pues-
toque esta fase de actividad es bastante extensa y representa un indicador
crítico en el ciclo de vida, la generación de un buen reporte extenso de
prueba es esencial desde el punto de vista histórico.

2.8.5 Modificaciones del sistema

La introducción de un cambio en un ítem de equipo, un programa de


software, un procedimiento o un elemento de soporte afectará posible-
mente los muy diversos componentes del sistema. Los cambios de equipo
afectarán las partes de repuesto, el equipo de prueba, los datos técnicos
y tal vez ciertos procesos de producción. Por otra parte, los cambios de
procedimientos afectarán al personal y los requerimientos de entrena-
miento. Los cambios de software pueden afectar el hardware y los datos téc-
nicos. Un cambio en un componente dado del sistema posiblemente tendrá
un impacto (de cualquier clase) en la mayoría, si no es que en todos, los
otros componentes más importantes del sistema.
Las recomendaciones para cambios desarrollados a partir de la prueba
y evaluación, deben ser tratados en forma individual. Cada cambio propues-
to debe ser evaluado en términos de su impacto en los otros elementos del
sistema y en el costo del ciclo de vida, antes de formar la decisión de
incorporar o no el cambio. La factibilidad de incorporar el cambio depende-
rá de lo extenso del cambio, su impacto en el sistema en términos de su
capacidad de desempeñarla misión designaday el costo de la implementación
del cambio.
Si un cambio tiene que ser incorporado, los procedimientos de control
de cambios descritos en el capítulo 5 deben ser implementados. Esto
incluye la consideración del tiempo cuando el cambio tiene que ser incor-
porado, el ítem(s) apropiadamente numerado en serie, afectado en una
cantidad de producción dada, los requerimientos para rehabilitación en los
primeros ítems numerados en serie, el desarrollo y "prueba" de los conjun-
tos de modificaciones de cambio, la localidad geográfica donde el conjunto
de modificaciones será instalado y los requerimientos para la revisión del
88 EL PROCESO DE INGENIERÍA DE SISTEMAS

sistema y la verificación después de la incorporación del cambio. Un plan


debe ser desarrollado para cada cambio aprobado que se implementa.

2.9 PRODUCCIÓN Y (0) CONSTRUCCIÓN

Dependiendo del sistema desarrollado y la naturaleza de su misión puede


haber un requerimiento del producción en seguida', o puede haber un re-
querimiento de construcción (véase la figura 1.2, ejemplos "A" y "B,"
respectivamente). En cada caso, hay ciertos retos únicos que deben ser
tratados para asegurar que la configuración del sistema que fue diseñada
inicialmente y verificada durante la evaluación, conserve las mismas carac-
terísticas a medida que avance a través de los procesos de producción
o construcciónUn sistema puede demostrar un cierto grado de efectividad
durante la prueba formal yevaluación No obstante, las réplicas subsiguien-
tes de esa configuración del sistema que es producida en múltiples cantida-
des quizá no exhiban las mismas características. La degradación puede
ocurrir como resultado de una combinación de variaciones permitidas en
el diseño y (o) variaciones de los diversos procesos de manufacturas
usados en la producción. Un efecto similar puede tener lugar si la calidad de
la mano de obra no se mantiene durante la construcción de la configuración
de un sistema único-en-su-clase.
Las experiencias actuales indican que el diseño básico, dado que un
buen diseño robusto existe inicialmente, puede ser influido significativamente
durante los procesos siguientes empleados en producción y (o) construc-
ción. En vista de esto, es necesario para la continuación del énfasis de la
ingeniería de sistemas y actividades durante la fase de producción/cons-
trucción del ciclo de vida. Estas actividades son discutidas más adelante en
el capítulo 6.'

2.10 USO OPERACIONAL DEL SISTEMA Y APOYO DE SOPORTE

En el diseño del sistema y proceso de desarrollo, la consideración debe


estar dirigida hacia 1) los segmentos esenciales orientados a la misión del
sistema para la capacidad de soporte, y 2) el diseño del mantenimiento y la
capacidad misma de soporte del sistema (véase la figura 1.2, ejemplos "A"
y "B"). El primer ítem trata las habilidades inherentes del sistema que son
soportadas de manera efectiva y eficiente, mientras el segundo ítem cubre

11 En el sector de defensa, el Departamento de Defensa ha reconocido estas Interfaces y hay

actualmente una gran cantidad de énfasis colocada en "ingeniería concurrente", "ingeniería


simultánea" y similares. Estos conceptos incluyen algunos de los mismos objetivos que se
definieron para la ingeniería de sistemas en el capítulo 1.
RESUMEN 89

los recursos requeridos para asegtirar un soporte del sistema, tomando en


cuenta el apoyo. Aunque un sistema puede ser diseñado y producido con las
características de efectividad requeridas e incorporadas, estas caracterís-
ticas necesitan ser mantenidas durante la duración del ciclo de vida me-
diante la realización de buenas prácticas de mantenimiento y soporte.
Los objetivos de la ingeniería de sistemas no sólo incluyen la creación
inicial de un sistema con las características requeridas, sino el mante-
nimiento continuo de ese sistema en el nivel requerido de efectividad.
La degradación no debería tener lugar como resultado de prácticas de man-
tenimiento y soporte inadecuados. De este modo, el énfasis de la ingeniería
de sistemas necesita continuar durante el uso operacional del sistema
y apoyo de soporte de la fase del ciclo de vida. Esto es básicamente
realizado durante las actividades de logística descritas en el capítulo 3.

2.11 RETIRO Y DESECHO DEL SIEMA

Tomando en cuenta la importancia del impacto ambiental que existe


actualmente, la consideración debe ser dirigida no sólo a la creación y
utilización del sistema durante el ciclo de vida intentado, sino a los reque-
rimientos asociados al retiro del sistema y el desecho adecuado de sus
componentes. Hay muchos sistemas actualmente en uso que cuando sean
obsoletos, serán costosos en la fase de salida del inventario. Aunque
algunos componentes del sistema pueden ser reciclados adecuadamente
y los materiales resultantes están disponibles para otros usos, hay un nú-
mero de otros componentes que no puede ser consumido sin crear un
impacto en detrimento del ambiente.
Al referirse al papel de ingeniería de sistemas, los objetivos del progra-
ma necesitan tratar la fase de retiro y desecho del ciclo de vida, así como
también a las fases iniciales. El diseño para "capacidad de desecho" debe
estar incluido en los criterios para análisis y decisiones de diseño iniciales.

2.12 RESUMEN

Aunque algunos términos ydefiniciones fueron introducidos en el capítu-


lo 1, el propósito de este capítulo es relacionar estos con el ciclo de vida del
sistema. Más adelante, una base necesita ser establecida con objeto de pro-
porcionar un marco de referencia para la discusión de las disciplinas in-
dividuales del diseño, los métodos de diseño ylas actividades asociadas con
la ingeniería de sistemas.
El proceso de ingeniería de sistemas, discutido en este capítulo, es
presentado en forma panorámica. Conforme uno prosigue con los capítulos
90 EL PROCESO DE INGENIERÍA DE SISTEMAS

subsiguientes de este texto, los conceptos introducidos aquí serán amplia-


dos en mayor grado. No obstante, el material de este capítulo es un prerre-
quisito necesario para la información presentada posteriormente.

PREGUNTAS Y PROBLEMAS

1. Identifique los pasos básicos en el proceso de ingeniería de sistemas


y describa algunas de las "entradas" y "salidas" asociadas con cada
paso.
2. ¿Cuál es el propósito del análisis de factibilidad? ¿Qué información
se desea de tal análisis?
3. Seleccione un sistema y defina los requerimientos operacionales
básicos del sistema. Defina el concepto de mantenimiento para ese
sistema (utilice diagramas de flujo a fin de mejorar el proceso de de-
finición).
4. ¿Por qué la definición de los requerimientos operacionales as¡ como
el concepto de mantenimiento son tan importantes en el diseño
conceptual?
S. ¿Qué se entiende por "análisis funcional"? ¿Por qué es importante
en la ingeniería de sistemas? ¿Para qué propósitos sirve?
6. Seleccione un sistema y construya un diagrama de bloque funcional
mostrando tres niveles de funciones operacionales. Muestre dos
niveles de funciones de mantenimiento. ¿Cómo se relacionan las
funciones operacionales y las funciones de mantenimiento?
7. ¿Cuál es el propósito de la asignación? ¿Cómo afecta al diseño de
sistemas?
S. ¿Cuáles son los pasos básicos involucrados en el análisis del siste-
ma? Construya un diagrama de flujo básico que ilustre el proceso,
mostrando los pasos, yque incluya provisiones de retroalimentación.
9. Describa qué entiende por "síntesis".
10. ¿Cuáles son las medidas de desempeño técnico (TPMs)? ¿Cómo se
determinan? ¿Cuáles son las prioridades establecidas en términos
de factores de importancia relativa?
11. ¿Qué es un "modelo"? Identifique algunas características básicas.
Liste algunos de los beneficios relacionados con el uso de modelos
matemáticos en el análisis del sistema. ¿Cuáles son algunos intere-
ses-problemas?
PREGUNTAS Y PROBLEMAS 91

12. ¿Qué se entiende por "análisis de sensibilidad"? ¿Cuáles son los


objetivos? ¿Cuáles son los beneficios?
13. Describa el proceso de evaluación del sistema. ¿Cuál es el objetivo
global?
14. Seleccione un sistema y desarrolle un plan de prueba y evaluación
abreviado. Identifique las categorías de prueba y describa las
entradas y salidas para cada categoría.
15. ¿Cómo se determinan los requerimientos de prueba de sistema?
16. Describa algunas de las consideraciones asociadas con el inicio de
los cambios del diseño como resultado de la prueba y evaluación.
17. ¿Por qué es importante la ingeniería de sistemas en la fase de pro-
ducción/construcción? ¿Fase de uso operacional y de apoyo de
soporte? ¿Fase cíe retiro y de desecho?
3
REQUERIMIENTOS DEL DISEÑO
DE SISTEMAS

Los requerimientos del diseño de sistemas evolucionan desde la descrip-


ción de la necesidad y se desarrollan a través de la realización de un análisis
de factibilidad, la definición de los requerimientos operacionales, el concep-
to de mantenimiento, la conclusión del análisis funcional y la distribución,
es decir, aquellas actividades que se realizan al principio en el proceso de
ingeniería de sistemas descrito en el capítulo 2. Inicialmente, aquellos reque-
rimientos se desarrollan para proporcionar una definición completa del
sistema en términos funcionales. Conforme el desarrollo del sistema
progresa, estos requerimientos se definen con bastante detalle como para
describir las características de desempeño, efectividad y características
relacionadas para cada componente más importante del sistema. Estos
requerimientos, conforme se aplican a cada nivel de indentación de la
jerarquía del sistema, se cubren a través de una serie de especificaciones.
Dadas las guías básicas de entrada para el diseño, el proceso entonces
se convierte en una serie de investigaciones, evaluaciones de estudios de
compromisos y la selección de las maneras en que los requerimientos del
diseño pueden cumplirse. Esto, evidentemente, involucra la aplicación
de experticia de diversas especialidades técnicas, es decir, puede haber
requerimientos eléctricos, mecánicos, estructurales, de materiales, hidráu-
licos, de confiabilidad, de mantenibilidad, de capacidad de soporte y de
calidad. Aunque las necesidades específicas variarán dependiendo de la
naturaleza y misión del sistema, cada programa relacionará el estableci-
miento de un equipo de diseño, para incluir una gran variedad de experticia
conjuntada de una manera tal que sea posible el diseño y desarrollo de un
sistema que responda a las necesidades del consumidor de una manera
efectiva en cuanto a costos. Un programa típico no sólo incluirá a los diseña-
dores de diversas disciplinas y una gran variedad de formación y experticia,
sino también los requerimientos específicos para esta área de
experiencia variarán de una fase del programa a la siguiente.
94 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

Al considerar la variedad de disciplinas de la ingeniería combinadas con


la variación en el énfasis de una fase del programa a la siguiente, es esencial
que se impongan los conceptos de la ingeniería de sistemas. Se requiere
durante el diseño y desarrollo del sistema integrar un enfoque de ciclo de
vida total, de arriba-abajo: el capítulo 2 estableció la etapa de definición del
proceso de desarrollo global; es conveniente ahora tratar algunas de las
especificaciones referentes a los requerimientos del diseño. El propósito
de este capítulo es cubrir estos requerimientos a través de las especificacio-
nes y revisar algunos detalles relativos a las disciplinas individuales del
diseño. Se incluye una introducción a una muestra selecta de las disciplinas
de diseño, se anotan algunas semejanzas y se subraya la importancia de la
integración del diseño a través de la ingeniería de sistemas.

3.1 DESARROLLO DE ESPECIFICACIONES Y CRITERIOS

La definición inicial de los requerimientos del sistema se proyecta a través


de una combinación de especificaciones formales y documentación de
planeación. Las especificaciones que básicamente cubren los requerimien-
tos técnicos del diseño del sistema y la documentación de planeación
incluyen todos los requerimientos de administración necesarios para satis-
facer los objetivos del programa. La combinación de especificaciones
y planes se considera como la base para todo el futuro programa de
ingeniería y las decisiones de administración. El alcance y profundidad de
tal documentación depende de la naturaleza, tamaño y complejidad del
sistema. Además, el grado en que el nuevo diseño es factible (donde se desea
una guía y controles extras), contra la selección de una capacidad a la
medida, ordenará la cantidad de documentación necesaria. Para los ítems
pequeños y relativamente simples, la especificación técnica así como los
requerimientos de planeación del programa pueden incluirse en un solo
documento. Por otra parte, para los sistemas en gran escala puede haber
una agrupación de documentación importante. En cualquier caso, la canti-
dad de documentación puede ajustarse a la necesidad de acuerdo con los
grados de control técnico y de administración necesarios para realizar
los objetivos del programa.
Al tratar con sistemas grandes, hay numerosos elementos que deben
cubrirse por especificación (ordenando requerimientos técnicos) y por
documentación de planeación (proporcionando la información "cómo",
"cuándo" y "dónde" perteneciente ala implementación y control del progra-
ma)) Algunos componentes del sistema pueden requerir una gran cantidad

Las clasificaciones y formatos de especificación pueden variar realmente de un caso al


siguiente. Sin embargo, unos pocos ejemplos clásicos se presentan en MIL-STD.490, Military
Standard, "Specification Practices", Departamento de Defensa, Washington, D.C.
DESARROLLO DE ESPECIFICACIONES Y CRITERIOS 95

de investigación y esfuerzo de desarrollo, mientras otros componentes se


proveen directamente de los inventarios de los proveedores actuales. Para
los nuevos ítems, unos los desarrolla el productor más importante del
sistema y otros los desarrollan proveedores localizados remotamente
en diversas partes del mundo. En la manufactura, ciertos componentes
pueden producirse en grandes cantidades usando los métodos convencio-
nales, mientras un proceso especial puede requerirse para producir otros
ítems. Puede haber una variedad de especificaciones necesarias para pro-
porcionar la guía y el control asociados con el desarrollo del sistema y sus
componentes.
Cuando se preparan y aplican las especificaciones, hay diferentes
clasificaciones como las observadas e ilustradas en la figura 3.1:
1. Especificación del sistema (tipo "A"). Incluye las características
técnicas de desempeño, operacionales y de soporte para el sistema
como una entidad; esto incluye la asignación de los requerimientos
para áreas funcionales y define las diversas interfaces del área
funcional. Asimismo, cubre la información derivada del análisis de
factibilidad, requerimientos operacionales, concepto de manteni-
miento y el análisis funcional (para mayor información véase las
secciones 2.2, 2.3, 2.4 y 2.5).
2. Especificación de desarrollo (tipo "B"). Incluye los requerimientos
técnicos para algún ítem abajo del nivel de sistema donde se
realizan la investigación, el diseño y el desarrollo. Esto puede cubrir
un ítem de equipo, ensamble, programa de computación, facilidad,
ítem crítico de soporte, etc. Cada especificación debe incluir las
características de desempeño, efectividad y soporte que se requie-
ran en la evaluación del diseño desde el nivel del sistema y niveles
inferiores.
3. Especificación del producto (tipo "C"). Incluye los requerimientos
técnicos para algún ítem del nivel más alto que actualmente está en
el inventario y puede ser suministrado. Esto puede cubrir los
componentes estándares del sistema (equipo, ensambles, unida-
des, cables), un programa específico de computación, una parte de
repuesto, una herramienta, etcétera.
4. Especificación de proceso (tipo "D"). Incluye los requerimientos téc-
nicos que cubren un servicio que se realiza sobre cualquier compo-
nente del sistema (por ejemplo, maquinado, doblado, soldado,
laminado, templado, corrugado, marcado, empacado y procesado).
S. Especificación de materiales (tipo "E"). Incluye los requerimientos
técnicos que se refieren a los materiales básicos, mezclas (por
ejemplo, colorantes, compuestos químicos) y (o) materiales
semielaborados (por ejemplo, cable eléctrico, tubería) que se usan
en la fabricación de un producto.

96 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

Requerimientos de¡ programa

----;.----
Plan do administración del programa (PMT)

T i r 1
Requerimientos técnicos Requerimientos—
de

L - _1 L 1
del programa

Especificación del sistema Plan de administración de


tipo A ingeniería de sistemas (SEMP)

Planes de ingeniería
individuales

Especificación del Especificación del producto


desarrollo tipo V tipo V

Especificación de proceso J Especificación de material


tipo D tipo E"

Otras especificaciones
y estándares

Figura 3.1. Jerarquía de especificaciones técnicas.

La preparación de las especificaciones es una actividad clave de la


ingeniería. La especificación del sistema es establecida en el inicio del
programa, durante la fase del diseño conceptual. Las especificaciones de
desarrollo y de producto están basadas en los resultados de las decisiones
"hágalo o cómprelo" y se establecen, generalmente, durante el diseño
DESARROLLO DE ESPECIFICACIONES Y CRITERIOS 97

preliminar.' Las especificaciones del proceso y material están más orienta-


das a las actividades de producción y (o) construcción y se establecen,
generalmente, durante el diseño de detalle y la fase de desarrollo. El tiempo
relativo de estas especificaciones en términos de planeación del programa
está ilustrado en la figura I.S.
Para los sistemas en gran escala, que involucran una gran combinación
de proveedores de componentes, es posible que muchas especificaciones
se generen y apliquen en diversas etapas del diseño del sistema y proceso
de desarrollo. Al revisar las experiencias pasadas asociadas a los diversos
programas, la generación-aplicación de muy diversas especificaciones en
forma independiente han dado lugar a conflictos (por ejemplo, contradic-
ciones relativas a los criterios de diseño) así como también dudas acerca de
qué especificaciones tienen precedencia.
Para ayudar a resolver un problema de precedencia, un "árbol de
documentación" (o "árbol de especificación") debe prepararse, mostrando
la jerarquía de especificaciones (o planes) de las especificaciones al nivel
sistema e inferiores. Al referirse el proceso de asignación de requerimientos
en la sección 2.6, es necesario establecer los requerimientos en el primer
nivel del sistema y luego asignar esos requerimientos abajo de los diversos
componentes del sistema. Cuando se desarrollan las especificaciones, que
ordenan los requerimientos del diseño para los diversos componentes del
sistema, es importante que una buena especificación extensa del sistema se
desarrolle inicialmente y luego complementar esta especificación con la
generación de buenas especificaciones de desarrollo, de producto, de
proceso y (o) materiales, tanto como sea posible.
En la figura 2.11 (del capítulo 2), una jerarquía preliminar de los
componentes del sistema se muestra como base para la asignación de
los requerimientos. La figura 3.2 muestra una variante de esta jerarquía,
convertida en la forma de un árbol de especificaciones. Básicamente, la
especificación del sistema es el documento técnico principal para el diseño.
Otras especificaciones complementan la especificación del sistema que
varía en grados. Más adelante, un tipo de precedencia debe establecerse
para proporcionar una guía acerca de qué especificación gobierna en el
caso de posibles conflictos.
Con la especificación del sistema (tipo "A"), que es el documento
esencial para la gula técnica, es apropiado que la responsabilidad de su
preparación e implementación se asigne como un trabajo de ingeniería de
sistemas. Se debe tener la precaución de asegurarse de que todas las

2
Los resultados de las decisiones "hágalo o cómprelo" determinan si un ítem tiene que
manufacturarse en la industria del productor o adquirirse de una fuente externa. Los factores
económicos y los requerimientos de planeación, aunados a la disponibilidad de fuentes de
suministro, son consideraciones esenciales en el proceso de la toma de decisión. Las decisio-
nes "hágalo o cómprelo" se verán más adelante, en el capítulo S.
98 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

características importantes del diseño aplicables en el nivel del sistema


estén incluidas. Los requerimientos deben integrarse adecuadamente y las
medidas de desempeño técnico (1'PM) significativas deben ser identifi-
cadas. 1 Los TPMs incluyen aquellas características cuantitativas del siste-
ma que se especifican al inicio, luego reflejadas en el diseño que sigue y, más
tarde, usadas como medidas contra las que el sistema se evalúa (por
ejemplo, rapidez, rango, exactitud, tamaño, capacidad,MTBF, MMH/OH, ikt
y costos).

Sistema XYZ

Especificación del sistema (Tipo RA")

Software Equipo Prueba especial de

Especificación del Especificación del Especificación del p


desarrollo (Tipo "B") desarrollo (Tipo "B') (Tipo NC")

Programa computacional Unidad A Unidad B

Especificación del Especificación del Especificación del


producto (Tipo "C) producto (Tipo "C") desarrollo (Tipo "B")

Ensamble 1

Especificación del proceso


(Tipo "D")

Subensamble s

Especificación del
material (Tipo QE")

Figura 3.2 Ejemplo de árbol de especificación (parcial).

En la actividad de medidas técnicas (TPMs) deben incluirse todas aquellas medidas de


efectividad (y factores de soporte) que se definen como los parámetros de nivel del sistema,
descritos en la sección 2.7 y destacados en la figura 2.13, en la especificación del sistema.
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 99

Un formato muestra para una especificación de sistema se presenta en


la figura 3.3. La especificación incluye una descripción del sistema; sus
características más importantes; algunos criterios generales para el diseño
y el ensamble; los requerimientos más importantes de los datos; considera-
ciones de logística y de capacidad de producción; los requerimientos de
prueba y evaluación así como las provisiones de aseguramiento de la cali-
dad. Se intenta proporcionar una descripción de la base funcional del
sistema. Esto constituye el marco empleado en la preparación de especifi-
caciones subordinadas por el diseñador responsable de los numerosos
componentes del sistema y sirve como la referencia técnica más importante
para toda la documentación del programa de la planeación. La especifica-
ción del sistema cubre los resultados del análisis de factibilidad, la defi-
nición de los requerimientos operacionales del sistema y el concepto de
mantenimientos, y el análisis funcional. Los factores asignados, revisados
en la sección 2.6, se derivan directamente de los TPMs del nivel del sistema,
pero se incluyen en las especificaciones de desarrollo, de producto, proceso
y (o) de material, según sea conveniente.
Como comentario final, la preparación de una buena especificación en
el sistema depende en gran medida de las habilidades de aquellos que
realizan los trabajos relativos a ellas a través del entendimiento total del
sistema, su misión, sus componentes y sus interrelaciones, las diversas
disciplinas de diseño requeridas y sus interfaces, etc. No es suficiente
preparar una serie de descripciones individuales que cubren cada discipli-
na, agruparlas y presentarlas como una especificación. Este tipo de salida da
lugar a contradicciones, confusión e ineficiencias durante todas las fases
subsecuentes del diseño y desarrollo del sistema. Sin una buena base
técnica desde el inicio, muchas de las decisiones del diseño tomadas
posteriormente ¡serán "sospechosas"! Así, la realización de una buena
especificación extensa, e integrada en gran medida, es crítica desde el inicio.

3.2 DISCIPLINAS DE INGENIERÍA DEL DISEÑO

Con base en las especificaciones del sistema, puede haber una variedad de
requerimientos de "diseñopara", tales como los que se ilustran en la figu-
ra 3.4. Estos requerimientos pueden sustentarse mutuamente por naturale-
za, o puede haber algunos conflictos inherentes en las metas. Estas metas se
observan en términos de importancia relativa (véase la figura 2.13) y la
optimización del diseño se realiza a través de estudios de compromiso con
el objetivo de establecer un planteamiento mutuamente satisfactorio.
En respuesta a la especificación y a las metas establecidas, ciertas
categorías de experticia de la ingeniería se identifican como necesarias para
el diseño y desarrollo del sistema en cuestión. Estas categorías y niveles
asociados de esfuerzo, dependen de la naturaleza y complejidad del sistema
100 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

Especificación del sistema

1.0 Alcance
2.0 Documentos aplicables
3.0 Requerimientos

3.1 Definición del sistema


3.1.1 Descripción general
3.1.2 Requerimientos operacionales (necesidad, misión, perfil de utilización, distribución, ciclo de vida)
3.1.3 Concepto de mantenimiento
3.1.4 Diagramas del sistema (análisis funcional, diagramas de bloque-producto)
3.1.5 Criterios de interfaz
3.1.6 Condiciones ambientales

3.2 Características del sistema


3.2.1 Características de desempeño
3.2.2 Características físicas
3.2.3 Requerimientos de efectividad
3.2.4 Confiabilidad
3.2.5 Capacidad de mantenimiento
3.2.6 Factores humanos
3.2.7 Capacidad de soporte
3.2.8 Capacidad de transporte-movilidad
3.2.9 Otras

3.3 Diseño y construcción


3.3.1 Requerimientos de CAD/CAM
3.3 .2 Materiales, procesos y partes
3.3.3 Montaje y etiquetado
3.3.4 Radiación electromagnética
3.3.5 Seguridad
3.3.6 Intercambiabilidad
3.3.7 Mano de obra
3.3.8 Flexibilidad del diseño

3.4 Documentación-datos

3.5 Logística
3.5.1 Requerimientos de mantenimiento
3.5.2 Soporte de suministros
3.5.3 Equipo de prueba y soporte
3.5.4 Personal y entrenamiento
3.5.5 Facilidades y equipo
3.5.6 Empacado, manejo, almacenamiento y transportación
3.5.7 Recursos computacionales
3.5.8 Creación y soporte logístico asistido por computadora (CALS)
3.5.9 Servicios al cliente

3.6 Capacidad de producción

4.0 Prueba y evaluación

5.0 Provisiones de aseguramiento de la calidad

6.0 Preparación para la distribución

Figura 3.3. Formato de especificación del sistema tipo UA (ejemplo).


DISCIPLINAS DE INGENIERÍA DEL DISEÑO 101

Diseño para desempeño

Exactitud, capacidad rendimiento computacional, potencia de salida, tiempo de proceso, rango,


tiempo de reacción, razón, sensibilidad, tamaño, rapidez, responsividad, tolerancia, peso, etc.

Diseño para la
confiabilidad k 1 )
Diseño para la
flexibilidad

,,,,,f Diseño para la

,j
Diseño para la

1\
capacidad de
mantenibilidad
transporte

Diseño para los Diseño para la


factores humanos sobrevivencia
Diseño
desarrollo
el sistema
para la
Diseño para la
capacidad de
seguridad
prueba

Diseño para la \j Diseño para la

F"
capacidad de capacidad de
soporte producción

Diseño para la 1/ \1 Diseño para la


disponibilidad 1
capacidad de
desecho

Diseño para la
factibilidad
económica (costos
M ciclo de vida)

Figura 3.4. Requerimientos del diseño del sistema.

y del tamaño del proyecto. Para sistemas/productos relativamente peque-


ños tales como un radio, como una herramienta eléctrica casera o un
automóvil, la cantidad yvariedad de los sistemas de experticia de ingeniería
pueden ser limitadas. Por otra parte, hay muchos sistemas en gran escala
102 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

que requieren la participación combinada de especialistas, que representan


una gran variedad de disciplinas de la ingeniería. Se dan dos ejemplos de
proyectos relativamente grandes:

1.Sistema de una aerolínea comercial. Los ingenieros aeronáuticos deter-


minan los requerimientos de desempeño de un avión y diseñan la estructura
total del avión. Los ingenieros eléctricos diseñan el sistema de distribución
de energía del avión y los requerimientos base de energía. Los ingenieros
electrónicos de diversos tipos son responsables del desarrollo de diversos
subsistemas como el radar, la navegación, las comunicaciones y el registro
y manejo de datos. Los ingenieros mecánicos de las estructuras mecánicas,
uniones, neumáticos e hidráulicas, los metalurgistas son necesarios en la
selección y aplicación de materiales para la estructura del avión.
Los ingenieros de confiabilidad y mantenibilidad se ocupan de la disponibi-
lidad, el tiempo medio entre fallas (MTBF), el tiempo medio de mantenimien-
to correctivo (Mat), horas-hombre de mantenimiento por hora de operación
(MMH/OH) y soporte logístico del sistema. Los ingenieros de factores huma-
nos están interesados en las funciones hombre-máquina, cabina y diseño de
cabina y el diseño de los diversos páneles de control del operador. El ingeniero
de sistemas se ocupa del desarrollo global del avión como un sistema
y asegura la integración adecuada de los numerosos subsistemas aéreos.
Los ingenieros industriales de diversos tipos están involucrados directa-
mente en la producción del avión mismo y en sus diversos componentes.
Los ingenieros de prueba se requieren para evaluar el sistema para asegurar
la concordancia con los requerimientos del consumidor. Otras especialida-
des de la ingeniería se emplean en una base tarea por tarea.
2.Sistema de Irónsito masivo terrestre. Los ingenieros civiles se requieren
para la distribución y (o) diseño de las vías férreas, túneles, puentes, cables
y facilidades. El ingeniero eléctrico está involucrado en el diseño de las pro-
visiones de control de tren automático, poder de tracción, subestaciones
y distribución de energía, recolección automática de cuotas, sistemas
digitales de datos, etc. Los ingenieros mecánicos son necesarios en el diseño
de vehículos de pasajeros y el equipo mecánico relacionado. Los arquitec-
tos pueden proporcionar soporte en la construcción de terminales de
pasajeros. Los ingenieros de confiabilidad y mantenibilidad podrían posi-
blemente involucrarse en el diseño para la disponibilidad del sistema y la
incorporación de características de capacidad de soporte. Los ingenieros
de factores humanos están involuerados en los aspectos de alumbrado,
ventilación adecuada, acceso de abordaje, señalamientos y guías en el
camino, mensajes audibles y estaciones cómodas.

Los ingenieros industriales tratarán los aspectos de producción de los


vehículos de pasajeros y los componentes de los vehículos. Los ingenie-
ros de prueba evaluarán el sistema para asegurar que todos los requerimien-
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 103

tos de desempeño, efectivi'dad y soporte del sistema se cumplan. Los in-


genieros de las áreas de planeación y comercialización serán requeridos
para mantener informado al público y para promover los aspectos técnicos
del sistema (por ejemplo, mantener a los políticos ya los ciudadanos locales
felices). Especialistas de ingeniería adicionales de diversas categorías serán
requeridos para realizar trabajos específicos relacionados con el proyecto
según se requiera.

osyc •" -&


SYSTEMS OW

ui. C,d
tNO1NEEp

MAINTENANCE

-
ENGINEER
AXA SYSItM

t?Z
W,Ít 915

: GEOTECHNIL
ENGINEERS
Ax.jIytCaI
uym Enginee

co O1tO!4NC MECHA1CL
ENG
Irçh4

-
VLUL L.INERI?
SYS lflS

EGp
NMkÍAIV.BILITY EMUEERS

c, T,oIk C1401

$TATy Cm SPtCIAL!ST
?EJ CO

ELECTRONIC D1AIOSJIC ENGINEER


OIMUTV £$tWWICI
INGINELM

a*POIIEIT

SMIU SOFTWARE
99.0
ENG UR
110,..tOfl
COMPUTER

o
TEST IQUIPME(INE(

SECI TYENGIERS
El E*9GI E

CORt

Figura 3.5 Típica clasificación ingenieril orientada al trabajo.


104 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

Aunque estos ejemplos no necesariamente pueden ser todos inclusivos,


es evidente que las muy diversas disciplinas de la ingeniería están directa-
mente involucradas. Algunas de las disciplinas más tradicionales, tales
como la ingeniería eléctrica y mecánica, están fraccionadas y dividas en
clasificaciones orientadas a trabajos específicos. Una muestra de clasifica-
ciones orientadas a trabajos, se observa en la figura 3.5 donde se ven las
solicitudes de empleo de un periódico. En términos de los requerimientos
de la ingeniería para grandes proyectos, puede haber desde 1 000 hasta 5000
personas (o más en el caso de un proyecto de desarrollo de un avión,
o equivalente) con variados antecedentes asignados a realizar funciones de
la ingeniería. Estos ingenieros, formando parte de una gran organización, no
sólo deben ser capaces de comunicarse entre sí, sino además estar al tanto
de actividades complementarias, como son la adquisición, la contabilidad,
la manufactura y el aspecto legal.
Cuando se considera la mano de obra empleada para grandes proyec-
tos, posiblemente habrá algunas fluctuaciones. Dependiendo de las funcio-
nes que se realizan, algunos ingenieros serán asignados a un proyecto dado
hasta que el desarrollo del sistema esté concluido, algunos serán asignados
durante la conclusión de la producción y otros serán contratados por un
corto tiempo para realizar trabajos específicos. Los requerimientos, en
términos de la experticia de ingeniería necesaria, también variarán entre
fase y fase ya que las áreas de énfasis cambian conforme progresa el desarro-
llo de sistemas. Durante las fases iniciales de avances de planeación y diseño
conceptual, las personas con amplios antecedentes orientados a los siste-
mas son necesarias en más cantidad que los especialistas de diseño detalla-
do, mientras que lo contrario ocurrirá durante el diseño de detalle y la fase
de desarrollo. En cualquier evento, las necesidades para la ingeniería cam-
biarán conforme el sistema evoluciona durante su ciclo de vida planeado.
Una característica adicional asociada a los proyectos grandes se refiere
a dividir las cargas de trabajo de la ingeniería de diseño entre el productor
de sistemas más importante y los proveedores de componentes del sistema.
Una gran cantidad de desarrollo, evaluación, producción y soporte de los
componentes del sistema se realiza en la localidad del proveedor en todo el
mundo (el porcentaje de actividad del proveedor en términos del costo total
de creación a menudo tiene un rango arriba del 75%, véase el capítulo 8).
En otras palabras, el productor más importante, quien es finalmente el
responsable del desarrollo, producción y soporte del sistema total como
una entidad, depende en gran manera de los resultados de las actividades
de ingeniería que se realizan en numerosos sitios dispersos.
¡El ambiente del proyecto para el diseño y desarrollo de un gran número
de sistemas actuales es altamente "dinámico"! Existen muchas personas
con especialidades y antecedentes diferentes, que laboran/no laboran en el
programa en diferentes tiempos. La necesidad de una buena comunicación
es esencial, así como tener un buen entendimiento de las numerosas
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 105

interfaces que existen. El ingeniero de diseño eléctrico necesita entender


sus relaciones de interfaz con el diseñador mecánico, el ingeniero de
estructuras, el ingeniero de confiabilidad y (o) los especialistas en factores
humanos. El ingeniero de logística necesita entender el proceso de diseño
y las responsabilidades del ingeniero de electrónica. Para crear la integra-
ción de diseño necesaria en la ingeniería de sistemas se requiere este
entendimiento y apreciación, junto con una buena comunicación.
Para proporcionar un mejor entendimiento de los requerimientos
globales del diseño (con el objetivo de promover el proceso de integración),
unas pocas disciplinas de diseño han sido seleccionadas para el propósito
de énfasis adicional. Las disciplinas de confiabilidad, mantenibilidad, facto-
res humanos, seguridad, ingeniería logística y capacidad de producción,
ingeniería de calidad e ingeniería valor/costo se verán en las secciones
posteriores. Estas áreas, por ellas mismas, ciertamente no representan el
aspecto total de la actividad de diseño. No obstante, en el pasado, estos
requerimientos particulares no han sido reflejados adecuadamente en
muchos sistemas desarrollados, tal vez debido a la carencia de entendimien-
to y apreciación de estas áreas, de acuerdo con su aplicación al diseño.
Como resultado, estas disciplinas (y otras) han sido tratadas independien-
temente a través de especificaciones y estándares y no han sido bien
integradas en el esfuerzo principal de diseño. Más adelante, cuando se
tratan los requerimientos individuales para cada una de las disciplinas
presentadas, ¡uno encontrará algunos semejantes! Mediante una revisión de
estos requerimientos, se espera que ocurra una mejor apreciación de la
necesidad de una integración total del diseño.

3.2.1 Ingeniería de confiabilidad4

La confiabilidad, en un sentido genérico, puede definirse como "la probabi-


lidad de que un sistema o un proyecto se desempeñe de manera satisfactoria
en un período dado de tiempo cuando se emplea bajo condiciones especí-
ficas de operación. El factor de probabilidad relaciona el número de veces
que uno puede esperar que ocurra un evento en un número total de ensayos.
Una probabilidad del 95%, por ejemplo, significa que (en promedio) un

'Aquí se Intenta proporcionar una panorámica introductoria de la Ingeniería de confiabilidad,


ambas en términos de definición y requerimientos del programa, ¡Y no para cubrir el tema con
profundidad! No obstante, se recomienda ampliamente que el área del tema se siga más
adelante. Tres buenas referencias son Fugua, N.B. Reliability Engineering for Eledronic Design.
Marcel Dekker, New York, 1987; Kapur, K.C. y L.R. Lamberson, Reliabi!ity in EngineeringDesigrs.
John Wiley, New York, 1977; y Lloyd, D.K. y M. Lipow, Reliability: Management, Methods, and
Mathematics, 2' ed., publicada por los autores, Defense and Space Systems Group, TRWSystems
and Energy, Redondo Beach, CA, 1977. Las referencias adicionales acerca de la confiabilidad se
incluyen en la bibliografía del apéndice D.
106 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

sistema se desempeñará adecuadamente 95 de cada 100 veces, o que 95 de


100 ítems se realizarán adecuadamente.
El aspecto de desempeño satisfactorio se refiere a la habilidad del
sistema para desempeñar su misión. Se incluye una combinación de factores
cualitativos y cuantitativos que define las funciones que el sistema debe
realizar, usualmente presentadas en el contexto de la especificación del
sistema. Estos factores se definen bajo los requerimientos operacionales
del sistema descritos en la sección 2.3.
El elemento del tiempo es el más importante ya que representa la
medida contra la cual el grado de desempeño puede relacionarse. Un sis-
tema se puede diseñar para desempeñarse bajo ciertas condiciones, pero
¿por cuánto tiempo? De interés particular es la habilidad para predecir la
probabilidad de sobrevivencia del sistema sin fallas en un periodo designa-
do de tiempo. Otras medidas relacionadas con el tiempo son tiempo
promedio entre fallas (MTBF), tiempo promedio para que ocurra una falla
(M7TF), ciclos promedios entre fallas (MCBF) y razón de fallas (X).
El cuarto elemento clave en la definición de confiabilidad, son las
condiciones específicas de operación, que se refieren al ambiente en que el
sistema operará. Los requerimientos ambientales están basados en los
escenarios anticipados de la misión (o perfiles) y las consideraciones
apropiadas para la confiabilidad deben incluir ciclos de temperatura, hume-
dad, vibración e impacto, arena y polvo, rocío salino, etc. Tales considera-
ciones no sólo deben tratar las condiciones cuando el sistema está operan-
do en un estado "dinámico", sino también las condiciones del sistema
durante la realización de actividades de mantenimiento, cuando el sistema
(o sus componentes) están siendo transportados de un lugar a otro y (o)
cuando el sistema está en modo de almacenamiento. La experiencia indica
que la transportación, el manejo, el mantenimiento y el modo de almace-
namiento son a menudo más críticos desde un punto devista de confiabilidad
que las condiciones ambientales durante los períodos de utilización real del
sistema.
Esta definición de confiabilidad es bastante básica y puede aplicarse a
casi cualquier tipo de sistema. No obstante, hay casos en que puede ser más
apropiado definir confiabilidad en términos de algún escenario específico
de una misión. En tales casos, la confiabilidad puede definirse como "la
probabilidad de que un sistema desempeñe una misión designada de
manera satisfactoria". Esta definición puede, evidentemente, implicar la
realización de actividades de mantenimiento, mientras no interfiera con
la conclusión exitosa de la misión. El aspecto de mantenimiento se verá más
ampliamente en las secciones subsiguientes de este texto.
En la aplicación de los requerimientos de confiabilidad para un sistema
específico, se necesita referir estos requerimientos en términos de alguna
medida de cantidad (o bien, una combinación de diversas figuras de mérito).
La función de confiabilidad básica, R(t), puede indicarse como:
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 107

R(t) = 1 —F(t) (3.1)

donde R(t) es la probabilidad del suceso y F(t) es la probabilidad de que el


sistema falle en un tiempo t. F(t) representa la función de la distribución de
fallas.
Cuando se trata con las distribuciones de fallas, uno asume a menudo
tasas de fallas promedio e intenta predecir el número esperado de fallas
(o promedios) en un período dado de tiempo. Para ayudarse en esta
predicción, la distribución de poisson (que es de alguna manera análoga a la
distribución binomial) puede aplicarse. Esta distribución generalmente se
expresa como:
= (? t) e'
^x, t) (3.2)
X.

donde ^k representa la tasa promedio de fallas, t es el tiempo de operación


y x es el número observado de fallas.
Esta distribución indica que si una tasa promedio de fallas (?) se conoce
por un ítem, entonces es posible calcular la probabilidad,P(x,t), de observar
0, 1, 2, 3,.. ., n fallas cuando el ítem está operando en un período designado
de tiempo, t. Recordando esto, la expresión de Poisson puede dividirse en
un número de términos tales como:
(),t)2e 1 (Xt)3e' (j)net
= + (Xt)et + + + + ( 3.3)
2! 3! n!
donde e t representa la probabilidad de que ocurran cero fallas durante un
tiempo, t, (V)e" es la probabilidad de que una (1) falla ocurrirá, etcétera.
Al tratar el objetivo de confiabilidad, se trata con la probabilidad de
éxito, ¡el primer término de la expresión de Poisson es importante! Este
término representa la distribución «exponencial", considerada a menudo
como la base para la especificación, predicción, y más tarde la medición de
la confiabilidad de un sistema.' En otras palabras,

R = e t = et/M (3.4)

donde M es el MTBF. Si un ítem tiene una tasa constante de fallas, la


confiabilidad de su vida promedio es aproximadamente 0.37, o hay un 37%
de posibilidades de que el ítem sobreviva su ciclo promedio sin fallas.

Se debe observar que nuestras suposiciones en este asunto están basadas en una tasa pro-
medio de fallas, o constante. Aunque esta suposición algunas veces simplifica el proceso de
cálculo de confiabilidad, hay casos en los que las tasas de fallas cambian constantemente.
En esta situación, puede ser más apropiado asumir una distribución Weibull (equivalente) en
lugar del exponencial negativo.
110 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

infantil en que se requiere una cierta cantidad de "depuración" o prueba real


a fin de alcanzar una condición estable. Los defectos de diseño y (o)
manufactura suceden a menudo, el mantenimiento se realiza y se toma la
acción correctiva para resolver algunos problemas importantes. Poste-
riormente, cuando se logra la estabilidad, la tasa de fallas es relativa-
mente constante hasta un punto en el tiempo donde los componentes se
desgastan, lo cual provoca una tasa de fallas creciente conforme pasa el
tiempo.
Las curvas presentadas en la figura 3.7 pueden ser influidas en gran
manera por las actividades individuales del programa. Por ejemplo, no es
inusual que un cliente pida que un sistema, o sus componentes se distribuya
antes de lo planeado. Con el objetivo de responder, el productor puede
eliminar ciertas verificaciones de calidad esenciales en el proceso de pro-
ducción a fin de ¡"tener el equipo/software a tiempo"! Esto usualmente
conduce a más defectos iniciales, el consumo de más recursos para mante-
nimiento y soporte de los previstos inicialmente y un alto grado de insatis-
facción del consumidor a largo plazo. Al referirse a la figura 3.7, el sistema
se vuelve operacional en las etapas tempranas de curva de bañera antes de
que se logre la estabilización.
Otra preocupación surge cuando existen presiones de incorporar lo
último y más grande de la tecnología (se necesite o no para cumplir con
la misión), conforme el sistema evoluciona desde el diseño, a través de la
producción, y hacia el uso operacional. Los cambios del diseño se proponen
en una base continua, los sistemas se modifican durante la producción, las
configuraciones que se desarrollan desde la producción son totalmente
diferentes (requieren recursos de soporte amplios e introducen muchos
gastos) y usualmente se introducen muchos problemas en el proceso.
En otras palabras, la ausencia de una buena administración de la configura-
ción con frecuencia crea numerosos problemas y, en relación con la figura
3.7, la inestabilidad en el inicio de la curva tipo "bañera" prevalece. En esencia,
la incorporación continua de cambios, sin el control adecuado, podría
influir significativamente en la región de tasa de fallas constantes de manera
negativa.
Al referirse a la figura 3.7 y a la ecuación (3.2) hasta la (3.4), la tasa de
fallas constituye el número de fallas ocurrido durante un intervalo especifi-
cado de tiempo, o:

número de fallas
(3.5)
horas totales de operación

más especificamente, la tasa de fallas puede expresarse en términos de


DISCIPLINAS DE INGENIERÍA DEL DISEÑO 111

fallas por hora, fallas por millón de horas, o bien, un porcentaje de fallas por
1 000 horas.'
Adicionalmente, cuando se definen las fallas en un sentido puramente
de confiabilidad, esto se refiere a las fallas "primarias" o "catastróficas",
es decir, los casos donde el sistema no está operando de acuerdo con los re-
querimientos de especificación debido a una falla del componente que
resulta de una condición de mayor falla. Un componente puede, a su vez,
causar que otros componentes fallen durante una reacción,de eventos en
cadena. Así, necesitamos considerar ambas, las fallas catastróficas prima-
rias y las fallas secundarias, algunas veces conocidas como fallas depen-
dientes.'
Con la identificación de las medidas de confiabilidad, es apropiado
mostrar ahora algunas aplicaciones. Los componentes del sistema están
relacionados funcionalmente entre sí mediante una relación de serie,
una relación paralela o una combinación de éstas. La figura 3.7 ilustra
algunos ejemplos.
Al referirse a la figura 3.8 A, una red en serie se presenta: todos los
componentes deben operar de manera satisfactoria para que el sistema esté
funcionando adecuadamente. La confiabilidad, o la probabilidad de éxito,
del sistema es el producto de las confiabilidades para los componentes
individuales y se expresa como:

R = (R)(RB)(Rc) (3.6)

Si la operación del sistema está en relación con un período específico de


tiempo, al sustituir la ecuación (3.4) en la ecuación (3.5), la confiabilidad
global de la red en series es:

R, = eA + + (3.7)

En la figura 3.8 se ilustra una red en paralelo redundante con dos


componentes. El sistema funcionará si "A" o "B", o ambas, están funcio-
nando. La expresión de confiabilidad para estas redes es:

R, = RA + RB - (RA)(RB) (3.8)

Esta definición se aplica especialmente para el equipo operativo. La tasa de fallas puede
expresarse en términos de fallas por ciclo de operación, errores ítem de línea de codificación
(por ejemplo, software), errores por página de documentación, errores por instrucción de
trabajo, etcétera.
La frecuencia global del mantenimiento no planeado considera las fallas primarias, las fallas
secundarias, defectos de manufactura, fallas inducidas por el operador, fallas inducidas por el
mantenimiento, defectos debido al manejo, etc. Mientras la mantenibilidad logística necesita
tratar el espectro entero, la confiabilidad generalmente considera sólo los dos primeros
factores.
Rr e
Ir tiempo de operación
0.8 Mr berrço promedio entre fallas

0.6

• 0.4

Ccqtliablidad o probabilidad de sobrevwenca


0.2 Cuando el tiempo de operación del sistema
es equivalente a] MTBF, la confiabilidad es
de 37%.

0 0.2 0.4 0.6 0.8 1.0 1.2 1.4 1.6 1.8 2.0

Tiempo normalizado, 1 ftI - 01

Figura 3,6. Función exponencial tradicional de confiabilidad.


DISCIPLINAS DE INGENIERÍA DEL DISEÑO 109

Inoernanlo de lasa de talas


Deaeinseb detasa de alas

periodo de desgae dei sisterna


Pero10 de mcrtasdad etana donde /eo donde se reqere
al madealmierdo dal naernento

Región de tasas de fallas constante

Ley aplicada al exponencial de tañas

\--

Curva de bañera basada en la lasa de fallas en relación al tiempo


Equipo electrónico Equipo mecánico

Figura 3,7. Relaciones de curva típica de tasa de fallas.

La figura 3.6 representa la curva de confiabilidad exponencial tradi-


cional. La consideración básica es que la tasa de fallas es constante. Cuando
se trata con tasas de fallas, es necesario revisarlas en términos tanto de
tiempo como de actividad de ciclo de vida. La figura 3.7 presenta algunas
relaciones típicas de curvas de tasas de fallas. Aunque de alguna manera
"purista" por naturaleza, las ilustraciones son incluidas para sustentar la
discusión adicional de confiabilidad.
Al referirse a la figura 3.7, la curva tipo "bañera" variará un poco
dependiendo del tipo de equipo (si es electrónico o mecánico), el grado de
madurez del sistema/equipo (nuevo diseño o producción contra el estado
del arte), etc. Usualmente, hay un período de madurez inicial o mortalidad
112 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

Entrada Componente Al Componente 8 Componente C Salida


I
(A) red en sede

Componente A
íentL
Entrada Salida Entrada -> Salida
Componente
Componente C
(8) red en paralelo - dos componentes
(C) red en paralelo - tres componentes

Componente B
14 ______1$.f CcrnPonenteEi
Componente A Salida
IComponente FI
Componente D

(D) series combinadas - red en paralelo

Figura 3.8. Relaciones de confiabilidad de los componentes.

Ahora, considere una red con tres componentes en paralelo, como se


muestra en la figura 3.8 C. Para que falle el sistema, los tres componentes
deben fallar individualmente. La confiabilidad de la red es:

(3.9)

En el caso en que los tres componentes sean idénticos, la expresión de


confiabilidad en la ecuación (3.9) puede simplificarse a:

Para un sistema con n componentes, la expresión se vuelve:

(3.10)

El incorporarla redundancia en el diseño ayuda a mejorarla confiabilidad


del sistema. Los efectos de la redundancia en el diseño presentados en un
sentido general, se ilustran en la figura 3.9. Uno también puede determinar
el grado de mejoramiento de confiabilidad a través de la redundancia
DISGIPLINAS DE INGENIERÍA DEL DISEÑO 113

Cinco unidades

SenE

Tiempo

Figura 3.9. Efectos de redundancia en la confiabilidad durante el diseño.

desarrollando algunos ejemplos matemáticos y usando las ecuaciones (3.8)


y (3.9).
La redundancia puede aplicarse en los diferentes niveles de la jerarquía
del sistema. Al nivel subsistema, puede ser apropiado estructurar capacida-
des funcionales en paralelo, donde el sistema continuará operando si una
trayectoria falla. La capacidad de control de vuelo (al incorporar alternati-
vas electrónicas, digitales y mecánicas) en un avión es un ejemplo donde
hay trayectorias alternas ¡en caso de que falle alguna! Al nivel detallado
pieza-parte, la redundancia puede incorporarse para mejorar la confiabilidad
de funciones críticas, particularmente en áreas donde la organización y el
mantenimiento no son factibles. Por ejemplo, en el diseño de muchos
tableros de circuitos electrónicos, la redundancia está integrada a menudo
a fin de mejorar la confiabilidad, mientras al mismo tiempo la realización del
mantenimiento no es práctica.
La aplicación de redundancia en el diseño es una área clave para la
evaluación. Aunque la redundancia per se mejora la confiabilidad, la incor-
poración de componentes extras en el diseño requiere espacio adicional
y los costos son muy altos. Esto induce un número de preguntas: ¿Se re-
quiere realmente la redundancia, en términos de criticabilidad en cuanto a
la operación del sistema y la realización de la misión? ¿A qué nivel debe
incorporarse la redundancia? ¿ Qué tipo de redundancia debe considerarse
("activa" o "inactiva")? ¿Deben considerarse las provisiones de manteni-
bilidad? ¿Hay algunos métodos alternativos para mejorar la confiabilidad
114 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

(por ejemplo, mejorar la selección de partes)? En esencia, hay muchos


asuntos interesantes y relacionados que requieren investigación más ade-
lante.
Una vez que se ha proporcionado una introducción a las redes en serie
y en paralelo, el siguiente paso es combinar éstas como se muestra en la
figura 3.8 B. La expresión de confiabilidad para esta red puede derivarse de
la aplicación de las ecuaciones (3.6), (3.8) y (3.9). Así,

R = (R A )[l (1 - RB)(l - Rc)(1 - RD)][RE + RF (RE)(RF)](RG) (3.11)

Al evaluar las redes en serie y en paralelo combinadas, igual que la red


ilustrada en la figura 3.8 D, el análisis debe evaluar primero los elementos
redundantes en paralelo para obtener la confiabilidad de la unidad y luego
combinar la unidad(es) con otros elementos del sistema que están en serie.
La confiabilidad global del sistema se determina mediante el cálculo del
producto de todas las confiabilidades en serie.
A través de las diversas aplicaciones de redes en serie paralelo, un
diagrama de bloque de confiabilidad del sistema puede desarrollarse para
usarlas en la distribución de la confiabilidad, modelado y análisis, prediccio-
nes, etc. El diagrama de bloque de confiabilidad se deriva directamente del
análisis funcional descrito en la sección 2.5 (véase las figuras 2.7, 2.8, 2.9),
y es expandido según se ilustra en la figura 3.10. El diagrama de bloque
describe la confiabilidad del sistema en términos de las diversas relaciones
entre los componentes.
El material presentado en esta sección obviamente no intenta ser un
texto completo acerca del tema de la confiabilidad, pero se incluye la
información suficiente para proporcionar al lector conocimientos generales
de los términos clave, definiciones y objetivos esenciales asociados con la
disciplina. Básicamente, el tema de confiabilidad está siendo presentado
como una de las muchas disciplinas que requieren consideración en el con-
texto global de la ingeniería de sistemas. Una familiarización general del tema
es necesaria, así como también un entendimiento de algunas de las acti-
vidades que se emprenden usualmente en el desempeño de un programa
de confiabilidad. Habiendo cubierto algunos términos claves y defini-
ciones, es apropiado ahora describir las actividades relacionadas del
programa. 8
Cuando se implementa un programa de confiabilidad para un sistema
típico en gran escala, los trabajos identificados en la figura 3.11 son aplica-

'Aunque los trabajos específicos de confiabilidad deben adaptarse al sistema ya las necesida-
des asociadas del programa, los trabajos listados en la figura 3.11 se asume que son típicos para
propósitos de discusión. Las bases para estos trabajos son MIL-STD-78513, Military Standard,
"Reliability Program for Systems and Equipment Development and Production", Departamento
de Defensa, Washington, D.C.
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 115

bies generalmente. Aunque hay variantes entre un programa y otro, el


desempeño de estos trabajos en términos de las fases del programa se
asume que está de acuerdo con la figura 3.12. Las fases más importantes del
programa y actividades del nivel del sistema, se derivan de la base presen-
tada en la figura 1.7 (capítulo 1).

1 Sistema más importante

Nivel 1

L
Sis—
fl— tema

LIEIJL
Nivel II

Vavi
Subsistema

vi
111 IV

Nivel III
vi

Nivel IV
Udad

a ama
a
A7altsis de ooacción de partes
y diagrama de modelo de fallas
up
n oi u
L
Nivel V

------------------
Ei ióI

Figura 3.10. Expansión progresiva del diagrama de bloque de confiabilidad. (Fuente: MIL-HDBK-338,
Military Handbook, Electronic ReliabilityDesign Handbook, Departamento de Defensa, Washington, D.C.)
116 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

Al referirse a la figura 3.11, los trabajos de confiabilidad listados pueden


colocarse por categorías bajo tres áreas básicas que incluyen 1) planeación
del programa, administración y control (trabajos 1-5), 2) diseño y análisis
(trabajos 6 a 14) y 3) prueba y evaluación (15-18). La primer categoría de los
trabajos debe integrarse estrechamente con las actividades de la ingeniería
de sistemas y se refleja en el Plan de Administración de la Ingeniería de
Sistemas (SEMP). El segundo grupo de trabajos constituye las herramientas
usadas como soportes del esfuerzo principal de la ingeniería de diseño, en
respuesta a los requerimientos de confiabilidad incluidos en la especifica-
ción del sistema y el plan de programa. El tercer grupo involucra pruebas de
confiabilidad, puede integrarse con las actividades de prueba del nivel del
sistema y cubrirse en el plan maestro de prueba y evaluación (TEMP).
Aunque estos trabajos son una respuesta a los requerimientos del programa
de confiabilidad hay muchas interfaces con funciones de diseño y con otras
disciplinas cíe soporte como mantenibilidad y soporte logístico.
A través de una breve descripción del trabajo se incluyen en la figura
3.11 algunos comentarios adicionales que cubren un selecto grupo que se
observa para propósitos de énfasis.

1. Plan de programa de confiabilidad. Aunque los requerimientos para


un programa de confiabilidad pueden especificar un esfuerzo separado in-
dependiente, es esencial que el plan de programa se haya desarrollado como
parte de o en conjunto con el Plan de Administración de Ingeniería de
Sistemas (SEMP). Las interfaces organizacionales, entradas-salidas de los
trabajos, planes, etc., deben ser directamente capaces de sustentar
las actividades de la ingeniería de sistemas. También, las actividades
de confiabilidad deben integrarse estrechamente con las funciones de
mantenibilidad y soporte logístico y deben incluirse en los planes respecti-
vos para estas áreas del programa (que también deben relacionarse direc-
tamente con el (SEMP). El SEMP está introducido en la sección 1.3 (véase la
figura 1.8) y se describirá posteriormente en el capítulo 6.
2. Reporte de fallas, análisis y sistema de acción correctiva (FRA CAS).
Aunque éste se identifica como una tarea de un programa de confiabilidad
diseñado para tratar las recomendaciones de acciones correctivas como
resultado de fallas catastróficas, el objetivo del trabajo global se relaciona
estrechamente con el lazo de retroalimentación de la ingeniería de sistemas
y el lazo de control. A menudo, conforme surgen los problemas y se inicia la
acción correctiva, los eventos que tienen lugar y los resultados no están
documentados adecuadamente. Aunque es importante responder a las
necesidades a "corto plazo" (por ejemplo, corrección de los problemas
pendientes de manera expedita), también es importante proporcionar
alguna "memoria a largo plazo" a través de un buen reporte o una buena
documentación. Este trabajo debe relacionarse directamente con el reporte
de la ingeniería de sistemas, retroalimentación y proceso de control.
Trabos del programa Aplicación y descdpdón de los traba)os

1. Plan de programa • Para desarrollar r plan de programa decontabdidad que ifiqje, integre asista enla
de conabduiad irrçlernentacsón de los 8abaos de adywrastradón aphcatdes en la sabstacaón de tos repie-
rirraentos de programas de conitabeelad. Este plan incluye tira descripción de la organización
de conlaisdidad, intertaces organizacionales, tsr listado de trabos, planes de 1~ e
Irdcadores, pollticas aplicables y procedrriertos, requerimientos proyectados de recursos.
Este plan debe concordar con el Plan de Arracidn de Ingerderta de Sistemas (SEMP).
2. Revisión y control delos Para establecer los reqierirrierdos de conlfatálkiad realizables y para realzar la revisión ne-
proveedores o s&trrontratistas cesaria del programa, evaluadón, retroaimentaddo y control de las actividades componentes
del programa deproveedodcordratisla Los planes de programa del pmveedorsondesanolades
en respuesta a los reqiertirienlos del Plan de Programa de Contiabilidad para el sistema.
3. Revuones del programa de Para condodr el programa pedódos y las revisiones del dse(ro con tos indicadores designa-
contabédad dos; por errIdo, revisión del dsao conceptua revisiones del diseño del sistema, revisiones
de rtise(io de eqipsottware y revisión del iseño critico. El objetivo es asegurar que los
requenn'lenbs de corálabilidad serán alcanzados.
4. Reporte de tallas, análisis y sistema Para establecer el sistema de repone de tatas de lazo cerrado, los proceirraentos para el
de acodo conectiva (FRAGAS) anIdes y para la detenrirsadónde las causas de talas y documentación para grabarla acción
correcttea tiádada.
S. Pánel de revisión de falla (FRB) Para esttdecertss pánel de revisión formal para revisarlas tallas significativas o criticas, las
tendencdasde tallas, el estado de acodo correctiva para asegurarlas acdones adecuadas que
se toman de manera oportuna para resolver los problemas perdentes.
6. Modelado de contabildad Para desarrollar tas modelo de contiablidad para hacer istñb&ones iránates numéricas, o
para estirnarpcetedormente para evaluar la contabilidad del sistem&corronenle. Conforme
progresa el diseño, iis diagrama de bloque deconflabéidad se desarrolla yse errplea come tira
base para realizar revisiones peñódcasdeconlabildad. El dagrama detloqaedecontiabitklad
debe evolucionar irectamente del iagraina de bloque de tiqo tiirdonaL
7. Asignación de la contabilidad Para asignar, o repartir, los reqieñrrlentos del *el dearrtra del sistema harda los niveles más
bajos del sistema (por erpto, sttsistema, unidad, ensamble). Esto se realiza con la
profundidad necesaña para propondorsar criterios especiticos como tira entrada al isefo.
8. Predcdón de La contabilidad Para estimarla cenIt ablidad deitr sistema (o sus cononentes) basado en una conhiradón
dada del iseño. Esto se realiza perráicarnente durante el diseño del sistema y el proceso de
desarrollo para deternirrar si los reqjeñrrienfos del sistema especificados es posible que
cusoplan el isel'ro propuesto dado arr ese tieropo.
9 Modelo de fallas, eledo y análisis Para idenliltcarel debilitamiento del isefo a través de tsr entoqje de análisis sistemático que
de cñticabilkiad (FMECA) que considera todas las formas poses en rpje ter coroponente puede tallar Oos modelos de
faltas), las causas posibles de cada falla, la treaainda posible de ocurrencia, la criticabildad
de falla, losefedosdecada talaenIaoperadóndel sistema (yenissdtiversoscorronentes del
sistema) y la acción correctiva pie debe iniciarse para preverir (o reiidr la probabilidad
de) el problema potendal de cpje ocurran en el kituro.
10. krásis de dmitos ocoitos (SCA) Para idenitcarlas trayectorias posibles latentesqie podrían causarla ocurrencia de t.ssciones
no deseadas, asririerdo cpie todos los componentes están funcionando correctamente desde
el principio.
11. Málisis de lolerandalpartes Para examinar los efectos de las tolerancias de los circuitos/partes elédócas, especificados
eléclr&ácas de los amitos bajo tas rango de operación )deserrpefre, temperatura, etc), en la confipuradórs de sistema.
El objetivo es valorarlas caracteristicas de cantlo de partes, incorporar la tolerancia postáe,
e identiticar las debilidades del isefro.
12. Programación de las parles Para eslatieceriir procedimiento cpie controle la selección y uso de Las parles eotárrdary no
estándar.
13. ¡lema col bcos de ccestabitdad Para idenffltcarios con-ponentes que reqiesoialenddoespedat a causa de sucorrpledad,
su relativamente corta vida y/oso uso en la aplicación de la nieva tecnología con el estado
del arte. Los llecos cruces usualmente reqieren manterirnienio/provisiones de soporte
logístico especial.
14. Electos de prueba, almacersanlerrto, Para deterrrinar los efectos de estas actividades (porejenlo, maoqo, transportación, etc.),
rnaneio, en'qaq.sr, bansportaoón en el sistema, o componentes, cantiabildad.
y mantenimientos
15. trwestigadón de tensión ambiental Para plarerary habititarier programa donde el sistema (o res cororponerles) se prueben usando
cañas tensiones azrtáentales; por ejerrçlo, ado terrosé o de temperatura, vibración e impacto,
rayos X etc. El objetivo es edrrs.áar las faltas potenciales relevantes ¡engranas en el ciclo de
vida.
16. Desarrollo de la confiabildaprueba Para planear e brrplem&star tas procedimiento'probar, analizar y corregir mediante
de madurez la debilidad del sistemalcoroponente puede identificarse las rnoificadores pueden incorpo-
rarse y la contiabilidad desarrollada puede realizarse conforme el proceso de desarmio de
sistema evolucione. Esta es tira actividad iterativa, irreoltrora pruebas de deseropefro, prueba
ambiental, prueba de apresuran-manto, etcétera.
17. Prueba de calificación dela Para planear y habilitar tsr programa donde la prueba secriervoal se realiza, usando
contabilidad tasprototipo de producción considerando los criterios estadlslicos aceptado' y«rechazado',
para rnedrla conflabildad M1'BF del sistema. Esto ocurre antes de entrara la proó,icdórl.
18. Prueba de aprobación de contablldad Para planear Incrementar sr programa cuando se realiza la prueba, con base en muestras
de la proiJcdórs iirafe el proceso de producción para asegurar que La degradación no ha oairñde como
resnitado de ese proceso.

Figura 3.11. Trabajos de) programa de la ingeniería de confiabilidad.


117
g
_2
Eca
nimi I' ou)o,
IEmCD<mi
C¿
mi _EO
-08 I > t: 2<8.2
1
0Oc ,-o2-a ni
t"9 0.LL>
I2
2-
i ni
*-1 I9-
El
o IH. 8 -1
t o - (91
ni > ni'fl0 -T,
82-ni I28—,
- - Ij*f2_ni_nini
00.5
WI

oo
. ni•- ni .nimiCnini
>

$_-
ci oo 13 ni
ni 13 o ni o Q o)
ni
:2
oa—
:Q-2-
• o-o>
(51 8a
oo <:Q-,
- ni> '<a E 0> 2
ni(
-- ni tni
o ---
nic ü-8
a
O -rni= >'
ni ni---
ni a(i) -ta o
1
- l3nini

:II_ l I- --o .22O'a


co wE
-----mi
-ni niCjCD fl g
" o)'•' _=o_ cu
-Oni.0)
o ni- -::
co 1 D W o o 13 E CT (3 u.>.
2E
10
:2E13° a
ni i'i8nf
- niE
ni -aW OZni. 5
ni 0 u niniÇt
w >, <D
ci 0 w 0,tni
cmi c 1
21 :Qmi -0
C')O- Oni -0 o
ni -ni- ni o

cE
'4 -c 4oini9
1

Cnni CDçd_i_6
Oo
Omi
-a—
c:

I ac:.ç 1'
8
0 r2 - iLC
,c
t1
0 cI 8 *-
1
1 a-
o_oo o=nio
_ - 1__
= - CC CC
mi
WoE. 8oi

01
118
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 119

3.Modelado en la confiabilidad. Este trabajo, junto con algunos otros


(por ejemplo, continuación, predicción, análisis de tensión/resistencia,
análisis de tolerancia), dependen del desarrollo de un buen programa de
bloque de confiabilidad. El diagrama de bloque debe surgir directamente
a partir de, y soportar, el análisis funcional del sistema y diagramas de flujo
funcionales asociados (véase la sección 2.5). Posteriormente, el diagrama
de bloque de confiabilidad se usa para análisis y predicciones, los resulta-
dos que se proporcionan como una entrada más importante para su
mantenibilidad, los factores humanos, logísticos ye! análisis de seguridad.
El diagrama de bloque de confiabilidad representa una liga importante a lo
largo de una serie de eventos y puede desarrollarse en conjunción con estas
otras actividades.
4.Modo de falta, efecto y análisis de criticabilidad (FMECA). El FMECA es
una herramienta que tiene muy diversas aplicaciones. No sólo es una
herramienta excelente de diseño para determinar las relaciones causa
y efecto e identificar los vínculos débiles, sino que es útil en la mantenibilidad
para el desarrollo de rutinas de diagnóstico. Eso se requiere en la realización
del análisis de soporte logístico (LSA) que se refiere a la identificación de
ambos requerimientos de mantenimiento, correctivo y preventivo. El FMECA
constituye una entrada muy importante en el programa de mantenimiento
enfocado a la confiabilidad (RCM). Se usa para complementar ambos
análisis, el de árbol de fallas y el de análisis de riesgos. El FMECA es una
actividad crítica que debe realizarse de manera oportuna (temprano duran-
te el diseño preliminar y actualizado posteriormente en una base iterativa)
y debe relacionarse directamente con estas otras actividades.
S. Prueba de calificación de la confiabilidad. Este trabajo, usualmente
realizado como parte de la prueba tipo 2, debe definirse en el contexto de la
prueba total del sistema y el esfuerzo de evaluación. Los requerimientos
específicos dependerán de la complejidad del sistema, el grado de defini-
ción del diseño, la naturaleza de la misión que se espera que realice el
sistema. Además, para ésta y cualquier otra prueba individual hay ciertas
expectativas y oportunidades de recolección de información. Por ejemplo,
el objetivo de la prueba de la calificación ambiental es determinar si el
sistema se desempeñará en un ambiente específico. Al realizar esta prueba,
debe ser posible reunir alguna información de la confiabilidad para observar
los puntos de operación del sistema, las fallas, etc. Esto, a su vez, puede
permitir una reducción en las pruebas de confiabilidad subsecuentes.
Un segundo ejemplo se refiere a la recolección de datos de la mantenibilidad
durante el desempeño de la prueba formal de confiabilidad. Conforme las
fallas ocurren durante la prueba, las acciones de mantenimiento pueden
evaluarse en términos del tiempo transcurridoy requerimientos de recurso.
Esto, a su vez, puede permitir alguna reducción en ambas pruebas, de
mantenibilidad y capacidad de evaluación yen los esfuerzos de evaluación.
En otras palabras, hay numerosas posibilidades de reducir los costos
120 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

(mientras aún se reúne la información necesaria) a través de la realización


de un enfoque de prueba integrado. Así, la prueba de confiabilidad debe
observarse en el contexto de la tentativa de prueba global del sistema, y los
requerimientos para ésta deben cubrirse en el TEMP.

En resumen, los trabajos identificados en la figura 3.11 se realizan


generalmente en respuesta a una especificación detallada o un requerimien-
to del programa. Para muchos programas, estos están concluidos en una
base relativamente independiente. Aunque las interfaces sean muchas
y haya excelentes posibilidades de integración de trabajos, se tendrá como
resultado la reducción de costos. Conforme uno avanza a través de este
texto, las oportunidades de integración se verán posteriormente. El intento
de esta sección es proporcionar una introducción a los requerimientos
asociados con la mayoría de los programas de confiabilidad.

3.2.2 Ingeniería de mantenlbllldad9

La mantenibilidades una característica inherente del diseño de sistemas que


se refiere a la facilidad, exactitud, seguridad y economía en el desempeño de
las acciones de mantenimiento. Se ocupa del empaque de componentes,
diagnóstico, estandarización de partes, accesibilidad, capacidad de inter-
cambio, montaje y etiquetación, etc. Un sistema debe diseñarse de tal
manera que pueda mantenerse sin grandes inversiones de tiempo y de
recursos (por ejemplo, personal, materiales, equipo de prueba, localidades,
datos) y con un costo mínimo, mientras aún cumple su misión designada.
La mantenibilidad es la habilidad de que un ítem se mantenga, mientras que
el mantenimiento constituye aquellas acciones tomadas para restaurar un
ítem a (o dejar un ítem en) una condición específica de operación. La mante-
nibilidad es un parámetro de diseño, mientras el mantenimiento es el
resultado del diseño.
La mantenibilidad, definida en el más amplio sentido, puede medirse en
términos de una combinación de tiempos de mantenimiento, horas cíe labor
del personal, factores de frecuencia de mantenimiento, costos de manteni-
miento y factores de soporte logístico. No hay una sola medida que involucre
todos los aspectos. Por ejemplo, un objetivo puede ser acortar el tiempo
transcurrido para realizar el mantenimiento con objeto de agregar más
personal (y posiblemente con más adiestramiento). Aunque de esta manera

'El objetivo es proporcionar una visión introductoria de la ingeniería de mantenibilidad, que


incluya las definiciones y requerimientos del programa y no cubrir el tema con profundidad.
No obstante, para más información, dos buenas referencias son Patton, J.D. ,Maintainabilityand
Mainfenance Management, Instrument Society of America, Research Triangle Park, North
Carolina, 1980; y Blanchard, B.S., Logistic Engineerirzg and Management, 4' ed., Prentice-Hall,
Englewood Cliffs, Ni., 1991. Las referencias adicionales están Incluidas en el apéndice D.
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 121

una acción puede reducir el requerimiento de tiempo, esto puede causar un


incremento en los requerimientos de personal y un incremento resultante
en el costo del ciclo de vida. Posteriormente, puede ser deseable reducir la
frecuencia de mantenimiento no planeado por medio del agregado
de requerimientos para más mantenimiento planeado. Al hacer esto, puede
haber un incremento en la frecuencia global de mantenimiento y el costo
de ciclo de vida también puede incrementarse. En esencia, estos factores
(como sea posible) deben tratarse en una base colectiva, así como también
considerarse en conjunción con las medidas de confiabilidad discutidas en
la sección 3.2.1.
Una de las medidas más comúnmente usadas para la mantenibilidad es
el aspecto del "tiempo". Al referirse a la figura 3.13, el espectro global de
tiempo puede separarse en diferentes aplicaciones. "Tiempo operable" se
refiere al tiempo transcurrido aplicable al sistema durante el uso operacional,
o durante un estado de espera o listo para ser usado. Por otra parte, "tiempo
no operable" se refiere al tiempo total transcurrido requerido, cuando el
sistema no está en uso operacional, para realizar mantenimientos correctivos
y (o) preventivos. Estas categorías de mantenimiento se definen así:'°
1. Mantenimiento correctivo. Las acciones no planeadas se inician
como resultado de fallas (o fallas percibidas), que son necesarias
para devolver un sistema a su nivel requerido de desempeño. Tales
actividades pueden incluir resolución de problemas, desacti-
vaciones, desarmado, alineación y ajuste, verificación, etcétera.
2. Mantenimiento preventivo. Las acciones planeadas necesarias para
mantener un sistema en un nivel especificado de desempeño. Este
puede incluir inspecciones periódicas, servicio, calibración, condi-
ción del monitoreo y (o) el remplazo de los ítems críticos de-
signados.
La referencia de la figura 3.13, tiempo total de mantenimiento (MDT), es
el tiempo transcurrido requerido para reparar y restaurar un sistema a su
estado enteramente operacional y (o) para mantener un sistema en esa
condición. MDT puede separarse en los siguientes componentes:

1. Tiempo activo de mantenimiento (M). La parte del tiempo en que el


sistema no está operable cuando las actividades de mantenimiento
correctivo y (o) preventivo están siendo realizadas. Este factor
a menudo se expresa como:

'°"Blanchard, B.S., Logistics Engineering and Management. 4 ed., Prentice-Hall, Englewood


Cliffs, Ni., 1991.
nio
ni
O

ni
o_ ni

122
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 123

(X) (Act) + (fvt) (Áipt)


M =
(3.12)
X + pi
donde jWes el tiempo promedio de mantenimiento activo, Mt es el
tiempo promedio de mantenimiento correctivo, Mjt es el tiempo
promedio de mantenimiento preventivo, fpt es la frecuencia de
mantenimiento preventivo y ? es la tasa de fallas (es decir, la fre-
cuencia de mantenimiento correctivo).
2. Tiempo de retraso logístico (LDT). Porción del tiempo no operable
cuando el sistema no está en uso operacional a causa de los retrasos
asociados con la capacidad de soporte, por ejemplo, espera de una
parte de repuesto, espera de la disponibilidad del equipo de prueba,
espera del uso de una facilidad especial.
3. Tiempo de retraso administrativo (ADT). Aquella porción de tiempo
no operable cuando el mantenimiento necesario se demora por
razones de naturaleza administrativa, por ejemplo, la indisponi-
bilidad de personal a causa de otras prioridades, restricciones
organizacionales, huelgas.
Cuando se observan estos elementos del tiempo no operable desde la
perspectiva de los ingenieros de diseño, es muy común tratar sólo el
segmento de mantenimiento activo (por ejemplo, M). Esto es porque es
posible relacionar directamente las características de sistema tales como
capacidad de diagnóstico, accesibilidad e intecambiabilidad con el tiempo
no operable. El productor (contratista) es responsable de y usualmente
puede controlar este elemento, mientras los factores LDT y ADT están
esencialmente influidos por el consumidor (cliente). Desde la perspectiva
de la ingeniería de sistemas uno necesita tratar con el espectro de tiempo no
operable completo. Hay un pequeño punto en que la restricción del diseño
del equipo esencial (por ejemplo, un ítem debe diseñarse de tal manera que
pueda repararse en 30 minutos), si la capacidad de soporte es tal que toma
tres meses adquirir la parte de repuesto necesaria. En esencia, el espectro
completo debe considerarse y cada uno de estos elementos de tiempo
representa una medida importante.
Al referirse a las relaciones de tiempo presentadas en la figura 3.13 así
como también los factores de la ecuación (3.12), el tiempo de mantenimien-
to activo (f) puede separarse en tiempos de mantenimiento correctivo
y mantenimiento preventivo. El tiempo promedio de mantenimiento
correctivo (Mt) se expresa,

- (X,)(Mct)
Mc,' = (3.13)
YEW

124 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

donde MTct representa el tiempo que toma progresar a través del ciclo de
mantenimiento correctivo ilustrado en la figura 3.13 (para el iésimo ítem)
y ?, es la tasa de fallas correspondiente. En el caso de un número fijo de
opciones de acciones de mantenimiento, n, entonces:
Pl
A4'ct
(3.14)
Mct =
n
---------------
1 F(t)
Normal F (1) F(t)
Exponencial Log-natural

1 Tiempo de reparación, 1, Tiempo de reparación, t, Tiempo de reparación, 1,


L --------(Abuonedeemop&areparaciónes J

0.4
WC

0.2
C

20.1

1.0
0.95

liii ; Función capacidad de


man(enirniento acumulativa

Mediana Mct Media Md Máxima Mmax


Tiampo de reparación

(B) parámetios de la capaddad de manlemndenlo en relación con la cistiibución de log-natural

Figura 3.14. Distribución de mantenibiídad.


DISCIPLINAS DE INGENIERÍA DEL DISEÑO 125

Mit, que es un promedio calculado de tiempos de reparación usando los


factores de confiabilidad, es equivalente al tiempo promedio de reparación
(MTTR), una medida que se usa comúnmente en la mantenibilidad.
La relación de dependencia al tiempo entre la probabilidad de manteni-
miento correctivo y el tiempo asignado para realizar el mantenimiento
correctivo puede esperarse que produzca una función de densidad de
probabilidad en una de las tres formas comunes, como las ilustradas en la
figura 3.14 A:

1. La distribución normal. Se aplica a las acciones de mantenimiento


relativamente simples y comunes donde los tiempos son fijos con
muy poca variación.
2. La distribución exponencial. Se aplica a las acciones de mantenimien-
to que involucran los métodos de sustitución de partes y el aisla-
miento de fallas en los sistemas grandes, que resultan en una tasa de
fallas constante.
3. La distribución logarítmica-normal. Se aplica a la mayoría de las
acciones de mantenimiento que involucran los trabajos detallados
con frecuencia desigual y duración de tiempos.

La experiencia ha indicado que en casi todos los casos la distribución de


los ítems de mantenimiento para sistemas complejos sigue la aproximación
logarítmica-normal. Al referirse a la figura 3.14 B los parámetros clave de la
mantenibilidad son el tiempo promedio para reparación (punto 1), la mediana
del tiempo para reparación (punto 2) y el tiempo máximo para reparación
(punto 3). Mientras el valor "promedio" constituye la medida que es más
comúnmente usada, los valores de la mediana y el tiempo máximo son las
medidas apropiadas aplicadas en ciertas aplicaciones.
La mediana del tiempo activo de mantenimiento correctivo (Mt) es
aquel valor que divide todos los valores de tiempo de reparación de tal
manera que el 50% está por debajo de la mediana y el 50% está por arriba
de la mediana. Para la distribución normal, la mediana es lo mismo que
la media, mientras la mediana en la distribución logarítmica-normal es la
misma que la media geométrica MTTRg, ilustrada en la figura 3.14 B.
La mediana, representada mediante el Punto 2, se calcula de esta manera:
n
log Mc4
(Xj)(log Mct)
fct = antilog = antilog
(3.15)
n

El tiempo máximo de mantenimiento correctivo activo (Mmax) puede definirse


como aquel valor del tiempo no operable bajo el cual un porcentaje
determinado de las acciones de mantenimiento puede esperar que se
126 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

concluyan. Esto está representado por el Punto 3 en la figura 3.14 B.


Los puntos seleccionados, en la distribución logarítmica-normal ante los
percentiles 90 o 95 son generalmente usados. El tiempo de mantenimiento
correctivo máximo se expresa de esta manera:

Mrnax = antilog llog MCt + ZtY 1og Mct j] (3.16)

donde logMctesla media del logaritmo de Mct,,Zes la variación estándar en


el punto donde Mm.está definida (1.65 del 95%, 1.28 del 90%, 1.04 del 85%
etc., que se refiere a las tablas de distribución normal en los textos estadís-
ticos) y a es la desviación estándar de los logaritmos de ejemplo del tiempo
promedio de reparaciones, Mct.
En el área de mantenimiento preventivo, se usan ambas medidas, tanto
la media como la mediana. El tiempo medio de mantenimiento preventivo
(t) puede determinarse por:
n
Mpt
- i=1
(fpt)(Mpt)
Mpt - ____ (3.17)
n

donde fpt, es la frecuencia de la acción del mantenimiento preventivo


individual (iésimo) yMpti es el tiempo transcurrido asociado al desempeño
del mantenimiento preventivo requerido.
El valor de la mediana del mantenimiento preventivo, así como el
requerimiento para mantenimiento correctivo especificado en la ecuación
(3.15), se determina con:

= antilog (fpt)(1og Mpt1 )


Mpt (3.18)
(fpt1 )

El mantenimiento preventivo puede realizarse mientras el sistema está


en completa operación, o los requerimientos para éste podrían resultar en
tiempo no-operable. En este caso (y en el de mantenimiento correctivo), se
consideran sólo aquellas acciones que se realizan y resultan en tiempo no
operable.
Las acciones de mantenimiento que no resultan en tiempo no operable
del sistema se contabilizan básicamente para las horas de trabajo del
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 127

personal y de las medidas de costo de mantenimiento de la mantenibi-


lidad.1 '
Aunque las diversas medidas de tiempo transcurrido son extremada-
mente importantes, también se deben considerar las horas de trabajo de
mantenimiento gastadas en el proceso. Cuando se trata de la facilidad
y economía en el desempeño de mantenimiento, un objetivo es obtener el
balance adecuado entre el tiempo transcurrido,, as horas de trabajo así
como el adiestramiento del personal a un costo mínimo de mantenimiento.
Los factores de hora de trabajo pueden expresarse en relación con las horas
hombre de mantenimiento por hora de operación del sistema (MMH/OH),
las horas hombre de mantenimiento o ciclo de operación del sistema (MMH-
ciclo), las horas hombre de mantenimiento por acción de mantenimiento
(MMH/M4), o las horas hombre de mantenimiento por mes (MMH-mes).
Algunos de estos factores pueden presentarse en relación con los valores
medios, tal como las horas hombre de mantenimiento correctivo (MMHc),
lo cual puede expresarse como:

Y(X)(MMH)
MMHc = (3.19)
44)
donde 2, es la tasa de fallas del ítem iésimo y MMH son las horas hombre
promedio de mantenimiento necesario para realizar las acciones relaciona-
das con el mantenimiento correctivo.
Cubiertos los aspectos en mantenimiento correctivo, los valores de
horas hombre promedio de mantenimiento preventivo y las horas hombre
promedio de mantenimiento total (para incluir todas las acciones de man-
tenimiento correctivo preventivo) pueden determinarse de manera similar.
Estos factores, pronosticados para cada nivel de mantenimiento identifica-
do en el concepto de mantenimiento, pueden utilizarse al determinar los
requerimientos de soporte logísticos específicos y costos asociados.
Una tercera medida de mantenibilidad (además del tiempo y de los
factores de hora de trabajo) es la frecuencia de mantenimiento. Al referirse
a la sección 3.2.1, los factores de frecuencia asociados con las fallas
primarias y secundarias se reflejan básicamente a través de las medidas de
confiabilidad MTBF y ?. Estas mediciones son, ciertamente, importantes

Aunque la capacidad de mantenimiento ya se ha definido en el contexto más amplio, hay


definiciones adicionales que se refieren a una medida específica. De acuerdo con el "tiempo",
puede definirse como "la medida de la habilidad de un ítem para mantenerse o restaurarse en
una condición donde el mantenimiento se realiza por personal que tiene un adiestramiento
específico, usando procedimientos prescritos y recursos, hacia la entrada al nivel prescrito de
mantenimiento y reparación". Esta definición está tomada de MIL-STD-721C, Military Standard,
"Definition of Terms for Reltability and Maintalnabillty". Departamento de Defensa, Washing-
ton, D.C.
128 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

para determinar la frecuencia global de mantenimiento no planeado; no


obstante, hay consideraciones adicionales tales como defectos de manufac-
tura, fallas inducidas por un operador, fallas inducidas por el mantenimien-
to y defectos debidos al manejo, que pueden ser relevantes (véase la nota
de pie de página 7, de este capítulo). También se debe considerar el aspec-
to de mantenimiento preventivo. Con esto en mente, es conveniente obser-
var el espectro total de mantenimiento y la medición de tiempo medio entre
mantenimientos (MTBM). Esto puede calcularse como:

(3.20)
1 /MTBMU + 1 /MTBM,

donde MTBMU es el intervalo promedio de mantenimiento no planeado


(o correctivo) y MTBM, es el intervalo promedio de mantenimiento planea-
do (preventivo). Los MTBMyMTBM. recíprocos son equivalentes alas tasas
de mantenimiento, o las acciones de mantenimiento por hora de la opera-
ción del sistema.
MTBMU debe ser equivalente a MTBF asumiendo que las posibilidades
de defectos inducidos por el operador, defectos inducidos por el manteni-
miento, etc., han sido diseñados fuera del sistema.
Ene! espectro total de la actividad representada por el factor MTBM, hay
algunas acciones de mantenimiento que resultan en la eliminación y remplazo
de los componentes y el requerimiento de partes de repuesto. Estas accio-
nes, en respuesta a ambos requerimientos, tanto al mantenimiento correctivo
como al preventivo, pueden medirse en términos de tiempo medio entre
remplazos (MTBR), un factor de MTBM. En esencia, el factor MTBM refleja
todas las acciones de mantenimiento, algunas de las cuales resultan en
remplazos de ítems.
Dadas las definiciones asociadas con MTBM, MTBR, iWTBF MDT, M,
yMt, Metc., es importante relacionar algunas de estas figuras de mérito
con un parámetro de orden más alto del sistema. Al referirse a la figura 2.13,
los factores de confiabilidad y mantenibilidad son, por ejemplo, entradas
claves para determinar la disponibilidad del sistema que, a su vez, son
elementos importantes para la efectividad del sistema. Aunque las medidas
específicas pueden variar significativamente de un sistema de aplicación al
siguiente, el término "disponibilidad" se usa a menudo como una medición
del sistema. La disponibilidad puede expresarse como sigue:

MTBM - arriba del tiempo


A. = (3.21)
MTBM + MDT arriba del tiempo + abajo del tiempo

donde A0 es la disponibilidad operacional. Esta definición de disponibilidad


está en relación con el ambiente operacional del consumidor, donde MTBM
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 129

refleja todos los requerimientos de mantenimiento y MDT representa todas


las consideraciones de tiempo no operable. En casos donde un productores
responsable de diseñar un sistema que cumpla un cierto requerimiento de
disponibilidad y donde el productor no tiene influencia o control sobre
la estructura de soporte del consumidor, puede ser adecuado definir la
disponibilidad como:

Aa = MTBM- (3.22
MTBM + M

donde A. es la disponibilidad alcanzada. Debe notarse que los factores LDT


yADT no se consideran aquí. Al avanzar un paso más, hay casos en los que
la disponibilidad se define como sigue:
MTBF
- (3.23)
MTBF + Mct
dondeA1 representa la disponibilidad inherente. Note que el mantenimiento
preventivo no se incluye aquí. El emplear esas figuras de mérito como una
medición de sistema, puede ser adecuado desde el punto de vista contrac-
tual donde el productor está un tanto aislado del ambiente del consumidor.
No obstante, al tratar con los requerimientos de la ingeniería de sistemas, el
factor A. es más relevante que los factores A. yA1 .
Al referirse las figuras 1.3 y 2.13, están los dos lados del balance: los
factores de confiabilidad y mantenibilidad descritos allí son colaboradores
importantes (junto con el desempeño) para medir la efectividad técnica del
sistema. Los parámetros de confiabilidad, y mantenibilidad se combinan
para determinar la disponibilidad, y la disponibilidad del sistema constituye
una entrada importante al determinar la efectividad del sistema. En el
otro extremo del balance está el costo del ciclo de vida (LCC). LCC es una
función de costos de investigación y desarrollo, costos de producción-
construcción, costos de operación y soporte, costos de retiro y desecho.
Las consecuencias de la confiabilidad y de la mantenibilidad tienen una
influencia directa sobre cada una de estas categorías de costo. Sin embargo,
el mayor impacto de estas características de diseño está en los costos
operativos y de soporte, donde la frecuencia de los factores de manteni-
miento y tiempo son importantes para determinar la capacidad global de
soporte del sistema. Si estas características no se consideran adecuadamen-
te en el diseño del sistema, el efecto de "iceberg" ilustrado en la figura 1.5
¡probablemente prevalecerá!
El material presentado hasta este punto intenta proporcionar una
familiarización con los términos y definiciones asociados con la manteni-
bilidad. La mantenibilidad es una de las muchas disciplinas que requieren
130 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

consideración en el contexto global de la ingeniería de sistemas. Un enten-


dimiento general del tema es necesario, así como también alguna familiari-
zación con las actividades que se emprenden usualmente en el desempeño
de un programa típico de mantenibilidad. Se han cubierto algunos términos
claves y definiciones; ahora, es conveniente describir las actividades rela-
cionadas con el programa.'2
Cuando se implementa un programa de mantenibilidad para un típico
sistema de gran escala, los trabajos identificados en la figura 3.15 son
generalmente aplicables. Aunque hay variantes entre una situación y la
siguiente, se asume que el desempeño de estos trabajos, en términos de las
fases del programa, están de acuerdo con la figura 3.16. Las fases más
importantes del programa y las actividades del nivel del sistema, se derivan
de la base presentada en la figura 1.7 (capítulo 1).
Al referirse a la figura 3.15, los trabajos de programa de mantenibilidad
listados pueden jerarquizarse bajo 1) planeación del programa, administra-
ción y control (trabajos 14); 2) diseño y análisis (trabajos 5-10) y3) prueba
y evaluación (trabajo 11). La primera categoría de los trabajos debe vincu-
larse estrechamente con las actividades de la ingeniería de sistemas
y reflejarse en el SEMP. El segundo grupo de trabajos constituye las herra-
mientas usadas en el soporte del proyecto principal de la ingeniería de
diseño, en respuesta a los requerimientos del programa de mantenibilidad
incluidos en la especificación del sistema y en el plan del programa. La
tercera área de actividad, demostración de la mantenibilidad, debe integrar-
se con las actividades de prueba del nivel del sistema y cubrirse durante el
TEMP. Aunque estos trabajos existen esencialmente en respuesta a los
requerimientos del programa de mantenibilidad, hay muchas interfaces con
funciones básicas de diseño y con otras disciplinas de soporte, tales como
la confiabilidad y el soporte logístico.
Aunque breves descripciones del trabajo están incluidas en la figu-
ra 3.15, algunos comentarios adicionales, ya que pertenecen a una minoría
selecta, se subrayan con el propósito de dar un mayor énfasis.

1. Plan de programa de mantenibilidad. Aunque los requerimientos para


un programa de mantenibilidad pueden especificar un esfuerzo indepen-
diente y aislado, es esencial que el programa pueda desarrollarse como
parte de, o en conjunción con ambos planes: el plan del programa de
orfiabilidad (véase el trabajo 1 de la figura 3.11) y el SEMP. Las interfaces
organizacionales, los requerimientos de trabajos de salida y entrada, los

"2 Aunque los trabajos específicos de la mantenibilidad deben vincularse a las necesidades del

sistema y el programa asociado, se asume que los trabajos listados en la figura 3.15 son típicos
para propósitos de discusión. En el sector de Defensa, las bases para estos trabajos son MIL-
STD-470A, Military Standard, "Maintainability Program for Systems and Equipment", Departa-
mento de Defensa, Washington, D.C.
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 131

planes, etc., deben integrarse con los requerimientos del programa de


confiabilidad y deben sustentar directamente las actividades de ingeniería
de sistemas. También las actividades de mantenibilidad deben integrarse
estrechamente con las funciones de factores humanos y de soporte logístico
y deben incluirse en los planes respectivos de estas áreas del programa.
El SEMP se introduce en la sección 1.3 (véase la figura 1.8) y se describe
posteriormente en el capítulo 6
2.Modelado de la mantenibilidad. La conclusión de este trabajo, junto
con la diversidad de los otros (por ejemplo, asignación, predicción, FMECA,
análisis de la mantenibilidad), depende del desarrollo de los diagramas del
nivel funcional, similares al que se presentó en la figura 3.17. Estos diagramas
deben evolucionar directamente de y soportar el análisis funcional del
sistema y de los diagramas de flujo funcionales asociados descritos en la
sección 2.5 (véase las figuras 2.7, 2.8 y 2.9). El objetivo es ilustrar los
conceptos de empacado del sistema, capacidad de diagnóstico (profundi-
dad de localización y aislamiento de la falla), ítems que se reparan en su
lugar o que se remueven para mantenimiento y otros. Los resultados de
estos trabajos constituyen una entrada importante al análisis de soporte
logístico (LSA) y deben proporcionarse de manera oportuna.
3.Modelo de fallas, efecto y análisis de criticabilidad (FMECA). El FMECA,
cuando se aplica a la mantenibilidad, se usa esencialmente como una ayuda
en el desarrollo de los planes de empacado del sistema y rutinas de diag-
nóstico y se emplea para ayudar a determinar los requerimientos críticos de
mantenimiento preventivo. Esta tarea debe relacionarse estrechamente con
las actividades de confiabilidad y utilidades logísticas ya que el FMECA es
también un trabajo necesario en estas áreas de programa.
4.Análisis de la mantenibilidad. Éste incluye la realización de los muy
diversos estudios relacionados con el diseño que se ocupan de los concep-
tos funcionales de empacado del sistema, de los niveles de diagnóstico, de
los niveles de reparación, de la prueba incorporada contra la prueba
externa, etc. Éste debe realizarse en conjunción con el FMECAy el modelado
de la mantenibilidad y también debe coordinarse con los requerimientos del
análisis de soporte logístico (LSA). El LSA también requiere el análisis de
nivel de reparaciones y el análisis de costo del ciclo de vida para satisfacer
los requerimientos referentes al diseño para la capacidad de soporte.
S. Demostración de la mantenibilidad. Este trabajo, generalmente reali-
zado como parte de la prueba tipo 2, debe definirse en el contexto de la
prueba total del sistema y en el esfuerzo de la evaluación. El objetivo de
la demostración de la mantenibilidad es la simulación en las diversas series
de trabajo de mantenimiento, registrar los tiempos asociados con el mante-
nimientoyverificar la adecuación de los recursos requeridos para soportar
las actividades demostradas de mantenimiento (por ejemplo, partes de
repuesto-reparación, equipo de soporte, software, cantidad de personal
y su adiestramiento y datos). Los resultados de estas actividades no sólo
Trabajo del programa Descripción y aplicación del frebajo

1. Plan del programa de mdbtidad Adecuado para desarrollar un plan de programa de mantenUidad que iderrttque, tirtege y asista en
la tastatación de lodos los bÉoqos de a ii*aaón aplicables para satislacer los requerimientos del
ooerna de maritembidad. Este Pan isctaye una descripción de la cegaerzadón de manterrtábdad,
Interfacesorganizacionales. rara lista deltebajos, planes tirdcadotes de babajo aplicables alas polilicas
yprocertimientos ylos requeónrientas proveclados de recursos, Este plan debe conccedai deectarnente
con el plan de aderirósltadón de isgenleria do sistemas (SEMP).

2. Revisión y ccmltcd de los proveedores Para establecer los requelinientas ¡riciales de manterrUidady para realzar la revisión del programa
o sobconitatistas necesaria, evaluación, retroalimentación y el ocnbe de las aclteidades componentes del programa del
proveeda•sobcoi*alista. Los planes de programa del proveedor se desarolan en respuesta a los
requerimientos del plan de programa de admisistración para el sistema

1 Revisiones del programa de Para oceróJctrse en el promna pedódcoy las revisiones de diseño en los irslcadctes rEseñados; pa
marrteríbtidad ejemplo, revisión del diseño conceptual, recadases de riseño del sistema, revisiones del risefro de
eqripo-sottearoyrevlsióndel rtiseñoaltico. 8 objetivo es asogzw que seakenzaráslosrequerxnienbs
de mantenUidad.

4. Recopladórr de datos, anátius Para establecer un cisterna de lazo cerrado para la receptación de datas, indIas y el irarso de las re-
y cisternas de acción correctiva comendaclones para la acción correotraa. 8 objotvo es identificar los problemas potenciales del cliseño
de manlenflrtidad.

S. Modelado de masterábitidad Para desarrollar un modelo de mantenirdidad que realoe las asignaciones iniciales numéricas y para
estimaciones frecuentes para evaluar la manterrUidad del cisterna-componente. Ccrrtanne el diseño
avanza, los clia9famas de bloque tr,rclareleo de la capacidad de mantenbnienta de lo general a lo
paladar, diagramas de flto lógicos medidores, eta., se desarrollan y empleas cur base mr las
predccicnes periódicas de realización, el análsis de soporte tagistico y el análisis de capacidad de
prueba. Estos deben evolucionar directamente desde los riagrarnas de flro de bloque flindcrrales del
manterrirniento del nivel del sistema.

6. Disbibación de muetemidtidad Para asignar, o reparte, los requerimientos del dad de sistema de amba en niveles más bajos del so.
terna (a ejemplo, sobsistenra, unidad, ensamble). Esto se realiza con la ixotanifidad necesaria para
lxopcodcear los criterios especificos como as ingreso al diseño.

7. Preolcolón de masterdótidad Para la esttinacidn de manlentritidad de un cisterna (osos componentes) basada mr rara configuración
dada del diseño. Esta se realiza periódcarnente disanteel diseño del sistema y el proceso de desarrollo
para determinar si es postele que los requerimientos del sistema especificados inicialmente se airrplan
dado el diseño propuesto en ese tiempo.

S. Modo de tabas, electo y análisis Para Identificar las debilidades potenciales del dsefro a través de iii estoque sistemático de análisis,
de ailicabikiad (FMECA): información considera fiadas las maneras posibles en que un componente puede faltar (los modelos delatas), las
de manterrildbdad causas probables de cada lilIa, la trecuencia posible de ocurrencia, la miticatidad de la tillo, los electas
de cada falla en la operación del sistema (yen Icarios componentes del sistema) y la acción correctiva
que debe Iriciarse para prevenir (o redecir su pobatitdad) el problema potencial de que ocurran fallas
en el tokio. 8 oetreo es determinar los requerimientos del isefiodelamantesbaidad como resultado
de las necesidades anticipadas de mantenimiento correctivo y(o) preventivo.

9. Asabas de rna,terátáídad Para rezar rtvetsosestsriosrelacionados con el diseño, que pertenecen a taslanes de empaque del
equipo, aislamiento de la falla y previsiones de diagnóstico, equipo de prueba incorporado contra equipo
de prueba externo, niveles de reparación, estandarización de los ocinpcerentes, consideraciones de la
capacidad de produoción, etc. Los modelos matemáticos de la capacidad de mantenimiento, el nivel de
los modelosdeandisisdereparación ylosmodelosdeandisisde costo en el ciclodevida se atIzan coleo
se requiere.

lO Los datos para mavledLstd Para identificar y preparar los datos de manteriokdad; se aplican atas diversos elementos de soporte
para el plan de nrarlecrrlaenk, logístico-parles de repuesta y reparación, equipo de prueba y de soporte, cantidad de personal en ni-
delilado y st análisis veles de adiestramiento, entrenamiento, localidades, manuales téauicos y software.
de scçxele logistico (LSA)

II. Demostración de marrievuldidad Para pianeare instrumentar rar programa donde se realiza la prueba (prueba secuendal cas ajernplode
hermano »o), usando un prototipo de la preproducción y considerando los criterios estadísticos de
aceptado y rechazado, para medias caacitertsticas de capacidad de maiteriniento del sistema.
Estas caraciseisticas pueden incluir Me( i4H/OH, Mg9 o equivalentes. Esta prueba se realiza antes de
entrar ala prodección.

Figura 3.15. Trabajos del programa de ingeniería de mantenibilidad.

132
Referencia: figura 1.7 (capítulo 1)
MI
Diseño conceptual Diseño preliminar de sistema Diseño de detalle y desarrollo

Estudio de factibilidad, requerimientos Análisis funcional del sistema y distribución de los reque- Diseño del detalle del sub sistenia/producto, desarrollo del
operacionales del sistema, concepto del rimientos, estudios de compromisos y utilización, sínte- prototipo del sistema, prueba del prototipo, documentación
mantenimiento, avance de la planeación del sis, diseño del sistema, revisión del diseño y evaluación. del diseño, revisión del diseño y evaluación.
sistema-producto.

Identificación de los requerimientos cuantita- Asignación de la mantenibilidad; análisis de la


tivos y cualitativos de la mantenibilidad del mantenibilidad; remodelado; modelo de fallas, efectos y
sistema (MTBM, Mct Mpf MMH/OH, etc.); análisis dh criticabilidad (FMECA); predicción; datos de la Análisis de la mantenibilidad; modelado; modelos de fallas,
planeación de la mantenibilidad (plan del mantenibilidad; revisión y control da los proveedores: efectos y análisis de cnticabilidad(FMECA); predicciones;
programa). revisiones del programa de la mantenibilidad. datos de la mantenibilidad (para plan de mantenimiento y
LSA); recopilación de datos, análisis y sistema de acción
correctiva; revisión y control de los proveedores; demostra-
ción de la mantenibilidad; revisiones del programa de
mantenibilidad.
- -- lazo deretroalimentación - - -- y-.........

(31 Utilización del sistema y soporte del ciclo de vida


Producción y (o) construcción
Uso operacional del sistema y mantenimiento de apoyo
Manulactura-producción-pruebade los com ponentes esen- del ciclo de vida y soporte, valoración del sistema en el Retiro y fase
ciales del sistema y de los elementos de soporte del ambiente del usuario, modificación del sistema por ac- de terminación
sistema, valoración de sistema, modificaciones por acción ción correctiva y (o) mejoramiento. del sistema
correctiva y (o) mejoramiento.

Recopilación de datos, análisis, sistemas de acción


Demostración de mantenibilidad; recopilación da datos, correctiva, revisión y control de los proveedores; moditi-
análisis y sistema de acción correctiva, revisión y control caciones del sistema por acción correctiva y (o) por
da los proveedores; modificaciones del sistema por acción mejoramiento de mantenibilidad; revisiones del progra-
correctiva y (o) mejoramiento; revisiones del programado ma de mantenibilidad.
mantenibilidad.

-- — — Lazoderetroalimentación
Figura 3.16. Trabajos del programa de mantenibilidad en el ciclo de vida.
134 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

1 Sistema 1

1 Subsistema 1 1 Subsistema 1

/\ 1 Equipo Equipo

Unidad Unidad
1 AL ( Unidad

A l (Ensamble) /\ 1
Ensamble Ensamble

r ítem o:able T
Subensamble
ítem remplazable

Ó
1 Puntos de prueba
(verificación)
AL Puntos de localización
Al
Parte
1 /\ Puntos de aislamiento 1
L ------
Figura 3.17 Diagrama funcional de nivel.

deben determinar si los requerimientos de la mantenibilidad han sido


cumplidos, sino deben ayudar a determinar si los requerimientos de la
capacidad del soporte han sido cumplidos en respuesta a los requerimien-
tos de soporte logístico. Los requerimientos de la demostración de la
mantenibilidad deben cubrirse durante el TEMP.

En resumen, los trabajos identificados en la figura 3.15 se realizan


generalmente en respuesta a alguna especificación detallada o algún reque-
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 135

rimiento del programa. Así como la confiabilidad, estas tareas se determi-


nan sobre una base relativamente independiente para muchos programas.
Más aún, las interfaces son numerosas y hay excelentes oportunidades de
integración de trabajo, que derivan en la reducción de costos del programa.
Conforme se avance en este texto, las oportunidades de integración se
volverán aún más evidentes. Esta sección intenta proporcionar una intro-
ducción a los requerimientos asociados con la mayoría de los programas de
mantenibilidad.

3.2.3 Ingeniería de factores humanos"

Muy frecuentemente, en el diseño y desarrollo de un sistema el énfasis está


puesto en el hardware y en el software: el elemento humano tiende a igno-
rarse. Para que el sistema sea completo, el ser humano y las interfaces entre
el humano y los otros elementos del sistema (por ejemplo, equipo, software,
localidades, datos, elementos de soporte logístico), deben considerarse. El
diseño óptimo del hardware o el software por sí solo, no garantiza resulta-
dos efectivos.
Los factores humanos, conocidos como "ergonómicos" o "ingeniería
humana", se refieren al diseño de un sistema o producto para uso humano.
Las consideraciones en el diseño pueden incluir los siguientes factores:

1. Factores antropométricos. La antropometría se encarga de la medición


de las dimensiones y de las características físicas del cuerpo humano; por
ejemplo, altura, estando de pie o sentado; extensión del brazo; amplitud;
longitud del glúteo a la rodilla; tamaño de la mano y peso. Cuando se
establecen los requerimientos básicos del diseño que involucran al ser
humano (para la aplicación del espacio de trabajo, el diseño de la superficie
de trabajo, el diseño del pánel de control), obviamente se deben tomar en
consideración las dimensiones físicas del cuerpo humano. Ambas dimensio-
nes "estructurales" (cuando el cuerpo está fijo y en un estado estático) y las
dimensiones "funcionales" (cuando el cuerpo está ocupado en alguna
actividad física yen un estado dinámico) deben medirse y usarse al diseñar
el desempeño de funciones operacionales y funciones de mantenimiento.
Posteriormente, el ingeniero de diseño debe considerar tanto las dimensio-
nes masculinas como las femeninas, con los rangos adecuados de variabili-
dad (generalmente, del percentil 5 al percentil 95). Por ejemplo, la altura

13
El objetivo es proporcionar una Introducción a los factores humanos (e ingeniería humana)
y no cubrir con profundidad el tema. No obstante, para más información, tres referencias
buenas son: Meister, D., Behaviora/Analysis andMeasurement Methods, John Wiley, New York,
1985; Sanders, M. S. yE. J. McCormick, Human Fa cto rs in Engineering Design, 6' ed., McGraw-Hill,
New York, 1987; y Woodson, W. E., Human Factors Design Handbook, McGraw-Hill, New York,
1981. Las referencias adicionales se incluyen en el apéndice D de este texto.
136 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

masculina puede ser de 162 cm (percentil 5), 173 cm (percentil 50y 185 cm
(percentil 95), mientras la altura de la dimensión femenina es de 150 cm,
160 cm y 170 cm, respectivamente. Aunque los valores promedios pueden
emplearse, el diseño de los espacios de trabajo, superficies, etc., deben
considerar posibles variaciones para ambos operadores, masculino y feme-
nino, y para los encargados de mantenimiento, por ejemplo, desde el
percentil 5 femenino hasta el percentil 95 masculino. Para criterios es-
pecíficos del diseño, el lector debe remitirse alas referencias adicionales."
2. Factores sensoriales humanos. Esta categoría se relaciona con las
capacidades de los sentidos humanos, particularmente la vista o la visión,
el oído, el tacto, el olfato, etc. En el diseño de las estaciones de trabajo,
superficies, consolas del operador y páneles, el ingeniero debe estar cons-
ciente de las capacidades humanas referentes a la vista que se refiere a los
campos verticales y horizontales de visualización, campos angulares de
visualización, la percepción de ciertos objetos desde diversos ángulos, la
percepción de ciertos colores yvariación de grados de la luminosidad desde
los diversos ángulos, etc. La colocación desde el pánel de exhibición
y control, como una función de uso de empleo de las diversas combinacio-
nes de colores para facilitar la realización de los trabajos manuales, requiere
conocimientos de las capacidades visuales del ser humano. Además, el
diseñador necesita entender la capacidad humana de oír, en términos de
frecuencia e intensidad (o amplitud). El diseño de las áreas de trabajo para
comunicación oral y (o) el uso de grandes exhibiciones requiere conoci-
mientos referentes a los efectos de sonido en el desempeño del trabajo.
Por ejemplo, conforme se incrementa el nivel de ruido, un ser humano se
incomoda y decrece la productividad y eficiencia. Si el nivel de ruido
se acerca a 1200 130 dB, entonces posiblemente se presentará, de alguna
forma, una sensación física o dolor. En esencia, el diseñador del sistema
necesita integrar las capacidades del humano en el producto final. '
3. Factores fisiológicos. Aunque el estudio de la fisiología está, obviamen-
te, fuera del alcance de este texto, es apropiado reconocer los efectos de
la tensión ambiental en el cuerpo humano durante el desempeño de los
trabajos humanos. La "tensión" se refiere a un tipo de actividad externa,
o ambiental, que actúa en un individuo de tal manera que causa una influen-
cia degradante. Algunas causas típicos de tensión son: 1) temperaturas altas

"Los datos antropométricos están Incluidos en NationalAeronautics and Space Administration


(NASA); vol. 1, Anthmpomeh-ic Source Book; vol. 2, A Handbook of Anthropometric Data; y vol.
3, Annotated Bibliography; NASA Reference Publicatlon 1024, 1978. También, véase Meister,
Sanders, Van Cott y Woodson, en el apéndice D.
11 Los factores de los sentidos humanos se tratan suficientemente en Van Cott, H. P. y R.G.

Klnkade (eds.), Human En.gineerirzg Guide foEquipment Design U.S. Government Printing Office,
Washington, D.C., 1972; ySanders, M. S. yE. J. McCormlck, Human Fa cto rs in EngineeringDesign,
6A ed., McGraw-Hill, New York, 1987.
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 137

y bajas, o temperaturas extremas; 2) mucha humedad; 3) altos niveles de


vibración; 4) altos niveles de ruido y(o); 5) grandes cantidades de radiación
o sustancias tóxicas en el aire. Al variar los grados, estos efectos ambienta-
les causarán una influencia negativa en el desempeño humano, es decir, la
fatiga física sobrevendrá, la respuesta motora será lenta, el proceso mental
se retrasará y la posibilidad de errores se incrementará. Estos factores,
relacionados con la tensión, normalmente derivarán en "agotamiento" del
individuo. El agotamiento puede, a su vez, tener una influencia en alguna
o algunas de las funciones biológicas del cuerpo humano (por ejemplo el
sistema circulatorio, el sistema digestivo, el sistema nervioso y el respirato-
rio). Las medidas de agotamiento pueden incluir parámetros como la
presión sanguínea, la temperatura del cuerpo, el nivel de pulsaciones y el
consumo de oxígeno. Estos factores de agotamiento, causados por tensio-
nes externas, definitivamente tendrán una influencia en el desempeño del
operador yen las funciones de mantenimiento, si el diseño deja de conside-
rar los efectos fisiológicos del humano.
4. Factores psicológicos. Esta categoría se refiere tanto a los factores que
pertenecen a la mente humana, es decir, la emoción, las características
individuales, las respuestas de actitudes, como los patrones de conducta en
lo que se refiere al desempeño del trabajo. Todas las demás condiciones
pueden ser perfectas al referirse a la conclusión de un trabajo de manera
efectiva. No obstante, si el operador (o técnico de mantenimiento) carece de
motivación propia, iniciativa, independencia, confianza en sí mismo, buenas
actitudes de comunicación, etc., la posibilidad de desempeñar el trabajo
de manera efectiva es extremadamente baja; generalmente, las actitudes de
uno, iniciativa, motivación, etc., se basan en las necesidades y expectativas
del individuo. Esto, a su vez, está en función del diseño del sistema del
ambiente organizacional en el que se desempeña el individuo. Si los trabajos
que habrán de concluirse se perciben como muy complejos, el individuo
puede frustrarse, desarrollar una actitud pobre y los errores se presentarán.
Por otra parte, silos trabajos son, extremadamente simples y rutinarios, hay
pocos retos, predominan las desmotivaciones, los errores ocurrirán como
resultado de esta actitud. Posteriormente, como un factor externo, el estilo
de administración del supervisor puede ocasionar un problema de actitud.
En algunas actividades, es conveniente considerar los posibles efectos
psicológicos del ser humano que está involucrado en el diseño y desarrollo
de un sistema. 16

La información adicional de las características, conducta del humano, factores psicológicos,


motivación, aptitud, características de liderazgo, etc., pueden encontrarse en la mayoría de los
textos que se ocupan de la dinámica organizacional, ciencia de la conducta y temas relaciona-
dos. Más específicamente, las dos referencias siguientes tratan este asunto: Griffin, R.W. y G.
Moorhead, Organiza nona! Behauior, Houghton Mifflin Co., Boston, 1986; y Blanchard, B.S.,
Engineering Oigan ization andManagement, Prentice-Hall, Englewood Cliffs, N.J., 1976. También,
véase la sección 7.5 de este texto.
138 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

Los requerimientos de los factores humanos son el resultado de la


definición de los requerimientos operacionales, el concepto de manteni-
miento y el análisis funcional que se ilustra en la figura 3.18. Al referirse alas
secciones 2.5 y 2.6, se identifican las funciones operacionales y de manteni-
miento, los análisis de compromisos se tratan en respuesta a los "cómos"
relativos a la realización de la función y aquellas funciones que involucran
la actividad humana (por ejemplo, trabajos que se realizan manualmente
o semiautomáticamente) se indican. Las funciones que están asignadas al
humano se pueden dividir más adelante en operaciones de trabajo, deberes,
trabajos, subtrabajos y elementos de trabajo. Un "elemento de trabajo"
puede jerarquizarse como la faceta más pequeña lógicamente definible de
actividad que requiere una respuesta de conducta del individuo (por
ejemplo, la identificación de una señal en una exhibición, la activación de un
interruptor en un pánel). Al progresar de manera descendente, los elemen-
tos de trabajo se combinan en secuencias lógicas para hacer los subtrabajos,
que se combinan para hacer trabajos, etc. Estas series de actividades se
definen a través de los diversos análisis (por ejemplo, análisis del trabajo del
operador, análisis de tiempo, análisis de la carga de trabajo, etc.), con la
consideración de los factores del personal en mente; por último, se identi-
fican los requerimientos específicos para el personal operador y personal
de mantenimiento, en términos de cantidad y niveles de adiestramiento.`
En la instrumentación de un programa de factores humanos para un
sistema común en gran escala, los trabajos identificados en la figura 3.19 son
generalmente aplicables. Hay 1) trabajos de planeación de programa, admi-
nistración y control (trabajos 1-4); 2) trabajos de diseño y análisis (traba-
jos 5-6) y 3) trabajos de prueba y evaluación (trabajos 14-15). Aunque las
descripciones de trabajo están incluidas en la figura, es necesario que
algunos comentarios adicionales se tomen en cuenta, para propósitos de
énfasis.

1. Plan de programa de factores humanos. Aunque los requerimientos


para un programa de factores humanos pueden especificar un esfuerzo por
separado e independiente, es esencial que el programa pueda desarrollarse
como parte de, o en conjunción con, el plan del programa de confiabilidad
(trabajo 1 de la figura 3.11), el plan de programa de mantenibilidad (trabajo
1 de la figura 3.15) y el plan de administración de ingeniería de sistemas
(SEMP). Muchas de las actividades en cada uno de los planes se sustentan
mutuamente y requieren integración en términos de requerimientos de
trabajo de entrada-salida, planes, etcétera.

11Los requerimientos de personal (cantidades y niveles de adiestramiento) que soporta las


actividades de mantenimiento del sistema también se definen a través de las actividades del
programa de mantenibilidad y de soporte logístico.
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 139

Concepto de mantenimiento de
los requerimientos operacionales

Análisis funcional de distribu- Consideraciones


ción de los requerimientos ambientales

• funciones operacionales • económicas


• funciones de mantenimiento • ecológicas
• políticas
• sociales
• tecnológicas

¿Funcio-' Factores personales


Funciones
asignadasa nes asigna-
hardware-software
das al ser • factores antropométricos
• factores de los sentidos humanos
• factores fisiológicos
• factores psicológicos
Sí • otros factores

Jerarquía de la actividad humana

• operaciones de trabajo
• obligaciones
• trabajos
• subtrabajos
• elementos de trabajo

Análisis de factores humanos

Tarea, tiempo, carga de trabajo,


error y análisis de seguridad

Requerimientos del personal


Cantidades y niveles de adiestra-
miento

Diseño y desarrollo del sistema 1

Figura 3.18 Requerimientos de los factores humanos.

2. Análisis funcional. El propósito del análisis funcional (en este contex-


to) es identificar aquellas funciones que deben desempeñarse por el ser
humano, donde hay una interfaz hombre-máquina. Esta actividad debe
surgir directamente de y debe soportar el análisis funcional de sistema y
140 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

Programa de b'*o Descripción y aplicación de

1.Plan del xowna de ladiores lueeno. Pata desanclar un dur de un sogerna de factores hatn.ncs que ióenøque, tirtoge y asista en la
irnptenatrtaddn de todos los tieñce de admioack,n aplicribles e selslacer los requerimientos de la
krgerderla de lictores humanos. Ecli plan krchjye una descripción deis organización de los lactares
inrrnano tirlerfaces organizacionales, una lisis de trabajos, planes de kto e indicadores, pellicas
qác~ socedmierdos y requerenemiós proyectados de recar. E!e plan debe concordar
directamente unir el Pan de administración de la irgerierla de atelemas (SEMP).

2.Aev,sú, y ccndicl de los proveedores Para establecer los r quenmlentcs de los factores humanos y para realizar la revisión del programa se-
o subcontratistas cesado, evaluación, retroalimentación y cantal de las adliádades componentes del programa del
oveeúm-acbunq*atisis. Ion planes del programa del proveedor ce desanclan cano reuesis a los
requerimientos de plan de programa de factores htanancc para si sielirna

Revisiones de los programas Pata indicar un programa periódicoy las revisiones del diseño de los indicadoras designados; por err-
de factores tramaras po, retido de diseño conceptuaL revisiones del diseño de mclerni,,evl*jnes de riseño de hardware-
sokware, reáldo altai del diseño. 8 oelivo es enequrar que se alcancen los requermnsentus de los
lictores humanos.

4. Arrdiios de sistema (arúbes Para depemirar las capacidades 0~ylos requerimientos de desempeñad! sistema para desa-
de la misión) sallar escenarios adecuados a la orión que idenlrlca la serie de actividades básicas. Éste debe
realzarse asno parte d cese de definición de los requedrinientosdel sistemaner! ríseñoconoep&tal.

S. Análisis trataloroal Para identilcar las tuiciones más Importantes que el cisterna debe desempeñar (basadas un los
requerimientos cperacion!es) y para desarrollar los diagoanas de hijo de teoque funcionales que
deinen losrequerimienlos de diseño del cisterna en linsinos bindanales. Este haba)o debe'seguir la
pista del ardiuis hucloni de mval del sistema.

6.Dlstlbackln de la tuición Para conducir estudios de canposinisos, evaluar y determina los recursos requeridos en la realzación
de las tardones identificadas a través de la actividad de análisis IjodarraL par ejemplo, determinando
los alrnos (costa los qués), parmailasnente en situaciones donde hay inlerlaoes humano-máquina.

7.Análisis detallado del Palo Pata evaluar las bindanes que deben ser orgadzadas pce! lunanoy pata estaldeoer tira separación
del operador jerárquica en el nivel más alto donde miste la actividad lunaria; pos qumplo, operación de trabajo,
cdilgaaones, Veños, wjbtiabajos y elementos de trabajos. Requerimientos de cantidad del personal
yrdvel de adiestramiento que se identifican a bando del análisis.

8.Dtaarnas de secuencia operacional Pata identificar las interfaces hcintxe-máq.rnra y pata desarrclat un flujo secuendal de información,
decisiones y acacnes por medio de la generaudo de diaamas de secuencia operacional (OSOs).

9.Análisis de cçceljrddad Pata seleccionar y evaluar las seosencsss de ltabo czllcas yverilica que las actividades necesarIas
puedes desempeñarse y que ellas son ocenpatules en iermmos de tiempo asignado; pos emç4o,
¿pueden los beños desempeñase en! tiempo adecuado asignado pata realzar la misión?

lO. Ariálsisde carga de trabajo Evaluar las actividades del operador lucano a través de os escenario delamisión dada (o a través de
att número de escenarios designados) para determinar el eleel de carga de trabajo; por ernplo, la
relación entre si lempo másimo asignado y el lempo real para desempeñar un trabo.

II. Arsáisis de errores Pata determinar sistemáticamente diversos caminos en que pueden cometerse errores pos los ints amos
y hacer las recanendadosmes del diseño pata remisos la çrctsaldtdad de que lates errores ocurran en el
lulseo. Este trabajo es comparaba a la contatáldad PMECA, salvo que las lilas del sistema-hardware
son el resultado de errores loan amos

12.Anális de seguridad Pata evaluar cislimáticanente, a través del análisis causa electo, los electos de las fallas del tsimna-
hat&eate en sequedad. Aunque la segundad se relate a personal y equipo, el aepedo de se9.andad
personal se entaza aqul. Este trabajo se vincula dieclomesie con la conllateldad FMECA y el anáicis
de errores de lactores lnumar

13.Modelos y(o) centiaciós, Pata desacotar tsr modelo fisiun triderrermiani otstasimtáadón del cisterna (o tirodesus componentes)
pata deatrionla las interfaces humano-mnáq.ina, relaciones espaciales, diseños de equipo, pálieles de
esintedón, soercicines de aoceatrlidad pata mantenimiento etcétera.

14.Requertirdenlos de programa Pata planear einplemenlar tsr programa lormi de entrenamiento. Este hrckrye la determinación de los
de entrenamiento requerimientos de entrenamiento del personal (cantidad del patataral ylos niveles y adectramlentes
deseadososrnosaida),calegorlasdeentenamnienlo, eqsapodees*ermamsento, datosdeem*enamienlo,
localesde entrenamiento, iómuladosresy modelos, quidasde entrenamiento especial, etc. El plan debe
incitar una descripción de la orgaruzadón de entesarniente, sima tela de trabajo., pares de trabajo
e indicadores, pdtbcas y procedimientos y requerimientos proyectados de recurso..

15.Prueba y evaluación del personal Pata planear e incrementar un programa que denuesta Ilsicarnemili las interfaces hombre-máqdn&
secuencias de trabajo, tiempos de trabajos, requerimientos de cantidad de personal y rival de
adiestramiento, la adecuación de los procedtirniesbs cperanlis, la adecuación de entrenamiento
de personal, etc. Esta actividad de prueba y evaluación se realiza antes de entrar ala producción.

Figura 3.19. Trabajos del programa de ingeniería de factores humanos.


DISCIPLINAS DE INGENIERÍA DEL DISEÑO 141

diagramas de flujo funcionales asociados descritos en la sección 2.5 (véase


las figuras 2.7, 2.8 y 2.9).
3.Análisis detallado del trabajo del operador. Esta parte del esfuerzo de
análisis global de los factores humanos constituye la expansión de las
funciones más importantes desde el análisis funcional del sistema en
las operaciones de trabajo, obligaciones, trabajos, etc. Por último, esto
conduce a la definición de los requerimientos del operador y del personal
de mantenimiento, en términos de cantidades y niveles de adiestramiento
ya! subsecuente desarrollo de los requerimientos del programa de entrena-
miento (trabajo 14 de la figura 3.19). Con la identificación de requerimientos
del personal y de entrenamiento, debe establecerse una estrecha coordina-
ción con la confiabilidad, la mantenibilidad y las actividades logísticas del
programa que tienen intereses comunes en esta área.
4. Diagramas de secuencia operacional. Como parte del esfuerzo de
análisis de diseño de los factores humanos, los diagramas de secuencia
operacional (OSD) se desarrollan para mostrar los diversos grupos de
actividades que involucran la interfaz hombre-máquina. Un ejemplo de un
OSD se presenta en la figura 3.20, donde está ilustrada una secuencia de
comunicaciones entre los operadores ylas estaciones de trabajo. Por medio
de una representación simbólica, las diversas acciones se muestran y
conllevan a la identificación de los requerimientos específicos del
diseño. De gran importancia es el requerimiento de que el OSD debe evolu-
cionar a partir del análisis funcional.
S. Prueba y evaluación del personal. El propósito de este trabajo es
demostrar las secuencias seleccionadas de actividad humana para verificar
los procedimientos de operación-mantenimiento y para asegurar la compa-
tibilidad entre el humano y los demás elementos del sistema. Las demostra-
ciones se inducen usando una combinación de simulaciones analíticas por
computadora, simulaciones físicas (de madera, de metal y (o) de cartón) y el
equipo prototipo de preproducción. Las simulaciones computarizadas
pueden incluir la inserción percentil 5 femenino al percentil 95 masculino en
un espacio de trabajo, en una posición sentado o de pie, a fin de evaluar las
secuencias de actividades y requerimientos de espacio. Una gran cantidad
de información puede adquirirse a través de las gráficas computacionales
adecuadas empleando bases de datos tridimensionales. La prueba tipo 2,
usando equipo de preproducción prototipo, puede incluir el uso de per-
sonal entrenado recomendado por los resultados del trabajo 14, en el
desempeño del operador seleccionado y (o) las secuencias de trabajo de
mantenimiento realizadas de acuerdo con los procedimientos aprobados.
La realización de tales pruebas no sólo debe permitir la evaluación de
interfaces críticas hombre-máquina, sino que debe proporcionar informa-
ción de confiabilidad perteneciente a las funciones del operador, datos de
mantenibilidad cuando se desempeñen los trabajos de mantenimiento, la
verificación y validación de información en manuales técnicos y de proce-
142 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

Operador 1 IC Estación 1 lO Estación 2 Operador 2


¿Reporte /\ N
ahora?

Presione
xirift
sw. de peda
llamada Convierta
Convierta

Llamada 2
--
;
S S'— i SaE
EaS

de llamada Pese
recibido i
Presione
Ack
Ç\
(Jl
Xmft /'S.J <Nr — \..) de sw.
permitida de llamada
Convierta ({1
SaE( SS.-' 14
Convierta
EaS <1
Presione
sw. de
rl- perrrótkla
llnaa Convierta

Haga
reporte - s Convierta
EaS

Libere
sw. de
1
Xmti
s Presione
sw. de
M Permiso
llamada llamada
de recibir permltida0-
Repita N ¿Recibe
Convierta
Convierta SaE
Q-CI)
/L
Recepción

Resuma
S
Reciba ° 0 Libere
sw. de
permiso llamada

Notas en el diagrama de secuencia operacional


Símbolos Enlaces
Decisión M Mecánicos o manuales

Operación E Eléctricos
()
Transmisión V Vsuiaies

Recepción S De sonido

II) Demora etc.

Inspección del monitor

7 Almacén

Las estaciones o sulosisternas se muestran por cokxmas; lleapo sewendal en pe avanza de manera descendente la
pána.

Fuente: MlL1-146855, Mililary Spedhcalion, «Eünan Engkieeimg Reirernenio For Mitary Systems, Epipmenl and
Fadlbes, Departamento de Defensa, Wadngton, D.C.

Figura 3.20. Diagrama de secuencia operacional (ejemplo).


DISCIPLINAS DE INGENIERÍA DEL DISEÑO 143

dimientos, la verificación de la adecuación del programa de entrenamiento


para el operador y el personal de mantenimiento, etc. Básicamente, esta
actividad debe coordinarse con los demás requerimientos de prueba y debe
cubrirse en el TEMP.

En resumen, los trabajos identificados en la figura 3.19 se realizan


generalmente como respuesta a algún requerimiento detallado del progra-
ma, a menudo concluidos en forma independiente. No obstante, las interfaces
son numerosas y es importante que estos requerimientos estén integrados
adecuadamente en el proceso global de la ingeniería de sistemas.

3.2.4 Ingeniería de seguridad 18

La seguridad es una característica del diseño de sistemas. La selección de


ciertos materiales en el diseño y construcción de un elemento de sistemas
podría producir efectos tóxicos nocivos para el humano; la colocación y el
montaje de los componentes podrían causar lesiones al operador y (o) el
encargado de mantenimiento; el uso de ciertos combustibles, fluidos
hidráulicos y (o) líquidos de limpieza podrían dar como resultado un
ambiente explosivo; la asignación de ciertos componentes electrónicos
estrechamente unidos puede causar la generación de un choque eléctrico;
el desempeño de una serie de trabajos intensos durante la operación
o mantenimiento del sistema podría causar lesiones al personal; etcétera.
La seguridad es importante, desde el punto de vista del operador y (o)
encargado de mantenimiento y desde el punto de vista del equipo, elemen-
tos del sistema, etc. Por medio de fallas del diseño, se pueden crear pro-
blemas que podrían dar como resultados lesiones a los humanos. También
los problemas creados pueden dañar los demás elementos del sistema.
En otras palabras, el interés en el diseño se ocupa de la seguridad del
personal y de la seguridad del equipo.
En relación con el diseño y proceso de desarrollo del sistema, los
requerimientos de la ingeniería de seguridad son comparables por natura-
leza a aquellos descritos para la confiabilidad, la mantenibilidad y los
[actores humanos (secciones 3.2.1, 3.2.2. y 3.2.3, respectivamente). La figura
3.21 proporciona una lista de los trabajos del programa para un sistema
común en gran escala. Hay 1) trabajos de planeación del programa, adminis-
tración y control (trabajos 1-3); 2) trabajos de diseño y análisis (traba-

'8 E1 objetivo es proporcionar una introducción a la ingeniería de seguridad. Para un análisis más
profundo, tres buenas referencias son Hammer, W., Occupational Safety Management and
Engineering 4 ed., Prentice-Hall, Englewood CIiffs, N.J., 1989; Roland, H.E. y B. Moriarty. System
Safety Engineering and Management, John Wiley, New York, 1983; y MIL-STD-88213, Military
Standard, "System Safety Program Requirements", Departamento de Defensa, Washington, D.C.
144 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

Programas de trabajo Aplicación y descripción del trabajo

Plan del programa de seguridad del sistema Para desarrollar un plan de programa de seguridad del sistema que
identifique, integre y asista en la Implementación de todas las tareas de
administración aplicables en la satisfacción de tos requerimientos de la
ingeniería de sistemas. Este plan incluye una descripción de la organización
de la ingeniería de seguridad, interfaces organizacionales, una lista de
trabajos, planes e indicadores de trabajo, políticas y procedimientos y
requerimientos proyectados de reclusos. Este plan debe concordar, direc-
tamente, con el plan de administración de ingeniería de sistemas (SEMP).

2. Revisión y control de los proveedores Para establecer los requerimientos de seguridad del sistema y para asegu
o subcontratistas rar la revisión necesaria del programa, la evaluación, la retroalimentación
y el control de actividades componentes del programa del proveedor-
subcontratista. Los planes del programa del proveedor se desarrollan, para
el sistema, en respuesta a los requerimientos del plan del programa de
seguridad del sistema.

3. Revisiones del programa de seguridad Para realizar programas periódicos y revisiones del diseño con indicadores
del sistema designados; por ejemplo, revisión del diseño conceptual, revisiones del
diseño de sistemas, revisiones del diseño de equo-softwam y revisión
crítica del diseño. El objetivo es asegurar que los requerimientos de la
ingeniería de seguridad serán alcanzados.

4. Análisis del árbol de tallas (FTA) Para realizar un análisis del árbol de tallas )FTA) para determinar los
eventos del sistema que pueden causar eventos no deseados (o riesgos)
y para establecer una clasificación de estos eventos no deseados. Los
diagramas de árbol de tallas se desarrollan desde los análisis de riesgo
tempranos, las rutas críticas son identificables y se ostentan las causas
probables (un enfoque de lo general a lo particular). Este trabajo está
estrechamente relacionado con la contiabilidad FMECA.

5. Análisis de peligros Para realizar un análisis del sistema con el objetivo de a( identificar lodos
los peligros más importantes y la probabilidad anticipada de que ocurran; b)
identificar los factores de causa" que resultará en un peligro; e) evaluarlos
impactos (electos) en el sistema en la actividad en que ocurren los peligros
y d) clasificar los peligros identificados; por ejemplo, catastrófico, crítico,
marginal, negligente. Este trabajo está estrechamente relacionado con la
contiabilidad FMECA y el análisis de seguridad de factores humanos.

6. Análisis de riesgos Para iniciar un programa de administración de riesgos para la evatuacióny


control de la probabilidad de ocurrencia y las consecuencias de eventos
riesgosos. Se incluyen el análisis de riesgos, el mejoramiento de riesgos y
las actividades de abatimiento de riesgos.

7. Recopilación de datos, análisis, Para planear la habilitación de una recopilación de datos y una capacidad
de reportes para

retroalimentación y acción correctiva identificar y evaluar las áreas potenciales de riesgo. Intervenir en la
actividad de análisis de tallas y en investigaciones de accidentes como es
adecuado. Las recomendaciones de acción correctiva se inician en las
áreas donde existe riesgo potencial.

8. Programa de entrenamiento de seguridad Para planear e instrumentar un programa de entrenamiento que cubra los
procedimientos y pasos necesarios para asegurar que el operador y el
personal de mantenimiento están entrenados adecuadamente en el des-
empeño de todas las funciones del sistema. Esto Incluye la consideración
de los requerimientos para materiales y datos de entrenamiento, equipo de
entrenamiento, ayudas de entrenamiento, locales de entrenamiento, etcé-
tera.

9. Prueba y evaluación de seguridad Para planear e implernenlar un programa que pruebe el sistema (y sus
componentes) para asegurar que puede operarse y mantenerse con toda
seguridad y que las precauciones necesarias en ese aspecto han sido
tomadas. Esta actividad de prueba de evaluación se realiza antes de entrar
a la producción.

Figura 3.21. Trabajos del programa de ingeniería de seguridad.


DISCIPLINAS DE INGENIERÍA DEL DISEÑO 145

jos 4-7) y, 3) trabajos de prueba y evaluación (trabajos 8-9). En relación con


la figura, hay tres trabajos básicos que requieren comentarios adicionales.

1.Plan de programa de seguridad del sistema. A pesar de que los reque-


rimientos para este trabajo pueden especificar un esfuerzo relativamente
independiente y por separado, es esencial que el plan de programa se
desarrolle como parte de, o en conjunción, con el plan del programa de
confiabilidad (figura 3.11, Trabajo 1), el plan de programa de mantenibilidad
(figura 3.15, trabajo 1), el plan del programa de factores humanos (figu-
ra 3.19, trabajo 1) y el plan de administración de la ingeniería de sistemas
(SEMP). Los trabajos 4 y 5 del programa de seguridad (análisis del árbol de
fallas y análisis de riesgos) están estrechamente relacionados con la
confiabilidad FMECA, el análisis de la mantenibilidad (análisis de diagnósti-
cos y de la capacidad de prueba) y el análisis de seguridad de los factores
humanos. El trabajo 7 debe concordar con la confiabilidad FRACAS y el
trabajo 4 de la mantenibilidad (recopilación de datos y análisis). El trabajo 8
(programa de entrenamiento) debe relacionarse con el trabajo 14 de facto-
res humanos. El trabajo 9 (prueba) debe coordinarse con los trabajos 16-18,
de confiabilidad, el trabajo 11, de mantenibilidad y el trabajo 15, de factores
humanos. Muchas de las actividades en cada uno de los planes se sustentan
mutuamente y requieren integración en términos de requerimientos del
trabajo de entrada-salida, planes, etcétera.
2.Análisis de árbol de fallas (FrA). Éste es un proceso analítico continuo
de arriba-abajo usando análisis deductivos y métodos boleanos, para deter-
minar los eventos del sistema que, a su vez, causarán sucesos indeseables
o riesgos. Posteriormente, estos sucesos se jerarquizan en términos de la
influencia para causar los riesgos potenciales. Los diagramas lógicos del
árbol de fallas se desarrollan comenzando con el suceso de arriba y proce-
diendo de manera descendente a través de lo niveles sucesivos de los pasos
de causa y efecto, determinando, en cada nivel, ¡cuál será el siguiente grupo
de sucesos! El análisis del árbol de fallas está estrechamente vinculado con
el análisis de confiabilidad y de mantenibilidad, particularmente cuando se
toman en cuenta los síntomas posibles y frecuencias de fallas, las rutinas de
diagnóstico y prueba, etcétera)'
3. Análisis de peligros. El objetivo de este trabajo es evaluar el diseño
y determinar los sucesos que eventualmente podrían derivar en peligros en
el nivel del sistema. Para simular fallas, actividades críticas, etc., en el nivel
componente, es posible (mediante un análisis de "causa y efecto") identifi-
car los peligros posibles, así como la secuencia anticipada de ocurrencia y la
clasificación en términos críticos. Las recomendaciones para cambio de

11 Para una revisión más profunda del análisis del árbol de fallas, véase Roland, H.E. y B.
Moriarty,System SafetyEngineering andManagement, John Wiley, New York, 1983, capítulo 26.
146 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

diseño se hacen cuando es adecuado. Este trabajo, en cuanto a metodología


y objetivos, está muy estrechamente relacionado con la confiabilidad
FMECA (que también jerarquiza los sucesos en términos críticos) y con el
análisis de seguridad de factores humanos.

En resumen, los trabajos que se muestran en la figura 3.21 se realizan


generalmente como respuesta a algún requerimiento específico del progra-
ma y a menudo concluidos en forma independiente. No obstante, las
interfaces son numerosas y es importante que estos requerimientos se
integren adecuadamente en el proceso global de la ingeniería de sistemas.

3.2.5 Ingeniería logístic&°

La logística, como una disciplina, incluye una gran variedad de actividades


realizadas durante el ciclo de vida del sistema. Tales actividades se ocupan
del flujo global de los materiales desde el proveedor-productor hasta el
consumidor, la distribución de los productos por medio del productor para
uso del consumidor, la transportación y manejo de materiales entre dos
o más puntos, adelantando el servicio del cliente y soporte de un sistema
(o producto) durante su ciclo de vida planeado, etc. Más simplemente, la
logística involucra la distribución del sistema-producto así como apoyo de
soporte.21
Al tratar las actividades logísticas asociadas con los sistemas (conforme
se comparan con los productos de consumo), se enfatiza el concepto de
soporte del sistema, y los elementos específicos del soporte del sistema
incluyen lo siguiente:22

20 E1 objetivo es proporcionar una visión de la ingeniería logística, una faceta del espectro global

de la logística. Para un análisis más profundo, tres referencias buenas son: Blanchard. B.S.,
Logistics Engineering and Management, 41. ed., Prentice-Hall, Englewood Chus, N.J.. 1991; MIL-
STD-1388-1, Military Standard", Logistic Support Analysis, "Departamento de Defensa, Was-
hington, D.C.; y Defense Systems Management College (DSMC), Integrated Logistics Support
Guide, DSMC, Fort Belvoir, Virginia 22060. Las referencias adicionales están incluidas en el
apéndice D.
21
Una definición de logística, desarrollada por la Society oí Logistics Englneers (SOLE), es "el
arte y ciencia de administración, ingeniería y actividades técnicas concernientes a los reque-
rimientos, diseño y recursos de apoyo y mantenimiento para objetivos de soporte, planes
y operaciones". "Esta definición es conceptual por naturaleza y conlleva a los aspectos amplios
de este campo.
22
Los elementos logísticos se definen en un número de recursos. Dos referencias son: Defense
Systems Managemente College (DSMC), Integrated Logistics Suppoort, DSMC, Fort Belvoir,
Virginia, 22060; y Blanchard, B.S., Logistics Engineering and Management, 4' ed., Prentice-Hall,
Englewood Cliffs, Ni., 1991.
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 147

1.Mano de obra y personal, Incluye todo el personal requerido en la


instalación, edificación, operación, manejo y apoyo de mantenimiento del
sistema durante su ciclo de vida planeado. Las consideraciones del personal
de mantenimiento cubren actividades en todos los niveles de mantenimien-
to, operación de equipo de prueba, operación de facilidades, etcétera.
2. Entrenamiento, equipo de entrenamiento y dispositivos. Incluye el
entrenamiento "inicial" del operador del sistema y personal de manteni-
miento, del entrenamiento de reposición para cubrir al personal agotado
y remplazarlo. Equipo de entrenamiento, simuladores de entrenamiento,
simulaciones, datos de entrenamiento y manuales, localidades especiales,
mecanismos y ayudas especiales y software para las operaciones de entre-
namiento del personal de soporte que también se incluyen.
3. Apoyo de soporte. Incluye todos los repuestos (unidades, ensamble,
módulos, etc.). Partes de reparación, consumibles, suministros especiales,
e inventarios relacionados necesarios para el equipo del soporte esencial
orientado a la misión, software, equipo de prueba y soporte, transportación
y manejo de equipo, equipo de entrenamiento y localidades que proporcio-
nan documentación, funciones de consecución, carga de trabajo, distribu-
ción de material y personal asociado con la creación y mantenimiento de
inventarios de partes de repuesto-reparación en todas las localidades
de soporte están también incluidas en esta categoría.
4.Equipo de prueba yde soporte. Incluye todas las herramientas, equipo
especial de monitoreo de condición, equipo de diagnóstico y verificación,
equipo de metrología y calibración, puestos de mantenimiento y equipo de
servicio y manejo requerido para operación de soporte, transportación
y acciones de mantenimiento planeadas y no planeadas asociadas con el
sistema o producto. Ambos, los ítems "peculiares" (desarrollados reciente-
mente) e ítems "estándares comunes" (existencias yya en inventario) deben
ser tratados.
S. Empaque, manejo, almacenamiento y transportación. Incluye todas las
provisiones especiales, materiales, contenedores (reusables y desechables)
y suministros necesarios para soportar el empaque, preservación, almace-
namiento, manejo y (o) transportación del equipo esencial orientado en la
misión, equipo de prueba y de soporte, repuestos y partes de reparación,
personal, datos técnicos y unidades móviles. En esencia, esta categoría
cubre la distribución inicial de los productos en la transportación del per-
sonal y materiales para propósitos de mantenimiento.
6. Localidades. Incluye todas las localidades especiales necesarias para
la operación del sistema ye! desempeño de las funciones de mantenimiento
en cada nivel. La planta física, los bienes raíces, las instalaciones portátiles,
las viviendas para el personal, tiendas de mantenimiento intermedio, labo-
ratorios de calibración y depósito especial con localidades de verificación
deben considerarse. El equipo y las utilidades esenciales (calor, energía,
requerimientos de energía, controles ambientales, comunicaciones, entre
148 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

otras) están generalmente incluidas como una parte de las facilidades.


7. Datos técnicos. Incluye instalación de sistemas, procedimientos de
verificación, instrucciones de operación y mantenimiento, procedimientos
de inspección y calibración, procedimientos de revisión, instrucciones de
modificación, información de facilidades, dibujos y especificaciones y bases
de datos asociadas que son necesarias en el desarrollo de las funciones de
operación y mantenimiento del sistema. La información de los requerimien-
tos de procesamiento (redes y equipo) están también incluidos en esta
categoría
8. Recursos computacionales. Incluye todo el software, equipo de compu-
tación, cintas-discos, bases de datos y accesorios necesarios en el desem-
peño de las funciones de mantenimiento del sistema en cada nivel. Esto
cubre los requerimientos de la condición de monitoreo y las ayudas de diag-
nóstico de mantenimiento.
Estos elementos básicos de soporte representan los segmentos signi-
ficantes del sistema. Ellos hacen posible el desempeño de las actividades de
mantenimiento del sistema, o apoyo del servicio al cliente. Hay distintas
"medidas" (por ejemplo, medidas de desempeño técnico) asociadas con
cada uno de estos segmentos y estos factores deben considerarse en el
proceso de evaluación del sistema. Por ejemplo ¿cuál es la probabilidad de
tener una parte de repuesto disponible cuando se requiere? ¿Cuál es la
probabilidad del éxito de la misión, dado un nivel designado de inventario
en una localidad específica?,Qué cantidad de factores de tipo económico
(EOQ) deben asumirse en el aprovisionamiento y suministro de las partes
de repuesto?,Cuál es el tiempo de proceso o el tiempo que gira alrededor del
proceso (TAT), para los ítems del nivel intermedio de mantenimiento? ¿Cuál
es la confiabilidad del equipo de prueba?,Cuáles son los requerimientos de
cantidad de personal y nivel de adiestramiento para el mantenimiento del
sistema?CuáIes son los tiempos de transportación entre los diversos
niveles de soporte?Cuáles son los requerimientos para el manejo de equipo
terrestre? Estos factores y los relacionados necesitan considerarse en la
actividad temprana de modelado de sistemas y de análisis (junto con MTBM,
MTBF, MDT, Mct,. MMM/OH, etcétera).23

Los elementos del soporte del sistema deben tratarse como una parte
inherente de la actividad de planeación del mantenimiento realizada en el
desarrollo del concepto de mantenimiento durante el diseño conceptual
(véase la sección 2.4). La planeación del mantenimiento entonces continúa
durante el diseño, extendiéndose con la ayuda del análisis de soporte
logístico y los diversos elementos de logística son adecuadamente integra-
dos en la configuración global del sistema.

n Aunque no se cubrió en el contexto de este texto, el estudio más avanzado de las diversas
medidas asociadas con los elementos de soporte logístico se recomienda ampliamente. Véase
la bibliografía en el apéndice O para material de referencia.
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 149

Como se indicó en la sección 1.2, la experiencia asociada con diversos


sistemas en gran escala ha indicado que una proporción importante del
costo del ciclo de vida para un sistema dado se atribuye al mantenimiento
ya los requerimientos de soporte para ese sistema. Posteriormente, al evaluar
las relaciones "causa y efecto", muchos de estos costos son el resultado
directo de la toma de decisiones durante las fases tempranas del diseño de
desarrollo del sistema-producto. Así, la logística (particularmente los as-
pectos que se ocupan del soporte de sistemas) debe tratarse en términos del
ciclo de vida del sistema completo. En otras palabras, hay actividades
logísticas de planeación realizadas en el inicio de un programa, hay activi-
dades de ingeniería logística, realizadas a través de todas las fases del
diseño y desarrollo del sistema, hay aprovisionamientos y creación
(o consecución) de funciones en la preparación por y a través de la fase de
uso del consumidor y hay actividades logísticas de evaluación y de valora-
ción realizadas durante el período cuando el sistema está siendo utilizado
en el campo.
El enfoque primario en este texto es sobre aquellos aspectos de la
logística referentes al diseño de ingeniería y son inherentes dentro del
proceso de ingeniería de sistemas. Con el objetivo de "diseño para la
capacidad de soporte", los requerimientos se establecen inicialmente, los
análisis funcionales y asignaciones se realizan, el análisis del sistema
y estudios de compromisos se realizan para asegurar un enfoque preferido
de diseño, las revisiones del diseño se realizan y la evaluación de la
capacidad del soporte se realiza como parte de la prueba global del sistema
y el esfuerzo de evaluación. La capacidad de soporte se refiere a aquellas
características del diseño que se relacionan con la facilidad y economía del
soporte del sistema (véase al apéndice B).
En relación con la ingeniería logística, los objetivos básicos inicialmente
pueden influir en el diseño y posteriormente determinar los requerimientos
de recursos de soporte logístico basados en una configuración considerada
del diseño. Al referirse a la figura 3.22, estos objetivos se realizan mejor a
través de un proceso iterativo continuo, que involucra la integración y
aplicación de diversas técnicas y funciones para asegurar que los requeri-
mientos de soportabilidad se consideran en el proceso de decisión. Este
proceso, conocido como el análisis de soporte logístico (LSA), es una parte
inherente del proceso de ingeniería de sistema, y responde a una variedad
de objetivos específicos. Básicamente:

1. Las ayudas de LSA en el establecimiento inicial de los requerimien-


tos de la capacidad de soporte durante el diseño conceptual a través
de la evaluación de los requerimientos operacionales del sistema,
aplicaciones alternativas de tecnología y conceptos de manteni-
miento alternativo y de soporte.
150 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

Niveles
de definición

Sistema

Srbststema

Sitensamie
(reparable
más bajo)

Componente
(parle)

Adaptación de AMC Pamphtet 700-22, «Logistic Support Analysis (LSA), Primer:" USAMC Material Readiness
Stporl ActMty, Lexinglon, Kentucky 40511.

Figura 3.22. Análisis de soporte logístico.

2. La asistencia del LSA en la evaluación del sistema alternativo,


o equipo, configuraciones de diseño, por ejemplo, las políticas de
reparación alternativas, esquemas de empaque, rutinas de diagnós-
tico y selección de componentes.
3. La asistencia del LSA en la evaluación de una configuración de un
diseño dado ("fija" o "considerada") para determinar los requeri-
mientos específicos de recursos logísticos, por ejemplo, personal
y entrenamiento, partes de repuesto/de reparación, equipo de prue-
ba, transportación ymanejo, datos y facilidades. Esto usualmente se
realiza a través de un análisis de trabajo de mantenimiento, un
análisis de ingeniería de mantenimiento, o el equivalente.
4. La asistencia del LSA en la medición y evaluación de un sistema
operativo en el campo, en términos de su efectividad y capacidad de
soporte en el ambiente del usuario. Los datos de campo se recolec-
tan, evalúan y utilizan para actualizar el LSA inicialmente desarrolla-
do a través del esfuerzo de evaluación del diseño inicial.

El proceso LSA incluye la evaluación de muy diversas alternativas,


siguiendo los pasos ilustrados en la figura 2.14. Inherente a esta actividad es
Progr ama de fto Descripción y aplicación del

1. Plan nado de soporte Pa desarrollar nr Plan ILS que identifique, integre y asista en la implementación de lodos los Sebajos
toglstico(ILSP) de sopaP IDgtsdoO para un programa dado. E] Plan ILS debe cubrir un número de ~anes
individuales de elementos lcglidcos queincluye:

i Plan Detado de Mant ni&rb (iisdabneerte el cosroepb de manmesnto)


b. Plan de Correlelióad y Manlmebónad (requenmientos de interfaz)
c. Plan de Análisis de Soporte Logls8co (LSAP)
d, Plan de Soporte de Suministros
e Plan de Prueba y Equipo de Soporte
1. Plan de EnEena'nienb de Persorsi
Plan de Datos Téascos
5. Plan de Empaque, Manajo, Almamamienlo y Trersspcelación
Plan de Locelelades
J. Pian de Rectases ClaaCWta1eS
5. Plan de Distribución de Soporte el Coresjmidor (opeeaames del asueno)
1. Plan de ScpcwP de Post-producción
m Plan defteleo del Sistema

El pian LS incluye una descripción de osnoeplos loglsbcos y esbaas de meadón, crgarwzaciórr


loglsica, intalacesorgeszaQooates, osa lista de osd programa, esernlcadcnesde Eabo,
pollbca aplicable y reoceelmienlos y requavimienlos proyectados de remisos. El Plan lAS debe
ocncorddrectamen con & Plan de Administración delngenrenlade Sisternas)SEMP), padoslemen-
le aquellos elementos que se ocupan de La ingenierla Ioglsbca.

2 Revisión y ccnbcl de los proveedores Para establecer los requerimientos de soporte logls&o iniciales
para reelizar la re4dón necesaria del
o subcontratistas programa, la evaisaa&r, la ,eftoalrnenlación y Las acrividades del programa de ccnbe del proveedor-
iboon5atisla. Cada peoveedcr debe desa'rcllarun Plan de Soporte Integrado (ISP) en respuesta al Plan
ILS globel para el dsrna.

3. Programa de arnelisis de soporte Para píanear e isnplemerrtar rin programa de ingeeserla loglsbca aplicable durante el duseóo y descrolo
Ioglslico (LSA) del dstenra.

4. Revióreres del programa kgls&o Para reamar un programa pci4dno ylas ,es,elcnes del diserto en los indnadoqes designados; por
ejemplo, tareidskrn del diseñoconceptual, Las revisiones del diseño del sislema, las revisiones del ctsmro
deequipo-software y la revisión mlmca del nisebo. E] objetivo es a.seqiar que los requerrnieniós
loglsticos serán elcarzados.

5 Eslcrrfto de uso operacional Pca dePrmrnc los requeranieniós operacionales del sistema y el ocercepta de maniódmienlo mino
base para demnsr los requerimientos de soporte del sistema.

6. Hcrtware y software de la misión Para definir Lacapacidad desoporle ylasotdigaaceresrelaoradasccn el diseño para el elsiemabasado
y estandarización de soporte en los remisos de soporte logiscos eostmrles y planeados. ¿Para rpjé ambiente eissterón debe
del uslerna dsertcse La capacidad de soporte?

7. Análisis comparativo Para desa-role una base de ccrnpcadón del sistema', que representa las caraclerísbcas del nuevo
sisterna,pca La ccrbdadpruyeclada de capacidad de soporte y para losm nienióscuidilativsy rpie
emplea soro base en curSasE copras ccnlguraacnes elEmnaivas se enastan.

8 Opomstudades tecnológicas Pera identtcar y establece‹ los uebqnes de las nuevas Econologlas de diseño, los avances de la
leardogla etc., para alcanzar las mejoqaspositdes de la capacidad de scporteen el nuevo sistema. Esta
acbedad rewila de la imrveolgad&n loglsftca.

9. Capacidad de scçoqE.Ldctcees de Pa establecer las caracl&lsbcas conailalvas y cuavblalrvas de la capacidad de soporte que resátan
sebo relacionados de la evaknaaiór de corrcepbs ellmrnalvos operantes, las pollboas de mantenimiento y soporte de Las
apmcacnones de Ecerologla.

Figura 3.23. Trabajos del programa de soporte logístico.

151
152 REQUERIMIENTOS DEL DISENO DE SISTEMAS

Programas de bebo Descripción y aplicación del 6ebo

lo. ldmrbcadÑr hirdoes Pa k1entílicar las triscones opmaóceres y de soporte que deben realizarse por & sislema y para
de los regerinienbe desarrollar los claTarnas de Iqo de bloque tronale, operacionales y de martenrnienb. A parúr
de los diagramas luínSonales, los debe del FMECA y del Mantenrrlenlv Enfocado a la Ccsrhalaldad
(BOA) deben generaren pa deber los roW~Mos de marbrióniento coerec6vo y preventivo en
el nivel del asrir&

11. Ahernalvas de ~te Pa idoníllicat y rlshrrgub alíernalívas factibles de scçooP pa la nueva oonfiguración del sistema
del sistema rpre se desa,rola.

12 Evaluación de alternativas Reazer eslados de ornspecerrisco y definir tira configuración preferida de soporte corno resultado.
yendiss de compromisos La realización del nivel de end&s de regaración, la ev&uaddrr de enfoques aheenubsos de diagrós-
bco, la evaluación de demos piases de empaque de equipo y peomsicnes de morrióje, etc., se
incluyen.

13. Análisis de trabajos ldentíficar y analizar los abos requeridos de operación y manlesmienlo (que se derivan de las
fszrciorren( a fardedelvir los requ ienloseopeclkasderecursosde soporteloglstioo; por ejemplo,
partes de reçueslv y reparación, equipo de prueba y de soperle, cantidad de personal y nrveles de
adiestramiento, localidades, datos, software, eb4taa.

14. Artisis temprano de Pa conseguir el inpacb de ,,odccri nuevos ssteenas-compcerenfas en centenas cocientes y en
representación el wrbierrle. Para identificar los recursos de soporte loglslco requeridos dararrlv la Ñnceode de la
prodcciórr en gran escala de las operaciones del crumsurridor,

15. Arrálces de soporte de Analizar los requertnienbsde scfxvte del ciclo devida para el nuevo sistema (entes de la producción
la ost-prodjcdón desconlbmuada( para asegurar que los recursos adecuados de soporte logístico, estarán disponibles
doraste lo que renta de la sida del sistema; por ejemplo, ¿puede soportarse adecuadamen lv siste-
ma después de que la capacidad de producción se desoonlbrúam

16. Prueba y evaluación de Verificar que los requerimientos especificados de capacidad de soporte para lv sistema has sido crin-
la capacidad de soporte pdldosyestablec procedimiento aflavésdlv cual lasrecomendacicnes para acción crurectivay (o)
mejoramiento puedan procesarse.

17. Aprovisionamiento y Planear e implementar ram programa para el afocoidormarnienlo, consecución y creación de parles de
cneadiór de elemetriós reprieslosyde reparación, ánmseopedalende equipo deprueba, transportación ymarogodeequipo,
loglsticos tadldades, personal entrenado adeoradasmeerle, dalos técnicos y software. Eskr puede incluir la
producción de diversos elementos de soporte, la consecución de llmms en el rival de stock del equipo,
mm desarrollo de tudricadormes ieadcas y (o( la construcción de una mueva localidad.

la. Servidos del consumidor o Establecer tira capacidad de epcyodomdeel productor-conflabsta proporcione seeviciosdeingeeserla
urgenierla de servidos de campo en lv lugar del ccemsrsnida ram lv soporle de operación del entena y actividades de mantenimiento.

19 Recopilación de dalos de campo, Planear eimple.nenlar una reccpladón de datos la capacidad de reportes a fin de çzcryadcrrar tina
análisis, retroalimentación y acción valoración de las operaciones del sistema y de soporte en el campo.
correctiva del sistema Las recomendaciones para acción correctiva y(o) moras se radas corno es adecuado.

20. Motcadoçres al sistema Establecer tsr procedvnieerb a través del cual las modificaciones del cisterna puedas implementarse
para oorneier ira deédmmda conocida. Esto irrctriye la planeación inicial de las momificaciones, lv
desarrollo y pruebas del conjunto de momificaciones, instalación de morlicacrones en este campo
y verificación de la operación del cisterna deopués de que los cambios has sido incorporados.

Figura 3.23. (Continuación).

la realización del análisis de costos del ciclo de vida (LCC), el nivel de


análisis de reparación (LORA), análisis de mantenimiento enfocado a la
confiabilidad (RCM), modo de falla, efecto análisis de criticalidad (FMECA),
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 153

Necesidad

Avance de la
planeación del i-i
Avance del
desarrollo y
Diseño del
Produccióny(o) -.l> Utilización del 1+fetrod]
construcción sistemaY náernaj
sistema y detalle y opone de
diseño diseño i-i desarrollo. Distribución e
conceptual prellminardel instalación. apoyo.
-sistema.

- JiRetroalimentación y acción correctiva.


Análisis de • Análisis funcional y • Actividades de • Aprovisionamiento • Servicios al cliente.
factibilidad. distribución de los soporte de diseño creación de los
requerimientos de la elementos y soporte • Soporte de
• Definición de los capacidad de • Aprovisionamiento y logístico, mantenimiento de
requerimientos soporte. adquisición de los apoyo (a todos los
operacionales y elementos de • Prueba y evaluación niveles).
concepto de • Actividades del soporte logístico, del sistema y
mantenimiento. soporte de diseño, capacidad del • Reprovisionamiento
Adquisición de soporte, y reconsecución de
• Análisis de soporte • Análisis de soporte elementos de los elementos de
logístico logísticos soporte logístico • Flujo de material, soporte logístico.
(requerimientos del (evaluación de distribución tísica,
nivel del sistema), alternativas). • Prueba y evaluación transportación, • Recopilación de
W sistema almacenamiento y datos, análisis y
• Definición de los • Plan formal (evaluación de la servicios al cliente, acción correctiva,
criterios del diseño integrado y de capacidad de
de la capacidad de soporte logístico, soporte del sistema • Recopilación de • Modificaciones (que
soporte. y elementos de datos, análisis, y se requieren).
Revisión(es) del logística). acción correctiva,
• Pian preliminar diseño del sistema.
integrado de soporte • Revisión(es) del
logístico, diseño de equ'o-
sdosistema.
• Revisión del diseño
conceptual.

Figura 3.24. Actividades de soporte logístico en el ciclo de vida del sistema.

capacidad de prueba y análisis de diagnóstico, etc. Las técnicas analíticas


tales como la simulación, programación lineal, programación dinámica,
análisis de colas y teoría de control pueden emplearse para resolver una
gran variedad de problemas.
En la implementación de un programa de logística para un sistema típico
a gran escala, los trabajos identificados en la figura 3.23 son generalmente
aplicables. La figura 3.24 proporciona una visión "general" de estos trabajos
en cuanto a un marco de tiempo del programa. Hay: 1) planeación del
programa, administración ytrabajos de control (trabajos 1-4), 2) trabajos de
ingeniería logística (trabajos 5-13, 16) y 3) trabajos de soporte del sistema-
producto (trabajos 14-15, 17-20). Aunque se incluyen breves discusiones
acerca de los trabajos en la figura 3.23, algunos comentarios adicionales son
adecuados.
154 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

1.Plan integrado de soporte logístico (ILSP). El ILSP, usualmente iniciado


durante el diseño conceptual y actualizado en el diseño preliminar, cubre
todas las actividades del programa que se ocupan del soporte logístico y del
sistema, es decir, las actividades de planeación, las actividades del diseño,
actividades de consecución y creación y las actividades de apoyo de soporte.
El ILSF' puede incluir un plan LSA (LSAP), un plan integrado de soportes (ISP)
ylos similares, dependiendo de la naturaleza de un programa dado. Así, su
alcance es bastante extenso en cuanto a contenido. Estas actividades que se
ocupan de la ingeniería y del diseño del sistema son críticas en el cumpli-
miento de los objetivos de la ingeniería de sistemas, de este modo, estas
actividades deben integrarse adecuadamente en el SEMP.
2.Ingeniería logística. Esta categoría general (definida aquí) cubre todas
las actividades que incluyen la definición inicial de los requerimientos del
sistema, el diseño para la capacidad de soporte del sistema y la prueba que
sigue, y el esfuerzo de evaluación. Las actividades de la ingeniería están
dirigidas hacia: 1) el diseño de los segmentos esenciales orientados a la
misión del sistema para soporte efectivo y económico y 2) el diseño de
la capacidad de soporte de tal manera que será sensible a los requerimien-
tos del sistema.21 El cumplimiento de estos objetivos puede realizarse, en
alto grado, a través de la incorporación de los principios de confiabilidad,
de mantenibilidad y de factores humanos en el diseño del sistema. Así, hay
muchos trabajos que son similares por naturaleza, que se realizan en
respuesta a los requerimientos especificados para un programa dado. Estos
trabajos deben integrarse adecuadamente a través del SEMP.
3. Soporte del sistema-producto. Teniendo en cuenta que un sistema
inicialmente se ha diseñado y producido (o construido), hay una serie de
actividades necesarias para asegurar que el sistema se mantenga de manera
tal que continúe satisfaciendo las necesidades del consumidor. Estas acti-
vidades se ocupan de la consecución, distribución, apoyo y mantenimiento
de soporte del sistema en esta áreayson críticas si el sistema debe satisfacer
los objetivos globales. Aquí el papel de la ingeniería de sistemas es la
valoración continua, evaluación, retroalimentación de datos, modificación
del sistema por acción correctiva conforme se requiera.

En resumen, el campo de la logística, que se define de diferente manera


por varias organizaciones y sectores de actividad, ¡está experimentando un
cambio! Aunque no todos los sectores ven la logística desde un enfoque del
ciclo de vida, éste es el énfasis aquí. Más adelante, este texto se ocupa
básicamente del funcionamiento "de los sistemas", comparados con los
productos de consumo. En el sector comercial, la logística trata esencial-

24 A través de los años, muchos progresos se han hecho en relación con responder el primer

objetivo, es decir, el diseño de los elementos esenciales del sistema para la capacidad de
soporte. No obstante, en opinión del autor, se ha realizado muy poco en relación con el diseño
de la capacidad de soporte.
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 155

mente diversos aspectos de distribución física, transportación, flujo de


material, almacenamientoy similares, desde una perspectiva de administra-
ción de empresas. Más adelante el énfasis es en los productos de consumo.`

3.2.6 Ingeniería de software

Con las tendencias actuales y el desarrollo continuo de la tecnología


computacional, el software se está volviendo (si no lo es ya) un elemento
importante en la configuración de muchos sistemas. La experiencia actual
indica que las consideraciones de software son inherentes en más del 50%
del diseño del sistema y en los esfuerzos de desarrollo. Los ingenieros de
sistemas no pueden tomar grandes decisiones de diseño de hardware sin
considerar las consecuencias del software.27
El software no es un sistema por sí mismo, sino que es un elemento
importante de un sistema junto con el hardware, el personal, las facilidades,
los datos, etc. Los requerimientos de software evolucionan directamente
de los requerimientos del sistema mediante el análisis funcional y el proce-
so de asignación descrito en la sección 2.6 (véase la figura 2.11). Se defi-
nen las funciones operativas y de mantenimiento (representando los "qués"),
los análisis de compromisos se realizan (para determinar los "cómos")
y aquellos requerimientos del sistema que especifican el software requeri-
do se identifican.
La ingeniería de software per se se refiere a la aplicación de principios
científicos matemáticos para desarrollo y mantenimiento de los programas
de computación, procedimientos y documentación asociada. El proceso de
ingeniería de software es similar a su contraparte, la ingeniería de hardware,
y cae en el contexto del proceso de ingeniería de sistemas global ilustrado
en la figura 1.7.28 Hay una función de planeación, una función de análi-
sis de requerimientos, diseño, codificación, utilización y mantenimiento.
Como es el caso de las otras áreas de la ingeniería discutidas anteriormente,

n Para obtener una perspectiva completa del campo de la logística, se recomienda que se
realicen estudios adicionales en esta área. Dos buenas referencias son: Bowersox, D., D. Closs
y O. Helferich. Logistical Management, Macmillan, New York, 1986; y Coyle., J., E. Bardi y C.
Langley, The Management ofBusiness Logisfics, 4' ed., West Publishing Company, St. Paul, 1988.
26 Aquí el objetivo es presentar una visión de software yrelacionar su importancia en el contexto

del proceso de la ingeniería de sistemas. Tres buenas referencias son: Boehm, B. W., Software
Engineering Economics, Prentice-Hall, Englewood Cliffs, Ni., 1981; Pressman, R. S.,
Software Engineering: A P-ractitioner's Appmach, McGraw-Hill, New York, 1982; y Shere, K. D.,
Software Engineering and Management, Prentice-Hall, Englewood Cliffs, N.J., 1988.
27 Defense Systems Management Coliege (DSMC), Mis.sion Critica¡ ComputerResourcesManagement

Guide, F'ort Belvoir, Virginia 22060.


11 La revisión de las diversas referencias que cubre el tema Indica algunas variantes en relación

con las fases en el ciclo de vida del software. No obstante, los objetivos globales son comunes.
Véase Shere, K. D., Software Engineering andManagement, Prentice-Hall, Englewood Cliffs, N.J.,
1988, capítulo 3, sección 3.2.
156 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

LIIIIIdentificación de la necesidad
111111
1 Diseño conceptual del sistema

Análisis de factibilidad, requerimientos operacionales, concepto de manteni-


miento, análisis funcional, asignación de los requerimientos, especificación del
sistema (tipo "Aa)

¿Enfoque de diseño?

Hardware

Diseño preliminar 1 Planeación de software y análisis deI 1


requerimiento
1

Diseño de detalle
1
4
Diseño del software (diseño
1
preliminar/detallado)
i


1' ____
Desarrollo de modelos 1 Codificación de software
prototipo 1
1
Prueba y evaluación de 1 1 1 Prueba y evaluación de 1
subsistema 1 1 software 1 1
L1J

1 Integración y prueba del sistema

Integración y prueba Utilización y soporte de apoyo del Mantenimiento del


del sistema sistema software

Retiro del sistema

Figura 3.25. Ciclo de vida del software.


DISCIPLINAS DE INGENIERÍA DEL DISEÑO 157

la ingeniería de software constituye un conjunto de métodos disciplinados.


Al referirse a la figura 3.25, se presenta una comparación simplificada
entre los pasos básicos en el desarrollo del software y los del desarrollo del
hardware. Una amplificación de los aspectos del software del proceso se
incluye a continuación:

1. Planeación del software. Una definición de alcance, ambiente


operacional del usuario, descripción del problema, estrategias de desarro-
llo y de soporte, características básicas funcionales, interfaces, filosofía de
consecución, etc., se incluye en el plan del software (algunas veces conocido
como el plan de recursos computacionales). Además, el plan debe incluir
planes del programa, datos de costos y una identificación de los recursos
necesarios para implementar el programa propuesto. Los requerimientos
de recursos pueden incluir diseñadores del sistema, programadores,
capturistas, hardware computacional para probar el desarrollo, software
existente que puede emplearse durante el desarrollo, etc. El plan de soft-
ware puede integrarse estrechamente en el SEMP.
2. Análisis de requerimientos. Una definición de los requerimientos del
sistema (por ejemplo, análisis funcional del sistema, funciones del opera-
dor, funciones de mantenimiento, asignaciones), la identificación de las
funciones del software, los factores de desempeño, restricciones, criterios
del diseño del software específico, diagrama de bloques funcionales del
software de alto nivel o información-diagramas de flujo de datos, etc., se
incluyen. Los requerimientos del software se derivan de los requerimientos
del nivel del sistema y los diagramas de información-flujo de datos, deben
evolucionar directamente de los diagramas de bloque funcionales que
describen el sistema, como se discutió en la sección 2.5. Esta información se
incluye generalmente en una especificación de los requerimientos de soft-
ware, es decir, en una especificación tipo "B".
3. Diseño preliminar. El desarrollo de una estructura jerárquica de
software se realiza para determinar las relaciones básicas entre los elemen-
tos funcionales de software, módulos y acoplamientos de los requerimien-
tos de interfaz. Los diagramas de información-flujo de datos se desarrollan
más adelante y los requerimientos de base de datos se definen.
4. Diseño de detalle. El desarrollo de diagramas de flujo detallados (de
los diagramas de flujo funcionales), se realiza y los requerimientos de len-
guaje(s) para el diseño de programas y la aplicación de las herramientas
adecuadas del diseño se identifican.
S. Codificación de software. La preparación y escritura de programas que
usan codificación estructurada, el formato apropiado de codificación y la
documentación de codificación, la depuración y procedimientos de verifica-
ción de errores, etc., se realizan.
6. Prueba y evaluación de software. Una "verificación" del diseño de
software se realiza para asegurar que cada uno de los diversos productos
158 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

individuales de software satisface su propósito específico. La verificación


del proceso a menudo constituye un enfoque paso por paso para probar un
programa, seguido por la prueba de un segundo programa dados los
resultados del primero, etc. La verificación es iterativa por naturaleza y está
orientada generalmente a los items específicos del software. Por otra parte,
"la validación" está enfocada hacia el nivel del sistema. La meta es asegurar-
se de que los elementos globales del software del sistema cumplen con los
requerimientos de la especificación del sistema. Esto se realiza a través de
la prueba y evaluación del sistema donde el software está integrado con el
hardware, con el personal de operación, con las facilidades, con los elemen-
tos de soporte, etcétera.

Estos pasos proporcionan sólo una visión superficial de los elementos


más importantes del ciclo de vida del software. Otro ejemplo se presenta en
el "modelo de cascada" ilustrado en la figura 3.26.21 Con los requerimientos
del software que crecen en relación con las aplicaciones del sistema y con
los costos de software que se incrementan a una rápida velocidad, es
importante que estos requerimientos se integren adecuadamente y se
controlen a través del proceso de ingeniería de sistemas.

3.2.7 Ingeniería de la capacidad de producción30

La capacidad de producción es una medida de la facilidad relativa y de la


economía al producir un sistema o un producto. Las características del
diseño deben ser tales que un ítem pueda producirse fácil y económicamen-
te, usando métodos de manufactura y procesos convencionales y flexibles,
sin sacrificar funciones, desempeño, efectividad o calidad. Algunos objeti-
vos más importantes para el diseño de un sistema para la capacidad de
producción se observan en seguida:

1.La cantidad y variedad de los componentes utilizados en el diseño del


sistema deben mantenerse al mínimo. Los ítems comunes estándares deben
seleccionarse cuando sea posible y debe haber un número de diversas
fuentes del proveedor disponibles durante el ciclo de vida planeado del
sistema.
2. Los materiales seleccionados para construir el sistema deben ser
estándares, estar disponibles en las cantidades deseadas y en el tiempo
apropiado y deben poseer las características de fácil fabricación y pro-
cesamiento. El diseño debe evitar la especificación de forma peculiar que

Boehm, B.W., Software Engineering Economics, Prentice-Hall, Englewood Cliffs, N.J., 1981,
capítulo 4 (reproducido con permiso).
Del ense Systems Management college (DSMC), Manufacturing Management Handbook For
Program Managers, Fort Belvoir, Virginia, 22060.
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 159

idd
d sistema
Validación

Planes y requerimientos
del software

Validación

Diseño del producto

Verificación

Diseño detallado

Verificación

Codificación

Prueba unifaria

Integración
Verificación
M producto

lmplementación

Prueba del sictema

Operaciones
y mantenimiento

Revalidación

Figura 3.26. El modelo de cascada del ciclo de vida del software.

requiere amplia maquila y (o) la aplicación de métodos de manufactura


especiales.
3.La configuración del diseño debe permitir el fácil ensamblado (y desen-
samblado, conforme se requiera) de los elementos del sistema, es decir,
equipo, unidades, ensamble y módulos. Los métodos de ensamble deben
ser simples, repetitivos, económicos y no deben requerir la utilización
de herramientas especiales ni de mecanismos o personal de alto nivel de
adiestramiento.
4. La configuración del diseño debe ser simple a tal grado que el sistema
o producto pueda producirse por más de un proveedor, usando un paquete
de datos dado y los métodos-procesos de manufactura convencionales.
160 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

El diseño debe ser compatible con la aplicación de tecnología CAD/CAM


cuando sea apropiado.
Los objetivos básicos fundamentales son "sencillez" y "flexibilidad" en
el diseño; más específicamente, es la meta para minimizar el uso de materia-
les críticos y procesos críticos, el uso de ítems patentados, el uso de
herramienta especial para la producción, la aplicación de tolerancias poco
realistas en la fabricación y ensamblado, el uso de sistemas de prueba
especiales, el uso de adiestramiento elevado para el personal de manufac-
tura y los tiempos de producción-consecución.
La ingeniería de la capacidad de producción es el esfuerzo necesario
para asegurar una transición sin inconvenientes del diseño de sistema
y desarrollo a su producción (o construcción). Esto requiere las actividades
coordinadas de la ingeniería de diseño y manufactura y generalmente
incluye la realización del siguiente programa de trabajo:
1.Plan de la capacidad de producción. Un plan se desarrolla para ase-
gurar la implementación adecuada de los requerimientos de la capacidad de
producción durante un programa dado. Este plan puede incluirse como una
sección en el SEMP, o un documento independiente por separado.
2.Los requerimientos de/a capacidad de producción. Los requerimientos
específicos del diseño del nivel del sistema se desarrollan durante el diseño
conceptual de avance de la fase de planeación y se incluyen en las especifi-
caciones de un sistema tipo "A" (véase la figura 3.3). Además, los requeri-
mientos en el subsistema, equipo, unidad, ensamble y nivel de componentes
deben incluirse en el desarrollo adecuado, proceso, producto y especifica-
ciones de material (los tipos "8", "C" y "E").
3.Análisis del sistema y estudios de compromisos. La capacidad de la
producción puede considerarse como una característica del diseño del
sistema-producto y cada alternativa del diseño debe evaluarse mediante el
uso del enfoque general ilustrado en la figura 3.27
4.Revisiones del diseño. Ambas revisiones del diseño, la informal y la
formal, deben cubrir los requerimientos de la capacidad de producción en
el proceso de evaluación. Dada una configuración definitiva del diseño, las
preguntas en la figura 3.28 (en el apéndice B) pueden utilizarse para la
valoración de propósitos. Las recomendaciones para el mejoramiento
pueden procesarse antes de que ¡el diseño se considere fijo!
En resumen, la ingeniería de la capacidad de producción pertenece a la
parte del diseño del sistema que trata la habilidad de un ítem de reproducir-
se en múltiples cantidades, basada en una configuración de un diseño dado.
Esto no es común en un producto que se desarrolla como resultado de una
investigación avanzada de un esfuerzo de desarrollo, usando las prácticas
difíciles de laboratorio de ingeniería y luego teniendo una solicitud inmedia-
ta de más de 300 (requeridos ayer). Aunque los resultados de la experiencia
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 161

Requerimientos del sistema

Configuración propuesta del diseño

Selección de componentes-materiales-diseños

¿Los componentes y materiales satisfacen los requerimientos del

Po
diseño (tensión, desgaste, resistencia a la corrosión, dureza,
ductibilidad, electronegatividad, etcétera)?


¿Están los componentes y los materiales comercialmente disponibles No
(más de una fuente o proveedor)?


¿Son los procesos de manufactura propuestos compatibles con los 1 No
componentes-materiales (exactitud, tolerancia, cantidad, disponibi-
lidad)?

¿Están los componentes-materiales dispuestos (diseñados oarma- No


dos) para permitir facilidades y economía en el desarrollo de las
funciones de ensamble-desensamble)?

4 sí
la configuración de diseño propuesta adecuadamente re-
rep No
sentada a través de una buena documentación (dibujos de manufac-
tura aprobados y publicados, listas de partes, etcétera)?
Recomendaciones
para mejoramiento

¿Es la configuración de diseño óptima para la capacidad de pro7duc-1 No
ción (puede algunas mejoras habilitarse véase la figura 3.28)? 1

Producción-construcción de sistema

Figura 3.27. Consideraciones de la capacidad de producción.

en laboratorios han probado ser exiLsos, el modelo de ingeniería desarro-


llado incluirá posiblemente el uso de componentes no estándares no
aprobados disponibles sólo en los almacenes del laboratorio. En otras
palabras, el modelo de laboratorio desarrollado puede haber demostrado
exitosamente la realización de ciertas metas relacionadas con el desempe-
162 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

tio, pero no se tiene en esta etapa una configuración de producción.


El trabajo que debe concluirse es la conversión del modelo de laboratorio
a un prototipo de producción, construido con datos de manufactura,
dibujos e incorporando los componentes estándares aprobados adecua-
dos. El objetivo es convertir los resultados de la investigación y los esfuer-
zos de desarrollo en una entidad capaz de producirse.

3.2.8 Ingeniería de calida0

En años recientes, la industria de los Estados Unidos, el Departamento de


Defensa y otras entidades han puesto mucho énfasis en el tema de calidad.
La motivación esencial en la "sobrevivencia" dentro de un ambiente interna-
cional altamente competitivo. En general, la disponibilidad de efectividad de
costos, sistemas de alta calidad-productos de fuentes internacionales se
han incrementado y la competencia está motivando a las industrias a hacer
un mejor trabajo en el diseño y producción de los sistemas. Como resultado,
el área de "calidad", aunque no es nueva, está experimentando un cambio en
cuanto al énfasis.
En el pasado, la satisfacción de los objetivos de calidad, se ha realizado,
esencialmente en las fases de producción y (o) construcción del ciclo de
vida mediante la implementación del control de la calidad formal (QC)
o programas de aseguramiento de calidad (QA). Las técnicas del control
estadístico del proceso (SPC), las actividades de inspección de entradas
y dentro del proceso, los programas de control de monitoreo estrechamen-
te con el proveedor, revisiones periódicas y métodos de solución de
problemas han sido implementados con el objetivo de conseguir un nivel
designado de calidad del sistema. Estos esfuerzos han sido básicamente
realizados "a posteriori", ¡y los resultados globales han sido cuestionables!
Recientemente, el aspecto de "calidad" se ha visto más desde una
perspectiva de arriba-abajo del ciclo de vida, y el concepto de "Administra-
ción de calidad total" (TQM) ha evolucionado. 12 La TQM puede describirse
como un enfoque de administración integrada total que se ocupa de la calidad
del sistema-producto en todas las fases del ciclo de vida y en cada nivel
dentro de la jerarquía global del sistema. Esto proporciona una orientación

Referencias seleccionadas que cubren varias facetas de la calidad, aseguramiento de la


calidad, control de calidad, etc., se identifican en la bibliografía en el apéndice D.
32
El Departamento de Defensa, en particular, ha estado avocándose a TQM y hay muchas
referencias que cubren el tema desde muchas perspectivas. Tres referencias acerca de esto son
Stuelpnagel, T. R., "Total Quality Management", National Defense, Journal of the American
Defense Preparedness Association (ADPA), Suite 900, 1700 N. Moore Street, Arlington, Virginia
22209, noviembre de 1988; DOD 5000.51G., "Total Quality Management- A Guide br
Implementation", Departamento de Defensa, Washington, DC; and SOAR-7, "A Guide for Imple-
meiting total Quality Management", ReliabilityAnalysis Center, Rome Air Development Center,
Griffiss AFB, New York 13441, 1990.
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 163

Lista de verificación de la probabilidad

1. ¿Puede ser bastante simplificado el diseño?


2. ¿Pueden combinarse en uno dos o más componentes?
3. ,Pueden hacerse idénticos, los componentes con diferencias insignificantes?
4. ¿Puede estandarizarse el diseño en gran medida; por ejemplo, uso más importante de los componentes
estándares y materiales?
S. ¿Puede modificarse el diseño para evitar el uso de componentes y materiales críticos y (o) patentados?
6. ¿Puede un componente estándar con un nivel de stock de material ser usado para remplazar un ítem
manufacturado?
7. Son los métodos de manufactura consistentes y estándares en relación con formado, doblado, tensado,
maquinado, tipos de fundición, maquinación, fresado, despacho de aduana, envasado, etcétera?
8. ¿Puede usarse un material diferente que es más fácil de maquinar?
9. Los métodos de manufactura propuestos ¿son compatibles con los métodos CAD/CAM donde sea aplicable?
10. Las exactitudes-tolerancias ¿son razonables y consistentes con las múltiples capacidades de procesos de
fabricación?
11. ¿Puede reducirse el costo mediante el uso de un componente menos costoso, un material, o un proceso de
manufactura más simple?Se especificó el proceso de manufactura más económico?
12. ¿Puede reducir el costo a través de la sustitución del componente- materiaI?Puede usarse una válvula de
material más ligero?
13. ¿Son las especificaciones-estándares consistentes con el ambiente planeado de producción?
14. ¿Han sido minimizados los requerimientos de recubrimiento de componente-material?
15. ¿Se minimizaron los requerimientos de inspección y prueba?Se han desarrollado donde se requieren los
métodos de pruebas no-destructivas? ¿Es el enfoque económico?

Figura 3.28. Lista de verificación de la productividad seleccionada

previa y se enfoca en el diseño del sistema y actividad de desarrollo así como


en la producción, manufactura, ensamble, construcción, soporte del pro-
ducto y funciones relacionadas. La TQM es un mecanismo de unificación
que vincula las capacidades humanas a la ingeniería, producción y procesos
de soporte. Esto proporciona un balance entre "el sistema técnico" y el
"sistema social". Algunas características específicas de la TQM se indican
abajo:`

1. La satisfacción total del cliente es el objetivo esencial comparado


a la práctica de realizar lo menos posible de acuerdo con los
requerimientos mínimos. La orientación al cliente es importante
(contra el enfoque "qué puedo yo lograr con").

11 Sealienta al lector a revisar la literatura que cubre las actividades japonesas en el área global
de "calidad". También, en las obras de Crosby, Deming yiuran se proporcionará una visión más
amplia acerca del área del tema y se recomiendan ampliamente (véase al apéndice D). Esta
sección discute algunos principios de la TQM, es decir, la satisfacción del cliente, la participa-
ción individual, el mejoramiento continuo, el diseño fuerte, la variabilidad, responsabilidad de
la administración y la integración del proveedor.
164 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

2. El énfasis está puesto en la práctica iterativa de "mejoramiento


continuo" aplicado a la ingeniería de producción y procesos de
soporte, funciones y similares. El objetivo es ver el mejoramiento en
una base día por día, comparado a la práctica de último minuto
a menudo impuesta, iniciada para forzar la conformidad con algún
estándar. La práctica japonesa de este enfoque es a través de la
implementación de un proceso que se conoce como "kaizen".
3. Reforzando el ítem 2, se requiere un entendimiento individual de los
procesos, los efectos de variación, la aplicación de métodos de
control de procesos, etc. Si los empleados individualmente deben
ser productivos en relación con el mejoramiento continuo, ellos
deben enterarse de los diversos procesos y sus características
inherentes. La capacidad de que varíen debe minimizarse (si no
eliminarse).
4. La TQM señala un enfoque total organizacional que involucra cada
grupo de la organización y no precisamente la función de control de
calidad. Los empleados individuales deben motivarse desde aden-
tro y deben reconocerse colaboradores claves para cumplir los
objetivos de calidad.

Incluidos en el espectro más amplio de TQM están los aspectos más


importantes de la ingeniería y el "diseño de calidad" es decir, la ingeniería
de calidad. Al referirse a la sección 1.1.1, los ciclos de vida proyectados,
ilustrados en la figura 1.2, ¡deben considerarse en su totalidad! Un sistema se
concibe, diseña, produce, utiliza y sustenta durante su ciclo de vida planea-
do. Como parte del esfuerzo inicial del diseño del sistema, la consideración
debe llevarse hacia: 1) el diseño del proceso que será utilizado para producir
este sistema y 2) el diseño de la configuración de soporte que será utilizado
para proporcionar el mantenimiento continuo necesario para el soporte de
ese sistema. Como las interacciones entre estas diversas facetas de activi-
dad del programa son numerosas, ¡es importante que estas áreas se traten
en una base integrada desde el inicio!
Estas relaciones del programa han sido reconocidas por el Departamen-
to de Defensa a través del inicio del concepto de "ingeniería concurrente",
que se define como "un enfoque sistemático para el diseño integrado,
concurrente de productos y sus procesos relacionados, incluyendo manu-
factura y soporte. Este enfoque se intenta a fin de que los desarrolladores,
desde el principio, consideren todos los elementos del ciclo de vida del
producto desde la concepción hasta el desecho, incluyendo calidad, costos,
planes y requerimientos del usuario."" El objetivo de la ingeniería concu-

34 Report R-338, "The Role of Concurrent Engtneering in Weapons System Acquisltíon",


Institute For Defense Analysls, 1801 N. Beauregard Street, Alexandria, Virginia 22311, diciembre
de 1988.
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 165

rrente incluye: 1) mejorar la calidad de efectividad de los sistemas-produc-


tos por medio de una mejor integración de los requerimientos y 2) reducir
el tiempo del ciclo de desarrollo del sistema-producto mediante una mejor
integración de actividades y procesos. Esto, a su vez, debe resultar en una
reducción de los costos totales del ciclo de vida para un sistema dado.
Desde la perspectiva de este texto, la acometida esencial es la ingeniería
de calidad y su papel como parte del proceso de ingeniería de sistemas.
En una relación similar a la ya expresada para la logística (véase la sec-
ción 3.25), hay una gran preocupación por la TQM y algunas preocupacio-
nes específicas asociadas con la calidad en relación con el diseño de
ingeniería. Con esto en mente, las siguientes actividades se consideran
apropiadas a la ingeniería de sistemas.

1.Planeación de la calidad. El desarrollo de un plan TQM (o equivalente)


debe realizarse durante el diseño conceptual y actualizarse durante el
diseño preliminar de detalle como sea requerido. Inherente a este plan
global son las actividades de ingeniería que incluyen: a) la determinación
de los requerimientos del diseño de la ingeniería que usan un QFD "casa de
calidad", o el enfoque equivalente; b) la evaluación y el diseño de la
manufactura y procesos de ensamblado como respuesta a las decisiones de
la tecnología de diseño; c) la participación en la evaluación y selección de
los componentes del sistema y las fuentes del proveedor; d) la preparación
del producto, procesos, especificaciones del material como se requiere
(tipos "C", "D" y "E"); e) la participación en las revisiones del proveedor en
su lugar; y f) la participación en las revisiones del diseño formal. Éstas y las
actividades relacionadas deben incluirse también en el SEMP.35
2. Calidad en eldiseño. Esta área de actividad, visualizada en el contexto
más amplio, pertenece a muchos de los asuntos discutidos durante las
secciones anteriores de este capitulo. El énfasis está dirigido hacia la
sencillez, sensibilidad, estandarización del diseño, etc. De una naturaleza
más específica son los problemas para la "variabilidad" donde una revisión
en la variación de definiciones para los diseños de los componentes especí-
ficos, o las tolerancias en los diseños del proceso, resultarán probablemente
en un mejoramiento global. El enfoque general de Taguchi para un "diseño
robusto" es proporcionar un diseño que no sea sensible a las variaciones
encontradas normalmente en la producción y (o) en el uso operacional.
Entre más robusto sea el diseño tendremos menos requerimientos de

"Casa de calidad" se refiere a la metodología básica para Implementar un programa "de


exhibición de la función de calidad (QFD)". Los focos de atención del QFD son la planeación
y comunicación que usan un enfoque de equipo interrelacior&ado con el sistema. Esto propor-
ciona un marco para valorar los atributos de producto y para transformarlos en requerimientos
de diseño de ingeniería. Véase Hauser, J.R. y D. Clausing, "The House oí Quality", Harvard
Business Reuiew, mayo-junio de 1988, pp. 63-73.
166 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

soporte, costos más bajos en el ciclo de vida y grado más alto de efectividad.
El mejoramiento del diseño global se anticipa a través de una combinación
de una evaluación cuidadosa de los componentes y la selección, el empleo
adecuado de métodos estadísticos de control de proceso (SPC) y la aplica-
ción de un enfoque de pruebas experimentales, aplicados en una base
continua.

El tema de la calidad se refiere a ambas características del diseño, de los


aspectos técnicos y humanísticos en la realización de las actividades de
diseño. No sólo hay un problema en relación con la selección y aplicación
de los componentes, sino que la satisfacción exitosa de los objetivos de
calidad depende en gran medida de las características del comportamiento
de aquellos involucrados en el proceso de diseño. Teniendo un conocimien-
to a fondo de los requerimientos del cliente, la buena comunicación, un
enfoque de "equipo", la voluntad de aceptar los principios básicos de
la TQM y demás, son todo lo necesario. Respecto a esto, los objetivos de la
ingeniería de calidad son inherentes al alcance de la ingeniería de sistemas.

3.2.9 Ingeniería vaIoicosto37

El material presentado hasta ahora ha subrayado las características técni-


cas del sistema o los factores técnicos listados en la figura 3.29 (también
véase la figura 2.13). Estas características que incluyen desempeño,
confiabilidad, mantenibilidad, factores humanos, capacidad de soporte
y calidad, representan sólo una parte del espectro global de los factores que
se usan en la evaluación del sistema. La otra parte del balance pertenece
a los factores económicos.
En la evaluación del sistema, estos factores técnicos y económicos
a menudo se combinan de una manera tal que proporcionan una medida de
efectividad. El objetivo es medir un sistema en términos de algún parámetro
técnico global o parámetro relacionado con el desempeño y su valor desde
el punto de vista de ingresos y costos. Aunque estas figuras de mérito
(FOMs) de efectividad variarán de una aplicación a la siguiente, unos
cuantos ejemplos se dan.
(Desempeño) (Disponibilidad)
Efectividad FOM = (3.24)
Costo del ciclo de vida

3' Eldoctor Genichi Taguchi ha desarrollado técnicas matemáticas para aplicaciones relativas
a la evaluación de las variables del diseño. Véase Rose, P. J., Taguchi Techniques for Quality
Engineering, McGraw-Hill, New York, 1988.
31 Los aspectos económicos y el costo del ciclo de vida se verán con detalle en Fabrycky, W. J.

y B. S. Blanchard, Life-Cycle Cost and Economic Analysis, Prentice-Hall, Englewood cliffs, N.J.,
1991. Las referencias adicionales en cuanto a economía de la ingeniería, costos del ciclo de vida,
costo estimable, etc., están incluidas en el apéndice D.
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 167

• Beneficios (ingresos) • Características de desempeño

• Ciclo de vida • Confiabilidad

1.Investigación y desarrollo de costos • Mantenibilidad

2. Costo de producción y (o) construcción • Factores humanos

3. Costo de operación y mantenimiento • Seguridad

4. Costo de retiro y desecho • Capacidad de soporte (logística)

• Calidad

• Otros factores

Objetivo

Un enfoque balanceado

Figura 3.29. Factores de evaluación del sistema.


168 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

Efectividad FOM = Capacidad del sistema


(325)
Ingresos-Costos
Costo del ciclo de vida
Efectividad FOM (3.26)
Facilidades de espacio
Soporte
Efectividad FOM = (3.27)
Costo del ciclo de vida
U otras.

Teniendo en cuenta los factores económicos, los ingresos ylos costos


deben considerarse; estos últimos se expresan en términos de costos del
ciclo de vida (LCC). El costo del ciclo de vida incluye el compuesto de
investigación y costo de desarrollo, costos de producción y (o) construc-
ción, costo de operación y mantenimiento del sistema, costo de retiro
y desecho. Un ejemplo de una estructura desglosada de costos (CBS),
mostrando el espectro total del costo a través del ciclo de vida del sistema,
está presentado en la figura 3.30. Aunque las decisiones pueden basarse en
ciertas facetas de costo (por ejemplo, el precio inicial de la consecución), el
impacto de tales decisiones en los costos del ciclo de vida necesita valorarse
a fin de determinar los riesgos asociados con tales decisiones. Las interac-
ciones entre las diversas categorías de costo son numerosas.
Cuando se considera la economía en el diseño del sistema (por ejemplo,
"diseño para factibilidad económica"), los pasos son similares a aquellos
seguidos al tratar los requerimientos de confiabilidad, los requerimientos
de la mantenibilidad, etc., yse ilustran en la figura 3.31. Más específicamente:

1.Costos de " metas", que reflejan las consideraciones del costo del ci-
clo de vida, pueden establecerse desde el inicio durante el diseño concep-
tual. Una meta así puede expresarse como costo de diseño (DTC), "diseño
del costo del ciclo de vida", etc. Este factor puede dividirse más adelante en
"diseño para costo de creación de unidad", "diseño de costo de unidad de
producción", "diseño de costo de unidad operacional y de soporte", o alguna
combinación de estos. Dichos valores de metas deben especificarse en la
definición de los requerimientos operacionales del sistema (véase la sec-
ción 2.3).
2. Los factores económicos cuantitativos especificados que son aplica-
bles en el nivel del sistema deben asignarse a los elementos apropiados del
sistema, conforme se necesite asegurar que la economía se refleja en el
diseño de estos elementos (véase la sección 2.6).
3. Análisis del costo y del ciclo de vida se realizan durante el proceso de
diseño en la evaluación de alternativas, para asegurar que el último enfoque
seleccionado refleja las consideraciones económicas. Las aplicaciones
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 169

alternativas de tecnología, conceptos operacionales, políticas de soporte,


esquemas de empaque de equipo, niveles de reparación, rutinas de diagnós-
tico, etc., se evalúan por medio un análisis de costos del ciclo de vida.
4. Durante la producción y uso operacional del sistema, los análisis de
costos del ciclo de vida se realizan para identificar "contribuidores de alto
costo" y para asistir al determinar las relaciones causa y efecto, llevando las
recomendaciones para el mejoramiento del sistema-producto. Las propues-
tas se generan con el objetivo de reducir los costos del ciclo de vida.

Los análisis del costo del ciclo de vida del sistema (en una forma u otra)
se realizan durante el diseño, desarrollo del sistema, durante la producción
yuso operacional. La conclusión de esto, un esfuerzo, generalmente requie-
re que uno siga ciertos pasos tales como aquellos presentados en la figu-
ra 3.32. Refiriéndose a la figura, uno necesita avanzar desde la etapa de
definición del problema hasta la definición de los requerimientos del
sistema, el desarrollo de una estructura desglosada de costos (CBS), perfiles
de costos, resúmenes, etc. Aunque este proceso es característico de un
enfoque de análisis del sistema común, una consideración importante es
asegurar que los asuntos económicos se traten en términos del ciclo de vida
completo del sistema. En el apéndice "A" de este texto se presenta con
profundidad un ejemplo de los pasos empleados para la realización de un
análisis de costo del ciclo de vida.
Inherente a este enfoque para los costos del ciclo de vida es el concepto
de "ingeniería de valor". Ingeniería de valor, una disciplina iniciada por el
Departamento de Defensa de Estados Unidos en los últimos cincuentas
años, y puede definirse como "un esfuerzo sistemático dirigido a analizar la
función de sistemas, equipo, facilidades, servicios y suministros para alcan-
zar las funciones esenciales a los costos más bajos del ciclo de vida sin
comprometer el desempeño requerido, la confiabilidad, calidad y seguri-
dad".38 La ingeniería de valor está basada en la visualización del diseño
desde el punto de vista "costo de manufactura" y el énfasis en el pasado ha
estado esencialmente orientado a la fase de producción de un programa.

La ingeniería de valor, sus objetivos, los pasos en el desempeño de un análisis de evaluación,


el proceso de preparar y presentan las Propuestas de Cambio de la Ingeniería de Evaluación
(VECPs) y requerimientos relacionados se discuten en Defense Systems Management College
(DSMC), Defense Manufacturing Management, DSMC, Fort Belvolr, Virginia 22060. Este tema
también se anota en 0MB Circular A-131, "Value Englneering", febrero de 1988.
Referencias: Diseño conceptual Diseño preliminar del sistema
figura 1.7
(capitulo 1) Diseño de detalle y desarrollo
Estudio de factibilidad, requerimientos
operacionales del sistema, concepto de Análisis funcional del sistema, asignación de los re-
mantenimiento, avance de la planeación querimientos, estudios decompromisos yoptimización,
M sistema-producto. síntesis, revisión del diseño, desarrollo del prototipo,
prueba y evaluación del sistema.
ldenbticación del costo de diseño (DTC) y
costo del ciclo de vida (LCC) figuras de Distribución de las metas-metas de costos, análisis de
mérito cuantitativos-metas. costo del ciclo de vida, modelado, estimación de cos-
tos, desarrollo de perfiles, identificación de los colabo-
radores de alto costo, análisis de sensibilidad, análisis
de riesgo, modificaciones del sistema para mejora-
miento.

Producción y(o) construcción Utilización del sistema y soporte del ciclo


de vida

Manufactura, producción, ensamblado y prueba Uso operacional del sistema y manteni-


de los componentes del sistema y elementos de la miento de apoyo del ciclo de vida y soporte.
capacidad de soporte.

Análisis del costo del ciclo de vida, modelado, Análisis del costo del ciclo de vida, mode-
identificación de los colaboradores de costo alto, lado. Identificación de los colaboradores
modificaciones del sistema para mejoramiento, de costo alto, modificaciones del sistema
(reducción en el costo del ciclo de vida). para mejoramientos (o reducción en el
costo del ciclo de vida).

Figura 331. Consideración del valor-costo en el ciclo de vida del sistema.


Costo total del sistema (C)

y Costos operacionales del sistema (Ca) Costos de mantenimiento y so- Costo de retiro y desecho
porte (Cg) (C.,)
Administración del sistema (C)
Administración de la producción Administración demantenimn- Administración del siste-
Planeación del sistema (C) (CTU) Distribución del producto (C.) to(C) ma(C..)

Administración del sistema (C) Ingeniería industrial y análisis de Instalación del sistema (CC,) Personal de mantenimiento Retiro del sistema-produc-
(C) to(C1)
Investigación del producto (C) Personal operante (CC )
• Ingeniería de planta Parles excedentes-da repara- Desecho de Ilems decla-
Diseño de ingeniería (C) • Ingeniería de manufactura Operación de instalaciones ción ycontrol de inventano (C,) rados no reparables (C)
• Métodos de ingeniería
• Ingeniería de sistemas • Control de la producción Prooiedad-bienes raíces {C) Documentación (Cx)
• ingeniería eléctrica Equipo de prueba y soporte (C,)
• Ingeniería mecánica [ Manufactura (C) a
• Otras ingenierías Mantenimiento de instalaciones
Recursos computacionales (C) Datos
Soporte Iogisco (CFJ
Construcción (C) Operador y entrenamiento de
Documentación del diseño (Cm) mantenimiento-equipode entre-
Soporte logisúco (C) namiento. (C,,,)
Software del sistema-producto (C)
{ Administración del proveedor (C4 Datos de mantenimiento (C)
Prueba y evaluación del sistema (CR )
Control de calidad (C) Transportación y manejo (C)

Modificaciones del sistema (C-)


Figura 3.30. Ejemplo de estructura desglosada de costos.
172 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

Paso Actividad

1 Definir el problema.

2 Identificar las alternativas - configuraciones factibles que se evalúan a través del análisis LCC.

3 Proyectar las altemafivas en relación con los requerimientos del sistema

a. Definirlos requerimientos operacionales.

b. Definir el concepto de mantenimiento del sistema.

c. Identificar y jerarquizar las actividades del ciclo de vida.

4 Desarrollo de una estructura desglosada de costos (CBS)-categorías de costo y relaciones


estimadas de costo.

5 Desarrollo de un modelo de costos (o seleccionar uno nuevo) que es sensible al problema a mano
y que puede utilizarse efectivamente para facilitar el proceso de análisis.

6 Estimar los costos apropiados para cada actividad, para cada año en el ciclo de vida proyectado-
factores conocidos de costo, factores análogos de costo y relaciones estimadas paraniétricas de
costos. Incluye los defectos de inflación, lectura de curvas, etcétera.

7 Desarrollo de un perfil de costo (costos infiacionados) para cada alternativa que se evalúa.

8 Desarrollo de un resumen de costo (costos de valor presente desconfinuados) paracada alternativa


y compararlos resultados en términos de preferencias.

9 Realizar un análisis oportuno que muestre los momentos en el tiempo de una alternativa dada que
asume como posición preterida.

10 Identificar los colaboradores de "costo alto" y determinar las relaciones causa y efecto.

11 Realizar un análisis de sensibilidad.

12 Realizar un análisis de riesgo e identificar las áreas potenciales de alto riesgo.

13 Recomendar un enfoque preterido-seleccionar las alternativas más deseables.

Figura 3.32. Los pasos básicos en un análisis de costo del ciclo de vida.

3.3 RESUMEN

Inherentes al proceso de ingeniería de sistemas descritos en el capítulo 2


son los requerimientos de confiabilidad, mantenibilidad, capacidad de
soporte, calidad y similares. Unas pocas disciplinas del diseño tales como
éstas han sido seleccionadas para discutirlas en la sección 3.2 de este
capítulo. En cada caso hay ciertos pasos que se siguen a fin de cumplir los
objetivos especificados. Inicialmente, los requerimientos para confiabilidad,
mantenibilidad, etc., deben establecerse al definir los requerimientos
operacionales y el concepto de mantenimiento del sistema. Los análisis
RESUMEN 173

funcionales y la distribución de estos requerimientos son necesarios para


identificar los criterios de entrada del diseño. Los análisis y estudios de
compromisos se realizan ene! proceso de utilización del diseño. Finalmente,
los requerimientos especificados inicialmente se verifican a través de la
prueba y evaluación de! sistema. Estos pasos, que son característicos en
cada caso, se ilustran en la figura 3.33.
Aunque las disciplinas de diseño en este capítulo han sido introducidas
como requerimientos individuales por separado, hay un cierto grado de
interdependencia entre ellas. Los requerimientos de la mantenibilidad
están basados en la confiabilidad. Los requerimientos de la capacidad de
soporte dependen de los datos de confiabilidad y mantenibilidad, los
factores de confiabilidad están basados en los factores humanos, etc. Estas
disciplinas no sólo construyen sobre el diseño básico (por ejemplo, diseño
eléctrico, diseño mecánico, etc.), sino que construyen sobre cada otra. En la
sección 3.2 se hace un intento para mostrar estas relaciones a través de tipo
de presentación del material.
Finalmente, con los objetivos de la ingeniería de sistemas en mente, es
esencial que el nivel adecuado de comunicación se establezca entre estas
disciplinas. Esta comunicación debe reflejarse a lo largo de los planes
respectivos individuales del programa, y debe haber un libre intercambio en
el diseño y los datos relacionados con el diseño a fin de satisfacer los di-
versos análisis y!as funciones de soporte del diseño. La necesidad de integrar
estas actividades en un esfuerzo efectivo de ingeniería de diseño es el
aspecto más importante de la ingeniería de sistemas.

PREGUNTAS Y PROBLEMAS
1. ¿Qué es un «árbol de documentación"? ¿Por qué es importante
generar uno para un programa?
2. Seleccione un sistema y desarrolle un bosquejo de una especifica-
ción tipo "A" para el sistema.
3. Defina "confiabilidad". ¿Cuáles son las medidas de confiabilidad?
4. Cien partes son probadas por 10 horas y 10 fallas ocurrieron durante
la prueba. Las horas a las que ocurrieron las fallas son 1, 3, 6, 2, 3, 6,
8, 9, 2 y 1 respectivamente. ¿Cuál es la tasa de fallas?
S. Los datos de campo han indicado que la unidad "A" tiene una tasa
de fallas de 0.0004 fallas por hora. Calcule la confiabilidad de la
Unidad para una misión de 150-horas.
6. Un sistema consiste en 4 subensambles conectados en serie.
Las confiabilidades individuales de los subensambles son A = 0.98,
B = 0.85, C = 0.90, D= 0.88. Determine la confiabilidad global del
sistema.
174 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

---------
Requerimientos del sistema

i 1 1
_
para para
desempeño
J;--
confiabilidad humanos seguridad
H

1 Diseñopara 1 1 Diseñopara 1 1 Diseño 1 1 Diseñopara 1


capacidad 1 1 capacidad deI 1 para 1 otras carac-
de soporte producción 1 calidad terísticas
L
_ _J

Análisis del sistema y compromisos

Revisión del diseño

Prueba y evaluación

No
sfacto
'os
.
Y
<resultados9

Producción y (o) construcción

Figura 3.33. El proceso de diseño

7. Un sistema consiste en tres subsistemas en paralelo. El subsistema


"A" tiene una confiabilidad de 0.98, el subsistema "B" tiene una
confiabilidad de 0.85 y el subsistema "C" tiene una confiabilidad de
0.88. Calcule la confiabilidad global del sistema.
S. En la siguiente figura, las confiabilidades de los componentes son
A= 0.95, B =0.97, C =0.92, D = 0.94yF = 0.88. Determine la confiabilidad
global de la red.
PREGUNTAS Y PROBLEMAS 175

Entrada

Figura 3.P1. Red del problema 8.

9.

Entrada Salida

Figura 3.P2. Red del problema 9.

Desarrolle la expresión de confiabilidad global (Re) para la red de


arriba.
10. Hay una variedad de ayudas (o herramientas) que pueden usarse
efectivamente en el proceso de diseño para ayudar a cumplir los
objetivos de la ingeniería de confiabilidad. Describa brevemente
el objetivo y la aplicación de cada una de las siguientes (qué
es? ¿cómo puede aplicarse? ¿cuáles son los resultados anticipa-
dos?): qué es modelado de confiabilidad? ¿qué es distribución de
confiabilidad? ¿qué es predicción de confiabilidad? ¿qué es FMECA?
¿qué es SCA? ¿qué es FRACAS?
11. Defina la mantenibilidad. ¿Cuáles son las medidas de mantenibilidad?
176 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

12. Observe los siguientes tiempos de trabajo de mantenimiento


correctivo:

Tiempo de trabajo (mm) Frecuencia Tiempo de trabajo (mm) Frecuencia

41 2 37 4
39 3 25 10
47 2 11 35 5
36 5 31 7
23 13 13 3
27 10 11 2
33 6 15 8
17 1 12 1 29 8
19 12 21 14

Figura 3.113. Datos del problema 12.

a. ¿Cuál es el rango de observaciones?


b. Usando un ancho de intervalo de clases de 4, determine el
número de intervalos de clase. Grafique los datos yconstruya una
curva. ¿Qué tipo de distribución se indica por la curva?
c. ¿Cuáles la ki,?
d. ¿Cuál es la media geométrica de los tiempos de reparación?
e. ¿Cuál es la desviación estándar de los datos del ejemplo?
f. ¿Cuál es el valor de M? ¿(asume 90%)?
13. Describa el objetivo y aplicación de cada una de las siguientes (qué
es? ¿cómo puede aplicarse?cuáles son los resultados anticipa-
dos?): el concepto de mantenimiento, la distribución de la manteni-
bilidad, el análisis de la mantenibilidad, predicción de la
mantenibilidad, FMECA (aplicado a la mantenibilidad).
14. Calcule los parámetros siguientes que pueda con la información
dada: determine
A MTBM
Aa MTBF
A0
Mt M7TRg
max
PREGUNTAS Y PROBLEMAS 177

Dado que:
= 0.004
Tiempo de operación total =10,000 horas
Tiempo medio = 50 horas
Número total de acciones de mantenimiento = 50 horas
Tiempo medio de mantenimiento preventivo = 6 horas
Tiempo medio de logístico más administrativo = 30 horas
15. Defina los factores humanos. ¿Cuáles son algunas de las mediciones
de los factores humanos?
16. Identifique (por clasificación) alguna de las características que
deben considerarse en el diseño de factores humanos.
17. Describa el objetivo y la aplicación de cada uno de los siguientes
análisis (qué es?cómo pueden aplicarse?,cuáles son los resulta-
dos anticipados?): análisis funcional, análisis detallado de trabajos,
análisis de error, análisis de seguridad-riesgo, OSD, ETA.
18. ¿Qué está incluido en la definición de requerimientos de
entrenamiento?Cómo se determinan estos requerimientos?
19. Defina logística. Identifique alguna de las actividades logísticas que
se aplican en el ciclo de vida del sistema. ¿Qué se entiende por
"ingeniería logística"? Defina "capacidad de soporte".
20. Describa algunas de las mediciones de soporte logístico (como las
definidas aquí).
21. ¿Qué es el LSA?Cuáles son las actividades que incluye?Cómo se
relaciona el LSAP con el lLSP?Cómo se relacionan estos con el
SEMP?
22. ¿Cómo se relacionan la confiabilidad, la rnantenibilidad, los factores
humanos, la seguridad y los requerimientos de soporte logístico
con el análisis funcional del nivel del sistema en el capítulo 2?
23. Defina "software". Identifique alguna de las mediciones de software.
24. ¿Cómo son los requerimientos iniciales para el software determina-
do?
25. Describa el proceso para el diseño y desarrollo de software (identi-
fique los pasos). ¿Cómo se relaciona este proceso con el proceso de
ingeniería de sistemas descrito en el capítulo 2?
26. ¿Cómo define "confiabilidad de software"? ¿Cómo define "manteni-
bilidad de software"?
178 REQUERIMIENTOS DEL DISEÑO DE SISTEMAS

27. Defina el TQM. ¿Qué se entiende por "ingeniería de calidad"? ¿Qué


se entiende por "SPC"? Cómo se relaciona la calidad con el proceso
de ingeniería de sistemas?Cuáles son algunos "obstáculos" para la
implementación exitosa del TQM?
28. ¿Qué se entiende por "ingeniería concurrente"?Cómo se relacio-
nan con la ingeniería de sistemas?
29. ¿Qué se entiende por "valor"? Defina "ingeniería de valor".
30. Defina "costo del ciclo de vida". ¿Cómo se relaciona el LCC con la
valuación? ¿Cómo se consideran los factores económicos en el
proceso del diseño del sistema?
31. ¿Qué se entiende por "CBS"?Qué incluye? Defina "perfil de costo",
"análisis de sensibilidad" y "análisis de riesgo".
32. Seleccione un sistema y realice un análisis de costo del ciclo de vida
de acuerdo con los pasos identificados en la figura 3.32 y el proceso
descrito en el apéndice "A".
33. Describa con sus propias palabras los intereses en común
(o similitudes) que existen entre las disciplinas de diseño cubiertas
en este capítulo.
2
MÉTODOS Y HERRAMIENTAS
DE LA INGENIERÍA DE DISEÑO

Dentro del proceso de ingeniería de sistemas, descrito en el capitulo 2, hay


una serie de actividades de diseño realizada con el objetivo de proporcionar
un sistema que satisfaga una necesidad precisa del consumidor. El éxito de
estas actividades, amplificado en cierto grado a través de los requerimien-
tos específicos cubiertos en el capítulo 3, depende de la aplicación adecuada
de los métodos y prácticas de diseño seleccionados. Esto, a su vez, es
influido en gran medida por la tecnología y las herramientas disponibles y
usado por el ingeniero de diseño responsable.
Durante años, el proceso básico de diseño ha involucrado una serie de
actividades, realizadas en forma individual mediante el uso de manuales de
procedimientos paso por paso. Las ideas fueron generadas y concep-
tualmente orientadas a la distribución o disposición de los dibujos que
fueron preparados y aprobados; los componentes del sistema fueron eva-
luados y seleccionados de la documentación de los estándares del diseño;
los detalles de los dibujos y las listas de partes fueron desarrolladas y
revisadas; las simulaciones y los modelos fueron construidos, etc. En esencia,
el proceso de diseño involucra una extensa serie de actividades, que a
menudo requiere una gran cantidad de tiempo y, generalmente, no está muy
bien coordinada.
Con el advenimiento de la tecnología computacional, el proceso de
diseño está experimentando un cambio importante. A través de la intro-
ducción de las gráficas computacionales, a finales de los años cincuentas y
principios de los sesentas; de los dispositivos de entrada para el usuario, en
los últimos años de la decada sesentas y los primeros de los setentas
(teclados, lápiz óptico, joysticks), y del desarrollo actual de las sofisticadas
estaciones de trabajo de diseño, el diseño de sistema-producto incluye la
aplicación de muchas innovaciones. La tecnología computacional está
disponible para facilitar la generación de gráficas, la realización de análisis
y la ejecución de actividades de manejo de datos. Es en este contexto
180 MÉTODOS Y HERRAMIENTAS DE L& INGENIERÍA DE DISEÑO

(o ambiente) donde el tema de la ingeniería de sistemas necesita ser tratado.


El propósito de este capítulo es destacar brevemente algunos de estos
conceptos relativamente recientes del diseño (por ejemplo, la aplicación de
métodos de diseño asistidos por computadora) y discutir los objetivos de la
ingeniería de sistemas y la forma en que se relacionan con los métodos
actuales del diseño.

4.1 PRÁCTICAS CONVENCIONALES DE DISEÑO

Para los muchos proyectos que se ocupan de los sistemas en pequeña y gran
escala, los pasos más importantes en el diseño del sistema incluyen el
diseño conceptual, el diseño preliminar y el diseño de detalle, ilustrados en
el flujo de proceso presentado en la figura 1.7. Este flujo de proceso está
confeccionado, evidentemente, para el requerimiento específico. Aunque
los pasos básicos se aplican en el desarrollo de todos los sistemas nuevos,
el nivel del esfuerzo y la longitud de tiempo requerido variará entre una
situación y la siguiente.
Hay muy diferentes actividades inherentes a los pasos fundamentales
identificados en la figura 1.7, lo cual está orientado al objetivo esencial de
diseñar un sistema que cumpla una necesidad del consumidor. Para proyec-
tos relativamente grandes, tales como el sistema de una aerolínea comercial
y el sistema masivo de tránsito referido en la sección 3.2, puede haber un
requerimiento de experticia técnica representando las muy diversas disci-
plinas, por ejemplo, los ingenieros eléctricos, los ingenieros mecánicos, los
ingenieros de estructuras, los ingenieros en materiales, los ingenieros
aeroespaciales, los ingenieros civiles y los ingenieros en confiabilidad.
En apoyo a los ingenieros de diseño responsables en los diversos campos,
existe la necesidad de dibujantes, ilustradores técnicos, especialistas de
componentes de partes, técnicos laboratoristas, programadores de compu-
tación, técnicos de pruebas, especialistas de adquisición y contratos,
expertos legales, etc. Hay una gran variedad de niveles de especialización
requeridos para la mayoría de los proyectos, y cada una de estas especiali-
dades asignada contribuye al diseño.
Para revisar más profundamente los pasos del diseño, la figura 4.1 se
presenta como una amplificación de la figura 1.7. Conforme avanza el diseño,
la definición real se lleva a cabo a través de la documentación en forma de
planos y especificaciones (ya discutidas), procedimientos, dibujos, mate-
riales y listas de partes, reportes y análisis de programas de computadora,
entre otros. La configuración del diseño puede ser, a los ojos del diseña-
dor, la mejor posible; no obstante, los resultados serán prácticamente inú-
tiles, a menos que estén documentados adecuadamente, de tal manera que
los demás puedan entender, desde el principio, de qué tratan y, luego,
que sea posible traducir el resultado a una entidad capaz de ser producida.
Diseño conceptual

Estudio de factibilidad, requerimientos del sistema, análisis funcional,


especificación del sistema

Definición y documentación del diseño de la configuración del sistema

Revisión y aprobación de la
documentación del diseño

Diseño preliminar

Análisis funcional, asignación, estudios de compromisos y opmización

Definición y documentación del diseño de los subsistemas,


unidades y ensambles más importantes j

Revisión y aprobación de la >No 2


documentación del diseño Cr

'Si
Diseño de detalle y desarrollo

Estudios de compromisos, síntesis, optimización, selección


de los componentes, desarrollo de simulaciones y modelos prototipo,
orueba y evaluación

Definición detallada del diseño y el conjunto completo


de la documentación del diseño

Revisión y aprobación de No
documentación del diseño

E1l

Liberación de la documentación del diseño para la


producción y(o) construcción

Figura 4.1. Secuencia básica del diseño.

181
182 MÉTODOS Y HERRAMIENTAS DE LA INGENIERÍA DE DISEÑO

Cuando se trata el aspecto de la documentación, subrayado en la figura


4.1 para definirlos diversos niveles de desarrollo de sistemas, los resultados
del diseño son generalmente transmitidos a través de una combinación de
lo siguientes:

1. Dibujos de diseño: los dibujos de ensamble, los dibujos de especifi-


caciones de control, los dibujos de construcción, los dibujos de
instalación, los diagramas lógicos, los diagramas de tuberías, los
diagramas esquematizados, los diagramas de interconexión,
los diagramas de alambrado y cableado de arneses.
2. Listas de partes y materiales. las listas de partes, las listas de
materiales, listas de artículos grandes y (o) de gran volumen, listas
de aprovisionameinto.
3. Reportes de análisis: reportes de estudios de compromisos que
sustentan las decisiones de diseño, reportes de análisis de elemen-
tos finitos, análisis y predicciones de confiabilidad y mantenibilidad,
reportes de seguridad, registros de análisis de soporte logístico, así
como reportes de la identificación de la configuración y documen-
tación del software.

Al referirse a la figura 4.1 y a los pasos de la definición del diseño,


las ideas se generan yse convierten en dibujos, los dibujos se revisan por las
diversas disciplinas interesadas y (u) organizaciones, que recomiendan que
los cambios se inicien e incorporen como es debido y los dibujos aprobados
(firmados de visto bueno) son liberados para la producción. Para la mayor
parte, los pasos de este proceso informal cotidiano se concluyen en serie y a
menudo requieren una gran cantidad de tiempo. Por ejemplo, un ingeniero
eléctrico puede empezar el proceso con una distribución propuesta de los
componentes en un tablero de circuitos; un ingeniero mecánico puede,
entonces, proveer las estructuras necesarias y los requerimientos de enfria-
miento, un ingeniero de confiabilidad puede continuar con una revisión
y evaluación de los componentes seleccionados, etc. Estos individuos
responsables pueden estar localizados en diferentes edificios, y el proceso
de la documentación y los tiempos de comunicación a menudo se vuelven
bastante grandes. Posteriormente, este procedimiento adquiere un grado
adicional de complejidad conforme el número de dibujos y los cambios de
dibujo se incrementan.
En esencia, esta actividad de diseño diaria, particularmente para los
sistemas de gran escala, puede incluir la generación y el procesamiento de

'En el sector de defensa, MIL-STD-1OOA, Military Standard, "Engineering Drawing Practices",


Departamento de Defensa, Washington, D.C., ha sido planeado un documento para la Ingeniería
de diseño. Hay más de 15 diversas categorías de dibujos colocados en este estándar.
NUEVAS TECNOLOGÍAS Y HERRAMIENTAS DE DISEÑO 183

miles de dibujos e indicaciones de cambios de dibujo (DCNs). Las muy


diversas disciplinas de diseño pueden ser representadas con el personal
de ingeniería localizado en la organización del productor y, en algunos
casos, en las localidades del proveedor. La comunicación, en términos de
discusiones verbales relativas a los enfoques de diseño y al manejo de la
documentación del diseño, es marginal, y los tiempos transcurridos son,
frecuentemente, grandes. En algunos casos, puede necesitarse un mes, o
más, para manejar un solo dibujo a través de los pasos de revisión para su
aprobación.
¡Estas prácticas, un tanto convencionales en el pasado, han creado
algunos retos importantes! En numerosos casos, se han pasado por alto los
procedimientos, se han implementado los cambios sin las aprobaciones
adecuadas y sin la coordinación necesaria, y los controles apropiados para
la configuración no se han practicado. En esencia, no se han seguido los
objetivos básicos de la ingeniería de sistemas.

4.2 NUEVAS TECNOLOGÍAS Y HERRAMIENTAS DE DISEÑO


Con el advenimiento de la tecnología computacional a lo largo de los últimos
tres decenios, se han desarrollado y adaptado muchas nuevas herramientas
y técnicas. No sólo las capacidades de las computadoras mainframe se han
incrementado significativamente, sino la disponibilidad de computadoras
personales (PCs) ha cambiado literalmente nuestra manera de hacer nego-
cios, particularmente en relación con la ingeniería de diseño. Además, el
desarrollo de paquetes de software y de modelos computacionales asocia-
dos se ha incrementado expon encialmente y los resultados han proporcio-
nado a la ingeniería de diseño (y a la administración) una gran variedad de
herramientas diseñadas para mejorar su productividad. Tales herramientas
incluyen los procesadores de palabras, los paquetes de graficación, las
hojas de cálculo, los paquetes de manejadores de base de datos y programa
de análisis.
Dadas las ayudas computacionales apropiadas para el diseño, al inge-
niero le es posible realizar un análisis de desempeño empleando los méto-
dos de simulación (estática contra dinámica, determinística contra
estocástica, continua contra discreta), en un marco de tiempo relativamen-
te breve. Los métodos matemáticos de programación (programación lineal,
programación cuadrática, programación dinámica), pueden ser usados
para la resolución de los problemas de la distribución de los recursos y de
los problemas de asignación. Herramientas estadísticas están disponibles
para la graficación de distribuidores y para determinar las características
relacionadas (por ejemplo, media, desviación estándar, rango y el valor
máximo). Las ayudas para la administración del proyecto se emplean para
graficar las redes planeadas (por ejemplo, PERT-CPM) y las proyecciones de
costos. Los modelos de administración de base de datos son empleados
extensamente para la adquisiÓn y almacenamiento de datos, el procesa-
184 MÉTODOS Y HERRAMIENTAS DE LA INGENIERÍA DE DISEÑO

miento de información yla generación de reportes. Finalmente, hay una gran


variedad de herramientas especializadas de ingeniería que pueden ser
utilizadas por el diseñador para ayudarle a resolver problemas específicos
(por ejemplo, el diseño de un filtro digital, la distribución de los componen-
tes en un tablero de circuitos y la realización de un análisis de confiabilidad
para el sistema "XYZ"). 2
En relación con la aplicación al proceso de diseño y desarrollo, la
disponibilidad de estas herramientas ofrece una variedad de diversas
ventajas:

1. La combinación de computadoras personales (PCs) incluidas como


parte de las estaciones de trabajo individuales de diseño, localizadas por
el área completa de diseño del proyecto, con las conexiones a una estación
de trabajo central y a una computadora mainframe, ha creado una excelente
red de comunicación de datos. No sólo es posible trasmitir muy diversas
categorías de datos, en formatos variables, a todas las estaciones de trabajo
posibles en forma concurrente, sino que esto puede, también, ser desarro-
llado rápida y eficientemente. Los paquetes de datos de diseño pueden ser
realizados por diseñadores individuales, trasmitidos a muchos otros simul-
táneamente y revisados con los cambios recomendados que se presenten al
diseñador, en un lapso muy breve. Esta capacidad minimiza los requeri-
mientos de conclusión de trabajos en serie, como los descritos en la sec-
ción 4.1, y permite una reducción en el tiempo global de desarrollo del
sistema. La figura 4.2 ilustra este concepto.
2. La versatilidad y variedad de los paquetes-modelos de software
proporcionan al diseñador muchas herramientas nuevas, no disponibles en
el pasado. Por ejemplo, en el diseño de sistemas, el uso de los métodos de
simulación al inicio de su fase conceptual, hace posible que el diseñador
haga un mejor trabajo al determinar los requerimientos operacionales
y realizar un análisis de desempeño. Los modelos computacionales tridi-
mensionales pueden desarrollarse a fin de evaluar una variedad de configu-
raciones posibles del sistema, para estudiar las interrelaciones entre los
componentes del sistema, para investigar asignaciones del espacio, para
estudiar el desempeño de las secuencias de trabajo humano, etc. El uso de
los modelos matemáticos-estadísticos permite al diseñador investigar mu-
chas más diversas alternativas (en comparación con las que eran posibles
en el pasado), involucrando numerosos cálculos y el procesamiento de una

Una fuente excelente para obtener una perspectiva global del estado del arte y los métodos
computarizados es Elsner, H. Computer-Aided Systems Engineerirzg (CASE), Prentice-Hall,
Englewood Cliffs, N.J., 1988.
Uno de los objetivos del Departamento de Defensa, a través de la Ingeniería concurrente, es
reducir el tamaño del proceso de creación del sistema para aplicar adecuadamente nuevas
tecnologías en el proceso de diseño ydesarrollo. Véase el capítulo 1, en la sección 1.4, y capítulo
3, sección 3.2.7.
Construcción C

Confiabilidad
1
Componentes 1 Capacidad de mantenimiento
/
tanos_+_.J
T /
u
¡ / / Capaci=
soporte
I /
1 / /
¡ / /
-------
Construoción B
/ 1 Archivos de base 1
de datos 1
11 u /
Sistemas Ece
n cn o la
unidad principal
o
Computadora Personal (es'taciónceh- Computadora mainframe1
tral de trabajo)
L upe - -

II

Construcción E

Proceso
Eléctrica

I Mecánica /
1 onstrucciónb
Material / Químico
Estructural

L -
Figura 4.2. Un proyecto del diseño de una red de comunicación (ejemplo).

185
186 MÉTODOS Y HERRAMIENTAS DE LA INGENIERÍA DE DISEÑO

gran cantidad de datos en un breve período. En esencia, el ingeniero de


diseño actual tiene muchas más herramientas disponibles para él y la
capacidad de estas herramientas le permite un análisis más profundo, así
como la investigación de las alternativas de diseño. Esta capacidad, aplicada
al inicio del ciclo de vida del sistema, ayuda a reducir los riesgos asociados
con la toma de decisiones del diseño, eliminando las opciones no factibles
desde el inicio.
3. Las capacidades del manejo de datos, proporcionadas a través de la
tecnología computacional, permiten la adquisición, el procesamiento, el
almacenamiento y la recuperación de una mayor variedad y cantidad
de datos que en el pasado. El almacenamiento de los datos y los métodos de
recuperación son más simples y los tiempos de procesamiento de datos son
menores. No sólo es fácil capturar cierta información del diseño o dibujos,
sino también la generación de listas de partes-materiales puede ser mane-
jada de manera expedita. Más adelante, los reportes y las publicaciones
técnicas pueden producirse automáticamente mediante el empleo de una
combinación de métodos gráficos y de procesadores de palabras.
En relación con el capítulo 1 y la definición de los objetivos de la
ingeniería de sistemas, el advenimiento de la tecnología computacional
(junto con las diversas herramientas que también están disponibles) puede
tener un efecto muy benéfico. Específicamente:
1. Un análisis más completo y producto de los requerimientos del
sistema puede ser realizado durante una etapa inicial del diseño donde los
impactos del ciclo de vida son los mayores. Esto, asu vez, tiende a fomentar
un mayor énfasis en un enfoque de arriba-abajo del ciclo de vida en el
desarrollo del sistema.
2. Un proceso de comunicaciones mejorado puede evolucionar como
resultado de: a) que sea posible difundir los datos rápida y efectivamente;
b) que sea posible trasmitir la información a los múltiples individuos y (u)
organizaciones en forma concurrente y c) que sea posible incorporar
cambios al diseño rápidamente. Este mejoramiento de la comunicación
ayuda a proporcionar la integración necesaria de las muy diferentes áreas
disciplinarias involucradas en el proceso del diseño.

Por otra parte, ¡adaptar la nueva tecnología computacional no será


posible sin algunos problemas y retos! Primero, el desarrollo e imple-
mentación de un enfoque estandarizado para convertir la información del
diseño a un formato digital es requerido. Todos los diseñadores y personal
de soporte, organizaciones del productor y del consumidor, y los proveedo-
res deben utilizar el mismo lenguaje y formatos de datos, siguiendo prácti-
cas idénticas, etcétera.

4 E1 Departamento de Defensa ha reconocido este requerimiento e Intenta proporcionar alguna

estandarización a través de la aplicación de MIL-D-28000, Military Specificatlon, "Digital


NUEVAS TECNOLOGÍAS Y HERRAMIENTAS DE DISEÑO 187

Segundo, los métodos para conectar las computadoras personales


(PCs) de la compañía a través de una red de área local (LAN), entre
compañías a través de una red de área amplia (WAN) y (o) el enlace de las
PCs a computadoras mainframe, son críticos para el proceso de comunica-
ción. La figura 4.2 ilustra una topología tipo estrella, que es un enfoque con
el objetivo de permitir la trasmisión de la información del diseño a las
múltiples estaciones de trabajo en forma concurrente. Otro enfoque utiliza-
do con frecuencia es una configuración circular (esto es, una topología tipo
anillo), donde los datos deben pasar en secuencia a través de varias
estaciones de trabajo, antes de llegar a la computadora central. Esta
configuración generalmente no permite la trasmisión simultánea a todos los
diseñadores interesados y el proceso asume series de acciones moviéndose
desde una estación de trabajo remota a otra.
En cualquier caso, el diseño de los protocolos y las diversas redes (por
ejemplo, LANs WANs), debe ser tal que proporcione una comunicación rá-
pida y efectiva sobre la información del diseño del sistema-producto. Más
adelante, ¡el hardware y los paquetes de software que son utilizados deben
ser completamente compatibles! A las diversas estaciones de trabajo les de-
be ser posible "conversar con las demás", y deben ser posibles los niveles
adecuados de comunicación dentro de la red y entre redes. En otras pala-
bras, los métodos y los procedimientos deben establecerse para permitir
una trasmisión rápida y eficiente de los datos del diseño entre los diversos
proveedores y el productor (el contratista) y entre el productor y el
consumidor (el cliente).
En relación con los objetivos de la ingeniería de sistemas destacados en
el capítulo 1, estos deben ser vistos en el contexto del ambiente global del
diseño. Los objetivos deben relacionarse con la aplicación de un enfoque
total del ciclo de vida, de arriba-abajo, integrado en el desarrollo de un
sistema que cumplirá las necesidades de un consumidor: efectiva y efi-
cientemente. La satisfacción exitosa de estos objetivos depende, evidente-
mente, de las actividades realizadas durante el proceso de desarrollo del
sistema. Esto, a su vez, está altamente influido por la capacidad de diseño
y el ambiente que existe en la organización del productor-proveedor. Si las
herramientas adecuadas están disponibles y son utilizadas apropiadamen-

Representation for Communlcation of Product Data: lOES Application Subsets", Departamento


de Defensa, Washington, D.C. Este estándar incluye la definición de una serie de subconjuntos
de aplicaciones específicas del Initial Graphics Exchange Specification (lOES), el nombre
popular de American National Standard ANSI Y14.26M, "Digital Representation br
Cornmunication of Product Definition Data".

El desarrollo de la "Initial Graphics Exchange Specification" (lOES) fue iniciado para permitir
la transferencia entre las redes de datos de diseño, los sistemas CAD/CAM, etc. La capacidad
se complementa por el "Product Data Exchange Specification" (PDES), el cual regirá el
establecimiento completo de los elementos de los datos que definen un sistema-producto para
todas las aplicaciones en su ciclo de vida esperado.
188 MÉTODOS Y HERRAMIENTAS DE LA INGENIERÍA DE DISEÑO

te, la realización de los objetivos de la ingeniería de sistemas puede ser


relativamente fácil. Por otra parte, si el ambiente no conduce a la realización
de un BUEN diseño, entonces se requerirán esfuerzos adicionales para
asegurar que los objetivos deseados de la ingeniería de sistemas se cum-
plan.
Así, los requerimientos para la ingeniería de sistemas variarán no sólo
en función de la naturaleza y complejidad del sistema que se desarrolla, sino
también debe incluir la consideración de la capacidad designada para
sustentar el proceso de diseño. El grado en que la tecnología computacional
está siendo utilizada puede tener un efecto significativo en el proceso de la
ingeniería de sistemas.

4.3 DISEÑO ASISTIDO POR COMPUTADORA (CAD)

El diseño asistido por computadora (CAD), definido en el más amplio


sentido, se refiere a la aplicación de la tecnología computacional al proceso
de diseño.' Con la disponibilidad de las herramientas computacionales que
pueden ser utilizadas adecuadamente en el desempeño de ciertas funciones
de diseño, el diseñador puede realizar más, a un paso más rápido y más al
principio del ciclo de vida. Estas herramientas, para incluir software de
soporte, incorporan capacidades gráficas (gráficas vectoriales y raster,
gráfica de barras, graficación x-y, diagramas de dispersión, exhibiciones en
tercera dimensión) capacidades analíticas (programas matemáticos y esta-
dísticos para análisis y evaluación) y capacidades de administración de
datos (almacenamiento de datos y recuperación, procesamiento de datos,
borrado y reportes). Estas capacidades generalmente están combinadas en
los paquetes integrados de aplicación para la solución de un problema
específico de diseño. Unos cuantos ejemplos de las aplicaciones de diseño
se indican abajo:

1. La utilización de gráficas, combinada con procesador de palabras


y las capacidades de los manejadores de bases de datos, permite al diseñador:
a. Distribuir los componentes en el tablero de circuitos eléctricos-
electrónicos, diseñar las pistas de la circuitería lógica, incorporar
provisiones de diagnóstico en microcircuitos electrónicos, etc.
Las capacidades del CAD se están empleando ampliamente en el diseño
de módulos electrónicos LSI-VLSI y paquetes estándares.

'Dos buenas referencias que cubren algunos de los aspectos generales del CAD-CA?vI son
Teichoiz, E. (ed.), C4D/G4MHandbook. McGraw-Hill, New York, 1985;y Krouse, J. K. WhatEvery
EngineerShouldKnowAbout Compufer-AidedDesign and Computer-AidedManufacturing Marcel
Dekker, New York, 1982.
términos con frecuencia utilizados para definir esta área de actividad son Ingeniería
asistida por computadora (CAE) y Sistemas de ingeniería asistidos por computadora (CASE).
DISEÑO ASISTIDO POR COMPUTADORA (CAD) 189

b. Distribuir los componentes individuales de acuerdo con el tama-


ño, posicionamiento y propósitos de asignación de espacio, a través del
uso de exhibiciones tridimensionales.
c. Desarrollar modelos de sólidos habilitando los ensambles, super-
ficies, intersecciones, interferencias, etc, para que sean claramente
delineados por medio de la generación automática de vistas isométricas
y dibujos detallados dimensionales y de dibujos de ensamble. Las áreas
de superficies de los componentes, volúmenes, pesos, momento de
inercia, centros de gravedad y otros parámetros pueden determinarse
automáticamente. Las capacidades del CAD se están empleando amplia-
mente en el desarrollo de modelos de sólidos para sistemas grandes, por
ejemplo, aeroplanos, barcos, submarinos, vehículos terrestres, facilida-
des, puentes, presas y carreteras. Muchos de estos modelos permiten
al diseñador ver el sistema como una entidad que proporciona un
desglose jerárquico de arriba-abajo de los componentes del sistema
en los diversos niveles. Los despliegues en dos y tres dimensiones
pueden presentarse mediante el uso de gráficas a color, como un
mejoramiento.
d. Desarrollar los modelos tridimensionales de las localidades, de
las consolas del operador, de los espacios de trabajo de mantenimiento
y similares, para propósitos de evaluación de las relaciones de la
interfaz de relaciones entre el humano y los demás elementos del
sistema. Las herramientas CAD se emplean para simular tanto los
secuención de trabajo del operador como los de mantenimiento.
2. La utilización de los métodos analíticos, combinada con el procesador
de palabras, la hoja de cálculo electrónica y las capacidades del maneja-
dor de base de datos, permite al diseñador:
a. Realizar los requerimientos del sistema y el análisis de desempe-
ño como apoyo para los estudios de compromisos del diseño, por
ejemplo, análisis de elemento finito, análisis estructural, análisis de
tensión-esfuerzo, análisis térmico, análisis de pesos-cargas yel análisis
de materiales.
b. Realizar los análisis de confiabilidad como apoyo del diseño, por
ejemplo, asignaciones, predicciones, FMECA, análisis de circuitos ocul-
tos, análisis críticos de la vida útil, análisis de tensión ambiental.
c. Realizar los análisis de la capacidad de mantenimiento en apoyo
al diseño, por ejemplo, asignaciones, predicciones, FMECA, análisis
de diagnóstico y prueba de los requerimientos así como análisis de
trabajos de mantenimiento.
d. Realizar los análisis de factores humanos, por ejemplo, el análisis
funcional, análisis de trabajos de operador, OSDs, análisis de requeri-
mientos de entrenamiento.
e. Realizar los análisis de seguridad, por ejemplo, análisis de riesgo,
análisis de árbol de fallas.
190 MÉTODOS Y HERRAMIENTAS DE LA INGENIERÍA DE DISEÑO

C EIdiseñoisdo por la mputadmAD)

neríaaaPorco ora

I lManufactura asistida por


computadora

Figura 4.3. Aplicación de CAD/CAM/CALS.

f. Realizar los análisis de soporte logístico, por ejemplo, el análisis


de los requerimientos de mantenimiento, análisis del nivel de repara-
ción, análisis de los requerimientos de repuestos, análisis de los
requerimientos de transportación, análisis de los requerimientos del
equipo de prueba, análisis de los requerimientos de las instalaciones.
g. Realizar los análisis de valor-costo, por ejemplo, análisis de
ingeniería de valor, análisis de costos del ciclo de vida.
3. La utilización del manejador de base de datos, combinado con las
gráficas, hojas electrónicas de cálculo ylas capacidades del procesador de
palabras, facilita al diseñador:
a. Desarrollar diagramas de flujo funcionales, diagramas de flujo de
información-datos, diagramas de dependencia, diagramas de bloque
de confiabilidad, diagramas de acción, árboles y tablas de decisión.
b. Desarrollar y mantener una base de datos que incluya los datos
históricos del diseño, las listas de partes, las listas de materiales,
información del proveedor, reportes técnicos. El propósito es ser capaz
de almacenar los datos estándares en formatos comunes y la recupera-
ción de dicha información, de manera rápida y confiable, para futuras
aplicaciones.
c. Desarrollar un sistema de información para administración (MIS)
DISEÑO ASISTIDO POR COMPUTADORA (CAD) 191

que permita la realización de la revisión del proyecto y las funciones de


control, por ejemplo, la comunicación de los datos, las proyecciones
de carga del personal de carga, las proyecciones del costo, el TPM "se-
guimiento", los reportes PERT/CPM, así como el reporte de los requeri-
mientos del proyecto.

A través de un análisis de estas áreas de aplicación se puede ver que la


utilización de la tecnología computacional es amplia y se incrementa a una
gran velocidad. Por otra parte, si bien hay muchos usos de la tecnología de
diseño asistida por computadora, estos aún no están bien integrados.
Al referirse al ciclo de vida global, ilustrado en la figura 4.3, las herra-
mientas de CAD están siendo aplicadas durante el proceso de diseño
y desarrollo, cuyos resultados se alimentan directamente a la manufactura
asistida por computadora (CAM) y las capacidades de creación y soporte
logístico asistido por computadora (CALS). 8 La aplicación de las herramien-
tas CAD ha evolucionado desde los sesentas y los setentas, esencialmente
siguiendo un enfoque de lo particular de abajo-arriba.
A diferencia del concepto de red integrada, ilustrado en la figura 4.2, las
estaciones de trabajo de diseño individual han sido desarrolladas en forma
un tanto independiente. Una estación de trabajo constituye un grupo
o arreglo de equipo (por ejemplo, terminal gráfica, computadora, teclado),
combinado y distribuido de tal manera que ayude al diseñador a concluir los
trabajos seleccionados. Las capacidades de una estación de trabajo de
diseño variarán dependiendo de: 1) las funciones específicas de diseño que
se desempeñan; 2) la naturaleza ycomplejidad del sistema que se desarrolla
(y sus componentes); 3) la educación yvisión del diseñador responsable, en
términos de su interés y la disponibilidad de adaptarse en relación con la
utilización de las nuevas tecnologías computacionales; 4) el grado de so-
porte de administración relativo a la modernización de la capacidad de
diseño y (o); 5) la disponibilidad de los recursos presupuestales necesarios
para adquirir y soportar los artículos capitales del equipo que son incorpo-
rados como parte de la estación del trabajo de diseño. En muchos casos,
adaptar las tecnologías computacionales al diseño requiere un cambio de
"estructura" o una reorientación, en relación con los métodos usados en la
realización de los trabajos. Adicionalmente, mientras la experiencia ha
indicado que el uso de los métodos CAD es muy efectivo en cuanto a costos
a largo plazo, el costo inicial de la adquisición de los bienes capitales re-
queridos puede ser percibido como muy alto. En cualquier caso, estos
obstáculos aparentes deben ser evitados si se desea avanzar en esta área.
Las capacidades de las estaciones de trabajo de diseño han evoluciona-
do desde una configuración donde le era posible al usuario diseñar una

8 Los CAM y CALS son estudiados más adelante, en las secciones 4.4 y 4.5, respectivamente.
192 MÉTODOS Y HERRAMIENTAS DE LA INGENIERÍA DE DISEÑO

parte específica de un componente, o desempeñar un análisis detallado de


alguna función un tanto aislada del sistema, para una configuración comple-
ta que integre muy diversas tecnologías discutidas antes. Inicialmente, una
terminal gráfica fue usada para diseñar una parte, analizar las tensiones,
estudiar y evaluar de una acción mecánica, etc. Ahora, una estación de
trabajo de diseño puede ser utilizada para realizar efectivamente muchas
de las funciones anotadas anteriormente, por ejemplo, la distribución de los
componentes en los tableros de circuitos, el desarrollo de los modelos de
sólidos tridimensionales y la utilización de métodos analíticos sofisticados.
En relación con el futuro, podrá realizarse mucho más en términos de
integración del diseño; ¡la incorporación de nuevos diseños así como el
potencial de crecimiento adicional son grandes!
En relación con el futuro, ¡el concepto de flujo integrado total, ilustrado
en la figura 4.4, ¡refleja una meta a largo 9 En el principio, una estación

de trabajo de diseño puede ser desarrollada y construida, junto con el


software apropiado, para reflejar las capacidades inferidas a través del
enfoque integrado presentado en la figura 4.2. Además de los requerimien-
tos para el diseño eléctrico, el diseño mecánico y el diseño estructural, la
confiabilidad, la mantenibilidad, los factores humanos, la capacidad de
soporte y los requerimientos comparables deben integrarse en el proceso
de diseño. En otras palabras, todos los requerimientos del diseño especifi-
cados en la figura 3.4 (capítulo 3, sección 3.2) deben integrarse adecuada-
mente; la red de comunicación del diseño ilustrada en la figura 4.2 debe estar
disponible y utilizarse, y cada una de las estaciones de trabajo de diseño
asignadas a un proyecto dado deben tener la capacidad de tratar con estos
requerimientos globales.
Además, para proporcionar una capacidad que fomentará un enfoque
completamente integrado del diseño, debe hacerse una revisión para permi-
tir la transición suave de información desde el proceso de diseño hasta el
proceso de manufactura y a la estructura de soporte logístico. Tal vez, en un
futuro no muy distante, al ingeniero de diseño (con la asistencia de su equipo
de expertos orientado a las disciplinas) le será posible proporcionar la
entrada del diseño adecuado en la estación de trabajo que, a su vez,
automáticamente, constituirá el flujo de los procesos CAM y CALS, a través
de la aplicación de métodos de comunicación de datos efectivos. Esta
provisión, evidentemente, requerirá completa compatibilidad (lenguaje,
formato de datos, etc.), entre CAD, CAM y CALS, en los niveles del productor
(contratante) y del proveedor.
En relación con el estado actual de las herramientas CAD y sus aplica-
ciones, muchas firmas industriales han desarrollado e instalado las capaci-

En el desarrollo de una configuración ideal, las capacidades deben, evidentemente, estar


diseñadas para las necesidades específicas de la organización del diseño.
'U-'

193
194 MÉTODOS Y HERRAMIENTAS DE LA INGENIERÍA DE DISEÑO

dades CAD, integradas en las estaciones de trabajos de diseño, software de


soporte y similares. Estas capacidades varían significativamente de una
instalación a la siguiente. No obstante, en la mayoría de los casos (en
particular para los sistemas en gran escala), el uso de la tecnología de
gráficas, métodos analíticos y capacidades del manejador de base de datos
ha sido empleado efectivamente para realizar algunas de las actividades de
diseño tradicionales, por ejemplo, el diseño de circuitos eléctricos, el diseño
de empaque mecánico, el diseño estructural. Por otra parte, muy poco se ha
realizado en relación con la integración de confiabilidad, mantenibilidad,
factores humanos y capacidad de soporte en este proceso, esto es, las
disciplinas del diseño vistas en el capítulo 3.
Aunque la tecnología computacional ha sido aplicada con éxito en el
desarrollo de los modelos de confiabilidad, los de mantenibilidad yen los de
soporte logístico, etc., estas herramientas han sido utilizadas en forma
aislada. En general, las actividades de diseño, asociadas con estas discipli-
nas, se han realizado independientemente, no integradas de manera adecua-
da en el proceso básico de la ingeniería de diseño, y las herramientas que
han sido desarrolladas en estas áreas no se han integrado a otras ni a es-
taciones de trabajo de diseño tradicionales. '°
En respuesta a la necesidad de ser más efectivo, desde el punto de
vista de la colaboración oportuna en el proceso de diseño, ha habido
recientemente una gran cantidad de esfuerzos dedicados a desarrollar
modelos de confiabilidad, de mantenibilidad y de capacidad de soporte.
Si se estudia la literatura de esta área, podría identificarse una lista de 200
modelos de tipos variantes (y este número se incrementa con gran rapidez).
Una breve descripción de unos cuantos modelos, los cuales deben ser
utilizados en el sector de las diversas aplicaciones actuales del diseño, se
presenta en seguida con el fin de proporcionar alguna idea acerca del tipo
de herramientas que están disponibles:

1. Programa de predicción de confiabilidad (RPP). El RPP consiste en


una serie de rutinas de software computacional diseñado para ayudar
en la realización de las predicciones de confiabilidad basadas en los factores
de esfuerzo de las partes de los componentes. Un sistema puede contener
un número de ensambles, subensambles y partes componentes (limitadas
sólo por el espacio disponible en el disco). La información de la tasa de fa-
llas de los componentes puede ser introducida a través de una serie de me-
nús; los datos de aplicación de la parte y los factores de esfuerzo pueden ser
tratados (temperatura, corriente eléctrica, etc.); y la predicción de MTBF,
o X, valores que pueden ser determinados por el sistema en cuestión.

lO
El término "islas de automatización" es usado frecuentemente cuando se refiere a las
herramientas analíticas que no están integradas y son empleadas en forma independiente.
Hay muchas áreas donde esta condición existe actualmente.
DISEÑO ASISTIDO POR COMPUTADORA (CM)) 195

La implementación de RPP puede realizarse usando una computadora


personal, y está disponible para todas las versiones actuales de MIL-HDBK-
217, "Reliability Prediction of Electronic Equipment", Departamento de
Defensa, Washington, D.C. (Powertronic Systems, Inc., 13700 Chef Menteur
Highway, P. O. Box 29109, Nueva Orleáns, LA 70189.)
2.Disponibilidad PC Un modelo que utiliza el análisis de Markov para
estudiar la influencia de las tasas de fallas, las tasas de reparaciones y el
soporte logístico en la disponibilidad del sistema. El objetivo es proporcio-
nar asistencia en el desarrollo del diseño óptimo de la configuración del
sistema y las políticas de reparación. (Management Sciences, Inc., 6022
Constitution Ave., N.E., Albuquerque, N.M. 87110.)
3.PredictorPC. Un modelo de confiabilidad que aplica automáticamente
el análisis de esfuerzo de partes o los métodos de conteo de partes de MIL-
HDBK-217E para producir la tasa de fallas del equipo estimadas y para
realizar las predicciones de confiabilidad. (Management Sciences, Inc., 6022
Constitution Ave., N.E., Albuquerque, N.M. 87110.)
4. Programa computacional Tiger. Una familia de programas compu-
tacionales que puede ser empleada para evaluar, por simulación Montecarlo,
un equipo o un sistema complejo de gran tamaño, a fin de establecer las
diversas medidas de confiabilidad, prontitud y disponibilidad. Las caracte-
rísticas claves incluyen la clasificación del equipo mediante el grado de no
confiabilidad yno disponibilidad, que evalúa una misión con tipos multifases
y que desempeña el análisis de sensibilidad en un complejo sistema por
degradación o mejora de las características de cada equipo. (M.L. Buckberg,
Room 5W64, Bldg. NC-2, Realibility Engineering, Naval Sea Systems Command,
Departamento de Marina, Washington, D.C., 20362)
S. Programa de predicción de confiabilidad mecánica (MRP). El MRP
puede utilizarse al realizar una predicción de confiabilidad del equipo
mecánico. El programa calcula la confiabilidad de los componentes tales
como sellos estáticos y dinámicos, resortes, solenoides, válvulas de ensam-
ble, filtros, frenos, embragues y actuadores. (Powertronic Systems, Inc.,
13700 Chef Menteur l-Iighway, P.O. Box 29109, Nueva Orleáns, LA, 70189)
6.Programa de predicción de la confiabilidad mecánica (MECHREL). Este
programa se usa en el desempeño de la predicción de la confiabilidad de los
sistemas mecánicos. Las partes componentes(por ejemplo, caja de engra-
nes, válvulas, bombas, filtros de baleros) se definen en términos de esfuer-
zos, tasas de fallas, modelos de fallas, etc., y se combinan para predecir el
sistema MTBF. (Eagle Technology, Inc., 2300 S. Ninth St., Arlington, VA,
22204.)
7. Programa de análisis de efectividad de manten ibilidad (MEAP).
Este modelo se usa para calcular los tiempos de mantenimiento para
componentes electrónicos y electromecánicos y para realizar predic-
ciones de mantenibilidad para los sistemas, de acuerdo con MIL-HDBK-472,
(predicción de mantenibilidad). Valores calculados de MTTR, Mm y MDT
196 MÉTODOS Y HERRAMIENTAS DE LA INCENIERÍÁ DE DISEÑO

con objeto de que puedan determinarse los diversos niveles de un sis-


tema. (Systems Effectiveness Associates, Inc., 20 Vernon St., Norwood, MA,
02062.)
8.Programa de predicción de la mantenibilidad (MPP). El MPP puede
usarse para predecir la mantenibilidad de los sistemas eléctricos, electróni-
cos, electromecánicos y mecánicos. Las predicciones de los factores MTTR
(Mct), Mmax (percentiles 60 a 90), MMH/OH y MMH/M4 asociados con las
actividades de mantenimiento en los niveles organizacional, intermedio y de
depósito-proveedor pueden realizarse. Los factores de tiempo de repara-
ción incluyen la localización, el aislamiento de la falla, el desarmado, el
intercambio, el reensamble, el alineamiento y la verificación. La cantidad de
artículos remplazables, que puede ser una mezcla de ensambles,
subensambles y partes componentes está limitada sólo por el espacio de
almacenamiento en disco. El MPP, aplicable con una computadora personal,
puede utilizarse para realizar una predicción de la mantenibilidad, de
acuerdo con MIL-HDBK-472 (Observación 1, Procedimiento V, Método B),
"Maintainability Prediction", Departamento de Defensa, Washington, D.C.
(Powertronic Systems, Inc., 13700 Cher Menteur Highway, P.O. Box 29109,
Nueva Orleáns, LA, 70189.)
9.Modos de fallas, efectos y análisis de criticalidad (FME). El FME puede
usarse en el análisis y desarrollo de un FMECA para un sistema, y apli-
carse a una jerarquía definida por el usuario incluyendo hasta 25 ni-
veles de ensambles, subensambles, componentes, etc. El FME permite
la determinación de los modos de fallas, porcentaje de contribuciones,
efectos locales y efectos del sistema, frecuencia del sistema, diversidad
de clasificaciones, métodos de detección de fallas y provisiones de
compensación recomendadas para el mantenimiento. La estructura de los
datos se presenta en forma de "árbol" y las operaciones pueden reali-
zarse destacando los elementos individuales del árbol. El FME puede
implementarse usando una computadora personal y los requerimientos
de entrada-salida necesarios para ser integrados con los programas de
predicción de confiabilidad y mantenibilidad (por ejemplo, los resultados
de los modelos RPP Y MPP). Este programa incluye todas las características
necesarias para desarrollar el FMECA de acuerdo con MIL-STD-1629A
(Observación 1), "Procedures for Performing a Failure Mode, Ef fects and
Criticality Analysis", Departamento de Defensa, Washington, D.C.
(Powertronic Systems, Inc., 13700 Chef Menteur Highway, P.O. Box 29109,
Nueva Orleáns, LA, 70189.)
10.Sistema de análisis de costo del equipo del diseñador (EDCAS).
El EDCÁS es una herramienta de diseño que puede usarse en la realización
de un análisis de nivel de reparación (LORA). Éste incluye una capacidad
para la evaluación de las decisiones de reparar contra desechar cuando falla
y puede manejar hasta 3 500 artículos únicos, concurrentemente (esto es,
1500 unidades remplazables por línea, 2 000 unidades remplazables de
DISEÑO ASISTIDO POR COMPUTADORA (CM)) 197

tienda). El análisis de nivel de reparación puede realizarse en dos niveles del


sistema, y los resultados pueden usarse para determinar los requerimientos
de las partes del puerto-de reparación y la realización del análisis del costo
del ciclo de vida (LCCA). EDCAS está disponible a través de una edición
universitaria simplificada, orientada a una computadora personal, y una
edición a escala completa de un modelo de laboratorio y es compatible con
los requerimientos de MIL-STD-139013, "Leve¡ oí Repair", Departamento de
Defensa, Washington, D.C. (Systems Exchange, 5504 Garth Ave., Los Ange-
les, CA, 90056)
11.Modelo de análisis de nivel de reparación óptimo (ORLA). Un nivel del
modelo de análisis de reparación usado para examinar la factibilidad
económica de mantenimiento y las alternativas de soporte. Más de cuatro
alternativas pueden ser evaluadas, con los costos del ciclo de vida
desglosados en 13 áreas logísticas diferentes. (U.S. Army-MICOM, Code
AMSMI-LC-TA-L, Redstone Arsenal, AL, 35898)
12.Nivel de reparación (NA VY). Este modelo se usa en el desempeño de
un nivel de análisis de reparación (LOR) durante el diseño y desarrollo
de sistemas y equipo nuevos. Un objetivo es establecer una política de
mantenimiento de menor costo, e influir en el diseño a fin de minimizar los
costos de soporte logístico. (MIL-STD-139013, Military Standard, "Leve¡ oí
Repair", Departamento de Defensa, Washington, D.C.)
13.Análisis del nivel de reparación de red (NRLA). El modelo NRLA se
emplea en el establecimiento del equipo y los niveles de reparación de los
componentes y para tomar una decisión de reparar contra desechar cuando
falla durante el diseño del nuevo equipo y su aprovisionamiento. (U.S. Air
Force, Air Force Acquisition Logistics Center, AFALC/LSS, Wright-Patterson
AFB, OH 45433)
14.Modelo de mantenimiento ysuministm óptimo (OSAMM). Un nivel de
un modelo de análisis de reparación (LORA) que se usa para determinar la
política económica de mantenimiento óptima para cada elemento que falla,
para identificar los elementos en términos de reparar vs. descartar, para
identificar la distribución de los criterios económicos y para evaluar las
opciones de soporte de equipo/reparación. Pueden evaluarse cuatro nive-
les de soporte ycuatro niveles del equipo. (U.S. ARMY-CECOM, Code AMSEL-
PL-SA, Fort Monmouth, N.J., 07703)
15.Optimización computacional de la reposición y repuestos iniciales
basados en la demanda y la disponibilidad (CORIDA). Un modelo que calcula
los requerimientos iniciales y los requerimientos de los repuestos/partes
de reparación, para los múltiples niveles de mantenimiento, en términos de
costos y distribución. Trata las restricciones organizacionales y presupues-
tadas y se utiliza como apoyo de las actividades de aprovisionamiento.
(Thompson-CSF Systems Canada, 350, Sparks St., Ste. 406, Ottawa, Ontario
KIR 758, Canadá.)
16.Modelo OPUS Un modelo versátil que se usa esencialmente para la
198 MÉTODOS Y HERRAMIENTAS DE LA INGENIERÍA DE DISEÑO

optimización de repuesto/partes de reparación e inventario. Éste considera


los diferentes escenarios operacionales y los perfiles de utilización del
sistema al determinar los patrones de demanda de los repuestos, y ayuda en
la evaluación de los diversos planes de diseño de empaque. Las políticas
alternativas de soporte y las estructuras pueden evaluarse con base en la
efectividad de costos (Systecon AB, Kungsgatan 8, 5-11143 Stockholm,
Sweden).
17.VMETRIC. Este es un modelo de repuestos que puede emplearse para
optimizar la disponibilidad del sistema mediante la determinación de las
disponibilidades individuales adecuadas de los componentes del sistema y
los requerimientos de inventario para tres niveles del de tienda y sub-
ensambles), en todos los renglones del mantenimiento. Las salidas incluyen
niveles óptimos de reserva en cada escalón de mantenimiento, las cantida-
des EOQ y los intervalos óptimos de reorganización. (Systems Exchange,
5504, Garth Ave., Los Angeles, CA, 90056.)
18.Sistemas y Capacidad de Integración Logística (SIJC). Este programa
es un sistema de manejo de datos del análisis de soporte logístico integrado,
diseñado para responder a los objetivos CALS en producción de una mini
LSAR, de acuerdo con MIL-STD-1 38-2, "Requirements for a Logistic Support
Analysis Record". (Integrated Micro Systems, Inc., 306 Dr., P.O. Box 1438,
Séneca, SC, 29679.)
19.Análisis Distribuido Integrado del Soporte Logístico (DIISA). Este
programa es un procesador de bases de datos distribuidas, diseñado
para producir un registro de análisis de soporte mini-logístico (LSAR). Este
incorpora la confiabilidad, la mantenibilidad y los datos logísticos, y crea los
reportes LSAR de acuerdo con MIL-STD-1 388-2, "Requirements for a Logistic
Support Analysis Record". (Logistic Engineering. Associates, 2700 Navajo
Road, Suite A, El Cajón, CA, 92020.)
20.Utilidad del Diseño delSistema (SDU). El modelo SDU puede aplicarse
durante las etapas iniciales del diseño del sistema en la realización de la
asignación de los requerimientos (por ejemplo, la distribución de arriba-
abajo de los requerimientos del nivel del sistema para los procedimientos
del nivel más bajo del sistema) y, en las etapas tardías del desarrollo, en la
realización de los estudios de compromisos del diseño. Éste incorpora
la flexibilidad que permite la evaluación de las diferentes arquitecturas del
sistema, y también proporciona la capacidad de manejo de bases de datos
para propósitos del control de la configuración. La salida del modelo SDU
puede utilizarse en una variedad de situaciones, para incluir provisiones de
una entrada para EDCAS. (Systems Exchange, 5504, Garth Ave., Los Angeles,
CA, 90056.)
21.Desarrollo manejado por los requerimientos (RDD-100). El RDD es un
enfoque de modelado para evaluarlas diversas alternativas de diseño y para
valorar el comportamiento del sistema. Este enfoque utiliza diagramas de
bloque funcionales para describir las actividades secuenciales y concurren-
DISEÑO ASISTIDO POR COMPUTADORA (CAD) 199

tes, los requerimientos de entrada-salida, flujo de datos y flujo de elementos


físicos, y para ayudar en la descomposición del sistema. El RDD es un
método de ingeniería de sistemas, soportado por un lenguaje de modelado
gráfico ejecutable y herramientas computacionales desarrolladas para
ayudar a la ingeniería en el diseño de un sistema complejo a través del
análisis funcional y de la asignación. Las plataformas del sistema incluyen
Apollo, Apple Macintosh II y Sun with 8 Mb RAM. (Ascent Logic Corp., 180
Rose Orchard Way, Suite 200, San José, CA, 95134; u Onmitech Systems, Inc.,
2070 Chain Bridge Road, Suite 320, Vienna, VA, 22180)
22.Sistema de población de equipo reparable (REPS). El modelo REPS
está diseñado para evaluar una capacidad del sistema. Éste sigue el escena-
rio de una población homogénea de equipo reparable al encontrar una
demanda. Estas unidades fallan y se reparan mediante un canal de repara-
ción. Después de un período designado, las unidades antiguas son
remplazadas por las nuevas. El modelo se usa para calcular la combinación
óptima de unidades para distribución, el número de canales de repara-
ción para mantenimiento y la edad de retiro, basado en los costos anuales
equivalentes al mantenimiento del sistema para cumplir una cierta deman-
da. (W. Fabrycky, Systems Engineering Department, 333C, Norris Hall,
Virginia Tech, Blacksburg, VA, 24061.)
23.Calculador del costo del ciclo de vida (LCCC). El modelo LCCC ayuda
en la realización de un análisis de costo del ciclo de vida, mediante el uso de
una metodología de una estructura desglosada de costos (CBS). Los objeti-
vos y las actividades están vinculados a los recursos y constituyen una
subdivisión lógica de costos de acuerdo con el área de actividad funcional,
el elemento más importante de un sistema y (o) un tipo más discreto de
elementos comunes o similares. Esto proporciona un mecanismo para la
distribución de costos, la categorización de costos y el resumen final de
costos. Éste tiene la capacidad de identificar las contribuciones de costos,
en dólares reales y con descuentos, en algún nivel de la CBS. (Systems
Engineering Departament, 333C Norris Hall, Virginia Tech, Blacksburg, VA,
24061.)
24.Valoración de la estrategia de análisis de costos (CASA). El modelo
CASA se utiliza para desarrollar los costos del ciclo de vida (LCC) estimado
para una gran variedad de sistemas y equipo. Éste incorpora diversas
herramientas de análisis en una unidad funcionante, y permite que el
analista genere los archivos de datos, el desempeño de costos del ciclo de
vida, el análisis de sensibilidad, el análisis de riesgo, los resúmenes de costo
y la evaluación de las alternativas. (Defense Systems Management College,
DSS Directorate [DRI-S], Fort Belvoir, VA, 22060.)
25.Modelo de costos del ciclo de vida para los sistemas de material de
defensa (Marine Corps). Este modelo proporciona la estructura para el
cálculo del costo del ciclo de vida (LCC) para un sistema o equipo en
desarrollo. (MIL-HDBK-276-1 [MC], Military Handbook, "Life-Cycle Cost
200 MÉTODOS Y HERRAMIENTAS DE LA INGENIERÍA DE DISEÑO

Model for Defense Materiel Systems Data Collection Workbook", Departa-


mento de Defensa, Washington, D.C.)

Estos modelos son sólo unos cuantos, representativos, en relación con


el espectro total de las herramientas disponibles dentro de los sectores
actuales de la industria y del gobierno de Estados Unidos. No obstante,
como se indicó anteriormente, éstos se han desarrollado en forma indepen-
diente y el esfuerzo del diseño principal se realiza fuera de ellos. Los
objetivos esenciales en el futuro son: "

1.Evaluar e integrar estas y otras herramientas, como aplicables, de tal


manera que puedan utilizarse interactivamente, como se demuestra a través
de la ilustración de la figura 2.15. La meta es desarrollar un conjunto de
herramientas: a) que pueda ser utilizado en respuesta a una diversidad
de necesidades; b) que pueda tratar el sistema como una entidad, mientras
se utiliza para evaluar los diversos componentes del sistema y, c) que pueda
"conversar" con cada una de las otras, en términos de comunicaciones de
datos.
2. Incorporar estas y otras herramientas como es adecuado, en las
estaciones de trabajo, para todos los diseñadores responsables. El ingenie-
ro de diseño, mediante el uso de la estación de trabajo ideal mostrada en la
figura 4.4, no sólo debe tener las herramientas necesarias disponibles para
la realización de un análisis de estructura, sino también para la realización
de un análisis de confiabilidad. La misma persona puede no realizar ambos
trabajos; no obstante, él o ella necesitan observar los resultados de cada uno
(y sus efectos en cada uno de los otros), en forma concurrente, a fin de tomar
decisiones inteligentes de diseño.

En relación con la ingeniería de sistemas, como se emplea en las


aplicaciones del CAD, los retos para el futuro están directamente en línea
con este objetivo. Las herramientas adecuadas deben estar disponibles
y bien integradas en la estación de trabajo de diseño común, de tal manera
que fomenten la consideración apropiada de todas las disciplinas del
proceso de diseño del sistema.

U Con este objetivo en mente, en años recientes se han iniciado diversos esfuerzos con
tentativas muy importantes. Una de éstas, identificada como "RAMCAD" (confiabilidad y
mantenibilidad en el diseño asistido por computadora), fue establecida con el Departamento
de Defensa en el intervalo de tiempo de 1987 a 1988. Un esfuerzo se hizo para identificar la
disponibilidad de las herramientas CAD, las herramientas RMS (por ejemplo, confiabilidad,
mantenibilidad, capacidad de soporte) y para investigar los requerimientos de integración.
Otra actividad, con un objetivo similar, se incluyó bajo la tentativa de CALS (véase la sec-
ción 4.5. Estas tentativas y las relacionadas con ellas continúan con algunos progresos que
deben hacerse.
MANUFACTURA ASISTIDA POR COMPUTADORA (CAM) 201

4.4 MANUFACTURA ASISTIDA POR COMPUTADORA (CAM)12

La manufactura asistida por computadora (CAM) se refiere a la aplica-


ción de tecnología computarizada al proceso de manufactura o producción.
Esta aplicación, reflejada en el contexto del ciclo de vida presentado en la
figura 4.3, incluye esencialmente el uso de métodos automatizados, como
los que pertenecen a las siguientes actividades:

1.Planeación del proceso. Durante el proceso de producción, hay una


serie de pasos requeridos para fabricar un componente, para ensamblar un
grupo de elementos, ¡o una combinación de ellos! El proceso de planeación
se ocupa del flujo entero de las actividades, que evoluciona desde la
definición de una configuración de un diseño dado hasta la terminación del
producto entregado al consumidor, y las especificaciones CAM incluyen
aquellas actividades que pueden ser automatizadas. Mientras las activida-
des asociadas con el proceso de producción se conocen y practican desde
hace tiempo, el uso de la tecnología computacional para la realización
de estas actividades ha sido una innovación relativamente reciente. '
2. Control numérico (NC). En el proceso de producción hay muchos
casos en los que las herramientas de la máquina se requieren para fabrica-
ción, perforación, corte, rotación, soldadura, doblado o para una combi-
nación de estas operaciones. La aplicación de la tecnología computacional
para el control de las máquinas herramientas, con la información codificada
previamente registrada para hacer una parte, se ha empleado durante años.
No obstante, estas actividades se han realizado, con frecuencia, de manera
aislada de las otras actividades en el proceso de producción. Las instruccio-
nes de control numérico las han preparado los programadores tomando
información de los dibujos de ingeniería, los programas se han probado,
revisado, vuelto a probar, etc. Como esto puede ser muy extenso, la meta en
el futuro es ser capaz de generar instrucciones de entrada para control
númerico directamente desde la base de datos de diseño, desarrolladas
a través de las aplicaciones CAD vistas en la sección 4.3.
3.Robótica. En varias etapas del proceso de producción, puede haber
aplicaciones donde los robots pueden emplearse para fines de manejo de
materiales (esto es, el acarreo de partes de una posición a la siguiente),
o para el empleo de herramientas y piezas de trabajo en la preparación de

11 Otro término, empleado algunas veces para definir esta área, es la Manufactura Integrada por
Computadora (CM).
° Al evaluar el proceso entero de producción, hay algunas actividades que son similares por
naturaleza y donde pueden ser utilizados los procedimientos de estandarización. Esto es
particularmente verdadero en la manufactura de los componentes donde, por medio de una
agrupación adecuada, un proceso común y estandarizado puede ser aplicado usando los
métodos CAM. Este enfoque suele definirse como 'tecnología de grupo".
202 MÉTODOS Y HERRAMIENTAS DE LA INGENIERÍA DE DISEÑO

aplicaciones NC. En algunos casos, los robots se están usando actualmente


para operar perforadoras, soldadoras y otras herramientas. La tecnología
computacional es, evidentemente, empleada en la programación de robots
para estas operaciones y las relacionadas con la producción.
4. Administración de la producción. Durante el proceso de producción,
hay una actividad de administración continua donde las aplicaciones
computacionales pueden utilizarse efectivamente en apoyo a la previsión de
la producción, planeación, reporte de costos, actividades MRP, generación
de reportes de administración, etc. Hay un requerimiento para desarrollar
un sistema de administración de la información (MIS) que hace posible la
revisión y control de las funciones de producción.

La aplicación de los métodos CAM para el proceso de producción serán


diferentes para un "flujo de almacén" comparado con la operación "trabajo
de almacén", o para la producción de múltiples cantidades contra la cons-
trucción de "uno en su clave". Independientemente de su función, el proceso
completo debe ser tratado como un sistema, las aplicaciones posibles de
CAM (es decir, las combinaciones de control númerico, la robótica y los
métodos del procesamiento de datos) pueden identificarse y debe desarro-
llar una capacidad bien integrada. El objetivo es diseñar una capacidad de
producción con la correcta combinación de gente y grados de automatización.
En el diseño inicial, y en el monitoreo y control subsecuente de una
capacidad de producción, los principios cubiertos deben prevalecer bajo
la ingeniería concurrente y la ingeniería de calidad. Las tolerancias en la
manufactura, permisibles a través de la aplicación de herramientas de
control numérico yrobótica, deben ser consistentes con los requerimientos
iniciales del diseño del sistema. Se debe tener la precaución de asegurar que
no ocurran las variaciones inesperadas, causantes de la posible degrada-
ción del producto a través del proceso de producción. Esto es, en particular,
un problema relativo al cumplimiento de los objetivos de la ingeniería de
sistemas.

4.5ADQUISICIÓNYSOPORTE LOGÍSTICOASLSTIDO POR COMPUTADORA


(CALS) '4

La adquisición y soporte logístico asistido por computadora (CALS) se


refiere ala aplicación de tecnología computarizada para el espectro comple-

14
El CALS representa un concepto que está siendo fomentado por el Departamento de Defensa
para mejorar oportunamente la calidad, el tiempo oportuno y la conformancia en la creación
de los requerimientos de soporte de un futuro sistema. Una buena referencia es MIL-HDB)(-59,
Military Handbook, "Computer-Alded, Acquisition And Logistics Support (CALS) Program
Habilitation Guide", Departamento de Defensa, Washington, D.C.
ADQUISICIÓN Y SOPORTE LOGÍSTICO ASISTIDO POR COMPUTADORA (CALS) 203

to de logística, como se definió en la sección 3.2.5. Durante años, la


consideración de los requerimientos de soporte logísticos ha sido relegada
a una actividad en las últimas etapas del ciclo de vida del sistema.
Adicionalmente, en la definición inicial de los requerimientos de soporte del
sistema, el proceso que se ha habilitado incluye la generación de una gran
cantidad de documentación, la cual es distribuida, en gran parte, a través de
una red que involucra muy diversas localidades. Como los sistemas son
producidos y liberados para uso operacional, la actividad global de logística
asume frecuentemente un grado adicional de complejidad, que involucra
una gran cantidad de datos-documentación, el procesamiento y la distribu-
ción de muy diversos componentes y los requerimientos de una cantidad
importante de comunicaciones de datos. Los requerimientos de soporte
logísticos, particularmente para sistemas en gran escala, no siempre han
sido sensibles a la necesidad del sistema, que ha sido costoso.
Al ocuparse de la logística en el concepto del ciclo de vida del sistema,
hay actividades relacionadas con el diseño, actividades de análisis, activida-
des de publicaciones técnicas, actividades de abastecimientoyde consecu-
ción, actividades de fabricación y de ensamble, actividades de inventarios
y de almacenamiento, actividades de transportación y distribución, activi-
dades de mantenimiento y soporte del producto y actividades de adminis-
tración a lo largo de todo el espectro. Al referirse a la figura 4.3, las
aplicaciones son extensas, y hay un cierto grado de traslape con los
requerimientos de CAD y CAM.
Para proporcionar una indicación acerca de la variedad de aplicaciones
de tecnología computacional en el área logística, se dan los siguientes
ejemplos:15

1. Ingeniería logística. La utilización de modelos de confiabilidad,


mantenibilidad y capacidad de soporte en la realización de los compromi-
sos del diseño es un requerimiento importante durante el desarrollo del
sistema (por ejemplo, análisis de nivel de reparación, requerimientos de
repuestos, carga de mantenimiento, análisis de transportación, modelos de
costos del ciclo de vida). Esta actividad debe estar integrada en el esfuerzo
de CAD descrita en la sección 4.3 y se requiere del uso de tecnología de
gráficas, de los métodos analíticos y de las capacidades de manejo de bases
de datos.
2. Análisis de soporte logístico (LSA). A través de la evaluación de una
configuración de un diseño dado, los datos LSA se desarrollan con el
objetivo de identificar los requerimientos específicos para soporte del

La organización de archivos de datos digitales en los documentos concluidos y en los


reportes se preparan en la industria de defensa por MIL-STD-1840A, Military Standard,
"Automated Interchange of Technical Information", Departamento de Defensa, Washington,
D.C.
204 MÉTODOS Y HERRAMIENTAS DE LA INGENIERÍA DE DISEÑO

sistema, por ejemplo, partes de repuestos, prueba y equipo de soporte,


cantidad de personal y niveles de adiestramiento. Estos datos deben
generarse, procesarse, almacenarse, recuperarse y ser retroali mentados de
manera oportuna, sise realiza el diseño de la capacidad de soporte. También
se requieren tanto el procesamiento de datos como las capacidades de
manejo de la base de datos.
3. Documentación técnica. Esta categoría cubre los requerimientos de
datos de aprovisionamiento de partes de repuesto y de reparación, datos
de aprovisionamiento de datos de equipo de soporte, los dibujos de diseño
y los cambios notificados, los procedimientos técnicos, los manuales de
entrenamiento y los diversos reportes. Se incluye el desarrollo de los
manuales técnicos (esto es, procedimientos de operación del sistema,
instrucciones de mantenimiento), a través de procesos automatizados.
Las aplicaciones de tecnología computacional requieren el uso de hojas de
cálculo electrónicas, procesadores de palabras, gráficos y las capacidades
de manejo de bases de datos.
4.Distribución, transportación yaimacenado. El mantenimiento continuo
y soporte de sistema durante el ciclo de vida planeado requiere la distribu-
ción, la transportación, el manejo y las actividades de almacenado referen-
tes a partes de repuesto y de reparación. Además del procesamiento de
datos y de los requerimientos del manejo de bases de datos, asociados al
control de inventarios y actividades MRP, la aplicación de equipo de manejo
automatizado de materiales y la robótica pueden emplearse efectivamente
en el desempeño de las funciones del almacén. La "requisición" y "selección"
automática de los componentes desde los estantes de almacenamiento, en
respuesta a una necesidad definida, proporciona un excelente ejemplo del
uso de la tecnología computacional en el área logística. Posteriormente, las
oportunidades de la futura incorporación de "sistemas expertos" o "inteli-
gencia artificial", son evidentes cuando se considera el tipo de decisiones
"si-entonces" que son sumamente necesarias durante el proceso de manejo
de materiales.
5. Mantenimiento y soporte. Las actividades de servicio al cliente, en
apoyo al sistema en el área durante el ciclo de vida planeado, incluyen la
realización de acciones de mantenimiento planeado y no planeado. Esto,
a su vez, lleva al consumo de recursos de personal de mantenimiento, a la
utilización de equipo de prueba para los requerimientos de partes de
repuerto, a la necesidad de procedimientos de mantenimiento formal, etc.
Mientras los métodos computacionales se han utilizado en la generación de
partes de repuesto-de reparación que proveen los datos y publicaciones
técnicas, hay aplicaciones adicionales referentes al equipo de prueba.
En unos cuantos casos, la destreza de los especialistas, con el software de
soporte, se ha usado para propósitos de diagnóstico de mantenimiento.
Esta área, sustentada con algunas aplicaciones seleccionadas de inteligen-
cia artificial, es un candidato esencial para el crecimiento futuro.
RESUMEN 205

El objetivo de CALS, como es el caso en relación a CAD, debe ser


implementado en el nivel de detalle (esto es, un enfoque de arriba-abajo).
Inicialmente, ha habido una gran cantidad de esfuerzos sujetos al desarro-
llo de los requerimientos ya la interfaz de especificaciones. Adicionalmente,
hay muchas actividades continuas que están dirigidas hacia el desarrollo de
manuales técnicos y procedimientos que usan procesos automatizados. El
desarrollo y procesamiento de registros de análisis de soporte logístico
(LSARs) y el abastecimiento de datos son ejemplos adicionales en los que
mucho se ha realizado. Mientras que estas tentativas actualmente represen-
tan el "aislamiento de la automatización", el objetivo global es integrar los
requerimientos CALS con los CAD/CAM, como se ilustró en la figura 4.4.

4.6 RESUMEN

La implementación exitosa del proceso de la ingeniería de sistemas está


altamente influida por la tecnología y las herramientas disponibles para el
diseñador. El advenimiento de la tecnología computacional y el uso apropia-
do de métodos gráficos y exhibiciones, modelos analíticos, hojas de cálculo
electrónicas y procesadores de palabras, capacidades de manejo de bases
de datos, etc., ha hecho posible para el diseñador la realización de mucho
más en un tiempo muycorto, en la etapa inicial del ciclo de vida, ycon menos
riesgos globales. Así que el proceso de diseño ha experimentado la primera
fase en la transición de una larga serie de trabajos desempeñados manual-
mente para un proceso más eficiente integrado y automatizado.
En relación con el futuro, el reto es concluir la siguiente fase. Esto
involucra la integración de muchos métodos analíticos-herramientas, que
actualmente se emplean en forma individual aislada, en el proceso global
de diseño. El objetivo es: 1) desarrollar un concepto de estación de trabajo
que proporcione la comunicación adecuada entre todas las funciones
responsables a la ingeniería de diseño (ilustradas en la figura 4.2) y 2)
desarrollar una capacidad que permita el flujo automatizado de informa-
ción, sin restricciones, a partir de la capacidad CAD a CAM y CALS (ilustra-
dos en la figura 4.4). No sólo a estas capacidades les debe ser posible
"conversar con cada una de las otras" en el contexto de un proyecto dado,
sino que también la información de diseño producida debe ser compatible
y transferible entre los otros proyectos que tienen objetivos similares. Así,
se debe tener mucha precaución en relación con la selección de un lenguaje
apropiado, un formato de datos y una estructura de datos. No obstante,
puede anticiparse una gran cantidad de progreso y crecimiento futuro en
esta área.
206 MÉTODOS Y HERRAMIENTAS DE L& INGENIERÍA DE DISEÑO

PREGUNTAS Y PROBLEMAS

1. Defina y describa, en sus propias palabras, qué se incluye en cada uno


de los siguientes: CAD, CAM, CALS.
2. Identifique y describa algunas de las "tecnologías" que se están aplicado
en el proceso de diseño. Proporcione algunos ejemplos con aplicacio-
nes típicas.
3. Describa alguno de los beneficios asociados con la aplicación de méto-
dos computacionales en el proceso de diseño. ¿Cómo se relacionan
estos métodos con los objetivos de la ingeniería de sistemas?
4. Identifique algunos de los problemas relacionados con la aplicación de
métodos computacionales en el proceso de diseño. ¿Qué precauciones
deben ser observadas?
S. Para las disciplinas de diseño identificadas en el capítulo 3, sección 3.2,
se proporciona una lista de trabajos de un programa típico. En cada una
de las siguientes disciplinas, identifique aquellos trabajos que se reali-
zan mediante el uso de métodos computacionales. Incluya algunos
ejemplos específicos.
a. ¿Trabajos de ingeniería de confiabilidad?
b. ¿Trabajos de ingeniería de mantenibilidad?
c. ¿Trabajos de ingeniería de factores humanos?
d. ¿Trabajos de ingeniería logística?
e. ¿Trabajos de ingeniería de calidad?
f. ¿Trabajos de la ingeniería de valor-costo?
6. Describa qué se entiende por "inteligencia artificial". ¿Cómo puede
aplicarse?
7. ¿Cómo afecta la aplicación de tecnología computacional a la "ingeniería
concurrente"?
8. Defina y describa el objetivo de cada uno de los siguientes: ¡GES PDES,
RAMCAD.
9. Vea la figura 4.2. Seleccione un sistema (describiendo los trabajos en el
diseño) y desarrolle un diagrama de [lujo que muestre la aplicación de
cómo se debe habilitar el CAD.
10. ¿Cómo se relaciona el CAM con la ingeniería de sistemas? Describa
algunos efectos posibles.
PREGUNTAS Y PROBLEMAS 207

11. ¿Cómo se relaciona el CALS con la ingeniería de sistemas? Describa


algunos efectos posibles.
12. Dibuje un diagrama de flujo que muestre la interfaz de relaciones entre
CAD, CAM y CALS.
5
REVISIÓN Y EVALUACIÓN DEL DISEÑO

El diseño de sistemas es un proceso evolutivo, que progresa desde una


noción abstracta hasta algo que tiene forma y función, es fijo y puede
reproducirse en cantidades especificadas para satisfacer una necesidad
dada del consumidor. Inicialmente, se identifica un requerimiento (o nece-
sidad); desde ese momento, el diseño evoluciona a través de una serie de
fases, que son: diseño conceptual, diseño preliminar del sistema y diseño
de detalle y desarrollo, todo ello ilustrado en la figura 1.7.
Conforme el diseño avanza, hay grados naturales de definición del
sistema. Los requerimientos se definen con orientación hacia una base
"funcional". Esto incluye la definición de los requerimientos operacionales
y el concepto de mantenimiento, reportes de estudios compromisos y los
resultados de los análisis de factibilidad y la especificación del sistema
(Tipo "A")'. Después, se realizan el análisis funcional y la distribución de los
requerimientos, cuyos resultados se definen a través de una base "distribui-
da". Esta base puede definirse por medio de una combinación de especifica-
ciones (Tipo "B", "C", "D" y "E") de desarrollo, proceso, producto y (o)
material, conforme es posible. Esta configuración se extiende progresiva-
mente a través de numerosas iteraciones, hasta que se define una base de
"producto", etc. Estas fases naturales de la definición del sistema se reflejan
mediante las actividades y (o) indicadores señalados en la figura 1.8.
Al revisar el proceso global del diseño, deben incorporarse "las verifica-
ciones y balances" necesarios para asegurar que la configuración del
sistema se desarrolle efectivamente, satisfaciendo los requerimientos ini-
cialmente especificados. Estas verificaciones y balances, realizados a través
de los resultados de las revisiones de diseño, se proponen tempranamente
en el ciclo de vida del sistema cuando los cambios se realizan relativa-
mente de manera fácil y, usualmente, sin grandes costos. Una revisión del
diseño y una función de evaluación deben ser parte integral del proceso de
diseño. En la función de revisión del diseño, debe haber provisiones de
retroalimentación para la acción correctiva y la incorporación de modifica-

1
Las bases "funcional", "distribuida" y "de producto", se describen más ampliamente en el
Defense Systems Management College (DSMC), Systems Engineering Management Gulde, Fort
Belvoir, Virginia, 22060.
210 REVISIÓrI Y EVALUACIÓN DEL DISENO

ciones en el diseño, conforme sea necesario. La filosofía básica de la


evolución del diseño, con la revisión necesaria y las provisiones de
retroalimentación, se muestra en Ja figura 1.9. El propósito de este capítulo
es explicar este concepto mediante la descripción de los métodos de
evaluación, las revisiones del diseño informal y formal, el lazo de retro-
alimentación asociado y el lazo de acción correctivo.

5.1 REQUERIMIENTOS DE REVISIÓN Y EVALUACIÓN DEL DISEÑO

Uno de los objetivos al establecer un mecanismo formal para la revisión


y evaluación del diseño es asegurar, en bases progresivas y continuas, que
los resultados del diseño reflejen una configuración que por último satisfará
la necesidad indicada del consumidor. El diseño evoluciona desde la defini-
ción inicial de los requerimientos para un sistema dado a través de una serie
de iteraciones que siguen un enfoque de arriba-abajo, para una firme con-
figuración del sistema, lista para la producción y (o) la construcción:
conforme se avanza a través de esta serie de pasos, es importante, desde el
inicio, implementar el proceso de verificación de los requerimientos, ya que
los problemas potenciales pueden detectarse oportunamente y, si son
necesarios, incorporar los cambios más fácilmente. Así, se requiere un
esfuerzo continuo de revisión y evaluación del diseño.
Al evaluar las diversas etapas del diseño, ilustradas en las figuras 1.7
y 1.8, el proceso global de revisión puede realizarse efectivamente mediante
una combinación de diversos enfoques. Primero, hay una revisión informal
día por día, y la actividad de evaluación ocurre conforme se toman decisio-
nes y los datos se desarrollan. Esta actividad puede involucrar muy diversas
disciplinas de diseño, tomando decisiones en forma relativamente indepen-
diente y generando los datos del diseño basados en los resultados. Segundo,
las revisiones del diseño formal se llevan hacia las etapas designadas en la
evolución del diseño y éstas sirven como vehículo de comunicación
y aprobación formal de los datos del diseño. Estas dos áreas principales de
actividad se reflejan en la figura 5.1 y serán vistas más adelante, en la sec-
ción 5.2 y 5.3, respectivamente.
En respuesta a los "porqués" de la revisión del diseño, el objetivo es
asegurar que los requerimientos del sistema se están cumpliendo. Estos
requerimientos incluidos en la especificación del sistema (véase la sec-
ción 3. l), se indican en ambos términos: cuantitativo y cualitativo. El pro-
pósito del proceso de revisión del diseño es evaluar la configuración de
sistemas en las diversas etapas, en términos de estos requerimientos.
Cuando se trata el aspecto de "requerimientos", hay requerimientos de
nivel del programa, requerimientos técnicos del nivel del sistema, requeri-
mientos del diseño detallado en el nivel del componente, etc. Estos reque-
rimientos, observados no sólo en un sentido jerárquico sino también con el
Fase de diseño conceptual y Fase de diseño preliminar Fase de diseño de dictado del Fase de construcción y (o) Fase de uso operacional y soporte
avance de planeación del sistema 1 sistema y desarrollo producci 1 del sistema

Análisis de taObliidad del sistema,


requerimientos operaclona los, concepto
de manterde,nto, avance de planeación

Análisis tunclonal. distribución de requenrnlenlos, sintes.


de compromiso, diseño preliminar, conceptos de prueba y
evatuaclon del (kserro, planeación de detalle

Diseño de detalle de los sebsistemasy de los componentes,


de compromisos, desarrollo de los modelos prolollpicos,
prueba y eyaluación, planeación de la producción

Producción y (o( construcción del sistema y sus coroporenes,


actividades de producción del proveedor, distrbución,-mo operacional
niel sistema, rnantersnuento y soporte, recopilación de dalosy análisis

Uso operacional del sistema, mantenimientos de


apoyo y soporte, recopilación de datos y análisis,
rnoddkaciones al sistema (según se requiera)

Los requerimientos del sistema, evaluación, proceso de revisión

Revisión del diseño informal día por día y actividad de evaluación

Revisión del deño conceptual (revisión de los requerimientos del sítema)

Á Revisiones del diseño de sistema

ÁiA Revisiones del diseño de equipo-software

Revisión típica del diseño

Figura 5.1. Revisión y evaluación del diseño.


212 REVISIÓN Y EVALUACIÓN DEL DISEÑO

nivel de énfasis colocado en ellos, cambiará conforme se progrese desde el


diseño conceptual hasta el diseño de detalle y la fase de desarrollo. Por ejem-
plo, es adecuado establecer una relación jerárquica de los parámetros del
sistema, tal como se muestra en la figura 2.3. Muchos de estos parámetros
pueden expresarse en términos de una medición específica cuantitativa del
desempeño del sistema, esto es, la identificación de una medición técnica
del desempeño (véase la sección 3.1). Algunas de estas mediciones son
aplicables al nivel del sistema, algunas se aplican, más apropiadamente, al
nivel del subsistema y algunas se relacionan directamente con el ensamble
o con el nivel del componente. En cualquier caso, la especificación del
sistema (y sus especificaciones de soporte) debe establecer el orden de los
parámetros de evaluación tomando en cuenta su prioridad e importancia.
A partir de la (o las) relación(es) jerárquica(s) deseadas de los paráme-
tros de evaluación, es posible ahora establecer algunos criterios específicos
contra los cuales se comparan los resultados del diseño. Esto, evidentemen-
te, lleva a la identificación de los requerimientos de la revisión del diseño
para el diseño conceptual, para el diseño preliminar del sistema y para el
diseño de detalle y la fase de desarrollo. Ene! diseño conceptual, el proceso
de revisión del diseño debe ocuparse de las mediciones de desempeño del
nivel más alto del sistema, las relaciones del nivel funcional, etc. (como las
incluidas en las especificaciones del sistema Tipo "A"). En el diseño de
detalle y en la fase de desarrollo, mientras los requerimientos del nivel del
sistema son aún importantes, el énfasis puede estar en la selección
y estandarización de las partes, en el montaje de los componentes en el
diseño de un módulo, en la accesibilidad de un ítem que requiere manteni-
miento frecuente y en el etiquetado del pánel de despliegue y los controles.
Estos factores deben integrarse en la revisión global del diseño ye! proceso
de evaluación, presentado en la figura 5.1.
Dados los criterios contra los cuales se evalúa el diseño, es importante
identificar las disciplinas que tienen el mayor efecto en el diseño de acuerdo
con un requerimiento específico. Por ejemplo, al cumplir un requerimiento
de equipo de diagnóstico en el diseño de un sistema electrónico, de
ingeniería eléctrica, ingeniería mecánica y de ingeniería de mantenibilidad,
al realizar los trabajos de diseño respectivos, pueden tener el mayor efecto
sobre las figuras de mérito del tiempo de mantenimiento correctivo del
tiempo no operable (Mct) del sistema. Cuando se evalúa el nivel de partici-
pación en el proceso de revisión del diseño, es necesario que estas discipli-
nas de diseño se representen adecuadamente. En otras palabras, junto con
la identificación de los criterios de evaluación, debe identificarse la "respon-
sabilidad" del diseño.
La responsabilidad del diseño, desde la perspectiva organizacional (y la
participación en las revisiones del diseño) se verá más adelante, en las
secciones posteriores de este libro. No obstante, hasta este momento, vale
la pena añadir un comentario acerca de los requerimientos para la partid-
REQUERIMIENTOS DE REVISIÓN Y EVALUACIÓN DEL DISEÑO 213

Funciones
dleingenerfa
e diseño

Medidas
desempeño
\ fi h h U Um
» U
tnicoçrP)
é Ms \' 'i

Disponibilidad (90%) H L L M M H M L M M M M FI

Diagnóstico (95%) L M L H L M FI M M FI M 1 M

Capacidad de
intercambio (99%) M H M FI Y 1-1 FI FI Y FI FI Y Y

Costos del ciclo de


vida ($350K/unidad) Y Y FI Y M H 4-1 L Y Y H Y FI

ict(30min.) L L L Y M FI H Y Y M Y Y M

MDT(24hrs.) L M Y L L FI Y Y L L Y L FI

MYH/OH (15) L L Y L Y Y FI L L L Y L FI

YTBF (300 hrs.) L H L Y L L Y H FI Y H Y Y

MTBM (250 hrs.) L L L L L M H L L L Y L H

Niveles de
adiestramiento
del personal Y L Y M FI Y H L L L L L FI

Tamaño (150 It
por 7sft) H H M U Y U Y FI FI FI Y H Y

Rapidez (4SOmph.) FI L L L L L L L L L L Y FI

Efectividad del
sistema (80%) U L L Y L Y Y L L M M U H

Peso )lSOKlibras) FI FI Y Y Y Y U FI H H L H Y

H = interés ano; U = interés medio L = interés bajo

Figura 5.2. Relación entre los TPMs y las disciplinas responsables del diseño.

pación en la revisión del diseño. Al referirse a la figura 2.13, debe establecer-


se y adecuarse una jerarquía de los parámetros de evaluación del sistema
para cada sistema grande que se esté desarrollando. Aquellos parámetros
considerados importantes pueden identificarse como se muestra en la
214 REVISIÓN Y EVALUACIÓN DEL DISENO

figura 5.2. Al mismo tiempo, puede establecerse una relación de "grado de


interés" entre las diversas medidas de desempeño técnico (TPMs) y las
disciplinas aplicables que participan en el proceso de diseño. El nivel de
interés indicado (esto es, alto, medio y bajo) se refiere al impacto real
o percibido que la actividad de la disciplina tiene en un TPM diseñado para
el sistema. Esto, a su vez, debe llevar a establecer los requerimientos organi-
zacionales para la revisión y evaluación del diseño conforme se avanza
desde el diseño conceptual hasta el diseño de detalle y la fase de desarrollo.
Las secciones 5.2 y 5.3 tratarán esta área de una manera más extensa.

5.2 REVISIÓN INFORMAL DÍA POR DÍA Y EVALUACIÓN


Al referirse a la figura 5.1, la revisión del diseño y el proceso de evaluación
incluyen dos categorías básicas de actividad: 1) una actividad informal, en
la cual los resultados del diseño se revisan y discuten día por cha y 2) una
serie estructurada de diseño formal llevada a cabo en el tiempo especifico
del proceso de desarrollo global del sistema. La salida de las actividades
informales día por día lleva a las revisiones del diseño formal, y esta relación
se muestra en la figura 5.3.
El diseño generalmente se inicia con la ingeniería eléctrica, la ingeniería
mecánica, la Ingeniería de estructura, la ingeniería de procesos y (o) otras
ingenierías, directamente responsables del diseño de los diversos compo-
nentes del sistema. Los resultados, casi siempre producidos independien-
temente de estas diferentes fuentes, se describen por medio de una combi-
nación de dibujos, listas de partes, reportes, bases de datos computacionales
y documentación de apoyo del diseño. Conforme evoluciona este proceso
de definición, hay diversos objetivos más importantes:

1.Los resultados del diseño deben comunicarse adecuadamente de una


manera clara, efectiva y oportuna a todos los miembros del equipo de
diseño. Cada una che las personas involucradas en el proceso de diseño debe
trabajar sobre la misma base de datos.
2. Los resultados de diseño deben ser compatibles con los requerimien-
tos para el sistema definidos inicialmente. Aunque cada diseñador respon-
sable debe familiarizarse con el espectro total de los requerimientos del
sistema (esto es, requerimientos eléctricos y de confiabilidad), la separa-
ción física de las disciplinas de diseño y la falta de apreciación para las
interfaces a menudo resultan en discrepancias de un tipo a otro (esto es,
conflictos, omisiones, incompatibilidades entre los componentes que con-
forman el sistema). Estas discrepancias deben, evidentemente, corregirse
tan pronto como sea posible.

La actividad de revisión del diseño intenta satisfacer ambos objetivos.


Éste puede realizarse por medio de una serie de pasos que involucran la
Ingeniería de
diseño

Desarrollo y Revisión interna de Datos del diseño


distribución de los acuerdo con los ¿Están Si si Datos del diseño
repartidos para la Realizar a revisión repartidos para la
datos de la ingeniería criterios de diseño y jban
del diseño para la requerimientos de quefirnefltoS revisión forma] del del diseno formal producción-
revisión interna. espeolticaciones diseño construcción.

No No

Prepare, presente y 1 Lleve los compromi- Solución no factible 1


coordine las
recomendaciones
i NO sos adicionales para _________ ¿Ccitomidad No alcanzada 1
____ ____ ____ mnla soludón
para acción _____ aprobadas ______ identificar las ______
factUO De compromiso,
correctiva alternativas 1
documentados 1
Sí sí

Cambio de diseño iniciado 1


Datos del diseño de la 1
ingeniería revisados

Figura 5.3. Procedimiento de revisión y evaluación del diseño.


2UG REVISIÓN Y EVALUACIÓN DEL DISEÑO

distribución de dibujos, vistas de partes, etc., para todas las áreas aceptadas
del diseño, la revisión yvisto bueno de datos para aprobación, la generación
de las recomendaciones de cambios en el evento de no conformidad con un
requerimiento dado o para los propósitos de mejoramiento del producto, la
revisión de las recomendaciones de cambio por el diseñador responsable,
etc. Esto es, un proceso dia por dia con los datos de diseño que surgen desde
muy diversas fuentes y en el cual la cantidad de datos puede ser bastante
amplia dependiendo de la naturaleza del sistema que se desarrolla y el
tamaño del proyecto.
En el pasado, particularmente en relación con los grandes proyectos en
los cuales los miembros del equipo de diseño están lejos uno de otro, el
proceso de distribución de datos y la aprobación a menudo ha sido un tanto
largo en términos del tiempo requerido para avanzar a través del ciclo de
eventos. A causa de esto, combinado con la necesidad de los diseñadores
de "apegarse al diseño", muchas organizaciones han elegido pasar por alto
estos pasos de la distribución de datos, revisión y aprobación, con el interés
de ahorrar tiempo. En otras palabras, el diseñador individual toma una
decisión (a menudo independientemente) y la documentación del diseño se
prepara y distribuye y las partes componentes se consiguen y (o) fabrican,
etc. Aunque se espera que se hayan conocido todas las interfaces del diseño
y que se hayan cumplido los requerimientos del sistema, éste no siempre ha
sido el caso! En la prisa por concluir el diseño, ha habido omisiones,
conflictos y(o) problemas asociados con la incompatibilidad de los compo-
nentes del sistema. Estos problemas se han vuelto evidentes tardíamente
durante una revisión formal del diseño (cuando las revisiones formales del
diseño se han tratado) o durante la prueba y evaluación del sistema.
Adicionalmente, la implementación de los cambios del diseño se hace
más costosa que cuando estos cambios se incorporan en etapas tempranas
en el proceso de diseño.
En relación con el futuro, la implementación de la revisión informal del
diseño y del proceso de evaluación, que se muestra en la figura 5.3 es, por
supuesto, altamente deseado. Incluso, este procedimiento se revisa de
manera eficiente y oportuna. Aunque la serie de datos de los pasos de la
revisión realizada en el pasado puede haber consumido mucho tiempo, el
advenimiento de los métodos computarizados, descritos en el capitulo 4, ha
derivado en un definitivo mejoramiento. La utilización de la tecnología del
diseño asistido por la computadora (CAD) y el establecimientos de una red
de comunicación, como la ilustrada en la figura 4.2, ayudará a asegurar el
flujo de información necesaria de manera eficiente. Los datos del diseño
pueden distribuirse a muy diversas localidades expeditamente y en forma
concurrente, la revisión de los datos y la aprobación con el visto bueno
puede realizarse a través de los medios electrónicos y las revisiones de los
datos pueden implementarse en un tiempo relativamente breve. En estas
capacidades disponibles, se espera que el proceso ilustrado en la figura 5.3
pueda implementarse de manera efectiva.
REVISIONES DEL DISEÑO FORMAL 2117

Concerniente ala revisión y evaluación en sí mismas, la profundidad de


la revisión está en función de la complejidad del diseño, de si el ítem que se
diseña es nuevo (esto es, promoviendo el estado del arte) o si se prepara a
base de los componentes existentes disponible en stock, ysi el ítem se está
desarrollando por un proveedor externo o diseñando "en casa". Los íterns
que son complejos o incluyen la aplicación de nueva tecnología serán in-
vestigados en un mayor grado que los componentes estándares que están
disponibles y que se han usado en otros sistemas.
Al evaluar una configuración de un diseño dado de acuerdo con un
conjunto específico de requerimientos, el revisor puede desear desarrollar
una serie de "listas de verificación" basadas en los criterios aplicables.
Por ejemplo, a través de la revisión de los estándares seleccionados del
diseño, los datos de las partes del componente, los datos antropométricos
de los factores humanos, los factores de accesibilidad a la mantenihilidad,
los estándares de seguridad, etc., las diversas actividades de revisión de
diseño pueden desarrollar criterios que son aplicables directamente al
sistema en cuestión.2 Estos criterios, resumidos en la forma de una lista de
verificación, se referencian como la evaluación que ha de Ilevarse a cabo, de
un ítem dado. La lista de verificación sirve como ayuda al facilitar el proceso
de revisión. La figura 5.4 muestra un ejemplo de una lista de verificación que
identifica las áreas comunes del tema para las revisiones al nivel de sistema.
La figura 5.5 presenta un ejemplo de algunas cuestiones específicas que
amplían los temas en la figura 5,4. Al preparar las diversas revisiones del
diseño informal día por día, las listas de verificación de esta naturaleza
pueden ser muy útiles.3
Los resultados de un proceso de revisión informal día por día, en el
contexto de la documentación del diseño aprobada ("con el visto bueno"),
se identifican como ítems que deben presentarse en la revisión formal del
diseño. Esto incluye no sólo los dibujos de diseño y listas de partes, sino
también los reportes de los estudios de compromisos que sustentan las
decisiones críticas del diseño.

S.S. REVWUGNES DEL DISEÑO FORMAL

La revisión formal de! diseño constituye una actividad coordinada (esto es,
una reunión estructurada o una serie de reuniones) dirigida hacia la revisión

2Cuatro ejemplos, en los cuales están Incluidos los criterios generales del diseño-guías, son MIL-
HDBK-338, Military Handbook, EIectronIc Rellability Deslgn Handbook", Departamento de
Defensa, Washington, D.C.; Blanchard, B.S. y E.E., Lowery, Mainfainability Principies and
Practices, McGraw-Hill, New York, 1969; Woodson, W.E., Human Factors Design Handbook,
McGraw-Hill, New York, 1981; y Hammer, W., Pmduct Safety Management and En.gineering.
Prentice-Hall, Engkwood ChIs, N.J. 1980.
Un ejemplo de una lista de verificación de revisión del diseño puede encontrarse en el
apéndice B de este texto.
210 REVISIÓN Y EVALUACIÓN DEL DISEÑO

Lista de verificación de la revisión del diseño del sistema

Requerimientos generales:

Los requerimientos técnicos y el programa sé definen adecuadamente para el sistema.

1. Análisis de factibilidad S. Análisis funcional y distribución


2. Requerimientos operacionales 6. Especificación del sistema
3. Concepto y mantenimiento 7. Requerimientos del proveedor
4. Factores de efectividad 8. Plan de administración de la ingeniería de sistemas (SEMP)

Características de diseño:

El diseño refleja laconsideración adecuada en:

1. Accesibilidad 19.Pánel de despliegue y de controles


2. Ajuste y alineación 20. Personal de entrenamiento
3. Cables y conectores 21. Capacidad de producción
4. Calibración 22.Capacidad de reconliguración
5. Requerimiento de datos 23.Confiabilidad
S. Capacidad de desecho 24.Seguridad
7. Requerimientos ecológicos 25.Selección da partes-materiales
8. Factibilidad económica 26.Servicio y lubricación
9. Requerimientos ambientales 27.Requerimientos sociales
10.Requerimiento de instalación 28.Software
11. Acelerador 29.Estandarización
12.Manejo 30.Almacenamiento
13.Factores humanos 31.Capacidad de soporte
14.Capacidad de mantenimiento 32.Requerimientos de equipo de soporte
15.Mentonabilidad 33.Sobrevivancia
16.Movilidad 34.Capacidad de prueba
17.Operabilidad 35.Capacidad de transportación
18.Empaque y montaje 36.Calidad
Cuando se revisael diseño (distribuciones, dibujos, listas de partes, reportes), esta lista de verificación puede ser
benéfica para cubrir los requerimientos más importantes del programa y las características del diseño aplicables
al sistema. Los ítems listados se apoyan con más cuestiones detalladas y criterios incluidos en el apéndice B. La
respuesta a cada ítem listado debe ser SI.

Figura 5.4. Un ejemplo de una lista de verificación del diseño.

final o a la aprobación de una configuración de diseño dada, ya sea la


configuración global del sistema, un subsistema o un elemento del sistema.
Mientras el proceso de revisión informal día por día discutido en la sec-
ción 5.2. cubre los aspectos específicos del diseño, éste usualmente involucra
una serie de esfuerzos fragmentados independientes que representan una
variedad de las disciplinas ingenieriles. El propósito de la revisión formal es
proporcionar un mecanismo por medio del cual TODOS los miembros
interesados responsables del equipo de diseño pueden concurrir de manera
coordinada, conversar con cada uno de los otros y estar de acuerdo con el
enfoque recomendado. El proceso de revisión formal del diseño usualmente
incluye los siguientes pasos:
REVISIONES DEL DISEÑO FORMAL 2

Lista de verificación de la revisión del diseño detallado.

18. Empaque y montaje

a. ¿Es atractivo el diseño del empaque, desde el punto de vista del gusto del consumidor (por
ejemplo, color, forma, tamaño)?
b. ¿Es funcional el empaque incorporado en el mayorgrado posible? Los afectos de interacción entre
los empaques deben minimizarse debe ser posible limitar el mantenimiento al retiro de un módulo
(el que contiene la parle defectuosa) cuando ocurre una falta y no se requiere retirar dos, tres
o cuatro módulos a in do resolver el problema.
C. ¿Son intercambiables eléctrica, funcional y físicamente los módulos de equipo y(o) componentes,
que desempeñan operaciones similares?
d. ¿ El diseño del empaque as compatible con las decisiones de análisis de nivel de reparación? Los
ítems reparables están diseñados para incluir provisiones de mantenimiento tales como: de
prueba, da accesibilidad y de los componentes conectables. Los ítems clasificados como
descartados por falta" deben encapsularse y, entonces, no se requieren las provisiones de
mantenimiento.
e. ¿Están los módulos desechables incorporados a las prácticas más extensas? Es altamente
deseable reducir el soporte global del producto a través de un concepto de diseño sin
mantenimiento" ya que los ítems involucrados son bastante confiables y relativamente bajos en
cuanto a costos.
f. ¿Los módulos conectables y los componentes son utilizados en la mayor capacidad posible
(a menos que el uso de los componentes conectables degrade significativamente la confiabilidad
del equipo)?
g. ¿Los accesos entre módulos son adecuados pare tomar en cuenta el acceso manual (véase el
Manual de Diseño "X" para las provisiones de accesibilidad recomendadas)?
h. ¿Están los módulos y los componentes colocados de tal manera que la eliminación de un solo ítem
para mantenimiento no requerirá la eliminación de los otros ítems? Cuando as posible, debe
evitarse el apilamiento de los componentes.
i. ¿En las áreas donde, a causa del espacio limitado, es necesario apilar los componentes, están
colocados los módulos de tal manera que la prioridad do acceso se asigna de acuerdo con la
frecuencia de eliminación pronosticada y el remplazo? Los ítems que requieren mantenimiento
frecuente deben ser más accesibles.
j. ¿Son los módulos y componentes, no de la variedad de los conectables, montados con cuatro
o menos sujetadores? Los módulos deben colocarse de manera segura, pero el número de
diseñadores debe ser el mínimo.
k. ¿Están las provisiones de montaje de amortiguadores incorporadas donde los requerimientos de
impacto y vibración son excesivos?
1. ¿Están incorporadas las provisiones para hacer imposible la instalación de un módulo incorrecto?
m. Los módulos conectables y los componentes ¿son removibles sin el uso de herramientas? Si se
requieren las herramientas, éstas deben ser del tipo estándar.
n. ¿Están provistas las correderas o los ganchos para facilitar la instalación de un módulo?
o. ¿Están etiquetados adecuadamente tos módulos y los componentes?

Figura S.S. Lista parcial de la revisión del diseño.

1. Un ítem recientemente diseñado, designado como completo por el


ingeniero responsable del diseño, se selecciona para la revisión formal
y evaluación. El ítem puede ser la configuración global del sistema como una
entidad o un elemento muy importante del sistema, dependiendo de la fase
del programa de la categoría de revisión realizada.
2. Se especifica un lugar, una fecha y un tiempo que cumplir para la
revisión de diseño.
20 REVISIÓN Y EVALUACIÓN DEL DISEÑO

3. Se prepara una agenda para la revisión, definiendo su alcance y los


objetivos anticipados de la revisión.
4.Se establece un pánel de revisión del diseño (DRB) representando los
elementos organizaciones y las disciplinas afectadas por la revisión.
La representación de la ingeniería eléctrica, de la ingeniería mecánica, de la
ingeniería estructurada, de la ingeniería de confiabilidad, de la ingeniería
logística, de la manufactura o producción, de los proveedores de componen-
tes, de la administración y de otras organizaciones adecuadas es incluida
según se aplique. Esta representación, evidentemente, variará de una
revisión a la siguiente. Se selecciona un presidente imparcial para conducir
la revisión.
S. Las especificaciones pertinentes, los dibujos, las listas de partes, las
predicciones y los resultados de los análisis, los reportes de los estudios de
compromisos yios otros datos de soporte del ítem que se está evaluando
deben identificarse antes de que se realice la revisión formal del diseño,
y debe estar disponible durante la reunión para propósito de referencia
según se requiera. Con optimismo, cada uno de los miembros del pánel de
revisión del diseño se familiarizará por sí mismo con los datos, antes de la
reunión.
6. Los items seleccionados del equipo (tableros, modelos de prueba de
servicio, prototipos) simulaciones y (o) el software puede utilizarse para
facilitar el proceso de revisión. Estos Items deben, evidentemente, identifi-
carse de manera temprana.
7. Deben definirse los requerimientos de reporte y los procedimientos
para realizar las acciones subsiguientes necesarias provenientes de las
recomendaciones de la revisión del diseño. Deben establecerse las respon-
sabilidades y límites de tiempo de la acción después de la reunión.
8. Deben identificarse las fuentes patrocinadoras de los preparativos
necesarios para conducir la reunión de la revisión del diseño formal y para
el procesamiento subsecuente de las recomendaciones sobresalientes.

La reunión de la revisión formal del diseño generalmente incluye una


presentación (o una serie de presentaciones) acerca del ítem que se está
evaluando, por el ingeniero responsable del diseño, para los miembros del
pánel de revisión del diseño seleccionado. Esta presentación debe cubrir la
configuración propuesta del diseño, junto con los resultados de los estudios
de compromisos y los análisis que soportan el enfoque del diseño. El ob-
jetivo es resumir lo que se ha establecido anteriormente a través de la
actividad de diseño informal día por día. Si los miembros del pánel de
revisión del diseño están preparados adecuadamente, este proceso puede
realizarse de manera eficiente.
La revisión formal del diseño debe organizarse bien y controlarse
firmemente por el presidente del pánel de revisión del diseño. Las reuniones
para la revisión de diseño deben ser breves y concisas, objetivas, en
REVISIONES DEL DISEÑO FORMAL 221

términos de que permitan contribuciones positivas, y no deben permitir


desviarse de los puntos de la agenda. La asistencia debe limitarse a quienes
tienen un interés directo y pueden contribuir al tema del asunto que se
presenta. Los especialistas del diseño que participan deben ser autorizados
para hablar y tomar decisiones concernientes a su área de especialidad.
Finalmente, la actividad de revisión de diseño debe hacer los preparativos
para la identificación, el registro, los planes y el rnonitoreo de acciones
correctivas. La responsabilidad específica para la acción siguiente debe
diseñarse por el director del pánel de revisión del diseño.
Con la realización de las reuniones de la revisión formal del diseño, se
cumple cierto número de propósitos:

1.¡La junta de la revisión formal del diseño proporciona un foro de


comunicaciones a través del pánel! La coordinación necesaria y la integra-
ción no se realizan adecuadamente por medio del proceso de revisión
informa! día por día, aun con la disponibilidad de la tecnología computarizada.
Se requiere el contacto, 'persona a persona.
2.Esto proporciona la definición de una base común de la configuración
para todo el personal del proyecto, es decir, cada uno de los involucrados
en el proceso del diseño debe trabajar sobre la misma base. El ingeniero
responsable del diseño tiene la oportunidad de explicar su enfoque del
diseño y quienes representan las diversas disciplinas tienen la oportunidad
de aprender a través de los problemas del diseñador. Esto, a su vez, crea un
mejor entendimiento entre el personal de diseño y de soporte.
3. Esto proporciona un medio para resolver los problemas sobresalien-
tes de la interfaz y fomenta el asegurarse de que todos los elementos del
sistema son compatibles. Se tratan los conflictos que no fueron resueltos
mediante de la revisión informal. También aquellas disciplinas no represen-
tadas apropiadamente a través de las actividades iniciales tienen la oportu-
nidad de ser escuchadas.
4. Esto proporciona una verificación formalizada (esto es, auditada) de
la configuración propuesta del diseño del producto con respecto de la
especificación y de los requerimientos contractuales. Se señalan las áreas
que no están de acuerdo y se inicia la acción correctiva corno es adecuado.
S. Esto proporciona un reporte de las decisiones más importantes del
diseño que se han tomado y de las razones para hacerlo. Se registran ade-
cuadamente la documentación, los análisis, las predicciones ylos reportes
de los estudios de compromisos del diseño que sustentan estas decisiones.

La realización de las reuniones de la revisión formal del diseño tiende a


incrementar la probabilidad de un diseño maduro, así como también
la incorporación de las últimas técnicas de diseño, cuando esto es apropia-
do. Las revisiones de grupo pueden llevar ala identificación de nuevas ideas,
la aplicación de los procesos más simples y al logro de disminuir los costos.
222 REVISIÓN Y EVALUACIÓN DEL DISEÑO

Una buena y "productiva" actividad de revisión formal del diseño puede ser
muy benéfica. No sólo puede causar una reducción de los riesgos del
productor referente a cumplir con la especificación y los requerimientos
contractuales, sino que también los resultados a menudo llevan a un
mejoramiento de los métodos de operación del productor.
Como ya se indicó, las reuniones de la revisión formal del diseño se
planean, generalmente, antes de cada paso importante de evolución del
proceso de diseño, por ejemplo, después de la definición de una base
funcional, pero antes del establecimiento de una base de distribución.
Aunque la cantidad y tipo de revisiones del diseño planeadas puede variar
de programa a programa, cuatro tipos básicos son fácilmente identificables
como comunes para la mayor parte de los programas. Estos son la revisión
del diseño conceptual, la revisión del diseño de sistema, la revisión del
diseño de equipo o software y la revisión de diseño crítico, El escalonamiento
relativo de estas revisiones se ilustra en la figura 5.1.

S. S. nevqonón dell dinao conecplull

La revisión del diseño conceptual (o revisión de los requerimientos del


sistema) usualmente se planea al final del diseño conceptual y antes de
introducirse a la fase del diseño preliminar del sistema del programa
(de preferencia, que no sea después de uno o dos meses de que empiece el
programa). El objetivo es revisar y evaluar la base funcional del sistema
y el material que se ha de cubrir por medio de esta revisión debe incluir lo
siguiente:

1. El análisis de factibilidad (los resultados de las valoraciones tecno-


lógicas y los estudios de compromisos que justifican el enfoque del
diseño del sistema que se propone).
2. Requerimientos operacionales del sistema.
3. Concepto de mantenimiento del sistema.
4. Análisis funcional (diagramas de bloque de alto nivel).
5. Criterios importantes del diseño para el sistema (esto es, factores
de confiabilidad, factores de mantenibilidad y factores de logística).

Se reconoce que algunos de estos requerimientos no pueden definirse adecuadamente


durante la fase conceptual del diseño y que la revisión de estos puede realizarse más tarde.
No obstante, al comentar el enfoque general deseado aquí descrito (y particularmente en
relación con la ingeniería de sistemas), deben hacerse mayores esfuerzos para completar estos
requerimientos tempranamente, aunque los cambios pueden ser necesarios conforme avanza
el diseño del sistema. El objeto es obligar (o "forzar") tempranamente la definición de sistema.
REVISIONES DEL DISEÑO FOR1VIAL 22

6. Figuras de mérito de la efectMdad aplicables (FOMs) y las medidas


de desempeño técnico (FPMs).
7. Especificación del sistema (Tipo 'A: véase la acción 3.1. y la figu-
ra 3.3).
8. Plan de administración de la ingeniería de sistemas (SEMP).
9. Pilan maestro de prueba y evaluación (I'EMP).
10. Documentación del diseño del sistema (dibujo de distribución,
croquis, listas de partes, datos de componentes de los proveedores
seleccionados).

La revisión conceptual del diseño se ocupa especialmente de los reque-


rimientos del sistema del nivel más alto y los resultados constituyen las
bases para el diseño preliminar del sistema siguiente y de la actividad de
desarrollo. La participación en esta revisión formal debe incluir la represen-
tación seleccionada de las organizaciones del consumidor y productor.
La representación de consumidor debe involucrar no sólo a aquel personal
que es responsable de la creación del sistema (esto es, la contratación y la
consecución), sino también a aquellos que son responsables esecialmente
de la operación y del soporte del sistema en el campo. Las personas con
experiencia en las operaciones de mantenimiento deben participar en la
revisión de los requerimientos del sistema. En la parte del productor del
espectro, aquellos que dirigen a los ingenieros responsables del sistema
deben participar junto con los representantes de las diversas disciplinas del
diseño y de la producción (como sea necesario). Es importante asegu-
rar, desde el inicio, que las disciplinas identificadas en el capitulo 3 se
representan adecuadamente en el proceso de la revisión formal del diseño.
En resumen, la revisión conceptual del diseño es extremadamente
importante para todo lo que se le relaciona, lo cual representa la primera
oportunidad de comunicación formal en relación con los requerimientos del
sistema de arriba-abajo ¡Esto puede proporcionar una base excelente para
todos los esfuerzos siguientes del diseño! Desafortunadamente para mu-
chos proyectos en el pasado, la realización de las revisiones del diseño
conceptual no ha sido evidentemente rápida. Adicionalmente, si de esta
manera se hubiesen conocido los resultados, no siempre estarían disponi-
bles para el personal responsable de la ingeniería de diseño asignado al
proyecto. Esto, a su vez, ha resultado en una serie de esfuerzos realizados
un tanto al vacío, y no bien coordinados o integrados. De este modo, con los
objetivos de la ingeniería de sistemas en mente es esencial que se defina una
buena base funcional para el sistema, y se evalúe adecuadamente a través
de la realización de la revisión conceptual efectiva del diseño.
224 REVISIÓN Y EVALUACIÓN DEL DISEÑO

5..2. RevlcUoneg del diseño del sistema

Las revisiones deldiseño delsis tema se planean generalmente durante la fase


del diseño preliminar, cuando se definen los requerimientos funcionales y
las asignaciones, se preparan las distribuciones del diseño preliminar
y especificaciones de detalle, se llevan a cabo los estudios de compromisos
al nivel del sistema, etc.(Véase la figura S. l.) Estas revisiones están orienta-
das a la configuración global del sistema, en lugar de los ftems individuales
de equipo, softwareyotros componentes del sistema. Conforme evoluciona
el diseño es importante asegurar que se mantengan los requerimientos
definidos en la especificación del sistema. Hay una o más revisiones forma-
les planeadas dependiendo del tamaño del sistema y la complejidad del
diseño. Las revisiones del diseño del sistema cubren una variedad de temas,
algunos de los cuales se anotan a continuación:

1. Análisis funcional y la asignación de los requerimientos (más allá de


lo que se cubrió a través de la revisión conceptual del diseño).
2. Desarrollo, proceso, producto y especificaciones del material, con-
forme es pertinente (Tipos "B","C", "D" y "E").
3. Datos del diseño definiendo el sistema global (distribuciones, dibu-
jos, listas de partes-materiales, datos del proveedor).
4. Los análisis, los reportes, las predicciones, los estudios de compro-
misos y la documentación relacionada con el diseño. Esto incluye el
material que se ha preparado para soportar la configuración del
diseño propuesto y los análisis-predicciones que proporcionan una
valoración de lo que se propone. Se incluyen las predicciones de
confiabilidad y mantenibilidad, los datos de análisis de soporte
logístico, etc.
S. La valoración de la configuración propuesta del diseño del sistema,
en términos de las medidas del desempeño técnico (l'PMs) que son
pertinentes.
6. Planes individuales del programa-diseño (esto es, planes del progra-
ma de confiabilidad y mantenibilidad, plan del programa de factores
humanos y plan LS).

La participación en las revisiones del diseño del sistema debe incluir la


representación de las organizaciones del consumidor y del productor, así
como también de los proveedores más importantes involucrados en las
bases tempranas del ciclo de vida del sistema.
REVISIONES DEL DISEÑO FORMAL 225

5.3.3 Revisiones 1e diseño del equlpo-eoftwere

Las revisiones formales del diseño que cubren al equipo, al software y a los
demás componentes del sistema se planean durante el diseño de detalle y la
fase de desarrollo del ciclo devida del sistema. Estas revisiones, usualmente
orientadas a un ítem particular, incluyen el reporte siguiente:

1. Los procesos, producto, especificaciones de los materiales (Tipos


"C", "D" y "E", después de que se cubrieron a través de las revisiones del
diseño del sistema).
2. Datos del diseño definiendo los subsistemas más importantes, el
equipo, el software, etc., elementos del sistema como es pertinente (dibujos
de ensamble, dibujos de especificaciones, dibujos de construcciones, dibu-
jos de instalación, diagramas lógicos, diagramas esquemáticos, material
y listas de partes detalladas, etcétera).
3. Los análisis, reportes, predicciones, estudios de compromisos
y demás documentación relacionada con el diseño, conforme sea requerida
en el soporte de la configuración del diseño propuesta y (o) para fines de
valoración. Las predicciones de confiabilidad y mantenibilidad, los análisis
de los trabajos de factores humanos, los datos de análisis de soporte
logísticos, etcétera.
4. Valoración de la configuración propuesta del diseño de sistema en
términos de las medidas pertinentes de desempeño técnico (TPMs).
Se requieren evaluaciones y revisiones continuas para asegurar que se
mantengan estos requerimientos a nivel del sistema durante las diversas
etapas de diseño de detalle y desarrollo.
5. Los tableros de ingeniería, los modelos de laboratorio, los modelos de
prueba de servicio, las simulaciones y los modelos prototipos usados para
apoyar la configuración específica del diseño que se evalúa.
6. Los datos del proveedor que cubren los componentes específicos del
sistema, según es pertinente (dibujos, material y listas de partes, análisis
y reportes de predicción, etcétera).

La participación en estas revisiones formales debe incluir la represen-


tación del consumidor (esto es, el cliente), productor (esto es, contratista)
y organizaciones de proveedor.

5.3.4 Revisión critica del diseño

La revisión crítica del diseño se planea generalmente después de la conclu-


sión del diseño de detalle, pero antes de la distribución en firme de los datos
de diseño para producción o construcción. El diseño está esencialmente
"congelado" hasta este momento, y la configuración propuesta se evalúa en
223 REVISIÓN Y EVALUACIÓN DEL DISEÑO

1 i

1 I
fi
1
fi
fi fi•.

1 1

/
.1
_ fi
1

fi fi
I I
fi I

O O O 0 O O O O O O C 0000
O O O O O C4 C O O O U') O U 0000
OU)OU)O
C) CJ C'J

ti 72

1 1 LA q
EL CAMBIO DE DSEflO Y EL PROCESO DE MODWICACIóN 2227

términos de adecuación y capacidad de producción. La revisión crítica del


diseño puede tratar temas como los siguientes:

1. Un conjunto completo de documentación del diseño final que cubre


el sistema y sus componentes (dibujos de manufactura, listas de
partes y materiales, datos del proveedor de las partes componentes,
notificación de cambios de dibujo, etcétera).
2. Loa análisis, predicciones, estudios de compromiso, resultados de
prueba y evaluación y documentación relacionada con el diseño
(predicciones de confiabilidad y mantenibilidad, análisis de factores
humanos y de seguridad, registros de análisis de soporte logísticos
como reportes de prueba, etcétera).
3. La valoración de laconfiguración final del diseño del sistema (esto es,
la base del producto) en términos de las medidas pertinentes de
desempeño técnico ÇTPMs).
4. Un plan detallado de producción-construcción (descripción de los
métodos propuestos de manufactura, procesos de fabrica(ci(án, sumi-
nistros de control de calidad, requerimientos del! proveedor, flujo de
material y requerimientos de distribución, planes, etcétera).
S. Un Plan Integrado de Soporte Logístico (ILSP) final, que cubre el
mantenimiento del ciclo de vida propuesto y el soporte del sistema
durante la fase de utilización del consumidor.

Los resultados de la base de la revisión del diseño crítico describen la


configuración del sistema-producto antes de introducirse a la producción-
construcción. Esta revisión constituye el último esfuerzo en una serie
progresiva de esfuerzos de evaluación, que reflejan el diseño y desarrollo
desde una perspectiva histórica que muestra el crecimiento y madurez del
diseño conforme el proyecto ingenieril evoluciona. Es importante observar
en general el proceso de revisión de diseño y proporcionar una evaluación
global de ciertos atributos del sistema designado conforme el proyecto
avanza particularmente, ya que se requiere continuidad entre las diversas
predicciones. Un ejemplo de los atributos diseñados del sistema que deben
valorarse en forma continua se presenta en la figura 5.6,

5.41. EL CAMBIO DE DIISIEÑO Y EL PilOCESO DE I!llODIIIFIICACIIÓilI

El objetivo hasta ahora ha sido desarrollar un sistema en forma progresiva


y establecer una base firme de configuración mediante de la revisión for-
mal y el proceso de evaluación. Er esencia, los resultados de la revisión
conceptual del diseño conducen a la definición de los requerimientos del
228 REVISIÓN Y EVALUACIÓN DEL DISEÑO

nivel del sistema, los resultados a partir de las revisiones del diseño del
sistema constituyen una descripción más profunda de los concepto
del empaque del sistema, etc. Conforme se avanza a través de la serie de las
revisiones del diseño descrita en la sección 5.3., la definición del sistema se
vuelve más refinada y se establece la base de configuración (actualizada
de una revisión a la siguiente). Esta base, que constituye un solo punto de
referencia para todas las personas que están involucradas en el proceso
de diseño, es crítica desde el punto de vista de cumplir con los objetivos de
la ingeniería de sistemas descritos anteriormente.
Una vez que se establece una base de configuración es igualmente
importante que cualquier variante o cambio con respecto a esta base sean
controlados estrictamente. Ciertamente, no se anticipó que una base dada
permanecería inalterable, particularmente durante las etapas tempranas
del desarrollo del sistema. No obstante, al evolucionar desde una configura-
ción del diseño a la siguiente, es importante que todos los cambios se
registren cuidadosamente y se documenten en términos de su posible
efecto en los requerimientos especificados del sistema.
El proceso de identificación de la configuración, el control de cambios
y mantenimiento de la integridad y continuidad del diseño se realiza a través
de la administración de la configuración (CM).
En el sector de defensa, la administración de la configuración a menudo
se relaciona con el concepto de "administración de la base". Remitiéndose
a la figura 1.7, las bases funcionales distribuidas y del producto se estable-
cen como el proceso evolutivo de desarrollo del sistema. Estas bases se
describen a través de una familia de especificaciones (Tipos "A", "B", "C",
"D" y (o) "E"), dibujos y listas de partes, reportes y documentación relacio-
nada. El proceso de revisión formal del diseño proporciona la autenticidad
neçesaria de estas configuraciones de base, y se realiza la función de
Identificación de la Configuración (CI). La Cl se refiere a una parte en
particular, mientras la función de configuración del estado contable (CSA)
es "un sistema de administración de la información que proporciona
trazabilidad de las bases de configuración y cambios a las bases, y facilita la
implementación efectiva de los cambios".' La CSA incluye la documentación
que evoluciona a partir de una base de configuración a la siguiente.
Los cambios de diseño propuestos o los cambios propuestos a una base
dada (esto es, un diseño CI) pueden iniciarse durante cualquier fase del ciclo

La administración de la configuración (CM) constituye el proceso que identifica las caracte-


rísticas funcionales y físicas de un ítem durante su ciclo de vida, los cambios de control de estas
características ylos registros y reportes de proceso de cambios y el estado de implementación.
La CM, como se definió en el sector de defensa, se describe en MIL-STD-483 Military Standard.
"Configuration Management Practices for Systems, Equipments, Munitions, and Computer
Programs," Departamento de Defensa, Washington, D.C.
'Defense Systems Management College SM,Systems Engineering Management Cuide, Fort
Belvoir, Virginia, 22060, capítulo 11.
EL CAMBIO DE DISEÑO Y EL PROCESO DE MODIFICACIÓN 229

de vida global del sistema. Dichos cambios, preparados en la forma de una


propuesta de cambios de ingeniería (ECP) puede clasificarse como sigue:

1. Cambios clase 1. Cambios del diseño que afectarán la forma, figura


y (o) función (por ejemplo, cambios que afectarán el desempeño del siste-
ma, la confiabilidad, la seguridad, la capacidad de soporte, los costos del ci-
clo de vida y(o) algún otro requerimiento de la especificación del sistema).
2. Cambios clase 2. Cambios del diseño que son relativamente menores
por naturaleza y que no afectarán los requerimientos de la especificación
(por ejemplo, cambios que cubren las especificaciones de material, aclara-
ciones de la documentación, nomenclatura del dibujo, deficiencias del
productor).

Los cambios pueden categorizarse como "de emergencia", "urgentes"


o "rutinarios", dependiendo de la prioridad y de lo crítico del cambio.
Una versión simplificada del procedimiento del control del sistema se
ilustra en la figura 5.7. Los cambios propuestos en una base dada pueden
iniciarse durante cualquier fase de desarrollo del sistema, de producción
y (o) de uso operacional. Cada cambio propuesto se presenta en forma de
una propuesta de cambio en ingeniería (ECP), presentada para la revisión,
evaluación y aprobación. En general, cada ECP debe cubrir los siguientes
puntos: 8

1. Una exposición del problema así como una descripción del cambio
propuesto.
2. Una breve descripción de las alternativas consideradas para respon-
der a la necesidad.
3. Un análisis que muestra de qué manera el cambio resolverá el
problema.
4. Un análisis que muestre de qué manera el cambio afectará el des-
empeño del sistema, los factores de efectividad, los conceptos de
empaque, la seguridad, los elementos de soporte logístico, los
costos del ciclo de vida, etc. ¿Cuáles son los efectos (si hay alguno)

Los cambios de la ingeniería se revisan en DOD/STD-480A, DOD Standard, "Configuration


Control-Engineering Changes, Deviations, and Waivers", Departamento de Defensa, Washing-
ton, D.C.
8
En muchas organizaciones, los procedimientos relacionados con la administración de
configuración del control de cambio son un poco más complejos que el que aquí se presenta.
El procedimiento puede involucrar solicitudes de cambio de la ingeniería (ECRs), notificacio-
nes de revisión del diseño (DRNs), documentos de control de interfaz (lCDs), etc. El objetivo
aquí es presentar un enfoque simplificado, proporcionando un entendimiento básico de la
importancia de control de cambios como parte del proceso de la ingeniería de sistemas.
1

•0

LJ
TU
u •;, o o
L
uo
cro

02
8.8

ii'o E'o
)•
'o .Ilcj —
' )
,
2
o
'L
o o o

10
EL CAMBIO DE DISEÑO Y EL PROCESO DE MODIFICACIÓN ñZfll

en los requerimientos de especificación del sistema? ¿Cuál es el


efecto en el costo del ciclo de vida?
S. Un análisis para asegurar que la solución propuesta no causará la
introducción de nuevos problemas.
6. Un plan preliminar para incorporar los cambios, es decir, fecha
propuesta de incorporación, números seriales afectados, requeri-
mientos de equipo no disponible y verificación del enfoque de
prueba (cuando es pertinente).
7. Una descripción de los recursos requeridos para implementar el
cambio.
S. Una estimación de los costos asociados con la implementación del
cambio.

9. Una descripción que cubre el impacto del sistema si el cambio


propuesto no se implementa, es decir, una identificación de los
riesgos posibles asociados con una decisión "de nc hacer nada".

Al referirse a la figura 5.7, las propuestas de cambios de ingedieria


(ECPs) se procesan a través del pánel de control de cambios (algunas veces
conocido como el "pánel de control de la configuración", o el CCB) para
revisión y evaluación. El CCB debe funcionar de manera similar al pánel de
revisión del diseño (DRB) discutido en la sección 5.3. La representación del
pánel debe cubrir aquellas disciplinas del diseño que son afectadas por el
cambio, para incluir la representación del cliente ydeli proveedor conforme
es necesario. No sólo es necesario revisar y evaluar el diseño original, sino
que también es importante asegurar que todos los cambios propuestos del
diseño se manejen de manera similar. En caso de que la planificación
del proyecto sea "apretada", el diseñador generará los datos sólo para
contar con algo disponible para el registro, mientras la presentación real del
diseño se reflejará por medio del "proceso de cambio". Aunque ésta no es
una práctica preferida, ocurre en un número de casos en los que el objetivo
es ahorrar tiempo. En algunos casos, la revisión de los cambios del diseño
deben tratarse con el mismo grado de importancia, como se especificó para
la revisión del diseño formal.
Hasta la conclusión de la revisión del cambio del diseño formal por el
CCB, los ECPs aprobados se apoyarán con el desarrollo de un plan para
incorporar el cambio (o los cambios) en el sistema. Este plan debe incluir no
sólo las modificaciones requeridas para el equipo esencial, sino las modifi-
caciones asociadas con el equipo de prueba y de soporte. Las partes de
repuesto y de reparación, las instalaciones, el software y la documentación
técnica. Todos los elementos del sistema deben tratarse en forma integrada.
232 REVISIÓN Y EVALUACIÓN DEL DISEÑO

La incorporación real de los cambios al sistema se realiza empleando


una variedad de enfoques que depende de cuándo debe implementarse el
cambio. El tiempo de implementación está en función de la prioridad y (o)
de la criticabilidad. Los cambios de emergencia o urgentes pueden requerir
acción inmediata, mientras los cambios de rutina pueden agruparse
e incorporarse ene! momento conveniente, más tarde. Los cambios aproba-
dos, iniciados durante el diseño y desarrollo del sistema antes de la
disponibilidad de algún hardware u otros componentes físicos, pueden
incorporarse a través de la preparación de las notificaciones de cambio del
diseño (DCNs), o equivalentes, adjuntos a los dibujos-documentación per-
tinentes, cubriendo aquellas áreas de diseño afectadas por los cambios.
Conforme avanza el proyecto, estos cambios en "papel" (o en la base de
datos) se reflejarán en la nueva configuración del diseño.
En caso de que los cambios se inicien durante la fase de producción-
construcción, cuando se está produciendo gran cantidad de ítems idénti-
cos, necesita identificarse un ítem con la numeración serial designada para
indicar efectivamente, esto es, el cambio se incorporará en la línea de
producción en Número de Serie "X". Éste debe asegurar que todos los items
pertinentes planeados para producirse en el futuro reflejarán automáti-
camente la configuración actualizada.
Para aquellos componentes del sistema que están ya en uso, los cambios
pueden incorporarse mediante la instalación de un conjunto de modificacio-
nes en el área del lugar operacional del consumidor. Tales conjuntos se
instalan y el sistema se prueba para verificar una adecuación del cambio.
Al mismo tiempo, la capacidad de soporte del sistema (por ejemplo, equipo
de prueba, repuestos, datos técnicos) necesita actualizarse por compatibi-
lidad con los segmentos esenciales orientados a la misión del sistema.
Óptimamente, el proceso de instalación debe tener lugar en el tiempo en el
que el sistema no está en demanda o no se está utilizando en el desempeño
de una misión.
Este proceso global se ilustra en la figura 5.7. Con la incorporación de los
cambios aprobados, se actualiza la configuración del sistema y se establece
una nueva base. En situaciones donde la adecuación del cambio no se
verifica, puede requerirse un rediseño adicional.

S.S. RESUMEN

Este capítulo trata especialmente la revisión básica, la evaluación y el


proceso de retroalimentación ilustrados en la figura 1.9. Este proceso que es
crítico en relación con los objetivos de la ingeniería de sistemas, debe ser
confeccionado con base en el esfuerzo de desarrollo específico del sistema
¡y debe controlarse adecuadamente! Es esencial una actividad de medición
y evaluación continua, y debe iniciarse desde el principio. Realizar una
PREGUNTAS Y PROBLEMAS 233

revisión y una evaluación puntuales después de que el sistema ha sido pro-


ducido, y está en uso operacional, puede ser en costos o en términos de posi-
bles modificaciones para la acción correctiva. Asimismo, la incorporación
de los cambios del diseño en forma continua sin el control adecuado puede
ser costosa desde el punto de vista del soporte del sistema. En esencia, debe
haber un enfoque de programa bien planeado, con el control adecuado, a fin
de asegurar una configuración integrada del sistema hasta el final.

PREGUNTAS Y PROBLEMAS

1. Describa las "verificaciones" y "balances" en el proceso de diseño (ya


vistos).
2. ¿Cómo se realiza la revisión y evaluación del diseño? ¿Por qué es de
relativa importancia cumplir los objetivos de la ingeniería de sistemas?
3. ¿Qué se incluye en el establecimiento de una base "funcional"? ¿Base
"asignada"? ¿Base de "producto"? ¿Cuál es la importancia de la adminis-
tración de la base?
4. Seleccione un sistema y construya un diagrama de flujo secuencia¡ del
proceso de desarrollo global del sistema. Identifique los trabajos más
importantes del desarrollo del sistema y desarrolle un plan-bitácora de
las revisiones formales del diseño. Describa brevemente qué se cubre
en cada una.
S. Identifique algunas de las ventajas derivadas a partir de la revisión
formal del diseño. Describa algunos de sus problemas.
6. Cuando se desarrolla una agenda al preparar la revisión del diseño
formal, ¿qué consideraciones deben tratarse en la selección de los ítems
que habrán de cubrirse en el proceso de revisión? ¿ Cómo se identifican
los criterios de revisión y evaluación? Describa los pasos y los recursos
requeridos al preparar la revisión del diseño.
7. ¿Cómo se consideran las medidas de desempeño técnico (TPMs) en el
proceso de revisión del diseño?
S. En el caso de que una deficiencia se identifique durante la revisión del
diseño, ¿qué pasos se requieren para la acción correctiva?
9. ¿Cómo se inician los cambios de diseño? ¿Cómo se establecen las
prioridades?
10. ¿Cómo se implementan los cambios del diseño? Identifique los pasos
involucrados en la modificación del sistema.
11. Describa las funciones del CCB.
234 REVISIÓN Y EVALUACIÓN DEL DISEÑO

12. ¿Qué es administración de la configuración (CM)? Defina identificación


de la configuración (CI) y contabilidad del estado de configuración
(CSA).
13. ¿Cómo se relaciona la administración de la configuración (CM) con la
ingeniería de sistemas? ¿Por qué es importante? ¿Qué es posible que
ocurra si no se siguieron las prácticas de administración de la configu-
ración?
PLANEACIÓN DE LA INGENIERÍA
DE SISTEMAS

La clave para la implementación exitosa de cualquier programa es la


planeación inicial. La planeación para las actividades de la ingeniería de
sistemas, discutidas a través de los primeros cinco capítulos de este texto,
comienza desde el inicio del programa. Una vez que se identifica la necesi-
dad de un sistema y se realizan los estudios de factibilidad para seleccionar
un enfoque de diseño técnico, deben establecerse los requerimientos para
definir una estructura del programa que pueda implementarse con objeto
de crear el sistema.
La planeación comienza con la definición de los requerimientos del
programa. Se identifican las funciones de la ingeniería de sistemas y los
trabajos, se define una estructura desglosada de los trabajos que se han de
desarrollar, se preparan los planes de programas, se define una estructura
organizacional, se describen las políticas claves y los procedimientos y se
prepara e implementa un plan de administración de ingeniería de sistemas
(SEMP). El SEMP, que generalmente se desarrolla durante el diseño concep-
tual y la fase de avance de la planeación, cubre todas las actividades de
administración de la ingeniería de sistemas durante el ciclo de vida del
sistema, incluyendo aquellos relativos a los cambios ya las modificaciones
del sistema realizados posteriormente.
Este capítulo cubre la planeación de la ingeniería de sistemas, el primer
paso en la administración de sistemas ilustrado en la figura 6.1. El mate-
rial presentado lleva a la organización (capítulo 7) y a la contratación
y administración de los proveedores y a la integración del sistema (capítu-
lo 8). La implementación de los requerimientos descritos en los cinco
primeros capítulos depende en gran medida de la minuciosidad de la
actividad de planeación descrita aquí.
——-— i

1
t

u;
ca
E
u,
o,
o- - a
-o
-----
--oa
ca
a)
. . a)
o,
ca
a)
ca
1E
o
ca
a)
ca
a-

o,
2 E
-o -oca
ca
LL

Ilt
CP Ch

236
REQUERIMIENTOS DEL PROGRAMA DE INGENIERÍA DE SISTEMAS 237

6.1 REQUERIMIENTOS DEL PROGRAMA DE INGENIERÍA DE SISTEMAS

Al remitirse a la figura 6.1, el primer paso en el proceso de planeación


involucra la definición de los requerimientos del programa (o proyecto).
Aunque esto puede parecer bastante básico por naturaleza, cada programa
es diferente y es esencial que los requerimientos de la ingeniería de sistemas
se confeccionen acordemente. Los conceptos y métodos descritos en este
texto son aplicables en cada programa, pero la naturaleza y profundidad de
la aplicación puede variar de un programa al siguiente.

6. 1.1 Ea necesidad de planeación Inicial del sistema

Como se indicó en el capítulo 1, la implementación exitosa de los conceptos


de la ingeniería de sistemas depende, en gran medida, de: 1) emplear un
enfoque de arriba-abajo de los sistemas, 2) la integración inicial de las
actividades relacionadas con el diseño, 3) revisar los requerimientos en
términos de ciclo de vida del sistema y, 4) la preparación de la documenta-
ción completa de los requerimientos desde el inicio (por ejemplo, especifi-
caciones y planes). Conforme se generan los conceptos iniciales del sistema
y se realizan los estudios de factibilidad para determinar los enfoques
técnicos de las alternativas posibles del diseño, debe iniciarse el nivel
apropiado de planeación para asegurar que se llevan acabo, adecuadamen-
te integradas, las ideas generadas a partir del análisis en la configuración
final del producto, y de manera efectiva en cuanto a costos.
La planeación en la ingeniería de sistemas comienza desde el inicio del
programa durante la realización inicial del análisis de las necesidades
(descrito en la sección 2.1). Las actividades de comunicación con el con-
sumidor o el "usuario" se requieren a fin de asegurar que la necesidad
definida se interprete correctamente y que la traducción de la necesidad in-
dicada a la definición de los requerimientos sea conforme al sistema ¡Este es
un paso crítico en la definición inicial de los requerimientos del sistema,
y a menudo hay una laguna de comunicaciones y la necesidad real no se
entiende completamente. Esto, evidentemente, puede derivar en una con-
figuración de diseño que no satisfará las funciones como se intentó.
Dada la identificación y la descripción de la necesidad, el siguiente paso
involucra la realización de los estudios de factibilidad (véase la sección 2.2);
Son identificadas las futuras oportunidades tecnológicas y se investigan los
enfoques alternativos en términos de aplicaciones posibles para el diseño
y desarrollo del nuevo sistema. La factibilidad de cada alternativa está en
función no sólo del cumplimiento de los requerimientos deseados del
desempeño, sino que también debe responder a las siguientes preguntas:
238 PLANEACIÓN DE LA INGENIERÍA DE SISTEMAS

1. ¿Se definieron los requerimientos de los recursos asociados con


una alternativa dada (esto es, recursos humanos, materiales, da-
tos)? ¿Se identificaronlos las fuentes de suministro? ¿Estarán dispo-
nibles los recursos necesarios cuando se requieran?
2. ¿Las alternativas consideradas reflejan un enfoque efectivo en
cuanto a costos, basado en un análisis del ciclo de vida?
3. ¿Se ha realizado un análisis del efecto para determinar si hay
posibles consecuencias secundarias y (o) terciarias, como resulta-
do de seleccionar una alternativa dada? Con optimismo, la selección
de una alternativa específica no tendrá un efecto en detrimento de
los aspectos sociales, políticos y (o) ambientales. Además, deben
minimizarse las interacciones con los demás sistemas.

Es en esta etapa del ciclo de vida, cuando la planeación inicial de la


ingeniería de sistemas es importante. El esfuerzo de análisis se dirige hacia
el nivel de sistema; se identifican los proveedores potenciales; comienza
el proceso de integración global del sistema; se valoran los efectos de
interacción (internos y externos) y se describen las áreas potenciales
de riesgo. Así como la definición del sistema continúa a través del desa-
rrollo de los requerimientos operacionales y el concepto de manteni-
miento (véase la sección 2.3 y 2.4), el proceso de planeación evoluciona
a través de una serie de iteraciones. Los requerimientos para la integración
del sistema son más grandes en términos de integración técnica de los di-
versos elementos del sistema y de la integración de las diversas y variadas
entidades organizacionales involucradas en el desarrollo del sistema.
La planeación del sistema es continua, comenzando con la definición de
una necesidad y extendiéndose hasta el desarrollo del plan de la administra-
ción de la ingeniería de sistemas (SEMP). Se definen los requerimientos al
nivel de sistema, y se desarrolla el proceso de planeación para identificar
aquellas actividades que puedan realizarse a fin de proporcionar un sistema
que satisfará estos requerimientos. El diseño y las decisiones de administra-
ción, en esta etapa del ciclo de vida del sistema, tienen una gran influencia
en las actividades tardías del programa. De este modo, es esencial que se
implemente un completo y bien integrado esfuerzo de planeación desde el
inicio.

6.1.2 Determinación de los requerimientos del programa

Aunque los conceptos, los métodos y los procesos que describen la ingenie-
ría de sistemas son aplicables generalmente en todas las categorías de los
sistemas, ellos pueden "confeccionarse" para cada aplicación individual.
Adicionalmente, las aplicaciones son numerosas y variadas:
REQUERIMIENTOS DEL PROGRAMA DE INGENIERÍA DE SISTEMAS 239

1. Los sistemas en gran escala, con muchos componentes diversos,


tales como un sistema del espacio, un sistema de transportación
urbano, un sistema de un generador de energía hidroeléctrica,
etcétera.
2. Los sistemas pequeños, con relativamente pocos componentes,
tales como un sistema de comunicaciones local, un sistema de
cómputo, un sistema hidráulico, un sistema mecánico de frenos,
etcétera.
3. Los sistemas en los que hay una gran cantidad de nuevo diseño y el
esfuerzo de desarrollo requerido, es decir, la aplicación de nuevas
tecnologías.
4. Los sistemas cuyo diseño se basa esencialmente en la utilización de
componentes existentes estándar disponibles en almacén.
5. Los sistemas que son altamente intensivos en equipo, intensivos en
software, intensivos en instalaciones, o intensivos en humanos; por
ejemplo, un sistema de producción contra un sistema de comando
y control, contra un sistema de distribución de datos, contra un
sistema de mantenibiliclad.
6. Los sistemas en los que hay un gran número de proveedores
involucrados en el diseño y desarrollo del proceso, ambos a nivel
nacional e internacional.

Sistemas Sistemas (de Sistemas de


(aeronáuticos) comente) procesamiento
del espacio aéreo hidroeléctricos de datos

Sistemas (civiles)
1 Sistemas
urbanos I•'._. electrónicos

Requerimientos
de la ingeniería
de sistemas

Sistemas de Sistemas de
comunicaciones F ,'r"\ transporlación

Sistemas 1 Otros 1
1
Sistemas de
(manufactura)
de marina sistemas
1 producción

Figura 6.2. La aplicación de los requerimientos de la ingeniería de sistemas.


240 PLANEACIÓN DE LA INGENIERÍA DE SISTEMAS

7. Los sistemas en los que es mínimo el número de organizaciones


diferentes involucradas en el proceso de diseño y desarrollo.
8. Los sistemas que se diseñan y desarrollan para utilización en el
sector gubernamental contra el sector privado, etcétera.

Aunque este texto básicamente sólo se ocupa de las categorías más,


importantes de los sistemas descritos en el capítulo 1 (esto es, el sistema
hecho por el hombre, el sistema de lazo abierto, el sistema dinámico), hay
aún una gran variedad de aplicaciones, como las ilustradas en la figura 6.2.
En cada situación individual, es aplicable el proceso de ingeniería de
sistemas descrito en el capítulo 2. Aunque la extensión y profundidad del
esfuerzo variarán, los pasos requeridos para crear el sistema son básica-
mente los mismos. Se realiza un análisis de necesidad y algún análisis de fac-
tibilidad, se definen los requerimientos operacionales del concepto de
mantenimiento de sistema y se concluyen el análisis funcional y la asigna-
ción de los requerimientos. Aunque uno puede ocuparse de un caso relati-
vamente simple, como un pequeño sistema conformado de componentes
estándar disponibles en los módulos correspondientes, es necesario aún
realizar el análisis de requerimientos arriba-abajo, realizar un análisis
funcional y de asignación, etc. En otras palabras, hay un requerimiento del
diseño del sistema, aunque el nuevo diseño puede no requerirse en el nivel
de componente.
Siguiendo los pasos generales indicados en la figura 1.7 (capítulo 1)
representan un buen enfoque global para el diseño y desarrollo de un nuevo
sistema. Conforme se avanza desde el análisis de las necesidades hasta la
realización de los estudios de factibilidad y la definición de los requeri-
mientos del nivel del sistema, el proceso evoluciona desde la identifica-
ción de los "qués" a los "cómos", es decir, qué se requiere en términos
de capacidad funcional del sistema, cómo se realiza ésta desde el punto
de vista de un enfoque técnico del diseño. La evaluación de respues-
tas iniciales para el enfoque técnico del diseño propuesto conduce a la
identificación de los requerimientos específicos del programa (o proyecto).
Los requerimientos del programa en este contexto se refieren al enfoque
de la administración y los pasos que deben seguirse en la consecución y(o)
creación del sistema, en respuesta a una necesidad indicada junto con la
identificación de los recursos requeridos para satisfacer este objetivo. Debe
establecerse una estructura del programa, la que hará posible el diseño
y desarrollo, producción y (o) construcción y liberación del sistema para el
consumidor, de manera efectiva en cuanto a costos. Esto incluye la identi-
ficación de las funciones del programa de trabajos detallados, el desarro-
llo de una estructura organizacional, el desarrollo de una estructura
desglosada de trabajos (WBS), la preparación de los planes del progra-
ma y laestimación de costos, la implementación de una capacidad de eva-
luación y el control del programa, etc. Esta información, presentada en
PLAN DE ADMINISTRACIÓN DE LA INGENIERÍA DE SISTEMAS (SEMP) 241

[Rn sistema
III
Consumidor-usuario
(cliente)

Contratista A Contratista B
(productor importante) (productor Importante)

Subcontratista A Subcontratista B" Subcontratista C

Proveedor Proveedor roveedor Proveedor Proveedor


del componente del componente d mponente del componente del componente
A B O E

Figura 6.3. Interfaces del consumidor, productor y proveedor

forma de plan de programa, proporciona la guía de administración día


por día requerida en la organización de un objetivo técnico.
Para satisfacer los objetivos de la ingeniería de sistemas descritos en los
capítulos anteriores de este texto, un plan de administración de ingenie-
ría de sistemas (SEMP) se desarrolla como parte de los requerimientos
iniciales de planeación para cada programa (véase la figura 6.1). Aunque
el contenido detallado puede variar de un paso al siguiente, algunas de las
características más importantes del SEMP se indican en la sección 6.2.

6.2 PLAN DE ADMINISTRACIÓN DE LA INGENIERÍA DE SISTEMAS (SEMP)

Al referirse a la figura 3.1, el SEMP se desarrolla a partir del plan de


administración del programa (PMP) y cubre todas las funciones de admi-
nistración asociadas al desempeño de las actividades de la ingeniería de
sistemas para un programa dado.' Un SEMP, que debe prepararse para cada

Para fines de discusión se asume que el PMP representa el documento de alta administración
para el programa. En términos de la jerarquía de la documentación, el SEMP debe representar
el documento de alta planeación de la ingeniería, complementando al PMP.
242 PLANEACIÓN DE LA INGENIERÍA DE SISTEMAS

programa, constituye el plan del ingeniero jefe para identificar e integrar


todas las actividades más importantes de la ingeniería.
La preparación del SEMP es responsabilidad del "administrador de
sistemas" y puede ser realizado por el consumidor-usuario (el "cliente")
o por un contratista importante, dependiendo del programa. Las relacio-
nes entre el consumidor, los contratistas esenciales o los productores más
importantes, los contratantes, los proveedores, etc., particularmente
para los sistemas en gran escala pueden tomar la forma de la ilustración
en la figura 6.3. En tales casos, el consumidor-usuario es responsable de la
preparación del SEMP, pero puede delegar la integración global del sistema
y la responsabilidad de la administración a un contratista principal.
En caso de que el consumidor prepare el SEMP, el Contratista"A" y el
Contratista "B" deben preparar un SEMP que cubra sus respectivas activi-
dades de ingeniería de sistemas, cada uno en respuesta al plan de nivel más
alto. Por otra parte, si la integración del sistema y la responsabilidad de la
administración se delega al contratista "A" (por ejemplo), entonces la res-
ponsabilidad de la preparación del SEMP y de la implementación de las
actividades definidas aquí serán en este nivel .2
¡Esta discusión puede parecer, inicialmente, bastante trivial! No obstan-
te, si el SEMP debe ser completamente significativo y realizar sus objetivos,
debe desarrollarse directamente desde el plan de administración de alto
nivel. Adicionalmente, la responsabilidad del SEMP y de la realización de las
funciones de trabajos descritos aquí, deben definirse claramente y estar
apoyados por el administrador (o director) del programa. Cuando la respon-
sabilidad de la administración del sistema se delega al contratista "A", de la
figura 6.3, entonces el contratista "A" debe delegar tanto la responsabilidad
como la autoridad de realizar todas las funciones del nivel del sistema
(descritas en el SEMP) de parte del contratista "B", así como también a todos
los contratistas y proveedores pertinentes. Finalmente, el SEMP debe
identificarse adecuadamente como el plan clave del diseño de ingeniería en
el árbol de documentación global del programa.
En términos del contenido del material, el SEMP debe confeccionarse de
acuerdo con requerimientos del sistema, el tamaño y complejidad del pro--
grama y la consecución o fase de creación. Inicialmente, el SEMP se prepara
durante la fase de diseño conceptual y la fase de avance de la planeación,
e incluye la cobertura de toda actividad de la ingeniería de sistema planeada
desde encima de eso. Conforme avanza el proceso de desarrollo de sistema,
el SEMP se actualiza para reflejar los nuevos requerimientos del programa
y los cambios en el énfasis de las actividades.
A fin de proporcionar una indicación de la naturaleza de la información
incluida en el SEMP, se presenta la figura 6.4 para ilustrar un ejemplo de un

2
En tales casos, el SEMP se prepara y concluye usualmente como parte de la propuesta del
contratista para el consumidor.
PLAN DE ADMINISTRACIÓN DE LA INGENIERÍA DE SISTEMAS (SEMP) 243

enfoque. En este caso, el SEMP está organizado en tres partes importantes.


La parte 1 incluye el alcance de la planeación más tradicional del progra-
ma, la organización, la implementación y control así como las funciones
asociadas con la administración. La parte II describe el proceso de ingenie-
ría de sistemas presentado en el capítulo 2. La parte III cubre la integración
de las muy diversas disciplinas de 14 ingeniería de diseño introducidas en
el capítulo 3. Este enfoque bastante general se amplía bastante a través del
ejemplo de esbozo temático presentado en la figura 6.5. Aunque el autor
no intenta discutir cada tema en el esbozo del SEMP detallado, se identifica-
ron unas pocas áreas seleccionadas para su discusión adicional.3

6.2.1 Descripción del trabajo (SOW)

La descripción del trabajo (SOW) es una descripción narrativa del trabajo


requerido para un proyecto determinado.
En relación con el SEMP, ésta debe desarrollarse a partir del proyecto
global SOW descrito en el PMP, y debe incluir lo siguiente:

1. Una descripción resumida de los trabajos que se realizan. Una iden-


tificación de los trabajos de ingeniería de sistemas más impor-
tantes que se presenta en la sección 6.2.2. Estos, a su vez, deben
apoyarse en los elementos de trabajo incluidos en la estructura de
descomposición de los trabajos (WBS), vista en la sección 6.2.3.
2. Una identificación de los requerimientos de entrada desde otros
trabajos. Esto puede incluir los resultados de otros trabajos realiza-
dos en el proyecto, los trabajos concluidos por el cliente y (o) los
trabajos realizados por un proveedor.
3. Las referencias para las especificaciones pertinentes (para incluir la
especificación "A" del sistema), los estándares, los procedimientos
y la documentación relacionada que sea necesaria para la conclu-
sión del alcance definido del trabajo. Estas referencias deben in-
cluirse como los requerimientos claves en el árbol de la documen-
tación descrito en la sección 6.2.4.
4. Debe realizarse una descripción de los resultados específicos. Esto
puede incluir el equipo que habrá de liberarse, el software, los datos
del diseño, los reportes y (o) la documentación relacionada, junto
con el plan propuesto de liberación, tal como se presenta en la sec-
ción 6.2.5.

Las bases para el esbozo de tres-partes se desarrolla desde MIL-STD-499A, Military Standard,
"Engineering Management" U.S. Air Force-Air Force Systems CommandAndrewsAFB, Maryland;
y Defense Systems Management College, Systems Engineering Management Guide, DSMC, Fort
Belvoir, Virginia. Los temas detallados que se presentan en la figura 6.5 representan una
explicación desarrollada por el autor.
o
-. [i

244

PLAN DE ADMINISTRACIÓN DE LA INGENIERÍA DE SISTEMAS (SEMP) 245

1.0 Panorámica

2.0 Propósito y alcance

3.0 Aplicación(es)

4.0 Planeación técnica del programa, implementación y control (Parte 1)

4.1 Introducción
4.2 Requerimientos del programa-descripción del trabajo
4.3 Organización (organización del proyecto, organización funcional, responsabilidad y autoridad
organizacional, interrelaciones y comunicación organizacional, relaciones y control del proveedor)
4.4 Planeación del programa (árbol de especificaciones, estructura de descomposición del trabajo,
planes y(o) tablas de indicadores de programa-proyecto)
4.5 Interfaz técnica de administración (relaciones entre las entidades internas organizacionales,
administración del proveedor y (o) subcontrasta)
4.6 Medidas de desempeño técnico (identificación de las medidas de desempeño técnico, así como
el seguimiento)
4.7 Costo del programa (proyecciones-reporte)
4.8 Revisión del diseño y auditoría técnica (revisiones técnicas, revisiones formales, revisiones del
proveedor-subcontrasta)
4.9 Comunicaciones técnicas (reportes y documentación del programa, monitoreo y control)
4.10 Administración de la configuración
4.11 Administración de los riesgos (identificación del riesgo, evaluación del riesgo y disminución)

5.0 Proceso de la ingeniería de sistemas (Parte II)

5.1 Análisis de las necesidades del sistema y estudio de factibilidad


5.2 Requerimientos operacionales del sistema
5.3 Concepto de mantenimiento
5.4 Análisis funcional
5.5 Distribución de los requerimientos
5.6 Síntesis del sistema y análisis de compromisos
5.7 Integración y soporte del diseño
5.8 Prueba y evaluación del sistema
5.9 Soporte de producción-construcción
5.10 Modificaciones al sistema (habilitación y control de cambio)

6.0 Integración de las especialidades de la ingeniería (Parte III)

6.1 Especialidades de la ingeniería (identificación de las especialidades claves de la ingeniería, que


son aptas para el proceso de la ingeniería de sistemas y sus relaciones con cada una de las otras)
6.2 Descripción de las especialidades individuales de la ingeniería (objetivo, organización, descripcio-
nes de trabajos, planes, etc., para el área significativa de la especialidad)

6.2.1 Efectividad del sistema


6.2.2 Ingeniería de confiabilidad
6.2.3 Ingeniería de mantenibilidad
6.2.4 Ingeniería de factores humanos
6.2.5 Ingeniería logística
6.2.6 Ingeniería de software
6.2.7 Ingeniería de calidad
6.2.8 Ingeniería de valuación-costos
6.2.9 Capacidad de producción
6.2.10 Otras disciplinas de la ingeniería (según sea apropiado)

7.0 Referencias (especificaciones, estándares, planes y otras referencias pertinentes-documentación)

Figura 6.5. Esbozo del plan de la administración de la ingeniería de sistemas (ejemplo).


246 PLANEACIÓN DE LA INGENIERÍA DE SISTEMAS

Al preparar un SOW, las guías generales siguientes se consideran


apropiadas.

1. El SOW debe ser relativamente corto e ir al grano (no debe exceder


de dos páginas), y debe estar escrito de manera clara y precisa.
2. Se deben hacer todos los esfuerzos para evitar ambigüedad y la
posibilidad de malas interpretaciones por parte del lector.
3. Describir los requerimientos con bastante detalle para asegurar
claridad considerando las aplicaciones prácticas y las interpreta-
ciones legales posibles. No especifique poco ni demasiado.
4. Evite la repetición innecesaria y la incorporación de material
y requerimientos extraños. Esto es probable que ocasione un costo
innecesario.
S. No repita las especificaciones y requerimientos detallados que ya
están cubiertos en la documentación referenciada aplicable.

El SOW será leído por muchas personas diferentes con una variedad de
experiencias (por ejemplo, ingenieros, contadores, administradores con-
tractuales, planeadores, abogados) y no debe haber preguntas sin res-
puesta, de acuerdo con el alcance deseado de trabajo. Esto constituye una
base para la definición y costos de los trabajos detallados, para el estable-
cimiento de los requerimientos del subcontratista y proveedor, etcétera.

6.2.2 Definición de las funciones y trabajos de la Ingeniería de sistemas

La ingeniería de sistemas, definida en este texto, cubre un gran espectro de


actividades; incluso puede parecer que el "ingeniero de sistemas", o la
organización de la ingeniería de sistemas, ¡hace todas las cosas! Aunque esto
no es práctico, el satisfacer los objetivos de la ingeniería de sistemas
requiere un involucramiento, directa o indirectamente, en casi cada faceta
de actividad del programa. El reto es identificar aquellas funciones (o
trabajos) que se ocupan del sistema global como una entidad y, cuando se
concluya exitosamente, tendrá un efecto positivo en la mayoría de los
trabajos relacionados y subordinados que deben realizarse.
Con la intención de identificar un número selecto de trabajos cla-
ves para la ingeniería de sistemas, el proceso descrito en el capítulo 2
puede considerarse un marco para discusiones adicionales. Como princi-
pio, es adecuada una revisión de algunas de las metas básicas globales.
Los objetivos de la ingeniería de sistemas son:

1. Asegurar que los requerimientos para el diseño y desarrollo del


sistema, prueba y evaluación, producción, operación y soporte se
PLAN DE ADMINISTRACIÓN DE LA INGENIERÍA DE SISTEMAS (SEMP) 247

desarrollen de manera oportuna mediante un análisis de requeri-


mientos iterativos de arriba-abajo.
Asegurar que las alternativas del diseño del sistema sean evaluadas
adecuadamente, en contraste con los criterios significativos,
cuantificables que se relacionan con todas las características de-
seadas; por ejemplo, factores de desempeño, factores de efectivi-
dad, características de confiabilidad y mantenibilidad, factores
humanos y factores de seguridad, características de la capacidad
de soporte y costo del ciclo de vida.
3. Asegurar que todas las disciplinas de diseño aplicables y áreas de
especialidad relacionada están adecuadamente integradas en el
esfuerzo total de la ingeniería, de manera oportuna y efectiva.
4. Asegurar que el esfuerzo global de desarrollo del sistema progrese
de manera lógica con las bases de configuración establecidas, las
revisiones del diseño formal, la propia documentación que sustenta
las decisiones del diseño y las provisiones necesarias para la acción
correctiva como se requiera.
S. Asegurar que los diversos elementos (o componentes) del sistema
sean compatibles con cada uno de los otros elementos y se combi-
nen para proporcionar una entidad que desempeñará sus funcio-
nes requeridas de manera efectiva y eficiente.

Revisión de aquellas metas generales que llevan a la pregunta: ¿Qué


trabajos detallados del programa-proyecto deben desempeñarse a fin de
cumplir con éxito los objetivos de la ingeniería de sistemas? Aunque cada
programa individual es diferente y las actividades deben diseñarse en la
forma correcta, se considera que los siguientes trabajos deben ser aplica-
bles a muchos casos:

1. Realice un análisis de necesidades y lleve a cabo los estudios de


factibilidad (véase las secciones 2.1 y 2.2). Estas actividades deben ser la
responsabilidad de la organización de la ingeniería de sistemas, ya que ellas
se ocupan del sistema como una entidad y son fundamentales en la interpre-
tación inicial y la definición subsecuente de los requerimientos del sistema.
2. Defina los requerimientos operacionales del sistema y el concepto
de mantenimiento del sistema (véase las secciones 2.3 y 2.4). Los resulta-
dos de estas actividades están incluidos en la definición global de los
requerimientos y nivel del sistema y son las bases para el diseño del sistema
de arriba-abajo.
3. Prepare la especificación Tipo "A" del sistema (véase la sección 3.1).
Esto representa el documento técnico de alto nivel para el diseño del siste-
ma y que satisface los objetivos de la ingeniería de sistemas dependiendo de
248 PLANEACIÓN DE LA INGENIERÍA DE SISTEMAS

la perfección y alcance de la especificación. Las especificaciones "B", "C",


"D" y "E" están basadas en los requerimientos de la especificación "A".
4. Prepare el plan maestro de prueba y evaluación (véase la sección 2.8).
Este documento refleja el enfoque, los métodos y los procedimientos que
deben seguirse en la evaluación global del sistema en términos de conformi-
dad con los requerimientos especificados inicialmente. Aunque hay diver-
sas pero relativamente pocas facetas de prueba, es la compilación de éstas
lo que proporciona una evaluación global del sistema como una entidad.
S. Prepare el plan administración de ingeniería de sistemas (véanse las
secciones 1.3 y 6.2). Esto, evidentemente, representa el documento de alta
administración para todas las actividades del programa de ingeniería de
sistemas.
6. Realice el análisis funcional y la asignación de los requerimientos
(véanse las secciones 2.5 y 2.6). El análisis funcional, que representa el
proceso de traducir los requerimientos del nivel del sistema a criterios de
diseño detallados, proporciona las bases para el desarrollo de los diver-
sos trabajos disciplinarios del diseño individual (véase la sección 2.5.4).
El proceso de asignación define los requerimientos específicos de diseño
para los diversos componentes del sistema, si se desarrollan a través de
las actividades del subcontratista o se consiguen de las disponibles en
almacén. En cualquier caso, la responsabilidad para este esfuerzo es ade-
cuada, ya que facilita el esfuerzo necesario de integración del diseño para
proporcionar una base común de la definición del sistema en términos
funcionales.
7. Realice el análisis del sistema, la síntesis y las funciones de inte-
gración del sistema en forma continua durante el proceso global de diseño
y desarrollo (véase las secciones 2.7 y 2.8 y el capítulo 3). La integración
del sistema es iterativa por naturaleza e incluye ambas consideraciones
técnicas que ejecutan las interfaces físicas y funcionales del equipo, del
software, del personal, de las instalaciones, etc., y las consideraciones de
administración que pertenecen a las interfaces organizacionales. A partir
de la perspectiva de administración, la organización de ingeniería de
sistemas es responsable de asegurar que: a) se definan inicialmente todas
las funciones trabajos relacionadas con el diseño del programa; b) se
establezcan las responsabilidades pertinentes y las relaciones de trabajo;
c) estén identificados los canales de la organización y de comunicación;
y d) estén concluidos, de manera satisfactoria, los requerimientos del
programa. En relación con el capítulo 3, la organización de la ingeniería
de sistemas es responsable de asegurar que el nivel adecuado de comunica-
ciones, coordinación e integración, existan entre las diversas disciplinas
de diseño descritas aquí. De particular interés son los requerimientos de
trabajos para la ingeniería de confiabilidad (figura 3.11), la ingeniería
de rnantenibilidad (figura 3.15), la ingeniería de factores humanos (figu-
ra 3.19) y la ingeniería de seguridad (figura 3.21), soporte logístico (fi-
PLAN DE ADMINISTRACIÓN DE LA INGENIERÍA DE SISTEMAS (SEMP) 249

gura 3.23), la ingeniería de software (sección 3.2.6), la ingeniería de la


capacidad de producción (sección 3.2.7), la ingeniería de calidad (sección
3.2.8) y la ingeniería valor-costo (sección 3.2.9).
8. Planee, coordine y lleve a cabo la revisión formal del diseño, por
ejemplo, la revisión conceptual del diseño, las revisiones del diseño del
sistema, las revisiones del diseño de equipo-software y la revisión crítica
del diseño (véase el capítulo 5). La organización de la ingeniería de sistemas
es responsable de asegurar que se desarrolle un esfuerzo continuo de
evaluación del diseño. Esto se realiza parcialmente por medio de la planeación
de las juntas periódicas de revisión del diseño. La conducción de estas
juntas debe realizarse por una persona imparcial y los resultados globales
deben soportar los objetivos del diseño del nivel del sistema.
9. Monitoree y revise las actividades de prueba y evaluación del sistema
(véase la sección 2.8). Es esencial que la organización de la ingeniería de
sistemas esté involucrada desde el punto de vista de la interpretación
e integración de los resultados de la prueba individual en la evaluación del
sistema, como un conjunto.
10. Planee, coordine, implemente y controle los cambios del diseño
conforme ellos evolucionen a partir de las propuestas de cambios de la in-
geniería (ECPs) iniciados desde la actividad de revisión informal día por día,
o bien como resultado de las revisiones formales del diseño (véase la sec-
ción 5.4). La organización de la ingeniería de sistemas es responsable
de establecer y mantener las "bases" del sistema a través del proceso del
diseño y desarrollo, por ejemplo, la base "funcional", la base "asignada"
ylabase "del producto" en la figura 1.8. La ingeniería de sistemas es
responsable esencialmente de la administración de la configuración con-
forme el sistema evoluciona a través de su ciclo de vida planeado.
11. Inicie y mantenga el enlace de producción-construcción y de las
actividades de servicio al cliente. Conforme avanza la configuración del
sistema, desde la fase del diseño y desarrollo hasta la producción y (o)
construcción y, posteriormente, al uso operacional, hay un requerimiento
para un nivel especificado de soporte de la ingeniería. El propósito es
proporcionar una relativa ayuda a la ingeniería para entrenamiento
y entendimiento del diseño del sistema, la incorporación de los cambios
aprobados de ingeniería en el sistema y la creación de los datos a partir de
las actividades de producción y las operaciones del consumidor en esta
área. La organización de la ingeniería de sistemas debe hacer posible dar
seguimiento al sistema durante su ciclo de vida planeado.

Los 11 trabajos básicos del programa descritos arriba constituyen un


ejemplo de lo que podría ser apropiado para un programa típico, aunque los
requerimientos específicos pueden variar de un programa al siguiente.
La meta es identificar los trabajos que están orientados hacia el sistema
y que son críticos al referirse al cumplimiento de los cinco objetivos más
250 PLANEACIÓN DE LA INGENIERÍA DE SISTEMAS

importantes de la ingeniería de sistemas indicados anteriormente. Más


específicamente, es importante que se siga un enfoque global de los sis-
temas, desde el establecimiento inicial de los requerimientos del sistema.
Conforme avanza el diseño, es importante que la configuración del
sistema que se desarrolla incluya las características deseadas. Finalmente,
es importante que el producto de salida se verifique en términos de que
cumpla los requerimientos establecidos inicialmente.
Al realizar esto, hay trabajos de definición de los requerimientos, hay
trabajos de revisión y aprobación del diseño, hay trabajos de control de la
configuración y trabajos de prueba y evaluación final. Estas actividades se
realizan a través de la combinación del aprovisionamiento de la docu-
mentación clave (especificaciones, planes y reportes), la realización cui-
dadosamente planeada de las revisiones del diseño planeado con las
provisiones de retroalimentación adecuadas, así como el porporcionar
los esfuerzos continuos de integración y coordinación necesarios.
Estas actividades deben tratar todas las funciones realizadas a través de
los diversos niveles descritas en la figura 6.3.
Al revisar los 11 trabajos propuestos, se advierte que la organización
de la ingeniería de sistemas per se no puede ser capaz de concluir con éxito
todo el trabajo requerido. Asimisrnp, no se intenta justificar una gran
organización para trabajar los detalles. No obstante, la organización de la
ingeniería de sistemas, a través de sus aspectos técnicos del nivel del
sistema y sus habilidades de liderazgo, debe tomar la iniciativa y asegurar
que se concluyan de manera oportuna estos requerimientos de trabajo.
Este enfoque organizacional se discute suficientemente en el capítulo 7.
A fin de proporcionar un entendimiento más profundo de los 11 traba-
jos, la figura 6.6 presenta una lista resumida de ellos, y muestra los requeri-
mientos comunes de entrada y de salida. Mientras que la mayoría de los
requerimientos de entrada-salida se explican por sí mismos mediante
la revisión de las secciones apropiadas de este texto, es necesaria una
discusión adicional, en apoyo a los requerimientos de salida del trabajo 6
que se ocupa del análisis funcional y de la asignación.
El análisis funcional abarca el proceso de traducir los requerimientos
del nivel del sistema a criterios detallados de diseño, y da como resultado
la definición completa de la configuración del sistema en términos funciona-
les (véase la sección 23). La realización del análisis funcional se facilita
a través del desarrollo de diagramas de flujo de bloques funcionales, descri-
tos en la sección 2,5.1. A partir de estos diagramas, el ingeniero de sistemas
puede desear evaluar las diversas funciones a profundidad, desde el punto
de vista de relaciones en serie-en paralelo, duraciones de tiempos y, por
último, la identificación de los requerimientos del recurso más importante.
Además, los requerimientos funcionales específicos deben comunicarse al
personal del programa-proyecto por medio de las hojas de análisis de
tiempos, las hojas de asignación de los requerimientos (RASs), los reportes
Trabajos de La Ingeniería de sistemas Requerimientos de Es trabajos de erirada Requerimientos de trabajos de salida

1. Realice tm análisis delas La documentación de los requenmierilos del consumidor-cliente; repones de información técnica que cubren las Reportes de estudio defactEilióad; reportes delesui-
necesktades y leve a cabo los aplicaciones de la tecnología; los reportes seleccionados de investigación; los repones de estudios de compromisos que dio de compromisos que justifica las decisiones del
estudios de 1actibióad. apoyan el entoque del diseño. diseño del nivel del sistema.

2. Delina los requerimientos La documentación de los requerimientos del cormumidor-cllenle; las especificaciones y estándares del cliente; tos Documentación de Es requerimientos del sistema
operacionales y el concepto de reportes de Es estudios de tactbltidad: Es reportes del estudio de compromisos que sustentan el planteamiento del (requerimientos operacionales y concepto de mame-
manterumiento del sistema. diseño. nnlento); reportes del estudio de compromisos que
justifica las decisiones del diseño del nivel del sis-
tema.

3. Prepare la especificación Tipo A del Los repodes de información técnica que cubren las aplicaciones de la tecnología; Es reportes de los estudios de Especificación Tipo A del sistema.
sistema. factibilidad; la documentación de los requerimientos del sistema (los requerimientos operacionales y el concepto de
mantenimiento): los reportes del estudio de compromisos que jietñca las decisiones del diseño del nivel del sistema.

4. Prepare el plan maestro de prueba y La especificación Tipo A del sistema: las especificaciones y Es estándares de prueba del cliente; la personalización de Plan maestro de prueba y evaluación (TEMP).
evaluación (TEMP). los requerimientos de prueba (requerimientos de prueba individual de la discçltna).

5. Prepare el plan de administración de La documentación de los requerimientos del consinldorctlente; las especificaciones y tos estándares del programa del Plan de administración de la ingeniada de sistemas
la ingeniería de sistemas (SEMP). cliente; la documentación de los requerimientos del sistema lrequedmletlos operacionales y concepto de mantenimien- (SEMP).
lo); especificación Tipo A del sistema; plan maestro de prueba y evaluación (TEMP): información de avance de la
planeación del sistema; plan de administración del programa (PMP).

6. Realice el análisis funcional yla La documentación de Es requerurnierifos del sistema; (requermileilos operacionales y concepto de mantenimiento); Reportes de análisis funcional-diagramas de flto
asignación de Es requerimientos. especificación Tipo Adel sistema; reportes del estudio de compromisos, que justifica las decisiones del diseño del nivel funcionales (funciones operacionales y de rnantenl-
del sistema. miento), hojas de análisis de tiempos, hojas de la
distribución de Es mequervnientos (RASs), reportes
de estudio de compromisos, hojas de Es requefl
mientas de prueba, hojas de Es crifenos del diseño.

7. Realice el análsis, la síntesis y la La documentación de Es requerimientos del consumidor-cliente; las especificaciones y Es estándares del cliente; Es Datos seleccionados deldisefio; repolles de Integra-
Integración del sistema. reportes delanábsis luncional; la especificación Tipo A del sistema: el plan de administraciónde la ingeniería de sistemas ción del sistema; datos y reportes del proveedor,
(SEMP); plan maestro de prueba y evaluación (TEMP): requerimientos cte planeación del programa de las disciplina reportes del estudio de compromisos que juatltica las
individual del diseño. decisiones del diseño. repodes de la dlsclØna selec-
cionada del dEslio (predicciones y análisis).

8. Planee, coordine y conduzca las Plan de administración del programa (PMP); plan de administración de la ingeniada as sistemas (SEMP); datos Mirnias de las justas de revisión deldisefio, lisias de
Juntas de revisión formal del diseño. aplicables del diseño (dibujos, listas de palles y de material, repolles, bases de datos): reportes del eslido de las acciones de los fiems con las resporreabllidades
compromisos que justifican las decisiones del diseño; reportes de la disciplina Individual del diseño (predicciones, designadas. Datos aprobados-distribuidos detdiseño
análisis, etcétera). y docirrerlación de apoyo.

. Monloree y revise las actividades de Plan maestro de prueba y evaluación (TEMP), plan de administración de la ingeniada de sistemas (SEMP); datos de Reportes de prueba y evaluación del sistema.
prueba y evaluación del sistema, prueba individual y reportes.

10. Planee, coordine, habilite y controle Dados de administración de la configuración y reportes (descripción de la base del diseño), propuestas de cambios de Reporte(s) de prueba y evaluación del sistema.
los cambios del diseño. la irigenierta; propuestas de requerwtsenlos del control de cambio y acciones.
Planes de habilitación del cambio, datos-reportes de
11. Inicie y mantenga la unión de Datos de diseño del sistema; requerimientos de producción-construcción: cambios aprobados del diseño; procedimien- verificación del cambio,
producción-construcción y las tos de operación y mantenimiento del sistema: operaciones consumidor-cliente y requerimientos de utilización del Datos de campo y reportes de fallas; reportes del
actividades del servicio al cliente, sistema; datos de campo y reportes de tallas, servicio al cliente en el área de operaciones.

Figura 6.6. Trabajos de la ingeniería de sistemas.


252 PLANEACIÓN DE LA INGENIERÍA DE SISTEMAS

de estudios de compromisos, las hojas de los requerimientos de prueba, las


hojas de los criterios del diseño y similares. Las hojas de los análisis de
tiempos y las hojas de asignación de requerimientos se discuten brevemen-
te, más adelanta.

1. Hojas de análisis de tiempo. Aunque los diagramas de bloque funcio-


nales conducen a las relaciones generales en serie-paralelo, estos requeri-
mientos pueden desarrollarse a profundidad mediante el uso de las hojas de
análisis de los tiempos. Los análisis de tiempos añaden un considerable
detalle al definir las duraciones de las diversas funciones. La concurrencia, la
superposición y las relaciones secuenciales de las funciones —traba-
jos pueden proyectarse. También las funciones de tiempo critico pueden
identificarse en seguida; esto es, aquellas funciones que afectan directamen-
te la disponibilidad del sistema, el tiempo de operación y el tiempo de
mantenimiento. Un ejemplo de la hoja de análisis de tiempos se presenta en
la figura 6.7.
2. Hojas de asignación de los requerimientos (RAS). La hoja de asigna-
ción de los requerimientos (RASs) se emplea a menudo como el documento
esencial para la identificación de los requerimientos específicos basados en
el análisis funcional. Un RASs se desarrolla para cada bloque en el diagrama
de bloque de flujo funcional. Los requerimientos de desempeño se descri-
ben y se incluyen: a) con el propósito de la función; b) con las características
detalladas de desempeño que la función debe realizar; c) la criticabilidaci de
la función; y d) con las restricciones aplicables al diseño. Los requerimien-
tos de desempeño deben tratar las características del diseño como tamaño,
peso, volumen, salida, rendimiento, confiabilidad y capacidad de manteni-
miento, factores humanos, seguridad, mantenibilidad, factores económi-
cos, etc. Ambos requerimientos de desempeño, cualitativos y cuantitativos,
que resultan a partir de un análisis de la función, se identifican mediante la
RASs. Estos requerimientos se desarrollan con suficiente detalle como para
permitir la síntesis y la evaluación de los conceptos alternativos para sa-
tisfacer cada necesidad funcional, para emplear una combinación de re-
cursos en términos de equipo, personal, software e instalaciones.
Una definición inicial de estos requerimientos del recurso se incluye en
la RASs. La figura 6.8 presenta un ejemplo de una hoja de asignación de los
requerimientos (RASs).

La salida específica del trabajo 6 (figura 6.6) variará en cuanto a estruc-


tura y formato dependiendo del tipo de sistema y la etapa de diseño y de-
sarrollo. Para los sistemas en gran escala que involucran muy diversas
Interfaces, pueden existir las relaciones ilustradas en la figura 6.9. Por otra
parte, para los sistemas más pequeños, donde el diseño es relativamente
simple en términos de su complejidad, puede no ser factible la utilización de
todos estos datos de salida.
Sistema: Subslerna Descripción de requerimientos:

Fuente (diagrama de flu- Número


Ubicación
jo de bloque funcional) de función
Descripción del trabajo Tiempo transcurrido (horas)
Niino Personal Tiempo
de trabajo 0.5 1.0 1.5 20 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 total

Figura 6.7. Ho'a de análisis de tiempos.


SLiia: 1 Sutna: 1 Descrlpcidn de los r&uerinlentos:
Fuente (diagrama de flujo de 1 Numero
Ubicación

y
tíloque funcional) de función
1
Desempeño funciona¡ requerimientos
del dloeño
Tarea
~
Requerimientos del

detaes
Aw.en*oa
dno
Entrena-
miento
Requerimientos de equipo

Nomenclatura Eeclfucación
Requerimientos de software-datos

Nomenclatura Eeclfkación
Requerimientos de instalación

Nomenclatura EecificaclÓn

Figura 6,8. Hoja de asignación de los requerimientos (RASs).


PLAN DE ADMINISTRACIÓN DE LA INGENIERLA DE SISTEMAS (SEMP) 255

Diagrama de tk* de bloque lunclonal

Hoja de análisis de tiempos

Hola de distribución de Os requerimientos (RASs

Reporte de estudio de compromisos (S)

Hojas de Os criterios del diseño r'' 1 HoJas de Os datos del diseño

Figura 6.9. Documentación de la ingeniería de sistemas.

6.2.3 Desarrollo de una estructura de descomposición del trabajo (WBS)

Uno de los pasos iniciales en el proceso de planeación del programa después


de la generación de la descripción del trabajo (SOW) es el desarrollo de la
256 PLANEACIÓN DE LA INGENIERÍA DE SISTEMAS

estructura de descomposición del trabajo (WBS).' La WBS es una familia de


árboles orientados al producto, que lleva a la identificación de las activida-
des, funciones,-trabajos, subtrabajos, paquetes de trabajo, etc., que se
deben desempeñar para la conclusión de un programa dado. La WBS exhibe
y define el sistema (o el producto) que es desarrollado y representa todos
los elementos de trabajo que se realizan. La WBS no es una tabla organizacional
en términos de los trabajos del personal del proyecto y sus responsabi-
lidades, sino que representa una organización de paquetes de trabajo
preparado para los propósitos de planeación del programa, presupuesto,
contratación y reporte.
En la figura 6.10 se ilustra un enfoque para el desarrollo de la WBS.
Durante las etapas iniciales de planeación del sistema, una estructu-
ra de descomposición de trabajo resumida (SWBS) usualmente se prepara
por el cliente e incluye una solicitud de una propuesta (RFP) o una invita-
ción para participar (JFB). Esta estructura, desarrollada de arriba-abajo,
esencialmente para propósitos presupuestales y de reportes, cubre
todas las funciones del programa y generalmente incluye tres niveles de
actividad:

1.Nivel 1. Identifica el alcance total del programa de trabajo, o el sistema


que se desarrolla, producido y liberado para el cliente. El nivel 1 es la base
para la autorización y seguimiento (o distribución) de todo el trabajo del
programa.
2.Nivel 2. Identifica los diversos proyectos, o categorías de actividad,
que deben concluirse como respuesta a los requerimientos del programa.
Éste también puede incluir los elementos más importantes del sistema y (o)
de las actividades importantes del proyecto, por ejemplo, los subsistemas,
el equipo, el software, los elementos de soporte, la administración del
programa y la prueba y la evaluación del sistema. Usualmente, los presu-
puestos del programa se preparan en este nivel.
3.Nivel 3. Identifica las actividades, funciones, trabajos más importan-
tes y(o) los componentes del sistema que están directamente subordinados
a los ítems del nivel 2. Generalmente, los planes del programa se preparan
en este nivel.

Conforme avanza la planeación del programa y las negociaciones indi-


viduales de contrato, la SWBS se desarrolla suficientemente yse adapta a un

El terna de la WBS y el empaque del trabajo se cubre en la mayor parte de los textos que se
ocupan de la administración del proyecto. Una buena referencia es Kerzner, H., Project
Management. A Systems Appmach ro Planning &hedulirzg and Control/mg, 3' ed., Van Nostrand
Reirihold, New York, 1989. En el sector de Defensa, una fuente excelente es MIL.STD.881A,
Mtlltary Standard, 'Work Breakdown Structure br Defense Materiel Items", Departamento de
Defensa, Washington, D.C.
Estructura resumida de la descomposición del trabajo (SWBS)

Nivel 1 01-00-00
Sistema XYZ

Nivel 01-01-00 01-02-00 01-03-00 01-04-00


Actividad A Actividad B Actividad C Actividad D

Nivel 01-02-01 01-02-02 01-02-03 01-02-04


Función 1 Función 2 Función 3 Función 4

Estructura de descomposición del trabajo de contrato (CWBS)


Estructura do descomposición del trajo de contrato (CWBS)
Fase del diseño preliminar del sistema Fase de diseño de detalle y desarrollo

wi II_II_II_JI _II_II_1

Figura 6.10. Desarrollo de la estructura de descomposición del trabajo (parcial).


258 PLANEACIÓN DE LA INGENIERÍA DE SISTEMAS

contrato particular o una acción de consecución que resulta de una estruc-


tura de descomposición del trabajo del contrato (CWBS). Al remitirse a la
figura 6.3, por ejemplo, el cliente puede desarrollar la SWBS con el objetivo
de iniciar la actividad de trabajo del programa. Esta estructura usualmente
reflejará los esfuerzos integrados de todas las actividades organizacionales
asignadas para el proyecto y no deben realizarse en un solo departamento,
grupo o sección. La SWBS, incluida en el RFP del cliente, es la base para la
definición de todo el trabajo interno y se establece para desarrollarse en un
programa dado. Por medio de la preparación subsecuente de las propues-
tas, negociaciones de contrato y procesos relacionados, el contratista "A"
se selecciona para realizar todo el trabajo asociado con la fase de dise-
ño preliminar del sistema, mientras el contratista "B" se selecciona
para concluir todo el trabajo relacionado con el diseño de detalle y la fase
de desarrollo. A partir de la definición de las descripciones individua-
les de trabajo, una CWDS se desarrolla para identificar los elementos de
trabajo para cada fase del programa. LA CWBS se diseña para un contrato
específico (o acción de consecución) que puede ser aplicable a los contra-
tistas esenciales, a los subcontratistas ya los proveedores, como se muestra
en la figura 6.3.
La WBS constituye un desglose jerárquico de arriba-abajo de las activi-
dades del proyecto que pueden dividirse suficientemente en funciones, las
funciones en trabajos, los trabajos en subtrabajos, los subtrabajos en
niveles de esfuerzo y así sucesivamente. A la inversa, en los trabajos deta-
llados (con las fechas de inicio y conclusión definidas) pueden combinarse
los esfuerzos combinados en los paquetes de trabajo y los paquetes de
trabajo pueden integrarse en las funciones y en las actividades, con la
acumulación de todo el trabajo que debe reflejarse en el programa más alto
del nivel del sistema.
Al desarrollar una WBS, se debe tener mucho cuidado de asegurar que
que: 1) se proporcione un flujo continuo de información relacionada con el
trabajo, de arriba-abajo; 2) se represente todo el trabajo pertinente; 3)
se proporcionen los niveles suficientes para causar la identificación de
los paquetes de trabajo bien definidos para propósitos de control de
costos planes; y 4) se elimine la duplicación de la tentativa de trabajo. Si la
WBS no contiene suficientes niveles, entonces la visibilidad de la adminis-
tración y la integración de los paquetes de trabajo puede tornarse difícil.
Por otra parte, si además existen muchos niveles, también será gastado
mucho tiempo en realizar la revisión del programa y las acciones de control.
La figura 6.11 presenta un ejemplo de una estructura de descomposición
del trabajo resumida (SWBS) que cubre el desarrollo de un sistema aéreo.
El mismo enfoque puede usarse al desarrollar una SWBS para un sistema
electrónico, un sistema hidráulico, una capacidad de producción, etc.
Conforme van siendo definidos los requerimientos del programa, a través
de un acuerdo (o consecución) contractual, la SWBS puede convertirse
PLAN DE ADMINISTRACIÓN DE LA INGENIERÍA DE SISTEMAS (SEMP) 259

enseguida en una CWBS para reflejar el trabajo real requerido bajo el


contrato. La CWBS, tal como aparece en el documento contractual, tam-
bién se presenta en tres niveles a fin de proporcionar una buena base
para propósitos de planeación, mientras que permite un poco de flexibili-
dad en la organización del contratista. Una expansión de la CWBS puede
llevarse a cabo conforme sea necesario para proporcionar el control in-
terno de costos del plan.
La figura 6.12 muestra una expansión de las actividades de la ingeniería
de sistemas que están en el quinto nivel, es decir, aquellos paquetes de
trabajo bajo 3A1 200, en la figura 6.11. El propósito es reconocer los trabajos
más importantes de la ingeniería de sistemas presentados en la figura 6.6
y proporcionar un desglose de estos trabajos en un formato CWBS con la
expansión necesaria para la propia visibilidad de los costos-plan. Por favor,
note que la figura 6.12 incluye dos diferentes CWBSs; uno cubre el trabajo
que debe desarrollarse durante el diseño conceptual y la fase de planeación
y el otro está dirigido hacia el trabajo requerido durante la fase de diseño
preliminar del sistema. Cada CWBS individual se deriva a partir de las SWBS
y la CWBS global del programa. Adicionalmente, hay estrecho vínculo entre
las dos, mientras la CWBS para el diseño preliminar debe reflejar las
actividades que evolucionan directamente desde la fase más temprana.
Los elementos de la WBS pueden representar un ítem identificable de
equipo o de software, o un paquete de datos distribuible, o un elemento
de soporte logístico, un servicio humano, o bien una combinación de ellos.
Los elementos de la WBS deben seleccionarse para permitir la estructu-
ración inicial de los presupuestos y el subsecuente seguimiento de las
medidas de desempeño técnico (TPMs), en contraste con los costos.
Así, al expandir la WBS exitosamente hacia los niveles más bajos, los re-
querimientos para la administración de trabajos día por día debe balan-
cearse en contraste con los requerimientos globales de reporte para el
programa. En esencia, las actividades del programa están separadas en
el nivel más bajo que puede estar asociado con ambas, una organización
y una contabilidad de costos, como la que se ilustra en la figura 6.3. A partir
de esto, se desarrollan los planes, se generan los costos estimados, se
establece la contabilidad y se monitorean las actividades del programa
para fines del control de los costos-plan.
Al desarrollar la WBS, es importante que se prepare un buen y com-
prensible "Diccionario de la WBS". Este constituye un documento que
contiene la terminología y la definición de cada elemento de la WBS.
La tranquilidad debe mantenerse de arriba-abajo y debe incluirse todo el
trabajo pertinente. Esto se facilita mediante la asignación de un número a
cada paquete de trabajo en la WBS. En relación con la figura 6. 10, el programa
total se representa por 01-00-00 ylos números desglosan las actividades, las
funciones, trabajos, subtrabajos, etc. En la figura 6.11, se usa una numera-
ción del sistema un poco diferente. Aunque los sistemas de numeración
Nivel Nivel Nivel
3M 100, Mrridetradee dat proyecto
381200, togeraerla de internas
3M300, Mrrdeslrectoe de la cordqurertoe
3M 400, Mrriedractón del cradrato
3M500, Mnidetrec8sr de tos datos
381 600, Sopole logístico integrado
3A1700, Adffids*Ier4de dat proveedro

301100, Investigación báica


301200, hweiacm aplicada
301300, Deswstbdelalecsctogla

acltoo, Ñnnazón de la nave


301200,
301300, Correrocartoe
301400, Navegacós-gula
3C1500,
301000, Medidas preventivas
301700, Eqiode reaencrr.ento
301000, Co*id de vuatos
301000, Electrónica auxiliar
302000, Equipo de amneido-prcyecties
302100, Equipo hóáiico

r 301100, Equipo especia de soprale, a mvi orgailizaciotsi

301200, Equipo eopecli de sprale, a ateel toterrnedla

30l300, Equipo especii de mcde, a reVi deço5sdo

E1:
Equipo ccm)n de xror1e, a revi orgarizaciceri

Equipo ccmicvn de soode, a revi inlermedio

1000, Equipo roma)n de erçrode, a revi de dep5s8o

301100, Datos didiseex dela rngereerls


301200, Datos de la disciplina di diseno-reçnales
301300, Manuiesldcicos
301400, Datos de sopcele bgliico
301500, Dates di proveedor
301000, Datos de adrosusiractoer
301700, Datos de caso-repules de lelas
301800, Bases de datos (de ~o(

E
00, Software cperackmi
301200, Software de arkr*airackm
301300. Paquetes de software especial

301100, Sav*tosde er4rerrarríeurto


301200, Equipo de erreqrarsiersto
301300, Datos de err6enarniento
301400, Instataciones de en8enassiosto

3Hll00, Áprcreisionanriesto
3Hl200, Partes excedentes, a ntoi cegarazadorsi
3H1300, Partes escedentes, a nivel intermedio
3111 ,100, Parles excedentes, a nivel de depóntlo
3841500, Parles de reparación, a todos los niveles
3Hl600, Materiales osnrejmldes
301700, Ccm8ct de iryveerlario
384l800, Faatdades (carga de 8v)

311100, ksstiacioeres industriales


311200, lnstaciorses de mantenimiento
311300, Equipo capital
311400, U8idades-jnpueskrs

111100, Prueba y esakjaadi, di desanolo


3J1200, Prueba y esateacedis operaidorsi
3)1300, Sonulacrones
3J1400, Planeados de prueba y evatuacidas
3)1500, Soporte de prueba y evaluación
1.11690. lrsstadoses de prueba
3)1700, Datos de prueba

31(1100, Actividades operacionales en si loca8dad


31(1200, Instalación de campo y verificación
31(1300, Actiódades intermedias de soporle di contratista
31(1400, Sopo< le di servicio de campo
31(1500, Scpoele de post-producido
31(1600, Modificaciones al sistema
31(1700, Mateeel readaide-de desedro

Figura 6.11. Estructura de descomposición de trabajo resumida (sistema aéreo).

260
PLAN DE ADMINISTRACIÓN DE LA INGENIERÍA DE SISTEMAS (SEMP) 261

variarán para los diferentes programas (y con diferentes contratistas), es


importante asegurar que ambas actividades y los presupuestos-costos
puedan seguirse, ambos de manera creciente y decreciente. En la genera-
ción inicial de una CWBS por un contratista, durante la preparación de una
propuesta, los presupuestos pueden asignarse de manera descendente
para los trabajos especificados. Después de adjudicar los trabajos del
contrato, deben realizarse los trabajos, los costos deben implicarse y car-
garse con la contabilidad de costos conveniente. Estos costos son, enton-
ces, recolectados de manera descendente para propósitos de reporte.
LaWBS proporciona el vehículo para medir el progreso del paquete de
trabajo en relación con el plan y el costo.
En resumen, la estructura de descomposición del trabajo (WBS) propor-
ciona muchas ventajas:

1. El programa total, o el sistema, puede describirse fácilmente me-


diante el desglose lógico de sus elementos en paquetes de trabajos
bastante definibles.
2. Las disciplinas asociadas con el desarrollo de la WBS proporcionan
una gran probabilidad de que cada actividad del programa se
tomará en cuenta.
3. La WBS es un vehículo excelente para vincular los objetivos del
programa y las actividades con recursos disponibles.
4. Las facilidades de la WBS de la asignación inicial de los presupues-
tos y la subsecuente recopilación y reporte de costos.
S. La WBS proporciona una matriz excelente para la asignación de
tareas de los trabajos y los paquetes de trabajo de los diversos
departamentos organizacionales, grupos y (o) secciones. Las ta-
reas de responsabilidad pueden identificarse en seguida.
6. La WBS es un vehículo excelente para el reporte de las medidas de
desempeño técnico del sistema (T'PMs), contra la planificación y los
costos.

Finalmente, la WBS es una herramienta excelente para el fomento de la


comunicación del programa en los diversos niveles. Como tal, debe actua-
lizarse para reflejar los cambios del programa-sistema, consistente con las
acciones de administración de la configuración. La actualidad del manteni-
miento es importante para poder cumplir los objetivos de la ingeniería de
sistemas.
EsucUa de 4eScApOeQdn de¡ trabajo Esbuc.ra ogizcion

1 CaiastaA 1

Nivel 1
1 Ineri&Ia 1

Nivel 2

IniutIa
sistemasde ln9edea
w&tica
IngrwIa
mecánica
Inw.rIa de
confiabildad
Desct,cón y
dbUJO mecánico

xi500
Nivel 3
Ccmdio

4C1510
I*d 4
AadM 1 1

4 1 1
11 1 1 1 1
SCIS12 5C1513
1
5C1514
Ccmd Amena 1 1 1
J 1 1 1
1 1
11— -1---1
____L ---I
1 -------

Costo ----------------—---—— -
Costc
}-. - - --- - - - - - - -- - - - - -
Figura 6.13. Integración organizacional con la CWBS.
EW~ c» dNoosl do dd a~ j~)
F... Ch d~óeI y d. h

wwI
L_________
10000

1 2Mc
Plv.I 2 1

3A1200
ru, i ~ 1

~do
4A121' 1 4l33O
1 1
1 1 4M230
1 1 i
J 4A121
d. 1
1
1 4At2
1 Tu, A dU 1 1 1 1 brid,Io. 1
II
S1211AM 5AI1- 5A1261.
_~ y .I.
o cç4r..
5A1212 5M252•
çIloorsI b

SAl 2y3.

(CWBS)
p.b,bwI ..

1 lOD
5~ XYZ

1 aalo
1A&w~ M 1
1-I
v1

__ 1 3Al2
[
..
d.

1
1 1 1 ¡
1
1 11 1 1 4A1240 1
1 1
4A1250 1 1 4Al2eo

*'US 5M211- SAl22T-Edo. SA11 5*1211 SA11. SAl2el.P..sdU


A~ M mIl.. PL~ dd PW~ dd Me'
dul p9ele
lAl2.AMki 5A1252.AMJ.i 5Al2e2-Roñ.du
SA1212. dÍMIoMe- SA12 5A1242
lb.lr l k~y du y Ml
mqk~ P'' pll 5Al2 codM du
S5I251lll S253Aa.irN.Io. eMly
5A1213- 5*l2•Plu. SAl2Plee
yeSaMn al
SA122.1nl.g.dM SA1254PlMe
Ml elle... 5*1331-AMII
SA1 214-
H~Cb~ S41225AdueMl "'OM
IKI y
bc6..Ms

Figura 6.12. Expansión de la CWBS que muestra las actividades de la ingeniería de sistemas.

262
264 PLANEACIÓN DE LA INGENIERÍA DE SISTEMAS

6.2.4 Árbol de especificaciones-documentación

Las especificaciones son documentos empleados esencialmente para crear


los ítems, es decir, la consecución de los componentes disponibles en
almacén, el establecimiento del diseño y el desarrollo de un nuevo ítem,
prueba y verificación de un producto, construcción de una nueva facilidad,
la producción de "X" cantidad de ítems, etc. Las especificaciones pueden
aplicarse en los contratos e imponerse a los contratistas más importantes,
los subcontratistas y los proveedores de bienes y servicios. Estos están
orientados a los requerimientos y pueden describirse de manera clara
y concisa. Debe eliminarse el lenguaje vago, redundante, oscuro y ambiguo.
Los requerimientos deben ser cuantificables yverificables y la necesidad de
usar el criterio de interpretación debe evitarse, es decir, el uso de frases
como "prácticas de un mejor diseño" o "buena relación de trabajo". Las espe-
cificaciones establecen los requerimientos relativos a los detalles de diseño
y características de desempeño. La información de la administración, las
descripciones de trabajo, los datos de los procedimientos, los planes
y proyecciones de costos, etc., no deben incluirse.
En relación con las aplicaciones, hay: 1) especificaciones generales;
2) especificaciones especiales del programa; 3) especificaciones militares
y estándares; 4) estándares industriales; 5) estándares específicos de la
compañía y, 6) especificaciones y estándares internacionales.' Las diver-
sas categorías de las especificaciones descritas en la sección 3.1 se refie-
ren a las especificaciones peculiares del programa, o aquellas que están
dirigidas hacia un requerimiento particular del programa y(o) a un compo-
nente específico del sistema. Además, hay especificaciones estándares que
cubren los componentes, materiales y procesos generales independien-
tes de la aplicación. En cada caso, hay una gran variedad de especificacio-
nes y estándares aplicados en un programa dado.
Al aplicar las especificaciones, se debe tener mucho cuidado de asegu-
rarse de que están preparados con el mismo grado de detalle y que son
aplicables en el nivel adecuado en la jerarquía del sistema. Tal como los
documentos deben detallarse con el grado requerido para afectar el diseño
en relación con la selección de los componentes, la utilización de los
materiales y la identificación de los procesos. Por otra parte, ¡aplicar las
especificaciones con mucho detalle y a un nivel muy bajo en la jerarquía del
sistema puede ser extremadamente perjudicial! Esto no sólo puede tender
a inhibir la innovación y la creatividad por no permitir los compromisos

Los estándares Industriales pueden variar significativamente y son desarrollados por


organizaciones tales como la American National Standards Institute (ANSI), International
Standards Organization OSO), American Soclety for Testing and Materials (ASTM), Electronic
Industries Assoclatlon (EIA), lnstitute of Electrical and Electronic Englneers (IEEE) y la National
Standards Assoclation (NSA).
PLAN DE ADMINISTRACIÓN DE LA INGENIERÍA DE SISTEMAS (SEMP) 265

posibles, sino que "la sobre especificación" puede ser bastante costosa.
Aplicar una especificación detallada a un pequeño componente disponible
en almacén, disponible comercialmente, puede resultar en un sobrediseño
que, a su vez, puede incrementar significativamente el costo de ese compo-
nente.'
Otro asunto relacionado con la aplicación de las especificaciones
involucra las posibles áreas de conflicto. La experiencia indica que los con-
flictos (esto es, contradicciones en la dirección) son algunas veces intro-
ducidas con la aplicación de las especificaciones generales y los estándares
generales. Estos documentos se preparan por diferentes personas, en mo-
mentos diferentes, con aplicaciones diferentes en mente y no son con
sistentes necesariamente en relación con los requerimientos detallados.
A menudo, en el desarrollo de los requerimientos del programa, hay una
tendencia a permitir el enfoque más expeditoymás fácil para juntar una gran
vista de estas especificaciones y estándares en un contrato de descripción
de trabajo. En otras palabras, "el contratista debe cumplir con la lista adjun-
ta de especificaciones y estándares para satisfacer los requerimientos del
programa". Esta aplicación a ciegas puede dar como resultado conflictos
en relación con la selección de las partes de los componentes, las variaciones
del proceso de manufactura, los parámetros de prueba y evaluación, etc.
En tales casos, hay una pregunta acerca de qué especificación tiene prece-
dencia. ¿Cuáles son las prioridades en cuanto a importancia?
Con el objetivo de fomentar la aclaración y eliminación de las áreas de
posible conflicto, se recomienda la preparación de un "árbol de especifica-
ciones" (o árbol de documentación). Esta es una familia de árboles de espe-
cificaciones y de documentos que apoyan la jerarquía del sistema, establece
el orden de precedencia en caso de conflictos y relaciona los elementos
de trabajo en la estructura de descomposición del trabajo (WBS). La figu-
ra 6.14 ilustra un árbol de especificaciones simplificado.
Al remitirse a la figura, el árbol se desarrolla de arriba-abajo comenzan-
do con la preparación de las especificaciones del sistema (para más in-
formación véase la sección 3.1). Posteriormente, las especificaciones
adicionales son aplicadas, siguiendo la jerarquía del sistema ilustrado en la
figura 2.11. Conforme se avanza, la aplicación de las especificaciones debe
ser consistente con los requerimientos de trabajo descritos por la WBS de
la figura 6.10. Posteriormente, esta aplicación debe adaptarse a una estruc-
tura de contratación entre los contratistas más importantes, los
subcontratistas y los proveedores (véase la figura 6.13).

'La referencia se relaciona con el número de casos, en los que, en el sector de defensa, las
especificaciones y los estándares militares se impusieron para la consecución de pequeños
componentes, herramientas manuales, etc. La imposición "ciega" de las especificaciones de los
ítems disponibles en almacén, disponibles comercialmente, puede, a su vez, resultar bastante
costosa. No sólo darán como resultado un caso sobrediseñado, sino que se reducirá el número
de proveedores disponibles.
266 PLANEACIÓN DE LA INGENIERÍA DE SISTEMAS

Sistema XYZ
SS 1234- Especificació
M sistema (Tipo A)

Software Equipo Dato


DS2A2- Especificación DS2A3-Especiflcación DS2A4- Especificación
M desarrollo (Tipo B) M desarrollo (Tipo B) del desarrollo (Tipo B)

MIL-D-28000, "Represen-
MIL-STD-1679-A, tación digital para la co-
"Desarrollo del software" municación de los datos
W producto": temas IGES

Unidad A Unidad B Unidad C

MSA36- Especificación DS3C6- Especificación PS61 2- Especificación


(Tipo D) del proceso (Tipo B) de desarrollo (Tipo C) del producto

MIL-P-11268, "Partes, MIL-C-21200C, "Diseño


materiales y procesos y desarrollo del sistema
empleados en el equipo y de control de equipo"
electrónico"

Computadora Programa de computadora Equipo

PS71 4- Especificación PS715- Especificación PS716- Especificación


(Tipo C) del producto (Tipo C) del producto (Tipo C) del producto

MIL-STD-454, "Requeri- DOD-STD-21 67,


mientos generales para "Desarrollo de defensa E1A262, Especificación
equipo electrónico" M software del sistema" industrial

MIL-E-5400, "Especifica- DOD-STD-21 68,


ción general, electrónica, "Evaluación de la calidad
equipo, M software"
aerotransportación"

Figura 6.14. Árbol de especificaciones-documentación.


PLAN DE ADMINISTRACIÓN DE LA INGENIERÍA DE SISTEMAS (SEMP) 267

Aquí, el trabajo crítico es la confección de las especificaciones para la


aplicación particular del sistema. Aunque los requerimientos del diseño
pueden ordenar el uso de un ítem disponible en almacén, la aplicación de ese
ítem en este sistema puede ser bastante diferente a aplicaciones compara-
bles en otros sistemas. Así, los componentes más importantes del sistema
deben describirse por medio de una serie de especificaciones peculiares del
programa, tal como se muestra en la figura 6.14, por ejemplo, especificacio-
nes de desarrollo, especificaciones del producto y especificaciones del
proceso. Bajo este nivel, puede ser apropiado aplicar las especificaciones
tan pronto como éstas apoyen los requerimientos globales del diseño del
sistema. Cuando hay un número de especificaciones diferentes y (o)
estándares aplicadas al mismo componente del sistema, éstas deben ser
complementarias y se deben de apoyar mutuamente. En el caso de conflic-
tos en relación con asuntos referentes a las prioridades de importancia, el
árbol de especificaciones debe proporcionar una indicación de qué docu-
mento toma precedencia.
El desarrollo de los requerimientos del diseño de arriba-abajo es crítico
en el cumplimiento de los objetivos de la ingeniería de sistemas indicados
aquí. Por lo tanto, se debe poner mucho cuidado en la identificación inicial
yen la aplicación de las especificaciones y estándares. Aunque esta función
suele verse como relativamente menor, los resultados pueden ser bastante
costosos ¡si el propio nivel de atención no se dirige hacia esta área desde el
inicio! Los conflictos, los cambios en los requerimientos de especificación
dan como resultado modificaciones contractuales, etc., lo cual puede ser
extremadamente perjudicial para el programa. La inclusión de un árbol de
especificaciones completo en el SEMP puede ayudar a evitar problemas
potenciales.

6.2.5 Desarrollo de los planes del programa

En línea con la descripción del trabajo (SOW) y la estructura de descompo-


sición del trabajo (WBS), los trabajos individuales se presentan en relación
con una línea de tiempo, es decir, una fecha de inicio y una fecha decon-
clusión. Los planes se desarrollan para reflejar los requerimientos de
trabajo durante todas las fases de un programa.
La planeación del programa comienza con la identificación de los
indicadores más importantes del programa en un alto nivel y proceden de
manera decreciente a través de los niveles sucesivamente más bajos
de detalle. Un "plan maestro del programa" inicialmente se prepara disponien-
do de las actividades del programa en base al tiempo transcurrido. Esto sirve
como marco de referencia para una familia de planes subordinados, desa-
rrollados para cubrir las subdivisiones del trabajo como se represen-
tan por la WBS. El progreso, en contraste con un plan dado, es medido en el
nivel de abajo y la información del estatus del trabajo se relaciona con
268 PLANEACIÓN DE LA INGENIERÍA DE SISTEMAS

Meses después que el programa arrancó

Programa deactividades 1 2 3 1 4 5 1 6 1 7 1 8 1 9 10 11 12

1. Necesidad de estudios de análisis y factibilidad

2. Requerimientos operacionales del sistema y


concepto de mantenimiento

3. Especificación del sistema [J


4. Planeación de la administración de la []
ingeniería de sistemas (SEMP)

S. Revisión del diseño formal

6. Análisis funcional y locaifzación de


requerimientos

7. Integración del sistema

Figura 6.15. Gráfica de barras parcial.

la contabilidad de costos apropiada mediante los elementos de la WBS y la


organización responsable (véase la figura 6.13).
La planificación del programa de trabajo puede realizarse mediante el
uso de una o varias de técnicas. Algunos de los métodos más comunes se
describen brevemente en la siguiente página.

Meses después que el programa arrancó

Programa de actividades 1 2 3 1 4 1 5 6 1 7 8 9 10 11 12
f

1. Necesidad de estudios de análisis y factibilidad

2. Requerimientos operacionales del sistema


y concepto de mantenimiento
3. Especificación del sistema Á

4. Planeación de la administración de la A
ingeniería de sistemas (SEMP)

S. Revisión del diseño formal A A A A


6. Análisis funcional y localización de
requerimientos

7. Integración del sistema

Figura 6.16. Ejemplo de gráfica con pilares.


PLAN DE ADMINISTRACIÓN DE LA INGENIERfA DE SISTEMAS (SEMP) 269

1.Gráfica de barras. La gráfica de barras simple presenta las actividades


del programa en términos de secuencias y el tiempo de esfuerzos. Los indi-
cadores específicos y la misión de los recursos no son cubiertos. La figu-
ra 6.15 ilustra una gráfica de barras parcial.
2.Gráfica con pilares. Una representación de los eventos específicos del
programa (por ejemplo, las salidas identificables) y las fechas de inicio
y conclusión por fecha del calendario se incluye. Se indican los ítems
requeridos bajo contrato. La figura 6.16 muestra un ejemplo de una gráfica
con indicadores.
3.Gráfica combinada de barras y pilares. La combinación de actividades
e indicadores en un plan global de un proyecto representa un enfoque
común para muchos programas. La figura 6.17 presenta los trabajos esencia-
les de la ingeniería de sistemas, incluidos en la figura 6.6, en un formato de
los tiempos del programa. Esto, evidentemente, dala base para la asignación
de los recursos y el desarrollo de las proyecciones de costos.
4.Redes de programa. Los métodos de planeación incluyen la Evaluación
yTécnica de Revisión del Programa (PERT), el Método cte Ruta Crítica (CPM)
así como las combinaciones de varios de estos. La PERT y el CPM son
idealmente una ayuda de seguimiento para la planeación inicial donde no
están disponibles tiempos precisos de los trabajos y los aspectos de la
probabilidad son introducidos para ayudar a definir el riesgo llegando
a mejorar la toma de decisiones. Estas técnicas ofrecen visibilidad y la
administración suficiente para el control de los proyectos de uno-en-su-
clave en oposición a las funciones repetitivas. Posteriormente, el plantea-
miento de red es efectivo al mostrar las interrelaciones de las actividades
combinadas.' La figura 6.18 refleja un ejemplo de un diagrama de una red que
consiste en los 17 "eventos" y las 29 "actividades" más importantes.
Los eventos son usualmente designados por círculos y se consideran
como los puntos de ejecución para ser revisados que muestran pilares
específicos, es decir, las fechas para empezar un trabajo, para concluir un
trabajo y para liberar un ítem bajo contrato. Las actividades están represen-
tadas por las líneas entre los círculos, que indican el trabajo que debe
realizarse para concluir un evento. El trabajo puede empezar en la siguiente
actividad sólo después de que el evento precedente ha sido concluido.
Los números de las líneas de actividad indican el tiempo requerido en días,
semanas o meses. El primer número refleja una fecha estimada opti-

Tres buenas referencias que cubren los métodos de planeación son Kerzner, H., Project
Management: A Systems Approach to Planning, Scheduling and Controlling, 3a ed., Van
Nostrand Reinhold, NewYork, 1989; Ullmann, J. E. (ed.), Handbook of Engineering Management,
John Wiley, New York, 1986; y Wiest, J. D. and F. K. Levy, A Management Cuide to PERT-CPM,
Prentice-Hall, Englewood Cliffs, Ni. 1977.
ej

u
L2

o)

1
(o

u ;:-

o)

il Ei e-

e)

ej

-i -

-o -
( 2

2 2-o
E . 2 o • -•5 O
-
As
>' -
-
fi II
- - E -o -

270
PLAN DE ADMINISTRACIÓN DE LA INGENIERÍA DE SISTEMAS (SEMP) 271

mista, el segundo número indica la fecha esperada y el tercer número


constituye una fecha estimada como pesimista.8

Al aplicar la PERT-CPM a un proyecto, uno debe identificar todos los


eventos interdepen dientes y las actividades para cada fase del proyecto.
Los eventos se relacionan con las fechas de los pilares del programa que se
basan en los objetivos de administración. La figura6.19 describe las activi-
dades más importantes que se reflejan mediante las líneas en la figura 6.18.
Los administradores y los programadores trabajan con las organizacio-
nes de la ingeniería para definir estos objetivos e identificar los trabajos
y subtrabajos. Cuando esto se realiza con el nivel necesario de detalle, las
redes se desarrollan, empezando con una red resumida y trabajando abajo
con las redes detalladas que cubren los segmentos específicos de un
programa. El desarrollo de las redes es un enfoque de equipo.
Cuando se construyen realmente las redes, uno empieza con un objetivo
final (por ejemplo, el evento 17 de la figura 6.18) y trabaja hacia atrás al
desarrollar la red hasta que se identifica el evento 1. Cada evento se etiqueta,
codifica y verifica en relación con el marco del programa. Las actividades
entonces se identifican y verifican para asegurar que están secuenciadas
adecuadamente. Algunas actividades pueden desempeñarse en forma con-
currente y otras deben realizarse en serie. Para cada red concluida, hay "un
evento de inicio" y "un evento final" y todas las actividades deben conducir
al evento final.
El siguiente paso al desarrollar una red consiste en estimar los tiempos
de actividad y relacionar estas fechas en términos de la probabilidad de
ocurrencia. Un ejemplo que soporta una red PERT-CPM típica se presenta en
la figura 6.20 y se describe abajo.

a. Columna 1
Liste cada evento, empezando desde el último y trabajando hacia atrás
hasta el inicio (por ejemplo, desde el evento 17 al evento 1 en la figura 6.18).

b. Columna 2
Liste todos los eventos previos que llevan hacia, o que se muestran que
están antes de, el evento listado en la columna 1 (por ejemplo, los eventos
15 y 16 llevan al evento 17).

8
El nivel de detalle y rango de desarrollo de la red (por ejemplo, el número de actividades
y eventos incluidos) se basa en lo crítico de los trabajos y en el grado deseado de la evaluación
del programa y del control. Los indicadores que son críticos en el cumplimiento de los objeti-
vos del programa deben concluirse junto con las actividades que requieren exten-
sas interacciones para la conclusión exitosa. El autor ha tenido experiencia al tratar las redes
PERT.CPM que incluyen de 10 700 eventos. El número de eventos-actividades, evidentemente,
variará de acuerdo al proyecto.
Actividad Descripción del programa de actividad Actividad Descripción del programa de actividad

A Desarrollo de la necesidad de análisis. estudos de conducta de factbáklad, y efectuar análisIs O Identifique los proveedores de corronenles convenientes para el sistema, Imponga los raque-
de sistemas (requerimientos operacionales, concepto de mantenimiento, y definición funcional nmlenlos y especificación necesarios a travésde los contratos ymonitoreo de las actMdades del
proveedor.
del sistema).

5 Realice el avance de la planeación, realice las funciones Iniciales de administración y concluya el R Lleve acabo la planeación necesaria yprepare las Revisiones delequo.software-componentes
Plan de la Administración de la Ingenierta de sistemas. del diseño uede haber una serle de revisIones Individuales del diseño que cubren los
componentes diferentes del sistema).
C Prepare la especificación (Tipo Al del sistema.
S Proporcione los datos del diseño de detalle (según sean necesarios para apoyar las operaciones
D Desarrolle los requerimientos técnicos al nivel del sistema para incluir el Plan de Administración del proveedor).
de Ingeniería de Sistemas (SEMP).
T Desarrolla un modelo prototipo con el soporte asociado, en la preparación de la prueba
E Prepare los datos del diseño al nivel del sistema y apoye los materiales para la Revisión del Diseño y evaluación del sistema
Conceptual.
u Prepare los datos del dineñoy los materiales de apoyo (como resultado de diseño de detalle) para
F Lleve a cabo el análisis funcional y la distrtución de los requerimientos globales del sistema al
las Revisiones del Equipo-Sotlware-Componente del Diseño.
nivel del sttsrstema (según se requiere),
V Traduzca los resultados de las Revisiones Equipo-Software-Compomrerite del Diseño para
G Desarrolle la lotraeslrr.ictura organizacional necesaria y le relacionada en la preparación para
incorporar el modelo(s) prototipo según sea pertinente. El modelo prototipo que debe utilizarse
realización de los trabajos requeridos para la integración del diseño del programa
en la prueba y evaluación y debe reflejar la última configuración del diseño.
H Traduzca los resultados de la Revisión del Diseño Conceptual a las actividades convenientes del
diseño (porejemplo,dalosapdoados del diseño, recarrrendaclorres para melora-accióncorrecliva). W Proporcione iris componentes del proveedor, con los datos de apoyo, para el desarrollo el
prototipo del sistema que se ultiza en las actividades de prueba y evaluación.
1 Traduzca los resultados del análisis funcional y actividad de distribicióna criterios específicos del
diseño requeridos como entrada para el proceso de integración del diseño. X Preparey realice la Evaluación y Prueba del Sistema )habe los requerimientos del Plan Maestro
de Prueba y Evaluación).
J Realice el diseño preliminar y las actividades de integración del diseño.
Y Proporcione los datos de prueba y el soporte logístico de los diversos proveedores durante la fase
1K Traduzca los resultados del nivel del sistema a requerimientos especificos en el nivel del de prueba y evaluación del sistema. Los datos de prueba se requieren para cubrir las pruebas
subsistema y abajo. Prepare el Desarrollo, Proceso, Producto y(o) Especificaciones de material Individuales llevadas a cabo en las localidades del proveedor y el soporte logistico, (por ejemplo,
según sea requerido. partes de repuesto-de-reparación, equipo de prueba, elcéteral es necesario para apoyar las
Lleve la planeación necesaria y prepare la Revisión del Diseño del Sistema. actividades de prueba del sistema.

M Traduzca los requerimientos conlenirles en las diversas especificaciones pertinentes en los Z Lleve a cabo la planeación necesaria y prepare la Revisión del Diseño Critico.
criterios específicos del diseño requeridos como una entrada al proceso de integración del diseño
AA Pruebe los resultados amanerada verificación del diseño o recomendaciones para mejoramlen-
fi Prepare los datosdeldiseñoy los materiales de apoyo (como resultados deldeeño preIimnarpara lo-acción correctiva, son proporcionados corno una entrada a la Revisión del Diseño Critico.
la revisión del diseño del sistema): o realce el diseño de detalle y las actividades de integración
del diseño relacionadas. BB Prepare el reporte de prueba y evaluación del sistema

O verificar el diseño detallado y el diseño relacionado de la integración de actividades. CC Traduzca tos resultados de la Revisión del Diseño Critico para incorporarlo en le cordlguraclón
final del sistema antes de entrar a la Fase de Producción y(o) Construcción del programa.
P Traduzca los resultados a partir de la revisión del diseño del sistema a las actividades convenien-
tes del diseño (por ejemplo, datos aprobados del diseño, recomendaciones para mejoramiento-
acción correctiva).

Figura 6.19. Lista de actividades en la red del programa.


Dbdo oencepal ~ Pre~ de ~ DSdIO de deIe y deswdlo del sIslema


1

Swn~ de,ués de que el programa se sJse en mN(*8

2 12
di
r
Cla
4 di de i.iI,
2-3-4 T.B-E 8-10-12 dsI.dn.

D 2-3-4 K M 346 Y 6-8-12


4-6 6-8-12 W
A 6-8-12 -8-12 15
11 17

di Idi.ci6ed O kH(ndi T ( \ iIóndi 8B


di dIMM
3- 10-24
~00 do
8-32-40 6 (o~) 348
(55W
(sern. .l21O2O>.a.,/10 12
H 13 3-4-6 AA 2-4-6
N 3-4-6
2-3-4 CC
2-3-4
10 16
.óóndi R
_________________
z - - di i..
P.sesindi
dWb 2-3-4 scev*.di
2-34 oseçoseÍ. 2
di i..#e

iaa. l.2-3-4-5-6-7-O-jl-12-l$l5.t6-17.

Figura 6.18. Red del programa resumida (parcial).


1 2 3 4 5 6 7 8 9 10 11 12
Número Número
actual previo Probabi8dad
t, t t 52 TE TL TS TC %
17 16 2 3 4 3.0 0.111 115.2 1152 0 110 6.4
15 3 4 8 4.5 0.694 112.1 116.2 3.1 115 47.9
16 15 - 2 4 6 4.0 0.444 112.1 1122 0 120 91.9
13 2 3 4 3.0 0.111 86.5 1122 25.7
15 14 10 12 16 123 1.000 108.2 108.2 0
12 6 8 12 8.3 1.000 95.9 108.2 12.3
J

14 13 2 3 4 3.0 0.111 86.5 95.9 94


12 6 8 12 8.3 1.000 95.9 96.9 O
11 12 16 20 16.0 1.778 95.3 95.9 0.6
13 11 3 4 6 4.2 0.250 83.5 13.6
lO 2 3 4 3.0 0.111 53.8 42.1
12 11 6 8 12 8.3 1.000 87.6 87.6 0
8 8 10 12 10.0 0.444 608 87.6 26.8
11 10 1 2 3 2.0 0.111 52.8 79.3 26.5
9 28 32 40 32.7 4.000 79.3 79.3 0
10 9 3 4 6 4.2 0.250 50.8 30.7
5 2 3 4 3.0 0.111 21.3 59.0
9 8 3 4 6 4.2 0.250 35.0 46.6 11.6
7 16 20 24 200 1.778 46.6 46.6 0
8 7 3 4 6 4.2 0.250 30.8 15.8
7 6 2 3 4 3.0 0.111 26.6 26.6 0
5 1 2 3 2.0 0.111 20.3 26.6
4 6.3
3 4 6 4.2 0.260 19.5 26.6 7.1
6 4 6 8 12 8.3 1.000 23.6 23.6 0
5 4 2 3 4 3.0 0.111 16.3 9.3
4 3 1 2 3 2.0 0.111 15.3 15.3 0
1 6 8 12 8.3 1.000 8.3 15.3 7.0
3 2 2 3 4 3.0 0.111 13.3 13.0 0

2 1 8 10 14 10.3 1.000 10.3 10.3 0

Figura 6.20. Ejemplo de los cálculos de la red del programa.


PLAN DE ADMINISTRACIÓN DE LA INCENIERfA DE SISTEMAS (SEMP) 275

c. Columna 3-5
Determine el tiempo optimista (ta), el tiempo más probable (th) y el
tiempo pesimista (te) en semanas o meses para cada actividad. El tiempo
optimista significa que hay muy poca oportunidad de que la actividad pueda
concluirse antes de este tiempo, mientras el tiempo pesimista significa que
hay poca probabilidad de que la actividad sea más larga. El tiempo más
probable (tb) está localizado en el punto más alto de la probabilidad o en la
cresta de la curva de la distribución. Estos tiempos pueden predecirse
por alguien que tiene experiencia en estimar. Las estimaciones de los
tiempos pueden seguir diferentes curvas de distribución, donde P represen-
ta el factor de probabilidad.

Tiempo ----* Tiempo Tiempo

Figura 6.20A. Ejemplo de curvas de distribución.

Los tres tiempos estimados se incluyen también en la figura 6.18 para


cada actividad (A, B, C etc).

d. Columna 6
Calcula el tiempo medio o esperado, te, a partir de:

t + 4t, + t (61)
te =

e. Columna 7
En una distribución estadística, uno puede desear determinar los diver-
sos factores de probabilidad para los diferentes tiempos de actividad.
Así, es necesario calcular la varianza s2 asociada con cada valor medio.
La raíz cuadrada de la varianza, o bien la desviación estándar, es una
medición de la dispersión de los valores en una distribución y es útil pa-
ra determinar el porcentaje de la población total del ejemplo, que cae dentro
de un conjunto especificado de valores. La varianza se calcula a partir de la
ecuación 6.2:
276 PLANEACIÓN DE LA INGENIERÍA DE SISTEMAS

= (tc ta)2 (6.2)

f. Columna 8
El tiempo más temprano esperado para el proyecto, TE, es la suma de
todos los tiempos, te, para cada actividad, a lo largo de la ruta de una red
dada, o el total acumulado de los tiempos esperados a través del evento
precedente que queda en la misma ruta a través de la red. Cuando varias
actividades llegan al mismo evento, el valor de tiempo más alto (te) será
usado. Por ejemplo, en la figura 6.18, la Ruta 1, 4, 7, 9, 11, 14, 15, 17 da como
total 98; la Ruta 1, 2, 3, 4, 7, 9,11, 14, 15, 17 da como total 105; y la Ruta 1, 2,
3, 4, 5, 6, 7, 9,11, 12, 14, 15,16,17 da como total 115.2. El valor más alto para
el TE (si uno verificó todas las rutas de la red) es 115.2 semanas y este es el
valor seleccionado para el evento 17. Los valores TE para los eventos 16, 15,
y así sucesivamente son calculados de manera similar trabajando hacia
atrás hasta el evento 1.

g. Columna 9
El tiempo más tardío permisible para un evento, TL, es el tiempo más
tardío para la conclusión de las actividades que preceden inmediatamen-
te al evento. 11 se calcula empezando con el tiempo más tardío para el
último evento (por ejemplo, donde TE es igual a 115.2 en la figura 6.20)
y trabajando hacia atrás sustrayendo el tiempo esperado (te) para cada
actividad, que queda en la ruta del ejemplo. Los valores TL para los eventos
16, 15, y así sucesivamente se calculan de manera similar.

h. Columna 10
El tiempo de holgura , TS, es la diferencia entre el tiempo más tardío
permisible (TL) y el tiempo más temprano esperado (TE):

TS = TL - TE (6.3)

i. Columnas 11-12
TC se refiere al tiempo planeado requerido para la red basado en la
necesidad actual. Asume que la administración especifica que el proyecto
que se reflejó en la figura 6.18 debe concluirse en 110 semanas. Ahora es
necesario determinar la probabilidad, es decir la probabilidad (P), de que
esto ocurrirá. Este factor de probabilidad se determina de la manera
siguiente:

TC — TE (6.4)
Z =
y Path Varjances
PLAN DE ADMINISTRACIÓN DE INGENIERÍA DE SISTEMAS (SEMP) 277

donde Z está relacionada al área bajo la curva de la distribución nor-


mal, que es igual al factor de probabilidad. La "varianza de la ruta" es la
suma de las varianzas individuales a lo largo de la ruta más larga, ola ruta
crítica en la figura 6.18 (por ejemplo, la Ruta 1, 2,3,4,6, 7, 9, 11, 12, 14,
15, 16, 17).
Z 110 - 115.2
=—l.522
/ 11.666

Al referirse a las tablas de distribución normal, el valor calculado de -


1.522 representa un área de aproximadamente 0.064, es decir, la proba-
bilidad de que se cumpla el tiempo planeado de 110 semanas es 6.4%. Si
el requerimiento de administración es de 115 semanas, entonces la
probabilidad de que resulte será de aproximadamente 47.9%; o si 120
semanas fueron especificadas, la probabilidad de que resulte será
alrededor de 91.9%.

Al evaluar el valor resultante de probabilidad (la columna 12 de la figu-


ra 6.20), la administración debe decidir sobre el rango de factores permisi-
ble en relación al riesgo. Si el factor de probabilidad es muy bajo, los recursos
adicionales pueden aplicarse al proyecto a fin de reducir los tiempos del
plan de actividad y mejorar la probabilidad de que resulte. Por otra parte,
si el factor de probabilidad es muy alto (es decir, que prácticamente no hay
riesgo involucrado), esto puede indicar que los recursos sobrantes están
siendo aplicados, algunos de los que podrían desviarse a otra parte.
La administración debe valorar la situación y establecer una meta.
Al referirse a la figura 6.18, la ruta crítica, que se refleja por la línea
oscura (o sea, la ruta 1, 2, 3 4,6, 7, 9, 11, 12, 14,15, 16, 17), incluye la serie de
actividades que requieren la cantidad más grande de tiempo para la conclu-
sión. Estas son las actividades críticas donde los tiempos de holgura son
cero y una desviación de lo planeado en cualquiera de estas actividades
causará una demora en la programación del programa global. Así, estas
actividades deben monitorearse estrechamente y controlarse durante el
programa.
Las rutas de la red representan otras actividades del programa mostra-
das en la figura 6.18 que incluyen tiempo de holgura ÇT'S), que constituye
una medición de la flexibilidad al planear el programa. El tiempo de
holgura es el intervalo por donde una actividad podría realmente demo-
rarse más allá de su inicio planeado inicialmente, sin demorar necesaria-
mente el tiempo de la conclusión global del programa. La disponibilidad de
tiempo permitirá una redistribución posible de recursos. El planear las
mejoras del programa, quizá sea posible mediante el cambio de los recursos
de actividades con tiempo de holgura a las actividades a lo largo de la ruta
crítica.
278
PLAN DE ADMINISTRACIÓN DE LA INGENIERÍA DE SISTEMAS (SEMP) 279

Como un punto adicional en relación con los planes del programa, es


posible desarrollar una jerarquía de redes individuales siguiendo un
patrón similar al enfoque de desarrollo de la WBS, ilustrado en la figura 6.10.
A fin de proporcionar las acciones de monitoreo y control apropiadas, la
planeación puede realizarse a diferentes niveles. La figura 6.21 muestra un
desglose de la red del programa (ilustrado en la figura 6.18), en una red en
el nivel más bajo que cubre los requerimientos de confiabilidad del pro-
grama. Una red similar puede desarrollarse para la mantenibilidad, otra red
para diseño eléctrico y las redes adicionales detalladas según sea conve-
niente. Estas redes del nivel muy bajo pueden, evidentemente, apoyar
directamente a la red global del programa.
La utilización de la técnica de planeación PERT/CPM ofrece varias
ventajas:

a. Es adaptable de inmediato a la base de la planeación y esencialmente


fortalece la definición detallada de los trabajos, la secuencia de trabajos
y las interrelaciones de trabajos. Todos los niveles de administración
e ingeniería se requieren para pensar bien y evaluar con cuidado el proyecto
completo.
b. Con la identificación de las interacciones de los trabajos, se tiende
a forzar la definición inicial, la administración subsecuente y el control de
las interfaces entre cliente y contratista, organizaciones dentro de la estruc-
tura del contratista, y entre el contratista y los diversos proveedores. La
administración y la ingeniería obtienen una gran apreciación del proyecto
en términos de requerimientos de recursos totales.
c. Hace posible que la administración y la ingeniería predigan con algún
grado de certidumbre el tiempo probable que tomará alcanzar un objetivo.
Las áreas de riesgo-incertidumbre del programa pueden identificarse en
seguida.
d. Hace posible el rápido avalúo del progreso y permite la detección
temprana de las posibles demoras y problemas.

Es posible la implementación de PERT/CPM de manera extensa


y oportuna, ya que la técnica es particularmente adaptable a los métodos
computacionles. De hecho, hay un número de modelos de computadora
y software asociado que están disponibles para planear la red.

5. Red-Costos. Las redes FERT/CPM pueden extenderse para incluir


costos mediante la sobreposición a una estructura de costos en la progra-
mación del tiempo. Cuando se implementa esta técnica, existe siempre la
opción de tiempo-costo, que hace posible a la administración evaluar las
alternativas relativas a la asignación de los recursos para la realización de
la actividad. En muchos casos, se puede ahorrar tiempo aplicando más
recursos. A la inversa, el costo puede reducirse extendiendo el tiempo para
280 PLANEACIÓN DE LA INGENIERÍA DE SISTEMAS

concluir una actividad. La opción tiempo-costo puede obtenerse por medio


de los siguientes pasos generales:

a. Para cada actividad de la red, determine el tiempo posible alternativo


y los estimados de costos (y pendiente de costo) y seleccione la alternativa
de más bajo costo.
b. Calcule la ruta crítica para la red. Seleccione la opción del costo más
bajo para cada actividad de la red y verifíquela para asegurarse de que el
total de los tiempos de actividad incremental no exceda el tiempo global
permisible para la conclusión del programa. Si el valor calculado excede el
tiempo permitido para el programa, revise las actividades a lo largo de la red

Inicio de una actividad

Fin de una actividad

1 Actividad propuesta (el nombre o número de actividad se puede mostrar)

J Achurado significa progreso

Fecha actual (marca movible)

EIiIIJ Tiempo para mantenimiento u otras actividades no productivas

Figura 6.22. Gráfica de Gantt para una máquina usada en producción.


PLAN DE ADMINISTRACIÓN DE LA INGENIERfA DE SISTEMAS (SEMP) 281

de la ruta crítica y seleccione la alternativa con la pendiente del costo más


baja. Reduzca el valor del tiempo para que sea compatible con el requeri-
miento del programa.
c. Después de que la ruta crítica se ha establecido en términos de la
opción del costo más bajo, revise todas las rutas de la red con tiempos de
holgura, y recorra las actividades para extender los tiempos y reducir
costos dondequiera que sea posible. Deben tratarse primero las actividades
con pendientes más pequeñas de tiempo-costo.
El PERT/CPM/COST ha demostrado que es una técnica muy útil en la
planeación de los eventos y actividades de programación y permite
monitorear el estatus necesario del programa de costo-plan y controlar los
requerimientos realizados durante el desarrollo del sistema.

6.Gráfica de Gantt. Esta técnica se emplea esencialmente en la produc-


ción y(o) en la planeación de la construcción para mostrar la actividad o los
requerimientos de trabajo, la carga de la instalación y el estatus de trabajo
en unas forma día por día. Ésta fue diseñada, y utilizada más exitosamente,
para apoyar las operaciones altamente repetitivas. Un ejemplo de una
gráfica de Gantt básica se muestra en la figura 6.22. Las gráficas de Gantt
usadas para planear a largo y a corto plazos en la forma día por día, pueden
tomar la forma de gráficas de control de carga de máquina, gráficas de con-
trol de carga de trabajo y (o) gráficas de control del avance del trabajo.
7.Línea de balance (LOB). Esta técnica es similar a la gráfica de Gantt
relativa a determinar el estatus de producción-construcción. Mediante la
técnica de Gantt, que esencialmente relaciona la información en la utiliza-
ción efectiva eficiente de recursos gastados (por ejemplo, carga de trabajo,
carga de fabricación), LOB está más orientado al producto. El LOB no se
relaciona directamente con los recursos gastados, sino que se utiliza para
determinar el progreso de la producción en relación con el porcentaje de
conclusión del trabajo. Se enfatizan "los cuellos de botella" más importantes
en el proceso de producción.
La aplicación de los métodos de planeación descritos aquí variará de
proyecto a proyecto y de una organización a la siguiente. Además, la técnica
utilizada puede diferenciarse por cada fase del ciclo de vida del sistema.
Por ejemplo, el uso de PERT/CPM puede ser adaptable en seguida a un
programa de investigación y desarrollo, mientras las gráficas de Gantt son
más adecuadas para un programa de producción.
Al considerar los objetivos de la ingeniería de sistemas, el uso de PERT
/CPM (o un enfoque de una red equivalente), comparada con las gráficas de
barras o con las gráficas con pilares, parece apropiado. Hay muchos
trabajos únicos en su clase, realizados relativamente temprano en el ciclo de
vida del sistema, ¡y las interfaces organizacionales de trabajo son numero-
sas! Se necesita un alto grado de visibilidad a través del proyecto, y es
importante que los problemas potenciales sean detectados tan oportuna-
282 PLANEACIÓN DE LA INGENIEREÁ DE SISTEMAS

mente como sea posible. El uso de la técnica de planeación de la red debe


ayudar a mantener la comunicación necesaria y a proporcionar las funcio-
nes apropiadas de monitoreo y control.

6.2.6 Preparación de las proyecciones del costo del programa9

Un buen control de costos es importante para todas las organizaciones,


independientemente del tamaño. Esto es particularmente verdadero en
nuestro ambiente actual, donde los recursos están demasiado limitados yla
competencia es grande.
El control de costos empieza con el desarrollo inicial de las estimacio-
nes de costos para un programa dado y continúa con las funciones de
monitoreo de costos y la recopilación de datos, el análisis de tales datos y
la iniciación de acción correctiva, antes de que sea muy tarde. El control de
costos implica buena administración global de costos, que incluye la
estimación de costos, la contabilidad de costos, el monitoreo de costos, el
análisis de costos, el reporte y las funciones de control necesarias. De manera
más específica, son aplicables las actividades que siguen:'°

1.Defina los elementos de trabajo. Desarrolle una descripción de trabajo


(SOW) de acuerdo con los requerimientos descritos en la sección 6.2.1.
Los trabajos detallados del proyecto se definen ylos trabajos planeados se
desarrollan, como se vio en la sección 6.2.2. (véase la figura 6.6).
2.Integre los trabajos en la estructura de descomposición del trabajo WBS.
Combine los trabajos del proyecto en paquetes de trabajo, e integre estos
elementos de trabajo en la estructura de descomposición del trabajo (WBS).
Los paquetes de trabajo se identifican contra cada bloque de la WBS.
Entonces, estos paquetes y los bloques de la WBS se relacionan con los
grupos organizacionales, ramificaciones, departamentos, proveedores, etc.
La WBS es estructurada y codificada de tal manera que los costos del
proyecto pueden distribuirse inicialmente (o fijados, y luego recolectados
en contraposición con cada bloque). Los costos pueden acumularse vertical
y horizontalmente para proporcionar figuras de resúmenes para las diver-
sas categorías de trabajo. Los objetivos de la WBS y sus requerimientos se

'Dos referencias que cubren el tema de la estimación de costos son Stewart, R. D., y R. M.
Wyskida, Cost Estimator's Reference Manual, John Wiley,New York, 1987; y Ostwald, P. F., Cost
Estimating 2' ed., Prentice-Hall, Englewood Cliffs, Ni., 1984. Aquí, el énfasis está esencialmente
orientado al cálculo de costos de los trabajos internos del proyecto, Identificados en la WBS,
contra el desarrollo de las relaciones estimadas de costos (CERs) para propósitos de análisis
de costo del ciclo de vida. La cobertura de la LCC se incluye en el apéndice A.
11 El control de costos está cubierto en la mayoría de los textos de administración de programas-
proyectos. Una buena referencia es Kerzner, H., Pmject Management: A Systems Approach fo
Planning. Scheduling and Controlling, 3' ed. Van Nostrand Reinhold, New York, 1989.
PLAN DE ADMINISTRACIÓN DE LA INGENIERÍA DE SISTEMAS (SEMP) 283

describen en la sección 6.2.3 (véase las figuras 6.11 y 6.12 para las funciones
de la ingeniería de sistemas en la WBS).
3.Desarrolle las estimaciones de costos para cada trabajo de! proyecto.
Prepare una proyección de costos para cada trabajo del proyecto, desarro-
lle la contabilidad de costos adecuada y relacione los resultados con los
elementos de la WBS.
4. Desarrolle una recopilación de datos de costos y una capacidad de
reporte. Desarrolle un método para calcular los costos (esto es, la recopila-
ción y presentación de los costos del proyecto), el análisis de los datos y el
reporte de los datos de los costos para propósitos de información para la
administración. Se destacan las áreas más importantes de este asunto, es
decir, los rebases de los costos actuales o potenciales y los "impulsores" de
costos altos.
S. Desarrolle un procedimiento para la evaluación y acción correctiva.
La provisión para retroalimentación y acción correctiva es inherente al
requerimiento global para el control de costos. Conforme se adviertan las
deficiencjas, o se identifiquen las áreas potenciales de riesgos, el adminis-
trador de proyecto debe iniciar la acción correctiva necesaria de manera
expedita. Este requerimiento se trata a profundidad en la sección 6.2.7.

Un paso inicial en el desarrollo de una buena capacidad de costos es


estimar costos y preparar las proyecciones de costos. Cada trabajo se
desglosa en un subtrabajo y otros elementos detallados del trabajo, y las
proyecciones del personal se desarrollan en forma mes por mes. La figu-
ra 6.23 identifica las actividades seleccionadas para un proyecto que
involucra el diseño y desarrollo de un sistema de con fiabilidad a gran escala.
En este caso, se asume un período de 12 meses de diseño y las proyecciones
se hacen en términos de un número de individuos por clasificación reque-
rida para concluir el trabajo, planeada en forma mes por mes. Por ejemplo,
bajo la ingeniería de sistemas hay una necesidad para la valoración para
cuatro personas en el grado de "ingenieros Senior" en el tercer mes del
proyecto. Aunque no se muestra completamente en la figura, todas las
actividades más importantes del programa deben cubrirse a través de un
desglose adecuado de los requerimientos de clasificación de trabajo, es
decir, ingeniero principal, ingeniero Senior, ingeniero, ingeniero Junior,
técnico de la ingeniería, analista, dibujante técnico, especialista de datos y
mecánico de la tienda. Estos requerimientos de recurso son proyectados
para cada trabajo del proyecto y se relacionan a la WBS (por ejemplo,
3A1 200, en las figuras 6.11 y 6.12).
Dada una proyección, presentada en términos de los requerimientos de
trabajo por grado, el siguiente paso es convertirlos en factores de costo en
forma mes por mes. La mayoría de las organizaciones ha establecido
clasificaciones del trabajo con escalas de pago de sueldos calculadas. Estos
factores se usan para estimar los costos directos de trabajo para una
2» • -'

o'

('4 • 2 co 2 u, 2 co u,

E
co • cc • s ccs co

a-
U)

- cc, - • , i2 co La La ('5 La cc) -

cc) (SS • cc co 2 cc, C,J un cc,

• cc, cc) (O N- ('5 ,- ('5 cc)

- ('5 cc) u) cc, ('5 (55 ('5

j_U1-
, gc
°• .2 .2 Q
- =
E 2

g 2222 .
g2
.2
a,

M oaa 2
2 2) a-
O

284
PLAN DE ADMINISTRACIÓN DE LA INGENIERÍA DE SISTEMAS (SEMP) 285

actividad diseñada que se extiende hasta el futuro. Además, los costos de


material son determinados para cada mes y los factores inflacionarios ade-
cuados son añadidos tanto al trabajo como al material. Los resultados netos
incluyen una producción de los costos directos del trabajo y los costos
directos del material, hechos con la inflación necesaria para cubrir las
contingencias económicas del futuro. Estas proyecciones deben, evidente-
mente, apoyar todos los trabajos del programa identificados en la sección
6.2.1. y 6.2.2, y deben ser compatibles con los planes relacionados con los
trabajos descritos en la sección 6.2.5.
Conforme las actividades individuales de proyecto se definan a profun-
didad a través de la preparación de las estimaciones de costos, estas
actividades pueden no sólo estar vinculadas a un bloque particular de la
WBS, sino que los resultados deben asignarse a una contabilidad de costos
específica (véase la figura 6.13). Una estructura desglosada parcial para un
proyecto se presenta en la figura 6.24. El objetivo es mostrar las diversas
contabilidades de costos del proyecto de manera jerárquica, indicando la
estructura que será usada para calcular los costos subsecuentes y para
propósitos de reporte.

Programa 1000 del


sistema XYZ

Administración del Ingeniería de


proyecto 2000 (WBS Datos del diseño 1 1 Soporte del diseño
sistemas 3000
3A1100) (WBS 3AI200) 4000 (WBS 2E1000) 5000 (WBS 2L1000)

Soporte logístico Ingeniería del diseño Software del sistema Prueba y evaluación
integrado 7000 8000 del sistema 9000
6000(WBS (WBS 2C1000) (WBS2F1000) (WBS 2,11000)
3A1600) 11

Ingeniería eléctrica
7100
(WBS SDI 100)

Ingeniería mecánica
7200
(WBS 5D2100)

Figura 6.24. Estructura de descomposición del código contable del costo (parcial).

286 PLANEACIÓN DE LA INGENIERÍA DE SISTEMAS

En relación con la aplicación, la estimación de costos puede realizarse


1 en algún momento o durante alguna fase del ciclo de vida del sistema. Algu-
nas veces, durante las fases iniciales del diseño conceptual y (o) preliminar
del sistema, cuando la disponibilidad de los datos de la ingeniería es
1 limitada, las estimaciones son gruesas, es decir, las aproximaciones son más
o menos un 30% de la realidad. El uso del análisis de regresión, las relaciones
de estimación lineales y no lineales, las curvas de aprendizaje, los análisis
paramétricos, o una combinación de estos, ayuda en el desarrollo de figuras
de mérito (FOMs) de costos. Más tarde, conforme se adquiere experiencia
en la ingeniería, los métodos de estimación son más precisos. Los planes, las
L_I especificaciones, los datos del diseño, las propuestas de costos del provee-
dor, los reportes actualizados de costo para terminar el proyecto, etc., están
disponibles. Las estimaciones de costos, usando datos reales de ingeniería
y (o) el desarrollo de métodos a través de datos análogos, se preparan con
una precisión del orden de más o menos el cinco por ciento.
Al concluir de las proyecciones de costos para trabajos indivi-
duales, uno puede entonces combinarlos en una proyección global de
costos para el proyecto como un todo, como se muestra en la figura 6.25.
Inicialmente, se desarrolla una estimación para todo el trabajo directo, con
un factor de gastos generales organizacionales, aplicado hasta el nivel
superior. Entonces, se determinan los costos directos de material yse aplica
un segundo rango de peso (esto es, un factor general y de administración)
para cubrir algunos costos indirectos asociados con el trabajo y las activi-
dades relacionadas con el material. El resultado neto, entonces, es un costo
global estimado para el proyecto, con objeto de incluir ambos costos,
directos e indirectos. 11

6.2.7 RequerimIentos de reporte del programa

Inherente al proceso de planeación está el establecimiento de ambos


requerimientos, técnicos y administrativos, en el inicio del programa.
Adicionalmente, se necesita revisar el progreso, en contraste con estos
requerimientos, en forma periódica conforme evoluciona el diseño y el
desarrollo del sistema. En caso de que se presenten algunos problemas, es
necesario establecer un procedimiento para la iniciación de la acción
correctiva, según sea necesario.

En la proyección de costos mostrada en la figura 6.25, los costos directos de trabajo fueron
determinados a partir de las figuras de personal de trabajo en la figura 6.23. Una tasa promedio
de $4 000 por hombre-mes fue usada para calcular las figuras de costo mensual. Una tasa de
gastos generales de 200% y una tasa de 20% general y de administración fue usada para fines
ilustrativos. En realidad, cada compañía, organización gubernamental, o equivalente, tendrá
diferentes tasas basadas en los criterios individualmente revisados.
PLAN DE ADMINISTRACIÓN DE LA INGENIERÍA DE SISTEMAS (SEMP) 287

ou

250

200

150

100

50

10 11 12

Tiempo (meses)

Figura 6.25. Proyección del costo del proyecto.

En respuesta, debe desarrollarse un sistema de información para la


administración (MIS) para proporcionar una visibilidad continua, y el
reporte del progreso en contraposición con los costos designados, los
planes y las medidas de desempeño. La información de plan y costos se
- H

8 8 8
8

'o
- o O (a
O

fi 9
(a
2
9
'o

1< 9

fil 'o
(a 1
c'J

2 2
(a 4 (a

(a (a

ID

o
o,

8
E
(o Lxs) samç (S'ous) CdULL

8
E

288
PLAN DE ADMINISTRACIÓN DE LA INGENIERÍA DE SISTEMAS (SEMP) 289

deriva de acuerdo a los procedimientos descritos en la sección 6.2.5 y 6.2.6.


Los reportes periódicos son necesarios a fin de valorar el estatus actual
contra el estatus planeado. La frecuencia de los reportes es una función del
plan del proyecto global y de los riesgos asociados con diversas actividades
del diseño. El proceso de comparación debe tratar asuntos como: ¿Está el
proyecto de acuerdo con lo planeado? ¿Están los costos del programa en las
limitaciones establecidas en el presupuesto? Asumiendo que la carga del
personal actual continúa como hasta ahora, qué trabajos es posible que
estén en una posición "por arriba del costo" seis meses a partir de ahora?
Éstas y otras preguntas de esta naturaleza tendrán que responderse en
muchas ocasiones durante el programa.
La figura 6.26 presenta un extracto que cubre datos de planeación y de
costos. La información del plan (o estatus de tiempo) refleja la salida de una
red típica de PERT/CPM.
En relación con el desempeño, las medidas de desempeño técnico
(TPMs) identificadas en la especificación del sistema y seleccionadas como
criticas a partir de una revisión periódica y un punto de vista de control,
deben incluirse en la estructura de reporte del programa. Estos TPMs
pueden incluir factores tales como rango, exactitud, peso, tamaño,
confiabilidad (MTBF-MTBM), manten ibilidad (2t, MMH-OH), tiempo de
paro de la producción (MDY), disponibilidad, costo, potencia de salida,
tiempo de proceso y otros parámetros que se relacionan directamente con
la misión del sistema que se desarrolla. La figura 5.6 (capítulo 5) ilustra el
proceso de evaluación TPM vinculado a las revisiones del diseño formal.
La medición, evaluación y control de estos parámetros puede también
cubrirse por medio del reporte periódico del programa.
El sistema de información para la administración (MIS) debe aplicarse
en seguida a los problemas existentes, así como también a las áreas
potenciales en las que es posible que ocurran los problemas, si las operacio-
nes del programa continúan como se planearon originalmente. Para ocupar-
se de tales contingencias, la planeación debe iniciarse para establecer un
procedimiento de acción correctiva que incluirá los siguientes pasos:

1. Identificar los problemas (o áreas potenciales del problema) yclasi-


ficarlos por orden de importancia. La clasificación debe considerar la
criticabilidad de la función del sistema.
2. Evaluar cada problema con base en la clasificación tratando primero
los problemas más críticos. Las posibilidades alternativas para la acción
correctiva son consideradas en relación a: a) los efectos en el plan del
programa de los costos; b) efecto en el desempeño y efectividad del sistema;
y c) los riesgos asociados con la decisión, conforme se debe tomar la acción
correctiva. Se identifica la alternativa más factible.
3. Dada la decisión de tomar la acción correctiva, la planeación se realiza
para iniciar los pasos requeridos para resolver el problema. Esto puede ser
290 PLANEACIÓN DE LA INGENIERÍA DE SISTEMAS

en forma de un cambio en la configuración del sistema, un cambio en la


política de administración, un cambio contractual y (o) un cambio
organizacional.
4. Después de que la acción correctiva se implementa, se requiere una
actividad subsecuente para: a) asegurar que el cambio (o los cambios)
incorporado realmente haya resuelto el problema; b) valorar otros aspectos
del programa para asegurar que no se crearon problemas adicionales como
resultados del cambio.

La implementación de los cambios debe, evidentemente, ser compati-


ble con los procedimientos descritos en la sección 5.4. En resumen, el
aspecto de acción-correctiva de la administración de la ingeniería de
sistemas es esencial, si un programa tiene que ser exitoso.

6.3 INTEGRACIÓN DE LOS PLANES DE LA ESPECIALIDAD, DEL DISEÑO


INDIVIDUAL

Un objetivo importante de la ingeniería de sistemas es asegurar la integra-


ción adecuada de todas las disciplinas de ingeniería aplicables al esfuerzo
de diseño total. Aunque hay algunas variantes con cada programa,
¡estas disciplinas identificadas en la figura 6.5 son consideradas como
críticas!
Al referirse al capítulo 3, hay una descripción de los requerimientos para
cada una de las disciplinas. Un análisis de estos requerimientos ilustra la
importancia de la confiabilidad, de la mantenibilidaci, de los factores huma-
nos , de la capacidad de soporte, de la capacidad de producción, de la
calidad, etc., en el diseño. Más adelante, estos requerimientos se inter-
relacionan estrechamente, además de ser "claves" para el proceso de la
ingeniería de sistemas. De este modo, estos factores deben tratarse adecua-
damente en el proceso del diseño, de manera oportuna, y comenzando
desde el inicio durante la fase conceptual del diseño.
A partir de una revisión de las secciones individuales del capítulo 3, se
puede ver que hay muchos trabajos que son similares. El primer trabajo en
cada una de las disciplinas del diseño representadas es la preparación de
un plan del programa, un documento que especifique los trabajos que
deben realizarse a fin de satisfacer los requerimientos del programa. En cada
área de actividad hay trabajos de análisis, trabajos de previsión, trabajos de
revisión y evaluación del diseño, trabajos de prueba y demostración, etc. En
la realización de los compromisos del diseño, como parte de un esfuerzo de
análisis continuo, los resultados netos deben reflejar un planteamiento
balanceado. Esto, a su vez, fuerza la combinación adecuada de las caracte-
rísticas de confiabilidad en el diseño, las características de la mantenibilidad
en el diseño, etc. En otras palabras, ¡estos factores que afectan el proceso de
diseño deben integrarse cuidadosamente!

INTEGRACIÓN DE LOS PLANES DE LA ESPECIALIDAD DEL DISEÑO INDIVIDUAL 291

En el pasado, una práctica común ha resultado en la preparación de es-


tos planes en forma separada e independiente, ya menudo en tiempos dife-
rentes durante el proceso de desarrollo del sistema. Esto ha causado algunas
diferencias en los objetivos indicados, inconsistencia en los planes, redun-
dancias en los requerimientos de los trabajos del programa y conflictos en
la salida. En vista de la importancia de estas disciplinas en él cumplimiento
de los objetivos de la ingeniería de sistemas, se recomienda que se preparen
los planes respectivos y sean integrados al plan de administración de la
ingeniería de sistemas (SEMP). Éste se ilustra en la figura 6.27.
Al referirse a la figura, no se intenta obstaculizar, de ninguna manera, ni
restringir los esfuerzos de las disciplinas individuales a fin de satisfacer los
requerimientos del programa. El propósito es asegurar las propias relacio-
nes entre los diversos trabajos que deben realizarse, así como también
eliminar las redundancias posibles. Por ejemplo, los resultados de la predic-

Plan de administración de ingeniería


de sistemas (SEMP)
Referencia: Figura 6.5

Plan del programa Plan del programa


de confiabilidad de mantenimiento
Ref: Figura 3.11 (Tarea 1) 1 1 Ref: Figura 3.15 (Tarea 1)

Plan de ingeniería de factores Plan del programa de ingeniería


humanos de seguridad
Ref: Figura 3.19 (Tarea 1) Ref: Figura 3.21 (Tarea 1)

Ingeniería logística
Plan de ingeniería de valor/costo
(parte del planLS)
Ref: Figura 3.23 (Tarea 1) Ref: Sección 3.2.8

Plan de ingeniería de calidad


(parte del plan TQM) Plan de ingeniería de software
Ref: Sección 3.2.8 Ref: Sección 3.2.6

Plan del programa de productividad __________________ Planes de otras ingenierías


(manufactura) (como se aplique)

Figura 6.27. La integración de los planes de las disciplinas individuales del diseño.
292 PLANEACIÓN DE LA INGENIERÍA DE SISTEMAS

ción deben alimentarse en la realización de la revisión de confiabilidad ye!


análisis de soporte logístico; la preparación del FMECA constituye una
entrada al análisis de la mantenibilidad y el análisis de soporte logístico,
y debe vincularse al análisis de seguridad, la realización de la mantenibili-
dad, ytambién debe ser compatible con el análisis detallado de los factores
humanos del trabajo del operador; la realización del análisis funcional debe
evolucionar, en cada caso, a partir de, y debe ser compatible con, el análisis
funcional al nivel del sistema, etc. Algunas de estas interfaces se describen
en el capítulo 3 y es importante que éstas se integren adecuadamente a
través del SEMP.

6.4 INTERFACES CON OTRAS ACTIVIDADES DE PLANEACIÓN


DEL PROGRAMA

Aunque es importante proporcionar la integración adecuada de los planes


de las disciplinas individuales del diseño, también es necesario asegurar
que existan los enlaces de comunicación adecuados entre el SEMP y los
otros planes claves seleccionados del programa. De particular interés son
los siguientes:

1.Plan maestro de prueba y evaluación (TEMP). La figura 1.8 identifica la


necesidad de un plan integrado de prueba y evaluación, la sección 2.8
describe los requerimientos de prueba y evaluación del sistema y la impor-
tancia de la prueba y evaluación, conforme se reconoce un trabajo de la
ingeniería de sistemas en la figura 6.6 (trabajos 7y 9). El TEMP proporciona
un enfoque integrado para la evaluación del sistema, es decir, la verificación
del diseño definida a través de las especificaciones, dibujos y bases de datos
que cumplirán los requerimientos del consumidor de manera satisfactoria.
La conclusión exitosa de las funciones de la ingeniería de sistemas se verifica
a través de los requerimientos descritos en el TEMP.
2. Plan de administración de la configuración. La importancia de la
administración de la configuración (CM) se describe en la sección 5.4
(capítulo 5) y en la figura 6.6 (trabajo 10). Mantener la base del diseño
y controlar los cambios en ella es importante para cumplir los objetivos de
la ingeniería de sistemas. Así, debe identificarse un enlace estrecho de
comunicaciones entre el plan CM y el SEMP.
3.Planes deldiseño. En el caso de que se preparen los planes individuales
para cubrir el diseño de la ingeniería eléctrica, el diseño de la ingeniería
mecánica, el diseño de la ingeniería estructural, el diseño de la ingeniería de
materiales, etc., dichos planes necesitan coordinarse con el SEMP.
4.Plan de Soporte Logístico Integrado (JISP). El ILSP cubre el soporte total
del sistema, para incluir la creación inicial de la capacidad de soporte
y seguir con el mantenimiento de apoyo y soporte del sistema a través de su
PLAN DE ADMINISTRACIÓN DE RIESGO 293

ciclo de vida planeado. Como la capacidad de soporte afecta significa-


tivamente el desempeño y efectividad del sistema, es necesario hacer un
buen enlace de comunicaciones entre el ILSPyeISEMP. Más específicamente,
las funciones de la "ingeniería logística" asociadas con el proceso de
creación deben cubrirse en el SEMP.
5.Plan de producción-manufactura. aquellas actividades que se ocupan
del diseño para la capacidad de producción deben incluirse en el SEMP.
Adicionalmente, es necesario hacer un estrecho enlace entre la producción
subsecuente, las actividades de manufactura y el SEMP. Éste incluye la
selección de los proveedores y la consecusión continua de los componen-
tes, operaciones de ensamble y prueba, modificaciones de la producción
y actividades de retrabajo, etcétera.
6.Plan de administración de la calidad total (TQMP). Estas actividades se
ocupan de la ingeniería de calidad que debe incluirse en el SEMP. Además,
es necesario un enlace de comunicación entre la función de la administra-
ción de la calidad total (TQN), como una entidad, y el SEMP.

Aunque la implementación exitosa de un programa de ingeniería de


sistemas requiere de la coordinación estrecha con todas las otras activida-
des relacionadas, es necesario un énfasis especial para asegurar relaciones
de trabajo estrechas con aquellas organizaciones responsables de las
actividades cubiertas por estos planes.

6.5 PLAN DE ADMINISTRACIÓN DE RIESGO


El riesgo es la probabilidad de que algo falle, como resultado de una
ocurrencia o una serie de ocurrencias. Éste se mide como el efecto combi-
nado de la probabilidad de ocurrencia y la consecuencia evaluada, dada tal
ocurrencia. El potencial para los riesgos se incrementa bastante, conforme
se introducen la complejidad y las nuevas tecnologías en el diseño de los
sistemas. El riesgo, tal como se usa en el contexto descrito aquí, se refiere
al potencial de no cumplir un requerimiento técnico especificado y (o) un
requerimiento del programa, por ejemplo, no cumplir un requerimiento
especificado por un TPM, un plan o una proyección de costos.
La administración de riesgos es un método organizado para identificar
y medir el riesgo y para seleccionar y desarrollar las opciones para el manejo
del riesgo. La administración del riesgo no es una acometida por separado del
programa por sí mismo, sino que debe ser una parte inherente de cualquier
administración sólida. La administración de riesgos incluye las siguientes
actividades básicas:

1. Valoración del riesgo. Esto involucra la revisión continua del diseño


técnico y (o) las decisiones de la administración del programa y la
identificación de las áreas potenciales de riesgo.
294 PLANEACIÓN DE LA INGENIERÍA DE SISTEMAS

2. Análisis del riesgo. Esto incluye la realización de un análisis para


determinar la probabilidad de los eventos y las consecuencias
asociadas con sus ocurrencias. Los propósitos del análisis de riesgo
son identificar la causa (o las causas), los efectos y la magnitud del
riesgo advertido, e identificar los enfoques alternativos para la
eliminación de riesgos. Hay muchas herramientas que están dispo-
nibles y pueden usarse como ayuda para realizar los análisis de
riesgos, por ejemplo, el análisis de planeación de la red, el análisis
de los costos del ciclo de vida, el FMECA, el análisis de riesgo y los
estudios de compromisos en sus diversas formas.

3. Abatimiento del riesgo. Esto involucra las técnicas y métodos desa-


rrollados para reducir (si no eliminar) o controlar el riesgo. Puede
implementarse un plan para el manejo del riesgo.

Uno de los primeros pasos en la administración de riesgos es la identi-


ficación de las áreas potenciales de riesgo. Aunque hay un grado de riesgo
asociado con un área de actividad del programa donde las decisiones
deben tomarse, ¡UflO necesita identificar aquéllos en los cuales las conse-
cuencias potenciales de fallas podrían ser importantes! Las áreas de riesgo
del programa pueden incluir el patrocinio, el plan, la relaciones contractua-
les, políticas y técnicas. Los riesgos técnicos se relacionan esencialmente
con el potencial de no cumplir un requerimiento del diseño, no ser capaz de
producir un ítem en múltiples cantidades y (o) que no sea posible soportar
un producto en el campo. Los riesgos de la ingeniería de diseño pueden estar
vinculados directamente con las medidas de desempeño técnico (TPMs)
identificadas en la figura 5.2 (capítulo 5). Estos TPM que reflejan los factores
críticos del diseño, pueden priorizarse para reflejar los grados relativos de
importancia.
Dada la identificación de las características de desempeño para las
cuales debe diseñarse el sistema (esto es, aquellos parámetros que requie-
ren monitoreo en forma regular), el siguiente paso es evaluar esto indicando
las causas posibles de la falla. En el evento de una falla que cumple un
requerimiento del diseño específico, ¿cuáles son las posibles causas y cuáles
son las probabilidades de ocurrencia? Aunque la medida de salida que se
monitorea puede ser un TPM de alta prioridad, la causa de una posible falla
puede ser resultado de un mal empleo de una nueva tecnología en el diseño,
una demora del plan sobre la parte del proveedor más importante, un
exceso del costo o una combinación de estos.
Las causas son evaluadas independientemente para determinar el
grado en que ellas afectan los TPMs que son monitoreadas. Se llevan a cabo
los análisis de sensibilidad, usando diversos modelos analíticos, según sea
apropiado, para determinar la magnitud del riesgo potencial. Esto, a su vez,
derivará en la clasificación de los factores en relación con el riesgo en
PLAN DE ADMINISTRACIÓN DE RIESGO 295

términos de "alto", "medio" o "bajo". Estas clasificaciones de riesgos son


entonces llevadas a la revisión de la administración del programa y a la
estructura del reporte. Los ítems de alto riesgo se monitorean, en gran
medida, con una prioridad relativa más alta al iniciar un plan de abatimiento
de riesgos que los ítems de bajo riesgo.
Para facilitar un proceso de administración de riesgos a menudo es
factible desarrollar un modelo de algún tipo. Un enfoque se ocupa del riesgo
en términos de las dos variables más importantes: la probabilidad de falla
(7) y el efecto o consecuencia de la falla (Ci ). Las consecuencias pueden
medirse con base en el desempeño técnico, costo o plan. Matemáticamente,
este modelo puede expresarse como: 12
Factor de riesgo (RF) = + c- (P)(C1 )
donde Pt es la probabilidad de la falla y C1 es la consecuencia de la falla. Las
relaciones cuantitativas de estos parámetros se describen en la figura 6.28.
Para ilustrar la aplicación del modelo, con la figura 6.28 como fuente
esencial de información, considere las siguientes características del diseño
del sistema:

1. Diseño del uso de hardware disponible, con modificaciones meno-


res al software.
2. El diseño es relativamente simple involucrando el uso de hardware
estándar.
3. El diseño requiere software de complejidad un poco mayor.
4. El diseño requiere una nueva base de datos para desarrollarse con
un proveedor (subcontratista).

Las características del sistema sugieren que hay riesgo potencial asocia-
do con el trabajo del desarrollo del software. Mediante el uso de los criterios
de la figura 6.28 (y aplicando los factores de peso como se indicó), la
probabilidad de la falla (Pr) se calcula como sigue:

P= 0.1,o a) (P) = (0.2)(0.1) = 0.02


0.3, o b) (P)
PMSW = = (0,1)(0.3) = 0.03
= 0. 1, oc) (P) = (0.4)(0.1) = 0.04
= 0.3, o d) (P 5 ) = (0.1)(0.3) = 0.03
PD = 0.09, o e) (Pb) = (0.2)(0.9) =

En base al criterio anterior el P de este ítem es 0.30.


Si la consecuencia de la falla del ítem se debe a problemas causados por

12
Estemodelo se adapta a partir del procedimiento del documento Defense Systems Management
College (DSMC), Systems Engineering Management Guide, Fort Belvoir, Virginia 22060, 1986.
(1) Factor derlesgo = P+C- P.0
(2) P = (a)(PJ + (b)(P) + (c)(PJ + (d)(P) + (e)jP0)

donde y donde: a, b, c, d, y e son lactares de peso donde suman


valores Iguales.
P = Probabilidad de tafia al grado
de madurez del hardware (3) C = (t)(C) + (g)(C) + (h)(C,)
P. = Probabilidad de tafia al grado
de madurez del software C= Consecuencia de talle a factores técnicos
P = Probabilidad de falla al grado C= Consecuencia de falla a cambios en costo
de complejidad del hardware C, = Consecuencia de tata a cambios en el esquema
P = Probabilidad de tafia al grado
de complejidad del software y donde: f, g, y h son factores de peso donde suman valores
P0 = Probabilidad de talla a la iguales.
dependencia onn otros fiems

Factor de madurez Factor de complejidad


(P (Pp)

Hardware Software Hardware Software Factor de dependencia (PO)


Magnitud
g
PMhw PMsw PChw PCgw

0.1 Existe Existe Diseño simple Diseño simple Independiente al sistema existente,
facilidad, o contratista asociado

0.3 Rediseño Rediseño Menor ocre- Menor incemento Esquema dependiente a sistema
menor menor mento en com- en complejidad existente, facilidad, o contratista
pie jidad asociado
0.5 Cambios Cambios Incremento Incremento Desempeño dependiente del desem-
mayores mayores moderado moderado peño dei sistema existente, facilidad,
factibles factibles o contratista asociado
0.7 Tecnología Nuevo soñ- Incremento Incremento mgniti- Esquema dependiente del esquema
disponible, di- ware similar significativo cativo/mayor incre del nuevo sistema, facilidad o contra-
seño complejo al existente mento, en #de tista asociado
módulos
0.9 Estado del arle Estado del Extremadamente Extremadamente Desempefro dependente del es.wma del
de algunas in- arte nunca complejo complejo nuevo sistema, facilidad, o contratista
vestigaciones llegó asociado
completas

Factortécnico Factor costo Factor esquema


Magnitud (C,) (C,)
(C)

0.1 (lento) Mínimo o sin consecuencias, Presupuesto estima no se exce- Impacto despreciable en el programa,
sin importancia deré, algunas transferencias de pequeño cambio en el desarrollo por
dinero le disponibilidad débil del esquema

0.3 (menor) Pequeña reducción Costos estimados exceden el Menor desfiz en esiema (menor de 1
en desempeño técnico presupuesto 1 a 5 por ciento mes) algunos ajustes son requeridos

0.5 (mode- Algunas reducciones Costos estimados exceden el Pequeños deslizamientos en


rado) en el desempeño técnico presupuesto de 5 a 20 porciento esquema

0.7 (signii- Degradación significativa Costos estimados exceden el Deslizamiento de 3 meses


cativo) en el desempeño técnico presupuesto de 20 a 25 por ciento en esquema

0.9 (ato) Metas técnicas no son logradas Costos estimados exceden el Grandes deslizamientos que afectan
presupuesto en un Sopor ciento el segmento o tiene un efecto en el
sistema

Figura 6.28. Un modelo matemático para valoración del riesgo. [Fuente: Defense Systems Management
College (DSMC), Systems Engineering Management Guide, Fort Belvoir, Virginia, 1986].
PLAN DE ADMINISTRACIÓN DE RIESGO 297

factores técnicos de naturaleza correctiva, pero la corrección resulta en un


incremento de 8% de costos y en un corrimiento del plan de dos meses, la
C1 se calcula como sigue:

C 0.3, oí) (C=(0.4)(0.3) = 0.12


C = 0. 5, o g) (Ca) (0.5)(0.5) = 0.25
Cj=0.3,oh)(Cg)=(0.100.3) =
0.40

Basándose en lo anterior (usando los factores de peso indicados), el


factor C1 es 0.40 y, a partir de la ecuación (6.5), el Factor de Riesgo calculado
(RF) es 0.580. Éste puede clasificarse en la categoría de riesgo medio, como
se observó en la figura 6.29. En este caso, el riesgo está esencialmente
asociado con el software del sistema y la dependencia sobre un proveedor.

Análisis de riesgos 1

Identificación de ítems de riesgo

Determinar el potencial Determinar las consecuencias


de falla (Pf 1 1 de falla (Cf)

1 Computar los riesgos

¿Es No ¿Es No
ç7 <ç3

sí sí
Alto riesgo Riesgo medio Bajo ri

1.Reporte de riesgos 1. Reporte de riesgos 1. Revisión regular


2.Plan de abatimiento de riesgos 2. Plan de abatimiento de riesgos 2. Monitoreo de la actividad
3.Revisión especial 3. Flujo normal del programa en el reporte de
estatus del programa

Figura 6.29. Análisis de riesgo y procedimiento de reporte.


298 PLANEACIÓN DE LA INGENIERÍA DE SISTEMAS

Puede aplicarse un enfoque similar al realizar un análisis de riesgo en


todos los otros parámetros aplicables. El resultado neto es el desarrollo de
una lista de Items críticos, presentados por orden de prioridad, que requie-
ren atención especial de la administración. Los reportes de riesgos se
preparan en tiempos diferentes (esto es, frecuencia de distribución), depen-
diendo de la naturaleza del riesgo. Los ítems de alto riesgo requieren
reportes frecuentes y atención especial de la administración, mientras los
ítems de bajo riesgo pueden manejarse a través de la revisión normal del
programa, la evaluación y el proceso de reportes.
Para ítems clasificados de riesgo "alto" y "medio", un plan de abatimien-
to de riesgo debe implementarse. Éste constituye un enfoque formal para
eliminar (si es posible), reducir y (o) controlar el riesgo. La realización de
esto puede involucrar uno o una combinación de los siguientes puntos:

1. Proporcione una revisión de administración incrementada del área


(o de las áreas) del problema, e inicie la acción correctiva mediante
una asignación interna o corrimiento en los recursos.
2. Contrate asesores externos o especialistas para ayudar a resolver
los problemas existentes en el diseño.
3. Implemente un programa de prueba extenso con el objetivo de
aislar de la mejor manera el problema eliminar las causas posibles.
4. Inicie una investigación especial y una actividad de desarrollo,
conducidas en paralelo, a fin de proporcionar una posición de
salida.

El propósito de plan de abatimiento de riesgo es destacar estas áreas


donde se requiere la atención especial de la administración. La identifica-
ción de los riesgos es de interés particular en relación con la ingeniería de
sistemas, ya que la satisfacción de los objetivos de diseño depende en gran
medida del manejo adecuado y expedito de estos riesgos. Respecto a esto,
la administración del riesgo debe ser un aspecto inherente a la administra-
ción de la ingeniería de sistemas.

6.6 RESUMEN

Con la introducción de este capítulo esencialmente orientada al tema de


planear, se ha puesto el mayor énfasis en el desarrollo del plan de adminis-
tración de la ingeniería de sistemas (SEMP). Este documento es el vehículo
por medio del cual las funciones-trabajos de la ingeniería de sistemas se
definen inicialmente y, posteriormente, se implementan. Como este docu-
mento es la clave de los objetivos descritos en este texto, es adecuado
RESUMEN 299

resumirlo a través de una revisión de la lista de verificación presentada más


adelante. Las preguntas de la lista de verificación pertenecen principalmen-
te al contenido del SEMP y la respuesta a cada pregunta debe ser SÍ. Para
preguntas adicionales relacionadas, véase el apéndice B.

1. El SEMP incluye:
a. ¿Una descripción del trabajo (SOW)?
b. ¿La definición de los trabajos de la ingeniería de sistemas?
c. ¿Una descripción de los paquetes de trabajo y una estructura de
descomposición del trabajo (WBS)?
d. ¿Una descripción de la organización del programa-proyecto, la
organización de la ingeniería de sistemas, las interfaces orga-
nizacionales críticas (es decir, interfaces del cliente, interfaces
del productor-contratista, interfaces del proveedor) y procedi-
mientos aplicables a la operación?
e. ¿ Un árbol de especificación-documentación?
f. ¿Un plan detallado del programa?
g. ¿Las proyecciones de costo del programa-trabajo?
h. ¿Un procedimiento para costo-plan-medida de desempeño téc-
nico?
i. ¿Una descripción de los requerimientos del reporte del pro-
grama?
j. ¿Un plan de administración del riesgo?
2. El SEMP describe adecuadamente el proceso de la ingeniería de
sistemas para incluir la cobertura de:
a. ¿El análisis de necesidades?
b. ¿El análisis de factibilidad?
c. ¿ Los requerimientos operacionales?
d. ¿ El concepto de mantenimiento del sistema?
e. ¿El análisis funcional y la distribución?
f. ¿La síntesis del sistema, el análisis y los compromisos?
g. ¿La integración y soporte del diseño?
h. ¿Las revisiones del diseño?
1. ¿La prueba y evaluación del sistema?
j. ¿Producción y (o) construcción?
k. ¿Modificación(es) del sistema?
300 PLANEACIÓN DE LA INGENIERÍA DE SISTEMAS

3. El SEMP incluye los requerimientos para la integración de las


especialidades aplicables de la ingeniería en el proceso de diseño
total a través de:
a. ¿La ingeniería de confiabilidad?
b. ¿La ingeniería de mantenibilidad?
c. ¿La ingeniería de factores humanos?
d. ¿La ingeniería logística?
e. ¿La ingeniería de software?
f. ¿La ingeniería de calidad?
g. ¿La ingeniería de valor/costo?
h. ¿La capacidad de producción?
i. ¿La capacidad de desecho?
4. El SEMP describe el enlace de comunicaciones necesarias con los
otros planes del programa tales como:
a. ¿Plan de administración del programa (PMP)?
b. ¿Plan maestro de prueba y evaluación (TEMP)?
c. ¿Plan de administración de la configuración?
d. ¿Plan de Soporte Logístico Integrado (ILSP)?
e. ¿Plan de administración de datos?
f. ¿Plan de comercialización del sistema?
g. ¿Plan de producción-manufactura?
h. ¿Plan de administración de la calidad (TQMP)?
S. ¿El SEMP apoya los requerimientos de la especificación del sistema
(Tipo "A")?
6. ¿El SEMP apoya adecuadamente los objetivos de la ingeniería de
sistemas?

PREGUNTAS Y PROBLEMAS

1. La planeación de la ingeniería de sistemas comienza en el inicio del


programa con la definición de los requerimientos globales del mismo.
¿Por qué es importante que esta actividad de planeación comience tan
pronto como sea posible? ¿Qué podría suceder si la planeación de la
ingeniería de sistemas se inicia más tarde?
2. ¿Cómo se relacionan la especificación del sistema (Tipo "A") y el plan
de administración de la ingeniería de sistemas la una con la otra?
PREGUNTAS Y PROBLEMAS 301

3. ¿Quién es el responsable de preparar el SEMP: el consumidor, el


productor, el contratista, el subcontratista o el proveedor? Describa
algunas de las condiciones e interfaces según sea pertinente.
4. Seleccione un sistema, describa el proceso de creación y desarrolle un
esbozo detallado de un SEMP para el programa en cuestión.
S. Seleccione un programa y describa los trabajos de selección de siste-
mas para ese programa (justifique los trabajos seleccionados). Identifi-
que alguna de las interfaces claves que existen.
6. Para los trabajos identificados en la pregunta 5, desarrolle: a) un plan
detallado en forma de una red del programa y; b) una estimación del
costo para la actividad propuesta en el plan.
7. Están disponibles los datos siguientes:

Evento Evento previo ta lb fc

8 7 20 30 40
6 15 20 35
5 8 12 15
7 4 30 35 50
3 3 7 12
6 3 40 45 65
3 25 35 50
5 2 55 70 95
4 1 10 20 35
3 1 5 15 25
2 1 10 15 30

Figura 01. Datos del problema 7.

a. Construya una tabla PERT-CPM a partir de los datos anteriores.


b. Determine los valores correspondientes de la desviación estándar,
TE, TL, 7S, TCyP.
c. ¿Cuál es la ruta crítica? ¿Qué significa este valor?
8. Cuando se emplea el PERT-COST, se emplea la opción costo-tiempo.
¿Qué se entiende por opción costo-tiempo? ¿Cómo puede afectar a la
ruta crítica?
9. Describa las relaciones funcionales entre la ingeniería de sistemas
y cada una de las siguientes ingenierías: ingeniería de confiabilidad,
302 PLANEACIÓN DE LA INGENIERÍA DE SISTEMAS

ingeniería de mantenibilidad, ingeniería de factores humanos, ingenie-


ría de seguridad, ingeniería logística, ingeniería de software, ingeniería
de valor-costo, ingeniería de calidad, capacidad de producción y capa-
cidad de desecho.
10. ¿Cuál es el propósito de la WBS? ¿Cuál es la diferencia entre una WBS,
una SWBS y una CWBS? ¿Cómo se relacionan los paquetes de trabajo con
la WBS? Construya una WBS para un programa de su elección.
II. ¿Cuál es la relación entre una WBS y una estructura de descomposición
de contabilidad de costos?
12. ¿Cuál es el propósito de las hojas de análisis de tiempos? ¿De las hojas
de distribución de los requerimientos? ¿De las hojas de los criterios de
diseño? ¿Cómo se relacionan éstas con los análisis funcionales del
sistema?
13. ¿Por qué es important e una buena medida de costo-plan-desempeño,
evaluación ycapacidad de control? ¿Qué atributos deben incorporarse?
14. Suponga que usted es responsable de la administración de una organi-
zación de la ingeniería de sistemas. ¿Qué requerimientos de reporte del
programa-proyecto podría imponer a fin de lograr la visibilidad necesa-
ria para asegurar que se satisfagan los objetivos de la ingeniería de
sistemas?
15. ¿Por qué es importante establecer un buen enlace de comunicación
entre el SEMP y el TEMP? ¿El plan de administración de la configuración?
¿Y el LSP? ¿El plan de producción-manufactura? ¿El plan de administra-
ción de la calidad total (TQMP)?
16. ¿Por qué es importante desarrollar un plan de administración de ries-
gos? ¿Qué se incluye?
7
ORGANIZACIÓN PARA LA INGENIERÍA
DE SISTEMAS

Los aspectos administrativos de la ingeniería de sistemas se inician con la


definición de los requerimientos de planeación del sistema en el capítulo 6.
Un paso subsiguiente necesario es el de la organización.
La organización es la combinación de los recursos, hecha de tal manera
que satisfaga una necesidad. Las organizaciones constituyen un grupo de
personas de diversos niveles de habilidad combinados en una estructura
social de algún tipo para realizar una o más funciones. Las estructuras
organizacionales variarán con las funciones que deben realizarse y los
resultados dependerán de las metas y objetivos establecidos, de los recur-
sos disponibles, de la comunicación y de las relaciones de trabajo de los
individuos participantes, de la motivación y de muchos otros factores.
El objetivo último, evidentemente, es alcanzar la utilización más efectiva de
los recursos humanos, materiales y monetarios mediante el establecimien-
to de la toma de decisiones y de los procesos de comunicación diseñados
para realizar los objetivos específicos.
El satisfacer los objetivos de la ingeniería de sistemas depende en gran
medida de la combinación adecuada de los recursos y el desarrollo de una
buena comunicación. La unicidad de los trabajos y las muy diferentes
interfaces existentes requieren no sólo buenas técnicas de comunicación,
sino también un entendimiento del sistema como una entidad y de aquellas
diversas disciplinas del diseño que contribuyan a su desarrollo. Este capí-
tulo se ocupa de la organización de la ingeniería de sistemas, sus funciones,
las interfaces organizacionales y el adiestramiento del personal necesario
para cumplir los objetivos.'

En este capítulo, el nivel de discusión de los conceptos organizacionales es, por su naturaleza,
bastante superficial, e Intenta proporcionar al lector una visión de algunos puntos claves con
respecto a la ingeniería de sistemas. Un análisis más profundo de la organización y la teoría de
administración se proporciona en algunas partes de las referencias del apéndice D.
304 ORGANIZACIÓN PARA LA INGENIERÍA DE SISTEMAS

7.1 RELACIONES CONSUMIDOR, PRODUCTOR Y PROVEEDOR

Para tratar adecuadamente el tema de la "organización para la ingeniería de


sistemas", es necesario entender el ambiente en el que se desempeñan las
funciones de la ingeniería de sistemas. Aunque esto puede variar un tanto
dependiendo del tamaño del proyecto y de la etapa del diseño y desarrollo,
esta discusión está esencialmente dirigida a la operación de un gran pro.'
yecto, característica para la creación de muchos sistemas en gran escala.
Mediante el tratamiento de los proyectos grandes y los retos ofrecidos, se
espera que se obtenga un mejor entendimiento del rol de la ingeniería de
sistemas en una situación un tanto compleja. El lector debe, evidentemente,
adaptarlo a los requerimientos de su programa-proyecto.
Para-un proyecto relativamente grande, la función de la ingeniería de
sistemas puede aparecer en diversos niveles, como se muestra en la fi-
gura 7.1. El consumidor (el cliente) puede establecer la organización de la
ingeniería de sistemas para realizar los trabajos descritos en el capítulo 6,
o estos trabajos pueden delegarse al productor a través de la forma de una
estructura contractual. La pregunta es: ¿Quién es el responsable y quién
tiene la capacidad para desempeñar las funciones definidas de la ingeniería
de sistemas?
En algunos casos, el consumidor puede asumir la responsabilidad
completa de diseño global y de la integración del sistema. El diseño del nivel
superior del sistema, la preparación de la especificación del sistema, la
preparación del SEMP y la conclusión de los trabajos descritos en la figu-
ra 6.6 se realizan a cargo de la organización del consumidor. Los producto-
res individuales, subcontratistas y proveedores de componentes llevarán
a cabo los trabajos de soporte según sean necesarios.
En otros casos, mientras el consumidor proporciona la guía global en
relación con la emisión de una descripción general del trabajo y (o) un
documento contractual equivalente, el productor (o contratista principal)
es el responsable de mantener el diseño e integración del sistema. En esta
situación, la conclusión de los requerimientos de la ingeniería de sistemas
se realiza por el productor, con los trabajos de soporte que se llevan a cabo
por los proveedores individuales conforme se requiere. En otras palabras,
mientras ambos, el consumidor y el productor, han establecido las organi-
zaciones de la ingeniería de sistemas, el responsable fundamental (y la
autoridad) para satisfacer los objetivos descritos a lo largo de este texto se
vinculan con la organización del productor Este es el modelo que aquí
servirá como la base para muchas discusiones.
Al referirse ala figura 7. 1, el punto principal de énfasis se relaciona con
la gran cantidad de comunicación que existe entre la organización de la
ingeniería de sistemas y otras organizaciones en el proyecto. Las interfaces
son muchas y la realización exitosa de los trabajos de la ingeniería de
sistemas requiere un entendimiento profundo de las responsabilidades
o

305
306 ORGANIZACIÓN PARA LA INGENIERÍA DE SISTEMAS

de los trabajos desempeñados por muchas y variadas entidades organi-


zacionales. No sólo son grandes los requerimientos de comunicación en la
organización del productor perse, sino que debe establecerse la comunica-
ción necesaria de manera ascendente, desde el productor al consumidor, y
de manera descendente, del productor al proveedor.

7.2 ORGANIZACIÓN DEL CONSUMIDOR Y FUNCIONES


(EL "CUENTE")
La organización del consumidor-cliente puede extenderse de un pequeño
grupo de individuos a una firma industrial, una empresa comercial, un
instituto académico, un laboratorio gubernamental, o un servicio militar tal
como la U.S. Air Force (o la U.S. Army o la U.S. Navy). El consumidor puede
ser el último "usuario" del sistema, o puede ser la agencia que atiende al
usuario. Un ejemplo de este último se encuentra en el sector de defensa,
donde la Air Force Systems Command (AFSC) es responsable, básicamente,
de la consecución ycreación de un nuevo aeroplano; el Tactical Air Command
(TAC) es el "usuario"; la Air Force Logistics Command (AFLC) proporciona
el mantenimiento de apoyo y el soporte logístico, y hay un número de firmas
industriales y pequeñas empresas que sirven como proveedores de los
diversos componentes del aeroplano.
Hay una variedad de enfoques y relaciones organizacionales, asociadas,
involucradas en el diseño ydesarrollo de los nuevos sistemas. El objetivo es
identificar al "administrador del programa" global y señalar la responsabi-
lidad y autoridad para la administración de la ingeniería de sistemas. En el
pasado, ha habido muchos casos donde la agencia de atención ha iniciado
un contrato con una firma industrial (por ejemplo, el productor) para el
diseño y desarrollo de un gran sistema, pero no ha delegado la responsabi-
lidad completa (o autoridad) a la administración de la ingeniería de sis-
temas. La compañía se ha mantenido como responsable del diseño, desarro-
llo y asignación de un sistema en respuesta a ciertos requerimientos
especificados. No obstante, el cliente no siempre ha proporcionado al
productor los datos necesarios y (o) el control para permitir proceder al
esfuerzo de desarrollo de acuerdo con una buena práctica de la ingeniería
de sistemas. Al mismo tiempo, el cliente no ha realizado las funciones
necesarias de la administración de la ingeniería. El resultado neto ha sido el
desarrollo de un sistema y la incorporación de las características tratadas
a lo largo del capítulo 3, es decir, un sistema que no es confiable, incapaz de
mantenerse e incapaz de sostenerse, no efectivo en cuanto a costos e
insensible a las necesidades del consumidor o, más específicamente, a las
necesidades del usuario final.
El satisfacer los objetivos de la ingeniería de sistemas depende, en gran
medida, ¡de un compromiso de arriba-abajo! Estos objetivos deben recono-
cerse desde el inicio por el cliente, y la organización necesita establecerse
ORGANIZACIÓN DEL PRODUCTOR Y FUNCIONES (EL «CONTRATISTA") 307

para asegurar que se cumplan estos objetivos. El cliente debe crear el


ambiente adecuado y tomar la iniciativa mediante la iniciación de cada uno
de los siguientes cursos de acción:

1. Realizar las funciones de la ingeniería de sistemas en la estructura


organizacional del cliente (véase la figura 7.1). La preparación de la especi-
ficación del sistema, el SEMP, la reafización de los estudios de factibilidad,
la realización de las revisiones del diseño y la conclusión de los trabajos
identificados en la figura 6.6 (capítulo 6) las realiza el consumidor. En otras
palabras, el trabajo completo de diseño e integración al nivel del sistema se
realizan por el cliente o la agencia de atención.
2. Realizar las funciones de la ingeniería de sistemas en una firma
industrial, es decir, la organización del productor descrita en la figura 7.1.
La preparación de la especificación del sistema, el SEMP, la realización de
los estudios de factibilidad y la conclusión de los trabajos identificados en
la figura 6.6 se ha delegado al productor.

Como la delegación de la autoridad, las responsabilidades y las sub-


secuentes obligaciones no pueden separarse tan claramente como aquí se
infiere, es importante que la responsabilidad de la ingeniería de sistemas se
establezca desde el principio. El cliente debe aclarar los objetivos del
sistema, y las funciones del programa y los requerimientos para la ingeniería
de sistemas deben definirse bien.
En caso de que la responsabilidad de la ingeniería de sistemas sea
delegada al productor (por ejemplo, la segunda opción citada), entonces el
consumidor debe apoyar, esta decisión proporcionando la guía de arriba-
abajo y el respaldo administrativo necesario. Las responsabilidades deben
delinearse adecuadamente; los datos del diseño al nivel del sistema, gene-
rados a través de las actividades iniciales del cliente, deben estar disponi-
bles para el productor (esto es, los resultados de los estudios de factibilidad,
la documentación de los requerimientos operacionales), y debe propor-
cionarse libertad necesaria al productor en relación con la toma de decisio-
nes en el nivel del sistema. El reto para el cliente es preparar una descripción
de trabajo extensa, bien escrita y limpia, que debe implementarse mediante
el productor. Esto, a su vez, forma la base para la negociación de un acuerdo
de contratación entre el cliente y el productor (o contratista). 2

7.3 ORGANIZACIÓN DEL PRODUCTOR Y FUNCIONES


(EL "CONTRATISTA")

Para la mayoría de los proyectos en gran escala, el productor (o contratista)


emprenderá el grueso de las actividades asociadas con el diseño y desarro-

2
A lo largo de este capítulo, los términos "consumidor" y "cliente" se usarán indistintamente.
También, "productor" y «contratista".

308 ORGANIZACIÓN PARA LA INGENIERÍA DE SISTEMAS

¡lo de un nuevo sistema (por ejemplo, la segunda opción descrita en la


sección 7.2). El cliente especificará en el nivel del sistema los requerimientos
M programa, mediante la preparación de una solicitud para una propuesta
(RFP) o un invitación para una oferta (IFB); diversas firmas industriales
cn responderán en términos de una propuesta formal. Como puede haber una
cantidad de proposiciones de respuestas, se iniciará una competencia
formal, se revisarán y evaluarán las propuestas individuales, se llevarán
a cabo las negociaciones y se hará una selección. El contratista ganador
procederá entonces con el nivel propuesto del esfuerzo. Estos procesos se
describen a profundidad en el capitulo 8.
Al tratar los requerimientos del programa, es importante que el contra-
tista tenga acceso a toda la información y a todos los datos que conducen
a los requerimientos en la parte técnica de la RFP-IFB. En un cierto número
de casos, la RFP incluirá una especificación del sistema que cubre los
aspectos técnicos, diseño y desarrollo del sistema, junto con una descrip-
ción de trabajo (SOW) dirigida hacia los trabajos del programa y a los
aspectos de administración de un programa. Generalmente, la preparación
de estas especificaciones evoluciona a partir de los resultados de los
estudios de factibilidad iniciales, los resultados de la investigación, etc.
Posteriormente, esta especificación debe incluir la definición de los reque-
rimientos operacionales, el concepto de mantenimiento, el análisis funcio-
nal de alto nivel, etc., como se describió en la sección 3.1 (véase la figura 3.3).
En otras palabras, en el momento en el que el contratista se ve involucrado,
el cliente debe haber concluido el último de los primeros tres trabajos de la
ingeniería de sistemas, subrayado en la figura 6.6:

1. Realice el análisis de necesidades y lleve a cabo los estudios de


factibilidad (véase las secciones 2.1 y 2.2).

2. Defina los requerimientos operacionales y el concepto de manteni-


miento (véase las secciones 2.3 y 2.4).

3. Prepare la especificación Tipo "A" (véasela sección 3.1 y también la


figura 3.3).

Como el satisfacer los objetivos de la ingeniería de sistemas depende en


gran medida de un enfoque de arriba-abajo, es esencial que se establezca el
nivel adecuado de comunicación hasta este momento, conforme pasamos
de los requerimientos del cliente a las responsabilidades del contratista.
El cliente debe hacer un trabajo completo en la definición de todos los

3 Dependiendo del programa específico, variará la partición de los trabajos de la ingeniería de


sistemas entre el cliente y el contratista. El objetivo principal aquí es asegurar la continuidad
en la transición de las actividades del cliente o contratista.
ORGANIZACIÓN DEL PRODUCTOR Y FUNCIONES (EL "CONTRATISTA") 309

requerimientos del sistema, en caso de que los objetivos de la ingeniería de


sistemas deban satisfacerse.
Este proceso de transición es uno de los puntos más críticos en un
programa. Primero, debe mantenerse el proceso descrito en el capítulo 2,
¡yes esencial un entendimiento minucioso de este proceso tanto por el
cliente como por el contratista! Segundo, debe concluirse la especificación
(o especificaciones) y la descripción del trabajo preparado por el cliente
y ser fácilmente comprensible, y éstas deben fomentar el proceso de la
ingeniería de sistemas descrito en el capítulo 2. A menudo, al intentar
cumplir un plan rutinario, las especificaciones y descripciones del trabajo
se colocarán juntas rápidamente sin la ventaja de una revisión completa
y de la integración adecuada. Los resultados a menudo son desastrosos y las
actividades subsecuentes reflejan inconsistencias y carencia de una inte-
gración adecuada. Finalmente, dada una buena especificación y descripción
del trabajo, las actividades claves de la ingeniería de sistemas no deben
negociarse fuera del desarrollo de un contrato entre el cliente ye! contratis-
ta. La tendencia a eliminar los trabajos de la ingeniería de sistemas para
ahorrar dinero es una falacia y refleja la falta de entendimiento de los
procesos y sus objetivos; sin embargo, esta situación, que algunas veces
ocurre, no se debe permitir.
En cualquier caso, dado que los requerimientos del nivel del sistema son
definidos adecuadamente y que se selecciona un contratista principal para
diseñar y desarrollar un nuevo sistema, el siguiente paso es tratare! tema de
la ingeniería de sistemas en el contexto de la estructura organizacional del
contratista. La estructura organizacional variará desde una mera "estructu-
ra funcional" a una "estructura de línea de producto-funcional", "estructura
matricial", etc. Estos patrones organizacionales se discuten en la sección
siguiente, recordando los objetivos de la ingeniería de sistemas.

7.3.1 Estructura funcional de la organización

El bloque de construcción primario para muchos patrones organizacionales


es la estructura funcional reflejada en la figura 7.2. Este enfoque, algunas
veces referidocomo un enfoque "clásico" o "tradicional", involucra la agrupa-
ción de especialidades o disciplinas en entidades identificadas por separa-
do. El intento es realizar actividades similares en un componente organizacio-
nal. Por ejemplo, todo el trabajo de la ingeniería podría ser la responsabili-
dad de un ejecutivo; todo el trabajo de producción o manufactura podría ser
la responsabilidad de otro ejecutivo, etc. Para fines ilustrativos, la figura 7.3
muestra un desglose profundo de las actividades propias de la ingeniería.
Al referirse a las figuras, la profundidad de los elementos individuales de
la organización variará con el tiempo de proyecto y el nivel de énfasis
requerido. Para los proyectos que involucran el diseño conceptual y (o)
preliminar de tos nuevos sistemas, hay una gran cantidad de énfasis puesto
cXc
E
ca c
a) 0 '2 :2
ca
'2 - - - 2
ci, ca ci, ca
a)
O
-
ca
.
ca
-U
ca
> E

I(E
ORGANIZACIÓN DEL PRODUCTOR Y FUNCIONES (EL "CONTRATISTA") 311

Vicepresidente

Ingeniero

Director de la división
Director de la división Director de la división Director de la división
de prueba
de la ingeniería de de la ingeniería del de aseguramiento del
evaluación de la
sistemas diseño diseño

Jefe del Departa- Jefe del Departa-


mento de Ingeniería mento de Ingeniería
Eléctrica de Confiabilidad

Jefe del Departamento


Jefe del Departamen- 1
1
fo de Ingeniería 1
1 de Ingeniería de la
Capacidad de
Mecánica
i i Mantenimiento

Jefe del Departamen- Jefe del Departamen-


to de Ingeniería de lo de Ingeniería de
Materiales 1 Factores Humanos

Jefe del Departamen- Jefe del Departamen-


to de Ingeniería de fo de Ingeniería de
Software Logística

1
Jefe del Departamentc H Jefe del Departamen-
de la Documentación to de Ingeniería de
de Diseño Valuación-Costo

Figura 7.3. Desglose de las actividades organizacionales de la ingeniería,

en la mercadotecnia yen la ingeniería. En la ingeniería, la organización de la


ingeniería de sistema debe ser altamente influyente en el proceso de la toma
de decisión del diseño, en comparación con alguna de las disciplinas
individuales del diseño. Más tarde, como las fases del proceso de desarrollo
en el diseño de detalle, las disciplinas individuales del diseño también
asumirán un buen grado de importancia y el interés aumentará en cuanto
a producción y manufactura. La figura 7.4 expresa el grado de influencia del
312 ORGANIZACIÓN PARA LA INGENIERÍA DE SISTEMAS

11 Fase del diseño 1 1


Fasedel diseño Fase del diseño de detalle
preliminar
conceptual y desarrollo
del sistema

Afta

Baja
Progreso del diseño y desarrollo del sistema

Figura 7.4. Influencias de la ingeniería de sistemas en el diseño,

diseño presentado en forma relativa. Esta relación también se lleva a través


de la carga de mano de obra proyectada en la figura 6.23 (capítulo 6).
Así, para una estructura organizacional hay ventajas y desventajas.
La figura 7.5 identifica algunos de los pros y los contras relacionados con un
mero enfoque funcional ilustrado en la figura 7.2. Como se muestra, el
presidente (o administrador general) tiene bajo su control todas las entida-
des funcionales necesarias para diseñar y desarrollar, producir, distribuir
y apoyar un sistema. Cada departamento mantiene una gran concentración
de expertos técnicos; así es como un proyecto puede también benefi-
ciarse de la tecnología más avanzada en el campo. Además, los niveles de
autoridad y responsabilidad están definidos claramente, las vías de comu-
nicación están bien estructuradas y el control necesario sobre los presu-
puestos y los costos puede establecerse fácilmente. En general, esta estruc-
tura organizacional está bien adaptada para una operación simple de un
proyecto, grande y pequeño.
Por otra parte, una organización funcional pura no puede ser apropiada
para las grandes firmas o agencias multiproductoras. Donde hay un gran
número de proyectos diferentes, cada uno compitiendo por atención espe-
cial y por las fuentes adecuadas, hay algunas desventajas. El problema
principal es que no hay una autoridad fuerte central, o individual, responsa-
ble del proyecto total. Como resultado, la integración de las actividades que
traspasan las líneas funcionales, se vuelve difícil. Los conflictos suceden
conforme cada actividad funcional lucha por poder y recursos y, a menudo,
las decisiones se toman sobre la base de qué es mejor para el grupo
funcional en vez de qué es mejor para el proyecto. Adicionalmente, los
ORGANIZACIÓN DEL PRODUCTOR Y FUNCIONES (EL "CONTRATISTA") 313

procesos de toma de decisiones son, algunas veces, lentos y tediosos,


puesto que todas las comunicaciones deben canalizarse a través de la
administración del nivel más alto. Básicamente, los proyectos pueden
quedarse atrás y sufrir a consecuencia de la estructura organizacional
funcional clásica.

7.3.2 Estructura de organización de La línea del producto-proyecto

Conforme las firmas industriales crecen y se desarrollan más productos,


a menudo es conveniente clasificar estos productos en grupos comunes
y desarrollar una estructura de la organización de la línea del producto,
como se muestra en la figura 7.6. Una compañía puede verse involucrada en
el desarrollo de los sistemas de comunicación, en los sistemas de transporte
y en el equipo electrónico de prueba y soporte. Donde hay intereses
funcionales en común, puede ser adecuado organizar la compañía en tres
divisiones, una por cada línea de producto. En tales casos, cada división será
suficiente por sí misma en relación con el diseño y soporte del sistema.
Posteriormente, estas divisiones pueden separarse geográficamente y cada
una puede servir como una entidad funcional con operaciones similares
a aquellas descritas en la sección 7.3.1.
En las divisiones donde hay grandes sistemas que deben desarrollarse,
las responsabilidades de la línea del producto pueden dividirse en proyec-
tos, como se ilustran en la figura 7.7. En tales casos, el proyecto será la
entidad menos independiente.
Una organización del proyecto es aquella que responde solamente a la
planeación, al diseño y desarrollo, a la producción y al soporte de un solo
sistema o un gran producto. Está limitada en tiempo, directamente orienta-
do al ciclo de vida del sistema y las obligaciones del personal y del material
están meramente para propósitos de realizar trabajos peculiares para ese
sistema. Cada proyecto contendrá su propia estructura de administración,
su propia función de ingeniería, su propia capacidad de producción, su
propia función de soporte, etc. El administrador del proyecto tiene la auto-
ridad y responsabilidad de todos los aspectos involucrados en el proyecto,
si tiene éxito o si falla.
En caso de ambas estructuras, de línea de producto y de proyecto, las
actividades están organizadas como se presentó en la figura 7.6. Las líneas
de autoridad y responsabilidad para un proyecto dado están claramente
definidas y no hay duda acerca de las prioridades. Por otra parte, potencial-
mente existe la duplicación de actividades en una firma, que puede ser
bastante costosa. El énfasis está en los proyectos individuales en compara-
ción con el enfoque global funcional ilustrado en la figura 7.2. Algunas
ventajas y desventajas de las estructuras del proyecto-línea del producto se
presentan en la figura 7.8.
314 ORGANIZACIÓN PARA LA INGENIERÍA DE SISTEMAS

Ventajas

1. Hace posible el desarrollo de una mejor capacidad técnica para la organización. Los especialistas pueden ser un
grupo para compartir conocimientos. Las experiencias de un proyecto pueden translertrse a otros proyectos a
través del Intercambio de personal El entrenamiento-cruzado es relativamente fácil

2. La organización puede responder más rápido a un requerimiento específico a través de una asignación cuidadosa
(o reasignadón) de personal. Hay un gran número de personal en la organización con el adiestramiento requerido
parauna áreadada. El adminietradortiene un aflogradode flexibilidad en el usode personaly una base más amplia
de mano de obra con la cual trabajar. Puede mantenerse un control técnico mayor.

3. Prestuestary controlarcoslos es fácil, debido a la centralización de las áreas de expertez. Los trabajos comunes
para los diferentes proyectos son integrados y es fácil no sólo estimar costos sino montorear y controlar costos.

4. Las vías de comunicación están bien establecidas. La estructura de reporte es vertical y no hay duda acerca de
quién es el*Jefe'.

Desventajas

1. Es difícil mantener una entidad con un proyecto específico, no sólo una persona es responsable del proyecto total
o de la integración de sus actividades. Es ddlcil señalar las responsabilidades específicas del proyecto.

2. Los conceptosy las técnicas tienden a orientarse funcionalmente un poco en lo que se refiere a los requerimientos
del proyecto. El «diseño" de los requerimientos técnicos para un proyecto particular no se promueve.

3. Hay poca orientación para el cliente apunto focal. La respuesta a las necesidades especificas del cliente es lenta.
Las decisiones son tomadas con base en el área funcional más fuerte de la actividad.

4. A causa de la orientación del grupo en relación con las áreas específicas dolos expertos, hay menos motivación
personal para destacar es poca la innovación concerniente a la generación de nuevas ideas.

Figura 7.5. Una organización funcional: ventajas y desventajas.

1 Compañía ABC 1

Línea T del producto 1 1 Línea Y" del producto 1 Línea Z" del producto 1

Administración del programa • Administración del programa • Administración del programa


Ingeniería de sistemas • Ingeniería de sistemas • Ingeniería de sistemas
Ingeniería eléctrica • Ingeniería eléctrica • Ingeniería eléctrica
Ingeniería mecánica • Ingeniería mecánica • Ingeniería mecánica
Ingeniería de confiabilidad • Ingeniería de confiabilidad • Ingeniería de confiabilidad
Ingeniería de mantenibilidad • Ingeniería de mantenibilidad • Ingeniería de mantenibilidad
Factores humanos • Factores humanos • Factores humanos
Ingeniería de componentes • Ingeniería de componentes • Ingeniería de componentes
Soporte logístico integrado • Soporte logístico integrado • Soporte logístico integrado
(ILS) (ILS) (ILS)

Figura 7.6. Organización tradicional del proyecto-línea del producto.


ORGANIZACIÓN DEL PRODUCTOR Y FUNCIONES (EL "CONTRATISTA") 315

Presidente
Compañía ABC

Vicepresidente
Ingeniería

Director Director Director


Línea T del Línea "Y' del Línea "Z' del
producto. División de producto. División de producto. División del
los sistemas de la transportación de equipo de prueba y
comunicaciones los sistemas soporte

1 Administrador 1 1 Administrador 1 1 Administrador 1

1 Proyecto "A' 1 1 Proyecto 'B' 1 Proyecto "C"


1 1

Figura 7.7. Organización de la línea del producto con las subunidades del proyecto.

7.3.3 Estructura de una organización matricial

La estructura de organización matricial es un esfuerzo de combinar las


ventajas de la organización funcional pura y la organización del proyecto
pura. En la organización funcional, la tecnología se enfatiza mientras los
trabajos orientados al proyecto, los planes y las restricciones de tiempo son
sacrificadas. ¡Para el mero proyecto, la tecnología tiende a sufrir ya que no
hay un solo grupo para planear y desarrollar esto! La administración
matricial es un esfuerzo de adquirir grandes cantidades de una tecnología,
consistente con los planes de proyecto, las restricciones de tiempo y costo
ylos requerimientos relacionados con el cliente. La figura 7.9 presenta una
estructura típica de organización matricial.
Cada administrador del proyecto se reporta con un vicepresidente,
tiene la responsabilidad global y es capaz de informar acerca de lo que
sucede en el proyecto. Al mismo tiempo, los departamentos funcionales son
responsables de mantener la excelencia técnica y para asegurar toda la
información técnica disponible se intercambia entre los proyectos. Los admi-
nistradores funcionales, que también se reportan con un vicepresidente,
son responsables de asegurar que su personal esté al tanto de las últimas
realizaciones en sus respectivas áreas.
La organización matricial en su forma más simple puede considerarse
como una entidad bidimensional, con los proyectos que representan los
316 ORGANIZACIÓN PARA LA INGENIERÍA DE SISTEMAS

Ventajas

1. Las lineas de autoridad responsabilidad para un proyecto dado están claramente definidas. Los participantes del
proyecto trabajan directamente para el administrador del proyecto, las vías de comunicación dentro del proyecto
son fuertes y no hay duda acerca de las prioridades. Se proporciona una buena orientación.

2. Hay una fuerte orientación hacia el diente, un punto focal de la compañía se Identifica en seguida y los procesos
de comunicación entre elclierifey el contratista son refativamentefácltes de mantener. Seda una respuesta rápida
a las necesidades del diente.

3. El personal asignado para el proyecto generalmente demuestra un alto grado de lealtad al proyecto, hay una
motivación fuerte y la moral del personal usualmente es mejor con la identificación y afiliación del producto.

4. El personal experto requerido puede asignarse y contratarse exclusiva mente en el proyecto, sin compartir e¡tiempo
que a menudo se requiere bajo el enfoque funcional.

S. Hay gran visibilidad en relación con las actividades del proyecto. Los progresos de costo, plan y desempeño
pueden monliorearse fácilmente y las áreas potenciales del problema (con la acción correctiva subsiguiente
adecuada) pueden Identificarse con mayor oportunidad.

Desventajas

La aplicación de nuevas tecnologías tiende a sufrir, sin los grupos funcionales fuertes, las oportunidades de
intercambio técnico entreproyecto. Conforme avanza el proyecto, estas tecnologías, que sonaplicablesenel inicio
del proyecto, continúan siendo aplicadas en forma repetifiva. No hay perpetuación de tecnología y se desalienta
la introducción de nuevos métodos y procedimientos.

2. En las orientaciones donde el contratista tiene muchos proyectos diferentes, usualmente hay una duplicación de
esfuerzos, de personal y del uso de instalaciones y equipo. La operación global es ineficiente y los resultados
pueden ser bastante costosos. Hay tiempos arando un enfoque descentralizado completamente no es tan
eficiente, como la centralización.

3. A partir de una perspectiva administrativa, es difícil utilizar personal de manera electiva para transferirlo de un
proyecto a otro. Los trabajadores bien calificados, asignados a los proyectos, son contratados por los administra-
dores de proyectotan prontocomo sea posible (si ellos son utilizados efectivamente ono) y la reasignaclón de este
personal usualmente requiere aprobación porparte de un nivel más alto de autoridad, lo cualpuede fomarbastante
tiempo. El cambio de personal, en respuesta a las necesidades a corto plazo, esencialmente es imposible.

4. La continuación de una carrera del Individuo, su potencial de crecimiento y las oportunidades de promoción
a menudo no son tan buenas cuando se asignó a un proyecto como en periodo extendido de tiempo. El proyecto
de personal está limitado en cuanto a oportunidades para ser innovado en relación con la aplicación de nuevas
tecnologías. La repefifividad de trabajos algunas veces resulta como un estancamiento.

Figura 7.8. Una organización de un proyecto-línea de producto: ventajas y desventajas.

centros potenciales de utilidad y los departamentos funcionales identifica-


dos como centros de costos. Para empresas industriales pequeñas, la
estructura bidimensional puede reflejar el enfoque organizacional preferido
ii

Responsabilidad funciona¡

rti CO
E = O

I) I
o lo 12
--1 - I
E -o 99993 2
I -oI o-

E
0

L__J

317
318 ORGANIZACIÓN PARA LA INGENIERÍA DE SISTEMAS

a causa de la flexibilidad permitida. El compartir el personal y llevarlo de un


lado a otro, son características a menudo inherentes. Por otra parte, en
corporaciones grandes, con muchas divisiones del producto, la matriz se
vuelve una estructura multidimensional.
Conforme el número de proyectos departamentos funcionales se
incrementa, la estructura matricial se vuelve bastante compleja. A fin
de asegurar el éxito en la implementación de la administración matricial,
debe crearse en la compañía un ambiente altamente cooperativo y de apoyo
mutuo. Tanto los administradores como los trabajadores probablemente
estén comprometidos con los objetivos de la administración matricial.
A continuación, se indican algunos puntos claves:

1.Deben establecerse buenas vías de comunicación (vertical y horizon-


tal) para permitir un flujo libre y continuo de información entre los proyec-
tosy los departamentos funcionales. Debe establecerse una buena comuni-
cación de proyecto a proyecto.
2. Tanto los administradores de proyecto como los administradores
funcionales del departamento deben participar en el establecimiento inicial
de los objetivos de la gran compañía, y orientarse al programa. Posterior-
mente, cada uno debe tener una entrada y estar involucrado en el proceso
de planeación. El propósito es ayudar a asegurar el compromiso de ambas
partes. Además, los administradores y funcionales y del proyecto deben
estar dispuestos a negociar los recursos.
3. En caso de conflicto, debe establecerse un método rápido y efectivo
para la resolución. Debe desarrollarse un procedimiento con la participa-
ción y el curso de los administradores funcionales y del proyecto.
4. En el caso del personal que representa las funciones técnicas, y que
se asigna a un proyecto, los administradores, el del proyecto y el adminis-
trador funcional del departamento, deben estar de acuerdo en la elabora-
ción de las tareas, los trabajos que se realizarán y las bases sobre las cuales
él o los individuos serán evaluados. El trabajador individual debe conocer
qué se espera de él, los criterios de evaluación y qué administrador
conducirá la evaluación del desempeño (o cómo se llevará a cabo la revisión
del desempeño). De otra manera, puede desarrollarse una situación de "dos-
jefes" (cada uno con diferentes objetivos) ¡y el empleado se podría quedar
en medio!

La estructura matricial proporciona lo mejor de diversos mundos, es


decir, una composición de un enfoque del mero proyecto y el enfoque
tradicional funcional. La ventaja principal se relaciona con la capacidad de
proporcionar la combinación adecuada de tecnología y de actividades que
se relacionan con el proyecto. Al mismo tiempo, una desventaja mayor se
relaciona con los conflictos que se presentan en forma continua, como
resultado de una estructura de poder entre el administrador del proyecto
ORGANIZACIÓN DEL PRODUCTOR Y FUNCIONES (EL "CONTRATISTA") 319

Ventajas

1. El administrador del proyecto puede proporcionar un fuerte centrol necesario para el proyecto, mientras tenga listo
el acceso a los recursos desde los mini diferentes departamentos orientados funcionalmente.

2. Las organizaciones funcionales existen cemo apoyo para los proyectos. Puede desarrollarse una capacidad
técnica fuerte, y estar disponible en respuesta a los requerimientos de proyecto de manera expedita.

3. El expediente técnico puede intercarrlarse entre los proyectos, con un mínimo de conflictos. El conocimiento está
disponible para todos los proyectos en unas bases iguales.

4. La autoridad y la responsabilidad de la realización de los trabajos de proyecto se comparten entre el administrador


del proyecto y el administrador funcional. Hay un compromiso mutuo para satisfacer los requerimientos del
proyecto.

S. El personal clave puede compartirse y asignarse para trabajar en una variedad de problemas. A partir de la
perspectiva de dirección de la compañía, puede realizarse una utilización más efectiva del personal técnico y,
como resultado, los costos del programa pueden minimizarse.

Desventajas

1. Cada organización del proyecto opera independientemente. En un intento por mantener una identidad, se
desarrolla una operación dividida de los procedimientos, se identifican por separado los requerimientos del
personal, etc. Debe ponerse cuidado extremo para evitar la posible duplicación de esfuerzos.

2. Desde el punto de vista de la compañía, la estructura matriclal puede ser más costosa en términos de
requerimientos administrativos. Ambas áreas de actividad, la del proyecto y la funcional, requieren un control
administrativo similar.

3. Debe definirse claramente, desde el inicio, el balance de poder entre las organizaciones del proyecto y la
organización funcional, y monitorearse estrechamente de allí en adelante. Dependiendo de la fuerza (o debilidad)
de los administradores individuales, el poder y la influencia pueden cambiar, en detrimento de la organización
global de la corr)añia,

4. Desde la perspectiva del trabajador individual, a menudo una partición en la cadena de órdenes para fines de
reporte. El individuo es algunas veces'jaloneado" entre el jefe del proyecto y el jefe funcional.

Figura 7.10. Una organización matricial: ventajas y desventajas.

y el administrador funcional, los cambios en las prioridades, etc. Algunas


ventajas y desventajas se observan en la figura 7.10.

7.3.4 Organización de la Ingeniería de sistemas

Las secciones 7.3.1, 7.3.2 y 7.3.3 proporcionan una panorámica de las


características más importantes de las estructuras de organización funcio-
320 ORGANIZACIÓN PARA LA INGENIERíA DE SISTEMAS

nal, del proyecto y matricial. Se identifican algunas de las ventajas y des-


ventajas de cada una. Es importante entender aun el detalle, y recordar estas
características cuando se desarrolla un planteamiento organizacional que
involucra la ingeniería de sistemas. Más específicamente, cuando se consi-
deran los objetivos de la ingeniería de sistemas, deben observarse los
siguientes puntos:

1. La función de la ingeniería de sistemas debe orientarse al objetivo


de "llevar un sistema a su existencia de una manera efectiva y eficiente".
A este respecto, hay una asociación cercana natural con el tipo del "proyec-
to" de estructura organizacional. La ingeniería de sistemas está fuertemente
involucrada en el establecimiento inicial de los requerimientos y en la
integración subsiguiente de la ingeniería de diseño y de las actividades de
apoyo, a lo largo del desarrollo del sistema, producción y uso operacional.
La ingeniería de sistemas influye en el diseño en un grado importante (véase
figura 7.4) y éste se realiza mejor a través de una estructura organizacional
de proyecto.
2. La naturaleza de la función de la ingeniería de sistemas, sus objetivos
en términos de integración de diseño, sus diversas interfaces con otras
actividades del programa, etc., requieren la existencia de buenas vías de
comunicación (vertical y horizontalmente). El personal en la organización
de la ingeniería de sistemas debe mantener comunicación efectiva con los
demás elementos organizacionales del proyecto, con muchos departamen-
tos funcionales diferentes, con una variedad de proveedores ycon el cliente.
Estos requerimientos se facilitan por medio del enfoque de organización del
proyecto.
3. A fin de cumplir exitosamente los objetivos de la ingeniería de siste-
mas se requiere la especificación de los requerimientos técnicos del
sistema, a realización de los estudios de compromisos, la selección de tec-
nologías adecuadas, etc. El personal en la organización de la ingeniería de
sistemas debe estar al corriente (esto es, actualizado) en relación con las
últimas aplicaciones de la tecnología y (o) debe tener acceso a los expertos
técnicos de las disciplinas adecuadas. Se requiere un fuerte impulso técnico
y debe establecerse una buena comunicación con los departamentos funcio-
nales (según sea apropiado); así, la estructura de la organización preferida
debe incluir los elementos funcionales seleccionados, además de la orienta-
ción del proyecto.

Aunque la implementación de los requerimientos de la ingeniería de


sistemas puede satisfacerse realmente a través de un número de estructu-
ras organizacionales, el enfoque preferido debe responder a estas tres con-
sideraciones importantes. Parece que la mejor estructura organizacional
consiste en una combinación de los requerimientos del proyecto y de los
requerimientos funcionales. Aunque se requiere una orientación más im-
al
o
o
a,
M

ca
tc
ca
CL
o
o

ÍV

321
322 ORGANIZACIÓN PARA LA INGENIERÍA DE SISTEMAS

portante del proyecto, en respuesta a las necesidades del cliente, es


necesaria una orientación funcional para asegurar la consideración de las
aplicaciones de las últimas tecnologías. El enfoque combinado de una
organización de proyecto-funcional puede variar un tanto dependiendo del
tamaño de la firma industrial. Para una empresa grande, puede ser adecuada
la estructura de organización ilustrada en la figura 7.11. Las actividades del
proyecto son relativamente extensas en cuanto al alcance (y en cuanto
a carga de personal) mientras, simultáneamente, hay actividades funciona-
les de apoyo que cubren las áreas seleccionadas de destreza donde la
centralización sejustifica. Para empresas más pequeñas, los departamentos
funcionales resultan relativamente grandes y éstos proporcionan apoyo a
los proyectos individuales con base en la demanda. Este apoyo se asigna
en una base trabajo por trabajo. La figura 7.12 ilustra una estructura
organizacional en la que el énfasis está puesto en el fin funcional del
espectro. En esencia, el grado de énfasis "de proyecto" y énfasis "funcional"
a menudo cambia de un lado a otro, dependiendo del tamaño de la empresa
y la naturaleza de la actividad, es decir, si el diseño conceptual, el diseño
preliminar del sistema, o el diseño detallado y las actividades de desarrollo
están en progreso.
Al referirse a las figuras, puede haber una variación de enfoque en la
misma empresa. Puede existir uno o dos proyectos grandes junto con
numerosos proyectos pequeños. Los proyectos grandes tienden a apoyar
una estructura organizacional similar a la que se presentó en la figura 7.11,
mientras los proyectos pequeños seguramente seguirán el formato de la
figura 7.12. Donde los proyectos grandes pueden tener suficiente dinero
para apoyar un número importante de personal en unas bases de tiem-
po completo, a los proyectos más pequeños les es posible apoyar un
número selecto de individuos en base al tiempo compartido. Los requeri-
mientos específicos se dictan a través de la generación de los trabajos del
programa por la organización del proyecto, es decir, se inicia una solicitud
de asistencia a través el administrador del proyecto, con los trabajos que se
concluyen en el departamento funcional.
El tamaño del proyecto variará no sólo con el tipo de naturaleza del
sistema que se desarrolla, sino con la etapa específica de desarrollo.
Un sistema en gran escala, puede estar representado por una organización
de un pequeño proyecto en etapas iniciales del diseño conceptual, como se
muestra en la figura 7.12. Conforme el desarrollo del sistema avanza en las
fases del diseño preliminar del sistema y el diseño de detalle y desarrollo, la
estructura de la organización puede cambiar un tanto, retomando la confi-
guración de la figura 7.11. En otras palabras, las características y la estruc-
tura de las organizaciones a menudo son, por naturaleza, dinámicas.
La estructura de la organización debe adaptarse a las necesidades del
proyecto en ese momento, y estas necesidades pueden modificarse confor-
me evoluciona el desarrollo del sistema.
ORGANIZACIÓN DEL PRODUCTOR Y FUNCIONES (EL "CONTRATISTA") 323

1 Compañía KLM 1

Administración 1 1 Ingeniería Producción Soporte

Actividades deI
Proyecto 'X" Proyecto 'Y» 1 Proyecto 'Z"

Ingenie
Solicitud de soporte
1

Ingeniería Aseguramiento
de diseño 1 del diseño

Ingeniería de Ingeniería
documentación Trabajos concluidos de software

Ingeniería
de componentes

Soporte Logístico
Integrado (SIL)

Figura 7.12. Organización del productor (estructura de proyecto-funcional).

En relación con la ingeniería de sistemas, los trabajos identificados en


la figura 6.6 (capítulo 6) pueden asignarse por fases, como sigue:

1. Fase del diseño conceptual:


a. Desempeñe el análisis de necesidades y lleve a cabo los estudios
de factibilidad.
b. Defina los requerimientos operacionales y el concepto de mante-
nimiento del sistema.
c. Realice la integración del sistema.
d. Prepare la especificación del sistema (Tipo "A").
e. Prepare el plan maestro de prueba y evaluación (TEMP).
f. Prepare el plan de administración de la ingeniería de sistemas
(SEMP).
g. Planee, coordine y lleve a cabo la revisión del diseño conceptual.
324 ORGANIZACIÓN PARA LA INGENIERÍA DE SISTEMAS

2. Fase del diseño preliminar del sistema:

a. Realice el análisis funcional así como la distribución de los reque-


rimientos.
b. Realice el análisis de sistemas, la síntesis y los estudios de
compromisos.
c. Realice la integración del sistema, es decir, la integración de las
disciplinas del diseño, las actividades del proveedor y los datos.
ci. Planee, coordine y lleve a cabo las revisiones del diseño del
sistema.
3. Fase de diseño de detalle y desarrollo:

a. Realice el análisis del sistema, la síntesis y los estudios de


compromisos.
b. Realice la integración del sistema, es decir, la integración de las
disciplinas del diseño, las actividades del proveedor y los datos.
c. Monitoree y revise las actividades de prueba y evaluación del
sistema.
d. Planee, coordine, implemente y controle los cambios del diseño.
e. Planee, coordine y lleve a cabo las revisiones del diseño del
equipo-software y la revisión del diseño crítico.
f. lniciey mantenga el enlace de producción y (o) construcción y las
actividades del servicio al cliente.
4. Fase de producción y (o) construcción:

a. Monitoreo y revisión de las actividades de prueba y evaluación


del sistema.
b. Planee, coordine, implemente y controle los cambios del diseño.
c. Mantenga el enlace producción y (o) construcción y lleve a cabo
las actividades de servicio al cliente (esto es, servicio de campo).
S. Utilización del sistema y soporte del ciclo de vida:

a. Monitoree y revise las actividades de prueba y evaluación del


sistema.
b. Planee, coordine, implemente y controle los cambios del diseño.
c. Lleve a cabo las actividades de servicio al cliente (esto es,
servicio de campo).
ORGANIZACIÓN DEL PRODUCTOR Y FUNCIONES (EL "CONTRATISTA") 325

d. Recopile, analice y procese los datos de campo. Prepare los


reportes en las operaciones del sistema en el ambiente del
usuario.

Como se indicó en la sección 6.22, estos trabajos reflejan que está


considerado como crítico para la implementación exitosa del proceso de la
ingeniería de sistemas. ¡Esto no significa que implique un tremendo nivel de
esfuerzo! Estos trabajos deben confeccionarse para la aplicación particular,
y la realización de muchos de estos requiere una entrada importante de
otras organizaciones. El objetivo más importante es proporcionar un meca-
nismo para la integración; las interfaces y relaciones entre la ingeniería de
sistemas y otras organizaciones son extensas. Como ejemplo, la realización
de un análisis del costo del ciclo de vida, como parte del trabajo de análisis
global del sistema, involucra un intercambio de datos con todas las organi-
zaciones de la ingeniería relacionadas con el proyecto, el financiamiento
y la contabilidad, el soporte logístico, la producción, el cliente, etc. La meta
de la organización de la ingeniería de sistemas es proporcionar la adminis-
tración técnica y la guía necesarias para asegurar que estas actividades se
concluyan de manera oportuna.
Para ilustrar a profundidad las diferentes interfaces que existen, la
estructura de organización de proyecto-funcional de la figura 7.11 se ha
ampliado para incluir un ejemplo de las vías de comunicación requeridas,
que deben establecerse entre la función de la ingeniería de sistemas y los
otros elementos organizacionales. Estos vínculos de comunicación se mues-
tran en la figura 7.13 y una descripción abreviada cubre la naturaleza de las
comunicaciones necesarias y se presenta en la figura 7.14. La función de la
ingeniería de sistemas como una comisión de integración, no sólo debe
proporcionar el liderazgo técnico a lo largo de la actividad del desarrollo del
sistema, sino que también debe establecer, inicial y posteriormente, mante-
ner abiertas y libres las comunicaciones a lo largo del pánel.4
Al cumplir estos objetivos de la ingeniería de sistemas, el éxito último
está, evidentemente, dependiendo en gran medida del soporte admis-
nistrativo de arriba-abajo. El presidente (o administrador general), el vice-
presidente de ingeniería, el administrador del proyecto "Y" y los otros
administradores de alto nivel deben, cada uno, entender y creer en los
conceptos y objetivos de la ingeniería de sistemas. Para tener éxito, el
administrador de la ingeniería de sistemas debe ser apoyado directamente
por estos administradores de alto nivel todo el tiempo. Habrá algunas

¡No se intenta dar a entender que la organización de la ingeniería de sistemas hace todo! Aquí
el énfasis está en proporcionar un impulso técnico yen asumir un rol de liderazgo técnico en el
diseño y desarrollo del sistema. El administrador del proyecto-programa debe, evidentemente,
proporcionar el liderazgo necesario desde el punto de vista organizacional global.
1
11

JL-
'
• 0,:

- \ 12 UJI u1

1_
a)

111 fi
a)
E

<D 2 L1fl2
I'I
!i
Di CU.O
0.a) a, >

326
ORGANIZACIÓN DEL PRODUCTOR Y FUNCIONES (EL "CONTRATISTA") 327

Canal de Organización de apoyo (requerimientos de interfaz)


comunicación
(figura 7.13)

A 1 Comercialización y ventas. Para crear y sostener las comunicaciones necesarias con el cliente, es
necesaria la información complementarla perteneciente a los requerimientos delcliente, a los requerimien-
tos de apoyo de soporte operacional de mantenimiento del sistema, los cambios en los requerimientos, la
competencia externa, etc. Esto va más allá de la vía «contractuar formal de comunicaciones.
2. Contabilidad Para crear ambos datos, los del Impuesto y los del costo en apoyo a los esfuerzos de análisis
económico (esto es, análisis del cesto del ciclo de vida).
3. Adquisición. Para ayudar a la identificación, evaluación y selección de los proveedores de componentes,
en lo que se refieres las consecuencias técnicas, de calidad y de cesto del ciclo de vida.
4. Recursos humanos. Para solicitar asistencia en el reclutamiento inicial y contratación del personal de la
ingeniería de sistemas, y para el entrenamiento y mantenimiento posterior del adiestramiento del personal.
Para llevar a cabo los programas de entrenamiento para todo el personal del proyecto a lo largo del pánel,
referente a los conceptos de la ingeniería de sistemas, a los objetivos y a la habilitación de los
requerimientos del programa.
S. Administración del contrato. Para mantenerse al día en los requerimientos del contrato (o de naturaleza
técnica) entre el cliente y el contratante. Para asegurar que las relaciones adecuadas se establecen,
y mantienen con los proveedores que están relacionados con el cumplimiento de las necesidades técnicas
del diseño y desarrollo del sistema.

B Para establecer y mantener el enlace continuo y estrechar las comunicaciones con los otros proyectos, con el
objetivo de transferirlos conocimientos que pueden aplicarse en beneficio del proyecto Y'. Para solicitar ayuda
de los otros laboratorios de una gran compañía de Ingeniería orientados funcionalmente y los departamentos
relacionados a la aplicación de nuevas tecnologías, en apoyo de diseño y desarrollo del sistema.

C Para proporcionar un ingreso referente alas requerimientos del proyecto para soporte del sistema y para solicitar
ayuda en términos de los aspados funcionales asociados con el diseño, desarrollo, prueba y evaluación,
producción y mantenimiento de apoyo de una capacidad de soporte a través del ciclo de vida del sistema
planeado.

D Para proporcionar una entrada en relación a los requerimientos del proyecto para la producción (esto es,
manufactura, fabricación, ensamble, inspección y prueba, aseguramiento de la calidad) y para solicitar ayuda
en relación con el diseño para la capacidad de producción y la implementación de los requerimientos de la
ingeniería de calidad, en apoyo del diseño y desarrollo del sistema.

E Para establecer y mantener relaciones estrechas y la comunicación continua necesaria con las actividades del
proyecto como planeación (monitores de las actividades críticas del programa a tras de un enfoque de red
de planeación); la administración de la configuración (la definición de las diversas bases de configuración y el
monitores y control de cambios-modificaciones); administración de datos (el monitoreo, revisión y evaluación
de los diversos paquetes de datos para asegurar la compatloilidad y la eliminación de redundancias innecesa-
rias); y la administración del proveedor (para monftorear el progreso y asegurar la integración apropiada de las
actividades del proveedor).

E Para proporcionar una entrada en relación con los requerimientos del diseño a nivel del Sistema y para
moniorear, revisar, evaluar y asegurar la integración adecuada de las actividades del diseño del sistema. Esto
incluye proveeruna guía, ventaja técnica para la definición de los requerimientos del sistema, la realización del
análisis funcional, la realización de los estudios de compromisos a nivel del sistema y los demás trabajos
del proyecto presentados en la figura 6.6.

Figura 7.14. Descripción de los requerimientos de la interfaz más importante del proyecto.

ocasiones en las cuales los ingenieros individuales de diseño y (o) los


administradores de nivel intermedio se apagarán por sí mismos al tomar
decisiones que provocarán conflictos con los objetivos de la ingeniería de
sistemas. Cuando esto ocurre, ¡el administrador de la ingeniería de sistemas
debe tener el apoyo necesario para asegurar que las acciones se tomen para
que se hagan cosas que nos mantengan sobre la pista! Esta área se trata a
profundidad en la sección 7.5.
328 ORGANIZACIÓN PARA LA INGENIERÍA DE SISTEMAS

7.4 ORGANIZACIÓN Y FUNCIONES DEL PROVEEDOR

El término "proveedor", definido aquí, se refiere a una amplia categoría de


organizaciones que proporcionan los componentes del sistema al produc-
tor (esto es, al contratante).
Estos componentes pueden extenderse desde un elemento grande del
sistema (por ejemplo, una instalación, una tienda de mantenimiento inter-
medio, llena de equipo de prueba, la Unidad "B" del sistema "XYZ") a un ítem
pequeño no reparable (por ejemplo, una resistencia, un contenedor, una
horquilla, un cable). En algunos casos, el componente puede ser de reciente
desarrollo y requerir una actividad detallada de diseño. El proveedor
diseñará y producirá el componente en las cantidades deseadas. En otros
casos, el proveedor servirá como una fuente de manufactura para el
componente. El proveedor será capaz de producir las cantidades deseadas
a partir de un conjunto de datos dado. En otras palabras, el diseño de com-
ponente se ha concluido (ya sea por la misma empresa o por alguna otra),
y las bases y el servicio básico que será proporcionado es la "producción".
Un tercer escenario puede involucrar al proveedor como una fuente de
inventario para uno o más componentes típicos y estándar disponibles en
almacén. No hay actividades de diseño o producción, sino hasta las funcio-
nes de manejo de distribución y materiales. Como se puede ver, los papeles
del proveedor pueden variar significativamente.
En el proceso de identificación y selección de proveedores que propor-
cionan los componentes del sistema, hay un cierto número de asuntos que
deben tratarse. Además de la competencia, hay consideraciones económi-
cas, configuraciones políticas, configuraciones ambientales, etc. Los pro-
veedores a menudo son seleccionados con base en el lugar geográfico, con
la necesidad económica en mente. Esto puede ser deseable para establecer
una gran capacidad de manufactura que ayude a estimular la economía
en un área de depresión. Los proveedores pueden seleccionarse debido a su
ubicación en una jurisdicción política. La selección del proveedor puede
basarse en un asunto ambiental, particularmente si hay un proceso de
producción que afecte el ambiente de manera perjudicial. Más recientemen-
te, ha habido una tendencia importante hacia la "globalización", y los
proveedores se han seleccionado en relación con su nacionalidad. Es pro-
bable que esta validación e intercambio internacional se extienda conside-
rablemente, en vista del crecimiento en las actividades a lo largo de la costa
del Pacífico, con el advenimiento del Mercado Común Europeo en los noven-
tas y cuando se consideran los avances tecnológicos en las comunicaciones,
los métodos de procesamiento de datos ylos sistemas de transportación.
La cantidad de proveedores y la naturaleza de sus actividades están en
función del tipo y de la complejidad del sistema que se desarrolla. Para
grandes sistemas, altamente complejos, puede haber muy diversos provee-
dores localizados a lo largo del mundo, como se ve en la figura 7.15. Algunos
ORGANIZACIÓN Y FUNCIONES DEL PROVEEDOR 329

Figura 7.15. Proveedores potenciales del sistema 'XYZ".

de estos proveedores pueden estar profundamente involucrados en el


diseño y desarrollo de los elementos más importantes del sistema, mientras
los otros proveedores sirven como fuentes de manufactura y para inventarios
seleccionados. Para un sistema de este tipo, usualmente hay una gran
variedad y combinación de actividades.
En lo que se refiere a la ingeniería de sistemas, los requerimientos
especificados por el cliente, e impuestos por el contratista principal del
sistema deben transferirse hacia los diversos proveedores, según sea
pertinente. El contratante prepara una especificación adecuada (Tipo "B",
"C", "D" o "E") para cada requerimiento del proveedor, junto con un apoyo
de la descripción de trabajo (SOW), con los trabajos específicos del provee-
dor del programa ya identificados. Las respuestas del proveedor, en el
contexto de las respuestas formales, se presentan al contratista y se evalúan
como resultado; se hacen selecciones, se negocian los contratos y se imple-
mentan los programas. Este proceso y áreas relacionadas de actividad se
verán a profundidad en el capítulo 8.
Al determinar los requerimientos de la ingeniería de sistemas para
grandes programas donde se requiere diseño y desarrollo, se recomienda
una revisión de ambos trabajos, los trabajos básicos de la figura 6.6 y los
trabajos propuestos conforme se aplican a las diversas fases del programa
de la sección 7.3.4. A partir de esta información, pueden desarrollarse los
requerimientos específicos de trabajo, aquellos que se aplican a la organi-
zación del proveedor. A continuación se presenta un ejemplo de una lista de
los requerimientos del trabajo para un gran proveedor:
330 ORGANIZACIÓN PARA LA INGENIERÍA DE SISTEMAS

1. Lleve a cabo los estudios de factibilidad y defina los criterios del


diseño para los componentes del sistema que se desarrolla. Esta informa-
ción se basa en los requerimientos operacionales del sistema, el concepto
de mantenimiento, el análisis funcional yla asignación de los requerimientos
Ei que se aplican al artículo producido por el proveedor. Dichos requerimien-
tos del proveedor están también incluidos en la especificación del desarro-
llo (Tipo "B"), conforme se aplica. Véase las secciones 2.3, 2.4, 2.5 y 2.6.
2. Prepare el plan de la ingeniería del proveedor, o su equivalente. Este
plan es una ampliación del SEMP y debe reflejar aquellos requerimientos
que apoyan a los objetivos de la ingeniería de sistemas.
3. Realice el análisis, la síntesis y los estudios de compromisos, en apoyo
a las decisiones del diseño de los componentes y cómo afectan ellos los
requerimientos del nivel más alto del sistema. Véase la sección 2.7.
4. Realice la integración del diseño, es decir, la integración continua de
las disciplinas, actividades y datos del diseño. Véase el capítulo 2.
S. Prepare el plan de prueba y evaluación que cubre al componente del
sistema que se desarrolla. Integre las actividades de prueba de los requeri-
mientos de prueba a nivel del sistema cuando sea factible. Monitoree, revise
y evalúe las actividades de prueba del componente llevadas a cabo en la
facilidad del proveedor. Véase la sección 2.8
6. Participe en las revisiones del diseño de equipo-software y en la
revisión del diseño crítico, es decir, en las revisiones del diseño formal que
cubren el componente del sistema que se desarrolla y sus interfaces con los
demás elementos del sistema. Véase el capítulo S.
7. Planee, coordine y monitoree los cambios propuestos del diseño,
cómo se aplican al componente y cómo afectan al sistema global. Véase la
sección 5.4
8. inicie y mantenga el enlace con las actividades de producción-
manufactura que apoyan al componente del sistema. Véase la sección 2.9
9. Inicie y mantenga el enlace con el contratista del sistema durante
todas las fases del programa, cuando las actividades del proveedor están
progresando.

Aunque los proyectos grandes pueden requerir que el proveedor con-


cluya todos estos trabajos, el nivel de actividad obviamente se reducirá
a escala para los proyectos más pequeños. Para los proveedores involucrados
sólo en la producción o manufactura, el foco de atención de la ingeniería de
sistemas está dirigido esencialmente a la administración de la calidad total
(TQM). Es importante asegurar que se mantengan las características inicial-
mente diseñadas para los componentes del sistema, a través de la produc-
ción subsecuente de múltiples cantidades de esos artículos. Como el
proceso de producción es dinámico por naturaleza y a menudo ocurren las
sustituciones de material, es necesario garantizar que cada uno de los
componentes producidos reflejan en realidad las características de calidad
ORGANIZACIÓN Y FUNCIONES DEL PROVEEDOR 331

Contratista
principal
(productor)

Proveedor 1 1 Proveedor 11 Proveedor

Proveedor 1 1 Proveedor 1 1 Proveedor 11 Proveedor

Proveedor¡ Proveedor Proveedor Proveedor Proveedor


1 11 11

Figura 7.16. Estructura típica que involucra el estrato de los proveedores.

inicialmente especificadas a través del diseño (véase la sección 3.2.8). Así,


deben establecerse comunicaciones estrechas con el control de la calidad
del proveedor o la organización de aseguramiento de la calidad.
Al ocuparse de los proveedores de los componentes estándar disponi-
bles en almacén, es importante preparar una buena especificación para la
consecución inicial de estos artículos. Los parámetros de entrada-salida,
tamaño y peso, forma, densidad, etc., deben cubrirse a detalle junto con las
tolerancias permisibles. Las varianzas incontroladas de las características
de los componentes pueden tener un efecto importante en la efectividad
total y la calidad del sistema. Debe mantenerse la intercambiabilidad com-
pleta, eléctrica, mecánica, física y funcional, cuando sea pertinente. Aunque
hay muy diversos componentes que actualmente estén en inventarios
y caigan bajo la categoría de "comunes y estándar", debe ponerse extremo
cuidado para asegurar que los componentes (por ejemplo, aquellos con el
mismo número de partes) están realmente manufacturados con los mismos
estándares. También deben minimizarse las varianzas permisibles acerca
de los parámetros claves.
Al tratar la categoría del "proveedor", a menudo se encuentra un efecto
"de pirámide", como el ilustrado en la figura 7.16. Hay una gran variedad de
proveedores con objetivos y patrones organizacionales variantes. Aunque
muchos están orientados funcionalmente, las prácticas y procedimientos
de cada uno serán diferentes. En cuanto a la ingeniería de sistemas per se,
¡es improbable que la organización del proveedor incluya un departamento,
grupo o sección identificado como tal! No obstante, es necesaria la organi-
zación de las funciones descritas anteriormente (según sea pertinente).
332 ORGANIZACIÓN PARA LA INGENIERÍA DE SISTEMAS

Aunque la responsabilidad global de la ingeniería de sistemas se asigna


al contratista principal, puede haber un elemento responsable organizacional
identificado para la integración técnica de aquellos trabajos asignados
al proveedor. Es importante que los conceptos y objetivos de la ingeniería
de sistemas sean establecidos y entendidos desde el inicio, y la colabora-
ción de cada proveedor es esencial para la realización de estos objetivos.
Desde la perspectiva del contratista principal, ¡la organización y admi-
nistración de la actividad del proveedor presenta muchos retos! No sólo hay
muchos tipos diferentes de proveedores, con niveles variantes de respon-
sabilidad, sino también hay aquellos que pueden localizarse a lo largo de
Estados Unidos, Canadá, México, África, Asia, Europa, Sudamérica, etc. Esto
es verdad particularmente para los proyectos grandes, aquéllas donde el
proveedor es responsable de los elementos más importantes del sistema.
En tales casos, el ingeniero de sistemas debe asegurarse de que el nivel
apropiado de integración del diseño se mantiene durante el proceso de
desarrollo del sistema. Éste comienza con la definición inicial de los reque-
rimientos del proveedor y la preparación de las actividades. Posteriormen-
te, se realiza la integración del diseño a través de una buena comunicación
y la revisión periódica de la documentación del diseño, la realización de las
revisiones del diseño, etc. El establecimiento de las comunicaciones exitosas
usualmente depende del entendimiento completo, por parte del ingeniero
de sistemas, del ambiente en que opera el proveedor. Por ejemplo, en el
terreno internacional, el ingeniero de sistemas debe tener un entendimiento
básico de la cultura, costumbres y prácticas, requerimientos de exportación
e importación, distribución geográfica, enlaces de comunicación y trans-
portación y fuentes disponibles en cada una de las nacionalidades que
proporcionan los componentes del sistema. Es importante un conocimiento
del lenguaje, e interpretación del mismo, como se aplica en las especificacio-
nes yen los datos del diseño. En algunos casos, esta área de actividad debe
ser creciente en importancia conforme se acentúa el fenómeno de la
globalización.

7.5 REQUERIMIENTOS DE LOS RECURSOS HUMANOS

Para completar nuestra discusión de los elemen,tos organizacionales de la


ingeniería de sistemas, es necesario proporcionar una cobertura de los
requerimientos de los recursos humanos, el cuerpo de una organización de
ingeniería de sistemas y el personal de desarrollo. Aunque habrá variacio-
nes en cada situación, hay ciertos objetivos que deben cumplirse desde el
punto de vista del empleado.
REQUERIMIENTOS DE LOS RECURSOS HUMANOS 333

7.5.1 Ambiente organizacional

La naturaleza de las actividades de la ingeniería de sistemas requiere la


consideración de las siguientes características al desarrollar una estructura
organizacional:
1. El personal seleccionado para el grupo de la ingeniería de sistemas
debe ser, en general, individuos altamente profesionales de nivel senior, con
experiencia variada y una gran amplitud de conocimiento; por ejemplo, un
entendimiento de la investigación, diseño, manufactura y de las aplicacio-
nes de soporte del sistema. El énfasis está en el diseño global del nivel del
sistema y las aplicaciones de la tecnología, con el conocimiento de las
operaciones del usuario y el mantenimiento del soporte del ciclo de vida en
mente.
2. El grupo de la ingeniería de sistemas debe incorporar la "visión" y ser
"creativo" en la selección de las tecnologías para el diseño, manufactura
y aplicaciones del soporte. El grupo de personal estará buscando continua-
mente nuevas oportunidades, debe ser innovativoy aplicar la investigación
que a menudo se requiere, a fin de resolver problemas técnicos específicos.
3. Debe iniciarse un enfoque de trabajo de equipo en el grupo de la
ingeniería de sistemas. El personal asignado debe comprometerse con los
objetivos de la organización: hay un cierto grado de interdependencia
requerida y hay confianza y respeto mutuo.
4. Debe prevalecer un alto grado de comunicación entre el grupo de la
ingeniería de sistemas y las muchas otras funciones relacionadas asociadas
con un proyecto dado (véase la figura 7.13). La comunicación es un proceso
de dos sentidos, y puede realizarse por medios escritos, verbales y (o) no
verbales. La buena comunicación debe existir, primero, en la organización
de la ingeniería de sistemas.Con esto, es necesario desarrollar una comuni-
cación, de dos vías externas, usando ambos canales, el vertical y el horizon-
tal, según se requiera.'
Dados los objetivos descritos en este texto, y con estas consideraciones
en mente, debe crearse un "ambiente" adecuado para permitir la realización
de los trabajos de ingeniería de sistemas de manera efectiva. El ambiente, en
este caso, se refiere a ambos ambientes de trabajo: 1) el ambiente de trabajo
externo a la función de la ingeniería de sistemas, pero en la estructura
organizacional del contratista y, 2) el ambiente de trabajo en el grupo mismo
de la ingeniería de sistemas.
La creación de un ambiente favorable en la organización del contratista,
o en alguna otra estructura organizacional que se trata, ¡debe empezar

Los procesos básicos de comunicación organizacional se ven a detalle en muchos textos que
tratan la teoría organizacional o el diseño organizacional. Una buena referencia es Griffin R. W.
y G. Moorhead, OrganizationalBehavior. Houghton, Mifflin, Boston, 1986.
334 ORGANIZACIÓN PARA LA INGENIERÍA DE SISTEMAS

desde la cima! El presidente, o el administrador general, debe creer inicial-


mente en él y, subsecuentemente, soportar los conceptos y objetivos de la
ingeniería de sistemas. En numerosas ocasiones, ocurrirá la lucha por el
poder, se desarrollarán conflictos organizacionales en metas y objetivos
y habrá una falta de comunicación entre las entidades organizacionales
claves.
Esto, a su vez, lleva a redundancias, a la contratación de personal no
calificado y en la adquisición de recursos no necesarios, que derivan en
gastos. Debe establecerse un mecanismo para dar solución rápida al con-
flicto, y todo el personal del proyecto debe saber que prevalecerá la filosofía
de la ingeniería de sistemas, en vez de los intereses individuales. La alta
administración debe crear este entendimiento desde el principio.
Segundo, el nivel apropiado de responsabilidad y autoridad, debe
delegarse desde la cima, hasta el vicepresidente de la ingeniería y el
administrador de programas y al administrador del departamento de la
ingeniería de sistemas (véase la figura 7.11). Las responsabilidades deben
definirse desde el nivel correspondiente de autoridad, para controlar y di-
rigir los medios mediante los cuales la actividad debe realizarse, lo cual
debe delegarse acordemente. Muy a menudo un administrador está de
acuerdo con delegar la responsabilidad de una actividad particular a un
subordinado, pero mantendrá la autoridad para controlar los recursos
necesarios para la conclusión del trabajo. En esta situación, el individuo
asignado a esta responsabilidad es ineficaz cuando llega a la utilización
completa de los recursos disponibles y, cuando piensa que se equivocó, no
puede responder en relación con el inicio de la acción correctiva apropiada.
Se desalienta, le falta motivación y, por último, decae el nivel de produ-
ctividad. En esencia, se le debe dar la responsabilidad, la autoridad y los
recursos para hacer el trabajo asignado al administrador de la ingeniería de
sistemas.
Como tercer punto, se deben establecer las relaciones adecuadas entre
el vicepresidente de ingeniería, el administrador del programa y el adminis-
trador de la ingeniería de sistemas, como se vio en la figura 7.11. Estas
relaciones, evidentemente, dependen en gran medida de los estilos adminis-
trativos de los individuos en estas posiciones. Aunque hay muchas varian-
tes, los dos estilos administrativos que menudo deben discutirse son el
enfoque "autocrático" y el enfoque "democrático".
El concepto autocrático es básicamente dictatorial por naturaleza y es
restrictivo en que las decisiones generalmente son unilaterales, es decir,
las decisiones se toman de arriba abajo, sin el concurso de quienes son re-
queridos para llevar a cabo estas decisiones. Los administradores contro-
lan, dirigen, obligan y aun amenazan a los empleados para forzarlos a trabajar
hacia las metas organizacionales especificadas. Por otra parte, el concepto
democrático es participativo, no amenazante, ylos intereses organizaciona-
les están enfocados al grupo. El tema general, entonces, es que los mdi-
REQUERIMIENTOS DE LOS RECURSOS HUMANOS 335

viduos del grupo tienen voz en materia de lo que les afecta directamente.6
Aunque ambos estilos de administración prevalecen en ciertas situacio-
nes, el estilo democrático ha sido aceptado como el más efectivo desde el
punto de vista motivacional. En general, la gente trabaja arduamente,
coopera más y está más de acuerdo en aceptar los cambios, si siente que
tiene una influencia en los resultados. El liderazgo democrático implica un
ambiente organizacional en el cual los empleados tienen la oportunidad de
crecer y desarrollar sus habilidades, cuando se considera la supervisión
formal, no es arbitraria la aplicación de órdenes y se solicitan y respetan las
opiniones de los individuos. En comparación con el enfoque autocrático, la
administración democrática está comprometida con el reconocimiento de
los empleados profesionales de alto nivel y no meramente como factores en
el esquema de producción.'
En cuanto a los niveles de sistemas, debe crearse un ambiente a fin de
permitir la iniciativa individual, la creatividad, la flexibilidad, el desarrollo
del personal, etc. Parece apropiado un enfoque democrático y participativo,
para cumplir los objetivos indicados. Aunque el administrador debe mante-
ner la autoridad y proporcionar la dirección necesaria y el control para
realizar las metas y objetivos de la organización efectivamente, él o ella
pueden introducir algunas prácticas que apoyen directamente el estilo
democrático. El estilo elegido ayudará, con gran optimismo, a crear un
ambiente favorable para la realización de los trabajos de la ingeniería de
sistemas. Esto está influido no sólo por el estilo administrativo empleado en
el grupo mismo de la ingeniería de sistemas, sino también por el enfoque
empleado por la administración de más alto nivel que tiene un efecto en el
grupo. Crear un ambiente así es crítico para los objetivos establecidos
durante este texto. Hay ejemplos en los que dos (o más) organizaciones
similares tienen los mismos objetivos básicos, la misma estructura, los
mismos títulos de puestos, etc., ¡pero uno es productivo y el otro no!
La productividad de alto nivel está en función del ambiente de trabajo.

7.5.2 Características de liderazgo

La organización de la ingeniería de sistemas se compone de un grupo de


individuos con habilidades variables y roles y expectativas diferentes,

6
Estos conceptos están relacionados con los análisis administrativos, descritos como "teoría
X" y "teoría Y" por Douglas McGregor, en su libro clásico, The Human Side of Enterprise, que se
recomienda leerlo para un entendimiento más meticuloso de movimiento de relaciones
humanas desarrollado en los años cuarentas.
Se recomienda en este punto una revisión de la literatura de la motivación humana. Buenas
referencias son: Maslow, A.H., "A Theory of Human Motivation", Psychological Review, julio de
1943; Herzberg, F.B. Maunsner y B. Snyderman, The Motivation fo Work, John Wiley, New York,
1959; y Myers, M. 5., "Who Are your Motivated Workers", Harvard Business !?eview, 1970.
336 ORGANIZACIÓN PARA LA INGENIERÍA DE SISTEMAS

diversas metas personales, distintos patrones de conducta. Aunque los


individuos de la organización dependen en gran manera de algún otro in-
dividuo, a menudo jalan en direcciones diferentes a causa de alguno de estos
factores. El reto para el administrador de la ingeniería de sistemas es
integrar diversas características en una fuerza cohesiva, que lleva a la
realización de los objetivos organizacionales. El administrador no sólo debe
asegurarse de que el trabajo se concluya de manera satisfactoria, sino que
también él (o ella) inspirará y motivará con optimismo a sus subordinados
para destacar en el cumplimiento de los objetivos organizacionales.
Es aparente que el administrador debe crear un clima que presente retos
(no amenazas) para los individuos involucrados.
Para facilitar este objetivo, el administrador debe iniciar ciertas prácti-
cas que respondan a ambas necesidades, a las necesidades de la organiza-
ción y a las necesidades individuales de la gente de la organización. Como
un inicio, el estilo democrático de liderazgo, analizado en la sección 7.5.1,
tiende a fomentar el ambiente necesario para la organización. En este
esquema, el administrador debe alentar la participación de los individuos en
el establecimiento de las metas yen la toma de decisiones, y debe fomentar
la comunicación. Para hacer esto, él (o ella), no sólo tenderán a proporcio-
nar la motivación desde aquí, sino creará un mejor entendimiento entre los
individuos de la organización. Este entendimiento puede mejorarse tenien-
do en consideración los siguientes pasos:

Reconozca las características personales de cada individuo de la


organización a fin de que el individuo cumpla mejor con los reque-
rimientos de trabajo. Una persona puede destacar en una situación
mientras hace sólo un trabajo mediocre en otra situación, aunque la
habilidad al hacer ambos y el clima global de la organización
permanezca relativamente constante. En esencia, el administrador
debe asignar los empleados al tipo de trabajo que ellos hacen más
eficientemente. Una salida de alta calidad es importante si la orga-
nización de la ingeniería de sistemas obtiene el respeto y mantiene
un papel de liderazgo en un proyecto.
2. Inspire a cada individuo para que destaque en su trabajo, creando
una atmósfera de interés personal. Un empleado tenderá a desem-
peñarse mejor si él (ella) sabe que el jefe está personalmente
interesado. El objetivo del personal es desarrollarse a través de
involucrarse en el nivel del empleado.
3. Sea sensible a los problemas del empleado, de manera que cada uno
pueda tratarse en términos personales. La solución a un problema
debe, si es posible en todos los casos, considerar los efectos sobre
el empleado individual.
REQUERIMIENTOS DE LOS RECURSOS HUMANOS 337

4. Evalúe a los empleados en forma personal e inicie recompensas en


cuanto las merezcan. Los ascensos y los aumentos merecidos no
sólo deben orientarse a la jerarquía organizacional, sino también
deben dirigirse al mejor desempeño.

Una buena comunicación y una buena confianza con los empleados


debe crearse desde el inicio. Lograr el ambiente deseado dç la organización
no sólo depende del esfuerzo del administrador de establecer inicialmente
tales prácticas, sino también, yen gran medida, de su habilidad de liderazgo
personal al dirigir las actividades de la organización en el tiempo. La mejor
planeación en el mundo tendrá pocos beneficios, a menos que las acciones
que siguen la fase de implementación la apoyen. Como meta, el administra-
dor debe esforzarse por mostrar las características listadas en la figura 7.17.

7.5.3 Las necesidades de los individuos

Con la discusión hasta aquí, que cubre esencialmente el ambiente de la


organización y las características deseadas de liderazgo, ahora es importan-
te que nuestra atención se dirija hacia las necesidades del empleado
individual. Si el administrador está para inspirar, motivar y tratar con
optimismo a sus subordinados, entonces es necesario un buen entendimien-
to de estas necesidades.
Como punto de vista, el lector debe primero revisar la teoría de A. H.
Maslow, que trata la jerarquía de las necesidades. La teoría fue desarrollada
para identificar por separado relativamente y distinguir los impulsos que
motivan a los individuos en general. Se identifican las siguientes cinco
necesidades básicas:

1. Las necesidades psicológicas tales como el hambre, la sed, el sexo,


el sueño. Éstas constituyen las necesidades del cuerpo y, a menos
que estén satisfechas básicamente, permanecen como los factores
esenciales influyentes en la conducta de un individuo.
2. La seguridad y las necesidades de seguridad que incluyen protec-
ción contra el peligro, contra las amenazas y contra la privación.
Habiendo satisfecho las necesidades corporales, la seguridad y la
necesidad de seguridad se vuelven la meta dominante.
3. La necesidad de amor y de estimación por los demás olas necesida-
des sociales. Esto incluye el pertenecer a los grupos que dan y pro-
porcionan amistad y similares.

Maslow, A. H., "A Theory of Human Motivation", PsychologicalReview, Julio de 1943.


338 ORGANIZACIÓN PARA LA INGENIERÍA DE SISTEMAS

Características de liderazgo

1. Aceptación: se gana el respeto y tiene la confianza de los demás.


2. Realización: usa efectivamente el tiempo para cumplir las metas y los objetivos.
3. Agudeza: se mantiene alerta mentalmente y comprende en seguida las Instrucciones, las explicaciones y las
circunstancias inusuales.
4. Administración: organiza su propio trabajo y el de sus subordinados; delega responsabilidad y autoridad, mide, evalúa
y controla las actividades de los puestos.
5. Análisis y juicio: realiza evaluaciones criticas de potencial y rebasadas áreas comunes del problema; separa el
problema en componentes; relaciona las afiemativas y arriba y llega a conclusiones correctas.
6. Actitud: entusiasta; optimista y leal a la empresa-agencia, al superior, al puesto y a los asociados.
7. Comunicación: promueve la comunicación en y entre los elementos de la organización.
8. Creatividad: tiene una mente curiosa; desarrolla Ideas originales, e Inicia nuevos enfoques de los problemas.
9. Capacidad de decisión: toma decisiones pronto, cuando es necesario,
10. Capacidad de dependencia: cumple los planes y techas de manera consistente y se adhiere a las políticas de los
procedimientos de la empresa-agencia.
11. Otras habilidades: desarrolla remplazos y sucesores competentes.
12. Adaptabilidad: se ajusta rápidamente a las condiciones cambiantes y hace frente a lo inesperado.
13. Relaciones humanas: es sensible y entiende las interacciones del personal; tiene sentido deJos individuos y reconoce
sus problemas; considera a los demás; tiene habilidad para motivar y lograr que la gente trabaje conjuntamente.
14. Iniciativa: iniciativa propia; impulso para tomar dirigir, busca y actúa en las nuevas oportunidades; muestra ato grado
de energía al trabajar, no se decepciona fácilmente, y posee a urgencia básica para lograr hacer las cosas.
15. Conocimientos: posee conocimientos (amplios y profundos) de las habilidades necesarias para satisfacer los
requerimientos del puesto; usa la intorrnacióny los conceptos de otras áreas del conocimiento; y generalmente entiende
el contexto general.
16. Objetividad: tiene una mente abierta y toma decisiones sin la Influencia del personal ni dolos intereses emocionales.
17. Planeación: se anticipa; desarrollando nuevos programas, preparando planes; y planeando los requerimientos.
18. Calidad: es apto y meticuloso en el trabajo y, consistentemente, mantiene altos estándares.
19. 'Confianza en sí mismo: aplomo; seguridad en si mismo; confía en él; y, toma los nuevos desarrollos con calma.
20. Control de sí mismo: se calma y se serena, aun bajo presión.
21. Motivaciónpor si mismo: tiene sus metas bien planeadas; está de acuerdo con asumir grandes responsabilidades;
ambicioso de manera realista y, generalmente, es entusiasta por progreso propio.
22. Sociabilidad: hace amigos fácilmente; trabaja bien con los demás, y tiene sincero interés en la gente.
23. Habilidad verbal: se comunica claramente y es generalmente entendido por las personas en todo.

Figura 7.17. Lista deverificaciÓn de (as características de liderazgo. Fuente: Blanchard, B. S., Engineering
Oganization andManagement, Prentice-Hall, Englewood Cliffs, N.J., 1976.

4. La necesidad de autoestima o respeto por sí mismo y de respeto


a los demás (esto es, la necesidad del ego). Un individuo necesita
considerarse fuerte, capaz, competente y básicamente digno de sus
estándares.

S. La necesidad de satisfacerse a sí mismo o el alcanzar completamen-


te el potencial de uno a través del propio desarrollo, la creatividad
y la expresión de sí mismo. Ésta se relaciona con el deseo del
hombre por crecer desarrollarse hasta el punto de un potencial
completo y, por último, alcanzar el nivel más alto posible.
REQUERIMIENTOS DE LOS RECURSOS HUMANOS 339

Las necesidades se relacionan mutuamente y están dispuestas a fin de


que estimulen la conciencia y la actividad. Cuando una necesidad se satisface,
el énfasis de la actividad cambia a la siguiente categoría de necesidad.
En otras palabras, una necesidad satisfecha no es ya un motivador y la
siguiente necesidad se vuelve el factor impulsor.
Mientras Maslow trata la jerarquía global de las necesidades desde un
punto de vista general, Herzberg conduce la investigación, que resulta en su
teoría de "motivación-higiene" que identifica los factores comúnmente
conocidos como "satisfactores" y "desatisfactores". La teoría fue desarrolla-
da a partir de la investigación relacionada con las aptitudes en el trabajo de
20 ingenieros y contadores, y se basó en dos preguntas: 1) "Puede usted
describir a detalle, cuándo se sintió excepcionalmente bueno en relación
con su trabajo?" y, 2) "Cómo describe, a detalle, cuándo usted se sintió
excepcionalmente malo en relación con su trabajo?" Los resultados fueron
clasificados en dos categorías, identificadas a continuación.'

1. Satisfactores

a. Realización. Satisfacción personal en la conclusión del trabajo


y en la resolución de un problema.
b. Reconocimiento. Reconocimiento de una realización (por ejem-
plo, un trabajo bien hecho).
c. Trabajo por sí mismo. Realmente contento con el trabajo y sus
efectos positivos-negativos en el empleado.
d. Responsabilidad. Responsabilidad y autoridad en relación con el
trabajo.
e. Progreso. Ascenso en el trabajo.
f. Desarrollo. Aprende las nuevas habilidades que ofrecen grandes
posibilidades de progreso.
2. Desatisfacto res
a. Política de administración de la compañía. Los sentimientos
acerca de la adecuación y la inadecuación de la organización de
administración, políticas y procedimientos de la compañía, etcé-
tera.
b. Supervisión. Competencia o habilidad técnica de supervisión.
c. Condiciones de trabajo. Ambiente físico en el trabajo.

Herzberg. F., "Work And Motivation", Studies in Personnel Policy Number 216: Behavoiral
Science, Concepts. AndManagementApplication, National Conference Board, New York 1969.
340 ORGANIZACIÓN PARA LA INGENIERÍA DE SISTEMAS

d. Relaciones interpersonales. Relaciones con los supervisores,


subordinados y compañeros.
e. Salario. Pago y beneficios complementarios.
f. Estatus. Ítems diversos tales como tamaño de la oficina, tener una
secretaria y un lugar privado de estacionamiento.
g. Seguridad en el trabajo. Planta, estabilidad o inestabilidad de la
compañía.
h. Vida personal. Factores personales que afectan el trabajo (por
ejemplo, problemas familiares, problemas sociales).

La mayoría de estos factores tiene efectos bipolares. Por ejemplo, "el


progreso" ciertamente es un satis factor aun cuando sucede que puede tener
un poco de desatisfactor, cuando éste no ocurre. No obstante, esta categoría
pesa tan profundamente como un satisfactor. El ítem "salario" es, definitiva-
mente, un desatisfactor, cuando la escala de pagos y los beneficios comple-
mentarios son pobres, y es un ligero satisfactor cuando la compensación es
buena. En este caso, la clasificación predominante para el salario es la de un
desatisfactor. En algunos casos, todos los factores listados representan las
necesidades del individuo y deben considerarse por el administrador.
La investigación conducida por Myers involucra 282 sujetos (incluyen-
do ingenieros, científicos y técnicos) entrevistados en la Texas lnstruments,
Inc., a inicios de 1961. Las categorías usadas fueron "motivadores"
y "desatisfactores" y los resultados pertenecientes a las ingenierías están
anotados más adelante. Estos ítems listados e identificados con una "M" son
claramente motivadores, y aquellos con una "D" son, definitivamente,
desatisfactores. Por ejemplo, el ítem de "pago" es claramente un desatis-
factor, si se considera inadecuado, y "progreso" es definitivamente un
motivador, cuando ocurre. Una vez más, hay afecciones bipolares; sin em-
bargo, la categorización indica cuando el efecto ocurre en gran medida.`

1. Trabajo por sí mismo (M)


2. Responsabilidad (D)
3. Política y administración de la compañía (D)
4. Pago (D)
S. Progreso (M)
6. Reconocimiento (D)
7. Realización (M)
8. Competencia de supervisión (D)
9. Simpatía de supervisión (D)

"°Myers, M. S., "Who Are your Motivated Workers", Harvard Business Review, 1970, This study
employs factors comparable to those usad by Herzberg".
REQUERIMIENTOS DE LOS RECURSOS HUMANOS 341

En resumen, las necesidades del empleado individual variarán un tanto


dependiendo de su situación. Si una necesidad está satisfecha, entonces otra
necesidad se vuelve predominante, etc. Además, estas necesidades están
relacionadas a menudo con la posición en el mundo de los negocios de la
compañía donde él es empleado (o con el éxito de la organización global).
Si la empresa está en una posición de crecimiento, las necesidades indivi-
duales advertidas pueden ser un tanto diferentes si la empresa está experi-
mentando un declive y se hace evidente la posibilidad de despedir emplea-
dos. Finalmente, el trabajo del administrador es de dos clases. Él (ella) debe:
1) ser consciente de las necesidades individuales de la organización y crear
las condiciones necesarias para la motivación del empleado y 2) satisfacer
estas necesidades en forma continua hasta la extensión posible. La motiva-
ción humana es una clave para el éxito organizacional, y el entendimiento de
los conceptos de esta misión debe ayudar a cumplir dicho objetivo.

7.5.4 La organización del personal

Los requerimientos para abastecer de personal una organización sucede,


inicialmente, a partir de los resultados de la actividad de planeación de
la ingeniería de sistemas, descrita en el capítulo 6. Los trabajos se identifi-
can a partir de las proyecciones a largo ya corto plazo (véase la figura 6.23),
combinadas con paquetes de trabajo y la estructura de descomposición de
trabajo (WBS), y los paquetes de trabajo son agrupados y relacionados a fin
de especificar los requerimientos específicos de los puestos. Los puestos
están, a su vez, dispuestos en la estructura organizacional considerada
como la más apropiada para la necesidad (véase de la figura 7.2 a la 7.14).
En cuanto a los requerimientos de un puesto específico para una
organización para la ingeniería de sistemas, primero se debe poseer un buen
entendimiento de las funciones básicas de la organización. Estas se han
discutido durante los capítulos anteriores de este texto y, más específica-
mente, en el capítulo 6. La revisión de los trabajos asignados, la naturaleza
y los retos de la estructura organizacional, etc., indican que en general un
"ingeniero de sistemas" al entrar debe tener lo siguiente:

1. Una educación básica fundamental en algún campo reconocido de


la ingeniería, es decir, un grado de bachillerato en ingeniería o su
equivalente."
2. Un alto nivel de competencia general técnica en los campos de la
ingeniería que son perseguidos por la organización, por el proyecto,
etcétera.

It
Los programas acreditados reconocidos en la ingeniería se definen por la Accreditation
Board br Engineering and Technology (ABET), United Engineering Center, 345 Street, New
York, N.Y., 10017. Véase el último Annual Report.
342 ORGANIZACIÓN PARA LA INGENIERÍA DE SISTEMAS

3. Experiencia relevante en el diseño en las áreas apropiadas de la


actividad. Por ejemplo, si la compañía está involucrada en el desa-
rrollo de sistemas eléctricos-electrónicos, entonces es deseable
que el candidato haya tenido alguna experiencia anterior en rela-
ción con el diseño en sistemas eléctricos-electrónicos. Es probable
que se requiera un tipo diferente de experiencia aplicable a los
sistemas aeronáuticos, los sistemas civiles, los sistemas hidráuli-
cos, etcétera.
4. Un entendimiento básico de los requerimientos del diseño en las
áreas tales como la ingeniería de confiabilidad, la ingeniería de
mantenibilidad, los factores humanos, la ingeniería de seguridad, la
ingeniería logística, la ingeniería de software, la ingeniería de cali-
dad y la ingeniería valor-costo.
S. Un entendimiento del proceso de la ingeniería de sistemas y las
metodologías-herramientas que pueden emplearse efectivamente
al llevar un sistema a un determinado estado, por ejemplo, la
selección de los requerimientos del sistema y el análisis funcional
y asignación.
6. Un entendimiento de las relaciones entre las funciones que incluye
comercialización, administración del contrato, adquisición, sopor-
te logístico integrado, administración de la configuración, produc-
ción (manufactura), control de calidad, operaciones del cliente
y del proveedor, etcétera.

Como la definición específica de un "ingeniero de sistemas" a menudo


variará de una organización a la siguiente, ¡las percepciones individuales
y los requisitos diferirán! Con base en la experiencia se cree que una
educación sólida y buena en ingeniería técnica es esencial, una experiencia
en el diseño es indispensable, un meticuloso entendimiento del ciclo de vida
del sistema y de sus elementos se requiere y es apropiado el conocimiento
de las diversas interfaces del diseño. Si se desea que un individuo pueda
implementar exitosamente las funciones identificadas en el capítulo 6
(figura 6.6), entonces se recomienda altamente una experiencia anterior en
estas áreas.
Dados los requisitos básicos, el administrador del departamento de
ingeniería de sistemas preparará una descripción individual del puesto
para cada plaza abierta en la organización. Un ejemplo de un formato de
descripción de un puesto se ilustra en la figura 7.18. Deben identificar-
se claramente el título del puesto, el supervisor responsable, las áreas de
responsabilidad y los objetivos del trabajo, los requerimientos de experien-
cia y la fecha de la necesidad. Los requerimientos del puesto de la ingeniería
de sistemas son concluidos y expedidos al Departamento de Recursos
REQUERIMIENTOS DE LOS RECURSOS HUMANOS 343

Fecha de la necesidad:____________________
Título del puesto: Siervtsor,
Ingeniero de sistemas senior Jefe del departamento de
Ingeniería de Sistemas
Función amplia:
Responsable del deseo-peño de las funciones en la ingeniería de sistemas, en el diseño y desarrollo de los productos de
comunicación.
Objetivos funcionales:
1. Realizar los estudios de factibilidad del sistema y evaluar las aplicaciones alternativas de la tecnología.
2. Desarrollar los requerimientos operacionales y los conceptos de mantenimiento para los nuevos sistemas-equipos de
comunicación.
3. Interpretar y traducir los requerimientos del nivel del sistema en requerimientos funcionales del diseño.
4. Preparar las especificaciones y planes de sistemas y subsistemas.
S. Realizar las actividades de integración del sistema (que incluyen las funciones del proveedor).
6. Determinar los requerimientos y conducir las revisiones formales del diseño para todos los elementos del sistema.
7. Preparar los requerimientos de prueba y evaluación del sistema, monitorear las funciones de prueba y evaluar los
resultados de ¡aprueba para determinarel desempeño y efectividad del sistema. Hacer recomendaciones para la acción
correctiva y (o) el mejoramiento.
8. Proporcionar ayuda para la comercialización en las actividades de ventas del producto y satisfacerlos requerimientos
de servicio al cliente, según sea necesario.
Requerimientos:
Graduado en ingeniería eléctrica (bachillerato o más alto), más de cinco a 10 años de experiencia en el diseño de sistemas
de comunicación.

Figura 7.18. Descripción del puesto (ejemplo).

Humanos (o equivalente), a fin de seguir con los pasos necesarios para el


reclutamiento y la contratación.
Al abastecer de personal la organización, las posibles fuentes incluyen:
1) personal calificado dentro la compañía y listo para la promoción y,
2) personal externo y disponible mediante el mercado abierto. Es responsa-
bilidad del administrador del departamento de ingeniería de sistemas
trabajar estrechamente con el Departamento de Recursos Humanos para
establecer los requerimientos iniciales del personal, al desarrollar las
descripciones de los puestos y al pedir el material (véase la figura 3.5), al
reclutar y al conducir las entrevistas, en la selección de los candidatos
calificados, así como al contratar finalmente a los individuos para el empleo
en la organización de la ingeniería de sistemas. En el proceso de conducir
entrevistas y seleccionar personal de la ingeniería de sistemas, deben
recordarse las características identificadas en la figura 7.17)2

12El Departamento de Recursos Humanos es responsable, en la mayoría de las compañías, de


establecer las clasificaciones del trabajo en las estructuras salariales, para la reclutación
y contratación del personal, para iniciar la cobertura de beneficios del empleado, para
proporcionar oportunidades de educación y entrenamiento a los empleados, etc. Esto es de la
incumbencia del administrador del departamento de la ingeniería de sistemas para asegurar
que sus requerimientos organizacionales se entienden inicialmente y, después, se cumplen por
medio de las actividades de reclutación, empleo y entrenamiento.
344 ORGANIZACIÓN PARA LA INGENIERÍA DE SISTEMAS

7.5.5 Desarrollo del personal

Casi cada ingeniero quiere saber cómo él (o ella) está funcionando en una
base día por día y cuáles son las oportunidades de desarrollo. La respuesta
a la primera parte de la pregunta se deriva a partir de una combinación de
la "revisión formal del desempeño", que se lleva en forma planeada regular-
mente (semianuales o anuales) y a través del "proceso informal de comuni-
cación" continua con el jefe. Se le da la responsabilidad al ingeniero y busca
el reconocimiento y la aprobación del supervisor. Como se discutió en la
sección 7.5.4, es necesario que haya comunicación estrecha y el jefe
necesita proporcionar un reforzamiento de que él (o ella) está haciendo un
buen trabajo. También, el empleado necesita saber, tan pronto como sea
posible, cuándo su trabajo no es satisfactorio y necesita un mejoramiento.
Esperar hasta que la revisión formal del desempeño se lleve a cabo para
aprender que el trabajo de uno no es satisfactorio es una práctica pobre,
desmoralizante, ya que, en virtud de no haber escuchado algunos comenta-
rios de lo contrario, ¡se asume que todo está bien! En una organización de la
ingeniería de sistemas, es particularmente importante que el nivel adecuado
de comunicación estrecha se establezca desde el principio.
La segunda pregunta en relación con las oportunidades de desarrollo
depende de: 1) el clima proporcionado en la organización y las acciones del
administrador que permiten el desarrollo individual y 2) la iniciativa por
parte de la ingeniería de aprovechar las oportunidades proporcionadas.
En un departamento de ingeniería de sistemas, es importante que tenga
lugar el crecimiento del personal individual, si ese departamento está
funcionando efectivamente. El clima (ambiente) debe permitir el desarrollo
individual y, acordemente, la ingeniería de sistemas individual debe buscar
las oportunidades. El administrador del departamento de la ingeniería de
sistemas debe trabajar con cada empleado al preparar un plan de desarrollo
diseñado para él. El plan, adaptado a cada una de las necesidades específi-
cas de la persona, debe permitir (y promover) el desarrollo del personal
proporcionando una combinación de lo siguiente:

1. Entrenamiento formal interno diseñado con el fin de familiarizar al


ingeniero con las políticas y procedimientos aplicables a la compañía global
como un conjunto, así como también los procedimientos detallados que
operan en su propia organización. Este tipo de entrenamiento debe hacer
posible que el individuo funcione con mayor éxito en el marco de la
organización total, a través de la familiarización con las muchas interfaces
que él (ella) encontrará en el trabajo.
2. El entrenamiento en el trabajo a través de las tareas selectivas del
proyecto. Aunque el amplio cambio del personal de trabajo a trabajo (o pro-
yecto a proyecto) puede ser perjudicial, ¡algunas veces es adecuado reasignar
a un individuo para trabajar donde él (ella) probablemente estará más
PREGUNTAS Y PROBLEMAS 345

altamente motivado! Cada empleado necesita adquirir nuevas habilidades


y las transferencias ocasionales pueden ser benéficas en tanto no sufra la
productividad global de la organización.
3. Educación formal técnica y entrenamiento diseñado para ascender
a la ingeniería relativa a la aplicación de nuevos métodos y técnicas en su
propio campo de habilidad. Esto se relaciona con la necesidad del ingeniero
de mantenerse actualizado (y evitar la obsolescencia técnica) a través de
una combinación de: a) continuar los cursos breves de educación, semina-
rios y talleres; b) los programas formales de la ingeniería de la licenciatura
del campus proporcionados a nivel local (que lleva un grado avanzado) y c)
el entrenamiento a largo plazo que involucra las oportunidades de investi-
gación y educación avanzada de alguna universidad o campus de un colegio.
4. Un intercambio técnico de habilidades con los demás del área a través
de la participación en la actividad técnica de la sociedad, la actividad de la
asociación de la industria, simposia, congresos y similares.

El administrador de la ingeniería de sistemas debe reconocer la necesi-


dad del desarrollo continuo del personal en su organización y debe estimu-
lar a cada individuo para que busque un nivel más alto de desempeño
mediante el ofrecimiento no sólo atractivo de las tareas del trabajo, sino
también de las oportunidades de desarrollo a través de la educación y entre-
namiento. La viabilidad a largo plazo de cada organización depende en gran
medida del desarrollo del personal. Esto, a su vez, debe aumentar la moti-
vación individual y derivar en el cumplimiento, de un modo de alta calidad,
de las funciones de la ingeniería de sistemas.

PREGUNTAS Y PROBLEMAS

1. Describa qué se entiende por "organización". ¿Cuáles son sus caracte-


rísticas, objetivos, etcétera?
2. Hay diversos tipos de estructura organizacional que incluyen la estruc-
tura "meramente funcional", la estructura de "línea de producto", la
estructura de "proyecto" y la estructura "matricial". Describa breve-
mente la estructura e identifique algunas de las ventajas y desventajas
de cada una.
3. Véase la pregunta 2. ¿Qué tipo de estructura organizacional se prefiere
desde la perspectiva de la ingeniería de sistemas? ¿Por qué?
4. Véase la figura 7.1. ¿Dónde se realiza la ingeniería de sistemas? ¿Quién
es el responsable de la realización de las funciones de la ingeniería de
sistemas? Identifique algunos de los asuntos más importantes asocia-
dos con las relaciones organizacionales mostradas en la figura.
346 ORGANIZACIÓN PARA LA INGENIERÍA DE SISTEMAS

5. Asuma que le ha sido asignada la responsabilidad del diseño y desarro-


llo de un nuevo sistema. Desarrolle una estructura organizacional de
proyecto (usando una combinación de los enfoques deseados), identi-
fique los elementos más importantes contenidos en ellas y describa
alguna de las interfaces claves; describa cómo planea organizar la
ingeniería de sistemas; construya una tabla organizacional.
6. Véase la pregunta S. Describa las funciones de la ingeniería de sistemas
(o trabajos) que deben realizarse.
7. Desde un punto de vista organizacional, identifique y describa algunas
condiciones que deben existir a fin de realizar los objetivos de la
ingeniería de sistemas de manera efectiva.
S. Suponga que se le ha asignado desarrollar un Departamento de Ingenie-
ría de Sistemas para un nuevo programa:
a.¿Qué tipo de estructura organizacional podría desarrollar (dando una
opción)?
b.¿Qué políticas y procedimientos implementaría?
c. ¿Qué tipo de gente necesitaría en términos de cantidad, niveles de
adiestramiento, experiencia individual, etcétera?
e. ¿Qué tipo de estilo de administración impondría? Describa algunas
de las características.
9. En términos de "ambiente organizacional" para la ingeniería de siste-
mas, ¿qué factores necesitan considerarse? Describa brevemente el
"ambiente" organizacional que es adecuado para la habilitación exitosa
de las funciones de la ingeniería de sistemas.
10.Describa algunas de las interfaces de los trabajos más importantes entre
la organización de la ingeniería de sistemas y el contrato de administra-
ción. ¿Adquisición? ¿Producción (manufactura)? ¿Soporte logístico in-
tegrado (ILS)? ¿Administración de la configuración? ¿Comercialización
y ventas?
11.Véase la sección 7.4. Describa alguno de los retos más importantes
asociados con la administración del proveedor.
12.En términos de estilos de administración, ¿qué se entiende por "Teoría
X" y "Teoría Y"? ¿Cuál es el estilo preferido en relación con la aplicación
de la ingeniería de sistemas?
13. Asuma que usted, como vicepresidente de la ingeniería, está buscando
un nuevo administrador del Departamento de la Ingeniería de Sistemas.
¿Qué características de liderazgo identificaría como críticas (identifí-
quelas en orden de importancia).
PREGUNTAS Y PROBLEMAS 347

14. Véase la figura 7.17. Seleccione y liste en orden de importancia las 10


principales características , basándose en su experiencia.
15. Revise los resultados de la investigación de Herzberg, presentados en la
sección 7.5.2. A partir de su propia experiencia, liste los "satisfactores"
y los "desatisfactores" en orden de importancia. Muestre los factores
adicionales conforme usted los vea aptos. Una buena manera de presen-
tar sus ideas es mediante una gráfica de barras que muestre las relacio-
nes bipolares.
16. Con base en su propia perspectiva, describa las características de un
"ingeniero de sistemas" (experiencia, características personales, facto-
res motivacionales, etcétera).
17. Como administrador del Departamento de Ingeniería de Sistemas, ¿qué
pasos seguiría para asegurar que su organización mantuviera una
posición relevante relativa a la competencia técnica?
L!J

CONTRATACIÓN Y ADMINISTRACIÓN
DE PROVEEDORES

Como se trató en los capítulos anteriores, el tipo las características de los


sistemas variarán en función de la necesidad. Hay ambos sistemas, sistemas
en gran escala, con muchos componentes diferentes, y los pequeños siste-
mas, con muy pocos componentes; los sistemas que tienen equipamiento
intensivoy otros que son predominantemente de uso humano intensivo; los
sistemas que requieren diseño extenso y esfuerzo de desarrollo y aquellos
esencialmente compuestos de componentes estándar disponibles en alma-
cén; los sistemas que involucran la producción de múltiples cantidades de
ítems y aquéllos de la misma naturaleza, etc. En esencia, hay muchas
configuraciones de sistemas diferentes.
Al evaluar las diversas configuraciones de estos sistemas, puede pare-
cer que una gran variedad de proveedores del componente han sido
utilizados durante la creación del sistema. Muchos de estos proveedores
estuvieron involucrados en el diseño de detalle y desarrollo de los compo-
nentes seleccionados del sistema. Con la responsabilidad del diseño y desa-
rrollo, ellos han tenido un efecto en el sistema en términos de su desempeño,
efectividad y costo. En otras palabras, el último éxito del sistema, al cumplir
sus objetivos, depende en gran medida de los proveedores de sus compo-
nentes.
En cuanto a cumplir los objetivos de la ingeniería de sistemas, es
esencial que se inicie una buena planeación desde el inicio del programa.
Esta planeación, que incluye el desarrollo del plan de administración de la
ingeniería de sistemas (SEMP), debe considerar incorporar las funciones del
proveedor como una parte inherente al proceso global de creación del sis-
tema. Posteriormente, las responsabilidades específicas referentes al cum-
plimiento exitoso de estas funciones deben ser adecuadamente tratadas a
través de la organización para la ingeniería de sistemas.
Los capítulos 6 y 7 proporcionan una introducción de las actividades
del proveedor en el contexto de conjunto! Este capítulo presenta material
350 CONTRATACIÓN Y ADMINISTRACIÓN DE PROVEEDORES

descriptivo adicional, que destaca el papel del proveedor y las relaciones


con las organizaciones del cliente y del contratista. Se cubre la identificación
del proveedor, la selección, la contratación y las actividades de monito-
reo y control del proveedor. Este capítulo es una extensión de los capítulos
6 y 7, con énfasis en las funciones del proveedor.

8.1 REQUERIMIENTOS DEL PROGRAMA

La revisión del proceso de la ingeniería de sistemas descrita en el capítu-


lo 2 ilustra un número de pasos comenzando con la identificación de una
necesidad y extendiéndose a través de la definición de los requerimientos
operacionales del sistema, el concepto de mantenimiento, la realización del
análisis funcional, la distribución de los requerimientos a nivel del subsistema
y más abajo, etc. Los pasos iniciales del proceso se muestran en la figura 8.1.
Como el sistema es definible en términos funcionales, los estudios de
compromisos son llevados a cabo con el objetivo de determinar "CÓMO" las
funciones pueden ser realizadas mejor (véase el capítulo 2, sección 2.5).
¿Deben realizarse las funciones a través de la aplicación del equipo, manual-
mente, a través de la utilización de recursos humanos, o a través de una
combinación de éstos? Los resultados de estos estudios de compromisos se
presentan en forma de requerimientos específicos del recurso.
El siguiente paso es identificar "DÓNDE" pueden ser obtenidos los
recursos requeridos, o la fuente de los suministros. La conclusión de una
función dada ¿debe realizarse en casa por el contratista, el diseño o manu-
factura de un componente, etc., o debe seleccionarse una fuente externa de
suministros? En muchas organizaciones industriales, se establece un
comité "hágalo o cómprelo" para evaluar las alternativas y para seleccionar
un enfoque preferido.
El comité hágalo o cómprelo se establece con la representación de la ad-
ministración del programa, la ingeniería, la logística, la manufactura, la
adquisición yel aseguramiento de la calidad. La participación de la ingenie-
ría debe incluir las disciplinas aplicables del diseño y la ingeniería del
diseño. Las decisiones se toman interesándose por la fuente de suministros
y se basan en los requerimientos de la disponibilidad del componente, la
disponibilidad de facilidades y recursos de ingeniería y la producción del
contratista, los requerimientos del plan, el costo y las implicaciones socio-
económicas y políticas asociadas. Desde la perspectiva de la ingeniería de
sistemas, los componentes que son relativamente complejos por naturale-
za, involucran la aplicación de nuevas tecnologías y son críticos para el
esfuerzo global de desarrollo del sistema, debiendo manejarse en casa, si es
del todo posible. Estos items, posiblemente del todo, requieran monitoreo
frecuente y la aplicación de un control (de administración y técnico).
Posteriormente, conforme la extensión de las actividades del proveedor se
LIIDefinición necesidad
III
Requerimientos del sistema
• Estudio de factibilidad
• Requerimientos operacionales
• Concepto de mantenimiento
• Avance de la planeación del sistema

Análisis funcional y distribución


de los requerimientos del sistema

Análisis y estudios de
compromisos del sistema
(Respuesta a cómo deben ser
realizadas las funciones-recursos)

'Ir

Tomar o adquirir una decisión El diseño, desarrollo y(o)


(¿Debe ser safisfecho
fecho
vés producción de los
elquerimlento a fr componentes del sistema se
No realiza por el contratista
.delactividad del proveedor?)
usando recursos propios
(Hacer).

Los componentes del sistema son conseguidos a partir de


los proveedores externos (por ejemplo, Comprar)

si

componente (Tipo B, C, D y(o) E) y


descripción del trabajo (SOW)

Preparación y distribución de la solicitud de una


propuesta (RFP) o invitación de una oterta

Respuesta del proveedor


Preparación y presentación de propuestas

Revisión de la propuesta, evaluación y selección del


proveedor (o grupos de proveedores)

Desarrollo, negociación y otorgamiento del contrato.


Comienza la actividad del proveedor

Figura 8.1. Proceso de identificación y del proveedor.

351
352 CONTRATACIÓN Y ADMINISTRACIÓN DE PROVEEDORES

incrementan, hay una gran cantidad de coordinación y control global


/ ! requerida. Los cambios para una organización de la ingeniería de sistemas
pueden ser bastante exigentes con la actividad del proveedor distribuida en
una base mundial.'

8.2 PROPUESTAS Y SELECCIÓN DEL PROVEEDOR

Aunque la sección previa establece los requerimientos básicos del progra-


ma, esta sección se extiende hasta el proceso ilustrado en la figura 8. 1, que
incluye el desarrollo de la solicitud para una propuesta (RFP) para el
contratista, la preparación de propuestas por los proveedores, la evalua-
ción de las propuestas del proveedor así como la selección última de los
proveedores. La sección 8.3 sigue con las negociaciones del contrato y la
implementación de los programas del proveedor.

8.2.1 Preparación de la solicitud para una propuesta (RFP)

Habiendo evaluado las alternativas con una decisión última de "COMPRAR",


el contratante (en este caso) debe desarrollar los materiales necesarios de
incorporación en una solicitud para una propuesta (RFP). El objetivo es
desarrollar un paquete de datos que pueda ser distribuido a los proveedo-
res potenciales para propósitos de solicitud para una propuesta. 2
En general, la RFP es un mecanismo formal mediante el cual el contratis-
ta especifica los requerimientos para un componente, o para un servicio, en
respuesta a una necesidad designada. La necesidad de un componente del
sistema se ha identificado, las decisiones han sido tomadas para conseguir
el componente desde una fuente externa y el contratista debe traducir los
requerimientos de este componente de una manera detallada y precisa.
Estos requerimientos se describen en un paquete de datos, con una carta
adjunta de indicación de la oferta, y se envían a los proveedores probables
interesados en responder a la RFP. Más específicamente, el contenido del
paquete de datos debe incluir los siguiente:

1. Una especificación técnica que describa el componente, sus caracte-


rísticas de desempeño y efectividad, las características físicas, las provisio-

En relación con las aplicaciones sociales-económicas-políticas una decisión puede tomarse en


las bases de 1) ayudar a mejorar la economía local; 2) el deseo de incrementar el porcentaje de
subcontratación; 3) la necesidad de establecer una capacidad de manufactura en una nación
extranjera dada y 4) la necesidad de responder a una crisis de desempleo existente en una área
geográfica dada, etcétera.
2
El paquete de la solicitud puede ser presentado como una solicitud de una propuesta (RFP),
una solicitud para una cotización (RFQ), o una invitación para una oferta (IFB). En cada caso,
el objetivo es proporcionar un paquete de datos en el que se basa una propuesta.
PROPUESTAS Y SELECCIÓN DEL PROVEEDOR 353

nes de logística y calidad, etc. Este documento, diseñado para la aplicación,


debe constituir un tipo de especificaciones "B", "C", "D" o "E", dependiendo
del requerimiento particular (véase la figura 6.14).
2. Un plan de administración abreviado que describa los objetivos
globales del programa, las responsabilidades organizacionales del contra-
tista y las interfaces, la WBS, los trabajos del programa, los planes del
trabajo, las políticas y procedimientos aplicables, etc. Esta información se
relaciona esencialmente con las actividades del contratista; no obstante, los
proveedores individuales deben entender sus respectivos papeles en el
contexto del programa global.
3. Una descripción del trabajo (SOW) que describa los trabajos detalla-
dos, los planes de trabajo, los componentes distribuibles, los datos de
apoyo y los reportes que deben proporcionarse al proveedor. Esta informa-
ción, derivada de una combinación de la especificación y el plan de adminis-
tración, constituye un resumen del trabajo que será realizado y sirve de base
para la propuesta del proveedor.

Como se estableció anteriormente, el cumplir los objetivos de la ingenie-


ría de sistemas depende en gran medida de la selección inicial del provee-
dor, de las actividades subsiguientes aplicables y de la evaluación continua
y de los esfuerzos del control impuestos por el contratante. Como una
entrada a este proceso, la especificación técnica (esto es, la especificación
Tipo "B", "C", "D" o "E", según sea pertinente) debe ser extensa para cubrir
todos los requerimientos a nivel del sistema conforme sean asignadas
(o apartadas) hacia abajo al elemento del sistema que se está consiguiendo.
Un enfoque de arriba-abajo es un aspecto importante de la ingeniería de
sistemas y la especificación técnica debe apoyar a los requerimientos
del sistema en la medida que sea posible.
El grado de influencia de la especificación del sistema (Tipo "A") en las
especificaciones más bajas depende, evidentemente, del ítem que debe
conseguirse a partir del proveedor. Un esfuerzo de desarrollo grande re-
querirá una especificación de Tipo "B" extensa, mientras un componente
estándar disponible en almacén puede cubrirse por una especificación Tipo
"C" relativamente corta y simple. Es importante asegurar que la trazabilidad
apropiada se mantenga conforme se avanza abajo a través del árbol de
especificaciones aplicable (véase la figura 6.14).
Mientras los requerimientos técnicos de arriba-abajo se mantienen
a través del "seguimiento de la especificación", los requerimientos apropia-
dos orientados a la administración deben imponerse al proveedor a través
del plan de administración y de la descripción del trabajo (SOW).
La continuidad organizacional debe asegurarse a partir de lo general a lo
particular, los trabajos especificados para el proveedor deben apoyar
directamente aquellos trabajos que son realizados por el contratista, los
planes deben ser compatibles, la WBS debe mostrar las relaciones entre el
354 CONTRATACIÓN Y ADMINISTRACIÓN DE PROVEEDORES

proveedor y las actividades del contratista, etc. En otras palabras, debe


asegurarse una estrecha continuidad en la transición del trabajo, del contra-
tista al proveedor.
El paquete de datos RFP, preparado por el contratista para cubrir la
actividad planeada del proveedor, es extremadamente importante para
mantener la continuidad necesaria desde los requerimientos de alto nivel
del sistema hacia abajo hasta el componente del nivel más bajo del sistema.
Uno de los trabajos principales de la ingeniería de sistemas es el de la
integración del sistema y es un objetivo para desarrollar la RFP, el nivel
apropiado de la integración del sistema se reconoce y se trata. Muy a me-
nudo, un documento como éste se compila de una manera "apresurada", se
generan las propuestas, se negocian los contratos, y los requerimientos
necesarios para la integración del sistema son dejados hasta el final. Esto,
evidentemente, puede ser una práctica costosa. El paquete de datos RFP
debe considerarse como una extensión de la especificación Tipo "A" del
sistema y del SEMP.

8.2.2 Desarrollo de las propuestas del proveedor


Después de que el paquete de datos RFP se ha desarrollado y distribuido
a los proveedores interesados y calificados, cada destinatario debe tomar
una decisión, "oferta-no oferta". Aquellos proveedores que deciden respon-
der establecerán un equipo de proposiciones y procederán con la prepara-
ción de una propuesta. Los resultados deben ser, evidentemente, sensibles
a las instrucciones incluidas en la RFP.
La naturaleza de la actividad de propuesta del proveedor dependerá del
tipoy alcance del esfuerzo descrito en la RFP. Cuando el proceso de creación
se dirige hacia grandes elementos del sistema e involucra algún diseño
y desarrollo (por ejemplo, subsistemas importantes), la actividad de pro-
puesta del proveedor podría ser bastante extensa. Puede establecerse una
organización formal del tipo-proyecto, los trabajos específicos del producto
se identifican y el nivel del esfuerzo puede ser un tanto similar al enfoque de
la configuración (o las configuraciones) del proyecto, descrita en los capí-
tulos 6 y 7.
En situaciones en las que existen esfuerzos de una propuesta grande,
usualmente hay un requerimiento de una actividad de diseño y desarrollo.
Si el RFP (a través de una especificación de desarrollo Tipo "B") dicta la

3E1 tema de la propuesta (por ejemplo, los requerimientos de la propuesta, las conferencias de
la propuesta, el establecimiento del equipo de la propuesta, las actividades de preparación
de la propuesta, el procesamiento y revisión de la propuesta) es bastante extenso. Sólo
aquellas funciones como las relacionadas con el cumplimiento de los objetivos de la ingeniería
de sistemas son tratados aquí. Dos referencias buenas que cubren este tema a profundidad son
Stewart, R. D., yA. L. Stewart, Pmposal Preparation, John Wiley, Nueva York, 1984 y Wall, W. C.,
Proposal Preparation Guide, John Wiley, New York, 1990.
PROPUESTAS Y SELECCIÓN DEL PROVEEDOR 355

necesidad del diseño de un elemento importante del sistema, el proveedor


a menudo intentará diseñar y construir un modelo prototípico del ítem,
como parte del esfuerzo de propuestas. Un miniproyecto se organiza, los
trabajos de diseño y desarrollo se concluyen en forma expedita y un mode-
lo físico se distribuye para el contratista junto con la propuesta escrita.
Las decisiones de diseño se llevan a cabo oportunamente, con el objetivo de
convencer al contratista (esto es, el cliente, en este caso) en relación con el
planteamiento del diseño y las capacidades del proveedor. El proveedor
debería tener éxito y ser seleccionado en este caso, el prototipo construido
podrá ser considerado como la configuración base que lleva al diseño de-
tallado subsiguiente.
En el escenario anterior, los requerimientos del subsistema fueron
especificados como parte del RFP, las actividades de diseño y desarrollo se
concluyeron durante la fase de propuesta, una revisión del diseño formal
ocurrió mediante la revisión del contratista y la evaluación de la propuesta
del proveedor yla configuración resultante se vuelve un tanto fija en cuanto
a la posibilidad de incorporar algunos cambios en el diseño. Este esce-
nario puede estar relacionado con el proceso de desarrollo descrito en el ca-
pítulo 2, salvo que el elemento tiempo está significativamente comprimido.
A causa de este tipo de escenario, la preparación de la RFP asume un gran
grado de importancia a partir del punto de vista de la ingeniería de sistemas
(como se indicó en la sección 8.2.1). Posteriormente, la actividad de diseño
continuo realizada durante la fase de propuesta debe considerar las carac-
terísticas de diseño necesarias que apoyan a los objetivos de la ingeniería
de sistemas (por ejemplo, las características de confiabilidad y caracterís-
ticas de mantenibilidad). Finalmente, la evaluación formal de las propuestas
del proveedor debe servir como una verificación final de la conformidad
con los requerimientos de la ingeniería de sistemas que se aplica al ítem, o al
servicio, que es conseguido.

8.2.3 Evaluación y selección de los proveedores


Al recibir todas las propuestas (solicitadas y no solicitadas) de los provee-
dores posibles, el contratista continúa con el proceso de revisión y evalua-
ción. Cuando una oferta competitiva llega, el contratista generalmente
establece un procedimiento de evaluación dirigido a seleccionare! mejor en-
foque propuesto. Inicialmente, cada propuesta de proveedor es revisada
en términos de conformidad con los requerimientos especificados en la
solicitud de propuesta (RFP). La no conformidad puede dar como resultado
la descalificación automática, o el contratista puede abordar al proveedor
designado y recomendarle una revisión de propuesta y (o) una adición.
Cuando dos o más proveedores cumplen los requerimientos básicos
RIP, entonces se concluye una evaluación de cada propuesta empleando
criterios preestablecidos. La figura 8.2 presenta un ejemplo de los criterios
356 CONTRATACIÓN Y ADMINISTRACIÓN DE PROVEEDORES

de revisión y los resultados de una evaluación que involucra las propues-


tas de tres diferentes proveedores. Refiriéndose a la figura, las áreas ma-
yores de importancia incluyen las características técnicas del elemento del
sistema o componentes en cuestión, la capacidad de producción del provee-
dor, la administración, el costo total, la experiencia de los proveedores y el
registro del desempeño en el pasado.
El contratista desarrolla una lista de factores considerados como rele-
vantes en la evaluación y establece factores de peso que indican el grado de
importancia. En la figura 8.2, cada uno de los factores del criterio de eva-
luación se apoya en una lista de verificación detallada contra la cual una
propuesta será evaluada. Un ejemplo de una lista de verificación que apoya
al ítem D.2 se presenta en la figura 8.3. Usando está lista de verificación, y las
similares para cada factor, las propuestas son revisadas y las valuaciones
son asignadas con base en la medida de conformidad con los objetivos
deseados. Estas valuaciones son multiplicadas por los factores de importan-
cia que proporcionan una puntuación para cada ítem. Las puntuaciones
individuales son entonces adicionadas y la puntuación más alta refleja el
proveedor con el mejor enfoque global. En este caso, el proveedor "B"
parece ser la alternativa preferida.
En la evaluación de las propuestas del proveedor desde la perspectiva
de la ingeniería de sistemas, las siguientes preguntas se aplican al elemento
o componente del sistema que es conseguido, según sea apropiado:

La propuesta del proveedor ¿es sensible a las necesidades del


contratista, como se especificó en la solicitud para una propuesta
(RFP)?
2. La propuesta del proveedor ¿apoya directamente a los requerimien-
tos del sistema determinados en la especificación Tipo "A" del
sistema y el plan de administración de la ingeniería de sistemas
(SEMP)?
3. ¿Han sido adecuadamente especificadas las características de des-
empeño del(de los) ítem(s) propuesto(s)? ¿Son éstas significativas,
medibles, trazables desde los requerimientos a nivel del sistema?
4. ¿Han sido especificados los factores de efectividad (por ejemplo,
confiabilidad, mantenibilidad, capacidad de soporte y disponibili-

Una evaluación similar que usa la misma lista de verificación básica y el planteamiento de
factor de importancia se encuentra en el apéndice A, ejemplo 4.
1 Estas preguntas son similares por naturaleza a los temas de revisión del diseño de la figura 5.4
(capítulo 5) y del apéndice B. También, el apéndice B puede ser usado en el proceso de
evaluación de la propuesta del proveedor como sea necesario para proporcionar una pro-
funda revisión. La respuesta aplicable a cada pregunta debe ser "SÍ" para los resultados
deseables.
Criterios de evaluación
Factor
de
Importan-
-- - - --
Propuesta A

Puntua
Propuesta 8

Puntua
Propuesta C

Puntua-
cia (%) Valuación dde Valuación cide ValUación ción

A. Requerimientos técnicos 25

1. Características de desempeño 6 4 25 5 30 5 30

2. Factores de efectividad 4 3 12 4 16 3 12

3. Enfoque del diseño 3 2 6 3 9 ¡ 3

4. Documentación del diseño 4 3 12 4 16 2 8

5. Enfoque de prueba y evaluación 2 2 4 1 2 2 4

6. Requerimientos de apoyo del producto 4 2 8 3 12 2 8

7. Crecimiento potencial 2 2 4 1 2 2 4

B. Capacidad de producción 20

1. Distribución de la producción 8 5 40 6 48 6 48

2. Proceso de manufactura 5 2 10 3 15 4 20

3. Control-aseguramIento de la calidad 7 5 35 6 42 4 28

C. Administración 20

1. Planeación (planes, programaciones) 6 4 24 5 30 4 24

2.Estructura de la organización 4 4 16 3 12 4 16

3.Recursos disponibles de personal 5 3 15 4 20 3 15

4. Control de la administración 5 3 15 4 20 4 20

D. Costo total 25

1. Precio deadquisición 10 7 70 5 50 6 60

2. Costo de] ciclo devida 15 9 135 10 150 8 120

E. Factores adicionales 10

1. Experiencia anterior 4 4 16 3 12 3 12

2. Desempeño en el pasado 6 5 30 5 30 3 18

Gran total 100 476 516 450

Figura 8.2. Criterios de evaluación de una propuesta (ejemplo).

357
358 CONTRATACIÓN Y ADMINISTRACIÓN DE PROVEEDORES

Valuación Criterios de evaluación-costo del ciclo de vida


(Puntos)

13-15 El proveedor ha justificado su diseño con base en el costo del ciclo de vida y ha incluido un
análisis completo del costo del ciclo de vida en su propuesta (por ejemplo, estructura de des-
composición de costos, perfil de costos, etcétera.).

10-12 El proveedor ha justificado su diseño con base en el costo del ciclo de vida, pero no incluye
un análisis completo del costo del ciclo de vida en su propuesta.

7-9 El diseño del proveedor no se ha basado en el costo del ciclo de vida, no obstante, él planeó
realizar un análisis del costo del ciclo de vida y ha descrito el enfoque, el modelo, etc., que
propone usar en el proceso del análisis.

4-6 El diseño del proveedor no se ha basado en el costo del ciclo de vida, sino que él intenta
realizar un análisis del costo del ciclo devida en el futuro. No fue incluida en su propuesta una
descripción del enfoque, del modelo, etcétera.

0-3 El tema del costo del ciclo de vida (y su aplicación) no fue tratado en toda la propuesta del
proveedor.

*Véase la figura 8.2 para criterios individuales

Figura 8.3. Lista de verificación de los criterios de evaluación para las propuestas del proveedor
(ejemplo).

dad)? ¿Son estos significativos, medibles, trazables a partir de los


requerimientos a nivel del sistema?
En caso de que sea requerido un nuevo diseño, ¿ha sido definido
adecuadamente el proceso de diseño en la organización del provee-
dor?¿Incorpora el proceso la utilización de las tecnologías CAD-
CAM-CALS donde es apropiado? ¿Han sido adecuadamente integra-
das las características de confiabilidad, mantenibilidad, factores
humanos, capacidad de soporte, costo del ciclo de vida y relaciona-
das con el diseño donde es apropiado? ¿Se han desarrollado los
procedimientos de cambio y están adecuadamente controlados
a través de unas buenas prácticas de administración de la configu-
ración?
6. ¿Está adecuadamente definido el diseño a través de una buena
documentación, es decir, dibujos, listas de partes, reportes, soft-
ware, cintas, discos y bases de datos?
7. ¿Ha tratado el proveedor el requerimiento de un componente, para
la prueba y evaluación del elemento del sistema propuesto? Si las
pruebas se han realizado en el pasado, ¿los resultados están docu-
mentados y disponibles? Para futuras pruebas, ¿han sido adecuada-
mente integrados los planes al plan maestro de prueba y evaluación
(FEMP) del sistema?
PROPUESTAS Y SELECCIÓN DEL PROVEEDOR 359

8.¿Han sido identificados los requerimientos de soporte del ciclo de


vida para el ítem propuesto, es decir, los requerimientos de recurso
de mantenimiento, las partes de repuesto-reparación, el equipo de
prueba y soporte, la cantidad de personal y los niveles de adiestra-
miento, el entrenamiento, las instalaciones, los datos, el software
de mantenimiento, etc.? ¿Han sido minimizados estos requerimien-
tos al máximo posible a través de un buen diseño?
9. ¿Refleja la configuración del diseño un buen potencial de crecimien-
to; de reconfigurabilidad?
10. ¿Ha desarrollado el proveedor un plan extenso de producción-
construcción? ¿Está identificado el proceso de manufactura junto
con sus características?
11. ¿Tiene el proveedor un buen programa de aseguramiento de la ca-
lidad? ¿Son utilizados los métodos estadísticos de control de la
calidad donde es apropiado? ¿Tiene el proveedor un buen plan de
retrabajo a fin de manejar los ítems desechados conforme es
necesario?
12. ¿Incluye la propuesta del proveedor un extenso plan de administra-
ción? ¿Cubre el plan los trabajos del programa, la estructura de
organización y las responsabilidades, un WBS, plan de trabajos,
monitoreo de programas, control de procedimientos y demás? ¿Ha
sido definida la responsabilidad de los planes de trabajo de la
ingeniería de sistemas?
13. ¿Trata la propuesta del proveedor todos los aspectos del costo
total, es decir, el costo de creación, el costo de operación y soporte
y el costo del ciclo de vida?
14. ¿Tiene experiencia previa el proveedor en cuanto al diseño, desa-
rrollo y producción de los elementos-componentes del sistema que,
por naturaleza, son similares al ítem propuesto? ¿Fue favorable la
experiencia en términos de la distribución de los productos de alta
calidad de manera oportuna y en cuanto a costos?

Mientras estas preguntas pueden ayudar a la evaluación de una pro-


puesta del proveedor, hay algunos factores que necesitan ser considerados
antes de recomendar un planteamiento específico de consecución:

1. ¿Debe seleccionarse un solo proveedor (esto es, una sola fuente),


o deben ser seleccionados dos o más proveedores para satisfacer los reque-
rimientos, como se estableció en la RFP? Si el nivel de esfuerzo especificado
cubre un elemento relativamente grande del sistema e involucra alguna
actividad de diseño y desarrollo, la selección de dos (o más) proveedores
360 CONTRATACIÓN Y ADMINISTRACIÓN DE PROVEEDORES

que realicen los mismos trabajos puede ser bastante costoso. Por otra parte
para los componentes más pequeños estándar disponibles en almacén,
puede ser adecuado establecer diversas fuentes de proveedores. El objetivo
es asegurar una fuente de suministros que cumplirá la necesidad mientras
sea requerido, con un mínimo de riesgo asociado con la posibilidad de que
el proveedor "salga del negocio".
2. ¿Le será posible al proveedor proporcionar el apoyo necesario para
el ítem propuesto, durante y después de la producción, durante el ciclo de
vida planeado de ese ítem? De interés particular es la fuente para las partes
de repuesto-reparación de soportar los requerimientos de mantenimien-
to de apoyo después de que la producción ha sido concluida y la capacidad
ya no existe; es decir, el soporte de la posproclucción. Si tal soporte no estará
disponible, entonces la política de consecución puede ordenar que las par-
tes de repuesto-reparación sean adquiridas inicialmente para apoyar las
operaciones de mantenimiento para el ciclo de vida entero.
3. ¿Un proveedor debe seleccionarse con base en los factores políticos,
sociales y (o) económicos? En esta época de involucramiento internacional
(o globalización), hay ciertas presiones políticas que refuerzan la consecu-
ción de los componentes o servicios, desde una fuente particular extranjera.
Por otra parte, puede ser fácil seleccionar un proveedor posible con base en
la ubicación geográfica y en la necesidad económica. En ocasiones, puede
especificarse que el menor porcentaje del volumen total del esfuerzo del
desarrollo del sistema debe ser subcontratado. En algunos casos, la selec-
ción del personal está influenciada por factores políticos, sociales y (o)
económicos.

La evaluación de las propuestas del proveedor pueden ser realizadas


usando el enfoque visto en la figura 8.2, modificado para tomar en conside-
ración estos factores adicionales, es decir, un solo proveedor contra múlti-
ples proveedores, requerimientos de soporte a la construcción y la influen-
cia de factores políticos y económicos en la selección del proveedor. Esta
actividad de evaluación usualmente no sólo incluye una revisión de la
misma propuesta escrita, sino una o más visitas de tipo inspección in situ en
la instalación del proveedor. Se hace una recomendación y se inician las
negociaciones del contrato entre el contratista y el proveedor.
Como los resultados del proceso de la evaluación y selección del
proveedor tienen un efecto importante en el éxito del programa y en el cum-
plimiento de los objetivos de la ingeniería de sistemas, es importante que la
organización de la ingeniería de sistemas esté representada durante este
proceso. La coordinación y la integración adecuada de la-actividad del pro-
veedor en el esfuerzo total del diseño y desarrollo son esenciales.
NEGOCIACIONES CONTRACTUALES 361

8.3 NEGOCIACIONES CONTRACTUALES

Habiendo identificado los posibles, proveedores a través del proceso de


evaluación y selección, ahora incumbe al contratista desarrollar un acuerdo
formal contractual con el proveedor. Una solicitud de propuesta (RFP) se
inició, las propuestas de los proveedores potenciales se generaron y evalua-
ron y necesita establecerse una estructura contractual (de alguna forma).
El tipo de acuerdo contractual negociado es muy probable que tenga un
efecto importante en el desempeño del proveedor, particularmente en la
consecución de grandes componentes del sistema que involucran la activi-
dad de diseño y el desarrollo.
El objetivo de la negociación del contrato es alcanzar un acuerdo
contractual más ventajoso desde el punto de vista de los requerimientos
técnicos, liberaciones, de precio, el tipo de contrato impuesto y la progra-
mación de remuneraciones. Obviamente, el contratista y el proveedor po-
sible visualiza por su parte este objetivo en relación con su propia posición
individual, en términos de los riesgos asumidos esencialmente por el
proveedor. En el otro extremo, hay una estructura de costo más pago fijo
(CPFF), donde el contratista asume la mayor parte del riesgo. Entre estos
dos extremos, hay un número de opciones relativamente flexibles.
El tipo de contrato negociado es importante ya que los resultados
pueden afectar de buena manera el desempeño del proveedor que, a su
vez, puede afectar la habilidad del contratista de desarrollar y producir'
un sistema que cumplirá los requerimientos especificados oportunamente.
El desempeño del proveedor, particularmente en la creación de grandes
subsistemas, es crítico para la realización exitosa de los objetivos de la
ingeniería de sistemas/Posteriormente, los factores de riesgo asociados con
el tipo de estructura contractual negociada deben ser considerados en el
desarrollo del plan de administración del riesgo incluido,como parte del
plan de administración de ingeniería de sistemas (SEMP): véase la figura 6.5
y también la sección 6.3.
Recordando esto, es importante que el ingeniero de sistemas tenga un
entendimiento de los contratos, ya que él (o ella) es afectado no sólo por el
tipo de contrato negociado, sino a menudo está directamente involucrado
en el proceso de negociación mismo. Los contratos a precio fijo están
estrictamente controlados, con el proveedor que asume la mayor parte del
riesgo (en este caso). La ingeniería de diseño debe estar bien definida,
puesto que los cambios posteriores a la negociación del contrato pueden
ser bastante costosos. Por otra parte, el tipo de costo de reintegración de
contratos (esto es, costo más pago fijo, costo más pago de incentivos) es
más flexible en términos de hacer cambios después de la negociación
inicial del contrato y el grueso del riesgo es asumido por el contratista.
En algunos casos, el ingeniero de sistemas debe tener un sentido relativo de
la extensión que se requiere para la definición del diseño y de lo que puede
362 CONTRATACIÓN Y ADMINISTRACIÓN DE PROVEEDORES

y no puede hacer, en virtud de los diversos acuerdos contractuales.


Como punto adicional, el ingeniero de sistemas a menudo participa,
desde un punto de vista técnico yde estimación de costos, en la preparación
inicial de la solicitud para una propuesta (que incluye la preparación de la
especificación del desarrollo, el plan de administración y la descripción del
trabajo), que lleva a las negociaciones del contrato. Cuando las negociacio-
nes realmente tienen lugar, a menudo el ingeniero de sistemas participa, una
vez más en relación con la interpretación de las especificaciones y los
aspectos físicos de la realización del trabajo. Durante el proceso de negocia-
ción, el alcance intentado de trabajo puede cambiar y estos cambios pueden
ser evaluados por su efecto en otro diseño del sistema y en las actividades
de desarrollo.
A fin de proporcionar un entendimiento adicional, las categorías más
importantes de los contratos se describen brevemente a continuación:

1.Contrato a precio fijo (FFP). Un acuerdo legal para pagar una cantidad
de dinero cuando los ítems llamados por el contrato han sido liberados yson
aceptados. No se permiten los ajustes de precio para el trabajo contratado
después de firmado, no importando los costos actuales experimentados por
el proveedor. A un precio especificado, el proveedor asume todos los
riesgos financieros por desempeño y sus utilidades dependen de su habili-
dad para, inicialmente, predecir costos, negociar y, posteriormente, contro-
lar los costos. En relación con la aplicación de este tipo de contrato, el
diseño del componente debe estar bastante bien establecido mediante las
especificaciones adecuadas.
2.Contrato a precio fijo con escalación. Similar al contrato FFP, excepto
que puede añadirse una cláusula de escalación para cubrir los incrementos
o decrementos no controlables del precio. La escalación puede aplicarse al
trabajo y al material. Ya que hay muchas incertidumbres en relación con la
predicción de la magnitud de la escalación, a menudo se establece un tope
de escalación con el proveedor y el contrato que comparte los riesgos arri-
ba de este punto. Los costos inesperados arriba del tope establecido son
asumidos por el proveedor.
3.Contrato aprecio fijo con incentivos. Aplicado en situaciones en las que
existen algunas incertidumbres de los costos y hay una posibilidad excelen-
te de que la reducción de costos pueda ser alcanzada a través de una buena
administración del proveedor y dotando al proveedor con algún incentivo
de utilidad. Un costo planeado, un costo mínimo y un precio límite son
negociados, junto con una fórmula de ajuste de la utilidad. El ajuste de la
utilidad, a partir de la utilidad planeada inicial, puede estar basado en el
desempeño del costo total.
4.Contrato de costo más pago fijo (CPFF). Un contrato de reembolso del
costo donde al proveedor se le reembolsan todos los costos permisibles
asociados con el proyecto. Un pago fijo negociado (por ejemplo, 10% del
NEGOCIACIONES CONTRACTUALES 363

costo estimado) se paga al proveedor a la conclusión del trabajo. Aunque se


fija este pago en términos de un porcentaje del costo total, los incrementos
o decrementos del pago pueden suceder, como suceden los cambios al
alcance del trabajo y al contrato. Esto es particularmente aplicable cuando
el contratista está de acuerdo con aceptar las propuestas de cambio de la
ingeniería generadas por el proveedor para realizar el trabajo más allá del
alcance del contrato inicial.
S. Contrato del costo más pago de incentivo (CPIF). Propuesto para cubrir
las situaciones en que existen algunas incertidumbres en el desempeño del
programa. Los costos permisibles son pagados al proveedor, junto con las
remuneraciones del pago del incentivo adicional basados en las realizacio-
nes diseñadas. Ei el tiempo de realización, los factores individuales tales
como indicadores de programación y medidas de desempeño específicas
pueden ser identificadas como ítems cuando los incentivos deben ser
especificados a fin de motivar a los proveedores para destacar en estas
áreas. La negociación del contrato dará como resultado un costo planeado de-
finido, un pago planeado, un pago mínimo y máximo y una fórmula de ajus-
te del pago. A la éonclusión del contrato, el desempeño de los proveedores
servirá como la base para el ajuste del pago. Una aplicación de este tipo de
contrato podría incluir la negociación de incentivos en contraste con cada
una de las medidas de desempeño técnico (TPMs) especificadas para el
sistema, que son aplicables al ítem que es conseguido.
6.Contrato de costo compartido. Está diseñado primordialmente para el
trabajo de investigación y desarrollo conducido con instituciones educacio-
nales y organizaciones no lucrativas. Tal trabajo se patrocina conj untamen-
te y el reembolso al proveedor se da en conformidad con un acuerdo
compartido predeterminado. El pago no es concedido; no obstante, en lugar
de él, el proveedor anticipa que el trabajo realizado derivará otras utilidades
(por ejemplo, un ítem patentable, la creación de un know-how técnico, una
buena dibulgación).
7.Contrato de tiempo y material. Permite el pago de los materiales actua-
les y de los servicios adquiridos en el desempeño de los trabajos designa-
dos. Este tipo de contrato se emplea cuando la extensión y duración del
trabajo no puede ser determinado por adelantado en el tiempo y cuando los
costos no pueden ser estimados con algún grado de exactitud. Las aplicacio-
nes apropiadas incluyen los trabajos subcontratados de investigación
y desarrollo, reparación de mantenimiento y servicios de revisión, etcétera.
S. Carta de acuerdo. A menudo se utiliza como un documento contractual
inciado con el intento de autorizar al proveedor a empezar a trabajar
inmediatamente en un proyecto. Estos acuerdos sirven como medios provi-
sionales para proporcionar una respuesta rápida a una necesidad identifica-
da, que de otra manera podría ser dejada pendiente en la negociación de un
contrato definitivo. Las cartas de acuerdos usualmente no incluyen la
información total del precio; no obstante, una cantidad de dinero como
364 CONTRATACIÓN Y ADMINISTRACIÓN DE PROVEEDORES

límite superior se especifica usualmente para evitar gastos excesivos. Bajo


este tipo de acuerdo, todos los costos incurridos por el proveedor para el
trabajo realizado son completamente reembolsados por el contratante.

Asociada con cada tipo más importante del contrato está la pregunta
concerniente a la programación de sueldos. ¿Cuándo serán reembolsados al
proveedor para la conclusión exitosa de los trabajos contratados? ¿Cuál es
la magnitud de los sueldos esperados? Para la contratación de incentivos
¿cuál es el plan de incentivo-penalización? Éstas y las preguntas compara-
bles son importantes, particularmente para grandes contratos, ya que el
contratista generalmente se sujeta a un ciclo específico de presupuestación
y el proveedor debe compensar los costos de operación sin ir tan lejos en
cuanto a deuda.
La figura 8.4 presenta un ejemplo de un tipo de plan, donde el progreso
de los pagos está vinculado a la conclusión exitosa de las revisiones
formales del diseño, es decir, la revisión del diseño del sistema, la última
revisión del equipo de diseño y la revisión crítica del diseño. Estas revisio-
nes particulares del diseño incluirán la cobertura de la actividad del
proveedor, y el proceso de enlace del pago de sueldos para estos eventos,
lo cual debe motivar al proveedor para poner énfasis en esta área, con el
objetivo de asegurar el éxito.
Si la contratación con incentivo se usa, un plan de incentivo-penaliza-
ción debe ser desarrollado, como un complemento de la programación del
pago de los sueldos. Así, un plan debe especificar la aplicación de los pagos
de incentivo y penalización para indicadores importantes del proyecto y (o)
el desempeño del sistema demostrado y las características efectivas.
Al referirse a la figura 5.2 (capítulo 5), las TPMs aplicadas a nivel del sistema
deben ser distribuidas al nivel subsistema, o bien al nivel aplicable al que el
ítem debe ser proporcionado al proveedor. Las medidas de desempeño que
son realistas para el ítem que debe ser conseguido pueden ser factores
apropiados de consideración en el desarrollo de un plan de incentivo-
penalización para el proveedor.
Al desarrollar un plan de pago de incentivo-penalización es necesario
identificar los parámetros a los que los incentivos y las penalizaciones
deberán ser aplicados. En muchos casos, hay más de un parámetro que da
como resultado una estructura múltiple. La suma adecuada de dinero para
cada incentivo es difícil de determinar y dependerá del tipo de componente
(o servicio) y la importancia del ítem al que se debe aplicar el incentivo.
Es poco probable que todos los parámetros seleccionados sean igualmente
importantes. Sin embargo, será necesario asignar un "valor de importancia"
o "peso" a cada parámetro y para estimar la magnitud de los valores del
incentivo-penalización, por consiguiente. Un ejemplo de un enfoque múlti-
ple, que involucra dos características del componente, se ilustra en la fi-
gura 8.5. Un valor objetivo se establece basado en los requerimientos de la
0
00

2
08

-4 ---

w.D

()--

__
II
o
bs -ste>' -;
o CL
. 2 -1
•2 82 s
a - 2
--
- 2 o . .
O -oQ2 _ac" ° O 0 -v — 0 000
CP

1
h
1
-

Cu
366 CONTRATACIÓN Y ADMINISTRACIÓN DE PROVEEDORES

Nota: RS: relación compartida (contratista-proveedor)


30/70 SR j u
-40

30 - 50150 SR

- 20

40/60 SR:
-lo-
-20 — 30170 SR

-30 — 1

-40-

50 100 150 200 250 300 350 400 450 500

1'
UmtIe Objetivo Umtie
de confianza (garantía) de confianza
más bajo más alto

Peso del sistema-libras

5 -

2
3-

4-

- 30/70 SR

50/50 SR

6 T(" II
100 125 150 t 175 200 225 250 275 300
1' t
Límfte Objetivo Umfte
de confianza (garantía) de confianza
más bajo más amo

Tiempo medió entre mantenimiento (MTBM) horas

Figura 8.5. Planes múltiples de incentivos-penalizaciones.

especificación que también se considera como un "valor contratado".


Si, después de la prueba y evaluación, el valor real medido representa una
mejora sobre el valor objetivo, un pago de incentivo es otorgado al provee-
dor en el tiempo designado, como se indicó en la programación de la fi-
NEGOCIACIONES CONTRACTUALES 367

gura 8.4. Más específicamente, si el MTBM medido excede por arriba del
límite de confianza aproximadamente 238 horas en la figura 8.5, el pago asig-
nado debe dividirse en 20% que va al contratista yen 80% que va al provee-
dor. A la inversa, si el MTBM medido cae abajo del objetivo, una penalización
del 50% del valor indicado podría ser pagado por el proveedor. Las aplica-
ciones de tipo similar que involucran otros parámetros claves pueden ser
cubiertos a través de la contratación de incentivos-penalizaciones.
Aunque hay una variedad de tipos de contrato posibles, se debe tener
mucho cuidado al adaptar la estructura de contrato a la acción de consecu-
ción particular. Por ejemplo, si diseño y desarrollo es requerido sobre la
parte del proveedor, entonces puede ser adecuado negociar un tipo de
contrato de costo más pago fijo (CPFF) o un tipo de contrato de costo más
pago de incentivos (CPIV). En tales casos, cuando se considera la flexibili-
dad, el contratista puede tener que incrementar actividades de monitoreo
y control estricto para asegurar la conclusión oportuna de los trabajos por
parte del proveedor. Al mismo tiempo, el contratista necesita tener cuidado
de no imponer (o causar) cualquier cambio en el diseño que podrían tener
un efecto en el proveedor. Si el contratista aún sugiere una mejora posible
al producto del proveedor, o un cambio en la dirección referente a la
actividad, entonces el proveedor probablemente pedirá un cambio en
cuanto al alcance del trabajo y cobra el contrato en la forma correspon-
diente. Además, un proveedor con conocimientos de contratación puede
inicialmente presentar una propuesta que representa "un esfuerzo mínimo"
¡a fin de mantener el precio bajoyvencer a la competencia! Al mismo tiempo,
el proveedor planea iniciar los cambios y (o) adiciones en el último momen-
to para cubrir los ítems que quizá se deben haber incluido en la propuesta
inicial. Estos cambios probablemente deben ser procesados a través de una
serie de propuestas de cambio de la ingeniería (ECPs) y los últimos costos
se incrementarán en la forma correspondiente. En tales situaciones, es im-
portante que el ingeniero de sistemas esté familiarizado con los métodos de
contratación en general pero él (ella) debe estar familiarizado a detalle con
el(los) ítem(s) que es(son) propuesto(s), su carácter técnico y cómo éste
cae en la jerarquía del sistema y las diversas interfaces y los requerimientos
de soporte que son aplicados.
En el otro extremo del espectro, habrá indudablemente muchos compo-
nentes del sistema diferentes que estarán bien definidos y no se requiere un
esfuerzo adicional de diseño. En este caso, la implementación de un contra-
to a precio fijo (FFP) puede ser requerido. Para el desempeño de los
servicios, tales como la realización de las actividades de mantenimiento
y reparación el tiempo básico y tipo de materiales del contrato, pueden ser
los más apropiados.
La realización última de los términos del contrato definitivo y el
condicionamiento se realizan a través de las negociaciones formalizadas
entre el contratista y el proveedor. Las negociaciones perse pueden asumir
368 CONTRATACIÓN Y ADMINISTRACIÓN DE PROVEEDORES

un planteamiento simplificado que involucra diversas representaciones de


cada lado reuniéndose en un día dado para discutir los requerimientos en
general. Por otra parte, para los subsistemas relativamente grandes y (o) los
componentes más importantes del sistema, el proceso de negociación del
contrato puede volverse bastante complejo. En una negociación más forma-
lizada, el contratista, como respuesta a la propuesta del proveedor, interro-
gará al proveedor en relación con la validez de su enfoque técnico propues-
to, de su enfoque de la administración y (o) del precio. Las preguntas a lo
largo de una línea técnica lograrán averiguar si el proveedor ha justificado
o no que su enfoque técnico es el mejor (basándose en los resultados de los
estudios de compromisos del diseño) y que él tiene habilidad técnica
y experiencia a fin de seguir adelante y de desarrollar y producir el ítem
propuesto. En relación con el costo, el objetivo es verificar que el precio del
proveedor es justo y razonable y que fue desarrollado a través de un análisis
lógico de costos. Desde el punto de vista del proveedor, la negociación
inicialmente toma la forma de defensa de la propuesta presentada al
contratista. El proveedor puede ser requerido para proporcionar una
cantidad de material de apoyo para ayudar a convencer al contratista de que
él es meticuloso, honrado y que ofrece el mejor trato posible.
La negociación, en general, es un arte y usualmente requiere una
estrategia de ambas partes. Inicialmente, se desarrolla un plan que identifica
la ubicación donde las negociaciones deben ser mantenidas e incluidas en
la agenda para cada junta que se planee. El contratista y el proveedor, cada
uno, identifica el personal que habrá de participar en el proceso de las
negociaciones. El personal técnico y administrativo será incluido y un
representante de la organización de la ingeniería de sistemas debe estar
presente para las discusiones técnicas que cubren los requerimientos
orientados al sistema. Durante las negociaciones formales en la "mesa de
negociación", ambos lados asumirán una posición de riesgo mínimo, consi-
derando los términos contractuales y las condiciones mencionadas arriba.
Las interrupciones ocurrirán, los encuentros de estrategia corta serán
mantenidos para discutir eventos que han tomado lugar, se intentará ganar
la simpatía de parte de la oposición y, con optimismo, un acuerdo se hará
después de un arreglo de ambas partes. Este proceso puede evolucionar
a través de un número de interacciones, tal vez consumiendo más tiempo
del que se anticipó inicialmente. No obstante, el objetivo final es realizar un
contrato formal firmado entre el contratista y el proveedor.

8.4 MONITOREO Y CONTROL DEL PROVEEDOR

Con la identificación, aprobación y el establecimiento de las relaciones


formales contractuales, con los proveedores, la actividad principal del
contratista asume el papel de coordinación del programa, evaluación y
MONITOREO Y CONTROL DEL PROVEEDOR 369

control. Esta actividad continua puede ser bastante importante por las
razones siguientes:

1.La magnitud de la actividad del proveedor y el número de proveedo-


res individuales de un componente para un sistema dado puede ser extenso.
Para algunos sistemas, tanto como 50 a 75% de la actividad planeada del
desarrollo y producción, será realizado por los proveedores.
2. Además del gran número de los proveedores involucrados en la
creación del sistema, ¡la distribución geográfica de estos proveedores
puede ser mundial! Muchos sistemas utilizan componentes que son desarro-
llados y manufacturados en los países de la costa del Pacífico, Europa,
África, Canadá, México, Sudamérica, etc. Los requerimientos en la creación
del sistema pueden ordenar una auténtica comunicación internacional
y una red de distribución (véase la sección 7.4, figura 7.15).
3. En la creación de los sistemas relativamente a gran escala, donde hay
muchos proveedores de componentes diferentes, la variedad de trabajos
que es realizada en un momento dado de tiempo puede ser bastante extensa.
Algunos proveedores pueden emprender un esfuerzo de diseño y desarrollo
de tamaño natural, otros pueden realizar funciones de manufactura y pro-
ducción y hay muchos proveedores que proporcionan componentes estándar
disponibles en almacén en respuesta a las órdenes de adquisición rutina-
rias. Hay algunos programas que son discontinuos y hay otros programas
que són continuos sobre un largo período de tiempo. La figura 8.6 presenta
un ejemplo de un plan de actividades de proyectos del proveedor.

En este tipo de ambiente (muchos diversos proveedores, localizados


a nivel mundial, realizando una gran variedad de funciones), el contratista
se enfrenta a un trabajo formidable y desafiante. Como se discutió anterior-
mente, los requerimientos específicos del proveedor pueden ser desa-
rrollados cuidadosamente y claramente establecidos desde el inicio y una
estructura de contratación adecuada debe ser establecida para asegurar
que los requerimientos serán cumplidos. El tipo de contrato debe, eviden-
temente, ser diseñado al nivel de esfuerzo del proveedor.
Al referirse a la figura 8.6, los proveedores "A", "C", "D", "F" y "G" están
cada uno involucrados en un proyecto que incluye alguna actividad de
diseño y desarrollo. Como parte del esfuerzo, los estudios de compromisos
son llevados a cabo, los reportes de confiabilidad y de predicción de la
mantenibilidad son preparados, las revisiones del diseño son programadas,
las funciones de prueba y evaluación son realizadas, etc. El proceso descrito
en el capítulo 2 y muchas actividades discutidas a lo largo de los capítu-
los 6 y 7 son aplicables, aunque la tentativa debe ser reducida a escala pa-
ra ser compatible con las necesidades del programa del proveedor.
En cuanto a la evaluación y control del programa del proveedor,
el contratista debe incorporar las actividades del proveedor, como parte
370
INTEGRACIÓN DEL SISTEMA 371

del proceso global de revisión del diseño descrito en el capítulo 5. Para


grandes esfuerzos de diseño y desarrollo, las revisiones individuales del
diseño seleccionado pueden ser llevadas a cabo en la instalación del pro-
veedor, con los resultados de estas revisiones siendo incluidas en las
revisiones en el nivel más alto llevadas a cabo en la planta del contratista
(véase la figura 5.1). Para programas más pequeños, el proceso de revisión
no puede ser tan formal, con los resultados del esfuerzo del proveedor que
deben ser integrados en la evaluación de un elemento más grande del
sistema. Cuando se trata de los proyectos que involucran la manufactura de
producción de componentes (esto es, a cada uno de los proyectos de la
figura 8.6), el problema principal del contratista es el de inspección de
entrada y control de calidad. Es esencial que las características diseñadas
del componente, ¡O como se indica en un ítem disponible en almacén, sean
mantenidas completamente!
En esencia, la evaluación y control del proveedor son meramente
ampliaciones de las actividades de control y revisión del programa, inicia-
das por el cliente e impuestas por el contratista. El contratista debe, a su
vez, imponer ciertos requerimientos al proveedor. Los grandes proveedo-
res deben imponer el control necesario a los proveedores pequeños en caso
de que una "integración de los proveedores" exista, como se muestra en la
figura 7.16. El objetivo es: 1) asegurar que los requerimientos del sistema
estén siendo asignados adecuadamente de arriba-abajo y 2) que la confor-
midad con esos requerimientos esté siendo realizado de abajo-a-arriba.
El SEMP debe describir los procedimientos necesarios, las revisiones técni-
cas, etc., cómo relacionadas con las actividades del proveedor (véase la
figura 6.5, parágrafo 4.0 del bosquejo del SEMP propuesto).

8.5 INTEGRACIÓN DEL SISTEMA

Inherente a los conceptos asociados a la ingeniería de sistemas es la función


de "integración". Inicialmente como parte del diseño conceptual, el énfasis
está colocado en la definición de los requerimientos del sistema y la
integración adecuada de estos requerimientos a través del desarrollo de
la especificación Tipo "A" del sistema y el SEMP. Luego, durante el diseño
preliminar y de detalle, la necesidad de integración continúa. Desde la
perspectiva técnica hay un esfuerzo de integración continua asociada con
la interfaz adecuada de los subsistemas, unidades, ensambles, módulos,
software, datos, localidades, equipo de prueba y soporte, personal y demás
elementos del sistema. El software debe ser compatible con el hardware, el
equipo de prueba y soporte debe ser compatible con el equipo esencial,
el personal debe ser compatible con el equipo y el software, etc. También
hay un impulso administrativo que se ocupa de la integración adecuada de
las diversas disciplinas del diseño y de las demás actividades del programa
374 CONTRATACIÓN Y ADMINISTRACIÓN DE PROVEEDORES

relacionado. Finalmente, hay una función de integración crítica asociada


L a la combinación de los diversos componentes del sistema dentro de una
entidad operante que responde a las necesidades del consumidor.
En las fases iniciales del diseño, el énfasis está esencialmente en un
enfoque de arriba-abajo. Los requerimientos del sistema se definen, los
análisis funcionales se concluyen y los requerimientos de nivel superior del
sistema son asignados con la profundidad necesaria para proporcionar los
criterios para propósitos de dirigir el diseño. Conforme el diseño avanza,
los estudios de compromisos son llevados a cabo y se seleccionan los
componentes del sistema. A través de la síntesis, los conceptos del diseño
son verificados y los componentes se combinan para formar los grandes
elementos del sistema. En esta etapa hay un cambio en el énfasis hacia un
enfoque abajo-arriba, como el observado en la figura 8.7 Los componentes
se identifican en el nivel más bajo y se integran en sus ensambles, los
subensambles se integran a los ensambles, los ensambles se integran a las
unidades, etcétera.
Al referirse a la figura 8.7, el objetivo de integración es asegurar que los
componentes 1,2,3... y8 no son sólo compatibles con cada uno de los otros,
sino que pueden integrarse adecuadamente al subensamble "B", conside-
rando todas las tolerancias ylos requerimientos de intercambiabilidad.
Aunque esta meta debería ser obvia, ésta no siempre ha sido alcanzada.
Históricamente, los sistemas han sido desarrollados en su mayoría de abajo-
arriba, sin ¡aventaja de una perspectiva de tipo más alto y, en muchos casos,
el proceso de integración ha ocurrido a través de la aplicación de métodos
"de fuerza bruta", ¡utilizando un enfoque de "prueba y error"! La integración
de los componentes no ha sido muy fácil, las sustituciones del componente
se han hecho al momento, el gasto ha sido grande ¡y los costos resultantes
han sido altos!
A causa de estas experiencias pasadas con la integración y prueba del
sistema, es importante que un enfoque de arriba-abajo de la ingeniería
de sistemas se implemente desde el inicio. A través de la definición
y distribución adecuada de los requerimientos en el diseño inicial del
sistema, muchos problemas experimentados en el pasado pueden, con
optimismo, ser evitados en el futuro. Con la identificación temprana y la
eliminación de las áreas potenciales del problema, el proceso de integración
del sistema realizado hacia el final del diseño de detalle, la etapa de desarrollo
puede ser significativamente mejorada. En lugar de depender de la integra-
ción final del sistema y de la actividad de prueba para resolver todos los
problemas, es necesario que el enfoque de abajo-arriba para el diseño del
sistema siga los requerimientos establecidos a través del proceso de arriba-
abajo. Sin la consideración adecuada de la integración del sistema desde el
inicio, los problemas asociados a la integración final y a la actividad de
prueba continuarán como en el pasado.
Recordando las últimas consideraciones, una integración global del
PREGUNTAS Y PROBLEMAS 375

sistema y un plan de prueba deben ser desarrollados e incluidos en el SEMP.


El objetivo es describir el flujo del proceso y los trabajos asociados con la
integración de los componentes de abajo-arriba, como se ilustró en la figu-
ra 8.7. Esta actividad prevalece durante la fase del diseño y desarrollo,
comenzando con la integración de los componentes que emplean técnicas
de simulación en conjunción con los métodos de diseño asistido por com-
putadora. Conforme los componentes se identifican y selecciones de ellos
se integran adecuadamente al sistema, eventualmente serán verificados por
medio de la prueba y evaluación final del sistema (véase la sección 2.8).
Este proceso del flujo de la integración del sistema se mostró en la figu-
ra 8.8. Los componentes se introducen tempranamente en el diseño (obser-
vando la figura desde la izquierda), combinados e integrados a los elemen-
tos del nivel más alto del sistema y un esfuerzo de prueba y evaluación del
sistema se realiza de acuerdo con el TEMP. Este esfuerzo de integración se
realiza empleando un enfoque paso por paso, que evoluciona de izquierda
a derecha, empleando una combinación de medios individuales analíticos
de evaluación y (o) mediante la conducción de una serie de pruebas de los
componentes. El objetivo de este esfuerzo de integración es asegurar que
todos los componentes sean compatibles entre sí, que se acomoden adecua-
damente en el siguiente ensamble más alto, que sean intercambiables (como
es pertinente) y que funcionen como se requiere.
En resumen, la organización de la ingeniería de sistemas no sólo debe
asegurar que un buen y gran esfuerzo de integración del sistema se planee
inicialmente, sino que también los diversos trabajos de integración se
realizen durante el esfuerzo completo de diseño y desarrollo del sistema.
De particular importancia son los retos asociados con las muchas funciones
del proveedor, identificados anteriormente en este capítulo. Estas activida-
des del proveedor, la liberación de los componentes, la integración de los
componentes al sistema, etc., deben ser cubiertas en la integración y en el
plan de prueba del sistema del contratista.

PREGUNTAS Y PROBLEMAS

1. Describa con sus propias palabras los pasos que deben seguirse al
determinar los "requerimientos del proveedor" asociados con la
creación de un nuevo sistema.
2. Identifique y describa algunos factores que deben ser considera-
dos en las decisiones "hágalo o cómprelo".
3. ¿Por qué es importante el desarrollo de un plan "hágalo o cómpre-
lo"? ¿Qué se incluye en él?
376 CONTRATACIÓN Y ADMINISTRACIÓN DE PROVEEDORES

4. ¿La organización de la ingeniería de sistemas debe involucrarse en


las decisiones "hágalo o cómprelo"? Si es así, ¿en qué capacidad? Si
no, ¿por qué?
S. El desarrollo de una RFP en preparación para las propuestas del
proveedor, evaluación y selección es extremadamente crítico des-
de el punto de vista de la Ingeniería de sistemas. Identifique y explique
las razones para esto y describa brevemente las características
claves que deben estar incluidas.
6. Véase la figura 8.2 y 8.3. Desarrolle una lista de verificación de
evaluación de una propuesta del proveedor para aplicación en su
propia organización repare la lista de verificación en el formato
mostrado en la figura 8.2 y proporcione un desglose de factores para
cada ítem en su lista de verificación, como se ilustró en la figura 8.3).
7. ¿Cómo pueden influir los factores políticos, sociales y económicos
al proceso de selección del proveedor? Proporcione algunos ejem-
plos.
S. Describa con sus propias palabras algunas de las tendencias que
ocurren en el mundo actual en relación con las actividades del
cliente, contratista, proveedor.
9. ¿Qué se entiende por "soporte de postproducción"? Proporcione
algunos ejemplos.
10. Hay un número de retos asociados con la administración y control
de los proveedores. Identifique y describa algunos de ellos.
11. Suponga que usted recientemente fue nombrado administrador de
las actividades del proveedor del sistema en una organización del
contratista. Describa su enfoque de planeación, organización, iden-
tificación de los trabajos, implementación del control, evaluación,
etcétera.
12. Como parte de un esfuerzo de evaluación del proveedor, usted está
planeando visitar la localidad del proveedor. ¿Qué haría para prepa-
rarla y qué información solicitaría durante la visita al lugar?
13. Hay varios tipos de escrituras de contrato que pueden imponerse a
través de un proceso de negociación del contrato para incluir FFP,
FP, CPFF, CPIF, costo compartidoy tiempo y material. Describa cada
una e incluya una explicación de cómo se deben aplicar.
14. Cuando se establecen múltiples incentivos bajo la contratación
de incentivos, ¿qué pasos seguiría usted? ¿cómo determinaría
los factores específicos o características en los cuales establecer los
incentivos?
PREGUNTAS Y PROBLEMAS 377

15. Bajo la contratación de incentivos, ¿qué se entiende por una rela-


ción compartida de incentivos-penalizaciones? ¿Cómo se aplica?
¿Cómo se relaciona la SR a los riesgos del contrato-proveedor?
16. El ingeniero de sistemas ¿debe participar en el proceso de negocia-
ción del contrato? Si es así, ¿en qué capacidad?
17. La organización de la ingeniería de sistemas ¿debe participar en las
actividades de administración ycontrol del proveedor? Sí es así, ¿en
qué capacidad?
18. Véase al capítulo S. ¿Cómo están cubiertos los proveedores (y la
actividad del proveedor) a través del proceso de revisión del diseño
formal?
19. Describa qué se entiende por "integración del sistema". ¿Cómo se
realiza? ¿Qué incluye? ¿Cuándo se realiza? ¿Por qué es importante?
20. Explique algunos conceptos asociados con los enfoques "arriba-
abajo" y "abajo-arriba" al diseño y desarrollo del sistema? ¿Cómo se
relacionan (si es que lo hacen)? ¿Cómo se involucra la ingeniería
de sistemas?
APÉNDICE A
EJEMPLOS DE CASOS DE ESTUDIO

A lo largo de los capítulos 2, 3 y 4 hay discusiones relativas a la organización


de estudios de compromisos y la utilización de estudios analíticos en la
toma de decisiones de la ingeniería. Por medio de una ilustración del
proceso, han sido seleccionados cuatro ejemplos abreviados:

1.Análisis de costo del ciclo de vida (Ejemplo 1). Compara dos configu-
raciones del diseño de sistemas alternativos, ilustrando el proceso de
análisis del costo del ciclo de vida a través de este ejemplo. Éste incluye los
pasos de la definición del problema, la definición de los requerimientos
operacionales y el concepto de mantenimiento, la estructura de descompo-
sición de costos (CBS), la estimación de costos, la generación de los perfiles
de costos, el desarrollo de un análisis desglosado, etcétera.
2. Nivel de análisis de reparación (Ejemplo 2). Compara las opciones de
diseñar un ítem para reparación en el nivel medio de mantenimiento,
reparación en el depósito/localidad del proveedor y para descartar la falla.
3. Análisis de trabajo de mantenimiento (Ejemplo 3). Evalúa una función
de manufactura en términos de los requerimientos de mantenimiento
y soporte. Esto lleva a la identificación de las áreas específicas donde el
consumo de las fuentes de apoyo es excesivo, y donde las recomendaciones
para la mejora del producto son adecuadas.
4. Evaluación de las configuraciones alternativas del diseño (Ejemplo 4).
Involucra la comparación de tres configuraciones alternativas en respuesta
a un requerimiento de diseño del sistema. Los múltiples criterios de evalua-
ción, que usan factores de importancia para establecer los niveles de
importancia, se emplean.
Figura 8.7. Integración del stema (enfoque abajo-a-arriba desde la base).

Figura 8.7. Integración del sistema (enfoque abajo-a-arba desde la base).

Integración y prueba del sistema

Recursos
de prueba
Unidad A
Subensamble

D
- -—VI–_ Ensamble Unidad A Sistema Z

L__
c
I

__
- - - - H dad C Capacidad
de soporte
M sistema

LL

Figura 8.8, Integración y prueba del sistema.


380 APÉNDICE A: EJEMPLOS DE CASOS DE ESTUDIO
ANÁLISIS DEL COSTO DEL CICLO DE VIDA (EJEMPLO 1) 381

A. 1 ANÁLISIS DEL COSTO DEL CICLO DE VIDA (EJEMPLO 1)


El nuevo sistema de comunicaciones debe ser adaptable para usarse en
todas las aplicaciones designadas, es decir, tos vehículos terrestres y las
A. 1.1 Definición del problema
localidades. La única diferencia de configuración entre la instalación en el
vehículo y la instalación en la localidad debe estar en las condiciones de
Una gran organización desea aumentar su capacidad global mediante la
interfaz, los elementos del montaje, etc. Además, el sistema de comunicacio-
creación de un nuevo sistema de comunicaciones para instalarlo en ambas
nes debe cumplir los siguientes objetivos:
partes, en los vehículos terrestres, y en las localidades distribuidas a lo
largo de cuatro diferentes áreas geográficas. Un total de 120 instalaciones
1. En cada una de las cuatro áreas geográficas, el sistema debe ser
del sistema se requieren con 30 sistemas en cada una de las 4 áreas.
instalado en 25 vehículos terrestres (uno por vehículo). Esto hará posible la
En respuesta a este requerimiento, dos configuraciones alternativas del
comunicación con otros vehículos en un radio de 25 millas, y con algunas de
sistema deben ser consideradas y evaluadas en base al costo del ciclo de
las cinco localidades en un rango de 100 000 millas o menos. Cada vehículo
vida (LCC).
estará en operación 8horas por día, 5 días por semana, y será utilizado 100%
durante ese tiempo. El MTBM requerido es de 400 horas, y la Mct debe ser
A.1.2 El proceso de análisis
menor a 60 minutos.
La realización de un análisis de costo del ciclo de vida requiere suficiente Requerimientos de sistemas uperacionales
ampliación de la descripción de la definición del problema. Al referirse a la
Lugares operacionales (locaciones de usuarios)
figura 3.28 uno de los primeros pasos es desarrollar un plan operacional
para dos alternativas. Éste incluye la definición de los requerimientos
Sistema de Sistema de Sistema de Sistema de
operacionales del sistema, el concepto de mantenimiento y un plan del comunicaciones (A) comunicaciones (B) comunicaciones (C) comunicaciones (D)
programa que ilustra las actividades durante el ciclo de vida propuesto.

O Tienda número 17 Tienda número 2


de mantenimiento [de mantenimiento

1 Localidad ()
inteunedio intermedio

1 de comunicación

® Proveedor (manleni.
VD Localidad -- - - -. J
Localidad
0 miento de depósito)
de oomunicación

.\
I\
,
Localidad localidad
Mantenimiento1
activo 11 Unidad interinedia
1 1
Ensamble del
proveedor-depósito
de comunicación - ----- -de comunicación Encasod. quo .no IRupel1id.d 1
I incorpo* la P~
pis vopadca
-*1
pwk~ p« aliIwiunio
laja a rív del
1 psp.. i enun*s
F-•--------------1 peineed. por alaleenlunlo
O
l.nlunbd.IahIaaIa de
unhdadA,,sedadB,o .1 1
O O
udd.dC. 8~iat,dd.d P'''°- 1 1
çscgl. y r.nlddcslu unu 1 1 in peeun cun un
p.c M.unlapreeeeo
No un tique. 1
Funciones del proveedor

Figura A.l. Distribución de los sistemas en las áreas geográficas.


Figura A.2. El plan de operación del sistema y el concepto de mantenimiento.
380 APÉNDICE A: EJEMPLOS DE CASOS DE ESTUDIO

A.1 ANÁLISIS DEL COSTO DEL CICLO DE VIDA (EJEMPLO 1)

A. 1.1 Definición del problema

Una gran organización desea aumentar su capacidad global mediante la


creación de un nuevo sistema de comunicaciones para instalarlo en ambas
partes, en los vehículos terrestres, y en las localidades distribuidas a lo
largo de cuatro diferentes áreas geográficas. Un total de 120 instalaciones
del sistema se requieren con 30 sistemas en cada una de las 4 áreas.
En respuesta a este requerimiento, dos configuraciones alternativas del
sistema deben ser consideradas y evaluadas en base al costo del ciclo de
vida (LCC).

A.1.2 El proceso de análisis

La realización de un análisis de costo del ciclo de vida requiere suficiente


ampliación de la descripción de la definición del problema. Al referirse a la
figura 3.28 uno de los primeros pasos es desarrollar un plan operacional
para dos alternativas. Éste incluye la definición de los requerimientos
operacionales del sistema, el concepto de mantenimiento y un plan del
programa que ilustra las actividades durante el ciclo de vida propuesto.

0
Localidad -
1
de comunicación
L o
D
V - Localidad — '
Localidad
._. de comunicación 0
de comunicación
*\.

0 I\
\\. ,
Localidad -{) - Localidad
- _ de comunicación_ ----- -de comunicación

o 0

Figura Al. Distribución de los sistemas en las áreas geográficas.


ANÁLISIS DEL COSTO DEL CICLO DE VIDA (EJEMPLO 1) 381

El nuevo sistema de comunicaciones debe ser adaptable para usarse en


todas las aplicaciones designadas, es decir, los vehículos terrestres y las
localidades. La única diferencia de configuración entre la instalación en el
vehículo y la instalación en la localidad debe estar en las condiciones de
interfaz, los elementos del montaje, etc. Además, el sistema de comunicacio-
nes debe cumplir los siguientes objetivos:

1. En cada una de las cuatro áreas geográficas, el sistema debe ser


instalado en 25 vehículos terrestres (uno por vehículo). Esto hará posible la
comunicación con otros vehículos en un radio de 25 millas, y con algunas de
las cinco localidades en un rango de 100 000 millas o menos. Cada vehículo
estará en operación 8horas por día, 5 días por semana, y será utilizado 100%
durante ese tiempo. El MTBM requerido es de 400 horas, y la Mct debe ser
menor a 60 minutos.
Requerimientos de sistemas operacionales

Lugares operacionales (locaciones de usuarios)

Sistema de Sistema de Sistema de Sistema de


comunicaciones (A) comunicaciones (B) comunicaciones (C) comunicaciones (D)

Tienda número 1 Tienda número 2


de mantenimiento de mantenimiento
intermedio intermedio

Proveedor (manteni-
miento de depósito)

Mantenimiento 1 1 Unidad intermedia 1 Ensamble del


correctivo 1 proveedor-depósito
1 1
Encasode que «no Repare launidad
Muntarniardo CO,T.O
flccrpore la pnJ.a p.r*nente por latarmento
que opccunael 1 defalaselveldel Prepara el ensambe
1 ensamble pednente por aáIaIrIenIO
ldanknbdola boa ala de lada a la parte
unidad A, unidad ° remplace
unidad C. Elmine la unidad 1
compcnenle y(o)mór*.io.
,'rente c un
aplcÉde y rwrd&cela con *cedenle. Elmbre el remp4azo del
un excedente. LI. lleon pardeenle ene un
VIardedib erer&o excedente
Ninguno _____
MacIardn,iente_raee*e
so
NosereqeierePJ
1 Ninguno
Funciones del proveedor

Figura A.2. El plan de operación del sistema y el concepto de mantenimiento.


382 APÉNDICE A: EJEMPLOS DE CASOS DE ESTUDIO

2. En cada área geográfica, el sistema debe ser instalado en cinco


localidades terrestres de comunicación (uno por localidad). Cada sistema
hará posible la comunicación con los vehículos terrestres en un rango de
100 millas y, con las demás localidades, en un rango arriba de 300 millas.
Los requerimientos de la utilización del sistema serán 16 horas por día en
siete días por semana, la MTBM requerida es 200 horas, y la Mct no debe
exceder de 30 minutos. Hay cuatro áreas geográficas más importantes, dos
de las cuales incluyen terreno montañoso y una incluye área de desierto.
Aunque la distribución real de los sistemas varía de un área a la
siguiente, la red ilustrada en la figura A.1 es representativa. Cada área
geográfica se representa por un bloque designado bajo "sitios operacionales"
en la figura A.2, es decir, área (A), área (B), área (C), y área (D).

Dado el plan operacional global, una breve descripción del concepto de


mantenimiento del sistema es necesario. Al remitirse a la figura A.2, tres
niveles de mantenimiento se asumen: mantenimiento organizacional, in-
termedio y del proveedor (depósito). El mantenimiento organizacional se
realizará en el vehículo o en la localidad (según se aplique), e incluirá la

Adquisición Capacidad operacional completa

Investigación y desarrollo Fuera de fase "


o-

Producción

Operación y soporte de mantenimiento

1 2 3 4 5 6 7 8 9 10 11 12

Tiempo del programa (años)


160
140
120
2
qn
100
' 80
60
40
20
o

1 2 3 4 5 6 7 8 9 10 11 12

Tiempo del programa (años)

Figura A.3. Plan del programa y perfil.


ANÁLISIS DEL COSTO DEL CICLO DE VIDA (EJEMPLO 1) 383

remoción y remplazo de unidades. Las unidades que fallaron serán trans-


portadas a la tienda de nivel intermedio donde las actividades de manteni-
miento incluirán reparación de unidad mediante de la remoción y remplazo
de ensambles. La reparación de ensamble se realizará en la localidad del
proveedor donde las actividades de mantenimiento de almacén serán
realizadas. La estructura ilustrada en la figura A.2 proporciona las bases
para el establecimiento de los factores de confiabilidad, mantenibilidaci
y los factores logísticos necesarios en el desempeño del análisis del costo
del ciclo de vida. Si se prefiere un detalle adicional, esta estructura puede
ser ampliada para reflejar el detalle en la figura 2.6 (capítulo 2).
El tercer elemento de información necesario en el establecimiento de
una base para el análisis del costo del ciclo de vida es una proyección de las
actividades anticipadas para cada fase del ciclo de vida. En este caso, cada
una de las dos configuraciones que deben ser evaluadas requerirán un
esfuerzo de investigación y desarrollo seguido por la producción, la utiliza-
ción del sistema y las actividades de soporte. El marco para estas activida-
des se muestra en la figura A.3. También se incluye un perfil de inventario
propuesto, basado en los requerimientos operacionales iniciales del sis-
tema. El perfil de inventarios proporciona una indicación del número de
sistemas realmente en uso operacional en unas bases año-por-año.
Al remitirse a la figura 3.32, el siguiente paso en el proceso de análisis de
costo del ciclo de vida, es el desarrollo de una estructura desglosada
de costos (CBS). La CBS es un desglose del costo en términos funcionales,
esto incluye la consideración de todos los costos, y va con la profundidad
necesaria para proporcionar la visibilidad de los elementos del sistema en
áreas importantes de actividad. La figura A.4 presenta un ejemplo de la CBS.
Aunque no todas las categorías pueden ser relevantes en términos de
magnitud del costo como una función del costo total del ciclo de vida, esta
CBS sirve como un buen punto de inicio. Inicialmente, todos los costos
deben ser considerados, con el objetivo último de concentrarse sobre
aquellas categorías de costo que reflejan los "más altos colaboradores".
Dado el mecanismo para la asignación y recopilación de costos (esto
es, la CBS), uno necesita distribuir y estimar los costos para cada uno de los
sistemas de comunicación alternativos. En un intento por ser más específi-
cos para el análisis de costo del ciclo de vida, el analista puede desear
considerar los siguientes pasos:
1. Identifique todas las actividades anticipadas del programa, a lo
largo del ciclo de vida proyectado de cada alternativa, que gene-
rará los costos de un ítem u otro.
2. Relacione cada actividad a una categoría de costo específico en la
CBS. Cada actividad debe caer en una o más categorías; no obstante,
si esto no ocurre, entonces la CBS necesita ser ampliada o revisada
como es adecuado para cubrir el esfuerzo requerido.
384 APÉNDICE A: EJEMPLOS DE CASOS DE ESTUDIO

3. Desarrolle una hoja de trabajo de tipo matricial a fin de recordar


los costos para cada categoría aplicable por año. La figura A.5
ilustra un ejemplo del formato de datos. El ciclo de vida asumido
y las actividades más importantes se basan en el plan del programa
presentado en la figura A.3.
4. Genere los datos de costos de entrada para cada actividad aplicable
listada en la matriz, y registre los resultados en la figura A.S. El costo
inicialmente puede ser presentado en términos de "dólares cons-
tantes" luego convertidos a "dólares reales" para incluir los efectos
de los factores inflacionarios, las curvas de aprendizaje, etc.,
y finalmente conviértalos a dólares de "valor presente" para propó-
sitos de comparar las alternativas.

Remítase a la figura A.4, las categorías esenciales del costo son Cr


y C0. Los siguientes párrafos presentan una revisión de las fuentes más
importantes que apoyan estas áreas relevantes del costo. El material aquí
cubierto se presenta con suficiente detalle para cubrir el enfoque global
usado en la evaluación de las dos configuraciones alternativas del sistema
de comunicación. Una discusión profunda de cada factor de entrada de
costo sería bastante extensa:

1. Costo de investigación y desarrollo (CR). Esta categoría incluye la


composición de aquellos costos iniciales no recurrentes del diseño en
desarrollo contratados por el cliente y el contratista. Hay "costos comunes"
para el cliente que están asociados con ambas alternativas (esto es, pla-
neación, estudios de factibilidad, y la definición de los requerimientos),
y hay costos peculiares para cada uno de los dos proveedores propuestos.
Aunque es adecuado desglosar los costos en cada categoría aplicable de
la estructura desglosada de costos (véase la figura A.4), estos costos están
resumidos aquí para fines de sencillez. El costo total de investigación
y desarrollo (Cp) para la Alternativa "A" es $545 000 ($235 000 por año 1
y $ 310 000 por Año 2). Para la Alternativa "B", el valor equivalente es de
$602 000 ($276000 por año 1 y$326 000 por año 2). Estos costos esencialmen-
te son transacciones financeras que afectan al estado de pérdidas y ganancias
que constituyen la administración y la labor de la ingeniería con los factores
inflacionarios adecuados incluidos.
Los costos de material asociados con los modelos prototipo de la
ingeniería usados para prueba y evaluación también se incluyen. Estos
costos se incluyen en la figura A.6.
2. Costo de inversión (CO. Esta categoría incluye todos los costos
asociados con la producción de 120 sistemas identificados en la figura A.3.
El "perfil de producción" se presenta al margen izquierdo del perfil del
inventario en la figura, y el espacio de la producción cubre los Años 3, 4,
ANÁLISIS DEL COSTO DEL CICLO DE VIDA (EJEMPLO 1) 385

Costo total del sistema

Investigación y desarrollo (Ca ) Inversión (CI) 1 Operaciones y mantenimiento


(C0)

Aflristradórr del programa (C) 1 Manufactura (CIM) 1 Operaciones (CO0)


1

Avance R&D(C
• Ingeniería de manufactura • Personal operante (C0)
• Herramientas y ep4o de prueba • Entrenamiento del operador (Cosr)
•Fabricación •localidades operacionales (C)
Diseño de la rigerierta (CE) •Ensamble •equipo de Soporte y manejo (C)
• Inspección y prueba
•Control de te calidad 1 Mantenimiento
•tegeriería de sistemas
•Material (Inventado)
•Diseño eléctilco
•Empaque y transportación • Personal de mantenimiento y so-
•Diseño mecánico
porte (COMM)
•Conflabiidad
Construcción (C0) -Nivel organizacional
•Capacidad de mantenimiento
-Nivel Intermedio
•Factores tirnanos
Localidades de manufactura -Nivel de depósito
•Capacidad deproducción
(C) -Nivel del proveedor
•AÑites de soporte logístico
Localidades de prueba (C 1) • Partes excedentes de reparación
Localidades operacionales (C)
Desarrollo y prueba de la irgelierla (C) (C110) -Nivel organizacional
Localidades de mantenimiento -Nivel intermedio
(C1 ) -Nivel de depistio
•Modelos de la ingerlerta
-Nivel del proveedor
•Prueba y evaluación
• Mantenimiento de equipo de prue-
Dates de la ingerierta (C)
Soporte logístico Inicial (CIL) 1 ba y soporte (C)
• Transportación y manejo (C)
• Administración del programa • Entrenamiento de mantenimiento
Nota: véasela tabla A-1 para ladesaEdónde (C) (C)
las categorías del costo. • Abasto • Localidades de mantenimiento
• Partes iniciales excedentes/ (Comt)
í iede observarse que los costos del s1 de reparación (C1 0) • Datos técnicos (C)
porte logístico directos constituye las • Administración inicial del In-
Calegorlas ClLy Coy parte dala catego- ventano (CIL? Modificaciones al slotema/equo

L2 CRE.
-----1 • Preparación de los datostéc-
nicos (C LO)
(C0)
• Entrenamiento inicial y equi- Fase de retiro progresivo y desech
po de entrenamiento (C LI) (C0)
• Creación del equipo deprue-
ba y soporte (C1 0)
• Primera transportación dees-
timación (C LI)

Figura A.4. Estructurade descomposición de costo (CBS). (Fuente: Blanchard, BS., Logistics Engíneering
and Management, 31 ed., Prentice-Hafi, Englewood Cliffs, N.J., 1986.)
386 APÉNDICE A: EJEMPLOS DE CASOS DE ESTUDIO

Actividad del programa Destino Costo por año del programa ($) Costo Contribu-
dela total clónpre.
categoría- - - -- - - - -- - sente(%)
del costo 1 2 3 4 5 6 7 8 9 10 11 12

Aemattra A
1 Costo de investigación ydesarrolio CR
a.Administración del programa CFN
b.Diseño de la Ingeniería CRE
c.Diseño eléctrico CRED
d.Datos de la ingeniería CRO
2.
3.
Otras

Costo total real C

Costo total P.V,(10%) C(10)

Atiemativa 8
y
1. Costo de Investigación desarrollo CR
a. Administración del programa C
b.Diseño de la Ingeniería CRE
Etc.

Figura A.S. Roja de cálculo de recopilación de costos.

y parte del Año S. Al remitirse a la figura A.4, esta categoría incluye los cos-
tos de administración, los costos de manufactura periódicos y no perió-
dicos, los costos de fabricación y ensamble, los costos del control de
calidad, los costos de soporte logístico inicial, etc. Se incluyen los efectos
de la inflación (que se aplican tanto al trabajo como al material) y las cur-
vas de aprendizaje.
De nuevo, por razones de sencillez, estos costos están resumidos en la
figura A.6A y se incluyen en la figura A.6. Para un análisis más profundo, es
conveniente revisar la figura A.4 y ampliar las diversas categorías de costo
en mayor detalle. Esto es particularmente cierto cuando los proveedores
han desarrollado los costos basándose en la aplicación de la curva de apren-
dizaje, por ejemplo un 80% de la unidad o un 90% de la curva de aprendizaje
acumulativa para las cantidades de producción repetitivas. Muchas decisio-
nes pertenecientes a la selección del proveedor se basan en una suposición
en relación a los costos asociados con éste.
3. Costo de operaciones y mantenimiento (Co). Esta categoría incluye los
costos de operación y apoyo al sistema durante su ciclo de vida planeado.
Estos costos constituyen los costos del usuario y se basan esencialmente en
la información de planeación del programa presentada en la figura A.2 yA.3.
El perfil de inventario de la figura A.3 está ampliado como se muestra en la
figura A. 7, para incluir la cantidad específica de sistemas en uso ye! tiempo
388 APÉNDICE A: EJEMPLOS DE CASOS DE ESTUDIO

Alternativa Año 3 Año 4 Año 5 Total

Alternativa A $2,367,000 52295,000 $2150,000 $6,812,000

Alternativa B $2240000 $2,180,000 $2120000 $6540000

Figura A.6A. Inversiones.

total de operación (en horas) para todos los sistemas en cada año aplicable
del ciclo de vida.
La utilización del sistema se basa en los tiempos individuales de
operación especificados para las aplicaciones del vehículo y las localidades
del sistema multiplicado por la cantidad de sistemas en uso. Aunque la
utilización actual variará de operador a operador, de organización a organi-
zación, de una área geográfica a la siguiente y así sucesivamente, los fac-
tores incluidos en la figura A.7 son los valores promedio y se emplean en
el ejemplo de base. También, se asume que cada configuración alternativa
siendo evaluada será operada de la misma manera.
Dados los factores para la utilización del sistema, junto con los valores
MTBM del sistema propuestos para cada uno de los probables proveedores
(por ejemplo, 575 horas por alternativa "A" y 450 horas por alternativa "B"),
es posible estimar la cantidad de actividades de mantenimiento para cada
alternativa. Una relación de estimación de $1000 por actividad de manteni-
miento se emplea, ylos costos del mantenimiento resultante se incluyen en
ambas figuras, la A.6 y la A.7.

A.1.3 Los resultados del análisis

Los resultados del esfuerzo de estimación de costos se proyecta en la figura


A.6 y A.8. Ambas proyecciones muestran los costos actuales inflados ylos
costos a valor presente (una tasa de 10% de descuento se asume). Cuando
se comparan las dos alternativas del costo a valor presente, aunque parezca
extraño la alternativa "A" se prefiere por un margen de $485 900 (esto es,
$7 925,700 menos $7 441 800).
No obstante, antes de tomar una decisión final, uno debe identificar el
punto en el tiempo cuando la Alternativa "A" asume la posición preferida.
La figura A.9 presenta los resultados de un análisis desglosado, donde los
costos acumulados se proyectan en una base relativa. A partir de los datos,
parece que la alternativa "A" asume la posición preferida al final del 40 año
del programa. ¿Es razonable este punto en términos de seleccionar
esta alternativa? Si el punto desglosado está muy lejos en el tiempo, debería
convenir más seleccionar la alternativa "B". La respuesta a esta pregunta
AA
8

cli

cc
cO

h-

- :
cc cc cc
Q CO CO
c
r-

8
U) cccc
CO Cc, Cc, CO cc) Cc, CO
sCO CO

N
cc, CO
'
cD cc

C) cc) '- CM CO cc, CO

8 U) "' cc,
U)
o

0
cci U)
CO O CO

:2 E
.2
E E
cc

66

o cc, oo oo,
E E

-8 -8 - cn 16
-

:2
L
lo
¿3

389
390 APÉNDICE A: EJEMPLOS DE CASOS DE ESTUDIO

Costo sin descuento Costo descontado P.V.


Años Tactor de
Alto A Alto B descuento Alto A Alto B
1 325 276 0.9091 216.6 250.9
2 310 326 0.8265 256.2 269.4
3 2472 2374 0.7531 1861.7 1787.8
4 2643 2624 0.6830 1805.2 1792.2
5 2642 2749 0.6209 1640.4 1706.8
6 565 721 0.5645 318.9 407.0
7 565 721 0.5132 289.9 370.0
8 565 721 0.4665 263.6 336.3
9 565 721 0.4241 239.6 3.5.8
10 565 721 0.3856 217.9 278.0
11 565 721 0.3505 198.0 252.7
12 420 721 0.3186 133.8 170.8
Factor de descuento= 10% 7,441.8 7,927.7

3D

lom

500

o
1 2 3 4 5 6 7 8 9 10 11 12

Ciclo de vida-años

Figura A.S. Perfil del costo (alternativa EA").

está en función del tipo de sistema, las tecnologías específicas incorporadas


en el diseño, las posibilidades de obsolescencia, la longitud del ciclo de vida
planeado, el nivel de competencia, etcétera.
ANÁLISIS DEL COSTO DEL CICLO DE VIDA (EJEMPLO 1) 391

OID

aID

icto

1 2 3 4 5 6 7 8 9 10 11 12

Ciclo de vida del programa (años)

Figura A.9. Análisis de equilibrio.

En cualquier caso, el analista no sólo debe observar el delta del costo,


sino que él (ella) debe evaluar los perfiles del costo en términos de equi-
valencia. Posteriormente debe realizarse un análisis de sensibilidad con el
objetivo de identificar las posibles áreas de riesgo. El análisis de sensibilidad
involucra la identificación de los parámetros clave de entrada selecciona-
dos, y la valoración posterior de estos parámetros en términos de su efecto
en los resultados de su análisis. Por ejemplo, la experiencia pasada indica
que el parámetro MTBM es un factor clave para determinar el costo del ciclo
de vida, particularmente la faceta del LCC que cubre la opera-ción y las
actividades de mantenimiento del sistema. También, la determinación
inicial de los requerimientos MTBM algunas veces se dificulta a causa de la
escacez de buenos datos históricos, y una gran cantidad de dependencia se
coloca en un buen ejercicio de predicción. En vista de la importancia de este
parámetro en el diseño, puede ser conveniente, "probar" el factor MTBM
mediante la variación de sus valores por medio de un rango designado de
valores para ver si la decisión resultante aún favorece a la alternativa "A".
Hay dos preguntas básicas: ¿Qué efecto tiene la variación de la MTBM, como
parámetro de entrada, en los resultados del análisis? ¿Cuánta variación de
el parámetro de entrada MTBM puede ser tolerada, mientras aún apoye la
392 APÉNDICE A: EJEMPLOS DE CASOS DE ESTUDIO

decisión de seleccionar la configuración "A"? El objetivo de aquí es valorar


la sensibilidad de ciertos parámetros críticos en términos de su efecto
con la toma de decisiones, la que, a su vez, lleva a la cuantificación del ries-
go potencial.
Como punto final, el analista debe intentar identificar algunos de los
colaboradores más importantes de "costo alto" para revisar la salida del
análisis del costo del ciclo de vida; es decir, los costos detallados identifica-
dos por las categorías de costo en la CBS. Aunque no se muestra en este
ejemplo de estudios un caso, los resultados de análisis mostrarán el costo
del personal de mantenimiento, el costo de las partes de repuesto-de
reparación, etc. Los "impulsores altos" deben identificarse, deben es-
tablecerse las relaciones causa y efecto y las recomendaciones de acción
correctiva se deben iniciar con el objetivo de reducir el costo global del
ciclo de vida.
Al seguir los pasos ilustrados en este ejemplo de un caso de estudio, el
proceso ilustrado en la figura 3.32 ha sido seguido. El planteamiento re-
comendado en este caso es seleccionar la alternativa "A".

A.2 NIVEL DE ANÁLISIS DE REPARACIÓN (EJEMPLO 2)

A.2.1 Definición del problema

En el diseño de los componentes del sistema, uno de los factores se relaciona


con la pregunta- ¿Debe ser diseñado el componente para ser "reparable"
o debe ser diseñado para ser "descartado" en caso de falla? Si es diseñado
para ser reparable, ¿a qué nivel de mantenimiento debe realizarse la
reparación? Aunque estas preguntas pueden aplicarse a algún componen-
te del sistema (por ejemplo, equipo, unidad, ensamble, módulo, y elemento
del software), este caso de estudio se aplica al diseño del ensamble "A-1".
Éste es uno de los 15 ensambles en la unidad "B" del sistema "XYZ".
El objetivo es evaluar las alternativas de diseño para el ensamble en base
a los criterios económicos.

A.2.2 Fi proceso de análisis

La realización de un análisis de reparación requiere que el ítem que debe ser


evaluado se presente en términos de un requerimiento operacional del
sistema, un concepto de mantenimiento y un plan de programa. En este
caso, se asume que el Sistema "XYZ" se instaló en un avión. Cuando se
requiere una actividad de mantenimiento, hay una incorporación de la
capacidad de prueba y el avión que permite a uno aislar la falta de la unidad
"A", unidad "B" o unidad "C". La unidad pertinente se elimina, se remplaza
con un excedente y el ítem defectuoso se transporta al almacén de mante-
NIVEL DE ANÁLISIS DE REPARACIÓN (EJEMPLO 2) 393

nimiento de nivel intermedio para mantenimiento correctivo. En el almacén


de mantenimiento, el aislamiento del defecto se realiza en al unidad a nivel
del ensamble. El ensamble defectuoso se remueve, se remplaza con un
repuesto, y la unidad es verificada afuera y regresada al inventario como
un repuesto operacional. ¿La pregunta básica pertenece a la disposición
del ensamble?
Al plantearse este problema, el primer paso es realizar un nivel de
análisis de reparación en el ensamble "A-1" como una entidad individual.
Posteriormente los resultados de esta parte del análisis necesitan ser
observados en el contexto del todo, es decir, los resultados de los análisis
similares que involucran el ensamble "A-2", "A-3", ..., y "A-15", y los ensam-
bles pertinentes de la Unidad "A" y la Unidad "C". Usualmente hay un efec-
to de retroalimentación entre el análisis individual del ensamble, el
análisis a nivel de la unidad, y el concepto de mantenimiento global para
el sistema en conjunto.
Al completar el nivel de análisis de reparación en el ensamble "A-!", se
proporciona la siguiente información:

1. El sistema "XYZ" se instala en cada uno de los 60 aviones que están


distribuidos igualmente en cinco lugares de operación por un período de
ocho años. La utilización del sistema en promedio es de 4 horas por día, y el
tiempo de operación total de todos los sistemas es de 452 600 horas.
2. Como se indicó arriba, el Sistema "XYZ" incluye tres unidades: la
unidad "A", la unidad "B", y la unidad "C". La unidad "B" incluye 15
ensambles, uno de los cuales es el ensamble "A-1". El costo estimado para
la creación del ensamble "A-1" (para incluir el costo de diseño y desarrollo
y el costo de producción), es $ 1,700 cada uno si el ensamble es diseñado
como reparable, y $1,600 cada uno si el ensamble debe ser diseñado para ser
descartado en caso de falla. El diseño para la capacidad de reparación
considera la incorporación de provisiones de diagnóstico, accesibilidad,
etiquetación interna, etc., que es apta para costar más en términos de costos
de diseño y producción.
3. El promedio de fallas estimado (o el promedio de mantenimiento
correctivo) del ensamble "A-!" es de 0.00045 fallas por hora de operación
del sistema. Cuando ocurren fallas la operación se realiza por un solo técni-
co que es asignado en tanto dura del tiempo de mantenimiento activo
distribuido. El ikt estimado es de tres horas. La tarifa de trabajo cargada
es de $20 por hora de trabajo para mantenimiento de nivel intermedio y $30
por hora de trabajo para mantenimiento a nivel almacén.
4. El suministro de soporte incluye tres categorías de costo: el costo
de ensambles de repuesto en el inventario, el costo de componentes de
repuesto que hacen posible la reparación de los ensambles defectuosos, y el
costo de administración del inventario y mantenimiento. Asuma que 5
ensambles de repuesto se requerirán el inventario cuando se realicen a nivel
394 APÉNDICE A: EJEMPLOS DE CASOS DE ESTUDIO

intermedio, y que 10 ensambles de repuesto se requerirán cuando el


mantenimiento se realice a nivel de almacén. Para los repuestos de compo-
nentes, asuma que el costo promedio de material consumido por la acción
de mantenimiento es de $50. El costo estimado de mantenimiento de
inventario se asume que es 20% del valor del inventario (la totalización
de los costos para ensambles y componentes de repuesto).
S. Cuando la reparación del ensamble se realiza, la prueba especial y el
equipo de soporte se requiere para el diagnóstico de la falla y verificación
del ensamble. El costo por prueba es de $12 000, e incluye el costo de
adquisición y el costo amortizado de mantenimiento. Este costo es aparte
del costo total que se atribuye al requerimiento de mantenimiento para el
ensamble "A-1", y hay 5 estaciones de prueba requeridas para el manteni-
miento a nivel intermedio.
6. Los costos de transportación y manejo son considerados como que
deben ser despreciables cuando el mantenimiento se realice a nivel inter-
medio. No obstante, el mantenimiento de ensamble realizado a nivel de
almacén involucrará una gran cantidad de transportación. Para el manteni-
miento de almacén, se asume $150 por 100 libras para el viaje de ida (in-
dependientemente de la distancia), ye! ensamble empacado pesa 20 libras.
7. La asignación del ensamble "A-U' relativo al costo de la facilidad del
mantenimiento se categoriza en términos de un costo fijo inicia!, y un costo
periódico de apoyo proporcional a los requerimientos de utilización de la
facilidad. El costo fijo es $1000 por instalación, y la distribución del costo
de uso se asume que es $ 1.00 por hora de labor de mantenimiento a nivel
intermedio y $ 1.50 por hora de labor directa a nivel de almacén.
8. Los datos técnicos y los requerimientos de mantenimiento de soft-
ware constituyen las instrucciones de mantenimiento que deben ser inclui-
das en los manuales técnicos para apoyar las actividades de reparación de
ensamble, y el reporte de fallas y los datos de mantenimiento que cubren
cada acción de mantenimiento en el área. Asuma que el costo para preparar
y distribuir las instrucciones de mantenimiento (y software computacional
de soporte) es de $1000, ye! costo para los datos de mantenimiento del área
es de $25 por acción de mantenimiento.
9. Habrá costos iniciales de entrenamiento formal asociados con el per-
sonal de mantenimiento al considerar la opción de reparación del ensam-
ble. Asuma que 30 por día de entrenamiento formal para el nivel intermedio
de mantenimiento (para los cinco lugares en total) y seis estudiantes por
día para el mantenimiento a nivel de almacén. El costo de entrenamiento
es de $150 por día por estudiante. El requerimiento del entrenamiento de
reposición como resultado del desgaste o renovación se considera, sin
importancia.
10. Como resultado del mantenimiento, habrá un requerimiento para
desecho y (o) reciclado de material. El costo de desecho asumido es de $20
por ensamble y $2 por componente.
NIVEL DE ANÁLISIS DE REPARACIÓN (EJEMPLO 2) 395

El objetivo es evaluar el ensamble "A-1" basándose en la información


proporcionada. ¿Debe ser diseñado el ensamble "A-I" para: 1) reparación en
el nivel intermedio de mantenimiento; 2) reparación a nivel de depósito de
mantenimiento o, 3) descartado por falla?

A.2.3 Los resultados del análisis

La figura A.10 presenta una hoja con los resultados de la evaluación del
ensamble "A-1". Basado en la información mostrada, se recomienda que el
ensamble sea reparado a nivel de depósito de mantenimiento.
Antes de tomar una decisión final, no obstante, uno debe revisar los
datos de la figura A.10 en términos de colaboradores de "alto costo" y las
sensibilidades de los diversos factores de entrada. Algunas de las suposicio-
nes iniciales pueden tener un gran efecto en los resultados de análisis y, tal
vez, deben ser intentados. También el administrador debe desear revisar la
fuente de los datos de predicción que cubren confiabilidad, mantenibilidad
y algunos de los factores de costos de entrada.
Dado que la decisión de la política de reparación para el ensamble
"A-1" se verifica en términos de su evaluación en un sentido "aislado", por
ejemplo, se ha tomado una decisión relativa a los resultados de los análisis
de la figura A.10), entonces es importante que esta decisión sea revisada en
contexto con otros ensambles del sistema "XYZ" y con el concepto de
mantenimiento. La figura A. 11 refleja los resultados a nivel individual de los
análisis de reparación realizados para cada uno de los ensambles más
importantes en la unidad "B". El mismo enfoque usado para el ensamble
"A-1" se usa para la evaluación de los ensambles "A-2" hasta "A-15".
Al referirse a la figura A.11, hay diversas opciones importantes: 1) se
adopta la política de reparación para cada ensamble (por ejemplo, una
política global "mixta"), y 2) se adopta una política global uniforme para
todos los ensambles basados en el costo total más bajo (por ejemplo,
reparación a nivel de almacén). Ambas opciones deben de ser revisadas en
términos de efectos de retroalimentación que ocurren, las consecuencias
del costo del ciclo de vida y los riesgos asociados.
La figura A.12 ilustra el proceso básico que se ha discutido aquí.
Haymuchos ítems candidatos que pueden ser evaluados en términos de
decisiones de reparación contra descarto. Bastante a menudo, tales decisio-
nes serán tomadas basándose en los criterios "no económicos". No puede
ser técnicamente posible reparar un ítem en el nivel intermedio. Los cri-
terios de seguridad y (o) la necesidad de una facilidad especializada de
reparación ordenan que la reparación debe realizarse a nivel de almacén.
Los aspectos patentados de un producto ordenan que un ítem debe ser
reparado en la facilidad del productor (por ejemplo, el depósito). El enfoque
usado en este ejemplo se ocupa de aquellos componentes donde es factible
8

U
a2

1 111 11 2

E 2

E E
1c
a
- -
E' E

-
h u
!
i•_ li fi I
2
1 r tU ? •
-
2. E •8 a E

2z o.
j E EE 2 U E

1 22
-

u ?? § 8 8

- 8 1

ii
2

1 11! 1
Hl• E
6 6 1 t E
1-
E - 2
E
-
2 2 E
- - • 2

396
ANÁLISIS DEL TRABAJO DE MANTENIMIENTO (EJEMPLO 3) 397

Política de reparación

Número de Reparación Reparación a Descarte


ensamble a nivel nivel de en caso Decisión
intermedio almacén de falla

A-1 $213300 $186566 $491790 Reparación-almacén


A-2 130 800 82622 75440 Descarte
A-3 215611 210420 3482452 Reparación-almacén
A-4 141 633 162912 238601 Reparación-intermedio
A-5 132319 98 122 121 112 Reparación-almacén
A-e 112 189 96 938 89226 Descarte
A-7 125611 142 206 157 982 Reparación-intermedia
A-8 99 812 131 413 145 662 Reparación-intermedia
A-9 128 460 79007 66080 Descarte
A-lo 167400 141788 314560 Reparación-almacén
A- 11 185850 142371 136740 Descarte
A-12 135611 122453 111 502 Descarte
A-13 105 667 113775 133492 Reparación-intermedia
A-14 111 523 89411 99223 Reparación-almacén
A-15 142119 120813 115723 Descarte
Política de costos 1 $2 147,905 $1 920808 1 $2679555 1 Reparación-almacén

Figura A.1 1. Resumen de las decisiones de nivel de reparación.

la evaluación económica. Al referirse a la figura, hay algunas decisiones que


inicialmente pueden ser "libres de ambigüedad", y hay otras decisiones en
las que se requiere un análisis más profundo.

A.3 ANÁLISIS DEL TRABAJO DE MANTENIMIENTO (EJEMPLO 3)

A.3.1 Definición del problema

La compañía "ABC" ha estado manufacturando el producto 12345 por pocos


años antes. ¡Los costos han sido más altos que lo anticipado y la competen-
cia internacional se ha incrementado! Como resultado, la administración de
la compañía ha decidido realizar una evaluación de la capacidad global
de producción, identificar los contribuyentes de "costo alto" a través de la
realización de un análisis del costo del ciclo de vida, e identificar las posibles
I
!
1

1
\

LJJ L_!JL E
t
-\ II o E
()

. 05
-1
l I•I

hil
ll
I

I
- L L_i

H
c-

1 L_

398
ANÁLISIS DEL TRABAJO DE MANTENIMIENTO (EJEMPLO 3) 399

áreas del problema donde se puede realizar una mejora. Un área para
posible mejora es la función de prueba de manufactura donde han ocurrido
fallas frecuentes durante la prueba del producto 12345. Para reducir los
costos de mantenimiento, es probable que uno pueda reducir el costo global
del producto y mejorar la posición competitiva de la compañía en el
mercado. Con el objetivo de identificar algo "especifico" un análisis del
trabajo de mantenimiento detallado de la función de prueba de la manufac-
tura se realiza. Las recomendaciones específicas para la mejora están
siendo solicitadas.

A.3.2 El proceso de análisis

En respuesta, un análisis detallado del trabajo de mantenimiento, se realiza


usando el formato incluido en el apéndice B de Blanchard, B.S., Logistics
Engineering and Management, 4 ed., Prentice-Hall, Englewood Cliffs, N.J.
El formato, adaptado para propósitos de esta evaluación, incluye los si-
guientes pasos generales:

1. Revisión de la información histórica cubriendo el desempeño de la


capacidad de prueba de manufactura indicó la falta frecuente de energía
durante la prueba final del producto 12345. A partir de esto, un "síntoma de
falla" típico se identificó, y se desarrolló un diagrama de flujo lógico con una
operación de ayuda como el mostrado en la figura A.13.
2. Las funciones "va/no va", identificadas en la figura A. 13, se convierten
al formato del análisis del trabajo de la figura A.14 y A.15. Las funciones
se analizan con base en los requerimientos que determinan los trabajos
(duraciones de los trabajos, relaciones en serie-paralelo, las secuencias,
la cantidad de personal y los requerimientos de nivel de adiestramiento, los
requerimientos de partes de repuesto-reparación, los requerimientos de
equipo de prueba y soporte, los requerimientos de datos técnicos, los
requerimientos de una facilidad especial, los requerimientos de datos
técnicos, etc. La figura A. 14 intenta distribuir los trabajos de mantenimiento
aplicables requeridos, determinar la frecuencia anticipada de ocurrencia,
e identificar los recursos de soporte logístico que probablemente son
necesarios para el desempeño de mantenimiento requerido. Esta informa-
ción puede a su vez ser evaluada con base en el costo.
3. Dados los resultados preliminares del análisis en términos de la
distribución de las funciones/trabajos de mantenimiento esperados, el
siguiente caso es evaluar la información presentada en al figura A.15,
y sugerir las posibles áreas donde se puede hacer una mejora.
PrueW

--+--
II
Fallas del slelema XYZ al
operar durante la prueba de
manufactura. Slrdorna: tala
total de corriente

01
Aísle la tafia a nivel de¡Ib
sis-
tema usando la cap
incoiporada de pruS

alIM
02 4'
Mote la falle a nivel de la
unidad'

4,
03
Remueva la unidad 8 defectuosa del
sistema y remplace con excedente

04
Transporte la Unidad 8
¡defectuosa a la tienda intermedia

05 06 07
Aplique contente a la
Unidad B. Verifique la Verifique la señal de Verifique que el 1 "a
Verifique otros
disponibilidad de la entrada del Ensamble ensamble es ensambles
señal de salida de A-V(2OVP-PO operacional
piezas que embonen. T.P.7)

11 No-va Y' No-va No-va


08 "Ir
Remueva el ensamble
defectuoso A-7y
remplácelo con un
excedente
09
Transporte el ensamble A-7
defectuoso al proveedor para
mantenimiento en el depósito.

10 11 12 13

que la condición
Operación de
verificación de
Verifique Verifique la
operación de
1 Verifique la
operación de
defectuosa CB 3A2 08 2A5 otros tableros

4
4,
de circuitos
FN No-va
14
No-va

Remueva y remplace
GB. lAS
la condición defectuosa Descarte CB
no es evidente
15
Verifique que el
ensamble es

Figura A,13. Diagrama de flujo para operación de ayuda, lógico abreviado,


400
1. Sistema
XYZ
2. ítem no rnbre/no. parle: Manulacluring
Tes1,14321
3. Sig. ensamble ato:
y
Ensamble prueba
4 Descripción del requerimiento: y
Durante la manutaclura pruebas del

y
producto 123.45 (No. serie 554), El slelema XI? talle aloperar El síntoma de falle
fue pérdida de la potencia lotar Requerimiento: Encontrar el problema reparar el
5 No q 6. Requerimiento 7 Frec Req 8 Nivel Mart Conf No
sistema.
Ql Dlagineparar 0.00460 Org,lnterno TA8100

10. Número 11. Descripción de tarea 12. Tiempo de enlace minutos 13 Ti~ 14. Eres, tarea rs. 16, 17. 18,
de tarea 22 24 26 28 btalerdace 9
- -
1

01 Aislar lalla a nÑet subsistema 1 5 0.00450 5 5


(Subsielema C defectuoso)
02 Alslar lata a nivel unidad ii••• ••••.•CI) 25 -25-25
-- ji i Iii @ 25 25
-- - --1 U
(Unidad Bdefectuosa) iii 1
03 Remover unidad B del sislemay )2dociele) 1 1 1 15 15 - - 15
mempta2ar con srlstiUo de Unidad 8
04 Transportar ta'ebaddet areparacún 1 U U U U U U 1 1 1 U 1 1 1 1 30 30 - - 30
05 Aplicar potencia a unidad con falta 1 1 • 1 (3erccto) - - 10= 20 - 20 - 20
Revisar La señal de saleta
U 1
It 1 U 15 - 15 - 15
06 Revisar señal de entrada a Ensamble A-1
(20eP-P O T.P_7)
07 Revisar señal de entrada a Ensamble A-7 NO 1 1 U 2cci.)
ciclo) M=~= 213 - 20 20
)orxia.PW -Smseg 0TP2)
08 RernovertallaA-7y reemplazar U 10 10 - 10
09 Transportar A-7detecluosa a proveedor 14 dlr' d- czW'rrlrrii sr tránsito
paramnantenirniento
y III -
10 RevIsar A-7 vent ar cond. de alía 1 1 (Sto ciclo • • 1 U 1 U 1 1 • 25
NI' 25 25
11 RevIsar operación de C8-3A2 --1.! . -- - - - 15 - _J J
12
13
Revisar operación deCB-2A4
Revisar operaclendeCB-1AS
H
i6locicie) U U
-- 10
20
-1010
- - 20 20
t. r - 40
'lmocdo) - ____
14 Romovery reemplazar C8-tA5defectuosa •i.0 40 40
Descartar tarjeta defectuosa
15 Verificar que el ensamble opera 11 Í - - - - - - - 15 - 15 15
y regresar a inventario
Total 1 265 1 0.00450 60 j) lit
o 290

Figura A14, Análisis de las tareas de mantenimiento (Parle 1).


ECV CV
o 2
.1

hDD

-
E

o-
2 E Cfl
-ID
CDL
U-) O
C.D
O LIC O O CV E Lfl UD O O O UD
CDL CDL - c CDL CCL O

o-

<<
u- o

i i -
oE O

O) 9
c cl? 9)0 00 O)
CO CV a)

t u

O E E
2 c

- -
E5 CX) O, LIC

.
--

- .
O

o-
XC CD- o
¿1) C.D CV
a -O CD- LIC CDL
o E EC
Cb
00

-- -------- --

00 0, 0' OCCL CDL UD

402
ANÁLISIS DEL TRABAJO DE MANTENIMIENTO (EJEMPLO 3) 403

A.3.3 Los resultados del análisis

La revisión de la información presentada en la figura A.14 yA. 15 sugiere que


las siguientes áreas sean tratadas a profundidad:

1.Con los recursos extensos requeridos para la reparación del ensam-


ble "A-7" (por ejemplo, la variedad de equipo especial de prueba y soporte,
la necesidad de una localidad de "cuarto estéril" para mantenimiento, la
extensa cantidad de tiempo requerido para eliminación y remplazo de
C13-1AS, etcétera), es posible identificar el ensamble "A-7" como irreparable!
En otras palabras, investigar la factibilidad de silos ensambles de la uni-
dad "B" deben ser clasificados como "reparables" o "descartados por falla".
2. Remítase a los trabajos 01 y 02, una capacidad de "prueba incorpora-
da" existe en el nivel organizacional para aislamiento del defecto en el
"subsistema". No obstante, el aislamiento de la falla de la "unidad" requiere
un probador especial del sistema (0-2310B), y toma 25 minutos de la prueba
más en individuos altamente adiestrados (adiestramiento de habilidades)
para realizar la función. En esencia, uno debe investigar la factibilidad de
extender la prueba incorporada bajo el nivel de la unidad y eliminar la
necesidad del probador especial del sistema y del individuo de nivel de alto
adiestramiento.
3. La eliminación física y el remplazo de la unidad "B", del sistema torna
15 minutos, que parecen bastante extensos. Aunque a un ítem importante
quizá no le podría ser conveniente investigar si el tiempo de eliminación/
remplazo puede ser reducido (a menos de 5 minutos por ejemplo).
4. Remítase a los trabajos 10-15, una localidad de un cuarto estéril
especial se requiere para mantenimiento. Asumiendo que los diversos
ensambles de la unidad "B" son reparados (contra que sean clasificados
como "descartados por falla"), entonces sería conveniente investigar
el cambio del diseño de esos ensambles de tal manera que un ambiente de
cuarto estéril no se requiera para mantenimiento. En otras palabras, ¿puede
el requerimiento de la localidad de mantenimiento extenso ser eliminado?
5. Hay un requerimiento aparente de un número de ítems de equipo
¡herramienta de prueba, es decir, el probador especial del sistema
(G-231013), el probador especial del sistema (1-8891011-A), el probador espe-
cial del sistema (1-8891011-13), el conjunto de pruebas C.B. (D-2252-A),
herramienta especial del extractor (EX201(003-4), y la herramienta especial
del extractor (EX45112-6). Usualmente, estos ítems especiales están limita-
dos a la aplicación general para otros sistemas, y se extienden para crear
y mantener. Inicialmente, uno debe investigar si pueden o no estos ítems ser
eliminados; si el equipo/herramientas se requieren, ¿pueden ser utilizados
los ítems estándar (en lugar de los ítems especiales)? También, si los
diversos probadores especiales se requieren, ¿pueden estar integrados en
un "solo" requerimiento? En otras palabras, ¿puede ser diseñado un solo
404 APÉNDICE A: EJEMPLOS DE CASOS DE ESTUDIO

ítem para remplazar los tres probadores especiales yel conjunto de pruebas
C.B? Reducir los requerimientos globales del equipo especial de prueba
y soporte es el objetivo más importante.
6. Remítase al trabajo 09 hay un contenedor especial del manejo para la
transportación ensamble "A-7". Esto puede representar un problema en
términos de la disponibilidad de un contendor en el tiempo y el lugar. Eso
sería preferible si los métodos normales de empaque y manejo pudieran se
utilizados.
7. Remítase al trabajo 14, la eliminación y remplazo de CB 1A5 toma 40
minutos y requiere un individuo de alto adiestramiento para realizar el
trabajo de mantenimiento. Asumiendo que el ensamble "A-7" es reparable,
podría se adecuado simplificar el procedimiento de eliminación/remplazo
del tablero de circuitos por medio de los componentes incorporados y dise-
ñados al circuito electrónico, o por último simplificar el trabajo para
permitir a alguien con un nivel de adiestramiento básico realizado.

A.4 EVALUACIÓN DE LAS ALTERNATIVAS (EJEMPLO 4)

A.4.1 Definición del problema

La compañía "DEF" es responsable del diseño y desarrollo de un sistema


importante que, a su vez, contiene un número de grandes subsistemas, el
subsistema XYZ debe ser conseguido a partir de un proveedor externo, y
hay tres configuraciones diferentes que deben ser evaluadas para selec-
ción. Cada una de las configuraciones representa un diseño existente, con
un rediseño necesario para que sea compatible con los requerimientos del
nuevo sistema. Los criterios de evaluación incluyen parámetros diferentes
tal como desempeño, capacidad de operación, efectividad, características
del diseño, plan y costo. Ambas configuraciones, la cualitativa y la cuantita-
tiva se cubre en el proceso de evaluación.

A4.2 El proceso de análisis

El analista comienza con el desarrollo de una lista de parámetros de


evaluación como se describió en la figura A.16. En este caso, no hay un solo
parámetro que sea adecuado por sí mismo, sino que hay 11 factores que
deben ser considerados en forma integrada. Dados los parámetros de
evaluación, el siguiente paso es determinar el nivel de importancia de cada
uno de ellos. Los factores de importancia cuantitativos de cero al 100 son
asignados a cada uno de los parámetros de acuerdo con el grado de impor-
tancia. El método Delphi, o alguna técnica de evaluación equivalente puede
emplearse para establecer los factores de importancia. la suma de todos los
factores de importancia es 100.
EVALUACIÓN DE LAS ALTERNATIVAS (EJEMPLO 4) 405

Configuración A Configuración B Configuración C


Factor de Tasa Puntua- Tasa Puntua- Tasa Puntua-
ftem Parámetro de evaluación ¡mportanci base ción Base ción base ción
(%)

1 Desempeño-entrada, salida,
exactitud, rango,
compatibilidad 14 6 84 9 126 3 42

2 Operabilidad-sencillez
facilidad de operación
y 4 10 40 7 28 4 16

3 Efectividad Ao, MTBM,


Mct Mp MDT, MMH-OH 12 5 60 8 96 7 84

4 Característica del diseño-


confiabilidad mantenibilidad,
factores humanos, capacidad
de soporte, capacidad de
producción capacidad
de intercambio 9 8 72 6 54 3 27

5 Datos del diseño-dibujos del


diseño, especificaciones, datos
logísticos, procedimientos de
- y
operación mantenimiento 2 6 12 8 16 1 5 10

6 Ayudas de prueba-equipo de
y
prueba común estandar,
estándares de calibración,
y
mantenimiento diagnóstico
de programas computacionales 3 5 15 8 24 3 9

7 y
Localidades utiterías -espacio,
peso, volumen, ambiente,
corriente, calor, agua,
aire acondicionado 5 7 35 8 40 4 20

8 Partes de repuesto yde


y
reparación-tipo cantidad de
parte, partes estándar, tiempo
de consecución 6 9 54 7 42 5 30

9 Flexibilidad-potencial de
crecimiento- para reconfigura-
ción, capacidad de aceptar
cambios en el diseño 3 4 12 8 24 6 18

10 Programación-invesñgación
y desarrollo, producción 17 7 119 8 136 9 153

11 Costo-ciclo de vida
&
(inversión R D y, O & M) 25 10 250 9 225 5 125

Subtotal - 753 - 811 534

Factor de ajuste
(riesgo de desarrollo) 113 81 197
- 15% - 10% 20%
Gran total 100 640 730 427

Figura A.16. Resumen de evaluación (tres alternativas).


406 APÉNDICE A: EJEMPLOS DE CASOS DE ESTUDIO

Para cada uno de los 11 parámetros identificados en la figura A.16, el


analista puede querer desarrollar una lista de verificación especial que
incluya los criterios contra los cuales evaluar las configuraciones de árbol
propuestas. Por ejemplo, el parámetro "desempeño" puede describirse en
términos de grados de deseabilidad; es decir, "altamente deseable", "desea-
ble", o "menos deseable". Aunque cada configuración debe cumplir con un
conjunto mínimo de requerimientos, uno puede ser más deseable que el
siguiente cuando se observan las características propuestas de desempeño.
En otras palabras, ¡el analista debe separar cada parámetro de evaluación en
"niveles de bondad, calidad"!
Cada una de las tres configuraciones propuestas del subsistema "XYZ"
se evalúa independientemente usando los criterios de la lista de verificación
especial. Los valores básicos devaluación de cero a lOse aplican de acuerdo
con el grado de compatibilidad con las metas deseadas. Si una evaluación
"altamente deseable" se realiza, una valuación de 10 se asigna.
Los valores base de valuación se multiplican por los factores de impor-
tancia para obtener una puntuación. La puntuación total entonces se
determina añadiendo las puntuaciones individuales para cada configura-
ción. Ya que algún diseño se requieren en cada caso, un factor especial de
ajuste se aplica para cubrir el riesgo asociado con la falla para cumplir un
requerimiento dado. Los valores resultantes a partir de la valuación se re-
sumen en la figura A.16.

A.4.3 Los resultados del análisis

Al referirse a la figura A.16 la configuración "B" representa el enfoque


preferido basado en la puntuación total más alta de 730 puntos. Esta
configuración se recomienda con base en sus características inherentes
relacionadas con el desempeño, capacidad de operación, efectividad, ca-
racterísticas del diseño, datos del diseño, etcétera.
APÉNDICE B
LISTA DE REVISIÓN DEL DISEÑO

Periódicamente, durante el diseño del sistema y el proceso de desarrollo, es


adecuado realizar una revisión informal para 1) determinar si han sido
completados los trabajos necesarios en un programa dado para asegurar
los resultados globales óptimos y 2) valuar si las características adecuadas
han sido consideradas e incorporadas en la configuración del diseño del
sistema-producto. Las preguntas, presentadas en forma de una lista de
revisión, se han desarrollado para reflejar ciertas características. Los re-
querimientos a nivel del sistema y las consideraciones detalladas del diseño
se incluyen. No todas las preguntas son aplicables en todas las revisiones;
sin embargo, la respuesta a aquellas preguntas que son aplicables debe ser
"SÍ" a fin de reflejar los resultados deseables. Para algunas preguntas, puede
ser necesario seguir un estudio más profundo del tema por medio de la re-
visión de las referencias seleccionadas antes de llegar a una decisión. Estas
preguntas apoyan directamente la lista de verificación abreviada presenta-
da en la figura 5.4, capítulo S.

B. 1 REQUERIMIENTOS GENERALES

1.0 Análisis de factibilidad

1.1 ¿Se ha definido y justificado la "necesidad" que requiere el sistema-


producto?
1.2 ¿Ha sido justificado en el enfoque técnico del diseño para el sistema
mediante un análisis de factibilidad?
1.3 En la realización del análisis de factibilidad, ¿Se han considera-
do todas las aplicaciones adecuadas de la tecnología y se han
priorizado en el desarrollo de un enfoque técnico del diseño para el
sistema?
408 APÉNDICE B: LISTA DE REVISIÓN DEL DISEÑO

1.4 ¿Se han seleccionado las tecnologías existentes donde es factible,


en comparación a la selección de las tecnologías en el estado del
arte?
1.5 Al evaluar las aplicaciones alternativas de la tecnología ¿se han em-
pleado las consideraciones del costo del ciclo de vida?,Se han iden-
tificado los requerimientos peculiares de apoyo?
1.6 ¿Estarán disponibles las tecnologías a tiempo para cumplir los
requerimientos del plan del programa?
1.7 ¿Hay fuentes múltiples de suministros para cada una de las tecnolo-
gías seleccionadas para aplicación (por ejemplo más de un provee-
dor)?
1.8 ¿Se han definido las actividades de investigación y desarrollo para
las áreas donde existen deficiencias?
1.9 ¿Se han identificado las áreas de riesgo e incertidumbre?

2.0 Requerimientos operacionales

2.1 ¿Se ha definido la misión para el sistema (por ejemplo, las misiones
primaria y secundaria con escenarios o perfiles aplicables)?
2.2 ¿Se han definido los requerimientos de desempeño del sistema?
2.3 ¿Se han identificado y descrito las medidas de desempeño técnico
(TPMs) para el sistema-programa? ¿Son éstas medibles?
2.4 ¿Ha sido definido adecuadamente el ciclo de vida del sistema-
producto y las actividades más importantes de él, (por ejemplo, el
diseño y desarrollo, la producción y (o) construcción, la distribu-
ción, el uso operacional, el soporte de apoyo, el retiro y desecho)?
2.5 ¿Se ha definido el despliegue operacional planeado, con la distribu-
ción geográfica de los componentes del sistema (por ejemplo, los
requerimientos del cliente, la cantidad de ítems por ubicación del
"usuario", plan de distribución)?
2.6 ¿Se han definido los requerimientos de utilización del sistema? Éste
puede incluir horas proyectadas de operación de sistema, o canti-
dad de ciclos operacionales en un período dado de tiempo. Un esce-
nario operacional "dinámico" se desea.
2.7 ¿Se ha descrito adecuadamente el ambiente operacional proyecta-
do en términos de ciclos de temperatura y temperaturas extremas,
humedad, vibración e impacto, almacenamiento, transportación
y manejo?
REQUERIMIENTOS GENERALES 409

3.0 Concepto de mantenimiento

3.1 ¿Se han identificado y definido los niveles anticipados de manteni-


miento?
3.2 ¿Se han identificado las funciones básicas de mantenimiento para
cada nivel?
3.3 ¿Se han asignado las responsabilidades organizacionales para
el mantenimiento y soporte del sistema (por ejemplo, soporte del
"usuario", soporte del contratista, soporte del proveedor, manteni-
miento por parte de terceros)?
3.4 ¿Se han establecido las políticas de nivel de reparación (por ejem-
plo, reparar contra desechar)? ¿Se han definido adecuadamente los
criterios para las decisiones de nivel de reparación?
3.5 ¿Se han establecido los requerimientos para "estandarización"
(como esto se aplica a la capacidad de soporte global del sistema)?
3.6 ¿Se han establecido los criterios para cantidades de personal y (o)
adiestramientos en cada nivel de mantenimiento?
3.7 ¿Se han establecido los criterios para equipo de prueba y soporte a
nivel de mantenimiento?Equipo de prueba incorporado contra
externo? ¿Requerimientos de diagnóstico?
3.8 ¿Se han definido los requerimientos del software para la prueba del
sistema y (o) el componente? ¿Los requerimientos del lenguaje de
prueba?
3.9 ¿Se han establecido los criterios para las facilidades de manteni-
miento?
3.10 ¿Se han establecido los criterios para empaque, transportación
y manejo?
3.11 ¿Se han establecido los factores apropiados de efectividad para el
diseño de capacidad de soporte global (esto es, promedios de
demanda de partes de repuesto, las localidades del inventario, los
niveles, la disponibilidad y utilización del equipo de prueba, el
almacén de mantenimiento y el tiempo de proceso, la utilización de
la localidad, el tiempo de retorno, etcétera)?
3.12 ¿Se han definido los ambientes de mantenimiento y soporte en
términos de ciclo de temperatura y temperaturas extremas, hu-
medad, vibración e impacto, transportación y manejo, y alma-
cenamiento?
410 APÉNDICE B: LISTA DE REVISIÓN DEL DISEÑO

4.0 Factores de efectividad

4.1 ¿Se han definido las figuras de mérito (FOMs) adecuadas de efecti-
vidad del sistema y efectividad de costos para el sistema-producto
(esto es, disponibilidad, tendencia, capacidad, prontitud, costo del
ciclo de vida, costo del diseño?
4.2 ¿Se ha especificado la cantidad aplicable de los factores para
confiabilidad, mantenibilidad, factores humanos y capacidad de
soporte (por ejemplo, MTBM, MTBR, MTBF )Jpt, MDT, M ADT, LDT,
Mct Mpt, MMH-OH, Costo-OH, Costo-MA, TAT)?
4.3 ¿Son directamente rastreables los factores de efectividad que han
sido especificados ya sea para algunos de los requerimientos opera-
cionales del sistema (el escenario de la misión) o para concepto de
mantenimiento?
4.4 ¿Puede medirse cada uno de los factores de efectividad identifica-
dos para el sistema? ¿Se han incorporado las provisiones de prueba
y evaluación en el plan maestro de prueba y evaluación (TEMP) para
propósitos de verificación?
4.5 En caso de que dos o más medidas de efectividad sean aplicables,
¿Son las medidas pesadas adecuadamente para indicar el grado de
importancia o el nivel relativo de importancia?
4.6 ¿Están integrados adecuadamente todas las FOMs importantes de
efectividad a la evaluación TPM y a la capacidad de reporte?

5.0 Análisis funcional y distribución

5.1 ¿Se ha definido adecuadamente el sistema-producto en términos


funcionales utilizando el planteamiento de diagrama de bloque fun-
cional?
5.2 ¿Se han definido todas las funciones importantes operacionales del
sistema y las funciones de mantenimiento?
5.3 Evoluciona el análisis funcional directamente de los requerimien-
tos operacionales del sistema y el concepto de mantenimiento?
¿Son las funciones directamente rastreables para los requerimien-
tos de alto nivel del sistema (por ejemplo, el escenario de la misión)?
5.4 ¿Evolucionan directamente las funciones de mantenimiento de las
funciones operacionales?
REQUERIMIENTOS GENERALES 411

5.5 ¿Se presenta el análisis funcional con bastante detalle para permitir
el desarrollo adecuado del diagrama de bloque y de confiabilidad,
la FTA, FMECA, la predicción de la mantenibilidad, el análisis de
mantenimiento, el análisis detallado del trabajo del operador, los
diagramas de secuencias operacionales, el análisis de seguridad de
riesgo y el análisis de soporte logístico (LSA)?
5.6 ¿Se presenta el análisis funcional con suficiente detalle para el
desarrollo de la especificación del sistema?
5.7 ¿Se han distribuido los requerimientos adecuados a nivel del siste-
ma con la profundidad necesaria para la definición adecuada del
diseño (por ejemplo, a nivel del subsistema y abajo)? Esto puede
incluir la distribución de los requerimientos de confiabilidad, los
requerimientos de la mantenibilidad, los factores de la capacidad
de soporte y los parámetros de costo?
5.8 En la distribución de los factores del sistema al subsistema, a la uni-
dad y abajo, ¿son los parámetros rastreables de un nivel al siguien-
te? ¿Son significativos los parámetros en términos de que sean
buenas medidas para el nivel del sistema especificado?

6.0 Especificación del sistema

6.1 ¿Se ha desarrollado un árbol de especificación del programa-pro-


yecto (mostrando las especificaciones dirigentes presentadas de
manera jerárquica)?
6.2 ¿Se ha preparado una especificación del sistema (por ejemplo, la
especificación tipo "A")?
6.3 ¿Se han preparado el desarrollo apropiado, la consecuencia, el pro-
ceso las especificaciones de material (por ejemplo, los tipos "B",
"C», "I" y "E")?
6.4 ¿Incluye la especificación del sistema los requerimientos de opera-
ción, el concepto de mantenimiento, una definición funcional del
sistema, los requerimientos de efectividad (por ejemplo,
confiabilidad, mantenibilidad, factores humanos, seguridad, capa-
cidad de soporte, economía y factores de calidad)?
6.5 ¿Son compatibles las diversas especificaciones que son aplicables
a cada una de las otras especificaciones? ¿Se han eliminado los
requerimientos de especificación conflictivos? Si no, ¿se ha estable-
cido precedencia?
412 APÉNDICE B: LISTA DE REVISIÓN DEL DISEÑO

7.0 Requerimientos del proveedor

7.1 ¿Se han establecido los criterios y procedimientos para la identifi-


cación inicial con la evaluación y la selección de los proveedores de
componentes?
7.2 ¿Se han identificado todos los proveedores de componentes? ¿Se ha
realizado una evaluación en sitio para cada proveedor potencial?
7.3 ¿Se han preparado las especificaciones del proveedor y se han
aplicado adecuadamente por medio de los acuerdos contractuales
adecuados?
7.4 ¿Se han preparado e implementado los planes individuales del
programa del proveedor?
7.5 ¿Son compatibles los datos del diseño y la documentación con los
requerimientos para el programa global?
7.6 ¿Se han impuesto los procedimientos de administración de la confi-
guración apropiados en las actividades de diseño y desarrollo?
7.7 ¿Se han establecido los procedimientos de control de calidad ade-
cuados para el monitoreo y en control de las actividades del pro-
veedor? ¿Se ha implementado un sistema devaluación del provee-
dor?

8.0 Plan de administración de la ingeniería de sistemas (SEMP)

8.1 ¿Se ha desarrollado un plan de administración de la ingeniería de


sistemas (SEMP)?
8.2 ¿Trata el SEMP el ciclo de vida global y sus fases-actividades?
8.3 ¿Describe adecuadamente el plan el proceso de ingeniería?
8.4 ¿Lleva el plan a la integración adecuada de las diferentes especiali-
dades de la ingeniería involucradas en el proceso del diseño del
sistema-producto?
8.5 ¿Se integra adecuadamente el SEMP a los planes tales como el plan
de programa de confiabilidad, plan del programa de la mantenibilidad,
el plan del programa de factores humanos, el plan de la ingeniería de
seguridad, el plan ILS, el plan de análisis de soporte logístico, el plan
de administración de la configuración, el plan maestro de prueba
y evaluación (TEMP), etcétera?
8.6 ¿Han sido documentados adecuadamente los estudios de compro--
CARACTERÍSTICAS DEL DISEÑO 413

misos importantes del sistemay están apropiadamente referenciados


en el SEMP?
8.7 ¿Apoya adecuadamente el SEMP a la especificación del sistema?
8.8 ¿Están incluidos los trabajos del programa, la estructura
organizacional y las responsabilidades, la WBS, los planes, las
proyecciones de costos y las funciones de monitoreo y control?
8.9 ¿Se ha incluido el plan de desarrollo de personal y un plan de
entrenamiento organizacional?
8.10 ¿Se han cubierto los requerimientos del programa del proveedor?
8.11 ¿Se han cubierto las revisiones formales del diseño? ¿Se ha descrito
y habilitado una evaluación formal y el procedimiento de acción
correctiva?
Las preguntas adicionales pertenecientes al SEMP se incluyen en el
capítulo 6, sección 6.6.

B.2 CARACTERÍSTICAS DEL DISEÑO

1.0 Accesibilidad

1.1 ¿Son directamente accesibles los componentes del sistema para el


desempeño de los trabajos del operador y de mantenimiento?
1.2 ¿Se logra fácilmente el acceso?
1.3 ¿Son compatibles los requerimientos de acceso con la frecuencia de
mantenimiento (o lo crítico de la necesidad)? Debe ser más gran-
de la accesibilidad para los ítems que requieren mantenimiento
frecuente que para aquellos ítems que requieren mantenimiento
no tan frecuente.
1.4 ¿Se proveen las puertas de acceso donde es adecuado? ¿Se utilizan
las puertas de bisagra?Pueden ser soportadas las puertas de
acceso que tienen bisagra en !a posición abierta?
1.5 ¿Son adecuados los accesos abiertos en cuanto a tamaño y están
localizados óptimamente para el acceso requerido?
1.6 ¿Están minimizados los cerrojos?
1.7 ¿Son los cerrojos de las puertas de acceso de la variedad de libe-
ración-rápida?
1.8 ¿Puede lograrse el acceso sin el uso de herramientas?
414 APÉNDICE B: LISTA DE REVISIÓN DEL DISEÑO

1.9 Si se requieren herramientas para lograr el acceso, ¿Se mantiene el


número de herramientas al mínimo? ¿Son las herramientas de la
variedad estándar?
1.10 ¿Son las provisiones de acceso entre los módulos y los compo-
nentes adecuados?
1.11 ¿Están las puertas de acceso y aberturas etiquetadas en términos
de los ítems que son accesibles desde ella?

2.0 Ajuste y alineación

2.1 ¿Han sido minimizados los requerimientos de ajuste-alineación, si


no eliminados?
2.2 ¿Se conocen los requerimientos de ajuste de las frecuencias donde
es aplicable?
2.3 ¿Son accesibles los puntos de ajuste?
2.4 ¿Son compatibles los lugares de punto de ajuste con el nivel de
mantenimiento al que se hace el ajuste?
2.5 ¿Se han eliminado los efectos de interacción del ajuste-alineación?
2.6 ¿Están especificados los ajustes de la fábrica?
2.7 ¿Están adecuadamente etiquetados los puntos de ajuste?
2.8 ¿Pueden hacerse los ajustes-alineaciones sin el requerimiento de
herramientas especiales?

3.0 Cables y conductores

3.1 ¿Se fabrican los cables en secciones removibles?


3.2 ¿Están ruteados los cables para evitar ángulos cerrados?
3.3 ¿Están ruteados los cables para evitar pellizcos?
3.4 ¿Está etiquetado adecuadamente el cable?
3.5 ¿Es adecuada la abrazadera del cable?
3.6 ¿Se usan los conectores de la variedad desconecte-rápido?
3.7 ¿Están lo suficientemente aparte los conectores que están monta-
dos en las superficies de tal manera que puedan ser firmemente
asidos para conectar y desconectar?
3.8 ¿Están etiquetados los conectores y los contactos?
CARACTERÍSTICAS DEL DISEÑO 415

3.9 ¿Están asegurados, los conectores y los contactos?


3.10 ¿Están estandarizados los conectores?
3.11 ¿Los conectores incorporan las provisiones para la prevención de
humedad?

4.0 Calibración

4.1 ¿Han sido minimizados los requerimientos de calibración si no eli-


minados?
4.2 ¿Se conocen los requerimientos de calibración donde es aplicable?
4.3 ¿Se conocen las frecuencias y tolerancias de calibración?
4.4 ¿Se han identificado las localidades para calibración?
4.5 ¿Están disponibles los estándares necesarios para calibración?
4.6 ¿Se han preparado los procedimientos de calibración?
4.7 ¿Es posible la capacidad de acudir al National Institute of Standards
and Technology (NISY)?
4.8 ¿Son compatibles los conceptos de calibración con el concepto de
mantenimiento y el análisis de soporte logístico (LSA)?

5.0 Requerimientos de datos

5.1 ¿Se ha definido adecuadamente el diseño a través de buenos datos


y documentación (por ejemplo, distribuciones, dibujos, diagramas
funcionales y materiales y lista de partes)?
5.2 ¿Se han cubierto adecuadamente los componentes del sistema a
través de buenos datos del diseño actualizados?
5.3 ¿Han sido adecuadamente registrados los resultados de los estu-
dios de compromisos importantes del diseño por medio de una
buena documentación?
5.4 ¿Se han definido los requerimientos para cada programa aplicable?
5.5 ¿Se han definido e integrado adecuadamente todos los requerimien-
tos de datos del proveedor a los requerimientos globales de datos
para el programa?
5.6 ¿Se han desarrollado y descrito los procedimientos para la recopi-
lación de datos, distribución y procesamiento?
416 APÉNDICE B: LISTA DE REVISIÓN DEL DISEÑO

5.7 ¿Se emplea una estandarización, donde es apropiado, al dar formato


a los datos, en el procesamiento y en el reporte?
5.8 ¿Son controlados adecuadamente los datos de acuerdo con los
procedimientos de administración de la configuración aprobados?

6.0 Desechabilldad

6.1 Ha sido diseñado el equipo para desechabilidad (por ejemplo,


selección de materiales, empaque)?
6.2 ¿Han sido preparados los procedimientos para cubrir el desecho
del componente del sistema-equipo?
6.3 ¿Pueden ser reciclados, para uso en otros productos, los compo-
nentes o materiales usados en el diseño del sistema-equipo?
6.4 ¿Si el reciclado del componente-material no es factible, puede
realizarse la descomposición?
6.5 ¿Puede realizarse el reciclado y (o) la descomposición usando los
recursos existentes del soporte logístico?
6.6 Son consistentes los métodos y los resultados del reciclado
y (o) descomposición con los requerimientos ambientales,
ecológicos, de seguridad, políticos y sociales?
6.7 ¿Es económicamente factible el método(s) usado para reciclaje
y (o) descomposición?

7.0 Requerimientos ecológicos

7.1 ¿Se ha concluido el estudio del efecto ambiental (para determinar si


el sistema tendrá un efecto adverso en el ambiente)?
7.2 ¿Están asociados los estándares requeridos con la calidad de aire,
la calidad de agua, el nivel(es) de ruido, el procesamiento de
desperdicio sólido, etcétera, que se mantienen pese a la introduc-
ción, operación y soporte de apoyo del sistema-producto?
7.3 ¿Se han identificados los efectos ecológicos potencialmente degra-
dantes? Es necesario tomar acción correctiva para eliminar los
problemas en esta área?
7.4 ¿Han sido descritos los métodos-procedimientos de manejo de
transportación para el procesamiento de desperdicio sólido?
CARACTERÍSTICAS DEL DISEÑO 417

8.0 Factibilidad económica

8.1 ¿Ha sido justificado el sistema-producto en términos de ingresos


y costos totales del ciclo de vida?
8.2 ¿Están considerados todos los elementos de costo?
8.3 ¿Están definidas adecuadamente todas las categorías de costo?
8.4 ¿Son relevantes las estimaciones de costo?
8.5 ¿Son variables e identificables por separado los costos fijos?
8.6 ¿Se especifican los factores de escalación y se emplean donde es
aplicable?
8.7 ¿Se especifican las curvas de aprendizaje y se emplean donde es
aplicable?
8.8 ¿Es económicamente factible el proyecto, considerando todas las
alternativas posibles?

9.0 Requerimientos ambientales

9.1 ¿El diseño del sistema-producto ha considerado todas las fases


posibles de actividad desde el punto de vista ambiental, por ejem-
plo, requerimiento ambiental durante el sistema y la operación-
utilización de manejo, transportación, almacenamiento y manteni-
miento?
9.2 ¿El diseño del sistema-producto ha considerad o lo siguiente: tem-
peratura, humedad, vibración, impacto, presión, aire, rocío de sal,
arena y polvo? ¿Se han especificado la extensión y las condiciones
extremas en el diseño? ¿Se han tratado los perfiles ambientales
adecuados?
9.3 ¿Es compatible el diseño con los estándares de aire y agua?
9.4 ¿Se han hecho los preparativos para especificar y controlar el ruido,
la iluminación, la temperatura y la humedad en áreas donde se
requiere personal para realizar los trabajos de operación y mante-
nimiento?

10.0 Requerimientos de facilidades

10.1 ¿Se han definido los requerimientos de facilidades necesarios (espa-


cio, volumen, equipo capital, utilerías, etc.) para la operación del
sistema?
418 APÉNDICE B: LISTA DE REVISIÓN DEL DISEÑO

10.2 ¿Se han definido los requerimientos de calidad (espacio, volumen,


equipo capital, utilerias, etc.) para el mantenimiento del sistema
en cada nivel)?
10.3 ¿Se han minimizado los requerimientos de facilidad operacional
de mantenimiento a la máxima extensión posible?
10.4 ¿Se han identificado los requerimientos ambientales del sistema
(por ejemplo, temperatura, humedad y control del polvo) asocia-
dos con las facilidades operacionales y de mantenimiento?
10.5 ¿Se han definido los requerimientos de almacenamiento o espacio
para las partes de repuesto-reparación?
10.6 ¿Se han definido los ambientes de almacenamiento?
10.7 ¿Son compatibles los requerimientos designados de facilidad y al-
macenamiento con el análisis de soporte logístico y los datos de
factores humanos?

11.0 Sujetadores

11.1 ¿Son usados los sujetadores deliberación rápida en puertas ypá-


neles de acceso?
11.2 ¿Está minimizado el número total de sujetadores?
11.3 ¿Se mantiene al mínimo el número de diferentes tipos de sujetado-
res? Esto se relaciona a la estandarización.
11.4 ¿Se han seleccionado los sujetadores basándose en los requeri-
mientos para herramientas estándar antes que para herramientas
especiales?

12.0 Manejo

12.1 Para ítems pesados, ¿se incorporan provisiones de grúas de arras-


tre (celdas fotosensibles de ascensor) o de accesorios base para
aplicación de grúas?Las grúas de arrastre deben proveerse en
todos los items que pesen más 150 libras?
12.2 ¿Están identificados los puntos de grúas y ascensores base en
relación a la capacidad de levantamiento?
12.3 ¿Se proporcionan las etiquetas de peso?
12.4 ¿Están provistos con asas los paquetes, unidades, componentes
u otros ítems que pesan arriba de 10 libras? ¿Se usan las asas de
CARACTERÍSTICAS DEL DISEÑO 419

tamaño adecuado y están colocadas en la posición correcta?


(Están localizadas óptimamente las asas desde el punto de vista
de la distribución del peso? Las asas deben localizarse en el cen-
tro de gravedad.
12.5 ¿Están provistos con dos asas los paquetes, las unidades u otros
ítems que pesan más de 40 libras (para una capacidad de acarreo
a dos manos)?
12.6 ¿Pueden usarse los materiales de empaque para transportación?
De no ser así, ¿se porpocionan contenedores especiales, cajas,
cubiertas para proteger las áreas del componente vulnerables al
daño durante el manejo?

13.0 Factores humanos

13.1 ¿Se ha realizado el análisis del sistema para identificarlas interfaces


óptimas humano-máquina? ¿Están adecuadamente definidas las
funciones automatizadas y manuables?
13.2 ¿Son consistentes las funciones identificadas automatizadas-ma-
nuales con los resultados de análisis funcional global del nivel del
sistema?
13.3 ¿Se han preparado los diagramas de frecuencia operacional (OSDs)
donde es apropiado?
13.4 ¿Se ha realizado un análisis detallado de trabajo del operador para
verificar la secuencia del trabajo, la complejidad del trabajo, el
adiestramiento del personal, etcétera?
13.5 ¿Se ha realizado un análisis detallado de trabajo del mantenimiento
para verificar la secuencia del trabajo, la complejidad del trabajo,
el adiestramiento del personal, etcétera?
13.6 ¿Es compatible el análisis detallado del trabajo de mantenimiento
con los datos de confiabilidad, con los datos de la capacidad de
mantenimiento y con los datos de análisis de soporte logístico
(ISA)?
13.7 ¿Son compatibles los análisis detallados del trabajo del operador
y de mantenimiento, con los procedimientos de operación y man-
tenimiento del sistema-producto (por ejemplo, las secuencias
del trabajo, la profundidad del material explicativo basado en la
complejidad del trabajo)?
420 APÉNDICE B: LISTA DE REVISIÓN DEL DISEÑO

13.8 Para las funciones humano-interfaz, ¿es óptimo el diseño del sis-
tema-producto cuando se consideran los factores antropométricos,
los factores de los sentidos humanos, los factores sicológicos y los
factores fisiológicos? Para los trabajos manuales, ¿refleja el diseño
la "facilidad de operación" por el personal de bajo adiestramiento?
¿Es tal el diseño que las tasas de error humano potencial se
minimizan?
13.9 ¿Se ha preparado un plan detallado de entrenamiento para el
personal operador y de mantenimiento? ¿Se han identificado los
requerimientos de facilidad de entrenamiento, equipo, material,
software y datos?
13.10 ¿Es compatible el esfuerzo de los factores humanos con los reque-
rimientos de la ingeniería de seguridad?
13.11 ¿Se ha establecido un enfoque para la prueba y evaluación del
personal?

14. 0 Intercamblablildad

14.1 ¿Son intercambiables el equipo, los módulos y (o) los componen-


tes que realizan operaciones eléctrica, funcional y físicamente si-
milares?
14.2 ¿Pueden hacerse el remplazo de ítems parecidos sin necesidad de
ajuste o alineación?

15.0 Mantenlblildad

15.1 ¿Es mantenible el sistema-producto en términos de problemas


y provisiones de diagnóstico, accesibilidad, fácil remplazo, capa-
cidad de manejo, exactitud de la prueba y verificación y en térmi-
nos económicos en el desempeño del mantenimiento (correctivo
y preventivo)? Realmente, muchos otros ítems de esta lista de veri-
ficación pueden incluirse apropiadamente bajo la mantenibilidad
dependiendo de la organización involucrada en el diseño.
15.2 ¿Se han definido adecuadamente los requerimientos del sistema-
equipo? ¿Son compatibles con el desempeño con la confiabilidad,
con la capacidad de soporte y los factores de efectividad del
sistema?
15.3 ¿Se han distribuido los requerimientos de la mantenibilidad en el
nivel apropiado (por ejemplo, MTBM, MDT, MMH-OH, Mct, M7pt,
CARACTERÍSTICAS DEL DISEÑO 421

$-MA al ensamble de la unidad, al subensamble y (o) a los demás


componentes apropiados del sistema)?
15.4 ¿Se han identificado los requerimientos de mantenimiento
correctivo y preventivo del sistema-producto por medio de un
análisis detallado de ingeniería de mantenimiento? ¿Se han condu-
cido los estudios de compromisos adecuados para alcanzar el
balance adecuado entre mantenimiento correctivo y preventivo?
También mucho mantenimiento preventivo puede ser costoso
y puede afectar significativamente los requerimientos del correc-
to mantenimiento. ¿Son compatibles los resultados con los datos
del análisis de soporte logístico (LSA)?
15.5 ¿Se ha concluido un nivel de análisis de reparación (LORA)? ¿Son
consistentes los resultados con el concepto de mantenimiento y el
análisis de soporte logístico (LSA)?
15.6 ¿Se han realizado las predicciones de la mantenibilidad para va-
luar el diseño en términos de los requerimientos especificados?
¿Indican las predicciones conformidad con los requerimientos?
15.7 ¿Se han conducido las demostraciones de la mantenibilidad?
¿Indican los resultados de conformidad con los requerimientos?
¿Se incluyen estos requerimientos en el plan maestro de prueba
y evaluación (TEMP)?

16.0 Movilidad

16.1 ¿Puede ser transportado fácilmente el equipo-componente? ¿Mo-


vido de un lugar a otro?
16.2 ¿Puede moverse el componente del sistema usando equipo de so-
porte-manejo común y estándar? El uso de equipo especial de
manejo debe evitarse.

17.0 Operabilldad

17.1 ¿Está diseñado el sistema para una fácil operación?


17.2 ¿Puede operarse el sistema efectivamente por los individuos que
tienen adiestramiento básico y que tienen un mínimo de entrena-
miento especial?
17.3 ¿Puede realizarse la operación del sistema con un mínimo de
error?
422 APÉNDICE B: LISTA DE REVISIÓN DEL DISEÑO

18.0 Empaque y montaje

18.1 ¿Es el diseño del empaque atractivo desde el punto de vista de los
sentidos del consumidor (por ejemplo, olor, forma, tamaño)?
18.2 ¿Se incorporó el empaque funcional a la máxima extensión posi-
ble? Deben minimizarse los efectos de interacción entre los empa-
ques. Debe ser posible limitar el mantenimiento para la elimina-
ción de un módulo (el que contiene la parte defectuosa) cuando
ocurre una falla y no se requiere la eliminación de dos, tres o cuatro
módulos a fin de resolver el problema.
18.3 ¿Es el diseño de empaque compatible con el nivel de decisiones de
análisis de reparación? Los ítems reparables se diseñan para in-
cluir provisiones de mantenimiento tales como puntos de prueba,
accesibilidad y componentes enchufables. Los ítems clasificados
como "descartados por falla" deben ser encapsulados y relativa-
mente bajos en cuanto a costo. Las provisiones de mantenimiento
en el módulo desechable no se requieren.
18.4 ¿Están incorporados los módulos desechables a la máxima exten-
sión práctica? Es altamente deseable reducir el soporte global
a través de un concepto de diseño sin mantenimiento mientras los
ítems que son descartados son relativamente altos en cuanto
a confiabilidad y bajos en cuanto a costos.
18.5 ¿Se utilizan los módulos y componentes enchufables a la máxi-
ma extensión posible (a menos que el uso de los componentes
enchufables degrade de manera significativa la confiabilidad del
equipo)?
18.6 ¿Son adecuados los accesos entre módulos para permitir el asi-
miento manual?
18.7 ¿Están montados los módulos y los componentes de tal mane-
ra que la eliminación de un solo ítem para mantenimiento no
requiera la eliminación de otros ítems? La aplicación de compo-
nentes debe evitarse cuando sea posible.
18.8 En áreas donde el apilamiento de módulos es necesario a causa del
espacio limitado, ¿están los módulos montados de tal manera
que la prioridad de acceso haya sido asignada de acuerdo con el
traslado pronosticado y la frecuencia de remplazo? Los ítems que
requieren frecuente mantenimiento deben ser más accesibles.
18.9 ¿Están montados los módulos y los componentes, no de lavarle-
dad enchufable, con cuatro sujetadores o menos? Los módulos de-
ben montarse de manera segura, pero el número de sujetadores
debe mantenerse al límite.
CARACTERÍSTICAS DEL DISEÑO 423

18.10 ¿Están incorporadas las provisiones de montaje-contacto donde


los requerimientos de impacto y vibración son accesibles?
18.11 ¿Están incorporadas las provisiones para evitar la instalación del
módulo erróneo?
18.12 ¿Son removibles los módulos y componentes enchufables sin el
uso de herramientas? Si se requieren herramientas deben ser de la
variedad estándar.
18.13 ¿Se proporcionan las guías (o seguros) para facilitar la instalación
del módulo?
18.14 ¿Están etiquetados los módulos y los componentes?
18.15 ¿Se localizan las etiquetas de los módulos y componentes en la
parte de arriba o inmediatamente adyacentes al ítem y completa-
mente a la vista?
18.16 ¿Están fijadas permanentemente las etiquetas y es poco probable
que se desprendan durante una acción de mantenimiento o como
resultado del ambiente? ¿Es adecuada la información de la etique-
ta? Los módulos desechables también deben etiquetarse. ¿En los
racks del equipo, están los ítems pesados montados hasta abajo
del rack? El peso de la unidad debe crecer con el incremento de la
altura de la instalación.
18.17 ¿Están óptimamente ubicados los páneles del operador? Para
el personal que está de pie, los páneles deben localizarse entre
40 y 70 pulgadas arriba del piso. El control crítico o preciso debe
ser entre 48 y 64 pulgadas sobre el piso. Para el personal en la
posición de sentado, los páneles deben localizarse 30 pulgadas
arriba del piso.
18.18 ¿Están montados los racks del equipo en torsetas deslizables?

19.0 Despliegue y control del pánel

19.1 ¿Está estandarizado el control?


19.2 ¿Está posicionado secuencialmente el control?
19.3 ¿Es adecuado el control de espaciamiento?
19.4 ¿Es adecuado el control de etiquetación?
19.5 ¿Se han incorporado las relaciones del control-despliegue adecua-
do (basándose en los buenos criterios de factores humanos)?
424 APÉNDICE B: LISTA DE REVISIÓN DEL DISEÑO

19.6 ¿Se usa el tipo adecuado de interruptores del pánel?


19.7 ¿Es adecuado el brillo del pánel de control?
19.8 ¿Se ha colocado el control de acuerdo ala frecuencia y(o) a lo crí-
tico del uso?

20.0 Personal y entrenamiento

20.1 ¿Se han definido los requerimientos del personal operacional de


mantenimiento (cantidad en niveles de adiestramiento)?
20.2 ¿Están minimizados en la máxima extensión posible los requeri-
mientos de personal operacional y de mantenimiento?
20.3 ¿Son compatibles los requerimientos de personal operacional y de
mantenimiento con el análisis de soporte logístico y con los datos
de factores humanos?La cantidad de personal y los niveles de
adiestramiento deben "seguir" ambas fuentes?
20.4 ¿Son compatibles los niveles planeados de adiestramiento del
personal en cada lugar con la complejidad de los trabajos
operacionales y de mantenimiento especificados?
20.5 ¿Se ha dado la consideración máxima al uso de adiestramientos de
personal existente para nuevo equipo?
20.6 ¿Se han establecido los promedios de agotamiento del personal?
20.7 ¿Se han determinado los factores de efectividad del personal
(tiempo real en que se realiza el trabajo por el tiempo total
permitido para la realización del trabajo)?
20.8 ¿Se han especificado los requerimientos de entrenamiento ope-
racional y de mantenimiento? Esto incluye tanto la configuración
del entrenamiento inicial como del entrenamiento de reposición
durante el ciclo de vida.
20.9 ¿Se han planeado los programas específicos de entrenamiento?
El tipo de entrenamiento, la frecuencia de entrenamiento, la du-
ración de entrenamiento y los requerimientos de ingreso de es-
tudiantes se debe identificar.
20.10 ¿Son compatibles los programas planeados de entrenamiento con
los requerimientos del nivel de adiestramiento de personal espe-
cificados para el desempeño de los trabajos operacionales y de
mantenimiento?
CARACTERÍSTICAS DEL DISEÑO 425

20.11 ¿Se han definido los requerimientos del equipo de entrenamiento?


¿Se han adquirido?
20.12 ¿Se han planeado las provisiones de mantenimiento para el equipo
de entrenamiento?
20.13 ¿Se han definido los requerimientos de datos de entrenamiento?
20.14 ¿Se utilizan los procedimientos de operación planeada yde man-
tenimiento (diseñados para apoyo del sistema durante su ciclo de
vida) a la máxima extensión posible en el programa(s) de entrena-
miento?

21.0 Capacidad de producción

21.1 ¿Permite el diseño su producción económica? ¿Pueden emplearse


la fabricación simplificada y las técnicas de ensamble?
21.2 ¿Se ha estabilizado el diseño (cambio mínimo)? Sino, ¿se controlan
los cambios adecuadamente por medio de los métodos de admi-
nistración de la configuración?
21.3 ¿Es tal el diseño que están minimizados los requerimientos de tra-
bajo? ¿Se mantienen al mínimo los factores de retrabajo?
21.4 ¿Se ha verificado el diseño a través de las pruebas de prototipos,
la calificación ambiental, la calificación de confiabilidad, la demos-
tración de la mantenibiliclad y casos similares?
21.5 ¿Es tal el diseño que muchos modelos del mismo ítem pueden
producirse con resultados idénticos? ¿Se controlan los casos de
fabricación, los procesos de manufactura y los métodos de ensam-
ble adecuadamente por medio de los procedimientos de buen
aseguramiento de la calidad?
21.6 ¿Se ha dado la consideración adecuada a la aplicación justo en el
tiempo (iii'), Taguchi, planeación de los requerimientos de mate-
rial (MRP) y los métodos correlacionados al proceso de produc-
ción?
21.7 ¿Son adecuados los dibujos de producción, los datos CAD-CAM-
CÁLS, las listas de material, etc., para las necesidades de produc-
ción?
21.8 ¿Pueden usarse las localidades disponibles actualmente, las herra-
mientas estándar y el personal existente para fabricación, ensam-
ble, manufactura y operaciones de prueba?
426 APÉNDICE B: LISTA DE REVISIÓN DEL DISEÑO

21.9 Es tal el diseño que los procesos automatizados de manufactura


(por ejemplo, el CAM, las técnicas de control numérico pueden ser
aplicados para las funciones repetitivas de alto volumen?
21.10 ¿Es tal la definición del diseño que dos o más proveedores pueden
producir el sistema-producto a partir de un conjunto dado de da-
tos con resultados idénticos?

22.0 Reconfigurabllldad

22.1 ¿Es tal la configuración del diseño que puede ser actualizada para
una capacidad mejorada?
22.2 ¿Se han configurado las mejoras pre-planeadas para el producto en
el diseño inicial del sistema?
22.3 ¿Pueden incorporarse las modificaciones para el aumento de
desempeño con un costo mínimo?

23.0 ConfiabIlidad

23.1 ¿Es simple el diseño? ¿Se ha mantenido al mínimo el número de


partes componentes?
23.2 ¿Se deben utilizar las partes estándar de alta confiabilidad?
23.3 ¿Se conocen los promedios de falla de un ítem? ¿Se ha determinado
el promedio de vida?
23.4 ¿Se han seleccionado las partes para cumplir los requerimientos
de confiabilidad?
23.5 ¿Se han identificado las partes con promedios excesivos de falla
(partes no confiables)?
23.6 ¿Se han establecido los factores adecuados para ajustes y se han
adherido a donde es adecuado?
23.7 ¿Se ha determinado la vida de los anaqueles así como las carac-
terísticas de desgaste de las partes?
23.8 ¿Se han eliminado los ítems de vida de uso crítico del diseño? Si no,
¿se han identificado con los requerimientos de inspección-reem-
plazo especificados? ¿Se ha realizado un análisis de vida de uso
crítico?
CARACTERÍSTICAS DEL DISEÑO 427

23.9 ¿Se han identificado las partes críticas que requieren métodos de
consecución especial, prueba y las provisiones de manejo?
23.10 ¿Se ha eliminado la necesidad de la selección de apareamiento de
partes?
23.11 ¿Se han incorporado las provisiones para automatizar equipos
hasta donde es posible (protección contra fallas secundarias que
resultan de las fallas primarias)?
23.12 ¿Se ha minimizado el uso de componentes "ajustables"?
23.13 ¿Se han usado los factores de seguridad y los márgenes de seguri-
dad en la aplicación de partes?
23.14 ¿Se han identificado los modelos de falta de componente y los
efectos? ¿Se han realizado un FMEA, a FMECAy un análisis de árbol
de falta (FrA)?
23.15 ¿Se ha realizado un análisis de tensión de energía?
23.16 ¿Se han incorporado las provisiones de enfriamiento en las áreas
"de lugares calientes"? ¿Se dirige el enfriamiento hacia los ítems
más críticos?
23.17 ¿Se ha incorporado redundancia en el diseño cuando es necesario
cumplir los requerimientos de confiabilidad especificados?
23.18 ¿Están los métodos mejor disponibles para predecir los objetos
adversos de los de ambientes operacionales y de mantenimiento
en los componentes críticos que están incorporados?
23.19 ¿Se han identificado y aceptado los riesgos asociados con las fallas
del ítem crítico? ¿Se debe tomar acción correctiva en el diseño?
23.20 ¿Se han considerado los requerimientos de confiabilidad para
partes excedentes y de reparación?
23.21 ¿Se han realizado las predicciones de conuiabilidad?Se han defini-
do los requerimientos de confiabilidad? ¿Los requerimientos de
prueba en el diseño? ¿Los requerimientos de prueba en produc-
ción-construcción? ¿Se han cubierto en un plan maestro de prueba
y evaluación (TEMP)?
23.22 ¿Se ha instalado un análisis de falla de confiabilidad y la capacidad
de acción correctiva?

24.0 Seguridad
24.1 ¿Se ha preparado e implementado un plan de ingeniería de la
seguridad integrada?
428 APÉNDICE 13: LISTA DE REVISIÓN DEL DISEÑO

24.2 ¿Se ha realizado un análisis de riesgo para identificar las condicio-


nes riesgosas potenciales? ¿Es compatible el análisis de riesgos
con la confiabilidad FMECA-FMEA (donde es aplicable)?
24.3 ¿Han sido eliminados los riesgos del calor, del frío, cambios ter-
males, cambios barométricos, cambio en la humedad, impacto,
vibración, luz, moho, bacterias, corrosión, roedores, hongos, olo-
res, químicos, aceites, grasas, manejo y transportación, etc., del
sistema-producto?
24.4 ¿Han sido incorporadas las provisiones de fallos seguros en el
diseño?
24.5 ¿Se han eliminado los aparatos sobresalientes o ellos están conve-
nientemente protegidos?
24.6 ¿Se han incorporado las provisiones para proteger contra alto
voltaje? ¿Están adecuadamente aterrizadas todas las partes exter-
nas de metal?
24.7 ¿Están protegidos todos los bordes puntiagudos de metal, los
accesos abiertos y las esquinas con goma, pasta, fibra o con una
cubierta de plástico?
24.8 ¿Se emplea la sincronización de circuitos eléctricos?
24.9 ¿Están las tarjetas provistas para proteger los componentes del
sistema de algún daño durante la realización de mantenimiento de
almacén?
24.10 ¿Están adecuadamente aisladas las herramientas que se usan
cerca de las áreas de alto voltaje en la asa o en otra parte de la
herramienta que el hombre de mantenimiento probablemente
debe tocar?
24.11 ¿Son los ambientes tales que la seguridad del personal está asegu-
rada? ¿Tienen los niveles de sonido un rango de inofensivo? ¿Está
limpio el aire? ¿Están las temperaturas a nivel adecuado? ¿Se de-
ben mantener los requerimientos OSHA?
24.12 ¿Se ha identificado la ropa protectora adecuada para las áreas
donde el ambiente podría ser perjudicial para la seguridad huma-
na? ¿Son ejemplos la radiación, frío o calor intenso, gas, ruido alto,
etcétera?
24.13 ¿Se identifican los requerimientos del equipo de seguridad en las
áreas donde los aparatos reglamentados (y los similares) se ac-
tivan?
CARACTERÍSTICAS DEL DISEÑO 429

25.0 Selección de partes-materiales

25.1 ¿Se han consultado los estándares adecuados para la selección de


componentes y materiales?
25.2 ¿Se han evaluado adecuadamente todas las partes componentes
y los materiales seleccionados para el diseño antes de su consecu-
ción y aplicación? ¿La evaluación debe considerar los parámetros
de desempeño, la confiabilidad, la mantenibiliclad, la capacidad de
soporte, los factores humanos, la calidad de costo?
25.3 ¿Se han establecido las fuentes del proveedor para la consecución
de parte-componente y material?
25.4 ¿Son confiables las fuentes del proveedor establecidas en térmi-
nos del nivel de calidad, la habilidad para entregar a tiempo y la
buena voluntad para aceptar las provisiones de garantía del com-
ponente?
25.5 ¿Se han identificado las fuentes alternativas del proveedor en el
caso de que falle la fuente primaria para entregar?

26.0 Servicio y lubricación

26.1 ¿Se han mantenido al mínimo los requerimientos de servicio?


26.2 Cuando se indica un servicio, ¿se identifican los requerimientos
específicos?
26.3 ¿Se conocen las fuentes de consecución para materiales de ser-
vicio?
26.4 ¿Son accesibles los puntos de servicio?
26.5 ¿Se han identificado los requerimientos de personal y equipo para
se -vicio? Esto incluye equipo de manejo, vehículos, carros, etcé-
tera.
26.6 ¿Incluye el diseño los indicadores de servicio?

27.0 Requerimientos sociales

27.1 ¿Satisface las necesidades sociales el sistema-producto?


27.2 ¿Han sido evaluados los efectos sociales a partir de la introducción
del sistema-producto en el inventario (para determinare! efecto de
operación del sistema y el soporte en la vida de la comunidad)?
430 APÉNDICE B: LISTA DE REVISIÓN DEL DISEÑO

27.3 ¿Se han minimizado, si no eliminado, todos los efectos usuales


adversos causados por la introducción, operación y soporte del
sistema-producto?

28.0 Software

28.1 ¿Se han identificado todos los requerimientos de software de


sistema para las funciones de operación y mantenimiento?Se han
desarrollado estos requerimientos a través del análisis funcional
a nivel del sistema (esto es, hay rastreabilidad indicada)?
28.2 ¿Está el software completo en términos de alcance y profundidad
de cobertura?
28.3 ¿Es compatible el software en relación al equipo con el cual tie-
ne interfaces? ¿Es compatible el software de operación con el
software de mantenimiento? ¿Con los demás elementos del sis-
tema?
28.4 ¿Son compatibles los requerimientos de lenguaje para el software
de operación y el software de mantenimiento?
28.5 ¿Se cubre adecuadamente todo el software por medio de buena
documentación (por ejemplo, flujos lógicos funcionales y progra-
mas codificados)?
28.6 ¿Se ha probado y verificado adecuadamente el software para
exactitud (desempeño), confiabilidad y mantenibilidaci?

29.0 Estandarización

29.1 ¿Están incorporados los componentes disponibles en almacén


y las partes estándares en el diseño a la máxima extensión posible
(excepto para ítems no compatibles con los factores de efectivi-
dad)? Se desea la máxima estandarización.
29.2 ¿Se usan los mismos ítems y (o) partes en las aplicaciones simila-
res?
29.3 ¿Se estandarizan las etiquetas de identificación de equipo y las
tareas de nomenclatura a la máxima extensión posible?
29.4 ¿Están las posiciones del pánel de control de equipo y las distribu-
ciones (de pánel a pánel) iguales o similares cuando un número de
páneles se incorpora y proporciona funciones comparables?
CARACTERÍSTICAS DEL DISEÑO 431

30.0 Almacenamiento

30.1 ¿Puede ser almacenado el equipo con períodos extendidos de tiem-


po sin la degradación excesiva (más allá de los límites de especi-
ficación)?
30.2 ¿Se han definido los requerimientos de mantenimiento planeado
para equipo almacenado?
30.3 ¿Se han eliminado los requerimientos de mantenimiento planeado
para equipo almacenado?
30.4 ¿Se han identificado las fuentes requeridas de mantenimiento ne-
cesarias para el equipo de servicio almacenado?
30.5 ¿Se han definido los ambientes de almacenamiento?

31.0 Capacidad de soporte

31.1 ¿Se han minimizado las partes de repuesto- reparación en la


máxima extensión posible? ¿Se minimiza el número de tipos de
parte diferente usados durante el diseño?
31.2 ¿Son compatibles los tipos y cantidad de partes de repuesto-re-
paración con el concepto de mantenimiento del sistema, el análisis
de soporte logístico (LSA) y el nivel de los datos del análisis de
reparación?
31.3 ¿Se designan los tipos ycantidad de partes de repuesto-reparación
para un lugar dado, apropiado para la demanda local estimada?
Tanto muchos como pocos excedentes pueden ser costosos.
31.4 ¿Se han establecido las vías de distribución y los puntos de
inventarios para las partes de repuesto-reparación?
31.5 ¿Son directamente rastreables los factores de abasto de partes de
repuesto-reparación (por ejemplo, frecuencia de remplazo) para
las predicciones de confiabilidad y mantenibilidad?
31.6 ¿Son compatibles los tiempos de línea de producción logísticos
especificados con el soporte de suministros? Los tiempos largos
de peso colocan una tremenda carga en el soporte logístico.
31.7 ¿Se han identificado y abastecido las partes de repuesto-repara-
ción para las actividades de soporte operacional (por ejemplo, el
soporte intermedio del productor o proveedor, los programas de
prueba)?
432 APÉNDICE B: LISTA DE REVISIÓN DEL DISEÑO

31.8 ¿Se han desarrollado los procedimientos de prueba y aceptación


para partes de repuesto-reparación? ¿Las partes de repuesto-
reparación se deben procesar, producir y aceptar en unas bases
similares con sus componentes equivalentes en el equipo pri-
mario?
31.9 ¿Se han definido las consecuencias (riesgos) de salida de stock en
términos de los requerimientos y costo de la misión?
31.10 ¿Se ha definido el nivel de reserva de seguridad del inventario?
31.11 ¿Se ha definido un ciclo de abastecimiento o consecución (o fre-
cuencia de orden)? ¿Se han determinado los factores EOQ?
31.12 ¿Se han establecido los requerimientos de disponibilidad del
proveedor (la probabilidad de que tenga disponible un excedente
cuando se requiere)?
31.13 ¿Se han definido los requerimientos de equipo de prueba y soporte
para cada nivel de mantenimiento?
31.14 ¿Se han seleccionado los ítems estándar de equipo de prueba
y soporte? El equipo diseñado recientemente no debe ser necesa-
rio a menos que el equipo estándar no esté disponible.
31.15 ¿Son compatibles los ítems seleccionados de equipo de prueba
y soporte con el equipo primario? ¿Hace el equipo de prueba el
trabajo?
31.16 ¿Son compatibles los requerimientos de equipo de pruebaysopor-
te con el concepto de mantenimiento, el análisis de soporte
logístico (LSA) y el nivel de los datos de análisis de reparación?
31.17 ¿Se han minimizado los requerimientos de prueba y soporte (am-
bos en términos de variedad y cantidad) a la máxima extensión
posible?
31.18 ¿Son compatibles las características de confiabilidad y mante-
nibilidad en el equipo de prueba y soporte con aquellas carac-
terísticas equivalentes en el equipo primario? No es práctico
seleccionar un ítem del equipo de soporte que no es tan confiable
como el ítem que soporta.
31.19 ¿Se han definido los requerimientos logísticos de soporte para
el equipo seleccionado de prueba y soporte? Esto incluye los tra-
bajos de soporte, el equipo de calibración, las partes de repuesto-
reparación, el personal y el entrenamiento, los datos y las locali-
dades.
31.20 ¿Se procesa la selección del equipo de prueba y soporte basándose
CA RACTERÍSTiCAS DEL DISEÑO 433

en las consideraciones de efectividad de costo (por ejemplo, costo


M ciclo de vida)?
31.22 ¿Se han definido los requerimientos de personal operacional y de
mantenimiento (cantidad y niveles de adiestramiento)?
31.23 ¿Se minimizan los requerimientos de personal operacional y de
mantenimiento a la máxima extensión posible?
31.24 ¿Son compatibles los requerimientos de personal operacional y de
mantenimiento con el análisis de soporte logístico (LSA) y con los
datos de factores humanos? La cantidad de personal ylos niveles
de adiestramiento deben seguir ambas fuentes.
31.25 ¿Son compatibles los niveles planeados de adiestramiento del
personal en cada lugar con la complejidad de los trabajos
operacionales y de mantenimiento especificados?
31.26 ¿Se ha dado máxima consideración al uso del personal adiestra-
do existente para el nuevo sistema?
31.27 ¿Se han establecido los promedios de agotamiento del personal?
31.28 ¿Se han determinado los factores de efectividad del personal
(tiempo real que se realiza el trabajo por el tiempo total permitido
para la realización del trabajo)?
31.29 ¿Se han especificado los requerimientos de entrenamiento
operacional? ¿Esto incluye tomar en consideración el entrena-
miento inicial y el entrenamiento de reposición durante el ciclo de
vida?
31.30 ¿Se han planeado los programas específicos de entrenamiento?
El tiempo de entrenamiento, la frecuencia de entrenamiento, la
duración del entrenamiento y los requerimientos de ingreso de
estudiantes se deben identificar.
31.31 ¿Son compatibles los programas planeados de entrenamiento con
los requerimientos del nivel de adiestramiento especificados para
la realización de los trabajos operacionales y de mantenimiento?
31.32 ¿Se han definido los requerimientos de equipo de entrenamiento?
¿Se han conseguido?
31.33 ¿Se han planeado las provisiones de mantenimiento para el equipo
de entrenamiento?
31.34 ¿Se han definido los requerimientos de los datos de entrena-
miento?
31.35 ¿Se utilizan los procedimientos planeados de operación y mante-
434 APÉNDICE B: LISTA DE REVISIÓN DEL DISEÑO

nimiento (diseñados para soporte del sistema durante su ciclo de


vida) a la máxima extensión posible de los programas de entrena-
miento?

32.0 Requerimientos del equipo de soporte

Véase las preguntas 31.15 hasta la 31.2 1, categoría 31-Capacidad de soporte,


para cubrir el equipo de prueba y soporte.

33.0 Sobrevlvencla

33.1 ¿Se ha preparado e implementado un plan integrado de ingeniería


de sobrevivencia?
33.2 ¿Se han establecido las medidas de sobrevivencia y están adecua-
damente integradas con los demás TPMs del sistema?
33.3 ¿Se ha definido un enfoque de prueba y evaluación para la verifica-
ción de la sobrevivencia del sistema? ¿Se cubre esto en el plan
maestro de prueba y evaluación (TEMP)?

34.0 Capacidad de prueba

34.1 ¿Se han incorporado las provisiones de autoprueba donde es apro-


piado?
34.2 ¿Se minimiza la degradación de la confiabilidad debida a la incor-
poración de pruebas incorporadas? La capacidad de BIT no debe
afectar significativamente la confiabilidad del sistema global.
34.3 ¿Es compatible la extensión o profundidad de la autoprueba con el
nivel de análisis de reparación?
34.4 ¿Son automáticas las provisiones de autoprueba?
34.5 ¿Se han provisto los indicadores directos de defecto (ya sea una
falta de luz, de señal de audio, o un medio para determinar que
existe realmente un mal funcionamiento)? ¿Están incorporadas las
provisiones de monitoreo continuo de la condición cuando es
apropiado?
34.6 ¿Están provistos los puntos de prueba para hacer posible la
verificación y el aislamiento de un defecto más allá del nivel de
autoprueba? Los puntos de prueba por aislamiento del defecto en
CARACTERÍSTICAS DEL DISEÑO 435

un ensamble no deben incorporarse si el ensamble debe descartar-


se por falla. ¿Las provisiones del punto de prueba deben ser com-
patibles con el nivel de análisis de reparación?
34.7 ¿Son accesibles los puntos? La accesibilidad debe ser compatible
con la extensión de mantenimiento desempeñado. Los puntos de
prueba en el pánel frente al operador no se requieren para una
actividad de mantenimiento específico.
34.8 ¿Están agrupados funcional y convencionalmente los puntos de
prueba para permitir la prueba secuencia¡ (siguiendo el flujo de
una señal), la prueba de funciones similares, ola frecuencia de uso
cuando se limita el acceso?
34.9 ¿Están provistos los puntos de prueba para una prueba directa de
todos los Items remplazables?
34.10 ¿Están adecuadamente etiquetados los puntos de prueba? Cada
punto de prueba debe ser identificado con un número único y la
señal adecuada o la salida medida esperada se debe especificar en
una etiqueta adyacente al punto de prueba?
34.11 ¿Están adecuadamente iluminados los puntos de prueba para
permitir ver al técnico el número de punto de prueba y el valor
etiquetado de la señal?
34.12 ¿Puede ser detectado cada mal funcionamiento del componente
que podría ocurrir (degradación más allá de los límites de toleran-
cia de la especificación) por medio de una indicación no-va a nivel
del sistema? ¿Se minimizan los promedios de falsa alarma? Esta es
una medida de prueba concienzuda?
34.13 ¿Proporcionará el software prescrito de mantenimiento la infor-
mación de diagnóstico adecuada?

35.0 Capacidad de transporte

35.1 ¿Se han definido los requerimientos de transportación y manejo?


35.2 ¿Se han considerado los requerimientos de transportación en el
diseño del equipo? Esto incluye la consideración de los rangos de
temperatura, la vibración y el impacto, la humedad, etc. ¿Se ha
minimizado la posibilidad de degradación del equipo si es trans-
portado por aire, vehículo terrestre, barco o ferrocarril?
35.3 ¿Puede el equipo ser fácilmente desensamblado, empaquetado,
transportado de un lugar a otro, reensamblado y operado con un
mínimo de desempeño y degradación de la confiabilidad?
436 APÉNDICE B: LISTA DE REVISIÓN DEL DISEÑO

35.4 ¿Se han definido los requerimientos de contenedores?


35.5 ¿Se han definido los requerimientos para el equipo de manejo
terrestre?
35.6 ¿Se basó la selección del equipo de manejo en las consideraciones
de efectividad de costos?

36.0 Calidad

36.1 ¿Se ha preparado e implementado una administración de la calidad


total (TQM)? ¿Incluye ésta la cobertura de las actividades e inter-
faces del cliente, del contratista (del productor) y del proveedor?
36.2 ¿Se deben conducir los programas de entrenamiento formal de la
calidad (esto es, TQM) en la organización del cliente-contratista-
proveedor)?
36.3 ¿Deben ser implementados los métodos-técnicas de control esta-
dístico del proceso (SPC) cuando es apropiado?
36.4 ¿Se especifican e imponen los requerimientos del control de la
calidad a todos los proveedores?

Las preguntas precedentes son representativas de lo que se puede con-


siderar al conducir una revisión de un programa-diseño. Esto no debe su-
gerir que se está incluyendo todo. De hecho, es apropiado para revisar
y diseñar su propia lista que cubre los asuntos aplicables "adaptados" al
programa en cuestión.
APÉNDICE C
GLOSARIO DE LOS TÉRMINOS
SELECCIONADOS

A lo largo de este texto, hay numerosos términos y definiciones que son


importantes para el entendimiento de la ingeniería de sistemas y sus
objetivos. Como muchos de éstos están bastante bien explicados en el
contexto del material de texto (mediante una referencia recomendada), no
se intenta ser repetitivo aquí. No obstante, con el interés de proporcionar un
resumen final del material, se han elegido unos cuantos términos conside-
rados como "clave" para los conceptos descritos. Mediante de una rápida
revisión de éstos, el lector podrá adquirir una opinión de aquellos conside-
rados como importantes en lo relativo a adquirir un entendimiento a fondo
del tema.

1. Foceso de creación. El proceso de crear un sistema desde el principio.


Esto incluye Ja fase del diseño conceptual y el avance de la planeación, el
diseño preliminar del sistema (demostración y validación), el diseño de
detalle y desarrollo (la escala de desarrollo completo) y la producción y (o)
construcción. Dada una necesidad definida, el proceso incluye aquellos
pasos que llevan desde la etapa de definición de los requerimientos a la
liberación del sistema para uso del consumidor. Véase la sección 1.1.3.
2.Asignación. La asignación de arriba-abajo, o separación, de los reque-
rimientos del nivel del sistema al subsistema, el equipo, el software, la
unidad, o abajo, con la profundidad necesaria para proporcionar los crite-
rios como una entrada al diseño. Este proceso tiende a fomentar un
"planteamiento de los sistemas" de arriba-abajo para ayudar a establecer
los requerimientos específicos del diseño para todos los niveles de la
jerarquía del sistema como es apropiado. Véase la sección 2.6.
3. Creación y soporte logístico asistido por computadora (C4LS). La apli-
cación de la tecnología computarizada del software computacional
disponible para el espectro entero de la logística. Éste incluye el uso de
métodos-herramientas computacionales en el diseño para la capacidad
438 ADMINISTRACIÓN DE INGENIERÍA DE SISTEMAS

de soporte del sistema (integrados en las actividades CASE-CAE-CAD), en


el desarrollo de los datos de análisis de soporte logístico para determinar
los requerimientos de recursos logísticos en el abasto y creación de los
elementos identificados del soporte (por ejemplo, partes de repuesto-
reparación, equipo de prueba y soporte) y la valoración de la capacidad de
soporte del sistema en el ambiente del usuario. El CALS también incluye el
desarrollo automático de los manuales técnicos y procesamiento de los
datos del diseño usando un formato digital de datos. Véase la sección 4.5.
4. Diseño asistido por computadora (CAD). El proceso de utilizar las
capacidades computacionales y el software disponible para apoyar las
actividades de diseño de la ingeniería. El CAD tiende a ocuparse esencial-
mente de las gráficas tridimensionales, las distribuciones del tablero de
circuitos, la realización de las diversas categorías de análisis y lo similar.
5.Ingeniería asistida por computadora (CAE). El proceso de utilizar las
capacidades computacionales ye! software para las actividades del diseño
de la ingeniería. El CAE tiende a ocuparse esencialmente de los análisis de
la ingeniería y la actividad de diseño en el nivel más bajo, similar a las
funciones del CAD.
6.Manufactura asistida por la computadora (CAM). El proceso de utilizar
las capacidades computacionales, el software disponible, el equipo de control
numérico, la robótica y los recursos relacionados para manufactura y pro-
ducir productos través de medios automatizados. ElCAMtiende a ocuparse
de la planeación del proceso de producción, el manejo de materiales, la
manufactura, el control de inventario y la administración de la producción.
7.Manufactura asistida por computadora (CASE). El proceso de integrar
los conceptos y construcciónes de la ingeniería de sistemas, las capacida-
des computacionales, el uso de los métodos analíticos y el software dispo-
nible de una manera tal como para concluir las funciones de la ingeniería de
sistemas de manera efectiva y eficiente. El CASE representa un nivel más
amplio de capacidad que el CAD o el CAE y está mejor descrito en el texto
de H. Eisner, Computer-Aided Systems Engineering (véase el apéndice B,
Ítem C.8).
8.Manufactura integrada por computadora (CIM). El proceso de utilizar
las capacidades computacionales y el software disponible para manufactu-
rar productos vía medios automatizados. El CIM se usa de manera similar al
CAM, salvo que el CIM tiende a enfatizar el uso de microcomputadoras y una
base de datos común. El CIM se describe a profundidad en el texto de M.
Horderski, Computer-Integrated Manufacturing (véase el apéndice D, ítem
C.1 1 para mayor información).
9.Ingeniería concurrente. "Un planteamiento sistemático al diseño inte-
grado, concurrente de productos y sus procesos relacionados, incluyendo
manufactura y soporte. Este enfoque se intenta para hacer que los desarro-
lladores, desde el exterior, consideren todos los elementos del ciclo de vida
del producto desde la concepción hasta el desecho, incluyendo la calidad,
GLOSARIO DE LOS TÉRMINOS SELECCIONADOS 439

el costo, el plan y los requerimientos del usuario" (Institute for Defense


Analysis Report, R-338). Véase la sección 1.4.
10.Bases de la configuración. Los puntos designados en el diseño del
sistema y el proceso de desarrollo cuando la configuración del sistema se
define con detalle. Los puntos comunes incluyen (1) la base funcional,
donde la configuración del sistema se describe a través de la definición de
los requerimientos operacionales del concepto de mantenimiento, la espe-
cificación Tipo "A" del sistema y los reportes del estudio de factibilidad; (2)
la base distribuida, donde la configuración del sistema se define a través de
una combinación de desarrollo, proceso, producto y especificaciones del
material (Tipos "B", "C", "D" y "E"), reportes de los estudios de compromisos
seleccionados del diseño y los datos del diseño del sistema-subsistema;
y (3) la base de producto, el producto y las especificaciones de material
(Tipos "C", "D" y "E"), reportes del estudio de compromisos, datos detalla-
dos del diseño (dibujos, listas de partes), datos del proveedor, etc.
La coordinación relativa del programa para cada una de estas "bases" se
ilustra en la figura 1.8 capítulo 1.
11.Control de la configuración. Se ocupa de la categorización y el control
de los cambios propuestos del diseño, es decir, los cambios de la clase 1 que
afectan la forma, medida y (o) la función y los cambios de la clase 2 que son
relativamente menores por naturaleza. Dada una base diseñada de configu-
ración, todos los cambios aplicados a esa base deben ser estrictamente
evaluados y controlados. Véase la sección 5.4.
12.Tablero de control de la configuración (CCB). Un tablero, que consiste
en los expertos que representan las diferentes disciplinas del diseño, el
responsable de la revisión y aprobación de los cambios a una base de
configuración dada. Véase la sección 5.4.
13.Administración de la configuración (CM). Un proceso de administra-
ción usado para identificar las características funcionales y físicas de un
ítem en las fases tempranas de su ciclo de vida, el control de cambios para
aquellas características y el registro y reporte de procesamiento ye! estatus
de implementación del cambio. La CM involucra cuatro funciones que
incluyen 1) la identificación de la configuración, 2) el control de la con-
figuración, 3) la contabilidad del estatus de la configuración y (4)
las revisiones de la configuración. La CM es el concepto "base" de la ad-
ministración.
14.Estructura de contrato. El tipo de contrato negociado entre el cliente
y el contratista y (o) entre el contratista y el proveedor. Las categorías más
importantes de los contratos incluyen a precio fijo (FFP), a precio fijo con
escalados, a precio fijo con incentivo, costo más pago fijo (CPFF), costo
más pago de incentivos (CPIF), costo compartido, tiempo y materiales
y carta de acuerdo. La naturaleza y tipo de contrato negociado son las
consideraciones más importantes en la implementación de los requerimien-
tos de la ingeniería de sistemas. Véase la sección 8.3.

440 ADMINISTRACIÓN DE INGENIERÍA DE SISTEMAS

15.Estructura de Descomposición de Costos (CBS). Una descomposición


de costos en términos funcionales. Deben incluirse todos los costos futuros
asociados con las actividades durante todas las fases del ciclo de vida
- deben separarse los costos con la profundidad requerida para proporcio-
y
nar la visibilidad necesaria relativa a los diferentes elementos del sistema y
(o) las diferentes actividades del programa. Se presenta un ejemplo en el
caso de estudio LCC en el apéndice A, figura A.4.
16.Efectividad de Costos (CE). La medida de un sistema en términos de
sus características técnicas y ciclo de vida. Las características técnicas
pueden incluir una combinación de desempeño, capacidad, rango, peso
y tamaño, confiabilidad, mantenibilidad, capacidad de soporte, capacidad de
producción, calidad y los parámetros relacionados. El costo del ciclo de vida
puede incluir todos los futuros costos asociados con la investigación,
diseño y desarrollo, la producción y (o) construcción, distribución, utiliza-
ción del sistema, mantenimiento de apoyo y soporte, retiro, desecho y el
reciclado de materiales como sea necesario. Estas características técnicas
pueden combinarse de alguna manera para proporcionar una medida de
"Efectividad del Sistema" La efectividad de costo puede expresarse a razón
de la efectividad del sistema al costo del ciclo de vida (LCC). Véase las
secciones 1. 1.2 y 1.3.9.
17.Revisión del diseño. Una revisión formal de la configuración del
sistema tal como éste se ha definido en un momento específico. Las revisio-
nes formales del diseño incluyen la revisión conceptual del diseño, una
omás revisiones del diseño (preliminar) del sistema, una o más revisiones de
diseño de equipo-software y una revisión del diseño crítico. Las revisiones
formales del diseño incluyen las "verificaciones y balances" necesarios en la
implementación de las funciones de la ingeniería de sistemas. Véase las
figuras 1.8 y 5.1 y secciones 5.1 y 5.3.
18.Diseño a costo (DTC) Una figura de mérito "diseño a" especificada
como un requerimiento del sistema durante el diseño conceptual e incluido
en la especificación Tipo "A" del Sistema. La figura de mérito DTC debe espe-
cificarse en términos del costo de ciclo de vida. Esto puede, a su vez, sepa-
rarse en "diseño al costo de creación de la unidad" y "diseño ala operación de
la unidad y costo de soporte" (o algo equivalente). Las categorías básicas
del costo deben definirse en términos de Lo que se incluye o no se incluye.
19.Efectividad. Una medida del sistema en términos de sus característi-
cas técnicas. Esta medida, o figura de mérito, que variará dependiendo del
tipo de sistema ysu misión, puede derivarse de una combinación de factores
de desempeño, peso y tamaño, capacidad, confiabilidad, mantenibilidad,
capacidad de soporte, calidad, etc. Véase las secciones 1.1.2 y 3.2.8.
20.Análisis de factibilidad. La investigación temprana, el estudio y la
determinación de los enfoques técnicos posibles del diseño en respuesta
a una necesidad definida para una nueva configuración del sistema. Esto
incluye la evaluación y la comparación de nuevas tecnologías, así como
GLOSARIO DE LOS TÉRMINOS SELECCIONADOS 441

la realización de la investigación aplicada en las áreas donde se desea un


conocimiento adicional. Véase la sección 2.2.
21.Análisis funcional El proceso de producir los requerimientos a nivel
M sistema a los criterios de diseño detallado para el desarrollo de los
componentes del sistema. Dada la definición de los requerimientos operacio-
nales del sistema yel concepto de mantenimiento, el siguiente paso es definir
el sistema en términos funcionales, identificar los QUÉS en términos de los
requerimientos específicos. Esto puede realizarse por medio de una serie de
diagramas de bloque funcionales. Estas funciones (para incluir ambas
funciones la operacional y la de mantenimiento) están separadas en
subf unciones, los estudios de compromisos se realizan para determinar
los CÓMOS asociados con la realización de las subfunciones y los recursos
se identifican en términos de requerimientos humanos, requerimientos de
equipo, software, datos, localidades, etc. Una vez más, este es un proceso
de arriba-abajo como resultado de los requerimientos del nivel del sistema
y lleva a la identificación de los requerimientos específicos del diseño. Véase
la sección 2.5.
22. Factores humanos. Las características del diseño del sistema se
relacionan al elemento humano del sistema. Las consideraciones en el
diseño deben incluir los factores antropométricos, los factores de los
sentidos humanos, los factores fisiológicos y los factores psicológicos.
Véase la sección 3.2.3.
23.Soporte Logístico Integrado (JIS). Una función de administración que
proporciona la planeación inicial, los recursos y el control que ayuda a ase-
gurar que el consumidor último (o el usuario) recibirán un sistema que no
sólo cumplirá los requerimientos de desempeño, sino también uno que
pueda ser soportado económicamente a lo largo de su ciclo de vida progra-
mado. Los elementos básicos del programa incluyen la programación inicial
para el soporte logístico, el diseño para la capacidad de soporte, el análisis
y creación de los diversos elementos de soporte y la valoración de la
capacidad de soporte del sistema en esta área. Véase la sección 3.2.5.
24.Ciclo de vida. El ciclo de vida planeado del sistema desde la identifi-
cación inicial de una necesidad hasta el retiro y la fase de salida de ese
sistema. Esto usualmente incluye las fases del diseño conceptual y la
planeación de avance, el diseño preliminar del sistema (la demostración
y validación), el diseño de detalle y desarrollo (la escala completa de desa-
rrollo), la producción y (o) construcción, la operación del sistema (utili-
zación), el mantenimiento y soporte de apoyo y el retiro. Aunque el ciclo de
vida (y sus fases) pueden cambiar a causa de las limitaciones presupuestales,
la introducción de obsolescencia y así sucesivamente, es aún importante
que se asuma un planteamiento del ciclo de vida. Véase la sección 1.1.1.
25. Costo del ciclo de vida (LCC). La combinación de todos los costos
asociados con las actividades planeadas y (o) realizadas durante el ciclo de
vida del sistema. Esto incluye los costos de investigación y desarrollo, el
442 ADMINISTRACIÓN DE INGENIERÍA DE SISTEMAS

diseño, la producción-construcción el uso operacional, el mantenimiento


y soporte y el retiro del sistema. Véase las secciones 1.1.2 y 3.2.8.
26.Sistema de información de la administración (MIS). Recopilación de
datos, procesamiento y capacidad de manejo que apoya a la administración
en la implementación de los requerimientos del programa. Un objetivo
esencial para la ingeniería de sistemas es el establecer una buena red de
comunicación que permita una valoración rápida del estatus del programa
y el inicio de acción correctiva de manera expedita. Véase la sección 6.2.7.
27.Mantenibilidad. Las características del diseño que se ocupan de la
facilidad, exactitud, seguridad y de la economía en el desempeño de las
acciones de mantenimiento. Las medidas asociadas más comúnmente con
la mantenibilidad son los tiempos transcurridos de mantenimiento (Md,
M7TR, Mpt, M MDT), los factores de frecuencia de mantenimiento (MTBR,
MTBM), los factores de hora de labor del personal de mantenimiento
(MMH/OH, MMH/MA, MMH-Mes, MLJ-f/OH) y el costo de mantenimiento ($
/M4). Cuando se trata solamente el tiempo transcurrido de mantenimien-
to, la mantenibilidad puede definirse como la probabilidad de que un siste-
ma sea mantenido o restaurado a una condición operante satisfactoria,
cuando se realiza el mantenimiento por el personal con los adiestramientos
especificados, usando los procedimientos y recursos aprobados, en cada
nivel designado de mantenimiento. Véase la sección 3.2.2.
28.Desempeño. Las características del diseño del sistema que se relacio-
nan a estas medidas, los requerimientos de entrada-salida, cantidad,
capacidad, tamaño y peso, rango, exactitud, potencia de salida, datos
trasmitidos por el incremento designado de tiempo, etc. A lo largo de este
texto, este término se ha usado para cubrir todas las características técnicas
de un sistema, con la posible excepción de la confiabilidad, mantenibilidad,
capacidad de soporte, factores humanos, la calidad, etcétera.
29.Capacidad de producción. Las características del diseño del sistema
que se relacionan a la facilidad, exactitud y economía asociadas con la
manufactura subsiguiente de los elementos del sistema en múltiples canti-
dades como se requiere. El objetivo es diseñar los productos que puedan ser
producidos fácilmente en múltiples cantidades, usando los procesos con-
vencionales de manufactura. Véase la sección 3.2.7 y la lista de verificación
del diseño de la figura 5.4y aquellas preguntas del apéndice B que se ocupan
de la capacidad de producción (ítem B.21).
30.Confiabilidad. Las características del diseño que se relacionan con la
habilidad de un sistema para realizar en un período designado de tiempo.
Más específicamente puede definirse como la probabilidad de que un siste-
ma o producto se desempeñará de manera satisfactoria por un período
dado de tiempo cuando se usa bajo condiciones especificadas operantes.
Las medidas de confiabilidad incluyen MTBF, MTBM, M7TF R y A. Véase la
sección 3.2.1.
GLOSARIO DE LOS TÉRMINOS SELECCIONADOS 443

31.Administración de riesgo. Un método organizado para identificar el


riesgo y para seleccionar y desarrollar las acciones de desarrollo para el
manejo del riesgo. La administración del riesgo debe tratarse en el plan de
administración de la ingeniería de sistemas (SEMP), e incluye las funciones
de valoración del riesgo, análisis del riesgo, abatimiento del riesgo. Véase la
sección 6.5.
32.Capacidad de soporte. Las características del diseño del sistema que
se ocupan de la habilidad de un sistema para ser soportado de manera
efectiva y económica. Estas características no sólo pertenecen a los elemen-
tos esenciales del sistema, sino también al diseño del equipo de prueba
y soporte, a la capacidad de suministro de soporte, al equipo de entrena-
miento, a las localidades, al software de mantenimiento, etcétera.
Muchos de los principios de confiabilidad, mantenibilidad, de factores
humanos también se incluyen. Véase la sección 3.2.5 y a la lista de verifica-
ción de la revisión del diseño de la figura 5.4, junto con aquellas preguntas
del apéndice B que se ocupan de la capacidad de soporte (Item 13.31).
33.Sistema. Un conjunto de componentes que funcionan juntos con el
objetivo común de desempeñar una función en respuesta a una necesidad
dada. Un sistema constituye un conjunto completo de recursos integrados
de una manera tal para cumplir un escenario definido de una misión. Tales
recursos pueden tomar la forma de seres humanos, materiales, equipo,
software, localidades, datos, etc. El sistema debe tener un propósito, éste
puede ser funcional, que sea posible responder a alguna necesidad identi-
ficada y debe ser posible alcanzar su objetivo global de manera efectiva en
cuanto a costo. Véasela sección 1.1.
34.Anólisis de/sistema. Un proceso analítico iterativo continuo, incluido
como parte del proceso de la ingeniería de sistemas, que involucra la
evaluación de los planteamientos del diseño, la realización de estudios de
compromisos, etc. El análisis del sistema se realiza a través del uso apro-
piado de los diversos métodos de investigación de operaciones para ayudar
a resolver el problema (simulación, teoría de colas, programación lineal
y dinámica, redes, etc.). Véase la sección 1.2.5.
35.Ingeniería de sistemas. La aplicación efectiva de los esfuerzos cientí-
ficos y de la ingeniería para transformar una necesidad operacional en una
configuración definida del sistema a través del proceso iterativo de arriba-
abajo de la definición de los requerimientos, el análisis funcional, distribu-
ción, síntesis, optimización del diseño, prueba y evaluación. Esto involucra
el proceso de la ingeniería de diseño para crear desde el principio urisistema
con énfasis en un enfoque del ciclo de vida integrado, de arriba-abajo. Véase
la sección 1.2.3.
36.Administración de la ingeniería de sistemas. Las actividades necesa-
rias de administración para la implementación de los requerimientos de la
ingeniería de sistemas. Esto incluye la planeación inicial, la organización
para la ingeniería de sistemas y la evaluación continua del programa y las
444 ADMINISTRACIÓN DE INGENIERLÁ DE SISTEMAS

actividades del control para asegurar que se cumplen los objetivos de la


ingeniería de sistemas. Véase la sección 1.3 y los capítulos 6, 7y 8.
37. Plan de administración de la ingeniería de sistemas (SEMP). El docu-
mento principal orientado a la administración que cubre la implementa-
ción de los requerimientos del programa de la ingeniería de sistemas. Este
plan se desarrolla durante la fase de diseño conceptual de un programa,
incluye los resultados de una planeación avanzada y lleva a los requerimien-
tos de las bases subsecuentes de la creación del sistema. Véase las seccio-
nes 1.3y6.2.
38. Integración del sistema. Involucra la integración técnica de los
elementos del sistema conforme avanza el esfuerzo de diseño y desarrollo,
junto con la integración de las diversas disciplinas del diseño y de soporte
en el esfuerzo global del diseño desde una perspectiva administrativa.
Posteriormente durante el diseño de detalle y desarrollo, el proceso de
integración involucra a menudo un enfoque de abajo-arriba relativo a la
determinación de los diversos componentes del sistema en subensam-
bIes, subensambles en ensambles, ensambles en unidades, etc. hasta un
sistema totalmente integrado que debe funcionar de acuerdo con los
requerimientos especificados inicialmente. Véase la sección 8.5.
39. Especificación del sistema. El documento técnico de alto nivel que
define los requerimientos básicos para el diseño y desarrollo del sistema.
Véase la sección 3.1 y la figura 3.3.
40. Síntesis del sistema. La combinación y estructuración de los compo-
nentes de una manera tal que representen una configuración factible del
sistema. Esto puede realizarse en algunas de ocasiones a través del proceso
de diseño y desarrollo del sistema y la configuración particular estructurada
no puede reflejar el planteamiento final del diseño. En esencia, uno necesita
definir una configuración de una manera tal que pueda evaluarse. Véase la
sección 2.7.
41. Medidas de desempeño técnico (TPMs). Aquellas medidas del siste-
ma, o actividades del programa que se consideran como críticas para la
realización exitosa de los objetivos de la ingeniería de sistemas. Los pará-
metros específicos cuantitativos, que reflejan las características básicas
del diseño del sistema, se especifican inicialmente en la Especificación del
Sistema (tipo "A"). Luego, conforme avanza el diseño y desarrollo, estos
factores necesitan integrarse al proceso de revisión del programa-diseño
planeado periódicamente para la comparación en oposición a los requeri-
mientos especificados inicialmente. Finalmente, una evaluación del siste-
ma, en términos de conformidad con estos requerimientos, se realiza
a través de la evaluación final del sistema y la actividad de prueba. El obje-
tivo es identificar los factores críticos que se relacionan con el desempeño.
Véase la sección 2.7 y la figura 5.2.
42. Plan maestro de prueba y evaluación (TEMP). Un documento clave de
la planeación, desarrollado durante la fase de diseño conceptual y planeación
GLOSARIO DE LOS TÉRMINOS SELECCIONADOS 445

de avance, que cubre la integración propuesta y los requerimientos de


prueba para el sistema como una entidad. Un planteamiento total de prueba
integrada es importante. Véase la figura 1.8 y la sección 2.8.
43.Administración de la calidad total (TQM). Un planteamiento de la
administración total integrada que trata la calidad del sistema-producto
durante todas las fases del ciclo de vida del sistema y en cada nivel de la
jerarquía global del sistema. Esto proporciona una orientación a posteriori
a la calidad, y se concentra en el diseño del sistema y en las actividades de
desarrollo, así como también en la producción, manufactura, ensamble,
construcción y funciones relacionados. Esto incluye las actividades asocia-
das con el "diseño para la capacidad de producción", la ingeniería de
calidad, el control de calidad, el control del proceso estadístico (SPC), el
aseguramiento de la calidad y la evaluación y control del proveedor. Véase
la sección 3.2.8.
44. Estructura de descomposición del trabajo (WBS). Una familia de
árboles orientados al producto que llevan a la identificación de actividades,
funciones, trabajos del programa, subtrabajos, paquetes de trabajo y etcé-
tera, que debe desarrollarse para la conclusión exitosa de un programa
dado. Esto despliega y define el sistema que debe desarrollarse, y represen-
ta todos los elementos de trabajo que deben realizarse. Hay "resúmenes de
las estructuras de descomposición del trabajo" (SWBSs) usadas para mos-
trar los niveles del árbol en la cima de descomposición del trabajo fuera de
una manera resumida y "contrato de estructuras de descomposición del
trabajo" (CWBSs) usados para propósitos de negociación de contrato.
Véase la sección 6.2.3.
-4
APÉNDICE D
BIBLIOGRAFÍA

A. SISTEMAS, INGENIERÍA DE SISTEMAS, CIENCIA DE LOS SISTEMAS,


ANÁUSLS DE LOS SISTEMAS.

1. Ackoff, R. L., S. K. Gupta y J.S. Minas, Scientific Method; Optimizing


Applied Research Decisions, John Wiley, New York, 1962.
2. Beam, W.R., Systems Engineering:Architecture andDesign, McGraw-Hill,
New York, 1990.
3. Bingham, J.E. y G.P. Davis. A Handbook of Systems Analysis, 2a ed.,
Macmillan, London, 1978.
4. Blanchard, B.S. y W.J. Fabrycky, Systems Engineering andAnalysis, 2d
ed., Prentice-Hall, Englewood Cliffs, N.J., 1990.
S. Chase, W.P., ManugementofSystem Engineering, John Wiley, New York,
1974.
6. Chestnut, H., Systems EngineeringMethods, John Wiley, New York, 1967.
7. Chestnut, H., Systems Engineering Tools, John Wiley, New YOrk, 1965.
8. Coutinho, J.,AdvancedSystems Deve!opmentManagement, John Wiley,
New York, 1977.
9. Defense Systems Management College (DSMC), Systems Engineering
Management Guide, DSMC, Fort Belvoir, Virginia, 22060.
10. Defense Systems Management College (DSMC), Test and Evaluation
Management Guide, DSMC, Fort Belvoir, Virginia, 22060.
11. Drew, D.R. y C.H. Hsieh, A Systems View of Deve!opment: Methodology
of Systems Engineering Management, Cheng Yang Publishing Co., No. 4,
Lane 20, Gong-Yuan Road, Taipei, ROC, 1984.
448 APÉNDICE D: BIBLIOGRAFÍA

12. Fisher, G.H. Cost Consideration in Systems Analysis, Rand Corp. Report,
R-490ASD, American Elsevier, New York, 1971.
13. Forrester, J.W., Principies of Systems, The MIT Press, Cambrigde, MA,
1968.
14. Gheorghe, A., AppliedSystems Engineering, John Wiley, New York, 1982.
15. Hall, A.D., A Methodology for Systems Engineering, D. Van Nostrand,
Princeton, N.J.,1962.
16. Jenkins, G.M. y P.V. Youle, Systems Engineering- A UnifyingApproach in
Jndustry and Society, C.A. Watts & Co., London, 1971.

17. Klir, G.J., An Approach to General Systems 7lieory, Van Nostrand Rein-
hoid, New York, 1969.
18. Macho!, R.E., (Ed.), System Engineering Handbook, McGraw-Hill, New
York, 1965.
19. Majone, G. y E.S. Quade (9 eds.), Pitfalls of Analysis, John Wiley, New
York, 1980.
20. Miles, R.F., Systems Concepts: Lectures on ContemporaryApproaches to
Systems, John Wiley, New York, 1973.
21. MIL-STD-499A, Military Standard, "Engineering Management"
Headquarters, U.S. Air Force/Air Force Systems Command, Andrews
AFB, MD 20331.
22. Ostrosfsky, B., Design, PianningandDevelopmentMethodoiogy, Prentice-
Hall, Englewook Cliffs, N.J., 1977.
23. Rouse, W.B., Systems Engineering Modeis oíHuman-Machine Intraction,
Elsevier/North Holland, New York, 1980.
24. Sage, A. P., Economic System analysis: Microeconomics for Systems
Engineering, Engineering Management, and Project Selecion, Elsevier
Science, New York, 1983.
25. Sage, A. P., Methodology for Large Scale Systems, McGraw-Hill, New
York, 1977.
26. Sandquist, G. M., Introduction to System Science, Prentice-Hall, Engle-
wood Cliffs, N.J., 1985.
27. Shinners, S.M., A Guide to Systems Engineering and Management,
Lexington Books, Lexington, MA, 1976.
28. Singh, M. G. (Ed.), Systems and ControlEncyclopedia: llieory, Applications,
Pergamon Press, Elmsford, NY, 1989.
BIBLIOGRAFÍA 449

29. Truxal, J. G., Jntroductoiy System Engineering, McGraw-Hill, New York,


1972.
30. Van Bertalanffy, L., General Systems Theory George Braziller, New York,
1968.
31. Weinberg G. M., An Introduction to General Systems Thinking, John
Wiley, New York, 1975.
32. Wymore, A. W. Systems Engineering Methodology for Jnterdisciplinary
Teams, John Wiley, New York, 1976.

B. INVESTIGACIÓN DE OPERACIONES

1. Churchman, C. W., R. L. Ackoff y E. L. Arnoff, Introduction to Operations


Research, John Wiley, New York, 1957.
2. Fabrycky, W. J., P. M. Ghare y P. E. Torgersen, Applied Operations
Research and Management Science, Prentice-Hall, Englewoocl, Cliffs,
N.J., 1984.
3. Hillier, F. S. y G. J. Lieberman., Introduction to Operations Research,
a ed., McGraw-Hill, New York, 1990.

4. Taha, H. A., Operations Research: An Introduction, 31 ed., Macmillan,


New York, 1982.

C. DISEÑO ASISTIDO POR COMPUFADORA/MANUFACrURA/LOGÍSTICA/


SOFTWARE

1. Asimow, M., Introduction to Design, Prentice-Hall, Englewood Cliffs,


N.J., 1962.
2. Beakley, G. C., D.L. Evans, y J. B. Keats, Engineering: An Introduction to
a Creatíve Profession, 3,1 ed., Macmillan, New York, 1986.
3. Boehm, B. W., Software EngineeringEconomics, Prentice-Hall, Englewoocl
Cliffs, N.J., 1981.
4. Buffa, E. S., Modem Production and Operations Management, Sa ed., John
Wiley, New York, 1987.
S. Defense Systems Management College (DSMC), Mission Critical Computer
Resources Management Guide, DSMC, Fort Belvoir Virginia, 22060.
450 APÉNDICE D: BIBLIOGRAFÍA

6. Dieter, G. E., Engineering DesignA Materials and Processing Approach,


McGraw-Hill, New York, 1983.
7. DOD-STD-2167, Defense Standard, "Defense System Software
Development", Departamento de Defensa, Washington, D.C.
8. Eisner, H., Computer-A ided Systems Engineering, Prentice-Hall,
Englewood Cliffs, N.J., 1988.
9. Fairley, R., Software Engineeering Concepts, McGraw-Hill, New York,
1985.
10. General Electric Co., Software Engineering Handbook, McGraw-Hill,
New York, 1986.
11. Hordeski, M., Computer Integrated Manufacturíng, TAB Books, Blue
Ridge Summit, PA, 1988.
12. Krick, E. y., An Introduction to Engineering and Engineering Design, 2
ed., John Wiley, New York, 1969.
13. Krouse, J. K., What Eveiy Engineer Should Know About Computer-A ided
Design and Computer-Aided Manufacturing, Marcel Dekker, New York,
1982.
14. MIL-HDBK-59, Military Handbook, "Computer-Aidecl Acquisition And
Logistic Support (CALS) Program Implementation Guide", Departa-
mento de Defensa, Washington, D.C.
15. MIL-STD-1679A, Military Standard, "Software Development", Departa-
mento de Defensa, Washington, D.C.
16. Nevins, J. L. yD. E. Whitney, Concurrent Des ign of Products andProcesses,
McGraw-Hill, New York, 1989.
17. Pressman, R.S. Software Engineering.A Practitioner'sApproach, McGraw-
Hill, New York, 1982.
18. Shere, K. D., Software Engineering and Management, Prentice-Hall,
Englewoocl Cliffs, N.J., 1988.
19. Shooman, M., Software EngineeringDes ign, Reliability andManugement,
McGraw-Hill, New York, 1983.
20. Starr, M. K., Operations Management, Prentice-Hall, Englewood Cliffs,
N.J., 1978.
21. Teicholz, E. (Ed.), CA D/CAM Handbook, McGraw-Hill, New York, 1985.
22. Vick, C. R. y C. V. Ramamcorthy, Handbook of So ftware Engineering, Van
Nostrand Reinhoid, New York, 1984.
BIBLIOGRAFÍA 451

23. Winner, R. 1., J. P. Penneli, H. E. Bertrand y M. M. G. Slusarczuk, The Role


of Concurrent Engineering in Weapons System Acquisition, Institute of
Defense Analysis (IDA) Report R-338, diciembre 1988.
24. Woodson, T. T., Introduct ion fo Engineering Design, McGraw-Hill, New
York, 1966.

D. CONFIABILIDAD

1. Amstadter, B. L., Reiiability Mathematics: Fundamenfais, Practices,


Procedures, McGraw-Hill, New York, 1971.
2. Annual Reiiabiiity and Mainfainabi!ity Symposium, Proceedings, Evans
Associates, 804 Vickers Avenue, Durham, NC, 27001.
3. Arsenault, J. E. yJ. A. Roberts, ReiiabiliiyandMainfainabiiiiyofEiectronic
Systems, Computer Science Press, Potomac, MD, 1980.
4. Bazovsky, 1., Reiiabiiify Theoiy and Pracfice, Prentice-Hall, Englewood
Cliffs, N.J., 1961.
5. Calabro, S. R., Reliabiiity Principies and Pracfices, McGraw-Hill, New
York, 1962.
6. Dhillon, B.S. y C. Singh, Engineering Reiiabiiity: New Techniques and
Appiications, John Wiley, New York, 1981.
7. Dhillon B.S. y H. Reiche, Reliabiiity and Mainfainability Management,
Van Nostrand Reinhold, New York, 1985.
8. DOD Directive 5000.40, "Reliability and Maintainability", Departa-
mento de Defensa, Washington, D.C.
9. Doty, L. A., Reliabili(y for the Technoiogies, Industrial Press, New York,
1985.
10. Fugua, N. B., Reliabiiity, Engineering for Eiectronic Design, Marcel
Dekker, New York, 1987.
11. Green, A. E. yA. J. Bourne, Re!iabiiity Technoiogy, John Wiley, New
York, 1972.
12. Grosh, D. L.,A PrimerofRe(iabiiity Theory, John Wiley, New York, 1989.
13. Halpern, S., The Assurance Sciences-An Introduct ion to Quaiify Control
and Realiabilily, Prentice-Hall, Englewood Cliffs, N.J., 1978.
14. Harr, M. E., Reiiabiiity-Based Design in Civil Engineering, McGraw-Hill,
New York, 1987.
452 APÉNDICE O: BIBLIOGRAFÍA

15. Henley, E. J., y H. Kumamoto, ReliabilityEngineeringandRiskAssessment,


Prentice-Hall, Englewoocl Cliffs, N.J., 1981.
16. Ireson, W. G. y C. F. Coombs (eds.), Handbook of Reliabilíty Engineering
and Management, McGraw-Hill, New York, 1988.
17. Jarcline, A. K. S., Maintenance, Replacement, and Reliability, Halsted
Press, John Wiley, New York, 1973.
18. Kapur, K. C. y L. R. Lamberson, Reliability in Engineering Design, John
Wiley, New York, 1977.
19. Landers, R. R., ReliabiliiycindProductAsurance.A ManualforEngineering
and Management, Prentice-Hall, Englewood Cliffs, N.J., 1963.
20. Lewis, E. E., Jntroduction fo Reliability Engineering, John Wiley, New
York, 1987.
21. Lloyd, D.K. y M. Lipow, Reliability: Management, Methods, and
Mathematics, 2,1 ed., publicados por los autores, Defense and Space
Systems Group, TRW Systems and Energy, Redondo Beach, California,
1977.
22. Locks M. O., Reliability Mainfainability, and Availabilily Assessment,
Hayden Book C'ompany, Roche/le Park, N.J, 1973.
23. Mann, N. R., R.E. Schafer y N. D. Singpurwalla, Mefhods for Statistical
Analysis of Reliability and Test Data, John Wiley, New York, 1974.
24. MIL=HDBK-1 89, Military Handbook, "Reliability Growth Management",
Departamento de Defensa, Washington, D.C.
25. MIL-HDBK-217-E, Military Handbook, "Reliability Predictions oí
Electronic Equipment", Departamento de Defensa Washington, D.C.
26. MIL-HDBK-338, Military Handbook "Electronic Reliability Design
Handbook", Departamento de Defensa, Washington, D.C.
27. MIL-STD-721C, Military Standard, "Definitions oí Terms for Reliability
and Maintainability", Departamento de Defensa, Washington, D.C.
28. MIL-STD-75613, MilitaryStandard, "Reliability Modeling and Prediction",
Departamento de Defensa, Washington, D.C.
29. MIL-STD-781D, Military Standard, "Reliability Testing for Engineering
Development, Qualification, and Production", Departamento de Defen-
sa, Washington, D.C.
30. MIL-ST13-78513, Military Standard, "Reliability Program for Systems and
Equipment Development and Production", Departamento de Defensa,
Washington, D.C.
BIBLIOGRAFÍA 453

31. MIL-STD-1 629A, Military Standard, "Procedures for Performing a Failure


Mode, Effets and Criticality Analysis", Departamento de Defensa, Wa-
shington, D.C.
32. MIL-STD-2155, Military Standard, "Failure Reporting, Analysis, and
Corrective Action System (FRACAS)", Departamento de Defensa, Wa-
shington, D.C.
33. MIL-STD-2164, Military Standard, "Environmental Stress Screening
Process for Electronic Equipment", Departamento de Defensa, Wa-
shington, D.C.
34. Musa, J. D., A. lanninoy K. Okumoto, Software Reiiabiiity: Measurement,
Prediction Appiication, McGraw-Hill, New York, 1987.
35. O'Connor, P. D. T., Practica! Reliability Engineering, John Wiley, New
York, 1981.
36. RDH-376, Reliability Design !- fandbook, Reliability Analysis Center,
Criffiss AFB, New York, 1976.
37. Sandler, G. H.,SystemReiiabi!ityEngineering, Prentice-Hall, Englewood
Cliffs, N.J., 1963.
38. Shooman, M. L., Probabi!istic Reliability: An Engineering Approach,
McGraw-Hill, New York, 1968.
39. Siewiorek, D. P. y R.B. Swarz, The TheoiyandPractice OfRe!iab!e System
Desing, Digital Press, Educational Services, Digital Equipment Corp.,
Bedford, MA01730, 1982.
40. Von Alven, W. U. (Ed.), ReiiabiiityEngineering, Prentice-Hall, Englewood
Cliffs, N.J., 1964.

E. MANTENIBILIDAD Y MANTENIMIENTO

1. Blanchard, B. S. yE. E. Lowery, Maintainabiiily Principies andPractices,


McGraw-Hill, New York, 1969.
2. Cunningham, C. E. yW. Cox,App!iedMaintainabiiilyEngineering, John
Wiley, New York, 1972.
3. DOD Directive 5000.40, "Reliability and Maintainability", Departamen-
to de Defensa, Washington, D.C.
4. Goldman, A. y T. Slattery, Maintainabi!ity: A Major E!ement of System
Effectiveness, John Wiley, New York, 1967.
454 APÉNDICE D: BIBLIOGRAFÍA

S. Jardine, A. K. S., Maintenance, Rep!acement and Re!iabilily, A Haisted


Press Book, John Wiley, New York, 1973.
6. KeIly, A. and M. J. Harris, Management fo Industria! Maintenance,
Newness-Butterworths, London, 1978.
7. Mann, L., Maintenance Management, Lexington Books, D. C. Heath,
Lexington, MA, 1976.
8. MIL-HDBK-472, Military Handbook, "Maintainability Prediction", De-
partamento de Defensa, Washington, D.C.
9. MIL-STD-470-B, MilitaryStandard, "Maintainability Program for Systems
and Equipment", Departamento de Defensa, Washington, D.C.
10. MIL-STD-4 1 7A, Military Standard, "Maintainability Verification, Demo-
nostration, Evaluation", Departamento de Defensa, Washington, D.C.
11. MIL-STD-721 C, Military Standard, "Definitions of Effectiveness Terms
for Reliability, Maintainability, Human Factors, and Safety", Departa-
mento de Defensa, Washington, D.C.
12. MIL-STD-2084, Military Standard, "General Requirements for
Maintainability", Departamento de Defensa, Washington, D.C.
13. MIL-STD-2 165, Military Standard, "Testability Program for Electronic
Systems and Equipments", Departamento de Defensa, Washington,
D.C.
14. Moss, M. A., Designing for Mm ima! Maintenance Expense: The Practica!
App!ication ofRe!iabi!ity and Maintainabi!ity,, Marce! Dekker, New York,
1985.
15. Nakajima, 5., Total Productive Maintenance (rPM), Productivity Press,
Cambridge, MA, 1988.
16. Nakajima, S. (Ed.), TPM Deve!opment Program: Imp!ementing Total
Productive Maintenance, Productivity Press, Cambridge, MA. 1989.
17. Newbrough, E. T., Effective Maintenance Management, McGraw-Hill,
New York, 1967.
18. Niebel, B.W., Engineering Maintenance Management, Marce! Dekker,
new York, 1985.
19. Patton, J. D., Maintainability and Maintenance, lnstrument Society of
America, 67AlexandriaDrive, P. O. Box 12277, ResearchTriangle Park,
NC 27709,1980.
20. Patton, J. D., Preventive Maintenance, Instrument Society of America,
Research Triangle Park, NC 27709, 1983.
BIBLIOGRAFÍA 455

21. Wireman, T., World Class Maintenance Management, Industrial Press,


New York, 1990.

F. FACTORES HUMANOS Y SEGURIDAD

1. Brown, D. B., Systems Analysis and Design for Safety, Prentice-Hall,


Englewood Cliffs, N.J., 1976.
2. DeGreene, K. B. (Ed.), Systems Psychology, McGraw-Hill, New York,
1970.
3. Hammer, W., Occupational Safety Management and Engineering, 41 ed.,
Prentice-Hall, Englewood Cliffs, N.J., 1989.
4. Hammer, W., Product Safety Management and Engineering, Prentice-
Hall, Englewood Cliffs, N.J., 1980.
S. Meister, D., BehavioralAnalysis andMeasurementMethods, John Wiley,
New York, 1985.
6. MIL-I-IDBK-759A, Military Handbook, "Human Factors Engineering
Desing for Army Material", Departamento de Defensa, Washington,
D.C.
7. MIL-1-1-4685513, Military Specification, "Human Engineering Requi-
rements for Military Systems, Equipment, and Facilities", U.S. Army
Missile R & D Command (DRDMI-ESD) Redstone Arsenal, Ala-
bama, 35809.
8. MIL-STD-88213, Military Standard, "Systems Safety Program
Requirements", Departamento de Defensa, Washington, D.C.
9. MIL-STD-1472C, Military Standard, "Human Engineering Design Criteria
for Military systems, Equipment, and Facilities", Departamento de
Defensa, Washington, D.C.
10. Rodgers, W. P., Introduction to System Safety Engineering, John Wiley,
New York, 1971.
11. Roland, H. E. yB. Moriarty,System Safety Engineering and Management,
John Wiley, New York, 1983.
12. Sanders, M.S y E.J. McCormick, Human Factors in Engineering and
Design, 61 ed., McGraw-Hill, New York, 1987.

13. Salvendy, G. (Ed.), Handbook of Human Factors, John Wiley, New York,
1987.
456 APÉNDICE D: BIBLIOGRAFÍA

14. Van Cott, H.P. y R. G. Kinkade (Eds.), Human Engineering Guide to


EquipmentDesign, U.S. Governemnt Printing Office, Washington, D.C.,
1972.
15. Woodson, W. E., Human Factors Design Handbook, McGraw-Hill, New
York, 1981.

G. LOGÍSTICA

1. Ammer, D.S., Material Management and Purchasing, Richard D. lrwin,


Homewood, IL, 1980.
2. Ballou, R. H., Basic Business Logisitic, Prentice-Hall, Englewood Cliffs,
N.J., 1978.
3. Banks, J. y W.J. Fabrycky, Procurement and Jnventoy Systems Analysis,
Prentice-Hall, Englewood Cliffs, N.J., 1987.
4. Blanchard, B. 5., Logistic Engineering and Management, 411 ed. Prentice-
Hall, Engelwood Cliffs, N.J., 1991.
5. BIeueI, W. H. y J. D. Patton, Service Management.Principles andPractices,
lnstrument Society of America, Pittsburgh, 1978.
6. Bowersox, D, D. Closs yO. Helferich, LogisticalManagement, Macmillan,
New York, 1986.
7. Council of Logistics Management, Joumal of Business Logistics, 2803
Butterfield Road, Suite 380, Oak Brook, lL 60521.
8. Coyle, J.J., E.J. Bardi y C.J. Langley, The Management of Business
Logistics, 41 cd., West Publishins Co., St. Paul, 1988.

9. Coyle, J.J., E. J. Bardi Y J.L. Cavinato, Transportation, West Publishing


Co., St. Paul, 1982.
10. Davis G. M. y S. W. Brown, Logistics Management, Lexignton Books,
Lexignton, MA. 1974.
11. Defense Systems Management College (DSMC), Integrated Logistics
Support Guide, DSMC, Fort Belvoir, VA 22060.
12. DOD Directive 5000.39, "Acquisition and Management of Integrated
Logistic Support for Systems and Equipment", Departamento de
Defensa, Washington, D.C.
13. Fair, M. L. y E. W. Williams, Transportation and Logistics, Business
Publications, Dallas, 1981.
BIBLIOGRAFÍA 457

14. Green, L. L., New Dimensions In Logistics, John Wiley, New York, 1990.
15. Hay W.W., An Introuction fo Transportation Engineering, 21 ed., John
Wiley, New York, 1977.
16. 1-larper, D. y., Transportation in America: Users, Carriers, Government,
2 ed., Prentice-Hall, Englewood Cliffs, N.J., 1982.
17. Heskett, J.L., N.A., Glaskowsky, y R.M. Ivie, Business Logistics, 21 ed.,
Ronald Press, New York, 1973.
18. Hutchinson, N. E., An Integrated Approach fo Logistics Management,
Prentice-Hall, Englewood Cliffs, N.i., 1987.
19. iones, J. y., Logistics SupportAnalysis Handbook, Tab books Blue ridge
Summit, PA, 1989.
20. Jones, J. y., Integrated Logistics Support Handbook, Tab Books, Blue
Ridge Summit, PA, 1987.
21. Magee, J. F., Industrial Logistics, McGraw-Hill, New York, 1968.
22. Magee, J.F., W.C. Copacino, y D.B. Rosenfield, Modern Logistics
Management, John Wiley, New York, 1985.
23. Nowland, F.S. y H. F. Heap, Reliability-Centered Maintenance, United
Airlines (MDA 903-75-C-0349), San Francisco, CA 94128, 1978.
24. MIL-1-IDBK-59, Military Handbook, "Computer-Aided Acquisition Logistic
Support (CALS) Habilitation Guide", Departamento de Defensa, Was-
hington, D.C.
25. MIL-HDBK-226, Military Handbook, "Application of Reliability-Centered
Maintenance to Naval Aircraft, Weapon Systems, and Support
Equipment", Departamento de Defensa, Washington, D.C.
26. MIL-STD-1388-1, Military Standard, "Logistics Support Analysis", De-
partamento de Defensa, Washington, D.C.
27. MIL-STD-1388-2, Military Satandard, "Departament of Defense
Requeriments for a Logistic Support Analysis Record", Departamento
de Defensa, Washington, D.C.
28. MIL-ST13-1 840A, Military Standard, "Automated Interchange of Technical
Information", Departamento de Defensa, Washington, D.C.
29. MIL-D-28000, Military Standard, "Digital Representantion for
Communication of Product Data: IGES Subsets", Departamento de
Defensa, Washington, D.C.
30. O'Neil and Associates, Inc., Integrated Logistics Support, P. O. box 520,
Dayton, OH, 45402.
458 APÉNDICE D: BIBLIOGRAFÍA

31. Orsburn, D. K., Introduction fo Spares Management, Academy Printing &


Publishing Co., 16202 S. Orange Avenue. P. O. Box 560, Paramount CA
90723, 1985.
32. Patton, J. D., Jr., Logistics Technology and Management-71e New
Approach, The Solomon Press, New York, 1986.
33. Peppers, J. G., History of UnitedStates Militaiy Logistics-1935 to 1985, 438
Coronado Drive, Fairborn, OH 45324, 1987.
34. Rose, W., Logzstics Management. Systems and Components, Wm. C.
Brown Company, Dubuque lA, 1978.
35. Shapiro, R. D. y James L. Heskett, Logistics Strategy: Cases and Concepts,
West Publishing Co., St. Paul, 1985.
36. Society of Logistics Engineers (SOLE), Annals, 125 West Park Loop,
Suite 201, Huntsville, AL 35806.
37. Society of Logistics Engineers (SOLE), Logistics Spectrum, 125 West
Park Loop, Suite 201, Huntsville, AL 35806.
38. Societyof Logistics Engineers (SOLE), Proceedings, Annual Suymposium,
125 West Park Loop, Suite 201, Huntsville, AL 35806.
39. Stock, James R. y Douglas M. Lambert, Strategic Logistics Management,
2a ed., Richard D, lrwin, Homewood, IL, 1987.
40. U.S. Air Force, Air Force Joumal Of Logistics, U.S. Government Printing
Office, Washington, D.C.
41. U.S. Air Force,A irForce Logistics Research AndStudies Program, Summary
Proceedings, U. S. Air Force Coordinating Office for Logistics Research
(AFCOLR), Wright-Patterson AFB, OH 45433 (Yeary Publication).
42. U.S. Air Force, Compedium oíA uf he nticated Systems andLogistics Terms,
Definitions, and Acroyms, AU-AFIT-LS-3-81, U.S. Air Force Institute of
Techonology, Wright-Patterson AFB, Dayton, OH, abril de1981.
43. U.S. Army, Annual Departament of Defense Bibliography of Logistics and
Related Documents, Defense Logistics Studies lnformation Exchange
(DLSIE), U.S. Army Logistics Management Center, Fort Lee, VA, 23801.

H. INGENIERÍA DE CALIDAD, ASEGURAMIENTO DE LA CALIDAD, ADMI-


NISTRACIÓN DE LA CALIDAD

1. Besterfield, D. H., Quali!y Control, 21 ed., Prentice-Hall, Englewood


Cliffs, N.J., 1986.
BIBLIOGRAFÍA 459

2. Crosby, P. B., Quality Is Free, The New American Library, New York,
1979.
3. Deming, W. E., Outof (he Crisis, Massachusetts Institute of Techonology
Press, Cambridge, MA, 1986.
4. Duncan, A. J., Quality Control and Industrial Statistics, 5a ed., Richard D.
lrwin, Homewood, IL, 1986.
5. Feingenbaum, A. V., Total Quality Control, 31 ed., McGraw-Hill, New
York, 1983.
6. Garvin, D. A., Managing Quality: The Strategic and Competitive Edge, The
Free Press, Macmillan, New York, 1988.
7. Grant, E.L. y R.S. Leavenworth, Statistical Quality Control, 6a ed., McGraw-
Hill, New York, 1988.
8. lshikawa, K., Guide to Quality Control, Unipub, New York, 1984.
9. Juran, J. M. (Ed.), Quality Control Handbook, 31 ed., McGraw-Hill, New
York, 1979.
10. Juran, J.M. y F.M. Gryna, Quality Planning and Analysis: From Product
Development Through Use, 2a ed., McGraw-Hill, New York, 1980.
11. MIL-Q-9858A, Military Stantard, "Quality Program Requirements",
Deparatamento de Defensa, Washington, D.C.
12. PalI, G. A., QualiiyProcess Management, Prentice-Hall, Englewood Cliffs,
N.J., 1987.
13. Ross, P. J., Taguchi Techniques for Quality Engineering, McGraw-Hill,
New York, 1988.
14. Scherkenbach, W. W., The Deming Route (o Quality and Productivity:
Road Maps and Roadblocks, CEE Press Books, George Washington
University, Washington, D.C., 1986.
15. Taguchi, G., E.A. ElsayedyT.C. Hsiang, QualilyEngineeringinProduction
Systems, McGraw-Hill, New York, 1989.

I. ECONOMÍA DE LA INGENIERÍA, COSTO DEL CICLO DE VIDA, ESTIMA-


CIÓN DE COSTO

1. Berliner, C. y J. Brimson, Cost Management for Today's Advanced


Manufacturing-The CAM-I Conceptual Design, Harvard Business School
Presss, Inc., Boston, MA, 1988.
460 APÉNDICE D: BIBLIOGRAFÍA

2. Blanchard, B.S., Design andManage toLife Cycie Cost, Matrix Press, 8437
Mayfield Roda, Chesterland, OH 44026.
3. Brown, R. J., y R.R. Yanuck, Introduction to Life Cycle Costing, AEE Energy
Books, Dept. 64, 4025 Pleasantdale Road, Suite 340, Atlanta, GA 30324,
1985.
4. Canada, J. R. y W. G. Sullivan, Economic andMultiattribute Evaluation of
Advanced Manufacturing Systems, Prentice-Hall, Enlewood Cliffs, N.J.,
1989.
S. DARCOM P700-6 (Army), NAVMAT P5242 (Navy), AFLCP-AFSCP 800-19
(Air Force), Joint-Des ign-to-CostGuide, Life Cycle Costa Design Parameter,
Departaments of the Army-Navy-Air Force, Washington, D.C.
6. Dhillon, B.S., Life C)'cle Costing: Techniques, Modeis and Applications,
Gordon and Breach, New York, 1989.
7. DOD Directive 4245.3, "Design to Cost", Departamento de Defensa,
Washington, D.C.
8. DOD Guide LCC-1 , Life Cycle CostingProcurement Guide, Deparatamento
de Defensa, Washington, D.C.
9. DOD Guide LCC-2, Casebook, Life Ccle Costing in EquipmentProcurement,
Deparatamento de Defensa, Washington, D.C.
10. DOD Guide LCC-3, Life Cycle Costing Guide for System Acquisitions,
Deparatamento de Defensa, Washington, D.C.
11. DOD-HDBK-766, Military Handbook, "Design To Cots", Departamento
de Defensa, Washington, D.C.
12. DOD-STD-337, Mlitary Standard, "Design to Cost", Departamento de
Defensa, Washington, D.C.
13. Earles, M.E., Factors, Formulas and Structures for Life Cycle Costing, 89
Lee Drive, Concord, MA 01741.
14. English, J. M. (Ed.), Cost Effectiveness-771e Economic Evaluation of
Engineering Systems, John Wiley, New York, 1968.
15. Fabrycky, W. J. y B. S. Blanchard, Life-Cycle CostandEconomic, Analysis,
Prentice-Hall, Englewood Cliffs, N.J., 1991.
16. Fabrycky, W. J. y G. J. Thuesen, Economic Decision Analysis, 2a ed.,
Prentice-Hall, Englewood Clifís, N.J., 1980.
17. Fisher, G. H., Cost Considerations in System Analysis, Prentice-Hall,
Englewood Cliffs, N.J., 1971.
BIBLIOGRAFÍA 461

18. Grant, E.L., W.G. Ireson y R.S. Leavenworth, Principies of Engineering


Economy, 71 ed., Ronald Press, New York, 1982.
19. Jelen, F. C. y J. H. Black, Cost and Opfimizafion Engineering, McGraw-
Hill, New York, 1983.
20. Humphreys, K.K. yS. Katell, Basic CostEngineering, Marce! Dekker, New
Yor, 1981.
21. Michaels, J.V. yW.P. Wood, Design fo Cost, John Wiley, New York, 1989.
22. MIL-HDBK-259, Military Handbook, "Life Cycle Cost in Navy
Acquisitions", Departamento de Defensa, Washington, D.C.
23. MIL-STD-1 390B, Military Standard, "Leve! of Repair", Departamento de
Defensa, Washington, D.C.
24. 0MB Circular A-76, "Cost Comparison Handbook", Office of the
Management of the Budget, Washington, D.C.
25. Ostwald, P. F., CostEstimating, 2a ed., Prentice-Hall, Englewood Cliffs,
N.J., 1984.
26. Riggs, J. L., EngineeringEconomics, 2 ed., McGraw-Hill, New York, 1982.
27. Stewart, R. D. y A. L. Stewart, Cost Estimating with Microcomputers,
McGraw-Hill, New York, 1980.
28. Stewart, R. D., CostEstimating, 2a ed., John Wiley, New York, 1990.
29. Stewart, R.D. y R.M. Wyskida, CostEstimator's Reference Mannual, John
Wiley, New York, 1987.
30. Thuesen, G.J. y W.J. Fabrycky, Engineering Economy, 7 ed., Prentice-
Hall, Englewood Cliffs, N.J., 1989.

J. ADMINISTRACIÓN Y ÁREAS DE APOYO

1. Blanchard, B. S., Engineering Organiza tion andManagement, Prentice-


Hall, Englewood ClifÍs, N.J., 1976.
2. Cleland, D. 1. y W. R. King, Project Management Handbook, 2a ed., Van
Nostrand, Reinhoid, New York, 1989.
3. Defense Systems Management College (DSMC), Manufacfuring
Management. Guide For Program Managers, DSMC, For Belvoir, VA
22060.
462 APÉNDICE D: BIBLIOGRAFÍA

4. Dhillon, B. S., Engineering Management, Technomic Publishing Co.,


Lancaster PA, 1988.
S. Griffin, R.W. yG. Moorhead, Organizational Behavior, Houghton Miflin,
Boston, 1986.
6. Johnson, R.A., F.E. , Rosenzweig, The TheoiyandManagmentofSystems,
3 ed., McGraw-Hill, New York, 1973.
7. Kerzner, H., Project Management: A Systems Approach to Planning,
Scheduling, and Contro!ling, 3a ed., Van Nostrand Reinhold, New York,
1989.
8. Koontz, H., C. O'Donnell y H. Weihrich, Essentials ofManagement, 4a ed.,
McGraw-Hill, New York, 1986.
9. Rosenau, M. D., Successful Project Management, Lifetime Learning
Publications, Belmont, CA, 1981.
10. Stewart, R. D. y A. L. Stewart, Proposal Preparation, John Wiley, New
York, 1984.
11. Ullmann, J.E., D.A. Christman yB. Holtje (Eds.), Handbook ofEngineering
Management, John Wiley, New York, 1986.
12. Wall, W. C., ProposalPreparation Guide, John Wiley, New York, 1990.
ÍNDICE

A de nivel de reparación, 53, 152, 392-


accesibilidad, 415-416 393
administración de calidad total (TQM), de riesgo, 293-294
40, 162-163, 292, 330, 445 de sensibilidad, 76
administración: de sistema, 33-34, 69-71
calidad total (TQM), 162 de soporte logístico (LSA), 65, 149-
configuración, 38 150, 203-204
Ingeniería de sistemas, 38-39 de tiempos, 251
sistema de información (MIS), 190- de trabajos, 141, 397, 399
191, 202, 286, 442 del costo del ciclo de vida, 168, 379
ajustes y alineación, 414 funcional, 57-60, 410-411, 441
alternativas, evaluación de, 71 pasos del, 72
ambiente: asesorando a la organización, 341
mantenimiento, 57 asignación, requerimiento de, 41, 437
operacional, 48 asistido(a) por computadora:
organizacional, 278 creación y soporte logístico, (CALS),
requerimientos, 416 78, 80, 202-203, 437-438
análisis de árboles de fallas (FrA), 64, diseño, (CAD), 78, 80, 188, 438
145 Ingeniería de sistemas, (CASE), 184,
análisis de factibilidad, 35, 45, 46, 407- 438
408 manufactura, (CAM), 78, 80, 438
análisis de nivel de reparación (LORA),
53, 152, 196, 392-393
análisis de riesgos, 145 B
análisis de sensibilidad, 76
análisis de tiempo, 251 bibliografía, 447
análisis del trabajo del operador, 65,
141
análisis: C
de árboles de fallas, 145
de factibilidad, 33, 44-45, 440-441 cables y conectores, 414-415
de mantenibilidad, 65 calibración, 415
464 ÍNDICE

calidad: bases del diseño de, 438


desplegado funcional (QFD), 165 control de, 441
ingeniería, 162 definición de, 38, 228, 438-439
planeación, 165 plan de, 290-291
requerimientos, 436 construcción, 88
calificación: contrato a precio fijo (FFP), 362
ambiental, 81 contrato a precio fijo con escalación,
confiabilidad, 81, 119 362
prueba, 80 contrato a precio fijo con incentivos
cambio: (FN), 362
clases de, 229 contrato de costo compartido, 363
pánel de control de, (CCB), 231 contrato de costo más pago de
capacidad de prueba, 434 incentivos (CPIF), 363
características de liderazgo, 335-336 contrato de costo más pago fijo
categorías, prueba y evaluación, 80 (CPFF), 362-363
ciclo de vida: contrato:
costo, 25, 168,441-442 de estructuras, 439
fases de, 22 de negociaciones, 361
pasos del análisis de costo, 172, 379 de pago de incentivos-penalizacio-
sistema, 21-22 nes, 364
software, 156 estructura de descomposición del
clasificaciones de trabajo, 104 trabajo (WBS), 253-254
compatibilidad: tipos de, 361
de equipo de soporte, 81 control númerico (NC), 201
de programa de computadora, 81 costo, visibilidad de, 25
computacional(es): costo:
recursos, 148, 430 ciclo de vida (LCC), 25, 168
tecnología, 179 códigos contables, 284
concepto, mantenimiento y soporte, compromiso de, 26
49-50,55 diseño de (DTC), 168
conceptual(es): efectividad, 5, 23, 24, 25, 440
diseño, 3' "efecto de iceberg", 25-26
revisión del diseño, 222 estimación de relaciones (CERs),
sistemas, 30 281
confiabilidad: estimación, 281
"curva de bañera", 110 estructura de descomposición
definición de, 106, 444-445 (CBS), 169, 385, 439440
diagrama de block, 114-115 Ingeniería de, 166
FMECA 64, 119, 131 perfil, 390
mantenimiento centrado en la, proyección, 281
(RCM), 65,152 reporte, 286
modelado, 119,194 visibilidad, 25
plan de programación, 116 CPM red de programación, 269
relaciones componentes, 112 creación:
requerimientos, 17, 426-427 proceso de, 437
trabajos de programación, 117 sistema de, 27
configuración del administrador:
ÍNDICE 465

E
datos: efectividad:
necesidades, 72 costo, 23-25
requerimientos, 415-416 elementos de, 24
técnicos, 148 factores, 48, 56, 410
decisión de comprarlo o hacerlo, 96- sistema, 21, 440
97,350 empaque y montaje, 422-423
definiciones: entrenamiento, 147, 344
ingeniería de sistemas, 31-32 equipo de soporte:
sistemas, 28-29 compatibilidad, 81
definición de soporte logístico integra- requerimientos, 434
do (ILS), 441 especificaciones tipo "A", 95, 242
Departamento de Defensa, 31, 39 especificaciones, árbol de, 97, 262-263
descripción de posición, 343 especificaciones:
descripción de trabajo (SOW), 243, árbol de, 97, 264
304,353 desarrollo de, 94
desechado del sistema, 62, 416 formato, 100
diagramas de bloque: jerarquía de, 96
de confiabIlidad, 114 Tipo "A", 35, 95, 244, 411
funcional, 58 tipos, 37, 96
dibujos, 182 especificación de material (Type "E"),
diseño, bases del, 37, 227-228, 247, 438 95
diseño, optimlzación de, 69 estadísticas, distribuciones, 76, 92
diseño: estándar, 262
cambios, 227 estandarización, 430
características, 413-414 estructura de descomposición del
conceptual, 36 trabajo (WBS):
de costo de (DTC), 168, 440 beneficios de, 260
detalle, 36 contrato (CWBS), 253-254
dibujos, 182 definición de, 254, 445
disciplinas, 99-102 desarrollo de, 255
estación de trabajo de, 193 resumen de (SWBS), 254-255
herramientas, 179 estructura de organización matricial,
notificación de cambio de (DCN), 315
232 evaluación e importancia, parámetros
optimización, de, 72
planes, 291 evaluación:
prácticas convencionales, 180 de alternativas, 71
proceso, 36, 174, 181 parámetros de, 70
red de comunicaciones, 185 sistema, 79
revisión de, 37, 210, 440 técnicas de, 73
sistema preliminar, 36
disponibilidad, 128
distribuciones estadísticas (SPC), 162 F
facilidades:
prueba, 85
466 ÍNDICE

requerimientos, 417-418
factibilidad económica, 417
factores antropométricos, 135 Identificación de necesidades, 43-44
factores de importancia, 171 Incertidumbre, 76
factores humanos: ingeniería concurrente, 39,164-165,
definición de, 135 440-441
pian de programación, 138 Ingeniería de sistemas:
requerimientos, 140, 419-420, 441 documentación, 253
trabajos de programación, 140 en el ciclo de vida, 34
factores sicológicos, 137 Influencia en el diseño, 313
fallas: Integración de planes, 289-290
cotización, 48, 107, 109, 110 Introducción a, 11
modo, efecto y análisis crítico pian de administración (SEMP), 35-
(FMECA), 64, 119, 131, 189 37, 239-240, 297-298, 412-413
sistema de reporte de, análisis y necesidad para, 28
acciones corregidas organización, 303, 319-320
(FRACAS), 116 planeación, 235
fuerza de trabajo y personal, 147 proceso, 43
función, 63 requerimientos de programación,
funcional(es): 238
análisis, 57, 410-411 trabajos de programación, 246
diagramas de flujo, 61 Ingeniería devaluación, 166
estructura de organización, 309 ingeniería:
calidad, 162
clasificaciones de trabajo, 104
concurrente, 39, 164
confiabilidad, 105
gráfica de planeación con indicadores, costo, 166
267 disciplina de diseño, 99
gráfica de programación de Gantt, 279- factores humanos, 135
280 logístico, 146, 153, 203
gráfica inicial de especificación de mantenibilidad, 199-120
intercambios (IGES), 187 producibilidad, 158
programación, 155,430
propuesta de cambio de (ECP), 229
H seguridad, 143
sistema, 31
Herberg, F., 339 inteligencia artificial, 204
horas-hombre promedio para mante- írlesgo, reducción del, 293-294
nimiento correctivo (MMHc), lazo de retroalimentación, 36
127 licitación para hacer una oferta (IFB),
humanos: 254,352
factores de sensibilidad, 136 logística:
recursos, 332 análisis de soporte (LSA), 65, 149,
203-204
CALS, 79-80, 202-203
de negocios, 154-155
definición de, 146
ÍNDICE 467

elementos de, 56, 146 medida de desempeño técnico (TPM),


Ingeniería de, 154, 203 72, 99, 213, 223, 288, 293, 444
modelos de, 195 mejora continua, 89
trabajos de programación de misión, pérfil de la, 47
soporte de, 151 mista:
de produclbilidad, 163
para revisión de diseño, 218, 407
modelo de cascada (software), 159
modelos:
manejo, 418-419 aplicación de, 75
mantenibilidad, demostración de, 81 confiabIlidad, 112
mantenibilidad: descripción de, 194
análisis, 131 selección de, 73
definición de, 880, 442 motivación, 337-338
demostración de, 81, 131, 133 movilidad, 421
distribución de, 124 Myers, M. S., 340
modelado de, 131, 195
plan de programa de, 130
requerimientos, 132, 419-420 R'1
trabajos de programación, 132
mantenimiento correctivo, 121 necesidades individuales (persona-
mantenimiento de productividad total les), 337
('rPM), 40 necesidades, identificación de, 43-44
mantenimiento en depósito, 53 necesidades, jerarquía de, 338
mantenimiento intermedio, 52 notificación de cambio de dibujo
mantenimiento organizacional, 52 (DCN), 183
mantenimiento preventivo, 121
mantenimiento:
análisis de trabajos de, 397 i]
correctivo, 121
en depósito, 53 operabilidad, 421
enfocado a la confiabilidad (RCM), operacional, perfil, 47
152 operacional:
frecuencia, 111 ciclo de vida, 48
funciones, 63 diagrama de secuencia (OSD), 65,
Intermedio, 52 141
niveles de, 50, 52, 54 distribución, 47
organizacional, 52 funciones, 63
planeación, 148 perfil, 47
preventivo, 121 uso del sistema, 88
proveedor de, 53 organización del consumidor, 306-307
tiempos, 121 organización del productor, 307-308
y soporte, 38-39, 204 organización:
manufactura Integrada por ambiente, 333-334
computadora (CM), 201 asesorando a la, 341-342
Maslow, A. H., 335 características de liderazgo, 335-
McGregor, D., 334 336
468 ÍNDICE

consumidor, 306-307 programación de mantenimiento,


estructura funcional, 309 130
estructura matriclal, 315 seguridad dei sistema, 143
Ingeniería de sistemas, 303, 319-320 soporte logístico integrado (ILSP),
Integración con CWBS, 261 154, 291-292
interfaces de consumidor-produc- plan:
tor-proveedor, 305 con gráficas de barras, 267
interfaces, 241 de gráfica de Gantt, 45
línea del producto/estructura de desarrollo de, 265
proyecto, 313 gráfica con indicadores, 266
productor, 307-308 línea de balance (LOB), 280
proveedor, 328 red de programación (PERT/CPM),
responsabilidad y autoridad, 334 267
red-costo, 279
planeación:
P ingeniería de sistemas, 235
necesidades para, 235
pánel de despliegue y controles, 423- planes, integración de, 289-290
424 políticas de reparación, 53
personal: políticas de reparación, 653
desarrollo de, 344 preparación para prueba de evalua-
entrenamiento de, 424425 ción, 83-84
prueba y evaluación, 81, 141 proceso:
Plan de la red PERT, 269 especificación (Tipo "D"), 95
plan de incentivos-penalizaciones, 366 Ingeniería de sistemas, 43
plan de soporte logístico integrado planeación, 201
(ILSP), 117, 154, 291-292 producción-construcción, 88
plan maestro de prueba y evaluación producibilidad:
(TEMP), 35, 37, 82-83, 120, 445 definición de, 158, 442
plan: lista de, 163
administración de Ingeniería de plan de, 160
sistemas (SEMP), 35, 241, 298 requerimientos de, 161, 425-426
administración de la configuración, producto:
290-291 especificación (Tipo "C"), 95
administración de programación especificación de intercambio de
(PMP), 240 datos, (PDES), 187
administración de riesgo, 292 programación con gráfica de barras,
calidad, 128, 165, 292 267
confiabilidad del programa, 84 programación de línea de balance
para especialidades de diseño, 289 (LOB), 280
patrón de prueba y evaluación propuestas:
(TEMP), 35, 82-83, 116, 245- criterios de evaluación, 357
246,291 desarrollo de, 354
producción-manufactura, 292 proveedor, 352
producibilidad, 160 proveedor:
programa de computadora, 157 interfaces, 241
programación de factores huma- monitoreo y control, 368
nos, 138 organización, 325
ÍNDICE 469

propuestas, 354 revisiones:


requerimientos, 350, 412 día por día, 214
selección, 352 diseño formato, 37, 210
proyecto: revisión de diseño crítico, 37, 225-226
estructura organizacional, 313 revisión de diseño de equipo, 37, 225
planeación, 265 revisión de diseño:
prueba, procedimiento de, 84 lista de, 218, 407
prueba: pánel de (DRB), 220
calificación, 81 procedimiento de, 215
categorías de, 80 riesgo:
confiabilidad, 119 identificación de, 76
desempeño, 85 plan de administración de, 293, 443
equipo de soporte, 84, 147 robótica, 201-202
facilidades, 85
mantenibilidad, 131
personal, 141 s
planeación, 82
preparación de, 83 seguridad:
programas de computadora, 157 definición de, 143
selección de lugar, 84 plan de programación, 145
requerimientos, 144, 427-428
trabajos de programación, 144
R servicio y lubricación, 429
sistema de soportes, 88-89
RAMCAD, 200 sistema hechos por el hombre, 30
reconfigurable, 426 sistema, ciencia de, 33
redundancia, 113 sistema, modificaciones del, 87
requerimientos de desempeño, 4748, sistema, síntesis del, 69, 444
442 sistema:
requerimientos de programación, 237- adquisición, 27
239 análisis de factibilidad, 35, 44
requerimientos ecológicos, 416 análisis funcional, 57
requerimientos: análisis, 33, 443
de distribución, 67 ciclo de vida, 21
desempeño, 46 ciencia, 33
diseño, 93 definición de, 28,443
efectividad, 48, 56 efectividad, 23, 440
hoja de distribución (RAS), 250 evaluación, estados de, 79
operacionales, 46 ingeniería de, 28, 31, 443
programación, 350 Ingeniería y análisis de, 23
recursos humanos, 332 Integración, 290, 371-374
utilización, 48 modificaciones, 87
responsabilidad: procedimientos de control de
organizacional, 56 cambio, 230
y autoridad, 334 proceso de requerimientos,
Resumen de estructura de descompo- evaluación, y revisión, 38
sición del trabajo (SWBS), 254 requerimientos de diseño, 94
retiro, 89 requerimientos operacionales, 35,
46
470 ÍNDICE

retiro y desecho, 89 tiempo promedio entre fallas (MTBF),


revisión de diseño, 37, 224 48,106
soporte, 88, 154 tiempo promedio entre mantenimien-
uso operacional, 88 tos (MtbM), 48,128
sistemas de lazo abierto, 31 tiempo promedio entre reemplazos
sistemas de lazo cerrado, 31 (MTBR), 128
sistemas dinámicos, 30 tiempo promedio entre reparaciones
sistemas estáticos, 30 (MTTR), 125
sistemas físicos, 30 tiempo promedio para mantenimiento
sistemas naturales, 30 (MDT), 48, 123
sistemas, categorías de, 30,240 tiempo promedio para mantenimiento
sistemas, integración de, 289, 371-374 correctivo (Mct), 123-124
sobrevlvencia, 434 tiempo promedio para mantenimiento
Sociedad de Ingenieros en Logística preventivo (Mpt), 26
(SOLE), 146 tiempo promedio para que ocurra una
software: falla (MTTF), 106
ciclo de vida, 156 tiempo:
ingeniería, 155 mantenimiento, 121
planeación, 157 relaciones, 122
requerimientos, 157, 430 trabajos:
revisión del diseño, 225 Ingeniería de sistemas, 246-247
solicitud de propuesta (RFP), 254, 308, programación de confiabilidad, 117
352 programación de factores huma-
soportabllidad, 149, 431-435, 443 nos, 140
soporte de suministros, 85, 147 programación de mantenibilidad,
sujetadores, 418 132
programación de soporte logístico,
151
T transportabilidad, 435-436

tiempo de retraso administrativo


(ÁDT), 123 11
tiempo de retraso logístico (LD1'), 123
tiempo máximo activo antes de utilización de Requerimientos, 48
mantenimiento correctivo (M
Max), 125-126
tiempo mediano para mantenimiento vi
correctivo (Mct), 126
VECP, 171
Diferencias en la terminología
Estados Unidos España Latinoamérica

American National Instituto nacional Instituto nacional


Standards Institute americano de normali- americano de
ANSI zación estandarización
Array Matriz Arreglo
Back-up Copia de seguridad Copia de respaldo
Background Fondo Segundo plano
Board Tarjeta Tablero, tarjeta
Breakpoint Punto de parada Punto de paro
Button Pulsador Botón
CAM Fabricación asistida Manufactura asistida por
por computadora computadora
Command lenguaje Lenguaje de órdenes Lenguaje de comandos
Computer Ordenador Computadora
Data base management Sistema de gestión de Sistema manejador
systems base de datos de base de datos
Driver Controlador Manejador, controlador
Failure Avería Falla
Feedback Realimentación Retroalimentación
File Fichero Archivo
Floppy disk drive Unidad de disco flexible Unidad de disquete
Frame Imagen Marco
Gate, port Puerta Compuerta
Graphics Gráficos Gráficas
Handling Manipulación Manejo
Heading Encabezamientos Encabezados
Light pen Lápiz óptico Pluma óptica
Link Enlace Liga
Log Registrar Bitácora
Loop Bucle, lazo Lazo
Password Palabra de paso Contraseña
Fin Patilla Patita
Pointer Puntero Apuntador
Row Fila Renglón
Satement Sentencia Instrucción
Slash Barra inclinada Diagonal
Status Estado Estatus
Utility Utilidad Utileria
Glosario de Términos MEGABYTE
A appllcatlon: aplicación. autoination: automatización.
appllcatlon program: programa automaton: autómata.
abacu8: ábaco. de aplicación. auxillary memory: memoria auxi-
abnormal termination: termina- appllcatlon software: programas liar.
ción anormal. de aplicación, software de apli-
abort: abortar, interrumpir. cación.
absolute address: dirección ab- appllcatlons programmer: pro-
soluta. gramador de aplicaciones.
absolute addresslng: direccio- a progranunlng language (APL): background: segundo plano.
namiento absoluto. lenguaje de programación APL. background activity: actividad
absolute value: valor absoluto. architecture: arquitectura. subordinada o de baja priori-
access: acceso. archive: archivo. dad.
acceas time: tiempo de acceso. argument: argumento. backspace: retroceso.
accuracy: factor de precisión o de arlthmetic operator: operador back-up: copia de seguridad, co-
exactitud. aritmético. pia de respaldo.
acknowledge: reconocimiento, arlthznetic shlft: desplazamiento bar code: código de barras,
respuesta afirmativa. aritmético. diagramas de barras.
acoustic coupler: acoplador acús- array: "array" arreglo. base address: dirección de base,
tico. array procesaor: procesador so- dirección base.
active element: elemento activo. bre arreglos. batch: lote (tren) de trabajos.
actual paraineter: parámetro ac- arrowkeys: teclas de movimiento battery: pila, batería.
tual. del cursor. baud: baudio (bit/segundo).
add: sumar. artificial lntelllgence: inteligen- benchnsark: trabajo normalizado
addltlon: suma. cia artificial. para computadoras, programa
add-on: adicional, expansión. ASCII: ASCCI, código ASCII. de prueba.
address: dirección. asaembler language: lenguaje bidirectional: bidireccional.
address bus: bus de direcciones. ensamblador. bldlrectlonal priMer: impresora
address tormat: formato de direc- asslgn: asignar. bidireccional.
ciones. asaigument: asignación. binary: binario.
address&ng: direccionamiento. asslgnment operator: operador de binary base: base binaria, base 2.
algorlthzn: algoritmo. asignación. binary language: lenguaje binario.
allocate: asignar. asynchronous: asíncrono. binary number: número binario.
al¡-purpose computer: compu- attenuatlon: atenuación. binary seas-ch: búsqueda binaria,
tadora de propósito general. auto-anawer: respuesta automá- búsqueda dicotómica.
alphabetic character: carácter tica. blonlcs: biónica.
alfabético. autocode: autocódigo. bipolar: bipolar.
alphanumeric: alfanumérico. automata theory: teoría de autó- blatable: biestable.
analog: analógico. matas. bit: bit.
analog Lo digital converter con- automatic codlng: codificación bit denalty: densidad de bits.
vertidor analógico-digital. automática. bits per lnch (BPI): bits por pul-
analyser/analyzer: analizador. automática, Informática. gada.
analysis: análisis. automatic lnterrupt: interrupción blankspaces: espacios en blanco.
analyst: analista. automática. blanklng: borrado, puesta a cero.
ANSI: Instituto nacional america- automatic request: petición auto- blinking: parpadeo, destello, cen-
no de estandarización, ANSI. mática de repetición. telleo.
append: añadir.
Glosario de Términos MEGABYTE

block: bloque, paquete. cache: memoria inmediata, closed-loop: bucle bloqueado, in-
block diagrani diagrama de blo- "cache". finito, sin fin; bucle o lazo ce-
ques. CAD: diseño asistido por rrado.
board: tarjeta, placa. computadora, CAD. closed subroutlne: subrutina ce-
boolean algebra: álgebra CAD/CAM: diseño asistido por nada.
booleana. computadora/manufactura code: código.
boolean loglc: lógica booleana, (fabricación) asistida por CODEC: codificador-decodifi-
lógica de Boole. computadora, CAD/CAM. cador.
boot: carga inicial, autocarga. CAE: educación asistida por cold-.tart: arranque en frío.
booting: carga inicial, autocarga. computadora, CAE. column: columna.
boot-load: carga Inicial. CAL enseñanza asistida por command: orden, comando.
horder: magen, lateral, marco, computadora, CAl. command language: lenguaje de
contorno. calculus: cálculo. órdenes.
borrow acarreo negativo, arras- calculator: calculadora. comnient field: campo comenta-
tre negativo, toma. cali: llamada, invocación. rio (o "del comentario", o "para
bounce: rebotar, rebote. cali routine (subroutlue): el comentario"),
bouncing: rebote. subrutina (subprograma) de communlcatlon link: enlace (liga)
bounds: límites, fronteras. llamada. de comunicaciones.
BPS: bits por segundo. calling sequence: secuencia de compatlbllity: compatibilidad.
branch: bifurcación, ramificación, llamada. compile: compilar.
salto. CAM: memoria direccionable por compiler compilador.
break: ruptura, suspensión tem- el contenido, CAM. complete status: estado, estatus
poral, interrupción. canal: canal. "completado".
breakpolnt: punto de paro, punto capture: captura. components: componentes.
de parada, punto de interrup- card: tarjeta, tablero. computation: cálculo, cómpuyo,
ción. carriage return: retorno de carro, computación.
bubble memory: memoria de bur- vuelta de carro, cambio de computer computadora, compu-
buja. línea. tador, ordenador.
bubble sort: ordenación por el carrier portadora. computer network: red de
método de la burbuja. carry: acarreo, arrastre. computadoras.
bulTer memoria intermedia, adap- cartrldge: cartucho. computer program: programa
tador, circuito tampón, ampli- cassette: casete. para computadoras. -
ficador, separador, memoria, cassette recorder grabadora de computer science: informática,
tampón, memoria tampón, casete. ciencia de las computadoras.
"buffer". cathode ray tube (CRT): tubo de computer system: sistema
buffering: separación, almace- rayos catódicos CRT). informático, sistema de
namiento temporal, memoria ceil: celda. computadora.
intermedia. central processlng unit (CPU): computervendor distribuidor de
bug: error, error en un programa, unidad central de procesa- computadoras.
"bug". miento (tratamiento), CPU, computing: cálculo, utilización de
bump: memoria anexa. UCP. computadoras para tratamien-
bus: bus, vía, barra, cable(s) de Centrouics interface: interfaz to de datos, cómputo, compu-
Interconexión. Centronics, interfaz, paralelo tación.
buzzwords: terminología informá- estándar. concatenation: concatenación.
tica. circuit: circuito. concurrence: concurrencia.
byte: byte, octeto. circular queue: cola circular, concurrent proceases: procesos
bytes per lnch (BPI): bytes por puesta en cola circular. concurrentes.
pulgada. clear: puesta a cero; borrar, lim- condition code: código de condi-
piar. ción, código de estado.
clear screen: borrar pantalla. condillonal cali: llamada condi-
C clock: reloj, generador de impul- cional.
sos. configure: configurar.
cable televislon: televisión por clock frequency: frecuencia de conneci time: tiempo o duración
cable. reloj. de conexión.
close: cerrar, cierre. console: consola.
Glosario de Términos MEGABYTE

condant: constante. charactera por aecond (CPS): ca- deadiock: lnterbloqueo, bloqueo.
control character: carácter de racteres por segundo. debug: depurar, corregir errores.
control. chart: diagrama, gráfico, carta. decibel: decibelio.
control key: tecla de control. check: comprobación, verifica- decode:decodificar, descodificar.
control unit: unidad de control. ción, prueba. dedicated system sistema dedi-
controller: regulador, contro- check bit: bit de comprobación cado.
lador. o verificación. default parameter: parámetro
converter: convertidor, con- checkout: comprobación, verifi- implícito (por omisión), (por
versor. cación de resultados de sa- defecto).
core: núcleo. lida. delay: retraso, retardo.
counter: contador. checkpoint: punto de control delete: borrar, anular.
coupler. acopiador. o verificación. demand paging: petición de pági-
CPS (charactera per second): ca- checksum suma de verificación, nas de memoria.
racteres por segundo CPS. suma de control. denslty: densidad.
critica¡ resource: recurso crítico. chip: chip, pastilla, circuito inte- descriptor: descriptor.
crosabar system: sistema de ba- grado. desktop publishing: autoedición.
rras cruzadas. development tools: herramientas
crossfoot: sumar y(o) restar hori- de desarrollo.
zontalmente. pi device: dispositivo, unidad.
CRT: tubo de rayos catódicos. diagnostic: diagnóstico, diag-
crystal: cristal (cuarzo). daisy chain: cadena tipo marga- nosis.
CTRL key: tecla de control. rita. dlalect: dialecto.
current: corriente, flujo. daisy wheel: rueda de margarita. dial-up une: línea de red
current loop: lazo (bucle) de co- data acquisitlon: adquisición de conmutada.
rriente. datos, captura de datos. die: pastilla.
current status: estado (estatus) data base: base de datos. digital computer computadora
"en ejecución". data base management system digital.
cursor movement: desplazamien- (DBMS): sistema manejador digitlzer: digitalizador, digiti-
to del cursor. (de gestión) de base de datos zador.
cursor positionlng: posiciona- (DBMS). dlgitizer tabiet: tablero digitali-
miento del cursor. data bus: bus de datos. zador, tableta digitalizadora.
cyhernetica: cibernética. data ceil: celdade datos, célula de diode: diodo.
cycle: ciclo. datos. DIP: DIP, encapsulado de 2 en lí-
cycle time: ciclo de memoria, tiem- data communicatlon: comunica- nea o doble fila de patillas.
po de ciclo. ción de datos. direct acceso: acceso directo
data compression: compresión de o aleatorio.
datos. direct addressing: direccio-
CH data me: archivo (fichero) de da- namiento directo.
tos, archivo de datos. directory: directorio, catálogo.
chain printer: impresora de ca- data integrity: integridad de da- disable: inhibir, inhabilitar, des-
dena. tos, calidad de transmisión. conectar, desactivar.
chaining: encadenamiento. data link: liga (enlace) de comuni- disasaembler: desensamblar.
channel: canal. cación de datos. disk: disco, disco magnético.
character carácter. data pointer: puntero de datos, disk controller card: tarjeta
character alignment: alineación, apuntador de datos, enlace de controladora del disco.
ajuste o encuadre de carac- datos. disk drive: unidad de disco.
teres. data processlng: procesamiento disk ifie: archivo (fichero) de
character key: tecla de carácter. de datos, tratamiento de disco.
character set: juego de caracte- datos. diskette: disquete, disco flexible.
res, conjunto de caracteres. dala retrieval: recuperación de display: visualizador, pantalla,
character string: cadena de ca- datos. presentación,
racteres. data security: seguridad de los display rnode: modo de visua-
charactera por lnch (CPI): carac- datos. lización, de presentación.
teres por pulgada. data structure: estructura de documentation: documentación.
datos.
Glosario de Términos MEGABYTE

DOS (Dial Operatlng System): sis- empty statement: Instrucción falling edge: flanco descendente.
tema operativo de disco, DOS. (sentencia) vacía. family: familia.
dot matrix: matriz de puntos. emulate: emular, Imitar. fan-in: cargabilidad de entrada,
double density: doble densidad. emulation: emulación. abanico de entrada.
double prec isbn: doble precisión. emulalor. emulador. fan-out: cargabilidad de salida,
double-sided disk: disco de doble enable: habilitar, activar, permi- abanico de salida.
cara (lado). tir, poner en servicio. fatal error: error fatal.
doublestrlke: doble impresión. encapaulate: encapsular. fault-tolerant: tolerante a fallas.
drive: unidad, dispositivo. enclosure: cápsula, pastilla. feedback: re(tro)alimentación.
driver controlador, manejador. encode: codificar. ferrite core: núcleo de ferrita.
drum: tambor. encoder: codificador. fetch: lectura de instrucción.
dual density: doble densidad. end of file (EOF): (EOF): fin de fleld: campo.
dual-density diskette: disquete de archivo (fichero) (EOF). FIFO: primero en entrar-primero
doble densidad. endiesa loop: lazo (bucle) sin fin, en salir, cola de espera.
dumb terminal: terminal básico, infinito. file: fichero, archivo.
terminal no inteligente. energise: energizar, dar energía, file management system: sistema
duinmyvariable: variable ficticia, excitar. manejador (de gestión) de ar-
irrelevante, inoperante, no entry polut: punto de entrada. chivos (ficheros).
operativa. envlronment: entorno, ambiente. file name: nombre de archivo (fi-
dump: copia, volcado, vaciado, erasable memory: memoria chero).
descarga, volcar. borrable. file structure: estructura de fiche-
duplex: dúplex. erase: borrar, anular. ro, estructura de arhivo.
dynamic: dinámico. ergonomlc: ergonómico. firmware: firmware, memoria fija,
dynainic memory: memoria diná- error error. soporte lógico inalterable.
mica. error correction code: código de flxed-head disk: disco de cabezas
correción de errores. fijas.
error detedion code: código de flag: indicador, señalizador, ban-
E detección de errores. dera.
error handling: manipulación flag bit: bit indicador, bit
earth: tierra, masa. (manejo) de errores. señalizador.
echo: eco. error-measage: mensaje de error. fioating computlng: cálculo en
echoed characters: caracteres escape character: carácter de es- coma flotante (o punto flo-
con eco. cape. tante)_
edge trtggering: disparo por flan- even parity: paridad par. floating point: coma (punto) flo-
co, activación por flanco. excluslon: exclusión. tante.
edit: editar. execute: ejecutar. floppy disk: disco flexible,
edit code: código de edición. executbon: ejecución. disquete.
edit mode: modo de edición. executbon cycle: ciclo de ejecu- floppy disk drive: unidad de
editor: editor, editor de texto. ción, fase de ejecución. disquete (disco flexible).
EDP: procesamiento (tratamien- executlon time: tiempo de ejecu- flow-chart: diagrama de flujo, or-
to) electrónico de datos, EDP. ción. ganigrama.
electrode: electrodo. exercizer: sistema de comproba- flowlLne: línea de flujo, dirección
electromagnetic Interference: ción o chequeo. de flujo.
interferencia electromagné- exponent: exponente. fly.back: retorno.
tica. expression: expresión. foregroundz primer plano, primer
electron: electrón. extensiblllty: ampliación. término.
electron beam: haz de elec- extensbon board: tarjeta de am- foreground color: color del pri-
trones. pliación. mer plano.
eletronlc data processlng: EDP. external lnten-upt: interrupción formal parameter: parámetro
elec ronlc mal!: correo electró- externa. formal.
nico. format: formato, organizar
eledronlcs electrónica. formatos, definir formatos.
electrodatic: electrostático. F format type: tipo de formato, cin-
electrodatic printer: impresora ta piloto (o maestro).
electrostática. fall back: estado (situación) de formattlng: organización de
emergencia, caída. formatos, preparación de
formatos.
Glosario de Términos MEGABYTE

forward error correction: correc- halt: detención, parada, interrup-


illegal instructlon: instrucción
ción anticipada de errores. ción. ilegal.
fragmentation: fragmentación. handier manipulador. lmmediate addreas: dirección in-
frame: elemento, imagen, marco. handahaklng: protocolo de inter-
mediata.
free-nm: ejecución libre. cambio, diálogo, lmpact printer impresora de im-
frenquency: frecuencia. hard copy: copia permanente,
pacto.
frequency.ahlft keylng: FSK. copla Impresa. lnch: pulgada.
front-end proceasor procesador hard disk: disco rígido, disco duro,
in-circuit emulation: emulación
frontal. disco fijo. en circuito.
front panel: pánel frontal. hardware: "hardware", material.
increment: incremento.
fuil duplex: bidireccional, fuil- hard-wired: cableado. index: índice.
dúplex, dúplex simultáneo. hannonic: armónico. index reglater: registro índice.
fuli *creen: pantalla llena, panta- Indexed: indexado.
hash: ruido, información parási-
lla completa. ta, "hash". ludexed address: dirección
function: función. hashing: cálculo de clave (llave).
indexada.
functional progranimlng: progra- hazardous envlronment: ambien-
indexed sequential acceas: acce-
mación funcional. te peligroso. so secuencial indexado.
fundamental: fundamental. head craah: rotura de cabeza, frac-
indexing: indexación.
tura de cabeza. indlrect: indirecto.
head disk: cabeza de disco.
indlrect mode: modo indirecto.
G heading: encabezado, encabeza-
information retrieval: recupera-
miento. ción de información.
gala: ganancia. heap: pila, montón. information aystem sistema de
game: juego. help menu: menú de ayuda. información.
game controla: controles para hertz: herzio, herz, hercio.
mfra-red: infrarrojos (rayos).
juegos. heuristic: heurística. inherent address: dirección im-
game paddle: paleta de juego. hex, hexadecimal: hexadecimal.
plícita.
gap: intervalo separación, hexadecimal notation: notación
initlalization: inicialización.
banda. hexadecimal. initialize: Inicializar.
garbage: información no válida. high addreas: dirección alta.
ink Jet: chorro de tinta.
gate: puerta, compuerta, circuito high-level language: lenguaje de
lnk-jetprinter: impresora por cho-
lógico elemental. alto nivel, lenguaje evolucio-
rro de tinta.
general-purpose computer: nado. Inner: interno.
computadora de propósito high resolution: alta resolución.
inner memory: memoria interna.
general, computadora de uso hlgh-resolutiongraphlcs: gráficos
input: entrada.
general. de alta resolución. Input device: dispositivo de en-
generating program generador hlghway: bus. trada.
de programas. input-output (I/O): entrada-salida
hobby computer computadora
gigabyte: gigabyte, gigaocteto. de aficionados. (E/S)_
glltch: ruido, interferencia, hold: mantener, contener, rete-
input perlpheral: periférico de
es pú reo. ner. entrada.
global variable: variable global. hold down: mantener (una tecla)
insert: insertar.
gloe.ary: glosario. pulsada. integer entero.
graznmar: gramática. hold time: tiempo de retención
lntegerarlthmetic: aritmética con
grammar rule: regla gramatical. o fijación enteros.
graph: grafo. host computer: computadora cen-
integer math: software de núme-
graphics gráficos. tral, computadora principal.
ros enteros.
graphlcs tablet: tablero gráfico. hybrid computer. computadora
Integrated drcult: circuito inte-
ground: masa, tierra. híbrida. grado.
tntelllgent terminal: terminal in-
teligente.
-a- interactive processing: procesa-
miento interactivo, tratarnien-
halt-dupiex: "haif-duplex", IC (lntegrated Circult): circuito to interactivo.
semldúplex. integrado. Interactive program programa
half..plitttng: división por mi- identifier: identificador. interactivo.
tades.
Glosario de Términos MEGABYTE

interblock gap: espacio entre blo- keypunch: perforadora. llbrary: biblioteca, librería.
ques. kilo: mil. llbrary ifie: archivo (fichero) de
Interface: interfaz, Interfase, kilobyte: "kilobyte", ldloocteto. biblioteca.
"interface". kips: kiloinstrucciones por se- UFO: LIFO.
interlace: entralazar, concatenar. gundo. light emlttlng diode (LED): diodo
interleaving: Intercalación kit: kit. emisor de luz (LEO).
Interlock: protección, bloqueo. llght pea: lápiz óptico, lápiz lumi-
Interna¡ memory: memoria in- noso.
terna. L Une delay: línea de retardo.
interna¡ timer: temporizador Une feed: avance de línea.
o reloj Interno. label: rótulo, etiqueta. une prInter. Impresora por líneas.
Lnternetworking: Interconexión lace: perforación en cadena. link: liga, enlace, encadena-
de redes. laced card: tarjeta perforada. miento.
interpreter: intérprete. lag: retardo. link edltor editor de ligas (en-
Interrogate:interrogar, consultar. landing: cableado interno. laces).
interrupt: Interrupción. language: lenguaje. Ilquid crystal display: visua-
interrupt mask: máscara de inte- language character set: conjunto lizador de cristal líquido.
rrupciones. de caracteres del lenguaje. llst: lista.
lnvalldlnMrudlon: instrucción no large acale Integration (LSI): inte- listlng: listado.
válida. gración a gran escala (LSD. literal: literal.
Inverter: Inversión. laser: láser, amplificador de luz load: cargar, carga.
I/O: E/S, entrada/salida. mediante emisión estimulada loader cargador, programa car-
I/O channel: canal de EIS. de radiación. gador.
ltem artículo, elemento, ítem. laser disk: disco láser. Ioadlng program: programa de
Iterate: iterar. laser printer impresora láser. carga.
lteratlon: iteración last-in first-out (LIFO): último en local variable: variable local.
lteratlon loop: lazo (bucle) de entrar-primero en salir (LIFO). location: posición, dirección de
iteración, ciclo iterativo. Iatency: espera, cadencia. celda de memoria.
Iterative: iterativo. layout: diseño, esquema. lock: bloqueo.
LCD: visualizador de cristal líqui- lock-out: inhibición de un siste-
do, LCD. ma, bloqueo.
J lead: cable conductor, conduc- iog: registrar, bitácora.
ción eléctrica, avance, adelan- loglc: lógica.
jack: enchufe. to, primer lugar. loglc card: tarjeta o placa lógica.
Job: trabajo, encargo, tarea. leading edge: flanco ascendente, loglc circuit: circuito lógico.
Job queulng: cola de trabajos. flanco de subida, flanco ante- loglc design: diseño lógico.
Job string: cadena de trabajos. rior. loglc pulser: generador de impul-
joystick: palanca de control, bas- leadlng zero: cero a la izquierda sos, generador lógico, reloj.
tón de control, palanca de o no significativo. logic shift: desplazamiento ló-
mando, "oystick". learning curve: curva de aprendi- gico.
jump: salto, bifurcación. zaje. logical expresaba: expresión ló-
justification: justificación, leaN slgnhflcant bit (138): bit gica.
encuadramiento, ajuste, colo- menos significativo (LSB). logical operator: operador ló-
cación de márgenes. LED: diodo LED, LED. gico.
ieft-justlflcatlon: justificación a la log-in: entrada de identificación.
izquierda, encuadre a la iz- log-on: identificación, identifi-
IA quierda o bien, alineación a la carse.
izquierda. look ahead: adelantamiento, anti-
K: k, kilo. letter quallty: calidad de letra. cipación.
kernel: núcleo. letter quality printer: impresora look-up: buscar, consultar.
key: tecla, llave, clave. de alta calidad de escritura. look-up table: tabla de consulta
key word: palabra clave, palabra level: nivel. o de búsqueda.
reservada. lexical: léxico, lexical. loop: bucle, laso, ciclo.
keyboard: teclado lexical analyzer: analizador de loop counter: contador de bucles
keypad: teclado numérico, léxico. o lazos.
numerlc pad. librarlan: bibliotecario. looping: realizar lazos, realizar
bucles.
Glosario de Términos MEGABYTE

low: bajo, inferior. procesador maestro, proce- MIPS: MIPS, millones de instruc-
low-bit: bit bajo, bit Inferior, bit sador principal. ciones por segundo.
de menor peso. master-.lave: maestro-esclavo. misteed:pérdida de alimentación,
loweiaae: minúscula, caja baja. match: superponer, aparear. fallo de alimentación.
lower-case letterE letras minús- maiching: selección por compa- mistake: error, equivocación.
culas. ración, superposición. mnemonlc: nemotécnico.
Iow-level language: lenguaje de matrix: matriz. mnemonlc code: código nemo-
bajo nivel. matrix character: carácter técnico.
low-resolution: baja resolución. matricial. mode: modo.
low-resolution graphlcs: gráficos matrix memory: memoria de ma- modem: módem, modulador-
de baja resolución. trices. demodulador.
LPM: líneas por minuto. matrix printer: Impresora de agu- monitor monitor, supervisor.
LPS: líneas por segundo. jas, impresora matricial, monolithic: monolítico.
LSB: bit/byte menos significativo. impresora por puntos. mostsignlflcant bit (MSB): bit más
LSI: integración a gran escala. medlum: medio. significativo.
1SF: lógica LST. medium scale lntegratlon (MSl: motherboard: placa base, placa
LSTFL: lógica LSTTL. integración a media escala matriz.
(MSI). move: transferir, desplazar.
mega: mega. moving head dial: disco de cabe-
M megabyte: megabyte, megaocteto. za móvil.
megahertz: megahercio. MS-DOS: sistema operativo
M: M, mega. memory: memoria. MS-DOS.
machine: máquina. memory addreas: dirección de MSI: integración a media escala.
machine code: código de máqui- memoria. multi-accesa: multiacceso, acce-
na, código máquina. memory addresslng: direccio- so múltiple.
machine language: lenguaje de namiento de memoria. multllayer: mu Iticapa.
máquina, lenguaje máquina. memoryallocation: asignación de multipiex: multiplexar.
macro: macro. memoria. multiplexer: multiplexor, mul-
macroprogrammlng: macro- memory cell: celda de memoria. tiplexador, "multiplexer"
programación. memory dump: copia, volcado multiprocessing: multiprocesa-
magnetic bubble: burbuja mag- o vaciado de memoria. miento, multitratamiento.
nética. memory management: adminis- multiprogrammlng: multipro-
magnetic card: tarjeta magnética. tración (gestión) de memoria. gramación.
magnetic disk: disco magnético. memory syze: capacidad, tamaño multitask: multitarea.
magnetic tape unu: unidad de cin- de memoria. multluser multiusuario.
ta magnética. memory wrlte: escritura de me- mustcsyntheslzer sintetizador de
mall-box: buzón. moria. música.
mailing: correo, lista de direc- menu: menú. MVT: multiprogramación con nú-
ciones. merge: fusión, fusionar, mezclar. mero variable de particiones.
mainframe: computadora central, merging: fusión, mezcla. mutual exciusion: exclusión
computadora grande, main- messages mensajes. mutua.
frame. micro: micro. mux: multiplexor.
main memory: memoria princi- microcode: microcódigo.
pal. microcomputer: microcompu-
maintenance: mantenimiento. tadora. N
malfunctlon routine: rutina para mllisecond: milisegundo.
detección de fallas. mlllions of instructions per nanosecond: nanosegundo, lQ
mask: máscara. second (MIPS): millones de segundos.
maskable interrupt: Interrupción Instrucciones por segundo negation: negación.
enmascarable. (MIPS). nesi: anidar.
masa memory: memoria masiva, minicomputer: mínicompu- nested subroutine: subrutina ani-
memoria de masa. tadora. dada.
master file: archivo (fichero) mini-dial: minidisco. network: red.
maestro, fichero permanente. minus flag: indicador de signo networklng: realización de redes.
master procesaor:unidad central, negativo. nlbble: cuaterna, cuarteto,
"nibble".
Glosario de Términos MEGAB

noise: ruido. operator operador. parser: analizador sintáctico.


non-pm: no-patita, no-patilla, "no- optical character recognition parsing procedure: procedimien-
pm". (OCR): reconocImIento óptico to de análisis sintáctico.
non removable disk: disco fijo. de caracteres. (OCR). partition: partición.
non resident: no residente. opthnlzatlon: optimizar. password:contraseña, palabrade
non-terminala: no-terminales. optlmlze: optimizar. paso.
non-volatile memory: memoria no output: salida. PC: computadora personal.
volátil. output enable: habilitación o acti- PC: circuito impreso.
null detector detector de cero. vación de la salida. PC: contador de programa.
mili instruction: instrucción nula. output peripheral: periférico de PCB: tarjeta de circuito impreso.
nuil string: cadena vacía. salida. PC board: tarjeta o placa de cir-
number notation: flotación, repre- overflow: desbordamiento, cuito impreso.
sentación numérica, sobrepasamiento, rebose. performances: prestaciones.
numeric character: carácter nu- overhead bit: bit suplementario. peripheral: periférico.
mérico. overlapped processlng: procesa- peripheral device: periférico
numeric codlng: codificación nu- miento simultáneo, super- o dispositivo periférico.
mérica. puesto. permanent file: archivo (fichero)
numeric keypad: teclado numé- overlay: solapamiento, superpo- permanente.
rico. sición, recubrimiento. personal computer (PC):
numeric pad: teclado numérico. overload: sobrecarga. computadora personal (CP),
numerical analysis: análisis nu- overwrite: reescritura. "PC".
mérico. pLane: fase
numerical calculus: cálculo nu- physical ground: tierra.
mérico. PIA: adaptador de interfaz para
periféricos.
pack: paquete, empaquetar. picosecoud: picosegundo, 10-12
Li] package: cápsula, paquete; empa- segundos.
quetar, encapsular. picture element: elemento de una
object: objeto. packet switching: conmutación de imagen digital, "pixel".
object code: código objeto. paquetes. pm: patita, patilla, terminal, 'pi ".
object file: archivo (fichero) ob- packing denaity: densidad de re- pipeline structure: estructura
jeto. gistro. tubular, "pipeline".
object language: lenguaje objeto. pad character: carácter de re- pixel: elemento de una imagen
OCR: reconocimiento óptico de lleno. digital, pixel, punto.
caracteres. paddles: mandos de control, plotter registrador de gráficos,
octal: octal. "paddles". trazador de gráficos, ploter.
odd parity: paridad impar. page: página. plugboard: tarjeta impresa.
off-line: fuera de línea, desconec- page printer: impresora por pá- plug-in unit: unidad enchufable.
tado, autónomo. ginas. pocket calculator: calculadora de
on-"e: en línea, conectado. paged allocation: asignación pa- bolsillo, portátil.
on-line atorage: memoria conec- ginada. pointer: puntero, apuntador.
tada, en línea. paging: paginación. polling: escrutinio, sondeo.
on-line system: sistema en línea. paper tape: cinta de papel perfo- pop: extraer, sacar, subir, re-
one's complement: complemen- rada. montar.
to a uno. parallel: paralelo. port: puerto, puerta, entrada, ac-
op-code: código de operación. parallel interface: interfaz para- ceso, punto o zona de acceso
open: abrir, abierto. lelo. (entrada), "port".
open loop: lazo abierto. parallel processing: procesamien- portabllity: portabilidad,
open subroutine: subrutina to en paralelo. transportabilidad.
abierta. parallel transmision: transmisión position: posición, celda.
operand: operando. en paralelo. positive logic: lógica positiva.
operating system: sistema paraUelism paralelismo. power: alimentación, potencia.
operativo. parameter: parámetro. power fail restart: restauración
operation: operación. parity: paridad. del fallo de la alimentación.
operation code: código de opera- parity bit: bit de paridad. power-on: encendido, puesta en
ción. parity error: error de paridad. marcha.
Glosario de Términos MEGABYTE

power supply: fuente de alimen- punched card: tarjeta perforada. record lenght: longitud de re-
tación. push: introducir, meter, cargar. gistro.
power-up: encendido, puesta en push-down: desplazamiento recovery: recuperación.
marcha. descendente, pulsación. recurrence: recurrencia.
precedence: prioridad, prece- push-down ilat: lista de elemen- recurslon: recurrencia, recur-
dencia. tos de una pila. sividad.
precislon: precisión. push-down stack: pila. recursive: recurrente, recursivo.
preproceuor: preprocesador. redundancy: redundancia.
primary memory: memoria pri- redundant character: carácter
maria. redundante.
prtnt: imprimir, impresión. reentrant: reentrante.
printed clrcult: circuito impreso. quad: cuatro, cuádruple. reentrypolnt:punto de reentrada.
printer: impresora. quantizer: cuantificador. refreah: refresco, regeneración,
prini out: copia impresa. quantum quantumjump): cuan- restauración.
prlorlty: prioridad. to (salto cuántico). retresh drcuitry: circuitería de
probe: sonda. quartz crystal: cristal de cuarzo. regeneración o refresco.
procedure: procedimiento. query language: lenguaje de Inte- regenerate: regenerar, restaurar.
processlng: procesamiento, trata- rrogación o de consulta. register: registro.
miento. queue: cola. register address: dirección de re-
processing unit: unidad de proce- queue of request: cola de peti- gistro.
samiento o de tratamiento. ciones. relation: relación.
proceasor: procesador, unidad queuing theory: teoría de colas. relational operator: operador de
central. qulck sort: ordenación rápida. relación (o relacional).
program programa. quiescent: reposo, relative address: dirección rela-
program execution: ejecución de quotlent: cociente. tiva.
un programa. relay: relé.
program file: archivo (fichero) de rellabtiity: fiabilidad, exactitud.
programas. relocatable: reasignable,
program llbrary: biblioteca de realojable, reubicable.
programas. rack mountable: montable en relocatable code: código
programmable memory: memo- chasis (o en "rack"). reubicable.
ria programable. radlx: base de numeración. relocate: reasignar, relocalizar,
progranuner: programador. RAM: RAM, memoria de acceso realojar, reubicar.
prograinming: programación. aleatorio (o directo). remark statement: instrucción
programmlng language: lenguaje random access: acceso aleatorio, (sentencia) comentario, sen-
de programación. acceso directo. tencia de documentación.
programmlng sentences instruc- random accesa file: archivo remote terminal: terminal re-
ciones (sentencias) de progra- (fichero) de acceso aleatorio moto.
mación. (o directo). removable disk: disco intercam-
prompt: petición de orden, random number generation: ge- biable.
indicador, marca, orientación, neración de números alea- repeat: repetir.
guiado. torios. request: interrogar, requerir.
propagation delay: retardo de Tange: rango, intervalo, margen. reserved word: palabra reser-
propagación. raster *can: barrido (de TV). vada.
propagation time: tiempo de pro- read: lectura, leer. reset: puesta a cero, puesta en
pagación. reader: lectora. condiciones iniciales,restable-
proportional spacing: espaciado read-only memory (ROM): memo- cer, restaurar.
proporcional. ria de sólo lectura, ROM. reset button: botón (pulsador) de
protected field: campo prote- read-write head: cabeza de lectu- reinicialización.
gido. ra-escritura. resident: residente.
protocol: protocolo. ready: listo, preparado. resistor: resistencia.
pseudo-instructlon: pseudoins- real number: número real. resolution: resolución.
trucción, seudoinstrucción. real-time: tiempo real. resource: recurso.
palI: extraer, sacar. recognition: reconocimiento. resource allocafton: asignación de
pulse: pulso, impulso. record: registro, registrar. recursos.
punch: perforadora, perforar. record key: clave de registro.
Glosario de Términos MEGABYTE

response time: tiempo de res- save: conservar, guardar, grabar, sequential memory: memoria
puesta. salvaguardar. secuencial.
restore: restaurar, restablecer, scalar data type: tipo de datos serial: serle, en serie.
reintegrar, normalizar. escalar. serlal-acceas memory: memoria
resume: reemprender, reanudar. scan: explorar, barrer. de acceso en serie.
retrieval: recuperación (de da- scanner: explorador, interro- serial Interface: interfaz serie.
tos). gador, muestreador, digita- serial printer: impresora serie.
retrollt: actualizar. lizador. serial transmiasion: transmisión
return: retorno, regreso, vuelta, scanning: exploración, barrido. en serie.
devolución, cambio de línea. schedule: planificar. series: series.
reverse video: vídeo inverso. scheduled inaintenance: mante- set: conjunto, juego, inicialización,
rewind: rebobinar. nimiento programado, planifi- activación, puesta a 1.
rlght.Justlflcation: justificación cado o previsto. set-point: punto de consigna.
a la derecha, encuadre a la de- scheduler: planificador. set-up time: tiempo de estableci-
recha, alineación a la derecha. schedullng: planificación. miento.
rise time: tiempo de subida. achema: esquema (de programa). shlft: desplazamiento.
roadmap: mapa del camino. sclentlfic notation: notación cien- shlft registen registro de despla-
robot: robot. tífica. zamiento.
robout: suprimir, borrar, eliminar. acope: ámbito, rango, pantalla, side effect: efecto lateral.
roco scaiming: barrido o explora- osciloscopio. sign: signo.
ción de líneas. scratchpad: memoria auxiliar, sign bit: bit de signo.
rolI: enrollar. memoria block de notas, me- siga position: posición del signo.
rol¡-in: trasvase, transferir moria de trabajo. slgnlficant digit: dígito significa-
adentro. acreen: pantalla, monitor. tivo.
roll-out: trasvase, transferir acreen greed: retícula, rejilla silicon (Si): silicio (Si).
afuera. o parrilla de la pantalla. slmplex: "simplex",unidireccional
roliover: teclado "rollover", tecla- screeping: barrido, exploración. simulate: simular.
do antirebotes. acroil: desplazar, mover en verti- simulation: simulación.
ROM: memoria de sólo lectura, cal (horizontal), enrollar. simulator: simulador.
ROM. acrollbar: barra de desplaza- single board computer: compu-
romable: grabable en ROM. miento tadora en una sola placa.
rotate: rotar, girar. scrolling: desplazamiento, movi- single precision: precisión
round: redondeo, redondear. miento en vertical (horizontal), simple.
rounding error: error de re- enrollamiento. single step: paso a paso.
dondeo. search: búsqueda, exploración; skewlng: enlazamiento, desliza-
rounding off: redondear (una ci- buscar. miento.
fra o un número). searchlng: búsqueda, explora- sUp: salto.
routine: rutina, subrutina, ción. slash (1): barra inclinada, diagonal.
subprograma. second source: segunda fuente. slave: esclavo.
row: fila, renglón. sector: sector. alot: ranura, abertura, conexión.
rubout character: carácter de su- seek: búsqueda, exploración. ama¡¡ scale Integration (SSI): in-
presión, eliminación o bo- aegment: segmento. tegración a pequeña escala
rrado segmentation: división en seg- (SSO.
run: ejecución, carrera, curso, mentos. smart: inteligente.
marcha; ejecutar. select: seleccionar. smooth, smoothlng: alisar, pulir,
running: ejecución, funciona- selecting: selección. suavizar. -
miento. semantics: semántica. snapshots: salidas parciales.
run time: tiempo de ejecución. semiduplex: semidúplex. socket: conector.
run-tlmeerror: error de ejecución, sensor: sensor. soft copy: copia temporal, fugi-
error durante la ejecución. sentence: sentencia, instrucción, tiva.
frase. soft key: tecla de función
sequence: secuencia, sucesión. programable.
sequencer secuenciador. software: "software", programa,
sequenclng: secuenciamiento, en logical.
sample: muestra, muestrear secuencia. software compatible: compatibles
muestreo. sequential: secu encial. por "software".
Glosario de Términos MEGABYTE

software englneering: ingeniería structured data type: tipo text editor editor de textos.
de "software'. estructurado de datos. text mode: modo texto.
solid Mate: estado sólido. structured language: lenguaje textprocesaing: procesamiento de
sort: ordenación, clasificación, estructurado. texto, tratamiento de texto.
ordenar, clasificar. subroutlne library: biblioteca de text window ventana de texto.
sort and merge system sistema subrutinas. thermal pninter impresora tér-
de ordenación y fusión. subscript: índice, subíndice. mica.
sont key: llave (clave) de supervisor supervisor. thlmble printer: impresora de
ordenación. support: apoyo, soporte. tulipa (de margarita).
sortlng: ordenación, clasificación. swapping: intercambiar, recopia thin fthn: película delgada.
source: fuente. de memoria en disco. throughput: rendimiento, produc-
source code: código fuente. switch: conmutador, interruptor, tividad, capacidad de produc-
space: espacio. selector. ción.
spedal character: carácter espe- swltchlng: conmutación. time dependent procesa: proce-
cial. swltchlng circuit: circuito de so dependiente del tiempo.
speech syntheslzer: sintetizador conmutación. time interrupt: interrupción tem-
de VOZ. symbol: símbolo. poral.
speed: velocidad. symbolic: simbólico. time out: transcurrir el tiempo (el
split acreen: pantalla dividida. synchronous: síncrono. intervalo de tiempo).
spooler: integrador de E/S. syntax: sintaxis. time sharing: tiempo compartido,
spread sheet: hoja electrónica, system: sistema. compartimiento del tiempo.
hoja de cálculo electrónica. system analyst: analista de sis- toggle: bascular, basculamiento.
sprite: imágenes con movimiento, temas. toggle switch: conmutador, inte-
objetos móviles. system programmer: programa- rruptor basculante.
stock: pila. dor de sistemas. token: símbolo designador, valor
stock pointer. apuntador (punte- system software: "software" del simbólico.
ro) de pila. sistema. tool: herramienta.
stand-alone: autónomo. systematic programmlng: progra- top.down: descendente.
standard: norma, estándar. mación sistemática. trace: traza, rastro, ejecución paso
start bit: bit de comienzo o inicio, a paso.
bit de arranque. track: pista.
Mart up program: programa de T trackball: bola rodante, bola de
activación. seguimiento, trackball.
state: estado. tab: tabulación, tabular, tab. tractor feed: alimentación por
statement: sentencia, instrucción, table: tabla. tracción.
frase. table look-up: búsqueda en tabla, trame: trama.
static: estático. consultar una tabla. transact.ion: transacción.
status: estado, estatus. tabllng: tabulación transducer transductor.
step: paso, etapa. tape: cinta. transfer transferencia, transmi-
stop bits: bist de paro, bits de tape drive: unidad de cinta. sión, transferir, transmitir.
parada, bits de detención. tape recorder: grabadora de translent: transitorio.
storage: almacenamiento, me- cinta. transiation: traducción.
moria. target system: sistema objeto. translator. traductor.
storage capaclty: capacidad de task: tarea. trap: interrupción, intercepción,
almacenamiento (o de me- tayloring: adaptación. trampa.
moria). telecommunlcatlons telecomuni- tree: árbol.
atore: almacenar. caciones. tree-strudured: estructurado en
stored program: programa alma- teleprocesslng: teleprocesa- árbol.
cenado. miento, teletratarniento. trigger disparador, activador, dis-
atored program computer: televislon monitor: monitor de paro de activación.
computadora de programa al- televisión. truncation: truncamiento.
macenado (o interno). template: pauta, plantilla, molde, truth table: tabla de verdad, tabla
stream corriente, flujo. modelo normalizado. lógica.
stning: cadena, hilera, ristra, temporary atorage: memoria tem- turnaround time: tiempo de res-
serie. poral. puesta.
strobe: habilitación, habilitar. test deck: paquete de prueba.
Glosario de Términos MEGABYT

two's complement: complemen- VDT: pantalla, monitor. word proceasor procesador de


to a dos. VDU: pantalla, monitor, unidad de palabras.
type: tipo. presentación visual. word wrap: escritura continua.
vector vector. work arca: área de trabajo.
vectored lnterrupt: Interrupción work station: puesto (estación)
[1] vectorizada. de trabajo.
verifier: verificador. worklng file: archivo (fichero) de
unary operator: operador uni- verlfy: verificar. trabajo.
tario. very hlgh leve¡ language (VHLL): workspace: espacio de trabajo.
unconditional control lnslruc- lenguaje de muy alto nivel. WPM Words Per Minute): pala-
tlous: instrucciones de control very large acale Integration bras por minuto.
Incondicional. (VLSI): Integración a muy gran- wrap-around: retorno de cursor.
underflow: desbordamiento ne- de escala. wrlte: escritura.
gativo. video: vídeo. wrlte cycle: ciclo de escritura.
unit: unidad, órgano. virtual address: dirección virtual. wrlte-pro(ed: proteger contra es-
unscheduled maintenance: man- visual display terminal: terminal critura.
tenimiento no periódico. de visualización.
update: actualizar, poner al día. volatile: volátil.
updatlng: actualización, puesta volume: volumen. X
al día.
uppercase: mayúscula, caja alta. X-Y plotter trazador, registrador
uppercase letters: letras mayús- w en coordenadas cartesianas.
culas.
user usuario. walt Mate: estado de espera.
user defined: definido por usua- welght: peso, ponderación. Y
rio. whlle: mientras.
user frlendly: cómodo, amistoso, wlndow: ventana. yield: yield: producción.
amigable para el usuario. wire wrap: conexión arrollada
user program: programa de usua- o enrollada, cableada "wire
rio. wrap". Z
utllity: utilería, utilidad. wlred control: control cableado.
utillty software: "software" de word: palabra. zero: cero. qu
utilería (o de servicio). word length: longitud de palabra. zero ellminaniminacf n
word processlng: procesamiento cero.
de palabras, tratamiento de zero Mate: e1ac ero.
palabras, procesamiento de zero supprr: elimiiór'
texto, tratamiento de texto. supresi deros.
rq 1
variable: variable.

1
V\IVFPÇ1DAD CESAR VALLEJO

CODIGO oO4

N° DE LIBRO:
fq0
FECHA: 0$
PC WORLD-COMPUTERWORLD-MACWORLD
FORMA DE SUSCRIPCIÓN

[1] por FAX L] por TELÉFONO por CORREO

Si deseo suscribirme a la revista

Nombre:

Dirección:

Ciudad: Cod. Postal:

Teléfono: País:

Forma de Pago:

çv
Cheque El Visa LII MasterCard

'.'
Verf1q%ie conlhstribuidor la tarifa correspondiente.
Tarifa básicaToun año (12 números)

LII Argeitina
ÇII jolombia
El hi
LIEpaña
'LJPerú
,EJ Eiador
LiP otros

NOTA: Editorial Limusa y Megabyte no asumen ninguna responsabilidad por los


servicios que se mencionan en este espacio.
DISTRIBUIDORES IDG EN AMÉRICA LATINA Y ESPAÑA

ARGENTINA COLOMBIA

CW Comunicaciones S/A Inviarco LTD.


Av. Belgrano 406-Piso 9 Carrera 90 No. 156-19
C.P. 1092 Buenos Aires. Apartado 401
Télefono: 54-1-34-5583 Télefono: 57-1-680-0399
Fax: 54-1-331-7672 Fax: 57-1-285-3920

CHILE PERÚ

Informática Clisa Servicios especiales de Edición.


Publicaciones en Computación Ltda. El Comercio
Pedro de Valdivia 2103, Santiago Jr. Miro Quesada 247-702
Télefono: 562-204-7677 Lima 1
Fax: 562-204-7245 Télefono: 51-14-281-061
Fax: 51-14-280-311

ECUADOR: ESPAÑA

Ecuasistem IDG Comunicaciones


P.O. Box 17-07-8787 Rafael Calvo 18,413
Inglaterra 1373 y Av. Amazonas 28010, Madrid
Quito. Télefono: 341-319-4014
Télefono: 59-32-450-807 Fax: 341-319-6104
Fax: 59-32-432-732
¡ SUSCRíBASE AHORA!!

Valor de la suscripción:
(11 números —Feb. a Diciembre)

Li *Venezuela
1 U Americano: US$60
Li (Caracas-mensajero Bs. 950,00) 1 Entregados por correo aéreo certificado
Li (Interior-mensajero Bs. 2,200,00) 1
Li (Interior-correo certificado Bs. 990,00) U *Resto del mundo: US$85
Li (Caracas-correo certificado Bs 990,00) 1 Entregados por correo aéreo certificado

Si desea mayor información comuníquese con nosotros por los teléfonos


(02) 762-76-38/36 - 71-31-97 o por el Fax: (02) 762-49-70

Nombre:
Empresa donde trabaja:
Dirección:

Ciudad: Edo: -
País: Teléfonos:

Adjunte a este cupón su cheque NO ENDOSABLE a nombre


de IDG Comunicaciones, C.A.
Si desea pagar con tarjeta de crédito, por favor complete la siguiente información:
Li AMERICAN EXPRESS Li VISA Li DINERS Li MASTERCARD

N9 Fecha de vencimiento:

Su firma-indispensable, por favor


IDG COMUNICACIONES, C.A.
Av. Libertador, Torre Maracaibo, piso 10, Ofic. H, La Campiña, Caracas, Venezuela
Favor enviarme COMPUTER WORLD VENEZUELA por un año

Suscripción Caracas-Mensajero ............. Bs. 1.430 LI Li AMERICAN EXP.


Suscripción Caracas-Correo Certif icado Bs. 1.540 LI
Suscripción Interior-Mensajero ............. Bs. 3.800 LI LI VISA
Suscripción Interior-Correo Certif icado Bs. 1.540 LI LI DINERS
Suscripción Continente Americano ....... .US$ 130 LI
Suscripción Resto del Mundo ................ US$ 200 Li
LI MASTERCARD

No¡ l!HlHIIIII FECHA VENCIMIENTO:

Si es cargo a su tarjeta de crédito, Si es cheque, favor enviarlo "NO ENDOSABLE"


favor registrar su firma, a nombre de "IDG COMUNICACIONES, CA."

Suscripción nueva LI Renovación LI Cambio de dirección LI Fecha


Apellidos:.
Nombres:
Compañía:
Dirección:
Teléfono(
Apartado Postal:______ _Ciudad:
Código Postal:_______ Estado:
La dirección indicada es: Habitación Trabajo Li
Li
Por favor, haga un círculo alrededor de un número en cada categoría:
Tipo de empresa 22 Software, Planificación 40 Ingeniero, Otros________________
USUARIOS 23 Distrfnjción o venta de "¡pos de computación 41 Gerente Representante de Ventas de DP
11 Industrias (excepto compilación) 24 Otros proveoiores_______________________ 42 Gerente Representante de Ventas,
12 Bancos, Seguros, Bienes Raices 2. Cargo
13 Hospitales, Escuelas 31 Presidente, Propietario, Socio, Gerente General 43 Conniltor
44 Profesional (no ingeniero)
14 Comercio al mayor o al detal 32 Vicepresidente, Gerente de División
45 Edocador, Esitidianle
15 Industria de servidos (excepto computación) 33 Tesorero, Contralor, Director F'inanciero
49 Otros__________________
16 Gobierno 34 Director, Gerente, Supervisor de OP.
3. Tipos de equipo de DP que utiliza
17 Servicios poblicos, Comunicación, Transportes 35 Director, Gerente de Operaciones o
51 Mainírames
18 Petrolen, Minas, Refinación, Construcción Administración 52 Superminis
19 Otros usianos_________________________ 36 Gerente, Analista de Sistemas 53 Minicomputeioras
PROVEEDORES 37 Gerente, Supervisor de Programación 54 Microcomputadoras
21 Fabricantes de computadoras, eguipos afines o 38 Programador, Analista de Métodos 55 Sistemas de comunicación
periféricos 39 Ingeniero, Técnico de Servido 56 Sistemas de automatización de oficinas

¡DG COMUNICACIONES, C.A. Torre Maracaibo. piso 10, oficina H. La Campiña Caracas 1050 Venezuela,
Apartado 61980 Chacao 1968-A. Teléfonos: (02) 762.88.96 - 762.76.34 -71.31.97. Fax: (02) 762.49.70
COMPUTERWORLD - MÉXICO

Agradecemos nosproporcione esta información OTROS CARGOS GERENCIALES


(marque con una x)
11 Presidente/ Socio! Director General
GIRO DE EMPRESA 12 Vicepresidente! Subdirector
II) Fabricación (no computadoras) 13 Contralor/ Tesorero/ Director Administrativo
20 Finanzas, Seguros, Bienes Raíces
30 Medicina/ Leyes! Académicos INGENIERÍA
40 Comercio Mayoreo/ Menudeo 41 Ingeniería/ Ciencias! Investigación y Desarrollo
50 Servicios empresariales (excepto EDP)
60 Gobierno/ Federal/ Estatal! otro VENTAS! MERCADOTECNIA
65 Sistemas de Comunicación! Servicios Públicos! 51 Representante Técnico de Ventas! Gerente de Ventas
Transportes 52 Gerente de Mercadotecnia! Publicidad! Promoción
70 Petroquímica/ Minería/ Construcción! Agroindustria
80 Fabricación de Computadoras! Sistemas Relacionados!
OTRAS PROFESIONES
Periféricos
90 Distribuidor de computadoras/ representante 60 Consultor
75 Usuario: Otros: 70 Medicina! Leyes! Contaduría
96 Proveedor: Otros: 80 Profesor! Periodista! Bibliotecario! Estudiante
90 Otros
CARGO! FUNCIÓN (INDIQUE UNA) IS! MIS! DP
19 Director! Subdirector IS! MIS! DP ACTIVIDADES RELACIONADAS CON LA COMPUTACIÓN
21 Director! Subdirector / OperacIones! Planeaclón! Equipos en los que se tiene contacto personal como
Servicios Administrativos
proveedor, consultor o usuario
22 Director/ Gerente! Encargado de Análisis de Sistemas
A Mainframes- Superminis
23 Director/ Gerente! Encargado Programación
31 Programador! Analista de Métodos B Minlcomputadoras- Equipos empresariales medianos
32 Gerente! Encargado Automatización! Proceso de C Microcomputadoras- Equipos de Cómputo de Oficina
Palabras D Equipos y Sistemas de Comunicación
35 Gerente! Enc ado Comunicación de Datos! Redes E Sistemas de automatización de oficinas
Sistemas F Ningún contacto con computadoras

Si por favor envíenme mi suscripción. Acepto la oferta de $ 175, 000. 00, N $ 175.00 por un año (41 ediciones), un ahorro
de $30, 000.00. N$ 30.00 sobre el precio de portada.

Adjunto Cheque No.: Firma


Compañia
Nombre
Puesto Teléfono(s):
Dirección:
Colonia: Código Postal:
Ciudad: Estado:

El domicilio que aparece arribas el de mi: O oficina O casa

E] pnodko Pr 1. 4 1.('onl Fuera de la República Mexicana: $77 dls.


COMPUTER WORLD El costo de cada suscripción es deducible de Impuestos
González de Cossío 334, Col. del Valle 03100 México, D.F Adjunte al cupón cheque o giro postal por $175, 000.00
teléfonos: 669-36-32, 66944-54 y 669-16-76 a nombre de Computerworld de México, S.A. de C.V.
MEGABYTE PRESENTA
SU SERIE CONOZCA A...

* EL DISCO DURO
Rubsam
* WINDOWS 3.0
Wentges
* HARVARD GRAPHICS
Bridges
*DR DOS 5.0
Schieb
* DOS 3.3 AVANCE A DOS 5
Beisecker
* FLIGHT SIMULATOR 4.)
Dille
* PC TOOLS DELUXE 6.0
Hoiste
* QUATI'RO PRO 2
Aitken
* NORTON UTILITIES
Bartel
* CARBON COPY PLUS
Bryan
* LOTUS 1-2-3
Baile!
* Q DOS-II
Tamayo
* PAGEMAKER PARA MACINTOSH
Dan uloff
4
1

La ingeneria de u temasasudo un temde interés desde finales


c4e los cincuentas, principios de los sesentas (y tal vez aun antes).
1 -Sin emargo , a causa de las diversas desviaciones que, por una u
• otrran, se travé& de bis años es apropiado revisar
- (yifatizar) algo ç Lbases.

/ Este texto describe Ja ¡n1géniería dWtnias en términos de sus


objetivos y aplicaciones durante el de desarrollo.
Se proporcionz una perspectiva de ladmÍmstración como ayuda
para la implementación de los progr.amas qu incluyen el impulso
• • - 'de la ingeniería de sisterias. Este es un texto'troductorio, desa-
rróllIo con la finalidad Me proporcionar al lector muchas nuevas
7 y utUes, ideas.
7
1 •-' 4

•-:
- ••• • -,
. ••4 :1

S-ar putea să vă placă și