Vous êtes sur la page 1sur 83

UNIVERSIDAD ANDRS BELLO

FACULTAD DE INGENIERA
ESCUELA DE INFORMTICA
INGENIERA EN COMPUTACIN E INFORMTICA

Software de Administracin para la Realizacin de


Mantenciones y Reparaciones de Vehculos
CRISTIAN RODRIGO VSQUEZ LEAN

PROYECTO DE TTULO PARA OPTAR AL TTULO DE


INGENIERO EN COMPUTACIN E INFORMTICA

SANTIAGO CHILE
SEPTIEMBRE 2012

AGRADECIMIENTO
Muchas gracias a todos quienes me apoyaron y estuvieron junto a m durante todo ste
proceso, el cual signific de muchos momentos difciles, como tambin de momentos
gratificantes, los cuales lograron mantener la motivacin para poder salir adelante.

En primer lugar, quiero agradecer a mis compaeros tanto por el apoyo moral, como
tambin por creer en m. Principalmente, agradezco la compaa durante largas tardes
cada semana. A su vez, Quiero agradecer a Oscar Pinto G, quien fue mi profesor gua y
una gran persona en la cual pude obtener todo el apoyo, respaldo y tiempo, como
tambin la confianza y motivacin para poder continuar y avanzar con mi proyecto de
software.

A mis amigos, por entender y considerarme en todo pese a mi ausencia durante tanto
tiempo.
Finalmente, agradecer a mi familia por permitir que ste sueo se convierta en realidad,
sin duda es el pilar fundamental para poder lograr cualquier cosa.

NDICE DE CONTENIDO
RESUMEN
2

INTRODUCCIN .......................................................................................................................................................... 1
1.1
1.2
1.3
1.4
1.5

SITUACIN ACTUAL ............................................................................................................................................................. 1


ACTORES RELEVANTES DE LA SITUACIN ACTUAL ........................................................................................................................ 2
EL PROBLEMA .................................................................................................................................................................... 3
EXPLICACIN DEL PROBLEMA ................................................................................................................................................. 4
PROPSITO DE LA SOLUCIN.................................................................................................................................................. 5

FUNDAMENTACIN DEL TEMA ................................................................................................................................... 7


2.1 SOLUCIN PROPUESTA ......................................................................................................................................................... 8
2.2 DETALLES DE LA SOLUCIN .................................................................................................................................................... 9
2.3 PROCESOS DE NEGOCIOS INTERVENIDOS .................................................................................................................................. 9
2.4 OBJETIVOS ....................................................................................................................................................................... 11
2.4.1
Objetivo General ................................................................................................................................................. 11
2.4.2
Objetivos Especficos ........................................................................................................................................... 11
2.4.3
Consideraciones .................................................................................................................................................. 12
2.4.4
Respecto del Software ........................................................................................................................................ 12
2.4.5
Supuestos ............................................................................................................................................................ 12
2.4.6
Limitaciones ........................................................................................................................................................ 13
2.4.7
Criterios de Aceptacin ....................................................................................................................................... 13

MATERIALES Y MTODOS ......................................................................................................................................... 15


3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
3.19

PROCESO ......................................................................................................................................................................... 16
PLAN DE CALIDAD ............................................................................................................................................................. 17
PLAN DE TRABAJO ............................................................................................................................................................. 18
PLAN DE GESTIN DE RIESGOS ............................................................................................................................................. 19
PLAN DE COMUNICACIONES ................................................................................................................................................ 21
PLAN DE ACEPTACIN DEL PROYECTO ................................................................................................................................... 22
PLAN DE GESTIN DE LA CONFIGURACIN.............................................................................................................................. 23
PLAN DE RESOLUCIN DE CONTROVERSIAS ............................................................................................................................. 25
PLAN DE DOCUMENTACIN................................................................................................................................................. 26
PLAN DE INFRAESTRUCTURA ........................................................................................................................................... 27
PLAN DE RECURSOS HUMANOS ....................................................................................................................................... 28
PLAN DE CIERRE DEL PROYECTO ...................................................................................................................................... 29
PRODUCTO.................................................................................................................................................................. 30
ANLISIS ..................................................................................................................................................................... 31
DISEO ...................................................................................................................................................................... 32
CONSTRUCCIN ........................................................................................................................................................... 33
PRUEBAS .................................................................................................................................................................... 33
IMPLANTACIN ............................................................................................................................................................ 34
PROCESO VS PRODUCTO ................................................................................................................................................ 34

RESULTADOS Y DISCUSIN ....................................................................................................................................... 36


4.1
4.2
4.3
4.4
4.5
4.6
4.7

RESULTADOS PLAN DE CALIDAD ........................................................................................................................................... 36


RESULTADOS PLAN DE TRABAJO ........................................................................................................................................... 36
RESULTADOS PLAN DE GESTIN DE RIESGOS........................................................................................................................... 39
RESULTADOS PLAN DE COMUNICACIN ................................................................................................................................. 41
RESULTADOS PLAN DE ACEPTACIN DEL PROYECTO ................................................................................................................. 42
RESULTADOS GESTIN DE LA CONFIGURACIN ........................................................................................................................ 43
RESULTADOS PLAN DE RESOLUCIN DE CONTROVERSIAS........................................................................................................... 46

4.8 RESULTADOS PLAN DE DOCUMENTACIN .............................................................................................................................. 46


4.9 RESULTADOS PLAN DE INFRAESTRUCTURA .............................................................................................................................. 47
4.10
RESULTADO PLAN DE RECURSOS HUMANOS ...................................................................................................................... 48
4.11
RESULTADOS PLAN DE CIERRE DEL PROYECTO .................................................................................................................... 50
4.12
RESULTADOS DEL PRODUCTO .......................................................................................................................................... 51
4.12.1
Resultados Anlisis ......................................................................................................................................... 51
4.12.2
Resultados Diseo .......................................................................................................................................... 55
4.12.3
Resultados Construccin ................................................................................................................................ 63
4.12.4
Resultados Pruebas ........................................................................................................................................ 65
6

CONCLUSIONES......................................................................................................................................................... 71

BIBLIOGRAFAS ......................................................................................................................................................... 74

NDICE DE TABLAS
TABLA 1 ESTIMACIN PROYECTO ..................................................................................................................................................... 37
TABLA 2 RIESGOS IDENTIFICADOS..................................................................................................................................................... 39
TABLA 3 MITIGACIN Y CONTINGENCIA DE LOS RIESGOS ...................................................................................................................... 41
TABLA 4 EQUIPO ADMINISTRADOR................................................................................................................................................... 42
TABLA 5 EQUIPO ENCARGADO BODEGA ............................................................................................................................................ 43
TABLA 6 TEMS DE CONFIGURACIN ................................................................................................................................................. 43
TABLA 7 ROL GESTIN DE LA CONFIGURACIN ................................................................................................................................... 44
TABLA 8 LNEAS BASE .................................................................................................................................................................... 45
TABLA 9 HARDWARE INFRAESTRUCTURA ........................................................................................................................................... 47
TABLA 10 HARDWARE INFRAESTRUCTURA (2) .................................................................................................................................... 47
TABLA 11 ROLES DEL EQUIPO DEL PROYECTO ..................................................................................................................................... 49
TABLA 12 ROLES POR PARTE DEL CLIENTE .......................................................................................................................................... 50
TABLA 13 CIERRE ETAPAS CICLO VIDA PROYECTO ............................................................................................................................... 51
TABLA 14 REQUERIMIENTO MDULO INGRESO .................................................................................................................................. 52
TABLA 15 REQUERIMIENTO MDULO DE ADMINISTRACIN .................................................................................................................. 53
TABLA 16 MDULO INFORMES E INDICADORES .................................................................................................................................. 53
TABLA 17 MDULO COMPRAS ........................................................................................................................................................ 54
TABLA 18 MDULO RETIRO REPUESTOS ........................................................................................................................................... 54
TABLA 19 MDULO ORDEN DE TRABAJO .......................................................................................................................................... 55
TABLA 20 VISTAS DE KRUCHTEN 4+1 ............................................................................................................................................... 55
TABLA 21 TIPOS DE PRUEBAS .......................................................................................................................................................... 65
TABLA 22 RESPONSABLES PRUEBAS.................................................................................................................................................. 66
TABLA 23 MATRIZ CASOS DE PRUEBA............................................................................................................................................... 67
TABLA 24 MATRIZ EJECUCIN PRUEBAS ........................................................................................................................................... 68
TABLA 25 RESULTADOS CICLOS PRUEBAS .......................................................................................................................................... 68

NDICE DE FIGURAS
FIGURA 1 - SITUACIN ACTUAL ............................................................................................................................................................ 2
FIGURA 2 - ACTORES SITUACIN ACTUAL ................................................................................................................................................ 2
FIGURA 3 - DIAGRAMA ISHIKAWA ......................................................................................................................................................... 3
FIGURA 4 - MAPA IDEAS NECESIDADES CLIENTE ...................................................................................................................................... 7
FIGURA 5 - SOLUCIN PROPUESTA........................................................................................................................................................ 8
FIGURA 6 - CASO DE USO PROCESO DE NEGOCIO INTERVENIDO................................................................................................................ 10
FIGURA 7 - NIVELES TPICOS DE COSTO Y DOTACIN DE PERSONAL DURANTE EL CICLO DE VIDA DEL PROYECTO ................................................ 15
FIGURA 8 - ETAPAS DEFINIDAS EN PMBOK.......................................................................................................................................... 16
FIGURA 9 - PLAN DE CALIDAD ............................................................................................................................................................ 17
FIGURA 10 - PLAN DE TRABAJO .......................................................................................................................................................... 18
FIGURA 11 - PLAN DE GESTIN DE RIESGOS ......................................................................................................................................... 19
FIGURA 12 - PLAN DE GESTIN DE RIESGOS (2) .................................................................................................................................... 20
FIGURA 13 - PLAN DE COMUNICACIN ................................................................................................................................................ 21
FIGURA 14 - PLAN DE ACEPTACIN DEL PROYECTO ................................................................................................................................ 22
FIGURA 15 - PLAN DE GESTIN DE LA CONFIGURACIN .......................................................................................................................... 23
FIGURA 16 - CONTROL DE CAMBIOS ................................................................................................................................................... 24
FIGURA 17 - PLAN DE RESOLUCIN DE CONTROVERSIAS ......................................................................................................................... 25
FIGURA 18 - PLAN DE DOCUMENTACIN ............................................................................................................................................. 26
FIGURA 19 - PLAN DE INFRAESTRUCTURA ............................................................................................................................................. 27
FIGURA 20 - PLAN DE RECURSOS HUMANOS ........................................................................................................................................ 28
FIGURA 21 - PLAN DE CIERRE DEL PROYECTO ........................................................................................................................................ 29
FIGURA 22 - MODELO EN CASCADA CON RETROALIMENTACIN ............................................................................................................... 30
FIGURA 23 - INGENIERA DE REQUERIMIENTOS ...................................................................................................................................... 31
FIGURA 24 - PLAN DE PRUEBAS.......................................................................................................................................................... 33
FIGURA 25 - CRONOGRAMA PROYECTO ............................................................................................................................................... 37
FIGURA 26 - CARTA GANTT ............................................................................................................................................................... 39
FIGURA 27 - CAMBIO TEM DE CONFIGURACIN.................................................................................................................................... 44
FIGURA 28 - ORGANIGRAMA DEL PROYECTO ........................................................................................................................................ 48
FIGURA 29 - DIAGRAMA CASO DE USO GENERAL ................................................................................................................................ 56
FIGURA 30 - CASO DE USO MDULO RETIRO REPUESTOS .................................................................................................................... 56
FIGURA 31 - CASO DE USO MDULO ORDEN DE TRABAJO.................................................................................................................... 57
FIGURA 32 - CASO DE USO MDULO INFORMES ................................................................................................................................ 57
FIGURA 33 - CASO DE USO MDULO COMPRAS ................................................................................................................................. 58
FIGURA 34 - DIAGRAMA DE SECUENCIA REGISTRAR FALLA EN ORDEN DE TRABAJO .................................................................................... 58
FIGURA 35 - DIAGRAMA DE SECUENCIA RETIRO DE REPUESTO ............................................................................................................... 59
FIGURA 36 - DIAGRAMA DE SECUENCIA REGISTRAR ORDEN DE TRABAJO ................................................................................................. 59
FIGURA 37 - DIAGRAMA DE CLASES .................................................................................................................................................... 60
FIGURA 38 - DIAGRAMA DE COMPONENTES ......................................................................................................................................... 61
FIGURA 39 - DIAGRAMA DE DESPLIEGUE .............................................................................................................................................. 62
FIGURA 40 - SOFTWARE AMRV MDULO INGRESO............................................................................................................................ 63
FIGURA 41 - SOFTWARE AMRV VENTANA PRINCIPAL ......................................................................................................................... 64
FIGURA 42 - SOFTWARE AMRV MDULO ORDEN DE TRABAJO ............................................................................................................ 64
FIGURA 43 - DURACIN FINAL PROYECTO ............................................................................................................................................ 69

CAPTULO I
RESUMEN

1 Resumen
El objetivo de ste proyecto de software, es desarrollar una herramienta que apoye por
un lado la administracin de los repuestos, los cuales se encuentran bajo la
responsabilidad de un encargado de bodega, y por otro apoyar el trabajo realizado por
el mecnico en cada vehculo que compone a la empresa SOPRAF S.A., en donde las
tareas que deba realizar, sern planificadas por un administrador a travs de la
herramienta desarrollada.

ste documento se ha dividido en seis captulos, dentro de los cuales el primero


corresponde a un resumen en el cual se establece una sntesis respecto al propsito y
los objetivos de todo el contenido posterior del documento, para luego dar paso a la
introduccin, fundamentacin del tema, materiales y mtodos utilizados, para poder
lograr planificar y disear lo que ser el producto final a travs de un proceso
secuenciado por actividades. Posteriormente, continua el captulo de los resultados
obtenidos, en donde se demuestra todo lo que se ha realizado en el proyecto,
finalizando con el captulo de conclusiones y experiencias adquiridas a lo largo de la
transicin del proyecto, el cual entrega como resultado una aplicacin que contiene las
actividades necesarias para solucionar la problemtica del cliente.

Al concluir el proyecto, se obtiene una herramienta informtica basada en un conjunto


de necesidades para poder mantener un orden del trabajo, realizado por un
administrador, un mecnico y un encargado de bodega. A su vez, proporcionar un valor
agregado entregando reportes que permitirn al cliente poder tomar una decisin ms
segura al momento de realizar una compra de repuestos, entregando informacin
necesaria para realizar una compra por mayor, con el objetivo de tener un stock
mensual. Finalmente, tener un registro de las fallas en detalle por vehculo.

CAPTULO II
INTRODUCCIN

Captulo II

2 Introduccin
El presente proyecto fue desarrollado para la empresa SOPRAF S.A., empresa de Taxis
Colectivos la cual est dedicada al rubro del transporte pblico de pasajeros dentro de
la comuna de Puente Alto.
SOPRAF S.A., es una empresa dedicada a su labor con el nimo de crecer cada da y
entregar un servicio seguro a sus clientes, necesita apoyo para estructurar y mejorar su
servicio de mantenimiento y reparacin de vehculos. Es por ello la razn por la cual se
propuso la realizacin de ste proyecto de software.
Para poder trabajar como empresa de transporte pblico de pasajeros, se debe
concursar a travs de una licitacin en el Ministerio de Transportes cada cierto ciclo de
aos. La licitacin est compuesta por diferentes normas que deben ser cumplidas para
poder ganar el permiso y poder operar.

2.1

Situacin Actual

El trabajo del mecnico consiste en realizar lo que estime necesario para cada vehculo
a medida que estos van llegando al terminal. Cabe destacar que no existe ninguna
planificacin por parte del mecnico. A su vez, el trabajo tambin se basa en atender
otros problemas siempre y cuando el conductor se percate de que algo no est
funcionando correctamente, o escuche algn ruido que genere inquietudes.
Para realizar alguna reparacin en el caso de encontrar una falla, el mecnico se dirige
hacia algn miembro del directorio y solicita el repuesto que necesita para realizar su
trabajo. Si no existe la disponibilidad para poder atender la solicitud, es el mecnico
quien puede obtener la facultad para poder realizar un retiro de estos bajo un permiso
otorgado.
Al obtener el repuesto, procede a hacer uso de ste para realizar la reparacin y finaliza
su trabajo demostrando al conductor que el problema ha sido solucionado. Se recalca,
que ste trabajo realizado de vez en cuando es registrado en una hoja de una agenda
personal, o un cuaderno.
Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

Reparacin o Mantencin Vehculo

OFICINA

Captulo II

Mecnico
Mecnico

Mecnico
Mecnico

TALLER

Encargado
Encargado Bodega
Bodega

Retiro
Retiro repuesto
repuesto

Figura 1 Situacin Actual

2.2

Actores relevantes de la situacin actual

El mecnico junto a algn miembro del directorio que por lo general es el designado
como encargado de bodega, son los principales actores de esta situacin.
uc Use Case Model

Encargado de
Bodega

Mecnico

Figura 2 - Actores situacin actual

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

Captulo II

2.3

El Problema

En la empresa SOPRAF S.A., existe una gran prdida de dinero en pagos de multas,
como tambin en la compra de repuestos, los cuales por falta de stock deben ser
adquiridos semanalmente en pocas unidades para poder realizar algn trabajo de
carcter mecnico en los vehculos de la empresa.

El mantenimiento de los vehculos tambin es un problema, ya que no se cuenta con la


suficiente organizacin, lo que implica no poseer evidencia respecto al trabajo que se
ha hecho en cada vehculo, mucho menos tener un conocimiento de los repuestos
utilizados y las fallas detectadas o bien reparadas.

A continuacin, se presenta un diagrama Ishikawa (cola de pez) para poder especificar


las causas del problema principal que acontecen en la empresa:

Figura 3 - Diagrama Ishikawa

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

Captulo II

2.4

Explicacin del problema

Algo que sucede comnmente en ste tipo de empresas, es dejar de lado el


cumplimiento de las normas solicitadas por el Ministerio de Transportes. Esto ocurra
debido a la falta de fiscalizacin, pero, con las nuevas implementaciones que se han
realizado en estos procesos, las multas comenzaron a ser reiteradas generando una
mayor prdida de dinero en la empresa, como tambin en los conductores de cada
vehculo al no contar con las mantenciones necesarias en estos. Obteniendo como
resultado final para los pasajeros, un servicio inseguro debido a la vulnerabilidad ante
una eventual falla, lo cual resulta muy probable.
Por otro lado, el taller mecnico en la empresa cuenta con escasa organizacin, esto
quiere decir que el orden en el trabajo que se debe realizar da a da a los vehculos
que se revisan en el taller tiene como consecuencia un trabajo incompleto la mayora de
las veces. Una de las grandes problemticas frente a esta situacin es el
desconocimiento por parte de los directores de la empresa respecto al trabajo que el
mecnico ha realizado a cierto vehculo. Generando muchos problemas debido a que la
mayora de estos son de la misma marca y modelo, donde slo pueden ser
diferenciados por su patente, lo que provoca en el mecnico realizar el mismo tipo de
trabajo al mismo vehculo durante el mismo da, ms de una vez.
Adems, respecto a la distribucin de los repuestos se tiene un conocimiento casi nulo,
al no recordar la mayora de las veces en donde se suministr cierto repuesto, lo cual
tambin se ha prestado para sufrir prdidas y robos.

Junto a lo sealado anteriormente, existe tambin un problema respecto a las fallas que
sufren los vehculos. Por un lado, un vehculo es reparado cuando tiene una falla, al
tener diferentes modelos dentro de la empresa, la falla para un modelo de vehculo y su
reparacin es diferente a la que pueda acontecer en otro modelo, como tambin su
reparacin y el tipo de repuesto que se debe utilizar.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

Captulo II

Es tambin por esta razn, que el trabajo realizado carece de informacin necesaria
para saber cmo se realiz la reparacin. Obteniendo comnmente como resultado en
ste trabajo que una falla vuelva a aparecer en un muy corto plazo despus de ser
reparada, lo que provoca en el mecnico volver a analizar la falla y gastar tiempo
nuevamente en pensar alguna solucin, ya que en ningn lugar se dej sealado cmo
se realiz algn trabajo de iguales caractersticas, o bien similares.

2.5

Propsito de la solucin

Para solucionar los problemas sealados anteriormente, se propone la creacin de un


proyecto de software que tendr la capacidad de organizar el trabajo que deba realizar
el mecnico a travs de rdenes de trabajo generadas por un administrador, las que
permitirn registrar los repuestos utilizados, las fallas detectadas y el tipo de servicio
que se le debe entregar a cada vehculo en particular durante una fecha determinada.
Por otro lado, registrar el ingreso y retiro de repuestos por parte del personal encargado
de bodega.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

CAPTULO III
FUNDAMENTACIN DEL TEMA

Captulo III

3 Fundamentacin del Tema


Respecto al proceso de negocio del cliente, a travs del anlisis ejecutado y a la
identificacin del problema, se lograron establecer las siguientes necesidades que
presenta para poder llevar a cabo su trabajo de una manera ms organizada.
A continuacin, se presenta un mapa de ideas dentro del cual se pueden observar las
ventajas que el cliente obtendr con el proyecto de software, como tambin una visin
general respecto al funcionamiento que ste tendr, y la organizacin que se
presentar una vez que se comience a utilizar la herramienta.

Figura 4 - Mapa Ideas Necesidades Cliente

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

Captulo III

3.1

Solucin Propuesta

Dado todos los antecedentes mencionados, esta propuesta se basa en ofrecer una
aplicacin que cubra las principales necesidades de la empresa, apoyando de esta
manera tanto la labor del directorio, del encargado de bodega y del encargado de la
mantencin y reparacin de vehculos. ste software (producto) se compone de una
aplicacin de escritorio (cliente) en donde cada usuario podr realizar las funciones que
le corresponda segn el rol que cumpla dentro de la empresa.

A continuacin, se presenta el funcionamiento que tendrn los diferentes actores dentro


de la solucin propuesta:

Figura 5 - Solucin Propuesta

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

Captulo III

3.2

Detalles de la solucin

La solucin de software que se ha propuesto deber contar con seis mdulos, dentro de
los cuales deber permitir mantener un registro del personal trabajando en la empresa
(conductores, administradores, encargados de bodega y mecnicos), como tambin
registros de los vehculos y la asociacin de estos a sus correspondientes conductores.
Cabe destacar, que parte de la solucin ser tener un registro de las fallas que se
producen en los vehculos, como tambin el ingreso de los repuestos que son
comprados a los proveedores y a la vez suministrados a cada uno de los vehculos.
ste suministro se realizar bajo la supervisin del encargado de bodega, el cual ser
el nico responsable de poder retirar algn repuesto solicitado por el mecnico, y ste
retiro estar asociado a la correspondiente orden de trabajo emitida por el administrador
del software.
El ingreso de los nuevos repuestos ser utilizando un generador de cdigos de barra, el
cual permitir imprimir los cdigos segn los productos adquiridos, para luego realizar el
registro de los productos a travs de un mdulo de compras complementado por un
lector de cdigo de barras.
Finalmente, generar informes respecto al trabajo realizado por parte del mecnico,
como tambin de los repuestos ms utilizados y comprados, fallas ms reiteradas,
como tambin la cantidad de rdenes de trabajo por vehculo, entre otros.

3.3
Los

Procesos de Negocios Intervenidos


procesos

asociados

para

el

Mecnico

cambiarn,

agregando

nuevas

funcionalidades a su rol, que sern el registro de las fallas al momento de estar


realizando una reparacin o mantencin, como tambin las observaciones que ste
debe indicar dentro de los servicios que vaya realizando. De esta manera, se podr
mantener un mayor control y cumplimiento de lo que se espera en su trabajo.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

Captulo III

Figura 6 Caso de Uso Proceso de Negocio Intervenido

Para el Encargado de Bodega, las funcionalidades que cumplir sern las mismas, sin
embargo el registro de los repuestos retirados ser algo fundamental para poder llevar
un control de stock ms claro.
Junto a esto, se decidi junto con el cliente agregar a un nuevo actor llamado
Administrador para que participe en la solucin. ste deber encargarse de la
generacin de nuevas rdenes de trabajo, la cual estar constituida por servicios que
un Mecnico debe realizar.
La asignacin de los vehculos que deber revisar, estar indicada en la orden de
trabajo impresa, en donde adems el mecnico tiene que cumplir con detallar el trabajo
de los servicios indicados y las fallas detectadas.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

10

Captulo III

3.4

Objetivos

SOPRAF S.A. es una empresa dedicada a la labor de transporte pblico de pasajeros,


con el nimo de crecer cada da y entregar un buen servicio a sus clientes. Necesita el
apoyo para estructurar y mejorar su servicio, es por ello la razn por la cual
encomiendan ste proyecto.

3.4.1 Objetivo General


Desarrollar un proyecto de software para la empresa SOPRAF S.A. que registre la
mantencin y reparacin de vehculos, y permita la administracin de los recursos que
dispone la empresa.

3.4.2 Objetivos Especficos


1. Registrar repuestos y recursos utilizados en las mantenciones y reparaciones de
vehculos.
2. Debe permitir a SOPRAF S.A administrar las rdenes de trabajo respecto a los
servicios que se deben realizar a un vehculo y asignarlas a un mecnico.
3. Obtener estadsticas de los recursos utilizados en las mantenciones y
reparaciones de vehculos.
4. Registrar las compras de repuestos.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

11

Captulo III

3.4.3 Consideraciones

Se establece la entrega de un proyecto de software al final del perodo


establecido en la propuesta.

Toda entrega realizada ser acompaada con su respectiva documentacin.

Se capacitar a los usuarios que participarn en la herramienta por un perodo


determinado, siendo como fecha tope 15 das.

El Cliente es el encargado de proporcionar la informacin de cada usuario para


definir la estructura jerrquica, respecto a la seguridad de la nueva herramienta.

3.4.4 Respecto del Software

Contar con un registro actualizado de fallas y sus observaciones.

Contar con un registro del stock de repuestos y su descripcin.

Contar con un registro de rdenes de trabajo y el detalle del trabajo realizado.

Registrar entrada y salida de repuestos.

Generar informes anuales de repuestos, fallas, ordenes de trabajo y vehculos.

Crear rdenes de trabajo con fechas establecidas para un mantenimiento


Autnomo y Preventivo.

3.4.5 Supuestos

La Empresa cuenta con equipamiento capaz de soportar la Solucin.

La Empresa cuenta con una red de rea local para sus equipos e Internet.

La Empresa cuenta con una red elctrica.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

12

Captulo III

3.4.6 Limitaciones
Los siguientes tpicos no estn incluidos en ste proyecto:

Configuracin y/o Mantencin del equipamiento de la empresa.

Configuracin y/o Mantencin de la red de rea local e Internet.

Todo lo que est fuera del alcance.

3.4.7 Criterios de Aceptacin

Software AMRV con el 100% de sus requerimientos definidos.

Aprobacin completa por parte de las pruebas durante dos semanas, junto a la
entrega de los resultados de estas.

Documentacin necesaria para poder operar el Software.

Aceptacin y completo funcionamiento identificado y aprobado por parte de las


pruebas realizadas por el cliente.

El Software ser aceptado haciendo las pruebas en los equipos del cliente.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

13

CAPTULO IV
MATERIALES Y MTODOS

Captulo IV

4 Materiales y Mtodos
Para alcanzar los objetivos mencionados, el proyecto se ha desarrollado siguiendo las
buenas prcticas sealadas por el PMBOK 4ta Edicin, estandarizaciones de la IEEE,
Ingeniera en Software Un Enfoque Prctico por Roger S. Pressman, complementado
con los conocimientos adquiridos durante la carrera. Cabe destacar que todas las
actividades sealadas tanto por el PMBOK, IEEE y Pressman no fueron utilizadas dado
a que el proyecto y sus caractersticas no las necesitaban. Junto a esto, el modelo de
desarrollo utilizado ha sido el de cascada con retroalimentacin, el cual se escogi
puesto a que los requerimientos del cliente han sido establecidos claramente desde un
principio y fue difcil que cambiaran durante el proceso del proyecto, pero no exenta a
que estos pudiesen tener alguna modificacin en el caso de que el cliente lo requiera.
Podemos decir que un proyecto es un proceso que requiere una organizacin de etapas
las cuales estn constituidas por actividades, cada una de estas indica un esfuerzo en
horas hombre, las cuales en resumidas cuentas indican el tiempo estimado en que el
proyecto podr llevarse a cabo, lo que concluye en un producto final. La naturaleza de
un proyecto debe indicar por lo menos un inicio y final definidos, en donde ste ltimo
se obtiene cuando se logran los objetivos indicados entre el inicio y el fin, o bien, por el
abandono del proyecto al no poder lograr alguno de estos. Por lo tanto, el proyecto se
dividir en dos fases: Proceso (basado en el ciclo de vida del proyecto) y Producto
(basado en la construccin del software).

Figura 7 - Niveles Tpicos de Costo y Dotacin de Personal Durante el Ciclo de Vida del Proyecto
Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

15

Captulo IV

Proceso

4.1

Para llevar a cabo el proceso del proyecto, se seguirn las actividades definidas para
cada una de las etapas descritas en la Gua de los Fundamentos de la Direccin de
Proyectos (PMBOK, 4ta Edicin). Las etapas definidas son las siguientes:

Iniciacin

Planificacin

Ejecucin

Seguimiento y Control

Cierre

Figura 8 - Etapas Definidas en PMBOK

Junto a estas etapas, cabe recalcar que no es obligacin hacer uso de todas, ya que
slo depender de las caractersticas del proyecto. Un proyecto por muy similar que se
vea a otro siempre tendr diferencias.
Para dirigir el proceso del proyecto de software, fue necesario construir un Plan de
Proyecto el cual junta diferentes planes que se deben tener en cuenta para cada
actividad que constituye a cada etapa del proceso.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

16

Captulo IV

ste plan pudo ser construido bajo la estandarizacin IEEE 1058, que hace mencin al
Plan de Gestin del Proyecto de Software, mencin que est compuesta de los
siguientes planes:

4.2

Plan de Calidad

Plan de Trabajo

Plan de Gestin de Riesgos

Plan de Comunicaciones

Plan de Aceptacin del Proyecto

Plan de Gestin de la Configuracin

Plan de Resolucin de Controversias

Plan de Documentacin

Plan de Infraestructura

Plan de Recursos Humanos

Plan de Cierre del Proyecto

Plan de Calidad

Figura 9 - Plan de Calidad

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

17

Captulo IV

Dentro del plan de calidad, se deben definir componentes que estarn sujetos para
asegurar la calidad. Estos componentes pueden ser Documentos, Clases de Software,
Scripts de base de datos entre otros. Como indica la figura N 9, buscar alguna Norma
o Metodologa que permita el aseguramiento, en donde esto ltimo realiza y comprueba
la Norma o Metodologa encontrada. Segn lo anterior, se debe dar paso para planificar
el tiempo y los recursos que actuarn en el aseguramiento de calidad del componente
para luego realizar el desarrollo de la actividad.
Para la construccin del plan, se recurri a la gua PMBOK 4ta Edicin (Captulo 8
Gestin de la Calidad del Proyecto).

4.3

Plan de Trabajo

Figura 10 - Plan de Trabajo

Dentro del plan de trabajo, la primera etapa consiste en la definicin de las actividades
elaborando la Estructura de Desglose de Trabajo (EDT, WBS), estructura que servir
para poblar cada etapa dentro del proceso de gestin del proyecto con actividades a
realizar. Luego de definir las actividades, se debe establecer una secuencia en estas
para dar paso a la asignacin de los recursos correspondientes junto al tiempo
estimado de duracin, concluyendo con un cronograma basado en la informacin
obtenida anteriormente.
Para la construccin del plan, se recurri a la gua PMBOK 4ta Edicin (Captulo 6
Gestin del Tiempo), junto a la definicin de la IEEE 1058 Plan de Proyecto.
Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

18

Captulo IV

4.4

Plan de Gestin de Riesgos

Figura 11 - Plan de Gestin de Riesgos

Dentro de ste plan, la primera etapa consiste en la planificacin de la gestin de los


riesgos, la cual corresponde a la definicin de todas las etapas que se llevarn a cabo,
junto al cmo y cundo se harn.
Una vez realizada la planificacin, se procede a identificar los riesgos del proyecto. Al
tener los riesgos definidos, se deben realizar dos tipos de anlisis, por un lado
corresponde a un anlisis cualitativo que corresponde a la medicin del impacto,
probabilidad de ocurrencia, entre otros. Como tambin, la segunda parte que
corresponde al anlisis cuantitativo, el cual mide los efectos de los riesgos a los cuales
se les asigna una clasificacin numrica. Junto a esto, se realiza la planificacin
correspondiente a la respuesta segn el tipo de riesgo disparado, en donde se define la
reaccin que se debe tener al momento de que ocurra un evento de ste tipo.
Una vez realizado lo anterior, se pasa a la etapa de monitoreo y control de riesgos, en
donde se controla la evolucin de los distintos riesgos identificados.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

19

Captulo IV

Figura 12 - Plan de Gestin de Riesgos (2)

Cuando ocurre una eventualidad, se debe recurrir a la identificacin del riesgo


disparado en donde se debe revisar el impacto que ste genera en el proyecto, como
tambin, correr el plan de contingencia y realizar la mitigacin correspondiente. Una vez
detectado todo esto, se procede a realizar los cambios o acciones pertinentes como
una re-planificacin de las actividades desde el punto en donde se gener la
eventualidad.
Finalmente, monitorear y controlar el riesgo disparado para que no siga afectando ms
all el avance del proyecto.
Para la construccin del plan, se recurri a la gua PMBOK 4ta Edicin (Captulo 11
Gestin de los Riesgos del Proyecto).

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

20

Captulo IV

4.5

Plan de Comunicaciones

Figura 13 - Plan de Comunicacin

Dentro del plan de comunicacin, se realiza el proceso que consiste en identificar a


todas las personas relacionadas con el proyecto y documentar informacin relevante
relativa a sus intereses, participacin e impacto en el xito del mismo. Para planificar la
comunicacin y luego distribuir la informacin, se deben determinar los canales entre
los interesados. En la etapa siguiente, se trabaja en conjunto con los interesados para
lograr satisfacer sus necesidades y abordar cada problema conforme se presenten.
Finalmente, se recopila y distribuye la informacin respecto al desempeo, incluyendo
informes, mediciones y proyecciones.
Para la construccin del plan, se recurri a la gua PMBOK 4ta Edicin (Captulo 10
Gestin de las Comunicaciones del Proyecto).

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

21

Captulo IV

4.6

Plan de Aceptacin del Proyecto

Figura 14 - Plan de Aceptacin del Proyecto

Inicialmente, el cliente debe crear los criterios de aceptacin. Esto indica lo que
considera que debe tener el software respecto a las funcionalidades que su empresa
necesita y que fueron previamente declaradas en la especificacin de la solucin
propuesta.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

22

Captulo IV

Una vez creados los criterios, se procede a una revisin por parte del Jefe de Proyecto
para realizar una validacin de estos, en donde esta validacin puede no cumplir con lo
que el cliente realmente necesita, por lo que se puede proceder a realizar una reunin
para establecer cambios en los criterios y llegar a un acuerdo final.

Si los criterios son aceptados, se realiza la ejecucin de estos, los cuales debern ser
documentados por el cliente para luego entregrselos al Jefe de Proyecto, el cual los
registrar dentro de la matriz de pruebas. Una vez realizado el registro, se procede a
validar los resultados, si estos no son satisfactorios se realizarn los cambios y
correcciones necesarias para volver a realizar la ejecucin de las pruebas y estas
obtengan el resultado esperado tanto por parte del Cliente como del Jefe de Proyecto.
Si estos resultan como lo esperado, se procede a generar el acta de aprobacin para
dar paso a la entrega de los entregables comprometidos con el Cliente, y finalmente dar
por aprobado el producto obteniendo la firma del acta de aprobacin.

4.7

Plan de Gestin de la Configuracin

Figura 15 - Plan de Gestin de la Configuracin

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

23

Captulo IV

Como primera parte del proceso, se deben definir los objetivos del plan de
configuracin. Al tener estos claros, se definen los tems de la configuracin los cuales
corresponden a todos aquellos elementos entregables en el proyecto. La siguiente
etapa consiste en la definicin de roles para el correcto funcionamiento del plan de
configuracin, con el fin de mantener un control respecto a las responsabilidades que
existen frente a cada tem, para ms tarde si fuese necesario hacer uso del control de
cambios.(Figura N 16 Control de Cambios).
El proceso continua con la definicin de la herramienta SVN y del repositorio web para
tener un control de las versiones que se vayan generando.
Finalmente, se definen cules sern las lneas base que permitirn registrar y controlar
los cambios que se vayan efectuando a medida que se avanza con el proyecto, sin
impedir el avance que ste vaya teniendo en el caso que se necesitara realizar algn
cambio, el cual debe ser realizado a travs del procedimiento Control de Cambios.
Para la construccin del plan, se recurri a la gua Ingeniera del Software Un
Enfoque Prctico, Roger S. Pressman (Captulo 9 Gestin de la Configuracin del
Software).

Figura 16 - Control de Cambios

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

24

Captulo IV

4.8

Plan de Resolucin de Controversias

Figura 17 - Plan de Resolucin de Controversias

La primera etapa de ste plan, es identificar la controversia para luego poder analizar
las razones que la generaron, razones que pueden ser causadas comnmente por
ambigedad en la especificacin de los requerimientos. El siguiente paso consiste en
lograr un acuerdo con el cliente para poder seguir avanzando con el proyecto y no
quedar atrapado en alguna etapa, lo que permitir plantear posibles soluciones al
problema generado.
Cuando el acuerdo est listo, se debe registrar el cambio como aceptado para luego
desarrollar la solucin planteada y realizar el cambio.
Finalmente, el proceso concluye cuando se aprueba el cambio por ambas partes, lo que
permite seguir avanzando con el proyecto.
Para la construccin del plan, se recurri a los apuntes del Profesor Vicente Aranda
Chacn.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

25

Captulo IV

4.9

Plan de Documentacin

Figura 18 - Plan de Documentacin

Partiendo de una base dentro del plan de documentacin, primero se deben establecer
los requisitos de documentacin, esto significa que se da a conocer lo que se va a
documentar. Luego comienza el establecimiento de los documentos junto a la definicin
de las nomenclaturas que se deben generar dependiendo la etapa en que se encuentre
el proceso dentro del Modelo de Desarrollo de Software, para luego dar paso al
establecimiento de extensiones de los documentos.
Finalmente, planificar fechas de estimacin para la documentacin.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

26

Captulo IV

4.10 Plan de Infraestructura

Figura 19 - Plan de Infraestructura

Dentro del plan de infraestructura, primero se debe identificar las necesidades de


hardware para luego realizar una comparacin de la amplia gama tecnolgica que
exista y que satisfaga los requisitos. Luego de definir el hardware a utilizar, se procede
a definir la disponibilidad y estado del hardware el cual puede necesitar una mantencin
para poder obtener el rendimiento esperado, como tambin la configuracin necesaria
para hacerlo funcionar.
Por ltimo, establecer el software a ser utilizado, lo que permitir poder trabajar
correctamente.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

27

Captulo IV

4.11 Plan de Recursos Humanos

Figura 20 - Plan de Recursos Humanos

Dentro del proceso de plan de recursos humanos, el comienzo est definido por el
organigrama del proyecto dentro del cual se deben establecer las descripciones de los
puestos, para luego poder adquirir al equipo de trabajo.
Una vez situado en la etapa de bsqueda de personal con disponibilidad, se realiza la
asignacin de estos al proyecto dependiendo de las caractersticas que ste tenga, de
lo contrario, se ejecutar el plan de contingencia el cual buscar a un nuevo recurso
humano para poder llenar el puesto vaco. Posteriormente, se realizar la
calendarizacin de los recursos obtenidos durante el proceso del proyecto, en donde se
dar paso para poder capacitar al personal adquirido y luego obtener una evaluacin de
estos segn su desempeo.
Para la construccin del plan, se recurri a la gua PMBOK 4ta Edicin (Captulo 9
Gestin de los Recursos Humanos del Proyecto).

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

28

Captulo IV

4.12 Plan de Cierre del Proyecto

Figura 21 - Plan de Cierre del Proyecto

Dentro de ste plan, el inicio est marcado por la verificacin del cierre de las fases
anteriores respecto al modelo de desarrollo, junto a esto, verificar que el plan de
proyecto est completamente culminado, lo cual podr asegurar que se ha realizado
todo lo planificado dentro del proyecto. Si algn plan no se encuentra finalizado, ste se
deber revisar para luego ser completado y volver a realizar la verificacin por el Plan
de Proyecto. Posteriormente, se debe ejecutar el plan de aceptacin del proyecto. Si
sale satisfactorio, documentar las lecciones aprendidas dentro de todo el proceso del
proyecto.
Finalmente, actualizar los documentos y procesos realizados si fuese necesario, con el
fin de responder de mejor manera ante un nuevo proyecto, reduciendo la cantidad de
errores al registrar la experiencia vivida en el proyecto, el cual se dar por finalizado
generando un informe de cierre.
Para la construccin del plan, se recurri a la gua PMBOK 4ta Edicin (Captulo 3
Proceso de la Direccin de Proyectos para un Proyecto).

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

29

Captulo IV

4.13 Producto
El producto se enfoca principalmente en el qu se quiere construir, en otras palabras, el
producto final para el cliente al momento de cerrar el proyecto en forma satisfactoria es
en ste caso una herramienta informtica que permitir apoyar las funcionalidades de
su empresa. Respecto al cmo lograr el producto final, se debe realizar un trabajo
basado en un proceso derivado en etapas. Para plantear las etapas que se deben
recorrer, se elige un modelo de desarrollo de producto, en ste caso, el modelo en
cascada (lineal secuencial) con retroalimentacin, el cual permitir volver a alguna
etapa anterior en el caso de que exista la necesidad de realizar ajustes.
Las etapas definidas por el modelo para el proyecto son las siguientes:

Figura 22 Modelo en Cascada con Retroalimentacin

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

30

Captulo IV

4.14 Anlisis
Esta etapa del producto, se centra en la obtencin de los requerimientos los cuales
fueron formalizados en el documento de especificacin de requerimientos bajo la
estandarizacin de la IEEE 830. Para la obtencin de los requerimientos, se recurri al
uso de la Ingeniera de requerimientos, la cual entrega los correctos pasos para lograr
obtener los requerimientos correctamente.
Las etapas realizadas fueron las siguientes:

Figura 23 - Ingeniera de Requerimientos

Dentro de la etapa de Elicitacin y Anlisis, se buscaron comprender las necesidades


del cliente. Esta bsqueda se manifest por un lado analizando el documento de
licitacin elaborado por el Ministerio de Transportes, junto a los principales defectos que
ya haban sido considerados importantes. Para la comprensin completa de los
requerimientos, se realizaron reuniones con el cliente sumando un total de tres, en
donde adems se trabaj en conjunto generando ideas y confeccionando mapas
mentales para poder aclarar an ms las necesidades.
Al terminar la elaboracin de los mapas y las reuniones, se determin la integracin de
un nuevo actor para colaborar en esta solucin.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

31

Captulo IV

Dentro de la etapa de Especificacin de requerimientos y Validacin, se utiliz la


estandarizacin sealada por la IEEE 830, para poder esclarecer los requerimientos
obtenidos anteriormente validando que las funciones concuerden con lo que se
identific en el mapa mental.
Todo lo mencionado anteriormente est bajo una estrategia de verificacin en donde se
busc la coherencia y cohesin a travs de una traza realizada desde el principio hasta
el fin de los requerimientos analizados.

4.15 Diseo
Esta etapa se enfoca en todo lo que est vinculado a la arquitectura del software que se
quiere construir, junto al cmo se ver una vez finalizado. Para la documentacin de
esta etapa se utiliz la estandarizacin sealada por la IEEE 1471 complementado con
la estandarizacin UML 2.0 y el desarrollo de las distintas vistas de Kruchten 4+1, lo
que permiti la realizacin de los siguientes diagramas:

Escenario: Asociado a los Casos de Uso, que permite describir la funcionalidad


propuesta.

Procesos: Asociado al Diagrama de Secuencia, que permite mostrar la


interaccin entre los usuarios, las pantallas y las instancias de los objetos en el
sistema.

Lgica: Asociado al Diagrama de Clases, en donde se encuentra el ncleo del


desarrollo y del diseo orientados a objetos.

Desarrollo: Asociado al Diagrama de Componentes, el cual ilustra las piezas del


software, controladores involucrados, entre otros.

Fsica: Asociado al Diagrama de Despliegue, el cual provee un modelo detallado


de la forma en la que los componentes se desplegarn a lo largo de la
infraestructura propuesta.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

32

Captulo IV

Adems, se define el lenguaje que se utilizar para la programacin del software, como
tambin para la base de datos.

4.16 Construccin
Dentro de esta etapa, se concentra la mayor parte del esfuerzo para la construccin del
software segn lo diseado en la etapa anterior, junto al entregable comprometido para
el cliente el cual consisti en el Manual de Usuario.
Para llevar a cabo la construccin, se decidi establecer una reunin con el profesor
gua para obtener asesora y comenzar en el mes de Enero. Esto ocurri debido a que
el tamao del software super lo esperado para el trabajo de una persona, lo que
implic utilizar ms tiempo de lo considerado.

4.17 Pruebas
Esta etapa se enfoca en todo lo que est vinculado a las pruebas de software, tanto por
parte del Jefe de Proyecto, como por parte del Cliente. Documentado bajo la
estandarizacin sealada por la IEEE 829, se puede resumir de la siguiente manera:

Figura 24 - Plan de Pruebas


Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

33

Captulo IV

El plan consisti en definir el alcance de las pruebas que se van a realizar, las cuales se
categorizaron segn su tipo y etapa, lo que permiti establecer la estrategia para
mantener una coherencia entre un tipo de prueba y otra. Luego, se procede a
categorizar las pruebas segn el resultado obtenido, permitiendo registrar estos
resultados en una Matriz de Pruebas al momento de ejecutar el plan. Para finalizar, se
deben especificar los recursos para la realizacin de las pruebas en donde se defini un
calendario, se identificaron los riesgos y se determin a los responsables para cada una
de estas.

4.18 Implantacin
Al llegar a esta etapa, est todo el proceso del proyecto casi terminado ya que es la
ltima fase del modelo de cascada, dentro de la cual se verific e instal en los equipos
del cliente la solucin propuesta bajo su correcta configuracin especificada en la etapa
de diseo. Por lo tanto, se inicia la actividad de adiestramiento para poder capacitar al
personal involucrado y estos logren manejar la herramienta.

4.19 Proceso vs Producto


Dado lo mencionado anteriormente en el punto 3.1, a lo largo del proceso del proyecto
de software la gestin estuvo presente en la ejecucin del proyecto. Desde el punto
3.13, se describe el modelo de desarrollo de software para poder lograr el producto
final.
Cabe destacar que durante todo el proceso, se realiz un seguimiento de la
planificacin inicial junto a los riesgos ante las posibles eventualidades que se haban
identificado y pudiesen ser disparadas.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

34

CAPTULO V
RESULTADOS Y DISCUSIN

Captulo V

5 Resultados y Discusin
Como resultado obtenido respecto a la ejecucin de los planes anteriores, se obtuvo lo
siguiente:

5.1

Resultados Plan de Calidad

Para asegurar la calidad de cada documento elaborado dentro de cada etapa del ciclo
de vida del proyecto, la base se sita en la estandarizacin utilizada por las IEEE 1058,
1471, 830, 829. Al utilizar estas estandarizaciones, la calidad puede asegurarse al
momento de realizar la construccin, ya que tambin pas por un proceso de validacin
estipulado dentro de estos documentos. Por otro lado, la ejecucin y definicin de
criterios de aceptacin previa marcha blanca, permiti poder realizar pruebas
obteniendo un producto correcto, sumando de esta manera puntos al aseguramiento de
la calidad. Por lo tanto, al haber hecho esto se est asegurando la calidad del producto
construido.

5.2

Resultados Plan de Trabajo

Al tener una definicin clara de las actividades, secuenciadas en un desglose de trabajo


y distribuidas por las etapas dentro del ciclo de vida del proyecto, se obtuvo un
cronograma final. Se defini en un comienzo la estimacin del tiempo (HH) de trabajo
para cada etapa, obteniendo los siguientes resultados utilizando Puntos por Caso de
Uso:

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

36

Captulo V
Etapa de Cascada
Anlisis
Diseo
Codificacin
Pruebas
Implantacin
Total Esfuerzo

Tiempo (HH)
83
167
335
125
125
835

Tabla 1 Estimacin Proyecto

A continuacin se presenta el cronograma asociado a la carta Gantt:

Figura 25 Cronograma Proyecto

Complementando al cronograma, se adjunta la carta Gantt final que muestra la cantidad


de HH (Horas Hombre) de la realizacin del proyecto que fueron 803HH Reales, versus
las 835HH estimadas.
Junto a esto, se muestran las actividades que contiene cada etapa:

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

37

Captulo V

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

38

Captulo V

Figura 26 Carta Gantt

5.3

Resultados Plan de Gestin de Riesgos

Se lograron identificar un total de 6 riesgos, los cuales se analizaron cualitativamente y


estn representados en la siguiente tabla:

ID
Riesgo
R01
R02
R03
R04
R05
R06

Nombre del Riesgo


Resistencia al cambio
Falta de motivacin por parte de
SOPRAF S.A.
Falta de compromiso o disponibilidad
por parte de SOPRAF S.A.
Problemas con avance del producto
No disponer de los recursos fsicos
especificados
Cambio en los requerimientos

Probabilidad
de ocurrencia

Impacto
(consecuencia)

Nivel de
Riesgo

Casi Cierto
Poco Probable

Muy Alto
Medio

Alto
Significativo

Poco Probable

Muy Alto

Significativo

Poco Probable
Poco Probable

Extremo
Extremo

Alto
Alto

Poco Probable

Extremo

Alto

Tabla 2 Riesgos Identificados

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

39

Captulo V

No se realiz un anlisis cuantitativo, dado a las caractersticas del proyecto y por la


razn de encontrar que no es algo indispensable tener ste tipo de evaluacin dentro
de los riesgos.
Con respecto a la mitigacin y contingencia, segn el riesgo que sea gatillado se
muestra a continuacin la siguiente tabla que explica la mitigacin que se debe ejecutar
y el plan de contingencia que se debe llevar a cabo:

ID
Riesgo

Responsable
de Mitigarlo

R01

Jefe de Proyecto

R02

Jefe de Proyecto

R03

Jefe de Proyecto

R04

Jefe de Proyecto

R05

Jefe de Proyecto

Mitigacin
1. Demostrar
las
ventajas
y
beneficios que se lograrn con el
cambio.
2. Demostrar que todos pueden
manejar un computador y que
ser fcil lograr el manejo del
software.
1. Mostrar avances del proyecto.
2. Buscar ejemplos de empresas
que han surgido y destacado
gracias a la TI.
1. Establecer reuniones y mantener
una constante comunicacin con
el cliente.
2. Integrarlos al trabajo, hacindoles
saber que su opinin es
importante para que el proyecto
salga satisfactorio.
1. Controlar y verificar con la carta
Gantt en la etapa del proyecto el
estado de avance de ste.
2. Buscar el respaldo ms reciente.
3. Designar ms horas de trabajo a
la actividad.
4. Re-Planificar desde la actividad
afectada en
adelante si es
necesario.
1. Una semana antes de comenzar
la etapa de pruebas, realizar un
chequeo a los computadores. En
el caso que requieran un
formateo, realizarlo para no tener
problemas.

Plan de Contingencia
Realizar una charla
al directorio,
especificando las ventajas y beneficios que
la empresa adquiere haciendo uso de la
TI. Ofrecer ayuda y disponibilidad para
atender cualquier duda que el cliente
presente.
Motivar al directorio a travs de charlas
didcticas las cuales indiquen el avance
que el proyecto est teniendo.
No se seguir con el proyecto por falta de
compromiso, desinters y poco feedback
por parte del cliente.

Pedir asesora a los profesores guas.


Pedir ms tiempo en la entrega de
proyecto final si fuese necesario.

En caso de presentar problemas para


contar con ellos, conseguir un equipo de la
Universidad para realizar las pruebas del
software.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

40

Captulo V
ID
Riesgo
R06

Responsable
de Mitigarlo
Jefe de Proyecto

Mitigacin
1. Formalizar los requerimientos con
actas.
2. Re Planificar e informar respecto
a las nuevas fechas de entrega.

Plan de Contingencia
Continuar
trabajando
con
requerimientos que no han cambiado.

Tabla 3 Mitigacin y Contingencia de los Riesgos

El seguimiento y control al riesgo, se realiz a travs de las actividades Control y


Evaluacin definidas en la carta Gantt dentro de cada etapa del ciclo de vida del
proyecto.
De los 6 riesgos identificados solo se manifestaron R04 y R06, por lo tanto se tuvo que
re planificar desde las actividades afectadas en adelante, perdiendo una semana de
trabajo lo cual no perjudic al proyecto en su entrega final debido a que se contaba con
el tiempo necesario y se trabajaron ms horas diarias.

Resultados Plan de Comunicacin

5.4

Los interesados del proyecto son:

Nelson Paillalef (Cliente)

Ernesto Morales (Cliente)

Cristian Vsquez Lean (Jefe de Proyecto)

Con respecto a los canales de comunicacin dentro del proyecto, se establecieron


reuniones una vez cada semana desde la etapa de codificacin. Desde la semana de
pruebas en adelante, dos veces por semana, destacando que estas fueron de carcter
presencial en la empresa del cliente.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

41

los

Captulo V

Ante cualquier situacin puntual, tambin se coordinaron reuniones por telfono para
establecer juntas en una fecha no planificada.

5.5

Resultados Plan de Aceptacin del Proyecto

Los criterios de aceptacin definidos son los siguientes:


1. Organizar el trabajo diario y semanal.
2. Crear registros respecto al trabajo realizado en las mantenciones y reparaciones.
3. Crear registros especficos de vehculos reparados y mantenidos.
4. Establecer registros respecto al stock de repuestos. Adems, organizar la
informacin que se conoce respecto a los existentes.
5. Emitir rdenes de trabajo respecto a los servicios que se deben realizar a un
vehculo y asignarlas a un mecnico.
6. Mantener un registro de compras de repuestos junto con el ingreso del respectivo
proveedor y asignar un cdigo de barras a cada repuesto adquirido.
7. Aumentar el conocimiento y distribucin de repuestos en un 90%.
8. Registrar el retiro de repuestos por parte del Encargado de Bodega.
9. Manual de Usuario y Capacitacin de personal involucrado.

Las funcionalidades del software, se probarn en los equipos del cliente destinados
para las pruebas de aceptacin. Los cuales presentan las siguientes caractersticas:

Equipo Administrador:
Procesador: Intel Core 2 Duo 3.2 GHz 64bits.
Memoria RAM: 2 GB DDR3.
Memoria en Disco Duro: 500 Gb SATA.
Tarjeta de Red: 10/100/1000.
Monitor LED 21 LG.
Tabla 4 Equipo Administrador

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

42

Captulo V

Equipo Encargado de Bodega


Procesador: Intel Celeron a 2.4 GHz 32bits.
Memoria RAM: 1 GB DDR.
Memoria en Disco Duro: 120 Gb ATA.
Tarjeta de Red: 10/100/1000.
Monitor AoC 17.
Lector Cdigo de Barras Manhattan.
Tabla 5 Equipo Encargado Bodega

El resultado de los criterios de aceptacin fue de un 100% al momento de haberlos


realizado, los cuales fueron documentados en una matriz de pruebas.
Posteriormente, se firm el acta de aceptacin.

5.6

Resultados Gestin de la Configuracin

El objetivo de ste plan, fue definir y mantener la integridad del cdigo y los
documentos que se generaron a lo largo del ciclo de vida del proyecto.
Los tems de configuracin definidos fueron los siguientes:
N tem
IC01
IC02
IC03
IC04
IC05
IC06
IC07
IC08
IC09
IC10
IC11
IC12
IC13
IC14

tem de Configuracin
Propuesta de Colaboracin Profesional - Software AMRV
Especificacin de Requerimientos IEEE 830
Anlisis de Riesgos
Control de Cambios
Resolucin de Controversias
Minuta de Reunin Cambio en los Requerimientos
IEEE 1471 Arquitectura de Software Kruchten 4+1
IEEE 829 Plan de Pruebas
IEEE 828 Gestin de la Configuracin
Software
Matriz de Pruebas
Manual de Usuario
Informe de Cierre (Experiencias Adquiridas)
Carta Gantt
Tabla 6 - tems de Configuracin

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

43

Captulo V

Nombre del Rol

Persona Asignada

Responsable de
Elementos de configuracin,
Gestor de la configuracin y Cristian Vsquez L
Gestor de Cambios

Responsabilidades
Entregables, cdigo fuente del software y
base de datos (fundamentalmente ste
ltimo).
Evaluar el impacto y riesgo de los
cambios.

Tabla 7 Rol Gestin de la Configuracin

Cada cambio en el versionamiento de un tem de Configuracin (IC) antes sealado,


deber quedar especificado en el documento Plan de Gestin de la Configuracin, en la
tabla realizada para ste efecto.
Es aqu donde se registran todos los cambios realizados a los tems de configuracin,
as como tambin los cambios no aprobados y los que se estn realizando hasta la
fecha.
Para poder realizar todo lo mencionado anteriormente, se tuvo que llevar a cabo el
siguiente proceso:

Figura 27 Cambio tem de Configuracin

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

44

Captulo V

El repositorio en Internet donde se maneja la informacin junto a los tems de


configuracin mencionados es GITHUB, utilizando el software GIT para controlar las
versiones.
A continuacin, la direccin del repositorio en internet:
https://github.com/CriVasquez/SWAMRV

Junto a esto, las lneas base que se crearon en la rama Master llevan la siguiente
definicin:

Nombre
Recopilacin de
Documentos (LB1)
Software (LB2)

Software (LB3)

Software (LB4)

Software (LB5)
Software (LB6)
Software (LB7)

Recopilacin
Documentos (LB8)

Cuando se define
Cuando comienza la construccin
del cdigo.
Cuando se construye y se realizan las
pruebas Unitarias para el Mdulo
Administracin
Cuando se construye y se realizan las
pruebas Unitarias. Mdulo Informes e
Indicadores
Cuando se construyen, se integran y se
prueban los Retiros de Repuesto,
Mdulo Retiro de Repuestos
Cuando se construye y se prueba el
Mdulo Ingreso Compras
Se integran los mdulos y se realizan
las pruebas de integracin.
Se completan las pruebas restantes del
software (Arquitectura Cliente-Servidor,
Sistema y Aceptacin). Se obtiene la
versin final del Software.
Se crean y/o actualizan los ltimos
tems de configuracin del proyecto
(IC10, IC11, IC12). Obteniendo la
versin final de todos los documentos.

tems de
Configuracin
IC1, IC2, IC3, IC4,
IC5, IC6, IC7, IC8
IC9

IC9

IC9

IC9
IC9
IC9

IC10, IC11, IC12

Tabla 8 Lneas Base

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

45

Captulo V

5.7

Resultados Plan de Resolucin de Controversias

Dentro del proyecto no se desarroll ningn tipo de controversia por parte del cliente, de
todas maneras en el caso de que alguna se hubiera manifestado, esta debe quedar
documentada a travs de una minuta de reunin firmada por ambas partes, en donde
se especifica la solucin respecto al problema acontecido.

5.8

Resultados Plan de Documentacin

Los documentos fueron los siguientes:

1. Project Charter.
2. IEEE 1058 - Plan de Proyecto.
3. IEEE 1471 - Arquitectura de software Kruchten 4+1.
4. IEEE 830 - Especificacin de Requerimientos.
5. IEEE 829 - Plan de pruebas.
6. Plan de Gestin de la configuracin.
7. Anlisis de riesgos.
8. Gestin de cambio.
9. Resolucin de controversias.
10. Minutas de reunin.
11. Estimacin Proyecto.
12. Matriz de pruebas.
13. Plan de Aceptacin.
14. Software AMRV.
15. Manual de Usuario.
16. Informe de cierre.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

46

Captulo V

5.9

Resultados Plan de Infraestructura

El hardware definido para poder realizar el proyecto se bas en dos equipos con las
siguientes caractersticas:

Nombre
Procesador
Memoria RAM
Disco Duro
SO

LENOVO 3000 N200


Intel Celeron 550 2.0 GHz
1 GB DDR
120 GB
Windows XP Professional SP3
Tabla 9 Hardware Infraestructura

Nombre
Procesador
Memoria RAM
Disco Duro
SO

LENOVO G470
Intel Core i5 2.5ghz
8.0 GB DDR3
500 GB
Windows 7 Ultimate
Tabla 10 Hardware Infraestructura (2)

Con respecto a la lista del software utilizado para realizar el proyecto, se detalla a
continuacin:

1. Microsoft Visio 2010.


2. SmartDraw 2010.
3. Mindjet MindManager 8.
4. Office 2010.
5. NetBeans IDE 7.0.
6. Oracle SQL Developer.
7. Oracle 10g Express.
Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

47

Captulo V

8. Toad For Oracle.


9. Microsoft Project 2010.
10. Enterprise Architecture 7.5.
11. GIT Versin 0.16.
12. Power Designer 12.

5.10 Resultado Plan de Recursos Humanos


El organigrama del proyecto se ve reflejado en el siguiente diagrama:

Figura 28 Organigrama del Proyecto

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

48

Captulo V

La lnea que une al Jefe de Proyecto con el Director general, indica que estas dos
personas fueron las que se comunicaron durante el proyecto. A continuacin, se
especifican los roles de cada uno de los integrantes del grupo de trabajo:

Rol
Jefe de
Proyecto

Arquitecto
Solucin

Secretara

Desarrollador
JEE - PL/SQL

Tester

Responsabilidades
Encargado llevar a cabo el proyecto, supervisar y mantener
el orden del trabajo que se ejercer en SOPRAF S.A. con
el fin de cumplir con los objetivos y expectativas del cliente.
Facilita la cohesin del equipo.
Encargado de facilitar informacin al equipo de trabajo con
respecto a la empresa con la cual se est trabajando.
Es el encargado de disear la solucin del problema
expuesto en SOPRAF S.A., con el fin de entregar al equipo
de trabajo soporte tcnico respecto al trabajo a realizar.
Disea la arquitectura de la Base de Datos.
Departamento encargado de mantener las minutas de
reunin al da, como tambin de los procesos de control de
cambio, actas de revisin, planes, etc.
Encargado de desarrollar la codificacin de mdulos del
proyecto a travs del lenguaje de programacin orientado a
objetos Java. Adems, disear los manuales tcnicos para
el usuario y aportar en las capacitaciones para la empresa.
Encargado del desarrollo de codificacin de base de datos,
apoyar la codificacin de las interfaces y brindar apoyo
para un mejor rendimiento al momento de realizar las
operaciones de procesos, complementando trabajo con el
desarrollo de JEE.
Define criterios de aceptacin para los resultados de la
integracin y realizacin de pruebas, procurando por sobre
todas las cosas que se cumpla con lo que el cliente
requiere y espera de manera eficiente.
Tabla 11 Roles del Equipo del Proyecto

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

49

Captulo V

En la siguiente tabla se especifican los roles con relevancia para el proyecto de


software por parte del cliente:

Rol
Gerente General

Director

Responsabilidad
Representante legal de la empresa, como tambin, jefe del
directorio de esta.
Conocer todo los movimientos dentro de los cuales se
desenvuelve la empresa, y de los nuevos proyectos que se lleven a
cabo.
Encargado de asistir a los diferentes debates, reuniones, etc. Es
la cara visible de SOPRAF S.A., desempeando un rol de Sponsor
para establecer comunicacin con el Jefe de Proyecto para
coordinar reuniones.
Tabla 12 Roles por parte del Cliente

Con respecto a la frecuencia y disponibilidad de comunicacin y establecimiento de


reuniones con el cliente, cabe destacar que no se produjeron mayores inconvenientes
debido a que desde un principio se lograron planificar y coordinar. Por lo tanto, no hubo
necesidad de aplicar el Plan de Contingencia asociado al Riesgo: Falta de compromiso
o disponibilidad por parte de SOPRAF S.A. (Ver Tabla N 2 Riesgos Identificados).

5.11 Resultados Plan de Cierre del Proyecto


Para la verificacin del cierre de cada etapa del ciclo de vida del proyecto, se presenta
la siguiente tabla que muestra la etapa y la evidencia que esta tiene, e indica que el
cierre est completo:

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

50

Captulo V

Etapa del Proyecto


Anlisis
Diseo
Codificacin
Pruebas
Implantacin
Plan de Proyecto

Evidencia
IEEE 830: Especificacin de Requerimientos.
IEEE 1471: Arquitectura de software
Software y Base de Datos
Matriz de Pruebas
Acta de Aceptacin del Proyecto
Informe de Cierre del Proyecto

Cierre
Realizado?
SI
SI
SI
SI
SI
SI

Tabla 13 Cierre Etapas Ciclo Vida Proyecto

5.12 Resultados del Producto


De acuerdo al ciclo de vida del producto, se presentan a continuacin los resultados de
cada etapa:

5.12.1 Resultados Anlisis


Utilizando la tcnica de Ingeniera de Requerimientos, se obtuvo lo siguiente:

Elicitacin y Anlisis de Requerimientos Se realizaron en total 3 reuniones con el


cliente, en la cual fueron documentados los acuerdos realizados junto al alcance que el
proyecto tendra ante un acta firmada por el Jefe de Proyecto y el Cliente.

Especificacin de Requerimientos Como formato, se utiliz la estandarizacin


IEEE 830.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

51

Captulo V

Validar y Evaluar Requerimientos Se lograron establecer los requerimientos


principales gracias al apoyo incondicional que se tuvo con el cliente, el cual colabor
para filtrar la determinacin de los objetivos para llevar a cabo el proyecto de software.
Junto a esto, una vez que la determinacin de los requerimientos fue clara, se firm un
acta de aceptacin, validando de esta manera que el cliente est conforme con lo que
se ve reflejado en los requerimientos.

Verificacin de requerimientos La primera parte, consisti en volver a revisar los


requerimientos a travs de una traza y compararlos con los mapas de ideas vs
problemas confeccionados, para luego llegar a una segunda parte del trazado al
relacionarlos con el Diagrama de Ishikawa, en donde no se encontraron inconsistencias
con respecto a los requerimientos establecidos.

Al utilizar esta trazabilidad, se pudo verificar que el producto que se va a construir es el


correcto.
A continuacin, se muestran los requerimientos del software que se ha construido:

Nombre :
Requisito :
Descripcin :

Proceso :
Entrada :
Salida

Mdulo Ingreso
El software deber tener un mdulo de autentificacin de
usuarios.
El software deber solicitar al usuario Rut, Contrasea y Tipo de
Cuenta para poder ingresar, de lo contrario no se podr ejecutar
ninguna accin dentro del software.
El usuario tendr la facultad de utilizar los diferentes mdulos del
software dependiendo el rol que cumpla.
Rut usuario y Contrasea.
Visualizacin de mdulos segn rol de usuario.
Tabla 14 Requerimiento Mdulo Ingreso

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

52

Captulo V

Nombre :
Requisito :

Descripcin :

Proceso :
Entrada :
Salida

Mdulo Administracin
Se compondr de los siguientes mantenedores:
1. Mantenedor Repuesto
2. Mantenedor Vehculo
3. Mantenedor Personal
4. Mantenedor Fallas
5. Mantenedor Proveedor
6. Mantenedor Servicios
Los cuales permitirn las siguientes funcionalidades:
Crear
Borrar
Modificar
Buscar
Permitir realizar operaciones con los sub mdulos del sistema
para poder trabajar con: vehculos, proveedores, fallas,
repuestos, servicios y personal.
El usuario Administrador tendr la facultad de utilizar estos
mantenedores una vez autentificado en el mdulo ingreso.
Visualizacin ventana principal.
Visualizacin y seleccin de sub mdulos.
Tabla 15 Requerimiento Mdulo de Administracin

Nombre :
Requisito :

Descripcin :

Proceso :
Entrada :
Salida

Mdulo Informes e Indicadores


Debern existir datos en la base de datos respecto a:
Vehculos
Repuestos
Ordenes de trabajo
Fallas
Permitir obtener informacin utilizando los datos de la empresa,
especficamente de repuestos, fallas, servicios, vehculos,
personal, compras.
El administrador ser el encargado de seleccionar la opcin
respecto a la informacin que desea obtener.
Datos de repuestos, fallas, servicios, vehculos, personal,
compras.
Creacin de informe formato PDF.
Tabla 16 Mdulo Informes e Indicadores

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

53

Captulo V

Nombre :
Requisito :

Descripcin :
Proceso :
Entrada :
Salida

Mdulo Compras
Permitir las siguientes funcionalidades:
Ingresar
Borrar
Modificar
Buscar
Mdulo que permitir ingresar las compras de repuestos junto al
proveedor y el detalle.
El Administrador ser el encargado de ingresar las facturas de las
compras de repuestos realizadas.
Factura con el detalle de la compra.
Ingreso de los datos de la compra a la base de datos.
Tabla 17 Mdulo Compras

Nombre :
Requisito :

Descripcin :
Proceso :

Entrada :
Salida

Mdulo Retiro Repuestos


Requiere de la existencia de repuestos y stock.
Permitir las siguientes funcionalidades:
Retirar
Devolver
Mdulo en el cual el encargado de bodega tendr la facultad para
poder buscar, retirar y devolver repuestos.
Se buscar el repuesto requerido en la bodega y posteriormente se
identificar con el lector de cdigos de barras para poder realizar el
retiro. El mismo procedimiento de identificacin funciona para la
devolucin.
Bsqueda o devolucin de repuestos.
Actualizacin de Stock en la base de datos.
Tabla 18 Mdulo Retiro Repuestos

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

54

Captulo V

Nombre :
Requisito :

Descripcin :

Proceso :
Entrada :
Salida

Mdulo Orden de Trabajo


Requerir datos ingresados por el resto de los mdulos para poder
operar.
Permitir las siguientes funcionalidades:
Ingreso
Modificacin
Bsqueda
Eliminacin
Adems, contar con la agregacin de servicios dependiendo del
tipo de trabajo que se necesite.
Mdulo principal del software en donde se manejarn los datos
ingresados por los otros mdulos para poder registrar rdenes de
trabajo.
El administrador ser el encargado de designar las rdenes de
trabajo, como tambin del mecnico y vehculo.
Definicin orden de trabajo.
Orden de trabajo formato PDF.
Tabla 19 Mdulo Orden de Trabajo

5.12.2 Resultados Diseo


Al haber seleccionado las vistas de Kruchten 4+1, se utilizaron los siguientes
diagramas:

Vistas
Escenarios
Procesos
Lgica
Desarrollo
Fsica

UML
Casos de Uso
Secuencia
Clases
Componentes
Despliegue
Tabla 20 Vistas de Kruchten 4+1

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

55

Captulo V

A continuacin, se muestra la vista correspondiente a los escenarios, utilizando Casos


de Uso separados por diferentes niveles, desde una vista general hasta una ms
especfica:

Figura 29 Diagrama Caso de Uso General

Figura 30 Caso de Uso Mdulo Retiro Repuestos

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

56

Captulo V

Figura 31 Caso de Uso Mdulo Orden de Trabajo

Figura 32 Caso de Uso Mdulo Informes

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

57

Captulo V

Figura 33 Caso de Uso Mdulo Compras

Por otro lado, solo se mostrarn tres de los diagramas de secuencia ms


representativos correspondientes a la vista de procesos, con el objetivo de demostrar la
interaccin que existe entre las funcionalidades antes sealadas:

Figura 34 Diagrama de Secuencia Registrar Falla en Orden de Trabajo

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

58

Captulo V

Figura 35 Diagrama de Secuencia Retiro de Repuesto

Figura 36 - Diagrama de Secuencia Registrar Orden de Trabajo

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

59

Captulo V

La lgica aplicada se basa en la orientacin a objetos, la cual se puede encontrar en


diferentes lenguajes, pero se decidi ocupar Java. Con respecto a la base de datos, se
utiliz Oracle 11g Express Edition.
Con respecto al diagrama de Clases diseado, se obtuvo lo siguiente:

Figura 37 Diagrama de Clases

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

60

Captulo V

La vista de desarrollo, que se enfoca en la organizacin de los mdulos del software en


el entorno de desarrollo, se ve reflejada en el diagrama de componentes presentado a
continuacin:

Figura 38 Diagrama de Componentes

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

61

Captulo V

Por otro lado, la vista fsica hace referencia a la distribucin de los componentes fsicos
en el ambiente de produccin, haciendo uso del diagrama de despliegue:

Figura 39 Diagrama de Despliegue

A travs de Kruchten 4+1, se ha logrado representar la arquitectura que el Software


AMRV necesitar para ser codificado, permitiendo hacer uso de todos los
requerimientos funcionales que fueron otorgados por el documento IEEE 830.
El uso de los diferentes diagramas UML, permitieron lograr un mayor entendimiento
respecto a las distintas capas, clases, objetos, funcionalidades y componentes del
software. A su vez, identificar las piezas de hardware que participaran en la
implantacin del proyecto, obteniendo una visin ms clara de lo que se va a entregar
como producto final. Entendiendo finalmente la coherencia y cohesin existente entre
cada diagrama de Kruchten 4+1 y el objetivo de cada uno de estos.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

62

Captulo V

5.12.3 Resultados Construccin


Dentro de esta etapa, como resultado se obtiene al software diseado en la etapa
anterior.
Con respecto a la programacin, cabe destacar la gran utilidad y claridad que se obtuvo
gracias a los requerimientos identificados. Esto signific un ahorro del tiempo, lo que
permiti poder reparar los errores que pudiesen ocurrir con el avance del proyecto, y a
su vez, ganar ms tiempo para poder ejecutar una mayor cantidad de pruebas.
Una de las grandes ventajas al haber ganado ste tiempo, fue poder contrarrestar de
manera correcta el disparo del riesgo identificado R04 Problemas con avance del
producto lo que permiti poder re planificar las actividades y no retrasar la entrega final
del proyecto de software.
A continuacin, se presentan algunas imgenes correspondientes al software:

Figura 40 - Software AMRV Mdulo Ingreso

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

63

Captulo V

Figura 41 - Software AMRV Ventana Principal

Figura 42 Software AMRV Mdulo Orden de Trabajo

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

64

Captulo V

5.12.4 Resultados Pruebas


Las pruebas que se realizaron fueron las siguientes:

Tipos de Pruebas
Unitarias

Integracin
Arquitectura
Cliente - Servidor
Sistema
Aceptacin

Elementos que se ven afectados


Cdigo perteneciente al Mdulo Administracin,
Ingreso,
Informes, Ingreso de compras y Retiro
repuestos.
Todos los mdulos mencionados funcionando
correctamente juntos.
Base de datos, transacciones y comunicacin en la red.
Informe Especificacin de Requerimientos (IEEE 830),
Informe de Diseo (IEEE 1471) y Software.
Software
Tabla 21 Tipos de Pruebas

Se realizaron pruebas unitarias, a medida que se fue obteniendo un pequeo avance


respecto a los diferentes mdulos, haciendo uso de la tcnica de programar y probar
(desarrollo comn). Junto a esto, una vez finalizada una porcin de cdigo se utiliz la
tcnica de valores lmites para probar que la parte del programa funciona
correctamente.
Solo se documentaron las pruebas realizadas a los mdulos. Estas deben tener el
resultado esperado vs el obtenido, junto con la fecha realizada y la descripcin de la
prueba, las cuales fueron registradas en una matriz de pruebas.
Para las pruebas de integracin, se utiliz de la tcnica de Integracin ascendente
(Bottom to Top), es decir, se integran los mdulos movindose en direccin jerrquica
de menor a mayor comenzando por el Mdulo principal (Mdulo Ingreso) para seguir
posteriormente con los otros mdulos del software y llegar al ms importante que es el
Mdulo Orden de Trabajo.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

65

Captulo V

Durante las pruebas de Arquitectura Cliente-Servidor se dispuso de todo el


equipamiento necesario, lo que permiti obtener los resultados esperados logrando la
conexin establecida en forma correcta. Esto quiere decir, que a travs del software se
pudo conectar a la base de datos ubicada en el otro equipo a travs de la direccin IP
ingresada en el software.
Las pruebas de sistema, consistieron en validar que los requerimientos se vieran
reflejados en el software, como tambin probar que lo diseado correspondiera a lo
construido.

Los responsables de realizar las pruebas mencionadas fueron los siguientes:

Prueba
Unitarias
Integracin
Arquitectura
Cliente - Servidor
Sistema
Aceptacin

Responsable
Cristian Vsquez
Cristian Vsquez
Cristian Vsquez
Cristian Vsquez
Nelson Paillalef Ernesto Morales

Tabla 22 Responsables Pruebas

Se ejecutaron todas las pruebas en donde se obtuvo

entre 2 a 4 ciclos segn el

Mdulo. Esto se produjo debido a la cantidad de errores que se fue detectando segn
cada iteracin.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

66

Captulo V

A continuacin se muestra la matriz de pruebas realizada:

Tabla 23 Matriz Casos de Prueba

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

67

Captulo V

Tabla 24 Matriz Ejecucin Pruebas

N Ciclo Prueba
1
2
3
4

% Correcto
50%
60%
50%
100%

% Incorrecto
50%
40%
50%
0%

Tabla 25 Resultados Ciclos Pruebas

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

68

Captulo V

Con respecto a las pruebas de aceptacin, estas fueron ejecutadas correctamente junto
al resto, por lo tanto, no fue necesario realizar otro ciclo de pruebas para realizar
correcciones.
Finalmente, se adjunta a continuacin un grfico que muestra la duracin real que tuvo
el proyecto, versus la duracin estimada:

Desviacin Planificacin
600

Horas Hombre

500
400
300
200
100
0

Anlisis

Diseo

Codificacin

Pruebas

Implantacin

Esfuerzo Estimado

83

167

335

125

125

Esfuerzo Real

62

115

490

66

67

Figura 43 Duracin Final Proyecto

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

69

CAPTULO VI
CONCLUSIONES

Captulo VI

6 Conclusiones
Se puede determinar que gracias a la ingeniera de requerimientos, se construy un
producto de software que cumple con todos los requerimientos especificados en la fase
de anlisis del proyecto. Para poder lograr esto, por un lado lo esencial fue basar el
apoyo en libros como Sommerville y Pressman, junto a las estandarizaciones de la
IEEE y el uso PMBOK, para poder lograr una gestin adecuada.
A su vez, fue importante haber obtenido apoyo de las herramientas que existen tanto
para poder controlar el avance que se tuvo dentro del proyecto, como tambin para
poder establecer diferentes versiones dentro del producto que se construy, lo que
contribuy especficamente para poder contrarrestar los riesgos que se dispararon en
un momento dentro de la etapa de codificacin, permitiendo continuar con la ejecucin
de esta y no perder el rumbo del proyecto.

Con respecto a la gestin del tiempo utilizado dentro del proyecto, se destaca que la
estimacin que se realiz en un comienzo del proyecto sirvi demasiado para poder
llevarlo a cabo, recalcando que al finalizar algunas etapas del proyecto se pudo notar
que se termin antes de lo estimado gracias a los hitos de control y evaluacin que
existieron dentro de estas. Permitiendo por un lado, poder dedicar ms tiempo para
afinar detalles o adelantar el trabajo de la siguiente etapa, y a su vez, prestar atencin a
los riesgos que fueron disparados, lo que finalmente provoc que ese tiempo de holgura
no fuera desperdiciado, retrasando minuciosamente las actividades posteriores que
terminaron exitosamente dentro del tiempo estimado, gracias al doble esfuerzo que se
tuvo que hacer da a da para mantener la duracin.

De esta manera, se aprendi que con seguimiento y control sobre el proyecto de


software se permite identificar retrasos y poder planificar nuevamente. Junto a esto, la
importancia de utilizar herramientas como un sistema de control de versiones y un IDE,
para lograr un producto.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

71

Captulo VI

En el diseo, al haber utilizado las 4 vistas de Kruchten se logr disminuir la


complejidad e incertidumbre respecto a lo que se va a codificar, como tambin a los
elementos que se van a utilizar y la relacin que estos van a tener bajo una
funcionalidad determinada.
Sin embargo, cabe destacar que a pesar de haber utilizado las vistas para disminuir
inseguridad respecto a lo que se quiso codificar, esto de todas maneras produjo errores
en el software, los cuales fueron mitigados a medida que se cumplan los ciclos de
pruebas generados segn el mdulo que correspondiera, como tambin del resultado
que se fuera obteniendo hasta lograr un 100% de aprobacin.
Dentro de los objetivos, se cumplieron los objetivos especficos planteados en el inicio
del proyecto de software, por lo tanto, se cumpli el objetivo general. De esta manera,
se obtuvo los resultados esperados para poder emitir ordenes de trabajo, las cuales
permitieron que el personal pueda manipularlas y trabajar haciendo uso de ellas.
SOPRAF S.A., rpidamente ha logrado la adaptacin esperada por parte del personal
encargado de su manipulacin, lo que ha concluido en entregar informacin necesaria y
relevante para aclarar dudas que el mecnico ha tenido con respecto a fallas y
reparaciones.
Finalmente, destacar la relevancia que tuvo mantener un contacto frecuente y fluido
tanto con el cliente, como tambin con el profesor gua, lo que permiti aclarar las
dudas que se generaron durante el proceso del proyecto y ejecutar los objetivos
planteados al comienzo, permitiendo de esta manera poder cumplir o superar las
expectativas del cliente, entregando un producto de calidad en el tiempo establecido.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

72

CAPTULO VII
BIBLIOGRAFA

Captulo VII

7 Bibliografas
Aranda, Vicente Apunte Mtricas de Software.
Fowler, Martin Scott, Kendall 1999 UML Gota a Gota Pearson Education
Addison Wesley Longman de Mxico.
Pressman, Roger 2002 Ingeniera del Software, Un Enfoque Prctico McGraw
Hill 5ta Edicin Madrid, Espaa.
Sommerville, Ian 2005 Ingeniera del Software Pearson Educacin 7ma
Edicin Madrid, Espaa.
PMI, Project Management Institute 2008 Gua de los Fundamentos para la
Direccin de Proyecto (Gua del PMBOK) 4ta Edicin Impreso en EEUU.
IEEE 829 1983 Plan de Pruebas de Software.
IEEE 830 1983 Especificacin de Requerimientos de Software.
IEEE 1058 1998 Estndar de la IEEE para los Planes Administracin de Proyectos
de Software.
IEEE 1471 2000 Arquitectura de Software.
http://www.slideshare.net/galo_priva/mtricas-del-proceso-y-proyecto-procesos-deingeniera-de-software-372897 Mtricas de Proceso y Proyecto.
http://www.fi.unju.edu.ar/materias/materia/SI2/document/Clase_20-may-2009/SIII2009__Metricas_de_Proceso_y_Proyecto.pdf?cidReq=SI2 Mtricas de Proceso y
Proyecto.
http://nathanj.github.com/gitguide/tour.html Gua de uso Software GIT.
http://chuwiki.chuidiang.org/index.php?title=Ejemplo_sencillo_de_creaci%C3%B3n_de_
un_pdf_con_iText Creacin de PDF con iText.

Software de Administracin para la Realizacin de Mantenciones y Reparaciones de Vehculos

74