Herramienta automática de planificación y control de...

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 –

[email protected]

o contiene ap

– Lear Corpo

com

partados e i

oration Hol

imágenes co

lding Spain

onfidencialees, para máss informacióón,


ÍNDICE GENERAL


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.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.4 Diseño de la capa de business ................................................................ 36

2.3 Implementación.......................................................................................... 37

2.3.1 Desarrollo de la capa datos .................................................................... 37



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


MEMORIA DESCRIPTIVA


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.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)

[email protected]

Enric Vidal (Universitat Rovira i Virgili)

[email protected]

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



[email protected]


[email protected]




[email protected]


[email protected]

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




Figura 12. Tabla encuesta System Test Leaders

System Test Engineer Implementación Ejecución

System Test Engineer 1 1h 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 Leader)



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


MEMORIA DE CÁLCULO


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.4 Diseño de la capa de business ................................................................ 36

2.3 Implementación.......................................................................................... 37

2.3.1 Desarrollo de la capa datos .................................................................... 37



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




[email protected]


[email protected]

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

[email protected]

confidencia

ado es conf

mies (Lear C

@Lear.com

al (Universi

[email protected]

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


[email protected]

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


PLIEGO DE CONDICIONES


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.





ESTADO DE MEDICIONES


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





PRESUPUESTO


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


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


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


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.





ESTUDIO CON ENTIDAD PROPIA


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.





ANEXOS


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




Herramienta automática de planificación y control de...

Documents

Transcript of Herramienta automática de planificación y control de...