Herramienta informática para apoyar el proceso de toma de decisiones sobre el tipo de mantenimiento a aplicar al equipamiento productivo

Texto completo

(1)Universidad Central “Marta Abreu” de las Villas Facultad de Ingeniería Industrial y Turismo Departamento de Ingeniería Industrial. Trabajo de Diploma Título: Herramienta informática para apoyar el proceso de toma de decisiones sobre el tipo de mantenimiento a aplicar al equipamiento productivo Autor:. Ernesto Erik Fonticiella Cárdenas. Tutores: Ms. C. Aramis Alfonso Llanes Dr. C. Fernando Marrero Delgado Santa Clara, 2009 “Año del 50 Aniversario del Triunfo de la Revolución”.

(2) Pensamiento.

(3) “Quiero que rechaces siempre lo fácil, lo cómodo, todo lo que enaltece y honra; implica sacrificio” Ernesto Che Guevara.

(4) Dedicatoria.

(5) A mis padres y abuelos, por apoyarme, ayudarme y guiarme con su luz por el camino correcto en todas las etapas de mi vida..

(6) Agradecimientos.

(7) A todos los que de una forma u otra contribuyeron y ayudaron en mi formación como futuro profesional, familia, amigos, profesores, compañeros de estudio y muy especialmente: . A mis padres por su ayuda y preocupación.. . A mi viejuca del alma por brindarme su cariño y apoyo en todo momento.. . A mi viejuco “Eddy” por su apoyo, cariño y por enseñarme las cosas que no se aprenden en un aula y que son muy necesarias para la vida.. . A mis viejucos “Freddy y Chichito” por brindarme todo su apoyo y cariño durante todos estos años y por su confianza en mí en todo momento.. . A mi hermanita por ser la cosita más linda que tengo (Espero que sigas mi ejemplo y que seas mucho mejor que yo). . A mis tíos por brindarme todo su apoyo y cariño.. . A mis amigos Angel, Yuniel, Roberto, Yumar, Pereira, Yohansi, Yandry, Dassiel, Luis, Reynol, Reinaldo, Denikel, Yunior y el Chino por ayudarme, apoyarme y aguantarme durante todos estos años.. . A mi amigo el Ing. Yoanni Fernández Guevara por su apoyo y por su valioso aporte en el desarrollo de este trabajo de diploma.. . A mi amigo y hermano Carlitos por ser él la persona en que siempre deposité toda mi confianza durante estos últimos cinco años de estudio, además de ser la persona que me guió y me ayudo de manera incondicional en todo momento.. . A los compañeros del Grupo de Redes de la Universidad Central “Marta Abreu” de las Villas por su apoyo y confianza.. . A los compañeros del departamento de Calidad y Sistemas de la Universidad Central “Marta Abreu” de las Villas por brindarme la posibilidad de ampliar mis conocimientos en estos últimos tres años y por todo su apoyo incondicional.. . A mis profesores y amigos Ms. C Lazaro de Jesús Espinosa Yera y a la Dr. C Yodaira Borroto Pénton por contribuir en el desarrollo de este trabajo de diploma y por el apoyo brindado durante toda la carrera.. . A mis tutores Ms. C Aramis Alfonso Llanes y Dr. C Fernando Marrero Delgado, por explicarme y atenderme siempre que lo necesité.. A muchos otros que no he nombrado y que espero me disculpen porque de lo contrario la lista sería interminable, pero igual todos saben cuánto les agradezco.. Gracias una vez más..

(8) Resumen.

(9) El presente Trabajo de Diploma muestra el proceso de desarrollo de una herramienta informática utilizando la Metodología de Desarrollo en Cascada y el Lenguaje Delphi destinada a apoyar el proceso de toma de decisiones sobre el tipo de mantenimiento a aplicar al equipamiento productivo. El uso de esta herramienta permite establecer la jerarquía o prioridades de procesos, sistemas y equipos, creando una estructura que facilita la toma de decisiones acertadas y efectivas, orientando el esfuerzo y los recursos en áreas donde sea más importante y/o necesario mejorar la confiabilidad operacional; todo ello a partir de la utilización de las principales variables que caracterizan este contexto (Seguridad, Calidad, Régimen de trabajo, Afectaciones, Frecuencia de Fallos, Tiempo de reparación y Costo de reparación). La herramienta creada se destaca por su alto grado de fiabilidad en la captación, procesamiento y obtención de los resultados lo que se traduce en reducción de errores de cálculo, tiempo de ejecución y la obtención de los resultados con mayor calidad comparada con la realización de estas tareas de forma manual..

(10) Summary.

(11) The present Diploma Work shows the process of development of a computer science tool using the Methodology of Development in Cascade and the Delphi Language destined to support the process of decision making on the type of maintenance to apply to the productive equipment. The use of this tool allows to establish the hierarchy or priorities of processes, systems and equipment, being created a structure that facilitates the right and effective decision making, orienting the effort and the resources in areas where it is more important and/or necessary to improve the operational reliability; all this from the use of the main variables that characterize this context (Security, Quality, Work Regime of Operating, Affectations, Failure Frequency, Repair Time and Cost of Repair). The created tool stands out by its high degree of reliability in the pick up, processing and obtaining of the results which is translated in reduction of computational errors, run time and the obtaining of the results with greater quality compared with the accomplishment of these tasks of form manual..

(12) Índice.

(13) Pág. Introducción………………………………………………………………………………. 1. Capítulo I. Marco Teórico Referencial……………………………………………...... 4. 1.1 Introducción………………………………………………………………………….... 4. 1.2 Teorías y conceptos sobre el mantenimiento en las organizaciones…………... 5. 1.3 Sistemas de mantenimiento…………………………………………………………. 6. 1.4 Las herramientas informáticas en la gestión del mantenimiento………………... 13. 1.4.1 El proceso de desarrollo de software………………………………………….. 15. 1.4.2 Modelos de proceso de software.................................................................. 18. 1.4.3 Modelo en cascada………………………………………………………………. 20. 1.5 Conclusiones parciales………………………………………………………………. 22. Capítulo II. Proceso de desarrollo de software...………………………………...... 23. 2.1 Introducción………………………………………………………………………….... 23. 2.2 Definición de los requisitos………………………………………………………….. 23. 2.2.1 Requisitos de usuario (RU)..……………………………………………………. 23. 2.2.2 Requisitos de software (RS)……………………………………………………. 24. 2.3 Diseño de software…………………………………………………………………... 29. 2.4 Implementación……………………………………………………………………….. 39. 2.5 Pruebas del sistema………………………………………………………………….. 40. 2.6 Mantenimiento del software…………………………………………………………. 40. 2.7 Conclusiones parciales………………………………………………………………. 41. Capítulo III. Descripción del software SGM – Criticidad………………………..... 42. 3.1 Introducción………………………………………………………………………….... 42. 3.2 Requerimientos del sistema…………………………………………………………. 42. 3.3 Proceso de instalación……………………………………………………………….. 43.

(14) Pág. 3.4 Configuración de conexión…………………………………………………………. 46. 3.5 Algunas partes que componen la ventana principal de SGM – Criticidad……... 48. 3.6 Barra de menú………………………………………………………………………... 49. 3.7 Componente para el manejo de los datos…………………………………………. 58. 3.8 Desinstalación……………………………………………………………………….... 60. 3.9 Conclusiones parciales………………………………………………………………. 61. Conclusiones……………………………………………………………………………... 62. Recomendaciones…………………………………………………...…………………... 63. Bibliografía Anexos.

(15) Introducción.

(16) En el siglo XXI se ha dejado atrás el período post-industrial y la sociedad mundial se encuentra en la era de los servicios, la informática, biotecnología, electrónica y todo un nuevo espacio que se va abriendo ante los inciertos ojos de hombres que viven un universo de maravillas y contradicciones. Esta nueva etapa, iniciada en los años 80 y todavía sin delimitar, es parte de un futuro inseguro donde el desarrollo de las tecnologías es arrollador, así como el incremento y diversificación acelerada de las ofertas. Las exigencias de los clientes son cada vez mayores, conocen de lo que desean y esperan recibir. En este ambiente la calidad y competitividad son ingredientes vitales para todo producto o servicio que aspire a surgir y mantenerse con éxito en el mercado. Ante las nuevas reglas de producción y la importancia que se le concede a la actividad integral de mantenimiento para el logro de ésta, varios autores han coincidido que en principio un sistema de mantenimiento bien diseñado debe adecuarse a las características de cada máquina lográndose un sistema de mantenimiento alterno, tanto a nivel de fábrica como a nivel de máquina. De modo que no todos los equipos deben tener el mismo sistema de mantenimiento, lo que permite centrar las fuerzas en aquellas partidas de mayor incidencia en éste, y a su vez más susceptibles de mejoramiento y lograr un uso eficiente de los recursos del área en general. Todo ello va a repercutir favorablemente en el logro eficaz y eficiente de la meta de la organización. Hoy día no es justificable pensar que toda una planta debe estar sujeta a un tipo de mantenimiento. Cada equipo ocupa una posición diferente en el proceso industrial, y tiene unas características propias que lo hacen diferente del resto, incluso de otros equipos similares. Si se quiere optimizar, ya no es suficiente con pensar en el tipo de instalación o en las características del equipo. Es necesario tener en cuenta toda una serie de factores que van a determinar las tareas de mantenimiento más convenientes para cada equipo. Tomando en cuenta todos los cambios tecnológicos que se han producido en las empresas cubanas a partir de la segunda mitad de la década de los 90´ se requiere de nuevas herramientas de gestión que de manera flexible permitan adaptarse a los nuevos requerimientos del entorno empresarial. Las nuevas tecnologías de la informática y las comunicaciones (NTIC) ponen a disposición de las empresas todos los medios necesarios para el desarrollo de herramientas informáticas encaminadas a agilizar y optimizar el proceso de toma de decisiones sobre el tipo de mantenimiento a emplear en el equipamiento productivo. Con la implantación de estás nuevas. 1.

(17) herramientas de gestión de la información las empresas cubanas lograrán un mayor aprovechamiento de los recursos humanos y materiales al disponer de toda la información necesaria para apoyar el proceso de tomas de decisiones con respecto a la selección del tipo de mantenimiento a aplicar al equipamiento productivo. En este entorno se requiere determinar el tipo de mantenimiento a aplicar a los equipos industriales. Para ello se necesita calcular el nivel de criticidad y clasificar el tipo de fallo. Estas actividades desarrolladas de forma manual se hacen demasiado engorrosas y atentan contra la aplicación efectiva del procedimiento para determinar el tipo de mantenimiento necesario por lo que la programación de estas actividades a través de un software facilitaría el cálculo y determinación del nivel de criticidad y la clasificación del tipo de fallo. Lo anterior expresa, en apretada síntesis, la situación problemática identificada que originó esta investigación. Lo anterior conduce a plantear como problema científico: la necesidad de contar con una herramienta informática que determine el nivel de criticidad del equipamiento productivo de modo tal que se facilite el proceso de toma de decisiones sobre el tipo de mantenimiento a aplicar. En correspondencia con lo anterior se formuló la Hipótesis de investigación siguiente: Es posible desarrollar una herramienta informática programada en Borland Developer Studio 2006 con un sistema de gestión de bases de datos relacionales basado en Microsoft SQL Server 2000 que permita agilizar el proceso de captación, procesamiento y obtención de los resultados sobre el cálculo del nivel de criticidad en el equipamiento industrial. El objetivo general que se persigue, es elaborar una herramienta informática programada en Delphi usando la herramienta Borland Developer Studio 2006 con un sistema de gestión de bases de datos relacionales basado en Microsoft SQL Server 2000 que permita la captación, procesamiento y obtención de los resultados sobre el cálculo del nivel de criticidad en el equipamiento industrial. Los objetivos específicos que se plantean son:  Diseñar una herramienta que cumpla con los requerimientos que se deriven de la investigación y que posea cierta flexibilidad en su funcionamiento.  Realizar un análisis preliminar que permita definir que se va a procesar y cuáles son las entradas y salidas de la herramienta.. 2.

(18)  Programar la herramienta utilizando el lenguaje anteriormente mencionado optimizando los algoritmos de manera tal que el usuario obtenga los resultados del procesamiento de la información en el menor de los tiempos.  Validar la herramienta mediante el cálculo manual de la criticidad del equipamiento estudiado y la clasificación del tipo de mantenimiento seleccionado para el mismo y establecer una comparación entre los resultados obtenidos por el software y los obtenidos de forma manual.  Elaborar un manual de usuario que contenga toda la información necesaria para el correcto entendimiento de dicha herramienta y que brinde de manera detallada todo lo necesario para la obtención de los resultados. El presente Trabajo de Diploma ha sido dividido en tres capítulos. En el primero se recoge toda la fundamentación teórica de la investigación, así como los términos y definiciones más utilizadas respecto al mantenimiento y las metodologías de selección del sistema de mantenimiento. La metodología de desarrollo propuesta para el software se ilustra en el segundo capítulo, donde se explica detalladamente el procedimiento general para su desarrollo. Posteriormente, en el capítulo tres, se describe de forma detallada el proceso de instalación y configuración del sistema, así como, su forma de utilización por parte de los usuarios. Además, se muestran las conclusiones a las que se arribó, las recomendaciones que se proponen con vistas a enriquecer los resultados alcanzados mediante investigaciones futuras y la bibliografía consultada.. 3.

(19) Capítulo 1.

(20) 1.1 Introducción En el presente capítulo se hace un análisis exhaustivo de la literatura especializada y de otras fuentes involucradas en la temática objeto de estudio, con vistas a precisar los principales aspectos conceptuales involucrados en la investigación. La revisión realizada se estructuró de forma tal que permitiera el análisis del estado del arte y de la práctica como se muestra en la figura 1.1, permitiendo sentar las bases teórico - prácticas del proceso de investigación y con ello, contribuir a sustentar la novedad científica de los principales resultados obtenidos. Se abordan las diferentes técnicas, metodologías y filosofías de mantenimiento que existen en la actualidad y se hace un énfasis especial en la metodología para la selección basadas en la clasificación del equipamiento (Análisis de Criticidad); también sobre las herramientas informáticas en la gestión del mantenimiento.. Figura 1.1 Estrategia seguida en el análisis de la bibliografía para la construcción del marco teórico referencial de la investigación (Fuente: Elaboración Propia).. 4.

(21) 1.2 Teorías y conceptos sobre el mantenimiento en las organizaciones Durante los últimos veinte años, el mantenimiento ha cambiado, quizás más que cualquier otra disciplina gerencial. Estos cambios se deben principalmente al enorme aumento en número y en variedad de los activos físicos que deben ser mantenidos en todo el mundo, diseños más complejos, nuevos métodos de mantenimiento, y una óptica cambiante en la organización de esta actividad y sus responsabilidades [Moubray, 1997; Jeira y Gibson, 2004]. El mantenimiento también está respondiendo a expectativas cambiantes. Estas incluyen una creciente toma de conciencia para evaluar: hasta qué punto las fallas en los equipos afectan la seguridad y el medio ambiente, la relación entre el mantenimiento y la calidad del producto, y la presión de alcanzar una alta disponibilidad en la planta y mantener acotado el costo. Varios autores [Nakajima, 1991; Moubray, 1997; Dunn 1998; Alkaim, 2003; Rodrigues, 2003; Pérez Jaramillo, 2004; Amaris Arias, 2006] consideran estos cambios acontecidos a través de tres generaciones, las cuales representan cómo han venido creciendo las expectativas respecto al desempeño del mantenimiento, la visión de la naturaleza de los fallos del equipamiento y las mejores prácticas utilizadas en una época determinada (ver figura 1.2). Sin embargo, García González-Quijano [2004] y González Fernández [2007] plantean que a los desarrollos en la tercera generación del mantenimiento se han ido añadiendo nuevas tendencias, técnicas y filosofías (ver figura 1.3), de tal forma que actualmente se puede hablar de una cuarta generación del mantenimiento. A modo de resumen, en la figura 1.4 se presenta como han ido evolucionando las expectativas y técnicas del mantenimiento durante estas cuatro generaciones. La definición del término mantenimiento ha sido expresada en diferentes libros, revistas, páginas Web, y otros documentos con puntos de vista similares y pequeñas diferencias o adaptaciones al caso de la empresa u organización de que se trate. Varios son los estudios realizados [De la Paz Martínez, 1996; Sánchez Sánchez, 1999; Batista Rodríguez, 2000; Aguilera Martínez, 2001; Dunn, 2002; Alkaim, 2003; Fabro, 2003; García González-Quijano, 2004; Borroto Pentón, 2005] en los cuales se hace una caracterización del largo camino recorrido en el desarrollo del concepto de mantenimiento, definiendo las particularidades y elementos comunes de cada propuesta, así como sus objetivos, tareas y funciones. Independientemente de la definición que se utilice, se percibe que los conceptos citados utilizan las expresiones “mantener”, “restablecer”, “conservar”, “restaurar” o “preservar” la función pretendida del activo hasta el estándar de funcionamiento deseado por sus usuarios.. 5.

(22) Inicio de la corrida espacial norteamericana. 1950. 1960. Guerra del petróleo (71-74). 1970. Creación de la Comunidad Europea (92). 1980. 1990. 1950- Mantenimiento de Avería. 1ra Generación. 1957- Mantenimiento Correctivo Conocimiento: - Análisis Financiero del Negocio - Previsión y Planificación - Tecnología de la Información. Conocimiento: Reconocimiento del fallo de las actividades de sustitución.. 1951- Mantenimiento Preventivo. 1960- Inicio del concepto de Mantenimiento Predictivo (Condition Maintenance) Generación 1968- Mantenimiento Centrado en la Confiabilidad (RCM). 2000. Conocimiento: - Análisis de Riesgo - Procesos y Calidad - Ciclo de Vida del Equipamiento - Análisis Costo – Beneficio - Tecnología de la Información - Sistema Basado en confiabilidad. Segunda Guerra Mundial (39-45). 1971- Mantenimiento Productivo Total (TPM). (1)- Otros Métodos de Mantenimiento. Era del Mantenimiento Basado en el Tiempo. Era del Mantenimiento Basado en la Condición. Era del Mantenimiento Basado en la Confiabilidad. Era del Mantenimiento Basado en la Calidad Total. 2da Generación 3ra Generación. (1)- Otros Métodos de Mantenimiento: RCM II, MBR, OEE, 6 SIGMAS, EAM.. Figura 1.2 Síntesis Evolutiva del Mantenimiento. Fuente: Alkaim [2003].

(23) TÉCNICAS * * * * * * * * * *. OBJETIVOS * * * * * * * *. Mayor disponibilidad y fiabilidad Mayor seguridad Mayor calidad del producto Respeto al Medio Ambiente Mayor vida de los equipos Eficacia de costos Mayor Mantenibilidad Patrones de fallos / Eliminación de los fallos. Monitoreo de condición Utilización de pequeños y rápidos ordenadores Modos de Fallo y Causas de Fallo (FMEA, FMECA) Polivalencia y trabajo en equipo / Mantenimiento autónomo Estudio fiabilidad y mantenibilidad durante el proyecto Gestión del Riesgo Mantenimiento preventivo Mantenimiento predictivo Mantenimiento proactivo / eliminación del fallo Grupos de mejora y seguimiento de acciones. Figura 1.3 Cuarta generación del mantenimiento. Fuente: García González-Quijano [2004].. Cuarta Generación. Tercera Generación * Mayor disponibilidad y fiabilidad * Mayor seguridad * Mayor calidad de servicio * Respeto al M. Ambiente * Mayor vida operación * Eficiencia de costos. Segunda Generación Primera Generación * Realizarlo cuando se produzca un fallo 1940. 1950. * Mayor disponibilidad * Mayor vida operación * Menores costos 1960. 1970. 1980. 1990. * Mayor disponibilidad y fiabilidad * Mayor seguridad * Mayor calidad producto * Respeto al Medio Ambiente * Mayor vida de equipos * Eficiencia de costos * Mayor mantenibilidad * Patrones de fallos * Eliminación de los fallos 2000. 2008. a) Evolución de las expectativas del mantenimiento Cuarta Generación. Tercera Generación. Segunda Generación Primera Generación * Mantenimiento correctivo 1940. 1950. * Revisiones periódicas * Utilización de grandes ordenadores * Sistemas de control y planificación del mantenimiento 1960. 1970. * Basado en mantenibilidad y fiabilidad * Monitoreo de condición * Estudios de riesgo * Utilización de pequeños y rápidos ordenadores * Modos de Fallo y Causas de Fallo (FMEA, FMECA) * Sistemas expertos * Polivalencia y trabajo en equipos. 1980. 1990. * Monitoreo de condición * Modos de Fallo y Causa de Fallo (FMEA, FMECA) * Polivalencia y trabajo en equipo / Mantenimiento Autónomo * Estudio fiabilidad y mantenibilidad durante el proyecto * Mantenimiento preventivo * Gestión del riesgo * Sistemas Mejora Continua * Mantenimiento predictivo * Mantenimiento proactivo * Grupo de mejora y seguimiento de acciones * Tercerización 2000. 2008. b) Evolución de las técnicas de mantenimiento Figura 1.4 Evolución de las expectativas y técnicas del mantenimiento. Fuente: García González-Quijano [2004] y González Fernández [2007]..

(24) El autor se identifica con el concepto presentado por De la Paz Martínez [1996] dado que proporciona una visión más integral de esta actividad, en consonancia con la dimensión que ha alcanzado esta función en la actualidad y con su impacto en el entorno empresarial. Concerniente al objetivo principal del mantenimiento, además de los autores abordados en los estudios referenciados anteriormente, existe un grupo de planteamientos [Knezevic, 1996a; Prando, 1996; Moubray, 1997; Batista Rodríguez, 2000; Sotuyo Blanco, 2001; Da Silva Neto y Gonçalves de Lima, 2002; Bastidas y Feliu Ripoll, 2003; Fabro, 2003; García-Ahumada, 2001; García Garrido, 2003; Torres, 2005; Wireman, 2005; Stefano, 2006; Lodola, 2006] que coinciden en definirlo, de manera general, como: conseguir el máximo nivel de efectividad en el funcionamiento del sistema productivo y/o de servicios con la menor contaminación del medio ambiente y mayor seguridad para el personal al menor costo posible. Todo lo anterior implica: conservar el sistema de producción y/o servicios funcionando con el mejor nivel de fiabilidad posible, reducir la frecuencia y gravedad de las fallas, aplicar las normas de higiene y seguridad del trabajo, minimizar la degradación del medio ambiente, adaptación rápida a los cambios del entorno (flexibilidad), controlar y reducir los costos a su mínima expresión, entre otros. 1.3 Sistemas de mantenimiento En la literatura especializada, han sido tratados indistintamente los sistemas de mantenimiento como políticas, estrategias o filosofías, métodos y tipos de mantenimiento [Borroto Pentón, 2005]. En la tabla 1.1 se muestra una recopilación de tipos de mantenimiento extraídos de la bibliografía consultada. Lo más común en las denominaciones es el término de sistemas. En Cuba, algunos autores [Fernández, Matos y Prim, 1983; Navarrete Pérez y González Martín, 1986; Portuondo Pichardo, 1990; Taboada Rodríguez et al., 1990], referenciados en Borroto Pentón [2005], han identificado como sistemas de mantenimiento a los siguientes: sistema controlado mediante la supervisión en la producción, sistema regulado, sistema por interrupción en la producción o contra avería, sistema inspectivo, predictivo o por diagnóstico y sistema de Mantenimiento Preventivo Planificado (MPP). También es conocido en la industria cubana, el Sistema Alterno de Mantenimiento (SAM) como un sistema integrador de varios de los sistemas tradicionales [Portuondo Pichardo et al., 1989; De la Paz Martínez, 1996; Aguilera Martínez, 2001]. Hoy en día existen infinidad de herramientas, técnicas, metodologías y filosofías de mantenimiento. Algunas de las más utilizadas son [Nakajima, 1991; Ellmann, 1996; Moubray, 1997; Latino, 1999; Zhu y Pintelon, 2000; Durán, 2000; Latino, 2001; Turner, 2001; Ellmann, 2001; Moore, 2001; Sotuyo Blanco, 2001; Amendola, 2003a; Alkaim, 2003; Fabro, 2003;. 6.

(25) Tabla 1.1 Tipos de mantenimiento según varios autores Tipos de mantenimiento Detectivo Mejorativo o modificativo Rutinario Programado, periódico o sistemático. Contra avería, reactivo, o correctivo. Circunstancial o de oportunidad Progresivo. Preventivo ó basado en el tiempo. Predictivo o basado en la condición. Protectivo Productivo Proactivo. Referencias Sotuyo Blanco, 2001; Malaguera, 2001; Yañez Medina, 2005 Malaguera, 2001; Sotuyo Blanco, 2001; Mora Gutiérrez, y Pérez Peral, 2002; Torres, 2005 Vinivius Lucattelli y García Ojeda, 1995 ; Malaguera, 2001 Pérez Jaramillo, 1992; Aduvire, López & Mazadiego, 1994; Malaguera, 2001; Torres, 2005 ; Yañez Medina, 2005; Normas AFNOR Diaz, 1993; Aduvire, López & Mazadiego, 1994; Benaim et al., 1994; Prando, 1996 ; Knezevic, 1996a; Torres, 1997; Tavares, 1999; Saavedra, 2000 ; Batista Rodríguez, 2000; Malaguera, 2001; Sotuyo Blanco, 2001; Da Silva Neto y Gonçalves de Lima, 2002; Dos Santos Mendez, 2002; Mora Gutiérrez, y Pérez Peral, 2002; Rodrigues, 2003; Kothari, 2004; Yañez Medina, 2005; Wireman, 2005; Torres, 2005; Stefano, 2006 ; Malaguera, 2001; Prando, 1996 ; Knezevic, 1996a Pérez Jaramillo, 1992 Pérez Jaramillo, 1992; Aduvire, Diaz, 1993; López & Mazadiego,1994; Benaim et al., 1994; Vinicius Lucatelly & García Ojeda, 1995; Prando, 1996 ; González García, 1997; Torres, 1997; Batista Rodríguez, 2000; Sotuyo Blanco, 2001; Da Silva Neto y Gonçalves de Lima, 2002; Dos Santos Mendez, 2002; Mora Gutiérrez, y Pérez Peral, 2002; Rodrigues, 2003; Kothari, 2004; Wireman, 2005; Yañez Medina, 2005; Torres, 2005; Stefano, 2006 ; Araya Schulz, 1991; Roda Vázquez & Sal García, 1992; Araya Schulz, 1993; Diaz, 1993; Aduvire, López & Mazadiego, 1994; Benaim et al., 1994; Bollman, 1995; Ellmann, 1997; Torres, 1997; Ortiz Álvarez, 2000; Batista Rodríguez, 2000; Sotuyo Blanco, 2001; Da Silva Neto y Gonçalves de Lima, 2002; Dos Santos Méndez, 2002; Mora Gutiérrez, y Pérez Peral, 2002; Martín, 2003; Rodrigues, 2003; Kothari, 2004; Wireman, 2005; Yañez Medina, 2005; Torres, 2005; Stefano, 2006 Desir & Castolin, 1994 Nakajima,1988; Pérez Jaramillo, 1992; Hartmann, 1993; Rey Sacristán,1993; Tobalina, 1992; Martín de Santiago, 1994; Lezana, 1995; Ortiz Álvarez, 2000 Borda Elejabarrieta, 1993; Dos Santos Mendez, 2002. Fuente: adaptado de Borroto Pentón [2005]..

(26) Alfonso Llanes et al., 2003a; García González-Quijano, 2004; Yañez Medina, Gómez de la Vega, y Valbuena Chourio, 2004; Tavares et al., 2005]: •. Mantenimiento Autónomo/Mantenimiento Productivo Total (TPM). •. Mejoramiento de la Confiabilidad Operacional (MCO). •. Mantenimiento Centrado en la Confiabilidad (MCC/RCM). •. Mantenimiento Basado en el Riesgo (MBR). •. Mantenimiento Centrado en Confiabilidad en Reversa (MCC-R). •. Análisis Causa Raíz (ACR). •. Análisis de Criticidad (AC). •. Optimización Costo Riesgo (OCR). •. Inspección Basada en Riesgo (RBI). Actualmente uno de los mayores retos para las personas encargadas en temas de mantenimiento no es sólo aprender todas las técnicas existentes, sino identificar cuáles son las adecuadas para aplicar en su propia organización y cuáles no, tanto desde el punto de vista técnico como económico [Pérez Jaramillo, 2004]. Ante las nuevas reglas de producción y la importancia que se le concede a la actividad integral de mantenimiento para el logro de esta, varios autores [De la Paz Martínez, 1996; Torres, 1997; Batista Rodríguez, 2000; Bevilacqua y Braglia, 2000; Huerta Mendoza, 2001; González Danger y Hechavarría Pierre, 2002; Dos Santos Mendes, 2002; Borroto Pentón, 2005; Christensen, 2006] han coincidido que, en principio, no es justificable pensar que toda una planta debe estar sujeta a un único tipo de mantenimiento. Cada equipo ocupa una posición desigual en el proceso industrial, y tiene unas características propias que lo hacen diferente del resto, incluso de otros equipos similares. Con el objetivo de decidir sobre el tipo de mantenimiento más apropiado en cada caso se han presentado disímiles propuestas en la literatura. Metodologías para la selección de los sistemas de mantenimiento En la literatura especializada se han presentado una variedad amplia de propuestas encaminadas a decidir el tipo de mantenimiento más apropiado a aplicar a cada equipo. Estas propuestas pueden dividirse en dos tendencias fundamentales, la primera está relacionada a la. 7.

(27) presentación de metodologías que, al considerar varios factores, permiten decidir directamente la política de mantenimiento a seguir en cada situación específica; la segunda estrategia, de mucho auge en la actualidad, consiste en la determinación del nivel de criticidad de cada activo dentro del proceso productivo para luego, en función de éste, asignar la política de mantenimiento que resulte pertinente. Metodologías para la selección directa del tipo de mantenimiento En la literatura se pueden encontrar métodos que pueden ayudar en la selección de políticas y acciones de mantenimiento económicamente efectivas como los empleados para la optimización del mantenimiento, dentro de éstos se destacan el procedimiento de la filosofía RCM (Reliability Centered Maintenance), el referido al Análisis Multicriterio [Alsyouf, 2004; De Freitas Cordeiro, 2005; Toskano Hurtado, 2005; Forslund, 2006; Alfonso Llanes et al., 2008d], y el correspondiente al Sistema Alterno de Mantenimiento (SAM) [Portuondo Pichardo et al., 1989; De la Paz Martínez, 1996; Aguilera Martínez, 2001] utilizado en varias industrias cubanas. Otra de las metodologías empleadas es el análisis del riesgo asociado a los diferentes modos de fallos que se pueden presentar en dichos equipos, todo ello llevado a cabo a través de la llamada “Matriz de Riesgo” [Yañez Medina, Gómez de la Vega, y Valbuena Chourio, 2004; García González-Quijano, 2004; HM Treasury, 2006]. Finalmente se presentan las estrategias de selección basadas en elementos económicos, desarrolladas con el fin de garantizar que el criterio de mantenimiento empleado en cada equipo (correctivo, preventivo o predictivo) garantice las mayores utilidades (ahorros) [Marín, 1994; Lofsten, 1999; Sondalini, 2002; Thompson, 2004 y Alsyouf, 2004]. Metodologías para la selección basadas en la clasificación del equipamiento (Análisis de Criticidad) El análisis de criticidad es una metodología que permite establecer la jerarquía o prioridades de procesos, sistemas y equipos, creando una estructura que facilita la toma de decisiones acertadas y efectivas, direccionando el esfuerzo y los recursos en áreas donde sea más importante y/o necesario mejorar la confiabilidad operacional, basado en la realidad actual [Huerta Mendoza, 2001; Christensen, 2006; Alfonso Llanes et al., 2006d; Alfonso Llanes et al., 2007; Alfonso Llanes et al., 2008d; Alfonso Llanes et al., 2008h]. La clasificación de un componente como crítico supondrá la exigencia de establecer alguna tarea eficiente de mantenimiento preventivo que permita atajar sus posibles causas de fallo. En la tabla 1.2 se muestran las diferentes clasificaciones del equipamiento propuestas en la literatura consultada.. 8.

(28) Tabla 1.2 Clasificación del equipamiento Fuente MINBAS [1986] Ochoa Crespo [1994]. Vinicius Lucatelli y García Ojeda [1995]. De la Paz Martínez [1996] González Danger y Hechavarría Pierre [2002] Torres [2003] Torres [1997] Huerta Mendoza [2001] García Garrido [2003] Yañez Medina [2004] Cardoso de Morais [2004] Borroto Pentón [2005] Christensen [2006]. Clasificación Fundamentales para la producción No fundamentales en la producción Máxima categoría Categoría media Categoría regular Categoría mínima De soporte directo a la vida Con sustitución periódica y obligatoria de piezas Que ofrece altos niveles de energía Con intervalo de mantenimiento normalizado Muy importantes o fundamentales Normales o convencionales Auxiliares Importancia A Importancia B Importancia C Alta criticidad (clase A) Mediana criticidad o importantes (Clase B) Baja criticidad o prescindibles (Clase C). Fuente: adaptada de Borroto Pentón [2005] El método clásico de evaluación de la criticidad de los componentes de un sistema se realiza normalmente mediante la técnica de Análisis de los Modos de Fallo y sus Efectos (FMEA, Failure Mode and Effect Análysis) y, en otros casos, mediante la herramienta de análisis de Modos de Fallo y Criticalidad (FMECA, Failure Modes, Effects and Criticality Analysis) [Fernández Pérez et al., 2003; García González-Quijano, 2004; Ojeda, 2006]. El método más generalmente utilizado para realizar la jerarquización de los elementos dentro de un sistema productivo o de servicios es el empleo de un grupo de factores, criterios o variables que caractericen su contexto operacional, valorando las consecuencias que sobre cada una de ellas genera cada modo de fallo que se presente. En el anexo 1 se muestra un resumen de las propuestas realizadas por diferentes autores e instituciones concernientes a la realización del análisis de criticidad. Existe un grupo de estos criterios que son comunes a la mayoría de las propuestas, dígase: seguridad, impacto ambiental, costo de reparación, pérdida de producción y tiempo de reparación.. 9.

(29) Estas propuestas adolecen de no considerar la ocurrencia potencial de fallos o interrupciones simultáneas (fallos múltiples), las cuales pudieran ser, en conjunto, de mayor criticidad aunque, por lo general, se trate de equipos de baja criticidad individual, y es necesario realizarle adecuaciones para el caso de operaciones de procesos continuos. A continuación se presenta la propuesta realizada por Alfonso Llanes [2008h] la cual servirá de guía para el proceso de toma de decisiones sobre el que se basará el funcionamiento del software a diseñar y desarrollar en la investigación. A continuación se definen las variables consideradas en el algoritmo de decisión, así como los posibles efectos (niveles) que, ante un fallo del equipamiento, se pueden presentar en cada una de ellas. Seguridad: capacidad del fallo de ocasionar daño a las personas que se encuentran en la zona donde opera el equipo o en general al medio ambiente. Nivel 1: el fallo del equipo provoca efectos graves sobre los operarios y/o sobre el medio ambiente. Nivel 2: el fallo del equipo trae consigo riesgos para los operarios y/o para el medio ambiente. En la tabla 1.3 se muestran las características a considerar en estos dos niveles. Nivel 3: el fallo del equipo no trae riesgos para los operarios ni afecta al medio ambiente. Tabla 1.3 Características de los niveles de la variable Seguridad. Efectos graves. Riesgos. Medio ambiente - El fallo provoca afectaciones al medio ambiente que, además, pueden ocasionar enfermedades a los operarios que laboran en el área. - El fallo ocasiona una contaminación fuera de las especificaciones permisibles. - Las consecuencias del fallo provocan alguna contaminación medioambiental pero dentro de los límites permisibles.. Operarios - El fallo causa la muerte del operario. - El fallo inhabilita totalmente al operario para seguir laborando. - Las consecuencias del fallo causar algunos de los definidos en la empresa sin causar efectos graves operario.. pueden riesgos llegar a en el. Fuente: Alfonso Llanes [2008]. Calidad: nivel de afectación a la calidad del producto que conlleva el fallo del equipo. Nivel 1: el fallo del equipo provoca producciones defectuosas sin posibilidades de reprocesamiento. Nivel 2: el fallo del equipo afecta la calidad del producto pero el mismo puede ser reprocesado. Nivel 3: el fallo del equipo afecta ligeramente o no afecta la calidad del producto.. 10.

(30) Régimen de trabajo: cantidad de tiempo que opera el equipo en la jornada de trabajo. Para llevar a cabo la clasificación de esta variable se propone emplear el criterio “tasa de utilización (tu)”, el cual puede agravar o reducir la incidencia del fallo sobre la misma. Nivel 1: el equipo es utilizado intensivamente (. t Nivel 2: el equipo es utilizado medianamente ( t. U U. ≥ tU ) 2. ≤ tU < t U ). Nivel 3: el equipo es de uso ocasional o de baja utilización (. t. U. < tU. 2. ). Afectaciones: se asocia al efecto del fallo del equipo en el proceso y su capacidad de interrumpirlo de forma total o parcial. Nivel 1: el fallo del equipo provoca la interrupción total de la producción/servicio. Esta situación se puede ocasionar cuando se presenta alguna de las situaciones siguientes: • El fallo del equipo inhabilita al equipo o a la instalación. • El fallo se presenta en el equipo limitante de la planta o en un equipo de una línea de producción continua. • El equipo que falla es redundante y existe la probabilidad de un fallo múltiple. La probabilidad de que se produzca un fallo múltiple durante un período dado está regida por la situación donde falla el equipo de reserva (B) mientras el equipo base (A) aún se encuentra averiado, o sea, el Tiempo Medio Para Reparación del equipo base (A) es mayor que el Tiempo Medio Entre Fallos del equipo de reserva (B) [TMPRA>TMEFB]. En los casos donde exista más de un equipo de reserva se realizaría este análisis a través del tratamiento que se le da a las configuraciones stand by con múltiples máquinas [Baraza Calvo, 2003]. Nivel 2: el fallo del equipo provoca la interrupción de un sistema o unidad importante. Nivel 3: el fallo del equipo no afecta la producción/servicio. Esta situación se puede ocasionar cuando ocurre alguna de las situaciones siguientes: • El fallo se presenta en un equipo auxiliar o en un equipo cuyo nivel de utilización es medio o bajo (posee capacidad suficiente para reestablecer el fallo sin afectar el resultado final de la producción/servicio). • El fallo se presenta en un equipo redundante y su falla no afecta el proceso de producción/servicio. Esta situación se presenta cuando el Tiempo Medio Para Reparación del equipo base (A) es menor que el Tiempo Medio Entre Fallos del equipo de reserva (B) [TMPRA<TMEFB], o sea, el equipo de reserva asume la producción mientras al equipo base se le reestablecen sus condiciones de funcionamiento. En los casos donde exista más de un equipo de reserva se realizaría este análisis a través del tratamiento que se le da a las configuraciones stand by con múltiples máquinas [Baraza Calvo, 2003].. 11.

(31) Frecuencia de fallos: cantidad de fallos de cualquier componente del sistema por período de utilización (fallos/unidad de tiempo). Para la evaluación de esta variable se utilizará el indicador “tasa de fallos (λ)”, la cual está dada por el número de fallos que se generan en un determinado período (se recomienda utilizar el período de un año). Nivel 1: muchas paradas ocasionadas por los fallos ( λ > λ ). Nivel 2: paradas ocasionales ( λ 2 ≤ λ ≤ λ ). Nivel 3: paradas poco frecuentes ( λ < λ 2 ). Tiempo de reparación: tiempo necesario para reparar el fallo. Nivel 1: el tiempo promedio de reparación del equipo ante un fallo es elevado ( TMPR > TMPR ) Nivel 2: el tiempo promedio de reparación del equipo ante un fallo es moderado ( TMPR /2≤TMPR ≤ TMPR ) Nivel 3: el tiempo promedio de reparación del equipo ante un fallo es pequeño (TMPR< TMPR /2) Costo de reparación: costo asociado a la reposición del estado de funcionamiento del elemento que ha fallado (costo del fallo) Nivel 1: el costo promedio de reparación del equipo ante un fallo es elevado (Cr > Nivel 2: el costo promedio de reparación del equipo ante un fallo es moderado (. c. c r. r. ). /2≤ Cr ≤. Nivel 3: el tiempo promedio de reparación del equipo ante un fallo es pequeño (Cr<. c. r. c. r. ). /2).. Como se ha podido observar en las variables régimen de trabajo, tiempo de reparación y costo de reparación se ha utilizado la estimación de la media en la caracterización de cada uno de sus niveles, sin embargo, esta medida puede verse afectada por la presencia de valores extremos en el conjunto de datos analizados. Para el tratamiento (detección) de este tipo de valores se propone emplear el Criterio Variacional de Dixon [Dixon y Massey, 1976]. En el caso de que un determinado valor “X” sea catalogado como extremo, entonces no se consideraría en el cálculo de la media aunque sí se tendría en cuenta a la hora de determinar el nivel que en el equipo que se esté analizando alcanzaría dicha variable. Se tomará un año como período de tiempo para el cálculo de los diferentes parámetros (Cr, tu, λ, TMEF, TMPR) que caracterizan a cada variable. Un elemento importante a considerar cuando se realizan análisis de este tipo, relativos al equipamiento productivo, lo constituye el tipo de producción continua dado que en estos. 12.

(32) sistemas es necesario analizar la línea de producción como una sola máquina debido a la interdependencia y sincronización que existe entre los diversos equipos que la conforman, pues el fallo de uno de ellos causa la parada total del proceso sin importar la posición que ocupe en la línea, a menos que se disponga de unidades de reserva para cubrir los picos de demanda. Estas características de la producción continua van a surtir efectos en varias de las variables del algoritmo presentado, dígase: régimen de trabajo, afectaciones, calidad y frecuencia. La evaluación de cada variable precisa que la empresa disponga de un sistema de estadística de fallos fiable, lo cual permitirá realizar cálculos “exactos y absolutos”; sin embargo, desde el punto de vista práctico, dado que pocas veces se dispone de una data histórica de excelente calidad, el análisis de criticidad permite trabajar en rangos, es decir, establecer cuál sería la condición más favorable, así como la condición menos favorable de cada uno de los criterios a evaluar. 1.4 Las herramientas informáticas en la gestión del mantenimiento El desarrollo y posterior implantación de una herramienta informática para apoyar el proceso de toma de decisiones sobre el tipo de mantenimiento a aplicar al equipamiento productivo en la empresa, representa para ésta una mejora tecnológica y organizativa. Para ello la informatización del mantenimiento debe estar orientada a desempeñar varias funciones principales: •. La entrada, salvaguarda y gestión de toda la información relacionada con el mantenimiento de forma que pueda ser accesible en cualquier momento de uno u otro modo.. •. Permitir la planificación y control del mantenimiento, incluyendo las herramientas necesarias para realizar esta labor de forma sencilla.. •. Suministro de información procesada y tabulada de forma que pueda emplearse en la evaluación de resultados y servir de base para la correcta toma de decisiones.. Una herramienta informática, si es suficientemente flexible, puede adaptarse a los procesos de la propia empresa, permitiendo organizar y controlar el trabajo administrativo, también reduce el tiempo de trabajo burocrático [Martín Montoliu & Elaine Kepcia, 1995]. La incorporación de la informática al mantenimiento trae consigo varias ventajas, entre ellas se pueden citar las siguientes [Benaim et al., 1994] : •. Facilita la planificación del mantenimiento.. 13.

(33) •. Simplifica y optimiza el control de costos.. •. Mejora el control de los trabajos.. •. Facilita el manejo, control y documentación del espacio.. •. Mejora la adquisición, manejo y aprovechamiento de los recursos.. •. Permite tener información actualizada y rápidamente accesible para la toma de decisiones.. •. Facilita el análisis de alternativas y la confección de estadísticas.. •. Permite el control a distancia de los sistemas, mejorando la rapidez y eficacia.. Otro asunto a considerar es la selección del sistema informático más adecuado. Algunos autores como Pérez Tejeda [1992], Treto Cárdenas & Navarrete Pérez [1993], Ibáñez, del Olmo & Hernández [1992], Benaim et al. [1994], Fuertes, del Olmo & Hernández [1994], Brenes Trejo [2000], Lourival Tavares [1999] se refieren a la importancia y las razones para la elección de un software para la gestión de mantenimiento y las ventajas que reporta la aplicación del mismo. Gil Diez-Ticio & Madurga Rivera [1994], plantean que la elección de un adecuado software es una de las decisiones más importantes a ser tomada en la política de desarrollo de mantenimiento. Existen en el mercado numerosas aplicaciones informáticas de mantenimiento, pero la implantación de cualquiera de ellas, es una tarea ardua cuya duración se estima en seis meses como promedio. Según Lourival Tavares & Silva Filho [2003] se comercializan en el mundo más de 300 software específicos de mantenimiento; este mercado representó en 1997 más de 900 millones de dólares, el 56.6 % en EUA, el 27.5 % en Europa, el 10.3 % en Asia y Oceanía y el 5.7 % en América Latina. En Cuba se conocen muy pocas herramientas informáticas en el área de mantenimiento. Es conocido que en el Centro de Estudio de Ingeniería de mantenimiento (CEIM), perteneciente al Instituto Superior Politécnico “José Antonio Echeverría”, se ha desarrollado un software para ayudar en la resolución de problemas técnicos y de gestión de mantenimiento conocido por el nombre de Mantenimiento Asistido por Computadora sobre Windows (MacWin) que es aplicado actualmente en hospitales, entidades productivas y de prestación de servicios, según Barrios Arias [1996], Vicent Hernández [1996] y MacWin [2009]. Para el caso concreto de la metodología para la selección basadas en la clasificación del equipamiento (Análisis de Criticidad) no existen herramientas informáticas que soporten su. 14.

(34) aplicación por lo que el autor considera que el desarrollo y posterior implementación de una herramienta que tenga en cuenta el Análisis de Criticidad para la clasificación del equipamiento y posterior selección del tipo de mantenimiento a aplicar constituye una prioridad. 1.4.1. El proceso de desarrollo del software. Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente. Dicho proceso, en términos globales se muestra en la figura 1.5. Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas [Sommerville ,2002]. Aunque un proyecto de desarrollo de software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniería, en el desarrollo de software hay una serie de desafíos adicionales, relativos esencialmente a la naturaleza del producto obtenido. A continuación se explican algunas particularidades asociadas al desarrollo de software y que influyen en su proceso de construcción. Un producto software en sí es complejo, es prácticamente inviable conseguir un 100% de confiabilidad de un programa por pequeño que sea. Existe una inmensa combinación de factores que impiden una verificación exhaustiva de todas las posibles situaciones de ejecución que se puedan presentar (entradas, valores de variables, datos almacenados, software del sistema, otras aplicaciones que intervienen, el hardware sobre el cual se ejecuta, etc.).. Figura 1.5: Proceso de desarrollo de software (Fuente: Jacaboson [2000]). Un producto software es intangible y por lo general muy abstracto, esto dificulta la definición del producto y sus requisitos, sobre todo cuando no se tienen precedentes en productos software similares. Esto hace que los requisitos sean difíciles de consolidar tempranamente. Así, los cambios en los requisitos son inevitables, no sólo después de entregado en producto sino también durante el proceso de desarrollo. Además, de las dos anteriores, siempre puede señalarse la inmadurez de la ingeniería del software como disciplina, justificada por su corta vida comparada con otras disciplinas de la ingeniería. Sin embargo, esto no es más que un consuelo inútil.. 15.

(35) El proceso de desarrollo de software no es único. No existe un proceso de software universal que sea efectivo para todos los contextos de proyectos de desarrollo. Debido a esta diversidad, es difícil automatizar todo un proceso de desarrollo de software. A pesar de la variedad de propuestas de proceso de software, existe un conjunto de actividades fundamentales que se encuentran presentes en todos ellos [Sommerville ,2002]: 1. Especificación de software: se debe definir la funcionalidad y restricciones operacionales que debe cumplir el software. 2. Diseño e Implementación: se diseña y construye el software de acuerdo a la especificación. 3. Validación: el software debe validarse, para asegurar que cumpla con lo que quiere el cliente. 4. Evolución: el software debe evolucionar, para adaptarse a las necesidades del cliente. Además de estas actividades fundamentales, Pressman [1997] menciona un conjunto de “actividades protectoras” que se aplican a lo largo de todo el proceso del software. Ellas se señalan a continuación: •. Seguimiento y control de proyecto de software.. •. Revisiones técnicas formales.. •. Garantía de calidad del software.. •. Gestión de configuración del software.. •. Preparación y producción de documentos.. •. Gestión de reutilización.. •. Mediciones.. •. Gestión de riesgos.. Pressman [1997] caracteriza un proceso de desarrollo de software como se muestra en la figura 1.6. Los elementos involucrados se describen a continuación: •. Un marco común del proceso, definiendo un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos de software, con independencia del tamaño o complejidad.. 16.

(36) •. Un conjunto de tareas, cada uno es una colección de tareas de ingeniería del software, hitos de proyectos, entregas y productos de trabajo del software, y puntos de garantía de calidad, que permiten que las actividades. del marco de trabajo se adapten a las. características del proyecto de software y los requisitos del equipo del proyecto. •. Las actividades de protección, tales como garantía de calidad del software, gestión de configuración del software y medición, abarcan el modelo del proceso. Las actividades de protección son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.. Figura 1.6: Elementos del proceso del software (Fuente: Pressman [1997]). Otra perspectiva utilizada para determinar los elementos del proceso de desarrollo de software es establecer las relaciones entre elementos que permitan responder quién debe hacer qué, cuándo y cómo debe hacerlo [Letelier, 2003].. Figura 1.7: Relación entre elementos del proceso del software. Fuente: Letelier [2003].. 17.

(37) En la figura 1.7 se muestran los elementos de un proceso de desarrollo de software y sus relaciones. Así las interrogantes se responden de la forma siguiente: •. Quién: las personas participantes en el proyecto de desarrollo desempeñando uno o más roles específicos.. •. Qué: un artefacto 1 es producido por un rol en una de sus actividades. Los artefactos se especifican utilizando notaciones específicas. Las herramientas apoyan la elaboración de artefactos soportando ciertas notaciones.. •. Cómo y cuándo: las actividades son una serie de pasos que lleva a cabo un rol durante el proceso de desarrollo. El avance del proyecto está controlado mediante hitos que establecen un determinado estado de terminación de ciertos artefactos.. La composición y sincronía de las actividades está basada en un conjunto de principios y prácticas. Las prácticas y principios enfatizan ciertas actividades y/o la forma como deben realizarse, por ejemplo: desarrollar iterativamente, gestionar requisitos, desarrollo basado en componentes, modelar visualmente, verificar continuamente la calidad, gestionar los cambios, etc. 1.4.2. Modelos de proceso de software. Sommerville [2002] define a modelo de proceso de software como “una representación simplificada de un proceso de software, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstracción de un proceso real.” Los modelos genéricos no son descripciones definitivas de procesos de software; sin embargo, son abstracciones útiles que pueden ser utilizadas para explicar diferentes enfoques del desarrollo de software. A continuación se listan algunos ejemplos de modelos de proceso de software: •. Codificar y corregir.. •. Modelo en cascada.. •. Desarrollo evolutivo.. •. Desarrollo formal de sistemas.. 1. Un artefacto es una pieza de información que (1) es producida, modificada o usada por el proceso, (2) define un área de responsabilidad para un rol y (3) está sujeta a control de versiones. Un artefacto puede ser un modelo, o un elemento de modelo.. 18.

(38) •. Desarrollo basado en reutilización.. •. Desarrollo incremental.. •. Desarrollo en espiral.. ¿Cuál es el modelo de proceso más adecuado? Cada proyecto de software requiere de una forma particular de abordar el problema. Las propuestas comerciales y académicas actuales promueven procesos iterativos, donde en cada iteración puede utilizarse uno u otro modelo de proceso, considerando un conjunto de criterios (Por ejemplo: grado de definición de requisitos, tamaño del proyecto, riesgos identificados, entre otros). En la tabla 1.4 se expone una comparación de los modelos de proceso de acuerdo con algunos criterios básicos para su selección. Tabla 1.4.Comparación entre los modelos de proceso de software. Modelo de proceso. Funcionamiento con requisitos y arquitectura no predefinidos. Producción de software altamente fiable. Gestión de riesgos. Forma en que permite correcciones sobre la marcha. Visión del progreso por el cliente y el jefe del proyecto. Codificar y corregir. Bajo. Bajo. Bajo. Alta. Media. Cascada. Bajo. Alto. Bajo. Baja. Baja. Evolutivo exploratorio. Medio o alto. Medio o alto. Medio. Media o alta. Media o Alta. Evolutivo prototipado. Alto. Medio. Medio. Alta. Alta. Desarrollo formal de sistemas. Bajo. Alto. Medio. Baja. Baja. Desarrollo orientado a reutilización. Medio. Bajo a Alto. Medio. Alta. Alta. Incremental. Bajo. Alto. Medio. Baja. Baja. Espiral. Alto. Alto. Alto. Media. Media. Fuente: Elaboración propia.. 19.

(39) Después de haberse realizado un estudio exhaustivo de los diferentes modelos de proceso de desarrollo de software se escogió el “Modelo en Cascada” por ser el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalización de la etapa anterior. De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado. Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy. Para un mejor entendimiento del mismo se exponen sus características en el epígrafe siguiente. 1.4.3. Modelo en cascada. El primer modelo de desarrollo de software que se publicó, se derivó de otros procesos de ingeniería [Royce, 1970]. Éste toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y las representa como fases separadas del proceso. El modelo en cascada consta de las fases siguientes: 1. Definición de los requisitos: los servicios, restricciones y objetivos son establecidos con los usuarios del sistema. Se busca hacer esta definición en detalle. 2. Diseño de software: se particiona el sistema en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los componentes del sistema. 3. Implementación y pruebas unitarias: construcción de los módulos y unidades de software. Se realizan pruebas de cada unidad. 4. Integración y pruebas del sistema: se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente. 5. Operación y mantenimiento: generalmente es la fase más larga. El sistema es puesto en marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de implementación. Se identifican nuevos requisitos. La interacción entre fases puede observarse en la figura 1.8. Cada fase tiene como resultado documentos que deben ser aprobados por el usuario. Una fase no comienza hasta que termine la fase anterior y. generalmente se incluye la. corrección de los problemas encontrados en fases previas.. 20.

(40) Figura 1.8. Modelo de desarrollo en cascada (Fuente: Elaboración Propia). En la práctica, este modelo no es lineal, e involucra varias iteraciones e interacción entre las distintas fases de desarrollo. Algunos problemas que se observan en el modelo de cascada son: •. Las iteraciones son costosas e implican rehacer trabajo debido a la producción y aprobación de documentos.. •. Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con las siguientes fases.. •. Los problemas se dejan para su posterior resolución, lo que lleva a que estos sean ignorados o corregidos de una forma poco elegante.. •. Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario por el largo tiempo de entrega del producto.. •. Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difícil responder a cambios en los requisitos.. Este modelo sólo debe usarse si se entienden a plenitud los requisitos. Aún se utiliza como parte de proyectos grandes.. 21.

(41) 1.5 Conclusiones parciales 1. En la bibliografía consultada se exponen un gran número de sistemas de mantenimiento pero la mayoría de los autores referidos consideran evidente que, a nivel empresarial, no se debe optar por uno solo de ellos, sino que deben aplicarse varios en función del contexto operacional en que se desempeñe cada equipo, apoyándose en herramientas informáticas que permitan apoyar el proceso de toma de decisiones. 2. La literatura científica consultada muestra las ventajas que ofrece el disponer de herramientas informáticas para gestionar el mantenimiento en las organizaciones, sin embargo el proceso de desarrollo de estas como de cualquier producto informático transcurre por etapas diferentes que se definen en los modelos de proceso de software, siendo el modelo en cascada uno de los de mayor factibilidad de aplicación a los efectos de esta investigación. 3. El “Modelo en Cascada” al ser un enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalización de la etapa anterior permite ejecutar de forma adecuada las etapas que contempla el procedimiento para apoyar el proceso de toma de decisiones sobre el tipo de mantenimiento a aplicar al equipamiento productivo propuesto por Alfonso Llanes [2008]. 4. De la revisión bibliográfica realizada se pudo constatar la carencia de herramientas informáticas que permitan sustentar el proceso de toma de decisiones sobre el tipo de mantenimiento a aplicar al equipamiento productivo, de ahí la importancia de desarrollar un software con este fin y lo acertado de la selección del problema científico a resolver en está investigación.. 22.

(42) Capítulo 2.

(43) 2.1 Introducción El proceso de desarrollo de software para el caso específico de la herramienta que informatiza la metodología para la selección del tipo de mantenimiento basado en la clasificación del equipamiento (Análisis de Criticidad) resulta de importancia vital dado que dicha actividad no dispone de un software que facilite su realización. La aplicación de forma manual del procedimiento para determinar el tipo de mantenimiento se hace demasiado engorrosa y atenta contra su aplicación efectiva. Debido a está situación fue necesario seleccionar un procedimiento de desarrollo de software que permitiera la correcta realización de una herramienta informática destinada a agilizar el proceso de captación, procesamiento y obtención de los resultados. Para dar cumplimiento a este objetivo se seleccionó la Metodología de Desarrollo en Cascada por ser el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software. Las diferentes fases o etapas de este modelo de desarrollo se exponen a continuación. 2.2 Definición de los requisitos La fase de definición de requisitos se divide en dos fases: análisis de requisitos de usuario y análisis de requisitos de software. La fase de análisis de requisitos de usuario (epígrafe 2.2.1) tiene como objetivo conocer las necesidades de los usuarios y cuáles deben ser los servicios que un sistema de software debe ofrecerles para satisfacerlas. La fase implica la creación de los requisitos de usuario (RU) que constituye la base para que, al final del desarrollo, el sistema sea aceptado por el usuario. La fase de análisis de requisitos del software (RS) (epígrafe 2.2.2) consiste en la construcción de un modelo lógico del sistema de software describiendo las funciones que sean necesarias (sin tomar ninguna decisión sobre cómo implementarlas) y las relaciones entre ellas suponiendo que no existen limitaciones de recursos. 2.2.1 Requisitos de usuario (RU) El desarrollo de una herramienta informática para el caso específico de la metodología para la selección del tipo de mantenimiento basado en la clasificación del equipamiento (Análisis de Criticidad) debe cumplir con los requerimientos siguientes:. 1. Crear un sistema de software que permita calcular el nivel de criticidad del equipamiento productivo empleando para ello la metodología anteriormente mencionada.. 23.

(44) 2. El sistema debe poseer una interfaz sencilla que permita a los usuarios familiarizarse con su uso en poco tiempo. 3. El sistema debe permitir la captación y procesamiento de los datos y la obtención de los resultados de una forma rápida y fiable. 4. El sistema debe aplicar para el tratamiento (detección) de valores extremos del Criterio Variacional de Dixon [Dixon y Massey, 1976]. 5. El sistema debe permitirle al usuario obtener e imprimir reportes sobre el nivel de criticidad que posee el equipamiento procesado. Por otra parte, el sistema debe ser capaz de implementar cada una de las etapas y pasos de la metodología propuesta descrita en el capítulo 1 de esta investigación. 2.2.2 Requisitos de software (RS) El propósito que tiene es describir y formalizar aquellos requisitos que ha de cumplir el sistema a desarrollar, es decir, qué tiene que hacer el sistema y de qué manera desde el punto de vista del cliente. Ámbito del sistema El sistema a construir deberá ser capaz de captar, procesar y obtener los resultados sobre el cálculo del nivel de criticidad y la clasificación del tipo de fallo en el equipamiento industrial. El ámbito del sistema desarrollado llega hasta la realización del sistema en sí y las bases de datos que sean necesarias para dicho funcionamiento. Descripción general El sistema de gestión de mantenimiento – módulo criticidad implementará la metodología para la selección del tipo de mantenimiento basado en la clasificación del equipamiento (Análisis de Criticidad). El sistema deberá interactuar con el usuario, entendiéndose por usuario a aquel que manipulará el software en búsqueda de los resultados que le permitan seleccionar el tipo de mantenimiento a aplicar en su organización. Funciones de acceso a la información El sistema tendrá acceso a una base de datos centralizada y replicada en cada uno de los clientes para así, ante cualquier eventualidad, ésta funcione en forma independiente. La herramienta deberá contemplar accesos a la base de datos para actualizar y obtener reportes. 24.