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
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.
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
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
NDICE
SECCIN 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
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
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
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

EVS
ASI
DSI
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

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 producto

Toma 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 Implementacin
Mantenimiento Seguridad Factores humanos Especificaciones
Tabla 2.3.5.a: Clase Ingeniera del producto.
36
Clase Ambiente de desarrollo

Toma 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 Restricciones
Toma 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: SGR
CU 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.2

Tabla 3.3.2.a caso de uso Evaluacin de riesgos
Captulo 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

Tabla 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

Tabla 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.

Tabla 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
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
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
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 C
3 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 Actividad

Fijar contenido de la sesin Fijar tamao del grano de los conocimientos Fijar Tcnica de educcin a utilizar.
Sesin 5
Descripcin general de la gestin de riesgos en SAC. Buscar perspectivas Grueso
Sesin 6
Detalle de terminologa utilizada
Sesin 7
Conocer 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 8

Observacin de un caso real de GR en un proyecto de SAC
Sesin 9
Despejar dudas sobre lo observado en sesin 8
Sesin 10
Origen de frmula de clculo de probabilidad de ocurrencia de riesgo Fino
Sesin 11
Construir 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 especialista basa su estrategia en tres actividades principales: - Evaluacin de riesgos. - Control de riesgos. - Monitoreo de riesgos. Evaluacin de riesgos: El especialista considera que la combinacin entre las caractersticas de ciertos generadores potenciales favorece la aparicin de un riesgo, estos son: - El integrador. - El cliente. - El proveedor de SAC. - Terceros involucrados en el proyecto. - El proceso. - El Hardware. - Las herramientas de desarrollo de software. - El contrato. - El proceso. El conocimiento del contexto en el que se desarrolla el proyecto, permite estimar la probabilidad de ocurrencia de riesgos tpicos en un proyecto SAC. Cada tipo de riesgo tiene un impacto conocido de antemano (establecido en base a la experiencia del especialista), ambas variables permiten evaluar la exposicin a riesgo. Control de riesgos: El especialista centra los esfuerzos de control en los riesgos prioritarios (los ms probables y de mayor impacto), sugiriendo soluciones que permitan eliminar, mitigar o trasladar el riesgo. Monitoreo de riesgos: Los procesos de evaluacin y control de riesgos deben ejecutarse a lo largo de todo el ciclo de vida del software del SAC, por ello se debe verificar que las soluciones sugeridas sean implementadas y verificar en que medida disminuyen los riesgos.
68
4.3 Modelizacin del sistema En base a la informacin obtenida durante el proceso de educcin de requisitos (ver 4.2 / apndice F) y a las metodologas / modelos de gestin de riesgos utilizadas en otras reas de la ingeniera del software se estableci un modelo que permite especificar y representar el sistema SGR. El modelo est compuesto por: - Clases, asociaciones y atributos (seccin 4.3.1). - Diagrama entidad relacin (seccin 4.3.2). - Casos de uso (seccin 4.3.3). - Frmulas (seccin 4.3.4). - Descripcin de inferencias (seccin 4.3.5). - Definicin de Interfases de usuario (seccin 4.3.6). A continuacin se describe cada componente del modelo . 4.3.1 Identificacin de clases, asociaciones y atributos A partir de la informacin obtenida durante el proceso de educcin, se identifican las siguientes clases. Clases: Cliente, Contrato, Hardware, Herramientas de desarrollo, Integrador, Proceso, Proveedor, Proyecto, Riesgo, Solucin, Tercero. Atributos: - Cliente: Actividad, Capacidad de coordinacin, Conocimientos del proceso, Conocimientos en Seguridad industrial, Flexibilidad, Estado econmicofinanciero, Estructura, Nombre, Ubicacin. - Contrato: Clusulas, Cdigo, Especificaciones, Flexibilidad, Nombre, Tipo, Estado. - Hardware: Cdigo, Conectividad, Costo, Fiabilidad, Nombre, Respaldo, Tecnologa, Tipo.
69
- Herramientas de desarrollo: Amigabilidad, Cdigo, Costo, Control de configuracin, Diseo arquitectnico, Fiabilidad, Nombre, Manejo integral del proyecto. - Integrador: Carga de trabajo, Estado econmico-financiero, Estructura Experiencia (en PLC, HMI, SCADA, Accionamientos, PC, redes y Seguridad industrial), Gestin de proyectos, Nivel de remuneracin. - Proceso: Conocimiento actual, Cantidad (de entradas / salidas digitales y analgicas, pantallas), Complejidad, Estado, Especificaciones, Nombre, Peligrosidad, Requerimientos (Control combinacional, secuencial, de velocidad, de posicin, PID, Similitud, Temperatura, Tipo). - Proveedor: Nombre, Cdigo, Estructura, Estado econmico-financiero, Tiempo de respuesta, Servicios de postventa generales, Servicio de postventa locales, Servicios de capacitacin. - Proyecto: Nombre, Cdigo, Etapa actual, Esfuerzo estimado, Esfuerzo real, Avance, Equipo asignado, Inicio, Fin. - Riesgo: Nombre, Cdigo, Probabilidad, Impacto econmico, Impacto tcnico, Impacto ecolgico, Impacto en la seguridad, Exposicin a riesgo, Etapa afectada., Prioridad. - Tercero: Nombre, Cdigo, Estructura, Estado econmico-financiero, Capacidad tcnica, Actividad, Gestin de proyectos, Comunicacin. Asociaciones: Comanda, Compra, Soporta. Sugiere. Fabrica, Genera, Impacta, Modifica, Negocia,
4.3.2 Diagrama entidad - relacin. Para detectar las entidades y relaciones que surgen durante el proceso de construccin de un proyecto SAC, analizaremos la siguiente descripcin del especialista que sintetiza el mismo.
70
Durante la etapa de cotizacin el cliente y el integrador debern negociar antes de establecer el contrato. El cliente y el integrador firman un contrato. El integrador construye el proyecto del software que comandar el proceso a automatizar. Tanto el tercero que realiza la obra civil y mecnica como el integrador modifican el proceso (existente o nuevo). El proveedor fabrica hardware y herramientas de desarrollo que suministra al integrador luego de la compra de las mismas El Hardware soportar el Proyecto software que construye el integrador. El integrador edita el proyecto software mediante las herramientas de desarrollo. A lo largo del ciclo de vida del el integrador, el cliente, el tercero, el proveedor, el contrato y el hardware generan riesgos. El integrador implementa las soluciones destinadas a controlar los riesgos. En la descripcin se subrayan las entidades detectadas y se remarcan en negritas las relaciones establecidas. En base a la misma, podemos determinar que durante el desarrollo de un proyecto de software para SAC, participan las siguientes entidades: Cliente, Contrato, Hardware, Herramientas de desarrollo, Integrador, Proceso, Proveedor, Proyecto, Riesgo, Solucin, Tercero. Podemos observar que las entidades detectadas coinciden con las clases identificadas en la seccin 4.3.1. Por lo tanto comparten los atributos identificados en la dicha seccin. Dichas entidades se asocian por las relaciones: Construye, Controla, Comanda, Compra, Edita, Fabrica, Firma, Genera, Implementa, Negocia, Modifica, Soporta.
71
En la figura 4.3.2 se representan las relaciones entre entidades de un proyecto SAC.

Comanda Construye
Proyecto Software
Impacta
Edita Soporta Genera
Hardware
Riesgos
Controla
Fabrica Herramientas de desarrollo Genera
Proveedor
Compra Suministra Genera Genera Genera Genera
Integrador A
Contrato
Cliente
Tercero
Modifica
Firma Negocia Implementa
Firma
Suministra
Proceso
Comanda Modifica
Relacin uno a uno Relacin uno a muchos Relacin muchos a muchos
Solucin
Figura 4.3.2: Diagrama entidad-relacin del proceso de gestin de riesgos en SAC.
72
4.3.3 Casos de uso Durante la sesin 11 el IS identific las funciones principales y sub-funciones de un proceso de gestin de riesgos en SAC (ver seccin F11, pgina 338). Para sintetizar las mismas se recurri a la tcnica de representacin mediante casos de usos, en la figura 4.3.3.a, se describen los paquetes que componen el sistema SGR: CU 0 Gestionar riesgos CU 1 Evaluacin de riesgos CU 11
Identificacin de riesgos basada en taxonoma SAC
CU 12
Anlisis de riesgo
CU 13
Priorizar riesgo
CU 2 Control de riesgos CU 21
Planificacin de la gestin de riesgos.
CU 22
Monitoreo de riesgos
CU 3 Evaluacin de calidad de la gestin de riesgos
CU 4 Parametizacin del SGR
Figura 4.3.3.a Representacin de paquetes del SGR
73
Nivel alto de abstraccin
Nivel medio de abstraccin
Nivel bajo de abstraccin
Figura 4.3.3.b Simbologa utilizada en la representacin de paquetes.
A continuacin veremos los diagramas de los a casos de uso contenidos en los paquetes que representan al SGR.
CU 1
CU 22 Monitoreo de riesgo
Evaluacin de riesgo
CU 11: Identificar riesgo
Usuario SGR
CU 12: Analizar riesgo
CU 13: Priorizar riesgo CU4 Parametrizacin Del SGR
Figura 4.3.3.b Caso de uso Evaluacin de riesgo
74
CU 11 Identificar riesgo
CU 111: Identificacin de caractersticas del NTEGRADOR
CU 112: Identificacin de caractersticas del CLIENTE

CU 1110: Inferir valores numricos del contexto de proyecto
Usuario SGR
CU 113: Identificacin de caractersticas del PROVEEDOR
CU 12 Analizar riesgo
CU 114: Identificacin de caractersticas del CONTRATO
CU 115: Identificacin de caractersticas del PROCESO CU 116: Identificacin de caractersticas de TERCERO CU 117: Identificacin de caractersticas del PROYECTO
CU 118: Identificacin de caractersticas del HARDWARE
CU 119: Identificacin de caractersticas del HERRAMIENTAS DE DESARROLLO
Figura 4.3.3.c Caso de uso Identificacin de riesgos basada en taxonoma de SAC
75
CU 12 Analizar riesgos
CU 11 Identificacin de riesgos
CU 121: Estimar esfuerzo
CU 4 Parametrizacin de SGR
CU 122: Calcular probabilidad de ocurrencia de riesgos
Usuario SGR
CU 123: Calcular exposicin a riesgo
CU13 Priorizar riesgos
Figura 4.3.3.d Caso de uso Analizar riesgos
CU 13 Priorizar riesgos
CU 131: Ordenar riesgos en base a valor de RE
CU 12 Analizar riesgos
Usuario SGR
CU 132: Seleccionar los cinco riesgos con mayor RE
CU 2 Control de riesgos
Figura 4.3.3.e: Caso de uso Priorizar riesgos
76
CU 2
Control de riesgos
CU 13 priorizar riesgos CU 21: Planificar gestin de riesgo
CU 22: Monitoreo de riesgos Usuario SGR
Figura 4.3.3.f: Caso de uso Control de riesgos
CU 21
Planificar gestin de riesgos
CU 13 Priorizar riesgos
CU 211: Buscar soluciones para los factores de riesgos ms importantes
CU 212: Proponer secuencia de implementacin de soluciones Usuario SGR
Figura 4.3.3.g: Caso de uso Planificar gestin de riesgos
77
CU 22
Monitoreo de riesgo
CU 221: Actualizar datos de cuestionario TBQ-SAC. Usuario SGR CU 222: Disparar nuevo proceso de gestin de riesgo. CU 12 Analizar riesgos
Figura 4.3.3.h: Caso de uso Monitoreo de riesgos
CU 3
Evaluacin de calidad de la gestin de riesgos CU 31: Controlar datos esenciales
CU 32: Contabilizar cantidad de datos
Usuario SGR
CU 33: Inferir calidad de la gestin de riesgos
Figura 4.3.3.i: Caso de uso Evaluacin de calidad de la gestin de riesgos
78
CU 4
Parametrizacin del SGR CU41: Edicin de pesos W de los factores de riesgo
Administrador SGR
CU 42: Edicin de constates K Peso estadistico de cada riesgo C 43: Edicin de prdidas CU 1 Evaluacin de riesgo
C44: Calcular prdidas promedio
Figura 4.3.3.j: Caso de uso Parametrizacin de SGR
Actores: Los actores Usuario SGR y Administrador SGR han sido definidos en el captulo anterior. El resto de los actores se corresponde con los subsistemas representados por los casos de uso. Descripcin de casos de uso: A continuacin se detallan los casos de uso de nivel medio y bajo (los de alto nivel fueron descriptos en el captulo anterior).
79
Caso de uso Identificacin de riesgos Nombre ID Nivel de abstraccin Incluido en Actor principal Identificacin de riesgos. CU 11 Medio Paquete CU1 evaluacin de riesgos. Usuario SGR
Actor secundario Subsistema CU 2 Analizar riesgo Frecuencia mxima 10 evaluaciones por da. Tomando como base la idea de un cuestionario basado en la taxonoma de riesgos (TBQ) y la experiencia del especialista, se desarrolla un cuestionario especializado en SAC (TBQSAC). En el mismo se agrupan las caractersticas del Descripcin proyecto en las clases CONTRATO, CLIENTE, INTEGRADOR, PROVEEDOR, TERCERO, PROYECTO, PROCESO, HARDWARE y HERRAMIENTAS DE DESARROLLO. Usuario SGR ha reunido los datos del contexto en el que se desarrolla el proyecto. Precondicin El usuario SGR ha ingresado los datos del contexto en el que se desarrolla el proyecto. Valoracin del contexto mediante valores lingsticos preestablecidos Post condicin Valoracin numrica del contexto. Evento de inicio Usuario SGR solicita cuestionario TBQ-SAC. Evento de El SGR ha valorizado el contexto del proyecto . finalizacin Presentar al usuario el cuestionario basado en la taxonoma de riesgos de SAC. Escenario principal Salvar datos ingresados por el usuario SGR Convertir valores lingsticos (preestablecidos mediante listados desplegables o check box) a valores numricos. Seleccionar una instancia (previamente cargada) de las clases de datos que conforman la taxonoma de SAC. Transferir datos a procedimientos de clculo del SGR Ver figura 3.3.3.c (pgina 75)
Escenario alternativo Observaciones
Tabla 4.3.3.a: Descripcin de caso de uso Identificacin de riesgos
80
Caso de uso Analizar riesgos Nombre ID Analizar riesgos. CU12
Nivel de abstraccin Medio Incluido en Actores principales Actor secundario Paquete C1 Evaluacin de riesgos. Usuario SGR y subsistemas CU 11 "Identificacin de riesgos" y CU 4 "Parametrizacin del sistema" Subsistema CU 13 "Priorizar riesgo"
Frecuencia mxima 10 evaluaciones por da. Descripcin En base a los datos numricos del contexto se determina la exposicin a riesgos del proyecto. Los datos de contexto de proyecto han sido cargados y convertidos a valores numricos. El SGR ha sido parametrizado. Valoracin del probabilidad de ocurrencia de los 33 riesgos tpicos de un proyecto SAC Valoracin de la exposicin a riesgo del proyecto Evento de inicio Evento de finalizacin CU 11 ha identificado los riesgos. El SGR ha estimado la exposicin a riesgo del proyecto. Estimar esfuerzo de desarrollo del proyecto. Calcular probabilidad de ocurrencia de riesgos. Escenario principal Calcular exposicin a riesgo. Determinar el nivel de calidad de la gestin de riesgo. Escenario alternativo Observaciones Solicitar parametrizacin del SGR. Ver figura 3.3.3.d (pgina 76)
Precondicin
Post condicin
Tabla 4.3.3.b: Descripcin de caso de uso Analizar riesgos
81
Caso de uso Priorizar riesgos Nombre ID Priorizar riesgos. CU 13
Nivel de abstraccin Medio Incluido en Actor principal Actor secundario Paquete CU 1 evaluacin de riesgos. Subsistemas CU 12 "analizar riesgos". Subsistema CU 2 "Control de riesgos" y Usuario SGR
Frecuencia mxima 10 evaluaciones por da. En base a la exposicin a riesgo del proyecto, seleccionar los cinco riesgos de mayor prioridad. Se limita el nmero de riesgos a corregir debido a que los recursos humanos y econmicos de un proyecto son limitados. Se ha determinado la exposicin a riesgo del proyecto. Precondicin El SGR ha sido parametrizado. Post condicin Evento de inicio Evento de finalizacin Escenario principal Seleccionar lo cinco riesgos de mayor RE. Escenario alternativo Observaciones Solicitar parametrizacin del SGR. Ver figura 3.3.3.e (pgina 76) Determinacin de los cinco riesgos prioritarios. Subsistema CU 12 ha analizado los riesgos del proyecto. El SGR ha determinado los cinco riesgos prioritarios. Ordenar riesgos de mayor a menor en base al valor RE (i).
Descripcin
Tabla 4.3.3.c: Descripcin de caso de uso Priorizar riesgos.
82
Caso de uso Planificar gestin de riesgos Nombre ID Planificar gestin de riesgos CU 21
Nivel de abstraccin Medio Incluido en Actor principal Actor secundario Paquete CU 2 Control de riesgos. Subsistemas CU13 "Priorizar riesgos". Usuario SGR
Frecuencia mxima 10 planificaciones por da. El SGR analiza el valor de los factores de riesgo y busca una de las soluciones preestablecidas para controlar el mismo. Se ha determinado la exposicin a riesgo del proyecto. Precondicin El SGR ha sido parametrizado. Post condicin Evento de inicio Evento de finalizacin Determinacin las soluciones necesarias para controlar los riesgos de mayor exposicin. Subsistema CU 13 ha determinado los cinco riesgos prioritarios. El SGR ha encontrado la solucin. Buscar soluciones para los factores de riesgo ms importantes. Escenario principal Determinar secuencia de implementacin de las soluciones. Escenario alternativo Observaciones Solicitar parametrizacin del SGR. Ver figura 3.3.3.g (pgina 77)
Descripcin
Tabla 4.3.3.d: Descripcin de caso de uso Planificar gestin de riesgos.
83
Caso de uso Monitoreo de riesgos Nombre ID Monitoreo de riesgos CU 22
Nivel de abstraccin Medio Incluido en Actor principal Actor secundario Frecuencia mxima 10 monitoreos por da. Descripcin Dado que el contexto en el que se desarrolla el proyecto cambia a lo largo del tiempo, es necesario monitorear en forma peridica los riesgos del mismo. Se ha actualizado los datos del contexto en el que se desarrolla el proyecto. El SGR ha sido parametrizado. Post condicin Evento de inicio Evento de finalizacin Determinacin las soluciones necesarias para controlar los riesgos de mayor exposicin. El usuario solicita un nuevo anlisis de riesgos. El SGR ha encontrado la solucin. Disparar Subsistema CU 11 "Identificacin de riesgos" Escenario principal Desarrollar el proceso completo de gestin de riesgo. Escenario alternativo Observaciones Solicitar parametrizacin del SGR. Ver figura 3.3.3.h (pgina 78) Paquete CU 2 Control de riesgos. Usuario SGR
Precondicin
Tabla 4.3.3.e: Descripcin de caso de uso Monitoreo de riesgos.
84
Caso de uso Identificacin de caractersticas del integrador Nombre ID Identificacin de caractersticas del integrador CU 111
Nivel de abstraccin bajo Paquete CU 11 Identificacin de riesgos. Incluido en Actor principal Actor secundario Usuario SGR Subsistema CU 12 " Analizar riesgo"
Frecuencia mxima 10 operaciones por da. Esta funcin administra el ingreso de los datos del INTEGRADOR: Carga de trabajo, Estado econmicofinanciero, Estructura Experiencia (en PLC, HMI, SCADA, Accionamientos, PC, redes y Seguridad industrial), Gestin de proyectos, Nivel de remuneracin. Estos datos sern salvados en una instancia de la clase INTEGRADOR. Se han cargado los datos del INTEGRADOR. Precondicin El SGR ha sido parametrizado. Post condicin Evento de inicio Evento de finalizacin Escenario principal Salvar instancia. Escenario alternativo Observaciones Transferir una instancia guardada en el SGR. Ver figura 3.3.3.C (pgina 75) Creacin de instancia de INTEGRADOR. El usuario SGR solicita editar el cuestionario TBQ-SAC. El SGR ha salvado los datos. Crear instancia de la clase INTEGRADOR
Descripcin
Tabla 4.3.3.f: Descripcin de caso de uso Monitoreo de riesgos.
Los casos de uso CU 112, CU 113, CU 113, CU 114, CU 115, CU 116, CU 117, CU 118 y CU 119 tienen una estructura similar a CU 111. Por ello se resume su estructura mediante la generalizacin representada en la tabla 4.3.3.g.
85
Caso de uso Identificacin de caractersticas de CLASE TBQ-SAC Nombre ID

Nivel de abstraccin Incluido en
Identificacin de caractersticas de CLASE TBQ-SAC CU 11

bajo Paquete CU 11 Identificacin de riesgos.
Actor principal Actor secundario
Usuario SGR Subsistema CU 12 " Analizar riesgo"
Frecuencia mxima 10 operaciones por da. Esta funcin administra el ingreso de los atributos de la Descripcin CLASE-TBQ-SAC Se han cargado los datos de la CLASE TBQ-SAC. Precondicin El SGR ha sido parametrizado. Post condicin Evento de inicio Evento de finalizacin Escenario principal Escenario alternativo Observaciones Creacin de instancia de CLASE TBQ-SAC. El usuario SGR solicita editar el cuestionario TBQ-SAC. El SGR ha salvado los datos. Crear instancia de la clase INTEGRADOR Salvar instancia. Transferir una instancia guardada en el SGR. Ver figura 3.3.3.C (pgina 75)
Tabla 4.3.3.g: Generalizacin de caso de uso Identificacin de caractersticas de ...
2 3 4 5 6 7 8 9
CLASE TBQ-SAC CLIENTE PROVEEDOR CONTRATO PROCESO TERCERO PROYECTO HARDWARE HERRAMIENTA DE DESARROLLO
Tabla 4.3.3.h: Valores que puede asumir .
86
Caso de uso Inferir valores numricos del contexto de proyecto Nombre ID Inferir valores numricos del contexto de proyecto CU 1110
Nivel de abstraccin bajo Incluido en Actor principal Actor secundario Paquete CU 11 Identificacin de riesgos. Usuario SGR Subsistema CU 12 " Analizar riesgo"
Frecuencia mxima 10 operaciones por da.
Descripcin
Esta funcin convierte los valores lingsticos preestablecidos del cuestionario TBQ-SAC en valores numricos (formato: nmero real). Luego de esta conversin el SGR est listo para comenzar con los clculos de probabilidad de ocurrencia de riesgos. Se han cargado los datos de la CLASE TBQ-SAC (mediante valores lingsticos preestablecidos). El SGR ha sido parametrizado.
Precondicin
Post condicin Evento de inicio Evento de finalizacin Escenario principal
Contexto del proyecto valorizado en forma numrica. El usuario SGR solicita editar el cuestionario TBQ-SAC. El SGR ha convertido todos los valores lingsticos en valores numricos. Inferir valor numrico a partir de valor lingstico. Salvar datos convertidos.
Escenario alternativo Observaciones
Transferir una instancia guardada en el SGR. Ver figura 3.3.3.C (pgina 75)
Tabla 4.3.3.i: Caso de uso Inferir valores numricos del contexto de proyecto.
87
Caso de uso Estimar esfuerzo Nombre ID

Estimar esfuerzo CU 121 Bajo Paquete CU 12 Analizar riesgos. Usuario SGR
Frecuencia mxima 10 operaciones por da. Esta funcin calcula el esfuerzo necesario para realizar el proyecto. SAC. El clculo se basa en las entradas, salidas y complejidad del sistema (ver seccin 4.3.4.6). El valor obtenido se compara con las horas que estim el integrador, de manera de evaluar el grado de sobrecarga de trabajo (ver seccin 4.3.4.5, pgina 105). Se han volcado los datos del proceso necesarios para estimar el esfuerzo (cantidad de entradas, salidas, complejidad, etc.). El SGR conoce de antemano los valores promedio de tiempos de desarrollo estndares. Estimacin de esfuerzo expresada en horashombre. Sobrecarga de trabajo. El subsistema CU 13 ha priorizado los riesgos del proyecto y ha seleccionado los cinco prioritarios. El SGR ha calculado el esfuerzo y la sobrecarga de trabajo. Analizar valores de los factores que disparan los riesgos prioritarios. Asociar una o ms soluciones a cada factor que pueda disparar un riesgo prioritario. Escenario alternativo Observaciones Parametrizar SGR. Ver figura 3.3.3.g (pgina 77)
Descripcin
Precondicin
Post condicin Evento de inicio Evento de finalizacin
Escenario principal
Tabla 4.3.3.j: Descripcin de caso de uso Estimar esfuerzo.
88
Caso de uso Calcular probabilidad de ocurrencia de riesgos Nombre ID

Calcular probabilidad de ocurrencia de riesgos. CU 122 Bajo Paquete CU 12 Analizar riesgos. Subsistema CU 11 " evaluacin de riesgos", Subsistema CU 4 "Parametrizacin de SGR", Usuario SGR. Subsistema CU 13 "Priorizar riesgos".
Frecuencia mxima 10 operaciones por da. Esta funcin calcula la probabilidad de ocurrencia de cada uno de los 33 riesgos tpicos que pueden aparecer en un proyecto SAC. Se ha determinado el contexto en el que se desarrolla el proyecto. Precondicin El SGR ha calculado el esfuerzo de desarrollo y la sobrecarga de trabajo. El SGR ha sido parametrizado. Post condicin Evento de inicio Evento de finalizacin Escenario principal Probabilidad de ocurrencia de riesgos 1 a 33: Determinada. El usuario SGR solicita analizar riesgo. El SGR ha determinado el perfil de riesgo del proyecto. Aplicar frmula de clculo de probabilidad (ver seccin 4.3.4 , pgina 54)
Descripcin
Escenario alternativo Parametrizar SGR. Observaciones Ver figura 3.3.3.d (pgina 76)
Tabla 4.3.3.k: Descripcin de caso de uso Calcular probabilidad de ocurrencia de riesgo.

Captulo 4: Anlisis del SI Autor: Ing. Jos Luis del Ro
89
Caso de uso Calcular exposicin a riesgo Nombre ID Calcular la exposicin a riesgo. CU 123 Bajo Paquete CU 12 Analizar riesgos. Subsistema CU 11 " evaluacin de riesgos", Subsistema CU 4 "Parametrizacin de SGR", Usuario SGR. Subsistema CU 13 "Priorizar riesgos". 10 operaciones por da.
Actor principal Actor secundario Frecuencia mxima
Descripcin
Esta funcin calcula la exposicin a riesgo tomando como base la frmula de Bohm. RE(i)= P(i) x L(i)
Se ha calculado la probabilidad de ocurrencia de los 33 riesgos tpicos de un proyecto SAC. Precondicin El SGR ha sido parametrizado. Post condicin Evento de inicio Evento de finalizacin Escenario principal Perfil de riesgos de proyecto. El usuario SGR solicita analizar riesgo. El SGR ha determinado el perfil de riesgo del proyecto. Aplicar frmula de exposicin a riesgo.
Escenario alternativo Parametrizar SGR. Observaciones Ver figura 3.3.3.d (pgina 76)
Tabla 4.3.3.l: Descripcin de caso de uso Calcular probabilidad de ocurrencia de riesgo.
90
Caso de uso Ordenar riesgos en base al valor de RE Nombre ID Ordenar riesgos en base al valor de RE. CU 131
Nivel de abstraccin Bajo Incluido en Actor principal Actor secundario Paquete CU 13 Priorizar riesgos. Subsistema CU 12 "analizar riesgos". Subsistema CU 2 "Control de ", Usuario SGR.
Frecuencia mxima 10 operaciones por da. Descripcin Esta funcin ordena la prioridad de atencin de riesgos en base al valor RE (i). Se ha determinado el perfil de exposicin a riesgo. Precondicin El SGR ha sido parametrizado. Post condicin Evento de inicio Evento de finalizacin Escenario principal Escenario alternativo Observaciones Lista ordenada de riesgos prioritarios. El usuario SGR solicita analizar riesgo. Subsistema CU 12 "analizar riesgos" ha determinado el perfil de exposicin a riesgo. Aplicar rutina de ordenamiento en funcin del valor de RE (i). Parametrizar SGR. Ver figura 3.3.3.e (pgina 76)
Tabla 4.3.3.m: Descripcin de caso de uso Ordenar riesgos en base al valor de RE.
Caso de uso Seleccionar los cinco riesgo de mayor RE Nombre ID Seleccionar los cinco riesgo de mayor RE CU 132
Nivel de abstraccin Bajo Incluido en Actor principal Actor secundario Paquete CU 13 Priorizar riesgos. Subsistema CU 12 "analizar riesgos". Subsistema CU 2 "Control de ", Usuario SGR.
Frecuencia mxima 10 operaciones por da. Descripcin Esta funcin selecciona los cinco riesgos de mayor prioridad (mayor RE) Se ha determinado el perfil de exposicin a riesgo. Precondicin El SGR ha sido parametrizado. Post condicin Evento de inicio Evento de finalizacin Escenario principal Escenario alternativo Observaciones Lista de los cinco riesgos prioritarios. El usuario SGR solicita analizar riesgo. Se han seleccionado los cinco riesgos prioritarios. Seleccionar los cinco riesgos de mayor RE. Parametrizar SGR. Ver figura 3.3.3.e (pgina 76)
Tabla 4.3.3.n: Descripcin de caso de uso seleccionar los cinco riesgos prioritarios de mayor RE.
Caso de uso Buscar soluciones para los factores de riesgo ms importantes Nombre ID
Buscar soluciones para los factores de riesgo ms importantes CU 211

Bajo Paquete CU 2 Control de riesgos.
Subsistema CU 13 " Priorizar riesgos" Usuario SGR
Frecuencia mxima 10 operaciones por da. Esta funcin analiza el valor de los factores que disparan cada uno de los cinco riesgos prioritarios. Si este valor puede desencadenar la aparicin de un riesgo busca una solucin preestablecida Se han seleccionado los cinco riesgos principales del proyecto. El SGR conoce de antemano las soluciones para cada factor de riesgo. Listado y descripcin de soluciones a adoptar para controlar el riesgo. El subsistema CU 13 ha priorizado los riesgos del proyecto y ha seleccionado los cinco prioritarios. El SGR ha propuesto al usuario la planificacin del control de riesgos. Analizar valores de los factores que disparan los riesgos prioritarios. Asociar una o ms soluciones a cada factor que pueda disparar un riesgo prioritario. Escenario alternativo Observaciones Parametrizar SGR. Ver figura 3.3.3.g (pgina 77)
Descripcin
Precondicin
Post condicin Evento de inicio Evento de finalizacin
Escenario principal
Tabla 4.3.3.m: Descripcin de caso de uso Buscar soluciones para los factores de riesgo ms importantes..
Caso de uso Proponer secuencia de implementacin de soluciones Nombre ID

Proponer secuencia de implementacin de soluciones CU 212

Bajo Paquete CU 2 Control de riesgos.
Subsistema CU 13 " Priorizar riesgos" Usuario SGR
Descripcin
Esta establece la secuencia en la que se deben aplicar las soluciones.
Se han seleccionado los cinco riesgos principales del proyecto. Precondicin El SGR conoce de antemano las soluciones para cada factor de riesgo. Post condicin Evento de inicio Evento de finalizacin Escenario principal Escenario alternativo Observaciones Secuencia de aplicacin de soluciones a adoptar para controlar el riesgo. El subsistema CU 13 ha priorizado los riesgos del proyecto y ha seleccionado los cinco prioritarios. El SGR ha propuesto al usuario la planificacin del control de riesgos. Establecer secuencia de implementacin de soluciones. Parametrizar SGR. Ver figura 3.3.3.g (pgina 77)
Tabla 4.3.3.l: Descripcin de caso de uso Proponer secuencia de implementacin de soluciones..

94
Caso de uso Actualizar datos de cuestionario TBQ-SAC Nombre ID

Nivel de abstraccin Incluido en Actualizar datos de cuestionario TBQ-SAC
CU 221
Bajo Paquete CU 22 Monitoreo de riesgos.
Usuario SGR Subsistema CU 11 Identificacin de riesgos.
Descripcin
Se registran los cambios de contexto del proyecto.
Se ha realizado al menos un anlisis del proyecto. Precondicin SGR Parametrizado. Post condicin Evento de inicio Evento de finalizacin Escenario principal Escenario alternativo Observaciones Reinicio de formulario TBQ-SAC. El usuario reinicia el proceso de gestin de riesgos. El SGR ha propuesto al usuario la nueva planificacin del control de riesgos. Disparar Subsistema CU 222. Parametrizar SGR. Ver figura 3.3.3.h (pgina 78)
Tabla 4.3.3.o: Descripcin de caso de uso Actualizar datos del cuestionario TBQ-SAC..
95
Caso de uso disparar nuevo proceso de gestin de riesgo Nombre ID

Nivel de abstraccin Incluido en Actualizar datos de cuestionario TBQ-SAC
CU 222
Bajo Paquete CU 22 Monitoreo de riesgos.
Usuario SGR Subsistema CU 11 Identificacin de riesgos.
Descripcin
Se registran los cambios de contexto del proyecto.
Se ha realizado al menos un anlisis del proyecto. Precondicin SGR Parametrizado. Post condicin Evento de inicio Evento de finalizacin Escenario principal Escenario alternativo Observaciones Reinicio de proceso de gestin de riesgos. El usuario reinicia el proceso de gestin de riesgos. El SGR ha propuesto al usuario la nueva planificacin del control de riesgos. Disparar nuevo proceso de gestin de riesgos. Parametrizar SGR. Ver figura 3.3.3.h (pgina 78)
Tabla 4.3.3.p: Descripcin de caso de uso Reinicio de nuevo proceso de gestin de riesgo..
96
4.3.4 Frmulas 4.3.4.1 Frmula de exposicin a riesgos utilizada por el especialista en proyectos de SAC. Segn el criterio de exposicin a riesgo desarrollado por Barry Bohm (ver seccin 2.3.1.1, pgina 33):
RE(i ) = P(i ) L(i )

Donde: i = nmero de riesgo
Ec. 4.3.4.1: Clculo de exposicin a riesgo.
P (i) = Probabilidad de ocurrencia de riesgo i [0 a 1] L(i) = Prdida ocasionada por del riesgo i [0 a 100] El especialista en SAC ha desarrollado los siguientes criterios para estimar la probabilidad y la prdida en proyectos SAC: 4.3.4.2 Estimacin de prdidas en SAC: El especialista considera que pueden existir cuatro tipos de prdidas (seccin F9 pgina 329). L crono(i) = Prdida de tiempo producida por R(i) [0 a 100]. L eco(i) = Prdida econmica producida por R(i) [0 a 100] L tec(i) = Impacto tcnico producido si ocurre riesgo i [0 a 100] L seg(i) = Prdida en la seguridad industrial producida por R(i) [0 a 100] Para el clculo de RE en SAC el especialista utiliza el promedio de las cuatro prdidas:
L ( i ) = (L crono
(i )
+ L eco ( i ) + L tec ( i ) + L seg ( i )
Ec 4.3.4.2.a: Clculo de prdida promedio causada por riesgo i.
97
Para poder promediar los cuatro tipos de prdida, es necesario que tengan una unidad comn, por ello cada una es evaluada en forma porcentual respecto de los valores preestablecidos para el proyecto. El especialista considera que el tiempo real de desarrollo del proyecto se puede prolongar segn:
Treal = ( 1 +
Lcrono (i ) 100
) * Tprogramado
Ec 4.3.4.2.b : Tiempo real.
Si L crono (i)= 100 % el tiempo real es el doble del programado. De manera similar el costo real del proyecto se incrementa segn:
CPreal = ( 1 +
Donde
Leco (i ) 100
) * CPprogramado
Ec 4.3.4.2.c: Costo real.
CP: Costo del proyecto Si L eco (i)= 100 % el costo real es el doble del programado. El aumento de las dificultades tcnicas se expresa como:
DTreal = ( 1 +
Donde
Ltec ( i ) 100
) * DTprogramado
Ec. 4.3.4.2.d: Dificultad
DT: Dificultades tcnicas Si L crono(i)= 100 % el grado de dificultad ser el doble del esperado.
98
En el aspecto seguridad los se establece el siguiente criterio: L seg(i = 80 % 40 L seg(i < 80 % 20 L seg(i < 40 % 10 L seg(i < 20 % 0 L seg(i < 10 % Prdidas de vidas humanas . Heridas graves . Heridas medias con largo tiempo de curacin . Heridas pequeas con corto tiempo de curacin . Heridas muy pequeas no hace falta tiempo de curacin.
Por otro lado el especialista estima para cada riesgo i una prdida segn la siguiente ponderacin:
Ppal. afectado Int. Cl. Cl. Todos Int. Cl. Int. Cl. Int. Int. Int. Int. Todas Todas Op. Todas Op. PM Prdidas Tipo de Contrato Riesgo Etapa estimada de impacto Todas Op. Op. Op. Todas
Lcrono
Leco
Lec
R01 R02 R03 R04
Baja productividad del equipo de desarrollo Baja productividad del proceso automatizado Baja fiabilidad del proceso automatizado Contaminacin ambiental MG
50 0 0 5
30 30 20 100
0 5 5 5 0 0 60 60 15
0 5 20 100 0 0 10 10 0
20 10 11 55 50 50 48 48 18
100 100 100 100 60 60 15 60 60 40
R05
Estimaciones de esfuerzo errneas Adm Especificaciones incompletas o errneas Falta de aceptacin del producto por parte de usuarios Falta de capacitacin / experiencia del personal No cumplir con los estndares del proceso industrial Pago de intereses punitorios por mora o proceso cado MG Adm
R06
R07 R08 R09 R10
100 100 100 100 100 20 20 0 0 20 0 15 50
100 100
Tabla 4.3.4.2.a Estimacin de prdidas causadas por cada tipo de riesgo.
99
Descripcin del riesgo
Lseg
Tipo de Contrato
Lcrono
Leco
Lseg
R12 R13 R14 R15 R16 R17 R18 R19 R20 R21 R22 R23 R24 R25 R26 R27 R28 R29 R30 R31 R32 R33
Perder licitacin Prdida de informacin del proceso Prdida de informacin del proyecto Prdida de materia prima Prdida de reputacin en el mercado (Integrador) Prdida de reputacin en el mercado (cliente) Prdida de reputacin en el mercado (Proveedor) Prdida de personal clave, difcil de reemplazar Prdida de representacin/ certificacin del proveedor Prdidas humanas y/o accidentes Prdida / dao de equipos de proceso . Perturbaciones causadas por tercero Problemas en otros proyectos en desarrollo Problemas de facturacin Problemas de mantenimiento (en garanta) Problemas de mantenimiento (fuera de garanta) Problemas legales Sobrecarga de trabajo Software de aplicacin de mala calidad Reserva Robo de herramientas de desarrollo de software Retraso en cronograma de trabajo
0 0 30 0 0 0 0 20 0 100 80 30 50 0 0 0 0 100 60
80 50 30 40 100 100 100 20 80 100 80 30 50 30 20 20 100 100 60
0 0 0 0 0 0 0 20 0 10 10 5 0 0 30 30 0 10 60
0 0 0 0 0 0 0 10 0 100 90 5 0 0 10 10 0 10 60
20 12 15 10 25 25 25 23 20 78 65 18 25 8 15 15 25 55 60
Int. Cl. Int. Cl. Int. Cl. Prov. Int. Int. Todos Todos Int. Int. Int. Int. Cl. Int. Int. Int.
Ppal. afectado Int. Int.
Prdidas
Todas PM Op. Op. Op. Op. Op. Op. Op. PM Todas Todas Op. Op. Todas Todas Todas
50 70
30 70
0 0
0 0
20 35
Todas Op.
Tabla 4.3.4.2.a (continuacin) Estimacin de prdidas causadas por cada tipo de riesgo.
100
Etapa estimada de impacto Cot. Op.
Riesgo
Lec
Abreviaturas de tabla 4.3.4

Cot Op PM Int Cl Prov MG Adm
Descripcin
Cotizacin Operacin Puesta en marcha Integrador Cliente Proveedor Monto global Administracin
Observaciones
Etapa en la que impacta el riesgo Principal afectado por la prdida Tipo de contrato
Tabla 4.3.4.2.b Abreviaturas utilizadas en tabla 4.3.4.2.a.
4.3.4.3 Clculo P i Segn se especific en el CU 122 es necesario determinar la probabilidad de ocurrencia. Para determinar P i (ver secciones F9 pgina 319 y F10 pgina 335), el especialista desarroll la siguiente ecuacin:
Pi = K i j =1Wi. j X i. j
mi
En donde:
Ec 4.3.4.3.a: Probabilidad de riesgo i.
i: nmero de riesgo (entero) 1 a 33 j: nmero de factor (entero) 1 a m m i : Cantidad de factores de riesgos para el riesgo i (entero) X i,j : Factor de riesgo (real) 0 a 1 W i,j : Peso de un factor de riesgo (real) 0 a 1 K i,j : Valor histrico de probabilidad de riesgo (real) 0 a 1
En la ecuacin se considera que un tipo de riesgo determinado (Ri) es influenciado por m factores de riesgo, cada uno de estos tiene un peso distinto en P i representado por W i,j, teniendo en cuenta que la suma de los m pesos debe ser igual a 1 es decir:
101
m j =1
Wi , j = 1
Ec. 4.3.4.3.b Verificacin de asignacin correcta de pesos.
A partir del cuestionario TBQ-SAC se valorizan los atributos de las clases establecidas por el mismo, de esta forma el contexto en la que se desarrolla el proyecto SAC es representada numricamente por los factores de riesgo X i,j. Por ejemplo considerando que el cuestionario TBQ-SAC permite asignar una de seis respuestas al evaluar la experiencia en seguridad industrial que tiene el cliente, la relacin respuesta - valor numrico ser la establecida en la tabla 4.3.4.3: Respuesta Muy malo Malo Regular Bueno Muy bueno Desconocida (?) Valor de X21.1 1.00 0.75 0.50 0.25 0.00 1.00
Tabla 4.3.4.3: Asignacin de valores numricos a las respuestas del TBQ-SAC. (Ej. Experiencia en seguridad industrial del cliente)
De manera similar, se establece la relacin respuesta - valor del resto de los factores de riesgo. El especialista asigna una constante Ki 1 que toma en cuenta los valores histricos de ocurrencia de un riesgo. En la seccin E1 se detallan los valores de W i,m y K i asignados en funcin de la experiencia del especialista. Consideremos como ejemplo el riesgo R21 (Prdidas de vidas humanas y/o accidentes) puede ser generado por cuatro factores: 1) La experiencia en seguridad industrial del cliente (X21.1). 2) La experiencia en seguridad industrial del Integrador (X21.2). 3) La complejidad del proceso (X21.3).
4) El tipo de ambiente en el que se desarrolla el proceso (X21.4). El especialista asigna un peso W i,j a cada uno de los factores: W21.1 = 0.40 W21.2 =0.40 W21.3 =0.1 W21.3 =0.1
Aplicando la ecuacin 4.3.4.3.b se verifica para R21 que la suma de los cuatro pesos debe ser igual a 1.
4 j =1
W21, j = 1
(i)
Para R 21 K21=0.04 (para ms detalles sobre la asignacin de K apndice E 12). De esta forma la probabilidad de R21 queda expresada como:
y W
(i,m)
(ver
P21= K21 [(W21.1 * X21.1) + (W21.2 * X21.2) + (W21.3 * X21.3) + (W21.4 * X21.4)]] P21= 0,04 [(0,4 * X21.1 ) + (0,4 * X21.2 ) + (0,1 * X21.3 ) + (0,1 * X21.4 )]] Veamos el resultado de aplicar esta frmula en dos contextos diferentes: Contexto 1 La experiencia en seguridad industrial del cliente es muy mala (X21.1=1). La experiencia en seguridad industrial del Integrador es mala (X21.2=0.75). El proceso es muy complejo (X21.3 =1). El proceso se desarrolla en un ambiente muy peligroso (X21.4= 1). En este contexto P21= (0.4 x 1+0.4 x 0,75 +0,1 x 1 + 0,1 x 1) 0,04= 0.036 = 3,6%
103
Contexto 2 La experiencia en seguridad industrial del cliente es buena (X21.1=0,25). La experiencia en seguridad industrial del Integrador es muy buena (X21.2=0). El proceso es complejo (X21.3 =1). El proceso se desarrolla en un peligroso (X21.4= 1). En este contexto P21= (0.4 x 0,25+0.4 x 0 +0,1 x 1 + 0,1 x 1) 0,04= 0.0108 = 1,08% Teniendo en cuenta que L
(21)= 78
(ver tabla 3.4.4.2.a) y P(21) el especialista puede
determinar la exposicin a riesgo RE(21) para ambos contextos : Contexto 1 Contexto 2 RE (21) = 0.036 * 78 = 2,908 RE (21) = 0.0108 * 78 = 0.8424
Podemos ver que el contexto 1crea a una situacin de riesgo mayor que el 2. En la seccin 4.3.5 (Identificacin y descripcin de Inferencias) se detallan los mecanismos de inferencias utilizados por el especialista para determinar los factores X21,j . 4.3.4.4 Clculo de prioridades Considerando que los recursos humanos y materiales necesarios para controlar un riesgo son limitados, es importante poder priorizar los mismos. El especialista establece las prioridades en funcin del RE y de la cercana del impacto. Si tenemos dos riesgos con exposiciones similares, se asignar una prioridad ms alta al que tenga un impacto ms cercano en el cronograma dado que contamos con menos tiempo para resolver el problema, el especialista representa este criterio mediante un coeficiente de cercana (CC), de esta forma la prioridad del R dada por:
(i)
viene
104
Pr io( i ) = RE( i ) CC ( i )
Donde:
Ec. 4.3.4.4: Prioridad del riesgo i.
Si se estima que el impacto del riesgo es inmediato Si se estima que el impacto del riesgo es cercano Si se estima que el impacto del riesgo es lejano 4.3.4.5 Sobrecarga del equipo de proyecto
CC = 1 CC = 0.75 CC = 0.50
Es importante que el SGR detecte la sobrecarga de trabajo (ST) en el equipo de proyecto, el hecho de tener que trabajar en jornadas de trabajos extensas puede crear un esfuerzo desmesurado del equipo de trabajo exponiendo al proyecto a: Errores en el diseo. Errores en la codificacin. Ausencias por enfermedad. Incumplimiento de cronograma de trabajo. Bajo rendimiento.
Debemos tener en cuenta que ST puede variar a lo largo del proyecto por varios factores (ejemplo: prdida de personal clave por sueldos bajos, adjudicacin de nuevos proyectos), por lo tanto es importante monitorear ST a lo largo de todo el proyecto. El especialista desarroll la siguiente frmula para estimar la sobrecarga de trabajo:
DR ST = 100% 100% DN
Donde:
Ec 4.3.4.5.a: Sobrecarga de trabajo.
ST = Sobrecarga de trabajo [%] DR = Duracin real (en funcin de la fecha de puesta en servicio de la aplicacin) DN = Duracin normal del proyecto (en jornadas de 8 horas en das hbiles)
DN =
EE
1
(i )
NP 176hs / mes
Ec 4.3.4.5.b: Duracin de normal del proyecto.
NP = Nmero de personas productivas EE = Estimacin de esfuerzo del proyecto [horashombre] n = Nmero de proyectos simultneos I = Nmero de proyecto [1 a n] DP = Disponibilidad de tiempo segn cronograma [meses] Si por ejemplo NP = 5 personas, EE1 = 2000 horas, EE2 = 5000 horas, n = 2, DR = 4 meses DN = 2000 + 5000 = 8 medes 5 * 176 Supongamos que comenzamos el proyecto con cuatro meses de atraso, la duracin real del proyecto ser entonces de cuatro meses, razn por la cual dispondramos de la mitad del tiempo necesario.
ST =
8 4
meses meses
100 % - 100 % = 100 %
Una sobrecarga del 100 % nos indica que disponemos de la mitad del personal necesario. Esto implica que se deber tomar ms personal (con los riesgos asociados) o que el personal trabajar ms horas o una combinacin de ambos. Si ST > 0 % (Sobrecarga) comienzan los riesgos de sobrecarga. Si ST < 0% (Desocupacin) comienzan los riesgos econmicos. Segn el especialista una situacin manejable sera -20% < ST < 20 %
El clculo de esta ST es vlido para una distribucin razonable de trabajo, es decir que en base la arquitectura y estructura del software a desarrollar, cada persona del equipo de proyecto tiene asignados los trabajos en funcin de su especialidad y a las caractersticas del proyecto.
4.3.4.6 Estimacin de esfuerzo Para calcular ST (CU 121) es necesario estimar el esfuerzo (EE). Segn el especialista, los integradores de SAC generalmente obtienen una aproximacin gruesa del esfuerzo, en base a la cantidad de componentes tpicos de un SAC y la complejidad del proceso a automatizar. Teniendo en cuenta que normalmente un SAC est constituido por: - Entradas digitales (ED). - Salidas digitales (SD). - Entradas analgicas (EA). - Salidas analgicas (SA). - Interfaces Humano- mquina (HMI). - Variadores de velocidad para motores de Corriente alterna (AccCA). - Variadores de velocidad para motores de Corriente continua (AccCA). - Redes de comunicacin. El esfuerzo requerido se obtiene de:
EE = Comp (EE DIG + EE ANALOG + EE HMI + EE ACC + EE RED )

Ec 4.3.4.6.a: Estimacin de esfuerzo.
En la cul:
EE DIG = ED C ED + SD C SD
Ec 4.3.4.6.b: Esfuerzo calculado en base a ED Ec 4.3.4.6.c: Esfuerzo calculado en base a EA Ec 4.3.4.6.d: Esfuerzo calculado en base a HMI Ec 4.3.4.6.e: Esfuerzo calculado en base a Acc Ec 4.3.4.6.f: Esfuerzo calculado en base a ED
EE ANALOG = EA C EA + SA C SA
EE HMI = HMI C HMI Scr
EE ACC = Acc CA C CA + Acc cc C cc
EE RED = EST C EST
107
ED: Cantidad de entradas digitales SD: Cantidad de salidas digitales EA: Cantidad de entradas analgicas SA: Cantidad de salidas analgicas HMI: Cantidad de HMIs EST: Cantidad de Estaciones de red
Ced: Horas de trabajo / entrada digital Cad: Horas de trabajo / salida digital Cea: Horas de trabajo / entrada analgica Csa: Horas de trabajo / salidas analgica Chmi Horas de trabajo / HMI-pantalla Cest: Horas de trabajo / estacin
AccCA : cantidad de accionamientos CA CccCA : Horas/accionamiento de CA AccCC : cantidad de accionamientos CC CccCA : Horas/accionamiento de CC Scr: Cantidad de pantallas CA: Corriente alternada Comp: Complejidad del proceso CC: Corriente continua
Si las especificaciones iniciales del proceso son errneas EE puede aumentar a lo largo del proyecto (por ejemplo por el agregado de entradas / salidas no contempladas en el inicio del proyecto). Esto genera sobrecarga de trabajo y costos adicionales de hardware e instalacin. 4.3.5 Identificacin de Inferencias Como hemos visto en el proceso de educcin y en la seccin 4.3.4 (Frmulas) el especialista utiliza inferencias en varias de las funciones del proceso de gestin de riesgo. En la tabla 4.3.5 se resumen las mismas:
Caso de uso CU 11 CU 12 CU 22 CU 3 Descripcin Identificacin de riesgo Anlisis de riesgo. Resolucin del riesgo Evaluar calidad del proceso de gestin de riesgo Tipo de inferencia Inferir los valores de los factores de riesgo en base a la situacin de contexto en la que se desarrolla el proyecto. Inferir medidas preventivas. Inferir la calidad anlisis de riesgo.
Tabla 4.3.5 Inferencias del SGR

A continuacin se describen las inferencias citadas en la tabla 4.3.5, las mismas son utilizadas por el especialista en los procesos de gestin de riesgos. 4.3.5.1 Identificacin de inferencias de estimacin de factores de riesgo X i,j Recordemos que el contexto de desarrollo es obtenido del cuestionario basado en la taxonoma de riesgos en SAC (TBQ-SAC). Cada pregunta del mismo se corresponde con un atributo de las clases CLIENTE, CONTRATO, HARDWARE, HERRAMIENTAS DE DESARROLLO, INTEGRADOR, PROCESO, PROVEEDOR, PROYECTO y TERCERO (CU 11). Durante el desarrollo de un proyecto de software en SAC pueden presentarse algunos de los 33 riesgos tpicos. Para calcular Pi, el SGR debe ponderar previamente los factores de riesgo que determinan la probabilidad de los mismos (CU 1110). Retomando el ejemplo de R21 (Riesgo de prdidas humanas y/o accidentes) el especialista sabe (en base a su experiencia) que existen tres factores de riesgo. 1) La combinacin de la peligrosidad del proceso y la falta de experiencia en seguridad industrial del integrador (X21.1) 2) La combinacin de la peligrosidad del proceso y la falta de experiencia en seguridad industrial del cliente (X21.2). 3) Un proceso peligroso y complejo (X21.3). Para estimar X21.1 se analizan los valores del atributo experiencia en seguridad industrial de la clase CLIENTE mediante las siguientes inferencias
SI La experiencia en seguridad industrial del integrador es muy mala Y el proceso industrial es muy peligroso. ENTONCES X21.1= 1 SI La experiencia en seguridad industrial del integrador es mala Y el proceso industrial es muy peligroso. ENTONCES X21.1= 0.75
109
SI La experiencia en seguridad industrial del integrador es regular Y el proceso industrial es muy peligroso. ENTONCES X21.1= 0.50 SI La experiencia en seguridad industrial del integrador es buena Y el proceso industrial es muy peligroso. ENTONCES X21.1= 0.25 SI La experiencia en seguridad industrial del integrador es muy buena Y el proceso industrial es muy peligroso. ENTONCES X21.1= 0
Notemos que dado que W21.1= 0.4 cuando X21.1= 1 este factor contribuye en un 40 % en la aparicin de R21 mientras que si X21.1= 0 la contribucin es nula. De manera similar se obtienen X21.2 y X21.2, notemos que esta inferencia se realiz con un proceso de mucha peligrosidad, es necesario implementar inferencias que tengan en cuenta los diferentes grados de peligro, en el captulo 5 seccin 5.5.1 (diseo de inferencias) se detalla el diseo de un mecanismo que tiene en cuenta estas variantes Mediante este tipo de inferencias se establecen los valores Xi,j de todos los Ri, (en la seccin 5.4.1 y en el apndice E1 se detallan las mismos). 4.3.5.2 Identificacin de inferencias de calidad de anlisis de riesgo En muchos casos la informacin de contexto volcada al SGR puede ser pobre, como consecuencia el anlisis de riesgo y las soluciones sugeridas por el sistema pueden ser errneas, en estos casos diremos que la fiabilidad del anlisis de riesgo es mala. Para establecer la calidad del proceso de GR se establecen cinco niveles de fiabilidad: muy buena, buena, regular, mala y muy mala A continuacin se describen las inferencias que evalan la calidad del proceso de gestin de riesgos.
110
SI Todos los atributos esenciales del cuestionario TBQ-SAC han sido completados Y Se han completado los atributos ms del 70 % de los atributos No esenciales del TBQ-SAC ENTONCES La fiabilidad del Anlisis de Riesgo es muy buena
SI Todos los atributos esenciales del cuestionario TBQ-SAC han sido completados Y Se han completado los atributos menos del 70 % de los atributos No esenciales del TBQ-SAC ENTONCES La fiabilidad del Anlisis de Riesgo es buena
SI Se han completado los atributos menos del 70 % de los atributos esenciales del TBQ-SAC Y Se han completado los atributos ms del 70 % de los atributos No esenciales del TBQ-SAC ENTONCES La fiabilidad del Anlisis de Riesgo es regular
111
SI Se han completado los atributos menos del 70 % de los atributos esenciales del TBQ-SAC Y Se han completado los atributos menos del 70 % de los atributos No esenciales del TBQ-SAC ENTONCES La fiabilidad del Anlisis de Riesgo es mala
SI La fiabilidad del Anlisis de Riesgo es regular O La fiabilidad del Anlisis de Riesgo es mala ENTONCES Se recomienda al usuario completar datos mediante entrevistas con clientes, integradores proveedores y terceros. Luego de ello completar nuevamente el cuestionario TBQ-SAC.
4.3.5.3 Identificacin de Inferencia de medidas preventivas Se analizan los factores de riesgo de Xi,j de los cinco riesgos prioritarios y Xi,j>=0,5 entonces es necesario proponer una solucin al usuario (CU 21). si
Por ejemplo: Si R21 tiene prioridad 1 y X21,1 0,5 quiere decir que el integrador no cuenta con conocimientos suficientes de seguridad industrial para el ambiente en el que se desarrolla el proceso, la solucin es capacitar al integrador en el rea de seguridad industrial. Como regla general el especialista evala los factores de riesgo y adopta como criterio que si los mismos son mayores a 0,5 en un riesgo prioritario, es necesario sugerir una solucin.
En la seccin 5.4.3 (Diseo de inferencias de medidas preventivas) se detalla la inferencia de referencia. 4.3.6 Definicin de interfases de usuario 4.3.6.1 Especificaciones de principios generales de la interfaz La interfaz est constituida por: - Men principal (1 pantalla). - Formulario TBQ-SAC (19 pantallas relacionadas con CU 11). - Anlisis de riesgos (1 pantalla relacionada con C12). - Riesgos prioritarios (1 pantalla relacionada con C13). - Detalle de riesgos prioritarios (5 pantallas relacionadas con CU 13). - Soluciones propuestas (5 pantallas relacionadas con CU 21). - Calidad del proceso de gestin de riesgos (1 pantalla relacionada con C U3). - Parametrizacin del SGR (1 pantalla relacionada con CU 4). - Ayudas. Men principal: En la figura 4.3.6.1.a se ilustra el aspecto de esta pantalla, la misma consta de cuatro botones principales y tres secundarios permiten el acceso a: - Formulario TBQ-SAC. - Anlisis de riesgo. - Riesgos prioritarios. - Visualizacin de las soluciones propuesta por el sistema. - Acceso a la parametrizacin del SGR, una ayuda contextual y salida del SGR.
113
Figura 4.3.6.1 a Men principal del SGR.
Formulario TBQ-SAC Est constituido por diecinueve pantallas: Men de acceso a clases del TBQ-SAC (1). Datos de la clase a analizar (9). Seleccin de instancias a analizar (9). El usuario debe completar los datos de las clases a analizar: - CLIENTE. - CONTRATO. - INTEGRADOR. - HARDWARE. - HERRAMIENTAS.
114
- PROCESO. - PROYECTO. - PROVEEDOR. - TERCERO. El Men de acceso a clases del TBQ-SAC (figura 4.3.6.1. b) permite el acceso a las clases citadas.
Anlisis de riesgo
Figura 4.3.6.1.b Men de acceso a componentes del formulario TBQ-SAC.
Las pantallas asociadas a cada una de las clases del TBQ-SAC permiten leer, escribir y/o modificar los atributos de las mismas, mediante campos con valores lingsticos predeterminados.
Figura 4.3.6.1.c Lectura, escritura y modificacin de datos del cliente seleccionado.
Por ejemplo el usuario puede asignar al atributo conocimientos del proceso del cliente Cementera Piedradura, uno de los seis valores predeterminados por el formulario: MB: Muy bueno (0) B: Bueno (0,25) R: Regular (0,50) M: Malo (0,75) MM: Muy Malo (1) ?: No hay datos (1) Se especifica entre parntesis el valor numrico que asigna la respuesta para la estimacin del factor de riesgo que trae aparejado la falta de conocimiento del proceso a automatizar. En nuestro ejemplo Bueno X ij = 0.25, esta valoracin del factor de riesgo es utilizada para calcular la probabilidad P i de riesgo mediante la ecuacin 4.3.4.3.a (seccin 4.3.4.3, pgina 101), De manera similar se asigna el resto de los atributos de la clase CLIENTE.
116
El botn SELECCIONAR CLIENTE permite acceder a una pantalla de seleccin de CLIENTE. En la figura 4.3.6.1.d se ilustra de qu manera el Usuario SGR selecciona la instancia Cementera Piedradura.
Figura 4.3.6.1.d Seleccin de cliente.
El botn GUARDAR permite guardar los datos del cliente (bajo el mismo nombre o crear un cliente nuevo (nueva instancia de la clase CLIENTE). El botn ? permite acceder a la ayuda contextual de esta pantalla. El resto de las clases del TBQ SAC presentan una estructura similar a las descriptas en las figuras 4.3.6.1.c y 4.3.6.1.c. Calidad del proceso de gestin de riesgos Una vez que usuario ha completado los datos de las nueve clases, puede disparar el anlisis de riesgo mediante el botn correspondiente desde el men principal (Figura 4.3.6.1.a, pgina 114) o desde el Men de acceso a componentes del formulario TBQ-SAC (Figura 4.3.6.1.b, pgina 115). El sistema informar al usuario sobre la calidad del anlisis que realizar y disparar el mismo solamente si el usuario considera que el mismo es fiable.
117
Evaluacin de la calidad del anlisis de riesgo
Figura 4.3.6.1.e Evaluacin de calidad del anlisis.
118
Anlisis de riesgo Si el usuario selecciona NO, se abre nuevamente el Men de acceso a componentes del formulario TBQ-SAC (Figura 4.3.6.1.b). Si selecciona SI se accede a los resultados del anlisis de riesgo (Figura 4.3.6.1.f). El usuario puede ver en forma numrica y grfica (barras) la valorizacin de los 33 riesgos posibles en un proyecto SAC (CU 12).
Figura 4.3.6.1.f Perfil de riesgos.

Mediante el botn VER DETALLES Y SOLUCIONES PRIORITARIOS accede a los cinco riesgos prioritarios.
DE
RIESGOS
Figura 4.3.6.1.g Riesgos que requieren atencin prioritaria.
En la figura 4.3.6.1.g, se visualiza la representacin grfica y numrica de la exposicin (RE) de los cinco riesgos prioritarios. Mediante las teclas de detalles, se puede visualizar de qu manera el SGR calcul el riesgo y las sugerencias para mitigarlo o anularlo. En la Figura 4.3.6.1.h podemos observar el detalle de R19. R19 Prdida de personal difcil de reemplazar
Se detalla la probabilidad estimada, el impacto promedio y la composicin del mismo. En la misma, el sistema sugiere una serie de medidas para retener el personal.
120
Tambin se detalla en que etapas del proyecto tendr lugar el impacto (programacin y puesta en marcha).
Figura 4.3.6.1.h Detalle del anlisis del riesgo R19 y soluciones sugeridas por el SGR
Mediante el botn VER DETALLES DEL RIESGO SELECCIONADO (R1 a R33) (Figura 4.3.6.1.g, pgina 120) se puede acceder al detalle del riesgo de cualquiera de los 33 riesgos (aunque no sea prioritario). Parametrizacin Est conformada por dos pantallas - Ingreso de clave de acceso a los parmetros del SGR (CU 4). - Modificacin de parmetros (CU 4).
Se accede a las mismas desde el men principal mediante la tecla PARAMETRIZAR (figura 4.3.6.1.a, pgina 114). El acceso a la pantalla de optimizacin de los parmetros del SGR (K, W y L) est restringido a los administradores del sistema, por ello es necesario contar con la pantalla Ingreso de clave de acceso a los parmetros del SGR (Figura 4.3.6.1.i)
Figura 4.3.6.1.i Ingreso de clave de acceso a parmetros del SGR
Si la clave no es correcta el sistema niega el acceso a la parametrizacin, si es correcta se accede a la misma (figura 4.3.6.1.j) En la pantalla de parametrizacin se pueden modificar los pesos de los factores de riesgo Wijj, la constante Ki y los impactos Li. Se debe seleccionar el riesgo y comprobar mediante el botn CHEQUEO DE PARAMETROS si los valores son coherentes (sumatoria de pesos =1, impacto promedio 100%):
122
Figura 4.3.6.1.j Parametrizacin del SGR
4.3.6.2 Especificaciones de perfiles y dilogos. Perfiles: Tenemos dos perfiles posibles - Usuario de SGR (Integrador, Cliente o Proveedor). - Administrador. El Usuario del SGR puede acceder y modificar datos de todas las pantallas salvo la parametrizacin del SGR, solamente el Administrador del sistema puede acceder a esta funcin.
123
Dilogos: Cuestionario TBQ-SAC. Como primer paso El SGR solicitar al usuario que complete todas las preguntas necesarias para comenzar el proceso de identificacin de riesgos (CU 11). Para ello deber informar el contexto en el que se desarrolla el proyecto: - 1 Caractersticas del Integrador (CU 111). - 2 Caractersticas del Cliente (CU 112). - 3 Caractersticas del Proveedor de Equipos de SAC (CU 113). - 4 Caractersticas del Proceso (CU 115). - 5 Caractersticas del Proyecto (CU 117). - 6 Caractersticas del Hardware (CU 118). - 7 Caractersticas del Herramientas de desarrollo (CU 119). - 8 Caractersticas del Contrato (CU 114). - 9 Caractersticas de terceros (CU 116). Una vez que se han completado los nueve cuestionarios (segn las caractersticas de las clases asociadas al TBQ-SAC), el SGR informa al usuario si el anlisis es fiable (en funcin de los datos volcados mediante el cuestionario TBQ-SAC), luego procede a iniciar el anlisis de riesgos. En forma secuencial y con el consentimiento del usuario el SGR presenta la siguiente informacin: - Perfil de riesgos del proyecto (CU 12). - Riesgos prioritarios (CU 13). - Detalles de riesgos prioritarios (CU 13). - Soluciones de riesgos prioritarios (CU 13). El usuario podr consultar tambin: - Detalles de riesgos NO prioritarios (CU 12). - Soluciones de riesgos NO prioritarios (CU 12).
124
4.3.6.3 Especificaciones de formatos individuales de la interfaz. Estructuras de pantallas: Las pantallas tendrn el aspecto y estructura indicados en las figuras 4.3.6.1.a, 4.3.6.1.b, 4.3.6.1.c, 4.3.6.1.d, 4.3.6.1.e, 4.3.6.1.f, 4.3.6.1.h, 4.3.6.1.i y 4.3.6.1.j Formato de Textos: Los textos de los campos y botones de comando tendrn formato arial, tamao de textos: 12. Ayudas: Cada pantalla dispondr de una tecla de ayuda que suministrar textos que guiarn al usuario dentro de la interfase de operacin activa. El propsito de las mismas, es que el usuario disponga permanentemente de un manual on-line, que se ubicar en el contexto del la interfase que est operando. Fondos de pantalla: Los fondos de pantalla del formulario TBQ-SAC sern de color gris de manera de evitar que la brillantez del fondo provoque fatiga en la vista del usuario. En las pantallas que muestran los resultados del anlisis se utiliza el fondo blanco para resaltar los mismos. Advertencias.: Las advertencias se visualizarn con textos con letras rojas y fondos amarillos, las alarmas con letras amarillas y fondo rojo. El objetivo de las mismas es prever que el usuario cometa errores de operacin. 4.3.6.4 Especificaciones de formatos dinmicos de la interfaz A continuacin en las figura Fig. 4.3.6.4.a , 4.3.6.4.b, 4.3.6.4.c y 4.3.6.4.d se ilustran los esquemas de navegacin, las pantallas han sido simplificadas para esquematizar ms claramente el proceso.
125
Men principal del SGR

TBQ-SAC Contexto Anlisis de riesgo Prioridades Solucin
Parmetrizacin
Fig. 4.3.6.4.b
Fig. 4.3.6.4.c
Men de acceso a componentes del formulario TBQ-SAC. (ver figura 4.3.6.1.b)

Cliente Integrado Proveedor Proceso Contrato Proyecto Hardware
X Escape
Herramienta de desarrollo Terceros Cerrar pantalla y volver a la anterior.
Terceros Herramienta de desarrollo Hardware Proyecto X Contrato X Proceso

Nombre Integrador Cuit Estado financiero Cliente Actividad Ver figura 4.3.6.1.c Conocimientos del proceso . Nombre : Cementera Piedradura Cuit . Estado financiero Actividad Conocimientos del proceso . Seleccin .
X X X X
Proveedor
X X X
Seleccin de Cliente Cementrera Piedradura Singapur Foods
Fig. 4.3.6.4.a: Navegacin desde pantalla principal a Cuestionario TBQ-SAC.
126

Parmetrizacin
Calidad del anlisis de riesgo Fiabilidad: - - - - - - Desea iniciar anlisis de riesgo? (Ver figura 4.3.6.1.e)
SI NO
Men de acceso a componentes del formulario TBQ-SAC.
Perfil de riesgos
R01 R02 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - R33
(Ver figura 4.3.6.1.f)
Fig. 4.3.6.4.b : Navegacin desde pantallas de anlisis de riesgo.
127
Perfil de riesgos
R01 R02 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - R33
Seleccionar
R18 R19 R20 TBQ-SAC Contexto Ver detalles y soluciones de riesgos prioritarios Ver detalles y soluciones de riesgo seleccionado (1 a 33)
Riesgos que requieren atencin prioritaria. (Ver figura 4.3.6.1.g)
100 R21
Detalle Prioridad 1
37 R29
Detalle Prioridad 2
27 R19
Detalle Prioridad 3
24 R33
Detalle Prioridad 4
22 R02
Detalle Prioridad 5
Detalle del anlisis del riesgo R19 y soluciones sugeridas por el SGR ( Ver figura 4.3.6.1.h)
R19: Prdida de personal clave

Soluciones: Mejorar sueldos e incentivos
Fig. 4.3.6.4.c: Navegacin desde pantallas de riesgos prioritarios.
128

Parmetrizacin
Ingreso de clave de acceso a parmetros del SGR (Ver Figura 4.3.6.1.i )
Clave :
Correcta
Clave X INCORRECTA
Parametrizacin
W1: 0.40 W2: 0.18 W3: 0.22 W4: 0.20 W5: 0.00 W6 :0.00
Impacto economico : Impacto crononograma : Impacto seguridad : Impacto tcnico :
15 25 90 22
Fig. 4.3.6.4.c: Navegacin a pantalla de parametrizacin del SGR.
129
4.3.6.5 Especificacin de formato de impresin. Por criterios ecolgicas se trata de minimizar el uso de papel, por esta razn slo se prev un botn que activa la copia de la pantalla actual. 4.4 Especificacin del plan de pruebas. El IS especifica un plan de pruebas basado en la gran cantidad de datos y resultados recopilados de proyectos de SAC anteriores 4.4.1 Definicin de alcance de las pruebas La idea es valorar los resultados de la adaptacin de mtodos y modelos que han tenido xito en la ingeniera del software, al rea de desarrollo de software para sistemas de automatizacin y control. Los resultados se compararn con los que el especialista obtiene en su forma tradicional de trabajo. Luego se tratar de llevar al SGR a posiciones lmites simulando datos incompletos y/o errneos. En la tabla 4.4 se resume la planificacin de pruebas: Tcnica
Comparacin frente a resultados conocidos
Carga de prueba
Casos histricos con solucin conocida Caso aleatorio Casos seleccionados Casos reales
Patrn de referencia
Comparar resultados del SGR con los histricos
Juego aleatorio Comparacin frente a un especialista en GR Juego de ensayo Ensayo en paralelo
Comparar resultados del SGR con los obtenidos por el especialista
Anlisis de sensibilidad
Casos aleatorios Sensibilidad a variaciones donde se provocan en las entradas variaciones de entrada Sensibilidad a errores en las entradas Casos con entradas invlidas
Las salidas de los casos variados deben ser semejantes No debe producirse salida y debe dar mensaje de error
Tabla 4.4: Planificacin de pruebas de SGR.

4.4.2 Definicin de requisitos del entorno de pruebas - Lugar: Oficinas de un integrador de confianza. - Hardware mnimo: PC stand -alone, Pentium III. - Sistemas operativos: Windows 2000 o XP. 4.5 Implementacin de revisin de requisitos. La revisin de los requisitos se efectu mediante el siguiente checklist [UPM, 2005]:
Nr. Pregunta Evaluacin del contenido de requisitos. 4.5.1 4.5.2 4.5.3 4.5.4 4.5.5 4.5.6 4.5.7 4.5.8 4.5.9 Estn especificadas todas las entradas del sistema? Estn especificadas todas las salidas del sistema? Estn especificadas todas las interfases necesarias? Se han especificado todas las tareas que el usuario quiere realizar? Se ha especificado el tiempo esperado de respuesta? Se ha especificado el lmite de memoria? Se ha especificado el lmite de almacenamiento? Se ha especificado la mantenibilidad del sistema? Se ha especificado la fiabilidad? SI SI SI SI SI SI SI SI SI SI NO NO NO NO SI NO SI NO SI Resultado esperado
Completitud de requisitos. Son los requisitos completos en el sentido de que si el producto 4.5.10 satisface todos los requisitos ser aceptable? 4.5.11 Surgen dudas acerca de alguna parte de los requisitos? 4.5.12 Son algunas partes del sistema imposibles de implementar? 4.5.13 Son algunas partes del sistema imposibles de probar? Calidad de requisitos 4.5.14 Existen requisitos contradictorios? 4.5.15 Son comprensibles los requisitos? 4.5.16 Existen requisitos redundantes o que puedan unificarse? Los requisitos estn a un nivel suficientemente consistente para 4.5.17 especificar el diseo? 4.5.18 Es necesario especificar algn requisito con ms detalle? 4.5.19 Es cada requisito testeable? Tabla 4.5 Checklist de requisitos
131
El cuestionario se aplic en forma iterativa (detectando y corrigiendo defectos) hasta obtener el resultado esperado. Defectos buscados: Correccin, Complencin, Ambigedad, Claridad. 4.6 Resultados de revisiones de requisitos. A continuacin se describen los resultados generales de las revisiones de requisitos. Para simplificar la lectura de los mismos se adopt la convencin establecida en las tablas 4.6.1, 4.6.2, y 4.6.3.
Cdigo de colores de resultados de revisiones de requisitos No se detectan defectos Presencia de defecto Tabla 4.6.1 Resultados de revisiones de requisitos. Defecto buscado Ambiguedad Claridad Correccin Complencin Tabla 4.6.2 Cdigo del tipo de defecto detectado. Descripcin 0 1 2 Tabla 6.4.3 Nmero de correccin. Requisito original Primera correccin de requisitos Segunda correccin de requisitos Cdigo de defecto A Cl Cr Cm
En los casos en los cuales se detecta defecto, se detalla el mismo en el informe de defectos correspondiente.
132
Revisin N
CU111 CU112 CU113 CU114 CU115 Nivel bajo de abstraccin CU116 CU117 CU118 CU119 CU121 CU122 CU131 CU132 CU 211 CU212 CU221 CU222 CU11 CU12 Nivel medio de abstraccin CU13 CU21 CU22 CU31 CU32 CU33 CU41 CU42 CU43 CU44
Resultados del checklist 0 1 2

A A A A A A A A A
Fecha de revisin
Revisin 0: Revisin 1: Revisin 0: Revisin 1: Revisin 0: Revisin 1: Revisin 0: Revisin 1: Revisin 0: Revisin 1: Revisin 0: Revisin 1: Revisin 0: Revisin 1: Revisin 0: Revisin 1: Revisin 0: Revisin 1: 5/5/5 6/5/5 5/5/5 6/5/5 5/5/5 6/5/5 5/5/5 6/5/5 5/5/5 6/5/5 5/5/5 6/5/5 5/5/5 6/5/5 5/5/5 6/5/5 5/5/5 6/5/5
Observaciones
Ver defecto R 1
Revisin 0: 5/5/5 Revisin 0: 5/5/5 Revisin 0: 5/5/5 Revisin 0: 5/5/5 Revisin 0: 5/5/5 Revisin 0: 5/5/5 Revisin 0: 5/5/5 Revisin 0: 5/5/5
Casos de uso
Requisitos
Revisin 0: 5/5/5 Revisin 1: 6/5/5 Revisin 0: 5/5/5 Revisin 0: 5/5/5 Revisin 0: 5/5/5 Revisin 0: 5/5/5 Revisin 0: 5/5/5 Revisin 0: 5/5/5 Revisin 0: 5/5/5 Revisin 0: 5/5/5 Revisin 0: 5/5/5 Revisin 0: 5/5/5 Revisin 0: 5/5/5
Ver defecto R 1
Los casos de uso de nivel medio se probaron luego de depurar los casos de uso de bajo.
Tabla 4.6.4: Resultados generales de la revisin de requisitos.

133
Revisin N
CU 1 Alto nivel de abstraccin CU 2 CU 3 CU 4 Casos de uso
Fecha de revisin
Revisin 0: 9/5/5 Revisin 0: 9/5/5 Revisin 0: 9/5/5 Revisin 0: 9/5/5
Observaciones
Los casos de uso de alto nivel se probaron luego de depurar los casos de uso de nivel bajo y medio. Ver defecto R 2
Requisitos
Frmulas Inferencias
Cl
Revisin 0: 10/5/5 Revisin 1: 10/5/5 Revisin 0: 11/5/5
Cm Interfases de usuario Cm Clases asociaciones y atributos Relaciones Plan de pruebas
Revisin 0: 12/5/5 Revisin 1: 14/5/5 Revisin 0: 2/5/5 Revisin 1: 14/5/5 Revisin 0: 15//5/5 Revisin 0: 15/5/5 Revisin 0: 15/5/5
Ver defecto R 3 Ver Defecto R 4
Tabla 4.6.4 (Continuacin): Resultados generales de la revisin de requisitos. Defecto R1: La descripcin de CU 11 Identificacin de riesgos resulta ambigua e incompleta. Correccin: Descomponer en una sub-funcin para cada clase de la taxonoma. Defecto R2: La descripcin de la frmula P(i) no resulta clara. Correccin: Ampliar la descripcin de los trminos de P(i) y completar con un par de ejemplos en diferentes contextos. Defecto R3; En la definicin de la interfase Datos del cliente falta un campo que permita ingresar los datos de conocimientos del proceso que tiene el cliente. Correccin: Agregar el campo en cuestin.
Defecto R4; Falta definir una interfase que habilite el acceso a la parametrizacin. Correccin: Especificar una interfase de control de acceso a parametrizacin.
Tabla 4.6.5 (Continuacin) Resultados detallados de la revisin de requisitos.
La planificacin general del control de calidad del software se describe en el apndice D (Interfase aseguramiento de la calidad).
135
CAPTULO 5 DISEO DEL SISTEMA DE INFORMACIN
Captulo 5: Diseo del SI
136
137
5 Introduccin En esta seccin se describen las siguientes actividades: - Definicin de la arquitectura del SGR (seccin 5.1). - Diseo de clases (seccin 5.2). - Diseo de interfases de usuario (seccin 5.3). - Diseo de inferencias (seccin 5.4). - Diseo de algoritmos (seccin 5.5). - Diseo de procedimientos (seccin 5.6). - Diseo del entorno tecnolgico (seccin 5.7). - Interfases con otros sistemas (seccin 5.8). - Completar el plan de pruebas del SGR (seccin 5.9). 5.1 Arquitectura del sistema
SERVIDOR / Usuario 1 (local)
SI SGR
IU-SGR
IPA -SGR
BD SGR
BD DDE Externa
RED
Usuario 2 Usuario3 Usuario N <- - - - - - - - CLIENTES - - - - - ->
Figura 5.5.1 Arquitectura del SGR.
138
En la figura 5.5.1 se describe la arquitectura del SGR, el mismo est constituido por: BD-SGR: Base de datos SGR, contiene todas las clases e instancias del proceso de GR IPA-SGR: Contiene las Inferencias, Procedimientos y Algoritmos necesarios para ejecutar un proceso de GR. IU-SGR: Representa las interfases de usuario que conforman el SGR (cuestionario TBQ-SAC ms la visualizacin y control del SGR) Estos tres elementos residen en una estacin de trabajo (CPU) que permite la operacin local del mismo, se prev la posibilidad de ampliar el sistema mediante una arquitectura cliente servidor. Debido a que todos los integradores cuentan con PCs conectadas mediante redes LAN (Local Area Interface) y WAN (Wide Area Interface) operando en entornos de Windows 2000 o XP, se deja abierta la posibilidad de exportacin e importacin de datos a una base de datos externa (localizada en el servidor). El trfico de datos se realizar mediante la funcin DDE (Dynamic Data Interchange) de Windows. El propsito del prototipo a construir, es comprobar y depurar los requerimientos y el diseo del SGR, por esta razn se limita el alcance de este trabajo al usuario local, dejando preparada la posibilidad de intercambio de datos con clientes de red a travs de la base de datos externa. 5.2 Diseo de clases Tomando como referencia la metodologa de cuestionario basado en la taxonoma de riesgo del software (seccin 2.3.5, pgina 36 ) y la experiencia del especialista, se adapta la idea a SAC estableciendo en primer lugar las clases que contienen los atributos que se convertirn en la preguntas del cuestionario: - CLIENTE (CU 112). - CONTRATO (CU 114). - HARDWARE (CU 118). - HERRAMIENTAS DE DESARROLLO (CU 119). - INTEGRADOR (CU 111). - PROCESO (CU 115).
Captulo 5: Diseo del SI 139 Autor: Ing. Jos Luis del Ro
- PROVEEDOR (CU 113). - PROYECTO (CU117). - TERCERO (CU116). En el cuestionario TBQ estndar, los atributos toman el valor verdadero o falso, en el cuestionario TBQ-SAC se deja de lado esta lgica binaria, pudiendo asignar hasta 6 valores a un atributo, el objetivo de esta modificacin es dar mayor precisin al calculo de P i y RE i. En la tabla 5.2.1.a se detallan las abreviaturas utilizadas para asignar valores en el diseo de clases
VALORES Abreviatura MB B R M MM AA A MD BJ BB Descripcin Muy bueno Bueno Regular Malo Muy Malo Muy alto Alto Medio Bajo Muy bajo No existe Existe Valor desconocido
Tabla 5.2.1.a Abreviaturas de valores de atributos de clases.
Los resultados de la identificacin de riesgo y clculos asociados se almacenan en la clase RIESGOS. Cada riesgo tendr asociada una o varias soluciones, la clase SOLUCIN tiene por objetivo agrupar las mismas. La columna tipo tiene por objetivo diferenciar los atributos segn los criterios establecidos en la tabla 5.2.1.b.
140
Tipos Abreviatura E NE SGR ADM Descripcin Atributo esencial para TBQ-SAC (ingresado por el usuario) Atributo NO esencial para TBQ-SAC (ingresado por el usuario) Atributo calculado/estimado por el sistema SGR Atributo ingresado por el administrador del sistema
Tabla 5.2.1.b Tipo de atributo.
5.2.2 Jerarquas de clases Se establece una estructura jerrquica que permite que cada instancia herede los atributos de la clase genrica, por ejemplo la empresa de integracin AUTOMATIC SRL heredar los atributos de la clase INTEGRADOR, el cliente la CEMENTARA PIEDRADURA heredar los atributos de la clase CLIENTE. Luego de disear las clases CLIENTE, INTEGRADOR, PROVEEDOR y TERCERO el IS consider conveniente definir una superclase denominada EMPRESA que posee atributos comunes a estas cuatro clases y permite que la mismas hereden los mismos de la superclase. De manera similar surge la necesidad de crear una superclase denominada EQUIPO de la cual heredan sus atributos las clases HARDWARE y HERRAMENTAS DE DESAROLLO. 5.2.3 Instancias Sern creadas y modificadas por el usuario por medio de las interfases relacionadas con el TBQ-SAC, el SGR necesita al menos una instancia de cada una de las clases relacionadas con el cuestionario (CLIENTE, CONTRATO, HARDWARE, HERRAMIENTAS DE DESARROLLO, INTEGRADOR, PROCESO, PROVEEDOR, PROYECTO, TERCERO) para poder realizar el proceso de GR. En el caso de la clase RIESGO la cantidad de instancias est limitada a 33 (una por cada tipo de riesgo), algo similar ocurre con las instancias de la clase SOLUCIN que estn limitadas a 23 instancias. Para ambas clases, las instancias sern definidas por el IS pero en el caso de las instancias de la RIESGO un Administrador podr modificar los valores de los Wi,j , Ki y Li con el objetivo de optimizar las prestaciones del SGR a distintos entornos de trabajo (mercados, pases, etc.).
141
5.2.4 Descripcin detallada de clases A continuacin se detallan cada una de las clases citadas:
CLASE Nombre Cuil Estructura Atributo (Slot) Descripcin Abreviatura CL:Nomb CL:Cuil CL:Est Tipo E NE E NE E E E VALOR Alfanumrico, ? Nmero, ? Pequea, Grande, ? MB, B, R, M, MM,?
Estado econmico- financie. CL:EFin Equipo de Ingeniera propio Conocimientos del proceso a automatizar Conocimientos y experiencia en seguridad industrial. CL:Ing CL:Conocimiento CL:ExpSegInd
, , ?
MB, B, R, M, MM, ,? MB, B, R, M, MM, ,? Alimenticia, Acero, Automotriz, Aeroespacial, Aeronutica, Cementera, Energa Nuclear , Farmacutica, Ferrocarriles, Generacin de Energa, Metalrgica, Petrolera, Petroqumica , Papelera, Plsticos, Qumica, Siderurgia , Textil,? AA, A, MD, B, BB, ,? MB, B, R, M, MM,? MB, B, R, M, MM,? MB, B, R, M, MM,? Cercana , Lejana MB, B, R, M, MM, ? Alfanumrico Nmero Monto Global, Administracin MB, B, R, M, MM, ?
Cliente
Tipo de actividad
CL:Activ
Contrato
Estndares de Calidad (Exigencias) Estndares de Mantenimiento Flexibilidad Cooperacin Ubicacin Capacidad de coordinacin del proyecto Nombre Cdigo Tipo Descripcin de especificaciones Clusulas limitativas Intereses punitorios Flexibilidad Estado
CL:ECalid CL:EMant CL:Flex CL:Coop CL:Lugar CL:GP CONT: Nomb CONT: :Codi CONT:Tipo CONT:Esp CONT:CLim CONT:IP CONT:Flex CONT:Estado
NE NE E E E E E E E E E E E
, , ?
AA, A, MD, B, BB, ? MB, B, R, M, MM, ? Cotizacin, Adjudicacin, ?
142
Tabla 5.2.4 Descripcin detallada de clases.
143
CLASE
Atributo Descripcin Nombre Cdigo Fiabilidad Tecnologa Costo Tiempo de reposicin Respaldo tcnico/comercial Tipo de equipo Conectividad Tipo de programacin Nombre Cdigo Fiabiliad Tecnologa Costo Amigabilidad Manejo integral del proyecto Control de configuracin Diseo arquitectnico Nombre Cuil Estructura Estado econmico-financi. Calificacin Experiencia en PLC Experiencia en HMI Abreviatura HW:Nomb HW:CodiI HW:Fiab
HW:Tecn HW:Cost HW:TRep HW:Resp HW:Tipo HW:Conec HW:Prog
Tipo E E E
NE NE E E E NE E
VALOR Alfanumrico Nmero Baja, Alta MB, B, R, M, MM AA, A, MD, B, BB AA, A, MD, B, BB MB, B, R, M, MM, PLC , HMI , SCADA ,RED, Driver AC, Driver CC, Servo MB, B, R, M, MM, Lineal, estructurada, OO Alfanumrico Nmero MB, B, R, M, MM MB, B, R, M, MM Nmero MB, B, R, M, MM MB, B, R, M, MM, MB, B, R, M, MM, MB, B, R, M, MM, ,? Alfanumrico Nmero Pequea, Grande Malo , Bueno No certificado , Certificado MB, B, R, M, MM, ,? MB, B, R, M, MM, ,? MB, B, R, M, MM, ,? MB, B, R, M, MM, ,? MB, B, R, M, MM, ,? MB, B, R, M, MM, ,? MB, B, R, M, MM, ,? MB, B, R, M, MM, ,? MB, B, R, M, MM, ,? MB, B, R, M, MM, ,?
Hardware
Herramienta de desarrollo
HD:Nomb HD:Codi HD:Ffiab HD:Tec HD:Cost HD:Amig HD:MIP HD:CConf HD:DArq INTEG:Nomb INTEG:Cuil INTEG:Est INTEG:EFin INTEG:Calif INTEG:ExpPLC INTEG:ExpHMI INTEG:ExpSCA INTEG:ExpSERV INTEG:ExpACC INTEG:ExpIPC INTEG:ExpNET INTEG:ExpSegInd INTEG:CGral INTEG:GP
E E E E NE E NE NE NE E NE E NE E E E E E E E E E E E
Integrador
Experiencia en SCADA Experiencia en Servos Experiencia en Variadores Experiencia en PC Indust. Experiencia en redes Exp. en seguridad industrial Calificacin general Gestin de proyectos
144
Capacidad trabajo en equipo Carga de trabajo Niv. Sueldos
INTEG:Equipo INTEG:Carga INTEG:NivSueldo
E SGR E
MB, B, R, M, MM, ,? Nmero,? MB, B, R, M, MM, ,?
145
CLASE Nombre Cdigo
Atributo (Slot) Descripcin Abreviatura PI: Nomb PI: Nomb Tipo E NE
VALOR Alfanumrico, ? Nmero, ? Alimenticia, Acero, Automotriz, Aeroespacial, Aeronutica, Cementera, Energa Nuclear , Farmacutica, Ferrocarriles, Generacin de Energa, Metalrgica, Petrolera, Petroqumica , Papelera, Plsticos, Qumica, Siderurgia , Textil,? MB, B, R, M, MM, , ? AA, A, MD, B, BB, ? nmero, ? AA, A, MD, B, BB, , ? Normal, Agresivo AA, A, MD, B, BB, , ? MB, B, R, M, MM, ? Pequeo, Grande, ? AA, A, MD, B, BB, ?
Tipo de proceso
PI: Tipo
Especificacin del proceso Similitud (con procesos relevables) Temperatura ambiente Peligrosidad
PI: Esp PI: Sim PI: Temp PI: Pelig
E E E E E E E E E E
Tipo de ambiente operacin PI: AmbOp Toxicidad PI: Tox PI: Est PI: Dim PI: Complej PI: ReqSeg
Proceso (Industrial)
Estado general de proceso Tamao Complejidad Requerimientos de Seguridad (Industrial) Requerimientos de: Fiabilidad Precisin Velocidad Control combinacional Control Secuencial Control PID Control de velocidad Control de posicin Control IA Grado de conocimiento Cantidad de: Entradas digitales Salidas digitales Entradas analgicas Salidas analgicas Pantallas HMI + SCADA
, ,? , ,? , ,? , ,? , ,? , ,? , ,? , ,? , ,? , ,?
MB, B, R, M, MM,? Nmero Nmero Nmero Nmero Nmero ? ? ? ? ?
PI: ReqFiab PI: ReqPreci PI: ReqVel PI: ReqCComb PI: ReqCSeq PI: ReqCPID PI: ReqCVel PI: ReqCPos PI: ReqIA PI: GradoCon PI: DimED PI: DimSD PI: DimEA PI: DimSA PI: DimPant 146
E E E E E E E E E E E E E E E
Comunicacin Sistemas Corporativos
PI: DimComCorp
NE
, ,?
147
CLASE
Atributo (Slot) Descripcin Nombre Cuil Estructura Estado econmico-financi. Servicio de postventa gral Servicio de postventa local Tiempo de respuesta Capacidad financiamiento Servicios de capacitacin Nombre Cdigo Abreviatura PROV:Nomb PROV:Cuit PROV:Estr PROV:EFinan PROV:SPG PROV:SPL PROV:Tresp PROV:CFinan PROV:Capa PROY: Nomb PROY:Codi PROY: Etapa PROY:Eesf PROY:EReal PROY:Avance PROY: Equipo PROY::FI PROY: FF T:Nomb T:Cuit T:Estr T:EFinan T:CTec T:Act T:Gproy T:Com R: Nomb R: Codi R: Prob R: ImpEco R :ImpCron R :ImpTecn R :ImpSeg R :Impacto R :ER R :Etapa R: Prio E E NE E E E E E E E E NE E NE E E E NE ADM ADM SGR ADM ADM ADM ADM ADM SGR SGR SGR Tipo E NE NE NE E NE E
VALOR Alfanumrico, ? Nmero, ? Pequea, Grande, ? MB, B, R, M, MM,? MB, B, R, M, MM, ,? MB, B, R, M, MM, ,? MB, B, R, M, MM,? MB, B, R, M, MM, ,? MB, B, R, M, MM, ,? Alfanumrico, ? Nmero, ? Oferta , Programacin , Puesta en Marcha, Operacin Nmero [horas], ? Nmero [horas], ? MB, B, R, M, MM, ? Nmero [personas], ? Fecha, ? Fecha, ? Alfanumrico, ? Nmero, ? Pequea, Grande, ? MB, B, R, M, MM, ? MB, B, R, M, MM, ? Montajes elc, Mec. ,Obra Civil, ? MB, B, R, M, MM, ? MB, B, R, M, MM, ? Alfanumrico (ver lista de riesgos) Nmero (ver lista de riesgos) Nmero Nmero Nmero Nmero Nmero Nmero Nmero Cotizacin, Programacin , Puesta en Marcha , Operacin Nmero
Proveedor Proyecto Tercero Riesgo
Etapa actual Esfuerzo estimado Esfuerzo real Avance Equipo asignado Inicio (programado) Fin (programado) Nombre Cuit Estructura Estado econmico-financi. Capacidad Tcnica Actividad Gestin del proyecto Comunicacin Nombre Cdigo Probabilidad de ocurrencia Impacto econmico Impacto en el cronograma Impacto tcnico Impacto en la seguridad Impacto promedio Exposicin a Riesgo Etapa afectada por el riesgo Prioridad
148
149
5.2.5 Lista de riesgos (nmero, nombre) A continuacin se listan los riesgos ms frecuentes en sistemas de automatizacin y control de procesos.
Riesgo R01 R02 R03 R04 R05 R06 R07 R08 R09 R10 R11 R12 R13 R14 R15 R16 R17 R18 R19 R20 R21 R22 R23 R24 R25 R26 R27 R28 R29 R30 R31 R32 R33
Descripcin del riesgo Baja productividad del equipo de desarrollo Baja productividad del proceso automatizado Baja fiabilidad del proceso automatizado Contaminacin ambiental Estimaciones de esfuerzo errneas Especificaciones incompletas o errneas Falta de aceptacin del producto por parte de usuarios Falta de capacitacin / experiencia del personal No cumplir con los estndares del proceso industrial Pago de intereses punitorios por mora o proceso cado Perder el cliente Perder licitacin Prdida de informacin del proceso Prdida de informacin del proyecto Prdida de materia prima Prdida de reputacin en el mercado (Integrador) Prdida de reputacin en el mercado (cliente) Prdida de reputacin en el mercado (Proveedor) Prdida de personal clave, difcil de reemplazar Prdida de representacin/ certificacin del proveedor Prdidas humanas y/o accidentes Prdida / dao de equipos de proceso. Perturbaciones causadas por tercero Problemas en otros proyectos en desarrollo Problemas de facturacin Problemas de mantenimiento (en garanta) Problemas de mantenimiento (fuera de garanta) Problemas legales Sobrecarga de trabajo Software de aplicacin de mala calidad Reserva Robo de herramientas de desarrollo de software Retraso en cronograma de trabajo
Tabla 5.2.5: Lista de riesgos en SAC.
150
5.3 Diseo de interfases de usuario Teniendo en cuenta las especificaciones de la seccin 4.3.6 (definicin de interfases de usuario), se procede a definir los campos de cada una de las pantallas y se completan las interfases de usuario no especificadas en las etapas anteriores. 5.3.1 Interfases del cuestionario basado en la taxonoma de SAC El cuestionario TBQ-SAC, define nueve pantallas de edicin y lectura de atributos: - CLIENTE. - CONTRATO. - HARDWARE. - HERRAMIENTAS DE DESARROLLO. - INTEGRADOR. - PROCESO. - PROVEEDOR. - PROYECTO. - TERCERO. Mediante estas nueve pantallas se puede ingresar, leer y modificar los valores de los atributos instanciados. Los campos de cada pantalla son los especificados como atributos en estas clases. En el caso de variables multivaluadas, surgir un listado desplegable, que permite al usuario elegir una de las opciones preestablecidas, por ejemplo: INTEGRADOR Experiencia en PLC Mala Muy buena (MB) Buena (B) Regular (R ) Mala (M) Muy mala (MM)
Base de datos del SGR
CLASE:Integrador INSTANCIA: Automatic SRL

SLOT INTEG:ExpPLC = M
Fig. 5.3.1 a Asignacin de valores de atributos mediante listados desplegables.

El atributo editado, es actualizado en la base de datos del SGR, mediante el enlace establecido entre el campo de interfase de usuario y el atributo de la instancia.
Automatic SRL
Automatic SRL Robotito SA Tronic SA
Experiencia en PLC
Mala (M)
Pantalla: INTEGRADOR
CLASE INTEG
Base de datos SGR
Instancia INTEG_Selec
Instancia Robotito SA ExpPLC=R
Instancia Automatic SRL
Instancia Tronic SA ExpPLC=MB
Procedimiento Seleccin Integrador
Figura 5.3.1.b Enlace entre el campo seleccionado y la base de datos del SGR.
Para establecer el enlace se crea una instancia de la clase INTEG (Integrador), denominada INTEG_Selec (Integrador seleccionado en pantalla). Esta permite conectar la pantalla Integrador con la instancia seleccionada (Automatic SRL) mediante un procedimiento de seleccin.
El procedimiento Seleccin de integrador tiene por objeto conectar la clase INTEG_Selec con la instancia seleccionada. De manera similar, se establecen los enlaces del resto de las pantallas que conforman el TBQ-SAC:
Enlace Cliente Pantalla Contrato Instancia CL_Selec Instancia Seleccionada Nombre del contrato Procedimiento Seleccin Contrato
Enlace Contrato Pantalla Contrato Instancia CONT_Selec Instancia Seleccionada Nombre del contrato Procedimiento Seleccin Contrato
Enlace Hardware Pantalla Hardware Instancia HW_Selec Instancia Seleccionada Nombre del Hardware Procedimiento Seleccin Hardware
Enlace Herramientas de desarrollo Pantalla Herramienta I Instancia. HD_Selec Instancia Seleccionada Nombre del Hardware Procedimiento Seleccin Hardware
Enlace Proceso Pantalla Proceso Instancia PI_Selec Instancia Seleccionada Nombre del Proceso Procedimiento Seleccin Proceso
153
Enlace Proveedor Pantalla Proveedor Instancia PROV_Selec Instancia Seleccionada Nombre del Proveedor Procedimiento Seleccin Proveedor
Enlace Tercero Pantalla Tercero Instancia T_Selec Instancia Seleccionada Nombre del Tercero Procedimiento Seleccin Tercero
Valores por defecto de campos de pantallas del TBQ-SAC Por defecto estos campos tendrn el valor ?, el objetivo es informar al SGR que el valor de este atributo no fue informado por el usuario. Esta informacin ser til en el momento que el SGR evale la calidad del proceso de gestin. 5.3.2 Interfase de usuario Anlisis de riesgo Una vez que el usuario ha completado el formulario TBQ-SAC o ha seleccionado instancias preexistentes, debe iniciar la funcin Anlisis de riesgo (CU 12). Esta pantalla contiene un botn denominado Ver resultados de Anlisis de riesgo, el mismo dispara: - Inferencias de estimacin de Factores X i,j en base TBQ-SAC (seccin 4.3.5 pgina 54). - Algoritmos de clculo de Pi, REi , PRi. 5.3.3 Interfase de usuario Ver riesgos prioritarios Esta interfase gestiona la funcin Priorizar riesgos (CU 13), para ello dispara el procedimiento Ordenamiento de riesgos segn prioridades y expone los cinco riesgos de mayor prioridad.
154
5.3.4 Interfase de usuario Ver soluciones Esta interfase gestiona la funcin Planificacin de la gestin de riesgos (CU 21), para ello dispara la inferencia Sugerir medidas preventivas y muestra las soluciones posibles para los cinco riesgos prioritarios (figura 4.3.6.1.h, pgina 121). 5.3.5 Interfase de usuario Calidad del proceso de gestin de riesgos Esta pantalla permite ver la evaluacin de la calidad del anlisis de riesgos (CU 3), la misma se implementa mediante una inferencia que determina el grado de fiabilidad del proceso de GR. A partir de los datos ingresados en el cuestionario TBQ-SAC, el SGR infiere la fiabilidad del proceso de gestin de riesgos. Si determin que es baja muestra al usuario las razones de este resultado, sugiriendo medidas para aumentarla fiabilidad del anlisis (figura 4.3.6.1.e, pgina 118). 5.3.6 Interfase de usuario Parametrizacin del SGR El SGR comenzar a operar con los valores de Ki, Wi,j y Li preestablecidos por el especialista, una correcta valorizacin de los mismos garantiza el xito del sistema. Con el objetivo de poder optimizar estos valores sin necesidad de reprogramar el sistema, se incluye la interfase Parametrizacin del SGR. Desde esta pantalla el IS o el Administrador del sistema podrn adecuar los parmetros de referencia, de manera de mejorar la precisin del anlisis realizado por el SGR. Esta interfase de usuario deber contar con una clave de acceso que evite el ingreso de personal no autorizado y/o entrenado para tal fin. Dado que Ki, Wi,j y Li estn almacenados dentro de las 33 instancias de la clase RIESGOS, ser necesario utilizar un mecanismo de enlace similar a los utilizados en el cuestionario TBQ-SAC.
Enlace Riesgo Pantalla parametrizacin Nombre del Riesgo Instancia R_Selec Instancia Seleccionada Procedimiento Seleccin del riesgo
155
5.4 Diseo de inferencias 5.4.1 Diseo Inferencias de estimacin de factores de riesgo X i,j Retomando la inferencia de los factores de riesgos para R21 (seguridad), considerando el CU 1110 y aplicando las definiciones de clases obtenidas en la etapa de diseo (seccin 5.2, pgina 139), podemos re-escribir la inferencia INF 21 como:
INFERENCIA INF 21
SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI Inferencia intermedia PI_Selec: Peligrosidad= AA ENTONCES PI_selec: Peligrosidad= A ENTONCES PI_selec: Peligrosidad= M ENTONCES PI_selec: Peligrosidad= BJ ENTONCES PI_selec: Peligrosidad= BB ENTONCES Peso X21.1 INTEG_Selec: ExpSegInd= MM ENTONCES INTEG_Selec: ExpSegInd= M ENTONCES INTEG_Selec: ExpSegInd= R ENTONCES INTEG_Selec: ExpSegInd= B ENTONCES INTEG_Selec: ExpSegInd= MB ENTONCES Peso X21.2 CL_Selec: ExpSegInd= MM ENTONCES CL_Selec: ExpSegInd= M ENTONCES CL_Selec: ExpSegInd= R ENTONCES CL_Selec: ExpSegInd= B ENTONCES CL_Selec: ExpSegInd= MB ENTONCES Peso X21.3 PI_Selec: Complejidad= AA ENTONCES PI_Selec: Complejidad= A ENTONCES PI_Selec: Complejidad= MD ENTONCES PI_Selec: Complejidad= BJ ENTONCES PI_Selec: Complejidad= BB ENTONCES K W21.1 = 0,4 K21= 0,04 W21.2 = 0,4 W21.3 = 0,2 Calculo de probabilidad M 21= M 21= M 21= M 21= M 21= X 21.1= X 21.1= X 21.1= X 21.1= X 21.1= X 21.2= X 21.2= X 21.2= X 21.2= X 21.2= X 21.3= X 21.3= X 21.3= X 21.3= X 21.3=
W
1 0,75 0,5 0,25 0 M21 x 1 M21 x 0,75 M21 x 0,5 M21 x 0,25 M21 x 0 M21 x 1 M21 x 0,75 M21 x 0,5 M21 x 0,25 M21 x 0 M21 x 1 M21 x 0,75 M21 x 0,5 M21 x 0,25 M21 x 0
P21= K21 (X21.1 W21.1 + X21.2 W21.2+ X21.3 W21.3)
Fig. 5.4.1 a: Inferencia de valores de factores de riesgo para R21.
156
En la figura 5.4.1.a, podemos observar que la inferencia INF 21 analiza los atributos de las instancias relacionadas con el riesgo R21 (Clases PI_Selec, INTEG_Selec y CL_Selec), en base a los mismos determina los valores de los tres factores de riesgo necesarios para calcular P21. Para ejecutar la inferencia, es necesario obtener resultados intermedios relacionados con la valoracin numrica de valores lingsticos preestablecidos (AA, A, M, BJ, MB), el valor inferido se almacena en una memoria (M21), posteriormente el mismo se utiliza para la determinacin de X21.1, X21.2 y X21.3. De manera similar se obtienen las inferencias de los Xi,j para el resto de los riesgos tpicos de SAC, en el apndice E1 se detallan las mismas. Podemos observar que las inferencias utilizadas durante la determinacin de los valores de X21.1, X21.2 y X21.3 pueden ser generalizadas mediante INF X: INF X
ENTRADAS SALIDA SI SI SI SI SI Memo : Nmero real 1 Atributo: String X : Nmero real 1 ENTONCES ENTONCES ENTONCES ENTONCES ENTONCES X = Memo X = Memo x 0,75 X = Memo x 0,50 X = Memo x 0,25 X=0
Atributo= AA o MM o o ? Atributo= A o M Atributo= R o MD Atributo= BJ o B Atributo= BB o MB o
INTEG_Selec: ExpSegInd-------- Atributo M21.1-------Memo
INF X
---- X21.1
Fig. 5.4.1 b: INF X Inferencia reutilizable para clculo de factores de riesgos
Notemos que INF X es una inferencia reutilizable tanto para la estimacin de resultados intermedios Mk como para los factores de riesgos Xi,j. El propsito de INF X es reducir los tiempos y esfuerzos de diseo, codificacin y pruebas de las inferencias de factores de riesgos del SGR. A titulo de ejemplo, se implementa INF21 de manera ms sinttica (el resto de las, inferencias se detallan en el apndice E1). En la figura 5.4.1.c se simplifica la implementacin de INF 21mediante la inferencia reutilizable INFX:
INFERENCIA INF 21
Inferencia intermedia intermedios Atributo= PI_selec: Peligrosidad Memo= 1 X= M21 Ejecutar INF X Peso X21.1 Atributo= INTEG_Selec: ExpSegInd Memo= M21 X= X21.1 Ejecutar INF X Peso X21.2 Atributo= CL_Selec: ExpSegInd Memo= M21 X= X21.2 Ejecutar INF X Peso X21.3 Atributo= PI_Selec: Complejidad Memo= M21 X= X21.3 Ejecutar INF X W K W21.1 = 0,4 K21= 0,04 W21.2 = 0,4 W21.3 = 0,2 Calculo de probabilidad P21= K21 (X21.1 W21.1 + X21.2 W21.2+ X21.3 W21.3)
Fig. 5.4.1 c Ejemplo de clculo de factores de riesgo de R21 mediante INF X.
5.4.2 Diseo de inferencias de calidad de anlisis de riesgo Muchas veces el usuario no conoce el valor de un atributo o por error omite ingresar el valor del mismo, en ese caso asumir un valor por defecto igual a ?. El SGR contabilizar mediante el procedimiento contar atributos la cantidad de atributos esenciales y no esenciales no evaluados (detectando el valor ?). Para el clculo de los porcentajes establecidos en las inferencias de calidad de anlisis de riesgo (seccin 4.3.5.2, pgina 110) el procedimiento toma como base los valores especificados en la tabla 5.4.2, correspondientes al caso ideal en el que se conocen y/o ingresan todas las preguntas del cuestionario TBQ-SAC. En la tabla 5.4.2 se detallan la cantidad total de atributos de las instancias seleccionadas para un anlisis de riesgo:
158
Atributo CL_Selec CONT_Selec HW_Selec HD_Selec INTEG_Selec PI_Selec PROY_Selec PRV_Selec T_Selec TOTAL
Cantidad de atributos Total E 14 14 8 8 10 7 9 5 17 15 29 27 9 4 9 8 8 5 113 93
NE 4 0 3 4 2 2 5 1 3 24
Tabla 5.4.2 Cantidad total de atributos para las clases seleccionadas.
Con los valores citados se aplican las inferencias desarrolladas en 4.3.5.3 para implementar el CU 3. 5.4.3 Diseo de Inferencia de medidas preventivas Segn lo especificado en CU 21 y en la seccin 4.3.5.3 se analizan los factores de riesgo de Xi,j de los cinco riesgos prioritarios y si Xi,j >= 0,5 es necesario buscar solucin:
Desde i=1 a 33 SI La prioridad de R(i) es menor o igual a cinco ENTONCES Desde n=1 hasta m SI El Factor X i.n 0,5 ENTONCES Sugerir Solucin S i.n
Para R21 Si X21.1 0,5 Solucin = S 21.1 S21.1: Capacitar al integrador en seguridad industrial
159
5.5 Diseo de algoritmos En base a las ecuaciones identificadas (seccin 4.3.4, pgina 97) se implementa un algoritmo que ejecuta las mismas.
ALGORITMO Ecuacin 4.3.4..6.a 4.3.4.3.a 4.3.4.2.a 4.3.4.1 4.3.4.4
Nombre EE P L RE PR
Descripcin Estimar esfuerzo Estimar probabilidad Estimar prdida promedio Estimar exposicin a riesgo Calcular prioridad
Caso de uso que incluye al algoritmo C12: Anlisis de Riesgo C12: Anlisis de Riesgo C4: Cambio de parmetros de SGR C12: Anlisis de Riesgo C12: Anlisis de Riesgo
Tabla 5.5.1: Listado de algoritmos de clculo
5.6 Diseo de procedimientos A continuacin se detallan los procedimientos a implementar:

PROCEDIMIENTOS Nombre Ordenar_prio Ident_R_Prio Descripcin Ordena los riesgos segn la prioridad calculada. Identificar los cinco riesgos de mayor prioridad Copia los datos de la instancia seleccionada a la instancia CL_Selec asociada a la interfase de usuario del cuestionario TBQ-SAC Copia los datos de la instancia seleccionada a la instancia CONT_Selec asociada a la interfase de usuario del cuestionario TBQ-SAC Copia los datos de la instancia seleccionada a la instancia HW_Selec asociada a la interfase de usuario del cuestionario TBQ-SAC Copia los datos de la instancia seleccionada a la instancia HD_Selec asociada a la interfase de usuario del cuestionario TBQ-SAC Copia los datos de la instancia seleccionada a la instancia INTEG_Selec asociada a la interfase de usuario del cuestionario TBQ-SAC Evento que dispara procedimiento Fin del anlisis de riesgo (C12) Fin de ordenar riesgo (CU13) Seleccin de cliente desde interfase de usuario (CU 112) Seleccin de contrato desde interfase de usuario (CU114). Seleccin de hardware desde interfase de usuario (CU 118). Seleccin de herramienta de desarrollo desde interfase de usuario (CU 119). Seleccin de integrador desde interfase de usuario (CU 111)
Selec_Cliente
Selec_Contrato
Selec_HW
Selec_HD
Selec_Integ
Tabla 5.6.1 Listado de procedimientos a implementar.

PROCEDIMIENTOS Nombre Selec_PI Descripcin Evento que dispara procedimiento
Copia los datos de la instancia seleccionada a la Seleccin de proceso instancia PI_Selec asociada a la interfase de usuario desde interfase de usuario del cuestionario TBQ-SAC (CU 115) Copia los datos de la instancia seleccionada a la instancia PROY_Selec asociada a la interfase de usuario del cuestionario TBQ-SAC Copia los datos de la instancia seleccionada a la instancia PROV_Selec asociada a la interfase de usuario del cuestionario TBQ-SAC Copia los datos de la instancia seleccionada a la instancia R_Selec asociada a la interfase de parametrizacin del SGR Seleccin de proyecto desde interfase de usuario (CU 117). Seleccin de proveedor desde interfase de usuario (CU 113). Seleccin de riesgo desde interfase de parametrizacin de SGR (CU4).
Selec_PROY
Selec_PROV
Selec_RIESGO
Selec_TER
Copia los datos de la instancia seleccionada a la Seleccin de tercero instancia T_Selec asociada a la interfase de usuario desde interfase de usuario del cuestionario TBQ-SAC (CU 116). Copia en la interfase de usuario "Ver solucin" las soluciones detectadas mediante la inferencia de medidas preventivas. Solicitud de soluciones a travs de interfase de usuario (CU 21).
Sugerir solucin
Tabla 5.6.1 Listado de procedimientos a implementar (Continuacin.)
5.7 Especificacin del entorno tecnolgico. 5.7.1 Herramientas de desarrollo. El desarrollo del prototipo requiere: - Creacin y administracin de clases e instancias. - Establecer jerarquas de clases. - Implementacin rpida y sencilla de interfases de usuario. - Codificacin de procedimientos y algoritmos. - Codificacin y administracin de inferencias. - Intercambio de datos con otras aplicaciones (DDE base de datos externa). El editor de Kappa PC rene estos requerimientos en un solo entorno, resultando una herramienta adecuada y econmica para desarrollar el prototipo. Por lo tanto el entorno tecnolgico de desarrollo esta conformado por:
Captulo 5: Diseo del SI Autor: Ing. Jos Luis del Ro
161
- Hardware: PC stand-alone Pentium III o superior. - Sistemas operativos: Windows 2000 o XP. - Editor: Kappa PC 5.7.2 Entorno tecnolgico operativo. Como mencionamos antes se toma una situacin de hecho impuesta por el entorno tecnolgico utilizado por los integradores para el desarrollo de sus aplicaciones SAC: - Hardware: PC stand-alone Pentium III o superior. - Sistemas operativos: Windows 2000 o XP. 5.8 Interfase con otros sistemas Para versiones posteriores del SGR, se prev la exportacin y exportacin de los datos obtenidos a bases de datos externas. Dado que Kappa tiene la posibilidad de intercambiar datos mediante DDE, es factible transferir informacin conectando las clases del SGR a las tablas de una base de datos externa. Los registros de la base de datos externa contendrn las instancias de las clases genricas. Por ello se declaran las instancias - CL_Ext - CONT_Ext - INTEG_Ext - HW_Ext - HD_Ext - PI_Ext - PROY_Ext - PROV_Ext - R_Ext - T_Ext (instancia de clase CLIENTE). (instancia de clase CONTRATO). (instancia de clase INTEGRADOR). (instancia de clase HARDWARE). (instancia de clase HERRAMIENTAS DE DESARROLLO). (instancia de clase PROCESO INDUSTRIAL). (instancia de clase PROYECTO). (instancia de clase PROVEEDOR). (instancia de clase RIESGO). (instancia de clase TERCERO).
162
En la tabla 5.8 se indica el esquema de transferencia de datos previsto: SGR

Instancia de interfase de usuario Instancia de Movimiento interfase con BD de datos externa CL_Ext CONT_Ext INTEG_Ext HW_Ext HD_Ext PI_Ext PROY_Ext PROV_Ext R_Ext T_Ext - - - - - - - - ->
DDE
Movimiento de datos
BD Externa
Tablas
CL_Selec CONT_Selec INTEG_Selec HW_Selec HD_Selec PI_Selec PROY_Select PROV_Selec R_Selec T_Select < - - - - - - -Alcances del prototipo
CLIENTE CONTRATO INTEGRADOR HARDWARE HERRAMIENTAS PROCESO IND PROYECTO PROVEEDOR RIESGO TERCERO <- - - -Ampliaciones futuras- - - ->
Tabla 5.8: Interfase de transferencia de datos entre BD SGR y BD Externa.
5.9 Especificacin tcnica del plan de pruebas 5.9.1 Especificacin del entorno de pruebas Hardware: PC stand-alone,Pentim II o superior. Herramientas de desarrollo: Kappa PC. Casos histricos. 5.9.2 Especificacin tcnica de niveles de prueba Nivel 1: Revisiones de cdigo. Nivel 2: Pruebas unitarias de mdulos de programa. Nivel 3: Pruebas de integracin. Nivel 4: Pruebas de sistema. 5.10 Implementacin de revisin de diseo. La revisin del diseo se efectu mediante el siguiente checklist [UPM, 2005]: El cuestionario se aplic en forma iterativa (detectando y corrigiendo defectos) hasta obtener el resultado esperado.
163
Pregunta Evaluacin del diseo arquitectnico Es la organizacin del sistema clara, incluyendo una buena visin de la arquitectura y su justificacin? Estn todos los mdulos bien definidos? Se cubre las funciones establecidas por los requisitos con una cantidad adecuada de mdulos? Se han especificado todas las tareas que el usuario quiere realizar? Se describieron los objetos principales? Se describieron los algoritmos principales? Se describieron los procedimientos principales? Se describieron las estructuras de datos principales? Se han definido los aspectos principales de la interfaz de usuario? Se ha diseado la arquitectura para incluir cambios probables? Alguna parte del diseo est poco trabajada? Se ha diseado la arquitectura para incluir cambios probables? Se han enunciado los objetivos principales del sistema? Encaja conceptualmente cada parte del sistema para formar un todo? Es el diseo de alto nivel independiente de la mquina y del lenguaje que se utilizar para implementarlo? Evaluacin del diseo de alto nivel Se han considerado varias opciones de diseo, seleccionando la mejor de varias opciones? Gestiona adecuadamente el diseo asuntos que fueron postergados a nivel de arquitectura? Es satisfactoria la forma en que el programa se ha descompuesto en mdulos u objetos? Se han definido bien todas las fronteras con los subsistemas? Es el diseo manejable intelectualmente? Tiene el diseo complejidad baja? Ser el sistema fcil de mantener? Permite el diseo extensiones futuras del sistema? Estn diseados los subsistemas de manera de poder reutilizarlos en otros sistemas? Tienen las rutinas de bajo nivel un Fan-in alto? Tienen la mayora de las rutinas un Fan out entre bajo y medio? Ser sencillo portar el diseo a otro entorno? Son todas las partes del diseo estrictamente necesarias? Evaluacin del diseo de alto nivel El diseo est estratificado en niveles? Usa el diseo tcnicas estndar y evita elementos exticos difciles de entender? Tabla 5.10 Checklist de diseo.
Resultado esperado SI SI SI SI SI SI SI SI SI SI NO SI SI SI SI
SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI
Defectos buscados: Complencin, Consistencia, Factibilidad, Trazabilidad

164
Para ms detalle sobre la planificacin general del CC ver apndice D (Interfase aseguramiento de la calidad). 5.11 Resultados de revisiones de diseo. A continuacin se describen los resultados generales de las revisiones de requisitos. Para simplificar la lectura de los mismos, se adopt la convencin establecida en las tablas 5.11.1, 5.11.2, y 5.11.3.
Cdigo de colores de resultados de revisiones de requisitos No se detectan defectos
Presencia de defecto
Tabla 5.11.1 Resultados de revisiones de diseo. Defecto buscado Complencin Consistencia Factibilidad Trazabilidad Tabla 5.11.2 Cdigo del tipo de defecto detectado.
Cdigo de defecto Cm Cn F T
Descripcin 0 1 2 Tabla 5.11.3 Nmero de correccin. Diseo original Primera correccin del diseo. Segunda correccin del diseo.
En los casos en los cuales se detecta defecto, se detalla el mismo en el informe de defectos correspondiente.
165
Revisin N
Arquitectura del SGR.

Cn
Fecha de revisin
Revisin 0: 5/8/9 Revisin 0: 5/8/9 Revisin 0: 7/8/9 Revisin 0: 5/8/9 Revisin 0: 7/8/9 Revisin 0: 5/8/9 Revisin 0: 7/8/9 Revisin 0: 8/8/9 Revisin 0: 9/8/9 Revisin 0: 9/8/9 Revisin 0: 9/8/9
Observaciones
Ver defecto D1 Ver defecto D2 Ver defecto D3 Ver defecto D4
Diseo de clases.
Cn Cm
Especificaciones del diseo
Diseo de interfase de usuario. Diseo de algoritmos. Diseo de inferencias. Diseo de procedimientos. Diseo de entorno tecnolgico Diseo de interfases con otros sistemas. CU 1 Casos de uso CU 2 CU 3 CU 4 Plan de pruebas.
Cm
Cm
Revisin 0: 8/8/9 Revisin 0: 10/8/9 Revisin 0: 9/8/9 Revisin 0: 9/8/9 Revisin 0: 10/8/9 Revisin 0: 10/8/9 Revisin 0: 10/8/9 Revisin 0: 10/8/9 Revisin 0: 10/8/9
Ver defecto D5
Luego de la revisin del diseo, los casos de uso fueron revisados en todos sus niveles de abstraccin.
Tabla 5.11.4 Resultados generales de la revisin de diseo.
Defecto D1: Las clases CLIENTE, INTEGRADOR, PROVEEDOR y TERCERO tienen muchos atributos en comn (Nombre, Ing, EstFin, Estruct y Cuit). Correccin: Crear Super-clase EMPRESA que contenga los atributos en comn. De manera que las clases citadas hereden dichas caractersticas de esta nueva clase. Defecto D2: Las clases HW Y HD comparten atributos similares (Nombre, Cdigo, Costo, Fiabilidad y Tecnologa). Correccin: Crear Super-clase EQUIPO que cubra los atributos comunes a ambas clases. Las clases en cuestin heredan los atributos citados de la clase EQUIPO.
Tabla 5.11.5 Resultados detallados de la revisin de diseo.
166
Defecto D3: Faltan dos atributos que describan si el proceso puede ser peligroso y complejidad del proceso del proceso industrial. Correccin: Agregar a la clase PI los atributos PI:Pelig y PI:Complej. PI:Pelig puede asumir los valores AA, A, M, BJ, BB y ?. PI:Complej puede asumir los valores AA, A, M, BJ, BB y ?.
Defecto D4: Las clases HARDWARE Y HERRAMIENTAS DE DESARROLLO comparten atributos similares (Nombre, Cdigo, Costo, Fiabilidad y Tecnologa). Correccin: Crear Super-clase EQUIPO que cubra los atributos comunes a ambas clases. Las clases en cuestin heredan los atributos citados de la clase EQUIPO.
Defecto D5: Falta definir dos procedimientos que permitan seleccionar los datos del cliente y de hardware de instancias preexistentes. Correccin: Definir los procedimientos Selec_Cliente y Selec_HW. Selec_Cliente: Copia los datos de la instancia seleccionada a la instancia CL_Selec asociada a la interfase de usuario del cuestionario TBQ-SAC es disparado por el evento Seleccin de cliente desde interfase de usuario. Selec_HW: Copia los datos de la instancia seleccionada a la instancia HW_Selec asociada a la interfase de usuario del cuestionario TBQ-SAC es disparado por el evento Seleccin de Hardware desde interfase de usuario.
Tabla 5.11.5 Resultados detallados de la revisin de diseo (Continuacin)

167
CAPTULO 6 CONSTRUCCIN DEL SISTEMA
Captulo 6: Construccin del SI
169
6.1 Preparacin del entorno de generacin y construccin Se actualiza sistema antivirus. Sobre el SO Windows XP, se cargan las herramientas que se utilizan para editar y probar el SGR: - Kappa PC 2.2 Editor. - Kappa PC 2.2 On-Line Manual. 6.2 Generacin del cdigo de los componentes y procedimientos 6.2.1 Generacin de clases Mediante la funcin Add Subclass de Kappa PC se crean las clases: - Contrato (CONT). - Empresa (EMPRESA). - Equipo (EQUIPO). - Proceso (PI). - Proyecto (PROY). - Riesgo (RIESGO). A partir del diseo de clases (obtenido en el captulo 5) se crean las propiedades de las mismas (Slots). Los Slots se editan mediante la funcin Edit de Kappa PC. 6.2.2 Generacin de subclases Por medio de la funcin Add Subclass de Kappa PC se crean: Subclases de Empresa: - Cliente (CL). - Integrador (INTEG). - Proveedor (PROV). - Terceros (T). Subclases de Equipo:
170
- Hardware (HW). - Herramientas de desarrollo (HD). Mediante la herramienta Edit de Kappa PC se agregan las propiedades (slots) no heredadas de las clases madres. 6.2.3 Generacin de instancias Mediante la funcin Add Instance de Kappa PC, se crean las instancias destinadas a conectar las interfases de usuario con las instancias del problema a analizar. En la tabla 6.2.3.a se listan las mismas: Nombre CL_Selec CONT_Selec INTEG_Selec HD_Selec HW_Selec PI_Selec PROV_Selec R_Selec T_Selec Instancia de CL CONT INTEG HD HW PI PROV RIESGO T
Tabla 6.2.3.a Instancias Selec
Con el objetivo de probar el SGR se crean cinco instancias de cada subclase segn la tabla 6.2.3.b. Nombre CL1 a CL5 CONT1 a CONT 5 INTEG1 a INTEG 5 HD1 a HD5 HW1 a HW5 PI1 a PI5 PROV1 a PROV5 R1 a R33 T1 a T5 Instancia de CL CONT INTEG HD HW PI PROV RIESGO T
Tabla 6.2.3.b Instancias de prueba.
171
6.2.4 Edicin de Interfases de usuario Por medio de la herramienta Session de Kappa PC se generan las interfases del sistema SGR. En la tabla 6.2.4 se describe el orden de edicin planificado.
Nombre de interfase de usuario

Menu Principal
Descripcin
Observacion es
CU 0
Pantalla de inicio y acceso a funciones principales. TBQ_SAC Elaboracin de cuestionario TBQ_Cliente Cuestionario datos de cliente segn TBQ-SAC Cuestionario datos de contrato segn TBQTBQ_Contrato SAC TBQ_Integrador Cuestionario datos de integrador TBQ-SAC Cuestionario datos de hardware segn TBQTBQ_HD SAC TBQ_HW Cuestionario datos de herramienta TBQ-SAC Cuestionario datos proceso industrialTBQTBQ_ProcesoIndust SAC TBQ_Provvedor Cuestionario datos de proveedor TBQ-SAC TBQ_Tercero Cuestionario datos de tercero TBQ-SAC Selec_Cliente Seleccin de cliente existente en SGR Selec_Contrato Seleccin de contrato existente en SGR Selec_Integrador Seleccin de integrador existente en SGR Selec_Herramienta Seleccin de herramienta existente en SGR Selec_HW Seleccin de hardware existente en SGR Sele_PI Seleccin de proces existente en SGR Selec_Proveedor Seleccin de proveedor existente en SGR Selec_Tercero Seleccin de tercesro existente en SGR Administracin_de_ acceso Administracin de acceso a parametrizacin Parametrizar_SGR Ingreso de parametros Ki y Wi,j Anlisis_de_riesgo Dispar anlisi de riesgo Perfil_de_exposicin_ a_ riesgo Muestra el resultado del anlis de riesgo Riesgos_prioritarios Muestra los cinco riesgos prioritarios Resultados_detallados_de_riesgo Muestra los detalles de un riesgo (Pi,REi,Li) Muestra soluciones sugeridas a un riesgo Soluciones_sugeridas dado. Ayuda_TBQ Describe el uso de funciones de esta pantalla Ayuda_Men_ principal Describe el uso de funciones de esta pantalla Ayuda_parametrizacin Describe el uso de funciones de esta pantalla Ayuda_resultados_ generales Describe el uso de funciones de esta pantalla Ayuda_lista_ de_ riesgos Lista de riesgos posibles en SAC Ayuda_anlisis_de_riesgo Describe el uso de funciones de esta pantalla
CU 11 CU 112 CU 114 CU 111 CU 119 CU 118 CU 115 CU 113 CU 116 CU 112 CU 114 CU 111 CU 119 CU 118 CU 115 CU 113 CU 116 CU 4 CU 4 CU 12 CU 12 CU 13 CU 12 CU 21 CU CU CU CU CU CU 11 0 4 12 11 12
Tabla 6.2.4 Listado de interfases de usuario generadas para el SGR.
172
6.2.5 Edicin de funciones de navegacin Se procede a codificar la navegacin entre las pantallas listadas en la tabla 6.2.4 mediante la herramienta Edit Function de Kappa PC. En la tabla 6.2.5 se listan las funciones de navegacin codificadas.
Botn Cliente Contrato Integrador Herramientas Hardware Proceso Ind. Proveedor Proyecto Tercero Esc Seleccionar cliente Seleccionar contrato Seleccionar integrador Seleccionar herramienta Seleccionar hardware Seleccionar proceso Seleccionar proveedor Seleccionar tercero Anlisis de riesgo SI (iniciar anlisis riesgo) Parametrizacin Parametrizar SGR Ayuda 1 Ayuda 2 Ayuda 3 Ayuda 4 Ayuda 5 Ayuda 6 Funcin ScrCliente ScrContrato ScrIntegrador ScrHD ScrHW ScrPI ScrProveedor ScrProyecto ScrTercero ScrPrincipal ScrSelecCliente ScrSelecContrato ScrSelecIntegrador ScrSelecHerramienta ScrSelecHW ScrSelePI ScrSelecProveedor ScrSelecTercero ScrAnalsisDeRiesgo ScrEstimarRiesgos ScrPassword ScrParametrizarSGR ScrAyudaTBQ ScrAyudaMenPrincipal ScrAyuda parametrizacin ScrAyudaResultados ScrAyudaRiesgos ScrAyudaAnlisis Riesgo Pantalla destino Observaciones TBQ_Cliente CU 112 TBQ_Contrato CU 114 TBQ_Integrador CU 111 TBQ_HD CU 119 TBQ_HW CU 118 TBQ_ProcesoIndust CU 115 TBQ_Provvedor CU 113 TBQ_Proyecto CU 117 TBQ_Tercero CU 116 Menu principal CU 0 Selec_Cliente CU 112 Selec_Contrato CU 114 Selec_Integrador CU 111 Selec_Herramienta CU 119 Selec_HW CU 118 Sele_PI CU 115 Selec_Proveedor CU 113 Selec_Tercero CU 116 Anlisis de riesgo CU 12 Perfil de RE CU 12 Administracin de acceso CU 4 Parametrizar SGR CU 4 Ayuda TBQ CU 11 Ayuda Men principal CU 0 Ayuda parametrizacin CU 4 Ayuda resultados generales CU 12 Ayuda lista de riesgos CU 11 Ayuda anlisis de riesgo CU 12
Tabla 6.2.5 Listado de funciones de navegacin del SGR.
Por ejemplo: Para abrir la pantalla TBQ_Cliente, se asocia al botn respectivo el cdigo: ShowWindow (TBQ_Cliente). El resto de los botones de navegacin se codific en forma similar.
173
6.2.6 Edicin de procedimientos de enlace entre instancias seleccionadas y cuestionarios TBQ Se procede a codificar los enlaces entre los cuestionarios TBQ - SAC y la seleccin mediante la herramienta Edit Function de Kappa PC, en la tabla 6.2.5 se listan los procedimientos implementados.
Funcin CopiarCLn_CLselec CopiarCONTn_CONTselec CopiarHDn_HDselec CopiarHWn_HWelec CopiarINTEGn_INTEGselec CopiarPIn_PIselec CopiarPROVn_PROVselec CopiarPROYn_PPROYselec CopiarTn_Tselec SalvarCLselec_CLn SalvarCONTselec:CONTn SalvarHDselec_HDn SalvarHWelec_HWn SalvarIINTEGselec_INTEGn SalvarPIselec_PIn SalvarPROVselecPROVn SalvarPROYselec_PROYn SalvarTselec_Tn Descripcin Copia los datos del cliente seleccionado (Instancia Cl(n)) en la pantalla TBQ_Cliente Copia los datos del contrato seleccionado (Instancia CONT(n)) en la pantalla TBQ_Contrato Copia los datos de la herramienta seleccionada (Instancia HD(n)) en la pantalla TBQ_Herramienta Copia los datos del hardware seleccionado (Instancia HW(n)) en la pantalla TBQ_Hardware Copia los datos del integrador seleccionado (Instancia INTEG(n)) en la pantalla TBQ_Integrador Copia los datos del proceso seleccionado (Instancia PI(n)) en la pantalla TBQ_proceso Copia los datos del proveedor seleccionado (Instancia PROV(n)) en la pantalla TBQ_Proveedor Copia los datos del proyecto seleccionado (Instancia PROY(n)) en la pantalla TBQ_Proyecto Copia los datos del tercero seleccionado (Instancia PROY(n)) en la pantalla TBQ_Proyecto Copia los datos del cuestionario TBQ_Cliente en cliente seleccionado (Instancia Cl(n)) Copia los datos del cuestionario TBQ_Contrato en contrato seleccionado (Instancia CONT(n)) Copia los datos del cuestionario TBQ_Herramienta en herramienta seleccionada (Instancia HD(n)) Copia los datos del cuestionario TBQ_Hardware en hardware seleccionado (Instancia HW(n)) Copia los datos del cuestionario TBQ_Integrador en Integrador seleccionado (Instancia INTEG(n)) Copia los datos del cuestionario TBQ_Proceso en el proceso seleccionado (Instancia PI(n)) Copia los datos del cuestionario TBQ_Proveedor en el proveedor seleccionado (Instancia PROV(n)) Copia los datos del cuestionario TBQ_Proyecto en el proyecto seleccionado (Instancia PROY(n)) Copia los datos del cuestionario TBQ_Tercero en el tercero seleccionado (Instancia PROY(n)) Observaci ones CU 112 CU 114 CU 119 CU 118 CU 111 CU 115 CU 113 CU 117 CU 116 CU 112 CU 114 CU 119 CU 118 CU 111 CU 115 CU 113 CU 117 CU 116
Tabla 6.2.6 Listado de procedimientos de enlace del SGR.
Ejemplo: Procedimiento SalvarPROYselec_PROYn se codifica en Kappa de la siguiente manera:
174
X: Argumento (instancia de proyecto) {X:Nombre=PROY_Selec:Nombre; X:Act=PROY_Selec:Act; X:Avance=PROY_Selec:Avance; X:Codigo=PROY_Selec:Codigo; X:CTec=PROY_Selec:CTec; X:EEst=PROY_Selec:EEst; X:EReal=PROY_Selec:EReal; X:Etapa=PROY_Selec:Etapa; X:Equipo=PROY_Selec:Equipo; X:FF=PROY_Selec:FF; X:FI=PROY_Selec:FI}; Los procedimientos Salvar son invocados cuando se completa el formulario TBQSAC respectivo. Los procedimientos Copiar permiten traer los datos de la instancia seleccionada a la pantalla TBQ-SAC. 6.2.7 Edicin de inferencias de factores de riesgo. Por medio de Edit Function de Kappa PC se codifican las inferencias, como primer paso se codifica el cdigo reutilizable de INF X: Arguments: Atrib,Mem If ((Atrib#=MM) Or (Atrib#=NE)Or (Atrib#=AA)Or (Atrib#=Si)Or(Atrib#=?)) Then (Aux1:X=Mem) Else (If ((Atrib#=M)Or (Atrib#=A)) Then (Aux1:X=0.75 * Mem) Else (If ((Atrib#=R)Or (Atrib#=MED)) Then (Aux1:X=0.5 * Mem) Else (If ((Atrib#=B)Or (Atrib#=BJ)) Then (Aux1:X=0.25 * Mem) Else (If ((Atrib#=MB)Or (Atrib#=BB)Or(Atrib#=No)) Then (Aux1:X=0)))) ); Luego se implementan las inferencias INF1 hasta INF33, indexando los argumentos Atrib y Mem de 1 a 33.
175
6.2.8 Edicin de algoritmos de clculo Se procede a implementar los procedimientos responsables de clculo del valor de P (i) y RE (i). Par ello se recurre a los procedimientos reutilizables Prob y RE, indexando el argumento de los mismos desde 1 hasta 33. A titulo de ejemplo se describe el procedimiento Prob (x) y RE(x) Prob (x) Argument X X:Prob=(X:K)*(((X:W1)*(X:X1))+((X:W2)*(X:X2))+((X:W3)*(X:X3))+((X:W4)*(X: X4))+((X:W5)*(X:X5))+((X:W6)*(X:X6))); RE(X) Argument X X:RE=(X:L) * (X:Prob); 6.2.9 Edicin de procedimientos de ordenamiento y seleccin de riesgos prioritarios Se editan los procedimientos Ordenar y Prioridad que toman como base el valor de la exposicin a riesgo calculada. 6.3 Implementacin de revisiones y pruebas La planificacin general es detallada en la seccin D Interfase de aseguramiento de la calidad. 6.3.1 Revisin del cdigo Para la revisin del cdigo se previ la utilizacin de la tcnica de checklist [UPM, 2005] de manera de detectar defectos antes de comenzar las pruebas dinmicas. El cuestionario se aplic en forma iterativa (detectando y corrigiendo defectos) hasta obtener el la calidad de software esperada. A continuacin se detalla el contenido del checklist aplicado.
Captulo 6: Construccin del SI 176 Autor: Ing. Jos Luis del Ro
Nr
6.3.1 6.3.2 6.3.3 6.3.4 6.3.5 6.3.6 6.3.7 6.3.8 6.3.9 6.3.10 6.3.11 6.3.12 6.3.13 6.3.14 6.3.15 6.3.16 6.3.17 6.3.18 6.3.20 6.3.21 6.3.22 6.3.23 6.3.24 6.3.25 6.3.26 6.3.27 6.3.28 6.3.29 6.3.30 6.3.31 6.3.32
Pregunta
Comprobacin de estructuras de control Se usan las expresiones verdadero o falso en lugar de cero y uno? Estn balanceados los pares Begin End? Se usan los pares Begin End en aquellos sitios que son necesarios por claridad? Se han simplificado las sentencias anidadas re probando parte de la condicin convirtindolas a If- then-else o moviendo el cdigo anidado a una rutina propia? Existen rutinas con ms de diez decisiones? Comprobacin de estructuras de control inusuales Se utilizan go to? Hace cada rutina uso del nmero mnimo de returns? Utiliza el programa contadores para garantizar que la rutina para? Est la recursividad de la rutina dentro de los lmites impuestos por el programa? Comprobacin de sentencias condicionales (Sentencias if then) Est claro el camino nominal a travs del cdigo? Se comportan las comprobaciones if-then correctamente con la igualdad? Est la clusula else presente o documentada? Es la clusula else correcta? Sigue el caso normal el if ms que el else? Comprobacin de sentencias condicionales (cadenas if-then-else-if) Estn encapsuladas las comprobaciones complicadas en llamadas a funciones booleanas? Se comprueban primero los casos ms comunes? Estn cubiertos todos los casos? Es la cadena if- then- else la mejor implementacin? Comprobacin de sentencias condicionales (sentencias case) Se utilizan sentencias Case? Comprobacin de bucles Est la inicializacin del ndice, directamente antes del bucle? Usa el Begin End para evitar problemas que surgen de modificaciones inadecuadas? El bucle esta vaco? Lleva a cabo el bucle una y solo una funcin como rutina bien definida? Termina el bucle para todas las posibles condiciones? Es la terminacin del bucle obvia? Se usa una variable para guardar valores importantes del ndice del bucle, en lugar de usar el ndice del bucle fuera de l? Usa el bucle contadores de seguridad? Tiene el ndice del bucle un nombre significativo? Es el bucle lo suficientemente corto como para verlo de una sola vez? Est anidado el bucle a tres niveles o menos? Existen bucles largos?
Resultado esperado
SI SI SI SI
NO SI SI SI SI SI SI SI NO SI SI SI SI NO SI SI NO SI SI SI SI SI SI SI SI NO
Tabla 6.3.a Checklist de comprobacin del cdigo
177
Nr.
Pregunta
Resultado esperado SI SI SI SI SI SI NO SI SI SI SI NO SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI
Comprobacin de cdigo inteligible (rutinas) 6.3.33 Describe el nombre de cada rutina claramente lo que hace? 6.3.34 Lleva a cabo la rutina una funcin bien definida? 6.3.35 Las interfaces de las rutinas son claras? Comprobacin de cdigo inteligible (datos) Son los nombres de los tipos de datos lo suficientemente 6.3.36 descriptivos para ayudar a documentar las declaraciones de datos? 6.3.37 Se han nombrado bien las variables? Se han usado las variables solo para el propsito para el que fueron 6.3.38 nombradas? 6.3.39 El bucle esta vaco? Lleva a cabo el bucle una y solo una funcin como rutina bien 6.3.40 definida? 6.3.41 Termina el bucle para todas las posibles condiciones? Comprobacin de cdigo inteligible (organizacin de datos) 6.3.42 Se usan variables extras para claridad cuando es necesario? Son las estructuras de datos simples, de manera de minimizar la 6.3.43 complejidad? Es complicado el acceso a datos, a travs de rutinas de acceso 6.3.44 abstractas? Comprobacin de cdigo inteligible (control) 6.3.45 Est claro el camino nominal a travs del cdigo? 6.3.46 Estn agrupadas las sentencias relacionadas? 6.3.47 Son las estructuras de control simples? 6.3.48 Se ha minimizado el nmero de anidamientos? Comprobacin de comentarios (General) 6.3.49 Contiene el cdigo fuente la mayor informacin sobre el programa? 6.3.50 Puede alguien entender el cdigo al leerlo por primera vez? 6.3.51 Explican los comentarios la intencin del cdigo? 6.3.52 Estn actualizados los comentarios? 6.3.53 Son los comentarios claros y correctos? 6.3.54 Los comentarios son fcilmente modificables? Comprobacin de comentarios (sentencias y prrafos) 6.3.55 Se centran los comentarios ms en el por qu ms que en el cmo? Preparan los comentarios la mente del lector para lo que viene a 6.3.56 continuacin? 6.3.57 Sirve para algo el comentario? 6.3.58 Se han eliminado comentarios redundantes o extraos? 6.3.59 Se han sustituido las abreviaciones? Comprobacin de comentarios (declaraciones de datos) 6.3.60 Se ha comentado las unidades de declaraciones de datos? 6.3.61 Se ha comentado el rango de datos numricos? 6.3.62 Estn comentados los significados codificados? 6.3.63 Se ha comentado cada variable global? Tabla 6.3.a Checklist de comprobacin del cdigo (continuacin)
Captulo 6: Construccin del SI 178
Nr.
Pregunta
Resultado esperado SI SI
Comprobacin de comentarios (rutinas) 6.3.64 Se ha comentado el propsito de cada rutina? Se han comentado otros hechos de cada rutina, cuando es relevante, incluyendo datos de entrada y salida, asunciones de 6.3.65 interfaz, limitaciones, correcciones de errores globales y fuentes de algoritmos? Comprobacin de comentarios (programa) 6.3.66 Est en el listado el nombre del autor y el modo de localizarlo? Tabla 6.3.a Checklist de comprobacin del cdigo (continuacin)
SI
Defectos buscados: Correccin 6.3.2 Implementacin de pruebas unitarias Se aplicaron las siguientes metodologas: - Caja blanca - Caja Negra Defectos buscados: Correccin, Complencin, Consistencia y Trazabilidad. La secuencia de las pruebas unitarias se estableci aprovechando el ordenamiento de construccin establecido en las tablas 6.2.4, 6.2.5 y 6.2.6. Las pruebas de caja blanca se realizaron mediante la herramienta Edit Function de Kappa PC y las de caja negra fueron soportadas por la herramienta Session de Kappa PC. Durante las pruebas de caja blanca se realizaron las siguientes actividades: Prueba de interfaces: Mediante las mismas se analiz el flujo de datos a travs de la interfaz (interna-externa) de los mdulos. Prueba de estructura de datos locales: Su objetivo fue asegurar la integridad de los datos durante todos los pasos de ejecucin del mdulo. Se efectuaron cuatro tipos de pruebas de datos: Referencias de datos: Su objetivo fue la comprobacin del acceso de los mismos (variables no inicializadas, salirse de los lmites prefijados, etc.).
179
Declaracin de datos: Se comprob que las definiciones de datos locales eran correctas. Clculo: Se busc errores derivados del uso de variables por ejemplo: overflow, divisiones por cero, etc. Comparacin: Mediante esta prueba se procur localizar errores en las comparaciones realizadas mediante instrucciones tipo If, While, etc. El objetivo de este tipo de prueba fue localizar errores derivados del uso de variables, por ejemplo: overflow, divisiones por cero, comparacin entre variables con formatos diferentes (string con nmeros), etc. Pruebas de camino bsico: Mediante esta metodologa se asegur que cada sentencia sea ejecutada al menos una vez. Se cubri la ejecucin de cada una de las sentencias, cada una de las decisiones y cada una de las condiciones de las decisiones. Para realizar esta prueba fue necesario determinar: - Flujograma de mdulos. - Complejidad ciclomtica de mdiulos. Pruebas de condiciones lmites: Tambin denominada Prueba de bucles, permiti comprobar la validez de las construcciones que utilizaban bucles. Se distinguen cuatro tipos de bucles cada uno con una tcnica de prueba especfica: - Bucles simples. - Bucles anidados. - Bucles concatenados/ encadenados. - Bucles no estructurados. Caja Negra: Se comprob cada unidad del programa sin entrar en el detalle procedimental de cada mdulo, centrando la atencin en la comprobacin de las especificaciones de diseo del mdulo. Se aplicaron dos tcnicas complementarias para determinar los
180
datos de entrada de las pruebas de caja negra: - Particiones de equivalencia. - Anlisis de valores lmites. Particiones de equivalencia: Se dividi la entrada al SGR en clases de datos representativos de los que se derivaron los casos de prueba. Anlisis de valores lmites: Se establecieron y comprobaron los valores lmites de cada clase de equivalencia. 6.3.3 Implementacin de pruebas de integracin Las interfases de usuario se probaron mediante un proceso de integracin incremental de ARRIBA ABAJO (TOP DOWN), desde el men principal hacia las pantallas secundarias mediante la siguiente secuencia de pruebas: - Cuestionarios TBQ-SAC. - Anlisis de riesgo. - Evaluacin y gestin de riesgos. La integracin de funciones, procedimientos algoritmos e inferencias se realiz mediante un proceso de integracin incremental del tipo ABAJO ARRIBA (DOWN TOP) comenzando por las funciones reutilizables para luego comprobar los mecanismos de indexacin y llamadas. Defectos buscados: Correccin, Complencin, Consistencia y Trazabilidad 6.3.4 Implementacin de pruebas de sistema Durante estas pruebas, se comprobaron los requisitos del sistema y las funciones que realiza. Los criterios mnimos para determinar si se cumplen los objetivos del sistema fueron:
181
- Cumplimiento de todos los requisitos funcionales. - Funcionamiento y rendimiento de todas las interfases. - Adecuacin de la documentacin del usuario. - Ejecucin y rendimiento de condiciones lmites y de sobrecarga. Se utilizaron tcnicas de caja negra, diseadas para comprobar los requisitos funcionales sin analizar el funcionamiento interno del programa (dado que ya fue probado en las pruebas unitarias y de integracin). Los casos de prueba se armaron con tres tipos de fuentes: Casos basados en los requisitos del sistema: Se disearon las pruebas teniendo en cuenta los requisitos del SGR. Casos basados en el diseo: Se tuvo en cuenta la estructura de alto nivel del software. Casos para probar el rendimiento del software y su capacidad funcional: Se busc llevar al sistema a condiciones lmites y de sobrecarga. Los casos de pruebas se disearon en base a estos criterios, tomando como referencia casos histricos de resultado conocido. El resultado esperado es el que obtendra el especialista en forma manual, debido a ello ejecut cada uno de los casos en paralelo con el SGR, comparando los resultados de ambos procesos. 6.3.5 Observaciones particulares sobre la implementacin de pruebas del SGR. A continuacin se describe dos hechos importantes que se presentaron durante la implementacin de las pruebas: - Reduccin de casos de prueba. - Problemas de ocultamiento de la programacin orientada a objetos. Reduccin de casos de prueba: Durante las pruebas de caja blanca del cdigo procedimental el nmero de pruebas se redujo drsticamente debido a que: 1) Se redujo la cantidad de valores asumidos por los datos de entrada debido a la estandarizacin de los mismos.
182
2) Slo cinco mdulos del SGR presentaron una complejidad ciclomtica mayor que uno. 3) Slo tres mdulos utilizan bucles y su profundidad de anidamiento es baja. 4) La estructura orientada a objetos del SGR y la herramienta Class Editor de Kappa PC permitieron verificar rpidamente la estructura de datos locales. A continuacin se amplan estos cuatro puntos: Si tomamos como ejemplo la valorizacin de la experiencia en seguridad del integrador vemos que slo puede asumir uno de seis valores: Muy Buena (MB), Buena (B), Regular (R), Mala (M), Muy mala (MM) o Desconocida (?), si no se completa el campo el sistema asume por defecto el valor ?. Lo mismo sucede con el resto de las respuestas del cuestionario TBQ-SAC, la utilizacin de este criterio de diseo redujo mucho la cantidad de variantes de las pruebas. Al analizar la complejidad ciclomtica (V(G)) del SGR, nos encontramos que para la mayora de ellos es igual a 1, salvo en los siguientes mdulos:
Nombre INF X Calidad Calidad 1 Calidad 2 Calidad 3 Prioridad 1 Prioridad 2 Prioridad 3 Prioridad 4 Prioridad 5 CopiarRN_RSelec Descripcin Estimar esfuerzo Estimar calidad de GR Subprograma de calidad Subprograma de calidad Subprograma de calidad Mostrar riesgo prioridad 1 Mostrar riesgo prioridad 2 Mostrar riesgo prioridad 3 Mostrar riesgo prioridad 4 Mostrar riesgo prioridad 5 Mostrar en pantalla el detalle del riesgo seleccionado y sus soluciones V (g) 6 3 36 19 27 2 2 2 2 2 6
Tabla 6.3.5.1 Mdulos con complejidad ciclomtica > 1.
La cantidad de pruebas de bucles (condiciones lmites) se redujo fuertemente debido a que slo se utilizaron bucles (anidados) en dos mdulos:
183
Mdulo
Buscar_Solucin Ordenar Prio
Cantidad de bucles
3 5 1
Observaciones
Anidado, profundidad = 3
Tabla 6.3.5.2 Mdulos con sentencias de anidamiento.
Problemas de ocultamiento: Si bien la programacin orientada a objetos simplific el trabajo de diseo y codificacin, se tuvo que tener en cuenta que la encapsulacin integra varias funciones en un objeto. A la hora de probar las clases y subclases del SGR, se debi analizar el encapsulamiento propio de los objetos construidos mediante Kappa PC. Debido a ello fue necesario comprobar cada sub-funcin del objeto e integrarla de modo gradual. Teniendo en cuenta las Pruebas de integracin OO basadas en uso se estableci una secuencia de pruebas mediante la cul se comprobaron primero las clases independientes y luego las clases dependientes. Considerando a cada objeto como una unidad, se aplic la metodologa de Pruebas unitarias para programacin OO, comprobando el comportamiento de cada clase mediante tcnicas de caja blanca y caja negra. Finalmente durante las pruebas de integracin de objetos, se adopt la metodologa de Integracin basada en hilos comprobando el conjunto de clases necesarias para responder a una entrada o evento del sistema (en nuestro caso las clases que integran el cuestionario TBQ-SAC). 6.4 Resultados de revisiones y pruebas unitarias. A continuacin, se describen los resultados generales de las revisiones y pruebas unitarias. Para facilitar la lectura de las mismas se adopt la convencin establecida en las tablas 6.4.1, 6.4.2, y 6.4.3.
184
Cdigo de colores de resultados de revisiones pruebas unitarias
No se detectan defectos
Presencia de defecto
Tabla 6.4.1 Resultados de revisiones y pruebas unitarias de cdigo. Defecto buscado Correccin Complencin Consistencia Trazabilidad Tabla 6.4.2 Cdigo del tipo de defecto detectado.
Cdigo de defecto Cr Cm Cn Tr
Descripcin 0 1 2 Tabla 6.4.3 Nmero de correccin. Mdulo original Primera correccin del mdulo a probar Segunda correccin de mdulo a probar
En los casos en los cuales se detecta defecto, se detalla el mismo en el informe de defectos correspondiente. Los resultados de las revisiones y pruebas unitarias (caja blanca y caja negra), se muestran segn el agrupamiento y ordenamiento utilizado. En cada agrupamiento se ilustran los resultados generales del grupo, ms el detalle de los defectos detectados.
185
Resultados generales de revisiones y pruebas de clases

Actividad ==> Revisin de cdigo Checklist 0
Cm
Metodologa ==> Correccin N ==> CONTRATO Clases independientes EMPRESA EQUIPO PI PROY RIESGO Clases dependientes
EMPRESA
Pruebas unitarias de cdigo Caja Caja Negra Blanca 0 1 2 0 1 2
Observaciones
CU 114 Error 1 CU 11 CU 11
Cr
Error 2
CU 115 CU 117 CU 12 CU 112
CL INTEGRADOR PROVEEDOR HD Revisin 0 8/8/5 12/9/5 18/9/5 Revisin 1 10/8/5 14/9/5 19/9/5
Cr
Error 3
CU 111 CU 113 CU 119 CU 118 Revisin 2
HW Tcnica de prueba Fecha de Checklist revisin Caja blanca Caja negra
Tabla 6.4.4 resultados generales de revisiones y pruebas unitarias de clases.. Defectos detectados mediante metodologa de checklist: Error 1: La clase EMPRESA no presenta comentarios claros en la descripcin de los slots. (Pregunta 6.3.53). Herramienta utilizada: Class Editor de Kappa PC. Defectos detectados mediante metodologa de caja blanca: Error 2: En la clase PI No fue declarado el slot del atributo Temp. (temperatura) Herramienta utilizada: Class Editor de Kappa PC. Defectos detectados mediante metodologa de caja negra: Error 3: En la clase INTEGRADOR dentro del listado de valores preestablecidos del slot ExpPLC (Experiencia en PLCs) faltaba el valor MB (Muy bueno). Herramienta utilizada: Session de Kappa PC Tabla 6.4.5 resultados detallados de revisiones y pruebas unitarias de clases.
EQUI PO
186
Resultados generales de revisiones y pruebas de interfases de usuario (CU 11)

Actividad ==> Revisin de cdigo Checklist 0 1 2 Pruebas unitarias de cdigo Caja Blanca 0 1 2 0 Caja Negra 1 2 CU 0 CU 11 CU 112 CU 114
Cr
Metodologa ==> Correccin N ==> Menu Principal TBQ_SAC TBQ_Cliente TBQ_Contrato TBQ_Integrador TBQ_HD TBQ_HW TBQ_ProcesoIndust TBQ_Proveedor TBQ_Tercero Selec_Cliente Selec_Contrato Selec_Integrador
Interfase de usuario
Observaciones
Error 4 Error 5 Error 6
CU 111 CU 119 CU 118 CU 115 CU 113 CU 116 CU 112 CU 114
Cr Cr
Cr
Error 7
CU 111 CU 119 CU 118 CU 115 CU 113 CU 116 CU 4
Selec_Herramienta Selec_HW Selec_PI Selec_Proveedor Selec_Tercero Administracin de acceso Parametrizar SGR Anlisis de riesgo Perfil de exposicin a riesgo Riesgos prioritarios Resultados detallados de riesgo Soluciones sugeridas Ayuda TBQ Ayuda Men principal Ayuda parametrizacin Ayuda resultados generales Ayuda lista de riesgos Ayuda anlisis de riesgo Error 10 Error 11
Cr Cr
Error 8 Error 9
CU4 CU 12 CU 12 CU 13
Cr
Cr
CU 12 CU 21 CU 11 CU 0 CU 4 CU 12 CU 11 CU 12
Tabla 6.4.6 Resultados de revisiones y pruebas unitarias de interfases de usuario.
187
Tcnica de prueba Fecha de Checklist revisin Caja blanca Caja negra
Revisin 0 21/9/5 27/9/5 3/10/5
Revisin 1 22/9/5 28/9/5 4/10/5
Revisin 2
4/10/5
Tabla 6.4.6 Resultados de revisiones y pruebas unitarias de interfases de usuario (Continuacin).
Defectos detectados mediante metodologa de caja blanca: Error 4: En la pantalla TBQ_Integrador el campo Calificacin del integrador no tiene link con ninguna variable, debe relacionarse con la variable Integ_Selec_Calif Error 5: En la pantalla TBQ_HW el acceso a valores dl campo Fiabilidad fue programado como SingleListBox en lugar de RadioButtomGroup . Error 6: En la pantalla TBQ_ProcesoIndust falta incluir el campo de entrada Nombre del proceso. Error 7: En la pantalla Selec:_Integrador el listado desplegable (SingleBoxOption) no se ha declarado la variable. Completar Owner =:Aux1 Owner Slot:= INTEGNum Allowable values = Lista de integradores Herramienta utilizada: Session (Layout mode) de Kappa PC. Defectos detectados mediante metodologa de caja negra: Error 8: En la pantalla Parametrizar_SGR en el listado de seleccin de riesgo a editar falta declarar el Owner:Aux1 para que la variable RiesgoNum quede correctamente relacionada. Error 9: En la pantalla Anlisis_de_Riesgo Parametrizar_SGR el objeto meter option utilizado para representar la fiabilidad tiene un valor incorrecto de escala mxima (MaxValue) debera tener asignado el valor 100%. Error 10: En la pantalla Resultados_detallados_de_Riesgo la barra que representa la Prdida promedio no tiene declarada el Owner de la variable L , corresponde Owner= R_Selec. Error 10: En la pantalla Resultados_detallados_de_Riesgo la barra que representa la Prdida promedio tiene no tiene valor mximo asignado. Para R_Selec:L corresponde MaxValue= 100 %. Herramienta utilizada: Session y Editor Class de Kappa PC.
Tabla 6.4.7 resultados detallados de revisiones y pruebas unitarias de clases.
188
Inferencias de valores numricos de X iJ a partir de valor lingstico (CU 1110). Actividad ==> Revisin de cdigo Checklist 0 Cr
Cr Cr
Pruebas de cdigo Caja Blanca Caja Negra 0 1 2 0 1 2 Error 12 Error 13 Error 14 Observaciones
Metodologa ==> Correccin N ==> INF 01 INF 02 INF 03 INF 04 INF 05 INF 06 INF 07 INF 08 INF 09 INF 10 INF 11 INF 12 INF 13 INFERENCIA INF 14 INF 15 INF 16 INF 17 INF 18 INF 19 INF 20 INF 21 INF 22 INF 23 INF 24 INF 25 INF 26 INF 27 INF 28 INF 29 INF 30
CU 1110
CR
Error 15
Tabla 6.4.8 resultados generales de revisiones y pruebas unitarias de inferencias.

Captulo 6: Construccin del SI Autor: Ing. Jos Luis del Ro
189
Inferencias de valores numricos de X iJ a partir de valor lingstico (CU1110). Actividad ==> Revisin de cdigo Checklist 0 1 2 Pruebas de cdigo Caja Blanca Caja Negra 0 1 2 0 1 2 Observaciones
Metodologa ==> Correccin N ==> INFERENCIAS INF 31 INF 32 INF 33
CU 1110
Revisin 0 6/10/5 8/10/5 9/10/5 Revisin 1 7/10/5 9/10/5 10/10/5 Revisin 2
Tabla 6.4.8 resultados generales de revisiones y pruebas unitarias de inferencias (continuacin).
Defectos detectados mediante metodologa de checklist: Error 12: La inferencia INF1 no presenta comentar claros (Pregunta 6.3.53). Herramienta utilizada: Function Editor de Kappa PC. Defectos detectados mediante metodologa de caja blanca: Error 13: {Aux1:Memo=R06:Prob; INFX(AA,Aux1:Memo)); Existe un parntesis de ms, eliminar. R02:X1=Aux1:X; Aux1:Memo=R08:Prob; INFX(AA,Aux1:Memo); R02:X2=Aux1:X; Aux1:Memo=1; INFX(CL_Selec:Ing,Aux1:Memo); R02:X3=1-Aux1:X; INFX(CL_Selec:Conocimiento,Aux1:Memo); R02:X4=Aux1:X; INFX(INTEG_Selec:GP,Aux1:Memo); R02:X5=Aux1:X}; Tabla 6.4.9 resultados detallados de revisiones y pruebas unitarias de inferencias (continuacin).
190
Defectos detectados mediante metodologa de caja blanca: Error 14: (Aux1:Memo=1) And INFX(PI_Selec:Especif,Aux1:Memo)Or (R06:X1=Aux1:X) Or INFX(CL_Selec:Conocimiento,Aux1:Memo) Or (R06:X2=Aux1:X) Or INFX(PI_Selec:Simil,Aux1:Memo) Or (R06:X3=(1 * Aux1:Memo)-(Aux1:X)) And INFX(PI_Selec:Complej,Aux1:Memo) And (R06:X4=Aux1:X); Todas las funciones OR deben ser reemplazadas po AND Herramienta utilizada: Function Editor de Kappa PC.
Defectos detectados mediante metodologa de caja blanca Error 15 Aux1:Memo=1; INFX(PI_Selec:Pelig,Aux1:Memo); Aux1:Memo2=Aux1:X; INFX(INTEG_Selec:ExpSegInd,Aux1:Memo2); R21:X1=Aux1:X; INFX(INTEG_Selec:ExpSegInd,Aux1:Memo2); Error 15 debe el argumento de INF X debe ser (CL_Selec:ExpSeg,Aux1:Memo2); R21:X2=Aux1:X; INFX(PI_Selec:Complej,Aux1:Memo2); R21:X3=Aux1:X}; Herramienta utilizada: Session y Function Editor de Kappa PC.
Tabla 6.4.9 resultados detallados de revisiones y pruebas unitarias de inferencias.
191
Resultados generales de revisiones y pruebas de navegacin

Actividad ==> Revisin de cdigo Checklist 0 1 2 0 Pruebas unitarias de cdigo Caja Blanca 1 2 Caja Negra Observaciones 0 1 2
Metodologa ==> Correccin N ==> Botn Cliente Contrato Integrador Herramientas Hardware Proceso Ind. Proveedor Proyecto Tercero Esc Cliente Contrato Seleccionar Integrador Herramienta Hardware ProcesoInd. Proveedor Tercero Anlisis de riesgo SI (iniciar anlisis riesgo) Parametrizacin Parametrizar SGR Ayuda 1 Ayuda 2 Ayuda 3 Ayuda 4 Ayuda 5 Ayuda 6 Funcin ScrCliente ScrContrato ScrIntegrador ScrHD ScrHW ScrPI ScrProveedor ScrProyecto ScrTercero ScrPrincipal ScrSelecCliente ScrSelecContrato ScrSelecIntegrador ScrSelecHerramienta ScrSelecHW ScrSelePI ScrSelecProveedor ScrSelecTercero ScrAnalsisDeRiesgo ScrEstimarRiesgos ScrPassword ScrParametrizarSGR ScrAyudaTBQ ScrAyudaMenPrincipal ScrAyuda parametrizacin ScrAyudaResultados ScrAyudaRiesgos ScrAyudaAnlisisRiesg
CU 112 CU 114 CU 111 CU 119 CU 118 CU 115 CU 113 Cm Error 16 CU117 CU 116 Cm Error 17 CU 112 CU 114 Cr Error 19 CU 111 CU 119 CU 118 CU 115 CU 113 CU 116 CU 12 CU 12 CU 4 CU 4 CU 11
CU 4 CU 12 CU 12 CU12
Tabla 6.4.10 resultados generales de revisiones y pruebas unitarias de funciones de navegacin.
192
Revisin 0 20/10/5 10/10/5 13/10/5
Revisin 1 21/10/5 11/10/5
Revisin 2
Tabla 6.4.10 (continuacin): resultados generales de revisiones y pruebas unitarias de funciones de navegacin.
Defectos detectados mediante metodologa de checklist: Error 16: La funcin ScrProyecto no es comentada (Pregunta 6.3.53). Error 17: La funcin ScrPrincipal no es comentada (Pregunta 6.3.53). Herramienta utilizada: Function Editor de Kappa PC.
Defectos detectados mediante metodologa de caja blanca: Error 18: La funcin ScrSelecContrato tiene errores de tipeo.. ShowWindow (SelecContarto); Debe expresarse como ShowWindow (SelecContrato);
Herramienta utilizada: Function Editor de Kappa PC.
Defectos detectados mediante metodologa de caja negra: Error 19: Al forzar el evento presionar el botn Seleccionar integrador, el SGR mostraba la pantalla TBQ-Cliente. ShowWindow (TBQ_Cliente); Est mal direccionada Debe expresarse ShowWindow (SelecInteg);
Herramienta utilizada: Session y Function Editor de Kappa PC
Tabla 6.4.11 resultados detallados de revisiones y pruebas unitarias de funciones de navegacin.
193
Resultados generales de revisiones y pruebas de procedimientos.

Actividad ==> Revisin de cdigo Checklist 0 1 2 Pruebas unitarias de cdigo Caja Caja Blanca Negra 0 1 2 0 1 2
Cr
Metodologa ==> Correccin N ==> CopiarCLn_CLselec CopiarCONTn_CONTselec CopiarHDn_HDselec CopiarHWn_HWelec CopiarINTEGn_INTEGselec CopiarPIn_PIselec CopiarPROVn_PROVselec CopiarPROYn_PPROYselec CopiarTn_Tselec SalvarCLselec_CLn SalvarCONTselec:CONTn SalvarHDselec_HDn SalvarHWelec_HWn SalvarIINTEGselec_INTEGn SalvarPIselec_PIn SalvarPROVselecPROVn SalvarPROYselec_PROYn SalvarTselec_Tn Tcnica de prueba Fecha de Checklist revisin Caja blanca Caja negra Procedimiento
Observaciones
Error 20
Revisin 0 30/9/5 14/10/5 15/10/5
Revisin 1 31/9/5 14/10/5
CU 112 CU 114 CU 119 CU 118 CU 111 CU 115 CU 113 CU 117 CU 116 CU 112 CU 114 CU 119 CU 118 CU 111 CU 115 CU 113 CU 117 CU116 Revisin 2
Tabla 6.4.12 resultados generales de revisiones y pruebas unitarias de procedimientos.

Defectos detectados mediante metodologa de caja blanca: Error 20: La funcin CopiarCONTn_CONTselec contiene errores de tipeo: Arguments Y El argumento es X en lugar de Y {HW_Selec:Nombre=X:Nombre; HW_Selec:Conec=X:Conec; HW_Selec:Prog=X:Prog; HW_Selec:Resp=X:Resp; HW_Selec:Tipo=X:Tipo; HW_Selec:TRep=X:TRep; HW_Selec:Codigo=X:Codigo; . Herramienta utilizada: Function Editor de Kappa PC.
Tabla 6.4.13 resultados detallados de revisiones y pruebas unitarias de procedimientos.
194
Resultados generales de revisiones y pruebas de algoritmos

Actividad ==> Revisin de cdigo Checklist 0 1 2 0 Pruebas unitarias de cdigo Caja Blanca 1 2 0 Caja Negra 1 2 Observaciones
Metodologa ==> Correccin N ==> Nombre EE P L RE PR Descripcin Estimar esfuerzo Estimar probabilidad Estimar prdida promedio Estimar exposicin a riesgo Calcular prioridad
Error 21 Error 21 Error 21 Error 21 Error 21 Error 21 Revisin 0 16/10/5 20/10/5 21/10/5 Revisin 1 19/11/5
CU 12 CU 12 CU 12 CU 12 CU13 CU 3
CALIDAD Estimar calidad del anlisis de riesgo Tcnica de prueba Fecha de Checklist revisin Caja blanca Caja negra
Revisin 2
Tabla 6.4.14 resultados generales de revisiones y pruebas unitarias de algoritmos de clculo.
Defectos detectados mediante metodologa de checklist: Error 21: Las cinco funciones analizadas presentan comentarios poco claros. (Pregunta 6.3.53). Herramienta utilizada: Function Editor de Kappa PC.
Tabla 6.4.15 resultados detallados de revisiones y pruebas unitarias de algoritmos de clculo.
Las pruebas descriptas anteriormente corresponden a mdulos con un solo camino bsico, en la tabla 6.4.16 se muestran los resultados de los mdulos con ms de un camino. Aplicando la metodologa de caja blanca se detecta el Error 22. Como primer paso, se construy el flujograma y el grafo de flujo de INF X. En uno de los seis caminos posibles de INF X se detect que el mdulo asignaba el valor 0,025 en lugar de 0,25 al factor de riesgo instanciado.
Resultados generales de revisiones y pruebas de mdulos con complejidad ciclomtica (mayor que 1
Actividad ==> Revisin de cdigo Checklist 0 1 2 Pruebas unitarias de cdigo Caja Blanca V(g) 6 3 36 19 27 2 2 2 2 2 6 Revisin 0 10/10/5 16/10/5 19/10/5 Revisin 1 17/10/5
0
Metodologa ==> Correccin N ==> Nombre INF X Calidad Calidad 1 Calidad 2 Calidad 3 Descripcin Estimar esfuerzo Estimar calidad de GR Subprograma de calidad Subprograma de calidad Subprograma de calidad
Caja Negra 2 0 1 2
Observaciones
Error 22
CU12 CU 3 CU 3 CU 3 CU 3 CU13 CU13 CU13 CU13 CU13 CU21
Prioridad 1 Mostrar riesgo prioridad 1 Prioridad 2 Mostrar riesgo prioridad 2 Prioridad 3 Mostrar riesgo prioridad 3 Prioridad 4 Mostrar riesgo prioridad 4 Prioridad 5 Mostrar riesgo prioridad 5 Mostrar en pantalla el CopiarRN detalle del riesgo _RSelec seleccionado y sus soluciones Tcnica de prueba Fecha de Checklist revisin Caja blanca Caja negra
Revisin 2
Tabla 6.4.16 resultados generales de revisiones y pruebas unitarias de mdulos con V(g) >1
A continuacin se detalla el error detectado.

INF X Arguments Atrib Mem If ((Atrib#=MM) Or (Atrib#=NE)Or (Atrib#=AA)Or (Atrib#=Si)Or(Atrib#=?)) Then (Aux1:X=Mem) Else (If ((Atrib#=M)Or (Atrib#=A)) Then (Aux1:X=0.75 * Mem) Else (If ((Atrib#=R)Or (Atrib#=MED)) Then (Aux1:X=0.5 * Mem) Else (If ((Atrib#=B)Or (Atrib#=BJ)) Then (Aux1:X=0.025 * Mem) Else Error 22 debe expresarse comor XAux1:=0,25 (If ((Atrib#=MB)Or (Atrib#=BB)Or(Atrib#=No)) Then (Aux1:X=0) Else (Aux1:X=Mem)))));
Tabla 6.4.17 Detalle de error de cdigo de Error 22
196
Atrib#=MM) Or (Atrib#=NE)Or (Atrib#=AA)Or (Atrib#=Si) Or (Atrib#=?)) Aux1:X=Mem
Atrib#=M) Or (Atrib#=A) Aux1:X=0.75 * Mem
Atrib#=R) Or (Atrib#=MED) Aux1:X=0.5 * Mem
Atrib#=B) Or (Atrib#=BJ)
Aux1:X=0.025 * Mem Atrib#=MB) Or (Atrib#=BB) Or Atrib#=NO)
Aux1:X=0
Aux1:X=Mem
Figura 6.4.1 Flujograma de INF X.
197
1 7
V(G) = Nmero de regiones = 6
8 3
Caminos bsicos:
9 4
Camino 1: 1-2-3-4-5-6 Camino 2: 1-7-2-3-4-5-6 Camino 3: 1-2-8-3-4-5-6 Camino 4: 1-2-3-9-4-5-6 Camino 5: 1-2-3-4-10-5-6 Camino 6: 1-2-3-4-5-11-6
10 5
11 6
Figura 6.4.2 Diagrama de grafo de flujo de INF X.
6.5 Resultados de pruebas de integracin A continuacin se detallan los resultados de las pruebas de integracin, los mismos se exponen en el orden en el que se fueron integrando los mdulos del SGR. .
Resultados generales de pruebas de integracin

Actividad ==> Revisin de cdigo Checklist 0 1 2 Pruebas unitarias de cdigo Caja Caja Blanca Negra 0 1 2 0 1 2
Metodologa ==> Correccin N ==> Entre Clases y Subclases Entre Clases y clases instanciadas Entre interfases de usuario
Observaciones
Integracin entre clases instanciadas e interfases de usuarios Inferencias (INF 1 a INF 33) con algoritmos de clculo Algoritmos de clculo con soluciones sugeridas Clases instanciadas con determinacin de calidad del anlisis Tcnica de prueba Revisin 0 Fecha de Checklist 3/10/5 revisin Caja blanca 22/10/5 Caja negra 25/10/5
Prueba de integracin
Error 22 Error 23
Revisin 1 23/10/5 26/10/5
Revisin 2
Tabla 6.5.1 resultados generales de revisiones y pruebas de integracin.
Defectos detectados mediante metodologa de caja blanca: Error 22: Faltaban las llamadas de INF 5, INF 7 e INF 21. Incluir las llamadas Call INF 5; Call INF 7 ; Call INF 21 al programa de disparo de anlisis de riesgo. Herramienta utilizada: Function Editor de Kappa PC. Defectos detectados mediante metodologa de caja negra Error 15: SGR no puede determinar los valores de RE (02) y RE (03) Luego de la prueba de caja negra se editan las llamadas a los algoritmos de clculo y se detecta un error en el traspaso de argumentos, producido por el copiado y pegado de sentencias Kappa. INF1(1) ; INF1(1) ; INF1(1) ; INF7(4) ; Prob(R01) ; RE(R01) ; Prob(R01) ; RE(R01) ; expresar como Prob(R01) ; RE(R01) ; expresar como Prob(R04) ; RE(R04) ; .
INF2(2) ; Prob(R02) ; RE(R02) ; INF2(3) ; Prob(R03) ; RE(R03) ;
Tabla 6.5.2 resultados detallados de revisiones y pruebas de integracin.
199
6.6 Resultados de las pruebas de sistema. Teniendo en cuenta los criterios de diseo de pruebas descriptos en la seccin 6.3.4, se cargan diez casos de pruebas. Los resultados del SGR se compararon con los del especialista (resultado esperado).
Caso Puntos a destacar del caso analizado
Caso 1 Caso 2 Caso 3
Cliente con bajos conocimientos del proceso y muy exigente Integrador con bajos conocimientos de las tcnicas a aplicar Cliente e integrador adolecen de falta de capacitacin en seguridad industrial , desconocen el proceso a automatizar y el proceso es muy peligroso Cliente con bajos conocimientos de seguridad industrial y proceso peligroso pero el integrador tiene muy buenos conocimientos de seguridad industrial y conoce procesos similares. El integrador tiene sueldos inferiores a los del mercado. Tercero con conocimientos y experiencia insuficientes Todos los participantes son fiables poseen conocimientos y experiencia muy buenos, el proceso es altamente contaminante del medio ambiente. El proveedor del equipo de automatizacin no es muy fiable El proceso es muy complejo y grande, el contrato y el cliente son muy inflexibles. El integrador estimo un esfuerzo muy por debajo del necesario El hardware es poco fiable y opera en condiciones ambientes extremas Existen pocos datos del cliente y las especificaciones del proceso son muy pobres
Caso 4
Caso 5 Caso 6 Caso 7 Caso 8 Caso 9 Caso 10
Tabla 6.6.1 Descripcin general del caso.
En la tabla 6.6.1 se describe en forma somera los puntos relevantes de los casos de prueba mientras que el la tabla 6.6.2 se detalla la situacin de contexto de cada caso en forma precisa.
200
CLASE
Atributo (Slot) Descripcin Abreviatura Estado econmicoCL:EFin financiero Equipo de Ingeniera CL:Ing propio
1 MB
2 R
Caso de prueba 4 5 6 7
10 ? ? ? ? ? ? ? ? ? ? ?
MB MB MB MB MB MB MB
Conocimientos del CL:Conocimie MM MB MB MB MB MB MB MB MB proceso a automatizar nto Conocimientos y exp. en seg. industrial. Estndares de Calidad (Exigencias) Estndares de Mantenimiento Flexibilidad Cooperacin Capacidad de coordinacin proyecto Descripcin de especificaciones Clusulas limitativas Intereses punitorios Flexibilidad Tipo Fiabilidad Tecnologa Costo Tiempo de reposicin Respaldo tcnico y comercial Conectividad Fiabilidad Tecnologa Costo Amigabilidad Manejo integral del proyecto Control de configuracin Diseo arquitectnico Cliente CL:ExpSegIn d CL:ECalid CL:EMant CL:Flex CL:Coop CL:GP CONT:Esp CONT:CLim CONT:IP CONT:Flex CONT:Tipo HW:Fiab
HW:Tecn HW:Cost HW:TRep HW:Resp HW:Conec
MB MB MM MM MB MB MB MB MB AA R R R BB BB BB BB BB
MM MB MB MB MB MB MB MB MB M M M M B B B B MB MB MB MB MB MB MB MB MB MB MB MB MB MB MB MB MB MB MB MB MB B B B B B B MB
Contrato
AA A A A AA BB BB BB BB ? R MB MB MB R MB MB MB MB ? SI SI SI SI SI No No SI SI ? AA AA AA AA AA AA AA AA BJ AA
MB MD B MB MB MB MD B MB MB MB MD B MB MB MB MD B MB MB MB MD B MB MB MB MD B MB MB MB MD B MB MB MB MD B MB MB M MD B MB MB MB MD B MB MB
Hardware
Herramienta de desarrollo
HD:Ffiab HD:Tec HD:Cost HD:Amig HD:MIP HD:CConf HD:DArq
MB MB MB MB MB MB MB MB MB MB B B B B B B B B B B B B B B B B B B B B MB MB MB MB MB MB MB MB MB MB B B B B B B B B B MB MB B B B B B B B B B B B B B B B B B B B
Tabla 6.6.2 Descripcin detallada de casos.
201
Atributo (Slot) CLASE Descripcin Estado econmico financiero Calificacin Experiencia en PLC Experiencia en HMI Experiencia en SCADA Experiencia en Servos Experiencia en Variadores Experiencia en PC Indust. Experiencia en redes Exp. en seguridad industrial Calificacin general Gestin de proyectos Capacidad trabajo en equipo Carga de trabajo Niv. Sueldos Abreviatura 1 2 3
Caso de prueba
10
INTEG:EFin
MB MB MB MB MB MB MB MB MB MB
INTEG:Calif
MB MM MB MB MB MB MB MB MB MB
INTEG:ExpPLC
MB
MB MB MB MB MB MB MB MB
INTEG:ExpHMI
MB
INTEG:ExpSCA
MB
INTEG:ExpSERV
INTEG:ExpACC
MB MB
MB MB MB MB MB
Integrador
INTEG:ExpIPC
MB MB
INTEG:ExpNET
MB MB MB
INTEG:ExpSegIn MB MB MM MB MB MB MB MB MB MB d INTEG:CGral MB M MB MB MB MB MB MB MB MB
INTEG:GP
MB
INTEG:Equipo
MB
INTEG:Carga INTEG:NivSueld o
BB
BB
BB
BB
BB
AA
BJ
BJ
BJ
BJ
MB MD MD MM MB MM MB MB MB MB
Tabla 6.6.2 Descripcin detallada de casos (continuacin).
202
CLASE
Atributo (Slot) Descripcin Abreviatura Esp. proceso Similitud (con procesos existentes) Temperatura ambiente Peligrosidad Tipo de ambiente de operacin Toxicidad Estado general de proceso Tamao Complejidad Requerimientos : Fiabilidad Precisin PI: ReqFiab PI: ReqPreci PI: ReqVel PI: ReqCComb PI: ReqCSeq PI: ReqCPID PI: ReqCVel PI: ReqCPos PI: ReqIA PI: GradoCon PI: DimED PI: DimSD PI: DimEA PI: DimSA PI: DimPant PI: Esp PI: Sim PI: Temp PI: Pelig
1 MM BB BB
2 MM BB BB Nor R MD A MM
3 MM BB BB AA Agr A MM MD A MM
Caso de prueba 4 5 6 7 MM BB BB AA R BJ BB BB MB MB AA BB AA AA BB AA
8 R BB BB AA
9 MM BB AA Nor R MD A MM
10 ? ? ? Nor R MD A R
PI: AmbOp Nor PI: Tox PI: Est PI: Dim PI: Complej R MD A MM
Agr Nor Agr Agr Agr A MM B B A A A
MB MB MB A BJ MB A A R
MD MD MD A MB A R BJ B
Proceso Industrial
Velocidad Control combi. Control sec. Control PID Control velocidad Control posicin Control IA Grado de conocimiento Cantidad de: Entradas digitales Salidas digitales Ent. analgicas Sali. analgicas Pantallas HMI + SCADA
400 200 20 20 40
400 200 20 20 40
1500 340 150 70 120
1500 1500 1500 1500 6000 340 150 70 120 340 150 70 120 340 150 70 120 340 150 70 120 3500 2000 1900 500
400 200 20 20 40
6000 3500 2000 1900 500
Comunicacin Sist PI: imCom Corporativos Corp
203
204
CLASE
Atributo (Slot) Descripcin Abreviatura Estado PROV:EFin econmico an financiero Servicio de postventa PROV:SPG gral. Servicio de postventa en PROV:SPL lugar de la implantacin Tiempo de PROV:Tres respuesta p Capacidad de PROV:CFin financiamiento an Servicios de capacitacin Etapa actual PROV:Capa PROY: Etapa PROY:Eesf PROY:ERea l T:EFinan T:CTec T:Gproy T:Com
1 MB
2 MB
3 MB
Caso de prueba 5 6 7 MB MB MB
8 MB
9 B
10 MB
MB
MM
MB
Proveedor
MM
MB
B MB MB Of
300 855
B MB MB Of
300 855
B MB MB Of
1000 3750
B MB MB Of
1000 3750
B MB MB Pro
1000 3750
B MB MB Pro
4000 3750
M MB M Pro
4000 3750
B MB MB Pro
500 13 K
MB B MB Pro
2000 2082
B MB MB Pro
1000 1010
Proyecto
Esfuerzo estimado Esfuerzo real Estado econmico financiero Capacidad Tcnica Gestin del proyecto Comunicacin
MB B B MB
MB B B MB
MB B B MB
MB B B MB
MB M MM R
MB MB MB MM
MB MB MB MB
MB MB MB MB
MB B B MB
MB B B MB
Los casos ingresados se corresponden con casos reales analizados previamente por el Especialista. Esto permiti comparar las conclusiones del SGR con las del referente. A continuacin se detallan lo resultados generales obtenidos por el SGR para cada uno de los casos de prueba planteados. En los diez casos se exponen los cinco riesgos que el SGR consider prioritarios con las respectivas sugerencias para mitigar los mismos.
Tercero
205
ID: Caso de uso
Prioridad
Riesgo
CU 1
Revisin
CU 2
CU 3
CU 4
Fecha de revisin
Resultado esperado
Soluciones sugeridas
Rev. 0: 12/11/5
Rev. 1: 13/11/5 Rev. 0: 12/11/5 Rev. 1: 13/11/5 Rev. 2: 13/11/5 Rev. 0: 14/11/5
R29 R21 R13 R05 R12 R29 R33 R05 R08 R21 R21 R29 R04 R05 R06 R21 R29 R19 R04 R05 R29 R23 R27 R06 R09
1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5
S29.1 S21.3 S13.1 S05.1 S12.1 S29.1 S33.1 S05.1 S08.1 S08.5 S21.1 S21.1 S29.1 S04.1 S05.1 S06.1 S21.1 S29.1 S19.1 S04.1 S05.1 S29.1 S23.1 S27.1 S06.1 S09.1
S29.2
Cr
S33.3 S05.2 S08.2
Cr
Cr
S08.3
S08.4
ID: Caso de prueba
S06.2
S06.3
S06.4
Rev. 0: 14/11/5
Rev. 0: 14/11/5
S23.2 S06.2 S06.3 S08.4
Nota Caso 1 (revisin 0): SGR estableci orden errneo de prioridad (R21, R29, R13, R05, R12). Se revisaron los valores estadsticos para este tipo de riesgo encontrando un error de clculo se modific W 21.1 con el valor correcto mediante la funcin Parametrizacin del SGR. se modific W 21.1. En la siguiente revisin se obtuvo el resultado esperado. Nota Caso 2 (revisin 0): SGR estableci orden errneo de prioridad (R05, R29, R33, R08, R21). Se revisaron los valores iniciales de los pesos W 5.1 y W 5.2, debido a un error de tipeo su valor era incorrecto. Se corrigieron mediante la funcin Parametrizacin del SGR. Nota Caso 2 (revisin 1): SGR obtuvo el orden de prioridad esperada pero la solucin propuesta para R33 fue solamente S33.1, faltaba la solucin S33.3.Se corrigi el peso W33.3 mediante la funcin Parametrizacin del SGR. Al efectuar la revisin 2 se obtuvo el resultado esperado.
Tabla 3.6.3 Resultados generales de pruebas de sistemas
206
ID: Caso de uso
Prioridad
Riesgo
CU 1
Revisin
CU 2
CU 3
CU 4
Fecha de revisin
Resultado esperado
Soluciones sugeridas
Rev. 0: 15/11/5
R04
S04.1
ID: Caso de prueba
Rev. 0: 15/11/5
R27 R27 R18 R21 R29 R12 R02 R27 R21 R04 R02 R27 R28 R21 R04 R28 R09 R29
1 2 3 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5
S26.1 S27.1 S18.1 S21.1 S29.1 S12.1 S02.3 S27.1 S21.1 S04.1 S02.4 S27.5 S28.1 S21.2 S04.1 S28.1 S09.1 S29.1
S26.2 S27.2
Rev. 0: 15/11/5
S02.4 S27.4
Rev. 0: 16/11/5
S02.5 S27.3 S28.2
10
Rev. 0: 16/11/5
S28.2
S28.3
Tabla 3.6.3 Resultados generales de pruebas de sistemas (continuacin)
En el apndice E2 se detallan los textos asociados a las soluciones especificadas en la columna resultados esperados. Como complemento de los resultados anteriores, en las tablas 3.6.4, 3.6.5, 3.6.7, 3.6.8, 3.6.9, 3.6.10, 3.6.11 ,3.6.12 y 3.6.13, se resumen de los resultados obtenidos por el SGR (para cada caso de prueba). En las mismas se describen los cinco riesgos principales y se listan por orden de prioridad las soluciones a implementar para controlar los mismos.
207
Puntos a destacar del caso analizado Cliente con bajos conocimientos del proceso y muy exigente. Proceso peligroso Prio Riesgo Descripcin Soluciones sugeridas 1 CASO 1 2 3 4 5 R29 R21 R13 R05 R12 Sobrecarga de trabajo Utilizar herramientas de desarrollo ms eficientes, trabajar en equipo y/o contratar personal experimentado.
Prdida humanas y/o Dado que el proceso es complejo y peligroso asegurar accidentes una adecuada gestin del proyecto y puesta en marcha. Prdida de info. proceso Estimaciones de esfuerzo errneas Perder licitacin Disear sistema de alta fiabilidad, robusto. Prever asistencia tcnica al cliente. Mejorar especificaciones mediante entrevistas, estudio de procesos similares, maquetas y/o prototipos Buscar ms datos, mejorar mtodos de estimacin de esfuerzo.
Tabla 6.6.4 resultados generales obtenidos por el SGR para el caso de prueba 1.
Puntos a destacar del caso analizado Integrador con bajos conocimientos de las tcnicas a aplicar Prio Riesgo 1 R29 Descripcin Sobrecarga de trabajo Atraso en el cronograma de trabajo Soluciones sugeridas Utilizar herramientas de desarrollo ms eficientes, trabajar en equipo y/o contratar personal experimentado. Este tipo de proceso requiere un integrador ms capacitado y experimentado. Mejorar la gestin del proyecto para evitar prdidas econmicas. Mejorar especificaciones mediante entrevistas, estudio de procesos similares, maquetas y/o prototipos. Capacitar al personal afectado al proyecto en tcnicas de estimacin de proyectos software Tomar curso de tcnicas digitales y programacin de PLC o contratar personal con conocimientos del tema. Tomar curso de diseo de circuitos secuenciales y PLC o contratar personal con conocimientos del tema. Tomar curso de SCADA o contratar personal con conocimientos del tema. Tomar curso de mecanismos y servo o contratar personal con conocimientos del tema. Tomar curso de motores y accionamientos o contratar personal con conocimientos del tema 5 R21 Prdida humanas y/o accidentes Dado que el proceso es complejo y peligroso asegurar una adecuada gestin del proyecto y puesta en marcha
R33
CASO 2
R05
Estimaciones de esfuerzo errneas
R08
Falta de capacitacin y/o experiencia del personal
208
Puntos a destacar del caso analizado Cliente e integrador adolecen de falta de capacitacin en seguridad industrial , desconocen el proceso a automatizar y el proceso es muy peligroso Prio Riesgo 1 R21 Descripcin Prdida humanas y/o accidentes Sobrecarga de trabajo Contaminacin ambiental Estimaciones de esfuerzo errneas Soluciones sugeridas Dado que el proceso es complejo y peligroso asegurar una adecuada gestin del proyecto y puesta en marcha. Utilizar herramientas de desarrollo ms eficientes, trabajar en equipo y/o contratar personal experimentado. Reforzar las medidas y criterios de seguridad capacitar y concientizar al personal, brindar equipos de seguridad. Mejorar especificaciones mediante entrevistas, estudio de procesos similares, maquetas y/o prototipos Mejorar especificacin del proceso (utilizar entrevistas y si hace falta maquetas y/o prototipos). 5 R06 Especificaciones incompletas y/o errneas Apoyar y asesorar al cliente con personal experimentado en procesos similares. Buscar antecedentes de procesos similares. Optimizar la gestin del proceso, evaluar y controlar resultados en forma continua.
2 CASO 3 3 4
R29 R04 R05
Tabla 6.6.6 resultados generales obtenidos por el SGR para el caso de prueba3.
Puntos a destacar del caso analizado Cliente con bajos conocimientos de seguridad industrial y proceso peligroso pero el integrador tiene muy buenos conocimientos de seguridad industrial y conoce procesos similares. El integrador tiene sueldos inferiores a los del mercado. Prio Riesgo 1 CASO 4 R21 Descripcin Prdida humanas y/o accidentes Sobrecarga de trabajo Prdida de personal clave Contaminacin ambiental Estimaciones de esfuerzo errneas Soluciones sugeridas Dado que el proceso es complejo y peligroso asegurar una adecuada gestin del proyecto y puesta en marcha. Utilizar herramientas de desarrollo ms eficientes, trabajar en equipo y/o contratar personal experimentado. Mejorar sueldos e incentivos de personal clave del proyecto, mejorar la motivacin de los diseadores. Reforzar las medidas y criterios de seguridad, capacitar y concientizar al personal, brindar equipos de seguridad. Mejorar especificaciones mediante entrevistas, estudio de procesos similares, maquetas y/o prototipos
R29
R19
R04
R05
209
Puntos a destacar del caso analizado Tercero con conocimientos y experiencia insuficientes Prio Riesgo 1 2 R29 R23 Descripcin Sobrecarga de trabajo Perturbaciones generadas por tercero Problemas de mantenimiento (fuera de garanta) Soluciones sugeridas Utilizar herramientas de desarrollo ms eficientes, trabajar en equipo y/o contratar personal experimentado. Establecer en el contrato clusulas limitativas Optimizar la gestin del proyecto Contratar ms personal, y/o optimizar servicios de gestin de asistencia tcnica Mejorar especificacin del proceso (utilizar entrevistas y si hace falta maquetas y/o prototipos). 4 R06 Especificaciones incompletas y/o errneas Apoyar y asesorar al cliente con personal experimentado en procesos similares. Buscar antecedentes de procesos similares. Optimizar la gestin del proceso, evaluar y controlar resultados en forma continua. Estudiar estndares de calidad del cliente revisar las condiciones de operacin finalmente revisar proyecto.
CASO 5
R27
R09
No cumplir con los estndares del proceso industrial
Puntos a destacar del caso analizado CASO 6 Todos los participantes son fiables poseen conocimientos y experiencia muy buenos, el proceso es altamente contaminante del medio ambiente. Prio Riesgo 1 R04 Descripcin Contaminacin ambiental Soluciones sugeridas Reforzar las medidas y criterios de seguridad, capacitar y concientizar al personal, brindar equipos de seguridad.
Puntos a destacar del caso analizado El proveedor del equipo de automatizacin no es muy fiable Prio Riesgo CASO 7 1 2 3 R26 R27 R18 Descripcin Problemas mant. (dentro de garanta) Problemas mant. (fuera de garanta) Prdida de reputacin (proveedor) Soluciones sugeridas Buscar proveedor ms fiable Establecer en el contrato clusulas limitativas Buscar proveedor ms fiable Establecer en el contrato clusulas limitativas Mejorar servicios de postventa y tiempo de respuesta
210
Puntos a destacar del caso analizado El proceso es muy complejo y grande, el contrato y el cliente son muy inflexibles. El integrador estimo un esfuerzo muy por debajo del necesario Prio Riesgo 1 R21 Descripcin Prdida humanas y/o accidentes Sobrecarga de trabajo Perder licitacin Soluciones sugeridas Dado que el proceso es complejo y peligroso asegurar una adecuada gestin del proyecto y puesta en marcha Utilizar herramientas de desarrollo ms eficientes, trabajar en equipo y/o contratar personal experimentado. Buscar ms datos, mejorar mtodos de estimacin de esfuerzo. Ayudar al cliente a establecer los requerimientos del proceso (por ej. mediante maquetas y/o prototipos). Adoptar mtodos de gestin de proyecto, evaluar y controlar resultados en forma continua. Contratar ms personal, y/o optimizar servicios de gestin de asistencia tcnica Buscar sucursal / proveedor local con buen servicio de asistencia tcnico-comercial.
CASO 8
2 3
R29 R12
R02
Baja productividad del proceso automatizado
R27
Problemas de mantenimiento (fuera de garanta)
Puntos a destacar del caso analizado El hardware es poco fiable y opera en condiciones ambientes extremas Prio Riesgo 1 R21 Descripcin Prdida humanas y/o accidentes Contaminacin ambiental Baja productividad del proceso automatizado Problemas de mantenimiento (fuera de garanta) Problemas legales Soluciones sugeridas Tomar recaudos ante la baja fiabilidad del hardware. Reforzar las medidas y criterios de seguridad, capacitar y concientizar al personal, brindar equipos de seguridad. Confinar el hardware en ambiente no agresivo Buscar Hardware ms robusto Buscar proveedor ms fiable Establecer en el contrato clusulas limitativas Establecer en el contrato clusulas limitativas 5 R28 Buscar sucursal / proveedor local con buen servicio de asistencia tcnico-comercial.
2 CASO 9
R04
R02
R27
211
Puntos a destacar del caso analizado Existen pocos datos del cliente y las especificaciones del proceso son muy pobres Prio Riesgo 1 2 CASO 10 R21 R04 Descripcin Prdida humanas y/o accidentes Contaminacin ambiental Soluciones sugeridas Tomar recaudos ante la baja fiabilidad del hardware. Reforzar las medidas y criterios de seguridad, capacitar y concientizar al personal, brindar equipos de seguridad. Establecer en el contrato clusulas limitativas 3 R28 Problemas legales Ayudar al cliente a establecer los requerimientos del proceso (por ej. mediante maquetas y/o prototipos). Adoptar mtodos de gestin de proyecto, evaluar y controlar resultados en forma continua. Estudiar estndares de calidad del cliente, revisar las condiciones de operacin finalmente revisar proyecto. Utilizar herramientas de desarrollo ms eficientes, trabajar en equipo y/o contratar personal experimentado.
4 5
R09 R29
No cumplir con estndares del proceso industrial Sobrecarga de trabajo
A continuacin se detallan los resultados numricos del anlisis realizado por el SGR para los diez casos.
Exposicin a riesgo RE Riesgo R01 R02 R03 R04 R05 R06 R07 R08 R09 R10

Baja productividad del equipo de desarrollo Baja productividad del proceso automatizado Baja fiabilidad del proceso automatizado Contaminacin ambiental Estimaciones de esfuerzo errneas
Caso de prueba 4 5 6 7 0 0 0 0 0 0 0 0 0 0 0
8 1.32
9 0
10 0
1,32 7,9 1,32 5,7 1,32 1,49 0 0 12 0 0
11,4 10,9 10,6 0,59 0 0 0 0 14
21.36 21.6 10.4 0 0 7.49 5.24 56.3 60.2
42,2 42,2 14,1
29,6 60,9 36,6 21,4 16,5 8,16
14.52 17,8 14.8 16.65 10,4 17.1 0.60 0.74 0.61 0 0 0 0 0 0 0 28.3 0
Especificaciones incompletas o 16,3 20,4 24,6 24,6 18,8 9,38 errneas Falta de aceptacin del producto 0,36 1,5 1,15 0,88 0.68 0,34 por parte de usuarios Falta de capacitacin / 18,7 52,9 18,7 0 0 0 experiencia del personal No cumplir con los estndares del 18 18 18 18 18 0 proceso industrial Pago de intereses punitorios por 0 0 0 0 0 0 mora o proceso cado
Tabla 6.6.14 resultados detallados del anlisis realizado por el SGR para los diez casos.
212
Exposicin a riesgo RE Riesgo R11 R12 R13 R14 R15 R16 R17 R18 R19 R20 R21 R22 R23 R24 R25 R26 R27 R28 R29 R30 R31 R32 R33 Descripcin del riesgo Perder el cliente Perder licitacin Prdida de informacin del proceso Prdida de informacin del proyecto Prdida de materia prima Prdida de reputacin en el mercado (Integrador) Prdida de reputacin en el mercado (cliente) Prdida de reputacin en el mercado (Proveedor) Prdida de personal clave, difcil de reemplazar Prdida de representacin/ certificacin del proveedor Prdidas humanas y/o accidentes Prdida / dao de equipos de proceso. Perturbaciones causadas por tercero Problemas en otros proyectos en desarrollo Problemas de facturacin Problemas de mantenimiento (en garanta) Problemas de mantenimiento (fuera de garanta) Problemas legales Sobrecarga de trabajo Software de aplicacin de mala calidad Reserva Reserva Retraso en cronograma de trabajo 1 2 3 Caso de prueba 4 5 6 7 0 0 0 0 0 0 0 0 0 0 0,5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7,3 0 0 0,5 0 0 0 0 10 8 0 4 0 0 0 8 9 10
0,63 1,96 0,93 0,36 0,34 22,5 22,5 22,5 22,5 38,4 38,8 0 0 17,1 0 0 0 0 0 0 0 0 0 0 0
0,85 0,66 0,34 22,5 2,5 0 0 0 0 0 0 22,5 38,8 0 0
0,37 1,06 0,4 0,04 0,04 0,18 0,3 1,17 0,73 0,12 0 0 0 0 27 14,6 0 0 0 0 54 0 0 0 0 0
0,73 0,09 0,04 0 0 0 0 0,73 0,72 0,41 0 0 0 0 0 173
47,3 47,3 100 100
141 121
0,71 1,26 0,96 0,73 0,56 2,06 2,06 2,06 2,06 26,2 3,3 12,9 3,13 3,13 3,13 0 19 4,6 4,9 74,3 0 0 0 0 0 0 0
0,5 8,03 0,51 3,71 3,71 3,71 3,13 0 0 0 0 3,17
0,87 0,87 0,87 0,87 19 0 72 19 0 68 19 0 59 0 0 0 18,9 0 71,3 0 0 0
0,31 12,4 0,14 19 18,5 0
3,21 15,3 42,4 74,3 0 0 0 0 0 0 0 18,1 0 0 0
4,01 0,14 0 0 0 0
4,55 70,8 4,86 4,42 4,52 0
4,46 0,36 13,2
Tabla 6.6.14 resultados detallados del anlisis realizado por el SGR para los diez casos.
213
6.7 Tasa de fallas Tasas de fallas = Total de errores detectados / Nmero de lneas del programa Errores detectados durante revisin de requisitos = 4 Errores detectados durante revisin de diseo = 5 Errores detectados durante revisin y pruebas de cdigo = 22 Errores detectados durante pruebas de sistema = 3 Total de errores detectados = 34 (Errores detectados y corregidos) Nmero de lneas de cdigo = 21.176 Tasa de fallas = 34 / 21176 = 1,6 errores / 1000 Lneas de cdigo Tomando como referencia una media 2,3 errores / 1000 Lneas de cdigo [ULC, 2000]. La tasa de fallas del SGR es 30 % inferior a la media de referencia. 6.8 Evaluacin de revisiones y pruebas del SGR. Teniendo en cuenta las revisiones y pruebas exhaustivas a las que fue sometido el SGR, la complementacin de diferentes y probadas metodologas de deteccin de defectos y la baja tasa de errores detectados durante las mismas, se puede considerar que el software tiene una alta fiabilidad. Durante las pruebas se fueron depurando errores de cdigo y optimizando la parametrizacin del sistema. Los resultados obtenidos por el SGR son similares a los que obtuvo el especialista en forma manual, es fiable y resulta fcil de operar, permitiendo a un usuario sin conocimientos de anlisis de riesgo conocer rpidamente los puntos peligrosos de un proyecto SAC. Desde el punto de vista de la mantenibilidad, el sistema presenta una lectura clara de su estructura y cdigo, debido a:
214
- La estructura del SGR est fuertemente orientada al proceso de GR. - El diseo orientado a objetos. - La aplicacin est ampliamente comentada. - Los nombres utilizados para las variables, funciones, procesos, algoritmos y objetos indican en forma directa el propsito del elemento. - La estructura propia de KappaPCpermite leer fcilmente el cdigo. Las herramientas Browser, Session y Function Editor proveen una visin general (alto nivel) de la estructura del software y un detalle de cada componente (bajo nivel).
215
216
CAPTULO 7 CONCLUSIONES Y FUTURAS LNEAS DE TRABAJO
Captulo 7: Conclusiones y Futuras Lneas de Trabajo
217
218
7.1 Conclusiones Al terminar el desarrollo del SGR, se evaluaron los resultados del trabajo desde cinco perspectivas: - Aportes del SGR al desarrollo de software de sistemas de automatizacin y control. - Aportes de la experiencia de desarrollo del SGR para la construccin de sistemas de gestin de riesgos especializados en otras reas de ingeniera. - Evaluacin de la contribucin de los elementos tericos y prcticos aplicados al desarrollo SGR. - Evaluacin de metodologas y tcnicas de desarrollo utilizadas. - Evaluacin de las herramientas de desarrollo. 7.1.1 Aportes del SGR al desarrollo de software de sistemas de automatizacin y control. El sistema aporta las siguientes ventajas al desarrollo de SAC: - Aplicacin rpida, segura, sencilla y automatizada de metodologas de gestin de riesgo ampliamente probadas en otras reas de la ingeniera del software. De esta manera los desarrolladores de software de SAC, cuentan con asesoramiento en gestin de riesgos, sin necesidad de asesoramiento externo. - Deteccin anticipada de riesgos en cualquier etapa del proyecto, de esta forma todas las personas / empresas involucradas en el desarrollo de SAC pueden eliminar, reducir y/o transferir los mismos. - Adaptacin del sistema a condiciones de desarrollo diferentes sin necesidad de modificaciones de programas. La interfase de parametrizacin permite optimizar el SGR para mercados / pases con diferentes problemticas de construccin de SAC.
219
7.1.2 Aportes de la experiencia de desarrollo del SGR para la construccin de sistemas de gestin de riesgos especializados en otras reas de ingeniera. La metodologa de construccin de software, los modelos de gestin de riesgos y el cdigo (reutilizable) desarrollados para el SGR, pueden ser fcilmente adaptados al desarrollo de sistemas automatizados de gestin de riesgos para otras reas de la Ingeniera. Con la ayuda de un especialista en el anlisis de riesgos del rea seleccionada, es posible reutilizar el conocimiento obtenido durante la construccin del SGR, para otras especialidades de la Ingeniera. 7.1.3 Evaluacin de la contribucin de los elementos tericos y prcticos aplicados al desarrollo del SGR. La determinacin de exposicin a riesgos obtenida mediante la frmula de Behm, la identificacin del entorno de desarrollo mediante la Taxonoma de riesgos propuestas por el SEI, y el proceso de gestin elaborado por Barry Bhem constituyen tres de los cuatro pilares bsicos para el desarrollo del SGR. El modelo del SGR se completa con el cuarto pillar construido a partir del conocimiento terico y prctico brindado por el especialista en anlisis de riesgos en SAC. 7.1.4 Evaluacin de las metodologas y tcnicas de desarrollo utilizadas. La metodologa MTRICA 3 combinada con tcnicas de programacin orientada a objetos, permitieron un desarrollo de proyecto claro, ordenado y eficiente. COCOMO II permiti estimar en forma precisa el esfuerzo de construccin del SGR, el valor real fue 3 % superior al calculado. La tcnica de representacin del sistema mediante Casos de uso brind una visin clara del sistema a lo largo de todo el proyecto. Combinada con la interfase de Control de configuracin permiti identificar y seguir en forma eficiente los documentos y elementos que componen el proyecto. Los mtodos de pruebas aplicados durante cada etapa del ciclo de vida del SGR contribuyeron a la mejora continua de la calidad del producto. Mediante las mismas se detect anticipadamente errores y/o omisiones que afectaran la fiabilidad del mismo.
220
7.1.5 Evaluacin de las herramientas de desarrollo Durante el proyecto se utilizaron las siguientes herramientas de desarrollo: USC-COCOMO II Microsoft Project Microsoft Access Kappa PC
USC COCOMO II aceler la estimacin de esfuerzo mediante COCOMO II, su aplicacin result sencilla y econmica. El sistema Microsoft Project permiti desarrollar, modificar y actualizar la planificacin del proyecto minimizando el tiempo de ejecucin de dichas tareas. Mediante Microsoft Access se construy un sistema de control de configuracin personalizado, de manera rpida y econmica. El mismo result muy fiable y amigable. La herramienta de edicin Kappa PC facilit y aceler la construccin del prototipo del SGR, el mismo fue utilizado para comprobar las suposiciones que se postularon al comienzo del trabajo de tesis. Cabe destacar que Kappa PC deja abierta la posibilidad de utilizar su motor de inferencias y editores de reglas para futuras versiones del SGR. 7.2 Futuras lneas de trabajo. El autor considera factible la evolucin del SGR tanto en profundidad como en amplitud segn dos lneas de trabajo complementarias: 1) Desarrollar una optimizacin automtica de parmetros del SGR. 2) Desarrollo de una herramienta de gestin de riesgos para otras reas de la Ingeniera, que cuente con la posibilidad de ser modelizada sin necesidad de re- programacin.
221
7.2.1 Desarrollar una optimizacin automtica de parmetros del SGR. Si se incorpora al SGR la posibilidad de recopilar valores estadsticos en forma local y remota (de otras instalaciones de SGR va Internet) se abre la posibilidad de optimizar los parmetros del SGR en forma automtica mediante su incorporacin a una base de conocimientos. Como se cit en la seccin 7.1.5 el prototipo de SGR puede aprovechar las posibilidades que brinda Kappa PC para del desarrollo de dicha base. Una vez probada esta versin de prototipo se podr migrar el cdigo a un lenguaje de programacin ms potente y actualizado (por ejemplo CLIPs). 7.2.2 Desarrollo de una herramienta de gestin de riesgos para otras reas de la Ingeniera, que cuente con la posibilidad de ser modelizada sin necesidad de re- programacin. Como se ha citado en la seccin 7.1.2, existen reas de la Ingeniera para las cuales se puede desarrollar fcilmente sistemas especializados. Teniendo en cuenta los criterios tericos prcticos desarrollados para el SGR, es posible implementar funciones de modelizacin que permitan adaptar el sistema a otras reas de la Ingeniera sin necesidad de reprogramar el sistema. Sera necesario disear un sistema de modelizacin segn dominio que permita la creacin y modificacin de - Listado de riesgos tpicos. - Clases del TBQ. - Atributos de las clases del TBQ. - Asociaciones de factores / atributos que genera cada riesgo. - Ecuaciones de clculo de probabilidad. - Soluciones. - Relaciones riesgo solucin. - Grficos de resultados. De esta forma, el proceso de modelizacin podra se desarrollado por un especialista del nuevo dominio sin la intervencin de IS. Este desarrollo se puede complementar con las mejoras propuestas en el punto 7.2.1.
222
APNDICE A INTERFASE DE GESTIN
Apndice A: Gestin del proyecto
223
224
A 1 Actividades de inicio del proyecto En esta fase se desarrollan las siguientes actividades: - Planificacin general. - Estimacin de esfuerzo. - Cronograma general del proyecto. A continuacin se detallan las mismas. A 1.1 Planificacin general El ciclo de vida seleccionado es del tipo prototipo evolutivo, en la figura A1.1 se representa el esquema general construccin de software SGR basado en Mtrica 3.
EVS
ASI
DSI
CSI
Gestin del proyecto Interfase Control de configuracin Interfase de Seguridad Interfase Aseguramiento de calidad
Fig. A1.1 Proceso de construccin de software SGR basado en METRICA 3
EVS: Estudio de viabilidad del sistema. ASI: Anlisis del sistema. DSI: Diseo del sistema. CSI: Construccin del sistema.
225
A 1.2 Estimacin de esfuerzo Para estimar el esfuerzo se seleccion el modelo COCOMO II, mediante la herramienta USC-COCOMO II [Horowitz, 1999] se logr un desarrollo rpido y ordenado del procedimiento de estimacin en cuestin. Considerando los procedimientos necesarios para le etapa de diseo temprano se siguieron los siguientes pasos: - Clculo del tamao de la aplicacin. - Determinar valores de factores de ajuste. - Determinar valores de multiplicadores de esfuerzo. A continuacin se detallan los mismos. Clculo del tamao de la aplicacin Para ello se aplic el mtodo Puntos de funcin. Siendo: EI EO EQ ILF ELF FP Entradas externas. Salidas externas. Consultas. Archivos de datos lgicos internos. Archivos de datos lgicos externos. Puntos de funcin sin ajustar.
Para calcular FP fue necesario calcular la cantidad y complejidad de cada elemento. El criterio aplicado en la estimacin de complejidad es el siguiente:
ILF & EIF Cantidad de registros Elementos de datos
1a 19 1 2a5 6+ 20 a 50 51 o ms 0o1 2a3 4+
EO & EQ Tipos de archivos Elementos de datos

1a5 6a 19 20 o ms 0o1 2a3 3+
EI Tipos de archivos Elementos de datos

1a4 5a 15
16+
Baja Baja Media Baja Media Alta Media Alta Alta
Tabla A1.2.1 criterio de evaluacin de complejidad.

Apndice A: Gestin del proyecto Autor: Ing. Jos Luis del Ro
226
Teniendo en cuenta los datos de diseo y el criterio de evaluacin de complejidad (Tabla A1.2.1) se determinan: EI: Entradas externas Existen 10 grupos lgicos de entradas externas on-line al sistema, 9 estn determinados por el cuestionario TBQ-SAC ms una interfase de ingreso de parmetros del SGR. Grupos de datos Cliente Contrato Integrador Hardware Herramientas Proceso Proveedor Proyecto Tercero Cant. Elementos registros de datos 1 1 1 1 1 1 1 1 1 20 14 8 21 10 9 29 9 9 8 20 7 2 Complejidad Baja Media Alta X X X X X X X X X X 1
Cuestionario TBQ-SAC
Ingreso de pesos W y K Totales
Tabla A1.2.2 Estimacin de Entradas externas del SGR.
EO: Salidas externas Existen 3 grupos lgicos de salidas externas on-line al sistema, el primero est asociado al perfil de riesgos del proyecto obtenido luego de analizar el contexto en el que se desarrolla, el segundo muestra los riesgos prioritarios y el tercero contiene la propuesta de solucin para los riesgos prioritarios. Grupos de datos Perfil de riesgo Riesgos prioritarios Solucin Totales Cant. registros 33 5 1 Elemento s de datos 34 10 14 Complejidad Baja Media Alta X X X 1 2
Tabla A1.2.3 Estimacin de Salidas externas del SGR.
227
Grupos de datos SGR Totales
ILF: Archivos internos Cant. Elementos registros de datos 12 124
Complejidad Baja Media Alta X 1
Tabla A1.2.4 Estimacin de Archivos internos del SGR.
Con la ayuda del USC-COCOMO II, se calculan los puntos de funcin sin ajustar y las lneas de cdigo:
Figura A1.2.1 Estimacin de FP y Lneas de cdigo mediante USC-COCOMO II.
228
Determinacin de factores de escalamiento del exponente SF Son cinco factores que afectan B, el exponente del tamao en COCOMO II, PREC, FLEX, RESL, TEAM, EPML. A continuacin se determina el valor de los mismos en base a los criterios impuestos por el modelo COCOMO II: PREC: Desarrollos previos similares
PREC 0 1,24 2,48 3,72 4,96 6,l2 El nuevo desarrollo: es idntico a previos es muy parecido a previos es bastante parecido a previos presenta aspectos novedosos es muy diferente a previos es totalmente diferente a previos
Tabla A1.2.5 Criterios de asignacin de PREC.
Para el SGR
PREC = 4,96 (Aspectos Novedosos)= Low (USC-COCOMO II)
FLEX: Flexibilidad del desarrollo

FLEX 0 1.01 2.03 3.04 4.05 5.07 Existe : metas generales cierto acuerdo acuerdo general cierta flexibilidad flexibilidad ocasional riguroso
Tabla A1.2.6 Criterios de asignacin de FLEX.
Para el SGR
FLEX = 4.05 (flexibilidad ocasional) = Low (USC-COCOMO II)
RESL: Manejo de riesgos y arquitectura

RESL 0 1,41 2,83 4,24 5,85 7,07 El plan identifica: todos los riesgos crticos la mayora de los riesgos crticos plan identifica muchos de los riesgos crticos plan identifica algunos de los riesgos crticos plan identifica pocos riesgos crticos no identifica los riesgos crticos Porcentaje de esfuerzo requerido 40% 33% 25% 17% 19% 5% Riesgos crticos 0 0 <1 2a4 5 a 10 > 10
Tabla A1.2.7 Criterios de asignacin de RESL.

Apndice A: Gestin del proyecto 229 Autor: Ing. Jos Luis del Ro
Para el SGR
RESL = 4,24 = Nom (USC-COCOMO II)
TEAM: Cohesin del equipo de desarrollo

TEAM 0 Observaciones Interacciones fluidas, objetivos y culturas de accionistas totalmente consistentes, total habilidad y disponibilidad de accionistas para acomodar objetivos de otros accionistas, dilatada experiencia previa operando como equipo, visin y compromisos 100% compartidos. Interacciones altamente cooperativas, objetivos y culturas de accionistas fuertemente consistentes, fuerte habilidad y disponibilidad de accionistas para acomodar objetivos de otros accionistas, considerable experiencia previa operando como equipo, visin y compromisos considerablemente compartidos por todos lo miembros. Interacciones principalmente cooperativas, objetivos y culturas de accionistas considerablemente consistentes, considerable habilidad y disponibilidad de accionistas para acomodar objetivos de otros accionistas, mediana experiencia previa operando como equipo, visin y compromisos medianamente compartidos por los integrantes. Interacciones bsicas cooperativas, objetivos y culturas de accionistas bsicamente consistentes, habilidad y disponibilidad bsica de accionistas para acomodar objetivos de otros accionistas, poca experiencia previa operando como equipo, visin y compromisos poco compartidos. Algunas interacciones difciles, objetivos y culturas de accionistas algo consistentes, algo habilidad y disponibilidad de accionistas para acomodar objetivos de otros accionistas, poca experiencia previa operando como equipo, visin y compromisos poco compartidos. Interacciones difciles, objetivos y culturas de accionistas poco consistentes, poca habilidad y disponibilidad de accionistas para acomodar objetivos de otros accionistas, nada de experiencia previa operando como equipo, visin y compromisos nada compartidos
1.1
2,19
3,29
4,38
5,48
Tabla A1.2.8 Criterios de asignacin de TEAM.
Para el SGR
TEAM = 0,0 = XHI (USC-COCOMO II)
EPML: Nivel de madurez estimada, en base al modelo de madurez de soft. CMM:

EPML 0 1,56 3,12 4,68 6,24 7,8 nivel 5 nivel 4 nivel 3 nivel 2 nivel 1, superior nivel 1, inferior. Nivel de madurez
Para el SGR
EPML = 3,12 = HI (USC-COCOMO II)

230 Autor: Ing. Jos Luis del Ro
En la figura A1.2.2 se vuelcan los valores determinados a la herramienta USCCOCOMO II.
Figura A 1.2.2 Determinacin de factores de escalamiento de exponente.
XHI: VHI: HI: NOM: LO: VLO:
Extra High. Very High. High. Nominal. Low. Very Low.
Determinacin de multiplicadores de esfuerzo COCOMO II sugiere que muchos de los 17 multiplicadores de esfuerzo no pueden estimarse en el diseo temprano, por lo que los reduce a 7 multiplicadores: - RCPX: Confiabilidad y complejidad del producto. - RUSE: Nivel de reutilizabilidad del desarrollo. Corresponde exactamente a su homlogo en el modelo de diseo post-arquitectura. - PDIF: Dificultad de uso de la plataforma. - PERS: Capacidad del personal de desarrollo.
- PREX: Experiencia del personal de desarrollo. - FCIL: Facilidades de desarrollo. - SCED: exigencias sobre el calendario. Corresponde exactamente a su homnimo en el modelo post-arquitectura. Para la estimacin de esfuerzo en la construccin del SGR se consideran los valores nominales salvo en el caso RCPX y RUSE. Considerando que el SGR deber tener una alta fiabilidad RECPX = HI y se desarrollar software reutilizable dentro de la aplicacin y con el propsito de reutilizarlo en futuras variantes del producto RUSE = VHI.
Figura A 1.2.3 Determinacin de multiplicadores de esfuerzo en USC-COCOMO II.
Estimacin de esfuerzo En las figuras A1.2.4 y A1.2.5 podemos ver los resultados obtenidos al aplicar el modelo COCOMO II mediante la ayuda de la herramienta USC-COCOMO II. Los mismos fueron empleados para disear el cronograma general de trabajos de construccin del SGR. El dato ms relevante es el esfuerzo total = 10.182 Personas / mes, esto implica una duracin de proyecto de 10 meses para una persona.
Apndice A: Gestin del proyecto Autor: Ing. Jos Luis del Ro
232
E n la figura A1.2.5 podemos observar la distribucin de esfuerzo estimada.
Figura A 1.2.4 Resultados de la estimacin de esfuerzos en el desarrollo del SGR mediante la herramienta USC-COCOMO II.
Figura A1.2.5 Resultados de la estimacin de esfuerzos en el desarrollo del SGR mediante la herramienta USC-COCOMO II.
A 1.3 Cronograma general de proyecto SGR Tomando como gua la metodologa Mtrica 3 y las estimaciones de esfuerzo, se desarrolla el siguiente cronograma de actividades.
Ao 2005 3/1 17/2 6/5 5/8 15/11
_______________________________________________________________________
Figura A 1.3 Cronograma de tareas (elaborado mediante Microsoft Project 2003)

A1.4: Hitos de entrega En base al cronograma de la figura A 1.3 se establecen los siguientes hitos de entrega 15/12/2005 Fin de captulo 1: INTRODUCCIN Documentos de salida: - Introduccin al proceso gestin del riesgo en SAC. - Objetivos de la tesis. - Organizacin general de la tesis. 05/01/2005 Fin de captulo 2: DESCRIPCIN DEL PROBLEMA Documentos de salida: - Informe de evolucin histrica de los sistemas de automatizacin y control. - Informe sobre estado actual de la tecnologa de SAC. - Sntesis de antecedentes de control de riesgos en IT. - Identificacin del problema. - Descripcin de solucin propuesta. 25/03/2005 Fin de captulo 3: ESTUDIO DE VIABILIDAD Documentos de salida: - Alcance del Sistema. - Descripcin de situacin actual. - Definicin de requisitos del sistema. - Alternativas de solucin. - Valoracin de alternativas. - Seleccin de solucin. 05/05/2005 Fin de captulo 4: ANLISIS DE REQUISITOS DEL SGR Documentos de salida: - Definicin del sistema. - Entrevistas transcriptas durante la educcin del proceso de GR.
- Listado de clases identificadas. - Listado asociaciones identificadas. - Listado de atributos identificados. - Descripcin de inferencias identificadas. - Descripcin de frmulas identificadas. - Descripcin de procedimientos identificados. - Descripcin de Interfases de usuario. - Plan de pruebas. 07/08/2005 Fin de captulo 5: DISEO DEL SGR Documentos de salida: - Arquitectura del SGR. - Diseo de clases. - Diseo de interfases de usuario. - Diseo de inferencias. - Diseo de algoritmos de clculo. - Diseo de procedimientos. - Especificacin de entorno tecnolgico de desarrollo. - Especificacin de entorno tecnolgico operativo. - Especificacin tcnica de plan de pruebas. 15/11/2005 Fin de captulo 6: CONSTRUCCION DEL SGR Documentos de salida: - Archivos de programa fuente. - Resultados de pruebas unitarias. - Resultados de pruebas de integracin. - Resultados de pruebas del sistema. A 2 Actividades de seguimiento y control - Seguimiento y control del cronograma de actividades. - Interfase de aseguramiento de calidad (ver seccin D). - Interfase de control de configuracin (ver seccin C). - Interfase de seguridad (ver seccin B).
236
A 3 Actividades de cierre del proyecto - Desarrollo presentacin power-point para defensa de Tesis. - Defensa de Tesis.
237
238
APNDICE B INTERFASE DE SEGURIDAD
Apndice B: Gestin de seguridad
239
Apndice B: Gestin de seguridad
240
INTERFASE SEGURIDAD B1.1 Introduccin El SGR puede sufrir los siguientes ataques durante su construccin y operacin: - Ataques al hardware - Factores ambientales (humedad, temperatura, polvo). - Suministro de inadecuado de energa elctrica (cortes, sobre tensiones). - Interferencia electromagntica. - Conexionado errneo. - Rotura intencional. - Robo. - Ataque al software - Borrado. - Modificacin: Virus. - Robo: Copias no autorizadas del producto, o uso sin licencia. Ataque a los datos - Borrado. - Modificacin. - Robo: (Copias no autorizadas del producto, o uso sin licencia). En la tabla siguiente de detallan los impactos que produciran por los mismos.
IMPACTO Secreto Hardware Robado Copiado Pirateado Revelados Inferidos Acreditados por otros Integridad Sobrecargado Destruido Daado Modificado Daado Disponibilidad Equipo no disponible para desarrollo Software no disponible para desarrollo y/o pruebas Datos de prueba y /o documentacin no disponibles
Tipo de ataque
Software
Datos
El SGR puede llegar a conclusiones errneas
Tabla B1: Impactos posibles en el SGR.

Apndice B: Gestin de seguridad 241 Autor: Ing. Jos Luis del Ro
B 1.2 Riesgos prioritarios: Debido al contexto en el que se construye el software de esta tesis, los riesgos ms probables y de mayor impacto son: - Modificacin por virus. - Suministro de inadecuado de energa elctrica (cortes, sobre tensiones). Los temas virus y fiabilidad del hardware son tratados con una prioridad alta, debido a la alta exposicin a riesgo que tienen dentro del trabajo de tesis. B1.3 Control de riesgos Disponemos de cuatro tipos de medidas, que combinadas pueden reducir los riesgos y/o el impacto del ataque. - Legales. - Administrativas. - Fsicas. - Lgicas. Si nos centramos en el desarrollo de la tesis y en los riesgos los riesgos prioritarios establecidos durante esta etapa, se considerarn solamente las medidas fsicas y lgicas dejando de lado las administrativas y legales (estas debern ser tenidas en cuenta en las versiones operativas del SGR). B1.4 Medidas de seguridad adoptadas para el desarrollo del SGR - Fsicas: - Acceso restringido. - Copias de respaldo ubicadas en un lugar fisicamente alejado. - Condiciones de trabajo adecuadas (Temperatura, Humedad). - Lgicas: - Instalacin y actualizacin de antivirus. - Implementacin de medidas de seguridad durante el acceso a red (derechos, parametrizacin del sistema operativo). - Acceso controlado a bases de datos (mediante derechos fijados por el administrador del sistema y claves de acceso.
Apndice B: Gestin de seguridad 242 Autor: Ing. Jos Luis del Ro
APNDICE C INTERFASE DE GESTIN DE CONFIGURACIN
Apndice C: Gestin de configuracin
243
244
C) GESTION DE CONFIGURACION C 1 Planificacin de gestin d configuracin El mtodo de control de configuracin a utilizar es el de LINEA BASE, los objetivos de esta planificacin son: - Identificar los resultados durante la fase. - Asegurar que se ha completado la fase. A lo largo del ciclo de vida del SGR podemos establecer las siguientes lneas bases: - Lnea base funcional: Se establece al finalizar la especificacin de requisitos. - Lnea base de diseo: Se establece al finalizar la fase de diseo, comprende todos los documentos en los que se detalla el diseo del software y la planificacin. - Lnea base de producto: Se establece al finalizar la fase de pruebas, comprende el software y documentos generados durante la construccin y pruebas del producto. Para efectuar un control de configuracin efectivo se planifican las siguientes actividades: - Identificacin de la configuracin. - Control de cambios de configuracin. - Generacin de informes de estado. A continuacin se detallan la forma en que se implementan estas actividades. C1.1 Identificacin de la configuracin: La configuracin de los elementos que componen el software, se describe mediante los siguientes datos: - Lnea base a la que pertenece. - Identificacin de fase en la que se cre. -Tipo de elemento de configuracin (Programa, documento, elemento fsico). - Nombre o cdigo de elemento de configuracin del software.
Apndice C: Gestin de configuracin 245 Autor: Ing. Jos Luis del Ro
C1.2 Control de cambios de configuracin Comprende las siguientes tareas: - Iniciacin del cambio (Solicitud de cambio). - Clasificacin y registro del cambio. - Realizacin del cambio. - Validacin del cambio. C1.3 Generacin de informes de estado Los cambios se controlan mediante: - Registros de cambio. - Registro de incidentes. - Registro de instalaciones. A continuacin se detallan los datos contenidos en cada registro: Registros de cambio Constituido por: - Cdigo de solicitud de cambio. - Descripcin de la causa que motiva el cambio. - Descripcin breve de solucin del problema. - Impacto previsto. - Estimacin de coste. - Plan de implementacin. - Lnea base. - Elementos afectados. - Fecha de solicitud de cambio. - Fecha de implementacin de cambio. - Fecha de cierre de cambio. - Solicitante. - Autorizante. - Ejecutor.
246
Registro de incidentes - Descripcin de incidente. - Prioridad. - Cdigo de solicitud de cambio a la que dio lugar. Registro de instalaciones - Lugar. - Versin. - Fecha de instalacin - Cdigo de instalacin. C2 Herramientas de apoyo al control de configuracin El control de configuracin se instrument mediante una base de datos (construida en MS-Access). En dicha base se introdujeron las funciones y registros que hemos detallado en C1. A continuacin se muestran a titulo de ejemplo las pantallas bsicas del sistema de gestin de configuracin:
Figura C2.1 Men principal de sistema de gestin de cambios implementado en MS-Access

Figura C2.2 Formulario de solicitud de cambio.
Figura C2.3 Formulario de solicitud de cambio.

Figura C2.4 Formulario registro de incidentes.
Figura C2.5 Formulario registro de instalaciones.
249
Figura C2.6 Ejemplo de bsqueda de modificaciones en clase INTEGRADOR mediante los mecanismos de filtrado de MS-Access.
Figura C1.6 Diseo de tabla control de configuracin mediante MS-Access.

Apndice C: Gestin de configuracin Autor: Ing. Jos Luis del Ro
250
C 3 Implementacin del control de configuracin A lo largo del proyecto se fueron introduciendo los datos de la configuracin segn los criterios descriptos en las tablas C 3.1, C3.2 y C3.4
Tipo de elemento Seccin de Documento Clases Interfases de usuario Funciones de navegacin Identificacin Se identifican mediante la asignacin de secciones del ndice principal de la Tesis. Se identifican segn los nombres asignados en la tabla 5.4 Se identifican segn los nombres asignados en la tabla 6.2.4 de interfases. Se identifican segn los nombres asignados en la tabla 6.2.5 de funciones de navegacin. Ejemplo A1.4 Hitos de entrega
INTEGRADOR
TBQ_Integrador
ScrIntegrador
Procedimientos Algoritmos de clculo Casos de prueba
Se identifican segn los nombres asignados en la tabla 6.2.6 de procedimientos. P, E, RE INF X Se establece un nmero de instancia similar al caso de prueba. Se identifican segn los nombres asignados en la tabla E1 de inferencias
CopiarINTEGn_INTEGselec
INF X Para el caso de prueba 1 se establece la Instancias: Clase 1, Integrador 1, Hardware 1 Etc. INF 21
Inferencias
Tabla C3.1 Identificacin de elementos del SGR

Tipo de archivo Documentacin Planificacin del proyecto Cdigo Control de configuracin Herramienta de desarrollo Microsoft Word Borrador Tesis_V(k) Microsoft Project Kappa PC Microsoft Access Planificacin_V(l) SGR_(m) ContConfig_V(n) Denominacin Anteproyecto_V(i) Observaciones i : Nmero de versin K : Nmero de versin I : Nmero de versin m : Nmero de versin n : Nmero de versin
Tabla C3.2 Denominacin de archivos segn tipo y versin.
251
Perfil
Nombre P Britos E Diez
Solicitante de cambio
C Rancall R Garca Martnez Docente UPM J L del Ro
Autorizante de cambio Ejecutor del cambio Gestin de cambios J L del Ro
Tabla C3.3 Asignacin de perfiles del control de configuracin.

Estados de una solicitud de cambio Notificada Autorizada En desarrollo Terminada
Tabla C3.4 Asignacin de estados de una solicitud de cambio.
Direccin del documento o programa C:\ITBA\Tesis\Borrador TesisV86 C:\ITBA\PlanificacinV3 C:\ITBA\Tesis\SGR07
Observaciones
Hiper vinculo
Tabla C3.5 Asignacin de direcciones de almacenamiento de la documentacin.
La base de datos del control de configuracin permiti relacionar la direccin del documento mediante un hipervnculo, brind acceso rpido a los archivos en cuestin. Los mismos fueron gestionados mediante los derechos asignados por el administrador del sistema, de esta forma ningn documento o programa pudo ser borrado ni modificado en forma accidental o intencionada. En la tabla C3.6 se muestra un ejemplo que ilustra parte de resultado del control de configuracin. Los datos fueron exportados en formato Excel para facilitar su insercin en el documento de Tesis.
Tabla C3.6 Ejemplo de resultados del control de configuracin.
253
254
APNDICE D INTERFASE DE ASEGURAMIENTO DE LA CALIDAD
Apndice D: Gestin de calidad
255
256
D: INTERFASE ASEGURAMIENTO DE CALIDAD D 1: Introduccin El objetivo de esta interfase es planificar la forma de garantizar: - Metas y objetivos. - Mtodos. - Rendimiento. Se compone de dos actividades principales: - Planificacin de la calidad. - Supervisin y control de calidad. D 2: Planificacin general del control de calidad: El objetivo de este proceso es Identificar defectos en el producto para su correccin Para el desarrollo del sistema SGR, se decidi evaluar la calidad del software segn los atributos definidos por la norma ISO 9126-1998 [UPM, 2005]:
CALIDAD DEL SOFTWARE (ISO 9126-1998)
ATRIBUTO
FUNCIONALIDAD: Habilidad del software para realizar los trabajos deseados FIABILIDAD: Habilidad del software para mantenerse operativo (funcionando) USABILIDAD: Habilidad del software para satisfacer al usuario. EFICIENCIA: Habilidad del software para responder a una peticin del usuario con una velocidad adecuada MANTENIBILIDAD: Habilidad del software para poder realizar cambios en l rpidamente y con una adecuada relacin cambio / costo. PORTABILIDAD: Habilidad del software para correr en diferentes entornos operativos.
Tabla D1 Atributos que definen la calidad del software (ISO 9126-1998).
257
Se planificaron las siguientes actividades de Control: - Actividades estticas. - Pruebas dinmicas. D 2.1: Actividades estticas Se realizaran las siguientes pruebas estticas: - Revisiones. - Auditorias. Pruebas estticas Tipo Revisiones Auditorias
Objetivo Detectar defectos Monitorear proceso
Fases Iniciales Finales
Tabla D2.1 Pruebas estticas del SGR.
Las actividades estticas de CC buscan faltas sobre el sistema en reposo. Se aplican mediante una metodologa TOP-DOWN. D 2.1.1: Planificacin general de revisiones Para el SGR se previeron dos tipos de revisiones: - Revisiones tcnicas. - Revisiones de proyecto. Revisiones tcnicas: - Revisin de especificacin de requisitos. - Revisin del diseo. - Revisin de cdigo. - Revisin de las pruebas. Durante estas revisiones se buscaron los siguientes defectos: En los requisitos: Correccin, Complencin, Ambigedad y Claridad.
258
En el diseo: Cdigo, Complencin, Consistencia. Factibilidad y Trazabilidad. En el cdigo: Correccin. Para detectar estos defectos se aplicaron las siguientes tcnicas [UPM, 2005]:
Tcnica Lectura basada en defectos. Lectura basada en perspectiva. Lectura activa del diseo. Lectura de abstraccin sucesiva (ir desde el cdigo a la especificacin)
Aplicable a etapa de Requisitos. Diseo. Edicin de cdigo.
Tabla D2.1.1: Tcnicas aplicadas durante la revisin del SGR.
Revisiones de proyecto - Control de progresin. - Evaluacin de riesgos del proyecto. - Evaluacin general del producto. D 2.1.2: Planificacin de auditorias Las auditorias a realizar son tres - Auditorias de producto. - Auditorias de proyecto. - Auditorias de gestin de proyecto. D 2.2 Planificacin general de pruebas dinmicas Durante este tipo de pruebas se generan entradas al sistema con el objetivo de detectar fallos. Se aplican con filosofa BOTTOM- UP, adems se debe tener en cuenta que se ha seleccionado un diseo orientado a objetos para construir el SGR. A continuacin se describen las pruebas planificadas:
Apndice D: Gestin de calidad 259 Autor: Ing. Jos Luis del Ro
Pruebas dinmicas Pruebas unitaria Prueba de integracin Prueba del sistema

Tabla D2.2 Pruebas del SGR.
Observaciones Prueba de mdulos. A partir del esquema de diseo los mdulos se vuelven a probar combinados para comprobar sus interfases. Se comprueba el funcionamiento del software totalmente ensamblado.
Para los tres tipos de prueba se realizaran las siguientes actividades. - Planificacin de las pruebas. - Diseo de la prueba. - Determinacin de casos de prueba. - Planificacin de procedimiento de prueba. - Ejecucin de la prueba. - Anlisis y evaluacin. Durante las pruebas dinmicas se buscaron los siguientes tipos de defectos: - Correccin, Complencin, Consistencia y Trazabilidad. Teniendo en cuenta el diseo orientado a objetos del SGR, se aplic la combinacin de las siguientes tcnicas para la deteccin y correccin de defectos [UPM, 2005]: - Caja blanca: Pruebas de interfaz, de estructura de datos locales, de camino bsico y condiciones lmites. - Caja Negra.: Identificacin de clases de equivalencia y definicin de casos de pruebas. Anlisis de valores lmites. - Pruebas Unitarias para programacin OO: Prueba de clases (Se comprueba el comportamiento de la clase mediante tcnicas de caja blanca y caja negra). - Pruebas de integracin basada en hilos: Se integra el conjunto de clases necesarias para responder a una entrada o evento del sistema - Pruebas de integracin basada en el uso: Se prueban primero las clases independientes y luego las dependientes.
260
En la seccin A1.3 (Interfase de gestin, pgina 228) se detalla la insercin de las actividades de control de calidad dentro de la planificacin general del proyecto. En la figura D2.1 se muestra el flujo general para cualquier tipo de prueba (Unitaria, integracin, sistema, etc.).
Configuracin de software de la prueba especifica Resultados de la prueba
Prueba
Evaluacin Errores Tasa de error
Depuracin
Plan y procedimientos de prueba especfica
Modelo de fiabilidad Resultados esperados
Correccin
Prediccin de fiabilidad
Figura D2.1 Flujo general de pruebas.
D 3: Actividades constructivas de garanta de calidad del software Con el propsito de asegurar la calidad del proceso de construccin del software y del producto se han adoptado las siguientes metodologas, herramientas y normas: Metodologas: - Mtrica 3 [Ministerio de Administraciones Pblicas, 2000]. - Evaluacin de riesgos mediante exposicin a riesgos [Bohm, 1989]. - Control de configuracin mediante lnea base.
261
Herramientas: - Base de datos para control de configuracin (Microsoft Access). - Estimacin de esfuerzo mediante USC-COCOMO II. - Microsoft Project. Normas: - ISO 9126-1998 D 4: Implementacin del CC. Al final de las etapas asociadas a las pruebas, se detalla la implementacin de las mismas y los resultados obtenidos. Nombre de prueba
Revisin de requisitos Revisin del diseo Revisin de cdigo Pruebas unitarias Pruebas de integracin Pruebas de sistema
Implementacin
Seccin 4.5 Seccin 5.10 Seccin 6.3 Seccin 6.4 Seccin 6.5 Seccin 6.6
Resultados
Seccin 4.5 Seccin 5.10 Seccin 6.3 Seccin 6.4 Seccin 6.5 Seccin 6.6
Observaciones
Pruebas estticas
Pruebas dinmicas
Tabla D4.1 Ubicacin de pruebas de CC.
262
APNDICE E ASIGNACIN DE PESOS , ENTRADAS / SALIDAS DE INF X Y ASIGNACIN DE SOLUCIONES SEGN CONTEXTO.
Apndice E: W,K,INF X, Soluciones
263
264
E 1 Asignacin de pesos y entradas salidas de INF X Para estimar los factores de riesgo X (i,j) es necesario: - Transformar las respuestas del cuestionario TBQ-SAC en nmeros. - Conocer los valores de W (i,j).. y K (i). Con el objetivo de acortar los tiempos de desarrollo y prueba, se implementan estas tareas en un mdulo reutilizable denominado INF X. Para evaluar los 33 riesgos posibles en un proyecto de software para SAC, fue necesario determinar los datos de entrada y salida para cada uno de ellos, a continuacin se detallan los mismos en la tabla E1.
Inferencia Salida de INF_X
Entradas a IN X
Peso W W 1.1=0,20 W 1.2=0,20 W 1.3=0,60 W 2.1=0,30 W 2.2=0,30 W 2.3=0,30 W 2.4=0,20 W 2.5=0,20 W 3.1=0,60 W 3.2=0,40 W 4.1=1,00 W 5.1=0,30 W 5.2=0,70 W 6.1=0,30 W 6.2= 0,33 W 6.3=0,30 W 6.4=0.07 W 7.2=0,50
Cte hist. K
Prob P
Atributo Memo X R 1: Baja productividad del equipo de desarrollo AA R29:Prob X 1.1 INF 1 INTEG_Selec: Sueldos 1 X 1.2 INTEG_Selec: GP 1 X 1.3 R 2: Baja productividad del equipo automatizado AA R6:Prob X 2.1 AA R8:Prob X 2.2 INF 2 CL_Selec: Ing 1 X 2.3 CL_Selec: Conocimiento 1 X 2.4 INTEG_Selec: GP 1 X 2.5 R 3: Baja fiabilidad del equipo automatizado PI_Selec:Temp 1 X 3.1 INF 5 HW_Selec: Fiab 1 X 3.2 R 4: Contaminacin ambiental INF 4 PI_Selec:Tox 1 X 4.1 R 5: Estimacin de esfuerxo errnea AA R6: Prob X 5.1 INF 5 AA R8: Prob X 5.2 R 6: Especificaciones incompletas o errneas PI_Selec: Esp 1 X 6.1 CL_Selec: Conocimiento 1 X 6.2 INF 6 PI_Selec: Simil 1 X 6.3 PI_Selec: Complejidad 1 X 6.4 AA R8: Prob X .7.2
K 1 =0,15
R 1 :Prob
K 33= 0,60
R 2: Prob
K 3= 0,12 K 4= 0,10 K 3= 0,50
R3: Prob R4 :Prob R3: Prob
K 6 =0,10
R 6 :Prob
Tabla E1 Valores instanciados de entradas y salidas a inferencia reutilizable INF X para Ri
265
Inferencia
Entradas a IN X
Salida de INF_X
Peso
Cte hist.
Prob
Atributo Memo X W K R 7: Falta de aceptacin de aplicacin por parte de usuarios AA R6: Prob X 7.1 W 7.1=0,50 INF 7 K 3= 0,09 AA R8: Prob X .7.2 W 7.2=0,50 R 8: El integrador no tiene la experiencia necesaria para los requerimientos del PI PI_Selec: ReqCCom 1 M 8.1 INTEG_Selec: ExpPLC M 8.1 X 8.1 W 8.1=0,25 PI_Selec: ReqCSeq 1 M 8.2 INTEG_Selec: ExpPLC M 8.2 X 8.2 W 8.2=0,15 PI_Selec: ReqHMI 1 M 8.3 INTEG_Selec: ExpHMI M 8.3 X 8.3 W 8.3=0,15 PI_Selec: ReqSCADA 1 M 8.4 INF 8 K 8 =0,10 INTEG_Selec: ExpSCADA M 8.4 X 8.4 W 8.4=0,10 PI_Selec: ReqServo 1 M 8.5 INTEG_Selec: ExpServo M 8.5 X 8.5 W 8.5=0,10 PI_Selec: ReqAcc 1 M 8.6 INTEG_Selec: ExpAcc M 8.6 X 8.6 W 8.6=0,10 PI_Selec: ReqNet 1 M 8.7 INTEG_Selec: ExpNet M 8.7 X 8.7 W 8.7=0,15 R 9: No cumplir con estndares de calidad del cliente INF 9 CL_Selec:Ecalidad R6: Prob X 9.1 W 9.1=1,00 K 9= 0,10 R 10: Pago de intereses punitorios por mora o proceso cado CONT_Selec: IP 1 M 10.1 INF 10 INTEG_Selec: GP K 10= 0,12 M 10.1 X 10.1 W 10.1=0,65 CONT_Selec: IP R5:Prob X 10.2 W 10.2=0,35 R 11: Perder clientes AA R7: Prob X 11.1 W 11.1=0,40 INF 11 AA K 3= 0,17 R8: Prob X 11.2 W 11.2=0,30 AA R2: Prob X 11.3 W 11.3=0,30 R 13: Prdida de informacin de proceso INF 13 CL_Selec:Emant R3: Prob X 13.1 W 13.1=1,00 K 13= 0,20 R 14: Prdida de informacin del proyecto INTEG_Selec: GP 1 X 14.1 W 14.1=0,50 INF 14 K 14= 0,08 INTEG_Selec: ST 1 X 14.2 W 14.2=0,50 R 16: Prdida de reputacin en el mercado (Integrador) AA R11:Prob X 16.1 W 16.1=0,50 INF 16 INTEG_Selec: Efin K 16= 0,20 R6: Prob X 16.2 W 16.2=0,30 AA R18:Prob X 16.3 W 16.3=0,20 R 17: Prdida de reputacin en el mercado (Cliente) AA R2 :Prob X 17.1 W 17.1=0,50 INF 17 K 17= 0,02 AA R21:Prob X 17.2 W 17.2=0,50
P R3: Prob
R8 :Prob
R9 :Prob
R10:Prob
R3: Prob
R13 :Prob R14: Prob
R16: Prob
R17: Prob
266
R 18: Prdida de reputacin en el mercado (Proveedor de equipos SAC) HW_Selec: Fiab 1 X 18.1 W 18.1=0,25 HD_Selec: Amig 1 X 18.2 W 18.2=0,25 INF 18 K 25= 0,01 PROV_Selec: SPG 1 X 18.3 W 18.3=0,25 PROV_Selec: SPL 1 X 18.4 W 18.3=0,25 R 19: Prdida de personal clave difcil de reeplazar INTEG_Selec: Sueldos 1 X 19.1 W 19.1=0,50 INF 19 K 19= 0,02 INTEG_Selec: Efin 1 X 19.2 W 19.2=0,50 R 20: Prdidad de certificacin del proveedor de SAC INTEG_Selec: Certif 1 M 20.1 INF 20 INTEG_Selec: GP K 20= 0,12 M 20.1 X 20.1 W 20.1=0,65 X 20.2 W 20.2=0,35 INTEG_Selec: Efin M 20.1 R 21: Prdida humanas y/o accidentes PI_Selec: peligrosidad 1 M 21.1 INTEG_Selec: ExpSeg M 21.1 X 21.1 W 21.1=0,40 INF 21 K 21= 0,04 CL_Selec: ExpSeg M 21.1 X 21.2 W 21.2=0,40 PI_Selec: complejidad M 21.1 X 21.3 W 21.3=0,20 R 22: Prdidas / Daos de euipos de proceso AA R6: Prob X 22.1 W 22.1=0,33 INF 22 AA K 15= 0,05 R8: Prob X 22.2 W 22.1=0,34 HW_Selec: Fiab 1 X 22.2 W 22.1=0,33 R 23: Proyecto puede sufrir demoras causadas por tercero PI_Selec: complejidad 1 M 23.1 T_Selec: Efin M 23.1 X 23.1 W 23.1=0,40 INF 23 K 23= 0,04 T_Selec: Com M 23.1 X 23.2 W 23.2=0,10 T_Selec: CapTec M 23.1 X 23.3 W 23.3=0,50 R 24: Prolemas con otros proyectos en desarrollo AA R29:Prob X 24.1 W 23.1=0,40 INF 24 INTEG_Selec: GP K 23= 0,19 1 X 24.2 W 23.2=0,50 HD_Selec: Amig 1 X 24.3 W 23.3=0,10 R 25: Problemas de facturacin X INF 25 CL_Selec:Efin 1 .25.1 W 25.1=1,00 K 25= 0,30 R 26: Prolemas de mantenimiento (en garanta) AA R29:Prob X 26.1 W 26.1=0,25 HW_Selec: Fiab 1 X 26.2 W 26.2=0,25 INF 26 K 26= 0,03 PROV_Selec: SPG 1 X 26.3 W 26.3=0,25 PROV_Selec: SPL 1 X 26.4 W 26.3=0,25 R 27: Prolemas de mantenimiento (fuera de garanta) AA HW_Selec: Fiab CL_Selec: Emant PROV_Selec: SPL R29:Prob 1 1 1 X 26.1 X 26.2 X 26.3 X 26.4 W 26.1=0,10 W 26.2=0,40 W 26.3=0,40 W 26.3=0,10
R18: Prob
R19: Prob
R20:Prob
R21: Prob
R22: Prob
R23: Prob
R24: Prob
R25 :Prob
R26: Prob
INF 27
K 27= 0,09
R27: Prob
267
R 28: Problemas legales CONT_Selec: flexi 1 M 28.1 CL_Selec: flexi M 28.1 X 28.1 INF 28 CONT_Selec: flexi R33:Prob X 28.2 CONT_Selec: flexi R2:Prob X 28.3 R 29: Sobrecarga de trabajo INF 29 INTEG_Selec: ST X 24.2 X 29.1 R 30: Baja calidad del software de aplicacin INTEG_Selec: GP 1 X 30.1 INF 30 AA R8:Prob X 30.2 INTEG_Selec: Certif 1 X 30.3 R 33: Retraso en el cronograma de trabajo INTEG_Selec: GP 1 X 33.1 AA R8:Prob X 33.2 INF 33 AA R29:Prob X 33.3 AA R22:Prob X 33.4 AA R23:Prob X 33.5
W 28.1=0,40 W 28.2=0,30 W 28.3=0,30 W 29.1=1,00 W 30.1=0,35 W 30.2=0,35 W 30.3=0,30 W 30.1=0,60 W 30.2=0,10 W 30.3=0,10 W 30.4=0,10 W 30.5=0,10
K 28= 0,06
R28: Prob
K 29= 0,30
R29: Prob
K 15= 0,25
R30: Prob
K 33= 0,30
R33: Prob
E 2 Asignacin de soluciones en base al contexto El SGR analiza el valor de los factores de riesgo de los cinco riesgos prioritarios, si determina que es mayor o igual que 0,5 propone una solucin. Esto se puede expresar de la siguiente manera. Si PRIO (R (i)) 5 y si (X (i,j) x M(i,j)) 0,5 => Sugerir Solucin S(i,j)
En la tabla E2 se detalla el listado de soluciones.

Nombre
S 1.1 S 1.2 S 1.3 S 2.1 S 2.2
Solucin sugerida por SGR Texto

Utilizar herramientas de desarrollo ms eficientes, trabajar en equipo y/o contratar personal experimentado Mejorar nivel sueldos e incentivos Mejorar los mtodos de gestin del proyecto, evaluar y controlar en forma continua los resultados. Mejorar las especificaciones del proceso, las mismas son incompletas y/o errneas. Mejorar la capacitacin del personal afectado al proyecto o contratar personal experimentado.
Tabla E2 Ejemplo de asignacin de soluciones preestablecidas en funcin del contexto.
268
Nombre
S 2.3 S 2.4 S 2.5 S 3.1 S 3.2 S 4.1 S 5.1 S 5.2 S 6.1 S 6.2 S 6.3 S 6.4 S 7.1 S 7.2 S 8.1 S 8.2 S 8.3 S 8.4 S 8.5 S 8.6 S 8.7

Ayudar al cliente a establecer los requerimientos del proceso (por ejemplo mediante maquetas y/o prototipos). Adoptar mtodos de gestin de proyecto, evaluar y controlar resultados en forma continua. Mejorar los mtodos de gestin del proyecto, evaluar y controlar en forma continua los resultados. Refrigerar hardware o alejarlo del calor (reubicar tablero) Adquirir hardware de mayor fiabilidad. Reforzar las medidas y criterios de seguridad, capacitar y concientizar al personal, brindar equipos de seguridad. Mejorar especificaciones mediante entrevistas, estudio de procesos similares, maquetas y/o prototipos Capacitar al personal afectado al proyecto en tcnicas de estimacin de proyectos software Mejorar especificacin del proceso (utilizar entrevistas y si hace falta maquetas y/o prototipos). Apoyar y asesorar al cliente con personal experimentado en procesos similares. Buscar antecedentes de procesos similares. Optimizar la gestin del proceso, evaluar y controlar resultados en forma continua. Mejorar las especificaciones y recalcular esfuerzo del proyecto (por ejemplo; utilizar maquetas y /o prototipos) Capacitar al personal del proyecto o tomar personal experimentado. Tomar curso de tcnicas digitales y programacin de PLC o contratar personal con conocimientos del tema. Tomar curso de diseo de circuitos secunciales y PLC o contratar personal con conocimientos del tema. Tomar curso de HMI o contratar personal con conocimientos del tema. Tomar curso de SCADA o contratar personal con conocimientos del tema. Tomar curso de mecanismos y servo o contratar personal con conocimientos del tema. Tomar curso de motores y accionamientos o contratar personal con conocimientos del tema. . Tomar curso de redes industriales o contratar personal con conocimientos del tema. .
Tabla E2 (Continuacin) Ejemplo de asignacin de soluciones preestablecidas en funcin del contexto.
269
Nombre

Estudiar estndares de calidad del cliente, revisar las condiciones de operacin finalmente revisar proyecto. Renegociar contrato y mejorar la gestin del proyecto. Revisar especificaciones y establecer clusulas limitativas en caso de especificaciones incompletas y/o errneas. Evaluar la satisfaccin del cliente con el producto, proponer negociar e implementar mejoras. Capacitar al personal en base a los requerimientos del proyecto o contratar personal experimentado. Evaluar la productividad del proceso y buscar puntos de mejora. Buscar ms datos, mejorar mtodos de estimacin de esfuerzo. Capacitar al personal que cotiza o tomar personal experimentado. Disear sistema de alta fiabilidad, robusto. Prever asistencia tcnica al cliente. Mejorar gestin del proyecto, establecer mecanismos de respaldo de la documentacin del proyecto. Tomar ms personal, y/o mejorar herramientas de desarrollo de software. Mejorar gestin del proyecto Mejorar fiabilidad del hardware Capacitar al personal del proyecto. Mejorar la comunicacin con el cliente, analizar la calidad de los productos elaborados. Buscar mtodos que optimicen la educcin de especificaciones (entrevistas, maquetas y/o prototipos ) Buscar un proveedor de equipos SAC con mejores servicios postventa. Mejorar mtodos de educcin de especificaciones, mejorar la gestin del proyecto. Mejorar medidas y criterios de seguridad industrial, capacitar y concientizar al personal del proyecto. Fabricar hardware ms fiable y robusto.. Mejorar el software de desarrollo, aumentar su portabilidad, fiabilidad y amigabilidad.
270
Nombre
S 18.3 S 18.4 S 19.1 S 19.2 S 20.1 S 20.2 S 21.1 S 21.2 S 21.3 S 22.1 S 22.2 S 22.2 S 23.1 S 23.2 S 23.3 S 24.1 S 24.2 S 24.3 S .25.1 S 26.1 S 26.2

Mejorar servicios de postventa (servicios de capacitacin, tiempo de respuesta, stock) Mejorar los servicios brindados por la sucursal local (mejorar tiempos de respuesta, asistencia tcnica y/o stocks), Mejorar sueldos e incentivos de personal clave del proyecto, mejorar la motivacin de los diseadores. Tomar medidas para que el estado econmico- financiero de la empresa no afecte al personal clave del proyecto. Mejorar los mtodos de gestin de proyectos, evaluar y controlar resultados en forma continua. Mejorar estado financiero del integrador, sanear cuentas, optimizar costos y mejorar mtodos de cotizaciones. Capacitar al integrador en "Seguridad industrial" Tomar recaudos ante la falta de experiencia del Cliente en Seguridad industrial Dado que el proceso es complejo y peligroso asegurar una adecuada gestin del proyecto y puesta en marcha. Mejorar mtodos de educcin de especificaciones (por ejemplo: entrevistas, maquetas y/o prototipos). Capacitar al personal del proyecto y/o tomar personal experimentado. Utilizar hardware de mayor fiabilidad. Limitar prdidas mediante clusulas del contrato, documentar con el cliente las demoras ajenas al personal del proyecto. Mejorar la comunicacin con terceros, coordinar esfuerzos y cronogramas. Trabajar en equipo. Asesorar al tercero, delimitar responsabilidades en el contrato mediante clusulas limitativas. Tomar ms personal y/o utilizar mtodos / herramientas de desarrollo de software ms efectivas. Mejorar los mtodos del proyecto, evaluar y controlar resultados en forma continua. Utilizar herramientas de desarrollo ms fiables y amigables. Prever medidas y clusulas contractuales que eviten prdidas econmicas. Contratar ms personal, y/o optimizar servicios de gestin de asistencia tcnica Instalar hardware ms fiable y/o mejorar el entorno de trabajo del hardware ( reducir temperatura, suciedad)
271
Nombre

Buscar proveedor con buen servicio de asistencia tcnica y comercial. Buscar sucursal / proveedor local con buen servicio de asistencia tcnico-comercial. Contratar ms personal, y/o optimizar servicios de gestin de asistencia tcnica Instalar hardware ms fiable y/o mejorar el entorno de trabajo del hardware ( reducir temperatura, suciedad) Dado que el cliente no realiza buen mantenimiento, prever costos y personal de asistencia tcnica. Buscar sucursal / proveedor local con buen servicio de asistencia tcnico-comercial. El contrato es poco flexible asesorar adecuadamente al equipo de proyecto, optimizar gestin del proyecto. El cliente es poco flexible, designar en caso de conflicto asignar un negociador experimentado. Utilizar herramientas de desarrollo ms eficientes, trabajar en equipo y/o contratar personal experimentado. Mejorar metodologa de gestin de proyecto, evaluar y controlar resultados en forma continua. Capacitar al equipo de proyecto y/o contratar personal experimentado. Convertirse en integrador CERTIFICADO, obliga a adoptar metodologas de desarrollo ms de mayor eficacia. Reserva Reserva Reserva Reserva Reserva Dada la sobrecarga de trabajo el integrador debe ampliar su plantel. Mejorar la gestin del proyecto para evitar prdidas econmicas. Dado que el proyecto puede sufrir demoras por terceros, establecer medidas contractuales y de gestin que limiten el riesgo. Mejorar comunicacin con tercero y reforzar la gestin del proyecto
Tabla E2 (Continuacin) Ejemplo de asignacin de soluciones preestablecidas en funcin del contexto
272
APNDICE F ENTREVISTAS
Apndice F: Entrevistas
274
F1 Detalle de sesin 1 Objetivos: - Conocer cual es la necesidad de la empresa y los motivos que la provocan. - Determinar los alcances del Sistema. - Detectar posibles candidatos especializados en la gestin de riesgos en SAC para poder avanzar en el entendimiento del proceso y en el estudio de viabilidad. Entrevistado: Gerente de producto de SAC de empresa lder Tcnica: Entrevista abierta Fecha: 5/1/05 Duracin estimada: 3 hs Preparacin de preguntas 1) Existe realmente un problema serio de riesgos en el desarrollo de software para SAC? 2) Existe algn especialista en SAC que conozca los riesgos del negocio y como administrarlos? Desarrollo de la entrevista IS: Existe realmente un problema serio de riesgos en el desarrollo de software para SAC? Gerente: Definitivamente la respuesta es si, los costos y tiempos de desarrollo de software de aplicacin ocasionan a nuestros integradores (desarrolladores de software), a nuestra empresa y a nuestros clientes prdidas de todo tipo. Dentro de las empresas que desarrollan software con nuestras herramientas de programacin, existen pocas personas que sepan como anticipar y gestionar los riesgos. Lugar: Administracin Central Sala A Duracin real: 3 hs
275
Generalmente son profesionales del rea de SAC que tienen ms de 15 aos en el tema, con mucha capacitacin terica y mucha prctica, desarrollada en varios tipos de industria y con distintos perfiles de clientes. La mayora de nuestros integradores sabe como desarrollar la solucin en base a slidos conocimientos del producto, pero no aplican ninguna metodologa para gestionar riesgos. Sera conveniente asistir a los integradores que no cuentan con esta experiencia, mediante un sistema de gestin automtica de riesgos especializado en SAC. Durante el desarrollo de la entrevista al IS le surge la siguiente duda: IS: Qu se entiende por integrador? Gerente: Un Integrador es una empresa con una estructura tcnico administrativa orientada a comercializar y desarrollar soluciones implementadas mediante SAC para la industria. Una solucin est conformada por la provisin de: - Hardware. - Software de aplicacin. Algunos integradores suman otras actividades, por ejemplo: la fabricacin de los tableros elctricos en los que se montar el SAC, la instalacin y el conexionado de sensores / actuadores de proceso. En los inicios de esta actividad los programas de aplicacin de SAC eran desarrollados por las propias empresas que fabricaban los equipos y herramientas de programacin. A medida que el negocio fue creciendo, fue necesario tener ms personas desarrollando software. Se estudiaron dos alternativas de crecimiento: 1) Incorporar ms personal. 2) Desarrollar Integradores que conocieran el producto. La primera alternativa se dej de lado, puesto que las empresas lderes contaban con una dotacin muy grande con costos de desarrollo poco competitivos.
276
La segunda alternativa presentaba costos mucho ms competitivos. Los integradores tenan estructuras ms pequeas y giles, razn por la cul podan obtener mejores costos operativos de desarrollo. La desventaja radicaba en que el proveedor dell SAC no poda garantizar la calidad de este servicio, por ello se recurri a certificacin del integrador. Para calificar como Integrador certificado la empresa debe reunir tanto requisitos tcnicos como econmicos / financiero: 1) Tcnicos: Conocimientos del producto y del tipo de industria en el que se desarrolla la aplicacin 2) Econmicos / financiero: Un integrador con pocos aos de trayectoria o con una situacin financiera crtica puede desaparecer del mercado, dejando al usuario de la aplicacin y al proveedor en un serio problema. Con estos dos requisitos, el proveedor de equipos de SAC puede garantizar al usuario final que el integrador (certificado) podr desarrollar, mantener y mejorar las aplicaciones desarrolladas para su planta. Pero tanto en el mejor caso (personal propio / integradores certificados) o en el peor caso (integradores no certificados con poca experiencia), se presentan desvos importantes debido a la falta de procesos adecuados de gestin de riesgos. El IS compara la Situacin de los SAC con el la situacin de gestin de riesgo de cualquier otro desarrollo de software y plantea la pregunta: IS: No es posible incorporar un especialista en gestin de riesgos en desarrollo de software de IT al integrador de SAC? Gerente: Actualmente la respuesta es NO, en principio no reunira los conocimientos necesarios de SAC y tomara mucho tiempo formarlo para que conozca el negocio. Por otro lado debemos tener en cuenta que los integradores poseen estructuras pequeas, si su tamao fuese mayor se incrementaran los costos de sus servicios y por lo tanto seran poco competitivos.
277
Por ello pensamos que es importante que el Integrador sea asistido por un Sistema que lo gue y le muestre los riesgos del proyecto que desarrollar o que est desarrollando. IS: Existe algn especialista en SAC que conozca los riesgos del negocio y como administrarlos? Gerente: Si, existe una persona con ese perfil, lo puedo contactar, es un profesional muy bien predispuesto que le brindar la informacin necesaria, ha trabajado en clientes finales, en el rea de proyecto y mantenimiento de SAC, luego desarroll tareas de comercializacin y proyecto en empresas de integracin y actualmente se desempea en nuestra empresa como responsable de proyectos. Anlisis de sesin El IS revisa los resultados y se pregunta a si mismo: IS: Se han conseguido los objetivos? IS: S, el Gerente de producto brind una buena introduccin al proceso de GR en SAC, y abri el camino para profundizar el tema con un especialista reconocido. IS: Se podra mejorar algo en la entrevista? IS: Sera conveniente respetar los descansos de 15 minutos previstos en cada sesin. IS: Cul es el prximo paso? IS: Entrevistar al especialista de manera de profundizar en el conocimiento del anlisis de riesgo en SAC y obtener informacin escrita
278
F2 Detalle de sesin 2 Objetivo: Conocer los riesgos que se presentan durante el Ciclo de vida de un SAC y recopilar informacin escrita para profundizar sobre el tema. Entrevistado: Especialista en gestin de riesgos en SAC Tcnica: Entrevista estructurada Fecha: 7/1/05 Duracin estimada: 2 hs Preparacin de preguntas El IS planifica las siguientes preguntas 1) Existe realmente un problema serio de riesgos en el desarrollo de software para SAC? 2) El problema varia con el proveedor de SAC? 3) Tiene alguna informacin escrita sobre el impacto y tipo de riesgo no previstos? Las preguntas restantes se van generando sobre la marcha en base a la informacin brindada por el especialista. Desarrollo de la entrevista IS: Existe realmente un problema serio de riesgos en el desarrollo de software para SAC? Especialista: Slo los especialistas muy experimentados saben como manejar la situacin, por otro lado ellos no aplican ningn mtodo que pueda ser transferido fcilmente a profesionales con menor experiencia. Como ejemplo, le describir algunos de los muchos casos tpicos de riesgos no previstos: Lugar: Oficina del especialista Duracin real: 3 hs
279
En el caso de los retrofitting (reciclado) de mquinas, el responsable del desarrollo de un automatismo, se encuentra normalmente con un cliente que no sabe como funciona realmente el proceso que se debe migrar. Otras veces determinados tipos de industria como la alimenticia desarrollan un proceso a pequea escala y lo operan manualmente, evalan si el gusto y nutrientes de producto son satisfactorios para el mercado, pero a la hora de fabricarlo en gran escala el mismo presenta dificultades que en las pruebas a pequea escala no aparecan.
Como vemos en estos dos ejemplos, la falta de conocimiento del proceso a controlar puede incrementar los costos respecto del presupuesto original, generando prdidas econmicas para el integrador y el usuario final (cliente). En otros casos se conoce el proceso, pero existen condiciones inseguras no previstas. Por ejemplo: al activar una parada de emergencia en algunas situaciones es ms seguro dejar presurizados los movimientos neumticos y/o hidrulicos de un sistema (por ejemplo en prensas), en otro tipo de mquinas resulta ms seguro despresurizar el sistema. Si esto no se tiene en cuenta de antemano, se pueden producir accidentes fatales o graves que atentan contra la seguridad de los operadores de la mquina. IS: El problema varia con el proveedor de SAC? Especialista: No, actualmente todos los proveedores de equipos de automatizacin y control padecen el problema. Durante los ltimos 20 aos, el mercado mundial de SAC es liderado por cinco empresas que abarcan aproximadamente el 70 % de las instalaciones de referencia, generalmente el 30 % restante sigue las tendencias que de hecho imponen las empresas lderes. Los proveedores de equipos para SAC brindan distinto tipo de asistencia en cada pas. En algunos pases unos tienen sus propias oficinas de representacin y otros no las tienen o se manejan con representantes inadecuados. En algunos casos podemos elegir la marca ms conveniente para el destino del proceso a automatizar y en otras no (dado que el usuario final fija la marca).
280
A pesar de estas diferencias los riesgos comunes (especificaciones errneas / incompletas, mala coordinacin con otras actividades / contratistas etc.) no dependen de la marca del equipo, sino que dependen de la gestin de riesgos del proyecto (en la mayora de los casos inexistente). Considero conveniente que el Sistema contemple la posibilidad de evaluar riesgos en el desarrollo de SAC en general y no para una marca en particular. IS Tiene alguna informacin escrita sobre el impacto y tipo de riesgo no previsto? Especialista: Si, para evaluar el impacto contamos en cada proyecto con la siguiente informacin: - Pedido de cotizacin / licitacin del cliente (usuario). - Oferta emitida por nuestra empresa de integracin. - Planificacin del proyecto (diagramas de Gantt, equipos de proyecto, etc.). - E-mails y notas con informes de la evolucin del proyecto. - Libros de obra. - Informes de puesta en marcha del proceso. - Encuestas de satisfaccin del Cliente. - Evaluacin de resultados tcnico econmicos del proyecto. - Reportes de mantenimiento brindados por nuestros clientes. Le aclaro que esta informacin no es habitual, la mayora de los integradores no llevan un historial ordenado de la evolucin de la aplicacin. Al IS le surgen preguntas fuera de la planificacin. IS: Tiene alguna formacin formal en la gestin de riesgos de SAC? Especialista: No, soy ingeniero electrnico con cursos de postgrado en automatizacin y control, tuve que adquirir conocimientos del rea Sistema (sistemas operativos, redes, lenguajes de programacin como C y VB). Durante esta formacin no recib ninguna capacitacin terica en gestin de riesgo ya sea en software de IT o de SAC, deb aprender a estimar este tipo de riesgos en base a mi experiencia personal. IS: Los especialistas en SAC tienen una formacin similar a la suya?
281
Especialista: NO, existen ingenieros / tcnicos provenientes de otras disciplinas: - Ingeniera Elctrica (muchos). - Ingeniera Electrnica (muchos). - Ingeniera Mecnica (pocos). - Ingeniera en Automatizacin y Control (pocos pues la carrera es nueva). - Ingenieros en Sistemas (pocos). En la mayora de los casos no cuentan con una formacin o experiencia prctica en gestin de riesgos de proyectos de software. IS: Conoce la existencia de metodologas y herramientas de gestin de Software de IT? Especialista: SI, teniendo en cuenta las diferencias y caractersticas del negocio de integracin de SAC, varias metodologas desarrolladas para otras reas de construccin de software, podran ser aplicadas. Resumen y comentarios del Especialista Es necesario asesorar a nuestros integradores, pero lamentablemente eso no es factible debido a que no podemos incrementar nuestra estructura y por otro lado los tiempos de capacitacin de personal que maneje con solvencia la GR en SAC son muy largos. Por estas razones, es necesario contar con un sistema de gestin automatizada de riesgos, que asista a nuestros integradores. Anlisis de sesin IS: El especialista logr sintetizar la problemtica de la GR, adems se ha brindado informacin escrita, que permite al IS interiorizarse ms en el tema. IS: Se podra mejorar algo en la entrevista? IS: El especialista fue interrumpido varias veces por otros temas, sera conveniente entrevistarlo en un sitio ms tranquilo, alejado de su lugar habitual de trabajo.
282
F3 Detalle de sesin 3 Objetivo: Evaluar si la construccin de un sistema de gestin de riesgos para sistemas de automatizacin y control es viable. Entrevistado: Especialista en gestin de riesgos en SAC Tcnica: Entrevista estructurada Fecha: 10/01/2005 Duracin estimada: 3 hs Preparacin de preguntas Es posible clasificar en distintos niveles la experiencia en gestin de riesgos de los responsables del desarrollo de software de SAC? Podra usted determinar cuantas personas estn en cada nivel? Desarrollo de la entrevista IS: Es posible clasificar en distintos niveles la experiencia en gestin de riesgos de los responsables del desarrollo de software de SAC? Especialista: S, bsicamente se detectan tres niveles (alto, medio y bajo), en funcin de la envergadura, complejidad, grado de automatizacin, y tecnologas aplicadas al proyecto. El aprendizaje comienza en el nivel ms bajo hasta alcanzar el ms alto, la experiencia prctica en gestin de riesgo coincide con estos niveles. A continuacin le describo el criterio que empleo para ubicar un integrador en cada nivel: Alto: Tienen buenos conocimientos terico prcticos de gestin de riesgo en Sistemas Software, adems cuentan con experiencia en el desarrollo de proyectos del siguiente tipo: - Sistemas de ms de 1000 entradas / salidas. - Sistemas que utilizan IA (redes neuronales, fuzzy Logic).
Apndice F: Entrevistas 283 Autor: Ing. Jos Luis del Ro
Lugar: Administracin Central Sala B Duracin real: 3 hs
- Sistema de telecomando. - Sistema de control multivariable. - Robtica. - Redes WAN - Conectividad con sistemas corporativos. - Conocimientos avanzados de IT. - Procesos industriales conocidos > 100. Medio: Poseen conocimientos prcticos bsicos de gestin de riesgo en proyectos de ingeniera, cuentan adems con experiencia en el desarrollo de proyectos del siguiente tipo: - Sistemas de ms de 200 entradas /salidas y menos de 1000. - Sistema que utilizan redes locales. - Sistemas de control numrico CNC. - Sistemas de posicionamiento (servos). - Sistemas de control con lazos simples. - HMIs grficas (Human Machine Interface). - Conocimientos bsicos de IT. - Procesos industriales conocidos > 20. Bajo: No cuentan con conocimientos de Gestin de riesgo pero tienen los siguientes conocimientos de automatizacin: - Microsistemas (menos de 200 entradas salidas). - Variadores de velocidad programables. - HMIs de texto. IS: Podra usted determinar cuantas personas estn en cada nivel? Especialista: Le puedo dar una idea general del mbito en el que me toc realizar mis actividades, no tome estos nmeros como una estadstica precisa y formal. Alto : 3 Medio: 100 Bajo : 1000 IS: En que basa estas estimaciones?
284
Especialista: Mis estimaciones se basan en los resultados de: - Evaluaciones de cursos de automatizacin y control. - Evaluaciones anuales de integradores (certificacin). Anlisis de sesin IS: Se han conseguido los objetivos? IS: S, dada la amplia experiencia del especialista se obtuvieron datos sobre la distribucin del conocimiento de GR en SAC. IS: Es necesario volver sobre el mismo? IS: No. IS: Quedo alguna duda pendiente? IS: En entrevistas anteriores tanto el Gerente del producto como el especialista hicieron referencia a integradores certificados, el tema no fue desarrollado con la suficiente profundidad, en la prxima entrevista se debe ampliar el tema.
285
F4 Detalle de sesin 4 Objetivo: Conocer las caractersticas y sistemas de clasificacin de los integradores. Entrevistado: Especialista en gestin de riesgos en SAC Tcnica: Entrevista abierta. Fecha: 15/1/005 Duracin estimada: 3 hs Preparacin de preguntas Cmo se clasifican los integradores? F4.1 Desarrollo de la entrevista IS: Cmo se clasifican los integradores? Especialista: Para las empresas proveedoras de equipos SAC y para los usuarios finales existen bsicamente tres tipos de integradores. 1) Integrador certificado de una marca de equipos SAC 2) Integrador no certificado 3) Proyectistas propios de la empresa proveedora de equipos SAC 1) Integrador certificado de un Equipo de SAC Es una empresa con capacidad tcnico administrativa para desarrollar software que comercializa y construye soluciones de Automatizacin y Control. Hoy en da en la mayora de los casos las mismas se basan en: PLC, HMI, SCADA, CNC, LAN, WAN, Robots y Sistemas de visin inteligentes Los integradores se encargan de comercializar hardware, software de edicin y software de aplicacin para los elementos descriptos. Lugar: Administracin Central Sala A Duracin real: 3 hs
286
El tamao, organizacin y especializacin de estas empresas suele ser muy diferente. Cuando cuenta con experiencia en procesos similares a los que maneja el cliente, corre con ventaja frente a otros integradores que no las tiene. 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. La empresa proveedora de equipos SAC comprueba los conocimientos de los integradores que quieren certificar su servicio, mediante exmenes tcnicos, adems audita peridicamente los ndices econmicos y financieros de la empresa de modo de garantizar la continuidad del servicio al cliente final. A cambio de esto, la empresa proveedora de equipos brinda apoyo y capacitacin preferencial al Integrador certificado, adems facilita el acceso a los clientes finales. Dada la gran cantidad de aplicaciones que desarrolla un integrador, el volumen de compra de este ltimo suele ser superior al de una gran industria. Esta situacin los convierte en uno de los principales clientes de las empresas proveedoras de equipos de SAC. 2) Integrador NO certificado de un Equipo de SAC Trabajan con varias marcas de SAC, esto abre el espectro de clientes, en la mayora de los casos cuentan con conocimientos ms amplios pero menos profundos de las marcas que trabajan. La gran diferencia para el cliente final, es que la empresa proveedora de una marca de equipos SAC no puede certificar la calidad y respaldo del software que construye un integrador no certificado. Si el cliente final conoce al Integrador y est satisfecho con su desempeo, el hecho de estar o no certificado no marca una diferencia en la evaluacin del riesgo. En muchos casos, la calidad de su trabajo queda garantizada por la trayectoria que han tenido en el mercado, de esta manera la confianza reemplaza la certificacin otorgada por el proveedor de equipos SAC.
287
3) Proyectista de aplicaciones de SAC propios de la empresa que fabrica el Equipo En el pasado las empresas proveedoras de equipamiento y software de desarrollo de SAC construan el 100 % del software de aplicacin, hoy en da esta participacin es muy inferior, al desarrollar y asociar a los Integradores de SAC los menores costos les ha permitido posicionarse mejor ante sus competidores. Para respaldar y asesorar a los integradores y a los clientes finales, las empresas proveedoras de equipamiento SAC deben contar con proyectistas con slidos conocimientos de desarrollo de aplicaciones, debido a ello los mismos participan habitualmente en la construccin de sistemas de gran complejidad y envergadura. Anlisis de sesin IS: Se han conseguido los objetivos? IS: S, el especialista ha diferenciado claramente los distintos tipos de desarrolladores de software SAC. Esto permiti al IS conocer en ms profundidad las caractersticas de los integradores. IS: Es necesario volver sobre el mismo? IS: No, el tema fue aclarado satisfactoriamente.
288
F5 Detalle Sesin 5 Objetivo: Descripcin general de la Gestin de Riesgos en SAC, buscar perspectivas. Entrevistado: Especialista en Sistemas de Automatizacin y control de una de las Empresas proveedoras de equipos de SAC. Tcnica: Entrevista Abierta Fecha: 25/02/05 Duracin estimada: 3 hs. Lugar: Administracin Central Sala B Duracin real: 5 hs.
Observaciones: SAC: Sistemas de Automatizacin y Control de Procesos Industriales GR: Gestin de riesgos Preparacin de preguntas Cules son los objetivos de la Gestin de Riesgos en SAC? Podra resumir en que consiste la GR? Cules son las actividades principales de GR? Quienes son los encargados del realizar la GR? Todos los integradores aplican GR? Existe alguna descripcin formal del procedimiento de GR en SAC? Podra describirme un caso representativo de GR? Podramos enumerar las perspectivas principales de la GR? Explicar objetivos al especialista. Se hace hincapi en los dos objetivos principales de esta entrevista: - Obtener una visin general del proceso SGR. - Definir las diferentes perspectivas del proceso. El IS solicit la aprobacin del especialista para grabar la entrevista y luego transcribirla.
289
Educcin A continuacin se transcribe la entrevista con el especialista: IS: Cules son los objetivos de la gestin de riesgo en SAC? Especialista: Segn los mencionado en las entrevistas anteriores, los equipos de proyecto de SAC estn conformados por profesionales con una formacin acadmica muy diversificada. En la mayora de los casos dicha formacin no incluye instruccin sobre gestin de riesgos. Debido a esto es habitual notar la existencia de riesgos previsibles, no detectados por el equipo de desarrollo de software. La ocurrencia de los mismos se manifiesta como: - Accidentes. - Procesos poco fiables - Un cliente / usuario insatisfecho con la aplicacin desarrollada. - Prdidas econmicas para el cliente debidas a: - Procesos detenidos - Incumplimiento de compromisos en la entrega del producto a fabricar. - Pago de adicionales no previstos en el presupuesto del proyecto. - Prdidas econmicas para el integrador debido a trabajos no contemplados en la oferta original. - Prdida de licitaciones por sobre-valoracin de proyectos. - Prdida de Imagen de mercado del Integrador. - Prdida de imagen de mercado de la empresa proveedora de equipo de SAC. Podemos afirmar que cuando un riesgo no previsto se hace realidad, en el corto plazo uno de los participantes (proveedor, cliente o integrador) se ve perjudicado pero al largo plazo TODOS pierden. Hoy en da, la mayora los integradores tratan de gestionar la crisis, en lugar de anticiparse a la misma mediante una adecuada gestin de riesgos.
290
IS:
Podra resumir en que consiste la GR en SAC?
Especialista: Primero: Detectar los riesgos potenciales que se pueden presentar durante la gestin de un proyecto de SAC. Segundo: Una vez determinados los riesgos: - Estimar la probabilidad de ocurrencia que tiene el mismo. - El Impacto que ocasionara su ocurrencia. Tercero: Dado que los recursos necesarios para eliminar o mitigar los riesgos son limitados, es conveniente establecer los riesgos que requieren atencin prioritaria. Cuarto: Recopilar y aprovechar datos histricos, en muchos casos la similitud de un proyecto nuevo con uno anterior permite anticipar tendencias, y soluciones. IS: Cules son las actividades principales de la GR en SAC? Especialista: Parte de la respuesta a esta pregunta se la contest en la pregunta anterior, pero podemos resumirla en las siguientes actividades: - Ubicarse en la situacin de contexto del riesgo en SAC. - Identificar el riesgo. - Cuantificar el riesgo. - Evaluar el Impacto de cada riesgo en SAC. - Priorizar riesgos segn su impacto. - Planificar de la gestin de riesgos en un proyecto de SAC. - Monitoreo y control del riesgo a lo largo del proyecto del SAC. IS: Quienes son los encargados de realizar la GR? Especialista: Como le mencion anteriormente, la mayora de los integradores no realiza esta actividad de manera formal, por lo tanto no hay responsables del tema.
291
Nuestra empresa como proveedora de Equipos de SAC tiene como objetivo principal mantener y acrecentar el Liderazgo en el mercado, esto no se logra con un cliente insatisfecho. Si nuestros integradores no consiguen gestionar los riesgos, tendremos un cliente insatisfecho con nuestra marca. Dado que el usuario final no especializado en SAC no tiene los conocimientos necesarios para distinguir si los problemas estn en el hardware, en el software de desarrollo o en el software de aplicacin, finalmente asocia el problema a la marca. Es importante destacar que si analizamos la posibilidad de incorporar un especialista en GR en las empresas de integracin, la misma resulta poco viable debido a su estructura y costos. IS: Tena pensado preguntarle si todos los integradores realizan GR, pero ya me contest la pregunta. Especialista: Como le dije la mayora no la realiza o no aplica una metodologa de GR. IS:Existe alguna descripcin formal de proceso de GR en SAC? Especialista: No conozco metodologas o normas de GR para el rea de automatizacin y control, pero como le coment en otras charlas existen modelos y metodologas de construccin de Software de IT que abordan el tema desde un punto de vista general. Actualmente no cubren los requerimientos de la actividad, debido a que es necesario sumar a las mismas una especializacin en el tema. He adaptado y complementado algunos criterios obteniendo buenos resultados. Entre las mismas podemos citar el modelo de Bohm, y los procesos sugeridos por el SEI. Cabe aclarar que a pesar de su potencial en el rea SAC, la mayora de los integradores no las conocen y por lo tanto no han intentado aplicarlas. IS: Podra describirme un caso representativo de GR?
292
Especialista: S, cuatro aos atrs, uno de nuestros integradores gan la licitacin de un proyecto de automatizacin de un proceso de molienda de cemento en el exterior. El integrador contaba con un equipo de trabajo con buena experiencia en automatizacin pero sin experiencia en GR. Al no anticiparse a las situaciones de riesgo que finalmente ocurrieron, el proyecto insumi el doble horas previstas. Este desvo se produjo principalmente como consecuencia de: Cambio de programadores a mitad del proyecto (se los envo a otra puesta en marcha). Descripciones errneas o incompletas del proceso a automatizar. Una mala seleccin del PLC, se utilizaron modelos de CPUs con baja capacidad de memoria y tiempos de procesamiento largos. Fue necesario trabajar ms de lo previsto en el programa para salvar estos problemas. Pruebas incompletas de instalacin de campo (sensores, actuadores, cableados). Las revisiones en cuestin se contrataron a terceros, a la hora de detectar problemas en los enclavamientos de un proceso era bastante difcil estimar si el problema era el hardware, la instalacin o el software de aplicacin. Los contratistas mecnicos provocaron demoras y problemas de diseo que impactaron en el cronograma de puesta en marcha.
El ao pasado la empresa cementera volvi a licitar el desarrollo de la automatizacin de un segundo proceso de Molienda (de mayor envergadura que el primero) esta vez encaramos el problema de modo diferente. Otro de nuestros integradores se present a la nueva licitacin, nos pareci oportuno realizar una prueba piloto asesorndolo en la GR. Contemplamos en la oferta dos alternativas de trabajo: cada una con un costo diferente, de manera que el cliente final pudiera tener una idea clara del modo en que se gestionara el proyecto en cada propuesta. En la primer alternativa el montaje era realizado por un tercero contratado por la cementera, nuestro presupuesto contemplaba 800 horas hombre de puesta en marcha y una responsabilidad limitada.
293
En la segunda alternativa el montaje era realizado por el integrador, el presupuesto contemplaba 400 horas de puesta en marcha y la responsabilidad de la entrega de un proceso llave en mano. En ambas alternativas se contempl las perturbaciones que podran introducir la obra civil y mecnica, limitando los riesgos mediante clusulas limitativas y adicionales. Adems se tuvo en cuenta en el la oferta la construccin de un prototipo de manera de determinar en forma precisa los requisitos del sistema. Luego de ganar la licitacin, comenzamos a asesorarlo sobre los riesgos que tena en su organizacin, por un lado manejaba muchos proyectos simultneos rotando al personal en forma innecesaria de uno a otro desarrollo, paralelamente el equipo de proyecto soportaba una carga de trabajo inadecuada. Durante el proyecto se mejor la comunicacin con los contratistas de obra civil y mecnico y el cronograma se cumpli sin mayores inconvenientes. Debido a nuestra experiencia en GR pudimos asesorar a este integrador para que el negocio tuviera xito (tanto en la etapa de oferta como en la etapa de construccin del sistema). Pero como le he comentado no contamos con el tiempo suficiente para asesorar personalmente a cada uno de nuestros integradores. IS: Podramos enumerar las perspectivas principales de la GR? Especialista: A mi criterio son: 1) Recopilacin de datos e identificacin de riesgos, mediante: - Bsqueda completa de antecedentes del cliente / usuario. - Bsqueda completa de datos relevantes de la estructura organizativa del integrador.
294
- Bsqueda de antecedentes sobre la experiencia del equipo de trabajo asignado al proyecto. - Datos sobre situacin de proyectos actuales y futuros desarrollados por el integrador. - Datos de terceros que puedan interactuar con el proyecto (Contratistas de instalaciones elctricas, mecnicas y obra civil). 2) Impacto del riesgo - Evaluar como impacta en el proyecto y en la organizacin del integrador. - Evaluacin de daos personales y materiales (por ejemplo en el caso de falla de automatismo de una caldera). 3) Priorizacin de riesgos - Dado que los recursos para controlar riesgos no son ilimitados es conveniente priorizar los mismos en funcin del impacto y la probabilidad de ocurrencia. 4) Control el Riesgo Sugerir medidas preventivas y correctivas que eliminen, mitiguen o trasladen el riesgo del proyecto. Anlisis de sesin El IS revisa los resultados y se pregunta a si mismo: IS: Se han conseguido los objetivos? IS: S, el especialista brind una visin general del proceso de GR en SAC, siendo el ejemplo bastante instructivo, el mismo sintetiza claramente las dificultades que se pueden presentar y como solucionarlas. Se han detectado ya cuatro posibles perspectivas que pueden subdividirse en subproblemas.
295
IS: Es necesario volver sobre el mismo? IS: Por el momento no, es ms conveniente profundizar en las primeras perspectivas con entrevistas estructuradas, si durante las mismas surgen otras perspectivas se puede ampliar mediante otra entrevista abierta. IS: Cul es el nmero y tipo de sesiones necesarias para cubrir el rea? IS: En esta etapa se estima necesario 3 sesiones ms: Una sesin destinada a determinar la terminologa utilizada por el especialista. Una sesin para conocer el procedimiento formal de GR en SAC. Observar al especialista en un caso concreto que nos permita refinar los conocimientos del proceso de GR.
296
F 6 Detalle Sesin 6 Objetivo: Detalle de terminologa utilizada Entrevistado: Especialista en Automatizacin y Control Tcnica: Entrevista Abierta Fecha: 3/3/05 Duracin estimada: 3 hs Preparacin de preguntas Cul es la terminologa bsica utilizada en GR de SAC? Repaso del anlisis de sesin anterior IS: Durante la entrevista anterior obtuvimos una visin general del proceso de GR, la misma nos proporcion la siguiente informacin introductoria: - Los objetivos de la GR en SAC (5.1a). - Un resumen del procedimiento GR (5.1b). - Un listado de las actividades principales de GR (5.1C). - Responsables de la GR. - Bsqueda de procedimientos formales de GR en SAC. - Un caso representativo de GR en SAC (5.1g). - Enumeracin de las perspectivas principales de GR en SAC (5.1h). Explicar objetivos al especialista IS: La idea de esta entrevista es comenzar a familiarizarse con la terminologa bsica utilizada en la GR (nuevamente se propuso al Especialista grabar la entrevista para luego transcribirla). Educcin La siguiente transcripcin la obtuvo el IS de la grabacin de la entrevista con el Especialista. El contenido fue revisado por el IS y el Especialista, corrigiendo as las interpretaciones errneas del IS. Lugar: Administracin Central Sala A Duracin real: 5 hs
297
IS: Cul es la terminologa bsica utilizada en GR en SAC El especialista consider conveniente familiarizar al IS con la terminologa que se utiliza en Automatizacin y Control de procesos Industriales. Por ello, previamente le entreg un resumen de os trminos y abreviaturas ms utilizadas en el dominio en cuestin (el mismo se incluye en el apndice G de la tesis). Especialista: Los trminos ms comunes utilizados en GR en SAC son: - Hardware. - Software de desarrollo. - Software de aplicacin. - Firmware. - Equipo de Automatizacin y Control. - Sistema de Automatizacin y Control. - Integrador. - Enclavamiento. - Seguridades. - Licitacin. - Oferta. - Programacin. - Puesta en marcha. - Equipo de trabajo. - Especialista. - Riesgo. - Impacto. - Organizacin. - Desvo. Hardware: Es el equipamiento electrnico que recopila la informacin proveniente del proceso segn las instrucciones programadas (software de aplicacin), activando comandos que controlan el mismo. Como ejemplo podemos citar los PLCs, HMIs, Redes., variadores de velocidad y Servos.
298
Software de Desarrollo: Es software que permite disea, codificar y probar el software de aplicacin. Esta herramienta es provista por el fabricante del Equipo de Automatizacin y Control Software de aplicacin: Es el conjunto de instrucciones que permiten transcribir la secuencia de operaciones a realizar por el hardware (por ejemplo un PLC) para comandar un proceso industrial. Este software construido a la medida del proceso, es provisto por el integrador. Firmware: Contiene el sistema operativo un equipo de automatizacin y control (ej. PLC, HMI), es provisto por el proveedor de SAC como parte del Hardware, normalmente se aloja en memorias Eprom o Flash-eprom. Interacta con el Software de desarrollo, el Software de aplicacin y el Hardware. Equipo de Automatizacin y Control: Normalmente hace referencia al Hardware necesario para implementar una solucin mediante tcnicas de automatizacin y control de procesos, podemos citar como ejemplos: PLCs, HMIs, DCS, PC Industriales, Redes, Servos, Variadores de velocidad, etc. Consta con la capacidad de procesar y controlar informacin digital y analgica proveniente del campo. Sistema de Automatizacin y Control: Conjunto de Equipamientos de Automatizacin y Control, Software de aplicacin, sensores y actuadores que permiten automatizar - controlar un proceso de Industrial. Integrador de SAC: Empresa constituida por un equipo de desarrollo y ventas, que brinda soluciones para la automatizacin y control Industrial.
299
Normalmente proveen el Software de aplicacin, en algunos se suma la provisin de el hardware, la ingeniera y el montaje de la instalacin elctrica (conexionado de sensores, actuadotes, fabricacin de tableros elctricos). Enclavamiento: Se refiere a las condiciones operativas y de seguridad que debe cumplir el proceso para activar o desactivar un actuador. Seguridades: Mediante la deteccin de condiciones inseguras en el proceso, se activan los controles y avisos necesarios para evitar prdidas humanas y/o materiales Licitacin: Llamado a concurso de ofertas, el objetivo de la misma es que el cliente obtenga (segn su criterio) la mejor relacin costo - beneficio para el trabajo a contratar. Oferta: Cotizacin y enumeracin de tareas y equipamiento de SAC necesarios para implementar la solucin. Programacin: En la jerga de sistemas de Automatizacin y Control, cubre las etapas de diseo arquitectnico, codificacin, pruebas unitarias y pruebas de integracin de una aplicacin SAC. Puesta en Marcha: En la jerga de SAC cubre las etapas de implantacin y pruebas del sistema en el entorno operativo. Esta compuesta por las pruebas del software de aplicacin, pudiendo incluir en algunos casos las pruebas del hardware y el conexionado a campo (depende del tipo de contratacin).
300
Equipo de trabajo: Equipo de especialistas coordinados de manera tal de lograr un desarrollo sincronizado y efectivo del proyecto. Especialista Persona capacitada y experimentada en una gama de productos SAC. Riesgo Segn Weber, 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, o en faltas. Impacto Se refiere al dao humano o material que puede provocar la ocurrencia de un riesgo. Por ejemplo, si las seguridades de un sensor de mxima presin en una caldera, no son implementadas adecuadamente, la ocurrencia de una sobrepresin podra traer como consecuencia prdidas humanas, materiales, problemas legales y de imagen para las empresas involucradas. Organizacin En nuestro caso el termino hace referencia al tamao, estructura, capacidad de desarrollo y operativa de un integrador. Desvo Diferencia entre los resultados previstos y los reales. Resumen y comentarios del Especialista Esta terminologa es bsica, ms adelante tendremos que introducir trminos ms especficos
301
Anlisis de sesin El IS revisa los resultados y se pregunta a si mismo: IS: Se han conseguido los objetivos? IS: S, el especialista brind una visin general de la terminologa utilizada en el proceso de GR. IS: Es necesario volver sobre el mismo? IS: Por el momento no, es ms conveniente profundizar en las primeras perspectivas con entrevistas estructuradas, si durante las mismas surgen nuevos trminos podra ser necesario ampliar el glosario mediante otra sesin similar IS: Se podra mejorar algo en la entrevista? IS: El IS no respet las pausas de descanso programadas, durante las ltimas etapas de esta entrevista se perciba cierta falta concentracin tanto en el especialista como en el IS. En la prxima entrevista el IS deber ser ms metdico en estos aspectos.
302
F 7 Detalle Sesin 7 Objetivo: Conocer el procedimiento de gestin de riesgos. Entrevistado: Especialista en Sistemas de Automatizacin y control de una de las Empresas proveedoras de equipos de SAC Tcnica: Entrevista estructurada Fecha: 15/3/05 Duracin estimada: 8 hs Preparacin de preguntas Cul es primer paso de la GR en un proceso SAC? Cules son los pasos siguientes? Cmo detecta los riesgos? Cmo evala la probabilidad de ocurrencia de los riesgos? Cmo evita que el riesgo ocurra? Cmo gestiona el riesgo? Repaso del anlisis de sesin anterior IS: Durante la entrevista anterior obtuvimos la terminologa bsica de GR, se definieron los trminos Hardware, Software de desarrollo, Software de aplicacin, Firmware, Equipo de automatizacin y control de procesos, Integrador de SAC, Enclavamiento. Seguridades, Licitacin, Oferta, Programacin, Puesta en marcha, Equipo de trabajo, Especialista, Riesgo, Impacto, Organizacin, Desvo. Explicar objetivos al especialista IS: La idea de esta entrevista profundizar el conocimiento que tiene el IS sobre el proceso de gestin de riesgos en el desarrollo de software de automatizacin y control de procesos industriales. Lugar: Administracin Central Sala A Duracin real: 8 hs
303
Educcin: La siguiente transcripcin fue obtenida por el IS, a partir de las notas y grabaciones que fue tomando durante el proceso de GR en un SAC. IS: Cul es primer paso de la GR en un proceso SAC? Especialista: Detectar los riesgos potenciales del Integrador en el contexto actual Para ello debemos conocer su capacidad tcnica - econmica, tipo y tamao de proyectos que est manejando. Tambin es necesario conocer su organizacin, tamao de los equipos de proyecto, su capacitacin y experiencia en automatizacin. Es conveniente evaluar el grado de trabajo en equipo logrado. Debemos verificar, si aplica alguna metodologa ordenada de construccin de software. Es importante tener en cuenta el nivel de remuneraciones, para evaluar si puede existir una rotacin alta de personal. Es conveniente analizar la forma en que cotizan sus trabajos, existen integradores que no tienen prevista ninguna clusula que los cubra contra riesgos que surjan durante el desarrollo del proyecto (por ejemplo: demoras en el montaje mecnico). Es necesario verificar si las herramientas de desarrollo son adecuadas y si han sido actualizadas. Adems, se debe evaluar si se ha previsto en el costo de hora-hombre los gastos de amortizacin de las herramientas de desarrollo (que suelen ser muy caras) y los gastos de capacitacin y actualizacin del equipo de trabajo. De esta forma obtenemos una visin de las caractersticas del integrador responsable de ejecutar el proyecto.
304
IS: Cules son los pasos siguientes? Especialista: El paso siguiente es evaluar al cliente que contrata el trabajo. Es importante evaluar con que estructura cuenta la empresa, por ejemplo luego del crisis econmica del 2001 muchas fabricas han reducido o incluso prescindido de un plantel propio de ingeniera. Esto trae como consecuencia especificaciones incompletas o errneas que generan problemas a lo largo de todo el proyecto. Es necesario tratar de evaluar la capacidad y grado de conocimiento que nuestro cliente tiene del proceso automatizar. Adems se debe tener presente la experiencia obtenida de ensayos a pequea escala o la existencia de procesos similares en otras plantas que pueden ser de gran ayuda para completar las especificaciones. Estos elementos nos permiten evaluar el grado de conocimiento que tenemos, y el contexto en que se desarrollar el proyecto. IS: Hasta el momento no tuvo en cuenta el proyecto en s mismo? Especialista: El tercer paso es estudiar el tipo de proyecto, teniendo en cuenta el tipo de industria en el que se va a desarrollar. Por ejemplo el tratamiento de la seguridad, fiabilidad y disponibilidad de un proceso difiere segn el tipo de proceso. En una Central Nuclear esto parmetros deben ser excelentes, en una petroqumica deben ser muy buenos y en una fbrica textil los requerimientos sern menores. Algunos clientes que tienen estndares de calidad muy estrictos (por ejemplo planes de Calidad Total, ISO 9000, ISO 14000, etc.), los mismos suelen crear requerimientos mayores para un mismo proceso, por ejemplo: mayor cantidad y calidad de monitoreos.
305
Adems del proyecto, es importante analizar el pliego de licitacin, nos debemos preguntar si las especificaciones son precisas o ambiguas, en el segundo caso, las estimaciones que realiz el integrador del proyecto pueden resultar errneas. Luego de confeccionada la cotizacin, es importante evaluar si la oferta del integrador cubre demoras y costos imprevistos. La falta de clusulas que limiten los trabajos y equipamiento cotizado pueden crear situaciones de riesgo graves. Una vez adjudicada la licitacin, el compromiso de trabajo se manifiesta a travs de un contrato que por lo general toma en cuenta el pliego y la cotizacin. Se debe considerar las perturbaciones que pueden ser generadas por terceros, por ejemplo: Es necesario construir nuevamente una pieza mecnica importante y compleja, dicha situacin genera una demora de un mes en la puesta en marcha. Si el integrador tiene capacidad ociosa en su equipo de trabajo, puede reorganizar su cronograma, pero si est manejando varios proyectos simultneos seguramente no contar con capacidad ociosa, esta demora puede convertirse en una sobrecarga de trabajo difcil de satisfacer. IS: Cmo detecta los riesgos? Especialista: Estudiando las caractersticas del integrador, el cliente, el proyecto y el contrato IS: Cmo evala la probabilidad de ocurrencia de los riesgos? Especialista: Analizando datos histricos de proyectos desarrollados en contextos similares y estudiando las caractersticas del integrador, el cliente, y el proyecto. IS: Cmo evita que el riesgo ocurra? Especialista: El termino evitar a veces no es el ms adecuado, si bien algunos riesgos pueden ser eliminados otros slo pueden ser acotados o transferidos.
306
Debemos priorizar el tratamiento de los riesgos de alto impacto frente a los de bajo impacto, reforzando los controles y monitoreos en los riesgos de mayor impacto. Por ejemplo si falla el control de temperatura en un reactor de un proceso de fabricacin de PVC, se dispone de 60 segundos para evacuar el producto antes de que el proceso ingrese en una etapa de embalamiento trmico y estalle. Si falla el control de temperatura en una inyectora de PVC, el impacto puede ser la rotura del extrusor o una inyeccin defectuosa. Como vemos en ambos casos, la misma falla tiene consecuencias muy diferentes. IS Cmo gestiona los riesgos detectados? Especialista: Una vez detectado y priorizado el riesgo, es necesario tomar las medidas necesarias para eliminar o mitigar el mismo. Las medidas a implementar dependen del origen del riesgo, para ser ms claro utilizaremos situaciones tpicas que se presentan en algunos proyectos: Si las caractersticas del integrador pueden generar situaciones de riesgo, se deber tomar las medidas necesarias para controlarlas, por ejemplo: - Tomar ms personal o capacitar al grupo de trabajo - Mejorar el trabajo en equipo - Comprar herramientas de desarrollo ms modernas etc. Si el riesgo es inherente al Cliente el integrador puede: Ayudar al cliente en el diseo de la especificacin (contemplando en forma anticipada estas horas en la cotizacin). Mejorar las condiciones en que se acepta el contrato. Colaborar con la coordinacin de tareas con otros contratistas (mecnicos, civiles etc.).
307
Si el riesgo es inherente al Proyecto el integrador puede: - Buscar especificaciones de procesos similares - Proponer la construccin de una maqueta o prototipo. Si el riesgo es inherente al tipo de industria: Buscar especialistas que asesoren al integrador. Por ejemplo en la industria papelera los procesos son muy similares en la mayora de las plantas, pero los requerimientos de un proceso de fabricacin de papel son tan estrictos, que vale la pena contratar a un especialista en fabricacin de papel que determine cuales son los requisitos que debe cumplir el proceso. Es importante destacar, la importancia de monitorear los riesgos durante todo el proceso, de manera tal de evaluar en que grado fueron exitosas las medidas aplicadas. Si en la cotizacin se fijaron clusulas limitativas, que no son tenidas en cuenta por el Jefe de proyectos del integrador, probablemente la medida preventiva tomada durante la etapa de cotizacin, no ser efectiva. Entonces resulta necesario mejorar la gestin la programacin y la puesta en marcha. IS: Debido a mi formacin en el rea de IT temo no interpretar correctamente algunos trminos IS: Qu entiende por programacin y puesta en marcha? Especialista: En la jerga de SAC la programacin equivale a las siguientes etapas de la Ingeniera del software: - Educcin de requisitos. - Diseo arquitectnico. - Codificacin. - Pruebas Unitarias. - Pruebas de integracin. Y puesta en marcha equivale a:
308
- Implantacin del sistema. - Pruebas del sistema. - Validacin. IS: Usted toma en cuenta alguna base terica que pueda yo consultar, para ampliar mis conocimientos sobre la gestin de riesgos? Especialista: Cuando comenc a trabajar en la gestin de riesgos en el rea de SAC me guiaba por el sentido comn, los errores propios y ajenos Ms tarde al estudiar procesos de construccin de software me interes en algunas metodologas de gestin de riesgo, que si bien no eran aplicables en forma directa podan ser adaptadas a nuestra rea, le recomiendo leer la metodologa propuesta por Barry W Bohm, y los trabajos publicados por el SEI y la norma IEEE 1540. IS: Es posible sintetizar en forma ms ordenada el procedimiento que usted utiliza? Especialista: Si, bsicamente podemos diferenciar dos etapas principales: 1) Cotizacin del proyecto de SAC. 2) Ejecucin del proyecto de SAC (Una vez adjudicado el contrato). Notemos que durante la etapa de cotizacin no existe la seguridad de la adjudicacin del proyecto y que adems las caractersticas del presupuestista / vendedor suelen ser diferentes a las del proyectista. Durante esta etapa nos encontraremos con que la mejor herramienta de control de riesgo es una buena redaccin de la oferta y el contrato, en lugar de sofisticados procedimientos de programacin.
309
1) Gestin de Riesgos durante la cotizacin del proyecto de SAC EVALUACION DE RIESGO: - Identificacin de riesgo. - Anlisis de riesgo. - Priorizacin de riesgo.. CONTROL DE RIESGO: - Diseo y aplicacin de clusulas limitativas a la oferta. - Definicin clara y precisa de los alcances del trabajo a realizar. - Estimar margen de reserva en el clculo de esfuerzo. - Estructurar la oferta con alternativas competitivas pero a la vez seguras. Gestin de Riesgos durante el proyecto de SAC EVALUACION DE RIESGO - Identificacin de riesgo. - Anlisis de riesgo. - Priorizacin de riesgo. CONTROL DE RIESGO - Planificacin de la GR durante. - Resolucin del Riesgo. - Monitoreo del Riesgo.
310
Resumen y comentarios del Especialista La descripcin del proceso anterior, puede ser til para describir los procesos principales del SGR. Anlisis de sesin El IS revisa los resultados y se pregunta a si mismo: IS: Se han conseguido los objetivos? IS: S, el especialista brind un visin resumida del procedimiento y los ejemplos que brind son lo suficientemente claros. IS: Es necesario volver sobre el mismo? IS: Por el momento no, ms adelante ser necesario refinar el conocimiento del proceso de GR mediante un anlisis de protocolo. Por otro lado es conveniente estudiar las metodologas sugeridas por el especialista antes de realizar el anlisis de protocolo.
311
F8 Detalle de sesin 8: Objetivo: - Observacin de un proceso de gestin de riesgo. - Refinar conocimientos. Entrevistado: Especialista en Sistemas de Automatizacin y control de una de las Empresas proveedoras de equipos de SAC. Tcnica: Anlisis de protocolo Fecha: 22/3/05 Duracin estimada: 8 hs. Observaciones: Luego de las entrevistas el IS se dispone a observar al especialista en un caso real de gestin de riesgos en un proyecto de Automatizacin y Control de procesos. Los pasos a seguir son: - Paso 1: Grabacin del proceso de GR. - Paso 2: Transcripcin. - Paso 3: Evaluacin de resultados. Preparacin de la sesin: Antes de comenzar la observacin del caso, se explica al especialista el procedimiento: IS: La idea del anlisis de protocolo es observar su accionar en un caso real, con el objetivo de detectar las acciones que usted fij a nivel inconsciente, dicha informacin se complementar con los datos que hemos obtenido en las entrevistas anteriores. Lugar: Administracin Central Sala B Duracin real: 8 hs.
312
Paso 1: Grabacin del protocolo El IS describe la actividad al especialista: El IS explica que el procedimiento se basa en presentar al especialista un caso a resolver, durante esta actividad deber relatar en voz alta todo lo que piense durante la bsqueda de la solucin. El relato del especialista ser grabado y el IS participar como observador registrando que acciones realiza y el material de consulta necesario. Puesta en situacin: Antes de entrar en situacin el IS propone al especialista un ejercicio de puesta en situacin, mediante esta prctica de "calentamiento" el especialista toma confianza, el mismo debe olvidar el micrfono y la observacin de manera de actuar con naturalidad. Durante esta actividad el IS marc al especialista ciertas pautas a tener en cuenta durante la grabacin (volumen de voz, claridad de las palabras), luego se pas al caso propuesto. Registro del caso real de GR El IS presenta el caso propuesto al especialista, graba la sesin observando el comportamiento del mismo. El IS interviene lo menos posible, pero debe anotar cuidadosamente el comportamiento del especialista (por ejemplo al buscar informacin de apoyo). El caso propuesto es el siguiente: Al Integrador B le llega una oferta para automatizar un proceso de fabricacin de un Film de PVC en una planta ubicada en el gran Buenos Aires. Paso 2: Transcripcin El IS escucha la grabacin y transcribe el relato del especialista segmentndolo, adems se indica sobre la transcripcin las observaciones hechas sobre el comportamiento del especialista en el momento de la resolucin del problema.
313
Segmentacin: El especialista analiza la oferta que le envi el integrador B y va a visitar el lugar donde se implantar el sistema de automatizacin y control. El pliego describe los requerimientos del sistema y enumera la cantidad de motores variacin de velocidad a accionar para la laminar el Film. Tambin menciona que existen otros tres motores accionados por drivers de corriente alterna, su propsito es variar la velocidad de tres extrusores. En todos los casos, se especifican la potencia de los motores, la mayora son grandes y requerirn varios niveles de proteccin (termistores, lmite de corriente, limitadores de velocidad y control de torque mximo). Todos los variadores debern comunicarse por red con un PLC, tomando valores de consigna de velocidad y reportando fallas a un PLC, para luego reportarlas en un panel de operaciones grfico del tipo Touch Screen de 15 . En la planta, operan dos mquinas similares, slo varan en el tamao del film que producen. El proceso es bastante sencillo de observar, las mquinas son muy abiertas y brindan la posibilidad de observar en forma directa el proceso a automatizar. Si la especificacin no es correcta podremos observar las mquinas en operacin y obtener lo requisitos por observacin. Al conversar con los ingenieros de planta sobre la reaccin que debera tener la mquina en el caso de cortes del Film, paradas de emergencia y paradas normales, me dieron la impresin de que no conocen en forma precisa los perfiles de variacin de velocidad, normalmente estos requisitos son bastante difciles de relevar en las otras mquinas dado que tendramos que simular esas situaciones varias veces y con producto. El sistema tiene alrededor de 1000 entradas y 600 salidas y unos 800 textos de alarmas, el panel de operaciones est conformado por 60 pantallas de densidad media, podramos decir que es de mediana envergadura.
314
La mquina deber trabajar en una ambiente duro, las inyectoras estn calefaccionadas y es comn tener una temperatura ambiente que oscila entre 40 y 50 C. Deberemos verificar si el Hardware soporta dicha temperatura, debemos tener en cuenta, que el personal de puesta en marcha no podr sostener un ritmo de trabajo fuerte. La red de comunicacin estar constituida por 25 variadores conectados a 5 PLCs y 5 HMIs va red del tipo CAN. El integrador ha trabajado con redes Profibus y Device Net, no tiene experiencia en redes CAN, nosotros no podremos darle apoyo en ese tipo de tecnologa dado que no tenemos experiencia en ese protocolo.
Terminada la visita a planta el IS acompaa al especialista a visitar al Integrador B, lo consulta sobre temas estructurales, quiere analizar el contexto en el cul se desarrollar el proyecto y detectar riesgos potenciales. El integrador B cuenta con un equipo de trabajo slidamente formado.
Segn tengo entendido estn bien coordinados.

Frente a otros integradores la remuneracin es baja puede tener el riesgo de perder personal especializado si no cambia la poltica. En este momento cerr los ltimos proyectos por lo cul este proyecto que el estima de 2500 horas no provocara una saturacin de la estructura.
La planta est trabajando con un programa de calidad total bastante avanzado, probablemente las exigencias de los reportes en el Touch Screen sern ms altas que las solicitadas en el pliego. El equipamiento y versiones de software que tiene el integrador B son bastantes viejas, probablemente se encuentre con alguna limitacin durante la codificacin. La estimacin de horas de trabajo parece adecuada.
En la oferta no se contempl ningn mecanismo de facturacin de horas adicionales. Estas se pueden generar por demoras de los contratistas mecnicos y elctricos . Me preocupa el hecho de que las pruebas de cableado sean realizadas por un tercero, me parece un error que el integrador B no las haya incluido dentro de sus responsabilidades. El cliente tiene un historial bueno, pero en los ltimos meses aparecieron algunas demoras en el pago. El integrador pidi referencias al banco y su situacin financiera es buena. El integrador comenta que la casa Matriz en un proyecto similar se demor 15 das ms de lo previsto en la entrega de la CPU debido a que no llevaba stock de equipos tan grandes. Dentro de la lista de prioridades creo que los riesgos, ordenados de Mayor a menor por su exposicin (probabilidad de ocurrencia e impacto) son: Riesgo 1: Falla del Hardware provocada por a la alta temperatura ambiente Impacto: Muy Alto Probabilidad: Muy Alta Riesgo 2: Bajo rendimiento del personal de puesta en marcha debida provocado por a la alta temperatura ambiente Impacto: Medio Probabilidad: Muy Alta Riesgo 3: Prolongacin de trabajo de desarrollo y puesta en marcha provocado por requisitos incompletos o errneos (debido a que los Ingenieros de planta no demuestran un conocimiento completo del proceso) Impacto: Medio Probabilidad: Media Riesgo 4: Prolongacin de trabajo de desarrollo y puesta en marcha provocado la falta de conocimientos y experiencia del integrador en redes CAN. Impacto: Bajo Probabilidad: Alta
Riesgo 5: Demoras en recepcin de equipos provocadas por no consultar previamente los plazos de entrega. Impacto: Muy Alto Probabilidad: Muy Baja Riesgo 6: Posibilidad de prdida de algn especialista a lo largo del proyecto provocada por una baja remuneracin del personal respecto a los sueldos del mercado Impacto: Medio Probabilidad: Baja Riesgo 7: Bajo rendimiento del personal del personal de desarrollo y puesta en marcha provocado por Herramientas de desarrollo de software anticuadas. Impacto: Bajo Probabilidad: Baja Riesgo 8: Dificultades financieras provocadas por pequeas dudas que surgen del retraso en los pagos del cliente dado que tiene un historial bueno de pagos es conveniente que el sector administrativo controle el tema para acotar el riesgo. Impacto: Medio Probabilidad: Muy baja Riesgo 9: Prolongacin de trabajo de puesta en marcha provocado por pruebas de conexionado incompletas. Impacto: Medio Probabilidad: Muy baja Riesgo 10: Prolongacin de trabajo de puesta en marcha provocado trabajos de terceros demorados. Impacto: Bajo. Probabilidad: Muy baja Ya hemos priorizado los riesgos veamos como los manejamos: Dado que el cliente es bastante flexible, podemos sugerir que coloque un aire acondicionado en la sala de tableros, con esto podremos eliminar los riesgos 1 y 2.
Podramos reforzar la etapa de educcin de requisitos, tenindola en cuenta dentro de los costos de la cotizacin, de manera de minimizar el riesgo 3. Se debe capacitar en redes CAN a los proyectistas para eliminar el Riesgo 4. El integrador debe conseguir un compromiso escrito con el proveedor, fijando los plazos de entrega y acotando as el riesgo 5. El integrador B deber estudiar los sueldos del mercado y acomodar los de su equipo de trabajo para disminuir el Riesgo 6. El Integrador deber conseguir los Up-Grade de herramientas de desarrollo y amortizar su costo en varios proyectos para eliminar el Riesgo 7. Respecto al problema en los pagos sera conveniente fijar intereses punitorios y seguir de cerca el cronograma de pagos para tener acotado el Riesgo 8. El integrador debera realizar por si l mismo las pruebas de conexionado para eliminar el Riesgo 9. Si se producen demoras por incumplimiento de plazos de montaje mecnico o electromecnico, el integrador debera llevar un libro de obra donde dnde se registren estos eventos, de esta forma evita cargar con la responsabilidad de demoras generadas por terceros, esto minimiza el Riesgo 10. En este caso el riesgo se transfiere a otro contratista. Paso 3: Evaluacin de resultados de la observacin: El IS considera que en general el comportamiento del especialista coincide bastante con los procedimientos de GR descriptos por los modelos de B Bohm, el SEI y las descripciones obtenidas en las entrevistas anteriores. Pero al IS no le queda claro dos puntos: - Cules son los riesgos ms comunes en un proyecto de un SAC? - Cmo se calcula la exposicin a riesgo que luego utiliza para establecer prioridades? El IS planifica otra entrevista para clarificar estos puntos.
F9 Detalle de sesin 9 Objetivo : Conocer el procedimiento de gestin de riesgos.
Entrevistado: Especialista en Sistemas de Automatizacin y control de una de las Empresas proveedoras de equipos de SAC Tcnica: Entrevista estructurada Fecha: 25/3/05 Duracin estimada: 5 hs Preparacin de preguntas Cules son los riesgos ms comunes en un proyecto de un SAC? Cmo se calcula la exposicin a riesgo que luego utiliza para establecer prioridades? Lugar: Administracin Central Sala A Duracin real: 8 hs
Repaso del anlisis de sesin anterior IS: Durante la observacin del caso real pudimos ver en forma prctica un proceso de GR, todava existen detalles del procedimiento que deben ser profundizados. Explicar objetivos al especialista IS: Durante las entrevistas anteriores y el proceso de observacin del caso real no pude determinar cuales son los riesgos ms comunes en un proyecto de SAC y de que manera calcula la exposicin a riesgos. IS Cules son los riesgos ms comunes en un proyecto de un SAC? Especialista: Los podramos resumir en la siguiente lista:
319

Baja productividad del equipo de desarrollo Baja productividad del proceso automatizado Baja fiabilidad del proceso automatizado Contaminacin ambiental Estimaciones de esfuerzo errneas Especificaciones incompletas o errneas Falta de aceptacin del producto por parte de usuarios Falta de capacitacin / experiencia del personal No cumplir con los estndares del proceso industrial Pago de intereses punitorios por mora o proceso cado Perder el cliente Perder licitacin Prdida de informacin del proceso Prdida de informacin del proyecto Prdida de materia prima Prdida de reputacin en el mercado (Integrador) Prdida de reputacin en el mercado (cliente) Prdida de reputacin en el mercado (Proveedor) Prdida de personal clave, difcil de reemplazar Prdida de representacin/ certificacin del proveedor Prdidas humanas y/o accidentes Prdida / dao de equipos de proceso. Perturbaciones causadas por tercero Problemas en otros proyectos en desarrollo Problemas de facturacin Problemas de mantenimiento (en garanta) Problemas de mantenimiento (fuera de garanta) Problemas legales Sobrecarga de trabajo Software de aplicacin de mala calidad Reserva Robo de herramientas de desarrollo de software Retraso en cronograma de trabajo Tabla F9.1: Listado de riesgos en SAC.
IS Cmo se calcula la exposicin a riesgo que luego utiliza para establecer prioridades? Especialista: La frmula de Bohm para el clculo de exposicin a riesgo requiere conocer la probabilidad de ocurrencia P(i) y el impacto L(i) que causa la aparicin del riesgo. Entonces deberamos analizar como se estima en SAC P(i) y L(i).
320
Comencemos por P (i): Un riesgo puede ser disparado por una o ms situaciones del contexto en el que se desarrolla el proyecto. Estas situaciones de riesgo sern representadas por un nmero denominado factor de riesgo, el mismo suministrar informacin sobre que tan riesgoso es el contexto de desarrollo del proyecto. Como ejemplo tomemos el riesgo de Prdidas humanas y/o accidentes el mismo puede ser disparado por tres causas (factores de riesgo): - La experiencia en seguridad industrial del cliente. - La experiencia en seguridad industrial del integrador. - La complejidad del proceso. - La peligrosidad del proceso. Si evaluamos la experiencia en seguridad industrial del cliente o del integrador podramos clasificarla en cinco valores: Muy buena, Buena, Regular, Mala, Muy Mala. Podemos asignar un valor numrico de 0 a 1 a esta escala: Muy Buena = 0 Buena = 0,25 Regular = 0,50 Mala = 0,75 Muy Mala = 1 Si evaluamos la peligrosidad y/o la complejidad del proceso podramos clasificarla en cinco valores: Muy alta, Alta, Regular, Baja, y Muy baja. Muy Alta = 1 Alta = 1 Regular = 0,50 Baja = 0,75 Muy baja = 0
321
Denominaremos Xi,j a cada factor de riesgo j del riesgo i. De manera que para el riesgo 21 Prdidas humanas y/o accidentes podramos asignar los factores: - X 21,1: La experiencia en seguridad industrial del cliente. - X 21,1: La experiencia en seguridad industrial del integrador. - X 21,1: La complejidad del proceso. - X 21,1: La peligrosidad del proceso. Podramos decir que si el Integrador tiene una muy mala experiencia en seguridad industrial (no conoce nada) X 21,1: =1. Si la probabilidad de ocurrencia del accidente dependiera solamente de la experiencia del integrador, podramos representar P(i) como: P21 = X 21,1: P21= 1
Pero dijimos que P21 depende de cuatro factores para ello se asigna un peso Wi,j a cada factor de riesgo. Para ser coherente con el rango de valores de de P(i) ( 0 a 1) la suma de los cuatro pesos debe ser igual a 1. - W 21,1: Peso de la experiencia en seguridad industrial del cliente. - W 21,2: Peso de la experiencia en seguridad industrial del integrador. - W 21,3: Peso de la complejidad del proceso. - W 21,4: Peso de la peligrosidad del proceso. Si el cliente y el integrador no conocen las normas de seguridad industrial ni las medidas para evitar o acotar los accidentes, podramos asignar el 80% del peso a W21,1 y : W 21,2: entonces W 21,1 + W 21,2= 0,8 repartiendo por partes iguales la causa del accidente se llega a W 21,1:= 0,4 y W 21,2:= 0,4 . Nos queda un 20 % del peso que repartiremos entre W21.3 y W21.4 por ello W 21,3:= 0,1 y W 21,4:= 0,1 De esta forma podemos expresar R21 como: P21 = W21,1 * X 21.1 + W21,2 * X 21.2 + W21,3 * X 21.3 + W21,4 * X 21.4 P21 = 0,4 * X 21.1 + 0,4 * X 21.2 + 0,1 * X 21.3 + 0,1 * X 21.4
322
Adems podemos decir que s: 0,75 < P21 1 La probabilidad de Prdidas humanas o accidentes es muy alta 0,5 < P21 0,75 La probabilidad de Prdidas humanas o accidentes es alta 0,25 < P21 0,5 La probabilidad de Prdidas humanas o accidentes es media La probabilidad de Prdidas humanas o accidentes es baja 0 < P21 0,5 P21 = 0 La probabilidad de Prdidas humanas o accidentes es nula Cuando comenzamos a analizar los riesgo de un proyecto, debemos preguntarnos que valor asignamos a X 21.1, X 21.2 , X 21.3 y X 21.1. Si nos encontramos con que el integrador y el cliente no cuentan con ninguna experiencia en seguridad industrial, si el proceso es muy peligroso y muy complejo, numricamente se puede expresar como: P21= 0,4 * 1 + 0,4 *1 + 0,1 * 1 + 0,1 *1 = 1 alta. La probabilidad de accidente es muy
Supongamos ahora que el integrador y el cliente cuentan con una muy buena experiencia en seguridad industrial, el proceso no presenta riesgos y es sencillo, numricamente se puede expresar como: P21= 0,4 * 0 + 0,4 *0 + 0,1 * 0 + 0,1 *0 = 0 La probabilidad de accidente es nula.
En otro contexto el integrador tiene muy buena experiencia en seguridad industrial, el cliente tiene una experiencia regular, la complejidad del proceso es regular y el proceso es medianamente peligroso: P21= 0,4 * 0,5 + 0,4 * 1 + 0,1 * 0,5 + 0,1 *0,5 = 0,7 La probabilidad de accidente es alta.
Esta frmula emprica, permite estimar P (i) a partir de los valores lingsticos asignados a las respuestas (Ej. muy malo, malo, regular, bueno, muy bueno) de un cuestionario que refleje el contexto en el que se desarrolla el proyecto SAC. IS Cules son los factores de riesgos para el resto de los riesgos enumerados? Especialista: En la tabla siguiente le resumo la respuesta.
323
Descripcin del riesgo Baja productividad del equipo de desarrollo Baja productividad del proceso automatizado Baja fiabilidad del proceso automatizado Contaminaci n ambiental Estimaciones de esfuerzo errneas Especificacion es incompletas o errneas Falta de aceptacin del producto por parte de usuarios
Xi,1
Xi,2 Nivel de sueldos del integrador. Experiencia necesaria para los requerimientos (integrador) Tasa de falla del hardware seleccionado 0 Experiencia necesaria para los requerimientos (integrador)
Xi,3 Calidad de la gestin del proyecto. Equipo de ingeniera del cliente
Xi,4
Xi,5
Xi,6
Sobrecarga de trabajo Especificacion es incompletas o errneas Temperatura ambiente en el proceso industrial. Proceso industrial txico Especificacion es incompletas o errneas
Conocimientos del proceso
Calidad de la gestin del proyecto.(Clie nte)
Falta de capacitacin / experiencia del personal
Especificacion Conocimientos Similitud con es del proceso del proceso otros procesos brindadas por (Cliente) accesibles el cliente Experiencia Especificacion necesaria para es los 0 incompletas o requerimientos errneas (integrador) El proceso El proceso requiere requiere El proceso conocimientos conocimientos circuitos requiere circuitos combinacional conocimientos secuenciales es de HMI (el implementado implementado integrador s con PLC s con PLC cuenta con (el integrador (el integrador ellos?) cuenta con cuenta con ellos?) ellos?) Estndares de calidad del cliente
Complejidad del proceso
El proceso requiere conocimientos de SCADA (el integrador cuenta con ellos?)
El proceso requiere conocimientos de SERVO S(el integrador cuenta con ellos?)
El proceso requiere conocimientos de REDES el integrador cuenta con ellos?)
10
No cumplir con los estndares del proceso industrial Pago de intereses punitorios por mora o proceso cado Perder el cliente
Intereses punitorios del contrato Falta de aceptacin del producto por parte de usuarios Especificacion es incompletas o errneas
Calidad de la gestin del proyecto. Falta de capacitacin / experiencia del personal
11
Baja productividad del proceso automatizado
12
Perder licitacin
Tabla F9.2 Factores de riesgo.
324
Descripcin del riesgo Prdida de informacin del proceso Prdida de informacin del proyecto Prdida de materia prima Prdida de reputacin en el mercado (Integrador) Prdida de reputacin en el mercado (cliente) Prdida de reputacin en el mercado (Proveedor) Prdida de personal clave, difcil de reemplazar Prdida de representacin / certificacin del proveedor
Xi,1
Xi,2
Xi,3
Xi,4
Xi,5
Xi,6
13
14
15
16
17
Calidad del sistema de mantenimiento 0 del software (Cliente) Calidad de la Sobrecarga de gestin del trabajo proyecto. Baja Baja fiabilidad productividad del proceso del proceso automatizado automatizado Gestin de Reputacin calidad del del proveedor proyecto del hardware (integrador) Baja Baja fiabilidad productividad del proceso del proceso automatizado automatizado Fiabilidad del hardware Servicio de postventa local
0 Servicio de postventa en el lugar en que se instala la aplicacin 0
18
Tiempo de respuesta
Software de desarrollo poco amigables
19
20
21
22
23
24
25
Estado econmicofinanciero del integrador Calidad de la Estado gestin del econmico proyecto financiero del (integrador) integrador Experiencia en Experiencia en Prdidas seguridad seguridad humanas y/o industrial del industrial del accidentes cliente integrador Experiencia Especificacion Prdida / dao necesaria para es de equipos de abordar el incompletas o proceso. proyecto errneas (Integrador). Estado Perturbacione Complejidad s causadas financiero del proceso por tercero (Tercero) Problemas en Calidad de Sobrecarga de gestin del otros proyectos en trabajo proyecto desarrollo (Integrador) Estado Problemas de econmico 0 facturacin financiero del cliente Nivel de sueldos del integrador
Complejidad del proceso
Peligrosidad del proceso
Fiabilidad del hardware
Comunicacin (tercero) Amigabilidad de la herramienta de desarrollo 0
Capacidad tcnica (Tercero) 0
0 Servicio de postventa en el lugar en que se instala la aplicacin (Proveedor de HW y HD)
26
Problemas de Sobrecarga de mantenimiento trabajo (en garanta)
Fiabilidad del hardware seleccionado
Servicio de postventa local (Proveedor de HW y HD)
325
Xi,1
Xi,2
Xi,3
Xi,4
Xi,5
Xi,6
27
Problemas de Calidad del mantenimiento servicio de (fuera de mantenimiento garanta) del cliente
Fiabilidad del hardware seleccionado
Servicio de postventa local (Proveedor de HW y HD) Retraso en el cronograma de trabajo
28
Problemas legales
Flexibilidad del Flexibilidad del contrato cliente
Servicio de postventa en el lugar en que Sobrecarga de se instala la trabajo aplicacin (Proveedor de HW y HD) Baja productividad 0 del equipo automatizado
29
30
Clculo de carga de Sobrecarga de trabajo en trabajo base al l total de proyectos a desarrollar Calidad de la Software de gestin del aplicacin de proyecto mala calidad (integrador) Reserva Robo de herramientas de desarrollo de software Retraso en cronograma de trabajo 0 Seguridad del integrador Calidad de la gestin del proyecto (integrador)
Experiencia requerida (integrador) 0 Seguridad del cliente Experiencia requerida (integrador)
Certificacin del integrador 0
31
32
0 Prdidas / Daos de equipamiento del proceso
33
Sobrecarga de trabajo
Demoras causadas por tercero
Debemos notar que algunos riesgos son consecuencia de otros por ejemplo R5 es consecuencia de R6 y R8 (que pasan a ser factores de riesgo de R5). IS Cules son los pesos asociados a los factores de riesgo? Especialista: En la tabla siguiente le resumo la respuesta.
i
1 2 3 4 5 6 7 8 9 10 11 W i,1 0,2 0,3 0,6 1 0,3 0,3 0,5 0,25 1 0,65 0,4 W i,2 0,2 0,3 0,4 0 0,7 0,33 0,5 0,25 0 0,35 0,3 W i,3 0,6 0,3 0 0 0 0,3 0 0,15 0 0 0,3 W i,4 0 0,2 0 0 0 0,07 0 0,15 0 0 0 W i,5 0 0,2 0 0 0 0 0 0,1 0 0 0 W i,6 0 0 0 0 0 0 0 0,1 0 0 0
Tabla F9.3 Pesos de los factores de riesgo.

i
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
W i,1 1 0 0,5 0,6 0,5 0,5 0,25 0,5 0,65 0,4 0,33 0,4 0,4 1 0,25 0,1 0,4 1 0,25 0 0,5 0,6
W i,2 0 0 0,5 0,4 0,3 0,5 0,25 0,5 0,35 0,4 0,34 0,1 0,5 0 0,25 0,4 0,3 0 0,35 0 0,5 0,1
W i,3 0 0 0 0 0,2 0 0,25 0 0 0,2 0,33 0,5 0,1 0 0,25 0,4 0,3 0 0,3 0 0 0,1
W i,4 0 0 0 0 0 0 0,25 0 0 0 0 0 0 0 0,25 0,1 0 0 0 0 0 0,1
W i,5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0,1
W i,6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Tabla F9.3 Pesos de los factores de riesgo.
Adems de los factores de riesgo y los pesos de los factores, en el clculo de P (i) se agrega una montante K (i) que refleja la proporcin de cada R (i) en la estadstica de riesgo. De manera que la frmula final para el clculo de P (i) es :
i Pi = K i j =1Wi. j X i. j
Ec 4.3.4.3.a: Probabilidad de riesgo i.
0 K(i) 1 A continuacin se detallan los valores estadsticos de K(i)

i
1 2 3 K (i) 0,15 0,6 0,12
Tabla F9.4 Valores estadsticos de K (i) obtenidos por el especialista
327
i
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
K (i) 0,1 0,5 0,1 0,09 0,1 0,1 0,12 0,17 0,01 0,2 0,08 0,01 0,2 0,02 0,01 0,02 0,12 0,04 0,05 0,04 0,19 0,3 0,03 0,09 0,06 0,3 0,25 0,01 0,01 0,3
Tabla F9.4 Valores estadsticos de K (i) obtenidos por el especialista
Para calcular las prdidas L (i) que genera cada riesgo debemos considerar que un riesgo puede generar prdidas humanas, econmicas, retraso en el cronograma planificado y grandes cambios tcnicos. Entonces podemos considerar que la ocurrencia de un riesgo en SAC genera un impacto con cuatro componentes: Impacto en la seguridad de las personas. Impacto econmico. Impacto en el cronograma de proyecto. Impacto tcnico.
328
Para clarificar el punto veamos dos ejemplos: - Ejemplo 1: Si estamos en la etapa de licitacin de un proyecto el riesgo Prdida de licitacin solo tiene un impacto econmico, los otros tres impactos no estarn presentes durante esta fase del proyecto. - Ejemplo 2: El riesgo Baja productividad del equipo de desarrollo tiene un impacto econmico y un impacto en el retraso del cronograma de trabajo, no tiene impacto tcnico ni impacto en la seguridad del proceso industrial. - Ejemplo 3: El riesgo Prdidas humanas y /o accidentes provoca un gran impacto en la seguridad de las personas afectadas al proceso industrial, genera impactos econmicos elevados (por pago de indemnizaciones, lucro cesante, etc.) y genera importantes demoras en la construccin del proyecto y en la operacin. Para calcular RE es necesario valorizar L(i), el primer problema que me encontr es el de establecer una unidad comn para los cuatro componentes de impacto, por ello establec una valorizacin de 0 a 100 para cada una de ellas, sum los cuatro valores y los divid por cuatro para obtener un valor promedio L(i). En base a mi experiencia constru la siguiente tabla de valorizacin de prdidas.
Tipo de Contrato Riesgo Prdidas
Lcrono
Leco
Ltec
R01 R02 R03 R04 R05 R06 R07 R08 R09 R10
Baja productividad del equipo de desarrollo Baja productividad del proceso automatizado Baja fiabilidad del proceso automatizado Contaminacin ambiental Estimaciones de esfuerzo errneas Especificaciones incompletas o errneas Falta de aceptacin del producto por parte de usuarios Falta de capacitacin / experiencia del personal No cumplir con los estndares del proceso industrial Pago de intereses punitorios por mora o proceso cado MG Adm. MG Adm.
50 0 0 5 100 100 60 60 15 100 20 100
30 30 20 100 100 0 60 0 40 100 20 100
0 5 5 5 0 0 60 60 15 100 0 0
0 5 20 100 0 0 10 10 0 100 20 0
20 10 11 55 50 25 48 32,5 18 100 15 50
Tabla F9.5 Valorizacin de prdidas establecida por el especialista.
329
Lseg
Lcrono
Leco
Lseg
0 0 0 0 0 0 0 10 0 100 90 5 0 0 10 10 0 10 60 0 0
Tipo de Contrato
Riesgo
Prdidas
Lec
R12 R13 R14 R15 R16 R17 R18 R19 R20 R21 R22 R23 R24 R25 R26 R27 R28 R29 R30 R31 R32 R33
Perder licitacin Prdida de informacin del proceso Prdida de informacin del proyecto Prdida de materia prima Prdida de reputacin en el mercado (Integrador) Prdida de reputacin en el mercado (cliente) Prdida de reputacin en el mercado (Proveedor) Prdida de personal clave, difcil de reemplazar Prdida de representacin/ certificacin del proveedor Prdidas humanas y/o accidentes Prdida / dao de equipos de proceso. Perturbaciones causadas por tercero Problemas en otros proyectos en desarrollo Problemas de facturacin Problemas de mantenimiento (en garanta) Problemas de mantenimiento (fuera de garanta) Problemas legales Sobrecarga de trabajo Software de aplicacin de mala calidad Reserva Robo de herramientas de desarrollo de software Retraso en cronograma de trabajo
0 0 30 0 0 0 0 20 0 100 80 30 50 0 0 0 0 100 60
80 50 30 40 100 100 100 20 80 100 80 30 50 30 20 20 100 100 60
0 0 0 0 0 0 0 20 0 10 10 5 0 0 30 30 0 10 60
20 12 15 10 25 25 25 23 20 78 65 18 25 8 15 15 25 55 60
50 70
30 70
0 0
20 35
Tabla F9.5 Valorizacin de prdidas establecida por el especialista.
MG : Contrato por monto global Adm. : Contrato por administracin (se factura por hora de trabajo). Con el valor de P(i) y L(i) se estima la exposicin al riesgo i, de esta forma se obtiene RE(i) mediante la frmula de Bohm RE(i) = P(i) * L(i). IS Cmo prioriza los riesgos?
330
Especialista: Mediante dos criterios: - Los riesgos con mayor RE requieren atencin prioritaria. - Los riesgos con RE similares se priorizan en base a la cercana del impacto. IS Qu entiende por cercana del impacto? Especialista: Le voy a explicar el criterio mediante un ejemplo, supongamos que estamos cotizando un proyecto y que al calcular las RE(i) nos encontramos con que los dos riesgos de mayor exposicin, tienen valores de RE similares. Supongamos adems que estos se corresponden con: - Prdidas humanas y/o materiales - Sobrecarga de trabajo El primero slo se puede producir durante las etapas finales del ciclo de vida de un SAC (puesta en marcha y/o operacin), mientras que el segundo aparecer a lo largo de todo el proyecto. En las etapas previas a la puesta en marcha y operacin resulta conveniente resolver primero el problema de sobrecarga de trabajo puesto que el impacto en la seguridad de las personas no aparecer en esta etapa. En cambio en la etapa de puesta en marcha y operacin es prioritario evitar las prdidas humanas y accidentes. Si analizamos el ejemplo anterior, notamos que es necesario establecer prioridades relativas al punto del ciclo de vida en que se encuentra el SAC, en el momento en que se realiza el anlisis de riesgo. Finalmente el criterio que adopt para establecer la prioridad es el siguiente: Prio (i) = RE (i) * CC(i) El coeficiente de cercana CC(i) toma el valor 1 si el impacto es inmediato, 0,75 si es cercano y 0,5 si el impacto es lejano. Podemos ver que ante un mismo valor de RE el riesgo de impacto ms cercano tendr una prioridad ms alta que un riesgo cuyo impacto tiene una distancia temporal mayor.
331
IS En qu etapa impacta cada riesgo? Especialista: Lo podemos resumir de la siguiente forma:

Descripcin del riesgo Baja productividad del equipo de desarrollo Baja productividad del proceso automatizado Baja fiabilidad del proceso automatizado Contaminacin ambiental Estimaciones de esfuerzo errneas Especificaciones incompletas o errneas Falta de aceptacin del producto por parte de usuarios Falta de capacitacin / experiencia del personal No cumplir con los estndares del proceso industrial Pago de intereses punitorios por mora o proceso cado Perder licitacin Prdida de informacin del proceso Prdida de informacin del proyecto Prdida de materia prima Prdida de reputacin en el mercado (Integrador) Prdida de reputacin en el mercado (cliente) Prdida de reputacin en el mercado (Proveedor) Prdida de personal clave, difcil de reemplazar Prdida de representacin certificacin del proveedor Prdidas humanas y/o accidentes Prdida / dao de equipos de proceso. Perturbaciones causadas por tercero Problemas en otros proyectos en desarrollo Problemas de facturacin Problemas de mantenimiento (en garanta) Problemas de mantenimiento (fuera de garanta) Problemas legales Sobrecarga de trabajo Software de aplicacin de mala calidad Robo de herramientas de desarrollo de software Retraso en cronograma de trabajo Etapa de ciclo de vida SAC impactada Todas Operacin Operacin Operacin Todas Todas Operacin Todas Operacin Operacin Cotizacin Todas Todas Puesta en marcha y/o Operacin Todas Todas Todas Todas Todas Puesta en marcha y/o Operacin Puesta en marcha y/o Operacin Todas Todas Puesta en marcha y/o Operacin Operacin Operacin Todas Todas Todas Todas Todas
Tabla F9.6: Etapas impactas por un riesgo
IS Cmo estima la sobrecarga trabajo? Especialista: Considerando una jornada normal de ocho horas cada persona dispone de un promedio de 176 horas al mes para realizar su parte del proyecto. Pero tambin debemos tener en cuenta el esfuerzo estimado del proyecto, los
Apndice F: Entrevistas Autor: Ing. Jos Luis del Ro
332
cronogramas de todos los proyectos que maneja y/o manejar el integrador y la cantidad de personas asignadas a los mismos. Cabe destacar que frecuentemente me encuentro con estimaciones de esfuerzo errneas. Cada integrador debera llevar una estadstica del tiempo de desarrollo en base a la cantidad de entradas / salidas (Digitales y/o analgicas) del proceso, los accionamientos y servomotores a gobernar, la cantidad de conexiones a redes de comunicacin y la complejidad del proceso a automatizar. Si se subvala el esfuerzo, aparecer una sobrecarga de trabajo que generar muchos problemas en el proyecto, por ello resulta conveniente revisar esta evaluacin en el momento del anlisis de riesgo y tener en cuenta este desvo en el clculo de la sobrecarga de trabajo. IS Qu otro parmetro necesita estimar en un anlisis de riesgo? Especialista: Es importante saber que tan fiable es el resultado para determinar as la calidad del anlisis de riesgo. El criterio que utilizo es el siguiente: - Si se han obtenido el 100 % de los datos de contexto esenciales y ms del 70% de los no esenciales, la fiabilidad del anlisis de riesgo es muy buena. - Si se han obtenido el 100 % de los datos de contexto esenciales y menos del 70% de los no esenciales, la fiabilidad del anlisis de riesgo es buena. - Si se han obtenido el 70 % de los datos de contexto esenciales y ms del 70% de los no esenciales, la fiabilidad del anlisis de riesgo es regular. - Si se han obtenido el 70 % de los datos de contexto esenciales y menos del 70% de los no esenciales, la fiabilidad del anlisis de riesgo es mala. Con una fiabilidad del anlisis regular o mala, deberamos buscar ms datos de manera de obtener resultados ms confiables. IS: Una vez determinados los riesgos prioritarios, cmo busca las soluciones? Especialista: Es sencillo en base al tipo de riesgo y a la valoracin de los factores es fcil armar una tabla en la que se relaciona la causa con la solucin. Por ejemplo si el integrador no tiene experiencia en seguridad industrial (X21.2= 1) es necesario
333
que tome cursos de seguridad industrial o contrate especialistas en el tema de manera de tratar que X21.2=0). Por lo tanto, es factible establecer una solucin para cada factor de los riesgos prioritarios. Anlisis de sesin: IS: Es necesario solicitar al especialista la tablas de soluciones asociadas a cada R(i) para completar la automatizacin del proceso de anlisis de riesgo. La frmula utilizada por el especialista permite estimar P (i) a partir de los valores lingsticos (Ej. Muy, malo, malo etc.) asignados a las respuestas de un cuestionario que refleje el contexto en el que se desarrolla el proyecto SAC. Dado que los valores de Wi,j ,K(i) y L(i) se obtienen en base a la experiencia del especialista para un mercado y/o pas particular sera conveniente que el SGR permita una modificacin rpida de los mismos (a un nivel solo accesible con clave de administrador del SGR). Los valores suministrados por el especialista se tomarn como valores preestablecidos de manera que presionado un botn se pueda volver fcilmente a ellos. Los valores de los factores de riesgo Xi,j sern ingresados al sistema mediante un cuestionario basado en la taxonoma de riesgos SAC. Mediante listados desplegables se asignar una gama de valores lingsticos predeterminados a cada respuesta (por ejemplo Muy bueno, Bueno, Regular, Malo y Muy malo) estos valores debern ser transformados a nmeros segn lo expuesto por el especialista. Esta claro como se estima P(i) pero no ha quedado bien fundamentado su origen, es conveniente realizar otra entrevista con el especialista para terminar de entender el problema. La duracin de la sesin, fue mayor que la prevista debido a las preguntas no programadas que surgieron durante el desarrollo de la misma.
334
F10 Detalle de sesin 10 Objetivo : Fundamentar la frmula utilizada para el clculo de P (i)
Entrevistado: Especialista en Sistemas de Automatizacin y control de una de las Empresas proveedoras de equipos de SAC Tcnica: Entrevista abierta Fecha: 3/4/05 Duracin estimada: 2 hs Preparacin de preguntas Es posible fundamentar claramente el origen de la frmula de P(i)? IS: Todava no queda bien fundamentado el origen de la frmula de P(i). Es posible fundamentar la misma? Especialista: Vamos a ver los fundamentos desde el punto de la probabilidad y estadstica, notemos que un riesgo puede ser disparado por uno o ms sucesos independientes, volviendo al caso del riesgo R21 Sufrir prdidas humanas y /o accidentes puede ser disparado por cuatro sucesos independientes: Suceso S21.1: El integrador no tiene conocimientos de seguridad industrial. Suceso S21.2: El cliente no tiene conocimientos de seguridad industrial. Suceso S21.3: El proceso es complejo. Seceso S21.4: El proceso opera en un ambiente Peligroso. Mediante los resultados histricos de los proyectos podemos determinar que en los casos que se produjo R21 las causas se distribuyeron de la siguiente forma: 40 % de las ocurrencias se debieron al suceso S21.1 40 % de las ocurrencias se debieron al suceso S21.2 10 % de las ocurrencias se debieron al suceso S21.3 10 % de las ocurrencias se debieron al suceso S21.4
Apndice F: Entrevistas 335
Lugar: Administracin Central Sala A Duracin real: 2 hs
P21.1 = 0,4 P21.2 = 0,4 P21.3 = 0,1 P21.4 = 0,1

Aplicando la frmula de probabilidad compuesta para sucesos independientes: P (S21.1 o S21.2 o S21.3 o S21.4) = P21.1 + P21.2 + P21.3 + P21.4
Ec. F10.1
Definiendo X21.1, X21.2, X21.3, X21.4 como factores de riesgo obtenidos del contexto en el que se desarrolla el proyecto y W21.1, W21.2, W21.3 y W21.4 como pesos que reflejen la distribucin estadstica que cada factor de riesgo tiene para R21. Podemos estimar P21.1, P21.2, P21.3 y P21.4 en funcin del contexto, utilizando las siguientes ecuaciones. P21.1 = W21.1 X21.1 P21.2 = W21.2 X21.2 P21.3 = W21.3 X21.3 P21.4 = W21.4 X21.4
Ec. F 10.2 Ec. F 10.3 Ec. F 10.4 Ec. F 10.5
Donde X21.1, X21.2, X21.3 , X21.4 W21.1, W21.2, W21.3 y W21.4 son nmeros reales con un valor comprendido entre cero y uno. Entonces: P (S21.1 o S21.2 o S21.3 o S21.4) = W21.1 X21.1 + W21.2 X21.2 +W21.3 X21.3 + W21.4 X21.4
Ec. F 10.6
Supongamos que los cuatro factores de riesgo estn presentes en su mximo potencial, es decir tanto el cliente como el integrador no tienen ninguna experiencia, el proceso es muy complejo y se desarrolla en un ambiente muy peligroso en este caso: X21.1 =1, X21.2 =1, X21.3 =1, X21.4 =1 y P (S21.1 o S21.2 o S21.3 o S21.4) = 1 Sustituyendo estos valores en la ecuacin F10.6: W21.1 + W21.2 +W21.3 + W21.4 = 1
W21.i =1
Ec. F10.7
Teniendo en cuenta la distribucin estadstica de R21 y considerando: P (S21.1 o S21.2 o S21.3 o S21.4) = 1
Si X21.1 =1 y P21.1 = 0,4 Si X21.2 =1 y P21.2 = 0,4 Si X21.3 =1 y P21.3 = 0,1 Si X21.4 =1 y P21.4 = 0,1
P21.1 = W21.1 X21.1 = W21.1 = 0,4 P21.2 = W21.2 X21.2 = W21.2 = 0,4 P21.3 = W21.3 X21.3 = W21.3 = 0,1 P21.14= W21.4 X21.4 = W21.4 = 0,1
Teniendo el conocimiento de los factores que dispara cada riesgo y su valor estadstico de distribucin, podemos generalizar este razonamiento para el resto de los riesgos. Determinando as el peso W (i.j ) de cada factor de riesgo R(i). Dado que a travs de los aos fui realizando una estadstica de riesgos, es factible afectar a P(i) de una constante K(i) que refleje estos valores estadsticos. Si estadsticamente el riesgo de Sufrir prdidas humanas y /o accidentes aparece en el 4 % de los proyectos K21= 0,04. De manera similar se puede determinar el resto de los K(i). IS: Durante el anlisis de protocolo observ que no aplic directamente la frmulas de P(i) y estim el impacto en forma intuitiva de manera tal que su estimacin de RE fue cualitativa ms que cuantitativa.Por qu no la aplic? Especialista: Realizar el clculo de exposicin a riesgo en forma manual es muy tedioso, la mayora de las veces las fechas de presentacin de pliegos de licitaciones son muy cercanas y en el caso de proyectos que ya comenzaron pocas veces dispongo de tiempo para un anlisis tan detallado. Por ello solamente aplico la frmula en proyectos grandes a pesar de que funciona muy bien para cualquier tamao de proyecto, Si contar con una Herramienta que aplique en forma automtica la metodologa citada, sera factible aplicarla a todos los casos.
337
F11 Detalle de sesin 11 Objetivo: Obtener un esquema detallado de la funciones que se desarrollan durante un proceso de gestin de riesgo. Entrevistado: Especialista en Sistemas de Automatizacin y control de una de las Empresas proveedoras de equipos de SAC Tcnica: Entrevista estructurada Fecha: 10/4/05 Duracin estimada: 6 hs Preparacin de preguntas Es posible obtener un detalle ms completo y detallado de las funciones desarrolladas durante un proceso de gestin de riesgos? Es posible combinar dichas funciones con los conceptos de RE y TBQ? El IS formula la pregunta y le propone al especialista construir en forma conjunta un diagrama de funciones del proceso de gestin de riesgos: Especialista: Podemos descomponer las funciones principales del proceso de gestin de riesgo: - Evaluacin de riesgo - Control de riesgo - Evaluacin de calidad del proceso del proceso de gestin de riesgo. - Recopilacin de valores estadisticos para optimizar W, K y L. El proceso puede representarse mediante diagramas de funciones de distinto de nivel de abstraccin. Partiremos del nivel ms alto hasta llegar a un nivel lo suficientemente detallado del proceso.
Lugar: Administracin Central Sala A Duracin real: 8 hs
GESTION DE RIESGOS
F1: Evaluacin de riesgos
F2: Control de riesgos
F3: Evaluar calidad de GR
F4: Optimizar GR
F11: Identificacin de riesgo
F21: Planificacin de GR
F12: Anlisis de Riesgo
F22: Monitoreo de Riesgo
F13: Priorizar de riesgo
Figura F10.a Identificacin de funciones principales y sub-funciones del proceso de GR.
F11: Identificacin de riesgos: El primer paso de la gestin de riesgos es identificar los riesgos potenciales. La ocurrencia del riesgo depende de eventos que cuando se disparan causan problemas. F12: Anlisis de riesgo: Teniendo en cuenta la probabilidad y el impacto de un riesgo, se estima la exposicin a riesgos del proyecto. F13: Priorizar los riesgos: Dado que los recursos necesarios para controlar los riesgos son limitados, es necesario establecer cuales son prioritarios de manera hacer foco en ellos.
F2: Control del riesgo: Una vez identificado y analizado el riesgo debe ser controlado F21: Planificacin de la gestin de riesgos: Es importante tener en cuenta que si no se ataca el riesgo a tiempo el mismo atacar en forma imprevista, por ello se debe planificar la forma de controlar el riesgo mediante soluciones (medidas preventivas y planes de contingencia) se deber indicar adems en que momento es conveniente aplicar las mismas. Existen cuatro estrategias de control de riesgo: - Eliminacin del riesgo. - Reduccin del riesgo. - Transferencia de riesgo. - Aceptacin del riesgo. La adopcin de una u otra depende del tipo de riesgo y/o de la ecuacin costo beneficio que la seleccin aporte, en base a la situacin de contexto y al tipo de riesgo, el SGR sugerir soluciones asociadas a uno de estas cuatro estrategias. F22: Monitoreo del riesgo: Se debe monitorear los factores de riesgo y verificar que las medidas de control sean efectivas. El objetivo es implementar un proceso continuo de evaluacin de riesgo durante el proyecto software. F3: Evaluar calidad de proceso de gestin de riesgo: Si no se cuenta con un conocimiento claro del contexto el proceso de gestin de riesgos ser poco preciso, es necesario evaluar la calidad de la gestin. 4.3.3.1 Descomposicin de F11 Identificacin de riesgos A continuacin se describen las sub- funciones de F11: F11: Identificacin de riesgo
F111: Identificacin de riesgos basados en la taxonoma
F112 Entrevistas Tormenta de Ideas
Figura F10.b: Descomposicin de F11 Identificacin de riesgos.

F111: Identificacin de riesgos basada en la taxonoma: Es una lista de riesgos que han ocurrido en otros proyectos y pueden ser usados como checklist para detectar los riesgos potenciales que se pueden presentar. F112: Entrevista / Tormenta de ideas: En el caso que los datos obtenidos en F111 sean incompletos o poco precisos el SGR sugerir al usuario la deteccin de riesgos mediante entrevistas y/o tormenta de ideas con proyectistas, clientes y/o proveedores. Descomposicin de F111 (Identificacin de riesgos basada en la taxonoma de SAC) Tomando como precedente exitoso, la posibilidad de identificar riesgos mediante un cuestionario basado en la taxonoma de los riesgos [SEI, 1993] y la metodologa empleada por el especialista, se ha desarrollado una taxonoma especializada que se denominar TBQ-SAC, a continuacin se describen las tareas que componen al funcin F111.
F111: Identificacin de riesgos basada en la taxonoma.
F1114 Identificar caractersticas del Contrato
Figura F10.c: descomposicin de F111 Identificacin de riesgos basada en la taxonoma
341
F1119 Identificar RIESGOS segn el contexto
F1111: Identificar Caractersticas Integrador
F1115 Identificar Caractersticas Proceso
F1113 Identificar Caractersticas Proveedor
F1112 Identificar Caractersticas Cliente
F1116 Identificar Caractersticas Terceros
F1117 Identificar Caractersticas Proyecto
F1118 Identificar Caractersticas Hardware
F1111: Identificacin de caractersticas del integrador: Se evalan las caractersticas del integrador (ejemplo: estructura pequea, muy buena experiencia en PLCs, tiene experiencia en el tipo de proceso a automatizar, etc.). F1112: Identificacin de caractersticas del cliente: Se evalan las caractersticas del cliente (ejemplo: conocimientos del proceso regulares, flexibilidad en las negociaciones, etc.). F1113: Identificacin de caractersticas del proveedor de equipos de SAC: Se evalan las caractersticas del proveedor (ejemplo: buen servicio de postventa, estructura grande, ubicacin de sucursales, etc.) F1114: Identificacin de caractersticas del contrato: Se evalan las caractersticas del contrato (ejemplo: Intereses punitorios altos, requisitos ambiguos, poca flexibilidad). F1115: Identificacin de caractersticas del proceso a automatizar: Se evalan las caractersticas del proceso (ejemplo: Alta complejidad, no existen procesos similares, cantidad de entradas / salidas, temperatura alta, ambiente explosivo). F1116: Identificacin de caractersticas de terceros: Se evalan las caractersticas los terceros que interactuarn (ejemplo: problemas econmicos o financieros serios, experiencia en procesos similares, etc.). F1117: Identificacin de caractersticas del proyecto: Se evalan las caractersticas del proyecto (ejemplo: esfuerzo estimado 2000 horas-hombre, plazo de ejecucin cuatro meses, es similar a otro proyecto, etc.). F1118: Identificacin de caractersticas del hardware: Se evalan las caractersticas del hardware (ejemplo: temperatura mxima de operacin 40 C, Tiempo de ciclo para 10 K instrucciones 50 mseg, etc.). F1119: Identificacin de riesgos segn el contexto: Una vez evaluadas las caractersticas en base al cuestionario basado en la taxonoma, se identifican los riesgos mediante inferencias que analizan el contexto en el cul se desarrolla el proyecto. A continuacin se citan dos ejemplos:
342
Ejemplo 1: SI (La estructura del Integrador es pequea) Y (El tamao del proyecto es grande) ENTONCES Existe un alto riesgo de incumplimiento de cronograma por sobrecarga de trabajo.
Ejemplo 2 SI (El Integrador no cuenta con experiencia en seguridad Industrial) Y (El proceso funciona en un ambiente explosivo) ENTONCES Existe riesgo de prdidas humanas y/o materiales. Descomposicin de F12 (Anlisis de riesgo) F12: Anlisis de riesgo
F121: Estimar probabilidad
F122 Estimar impacto
F 123 Evaluar marco temporal
F 124 Evaluar Exposicin a riesgo
Figura F10.d: Descomposicin de F12 anlisis de riesgo.
343
Una vez que se han identificado los riesgos, es necesario valorizar los mismos, se ha adoptado el concepto de exposicin a riesgo propuesto por Barry Bohm (Ver seccin 2.3.1.1). F121: Estimar probabilidad: Estimar qu probabilidad de ocurrencia del riesgo existe para el proyecto. F122: Estimar impacto: Estimar cual ser el impacto de la ocurrencia del riesgo. F123: Evaluar marco temporal: Dentro del cronograma de trabajo existen riesgos cercanos en el tiempo y otros lejanos. Al momento de priorizar riesgos, debemos tener en cuenta el tiempo disponible para implementar un adecuado control del riesgo. F124: Evaluar exposicin a riesgo: Se evala la exposicin a riesgo en base a la frmula de Bohm. Descomposicin de F 21 (Planificacin de la gestin de riesgos)
F 21: Planificacin de la gestin de riesgo de riesgo
F 211: Planificar Eliminacin de riesgos
F 212 Planificar Reducir riesgos
F213 Planificar Transferencia riesgo
F 214 Planificar Aceptacin de riesgos
F215 Plan de contingencia
Figura F10.e: Descomposicin de F21 Planificacin de la gestin de riesgo
344
F211: Planificar eliminacin de riesgos: Se debe seleccionar las soluciones que permitan eliminar el riesgo y evaluar la relacin costo beneficio de esta accin. A continuacin se citan dos ejemplos de solucin: 1) Si existe la posibilidad de perder documentacin (por incendio, por contaminacin con virus, etc.), es conveniente contratar un sistema de respaldo del proyecto, de manera de recuperar fcilmente el trabajo desarrollado. Los costos de proyecto son mucho mayores que este servicio, por ello es recomendable contratarlo. 2) Es necesario tener en cuenta que muchas veces la eliminacin del riesgo, provocar la prdida de una oportunidad. Si una cotizacin es riesgosa (por especificaciones incompletas o errneas), podemos eliminar el riesgo no participando de la licitacin, pero perderamos la oportunidad de desarrollar el proyecto, ganar un cliente y obtener ganancias econmicas. F212: Planificar reduccin de riesgos: Muchas veces, el riesgo no se puede eliminar pero se puede reducir, en otras ocasiones resulta muy costoso eliminarlo pero no demanda mucho esfuerzo reducirlo. En el ejemplo anterior (F211, ejemplo2), puede ser conveniente presentarse a la licitacin, con una cotizacin que contenga clusulas limitativas que acoten el riesgo. F213: Planificar transferencia de riesgos: Muchas veces, es conveniente transferir el riesgo a un tercero, por ejemplo por subcontratacin de un especialista o contratando una compaa de seguros. Otra alternativa es contemplar en el contrato una transferencia de costos, mediante clusulas que se disparen ante la aparicin de trabajos no previstos. De esta forma el riesgo de una especificacin incompleta es asumido por el cliente. F214: Aceptar los riesgos: Si eliminar, reducir o transferir el riesgo es imposible o muy costoso, puede ser aconsejable aceptar el riesgo. Si por ejemplo, un cliente compra en promedio 2000 horas por ao y el riesgo de un proyecto en particular es asumir 200 horas adicionales, puede ser conveniente aceptar el riesgo puntual para no perjudicar la relacin con un buen cliente F215: Plan de contingencia: Se planifican las acciones necesarias ocurrencia del riesgo. ante la
345
F3: Evaluar calidad de proceso de gestin de riesgo: Si se cuenta con un conocimiento pobre del contexto, el proceso de gestin de riesgos ser poco preciso, es necesario entonces evaluar la calidad de la gestin. F4: Configurar SGR: Esta funcin permite ajustar los parmetros de clculo utilizados por el SGR. Toma como base valores estadsticos de probabilidad de ocurrencia de riesgo y su impacto promedio.
346
APNDICE G DICCIONARIO AMPLIADO DE TRMINOS Y ACRNIMOS
Apndice G: Trminos y acrnimos
348
G 1: Diccionario ampliado de trminos

Accionamientos: Ver Variacin de velocidad 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) o Sistemas Expertos. Su mayor campo de aplicacin se da en las industrias qumicas, petroqumicas y en menor medida farmacutica y alimenticia. Control numrico: Sistema de control que calcula y controla el posicionamiento de elementos de corte, son muy utilizados en la mquinas herramientas por ejemplo en la construccin automtica de matrices para la industria automotriz. Controlador lgico programable: Est constituido por la CPU y mdulos perifricos aptos para el comando de elementos industriales, entre los que se pueden citar: Entradas digitales / analgicas, Salidas digitales / analgicas, Mdulos de comunicacin para conectar a redes, HMIs, SCADAS, etc.). Se pueden programar con diversos lenguajes y/o representaciones Entrada digital: Elemento montado sobre un modulo perifrico que permiten leer informacin de seales binarias provenientes de sensores (termostatos, presostatos, fines de carrera, pulsadores, etc.). Entrada analgica: Elemento montado sobre un modulo perifrico que permiten leer una seal analgica suministrada por sensores de velocidad, caudal., corriente, tensin, PH, etc. Hardware: En la tesis se refiere al equipamiento electrnico necesario para correr el software de automatizacin y control de procesos industriales.
349
Herramientas de desarrollo: Se reserva este trmino para el software de edicin de aplicaciones para sistemas de automatizacin y control industrial. IEC 1131: Estndar de programacin de PLC elaborado por IEC que busca unificar los lenguajes de programacin de los proveedores de PLCs. IEEE 1540-2001: Estndar de gestin de riesgos en proyectos software creado y auspiciado por IEEE. Integrador: Empresa encargada de desarrollar software para sistemas de automatizacin y control industrial. Interfase humano-mquina: Esta constituida por un panel de textos o grfico que permite visualizar los datos, estados y/o alarmas y eventos de una mquina o proceso comandado por uno o varios PLCs y PCs industriales. Se programan mediante un Software de desarrollo en un entorno de objetos grficos y scripts. Lenguajes de programacin: Cada fabricante de PLC tiene un lenguaje propio que normalmente permite las siguientes representaciones: Ladder (diagrama escalera), Listado de instrucciones, Compuertas y Bloque lgicos, Scripts. El ms utilizado histricamente es el Ladder que representa en forma grfica el conexionado de distintos contactos similarmente a lo que se utilizaba en la lgica cableada. El Listado de instrucciones permite combinar sentencias de forma tal de representar ecuaciones booleanas. Los Scripts suelen ser propios del fabricante o utilizar lenguajes muy difundidos (C, Visual Basic, Java). Para reducir los tiempos de programacin se utilizan lenguajes de alto nivel, actan en forma similar las herramientas CASE utilizadas en IT. Lgica cableada: La secuencias y condiciones lgicas se implementan mediante relays cableados entre si de forma de implementar los enclavamientos que el automatismo requiera. Lgica programada: Las secuencias y condiciones lgicas se implementan mediante un programa que corre en un PLC o PC Industrial. El programa puede ser editado en diversos lenguajes y/o representaciones, como ser Ladder, Compuertas Lgicas o Listado de instrucciones.
350
Proceso industrial: Conjunto de actividades a desarrollar por un sistema electromecnico (mquina) para producir un producto. Proyecto: En la tesis, se refiere al desarrollo de software de automatizacin industrial. Proveedor: En la 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. Red industrial: Sistema de comunicacin que permite comunicar PLCs, PCs, sensores, DCs, SCADAS mediante un protocolo propietario o abierto. Como ejemplo de protocolos abiertos podemos citar ASI, DeviceNEt, Profibus, Industrial ETHERNET, Profinet. Relay: Dispositivo elctrico 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 posibilidad de conmutacin entre dos estados (abierto y cerrado) permite utilizar lgica booleana e implementar mediante los mismos una lgica de control. Retrofitting: Trmino aplicado al proceso de reciclado de una mquina. Mediante el mismo se realiza el mantenimiento y mejora de la instalacin mecnica mientras que en paralelo se reemplaza el sistema de control. El software puede ser obtenido a partir de una migracin o puede ser diseado nuevamente. Riesgo: Es la posibilidad de sufrir prdidas. Su aparicin produce un resultado no deseado. Salida analgica: Elemento montado sobre un modulo perifrico que permite enviar una seal analgica a un actuador (vlvulas moduladoras, sistemas de posicionamiento, instrumentos, etc.) .Hoy en da estn normalizadas a rangos preestablecidos (4 a 20 miliamper , 0a 20 miliamper, 0 a 10 Volt, Etc.) Salida digital: Elemento montado sobre un modulo perifrico que permite enviar una seal binaria informacin a actuadores (relays, contactores, electrovlvulas, lmparas de sealizacin etc.).
351
Seal analgica: Es una seal que puede variar dentro de un rango continuo de valores dentro de ciertos lmites prefijados. Salida binaria: Es una seal que solo puede asumir dos valores por ejemplo: Marcha-Parada, Abierto-cerrado, SI-NO. Seguridad industrial: Conjunto de disciplinas y actividades destinadas a eliminar y/o minimizar los riesgos de prdidas humanas ,y materiales. Servomotor: Motor de baja inercia mecnica que permite un posicionamiento preciso de mquinas (del orden del micrn). Servoaccionamiento: Accionamiento electrnico de servomotor, permite controlar en forma precisa la velocidad y posicin angular de una mquina mediante dos lazos cerrados de control de dichas variables. 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 monitorear 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 industrial hoy en da ambas disciplinas se complementan y mezclan de forma tal que es difcil precisar el lmite entre ambas. Sistema de posicionamiento: Comandan el posicionamiento de mecnico mediante servomotores, actualmente los sistemas ms modernos suelen incluir una lgica de control y de posicionamiento programables en forma similar a lo que sucede con los PLCs. Son utilizados en robtica y en mquinas herramientas. Sistema de supervisin y adquisicin de datos: Permite visualizar el proceso o automatismo por medio de una computadora (incluye funciones de HMI) conectada a una red industrial adems tiene capacidad de conectarse con la red corporativa y/o a bases de datos corporativas (ej SQL, Access, Oracle etc.).
352
Sistema de visin inteligente: Permiten el reconociendo y discriminacin de imgenes, en la actualidad suelen comunicarse con PLCs, HMIs y SCADAS mediante red. Un aplicacin tpica es el control de calidad de una lnea de proceso continuo. Solucin: En el trabajo de tesis, el trmino sintetiza el conjunto de actividades cuyo objetivo es controlar uno o varios riesgos. Tcnicas digitales: Metodologas de desarrollo de circuitos lgicos que toman como base seales digitales binarias (uno y cero). Mediante su aplicacin se pueden desarrollar circuitos combinatorios (dependen solo del estado actual) y circuitos secuenciales (dependen de los estados predecesores y del estado actual) Tercero: Empresa contratada por el cliente para participar en la construccin del proceso (construccin y montaje de componentes mecnicos, obra civil, instalaciones elctricas, etc.) Variacin de velocidad: Se comanda la velocidad de motores de corriente alterna o continua mediante dispositivos electrnicos denominados accionamientos (Drivers), estos dispositivos se configuran mediante software, pueden incluir una pequea lgica de control local y posibilidades de conectarse a una red industrial.
353
G 2: Diccionario ampliado de acrnimos COCOMO: Constructive Cost Model. CNC: Computer Numeric Control (Control numrico computarizado). CU: Caso de uso DC: Distributed Control (Control distribuido). DIN: Deutches Institute fr Normung (Instituto alemn de normalizacin). FDA: Food and Drug Administration (Administracin de frmacos y alimentos). FP: Function points (Puntos de funcin). GR: Gestin de riesgos. HMI: Human Machine Interface (Interfase Humano Mquina). IEC: International Electro technical comisin. IEEE: Institute of Electrical and Electronics Engineers. ISO: International Organization for Standardization. IT: Information Technology. KDSI: Thousands of Delivered Source Instructions. 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).
354
SGR: Sistema de gestin de riesgos. SEI: Software Engineering Institute. SI: Sistema informtico. TBQ: Taxonomy - Based Risk Identification. TBQ-SAC: Cuestionario de identificacin de riesgos basado en la taxonoma de riesgos en sistemas de automatizacin y control de procesos industriales. TDEV: Time of Develop (Tiempo de desarrollo).
355
356
APNDICE H BIBLIOGRAFA
Apndice H: Bibliografa
357
358
BIBLIOGRAFA [Bohm , 1989] Autor: Bohm B. Tutorial on Software Risk Management Editado por IEEE Computer Society ISBN :0818689064. [Ceria, 2006] Autor Santiago Ceria Casos de uso,un mtodo prctico para explorar requerimientos. Disponible en el sitio de la Universidad de Buenos Aires http://www.dc.uba.ar/people/materias/isoft1/2002_2/apuntes/CasosDeUso. pdf#search='caso%20de%20uso%20actor pgina vigente al 14 de Mayo del 2006. [Croll, 2005] Autor: Paul R Croll IEEE 1540 Engineering Risk Management measurement-based life cycle EIA 12207. Disponible en el sitio http://www.psmsc.com/UG2001/Presentations/06IEEEStandard1540.PDF pgina vigente al 23 de julio del 2005. [DAVION-SYSTEM, 2004] RIAS Product Description. Disponible en el sitio http://www.davion.com/products/rias_product.html pgina vigente hasta el 23 de julio del 2005. [DAVION-SYSTEM, 2004] Risk Management Disponible en el sitio http://www.davion.com/services/risk_management.html pgina disponible vigente hasta el 23 de julio del 2005. [Mc Connell, 1996] Autor Steve Mc Conell Classic Mistakes in Software Engineering Best Practices IEEE Software, Vol. 13, No. 5, September 1996. Disponible en el sitio http://www.stevemcconnell.com/bp05.htm pgina vigente al 23 de julio del 2005. [Ministerio de Administraciones Pblicas, 2000] MTRICA Versin 3 Metodologa de planificacin y desarrollo de Sistemas de Informacin. Disponible en el sitio http://edic.lsi.uniovi.es/metricav3/ pgina vigente al 23 de julio del 2005. [Pfleeger, 2000] Autor Shari Lawrence Pfleeger - University of Maryland Assessing Project Risk. Informacin disponible en el sitio http://www.cs.concordia.ca/~comp554/Wint2000/AssessingProjectRisk.htm vigente hasta el 23 de julio del 2005.
359
[Pressman, 2003] Autor R S Pressman RISK Analasys and Management Disponible en el sitio http://www.rspa.com/spi/project-risk.html#papers pgina vigente al 23 de julio del 2005. [Profibus, 2005] Open solution for the World of automation Disponible en el sitio http://www.profibus.com/ pgina vigente al 23 de julio del 2005. [Risk-Radar, 2005] Software de estimacin de riesgo Risk Radar. Disponible en el sitio: http://www.iceincusa.com/products_tools.htm pgina vigente al 23 de julio del 2005. [Risk-Radar, 2005] User manual. Disponible en el sitio de descarga http://www.iceincusa.com/RRUserManual.pdf pgina vigente al 23 julio de 2005. [Risk-Radar, 2006] Download Demonstration Software. Disponible en el sitio http://www.iceincusa.com/download_tools.htm pgina vigente al 23 de julio del 2005. [Rockwell, 2005]. What is IEC 1131?. Disponilble en el http://www.software.rockwell.com/corporate/reference/Iec1131/ Rockwell Automation pgina vigente al 23 de julio del 2005. sitio de
[SEI, 1993] Autores M J Carr, S L Konda, I Monarch, F C Ulrich, C F Walter, Taxonomy-Based Risk Identification. Disponible en el sitio del SEI http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr06.93.pdf pgina vigente al 23 de julio del 2005. [SEI, 2004] RISK Managemente Overview. Disponible en el sitio del Software , Engineering Institute http://www.sei.cmu.edu/programs/sepm/risk/ pgina vigente al 23 de julio del 2005. [SEI, 2005] Autores: Williams, Ambrose, Bentrem A Roadmap of Risk Diagnostic Methods: Developing an Integrated View of Risk Identification and Analysis Techniques. Disponible en el sitio del SEI http://www.sei.cmu.edu/publications/documents/04.reports/04tn002.html pgina vigente al 23 de julio del 2005.
360
[SERIM, 2004] SERIM Product description .Descripcin del producto disponible en el sitio http://www.computer.org/cspress/CATALOG/sw07970.htm pgina vigente hasta el 23 de julio del 2005. [Siemens, 2004] CD SIMATIC MANUAL Collection. Brinda una amplia descripcin de la tecnologa de automatizacin y control utilizada actualmente. Editado por Siemens AG. [Horowitz, 1999] Autor: Prof. Ellis Horowitz USC COCOMO II.1999.0 Software Implementations of Post-architecture and Early Design models, http://sunset.usc.edu/research/COCOMOII/cocomo_main.html#downloads vigente hasta el 23 de julio del 2005.. [UPM, 2005] Autores: Natalia Jurado, Ana M. Moreno, Sira Vega Tcnicas de evaluacin de Software. Editado por la Universidad Politcnica de Madrid [ULC, 2000] Autor: Dr. Juan M. Ares Casal Pruebas de software, titular de la Universidad de La Corua. Apuntes de la carrera de Ingeniera del Software Unidad 15. Editado por la Universidad Politcnica de Madrid y el Instituto tecnolgico Buenos Aires. [Van Scoy, 2001] Autor: Roger L. Van Scoy Software development risk. Opportunity, NOT problem. Disponible en el sitio http://www.cse.ohiostate.edu/~stovsky/Risk.pdf vigente hasta el 23 de julio del 2005.
361

Del Rio Tesisdemagister

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Del Rio Tesisdemagister

Uploaded by

Copyright:

Available Formats

TESIS DE MAGISTER EN INGENIERA DEL SOFTWARE

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

Autor: Ing. Jos Luis del Ro

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

Autor: Ing. Jos Luis del Ro

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

Autor: Ing. Jos Luis del Ro

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

Autor: Ing. Jos Luis del Ro

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

5.2 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5

Autor: Ing. Jos Luis del Ro

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

5.3 5.3.1 5.3.2 5.3.3 5.3.4 5.3.5 5.3.6 5.4

Autor: Ing. Jos Luis del Ro

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

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

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

Autor: Ing. Jos Luis del Ro

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

F Detalle de entrevistas y observaciones

Autor: Ing. Jos Luis del Ro

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

275 279 283 286 289 297

303 312 319

Autor: Ing. Jos Luis del Ro

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

Autor: Ing. Jos Luis del Ro

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

Autor: Ing. Jos Luis del Ro

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

Autor: Ing. Jos Luis del Ro

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

Autor: Ing. Jos Luis del Ro

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

Autor: Ing. Jos Luis del Ro

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

Autor: Ing. Jos Luis del Ro

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

La figura 1.3 sintetiza la organizacin de la tesis.

Autor: Ing. Jos Luis del Ro

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

Descripcin general del problema

Interfase Gestin del proyecto

Interfase Control de configuracin

Interfase Aseguramiento de calidad

Futuras lneas de trabajo

Detalle de asignacin de entrada y salida de mdulo reutilizable

Diccionario ampliado de terminologa y acrnimos.

Detalle de planificacin, desarrollo y evaluacin de entrevistas

Figura 1.3 Organizacin de la tesis.

Autor: Ing. Jos Luis del Ro

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

Autor: Ing. Jos Luis del Ro

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

Autor: Ing. Jos Luis del Ro

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

Autor: Ing. Jos Luis del Ro

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

CAPTULO 2 DESCRIPCIN DEL PROBLEMA

Captulo 2: Descripcin del problema

Autor: Ing. Jos Luis del Ro