1 ingenieria de sistemas

8/6/2019 1 Ingenieria de Sistemas

1/125

1

P u b l i c a c i o n e s d e I n g e n i e r a d e S i s t e m a s

Benjamin S. Blanchard

Benjamin S. Blanchardes el Director del

Programa de Ingeniera

de Sistemas de Virginia

Polytechnic Institute &

State University. Es

consultor, investigador y profesor de

cursos de ingeniera de sistemas,

fiabilidad y mantenibilidad, apoyo logstico

y coste del ciclo de vida. Antes de

incorporarse a la comunidad acadmica

en 1970 pas 17 aos en la industria

como ingeniero de diseo, ingeniero de

campo y responsable de ingeniera

(Boeing Airplane Co., SandersAssociates, Bendix Corp. y General

Dynamics Corp.). Ha escrito cuatro libros

y es co-autor de otros cuatro, y ha

publicado numerosos artculos sobre

ingeniera de sistemas y disciplinas

asociadas. Ha impartido conferencias en

Asia, Europa, Australia y Amrica. Es

miembro de la Society of Logistics

Engineers, de la que ha sido Presidente,

y de otras organizaciones profesionales

como el National Council on Systems

Engineering.INGENIERA

DE

SISTEMAS.

B

enjamin

S.

Blanchard

MIT DE REDACCIN

esidente. D. Martn Alear Ginard

eniente General (R) del Ejrcito de Tierra

calesr. D. Eduardo Avanzini Blancoeneral de Brigada Ingeniero del Ejrcito del Aire

. D. Manuel Bautista Prezrector General del Instituto Nacional de Meteorologa

. D. Carlos Casajs Dazcealmirante Ingeniero de la Armada

r. D. Luis Garca Pascualrector de las Escuelas de Ingeniera del ICAI

r. D. Ricardo Torrn Durneneral de Brigada Ingeniero del Ejrcito de Tierra

r D. Alberto Sols Rodrguez-Candelageniero de Sistemas. Isdefe

ra. Da. M Fernanda Ruiz de Azcrate Varelamagen Corporativa. Isdefe

Ingeniera de Sistemas

c/ Edison, 4

28006 Madrid

Telfono (34-1) 411 50 11

Fax (34-1) 411 47 03

E-mail: [email protected] P.V. P.: 1.000 Ptas .

(IVA incluido)

INGENIERA DE SISTEMASpor

Ben j am in S . B l ancha rd

USTRACIN DE PORTADAquina de vapor de Watt


2/125

INGENIERA DE SISTEMAS

2

No est permitida la reproduccin total o

parcial de este libro, ni su tratamiento

informtico, ni la trasnmisin de ninguna

forma o por cualquier medio, ya seaelectrnico, por fotocopia, por registro o por

otros mtodos, sin el previo consentimiento

por escrito de los titulares del Copyright.

Primera Edicin: Enero - 1995

1.250 ejemplares

Traductores:

Rafael Ugarte Azuela

Alberto Sols Rodrguez - Candela

Isdefe

c/ Edison, 4

28006 Madrid.

Diseo:

HB&h Direccin de arte y produccin

Infografa de portada:Salvador Vivas

Fotomecnica:

Microprint, S.A.

Impresin:

Grficas Marte, S.A. (Madrid)

ISBN: 84-68338-00-0Depsito legal: M-1661-1995

Printed in Spain - Impreso en Espaa.


3/125

3


4/125


4


5/125

5

PRLOGO

Esta monografa versa sobre Ingeniera de Sistemas, expre-sin o vocablo definido diferentemente segn la experiencia y la tra-yectoria profesional del que lo intenta. La descripcin contenida enesta monografa se basa en mi propia trayectoria profesional, que in-cluye 17 aos de experiencia industrial (como ingeniero de diseo,ingeniero de mantenimiento de campo, y director de ingeniera), se-

guido por otros 24 en el campo docente de la enseanza superior(como instructor, consultor y Director del Programa de Ingeniera deSistemas de Virginia Polytechnic Institute and state University). El pro-ceso, la terminologa, el tipo de especificaciones, los elementos org-nicos, etc, son genricos y no se refieren a ninguna situacin, pro-yecto o ambiente particular concreto. Gran parte del material aqu ex-puesto se basa en los siguientes textos:

1. Blanchard, B.S., and W.J. Fabrycky, Systems EngineeringAnd Analysis, 2nd Edition, Prentice-Hall, Inc., Englewood Cliffs, NewJersey, 1990.

2. Blanchard, B.S., System Engineering Management, JohnWiley & Sons, Inc., New York, 1991.

3. Blanchard, B.S., W.J. Fabrycky, and D. Verma (Eds.),Application of The System Engineering Process To Define


6/125


6

Requirements For Computer-Based Design Tools, Monograph, Societyof Logistics Engineers (SOLE), 8100 Professional Place, Suite 211,

New Carrollton, Maryland 20785, 1994.

Es para m un gran honor el tener la oportunidad de desarrollary recopilar esta monografa para ISDEFE, Madrid, Espaa, y deseoexpresar mi agradecimiento a Alberto Sols quien hizo posible estacolaboracin. Asimismo agradezco profundamente los comentarios eintercambios de opiniones tanto de Dinesh Verma (Virginia Tech) comode los componentes del Comit de Redaccin Martn Alear Ginard,

Eduardo Avanzini Blanco, Manuel Bautista Prez, Carlos Casajs Daz,Lus Garca Pascual, Ricardo Torrn Durn, y Mara Fernanda Ruizde Azcrate Varela.

Benjamin S. Blanchard


7/125

7


8/125


8


9/125

9

NDICE GENERAL1. INTRODUCCIN 11

1.1.Entorno actual 151.2.Definicin de ingeniera de sistemas 181.3.Caractersticas de la ingeniera de sistemas 211.4.Aplicaciones de la ingeniera de sistemas 24

2. EL PROCESO DE INGENIERA DE SISTEMAS 27

2.1.Requisistos del sistema 292.1.1. Identificacin de la necesidad 30

2.1.2. Realizacin de los estudios de viabilidad 312.1.3. Definicin de los requisitos operativos del sistema 332.1.4. Desarrollo de los conceptos de apoyo y mantenimiento 372.1.5. Desarrollo y asignacin de prioridades

de medidas de prestaciones tcnicas 432.1.6. Elaboracin de la especificacin del sistema (Tipo A) 46

2.2.Anlisis funcional y asignacin de requisitos 472.3.Anlisis, sntesis, evaluacin y optimizacin del diseo 542.4.Integracin del diseo 59

2.5.Revisin, evaluacin y realimentacin del diseo 602.6.Prueba y evaluacin del sistema 652.7.Produccin y/o construccin 692.8.Utilizacin y apoyo del sistema 702.9.Retirada del sistema, desecho del material,

rehabilitacin y reutilizacin 72

3. PLANIFICACIN, ORGANIZACIN YGESTIN DE INGENIERA DE SISTEMAS 77

3.1.Requisitos del programa de ingeniera de sistemas 793.2.Identificacin de tareas 823.3.Organizacin para ingeniera de sistemas 863.4.Integracin de las disciplinas de ingeniera 933.5.Relaciones con actividades claves del programa 953.6.Gestin y control del programa 973.7.Resumen 99

REFERENCIAS 101

BIBLIOGRAFA 105

GLOSARIO 109


10/125


1 0


11/125

1 1

1Introduccin


12/125


1 2

Esta monografa trata de ingeniera de sistemas, o el proce-

so ordenado para hacer realidad un sistema. Un sistema es una com-binacin de medios (como personas, materiales, equipos, software,instalaciones, datos, etc.), integrados de tal forma que puedan desa-rrollar una determinada funcin en respuesta a una necesidad con-creta. Los sistemas se clasifican como naturales o artificiales, fsicoso conceptuales, abiertos o de lazos cerrados, estticos o dinmicos.Los sistemas analizados en esta monografa son artificiales, ocupan

un espacio fsico, son dinmicos por naturaleza, y son abiertos por laposibilidad de ser interactivos y de modificar los mrgenes de su cam-po de actuacin. Ms an, los pasos especficos, la terminologa, lostipos de especificaciones, los elementos orgnicos, etc., son genri-cos y no se refieren a ninguna situacin o entorno concreto [1].

Un sistema puede variar por su forma, adecuacin, y/o funcin.Se puede tratar con un grupo de aviones desarrollando una misin en

una situacin geogrfica concreta, un barco o una capacidad de dirigirel combate, una red de comunicaciones capaz de distribuir informa-cin a nivel mundial, un sistema de distribucin de energa que abar-que canales y plantas generadoras de energa, una planta de fabrica-cin capaz de producir x productos en un tiempo determinado, o unpequeo vehculo terrestre que realice el transporte de cierto tipo decarga de un lugar a otro. Cada sistema est formado por componen-tes, y stos a su vez pueden descomponerse en otros ms pequeos.Si en un sistema determinado se establecen dos niveles jerrquicos,al inferior se le suele denominar subsistema. Por ejemplo, en un


13/125

1 3

Introduccin

sistema de transporte areo, los aviones, las terminales, el equipo deapoyo terrestre y los controles son subsistemas. Los equipos, las per-

sonas y la informacin son componentes. Por ello los mtodos paradesignar sistemas, subsistemas y componentes son relativos, ya queun sistema situado en un nivel jerrquico puede ser el componente deotro de nivel superior. As, para una situacin determinada, es esen-cial definir el sistema considerado especificando claramente sus lmi-tes y fronteras.

El proceso para obtener sistemas (y/o mejorar los existentes),

con independencia del tipo de sistema, es el objetivo principal de estamonografa. A toda nueva y definida necesidad le sigue un proceso.La forma ms lgica de conseguir resultados satisfactorios es fijarseen la totalidad del sistema, considerar las relaciones funcionales desus elementos e integrarlos como un todo. El proceso de desarrollar yproducir sistemas artificiales de forma lgica y ordenada se realizamejor a travs de buena ingeniera de sistemas.

Consustancial a la ingeniera de sistemas es la oportuna y efi-caz integracin de las actividades y medios apropiados, en un proce-so evolutivo que va desde la identificacin de la necesidad del usuariohasta la entrega de un sistema de adecuada configuracin, medianteun proceso arriba-abajo e iterativo de definicin de requisitos, anlisisy asignacin funcional, sntesis, optimizacin, diseo, prueba y eva-luacin. El proceso de ingeniera de sistemas, en su evolucin desde

los detalles funcionales y los requisitos del diseo, tiene por finalidadla obtencin del adecuado equilibrio entre los factores operativos (esdecir, prestaciones), econmicos y logsticos. La mejor manera de lo-grar esto es mediante un esfuerzo multidisciplinar enfocado al diseo.Adems de las caractersticas de prestaciones tradicionales, debeprestarse una especial consideracin en el diseo a factores comofiabilidad, mantenibilidad, factores humanos, capacidad de superviven-cia, apoyo logstico, manufacturabilidad, calidad, desechabilidad, costede su ciclo de vida, y otros afines. La ingeniera de sistemas ayuda aasegurar que estos factores son adecuadamente integrados de forma


14/125


1 4

concurrente en el diseo, desarrollo y produccin de nuevos siste-mas, y/o la modificacin de los existentes.

Aunque las tcnicas y los mtodos asociados a la ingeniera desistemas no son nuevos, no han sido perfectamente ejecutados en elpasado. Por ello se han producido efectos perjudiciales y muchos delos sistemas actualmente en uso no han resuelto las necesidades delusuario, ni su funcionamiento y apoyo han alcanzado la efectividad-coste esperada. Hoy da cuando los recursos disponibles disminuyen yla competencia internacional aumenta, es necesario revisar los con-

ceptos, principios y tcnicas de la ingeniera de sistemas. Por ello, elmotivo de esta monografa es presentar la estructura de la ingenierade sistemas. Tomando a esta monografa como base de partida, es ne-cesario desarrollar otras adicionales destinadas a ampliar los aspectosdetallados de las disciplinas clave que componen el proceso total de laingeniera de sistemas, con objeto de presentar una visin completa deldiseo, desarrollo, produccin, funcionamiento y apoyo de sistemas.


15/125

1 5

Introduccin

1.1. Entorno actual

En general, la complejidad de los sistemas actuales va en au-mento con la aparicin de nuevas tecnologas en un entorno que cam-bia sin cesar; el tiempo que se tarda en transformar una necesidad iden-tificada en el desarrollo de un nuevo sistema operativo es cada vez mslargo; y los costes asociados con el desarrollo, produccin, utilizacin yapoyo de los sistemas estn incrementando. Simultneamente, los re-cursos se van reduciendo y la competencia va aumentando a nivel mun-dial. En resumen, hay un conjunto de factores, como los sealados en

la Figura 1, que constituyen todo un reto en el entorno actual.

Cuando nos fijamos en los aspectos econmicos, nos encon-tramos con que normalmente existe una falta de visibilidad total o cla-ra de los costes, tal como se muestra en el efecto iceberg de laFigura 2. En muchos sistemas, los costes del diseo y desarrollo sonrelativamente bien conocidos; sin embargo, son bastante desconoci-

dos los relativos a su operatividad y apoyo. En esencia los diseadorestratan satisfactoriamente los factores de costes que ms influyen acorto plazo, pero suelen fallar en los correspondientes a largo plazo.Al mismo tiempo, la experiencia ha demostrado que una gran partedel coste total de la vida de un sistema determinado corresponde a lasactividades de funcionamiento y apoyo de las ltimas fases de su vida(por ejemplo hasta el 75% del coste total) [2].

Adicionalmente, cuando se analizan las relaciones causa-efec-to, nos encontramos con que una gran parte del coste del ciclo devida proyectado para un determinado sistema es consecuencia de lasdecisiones tomadas durante las fases de planificacin preliminar ydiseo conceptual del sistema. Las decisiones correspondientes a losrequisitos operativos (por ejemplo, el nmero y localizacin de los em-plazamientos previstos), a las aplicaciones tecnolgicas, a las polti-cas de mantenimiento y apoyo (dos escalones frente a tres de manteni-miento), asignacin de actividades manuales y/o automatizadas, es-quemas de empaquetado de equipo y software, tcnicas de diagnsti-


16/125


1 6

co, seleccin de materiales, conceptos sobre el nivel de reparacin,etc., tienen un gran impacto sobre el coste total del ciclo de vida. As,

mientras se intentan reducir los costes iniciales de un proyecto, mu-chas de las decisiones del diseo y la gestin que se toman en estafase pueden tener efectos catastrficos a largo plazo. En otras pala-bras, la oportunidad de reduccin de los costes totales es mxima enlas primeras fases del desarrollo del sistema. La Figura 3 muestra noslo los compromisos de coste total del ciclo de vida, sino tambin losde arquitectura, aplicaciones tecnolgicas, y filosofa global de diseoa ser implantada.

Para agravar la situacin, en un gran nmero de casos faltaun mtodo disciplinado en la obtencin de nuevos sistemas. Existeuna tendencia generalizada a "disear-ahora-arreglar-despus" uti-lizando el mtodo de bottom-up (mtodo ascendente o de abajo-arriba); a mantener poco clara la definicin de los requisitos en las


17/125

1 7

Introduccin

primeras fases de la obtencin del sistema para introducir cambiosen el diseo ms tarde, preocupndose del control de la configura-

cin el ao prximo; a eliminar determinados puntos crticos en eldiseo y desarrollo del sistema con la idea de ahorrar tiempo ydinero (es decir, los atajos extraoficiales); etc. La experiencia hademostrado que los mtodos de gestin prevalentes aplicados enmuchos casos han sido perjudiciales. Cuntas veces los resultadoshan sido excesivamente costosos por no haber definidoadecuadamente los requisitos al principio, por no haber efectuado elnecesario anlisis para evaluar los riesgos asociados con las deci-

siones adoptadas en las primeras fases del proceso, y por no adop-tar un procedimiento metdico y estructurado en el diseo y desarro-llo de sistemas.

Considerando estas tendencias pasadas y las relaciones exis-tentes entre las caractersticas del sistema y las diversas fases de un


18/125


1 8

programa, es imperativo para los esfuerzos de diseo y desarrollo defuturos sistemas, poner el nfasis sobre: (1) la mejora de nuestros m-

todos para definir los requisitos del sistema que concuerden con lasverdaderas necesidades del usuario, al principio de la fase del diseoconceptual, y las prestaciones, eficacia y todas las caractersticas esen-ciales del sistema; (2) la consideracin del sistema total, sus principalescomponentes de misin y sus elementos de apoyo bajo una perspectivade ciclo de vida; (3) la organizacin y la integracin de la ingenieranecesaria y las disciplinas relacionadas en el esfuerzo de diseo global;y (4) el establecimiento de un mtodo disciplinado que incluya las nor-

mas necesarias para la revisin, evaluacin y realimentacin con el finde asegurar un progresin ordenada, desde la identificacin inicial dela necesidad del usuario hacia adelante. Es esencial para el futuro laimplantacin de la ingeniera de sistemas en la obtencin de nuevossistemas, y/o la mejora o modificacin de los existentes.

1.2. Definicin de ingeniera de sistemas

Una revisin de lo escrito sobre el tema, muestra que no existeuna definicin comnmente aceptada de ingeniera de sistemas.Dependiendo de la experiencia y antecedentes personales de cadauno, el trmino puede ser definido de diversas formas. Sin embargo,con independencia de este hecho, existe una cierta unanimidad en losconceptos, el camino a seguir, y los fines ltimos perseguidos [3]. De

forma general, la ingeniera de sistemas es la aplicacin efectiva demtodos cientficos y de ingeniera para transformar una necesidadoperativa en una configuracin determinada del sistema mediante unproceso de arriba-abajo iterativo (top-down) de establecimiento de re-quisitos, seleccin del concepto, anlisis y asignacin funcional, sn-tesis, optimizacin del diseo, prueba y evaluacin. Est orientado alproceso y utiliza procedimientos de realimentacin y control [4].

La ingeniera de sistemas puede definirse como la aplicacinde tcnicas cientficas y de ingeniera para (1) transformar una nece-


19/125

1 9

Introduccin

sidad operativa en la descripcin de los parmetros de prestacionesde un sistema y en su configuracin mediante la utilizacin de un pro-

ceso iterativo de definicin, sntesis, anlisis, diseo, prueba y eva-luacin; (2) integrar los parmetros tcnicos relacionados y asegurarla compatibilidad de todas las interrelaciones fsicas, funcionales y delprograma de forma que se consiga la mejor definicin y diseo delsistema completo; y (3) integrar los aspectos de fiabilidad,mantenibilidad, seguridad , supervivencia, de personal y otros simila-res en el proceso global de ingeniera para conseguir los objetivostcnicos, de coste y de calendario fijados [5].

Bsicamente, ingeniera de sistemas es BUENA ingenieraorientada al ciclo de vida, que incluye la integracin oportuna de losfactores tcnicos, las relaciones funcionales y las actividades del pro-grama. Estas incluyen las diferentes disciplinas de diseo que se com-binan e integran de tal manera para conseguir el desarrollo y laobtencin de un sistema que cubra las necesidades del consumidor

(ej.: el usuario) de forma efectiva y eficaz. La Figura 4 refleja los mu-chos factores que deben ser considerados e integrados como un todo.

A menudo, al tratar sobre el tema, se utilizan los trminos cien-cia de los sistemas, anlisis de sistemas, e ingeniera de siste-mas de forma indistinta. La ciencia de los sistemas trata principal-mente la observacin, identificacin, descripcin, investigacin expe-rimental, y explicacin terica de los hechos, leyes fsicas,

interrelaciones, etc., asociados con los fenmenos naturales. La cien-cia trata con los conceptos y principios bsicos que ayudan a explicarcmo se comporta el mundo. En un sentido ms exacto, las ramas dela biologa, la qumica, y la fsica cubren muchas de estasinterrelaciones. En cualquier caso, la ingeniera de sistemas incluyela aplicacin de principios cientficos a lo largo del proceso de diseoy desarrollo del sistema [6].

Consustancial con el proceso de la ingeniera de sistemas es larealizacin permanente de un esfuerzo analtico. Existe una variedad


20/125


2 0

de alternativas (soluciones de compromiso) que deben someterse aalgn tipo de evaluacin. Por ejemplo, diferentes escenarios operativos

del sistema, aplicaciones tecnolgicas, diversos conceptos de apoyoy mantenimiento, diferentes esquemas de empaquetado de equipos ysoftware, mtodos alternativos de diagnstico, la disyuntiva entre lautilizacin de personas o sistemas automticos, y otros ms. El proce-so de investigar estas diferentes alternativas del diseo, y la evalua-cin de cada una de ellas atenindose a determinados criterios, es unproceso iterativo.

Para realizar esta actividad de una manera eficaz, el ingeniero(analista) se vale de tcnicas o herramientas analticas disponiblesentre las que se incluyen mtodos de investigacin operativa talescomo la simulacin, las programaciones lineal y dinmica, laoptimizacin, y la teora de colas para resolver problemas. Adems,los modelos matemticos suelen ayudar a realizar los anlisis cuanti-tativos. En resumen, el anlisis de sistemas incluye un proceso anal-


21/125

2 1

Introduccin

tico iterativo para evaluar las diferentes alternativas del diseo (den-tro del contexto del proceso de ingeniera de sistemas), utilizando cuan-

do sea necesario las tcnicas de los modelos matemticos y mtodosanalticos asociados [7] [8].

1.3. Caractersticas de la ingeniera de sistemas

La ingeniera de sistemas per se no es considerada actual-mente como una de las ingenieras tradicionales, como pueden ser la

elctrica, la mecnica, la industrial, la civil, la de fiabilidad, o cualquierotra especialidad de diseo. No tiene necesariamente que organizar-se de forma similar a estas, ni su ejecucin requiere la aplicacin degrandes recursos (es decir, elevados costes). Esencialmente, la apli-cacin de los principios de la ingeniera de sistemas constituye msbien un proceso intelectual, o una forma de organizar trabajos. Re-quiere un cambio de mentalidad para muchos, o un cambio de cultura.

La ingeniera de sistemas es buena ingeniera que pone un nfasisespecial en determinadas reas, y cabe sealar que:

1. Es necesario utilizar un enfoque de arriba-abajo (top-down),viendo al sistema como un todo. Aunque los trabajos de ingeniera delpasado lograron diseos muy satisfactorios de los diferentes compo-nentes de un sistema (representando solamente una trayectoria deabajo-arriba, o bottom-up), carecan sin embargo de la necesaria

visin global y comprensin de cmo deban integrarse eficazmentetodos ellos entre s. La Figura 5 muestra los componentes de un siste-ma que necesitan ser considerados de forma integrada.

2. Es necesario contemplar todo el ciclo de vida del sistema,contemplando todas sus fases, que incluyen el diseo y desarrollo delsistema, la produccin y/o construccin, su distribucin, su vidaoperativa, el apoyo y mantenimiento durante la misma, su baja y reti-rada (desecho). En el pasado la mayor atencin se centraba slo enlas actividades del diseo o adquisicin del sistema, prestando muy


22/125


2 2

poca (o casi ninguna) al impacto que las mismas podran provocar enlos aspectos de produccin, vida operativa, y apoyo logstico. Para

poder evaluar adecuadamente los riesgos asociados con las decisio-nes adoptadas en el proceso inicial de toma de decisiones, es nece-sario que las mismas se basen en consideraciones del ciclo de vida.

3. Un mejor y ms completo esfuerzo es requerido en lo relativoa la definicin de los requisitos del sistema, relacionando dichos re-quisitos con los criterios particulares de diseo basados en estos ob-jetivos, as como un esfuerzo de anlisis continuado para asegurar la

eficacia de las decisiones adoptadas en los primeros momentos de lafase de diseo. Los verdaderos requisitos del sistema deben estarbien definidos y especificados, y debe ser visible la capacidad de se-guimiento de estos requisitos del nivel sistema hacia abajo. Han sidomnimos en el pasado los trabajos de anlisis previos completos, talcomo hoy da se realizan en un gran nmero de nuevos sistemas. Laausencia del establecimiento de una lnea bsica o de referencia

inicial ha resultado en mayores esfuerzos individuales de diseo aguasabajo en el ciclo de vida, muchos de los cuales no fueron bien integra-dos con otras actividades de diseo, necesitando por ello modificacio-nes. Los costes que provocan la introduccin de cambios aguas abajopueden ser muy grandes, tal como se refleja en la Figura 6.

4. Se necesita realizar un esfuerzo multidisciplinar conjunto(o trabajo en equipo), a lo largo del proceso de diseo y desarrollo

de un sistema, para asegurar que se alcanzan todos los objetivosdel diseo eficaz y eficientemente. Para conseguir esto se necesitaun total conocimiento de las variadas y diferentes disciplinas dediseo que intervienen y sus relaciones mutuas, as como los m-todos y tcnicas o herramientas que pueden aplicarse para facilitarel desarrollo del proceso de la ingeniera de sistemas de formaeficaz.

La implantacin con xito de la ingeniera de sistemas requie-re que estos principios (y sus elementos de apoyo) sean seguidos a


23/125

2 3

Introduccin


24/125


2 4

lo largo del proceso de obtencin de sistemas. Para ello debe se-guirse un plan bien pensado, estructurado y ordenado para el dise-

o y desarrollo de nuevos sistemas (y/o la modificacin o mejora delos existentes). La ingeniera de sistemas abarca tanto la ejecucin ydesarrollo de las tcnicas apropiadas como los conocimientos degestin y direccin necesarios para hacerlos realidad.

1.4. Aplicaciones de la ingeniera de sistemas

Los conceptos, principios, mtodos, y tcnicas descritos a lolargo de esta monografa pueden ser aplicados de forma eficaz acualquier tipo de sistema. Si existe la necesidad de realizar o desa-rrollar una funcin, tenemos ya un requisito del sistema. Existensistemas de aviones, de comunicaciones, de distribucin, de infor-macin, de fabricacin, de generacin de energa, de radar, de bar-cos, de transporte, y otros muchos ms. Cada uno de ellos trata de

cubrir una determinada necesidad funcional, tiene unos requisitosde entrada y salida, y hay un proceso que debe seguirse para sudiseo, desarrollo, produccin, y distribucin. Es en este procesodonde pueden aplicarse los mtodos de la ingeniera de sistemas.Sin embargo, las actividades y trabajos a realizar no deben ser par-ticularizadas para cada proyecto concreto ni por exceso ni pordefecto, sino con el nivel de esfuerzo adecuado, seleccionando slolas tareas que sean realmente esenciales y ejecutndolas con la

profundidad necesaria. En esencia, mientras las aplicaciones sonprcticamente ilimitadas, las necesidades particulares de cada pro-yecto sern diferentes. Por otro lado, la seleccin ciega y unifor-me de especificaciones y normas para su aplicacin a lo largo detodo proyecto, puede ser muy costoso y no cumplir con los objeti-vos aqu expuestos.


25/125

2 5

Introduccin


26/125


2 6


27/125

2 7

2El proceso deingeniera de

sistemas


28/125


2 8

Aunque existe un consenso generalizado en lo relativo a losprincipios y objetivos de la ingeniera de sistemas, la forma de desa-rrollar o ejecutar los requisitos en este rea variar de un programa aotro dependiendo de las experiencias y conocimientos individuales delas personas involucradas. Por ello, con objeto de establecer un mar-co de referencia nico con la idea de entenderse mejor, es necesariodefinir una lnea bsica o de referencia que describa tanto el proce-

so para la obtencin de sistemas como algunas de las actividadesclave en l contenidas.

La Figura 7 muestra el ciclo de vida de un sistema tpico, esdecir, el modelo que servir como marco de referencia para las ex-plicaciones posteriores. En ella se muestran las principales fases delprograma (como son la fase del diseo conceptual, la del diseo pre-liminar, etc.) junto con los principales hitos aplicables en la obtencin

de nuevos sistemas (como la configuracin funcional, la configuracinasignada, etc.). Incluye asimismo los pasos bsicos del proceso de laingeniera de sistemas; cabe citar, por ejemplo, el anlisis de requisi-tos y la seleccin del concepto, el anlisis funcional, la asignacin derequisitos, estudios de soluciones de compromiso, sntesis, evaluacio-nes, y otros. En las descripciones de las fases del programa, la figurano especifica ni los perodos de tiempo que pueden durar ni los nive-les de financiacin, ya que los requisitos de cada programa en parti-cular variarn de un caso a otro. La figura refleja el proceso globalque debe seguirse en la obtencin de sistemas. Siempre que surja


29/125


30/125

2 9

El proceso de Ingeniera de Sistemas

una nueva necesidad y se establezcan los requisitos de un nuevosistema, habr cierta actividad de diseo conceptual, diseo prelimi-

nar, etc., hasta llegar al desarrollo de un sistema completamente con-figurado, listo para ser utilizado. La realizacin de las actividades dediseo conceptual pueden constituir desde la asignacin de un redu-cido nmero de personas durante un mes, hasta el empleo de variosexpertos en diversas disciplinas durante perodos de tiempo ms pro-longados. Esto, por supuesto, variar dependiendo del tipo y caracte-rsticas del sistema, de su complejidad, de la proporcin existente en-tre el desarrollo de nuevos diseos o la utilizacin de componentes ya

desarrollados, normalizados y disponibles en el mercado, etc. Seacomo fuere, hay un proceso que debe seguirse a partir de la identifica-cin de una necesidad.

2.1. Requisitos del sistema [9]

Refirindonos a la Figura 7, los trabajos de anlisis de requisi-tos, anlisis funcional y asignacin de requisitos, etc., son iterativospor naturaleza, yendo de la identificacin de una necesidad hasta ladefinicin del sistema en trminos funcionales. Dentro de cada uno delos bloques mostrados, existe un determinado grado de realimenta-cin. Por ejemplo, los estudios de soluciones de compromiso se reali-zan en todos los niveles. Sin embargo, es imposible representar grfi-camente todas las realimentaciones que se pueden producir. Por ello,

el formato representado en la figura sirve como modelo para destacarlas principales tareas que tienen lugar durante el desarrollo de unsistema. En cualquier caso, el proceso es de arriba-abajo y evolutivopor naturaleza, yendo de la definicin a nivel sistema, al nivelsubsistema, y a los principales componentes del sistema. Su finalidades describir los requisitos en cada nivel de la jerarqua del sistema, olo que es lo mismo, los QUE - no los COMO - expresados entrminos de hardware, software, instalaciones, personas, datos, etc.especficos. Los recursos que apoyan los COMO sern la conse-cuencia de desarrollar el anlisis y la asignacin funcional. Por ltimo,


31/125


3 0

los requisitos deben ser completos y describir completamente la ne-cesidad del usuario, deben ser objetivos e incorporables al diseo del

sistema, deben ser medibles y demostrables, etc.

2.1.1. Identificacin de la necesidad

El proceso de ingeniera de sistemas generalmente comienzacon la identificacin de una apetencia o deseo de uno o mselementos, y se basa en una carencia real (o percibida). Por ejemplo,

determinada capacidad actual no es adecuada en trminos de alcan-zar ciertos objetivos de prestaciones, no est disponible cuando se lanecesita, no se la puede apoyar adecuadamente, su utilizacin esdemasiado costosa, etc. O, no se puede establecer el enlace entre lospuntos A y B, transmitir determinado volumen de informacin conun grado x de exactitud, en un determinado entorno, en cierto pe-rodo de tiempo, con un grado y de fiabilidad, y dentro de un coste

z determinado. Como resultado de lo anterior, se define un nuevorequisito para el sistema en unin de una prioridad para su obtencin,de la fecha en que debe estar operativo para el usuario la nueva capa-cidad, as como de una estimacin de los medios necesarios para suobtencin. La determinacin de la necesidad debe expresarse entrminos cualitativos y cuantitativos, con el suficiente detalle que jus-tifique el paso a la siguiente fase.

El requisito de identificar la necesidad parece bsico (evi-dente). Sin embargo, es muy corriente encontrarse con que se iniciandiseos como consecuencia de un inters personal o un capricho po-ltico, sin haberse establecido previamente de forma adecuada susrequisitos. Ms an, a veces se persiguen desarrollos tecnolgicossin tener una idea concreta de su aplicacin viable. Muchas veces elplanteamiento o enunciacin del problema resulta ser la parte ms

difcil del proceso. Sin embargo, una completa descripcin de la ver-dadera carencia as como de la necesidad real es muy necesaria, y esimportante que los resultados reflejen un requisito del usuario. Este


32/125

3 1


objetivo puede facilitarse involucrando al consumidor (o usuario fi-nal) a lo largo de todo el proceso, desde su iniciacin. La aplicacin

de tcnicas, como el despliegue de la funcin de calidad (QualityFunction Deployment, QFD), es apropiada para conseguir el necesa-rio grado de entendimiento, identificando y asignando prioridades aobjetivos concretos, etc.

2.1.2. Realizacin de los estudios de viabilidad

Dada la definicin de una necesidad como muestra la Figura 8,es necesario (1) identificar los diferentes enfoques de diseo a nivelsistema que pueden ser seguidos para alcanzar los requisitos; (2)evaluar los candidatos ms apropiados en trminos de sus prestacio-nes, efectividad, requisitos logsticos, y criterios econmicos; y (3) re-comendar la lnea de accin preferida.


33/125


3 2

Pueden resultar diversas alternativas; sin embargo, el nmerode posibilidades debe limitarse a un nmero reducido de opciones

viables, acordes con los recursos disponibles (como son los de perso-nal, de material y financieros).

Al considerar distintos enfoques de diseo, deben analizarselas diferentes aplicaciones tecnolgicas existentes. Por ejemplo, en eldiseo de un sistema de comunicaciones, se debe usar la fibra pti-ca o el cable fsico convencional? En el diseo de un avin en qumedida deben usarse materiales compuestos? Cuando se disea un

automvil se deben utilizar circuitos integrados de gran rapidez enfunciones de control o debemos inclinarnos por el enfoque electrome-cnico convencional? Al planificar un proceso en qu medida debe-mos incorporar recursos informticos integrados, o emplear la inteli-gencia artificial?

Es en esta etapa inicial del ciclo de vida (o sea, en la fase de

diseo conceptual) en que las principales decisiones adoptadas sonlas que se refieren a un determinado enfoque de diseo, y es en laque los resultados de dichas decisiones tienen su mayor impacto so-bre el coste ltimo del ciclo de vida del sistema. Las aplicacionestecnolgicas son evaluadas, y en algunos casos cuando no existasuficiente informacin, debe iniciarse un proceso de investigacin conobjeto de desarrollar nuevos mtodos o tcnicas para aplicacionesespecficas.

Los resultados del anlisis de viabilidad repercutirnsignificativamente no slo en las caractersticas operativas del siste-ma sino tambin en la manufacturabilidad, soportabilidad,desechabilidad y otras caractersticas anlogas. La seleccin (y apli-cacin) de una tecnologa determinada tiene implicaciones de fiabili-dad y mantenibilidad, puede afectar a los requisitos de fabricacin,puede influir de forma determinante en los equipos de prueba y re-puestos, y ciertamente afectar al coste del ciclo de vida del sistema.De la misma forma, las decisiones relativas a la seleccin de determi-


34/125

3 3


nados procesos, pueden tener implicaciones en el ciclo de vida. Porello, es esencial que el ciclo de vida est siempre presente en este

trabajo de evaluacin. El resultado final de esta actividad conducedirectamente al establecimiento de los requisitos operativos del siste-ma y del concepto de mantenimiento y, finalmente, se ver reflejadoen la especificacin del sistema (del Tipo A, ver Figura 7).

2.1.3. Definicin de los requisitos operativos del sistema

Con el anlisis de la necesidad, combinado con la seleccindel enfoque tcnico, es necesario transformar esta informacin en tr-minos de requisitos operativos previos. Tales requisitos deben con-templar los siguientes aspectos:

a. La distribucin o despliegue operativo- el nmero de empla-zamientos en los que se utilizar el sistema, la distribucin geogrfica

y el calendario, as como el tipo y nmero de componentes del siste-ma a situar en cada emplazamiento. Todo ello es la respuesta a lapregunta - donde se va a utilizar el sistema? La Figura 9 muestra unejemplo de un despliegue mundial.

b. Perfil o escenario de la misin - identificacin de la misinprincipal del sistema, y sus misiones alternativas o secundarias. Qudebe realizar el sistema en respuesta a la necesidad? Esto puede

expresarse a travs de una serie de perfiles operativos, que ilustrenlos aspectos dinmicos necesarios para desarrollar una misin. Sonejemplos, el perfil de vuelo de un avin entre dos ciudades, la trayec-toria a recorrer por un automvil, y la derrota a seguir por un barco. LaFigura 10 muestra un ejemplo simple de perfiles posibles.

c. Prestaciones y parmetros relacionados- definicin de las

caractersticas operativas o funciones bsicas del sistema. Se refierea parmetros como alcance o autonoma, precisin, tasa, capacidad,volumen procesado, potencia de salida, dimensin, y peso. Cuales


35/125


3 4

son los parmetros crticos de prestacin del sistema necesarios paradesarrollar su misin en los diferentes emplazamientos del usuario?Adicionalmente, cmo se relacionan dichos valores con los perfilesde misin de la Figura 10?

d. Requisitos de utilizacin- uso previsto del sistema, y sus

componentes, en el desempeo de su misin. Se refiere a horas deutilizacin del equipo por da, tiempo ciclo, ciclos de utilizacin-inacti-vidad, porcentaje de capacidad total empleada, carga de instalacio-nes, etc. Hasta que lmite se utilizarn los diferentes componentesdel sistema? Esto conduce a calcular algunas de las solicitacionesimpuestas al sistema por el usuario.

e. Requisitos de efectividad- requisitos del sistema, expre-sados cuantitativamente segn sea aplicable, incluyendo efectivi-dad/coste del sistema, disponibilidad operativa, seguridad de mi-


36/125

3 5


sin, tiempo medio entre fallos (Mean Time Between Failures,MTBF), tasa de fallos ("l"), tasa de alistamiento, tiempo de inactivi-

dad por mantenimiento (Maintenance Down Time, MDT), tiempo me-dio entre acciones de mantenimiento (Mean Time BetweenMaintenance, MTBM), utilizacin de instalaciones (en tanto por cien-to), niveles de cualificacin del personal, costes, y otros similares.Sabiendo que el sistema funcionar qu efectividad o eficienciase espera de l?

f. Ciclo de vida operativo (horizonte)- tiempo estimado que se

espera est el sistema en uso operativo. Cuanto tiempo utilizar elsistema el usuario? Cual es el perfil total de inventario necesariopara el sistema y sus componentes, y donde se situar dicho inventa-rio? Debe definirse el ciclo de vida del sistema. Aunque el inventariovariar segn se aumente o reduzca el ciclo de vida del sistema, esnecesario fijar en este punto una lnea de referencia.


37/125


3 6

g. Entorno- definicin del entorno en el que se espera opere elsistema de forma efectiva, por ejemplo: temperatura, vibraciones y

choques, ruidos, humedad, condiciones rticas o tropicales, terrenollano o montaoso, aerotransportado, terrestre y embarcado. Despusun conjunto de perfiles de misin pueden resultar en la especificacinde un rango de valores. A qu estar sujeto el sistema durante suutilizacin, y por cunto tiempo? Adems del funcionamiento del sis-tema, las consideraciones ambientales deben incluir modos de trans-porte, manejo y almacenamiento. Es posible que el sistema (y/o algu-no de sus componentes) est sujeto a un entorno ms riguroso duran-

te el transporte que durante su funcionamiento.

El establecimiento de los requisitos operativos forma la basepara el diseo del sistema. Obviamente, se necesitan respuestas alas siguientes preguntas antes de proseguir:

1. Qu funcin o funciones desarrollar el sistema?

2. Cundo ser requerido el sistema para realizar su fun-cin y durante cuanto tiempo?

3. Dnde se utilizar el sistema?

4. Cmo cumplir su objetivo el sistema?

La respuesta a estas preguntas debe establecer la lnea dereferencia. Aunque las condiciones pueden cambiar, es necesario es-tablecer unos supuestos iniciales. Por ejemplo, los componentes delsistema sern utilizados de forma distinta en los diferentes emplaza-mientos de los usuarios, la distribucin de dichos componentes puedevariar segn varen las necesidades operativas, y/o la duracin delciclo de vida puede cambiar como consecuencia de la obsolescenciadel sistema o por criterios competitivos. An as, el mtodo descritoanteriormente debe ser realizado para poder seguir con el diseo delsistema.


38/125

3 7


2.1.4. Desarrollo de los conceptos de apoyo y mantenimiento [10]

Cuando se analizan los requisitos del sistema, la tendencia nor-mal es comenzar por fijarse en aquellos elementos del sistema queestn relacionados directamente con la ejecucin de la misin, esdecir: equipos principales, personal operador, software operativo, einformacin relacionada. Al mismo tiempo se presta poca atencin alos conceptos de mantenimiento y apoyo del sistema. En general, elnfasis en el pasado se centraba slo sobre parte del sistema, y nosobre la totalidad del mismo, como se estableci previamente. Esto ha

sido obviamente la causa de algunos de los problemas tratados en laSeccin 1.1.

Para cumplir con los objetivos generales de la ingeniera desistemas, es esencial que todos los aspectos del sistema sean consi-derados bajo un enfoque integrado desde el principio. Esto incluye noslo a los elementos relacionados con la misin principal del sistema,sino tambin la capacidad de apoyo. Los principales elementos delsistema deben disearse de tal forma que puedan ser apoyados efi-caz y eficientemente durante el ciclo de vida previsto, y la capacidadglobal de apoyo debe responder a este requisito. Esto significa que sedeben considerar las caractersticas del diseo en lo relativo a la redde apoyo (es decir: repuestos, reparables y consideraciones de in-ventario), equipos de apoyo y prueba, equipo de transporte y manejo,recursos informticos (como el software), personal y adiestramiento,

instalaciones, y datos tcnicos. Por tanto, es esencial que durante lafase del diseo conceptual sea desarrollado un concepto de apoyo ymantenimiento del sistema.

El concepto de mantenimiento se desarrolla partiendo de ladefinicin de los requisitos operativos del sistema (ver Seccin 2.1.3.),e incluye las acciones reflejadas en la Figura 11. Constituye una seriede ilustraciones y aseveraciones sobre cmo debe ser diseado elsistema para que sea apoyable, mientras que el plan de manteni-miento define los sucesivos requisitos de apoyo del sistema basados


39/125


3 8

en los resultados de los anlisis de apoyo logstico u otros estudiossimilares [10]. El concepto de mantenimiento se plasma finalmente enun plan de mantenimiento detallado. Refirindonos a la figura, se debetratar el flujo de materiales y actividades desde el diseo, pasando porla fabricacin, hasta los lugares de uso operativo. Se produce un flujode mantenimiento cuando los componentes son enviados desde suemplazamiento operativo a las instalaciones de mantenimiento de

segundo o tercer escaln.

Revisando la red en conjunto, se deben considerar aspectostales como los niveles de mantenimiento, las responsabilidades y fun-ciones a desarrollar en cada nivel, los criterios de diseo relativos alos diferentes elementos de apoyo (por ejemplo, tipo de repuestos yniveles de inventario, fiabilidad de los equipos de prueba, cantidadesy cualificaciones del personal), as como los factores de efectividadde la capacidad global de apoyo. Aunque pueda parecer que el dise-o de los principales componentes de un sistema es el adecuado, la


40/125

3 9


habilidad total del sistema para cumplir satisfactoriamente su misindepende en gran medida de la estructura y eficacia del apoyo.

Aunque pueden existir variaciones, dependiendo de la natura-leza y tipo de sistema, el concepto de mantenimiento generalmenteincluye la siguiente informacin:

a. Niveles de mantenimiento - el mantenimiento, preventivo ocorrectivo, puede realizarse sobre el mismo sistema (o sobre un ele-mento del mismo) en su lugar de utilizacin por el usuario, en una

instalacin de segundo escaln, prxima a dicho emplazamiento, o enuna instalacin de tercer escaln o del fabricante. Los niveles demantenimiento conciernen a la divisin de funciones y tareas de cadarea en la que se ejecute el mantenimiento. La frecuencia prevista demantenimiento, la complejidad de las tareas, los requisitos decualificacin del personal, necesidades de instalaciones especiales,etc, dictan en gran medida las funciones especficas que deben ser

desarrolladas en cada nivel. Dependiendo de la naturaleza y misindel sistema, pueden establecerse dos, tres y hasta cuatro niveles demantenimiento. En cualquier caso, para facilitar las siguientesdescripciones clasificaremos el mantenimiento como de primer, se-gundo y tercer escaln. La Figura 12 describe las diferencias bsi-cas entre estos niveles.

b. Polticas de reparacin - dentro de las limitaciones ilustradas

en las Figuras 11 y 12, puede haber un nmero de polticas posiblesque especifiquen el grado en que puede realizarse la reparacin deun componente del sistema (caso de que exista). Una poltica de repa-racin puede dictar que un elemento sea designado como no repara-ble, parcialmente reparable, o totalmente reparable. Las polticas dereparacin se establecen inicialmente, se desarrollan criterios, y eldiseo del sistema progresa enmarcado en la poltica de reparacinseleccionada. Un ejemplo de una poltica de reparacin para un Siste-ma XYZ, desarrollada como parte del concepto de mantenimiento du-rante la fase del diseo conceptual, se describe en la Figura 13.


41/125


4 0

c. Responsabilidades orgnicas - la ejecucin del mantenimientopuede ser responsabilidad del usuario, del fabricante (o suministra-dor), de terceros, o de una combinacin de ellos. Adems, estas res-ponsabilidades pueden variar, no slo con respecto a diferentes com-ponentes del sistema, sino a medida que se progresa en la fase operati-va y de apoyo al sistema. Las decisiones relativas a responsabilida-

des orgnicas influirn en el diseo del sistema desde un punto devista de diagnstico y empaquetado, de polticas de reparacin, clu-sulas de garanta de los contratos, y otros aspectos afines. Aunquepuedan cambiar las condiciones, es necesario definir en esta faseunos supuestos iniciales.

d. Elementos de apoyo logstico - como parte de la definicin delconcepto de mantenimiento inicial, deben establecerse los criterios re-lativos a los distintos elementos de apoyo logstico. Estos elementosincluyen el aprovisionamiento (repuestos y reparables, inventarios aso-


42/125

4 1


ciados, datos de aprovisionamiento), equipos de apoyo y prueba, per-sonal y entrenamiento, equipo de transporte y manejo, instalaciones,

datos tcnicos y recursos informticos. Tales criterios, como datos deentrada al diseo, pueden incluir provisiones de autodiagnstico, requi-sitos de prueba incorporados (built-in) y/o externos, factores denormalizacin y empaquetado, cantidad y cualificacin de personal, fac-tores y limitaciones de transporte y manejo, etc. El concepto de mante-nimiento proporciona algunos criterios iniciales de diseo del sistemarelativo a las actividades reflejadas en la Figura 11, mientras que ladeterminacin final de requisitos especficos de apoyo logstico se pro-

ducirn a travs de la realizacin del anlisis de apoyo logstico (LogisticsSupport Analysis, LSA), que se realiza segn progresa el diseo.

e. Requisitos de efectividad - constituyen los factores de efecti-vidad asociados a la capacidad de apoyo. En el rea del apoyo logstico,esto puede incluir una tasa de demanda de repuestos, la probabilidad


43/125


4 2

de que un repuesto est disponible cuando se necesite, la probabili-dad de xito de una misin para un determinado nmero de repues-

tos, y la cantidad econmica de pedido en relacin con la adquisi-cin de inventarios. En lo relativo a los equipos de prueba son facto-res determinantes la longitud de la cola de equipos que esperan serprobados, el tiempo de procesado de la estacin de prueba y la fia-bilidad del equipo de prueba. En lo que concierne al transporte sonsignificativos la tasa esperada, sus duraciones, fiabilidad y costes.En cuanto al personal y su adiestramiento, debe considerarse nme-ro y cualificacin del personal, niveles de su formacin, tiempo de

formacin y fiabilidad de los equipos de adiestramiento. El nmerode errores por lnea de cdigo puede ser una medida importante enel caso del software. Estos factores deben considerarse en relacincon requisitos especficos a nivel sistema. No tiene sentido especifi-car unos requisitos muy exigentes para la reparacin de elementosprincipales de un sistema si se tarda 6 meses en conseguir un re-puesto necesario. Los requisitos de efectividad aplicables a la capa-

cidad de apoyo deben ser un complemento de los de la totalidad delsistema.

f. Entorno - definicin del entorno en lo referente al manteni-miento y apoyo. Esto incluye temperatura, vibraciones y choques, hu-medad, ruidos, entornos rticos o tropicales, terrenos llanos o monta-osos, entornos martimos o terrestres, etc., aplicado a las tareas demantenimiento y funciones relacionadas de transporte, manejo y

almacenamiento.

Resumiendo, el concepto de mantenimiento constituye la basepara el establecimiento de los requisitos de soportabilidad en el dise-o del sistema. Dichos requisitos no solo influyen sobre los elementosprincipales del sistema, sino que adems deben proporcionar gua enel diseo y/o adquisicin de los elementos necesarios de apoyologstico. Adems, el concepto del mantenimiento constituye la basepara el desarrollo del plan de mantenimiento detallado, que se prepa-rar durante la fase del diseo detallado y desarrollo.


44/125

4 3


2.1.5. Desarrollo y asignacin de prioridades de medidas de

prestaciones tcnicas

Tomando como base los requisitos operativos y el concepto demantenimiento se desarrollan criterios cualitativos y cuantitativospara el diseo. Son especialmente interesantes los factores cuan-titativos o mtricas asociadas al sistema que se est desarrollando.Estas mtricas, que se suelen denominar medidas de prestacionestcnicas (Technical Performance Measures, TPMs) o parmetrosdependientes del diseo, deben fijarse inicialmente como parte del

proceso de definicin de requisitos durante el diseo conceptual.Las TPMs adecuadas deben identificarse para cada nivel de la es-tructura jerrquica del sistema e incluirse en la especificacin delsistema (Tipo A), deben ser inherentes al subsiguiente procesode revisin y evaluacin del programa y medirse por medio de larealizacin de diversos anlisis y predicciones, y deben ser verifica-das ms tarde a travs de la prueba y evaluacin del sistema. Estosfactores (o sea, los valores especificados en cada caso) influirnsobre las tecnologas seleccionadas para el diseo, el empaquetadodel sistema y la seleccin de componentes, las herramientas/mode-los utilizados para los anlisis y sntesis del diseo, etc.

Para identificar las TPMs, se debe partir de una estructura globalcomo la mostrada en la Figura 14. En todo sistema, estn los factorestcnicos, representados aqu como efectividad del sistema, que son

una funcin de sus prestaciones, disponibilidad, fiabilidades de mi-sin, capacidad, fiabilidad, mantenibilidad, manufacturabilidad,desechabilidad, y otros factores similares que pueden relacionarsedirectamente con los requisitos operativos y el concepto del manteni-miento del sistema. Al otro lado del espectro est el aspecto del coste,que debe ser considerado desde una perspectiva de ciclo de vida.Aunque existen diversas categoras de costes utilizadas diariamenteen el proceso de toma de decisiones (como costes de obtencin oadquisicin, costes de produccin y/o construccin, costes operativosy de apoyo, costes de retirada, etc.), deben ser vistos en el contexto


45/125


4 4

del coste total del ciclo de vida. Esto es necesario si el aspecto delriesgo, asociado con las consecuencias de decisiones, va a serdebidamente considerado.

Refirindonos a la Figura 15, debe desarrollarse un rbol deobjetivos (o un enfoque equivalente), comenzando con un grupo dedescriptores generales y continuando con un desarrollo de arriba-abajo.

Lo que se pretende es partir de un objetivo general del sistema consi-derado como un todo, y entonces desarrollar algunos modificadoresque apoyen este objetivo del mximo nivel. Esto, por contra, estableceun marco de referencia para la posterior asignacin de los criterios dediseo cualitativos y cuantitativos.

Dada la identificacin de criterios cuantitativos (es decir, medi-

das de prestaciones tcnicas), deben establecerse las prioridadesadecuadas, tal como lo aprecie el usuario. Mediante un trabajo en equi-po, involucrando al personal adecuado del cliente y del contratista, las


46/125

4 5


TPMs deben ser priorizadas con el fin de identificar los criterios de dise-o que deben introducirse para cumplir, lo ms fielmente posible, lasnecesidades del usuario. Estos criterios deben incluirse en las especifi-caciones adecuadas, empezando por la especificacin del sistema ydescendiendo a travs de las especificaciones de los diferentessubsistemas, productos, procesos y/o materiales, que sean necesarias.Los principales factores deben, por supuesto, recibir la mxima aten-

cin de los gerentes y los ingenieros de diseo, y deben ser considera-dos en el plan de gestin de riesgos del programa (o equivalente). LaFigura 16 presenta un esquema reducido de este enfoque. Ntese quelas responsabilidades de entradas de diseo y de seguimiento deestas TPMs a travs del proceso de desarrollo del sistema estn ali-mentadas con diversos componentes de la organizacin del proyecto.

Ingrediente importante en la realizacin del proceso de anlisisy definicin de requisitos, que es tambin reiterativo por naturaleza,es la comunicacion necesaria que debe existir entre el usuario (ej.: el


47/125


4 6

cliente) y el fabricante (ej.: el contratista). Debe establecerse un traba-jo en equipo para realizar una transicin efectiva de la especificacin

de necesidad del usuario en la definicin de los criterios de diseo. Elempleo de una tcnica como el despliegue de la funcin de calidadpuede facilitar las necesarias comunicaciones [12].

2.1.6. Elaboracin de la especificacin del sistema (Tipo A)

Desde la perspectiva de la ingeniera de sistemas, el documen-

to ms importante de un determinado programa, en lo que se refiere aldiseo, es la Especificacin del Sistema (Tipo A). La Figura 7 des-cribe la configuracin funcional bsica y constituye el primer paso enla implantacin de un enfoque disciplinado en el diseo y desarrollode un sistema. Incluye los resultados del proceso de anlisis de requi-sitos, y conduce a los requisitos de diseo de subsistemas y otroscomponentes del sistema. Bsicamente es el cimiento a partir del


48/125

4 7


cual se deriva la totalidad de los requisitos tcnicos. La Figura 17presenta un ejemplo de lo que puede ser incluido en la especificacin

de un sistema.

En multitud de proyectos, la especificacin del sistema es de-masiada vaga y no describe los requisitos de forma definitiva. Esto sehace a veces intencionadamente para poder introducir ms tarde nue-vos requisitos o tecnologas durante el ciclo de vida. Al mismo tiempose preparan y negocian contractualmente especificaciones de ms bajonivel (como son las especificaciones del producto, del proceso, del

software, y/o del material), y el diseo detallado de los subsistemas ycomponentes progresa sin el beneficio de tener un slido cimientosobre el que construir. Cuando los diferentes componentes son final-mente integrados de abajo-arriba, se producen desajustes,incompatibilidades, etc. Esto se convierte generalmente en un proce-so costoso. Por ello es fundamental que sea preparada y seguida fiel-mente desde el principio una buena y completa especificacin del sis-

tema [13].

2.2. Anlisis funcional y asignacin de requisitos

El siguiente paso en el proceso de ingeniera de sistemas es latransformacin de los requisitos del sistema en criterios detallados dediseo y la identificacin de los requisitos de recursos especficos a

nivel subsistema e inferior. Esto se realiza mejor por medio del an-lisis funcional. Una funcin se refiere a una accin concreta o espe-cfica que debe desarrollar el sistema para cumplir un objetivo dado;por ejemplo, la operacin que un sistema debe realizar para cumplirsu misin, o la accin de mantenimiento necesaria para devolver elsistema a condicin operativa. Tales acciones pueden ser realizadasa travs de la utilizacin de equipos, software, personas, instalacio-nes, datos, o una combinacin de ellos. No obstante, el objetivo eneste momento es el especificar los QU y no los CMO; o sea,qu es necesario realizar en vez de cmo debe realizarse. No debe


49/125


4 8


50/125

4 9

identificarse ni adquirirse ningn equipo, elemento de software, ele-mentos de datos, o elemento de apoyo logstico si no ha sido justifica-

do a travs del anlisis funcional.

El anlisis funcional constituye el proceso iterativo de estructuraro descomponer los requisitos del nivel sistema, a los subsistemas, y tanabajo en la estructura jerrquica como sea necesario para identificar losrecursos especficos y los distintos componentes del sistema. Represen-ta una definicin del sistema (y actividades asociadas) en trminos fun-cionales e incluye funciones del sistema, de produccin, de utilizacin,

de mantenimiento y apoyo, etc. La realizacin del anlisis funcional sefacilita mediante el uso de diagramas de bloque de flujos funcionales. LaFigura 18 muestra un diagrama de flujo simplificado con cierta descom-posicin. Las funciones de alto nivel se descomponen en las de segundonivel, las funciones operativas conducen a las de mantenimiento, y seemplea la numeracin de bloques para proporcionar capacidad de



51/125


5 0

seguimiento, tanto descendente como ascendente, de los requisitos.

La Figura 19 ilustra el proceso de evolucin, desde la defini-cin de la necesidad a la identificacin del escenario para una capa-cidad de transporte, y al anlisis funcional. Las funciones operativasconducen a la descripcin de funciones de mantenimiento (ver blo-que 9.5.1.). La Figura 20 muestra un ejemplo en el que uno de losbloques del diagrama de flujo es evaluado en trminos de entradas,salidas, controles y/o limitaciones, y mecanismos facilitadores. N-tese que las expresiones de cada bloque estn orientadas a accio-

nes, y que los mecanismos bsicamente conducen a la identifi-cacin de los recursos necesarios para desarrollar la funcin; porejemplo, un equipo, un elemento de software, una herramienta deanlisis del diseo, una instalacin, personas, datos de informacin,u otros cualesquiera. La Figura 21 muestra un ejemplo de formateadode datos. Esto, por supuesto, debe ser adaptado a los requisitosespecficos de un programa dado [14].

Los diagramas de bloques funcionales se desarrollan princi-palmente con objeto de estructurar los requisitos del sistema en trmi-nos funcionales, y sirven para ilustrar la organizacin del sistema eidentificar las principales interfaces funcionales. El anlisis funcional,iniciado durante las ltimos pasos del diseo conceptual, est orien-tado a permitir la finalizacin del proceso de diseo y desarrollo delsistema de una forma completa y lgica. Ms concretamente, el enfo-

que funcional ayuda a asegurar lo siguiente:

1. Que se han considerado todas las facetas del diseo ydesarrollo, produccin, utilizacin, y apoyo del sistema, es decir,todas las actividades significativas durante el ciclo de vida del sis-tema.

2. Que estn completamente reconocidos y definidos todos loselementos del sistema, como los equipos principales, los repuestosy los reparables, el equipo de apoyo y prueba, instalaciones, el per-sonal, los datos y el software.


52/125


53/125

5 1


3. Que existe un medio para relacionar conceptos de empa-quetado y requisitos de apoyo del sistema con funciones especficas

del mismo; o sea, satisfacer los requisitos de buen diseo funcional.

4. Que se establecen las adecuadas secuencias de relacionesde actividades y diseo, junto con las interfaces crticas de diseo. Elanlisis funcional proporciona una descripcin inicial del sistema y,como tal, tiene mltiples aplicaciones. Por ejemplo, el anlisis funcio-nal se utiliza como entrada en el desarrollo de los siguientes requi-sitos, aplicables a la mayora de los programas:

1. Diseos elctricos y mecnicos de empaquetado fun-cional, seguimiento de funcionamiento y provisionesde diagnstico.

2. Modelos de fiabilidad y diagramas de bloques.3. Anlisis de modos de fallos, sus efectos y su criticidad

(Failure Modes, Effects, and Criticality Analysis, FMECA).

4. Anlisis de rbol de fallos (Fault Tree Analysis, FTA).5. Mantenimiento centrado en la fiabilidad (Reliability-centered Maintenance, RCM).

6. Anlisis de riesgos/seguridad del sistema.7. Anlisis de mantenibilidad.8. Anlisis de nivel de reparacin.9. Anlisis de tareas de mantenimiento (Maintenance Task

Analysis, MTA).

10. Anlisis de tareas de operador (Operator Task Analysis,OTA).

11. Diagramas de secuencia de acciones (OperationalSequence Diagrams, OSDs).

12. Anlisis de apoyo logstico (Logistic Support Analysis,LSA).

13. Instrucciones de utilizacin y mantenimiento.

En el pasado, el anlisis funcional, no ha sido siempre realiza-do en el momento adecuado, si es que se realizaba. Como conse-


54/125


5 2

cuencia de ello, las diferentes disciplinas de diseo asignadas a unprograma determinado han tenido que generar sus propios anlisis

para cumplir con los requisitos del mismo. En gran cantidad de casos,estos esfuerzos se realizaban de forma independiente, y muchas de-cisiones de diseo se tomaban sin el beneficio de tener una lnea dereferencia que seguir. Por supuesto, esto resultaba en discrepanciasde diseo y costosas modificaciones en momentos posteriores del ci-clo de vida del sistema. De aqu, el anlisis funcional es necesario yproporciona una excelente lnea de referencia y todas las actividadespertinentes de diseo deben seguir la misma fuente de datos (como

puede ser la definicin de la configuracin del sistema) para satisfa-cer los objetivos de la ingeniera de sistemas. Por esta razn, el an-lisis funcional es considerado una de las actividades fundamentalesen el proceso de ingeniera de sistemas.

Dada una descripcin de alto nivel del sistema en trminos fun-cionales, el paso siguiente es combinar, o agrupar, las funciones simi-

lares en subdivisiones lgicas, identificando los principales subsistemasy componentes de los niveles inferiores de la totalidad del sistema (eldesarrollo de un esquema de empaquetado funcional del sistema).Esto resulta en la identificacin inicial de equipos, software, medioshumanos, instalaciones, datos, o sus combinaciones. La Figura 22muestra (conceptualmente) la evolucin de un diagrama de flujo defunciones operativas a un esquema recomendado de empaquetado;esto es, a la Unidad A, la Unidad B, y la Unidad C que pueden

estar constituidas por equipos fsicos, software, o entidades equiva-lentes.

La Figura 23 muestra el flujo de actividades del proceso deadquisicin, conduciendo de la lnea de referencia sealada en la Fi-gura 7 a los ciclos individuales de desarrollo para varios elementosdel sistema. En este caso, se muestra la integracin de los desarrollosde los ciclos de vida de los equipos, el software y los recursos huma-nos del sistema, partiendo del anlisis funcional (Bloque 0.2 de laFigura 7). Ntese que stos son los nicos componentes del sistema


55/125


56/125


57/125

5 3


que deben contemplarse; sin embargo, son ellos los principales res-ponsables del coste del sistema, y son los que deben ser adecuada-

mente integrados a lo largo del diseo y desarrollo del sistema.

La Figura 24 presenta una descomposicin de los componen-tes del sistema en forma jerrquica, que establece una estructura queconduce a la asignacin de requisitos (Bloque 0.3 de la Figura 7).Asignacin es la descomposicin de los requisitos a nivel sistema,efectuada de forma descendente hasta el nivel necesario que propor-cione una entrada comprensible para el diseo y/o la adquisicin de

un determinado componente del sistema. Como se ve en la figura, espreciso especificar detalladamente los requisitos de diseo cualita-tivos y cuantitativos de los equipos, el software, etc., basados en losrequisitos especificados a nivel sistema. Dada una medida de presta-cin tcnica, tal como el tiempo medio entre acciones de manteni-miento (MTBM), cules deben ser los requisitos de MTBM al nivel delas unidades? Inversamente, los requisitos de MTBM de las diferentes

unidades, cuando sean combinados, deben cumplir los requisitos deTPM a nivel sistema si ste va a cumplir su misin. Esto es un procesoarriba-abajo/abajo-arriba, mostrando la capacidad de seguimientode los requisitos hacia abajo y hacia arriba. En muchos casos en elpasado se ignor la parte arriba-abajo de este ciclo. En otras pala-bras, se haba asumido el proceso abajo-arriba, estableciendo prime-ro los requisitos de los niveles inferiores y esperando que los resulta-dos finalmente respondieran a las necesidades del usuario. Esto, por

supuesto, es un enfoque de alto-riesgo.

Como ltimo paso, es crtico que las adecuadas TPMs seanincluidas en las diferentes especificaciones de diseo y/o adquisicinde componentes del sistema. La Figura 25 transmite la aplicacin deTPMs a los diferentes niveles jerrquicos del sistema. Partiendo delrbol de objetivos (Figura 15) como ayuda del proceso de empaqueta-do y asignacin funcional (Figura 24), los criterios adecuados de dise-o cualitativos y cuantitativos deben incluirse en las especificacionesaplicables. Si debe ser desarrollado un nuevo elemento los requisitos


58/125


59/125


60/125


61/125

5 5


prestaciones tcnicas), seleccionar las tcnicas de evaluacin ade-cuadas, seleccionar o desarrollar el modelo que facilite la evaluacin,

obtener los datos necesarios de entrada, evaluar cada uno de los can-didatos considerados, realizar un anlisis de sensibilidad e identificarreas potenciales de riesgo. Este proceso puede ser adaptado yaplicado en cualquier punto del ciclo de vida mostrado en la Figura 7.

Con referencia a la Figura 26, un paso crtico en la realizacinde un anlisis determinado es la seleccin del modelo o herramientaadecuada. El modelo seleccionado debe: (1) representar el mundo

real tal y como aplique al problema que trata de resolverse; (2) repre-sentar los aspectos dinmicos de la configuracin del sistema que seevala; (3) ser completo por incluir todos los factores relevantes; (4)ser fiable en trminos de repetibilidad de resultados; (5) ser de estruc-tura lo suficientemente simple como para permitir su oportuna utiliza-cin en la resolucin de problemas; (6) ser diseado de tal forma queel analista pueda evaluar la configuracin aplicable del sistema como

................................ ................................ ................................


62/125


5 6

una entidad, analizar diferentes componente del sistema de forma in-dividual, y luego integrar los resultados en el conjunto; y (7) ser dise-ado para incorporar provisiones de modificacin y/o crecimiento parapermitir la evaluacin de factores adicionales cuando sea necesario.Un objetivo importante es seleccionar y/o desarrollar una herramientaque facilite la evaluacin de la configuracin global del sistema, ascomo de las interrelaciones de sus distintos componentes.

Segn un reciente estudio, hay ms de 350 modelosinformticos disponibles en el mercado, que desarrollan diferentesfunciones [4]. Cada uno de los modelos identificados fue desarrolla-do de forma independiente o aislada en trminos de platafor-mas seleccionadas, lenguajes informticos o contextos, requisitosde datos de entrada, grados de facilidad de manejo, etc. En gene-ral, los modelos identificados no se hablan entre s, son complejosy requieren demasiados datos de entrada, son de difcil manejo yslo pueden ser utilizados en las ltimas fases del proceso de


63/125


64/125

5 7


obtencin (es decir, en los ltimos momentos del diseo detallado ydesarrollo). Esto no es inesperado, ya que los modelos fueron desa-

rrollados principalmente por contratistas en respuesta a necesida-des percibidas. Al mismo tiempo, muchos diseadores y responsa-bles de proyectos buscaban herramientas que pudiesen resolver deforma automtica algunos problemas detallados (contra seleccionaruna herramienta que pueda ser utilizada en muchas situaciones di-ferentes). El enfoque abajo-arriba ha sido predominante en la selec-cin de herramientas de diseo.

Desde una perspectiva de ingeniera de sistemas, un buen ob-jetivo es seleccionar y/o desarrollar una estacin de trabajo integradade diseo, que pueda ser utilizada en todas las fases de la obtencindel sistema y que pueda ser adaptada para considerar los diferentesniveles de definicin del diseo a medida que se progrese desde lafase de definicin de requisitos a travs del diseo detallado y desa-rrollo detallado (ver Figura 7). Adems, debe existir una capacidad por

la cual las herramientas utilizadas en un programa determinado pararesolver diferentes problemas se hablen entre s, y puedan conectar-se adecuadamente a la estacin de trabajo centralizada de diseo. LaFigura 27 transmite un enfoque que muestra la integracin de un con-junto seleccionado de modelos informticos. Con tal esquema integra-do, el ingeniero de sistemas ser capaz de realizar ms anlisis fronta-les, investigar pronto muchas ms alternativas posibles de diseo, ydesarrollar la configuracin preferida en un perodo de tiempo mucho

ms corto al tiempo que se reducen los riesgos aguas abajo. Final-mente, la seleccin de las herramientas o modelos informticos ade-cuados debe ser el resultado del anlisis funcional y la identificacin delas mejores prcticas, como se ilustra en la Figura 21.

El anlisis conduce a la sntesis. La sntesis es la combinaciny estructuracin de los componentes de tal forma que representenuna configuracin viable del sistema. Han sido establecidos los requi-sitos bsicos del sistema, se han realizado algunos estudios de solu-ciones de compromiso, y se ha desarrollado una configuracin de re-


65/125


5 8

ferencia para demostrar los conceptos anteriormente presentados.

La sntesis es diseo. Inicialmente, la sntesis se utiliza en eldesarrollo de conceptos preliminares y para establecer las relacionesbsicas entre los distintos componentes del sistema. Ms tarde, cuan-

do se dispone de la suficiente definicin y descomposicin funcional,la sntesis se utiliza para definir an ms los COMO, en respuesta alos QUE del anlisis funcional. La sntesis incluye la seleccin deuna configuracin que pueda ser representativa de la forma que final-mente adoptar el sistema, aunque ciertamente no debe asumirse unaconfiguracin final en este momento.

Dada una configuracin resultante de la sntesis, deben eva-luarse las caractersticas de esta configuracin en trminos de losrequisitos especificados inicialmente. Se inician los cambios requeri-


66/125

5 9


dos, que conduzcan a la configuracin de diseo preferida. Refirin-donos a la Figura 7, este proceso iterativo de anlisis, sntesis, eva-

luacin, y optimizacin del diseo conduce inicialmente al estableci-miento de la configuracin funcional (Hito I), despus a la configura-cin asignada (Hito II), y finalmente a la configuracin del producto(Hitos III y IV).

2.4. Integracin del diseo

Con relacin a la definicin de ingeniera de sistemas (Seccin

1.2.), uno de los objetivos clave es la necesaria integracin y concu-rrencia diaria de las distintas actividades del diseo tanto a lo largocomo despus del proceso de obtencin del sistema. Como se mues-tra en la Figura 4, puede haber muchas disciplinas diferentes de dise-o (representando las diversas reas de especialidad) requeridas paraun programa determinado. Estas reas de actividad deben ser ade-cuadamente integradas en el proceso de diseo y desarrollo, traba-

jando en equipo, de forma efectiva y oportuna.

La Figura 28 (una extensin de la Figura 23) muestra la evolu-cin del diseo, junto con los criterios seleccionados de diseo quesean aplicables, en grado variable, en cada nivel de la estructura jerr-quica del sistema. Adems, hay muchas actividades y tareas diferentesque son realizadas para asegurar que se alcanzan todos los objetivosdel programa, y que la configuracin final del sistema satisface al usua-

rio, eficaz y eficientemente. Hay ciertas reas de afinidad inherentes alos requisitos para desarrollar las tareas identificadas en la figura. Porejemplo, el anlisis funcional constituye la base para requisitos de fiabi-lidad, mantenibilidad, factores humanos, logstica y otros; el anlisis demodos de fallos, sus efectos y criticidad se requiere en la realizacin delos anlisis de fiabilidad, mantenibilidad y apoyo logstico; se necesitaun anlisis detallado de tareas para los requisitos del programa demantenibilidad, factores humanos y logstica; los anlisis de coste delciclo de vida son inherentes al desarrollo de anlisis de requisitos delsistema, viabilidad, fiabilidad, mantenibilidad, apoyo logstico; etc.


67/125


6 0

Desde el punto de vista de la ingeniera de sistemas, es esen-cial que los adecuados elementos orgnicos que participan en unprograma determinado estn ntimamente integrados, promovien-do las necesarias comunicaciones que deben existir diariamente.Esto puede ser parcialmente realizado por medio de la co-disposi-cin del personal del proyecto. Si los miembros de los equipos deproyecto no estn situados en la misma zona, es necesario esta-blecer los adecuados enlaces de comunicaciones mediante la utili-zacin de redes de rea local, mtodos de diseo asistidos porordenador y otros anlogos. La Figura 29 presenta la situacin en

la que disciplinas individuales de diseo estn enlazadas para pro-mover las comunicaciones diarias que apoyan los distintos tipos deactividades de diseo. Es ms, deben integrarse adecuadamentelos diferentes informes, anlisis, datos del diseo e informacinrelacionada mediante un enfoque de base de datos compartida,como se ilustra en la Figura 30. Para lograr este objetivo, los mode-los/herramientas necesarios deben estar disponibles a los diver-sos miembros del equipo de diseo (como se expuso en la Seccin2.3.). Por ltimo, debe establecerse el adecuado entorno orgnicoque facilite la consecucin de esta necesaria integracin. La orga-nizacin para la realizacin y direccin de ingeniera de sistemasse desarrolla en el Captulo 3.

2.5. Revisin, evaluacin y realimentacin del diseo

Parte integral del proceso de obtencin, ilustrado en la Figura7, es la actividad peridica de revisin y evaluacin que ocurre infor-malmente de forma diaria, y ms formalmente en instantes concretosdel ciclo global de diseo y desarrollo. En relacin con esto ltimo,las revisiones formales de diseo suelen llevarse a efecto despusde la finalizacin del diseo conceptual, las revisiones del diseodel sistema pueden realizarse durante el diseo preliminar, las revi-siones de los equipos/software pueden realizarse durante el diseopreliminar y detallado, y las revisiones crticas de diseo puedan


68/125


69/125

6 1


realizarse despus de que el diseo est esencialmente congela-do y antes de entrar en la fase de produccin/construccin. Aunque

el tipo y nmero de revisiones formales de diseo dependern de losrequisitos especficos de cada programa, la lnea de referencia pre-sentada en la Figura 31 servir como punto de partida para posterio-res discusiones.

En relacin con la actividad diaria informal de revisin yevaluacin de diseo mostrada en la figura, sta incluye el de-sarrollo inicial de los criterios de diseo, la funcin diaria de

participacin y evaluacin del diseo, la revisin y aprobacinde documentacin de diseo (dibujos y planos, ilustraciones,listas de material y de repuestos, croquis, informes, etc.) y laelaboracin y procesado de recomendaciones de accionescorrectivas y/o de mejoras del producto.


70/125


6 2

Dado que esta contnua actividad abarca diferentes disciplinas,es pertinente que sean identificados (y acordados) desde el principiopara que sirvan como gua para el diseo, los criterios para ste,las normas sobre equipos y materiales, y los procedimientos relacio-nados. Subsiguientemente, deben desarrollarse listas de comproba-cin para facilitar la revisin y evaluacin de datos/documentacin dediseo en trminos de los requisitos globales de especificacin delsistema y sus diversos elementos. Un ejemplo de una lista de compro-

bacin se muestra en la Figura 32.

La Figura 33 muestra el desarrollo de una de las actividadessealadas en la lista de comprobacin. La utilizacin de listas de com-probacin, que debern ser adaptadas al programa y a las caracte-rsticas particulares del sistema en desarrollo, puede ser extremada-mente beneficiosa en el proceso global de evaluacin.

Refirindonos a la Figura 31, las revisiones formales de diseose programan en instantes concretos del proceso de obtencin a me-


71/125


72/125

6 3


dida que la definicin del diseo evoluciona de una configuracin fun-cional, a una configuracin asignada y a una configuracin del pro-

ducto. El objetivo es: (1) proporcionar una comprobacin metdica deldiseo del producto/sistema con respecto a los requisitos contractua-les y de especificaciones; (2) proporcionar una referencia comn atodo el personal del proyecto; (3) proporcionar un medio para resolverlos principales problemas de interface; (4) proporcionar un registrometdico y sistemtico de las decisiones de diseo adoptadas y losmotivos por los que se han tomado; y (5) promover un diseo msmaduro mediante entradas de grupo. En el proceso se incluye la

revisin de las medidas de prestaciones tcnicas y de cmo progresael diseo en trminos de cumplir con los requisitos. La Figura 34 ilus-tra el enfoque de medida y evaluacin.

Puede haber cualquier nmero de revisiones de diseo progra-madas de acuerdo con la complejidad del sistema y el grado de madu-rez del diseo alcanzado en un momento determinado. Aunque el ob-

jetivo es integrar, coordinar, comunicar, y aprobar de forma apropiadael diseo a medida que avanza la actividad de desarrollo, la revisinformal de diseo sirve, en ocasiones, de vehculo de integracin yadecuada comunicacin. La actividad de revisin y evaluacin del di-seo puede ser enormemente beneficiosa, si se realiza de maneraprofesional. Sin embargo, una determinada revisin debe ser identifi-cada con la adecuada documentacin de apoyo, el panel de revisinde diseo debe incluir las personas adecuadas que sean responsa-

bles y puedan tomar decisiones sobre la marcha si fuesen necesarias,y las acciones correctivas necesarias deben iniciarse inmediatamentedespus de las revisiones (o sea, la adecuada actividad de segui-miento). Desde la perspectiva de la ingeniera de sistemas, es esen-cial la realizacin de las revisiones formales de diseo.


73/125


6 4


74/125

6 5


2.6. Prueba y evaluacin del sistema

Paralelamente al establecimiento de los requisitos iniciales delsistema en la fase del diseo conceptual (Seccin 2.1.), debe implan-tarse un mtodo de medida y evaluacin para asegurar la consecu-cin final de los requisitos especificados. Las medidas de prestacio-nes tcnicas son identificadas y priorizadas y, al mismo tiempo, debeespecificarse cmo ser evaluado el sistema en trminos de cumpli-miento de esos requisitos de medidas de prestaciones tcnicas.

Cuando se considera el tema de la evaluacin, el objetivo esconseguir un alto grado de confianza, lo antes posible en el ciclo devida, de que el sistema funcionar de la forma deseada. Esperar aque el sistema haya alcanzado su plena capacidad operativa conduci-r a una prueba de su verdadera capacidad. Sin embargo, si hay pro-blemas y el sistema no cumple con los requisitos especificados, laincorporacin de los necesarios cambios por accin correctiva puede

resultar muy costosa. Por otro lado, si se detectan problemas poten-ciales en los primeros momentos del ciclo de vida, cualquier cambionecesario puede incorporarse con un coste mnimo.

La Figura 35 identifica las etapas de evaluacin del sistema. Laprimera categora es "analtica", que se refiere a ciertas evaluacionesde diseo que pueden ser realizadas en las primeras fases de ciclo devida del sistema utilizando mtodos informatizados entre los que es-

tn CAD, CAM, CALS, simulacin y otros anlogos.

"Pruebas tipo 1" se refiere a la evaluacin de los componen-tes del sistema en el entorno del laboratorio utilizando modelos,bancos de prueba, etc. Estas pruebas estn diseadas principal-mente con el propsito de verificar ciertas caractersticas fsicas yde prestaciones y son de desarrollo por naturaleza. El "prototipadorpido" se emplea en ocasiones con este propsito. Las "Pruebastipo 2" incluyen pruebas y demostraciones formales realizadas du-rante las ltimas etapas de la fase de diseo detallado y desarrollo,


75/125


6 6


76/125

6 7


cuando estn disponibles prototipos pre-produccin de equipos ysoftware. Los prototipos de equipos y software son similares enforma y funcin (con partes de componentes operativos incorpora-dos) a los elementos de produccin, excepto que no han sido total-mente aprobados en ese determinado instante. Las "Pruebas tipo3" incluyen la terminacin de las pruebas formales en emplaza-mientos designados, realizadas por el "usuario" durante un cierto

perodo de tiempo. Estas pruebas se realizan normalmente des-pus de la validacin inicial del sistema y antes de completar lafase produccin/construccin. El objetivo es realizar una evalua-cin tcnica completa del sistema. Las "Pruebas tipo 4", realizadasdurante la fase de utilizacin y apoyo del sistema, incluyen prue-bas formales realizadas en ocasiones con el propsito de obtenerinformacin especfica relativa a algn aspecto de la utilizacin o

el apoyo. El objetivo es obtener mayor conocimiento de la utiliza-cin del sistema en el entorno del usuario, o de las operaciones delusuario en campo.


77/125


6 8

Con relacin a la figura, un objetivo de la ingeniera de siste-mas es causar la integracin de estos requisitos de prueba de manerarentable. La verificacin de algunos componentes puede realizarsepor medios analticos; otros requisitos pueden cumplirse mediantePruebas tipo 1, y as sucesivamente. En el plan maestro de prueba y

evaluacin desarrollado durante la fase de diseo conceptual debedesarrollarse e incluirse un enfoque integrado total.

La recomendacin e iniciacin de cambios, como consecuen-cia de la prueba y evaluacin, debe tratarse de forma individual. Cadacambio propuesto debe ser evaluado, ant

1 ingenieria de sistemas

Documents