Tesis Digital AMRV

UNIVERSIDAD ANDRÉS BELLO FACULTAD DE INGENIERÍA ESCUELA DE INFORMÁTICA

INGENIERÍA EN COMPUTACIÓN E INFORMÁTICA

“Software de Administración para la Realización de Mantenciones y Reparaciones de Vehículos”

CRISTIAN RODRIGO VÁSQUEZ LEAN

PROYECTO DE TÍTULO PARA OPTAR AL TÍTULO DE INGENIERO EN COMPUTACIÓN E INFORMÁTICA

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 difíciles, como también de momentos

gratificantes, los cuales lograron mantener la motivación para poder salir adelante.

En primer lugar, quiero agradecer a mis compañeros tanto por el apoyo moral, como

también por creer en mí. Principalmente, agradezco la compañía durante largas tardes

cada semana. A su vez, Quiero agradecer a Oscar Pinto G, quien fue mi profesor guía y

una gran persona en la cual pude obtener todo el apoyo, respaldo y tiempo, como

también la confianza y motivación 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 sueño se convierta en realidad,

sin duda es el pilar fundamental para poder lograr cualquier cosa.

ÍNDICE DE CONTENIDO

RESUMEN

2 INTRODUCCIÓN .......................................................................................................................................................... 1

1.1 SITUACIÓN ACTUAL ............................................................................................................................................................. 1 1.2 ACTORES RELEVANTES DE LA SITUACIÓN ACTUAL ........................................................................................................................ 2 1.3 EL PROBLEMA .................................................................................................................................................................... 3 1.4 EXPLICACIÓN DEL PROBLEMA ................................................................................................................................................. 4 1.5 PROPÓSITO DE LA SOLUCIÓN.................................................................................................................................................. 5

3 FUNDAMENTACIÓN DEL TEMA ................................................................................................................................... 7

2.1 SOLUCIÓN PROPUESTA ......................................................................................................................................................... 8 2.2 DETALLES DE LA SOLUCIÓN .................................................................................................................................................... 9 2.3 PROCESOS DE NEGOCIOS INTERVENIDOS .................................................................................................................................. 9 2.4 OBJETIVOS ....................................................................................................................................................................... 11

2.4.1 Objetivo General ................................................................................................................................................. 11 2.4.2 Objetivos Específicos ........................................................................................................................................... 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 Aceptación ....................................................................................................................................... 13

4 MATERIALES Y MÉTODOS ......................................................................................................................................... 15

3.1 PROCESO ......................................................................................................................................................................... 16 3.2 PLAN DE CALIDAD ............................................................................................................................................................. 17 3.3 PLAN DE TRABAJO ............................................................................................................................................................. 18 3.4 PLAN DE GESTIÓN DE RIESGOS ............................................................................................................................................. 19 3.5 PLAN DE COMUNICACIONES ................................................................................................................................................ 21 3.6 PLAN DE ACEPTACIÓN DEL PROYECTO ................................................................................................................................... 22 3.7 PLAN DE GESTIÓN DE LA CONFIGURACIÓN .............................................................................................................................. 23 3.8 PLAN DE RESOLUCIÓN DE CONTROVERSIAS ............................................................................................................................. 25 3.9 PLAN DE DOCUMENTACIÓN ................................................................................................................................................. 26 3.10 PLAN DE INFRAESTRUCTURA ........................................................................................................................................... 27 3.11 PLAN DE RECURSOS HUMANOS ....................................................................................................................................... 28 3.12 PLAN DE CIERRE DEL PROYECTO ...................................................................................................................................... 29 3.13 PRODUCTO.................................................................................................................................................................. 30 3.14 ANÁLISIS ..................................................................................................................................................................... 31 3.15 DISEÑO ...................................................................................................................................................................... 32 3.16 CONSTRUCCIÓN ........................................................................................................................................................... 33 3.17 PRUEBAS .................................................................................................................................................................... 33 3.18 IMPLANTACIÓN ............................................................................................................................................................ 34 3.19 PROCESO VS PRODUCTO ................................................................................................................................................ 34

5 RESULTADOS Y DISCUSIÓN ....................................................................................................................................... 36

4.1 RESULTADOS PLAN DE CALIDAD ........................................................................................................................................... 36 4.2 RESULTADOS PLAN DE TRABAJO ........................................................................................................................................... 36 4.3 RESULTADOS PLAN DE GESTIÓN DE RIESGOS ........................................................................................................................... 39 4.4 RESULTADOS PLAN DE COMUNICACIÓN ................................................................................................................................. 41 4.5 RESULTADOS PLAN DE ACEPTACIÓN DEL PROYECTO ................................................................................................................. 42 4.6 RESULTADOS GESTIÓN DE LA CONFIGURACIÓN ........................................................................................................................ 43 4.7 RESULTADOS PLAN DE RESOLUCIÓN DE CONTROVERSIAS ........................................................................................................... 46

4.8 RESULTADOS PLAN DE DOCUMENTACIÓN .............................................................................................................................. 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 Análisis ......................................................................................................................................... 51 4.12.2 Resultados Diseño .......................................................................................................................................... 55 4.12.3 Resultados Construcción ................................................................................................................................ 63 4.12.4 Resultados Pruebas ........................................................................................................................................ 65

6 CONCLUSIONES ......................................................................................................................................................... 71

7 BIBLIOGRAFÍAS ......................................................................................................................................................... 74

ÍNDICE DE TABLAS

TABLA 1 – ESTIMACIÓN PROYECTO ..................................................................................................................................................... 37 TABLA 2 – RIESGOS IDENTIFICADOS..................................................................................................................................................... 39 TABLA 3 – MITIGACIÓN Y CONTINGENCIA DE LOS RIESGOS ...................................................................................................................... 41 TABLA 4 – EQUIPO ADMINISTRADOR ................................................................................................................................................... 42 TABLA 5 – EQUIPO ENCARGADO BODEGA ............................................................................................................................................ 43 TABLA 6 – ÍTEMS DE CONFIGURACIÓN ................................................................................................................................................. 43 TABLA 7 – ROL GESTIÓN DE LA CONFIGURACIÓN ................................................................................................................................... 44 TABLA 8 – LÍNEAS 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 MÓDULO INGRESO .................................................................................................................................. 52 TABLA 15 – REQUERIMIENTO MÓDULO DE ADMINISTRACIÓN .................................................................................................................. 53 TABLA 16 – MÓDULO INFORMES E INDICADORES .................................................................................................................................. 53 TABLA 17 – MÓDULO COMPRAS ........................................................................................................................................................ 54 TABLA 18 – MÓDULO RETIRO REPUESTOS ........................................................................................................................................... 54 TABLA 19 – MÓDULO 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 EJECUCIÓN PRUEBAS ........................................................................................................................................... 68 TABLA 25 – RESULTADOS CICLOS PRUEBAS .......................................................................................................................................... 68

ÍNDICE DE FIGURAS

FIGURA 1 - SITUACIÓN ACTUAL ............................................................................................................................................................ 2 FIGURA 2 - ACTORES SITUACIÓN ACTUAL ................................................................................................................................................ 2 FIGURA 3 - DIAGRAMA ISHIKAWA ......................................................................................................................................................... 3 FIGURA 4 - MAPA IDEAS NECESIDADES CLIENTE ...................................................................................................................................... 7 FIGURA 5 - SOLUCIÓN PROPUESTA ........................................................................................................................................................ 8 FIGURA 6 - CASO DE USO PROCESO DE NEGOCIO INTERVENIDO ................................................................................................................ 10 FIGURA 7 - NIVELES TÍPICOS DE COSTO Y DOTACIÓN 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 GESTIÓN DE RIESGOS ......................................................................................................................................... 19 FIGURA 12 - PLAN DE GESTIÓN DE RIESGOS (2) .................................................................................................................................... 20 FIGURA 13 - PLAN DE COMUNICACIÓN ................................................................................................................................................ 21 FIGURA 14 - PLAN DE ACEPTACIÓN DEL PROYECTO ................................................................................................................................ 22 FIGURA 15 - PLAN DE GESTIÓN DE LA CONFIGURACIÓN .......................................................................................................................... 23 FIGURA 16 - CONTROL DE CAMBIOS ................................................................................................................................................... 24 FIGURA 17 - PLAN DE RESOLUCIÓN DE CONTROVERSIAS ......................................................................................................................... 25 FIGURA 18 - PLAN DE DOCUMENTACIÓN ............................................................................................................................................. 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 RETROALIMENTACIÓN ............................................................................................................... 30 FIGURA 23 - INGENIERÍA DE REQUERIMIENTOS ...................................................................................................................................... 31 FIGURA 24 - PLAN DE PRUEBAS .......................................................................................................................................................... 33 FIGURA 25 - CRONOGRAMA PROYECTO ............................................................................................................................................... 37 FIGURA 26 - CARTA GANTT ............................................................................................................................................................... 39 FIGURA 27 - CAMBIO ÍTEM DE CONFIGURACIÓN .................................................................................................................................... 44 FIGURA 28 - ORGANIGRAMA DEL PROYECTO ........................................................................................................................................ 48 FIGURA 29 - DIAGRAMA CASO DE USO – GENERAL ................................................................................................................................ 56 FIGURA 30 - CASO DE USO – MÓDULO RETIRO REPUESTOS .................................................................................................................... 56 FIGURA 31 - CASO DE USO – MÓDULO ORDEN DE TRABAJO.................................................................................................................... 57 FIGURA 32 - CASO DE USO – MÓDULO INFORMES ................................................................................................................................ 57 FIGURA 33 - CASO DE USO – MÓDULO 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 – MÓDULO INGRESO............................................................................................................................ 63 FIGURA 41 - SOFTWARE AMRV – VENTANA PRINCIPAL ......................................................................................................................... 64 FIGURA 42 - SOFTWARE AMRV – MÓDULO ORDEN DE TRABAJO ............................................................................................................ 64 FIGURA 43 - DURACIÓN FINAL PROYECTO ............................................................................................................................................ 69

CAPÍTULO I

RESUMEN

1 Resumen

El objetivo de éste proyecto de software, es desarrollar una herramienta que apoye por

un lado la administración de los repuestos, los cuales se encuentran bajo la

responsabilidad de un encargado de bodega, y por otro apoyar el trabajo realizado por

el mecánico en cada vehículo que compone a la empresa SOPRAF S.A., en donde las

tareas que deba realizar, serán planificadas por un administrador a través de la

herramienta desarrollada.

Éste documento se ha dividido en seis capítulos, dentro de los cuales el primero

corresponde a un resumen en el cual se establece una síntesis respecto al propósito y

los objetivos de todo el contenido posterior del documento, para luego dar paso a la

introducción, fundamentación del tema, materiales y métodos utilizados, para poder

lograr planificar y diseñar lo que será el producto final a través de un proceso

secuenciado por actividades. Posteriormente, continua el capítulo de los resultados

obtenidos, en donde se demuestra todo lo que se ha realizado en el proyecto,

finalizando con el capítulo de conclusiones y experiencias adquiridas a lo largo de la

transición del proyecto, el cual entrega como resultado una aplicación que contiene las

actividades necesarias para solucionar la problemática del cliente.

Al concluir el proyecto, se obtiene una herramienta informática basada en un conjunto

de necesidades para poder mantener un orden del trabajo, realizado por un

administrador, un mecánico y un encargado de bodega. A su vez, proporcionar un valor

agregado entregando reportes que permitirán al cliente poder tomar una decisión más

segura al momento de realizar una compra de repuestos, entregando información

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 vehículo.

CAPÍTULO II

INTRODUCCIÓN

Capítulo II

Software de Administración para la Realización de Mantenciones y Reparaciones de Vehículos - 1

2 Introducción

El presente proyecto fue desarrollado para la empresa SOPRAF S.A., empresa de Taxis

Colectivos la cual está dedicada al rubro del transporte público 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 día y

entregar un servicio seguro a sus clientes, necesita apoyo para estructurar y mejorar su

servicio de mantenimiento y reparación de vehículos. Es por ello la razón por la cual se

propuso la realización de éste proyecto de software.

Para poder trabajar como empresa de transporte público de pasajeros, se debe

concursar a través de una licitación en el Ministerio de Transportes cada cierto ciclo de

años. La licitación está compuesta por diferentes normas que deben ser cumplidas para

poder ganar el permiso y poder operar.

2.1 Situación Actual

El trabajo del mecánico consiste en realizar lo que estime necesario para cada vehículo

a medida que estos van llegando al terminal. Cabe destacar que no existe ninguna

planificación por parte del mecánico. A su vez, el trabajo también se basa en atender

otros problemas siempre y cuando el conductor se percate de que algo no está

funcionando correctamente, o escuche algún ruido que genere inquietudes.

Para realizar alguna reparación en el caso de encontrar una falla, el mecánico se dirige

hacia algún 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 mecánico

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 reparación 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.

Capítulo II


OF

ICIN

AT

ALL

ER

MecánicoMecánico

Reparación o Mantención Vehículo

Retiro repuestoRetiro repuesto

MecánicoMecánico Encargado BodegaEncargado Bodega

Figura 1 – Situación Actual

2.2 Actores relevantes de la situación actual

El mecánico junto a algún miembro del directorio que por lo general es el designado

como encargado de bodega, son los principales actores de esta situación.

Figura 2 - Actores situación actual

uc Use Case Model

MecánicoEncargado de

Bodega

Capítulo II


2.3 El Problema

En la empresa SOPRAF S.A., existe una gran pérdida de dinero en pagos de multas,

como también en la compra de repuestos, los cuales por falta de stock deben ser

adquiridos semanalmente en pocas unidades para poder realizar algún trabajo de

carácter mecánico en los vehículos de la empresa.

El mantenimiento de los vehículos también es un problema, ya que no se cuenta con la

suficiente organización, lo que implica no poseer evidencia respecto al trabajo que se

ha hecho en cada vehículo, mucho menos tener un conocimiento de los repuestos

utilizados y las fallas detectadas o bien reparadas.

A continuación, 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

Capítulo II


2.4 Explicación del problema

Algo que sucede comúnmente en éste tipo de empresas, es dejar de lado el

cumplimiento de las normas solicitadas por el Ministerio de Transportes. Esto ocurría

debido a la falta de fiscalización, pero, con las nuevas implementaciones que se han

realizado en estos procesos, las multas comenzaron a ser reiteradas generando una

mayor pérdida de dinero en la empresa, como también en los conductores de cada

vehículo 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 mecánico en la empresa cuenta con escasa organización, esto

quiere decir que el orden en el trabajo que se debe realizar día a día a los vehículos

que se revisan en el taller tiene como consecuencia un trabajo incompleto la mayoría de

las veces. Una de las grandes problemáticas frente a esta situación es el

desconocimiento por parte de los directores de la empresa respecto al trabajo que el

mecánico ha realizado a cierto vehículo. Generando muchos problemas debido a que la

mayoría de estos son de la misma marca y modelo, donde sólo pueden ser

diferenciados por su patente, lo que provoca en el mecánico realizar el mismo tipo de

trabajo al mismo vehículo durante el mismo día, más de una vez.

Además, respecto a la distribución de los repuestos se tiene un conocimiento casi nulo,

al no recordar la mayoría de las veces en donde se suministró cierto repuesto, lo cual

también se ha prestado para sufrir pérdidas y robos.

Junto a lo señalado anteriormente, existe también un problema respecto a las fallas que

sufren los vehículos. Por un lado, un vehículo es reparado cuando tiene una falla, al

tener diferentes modelos dentro de la empresa, la falla para un modelo de vehículo y su

reparación es diferente a la que pueda acontecer en otro modelo, como también su

reparación y el tipo de repuesto que se debe utilizar.

Capítulo II


Es también por esta razón, que el trabajo realizado carece de información necesaria

para saber cómo se realizó la reparación. Obteniendo comúnmente como resultado en

éste trabajo que una falla vuelva a aparecer en un muy corto plazo después de ser

reparada, lo que provoca en el mecánico volver a analizar la falla y gastar tiempo

nuevamente en pensar alguna solución, ya que en ningún lugar se dejó señalado cómo

se realizó algún trabajo de iguales características, o bien similares.

2.5 Propósito de la solución

Para solucionar los problemas señalados anteriormente, se propone la creación de un

proyecto de software que tendrá la capacidad de organizar el trabajo que deba realizar

el mecánico a través de órdenes de trabajo generadas por un administrador, las que

permitirán registrar los repuestos utilizados, las fallas detectadas y el tipo de servicio

que se le debe entregar a cada vehículo en particular durante una fecha determinada.

Por otro lado, registrar el ingreso y retiro de repuestos por parte del personal encargado

de bodega.

CAPÍTULO III

FUNDAMENTACIÓN DEL TEMA

Capítulo III


3 Fundamentación del Tema

Respecto al proceso de negocio del cliente, a través del análisis ejecutado y a la

identificación del problema, se lograron establecer las siguientes necesidades que

presenta para poder llevar a cabo su trabajo de una manera más organizada.

A continuación, se presenta un mapa de ideas dentro del cual se pueden observar las

ventajas que el cliente obtendrá con el proyecto de software, como también una visión

general respecto al funcionamiento que éste tendrá, y la organización que se

presentará una vez que se comience a utilizar la herramienta.

Figura 4 - Mapa Ideas Necesidades Cliente

Capítulo III


3.1 Solución Propuesta

Dado todos los antecedentes mencionados, esta propuesta se basa en ofrecer una

aplicación 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

mantención y reparación de vehículos. Éste software (producto) se compone de una

aplicación de escritorio (cliente) en donde cada usuario podrá realizar las funciones que

le corresponda según el rol que cumpla dentro de la empresa.

A continuación, se presenta el funcionamiento que tendrán los diferentes actores dentro

de la solución propuesta:

Figura 5 - Solución Propuesta

Capítulo III


3.2 Detalles de la solución

La solución de software que se ha propuesto deberá contar con seis módulos, dentro de

los cuales deberá permitir mantener un registro del personal trabajando en la empresa

(conductores, administradores, encargados de bodega y mecánicos), como también

registros de los vehículos y la asociación de estos a sus correspondientes conductores.

Cabe destacar, que parte de la solución será tener un registro de las fallas que se

producen en los vehículos, como también el ingreso de los repuestos que son

comprados a los proveedores y a la vez suministrados a cada uno de los vehículos.

Éste suministro se realizará bajo la supervisión del encargado de bodega, el cual será

el único responsable de poder retirar algún repuesto solicitado por el mecánico, 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 códigos de barra, el

cual permitirá imprimir los códigos según los productos adquiridos, para luego realizar el

registro de los productos a través de un módulo de compras complementado por un

lector de código de barras.

Finalmente, generar informes respecto al trabajo realizado por parte del mecánico,

como también de los repuestos más utilizados y comprados, fallas más reiteradas,

como también la cantidad de órdenes de trabajo por vehículo, entre otros.

3.3 Procesos de Negocios Intervenidos

Los procesos asociados para el Mecánico cambiarán, agregando nuevas

funcionalidades a su rol, que serán el registro de las fallas al momento de estar

realizando una reparación o mantención, como también 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.

Capítulo III


Figura 6 – Caso de Uso Proceso de Negocio Intervenido

Para el Encargado de Bodega, las funcionalidades que cumplirá serán las mismas, sin

embargo el registro de los repuestos retirados será algo fundamental para poder llevar

un control de stock más claro.

Junto a esto, se decidió junto con el cliente agregar a un nuevo actor llamado

Administrador para que participe en la solución. Éste deberá encargarse de la

generación de nuevas órdenes de trabajo, la cual estará constituida por servicios que

un Mecánico debe realizar.

La asignación de los vehículos que deberá revisar, estará indicada en la orden de

trabajo impresa, en donde además el mecánico tiene que cumplir con detallar el trabajo

de los servicios indicados y las fallas detectadas.

Capítulo III


3.4 Objetivos

SOPRAF S.A. es una empresa dedicada a la labor de transporte público de pasajeros,

con el ánimo de crecer cada día y entregar un buen servicio a sus clientes. Necesita el

apoyo para estructurar y mejorar su servicio, es por ello la razón 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

mantención y reparación de vehículos, y permita la administración de los recursos que

dispone la empresa.

3.4.2 Objetivos Específicos

1. Registrar repuestos y recursos utilizados en las mantenciones y reparaciones de

vehículos.

2. Debe permitir a SOPRAF S.A administrar las órdenes de trabajo respecto a los

servicios que se deben realizar a un vehículo y asignarlas a un mecánico.

3. Obtener estadísticas de los recursos utilizados en las mantenciones y

reparaciones de vehículos.

4. Registrar las compras de repuestos.

Capítulo III


3.4.3 Consideraciones

Se establece la entrega de un proyecto de software al final del período

establecido en la propuesta.

Toda entrega realizada será acompañada con su respectiva documentación.

Se capacitará a los usuarios que participarán en la herramienta por un período

determinado, siendo como fecha tope 15 días.

El Cliente es el encargado de proporcionar la información de cada usuario para

definir la estructura jerárquica, 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 descripción.

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 vehículos.

Crear órdenes de trabajo con fechas establecidas para un mantenimiento

Autónomo y Preventivo.

3.4.5 Supuestos

La Empresa cuenta con equipamiento capaz de soportar la Solución.

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

La Empresa cuenta con una red eléctrica.

Capítulo III


3.4.6 Limitaciones

Los siguientes tópicos no están incluidos en éste proyecto:

Configuración y/o Mantención del equipamiento de la empresa.

Configuración y/o Mantención de la red de área local e Internet.

Todo lo que esté fuera del alcance.

3.4.7 Criterios de Aceptación

Software AMRV con el 100% de sus requerimientos definidos.

Aprobación completa por parte de las pruebas durante dos semanas, junto a la

entrega de los resultados de estas.

Documentación necesaria para poder operar el Software.

Aceptación 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.

CAPÍTULO IV

MATERIALES Y MÉTODOS

Capítulo IV


4 Materiales y Métodos

Para alcanzar los objetivos mencionados, el proyecto se ha desarrollado siguiendo las

buenas prácticas señaladas por el PMBOK – 4ta Edición, estandarizaciones de la IEEE,

Ingeniería en Software – Un Enfoque Práctico por Roger S. Pressman, complementado

con los conocimientos adquiridos durante la carrera. Cabe destacar que todas las

actividades señaladas tanto por el PMBOK, IEEE y Pressman no fueron utilizadas dado

a que el proyecto y sus características no las necesitaban. Junto a esto, el modelo de

desarrollo utilizado ha sido el de cascada con retroalimentación, el cual se escogió

puesto a que los requerimientos del cliente han sido establecidos claramente desde un

principio y fue difícil que cambiaran durante el proceso del proyecto, pero no exenta a

que estos pudiesen tener alguna modificación en el caso de que el cliente lo requiera.

Podemos decir que un proyecto es un proceso que requiere una organización de etapas

las cuales están 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 construcción del software).

Figura 7 - Niveles Típicos de Costo y Dotación de Personal Durante el Ciclo de Vida del Proyecto

Capítulo IV


4.1 Proceso

Para llevar a cabo el proceso del proyecto, se seguirán las actividades definidas para

cada una de las etapas descritas en la Guía de los Fundamentos de la Dirección de

Proyectos (PMBOK, 4ta Edición). Las etapas definidas son las siguientes:

Iniciación

Planificación

Ejecución

Seguimiento y Control

Cierre

Figura 8 - Etapas Definidas en PMBOK

Junto a estas etapas, cabe recalcar que no es obligación hacer uso de todas, ya que

sólo dependerá de las características 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.

Capítulo IV


Éste plan pudo ser construido bajo la estandarización IEEE 1058, que hace mención al

Plan de Gestión del Proyecto de Software, mención que está compuesta de los

siguientes planes:

Plan de Calidad

Plan de Trabajo

Plan de Gestión de Riesgos

Plan de Comunicaciones

Plan de Aceptación del Proyecto

Plan de Gestión de la Configuración

Plan de Resolución de Controversias

Plan de Documentación

Plan de Infraestructura

Plan de Recursos Humanos

Plan de Cierre del Proyecto

4.2 Plan de Calidad

Figura 9 - Plan de Calidad

Capítulo IV


Dentro del plan de calidad, se deben definir componentes que estarán 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 Metodología que permita el aseguramiento, en donde esto último realiza y comprueba

la Norma o Metodología encontrada. Según lo anterior, se debe dar paso para planificar

el tiempo y los recursos que actuarán en el aseguramiento de calidad del componente

para luego realizar el desarrollo de la actividad.

Para la construcción del plan, se recurrió a la guía PMBOK 4ta Edición (Capítulo 8 –

Gestión 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 definición de las actividades

elaborando la Estructura de Desglose de Trabajo (EDT, WBS), estructura que servirá

para poblar cada etapa dentro del proceso de gestión del proyecto con actividades a

realizar. Luego de definir las actividades, se debe establecer una secuencia en estas

para dar paso a la asignación de los recursos correspondientes junto al tiempo

estimado de duración, concluyendo con un cronograma basado en la información

obtenida anteriormente.


Gestión del Tiempo), junto a la definición de la IEEE 1058 – Plan de Proyecto.

Capítulo IV


4.4 Plan de Gestión de Riesgos

Figura 11 - Plan de Gestión de Riesgos

Dentro de éste plan, la primera etapa consiste en la planificación de la gestión de los

riesgos, la cual corresponde a la definición de todas las etapas que se llevarán a cabo,

junto al cómo y cuándo se harán.

Una vez realizada la planificación, se procede a identificar los riesgos del proyecto. Al

tener los riesgos definidos, se deben realizar dos tipos de análisis, por un lado

corresponde a un análisis cualitativo que corresponde a la medición del impacto,

probabilidad de ocurrencia, entre otros. Como también, la segunda parte que

corresponde al análisis cuantitativo, el cual mide los efectos de los riesgos a los cuales

se les asigna una clasificación numérica. Junto a esto, se realiza la planificación

correspondiente a la respuesta según el tipo de riesgo disparado, en donde se define la

reacción 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 evolución de los distintos riesgos identificados.

Capítulo IV


Figura 12 - Plan de Gestión de Riesgos (2)

Cuando ocurre una eventualidad, se debe recurrir a la identificación del riesgo

disparado en donde se debe revisar el impacto que éste genera en el proyecto, como

también, correr el plan de contingencia y realizar la mitigación correspondiente. Una vez

detectado todo esto, se procede a realizar los cambios o acciones pertinentes como

una re-planificación de las actividades desde el punto en donde se generó la

eventualidad.

Finalmente, monitorear y controlar el riesgo disparado para que no siga afectando más

allá el avance del proyecto.


Gestión de los Riesgos del Proyecto).

Capítulo IV


4.5 Plan de Comunicaciones

Figura 13 - Plan de Comunicación

Dentro del plan de comunicación, se realiza el proceso que consiste en identificar a

todas las personas relacionadas con el proyecto y documentar información relevante

relativa a sus intereses, participación e impacto en el éxito del mismo. Para planificar la

comunicación y luego distribuir la información, 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 información respecto al desempeño, incluyendo

informes, mediciones y proyecciones.


Gestión de las Comunicaciones del Proyecto).

Capítulo IV


4.6 Plan de Aceptación del Proyecto

Figura 14 - Plan de Aceptación del Proyecto

Inicialmente, el cliente debe crear los criterios de aceptación. 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 especificación de la solución

propuesta.

Capítulo IV


Una vez creados los criterios, se procede a una revisión por parte del Jefe de Proyecto

para realizar una validación de estos, en donde esta validación puede no cumplir con lo

que el cliente realmente necesita, por lo que se puede proceder a realizar una reunión

para establecer cambios en los criterios y llegar a un acuerdo final.

Si los criterios son aceptados, se realiza la ejecución de estos, los cuales deberán ser

documentados por el cliente para luego entregárselos 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 realizarán los cambios y

correcciones necesarias para volver a realizar la ejecución 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 aprobación 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 aprobación.

4.7 Plan de Gestión de la Configuración

Figura 15 - Plan de Gestión de la Configuración

Capítulo IV


Como primera parte del proceso, se deben definir los objetivos del plan de

configuración. Al tener estos claros, se definen los ítems de la configuración los cuales

corresponden a todos aquellos elementos entregables en el proyecto. La siguiente

etapa consiste en la definición de roles para el correcto funcionamiento del plan de

configuración, con el fin de mantener un control respecto a las responsabilidades que

existen frente a cada ítem, para más tarde si fuese necesario hacer uso del control de

cambios.(Figura N° 16 – Control de Cambios).

El proceso continua con la definición de la herramienta SVN y del repositorio web para

tener un control de las versiones que se vayan generando.

Finalmente, se definen cuáles serán las líneas base que permitirán 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 algún

cambio, el cual debe ser realizado a través del procedimiento Control de Cambios.

Para la construcción del plan, se recurrió a la guía Ingeniería del Software – Un

Enfoque Práctico, Roger S. Pressman (Capítulo 9 – Gestión de la Configuración del

Software).

Figura 16 - Control de Cambios

Capítulo IV


4.8 Plan de Resolución de Controversias

Figura 17 - Plan de Resolución 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 comúnmente por

ambigüedad en la especificación 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 solución 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 construcción del plan, se recurrió a los apuntes del Profesor Vicente Aranda

Chacón.

Capítulo IV


4.9 Plan de Documentación

Figura 18 - Plan de Documentación

Partiendo de una base dentro del plan de documentación, primero se deben establecer

los requisitos de documentación, esto significa que se da a conocer lo que se va a

documentar. Luego comienza el establecimiento de los documentos junto a la definición

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 estimación para la documentación.

Capítulo 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 comparación de la amplia gama tecnológica 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 mantención

para poder obtener el rendimiento esperado, como también la configuración necesaria

para hacerlo funcionar.

Por último, establecer el software a ser utilizado, lo que permitirá poder trabajar

correctamente.

Capítulo 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 búsqueda de personal con disponibilidad, se realiza la

asignación de estos al proyecto dependiendo de las características 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 vacío. Posteriormente, se realizará la

calendarización de los recursos obtenidos durante el proceso del proyecto, en donde se

dará paso para poder capacitar al personal adquirido y luego obtener una evaluación de

estos según su desempeño.


Gestión de los Recursos Humanos del Proyecto).

Capítulo 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 verificación 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 algún plan no se encuentra finalizado, éste se

deberá revisar para luego ser completado y volver a realizar la verificación por el Plan

de Proyecto. Posteriormente, se debe ejecutar el plan de aceptación 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.


Proceso de la Dirección de Proyectos para un Proyecto).

Capítulo 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 informática que permitirá apoyar las funcionalidades de

su empresa. Respecto al cómo 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 retroalimentación, 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 Retroalimentación

Capítulo IV


4.14 Análisis

Esta etapa del producto, se centra en la obtención de los requerimientos los cuales

fueron formalizados en el documento de especificación de requerimientos bajo la

estandarización de la IEEE 830. Para la obtención de los requerimientos, se recurrió al

uso de la Ingeniería de requerimientos, la cual entrega los correctos pasos para lograr

obtener los requerimientos correctamente.

Las etapas realizadas fueron las siguientes:

Figura 23 - Ingeniería de Requerimientos

Dentro de la etapa de Elicitación y Análisis, se buscaron comprender las necesidades

del cliente. Esta búsqueda se manifestó por un lado analizando el documento de

licitación elaborado por el Ministerio de Transportes, junto a los principales defectos que

ya habían sido considerados importantes. Para la comprensión completa de los

requerimientos, se realizaron reuniones con el cliente sumando un total de tres, en

donde además se trabajó en conjunto generando ideas y confeccionando mapas

mentales para poder aclarar aún más las necesidades.

Al terminar la elaboración de los mapas y las reuniones, se determinó la integración de

un nuevo actor para colaborar en esta solución.

Capítulo IV


Dentro de la etapa de Especificación de requerimientos y Validación, se utilizó la

estandarización señalada 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 verificación en donde se

buscó la coherencia y cohesión a través de una traza realizada desde el principio hasta

el fin de los requerimientos analizados.

4.15 Diseño

Esta etapa se enfoca en todo lo que está vinculado a la arquitectura del software que se

quiere construir, junto al cómo se verá una vez finalizado. Para la documentación de

esta etapa se utilizó la estandarización señalada por la IEEE 1471 complementado con

la estandarización UML 2.0 y el desarrollo de las distintas vistas de Kruchten 4+1, lo

que permitió la realización 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

interacción entre los usuarios, las pantallas y las instancias de los objetos en el

sistema.

Lógica: Asociado al Diagrama de Clases, en donde se encuentra el núcleo del

desarrollo y del diseño orientados a objetos.

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

software, controladores involucrados, entre otros.

Física: Asociado al Diagrama de Despliegue, el cual provee un modelo detallado

de la forma en la que los componentes se desplegarán a lo largo de la

infraestructura propuesta.

Capítulo IV


Además, se define el lenguaje que se utilizará para la programación del software, como

también para la base de datos.

4.16 Construcción

Dentro de esta etapa, se concentra la mayor parte del esfuerzo para la construcción del

software según lo diseñado en la etapa anterior, junto al entregable comprometido para

el cliente el cual consistió en el Manual de Usuario.

Para llevar a cabo la construcción, se decidió establecer una reunión con el profesor

guía para obtener asesoría y comenzar en el mes de Enero. Esto ocurrió debido a que

el tamaño del software superó lo esperado para el trabajo de una persona, lo que

implicó utilizar más 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

estandarización señalada por la IEEE 829, se puede resumir de la siguiente manera:

Figura 24 - Plan de Pruebas

Capítulo IV


El plan consistió en definir el alcance de las pruebas que se van a realizar, las cuales se

categorizaron según 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 según 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 realización 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 Implantación

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 solución propuesta bajo su correcta configuración especificada en la etapa

de diseño. 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 gestión estuvo presente en la ejecución 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

planificación inicial junto a los riesgos ante las posibles eventualidades que se habían

identificado y pudiesen ser disparadas.

CAPÍTULO V

RESULTADOS Y DISCUSIÓN

Capítulo V


5 Resultados y Discusión

Como resultado obtenido respecto a la ejecución 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 sitúa en la estandarización utilizada por las IEEE 1058,

1471, 830, 829. Al utilizar estas estandarizaciones, la calidad puede asegurarse al

momento de realizar la construcción, ya que también pasó por un proceso de validación

estipulado dentro de estos documentos. Por otro lado, la ejecución y definición de

criterios de aceptación 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 definición 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 estimación del tiempo (HH) de trabajo

para cada etapa, obteniendo los siguientes resultados utilizando Puntos por Caso de

Uso:

Capítulo V


Etapa de Cascada Tiempo (HH)

Análisis 83

Diseño 167

Codificación 335

Pruebas 125

Implantación 125

Total Esfuerzo 835

Tabla 1 – Estimación Proyecto

A continuación 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 realización del proyecto que fueron 803HH Reales, versus

las 835HH estimadas.

Junto a esto, se muestran las actividades que contiene cada etapa:

Capítulo V


Capítulo V


Figura 26 – Carta Gantt

5.3 Resultados Plan de Gestión de Riesgos

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

están representados en la siguiente tabla:

ID

Riesgo

Nombre del Riesgo Probabilidad

de ocurrencia

Impacto

(consecuencia)

Nivel de

Riesgo

R01 Resistencia al cambio Casi Cierto Muy Alto Alto

R02 Falta de motivación por parte de

SOPRAF S.A.

Poco Probable Medio Significativo

R03 Falta de compromiso o disponibilidad

por parte de SOPRAF S.A.

Poco Probable Muy Alto Significativo

R04 Problemas con avance del producto Poco Probable Extremo Alto

R05 No disponer de los recursos físicos

especificados

Poco Probable Extremo Alto

R06 Cambio en los requerimientos Poco Probable Extremo Alto

Tabla 2 – Riesgos Identificados

Capítulo V


No se realizó un análisis cuantitativo, dado a las características del proyecto y por la

razón de encontrar que no es algo indispensable tener éste tipo de evaluación dentro

de los riesgos.

Con respecto a la mitigación y contingencia, según el riesgo que sea gatillado se

muestra a continuación la siguiente tabla que explica la mitigación que se debe ejecutar

y el plan de contingencia que se debe llevar a cabo:

ID Riesgo

Responsable de Mitigarlo

Mitigación Plan de Contingencia

R01

Jefe de Proyecto

1. Demostrar las ventajas y

beneficios que se lograrán con el

cambio.

2. Demostrar que todos pueden

manejar un computador y que

será fácil lograr el manejo del

software.

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.

R02 Jefe de Proyecto 1. Mostrar avances del proyecto.

2. Buscar ejemplos de empresas

que han surgido y destacado

gracias a la TI.

Motivar al directorio a través de charlas

didácticas las cuales indiquen el avance

que el proyecto está teniendo.

R03 Jefe de Proyecto 1. Establecer reuniones y mantener

una constante comunicación con

el cliente.

2. Integrarlos al trabajo, haciéndoles

saber que su opinión es

importante para que el proyecto

salga satisfactorio.

No se seguirá con el proyecto por falta de

compromiso, desinterés y poco feedback

por parte del cliente.

R04 Jefe de Proyecto 1. Controlar y verificar con la carta

Gantt en la etapa del proyecto el

estado de avance de éste.

2. Buscar el respaldo más reciente.

3. Designar más horas de trabajo a

la actividad.

4. Re-Planificar desde la actividad

afectada en adelante si es

necesario.

Pedir asesoría a los profesores guías.

Pedir más tiempo en la entrega de

proyecto final si fuese necesario.

R05 Jefe de Proyecto 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.

En caso de presentar problemas para

contar con ellos, conseguir un equipo de la

Universidad para realizar las pruebas del

software.

Capítulo V


Tabla 3 – Mitigación y Contingencia de los Riesgos

El seguimiento y control al riesgo, se realizó a través de las actividades “Control y

Evaluación” 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 más horas diarias.

5.4 Resultados Plan de Comunicación

Los interesados del proyecto son:

Nelson Paillalef (Cliente)

Ernesto Morales (Cliente)

Cristian Vásquez Lean (Jefe de Proyecto)

Con respecto a los canales de comunicación dentro del proyecto, se establecieron

reuniones una vez cada semana desde la etapa de codificación. Desde la semana de

pruebas en adelante, dos veces por semana, destacando que estas fueron de carácter

presencial en la empresa del cliente.

ID

Riesgo

Responsable

de Mitigarlo

Mitigación Plan de Contingencia

R06 Jefe de Proyecto 1. Formalizar los requerimientos con

actas.

2. Re Planificar e informar respecto

a las nuevas fechas de entrega.

Continuar trabajando con los

requerimientos que no han cambiado.

Capítulo V


Ante cualquier situación puntual, también se coordinaron reuniones por teléfono para

establecer juntas en una fecha no planificada.

5.5 Resultados Plan de Aceptación del Proyecto

Los criterios de aceptación 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 específicos de vehículos reparados y mantenidos.

4. Establecer registros respecto al stock de repuestos. Además, organizar la

información que se conoce respecto a los existentes.

5. Emitir órdenes de trabajo respecto a los servicios que se deben realizar a un

vehículo y asignarlas a un mecánico.

6. Mantener un registro de compras de repuestos junto con el ingreso del respectivo

proveedor y asignar un código de barras a cada repuesto adquirido.

7. Aumentar el conocimiento y distribución de repuestos en un 90%.

8. Registrar el retiro de repuestos por parte del Encargado de Bodega.

9. Manual de Usuario y Capacitación de personal involucrado.

Las funcionalidades del software, se probarán en los equipos del cliente destinados

para las pruebas de aceptación. Los cuales presentan las siguientes características:

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

Capítulo 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 Código de Barras Manhattan.

Tabla 5 – Equipo Encargado Bodega

El resultado de los criterios de aceptación fue de un 100% al momento de haberlos

realizado, los cuales fueron documentados en una matriz de pruebas.

Posteriormente, se firmó el acta de aceptación.

5.6 Resultados Gestión de la Configuración

El objetivo de éste plan, fue definir y mantener la integridad del código y los

documentos que se generaron a lo largo del ciclo de vida del proyecto.

Los ítems de configuración definidos fueron los siguientes:

N° Ítem Ítem de Configuración

IC01 Propuesta de Colaboración Profesional - Software AMRV

IC02 Especificación de Requerimientos IEEE 830

IC03 Análisis de Riesgos

IC04 Control de Cambios

IC05 Resolución de Controversias IC06 Minuta de Reunión – Cambio en los Requerimientos

IC07 IEEE 1471 – Arquitectura de Software “Kruchten 4+1” IC08 IEEE 829 – Plan de Pruebas IC09 IEEE 828 – Gestión de la Configuración IC10 Software

IC11 Matriz de Pruebas IC12 Manual de Usuario

IC13 Informe de Cierre (Experiencias Adquiridas) IC14 Carta Gantt

Tabla 6 - Ítems de Configuración

Capítulo V


Cada cambio en el versionamiento de un Ítem de Configuración (IC) antes señalado,

deberá quedar especificado en el documento Plan de Gestión de la Configuración, en la

tabla realizada para éste efecto.

Es aquí donde se registran todos los cambios realizados a los ítems de configuración,

así como también los cambios no aprobados y los que se están 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 Configuración

Tabla 7 – Rol Gestión de la Configuración

Nombre del Rol Persona Asignada Responsabilidades

Responsable de

Elementos de configuración,

Gestor de la configuración y

Gestor de Cambios

Cristian Vásquez L

Entregables, código fuente del software y

base de datos (fundamentalmente éste

último).

Evaluar el impacto y riesgo de los

cambios.

Capítulo V


El repositorio en Internet donde se maneja la información junto a los Ítems de

configuración mencionados es GITHUB, utilizando el software GIT para controlar las

versiones.

A continuación, la dirección del repositorio en internet:

https://github.com/CriVasquez/SWAMRV

Junto a esto, las líneas base que se crearon en la rama Master llevan la siguiente

definición:

Nombre Cuando se define Ítems de

Configuración

Recopilación de

Documentos (LB1)

Cuando comienza la construcción

del código.

IC1, IC2, IC3, IC4,

IC5, IC6, IC7, IC8

Software (LB2) Cuando se construye y se realizan las

pruebas Unitarias para el Módulo

Administración

IC9

Software (LB3) Cuando se construye y se realizan las

pruebas Unitarias. Módulo Informes e

Indicadores

IC9

Software (LB4) Cuando se construyen, se integran y se

prueban los Retiros de Repuesto,

Módulo Retiro de Repuestos

IC9

Software (LB5) Cuando se construye y se prueba el

Módulo Ingreso Compras

IC9

Software (LB6) Se integran los módulos y se realizan

las pruebas de integración.

IC9

Software (LB7) Se completan las pruebas restantes del

software (Arquitectura Cliente-Servidor,

Sistema y Aceptación). Se obtiene la

versión final del Software.

IC9

Recopilación

Documentos (LB8)

Se crean y/o actualizan los últimos

ítems de configuración del proyecto

(IC10, IC11, IC12). Obteniendo la

versión final de todos los documentos.

IC10, IC11, IC12

Tabla 8 – Líneas Base

https://github.com/CriVasquez/SWAMRV

Capítulo V


5.7 Resultados Plan de Resolución de Controversias

Dentro del proyecto no se desarrolló ningún tipo de controversia por parte del cliente, de

todas maneras en el caso de que alguna se hubiera manifestado, esta debe quedar

documentada a través de una minuta de reunión firmada por ambas partes, en donde

se especifica la solución respecto al problema acontecido.

5.8 Resultados Plan de Documentación

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 - Especificación de Requerimientos.

5. IEEE 829 - Plan de pruebas.

6. Plan de Gestión de la configuración.

7. Análisis de riesgos.

8. Gestión de cambio.

9. Resolución de controversias.

10. Minutas de reunión.

11. Estimación Proyecto.

12. Matriz de pruebas.

13. Plan de Aceptación.

14. Software AMRV.

15. Manual de Usuario.

16. Informe de cierre.

Capítulo V


5.9 Resultados Plan de Infraestructura

El hardware definido para poder realizar el proyecto se basó en dos equipos con las

siguientes características:

Nombre LENOVO 3000 N200

Procesador Intel Celeron 550 2.0 GHz

Memoria RAM 1 GB DDR

Disco Duro 120 GB

SO Windows XP Professional SP3

Tabla 9 – Hardware Infraestructura

Nombre LENOVO G470

Procesador Intel Core i5 2.5ghz

Memoria RAM 8.0 GB DDR3

Disco Duro 500 GB

SO Windows 7 Ultimate

Tabla 10 – Hardware Infraestructura (2)

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

continuación:

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.

Capítulo V


8. Toad For Oracle.

9. Microsoft Project 2010.

10. Enterprise Architecture 7.5.

11. GIT Versión 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

Capítulo V


La línea que une al Jefe de Proyecto con el Director general, indica que estas dos

personas fueron las que se comunicaron durante el proyecto. A continuación, se

especifican los roles de cada uno de los integrantes del grupo de trabajo:

Rol Responsabilidades

Jefe de

Proyecto

• 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 cohesión del equipo.

• Encargado de facilitar información al equipo de trabajo con

respecto a la empresa con la cual se está trabajando.

Arquitecto

Solución

• Es el encargado de diseñar la solución del problema

expuesto en SOPRAF S.A., con el fin de entregar al equipo

de trabajo soporte técnico respecto al trabajo a realizar.

• Diseña la arquitectura de la Base de Datos.

Secretaría • Departamento encargado de mantener las minutas de

reunión al día, como también de los procesos de control de

cambio, actas de revisión, planes, etc.

Desarrollador

JEE - PL/SQL

• Encargado de desarrollar la codificación de módulos del

proyecto a través del lenguaje de programación orientado a

objetos Java. Además, diseñar los manuales técnicos para

el usuario y aportar en las capacitaciones para la empresa.

• Encargado del desarrollo de codificación de base de datos,

apoyar la codificación 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.

Tester • Define criterios de aceptación para los resultados de la

integración y realización 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

Capítulo V


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

software por parte del cliente:

Rol Responsabilidad

Gerente General ∙ Representante legal de la empresa, como también, 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.

Director ∙ Encargado de asistir a los diferentes debates, reuniones, etc. Es

la cara visible de SOPRAF S.A., desempeñando un rol de Sponsor

para establecer comunicación con el Jefe de Proyecto para

coordinar reuniones.

Tabla 12 – Roles por parte del Cliente

Con respecto a la frecuencia y disponibilidad de comunicación 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 verificación 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:

Capítulo V


Etapa del Proyecto Evidencia ¿Cierre

Realizado?

Análisis IEEE 830: Especificación de Requerimientos. SI

Diseño IEEE 1471: Arquitectura de software SI

Codificación Software y Base de Datos SI

Pruebas Matriz de Pruebas SI

Implantación Acta de Aceptación del Proyecto SI

Plan de Proyecto Informe de Cierre del Proyecto SI

Tabla 13 – Cierre Etapas Ciclo Vida Proyecto

5.12 Resultados del Producto

De acuerdo al ciclo de vida del producto, se presentan a continuación los resultados de

cada etapa:

5.12.1 Resultados Análisis

Utilizando la técnica de Ingeniería de Requerimientos, se obtuvo lo siguiente:

Elicitación y Análisis 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 tendría ante un acta firmada por el Jefe de Proyecto y el Cliente.

Especificación de Requerimientos Como formato, se utilizó la estandarización

IEEE 830.

Capítulo 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 determinación de los objetivos para llevar a cabo el proyecto de software.

Junto a esto, una vez que la determinación de los requerimientos fue clara, se firmó un

acta de aceptación, validando de esta manera que el cliente está conforme con lo que

se ve reflejado en los requerimientos.

Verificación de requerimientos La primera parte, consistió en volver a revisar los

requerimientos a través 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 continuación, se muestran los requerimientos del software que se ha construido:

Nombre : Módulo Ingreso

Requisito : El software deberá tener un módulo de autentificación de

usuarios.

Descripción : El software deberá solicitar al usuario Rut, Contraseña y Tipo de

Cuenta para poder ingresar, de lo contrario no se podrá ejecutar

ninguna acción dentro del software.

Proceso : El usuario tendrá la facultad de utilizar los diferentes módulos del

software dependiendo el rol que cumpla.

Entrada : Rut usuario y Contraseña.

Salida Visualización de módulos según rol de usuario.

Tabla 14 – Requerimiento Módulo Ingreso

Capítulo V


Nombre : Módulo Administración

Requisito : Se compondrá de los siguientes mantenedores:

1. Mantenedor Repuesto

2. Mantenedor Vehículo

3. Mantenedor Personal

4. Mantenedor Fallas

5. Mantenedor Proveedor

6. Mantenedor Servicios

Los cuales permitirán las siguientes funcionalidades:

Crear

Borrar

Modificar

Buscar

Descripción : Permitirá realizar operaciones con los sub módulos del sistema

para poder trabajar con: vehículos, proveedores, fallas,

repuestos, servicios y personal.

Proceso : El usuario Administrador tendrá la facultad de utilizar estos

mantenedores una vez autentificado en el módulo ingreso.

Entrada : Visualización ventana principal.

Salida Visualización y selección de sub módulos.

Tabla 15 – Requerimiento Módulo de Administración

Nombre : Módulo Informes e Indicadores

Requisito : Deberán existir datos en la base de datos respecto a:

Vehículos

Repuestos

Ordenes de trabajo

Fallas

Descripción : Permitirá obtener información utilizando los datos de la empresa,

específicamente de repuestos, fallas, servicios, vehículos,

personal, compras.

Proceso : El administrador será el encargado de seleccionar la opción

respecto a la información que desea obtener.

Entrada : Datos de repuestos, fallas, servicios, vehículos, personal,

compras.

Salida Creación de informe formato PDF.

Tabla 16 – Módulo Informes e Indicadores

Capítulo V


Nombre : Módulo Compras

Requisito : Permitirá las siguientes funcionalidades:

Ingresar

Borrar

Modificar

Buscar

Descripción : Módulo que permitirá ingresar las compras de repuestos junto al

proveedor y el detalle.

Proceso : El Administrador será el encargado de ingresar las facturas de las

compras de repuestos realizadas.

Entrada : Factura con el detalle de la compra.

Salida Ingreso de los datos de la compra a la base de datos.

Tabla 17 – Módulo Compras

Nombre : Módulo Retiro Repuestos

Requisito : Requiere de la existencia de repuestos y stock.

Permitirá las siguientes funcionalidades:

Retirar

Devolver

Descripción : Módulo en el cual el encargado de bodega tendrá la facultad para

poder buscar, retirar y devolver repuestos.

Proceso : Se buscará el repuesto requerido en la bodega y posteriormente se

identificará con el lector de códigos de barras para poder realizar el

retiro. El mismo procedimiento de identificación funciona para la

devolución.

Entrada : Búsqueda o devolución de repuestos.

Salida Actualización de Stock en la base de datos.

Tabla 18 – Módulo Retiro Repuestos

Capítulo V


Nombre : Módulo Orden de Trabajo

Requisito : Requerirá datos ingresados por el resto de los módulos para poder

operar.

Permitirá las siguientes funcionalidades:

Ingreso

Modificación

Búsqueda

Eliminación

Además, contará con la agregación de servicios dependiendo del

tipo de trabajo que se necesite.

Descripción : Módulo principal del software en donde se manejarán los datos

ingresados por los otros módulos para poder registrar órdenes de

trabajo.

Proceso : El administrador será el encargado de designar las órdenes de

trabajo, como también del mecánico y vehículo.

Entrada : Definición orden de trabajo.

Salida Orden de trabajo formato PDF.

Tabla 19 – Módulo Orden de Trabajo

5.12.2 Resultados Diseño

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

diagramas:

Vistas UML

Escenarios Casos de Uso

Procesos Secuencia

Lógica Clases

Desarrollo Componentes

Física Despliegue

Tabla 20 – Vistas de Kruchten 4+1

Capítulo V


A continuación, se muestra la vista correspondiente a los escenarios, utilizando Casos

de Uso separados por diferentes niveles, desde una vista general hasta una más

específica:

Figura 29 – Diagrama Caso de Uso – General

Figura 30 – Caso de Uso – Módulo Retiro Repuestos

Capítulo V


Figura 31 – Caso de Uso – Módulo Orden de Trabajo

Figura 32 – Caso de Uso – Módulo Informes

Capítulo V


Figura 33 – Caso de Uso – Módulo Compras

Por otro lado, solo se mostrarán tres de los diagramas de secuencia más

representativos correspondientes a la vista de procesos, con el objetivo de demostrar la

interacción que existe entre las funcionalidades antes señaladas:

Figura 34 – Diagrama de Secuencia – Registrar Falla en Orden de Trabajo

Capítulo V


Figura 35 – Diagrama de Secuencia – Retiro de Repuesto

Figura 36 - Diagrama de Secuencia – Registrar Orden de Trabajo

Capítulo V


La lógica aplicada se basa en la orientación 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 diseñado, se obtuvo lo siguiente:

Figura 37 – Diagrama de Clases

Capítulo V


La vista de desarrollo, que se enfoca en la organización de los módulos del software en

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

continuación:

Figura 38 – Diagrama de Componentes

Capítulo V


Por otro lado, la vista física hace referencia a la distribución de los componentes físicos

en el ambiente de producción, haciendo uso del diagrama de despliegue:

Figura 39 – Diagrama de Despliegue

A través 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

implantación del proyecto, obteniendo una visión más clara de lo que se va a entregar

como producto final. Entendiendo finalmente la coherencia y cohesión existente entre

cada diagrama de Kruchten 4+1 y el objetivo de cada uno de estos.

Capítulo V


5.12.3 Resultados Construcción

Dentro de esta etapa, como resultado se obtiene al software diseñado en la etapa

anterior.

Con respecto a la programación, 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 más 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 continuación, se presentan algunas imágenes correspondientes al software:

Figura 40 - Software AMRV – Módulo Ingreso

Capítulo V


Figura 41 - Software AMRV – Ventana Principal

Figura 42 – Software AMRV – Módulo Orden de Trabajo

Capítulo V


5.12.4 Resultados Pruebas

Las pruebas que se realizaron fueron las siguientes:

Tipos de Pruebas Elementos que se ven afectados

Unitarias Código perteneciente al Módulo Administración,

Ingreso, Informes, Ingreso de compras y Retiro

repuestos.

Integración Todos los módulos mencionados funcionando

correctamente juntos.

Arquitectura

Cliente - Servidor

Base de datos, transacciones y comunicación en la red.

Sistema Informe Especificación de Requerimientos (IEEE 830),

Informe de Diseño (IEEE 1471) y Software.

Aceptación Software

Tabla 21 – Tipos de Pruebas

Se realizaron pruebas unitarias, a medida que se fue obteniendo un pequeño avance

respecto a los diferentes módulos, haciendo uso de la técnica de programar y probar

(desarrollo común). Junto a esto, una vez finalizada una porción de código se utilizó la

técnica de valores límites para probar que la parte del programa funciona

correctamente.

Solo se documentaron las pruebas realizadas a los módulos. Estas deben tener el

resultado esperado vs el obtenido, junto con la fecha realizada y la descripción de la

prueba, las cuales fueron registradas en una matriz de pruebas.

Para las pruebas de integración, se utilizó de la técnica de Integración ascendente

(Bottom to Top), es decir, se integran los módulos moviéndose en dirección jerárquica

de menor a mayor comenzando por el Módulo principal (Módulo Ingreso) para seguir

posteriormente con los otros módulos del software y llegar al más importante que es el

Módulo Orden de Trabajo.

Capítulo V


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

equipamiento necesario, lo que permitió obtener los resultados esperados logrando la

conexión establecida en forma correcta. Esto quiere decir, que a través del software se

pudo conectar a la base de datos ubicada en el otro equipo a través de la dirección IP

ingresada en el software.

Las pruebas de sistema, consistieron en validar que los requerimientos se vieran

reflejados en el software, como también probar que lo diseñado correspondiera a lo

construido.

Los responsables de realizar las pruebas mencionadas fueron los siguientes:

Prueba Responsable

Unitarias Cristian Vásquez

Integración Cristian Vásquez

Arquitectura

Cliente - Servidor

Cristian Vásquez

Sistema Cristian Vásquez

Aceptación Nelson Paillalef – Ernesto Morales

Tabla 22 – Responsables Pruebas

Se ejecutaron todas las pruebas en donde se obtuvo entre 2 a 4 ciclos según el

Módulo. Esto se produjo debido a la cantidad de errores que se fue detectando según

cada iteración.

Capítulo V


A continuación se muestra la matriz de pruebas realizada:

Tabla 23 – Matriz Casos de Prueba

Capítulo V


Tabla 24 – Matriz Ejecución Pruebas

N° Ciclo Prueba % Correcto % Incorrecto

1 50% 50%

2 60% 40%

3 50% 50%

4 100% 0%

Tabla 25 – Resultados Ciclos Pruebas

Capítulo V


Con respecto a las pruebas de aceptación, 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 continuación un gráfico que muestra la duración real que tuvo

el proyecto, versus la duración estimada:

Figura 43 – Duración Final Proyecto

Análisis Diseño Codificación Pruebas Implantación

Esfuerzo Estimado 83 167 335 125 125

Esfuerzo Real 62 115 490 66 67

0

100

200

300

400

500

600

Ho

ras

Ho

mb

re

Desviación Planificación

CAPÍTULO VI

CONCLUSIONES

Capítulo VI


6 Conclusiones

Se puede determinar que gracias a la ingeniería de requerimientos, se construyó un

producto de software que cumple con todos los requerimientos especificados en la fase

de análisis 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 gestión 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 también para

poder establecer diferentes versiones dentro del producto que se construyó, lo que

contribuyó específicamente para poder contrarrestar los riesgos que se dispararon en

un momento dentro de la etapa de codificación, permitiendo continuar con la ejecución

de esta y no perder el rumbo del proyecto.

Con respecto a la gestión del tiempo utilizado dentro del proyecto, se destaca que la

estimación 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 evaluación que

existieron dentro de estas. Permitiendo por un lado, poder dedicar más tiempo para

afinar detalles o adelantar el trabajo de la siguiente etapa, y a su vez, prestar atención 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 día a día para mantener la duración.

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.

Capítulo VI


En el diseño, al haber utilizado las 4 vistas de Kruchten se logró disminuir la

complejidad e incertidumbre respecto a lo que se va a codificar, como también a los

elementos que se van a utilizar y la relación 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 cumplían los ciclos de

pruebas generados según el módulo que correspondiera, como también del resultado

que se fuera obteniendo hasta lograr un 100% de aprobación.

Dentro de los objetivos, se cumplieron los objetivos específicos 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., rápidamente ha logrado la adaptación esperada por parte del personal

encargado de su manipulación, lo que ha concluido en entregar información necesaria y

relevante para aclarar dudas que el mecánico 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 también con el profesor guía, 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.

CAPÍTULO VII

BIBLIOGRAFÍA

Capítulo VII


7 Bibliografías

Aranda, Vicente – “Apunte Métricas de Software”.

Fowler, Martin – Scott, Kendall – 1999 – “UML Gota a Gota” – Pearson Education – Addison Wesley Longman de México. Pressman, Roger – 2002 – “Ingeniería del Software, Un Enfoque Práctico” – McGraw Hill – 5ta Edición – Madrid, España. Sommerville, Ian – 2005 – “Ingeniería del Software” – Pearson Educación – 7ma Edición – Madrid, España. PMI, Project Management Institute – 2008 – “Guía de los Fundamentos para la Dirección de Proyecto (Guía del PMBOK)” – 4ta Edición – Impreso en EEUU. IEEE 829 – 1983 – “Plan de Pruebas de Software”. IEEE 830 – 1983 – “Especificación de Requerimientos de Software”. IEEE 1058 – 1998 – “Estándar de la IEEE para los Planes Administración de Proyectos de Software”. IEEE 1471 – 2000 – “Arquitectura de Software”. http://www.slideshare.net/galo_priva/mtricas-del-proceso-y-proyecto-procesos-de-ingeniera-de-software-372897 – “Métricas 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 – “Métricas de Proceso y Proyecto”. http://nathanj.github.com/gitguide/tour.html – “Guía de uso Software GIT”. http://chuwiki.chuidiang.org/index.php?title=Ejemplo_sencillo_de_creaci%C3%B3n_de_un_pdf_con_iText – “Creación de PDF con iText”.

http://standards.ieee.org/findstds/standard/829-1983.html

http://www.slideshare.net/galo_priva/mtricas-del-proceso-y-proyecto-procesos-de-ingeniera-de-software-372897

http://www.slideshare.net/galo_priva/mtricas-del-proceso-y-proyecto-procesos-de-ingeniera-de-software-372897

http://www.fi.unju.edu.ar/materias/materia/SI2/document/Clase_20-may-2009/SIII2009_-_Metricas_de_Proceso_y_Proyecto.pdf?cidReq=SI2

http://www.fi.unju.edu.ar/materias/materia/SI2/document/Clase_20-may-2009/SIII2009_-_Metricas_de_Proceso_y_Proyecto.pdf?cidReq=SI2

http://nathanj.github.com/gitguide/tour.html

http://chuwiki.chuidiang.org/index.php?title=Ejemplo_sencillo_de_creaci%C3%B3n_de_un_pdf_con_iText

http://chuwiki.chuidiang.org/index.php?title=Ejemplo_sencillo_de_creaci%C3%B3n_de_un_pdf_con_iText

Tesis Digital AMRV

Documents

Transcript of Tesis Digital AMRV