Documente Academic
Documente Profesional
Documente Cultură
-.`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
ADMINISTRACIÓN DE
INGENIERÍA DE SISTEMAS
BENJAMIN S. BLANCHARD
Virginia Polytechnic Institute & State University
MEGABYTE
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
ISBN 968-18-4527-7
528
PRÓLOGO
RODNEY D. STEWART
Octubre de 1990
PREFACIO
BENJAMIN S. BL.NCHARD
1.1 EL AMBIENTE
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)
Diseno Utilización
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 - -
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 Costo-efectividad 1
t
tnbutoesenodekism
— L- - - - - - - - - - -
- - lemeopoedele
t
----
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 retiro
y desecho
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
___________________________
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
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
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
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.
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:
'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
'¡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
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)
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
III
Retroalimentación y acción correctiva ------
Investigación aplicada
Figura 1.7. Los pasos más importantes del diseño y desarrollo del sistema.
38 INTRODUCCIÓN A LA INGENIEREÁ DE SISTEMAS
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)
,/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
1.5 RESUMEN
PREGUNTAS Y PROBLEMAS
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.
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
( s
o o
a
E
a
E
o 0)
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.) -
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
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
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
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
4 Ninguna pieza de equipo o software, o ítem de datos, o elemento de soporte logístico debe ser
5.3 5.5
(
)
5.4
Necesidades
Para desarrollar la capacidad es trans-
porte entre la ciudad 'A'y la ciudad 8
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
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
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.
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".
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
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.
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 --
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
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)
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
- - 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
Parámetro de
Efectividad de costos
primer orden
Enfoque seleccionado
No
¿Es factible el
enfoque? Si
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
----------- ------------
2
Modelo de 1 1 Modelo de 1 Modelo de
empaque del 4 1 desempeño del análi sis
sistema sistema estructural
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 ----------------------
o *
o
o --
-- o
Costo total
"\ r - - - - J
1 /del costo del equipo
Prueba y soporte
`Costo total
ostodesoportede
_ Costo Costo del mantenimiento
1
F-71 de factibilidad
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
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
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
11 En el sector de defensa, el TEMP es requerido para los programas más grandes, e Incluye la
Planeación de prueba
K
Verificación de si la j
modificación corrigió el una acción co No se requiere acción
problema E5 eq
sí
86
PRUEBA Y EVALUACIÓN 87
2.12 RESUMEN
PREGUNTAS Y PROBLEMAS
----;.----
Plan do administración del programa (PMT)
T i r 1
Requerimientos técnicos Requerimientos—
de
L - _1 L 1
del programa
Planes de ingeniería
individuales
Otras especificaciones
y estándares
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
Sistema XYZ
Ensamble 1
Subensamble s
Especificación del
material (Tipo QE")
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
1.0 Alcance
2.0 Documentos aplicables
3.0 Requerimientos
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
Diseño para la
confiabilidad k 1 )
Diseño para la
flexibilidad
,j
Diseño para la
1\
capacidad de
mantenibilidad
transporte
F"
capacidad de capacidad de
soporte producción
Diseño para la
factibilidad
económica (costos
M ciclo de vida)
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
SMIU SOFTWARE
99.0
ENG UR
110,..tOfl
COMPUTER
o
TEST IQUIPME(INE(
SECI TYENGIERS
El E*9GI E
CORt
R = e t = et/M (3.4)
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
número de fallas
(3.5)
horas totales de operación
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)
R, = eA + + (3.7)
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
0 0.2 0.4 0.6 0.8 1.0 1.2 1.4 1.6 1.8 2.0
\--
Equipo electrónico Equipo mecánico
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
(3.9)
(3.10)
Cinco unidades
SenE
Tiempo
'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
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
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.
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
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
ni
o_ ni
122
DISCIPLINAS DE INGENIERÍA DEL DISEÑO 123
- (X,)(Mct)
Mc,' = (3.13)
YEW
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
0.4
WC
0.2
C
20.1
1.0
0.95
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
(3.20)
1 /MTBMU + 1 /MTBM,
Aa = MTBM- (3.22
MTBM + M
"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
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.
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.
-- — — 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.
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
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
Concepto de mantenimiento de
los requerimientos operacionales
• operaciones de trabajo
• obligaciones
• trabajos
• subtrabajos
• elementos de trabajo
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.
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
Operación E Eléctricos
()
Transmisión V Vsuiaies
Recepción S De sonido
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.
'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
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.
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.
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
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
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
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.
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:
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.
151
152 REQUERIMIENTOS DEL DISENO DE SISTEMAS
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.
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.
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
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
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
¿Enfoque de diseño?
Hardware
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
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
Verificación
Diseño detallado
Verificación
Codificación
Prueba unifaria
Integración
Verificación
M producto
lmplementación
Operaciones
y mantenimiento
Revalidación
Selección de componentes-materiales-diseños
Po
diseño (tensión, desgaste, resistencia a la corrosión, dureza,
ductibilidad, electronegatividad, etcétera)?
Sí
¿Están los componentes y los materiales comercialmente disponibles No
(más de una fuente o proveedor)?
Sí
¿Son los procesos de manufactura propuestos compatibles con los 1 No
componentes-materiales (exactitud, tolerancia, cantidad, disponibi-
lidad)?
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
sí
¿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
Sí
Producción-construcción de sistema
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
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.
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
• Calidad
• Otros factores
Objetivo
Un enfoque balanceado
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
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.
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).
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)
Paso Actividad
1 Definir el problema.
2 Identificar las alternativas - configuraciones factibles que se evalúan a través del análisis LCC.
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.
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.
Figura 3.32. Los pasos básicos en un análisis de costo del ciclo de vida.
3.3 RESUMEN
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
Prueba y evaluación
No
sfacto
'os
.
Y
<resultados9
Entrada
9.
Entrada Salida
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
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
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
Revisión y aprobación de la
documentación del diseño
Diseño preliminar
'Si
Diseño de detalle y desarrollo
Revisión y aprobación de No
documentación del diseño
E1l
181
182 MÉTODOS Y HERRAMIENTAS DE LA INGENIERÍA DE DISEÑO
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
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
'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
neríaaaPorco ora
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
193
194 MÉTODOS Y HERRAMIENTAS DE LA INGENIERÍA DE DISEÑO
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
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
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
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
4.6 RESUMEN
PREGUNTAS Y PROBLEMAS
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
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
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
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
Figura 5.2. Relación entre los TPMs y las disciplinas responsables del diseño.
No No
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
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
Requerimientos generales:
Características de diseño:
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?
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.
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 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
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
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)
•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
S.S. RESUMEN
PREGUNTAS Y PROBLEMAS
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
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
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
[Rn sistema
III
Consumidor-usuario
(cliente)
Contratista A Contratista B
(productor importante) (productor Importante)
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
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
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
1.0 Panorámica
3.0 Aplicación(es)
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)
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.
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.
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
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
wi II_II_II_JI _II_II_1
E1:
Equipo ccm)n de xror1e, a revi orgarizaciceri
E
00, Software cperackmi
301200, Software de arkr*airackm
301300. Paquetes de software especial
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)
260
PLAN DE ADMINISTRACIÓN DE LA INGENIERÍA DE SISTEMAS (SEMP) 261
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
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
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)
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
Programa deactividades 1 2 3 1 4 5 1 6 1 7 1 8 1 9 10 11 12
Programa de actividades 1 2 3 1 4 1 5 6 1 7 8 9 10 11 12
f
4. Planeación de la administración de la A
ingeniería de sistemas (SEMP)
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
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).
2 12
di
r
Cla
4 di de i.iI,
2-3-4 T.B-E 8-10-12 dsI.dn.
iaa. l.2-3-4-5-6-7-O-jl-12-l$l5.t6-17.
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.
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
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
'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.
o'
('4 • 2 co 2 u, 2 co u,
E
co • cc • s ccs co
a-
U)
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
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).
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)
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
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
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
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:
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)
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
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.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
Análisis de riesgos 1
¿Es No ¿Es No
ç7 <ç3
sí sí
Alto riesgo Riesgo medio Bajo ri
6.6 RESUMEN
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
PREGUNTAS Y PROBLEMAS
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
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
305
306 ORGANIZACIÓN PARA LA INGENIERÍA DE SISTEMAS
2
A lo largo de este capítulo, los términos "consumidor" y "cliente" se usarán indistintamente.
También, "productor" y «contratista".
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
1
Jefe del Departamentc H Jefe del Departamen-
de la Documentación to de Ingeniería de
de Diseño Valuación-Costo
Afta
Baja
Progreso del diseño y desarrollo del sistema
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.
1 Compañía ABC 1
Línea T del producto 1 1 Línea Y" del producto 1 Línea Z" del producto 1
Presidente
Compañía ABC
Vicepresidente
Ingeniería
Figura 7.7. Organización de la línea del producto con las subunidades del proyecto.
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.
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
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.
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.
ca
tc
ca
CL
o
o
ÍV
321
322 ORGANIZACIÓN PARA LA INGENIERÍA DE SISTEMAS
1 Compañía KLM 1
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)
¡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
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.
Contratista
principal
(productor)
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
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.
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
Características de liderazgo
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.
1. Satisfactores
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
"°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
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
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.
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:
PREGUNTAS Y PROBLEMAS
CONTRATACIÓN Y ADMINISTRACIÓN
DE PROVEEDORES
Análisis y estudios de
compromisos del sistema
(Respuesta a cómo deben ser
realizadas las funciones-recursos)
'Ir
si
351
352 CONTRATACIÓN Y ADMINISTRACIÓN DE PROVEEDORES
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
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
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
2.Estructura de la organización 4 4 16 3 12 4 16
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
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
357
358 CONTRATACIÓN Y ADMINISTRACIÓN DE PROVEEDORES
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.
Figura 8.3. Lista de verificación de los criterios de evaluación para las propuestas del proveedor
(ejemplo).
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.
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
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
30 - 50150 SR
- 20
40/60 SR:
-lo-
-20 — 30170 SR
-30 — 1
-40-
1'
UmtIe Objetivo Umtie
de confianza (garantía) de confianza
más bajo más alto
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
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
control. Esta actividad continua puede ser bastante importante por las
razones siguientes:
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
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).
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
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
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
Proveedor (manteni-
miento de depósito)
Producción
1 2 3 4 5 6 7 8 9 10 11 12
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
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.
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
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.
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
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
3D
lom
500
o
1 2 3 4 5 6 7 8 9 10 11 12
Ciclo de vida-años
OID
aID
icto
1 2 3 4 5 6 7 8 9 10 11 12
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
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.
--+--
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)
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
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
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
-- -------- --
402
ANÁLISIS DEL TRABAJO DE MANTENIMIENTO (EJEMPLO 3) 403
í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.
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
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
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
Factor de ajuste
(riesgo de desarrollo) 113 81 197
- 15% - 10% 20%
Gran total 100 640 730 427
B. 1 REQUERIMIENTOS GENERALES
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
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.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?
1.0 Accesibilidad
4.0 Calibración
6.0 Desechabilldad
11.0 Sujetadores
12.0 Manejo
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
15.0 Mantenlblildad
16.0 Movilidad
17.0 Operabilldad
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
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.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
28.0 Software
29.0 Estandarización
30.0 Almacenamiento
33.0 Sobrevlvencla
36.0 Calidad
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
B. INVESTIGACIÓN DE OPERACIONES
D. CONFIABILIDAD
E. MANTENIBILIDAD Y MANTENIMIENTO
13. Salvendy, G. (Ed.), Handbook of Human Factors, John Wiley, New York,
1987.
456 APÉNDICE D: BIBLIOGRAFÍA
G. LOGÍSTICA
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
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.
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
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
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
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
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
1
V\IVFPÇ1DAD CESAR VALLEJO
CODIGO oO4
N° DE LIBRO:
fq0
FECHA: 0$
PC WORLD-COMPUTERWORLD-MACWORLD
FORMA DE SUSCRIPCIÓN
Nombre:
Dirección:
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
ARGENTINA COLOMBIA
CHILE PERÚ
ECUADOR: ESPAÑA
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
Nombre:
Empresa donde trabaja:
Dirección:
Ciudad: Edo: -
País: Teléfonos:
¡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
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.
* 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
•-:
- ••• • -,
. ••4 :1