Del Rio Tesisdemagister

TESIS DE MAGISTER EN INGENIERA DEL SOFTWARE

SISTEMA DE ASISTENCIA A LAGESTIN DE RIESGOS EN PROYECTOS SOFTWARE DE SISTEMAS INDUSTRIALES DE AUTOMATIZACIN Y CONTROL

Autor: Ing. Jos Luis del Ro Director: M Ing. Eduardo Diez Co-Director: M Ing. Claudio Rancan

9 de Octubre de 2006

2

A mi esposa por su apoyo incondicional. A mi hija por su comprensin y la fuerza que me brinda. A mis padres por los valores que me han transmitido. Al Dr. Ramn Garca Martnez por su ayuda en el desarrollo estratgico de la tesis. A la M Ing. Paola Britos por su asesoramiento y gua durante el trabajo de tesis. A la M Ing. Bibiana Rossi por el conocimiento y apoyo brindado durante su tutora. A M Ing. Eduardo Diez y M Ing. Claudio Rancan por sus consejos.

3

4

Sistema de asistencia a la Gestin de Riesgo en Proyectos Software de Sistemas de Automatizacin y Control

PRLOGO Los Sistemas de automatizacin y control de procesos industriales (SAC) han sufrido cambios permanentes durante las ltimas dcadas. En sus comienzos la lgica de control del automatismo, se implementaba mediante dispositivos mecnicos, luego electromecnicos y ms tarde con circuitos electrnicos digitales y/o analgicos, todas estas tecnologas tenan una caracterstica en comn, su rigidez al cambio. El mismo problema se presentaba en el rea de control de procesos industriales, cualquier modificacin del cableado de la lgica de control, requera grandes esfuerzos e inversiones. La utilizacin de nuevas tecnologas basadas en microprocesadores, permiti flexibilizar la automatizacin y el control de procesos, debido a la posibilidad de implementarlos mediante Lgica y algoritmos de control de proceso programables. A partir de esta tecnologa, se fue consolidando una nueva disciplina de construccin de Software, orientada al desarrollo de SAC. Al revisar los resultados histricos de dichos desarrollos, podemos observar que en los mismos, existan riesgos previsibles que provocaron grandes prdidas humanas y materiales. Es necesario evitar las mismas detectando, eliminando y/o reduciendo de manera temprana los riesgos que se pueden generar durante el desarrollo, la puesta en marcha y la operacin del software de control de un SAC. El problema principal de los SAC, radica en que actualmente no existen metodologas ni herramientas de gestin de riesgos adecuadas al desarrollo de los mismos. El presente trabajo tiene como objetivo desarrollar un Sistema asistente de gestin de riesgos (SGR), para proyectos de software, en el dominio de SAC que resuelva el problema en cuestin.

Prlogo

5

Autor: Ing. Jos Luis del Ro


ABSTRACT The Automation and Industrial Control System have undergone permanent changes during the last decades. At the begin, the control logic of the Automation System was implemented by means of mechanical device, later by electromechanical devices and after that by digital and/or analogical electronic circuits, all these technologies had a characteristic in common, its "rigidity to the change". The same problem appeared in the area of industrial process control, any modification of the wiring of the control logic, required major efforts and investments. The use of new technologies based on microprocessors, allowed "to make flexible" the Automation and the Process Control, due to the possibility of implementing them by means of "Logic and algorithms of programmable process control". From this technology, it has been consolidating a new discipline of Software Construction, oriented to the SAC development. When the historical results of these developments were reviewed, we can observe that in these results, existed foreseeable risks that caused great human and material losses. It is necessary to avoid these risks, to detect, to eliminate and/or reduce early, the risks that can be generated during the development, the start up and the operation of the software of control of a SAC. The main problem of the SAC, is that at the moment, do not exist methodologies even not tools of risks management, adapted to the development of Industrial Control Software. The goal of the present work is to develop an Advisor System of Risk Management (SGR) for software projects, in the SAC dominion that solves the related problem.

Prlogo

6



NDICESECCIN Prlogo Tema Sistema de asistencia a la Gestin de Riesgos en proyectos Software de Automatizacin y Control Industrial. Pg. 5

CAPTULO 1 : INTRODUCCION 1.1 1.2 1.3 1.4 Introduccin. Objetivos. Organizacin del trabajo de Tesis. Definiciones y acrnimos bsicos

15 17 18 18 22 25 27 29 31 33 34 35 35 36 38 38 43 45 45 46 46 46 47 47 47 48

CAPTULO 2 : Descripcin del problema 2.1 2.2 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.4 2.5 Evolucin histrica de sistemas de Automatizacin y Control. Estado actual de la tecnologa de Automatizacin y Control. Conceptos bsicos de riesgos en proyectos de software. Modelo de gestin de riesgo de Barry W. Bohm. Modelo de gestin de riesgo del SEI. Estndar IEEE 1540. Marco de gestin de riesgo. Cuestionario basado en la taxonoma de riesgo. Identificacin del problema. Solucin del problema.

CAPTULO 3 : EVS Estudio de Viabilidad 3.1 Establecimiento de alcances del Sistema 3.1.1 Resumen de entrevista con Gerente de producto SAC. 3.1.2 Identificacin del alcance del sistema. 3.1.3 Especificacin del alcance del EVS. 3.2 Estudio de la situacin actual 3.2.1 Valoracin de la situacin actual. 3.2.2 Identificacin de usuarios participantes en el EVS. 3.2.3 Descripcin de sistemas de informacin existentes. 3.2.4 Diagnstico de la situacin actual.

ndice

7



Especificacin de requisitos del sistema 3.3 3.3.1 Identificacin de tcnicas y de gestin. 3.3.2 Requisitos especficos. 3.3.3 Requisitos de usuario. 3.3.4 Requisitos de tecnolgicos. 3.3.5 Requisitos de interfases. 3.3.6 Requisitos de rendimiento. 3.3.7 Requisitos de desarrollo 3.3.8 Requisitos de diseo. 3.3.9 Atributos. 3.4 EVS 4 Estudio de alternativas de solucin 3.4.1 Preseleccin de alternativas de solucin. 3.4.2 Descripcin de alternativas de solucin.3.5

48 49 49 54 54 54 53 55 55 55 55 55 56 56 56 57 58 59 62 62 62 63 63 65 66 68 69 69 70 73 74 79 79

Valoracin de las alternativas 3.5.1 Estudio de riesgos. 3.5.2 Estudio de factibilidad del SGR (sesin 3). 3.5.3 Conclusiones del EVS.

CAPTULO 4 : ASI Anlisis del Sistema de Informacin 4.1 4.1.1 4.1.2 4.1.3 4.1.4 4.2 4.2.1 4.2.2 4.3 Definicin del Sistema Determinacin del alcance del sistema. Identificacin del entorno tecnolgico. Especificacin de estndares y normas. Identificacin de usuarios participantes y finales. Educcin de proceso de gestin de riesgos en SAC Planificacin de entrevistas. Resumen de estrategia de proceso de gestin riesgos SAC

Modelizacin del sistema 4.3.1 Identificacin de clases, asociaciones y atributos. 4.3.2 Modelo entidad relacin. 4.3.3 Casos de uso. 4.3.3.1 Diagramas. 4.3.3.2 Actores. 4.3.3.3 Descripcin.

ndice

8



4.3.4 Identificacin de frmulas utilizadas 4.3.4.1 Clculo exposicin a riesgo (RE). 4.3.4.2 Estimacin de prdidas (L). 4.3.4.3 Clculo de probabilidad (P). 4.3.4.4 Clculo de prioridades (PR). 4.3.4.5 Clculo de sobrecarga del equipo de proyecto (ST). 4.3.4.6 Estimacin de esfuerzo en proyectos SAC (EE). 4.3.5 Identificacin de inferencias 4.3.5.1 Determinacin factores de riesgo. 4.3.5.2 Determinacin de calidad del proceso de GR. 4.3.5.3 Determinacin de medidas preventivas / soluciones. 4.3.6 Identificacin de interfases de usuario 4.3.6.1 Especificacin de principios generales de la interfaz. 4.3.6.2 Especificacin de perfiles y dilogos. 4.3.6.3 Especificacin de formatos individuales de interfaz 4.3.6.4 Especificacin del formato dinmico de la interfaz. 4.4.6.5 Especificacin de formatos de impresin. 4.4 Especificacin del plan de pruebas 4.4.1 Definicin de alcance de las pruebas. 4.4.2 Definicin de requisitos del entorno de pruebas. Implementacin de revisin de requisitos Resultados de revisin de requisitos.

97 97 97 101 104 105 107 108 109 110 112 113 113 123 125 125 130 130 130 131 131 132

4.5 4.6

CAPTULO 5 : DSI Diseo del SI 5.1 Definicin de ARQUITECTURA del SI 5.1.1 Arquitectura del SI. Diseo de clases Descripcin general. Jerarquas. Instancias. Descripcin detallada de clases. Listado de riesgos tpicos de SAC. 138 138 139 139 141 141 142 142

5.2 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5

ndice

9



5.3 5.3.1 5.3.2 5.3.3 5.3.4 5.3.5 5.3.6 5.4

Diseo de interfases de usuario Interfases del cuestionario TBQ-SAC. Interfase de anlisis de riesgo. Interfase de visualizacin de riesgos prioritarios. Interfase de visualizacin de soluciones. Interfase de visualizacin de calidad del proceso de GR. Interfase de parametrizacin del SGR.

151 151 154 154 155 155 155 156 156 158 159 160 160 160 160 161 161 162 137 137 138 138 138 163 165 143 170 170

Diseo de inferencias 5.4.1 Diseo Inferencias de estimacin factores de riesgo INF X. 5.4.2 Diseo de inferencias de calidad de anlisis de riesgo. 5.4.3 Diseo de Inferencias de medidas preventivas. Diseo de algoritmos de clculo 5.5.1 Diseo de algoritmos de clculo de EE, P, L, RE y PR. Diseo de procedimientos 5.6.1 Listado de procedimientos a codificar. Especificacin del entorno tecnolgico 5.7.1 Entorno tecnolgico de desarrollo. 5.7.2 Entorno tecnolgico operativo. Diseo de interfases con otros sistemas 5.7.1 Exportacin e importacin de datos a base de datos externa.

5.5

5.6

5.7

5.8

5.9

Especificacin tcnica del plan de pruebas 5.9.1 Especificacin tcnica del entorno de pruebas. 5.9.2 Especificacin tcnica de niveles de pruebas. Implementacin de revisin del diseo Resultados de revisin del diseo

5.10 5.11

CAPTULO 6 : Construccin del SI 6.1 Preparacin del entorno de generacin y construccin 6.1.1 Preparacin del entorno de construccin.

ndice

10



6.2 6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 6.2.6 6.2.7 6.2.8

Generacin del cdigo de los componentes y procedimientos Generacin de clases. Generacin de sub -clases. Generacin de instancias. Generacin de interfases de usuario. Generacin de funciones de navegacin. Generacin de enlaces TBQ-SAC - Instancia seleccionada. Generacin de inferencias de factores de riesgo. Generacin de procedimientos de ordenamiento y seleccin de riesgos prioritarios. Implementacin de revisiones y pruebas de cdigo Resultado de revisiones y pruebas unitarias Resultado de pruebas de integracin Resultados de pruebas del sistema Estimacin de tasa de fallas Evaluacin de pruebas

170 170 170 171 172 173 174 175 176

6.3 6.4 6.5 6.6 6.7 6.8

176 184 198 200 214 214

CAPTULO 7 : Conclusiones y futuras lneas de trabajo 7.1 7.2 Conclusiones Futuras lneas de trabajo 219 221

APENDICES A Interfase Gestin A1 A 1.1 A 1.2 A 1.3 A 1.4 Actividades Iniciales del proyecto Planificacin general. Estimacin de esfuerzo. Cronograma de actividades. Hitos de entrega / Documentos de salida. 223 225 226 234 235

ndice

11



A 2 Actividades de seguimiento y control B B 1.1 B 1.2 B 1.3 B 1.4 C C1 Interfase Seguridad Introduccin. Riesgos prioritarios. Control de riesgos. Medidas de seguridad adoptadas. Interfase Gestin de configuracin Planificacin de la gestin de configuracin C 1.1 Identificacin de la configuracin. C 1.2 Control de cambios de la configuracin. C 1.3 Generacin de informes de estado de la configuracin. Herramientas de apoyo al control de configuracin Implementacin

236

241 242 242 242 245 245 245 246 246 247 251 257 257 257 258 259 261

C2 C3

D Interfase de Aseguramiento de la Calidad D1 D2 Introduccin Control de calidad D 2.1 Actividades estticas. D 2.2 Pruebas dinmicas. Actividades constructivas de garanta de calidad del software

D3

E Inferencias de estimacin de factores de riesgo y asignacin de pesos E1 E2 Asignacin de pesos y entradas salidas de INF X. Asignacin de soluciones en base al contexto. 263 268

F Detalle de entrevistas y observaciones

ndice

12



F1 F2 F3 F4 F5 F6

Sesin 1: Gerente de producto: Introduccin al problema. Sesin 2: Especialista: Introduccin a la GR en SAC. Sesin 3: Especialista: Viabilidad del SGR. Sesin 4: Especialista: Clasificacin de integradores. Sesin 5: Especialista: Perspectivas de GR en SAC. Sesin 6: Especialista: Terminologa utilizada en GR de SAC. Sesin 7: Especialista: Descripcin detallada de GR en SAC. Sesin 8: Anlisis de protocolo. Sesin 9: Especialista: Aclaraciones sobre de sesiones anteriores. Sesin 10: Especialista: Origen de frmula de clculo de probabilidad de ocurrencia de un riesgo. Sesin 11: Especialista: Descripcin detallada de funciones del proceso de gestin de riesgo.

275 279 283 286 289 297

F7 F8 F9

303 312 319

F10

335

F11

338

G Diccionario ampliado de trminos y acrnimos G1 G2 Diccionario de trminos. Acrnimos. 349 354 359 359

H Bibliografa H1 Bibliografa.

ndice

13



ndice

14



CAPTULO 1 INTRODUCCIN

Captulo 1: Introduccin

15




16



1.1 Introduccin Los Sistemas de Automatizacin y Control (SAC), han permitido al ser humano delegar en las mquinas las tareas peligrosas y repetitivas, en forma eficiente y econmica. Actualmente, la implementacin de los mismos, se fundamenta en microprocesadores programados en base a las secuencias de tareas que la actividad a automatizar y/o controlar requiera. Durante la construccin de software para SAC se presentan riesgos, si no son detectados y evitados en forma temprana pueden manifestarse como: - Prdidas de vidas humanas o accidentes graves. - Sistemas que no cumplen las expectativas para las cuales fueron creados. - Prdidas econmicas. - Incumplimiento de programas de produccin. - Baja fiabilidad. - Baja eficiencia. - Tiempos y costos de desarrollo de proyecto mucho mayores que los esperados. - Conflictos legales. - Prdidas de clientes. A lo largo de las tres ltimas dcadas, mucha de la experiencia acumulada en otras reas del software se ha trasladado con xito al mbito del desarrollo de SAC. Como uno de los muchsimos ejemplos que existen, podemos citar la programacin estructurada aplicada a controladores lgicos programables (PLCs), introducida por Siemens en la dcada del 80. Dado que en otros dominios de la ingeniera del software, se han creado y perfeccionado criterios y metodologas de gestin de riesgos sumamente exitosas, surge la pregunta: Es posible adecuar y complementar esos conocimientos al desarrollo de Software de aplicacin para automatismos y sistemas de control Industrial? La respuesta es SI, el propsito de esta tesis es desarrollar un sistema que permita asistir y automatizar la gestin de riesgo, durante el ciclo de vida de este tipo de aplicaciones.


17



1.2 Objetivos del sistema Detectar, mitigar y/o eliminar los riesgos durante el proceso de construccin de SAC. 1.3 Organizacin general de la tesis La tesis se elaborar en base al proceso de desarrollo de software propuesto por la metodologa MTRICA 3. La organizacin de la misma se fundamentar en: - Procesos principales: EVS, ASI, DSI y CSI. - Interfases: Gestin, Seguridad, Control de configuracin y aseguramiento de la calidad. A continuacin se describen brevemente cada una de las etapas: Procesos principales: - EVS: Estudio de viabilidad del Sistema de Informacin (Captulo 3): Durante este proceso, se analizarn las necesidades a cubrir con el Sistema de Informacin, definiendo a partir de las mismas los requisitos del SGR. Se estudiarn y valorizarn las distintas alternativas de solucin, verificando la factibilidad de las mismas. - ASI: Anlisis del Sistema de Informacin (Captulo 4): El objetivo de este proceso, ser conseguir una especificacin detallada del Sistema de Informacin a travs de un catlogo de requisitos y una serie de modelos que servirn como base para la etapa de diseo del SI. - DSI: Diseo del Sistema de Informacin (Captulo 5): El propsito de esta etapa, ser obtener la definicin de la arquitectura del sistema, el entorno tecnolgico de soporte, las especificaciones detalladas de los componentes del SI y el plan de pruebas


18



- CSI: Construccin del Sistema de Informacin (Captulo 6): Durante esta etapa se preparar el entorno de construccin de cdigo, se generar y comprobar el funcionamiento unitario e integrado de los componentes, para pasar luego a las pruebas del sistema. Interfases: - Gestin del Proyecto (apndice A): En esta interfase se estimar el esfuerzo de desarrollo, en base al mismo se planificar la estrategia general del proyecto, se disear el cronograma de trabajo y se especificarn los hitos del proyecto. - Seguridad (apndice B): En esta interfase se disear la estrategia destinada a mantener un desarrollo y funcionamiento operativo seguro del SGR. A partir de la misma, se desarrollarn los procesos necesarios para cumplir con el objetivo. - Gestin de configuracin (apndice C): Esta interfase tendr como objetivo determinar la planificacin implementacin del proceso de control de configuracin del proyecto. - Aseguramiento de calidad (apndice D): La planificacin del aseguramiento de calidad ser desarrollada en esta interfase, mientras que la implementacin y resultados de las revisiones / comprobaciones de requisitos, diseo, cdigo y sistema sern detalladas al final de las etapas ASI, DSI y CSI. Para agilizar la lectura del presente trabajo, durante el desarrollo de los captulos 2 a 6 se resumirn las tcnicas de estimacin de factores de riesgo y las entrevistas desarrolladas para la construccin del SGR. El lector interesado en el detalle de las mismas encontrar una descripcin pormenorizada en los apndices E y F. e


19



En el captulo 7, se describirn las conclusiones de la tesis y las futuras lneas de trabajo. Las conclusiones se analizarn desde las siguientes perspectivas: - Aportes del SGR al desarrollo de software de sistemas de automatizacin y control. - Evaluacin de la contribucin de los elementos tericos y prcticos aplicados al desarrollo SGR. - Evaluacin de metodologas, tcnicas y herramientas de desarrollo utilizadas para construir el SGR. Se analizarn futuras lneas de trabajo que permitan profundizar y ampliar los conocimientos que se obtengan durante el desarrollo del SGR. En el apndice G, se detallar la terminologa y abreviaturas utilizadas en el rea de SAC. Para el desarrollo de la tesis se investigar la informacin relacionada con metodologas, tcnicas y herramientas de: - Desarrollo de software de automatizacin y control de procesos industriales. - Gestin de riesgos en la Ingeniera del Software. En el APENDICE H, se citar la bibliografa consultada durante el trabajo de investigacin. Las figuras y tablas utilizadas en este trabajo, se identificarn con el nmero de seccin. Si en la misma existiesen varias tablas o figuras, se diferenciarn mediante el agregado de una letra al nmero de seccin a la que pertenecen.

La figura 1.3 sintetiza la organizacin de la tesis.


20



Introduccin(Captulo 1, pgina 15)

Descripcin general del problema(Captulo 2, pgina 25)

EVS(Captulo 3, pgina 43)

ASI(Captulo 4, pgina 59)

DSI(Captulo 5, pgina 135)

CSI(Captulo 6, pgina163 )

Interfase Gestin del proyecto(Apndice A, pgina 215)

Interfase Control de configuracin(Apndice B, pgina 231 )

Interfase de Seguridad(Apndice C, pgina 235)

Interfase Aseguramiento de calidad(Apndice D, pgina 246)

Futuras lneas de trabajo(Captulo 7, pgina 211)

Auxiliares

Detalle de asignacin de entrada y salida de mdulo reutilizable(Apndice E, pgina 256)

Diccionario ampliado de terminologa y acrnimos.(Apndice G, pgina 341 )

Detalle de planificacin, desarrollo y evaluacin de entrevistas(Apndice F, pgina 267)

Bibliografa(Apndice H, pgina 351)

Figura 1.3 Organizacin de la tesis.


21



1.4 Definiciones y acrnimos bsicos. A continuacin se resumen las definiciones bsicas utilizadas en el proceso de gestin de riesgos de sistemas de automatizacin y control. En el captulo G se brindar una visin ms amplia de la terminologa a utilizar. Definiciones bsicas: Cliente: Empresa que solicita la construccin de sistema de automatizacin y control. Contrato: Documento que restablece obligaciones (comerciales / legales) entre el cliente y la empresa que desarrolla el sistema de automatizacin y control de un proceso industrial. Control de procesos industriales: Lectura y manipulacin de variables de un proceso mediante lazos cerrados de control e instrumentacin de campo. El lazo se controla mediante algoritmos tipos PID (Proporcional Integral Derivativo), Fuzzy Logic (Lgica Difusa), Sistemas Expertos. En la actualidad, su mayor campo de aplicacin se da en las industrias qumicas, petroqumicas y en menor medida farmacutica y alimenticia. Hardware: En la tesis se refiere al equipamiento electrnico necesario para ejecutar el software de automatizacin y control de procesos industriales. Herramientas de desarrollo: Se reserva este trmino para el software de edicin de aplicaciones para sistemas de automatizacin y control industrial. Integrador: Empresa encargada de desarrollar software para sistemas de automatizacin y control industrial. Proceso industrial: Conjunto de actividades a desarrollar por un sistema electromecnico y/o qumico para producir un producto. Proyecto: En la tesis, el trmino se refiere al desarrollo de software de automatizacin industrial.


22



Proveedor: En el documento de tesis, se reserva esta palabra para la empresa que provee el hardware y herramientas de desarrollo necesarias para implementar el software de automatizacin y control de procesos industriales. Riesgo: Es la posibilidad de sufrir prdidas. Sistema de automatizacin y control de procesos industriales: Sistema constituido por PLCs, HMIs, PCs industriales, redes, accionamientos, servos ,sistemas operativos y software de aplicacin que permite automatizar y controlar un proceso industrial. Sistema de control de procesos: Es un conjunto de elementos (Computadoras industriales, PLCs, DCS, sensores, actuadores, SCADAS, redes industriales) que permite comandar lazos cerrados de control de temperatura, presin caudal, etc. Los lazos pueden ser controlados por accin PID, por Fuzzy Logic y en casos ms complejos por redes neuronales. Hasta hace pocos aos, el Control de proceso era una disciplina separada de la Automatizacin. Hoy en da ambas disciplinas se complementan y mezclan de forma tal que es difcil precisar el lmite entre ellas. Sistema de posicionamiento: Comanda el posicionamiento de un dispositivo mecnico mediante servomotores. Actualmente, los sistemas ms modernos suelen incluir una lgica de control y de posicionamiento programables, son utilizados en robtica y en mquinas herramientas. Sistema de supervisin y adquisicin de datos: Permite visualizar y comandar el proceso o automatismo por medio de una computadora comunicada a una red industrial. Habitualmente ofrece la posibilidad de conectarse con la red corporativa y/o a bases de datos (ej SQL, Access, Oracle etc.). Solucin: En el trabajo de tesis se utiliza este trmino para sintetizar el conjunto de actividades destinadas a controlar uno o varios riesgos. Tercero: Empresa contratada por el cliente para participar en la construccin del proceso industrial (por ejemplo: ingeniera, fabricacin y montaje de componentes mecnicos, obra civil, instalaciones elctricas, etc.) En el apndice F6 se detalla la entrevista mediante la cual se obtuvo la terminologa utilizada en el proceso de gestin de riesgos en proyectos de software de SAC.


23



G 2: Acrnimos CNC: Computer Numeric Control (Control numrico computarizado). CU: Caso de Uso DC: Distributed Control (Control distribuido). GR: Gestin de riesgos. HMI: Human Machine Interface (Interfase Humano Mquina). PC: Personal Computer. PLC: Programmable Logic Controller (Controlador lgico programable) SAC: Sistema de Automatizacin y Control de procesos industriales. SCADA: Supervisor Control And Data Acquisition (Sistema de supervisin y adquisicin de datos). SGR: Sistema de Gestin de Riesgos. SI: Sistema Informtico. TBQ: Taxonomy - Based Risk Identification. En el apndice G se detalla la lista completa de acrnimos.


24



CAPTULO 2 DESCRIPCIN DEL PROBLEMA

Captulo 2: Descripcin del problema

25




26



2.1 Evolucin histrica de los sistemas de automatizacin y control Para comprender mejor la naturaleza de los riesgos que aparecen durante el desarrollo de un SAC, resulta conveniente hacer un breve repaso de su evolucin. Los primeros automatismos se implementaban con elementos mecnicos entre los que podemos citar: - rboles y/o discos de levas. - Tarjetas perforadas. - Cintas perforadas. Mas tarde, los avances de la ingeniera elctrica permitieron implementar el mando por medio de relays (dispositivo electromecnico que permite abrir y/o cerrar circuitos elctricos mediante la fuerza electromagntica generada por una bobina de alambre conductor al circular una corriente dada). La lgica de control se construa interconectando adecuadamente los mismos, los enclavamientos y conexiones se representaban por esquemas funcionales elctricos. Cuando se realizaban tareas de Ingeniera o Mantenimiento de sistemas de mediano y gran tamao, la creacin, actualizacin, modificacin y lectura de estos esquemas as como su implementacin resultaban muy engorrosas. Por otro lado los relays sometidos a una frecuencia de trabajo alta comenzaban a fallar por desgaste, suciedad, falta de mantenimiento adecuado, etc. Al mismo tiempo, surgi la posibilidad de realizar lgicas de control mediante circuitos neumticos en muchas aplicaciones resultaban ms seguros que los dispositivos elctricos (por ejemplo en ambientes explosivos). Las dificultades que presentaba esta tecnologa eran similares a las de los relays. En la dcada de los 60, los transistores fueron reemplazando a los relays. Surge entonces, la posibilidad de implementar una lgica booleana de control por medio de electrnica digital, interconectando plaquetas transistorizadas que emulaban funciones AND, OR, temporizadores y memorias de estado. Estos automatismos eran mucho ms duraderos que los sistemas mecnicos, electromecnicos y neumticos, pero las tareas de mantenimiento o modificaciones resultaban muy complejas, requiriendo el uso de equipos de diagnstico muy costosos.


27



Paralelamente, la tecnologa del transistor lograba procesar seales analgicas en forma segura y econmica. Los amplificadores de seal transistorizados, mejoraban en forma significativa la lectura y control de seales continuas de proceso, como la temperatura de un reactor, el caudal, la presin de caeras, etc. En pocos aos el control electrnico de variables de procesos se fue afianzando en diversas industrias (plantas qumicas, farmacuticas, alimenticias, etc.). Todas estas tecnologas permitieron al hombre controlar eficazmente mquinas y procesos, pero a medida que estos crecan en tamao y complejidad, su rigidez al cambio se convirti en un obstculo difcil de sortear. Los proveedores de SAC iniciaron entonces la bsqueda de soluciones ms flexibles. En dcada de los 70, comenz a establecerse una nueva tecnologa que permita que la lgica de un automatismo se pudiera programar en un nuevo dispositivo electrnico denominado PLC (Programmable Logic Controller). El controlador estaba constituido por una unidad central de proceso y mdulos perifricos que permitan el ingreso o egreso de seales digitales. Al mismo tiempo, los avances realizados en computacin permitieron construir grandes sistemas de control de procesos industriales gobernados por un sistema central (similar a un Mainframe). En principio el PLC reemplazaba a los sistemas de relays procesando en forma sencilla econmica y fiable seales digitales, paralelamente los sistemas de control de proceso lograban lo mismo con seales analgicas. El control mediante PLC se convirti en sinnimo de Automatizacin industrial Los primeros PLCs utilizados en automatizacin industrial slo contaban con un nmero limitado de operaciones digitales (AND, OR, y TEMPORIZADORES), con el tiempo fueron adquiriendo la capacidad de procesar funciones matemticas complejas y manejar seales analgicas. Esto permiti que la tecnologa del PLC ingresara gradualmente al dominio de los Sistemas de control de proceso. A su vez los Sistemas de control de proceso dejaron de ser implementados mediante una gigantesca computadora central, la misma fue reemplazada por una red de pequeos procesadores intercomunicados y distribuidos a los largo de todo el proceso. Simultneamente los sistemas de control de proceso distribuido (DCS) fueron adquiriendo la capacidad de procesar adecuadamente seales digitales.


28



El desarrollo y disminucin de costos del hardware y sistemas operativos de PCs hicieron posible montar Interfaces Humano Mquina (HMI) mejorando el dilogo con el operador del proceso (mediante la visualizacin de eventos, cambios de estado y alarmas). De este modo la automatizacin industrial con su exponente ms fuerte (el PLC) y los sistemas de control de proceso fueron evolucionando y expandiendo sus lmites, hasta un punto en el cual ambos se solaparon. Actualmente ambas tecnologas se complementan, prcticamente se pueden tratar como una sola disciplina desde el punto de vista de desarrollo de software (esto no es vlido para el hardware que las soporta). En los 80, los proveedores de dispositivos de Automatizacin y Sistemas de control proceso dieron otro paso adelante al interrelacionar mediante redes de comunicacin a mquinas y procesos que hasta el momento no podan interactuar. Los protocolos de comunicacin eran hasta ese momento cerrados y variaban con el proveedor; comunicar dos sistemas de distintas marcas era una tarea difcil, slo encarada por puado de especialistas. Para evitar este problema de comunicacin, el cliente terminaba cautivo de una sola marca. A fines de esta dcada, se establecieron protocolos de transmisin de datos abiertos, elaborados en forma conjunta por los proveedores que lideraban el mercado. Estos protocolos facilitaron la comunicacin entre autmatas de distintos marcas, creando una sinergia que increment la potencia de los mismos acompaada de una baja de costos. 2.2 Estado actual de la tecnologa de Sistemas de Automatizacin y Control de Procesos Industriales Los proveedores lderes del mercado suministran equipos con hardware y herramientas de construccin de software muy fiables con prestaciones que evolucionan da a da. La incorporacin de tecnologa IT al ambiente industrial, reforz el crecimiento de los SAC, creando las condiciones propicias de desarrollo para la que los procesos industriales y los corporativos comiencen a interactuar . Los avances logrados en internet brindaron la posibilidad visualizar y controlar a miles de kilmetros mquinas y procesos en forma segura. El uso herramientas y tcnicas de Inteligencia artificial (IA) en SAC ha permitido controlar de manera eficiente y econmica complejos procesos industriales.


29



Como ejemplo de aplicacin de IA al control de proceso industrial, podemos citar el control control multi variable de lazos cerrados con capacidad de aprendizaje. La lgica de control difusa (Fuzzy Logic) combinada con redes neuronales, permiti disminuir drsticamente los tiempos de programacin y puesta en marcha de procesos de destileras. Si cada da contamos con herramientas ms potentes y amigables, nos podramos preguntar entonces: Existe algn problema grave a resolver en el dominio de SAC? Tengamos en cuenta que hasta el momento no hemos analizado los cambios que experiment en s mismo el diseador de SAC. El equipo de proyecto debi asimilar en poco tiempo las nuevas tecnologas, aprovechando el conocimiento anterior, sin que ello lo limite por la fijacin de paradigmas obsoletos. Hoy en da, el equipo de desarrollo de SAC no esta conformado por profesionales de IT que conozcan la gestin de riesgos de un proyecto de software. Al analizar su evolucin histrica, nos encontramos con que fue y es necesario contar con ingenieros / tcnicos especializados en otras disciplinas. Entre ellas podemos citar: electrnica, electricidad, mecnica y automatizacin industrial (la ltima especialidad se incorpora en la dcada de los 90). Similarmente a lo ocurrido en IT, los errores en proyectos de SAC han causando prdidas de todo tipo, debido a que el equipo de proyecto no pudo detectar a tiempo los riesgos potenciales que presentaba cada tipo de aplicacin, usuario o la propia organizacin. Es notable el gran paralelismo que existe en la evolucin de tecnologas y herramientas de desarrollo de software de IT y de SAC. En base a esta similitud, surge la pregunta: Por que no estudiar las metodologas y herramientas utilizadas en Ingeniera del Software para aprovechar, mejorar y complementar la experiencia existente, aplicando la misma al dominio de los SAC? En la siguiente seccin se describen a titulo de introduccin, los conceptos bsicos y antecedentes desarrollados en forma exitosa por la Ingeniera del Software. Para desarrollar el SGR se complementarn estos conceptos con los conocimientos de gestin de riesgos de un especialista en Automatizacin y Control industrial.


30



2.3 Conceptos bsicos y antecedentes de gestin de riesgos en proyectos de sistemas software Veamos tres definiciones que sintetizan el concepto de riesgo: Segn Webster [SEI 2004]: El riesgo es la posibilidad de sufrir prdida. En un proyecto de desarrollo, la prdida describe el impacto al proyecto que podra aparecer como la disminucin de calidad del producto final, costes crecientes, demoras en la terminacin y/o faltas. Segn Roger L Van Scoy [Van Scoy, 2001] El riesgo y la oportunidad van tomados de la mano. Muchos proyectos del desarrollo se esfuerzan en superar capacidades actuales y alcanzar algo que no se ha hecho antes. La oportunidad para el adelanto no puede ser alcanzada sin tomar riesgo. El riesgo en s mismo no es malo; el riesgo es esencial para progresar, y muchas veces forma parte del proceso de aprendizaje. Pero debemos aprender como balancear las consecuencias negativas posibles del riesgo contra las ventajas potenciales de su oportunidad asociada." Segn Shari Lawrence Pfleeger [Pfleeger, 2001] Hay dos fuentes importantes del riesgo en proyectos software: riesgos genricos y riesgos especficos del proyecto. Los riesgos genricos son comunes a todos los proyectos del software, tales como entender mal los requisitos, a la prdida de personal clave, o a dar un plazo de tiempo corto para probar el sistema. Los riesgos especficos de un proyecto: son las amenazas que resultan de las vulnerabilidades particulares del proyecto dado. Por ejemplo, un vendedor de software nos ofrece un software de red prometedor para una fecha particular, pero hay un cierto riesgo que el software de red no estar listo a tiempo La IEEE (Institute of Electrical and Electronics Engineers) brinda una lista de algunos de los errores tpicos que crean riesgos durante el proceso de construccin de Software [IEEE ,1996]:


31



- Falta de Motivacin del equipo de proyecto. - Condiciones de desarrollo poco confortables (ej. Oficinas ruidosas). - Abandono de la planificacin ante presiones. - Sumar desarrolladores al final de un proyecto atrasado. - El cliente no brinda informacin suficiente. - Horarios de trabajo excesivamente agresivos. - Recortar etapas anteriores a la codificacin (ej. Reduccin de etapa de Diseo). - Recortar tareas de aseguramiento de calidad para acelerar el proyecto. - Expectativas Excesivas o equivocadas sobre una nueva herramienta o metodologa de desarrollo. - Prdida del control de proceso de construccin. Como vemos no podemos prescindir del riesgo, pero es necesario controlar metodolgicamente el mismo. Por ello debemos eliminar o al menos reducir anticipadamente el riesgo, mediante una gestin adecuada del tema en cuestin. El SEI (Software Engineering Institute) brinda los siguientes conceptos sobre Gestin de riesgo [SEI, 2005]: La Gestin de riesgo del software es la prctica de los procesos, mtodos, y herramientas necesarios para manejar riesgos en un proyecto. Proporciona un ambiente disciplinado para la toma de decisin proactiva, determinando continuamente qu puede ir mal; determinar cuales riesgos requieren mas seguimiento y ocupacin en funcin de su importancia y que acciones tomar para ocuparse de esos riesgos. Segn el SEI una organizacin dedicada a la construccin de Software puede estar dentro de uno de los siguientes niveles de Gestin de riesgo. - Nivel 1: Gestin de crisis: El riesgo es manejado luego de que se ha transformado en un gran problema. - Nivel 2: Reparar sobre la falla Se detecta y se reacciona al riesgo pero luego que este ha ocurrido. - Nivel 3: Mitigacin del riesgo La gestin elabora un plan de contingencia que provee elementos para cubrir el riesgo si este ocurre, pero no se hace nada para eliminarlo anticipadamente.


32



- Nivel 4: Preventivo La gestin implementa y ejecuta un plan como parte de un proyecto de software para identificar riesgo y prevenir que se transforme en un problema. - Nivel 5: Eliminacin de las causas races La Gestin busca Identificar y eliminar factores de manera que el riesgo NO exista. Si la organizacin esta ubicada en uno de los tres primeros niveles muy probablemente se pierda la batalla contra los riesgos. Para ubicarse en los niveles cuatro y cinco es necesario adoptar un modelo de gestin de riesgo. A continuacin se describen Ingeniera del software. los principales modelos y estndares utilizados en

2.3.1 Modelo de Proceso de Gestin de Riesgo elaborado por Barry W. Bohm Este modelo est constituido sobre un conjunto de prcticas y actividades que necesitan ser ejecutadas continuamente, durante todo el ciclo de vida. Las mismas se resumen en el siguiente rbol [SEI, 2005]: EVALUACION DE RIESGO Identificacin de Riesgos. Anlisis de riesgo de Riesgos. Priorizacin de Riesgos. CONTROL DE RIESGO Planificacin de la Gestin de Riesgos. Resolucin del Riesgo. Monitoreo del Riesgo. 2.3.1.1 Exposicin a riesgo Una vez que se han identificado los riesgos, es necesario priorizarlos, para ello resulta conveniente cuantificar los mismos y compararlos. Barry Bohm propuso evaluar riesgos mediante la exposicin a riesgo [Bohm ,1981]:


33



RE = P( uo ) L( uo )Donde

Ecuacin 2.3.1.1

RE= Exposicin a riesgo (Risk Exposure) UO= Prdida inesperada (Unexpected outcome) P = Probabilidad L = Prdida (Loss) Por ejemplo: Supongamos que tenemos que establecer la prioridad entre dos riesgos. - Si el riesgo 1 tiene una probabilidad de ocurrencia del 5 % y si la aparicin de este riesgo retrasa cuatro semanas el cronograma entonces: RE1 = 5% * 20 das = 1 da - Si el riesgo 2 un riesgo tiene probabilidad de ocurrencia del 3 % y si la aparicin del mismo retrasa ocho semanas el proyecto en cuestin entonces: RE2 = 3% * 40 das = 3,6 das Vemos que a pesar de que el riesgo 1 es ms probable que el 2, resulta ms conveniente priorizar la atencin del segundo, dado que genera una exposicin mayor. 2.3.2 Modelo de Proceso de Gestin de Riesgo elaborado por el SEI A continuacin se resume el modelo desarrollado por el SEI [SEI, 2005], el mismo puede ser configurado de forma de ser consistente con los procesos de construccin de Software. En todas las fases del proyecto el riesgo deber ser evaluado continuamente y utilizado para tomar decisiones, el modelo identifica las seis funciones fundamentales que aseguran una Gestin de riesgo efectiva: - Identificar. - Analizar. - Planificar. - Seguir. - Controlar. - Comunicar.


34



En la figura 2.3.2 se representa la continuidad y secuencia actividades.

.

Fig. 2.3.2 Modelo SEI: Conjunto de actividades para identificar confrontar y resolver riesgos.

2.3.3 Estndar de Gestin de Riesgos IEEE 1540 Mediante una estructura similar a los modelos anteriores, el estndar IEEE 1540 efecta recomendaciones para implementar un proceso formal de gestin de riesgos exitoso. 2.3.4 Marco de desarrollo de proceso de gestin de riesgos Un proceso formal de la gestin de riesgo requiere la aceptacin corporativa del riesgo como consideracin importante para el xito del proceso. La Direccin debe apoyar las actividades de la gestin riesgo mediante: - Abastecimiento de personal y presupuesto adecuados (ej., herramientas y equipo). - Asegurar que la gerencia de proyecto recibe el entrenamiento requerido en identificar y manejar riesgos. - Asegurar que el personal del proyecto reciba el entrenamiento requerido en las tareas de gestin de riesgo que conducen. - Repaso de actividades de la Gestin de riesgo sobre una base peridica.


35



2.3.5 Identificacin de riesgo mediante cuestionario basado en su taxonoma El primer paso para gestionar el riesgo es la Identificacin del mismo, el mtodo TBQ (Taxonomy - Based Risk Identification) aporta una tcnica sencilla y a la vez exitosa se deteccin temprana [SEI ,1993]. TBQ es un cuestionario que agrupa las preguntas en clases. Las mismas se basan en la taxonoma de los riesgos en el desarrollo de software, segn IEEE una taxonoma es una particin del cuerpo del conocimiento que establece relaciones entre las partes [SEI ,1993]. Es utilizada para clasificar y entender el cuerpo del conocimiento, en la metodologa TBQ la Taxonoma es organizada en tres clases: - Ingeniera de Producto. - Ambiente de desarrollo. - Restricciones. Las clases son divididas en elementos siguiente esquema: y los elementos en atributos segn el

Clase Ingeniera del productoToma en cuenta los aspectos tcnicos del desarrollo del problema a resolver, est compuesta por cinco elementos: Elemento Codificacin y pruebas unitarias Pruebas de integracin Ingeniera especializada

Requerimientos

Diseo

Estabilidad Complejidad Atributo Claridad Validez Precedentes Escala Factibilidad Funcionalidad Dificultad Interfases Eficiencia Restricciones de hardware. Factibilidad Ambiente Pruebas Producto Codificacin Sistema ImplementacinMantenimiento Seguridad Factores humanos Especificaciones

Tabla 2.3.5.a: Clase Ingeniera del producto.


36



Clase Ambiente de desarrolloToma en cuenta el entorno y herramientas de desarrollo Elemento Proceso de desarrollo Sistema de desarrollo Proceso de gestin del proyecto Planificacin Organizacin de proyecto Experiencia en la gestin Interfases Mtodos de gestin Ambiente de trabajo

Formalidad Control de proyecto Familiaridad

Capacidad Utilidad Familiaridad Fiabilidad

Monitoreo Gestin de personal Aseguramiento de la calidad Gestin de configuracin

Actitud

Aptitud Cooperacin Comunicacin Moral

Atributo

Control del producto

Soporte Distribucin

Tabla 2.3.5.b: Clase Ambiente de desarrollo.

Clase RestriccionesToma en cuenta los factores contractuales y operacionales bajos los cuales es desarrollado el software Elemento

Recursos

Contrato

Interfases

Cliente Cronograma Atributo Tipo de contrato Staff Restricciones Presupuesto Dependencias Facilidades Proveedores Polticas Gestin cooperativa Contratista principal Contratistas asociados

Tabla 2.3.5.c: Clase Restricciones.Captulo 2: Descripcin del problema 37 Autor: Ing. Jos Luis del Ro


TBQ toma como base de su cuestionario los atributos de las tablas 2.3.5 a/b/c, las respuestas al mismo son del tipo binarias (SI / NO), las mismas brindan una identificacin temprana de riesgos. 2.4 Identificacin del problema A los problemas tpicos de todo proyecto de software, generalmente se suman las siguientes dificultades al desarrollo de Sistemas de Automatizacin: - Incremento continuo de la complejidad de los procesos a automatizar - Cronogramas de trabajo ms cortos. - Desarrollo paralelo del Software de Control con otras actividades. - Falta de especializacin del diseador de Software - Comportamiento del proceso poco predecible de antemano - Falta de formacin en procesos de Gestin de proyectos de Software y Gestin de Riesgos en Sistemas Software del especialista en automatizacin y control. - Equipos de trabajo pequeos. A continuacin se detallan cada uno de estos puntos a) Aumento de la complejidad de los procesos a automatizar En actualidad los problemas a resolver mediante SAC son cada vez ms complejos, a continuacin se enumeran las causas principales del aumento de la complejidad: 1) Los mayores requerimientos de los productos a fabricar. 2) La globalizacin y mercados ms exigentes imponen estndares de gestin de planta cada vez ms estrictos, como ejemplo podemos citar las normas impuestas por la FDA (Food and Drug Administration), la ISO (International Organization for Standardization), etc. 3) Los requerimientos ecolgicos establecen restricciones que implican mejoras en el aprovechamiento de la energa y controles de emanaciones. 4) La competencia crea la necesidad permanente de aumentar la productividad de los procesos de fabricacin. 5) Un consumidor final requiere productos de mayor calidad generando as la necesidad de implementar procesos de inspeccin y control ms elaborados (por ejemplo: sistemas de visin inteligente). 6) Mquinas flexibles que puedan adaptarse fcilmente a nuevos productos.Captulo 2: Descripcin del problema 38 Autor: Ing. Jos Luis del Ro


b) Cronogramas de trabajo ms cortos. En la actualidad las empresas deben innovar sus lneas de fabricacin permanentemente, esto obliga a que el equipo proyecto deba desarrollar el proceso de construccin de software en perodos de tiempo menores. c) Desarrollo paralelo del Software de Control con otras actividades. Cuando se inicia la construccin del Software de un SAC, normalmente se comienza con otros procesos en paralelo que implican tareas de Ingeniera Mecnica, Elctrica, Civil, etc. Si no existe un a buena interaccin entre todas las actividades se generan riesgos importantes como veremos en los siguientes ejemplos: Ejemplo 1: Cambios del diseo mecnico del proceso: Si esta situacin no es comunicada a tiempo, el equipo de desarrollo del Software del SAC se encontrar con todo tipo de problemas como accidentes, rotura de equipos, prdida de materias primas y demoras en la puesta en marcha Ejemplo 2: Errores de conexionado: Un cable mal conectado suele manifestarse a primera vista como un error del software, estos errores son difciles de detectar y prolongan la etapa de puesta en marcha de un SAC. Ejemplo 3: Tendidos de cableados inadecuados: Si la empresa responsable del tendido de cables no contempl el blindaje electromagntico adecuado de los mismos o los recorridos impuestos son muy ruidosos (cables de comando y fuerza electromotriz montados sobre una misma bandeja porta-cables), puede ser necesario inmunizar al proceso con filtros de ruido implementados mediante software (promediadores, Fuzzy Logic, tcnicas de inteligencia artificial etc.) esto genera costos mayores y demoras respecto del cronograma original. Ejemplo 4: Aumentos de velocidades del proceso: Los programas de SAC operan con tiempos de ciclo de CPU (Central Process Unit) muy cortos, del orden del las 10 milisegundos, normalmente esta orden de magnitud suele ser aceptable. Supongamos que el al final del proyecto el cliente necesita aumentar la velocidad del proceso por aumento de la demanda. Para cumplir con este requisito el sistema exige una lectura de las seales de entrada cada 2 mseg.


39



Esta mejora se puede lograrse rediseando el programa (por ejemplo: mediante instrucciones de salto o utilizando instrucciones con menor tiempo de ejecucin o recurriendo a rutinas de interrupcin). Estos cambios no son gratuitos, exigen redisear y probar nuevamente el software. d) Falta de especializacin del diseador de Software Hoy en da es difcil que un diseador de SAC pueda cubrir gran cantidad de marcas y tipos de equipos. Muchas veces un especialista en PLCs de una determinada marca se lanza a programar productos de otras empresas o modelos nuevos sin la debida capacitacin, experiencia y herramientas. e) Proceso de comportamiento poco predecible de antemano Muchas veces no existe el conocimiento de un proceso nuevo y tampoco existe la posibilidad de probarlo en una escala menor. En estos casos extremos se deben implementar una serie de metodologas de prueba que minimicen los riesgos. f) Falta de formacin en procesos de Gestin de Riesgos en Sistemas Software. Como remarcamos anteriormente: histricamente los diseadores de SAC, no provienen de sectores de IT sino que fueron formados en otras disciplinas en las cuales no es habitual contar con este tipo de conocimientos. g) Equipos de trabajo pequeos Muchos mercados no crean condiciones propicias para sostener equipos de trabajo grandes, debido a ello el diseador de SAC no tiene normalmente la posibilidad de contar con la ayuda de especialistas en gestin de riesgos dentro del grupo de desarrollo. 2.5 Solucin del problema El objetivo es implementar un Sistema asistente de gestin de riesgo que tome como base: - Metodologas de Gestin de Riesgos en Sistemas Software utilizadas en IT.


40



- Metodologas aplicadas al desarrollo y puesta en marcha de lgicas de control de automatismos y sistemas de control de proceso. - Caractersticas y datos histricos de: - La organizacin que construye la aplicacin. - El equipo de trabajo asignado al proyecto. - El proveedor de Herramientas de desarrollo de Software - El proveedor de hardware. - Las herramientas de desarrollo del software. - El cliente. - El proceso. - Otros contratistas que interactan durante el proyecto, instalacin y puesta en marcha. - Ciclo e vida del software seleccionado. - Tipo de trabajo (Sistema Nuevo, Migracin, Reciclado) En base a la informacin anterior, el Sistema SGR deber proveer las siguientes funciones: - Deteccin anticipada de riesgos. - Evaluacin del Impacto que provocara la ocurrencia del riesgo. - Determinacin de acciones preventivas necesarias para eliminar o reducir riesgo. - Priorizar acciones en base al impacto que provocan. Estas funciones se aplicarn a las siguientes etapas. - Cotizacin / Presupuesto de construccin de software. - Ciclo de vida del software. Antes de avanzar en el desarrollo de la aplicacin nos debemos preguntar:


41



Es viable la construccin del Sistema de gestin de riesgos (SGR)? Teniendo en cuenta que: 1) Existe una carencia de especialistas en gestin de riesgos de software en el mbito de SAC. 2) Actualmente, las herramientas comerciales de gestin de riesgos utilizadas en IT no cubren adecuadamente las necesidades del dominio de los SAC. Podemos afirmar que el sistema es viable, en el captulo 3 se fundamenta esta conclusin mediante el EVS.


42



CAPTULO 3 ESTUDIO DE VIABILIDAD

Captulo 3: Estudio de viabilidad

43




44



3.1 Establecimiento de alcances del Sistema Con el propsito de conocer y evaluar los alcances del proceso de Gestin de riesgos en SAC, el Ingeniero de software (IS) entrevist al responsable tcnico comercial de una empresa lder en la provisin de hardware y software de desarrollo de SAC. 3.1.1 Resumen de entrevista con el Gerente de producto (SAC) Las aplicaciones de SAC son desarrolladas por Integradores. Esta designacin describe a una empresa con una estructura tcnico administrativa encargada de comercializar y desarrollar soluciones implementadas mediante SAC. Una solucin est conformada por la provisin de: - Hardware. - Sistemas operativos. - Software de aplicacin. Dentro de las empresas que desarrollan software de aplicacin para SAC, existen pocas personas que conozcan como anticipar y gestionar los riesgos. A pesar de que estas firmas cuentan con profesionales con mucha capacitacin terica prctica desarrollada en distintos tipos de industria y con distintos perfiles de clientes, existen pocos especialistas en SAC que sepan como adelantarse y controlar los problemas inherentes a la actividad. Debido al impacto que ha tenido la ocurrencia de riesgos no detectados a tiempo, resulta clara la necesidad de ayudar a los integradores a implementar un proceso de gestin de riesgos adecuado. Dadas las caractersticas de la estructura de las empresas que desarrollan software para SAC, no resulta viable la contratacin de un especialista en la gestin de riesgos del rea en cuestin (por su escasez y por razones econmicas). Por ello el gerente de producto considera oportuno asistir a los integradores mediante un sistema de gestin automtica de riesgos que se adecue al mbito SAC. Las caractersticas del integrador, del cliente (usuario final de la aplicacin) y del proceso a automatizar / controlar determinan riesgos que pueden ser anticipados con una metodologa adecuada. En la seccin F1 (pgina 275) se detalla la planificacin y desarrollo de esta entrevista.


45



3.1.2 Identificacin del alcance del sistema En base a la introduccin brindada durante la sesin 1 y al intercambio de puntos de vista con el directivo entrevistado, surgen los siguientes alcances bsicos del sistema: 1) Cada integrador debera contar con un sistema que lo gue y asesore durante las etapas de : - Confeccin de ofertas de proyectos SAC. - Construccin de un proyecto software de aplicacin SAC. 2) Las empresas proveedoras de equipos necesitan que el sistema los asesore en: - Evaluacin de los riesgos potenciales de cada integrador. - Calificacin del integrador (nivel de riesgo). 3) Los usuarios finales de la aplicacin (clientes) deben tener la posibilidad de evaluar el riesgo que se presenta a la hora de trabajar con determinado integrador y/o proveedor de equipamiento para SAC. 4) Por lo general no existir intercambio de datos de riesgos entre integradores, puesto que lo ms frecuente es que deban competir por un proyecto . 3.1.3 Especificacin del alcance del EVS El alcance del EVS consiste en determinar si existe una aplicacin comercial que satisfaga los requerimientos de la actividad de construccin de software de SAC y compararla con la posibilidad de construir un sistema de gestin de riesgos para la actividad en cuestin. 3.2 Estudio de la situacin actual Luego de la primera entrevista con el Gerente de producto se procedi a profundizar el conocimiento del problema entrevistando a un especialista en anlisis de riesgo en sistemas SAC. Los resultados resumidos de la misma se exponen en la seccin 3.2.1 Valoracin de la situacin actual (para ms detalle ver apndice F 2, pgina 279).Captulo 3: Estudio de viabilidad Autor: Ing. Jos Luis del Ro

46


3.2.1 Valoracin de la situacin actual La falta de experiencia en evaluacin metodolgica de riesgos es un problema inherente a la mayora de los integradores. Se ha determinado que por razones de costos y competitividad resulta difcil que las empresas de integracin de SAC cuenten con especialistas en gestin de riesgos en proyectos de software. Por otro lado, los especialistas en gestin de riesgos en proyectos de tecnologa de la informacin (IT) no cuentan con la experiencia necesaria en proyectos de SAC para adaptar sus conocimientos al rea. Es necesario contar con una herramienta de evaluacin de riesgos apropiada para la actividad en cuestin. Existen excelentes metodologas y normas de evaluacin de riesgo no especializadas en SAC que podran ser tomadas como base de desarrollo de una herramienta especializada en sistemas de automatizacin y control de procesos, entre ellas podemos citar: -Modelo de Proceso de Gestin de Riesgo elaborado por Barry W. Bohm. -Std. 1540-2001 IEEE Standard for Software Life Cycle Processes-- Risk Management Description. -Modelo de Proceso de Gestin de Riesgo elaborado por el SEI. 3.2.2 Identificacin de usuarios participantes en el EVS Se consult al directivo de la empresa proveedora de equipos de SAC, quien recomend y contact al IS con un especialista y con integradores interesados en resolver el tema. 3.2.3 Descripcin de sistemas de informacin existentes Actualmente, los integradores no evalan riesgos o lo hacen sin ninguna metodologa, existen unos pocos que almacenan bases de datos los resultados de proyectos pasados, el soporte de datos en cuestin no cuenta con procedimientos predeterminados para la gestin de riesgo. Puesto que en el mercado no existen herramientas orientadas a la gestin de riesgos en SAC, el IS investig qu productos comerciales aplicados al desarrollo de software de IT existan, verificando si podan ser aplicados al rea de estudio, entre ellos se destacan tres:Captulo 3: Estudio de viabilidad 47 Autor: Ing. Jos Luis del Ro


Risk Radar: Este producto fue desarrollado sobre la base de Microsoft Access, utiliza la terminologa estndar de Gestin de riesgos, soporta el proceso prescripto por el SEI (CMM nivel 3) y el estndar 1540 de IEEE para ciclo de vida del software. El sistema permite detectar, evaluar y priorizar puntos de riesgo adems brinda sugerencias para mitigar los mismos [Risk-Radar, 2005]. SERIM: Esta aplicacin permite detectar puntos de riesgos, evaluarlos desde distintas perspectivas analticas sumando tcnicas de gestin como Just-in time [SERIM, 2004]. RIAS: El producto basado en el modelo Montecarlo, brinda informacin de contexto del riesgo, identificacin, impacto, planificacin de la gestin de riesgos, monitoreo y control [Davion-Systems, 2004]. 3.2.4 Diagnstico de la situacin actual Durante la investigacin el IS prob con el especialista en gestin de riesgos de SAC las versiones de demostracin de los productos citado, obteniendo las siguientes conclusiones: - Los tres productos permiten a un Ingeniero de Software una excelente evaluacin y seguimiento de riesgos en sistemas software de IT, pero no sucede lo mismo cuando dichas herramientas son aplicadas a sistemas de automatizacin y control de procesos industriales. - La falta de especializacin en el rea de SAC no permite una utilizacin directa y sencilla a los desarrolladores de aplicaciones de automatizacin y control de mquinas y procesos industriales. 3.3 Definicin de requisitos del sistema Para definir los requisitos del sistema se tomaron como base: - Estndares y metodologas de Gestin de Software desarrollados por la Ingeniera del Software. - Estndares y metodologas de programacin impuestos de hecho por las marcas lideres. - Las entrevistas realizadas con los directivos y especialistas en la materia.


48



3.3.1 Definicin de directrices tcnicas y de gestin Se ha adoptado METRICA 3 como metodologa de gestin. 3.3.2 Definicin de requisitos especficos Tomando como base las necesidades presentadas por el directivo y el especialista entrevistados, las metodologas de gestin de riesgos disponibles en la Ingeniera del Software y las herramientas comerciales disponibles para Gestin de riesgos (no especializadas en SAC), podemos establecer el modelo de casos de uso del SGR: SGRCU 4: Configuracin el SGR Administrador SGR

CU 1: Evaluacin de riesgos

CU 2: Control de riesgos

Usuario SGR

CU 3: Evaluacin calidad de proceso de gestin de riesgos

Cliente

Integrador

Proveedor

Figura 3.3.2 Diagrama de casos de uso del SGR

Descripcin de actores: Usuario SGR: Persona que quiere ejecutar un proceso de gestin de riesgo. Administrador SGR: Persona entrenada en la configuracin del SGR, con slidos conocimientos de gestin de riesgos, hereda todos los derechos del Usuario SGR.


49



Caso de uso Evaluacin riesgos Nombre ID Actor relacionado Frecuencia mxima - Evaluacin riesgos - CU 1 - Usuario SGR - 10 evaluaciones por da. - En base al contexto en el que se desarrolla el proyecto y a los parmetros del SGR, el sistema deber estimar los riesgos del mismo, estableciendo cuales requieren atencin prioritaria. El contexto ser ingresado al sistema segn la taxonoma de riesgos de un proyecto SAC, de manera de ir guiando al usuario en el relevamiento de datos necesarios para una evaluacin de riesgos fiable. Los datos ingresados como valores lingsticos (preestablecidos) se transforman en valores numricos que sern utilizados para estimar la exposicin a riesgo (segn frmula de Bohm). - SGR parametrizado. - Recopilacin de caractersticas de: Cliente, Integrador (empresa que desarrolla el software), Proveedor de equipos SAC, Terceros que participan del proyecto, Hardware, Herramientas de desarrollo, Proceso y Proyecto. - Perfil exposicin a riesgos del proyecto: Determinado - Riesgos prioritarios: Identificados y ordenados. - El Usuario SGR solicita evaluacin de riesgos de un proyecto. - El SGR termin proceso de evaluacin de riesgos. - Ingreso de datos (valores lingsticos preestablecidos) de contexto segn la taxonoma de riesgos de proyectos SAC. - Conversin de valores lingsticos a valores numricos. - Estimar exposicin a riesgos del proyecto. - Determinar el perfil de riesgos del proyecto. - Identificar los cinco riesgos prioritarios. - Priorizar riesgos segn su exposicin. - Solicitar ms datos

Descripcin

Precondicin

Postcondicin Evento de inicio Evento de finalizacin

Escenario principal

Escenario alternativo

Observaciones - Ver figura 3.3.2Tabla 3.3.2.a caso de uso Evaluacin de riesgosCaptulo 3: Estudio de viabilidad 50 Autor: Ing. Jos Luis del Ro


Caso de Uso Control de riesgos Nombre ID Actores Frecuencia mxima - Control de riesgos. - CU 2 - Usuario SGR - 10 evaluaciones por da.

Descripcin

- En base al perfil de riesgos obtenidos de la evaluacin de riesgos, se sugiere al usuario la secuencia de atencin y las acciones a seguir para eliminar, mitigar o transferir los mismos.

Precondicin

- Perfil exposicin a riesgos del proyecto: Determinado. - Riesgos prioritarios: Determinados y ordenados.

Post condicin

- Secuencia de actividades: Determinada - Descripcin de soluciones: Completa

Evento de inicio Evento de finalizacin Escenario principal Escenario alternativo

- El Usuario SGR solicita controlar riesgos. - El SGR ha terminado la planificacin. - Buscar soluciones para los cinco riesgos principales. - Planificar acciones de control de riesgo. - Solicitar ms datos

Observaciones - Ver figura 3.3.2Tabla 3.3.2.b caso de uso Control de riesgos


51



Caso de uso Evaluacin del proceso de gestin de riesgo Nombre ID Actor Frecuencia mxima - Evaluacin del proceso de gestin de riesgos. - CU 3 - Usuario SGR - 10 evaluaciones por da. - La correcta estimacin del perfil de riesgo del proyecto requiere una cantidad determinada de informacin sobre los datos de contexto. El SGR debe tener en cuenta los datos esenciales para que el anlisis de riesgo sea acertado. El usuario debe conocer que tan fiable es la evaluacin y el sistema debe aconsejar sobre los pasos a seguir para mejorar la calidad del proceso de gestin de riesgo. - El usuario SGR ha ingresado los datos del contexto en el que se desarrolla el proyecto.

Descripcin

Precondicin

- Fiabilidad del proceso de gestin de riesgos: Evaluada Post condicin - Sugerencias para mejorar la fiabilidad del anlisis de riesgo: Propuestas Evento de inicio Evento de finalizacin Escenario principal Escenario alternativo - Usuario SGR solicita evaluacin de calidad de la gestin de riesgos. - El SGR ha evaluado la calidad del a gestin de riesgos. - Evaluar si los datos ingresados son suficientes. - Determinar el nivel de calidad de la gestin de riesgo. - Solicitar ms datos

Observaciones - Ver figura 3.3.2Tabla 3.3.2.c caso de uso Evolucin del proceso de control riesgos


52



Caso de uso Configuracin del SGR Nombre ID Actor Frecuencia mxima - Configuracin del SGR - CU 4 - Administrador SGR - Una vez cada dos aos.

Descripcin

- En base a los datos histricos de riesgos ocurridos durante el desarrollo de proyectos SAC, se ingresan valores estadsticos de probabilidad e impacto que el SGR utilizar para estimar la exposicin a cada uno de los riesgos tpicos de un proyecto SAC en un mercado o pas determinados.

- Clave de administrador de SGR Precondicin - Recopilacin de: datos estadsticos de probabilidad de ocurrencia de un riesgo tpico de proyectos SAC y valores promedio de impacto.

Post condicin - SGR parametrizado. Escenario principal Escenario alternativo 1 Escenario alternativo 2 - Control de acceso. - Ingreso y o modificacin de parmetros. - Acceso denegado - Avisar al usuario que la clave es incorrecta - Solicitar al administrador : completar datos faltantes - Asignar valores por defecto a los datos faltantes.

Observaciones - Ver figura 3.3.2Tabla 3.3.2.4 caso de uso Configurando SGR


53



3.3.3 Requisitos de usuario Los usuarios que utilizarn el sistema sern integradores, clientes o proveedores de equipos SAC con o sin experiencia en gestin de riesgos. El manual del usuario debe ser claro permitiendo que una persona sin conocimientos de gestin de riesgos pueda conocer los mismos y aplicar las soluciones sugeridas. 3.3.4 Requisitos de tecnolgicos El SGR debe ser capaz de correr sobre una PC equipada con sistemas operativos Windows 2000 y Windows XP. 3.3.5 Requisitos de interfases 3.3.5.1 Interfases de usuario Las interfases de usuario deben ser amigables y permitir la ayuda on-line de manera de evitar el uso de manuales impresos. 3.3.5.2 Interfases hardware No han sido definidas. 3.3.5.3 Interfases software En esta etapa de desarrollo del SGR no son necesarias. Teniendo en cuenta versiones posteriores, el lenguaje de edicin de cdigo seleccionado debe dejar abierta la posibilidad de lectura y/o escritura en una base de datos externa. 3.3.5.4 Interfases de comunicacin En esta etapa de desarrollo del SGR no son necesarias. 3.3.6 Requisitos de desarrollo - Ciclo de vida: Prototipo evolutivo. - Sistema flexible fcil de mantener, modificar y o ampliar. - Herramientas de desarrollo de bajo costo.


54



3.3.7 Requisitos de rendimiento El sistema debe permitir la evaluacin de 20 proyectos por da. 3.3.8 Requisitos de diseo 3.3.8.1 Ajuste a estndares Estndares propios del rea de aplicacin: - Estndares de seguridad industrial. - Estndares de automatizacin industrial. - Estndares de control de procesos industriales. Estndares propios del desarrollo de software: - MTRICA 3 (desarrollo orientado a objetos) 3.3.9 Atributos 3.3.9.1 Seguridad: El acceso a la parametrizacin del SGR debe ser restringido a administradores previamente entrenados en la configuracin del sistema. 3.3.9.2 Mantenimiento: El mantenimiento del sistema ser responsabilidad del departamento de informtica de la empresa que utilice el SGR. El Sistema debe estar claramente estructurado, comentado y documentado. 3.4 Estudio de alternativas de solucin 3.4.1 Preseleccin de alternativas de solucin En la tabla siguiente se comparan las alternativas disponibles, en ellas podemos observar que la alternativa ms conveniente es la 5. El resto de las alternativas no cumple con los requisitos del sistema debido a su falta de especializacin en SAC.


55



Alternativa Base de datos sin procedimientos de gestin de riesgos programados

N

Producto Base de datos (por ejemplo Access)

Ventajas

Desventajas Solo almacenan datos sin ningn tipo de gestin No estn especializadas en el desarrollo de SAC

1

Bajo costo

2 Sistema de Gestin de riesgos en proyectos Software comerciales 3 4

Risk radar SERIM RIAS

Se basan en modelos y estndares ampliamente probados en la Gestin de riesgos de Software

Desarrollo de Sistema de Gestin de Riesgos especializado en SAC que tome como base modelos de gestin de riesgos ya utilizados en IT

5

SGR

Especializacin

Se debe desarrollar y probar la herramienta

Tabla 3.4.1: Preseleccin de alternativas.

3.4.2 Descripcin de alternativas de solucin La nica alternativa viable es la 5 dado que el resto no cumple con los requisitos que impone el desarrollo de una aplicacin de SAC. El SGR debe ser capaz de asesorar al integrador de SAC, al proveedor y al usuario final, manteniendo el riesgo acotado y alertando sobre desvos peligrosos a lo largo de todo el ciclo de vida de la aplicacin SAC. 3.5 Valoracin de alternativa preseleccionada 3.5.1 Estudio de riesgos La alternativa 5 presenta los riesgos inherentes a todo proyecto nuevo, los mismos sern minimizados y controlados gracias a una adecuada planificacin (PROCESO PRINCIPAL METRICA 3) y gestin del proyecto (Interfases METRICA 3).


56



Como puntos favor de la viabilidad del proyecto podemos citar: la ayuda de un especialista reconocido y metodologas de gestin de riesgos que han sido aplicadas con mucho xito en otros tipos de proyectos de software (no especializados en SAC) que pueden ser adaptados al rea en cuestin. Para verificar si la percepcin anterior es cierta, se realiza un estudio ms detallado de factibilidad del SGR 3.5.2 Estudio de Factibilidad del SGR Se realiz una nueva entrevista al especialista en SAC para evaluar si la alternativa 5 puede resultar una solucin viable. Se le pidi al especialista que evale el grado de conocimiento en gestin de riesgos que tienen los integradores, para ello determin tres niveles de experiencia (alto, medio y bajo). Luego de esta evaluacin se comprob que muy pocos desarrolladores de aplicaciones SAC, cuentan con la formacin y experiencia necesarias para levar adelante un proceso de GR. Los resultados generales del estudio se grafican en la figura 3.5.1 (para ms detalle ver sesin 3 seccin F3, pgina 283).

Experiencia

Alto

Medio Bajo

A B C3 100 1000 Nro. de personas

Figura 3.5.2

Distribucin de experiencia en gestin de riesgos en SAC.


57


3.5.3 Conclusiones del EVS La construccin del SGR es viable debido a dos razones bsicas: 1) Debido a su falta de especializacin los sistemas de Gestin de riesgos comercializados actualmente no tienen un buen desempeo si se lo utiliza en el dominio de SAC. 2) La figura 3.5.2 (pgina 57) nos indica que la experiencia en gestin de riesgos en SAC est concentrada en unos pocos especialistas muy experimentados, resulta muy conveniente, asistir al resto de los participantes con un sistema que automatice esta tarea y que gue a los Integradores que no cuentan con la experiencia necesaria para gestionar adecuadamente los riesgos propios del negocio.


58


CAPTULO 4 ANLISIS DEL SISTEMA DE INFORMACIN


59



Captulo 4: Anlisis del SI

60




61



4.1 Definicin del Sistema 4.1.1 Determinacin del alcance del sistema En la figura 4.1.1 se esquematizan las funciones a cumplir por el SGR:

GESTION DE RIESGOS

F1: Evaluacin de riesgos (CU 1)

F2: Control de riesgos (CU 2)

F3: Evaluar calidad de GR (CU 3)

F4: Configurar GR (CU 4)

F11: Identificacin de riesgo F12: Anlisis de Riesgo F13: Priorizar de riesgo

F21: Planificacin de GR F22: Monitoreo de Riesgo

Figura 4.1.1: Funciones del SGR

Para ms detalle ver apndice F11 (pgina 338). 4.1.2 Identificacin del entorno tecnolgico Debido a las requisitos de instalacin de los paquetes de desarrollo de aplicaciones de automatizacin, los integradores y proveedores de equipamiento de SAC cuentan al menos con el siguiente entorno tecnolgico: - Sistema operativo Windows 2000 o XP. - Procesador Pentium III. - Capacidad de memoria RAM 256 MB. - Disco rgido 80 GB. - MS Office Professional.


62



4.1.3 Especificacin de estndares y normas En base a los estudios realizados sobre el tema de gestin de riesgos en proyectos de software de IT (no especializados en SAC) podemos destacar: - Modelo de gestin de Riesgo de proyectos Software de Bohm: [Bohm, 1989]. - Modelo de Gestin de Riesgos del SEI (Software Engineering Institute) [SEI, 2005]. - Estndar de Gestin de Riesgos en proyectos Software IEEE 1540 [IEEE, 1989]. No existen modelos ni estndares de gestin de riesgos especficos para SAC 4.1.4 Identificacin de usuarios participantes y finales Durante la primera entrevista se han identificado los siguientes usuarios: 1) Integrador certificado de un Equipo de SAC. 2) Integrador NO certificado de Equipos de SAC. 3) Proyectista de aplicaciones de SAC propios de la empresa que fabrica el equipo. Se realiz una cuarta entrevista con el Especialista quien brind las siguientes caractersticas de los usuarios del SGR (ver detalle en seccin F4, pgina 286): 1) Integrador certificado de un Equipo de SAC Es una empresa con capacidad tcnico - administrativa para desarrollar el software que comercializa, construyendo soluciones de automatizacin y control basadas en: - PLC: (Controlador lgico programable). - HMI: (Interfase humano - mquina). - SCADA (Sistema de supervisin y adquisicin de datos). - CNC: (Control numrico). - LAN: (Red de rea local). - WAN: (Red de rea amplia). - Sistemas de Visin inteligentes. - Robots.


63



Dependiendo del nivel de conocimientos del integrador, existen empresas que cubren todos los elementos citados en la lista y existen otras que cubren slo una porcin de la misma. Por lo tanto la estructura y grado de especializacin de cada Integrador puede ser muy diferente. Dentro de las tareas que debe realizar el Integrador podemos citar - Comercializacin de Hardware de SAC. - Comercializacin de Aplicaciones de SAC. - Presupuestos de Soluciones SAC (Hardware + Software de desarrollo y aplicacin). - Construccin de Software de Aplicacin SAC. El objetivo del Integrador es proveer soluciones de automatizacin industrial a un cliente final, si tuvo experiencia en procesos similares a los que maneja el cliente, corre con ventaja frente a otros integradores que no la tienen. Por ejemplo si el integrador desarroll software para sistemas de inyeccin de plstico cuenta con un conocimiento que le permitir reducir los riesgos en el caso de una especificacin incompleta. Un Integrador certificado por la empresa proveedora de equipos SAC debe cumplir con una serie de exmenes tcnicos anuales que garanticen sus conocimientos acerca del producto que van a comercializar y programar. Adems es sometido peridicamente a auditorias administrativas y financieras que verifican el buen estado econmico-financiero de la empresa. El Integrador certificado cuenta con ventajas a la hora de capacitar a su personal, dada la estrecha relacin que se establece con la empresa proveedora de equipos y el respaldo tcnico econmico que le brinda la misma. Este punto es importantsimo dado que la obsolescencia de los conocimientos se produce en muy poco tiempo debido a la rpida y continua evolucin de los SAC. El cliente final cuenta con una garanta de la empresa proveedora de equipos SAC que asegura la calidad y respaldo del Software producido por el Integrador certificado. Dada la gran cantidad de aplicaciones que desarrolla un integrador, el volumen de compra de este ltimo llega muchas veces a ser muy superior al de una gran industria. Por lo tanto los integradores, adems de suministrar mano de obra


64



especializada, se convirtieron en los ltimos aos en uno de los principales clientes de las empresas proveedoras de equipos de SAC. 2) Integrador NO certificado de un Equipo de SAC Es una empresa con caractersticas similares a la del integrador certificado., la mayor diferencia radica en que la empresa proveedora no puede certificar la calidad y respaldo del software que construye. Suelen trabajar con varias marcas de sistemas SAC permitindoles en muchos casos un mayor espectro de clientes, esto implica que sus conocimientos deben ser ms amplios, muchas veces esta amplia cobertura trae como consecuencia el conocimiento parcial del producto comercializado. En muchos casos la calidad de su trabajo queda garantizada por la trayectoria que han tenido en el mercado, reemplazando la certificacin otorgada por el proveedor de equipos SAC. Se debe tener en cuenta que si el cliente final no conoce al Integrador el hecho de estar o no certificado puede brindarle una garanta sobre la solucin que est adquiriendo. 3) Proyectista de aplicaciones de SAC propios de la empresa que fabrica el Equipo Como se mencion en la entrevista N 1 las empresas proveedoras de equipamiento y software de desarrollo de SAC han dejado de construir el 100 % del software de aplicacin. El cambio de cambio estratgico que implica su asociacin con Integradores de Sistemas SAC les permite ofrecer a sus clientes finales, costos de desarrollo ms competitivos. Pero deben contar con una slida experiencia en el desarrollo de aplicaciones de manera de poder afianzar los conocimientos necesarios para respaldar / asesorar a los integradores y a los clientes finales, debido a ello cuentan en su equipo de desarrollo con proyectistas muy especializados que disean sistemas de gran complejidad y envergadura. 4.2 Educcin del proceso de gestin de riesgos en SAC Una vez conocidos las caractersticas, alcances y factibilidad de desarrollo del SGR se procedi a realizar una nueva serie de entrevistas que se completaron con


65



la observacin de la actividad del especialista en un caso real. El objetivo era conocer con ms profundidad el proceso de gestin de riesgos en SAC. 4.2.1 Planificacin de entrevistas En las tablas 4.2.1.a y 4.2.1.b se resume la planificacin inicial de las sesiones de educcin de requisitos.

Preparacin de sesin ActividadFijar contenido de la sesin Fijar tamao del grano de los conocimientos Fijar Tcnica de educcin a utilizar.

Sesin 5Descripcin general de la gestin de riesgos en SAC. Buscar perspectivas Grueso

Sesin 6Detalle de terminologa utilizada

Sesin 7Conocer ms detalladamente el proceso de Gestin de riesgos Fino

Fino

Entrevista abierta Ver Apndice F Seccin F5 Pgina 289 Detalle Sesin 5 25/2/2005

Entrevista abierta Ver Apndice F Seccin F6 Pgina 297 Detalle Sesin 6 3/3/2005

Entrevista estructurada Ver Apndice F Seccin F7 Pgina 303 Detalle Sesin 7 15/3/2005 8 hs con cuatro breaks de 15 mtos y uno de 1 hora 8 hs Planta Industrial Nro 3

Preparacin de preguntas

Fecha programada

Duracin programada

3 hs con un break de 3hs con dos break de 15 mtos 15 mtos

Duracin real

4hs Administracin Central Sala A

5 hs Administracin Central Sala A

Lugar

Tabla 4.2.1 a: Preparacin de sesiones 5,6 y 7.


66



Preparacin de sesin Actividad Sesin 8Observacin de un caso real de GR en un proyecto de SAC

Sesin 9Despejar dudas sobre lo observado en sesin 8

Sesin 10Origen de frmula de clculo de probabilidad de ocurrencia de riesgo Fino

Sesin 11Construir un diagrama de funciones del proceso de gestin de riesgos en SAC Fino

Fijar contenido de la sesin Fijar tamao del grano de los conocimientos

Fino

Fino

Grabacin, Transcripcin y Fijar Tcnica segmentacin de de educcin a la actividad utilizar. desarrollada por el especialista Preparacin de preguntas Fecha programada Duracin programada Duracin real Lugar Ver Apndice F Seccin F8 Pgina 312 Detalle Sesin 8 22/3/2005

Entrevista estructurada

Entrevista abierta

Entrevista estructurada

Ver Apndice F Ver Apndice F Ver Apndice F Seccin F9 Seccin F10 Seccin F11 Pgina 319 Pgina 335 Pgina 338 Detalle Sesin 9 Detalle Sesin 10 Detalle Sesin 11 25/3/2005 3/4/2005 2 hs sin break 2 hs Administracin Central Sala A 10/3/2005 6 hs con dos break de 15 mtos 8 hs Administracin Central Sala A

8 hs con tres 5 hs con dos break de 30 mtos break de 15 mtos 8hs Planta Industrial Nro 3 y oficinas del integrador "B" 8 hs Administracin Central Sala A

Tabla 4.2.1.b: Preparacin de sesiones 8 a 11.

En el apndice F se detallan las sesiones 5 a 11 en el mismo se describe: - Preparacin de preguntas. - Repaso de anlisis de sesin anterior. - Transcripcin de la entrevista. - Resumen y comentarios del especialista. - Anlisis de sesin.Captulo 4: Anlisis del SI 67 Autor: Ing. Jos Luis del Ro


4.2.2 Resumen de estrategia del proceso de GR En base a los conocimientos educidos durante las entrevistas se ha determinado que el es

Del Rio Tesisdemagister

Documents

Transcript of Del Rio Tesisdemagister