Ingenieria BN

~
~

Iq~tt;·:+ .~

Ct''''' (:{n~;Dn ~ .. ~. ::-=~8C~C~{) :\'·1~~·ddd

• • • • ••• • ••

Maquinade vapor de Watt

P.V.F-~.:

Publicaciones de Ingenierfa de Sistemas

,#

IA

I

1

IN

NI

por

Benjamin S~ Blanchard

No ests permitida la reproducci6n total 0 parcial de este libro, ni su tratamiento intormetico, ni la trasnmisi6n de ninguna forma 0 por cualquier medic, ya sea eiectronico, por totocopis, por registro 0 por otros rnetodos, sin el previo consentimiento por escrito de los titulares del Copyright.

Primera Edicion: Enero - 1995 1.250 ejemplares

Traductores:

Rafael Ugarte Azuela

Alberto Sols Rodriguez - Candela

© Isdefe

c/ Edison, 4 28006 Madrid.

Disefio:

HB&h Direccion de arte y produccion

Infografia de portada:

Salvador Vivas

Fotomecan ica:

Microprint, S.A.

lmpresion:

Graficas Marte, S.A. (Madrid)

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

Printed in Spain - Impreso en Espana.

3

4

5

PROLOGO

Esta monograffa versa sobre «Ingenierfa de Sistemas», expresi6n 0 vocablo definido diferentemente sequn la experiencia y la trayectoria profesional del que 10 intenta. La descripci6n contenida en esta monograffa se basa en mi propia trayectoria profesional, que incluye 17 afios de experiencia industrial (como ingeniero de disefio, ingeniero de mantenimiento de campo, y director de ingenierfa), seguido por otros 24 en el campo docente de la ensefianza superior (como instructor, consultor y Director del Programa de Ingenierfa de Sistemas de Virginia Polytechnic Institute and state University). EI proceso, la terminologfa, el tipo de especificaciones, los elementos orqanicos, etc, son «qenericos» y no se refieren a ninguna situaci6n, proyecto 0 ambiente particular concreto. Gran parte del material aquf expuesto se basa en los siguientes textos:

1. Blanchard, B.S., and W.J. Fabrycky, Systems Engineering And Analysis, 2nd Edition, Prentice-Hall, Inc., Englewood Cliffs, New Jersey, 1990.

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

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

Reguirements For Computer-Based Design Tools, Monograph, Society of Logistics Engineers (SOLE), 8100 Professional Place, Suite 211, New Carrollton, Maryland 20785, 1994.

Es para rnl un gran honor el tener la oportunidad de desarrollar y recopilar esta monograffa para ISDEFE, Madrid, Espana, y deseo expresar mi agradecimiento a Alberto Sols quien hizo posible esta colaboraci6n. Asimismo agradezco profundamente los comentarios e intercambios de opiniones tanto de Dinesh Verma (Virginia Tech) como de los componentes del Comlts de Redacci6n Martf n Alefiar Ginard, Eduardo Avanzini Blanco, Manuel Bautista Perez, Carlos Casajus Dlaz, Lufs Garda Pascual, Ricardo Torr6n Duran, y Marfa Fernanda Ruiz de Azcarate Varela.

Benjamin S. Blanchard

7

8

9

INDICE GENERAL

1. iNTRODUCCiON

11

1.1.Entorno actual

1.2.Definici6n de ingenierfa de sistemas 1.3.Caracterfsticas de la ingenierfa de sistemas 1.4.Aplicaciones de la ingenierfa de sistemas

15 18 21 24

2. EL PROCESO DE INGENIERfA DE SiSTEMAS

27

2.1.Requisistos del sistema 29

2. 1. 1. ldentiticecion de la necesidad 30

2.1.2. Beelizecion de los estudios de viabilidad 31

2. 1.3. Definicion de los requisitos operativos del sistema 33

2. 1.4. Desarrollo de los conceptos de apoyo y mantenimiento 37

2. 1.5. Desarrollo y esiqnecion de prioridades

de medidas de prestaciones tecnices 43

2.1.6. Eleboreclon de la eepeclttcecion del sistema (Tipo "A») 46

2.2.Analisis funcional y asignaci6n de requisitos 47

2.3.Analisis, sfntesis, evaluaci6n y optimizaci6n del disefio 54

2.4.lntegraci6n del disefio 59

2.5.Revisi6n, evaluaci6n y realimentaci6n del dlsefio 60

2.6.Prueba y evaluaci6n del sistema 65

2.7.Producci6n y/o construcci6n 69

2.8.Utilizaci6n y apoyo del sistema 70

2.9.Retirada del sistema, desecho del material,

rehabilitaci6n y reutilizaci6n 72

3, PLAN!F!CACION, ORGANIZACION Y GEST!ON DE INGENIER!A DE S!STEMAS

77

3.1.Requisitos del programa de ingenierfa de sistemas 3.2.ldentificaci6n de tareas

3.3.0rganizaci6n para ingenierfa de sistemas 3.4.lntegraci6n de las disciplinas de ingenierfa 3.5.Relaciones con actividades claves del programa 3.6.Gesti6n y control del programa

3.7.Resumen

79 82 86 93 95 97 99

REFERENCIAS

101

BH3UOGRAFIA

105

GLOSARIO

109

10

INGENIERIA DE SISTEMAS

1 1

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

Intr

~ ..

··n····

.: .: .:

......

.. .. .

12


Esta monograffa trata de «ingenierfa de sistemas», 0 el proceso ordenado para hacer realidad un sistema. Un sistema es una combinaclon de medios (como personas, materiales, equipos, software, instalaciones, datos, etc.), integrados de tal forma que puedan desarrollar una determinada funclon en respuesta a una necesidad concreta. Los sistemas se clasifican como naturales 0 artificiales, ffsicos o conceptuales, abiertos 0 de lazos cerrados, estatlcos 0 dlnarnlcos. Los sistemas analizados en esta monograffa son artificiales, ocupan un espacio flslco, son dlnamlcos por naturaleza, y son abiertos por la posibilidad de ser interactivos y de modificar los rnarqenes de su campo de actuacion. Mas aun, los pasos especfficos, la terminologfa, los tipos de especificaciones, los elementos orqanlcos, etc., son «genericos» y no se refieren a ni nguna sltuaclon 0 entorno concreto [1].

Un sistema puede variar por su forma, adecuaclon, y/o funclon.

Se puede tratar con un grupo de aviones desarrollando una rnlslon en una sltuaclon qeoqraflca concreta, un barco 0 una capacidad de dirigir el combate, una red de comunicaciones capaz de distribuir informacion a nivel mundial, un sistema de distrlbuclon de energfa que abarque canales y plantas generadoras de energfa, una planta de fabricacion capaz de producir «x» productos en un tiempo determinado, 0 un pequefio vehfculo terrestre que real ice el transporte de cierto tipo de carga de un lugar a otro. Gada sistema esta formado por componentes, y estos a su vez pueden descomponerse en otros mas pequefios. Si en un sistema determinado se establecen dos niveles jerarqulcos, al inferior se Ie suele denominar «subslsterna». Por ejemplo, en un

13

Introducci6n

sistema de transporte aereo, los aviones, las terminales, el equipo de apoyo terrestre y los controles son subsistemas. Los equipos, las personas y la informaci6n son componentes. Por ello los rnetodos para designar sistemas, subsistemas y componentes son relativos, ya que un sistema situado en un nivel jsrarqulco puede ser el componente de otro de nivel superior. Asf, para una situaci6n determinada, es esencial definir el sistema considerado especificando claramente sus Ifmites y fronteras.

EI proceso para obtener sistemas (y/o mejorar los existentes), con independencia del tipo de sistema, es el objetivo principal de esta monograffa. A toda nueva y definida necesidad Ie sigue un «proceso». La forma mas 16gica de conseguir resultados satisfactorios es fijarse en la totalidad del sistema, considerar las relaciones funcionales de sus elementos e integrarlos como un todo. EI proceso de desarrollar y producir sistemas artificiales de forma 16gica y ordenada se realiza mejor a traves de buena «ingenierfa de sistemas».

Consustancial a la ingenierfa de sistemas es la oportuna y eficaz integraci6n de las actividades y medios apropiados, en un proceso evolutivo que va desde la identificaci6n de la necesidad del usuario hasta la entrega de un sistema de adecuada configuraci6n, mediante un proceso arriba-abajo e iterativo de definici6n de requisitos, anallsls y asignaci6n funcional, sfntesis, optimizaci6n, dlssfio, prueba y evaluaci6n. EI proceso de ingenierfa de sistemas, en su evoluci6n desde los detalles funcionales y los requisitos del dlsefio, tiene por finalidad la obtenci6n del adecuado equilibrio entre los facto res operatlvos (es decir, prestaciones), econ6micos y logfsticos. La mejor manera de 10- grar esto es mediante un esfuerzo multidisciplinar enfocado al dlsefio. Adernas de las caracterfsticas de -prestaclones» tradicionales, debe prestarse una especial consideraci6n en el disefio a factores como fiabilidad, mantenibilidad, facto res humanos, capacidad de supervivencia, apoyo logfstico, manufacturabilidad, calidad, desechabilidad, coste de su cicio de vida, y otros afines. La ingenierfa de sistemas ayuda a asegurar que estos facto res son adecuadamente integrados de forma

14


concurrente en el dlsefio, desarrollo y producclon de nuevos sistemas, y/o la rnodlflcaclon de los existentes.

Aunque las tecnlcas y los rnetodos asociados a la ingenierfa de sistemas no son nuevos, no han side perfectamente ejecutados en el pasado. Por ello se han producido efectos perjudiciales y muchos de los sistemas actualmente en uso no han resuelto las necesidades del usuario, ni su funcionamiento y apoyo han alcanzado la efectividadcoste esperada. Hoy dfa cuando los recursos disponibles disminuyen y la competencia internacional aumenta, es necesario «revisar» los conceptos, principios y tecnlcas de la ingenierfa de sistemas. Por ello, el motivo de esta monograffa es presentar la «estructura» de la ingenierfa de sistemas. Tomando a esta monograffa como base de partida, es necesario desarrollar otras adicionales destinadas a ampliar los aspectos detail ados de las disciplinas clave que componen el proceso total de la ingenierfa de sistemas, con objeto de presentar una vision completa del disefio, desarrollo, producclon, funcionamiento y apoyo de sistemas.

REQUISITOS CAMBIANTES

COMPLEJIDAD CRECIENTE DE LOS SISTEMAS

r~~~~~~~~DE~~~~I~N~~~}\

l J -,

\

CICLOS DE ADQUISICION MAS LARGOS

BASE INDUSTRIAL MERMADA

;E~~~~()(;,~~~,~~L

l J

------r---~~;~~~~~~~~~~~---!

l !

MAYOR COMPETENCIA INTERNACIONAL

\ i---clcLos-oEVloiEXTENoIDos----i

1 DE LOS SISTEMAS i

L :

. ,

. ,

.---------------------------------------------------------------------.

, , ,

\----, MULTIPLES CONTRATISTAS/SUBCONTRATISTAS

, ,

, ,

, ,

,--------------------------------------------------------------------_.

Figura 1. - EL ENTORNO ACTUAL -

15

Introducci6n

1.1. En1orno actual

En general, la complejidad de los sistemas actuales va en aumento con la aparici6n de nuevas tecnologfas en un entorno que cambia sin cesar; el tiempo que se tarda en transformar una necesidad identificada en el desarrollo de un nuevo sistema operatlvo es cada vez mas largo; y los costes asociados con el desarrollo, producci6n, utilizaci6n y apoyo de los sistemas estan incrementando. Slrnultanearnente, los recursos se van reduciendo y la competencia va aumentando a nivel mundial. En resumen, hay un conjunto de factores, como los sefialados en la Figura 1, que constituyen todo un reto en el entorno actual.

Cuando nos fijamos en los aspectos econ6micos, nos encontramos con que normalmente existe una falta de visibilidad total 0 clara de los costes, tal como se muestra en el «efecto iceberg» de la Figura 2. En muchos sistemas, los costes del disefio y desarrollo son relativamente bien conocidos; sin embargo, son bastante desconocidos los relativos a su operatividad y apoyo. En esencia los disefiadores tratan satisfactoriamente los facto res de costes que mas influyen a corto plazo, pero suelen fallar en los correspondientes a largo plazo. AI mismo tiempo, la experiencia ha demostrado que una gran parte del coste total de la vida de un sistema determinado corresponde a las actividades de funcionamiento y apoyo de las ultlrnas fases de su vida (por ejemplo hasta el 75% del coste total) [2].

Adicionalmente, cuando se analizan las relaciones «causa-efecto», nos encontramos con que una gran parte del coste del clclo de vida proyectado para un determinado sistema es consecuencia de las decisiones tomadas durante las fases de planificaci6n preliminar y disefio conceptual del sistema. Las decisiones correspondientes a los requisitos operatlvos (por ejemplo, el nurnero y localizaci6n de los emplazamientos previstos), a las aplicaciones tecnol6gicas, a las polfticas de mantenimiento y apoyo (dos escalones frente a tres de mantenimiento), asignaci6n de actividades manuales y/o automatizadas, esquemas de empaquetado de equipo y software, tecnlcas de diagn6sti-

1 6


co, selecci6n de materiales, conceptos sobre el nivel de reparaci6n, etc., tienen un gran impacto sobre el coste total del clclo de vida. Asf, mientras se intentan reducir los costes iniciales de un proyecto, muchas de las decisiones del disefio y la gesti6n que se toman en esta fase pueden tener efectos catastr6ficos a largo plazo. En otras palabras, la oportunidad de reducci6n de los costes totales es maxima en las primeras fases del desarrollo del sistema. La Figura 3 muestra no s610 los compromisos de coste total del clclo de vida, sino tarnblen los de arquitectura, aplicaciones tecnol6gicas, y filosoffa global de disefio a ser implantada.

Para agravar la situaci6n, en un gran nurnero de casos falta un rnetodo disciplinado en la obtenci6n de nuevos sistemas. Existe una tendencia generalizada a "dlsefiar-ahora-arreqlar-despues" utilizando el rnetodo de «bottom-up» (rnetodo ascendente 0 de «abajoarrlba»): a mantener poco clara la definici6n de los requisitos en las

GESTION DEFICIENTE

Personal openilMl. I_nes. SoNlclos. Energla, Imp_. all:.

ManliU0d6n d& maierlal. E1D1Bje EnvIII. Tnmsporl&. Dlsblbucl6n

"

., - -- _. __ .. _----------_.-.-------_.

, .

;' COSTE DE RECURSOS INFORMATICOS

----

»-r-: ~ ~ c

COSTE DE MANTENIMIENTO

COSTE DE DATOS TECNICOS

,

/

Manuaies de oporaci6n y INlnlllltNerrtoi I'IDc8dmlonlDs, InsbuccIonos. /

Infurmes de fellos r

Figura 2. - VISIBILIDAD DEL COSTE TOTAL-

17

Introducci6n

primeras fases de la obtenci6n del sistema para introducir cambios en el disefio mas tarde, preocupandose del control de la configuraci6n el afio pr6ximo; a eliminar determinados puntos crfticos en el dlsefio y desarrollo del sistema con la idea de «ahorrar tiempo y dinero» (es decir, los «atajos» extraoficiales); etc. La experiencia ha demostrado que los rnetodos de gesti6n prevalentes aplicados en muchos casos han side perjudiciales. Cuantas veces los resultados han side excesivamente costosos por no haber definido adecuadamente los reguisitos al principio, por no haber efectuado el necesario analisis para evaluar los riesgos asociados con las decisiones adoptadas en las primeras fases del proceso, y por no adoptar un procedimiento met6dico y estructurado en el diseno y desarrollo de sistemas.

Considerando estas tendencias pasadas y las relaciones existentes entre las caracterfsticas del sistema y las diversas fases de un

1D11%

OPORTUNIDAD DE REDUCCION DEL COslE DEL ClCLO DE VIDA

< c ;;: w c

§

U

--' w c

~

8

iil

c w

~ ~

//.

/ COslE PREVISTO DEL CICLO DE VIDA

/'

DlsBlO YDESARROLLO DEL SISTEMA

UTILIZACION Y APOYO AL SISTEMA

Figura 3. - COMPROMISO DE COSTE EN EL CICLO DE VIDA -

1 8


programa, es lrnperatlvo para los esfuerzos de dlsefio y desarrollo de futuros sistemas, poner el enfasis sobre: (1) la mejora de nuestros metodos para definir los requisitos del sistema que concuerden con las verdaderas necesidades del usuario, al principio de la fase del dlsefio conceptual, y las prestaciones, eficacia y todas las caracterfsticas esenciales del sistema; (2) la consideraci6n del sistema total, sus principales componentes de misi6n y sus elementos de apoyo bajo una perspectiva de cicio de vida; (3) la organizaci6n y la integraci6n de la ingenierfa necesaria y las disciplinas relacionadas en el esfuerzo de dlsefio global; y (4) el establecimiento de un rnetodo disciplinado que incluya las normas necesarias para la revisi6n, evaluaci6n y realimentaci6n con el fin de asegurar un progresi6n ordenada, desde la identificaci6n inicial de la necesidad del usuario hacia adelante. Es esencial para el futuro la implantaci6n de la ingenierfa de sistemas en la obtenci6n de nuevos sistemas, y/o la mejora 0 modificaci6n de los existentes.

Una revisi6n de 10 escrito sobre el tema, muestra que no existe una definici6n cornunrnente aceptada de ingenierfa de sistemas. Dependiendo de la experiencia y antecedentes person ales de cada uno, el tsrrnlno puede ser definido de diversas formas. Sin embargo, con independencia de este hecho, existe una cierta unanimidad en los conceptos, el camino a seguir, y los fines ultlrnos perseguidos [3]. De forma general, la ingenierfa de sistemas es «la aplicaci6n efectiva de rnetodos cientfficos y de ingenierfa para transformar una necesidad operativa en una configuraci6n determinada del sistema mediante un proceso de arriba-abajo iterativo (top-down) de establecimiento de requisitos, selecci6n del concepto, anallsis y asignaci6n funcional, sfntesis, optimizaci6n del disefio, prueba y evaluaci6n. Esta orientado al proceso y utiliza procedimientos de realimentaci6n y control [4].

La ingenierfa de sistemas puede definirse como «la aplicaci6n de tecnicas cientfficas y de ingenierfa para (1) transformar una nece-

19

Introducci6n

sidad operativa en la descripci6n de los parametres de prestaciones de un sistema yen su configuraci6n mediante la utilizaci6n de un proceso iterativo de definici6n, sfntesis, analisls, disefio, prueba y evaluaci6n; (2) integrar los parametres tecnlcos relacionados y asegurar la compatibilidad de todas las interrelaciones ffsicas, funcionales y del programa de forma que se consiga la mejor definici6n y dlsefio del sistema completo; y (3) integrar los aspectos de fiabilidad, mantenibilidad, seguridad , supervivencia, de personal y otros similares en el proceso global de ingenierfa para conseguir los objetivos tecnlcos, de coste y de calendario fijados» [5].

Baslcarnente, ingenierfa de sistemas es «BUENA» ingenierfa orientada al clclo de vida, que incluye la integraci6n oportuna de los facto res tecnlcos, las relaciones funcionales y las actividades del programa. Estas incluyen las diferentes disciplinas de dlsefio que se combinan e integran de tal manera para conseguir el desarrollo y la obtenci6n de un sistema que cubra las necesidades del consumidor (ej.: el usuario) de forma efectiva y eficaz. La Figura 4 refleja los muchos facto res que deben ser considerados e integrados como un todo.

A menudo, al tratar sobre el tema, se utilizan los terrnlnos «olencia de los sistemas», «anallsls de sistemas», e «ingenierfa de sistemas» de forma indistinta. La ciencia de los sistemas trata principalmente la observaci6n, identificaci6n, descripci6n, investigaci6n experimental, y explicaci6n te6rica de los hechos, leyes ffsicas, interrelaciones, etc., asociados con los fen6menos naturales. La ciencia trata con los conceptos y principios baslcos que ayudan a explicar c6mo se comporta el mundo. En un sentido mas exacto, las ramas de la biologfa, la qufmica, y la ffsica cubren muchas de estas interrelaciones. En cualquier caso, la ingenierfa de sistemas incluye la aplicaci6n de principios cientfficos a 10 largo del proceso de disefio y desarrollo del sistema [6].

Consustancial con el proceso de la ingenierfa de sistemas es la realizaci6n permanente de un esfuerzo analftico. Existe una variedad

20


de alternativas (soluciones de compromiso) que deben someterse a alqun tipo de evaluaci6n. Por ejemplo, diferentes escenarios operatives del sistema, aplicaciones tecnol6gicas, diversos conceptos de apoyo y mantenimiento, diferentes esquemas de empaquetado de equipos y software, rnetodos alternativos de diagn6stico, la disyuntiva entre la utilizaci6n de personas 0 sistemas autornatlcos, y otros mas. EI proceso de investigar estas diferentes alternativas del dlsefio, y la evaluaci6n de cada una de elias atenlendose a determinados criterios, es un proceso iterativo.

Para realizar esta actividad de una manera eficaz, el ingeniero (analista) se vale de tecnlcas 0 herramientas analfticas disponibles entre las que se incluyen rnetodos de investigaci6n operativa tales como la simulaci6n, las programaciones lineal y dlnarnlca, la optimizaci6n, y la teorfa de colas para resolver problemas. Adernas, los modelos rnaternatlcos suelen ayudar a realizar los anallsls cuantitativos. En resumen, el analisis de sistemas incluye un proceso anali-

INGENIERIA DE FIABIUDAD

j--------------------------,

INGENIERIA DESEGURIDAD

, '

, '

, '

, '

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

r--------------------------.

, '

i INGENIERIA [//-

; DE FABRICACION :

L :

INGENIERIA QUIMICA

INGENIERIA ELECTRICA

INGENIERIA CIVIL

INGENIERIA DE MANTENIBILIDAD

,---------------------------,

INGENIERIA

, DE FACTORES

: HUMANOS :

: ~~~~~~~ :

,--------------------------~

, ,

_! INGENIERIA

, LOGISTICA

, ,

, ,

, ,

, ,

'-------------------------_.!

OTRAS INGENIERIAS

INGENIERIA MEDIOAMBIENTAL

Figura 4. - INTEGRACION DE DISCIPLINAS DE INGENIERIA-

21

Introducci6n

tico iterativo para evaluar las diferentes alternativas del dlsefio (dentro del contexto del proceso de ingenierfa de sistemas), utilizando cuando sea necesario las tecnicas de los model os maternatlcos y rnetodos analfticos asociados [7] [8].

1,3, Cerecteristicas de la ingenieria de sistemas

La ingenierfa de sistemas «per se» no es considerada actualmente como una de las ingenierfas tradicionales, como pueden ser la electrlca, la mecanlca, la industrial, la civil, la de fiabilidad, 0 cualquier otra especialidad de dlsefio No tiene necesariamente que organizarse de forma similar a estas, ni su ejecuci6n requiere la aplicaci6n de grandes recursos (es decir, elevados costes). Esencialmente. la aplicaci6n de los principios de la ingenierfa de sistemas constituye mas bien un «proceso intelectual», 0 una forma de organizar trabajos. Requiere un cambio de mentalidad para muchos, 0 un cambio de cultura. La ingenierfa de sistemas es buena ingenierfa que pone un enfasis especial en determinadas areas, y cabe ssfialar que:

1. Es necesario utilizar un enfoque de arriba-abajo (<<top-down»), viendo al sistema como un todo. Aunque los trabajos de ingenierfa del pasado lograron dlsefios muy satisfactorios de los diferentes componentes de un sistema (representando solamente una trayectoria de abajo-arriba, 0 -bottorn-up»), carecfan sin embargo de la necesaria visi6n global y comprensi6n de c6mo debfan integrarse eficazmente todos ellos entre sf. La Figura 5 muestra los componentes de un sistema que necesitan ser considerados de forma integrada.

2. Es necesario contemplar todo el clclo de vida del sistema, contemplando todas sus fases, que incluyen el disefio y desarrollo del sistema, la producci6n y/o construcci6n, su distribuci6n, su vida operativa, el apoyo y mantenimiento durante la misma, su baja y retirada (desecho). En el pasado la mayor atenci6n se centraba s610 en las actividades del dlsefio 0 adquisici6n del sistema, prestando muy

22


poca (0 casi ninguna) al impacto que las mismas podrfan provocar en los aspectos de producci6n, vida operativa, y apoyo logfstico. Para poder evaluar adecuadamente los riesgos asociados con las decisiones adoptadas en el proceso inicial de toma de decisiones, es necesario que las mismas se basen en consideraciones del cicio de vida.

3. Un mejor y mas completo esfuerzo es requerido en 10 relativo a la definici6n de los requisitos del sistema, relacionando dichos requisitos con los criterios particulares de disefio basados en estos objetivos, asl como un esfuerzo de anallsls continuado para asegurar la eficacia de las decisiones adoptadas en los primeros momentos de la fase de disefio. Los verdaderos requisitos del sistema deben estar bien definidos y especificados, y debe ser visible la capacidad de seguimiento de estos requisitos del nivel sistema hacia abajo. Han side mfnimos en el pasado los trabajos de anallsls previos completos, tal como hoy dla se realizan en un gran nurnero de nuevos sistemas. La ausencia del establecimiento de una «linea basica 0 de referencla» inicial ha resultado en mayo res esfuerzos individuales de dlsefio aguas abajo en el cicio de vida, muchos de los cuales no fueron bien integrados con otras actividades de dlssfio, necesitando por ello modificaciones. Los costes que provocan la introducci6n de cambios aguas abajo pueden ser muy grandes, tal como se refleja en la Figura 6.

4. Se necesita realizar un esfuerzo multidisciplinar conjunto (0 trabajo en equipo), a 10 largo del proceso de disefio y desarrollo de un sistema, para asegurar que se alcanzan todos los objetivos del dlsefio eficaz yeficientemente. Para conseguir esto se necesita un total conocimiento de las variadas y diferentes disciplinas de dlsefio que intervienen y sus relaciones mutuas, asl como los metodos y tecnicas 0 herramientas que pueden aplicarse para facilitar el desarrollo del proceso de la ingenierfa de sistemas de forma eficaz.

La implantaci6n con exlto de la ingenierfa de sistemas requiere que estos principios (y sus elementos de apoyo) sean seguidos a

23

Introducci6n

SOFTWARE OPERATIVO

PERSONAL OPERATIVO

RECURSOS

CONSUMIBLES i --,

ENTRENAMIENTO TECNICO

EQUIPO DE APOYO YPRUEBA

r~~~~~D~

----------------------------------1 MANTENIMIENTO •

L j

EQUIPODE MANIPUlAClON Y ,------------------------------------8

TRANS PORTE

PERSONAL DE MANTENIMIENTO

-, -- - _IMANTENIMIENTO

1 DE DATOS

1 ---------------------

APoYO (REPUESTOS/ INVENTARIOS)

OTROS ELEMENTOS

DATOS TECNICOS

Figura 5. - ELEMENTOS DE UN SISTEMA -

~DESEADA

PROOUCCION YIO CONSlRUCClON

COSTE DE LA IMPLANTACION DE CANBIOS DE DISEliio ----m.~~

Figura 6. - EL IMPACTO DE LOS CAMBIOS DE DISENO -

24


10 largo del proceso de obtenci6n de sistemas. Para ello debe seguirse un plan bien pensado, estructurado y ordenado para el diseno y desarrollo de nuevos sistemas (y/o la modificaci6n 0 mejora de los existentes). La ingenierfa de sistemas abarca tanto la ejecuci6n y desarrollo de las tecnicas apropiadas como los conocimientos de gesti6n y direcci6n necesarios para hacerlos realidad.

1.4. Ap!icaciones de la lnqenleria de sistemas

Los conceptos, principios, metodos, y tecnlcas descritos a 10 largo de esta monograffa pueden ser aplicados de forma eficaz a cualquier tipo de sistema. Si existe la necesidad de realizar 0 desarrollar una funci6n, tenemos ya un reguisito del sistema. Existen sistemas de aviones, de comunicaciones, de distribuci6n, de informaci6n, de fabricaci6n, de generaci6n de energfa, de radar, de barcos, de transporte, y otros muchos mas. Gada uno de ellos trata de cubrir una determinada necesidad funcional, tiene unos requisitos de entrada y salida, y hay un proceso que debe seguirse para su disefio, desarrollo, producci6n, y distribuci6n. Es en este proceso donde pueden aplicarse los rnetodos de la ingenierfa de sistemas. Sin embargo, las actividades y trabajos a realizar no deben ser «particularlzadas» para cada proyecto concreto ni por exceso ni por defecto, sino con el nivel de esfuerzo adecuado, seleccionando s610 las tareas que sean realmente esenciales y ejecutandolas con la profundidad necesaria. En esencia, mientras las aplicaciones son practlcarnente ilimitadas, las necesidades particulares de cad a proyecto saran diferentes. Por otro lado, la selecci6n «cleqa» y uniforme de especificaciones y normas para su aplicaci6n a 10 largo de todo proyecto, puede ser muy costoso y no cumplir con los objetivos aqul expuestos.

25

Introducci6n

26


27

EI pro

e

28


Aunque existe un consenso generalizado en 10 relativo a los principios y objetivos de la ingenierfa de sistemas, la forma de desarrollar 0 ejecutar los requisitos en este area varlara de un programa a otro dependiendo de las experiencias y conocimientos individuales de las personas involucradas. Por ello, con objeto de establecer un marco de referencia unlco con la idea de entenderse mejor, es necesario definir una «linea basica 0 de referencia» que describa tanto el proceso para la obtenci6n de sistemas como algunas de las actividades clave en 91 contenidas.

La Figura 7 muestra el cicio de vida de un sistema tlplco, es decir, el «modele» que servlra como marco de referencia para las explicaciones posteriores. En ella se muestran las principales fases del programa (como son la fase del disefio conceptual, la del disefio preliminar, etc.) junto con los principales hitos aplicables en la obtenci6n de nuevos sistemas (como la configuraci6n funcional, la configuraci6n asignada, etc.). Incluye asimismo los pasos baslcos del proceso de la ingenierfa de sistemas; cabe citar, por ejemplo, el anallsls de requisitos y la selecci6n del concepto, el anallsls funcional, la asignaci6n de requisitos, estudios de soluciones de compromiso, sfntesis, evaluaciones, y otros. En las descripciones de las fases del programa, la figura no especifica ni los perfodos de tiempo que pueden durar ni los niveles de financiaci6n, ya que los requisitos de cada programa en particular variaran de un caso a otro. La figura refleja el proceso global que debe seguirse en la obtenci6n de sistemas. Siempre que surja

___________ ~,~~~_E~e:IT~~ , B_I~~~_l~~~~~ L lXt~~~I .--------------_[;~;~~ L ~f~~~~ '_ ~_~~~~ _

IdBnIIfIcacI6n dB Ia necesldad; anAiIsis dB llIquisilos; llIquisilos operalivos; IXIIICIIpIDs de apoyo y manterirriento; evakJaci6n de apbclone5 vlablas de Ia tacoologla; seiellli6n dar anfoque !*:rico; dBfirici6n funcional del5isterna; plarilk:aci6n del prograrnaisiAlrnll.

-------------------------------------------------- --------------------------------------------------- ------------------------------------------------- --------------------------------------------------------------------------------------------------------f--------------------

HITOS DEL SISTEMAIPROGRAMA. HiID I Hit! II HiID III H~ IV

A A A A

r_-_-_~~_~~~~j~~_-~_~-~_~~~_~-_-_-_j '_-_-_-~~~_~~ii-~j~~-------l l-_-_-_~~~i§l)_~~~_~.~-~-~-~~-0-~-------1 ;---CONFIG~~~:~:IZAii---·

ESPEGIAGACION IlEL SlSfEtM ESPECIFICACIONES DE DESARROllO. ESPECIFICACIONES DEL PROCESO. . --------------------~--------------------.

(TlPO 'A1 DEL PROCESO. DEL PRODUCTO DB. PRDDlICTO Y DB. tMlERlAL

Y DB. tMlERlAL [TIPOS 'C', 'D', 'E'}

(TlPOS'B', 'G', 'D', 'E')

A Plan d& gasII6n de Il'l!Bf'Ierfa deilimna (SEMP)

i Plan maeoIbo d. prueba r Nad6n

4 Relisiln del dseOO IlClf1COIlIuaI (reWI~" d& los requilitos del .0001lll) &-------------------------A RelisiliesdeidseOOdel!i$na

&--- --------------------------------------------A ~deldiooj'j]d.OIJI~

Ll~~crffioa~'d~._

N

E REQUISITOS DE INGENIERIA DE SISlEMAS

C

EtMI-

S ~

I .-----

D , _dollll_ ::

~ :r-----==-'-jf~: .~

0.1

, , ,

:---~:::::::::::::::::::J--i:DJ

·~·-l---~=:~::~:::t_t:DA

<d- -l-do .......... 1

--::::::::::::::::::::1*0.5

:~-.- l---------~~---------~t DB ,*- -- -- --iE.;id,l-;

·-----------------------·~0.1

-C~~~~~~~_~~~rT n ,--"""'~~ --{-_-_-_-~_~_~~-_-_-_1

:-.$----

Aniilisis fin:ional; asignaciiln de reqlisilDs; lIIlIuclDIlB5 dB comprnmiso; slntasls; dl5efto plllliminar, plUllba y evaluaci6n de conc:eplDs de diseoo (~oo prallmlnaQ; planes de adqulsk:lOn; contrataciln; ~lantaciOn del prograrna; principales sumirisbadores y sus ac:tividedas.

Disefio de subsislemas y ~nentes; lIIlIuclonas de comproml5o y evalUlicIOn de allsmalil'as; desarrollo dB pRllolipo Y model:ls de i~enierla: verifk:aci6n de los procesos de pnxfucciOn ycol15truJclOn; plUllbas y IIVIIUcionas de dasarmlo: ac:IMdades de los surriristradores: plarifilailn de la pnm:ci6n.

Producciiln y/o cons1rullliiln de los aJII'IlDI'IBnIas dar siAlrnll; aclMdadas de prnducci:ln da los suminislraoontS; plUllbas de aoeptaci6n: dislribuc:i6n y IMlizaci6n del sistema: pl1lllbas y IWIUcIones oparatrvas Y da desarrollo; apoyo intarino del con1IlItista: validaci6n del sistema.

Utilizac:ijn del sislema en el entomo del usuarfo; apoyo loglsllco y mantanlmlei1lD continuado; pruabas oparalivas: modfficaciones del sistema pam su mejora: apoyo de 0DIIIra1IsIB&; valldaci6n del sislBma (tnma de datos dB ~ Y 8U wlisis).

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

. .

,,*,,- ,

, pDjIIeSU<Io_ r:

t·~-------------------~--~.t2

i~' S,..,do

_ ..

i --:::::::::::::::::::::--~14.3 !~I-doIp!!iIDq>If.

L ::::::::::::::::::::: __ *«

! '

'~----c== :---

='n~rj

iu~~;{n:;;:;;--r

1 _ ~ ~ 1 I . I ~ t

I I I I

t.tejora ContirRJa del Proceso Il'nIductos i

-paa .....

_____________________ ,1.1

r-: , ...

¥··: : __ 'i-:12

~,~: "

:-----------------------13.1

1obI1_ '--j

k-.-~-~~---JJa2 +

<Ii S_do c_

1----.::~:::::::--t:.:1.3

11 * r"'=~I--

l---:_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-~ __ 't,u

C<f SrDIi"I,I.1aiIa ,---

·'l;~;T

:~-----L_--?:~::::j_1.B ~ .. L~~e:~iiyEt~~,

~ .• u . . u . L___~~~~~~~~~~_i 1.7 : 1< l5

u .. _.~D_ --i___n~_~~ ' '--~~--r_-_-_-_~-~_~_-_-_-_1

. .

. .

~--- -~ _<101l1*\li ~--j

--~~~~~~~~~~~~~~~~~~~~:--* M

""""""'- c_

: {""",*,do"",~ : :

: J ~ 3~

r---n~;;.------:

41------ ~I ..

~-

...................... ~ 15

----------------------: i~6

'.-,.1_<10_

------------------: "' .... -

Figura 7. - EL CICLO DE VIDA DEL SISTEMA rCONFIGURACION")·

9 !OperareT-

.. sistema f---)! ! en entomo! . ! ig~LusuaIioj

I

_c.

1\9i

10

! : --Mantener- -,

! i

cj el sistema}:>

-,

(como sa

necesite)

"If .-9J------------------------.

__ }! Chequeo

i de aeronave

iNbta,~ ••••••••••......... iF ••• FlJooona •• i i ~ ~,

F No roOci()na •

29

El proceso de Ingenierfa de Sistemas

una nueva necesidad y se establezcan los requisitos de un nuevo sistema, habra cierta actividad de disefio conceptual, disefio preliminar, etc., hasta lIegar al desarrollo de un sistema completamente configurado, listo para ser utilizado. La realizaci6n de las actividades de disefio conceptual pueden constituir desde la asignaci6n de un reducido nurnero de personas durante un mes, hasta el empleo de varios expertos en diversas disciplinas durante perfodos de tiempo mas prolongados. Esto, por supuesto, varlara dependiendo del tipo y caracterlstlcas del sistema, de su complejidad, de la proporci6n existente entre el desarrollo de nuevos disefios 0 la utilizaci6n de componentes ya desarrollados, normalizados y disponibles en el mercado, etc. Sea como fuere, hay un proceso que debe seguirse a partir de la identificaci6n de una necesidad.

2,1, RequlsHes del sistema [9]

Heflrlendonos a la Figura 7, los trabajos de anallsls de requisitos, anallsls funcional y asignaci6n de requisitos, etc., son iterativos por naturaleza, yendo de la identificaci6n de una necesidad hasta la definici6n del sistema en terrnlnos funcionales. Dentro de cada uno de los bloques mostrados, existe un determinado grado de realimentaci6n. Por ejemplo, los estudios de soluciones de compromiso se realizan en todos los niveles. Sin embargo, es imposible representar graficamente todas las realimentaciones que se pueden producir. Por ello, el formato representado en la figura sirve como modele para destacar las principales tareas que tienen lugar durante el desarrollo de un sistema. En cualquier caso, el proceso es de arriba-abajo y evolutivo por naturaleza, yendo de la definici6n a nivel sistema, al nivel subsistema, y a los principales componentes del sistema. Su finalidad es describir los requisitos en cada nivel de la jerarqufa del sistema, 0 10 que es 10 mismo, los «QUE» - no los «COMO» - expresados en tsrrnlnos de hardware, software, instalaciones, personas, datos, etc. especfficos. Los recursos que apoyan los «COMO» seran la consecuencia de desarrollar el anallsis y la asignaci6n funcional. Por ultimo,

30


los requisitos deben ser completos y describir completamente la necesidad del usuario, deben ser objetivos e incorporables al disefio del sistema, deben ser medibles y demostrables, etc.

2.1.1. tdentiticecion de te necesided

EI proceso de ingenierfa de sistemas generalmente comienza con la identificaci6n de una «apstencla» 0 «deseo» de uno 0 mas elementos, y se basa en una carencia real (0 percibida). Por ejemplo, determinada capacidad actual no es adecuada en terrnlnos de alcanzar ciertos objetivos de prestaciones, no esta disponible cuando se la necesita, no se la puede apoyar adecuadamente, su utilizaci6n es demasiado costosa, etc. 0, no se puede establecer el enlace entre los puntos «A» y «B», transmitir determinado volumen de informaci6n con un grado «x» de exactitud, en un determinado entorno, en cierto pedodo de tiempo, con un grado «y» de fiabilidad, y dentro de un coste «Z» determinado. Como resultado de 10 anterior, se define un nuevo requisito para el sistema en uni6n de una prioridad para su obtenci6n, de la fecha en que debe estar operatlvo para el usuario la nueva capacidad, asl como de una estimaci6n de los medios necesarios para su obtenci6n. La «determinaci6n de la necesidad» debe expresarse en terrnlnos cualitativos y cuantitativos, con el suficiente detalle que justifique el paso a la siguiente fase.

EI requisito de identificar la necesidad parece «baslco» (evidente). Sin embargo, es muy corriente encontrarse con gue se inician disefios como consecuencia de un interes personal 0 un capricho politico, sin haberse establecido previamente de forma adecuada sus reguisitos. Mas aun, a veces se persiguen desarrollos tecnol6gicos sin tener una idea concreta de su aplicaci6n viable. Muchas veces el planteamiento 0 enunciaci6n del problema resulta ser la parte mas diffcil del proceso. Sin embargo, una completa descripci6n de la verdadera carencia asl como de la necesidad real es muy necesaria, yes importante que los resultados reflejen un requisito del usuario. Este

31


objetivo puede facilitarse involucrando al consumidor (0 «usuario» final) a 10 largo de todo el proceso, desde su iniciaci6n. La aplicaci6n de tecnicas, como el «despliegue de la funci6n de calldad» (Quality Function Deployment, QFD), es apropiada para conseguir el necesario grado de entendimiento, identificando y asignando prioridades a objetivos concretos, etc.

2. 1.2. Reaifzaci6n de tos estudios de viabifidad

Dada la definici6n de una necesidad como muestra la Figura 8, es necesario (1) identificar los diferentes enfoques de disefio a nivel sistema que pueden ser seguidos para alcanzar los requisitos; (2) evaluar los candidatos mas apropiados en terrnlnos de sus prestaciones, efectividad, requisitos logfsticos, y criterios econ6micos; y (3) recomendar la linea de acci6n preferida.

·----------------------------------l ~~~~~~~~~~_~~-~_~~~~~~~~~ _ __]

. ¥

~;.k" !~REQ"'~;'EJ~;~~~E

: DEL SISTEMA: CONCEPTO DE MANTENIMIENTO i i DESARROLLO Y i

~--------------------------------: ---------AN----AL--DD--IEES--LLI-SSS-pIISS-RETTEEL-MAMAIM---I-NAR---------------".::::, i APLiCACION DE LA i

iTECN()L()~lI\j

i--------------E-iWE!i~~I~N--------------i ~~EVI~:Ns::I.E:E~O-:--

CONCEPTIJAL

,-----------------------------------------------------:

REALiMENTACION

A

~ Figura 8.

PROCESO DE DEFINICION DE LOS REQUISITOS DEL SISTEMA

32


Pueden resultar diversas alternativas; sin embargo, el nurnero de posibilidades debe limitarse a un nurnero reducido de opciones viables, acordes con los recursos disponibles (como son los de personal, de material y financieros).

AI considerar distintos enfoques de dlsefio, deben analizarse las diferentes aplicaciones tecnol6gicas existentes. Por ejemplo, en el disefio de un sistema de comunicaciones, ~se debe usar la fibra 6ptica 0 el cable ffsico convencional? En el disefio de un avi6n ~en que medida deben usarse materiales compuestos? Cuando se dlsefia un autom6vil ~se deben utilizar circuitos integrados de gran rapidez en funciones de control 0 debemos inclinarnos por el enfoque electromecanlco convencional? AI planificar un proceso ~en que medida debemos incorporar recursos lnforrnatlcos integrados, 0 emplear la inteligencia artificial?

Es en esta etapa inicial del cicio de vida (0 sea, en la fase de disefio conceptual) en que las principales decisiones adoptadas son las que se refieren a un determinado enfoque de dlsefio, y es en la que los resultados de dichas decisiones tienen su mayor impacto sobre el coste ultimo del clclo de vida del sistema. Las aplicaciones tecnol6gicas son evaluadas, y en algunos casos cuando no exista suficiente informaci6n, debe iniciarse un proceso de investigaci6n con objeto de desarrollar nuevos metod os 0 tecnlcas para aplicaciones especfficas.

Los resultados del anal isis de viabilidad repercutlran significativamente no s610 en las caracterlstlcas operativas del sistema sino tarnblen en la manufacturabilidad, soportabilidad, desechabilidad y otras caracterfsticas analoqas, La selecci6n (y aplicaci6n) de una tecnologfa determinada tiene implicaciones de fiabilidad y mantenibilidad, puede afectar a los requisitos de fabricaci6n, puede influir de forma determinante en los equipos de prueba y repuestos, y ciertamente afectara al coste del cicio de vida del sistema. De la misma forma, las decisiones relativas a la selecci6n de determi-

33


nados procesos, pueden tener implicaciones en el cicio de vida. Por ello, es esencial que el cicio de vida este siempre presente en este trabajo de evaluaci6n. EI resultado final de esta actividad conduce directamente al establecimiento de los requisitos opsratlvos del sistema y del concepto de mantenimiento y, finalmente, se vera reflejado en la especificaci6n del sistema (del Tipo «A», ver Figura 7).

2. 1.3. Definicion de los requisitos operetivos del sistetne

Con el analisls de la necesidad, combinado con la selecci6n del enfoque tscnlco, es necesario transformar esta informaci6n en terminos de requisitos opsratlvos previos. Tales requisitos deben contemplar los siguientes aspectos:

a. La distribuci6n 0 despliegue operativo- el nurnero de emplazamientos en los que se utillzara el sistema, la distribuci6n geografica y el calendario, as! como el tipo y nurnero de componentes del sistema a situar en cada emplazamiento. Todo ello es la respuesta a la pregunta - l,donde se va a utilizar el sistema? La Figura 9 muestra un ejemplo de un despliegue mundial.

b. Perfil 0 escenario de la misi6n - identificaci6n de la misi6n principal del sistema, y sus misiones alternativas 0 secundarias. l,Que debe realizar el sistema en respuesta a la necesidad? Esto puede expresarse a traves de una serie de perfiles operatives, que ilustren los aspectos «dlnarnlcos» necesarios para desarrollar una misi6n. Son ejemplos, el perfil de vuelo de un avi6n entre dos ciudades, la trayectoria a recorrer por un autom6vil, y la derrota a seguir por un barco. La Figura 10 muestra un ejemplo simple de perfiles posibles.

c. Prestaciones y para metros relacionados- definici6n de las caracterlstlcas operativas 0 funciones baslcas del sistema. Se refiere a parametres como alcance 0 autonornla, precisi6n, tasa, capacidad, volumen procesado, potencia de salida, dimensi6n, y peso. l,Cuales

34


Figura 9.

REQUISITOS OPERATIVOS DEL SISTEMA (DISTRIBUCION GEOGRAFICA)

son los parametres crfticos de prestaci6n del sistema necesarios para desarrollar su misi6n en los diferentes emplazamientos del usuario? Adicionalmente, ~c6mo se relacionan dichos valores con los perfiles de misi6n de la Figura 10?

d. Requisitos de utilizaci6n- uso previsto del sistema, y sus componentes, en el desempefio de su misi6n. Se refiere a horas de utilizaci6n del equipo por dla, tiempo clclo, ciclos de utilizaci6n-inactividad, porcentaje de capacidad total empleada, carga de instalaciones, etc. ~Hasta que limite se utllizaran los diferentes componentes del sistema? Esto conduce a calcular algunas de las solicitaciones impuestas al sistema por el usuario.

e. Requisitos de efectividad- requisitos del sistema, expresados cuantitativamente sequn sea aplicable, incluyendo efectividad/coste del sistema, disponibilidad operativa, seguridad de mi-

35


sion, tiempo medio entre fallos (Mean Time Between Failures, MTBF), tasa de fallos ("A."), tasa de alistamiento, tiempo de inactividad por mantenimiento (Maintenance Down Time, MDT), tiempo medio entre acciones de mantenimiento (Mean Time Between Maintenance, MTBM), utilizaci6n de instalaciones (en tanto por ciento), niveles de cualificaci6n del personal, costes, y otros similares. Sabiendo que el sistema funclonara l,que efectividad 0 eficiencia se espera de el?

f. Cicio de vida opsratlvo (horizonte)- tiempo estimado que se espera este el sistema en usa operativo. l,Cuanto tiempo utlllzara el sistema el usuario? l,Cual es el perfil total de inventario necesario para el sistema y sus componentes, y donde se sltuara dicho inventario? Debe definirse el cicio de vida del sistema. Aunque el inventario varlara sequn se aumente 0 reduzca el cicio de vida del sistema, es necesario fijar en este punta una «linea de referencla».

PERFIL MISION 'A"

MISION

PERFIL MISION 'A"

TIEMPOS DE MISION

PERFIL MISION "8"

MISION

PERFIL MISION '8"

TIEMPOS DE MISION

PERFIL MISION "C'

MISION

PERFIL MISION 'C"

TIEMPOS DE MISION

Figura 10. - PERFILES OPERATIVOS DEL SISTEMA (EJEMPLO) -

36


g. Entorno- definici6n del entorno en el que se espera opere el sistema de forma efectiva, por ejemplo: temperatura, vibraciones y choques, ruidos, humedad, condiciones artlcas 0 tropicales, terreno llano 0 montarioso, aerotransportado, terrestre y embarcado. Despues un conjunto de perfiles de misi6n pueden resultar en la especificaci6n de un rango de valores. ~A que estara sujeto el sistema durante su utilizaci6n, y por cuanto tiempo? Adernas del funcionamiento del sistema, las consideraciones ambientales deben incluir modos de transporte, manejo y almacenamiento. Es posible que el sistema (y/o alguno de sus componentes) este sujeto a un entorno mas riguroso durante el transporte que durante su funcionamiento.

EI establecimiento de los requisitos opsratlvos forma la base para el disefio del sistema. Obviamente, se necesitan respuestas a las siguientes preguntas antes de proseguir:

1. ~Que funci6n 0 funciones desarrollara el sistema?

2. ~Cuando sera requerido el sistema para realizar su funci6n y durante cuanto tiempo?

3. ~D6nde se utillzara el sistema?

4. ~C6mo curnpllra su objetivo el sistema?

La respuesta a estas preguntas debe establecer la Ifnea de referencia. Aunque las condiciones pueden cambiar, es necesario establecer unos supuestos iniciales. Por ejemplo, los componentes del sistema seran utilizados de forma distinta en los diferentes emplazamientos de los usuarios, la distribuci6n de dichos componentes puede variar sequn varfen las necesidades operativas, y/o la duraci6n del clclo de vida puede cambiar como consecuencia de la obsolescencia del sistema 0 por criterios competitivos. Aun asf, el rnetodo descrito anteriormente debe ser realizado para poder seguir con el dlsefio del sistema.

37


2.1.40 Deserrolio de i05 conceptos de epoyo y mantenimiento [10]

Cuando se analizan los requisitos del sistema, la tendencia normal es comenzar por fijarse en aquellos elementos del sistema que estan relacionados directamente con la «ejecuci6n de la rnlslon», es decir: equipos principales, personal operador, software operatlvo, e informaci6n relacionada. AI mismo tiempo se presta poca atenci6n a los conceptos de mantenimiento y apoyo del sistema. En general, el enfasls en el pas ado se centraba s610 sobre parte del sistema, y no sobre la totalidad del mismo, como se estableci6 previamente. Esto ha side obviamente la causa de algunos de los problemas tratados en la Secci6n 1.1.

Para cumplir con los objetivos generales de la ingenierfa de sistemas, es esencial que todos los aspectos del sistema sean considerados bajo un enfoque integrado desde el principio. Esto incluye no s610 a los elementos relacionados con la misi6n principal del sistema, sino tarnblen la capacidad de apoyo. Los principales elementos del sistema deben disefiarse de tal forma que puedan ser apoyados eficaz y eficientemente durante el cicio de vida previsto, y la capacidad global de apoyo debe responder a este requisito. Esto significa que se deben considerar las caracterfsticas del disefio en 10 relativo a la red de apoyo (es decir: repuestos, reparables y consideraciones de inventario), equipos de apoyo y prueba, equipo de transporte y manejo, recursos lntorrnatlcos (como el software), personal y adiestramiento, instalaciones, y datos tecnlcos. Por tanto, es esencial que durante la fase del disefio conceptual sea desarrollado un «concepto de apoyo y mantenimiento» del sistema.

EI concepto de mantenimiento se desarrolla partiendo de la definici6n de los requisitos opsratlvos del sistema (ver Secci6n 2.1.3.), e incluye las acciones reflejadas en la Figura 11. Constituye una serie de ilustraciones y aseveraciones sobre c6mo debe ser disefiado el sistema para que sea apoyable, mientras que el «plan de mantenirnlento» define los sucesivos requisitos de apoyo del sistema basados

38


PRIMER ESCALON

OPERACION DEL SISTEMA· MISION EMPLAZAMIENTO

.OF'ERA,TIV() -----------,---------\

• MANTENIMIENTO CORRECTIVO Y PREVENTNO

• ~YO (ELEMENTOS CRInCOS)

• CAPACiDAD DE PRUEBADEL SISTEMA. (INCORPORADA)

• PERSONAL (BAJA CUAUFICACION)

• ENTORNO OPERATIVO

: INSTAlACIONES: :,,'y'----------------'

"

,,--_ '~

.>: /) ---, SEGUNDO ESCALON

, "" ::, " .. ( -: /!

"""'" ,...,.,)<> ~ ;",~,~'~ "'.::::::,' , • MANTENIMIENTO CORRECTIVO

, : iii : i / Y PREVENTNO (NIVEL SUBSISTEMA.)

"""""""""", • APOYO

'\ ,~# A • EOOIPOSDEAPOYOYPRUEBA

,*,'/f" I . PERSONAL (CUALIFICACION MEDIA)

C~f[~~~"~~~~~:~r;~Di 4# • INSTAlACIONES DE TALLER DE CAMPO

""'" 'r

" ......., TsuMI~mRADOOESl

-- "* !DE~p(J~E~!

TERCER ESCALON

• MA.NTENIMIENTO DE DETALLE

• REVISION

• CALIBRACION

• FABRICACION '~YO

• PERSONAL

• EOOIPO DE PRUEBA EN FABRICA

• INSTAlACIONES FIJAS

~ FLUJO DE MA.NTENIMIENTO """""'):0- FLUJODE~YO

Figura 11. - OPERACION DEL SISTEMA Y FLUJO DE MANTENIMIENTO-

en los resultados de los anallsis de apoyo logfstico u otros estudios similares [10]. EI concepto de mantenimiento se plasma finalmente en un plan de mantenimiento detallado. Hefirlendcncs a la figura, se debe tratar el flujo de materiales y actividades desde el dlsefio, pasando por la fabricaci6n, hasta los lugares de uso operativo. Se produce un flujo de mantenimiento cuando los componentes son enviados desde su emplazamiento operative a las instalaciones de mantenimiento de segundo 0 tercer escal6n.

Revisando la red en conjunto, se deben considerar aspectos tales como los niveles de mantenimiento, las responsabilidades y funciones a desarrollar en cada nivel, los criterios de disefio relativos a los diferentes elementos de apoyo (por ejemplo, tipo de repuestos y niveles de inventario, fiabilidad de los equipos de prueba, cantidades y cualificaciones del personal), as! como los facto res de efectividad de la capacidad global de apoyo. Aunque pueda parecer que el disefio de los principales componentes de un sistema es el adecuado, la

39


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

Aunque pueden existir variaciones, dependiendo de la naturaleza y tipo de sistema, el concepto de mantenimiento general mente incluye la siguiente informaci6n:

a. Niveles de mantenimiento - el mantenimiento, preventivo 0 corrective, puede realizarse sobre el mismo sistema (0 sobre un elemento del mismo) en su lugar de utilizaci6n por el usuario, en una instalaci6n de segundo escal6n, pr6xima a dicho emplazamiento, 0 en una instalaci6n de tercer escal6n 0 del fabricante. Los niveles de mantenimiento conciernen a la divisi6n de funciones y tareas de cada area en la que se ejecute el mantenimiento. La frecuencia prevista de mantenimiento, la complejidad de las tareas, los requisitos de cualificaci6n del personal, necesidades de instalaciones especiales, etc, dictan en gran medida las funciones especfficas que deben ser desarrolladas en cada nivel. Dependiendo de la naturaleza y misi6n del sistema, pueden establecerse dos, tres y hasta cuatro niveles de mantenimiento. En cualquier caso, para facilitar las siguientes descripciones clasificaremos el mantenimiento como «de primer, segundo y tercer escalon». La Figura 12 describe las diferencias basicas entre estos niveles.

b. Polfticas de reparaci6n - dentro de las limitaciones ilustradas en las Figuras 11 y 12, puede haber un nurnero de politlcas posibles que especifiquen el grado en que puede realizarse la reparaci6n de un componente del sistema (caso de que exista). Una polltlca de reparaci6n puede dictar que un elemento sea designado como no reparable, parcialmente reparable, 0 totalmente reparable. Las polltlcas de reparaci6n se establecen inicialmente, se desarrollan criterios, y el disefio del sistema progresa enmarcado en la polltlca de reparaci6n seleccionada. Un ejemplo de una polftica de reparaci6n para un Sistema XYZ, desarrollada como parte del concepto de mantenimiento durante la fase del disefio conceptual, se describe en la Figura 13.

40


llpo de lrabajo IlIBlizado?

Equlpo propledad de Is organlzacl6n usuarla

__________________________ , L , _

De qulen es el equlpo? Uso llel equlpanientD lie la organlladlin ~

CRitERIOSP~MER~c:AL~~slluNDOWGAL()N~R~RWCAL~< ---------------------------,-En-el~:=~=-o:~=----------·---~~==-::--y-----U-nld::fiJ:---------------I~=:==-lnd~=~I:---------··

Hecho en d6nde?odonlle asl6localizadD ~ 0 semilYlllvil911 ~ •

• II equlpo pI1nc1pel iC;;~i6~:h;~~:fi

, caleta porttHI, • • htividad especializada de rep8lllCilln,

, 0 equlvalenle ~ Taller IJo de campo • 0 planla del fabrican1il

--------------------------"--------------------------- j __l ----------"----------l'iiiiiiiiilifife-liliiiiKi!iii-o-----------

Hecho por qulan? • PeIllOOlll ope.llel ~ PelllOnal asignado a unidades • pelllOnal de producci6n

':' slslBma/ ..... po .,' fi;as, mOviles 0 semim6vi1es :,' (mezcIa de cualilicaciones

...,,, , de fablicaci6n intermedia

)ba~ctJBificacijnden1Snleni~lento): (~IIfic:aciOninleiTrMld~ds~~nlani~isr1lD)c)'liliaciernan1BninieJllDL

Inspec:cl6n visual Comprobaci6n operativa Man1Bnimienlo manor Ajus!BS exlBmas Sustituci6n de slsll1lHllDs

• Inspecci6n dlllallada y

• oomprobaci6n del_rna ~ Manlsnimianto mayar

• Repel3c:it1n Y modificacion911 ~ de equipoa principeles

• AjIl8les diflciles

~ Calibl3ci6n limitada

• Sobrecarga del primer escal6n , de manleniniento

Ajusles diflcilas en fabrica

Reparaci6n y rnodilicaciones de equipos oomplejos

Revisi6n y reoonBtrucci6n Calibraci6n detallada ~

Sobrecarga del segundo escal6n de manlenlmlento

Figura 12. - PRINCIPALES NIVELES/ESCALONES DE MANTENIMIENTO-

c. Responsabilidades orqanlcas -Ia eiecuci6n del mantenimiento puede ser responsabilidad del usuario, del fabricante (0 suministrador), de terceros, 0 de una combinaci6n de ellos. Adernas, estas responsabilidades pueden variar, no s610 con respecto a diferentes componentes del sistema, sino a medida que se progresa en la fase operativa y de apoyo al sistema. Las decisiones relativas a responsabilidades orqanlcas lnflulran en el disefio del sistema desde un punta de vista de diagn6stico y empaquetado, de polfticas de reparaci6n, clausulas de garantfa de los contratos, y otros aspectos afines. Aunque puedan cambiar las condiciones, es necesario definir en esta fase unos supuestos iniciales.

d. Elementos de apoyo logfstico - como parte de la definici6n del concepto de mantenimiento inicial, deben establecerse los criterios relativos a los distintos elementos de apoyo logfstico. Estos elementos incluyen el aprovisionamiento (repuestos y reparables, inventarios aso-


ciados, datos de aprovisionamiento), equipos de apoyo y prueba, personal y entrenamiento, equipo de transporte y manejo, instalaciones, datos tecnlcos y recursos lnforrnatlcos. Tales criterios, como datos de entrada al dlsefio, pueden incluir provisiones de autodiagn6stico, requisitos de prueba incorporados (built-in) y/o externos, factores de normalizaci6n y empaquetado, cantidad y cualificaci6n de personal, factores y limitaciones de transporte y manejo, etc. EI concepto de mantenimiento proporciona algunos criterios iniciales de dlsefio del sistema relativo a las actividades reflejadas en la Figura 11, mientras que la determinaci6n final de requisitos especfficos de apoyo logfstico se produclran a traves de la realizaci6n del anal isis de apoyo logfstico (Logistics Support Analysis, LSA), que se realiza sequn progresa el dlsefio,

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

MANTENIMIENTO DE PRIMER ESCALON

PAANlENIMIENTO DE SEGUNDO ESCALON

PAANlENIMIENTO DE lERCER ESCALON

LABORATORIO DE CALIBRACION

.-

, __ ,,~ RepolBl'yiD .... bmr

,----- - - - - - - - - - - - - - - - - - - - - - - - -: NOTAS:

~ • rIB""", de calibrm:i6n -II hr. ~ 1, r .. rlas piezas

, , 2, Loa 1aJj9tas de cmA> 99 dleal\an

00,"" desachabI ..

3, La reparm:i6n del.umi1is1m

de potaneIa 99 !HIlla mil _call'lllllla an ta ...... cakin

Figura 13. - POLITICA DE REPARACION DEL SISTEMA -

41

42


de que un repuesto esta disponible cuando se necesite, la probabilidad de exlto de una misi6n para un determinado nurnero de repuestos, y la cantidad econ6mica de pedido en relaci6n con la adquisici6n de inventarios. En 10 relativo a los equipos de prueba son factores determinantes la longitud de la cola de equipos que esperan ser probados, el tiempo de procesado de la estaci6n de prueba y la fiabilidad del equipo de prueba. En 10 que concierne al transporte son significativos la tasa esperada, sus duraciones, fiabilidad y costes. En cuanto al personal y su adiestramiento, debe considerarse nurnero y cualificaci6n del personal, niveles de su formaci6n, tiempo de formaci6n y fiabilidad de los equipos de adiestramiento. EI nurnero de errores por linea de c6digo puede ser una medida importante en el caso del software. Estos facto res deben considerarse en relaci6n con requisitos especfficos a nivel sistema. No tiene sentido especificar unos requisitos muy exigentes para la reparaci6n de elementos principales de un sistema si se tarda 6 meses en conseguir un repuesto necesario. Los requisitos de efectividad aplicables a la capacidad de apoyo deben ser un complemento de los de la totalidad del sistema.

f. Entorno - definici6n del entorno en 10 referente al mantenimiento y apoyo. Esto incluye temperatura, vibraciones y choques, humedad, ruidos, entornos articos 0 tropicales, terrenos llanos 0 montafiosos, entornos marftimos 0 terrestres, etc., aplicado a las tareas de mantenimiento y funciones relacionadas de transporte, manejo y al macenamiento.

Resumiendo, el concepto de mantenimiento constituye la base para el establecimiento de los requisitos de soportabilidad en el diseno del sistema. Dichos requisitos no solo influyen sobre los elementos principales del sistema, sino que adernas deben proporcionar gufa en el dlsefio y/o adquisici6n de los elementos necesarios de apoyo logfstico. Adernas, el concepto del mantenimiento constituye la base para el desarrollo del plan de mantenimiento detallado, que se preparara durante la fase del disefio detallado y desarrollo.

43


2,1,5. Deserroito y esiqnscion de prioridedes de rtiedides de ptesteciones tecnices

Tomando como base los requisitos operatlvos y el concepto de mantenimiento se desarrollan criterios cualitativos y cuantitativos «para el disefio». Son especial mente interesantes los facto res cuantitativos 0 rnetricas asociadas al sistema que se esta desarrollando. Estas rnetricas, que se suelen denominar «rnedidas de prestaciones tscnlcas» (Technical Performance Measures, TPMs) 0 «parametres dependientes del disefio», deben fijarse inicialmente como parte del proceso de definici6n de requisitos durante el disefio conceptual. Las TPMs adecuadas deben identificarse para cad a nivel de la estructura [erarqulca del sistema e incluirse en la especificaci6n del sistema (Tipo «A»), deben ser inherentes al subsiguiente proceso de revisi6n y evaluaci6n del programa y medirse por medio de la realizaci6n de diversos anallsis y predicciones, y deben ser verificadas mas tarde a traves de la prueba y evaluaci6n del sistema. Estos facto res (0 sea, los valores especificados en cad a caso) lnflulran sobre las tecnologfas seleccionadas para el disefio, el empaquetado del sistema y la selecci6n de componentes, las herramientas/modelos utilizados para los anallsis y sfntesis del disefio, etc.

Para identificar las TPMs, se debe partir de una estructura global como la mostrada en la Figura 14. En todo sistema, estan los facto res tecnicos, representados aquf como «efectividad del sistema», que son una funci6n de sus prestaciones, disponibilidad, fiabilidades de misi6n, capacidad, fiabilidad, mantenibilidad, manufacturabilidad, desechabilidad, y otros facto res similares que pueden relacionarse directamente con los requisitos opsratlvos y el concepto del mantenimiento del sistema. AI otro lade del espectro esta el aspecto del coste, que debe ser considerado desde una perspectiva de cicio de vida. Aunque existen diversas categorfas de costes utilizadas diariamente en el proceso de toma de decisiones (como costes de obtenci6n 0 adquisici6n, costes de producci6n y/o construcci6n, costes operatlvos y de apoyo, costes de retirada, etc.), deben ser vistos en el contexto

44


r---~~~~;~~~~---1

---------------~---------------

'.1]----------------.

C~~~~~FJ.~I~~~~~IJA.] rEFE~IVI~IlEJ.~'S1l:~J

+

:D:l==:!r:::iR=::l[~:E~][~~~D~:-

I :g~~~==~N~~~O

i • COSTE DE APOYO Y OPERACION

i • COSTE DE FINALIZACION Y RETlRADA DE SERVlCIO

cf

--I------::::::::~~~~~~~~~~:::::::::~-------!-- -----------------------------::~~:~~~~~§:::-----

~--~----------------FiABLIDAD--------------T------------------------ .. ···················----------;-----EooiPO-iiEAPOVO-YPRUEBA-----

u::: == ' r-==~::--=

li'------------PR~~Um;V;DAD------------f----------- -----------------------;------R~~UR~-I~F;;ru;v;n~~------~

~--~'------------~~~~------------- '-----------~~-T~~~~~------------:---

L'---------~~~~~~,~--''''''' .. ------------------------- ----------,'------------;~;;~~;~~~~------------

1---;-----------------mR~-----------------~ -----r--EM;Q~ET;;oo:;;;;IP-u;;;;-i;~-:---j

i ALMACENANIENTO Y TRANSPORJE :

figura 14. . RElACIONES DE EFECTMDAD .

del coste total del clclo de vida. Esto es necesario si el aspecto del «riesqo», asociado con las consecuencias de decisiones, va a ser debidamente considerado.

Heflrlendonos a la Figura 15, debe desarrollarse un «arbol de objetivos» (0 un enfoque equivalente), comenzando con un grupo de descriptores generales y continuando con un desarrollo de arriba-abajo. Lo que se pretende es partir de un objetivo general del sistema considerado como un todo, y entonces desarrollar algunos modificadores que apoyen este objetivo del maximo nivel. Esto, por contra, establece un marco de referencia para la posterior asignaci6n de los criterios de disefio cualitativos y cuantitativos.

Dada la identificaci6n de criterios cuantitativos (es decir, medidas de prestaciones tecnlcas), deben establecerse las «priorldades» adecuadas, tal como 10 aprecie el usuario. Mediante un trabajo en equipo, involucrando al personal adecuado del cliente y del contratista, las

45


DlSEFiAR Y DESARROUAR

UN SISTEMA QUE SATISFAGA LOS REQUISITOS DEL CLiENTE DE UNA FORMA EFECTIVA Y EACAZ

, ,

, ,

, ,

,-----------------------------------------------_.

________________ r~~-------------------------------------------~-----------------------------~~~~~~~~~~~~~~~~~ _

MAXIMIZAR VALOR ECONOMICO

MAXlMIZAR EFECTIVIDAD DEL SISTEMA

-----------------,---

----------------,

A/

________________________ c (

_______ ~~~~] __ ~-------------~~~~~~~~~]___ _ L --------------~~~~~~~~]

~~~~~I~:: -',ii :~ :~~~i 1 :~r~f" I ASEGu~1

TECNICAS DE DlSPONIBILIDAD i DE SEGURIDAD i iMANUFACruRABILIDADi

-------------------------, ----------T----------- c ;:; : l----------T-----------..i

',.------~----------------~------------------~-----~-- c~ >.' 1 :, ---------------------:, 5

r----~ns~ii-----i IL '

i NECESIDADES : i MINI MIZAR

lD~!~~i i PESO

r L ,

MINIMIZAR

: COSTE TOTAL • i DEL CICLO DE VIDA i

'--------------:------------'

~~v

MIOOMiZAR!

• BENEFICIOS i

U~~~)__i

ASEGURAR FIABILIOAD DEL SISTEMA

ASEGURAR MANlENIBILIDAD DEL SISTEMA

MAXlMIZAR VELOCIDAD

.------~GI~~---------------------------~i~URAA·····j

• SOPORTABILIDAD • i DESECHABILIDAD •

, , i ~~~~_I? ___i

Figura 15. - ARBOl DE OBJETIVOS (PARCIAL) -

TPMs deben ser priorizadas con el fin de identificar los criterios de diserio que deben introducirse para cumplir, 10 mas fielmente posible, las necesidades del usuario. Estos criterios deben incluirse en las especificaciones adecuadas, empezando por la especificaci6n del sistema y descendiendo a traves de las especificaciones de los diferentes subsistemas, productos, procesos y/o materiales, que sean necesarias. Los principales factores deben, por supuesto, recibir la maxima atenci6n de los gerentes y los ingenieros de disefio, y deben ser considerados en el plan de gesti6n de riesgos del programa (0 equivalente). La Figura 16 presenta un esquema reducido de este enfoque. N6tese que las responsabilidades de entradas de disefio y de «sequlrnlento» de estas TPMs a traves del proceso de desarrollo del sistema estan alimentadas con diversos componentes de la organizaci6n del proyecto.

Ingrediente importante en la realizaci6n del proceso de anallsls y definici6n de requisitos, que es tarnblen reiterativo por naturaleza, es la comu nicacion necesaria que debe existi r entre el usuario (ej.: el

46


cliente) y el fabricante (ej.: el contratista). Debe establecerse un trabajo en equipo para realizar una transici6n efectiva de la especificaci6n de necesidad del usuario en la definici6n de los criterios de dlsefio EI empleo de una tecnlca como el despliegue de la funci6n de calidad puede facilitar las necesarias comunicaciones [12].

2.1.8, Eteborecion de le especiticecion del sistema (Tipo ((A»)

Desde la perspectiva de la ingenierfa de sistemas, el documento mas importante de un determinado programa, en 10 que se refiere al disefio, es la Especificaci6n del Sistema (Tipo «A»). La Figura 7 describe la configuraci6n funcional basica y constituye el primer paso en la implantaci6n de un enfoque disciplinado en el disefio y desarrollo de un sistema. Incluye los resultados del proceso de anallsls de requisitos, y conduce a los requisitos de dlsefio de subsistemas y otros componentes del sistema. Baslcarnente es el «clrnlento» a partir del

VELOCIDAD 100 MPH 21 INGENIERIA FABRICACION
(MINIMa) MECANICA MATERIALES
ESTRUCTIJRAL
COSTE DEL $1.8OOJAfilo 19 INGENIERIA LOGISTICA
CICLO DE VIDA (10AlilOS) DE SISTEMAS FABRICACION
VALOR AIiIADIDO
DIMENSIONES 10 PIES DE LARGO 18 INGENIERIA FABRICACION
6 PIES DE ANCHO ESTRUCTURAL MATERIALES
4 PIES DE ALTO MECANICA
(MAXIMO)
DISPONIBILIDAD 98.5% 15 INGENIERIA FIABILIDAD
(OPERATIVA) (MINIMa) DE SISTEMAS MANTEN IBILIDAD
LOGISTICA
PESO 600 LIBRAS 12 INGENIERIA FABRICACION
(MAXIMO) ESTRUCTURAL MATERIALES
MECANICA
FACTORES MENOSDEL1% 10 INGENIERIA DE SISTEMAS
HUMANOS DE TASA DE ERROR FACTORES HUMANOS DISEI'iIOINT.
PORAfilo ELECTRICA
MANTENIBILIDAD 3000 MILLAS 7 INGENIERIA DE SISTEMAS
(MTBM) (MINIMa) MANTENIBILIDAD LOGISTICA
ELECTRICA

Figura 16. - ATRIBUTOS DEL SISTEMA (REQUISITOS DEL CLiENTE) 47


cual se deriva la totalidad de los requisitos tecnlcos. La Figura 17 presenta un ejemplo de 10 que puede ser incluido en la especificaci6n de un sistema.

En multitud de proyectos, la especificaci6n del sistema es demasiada vaga y no describe los requisitos de forma definitiva. Esto se hace a veces intencionadamente para poder introducir mas tarde nuevos requisitos 0 tecnologfas durante el cicio de vida. AI mismo tiempo se preparan y negocian contractual mente especificaciones de mas bajo nivel (como son las especificaciones del producto, del proceso, del software, y/o del material), y el disefio detallado de los subsistemas y componentes progresa sin el beneficio de tener un s61ido cimiento sobre el que construir. Cuando los diferentes componentes son finalmente integrados de abajo-arriba, se producen desajustes, incompatibilidades, etc. Esto se convierte generalmente en un proceso costoso. Por ello es fundamental que sea preparada y seguida fielmente desde el principio una buena y completa especificaci6n del sistema [13].

2,2, Anallsis tunelonal y aslgnaci6n de requtsltos

EI siguiente paso en el proceso de ingenierfa de sistemas es la transformaci6n de los requisitos del sistema en criterios detail ados de disefio y la identificaci6n de los requisitos de recursos especfficos a nivel subsistema e inferior. Esto se realiza mejor por medio del «analisis funclonal». Una funci6n se refiere a una acci6n concreta 0 especffica que debe desarrollar el sistema para cumplir un objetivo dado; por ejemplo, la operaci6n que un sistema debe realizar para cumplir su misi6n, 0 la acci6n de mantenimiento necesaria para devolver el sistema a condici6n operativa. Tales acciones pueden ser realizadas a traves de la utilizaci6n de eguipos. software. personas. instalaciones. datos. 0 una combinaci6n de ellos. No obstante, el objetivo en este momento es el especificar los «QUE» y no los «COMO»; 0 sea, gue es necesario realizar en vez de c6mo debe realizarse. No debe

48


ESPECIFICACION DEL SISTEMA

1.0. Alcance

2.0. Documentos aplicables 3.0. Requisitos

3.1. Definicion del sistema 3.1.1. Descripci6n General

3.1.2. Requisitos operalivos (necesidad, misi6n, perfil de utilizaci6n, disbibuci6n, cicio de vida) 3.1.3. Concepto de mantenimiento

3.1.4. Diagramas del sistema (analisis funcional. diagramas de flujos funcionales del sistema/producto) 3.1.5. Criterios de interfases

3.1.B. Condiciones ambientales

3.2. Caracterfsticas del sistema 3.2.1. Prestaciones

3.2.2. Caracterlsticas f1sicas 3.2.3. Requisitos de efectividad 3.2.4. Fiabilidad

3.2.5. Mantenibilidad

3.2.B. Factores humanos

3.2.7. Soporlabilidad

3.2.B. Transporlabilidad/movilidad 3.2.9. Reconfigurabilidad

3.2.10. Disponibilidad

3.2.11. Supervivencialvulnerabilidad 3.2.12. otros

3.3. Diseiio y construcci6n 3.3.1. Requisitos CAD/CAM

3.3.2. Materiales, procesos y partes 3.3.3. Montaje y etiquetado

3.3.4. Radiaci6n electromagneUca 3.3.5. Seguridad

3.3.B. Intercambiabilidad 3.3.7. Mano de obra

3.3.B. Flexibilidad de diseno 3.3.9. Requisitos de software

3.4. Documentaci6nJdatos 3.5. Loglstica

3.5.1. Requisites de mantenimiento 3.5.2. Apoyo

3.5.3. Equipo de apoyo y prueba 3.5.4. Personal y adieslramiento 3.5.5. Instalaciones y equipamiento

3.5.B. Empaquetado, manejo, almacenaje y lransporte 3.5.7. Recursos infonnaticos

3.5.B. Adquisici6n y apoyo continuo durante el cicio de vida (CALS) 3.5.9. Servicio al cliente

3.B. Manufaclurabilidad 4.0. Evaluaci6n y prueba

5.0. Provisiones de aseguramiento de calidad B.O. Preparaci6n para entrega

Figura 17. - FORMATO DE ESPECIFICACION DEL SISTEMA TIPO WAil - (EJEMPLO)

49


identificarse ni adquirirse ninqun equipo, elemento de software, elementos de datos, 0 elemento de apoyo logfstico si no ha side justificado a traves del anal isis funcional.

EI analisls funcional constituye el proceso iterativo de estructurar o descomponer los requisitos del nivel sistema, a los subsistemas, y tan abajo en la estructura jerarqulca como sea necesario para identificar los recursos especfficos y los distintos componentes del sistema. Representa una definici6n del sistema (y actividades asociadas) en terrnlnos funcionales e incluye funciones del sistema, de producci6n, de utilizaci6n, de mantenimiento y apoyo, etc. La realizaci6n del anallsls funcional se facilita mediante el uso de diagramas de bloque de flujos funcionales. La Figura 18 muestra un diagrama de flujo simplificado con cierta descomposici6n. Las funciones de alto nivel se descomponen en las de segundo nivel, las funciones operativas conducen a las de mantenimiento, y se emplea la numeraci6n de bloques para proporcionar capacidad de

FUNCIONES DE PRIMER NIVEL DEL SISTEMA

FUNCION 'CO

FUNCION '0'

~_,o_ ~: _

2.0

-----~~~~~~-:~:-]

-'T:~ ----~--- -------------r:------------

-,~--~,Q_--.j,---------:_-~,

1 FUNCION"E"J~-------------------:: !ML + ;

___l<'L__~_~_~~~~_~_~~: i

:~,Q_------------------,

:~J:I__-----l-----------,

FUNCIONES DE TERCER NIVEL "-t _

5 5 1 [------------------------1 5.5.2 ---fr:

>- . ._ -»'l t J-- : :

:------------»'-<

,--x---------------------,

____ §A;;,;4 ~I------!;i-,5-,5------,.. ( !

'-----------,K-----------I

l :_-~: __ : :_- _ .. __ -_- -_- _ _- __ .. >~-------------------- _

Figura 18. - DESCOMPOSICION FUNCIONAL DEL SISTEMA-

50


seguimiento, tanto descendente como ascendente, de los requisitos.

La Figura 19 ilustra el proceso de evoluci6n, desde la definici6n de la necesidad a la identificaci6n del escenario para una capacidad de transporte, y al anallsls funcional. Las funciones operativas conducen a la descripci6n de funciones de mantenimiento (ver bloque 9.5.1.). La Figura 20 muestra un ejemplo en el que uno de los bloques del diagrama de flujo es evaluado en terrnlnos de entradas, salidas, controles y/o limitaciones, y mecanismos facilitadores. N6- tese que las expresiones de cad a bloque estan «orientadas a acciones», y que los «rnecanlsmos» baslcarnente conducen a la identificaci6n de los recursos necesarios para desarrollar la funci6n; por ejemplo, un equipo, un elemento de software, una herramienta de anallsls del dlsefio, una instalaci6n, personas, datos de informaci6n, u otros cualesquiera. La Figura 21 muestra un ejemplo de formateado de datos. Esto, por supuesto, debe ser «adaptado a los requisitos especfficos de un programa dado» [14].

Los diagramas de bloques funcionales se desarrollan principalmente con objeto de estructurar los requisitos del sistema en terrnlnos funcionales, y sirven para ilustrar la organizaci6n del sistema e identificar las principales interfaces funcionales. EI anallsis funcional, iniciado durante las ultlrnos pasos del dlsefio conceptual, esta orientado a permitir la finalizaci6n del proceso de dlsefio y desarrollo del sistema de una forma completa y 16gica. Mas concretamente, el enfoque funcional ayuda a asegurar 10 siguiente:

1. Que se han considerado todas las facetas del dlsefio y desarrollo, producci6n, utilizaci6n, y apoyo del sistema, es decir, todas las actividades significativas durante el clclo de vida del sistema.

2. Que estan completamente reconocidos y definidos todos los elementos del sistema, como los equipos principales, los repuestos y los reparables, el equipo de apoyo y prueba, instalaciones, el personal, los datos y el software.

NECESID.6D

IlesirDliJ lIIa......;tlo~ de IrIlspJrle entre Cb1adWyc1I1i11'B'

Resull9:los de Mliliis (SeMI'8I' capaciill de tralBplXl! rill!Oj

..... J

FIjUIlI19, • DESARROllO EVOLlITIVO DE REQUISITOS FUNCIONALES •

Flup funaonal de primer niwl del sistema

2 ! Produdr

,~D~nar~,'II--'11 ; ~ ele~ntos ,

L______________ i i sistema 4, i i dBSlstema i B ~

! Definir it Ideaerlll1~~1 ~ i Integraoon i,----Jrt~g~j-----, i i Dsbibuir i

! necesidadesf-( Y :) ,3 ~} Y prueba !+: Y '; .6__ ~ L i el sstema c~

~ del sistema ~ \ ~ Di~n~rl i • del sistema ~ '_./ i Adquirir ! > para utilizaci6n !

d9~!~_~9__ i ~ capaddad I!j ~ r----} elementos del usuario

i de apoyo r---J i J i de apoyo

! __ ~_~~_~~~_~ __ !--}i:O! c1~---'

.~- ---~ Fabricar ! i

i e~menlos fJ

FI' f 'Id do . I ! deapoyo !

uJO unclo~ e segun mve , J

11.- - - - - - - - - - - - - - - - - - - - -----.----.-----.-----.-----.--«----.-----.----.-----.-----.---------.-----.-----.----.---- -----.----.-----.-----.-----

tJ1PiePiOillCiiJdlii. rJ_: }IPCi-~d-ade'A~! J8~~~~

9.0 i 'i aeronave i-l"j aeronave ~~i de Ci d d 'A' !-1"j u i"'i Ci dad 'B' i

r~~rar ~f~i~~~-- I c_~~_~_~~~_1 lJl8~~~ue, c ~_~ _! c ~_~~~~_~~_'____ i~nul

i en enlomo)- 0 de usuario

. - - - - - - --- - - - - ~ - - - - - - - - - _.

9,2 '------pre~rar-----!

l } aeronave !;

, ~---~~-~~~---~

Flujo fundonal de segundo nivel

__ - __ __ __ _~ - --------'1

95 Y _9,5J______________ 9._52________________ 9.5.3 9.5.4

r. Ref. ----------i ! Verilicac~n F! Contado i F ICOntado ! F -------Reclb;------I

, Procede de .~ del subsislema--~ control de tierra !-}I control de tierra if-I inslrucciones r+

I Ciudad 'AI a Ciudad 'B' ! ' I de comunicaci6n ! de Ciudad 'AI! I de Ciudad 'BI! I de aterrizaje !

.____ ! .! • , L____ L •

'W f - - -} Flup de Manlenimiento

5 1


3. Que existe un medio para relacionar conceptos de empaquetado y requisitos de apoyo del sistema con funciones especfficas del mismo; 0 sea, satisfacer los requisitos de buen disefio funcional.

4. Que se establecen las adecuadas secuencias de relaciones de actividades y disefio, junto con las interfaces crltlcas de disefio. EI anallsls funcional proporciona una descripci6n inicial del sistema y, como tal, tiene multiples aplicaciones. Por ejemplo, el anallsls funcional se utiliza como «entrada» en el desarrollo de los siguientes requisitos, aplicables ala mayorfa de los programas:

1. Disefios electrlcos y rnecanlcos de empaquetado funcional, seguimiento de funcionamiento y provisiones de diagn6stico.

2. Modelos de fiabilidad y diagramas de bloques.

3. Anallsls de modos de fallos, sus efectos y su criticidad (Failure Modes, Effects, and Criticality Analysis, FMECA).

4. Anallsls de arbol de fallos (Fault Tree Analysis, FTA).

5. Mantenimiento centrado en la fiabilidad (Reliability-

centered Maintenance, RCM).

6. Anallsls de riesgos/seguridad del sistema.

7. Anallsls de mantenibilidad.

8. Analisls de nivel de reparaci6n.

9. Analisls de tareas de mantenimiento (Maintenance Task Analysis, MTA).

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

11. Diagramas de secuencia de acciones (Operational Sequence Diagrams, OSDs).

12. Anallsls de apoyo logfstico (Logistic Support Analysis, LSA).

13. Instrucciones de utilizaci6n y mantenimiento.

En el pasado. el analisis funcional. no ha side siempre realizado en el momento adecuado. si es gue se realizaba. Como conse-

52


cuencia de ello, las diferentes disciplinas de disefio asignadas a un programa determinado han tenido que generar sus propios anal isis para cumplir con los requisitos del mismo. En gran cantidad de casos, estos esfuerzos se realizaban de forma independiente, y muchas decisiones de disefio se tomaban sin el beneficia de tener una Ifnea de referencia que seguir. Por supuesto, esto resultaba en discrepancias de disefio y costosas modificaciones en momentos posteriores del ciclo de vida del sistema. De aquf, el anallsis funcional es necesario y proporciona una excelente Ifnea de referencia y todas las actividades pertinentes de disefio deben «sequlr» la misma fuente de datos (como puede ser la definici6n de la configuraci6n del sistema) para satisfacer los objetivos de la ingenierfa de sistemas. Por esta raz6n, el analisis funcional es considerado una de las actividades fundamentales en el proceso de ingenierfa de sistemas.

Dada una descripci6n de alto nivel del sistema en terrnlnos funcionales, el paso siguiente es combinar, 0 agrupar, las funciones similares en subdivisiones 16gicas, identificando los principales subsistemas y componentes de los niveles inferiores de la totalidad del sistema (el desarrollo de un esquema de empaquetado funcional del sistema). Esto resulta en la identificaci6n inicial de equipos, software, medios humanos, instalaciones, datos, 0 sus combinaciones. La Figura 22 muestra (conceptualmente) la evoluci6n de un diagrama de flujo de funciones 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 ffsicos, software, 0 entidades equivalentes.

La Figura 23 muestra el flujo de actividades del proceso de adquisici6n, conduciendo de la linea de referencia sefialada en la Figura 7 a los ciclos individuales de desarrollo para varios elementos del sistema. En este caso, se muestra la integraci6n de los desarrollos de los ciclos de vida de los equipos, el software y los recursos humanos del sistema, partiendo del anallsis funcional (Bloque 0.2 de la Figura 7). N6tese que estes son los unicos componentes del sistema

DIAGRAMA SIMPLIFICADO DE FLUJO FUNCIONAL

1.0

2.0

3.0

4.0

DESARROLLO DE REQUISITOS FUNCIONALES (EJEMPLO)

1.0

2.0

3.0

4.0

... ...¥ ~limenlaci6n'v , ,

OPERACION DEL SISTEMA EN MODO "A·

.-------------------

14.0 ¥

I A:~ !u;'~I'i RE:~

, 'DEFECTUOSA

II

14.1

4.2

4.3

OPERACION DEL SISTEMA EN MODO "8·

F! OPERACION )i DEL SISTEMA EN MODO·C"

14.2

14.3

;:;'~;::I

}! DEFECTUOSA f·"ii i A TALLER DE i

i MANTENIMIENTO !

lJ

REPARAR UNlOAD DEFECTUOSA

. ,

~'~ \ ..

./ /

!

•

IDENTIFICA

NECESIDAD Y DISEfilo FABRICACION

DETERMINA , .... ) Y DESARROLLO} DEL SISTEMA I· .. }

REQUISITOS DEL SISTEMA (PRODUCCION)

DEL SISTEMA

! • •

: J

OPERAR

Y MANTENER> \ ELSISTEMA

I

: CONTROLESlLlMITACIONES

- ReglasIProcedimientos

- Especificaci6n(es} del clienle

- Factores relacionados . Polflicos, Tecnol6gicos,

Medioamblenlales, economicos, sociales

,i- Requisi\llS del Sislama i · .. :

, .» • ENTRADAS- Eslructura organizativa i DISEflo Y DESARROLLO:

.......i - Materia pr1ma l DEL SISTEMA :

- Sistema disenado lislo

para fabricaciDn : SALiDAS

- Dm de diseno

- Desech09

- Recursos humanos - Ayudas de diseflo

- Recursos mateliales - InslalacioneslHerramientas

m~~m ............ m

F'" FunClona"":

,L ~L~~~~_!

. :

: MECANISMOS !

________________________________________________________________________ 1 !

Figura 20. - DESARROLLO DE REQUISITOS FUNCIONALES -

PROCESO DE DISENO DE INGENIERIA DEL SISTEMA CONCEPTUAL

Realimentaci6n y Control

Estudlos de cllente; elementos de mercado; embarque y servicio de sondeos, estudios de

mercado; investigaci6n de producto.

Relaci6n especfftca de necesidades cualitalivas y cuanlitalivas respondlendo a la carencia acrual.

Se debe lener culdado en establecer esta necesldad en t6rminos funcionales.

Disano Preliminar del Sistema

Punte de referencia; anallsis estadfslicos

de dales (ej., dales recogldos como resultado de estudlos y consolldados por embarque y servicio de sondeos, etc.).

21

22

23

Analisls de necesidades y deftnici6n de requisites

Sintesis de altemaUvas de diseno del Sistema ConcepbJal

Analis de las altemativas de diseno del Sistema ConcepbJal

Relaclon especiftca de necesidades cuanlitaUvas y cualltaUvas expresadas en IiIrminos funclonales.

Resultados de analisis de necesidades y proceso de deftniclon de requisites; esbJdios de investigaclon tecnologica; suministro de informacl6n.

Soluclones concepbJales de candidato y tecnologias; resultados de los anal isis de necesidades y proceso de definicion de requisltos.

Faclores cualitalivos y cuantitalivos pertinenles a niveles de prestaci6n del sistema, dislJibuci6n geograftca de productos, perfiles de utilizaci6n esperados, entemo del usuario/consumidor; cicio de vida operalivo,

requisiles de efectividad, niveles de mantenimiente y apoyo, consideraci6n de los elementos aplicables del apoyo loglstico,

entomo de apoyo, y etc.

Identiftcacion y descripci6n de las altemativas de diseno del sistema candidate conceptual y aplicaclones tecnol6gicas.

Aproximaci6n de la "bond ad" de cada soluci6n concepbJal ftable relativa a los parametros pertinenles, direclos e indireclos.

Esta bondad se podrfa expresar como tasa numerica, medidas probabilfslicas 0 medidas de distersi6n.

Despliegue de la funci6n de calidad (QFD);

matriz de entrada y salidad; chequeo de listado; ingenierla de valor; analisis de dales estadlslicos; analisis de tendencia; analisis de malriz; analisis paramelJlcos; categorias de model ns

analiticos y herramientas para esbJdios de simulacion, transacciones, etc.

Aproximaci6n de la generaclon del concepte de Pugh; reunion imaginaliva; analogia; comprobacion de listas.

Experlmentaci6n del sistema indireclo (ej., simulaci6n y modelado mate matico); analisis parame!rico; analisis de riesgos.

24

Evaluaci6n de las allemalivas de diseno del Sistema ConcepbJal

Resultados de las !areas de analisis en forma de conjunto de altemaUvas de diseno del sistema concepbJal de vlabilidad.

lislado simple 0 corte de los disenos del sistema conceptual preferidos. Ademas, la 'sensaci6n" de como la(s) aproximaci6n(es) preferenle(s) se relaciona(n) mucho mejor con las olras altemativas de ftabilidad.

Figura 21. - REQUISITOS DE RECURSOS Y ENTRADAS Y SALIDAS FUNCIONALES

Enfoque paramelrico dependiente del diseno; generaci6n de n(Jmeros hibridos para representar la "bondad" de la soluci6n candidata; presentaci6n de la evaluaci6n del disello del sistema concepbJal.

53


que deben contemplarse; sin embargo, son ellos los principales responsables del coste del sistema, y son los que deben ser adecuadamente integrados a 10 largo del disefio y desarrollo del sistema.

La Figura 24 presenta una descomposici6n de los componentes del sistema en forma [erarquica, que establece una estructura que conduce a la asignaci6n de requisitos (Bloque 0.3 de la Figura 7). Asignaci6n es -Ia descomposici6n de los requisitos a nivel sistema, efectuada de forma descendente hasta el nivel necesario que proporcione una entrada comprensible para el disefio y/o la adquisici6n de un determinado componente del sistema». Como se ve en la figura, es preciso especificar detalladamente los requisitos de disefio cualitativos y cuantitativos de los equipos, el software, etc., basados en los requisitos especificados a nivel sistema. Dada una medida de prestaci6n tecnlca, tal como el tiempo medio entre acciones de mantenimiento (MTBM), ~cuales deben ser los requisitos de MTBM al nivel de las unidades? Inversamente, los requisitos de MTBM de las diferentes unidades, cuando sean combinados, deben cumplir los requisitos de TPM a nivel sistema si este va a cumplir su misi6n. Esto es un proceso arriba-abajo/abajo-arriba, mostrando la «capacldad de seguimiento» de los requisitos hacia abajo y hacia arriba. En muchos casos en el pasado se ignor6 la parte arriba-abajo de este cicio. En otras palabras, se habra asumido el proceso abajo-arriba, estableciendo primero los requisitos de los niveles inferiores y esperando que los resultados finalmente respondieran a las necesidades del usuario. Esto. por supuesto. es un enfoque de «alto-riesgo».

Como ultimo paso, es crltlco que las adecuadas TPMs sean incluidas en las diferentes especificaciones de dlsefio y/o adquisici6n de componentes del sistema. La Figura 25 transmite la aplicaci6n de TPMs a los diferentes niveles [erarqulcos del sistema. Partiendo del arbol de objetivos (Figura 15) como ayuda del proceso de empaquetado y asignaci6n funcional (Figura 24), los criterios adecuados de diseno cualitativos y cuantitativos deben incluirse en las especificaciones aplicables. Si debe ser desarrollado un nuevo elemento los requisitos

54


apropiados deben incluirse en la especificaci6n de desarrollo Tipo «8» (0 equivalente); si va a ser adquirido un elemento comercial, los requisitos adecuados deben en la especificaci6n de producto Tipo «C», y as! sucesivamente. Los resultados de la asignaci6n (y la capacidad de seguimiento de los requisitos) debe ser inherente a las diferentes especificaciones y normas que se hayan impuesto para un programa determinado.

2.3. Anaitsis, sintests, evaluaclen y optlmtzaclen de! diseno

Con los principales requisitos de disefio establecidos, hay un proceso continuo e iterativo de analls!s, sfntesis, evaluaci6n, y optimizaci6n del disefio (Bloques 0.4, 0.5 Y 0.6 de la Figura 7). Este proceso comienza con la definici6n en termlnos generales de una configuraci6n del sistema durante la fase de disefio conceptual y continua hasta que el sistema y sus componentes esten perfectamente definidos y listos para entrar en la fase de producci6n y/o construcci6n.

Parte integrante de este proceso es la evaluaci6n de alternativas y la realizaci6n de estudios de soluciones de compromiso. Inicialmente pueden considerarse requisitos opsratlvos alternativos y la aplicaci6n de tecnologfas nuevas, 0 conceptos alternativos de mantenimiento y apoyo. A medida que el disefio avanza, hay muchas soluciones de compromiso posibles que incluyen aspectos tales como esquemas alternativos de empaquetado, rnetodos de diagnostico alternativos, la evaluaci6n y selecci6n de elementos comerciales, la incorporaci6n de automatismos 0 la realizaci6n manual de funciones, etc. Mas tarde habra procesos de fabricaci6n 0 estructuras de apoyo logfstico alternativas que necesitan ser evaluados. En general, el enfoque seguido en la realizaci6n de practlcarnente cada tipo de estudio de soluciones de compromiso se muestra en la Figura 26. Primero se debe definir el problema, identificar los criterios aplicables cualitativos y cuantitativos a utilizar en la evaluaci6n (esto es, las medidas de

1 ~ •

3.0- Funci6n i : : J--"2:1~--ld~~tiii~d6-~----: ~

)fdeC()ntr_olr 0-11 ------------------------------i<\. - y_-<--; !------------~~~-~-~-~------------

\. ----4:0~--F~-~d6~-d~------1 ! i i ~ r------------------------------------: '

\ )1t>i 1---,--:--,- ~ 2.2- Volumenl

-------- '~~t!J\l~~~c:a~~~1 l ~_~!_~~~ _

i _' ,----------~-----1:0~-~::~d6~----l-:_</------1 5·~~IS~~~~s~.~-~~~~~

Somma' / <'Ii .. , / ;~2.~;6nj /j,~:i~5:2d:~:on~;~~JE2~n _il'------------;~~~~~~i~~~~~----

,XyZr~'~~)~l~ \;)"~.5·;6~t),· ;(/~:~sjl,,4~i2tF~/ltF~~~:.~.-·.-·.-·.-:---!r-,-.-4-.-._~_._._._f_n_~_m_:_._""_:_._,_'_~_g_fi_:_.~_._._._C_._~_._._'_._._'_._'_,:,.

\)<~~~C()ntrc>IJ-------~ ! 'l _

"\ \ I

rD~~± 3 \,--------------~------:~~!~~:~~~-----t---------,-~}.-r6.1~R~~ibi~',

L \: __ ' '-- •••••••••••••••••••••••••••••••••• ~ i. ~(",~:, - ~-_-_-_-_-_-_-_-_-_-_-}_~_~_~_~~-_-_-_-_-_-_-_-_-_-_-_: J---- r-----

\\ ----------~ 5.0-ttormaci6n i---------,--L, -/'-------)It ~:~~;;_i~~~_______j i

\, / -,._,:----------~-:~~--;2~~-~--~~-i---------~,' • ,1 --/ ,

\, /;'" - _ ------/ -: ~r3.1-dTran~":ncia ,---------------------------------------------, i "

::~- - \ // ,-----------~~~~~~~~-----------I &'c&'( -::, ,;~-----------~--~~----~-~~~--------~pi 3.3- MOOos de • ~----~:::::::::::::::~ Unidad C

',-\ <iO~F~~ci6~i -, -~~ i 3.2- Selecci6n l operaci6n :

- ~ '--------)<- de control r-----' '------~ de canal ,---------------------------------------------:

~ I l ;

Requisitos del Sistema

~ ~ ~ Nota.- ~ ~ .

~ ~ ~ F ~ ~ ~F~nt:illn~ ~ ~ ~ ~ ~ ~

~ __ I ~_~_~~~~L

Actividad operativa

Funciones operativas

Subfunciones

Empaquetado funcional

/

/. __ ··~.", •• cccc

: y ; ~ia·~\~ <.

/----------~1.0~I~furl1l~ci6~l~

• de rumba i -

~ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - __ I

~--------~-----2:o~~~~~~~d6-~-----I"

, J

~~I------1:1~Ai;~;-d~------------------------------------ ,

~ __ --_. __ -~_"-~-'--/ ~1·.rIJ~I>tl .... ~:f------1':3d~-eVaru-iimd~ba-d-6~-------,~ ··················).-----U----.-d----d---A-----1

- r":"! ~_I ~ __ --------!

-; <, ~ 1.2- Sef'iales i------~::::::::::::::::::::::::::::::::::::'---$

i de acimut

\ \

\ \

;

i----M~'--

~opemliw 1

, '

\----------~:~~!j:~~~l

~ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - __ I

Figura 22. - FLUJO OPERATIVO DEL SISTEMA X Y Z (ABREVIADO) -

DISENO PRELlMINAR

DISENO CONCEPTUAL

DISENO DETALLADO Y DESARROLLO

PRODUCCION »Y/O CONSTRUCCION~

NIVEL DEL SISTEMA

: 0.0>, 0.1

!AnAI,i~diil

i I8qUlSiIoe :: 0.2 f~===========x, 'I ~isis:

~1 funClllnal. 0 3

lCj~~~<

, de raqu~ : 0.4

~c-=~UD.5

~-·--{:::~~1~:::::~}.6

f~~~~f

CONFIGURACION FUNCIO~ J~ONFIGURACION ASIGNADA

~ CONFIGURACION DEL PRODUCTO

..&. Especificaci6n del Sistema tipo "Ao

..&. Plan de Gesti6n de Ingenierfa del Sistema ..&. Plan Maestro de Prueba y Evaluaci6n_

..&. Especificaciones de Requisitos Preliminares de Software

"m, Revisi6n del Diseno Conceptual (Revisi6n de los Requisitos del Sistema) "m, Plan de IntegraciOn de los Sistemas Humanos

..&..#. Revisiones del Diseno del Sistema

.#. RevisiOn de la Especificaci6n del Software EquipolSoftwarelRevisiones

A-A de Diseno de Factores Humanos

CICLO DE VIDA DEL HARDWARE .... __ ..... __ ..... __ ..... _ .... #.,._R.~i~.i9n.Cr:itl~.~ElI_Diseiio-

deadeO.25)---- dasde 1.1 j---, desde2.1 >----

Q,2;lL REF'>\-' L~_I_L *-- g;_I_L i__________________________________________ 2.2513

funJ~~_I __ "_A • I",I:-------.., p~il~~ar I", Diseno detall~do y dem6d~rrol"o (EqUipo,)unHjadeS, !J--~~=---!-----------------

del sistema i conjuntos, u os y partes i '( rotot' ) i , 2.8 .;.

~!HanJ..are:" '::::JP;:' I ~

_C,Ci(i[)E_yi[JA[JEl.SOF'[WARE-:I="~=:Y~l: 1~~'~~;1~~~~i~. --_I ~

desde02S> , dead. 1.1 (desde2.1'----, ~ 1 irl

II~~! '::t: .~·iJ~de:;~~'ir~:i~,.;~~:~!.i~~ I,~~;:I U U

!~~id.l~ i ':~: .. ~;~>d.~ m ~bo i~=j·1 ~ i

CICL(ftiE"'viDA-DEi':INTEGRAC-iotfTtiEi-siSTENiA-iiuMANO--------T---------------------T-I;rt;;~~~-iir~i~------------ ! r:!

I..)..! ----------------------------------------------------------------,,--------------------"¥---------------------------c.,y-----------------------v-----------------------------------~·-·i til

-Or! dasdeD25)---, desde1.1~---: desde2.1>----, ,: .....

~.25,l __ . REF _i_~ ~,~L--;----~-------~--: I~-----------------------j------------------------------------------:~,~-----------: ~ 1 ~

i Grupo: Dlseno i: D' - detail d d II i i Prueba de i : L--r---------J

: 1 I' . i 1 seno a 0 y esarro 0 i : 1lI}rsonai i' . ,

: funcional "C· r ----~~ pre I.mlnar :---*1 (Analisis, requisitos de personal, adiestramiento) ~ : \Maqijeta ~ ~

Elemento humano: ~ del sistema i : i • protdtlPO) i

'------------,,--------------" -------------,--------------_ .. _-----,--------------------"-----------------------------------------------_._--------"-------_ .

. ... --.--.-- .~ ..... - ..... - ..... -- ... -- ... __ 't. __ .... _ ..... _ ..... _~.__.__.__*_ ... _ ..... _ ..... __*_.__. __ .... _ ..... -~<>t- ..... __L_ ... __ .... _.Iic

RealimerrlaciOO y oontroI

Fuente: [4]

)~-- .. ,.--;

Figura 23. - EVOLUCION DE LOS REQUISITOS HARDWARE, SOFTWARE Y HUMANOS-

-----------------~>-

)~-- .. ,.--;

55


prestaciones tecnlcas), seleccionar las tecnlcas de evaluaci6n adecuadas, seleccionar 0 desarrollar el modele que facilite la evaluaci6n, obtener los datos necesarios de entrada, evaluar cada uno de los candidatos considerados, realizar un anallsls de sensibilidad e identificar areas potenciales de riesgo. Este proceso puede «ser adaptado» y aplicado en cualquier punta del cicio de vida mostrado en la Figura 7.

Con referencia a la Figura 26, un paso crltlco en la realizaci6n de un anal isis determinado es la selecci6n del modele 0 herramienta adecuada. EI modele seleccionado debe: (1) representar el mundo real tal y como aplique al problema que trata de resolverse; (2) representar los aspectos dlnarnlcos de la configuraci6n del sistema que se evalua; (3) ser completo por incluir todos los facto res relevantes; (4) ser fiable en terrnlnos de repetibilidad de resultados; (5) ser de estructura 10 suficientemente simple como para permitir su oportuna utilizaci6n en la resoluci6n de problemas; (6) ser disefiado de tal forma que el analista pueda evaluar la configuraci6n aplicable del sistema como

--------------------------------------------------------------+ ------------------------------------------------------------,

,UNIDAD A ~ ! UNIDAD B! 'UNIDAD C

.··MTBM·:~.~:.·.~:.:~:.~:.·.~~.:~:.~:··300·h~.·1 r·~M·.::~.~:.·.~:.::~.~:.·.~:.:~:.··500;;~:·1 !:' ·~Ts .. ·.·.M .. ·.· .. · ... ~.: ... :.:.~ ... ~.: .. · ... ~.: .. · ... ~.: ... ~.: .. · ... ~.: .... ·41· •. 10·0h;;rs·h.~]::

! I,L .. , .. ,., .. , , .. , .. , , .. ,.. 1.0 hr. ! ! M 3.0 hrs. ! !VI

! MMHIOH ,., .. , .... , •• , .. , .... , 0,25! i MMHIOH .. , , •• , .. ,., .. , •• , 0.15 i i MMH/OH , •• , .. , .... , •• , .. ,., .. 0,10 i

i Nivel Cualificaci6n ., .. , •• , GS-7 i ! Nivel cualificaci6n .,., .. ,. 00·7 ! ! Nivel CUalificaci6n •• , .. ,., GS·7 !

i CosbI $17.000 : l.~ .. :::,:::·::·:::·:::·:::·::·: .. ~~~·~.J l.~.:·::·:::·:::·::·:::·:::·:::· .. ~:~.~ j

I

MODULO 3

'i:: .. ~~: .. ~~:: .. ~~: .. ~~:: .. ~:: .. ~·():OO;,"

! Met , .. , .... , •• , .. , , •• , .. , ...... 5.0 hrs.

i MMHIOH .. , , •• , .. ,......... 0.07

i Nivel Cualificaci6n ., .... , •• GS-9

,------------------------------------------~

MODULO 1

,------------------------------------- 1

! A o.Oooa/hr.!

! Met .. , •• , .. ,., .. , •• , .. ,., .. ,....... 4.5 hrs, '

! MMHlOH ., •• , .. ,., .. , •• ,....... 0.03

: Nivel CUalilicacl6n , •• , .. ,., OO~

SISTEMA 'X Y Z'

PreslBciones:

A 0.90

MTEM 170 hrs.

MDT 16 hrs.

MMHlOH 0.5

Nivel CUalificaci6n GS-5

Costa $50,000

MODULO 2

'i: .. ~~::.~~:: .. ~~: .. ~~:: .. ~:: .. ~~·():OO21n;;,"

! Met ., .. , .... , •• , .. , , •• , .. , , 2,5 hrs.

i MMH/OH , .. , , •• , .. , , •• , 0,15

i Nivel CUalificacl6n .. , ,. GS-9

,------------------------------------------~

Figura 24. - ASIGNACION DE OBJETIVOS DEL SISTEMA XYZ -

56


SubsistBma

- Especilicaci6n de producto del elemento de inventario., 'C4'

- Especilicaci6n del procaso tipo '0' (Elemento crftico)

ElernenID de conflguracl6n

Espec1ftcac16n de desarTlllo - Especlllcad6n de

de IllTlilmento Hpo 'B1'

- Especlllcad6n de faI*lres hllTlall ....

- Programa infumllitico PIl1l 81 conIrDl

de IllTlilmento tipo 'B5'

- Especilicaci6n del procesador de sanal tipo '01'

Buque

-1 - Tamaila XXXX

i - Valcddad XXXX

i - Disponlbilidad XXXX

J _ Cosbo del CIcIo de VIda XXXX

'--------,---

:---i-----------------~_:__:__:__:__:__:__:__t_:_~~

'-------.-------j Sistema de i - llempo de reacciOn XXXX

cormate i - Capacidad de supervivencia XXXX

________________ . -,-__ J - Disponibilidad XXXX

'--.--------------------------j--" - PJacisi6n XXXX

r---------------1: : - Tamafio XXXX

! Pe f50 naI ! ! =: ! : ~~::=On XXXX

- . ----T-----' - CosI9 de adquisici6n XXXX

>-T-------------------~~~~~~t_-~ iPiO!ir&:inriirli.i1 - 1lIempo de proceao XXXX

, nIJ1lI' : Procesador i - MTBF Procesador XXXX

!~~r : ~~_~_~~ i : ~:~del software XXXX

____ :~J_~~~~~~~----------.~~~~~~~~L;, - 1lIempo de fabllcacl6n XXXX

: Elemento : : ~Jg i - Realnftguabilidad XXXX

est6ndar' j (il8ri)i~ i - Cosbo de mateJlal XXXX

i de inventario i : Qltico) i - Tasa de faIos XXX)(

---------------~ ---------------- - Cos1E de garantla XXXX

Figura 25.

- NIVELES DE INDENTACION DEL SISTEMA, ESPECIFICACIONES Y RELACIONES TPM -

una entidad, analizar diferentes componente del sistema de forma individual, y luego integrar los resultados en el conjunto; y (7) ser diseriado para incorporar provisiones de modificaci6n y/o crecimiento para permitir la evaluaci6n de factores adicionales cuando sea necesario. Un objetivo importante es seleccionar y/o desarrollar una herramienta que facilite la evaluaci6n de la configuraci6n global del sistema, asl como de las interrelaciones de sus distintos componentes.

Segun un reciente estudio, hay mas de 350 modelos lnforrnatlcos disponibles en el mercado, que desarrollan diferentes funciones [4]. Gada uno de los modelos identificados fue desarrollado de forma «lndependlente» 0 «alslada» en terrnlnos de plataformas seleccionadas, lenguajes lnforrnatlcos 0 contextos, requisitos de datos de entrada, grados de «facllldad de rnanejo», etc. En general, los modelos identificados no «se hablan entre sf», son complejos y requieren demasiados datos de entrada, son de diffcil manejo y s610 pueden ser utilizados en las ultlrnas fases del proceso de

~ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - i

Diseno Conceptual, Desarrollo, Prueba, Produccion/Construccion, Utilizacion, Mantenimiento

~-----------------------------------------------------------------1-----------------------------------------------------------------r----------------------------------------------------------------f---------------------------------------------------------------- ~------------------------------------------------------------~

___~:~~~~~;~~;;~i~~~L~~lrti;:I~:c~~n~~;~i~~,~~~~~~~!~;~~;~i~:~~l~~~~;;u~~;~;~a,~~~~~~~~;~i~~~~;ti~ __ < _

2

3

4

--------------E~~q~~-d~i-A~-~ii~-i;------------1 Criterios de Evaluacion ·----------T~~~-i-~~-d-~--E~~I~~d6~---------

c---:--~~~~I-~~-~;-~~~;~~~;--------------------------I ~ ,~~fi~i;~i~~~~f~~~~~~~~~~- " Seleccionar las ~cnicas apropiadas •

, Definir objetivos del anal isis, ! ~, Definir variables ~ ~ (simulaci6n, programaci6n lineal! ~

~ reglas b8sicas, limitaciones l ~ ~, Identilicar necesidades de datos ~ ~~ dinamica, teoria de colas, probabilidad, ,

, Identificar altemativas viables ! ~ (datos existentes, nuevos datos,' ~ contabilidad, redes, secuenciado, otras) ~ .

, Definir el enfoque a la resoluci6n! ~ relaciones de estimaci6n, fuentes, etc.) ~ , Definir los requisitos de la modelizaci6n ~

del problema ! ~, Identilicar riesgo e incertidumbre . (aplicaci6n tecnica) .

l 1 : :

1, ~

Requlsltos

/

81 ./ . i.Existe

!~odel~>/

,

Gestion

Decisiones

8

7

6

,--------------------------------------------------------------------,

· .

r-------------------T~~-~-d~--D~t;;~------------------

L _

~ , Utilizar bases de datos (existentes)

«S(---------~ , Obtener asignaciones de fiabilidad y

~ mantenibilidad; predicciones; analisis 5

~ de datos de mantenimiento; etc, "

i ' Obtener relaciones de estimaci6n de ;- -- _, coii~t~u'ir .- _, i

~ costes i~--<i modelo nuevo'

l ,(}btene~datos~~~rIJ~~~! '_ - - - _ - - - - _ - -'

• Analisis de Resultados

i

, Recomendaciones

~, . :~ 'Niveles de Confianza

i 'Soluciones de Compromiso , Puntos de ruptura

, Sensibilidad (riesgo e incertidumbre)

•

i

Evaluaci6n de Alternativas

· .

'---------------------------------------------------------------------,

· .

~ , Ejecutar el modelo (adaptado a las -<8(-------------j necesidades particulares)

~ , Realizar un analisis de sensibilidad (posible impacto en 105 resultados de variaciones de las entradas)

· .

· .

· .

· .

· .

· .

· .

· .

· .

· .

'---------------------------------------------------------------------'

Acci6n adecuada

•

•

Figura 26. - EL PROCESO DE ANALISIS DEL SISTEMA -

NO

57


obtenci6n (es decir, en los ultlrnos momentos del dlsefio detallado y desarrollo). Esto no es inesperado, ya que los modelos fueron desarrollados principalmente por contratistas en respuesta a necesidades percibidas. AI mismo tiempo, muchos dlsefiadores y responsables de proyectos buscaban herramientas que pudiesen resolver de forma autornatlca algunos problemas detallados (contra seleccionar una herramienta que pueda ser utilizada en muchas situaciones diferentes). EI enfoque abajo-arriba ha side predominante en la selecci6n de herramientas de dlsefio.

Desde una perspectiva de ingenierfa de sistemas, un buen objetivo es seleccionar y/o desarrollar una estaci6n de trabajo integrada de disefio, que pueda ser utilizada en todas las fases de la obtenci6n del sistema y que pueda ser adaptada para considerar los diferentes niveles de definici6n del dlsefio a me did a que se progrese desde la fase de definici6n de requisitos a traves del disefio detallado y desarrollo detallado (ver Figura 7). Adernas, debe existir una capacidad por la cual las herramientas utilizadas en un programa determinado para resolver diferentes problemas se «hablen entre sf», y puedan conectarse adecuadamente a la estaci6n de trabajo centralizada de dlsefio. La Figura 27 transmite un enfoque que muestra la integraci6n de un conjunto seleccionado de modelos lnforrnatlcos. Con tal esquema integrado, el ingeniero de sistemas sera capaz de realizar mas anallsls frontales, investigar pronto muchas mas alternativas posibles de dlsefio, y desarrollar la configuraci6n preferida en un perfodo de tiempo mucho mas corto al tiempo que se reducen los riesgos «aquas abajo». Finalmente, la selecci6n de las herramientas 0 modelos lnforrnatlcos adecuados debe ser el resultado del anal is is funcional y la identificaci6n de las «mejores practlcas», como se ilustra en la Figura 21 .

EI anallsls conduce a la sfntesis. La sfntesis es la combinaci6n y estructuraci6n de los componentes de tal forma que representen una configuraci6n viable del sistema. Han side establecidos los requisitos baslcos del sistema, se han realizado algunos estudios de soluciones de compromiso, y se ha desarrollado una configuraci6n de re-

58


i-~~~~~i~~~1 ~------------------~ i-C;;~~~~i~~~~~~~~] t

, ModelD de i Modele de

1 Requisill!s del SistelllB 1 ------------------------~ AnAlisis del Sistema

.--------------------~ r ------M~b-d~-------~

I AnAIIsis de Flabilidad •

I ~------------------------i

---------------------~1P_---

M;,;j~I~d~I~la";6,,l------------- iMDdBklde : i----I.bj~I~-~-A;;~I~---l

,--~ l d~u:~i=:B l~----------------------- 1 ~~=~~=::- i~-------------------- I del Nlvel de Reparaclon.

A:::::::::::::~------------------------------~:::::::::::::::::::::::::::::::-----------------------------~:::::::::::::::r

Figura 27. - LA APLICACION DE MODELOS INFORMATICOS -

ferencia para demostrar los conceptos anteriormente presentados.

La sfntesis es disefio. Inicialmente, la sfntesis se utiliza en el desarrollo de conceptos preliminares y para establecer las relaciones baslcas entre los distintos componentes del sistema. Mas tarde, cuando se dispone de la suficiente definici6n y descomposici6n funcional, la sfntesis se utiliza para definir aun mas los «COMO», en respuesta a los «QUE» del anallsis funcional. La sfntesis incluye la selecci6n de una configuraci6n que pueda ser representativa de la forma que finalmente adoptara el sistema, aunque ciertamente no debe asumirse una configuraci6n final en este momento.

Dada una configuraci6n resultante de la sfntesis, deben evaluarse las caracterfsticas de esta configuraci6n en termlnos de los requisitos especificados inicialmente. Se inician los cambios requeri-

59


dos, que conduzcan a la configuraci6n de dlsefio preferida. Refiriendonos a la Figura 7, este proceso iterativo de anallsls, sfntesis, evaluaci6n, y optimizaci6n del disefio conduce inicialmente al establecimiento de la configuraci6n funcional (Hito I), despues a la configuraci6n asignada (Hito II), y finalmente a la configuraci6n del producto (Hitos III y IV).

204, !nlegmci6n de! dlsefio

Con relaci6n a la definici6n de ingenierfa de sistemas (Secci6n 1.2.), uno de los objetivos clave es la necesaria integraci6n y concurrencia diaria de las distintas actividades del dlsefio tanto a 10 largo como despues del proceso de obtenci6n del sistema. Como se muestra en la Figura 4, puede haber muchas disciplinas diferentes de diseno (representando las diversas areas de especialidad) requeridas para un programa determinado. Estas areas de actividad deben ser adecuadamente integradas en el proceso de disefio y desarrollo, trabajando «en equipo», de forma efectiva y oportuna.

La Figura 28 (una extensi6n de la Figura 23) muestra la evoluci6n del disefio, junto con los criterios seleccionados de disefio que sean aplicables, en grado variable, en cada nivel de la estructura jerarquica del sistema. Adernas, hay muchas actividades y tareas diferentes que son realizadas para asegurar que se alcanzan todos los objetivos del programa, y que la configuraci6n final del sistema satisface al usuario, eficaz y eficientemente. Hay ciertas areas de afinidad inherentes a los requisitos para desarrollar las tareas identificadas en la figura. Por ejemplo, el analisls funcional constituye la base para requisitos de fiabilidad, mantenibilidad, factores humanos, logfstica y otros; el analisls de modos de fallos, sus efectos y criticidad se requiere en la realizaci6n de los anal isis de fiabilidad, mantenibilidad y apoyo logfstico; se necesita un anallsls detallado de tareas para los requisitos del programa de mantenibilidad, facto res humanos y logfstica; los anal isis de coste del cicio de vida son inherentes al desarrollo de anallsis de requisitos del sistema, viabilidad, fiabilidad, mantenibilidad, apoyo logfstico; etc.

60


Desde el punta de vista de la ingenierfa de sistemas, es esencial que los adecuados elementos orqanicos que participan en un programa determinado esten fntimamente integrados, promoviendo las necesarias comunicaciones que deben existir diariamente. Esto puede ser parcialmente realizado por medio de la co-disposici6n del personal del proyecto. Si los miembros de los equipos de proyecto no estan situados en la misma zona, es necesario establecer los adecuados enlaces de comunicaciones mediante la utilizaci6n de redes de area local, rnetodos de disefio asistidos por ordenador y otros analoqos. La Figura 29 presenta la situaci6n en la que disciplinas individuales de disefio estan enlazadas para promover las comunicaciones diarias que apoyan los distintos tipos de actividades de disefio. Es mas, deben integrarse adecuadamente los diferentes informes, anallsls, datos del disefio e informaci6n relacionada mediante un enfoque de base de datos compartida, como se ilustra en la Figura 30. Para lograr este objetivo, los modelos/herramientas necesarios deben estar disponibles a los diversos miembros del equipo de disefio (como se expuso en la Secci6n 2.3.). Por ultimo, debe establecerse el adecuado entorno orqanico que facilite la consecuci6n de esta necesaria integraci6n. La organizaci6n para la realizaci6n y direcci6n de ingenierfa de sistemas se desarrolla en el Capftulo 3.

2,5, Rev!s!6n~ evaluaclon y reallmenteeicn del dlseno

Parte integral del proceso de obtenci6n, ilustrado en la Figura 7, es la actividad peri6dica de revisi6n y evaluaci6n que ocurre informalmente de forma diaria, y mas formalmente en instantes concretos del cicio global de disefio y desarrollo. En relaci6n con esto ultimo, las revisiones formales de disefio suelen Ilevarse a efecto despues de la finalizaci6n del disefio conceptual, las revisiones del disefio del sistema pueden realizarse durante el disefio preliminar, las revisiones de los equipos/software pueden realizarse durante el disefio preliminar y detallado, y las revisiones crfticas de disefio puedan

rO.1/O.2~-iiEFL. !.wlisis·derequisitos!

l __ ~~~;M~;;t __ ! -- ccccccccc~~.~1~'~;.~~R)i~.~~~Tc7.lY~,.I:~.!2.~~:c~~:c~l~:~,~J

r:~~~~~.A.~':~ru~~~,.,.;~~:~+do~~! ~ · D:=( .. _, .. ~_ MoJ.

~ ~~_~~_~ I l Softwa~i~----~l~~:~~ __ ~_~_~~~_~_, ~ . Efectivklad sistema-coste.

, . Fiabilklad.

W + w

[~u~}{~~;;~ "'i:~:;~~;

w , i ; r-------------~-------------, ~ ~ . Seguridad.

IEiiu:::::~ot ., ~::=~~e Lm*1 Ta~~~:reas ! ~ . Capacidad de supervWenda.

i Configuraci6n ~ l ~~~~ l '

~.;,;,;,;,;,;,;,;,;,;,;,;,;,;,;,_~;,;,;,;,;,;,;,;,;,;,_~;,;,;,;,;,;,;,;,;,;,_..;.;;. cT' 1 -------------~-- ~ . Vulnerabilidad.

;,IE=~:{-~~)rel~---+;,IE~~-~~reL iR;;q~i~b;d~-p~~8j1 ~ . Soportabilidad.

i de unidades, CIlIIjlllkl, ~ i Desarrollo i*l ~~~~~~bcl6n I ~ . Manufaclurabilidad.

lrn6dlJos,~m_ponelllesj l_ ~_~L§~~-~------~~el~nal' ~ . Reconflgurabilklad.

i------jlitBQ;a~-de------~ 1-------,~~~i6~------1 r------[kSi!II~-y------ ~ . Viabilklad econ6mica (coste del cicio de vida)

i componentes ~"l~i de elementos f>1l --->-I entrenamiento del ~

I~e~;;~uipo_sl 1------~~-~r-~------jlJE!~~nalj ~ ~ . Desechabilidad (relirada/reciclaje).

+ ti ' . Viabilidad ambiental.

I~~(=~ ~u~~~~-----~r~:~~:-~~;-::~t----~ d:~e=al I ~ . Apllcable a rodos los niveles de ~

l~~ l~ i (maquetaslprototipos) ~ estructura jerarqulca del sistema y adaplado a las necesklades especfficas del programa.

~ . Mantenibilidad.

~ . Fadores humanos.

i ~-------------- J

'"

2.3 REF--

Evaluaci6n Aclividades diarias de ~

! (inte~~~~nia)eba~.J! ---*, Integrad6n del dise~o ~~ ,-------------------------------------------------------------------

Figura 28. - LA APLICACION DE REQUISITOS DE DISEt\JO A LA JERARQUIA DEL SISTEMA-

DISENO REALIZADO MEDIANTE:

· AnAl isis de requisites.

· Despliegue se la funcien de calidad (QFD)'1

· Analisis de viabilidad.

· Requisites operatives y concepto de manlenimiento.

· AnAl isis funcional.

· Esludios de soluciones de compromise de ~ dise~o.

· Simulaci6n y modelizad6n.

· Asignaci6n de requisites.

· AnAl isis y predicciones de fiabilidad y mantenibilidad.

· Analisis de faclores humanos.

· Analisis de apoyo Iogislico.

· AnAl isis de seguridadiriBsgo.

· AnAl isis de vulnerabilidad y capacidad de supervWencia.

· Prueba y evaluaci6n.

61


realizarse despues de que el disefio este esencialmente «conqelado» y antes de entrar en la fase de producci6n/construcci6n. Aunque el tipo y nurnero de revisiones formales de disefio dependerim de los requisitos especfficos de cad a programa, la linea de referencia presentada en la Figura 31 servlra como punta de partida para posteriores discusiones.

En relaci6n con la actividad diaria informal de revisi6n y evaluaci6n de disefio mostrada en la figura, esta incluye el desarrollo inicial de los criterios de disefio, la funci6n diaria de participaci6n y evaluaci6n del disefio, la revisi6n y aprobaci6n de documentaci6n de dlsefio (dibujos y pianos, ilustraciones, listas de material y de repuestos, croquis, informes, etc.) y la elaboraci6n y procesado de recomendaciones de acciones correctivas y/o de mejoras del producto.

EDiFICIO "A"

EDIFICID "0"

.1- -i

,-- f:~--' MECANICO ESTRUCTURAL

\. '

MANTENIBILIDAD

-. ~ MATER~~S' !,"

.,.".".---~j--~----.,.".".

FIABILIDAD

FP.cTORES HUMO.NOS !

i_~!!'I~!Q_~_"_i .... i.

~--~

'_'

i .' i I

!

'i' SISTEMAS, .,» •• ,_ :

!~~~~$;~~i ~ .. ~ --

.;

':;;'_" _ ~_ ! QUIMICA

ELECTRICO

COMPONENTES

t EDIFICID "10"

-. ~~/

CALI DAD

FABRICACION

PROCESOS

Figura 29. - RED DE COMUNICACIONES DE DISENO -

62


BASE DE DATOS INTEGRADA (CASE, CAD, CAM, CIM, CALS)

SEGURIDAD

VlABILIDAD AMBIENTAL

i··~;~;~~~~~;~,;;'·····~

i SOCIAL YTECNOLOGICA " ..

~-----------------------------------:

r~I~II):'E~~~Ic.\T

L : ",

EFECTIVIDADISISTEMA COSTE

PRESTACIONES "

i i

FIABILIDAD

RECONFIGURABIUDAD

MANTENIBILIDAD

CAPACIDAD DE SUPERVIVENCIA

FACTORES HUMANOS

WLNERABILIDAD

·-----------------------------------1

", MANUFACTURABILIDAD i

---------------------------------!

'·······~~~~~::,~,~~······1

: J

SOPORTABILIDAD

< OTRAS CARACTERlSTICAS I

: _i

Figura 30. - INTEGRACION DE DATOS DEL PROGRAMA -

Dado que esta continua actividad abarca diferentes disciplinas, es pertinente que sean identificados (y acordados) desde el principio para que sirvan como «qula para el dlsefio», los criterios para este, las normas sobre equipos y materiales, y los procedimientos relacionados. Subsiguientemente, deben desarrollarse listas de comprobaci6n para facilitar la revisi6n y evaluaci6n de datos/documentaci6n de disefio en terrnlnos de los requisitos globales de especificaci6n del sistema y sus diversos elementos. Un ejemplo de una lista de comprobaci6n se muestra en la Figura 32.

La Figura 33 muestra el desarrollo de una de las actividades sefialadas en la lista de comprobaci6n. La utilizaci6n de listas de comprobaci6n, que deberan «ser adaptadas» al programa y a las caracterlstlcas particulares del sistema en desarrollo, puede ser extremadamente beneficiosa en el proceso global de evaluaci6n.

Refiriendonos a la Figura 31, las revisiones formales de disefio se programan en instantes concretos del proceso de obtenci6n a me-

:~~IF!c~~~:~iI~:~~NI:S~~~~N]

ii'

": ~l~i:~f~

------------------------------------------------------ J l -------------i

Analisis funcional, asignaci6n de requisites, sinlesis, soluciones de compromiso, diseno preliminar, prueba y evaluaci6n de conceplos de disano, planificaci6n detallada

_________________ ~ J _

Diseno detallado de subsistemas y componentes, soluciones de compromise, desarrollo de prototipos, prueba yevaluaci6n, planificaci6n de producci6n

'.~§~iil

!:~~~~~~~t

-----------------------------------------------~------------------------------------------------------- ----------------------------------------------------------------~--------------------------------------------------------------------------~----------------------------------------------------------------------------------~

Proceso de revisi~n y evaluacion de los requisitos del sistema i

! : i

--------------------------------------EVal-uaCl6-n-y-rev:ls16n-lnfOrmafitlaria-iiefitlsefto-------------------------------------1 i

l~i~~~~:~:~:~~{;:~i~~:,:~:~ftqo del.~m.)

~. Revisiones de disefto del Sis~ma

• ~----------------------~ R~isiones de disefto de equipos y softwa'!'

,~~lt"i~i~~~I'iti~~~~~i~e~~"

Figura 31. - EVALUACION Y REVISION DE DISENO -

63


dida que la definici6n del dlsefio evoluciona de una configuraci6n funcional, a una configuraci6n asignada y a una configuraci6n del producto. EI objetivo es: (1) proporcionar una comprobaci6n met6dica del disefio del producto/sistema con respecto a los requisitos contractuales y de especificaciones; (2) proporcionar una referencia cornun a todo el personal del proyecto; (3) proporcionar un medio para resolver los principales problemas de interface; (4) proporcionar un registro met6dico y sistematico de las decisiones de disefio adoptadas y los motivos por los que se han tomado; y (5) promover un disefio mas maduro mediante «sntradas de grupo». En el proceso se incluye la revisi6n de las medidas de prestaciones tecnlcas y de c6mo progresa el dlsefio en terrnlnos de cumplir con los requisitos. La Figura 34 ilustra el enfoque de medida y evaluaci6n.

Puede haber cualquier nurnero de revisiones de dlsefio programadas de acuerdo con la complejidad del sistema y el grado de madurez del disefio alcanzado en un momento determinado. Aunque el objetivo es integrar, coordinar, comunicar, y aprobar de forma apropiada el disefio a medida que avanza la actividad de desarrollo, la revisi6n formal de dlsefio sirve, en ocasiones, de vehfculo de integraci6n y adecuada comunicaci6n. La actividad de revisi6n y evaluaci6n del disene puede ser enormemente beneficiosa, si se realiza de manera profesional. Sin embargo, una determinada revisi6n debe ser identificada con la adecuada documentaci6n de apoyo, el panel de revisi6n de dlsefio debe incluir las personas adecuadas que sean responsables y puedan tomar decisiones sobre la marcha si fuesen necesarias, y las acciones correctivas necesarias deben iniciarse inmediatamente despuss de las revisiones (0 sea, la adecuada actividad de seguimiento). Desde la perspectiva de la ingenierfa de sistemas, es esencial la realizaci6n de las revisiones formales de diseno.

64


COMPROBACIONES DE REVISION DEL DISENO DEL SISTEMA

REQUISITOS GENERAlES

l Han sido los requisites tecnlcos y del programa para el sistema adecuadamente de1inidos a !raves de:

1. Anallsls de vlabllldad.

2. Requisitos operatives.

3. Conceplo de manlenimienlo.

4. Faclores de efeclividad.

5. Analisis y asignaci6n funcional.

6. Especificaci6n del sistema.

7. Requisitos de suministradores.

8. Plan de gesti6n de ingenierla del sistema?

CARACTERISTICAS DEL DISENO lRefleja adecuadamente el diseno conslderaciones de:

1. Accesibilidad.

2. Ajustes y alineaciones.

3. Cables y conectores.

4. CalibraciOn.

5. Requisites de datos.

6. Desechabilidad.

7. Requisites ecol6gicos.

8. Viabilidad econ6mica.

9. Requisites ambientales.

10. Requisites de Instalaclones.

11. Abrazaderas.

12. Manejo.

13. Factores humanos,

14. Intercambiabilidad.

15. Mantenibilidad.

16. Movilidad

17. Operatividad.

18. Embalaje y montaje.

19. Controles y seiiales de los paneles

20. Personal y entrenamienlo.

21. Manufacturabilidad.

22. ReconflQurabilidad.

23. Fiabilidad.

24. Seguridad.

25. Selecci6n de partes/materiales.

26. Entretenimienlo y lubricaciOn.

27. Requisites sociales.

28. Software.

29. Estandarizaci6n. 3~. Almacenaje.

31. Soportabilidad.

32. Requisites de equipo de apoyo.

33. Capacidad de supervivencia.

34. Capacidad de prueba.

35. Transportabilidad.

36. Calidad?

Cuanclo se revise el diseiio (disposici6n, pianos, listas de piezas, informes) estas comprobaciones pueden ser beneficiosas al cubrir

los principales requisitos del programa y

L.IJ~'i~atfl~M~<i"'tmf1~I.

Figura 32. - EJEMPLO DE COMPROBACIONES DE REVISION DEL DISENO -

65


2.6. Prueba y evaluacion del sistema

Paralelamente al establecimiento de los requisitos iniciales del sistema en la fase del disefio conceptual (Secci6n 2.1.), debe implantarse un rnetodo de medida y evaluaci6n para asegurar la consecuci6n final de los requisitos especificados. Las medidas de prestaciones tecnicas son identificadas y priorizadas y, al mismo tiempo, debe especificarse c6mo sera evaluado el sistema en terrninos de cumplimiento de esos requisitos de medidas de prestaciones tscnlcas.

Guando se considera el tema de la evaluaci6n, el objetivo es conseguir un alto grado de confianza, 10 antes posible en el cicio de vida, de que el sistema tunclonara de la forma deseada. Esperar a que el sistema haya alcanzado su plena capacidad operativa conducira a una prueba de su verdadera capacidad. Sin embargo, si hay problemas y el sistema no cumple con los requisitos especificados, la incorporaci6n de los necesarios cambios por acci6n correct iva puede resultar muy costosa. Por otro lado, si se detectan problemas potenciales en los primeros momentos del cicio de vida, cualquier cambio necesario puede incorporarse con un coste mfnimo.

La Figura 35 identifica las eta pas de evaluaci6n del sistema. La primera categorfa es "analftica", que se refiere a ciertas evaluaciones de disefio que pueden ser realizadas en las primeras fases de cicio de vida del sistema utilizando rnetodos informatizados entre los que estan GAD, GAM, GALS, simulaci6n y otros analoqos.

"Pruebas tipo 1" se refiere a la evaluaci6n de los componentes del sistema en el entorno del laboratorio utilizando modelos, bancos de prueba, etc. Estas pruebas estan disefiadas principalmente con el prop6sito de verificar ciertas caracterfsticas ffsicas y de prestaciones y son de desarrollo por naturaleza. EI "prototipado rapldo" se emplea en ocasiones con este prop6sito. Las "Pruebas tipo 2" incluyen pruebas y demostraciones formales realizadas durante las ultlrnas eta pas de la fase de disefio detallado y desarrollo,

66


18. EMBALAJE Y MONTAJE

A} l.Es el disefio del embalaje atractivo para el consumidor (ej., color, fonna, tamafio)?

B} "Se ha incorporado el empaquetado fundonal al mayor nivel posible? Los efectos de las Interacciones entre los paCluetes funcionales deben minimizarse, y debe ser posible limitar el mantenimiento al desmontaje de un mOdulo (el que contenga la parte averiada) cuando se produzca un fallo, y no requerir el desmontaje de dos, fres 0 cuatro mOdulos para resolver el problema.

C) l.Son fisica, fundonal y elecbicamente intercambiables los m6dulos 0 componentes del equipo que realizan operaciones similares?

D) j,Es el diseiio de empaquetado compaHble con las decisiones del analisis del nivel de reparaci6n?

Los elementos re~rables se diseiian incluyendo provisiones de mantenimiento tales como puntos de prueba, acceslbilidad, y componentes conectaljles. Los elementos clasificados como "desechar en caso de fallo· deben encapsularse y las provisiones de mantenimiento no son requeridas.

E) l.Se han incorporado m6dulos desechables al maximo nivel practico? Es altamente deseable reducir el apoyo global al producto a !raves de un concepto de disefio de ·no mantenimiento· siempre que los elementos involucrados sean de alta fiabilidad y coste relativamente bajo.

F} i,Se emplean m6dulos y com!;lonentes conectables aI maximo nivel posible (a menos que su uso degrade significativamente Ia fiabilidad del equipo)?

G} l.Son los accesos entre mOdulos adecuados para penniHr los agarres con las manos (referirse al [ibro de Referenda de Disefio ·X· para provisiones recomendadas de accesibilidad)?

H) l.Estan los mOdulos y componentes montados de fonna tal que el desmontaJe de un unico elemento para su mantenimiento no requiera el desmontaJe de otros? La apilaci6n de componentes debe evitarse siempre que sea posible.

I}

En areas donde la apilaci6n de componentes sea necesaria por limitadones de espacio, l.se han montado los m6dulos de fonna tal que prioridades de acceso hayan sido asignadas segun las frecuencias predichas de desmontaje y reemplazo? los elementos que requieren rnantenlmiento frecuente deben ser mas accesibles.

J} "Est/jn los m6dulos 0 componentes no conectables mantados con cuatro abrazaderas 0 menos?

Los mOdulos deben estar mantados de fonna segura, pero el numero de abrazaderas debe reducirse al minima.

K) i..Se han incorporado provisiones de montaje anti-choque cuando los requisitos de cheques y vlbraciones sean exceslVOS?

L) l.Se han incorporado provisiones para prevenir la instalaci6n de m6dulos err6neos?

M) l.Se pueden desmontar los componentes y rn6dulos conectables sin el empleo de herramientas? Si se requieren herramientas, deben ser est/jndar.

N} l.Se han facilitado guias (correderas 0 pemos) para facilitar la instalaci6n de los mOdulos? O} l.Est/jn los componentes y m6dulos debidamente etiquetados?

Figura 33. - RELACION PARCIAL DE PREGUNTAS DE REVISION DE DISENO -

67


,- ...............• EiliiiA r ··················HiroS·DErPROGRAMJJ"··················· ,

! •.•.•.•.•.•.•.•.•.•. ~a~ ••••••••••••••••••• I .•••••••••••• cE ••••••••••••••••• E: •••••••••••• ~~.~~ ••••••••••••••••• _ .

;._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._,._._._._._._._._._._._._.-·_·-r·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·:·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·-r·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·_·-l-._._._._._._._._._._._._._._._._._._._._._._._._._._._i

Dlsponllldad 100% !~ ~ ~\. ·'·l' " ~ ~ ~

: 9D% I~ --;- :.... ;- ~ ..".,~ ~ ~ ~ ~ ""

1 ; 1 " + --1 , l

Costa del Cicio de VIda $55OK I' ~,,~ 1 1 :

$5OOKi i I"'_ i i •

$45OK I I : eeee 1r..."OoiN I ,

$4O:lK I~ :l ll { ~ ~ ~ )..""«<o. ~ ~~

$35OK ! ~ ·t ~

MM~m----------------mfl--------ml,m.m,m,--~m=m=m[m----------------mL •

· 15 ! : ~ I ~ ~ ~ ~ ";;:;;:;;:;;:; ~:

~----------------------------------~~---~~':.':.':.':.':.':.':.':.':.':.':.':.':.~':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.1~':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.T-':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.1~':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.':.i

MTBF 500 ~ I ~ ~ ~

: 400 l { ~ { ~ -..:..,_~ ~ ~ ~ ~i

: 300 ! i ~ ~ N1N1i !~ : :

~JIT'··II+

• 2.5OO! .-""""",,": 1 1 : :

• 2.0oo~·. 1 . i i •

: 1.500 ! ~ ~ ~ 'l~ ~ ~ ~ '"11'11'11'1110 ~ ~~

: 1.000 ! ";........................................................................................................ .~ 'l ~ ~

'- J .!_____________________ _ J ~ ,

Figura 34. - REVISION DE MEDIDAS TECNICAS DE PRESTACIONES DEL SISTEMA -

cuando estan disponibles prototipos pre-producci6n de equipos y software. Los prototipos de equipos y software son similares en forma y funci6n (con partes de componentes operatives incorporados) a los elementos de producci6n, excepto que no han side totalmente aprobados en ese determinado instante. Las "Pruebas tipo 3" incluyen la terminaci6n de las pruebas formales en emplazamientos designados, realizadas por el "usuario" durante un cierto perfodo de tiempo. Estas pruebas se realizan normal mente despues de la validaci6n inicial del sistema y antes de completar la fase producci6n/construcci6n. EI objetivo es realizar una evaluaci6n tecnica completa del sistema. Las "Pruebas tipo 4", realizadas durante la fase de utilizaci6n y apoyo del sistema, incluyen pruebas formales realizadas en ocasiones con el prop6sito de obtener informaci6n especffica relativa a alqun aspecto de la utilizaci6n 0 el apoyo. EI objetivo es obtener mayor conocimiento de la utilizaci6n del sistema en el entorno del usuario, 0 de las operaciones del usuario en campo.

68


lI!::!:~I]]IIIII~:i&II]I~~IIIII5IIII

evaluados en Instalaclanes

~ i:,' designadas de prueba

~ Evaluaci6n de madelas

il5 , de praduccion y proIotipas

iilc ': (muBSbvo de producciOn)

Evaluacl6n de madelas ,

i!i ~ de prueba e Ingenlerfa,

t:S : companentes del sistema

:§ ~ Y maquetas

:;;!, iri, Evaluacitln empleanda

:5' esIaciones de InIbaja ~ ~ y modlelas analilicos ~ i (CAD, CAE, CAM, CALS)

~!

u:

I:l!'

w

ANALiTICO

PRUEBAS TIP02

PRUEBAS TIP04

CICLO DE VIDA DEL SISTEMA-------~

Figura 35. - ETAPAS DE LA EVALUACION DEL SISTEMA EN EL CICLO DE VIDA -

Con relaci6n a la figura, un objetivo de la ingenierfa de sistemas es causar la integraci6n de estos requisitos de prueba de manera rentable. La verificaci6n de algunos componentes puede realizarse por medios analfticos; otros requisitos pueden cumplirse mediante Pruebas tipo 1, Y asl sucesivamente. En el plan maestro de prueba y evaluaci6n desarrollado durante la fase de disefio conceptual debe desarrollarse e incluirse un enfoque integrado total.

La recomendaci6n e iniciaci6n de cambios, como consecuencia de la prueba y evaluaci6n, debe tratarse de forma individual. Cada cambio propuesto debe ser evaluado, antes de tomar una decisi6n respecto a si incorporarlo 0 no, en terrnlnos de su impacto en otros elementos del sistema y en el coste del cicio de vida. La viabilidad de incorporar el cambio depsndera de su extensi6n, su impacto en el sistema en termlnos de su habilidad para desarrollar su misi6n de-

69


signada, y del coste de su implantaci6n. EI procedimiento general para la iniciaci6n y el procesado de cambios se ilustra en la Figura 36.

Si se va a incorporar un cambio, deben implantarse los necesarios procedimientos de control de cambios. Esto incluye la consideraci6n del momento en que debe realizarse el cambio, los adecuados elementos serializados afectados de un determinado lote de fabricaci6n, los requisitos para efectuar cambios en elementos fabricados con anterioridad, el desarrollo y «prueba» de los conjuntos de modificaci6n de cambios, la localizaci6n geografica donde deben instalarse los conjuntos de cambios, y los requisitos de comprobaci6n y verificaci6n del sistema despues de haber incorporado el cambio. Es particularmente importante desde la perspectiva de ingenierfa de sistemas el aspecto del control de cambios y el mantenimiento de una configuraci6n de referencia bien definida. Debe existir una estrecha relaci6n de trabajo entre la ingenierfa de sistemas y la gesti6n de la configuraci6n.

2,1. Prcducclon "I/o eonstrucclen

Es necesario definir, al principio de la fase conceptual del disefio y concurrentemente con la definici6n de los elementos del sistema que se va a desarrollar, los requisitos de producci6n (si van a producirse cantidades multiples de un elemento) 0 construcci6n (de un sistema unico en su clase como una planta de fabricaci6n, un sistema de seguimiento de satelltes, un sistema de distribuci6n de energfa, 0 una red de comunicaciones). A medida que el disefiador evalua diferentes opciones tscnlcas como parte de los analisls de viabilidad (ver Secci6n 2.1.2.), los requisitos de fabricaci6n, de mecanizaci6n, de procedimientos de montaje ydesmontaje, y de enfoque de las pruebas de aceptaci6n del sistema deben ser evaluadas tarnblen en termlnos de viabilidad. Puede resultar que una determinada tecnologfa, considerada para su aplicaci6n en el disefio de los componentes mas importantes del sistema, pueda causar importantes problemas en terrnlnos de fabricaci6n y montaje, pruebas, yentorno. No s610

70


;----------------~----------------,

, Propuesta de cambio de ingenieria (ECP)

----------------~-

Propuesta de cambio ~ de ingenieria (ECP) ,

,-----------------,-----------------,

Propuesta de cambio de ingenieria (ECP)

I ------------~------------------,

'------------------,-------------------'

~ - - - - - - - - - - - - - - - - - -,- - - - - - - - - - - - - - - - - -.!

wt ~

r Panel de Control c:leca!billsf),

f--

I ~~:~~~ ~~=::~ ::~:~ad, ~ /,/ "",~,_ 51 ·-D~~~I-b-d~-~~-pi~~-1

i coste de cicio de vida, etc. i~' {,Es ~I camblo>~ de ImplantaCion :

, ' ""V1able!/ 'del cambio '

i' Fecha propuesta de incorporacion, i <:> :

i numeros de serie afectados, requisites i \If, ,:, NO

i de retrofit, etc, i 'f

!, Recursos requeridos para implantar ~

ielcambio i

i' Coste de implantar el cambio i

1 ----------------------------------------------- !

No acci6n adicional ~

~ Desarrollo de kits de

~ modificacion

--------~ y procedimientos

, de instalacion

• . //"c /" <, '''...,'' : SisterTB i

: : /Ve 'fi d I" : devuelto :

i Incorporacion del i,/ (., n c:=' a a'" 51 ~ ,i

----~ bi bad :---,$<&- Idoneldad·-----~ a pruducci6n :

: cam 10 apro 0: 'l""'" /: '

• • ',' '"del cambio?/ " y/o

--------------r---------------- , .

operacion

iD~secllClS ~~ - residuos

• Revision de datos. ,---------------------------------- •

----------~ y documentacion--------------------------------------------------

________ ~_~ __ ~~~~________ Rediseilo reqUeridO~#

, ,

, ,

'------------------------------------,

~ J

(j Esta actMdad se conace tambiim como "Panel de Control de ConfiguraciOn"

Figura 36 .• PROCESO DE CONTROL DE CAMBIOS DE INGENIERIA·

debe disefiarse para manufacturabilidad (0 capacidad de ser construido), sino tenerse en cuenta tarnblen el entorno, ~ Tendril el proceso de fabricaci6n, debido a los materiales seleccionados en el disefio, efectos nocivos sobre el entorno? Un objetivo de la ingenierfa de sistemas es asegurar que esta fase de actividad este adecuadamente integrada desde el comienzo con las otras caracterfsticas del disefio.

2)3, U1ilizaciol1 y apoyc del sistema

La valoraci6n de las prestaciones y la efectividad de un sistema requiere de la disponibilidad de los hist6ricos de utilizaci6n

7 1


y de mantenimiento de los diversos elementos del sistema. Las medidas de prestaciones tscnlcas se establecen al comienzo del cicio de vida con el desarrollo de los requisitos operatlvos y el concepto de mantenimiento; los requisitos de fiabilidad, mantenibilidad, factores humanos, soportabilidad, y otros similares se identifican, se realizan anal isis y predicciones a 10 largo del desarrollo del sistema; y ahora que el sistema ha side desplegado con total capacidad operativa y esta siendo utilizado por el usuario, surgen las siguientes preguntas:

1 . ~ Cuales son las verdaderas caracterfsticas de prestaciones y efectividad del sistema?

2. ~Cual es la verdadera efectividad de su capacidad de apoyo logfstico?

3. ~Se han cubierto los requisitos inicialmente establecidos?

4. ~Es rentable el sistema desde la perspectiva de su utilizaci6n y apoyo?

5. ~Se estan cumpliendo todas las expectativas del usuario?

Dar respuestas a estas preguntas requiere una capacidad formal de informaci6n y de realimentaci6n de datos con las salidas adecuadas en los momentos oportunos. Se debe disefiar, desarrollar, e implantar un subsistema de datos que cumpla un conjunto especffico de objetivos, que deben estar directamente relacionados con las preguntas anteriores. Mas concretamente, el objetivo es doble:

1. Proporcionar los datos, de forma continua, que se puedan aplicar en la evaluaci6n y valoraci6n de las prestaciones, efectividad, funcionamiento, mantenimiento, y capacidad de apoyo logfstico del sistema utilizado en campo por el usuario. ~Se sabe hasta que punta esta funcionando bien (0 mal) el sistema? ~Se pueden identificar las

72


areas de debilidad en las que se puedan realizar mejoras del producto? Aunque estas preguntas puedan parecer «baslcas», la mayor parte de las capacidades de toma de datos y anallsis de utilizaci6n y mantenimiento actualmente en uso no proporcionan al ingeniero de sistemas la necesaria visibilidad para una correcta valoraci6n.

2. Proporcionar una base de datos hist6rica que cubra sistemas existentes similares en funci6n y configuraci6n y pueda ser utilizada eficazmente para facilitar el disefio y desarrollo de nuevos sistemas. Esto se refiere a las «Iecciones aprendidas» y a las realimentaciones necesarias para el desarrollo de la ingenierfa al pasar de un programa a otro. Como se transmiti6 en las Secciones precedentes de esta monograffa, hay multitud de modelos/herramientas disponibles para ayudar a realizar diferentes anallsls. Sin embargo, en la mayorfa de los casos, los datos de entrada son altamente «dudoses» al continuar dependiendo esencialmente de predicciones y estimaciones basadas en un conocimiento inadecuado del pasado, introduciendo muchas veces un alto grado de riesgo en el proceso de toma de decisiones.

Inherente al proceso de ingenierfa de sistemas es la capacidad continua de evaluaci6n y realimentaci6n. EI ingeniero de sistemas debe tener la necesaria informaci6n en tsrrnlnos de «que esta ocurriendo realmente» en el campo, debe ser capaz de identificar las areas de debilidad (en terrnlnos de ingenierfa), y debe ser capaz de proporcionar recomendaciones de mejoras y/o acciones correctoras. La Figura 37 lista algunos de los objetivos de evaluaci6n y la Figura 38 identifica el bude de evaluaci6n del sistema y de acciones correctoras.

2,9, Re-tirada de! slstema, desecho del material, rehabllttaclon y reutWzaci6n

Con la preocupaci6n existente actualmente con el medio ambiente, debe prestarse atenci6n no solo a la obtenci6n y utilizaci6n del

73


sistema a 10 largo de su pretendido cicio de vida, sino tamblsn a los requisitos relacionados con la retirada del sistema y el adecuado desecho de sus componentes. A esta actividad concreta se Ie ha prestado muy poca (0 ninguna) atenci6n en el pasado; por ello. existen muchos elementos obsoletos gue no pueden consumirse. reciclarse. 0 dejarse fuera de servicio sin crear un impacto negativo en el entorno. y sus costes de desecho seran tremendos.

Referente al papel de la ingenierfa de sistemas, un objetivo clave es el de «disefiar para desechabilidad» desde el principio; esto es, disefiar un determinado componente para que pueda ser completamente reciclado cuando se quede obsoleto para desempefiar su funci6n actual; 0 disefiar un elemento para que pueda ser desechado por incineraci6n sin impactar negativamente en el entorno. Estas caracterlstlcas deben considerarse en la realizaci6n de los estudios de viabilidad durante la fase de disefio conceptual, y cuando se definan los requisitos operatlvos del sistema y su concepto de mantenimiento. En la toma de decisiones sobre tecnologfas, materiales, esquemas de empaquetado, etc., debe considerarse un enfoque total del cicio de vida, que incluya las acciones relacionadas con la retirada del sistema y el desecho del material.

En el caso de que se tenga que tratar con la tarea de retirada de un sistema y desecho del material obsoleto, cuando las caracterlsticas adecuadas de «disefio para desechabilidad» no hayan side incorporadas, es conveniente extender el anallsis funcional y realizar un estudio de soluciones de compromiso que contemple las diferentes opciones para el desecho del material. Unos enfoques seran menos impactantes que otros, por 10 que debsra seleccionarse el que cause el menor deterioro del entorno.

74


1. FACTORES GENERALES OPERATIVOS Y DE APOYO

a) Evaluaci6n de requisitos de misi6n y medidas de prestaciones.

b) Verificaci6n de Ia utilizaci6n del sistema (modos y horas de operaci6n).

c) Verificaci6n de Ia efecIividad yel coste del sistema, disponibilidad operaliva, seguridad de misi6n, fiabilidad, mantenibilidad

d) Evaluaci6n de los escalones y ubicaciones de manlenimiento.

e) Evaluaci6n de funciones y tareas por escalOn y ubicaci6n de mantenimiento. Q Verificaci6n de politicas de nival de reparaci6n.

g) Verificaci6n de disbibuciones de frecuencia de aOOones de mantenimiento no programado y tiempos de reparaci6n.

2. EQUIPO DE APOYO Y PRUEBA

a) Verificaci6n de tipo y canlidad de equipo de apoyo por escal6n y ubicaci6n de rnanlenimienlo.

b) Verificaci6n de disponibilidad del equipo de apoyo.

c) Verificaci6n de ulilizaci6n del equipo de apoyo (frecuencia de uso, ubicaci6n, porcenlaje de liempo utilizado, ftexibilidad de uso).

d) Evaluaci6n de requisitos de manlenimiento del equipo de apoyo (rnanlenimiento programado y no programado, tiempo de inactividad, requisilos de apoyo logistico).

3. APOYO DE SUMINISTROS (REPUESTOS, REPARABLES)

a) Verificaci6n de tipos y cantidades de repueslos y reparables por escalOn y ubicaci6n de manlenimiento.

b) Evaluaci6n del grade de reacci6n de los suministros (i,es12 el repuesto disponible cuando es requerido?).

c) Verificacion de las tasas de reemplazo de elementos, tasas de condenaci6n y lasas de abicion.

d) Verificaci6n de los tiempos de reposict6n y del conduclo de distribuci6n.

e) Evaluaci6n de requisitos de mantenimiento para articulos de eslanleria.

Q Evaluaci6n de pollticas de inventario y reemplazo de repueslos y reparables. g) Identificacion de riesgos de escasez.

4. PERSONAL Y ENTRENAMIENTO

a) Verificaci6n de cantidades y cualificaciones de personal por escalOn y ubicaci6n de mantenimiento.

b) Verificaci6n de tiempos transcunidos y horas-hombre empleadas por nival de cuallficaci6n del personal.

c) Evaluaci6n de cualificaciones del personal.

d) Evaluaci6n de poliUcas de entrenamiento del personal.

e) Verificaci6n de requisitos de datos y equipo de entrenamienlo.

5. TRANSPORTE Y MANEJO

a) Verificaci6n de opo y canlidad de equipo de lransporle y manejo por escalon y ublcaoon de manlenimiento.

b) Verificaci6n de Ia disponibllidad y utilizaci6n del equipo de trans porte y rnanejo.

c) Evaluaci6n de los 1iempos de 19S(luesta en las entregas.

d) Evaluaci6n de los procedimientos de transporle y manejo.

6. INSTALACIONES

a) Verificaci6n de Ia idoneidad y utilizaci6n de las instalaciones (entrenamiento, manlenimiento, instalaciones de operaci6n).

b) Evaluaci6n de los requisilos de recursos logistiCDS para apoyo a instalaciones de operaci6n, manlenimiento y entrenamiento.

7. DATOS TECNICOS

a) Verificaci6n de Ia idoneidad de Ia cobertura de datos (nivel, precisi6n. y mBtodo de prasentaci6n de la informaci6n) en manuales de operaci6n y rnanlenimiento.

b) Verificacion de Ia idoneidad del subsislema de Ioma y analisis de dalos de campo y de aOOones correctoras.

8. SOFTWARE

a) Verificaci6n de Ia idoneidad del software (nivel, precisi6n. detalle, complnud).

b) Verificaci6n de Ia compalibilidad del software con otros elementos del sislema.

Figura 37. - VERIFICACION DE LOS REQUISITOS DEL SISTEMA-

75


Analisis de datos

Recuperaci6n, formateo, ordenaci6n y procesado de datos

· Evaluaci6n de las prestaciones del sistema

· Evaluaci6n de la efectividad del sistema F_~ ..... ,.,B ... a,.,s ... e ... d eee e ... d ... a""tos __ ~~"i' Evaluaci6n de la capacidad apoyo logistico

· Evaluaci6n de otros aspectos del sistema

. Almacenamiento datos . Recuperaci6n datos

No acci6n requerida

Requisitos especiales Datos . Aseguramiento sistema existente

. Disafio y desarrollo nuevos equipos {sistemas

NO

Datos directamente aplicables al disefio y desarrollo

de nuevas sistemas

correctoras tomadas

Identificaci6n de cam bios

Figura 38. - CICLO DE EVALUACION DEL SISTEMA Y ACCIONES CORRECTORAS

76


77

r,
' ill
@
'~
1
w
• ¥
% ,~ ......... -, -, x
lanific lIB ,
CI n,
lIB lIB F
r nl CI n
ti r
n
II! II! F
In enter: e 78


EI proceso de ingenierfa de sistemas es aplicable en todas las fases del cicio de vida de los sistemas, con enfasls durante las fases de disefio conceptual y preliminar del sistema, tal como se ilustra en la Figura 39 y se ha descrito en el Capitulo 2. EI objetivo es primero influir sobre el disefio de forma eficaz y efectiva, y despues evaluar y mejorar el disefio mediante una mejora continua del proceso.

La implantaci6n satisfactoria del proceso de ingenierfa de sistemas de pen de no s610 de la disponibilidad y aplicaci6n de las tecnologfas y herramientas adecuadas, sino tarnblen de la planificaci6n y ges-

Fase de Diseno Conceptual

Fase de Diseno Detallado yDesarrolio


;

ALTA

DISCIPLINAS DE DISEfilo

BAJA PROGRESO DEL DISEfilo Y DESARROLLO DEL SISTEMA

Figura 39. - INFLUENCIA DE LA INGENIERIA DE SISTEMAS EN EL DISENO -

79

Planificaci6n, Organizaci6n y Gesti6n de Ingenieria de Sistemas

ti6n de las actividades necesarias para alcanzar el objetivo global. Aungue todos los pasos descritos en el Capitulo 2 pueden ser especificados para un determinado proyecto, la satisfactoria implantaci6n y sus beneficios derivados no se materializarim a menos gue se establezca el adecuado entorno orgimico. Este autor ha visto muchos casos en que se ha incluido en la organizaci6n del proyecto la funci6n «ingenierfa de sistemas», pero el impacto sobre el disefio ha side practlcarnente inexistente y no se alcanzaron los objetivos. Sin el adecuado enfasis orqanlco de arriba-abajo, la creaci6n de un entorno que permita la creatividad y la innovaci6n, un estilo de liderazgo que promueva un enfoque «en equlpo», etc., la implantaci6n de los conceptos y metodologfas descritas en el Capftulo 2 no tendra lugar. Por eso, la «ingenierfa de sistemas» debe considerarse en terrnlnos de aplicaciones tecnol6gicas y de gesti6n, como se muestra en la Figura 40.

3,1, Requisi10s del pregrama de ingen!eds de sistemas

De acuerdo con la Figura 41 , que describe el cicio de vida y las actividades del sistema, la implantaci6n satisfactoria de cualquier programa depende de la planificaci6n que se realice durante la fase de disefio conceptual. Sequn se identifica la necesidad de un sistema y se completan los estudios de viabilidad en la selecci6n de un enfoque tscnlco del dlsefio, se van estableciendo los requisitos que definen la estructura del programa que pueda ser implantado para hacer realidad el sistema.

La planificaci6n comienza con la definici6n de los requisitos del programa. Se identifican funciones y tareas de ingenierfa de sistemas, se establece un enfoque orqanico, se desarrolla una descomposici6n estructurada del trabajo, se describen polfticas y procedimientos clave, y se prepara e implementa un Plan de Gesti6n de Ingenierfa del Sistema (System Engineering Management Plan, SEMP). EI SEMP, que se prepara generalmente durante la fase de

80


DISEfilo CONCEPTIJAl

" .

. a

DISEtiio PRELlMINAR DEL SISTEMA

<,

:a

DISEfilo DETAlLADO

Y DESARROLLO

''4 PRODUCCION YIO CONSTRUCCION .~

OPERACION Y fJS'OYO

DEL SISTEMA

''',*,

RETIRADA Y BAJA

Figura 40. - APLICACION DE GESTION Y TECNOLOGIA DE INGENIERIA DE SISTEMAS -

FASE DE DISEt'.lO CONCEPTUAL Y PLANIFICACION PRELlMINAR

DISENO PRELlMINAR

NECESIDAD DELUSUARIO

CONFIGURACION FUN ClONAL BASICA DEL SISTEMA

!D~:~~~~1 r~I~;;,~~l 1 ==~~

. .~ PRELIMINAR i----~

• PROGRAMAI i i DEL SISTEMA. . DE INGENIERIA

l !:'_~_Q~~I9---------- L J !?_~_~_~!~~~ _

..................................... ~-~ ~----------W

"------------------------------------,

W

IMPLANTACION \ --Jli!o-

DEL PROGRAMA

. ,

. .

,-----------------------------------_ .

BUCLE DE REALIMENTACION

Figura 41 .• PlANlFICACION DE INGEN IERIA DEL SISTEMA •

81


dlsefio conceptual y planificaci6n preliminar, abarca todas las actividades de gesti6n de ingenierfa del sistema a travss del cicio de vida, incluyendo aquellas funciones relativas a la utilizaci6n yapoyo del sistema, cambios y modificaciones, etc., que seran realizadas posteriormente.

En la determinaci6n de los requisitos del programa, los conceptos, rnetodos y procesos que describen la ingenierfa de sistemas son aplicables a todas las categorfas de sistemas. Sin embargo, deben «adaptarse» a cada aplicaci6n particular. Mas aun, las aplicaciones son numerosas y diversas:

1 . Grandes sistemas con muchos componentes diferentes, tales como un sistema espacial, uno de transportes urbanos, 0 uno hidroelectrico de generaci6n de potencia.

2. Sistemas pequefios con un nurnero reducido de componentes, tales como un sistema local de comunicaciones, un sistema lnforrnatico, un sistema hidraullco, 0 un sistema rnecanlco de freno.

3. Sistemas donde se requiera una gran cantidad de nuevo diseno y desarrollo; esto es, la aplicaci6n de nuevas tecnologfas.

4. Sistemas cuyo dlsefio se basa principal mente en la utilizaci6n de componentes comerciales existentes.

5. Sistemas con gran cantidad de equipos, software, instalaciones,o recursos humanos; esto es, un sistema de producci6n, un sistema terrestre de mando y control, un sistema de distribuci6n de datos, 0 una capacidad de mantenimiento.

6. Sistemas en los que hay un gran nurnero de suministradores involucrados, tanto nacionales como extranjeros, en el proceso de diseno y desarrollo.

82


7. Sistemas en los que el nurnero de organizaciones diferentes involucradas en su dlsefio y desarrollo es mfnimo.

8. Sistemas disefiados y desarrollados para su utilizaci6n en el sector de la Administraci6n, 0 en el sector comercial.

EI proceso de ingenierfa de sistemas en el Capitulo 2 es aplicable en cada situaci6n concreta. Aunque varlaran tanto la profundidad como la amplitud del esfuerzo, los pasos requeridos para hacer realidad un sistema son baslcarnente los mismos. Se realizaran anallsls de la necesidad y de viabilidad, se definlran los requisitos opsratlvos y el concepto de mantenimiento, se cornpletaran el anallsis funcional y la asignaci6n de requisitos, y as! sucesivamente. Incluso cuando se trate de un caso relativamente simple, como puede ser el de un pequefio sistema formado por componentes comerciales, es necesario un enfoque arriba-abajo del dlsefio y desarrollo del sistema. En otras palabras, hay un requisito de disefio del sistema incluso cuando no se requieran nuevos disefios a nivel subsistema e inferior.

3,2, identificacion de tareas

Aunque los requisitos especfficos de los programas pueden variar, se asume aqul que los requisitos tscnlcos de todo sistema estan incluidos en la Especificaci6n del Sistema (Tipo «A») y en las especificaciones subordinadas, descritas en la Secci6n 2.1.6. AI mismo tiempo, los requisitos de planificaci6n, organizaci6n, y gesti6n de ingenierfa de sistemas estan incluidos en el Plan de Gesti6n de Ingenieria del Sistema (SEMP). Estos dos documentos deben apoyarse mutuamente (esto es, «hablarse el uno al otro»).

La Figura 42 muestra las relaciones entre dichos documentos e indica la naturaleza de la informaci6n incluida en el SEMP. La Parte I incluye un tratamiento mas tradicional de planificaci6n, organizaci6n, implantaci6n y control, y funciones asociadas de gesti6n del progra-

83


mao La Parte II describe el proceso de ingenierfa de sistemas, desarrollado en el Capitulo 2. La Parte III trata la integraci6n de las diferentes disciplinas de disefio representadas en la Figura 4. Este enfoque general se amplia con el ejemplo de esquema general de actualidad de la Figura 43.

En el contexto del Capftulo 4 del ejemplo de esquema general del SEMP (Figura 43), se puede tratar de identificar un nurnero seleccionado de tareas clave para una organizaci6n de ingenierfa de sistemas. Para empezar, es adecuada una revisi6n de algunos de los objetivos globales. Los objetivos de la ingenierfa de sistemas son:

__________________________ 1 ,

PLAN DE GESTION DEl PROGRAMA

______________ J_________________ __ __ J __

:

:---------------------------]----------------------------

REQUISITOS TECNICOS DELPROGRAMA

: 1 ,

ESPECIFICACION DEL SISTEMA TIPO'A'

.;.,(.

; J ,

PARTE I

PARTE III

, ,

I ,

• PLANIFICACION. IMPLANTACION • Y CONTROL DEL PROGRAIvIA TECNICO

, ,

,-----------------------------------------------

Describe las tareas del programa tecnico que deben ser planeadas e

implantadas en la consecuci6n de los objetivos de gestion de ingenierla de sistemas.

Describe el proceso de ingenierfa de sistemas tal y como apllca a la definicion de requisitos del sistema,

y al desarrollo de esos requlsltos en una configuraci6n final del producto.

Describe los requisitos del sistema en las diferentes areas de especlalldad de ingenieria. y la integraci6n

de esas areas de especialidad en el esfuerzo global "principal" de diseiio y desarrollo

de ingenierla.

Figura 42. • DOCUMENTACION DEL PROGRAMA •

84


1. Visi6n de conjunto.

2. Objativo yalcanc:e.

3. Aplicacionas.

4. Planificaci6n, implantaci6n y control del programa t8cnico (Parte I). 4.1. IntroducciOn.

4.2. Requisilos del programa/especilicaci6n de los trabajos.

4.3. OrganizaciOn (organizaciOn del proyeclo, organizaciOn funcional, atribuciones responsabilidades, interrelaciones y comunicaciones, control y relaciones con los suministradores).

4.4. Planificaci6n del programa (albal de especificaciOl1es, descomposici6n estructurada de los trabajos, calendarios y/o hilos del programa 0 proyeclo).

4.5. Gestion de la intermse !ecnica (relaciones entre entidades intemas, gesti6n de suministradores

y/o subcontratistas).

4.6. MediciOn de prestaciones tecnicas (identificaciOn medidas de prestaciones tecnicas, seguimiento). 4.7. Coste del programa (previsiones/informes).

4.8. Auditorra tecnica y revisiOn del diseno (revisiones intemas, revisiones formales, revisiones de

suministradores!subcontratistas).

4.9. Comunicaciones tecnicas (documentaciOn e informes del programa, seguimiento y control). 4.10. GestiOn de configuraciOn.

4.11. GestiOn de r1esgos (ldentificaci6n de r1esgos, valoraci6n de riesgos, dlsminuci6n/supresi6n).

5. Proc:eso de ingenierfa de sistemas (Parte II).

5.1. Analisis de la necesidad del sistema y estudio de viabilidad. 5.2. Requisitos operativos del sistema.

5.3. Concepto de mamenimiento.

5.4. Analisis funcional.

5.5. AsignaciOn de requlsitos.

5.6. Sintesis, anillisis y solucionas de compromiso del sistema. 5.7. IntegraciOn y apoyo del diseoo.

5.8. Prueba y evaluaciOn del sistema.

5.9. Apoyo de la producci6n y/o construcci6n.

5.10. Modificaciones del sistema (implantaciOn y control de cambios).

6. Integraci6n de especialidades de ingenierfa (Parte III).

6.1. Especialidades de ingenieria OdentificaciOn de especialidades clave de ingenieria, su integratiOn en el proceso de ingenierra de sistemas, y sus interrelaciones).

6.2. Oescr1pciOn de especialidades individuales de ingenieria (objetivo, organizaciOn, desaipciones

de tareas, calendarios, etc., para cada area significaliva de especialidad). 6.2.1. Efectividad del sistema.

6.2.2. Ingenieria de fiabilidad.

6.2.3. Ingenierfa de mantenibilidad.

6.2.4. Ingenieria de factores hUmanos.

6.2.5. Ingenieria log [stica.

6.2.6. Ingenierfa de software.

6.2.7. Ingenieria de calldad.

6.2.8. Ingenieria de valorfcosle.

6.2.9. Manufacturabilidad.

6.2.10. Otras disciplinas de ingenieria (segan se requieren).

7. Rafaranclas (aspecHicacionas, estandaras, planas y otras rafaranclasldocumelltacl6n pertlnantes).

Fjgura 43.

(Ejemplo) - ESQUEMA DE PLAN DE GESTION DE INTEGRACION DE SISTEMAS

85


1. Asegurar que se desarrollan de forma oportuna los requisitos de dlsefio y desarrollo, pruebas y evaluaci6n, fabricaci6n y/o construcci6n, utilizaci6n, y apoyo, a traves de un anallsis lteratlvo, de arriba-abajo, de los requisitos.

2. Asegurar que las alternativas de disefio del sistema son adecuadamente evaluadas en base a unos criterios significativos y cuantificables relacionados con todas las caracterlstlcas deseadas; esto es, facto res de prestaciones, factores de efectividad, caracterlsticas de fiabilidad y mantenibilidad, facto res humanos y de seguridad, caracterfsticas de soportabilidad y coste del cicio de vida.

3. Asegurar que todas las disciplinas aplicables de dlsefio y sus areas de especialidad asociadas son adecuadamente integradas en el esfuerzo total de ingenierfa de forma oportuna y efectiva.

4. Asegurar que el esfuerzo global de desarrollo del sistema progresa de forma 16gica, con configuraciones de referencia establecidas, revisiones formales de dlsefio, la adecuada documentaci6n que apoye las decisiones de disefio, y las necesarias provisiones para acciones correctoras, sequn se requiera.

5. Asegurar que los diferentes elementos (0 componentes) del sistema son compatibles entre sf, y se combinan para constituir una entidad que realizan las funciones requeridas de forma efectiva y eficaz.

La revisi6n de estos objetivos generales conduce a la pregunta l,que tare as detalladas del programa/proyecto deben realizarse con el fin de cumplir, de forma satisfactoria, los fines de la ingenierfa de sistemas? Aunque cada programa es diferente y las tareas a aplicar deben ser «adaptadas» en consecuencia, se considera que las tareas identificadas en la Figura 44 son aplicables en la mayorfa de los casos. Esto no quiere decir que una organizaci6n de ingenierfa de sistemas complete cada una de elias dentro de su propia estructura; sin

86


embargo, la organizaci6n de ingenierfa de sistemas debe asumir el liderazgo para asegurar que todas elias se realizan de forma efectiva yeficaz.

3.3. Organtzaci6n para ingenier!a de sistemas

AI organizarse para ingenierfa de sistemas, es necesario comenzar por el cliente (esto es, el «usuarlo»), ya que los requisitos basicos deben evolucionar desde «10 mas alto». EI cliente debe pensar en terrnlnos de sistemas, debe creer en el proceso de ingenierfa de sistemas, y debe iniciar los adecuados requisitos del programa para asegurar que los objetivos, conceptos, y rnetodos aqul descritos se implantan adecuadamente. EI cliente debe crear el ambiente necesario para gue «ello ocurra». Con esto como punta de partida, los requisitos de alto nivel del programa deben ir fluyendo a traves de los niveles inferiores de la estructura orqanlca, como se muestra en la Figura 45. Aunque los principales segmentos de actividad puedan tener lugar en las organizaciones del contratista o del fabricante, la necesidad debe ser establecida al nivel superior.

La satisfactoria implantaci6n de los requisitos del programa de ingenierfa de sistemas depende, en gran parte, del establecimiento de buenas comunicaciones, no s610 entre el cliente y el contratista (0 fabricante) principal, sino entre el contratista y los diferentes suministradores. Debe establecerse desde el comienzo del programa un enfoque de «equlpo» (que incluya al cliente, contratistas y suministradores). Este equipo de dlssfio, con representantes de las distintas areas de actividad a traves del clclo de vida (incluyendo al «usuarlo» final del sistema) debe participar en el proceso preliminar de anallsls de los requisitos del sistema y en la subsiguiente definici6n de las actividades/tareas del programa. Por ello, la existencia de buenas comunicaciones es esencial. Con relaci6n a la Figura 46, son numerosas las interfaces diarias con la ingenierfa de sistemas, aunque pueda ser fijo

1. Realizar el analisis de la necesidad y el estudio de viabilidad.

2. Definir los requisitos operativos y el concepto de mantenimiento del sistema.

3. Preparar la especificaci6n Tipo "A" del sistema.

4. Preparar el Plan Maestro de Prueba y Evaluaci6n.

5. Preparar el Plan de Gesti6n de Ingenieria del Sistema.

6. Realizar el anslisis funcional y la asignaci6n de requisitos.

7. Realizar el anelisis del sistema, la sintesis y la integraci6n del sistema.

8. Planificar, coordinar y celebrar reuniones de revisi6n formal del disefio.

9. Seguir y revisar las actividades de prueba yevaluaci6n del sistema.

10. Planificar, coordinar, implantar y controlar cam bios de disefio.

11. Iniciar y mantener enlaces con producci6nl construcci6n yactivid ades de servicio al cliente.

Documentaci6n de los requisitos del cliente/consumidor; informes tecnlcos que cubran las aplicaciones tecnol6gicas; informes seleccionados de investigaci6n; informes de estudios de soluciones de compromiso que apoyen el enfoque del disefio,

Documentaci6n de los requisitos del cliente/consumidor; especificaciones y estandares del cliente; informes del estudio de viabilidad; informes de estudio de soluciones de compromiso que apoyen el enfoque del disefio,

Informes tecnicos que cubran aplicaciones tecnol6gicas; informes del estudio de viabilidad; documentaci6n de los requisitos del sistema (requisitos operativos y concepto de mantenimiento); informes de los estudios de soluciones de compromiso que justifiquen decisiones de disefio al nivel del sistema.

Especificaci6n Tipo "A" del sistema; especificaciones y estandares de prueba del cliente; hojas de requisitos de pruebas (requisitos de prueba de disciplinas individuales).

Documentaci6n de los requisitos del cliente/consumidor; especificaciones y estandares de program a del cliente; documentaci6n de los requisitos del sistema (requisitos operativos y concepto de mantenimiento); especificaci6n Tipo "A" del sistema; Plan Maestro de Prueba y Evaluaci6n; informaci6n de la planificaci6n preliminar del sistema; Plan de Gesti6n del Programa.

Documentaci6n de los requisitos del sistema (requisitos operatvos y concepto de mantenimiento); especificaci6n Tipo "A" del sistema; informes de los estudios de soluciones de compromiso que justifiquen decisiones de diserio al nivel del sistema.

Documentaci6n de los requisitos del cliente/consumidor; especificaciones y estandares del cliente; informes del anelisis funcional; especificaci6nTtipo "A" del sistema; Plan de Gesti6n de Ingenieria del Sistema; Plan Maestro de Prueba y Evaluaci6n; requisitos de planificaci6n de los programas de las disciplinas individuales de disefio,

Plan de Gesti6n del Programa; Plan de Gesti6n de Ingenieria del Sistema; datos aplicables de disefio (pianos, listas de piezas y materiales, informes, bases de datos); informes de los estudios de soluciones de compromiso que justifiquen decisiones de diserio: informes de disciplinas individuales de disefio (predicciones, anal isis, etc.).

Plan Maestro de Prueba y Evaluaci6n; Plan de Gesti6n de Ingenieria de Sistemas; informes y datos de pruebas individuales.

Informes y datos de gesti6n de configuraci6n (descripci6n de la configuraci6n basica de disefio); propuestas de cambio de ingenieria; requisitos y acciones de control de cambios.

Datos de dlsefio del sistema; requisitos de producci6n/construcci6n; cambios de dlsefio aprobados; procedimientos de utilizaci6n y mantenimiento del sistema.

Informes del estudio de viabilidad; informes de los estudios de soluciones de compromiso que justifiquen decisiones de disefio al nivel del sistema.

Documentaci6n de requisitos del sistema (requisitos operafivos y concepto de mantenimiento); in formes de los estudios de soluciones de compromiso que justifiquen decisiones de diserio al nivel del sistema.

Especificaci6n Tipo "A" del sistema.

Plan Maestro de Prueba y Evaluaci6n.

Plan de Gesti6n de Ingenieria del Sistema.

Informes de los anal isis funcionales-diagramas de flujos funcionales (funciones operativas y de mantenimiento); hojas de anslisis de oportunidad; hojas de asignaci6n de requisitos; informes de los estudios de soluciones de compromiso; hojas de requisitos de prueba; hojas de criterios de disefio.

Datos seleccionados de disefio: informes de integraci6n del sistema; in formes y datos de los suministradores; informes de los estudios de soluciones de compromiso que justifiquen decisiones de disefio: informes de disciplinas seleccionadas de diseno (predicciones y analisls).

Actas de las reuniones de revisi6n de disefio: listas de acciones con responsabilidades designadas; datos de dlsefio y documentaci6n de apoyo aprobados.

Informe(s) de prueba y evaluaci6n del sistema.

Planes de implantaci6n de cambios; datosflnformes de verificaci6n de cambios.

Informes de datos y fallos de campo; informes de servicio al cliente en operaciones de campo.

Figura 44. - TAREAS DE INGENIERIA DE SISTEMAS -

87


el canal mas formal de comunicaciones referente a aspectos contractuales y de direcci6n del programa. Uno de los principales objetivos de la ingenierfa de sistemas es «causar» la integraci6n de los distintos elementos orqanlcos responsables del disefio y desarrollo del producto final.

Dentro de una organizaci6n determinada (esto es, la organizaci6n del cliente 0 la del contratista) puede haber distintos enfoques en terrnlnos de estructura. Por ejemplo, la organizaci6n de un contratista puede estar estructurada de forma «funclonal», en terrnlnos de «proyectos» 0 «llneas de producto», puede tener forma de organizaci6n «matriclal»;» puede ser una combinaci6n de las anteriores. La elecci6n final de un determinado enfoque cependera, 16gicamente, de la naturaleza y complejidad del sistema en desarrollo, de la necesidad 0 no de un volumen slqnlficatlvo de nuevo dlsefio, de la magnitud global del

REQUISITOS DEL SISTEMA

~~TlSTAAj~~~~~~~~~~m',;;d;;~~~~

1m

1m. . .lm ;mL,l

• SUMINISTRADOR • • SUMINISTRADOR. • SUMINISTRADOR. i SUMINISTRADOR i

DE COMP~NENTES DE COM~NENTES! I DE COM~ONENTES IDE COMP~NENTESI

: J l i l J

~ nnnnnmI

! SUMINISTRII[)~~! • A • DE COMPONENTES.

: J

Figura 45. -lA ASIGNACION DE REQUISITOS DE INGENIERIA DE SISTEMAS -

88


INGENIERIA DE

~ SISTEMAS

1--;~~~~;~~,~-1

i FUNCIONAL i

I J

~ ; .-

ORGANIZACION DEL FABRICANTE ..:'

- - -----~

INGENIERIA DE DISENO

"'" :

-~~~~~~~'-~~ I

! APOYO !

! LOGISTICO !.

l __ '_~~=~_~~_~ __

c-,"

'". .'

'--PRoj):uccfoN--1 ,PRUEBA1 :------CONTRii------1

: DE CALIDAD i

• - - - - - - - - - - _~ - - - - - - - - - - __ I

- - - - - - - - - - -::- ~ .. '

i GESTI~~1 ! DEL f ! PROGRAMA!

l :~-:-:~:::_:] ,

-.-~-,.:,-

:---------~·'··-'~--------l


----------'~~-~~-'----------.

c •• c •• _ ~_- ., ,c

,----------------~;~~';~~~~~~~=~-~--~~,.

~-.::~----.--

~SUMINISTRADORA ~ DISENODE COMPONENTES DEL SISTEMA

:-~~~~-~;~;~~~-~l

COMPONENTES ~

=~T~~~l

rsu~~~cl

COMPONENTES !

-----------------------------_I

Figura 46 .• INTERFACES CLiENTElFABRICANTElSUMINISTRADORES •

esfuerzo emprendido, y de otros aspectos afines. Gada tipo de estructura tiene sus ventajas y sus desventajas al considerar la implantaci6n de los requisitos de un programa de ingenierfa de sistemas para un proyecto tlplco. EI enfoque puramente funcional tiende a favorecer el desarrollo y la aplicaci6n de nuevas tecnologfas, mientras que en la orientaci6n al cliente no es tan evidente. Por otra parte, el enfoque previo al proyecto proporciona el necesario enfasis en el cliente, pero no siempre permite la introducci6n de nuevas tecnologfas. En este punto, el lector puede desear revisar parte de la Bibliograffa para comprender mejor los «pros y contras» asociados a los diferentes enfoques de organizaci6n para ingenierfa de sistemas [2].

La Figura 47 muestra la estructura orqanlca de un contratista determinado, que desarrolla multiples proyectos (grandes y peque-

89


~PJI~rt~~A HIJ •

{----------------r----------------------------------r----------------L---------------i----------------------------------,----------------{

/ .' riNGENiERiA-1i~~~~_~!~~~~~_1

'--:--~---ntas---bi--f-kl-':ct--amrti--Y--fi-,~-~---·- ---,--'" c .: .>: / :: =ii;ti~~::-

- Compru, c:::::' c " EIIuipo de apoyo, ,

• Recursos hUmanos. ",~, Repusstos/nlparablas. ~

. Ges!illn de conlnilDs, " Publk:adonllS tj~lcas, ,

~, EIIul~lenIo. ~

" Transporte y dis1ribuci6n. ,

"l ~'--~-~-~-~-~,---------~

~B ' 'c-l- -------~

;~~~~~T~:,~:;l~l (RES~=~R~=)1, ;F{()~~ RZ-

! "

---~J' L , ! L _

E ,_:~~~1

'" Gesliilnde~raci6n. i 11

,'> ,_.F--- '-1' G85IIOndedatos, i .l

l----~,;::---------~~,-·,::-~--~~~--·:---f-------------------jt-~~f~:~~~~~j___--~\---r--------------------------'~,-----T-------l

-------liiOE~iEiUA-'-----i ;------ING~ERiA-------- ~------;AUDACiON----1 '------INOENIERIA----- iiUEilO~Y-D~U.EiiTACiDIi.

DE 8ISTEMAS ,DE DISEliDD~~ISEIlDj DE SDFTWARE l~IDAPllRCI'!DE~~

RequisiDs del sistema, Diseiio eliK:trico. Fl8bilidad. Software opaiUvo, Eslandarizaci6n del disaiio,

Espec:ificaeiOn del silBna. DiBello mecSlico, t.IanIejjJidad. Soflware de manlenimienlo. Aplicaaones iTIDImIIticas,

hlAisis del &9II1II, Dlsello de malallalllS, IngeliBlia de logislica, Software d. producclOn InIIiIfac;ss CAMICALS.

IniegradOn Y Disano es1nIctul8l, Ingenieria de 'IlI1er, y prueba. InlBrfaces clierrte/suministredor.

pruebadel Sislelllll, Ingenierla de componenies, Factores hUIlllll1Dll_ ValidaciOn del soilw8re,

RlMBiones dB diillilo,

-----------'-----------~

~ COMERCIAL •

-l{)PERACIONES.

• Ingerielia de pnxtucci/ln, · Pnxtucci/ln,

• Fabrlc:aclOn.

• Inspea:l6n y prueba.

• Modificaciones,

• CooIJIII de ceiidisd,

F~ura 47 .• PRINCIPALES ENlACES DE COMUNICACION DE INGENIERIA DE SISTEMAS·

nos). La figura enfatiza las interfaces orqanlcas y las comunicaciones requeridas para un programa relativamente grande (esto es, el Proyecto «Y»). La Figura 48 presenta una breve descripci6n de cad a una de las principales necesidades de interfaz y de flujo de informaci6n. Su finalidad es mostrar que hay muchas relaciones diferentes que deben ser establecidas para cumplir los objetivos de ingenierfa de sistemas. Mediante la realizaci6n de las tareas de la Figura 44, la organizaci6n de ingenierfa de sistemas sera capaz (deseablemente) de promover la necesaria integraci6n de todas las actividades relacionadas con el dlsefio, de manera oportuna y efectiva. EI cometido del responsable de ingenierfa de sistemas es implantar los requisitos del programa especificados en el Plan de Gesti6n de Ingenierfa del Sistema (SEMP). Estos requisitos deben, por supuesto, ser adecuadamente «adaptados» al programa en cuesti6n.

90


CANAL DE ORGANIZACION DE APOYO
COMUNICACION (REQUISITOS DE INTERFACE)
A 1. Marketing 0 ventas - adquirir y mantener las
comunicaciones necesarias con el cliente. Se necesita infomaci6n
supletoria relativa a requisitos del cliente, requisitos operatives y de
apoyo del mantenimiento del sistema. Esto es por encima del canal
"contractual" formal de comunicaciones.
2. Contabilidad - adquirir datos de costes y presupuestarios
en apoyo a analisls econ6micos (ej., anajsis del coste del cicio de
vida).
3. Compras - asistir en la identificaci6n, evaluaci6n y
selecci6n de suministradores de componentes relativo a
implicaciones tecnlcas, de calidad, y de coste del cicio de vida.
4. Recursos humanos - solicitar asistencia en el reclutamiento
inicial y contrataci6n de personal cualificado para ingenierfa de
sistemas, yen el subsiguiente entrenamiento y mantenimiento de
las cualificaciones del personal. Desarrollar programas de
entrenamiento para todo el personal del proyecto relativos a
conceptos de ingenierfa de sistemas, objetivos, e implantaci6n de
requisitos del programa.
5. Gesti6n de contratos - mantenerse al nivel de los requisitos
del contrato (de naturaleza tecnica) entre el cliente y el contratista.
Asegurarse que las relaciones adecuadas se establecen y
mantienen con suministradores, en 10 referente a cumplir las
necesidades tecnleas de dlsefio y desarrollo del sistema.
B Establecer y mantener enlace permanente y estrecha
comunicaci6n con otros proyectos con el objetivo de transferir
conocimientos que pueden ser aplicados con beneficia al
proyecto "Y". Solicitar asistencia de otros departamentos y
laboratorios de ingenierfa de la compafiia, de orientaci6n
funcional, relativo a la aplicaci6n de nuevas tecnologfas en
apoyo del disefio y desarrollo del sistema. Figura 48.-

DESCRIPCION DE LOS PRINCIPALES REQUISITOS DE INTERFACE DEL PROYECTO

Ingenieria BN

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ingenieria BN

Cargado por

Copyright:

Formatos disponibles

~

También podría gustarte

Ingenieria BN

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ingenieria BN

Cargado por

Copyright:

Formatos disponibles

﻿ ~

También podría gustarte

~