Tesis Final.docx
-
Upload
kevin-jordan-rosas-rondon -
Category
Documents
-
view
15 -
download
7
description
Transcript of 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.
CAPITULO IV CONSTRUCCION Página 3
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
CAPITULO IV CONSTRUCCION Página 4
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.
CAPITULO IV CONSTRUCCION Página 5
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
CAPITULO IV CONSTRUCCION Página 6
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
CAPITULO IV CONSTRUCCION Página 7
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
CAPITULO IV CONSTRUCCION Página 8
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
CAPITULO IV CONSTRUCCION Página 9
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
CAPITULO IV CONSTRUCCION Página 10
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
CAPITULO IV CONSTRUCCION Página 11
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
CAPITULO IV CONSTRUCCION Página 12
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
CAPITULO IV CONSTRUCCION Página 13
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.
CAPITULO IV CONSTRUCCION Página 14
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
CAPITULO IV CONSTRUCCION Página 15
componentes con vida propia.
Falta de trazabilidad de los
componentes con vida propia.
fallas de los componentes.
No existe órdenes de
mantenimiento.
No existe un análisis de fallas de
componentes con vida propia.
repuestos.
Imposibilidad de realizar planes de
prevención de fallas.
CAPITULO IV CONSTRUCCION Página 16
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
CAPITULO IV CONSTRUCCION Página 17
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
CAPITULO IV CONSTRUCCION Página 18
Ilustración 3 Shotcrete en túneles
Ilustración 4 Shotcrete en taludes
CAPITULO IV CONSTRUCCION Página 19
Ilustración 5 Shotcrete en canales
CAPITULO IV CONSTRUCCION Página 20
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.
CAPITULO IV CONSTRUCCION Página 21
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:
CAPITULO IV CONSTRUCCION Página 22
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.
CAPITULO IV CONSTRUCCION Página 23
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.
CAPITULO IV CONSTRUCCION Página 24
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.
CAPITULO IV CONSTRUCCION Página 25
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
CAPITULO IV CONSTRUCCION Página 26
satisfacer los requerimientos de nuestros clientes con el más alto nivel de
calidad y profesionalismo.
CAPITULO IV CONSTRUCCION Página 27
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.
CAPITULO IV CONSTRUCCION Página 28
CAPITULO IV CONSTRUCCION Página 29
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”
CAPITULO IV CONSTRUCCION Página 30
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”.
CAPITULO IV CONSTRUCCION Página 31
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
CAPITULO IV CONSTRUCCION Página 32
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.
CAPITULO IV CONSTRUCCION Página 33
Arquitectura de un TPS
Ilustración 9 Arquitectura TPS
FUENTE: (Friginal, 2013)
CAPITULO IV CONSTRUCCION Página 34
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.
CAPITULO IV CONSTRUCCION Página 35
Arquitectura de un MIS
Ilustración 10 MIS en una organización
FUENTE: ENLACE WEB (Barbara Canning McNurlin)
CAPITULO IV CONSTRUCCION Página 36
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.
CAPITULO IV CONSTRUCCION Página 37
Arquitectura de un DSS
Ilustración 11 Arquitectura DSS
FUENTE: DSS Arquitecture, Abraham Otero
CAPITULO IV CONSTRUCCION Página 38
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.
CAPITULO IV CONSTRUCCION Página 39
Arquitectura de un EIS
FUENTE: Elaboración Propia
FUENTE: Elaboración Propia
CAPITULO IV CONSTRUCCION Página 40
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.
CAPITULO IV CONSTRUCCION Página 41
Arquitectura del ERP SAP Netweaver
Ilustración 13 Arquitectura del ERP SAP
FUENTE: (SAP)
CAPITULO IV CONSTRUCCION Página 42
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:
CAPITULO IV CONSTRUCCION Página 43
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:
CAPITULO IV CONSTRUCCION Página 44
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.
CAPITULO IV CONSTRUCCION Página 45
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
CAPITULO IV CONSTRUCCION Página 46
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:
CAPITULO IV CONSTRUCCION Página 47
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.
CAPITULO IV CONSTRUCCION Página 48
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.
CAPITULO IV CONSTRUCCION Página 49
Ilustración 14 Ciclo de Vida del Desarrollo de Sistemas
CAPITULO IV CONSTRUCCION Página 50
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
CAPITULO IV CONSTRUCCION Página 51
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
CAPITULO IV CONSTRUCCION Página 52
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.
CAPITULO IV CONSTRUCCION Página 53
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.
CAPITULO IV CONSTRUCCION Página 54
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.
CAPITULO IV CONSTRUCCION Página 55
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:
CAPITULO IV CONSTRUCCION Página 56
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.
CAPITULO IV CONSTRUCCION Página 57
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
CAPITULO IV CONSTRUCCION Página 58
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
CAPITULO IV CONSTRUCCION Página 59
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.
CAPITULO IV CONSTRUCCION Página 60
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
CAPITULO IV CONSTRUCCION Página 61
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.
CAPITULO IV CONSTRUCCION Página 62
Ilustración 20 Equipos de shotcrete
CAPITULO IV CONSTRUCCION Página 63
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
CAPITULO IV CONSTRUCCION Página 64
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°.
CAPITULO IV CONSTRUCCION Página 65
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.
CAPITULO IV CONSTRUCCION Página 66
Ilustración 21 Bomba hidraulica A4VG125
Ilustración 22 Bomba de giro de cuba A4VTG71
Ilustración 23 Motor diesel BF4M2012C
CAPITULO IV CONSTRUCCION Página 67
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
CAPITULO IV CONSTRUCCION Página 68
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
CAPITULO IV CONSTRUCCION Página 69
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
CAPITULO IV CONSTRUCCION Página 70
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
CAPITULO IV CONSTRUCCION Página 71
ARRANCADOR MIXRET 4 C6.6 24V
CAPITULO IV CONSTRUCCION Página 72
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
CAPITULO IV CONSTRUCCION Página 73
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
FUENTE: Elaboración Propia
CAPITULO IV CONSTRUCCION Página 74
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
CAPITULO IV CONSTRUCCION Página 75
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.
FUENTE: Elaboración Propia
CAPITULO IV CONSTRUCCION Página 76
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
CAPITULO IV CONSTRUCCION Página 77
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.
CAPITULO IV CONSTRUCCION Página 78
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
CAPITULO IV CONSTRUCCION Página 79
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
CAPITULO IV CONSTRUCCION Página 80
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
CAPITULO IV CONSTRUCCION Página 81
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
CAPITULO IV CONSTRUCCION Página 82
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
CAPITULO IV CONSTRUCCION Página 83
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.
CAPITULO IV CONSTRUCCION Página 84
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.
CAPITULO IV CONSTRUCCION Página 85
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.
CAPITULO IV CONSTRUCCION Página 86
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.
CAPITULO IV CONSTRUCCION Página 87
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.
CAPITULO IV CONSTRUCCION Página 88
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
CAPITULO IV CONSTRUCCION Página 89
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
CAPITULO IV CONSTRUCCION Página 90
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
CAPITULO IV CONSTRUCCION Página 91
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.
CAPITULO IV CONSTRUCCION Página 92
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
CAPITULO IV CONSTRUCCION Página 93
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
CAPITULO IV CONSTRUCCION Página 94
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
CAPITULO IV CONSTRUCCION Página 95
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
CAPITULO IV CONSTRUCCION Página 96
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.
CAPITULO IV CONSTRUCCION Página 97
Ilustración 28 Arquitectura del sistema
CAPITULO IV CONSTRUCCION Página 98
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
CAPITULO IV CONSTRUCCION Página 99
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
CAPITULO IV CONSTRUCCION Página 100
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.
CAPITULO IV CONSTRUCCION Página 101
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
CAPITULO IV CONSTRUCCION Página 102
Ilustración 30LINQ.dbml
CAPITULO IV CONSTRUCCION Página 103
Ilustración 31 Entidad LINQ.dbml
3.1.2 Diseño de la arquitectura de la solución
CAPITULO IV CONSTRUCCION Página 104
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
CAPITULO IV CONSTRUCCION Página 105
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
CAPITULO IV CONSTRUCCION Página 106
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
CAPITULO IV CONSTRUCCION Página 107
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
CAPITULO IV CONSTRUCCION Página 108
C. Paquete Orden de trabajo
Este paquete contiene las clases que registran información sobre las
ó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
CAPITULO IV CONSTRUCCION Página 109
D. Paquete Despacho
Este paquete contiene las clases que registran información sobre las
ó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
CAPITULO IV CONSTRUCCION Página 110
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
CAPITULO IV CONSTRUCCION Página 111
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
CAPITULO IV CONSTRUCCION Página 112
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
CAPITULO IV CONSTRUCCION Página 113
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
CAPITULO IV CONSTRUCCION Página 114
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
CAPITULO IV CONSTRUCCION Página 115
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
CAPITULO IV CONSTRUCCION Página 116
L. Relaciones entre Clases
CAPITULO IV CONSTRUCCION Página 117
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.
CAPITULO IV CONSTRUCCION Página 118
A. Diagrama Inicial Sesión
Ilustración 46 Diagrama Iniciar Sesión
CAPITULO IV CONSTRUCCION Página 119
B. Diagrama Registrar Recepción
Ilustración 47 Diagrama Registrar Recepción
CAPITULO IV CONSTRUCCION Página 120
C. Diagrama Registrar Orden de Servicio
Ilustración 48 Diagrama Orden de Servicio
CAPITULO IV CONSTRUCCION Página 121
D. Diagrama Registrar Orden de Trabajo
Ilustración 49 Diagrama Registrar Orden de trabajo
CAPITULO IV CONSTRUCCION Página 122
E. Diagrama Registrar Despacho
Ilustración 50 Vista Registrar Despachos
CAPITULO IV CONSTRUCCION Página 123
F. Diagrama Asignaciones OS
Ilustración 51 Diagrama Asignaciones OS
CAPITULO IV CONSTRUCCION Página 124
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
CAPITULO IV CONSTRUCCION Página 125
H. Vista general del esquema de la base de datos
CAPITULO IV CONSTRUCCION Página 126
Ilustración 53 Esquema general de la base de datos
CAPITULO IV CONSTRUCCION Página 127
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.
CAPITULO IV CONSTRUCCION Página 128
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
CAPITULO IV CONSTRUCCION Página 129
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
CAPITULO IV CONSTRUCCION Página 130
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
CAPITULO IV CONSTRUCCION Página 131
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
CAPITULO IV CONSTRUCCION Página 132
E. Secuencia Iniciar Sesión
this : FrmIniciomodulos : Modulomodulos.m : ClasesLINQ
FrmInicio_Load
Create Modulo
modulos
<<return>>
Create ClasesLINQ
m
<<return>>
Create LINQDataContext
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>>
ListarModulos_sin_repetidos
m.ListarModulos_sin_repetidos
<<return>>
ListarModulos
modulos.ListarModulos
<<return>>
ListarModulos
m.ListarModulos()
<<return>>
ListarMod
modulos.ListarMod
<<return>>
ListarModulos_sin_repetidos
m.ListarModulos_sin_repetidos
<<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
CAPITULO IV CONSTRUCCION Página 133
F. Secuencia Eliminar Recepción
this : FrmRecepcion_Eliminar ORecep : RecepcionORecep.DAL : ClasesLINQ
btnElimRecepcion_Click
Create Recepcion
ORecep
<<return>>
Create ClasesLINQ
DAL
<<return>>
Create LINQDataContext
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)]
CAPITULO IV CONSTRUCCION Página 134
G. Secuencia Eliminar Recepción Detalles
this : FrmRecepcion_EliminarORecepdetalles : RecepcionDetalles ORecepdetalles.DAL : ClasesLINQ
btnElimRecepcionDetalles_Click
Create RecepcionDetalles
ORecepdetalles
<<return>>
Create ClasesLINQ
DAL
<<return>>
Create LINQDataContext
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]
CAPITULO IV CONSTRUCCION Página 135
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>>
Create LINQDataContext
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...
Create OrdendeServicioDetalles
ReporteOS
<<return>>
Create ClasesLINQ
DAL
<<return>>
Create LINQDataContext
Create FrmImpresiones
frm
<<return>>
CAPITULO IV CONSTRUCCION Página 136
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>>
Create LINQDataContext
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...
Create OrdendeServicioDetalles
ReporteOT
<<return>>
Create ClasesLINQ
DAL
<<return>>
Create LINQDataContext
Create FrmImpresiones
frm
<<return>>
CAPITULO IV CONSTRUCCION Página 137
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.
CAPITULO IV CONSTRUCCION Página 138
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
CAPITULO IV CONSTRUCCION Página 139
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
CAPITULO IV CONSTRUCCION Página 140
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
CAPITULO IV CONSTRUCCION Página 141
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.
CAPITULO IV CONSTRUCCION Página 142
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:
CAPITULO IV CONSTRUCCION Página 143
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.
CAPITULO IV CONSTRUCCION Página 144
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
CAPITULO IV CONSTRUCCION Página 145
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.
CAPITULO IV CONSTRUCCION Página 146
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
CAPITULO IV CONSTRUCCION Página 147
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:
CAPITULO IV CONSTRUCCION Página 148
Ilustración 65 Reporte de Recepciones
CAPITULO IV CONSTRUCCION Página 149
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
CAPITULO IV CONSTRUCCION Página 150
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.
CAPITULO IV CONSTRUCCION Página 151
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
CAPITULO IV CONSTRUCCION Página 152
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.
CAPITULO IV CONSTRUCCION Página 153
Ilustración 67 Logo de VB.net
CAPITULO IV CONSTRUCCION Página 154
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
CAPITULO IV CONSTRUCCION Página 155
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
CAPITULO IV CONSTRUCCION Página 156
Ilustración 71 O/R Designer
CAPITULO IV CONSTRUCCION Página 157
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.
CAPITULO IV CONSTRUCCION Página 158
Ilustración 72 Logo de Visual Studio 2012
Ilustración 73 Pantalla de trabajo de Visual Studio 2012
CAPITULO IV CONSTRUCCION Página 159
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.
CAPITULO IV CONSTRUCCION Página 160
Ilustración 74 Logo SQL Server 2012
Ilustración 75 Pantalla de trabajo SQL Server 2012 Management Studio
CAPITULO IV CONSTRUCCION Página 161
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.
CAPITULO IV CONSTRUCCION Página 162
Ilustración 76 Vista previa de Report Viewer
CAPITULO IV CONSTRUCCION Página 163
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
CAPITULO IV CONSTRUCCION Página 164
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á
CAPITULO IV CONSTRUCCION Página 165
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.
CAPITULO IV CONSTRUCCION Página 166
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:
CAPITULO IV CONSTRUCCION Página 167
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
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
“Contraseña” 100%
SES-
003
Segurida
d Unitario Ingresar Usuario y Contraseña
IniciarSesion.v
b Verificar que el usuario pueda salir del programa al hacer clic en "Cancelar" 100%
SES-
004
Segurida
d Unitario Ingresar Usuario y Contraseña
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
Manipular los controles de la ventana de
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
Manipular los controles de la ventana de
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
Manipular los controles de la ventana de
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
Manipular los controles de la ventana de
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
Dar mantenimiento a la base componentes
VP
FrmComponentesVP_Mantenimiento.
vb Verificar que el usuario pueda registrar un nuevo componenteVP. 100%
MTT-CVP-
003
Mantenimient
o Unitario
Dar mantenimiento a la base componentes
VP
FrmComponentesVP_Mantenimiento.
vb Verificar que el usuario pueda actualizar un nuevo componenteVP. 100%
CAPITULO IV CONSTRUCCION Página 168
MTT-CVP-
004
Mantenimient
o Unitario
Dar mantenimiento a la base componentes
VP
FrmComponentesVP_Mantenimiento.
vb Verificar que el usuario pueda eliminar un nuevo componenteVP. 100%
MTT-CVP-
005
Mantenimient
o Unitario
Dar mantenimiento a la base componentes
VP
FrmComponentesVP_Mantenimiento.
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
ID_Test Modulo Prueba_Tipo Caso de Prueba Formulario Descripcion Status
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-
002 Mantenimiento Unitario Dar mantenimiento a la tabla empleados
FrmEmpleados_Mantenimiento.v
b Verificar que el usuario pueda registrar un Empleado. 100%
MTT-EMP-
003 Mantenimiento Unitario Dar mantenimiento a la tabla empleados
FrmEmpleados_Mantenimiento.v
b Verificar que el usuario pueda actualizar un Empleado. 100%
MTT-EMP-
004 Mantenimiento Unitario Dar mantenimiento a la tabla empleados
FrmEmpleados_Mantenimiento.v
b Verificar que el usuario pueda eliminar un nuevo Empleado. 100%
MTT-EMP-
005 Mantenimiento Unitario Dar mantenimiento a la tabla empleados
FrmEmpleados_Mantenimiento.v
b Verificar que el usuario pueda visualizar todos los empleados activos y realizar una búsqueda. 100%
CAPITULO IV CONSTRUCCION Página 169
E. Pruebas Unitarias Equipos
Tabla 20 Pruebas unitarias Equipos
ID_Test Modulo Prueba_Tipo Caso de Prueba Formulario Descripcion Status
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
ID_Test Modulo Prueba_Tipo Caso de Prueba Formulario Descripcion Status
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
o Unitario Registrar una asignacion
FrmAsignacion_Registrar.v
b Verificar que el usuario pueda registrar un nuevo AsignacionesOS. 100%
MTT-SIG-
003
Mantenimient
o Unitario Registrar una asignacion
FrmAsignacion_Registrar.v
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
o Unitario Registrar una asignacion
FrmAsignacion_Registrar.v
b Verificar que el usuario pueda visualizar todos los AsignacionesOS activos y realizar una búsqueda. 100%
CAPITULO IV CONSTRUCCION Página 170
G. Pruebas Unitarias Recepción
Tabla 22 Pruebas Unitarias Recepcion
ID_Test Modulo Prueba_Tipo Caso de Prueba Formulario Descripcion Status
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
ID_Test Modulo Prueba_Tipo Caso de Prueba Formulario Descripcion Status
PLN-OT-001 Planeamiento Unitario Generar Orden de Trabajo FrmOT_registrar.vb Verificar que el usuario pueda registrar una nueva Orden de Trabajo. 100%
CAPITULO IV CONSTRUCCION Página 171
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%
CAPITULO IV CONSTRUCCION Página 172
J. Pruebas Unitarias Despachos
ID_Test Modulo Prueba_Tipo Caso de Prueba Formulario Descripcion Status
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%
CAPITULO IV CONSTRUCCION Página 173
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.
CAPITULO IV CONSTRUCCION Página 174
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.
CAPITULO IV CONSTRUCCION Página 175
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.
CAPITULO IV CONSTRUCCION Página 176
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
CAPITULO IV CONSTRUCCION Página 177
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.
CAPITULO IV CONSTRUCCION Página 178
CAPITULO IV CONSTRUCCION Página 179
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.
CAPITULO IV CONSTRUCCION Página 180
CAPITULO IV CONSTRUCCION Página 181
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.
CAPITULO IV CONSTRUCCION Página 182
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.
CAPITULO IV CONSTRUCCION Página 183
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
CAPITULO IV CONSTRUCCION Página 184
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
CAPITULO IV CONSTRUCCION Página 185
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.
CAPITULO IV CONSTRUCCION Página 186
7.2 Calculo de la energia
Ilustración 78 Fuente: http://michaelbluejay.com/electricity/computers.html
Ilustración 79 Plana tarifaria OSINERGMIN
CAPITULO IV CONSTRUCCION Página 187
7.3 Objetos LINQ to SQL
CAPITULO IV CONSTRUCCION Página 188
CAPITULO IV CONSTRUCCION Página 189
CAPITULO IV CONSTRUCCION Página 190
CAPITULO IV CONSTRUCCION Página 191
CAPITULO IV CONSTRUCCION Página 192
CAPITULO IV CONSTRUCCION Página 193