Tesis Final.docx

UNIVERSIDAD NACIONAL DE SAN AGUSTIN DE AREQUIPA

FACULTAD DE PRODUCCION Y SERVICIOS

ESCUELA PROFESIONAL DE INGENIERIA INDUSTRIAL

“CONTRUCCION DE UN SISTEMA DE INFORMACION PARA LA

GESTION DEL MANTENIMIENTO DE UN TALLER DE MAQUINARIA

PESADA”

Tesis para optar por el Título de Ingeniero Industrial

PRESENTADO POR:

Kevin Jordan Rosas Rondón

LIMA-PERU

2015

Executive Summary

This project involves the development of an information system (CMMS) to manage major

components in a workshop that perform maintenance to heavy equipment specialized in

the shotcrete industry. This system will allow the storage of delivery times per each activity

in the maintenance process, tracking works performed in each major component during

lifetime, follow-up of the service requisition and work orders and finally reporting

quantifiable key performance indicators to help decision making in the management.

Resumen

El presente proyecto se enfoca en el desarrollo de un sistema de información (CMMS)

para la gestión de componentes mayores en un taller de maquinaria pesada especializado

en equipos utilizados en la industria del shotcrete. Este sistema permitirá el registro de

tiempo de entrega por actividad de mantenimiento, mejor trazabilidad de los trabajos de

mantenimiento realizados a componentes mayores, seguimiento eficaz de las ordenes de

servicio y ordenes de trabajo en proceso y finalmente reportar indicadores de desempeño

cuantificables y medibles a través del tiempo.

CAPITULO IV CONSTRUCCION Página 2

ASPECTO METODOLOGICO

Tipo de Estudio: Estudio descriptivo

Se analiza y se modela en sistema de gestión del mantenimiento empleado en un

taller de maquinaria pesada.

Método de la investigación: Método de análisis

Según la experiencia laboral en un taller de maquinaria pesada se pudo observar

los procedimientos de gestión y participar en los procesos de mejora. A partir de

esta observación inicial, se identificaron las entidades que participan en la gestión

y se modelaron las relaciones existentes, los requerimientos del sistema y las

ventajas de un sistema de información.

Técnicas para la recopilación de la información: Información secundaria

La principal fuente de información fue la recopilada mediante información

secundaria provistas por el tesista en su labor de asistente de la jefatura del taller

de mantenimiento de un taller de maquinaria pesada, en la cual se recopilo:

o Bases de datos de Ordenes de mantenimiento

o Bases de datos de control de la mano de obra

o Recopilación de las recetas de repuestos por componentes y/o equipos

o Sistema de codificación de componentes y/o equipos

o Manuales de modelos de equipos

Tratamiento de la información

La información recopilada fue organizada, clasificada en entidades o tablas

normalizadas que permitieran la formulación de una base de datos relacional para

ingresar, actualizar la información requerida por los procesos de recepción,

solicitud, trabajo y despacho de los componentes del taller y posteriormente tener

la data necesaria para generar los reportes o salidas de información que requiera

la jefatura del taller para la toma de decisiones.


PLANTEAMIENTO DEL PROBLEMA

El problema que se pudo observar en el taller de maquinaria pesada son los

siguientes:

PROBLEMA CONSECUENCIAS

No se conoce el tiempo de entrega de

cada actividad de mantenimiento.

No se conoce ni se puede estimar la

carga de trabajo a realizar.

No se puede generar planes de mejora

puesto que no se tienen mediciones del

proceso.

Incumplimiento de tiempos de entrega.

Programación errada de los futuros trabajos de

mantto.

Sobreesfuerzo, exceso de horas extra y tiempo

ocioso.

Trabajos o solicitudes olvidados atendidas a

última hora.

Toma de decisiones sujeta a incertidumbre.

OBJETIVOS

Objetivo General

Diseñar un sistema de información para la gestión del mantenimiento (Computer

Maintenance Management System o CMMS por sus siglas en ingles) para una

empresa que brinda servicios de mantenimiento de equipos de maquinaria pesada.

Objetivos específicos

ASPECTO OBJETIVOS

ENTRADA DE

INFORMACION

Generar la capa de presentación (interfaz de usuario) para el registro de

las recepciones y despachos de componentes y equipos, registro de

órdenes de mantenimiento, ordenes de servicio.

PROCESAMIENTO

LOGICO DE

DATOS

Generar las reglas de decisión y cálculos para el procesamiento de la

información.

ALMACENAMIENT

O

Crear la estructura de la base de datos para el registro de órdenes de

Mantenimiento, ordenes de Servicio, recepciones de componentes,

despachos de componentes, componentes con vida propia.

SALIDA DE

INFORMACION

Generar la estructura de reportes de indicadores KPI del taller (grado de

utilización de la MO, capacidad de la MO, eficiencia de la MO, OT

atendidas, OS generadas, OT pendientes, Horas hombre promedio por

mantenimiento de componente.)

SOPORTE Generar la documentación de soporte respectiva de las diferentes


DOCUMENTARIO etapas de desarrollo del sistema.

HIPOTESIS

La implementación de un sistema de gestión de órdenes de mantenimiento

brindará a la organización:

Tiempos de entrega por actividad de mantenimiento.

Trazabilidad de los trabajos de mantenimiento realizados a componentes con

vida propia.

Seguimiento eficaz de las órdenes de servicio y órdenes de trabajo pendientes.

Indicadores de desempeño cuantificable y medible a través del tiempo.


Agradecimiento

A Dios, por la fuerza y la fe para culminar este proyecto importante de mi vida.

A Victor, mi padre, mi mejor amigo: por tu apoyo y confianza

depositada. Con este proyecto logro demostrarte el cumplimiento y compromiso

absoluto con todos mis proyectos.

A Karolam, mi hermana, por su compañía y afecto: siempre estarán grabados en mi

memoria los momentos compartidos en nuestra infancia.

A todos aquellos quienes han impulsado en mí el deseo de aprender nuevas tecnologías

que han servido a la gestión.

Y a ti madre: porqué sé que este es el premio que tanto estabas esperando por tu

dedicación, entrega y coraje por haber llevado a tus hijos por el buen camino criándolos

en un clima de paz y amor.

.

Contenido


Lista de Figuras................................................................................................................................ 10

Lista de tablas.................................................................................................................................. 12

1. CAPITULO I Generalidades.....................................................................................................13

1.1 Definición del problema....................................................................................................13

1.1 Marco Conceptual............................................................................................................17

1.1.1 Industria de Shotcrete...............................................................................................17

1.2 Estado del arte.................................................................................................................28

1.2.1 Conceptos básicos...................................................................................................28

1.2.2 Importancia y Beneficios de los sistemas de información.........................................30

1.2.3 Tipos de Sistemas....................................................................................................32

1.3 Descripción de la solución................................................................................................38

1.3.1 Sistemas de información gerencial para la gestión del mantenimiento, CMMS........39

1.4 Plan de Proyecto..............................................................................................................42

1.4.1 Selección de la Metodología de desarrollo...............................................................42

1.4.2 Selección de la herramienta Metodológica...............................................................50

2. CAPITULO II ANALISIS...........................................................................................................51

2.1 Análisis de las necesidades del cliente.............................................................................51

2.2 Análisis del proceso..........................................................................................................53

2.2.1 Estructura organizacional de un taller de maquinaria pesada..................................53

2.2.2 Layout general del taller de mantenimiento..............................................................55

2.2.3 Equipos empleados para el mantenimiento..............................................................57

2.2.4 Componentes con vida propia..................................................................................61

2.2.5 Flujo de trabajo para el mantenimiento de componentes.........................................68

2.2.6 Procesos de mantenimiento de maquinaria pesada.................................................69

2.3 Análisis de requerimientos................................................................................................73

Requerimientos Funcionales....................................................................................................74

Requerimientos no funcionales................................................................................................75

Consideraciones sobre el sistema............................................................................................76

2.4 Análisis Técnico – Económico..........................................................................................77


2.4.1 Análisis técnico.........................................................................................................77

2.4.2 Análisis Económico...................................................................................................79

2.5 Análisis de riesgos............................................................................................................85

Tipos de riesgo......................................................................................................................... 85

Listado de riesgos....................................................................................................................87

3. CAPITULO III DISEÑO.............................................................................................................89

3.1 Arquitectura de la solución...............................................................................................89

3.1.1 Representación de la arquitectura............................................................................89

3.1.2 Diseño de la arquitectura de la solución...................................................................95

3.1.3 Diagrama de clases de diseño................................................................................100

3.1.4 Diagrama de bases de datos..................................................................................110

3.1.5 Diagrama de secuencia..........................................................................................118

3.1.6 Evaluación de la Arquitectura.................................................................................128

3.2 Diseño de la interfaz grafica...........................................................................................129

3.2.1 Estándar de interfaz grafica....................................................................................129

4. CAPITULO IV CONSTRUCCION...........................................................................................136

4.1 Construcción...................................................................................................................136

4.1.1 Framework de desarrollo........................................................................................138

4.1.2 Lenguaje de programación.....................................................................................139

4.1.3 Mapeo Objeto - Relacional.....................................................................................141

4.1.4 IDE.......................................................................................................................... 144

4.1.5 Motor de Bases de datos........................................................................................146

4.1.6 Otras herramientas y librerías.................................................................................148

4.2 Pruebas.......................................................................................................................... 150

4.2.1 Estrategia de Prueba..............................................................................................150

4.2.2 Tipos de Pruebas....................................................................................................150

4.2.3 Catálogo de pruebas..............................................................................................153

4.2.4 Resultados de pruebas...........................................................................................159

5. CAPITULO V OBSERVACIONES, CONCLUSIONES Y RECOMENDACIONES.................160


5.1 Observaciones................................................................................................................160

5.2 Conclusiones..................................................................................................................162

5.3 Recomendaciones..........................................................................................................163

6. BIBLIOGRAFIA....................................................................................................................... 164

7. ANEXOS................................................................................................................................ 166

7.1 Los 12 principios de la metodología ágil.........................................................................166

7.2 Calculo de la energia......................................................................................................167

7.3 Objetos LINQ to SQL......................................................................................................168


Lista de Figuras

Ilustración 1 Aplicacion de shotcrete....................................................................................9

Ilustración 2 Shotcrete en minas subterráneas...................................................................10

Ilustración 3 Shotcrete en túneles.......................................................................................10

Ilustración 4 Shotcrete en taludes.......................................................................................11

Ilustración 5 Shotcrete en canales......................................................................................11

Ilustración 6 Mantenimiento en la industria del shotcrete...................................................12

Ilustración 7 Logo de Robocon SAC..................................................................................15

Ilustración 8 Jerarquía de Sistemas....................................................................................18

Ilustración 9 Ciclo de Vida del Desarrollo de Sistemas......................................................30

Ilustración 10 Análisis de Sistemas orientado a objetos.....................................................32

Ilustración 11 Metodología Ágil de Desarrollo....................................................................35

Ilustración 12 Diagrama general de Caso de Uso del sistema...........................................36

Ilustración 13 Estructura Organizacional de un taller de maquinaria pesada.....................37

Ilustración 14 Layout del taller............................................................................................39

Ilustración 15 Equipos de shotcrete....................................................................................40

Ilustración 16 Bomba hidraulica A4VG125.........................................................................42

Ilustración 17 Bomba de giro de cuba A4VTG71................................................................42

Ilustración 18 Motor diesel BF4M2012C.............................................................................42

Ilustración 19 Flujo de trabajo.............................................................................................46

Ilustración 20 Tabla de evaluación de riesgos....................................................................59

Ilustración 21 Arquitectura del sistema...............................................................................61

Ilustración 22Objeto CLASESLINQ....................................................................................64

Ilustración 23LINQ.dbml......................................................................................................65

Ilustración 24 Entidad LINQ.dbml.......................................................................................65

Ilustración 25 Vista lógica...................................................................................................66

Ilustración 26 Vista de despliegue......................................................................................67

Ilustración 27 Diagrama de Clases.....................................................................................76

Ilustración 28 Diagrama Iniciar Sesión...............................................................................77

Ilustración 29 Diagrama Registrar Recepción....................................................................78

Ilustración 30 Diagrama Orden de Servicio........................................................................79

Ilustración 31 Diagrama Registrar Orden de trabajo..........................................................79

Ilustración 32 Vista Registrar Despachos...........................................................................80

Ilustración 33 Diagrama Asignaciones OS.........................................................................80


Ilustración 34 Vistas de la base de datos...........................................................................81

Ilustración 35 Esquema general de la base de datos.........................................................82

Ilustración 36 Diagrama de secuencia Insertar Codificación VP........................................84

Ilustración 37 Actualizar componente.................................................................................85

Ilustración 38 Insertar Equipo.............................................................................................86

Ilustración 39 Listar Equipos...............................................................................................87

Ilustración 40 Iniciar Sesión................................................................................................88

Ilustración 41 Patrón de diseño gráfico del sistema...........................................................95

Ilustración 42 Formulario de Mantenimiento de Equipos....................................................95

Ilustración 43 Datagridview para registrar Orden de Servicio.............................................97

Ilustración 44 Reporte de Recepciones..............................................................................98

Ilustración 45 Logo .NET Framework...............................................................................100

Ilustración 46 Logo de VB.net...........................................................................................101

Ilustración 47 Logo LINQ to SQL......................................................................................102

Ilustración 48 Select clause..............................................................................................103

Ilustración 49 Insert Clause...............................................................................................103

Ilustración 50 O/R Designer..............................................................................................104

Ilustración 51 Logo de Visual Studio 2012........................................................................105

Ilustración 52 Pantalla de trabajo de Visual Studio 2012..................................................105

Ilustración 53 Logo SQL Server 2012...............................................................................106

Ilustración 54 Pantalla de trabajo SQL Server 2012 Management Studio........................106

Ilustración 55 Vista previa de Report Viewer....................................................................107

Ilustración 56 Fuente: http://michaelbluejay.com/electricity/computers.html....................122

Ilustración 57 Plana tarifaria OSINERGMIN.....................................................................122


Lista de tablas

Tabla 1 Análisis Comparativo de Soluciones......................................................................27

Tabla 2 Headcount taller de maquinaria pesada................................................................38

Tabla 3 Equipos para Shotcrete.........................................................................................41

Tabla 4 Procesos de mantenimiento de equipos de maquinaria pesada...........................48

Tabla 5 Costo de RR.HH. del proyecto...............................................................................56

Tabla 6 Etapas del proyecto...............................................................................................57

Tabla 7 Uso de Recursos....................................................................................................57

Tabla 8 Estimación del costo de implementación del sistema............................................58

Tabla 9 Análisis de escenario por la implementación del sistema......................................58

Tabla 10 Listado de Riesgos...............................................................................................60

Tabla 11 Lista de Formularios.............................................................................................62

Tabla 12 Lista de Entidades................................................................................................63

Tabla 13 Paleta de colores de pantalla...............................................................................94

Tabla 14Especificaciones de diseño para datagridview.....................................................97

Tabla 15 Resumen de recursos de construcción................................................................99

Tabla 16 Pruebas unitarias Iniciar Sesion........................................................................111

Tabla 17 Pruebas Unitarias Componentes VP.................................................................111

Tabla 18 Pruebas unitarias Componentes........................................................................111

Tabla 19 Pruebas Unitarias Empleados...........................................................................112

Tabla 20 Pruebas unitarias Equipos.................................................................................112

Tabla 21 Pruebas Unitarias Asignaciones........................................................................112

Tabla 22 Pruebas Unitarias Recepcion............................................................................113


1. CAPITULO I Generalidades

En este capítulo se presentan el contexto de la problemática de la organización a la

cual se dará solución. Asimismo, se presenta un desarrollo conceptual de los temas a

desarrollar para la solución. Por último, se describe las principales metodologías de

desarrollo y se selecciona la metodología para el desarrollo del proyecto.

1.1 Definición del problema

Debido al avance de proyectos mineros de gran relevancia que son desarrollados

en nuestro país, existe un crecimiento paralelo de servicios que se brindan a los

operadores mineros, entre estos servicios se incluyen servicios de mantenimiento

de equipos y servicios auxiliares de operaciones.

Actualmente dicho rubro está atravesando una disminución de las utilidades

generadas por la venta de los minerales minados debido a una caída general del

precio de los comodities. Dicha caída impulsa la búsqueda de operaciones con

capital reducido. Es por ello que es tan importante incrementar la productividad

los servicios requeridos por estas entidades mineras ya sean gestionadas por el

dueño de la operación minera o tercearizadas a alguna entidad externa.

Las empresas que brindan estos servicios, como la que se ha analizado en el

presente estudio, tienen la necesidad de gestionar sus recursos eficientemente y

mantener un nivel de servicio de la calidad que brindan otras empresas en el

mercado para poder mantener y renovar constantemente la confianza de sus

usuarios, cualquier desinterés por mejorar la competitividad de sus servicios

impulsara una migración de la demanda hacia soluciones más eficientes que

brinda el mercado.

Consecuentemente, las empresas que brindan estos servicios buscan

herramientas que les permitan ser más eficientes en costos y aprovechar sus

recursos inteligentemente tomando decisiones y controlando al mayor detalle

posible sus operaciones.

Específicamente si nos centramos en el mercado de servicios en mantenimiento

de equipos mineros vemos que muchas empresas no están alineadas con este


objetivo de incrementar la eficiencia de sus operaciones y aun trabajan la gestión

de una manera manual desaprovechando los beneficios que nos brinda la

informática y los sistemas de gestión imposibilitando generar un ambiente propicio

para incrementar su eficiencia.

En conclusión, la problemática que se toma en consideración a través de la

siguiente investigación es la falta de implementación de herramientas informáticas

para organizaciones en crecimiento que brindan servicios de mantenimiento

específicamente en el rubro minero.


A continuación, se detalla el problema de los procesos de mantenimiento y se organiza a través de la siguiente tabla:

ENFOQUE CAUSA PROBLEMA CONSECUENCIAS

PLANEAMIENTO

No existen registros de los tiempos

reales de las órdenes de

mantenimiento de equipos y

componentes.

No existen registros de la mano de

obra empleada por cada actividad de

mantenimiento.

No existen registros de órdenes de

trabajo ni ordenes de servicio.

No se tienen tiempos estándar por

actividad de mantenimiento.

No se conoce el grado de

utilización de las HO-HM por

actividad de mantenimiento.

Estimación sesgada de tiempos de

entrega.

Inadvertencia de trabajos

pendientes de menor importancia.

Incumplimiento de tiempos de

entrega.

Programación errada de los futuros

trabajos de mantto.

Sobreesfuerzo, exceso de horas

extra y tiempo ocioso.

Trabajos o solicitudes olvidados

atendidas a última hora.

GESTION La empresa no cuenta con

indicadores clave de proceso, KPIs.

La gestión se mide de una manera

cualitativa y propensa a

subjetividades.

Toma de decisiones sujeta a

incertidumbre.

PERSONAS No se cuenta con un registro digital

del tareo del personal.

No se conoce la distribución de

personal ni las inasistencias

diarias.

No existe un sustento de las horas

extra laboradas.

Incoherencias al determinar el pago

de las horas extra.

Falta de control de inasistencias.

COSTOS Y

PRESUPUESTO

No se conoce el costo de la mano de

obra por orden de mantenimiento.

Las cotizaciones toman a la Mano

de Obra como un porcentaje fijo en

función de los repuestos utilizados.

Sobrestimación u subestimación del

costo real del Ho-Hm empleadas por

orden de mantto.

MANTENIMIENTO Falta de registros históricos de

órdenes de mantenimiento y de

No se analiza las causas de las Desconocimiento de la tarea de

mantenimiento y requerimientos de


componentes con vida propia.

Falta de trazabilidad de los


fallas de los componentes.

No existe órdenes de

mantenimiento.

No existe un análisis de fallas de


repuestos.

Imposibilidad de realizar planes de

prevención de fallas.


1.1 Marco Conceptual

En esta sección se amplía el marco teórico base para el desarrollo y comprensión

de la problemática.

1.1.1 Industria de Shotcrete

A. Definición y alcance

El shotcrete o concreto lanzado por el sistema de vía húmeda, consiste

en trasladar neumáticamente por una tubería, una mezcla de concreto a

la que se añade un aditivo acelerante que produce una fragua o

endurecimiento inicial muy rápido, éste producto se adhiere a la superficie

irregular de la mina, evitando accidentes por desprendimiento de la roca.

(UNICON, 2013).

Ilustración 1 Aplicación de shotcrete


B. Usos y Aplicaciones del shotcrete

Revestimiento y soporte de túneles en minas subterráneas.

Protección de rampas y accesos en minas subterráneas.

Revestimiento y soporte de túneles de centrales hidroeléctricas.

Estructuras con secciones curvas o que requieran ser construidas o

tratadas con concreto lanzado.

Protección del acero estructural.

Estabilización de taludes. Muros de contención.

Soporte en obras viales.

Refuerzo o reparación de estructuras de concreto deterioradas.

Recubrimiento de canales de agua y cunetas. Tanques de agua,

piscinas.

Ilustración 2 Shotcrete en minas subterráneas


Ilustración 3 Shotcrete en túneles

Ilustración 4 Shotcrete en taludes


Ilustración 5 Shotcrete en canales


C. Mantenimiento en la Industria de Shotcrete

Como en cualquier otro rubro, en la industria del Shotcrete es necesario

conservar el buen funcionamiento de los equipos para soportar un

periodo prolongado de operación.

Principalmente en nuestro medio, los talleres de mantenimiento realizan

el mantenimiento correctivo que es un tipo de mantenimiento que se da

luego que ocurra una falla o avería en el equipo que por su naturaleza no

pueden planificarse en el tiempo, presenta costos por reparación y

repuestos no presupuestadas, pues implica el cambio de algunas piezas

del equipo. Otros tipos de mantenimiento como el preventivo y el

proactivo se realizan únicamente a componentes críticos como motores

diesel o motores hidráulicos que suponen un alto costo y requieren una

alta disponibilidad.


Ilustración 6 Mantenimiento en la industria del shotcrete

En el taller de mantenimiento de equipos de shotcrete, las labores de

mantenimiento se pueden dividir en dos procesos principales:


1. Mantenimiento de Equipos

El mantenimiento de equipos se refiere al mantenimiento que se

realiza cuando todo el equipo se encuentra en el taller. Cuando esto

sucede, se debe a las siguientes razones:

OVERHAUL

Llamado también cero horas. Es el conjunto de tareas cuyo objetivo

es revisar los equipos a intervalos programados cuando la fiabilidad

del equipo ha disminuido de manera apreciable que es arriesgado

hacer prever sobre su capacidad. Consiste en dejar el equipo a Cero

horas de funcionamiento, es decir, como nuevo. Se sustituyen o

reparan todos los elementos sometidos a desgaste. Se pretende

asegurar, con una alta probabilidad un buen tiempo de funcionamiento

fijado de antemano.

En este tipo de mantenimiento se coloca al equipo en una estación de

trabajo, se realiza una verificación de sus sistemas (combustión,

hidráulico, transmisión, eléctrico, Chasis) luego se procede a evaluar

el grado de deterioro de los componentes para hacer el requerimiento

de sus partes a los proveedores correspondientes. Una vez que llegan

los componentes nuevos, se desmontan los componentes antiguos y

se montan los nuevos componentes. Estos procesos pueden durar de

3 a 6 meses dependiendo el grado de deterioro del equipo.

ACONDICIONAMIENTO

Es un tipo de mantenimiento en el cual se recibe una unidad nueva

del fabricante al taller y se realizan cambios o ajustes en su estructura

para soportar las condiciones de trabajo en las unidades mineras.

Algunos ejemplos pueden ser la colocación de guarda tacos para

asegurar el no deslizamiento del equipo en caso de lluvias. El

ensanchamiento de las mangueras en el sistema de alimentación del

motor, el reemplazo de llantas, etc. Este tipo de trabajos puede durar

1 a 2 meses.


REPARACION PARCIAL

Cuando el equipo sufre una avería que lo deja inoperativo se envía al

taller para verificar los sistemas, investigar la falla y realizar el

mantenimiento correspondiente. Dependiendo de la gravedad del

daño y de la disponibilidad de sus repuestos, se evalúa el tiempo que

deberá permanecer en el taller.


2. Mantenimiento de componentes

El mantenimiento de componentes se realiza cuando se identifica la

falla del componente en campo y luego de proceder con el reemplazo

por el componente en stand-by. Se enviar el componente fallado al

taller para su reparación. Este tipo de mantenimiento es más

frecuente que el mantenimiento de equipo, pudiendo involucrar desde

un 40% a un 70% de la mano de obra del área. Según el tipo de

componentes, podemos subdividir a este mantenimiento en:

Mantenimiento de componentes con alta rotación o

Componentes con vida propia

Mantenimiento de componentes menores

La presente investigación ha sido desarrollada para generar un

sistema que permita gestionar el mantenimiento de componentes

puesto que representan un gran volumen de piezas y su gestión

representa tanto o mayor esfuerzo que los mantenimiento de equipos,

el cual no se descarta adicionar en posteriores proyectos de mejora.

Estos componentes son descritos más detalladamente en la sección

2.2.4 Componentes con vida Propia.


D. Caso de estudio: ROBOCON SERVICIOS SAC

Para la presente investigación se tomó como base de análisis a la

empresa Robocon Servicios SAC, la cual se describe a continuación:

Es una empresa contratista especializada en el sostenimiento de

superficies rocosas con Shotcrete (concreto proyectado por vía húmeda),

en exploraciones mineras subterráneas, líder en el mercado peruano con

más de 120,000 m3 de concreto colocados desde el 2005.

Ilustración 7 Logo de Robocon SAC

Visión

Mantener el liderazgo como empresa peruana especializada en

sostenimiento con Shotcrete, con proyección a la atención de distintas

obras de tuneleria y sostenimiento a nivel local y regional, manteniendo

un compromiso de mejora continua en la calidad a nivel local y seguridad

de las condiciones de trabajo así como la protección al medio ambiente.

Misión

Brindar soluciones en sistemas de sostenimiento de túneles mediante uso

de concreto proyectado con equipos de alta tecnología desarrollando

innovaciones tecnológicas para afrontar las más diversas condiciones de

trabajo, aplicando técnicas y procesos de acuerdo a normas

internacionales y realizando capacitación constante del personal para


satisfacer los requerimientos de nuestros clientes con el más alto nivel de

calidad y profesionalismo.


1.2 Estado del arte

En esta sección, se presentaran conceptos básicos sobre los sistemas de

información, su importancia y objetivos, así como una breve descripción de

algunos sistemas de gestión de mantenimiento que existen en el mercado.

Previamente definiremos algunos conceptos básicos de sistemas de información.

1.2.1 Conceptos básicos

A. Sistema

Es una colección de subsistemas que están relacionados y son

interdependientes, trabajan en conjunto para lograr metas y objetivos

predeterminados. Todos los procesos tienen entrada, proceso, salida y

retroalimentación. Algunos ejemplos son un sistema de información

computarizado en una organización. (Kendall, 2011).

B. Sistema de Información (SI)

Es un sistema orientado al tratamiento y administración de datos e

información, que cubre una necesidad de información de una organización.

C. Análisis y diseño de sistemas

Es la primera etapa del desarrollo de un sistema informático que consiste

en relevar la información actual de los procesos de la organización y

proponer los rasgos generales de la solución a futuro.

D. Analista de sistemas

Por consiguiente, el analista de sistemas es la persona encargada de

evaluar de manera sistemática el funcionamiento de la organización a

través de la entrada y procesamiento de datos y posterior producción de

información con el propósito de mejorar los procesos de la organización.



1.2.2 Importancia y Beneficios de los sistemas de información

Los autores Correa, Saavedra y Arévalo (2009), muestran que gracias a la

utilización de los sistemas de información se obtienen los siguientes

beneficios. (IZAMORAR)

a) Acceso inmediato a la información ya sea de personas, datos, software

o hardware.

b) Mayor motivación para anticipar las solicitudes de las directivas.

c) Evitar pérdida de tiempo en la recopilación de información.

d) Impulsos para crear grupos de investigación.

e) Se generan más dinámicas, gracias a los medios informáticos; como el

correo electrónico.

Según López (2006) las organizaciones necesitan de la información para

tener vida y prosperar, creciendo de esta manera hacia lugares lejanos,

modificando así la forma de manejar los negocios. (IZAMORAR)

Para que una organización mejore su productividad y rendimiento, es

necesario aplicar técnicas y sobre todo tecnologías para que de esta

manera los sistemas se puedan desenvolverse con precisión y eficacia

(2008).

Objetivo de los sistemas de información:

Según Guzmán (2002), los sistemas de información se encargan

específicamente de (IZAMORAR):

a. Proporcionar, facilitar y ejecutar automáticamente procesos que

constantemente se realizan manualmente.

b. Dar información y datos para ayudar a la toma de decisiones.

Senn (2005, p.23), considera que : “las finalidades de los sistemas de

información, como la de cualquier sistema dentro de una organización

son ,procesar entradas, mantener archivos de datos relacionados con la

organización y producir información, reportes y otras salidas”


Desde el punto de vista comercial López (2006), considera que los

sistemas de información tienen la siguiente finalidad: “Incrementar el

rendimiento de las inversiones, mejorar su posición estratégica y acrecentar

el valor del mercado de las acciones”.


1.2.3 Tipos de Sistemas

En los inicios de la programación, cada vez que se necesitaba un SI, dicho

sistema se desarrollaba “a la medida” de un problema en particular. Sin

embargo, pronto se hizo aparente que muchos de los problemas de los

sistemas de información compartían soluciones comunes.

Consecuentemente, las organizaciones intentaron desarrollar un modelo de

sistema que resolviera un rango de problemas relacionados. Sin embargo,

se dieron cuenta que para realizar esta labor era necesario definir cómo y

dónde el SI sería usado y porqué era necesario. Desde ese momento,

nació la necesidad de desarrollar una estructura para clasificar los SI.

(Kimble, 2013).

Ilustración 8 Jerarquía de Sistemas


A. Sistemas de Procesamiento de transacciones, TPS

Son sistemas a nivel operativo en la base de la pirámide, usualmente

utilizados por personal de primera línea (cajeros, vendedores, etc.) que

proveen los datos clave requeridos para el soporte de la gestión de las

operaciones.

Una transacción es un evento que genera o modifica los datos que se

encuentran eventualmente almacenados en un sistema de información.

(Wikipedia, 2014).

Algunos ejemplos comunes de TPS son:

Sistemas de Planillas

Sistemas de procesamiento de Órdenes

Sistemas de reservaciones

Sistemas de control de stocks

Sistemas de Pagos y transacciones financieras

Desde un punto de vista técnico, un TPS monitoriza los programas

transaccionales (un tipo especial de programas). La base de un programa

transaccional está en que gestiona los datos de forma que estos deben

ser siempre consistentes (por ejemplo, si se realiza un pago con una

tarjeta electrónica, la cantidad de dinero de la cuenta sobre la que realiza

el cargo debe disminuir en la misma cantidad que la cuenta que recibe el

pago, de no ser así, ninguna de las dos cuentas se modificará), si durante

el transcurso de una transacción ocurriese algún error, el TPS debe poder

deshacer las operaciones realizadas hasta ese instante.


Arquitectura de un TPS

Ilustración 9 Arquitectura TPS

FUENTE: (Friginal, 2013)


B. Sistema de información gerencial, MIS

Son sistemas utilizados por las jefaturas de áreas para asegurar el

funcionamiento de la organización en el corto y mediano plazo. La

estructura compleja y desarrollada de estos sistemas permite a los

administradores evaluar el funcionamiento de la organización al comparar

resultados actuales vs. Históricos.

Algunos ejemplos comunes de MIS son:

Sistemas de gestión de ventas

Sistemas de control de inventarios

Sistemas de presupuestos

Sistemas de gestión de reportes, MRS

Sistemas de gestión de personas

Los MIS son importantes en cualquier organización por las siguientes

razones:

o Oportunidad : Para lograr un control eficaz de una organización, se deben

tomar a tiempo medidas correctivas en caso de ser necesarias, antes de

que se presente una gran desviación respecto de los objetivos

planificados con anterioridad.

o Cantidad : Es probable que los gerentes casi nunca tomen decisiones

acertadas y oportunas si no disponen de información suficiente, pero

tampoco deben verse desbordados por información irrelevante e inútil

(redundancia), pues ésta puede llevar a una inacción o decisiones

desacertadas.

o Relevancia : Reducción de costos.


Arquitectura de un MIS

Ilustración 10 MIS en una organización

FUENTE: ENLACE WEB (Barbara Canning McNurlin)


Los TPS proporcionaran los datos que procesaran los MIS.

Los MIS generaran los reportes de detalle, de indicadores, programados. Según la necesidad del cliente

Los MIS generaran los reportes de detalle, de indicadores, programados. Según la necesidad del cliente

C. Sistema de soporte de decisiones, DSS

Es un tipo de sistema basado en el conocimiento, usado por la alta

gerencia que facilita la creación de conocimiento y permite la integración

de la organización. Estos sistemas son usualmente utilizados para

analizar información estructurada existente y permite a los gerentes

proyectar los efectos y riesgos de sus decisiones a futuro. Ofrecen acceso

a las bases de datos, herramientas analíticas, permiten análisis de

sensibilidad, y soportan intercambio de información dentro de la

organización.

Algunos ejemplos comunes de MIS son:

Sistemas de soporte a las decisiones grupales (GDDS)

Sistemas de trabajo cooperativo (CSCW)

Sistemas logísticos

Sistemas de planeamiento financiero.


Arquitectura de un DSS

Ilustración 11 Arquitectura DSS

FUENTE: DSS Arquitecture, Abraham Otero


D. Sistema de información ejecutiva, EIS

Son sistemas de información a nivel estratégico encontrados en la punta

de la pirámide, ayudan a la gerencia ejecutiva a analizar el entorno en el

que opera la organización para identificar tendencias a largo plazo y

elaborar los planes de acción respectivos. La información en dichos

sistemas esta débilmente estructurada y proviene de fuentes tanto dentro

como fuera de la organización. Estos sistemas son diseñados para ser

operados directamente por los ejecutivos sin la necesidad de

intermediarios y son flexibles para adecuarse a las preferencias de los

individuos que lo utilizan.


Arquitectura de un EIS

FUENTE: Elaboración Propia



Fuentes internas

Fuentes Externas

Gráficos, diagramas

Pronósticos

Reporte de Panel de Control

(Dashboard)

Herramientas “drill down”

Procesador de simulaciones

Agrupamiento de Información

MIS Financiero

MIS Logístico

MIS Contable

TPSFinanciero

TPSLogístico

TPSContable

Entradas de datos Salida de informacionProcesamiento

Ilustración 12 Arquitectura EIS

E. Sistemas de planificación de recursos empresariales (ERP)

Los sistemas de planificación de recursos empresariales, o ERP (por sus

siglas en inglés, Enterprise Resource Planning) son un conjunto

de sistemas de información gerenciales que integran y manejan muchos

de los negocios asociados con las operaciones de producción y de los

aspectos de distribución de una compañía en la producción de bienes o

servicios.

Los ERP funcionaban ampliamente en las empresas. Entre sus módulos

más comunes se encuentran el de manufactura o producción,

almacenamiento, logística e información tecnológica, incluyen además

la contabilidad, y suelen incluir un sistema de administración de recursos

humanos, y herramientas de mercadotecnia y administración estratégica.

(WIKIPEDIA, 2014). Entre uno de los ERP más conocidos y aplicados a

una amplia gama de sectores se encuentra:

SAP R/3

Es un ERP (Enterprise Resource Planning) de origen alemán, creado

por SAP. Asimismo, permite controlar todos los procesos que se llevan a

cabo en una empresa, a través de módulos.


Arquitectura del ERP SAP Netweaver

Ilustración 13 Arquitectura del ERP SAP

FUENTE: (SAP)


El ICM permite la conexión con Internet. Puede procesar peticiones del servidor y del cliente.

El dispattcher distribuye las peticiones a los procesos de trabajo (WP). Si todos los procesos están ocupados, se mantiene en cola.

Cada WP ejecuta los programas en ABAP o Java.

El Gateway habilita la interfaz RFC entre todas las instancias SAP.

Cada WP realiza las peticiones en el Database schema de la instancia de SAP utilizada.

Existen otros componentes como Java Dispatcher, Server Process y Software Development manager (SDM) que cumplirían funciones paralelas al motor ABAP/Java, utilizando el Entorno J2EE.

1.3 Descripción de la solución

Frente a la problemática en torno a la necesidad de una solución informática para

la gestión del mantenimiento en los talleres de mantenimiento, se propone la

implementación de un sistema de información gerencial especializado para la

gestión del mantenimiento de componentes (CMMS). La solución está facultada

para administrar tareas básicas de mantenimiento de talleres de maquinaria

como son la gestión del mantenimiento correctivo y la administración de los

componentes de alta rotación.

A continuación, se describe el tipo de sistema de información a desarrollar:


1.3.1 Sistemas de información gerencial para la gestión del

mantenimiento, CMMS

Son sistemas de información gerenciales cuyas características específicas

planteadas por Duffuaa, Raouf y Dixon (2000: 303) comprenden cinco

módulos predefinidos:

o Administración del equipo

o Control de órdenes de trabajo

o Administración de las especialidades de mantenimiento

o Abastecimiento y control de materiales

o Informes de desempeño

Cabe destacar que se considera la estructura organizativa de la función de

mantenimiento como una función diferenciada de carácter operativo, lo cual

implica que esta función es establecida como una gerencia o un

departamento con responsabilidades y recursos específicos.

Entre algunos CMMS que se encuentran en el mercado podemos describir

los siguientes:


PROVEEDOR DESCRIPCION SOFTWARE

Permite visualizar el plan general de mantenimiento , como ventaja comparativa genera OT clasificadas

en proyectos, control de flotillas (combustible y neumáticos), códigos de barras, interfaces con ERP’s,

módulo de alertas vía sms, E-mail, Conexión a internet, lecturas importadas de sistemas SCADA, PLC.

En resumen, es un CMMS muy completo y robusto indicado para la gestión de organizaciones

complejas y extensas. Tiene un precio de licenciamiento de 1020 USD Anual (5 Servidores

funcionalidad completa).

Es un CMMS con leguaje en español, aunque con un diseño de interfaz complejo y algo desordenado,

presenta versatilidad en cuanto a entrada de información y simplicidad en cuanto a las variables que

maneja.

Es un CMMS simple, con un diseño de interfaz básica, no requiere un sistema de codificación compleja.

Presenta un catálogo de instalaciones con la ubicación de cada equipo, tiene conectividad por internet

para la generación de órdenes de servicio. Tiene un precio final de 5520 USD. (5 servidores,

Funcionalidad completa)

Es un CMMS con lenguaje español, simple, con un diseño de interfaz conservador, permite ubicar

equipos en un plano, tiene un módulo de gestión de procedimientos, presupuestos a una fecha dada,

préstamos de herramientas.

Es un CMMS virtualizado canadiense en ingles, con una amplia funcionalidad, con una interfaz

amigable, presenta una subscripción mensual de 29 USD por mes.


RESUMEN COMPARATIVO DE SOLUCIONES

Tabla 1 Análisis Comparativo de Soluciones

FUNCIONALIDAD

Administración del equipo Si Si Si

Administración de mantenimiento programado Si Si Si

Administración de mantenimiento correctivo Si Si Si

Gestión de materiales y stock Si Si Si

Gestión de compras Si Si No

Gestión de mantenimiento predictivo Si Si Si

Gestión de recursos Si Si Si

Visualización de Informes y graficas Si Si Si

Gestión de garantías Si Si Si

Gestión de Proyectos Si No No

Seguimiento a través de cronogramas Si Si Si

Gestión de herramientas Si Si No

Gestión de flotillas Si No No

Conectividad a ERP, SCADA Si No No

Precio 1020 USD/Year 29 USD /Month 5520 USD


1.4 Plan de Proyecto

En esta sección se analizan, describen y selecciona la metodología de desarrollo

más adecuada llevar a cabo el proyecto de tesis, así como del ciclo de desarrollo

del producto software.

1.4.1 Selección de la Metodología de desarrollo

En el desarrollo de sistemas, existen diversas metodologías de desarrollo

entre ellas encontramos:


A. Ciclo de vida de desarrollo de sistemas, SDLC System Developement

Life Cicle

Según la metodología SDLC, las fases para el desarrollo de un sistema

comprenden:

3. Identificación de los problemas, oportunidades y objetivos

En esta etapa se conoce los procesos de la organización, se dialoga

con los responsables de los procesos, se sintetiza el conocimiento

obtenido, se estima el alcance del proyecto y finalmente se

documenta los resultados.

4. Determinación de los requerimientos de información

En esta fase el analista determina los requerimientos de información

de los usuarios. Entre las herramientas para determinar los

requerimientos se encuentran las entrevistas, los muestreos, la

investigación de datos impresos, y la aplicación de cuestionarios, la

observación del comportamiento de los usuarios, así como métodos

de alto alcance como la elaboración de prototipos.

5. Análisis de las necesidades del sistema

Las herramientas utilizadas para esta fase son principalmente los

diagramas de flujo para graficar las entradas, los procesos y las

salidas, de las funciones del proceso a gestionar. A partir de los

diagramas de flujo se elabora un diccionario de datos, que enlista

todos los datos utilizados en el sistema, así como sus respectivas

especificaciones. Para generar las especificaciones del proceso se

utilizan herramientas como el español estructurado, tablas de decisión

u arboles de decisión.

6. Diseño del sistema recomendado

En esta etapa se diseñan los procedimientos precisos para la captura

de datos mediante técnicas adecuadas de formularios y pantallas.


En esta etapa toma importancia el concepto de interfaz de usuario

como son el teclado, los menús de pantalla, y diversas GUI (Graphical

user Interface) que se manejan a través de un ratón o una pantalla

sensible al tacto.

Asimismo, en esta etapa se incluye el diseño de archivos o bases de

datos como también se interactúa con los usuarios para diseñar la

salida de información (en pantalla o impresa) que satisfaga las

necesidades de información de estos últimos.

7. Desarrollo y documentación del software

Esta parte comprende la elaboración del código del software y el

diseño de la interfaz de usuario. El analista trabaja con los

programadores para desarrollar el software necesario para el sistema.

Durante esta etapa, el analista se encarga de elaborar la

documentación de soporte del sistema como pueden ser: los

manuales de procedimientos, ayuda en línea, FAQ, etc.

8. Prueba y mantenimiento del sistema

Antes de utilizar el nuevo sistema se debe probar. Primero se utiliza

datos de muestra para evaluar la funcionalidad y luego datos reales

para evaluar la lógica y fiabilidad de la información.

9. Implementación del sistema

Esta fase comprende la capacitación a los usuarios, la conversión de

los sistemas antiguos al nuevo, instalación de nuevos equipos o

software.


Ilustración 14 Ciclo de Vida del Desarrollo de Sistemas


Identificacion de Objetivos

Requerimientos de Informacion

Analisis de necesidades Dseño del sistema

Desarrollo y documentacion del software

Prueba y mantenimientoImplementacion

B. Análisis y Diseño de sistemas Orientado a Objetos

El Análisis y Diseño de sistemas Orientado a Objetos es una metodología

enfocada en el UML que se basa en iteraciones a manera de espiral

hasta llegar al estado de solución requerido.

Unified Modeling Language, UML es un lenguaje que permite modelar,

construir y documentar los elementos que forman un sistema software

orientado a objetos.

Dicha metodología consta de las siguientes fases:

1. Planificación y especificación de requisitos

Fase similar a la identificación de los problemas oportunidades y

objetivos del SDLC, se define qué es lo que necesita resolver el

sistema. Asimismo, se define los recursos necesarios para el proyecto

de desarrollo del sistema.

2. Análisis y Diseño

Comprende las siguientes actividades:

Definir el modelo de caso de Uso: En esta etapa se identifica los

actores y los eventos iniciados por los actores.

Diseño de los diagramas de UML: En esta fase se dibujan los

diagramas de actividad, los cuales ilustran todas las principales

actividades en el caso de uso. Además se elaboran los diagramas de

secuencia para cada caso de uso, los cuales muestran la secuencia

de actividades y su sincronización. En esta fase se revisan y se

actualizan los casos de uso según convenga.

Desarrollar los diagramas de clase: En esta fase se diseñan los

diagramas de clase, los cuales son la representación gráfica de la

estructura de un sistema mostrando sus clases, orientado a objetos.

Dibujar los diagramas de estado: Los diagramas de estado

permiten comprender procesos complejos que no se pueden detallar

en los diagramas de secuencia. En esta fase es posible una


actualización de los diagramas de clases, debido al comportamiento

iterativo de esta metodología.

3. Implementación

Se lleva lo especificado en el diseño a un lenguaje de programación

orientado a objetos, entre los cuales tenemos el Visual Basic. Net. El

C++, Java, etc. En esta fase es posible replantear los diagramas

iniciales y documentar las especificaciones del sistema.

Ilustración 15 Análisis de Sistemas orientado a objetos


Planificacion

Analisis y Diseño

Implementacion

C. Metodología Ágil de desarrollo

El desarrollo ágil de software engloba una lista de métodos de ingeniería

del software basado en el desarrollo iterativo e incremental, donde los

requisitos y soluciones evolucionan mediante la colaboración de grupos

auto-organizados y multidisciplinarios (CockBurn, 2000). El software

desarrollado en una unidad de tiempo es llamado una iteración, la cual

debe durar de una a cuatro semanas. Cada iteración del ciclo de vida

incluye: planificación, análisis de requisitos, diseño, codificación, revisión

y documentación. Una iteración no debe agregar demasiada

funcionalidad para justificar el lanzamiento del producto al mercado, sino

que la meta es tener una «demo» (sin errores) al final de cada iteración.

Al final de cada iteración el equipo vuelve a evaluar las prioridades del

proyecto.

Los métodos ágiles enfatizan las comunicaciones cara a cara en vez de la

documentación. La mayoría de los equipos ágiles están localizados en

una simple oficina abierta, a veces llamadas "plataformas de lanzamiento"

(bullpen en inglés). La oficina debe incluir revisores, escritores de

documentación y ayuda, diseñadores de iteración y directores de

proyecto. Los métodos ágiles también enfatizan que el software funcional

es la primera medida del progreso. Combinado con la preferencia por las

comunicaciones cara a cara, generalmente los métodos ágiles son

criticados y tratados como "indisciplinados" por la falta de documentación

técnica.

La metodología de desarrollo ágil consta de las siguientes etapas:

1. Exploración – Introducción

Esta etapa consiste en explorar el entorno, ensamblar el equipo y

evaluar las habilidades de sus miembros. Esta etapa puede durar

desde unas cuantas semanas a algunos meses, si todo es nuevo.

Asimismo, se evalúan las tecnologías disponibles y el cliente termina

de transmitir detalladamente el problema al equipo lo que permitirá

estimar con mayor precisión el tiempo del proyecto.


2. Planeación – Elaboración

Esta etapa permite que el equipo llegue a un acuerdo con el cliente

sobre el plazo de tiempo necesario para el desarrollo del proyecto,

asimismo, el cliente define qué es lo primero que abordara el equipo

de desarrollo.

3. Iteraciones para la liberación de la primera versión -

Construcción

Esta etapa hace referencia a los ciclos de prueba, retroalimentación y

modificación. En esta etapa se bosqueja toda la arquitectura del

sistema, aun cuando solo este en forma de esqueleto. El objetivo es

realizar las pruebas funcionales escritas por el cliente al final de cada

iteración.

4. Puesta en producción – Transición

Durante esta etapa, luego de las modificaciones respectivas, se

agiliza el ciclo de retroalimentación, el sistema se pone en

funcionamiento y se realizan pequeños ajustes.

5. Mantenimiento

Durante esta etapa se busca asegurar el buen funcionamiento del

sistema y se evita cualquier cambio que genere riesgos frente a la

confiabilidad del sistema.


Ilustración 16 Metodología Ágil de Desarrollo

1.4.2 Selección de la herramienta Metodológica

Se optó por seleccionar la metodología de desarrollo ágil AUP, debido a

que ofrece un paradigma dirigidos a un modelamiento esbelto del negocio y

un marco conceptual de buenas prácticas para la etapa de construcción del

software.


2. CAPITULO II ANALISIS

2.1 Análisis de las necesidades del cliente

Como principales necesidades establecidas por el jefe del taller y jefes de área de

la organización del taller se obtuvieron los siguientes alcances:

Seguimiento de las órdenes de trabajo del taller de mantenimiento

Generación de los kpi del taller de mantenimiento.

Registro de órdenes de servicio de mantenimiento.

Registro de órdenes de trabajo de mantenimiento.

Seguimiento de los componentes con vida propia identificados en el

sistema.

Estas necesidades quedaran cubiertas por los requerimientos del sistema. A

partir de las necesidades de los usuarios es posible construir el diagrama de

casos y actores:


Usuario

Actualizar catalogos

Gestionar procesos

Reportar KPIs de mantenimiento

Mantener registro de Equipos,

«include»

Mantener registro de Componentes

«include»

Mantener registro de Componentes con vida propia

«include»

Mantener registro de empleados«include»

Procesar Recepciones

«include»

Procesar Ordenes de Servicio

«include»

Procesar Ordenes de trabajo

«include»

Procesar Despachos

«include»

Reportar Detallado«include»

Reportar Indicadores

«include»

Ilustración 17 Diagrama general de Caso de Uso del sistema

Este diagrama muestra, en un nivel básico, las principales acciones que deberá

ejecutar el usuario.


2.2 Análisis del proceso

En esta sección se hace una recopilación de la información necesaria para

describir el proceso. La estructura organizacional, la descripción de las áreas, los

equipos, los componentes y el flujo de trabajo del mantenimiento de

componentes. Esta sección es importante porque permitirá generar la base de

datos del sistema.

2.2.1 Estructura organizacional de un taller de maquinaria pesada

A continuación se muestra un modelo organizacional de un taller de

maquinaria pesada:

Ilustración 18 Estructura Organizacional de un taller de maquinaria pesada


Jefe de taller

Supervisor area Motores

Mecanico I

Mecanico II

Mecanico II

Supervisor area Hidráulica

Mecanico I

Mecanico II

Mecanico III

Supervisor area Transmisión

Mecanico I

Mecanico II

Mecanico III

Supervisor area Electrica

Electronico

Electricista I

Electricista II

Electricista III

Supervisor area Estructuras

Tornero

Soldador I

Soldador II

Soldador III

Supervisor area Pintura

Pintor I

Pintor II

Pintor III

Analista de planeamiento

Analista de seguridad

Asistente de gestión

Fuerza laboral del taller de mantenimiento

Dentro de un taller podemos encontrarnos con la siguiente distribución de la

fuerza laboral:

Tabla 2 Headcount taller de maquinaria pesada

Sub área Puesto Cantidad

Gestión

Jefe 1

Analista 3

Asistente 1

Total Gestión 5

Electricidad

Electricista 1 1

Electricista 2 1

Electricista 3 2

Electrónico 1 1

Total Electricidad 5

Estructuras

Soldador 1 4

Soldador 2 4

Soldador 3 3

Total Estructuras 11

Hidráulica

Mecánico 1 2

Mecánico 2 2

Mecánico 3 5

Total Hidráulica 9

Motores Mecánico 1 2


Mecánico 2 1

Mecánico 3 2

Total Motores 5

PinturaPintor 1 2

Pintor 3 1

Total Pintura 3

transmisión

Mecánico 1 1

Mecánico 3 2

Pintor 2 1

Total transmisión 4

Total general 42

2.2.2 Layout general del taller de mantenimiento

La distribución de un taller puede variar según los equipos y tareas a

ejecutar, sin embargo para el presente documento, según la experiencia se

muestra la siguiente distribución como referencia de la distribución general

del taller. Como se puede apreciar se han graficado las áreas, las zonas

para el ensamblaje y montaje de equipos y las zonas para la recepción de

componentes de cada área.


Oficina

45 m cuadr

Oficina Taller

Oficina Taller 2

Area Motores

Area Transmisión

8 m cuadr

Area HidraulicaArea Electricidad

Almacen

Area Pintura

15 m cuadr

Area Estructuras

20 m cuadr

COMPONENTES COMPONENTESCOMPONENTES

COMPONENTES

COMPONENTES

Ilustración 19 Layout del taller


2.2.3 Equipos empleados para el mantenimiento

Los equipos empleados en shotcrete pueden diferir notablemente sin

embargo, la función principal de estos equipos se resume en dos tareas

básicas: Mantener la mezcla de concreto en movimiento durante el

lanzamiento para evitar el endurecimiento prematuro de la mezcla y

generar el disparo o lanzamiento del concreto con suficiente potencia para

que este pueda adherirse a las paredes del socavón. Los principales

equipos pueden apreciarse según la Tabla 3.


Ilustración 20 Equipos de shotcrete


Tabla 3 Equipos para Shotcrete

EQUIPO DESCRIPCION

MIXER - MIXKRET 4 – PUTZMEISTER ALEMANIA

Compacto, resistente y versátil. Equipado con un motor de 6 cilindros 174 HP, el Mixkret 4 ofrece mayor

tracción y maniobrabilidad que sus similares. La cuba de 5.2 yardas cubicas diseñado especialmente para el

mezclado, transporte y descarga del concreto ayuda a incrementar la carga transportada manteniendo un

bajo centro de gravedad para mejorar la estabilidad durante el transporte.

MIXER - HURON 4 – LORENZANA ESPAÑA

Equipo hormigonera de 4 m3, de reducidas dimensiones para transportar y mezclar hormigón, en seco o en

húmedo, en túneles y galerías de bajo perfil. Incorpora chasis articulado de estructura tubular. El motor diesel

electrónico, modelo PERKINS 1104D-E44TA 4 cilindros turbo intercooler. Refrigeración líquida. Potencia

máxima 116 kW (140 CV) a 2.300 r.p.m., preparado para trabajar a 4.700 msnm.

MIXER - HURON 5 – LORENZANA ESPAÑA

Articulado de chapa oxicortada compuesto por: - Chasis delantero de cabina sobre el que va montado motor

diesel y sistema hidráulico - Chasis trasero sobre el que se monta el bombo para hormigonado. - Articulación

central MOTOR: Deutz Diesel, TCD 2012 L06 2V, 6 cilindros turbo intercooler. Refrigeración líquida.

Potencia máxima 147 kW (197 CV) a 2.400 r.p.m., preparado para trabajar a 4700m.

MIXER – TORNADO – NORMET FINLANDIA

Chasis tubular, Motor DEUTZ BF4M1013C, 145HP,cuatro cilindros refrigerado por agua. Transmision

hidrostatica de regulacion automatica, bombas de pistones Rexroth montados directamente al diferencial de

cada eje. Direccion hidroasistida sobre el eje delantero y trasero. Cuba de 3m3. Rotacion en ambos sentidos


con motor Rexroth.

ROBOT - ALPHA 20 – NORMET FINLANDIA

Motor DEUTZ BF4M1013C, Potencia de 110 KW a 2300 RPM, Transmision hidrostatica Rexroth-Sauer.

Caudal nominal 20 mts3/hr, caudal normal de 12mts3/hr. Brazo robotizado con doble extension, con angulo

de rotacion de 250°.


2.2.4 Componentes con vida propia

Existen algunos componentes que presentan estos equipos que son

intercambiados con mayor frecuencia que otros y cuyo mantenimiento y

reemplazo es crítico para no perder disponibilidad del equipo, estos

componentes son denominados componentes con vida propia.

Los componentes con vida propia requieren un control particular debido a

su importancia dentro del funcionamiento del equipo, su valor económico es

alto y cualquier causa de falla de estos componentes debe ser identificada

y solucionada a tiempo. Un sistema de información permite obtener mucha

información con la cual analizar y trackear cada componente.

A continuación, se detallan alguno de estos componentes y se presentan

algunas imágenes como referencia.


Ilustración 21 Bomba hidraulica A4VG125

Ilustración 22 Bomba de giro de cuba A4VTG71

Ilustración 23 Motor diesel BF4M2012C


Componentes con vida propia de la especialidad de Hidráulica

SISTEMA COMPONENTE EQUIPO MODELO MARCA

HIDROSTATIC

OBOMBA DE GIRO DE CUBA TORNADO A4VTG71EPA/32R-NXD10FO11 REXROTH

HIDROSTATIC

OBOMBA DE TRASLACION TORNADO A4VG125 DA2D2/32R- NTF REXROTH

HIDROSTATIC

OMOTOR DE GIRO DE CUBA TORNADO 90MO75NCON8NOC6WO SAUER

HIDROSTATIC

O

MOTOR DE TRASLACION/ MOTOR DE GIRO DE

CUBAALPHA O TORNADO AGVM140HA2R2/63W-VZB017PA REXROTH

HIDROSTATIC

OVALVULA DIVISORA DE CAUDAL TORNADO 2552A-11/220F2H420F45V11-622 REXROTH

HIDROSTATIC

OBOMBA DE CONCRETO ALPHA 20 PGP330

HIDRAULICO BOMBA DE BRAZO ALPHA 20 JRR045BLS2020NNN3C3V2A8NNNNNNNNNNSAUER

DANFOSS

HIDROSTATIC

OBOMBA DE TRASLACION ALPHA 20 A4VG56 REXROTH

HIDROSTATIC

OMOTOR DE TRASLACION ALPHA 20 90M075NC0N8N0C6W00NNN000024

SAUER

DANFOSS

HIDROSTATIC

OBOMBA DE GIRO DE CUBA HURON 4 M4PV58-58

HIDROSTATIC

OBOMBA DE TRASLACION HURON 4 HPV135-O2 LINDE

HIDROSTATIC

OMOTOR DE GIRO DE CUBA HURON 4 HTC-2501011-144457 SAMHYDRAULIK

HIDROSTATIC MOTOR DE TRASLACION HURON 4 A6VM80HD1/63W-VSC520B-E REXROTH


O

HIDROSTATIC

OBOMBA DE GIRO DE CUBA PUTZMEISTER 42R51DANKB03ANA3FNN1717BNNNNNNNN

SAUER

DANFOSS

HIDROSTATIC

OBOMBA DE TRASLACION PUTZMEISTER H1P115RAC3C2CD8L62H5L45L45

SAUER

DANFOSS

HIDROSTATIC

OMOTOR DE GIRO DE CUBA PUTZMEISTER OMTS20015183037

SAUER

DANFOSS

HIDROSTATIC

OMOTOR DE TRASLACION PUTZMEISTER OV1231

HIDROSTATIC

OBOMBA DE GIRO DE CUBA HURON 5 M4PV65-65 NNNNNNN

HIDROSTATIC

OBOMBA DE TRASLACION HURON 5 HPV105-O2-0000 LINDE

HIDROSTATIC

OMOTOR DE GIRO DE CUBA HURON 5 HTC-3501011-144457

HIDROSTATIC

OMOTOR DE TRASLACION HURON 5 MS18-D21 LINDE

HIDROSTATIC

OMOTOR DE TRASLACION HURON 5 MS18-G21 LINDE

HIDROSTATIC

O

MOTOR DE TRASLACION/ MOTOR DE GIRO DE

CUBA

ALPHA 20 O

TORNADOAA2FM80


Componentes con vida propia de la especialidad de Electricidad

COMPONENT

EEQUIPO MODELO MOTOR MOD COM

ALTERNADOR ALPHA 20 O TORNADO BF4M1013C 24V

ARRANCADO

R

ALPHA 20 O TORNADO O HURON

5

BF4M1013C / TCD2012 L06

2V 24V

ALTERNADOR HURON 4 BF4M2012C 12V

ARRANCADO

R HURON 4 BF4M2012C 12V

ALTERNADOR HURON 5 TCD2012 L06 2V 24V

ALTERNADOR MIXRET 4 C6.6 - CATERPILLAR 24V

ARRANCADO

R MIXRET 4 C6.6 - CATERPILLAR 24V

ALTERNADOR HURON 4 3028/N538957 - PERKINS 12V

ARRANCADO

R HURON 4 3028/N538957 - PERKINS 12V

Componentes con vida propia de la especialidad de Motores

AREA COMPONENTE MARCA MOTOR MODELO EQUIPO TIPO

MOTORES MOTOR DIESEL DEUTZ BF4M1013C ALPHA 20 O TORNADO MOTOR DIESEL


MOTORES MOTOR DIESEL DEUTZ BF4M2012C HURON 4 MOTOR DIESEL

MOTORES MOTOR DIESEL DEUTZ TCD2012 L06 2V HURON 5 MOTOR DIESEL

MOTORES MOTOR DIESEL CATERPILLAR C6.6 PUTZMEISTER MOTOR DIESEL

MOTORES MOTOR DIESEL PERKINS 3028/N538957 HURON 4 MOTOR DIESEL

Componentes con vida propia de la especialidad de Electricidad

COMPONENTE MARCA MOTOR EQUIPO TIPO

CONTROL REMOTO ALPHA 20 BF4M1013C EMISOR

CONTROL REMOTO ALPHA 20 BF4M1013C RECEPTOR

CONTROL REMOTO ALPHA 20 BF4M1013C EMISOR

CONTROL REMOTO ALPHA 20 BF4M1013C RECEPTOR

ALTERNADOR

ALPHA 20 O

TORNADO BF4M1013C 24V

ARRANCADOR

ALPHA 20 O

TORNADO BF4M1013C 24V

ALTERNADOR HURON 4 BF4M2012C 12V

ARRANCADOR HURON 4 BF4M2012C 12V

ALTERNADOR HURON 5 TCD2012 L06 2V 24V

ARRANCADOR HURON 5 TCD2012 L06 2V 24V

ALTERNADOR MIXRET 4 C6.6 24V


ARRANCADOR MIXRET 4 C6.6 24V


2.2.5 Flujo de trabajo para el mantenimiento de componentes

El flujo de trabajo está representado en el siguiente diagrama:

Estructuras

Pintura

Hidraulica

Transmision

Electrica

Taller

Jefe de taller Repartidor Almacen

Llegada de componentes

Salida de componentes

Tecnico

Despacho

Orden de Servicio

Recepcion

Orden de trabajo

Despacho

12

4

5

3

Asignacion

Ilustración 24 Flujo de trabajo


2.2.6 Diagrama de flujo para el proceso de mantenimiento de Componentes

Existen varios responsables en el proceso de mantenimiento desde que este es entregado al taller o enviado a la

unidad minera. A continuación mostramos el diagrama de flujo de las actividades que se ejecutan en el proceso.

Ilustración 25 Mapa de Procesos



2.2.7 Procesos de mantenimiento de maquinaria pesada

Los principales procesos que se han generado en la industria del shotcrete para el mantenimiento de los equipos han

sido detallados según la Tabla 4.

Ilustración 26 Actividades de mantenimiento


Tabla 4 Procesos de mantenimiento de equipos de maquinaria pesada

SISTEMA ACTIVIDADES PRINCIPALES ESTRUCTURA

A. MANTTO.HIDRAULICO

Desmontaje, armado y montaje de componentes

Tendido de línea hidráulica.

Reemplazo de aceite hidráulico.

Lavado y limpieza de partes. Pruebas hidráulicas.

Componentes:

Motores, Bombas, Válvulas

Insumos:

Mangueras, Adaptadores, bridas, sellos, mangueras, O-rings. Pernos,

tuercas.

B. MANTTO. TRANSMISION Desmontaje, armado y montaje de componentes

Lavado y limpieza de partes.

Reemplazo de neumáticos.

Componentes:

Ejes diferenciales, Línea cardánica, Caja reductora

Insumos:

Pernos, tuercas, rodamientos, juntas, o-rings.

C. MANTTO. MOTORES Instalación de líneas de D2, admisión y escape.

Desmontaje y montaje de motor y componentes menores.

Testeo de arranque.

Componentes:

Motor Diesel, Intercooler, radiador, enfriador hidráulico.

Insumos:

Diesel, gasolina, refrigerante, spray, pernos, tuercas.

D. MANTTO. ELECTRICO Reparación de alternadores y arrancadores.

Armado y montaje de tableros eléctricos.

Instalación del tablero de control.

Componentes:

Arrancadores, alternadores, tablero principal, tablero de control.

Insumos:

Solenoides, bocinas, pernos, portadiodo, termoencogibles, leds.

E. MANTTO. ELECTRONICA Reparación de control remoto.

Cambio de batería.

Componentes:

Control remoto: Emisor y Receptor

Insumos:

Diodos, Soldadura, resistencias.

F. MANTTO. ESTRUCTURA Fabricación de estructuras metálicas del chasis, tolva, sistema de descarga, cabina.

Montaje de estructuras metálicas.

Componentes:

Cabina de operador, Chasis, Laterías, Cuba. Torres de brazo

Insumos:

Discos de corte, discos de desbaste, varillas de soldadura, pernos, tuercas.

G. PINTURA Masillado y lijado de estructuras.

Pintado y acabado de estructuras y componentes.

Componentes:

Cabina de operador, Chasis, Laterías, Cuba. Torres de brazo

Insumos:

Pintura y esmalte epóxico, lijas, masillas.

H. MAESTRANZA Fabricación de bocinas y ejes, rectificación de componentes, corte mecanizado. Herramientas:

Torno, Máquina de corte CNC.

Insumos:

Boquilla de corte, Lijas, limas rotativas.



2.3 Análisis de requisitos

Luego de tener el panorama básico de las necesidades del taller, se identificaron,

en un nivel de detalle, los requisitos funcionales de la solución especialmente

mediante la observación de los procesos a modelar.

Primero se definió una escala de prioridades de requisitos. Esta escala permite

priorizar la ejecución de unos sobre otros con menor importancia, mayor grado de

dificultad, lo cual delimitara el alcance del sistema.

A continuación, mediante una lluvia de ideas entre el analista y el jefe del área, se

generó la lista de requisitos que debería cumplir el sistema. Luego, se empezó a

determinar subjetivamente los grados de dificultad y prioridad por cada uno.

Finalmente, la lista definitiva de requisitos es la que se presenta a continuación:

Leyenda

Dificultad Prioridad

Valo

r

Descripción Valo

r

Descripción

1 Alta 1 Alta

2 Media 2 Media

3 Baja 3 Baja


Requisitos Funcionales

Un requisito funcional define una función del sistema. Los requisitos pueden ser: cálculos, detalles técnicos, manipulación de datos, etc. Los requisitos del sistema establecerán los comportamientos del sistema. A continuación, se especifican cartillas con la información de los requisitos funcionales identificados de mayor relevancia.

RF1 Mantener un catálogo de equipos.Descripción El analista deberá incluir la funcionalidad al sistema

para el mantenimiento de la base de equipos.Requisitos asociadosDatos Específicos Unidad Minera

NombreMarcaModeloSerieAñoFecha de ingreso

Prioridad Muy alta

RF2 Mantener un catálogo de componentes.Descripción El analista deberá incluir la funcionalidad al sistema

para el mantenimiento de la base de componentes.Requisitos asociadosDatos Específicos Código de almacén

DescripciónSistemaCódigo VPUnidad de medida

Prioridad Muy alta

RF3 Mantener un catálogo de actividades de mantenimiento.

Descripción El analista deberá incluir en el sistema el catálogo de actividades de mantenimiento según el detalle requerido.

Requisitos asociados Código de actividadÁrea

Datos Específicos Catálogo de actividadesPrioridad Muy alta

RF4 Mantener una base de componentes con vida propia.


Descripción El analista deberá incluir en el sistema el catálogo de componentes con vida propia.

Requisitos asociados RF1Datos Específicos Identificación de componentes con vida propiaPrioridad Muy alta

RF5 Registrar recepciones de componentes.Descripción El sistema deberá permitir el registro de las

recepciones de componentes que llegar al taller.Requisitos asociados RF1Datos Específicos Unidad Minera emisora.

Fecha de Salida.Fecha de ingreso a almacén.Guía de remisión.Cantidad.Unidad de medida.

Prioridad Muy alta

RF6 Registrar órdenes de servicio.Descripción El sistema deberá permitir el registro de las órdenes

de servicio que solicita el planner de mantenimiento.Requisitos asociados RF1, RF2Datos Específicos Unidad Minera

EquipoComponenteCantidadFecha de emisión

Prioridad Muy alta

RF7 Registrar órdenes de trabajoDescripción El sistema deberá permitir el registro de las órdenes

de trabajo que se requiere para procesar el componente.

Requisitos asociados RF1, RF2, RF3, RF6, RF5Datos Específicos Fecha de emisión

Fecha de inicioFecha de finDescripciónResponsableActividades

Prioridad Muy alta


RF8 Registrar despachosDescripción El sistema deberá permitir el registro de los despachos

que se requiere para regresar el componente a la unidad minera que lo requiera.

Requisitos asociados RF1,RF2,RF3,RF4,RF5,RF6,RF7,RF9Datos Específicos Guía de remisión

Fecha de salidaDestinoNotaOrden de servicio asignada con OT cerrada

Prioridad Muy alta

RF9 Asignar componentes a órdenes de servicioDescripción Los componentes que llegar no siempre serán

asignados a la unidad minera emisora. Podran utilizados para atender ordenes de servicio de mayor prioridad.

Requisitos asociados RF6, RF7Datos Específicos Fecha de asignación

Componente recepcionadoOrden de servicio asignadaCantidad de asignación

Prioridad Muy alta

RF10 Reportar RecepcionesDescripción El sistema deberá permitir reportar la lista de

recepciones registradasRequisitos asociados RF5Datos Específicos Recepción

EquipoUMFecha InicioFecha Fin

Prioridad Muy alta

RF11 Reportar Orden de ServicioDescripción El sistema deberá permitir reportar la lista de órdenes

de Servicio registradosRequisitos asociados RF6Datos Específicos Orden de Servicio

UsuarioEquipoCodigo de materialDescripcion de material


Unidad MineraFecha InicioFecha Fin

Prioridad Muy alta

RF12 Reportar Orden de trabajoDescripción El sistema deberá permitir reportar la lista de órdenes

de trabajos registradosRequisitos asociados RF7Datos Específicos Código OT

ÁreaProcesoEmpleadoCódigo almacénFecha InicioFecha Fin

Prioridad Muy alta

RF13 Reportar DespachosDescripción El sistema deberá permitir reportar la lista de

despachos registradosRequisitos asociados RF8Datos Específicos Código Despacho

Fecha emisiónFecha salidaCódigo de almacénDescripción

Prioridad Muy alta

A continuación se resumen todos los requisitos funcionales identificados:N

°Modulo Descripción

Dificulta

d

Priorida

d

1

Mantenimient

o

El sistema permitirá el mantenimiento de los equipos y

componentes.3 1

3El sistema permitirá el mantenimiento de actividades de

mantenimiento.3 2

4El sistema permitirá el mantenimiento de componentes con

vida propia.3 1

5Planeamiento El sistema permitirá el registro de recepciones de

componentes.3 1

6 El sistema permitirá el registro de órdenes de servicio 1 2

7 El sistema permitirá el registro de órdenes de trabajo 1 1


8 El sistema permitirá el registro de despachos. 2 2

9El sistema permitirá asignar recepciones a órdenes de

servicio2 2

1

0

El sistema permitirá la eliminación de recepciones de

componentes y equipos.2 1

1

1El sistema permitirá la eliminación de órdenes de servicio 2 1

1

2El sistema permitirá la eliminación de órdenes de trabajo 2 1

1

3El sistema permitirá la eliminación de despachos. 2 1

1

4

El sistema permitirá visualizar la cola de órdenes de servicio

pendientes de atención.3 1

1

5

El sistema permitirá visualizar la cola de órdenes de trabajo

abiertas.3 2

1

6El sistema permitirá cerrar las órdenes de trabajo. 3 2

1

7

El sistema calculara el tiempo promedio y desviación

estándar por actividad de mantenimiento3 3

1

8

El sistema permitirá asociar varias recepciones o

recepciones parciales por cada orden de servicio.1 2

2

0

Reportes

El sistema permitirá generar reporte de recepciones 2 1

2

1El sistema permitirá generar reporte de órdenes de servicio 2 1

2

2El sistema permitirá generar reporte de órdenes de trabajo 2 1

2

3El sistema permitirá generar reporte de despachos. 2 1

Requisitos no funcionales

RN1 Interactuar con una interfaz gráfica amigable y eficiente

Descripción La interfaz gráfica debe ser lo más sencilla posible para que los ingresos y los reportes se generen de forma rápida.

Requisitos asociadosDatos Específicos Características de entidades

Roles de usuarioPrioridad Muy alta


RN2 Sincronizar la fecha y hora del sistema con la del equipo.

Descripción La fecha y hora del sistema provendrá del equipo de cómputo.

Requisitos asociadosDatos Específicos Fecha de sistema

Hora de sistemaPrioridad Muy alta

RN3 Administrar cambios rápidamente sin tener que ingresar al sistema

Descripción El acceso a las bases de datos deberá ser independiente al sistema, en caso no estar programado en el sistema.

Requisitos asociadosDatos Específicos Administrador de bases de datos SQLPrioridad Muy alta

A continuación se resumen los requisitos no funcionales:

N

°

DESCRIPCION Dificulta

d

Priorida

d

1 El usuario interactuara con una interfaz gráfica basada en

controles .NET framework.

2 3

2 El sistema trabajara con la hora del sistema para grabar

fechas y horas.

3 2

3 El sistema trabajara con el administrador de base de datos

SQL Server.

1 1


Consideraciones sobre el sistema

Como alcance de la propuesta quedan excluidas las automatizaciones de los

procesos de compras, gestión de materiales y stock, gestión de personas, gestión

de mantenimiento preventivo, programado y predictivo. En contraparte se

respetaran las siguientes restricciones:

Validación: La información ingresada por teclada es verificada como medida

preventiva ante posibles errores en el proceso.

Seguridad: Acceso al sistema a personas mediante cuentas de usuario y

contraseña. En función a los perfiles y accesos se controlara el nivel de visibilidad

de la información.

Escalabilidad: La arquitectura modular posibilitara la incorporación de nuevas

funcionalidades sin procedimientos drásticos para el desarrollador.

Usabilidad: Para la familiarización del usuario con el software se requiere de una

interfaz gráfica ligera e intuitiva sumada a una correcta emisión de avisos de error

y advertencia. El usuario iniciara todas las operaciones requeridas.

Performance: Garantizar un tiempo de acceso no mayor a siete (10) segundos.

Como consecuencia de la experiencia propia y conocida de los procesos del área

de mantenimiento, e presenta a continuación los participantes del sistema:

Usuario: Toda persona con una cuenta y accesos autorizados al sistema.

Administrador: Es un usuario especial que realiza funciones tales como

administrar cuentas, perfiles de usuario y monitorear el funcionamiento del

sistema.


2.4 Análisis Técnico – Económico

Después de definir los requerimientos del sistema, es necesario determinar su

factibilidad. A continuación se determina la factibilidad técnica y económica de la

solución.

2.4.1 Análisis técnico

Para la viabilidad técnica se presentan las restricciones en hardware y

software con miras a la construcción de la solución planteada, así como su

disponibilidad. Con la salvedad del software de ofimática (Excel, Word) para

labores documentarias, las restricciones técnicas identificadas son las

siguientes:

A. Recursos en Hardware

REQUERIMIENTO SOLUCION

Disponibilidad del equipo de cómputo/

servidor para albergar a la base de

datos.

Equipo personal procesador

Intel Core i3 2.20 GHz. 6 GB

de Memoria RAM con sistema

operativo Windows 8 de 64

bits.

Se tiene disponible 335 Gb en

el disco duro para

almacenamiento de la base de

datos.

Disponibilidad del equipo de cómputo

para las labores de análisis, diseño,

construcción y pruebas.

Los requerimientos de IDEs comunes

(Visual Studio o Netbeans) son:

Procesador Pentium III entre 600-800

Mhz, 750 MB – 900 MB de

almacenamiento, 100MB a 512 MB de

RAM.

B. Recursos en Software

REQUERIMIENTO SOLUCION

Herramientas IDE para la

construcción de la interfaz

gráfica y codificación de las

Se cuenta con la versión 2012 del

software de desarrollo Microsoft Visual

Studio.


funcionalidades bajo el lenguaje

VB.NET.

Herramientas CASE para la

generación de los diagramas de

modelado UML.

Existen en el mercado software de

modelamiento UML como Visual

Paradigm CE, pero, en este caso, se

utilizara las opciones de modelamiento

de arquitectura que ofrece Visual Studio

2012.

Sistema administrador de base

de datos de libre distribución

con capacidad para soportar

múltiples conexiones.

Se hará uso del motor de base de datos

que ofrece la versión 2012 de Microsoft

SQL Server y de la herramienta de

administración de bases de datos

Microsoft SQL Server Management

Studio del mismo paquete.

El lenguaje de programación y

sus características para la

construcción bajo el paradigma

orientado a objetos.

La elección recae sobre el lenguaje de

programación Visual Basic

implementada sobre el framework .NET

de Microsoft.

C. Habilidad técnica

En conclusión, el proyecto no tiene restricciones que no presenten una

solución y es factible desde el punto de vista técnico.


2.4.2 Análisis Económico

Los beneficios del CMMS y el retorno de la inversión (ROI) proveniente

del CMMS pueden ser difícil de calcular y la transición de un sistema de

gestión del mantenimiento “manual” a un CMMS puede demandar una

inversión significativa.

El ROI proveniente de la implementación de un CCMS dependerá de la

adecuación del CMMS seleccionado, la efectividad de la implementación y

el compromiso del personal que está incluido en la implementación y uso

del nuevo sistema.

En líneas generales, se puede esperar una reducción del presupuesto de

mantenimiento de un 5% a un 15% (Perspective CMMS, 2013).

Según Joel Levitt, director de proyectos internacionales de Life Cicle

Engineering, la implementación efectiva de un CMMS debería disminuir los

costos de mantenimiento en un 30%. (Levitt, 2014).

A. Método de evaluación

Debido a la falta de un método preciso para determinar los beneficios de

la implementación de un CMMS y a la falta de información de los costos

de mantenimiento de la organización analizada, se tomó por conveniente

utilizar el método de punto de equilibrio para determinar la factibilidad

económica de la propuesta por medio del análisis del costo de

mantenimiento necesario que debe generar la empresa para que la

reducción de costos por la aplicación del sistema desarrollado sea mayor

a los costos de desarrollo e implementación del sistema.

B. Determinación del costo

Recursos Tecnológicos

Los requisitos a nivel de hardware se encuentran excluidos asumiendo su

aprovisionamiento bajo la responsabilidad del tesista.


Las herramientas CASE para el modelamiento UML y de la base de datos

permanecen libres de costos.

Las herramientas IDE y el sistema administrador de base de datos no

representaron un costo considerable para la investigación y por lo tanto,

al igual que las herramientas CASE, no se distribuyen en el costo del

proyecto.

Recursos Humanos

La siguiente tabla muestra el costo estimado por concepto de

contratación de personal (según roles y funciones) durante la realización

del proyecto.

Tabla 5 Costo de RR.HH. del proyecto

Puesto Funciones CantC Unit

(S/.Hr.)

Etapa de

Proyecto

Analista

Funcional

Levantamiento de

procesos.

Levantamiento de

requerimientos.

Modelamiento del

sistema.

1 8Planificación

y análisis

Programado

r VB.NET

Construcción de los

módulos del

sistema.

1 8 Construcción

Estos costos son asumidos por el tesista que desempeñara ambos

puestos. El costo estimado se tomó de un promedio de la subvención

económica de un practicante o asistente de sistemas de corta experiencia

(1200 Soles mensuales). El costo es relativamente bajo para el mercado

debido a que el tiempo estimado considera la curva de aprendizaje de las

herramientas de programación requeridas para la elaboración, por

consiguiente, los tiempos estimado contienen alto porcentaje de

contingencia.


Energía

Los costos de la energía se han tomado como costos directos en función

a la siguiente formula:

Costo=(Watts× Horas1000 )×CostoKwhY los siguientes supuestos:

Consumo equipo

de computo45 W = 0.045 Kw

Tarifa energía activa

al 4Jul2015S/. 0.4358 por Kwh

Costo energía por

horaS/. 0.0196 por hr o S/.0.02 por hr

Del mismo modo, la siguiente tabla muestra los costos estimados para la

realización del proyecto.

Tabla 6 Etapas del proyecto

Nombre de tarea Comienzo Fin

PROYECTO 12/04/14 07/03/15

ETAPA 0:

PLANIFICACION12/04/14 17/04/14

ETAPA 1:

GENERALIDADES17/04/14 20/04/14

ETAPA 2:

ALCANCE Y

RIESGOS

20/04/14 27/04/14

ETAPA 3:

ANALISIS Y DISEÑO27/04/14 24/05/14


ETAPA 4:

CONSTRUCCION24/05/14 04/10/14

ETAPA 5:

TRANSICION04/10/14 07/03/15

Se resume los costos del proyecto en la siguiente estructura de costos:

Tabla 7 Estructura de Costos

Nombre de tarea Duración Costo

ETAPA 0: PLANIFICACION 25 horas S/. 230.43

ETAPA 1: GENERALIDADES 29 horas S/. 232.30

ETAPA 2: ALCANCE Y RIESGOS 24 horas S/. 192.40

ETAPA 3: ANALISIS Y DISEÑO 66 horas S/. 529.32

ETAPA 4: CONSTRUCCION 380 horas S/. 3,047.60

ETAPA 5: TRANSICION 90 horas S/. 801.80

TOTAL 614 horas S/. 5,033.85

C. Viabilidad económica

Según el análisis del costo realizado anteriormente, es posible realizar las

siguientes estimaciones:

Además de los costos vinculados a la implementación del sistema. Se

estimaron los costos de mantenimiento de la operatividad del sistema:

Tabla 8 Estimación del costo de mantenimiento del sistema


Asumiendo un factor de 60% por concepto de mantenimiento sobre el costo total del sistema obtenemos un costo final para

la organización de 4,059.68 USD.

Debido al dinamismo de los sistemas, el periodo de vida útil del sistema está estimado para 3 años, luego del cual es

necesario evaluar si el proceso se ha transformado significativa o si los costos de mantenimiento ha variado

considerablemente para poder decidir si continuar o no con el sistema o migrar hacia una nueva solución. A continuación

evaluamos el ahorro generado por la implementación del sistema:

Tabla 9 Análisis de escenario por la implementación del sistema


En base al costo del sistema, podemos determinar a cuánto debe ascender el

costo de mantenimiento de la organización para poder generar una utilidad

económica por la decisión de implementar el sistema.

En el presenta caso, según las premisas efectuadas por Perpective CMMS y Joel

Levitt, se han determinado 9 escenarios según el tamaño de la organización y la

tasa de reducción en el costo de mantenimiento. Según la tabla mostrada, vemos

que implementar la presente solución de mantenimiento no es económicamente

factible sólo en el caso que se desarrolle en una microempresa y se obtenga solo

un 5% de ahorro en el costo. No se consideró acertado una evaluación del costo

beneficio para medianas empresas puesto que la complejidad de sus operaciones

de mantenimiento están fuera del alcance de la solución establecida y por lo tanto

el costo de implementación pueda ser mucho mayor.

Concluimos que la solución presentada es económicamente viable puesto que el

costo de implementación y mantenimiento se encuentra por debajo del ahorro

generado en la mayoría de los escenarios considerados.


2.5 Análisis de riesgos

Luego de que la solución a los requerimientos sea definida como técnica y

económicamente viable, es esencial identificar otras variables propias de la

incertidumbre que no fueron consideradas en la evaluación técnico económica y

que pueden afectar el resultado final de la solución. Estas variables, denominadas

riesgos, deben ser controladas a lo largo de la fase de construcción y transición. A

continuación, se clasifican en función al grado de severidad y probabilidad.

Tipos de riesgo

En el PMBOK se define riesgo como un evento incierto cuya ocurrencia provoca

efectos en los objetivos del proyecto repercutiendo en el alcance, cronograma

costo y calidad (PMI, 2008). El riesgo puede ser clasificado como:

Riesgos técnicos, de calidad y/o de rendimiento (R-TEC):

Este grupo se encuentra presente durante las actividades de diseño y

desarrollo del producto deseado y en donde intervienen aspectos de

carácter técnico en su elaboración y control de calidad.

Riesgos en la gerencia de proyectos (R-DIR):

Son riesgos presentes en parte de los procesos de gestión y dirección

llevados a cabo. Su manejo queda bajo la responsabilidad del equipo del

proyecto.

Riesgos organizacionales (R-ORG):

Son riesgos provenientes de la misma organización laboral o profesional a

quienes el proyecto y/o producto impacta directa o indirectamente en sus

funciones.

Riesgos externos (R-EXT):

Son riesgos provenientes del ámbito exterior (entorno) de la organización.

A continuación se presenta una lista de riesgos que podrían presentarse en el

desarrollo del proyecto. Como se puede observar, en la fase de iniciación el

riesgo más severo es la subestimación de requerimientos en más de 20%. En la

fase de análisis, el riesgo más importante es no haber identificado correctamente

los casos de uso, en la fase de transición el riesgo más severo es la sub

estimación de la habilidad para emplear las herramientas de programación. En la


fase de transición, la cual no se encuentra dentro del alcance de esta

investigación, el riesgo más importante es que el personal no tome decisiones en

base a la información del sistema o que se considere esta poco confiable.

Probabilidad (P) Impacto (I) Severidad (S)

Rango Descripción Rango Descripción Rango Descripción

0.25 Baja 0.25 Leve 0.25 Baja

0.50 Media 0.50 Moderado 0.50 Media

0.75 Alta 0.75 Severo 0.75 Alta

1.00 Muy alta 1.00 Muy Severo 0.50 Media

Ilustración 27 Tabla de evaluación de riesgos


Listado de riesgos

Tabla 10 Listado de Riesgos

Grupo

riesgoDescripción del riesgo

Restricción

primariaP I S

FASE I: INICIACION

R-Dir Costo real del sistema por encima del 15% del estimado. Costo 0.5

0

0.25 0.13

R-Dir Más del 20% de Actividades del proyecto no identificadas. Tiempo 0.2

5

0.50 0.13

R-Ext Eventos externos al proyecto no identificados en el calendario del proyecto que

suman más del 20% del total de las horas asignadas al proyecto.

Tiempo 0.7

5

0.25 0.19

R-Dir Subestimación de la duración de actividades identificadas proyecto que suman

más del 20% del total de horas asignadas al proyecto.

Tiempo 0.7

5

0.25 0.19

R-Dir Más del 20% de Requerimientos no identificados para el sistema. Calidad 0.5

0

0.75 0.38

FASE 2: ANALISIS Y DISEÑO

R-Tec Arquitectura del sistema que incrementa las tiempos estimados de

mantenimiento del sistema en 20%.

Costo 0.2

5

0.75 0.19

R-Tec Más del 20% de clases identificadas en la fase de construcción. Tiempo 0.2

5

0.50 0.13

R-Tec Algún caso de uso identificado en la fase de construcción. Tiempo 0.5

0

0.75 0.38


R-Tec Más del 20% de entidades identificadas en la fase de construcción. Tiempo 0.2

5

0.50 0.13

R-Tec 20% del número total de pruebas no identificadas. Calidad 0.5

0

0.50 0.25

FASE 3: CONSTRUCCION

R-Tec Clases y entidades no alineadas a la arquitectura diseñada para el sistema. Calidad 0.2

5

0.75 0.19

R-Tec 20% sobre el tiempo del proyecto, invertido en aprendizaje de herramientas de

programación.

Tiempo 0.7

5

0.50 0.38

R-Tec Una o más de una solución no encontrada para satisfacer un requerimiento del

sistema.

Calidad 0.2

5

0.75 0.19

R-Tec Malas prácticas de programación generando un sobrecosto del mantenimiento

del sistema de más de 20%.

Costo 0.2

5

0.50 0.13

FASE 4: TRANSICION

R-Org Transformación significativa del proceso de mantenimiento modificando

consecuentemente más del 50% de los requerimientos del sistema.

Calidad 0.2

5

1.00 0.25

R-Org Falta de compromiso para el registro de información en el sistema. Calidad 0.5

0

1.00 0.5

R-Org Personal no toma acción en base a la información generada por el sistema. Calidad 0.7

5

1.00 0.75


3. CAPITULO III DISEÑO

El diseño de la arquitectura de un sistema es el proceso por el cual se define una

solución para los requisitos técnicos y operacionales del mismo. (de la Torre Llorente,

Zorrilla Castro, Barros Ramos, & Calvarro Nelson, 2010). Este proceso define que

componentes forman el sistema, como se relacionan y como llevan a cabo la

funcionalidad esperada.

3.1 Arquitectura de la solución

A continuación, se definen la arquitectura de la solución presentando la

representación de la arquitectura, la vista lógica y vista de despliegue de la

solución, la estructura de las clases de diseño, los diagramas de secuencia y por

último la estructura de la base de datos (tablas, vistas, diagramas).

3.1.1 Representación de la arquitectura

La solución se presenta desde el punto de vista físico es de 1 cliente-

servidor (one-tier application), donde tanto la interfaz de usuario, el

procesamiento de datos y la base de datos se encuentran dentro de un

único servidor o equipo de cómputo. La arquitectura adopta el patrón de

arquitectura en 3 capas, comprende la implementación de la presentación

(PresentationLayer) , la lógica del negocio(BusinessLayer) y la capa de

acceso a datos (DataAccessLayer). Este diseño es altamente escalable y

permite la incorporación de nuevos módulos y funcionalidades en el futuro.


Ilustración 28 Arquitectura del sistema


A. Presentation Layer

En esta capa encontramos la estructura de la interface de la solución, la

cual comprende los siguientes objetos:

Resources: Librería de imágenes (.jpg, .png, .bmp) que nos servirán para

la implementación de la simbología que utilizaremos en los botones y

demás controles que utilizara el usuario.

Formularios: Conjunto de formularios (Forms) que servirán como la

interfaz de usuario que comunicara las acciones del usuario al sistema y

permitirá inicializar los procedimientos de ejecución del código de la capa

de negoco y consecuentemente de la capa de acceso a la base de datos.

Asimismo, estos formularios generan la estructura principal de navegación

del usuario lo que lo llevara a realizar las operaciones de registro,

actualización o eliminación de los datos en la base datos.

Tabla 11 Lista de Formularios

Formulario Modulo Tarea

FrmInicio Acceso Pantalla de Inicio y menú de

Opciones.

FrmIniciarSesion Acceso Ingresa el usuario y contraseña.

FrmEquipos_Mantenimiento Mantenimiento Mantenimiento Equipos

FrmComponentes_Mantenimiento Mantenimiento Mantenimiento Componentes

FrmComponentesVP_Manenimient

o

Mantenimiento Mantenimiento ComponentesVP

FrmEmpleados_Mantenimiento Mantenimiento Mantenimiento de Empleados

FrmRecepcion_Registrar Planeamiento Registra Recepciones

FrmRecepcion_Reportar Reportar Reporta Recepciones

FrmRecepcion_Eliminar Planeamiento Eliminar Recepciones

FrmOS_Registrar Planeamiento Registra Orden de Servicio

FrmOS_Reportar Reportar Reporta Orden de Servicio

FrmOS_Eliminar Planeamiento Eliminar Orden de Servicio

FrmAsignacion_Registrar Planeamiento Registra Asignación

FrmAsignacion_Eliminar Planeamiento Elimina Asignación


FrmOT_Registrar Planeamiento Registra Orden de Trabajo

FrmOT_Actualizar Planeamiento Actualiza Orden de trabajo

FrmOT_Reportar Reportar Reporta Orden de Trabajo

FrmOT_Eliminar Planeamiento Eliminar Orden de Trabajo

FrmOT_Cerrar Planeamiento Cierra Orden de Trabajo

FrmDespachos_Registrar Planeamiento Registra Despachos

FrmDespachos_Reportar Reportar Reporta Despachos

FrmDespachos_Eliminar Planeamiento Eliminar Despachos

B. Business Layer

Contiene los objetos que servirán de comunicación entre la capa de

presentación y la capa de acceso a la base de datos. Se han modulado

cada entidad requerida por el sistema y vinculado las propiedades,

procedimientos y funciones de cada una con las correspondientes en la

capa de acceso a datos.

Tabla 12 Lista de Entidades

No

.Nombre Descripción

1 AsignacionOS.vb Clase que mapea las propiedades y métodos a partir de la

entidad AsignacionOS de la base de datos.

2 Componente.vb Clase que mapea las propiedades y métodos a partir de la

entidad Componente de la base de datos.

3 ComponenteVP,vb Clase que mapea las propiedades y métodos a partir de la

entidad ComponenteVP de la base de datos.

4 Despacho.vb Clase que mapea las propiedades y métodos a partir de la

entidad Despacho de la base de datos.

5 DespachoDetalle.vb Clase que mapea las propiedades y métodos a partir de la

entidad DespachoDetalle de la base de datos.

6 Empleado.vb Clase que mapea las propiedades y métodos a partir de la

entidad Empleado de la base de datos.

7 Entidad.vb Clase que mapea los métodos que permiten conocer el

próximo identificador de cualquier entidad del sistema.

8 Equipo.vb Clase que mapea las propiedades y métodos a partir de la

entidad Equipo de la base de datos.

9 Especialidad.vb Clase que mapea las propiedades y métodos a partir de la


entidad Especialidad de la base de datos.

11 Modulo.vb Clase que mapea las propiedades y métodos a partir de la

entidad Modulo de la base de datos.

12 OrdendeServicio.vb Clase que mapea las propiedades y métodos a partir de la

entidad OrdendeServicio de la base de datos.

13 OrdendeServicioDetalles.vb Clase que mapea las propiedades y métodos a partir de la

entidad OrdendeServicioDetalles de la base de datos.

14 OrdendeTrabajo.vb Clase que mapea las propiedades y métodos a partir de la

entidad OrdendeTrabajo de la base de datos.

15 OrdendeTrabajoDetalles.vb Clase que mapea las propiedades y métodos a partir de la

entidad OrdendeTrabajoDetalles de la base de datos.

16 Recepcion.vb Clase que mapea las propiedades y métodos a partir de la

entidad Recepcion de la base de datos.

17 RecepcionDetalles.vb Clase que mapea las propiedades y métodos a partir de la

entidad RecepcionDetalles de la base de datos.

18 UnidadMinera.vb Clase que mapea las propiedades y métodos relacionados a la

Unidad Minera a partir de la entidad Equipos de la base de

datos debido a que Unidad Minera no se consideró como una

entidad individual en la base de datos.


C. Data Access Layer

Contiene dos objetos principales que son:

LINQ.dbml: Es un objeto que se basa en las tablas de una base de datos

relacional para modelar las entidades que posteriormente serán llamadas

por las clases del Business Layer.

ClasesLINQ.vb: Es una clase que contiene todos los procedimientos y

funciones usando la estructura de sentencias LINQ. Esta clase utiliza la

clase LINQDATACONTEXT que fue la que se genera después de haber

mapeado las tablas y relaciones cargadas en el diagrama LINQ.dbml.

Estos procedimientos y funciones nos servirán de base para generar los

métodos de los objetos que generaremos en la capa de negocio.

Ilustración 29Objeto CLASESLINQ


Ilustración 30LINQ.dbml


Ilustración 31 Entidad LINQ.dbml

3.1.2 Diseño de la arquitectura de la solución


A. Vista lógica

Muestra los componentes principales de diseño y las relaciones de forma

independiente de los detalles técnicos y de cómo la funcionalidad será

implementada en .NET Framework. A continuación, se describe la

solución en términos de paquetes y clases de diseño. Dentro de esta vista

se describe la Realización de los Casos de uso, subsistema, paquetes y

clases más significativos arquitectónicamente. La siguiente figura muestra

este tipo de descripción.

Ilustración 32 Vista lógica


O/R Clases

O/R Designer

Especialidades

Módulos

Unidad Minera

Empleados

Orden de Trabajo

Orden de Servicio

Recepción

Equipos

Componentes

SQL to LINQclasses

CLASESLINQ

Data Access Layer

Reports Resources (jpg. bmp.etc)

Forms

Presentation Layer

Business Layer

Base de datos (Tables, views, store procedures)

B. Vista de despliegue

Sobre esta vista se modela la disposición física del software. Nuestro

sistema centralizara el ingreso y salida de información en una sola

estación cliente la cual también servirá de repositorio de la base de datos.

Por consiguiente podemos definir nuestro sistema como un sistema

cliente/servidor en un solo equipo de cómputo. Se optó por esta

arquitectura por estar dentro de los recursos técnicos disponibles y por no

requerir más de una persona para su mantenimiento. La funcionalidad

adicional de ser un sistema cliente/servidor que se emplea en múltiples

estaciones cliente es una mejora que se deberá desarrollar cuando el

sistema sea más complejo y requiera más de una persona para el ingreso

de la información.

Esta configuración, agrupa los componentes del sistema como es la

aplicación (el ejecutable del sistema), las diferentes capas del sistema y el

motor de base de datos de SQL Server.

Ilustración 33 Vista de despliegue


3.1.3 Diagrama de clases de diseño

Existen más de 15 clases utilizados en la capa de negocio, a continuación

se presentaran individualmente a través de paquetes representando las

relaciones de mayor importancia, posteriormente, se presentaran las clases

en conjunto para exponer sus relaciones.

A. Paquete Recepción

Este paquete contiene las clases que registran información sobre la

recepciones de componentes. Algunas propiedades relevantes son la

Unidad Minera emisora, el Equipo al que pertenecieron, si presentan

algún componente con vida propia, la fecha de salida de la unidad

minera, la fecha de ingreso al almacén, etc. Asimismo, contiene los

métodos con los cuales actualizar, insertar, eliminar o listar las

recepciones ingresadas a la base de datos. Como se muestra en el

gráfico, el registro de una recepción utiliza dos clases, una para

almacenar datos generales de la recepción (cabecera) y otra para los

componentes que están contenidos en la recepción (detalles).

Paquete Recepcion

Recepcion

Attributes

+ ALFching+ CodRecep+ GR+ IDRecepcion+ SolicitanteID+ UMEmisor+ UMFchsal

Operations

+ Actualizar()+ Eliminar()+ Insertar()+ Listar()+ Listar_a_Eliminar()

RecepcionDetalles

Attributes

+ Cantidad+ ComponenteID+ CompVPID+ EquipoID+ IDRecepcionDetalles+ RecepcionID+ Serie+ Unidad

Operations

+ Eliminar()+ Insertar()+ Listar()+ Listar_a_Eliminar()+ Reportar(p : String)

1 *

Contiene

Ilustración 34 Paquete Recepción


B. Paquete Orden de servicio

Este paquete contiene las clases que registran información sobre las

órdenes de servicio. Algunas propiedades relevantes son la fecha de

emisión, fecha de cierre de la orden, unidad minera receptora, equipo,

cantidad por componente, etc. Asimismo, contiene los métodos con los

cuales actualizar, insertar, eliminar, listar o reportar las órdenes de

servicio ingresadas a la base de datos. Como se muestra en el gráfico, el

registro de una orden de servicio utiliza dos clases, una para almacenar

datos generales de la orden de servicio (cabecera) y otra para los

componentes que están siendo solicitados en la orden de servicio

(detalles).

Paquete OrdendeServicio

OrdendeServicio

Attributes

+ CodOS+ FchCierre+ FchEmision+ IDOS+ SolicitanteID+ UMReceptora

Operations

+ Eliminar()+ Insertar()+ Listar()+ Listar_a_Eliminar()

OrdendeServicioDetalles

Attributes

+ Cantidad+ ComponenteID+ EquipoID+ ID+ OSID+ Serie+ Unidad

Operations

+ Eliminar()+ EliminarsegunRecepcion()+ Insertar()+ Listar()+ ListarAsignadas()+ ListarAsignadas_con_OTCerradas()+ Listar_a_Eliminar()

1 *

contiene

Ilustración 35 Paquete Orden de Servicio


C. Paquete Orden de trabajo


órdenes de trabajo. Algunas propiedades relevantes son la descripción

del trabajo, la fecha de emisión, fecha de inicio, fecha de término, la

especialidad del trabajo a ejecutar, el responsable del trabajo,etc.

Asimismo, contiene los métodos con los cuales actualizar, insertar,

eliminar, listar o reportar las órdenes de trabajo ingresadas a la base de

datos. Como se muestra en el gráfico, el registro de una orden de trabajo

utiliza dos clases, una para almacenar datos generales de la orden de

trabajo (cabecera) y otra para los componentes que están siendo

solicitados en la orden de trabajo (detalles).

Paquete Orden de Trabajo

OrdendeTrabajo

Attributes

+ CodOT+ Descripcion+ FchEmision+ FechaFin+ FechaInicio+ idOT+ Responsable

Operations

+ Eliminar()+ Insertar()+ Listar()+ Listar_a_eliminar()

OrdendeTrabajoDetalles

Attributes

+ ClaveEspecialidad+ CodOTDetalles+ FechaFin+ FechaInicio+ ID+ OSID+ OTID+ Pos+ SubResponsable

Operations

+ Actualizar()+ eliminar()+ Insertar()+ Listar()+ Listar_a_Actualizar()+ Listar_a_Eliminar()+ Reportar(pOT : String, pArea : String, pProceso : String, pCodalmacen : String, pSubresponsable : Integer, pFchinicio : DateTime, pFchFin : DateTime)

1 *

Contiene

Ilustración 36 Paquete Orden de Trabajo


D. Paquete Despacho


órdenes de trabajo. Algunas propiedades relevantes son la Fecha de

emisión, fecha de salida, la guía de remisión, la descripción del despacho,

la Unidad minera receptora. Asimismo, contiene los métodos con los

cuales actualizar, insertar, eliminar, listar o reportar los despachos

ingresadas a la base de datos. Como se muestra en el gráfico, el registro

de un despacho utiliza dos clases, una para almacenar datos generales

del despacho (cabecera) y otra para los componentes que están siendo

enviados en el despacho (detalles).

Paquete Despachos

Despacho

Attributes

+ CodDespacho+ FchEmision+ FchSalida+ GR+ IdDespacho+ Texto+ UMReceptor+ UsuarioId

Operations

+ Eliminar()+ Insertar()+ Listar_a_Eliminar()

DespachoDetalles

Attributes

+ CodDespachoDetalles+ IdDespacho+ IDDespachoDetalles+ IdOSDetalles+ Serie

Operations

+ Eliminar()+ Insertar()+ Listar_a_Eliminar()+ Reportar(pCodDespacho : String, pCodAlmacen : String, pdescripcion : String, pFchInicio : DateTime, pFchFin : DateTime)

1 *

Contiene

Ilustración 37 Paquete despacho


E. Paquete componente

Este paquete contiene las clases que registran información sobre los

componentes. Algunas propiedades relevantes son la el código de

almacén, la descripción, la fecha de codificación de componente con vida

propia, la fecha de creación de componente, la unidad de medida y el

sistema al que pertenecen. Asimismo, contiene los métodos con los

cuales actualizar, insertar, eliminar, listar o reportar los componentes o

componentes VP ingresados a la base de datos. Como se muestra en el

gráfico, el registro de un componente puede utilizar dos clases,

dependiendo de si el componente fue definido o no como componente

con Vida propia. Una vez que el componente es definido con vida propia,

este empieza a ser registrado uno a uno.

Paquete componente

Componente

Attributes

+ Activo+ CodAlmacen+ CodComponenteVP+ CodificacionVP+ Descripcion+ FechaCodificacionVP+ FechaCreacionComponente+ IDComponente+ Sistema+ UM

Operations

+ Actualizar()+ ComprobarComponentesVP_vinculados()+ Eliminar()+ Insertar()+ Listar()+ ListarComponentesVP()+ ListarComponentesVPDetalles()+ ListarComponente_segun_descripcion_o_codalmacen(caracteristica : String)+ ListarComponente_segun_id()+ ListarSistemas()+ Siguiente()

ComponenteVP

Attributes

+ AnoFabricacion+ CodAlmacenVP+ CodigoComponenteVP+ Correlativo+ IDCompVP+ Serie

Operations

+ Actualizar()+ Eliminar()+ Insertar()+ Listar()+ Listar_segun_CodAlm()+ Siguiente()+ SiguienteCorrelativo()

1 1

Puede ser

Ilustración 38 Paquete Componente


F. Clase Asignación OS

Para poder empezar a realizar un trabajo en el taller, se requiere que a

una orden de servicio (un requerimiento) se le asigne la recepción de un

componente. Para esto es necesario una clase intermedia que funcione

como puente que vincule las recepciones de componentes con las

ordenes de servicio, a esta clase llamamos asignación OS. Esta clase

presenta propiedades de vinculación como la llave de la Orden de servicio

detalle con la llave de la recepción detalle y otras propiedades como la

fecha de asignación y la cantidad. La cantidad es un parámetro

importante puesto que para que una orden de servicio sea procesada

mediante una orden de trabajo es necesario que sea asignado el 100%

de la cantidad solicitada en la orden de servicio detalle. Esta clase

también tiene métodos que permiten eliminar, listar o insertar

asignaciones registradas en la base de datos.

BusinessLayer::AsignacionOS

Attributes

+ Cantidad+ FechaAsignacion+ IDAsignacionOS+ OSDetallesID+ RecepcionDetalleID

Operations

+ Eliminar()+ Insertar()+ ListarAsignacion_Eliminar()+ ListarOrdenesdeServicioDetalles_sin_Asignacion_o_Pendientes()+ ListarRecepcionesDetalles_Asignadas()+ ListarRecepcionesDetalles_sin_Asignacion_o_Pendientes()

Ilustración 39 Clase Asignación OS


G. Clase Empleado

Esta clase contiene las propiedades y métodos de los trabajadores del

taller. En el encontramos propiedades como apellidos, nombres, fecha de

ingreso, puesto, nombre de usuario y contraseña, etc. Asimismo tenemos

los métodos de actualizar, eliminar, insertar o Listar para el

mantenimiento de la base. Existe un método Isregistered () que nos

permitirá saber si el usuario y password ingresado en el sistema es

correcto.

BusinessLayer::Empleado

Attributes

+ Administrador+ ApellidoMaterno+ ApellidoPaterno+ Contrasena+ Deshabilitado+ Especialidad+ FchIngreso+ FchSalida+ ID+ Nombre+ Permisos+ Puesto+ Supervisor+ Usuario

Operations

+ Actualizar()+ Eliminar()+ Insertar()+ Isregistered()+ Listar()+ ListarUsuarios()+ SiguienteID()

Ilustración 40 Clase Empleado


H. Clase Equipo

Esta clase contiene los atributos y métodos de la información de los

equipos ingresados en la base de datos, como son: el Año, la Fecha de

ingreso, la marca, el modelo, la serie, el nombre, el propietario del equipo

(Si el equipo es de la compañía minera a la que se presta servicio), la

unidad minera a la que presta servicio. Asimismo, se cuenta con los

métodos usuales de mantenimiento de entidades: Listar, insertar,

eliminar, actualizar. El método siguiente ID () nos permitirá conocer la

llave de un equipo nuevo que se piensa ingresar.

BusinessLayer::Equipo

Attributes

+ Activo+ Ano+ FchInicio+ ID+ Marca+ Modelo+ Nombre+ Propietario+ Serie+ UM

Operations

+ Actualizar()+ Eliminar()+ Insertar()+ Listar()+ SiguienteID()

Ilustración 41 Clase Equipo


I. Clase Especialidad

Esta clase que no contiene atributos, lista las especialidades ingresadas

en la base de datos. La especialidad hace referencia a los trabajos a

realizar o ejecutar en la orden de trabajo.

BusinessLayer::Especialidad

Attributes

Operations

+ Listar()

Ilustración 42 Clase Especialidad

J. Clase Unidad Minera

Esta clase que no representa una entidad en la base de datos, lista las

unidades mineras ingresadas al momento de registrar un equipo.

BusinessLayer::UnidadMinera

Attributes

Operations

+ Listar()

Ilustración 43 Clase Unidad Minera


K. Clase Modulo

Esta clase nos permite listar los módulos o funcionalidades de nuestro

sistema según los accesos habilitados por usuario.

BusinessLayer::Modulo

Attributes

Operations

+ Listar()

Ilustración 44 Clase Modulo


L. Relaciones entre Clases


Ilustración 45 Diagrama de Clases

3.1.4 Diagrama de bases de datos

Este diagrama nos permitirá conocer la estructura de la base de datos

generada para la solución. La estructura comprende: Las entidades o

tablas que representan, los campos con la información que utilizaremos

para generar los KPI del área y las relaciones entre cada una de las

entidades.

Para mejorar la descripción del esquema de la base de datos, se ha

dividido el esquema en varias vistas con las tablas con más relaciones

comunes.


A. Diagrama Inicial Sesión

Ilustración 46 Diagrama Iniciar Sesión


B. Diagrama Registrar Recepción

Ilustración 47 Diagrama Registrar Recepción


C. Diagrama Registrar Orden de Servicio

Ilustración 48 Diagrama Orden de Servicio


D. Diagrama Registrar Orden de Trabajo

Ilustración 49 Diagrama Registrar Orden de trabajo


E. Diagrama Registrar Despacho

Ilustración 50 Vista Registrar Despachos


F. Diagrama Asignaciones OS

Ilustración 51 Diagrama Asignaciones OS


G. Otras Vistas

Cuando las sentencias de SQL son demasiado complejas, requieren

una visualización rápido de la salida y no es practico que sean

generadas en la capa de acceso a datos del sistema, se encuentran

en las llamadas vistas de la base de datos. Estas vistas nos permitirán

generar sentencias complejas a través del diseñador de SQL Server.

Finalmente, hacer los filtros necesarios para generar las salidas del

sistema, ellas son:

Ilustración 52 Vistas de la base de datos


H. Vista general del esquema de la base de datos


Ilustración 53 Esquema general de la base de datos


3.1.5 Diagrama de secuencia

Un diagrama de secuencia muestra la interacción de un conjunto de objetos

en una aplicación a través del tiempo y se modela para cada caso de uso.

(Wikipedia, 2015). El diagrama de secuencia contiene detalles de

implementación del escenario, incluyendo los objetos y clases que se usan

para implementar el escenario y mensajes intercambiados entre los objetos.

Los mensajes se dibujan cronológicamente desde la parte superior del

diagrama a la parte inferior; la distribución horizontal de los objetos es

arbitraria.

Existen dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes

sincrónicos se corresponden con llamadas a métodos del objeto que recibe

el mensaje. El objeto que envía el mensaje queda bloqueado hasta que

termina la llamada. Este tipo de mensajes se representan con flechas con

la cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y

crean un nuevo hilo de ejecución dentro de la secuencia. Se representan

con flechas con la cabeza abierta.

También se representa la respuesta a un mensaje con una flecha

discontinua.

A continuación, se muestran algunos diagramas de secuencia

representativos del sistema. Estos diagramas muestran la comunicación

que existen entre los diferentes objetos del sistema. Como vemos la

comunicación se dispara desde la GUI (evento clic de botones

principalmente) que pasa por los objetos de Business Layer el cual

finalmente se comunica con el Data Access Layer que realiza las llamadas

a las bases de datos.


A. Secuencia Insertar Codificación VP

this : FrmCodificarOComponenteVP : ComponenteVPOComponenteVP.DAL : ClasesLINQ

btngrabar_Click

Create ComponenteVP

OComponenteVP

<<return>>

Create ClasesLINQ

DAL

<<return>>

Create LINQDataContext

Insertar

OComponenteVP.Insertar()

<<return>>

InsertarComponenteVP

DAL.InsertarComponenteVP(CodAlmacenVP, Correlativo, Serie, AnoFabricacion, Activo)

<<return>>

Create CodificacionVP

InsertOnSubmit

Ilustración 54 Diagrama de secuencia Insertar Codificación VP


B. Secuencia Actualizar componente

this : FrmComponentesthis.Componente : Componentethis.Componente.DAL : ClasesLINQ

btnActualizar_Click

Actualizar

Componente.Actualizar()

<<return>>

ActualizarComponente

DAL.ActualizarComponente(IDComponente, CodAlmacen, Descripcion, Sistema, CodificacionVP, FechaCreacionComponente, FechaCodificacionVP, UM)

<<return>>

If

[If m = Windows.Forms.DialogResult.Yes Then]

Ilustración 55 Actualizar componente


C. Secuencia Insertar Equipo

this : FrmEquiposthis.Equipo : Equipothis.Equipo.DAL : ClasesLINQ

btnDelete_Click

Eliminar

Equipo.Eliminar()

<<return>>

EliminarEquipo

DAL.EliminarEquipo(ID)

<<return>>

Ilustración 56 Insertar Equipo


D. Secuencia Listar Equipos

this : FrmEquiposthis.Equipo : Equipothis.Equipo.DAL : ClasesLINQsource : IQueryable(Of TSource) qry : IQueryable(Of VB$AnonymousType_0(Of Int32, String, String, String, String, String, Nullable(Of Int32), Nullable(Of DateTime), String, Nullable(Of Boolean)))

FrmEquipos_Load

Listar

Equipo.Listar

<<return>>

ListarEquipos

DAL.ListarEquipos

<<return>>

Distinct(Of VB$AnonymousType...

Distinct

<<return>>

qry.CopyToDataTable

<<return>>

Shred

Ilustración 57 Listar Equipos


E. Secuencia Iniciar Sesión

this : FrmIniciomodulos : Modulomodulos.m : ClasesLINQ

FrmInicio_Load

Create Modulo

modulos

<<return>>

Create ClasesLINQ

m

<<return>>


ListarModulos

modulos.ListarModulos

<<return>>

ListarModulos

m.ListarModulos()

<<return>>

CopyToDa...

Exit

Exit For

ListarMod

modulos.ListarMod

<<return>>

ListarModulos_sin_repetidos

m.ListarModulos_sin_repetidos

<<return>>

ListarMod

modulos.ListarMod

<<return>>



<<return>>

ListarModulos

modulos.ListarModulos

<<return>>

ListarModulos

m.ListarModulos()

<<return>>

ListarMod

modulos.ListarMod

<<return>>



<<return>>

Loop

[For Each Fila In modulos.ListarModulos.Rows]

Loop

[For Each item In MnuOpciones.DropDownItems]

Loop

[For Each fila In IniciarSesion.user.Permisos.Rows]

If

[If item.tag = fila(0) Then]

[Else]

Loop

[For i = 0 To modulos.ListarMod.Count - 1]

Loop

[For Each Fila In modulos.ListarModulos.Rows]

If

[If Fila(1) = modulos.ListarMod.Item(i) Then]

Loop

[For Each permiso In IniciarSesion.user.Permisos.Rows]

Ilustración 58 Iniciar Sesión


F. Secuencia Eliminar Recepción

this : FrmRecepcion_Eliminar ORecep : RecepcionORecep.DAL : ClasesLINQ

btnElimRecepcion_Click

Create Recepcion

ORecep

<<return>>

Create ClasesLINQ

DAL

<<return>>


Eliminar

ORecep.Eliminar()

<<return>>

EliminarRecepcion

DAL.EliminarRecepcion(IDRecepcion)

<<return>>

DeleteOnSubmit

DeleteOnSubmit

Listar_a_Eliminar

ORecep.Listar_a_Eliminar

<<return>>

ListarRecepcion_a_Eliminar

DAL.ListarRecepcion_a_Eliminar

<<return>>

ToDataTa...

If

[If rs = Windows.Forms.DialogResult.OK Then]

Loop

[For Each ORecepcionDetalles As RecepcionDetalle In (From Obj In lq.RecepcionDetalles Where Obj.RecepcionID = NIdrecepcion)]


G. Secuencia Eliminar Recepción Detalles

this : FrmRecepcion_EliminarORecepdetalles : RecepcionDetalles ORecepdetalles.DAL : ClasesLINQ

btnElimRecepcionDetalles_Click

Create RecepcionDetalles

ORecepdetalles

<<return>>

Create ClasesLINQ

DAL

<<return>>


Eliminar

ORecepdetalles.Eliminar()

<<return>>

EliminarRecepcionDetalles

DAL.EliminarRecepcionDetalles(IDRecepcionDetalles)

<<return>>

DeleteOnSubmit

DeleteOnSubmit

If

[If rs = Windows.Forms.DialogResult.OK Then]

Loop

[For Each OAsign As AsignacionesO In lq.AsignacionesOs]


H. Secuencia Reportar Orden de Servicio

this : FrmOS_Reportarobj : OrdendeServicioDetalles obj.DAL : ClasesLINQReporteOS : OrdendeServicioDetalles ReporteOS.DAL : ClasesLINQ frm : FrmImpresiones

tsReportar_Click

Create OrdendeServicioDetalles

obj

<<return>>

Create ClasesLINQ

DAL

<<return>>


ListarOrdendeServicio3

obj.ListarOrdendeServicio3(txtOrdendeServicio.Text, txtUsuario.Text, txtEquipo.Text, txtCodMaterial.Text, txtDescripcionMaterial.Text, txtUnidadMinera.Text, dtFechaInicio.Value, dtFechaFin.Value)

<<return>>

ListarOrdendeServicio3

DAL.ListarOrdendeServicio3(pCodOs, pUsuario, pEquipo, pCodMaterial, pDescripcionMaterial, pUnidadMinera, pFechainicio, pFechafin)

<<return>>

ToDataTable(Of VB$An...


ReporteOS

<<return>>

Create ClasesLINQ

DAL

<<return>>


Create FrmImpresiones

frm

<<return>>


I. Secuencia Reportar Orden de Trabajo

this : FrmOT_Reportarobj : OrdendeTrabajoDetalles obj.DAL : ClasesLINQReporteOT : OrdendeServicioDetalles ReporteOT.DAL : ClasesLINQ frm : FrmImpresiones

tsReportar_Click

Create OrdendeTrabajoDetalles

obj

<<return>>

Create ClasesLINQ

DAL

<<return>>


Reportar

obj.Reportar(txtCodOT.Text, txtArea.Text, txtProceso.Text, txtEmpleado.Text, txtCodAlmacen.Text, dtFchInicio.Value, dtFchFin.Value)

<<return>>

ListarOrdendeTrabajo3

DAL.ListarOrdendeTrabajo3(pOT, pArea, pProceso, pCodalmacen, pSubresponsable, pFchinicio, pFchFin)

<<return>>

ToDataTable(Of VB$An...


ReporteOT

<<return>>

Create ClasesLINQ

DAL

<<return>>


Create FrmImpresiones

frm

<<return>>


3.1.6 Diagrama de Actividad (pendiente)

Un diagrama de actividad es un caso especial de un diagrama de estados en donde

todos -o al menos la mayoría- de los estados son estados de acciones y en donde

todas -o al menos la mayoría- de las transiciones son disparadas por la finalización

de las acciones que las alimentan (Aires). El propósito de este diagrama es

enfocarse en los flujos manejados por el procesamiento interno (en contraposición

con eventos externos). A continuación, mostramos los diagramas de actividad de

las acciones más relevantes que realiza el sistema.


A. Actividad Iniciar_Sesion

Esta actividad se refiere al ingreso al sistema. A través de una gestión de los perfiles de usuario, se levantan los accesos a las diversas actividades que proporciona el sistema. Para lograr iniciar sesión, el usuario deberá digitar correctamente su contraseña o el administrador del sistema deberá proceder a su registro en la tabla maestra de Empleados.

Seleccionar usuario

Ingresar contraseña

Validar Contraseña

Registrar Usuario

[Usuario registrado][Usuario no registrado]

Mostrar formulario de Inicio

[Contraseña Correcta]

Generar mensaje

[Contraseña Incorrecta]

Ilustración 59 Actividad Iniciar Sesion


B. Actividad Mantener Tabla maestra

Las entidades como Empleados, Componentes, Especialidades, Equipos, Componentes VP se actualizan y mantienen según el siguiente patrón de actividades.

Ingresar al modulo

Insertar Posicion en blanco Seleccionar registro Seleccionar registro

[Insertar registro]

[Actualizar registro]

[Eliminar registro]

Modificar Parametro requerido

Insertar registro

Regresar al Formulario de Inicio

Ingresar datos del registro

Visualizar registros activos

Actualizar RegistroEliminar Registro

Ilustración 60 Actividad Mantener Tabla Maestra


C. Actividad Gestionar documento

Las Recepciones, Ordenes de Servicio, Asignaciones, Ordenes de trabajo y Despachos son gestionados haciendo uso de las siguientes actividades.

Completar parametros de reporteCompletar campos de cabecera

Seleccionar el modulo deseado

[Registrar] [Reportar]

[Eliminar]

Seleccionar la Recepcion Seleccionar la Recepcon

Completar campos de detalle

[Item][Recepcion]

Seleccionar el item

Eliminar item Eliminar Recepcion

Generar prevista reporte

Registrar Recepcion

Exportar a Excel Imprimir

[exportar] [imprimir]

Regresar al menu Inicio

Visualizar documentos activos

Ilustración 61 Actividad Registrar Empleado


3.1.7 Evaluación de la Arquitectura

Se optó por hacer uso de la arquitectura de 3 capas debido a que esta

opción es más ordenada, permite en el futuro la incorporación de mayor

funcionalidad y permite el trabajo independiente en la interfaz, en las reglas

de negocio o en el acceso a datos.

Programación por capas

Es un patrón de arquitectura cuya ventaja principal reside en que el

desarrollo se puede llevar a cabo en varios niveles en caso sobrevenga

realizar algún cambio.


3.2 Diseño de la interfaz grafica

3.2.1 Estándar de interfaz grafica

El objetivo de esta sección es establecer los estándares generales para el

diseño de los componentes gráficos en la aplicación a desarrollar.

A. Entrada de datos

En esta sección, especificamos los parámetros de diseño para la creación

de formularios, pantallas de inicio, área de trabajo, etiquetas y botones de

acción.

Los botones deberán estar mostrados tanto en la región principal como

en la barra de herramientas, esto permite al usuario acceder a los

eventos desde varias ubicaciones de la pantalla. Lo mismo sucede con

los menús de opciones que tanto en la barra de menús como en el

treeview, son accesibles los controles para navegar a través del sistema.

Solo se mostrara una ventana a la vez, para evitar aglutinamiento de

ventanas y mejorar la limpieza y orden de la pantalla del sistema.

Los colores utilizados para las pantallas deberán estar estandarizados. A

continuación presentamos los colores que se utilizaran en el sistema:


Tabla 13 Paleta de colores de pantalla

Las fuentes que se utilizaran son las predeterminadas: Microsoft Sans Serif y un tamaño

de fuente de 8.25 pt para todos los textbox o label a excepción única de los títulos

ubicados en las áreas principales de los formularios.

Es importante utilizar mecanismos indicadores de estado del sistema que

mantengan a los usuarios alertas e informados. Para esto se empleara la

barra de estado.

Los botones que se encuentran en la región principal de la pantalla serán

mostrados a nivel de texto e imagen para presentar la interfaz de una

manera más amigable.

Las pantallas del sistema seguirán en patrón grafico mostrado en la

Ilustración 62.


Especificación de colores

Parámetro Estándar RGB Color

Tree view de

Opciones

(153, 180, 209)

Menú de Opciones (191,205,219)

Barra de

Herramientas

(191,205,219)

Área principal 128,128,128)

Color de fondo de

Datagridviews

(171,171,171)

Color de los textbox (255,255,255)

Ilustración 62 Patrón de diseño gráfico del sistema

<Logo> <Encabezado de pagina >

Barra de Menú de Opciones

Barra de Herramientas

Treeview de

Opciones

Area principal del sistema

<Barra de estado>

Ilustración 63 Formulario de Mantenimiento de Equipos


Leyenda:

1. Encabezado de página: Presenta el nombre del sistema.

2. Barra de Menús de Opciones: El encabezado contiene los menús de Archivo que

permite al usuario salir del sistema. Asimismo, permite ir a cualquier otro modulo

que se desee. Cada módulo tiene su formulario que permite ejecutar tareas

específicas según los permisos otorgados al usuario.

3. Barra de Herramientas: Es la barra donde se encuentran los comandos

específicos de cada formulario según su función determinada. Estos controles

pueden ser Registrar, Actualizar, Nuevo, Eliminar, etc.

4. Treeview de Opciones: Muestra el árbol de módulos del sistema. Cada módulo

tiene su formulario que permite ejecutar tareas específicas según los permisos

otorgados al usuario.

5. Area principal del sistema: En esta región se encuentran controles como:

textbox, combobox, checkbox, datagridview. Es la región de la pantalla donde se

realizaran los registros, actualizaciones, filtrado, eliminación o búsqueda de datos.

6. Barra de estado: Muestra el status e información relevante del sistema.


B. Salida de datos

En esta sección, mostramos las especificaciones de diseño para la

creación de reportes, listas o tablas en tiempo de ejecución.

Los controles como datagridview que presentan vistas desde la base de

datos, solo deben ser modificables aquellas columnas que requieren el

ingreso de información. Las demás deberán permanecer no editables.

El diseño de los datagridview deberá estar estandarizado como el

backcolor, el fontcolor, el tamaño de letra. A continuación presentamos

las especificaciones de este control:

Tabla 14Especificaciones de diseño para datagridview


Parámetro Estándar RGB Color

Color de fondo de

Datagridviews

(224, 224, 224)

Color de columnas

de datagridview

128,128,128)

Color de filas

seleccionadas del

datagridview

128,128,128)

Texto del

datagridview

Arial Narrow,

8.25pt,

style=Bold,

Color = black

A continuación, se muestra un ejemplo del uso de las especificaciones:

Ilustración 64 Datagridview para registrar Orden de Servicio

Los reportes deberán ser generados en herramientas especializadas

como el Report Viewer de Visual Studio. Esta herramienta tiene

incorporado las funcionalidades de impresión y exportación a Excel.

El diseño de los reportes deberá estar estandarizado. El modelo

seleccionado toma los colores de la organización de estudio, así como su

logo y demás datos de la organización. El diseño se muestra a

continuación:


Ilustración 65 Reporte de Recepciones


4. CAPITULO IV CONSTRUCCION

El presente capítulo tiene como propósito presentar las tecnologías seleccionadas

para la implementación del producto. Por su parte se define la estrategia de pruebas y

los tipos de pruebas seleccionados en esta etapa.

4.1 Construcción

Al igual que la construcción de una estructura física o una edificación. Para la

construcción de un sistema se debe seleccionar las herramientas adecuadas y los

materiales que nos permitirán desarrollar los requerimientos del sistema. Durante

esta etapa se desarrollan las siguientes actividades:

Preparación del entorno de Generación y Construcción, en la cual

determinamos las herramientas y recursos informáticos necesarios para

desarrollar y albergar el código, la base de datos, la interfaz de usuario. En la

siguiente tabla mostramos el resumen de los recursos empleados:

Tabla 15 Resumen de recursos de construcción

Parámetros Descripción del recurso

Framework de desarrollo .NET Framework 3.5

Lenguaje de programación Visual Basic.NET

Mapeo Objeto relacional (ORM) Linq to SQL

Entorno de desarrollo de programación

del

interfaz grafico

Visual studio 2012

Entorno de desarrollo de la Base de

datos

SQL Server 2012 Management

Studio

Motor de base de datos SQL Server database engine

Servicio de reportes Report viewer


Ejecución de pruebas, en la cual determinamos y ejecutamos las pruebas

necesarias para verificar la eficiencia del código y la correcta respuesta de los

controles del sistema. Las pruebas a realizar pueden ser unitarias si se realizan

individualmente a cada componente o pruebas de integración que verifican el

performance de los subsistemas.


4.1.1 Framework de desarrollo

Framework

En el desarrollo de software, un framework o infraestructura digital, es

una estructura conceptual y tecnológica de soporte definido, normalmente

con artefactos o módulos de software concretos, que puede servir de base

para la organización y desarrollo de software. Típicamente, puede incluir

soporte de programas, bibliotecas, y un lenguaje interpretado, entre otras

herramientas, para así ayudar a desarrollar y unir los diferentes

componentes de un proyecto.

.NET Framework 4.5

.NET Framework es una popular plataforma de desarrollo para la creación

de aplicaciones para Windows, Tienda Windows, Windows Phone,

Windows Server y Microsoft Azure. La plataforma .NET Framework incluye

los lenguajes de programación C# y Visual Basic, también el common

language runtime y una gran biblioteca de clases. Para el sistema, se

utilizara la versión 4.5, la cual ya presenta la clase System.Linq la cual nos

brindara las herramientas para hacer la conexión a la base de datos.

Se seleccionó trabajar bajo este framework debido a que se tiene un mayor

conocimiento de la misma, la sintaxis es fácil de entender (existe intelisense

que es una característica que permite autocompletar las funciones,

métodos disponibles por objeto) no discrimina las mayúsculas de las

minúsculas y presenta herramientas de ingeniería inversa para representar

diagramas UML.

Ilustración 66 Logo .NET Framework


https://msdn.microsoft.com/library/vstudio/8bs2ecf4.aspx

https://msdn.microsoft.com/library/vstudio/8bs2ecf4.aspx

4.1.2 Lenguaje de programación

.NET Framework permite trabajar con más de veinte lenguajes de

programación integrados entre ellos C# y Visual Basic. Se seleccionó en

lenguaje VB por las razones expuestas a continuación:

Posee una curva de aprendizaje muy rápida.

Integra el diseño e implementación de formularios de Windows.

Es uno de los lenguajes de uso más extendido, por lo que resulta fácil

encontrar información, documentación y fuentes para los proyectos.

Existe una versión, VBA, integrada en las aplicaciones de Microsoft

Office, tanto Windows como Mac, que permite programar macros para

extender y automatizar funcionalidades en documentos, hojas de

cálculo y bases de datos (Access).

Si bien permite desarrollar grandes y complejas aplicaciones, también

provee un entorno adecuado para realizar pequeños prototipos rápidos.

Visual Basic .net

Es un lenguaje de programación orientado a objetos que se puede

considerar una evolución de Visual Basic implementada sobre el framework

.NET. Su introducción resultó muy controvertida, ya que debido a cambios

significativos en el lenguaje VB.NET no es retro compatible con Visual

Basic, pero el manejo de las instrucciones es similar a versiones anteriores

de Visual Basic, facilitando así el desarrollo de aplicaciones más avanzadas

con herramientas modernas. Para mantener eficacia en el desarrollo de las

aplicaciones. La gran mayoría de programadores de VB.NET utilizan

el entorno de desarrollo integrado Microsoft Visual Studio en alguna de sus

versiones, aunque existen otras alternativas, como SharpDevelop.


Ilustración 67 Logo de VB.net


4.1.3 Mapeo Objeto - Relacional

Para la escritura y lectura de base de datos existen en el mercado muchas

tecnologías para acceder a las bases de datos, entre las más

representativas están OLE DB, ADO, DAO. Existe una tecnología

relativamente nueva que está incluida en la .NET framework 3.5 y por lo

tanto también en Visual Studio: LINQ to SQL, que proporciona una

infraestructura en tiempo de ejecución para administrar los datos

relacionales como objetos. Esta tecnología fue la empleada para el

desarrollo del proyecto debido a la corta curva de aprendizaje y la facilidad

de su uso conjunto con el IDE de desarrollo de Visual Studio.

LINQ to SQL

En LINQ to SQL, el modelo de datos de una base de datos relacional se

asigna a un modelo de objetos expresado en el lenguaje de programación

del programador. Cuando la aplicación se ejecuta, LINQ to SQL convierte a

SQL las consultas integradas en el lenguaje en el modelo de objetos y las

envía a la base de datos para su ejecución. Cuando la base de datos

devuelve los resultados, LINQ to SQL los vuelve a convertir en objetos con

los que pueda trabajar en su propio lenguaje de programación. El Object

Relational Designer, también incluido en el .NET Framework 3.5,

proporciona una interfaz de usuario para implementar muchas de las

características de LINQ to SQL.

Ilustración 68 Logo LINQ to SQL


A continuación mostramos algunos diagramas para demostrar cómo

funciona esta funcionalidad del .NET Framework:

Ilustración 69 Select clause

Ilustración 70 Insert Clause


Ilustración 71 O/R Designer


4.1.4 IDE

Para el IDE de desarrollo se empleó el IDE por excelencia para

implementar clases VB.NET: Visual Studio, el cual, en su versión 2012, es

un IDE que presenta herramientas útiles para diseñar y representar la

arquitectura del sistema:

Visual Studio 2012

Mediante el módulo Architecture, permite generar diagramas UML como

diagramas de clases, diagramas de secuencia, Casos de uso, diagramas

de actividad, diagramas de componentes, diagramas de capas. Cabe

resaltar que ese diseñador permite realizar ingeniería inversa para modelar

los diagramas de secuencia y diagrama de clases basta arrastras los

objetos al modelador correspondiente para que VS genere el diagrama.

Asimismo, como se indicó en el apartado anterior, VS posee e framework

LINQ to SQL y el diseñador de objetos relacional O/R Designer que serán

los objetos que mapearan las tablas y vistas de la base de datos al sistema.

Otro punto a favor de VS es que presenta una amplia documentación de

sus clases en la Microsoft Developer Network https://msdn.microsoft.com

e información adicional en foros online.


Ilustración 72 Logo de Visual Studio 2012

Ilustración 73 Pantalla de trabajo de Visual Studio 2012


4.1.5 Motor de Bases de datos

Un motor de base de datos es el software que utiliza un sistema de gestión

de bases de datos (DBMS) y que es usado para generar las sentencias

CRUD (Crear, Leer, Actualizar y borrar) en la BD. Asimismo, el Motor de

base de datos nos permite generar vistas, crear llaves principales y

secundarias con las cuales armar las relaciones entre tablas.

SQL Server 2012

Para el proyecto se utiliza el motor de bases datos de SQL Server 2012,

con el cual generaremos las tablas, relaciones y vistas principales para

conectar a nuestro sistema mediante nuestra capa de acceso a datos. El

IDE para manipular el motor de la base de datos será el SQL Server 2012

Management Studio.


Ilustración 74 Logo SQL Server 2012

Ilustración 75 Pantalla de trabajo SQL Server 2012 Management Studio


4.1.6 Otras herramientas y librerías

Todas las clases y herramientas empleadas en el sistema han sido

desarrolladas dentro de la librería .NET framework 3.5. Sin embargo,

también seria indicado especificar que para el desarrollo de los reportes de

salida, se empleó la herramienta VS llamada Report Viewer que nos brinda

funcionalidades predeterminadas para imprimir o exportar reportes a otros

formatos como a archivos Excel.

Report Viewer

Microsoft Visual Studio 2012 incluye funcionalidad de diseño de informes y

controles ReportViewer para que puedan agregarse informes completos a

las aplicaciones personalizadas. Los informes pueden contener datos

tabulares, agregados y multidimensionales. Los controles ReportViewer

permitirán procesar y mostrar el informe en la aplicación.


Ilustración 76 Vista previa de Report Viewer


4.2 Pruebas

En esta sección se detalla el procedimiento de pruebas durante la verificación y

validación del software, desde los tipos de pruebas seleccionados junto con las

justificaciones de sus respectivas elecciones, así como la estrategia desarrollada.

4.2.1 Estrategia de Prueba

El objetivo global de la estrategia de pruebas es demostrar el

funcionamiento completo del software a nivel de eficiencia de código y

funcionalidad. En otras palabras, verificar la interacción e integración de los

componentes y validar la implementación de todos los requerimientos de

producto.

Para el cumplimiento de lo descrito anteriormente, la estrategia establecida

será como sigue (para mayor información revisar el Plan de Pruebas):

Recopilar, diseñar y documentar los casos de prueba de software a

nivel de módulo y de producto en el catálogo de pruebas. Los casos de

prueba deben cubrir la revisión de más de un requerimiento funcional.

Cuantificar el esfuerzo estimado en horas de cada uno de los recursos

por emplear bajo estas pruebas.

Las pruebas unitarias serán ejecutadas en paralelo con la codificación

teniendo como propósito el funcionamiento correcto del código fuente

implementado bajo el lenguaje de programación.

4.2.2 Tipos de Pruebas

En esta sección se describen los tipos de prueba empleados en la

estrategia de pruebas.

Pruebas Unitarias

Estas pruebas de software se dirigen a componentes menores como los

módulos de un sistema, probando los caminos de control importantes con el


fin de descubrir errores dentro de esta instancia (Dávila 2005). Es así como

el equipo logrará identificar los defectos en fases tempranas de codificación

sin esperar la realización de pruebas integrales. Las técnicas consideradas

son:

Pruebas de Caja Blanca: Examinan la estructura de un código fuente

según la lógica implementada evaluando la ejecución correcta a nivel de

sentencia, estructuras selectivas e iterativas (Dávila 2005). No obstante,

este ámbito queda cubierto dentro del marco de pruebas de código a

realizarse durante la codificación del producto adoptada como práctica ágil.

Pruebas de Caja Negra: Estas pruebas se realizan sobre las interfaces

gráficas buscando comprobar la funcionalidad, comportamiento en la

entrada y salida de datos así como la integridad de la información enviada y

recibida.

Pruebas de Integración

Bajo estas pruebas todos los módulos revisados e integrados en diferentes

secuencias de procesos y llamadas, son evaluados con el propósito de

comprobar la ejecución correcta conforme al proceso de negocio esperado.

Un factor clave es la capacidad de identificación de todos los esquemas de

llamadas para una buena cobertura de casos de prueba integral. Las

pruebas integrales se clasifican en:

No incremental: Requiere tener todos los módulos del producto software

culminados para así concretar en su conjunto estas pruebas.

Incremental: Cada módulo es acoplado a los componentes existentes, así

las pruebas futuras no afectarán los avances y correcciones de fases

anteriores, en la búsqueda de un software robusto desde el inicio de las

pruebas. La prueba de integración incremental fue adoptada para esta

etapa, pretendiendo demostrar así el funcionamiento del software sin

errores desde el inicio de su creación. Esto puede afectar en mediano

grado los tiempos globales, pero asegura calidad en la construcción y está


alineado con la metodología iterativa incremental. Involucrando a los

usuarios en las pruebas, trae como ventaja la simulación de los escenarios

reales de los procesos de negocio midiendo así el grado de satisfacción de

los requerimientos funcionales.


4.2.3 Catálogo de pruebas

A continuación en la tabla 4.2 se listan los principales casos del catálogo de

pruebas concerniente a los módulos de Seguridad, Planeamiento y

Mantenimiento:


A. Pruebas Unitarias Iniciar Sesión

Tabla 16 Pruebas unitarias Iniciar Sesión

ID_Test Modulo

Prueba_Tip

o Caso de Prueba Formulario Descripcion

Statu

s

SES-

001

Segurida

d Unitario Ingresar Usuario y Contraseña

IniciarSesion.v

b

Verificar la emisión de un mensaje de error al no

indicar un código de usuario correcto en el campo

“Usuario” 100%

SES-

002

Segurida


IniciarSesion.v

b

Verificar la emisión de un mensaje de error al no

indicar un código de usuario correcto en el campo

“Contraseña” 100%

SES-

003

Segurida


IniciarSesion.v

b Verificar que el usuario pueda salir del programa al hacer clic en "Cancelar" 100%

SES-

004

Segurida


IniciarSesion.v

b Verificar que el usuario pueda ingresar a la pantalla de inicio en el formulario FrmInicio.vb si el usuario y contraseña son correctos. 100%

SES-

005

Segurida

d Unitario

Manipular los controles de la ventana de

inicio FrmInicio.vb Verificar que el usuario pueda cambiar sesion al ingresar a "Cambiar Sesion" en la barra de inicio. 100%

SES-

006

Segurida

d Unitario


inicio FrmInicio.vb Verificar que el usuario pueda salir del sistema al ingresar a "Cerrar" en la barra de inicio considerando un mensaje previo de confirmacion. 100%

SES-

007

Segurida

d Unitario


inicio FrmInicio.vb

Verificar que el usuario pueda visualizar los formularios correctos según los permisos generados, tanto en la barra de menú como en el treeview de

opciones. 100%

SES-

008

Segurida

d Unitario


inicio FrmInicio.vb Verificar que el usuario al hacer clic en alguno de los treenode de la pantalla de inicio pueda ingresar a los formularios correspondientes. 100%

SES-

009

Segurida

d Unitario


inicio FrmInicio.vb Verificar que el usuario al hacer clic en alguno de los botones del menú de opciones pueda ingresar a los formularios correspondientes. 100%

B. Pruebas Unitarias Componentes VP

Tabla 17 Pruebas Unitarias Componentes VP

ID_Test Modulo

Prueba_Tip

o Caso de Prueba Formulario Descripcion

Statu

s

MTT-CVP-

001

Mantenimient

o Unitario

Dar mantenimiento a la base componentes

VP

FrmComponentesVP_Mantenimiento.

vb

Verificar que el sistema muestre un mensaje de advertencia al tratar de registrar, actualizar o eliminar un componente

VP. 100%

MTT-CVP-

002

Mantenimient

o Unitario


VP


vb Verificar que el usuario pueda registrar un nuevo componenteVP. 100%

MTT-CVP-

003

Mantenimient

o Unitario


VP


vb Verificar que el usuario pueda actualizar un nuevo componenteVP. 100%


MTT-CVP-

004

Mantenimient

o Unitario


VP


vb Verificar que el usuario pueda eliminar un nuevo componenteVP. 100%

MTT-CVP-

005

Mantenimient

o Unitario


VP


vb Verificar que el usuario pueda visualizar los componentes vp activos y realizar una búsqueda. 100%

C. Pruebas Unitarias Componentes

Tabla 18 Pruebas unitarias Componentes

ID_Test Modulo Prueba_Tipo Caso de Prueba Formulario Descripcion Status

MTT-COM-

001 Mantenimiento Unitario Dar mantenimiento a la base componentes FrmComponentes.vb

Verificar que el sistema muestre un mensaje de advertencia al tratar de registrar, actualizar o eliminar un

componente. 100%

MTT-COM-

002 Mantenimiento Unitario Dar mantenimiento a la base componentes FrmComponentes.vb Verificar que el usuario pueda registrar un nuevo componente. 100%

MTT-COM-

003 Mantenimiento Unitario Dar mantenimiento a la base componentes FrmComponentes.vb Verificar que el usuario pueda actualizar un nuevo componente. 100%

MTT-COM-

004 Mantenimiento Unitario Dar mantenimiento a la base componentes FrmComponentes.vb Verificar que el usuario pueda eliminar un nuevo componente. 100%

MTT-COM-

005 Mantenimiento Unitario Dar mantenimiento a la base componentes FrmComponentes.vb Verificar que el usuario pueda visualizar todos los componentes activos y realizar una búsqueda. 100%

D. Pruebas Unitarias Empleado

Tabla 19 Pruebas Unitarias Empleados


MTT-EMP-

001 Mantenimiento Unitario Dar mantenimiento a la tabla empleados

FrmEmpleados_Mantenimiento.v

b

Verificar que el sistema muestre un mensaje de advertencia al tratar de registrar, actualizar o eliminar un

componente. 100%

MTT-EMP-



b Verificar que el usuario pueda registrar un Empleado. 100%

MTT-EMP-



b Verificar que el usuario pueda actualizar un Empleado. 100%

MTT-EMP-



b Verificar que el usuario pueda eliminar un nuevo Empleado. 100%

MTT-EMP-



b Verificar que el usuario pueda visualizar todos los empleados activos y realizar una búsqueda. 100%


E. Pruebas Unitarias Equipos

Tabla 20 Pruebas unitarias Equipos


MTT-EQU-001 Mantenimiento Unitario Dar mantenimiento a la base equipos FrmEquipos.vb Verificar que el sistema muestre un mensaje de advertencia al tratar de registrar, actualizar o eliminar un equipo 100%

MTT-EQU-002 Mantenimiento Unitario Dar mantenimiento a la base equipos FrmEquipos.vb Verificar que el usuario pueda registrar un Equipo. 100%

MTT-EQU-003 Mantenimiento Unitario Dar mantenimiento a la base equipos FrmEquipos.vb Verificar que el usuario pueda actualizar un Equipo. 100%

MTT-EQU-004 Mantenimiento Unitario Dar mantenimiento a la base equipos FrmEquipos.vb Verificar que el usuario pueda eliminar un nuevo Equipo. 100%

MTT-EQU-005 Mantenimiento Unitario Dar mantenimiento a la base equipos FrmEquipos.vb Verificar que el usuario pueda visualizar todos los equipos activos y realizar una busqueda. 100%

F. Pruebas Unitarias Asignaciones

Tabla 21 Pruebas Unitarias Asignaciones


MTT-SIG-

001

Mantenimient

o Unitario Registrar una asignacion

FrmAsignacion_Registrar.v

b Verificar que el sistema muestre un mensaje de advertencia al tratar de registrar o eliminar un AsignacionesOS. 100%

MTT-SIG-

002

Mantenimient



b Verificar que el usuario pueda registrar un nuevo AsignacionesOS. 100%

MTT-SIG-

003

Mantenimient



b Validar que las cantidades asignadas no excedan las cantidades solicitadas ni las cantidades recepcionadas 100%

MTT-SIG-

004

Mantenimient

o Unitario Eliminar una asignacion FrmAsignacion_Eliminar.vb Verificar que el usuario pueda eliminar un nuevo AsignacionesOS. 100%

MTT-SIG-

005

Mantenimient



b Verificar que el usuario pueda visualizar todos los AsignacionesOS activos y realizar una búsqueda. 100%


G. Pruebas Unitarias Recepción

Tabla 22 Pruebas Unitarias Recepcion


PLN-RC-001 Planeamiento Unitario Generar Recepcion FrmRecepcion_registrar.vb Verificar que el usuario pueda registrar una nueva Recepcion. 100%

PLN-RC-002 Planeamiento Unitario Generar Recepcion FrmRecepcion_registrar.vb

Verificar que el sistema valide que todos los campos requeridos estén completos y correctos antes de que la recepción sea

registrada. 100%

PLN-RC-003 Planeamiento Unitario Reportar Recepcion FrmRecepcion_reportar.vb Verificar que el usuario pueda imprimir la(s) recepción(es) según requiera. 100%

PLN-RC-004 Planeamiento Unitario Generar Recepcion FrmRecepcion_registrar.vb Verificar que el usuario no pueda registrar más de 1 componentes VP en un item detalle de una recepción 100%

PLN-RC-005 Planeamiento Unitario Generar Recepcion FrmRecepcion_registrar.vb Verificar que el usuario ingrese fechas válidas y coherentes para la salida de la U.Minera o ingreso al almacén. 100%

PLN-RC-006 Planeamiento Unitario Eliminar Recepcion FmRecepcion_eliminar.vb Verificar que el usuario pueda eliminar una recepción no asignada. 100%

PLN-RC-007 Planeamiento Unitario Generar Recepcion FmRecepcion_registrar.vb Verificar que el usuario reciba una advertencia antes de realizar un registro de recepciones. 100%

PLN-RC-008 Planeamiento Unitario Reportar Recepcion FrmRecepcion_reportar.vb Verificar que el usuario pueda exportar la información del reporte a una plantilla Excel 100%

H. Pruebas Unitarias Orden de Servicio

ID_Test Modulo

Prueba_Tip

o Caso de Prueba Formulario Descripcion Status

PLN-OS-

001

Planeamient

o Unitario Generar Orden de Servicio FrmOS_registrar.vb Verificar que el usuario pueda registrar una nueva Orden de Servicio. 100%

PLN-OS-

002

Planeamient

o Unitario Generar Orden de Servicio FrmOS_registrar.vb

Verificar que el sistema valide que todos los campos requeridos estén completos y correctos antes de que la Orden de Servicio sea

registrada. 100%

PLN-OS-

003

Planeamient

o Unitario

Reportar Orden de

Servicio FrmOS_reportar.vb Veriificar que el usuario pueda imprimir la(s) Orden de Servicio(es) según requiera. 100%

PLN-OS-

004

Planeamient

o Unitario Generar Orden de Servicio FrmOS_registrar.vb Verificar que el usuario no pueda registrar más de 1 componentes VP en un item detalle de una Orden de Servicio 100%

PLN-OS-

005

Planeamient

o Unitario Generar Orden de Servicio FrmOS_registrar.vb Verificar que el usuario ingrese una fecha de emisión valida. 100%

PLN-OS-

006

Planeamient

o Unitario Eliminar Orden de Servicio FmOS_eliminar.vb Verificar que el usuario pueda eliminar una Orden de Servicio no asignada. 100%

PLN-OS-

007

Planeamient

o Unitario Generar Orden de Servicio FmOS_registrar.vb Verificar que el usuario reciba una advertencia antes de realizar un registro de Orden de Servicios. 100%

PLN-OS-

008

Planeamient

o Unitario

Reportar Orden de

Servicio FrmOS_reportar.vb Verificar que el usuario pueda exportar la información del reporte a una plantilla Excel 100%

I. Pruebas Unitarias Orden de Trabajo


PLN-OT-001 Planeamiento Unitario Generar Orden de Trabajo FrmOT_registrar.vb Verificar que el usuario pueda registrar una nueva Orden de Trabajo. 100%


PLN-OT-002 Planeamiento Unitario Generar Orden de Trabajo FrmOT_registrar.vb Verificar que el sistema valide que todos los campos requeridos estén completos y correctos antes de que la Orden de Trabajo sea registrada. 100%

PLN-OT-003 Planeamiento Unitario Reportar Orden de Trabajo FrmOT_reportar.vb Veriificar que el usuario pueda imprimir la(s) Orden de Trabajo(s) según requiera. 100%

PLN-OT-004 Planeamiento Unitario Generar Orden de Trabajo FrmOT_registrar.vb Verificar que el usuario no pueda registrar una OS Detalles que no esté asignada completamente. 100%

PLN-OT-005 Planeamiento Unitario Eliminar Orden de Trabajo FmOT_eliminar.vb Verificar que el usuario pueda eliminar una Orden de Trabajo no despachada. 100%

PLN-OT-006 Planeamiento Unitario Generar Orden de Trabajo FmOT_registrar.vb Verificar que el usuario reciba una advertencia antes de realizar un registro de Orden de Trabajos. 100%

PLN-OT-007 Planeamiento Unitario Reportar Orden de Trabajo FrmOT_reportar.vb Verificar que el usuario pueda exportar la información del reporte a una plantilla Excel 100%


J. Pruebas Unitarias Despachos


PLN-DE-001 Planeamiento Unitario Generar Despacho FrmDespacho_registrar.vb Verificar que el usuario pueda registrar una nuevo Despacho. 100%

PLN-DE-002 Planeamiento Unitario Generar Despacho FrmDespacho_registrar.vb Verificar que el sistema valide que todos los campos requeridos estén completos y correctos antes de que el Despacho sea registrado. 100%

PLN-DE-003 Planeamiento Unitario Reportar Despacho FrmDespacho_reportar.vb Veriificar que el usuario pueda imprimir el(los) Despacho(s) según requiera. 100%

PLN-DE-004 Planeamiento Unitario Generar Despacho FrmDespacho_registrar.vb Verificar que el usuario no pueda despachar Órdenes de trabajo que no estén cerradas. 100%

PLN-DE-005 Planeamiento Unitario Generar Despacho FrmDespacho_registrar.vb Verificar que el usuario ingrese fechas válidas y coherentes para la salida del taller o ingreso a la U.Minera. 100%

PLN-DE-006 Planeamiento Unitario Eliminar Despacho FmDespacho_eliminar.vb Verificar que el usuario pueda deshacer un Despacho. 100%

PLN-DE-007 Planeamiento Unitario Generar Despacho FmDespacho_registrar.vb Verificar que el usuario reciba una advertencia antes de registrar el Despachos. 100%

PLN-DE-008 Planeamiento Unitario Reportar Despacho FrmDespacho_reportar.vb Verificar que el usuario pueda exportar la información del reporte a una plantilla Excel 100%

K. Pruebas Integrales

ID Test Modulo Tipo Descripcion Status

INT-001 Todos Integral Verificar que el usuario pueda navegar correctamente por los diferentes formularios del equipo. 100%

INT-002 Todos Integral Verificar que el usuario sepa el status de todas las acciones que realiza. 100%

INT-003 Todos Integral Validar que el tiempo de procesamiento de los eventos sea aceptable. 100%


4.2.4 Resultados de pruebas

Tras la ejecución de pruebas unitarias e integración según el Plan de

Pruebas se presenta en esta sección los resultados obtenidos.

Como vemos las pruebas unitarias han sido realizadas con éxito y se

encuentran satisfactorias al 100%. Esto fue posible gracias al enfoque de

prototipado ágil a través de versiones de prueba que se mejoran con la

ejecución de pruebas incrementales.


4.2.5 Aplicación del sistema

Para validar la efectividad del sistema, realizamos la simulación de una nueva recepción de un componente al taller.

Paso 1 Iniciar sesión

Al iniciar la simulación, ingresamos al formulario de Iniciar Sesión. Este formulario nos exige seleccionar nuestro

usuario e ingresar nuestra contraseña.


Ilustración 77 Ingresar al sistema

Paso 2 Seleccionar el módulo de Registrar recepción

Luego de ingresar nuestra contraseña el sistema nos muestra el formulario de inicio, en el cual podemos seleccionar

las actividades habilitadas según nuestro usuario. En este caso, haremos uso del treeview de opciones y haremos

doble clic a Registrar Recepciones.


Paso 3 Ingresar parámetros de Recepción

Posteriormente, el sistema nos mostrara el formulario para registrar recepciones donde ingresaremos los datos de la

recepcion y los ítems de la recepcion. En este caso, vamos a registrar una recepción de dos ítems: 1 bomba de

combustible y 1 inyector que provienen de la unidad minera CHUNGAR enviados por el usuario ALBERCA


adjuntando la Guia de remisión 001-0000213. Estos componentes salieron de la unidad el 25/09/2015 e ingresaron a

almacen el 27/09/2015. Si esta recepcion es registrada su código será el R00009.

Paso 4 Aceptar la Recepción

Al momento de hacer clic en el botón de registrar, nos muestra el siguiente mensaje, con lo cual damos por finalizado

el registro de la recepción y al hacer clic en aceptar nos regresa a la pantalla de inicio.



5. CAPITULO V OBSERVACIONES, CONCLUSIONES Y RECOMENDACIONES

Este capítulo final comprende las observaciones identificadas y asimiladas una vez

completadas las fases del proyecto, junto con las conclusiones y recomendaciones

finales para futuros proyectos afines a la temática de este proyecto.

5.1 Observaciones

Este proyecto fue concebido con el objetivo de mejorar la calidad de información

que maneja un taller de mantenimiento de maquinaria pesada y

consecuentemente tomar decisiones de mayor valor.

En la etapa de análisis se realizó el levantamiento de información y ordenamiento

de información en base a la experiencia previa en el campo, para obtener los

campos requeridos y las entidades que el sistema exigía. Estas entidades fueron

normalizadas y organizadas en una base de datos relacional, la cual nos da la

fuente de información para generar los reportes correspondientes al proceso y a la

gestión del performance.

Se incorporaron practicas agiles en la fase de construcción y pruebas que

favoreció en la mejora continua del sistema a través de los desarrollos iterativos. El

sistema es altamente escalable gracias a la arquitectura en n capas y los módulos

de trabajo, es posible aumentar la funcionabilidad del sistema en un plazo a futuro.

Se ha apostado por un sistema Mono servidor o servidor-cliente lo cual es una

restricción importarte a considerar para mejorar en el futuro, pero esta limitación se

entiende ya que la actividad del registro se encuentra centralizada en empresas de

pequeña escala.

El presente trabajo fue concebido con fines estrictamente académicos y no es de

interés del autor obtener un fin lucrativo a futuro. Aquí es preciso destacar las

características y funcionalidades de este sistema están estrechamente vinculados

a las necesidades que se observaron en campo y que deben ser transformados o

mejorados si el sistema se aplica fuera del ámbito estudiado.



5.2 Conclusiones

Con este proyecto se consiguió implementar una solución automatizada capaz de

gestionar la información obtenida en un taller de mantenimiento de maquinaria

pesada.

El proyecto realizado es la primera fase de desarrollo de una propuesta de mejora

continua de la gestión de información en concordancia con la metodología AUP.

Los esfuerzos y tiempo invertidos en el análisis y diseño de la solución posibilitaron

la cobertura de todos los requerimientos funcionales del usuario maximizando las

funcionalidades deseadas del producto.

La utilización del namespace LINQ to SQL permite mapear rápidamente las

entidades de la base de datos y transformarlos en objetos que pueden ser

utilizados en el sistema. Esto permitió un menor tiempo de desarrollo en la capa de

acceso a datos.

La arquitectura en capas ofrece una mejor escalabilidad para futuras integraciones

con nuevas herramientas y servicios aplicando la reutilización de componentes.

La documentación técnica y funcional del producto brindará a todo nuevo usuario

un mejor entendimiento de las funciones implementadas.


5.3 Recomendaciones

Como trabajos a futuro en este campo se recomienda incorporar los procesos

de gestión de personas y costeo de órdenes de trabajo para abarcar la

totalidad de ámbitos en que se desenvuelve un taller de mantenimiento.

Respecto a la codificación de componentes VP se recomienda establecer un

sistema de encriptación de los componentes VP en códigos de barras o

códigos QR para la codificación en campo de los componentes.

El sistema, según el alcance inicial del proyecto, no contempla la

implementación de algún servicio web que permita la conexión al sistema

mediante Internet, por consiguiente, éste no utiliza IDEs para desarrollar o

testear websites y aplicaciones online. La puesta en marcha del sistema vía

internet será esencial cuando el sistema requiera concurrencia e ingresos

multiusuario.


6. BIBLIOGRAFIA

Aires, U. d. (s.f.). Diagramas de actividad. Obtenido de http://www-2.dc.uba.ar/materias/isoft1/Apuntes/DiagramasDeActividad.pdf

Ambler, S. (2012). Agile Model Driven Development (AMDD): The Key to Scaling Agile Software Development - See more at: http://www.agilemodeling.com/essays/amdd.htm#sthash.imSAeqFm.dpuf. Recuperado el 13 de 04 de 2014, de http://www.agilemodeling.com/essays/amdd.htm

Barbara Canning McNurlin, R. H. (s.f.). Information systems management in practice. Obtenido de http://visysupyloho.netii.net/information-system-management-in.php

CockBurn, A. (2000). Agile Software Development (Draft version 3b ed.). CockBurn, Alistair.

de la Torre Llorente, C., Zorrilla Castro, U., Barros Ramos, M. A., & Calvarro Nelson, J. (2010). Guia de arquitectura N-Capas orientada al dominio con .NET 4.0. España: Krasis Consulting S.L.

Friginal, G. (28 de Marzo de 2013). Slideshare. Obtenido de http://www.slideshare.net/giofriginal/lesson-11-information-system

Galindo, R. M. (2012). Analisis, diseño e implementacion de un informacion aplicado a la gestion educativa en centros de educacion especial. Lima: Pontificia Universidad Catolica del Peru.

IZAMORAR. (s.f.). beneficios importancia y objetivos de un sistema de informacion. Recuperado el 01 de 08 de 2015, de http://izamorar.com/beneficios-importancia-y-objetivos-de-un-sistema-de-informacion/

Kendall, K. &. (2011). Analisis y Diseño de Sistemas (Octava ed.). (L. M. Castillo, Ed.) Naucalpan de Juarez, Estado de Mexico, Mexico: Prentice Hall - Pearson Education Inc.

Kimble, C. (20 de 10 de 2013). Euromed Marseille School of Management. Recuperado el 07 de 04 de 2014, de World Med MBA Program - Information Systems and Strategy Course: http://www.chris-kimble.com/Courses/World_Med_MBA/Types-of-Information-System.html

Levitt, J. (2014 de 04 de 2014). Best Practices Webinar: Maximizing the Benefit from your CMMS. Recuperado el 2014 de ABRIL de 2014, de YOUTUBE: http://www.youtube.com/watch?v=T8wb_ANoSWg

Microsoft. (02 de Diciembre de 2014). Visual Studio 2012 Documentacion. Obtenido de https://msdn.microsoft.com/es-es/library/vstudio/dd831853(v=vs.110).aspx

Otero, A. (s.f.). DSS Arquitecture. Recuperado el 09 de Setiembre de 2015, de http://biolab.uspceu.com/decisionsupportsystems/DSSGeneralArchitecture.pdf


Perspective CMMS. (31 de Mayo de 2013). Benefits of Using a CMMS System. Recuperado el 19 de Abril de 2014, de http://www.pemms.co.uk/cmms_benefits.html

PMI. (2008). A Guide to the Project Management Body of Knowledge.

SAP. (s.f.). SAP Help Portal. Recuperado el 09 de Setiembre de 2015, de http://help.sap.com/saphelp_nw70/helpdata/en/84/54953fc405330ee10000000a114084/content.htm

UNICON. (6 de 5 de 2013). UNICON. Recuperado el 13 de 4 de 2014, de http://www.unicon.com.pe/principal/categoria/10-servicio-de-shotcrete/136/c-136

WIKIPEDIA. (10 de Abril de 2014). Mantenimiento correctivo. Recuperado el 14 de Abril de 2014, de http://es.wikipedia.org/wiki/Mantenimiento_correctivo

WIKIPEDIA. (15 de Abril de 2014). Sistema de planificación de recursos empresariales. Recuperado el 17 de 4 de 2014, de http://es.wikipedia.org/wiki/Sistema_de_planificaci%C3%B3n_de_recursos_empresariales

Wikipedia. (6 de 1 de 2014). Wikipedia. Recuperado el 7 de 4 de 2014, de http://es.wikipedia.org/wiki/Sistema_de_procesamiento_de_transacciones

Wikipedia. (23 de Junio de 2015). Wikipedia. Recuperado el 2015 de 08 de 03, de https://es.wikipedia.org/wiki/Diagrama_de_secuencia


7. ANEXOS

7.1 Los 12 principios de la metodología ágil

Desarrollados por Alistair CockBurn, refuerzan la idea del pensamiento ágil

enfocado en el desarrollo de sistemas, estos son:

Satisfacer al cliente a través de la entrega temprana y continua de software

de valor.

Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al

desarrollo. Los procesos ágiles se doblegan al cambio como ventaja

competitiva para el cliente.

Entregar con frecuencia software que funcione, en periodos de un par de

semanas hasta un par de meses, con preferencia en los periodos breves.

Las personas del negocio y los desarrolladores deben trabajar juntos de

forma cotidiana a través del proyecto.

Construcción de proyectos en torno a individuos motivados, dándoles la

oportunidad y el respaldo que necesitan y procurándoles confianza para que

realicen la tarea.

La forma más eficiente y efectiva de comunicar información de ida y vuelta

dentro de un equipo de desarrollo es mediante la conversación cara a cara.

El software que funciona es la principal medida del progreso.

Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores,

desarrolladores y usuarios deben mantener un ritmo constante de forma

indefinida.

La atención continua a la excelencia técnica enaltece la agilidad.

La simplicidad como arte de maximizar la cantidad de trabajo que no se hace,

es esencial.

Las mejores arquitecturas, requisitos y diseños emergen de equipos que se

auto-organizan.

En intervalos regulares, el equipo reflexiona sobre la forma de ser más

efectivo y ajusta su conducta en consecuencia.


7.2 Calculo de la energia

Ilustración 78 Fuente: http://michaelbluejay.com/electricity/computers.html

Ilustración 79 Plana tarifaria OSINERGMIN


http://michaelbluejay.com/electricity/computers.html

7.3 Objetos LINQ to SQL







Date post:	08-Dec-2015
Category:	Documents
Upload:	kevin-jordan-rosas-rondon
View:	15 times
Download:	7 times

Tesis Final.docx

Documents