herramienta automática de planificación y control de...
TRANSCRIPT
Herramienta automática de planificación y control de proyectos (Test Management Tool)
Trabajo fin de grado con información confidencial
Versión pública
TITULACIÓN: Grado en Ingeniería electrónica y automática industrial
AUTOR: Laura Fontanet Bujaldón DIRECTOR: Enric Vidal Idiarte
FECHA: Abril / 2014
Este conta
Albe
apam
documentoactar con:
ert Pàmies –
o contiene ap
– Lear Corpo
com
partados e i
oration Hol
imágenes co
lding Spain
onfidencialees, para máss informacióón,
Herramienta automática de planificación y control de proyectos (Test Management Tool)
ÍNDICE GENERAL
AUTOR: Laura Fontanet Bujaldón DIRECTOR: Enric Vidal Idiarte
FECHA: Abril / 2014
2
ÍNDICE GENERAL
1 MEMORIA DESCRIPTIVA ............................................................................ 7 1.1 La empresa ................................................................................................... 7
1.2 Motivación ................................................................................................... 9
1.3 Introducción al proyecto .............................................................................. 9
1.4 Objetivo del proyecto ................................................................................. 10
1.5 ¿Qué es Test Management Tool? ............................................................... 11
1.6 Fase de análisis .......................................................................................... 11
1.6.1 V-MODEL (Modelo de desarrollo de un Software) .............................. 12
1.6.2 Proceso de System Test .......................................................................... 13
1.6.3 Apartado confidencial ............................................................................ 16
1.6.4 Apartado confidencial ............................................................................ 16
1.6.5 Aporte de la herramienta al proceso de System Test ............................. 16
1.7 Orden de prioridades .................................................................................. 18
2 MEMORIA DE CÁLCULO ........................................................................... 21
2.1 Tecnologías y herramientas utilizadas ....................................................... 21
2.1.1 JAVA ...................................................................................................... 21
2.1.2 JavaScript ............................................................................................... 21
2.1.3 ECLIPSE ................................................................................................ 22
2.1.4 NETBEANS ........................................................................................... 22
2.1.5 MySQL ................................................................................................... 23
2.1.6 JIRA ....................................................................................................... 24
2.1.7 Microsoft Project .................................................................................... 28
2.1.8 Microsoft Office Visio ........................................................................... 28
2.2 Diseño ........................................................................................................ 29
2.2.1 Caso de uso y diagrama de flujo ............................................................ 33
2.2.2 Diseño de la capa de datos ..................................................................... 35
2.2.3 Apartado confidencial ............................................................................ 36
2.2.4 Diseño de la capa de business ................................................................ 36
2.3 Implementación.......................................................................................... 37
2.3.1 Desarrollo de la capa datos .................................................................... 37
2.3.2 Apartado confidencial ............................................................................ 40
2.3.3 Apartado confidencial ............................................................................ 40
2.4 Apartado confidencial ................................................................................ 40
2.5 Dificultades encontradas ............................................................................ 41
3
2.6 Verificación de funcionamiento ................................................................. 41
2.7 Siguientes pasos ......................................................................................... 41
2.8 Conocimientos aportados del proyecto ...................................................... 42
2.8.1 Personalmente ........................................................................................ 42
2.8.2 Profesionalmente .................................................................................... 42
3 PLIEGO DE CONDICIONES ....................................................................... 45
3.1 Objetivo ..................................................................................................... 45
3.2 Materiales ................................................................................................... 45
3.3 Condiciones Generales............................................................................... 45
3.4 Condiciones Económicas ........................................................................... 45
3.5 Condiciones de Seguridad ......................................................................... 45
3.6 Limitación de responsabilidad ................................................................... 46
4 ESTADO DE MEDICIONES ......................................................................... 49
4.1 Definición del hardware utilizado .............................................................. 49
4.2 Entornos de programación y programas utilizados .................................... 49
5 PRESUPUESTO .............................................................................................. 52
5.1 Presupuesto FASE I. Definición del equipo e instalación ......................... 52
5.2 Presupuesto FASE II. Diseño de la herramienta ........................................ 52
5.3 Presupuesto FASE III. Implementación de la herramienta ........................ 53
5.4 Presupuesto FASE IV. Formación usuarios .............................................. 53
5.5 Resumen ..................................................................................................... 54
6 ESTUDIO CON ENTIDAD PROPIA ........................................................... 57
6.1 Estudio de salud y seguridad en el trabajo ................................................. 57
6.1.1 Obligaciones en Materia de Prevención de Riesgos Laborales .............. 57
6.1.2 Como comunicar una situación de riesgo .............................................. 57
6.1.3 Funciones de los recursos preventivos ................................................... 57
7 ANEXOS .......................................................................................................... 61
7.1 Conclusiones .............................................................................................. 61
7.2 Agradecimientos ........................................................................................ 61
7.3 Bibliografía ................................................................................................ 61
Herramienta automática de planificación y control de proyectos (Test Management Tool)
MEMORIA DESCRIPTIVA
AUTOR: Laura Fontanet Bujaldón DIRECTOR: Enric Vidal Idiarte
FECHA: Abril / 2014
6
ÍNDICE MEMORIA DESCRIPTIVA
1 MEMORIA DESCRIPTIVA ............................................................................ 7 1.1 La empresa ................................................................................................... 7
1.2 Motivación ................................................................................................... 9
1.3 Introducción al proyecto .............................................................................. 9
1.4 Objetivo del proyecto ................................................................................. 10
1.5 ¿Qué es Test Management Tool? ............................................................... 11
1.6 Fase de análisis .......................................................................................... 11
1.6.1 V-MODEL (Modelo de desarrollo de un Software) .............................. 12
1.6.2 Proceso de System Test .......................................................................... 13
1.6.3 Apartado confidencial ............................................................................ 16
1.6.4 Apartado confidencial ............................................................................ 16
1.6.5 Aporte de la herramienta al proceso de System Test ............................. 16
1.7 Orden de prioridades .................................................................................. 18
1
1.1
fabriaviónindus
energventaprodufabriemplSouthcon i
activ
baterentonlabor
con Presi
siguidepa
MEMOR
La empreLear fue f
cante de tubn. Desde enstria con 18
Hoy en dígía eléctricaas fueron deuctos, a ncados por leados en 2hfield, Micinstalacione
Lear Corpvidades Side
En Lear Crías para cnces hablamral actual.
A continuel Presiden
identes.
A nivel diente. Lear artamento de
RIA DES
esa fundada en bular, ensamntonces, han8 grandes ad
ía, ofrecen a en todo ee 14.6 mil mnivel mund
un divers221 localizchigan, Lees en 36 país
poration conerometalúrg
Corporation coches elécmos de un
uación se mnte de Lea
F
de departamCorporatio
e Software,
CRIPTIV
1917 en Demblajes soldn ido creciedquisiciones
sistemas deel mundo. Emillones de dial, son do equipo
zaciones. Cear continúses de todo
n sede en Vgicas.
fabrican coctricos, cara empresa
muestra un oar, el Sr.
Figura 2. Organ
mentos, el oon dispone de Hardwa
VA
etroit, Michdados y sellendo para sas desde que
e gestión dEn 2012 ladólares. Su
diseñados yde 115.000
Con sede enúa operando
el mundo.
Valls, realiz
omponentesrgadores…
multinacio
organigramaMatt Simo
nigrama general
organigramde un dep
are, Electrom
7
higan comolados para laatisfacer lasLear salió a
e as us y 0 n o
a
s de automópara difer
onal muy b
a general doncini segu
l de Lear Corpo
ma general spartamento mecánico, L
Fi
American as industriass necesidadea bolsa en 1
óvil, como arentes marbien recono
e la empresuido de Pr
oration
se represende ingenie
Laboratorio…
igura 1. Imagen
Metal Prodas del automes cambian1994.
asientos, cenrcas de auocida en el
sa a segundresidentes y
ntaría en laería compue…
n ilustrativa
ducts, un móvil y el
tes de la
ntralitas, utomóvil, l mundo
do nivel, y Vice
imagen esto por
realizmuesLear
funcipasan
Por otra pzando el prstra un orga.
La misiónionamiento ndo por la i
Figura 3.
parte, el orgroyecto, es anigrama co
Figura
n del depade los pr
dea, la crea
Organigrama a
ganigrama cel departa
orrespondie
4. Organigram
artamento drogramas s
ación, el pro
a nivel de depar
correspondiamento de Sente al depa
ma departamento
de softwarsoftware inoceso de test
8
rtamentos de Le
iente al depSoftware &artamento d
o software Lear
e es princnstalados ent y finalmen
ear Corporation
partamento & Systems. de software
Corporation
ipalmente n cada disnte la entreg
n
donde se hA continua nivel de
velar por spositivo haga a cliente.
ha estado ación se tutor de
el buen ardware, .
imagel mu
basta
1.2
con euna boportmate
1.3
recopdatosManaSW-
difertesteadocu(tiemrealizcostaempl
Lear Corpgen mapa-mundo.
Como poante extensa
MotivacióLa posibil
el plus de abase de dattunidad de
eria, hace qu
IntroduccNos situa
pilación de s actualmenagement Li132, que má
Software Vrentes proyeando en es
umento, adempo invertidzar cotizaciarle validar learía un cie
poration opemundi donde
Figu
odemos vera.
ón lidad de trabaprender a ptos MySQLtrabajar co
ue la decisió
ción al proyamos en el
datos de tente se recogst, estandarás adelante
Validation ectos de Lse momentmás, recoge
do, estado diones a cliuna fase y
erto número
era en todoe los círculo
ura 5. Extensió
r, estamos
bajar en unprogramar eL, conocer lon gente quón de realiza
yecto departame
esteo del sofgen mediantrizado por Lprocederem
Managemenear para lleto y hacer e unas métrde la fase, gente. Por eLear media
o de horas, c
os los continos represent
ón a nivel mund
hablando
n proyecto qen JAVA y los procesoue tiene muar este proy
ento de Software y hate un docum
Lear en el prmos a explic
nt List, es uevar un comejores p
ricas, es decgrado de auejemplo, unante este docon esto, pu
9
nentes. A ctan las sede
dial de Lear Cor
de una em
que será de JavaScipt,
s usados poucha experiyecto sea mu
ftware. Leaardware desmento Exceroceso de tecar.
un documenontrol de laplanificacioncir, datos quutomatización cliente prcumento es
ueden realiz
continuaciónes de Lear C
rporation
mpresa a n
gran utilidallegar a con
or Lear, y aiencia y conuy enriquec
ar dispone arrollado enl llamado S
esteo como
nto de proca fase del pnes de sigu
ue se recogeón…) y tamregunta a Lstima que paar cotizacio
n podemos Corporation
nivel Multi
ad para la enocer cómoal mismo ti
onocimientocedora.
de un pron la empres
Software Vadocumento
ceso, y es usproyecto quuientes fas
en a lo largombién es usaLear cuántoara la fase dones.
ver una n en todo
nacional
empresa, o utilizar iempo la
o en esta
oceso de sa. Estos alidation SVML-
sado por ue están
ses. Este o del test ado para o podría de testeo
10
Por otra parte, Software Validation Management List, es rellenado manualmente por las personas que toman parte en el proceso de test, como son los System Test Engineers, encargados de testear los requerimientos del sistema, y los System Test Leaders, encargados de la gestión del proyecto de system test.
Como este documento es rellenado manualmente, se emplea mucho tiempo en rellenar los datos en Software Validation Management List.
Seguidamente, el documento es compartido entre todas las personas que toman parte en el proceso de test y el documento se rellena al finalizar todas estas tareas.
Finalmente, cada proyecto adapta este documento a sus necesidades, es decir, no todos los proyectos lo rellenan de la misma manera, disponen de diferentes datos a rellenar. Además de las complicaciones en la compartición del archivo que nos encontramos cuando todos los componentes del equipo quieren acceder a él para su actualización.
1.4 Objetivo del proyecto Pues bien, conocido a grandes rasgos el proceso utilizado por Lear en el proceso de
test, podemos proceder a definir el objetivo del proyecto.
El objetivo del proyecto es eliminar el proceso manual de obtención de datos y planificación, por dos razones de peso. La primera es a causa de que no todos los proyectos rellenan el documento de la misma manera, disponen de diferentes datos a rellenar. La segunda, obtener un proceso automático, es decir, eliminar el documento Software Validation Management List del proceso y utilizar otro método, un método automático, y común de recopilación de datos de testeo para todos los proyectos, para así ganar eficiencia, ya que los System Test Leaders y System Test Engineers no deberán ir a rellenar este documento, la información se recogería automáticamente de diferentes fuentes de datos.
Por otra parte también se ganaría consistencia en los datos, ya que el System Test Engineer, al rellenar los datos del documento al final de realizar todas las tareas, podría ser que no se acordase exactamente de algunos de los datos de las tareas anteriores. Con el proceso automático esto no pasa, se recogerían los datos en tiempo real.
El proceso automático consiste en una herramienta que recoge los datos de diferentes sitios como bases de datos, entre otros y los muestra visualmente en una aplicación web, es decir una página web. Esta herramienta lleva por nombre Test Management Tool.
y gande re
1.5
Corptenerdiferfase, medirecogaplicconsilos dseguieficie
1.6
softwdepa
este m
Con Test Mnaríamos efecopilación
¿Qué es TTest Man
poration Hor conocimierentes fases
grado de iante un dogida y mancación Testistencia en datos son idamente mencia en el p
Fase de anComo hem
ware. Se hizartamento de
Para tenermodelo de d
F
Managemenficiencia en de datos pa
Test Managagement To
olding Spainento del esde los proy
automatizacocumento llanipulación dt Managemlos resultadobtenidos
mostrados enproceso de
nálisis mos comentzo un estudie Software &r claros los desarrollo d
Figura 6. Detal
nt Tool obteel proceso y
asarían a ser
gement Tooool es una n, con basestado de layectos. Antción…) se amado Softde datos se
ment Tool, cdos, ya que n
directamenn una págintest.
tado anterioio y se vio& systems econceptos
de un softwa
lle gráfico del o
endremos uya que estor automático
ol? herramient
e visual en a planificacteriormente mostraban
tware Validha querido
con el objno se precisnte de la
na web. De e
ormente, elel modelo den Lear Coexplicados are para un
11
objetivo del pro
n proceso cs procedimios.
ta software página we
ión, implemlos datos (y recogían
dation Manao automatizetivo de apsa un documbase de d
esta manera
proyecto sde desarroll
orporation. a lo largo dproyecto, e
yecto
común para ientos actua
interna parb, surgida mentación y(tiempo invn manualmeagement Lizar mediantportar efici
mento el cuadatos, entrea se consigu
se sitúa en lo de un pro
del proyectol modelo en
todos los pralmente man
ra la emprede la necesy ejecución
vertido, estaente por emist. Este prote la creacióiencia, veraal rellenar, se otros lugue automati
el departamoyecto usad
to debemos n V (V-Mod
royectos nuales
esa Lear sidad de n de las
ado de la mpleados oceso de ón de la acidad y si no que gares, y zación y
mento de do por el
conocer del).
12
1.6.1 V-MODEL (Modelo de desarrollo de un Software)
Como hemos comentado anteriormente, el proyecto se sitúa en el departamento de software & Systems. Entonces para tener claros los conceptos explicados a lo largo del proyecto debemos conocer las fases de desarrollo de un software para un proyecto como por ejemplo JLR, Renault (RSA), FORD, VOLVO, entre otros, de Lear Corporation. Concretamente el modelo del cual hablaremos a continuación es usado por esta empresa.
1.6.1.1 Descripción general
El Método-V define un procedimiento uniforme para el desarrollo de productos. Es el estándar utilizado para los proyectos de la Administración Federal y de defensa alemana y fue desarrollado para regular los procesos de desarrollo de software. Como está disponible públicamente muchas compañías lo usan, una de ellas, Lear Corporation. Es un método de gestión de proyectos y describe tanto métodos para la gestión como para el desarrollo de sistemas. Es una representación gráfica que representa la secuencia de pasos en el desarrollo del ciclo de vida de un proyecto y se describen las actividades y resultados que deben producirse durante el desarrollo del producto, empezando por los requerimientos de cliente (especificaciones para la realización del producto) y acabando por la verificación y validación del producto, para la entrega a cliente.
El modelo proporciona una guía para la planificación y realización de proyectos. Los siguientes objetivos están destinados a ser alcanzados durante la ejecución del proyecto:
1.6.1.1.1 Minimización de los riesgos del proyecto
Mejora la transparencia y control del proyecto. Permite una detección temprana de desviaciones y mejora la gestión de procesos, reduciendo así los riesgos del proyecto.
1.6.1.1.2 Mejora y Garantía de Calidad
Como un modelo de proceso estándar, asegura que los resultados que se proporcionan sean completos y contengan la calidad deseada. Los resultados provisionales definidos se pueden comprobar en una fase temprana. La uniformidad en el contenido del producto mejora la legibilidad, comprensibilidad y verificabilidad.
1.6.1.1.3 Reducción de los gastos totales durante todo el proyecto y sistema de Ciclo de Vida
El esfuerzo para el desarrollo, producción, operación y mantenimiento de un sistema puede ser calculado, estimado y controlado de manera transparente mediante la aplicación de un modelo de procesos estandarizados, reduciendo la dependencia en los proveedores y el esfuerzo para las siguientes actividades y proyectos.
13
1.6.1.1.4 Mejora de la comunicación entre todos los inversionistas
La descripción estandarizada y uniforme de todos los elementos pertinentes y términos es la base para la comprensión mutua entre todos los inversionistas. De este modo, se reduce la pérdida por fricción entre el usuario, comprador, proveedor y desarrollador.
1.6.1.2 Apartado confidencial
Este apartado es confidencial, si desea más información, contactar con:
Albert Pàmies (Lear Corporation Holding Spain)
Enric Vidal (Universitat Rovira i Virgili)
1.6.2 Proceso de System Test
Como se ha comentado anteriormente, Lear Corporation sigue el modelo V de desarrollo de un software y para situarnos, nos fijamos concretamente en la parte superior derecha, en System Tests.
A continuación se procederá a explicar el proceso de System Test utilizado en Lear Corporation, pasando por uno de los documentos utilizados en el proceso, como el documento Software Validation Management List, estandarizado en el documento SVML-SW-132 del proceso de test, que más adelante se explicará, como también las inputs y las outputs del proceso pasa validar una fase de un proyecto. Para entender esto hay que saber que cada cliente (JLR, VOLVO, Renault (RSA), FORD… entre otros) tiene diferentes proyectos y cada proyecto tiene diferentes fases que tienen que ser validadas mediante el proceso de System Test que se explicará a continuación.
1.6.2.1 Propósito del proceso de System Test
El propósito del proceso de System Test es asegurar que la implementación de cada requisito del sistema es testeado por cumplimiento, garantizando que el sistema cumple con las expectativas del cliente y el sistema está listo para la entrega.
1.6.2.2 Objetivos
1.6.2.2.1 Objetivos cualitativos
• El sistema se prueba para verificar que cumple los requisitos del sistema.
1.6.2.2.2 Objetivos cuantitativos
• El 100% de los requisitos del sistema son testeados / probados.
14
1.6.2.3 Explicación en detalle de las actividades llevadas a cabo en el proceso de System Test en Lear Corporation:
El proceso de System Test se divide en un conjunto de actividades definidas. A continuación se muestra la explicación detallada de cada una de las actividades llevadas a cabo en el proceso de System Test de Lear Corporation:
1.6.2.3.1 Definir la estrategia del proceso de System Test
El System Test Leader conjuntamente con el jefe de equipo de software y el jefe de equipo de hardware debe definir y documentar una estrategia de System Test, que define los tests que se van a realizar y en que nivel del producto. Esto típicamente se documenta en los documentos de System Test – System Test Concept ( STC - SW- 301 ) o en el SPP – Software Project Plan ( SW- SPP - 120 ). Estos son documentos que forman parte en esta actividad del proceso de System Test.
1.6.2.3.2 Planear el proceso de System Test
Al igual que cualquier otro aspecto de la gestión de proyectos, se deben planificar las actividades de test. Los aspectos clave de la planificación de controles incluyen la coordinación del personal, gestión de las instalaciones de ensayo y equipos disponibles (que pueden incluir medios magnéticos, planes de prueba y procedimientos), y la planificación de posibles resultados indeseables. Si se mantiene más de una línea de base de software, seguidamente, una consideración importante de planificación es el tiempo y el esfuerzo necesario para asegurar que el entorno de test se realiza en la configuración adecuada. La planificación del proceso de System Test se realiza normalmente en el documento Project Timing Plan (SPS- SW- 130) y en Software Validation Management List (SVML -SW -132). Estos son documentos que forman parte en esta actividad del proceso de System Test y concretamente nos centraremos en el documento Software Validation Management List (SVML -SW -132), que es el proceso manual actual que queremos sustituir por el proceso automático. Más adelante se explicará este documento.
1.6.2.3.3 Preparar el entorno de System Test / Set-Ups
Sobre todo en las primeras fases del proyecto, se deben preparar los equipos, las herramientas y las instalaciones para la realización de los tests. Según el plan, la estrategia de System Test del proyecto definido y la planificación del tiempo del proyecto, el jefe de proyecto tiene la responsabilidad de asegurar que las herramientas, equipos e instalaciones necesarias para el proceso de System Test estarán en su lugar .
El entorno utilizado para los tests debería ser compatible con las herramientas de ingeniería de software. Se debe facilitar el desarrollo y el control de las tareas, así como el registro y la recuperación de los resultados esperados, scripts y otros materiales de test.
1.6.2.3.4 Definir las especificaciones del proceso de System Test
15
La generación de las tareas de testeo se basa en el nivel de los testeos a realizar y las técnicas de ensayo particulares. Las tareas de test deben estar bajo el control de la gestión de configuración de software e incluir los resultados esperados para cada test.
Los grupos de proyectos definirán las especificaciones de System Test para verificar los requisitos del sistema.
Las especificaciones de System Test deberán:
Describir los tests que se utilizan para verificar los requisitos del sistema Referenciar las tareas a testear a los requisitos del sistema que se verifican, es
decir, cada tarea debe estar relacionada con un requisito definido por cliente Definir el resultado esperado del test para ser aprobado o no aprobado Definir las condiciones set-up/entorno para ejecutar los tests
1.6.2.3.5 Revisión de los requisitos del proceso de System Test
Se realiza una revisión con el fin de verificar la exactitud de las especificaciones del proceso de System Test.
1.6.2.3.6 Planear el proceso de ejecución del proceso de System Test
Utilizando como entrada la información sobre los cambios aplicados en el proceso y la evaluación de riesgos realizada para identificar el alcance de System Test, un plan más detallado será hecho para la fase de ejecución del proceso de System Test. Este plan deberá ser parte de la planificación en el Project Timing Plan (SPS-SW-130). Algo parecido al documento Software Validation Management List (SVML-SW-132).
1.6.2.3.7 Realizar el proceso de System Test
Los tests del proceso de System Test se llevan a cabo de acuerdo con la estrategia definida de System Test y el plan del proyecto. Todo lo hecho durante la ejecución de los tests debe ser realizado y documentado con suficiente claridad para que otra persona pueda reproducir los resultados. Por lo tanto, los ensayos deberán realizarse con los procedimientos documentados y con las especificaciones de test, usando una versión claramente definida del sistema ( N º de pieza, versión de hardware, software, etc ...) .
1.6.2.3.8 Evaluar y realizar un informe de los resultados de System Test
Los resultados de los tests del proceso de System Tests deben ser evaluados para determinar si los tests han sido realizados con éxito. El éxito de los resultados quiere decir que el sistema testeado se comporta como se esperaba y no tiene en principio ningún resultado inesperado.
Las actividades de test se pueden introducir en un registro de test para identificar cuándo se llevó a cabo un test, quién realizó el test, qué configuración de software fue la utilizada para el test, y otras informaciones de identificativas. Los resultados de test inesperados o incorrectos serán documentados en el sistema de resolución de problemas del proyecto (Problem resolution system). Los informes (reports) de los tests se comunicarán a las partes afectadas.
16
En este proyecto nos centramos en el punto 3. Planear el proceso de System Test1 y sobretodo en el documento Software Validation Management List (SVML-SW-132). El documento de planificación usado en el proceso de System Test.
1.6.3 Apartado confidencial
Este apartado es confidencial, si desea más información, contactar con:
Albert Pàmies (Lear Corporation Holding Spain)
Enric Vidal (Universitat Rovira i Virgili)
1.6.4 Apartado confidencial
Este apartado es confidencial, si desea más información, contactar con:
Albert Pàmies (Lear Corporation Holding Spain)
Enric Vidal (Universitat Rovira i Virgili)
1.6.5 Aporte de la herramienta al proceso de System Test
Se realizaron varios estudios que serán comentados a continuación. Se vio un gran aporte de la herramienta al proceso de system test. Por una parte la herramienta aporta eficiencia al proceso y por otra parte consistencia en los datos obtenidos. Seguidamente se explicará detalladamente cada aporte.
1.6.5.1 Eficiencia
La herramienta aporta eficiencia por una serie de razones, una de ellas es que no tenemos que esperar a que los datos sean rellenados en un documento por todos los System Test Engineers al finalizar las tareas, si no que los datos son cogidos de diferentes sitios y posteriormente mostrados en una aplicación web que más adelante comentaremos.
Por otra parte, aporta eficiencia en tiempo de proceso. Se realizó un estudio preguntando a varios System Test Leaders y System Test Engineers cuánto tiempo gastaban en rellenar este documento, en rellenar los datos en él. Podemos ver a continuación una tabla con cada fase del proceso, separada por cada System Test Engineer y System Test Leader que fueron encuestados. Los System Test Leaders toman parte en la fase de planificación y los System Test Engineers toman parte en la fase de implementación y ejecución. El tiempo de relleno del documento por la parte de System Test Engineers depende mucho del número de tareas que tengan asignadas. Se muestran anónimamente.
1 Ver apartado 2.6.2.4.3
17
Las preguntas fueron: ¿Cuánto tarda en rellenar la fase de planificación un System Test Leader?, ¿Cuánto tarda en rellenar la fase de implementación un System Test Engineer?, ¿Cuánto tarda en rellenar la fase de ejecución un System Test Engineer?
System Test Leader Planificación
System Test Leader 1 4h
System Test Leader 2 3h
System Test Leader 3 5h
System Test Leader 4 4h
Figura 12. Tabla encuesta System Test Leaders
System Test Engineer Implementación Ejecución
System Test Engineer 1 1h 5h
System Test Engineer 2 2h 2h
System Test Engineer 3 1h 4h
System Test Engineer 4 3h 6h
System Test Engineer 5 2h 3h
System Test Engineer 6 3h 5h
Figura 13. Tabla encuesta System Test Engineers
Finalmente se muestra en la tabla siguiente una estimación media del tiempo empleado en rellenar los datos de cada fase, planificación, implementación y ejecución. Las fases de análisis y Formal Technical Review (fase de revisión), no se contemplan ya que estas tareas puede ser que no tengan que ser realizadas, solo hay revisiones si tenemos que revisar los casos de test, si no, no. Solo tendrían que añadir en un campo del documento, cuánto han tardado en revisar la tarea.
Proceso manual Proceso automático
(Software Validation Management List) (Test Management Tool)
Fase Fase
Planificación Implementación Ejecución Planificación Implementación Ejecución(h/System Test Leader)
(h/System Test Engineer)
(h/System Test Engineer)
(h/System Test Leader)
(h/System Test Engineer)
(h/System Test Engineer)
4 horas 2 horas 3 ‐ 5 horas ‐ ‐ ‐
Figura 14. Tabla eficiencia
Podemos observar que para el proceso manual, es decir, rellenar los datos en el documento; para la fase de planificación, un System Test Leader emplea aproximadamente unas 4 horas en planificar y distribuir todas las tareas entre System Test Engineers. Por otro lado, para la fase de implementación y ejecución, un System Test Engineer emplea aproximadamente 2 horas en rellenar los datos correspondientes a la fase de implementación y entre 3 y 5 horas en rellenar los datos de la fase de ejecución. Esto es por System Test Engineer y por System Test Leader, es decir, por persona, pero si multiplicamos estas horas por todas las personas que forman parte en la fase de test, podemos hacer una estimación de que se emplea mucho tiempo en rellenar el documento.
Por otro lado, para el proceso automático podemos observar que para la fase de planificación, el System Test Leader no debería emplear tiempo en rellenar ningún
18
documento, es decir, los datos se cogerían automáticamente de diferentes sitios. Y para la fase de implementación y ejecución, como los System Test Engineers ya registraban el tiempo que tardaban en hacer las tareas en JIRA, no deberán rellenar ningún documento ya que esta información se obtendría de JIRA directamente.
1.6.5.2 Consistencia
Con esta herramienta también ganamos consistencia en los datos obtenidos. Con Software Validation Management List, como se comparte este documento entre toda la gente que trabaja en el proyecto y se rellenan los datos al acabar todas las tareas, pierde consistencia.
Es decir, el System Test Engineer acaba una tarea y registra el tiempo que ha tardado en hacerla en JIRA, empieza con otra tarea, la acaba y registra el tiempo, así sucesivamente con todas las tareas que tenga asociadas. Cuando ha acabado todas las tareas, va a rellenar el documento y podría ser que la tarea que había realizado hace dos semanas no se acordase realmente lo que habría tardado y aquí podria haber contradicciones en los datos.
Con Test Management Tool solventamos este problema ya que los datos se obtendrían en tiempo real. Este registra el tiempo en JIRA de la tarea que está realizando y la herramienta coge automáticamente el estatus de esta, si está acabada o no y el tiempo que lleva registrado. Es decir, se obtienen los datos en tiempo real.
Por último, este documento también se utiliza para hacer cotizaciones a cliente. Con la suma total de horas podemos hacer una planificación y una cotización a cliente de una fase de test, se cotizarían el número de horas empleadas en realizar la fase de test. Entonces con Test Management Tool, como los datos se obtienen en tiempo real, las cotizaciones y estimaciones son más realistas y el problema de la poca consistencia se soluciona.
1.7 Orden de prioridades El orden de prioridades de los documentos del proyecto es el siguiente:
1. Presupuesto 2. Memoria descriptiva 3. Memoria de cálculo 4. Pliego de condiciones 5. Estado de mediciones 6. Estudios con entidad propia
Tarragona, 27 de Abril de 2014
Firmado: Laura Fontanet Bujaldón
Ingeniera en Electrónica y Automática Industrial
Herramienta automática de planificación y control de proyectos (Test Management Tool)
MEMORIA DE CÁLCULO
AUTOR: Laura Fontanet Bujaldón DIRECTOR: Enric Vidal Idiarte
FECHA: Abril / 2014
20
ÍNDICE MEMORIA DE CÁLCULO
2 MEMORIA DE CÁLCULO ........................................................................... 21 2.1 Tecnologías y herramientas utilizadas ....................................................... 21
2.1.1 JAVA ...................................................................................................... 21
2.1.2 JavaScript ............................................................................................... 21
2.1.3 ECLIPSE ................................................................................................ 22
2.1.4 NETBEANS ........................................................................................... 22
2.1.5 MySQL ................................................................................................... 23
2.1.6 JIRA ....................................................................................................... 24
2.1.7 Microsoft Project .................................................................................... 28
2.1.8 Microsoft Office Visio ........................................................................... 28
2.2 Diseño ........................................................................................................ 29
2.2.1 Caso de uso y diagrama de flujo ............................................................ 33
2.2.2 Diseño de la capa de datos ..................................................................... 35
2.2.3 Apartado confidencial ............................................................................ 36
2.2.4 Diseño de la capa de business ................................................................ 36
2.3 Implementación.......................................................................................... 37
2.3.1 Desarrollo de la capa datos .................................................................... 37
2.3.2 Apartado confidencial ............................................................................ 40
2.3.3 Apartado confidencial ............................................................................ 40
2.4 Apartado confidencial ................................................................................ 40
2.5 Dificultades encontradas ............................................................................ 41
2.6 Verificación de funcionamiento ................................................................. 41
2.7 Siguientes pasos ......................................................................................... 41
2.8 Conocimientos aportados del proyecto ...................................................... 42
2.8.1 Personalmente ........................................................................................ 42
2.8.2 Profesionalmente .................................................................................... 42
2
2.1
JavaSdatoscontiprogr
2.1.1
herra
propóclasedepees pprogr(conoanywejecupartirparticusuar
2.1.2
capa
de ECMproto
cliennaveaunqSSJSaplic
conv
planif
MEMOR
TecnologíLas tecno
Script, los es se ha realiinuación prramación.
1 JAVA
Java ha amienta Tes
Java es uósito gener
es que fue ndencias deermitir querama una ocido en i
where"), lo utado en unr de 2012cularmente rios reporta
2 JavaScrip
JavaScriptvisual de la
JavaScriptprogramac
MAScript. Sotipos, impe
Se utilizante (client-gador web
que existe uS). Su uso caciones de
JavaScriptvenciones de
2 Las tareas
ficación con M
RIA DE C
ías y herraologías y hentornos deizado con enrocedemos
sido el lst Managem
un lenguajeral, concurr
diseñado e implemene los desarvez y lo einglés com
que quierna plataform2, uno de
para aplicados.
pt
t ha sido ela herramien
t (abreviadoción interpSe define coerativo, déb
a principalmside), implpermitiend
una forma en aplicac
escritorio (m
t se diseñóel lenguaje
s son subidas
Microsoft Proj
CÁLCUL
mientas utierramientase programacntorno MySa explicar
enguaje utment Tool.
e de prograrente, orienespecíficam
ntación comrrolladores ejecuten en
mo WORA,re decir q
ma no tiene e los lengaciones de
l lenguaje unta Test Man
o comúnmepretado, domo orientailmente tipa
mente en sulementado
do mejoras de JavaScr
ciones extermayoritaria
ó con una de program
s a JIRA conect y gracias a
2
LO
ilizadas s utilizadasción EclipsSQL y la her cada una
tilizado pa
amación mntado a objmente para
mo fuera posde aplicac
n cualquier , o "write
que el códque ser rec
guajes de cliente-ser
utilizado panagement T
ente "JS") edialecto dado a objetoado y dinám
u forma decomo paren la inter
ript del ladrnas a la w
amente widg
sintaxis simación Java
n Microsoft Pa un script sub
21
en el proye y Netbearramienta d
a de estas
ara desarro
multiplataformjetos y basa tener tansible. Su intciones escri
dispositivoe once, runigo que ecompilado programaci
rvidor de w
ara elaborar Tool.
es un lenguadel estándos, basado
mico.
el lado del rte de un rfaz de usuado del serviweb, por egets) es tam
imilar al Ca. Sin embar
Project, ya qube las tareas a
yecto son ens, el desar
de control deherramient
ollar la
ma, de ado en
pocas tención iban el o n s para correrión más p
web, con un
la
aje dar en
ario y páginidor (Serverejemplo en
mbién signifi
C, aunque rgo Java y
ue el System a JIRA automá
Fig
Figura
el lenguajerrollo de la e tareas es Jtas y lengu
r en otra. Japopulares nos 10 mill
inas web dier-side Java
documentoicativo.
adopta nomJavaScript
Test Leader áticamente.
gura 15. Image
a 16. Imagen Ja
e JAVA, base de
JIRA2. A uajes de
ava es, a en uso, lones de
inámicas aScript o os PDF,
mbres y no están
realiza el
en JAVA
avaScript
relacincru
2.1.3
utilizbusinTool
compprogrpara “AplplatadesaringléDeveque usado
nuest
2.1.4
utilizherra
integprincJava.móduprodu
gran comu100 fundóde 20
un coque cespecpartirmódu
cionados y ustado en len
3 ECLIPSE
Eclipse hazado para ness de lal.
Eclipse puesto por ramación d
desarrollalicaciones aforma, típrrollar entoés IDE), coelopment Tse entrega os también
Como se htras necesid
4 NETBEAN
NetBeans zado para amienta Tes
NetBeans grado libre,cipalmente . Existe aulos para ucto libre y
NetBeans éxito con
unidad en csocios en
ó el proyect000 y contin
La platafoonjunto de ccontiene clacial (manifr de módululos puede
tienen semánguaje HTM
E
a sido el endesarrollar
a herramien
es un pun conjun
de código aar lo quede Cliente
picamente rnos de des
omo el IDEToolkit (JDT
como partpara desarr
ha usado el dades.
NS
ha sido el desarrollar
st Managem
es un , entorno dpara el len
además un extenderlo.
y gratuito sin
es un proyn una granconstante cre
todo el mto de códigonúa siendo e
orma NetBecomponenteases de javafest file) qulos pueden n ser desa
ánticas y pML.
ntorno de prla capa
nta Test M
programa nto de herraabierto multe el proye Enriquecha sido u
sarrollo intede Java ll
T) y el comte de Ecliprollar el mis
lenguaje jav
entorno de r la capa
ment Tool.
entorno dde programnguaje de
número iNetBeans
n restriccion
ecto de códn base de ecimiento, y
mundo. Suno abierto Nel patrocina
eans permitees de softwaa escritas paue lo identiser extendirrollados in
2
propósitos d
rogramaciónde datos y
Managemen
informáticoamientas detiplataforma
yecto llamacido”. Estausada paraegrados (delamado Javampilador (Epse (y que smo Eclipse
va, Eclipse
programacvisual de
de desarromación, hec
programacimportante
IDE2 es nes de uso.
digo abiertousuarios, uy con cercan MicroSyetBeans en
ador princip
e que las aare llamado
ara interactuifica como idas agregánndependien
22
diferentes. J
n y
nt
o e a a a a
el a
ECJ) son
e).
ha sido la i
ión la
ollo cho ión de un
de una a de stems junio
pal de los pr
plicacionesos módulos. uar con las A
módulo. Lndole nuev
ntemente, la
Fi
Fig
JavaScript u
nterfaz que
oyectos.
sean desarUn módulo
APIs de NetLas aplicacios módulosas aplicacio
igura 17. Imag
gura 18. Imagen
usa lenguaj
mejor se aj
rrolladas a po es un archtBeans y uniones consts. Debido aones basada
gen logo Eclipse
n logo NetBean
e JAVA
justaba a
partir de hivo Java n archivo truidas a a que los as en la
e
ns IDE
platasoftw
comode laincru
2.1.5
desarconcdatosTool
de da
más —deMicrMyS
licendebedesar
comuMySdel mencservivía IWide
Goog
aforma Netware.
La obtenco applets deas páginas ustado en H
5 MySQL
MySQL hrrollar la cretamente s con la capl.
MySQL eatos relacio
de seis miesde enero rosystems ySQL como s
Por un ladncia, pero pn comprar rrollado en
Al contrarunidad públ
SQL es patrocódigo. Escionado. Adicios. Para sInternet. Menius.
MySQL egle (aunque
A continu
3 Licencia P
tBeans pue
ción de los e Java que visuales, seTML, algo
ha sido el capa de datla comunicpa de datos
es un sistemonal, multih
llones de inde 2008
y ésta a su software libr
do se ofrecpara aquella
a la empsu mayor p
rio de proylica y los deocinado porsto es lo demás de lsus operacio
MySQL AB
es usado poe no para bú
ación podem
ública Genera
eden ser ex
datos se rease ejecutane realiza mparecido al
entorno utitos de la hcación de s de Test M
ma de gestióhilo y multi
nstalacionesuna subsidvez de Or
re en un esq
ce bajo la Gas empresasresa una larte en ANS
ectos comoerechos de r una empreque posibila venta deones contra
fue funda
or muchos úsquedas), F
mos observa
al de GNU. Li
2
xtendidas f
aliza median en servidomediante arcl lenguaje de
ilizado paraherramientala base de
Managemen
ón de baseiusuario con
s. MySQL diaria de racle Corpoquema de lic
GNU GPL3
s que quierlicencia espSI C.
o Apache, dautor del có
esa privada,ilita el esq
e licencias patan trabajadado por Da
sitios webFacebook, T
ar el entorn
icencia de Sof
23
fácilmente
ante servletsores, códigochivos con e progamac
a a, e
nt
s n
AB Sun
oration desdcenciamien
3 para cualqran incorpopecífica qu
donde el sofódigo están, que posee quema de privativas, dores alredeavid Axmar
b grandes yTwitter, Flic
no de usuari
ftware Libre
Fi
por otros
s, clases quo java puro,
formato .jción php.
de abril deto dual.
quier uso corarlo en pre les perm
ftware es den en poder d
el copyrighlicenciamiela compañíedor del murk, Allan L
y populareskr y YouTu
o de MySQ
igura 19. Image
desarrollad
ue pueden s, y la progrsp, de cód
e 2009— d
compatible roductos pr
mita este u
esarrollado del autor indht de la mayento anteriía ofrece soundo que coLarsson y
s, como Wiube.
QL.
en logo MySQL
dores de
er vistas ramación ido java
esarrolla
con esta rivativos so. Está
por una dividual, yor parte iormente oporte y olaboran Michael
ikipedia,
L
2.1.6
utilizEngirealizestos
6 JIRA
Jira es unzada por Sneers para lzadas. Las s donde se e
El worksp
na herramieSystem Tellevar un cotareas son
encuentra la
pace (entorn
Figu
nta de seguest Leadersontrol de las
denominada informació
no de trabajo
Figura 2
2
ura 20. Entorno
uimiento des y Systems tareas a redas tickets yón de cada t
o) de JIRA
22. Entorno de
24
o usuario MySQ
e tareas m Test alizar y y es en tarea.
se muestra
trabajo JIRA
QL
a continuac
Figura 21
ción:
1. Imagen logo
JIRA
JIRA
pantamás ú
persofunci
nece
atravtraba
diferproblasiste
cuad
El DashbA.
La barra dallas de JIRútiles de JIR
La zona bonalizar paión de sus á
Un proyesidades de s
Un Un Un Un Un
Un flujo dviesa durantajo de JIRA
Diferentesrentes tiposlema podríencia técnic
Se puede dro de mand
oard es la
de navegaciRA. ContienRA.
blanca de laara mostrar áreas de inte
ecto de JIRsu organiza
n proyecto dna campañan sistema den sistema den sistema de
de trabajo te su ciclo d:
s organizac de problema represent
ca, un formu
acceder a udos que perm
primera pá
ón (en la pane enlaces q
a pantalla, dde mucho
erés.
RA es una ción. Por ej
de desarrollode marketi
e helpdesk e gestión dee solicitud d
JIRA es el de vida. El
Figura
ciones, commas. Depentar un errorulario de so
un ticket demite acceder
2
ágina que ap
arte superioque le dan
debajo de los tipos dif
colección jemplo, un p
o de softwaing
e solicitudesde mejora pá
conjunto dsiguiente d
a 23. Flujo de tr
mo Lear ndiendo der de softwa
olicitud de li
e JIRA a par a las tarea
25
parece (por
or de la panacceso rápi
a barra de nferentes "ap
de temas, proyecto de
are
s de licenciaágina web
de estados ydiagrama m
rabajo JIRA
Corporatione cómo la oare, una taricencia, etc
artir de un ras.
defecto) de
ntalla) es el ido a much
navegaciónpartados" d
y se definee JIRA podr
a
y transicioneuestra una
n, usan JIorganizaciórea de proy
resultado de
espués de e
mismo en thas de las fu
n superior, sde informac
e de acuerdría ser:
es que un pfunción de
IRA para ón utiliza JIyecto, un b
e búsqueda
entrar en
todas las unciones
se puede ción, en
do a las
problema flujo de
rastrear IRA, un illete de
o de un
campSyste
admi
Un ticket pos, donde em Test Eng
El aspectoinistrador ha
En nuestro
Ticket cer
de JIRA npodemos
gineers deb
o de los ticka personaliz
o caso, los t
rrado (tarea
normalmentobservar enen registrar
Fig
kets de JIRzado JIRA p
tickets de ta
acabada):
Figura
2
te se mostran el primerr el tiempo.
gura 24. Entorn
RA puede papara su orga
areas tendría
25. Ticket de t
26
aría como r texto, Lo
no JIRA.
arecer diferanización.
an el aspect
tarea cerrado
se ve a conog work, qu
rente a la im
o siguiente:
ntinuación, ue sería do
magen anter
:
con sus onde los
rior si el
Podecorreha prrespo
tiempregisautom
2.1.6
Para proto
a tralenguSOA
cualqde loserviarquiestilodiferRPC
cond
Ticket abi
emos ver eespondienterogramado onsable.
Podemospo de trabastraría el timática, se m
6.1 Conectiv
conexionarocolo SOAP
El protocavés de meuaje. Está b
AP son docu
El protocquier interfaos protocoloicios web Sitectural REo de llamadrentes del té no es un ej
Son prodiciones de c
ierto (tarea s
en la partees al ticket y
para esa ta
s ver en la ajo, justo deempo que
mostraría en
vidad con Ji
rse con JiraP y el protoc
colo SOAP ensajes por basado en Xumento XML
colo REST az web simos basados OAP. Es po
EST y tambda a procedérmino RESjemplo de R
tocolos discada herram
sin finalizar
Figura
e superior y en la partearea, el resp
imagen anebajo del nha empled
n la parte de
ira
a, se han escolo REST.
es un protomedio de
XML y es lL propiame
en la actuample que util
en patronesosible diseñbién es posidimiento reST causan cREST.
stintos y semienta a util
2
r):
a 26. Ticket de t
el nombree derecha d
ponsable de
nterior, la dnombre del do en realizerecha como
studiado dif.
ocolo que peInternet. Ea base prin
ente dicho.
alidad se usliza XML ys de interca
ñar sistemasible diseñaremoto (RPCcierta confu
e tiene quelizar.
27
tarea abierto
e del tickedatos referen
la tarea, y
del ticket abticket Jira. zar la tareao tiempo reg
ferentes pro
ermite la coEs independncipal de los
a en el senty HTTP, sinambio de ms de servicior interfaces C), pero sinusión en las
e escoger e
t, en la pntes al tiemel tiempo r
bierto, el boAsí, el Sys
a y seguidagistrado.
otocolos de
omunicacióndiente de las Web Serv
tido más amn las abstra
mensajes comos web de acXMLHTTPn usar SOAs discusione
el que mejo
parte centrampo estimad
registrado p
otón de regstem Test Eamente, de
conexión,
n entre aplia plataformvices. Los m
mplio para dacciones adimo el proto
acuerdo con P de acuerdAP. Estos des técnicas,
or se adap
al, datos do que se por cada
gistrar el Engineer
manera
como el
caciones ma, y del mensajes
describir icionales ocolo de el estilo
do con el dos usos , aunque
pte a las
2.1.7
Test tareaEngidirec
desarel deadmi
proceProje
2.1.8
utilizManapodidpode
aplicIngenadqude lapasó desarprinc"propasí cobjetreside Ing
funda
7 Microsoft
Microsoft por los Sys
as que debenneers. Grac
ctamente los
Microsoft rrollado y cesarrollo deinistrar pres
El softwaredimientos ect Managem
8 Microsoft
Microsoft zado para reagement Todo visualiza
er realizar el
Aunque ocación para niería y A
uisición por a versión de
de añadidrrollo de pcipales hastperty line" tcomo el suptos en dibu
día en el mugenieros com
En sus oamental en
t Project
Project es ustem Test Len implemencias a un scrs tickets de
Project (o comercializae planes, asupuesto y a
re Microsofdescritos e
ment Institu
t Office Visi
Office Vealizar el disool. Medianar cómo qul diseño visu
originalmendibujo téc
ArquitecturaMicrosoft iVisio para
do a ser el planos de a antes de ltan útil paraprimir la caujos técnicoundo corporampitiendo c
orígenes se el análisis d
usado en eleaders, para
ntar y ejecutript, al ejeculas tareas a
MSP) es unado por Micsignación lanalizar carg
ft Office Pren el PMBoute.
io
Visio ha sseño de la hnte gráficosuedaría la hual final de
nte apuntabcnico para e; con añadimplicó drásMicrosoft Onúcleo ceIngeniería
la compra. a trabajos dearacterísticaos. Al pareativo de loson producto
aplicaba mde procesos
2
proceso dea planificar tar los Systeutarlo, se suJIRA.
n software crosoft paralos recursosgas de traba
roject es útioK (Projec
ido el entherramientas y tablas sherramienta
esta.
ba a ser unel campo ddidos para sticos cambOffice 2003
entral de ney Arquite
Una pruebae agrimensua de ghost ecer Micross negocios yos como Au
más al rams y operacio
28
System las
em Test uben
de administa asistir a ads a tareas, ajo.
il para la gt Managem
torno a Test se ha para
na de
desarrollarbios de direc3 el desarrolegocio, minectura que a de ello esura y localizshape que
soft decidióy no en las mutoCad, Des
mo de Ingnes en las e
Fig
Figura
tración de pdministradodar seguim
estión de prment Body o
r diagramactrices de tallo de diagrnimizando
se habíans la desaparzación de pufacilitaba l
ó que el fumesas de dibsignCad, Mi
geniería, peempresas.
gura 27. Imagen
a 28. Imagen log
proyectos dores de proymiento al p
royectos, apof Knowle
as de negoal forma queramas para nlas funcion
n mantenidrición de launtos por rala ubicaciónuturo del pbujo de Arqicrostation,
ero hoy en
n logo Microso
go Microsoft O
diseñado, yectos en progreso,
plicando dge) del
ocios, su e a partir negocios nes para
do como a función adiación, n de los
programa quitectos etc.
n día es
oft Project
Office Visio
29
2.2 Diseño Se investigó el método de como diseñar la herramienta. Finalmente se optó por usar
un diseño jerárquico e independiente, un diseño por capas, donde una capa no influye en la otra y se podría hacer cualquier cambio en una capa sin influir, a nivel de código, en la otra.
Las tres capas son:
Capa de datos: Donde se obtienen datos de la base de datos, se realizan las peticiones SQL, etc.
Capa business: Capa encargada de manejar la información, es decir, de cómo usar los datos
Capa visual o de aplicación: Capa encargada de mostrar estos datos, en este caso en la aplicación web.
A continuación se muestra una ilustración, donde la capa de datos sería el nivel más bajo y la capa visual el nivel más alto.
Figura 29. Estructura por capas de la herramienta
Se realizó un estudio para ver cómo se obtendría la misma información del documento Software Validation Management List4 en la herramienta Test Management Tool y se determinó que los tiempos estimados, registrados (tiempo que tardan en realizar
4 Ver apartado 2.3.6 para ver el documento Software Validation Management List en detalle
la tardatosperíoestad
RepoestadRepode lausada
rea) y respos del estadoodo de práctdo de autom
Finalmentorting de dodo de testeoorting acceda base de daa ya en Aut
A continu
onsables deo de automaticas realiza
matización y
te se hará onde será oo de las tarde a la baseatos. En la htomatic Rep
ación se mu
e las tareas atización deado en la em
y se mostraro
uso de unobtenido el reas, cuanta de datos ta
herramienta porting para
uestra un br
Figura 30
se obtendre las tareasmpresa se aon los datos
na herramieestado de eas tareas seambién, en a Test Manaa obtener el
reve esquem
0. Estructura ge
30
rían de los se obtendr
automatizó us en la base
enta internaejecución dee han testeeste caso se
agement Tooestado de te
ma de la estr
neral de la herr
tickets de trían de la buna herramide datos).
a de Lear letallado de ado o no. e podría decol solo se uesteo.
ructura de la
amienta
tareas de JIbase de datoienta que re
llamada Aula fase de Aunque Aucir que se o
utilizará una
a herramien
IRA; los os (en el ecogía el
utomatic test y el utomatic
obtendría a función
nta:
cómo
A contin
Seguidamo interactúa
nuación se m
mente se puean las capas
muestra un d
Figura 31.
ede observaentre ellas.
diagrama qu
Diagrama capa
ar la intera
31
ue relaciona
as e informació
acción del u
a capas e inf
n
usuario con
formación.
n la herram
mienta, y
32
Figura 32. Esquema Usuario-Herramienta
El usuario interactúa con la herramienta (la aplicación) y esta se interrelaciona con las tres capas anteriormente explicadas, capa de datos, capa business y capa visual (o capa de aplicación). La capa de datos obtiene los datos de diferentes sitios y estos datos cuando son obtenidos, a través de la capa de business, son manejados, es decir, se crean las funciones para poder obtener la información que se desee en cada caso. Con la capa visual, se cogen las funciones creadas en la capa business y se muestran en una aplicación web, que sería lo que recibiría el usuario al ingresar en la aplicación web.
2.2.1
usuar
1 Caso de u
A continurio y la herr
uso y diagra
uación se muramienta.
ama de flujo
uestra el dia
Figura 3
o
agrama de f
33. Diagrama de
33
flujo de la h
e la aplicación
herramienta,, la relación
n entre el
contidecisSoftwproyepodeesté e
contrmomlogin
realizun causo erespu
proyetrabaMana
las aejecuaplic
asocirealiz
Cuando elinuación sesión ya que ware Validaecto lo ada
emos saber aen vigor (im
Se debe traseña, y e
mento o hacn.
A continu
Un caso zarse para laso de uso ses una secueuesta a un e
En este caectos a los
ajando. Se magement Li
En el siguacciones queutar la herrcación y sali
Al introduiados a estzando, con
A continu
l usuario ace mostrarán queremos ation Managaptaba). Enta qué proye
mplementán
tener en cuesto sea coer logout; e
ación se mu
de uso es llevar a cabse denominaencia de intvento que in
aso, el usuaque esté a
mostrarán lost, para tene
uiente caso de puede rearamienta, inir de esta.
ucir un usue usuario yla aplicació
ación podem
ccede a la aplos proyec
un proceso gement Listtonces, al iectos está asndose o ejec
uenta que aorrecto, el en el segun
uestra un ca
una descrio algún proan actores.eracciones qnicia un act
ario realiza asociado y sos mismos der un mejor
de uso podealizar la herntroducir s
uario y cony se muestrón.
mos ver el c
Figura 34.
plicación wctos asociad
común part teníamos introducir esociado ese
cutándose) d
a partir de usuario pu
ndo caso, se
aso de uso d
ipción de loceso. Los pEn el conteque se desator principa
el login, sese muestrandatos o inclur control de
emos ver larramienta T
su usuario
ntraseña, seran los dat
caso de uso
Caso de uso ap
34
web, introdudos a ese ura todos losun docume
el usuario ye usuario y sde esos proy
que el usuuede salir de redireccio
de interacció
os pasos opersonajes oexto de ingearrollarán enl sobre el pr
eguidamenten los datos uso más datla fase en q
as acciones qTest Managy contraseñ
e realiza unos de la úl
correspond
plicación-usuari
uce su usuarusuario. Se proyectos nto para ca
y la contrasse podrá veyectos.
uario introdde la aplicanaria a la p
ón entre usu
o las activido entidades eniería del sntre un sisteropio sistem
e se hace ude la últim
tos que en Sque se está tr
que puede rgement Toolña, consult
na búsquedltima fase d
diente:
io
rio y contraha optado (Con el doc
ada proyectoseña, mediaer la última
duzca su uación en cpágina inici
uario y herra
dades que que particip
software, unema y sus acma.
una búsquedma fase queSoftware Vatrabajando.
realizar el ul. El usuaritar los dato
da de los pde test que
aseña y a por esta cumento o y cada
ante Jira, fase que
suario y cualquier ial, la de
amienta.
deberán parán en
n caso de ctores en
da de los e se está alidation
usuario y io puede os de la
royectos e se está
2.2.2
deterValid
obtenejecudecirla he‘.jar’infor
dónd
2 Diseño de
Para diseñrminado dedation Mana
Los respondrán de Jirutado automr, cuantas taerramienta A’, como librmación nec
A continude se obtiene
e la capa de
ñar la capae dónde oagement Li
onsables, elra; el grado
máticamenteareas se hanAutomatic Rbrería y ascesaria.
uación se pue la informa
e datos
a de datos obtener la st.
l tiempo ro de automae o no, se on testeado oReporting ysí podremo
uede ver unaación.
Figura
de la herrmisma inf
registrado datización de
obtendrá de o no, tambiéya obtenía eos utilizar
a ilustración
a 35. Situación
35
ramienta Tformación
de las tareae cada tareala base de
én de la basel estado de
la función
n de en qué
n capa datos
est Manageque el do
as y el noa, es decir, datos y el ee de datos. testeo, se r
n de donde
paso está la
ement Tooocumento S
ombre de esi las tareaestado de teEn este cas
realizará une obtendrem
a capa de da
ol, se ha Software
estas, se as se han esteo, es so, como n archivo mos esa
atos y de
36
2.2.3 Apartado confidencial
Este apartado es confidencial, si desea más información, contactar con:
Albert Pàmies (Lear Corporation Holding Spain)
Enric Vidal (Universitat Rovira i Virgili)
2.2.4 Diseño de la capa de business
Para diseñar la capa de business de la herramienta Test Management Tool, se ha determinado cómo manejar la información que se mostrará en la capa visual o de aplicación de la herramienta.
Primero tendremos una función que al introducir un usuario y contraseña, obtenga todos los proyectos asociados a ese usuario, con la información de que cliente es y la última fase de ese proyecto, con su estado de automatización y estado de testeo correspondiente para que la capa visual pueda mostrar esa información.
Seguidamente necesitaremos otra función que obtenga todas las fases de ese proyecto, para mostrarlas en una lista desde la fase más reciente a la más antigua y que obtenga toda la información de una fase, pasando por la información de la planificación, el análisis, la implementación, la revisión y la ejecución. Así tendremos la lista de todas las fases y el estado de automatización y de testeo de una única fase, la más reciente.
Por último, necesitaremos una función que obtenga los datos de una sola fase, así al pinchar en el enlace de cualquier otra fase, podremos ver la información de esa fase. Sería una función parecida a la anterior pero en este caso solo tendrá que obtener la información de una sola fase, sin obtener los nombres de todas las fases.
Seguidamente se puede ver una ilustración de en qué paso está la capa business y donde se maneja la información.
2.3
de prNetB
2.3.1
‘daoOencarMyS
lugartenga‘daoOdondtareauna hbase
ImplemenPara la rea
rogramaciónBeans.
1 Desarrollo
Para desaObject’. Estrgado de se
SQL (en nue
Por otro lares de captamos la inObjectJIRA
de tendríamoa, que recorherramientade datos.
ntación alización den Java y Jav
o de la capa
arrollar la cte paquete eeleccionar qestro caso) o
ado, la otra tación de innformación. A’, de dondos la informrdamos, en a que recog
Figura
e la implemvaScript y p
a datos
capa de daestá divididqué base deo incluso un
parte es la nformación
En la sige obtendría
mación en lael período
gía el estado
45. Situación c
mentación, spor otro lad
atos se ha do en dos, une datos quern fichero de
encargada como Jira
guiente imaamos la infoa base de dde práctica
do de autom
37
capa business
se han utilizdo los entorn
optado porna parte es remos utiliztexto para
de obtener a o las tablaagen se puformación ddatos del graas realizado
matización y
zado por unnos de prog
r realizar uel paquete ‘
zar, si quereobtener los
la informacas de la ba
ueden obserde JIRA y ‘ado de autoo en la empy se mostra
n lado los legramación E
un paquete ‘daoObjectUemos usar Sdatos.
ción de los ase de datorvar dos ej‘daoObjectMomatizaciónpresa se autaron los dat
enguajes Eclipse y
llamado Utils’, el SQLite o
distintos os donde jemplos, Metrics’, n de cada tomatizó tos en la
cuale
‘daoOporqude lacorrees delos pcampbase
base d
Por otra pes hablarem
Cada paquObjectMetrue para hacas tablas deespondienteecir, los campaquetes ‘Vpos restantede datos qu
5 Instruccion
de datos.
parte existemos a continu
uete ‘daoOrics’), necescer SELECTe la base dees a cada tabmpos que no
ValueObjectes. Si es caue estemos u
nes básicas de
Figura
en otros paquación.
Object’ que sita un paquTS y JOINSe datos. Parbla se debero se debería’, en las clampo identifutilizando.
e SQL para ob
a 46. Diagrama
quetes llam
acceda a tuete ‘PkObjeS5, necesitamra la parte drían insertaran repetir a ases correspficativo o n
btener datos de
38
a capa datos
mados ‘Valu
tablas de laect’ y otro pmos clases pde los paqur los campolo largo de
pondientes no, se deter
e la base de d
ueObject’ y
a base de dpaquete ‘Vapara cada tauetes ‘PkObos identifica
toda la tabla cada tablarmina al ins
atos y para re
y ‘PkObject
datos (por ealueObject’abla con losbject’, en laativos de cala; y por la a, se insertasertar la tab
elacionar las ta
t’ de los
ejemplo, . Esto es
s campos as clases da tabla, parte de
arían los bla en la
ablas de la
cada Corpcorredetalpara la ba
Repode Jirealizser uhacerobser
soluc
conese poel pro
soluc
Por otro lafase de ca
poration llaespondientellado y por oobtener el e
ase de datos
Por últimoorting, la coira como elza con un p
usado en Ter un estudiorvó que hab
Esto creó cionar el pro
Se buscó xión, el pro
odían obteneotocolo RE
Se encontrcionó el pro
Figur
ado, necesitada proyectmada Auto
e desde la hotro lado utestado de te.
o se enfrontonexión conl responsabrotocolo dest Managemo del protocbía un camp
un retraso oblema desd
informaciónotocolo RESer todos o cST.
ró la maneroblema de la
ra 47. Diagrama
tábamos el eo. Esto se
omatic Repherramienta tilizando unesteo, es dec
tó una probn Jira para oble de la tare conexión dment Tool polo y de los
po que no se
en la realizde el primer
n de cómo ST. Se estudcasi todos lo
ra de implema obtención
a ejemplo daoO
estado de ejobtendrá d
porting, porTest Mana
na clase usadcir, cuántas
blemática coobtener los rea, el tiemde Jira llampara poder cs campos dee podía obte
zación del pr momento
conexionardió el protocos campos d
mentarlo ende la inform
39
Object tablas ba
jecución dee una herrar una parteagement Tooda en la hertareas han
on Test Madatos nece
mpo empleadado protoco
conexionar le los ticketsener, el tiem
proyecto, asque surgió
r con Jira y colo y se obde un ticket
n código javmación de l
se de datos
tallado y el amienta inte
redirecciool, para el erramienta Asido testead
anagement Tesarios y camdo en realizolo SOAP. Ela herramien que se nec
mpo estimad
sí que se buel problema
se encontróbservó que cde Jira, así
va para nueos tickets d
l estado de terna usada
onando a laestado de ej
Automatic Rdas y cuanta
Tool. En Auampos de lozar la tareaEste protoconta con Jiraesitaban ob
do de cada ta
uscó una ma.
ró otro protocon dicho pque se deci
estra aplicacde Jira.
testeo de en Lear
a página jecución
Reporting as no, de
utomatic os tickets a, etc. se olo iba a
a, pero al btener, se area.
anera de
ocolo de protocolo idió usar
ción y se
no pproto
2.3.2
2.3.3
2.4
A continupodíamos obocolo REST
2 Apartado
Este apart
Albert Pàm
apamies@
Enric Vida
enric.vida
3 Apartado
Este apart
Albert Pàm
apamies@
Enric Vida
enric.vida
ApartadoEste apart
Albert Pàm
apamies@
uación podembtener con
T, donde se
Figura 4
confidencia
ado es conf
mies (Lear C
@Lear.com
al (Universi
confidencia
ado es conf
mies (Lear C
@Lear.com
al (Universi
o confidencado es conf
mies (Lear C
@Lear.com
mos observel protoco
obtiene muc
48. Tabla camp
al
fidencial, si
Corporation
itat Rovira i
al
fidencial, si
Corporation
itat Rovira i
ial fidencial, si
Corporation
4
var una tablolo SOAP ycha informa
os obtenidos po
desea más
n Holding S
i Virgili)
desea más
n Holding S
i Virgili)
desea más
n Holding S
40
a donde se y qué campación.
or protocolos SO
información
Spain)
información
Spain)
información
Spain)
aprecia clarpos si se p
OAP y REST
n, contactar
n, contactar
n, contactar
ramente qupodían obte
r con:
r con:
r con:
é campo ener con
41
Enric Vidal (Universitat Rovira i Virgili)
2.5 Dificultades encontradas La principal dificultad fue que el protocolo de conexión que tenían previamente para
conectarse a JIRA, (protocolo SOAP), no pudo ser usado en esta herramienta (Test Management Tool) ya que con este protocolo, no se obtenían algunos campos de los tickets que se necesitaban obtener como por ejemplo las horas estimadas (planeadas).
Se tuvo que buscar una alternativa y se optó por cambiar de protocolo de conexión con JIRA a protocolo REST. Con este protocolo ya se pudieron obtener todos y cada uno de los campos necesarios que se necesitaban en la herramienta Test Management Tool con un resultado satisfactorio en la obtención de los campos de los tickets JIRA.
Otra de las dificultades fue el tener que documentarme y aprender sobre el diseño de bases de datos y la programación orientada a objetos, ya que en la universidad, la programación orientada a objetos se estudia muy vagamente y no se profundiza realmente como para poder enfrentarse a un proyecto de tal calibre como Test Management Tool.
Por último, otra de las dificultades fue el tiempo empleado en hacer el proyecto. Se empezó el 13 de enero de 2014 y se acabó el 25 de abril de 2014. Poco menos de tres meses para la realización del proyecto con una estancia a media jornada en la empresa a causa de las pocas horas que la universidad proporcionó para poder realizarlo.
2.6 Verificación de funcionamiento Para verificar el funcionamiento de la herramienta, se utilizaron datos de la base de
datos del proyecto L494 del cliente Jaguar Land Rover (JLR) para la fase VPMulti, como se ha mostrado anteriormente en el resultado visual final. En referencia a los tickets de Jira, se subieron unos tickets de prueba para verificar el funcionamiento de la conexión de Jira, se realizaron varios tickets para cada una de las fases a mostrar, tanto análisis como implementación, revisión y ejecución.
Finalmente, se probó la herramienta y se vio que obtenía correctamente tanto los datos de la base de datos como la información que necesitábamos de los tickets de Jira.
2.7 Siguientes pasos Uno de los siguientes pasos sería la mejora del tiempo de respuesta de la conexión de
JIRA con el nuevo protocolo REST, ya que se ha visto una notable tardanza en este proceso de obtención de los campos de JIRA. Como siguiente paso sería estudiar este suceso y solventarlo mediante optimizaciones de código, mejoras, etc.
Otro de los siguientes pasos sería probarlo en un proyecto piloto, para ver cómo reaccionaría la herramienta ante un proyecto en vigor.
Y por último, cuando esté probado en el proyecto piloto, se debería realizar un despliegue para usar la herramienta Test Management Tool en todos los proyectos.
42
2.8 Conocimientos aportados del proyecto Este proyecto ha aportado muchos conocimientos a lo largo de su realización, tanto
personalmente como profesionalmente. A continuación se muestran algunos de los muchos conocimientos aportados gracias a la realización del proyecto.
2.8.1 Personalmente
Como mejorar procesos, sobre todo el proceso de System Test. Como enfrentarse a desviaciones en una planificación y poder solventar esas
desviaciones. Un buen diseño, siempre será la mejor implementación. Como hacer mejores presentaciones y enfrentarse a presentaciones a
management/supervisores.
2.8.2 Profesionalmente
Como trabajar en una multinacional como es Lear Corporation. Como trabajan los proyectos y el proceso de System Test desde dentro,
gracias a trabajar con System Test Leaders. La estructura del departamento de Software. Las fases de desarrollo de un Software.
Por la parte más técnica:
Entornos de programación como Eclipse y NetBeans y lenguajes de programación como JAVA, JavaScript y HTML.
La programación orientada a objetos (OOP). Diseños de clases y de bases de datos.
Tarragona, 27 de Abril de 2014 Firmado: Laura Fontanet Bujaldón Ingeniera en Electrónica y Automática Industrial
Herramienta automática de planificación y control de proyectos (Test Management Tool)
PLIEGO DE CONDICIONES
AUTOR: Laura Fontanet Bujaldón DIRECTOR: Enric Vidal Idiarte
FECHA: Abril / 2014
44
ÍNDICE PLIEGO DE CONDICIONES
3 PLIEGO DE CONDICIONES ....................................................................... 45 3.1 Objetivo ..................................................................................................... 45
3.2 Materiales ................................................................................................... 45
3.3 Condiciones Generales............................................................................... 45
3.4 Condiciones Económicas ........................................................................... 45
3.5 Condiciones de Seguridad ......................................................................... 45
3.6 Limitación de responsabilidad ................................................................... 46
45
3 PLIEGO DE CONDICIONES
3.1 Objetivo El objetivo de este Pliego de Condiciones es definir y establecer las limitaciones y
condiciones sobre la distribución, utilización y responsabilidades concernientes a esta herramienta de planificación y control de proyectos.
3.2 Materiales Este proyecto consiste en una herramienta de adquisición automática de datos basada
en página web y programada tanto en entorno Eclipse como en entorno NetBeans. El paquete en el que se presenta el equipo de adquisición consta de la documentación técnica siguiente:
o Memoria Descriptiva o Memoria de Cálculo o Pliego de Condiciones o Estado de mediciones o Presupuesto
3.3 Condiciones Generales La herramienta queda en posesión de la empresa Lear Corporation Holding Spain
como producto final e indivisible. El programa instalado en el sistema está preparado para que funcione únicamente en el servidor proporcionado por Lear Corporation.
No está permitida la reproducción total o parcial de este Proyecto (incluyendo el diseño y la documentación técnica adjuntada), ni su tratamiento informático, ni la transmisión de ninguna forma o por cualquier medio, ya sea electrónico, mecánico, por fotocopia, por registro u otros métodos, sin el permiso previo y por escrito del Ingeniero Técnico firmante del Proyecto.
3.4 Condiciones Económicas Las condiciones económicas de la distribución o venta del programa de adquisición
serán impuestas por la empresa Lear Corporation Holding Spain, que dispone de la propiedad intelectual de la herramienta Test Management Tool.
3.5 Condiciones de Seguridad La herramienta debe estar correctamente instalada para evitar cualquier anomalía en
el funcionamiento de esta.
Los equipos deben estar correctamente conectados para evitar cualquier tipo de cortocircuito.
No se hace responsable al Ingeniero Técnico firmante de manipulaciones, malas conexiones o usos indebidos no aprobados por éste, que perjudiquen y afecten al usuario.
46
3.6 Limitación de responsabilidad La instalación y funcionamiento de la herramienta debe realizarse tal y como se
especifica en los cursos de formación de usuarios que se realizan antes de trabajar con la herramienta, sin hacerse responsable el Ingeniero Técnico firmante de la pérdida o daños en el hardware o software del equipo donde se ejecute el programa, provocados por el uso incorrecto del sistema, tanto en su instalación o en su posterior utilización.
Tarragona, 27 de Abril de 2014
Firmado: Laura Fontanet Bujaldón
Ingeniera en Electrónica y Automática Industrial
Herramienta automática de planificación y control de proyectos (Test Management Tool)
ESTADO DE MEDICIONES
AUTOR: Laura Fontanet Bujaldón DIRECTOR: Enric Vidal Idiarte
FECHA: Abril / 2014
48
ÍNDICE ESTADO DE MEDICIONES
4 ESTADO DE MEDICIONES ......................................................................... 49 4.1 Definición del hardware utilizado .............................................................. 49
4.2 Entornos de programación y programas utilizados .................................... 49
49
4 ESTADO DE MEDICIONES
4.1 Definición del hardware utilizado
Uds. Descripción Longitud Anchura Altura Parciales Cantidad
u HP Compaq PRO 6300MT CORE I7 Ordenador sobremesa HP Compaq PRO 6300MT CORE I7 4 GB 500 GB PC SIN MONITOR
2 2
u Monitor S19C450BW Monitor Samsung LED S19C450BW 19'
1 1
u Teclado y ratón HP Essentials Juego de teclado y ratón HP Essentials
1 1
4.2 Entornos de programación y programas utilizados
Uds. Descripción Longitud Anchura Altura Parciales Cantidad
u Microsoft Office Visio 2007 Service Pack 1
Software de dibujo vectorial para el diseño de la aplicación. Microsoft Office Visio 2007 Service Pack 1
1 1
u Eclipse SDK Sistema de desarrollo profesional de software libre ECLIPSE
1 1
u NetBeans IDE Sistema de desarrollo profesional de software libre NetBeans IDE
1 1
Tarragona, 27 de Abril de 2014
Firmado: Laura Fontanet Bujaldón
Ingeniera en Electrónica y Automática Industrial
Herramienta automática de planificación y control de proyectos (Test Management Tool)
PRESUPUESTO
AUTOR: Laura Fontanet Bujaldón DIRECTOR: Enric Vidal Idiarte
FECHA: Abril / 2014
51
ÍNDICE PRESUPUESTO
5 PRESUPUESTO .............................................................................................. 52 5.1 Presupuesto FASE I. Definición del equipo e instalación ......................... 52
5.2 Presupuesto FASE II. Diseño de la herramienta ........................................ 52
5.3 Presupuesto FASE III. Implementación de la herramienta ........................ 53
5.4 Presupuesto FASE IV. Formación usuarios .............................................. 53
5.5 Resumen ..................................................................................................... 54
52
5 PRESUPUESTO
5.1 Presupuesto FASE I. Definición del equipo e instalación
Unid. Descripción Cantidad Precio Importe
u HP Compaq PRO 6300MT CORE I7 2,00 813,79 1.627,58
u Monitor S19C450BW 1,00 149,99 149,99
u Teclado y ratón HP Essentials 1,00 39,99 39,99
hora Mano de Obra Ingeniero Técnico 1,00 32,00 32,00
TOTAL 1. 849,56
5.2 Presupuesto FASE II. Diseño de la herramienta
Unid. Descripción Cantidad Precio Importe
u Microsoft Office Visio 2007 Service Pack 1 1,00 259,96 259,96
hora Mano de Obra Ingeniero Técnico 50,00 32,00 1.600,00
hora Mano de Obra Ingeniero Superior 25,00 45,00 1.125,00
TOTAL 2. 984,96
53
5.3 Presupuesto FASE III. Implementación de la herramienta
Unid. Descripción Cantidad Precio Importe
u Eclipse SDK 1,00 0,00 0,00
u NetBeans IDE 1,00 0,00 0,00
hora Mano de Obra Ingeniero Técnico 240,00 32,00 7.680,00
hora Mano de Obra Ingeniero Superior 100,00 45,00 4.500,00
TOTAL 1 2.180,00
5.4 Presupuesto FASE IV. Formación usuarios
Unid. Descripción Cantidad Precio Importe
hora Mano de Obra Ingeniero Técnico 10,00 32,00 320,00
TOTAL 3 20,00
54
5.5 Resumen
Descripción Importe
FASE I 1.849,56
FASE II 2.984,96
FASE III 12.180,00
FASE IV 320,00
TOTAL 1 7.334,52
El presupuesto total del proyecto asciende a DIEZ Y SIETE MIL TRESCIENTOS TREINTA Y CUATRO con CINCUENTA Y DOS CENTIMOS.
Tarragona, 27 de Abril de 2014
Firmado: Laura Fontanet Bujaldón
Ingeniera en Electrónica y Automática Industrial
Herramienta automática de planificación y control de proyectos (Test Management Tool)
ESTUDIO CON ENTIDAD PROPIA
AUTOR: Laura Fontanet Bujaldón DIRECTOR: Enric Vidal Idiarte
FECHA: Abril / 2014
56
ÍNDICE ESTUDIO CON ENTIDAD PROPIA
6 ESTUDIO CON ENTIDAD PROPIA ........................................................... 57 6.1 Estudio de salud y seguridad en el trabajo ................................................. 57
6.1.1 Obligaciones en Materia de Prevención de Riesgos Laborales .............. 57
6.1.2 Como comunicar una situación de riesgo .............................................. 57
6.1.3 Funciones de los recursos preventivos ................................................... 57
57
6 ESTUDIO CON ENTIDAD PROPIA
6.1 Estudio de salud y seguridad en el trabajo
6.1.1 Obligaciones en Materia de Prevención de Riesgos Laborales
Velar, mediante el cumplimiento de las medidas de prevención que Lear Corporation Holding Spain establezca, por su propia seguridad y salud en el trabajo, por la de sus compañeros y por las de aquellas otras personas a las que su actividad profesional pueda afectar, a causa de sus actos y omisiones.
Asistir a las sesiones formativas e informativas en materia de riesgos laborales a las que le convoquen.
Usar adecuadamente los equipos de trabajo, aparatos, herramientas, sustancias químicas y en general, cualquier otro medio con el que desarrolle su actividad.
Utilizar correctamente los medios y equipos de protección facilitados por la empresa, de acuerdo a las instrucciones recibidas por ésta. Si algún equipo está dañado o deteriorado, comunicarlo con inmediatez a su superior.
Utilizar correctamente los dispositivos de seguridad existentes o que sean instalados en los equipos de trabajo o en los lugares de trabajo.
Cooperación con la empresa para que ésta pueda garantizar unas condiciones de trabajo seguras y no comporten riesgos para la seguridad y salud de los trabajadores.
6.1.2 Como comunicar una situación de riesgo
Comunicar la incidencia al responsable para que analice la situación e intente aportar una solución al problema detectado. Con frecuencia, muchas situaciones de riesgo se pueden resolver con la intervención directa del responsable.
6.1.3 Funciones de los recursos preventivos
Detección y comunicación al Servicio de Prevención de situaciones de riesgo.
Comunicación al Servicio de Prevención los incidentes relacionados con la seguridad que puedan suceder en su área de influencia.
Velar por la correcta utilización de los equipos de protección individual y por la correcta utilización de los equipos de trabajo, tanto hardware como software y comunicar al responsable los incumplimientos que se detecten en materia de riesgo laboral.
58
Comunicar al responsable las situaciones de riesgo que les transmitan los trabajadores, así como inquietudes o necesidades sobre las condiciones de trabajo.
Colaborar con el técnico de prevención, durante las visitas de inspección de las zonas de trabajo, investigaciones de accidentes e incidentes, etc.
Asistencia a las reuniones a las que sea convocado por el Servicio de Prevención.
Tarragona, 27 de Abril de 2014
Firmado: Laura Fontanet Bujaldón
Ingeniera en Electrónica y Automática Industrial
Herramienta automática de planificación y control de proyectos (Test Management Tool)
ANEXOS
AUTOR: Laura Fontanet Bujaldón DIRECTOR: Enric Vidal Idiarte
FECHA: Abril / 2014
60
ÍNDICE ANEXOS
7 ANEXOS .......................................................................................................... 61 7.1 Conclusiones .............................................................................................. 61
7.2 Agradecimientos ........................................................................................ 61
7.3 Bibliografía ................................................................................................ 61
61
7 ANEXOS
7.1 Conclusiones Se puede ver que los objetivos marcados al principio del proyecto han sido logrados.
Se ha conseguido un proceso automático de recopilación de datos, dejando de lado el proceso manual y aportando eficiencia y consistencia al proceso de System Test.
En un punto de vista personal, la realización de este proyecto ha sido un reto, porque he podido tocar varios campos de la informática donde yo carecía de estos conocimientos, como el uso de bases de datos o la programación y usos de JAVA y JavaScript. El proyecto ha ampliado mis conocimientos sobre todo en la industria del automóvil y por lo tanto ha ayudado a mejorar mi comprensión sobre los problemas a que se enfrentan en este campo, y personalmente, me ha parecido un campo de la ingeniería muy interesante.
7.2 Agradecimientos Me gustaría agradecer a mi tutor de Lear, Albert Pàmies, su asesoramiento y
asistencia durante la realización del proyecto, como también la gran ayuda recibida por Edu del Rey durante la realización del mismo. También me gustaría agradecer al profesor Enric Vidal su orientación y críticas tanto útiles como constructivas del proyecto final de grado. También me gustaría agradecer la ayuda recibida por diferentes compañeros de Lear Corporation del departamento de Software & Systems.
7.3 Bibliografía http://es.wikipedia.org/wiki/M%C3%A9todo_en_V
http://sistemas.uniandes.edu.co/~isis2603/dokuwiki/lib/exe/fetch.php?media=principal:isis2603-modelosciclosdevida.pdf
http://es.wikipedia.org/wiki/NetBeans
http://es.wikipedia.org/wiki/Eclipse_(software)
http://es.wikipedia.org/wiki/MySQL
http://es.wikipedia.org/wiki/Microsoft_Project
http://es.wikipedia.org/wiki/Microsoft_Visio
http://eudca-con01:8080/display/ELECTRONIC/Development+Processes
http://eudca-con01:8080/display/ELECTRONIC/System+Test+Process
http://eudca-con01:8080/display/BMWBDC/JIRA+Process
http://www.desarrolloweb.com/faq/360.php
Tarragona, 27 de Abril de 2014
Firmado: Laura Fontanet Bujaldón
Ingeniera en Electrónica y Automática Industrial