24 CAPITULO 2 m Sistemas socio-técnicos Figura 2.2 El proceso de la ingenieria de sistemas. 2.24 Figura 23. Disciplinas involucradas en la ingenierla de sistemas. 2. Implicacién interdisciptinaria, Muchas disciplinas de la ingenieria se conjuntan en Ia ingenieria de sistemas. Existe una gran discrepancia debido a que diferentes ingenie- ros usan diferente terminologia y convenciones. La ingenierfa de sistemas es una actividad interdisciplinaria que conjunta equipos de perso- nas con diferentes bases de conocimiento. Los equipos de ingenieria de sistemas son necesatios debido al amplio conocimiento requerido para considerar todas las implicaciones de las deci- siones en el disefio del sistema. Como ejemplo de esto, la Figura 2.3 muestra algunas de las dis- ciplinas que conforman el equipo de ingenier‘a de sistemas para un sistema de control del trifi- co aéreo (CTA) que utilizan radares y otros sensores para determinar la posicién de los aviones. Para muchos sistemas existen posibilidades casi infinitas de equilibrio entre los diferentes, tipos de subsistemas. Las diferentes disciplinas negocian para decidir qué funcionalidad debe proporcionarse. A menudo no existe una decisiGn «correcta» sobre cémo se debe descompo- nner un sistema. Més bien, puede tener varias opciones, pero es posible que no pueda elegir la ‘mejor soluci6n técnica. Por ejemplo, una alternativa en un sistema de control del trifico aé- reo es construir nuevos radares, més que arreglar las instalaciones existentes. Si los ingenie- 10s civiles relacionados con este proceso no tienen més trabajo que hacer, estardn a favor de esta opcién debido a que les permite conservar sus trabajos, Pueden justificar esta eleccién utilizando argumentos téenicos. Definicién de requerimientos del sistema Las definiciones de requerimientos del sistema especifican que es lo que el sistema debe hacer (sus Funciones) y sus propiedades esenciales y deseables. Como en el andlisis de requerimien- Ingenieria Ingenieria Ingenieria del software de electronica mecinica Ingenieria de estructuras Ingenieria celéctrica |2.2 m Ingenieria de sistemas 25 tos del software (tratado en la Parte 2), crear definiciones de requerimientos del sistema re- ‘quiere consultar con los clientes del sistema y con los usuarios finales. Esta fase de definicién de requerimientos usualmente se concentra en la derivacién de tres tipos de requerimientos: 1, Requerimientos funcionales abstractos. Las funciones basicas que el sistema debe pro- porcionar se definen en un nivel abstracto. Una especificacién més detallada de re- querimientos funcionales tiene lugar en el nivel de subsistemas. Por ejemplo, en un sis- tema de control del trafico aéreo, un requerimiento funcional abstracto especificaria que una base de datos del plan de vuelo debe usarse para almacenar los planes de vue- lo de todos los aviones que entran al espacio aéreo controlado. Sin embargo, normal mente no se especiticarian los detalles de la base de datos a menos que afecten a los requerimientos de otros subsistemas. 2. Propiedades del sistema, Como se sefial6 anteriormente, éstas son propiedades emer- gentes no funcionales del sistema, tales como la disponibilidad, el rendimiento y la se- guridad, Estas propiedades no funcionales del sistema afectan a los requerimientos de todos los subsistemas. 3. Caracteristicas que no debe mostrar el sistema. Algunas veces es tan importante es- pecificar lo que el sistema no debe hacer como especificar lo que debe haces. Por ejem- Plo, si estd especificundo un sistema de control del trfico aéreo, puede especificar que el sistema no debe presentar demasiada informacién al controlador. Una parte importante de la fase de definicién de requerimientos es establecer un conjunto completo de objetivos que el sistema debe cumplis. Estos no necesariamente deben expresar- se forzosamente en términos de ta funcionatidad del sistema, pero deben definir por qué se construye el sistema para un entomo particular. Para ilustrar qué quiere decir esto, digamos que esta especificando un sistema contra in- cendios y deteccién de intrusos para un edificio de oficinas. Un enunciado de los objetivos basado en la funcionalidad del sistema seria: Construir un sistema de alarma contra incendios e intrusos para et edificio que pro- porcione avisos de fuego y de intrusiones no autorizadas tanto internas como externas. Este objetivo establece explicitamente que debe ser un sistema de alarma que proporcione avisos sobre eventos no deseados. Tal enunciado serfa apropiado si estuviéramos reempla- zando un sistema de alarma existente. En contraste, un enunciado més amplio de los objeti- vos seri Asegurar que el funcionamiento normal de los trabajos realizados en el edificio no se Interrumpa por eventos como el fuego ¢ intrusion no autorizada. Si enuncia ef objetivo de esta forma. amplia y limita algunas decisiones en el disefto, Por |ejemplo, este objetivo permite la proteccién contra intrusos utilizando tecnologia sofisticada, sin alarma interna alguna, También puede excluir la utilizaci6n de extintores para la protec~ ci6n del fuego porque puede afectar a los sistemas eléctricos en el edificio e interrumpir se- riamente el trabajo. Una dificultad fundamental al establecer los requerimientos del sistema es que los proble- mas para los cuales se construyen los sistemas complejos son normalmente «problemas tra- viesos» (Rittel y Webber, 1973), Un «problema travieso» es un problema que es tan comple jo. y en el que hay tantas entidades relacionadas, que no existe una especificacién definitiva del problema, La verdadera naturaleza de éste emerge s6lo cuando se desarrolla una soluci6n. Un ejemplo extremo de un «problema travieso» es la previsién de terremotos. Nadie puede26 CAPITULO 2 m Sistemas socio-téenicos 2.2.2 Figura 2.4 El proceso de disenio de sistemas. predecir de forma precisa dénde seré el epicentro de un terremoto, en qué momento ocurtiré © qué efecto tendra en el entomno local. Por lo tanto, no es posible especificar completamen- te cmo abordar un terremoto. El problema sélo se puede abordar una vez que ha pasado. El disefio del sistema (Figura 2.4) se centra en proporcionar la funcionalidad del sistema a tra- vés de sus diferentes componentes. Las actividades que se realizan en este proceso son: 1 Dividir requerimientos. Analice los requerimientos y organicelos en grupos afines. Normalmente existen varias opciones posibles de divisién, y puede sugerir varias al- temnativas en esta etapa del proceso. Identificar subsistemas. Debe identificar los diferentes subsistemas que pueden, in- dividual 0 colectivamente, cumplir los requerimientos. Los grupos de requerimientos estan normalmente relacionados con los subsistemas, de tal forma que esta actividad y la de divisi6n de requerimientos se pueden fusionar. Sin embargo, la identificacion de subsistemas se puede ver infiuenciada por otros factores organizacionales y del en- tomo. Asignar requerimientos a los subsistemas. Asigne los requerimientos a los subsiste- ‘mas. En principio, esto debe ser sencillo sila divisi6n de requerimientos se utiliza para la identificacién de subsistemas. En la prictica, no existe igualdad entre las divisiones de requerimientos y la identificacién de subsistemas. Las limitaciones de los subsis- temas comerciales pueden significar que tenga que cambiar los requerimientos para acomodarlos a estas restricciones. Especificar la funcionatidad de los subsistemas. Debe enumerar les funciones especi- ficas asignadas a cada subsistema. Esto puede verse como parte de la fase de disefio del sistema 0, si el subsistema es un sistema de software, como parte de la actividad de especificacién de requerimientos para ese sistema, También debe intentar especiti- car las relaciones entre los subsistemas en esta etapa. Definir las interfaces del subsistema. Defina las interfaces necesarias y requeridas por cada subsistema. Una vez que estas interfaces se han acordado, es posible desarrollar estos subsistemas en paralelo. ‘Como se indica en las flechas bidireccionales en la Figura 2.4, en este proceso de diseito existe mucha realimentaci6n € iteracién de una etapa a la otra. Cuando surgen problemas y preguntas, a menudo tiene que rehacer el trabajo hecho en etapas anteriores. ‘Aunque se han separado los procesos de ingenieria de requerimientos y de disefto en este anilisis, en la practica estan inextricablemente relacionados. Restricciones planteadas por sis- temas existentes pueden limitar elecciones de di fio, y estas elecciones pueden ser especifi-2.2 W Ingenieria sistemas 27 ccadas en los requerimientos, Puede tener que hacer algin diseio inicial para estructurar y or- ‘ganizar el proceso de la ingenieria de requerimientos. A medida que el proceso de disefto con- tind, puede descubrir problemas con los requerimientos existentes y pueden surgir nuevos re- querimientos. Por consiguiente, una manera de representar estos provesos relacionados es en forma de espiral, como se muestra en la Figura 2.5, El proceso en espiral refleja la realidad de que los requerimientos afectan a las decisiones de disefio y viceversa, y de esta forma tiene sentido entrelazar estos procesos. Comenzando enel centro, cada vuelta de la espiral afiade algtn detalle a los requerimientos y al disefio. Al- unas vueltas se centran en los requerimientos; otras. en el disefio. A veces, nuevo conoci- fi miento recopilado durante los procesox de requerimientos y disetio significa que Ia declara- cin del problema en s{ misma tiene que ser cambiada. Para la mayoria de los sistemas, existen muchos disefios posibles que cumplen los reque- rimientos. Estos comprenden una amplia gama de soluciones que combinan hardware, soft- ‘ware y operaciones humanas. La solucién que elija para el desarrollo futuro deberd ser fa so- lucién técnica mas apropiada que cumpla los requerimientos. Sin embargo. las intervenciones corganizacionales y politicas pueden influir en la elecciGn de la soluciGn, Por ejemplo, un clien- te del gobiemo puede preferir usar proveedores nacionales antes que los extranjeros para su sistema, aun cuando el producto nacional sea técnicamente inferior, Estas influencias nor- ‘malmente tienen efecto en la fase de revisidn y valoracién en el modelo en espiral, donde los, diseftos y requerimientos pueden ser aceptados 0 rechazados. El proceso finaliza cuando la revisi6n y evaluaciGn muestra que los requerimientos y el disefio de alto nivel son suficiente- ‘mente detallados para permitir empezar la siguiente fase del proceso. > isefio arquitecténico Revision vyvaloracién A Requerimientos y disefto del sistema Figura 2.5 Un modelo en espiral de requerimientos y disefo.