Migraci o d’un sistema ERP per a una empresa del sector de ...

Migracio d’un sistema ERPper a una empresa del sector de

mobles de disseny

Grau en Enginyeria InformaticaEspecialitat en Sistemes d’Informacio

Autor: Jordi Masvidal BrunDirector: Jordi Ballester Alomar (ForgeFlow S.L.)

Ponent: Joan Antoni Pastor Collado (Dept. d’ESSI)

26 d’abril de 2021

Realitzat en conveni de cooperacio educativa a:

Resum

La disrupcio de les noves tecnologies de la informacio al llarg de les ultimes

decades ha suposat un gran impacte a nivell global, facilitant l’acces, ma-

nipulacio i comparticio d’informacio arreu del mon. En l’ambit empresarial

aixo s’ha traduıt en la seva aplicacio als diferents processos de negoci, ja sigui

per automatitzar tasques, agilitzar fluxos de treball, o gestionar integralment

tota la informacio, amb l’objectiu final de reduir costos i incrementar la pro-

ductivitat de l’empresa.

Dins del conjunt d’aquestes eines, els ERP esdevenen la peca clau en

l’organitzacio, unificant i integrant tots els processos i recursos associats en

un unic sistema. Malauradament, pero, l’evolucio tecnologica comporta una

necessitat constant de manteniment i actualitzacio del software per tal de

poder gaudir de les noves millores, aixı com evitar la seva obsolescencia.

El present projecte consisteix en la migracio d’un sistema ERP per a

una empresa del sector de mobles de disseny, la qual opera amb una versio

desactualitzada. Al llarg de la memoria es planteja la planificacio general del

projecte, es defineixen els processos involucrats en la migracio a una versio

posterior del sistema, i s’analitzen i avaluen els principals riscos associats.

Resumen

La disrupcion de las nuevas tecnologıas de la informacion a lo largo de las

ultimas decadas ha supuesto un gran impacto a nivel global, facilitando el

acceso, manipulacion y comparticion de informacion alrededor del mundo.

En el ambito empresarial esto se ha traducido en su aplicacion en los distintos

procesos de negocio, ya sea para automatizar tareas, agilizar flujos de trabajo,

o gestionar integralmente toda la informacion, con el objetivo final de reducir

costes e incrementar la productividad de la empresa.

Dentro del conjunto de estas herramientas, los ERP son la pieza clave

en la organizacion, unificando e integrando todos los procesos y recursos aso-

ciados en un solo sistema. Sin embargo, la evolucion tecnologica conlleva

la necesidad constante de mantenimiento y actualizacion del software para

poder disponer de las nuevas mejoras, ası como para evitar su obsolescencia.

Este proyecto consiste en la migracion de un sistema ERP para una em-

presa del sector de muebles de diseno, la cual opera con una version desac-

tualizada. A lo largo de la memoria se plantea la planificacion general del

proyecto, se definen los procesos implicados en la migracion a una version

posterior del sistema, y se analizan y evaluan los principales riesgos asocia-

dos.

Abstract

The disruption of new information technologies over the last decades has had

a great impact at the global level, facilitating the access, manipulation and

sharing of information around the world. In the business environment this

has translated into its application in the different business processes, whet-

her to automate tasks, streamline workflows, or manage all information inte-

grally, with the ultimate goal of reducing costs and increasing the productivity

of the company.

Within this set of tools, ERPs are the key piece in the organization,

unifying and integrating all processes and associated resources into a sin-

gle system. However, the technological evolution entails the constant need of

software maintenance and update in order to have the new improvements, as

well as to avoid its obsolescence.

This project covers the migration of an ERP system for a company in the

design furniture sector, which operates with an outdated version. Throughout

the document, the general planning is outlined, the processes involved in the

migration to a later version of the system are defined, and the associated

risks are analyzed and evaluated.

Glossari

API Application Programming Interface: Conjunt de funcions i protocols

d’interaccio entre varis programaris que permeten la seva comunicacio

sense necessitat de saber com estan implementats, afegint una capa

d’abstraccio per a la seva integracio.

backup En el context de les bases de dades, es refereix a la realitzacio d’una

copia de seguretat.

CEO Chief Executive Officer: Anglicisme referent al Director Executiu d’u-

na empresa, la persona de maxima autoritat en la gestio i direccio

administrativa de l’organitzacio.

CRM Customer Relationship Management: En l’ambit dels sistemes in-

formatics, fa referencia als sistemes d’informacio destinats al suport a

la gestio de relacions amb els clients, a la venda, i al marqueting.

e-commerce Electronic Commerce: El comerc electronic consisteix en la

compra i venda de productes o serveis a traves d’Internet.

e-learning Electronic learning: Anglicisme referent a l’educacio en lınia,

realitzada a traves de mitjans digitals i la xarxa.

end-to-end Es refereix a una metodologia de proves en la que el sistema es

prova simulant processos reals dels usuaris finals d’inici a fi.

ERP Enterprise Resource Planning: En l’ambit dels sistemes informatics fa

referencia a un conjunt de sistemes d’informacio destinats a la Planifi-

cacio dels Recursos Empresarials, integrant les operacions de diverses

arees de l’empresa com la produccio, logıstica, o comptabilitat, entre

d’altres.

framework Anglicisme utilitzat per referir-se a un marc de treball, un con-

junt estandarditzat de conceptes, practiques i criteris per a resoldre

una problematica particular. En l’ambit de les TI aquest defineix una

estructura tecnologica definida per a ser utilitzada com a base per al

desenvolupament de programari.

GNU GPL GNU General Public License: Llicencia de dret d’autor apli-

cada en el mon del software lliure i de codi obert, que garanteix als

usuaris finals la llibertat d’utilitzar, estudiar, compartir i modificar el

programari. En el cas de copies o treballs derivats, aquests s’han de

distribuir sota la mateixa llicencia.

GNU LGPL GNU Lesser General Public License: Llicencia que segueix les

mateixes directrius que la GNU GPL, pero que permet l’enllacament

del software a un altre programari que no estigui sota les restriccions

d’una GPL, permetent-ne la seva distribucio completa sota qualsevol

condicio desitjada (per exemple sota llicencies privatives).

go-live Fase del projecte on es realitza el llancament oficial del desenvolu-

pament a l’entorn on sera usat pels usuaris finals.

hosting Anglicisme utilitzat per referir-se a l’emmagatzematge d’una pagina

o aplicacio web a un servidor per tal de fer-lo accessible a traves d’In-

ternet als usuaris.

key user Usuari clau: Persones de l’empresa client que actuen com a nexe

entre aquesta i el proveıdor, amb gran coneixement sobre els processos

de l’empresa, i representant les necessitats dels usuaris finals.

Kick Off Anglicisme utilitzat en l’ambit empresarial i de gestio de projectes

per referir-se a la reunio que determina l’inici d’un projecte.

migracio En el context dels sistemes informatics, fa referencia a la reloca-

litzacio del contingut d’un sistema a una versio diferent de l’actual.

MRP Material Requirements Planning: En l’ambit dels sistemes informatics,

fa referencia al sistema d’informacio destinat a la planificacio i admi-

nistracio de la produccio i la gestio d’inventaris.

open core Model de negoci orientat a la comercialitzacio de software de

codi obert, oferint una versio basica o limitada del programari sota

llicencia de software lliure, i una versio completa de pagament sota una

llicencia privativa.

ORM Object-Relational Mapping: Model de programacio que permet asso-

ciar automaticament les estructures d’una base de dades relacional amb

els objectes definits per un llenguatge de programacio, podent interac-

tuar amb la base de dades utilitzant directament aquest llenguatge.

rollback En tecnologia de base de dades, un rollback es una operacio que

retorna la base de dades a un estat previ a l’execucio d’una operacio o

varies.

script En el context de la informatica, es refereix a una sequencia d’instruc-

cions executades per un programa.

setup En el context dels sistemes informatics, es refereix a la configuracio o

preparacio d’una infraestructura tecnologica.

Silver Partner L’Odoo Official Partner es una designacio atorgada a em-

preses que ofereixen un servei de qualitat especialitzat en Odoo. El

nivell Silver fa referencia a partners que adquireixin mes de 50 nous

usuaris d’Odoo Enterprise a l’any, amb mes de 2 recursos interns actius

certificats oficialment, i amb una taxa de retencio mınima dels usuaris

del 70%.

ssh Secure Shell: Protocol que possibilita l’acces i administracio remota a un

servidor a traves d’una connexio segura, on la informacio esta xifrada.

TI Tecnologies de la Informacio: Aplicacio d’ordinadors i tecnologies de te-

lecomunicacio per a l’emmagatzematge, consulta, transmissio, i mani-

pulacio de dades i informacio.

Index

Introduccio 13

Bloc 1: Gestio del Projecte 14

1.1 Contextualitzacio . . . . . . . . . . . . . . . . . . . . . . . . 14

1.1.1 ForgeFlow S.L. . . . . . . . . . . . . . . . . . . . . . . 14

1.1.2 Odoo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.1.3 Empresa client . . . . . . . . . . . . . . . . . . . . . . 15

1.1.4 Problema a resoldre . . . . . . . . . . . . . . . . . . . . 16

1.1.5 Actors implicats . . . . . . . . . . . . . . . . . . . . . . 16

1.2 Justificacio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.2.1 Adquisicio d’un nou sistema . . . . . . . . . . . . . . . 18

1.2.2 Implantacio des de zero d’una nova versio d’Odoo . . . 18

1.2.3 Seguir operant amb la versio actual . . . . . . . . . . . 19

1.2.4 Conclusio . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.3 Abast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.3.1 Objectius . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.3.2 Requisits . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.3.3 Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.4 Metodologia i rigor . . . . . . . . . . . . . . . . . . . . . . 24

1.4.1 Metodologia de treball . . . . . . . . . . . . . . . . . . 24

1.4.2 Metodologia de migracio . . . . . . . . . . . . . . . . . 25

1.4.2.1 Base de dades . . . . . . . . . . . . . . . . . . 26

1.4.2.2 Moduls . . . . . . . . . . . . . . . . . . . . . 26

1.5 Planificacio . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

1.5.1 Ajustaments d’estructura . . . . . . . . . . . . . . . . . 27

1.5.2 Ajustaments temporals . . . . . . . . . . . . . . . . . . 29

1.5.3 Afegiment de recursos . . . . . . . . . . . . . . . . . . 30

1.5.4 Planificacio final del projecte . . . . . . . . . . . . . . . 31

1.5.4.1 Consideracions generals . . . . . . . . . . . . 31

1.5.4.2 Descripcio de les tasques . . . . . . . . . . . . 31

1.5.4.3 Recursos emprats . . . . . . . . . . . . . . . . 36

1.5.4.4 Estimacio temporal . . . . . . . . . . . . . . . 37

1.6 Gestio economica i desviacions . . . . . . . . . . . . . . . 40

1.6.1 Identificacio dels costos . . . . . . . . . . . . . . . . . . 40

1.6.1.1 Costos de Personal . . . . . . . . . . . . . . . 40

1.6.1.2 Costos de Hardware . . . . . . . . . . . . . . 41

1.6.1.3 Costos de Software . . . . . . . . . . . . . . . 41

1.6.1.4 Costos Generics . . . . . . . . . . . . . . . . . 42

1.6.2 Estimacio final dels costos i desviacions . . . . . . . . . 42

1.7 Sostenibilitat i compromıs social . . . . . . . . . . . . . . 46

1.7.1 Dimensio Economica . . . . . . . . . . . . . . . . . . . 47

1.7.2 Dimensio Mediambiental . . . . . . . . . . . . . . . . . 47

1.7.3 Dimensio Social . . . . . . . . . . . . . . . . . . . . . . 48

Bloc 2: Factors crıtics d’exit i riscos del projecte 49

2.1 Perspectiva Organitzacional . . . . . . . . . . . . . . . . . 51

2.1.1 Estrategics . . . . . . . . . . . . . . . . . . . . . . . . . 51

2.1.2 Tactics . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

2.2 Perspectiva Tecnologica . . . . . . . . . . . . . . . . . . . . 57

2.2.1 Estrategics . . . . . . . . . . . . . . . . . . . . . . . . . 57

2.2.2 Tactics . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Bloc 3: El sistema Odoo 62

3.1 L’ecosistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.1.1 Odoo Core . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.1.2 Odoo Enterprise . . . . . . . . . . . . . . . . . . . . . . 64

3.1.3 Odoo Community Association . . . . . . . . . . . . . . 64

3.1.4 Codi privatiu . . . . . . . . . . . . . . . . . . . . . . . 65

3.2 Arquitectura tecnologica . . . . . . . . . . . . . . . . . . . 66

3.2.1 Aplicacions/Moduls . . . . . . . . . . . . . . . . . . . . 69

3.2.2 Components d’un modul . . . . . . . . . . . . . . . . . 69

Bloc 4: Aspectes Legals — Llicencies 81

4.1 Codi i Moduls Community . . . . . . . . . . . . . . . . . . 82

4.2 Moduls Enterprise . . . . . . . . . . . . . . . . . . . . . . . 82

4.3 Moduls de la Odoo Community Association . . . . . . . 84

4.4 Moduls privatius de tercers . . . . . . . . . . . . . . . . . 84

4.5 Moduls custom . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.6 Matriu de compatibilitat de llicencies . . . . . . . . . . . 85

Bloc 5: Proces de migracio 86

5.1 Infraestructura de migracio . . . . . . . . . . . . . . . . . 86

5.1.1 Gestio del codi . . . . . . . . . . . . . . . . . . . . . . 86

5.1.2 Git / GitLab . . . . . . . . . . . . . . . . . . . . . . . 87

5.1.3 Docker / Docker Compose . . . . . . . . . . . . . . . . 89

5.1.4 Servidor de migracio . . . . . . . . . . . . . . . . . . . 92

5.1.5 Flux de treball . . . . . . . . . . . . . . . . . . . . . . 93

5.2 Analisi de processos . . . . . . . . . . . . . . . . . . . . . . 94

5.3 Migracio de la base de dades . . . . . . . . . . . . . . . . 99

5.3.1 OpenUpgrade i el Gestor de Migracio d’Odoo . . . . . 99

5.3.2 openupgradelib . . . . . . . . . . . . . . . . . . . . . . . 102

5.3.3 Proces de migracio de la Base de Dades . . . . . . . . . 104

5.4 Migracio dels moduls . . . . . . . . . . . . . . . . . . . . . 106

5.4.1 Volum de moduls . . . . . . . . . . . . . . . . . . . . . 106

5.4.2 Analisi Inicial del modul . . . . . . . . . . . . . . . . . 108

5.4.3 Migracio del codi . . . . . . . . . . . . . . . . . . . . . 113

5.4.4 Scripts de migracio . . . . . . . . . . . . . . . . . . . . 124

5.4.5 Documentacio tecnica . . . . . . . . . . . . . . . . . . 128

5.4.6 Desenvolupament de proves . . . . . . . . . . . . . . . 133

5.5 Documentacio i formacio . . . . . . . . . . . . . . . . . . . 140

5.5.1 Documentacio d’usuari . . . . . . . . . . . . . . . . . . 140

5.5.2 Formacio d’usuaris . . . . . . . . . . . . . . . . . . . . 142

5.6 Proces de Validacio . . . . . . . . . . . . . . . . . . . . . . 144

5.6.1 Preparacio de les sessions de validacio . . . . . . . . . . 144

5.6.2 Gestio dels resultats . . . . . . . . . . . . . . . . . . . 146

Bloc 6: Conclusions 148

6.1 Assoliment dels objectius del projecte . . . . . . . . . . 148

6.2 Continuacio del projecte . . . . . . . . . . . . . . . . . . . 151

6.3 Competencies tecniques . . . . . . . . . . . . . . . . . . . 152

6.4 Conclusions Personals . . . . . . . . . . . . . . . . . . . . . 157

Annex 163

Bloc A: Planificacio i Gestio Economica Inicial 163

A.1 Planificacio Inicial . . . . . . . . . . . . . . . . . . . . . . . 163

A.1.1 Consideracions generals . . . . . . . . . . . . . . . . . 163

A.1.2 Descripcio de les tasques . . . . . . . . . . . . . . . . . 164

A.1.3 Recursos emprats . . . . . . . . . . . . . . . . . . . . . 167

A.1.4 Estimacio temporal . . . . . . . . . . . . . . . . . . . . 168

A.2 Gestio economica . . . . . . . . . . . . . . . . . . . . . . . . 170

A.2.1 Identificacio dels costos . . . . . . . . . . . . . . . . . . 170

A.2.1.1 Costos de Personal . . . . . . . . . . . . . . . 170

A.2.1.2 Costos de Hardware . . . . . . . . . . . . . . 170

A.2.1.3 Costos de Software . . . . . . . . . . . . . . . 171

A.2.1.4 Costos Generics . . . . . . . . . . . . . . . . . 171

A.2.2 Estimacio dels costos totals . . . . . . . . . . . . . . . 172

A.2.3 Model de control dels costos . . . . . . . . . . . . . . . 175

Bloc B: Diagrama de Gantt (Inicial) 177

Bloc C: Interfıcies pel Control dels Costos 178

C.1 Desviacions Costos de Personal per Activitat . . . . . . 178

C.2 Desviacions Costos Hardware, Software i Generics . . . 179

C.3 Desviacions Costos Totals . . . . . . . . . . . . . . . . . . 179

Bloc D: Diagrama de Gantt (Final) 180

Index de taules

1 Cost del servidor de migracio. Font propia. . . . . . . . . . . . 30

2 Taula resum final de les tasques del projecte (I). Font propia. . 38

3 Taula resum final de les tasques del projecte (II). Font propia. 39

4 Salaris dels rols involucrats al projecte. Font propia. . . . . . . 40

5 Costos associats als recursos hardware. Font propia. . . . . . . 41

6 Costos associats als recursos software. Font propia. . . . . . . 41

7 Costos associats als recursos generics. Font propia. . . . . . . 42

8 Costos de Personal per Activitat Totals Final. Font propia. . . 43

9 Avaluacio dels riscos del projecte. Font propia. . . . . . . . . . 61

10 Exemple d’especificacio d’una llista de control d’acces. Font

propia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

11 Matriu de compatibilitat de llicencies involucrades en el siste-

ma Odoo. Font propia. . . . . . . . . . . . . . . . . . . . . . . 85

12 Volum de moduls per proces. Font propia. . . . . . . . . . . . 107

13 Taula resum de les tasques del projecte. Font: Propia. . . . . 169

14 Salaris dels rols involucrats al projecte. Font propia. . . . . . . 170

15 Costos associats als recursos hardware. Font propia. . . . . . . 171

16 Costos associats als recursos software. Font propia. . . . . . . 171

17 Costos associats als recursos generics. Font propia. . . . . . . 172

18 Costos de Personal per Activitat totals. Font propia. . . . . . 173

19 Pressupost total del projecte. Font propia. . . . . . . . . . . . 174

Index de figures

1 Costos de Hardware, Software i Generics Finals, i desviacions.

Font propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2 Costos de Personal per Activitat Finals i desviacions. Font

propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3 Costos Totals Finals i desviacions. Font propia . . . . . . . . 45

4 Odoo Ecosystem. [23] . . . . . . . . . . . . . . . . . . . . . . . 63

5 Interfıcie d’inici de sessio del client d’Odoo 13. Font propia . . 67

6 Arquitectura d’Odoo. Font propia . . . . . . . . . . . . . . . . 68

7 Menu general d’Odoo. Font propia . . . . . . . . . . . . . . . 69

8 Mapeig. Font propia . . . . . . . . . . . . . . . . . . . . . . . 72

9 Interfıcie resultant de la vista definida al Llistat de codi 2.

Font propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

10 Exemple d’un wizard a Odoo. Font propia . . . . . . . . . . . 74

11 Part de l’informe resultant del Llistat de codi 7. Font propia . 79

12 Fitxer Docker Compose de configuracio dels serveis utilitzats

en el desplegament d’un sistema Odoo a un servidor. Font

propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

13 Connexio al servidor i llistat de directoris on es troben les

imatges principals. Font propia . . . . . . . . . . . . . . . . . 92

14 Flux de treball a traves de la infraestructura. Font propia . . 93

15 Estructura d’un modul d’OpenUpgrade 13 (esquerra) i Odoo

Community 13 (dreta). Font propia . . . . . . . . . . . . . . . 101

16 Estructura d’un directori de migracio d’un modul. Font propia 101

17 Part del metode rename fields d’openupgradelib. Font propia 103

18 Part del metode drop columns d’openupgradelib. Font propia 103

19 Branca openupgrade del repositori del projecte. Font propia . 104

20 Proces de migracio OpenUpgrade. Font propia . . . . . . . . . 105

21 Estructura del modul x sale. Font propia . . . . . . . . . . . . 109

22 Estructura del modul x designer. Font propia . . . . . . . . . 109

23 Codi parcial de les vistes del modul x designer. Font propia . 110

24 Vista tree del model x designer. Font propia . . . . . . . . . . 111

25 Vista form del model x designer. Font propia . . . . . . . . . 111

26 Part de la vista d’un producte del sistema. Font propia . . . . 112

27 Captura parcial dels moduls a la branca 10.0. Font propia . . 114

28 Fitxer manifest en versio 10. Font propia . . . . . . . . . . . . 116

29 Fitxer manifest en versio 13. Font propia . . . . . . . . . . . . 116

30 Metode amb decorador a versio 10. Font propia . . . . . . . . 117

31 Metode sense decorador a versio 13. Font propia . . . . . . . . 117

32 Metode de camp calculat a versio 10. Font propia . . . . . . . 117

33 Metode de camp calculat a versio 13. Font propia . . . . . . . 118

34 Especificacio del format de codificacio d’un fitxer Python en

Odoo 10. Font propia . . . . . . . . . . . . . . . . . . . . . . . 118

35 Metode en versio 10. Font propia . . . . . . . . . . . . . . . . 119


37 Assignacio de metode d’enviament a Odoo 10. Font propia . . 120

38 Assignacio de metode d’enviament a Odoo 13. Font propia . . 120





43 Codi de vista en versio 10. Font propia . . . . . . . . . . . . . 123

44 Codi de vista migrat en versio 13. Font propia . . . . . . . . . 123

45 Codi exemple fitxer de migracio d’un modul. Font propia . . . 125

46 Logs corresponents a l’execucio de fitxers de migracio. Font

propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

47 Codi exemple fitxer de migracio d’un modul. Font propia . . . 127

48 Codi d’exemple d’un fitxer README. Font propia . . . . . . 129

49 Visualitzacio d’un fitxer README a l’Odoo. Font propia . . . 130

50 Codi d’exemple d’un fitxer README. Font propia . . . . . . 131

51 Visualitzacio d’un fitxer README a GitLab. Font propia . . 132

52 Codi parcial del metode set up. Font propia . . . . . . . . . . 136

53 Metode per a la creacio d’un producte en una classe de test.

Font propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

54 Codi d’exemple d’un metode de prova. Font propia . . . . . . 137


56 Resultat d’execucio dels tests d’un modul. Font propia . . . . 139


58 Exemple seccio del Standard Operating Procedure. Font propia 141

59 Captura d’un vıdeo formatiu orientat a la contextualitzacio

d’un proces. Font propia . . . . . . . . . . . . . . . . . . . . . 142

60 Captura d’un vıdeo formatiu orientat a la demostracio d’un

proces en el sistema. Font propia . . . . . . . . . . . . . . . . 143

61 Exemple document base de validacio. Font propia . . . . . . . 145

62 Exemple 1 d’incidencia registrada a Jira. Font propia . . . . . 147

63 Exemple 2 d’incidencia registrada a Jira. Font propia . . . . . 147

Index de llistats de codi

1 Exemple parcial d’implementacio d’un model. Font propia . . 70

2 Exemple d’implementacio d’una vista. Font propia . . . . . . 73

3 Exemple d’implementacio d’un controlador. Font propia . . . 75

4 Exemple de creacio d’una instancia. Font propia . . . . . . . . 76

5 Exemple parcial d’un fitxer i18n. Font propia . . . . . . . . . 77

6 Exemple metode unittest de Python. Font propia . . . . . . . 78

7 Exemple parcial de la definicio d’un informe. Font propia . . . 78

8 Exemple d’un fitxer Manifest d’un modul. Font propia . . . . 80

9 Clonacio del repositori del projecte en l’ordinador personal.

Font propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

10 Comandes per a l’execucio dels dos primers passos. Font propia113

11 Comanda per a l’execucio dels tests d’un modul. Font propia . 134

Introduccio

El present document constitueix el Treball de Fi de Grau titulat ”Migracio

d’un sistema ERP per a una empresa del sector de mobles de disseny”, cor-

responent al Grau d’Enginyeria Informatica de la Facultat d’Informatica de

Barcelona (FIB), i basat en el projecte desenvolupat a traves d’un conveni

de cooperacio educativa a l’empresa ForgeFlow.

Al llarg del document es defineixen tots els aspectes relacionats amb la

gestio del projecte, com la seva contextualitzacio, abast i planificacio. Segui-

dament s’identifiquen i s’analitzen els principals factors crıtics d’exit i riscos

del projecte, aixı com tambe s’aprofundeix en els elements claus involucrats

en aquest. Finalment s’especifica el desenvolupament del proces de migracio

realitzat, documentant-ne les seves fases, i es presenten les conclusions del

treball.

13

Capıtol 1

Gestio del Projecte

1.1 Contextualitzacio

1.1.1 ForgeFlow S.L.

ForgeFlow [1] (anteriorment Eficent S.L.) es una empresa fundada l’any 2015

a Barcelona, Espanya, de la ma del seu actual CEO, en Jordi Ballester Alo-

mar. Actualment amb seu a Barcelona i impacte internacional, la seva missio

es la d’oferir serveis de consultoria TI i de negoci especialitzats principalment

en el sistema ERP Odoo.

La seva especialitzacio i notable experiencia fa que actualment sigui Silver

Partner d’Odoo, essent el que mes conferencies ha realitzat en esdeveniments

oficials. Tanmateix, dins de l’ecosistema d’empreses especialitzades en el

sistema, es troben entre els deu majors contribuıdors de programari.

1.1.2 Odoo

Odoo [2] es un sistema ERP integrat, format per aplicacions/moduls indivi-

duals que empaqueten funcionalitats i models de dades especıfics per a una

area funcional de l’empresa, o be per a uns processos concrets. Aquesta es-

tructura modular permet que el sistema sigui molt flexible, ja que totes les

aplicacions estan dissenyades per a integrar-se perfectament al sistema i, al-

hora, entre elles. Aixı, tot i ser un software ERP, Odoo inclou tambe moduls

oficials de CRM, MRP, o e-commerce, entre molts d’altres [3].

14

1.1. CONTEXTUALITZACIO

Des dels inicis el sistema va ser distribuıt sota la llicencia de software lliure

GNU GPL, pero al 2014 l’empresa va decidir modificar el seu model de negoci.

Per una banda, van modificar la marca a el nom actual, Odoo, mentre que un

any mes tard, al 2015, van adoptar un model de negoci open core [4]. Aixı,

des d’aleshores i fins a dia d’avui, hi ha disponibles milers de moduls especıfics

desenvolupats per contribuıdors i partners [5], els quals segueixen les pautes

marcades per la principal associacio que dona suport al desenvolupament

col·laboratiu d’Odoo, la Odoo Community Association(OCA [6]). Basats en

el model de negoci, es distribueixen actualment dues versions del sistema [7]:

• Odoo Community Edition: Versio de codi obert amb funcionalitats

limitades i sense suport oficial, distribuıda sota llicencia GNU LGPL

v3.

• Odoo Enterprise Edition: Versio de pagament de subscripcio per

nombre d’usuaris i aplicacions utilitzades, oferint suport oficial. Esta

distribuıda sota la llicencia Odoo Enterprise Edition License v1.0 i

basada en la versio comunitaria.

En la Seccio 3 del document s’entra mes en detall en l’arquitectura i funciona-

ment del sistema per tal d’obtenir una visio tecnica que faciliti la comprensio

del contingut del treball. Tanmateix, en la Seccio 4 s’aprofundeix en l’aspec-

te legal d’Odoo, aixı com d’altres recursos involucrats en el projecte, des del

punt de vista de les llicencies de distribucio.

1.1.3 Empresa client

L’empresa client del projecte relacionat amb el present treball, la identitat de

la qual s’ha anonimitzat per a preservar-ne la confidencialitat, es una empre-

sa internacional dedicada al disseny i comercialitzacio de mobiliari elegant

d’oficina i de la llar. Amb operacio a nivell mundial, juntament amb una

gran oferta de productes i configuracions per al client final, l’empresa utilit-

za actualment el sistema Odoo per a la seva gestio interna, aixı com per a la

comunicacio amb proveıdors i la comercialitzacio. En consequencia, aquest

esdeve no nomes una peca central en el funcionament de la organitzacio, sino

tambe l’element clau per a l’operativa de la cadena seva logıstica.

15


1.1.4 Problema a resoldre

Com a partner oficial d’Odoo, ForgeFlow ofereix la seva consultoria a nivell

global, treballant amb una amplia varietat de clients d’ambit internacional.

L’empresa client va contactar amb ForgeFlow per sol·licitar els seus serveis

en la seva situacio actual, on es troben amb dues problematiques principals:

1. El sistema que utilitzen es la versio 10.0 d’Odoo, llancada l’any 2016,

el suport oficial de la qual ja ha expirat. La versio mes actualitzada i

estable en el present es la 13.0, tot i que aquest mes d’octubre del 2020

s’acaba de llancar la 14.0 [8].

2. La implementacio actual, realitzada per una empresa externa, conte

moduls i configuracions especıfiques, la majoria sense documentar, que

caldria adaptar a una versio actualitzada d’Odoo. A mes, alguns pre-

senten problemes d’usabilitat o mancances en l’ajustament als proces-

sos de negoci.

1.1.5 Actors implicats

En el marc del projecte es poden identificar diverses parts interessades, les

quals es veuran influenciades pel seu desenvolupament i prendran rols es-

pecıfics:

• Empresa client: Esdeve el principal beneficiat del projecte, rebent

el servei esperat per tal de solucionar les seves problematiques i poder

operar amb un sistema actualitzat.

• Clients i proveıdors de l’empresa client: L’us d’un sistema ac-

tualitzat comportara una millor operativa de l’empresa, la qual te un

impacte directe amb la qualitat del servei ofert en la seva comercialit-

zacio de productes, aixı com en la gestio amb els seus proveıdors.

• ForgeFlow S.L.: Essent l’empresa implantadora de la solucio, es be-

neficiara tant dels recursos economics adquirits a canvi del servei ofert

com dels intangibles com l’experiencia o la reputacio de la feina feta.

16


• Director i Ponent: El director (Jordi Ballester) i el ponent (Joan

Antoni Pastor) actuaran com a guia i suport en el desenvolupament

del Treball de Fi de Grau, amb un interes directe en que el projecte

sigui un exit.

17

1.2. JUSTIFICACIO

1.2 Justificacio

Tot i que la justificacio del projecte ve principalment marcada per la demanda

del client, es essencial que s’avaluın les potencials alternatives que es podrien

considerar, amb l’objectiu final d’oferir l’assessorament i servei de major

qualitat.

1.2.1 Adquisicio d’un nou sistema

Adquirir un nou sistema ERP suposaria una serie d’impactes a diferents

nivells:

• Financer: Adquirir un nou sistema suposaria una inversio de recursos

financers en tres fases: una investigacio de mercat per trobar una solu-

cio adequada als requeriments de l’empresa, l’adquisicio del producte,

i posteriorment la seva implantacio.

• Temporal: Segons l’informe del 2020 de Panorama Consulting [9],

la mitjana dels projectes d’implantacio es sol situar al voltant dels 12

mesos, i practicament la meitat dels projectes s’allarguen un 33% mes

del previst.

• Huma: En aquesta dimensio cal destacar el risc derivat de la re-

sistencia al canvi per part dels treballadors, els quals seran els usu-

aris directes del sistema. Tenint en compte que ja estan familiaritzats

amb l’Odoo, un canvi d’aquestes caracterıstiques suposaria haver de

gestionar-ne la seva adaptacio i formacio a un nou entorn.

1.2.2 Implantacio des de zero d’una nova versio d’O-

doo

Aquesta alternativa suposaria un impacte menor a l’anterior, ja que no seria

necessari un analisi de mercat inicial per escollir un nou producte, aixı com

potencialment tampoc es requeriria una gran gestio de resistencia al canvi.

Tot i aixo, a nivell temporal i de recursos, suposaria implementar de nou tota

la logica actual de zero, sense reutilitzar cap part del codi existent, pel que

18

1.2. JUSTIFICACIO

es requeriria un analisi molt mes profund a nivell de negoci i augmentaria

considerablement la complexitat i duracio del projecte.

1.2.3 Seguir operant amb la versio actual

Tot i que aquesta alternativa es factible i eficac a curt termini, seguir operant

amb la versio actual comportara inherentment una obsolescencia del sistema

amb el pas del temps, ja que no nomes Odoo deixa d’oferir el suport en versi-

ons antigues, sino que l’ecosistema d’empreses clients i consultores d’aquest

es centraran en oferir la major qualitat amb les ultimes actualitzacions. Cal

destacar tambe que Odoo esta basat en el llenguatge Python, i mentre que

Odoo 10 opera amb la versio 2.7, Odoo 13 utilitza ja les versions 3.X, que

son les mes actualitzades.

En consequencia, no apostar per una actualitzacio del sistema no nomes

limita a l’empresa en la seva operativa, ja que no poden disposar de les

millores introduıdes tant a nivell de rendiment com d’aplicacions, sino que

amb el pas del temps la dificultat per desenvolupar una migracio incrementa

cada vegada mes rapid.

1.2.4 Conclusio

Tenint presents els interessos de l’empresa client, les alternatives proposades

no son prou eficients, ja sigui per un major cost o be per una major com-

plexitat, que no aportaria avantatges significatius respecte a una migracio.

D’aquesta forma, la solucio proposada permetra:

• Seguir una metodologia iterativa, on gracies a la modularitat del sis-

tema es pugui desenvolupar el proces de forma incremental, aixı com

realitzar proves constantment.

• Adequar els processos de negoci actuals a la nova versio del sistema,

podent reutilitzar aquella logica ja implementada que no requereixi

modificacio, i identificant les potencials millores al llarg del proces.

• Operar en una versio millorada del sistema, la qual ofereix una major

19

1.2. JUSTIFICACIO

usabilitat i varietat de funcionalitats, juntament amb un major rendi-

ment i fiabilitat gracies a l’us de tecnologia mes actualitzada.

20

1.3. ABAST

1.3 Abast

Identificades les problematiques que l’empresa client vol resoldre, es essencial

definir els objectius principals que s’espera assolir amb el projecte, aixı com

els requisits que ha d’assegurar. Tanmateix, cal destacar els principals riscos

associats a la seva gestio i desenvolupament.

1.3.1 Objectius

Obj 1: Migrar el sistema Odoo de la versio 10.0 a la 13.0.

Obj 1.1: Analitzar el funcionament actual dels moduls.

Obj 1.2: Implementar les modificacions requerides per a la migracio.

Obj 1.3: Dissenyar i aplicar les proves que assegurin un correcte fun-

cionament del sistema.

Obj 1.4: Garantir el compliment dels requisits del client en la posada

en marxa del sistema final.

Obj 2: Identificar oportunitats de millores tecniques i de proces.

Obj 2.1: Identificar potencials millores en la logica actual del sistema.

Obj 2.2: Identificar potencials millores resultants de les noves funcio-

nalitats afegides en la migracio.

Obj 2.3: Capturar i gestionar les millores identificades per a la seva

avaluacio i implementacio.

Obj 3: Gestionar adequadament el risc del projecte.

Obj 3.1: Identificar els potencials riscos del projecte.

Obj 3.2: Analitzar l’impacte dels riscos identificats.

Obj 3.3: Proposar accions per a la prevencio dels riscos en el cas que

sigui possible.

Obj 3.4: Proposar accions per a la resolucio de la incidencia derivada

d’un risc, o be per minimitzar-ne el seu impacte.

21

1.3. ABAST

1.3.2 Requisits

Del producte

• Mantenir la completa operabilitat del sistema.

• Mantenir la correcta integracio entre el sistema del client i els dels seus

proveıdors.

• Mantenir la integritat de totes les dades presents al sistema.

• Assegurar la seguretat de les dades i processos de negoci implicats al

llarg de la migracio.

• Aplicar les modificacions a nivell d’interfıcie i/o logica proposats pel

client per a millorar l’eficiencia dels processos.

• Desfer-se dels moduls obsolets, que no s’utilitzin, o que no es vulguin

utilitzar en el nou sistema.

Organitzatius

• Garantir el correcte seguiment de la planificacio definida.

• Implementar el projecte seguint la metodologia proposada.

• Mantenir una comunicacio constant entre ForgeFlow i l’empresa client.

22

1.3. ABAST

1.3.3 Riscos

Una de les part mes crıtiques en la gestio de qualsevol projecte, pero especial-

ment en l’ambit de les TI, es la gestio dels riscos. A continuacio s’identifiquen

els principals que potencialment apareixeran en el projecte:

• Riscos temporals: No mantenir els terminis especificats en la pla-

nificacio inicial, fet que suposaria un augment del cost del projecte.

Aprofitant-se de la comunicacio constant associada a la metodologia

agil, juntament amb les adequades eines de gestio, aquest risc es mini-

mitzara. En el cas que es produeixin desviacions, caldra assegurar-ne

el coneixement per part del client.

• Riscos de rendiment: Que el codi migrat no funcioni correctament.

Per minimitzar aquest risc es seguira una metodologia incremental que

permeti realitzar proves constants i incrementals de les modificacions,

aixı com un suport post-desplegament del projecte.

• Riscos de gestio del projecte: Que la comunicacio amb el client no

sigui efectiva, degut a que es realitza remotament i en un altre idioma

(angles). Aquest risc esta principalment minimitzat gracies a l’alta

experiencia de ForgeFlow en projectes internacionals, pero alhora un

membre de l’equip es desplacara per a donar suport in situ.

• Riscos d’integritat de les dades: Les dades del sistema son una peca

clau en el proces de migracio, ja que no assegurar-ne la seva integracio

i seguretat pot suposar grans consequencies per al client, i obviament

per a ForgeFlow. Per a minimitzar el risc es realitzara una adequada

administracio de la base de dades, aixı com treballar en un entorn

controlat i aıllat per assegurar que no es perd ni es transmet informacio

a l’exterior.

A banda dels principals riscos generals identificats, a la Seccio 2 es desenvo-

lupa un analisi mes profund dels factors crıtics d’exit del projecte i els seus

riscos associats, amb propostes per al seu control.

23

1.4. METODOLOGIA I RIGOR

1.4 Metodologia i rigor

1.4.1 Metodologia de treball

Al llarg dels ultims anys les metodologies agils s’han popularitzat en el desen-

volupament de projectes, especialment en l’ambit de les TI. Un dels informes

mes rellevants sobre aquestes, el State of Agile Report, destaca en l’edicio d’a-

quest any 2020 [10] que el 95% de les empreses enquestades ja implementen

metodologies agils, destacant entre les majors avantatges per la seva adopcio

caracterıstiques com un increment de la productivitat, i una reduccio del risc

del projecte.

Mes enlla dels avantatges que demostren aportar a nivell general, hi ha

varies raons per les quals una metodologia agil pot ser adequada per aquest

projecte:

• El grup de treball involucrat en el projecte es reduıt (7 integrants),

fent que la transparencia i comunicacio constant dins d’aquest i amb el

client, claus en les metodologies agils, es vegi facilitada.

• ForgeFlow ja te experiencia utilitzant aquesta metodologia, pel que

tenen el coneixement i mitjans requerits per aplicar-la.

• En el marc de la FIB, la filosofia de les metodologies agils es tractada

en assignatures com Disseny de Sistemes d’Informacio (DSI), on fins i

tot es profunditza en una de les mes conegudes, l’SCRUM. Aixı, es ga-

ranteix que l’autor d’aquest treball disposa tambe dels principis basics

per aplicar-la.

• La metodologia iterativa i incremental permetra mantenir un major

control i una millor gestio dels riscos del projecte.

Tot i els avantatges de les metodologies agils, hi ha certes fases del projec-

te que no poden seguir aquesta dinamica iterativa i incremental, com per

exemple l’analisi i planificacio inicial del projecte. Aixı doncs, es segueix una

metodologia hıbrida al llarg del proces, les fases del qual es poden agrupar

a nivell general en cinc etapes:

24


• Analisi inicial: Identificacio general dels moduls que cal migrar al nou

sistema, avaluant la possibilitat de poder-los migrar i la complexitat del

proces. Tanmateix, es desenvolupen una serie de reunions amb usuaris

clau dels diferents departaments de l’empresa client, amb l’objectiu

d’obtenir informacio sobre els principals processos de negoci suportats

pel sistema.

• Migracio dels moduls i la base de dades: Aplicant una meto-

dologia iterativa i incremental, es migren els moduls en un entorn

especıfic de migracio amb l’objectiu d’obtenir una versio operativa

del sistema en la versio 13.

• Validacio d’usuaris clau: A partir dels moduls migrats i en un

entorn especıfic, seguint una metodologia iterativa i incremental es

desenvolupa un proces integral de validacio, amb la involucracio directa

dels usuaris clau del client.

• Desplegament i suport: Finalment es desplega la migracio a l’entorn

de produccio final i s’ofereix un suport post-desplegament, per tal de

gestionar potencials incidencies derivades del proces.

En paral·lel a les etapes principals del projecte, es duen a terme una serie

de fases destinades al desenvolupament de material formatiu pels usuaris de

l’empresa client, aixı com per al control de l’execucio del projecte. Totes les

fases del projecte i el seu ordre d’execucio queden definides en la planificacio

a la Seccio 1.5.

1.4.2 Metodologia de migracio

A nivell tecnic la migracio es basa en un proces l.lift and shift”, realitzant els

canvis estrictament necessaris per mantenir la compatibilitat de les funcio-

nalitats i dades presents en l’actual sistema. Tot i aixo, com s’ha esmentat

anteriorment, s’identificaran potencials millores i s’avaluara la seva imple-

mentacio en el projecte. El proces de migracio contempla principalment dos

elements: la base de dades i els moduls.

25


1.4.2.1 Base de dades

La migracio de la base de dades consisteix en aplicar les modificacions reque-

rides per tal d’assegurar que aquesta es compatible amb la versio actualitzada

del sistema. Aquestes modificacions s’apliquen a l’estructura de les dades em-

magatzemades, i son consequencia de canvis en els models de dades definits

pels moduls en la versio 13. El proces per assolir aquesta tasca es basa en el

projecte OpenUpgrade, el qual es tracta en la Seccio 5.3.1.

1.4.2.2 Moduls

La migracio consisteix en mantenir la operabilitat dels moduls del sistema

del client a la versio 13. Tot i que a la Seccio 3 s’entrara mes en detall en

l’estructura tecnologica d’Odoo, dins del sistema utilitzat pel client troba-

rem tres tipologies diferents de moduls, els quals requeriran d’una estrategia

especıfica:

• Moduls core : Son els moduls desenvolupats i mantenguts per Odoo

S.A. Degut a que ja estan disponibles en la versio corresponent el seu

codi no requereix un proces de migracio, pero cal obviament considerar-

los en la migracio de la base de dades.

• Moduls custom : Moduls desenvolupats a mida per al client a traves

d’una empresa externa. El seu manteniment no esta suportat per cap

entitat i esdevenen els principals involucrats en el proces de migracio,

tant pel que fa al seu codi com en els consequents canvis en la base de

dades.

• Moduls de tercers: Moduls desenvolupats i mantenguts per tercers,

ja siguin privatius o publicament accessibles (per exemple els desenvo-

lupats per la Odoo Community Association). En el cas d’estar dispo-

nibles a la nova versio simplement caldra adquirir-los (si son de paga-

ment) o descarregar-los, sense necessitat de desenvolupar cap migracio

especıfica. Tot i aixo, en el cas contrari, caldra avaluar potencials al-

ternatives.

26

1.5. PLANIFICACIO

1.5 Planificacio

En el transcurs del cicle de vida del projecte s’han hagut de realitzar una serie

d’ajustaments a la planificacio inicial proposada, la qual es pot trobar anne-

xada al final del document. Aquests ajustaments, especificats a continuacio,

defineixen la planificacio final del projecte. Tanmateix, en aquesta seccio es

quantificaran les desviacions referents als costos resultants dels ajustaments

realitzats.

1.5.1 Ajustaments d’estructura

En l’ambit academic en el qual s’emmarca aquest treball de final de grau,

una de les tasques inicials es el desenvolupament d’una planificacio inicial.

Aquesta, tot i seguir les directrius requerides per part de la Gestio de Pro-

jectes, es va desenvolupar en una fase previa a la formalitzacio oficial d’una

planificacio del projecte en el qual es basa. Per aquest motiu, en aquesta

seccio es defineixen els ajustaments estructurals a la presentada inicialment.

Els ajustaments d’estructura s’apliquen principalment en la definicio de

fases i tasques de la planificacio, justificats a continuacio:

• Fase 1 - Gestio del Treball (original): S’afegeix a la Fase 1 la tas-

ca originalment definida a la Fase 10, referent a la documentacio del

projecte. Aquest canvi permet ajuntar en una unica fase les tasques

orientades propiament al desenvolupament del Treball de Fi de Grau.

La Fase 10 original queda doncs eliminada.

• Fase 5 - Inici del projecte de migracio (nova): S’afegeix una nova

Fase 5 per a definir la tasca corresponent a la reunio de kick off del

projecte, amb l’objectiu que aquesta quedi destacada en la planificacio.

• Fase 6 - Preparacio de la infraestructura (original): Les tasques

de setup de servidors s’unifiquen en una sola, ja que s’utilitza el mateix

servidor per a preparar la migracio i realitzar els processos de validacio.

27

1.5. PLANIFICACIO

• Fase 8 - Analisi de processos (nova): S’afegeix una nova fase previa

a la migracio dedicada a l’analisi dels processos empresarials de l’em-

presa client. Aquesta permetra adquirir informacio clau per facilitar la

migracio i documentacio dels moduls, minimitzar els potencials errors,

i agilitzar el proces general.

• Fase 9 - Migracio de la base de dades (nova): S’afegeix una nova

fase per destacar a la planificacio la diferenciacio entre el proces de

migracio de la base de dades i el dels moduls, tot i que ambdos estaran

correlacionats.

• Fase 10 - Migracio dels moduls (nova): Idem de la justificacio

anterior, es defineix una tasca per a la migracio dels moduls, seguint la

referencia de la Fase 7 original.

• Fase 11 - Documentacio de processos (nova): S’afegeix una no-

va tasca de documentacio orientada al desenvolupament de material

formatiu per als usuaris. Aquesta fase es fruit d’un acord que es duu

a terme entre ForgeFlow i el client en la definicio final de l’abast del

projecte.

• Fase 12 - Proces de Validacio (nova): S’afegeix una nova fase de-

dicada a la validacio dels moduls migrats. Aquesta s’afegeix per a des-

acoblar aquestes tasques de la fase de migracio. Tanmateix, en acord

entre les parts involucrades es decideix usar l’eina software Jira [11]

per a la gestio de les incidencies detectades en aquesta fase.

• Fase 9 - Suport Post Go-live (original): La tasca de formacio queda

eliminada de la fase ja que aquesta es desenvolupa principalment a

traves del material resultant de la Fase 11 - Documentacio de processos.

Finalment, queda en aquesta fase una unica tasca centrada en el suport

i resolucio d’incidencies posteriors al desplegament oficial.

A consequencia dels canvis, les tasques originalment plantejades poden veure

la seva nomenclatura modificada.

28

1.5. PLANIFICACIO

1.5.2 Ajustaments temporals

En el transcurs del desenvolupament del projecte, l’estimacio inicial de les

tasques principals del projecte s’ha mostrat molt acurada. Tot i aixo, varis

factors han provocat la desviacio temporal en algunes d’elles, aixı com tambe

l’aparicio de noves tasques, consequentment allargant la duracio i dedicacio

total. D’aquesta forma, s’especifiquen a continuacio els ajustaments tempo-

rals necessaris, seguint el format utilitzat per als ajustaments d’estructura:

• Fase 5 - Inici del projecte de migracio (nova): La nova tasca

afegida en aquesta fase correspon a una duracio de 3 hores.

• Fase 8 - Analisi de processos (nova): La tasca dedicada a l’analisi

inicial dels processos claus de l’empresa client, comporta una dedicacio

important en els inicis del projecte, i acaba sent de 28 hores. Degut

a la dependencia dels usuaris clau del client en aquesta tasca, tot i

el nombre d’hores dedicades aquesta s’acaba estenent al llarg de les

primeres 4 setmanes a partir del kick off oficial. Cal destacar, pero, que

aquest analisi permet reduir la planificacio d’hores inicial en l’analisi

dels moduls per a la migracio.

• Fase 9 - Migracio de la base de dades (nova): Gracies a l’us del

projecte OpenUpgrade, la dedicacio d’hores a aquesta fase esta princi-

palment centrada a preparar els scripts d’OpenUpgrade, els quals han

d’anar adaptant-se per adaptar l’esquema de la base de dades a la versio

13. Al tractar-se d’una fase relacionada amb la migracio dels moduls,

comprendra al llarg del temps la mateixa duracio. La informacio rela-

tiva al projecte OpenUpgrade es pot trobar a la Seccio 5.3.1.

• Fase 10 - Migracio dels moduls (nova): La fase dedicada a la mi-

gracio dels moduls suposa la part principal del projecte, agrupant tas-

ques de migracio, documentacio i prova d’aquests. Duent-se a terme

de forma iterativa i incremental, en quatre fases, es dediquen aproxi-

madament tres setmanes per cada una. Tanmateix cal considerar les

vacances de nadal, ja que degut a la pandemia varis membres de l’equip

les havien de recuperar. Aixo fa alentir dues setmanes els temps de la

migracio dels moduls.

29

1.5. PLANIFICACIO

• Fase 11 - Documentacio de processos (nova): La nova fase de

documentacio de processos es desenvolupa en paral·lel a la migracio

dels moduls, amb una dedicacio total de 256h.

• Fase 12 - Proces de Validacio (nova): El proces de validacio es

desacobla de la Fase de Proces de Migracio de la planificacio inicial

presentada, i s’especifica amb mes precisio les tasques involucrades.

Per part de ForgeFlow, les hores a dedicar corresponen principalment

a la resolucio d’incidencies sorgides del proces de validacio, mentre

que la validacio en si es desenvolupada ıntegrament pels usuaris clau.

Aixı, com que la responsabilitat d’aquesta ultima tasca es del client, en

comptes d’estimar unes hores concretes s’habilita un perıode de dues

setmanes per a cada iteracio de la fase de validacio, en la qual han de

dur-la a terme. Per part de ForgeFlow, el perıode de resolucio d’in-

cidencies s’habilita en una setmana posterior a cada fase de validacio,

amb una estimacio per iteracio de 40h.

Com a consequencia de les desviacions, el projecte de migracio

s’acaba estimant en 8 mesos.

1.5.3 Afegiment de recursos

Pel que fa a l’afegiment de nous recursos, s’especifica en la categoria de fısics

la contractacio del servidor virtual privat, tenint en consideracio el cost oficial

del servei. Tanmateix, pel que fa a software, Jira es considera per al proces

de validacio, pero el seu cost sera cobert per l’empresa client.

Recurs Cost Mensual Cost Total

Servidor Virtual Privat (VPS) 12.10 AC [12] 96.80 AC

Jira (JI) — —

Taula 1: Cost del servidor de migracio. Font propia.

30

1.5. PLANIFICACIO

1.5.4 Planificacio final del projecte

A continuacio es mostra la planificacio final del projecte amb els ajustaments

incorporats. La versio final del Diagrama de Gantt es pot trobar en la Seccio

D de l’annex.

1.5.4.1 Consideracions generals

Per tal d’introduir les principals tasques a realitzar en el projecte, es essencial

definir unes marques temporals claus que guien la seva planificacio:

• Inici del conveni:

22 de setembre de 2020

• Finalitzacio del conveni:

9 de marc de 2021

• Equip de treball:

7 persones

• Finalitzacio del treball:


• Data lectura del treball:


• Duracio temporal estimada

del projecte:

8 mesos

Degut a que els membres de l’equip no dedicaran la totalitat de la seva

jornada unicament el projecte, la dedicacio diaria de l’equip anira variant

en funcio de les necessitats, sempre amb l’objectiu de complir les dates lımit

establertes amb el client.

1.5.4.2 Descripcio de les tasques

Les diferents tasques es descriuran i s’agruparan en les principals fases que

comprendra el projecte. La seva estimacio temporal i recursos associats es

pot trobar a les Taules 2 i 3. Finalment, la nomenclatura emprada en l’es-

pecificacio de les tasques segueix la seguent referencia:

Fx Fase numero x del projecte.

Tx.y Tasca numero y de la fase x del projecte.

31

1.5. PLANIFICACIO

F1 — Gestio del treball

La gestio del projecte, des del punt de vista del Treball de Fi de Grau derivat,

s’estendra al llarg de tot el seu temps de vida.

T1.1 - Contextualitzacio i abast del projecte: Documentacio cor-

responent a la definicio de la contextualitzacio i abast del projecte.

T1.2 - Planificacio temporal: Documentacio de la planificacio i esti-

macio temporal del projecte, a partir de l’analisi inicial d’aquest.

T1.3 - Gestio economica i analisi de sostenibilitat: Documentacio

del pressupost i analisi de sostenibilitat associats al projecte, en

base a les tasques, estimacions i recursos definits en la planificacio

temporal.

T1.4 - Integracio final de la gestio: Integracio dels documents desen-

volupats en les tasques T1.1, T1.2 i T1.3, incorporant les modifi-

cacions derivades de la seva avaluacio.

T1.5 - Reunions de seguiment amb el director: Realitzacio de reu-

nions amb el director del projecte. Tot i que es realitzaran pe-

riodicament i a conveniencia, s’estima que es duguin a terme una

hora setmanalment.

T1.6 - Reunions de seguiment amb el ponent: Realitzacio de reu-

nions amb el ponent, recurrents al llarg de la seva duracio, per

al correcte seguiment del treball. Tot i que es realitzaran pe-

riodicament i a conveniencia, s’estima una dedicacio d’una hora

mensual.

T1.7 - Documentacio del treball realitzat: Documentacio del treball

en base a l’execucio del projecte, que es realitzara en paral·lel al

llarg d’aquest. S’estima una dedicacio de dues hores setmanals.

F2 — Formacio inicial en el sistema Odoo

T2.1 - Lectura de documentacio oficial: Lectura i comprensio de la

documentacio oficial de desenvolupament [13].

32

1.5. PLANIFICACIO

T2.2 - Desenvolupament tecnic i funcional: Realitzacio d’activitats

interactives a nivell funcional i de desenvolupament, en base a la

plataforma d’e-learning [14].

F3 — Estimacio inicial del projecte

Fase ja iniciada en el moment en que s’inicia el conveni, orientada a realitzar

un breu analisi preliminar dels moduls involucrats en el proces.

T3.1 - Estimacio dels moduls: Identificacio i avaluacio inicial dels

moduls que s’han de migrar, estimant-ne la potencial complexitat

associada.

T3.2 - Proposta de planificacio de migracio: Estimacio de la pla-

nificacio temporal de la migracio, partint de l’avaluacio resultant

a la tasca anterior, per a la validacio per part del client de la

proposta final.

F4 — Gestio dels riscos del projecte

T4.1 - Identificacio dels riscos: Identificacio dels principals riscos in-

volucrats en aquesta tipologia de projecte.

T4.2 - Avaluacio i control dels riscos: Analitzar l’impacte dels riscos

identificats i avaluar possibles accions per tal de contenir-los i/o

evitar-los.

F5 — Inici del projecte de migracio

T5.1 - Reunio Kick Off: Realitzacio de la reunio inicial del projecte, en

la qual es presenten els objectius, abast, metodologia i planificacio

inicial d’aquest. S’hi involucra tot l’equip de treball, juntament

amb el client.

F6 — Gestio del canvi

Fase orientada al control i la gestio dels potencials canvis del projecte, ja

siguin incidencies derivades o la captacio de nous requisits, desenvolupada al

llarg de tot el projecte.

33

1.5. PLANIFICACIO

T6.1 - Reunions de seguiment amb el client: La gestio del pro-

jecte ha d’incloure les principals parts interessades del projecte,

pel que la realitzacio de reunions sera constant al llarg d’aquest

(s’estima una hora setmanal). Tanmateix aquesta tasca inclou po-

tencialment la identificacio de nous requisits, avaluacio de la seva

viabilitat dins l’abast del projecte, i modificacio de la planificacio

a conveniencia.

F7 — Preparacio de la infraestructura

T7.1 - Setup del servidor de migracio: Contractacio i configuracio

del servidor utilitzat per al proces de migracio.

T7.2 - Backup de la base de dades: Realitzacio de la copia de la base

de dades del client per a utilitzar-la com a base en el proces de

migracio.

F8 — Analisi de processos

T8.1 - Reunions amb key users: Realitzacio de reunions amb els usu-

aris clau dels diferents departaments de l’empresa client, amb

l’objectiu d’entendre i captar els principals fluxos de negoci de

l’empresa i la seva execucio en el sistema.

F9 — Migracio de la base de dades

Fase dedicada a la migracio de la base de dades a un sistema Odoo 13, seguint

el proces definit en la metodologia.

T9.1 - Preparacio dels scripts d’OpenUpgrade: Preparacio dels

scripts de migracio emmarcats dins del projecte d’OpenUpgrade

per assolir la correcta migracio de la base de dades, contemplant

els moduls d’Odoo.

F10 — Proces de migracio dels moduls

Fase principal del projecte, desenvolupada de forma iterativa i incremental

en quatre iteracions, on en cada iteracio es considera un conjunt de moduls

custom del client. Per cada modul es desenvolupen les seguents tasques:

T10.1 - Analisi inicial: Analisi del funcionament actual del modul.

34

1.5. PLANIFICACIO

T10.2 - Migracio del codi: Implementacio de les modificacions en el

codi per al correcte funcionament del modul a la nova versio.

T10.3 - Desenvolupament scripts de migracio: Davant de canvis re-

llevants en l’estructura de les dades definides pel modul, cal desen-

volupar els scripts de migracio requerits per assegurar la compa-

tibilitat de la base de dades a aquests canvis.

T10.4 - Documentacio tecnica: Desenvolupament de la documentacio

tecnica basica del modul.

T10.5 - Proves unitaries i d’integracio: Creacio i realitzacio de proves

unitaries per tal d’assegurar el funcionament integral de modul.

Tanmateix, a traves del servidor de migracio, es desenvolupen

proves d’integracio amb altres moduls. Aquesta tasca s’estima

la major en dedicacio, ja que permet detectar i solucionar errors

produıts en la migracio del codi.

F11 — Documentacio de processos

Fase orientada al desenvolupament de documentacio de suport i formativa

per als usuaris, relativa a l’execucio dels processos identificats en la Fase 8

en la nova versio del sistema. Aquesta servira tambe com a guia per a que

els usuaris clau puguin, en una fase posterior, realitzar la validacio funcional

dels moduls.

T11.1 - Documentacio d’usuari: Desenvolupament de documentacio

funcional d’usuari.

T11.2 - Desenvolupament de material formatiu: Desenvolupament

d’elements formatius en format audiovisual.

F12 — Proces de validacio

Fase de validacio de la migracio, desenvolupada de forma iterativa i incre-

mental en un sistema de proves, amb la involucracio directa dels usuaris clau.

Concretament, es realitzaran quatre iteracions d’aquesta, on en cada una el

percentatge de moduls involucrats s’incrementara (20%, 40%, 70%, 100%).

35

1.5. PLANIFICACIO

T12.1 - Validacio funcional de key users: El client validara la correc-

ta migracio dels moduls a traves de proves end-to-end i donara el

vist-i-plau per a continuar amb la seguent iteracio. La documen-

tacio dels processos els servira com a guia per a dur a terme les

proves.

T12.2 - Correccio d’errors: Correccions requerides davant la deteccio

d’errors en el proces de validacio.

F13 — Desplegament

T13.1 - Go-live: Desplegament de la migracio a l’entorn de produccio, es

a dir l’entorn final en el que accedeixen i operen els usuaris finals.

F14 — Suport Post Go-live

T14.1 - Suport i resolucio d’incidencies: Suport als usuaris i resolucio

de potencials incidencies derivades del desplegament final.

1.5.4.3 Recursos emprats

• Humans

– Equip de desenvolupament (DT): Grup de treball de Forge-

Flow.

– Key users (KU): Usuaris clau del client involucrats en el pro-

jecte.

– Director del projecte / Project Manager (PM): CEO de

ForgeFlow, Jordi Ballester Alomar.

– Ponent del projecte (PP): Joan Antoni Pastor Collado.

• Fısics

– Ordinador (PC): Eina principal de treball.

– Oficina (OF): Espai principal de treball amb acces a Internet.

– Servidor Virtual Privat (VPS): Servidor emprat pel proces

de migracio.

36

1.5. PLANIFICACIO

• Software

– Gsuite (GO): Us d’eines d’ofimatica (Docs), emmagatzematge

al nuvol (Drive), correu electronic (Gmail) i videotrucades (Meet).

– Microsoft Teams (MT): Col·laboracio i comunicacio amb el

client.

– Element (EL): Col·laboracio i comunicacio dins l’equip de For-

geFlow.

– Odoo (OD): Sistema base per a la migracio i la realitzacio de les

proves associades.

– Git-Lab (GL): Repositori per a la gestio del codi derivat del

projecte.

– Jira (JI): Eina per a la gestio d’errors i incidencies detectades en

la fase de validacio.

1.5.4.4 Estimacio temporal

Partint de les tasques i fases definides en la seccio anterior, es representen en

les Taules 2 i 3 les estimacions temporals de les diverses tasques, discernint

entre el total d’hores realitzades per l’equip (T) i les realitzades per l’au-

tor del treball (P), les seves dependencies, i els recursos emprats per a la

seva realitzacio. Posteriorment, a la Seccio D de l’annex, es pot trobar la

representacio grafica de la planificacio en format de Diagrama de Gantt.

37

1.5. PLANIFICACIO

ID - Fase/Tasca Temps T - P Recursos Dependencies

F1 - Gestio del treball 138h - 138h

T1.1 - Contextualitzacio i abast del projecte 20h - 20h PC, GO —

T1.2 - Planificacio temporal 15h - 15h PC, GO T1.1

T1.3 - Gestio economica i analisi de sostenibilitat 15h - 15h PC, GO T1.1, T1.2

T1.4 - Integracio final de la gestio 10h - 10h PC, GO T1.1 - T1.3

T1.5 - Reunions de seguiment amb el director 24h - 24h PM, OF —

T1.6 - Reunions de seguiment amb el ponent 6h - 6h PP, PC, GO —

T1.7 - Documentacio del treball realitzat 48h - 48h PC, GO T5.1

F2 - Formacio inicial en el sistema Odoo 112h - 112h

T2.1 - Lectura de documentacio oficial 56h - 56h PC, OF —

T2.2 - Desenvolupament tecnic i funcional 56h - 56h PC, OF, OD —

F3 - Estimacio inicial del projecte 56h - 0h

T3.1 - Estimacio dels moduls 40h - 0h DT, PM, PC, OF, GO, EL —

T3.2 - Proposta de planificacio de migracio 16h - 0h PM, PC, OF, GO —

F4 - Gestio dels riscos del projecte 40h - 40h

T4.1 - Identificacio dels riscos 24h - 24h PC, GO, OF —

T4.2 - Avaluacio i control dels riscos 16h - 16h PC, GO, OF —

F5 - Inici del projecte de migracio 3h - 3h

T5.1 - Reunio Kick Off 3h - 3h KU, DT, PM, PC, OF, MT T3.2

F6 - Gestio del canvi 28h - 0h

T6.1 - Reunions de seguiment amb el client 28h - 0h KU, PM, PC, OF, MT T5.1

F7 - Preparacio de la infraestructura 16h - 0h

T7.1 - Setup del servidor de migracio 8h - 0h DT, PC, OF, EL, VPS T5.1

T7.2 - Backup de la base de dades 8h - 0h KU, DT, PC, MT, OF T5.1

F8 - Analisi de processos 28h - 28h

T8.1 - Reunions amb key users 28h - 28h KU, DT, PM, PC, OF, MT T5.1

F9 - Migracio de la base de dades 64h - 0h

T9.1 - Preparacio dels scripts d’OpenUpgrade 64h - 0h DT, PC, OF, GL, VPS, EL T7.1

Taula 2: Taula resum final de les tasques del projecte (I). Font propia.

38

1.5. PLANIFICACIO


F10 - Migracio dels moduls 992h - 328h

T10.1 - Analisi inicial 40h - 16h (x4) DT, PC, OF, GO, EL T5.1, T7.1, T7.2

T10.2 - Migracio del codi 80h - 24h (x4) DT, PC, OF, EL, OD, GL T10.1

T10.3 - Desenvolupament scripts de migracio 8h - 2h (x4) DT, PC, OF, EL, OD, GL T10.2

T10.4 - Documentacio tecnica 20h - 8h (x4) DT, PC, OF, EL, OD, GL T10.2

T10.5 - Proves unitaries i d’integracio 100h - 32h (x4) DT, PC, OF, EL, OD, GL, VPS T10.2

F11 - Documentacio de processos 256h - 104h

T11.1 - Documentacio d’usuari 128h - 64h DT, PC, OF, GO T8.1, T10.5

T11.2 - Desenvolupament de material formatiu 128h - 40h DT, PC, OF, GO T10.5, T11.1

F12 - Proces de validacio 160h - 16h

T12.1 - Validacio funcional de key users 0h - 0h (x4) KU, MT, OD, VPS, JI T10.5

T12.2 - Correccio d’errors (iteracio 1) 40h - 16h DT, PC, OF, EL, OD, GL, VPS, JI T12.1

T12.3 - Correccio d’errors (iteracions 2,3,4) 40h - 0h (x3) DT, PC, OF, EL, OD, GL, VPS, JI T12.1

F13 - Desplegament 8h - 0h

T13.1 - Go-live 8h - 0h DT, KU, PM, PC, OF, MT, OD, GL T12.3

F14 - Suport Post Go-live 80h - 0h

T14.1 - Suport i resolucio d’incidencies 80h - 0h DT, KU, PC, OF, MT, EL, OD, GL T13.1

TOTAL: 1,981h - 769h

Taula 3: Taula resum final de les tasques del projecte (II). Font propia.

39

1.6. GESTIO ECONOMICA I DESVIACIONS

1.6 Gestio economica i desviacions

La viabilitat economica d’un projecte esdeve clau per assegurar-ne la seva

rendibilitat final, pel que es imperatiu gestionar correctament els costos deri-

vats de la seva realitzacio, identificant-los, estimant el seu valor, i assegurant

el seu control davant potencials desviacions.

Fruit dels ajustaments especificats en la planificacio, en aquesta seccio es

presenta la gestio economica final, juntament amb les desviacions correspo-

nents dels costos en base al que es va desenvolupar en l’etapa inicial de la

Gestio del Projecte. El contingut de la gestio economica inicial, on es pre-

senten les estimacions inicials i el model de control dels costos, s’inclou a la

Seccio A.2.3 de l’annex.

1.6.1 Identificacio dels costos

Els principals costos del projecte estan associats als recursos necessaris per

a la seva implementacio, podent discernir-los en quatre categories.

1.6.1.1 Costos de Personal

Costos associats als principals rols de l’empresa involucrats en el projecte, es

a dir el Project Manager i l’equip de desenvolupament, format per Consultors

Tecnics i un Becari. Aquests, juntament amb el seu salari, es poden veure

especificats a la Taula 4.1

Rol Sou Brut (any) Sou Brut (h) Cost (h)

Project Manager 45,676.00 AC [16] 25.01 AC 32.52 AC

Consultor Tecnic 36,000.79 AC [17] 19.72 AC 25.63 AC

Becari — 9.00 AC 11.70 AC

Taula 4: Salaris dels rols involucrats al projecte. Font propia.

1Es consideren 1,826 hores laborals a l’any [15], aixı com un cost afegit del 30% referenta la cotitzacio de Seguretat Social.

40


1.6.1.2 Costos de Hardware

Costos associats als principals dispositius fısics utilitzats en el projecte. A la

Taula 5, s’especifica el seu cost unitari2, juntament amb el total, tenint en

compte els 7 membres involucrats. Per tal de definir la part del cost total que

cal imputar al projecte, s’especifica la part proporcional d’aquest que s’hi ha

destinat, considerant-ne l’amortitzacio al llarg de la seva vida util. Aquesta

s’estableix en 4 anys, i el cost es calcula seguint la seguent formula:

CostImputable = 1, 770horestotals ×CostTotal

4anys × 250dieslaborables × 8hores/dia

(1.1)

Recurs Cost Unitari Cost Total Cost Imputable

Ordinador Lenovo 1,100.00 AC 7,700.00 AC 1,703.63 AC

Auriculars Sony 30.00 AC 210.00 AC 46.46 AC

Taula 5: Costos associats als recursos hardware. Font propia.

1.6.1.3 Costos de Software

Costos associats al programari involucrat en la realitzacio del projecte, espe-

cificats en la Taula 6.3 Els recursos dels quals s’utilitza la seva versio gratuıta

no s’especifiquen com a despesa.

Recurs Cost Unitari Cost Total

Gsuite 9.36 AC/usuari/mes [18] 393.12 AC

Taula 6: Costos associats als recursos software. Font propia.

2Costos aproximats a partir de fonts internes.3Es consideren 8 mesos de projecte en base a la planificacio inicial (Seccio 1.5).

41


1.6.1.4 Costos Generics

Costos associats als recursos generics requerits per a desenvolupar el projecte,

que s’especifiquen a la Taula 7.2 3


Oficina (despeses incloses) 1,600.00 AC 9,600.00 AC

Servidor Virtual Privat (VPS) 12.10 AC [12] 96.80 AC

Taula 7: Costos associats als recursos generics. Font propia.

1.6.2 Estimacio final dels costos i desviacions

Els costos especificats a la Taula 8 estan desgranats en les hores dedicades

pels diversos rols, seguint la seguent nomenclatura:

• PM: Project Manager

• CT: Consultor Tecnic

• BE: Becari

Tots els imports de les despeses especificades a la Taula 8, aixı com en les des-

viacions, inclouen impostos i costos derivats de les cotitzacions a la Seguretat

Social.

42


ID - Tasca PM CT BE Import

T1.1 - Contextualitzacio i abast del projecte — — 20h 234.00 AC

T1.2 - Planificacio temporal — — 15h 175.50 AC

T1.3 - Gestio economica i analisi de sostenibilitat — — 15h 175.50 AC

T1.4 - Integracio final de la gestio — — 10h 117.00 AC

T1.5 - Reunions de seguiment amb el director — — 24h 280.80 AC

T1.6 - Reunions de seguiment amb el ponent — — 6h 70.20 AC

T1.7 - Documentacio del treball realitzat — — 48h 561.60 AC

T2.1 - Lectura de documentacio oficial — — 56h 655.20 AC

T2.2 - Desenvolupament tecnic i funcional — — 56h 655.20 AC

T3.1 - Estimacio dels moduls — 40h — 1,025.21 AC

T3.2 - Proposta de planificacio de migracio 16h — — 520.30 AC

T4.1 - Identificacio dels riscos — — 24h 280.80 AC

T4.2 - Avaluacio i control dels riscos — — 16h 187.20 AC

T5.1 - Reunio Kick Off 3h 15h 3h 517.11 AC

T6.1 - Reunions de seguiment amb el client 28h — — 910.52 AC

T7.1 - Setup del servidor de migracio — 8h — 205.04 AC

T7.2 - Backup de la base de dades — 8h — 205.04 AC

T8.1 - Reunions amb key users 28h 140h 28h 4,826.37 AC

T9.1 - Preparacio dels scripts d’OpenUpgrade — 64h — 1,640.34 AC

T10.1 - Analisi inicial — 96h 64h 3,209.31 AC

T10.2 - Migracio del codi — 224h 96h 6,864.40 AC

T10.3 - Desenvolupament scripts de migracio — 24h 8h 708.73 AC

T10.4 - Documentacio tecnica — 48h 32h 1,604.66 AC

T10.5 - Proves unitaries i d’integracio — 272h 128h 8,469.06 AC

T11.1 - Documentacio d’usuari — 64h 64h 2,389.14 AC

T11.2 - Desenvolupament de material formatiu — 88h 40h 2,723.47 AC

T12.1 - Validacio funcional de key users — — — 0.00 AC

T12.2 - Correccio d’errors (iteracio 1) — 24h 16h 802.33 AC

T12.3 - Correccio d’errors (iteracions 2,3,4) — 120h — 3,075.64 AC

T13.1 - Go-live 8h 8h — 465.19 AC

T14.1 - Suport i resolucio d’incidencies — 80h — 2,050.43 AC

Total CPA (Costos de Personal per Activitat) 45,605.30 AC

Taula 8: Costos de Personal per Activitat Totals Final. Font propia.

43


Desviacio dels Costos Hardware, Software i Generics

Figura 1: Costos de Hardware, Software i Generics Finals, i desviacions. Fontpropia

Desviacio dels Costos de Personal i d’Hores per Activitat

Figura 2: Costos de Personal per Activitat Finals i desviacions. Font propia

44


Desviacio dels Costos Totals

Figura 3: Costos Totals Finals i desviacions. Font propia

Tal i com es pot observar en les imatges, on es mostra el control dels

costos a traves d’una interfıcie de calcul, les modificacions en la planificacio i

els ajustaments de les tasques ha provocat desviacions en els diferents nivells.

Finalment, pero, la desviacio en el total dels costos (CPA + CG) ha estat

menor que la contingencia afegida en un principi, pel que dins d’aquest marge

el projecte es pot mantenir dins del pressupost inicialment establert.

45

1.7. SOSTENIBILITAT I COMPROMIS SOCIAL

1.7 Sostenibilitat i compromıs social

L’interes general per la sostenibilitat es cada vegada mes notori en la societat,

ja sigui a traves de la polıtica, els valors transmesos per organitzacions i

institucions, o en les activitats quotidianes. En la majoria dels escenaris

es tendeix a relacionar principalment aquest concepte amb la seva vessant

mediambiental, possiblement degut a que es tracta de la problematica de la

qual ningu pot escapar, independentment del seu nivell de vida. El cert,

pero, es que la sostenibilitat es un concepte mes ampli, ja que per assegurar

que no es compromet l’acces als recursos actuals, aixı com tampoc per a les

generacions futures, cal desenvolupar-la tambe a nivell economic i social.

En el sector tecnologic, fortament associat a un ritme de canvi frenetic,

l’evolucio i adopcio de les noves tecnologies es tan rapida que les analisis

sobre el seu impacte van sempre un pas enrere. En consequencia, tot i que

la conscienciacio general es present, la sostenibilitat (si s’aplica) esdeve una

practica reactiva, pel que es essencial que en qualsevol projecte s’avaluın

ıntegrament totes les seves dimensions.

Malauradament, pero, aquestes practiques no solen desenvolupar-se amb

prou frequencia, i aixo sol ser producte d’una mancanca en els coneixements

i eines requerides per aplicar-les. D’aquesta forma, cal que no nomes es

fomentin en els ambits professionals, sino que tambe s’aposti amb fermesa

per la seva aplicacio a nivell academic, ja que es el fonament dels futurs

professionals.

En el marc d’aquest treball es disposen de certs coneixements per al

desenvolupament d’un analisi de sostenibilitat, especialment en la vessant

economica, ja que es la mes tractada a nivell educatiu, aixı com dins de

l’especialitat de Sistemes de la Informacio. Tot i aixo, sera imperatiu recolzar-

se en material de suport, aixı com dedicar el temps necessari a la reflexio del

potencial impacte que el desenvolupament del projecte pot suposar en les

tres dimensions de la sostenibilitat.

En definitiva, en aquesta seccio es desenvolupa un analisi inicial de la

sostenibilitat del projecte, amb l’objectiu d’assegurar que s’analitza la se-

va viabilitat en les dimensions, i que a posteriori se’n pot avaluar la seva

aplicacio.

46


1.7.1 Dimensio Economica

La sostenibilitat economica del projecte al llarg de la seva planificacio, desen-

volupament i implantacio, ha estat marcada per la seva correcta gestio en

aquest ambit, basada en la quantificacio dels costos realitzada en la Seccio

1.6, juntament amb els mecanismes aplicats per al seu control. Les desviaci-

ons resultants dels canvis en la planificacio s’han quantificat seguint el model

de control proposat inicialment, i en ultima instancia el projecte s’ha ajustat

al pressupost inicial.

Els sistemes ERP son una peca essencial per a les organitzacions gracies

als avantatges que aporten de forma integral en la seva operativa, ja sigui

en la gestio interna o en la interaccio amb proveıdors i clients. Aixo s’acaba

traduint en un increment de la productivitat, aixı com en un millor servei,

que impacta a nivell economic amb una reduccio de costos i/o un increment

dels ingressos. Tot i aixo, poden esdevenir una limitacio si no es mantenen

correctament, ja que les dificultats per a la seva actualitzacio van incremen-

tant amb el pas del temps. En consequencia, la migracio del sistema a una

versio actualitzada ofereix majors funcionalitats, usabilitat i eficiencia [19] a

l’empresa client, que redueixen directament els seus costos operacionals en

comparacio amb l’actual.

1.7.2 Dimensio Mediambiental

La sostenibilitat mediambiental del projecte esta principalment marcada pel

consum dels recursos involucrats en el seu desenvolupament i implantacio,

sobretot els referents als dispositius hardware. L’empresa ja opera el sistema

amb una infraestructura tecnologica especıfica, pel que el desplegament en

produccio del projecte no tindra directament un impacte negatiu afegit al

consum realitzat actualment en l’aspecte tecnologic.

Per altra banda, cal considerar que l’us d’un sistema actualitzat reduira

el temps requerit per realitzar les operacions involucrades als processos de

negoci, que es traduira amb una major eficiencia en el seu rendiment. Tan-

mateix, si s’hagues optat per una alternativa com la implantacio des de zero

d’un nou sistema, resultaria en un projecte d’un major abast que requeriria

la involucracio de mes temps i recursos.

47


Finalment, pel que fa al desenvolupament del projecte, factors com el

teletreball d’alguns membres de l’equip, juntament amb el fet que aquest

es realitza remotament des de Barcelona, minimitzen l’impacte mediambi-

ental de la realitzacio de les tasques requerides. Tot i aixo, prescindir del

desplacament d’un membre de l’equip per treballar in situ permetria reduir

encara mes l’impacte resultant del desplacament i la gestio, pero els avantat-

ges que aquest recurs aporta en el control del risc del projecte fan que sigui

necessari.

1.7.3 Dimensio Social

L’autor d’aquest treball considera que, a nivell personal, el projecte li ha

aportat coneixements solids en la gestio de projectes, amb especial emfasi en

els ambits de planificacio, gestio economica, i sostenibilitat, els quals no solen

tractar-se en profunditat en l’espai academic i esdevenen claus en qualsevol

escenari professional. Mes especıficament, l’autor ha adquirit els fonaments

tecnics requerits per al desenvolupament del projecte, com son la capacitat

d’analisi de processos empresarials i la seva implementacio en el sistema ERP,

aixı com tambe ha potenciat les capacitats de treball en equip associades.

Pel que fa a ForgeFlow, l’empresa podra sumar al final l’experiencia ad-

quirida d’un nou projecte, que contribuira a potenciar la seva imatge i reco-

neixement a nivell internacional. Tanmateix, l’empresa client que actualment

opera amb una versio d’Odoo antiga, que no ofereix tots els avantatges de les

noves versions posteriors, podra disposar d’un producte mes actualitzat, amb

un major ventall de funcionalitats i un increment notable en el rendiment.

Aixı, no nomes la propia empresa se’n veu beneficiada, sino que els agents

externs que interaccionen i/o es veuen influenciats pel seu sistema podran

gaudir d’un servei mes eficient i de major qualitat.

Finalment, cal destacar en aquest aspecte que la implantacio d’un siste-

ma, independentment de les millores que comporti, genera directament una

dependencia per als usuaris finals, que han d’adaptar-se a les noves modifica-

cions d’aquest, Es essencial en aquest ambit, doncs, les tasques de formacio

i suport post-desplegament del projecte.

48

Capıtol 2

Factors crıtics d’exit i riscos del

projecte

En les primeres seccions d’aquest document, concretament a la Seccio 1.3.3,

s’ha introduıt breument els riscos generals associats al projecte, especialment

a nivell del seu desenvolupament i planificacio. Tot i aixo, per assolir un nivell

de gestio adequat d’aquests, s’ha considerat dedicar una seccio especıfica a

la seva identificacio i avaluacio des de diverses perspectives, emmarcant-los

en el context de l’activitat central del projecte: el proces de migracio.

Per tal d’identificar els riscos que es podrien derivar, s’ha utilitzat com a

base un article desenvolupat pel Doctorant del Programa de Software i Sis-

temes d’Informacio de la Universitat Politecnica de Catalunya Jose Esteves,

juntament amb l’actual Vicedega de Relacions Institucionals i Internacionals

de la Facultat d’Informatica de Barcelona, Joan Antoni Pastor [20].

La primera part del document en questio defineix les conclusions d’un

projecte d’investigacio destinat a la unificacio i analisi dels principals Fac-

tors Crıtics d’Exit (FCE) en projectes d’implantacio de sistemes ERP. En

aquesta, s’estableix un model de classificacio d’aquests factors segons la seva

naturalesa, discernint entre quatre perspectives principals:

49

• Organitzacional: vinculada a factors relatius a l’estructura i cultura

organitzacional de l’empresa.

• Tecnologica: vinculada a factors tecnologics especıfics del producte

ERP involucrat en el projecte.

• Estrategica: vinculada a factors associats amb accions orientades a

objectius a llarg termini de l’empresa, aixı com al compliment de la

seva missio.

• Tactica: vinculada a factors associats amb accions orientades a objec-

tius a curt i mitja termini de l’empresa.

A partir d’aquest model, les perspectives tecnologica i organitzacional

permeten diferenciar els factors relacionats especıficament amb el sistema

emprat d’aquells relacionats amb l’estructura i funcionament de l’equip huma

implicat. Per altra banda, per cada un d’aquests grups els seus factors po-

den relacionar-se amb una perspectiva estrategica o tactica en funcio de la

orientacio dels seus objectius.

Es important destacar que un proces de migracio esdeve la implementacio

d’una versio actualitzada del sistema, pel que en gran mesura s’estableix un

paral·lelisme entre un projecte d’aquest tipus amb una implementacio d’un

nou sistema, tant a nivell de processos com dels riscos involucrats. Per aquest

motiu, a l’hora d’analitzar els diferents factors d’exit, s’ha avaluat la seva

adequacio concreta en l’escenari del projecte, i s’han tractat des del punt de

vista de ForgeFlow, on l’autor ha desenvolupat el treball.

Finalment, juntament amb l’article s’ha utilitzat com a referencia com-

plementaria el CHAOS Manifesto [21] i el CHAOS Report [22], documents

derivats del CHAOS Research Project. Aquest ultim es un estudi destinat

a l’analisi de l’exit o el fracas dels projectes de TI, aixı com dels factors a

nivell de gestio i execucio d’aquests que afavoreixen els consequents resultats.

Ambdues fonts han sigut emprades per a la identificacio dels diferents riscos,

aixı com per a la seva avaluacio.

50

2.1. PERSPECTIVA ORGANITZACIONAL

2.1 Perspectiva Organitzacional

2.1.1 Estrategics

· Suport continu de l’alta direccio

• Definicio: Necessitat per part de la direccio executiva del client de

destinar els recursos necessaris al projecte, aixı com d’involucrar-se en

la mesura del possible i requerit al llarg del proces.

• Risc associat: La falta d’involucracio per part del client pot resultar

no nomes en una falta de compliment dels objectius, sino en una manca

d’alineacio d’aquests amb les seves necessitats reals. En consequencia,

aquest factor podria comportar el desenvolupament fallit del projecte,

fent que el CHAOS Manifesto el posicioni com un dels principals factors

d’exit en petits projectes.

• Avaluacio: Degut a que es tracta d’un factor altament dependent en

la voluntat del client, esdeve un risc alt degut a la seva importancia

per a l’exit del projecte.

• Control: Aquest factor es minimitzara seguint tres passos essencials:

– Identificar i definir clarament els rols requerits per part del client

en el projecte, principalment els key users.

– Establir una comunicacio constant al llarg del proces, aixı com

definir-la ja des del moment de la seva planificacio.

– Definir la involucracio del client en els processos de validacio ja

des de la planificacio del projecte, en lınia amb els processos invo-

lucrats en la migracio.

· Gestio efectiva del canvi

• Definicio: Capacitat per part del client de gestionar l’acceptacio i

preparacio de l’organitzacio a la nova versio del sistema, juntament

amb el suport de l’empresa consultora.

51


• Risc associat: Una mala gestio de la implantacio del nou sistema pot

provocar incidencies en el desplegament i operativa final que en facin

els usuaris. A la fi, l’exit del desenvolupament es projectara en els

beneficis aportats per aquest a posteriori, els quals seran dependents

de l’us que en facin els usuaris finals. Per aquest motiu, el CHAOS

Manifesto situa tambe com a factor principal d’exit la involucracio dels

usuaris i els seus interessos o necessitats.

• Avaluacio: Tot i la importancia d’aquest factor, degut a que les modi-

ficacions s’estableixen entre versions d’un mateix sistema no es preveu

un gran risc en aquesta gestio, pel que es pot avaluar com a baix.

• Control: Per tal de controlar aquest risc s’estableixen per part de

Forgeflow dues tasques principals dins del proces:

– Involucrar key users al llarg de tot el proces, especialment en les

validacions, els quals podran comprovar l’adaptacio dels processos

de negoci a la nova versio del sistema.

– Oferir un suport post-migracio en el que es dugui a terme una fase

de formacio i suport a usuaris, aixı com documentar correctament

els processos.

· Composicio adequada de l’equip del projecte

• Definicio: Alineacio de les capacitats conjuntes de l’equip involucrat

en el projecte amb els coneixements tecnologics i de negoci requerits.

• Risc associat: Per a l’exit del projecte es essencial que les capaci-

tats tecnologiques i els coneixements de negoci estiguin presents en els

rols involucrats, ja que si no s’integren i es combinen correctament pot

resultar en una falta d’alineacio entre els resultats entregats per l’em-

presa consultora i les necessitats reals del client. De forma analoga, el

CHAOS Manifesto situa l’us de recursos experts.

52


• Avaluacio: Degut a les capacitats transversals de les que disposen

els membres de l’equip de desenvolupament en els fluxos empresarials,

gracies als seus coneixements i experiencia en altres projectes, aquest

risc es pot considerar baix. Tot i aixo, degut a que es imperatiu dis-

posar del coneixement de negoci especıfic del client, el qual requereix

manifestar-se a traves dels seus membres, segueix sent un risc impor-

tant a considerar en la gestio.

• Control: Per tal de minimitzar aquest factor s’involucra des d’un inici

uns key users destinats especıficament pel client com a punts clau de

contacte entre l’empresa consultora i aquest. Paral·lelament, el contac-

te directe i periodic establert entre ambdues parts permet controlar en

la mesura del possible les potencials desalineacions en els resultats que

es van entregant de forma incremental.

· Confianca entre les parts involucrades

• Definicio: Establiment d’una relacio cooperativa i de confianca entre

el client i l’empresa consultora al llarg del proces.

• Risc associat: Tot i semblar obvi, el fet que s’estableixi com un dels

principals factors crıtics posa de manifest la manca d’importancia que

se li sol donar. Una falta de confianca entre les parts impedira de forma

directa assolir un nivell de comunicacio i cooperacio adequat, que tindra

un efecte negatiu en el desenvolupament i resultat final del projecte.

• Avaluacio: En el marc del projecte aquest risc es pot considerar mo-

derat, ja que tot i ser un dels factors essencials en l’exit d’aquest, es

veu directament minimitzat pel propi context: Per una banda l’empre-

sa client te un alt interes en l’exit del projecte per a millorar la seva

operativa, fet que potencia la seva proactivitat en la correcta interaccio

amb l’empresa consultora. Per altra, ForgeFlow disposa d’un extens

currıculum de projectes d’aquestes caracterıstiques desenvolupats amb

exit, entre els quals s’hi troben altres empreses del mateix paıs d’origen

que el client, esdevenint referencies clau per a la confianca d’aquest.

• Control: La confianca per part del client es pot controlar a traves de

dues tasques principals:

53


– Comunicacio constant: en lınia amb el que ja s’ha comentat amb

anterioritat, la comunicacio amb el client permet no nomes mante-

nir una bona relacio sino tambe controlar possibles desavinences

que puguin sorgir al llarg del proces, mitigant-les al mes aviat

possible.

– Entrega incremental de resultats: gracies a la metodologia propo-

sada, el resultat de la migracio es podra obtenir de forma incre-

mental, pel que l’empresa client podra anar validant els resultats

en les diferents iteracions del proces. Poder veure i seguir aquest

proces permet assegurar al client que els objectius s’assoliran sa-

tisfactoriament.

2.1.2 Tactics

· Planificacio formalitzada del projecte

• Definicio: Realitzacio d’una planificacio detallada del projecte i les

seves tasques, aixı com l’assignacio corresponent del pressupost i els

recursos necessaris.

• Risc associat: Una planificacio poc o mal definida comportara amb

alta probabilitat un exces temporal en el desenvolupament del projec-

te, principalment degut a la falta d’organitzacio o definicio de les tas-

ques necessaries, aixı com en la identificacio de les seves dependencies,

desembocant en importants sobrecostos economics. Tanmateix, aplicar

mecanismes de control sobre els desviaments dels costos del projecte

esdeve complicat si no hi ha una planificacio ben definida, la qual per-

meti establir facilment la tracabilitat de les activitats que es duen a

terme i els seus recursos involucrats.

• Avaluacio: Tot i que un projecte de migracio no comporta una com-

plexitat tan elevada en comparacio amb una implantacio des de zero,

les activitats involucrades en el proces son crıtiques per tal d’assolir

l’exit del projecte. Es important considerar que aquest s’ha de dur a

terme dins del marc de l’empresa client, la qual ha definit en el seu pla

estrategic els objectius que preten assolir i les fites temporals en les que

54


espera assolir-los. Aixı doncs, la planificacio en aquest context no es

unicament clau per a l’exit, sino que ha d’integrar-se i respectar dins

del possible les expectatives del client, fent que una mala formalitzacio

esdevingui un risc alt.

• Control: Per tal d’afrontar un risc tan elevat es fa essencial destinar

tot un conjunt de tasques dins de la lınia temporal del projecte a assolir

una estimacio temporal i de costos associats el mes acurada possible.

Principalment aixo s’assoleix a partir d’un analisi inicial dels moduls

involucrats en la migracio, juntament amb l’experiencia personal de

l’empresa consultora en altres projectes similars.

· Programa de formacio adequat

• Definicio: Desenvolupament d’un pla de formacio adequat a les modi-

ficacions del sistema i l’operativa de l’empresa derivades de la migracio,

el qual consideri tant els key users com els usuaris finals.

• Risc associat: Des de la perspectiva de Forgeflow, el risc associat

a aquest factor es deriva del compromıs establert en el contracte de

contribuir al desenvolupament de documentacio del funcionament del

sistema, aixı com d’oferir suport directe en l’etapa posterior al desplega-

ment oficial durant un perıode concret. En consequencia, no gestionar

correctament aquest factor implicara la fallida del servei ofert.

• Avaluacio: Tot i la importancia del factor dins el desenvolupament del

projecte, des del punt de vista de l’empresa consultora el risc associat

no te un impacte tan crıtic com per al client. Tanmateix, degut a que

el proces de migracio no comportara grans canvis a nivell de l’operativa

de negoci, aquest risc s’avalua com a baix.

• Control: Per tal de minimitzar aquest risc per a Forgeflow, s’estableix

en la planificacio una serie de tasques especıficament destinades a cobrir

les necessitats derivades del factor:

– Involucracio dels key users en els processos de validacio, en els

quals es mostraran i debatran les modificacions derivades de la

migracio.

55


– Desenvolupament de documentacio.

– Suport als usuaris durant un perıode posterior al desplegament

oficial.

· Anticipacio preventiva de problemes

• Definicio: Habilitat per gestionar problemes inesperats i desviacions

de la planificacio inicial.

• Risc associat: Si no es gestionen correctament els riscos del projec-

te, l’aparicio de problemes inesperats provocara desviacions que poden

desembocar, tal i com s’ha esmentat anteriorment, en excessos tempo-

rals, sobrecostos economics, i fins i tot en el fracas del projecte. Aquesta

ultima instancia pot produir-se en el cas en el que l’aparicio d’un pro-

blema afecti col·lateralment la relacio entre les parts implicades en el

projecte.

• Avaluacio: En qualsevol projecte, ja sigui d’una complexitat major o

menor, la capacitat de preveure i gestionar potencials problemes esdeve

un factor clau, ja que aquests poden ser la causa d’impactes derivats

molt mes crıtics. Per aquest motiu, es imperatiu avaluar aquest risc

com a alt, dotant-lo d’una alta importancia per a controlar-lo correc-

tament.

• Control: La clau per minimitzar i controlar aquest risc recau princi-

palment en la capacitat de previsio, juntament amb l’establiment de

mecanismes de control, ja en la propia planificacio del projecte. D’a-

questa forma, es desenvolupa ja des d’un inici un analisi dels principals

riscos associats al projecte, alhora que es defineix una comunicacio

constant i periodica entre les parts implicades per tal d’identificar i

resoldre, de la forma mes rapida i directa possible, qualsevol problema

inesperat.

56

2.2. PERSPECTIVA TECNOLOGICA

2.2 Perspectiva Tecnologica

2.2.1 Estrategics

· Estrategia de migracio adequada

• Definicio: Desplegament de les metodologies, activitats i decisions de

gestio adequades a les necessitats del projecte.

• Risc associat: El proces de migracio pot seguir diverses estrategies en

les quals les activitats involucrades es duguin a terme de forma diferent,

per exemple entre un proces en cascada o un per fases. L’el·leccio s’ha

de basar en les avantatges i inconvenients de cada una, juntament amb

els riscos i requeriments del projecte, ja que sino l’estrategia no seria

adequada i produiria l’aparicio de problemes inesperats.

• Avaluacio: Al tractar-se d’un factor clau per a l’exit del projecte,

aquest representa un risc significatiu per a l’empresa consultora. Tot i

aixo, degut a l’experiencia d’aquesta en el desenvolupament de projec-

tes similars, es podria avaluar des d’un inici com a baix.

• Control: Per tal d’assegurar el control d’aquest factor, es defineix

clarament des d’un inici una metodologia adequada a les necessitats

del projecte, a l’equip de treball, i la qual permeti minimitzar els po-

tencials riscos del projecte. D’aquesta forma, tal i com s’ha vist es

dona important emfasi en l’estrategia a seguir a la comunicacio entre

les parts, i a la validacio periodica i constant per part del client.

· Evitar desenvolupaments a mida

• Definicio: Evitar en la mesura del possible el desenvolupament de

modificacions sobre les funcionalitats ja disponibles en el sistema oficial.

• Risc associat: Quan es modifica, s’esten, o s’afegeix un nou modul

al sistema, la complexitat de la migracio entre versions creix, especial-

ment quan aquests presenten varies integracions entre ells. En el marc

del projecte, es pot haver d’afrontar escenaris en els quals unes funci-

onalitats o moduls no siguin compatibles ni estiguin disponibles per a

la versio objectiu.

57


• Avaluacio: Degut a que en l’escenari d’una migracio no es preveu

haver d’afrontar gran quantitat d’escenaris en els que es requereixi un

desenvolupament nou, aquest risc es considera baix.

• Control: Davant les situacions en les que pugui ser necessari un desen-

volupament a mida, degut a que un modul no sigui compatible amb la

nova versio, es essencial que s’avaluın primerament alternatives ja exis-

tents, ja sigui en base als moduls oficials existents o a traves de la

botiga d’aplicacions d’Odoo.

2.2.2 Tactics

· Infraestructures i interfıcies adequades

• Definicio: Correcta migracio i desenvolupament de proves sobre les

interfıcies i moduls destinats a la interconnexio amb sistemes externs.

• Risc associat: Les cadenes de subministrament de les empreses son

cada vegada mes complexes, comprenent des de la compra a proveıdors

fins a l’entrega del producte al client final. D’aquesta forma, els sis-

temes ERP han de ser capacos d’integrar-se correctament amb els sis-

temes o programes externs dels agents amb els que l’empresa ha d’in-

teractuar per tal de desenvolupar la seva activitat de negoci. Si en el

proces de migracio no s’assegura que aquesta integracio segueix ope-

rativa, suposaria grans problemes pel client i comportaria el fracas de

l’assoliment dels objectius del projecte.

• Avaluacio: En el marc del projecte, l’empresa client utilitza varis

moduls connectors per tal d’integrar informacio de proveıdors externs,

la qual es clau per poder operar correctament. Per aquest motiu, el

risc associat a aquest factor no es unicament destacable, sino que cal

avaluar-lo com a alt.

• Control: En lınia amb el control establert per a altres riscos, la meto-

dologia proposada permetra minimitzar-lo gracies a les proves i valida-

cions incrementals i periodiques, desenvolupades en entorns controlats,

assegurant al maxim la fiabilitat del resultat final.

58


· Pla de proves formalitzat

• Definicio: Definicio de l’ambit, recursos involucrats, i planificacio de

les activitats associades als processos de proves i validacio.

• Risc associat: Tot i que pugui semblar un factor obvi en qualsevol

projecte de l’ambit de les TI, sovint no es dona prou importancia als

processos de validacio. Aquests han de ser complets i adequats als

requisits de negoci plantejats, tenint en consideracio tant les proves

tecniques com les funcionals. Si totes les consideracions no son plante-

jades ja en la planificacio de les activitats, el risc que el resultat final

no satisfaci els requisits es molt elevat, i no nomes comportaria un so-

brecost per a solucionar els problemes sino que podria suposar el fracas

del projecte.

• Avaluacio: En qualsevol projecte de l’ambit de les TI es imperatiu

assegurar que el resultat final satisfa els requeriments i objectius del

client. Per assolir-ho, les proves i validacions son l’element clau, fent

que el risc derivat d’aquest factor hagi de ser considerat alt.

• Control: La millor forma d’adrecar aquest risc es basa en definir des

d’un inici a la planificacio inicial els processos de validacio que es segui-

ran, especialment involucrant als key users a nivell de proves funcionals.

Tanmateix, sera clau entendre l’actual funcionament del sistema i els

principals processos, ja que aixo facilitara les proves dels moduls que

es van migrant per part dels consultors tecnics.

· Proces de migracio de dades

• Definicio: Transferencia i prova d’integritat de les dades existents del

sistema antic al nou abans del seu desplegament.

• Risc associat: Una mala planificacio i desenvolupament del proces

de migracio de les dades al nou sistema provocara potencialment l’a-

paricio d’imprevistos, que retardaran el desplegament final d’aquest i

comportaran sobrecostos.

59


• Avaluacio: Tant en una implantacio com en un proces de migracio

aquesta fase esdeve un punt clau en l’exit del projecte, estant associa-

da a un dels requisits principals del projecte: mantenir la integritat de

totes les dades presents al sistema. Tot i aixo, degut a que s’esta realit-

zant una migracio entre versions d’un mateix sistema, juntament amb

l’experiencia de l’empresa consultora en aquest, el risc es pot avaluar

com a moderat.

• Control: La minimitzacio d’aquest risc segueix la lınia del que ja s’ha

esmentat amb anterioritat: una correcta planificacio i metodologia que

asseguri no nomes com i quan es dura a terme el proces, sino tambe la

validacio corresponent per part del client.

60


Factor Avaluacio Control

Suport continu de l’alta direccio Alt • Comunicacio amb el client

• Planificacio

Gestio efectiva del canvi Baix • Involucracio de key users

• Documentacio i formacio a usuaris

Composicio adequada de l’equip del projecte Baix • Involucracio de key users

Confianca entre les parts involucrades Moderat • Comunicacio amb el client

• Entrega incremental de resultats

Planificacio formalitzada del projecte Alt • Analisi inicial

Programa de formacio adequat Baix • Involucracio key users

• Documentacio i suport

Anticipacio preventiva de problemes Alt • Analisi de riscos

• Comunicacio amb el client

Estrategia de migracio adequada Baix • Clara definicio del proces

Evitar desenvolupaments a mida Baix • Planificacio

• Avaluacio d’alternatives

Infraestructures i interfıcies adequades Alt • Validacions constants i incrementals

• Entorn especıfic de proves

Pla de proves formalitzat Alt • Planificacio

• Coneixement de negoci

Proces de migracio de dades Moderat • Planificacio

• Validacio del client

Taula 9: Avaluacio dels riscos del projecte. Font propia.

61

Capıtol 3

El sistema Odoo

En la contextualitzacio del projecte s’ha introduıt breument el sistema ERP

Odoo, principalment des del punt de vista empresarial, aixı com tambe la

seva historia. L’objectiu d’aquesta seccio es per una banda aprofundir en

l’ecosistema sobre el qual esta construıt, veient quines son les parts involu-

crades en el seu desenvolupament, i per l’altra especificar la seva arquitectura

tecnologica, definint els elements principals en els quals es basa el seu fun-

cionament. En definitiva, aportara la informacio requerida per entendre que

es i com funciona Odoo, facilitant la comprensio dels continguts posteriors

del treball referents al desenvolupament del projecte.

3.1 L’ecosistema

Quan es parla del sistema Odoo es important discernir entre les diverses parts

involucrades en el seu desenvolupament. Tot i la seva vessant comercial, el

sistema es fonamenta en una base de codi obert, accessible per a qualsevol

usuari, que permet la modificacio i extensio d’aquesta per afegir noves fun-

cionalitats. Degut a aquesta flexibilitat, un sistema Odoo utilitzat per una

entitat pot ser molt diferent al d’una altra, en funcio de les modificacions

que s’hi hagin realitzat.

62

3.1. L’ECOSISTEMA

Des d’una perspectiva general, Odoo es pot entendre com la composicio

de diverses capes de software que estenen o afegeixen funcionalitats a la

capa base. Aquesta estructura pot visualitzar-se facilment a traves de la

Figura 4, en la que s’aprecia com, sobre la base definida per l’Odoo Core, les

altres capes s’integren per afegir-hi noves caracterıstiques, estant cadascuna

relacionada amb alguna entitat de l’ecosistema. Aixı doncs, a continuacio es

tractaran individualment per tal d’analitzar-les.

Figura 4: Odoo Ecosystem. [23]

3.1.1 Odoo Core

Odoo Core es el nom que identifica el software base del sistema, corresponent

a la seva versio de codi obert Odoo Community, la qual ja s’ha introduıt en

la contextualitzacio del projecte. El codi corresponent a aquesta versio es ac-

cessible directament des de Github, una plataforma destinada a l’allotjament

de projectes software en repositoris a Internet, des d’on es pot descarregar i

instal·lar lliurement.

Tot i que la base del sistema esta desenvolupada i gestionada per part de

la propia empresa Odoo S.A., la seva distribucio sota la llicencia GNU LGPL

permet que s’hi puguin afegir extensions i modificacions per formar un nou

producte, el qual pot ser distribuıt o protegit per llicencies mes restrictives.

De fet, es degut a aixo que la propia empresa pot seguir un model de negoci

Open Core.

63

3.1. L’ECOSISTEMA

Cal destacar, pero, que la comunitat desenvolupada al voltant d’Odoo

vetlla sempre per la seva millora, i gracies a la gestio que l’empresa fa del

seu projecte de codi obert els usuaris poden proposar modificacions amb

l’objectiu de ser avaluades i introduıdes al repositori oficial.

3.1.2 Odoo Enterprise

Odoo Enterprise defineix la versio de pagament distribuıda, desenvolupada i

gestionada per l’empresa Odoo S.A. El cert es que, tal i com s’observa a la

Figura 4, a nivell tecnologic aquesta simplement afegeix una capa en la que

es defineixen nous moduls amb funcionalitats unicament disponibles a traves

de la subscripcio de pagament. Cal destacar que, tot i que aquesta versio

tambe esta allotjada a la plataforma de Github, el seu acces esta restringit

al public.

3.1.3 Odoo Community Association

Idem de la capa afegida per Odoo Enterprise, la capa de la Odoo Community

Association (OCA) s’afegeix a la versio base per incorporar tota una serie de

moduls desenvolupats per aquesta. Els moduls de la OCA estan desenvolu-

pats i gestionats pels seus membres, els quals son contribuıdors independents

o empreses interessades que s’hi associen a canvi d’una tarifa i la signatura

d’un acord de contribucio. En aquest s’hi estipulen les bases i normatives per

a contribuir en les activitats desenvolupades per l’associacio, amb l’objectiu

d’assegurar un marc regulatiu necessari per al correcte desenvolupament i

manteniment del codi.

La caracterıstica principal d’aquesta capa resideix en que tots els moduls

afegits per l’associacio estan, i han d’estar, disponibles sota alguna llicencia

lliure derivada de la GNU GPL, assegurant que qualsevol copia o modificacio

es distribueix sempre amb les mateixes condicions [24].

64

3.1. L’ECOSISTEMA

3.1.4 Codi privatiu

Finalment, juntament amb les capes afegides sobre la versio base, una ultima

de privativa pot estar present en els sistemes utilitzats per les diferents orga-

nitzacions o entitats. Odoo permet una alta flexibilitat i adaptacio, i tot i que

moltes funcionalitats ja estan disponibles a traves de les capes anteriorment

definides, molts escenaris poden no estar contemplats o requerir configuraci-

ons especıfiques. Aixı, en aquest codi privatiu es pot discernir principalment

entre dues tipologies de moduls afegits:

• Moduls propietaris especıfics: desenvolupats per tercers per a un

client concret, el qual sol ser-ne el propietari ja que ha pagat pel seu

desenvolupament.

• Moduls propietaris generals: desenvolupats per tercers que volen

oferir funcionalitats no disponibles a traves de cap altra capa. El pro-

pietari pot distribuir-lo sota varies tipologies de llicencia, inclosa pri-

vativa, i a canvi d’un preu d’adquisicio.

65

3.2. ARQUITECTURA TECNOLOGICA

3.2 Arquitectura tecnologica

Odoo es presenta com un paquet d’aplicacions web empresarials amb una

proposta de valor centrada en la usabilitat, qualitat tecnica, i assequibilitat

economica [25], les quals poden ser utilitzades de forma individual o conjun-

ta, oferint una perfecta integracio entre elles. Per assolir aquest objectiu es

essencial que, a nivell tecnologic, les noves extensions del sistema segueixin

una estructura adequada i compatible amb la capa d’Odoo Core, on es defi-

neix el framework per al seu desenvolupament. D’aquesta forma, els moduls

del sistema es basaran en els models i estructures de dades especificades en

aquests recursos base.

Previament a entrar en detall en que son i com s’estructuren els moduls

cal entendre la seva arquitectura tecnologica, la qual segueix una divisio per

capes [26]:

• Capa de presentacio: es la responsable d’interactuar amb l’usuari

del sistema i presentar-li les dades que sol·liciti a traves de la interfıcie.

Aquest usuari es connecta al sistema a traves del client web ofert pel

propi Odoo, accessible directament des d’un navegador, oferint totes les

caracterıstiques necessaries per a la correcta interaccio amb l’aplicacio

(inicis de sessio, interfıcies interactives...). Aixı, el client processa les

accions de l’usuari i es comunica amb el servidor per realitzar qualsevol

operacio sobre les dades del sistema.

• Capa de logica: es la responsable d’interactuar amb les seves capes

adjacents, processant per una banda les sol·licituds del client (rebent la

sol·licitud i retornant els resultats) i per altra operant sobre les dades

emmagatzemades al sistema. Aquesta capa esta gestionada pel servi-

dor del sistema, a traves del qual s’implementa tota la logica de les

aplicacions. Tot i que pot accedir directament a la base de dades, en la

major part dels escenaris aixo es realitza a traves del component ORM,

que defineix l’API utilitzada per qualsevol modul per interactuar amb

la capa de dades.

66


Figura 5: Interfıcie d’inici de sessio del client d’Odoo 13. Font propia

• Capa de dades: es la responsable de l’emmagatzematge de les dades

i la seva persistencia, aixı com de gestionar la comunicacio amb la seva

capa superior. Aquesta capa rep les sol·licituds de la capa de logica

i realitza les operacions requerides sobre les dades que emmagatzema.

La seva implementacio utilitza una base de dades relacional gestionada

com a unica opcio per un sistema PostgreSQL.

Aquesta arquitectura tecnologica es el fonament sobre el que s’implementen

els moduls del sistema, encarregats de definir els components requerits de

cada capa per afegir o modificar caracterıstiques.

67


Figura 6: Arquitectura d’Odoo. Font propia

68


3.2.1 Aplicacions/Moduls

Tot i que fins ara no s’ha discernit entre modul i aplicacio, ja que a la fi

defineixen la mateixa entitat, s’utilitza el terme aplicacio per referir-se a un

modul que ofereix unes funcionalitats noves o molt destacades per a una area

especıfica, essent directament accessible a traves del menu general d’Odoo

(Figura 7). Aixı, el terme modul s’utilitza principalment per aquells que afe-

geixen o modifiquen funcionalitats dins d’una area funcional ja implementada

per una aplicacio.

La capa base d’Odoo (Odoo Core) es la que especifica el conjunt de re-

cursos i informacio necessaria per al funcionament del sistema, definint aixı

el framework i les estructures de dades que esdevenen la referencia per al

desenvolupament dels moduls del sistema.

Figura 7: Menu general d’Odoo. Font propia

3.2.2 Components d’un modul

Un cop definida l’arquitectura general del sistema, des de la perspectiva

mes tecnica cal finalment veure com s’implementen els moduls. Amb una

estructura molt definida, marcada per unes guies de desenvolupament [27],

els seus elements es divideixen en diferents directoris:

69


• Models: Els models descriuen l’estructura de dades utilitzada en un

modul a traves de la definicio d’objectes amb un conjunt d’atributs,

relacions entre ells, i metodes associats. Aquests elements son els que

tracten amb les dades del sistema, ja sigui a traves del ORM o direc-

tament a la base de dades, esdevenint el fonament al voltant del qual

es construeix el modul.

Odoo esta basat en el llenguatge de programacio Python, pel que

aquests models es representen a traves de classes d’aquest mateix llen-

guatge.

Llistat de codi 1: Exemple parcial d’implementacio d’un model. Font propia

class ProductCategory(models.Model):

# Definici o dels atributs del model

_name = "product.category"

_description = "Product Category"

_parent_name = "parent_id"

_parent_store = True

_rec_name = ’complete_name ’

_order = ’complete_name ’

name = fields.Char(’Name’, index=True , required=True)

complete_name = fields.Char(’Complete Name’, compute=’

_compute_complete_name ’, store=True)

parent_id = fields.Many2one(’product.category ’, ’Parent Category ’, index

=True , ondelete=’cascade ’)

parent_path = fields.Char(index=True)

child_id = fields.One2many(’product.category ’, ’parent_id ’, ’Child

Categories ’)

# Definici o d’un me tode del model

@api.depends(’name’, ’parent_id.complete_name ’)

def _compute_complete_name(self):

for category in self:

if category.parent_id:

category.complete_name = ’%s / %s’ % (

category.parent_id.complete_name ,

category.name

)

else:

category.complete_name = category.name

70


El model definit es tradueix a nivell de base de dades en una taula,

mentre que els seus atributs es converteixen en columnes d’aquesta.

El framework d’Odoo ofereix diferents tipologies de camps de dades

(fields) per definir els atributs d’un model [13]:

– Camps basics: Encapsulen tipus de dades simples com boolean,

float, char o integer.

– Camps avancats: Encapsulen tipus de dades complexos com

date/datetime, image o monetary, aixı com tambe relacionals.

Aquests ultims permeten establir relacions amb altres models:

∗ Many2one: Estableix una relacio de molts a un. En la taula

de la base de dades es tradueix en una clau forana.

∗ One2many: Estableix la contrapartida a la relacio anterior

amb l’objectiu de realitzar l’acces invers. A nivell de base de

dades aquesta relacio no es materialitza, pero es molt util a

nivell de l’ORM.

∗ Many2many: Estableix una relacio de molts a molts. En la

base de dades es tradueix en una nova taula que relaciona les

taules dels models.

Independentment de la tipologia de dades d’un camp, la seva naturalesa

pot ser diferent. Alguns exemples son:

– Camps calculats: Camps el valor dels quals es basa en una fun-

cio especificada en la definicio de l’atribut en el parametre com-

pute. Per defecte, aquests camps no s’emmagatzemen a la base de

dades.

– Camps automatics: Camps generats automaticament per cada

model que es defineix en un modul i s’emmagatzema a base de

dades. El seu objectiu es oferir informacio basica sobre la seva

creacio i actualitzacio.

∗ ID: identificador unic de cada instancia creada del model.

∗ create date / write date: camps datetime per a tracar el

moment de creacio / ultima modificacio d’una instancia del

model.

71


∗ create uid / write uid: camp Many2one que relaciona l’ID

de l’usuari que ha creat / modificat per ultima vegada la

instancia d’un model.

En el llistat de codi anterior es pot observar la creacio del model Product

Category, del qual es crea la corresponent taula de la Figura 8, amb les

columnes definides en els seus atributs.

Com es pot observar, el nom del model especificat en la variable name,

s’utilitza per a definir el nom de la taula creada a la base de dades, i

els seus atributs es converteixen en columnes de diferent tipus.

L’atribut complete name, el qual sent un camp calculat per defecte no

s’emmagatzema a la base de dades, apareix com una columna. Aixo es

degut a que en la seva definicio s’especifica el parametre store=True.

Hi ha multiples parametres que es poden especificar al definir un camp,

com per exemple index=True. Com es pot observar en l’atribut name,

un ındex es crea per a la columna de la base de dades amb el nom de

product category name index.

Finalment, pel que fa a les relacions, es pot observar com el Many2one

de l’atribut parent id, que estableix una relacio de la taula amb si ma-

teixa, es materialitza en una clau forana.

Figura 8: Mapeig. Font propia

72

• Views: Les vistes defineixen les interfıcies amb les quals l’usuari podra

interactuar i visualitzar l’estat de l’aplicacio, aixı com els resultats a

les seves peticions. Tot i utilitzar les dades del sistema, a traves de les

vistes l’usuari nomes podra interactuar amb els models, que seran els

encarregats de rebre les sol·licituds i operar sobre les dades.

Per a la seva implementacio s’utilitza el llenguatge de programacio

XML, a partir del qual Odoo genera les vistes web resultants. Amb

aquests fitxers no nomes es poden especificar multiples tipologies de

vistes sino que tambe es poden definir elements d’interaccio i navega-

bilitat.

Llistat de codi 2: Exemple d’implementacio d’una vista. Font propia

<record id="product_category_form_view" model="ir.ui.view">

<field name="name">product.category.form </field >

<field name="model">product.category </field >

<field name="arch" type="xml">



<form class="oe_form_configuration">

<sheet >


<div class="oe_button_box" name="button_box">

<button class="oe_stat_button"

name="%( product_template_action_all)d"

icon="fa-th -list"

type="action"

context="{’search_default_categ_id ’: active_id , ’

default_categ_id ’: active_id , ’group_expand ’:

True}">

<div class="o_field_widget o_stat_info">

<span class="o_stat_value"><field name="

product_count "/></span >

<span class="o_stat_text"> Products </span >

</div>

</button >

</div>


<div class="oe_title">

<label for="name" string="Category name" class="

oe_edit_only"/>

<h1><field name="name" placeholder="e.g. Lamps"/> </h1 >

</div>


<group name="first" col="2">

<field name="parent_id" class="oe_inline"/>

</group>

73


</sheet>

</form>

</field>

</record >

Figura 9: Interfıcie resultant de la vista definida al Llistat de codi 2. Fontpropia

• Wizard: Els wizards, tambe anomenats quadres de dialeg, defineixen

una tipologia de vistes mes simples que s’utilitzen per a interaccions

rapides amb l’usuari, principalment en moments en el que es requereix

que introdueixi dades al sistema. Aquests s’accedeixen a partir d’una

vista normal sobre la qual el wizard es sobreposara en obrir-se.

En la mateixa lınia que les vistes, aquests es defineixen a traves de

fitxers XML, que solen anar acompanyats d’un fitxer Python per es-

pecificar les dades que l’usuari introdueix i els metodes associats a

aquestes.

Figura 10: Exemple d’un wizard a Odoo. Font propia

74


• Controllers: Una de les aplicacions que ofereix Odoo es la de Website

(pagina web), que permet gestionar una o mes pagines de la organit-

zacio directament des del sistema. Per aquest motiu, una de les ca-

racterıstiques que ofereixen es un framework de desenvolupament web,

amb l’objectiu de poder desenvolupar funcionalitats relacionades amb

aquest ambit. Aixı, els controladors web son els components encarre-

gats de la renderitzacio de les pagines, i poden especificar-se per tal de

modificar el comportament de la pagina.

A Odoo els controladors es defineixen a traves de classes de Python,

especificant l’adreca URL a la que es fa referencia i el metode a executar

quan l’usuari la visita.

Llistat de codi 3: Exemple d’implementacio d’un controlador. Font propia

class CustomerPortal(CustomerPortal):

# URL en la que executar el me tode

@http.route ([’/my/orders/<int:order_id >/ update_line ’], type=’json’, auth

="public", website=True)

# Me tode a executar

def update(self, line_id , remove=False , unlink=False , order_id=None ,

access_token=None , **post):

values = self.update_line_dict(line_id , remove , unlink , order_id ,

access_token , **post)

if values:

return [values[’order_line_product_uom_qty ’], values[’

order_amount_total ’]]

return values

• Data: En aquest directori s’agrupen fitxers XML que s’utilitzen princi-

palment per introduir dades inicials requerides pel modul en el moment

de la seva instal·lacio. Tanmateix pot incloure dades de demostracio

destinades a realitzar proves sobre el modul, o simplement com a mos-

tra per a l’usuari que vulgui provar-lo.

Per tal de crear les dades es defineixen instancies del model desitjat,

especificant els atributs requerits per a poder ser introduıts al sistema.

75

Llistat de codi 4: Exemple de creacio d’una instancia. Font propia

<?xml version ="1.0" encoding ="utf -8"?>

<odoo >

<data noupdate="1">



<record id="product_category_all" model="product.category">



<field name="name">All </field >

</record >

</data>

</odoo>

• Security: Agrupa els fitxers que defineixen els permisos d’acces a les

vistes i models del modul. Odoo gestiona aquests permisos a traves

de grups d’usuari, pel que cada usuari que accedeix al sistema estara

assignat a un o mes grups.

Per a la seva especificacio es defineixen llistes de control d’acces amb

un fitxer CSV, les quals indiquen els permisos de creacio, lectura, mo-

dificacio i eliminacio sobre els models del modul per als grups d’usuari.

Tanmateix, es poden crear nous grups d’usuaris del sistema a traves

d’un fitxer XML, en el qual es defineixen noves instancies d’un model

base ofert per Odoo per gestionar-los.

id name model id:id group id:id perm read perm write perm create perm unlink

access product category user product.category.user model product category base.group user 1 0 0 0

access product template user product.template.user model product template base.group user 1 0 0 0

Taula 10: Exemple d’especificacio d’una llista de control d’acces. Fontpropia.

• i18n: Odoo busca en aquest directori fitxers per a la traduccio dels

elements definits en el modul. Aquests fitxers utilitzen els formats PO i

POT, els quals permeten especificar per a cada idioma les equivalencies

entre el text original i el resultant de la traduccio.

76


Llistat de codi 5: Exemple parcial d’un fitxer i18n. Font propia

#. module: product

#: model:ir.model.fields. selection

msgid " Product Category" # Text original

msgstr "Categoria de Producte" # Traducci o

• Static: Aquest directori es un estandard en aplicacions web, ja que

es on s’agrupen els fitxers utilitzats per al renderitzat d’elements al

navegador. Conte principalment els formats basics d’aquest ambit com

Javascript, CSS o directament imatges a mostrar a la interfıcie d’usuari.

Cal tenir present que el contingut d’aquest directori es public a traves

de la web.

• Tests: Tal i com indica el seu propi nom, aquest directori conte els

fitxers utilitzats per als tests o proves dels principals models i metodes

definits pel modul. Per a tal fi, es poden desenvolupar tres tipologies

de proves diferents:

– Proves unitaries de Python: son les mes utilitzades ja que

permeten assegurar el correcte funcionament dels models i els seus

metodes. Estan basades en el framework de Python unittest.

– Proves unitaries de JavaScript: estan dedicades a realitzar

proves sobre les vistes del modul, tot i que no es solen utilitzar tant

com les anteriors. Estan basades en el framework de JavaScript

QUnit.

– Tours: els tours permeten definir proves end-to-end, simulant

situacions reals en les que l’usuari ha d’anar realitzant una serie

d’interaccions amb l’aplicacio. Aixo no nomes serveix per a provar

ıntegrament els elements del modul, sino que tambe es util com a

element de formacio per a l’usuari.

En definitiva, en funcio de la mida del modul, la quantitat i varietat de

proves podra ser menor o major.

77

Llistat de codi 6: Exemple metode unittest de Python. Font propia

def test_get_variant_for_combination(self):

computer_ssd_256 = self._get_product_template_attribute_value(self.

ssd_256)

computer_ram_8 = self._get_product_template_attribute_value(self.ram_8)

computer_ram_16 = self._get_product_template_attribute_value(self.ram_16

)

computer_hdd_1 = self._get_product_template_attribute_value(self.hdd_1)

combination = computer_ssd_256 + computer_ram_8 + computer_hdd_1

# Execuci o del me tode

ok_variant = self.computer._get_variant_for_combination(combination)

# Validaci o del resultat

self.assertEqual(ok_variant.product_template_attribute_value_ids ,

combination)

• Report: Aquest directori conte els fitxers que defineixen informes uti-

litzats en el modul, els quals puguin ser impresos o visualitzats directa-

ment en la interfıcie web. La seva estructura visual es defineix a traves

de plantilles especificades amb fitxers XML, que poden anar acom-

panyats de fitxers Python si les dades a mostrar requereixen alguna

transformacio o es basen en consultes a la base de dades.

Llistat de codi 7: Exemple parcial de la definicio d’un informe. Font propia

<odoo >

<template id="report_pricelist">

<t t-call="web.html_container">

<t t-call="web.internal_layout">

<div class="page">



<h2>Price List </h2>



<div class="row mt32 mb32">

<div class="col -3">

<strong >Price List Name </strong >:<br/>

<span t-esc="data[’pricelist ’].name"/>

</div>


<strong >Currency </strong >:<br/>

<span t-esc="data[’pricelist ’]. currency_id.name"

/>

</div>


<strong >Print date </strong >:<br/>

78


<t t-esc="datetime.datetime.now().strftime(’%Y-%

m-%d %H:%M:%S’)"/>

</div>

</div>

</div>

</t>

</t>

</template >

</odoo>

Figura 11: Part de l’informe resultant del Llistat de codi 7. Font propia

Finalment, a part de l’estructura definida pels diferents directoris, un

dels elements mes importants en qualsevol modul d’Odoo es el fitxer conegut

com a Manifest, especificat a traves d’un diccionari de Python. En aquest,

cadascuna de les claus del diccionari defineix informacio relacionada amb el

modul, com per exemple el seu nom, versio, autor o llicencia. Tot i que

algunes d’aquestes dades son purament informatives, el cert es que n’hi ha

que son requerides pel sistema degut a que aquest les utilitza a l’hora d’afegir

o eliminar el modul:

79


• depends: especifica el nom dels moduls dels quals el que s’esta definint

depen. D’aquesta forma, el sistema sap quins son requerits a priori per

a poder instal·lar-lo satisfactoriament.

• data : especifica la ruta dins del codi del modul dels diferents fitxers

XML i CSV especificant vistes o llistes d’acces de seguretat, per tal que

el sistema pugui saber on trobar-los. Aixo no es unicament util en la

instal·lacio, amb l’objectiu d’emmagatzemar el seu contingut a la base

de dades, sino tambe per saber que cal eliminar un cop es desinstal·lael modul.

Llistat de codi 8: Exemple d’un fitxer Manifest d’un modul. Font propia

{

"name": "Product Dimension",

"version": "13.0.1.0.1",

"category": "Product",

"author": "brain -tec AG , ADHOC SA, Camptocamp SA, "

"Odoo Community Association (OCA)",

"license": "AGPL -3",

"website": "https :// github.com/OCA/product -attribute",

"depends": ["product"],

"data": ["views/product_view.xml"],

"installable": True ,

"images": ["static/description/icon.png"],

}

80

Capıtol 4

Aspectes Legals — Llicencies

Els aspectes legals associats a qualsevol projecte han de definir-se a priori,

establint les obligacions de les parts implicades a traves d’un contracte accep-

tat per aquestes, i complir-se al llarg de tot el proces. Tot i aixo, mes enlla de

les especificitats de l’acord, hi ha uns aspectes legals implıcits i innegociables

en el desenvolupament que s’han de considerar en l’execucio del projecte.

Aquests estan associats principalment a les obligacions derivades de l’us dels

multiples recursos tecnologics implicats en el projecte, especialment els quals

es manipularan directament en el seu desenvolupament, fruit de les llicencies

amb les que es distribueixen.

En el marc de la migracio, els principals elements involucrats son els

moduls que formen el sistema, els quals poden estar desenvolupats per di-

ferents actors de l’ecosistema d’Odoo. Per aquest motiu, a continuacio es

realitza un analisi dels principals a considerar i les seves corresponents im-

plicacions legals en el projecte.

81

4.1. CODI I MODULS COMMUNITY

4.1 Codi i Moduls Community

Tant per les versions 10 com 13, el codi d’Odoo Community esta distribuıt

sota la llicencia LGPL Versio 3 [28][29]. Tal i com s’ha comentat amb anterio-

ritat, aixo permet que aquest pugui ser usat per qualsevol persona lliurement,

aixı com integrat en el seu propi software, sense la necessitat d’haver-ne de

distribuir el codi resultant sota la mateixa llicencia. Com a consequencia,

la propia empresa Odoo S.A. pot desenvolupar i distribuir una versio pro-

pietaria del sistema basada en la versio Community, la qual es tracta en la

seguent seccio.

Es important destacar davant d’aquesta llicencia LGPL que, tot i poder

integrar lliurement el codi, en el cas de realitzar-hi qualsevol modificacio sı

que hi hauria la obligacio legal de distribuir el software resultant amb la

mateixa llicencia lliure. Per aquest motiu, en el context del present projecte,

quan es vulguin desenvolupar modificacions especıfiques per al client s’han

de realitzar afegint nous moduls que les apliquin sobre els de la capa base,

es a dir que el codi original no s’ha de modificar directament.

4.2 Moduls Enterprise

Tant per a les versions 10 com 13, els moduls de l’edicio Enterprise es distri-

bueixen sota la llicencia propietaria Odoo Enterprise Edition License v1.0.

Aquesta defineix una serie de condicions que estableixen el marc legal del

sistema [28]:

• El software i tots els fitxers associats nomes poden usar-se amb una

subscripcio valida d’Odoo Enterprise per al nombre correcte d’usuaris.

• Amb un acord de Partnership valid amb Odoo S.A., els permisos de-

finits en l’anterior punt estan tambe garantits, sempre i quan la seva

utilitzacio es limiti a entorns de prova i desenvolupament.

82

4.2. MODULS ENTERPRISE

• Es poden desenvolupar moduls d’Odoo basats en el software Enterprise

i distribuir-los sota qualsevol llicencia, sempre i quan sigui compatible

amb les condicions establertes per la Odoo Enterprise Edition License

(per exemple les llicencies LGPL, MIT o llicencies propietaries similars

a aquesta).

• Es poden usar moduls d’Odoo publicats sota qualsevol llicencia amb el

software Enterprise, sempre i quan les seves llicencies siguin compati-

bles amb les condicions establertes per aquesta.

• Esta prohibit publicar, distribuir, subllicenciar o vendre qualsevol copia

del software Enterprise, aixı com tambe qualsevol copia modificada.

• Els drets i condicions establertes en aquests ıtems s’han d’incloure en

totes les copies, aixı com porcions substancials, del software Enterprise.

• El software es proporciona sense cap tipus de garantia, i en cap succes

els autors ni els propietaris dels drets del software han de ser respon-

sables de cap reclamacio, desperfecte, o qualsevol altra responsabilitat

originada d’alguna interaccio amb el software o en connexio amb aquest.

En el marc del present projecte, tenint en compte que el client utilitza el codi

de la versio Enterprise, aquestes condicions hauran de complir-se. Per altra

banda, ForgeFlow disposa dels drets necessaris per a l’us del codi Enterprise

amb la finalitat del desenvolupament i prova del projecte, gracies a la seva

condicio de Partner d’Odoo, pel que no es presenten problematiques en aquest

aspecte.

83

4.3. MODULS DE LA ODOO COMMUNITY ASSOCIATION

4.3 Moduls de la Odoo Community Associa-

tion

Tal i com s’ha vist en la Seccio 3.1, els moduls desenvolupats per la OCA

estan distribuıts sota llicencies de codi obert [24]. La llicencia GPL v3 no

obliga a distribuir el codi d’un programari quan aquest s’utilitzi per a oferir

un servei, pero una de les seves variants, la AGPL v3, afegeix una clausula per

tal d’incloure aquest deure. Aixı, tot i que la OCA no estableix una llicencia

en especıfic, la gran majoria dels moduls utilitzen la AGPL v3 amb l’objectiu

de protegir a les empreses que disposin d’un proveıdor extern per al hosting

del seu sistema, amb l’objectiu final d’assolir la maxima transparencia per al

client.

En el marc del present projecte aquestes llicencies son altament consi-

derades, ja que en la migracio es pot requerir la manipulacio o afegiment

d’aquest tipus de moduls en el sistema del client. El seu us aıllat no suposa

cap problema, ja que aquests ja estan desenvolupats per a ser compatibles

amb la capa base d’Odoo. El problema, pero, es que si algun dels moduls cus-

tom ha d’estendre o simplement dependre d’algun distribuıt amb la llicencia

AGPL, haura de tenir obligatoriament la mateixa i distribuir-se lliurement.

4.4 Moduls privatius de tercers

Els moduls privatius de tercers, els quals poden estar distribuıts sota varies

tipologies de llicencia, no generen cap conflicte directe en el seu us en el

projecte degut a que ja compleixen amb les compatibilitats requerides. La

seva utilitzacio i capacitat de modificacio, pero, estara emmarcada en la

clausula legal de la llicencia que l’autor hagi emprat.

84

4.5. MODULS CUSTOM

4.5 Moduls custom

Els moduls especıfics de l’empresa client son de la seva propietat pero no

estan publicament disponibles, pel que no hi ha directament una llicencia

de distribucio especificada. Com s’ha esmentat anteriorment, el codi d’Odoo

permet ser utilitzat per a desenvolupar nou software que despres es pugui

distribuir sota qualsevol tipologia de llicencia, pel que els moduls custom

poden mantenir-se privatius.

Es important destacar, com s’ha esmentat anteriorment, que fruit de

la migracio es possible que algun d’aquests moduls hagi de dependre d’un

modul distribuıt sota la AGPL, que l’obligui a ser publicat sota la mateixa

llicencia. D’aquesta forma, aquests escenaris han d’analitzar-se i tractar-se

corresponentment si apareixen al llarg del projecte.

4.6 Matriu de compatibilitat de llicencies

Finalment es mostra en la seguent matriu la compatibilitat de l’us entre les

diferents llicencies identificades en l’ecosistema Odoo. Cal destacar que en el

cas de les propietaries, la seva compatibilitat es negociable ja que depen de

les especificitats marcades pel propietari.

LGPL v3 AGPL v3 Propietaria

LGPL v3 Ë Ë Ë

AGPL v3 é Ë é

Propietaria é é −

Les files representen la llicencia del codi original, iles columnes les llicencies del codi que utilitza l’o-riginal.

Taula 11: Matriu de compatibilitat de llicencies involucrades en el sistemaOdoo. Font propia.

85

Capıtol 5

Proces de migracio

En aquest bloc s’especifica el conjunt de fases involucrades en el proces de

migracio del sistema. Degut a que el nom de l’empresa client s’utilitza en

la nomenclatura de certs elements, en el contingut del treball s’ometra o es

substituira com a X per tal de preservar-ne l’anonimat.

5.1 Infraestructura de migracio

En aquesta seccio es descriu la infraestructura tecnologica utilitzada per al

proces de migracio, la qual esdeve la base per al desenvolupament de les

principals tasques del projecte relacionades amb la migracio del sistema i les

validacions corresponents.

5.1.1 Gestio del codi

Un dels elements essencials del projecte, per no dir practicament el mes

important, es el codi dels moduls del sistema. Aquest no nomes es refereix

al corresponent a la versio anterior, sino tambe al resultant de la migracio a

la versio 13.

86

5.1. INFRAESTRUCTURA DE MIGRACIO

Per al desenvolupament del projecte es essencial poder accedir i gestionar

facilment, aixı com tambe de forma segura, tot el codi involucrat en aquest.

El proces de migracio parteix dels moduls inicials, i a mesura que es realitza

la seva migracio cal assegurar que el codi resultant per a la versio posterior

estigui degudament emmagatzemat. Tanmateix, s’ha de considerar la gestio

del treball col·laboratiu que duu a terme l’equip de desenvolupament sobre

aquest, principalment a traves de l’us d’un sistema de control de versions.

Un sistema de control de versions es un sistema que registra els canvis rea-

litzats a un fitxer o conjunt d’aquests al llarg del temps, permetent recuperar

versions especıfiques en qualsevol moment [30]. L’oferta d’aquesta tipologia

de sistemes es variada, pero en aquest projecte s’utilitza el reconegut Git.

5.1.2 Git / GitLab

Git es un sistema de control de versions distribuıt de codi obert i lliure, el

qual permet gestionar eficientment tot tipus de projectes software [31]. El

seu us es complementa directament amb GitLab, una plataforma destinada

a l’allotjament de projectes software en repositoris a Internet, des de la qual

aquests poden ser gestionats ıntegrament a traves de multiples funcionalitats,

juntament amb les que ofereix Git.

Per a facilitar al maxim la gestio i manteniment del projecte, a GitLab

es creen tres repositoris diferenciats:

• X-odoo-addons (Moduls custom): en aquest repositori s’hi em-

magatzema i es gestiona el codi dels moduls especıfics del client, que

esdevenen els principals a migrar en el proces.

• X-addons-external (Moduls externs): en aquest repositori s’hi em-

magatzema i es gestiona el codi dels moduls propietaris externs de ter-

cers utilitzats en el sistema.

• X-odoo-docker (Imatges Docker): en aquest repositori s’hi emma-

gatzema i es gestiona el codi de les imatges Docker utilitzades per al

desenvolupament del projecte. El seu us es tracta a la Seccio 5.1.3.

87


Totes les modificacions que es realitzen en un projecte amb Git s’apliquen

a traves de commits, els quals capturen l’estat del codi amb aquests nous

canvis per tal de ser despres afegits al repositori. Cada commit esdeve aixı

una versio del projecte, el conjunt de les quals permet no nomes tracar-ne

la seva evolucio sino tambe tornar a una versio anterior davant de qualsevol

problema.

El desenvolupament i gestio de projectes en Git, aixı com en la majoria

de sistemes de control de versions, es basa principalment en la ramificacio

a traves de l’us de branques. Una branca es simplement un punter a algun

commit del projecte, pel que a la fi aquestes esdevenen una versio concreta del

codi. Gracies a aquesta funcionalitat, el flux de treball permet als membres de

l’equip desenvolupar les seves modificacions en branques diferents i isolades,

que posteriorment caldra ajuntar en una principal.

Cada projecte emmagatzemat a un repositori te una o varies branques

principals, que esdevenen la base sobre la qual aplicar modificacions a traves

de branques basades en aquestes. D’aquesta forma, s’assegura que tot el

contingut de les principals no es alterat incorrectament. Per a cada repositori

de moduls involucrat en la migracio, a GitLab es gestionen dues branques

principals:

• 10.0: corresponent al codi de la versio 10.

• 13.0: corresponent al codi de la versio 13.

Pel que fa a la imatge Docker, es gestionen tres branques principals:

• 10.0: corresponent a la imatge per al manteniment del sistema Odoo

en versio 10.

• 13.0: corresponent a la imatge per al manteniment del sistema Odoo

en versio 13.

• openupgrade: corresponent a la imatge utilitzada per a la gestio de

la migracio de la base de dades, tractada en major profunditat en la

Seccio 5.3.1.

88


5.1.3 Docker / Docker Compose

Docker es un projecte de codi obert que automatitza el desenvolupament i

desplegament d’aplicacions dins de contenidors software. Un contenidor es

una unitat estandard de software que empaqueta el codi d’una aplicacio i

totes les seves dependencies requerides per al seu funcionament. El projec-

te Docker ofereix una tecnologia que permet definir aquests contenidors a

traves de fitxers anomenats imatges, les quals especifiquen tot el necessari

per a executar l’aplicacio (codi, llibreries, configuracions...). Aquestes imat-

ges s’executen sobre l’aplicacio Docker Engine, en la qual es basa aquesta

tecnologia, convertint-se aixı en contenidors independents i isolats [32].

Molt sovint les aplicacions requereixen de multiples serveis per al seu

funcionament. Per aplicar les funcionalitats ofertes per Docker en aquests

escenaris, s’utilitza l’eina Docker Compose, que permet definir i executar

aplicacions multi-contenidor. D’aquesta forma, els contenidors dels serveis

requerits es configuren en un unic fitxer des d’on poden ser executats alhora

[33].

Per al desplegament del sistema Odoo en un servidor, els seguents serveis

son definits i executats a traves d’un fitxer Docker Compose:

• Odoo: executa una instancia del sistema Odoo amb les seves configu-

racions especıfiques.

• DB: executa una instancia del PostgreSQL, el sistema de gestio de la

base de dades utilitzat per l’Odoo.

• SMTP: executa una instancia del servei Simple Mail Transfer Protocol,

que permet establir comunicacions per correu electronic des d’Odoo.

• BackUp: executa una instancia del servei de backup de la base de

dades utilitzat, configurant la destinacio en la qual s’emmagatzema.

89


Degut a que no tots els serveis s’executaran igual en funcio de quin es el

proposit de l’entorn, cada branca d’imatge Docker conte tres tipus de fitxers

Docker Compose:

• Devel: executa els serveis per a ser utilitzats en un entorn de desen-

volupament.

• Test: executa els serveis per a ser utilitzats en un entorn de test.

• Prod: executa els serveis per a ser utilitzats en un entorn de produccio.

En un entorn de desenvolupament, per exemple, s’utilitzara una base de da-

des especıfica per a desenvolupament, el servei de backup no s’executara, i la

configuracio del SMTP no es comunicara amb l’exterior, sino que simplement

simulara l’enviament dels correus.

90


Figura 12: Fitxer Docker Compose de configuracio dels serveis utilitzats enel desplegament d’un sistema Odoo a un servidor. Font propia

91


5.1.4 Servidor de migracio

El servidor de migracio utilitzat en el projecte es un Virtual Private Server

(VPS), anglicisme referent a un Servidor Privat Virtual. Aquesta tipologia de

servidor permet allotjar aplicacions software de forma aıllada per a un mateix

client, a diferencia dels servidors compartits. Tanmateix, essent un servidor

virtual, no cal preocupar-se de la gestio i supervisio dels seus recursos, la

qual es desenvolupada per la propia empresa que l’ofereix. Aixı doncs, un

VPS es ideal per a projectes amb poca complexitat.

L’acces al servidor de migracio es realitza a traves de connexio ssh, i

alla s’emmagatzemen les tres branques Docker principals, tal i com es pot

observar en la Figura 13:

• Projecte OpenUpgrade: al servidor s’executen les migracions de

la base de dades, el resultat de les quals s’emmagatzema per estar

disponible pel sistema a la versio 13.

• Sistema Odoo del client Versio 13: la imatge Docker per al sistema

Odoo a la nova versio s’emmagatzema al servidor, des d’on s’executa

i es pot provar el seu funcionament. Aquesta imatge descarrega els

moduls per al sistema directament des dels repositoris de GitLab, pel

que es mante actualitzat facilment a mesura que es migren nous moduls

o es realitzen millores.

• Sistema Odoo del client Versio 10: ıdem de l’anterior, permet

provar els moduls de la versio actual per al seu analisi.

Figura 13: Connexio al servidor i llistat de directoris on es troben les imatgesprincipals. Font propia

92


5.1.5 Flux de treball

A partir dels diferents elements definits en la infraestructura, el flux de treball

segueix l’esquema observable en la Figura 14, tot a traves de connexio a

Internet.

Per una banda, els membres de l’equip de desenvolupament sincronitzen

els fitxers del projecte i les seves modificacions a traves dels repositoris de la

plataforma GitLab.

Les imatges Docker emmagatzemades al servidor, per altra banda, des-

carreguen les ultimes modificacions dels repositoris per a ser executades al

mateix servidor, juntament amb la resta de serveis requerits per mantenir el

sistema Odoo.

Finalment, els membres de l’equip poden accedir al sistema Odoo tant de

la versio 10 com 13 a traves del seu navegador web, gracies a la connexio al

domini del servidor.

Figura 14: Flux de treball a traves de la infraestructura. Font propia

93

5.2. ANALISI DE PROCESSOS

5.2 Analisi de processos

En la identificacio dels factors crıtics d’exit del projecte, desenvolupada en la

Seccio 2, un dels principals destacats es el de la composicio adequada de l’e-

quip de treball, amb especial emfasi en la necessitat d’alinear el coneixement

tecnic d’aquest amb el context de negoci implicat en el projecte.

Disposar del context i el coneixement dels processos desenvolupats en

l’empresa client, aixı com en la seva activitat empresarial, es essencial no

nomes per a facilitar el desenvolupament de la migracio, sino tambe per

assegurar-ne la seva correctesa.

Per tal d’afrontar aquest objectiu, en una de les primeres etapes un cop

iniciat el projecte es essencial involucrar el client el maxim possible per poder

aprendre:

• Quins son els principals processos de negoci involucrats en l’activitat

de l’empresa i quin es el seu flux d’execucio.

• Quin paper juga el sistema en aquests processos i com els diferents

actors involucrats hi interactuen.

• Quins problemes poden identificar en la seva interaccio amb l’actual

sistema.

Aquesta fase d’analisi en la part inicial del propi desenvolupament del pro-

jecte permet definir una serie d’arees especıfiques del context empresarial del

client, a partir de les quals es basaran gran part de les tasques posteriors en

la migracio. Cadascuna d’aquestes arees agrupa uns processos claus per a la

operativa diaria de l’empresa, els quals es duen a terme en alguna mesura a

traves del seu sistema Odoo. A traves del desenvolupament d’entrevistes amb

els seus principals key users, es poden obtenir els coneixements necessaris per

assolir els objectius establerts.

El motiu principal pel qual es realitza aquesta agrupacio a nivell de proces,

i no a nivell d’area de l’empresa, es pel fet que en molts escenaris un mateix

proces pot veure’s implicat en mes d’una, pel que els usuaris clau de cada un

poden formar part de varis departaments.

94


Finalment, per cada un dels processos que s’identifica a continuacio, un

dels membres de l’equip sera designat com a process owner, es a dir que sera el

responsable principal dels moduls associats i els processos de documentacio,

formacio i validacio corresponents. Aquells en els que l’autor es el responsable

es destacaran amb el nom en cursiva:

• Finance: Agrupa els processos relacionats amb les finances i compta-

bilitat de l’empresa. Els processos principals inclouen:

– Gestio de pagaments.

– Gestio d’extractes bancaris.

– Gestio de targetes de credit usades per despeses de treballadors.

– Gestio de futurs cobraments i despeses.

– Gestio de pagament i declaracio d’impostos.

– Gestio d’actiu no corrent i depreciacio.

– Gestio de nomines.

– Gestio de la comptabilitat d’inventari.

– Gestio del tancament de l’exercici comptable.

• Commission : Agrupa els processos relacionats amb la gestio de les

comissions. Els processos principals inclouen:

– Gestio de comissions per a dissenyadors.

– Gestio de comissions per a agents comercials.

• Sales : Agrupa els processos relacionats amb les vendes de l’empresa.

Els processos principals inclouen:

– Entrada, gestio i confirmacio de vendes.

– Gestio de la facturacio de vendes.

– Gestio de les vendes per comerc electronic.

– Gestio del renting de productes.

95


• Purchases: Agrupa els processos relacionats amb les compres de l’em-

presa. Els processos principals inclouen:

– Entrada, gestio i confirmacio de compres.

– Gestio de l’aprovisionament de stock.

– Gestio de proveıdors.

• Customer Relationship Management (CRM): Agrupa els pro-

cessos relacionats amb la gestio de potencials clients i vendes. Els

processos principals inclouen:

– Gestio de l’embut de vendes.

– Gestio de la forca de vendes.

– Gestio de la informacio i segmentacio de clients.

• Claims : Agrupa els processos relacionats amb la gestio de les queixes

dels clients. Els processos principals inclouen:

– Gestio de l’autoritzacio de devolucio de mercaderia, conegut amb

l’anglicisme Returns Merchandise Authorization (RMA).

– Gestio de recanvis de productes a clients.

– Gestio de reemborsaments.

• Marketing: Agrupa els processos relacionats amb el marqueting de

l’empresa i els seus productes, per tal de gestionar la seva estrategia i

augmentar-ne la seva comercialitzacio. Els processos principals inclo-

uen:

– Gestio de la publicitat de la marca i els seus productes.

– Gestio de l’email marketing, referencia a l’enviament de correus

electronics comercials a clients actuals i potencials.

96


• Product Development: Agrupa els processos relacionats amb la con-

figuracio i gestio dels productes oferts. Els processos principals inclo-

uen:

– Entrada i configuracio dels productes del sistema.

– Gestio del cicle de vida dels productes.

– Gestio de la configuracio de preus.

• Supply Chain: Agrupa els processos relacionats amb la gestio i ope-

rativa de la cadena de subministrament dels productes. Els processos

principals inclouen:

– Configuracio i gestio dels processos de subministrament dels pro-

ductes, que defineixen les rutes que segueixen per a arribar al

client.

– Seguiment de l’estoc a traves de la cadena de subministrament.

– Gestio de les transferencies d’estoc: recepcions, entregues, trans-

ferencies internes i drop shipments. Aquest ultim es refereix a una

tipologia de vendes en les que els proveıdors son directament els

encarregats d’enviar els productes al client, pel que aquests no

passen mai pels magatzems de l’empresa.

– Control i polıtiques de nivells d’inventari.

• Electronic Data Interchange (EDI): Agrupa els processos relacio-

nats amb la gestio de l’intercanvi electronic de dades entre el sistema

de l’empresa i sistemes externs. Els processos principals inclouen:

– Gestio d’EDI amb proveıdors.

– Gestio d’EDI amb clients.

– Gestio d’EDI amb magatzems.

– Gestio d’EDI amb empreses de transport i enviament.

97


• Human Resources: Agrupa els processos relacionats amb la gestio

dels recursos humans de l’empresa. Els processos principals inclouen:

– Gestio d’empleats i les seves dades.

– Gestio de les absencies dels treballadors, proces conegut com time

off management.

– Gestio de processos de sel·leccio de nous empleats.

Finalment, hi ha una serie de moduls de proposit general al sistema que no

s’emmarquen en cap area especıfica. Aquests afegeixen funcionalitats gene-

rals d’usabilitat per als usuaris del sistema, aixı com tambe personalitzacions

en l’aparenca visual de la interfıcie del programari. Aixı, com s’ha esmentat,

no queden explıcitament inclosos en cap proces.

98

5.3. MIGRACIO DE LA BASE DE DADES

5.3 Migracio de la base de dades

La migracio de la base de dades consisteix en aplicar les modificacions reque-

rides en l’estructura de les dades emmagatzemades corresponents a la versio

10, per tal que siguin totalment compatibles a la nova versio 13. D’aquesta

forma, en el moment en que es realitzi el desplegament final de la nova versio,

totes les dades podran estar disponibles.

Els canvis realitzats en l’estructura de les dades ve principalment mar-

cat per les modificacions que els models de dades dels diferents moduls del

sistema han tingut, pel que aquestes es poden discernir entre:

• Moduls core : els canvis requerits per mantenir les dades dels moduls

core del sistema de la versio 10 a la 13 estan coberts a traves del pro-

jecte OpenUpgrade. Entendre que es el projecte OpenUpgrade permet

comprendre com es realitza la migracio d’una base de dades d’Odoo,

pel que a la seguent seccio es tracta en major profunditat.

• Moduls custom : els canvis requerits sorgeixen al llarg del proces de

migracio del seu codi especıfic. Aquests es tracten doncs en la seva

corresponent Seccio 5.4.4.

En la Seccio 3 s’ha vist que, en l’estructura d’Odoo, el sistema utilitzat per

a la gestio de la base de dades es relacional. Per aquest motiu, la migracio

de la base de dades es basa en l’execucio de sentencies SQL les quals

apliquen les modificacions necessaries per assegurar la integritat de les dades

en la nova versio.

5.3.1 OpenUpgrade i el Gestor de Migracio d’Odoo

OpenUpgrade es un projecte nascut de la iniciativa de la comunitat d’Odoo

per tal de proveir un metode d’actualitzacio de codi obert per als sistemes

Odoo [34]. El projecte conte els scripts requerits per a la migracio de la base

de dades d’un sistema Odoo, contemplant els moduls estandard proveıts per

la versio Community. Aixo es degut a que l’empresa Odoo S.A. nomes ofereix

el servei de migracio per a clients amb subscripcio Enterprise, aixı com tambe

als que adquireixen un servei de suport oficial.

99


La metodologia emprada pel projecte es basa en el gestor de migracio que

el propi sistema Odoo utilitza internament:

1. Pre-migration: fase on s’executen els scripts requerits abans de car-

regar un modul a la base de dades. En aquesta fase la base de dades

no ha estat encara alterada per la instal·lacio/actualitzacio del modul.

2. Post-migration: fase on s’executen els scripts requerits despres de

carregar un modul a la base de dades. En aquesta fase la base de dades

ha estat ja alterada per la instal·lacio/actualitzacio del modul.

3. End-migration: fase final on s’executen els scripts requerits un cop

tots els moduls ja han sigut carregats a la base de dades. En aquesta

fase tots els moduls han estat ja instal·lats/actualitzats.

Com s’ha vist en la Seccio 3.2.2, cada modul conte un fitxer on s’especifica

la seva versio. Aquesta s’especifica amb la versio d’Odoo (ex: 13.0), seguida

de la versio del modul x.y.z on:

• x : incrementa quan es produeixen canvis significatius en els models de

dades o vistes del modul. Solen ser canvis que requereixen scripts de

migracio.

• y : incrementa quan s’afegeixen noves caracterıstiques.

• z : incrementa quan es produeixen correccions poc significatives.

Aquesta nomenclatura s’utilitza per anomenar els directoris en els quals s’em-

magatzemen els scripts de migracio dins l’estructura d’un modul. Cada ve-

gada que s’actualitza (o s’instal·la) un modul al sistema, Odoo comprovara

automaticament la seva versio actual (abans de l’actualitzacio) amb l’espe-

cificada en el/s directori/s de migracio. Si la versio corresponent als fitxers

de migracio es posterior, aquests s’executaran.

El projecte OpenUpgrade esta disponible publicament a traves de Github,

on s’emmagatzema, es gestiona i es desenvolupa el codi. Cadascuna de les

branques del repositori emmagatzema la versio d’OpenUpgrade destinada a

la corresponent migracio de la versio d’Odoo, facilitant la seva organitzacio.

Per a cada versio, l’estructura del codi segueix les seguents directrius:

100


• Dins el directori addons, on es troben emmagatzemats els moduls de la

versio base d’Odoo, per cada un d’ells es segueix la mateixa estructura

base que en la versio corresponent d’Odoo, com es pot observar en la

Figura 15. En aquest cas, la principal diferencia recau en el directori

migrations/, el qual conte els directoris de migracio especıfics.

• Per a cada un dels directoris de migracio dels moduls, com es pot

observar en l’exemple de la Figura 16, es troben els fitxers desenvolupats

pel projecte OpenUpgrade, essent els mes importants els corresponents

al pre-, post- i end-migration.

Figura 15: Estructura d’un modul d’OpenUpgrade 13 (esquerra) i OdooCommunity 13 (dreta). Font propia

Figura 16: Estructura d’un directori de migracio d’un modul. Font propia

101


5.3.2 openupgradelib

El projecte OpenUpgrade es basa en un altre projecte desenvolupat per la

OCA: l’openupgradelib. Aquest esdeve la llibreria principal utilitzada per

a dur a terme les migracions dels diferents moduls d’Odoo Core, i defineix

una serie de funcions a utilitzar davant dels escenaris en els que es pot trobar

un sistema a consequencia de canvis en la seva estructura de dades. Alguns

exemples de les funcions que defineix openupgradelib son:

• rename fields : Funcio utilitzada en scripts de migracio quan un dels

atributs d’un model de dades, el qual s’emmagatzema a la base de

dades, ha tingut una modificacio en el seu nom en una nova versio

del modul. Tal i com es pot observar en la Figura 17, on es mostra

part del metode, un dels passos essencials que executa es una operacio

SQL d’actualitzacio sobre la taula ir model fields de la base de dades.

En aquesta, on s’emmagatzemen els atributs dels models presents al

sistema, modifica el nom original de l’atribut pel nou, a partir dels

parametres que el metode rep per part de l’usuari que desenvolupa el

fitxer de migracio.

• drop columns : Seguint la lınia de l’anterior, aquesta funcio s’utilitza

quan una nova versio d’un modul elimina un dels atributs que un model

definia originalment. En la Figura 18, on es mostra part del metode,

un dels passos essencials que executa es una operacio SQL sobre la

taula del model per tal d’eliminar el camp corresponent a l’atribut.

Tanmateix, el propi metode comprova previament si el camp ja ha estat

eliminat, per tal d’evitar errors en l’execucio de la instruccio SQL. Idem

de l’anterior, els parametres requerits es passen a la funcio en la seva

crida des dels fitxers de migracio.

Gracies a les funcions implementades en la llibreria, aquestes poden ser utilit-

zades per a desenvolupar els scripts especıfics dels moduls custom, dels quals

es parlara mes especıficament a la Seccio 5.4.4.

102


Figura 17: Part del metode rename fields d’openupgradelib. Font propia

Figura 18: Part del metode drop columns d’openupgradelib. Font propia

103


5.3.3 Proces de migracio de la Base de Dades

Partint del projecte OpenUpgrade, el codi corresponent als moduls core uti-

litzats en el sistema del client s’emmagatzema al repositori de GitLab. Tal

i com s’observa en la Figura 19, degut a que els scripts d’OpenUpgrade es

desenvolupen per cada versio principal d’Odoo, cal incloure les branques del

projecte per tal d’assolir la migracio de la versio 10 a la 13. D’aquesta for-

ma, el proces de migracio de la base de dades pels moduls core engloba en si

mateix tres processos:

• Migracio de la base de dades V10 −→ V11.



Cada proces de migracio de la base de dades, especificat en el diagrama de la

Figura 20, s’inicia llancant l’actualitzacio de tots els moduls del sistema

amb el codi corresponent a la versio objectiu. Per cada un d’ells, si hi ha

fitxers de migracio que cal executar, s’executaran en el moment corresponent.

Figura 19: Branca openupgrade del repositori del projecte. Font propia

104


Figura 20: Proces de migracio OpenUpgrade. Font propia

105

5.4. MIGRACIO DELS MODULS

5.4 Migracio dels moduls

La migracio del sistema Odoo compren principalment dues grans parts: la

migracio de les dades i la migracio dels moduls. Ambdos processos estan

altament relacionats ja que en funcio de les modificacions realitzades en la

migracio d’un modul, unes consequents modificacions a la base de dades seran

requerides.

Tal i com s’ha comentat en la Seccio 1.4.2, el proces de migracio dels

moduls del projecte compren una metodologia iterativa en la qual es desen-

volupen una serie de tasques. Per tal de mostrar el desenvolupament del

proces, es mostren en les principals tasques involucrades exemples de moduls

implicats en el projecte. Per cada una d’elles, un dels exemples es el ma-

teix, amb l’objectiu de poder mostrar un proces integral aplicat a un mateix

modul. Tot el material d’exemple que es mostra en les properes

seccions ha estat desenvolupat per l’autor del present treball.

5.4.1 Volum de moduls

Previament a detallar les principals tasques involucrades en el proces de

migracio dels moduls, es important especificar el volum amb el que es troba en

el present projecte. Aquest proces compren els moduls especıfics de l’empresa

client, els quals en el present projecte esdevenen una quantitat important,

fent que la complexitat d’aquest sigui major que en altres escenaris de la

mateixa tipologia.

En la Seccio 5.2, s’han definit els principals grups de processos de l’em-

presa, que permeten estructurar alhora els moduls involucrats en la migracio.

Tot i que cada proces disposa d’un responsable assignat, degut a la meto-

dologia de treball i la integracio d’aquests al sistema, fa que a la fi tots els

membres hagin potencialment de desenvolupar modificacions per moduls de

qualsevol proces.

106


Cal destacar tambe que, per una banda, en grups com Finance o Supply

Chain en els quals el volum de moduls es considerablement major, la seva

carrega total s’ha dividit entre els membres de l’equip a part del process ow-

ner en funcio de la seva disponibilitat. Tanmateix, s’ha de tenir present que

la logica afegida per un modul pot tenir un volum i complexitat molt major

que l’afegida per un altre. Aixı, mentre que processos com Commission i

Claims es basen en pocs moduls complexos que engloben tots els models i

funcionalitats requerides per aquests, altres com Product Development en-

globen petits moduls amb funcionalitats molt mes especıfiques.

Grup # Moduls principals implicats

Finance 19

Commission 1

Sales 12

Purchases 2

CRM 9

Claims 2

Marketing 9

Product Development 28

Supply Chain 22

EDI 9

Human Resources 4

General 13

TOTAL 130

Taula 12: Volum de moduls per proces. Font propia.

107


5.4.2 Analisi Inicial del modul

L’analisi d’un modul es desenvolupa principalment en dues vessants:

• Analisi Estatic: centrat en la lectura i comprensio del codi (models

de dades que es defineixen, metodes utilitzats, vistes...). Aquest analisi

permet obtenir una primera avaluacio de les funcionalitats afegides pel

modul, aixı com discernir si es tracta d’una nova aplicacio o si s’esta

modificant/estenent una d’existent. Tanmateix, a partir de les vistes

(si se’n defineixen) es pot veure com accedir als nous models o camps

afegits, facilitant el desenvolupament de l’analisi dinamic o funcional.

• Analisi Dinamic o Funcional: centrat en la prova funcional del

comportament del modul, aixı com de la seva implicacio en els processos

de l’empresa. En aquesta tasca pren gran importancia la informacio

recopilada en les reunions inicials amb els usuaris clau de les diferents

arees de l’empresa client, juntament amb el previ analisi estatic.

Aquest analisi inicial es materialitza en les tasques de documentacio tecnica

del modul, aixı com tambe pren importancia en el desenvolupament de do-

cumentacio i formacio per a usuaris, les quals es tracten mes endavant.

Exemple: Analisi Estatic

En aquest primer exemple es pot observar l’estructura de dos moduls del

sistema en la versio 10:

• L’estructura del modul x sale a la Figura 21 permet veure, en una

primera instancia de l’analisi estatic del codi, que aquest aplica modi-

ficacions a models base del sistema. Mes concretament, aquestes estan

relacionades amb models de sale i stock, fet que ja permet relacionar-lo

amb aplicacions de Sale (usada per a la gestio de vendes) i Inventory

(usada per a la gestio de stock i la cadena de subministrament, entre

d’altres).

Tanmateix, la presencia dels directoris report i wizard mostra que el

modul implementa o modifica models d’aquests dos tipus. Aixı, com

mes modificacions afegeix el modul mes augmenta la seva complexitat.

108


• L’estructura del modul x designer a la Figura 22 permet identificar

rapidament la implementacio d’un nou model anomenat designer. Se-

guint les practiques d’Odoo els noms dels fitxers que implementen codi

de models s’anomenen en relacio als models que estan utilitzant en

aquests. Gracies al coneixement i formacio en el sistema, es pot iden-

tificar facilment si un model forma part dels models core o no.

Paral·lelament, la presencia del directory security permet reafirmar

l’observacio anterior, ja que seguint les practiques d’Odoo es impor-

tant implementar permisos d’acces als nous moduls que es defineixen.

En definitiva, l’analisi estatic simplement de l’estructura d’un modul per-

met rapidament identificar-ne caracterıstiques de la logica que implementa.

Obviament, pero, es important aprofundir en els diferents fitxers per tal

d’analitzar els diversos models, atributs implementats, i els seus metodes.

Finalment, cal destacar que l’analisi general d’un modul esdeve molt mes

senzill si aquest va acompanyat d’una bona documentacio tecnica, pel que la

tasca corresponent a la Seccio 5.4.5 es essencial en el proces de migracio.

Figura 21: Estructura del modulx sale. Font propia

Figura 22: Estructura del modulx designer. Font propia

109


Exemple: Analisi Dinamic/Funcional

Partint de l’analisi estatic del modul x designer on s’afegeix un nou model,

tal i com s’ha mostrat en l’exemple anterior, cal analitzar tambe la seva

implementacio a nivell funcional. Si s’observa el codi corresponent a les

vistes que implementa el modul, s’identifica rapidament la implementacio

d’un menu especıfic per al model que es defineix, fent us de l’etiqueta XML

oferta pel framework anomenada menuitem (Figura 23).

Figura 23: Codi parcial de les vistes del modul x designer. Font propia

El menu esta associat a un menu pare, especificat amb l’atribut parent de

l’etiqueta XML, el qual esta definit per l’aplicacio website. D’aquesta forma,

des de l’Odoo en la versio 10, es pot facilment localitzar el menu del modul

des de la corresponent aplicacio. Per defecte, fent click al menu Designers,

es presenta una llista de les instancies definides al sistema, com s’observa en

la Figura 24. Aquest tipus de vista, anomenada en Odoo com a tree o list,

esta implementada en el mateix modul, i permet mostrar diferents atributs

de les instancies del model com a columnes.

110


Figura 24: Vista tree del model x designer. Font propia

Per altra banda, es tambe possible crear noves instancies del model direc-

tament des del sistema. Fent click al corresponent boto, es presenta la vista

anomenada en Odoo com a form, la qual permet visualitzar la informacio re-

lativa a una instancia especıfica del model. Aquesta vista ens permet veure

els atributs requerits per a crear una nova instancia, tal i com s’observa en la

Figura 25, aixı com tambe crear informacio per a seguir provant i analitzant

el modul.

Figura 25: Vista form del model x designer. Font propia

111


Finalment, a l’hora d’analitzar funcionalment el modul, cal tenir present

no nomes el seu propi context, sino tambe la seva interaccio i/o integracio

en altres moduls. En l’exemple de la Figura 26 es pot observar com el model

definit es relaciona directament amb el model que defineix un producte al

sistema. Concretament, per cada producte del sistema es pot relacionar una

instancia del model designer, definint aixı el seu dissenyador.

Figura 26: Part de la vista d’un producte del sistema. Font propia

112


5.4.3 Migracio del codi

La migracio d’un modul parteix de l’existencia i preparacio dels seguents

elements principals:

• Versio origen del modul, emmagatzemada a la seva corresponent branca

(10.0) del repositori del projecte (Figura 27.

• Branca destı del modul en la nova versio (13.0), present en el repositori

del projecte.

• Copia local del repositori a l’ordinador del desenvolupador, a traves de

la comanda clone de Git.

Llistat de codi 9: Clonacio del repositori del projecte en l’ordinador personal.

Font propia

$ git clone [email protected]:repositori/X-odoo -addons.git

Amb aquests elements, el proces de migracio del codi de cada modul segueix

una serie de principals passos que es poden enumerar de la seguent forma:

1. Creacio de la branca de migracio del modul: seguint les bones

practiques en l’us d’un sistema de control de versions, es crea una

branca especıfica en la que es desenvolupa la migracio del modul.

2. Copia de l’historial de commits : per tal de mantenir la tracabilitat

del cicle de vida del modul, es mante l’historial de commits que s’han

realitzat en la versio original. Aixo fa que, en el moment d’analitzar

la historia de cada modul en el repositori, es puguin veure totes les

modificacions que s’hi han aplicat des del seu inici.

Llistat de codi 10: Comandes per a l’execucio dels dos primers passos. Font

propia

# $MODULE es refereix al nom del modul migrat

$ git checkout -b 13.0-mig -$MODULE origin /13.0

$ git format -patch --keep -subject --stdout origin /13.0.. origin /12.0 --

$MODULE | git am -3 --keep

113


Figura 27: Captura parcial dels moduls a la branca 10.0. Font propia

3. Modificacions essencials: entre les diferents versions d’Odoo, hi ha

una serie de canvis essencials realitzats a nivell del framework que cal

aplicar a tots els moduls que hagin de migrar-se. Aquestes modificaci-

ons, tot i representar una petita part de la carrega del proces de migra-

cio, son crıtiques per assegurar que un modul funciona correctament a

la versio destı. Per aquest motiu, la comunitat de la OCA els recull

en documents especıficament dedicats a cada nova versio, els quals son

actualitzats i revisats constantment, amb l’objectiu de facilitar aquesta

tasca als desenvolupadors.

114


En el marc del projecte, degut a que la migracio es produeix de la versio

10 a la 13, es consideren els canvis aplicats entre les versions 10 i 11

[35], 11 i 12 [36], i finalment 12 i 13 [37].

4. Modificacions especıfiques: un cop aplicades les modificacions es-

sencials, cal assegurar que el modul mante la seva correcta funcionalitat

en la nova versio, no nomes a nivell del seu flux d’execucio sino tambe

pel que fa a les interfıcies/vistes que implementa. Es tracta d’un proces

el qual requereix l’aplicacio tant de coneixements tecnics com de nego-

ci, ja que cal entendre no nomes quina es la funcio del modul, sino quin

es el seu paper en el corresponent/s flux de negoci on esta implicat.

Per altra banda, aquestes modificacions son principalment tambe resul-

tat dels canvis aplicats en els models definits pels moduls core d’Odoo.

A la fi, la gran majoria de moduls son dependents de moduls core,

sobre els quals s’hi apliquen modificacions i/o extensions, pel que qual-

sevol canvi en aquests te un impacte directe en la migracio. Degut a

la filosofia en el desenvolupament del sistema Odoo, juntament amb la

seva trajectoria i el seu creixement al llarg dels ultims anys, fa que en

cada gran versio llancada es produeixin canvis importants en multiples

moduls base.

Exemple: Modificacions Essencials

En aquest primer exemple s’analitzen alguns dels canvis relatius a modi-

ficacions essencials mes comunes en el proces de migracio del codi dels

moduls:

• Especificacio de versio: per tots els moduls cal indicar correctament

la seva versio en el manifest. Com es pot observar en la Figura 28, al

codi de la versio 10 del modul no s’indica la versio seguint les guies

de la OCA, mentre que resultat de la migracio en la versio 13 (Figura

29) s’ha modificat corresponentment. Es essencial definir la versio cor-

rectament, no unicament per la importancia a nivell d’especificacio del

modul, sino tambe per als scripts de migracio que pugin requerir-se.

115


• Dependencies: seguint amb la comparacio dels dos manifest del punt

anterior, en la versio 13 s’ha eliminat redundancia en l’especificacio de

les dependencies dels moduls del sistema. Per exemple, mentre que

en la versio 10 s’especifiquen els moduls de sale, sales team, sale crm,

stock i delivery, a versio 13 nomes s’especifiquen delivery i sale crm.

Aixo es deu a que les dependencies d’aquests dos ultims ja afegeixen la

resta.

Figura 28: Fitxer manifest en ver-sio 10. Font propia

Figura 29: Fitxer manifest en ver-sio 13. Font propia

• Eliminacio de decoradors: a nivell de framework, una de les des-

tacables a nivell de codi Python es l’eliminacio dels decoradors. Odoo

disposa fins a la versio 12 d’uns decoradors1 per a les funcions, en-

tre els quals els mes utilitzats son @api.multi (el metode s’executa per

multiples instancies del model) i @api.one (el metode s’executa per una

unica instancia del model).

1A Python, un decorador es una funcio que esten el comportament d’una altra funciosense modificar-la directament.

116


En el canvi d’Odoo 12 a Odoo 13, aquests decoradors han quedat obso-

lets, ja que per defecte ara tots els metodes es considera que s’executen

per a multiples instancies. En aquest escenari, doncs, les modificacions

essencials passen per eliminar-los com s’observa en la comparacio entre

les Figures 30 i 31.

Figura 30: Metode amb decoradora versio 10. Font propia Figura 31: Metode sense decora-

dor a versio 13. Font propia

• Camps calculats: en la versio 13 del framework, un dels altres canvis

importants es que els atributs calculats han de disposar sempre d’un

valor, fet que no era requerit en versions anteriors. Aixo es tradueix en

que els metodes utilitzats per a calcular-los han de definir sempre un

valor a l’atribut, per molt que sigui un False.

Quan en la versio 13 no s’assegura aquest comportament Odoo retorna

un error en accedir als models afectats, pel que aquests canvis sovint es

detecten en les proves funcionals dels moduls. Aixı, com es pot observar

en la diferencia entre el metode en versio 10 (Figura 32) i el de la versio

13 (Figura 33), en aquest ultim s’assigna per a cada instancia rebuda

pel metode un valor a l’atribut calculat requested date.

Figura 32: Metode de camp calculat a versio 10. Font propia

117


Figura 33: Metode de camp calculat a versio 13. Font propia

• Canvis relatius a la versio Python: la versio Python usada en

Odoo 10 es la 2.7, pero a partir de la 11 es canvia a la 3 (o posteriors).

Concretament, a la versio 13 s’utilitza la 3.7, pel que a la migracio

dels moduls cal adaptar els canvis relacionats amb la transicio entre les

grans versions de Python.

Per una banda, aquests poden tractar-se de modificacions molt es-

pecıfiques, com el fet que a partir de Python 3 els fitxers ja es codifiquen

per defecte en el format UTF-8. Aixı, les lınies utilitzades en moduls

com es veu a la Figura 34 poden eliminar-se.

Figura 34: Especificacio del format de codificacio d’un fitxer Python en Odoo10. Font propia

Per altra banda, el canvi de versio de Python pot tenir un impacte en

el framework d’Odoo. Per exemple, en versions anteriors els camps de

tipologia date/datetime oferts per Odoo retornen un string. Amb les

noves versions, pero, s’han modificat per encapsular i retornar direc-

tament objectes date/datetime de Python 3. Aixo provoca modificar

la gestio d’aquests camps en els metodes de tots els moduls especıfics

que els utilitzin o implementin, com es pot observar en la comparativa

entre les Figures 35 i 36.

118


En el metode de l’exemple es vol retornar una llista de dates en format

datetime. En la versio 10, com que els atributs retornen un string,

cal transformar el seu valor fent us de la funcio from string. A la

versio 13, pero, aquesta ja no es requerida. Gestionar correctament

aquests canvis es essencial per assegurar el correcte funcionament del

modul, especialment quan aquests atributs s’utilitzen en interaccions

i/o integracions amb altres moduls o, fins i tot, sistemes externs.

Figura 35: Metode en versio 10. Font propia


Exemple: Modificacions Especıfiques

En aquest segon bloc es mostren breument alguns dels canvis relatius a mo-

dificacions especıfiques en el proces de migracio del codi dels moduls. Com

s’ha esmentat anteriorment, aquests canvis principalment son fruit de modi-

ficacions en els moduls core d’Odoo, dels quals depenen els moduls especıfics

del client.

119


Un primer exemple del modul x sale es fruit d’un canvi en el modul core

delivery. En la versio 10, Odoo permet definir el metode d’enviament d’una

venda a traves d’un camp directament accessible i definit en el model de

la venda, com s’observa en la Figura 37. Tanmateix, fent click al boto Set

price, afegeix directament els corresponents costos d’enviament. En la versio

13, pero, aquest comportament s’ha modificat i el proces es realitza a traves

d’un wizard, accessible des de la venda amb el boto Add Shipping, escollint

en aquest el metode a aplicar (Figura 38).

Figura 37: Assignacio de metode d’enviament a Odoo 10. Font propia

Figura 38: Assignacio de metode d’enviament a Odoo 13. Font propia

120


El modul custom afegeix logica directament relacionada amb els metodes

d’enviament en les vendes. Per una banda, defineix una funcio per assignar

automaticament el metode d’enviament en funcio del client (Figura 39), la

qual s’aplica directament a nivell del model de la venda. Per tal d’adaptar

la mateixa logica al estandard de la versio 13, com s’observa en la Figura

40, es trasllada la logia a una funcio anomenada get partner carrier, la qual

s’executa just en el moment en que l’usuari obre el wizard. D’aquesta forma,

s’assegura que el metode d’enviament que s’assigna automaticament en el

wizard mante la logica emprada en la versio 10.



121


Per altra banda, el modul custom tambe afegeix una logica especıfica

per a filtrar metodes d’enviament definits en el sistema. Concretament, com

s’observa en la Figura 41, s’especifica un domini per a l’atribut que relaciona

el metode d’enviament a la venda, fent que l’usuari nomes pugui escollir

aquells que tenen l’atribut is calculator com a True.


Degut a que el metode d’enviament s’escull ara a traves del wizard, aquest

filtratge cal aplicar-lo en el model que l’implementa. Concretament, el model

estandard defineix ja una funcio per determinar els metodes d’enviament que

es poden escollir, pel que com s’observa en la Figura 42 el domini cal aplicar-

lo en aquesta.


L’exemple vist amb el modul x sale permet il·lustrar la importancia de

considerar els riscos del projecte a l’hora de desenvolupar la migracio, ja que

un dels factors mes importants es intentar evitar desenvolupaments a mida

sempre i quan es pugui mantenir en lınia amb el comportament estandard

del sistema.

122


Finalment, a nivell de migracio de codi XML referent a vistes, una de

les modificacions especıfiques que normalment es requereix es fruit de canvis

en les vistes de moduls core, sobre les quals els moduls custom hi apliquen

modificacions o hi depenen. En el cas del modul x account payment order,

per exemple, es pot observar com una vista implementada en versio 10 (Fi-

gura 43) hereta d’una anomenada invoice supplier form, per al model ac-

count.invoice, i modifica un camp de la vista anomenat partner bank id.

Figura 43: Codi de vista en versio 10. Font propia

A la versio 13, el model account.invoice es substituıt per account.move

en el modul core, i tant la vista com l’atribut que hereta han modificat el seu

nom. Fruit dels canvis, doncs, es migra el codi amb el resultat de la Figura

44.

Figura 44: Codi de vista migrat en versio 13. Font propia

123


5.4.4 Scripts de migracio

Resultat de la migracio del codi d’un modul, canvis en l’estructura de da-

des dels models que defineix o hereua poden suposar haver de desenvolupar

scripts de migracio especıfics per aquest, fent us de la llibreria oferta pel

projecte OpenUpgrade del qual es parla a la Seccio 5.3.1.

Els diversos escenaris que cal afrontar a l’hora de desenvolupar els scripts

de migracio, poden agrupar-se a nivell general en dues tipologies:

• Canvis en models de dades definits pel propi modul: quan

els canvis es produeixen en models de dades definits pel propi modul

custom.

• Canvis en models de dades definits per altres moduls: quan

el modul afegeix nous camps en models de dades definits per altres

moduls, els quals s’han vist afectats entre la versio 10 i la 13.

Com be s’ha presentat en la seccio corresponent al projecte OpenUpgrade,

especialment en relacio a la llibreria d’openupgradelib, aquesta esdeve la

base a partir de la qual desenvolupar els fitxers de migracio requerits per

cada modul.

Exemple: Funcio d’OpenUpgrade

En aquest primer exemple es mostra el fitxer de migracio per al modul

x commission, el qual afegeix una serie de nous models al sistema per a

gestionar les comissions. En el proces de migracio, a alguns dels atributs

dels models se’ls ha modificat el nom. Per a gestionar correctament la com-

patibilitat de la base de dades, cal modificar corresponentment aquests noms

a les columnes de les taules implicades.

En base a la llibreria d’openupgradelib, la qual s’importa a l’inici del fit-

xer, en aquest escenari es pot aprofitar una de les seves funcions: el field

rename. Aquest metode ha de rebre com a parametre una llista on s’espe-

cifiquin els canvis requerits, seguint la seguent estructura per cada un dels

seus elements:

124


• Nom del model: en el cas de l’exemple, es realitzen canvis a tres mo-

dels: commission.pricing, commission.commission, i finalment al co-

mission.agreement.line.reduction.

• Nom de la taula de la base de dades: el nom corresponent a la

taula de la base de dades del model es el mateix que el seu nom pero,

en comptes d’un ”.”s’utilitza un ” ”.

• Nom original del camp: nom del camp en la versio 10, i que es

precisament el nom de la columna de la taula del model a la base de

dades.

• Nom del nou camp: nom del camp que s’utilitza en el codi de la

versio 13, el qual cal fer servir a nivell de base de dades per assegurar-

ne la compatibilitat.

D’aquesta forma, la funcio assegurara no nomes que l’estructura de la base

de dades es mante compatible amb els canvis del codi de la versio 13, sino

que els valors que estaven en la columna original es mantindran en la nova

columna.

Finalment, cal destacar la funcio migrate, oferta per la llibreria, la qual es-

deve la base per a executar tots els metodes dels fitxers de migracio. Aquesta,

aixı com la resta de metodes, ha de rebre tambe un parametre Environment

(env), des del qual es pot accedir al cursor 2 de la base de dades.

Figura 45: Codi exemple fitxer de migracio d’un modul. Font propia

2Un cursor es una estructura oferta des de l’ORM que permet interaccionar amb lesinstancies de la base de dades.

125


Quan s’executa l’actualitzacio del modul en la migracio de la base de

dades, OpenUpgrade mostra en els corresponents logs les accions que s’estan

realitzant. Aixo es pot observar en els exemples d’altres moduls que utilitzen

la funcio com la de rename fields mostrats en la Figura 46.

Figura 46: Logs corresponents a l’execucio de fitxers de migracio. Fontpropia

Exemple: Comanda SQL especıfica

En aquest segon exemple es mostra el fitxer de migracio per a un modul el

qual requereix d’una comanda SQL especıfica, es a dir que no pot aprofitar-se

d’un metode predefinit en la llibreria d’openupgradelib. Tot i aixo, com es pot

observar en la corresponent Figura 47, aquesta segueix la mateixa estructura

amb el pas de l’environment. Tanmateix, cal destacar que la comanda SQL

no s’executa directament al fitxer, sino que es passa com a parametre al

metode de la llibreria logged query. Aquest, no nomes executara la comanda

sino que tambe mostrara als logs del sistema informacio relacionada amb

aquesta.

En el cas concret d’aquest exemple, ens trobem en una situacio en la que

un modul custom afegia a la versio 10 una serie de camps al model account

invoice, definit en un dels moduls core del sistema. A la versio 13, pero, el

model queda obsolet i es substitueix pel model account move. Aixı, el metode

implementat en el fitxer realitza una actualitzacio dels camps custom a les

instancies del nou model que son equivalents al model original.

126


Es essencial destacar que el desenvolupament d’aquests scripts es deu

gracies a que, per una banda, la migracio d’OpenUpgrade mante les taules

de la base de dades al llarg del proces, pel que tot i quedar un model obsolet

les seves dades es mantenen accessibles fins que no se’n realitzi una neteja.

Per altra banda, com s’observa en la propia comanda SQL, hi ha una relacio

establerta entre el model original i el nou, la qual es resultat de la migracio

del modul core que afegeix el canvi. Alla, les instancies del model account

invoice es converteixen en noves instancies del model account move.

Figura 47: Codi exemple fitxer de migracio d’un modul. Font propia

127


5.4.5 Documentacio tecnica

Una de les bones practiques seguides per la Odoo Community Association es

la de desenvolupar un fitxer README per cada un dels moduls que mante.

Aquest es un fitxer de text que s’afegeix al directori principal d’un modul,

i que te com a principal objectiu definir resumidament les caracterıstiques

principals del modul.

En el present projecte, aquesta practica es segueix definint els fitxers

README per cada modul que es migra, els quals no estan presents en la

versio original, per tal de facilitar-ne la seva comprensio i futur manteniment.

El format utilitzat per definir els fitxers es el ReStructuredText, i l’estructura

de cada README conte la seguent informacio principal:

• Title: Nom del modul.

• Description: Descripcio resumida del proposit del modul i les funcio-

nalitats principals que afegeix.

• Usage: Breu explicacio de com utilitzar el modul a nivell funcional.

• Credits: Credits del modul.

– Authors: Autor/s del modul.

– Contributors: Contribuıdors que han aplicat millores o modifi-

cacions al codi original del modul.

Exemple: Documentacio 1

En aquest primer exemple es mostra a la Figura 48 el codi corresponent al

fitxer de documentacio tecnica del modul x sale, seguint l’estructura presen-

tada en aquesta seccio. Aquest fitxer de codi es utilitzat internament per

Odoo per tal de mostrar la informacio del modul des del buscador de moduls

del sistema. Aixı, l’usuari podra visualitzar-la a traves de la interfıcie de la

forma com s’observa en la Figura 49.

128


Figura 48: Codi d’exemple d’un fitxer README. Font propia

129


Figura 49: Visualitzacio d’un fitxer README a l’Odoo. Font propia

130


Exemple: Documentacio 2

En aquest segon exemple es mostra a la Figura 50 el codi corresponent al

fitxer de documentacio tecnica del modul x payment term blocker, seguint

l’estructura presentada en aquesta seccio. A diferencia de l’exemple anterior,

en aquest es vol mostrar que aquest fitxer de codi es tambe utilitzat per les

plataformes que donen suport als sistemes de control de versions, com es el

cas de GitLab. Aixı, a la Figura 51 es mostra el que un usuari observa en

accedir al directori del modul en el repositori usat en el projecte.

Figura 50: Codi d’exemple d’un fitxer README. Font propia

131


Figura 51: Visualitzacio d’un fitxer README a GitLab. Font propia

132


5.4.6 Desenvolupament de proves

Tal i com s’ha vist al definir els components d’un modul d’Odoo a la Seccio

3.2.2, les proves per al seu codi es desenvolupen a partir del framework de

Python unittest, i s’emmagatzemen al directori de test de cada modul.

A l’hora de definir les classes Python que defineixen els tests d’un modul,

el framework d’Odoo n’ofereix diferents tipologies base, essent les principal-

ment usades:

• Transaction Case : Cada metode de prova definit en aquest tipus de

classe s’executa en la seva propia transaccio, de la qual es fa un rollback

despres de l’execucio del metode. Consequentment, cada metode de

prova s’executa amb el mateix estat inicial de la base de dades, i no hi

ha cap interferencia entre ells.

• Single Transaction Case : Tots els metodes de prova definits en

aquest tipus de classe s’executen en una unica transaccio, iniciada amb

el primer metode i de la qual es fa un rollback en acabar l’ultim. Con-

sequentment, cada metode de prova s’executa amb la base de dades

modificada pels metodes previs, excepte el primer que s’executa amb

l’estat inicial.

• Savepoint Case : Tots els metodes de prova definits en aquest tipus

de classe s’executen en una unica transaccio, pero cada un d’ells ho fa

en una propia subtransaccio de la qual es fa un rollback en acabar el

metode. En aquest tipus de classe la transaccio principal s’inicia amb

un metode anomenat setUpClass(), el qual genera les dades de prova

que s’utilitzaran al llarg de l’execucio dels metodes. D’aquesta forma,

cada test s’executara amb el mateix estat inicial de la base de dades, el

qual ja contindra les dades de prova creades en el setUpClass(), sense

necessitat de recrear-les cada vegada.

133


Les proves dels moduls d’Odoo estan orientades a ser executades en una

base de dades de prova, les quals estan compostes per les dades demo dels

moduls del sistema, i per a tal fi es necessari usar la interfıcie de lınia de

comandes. Els fitxers de prova s’executaran en el moment en que un modul

s’actualitza o s’instal·la, sempre i quan s’especifiqui en la comanda utilitzada

per a dur a terme l’operacio.

Com es pot observar en el seguent Llistat de codi, la primera part de

la comanda (des de l’inici fins a l’ultim odoo) executa una nova instancia

del servei d’Odoo definit al fitxer docker compose, del qual s’ha parlat en la

Seccio 5.1, i amb l’opcio –rm s’especifica que es vol que el servei s’aturi en

finalitzar la comanda. Per altra banda, la resta d’opcions son ja especıfiques

d’Odoo:

• -d: especifica la base de dades on executar la comanda (en l’exemple

seria la base de dades anomenada devel).

• -u: especifica el modul a actualitzar (la opcio -i seria l’equivalent per

a instal·lar-lo).

• –test-enable: habilita l’execucio dels tests del modul.

Llistat de codi 11: Comanda per a l’execucio dels tests d’un modul. Font

propia

# $MODULE es refereix al nom del modul

$ docker -compose run --rm odoo odoo -d devel -u $MODULE --test -enable

Com s’ha esmentat en la Seccio 3.2.2, Odoo utilitza la llibreria de Python

unittest per al desenvolupament dels fitxers de prova. Aquesta ofereix una

serie de metodes d’assert, anglicisme que es refereix a afirmar, que son la

clau per a dur a terme les comprovacions dels resultats obtinguts en un test.

La seva referencia pot trobar-se en la documentacio oficial [38].

134


Exemple: Savepoint Case

En aquest primer exemple es mostra un test del tipus Savepoint Case, cor-

responent al modul x sale. Aquest tipus de classe de prova es el mes usat en

moduls custom, ja que en els tests sol ser necessari inicialitzar varies dades

especıfiques que seran usades pels metodes.

Tot i que no hi ha un estandard especıfic definit en el desenvolupament

d’aquests fitxers, les bones practiques es centren en estructurar de forma

clara el seu contingut. En la Figura 52, corresponent a una part del metode

per al set up de les dades de la classe, es pot observar la seva divisio en tres

parts principals (de dalt a baix):

• Carrega dels models involucrats: en aquest primer bloc es carre-

guen els models que s’utilitzen al llarg de les proves en unes variables

concretes. A Odoo, per tal de referenciar un model i poder crear-ne no-

ves instancies en codi, cal carregar-lo a traves de l’objecte entorn env.

Qualsevol instancia del sistema te un objecte Environment disponible,

el qual no nomes permet carregar i accedir a altres models sino tambe

emmagatzemar dades contextuals [13].

• Dades base: en aquest segon bloc s’emmagatzemen en variables aque-

lles dades base que seran utilitzades en les proves. Les dades base fan

referencia a les dades demo afegides pels moduls del sistema. Tal i

com s’ha vist a la Seccio 3.2.2 aquestes dades son afegides a traves

de fitxers XML, cada un dels quals tenen un identificador que permet

referenciar-los i carregar-los fent us de l’Environment.

Es important destacar que per defecte Odoo emmagatzema els fitxers

XML afegits per un modul prefixant el seu identificador amb el nom

del modul, seguit per un ’.’. D’aquesta forma, si dos moduls afegeixen

el mateix identificador, no hi haura conflictes.

En el cas de l’exemple es poden observar dades base que, en la majoria

de casos, no son creades com a dades especıfiques en les proves sino

que poden aprofitar-se de les dades demo. Aquestes son, per exemple,

l’empresa del sistema i la seva unitat monetaria, l’usuari del sistema,

un client especıfic o un paıs.

135


• Dades especıfiques: en l’ultim bloc, el qual nomes es mostra par-

cialment en la figura, es creen les dades especıfiques per als diferents

metodes de prova. Aquestes dades es creen per als models que estan

principalment involucrats en el modul, ja sigui perque es tracta de nous

models, d’altres que se’ls afegeix alguna configuracio, o be se’ls modifica

alguna funcionalitat.

En el cas de l’exemple, degut a que les proves es centraran en modifi-

cacions afegides a l’hora de realitzar la compra de productes, es creen

categories de producte i productes especıfics per als tests. Tanmateix,

es pot observar com la logica per a la seva creacio es pot desacoblar

en altres metodes, com el create product de la Figura 53, que potencia

l’encapsulament i reutilitzacio del codi.

Figura 52: Codi parcial del metode setup. Font propia

Figura 53: Metode per a la creaciod’un producte en una classe de test.Font propia

Un cop inicialitzades les dades en el metode de set up, la resta de la classe

de test implementa els diversos metodes de prova. Cada un d’aquests esta

orientat a provar una funcionalitat concreta afegida o modificada pel modul,

ja sigui a nivell del flux d’execucio d’un proces o be dels models de dades

involucrats.

136


En l’exemple de la Figura 54, es mostra el codi d’un metode orientat a la

prova del flux d’execucio d’una venta. Com es pot observar, seguint les bones

practiques, s’especifica a l’inici del metode quin es el seu objectiu. Tanma-

teix, a la Figura es remarquen els metodes utilitzats per a la validacio dels

resultats, els quals s’executen en diversos punts de la prova. Concretament,

en l’exemple s’esta comprovant que el flux de venda amb les configuracions

afegides pel modul es desenvolupa correctament, i que la informacio es l’es-

perada en base a les dades que s’han definit en el set up. Per a tal fi, la

prova crea una venda per a un client amb un producte, li associa un metode

d’enviament, confirma la venda, processa l’enviament, i finalment en genera

la factura.

Figura 54: Codi d’exemple d’un metode de prova. Font propia

137


Per altra banda, l’exemple de la Figura 55 mostra el codi d’un metode

mes especıfic que l’anterior, orientat a la prova d’una funcionalitat afegida

pel modul. Concretament, la funcionalitat es basa en permetre a l’usuari

escollir una unica empresa d’enviament per a ser usada en tots els productes

afegits a la venda. Seguint una estructura com l’anterior, en aquest cas es

crea primerament una venda i s’hi afegeixen dos productes, cada un amb una

empresa d’enviament diferent. Seguidament, es comprova que a traves de la

funcionalitat afegida ambdos productes tenen associats la mateixa empresa

d’enviament. Finalment, es comprova que en revertir l’us de la funcionalitat

es torna al mateix estat inicial.


Amb els metodes definits, i executant l’actualitzacio del modul, Odoo

executara el fitxer de proves i en mostrara el resultat en els logs de la terminal.

Com es pot observar en la Figura 56 cada metode s’avalua i, en finalitzar,

es mostren el numero de tests executats, juntament amb el temps d’execucio

total. Si cap dels asserts de les proves dona un error, aquests s’han executat

satisfactoriament.

138


Figura 56: Resultat d’execucio dels tests d’un modul. Font propia

Exemple: Single Transaction Case / Transaction Case

En aquest exemple es mostra un metode d’una classe de prova basada en

Single Transaction Case. Aquesta tipologia, aixı com tambe la Transaction

Case, es usada principalment en moduls molt especıfics, els quals afegeixen

un volum de canvis reduıt. Consequentment, els fitxers de prova d’aquests

moduls poden estar compostos simplement d’un unic metode, o de varis molt

reduıts.

En l’exemple de la Figura 57, es mostra un metode orientat a provar la

funcionalitat principal afegida per un dels moduls del projecte. Concreta-

ment, aquest modul fa que quan un contacte 3 del sistema s’inhabiliti, els

seus descendents tambe ho facin. Aixı, primerament es crea un contacte pare

i un descendent, despres s’inhabilita el pare, i finalment es comprova que el

fill ha estat automaticament inhabilitat.


3A Odoo un contacte representa una empresa o individu, entre els quals hi pot haveruna relacio jerarquica. S’utilitzen principalment per gestionar clients i proveıdors.

139

5.5. DOCUMENTACIO I FORMACIO

5.5 Documentacio i formacio

En la identificacio dels factors crıtics d’exit i riscos del projecte (Seccio 2)

s’han destacat com a factors clau la gestio efectiva del canvi i el desenvo-

lupament d’un programa de formacio adequat, els quals es controlen prin-

cipalment gracies a la realitzacio d’una documentacio orientada a l’usuari,

juntament amb un material formatiu.

A mesura que es realitza l’analisi dels moduls, una de les tasques essencials

es comprendre la seva funcionalitat, les dades que afegeix, i com interactua

amb el sistema. A partir de la seva migracio a la nova versio, l’us funcional del

modul es documenta principalment en quatre nivells diferents en el projecte,

els quals es descriuen a continuacio.

5.5.1 Documentacio d’usuari

Des d’una perspectiva de negoci, una documentacio essencial a desenvolupar,

especialment de cara a la formacio dels empleats de l’empresa client, es la

documentacio d’usuari. Aquesta compren els diferents processos involucrats

en les arees de l’empresa a un nivell funcional, i especialment orientats a la

seva realitzacio en el sistema Odoo.

La documentacio d’usuari es recull en un document unic que esdeve un

Standard Operating Procedure (SOP), una guia pas a pas purament orientada

als treballadors per al desenvolupament de les tasques clau del seu dia a dia

en el sistema. A partir de la identificacio dels processos principals en la Seccio

5.2, aquests s’utilitzen per definir les seccions del document.

En el desenvolupament de la documentacio d’usuari, es essencial involu-

crar diversos elements en cada una de les seccions:

• Contextualitzacio del proces en el negoci, aixı com en el sistema Odoo.

Aquesta contextualitzacio es essencial ja que la documentacio ha de

servir per a potencials noves incorporacions en l’empresa client, les

quals no nomes poden requerir coneixement del sistema sino tambe del

negoci.

• Instruccions per al desenvolupament de les tasques, no nomes descrivint

el proces sino tambe definint les dades mes importants del proces.

140


• Suport visual, afegint captures de la interfıcie del sistema per tal de

facilitar a l’usuari la comprensio de les tasques.

• Referencies a altres seccions, molts processos interactuen entre sı, pel

que es important identificar els casos en els que calgui referenciar in-

formacio descrita a una altra seccio, tanmateix per evitar duplicacio de

contingut.

A l’exemple de la Figura 58 es pot observar part d’una de les seccions del

SOP, relativa al proces de Supply Chain.

Figura 58: Exemple seccio del Standard Operating Procedure. Font propia

141


5.5.2 Formacio d’usuaris

Degut a que el projecte es realitza de forma remota, les tasques de formacio

a usuaris es realitzen principalment a traves d’elements audiovisuals. Per als

diferents processos clau de negoci, es dissenyen i graven uns vıdeos en un

mateix format (vegeu les Figures 59 i 60) dedicats a dos objectius principals:

• Contextualitzacio del proces: Idem de la documentacio d’usuari,

la formacio no esta orientada unicament als actuals empleats, sino que

tambe ha de poder ser util per a potencials noves incorporacions a

l’empresa. Tanmateix, per tal de facilitar la comprensio del material

formatiu, es essencial contextualitzar el proces que s’esta mostrant dins

de l’ambit de negoci del client. Aixı, un dels vıdeos formatius es centra

en presentar els conceptes clau del proces, les tasques implicades en

el seu flux d’execucio, i les seves possibles variants, utilitzant com a

suport una presentacio de diapositives.

Figura 59: Captura d’un vıdeo formatiu orientat a la contextualitzacio d’unproces. Font propia

142


• Demostracio del proces al nou sistema: La part mes important de

la formacio es basa en mostrar l’execucio del proces, aixı com les seves

principals variants, en la nova versio d’Odoo que els usuaris utilitzaran

despres de la migracio. Per a tal fi, la resta de vıdeos formatius es

centren en mostrar de forma interactiva les tasques que els usuaris

han de desenvolupar en les diverses variants del proces. Cal remarcar

que, aquest material, es realitza a traves del servidor de migracio del

projecte, un cop ja s’ha desenvolupat el proces principal de migracio

dels moduls.

Figura 60: Captura d’un vıdeo formatiu orientat a la demostracio d’un procesen el sistema. Font propia

El desenvolupament d’aquest material no serveix unicament com a element

formatiu a llarg termini, sino que tambe esdevenen una peca clau per a

comencar a introduir als empleats al nou sistema, especialment de cara a la

fase de validacio que els propis usuaris han de desenvolupar.

143

5.6. PROCES DE VALIDACIO

5.6 Proces de Validacio

El proces de validacio te com a objectiu assegurar que el resultat de la mi-

gracio del sistema compleix amb els objectius del projecte, principalment en

referencia a:

• Assegurar que els mateixos processos que es desenvolupen en la versio

actual segueixen operatius en la nova versio.

• Les dades presents en la versio actual segueixen accessibles i compati-

bles amb la nova versio.

Gracies a la metodologia emprada per aquesta fase del proces, on la validacio

es desenvolupa en quatre subfases iteratives amb la implicacio directa dels

usuaris clau, els potencials errors resultants de la migracio es minimitzen de

forma significativa.

5.6.1 Preparacio de les sessions de validacio

El proces de validacio es desenvolupat ıntegrament pels usuaris clau del cli-

ent, especıficament designats per cada un dels processos identificats en la

operativa de l’empresa. Per tal de facilitar el seu desenvolupament, pero,

es preparen uns documents de validacio com a suport per aquests usuaris.

Aquests documents permeten:

• Especificar quin proces s’esta validant i qui el desenvolupa.

• Especificar el resultat de la validacio.

• Identificar les dades emprades en el proces.

• Mantenir una tracabilitat del desenvolupament de les validacions, aixı

com dels processos que s’han cobert en aquestes.

Aquests documents base, desenvolupats per cada un dels processos definits,

segueix la seguent estructura:

• Scenario #: Codi identificador de l’escenari de prova. Aquest codi

esta compost del codi del proces, format per l’identificador del projecte

(OMS) i el numero del proces, seguit pel numero de l’escenari de prova.

144


• Description: Breu descripcio de l’escenari de prova.

• Data Used: Especificacio de les dades emprades per al desenvolupa-

ment de la prova.

• Tested by: Nom de l’usuari clau que ha desenvolupat la prova.

• Expected Outcome: Breu descripcio del/s resultat/s esperat/s.

• Documents Created: Identificador/s dels documents i/o entitats del

sistema resultants de la prova.

• Result (PASS/FAIL): Resultat del proces de validacio, essent PASS

un resultat sense cap error, o FAIL un resultat amb errors.

Figura 61: Exemple document base de validacio. Font propia

145


5.6.2 Gestio dels resultats

Un dels recursos software claus en el proces de validacio es l’us de l’eina Jira,

la qual permet gestionar els errors identificats pels usuaris i seguir-ne la seva

resolucio. En aquesta aplicacio es crea un projecte especıfic per aquesta fase,

en el qual els mateixos usuaris clau de l’empresa client poden crear noves

incidencies que seran resoltes per l’equip de desenvolupament.

En els seguents exemples es poden observar dues mostres d’incidencies

obertes en el proces de validacio:

• En el primer exemple de la Figura 62, es pot observar a la part superior

esquerra com cada incidencia esta associada el seu proces, en aquest cas

el de Sales. Tanmateix, en el mateix tıtol d’aquesta es pot especificar

breument l’error trobat, aixı com el codi de l’escenari de prova en que

s’ha produıt.

Per altra banda, cada incidencia pot tenir un estat en el seu cicle de

vida, tal i com s’observa a la part superior dreta, essent en l’exemple

l’estat de To test. Aixo permet indicar si aquesta esta resolta i llesta

per a que l’usuari pugui provar-ne la solucio.

• En el cas del segon exemple de la Figura 63, es poden veure les mateixes

caracterıstiques, pero en aquest cas es pot observar com l’estat de la

incidencia esta a Closed, que indica que ha estat resolta i verificada per

l’usuari. Tanmateix, en aquest exemple es mostra tambe una de les

comoditats que aporta Jira en aquesta tasca, i es permetre als usuaris

afegir fitxers a la incidencia que aportin informacio sobre el problema

que volen reportar.

146


Figura 62: Exemple 1 d’incidencia registrada a Jira. Font propia

Figura 63: Exemple 2 d’incidencia registrada a Jira. Font propia

147

Capıtol 6

Conclusions

6.1 Assoliment dels objectius del projecte

Tot i que en la finalitzacio del present treball el projecte encara esta en exe-

cucio, consequentment afectant el desenvolupament total dels objectius inici-

alment plantejats, en aquesta seccio s’avalua breument el grau d’assoliment

de cada un d’ells en tres nivells: NO ASSOLIT, ASSOLIT EN POTENCIA,

o ASSOLIT.

Obj 1: Migrar el sistema Odoo de la versio 10.0 a la

13.0.

Obj 1.1: Analitzar el funcionament actual dels moduls.

ASSOLIT - L’analisi del funcionament dels moduls s’ha desenvolupat en la

fase especıfica d’analisi dels moduls, al llarg del proces de migracio d’aquests,

i s’ha materialitzat a traves de la documentacio tecnica juntament amb la

orientada als usuaris.

148

6.1. ASSOLIMENT DELS OBJECTIUS DEL PROJECTE

Obj 1.2: Implementar les modificacions requerides per a la migra-

cio.

ASSOLIT EN POTENCIA - Les modificacions requerides per a la migracio

dels moduls s’ha desenvolupat al llarg del proces de migracio d’aquests, es-

pecialment pel que fa al codi, per assegurar un entorn en versio 13 funcional.

Certament, pero, petits canvis poden requerir-se fruit del proces de validacio.

Obj 1.3: Dissenyar i aplicar les proves que assegurin un correcte

funcionament del sistema.

ASSOLIT EN POTENCIA - A nivell de proves especıfiques dels moduls

del sistema, s’han desenvolupat en el proces de migracio fitxers de test per

assegurar que qualsevol canvi no altera el funcionament principal de cada un

d’ells. Tot i aixo, fruit dels potencials canvis en el proces de validacio, noves

proves poden ser requerides en casos puntuals.

Obj 1.4: Garantir el compliment dels requisits del client en la

posada en marxa del sistema final.

NO ASSOLIT - Degut a que la posada en marxa no s’ha produıt en la

finalitzacio del treball, aquest objectiu no pot considerar-se assolit. Tot i

aixo, degut a que els requisits han estat presents al llarg del desenvolupament

de totes les tasques ja executades, s’espera que en el moment de dur a terme

la fase de desplegament aquest es vegi assolit sense problemes.

Obj 2: Identificar oportunitats de millores tecniques i

de proces.

Obj 2.1: Identificar potencials millores en la logica actual del sis-

tema.

ASSOLIT - Al llarg del proces de migracio dels moduls, aixı com tambe a

partir de l’analisi inicial d’aquests i els seus processos, s’han pogut identificar

multiples millores en la seva logica.

149

6.1. ASSOLIMENT DELS OBJECTIUS DEL PROJECTE

Obj 2.2: Identificar potencials millores resultants de les noves fun-

cionalitats afegides en la migracio.

ASSOLIT EN POTENCIA - Aquest objectiu s’ha assolit principalment al

llarg del proces de migracio, en el que la logica original es veu realitzada en

el context del nou sistema, i s’ha materialitzat en la documentacio d’usuari i

material formatiu. En aquests, s’ha pogut mostrar com noves funcionalitats

afegides per la versio 13 d’Odoo es poden aplicar per a optimitzar i facilitar

l’execucio de varis processos de l’empresa. Certament, pero, al llarg del

proces de validacio poden apareixer noves oportunitats que el client tingui

interes en aplicar.

Obj 2.3: Capturar i gestionar les millores identificades per a la seva

avaluacio i implementacio.

ASSOLIT EN POTENCIA - Les potencials millores identificades en els punts

anteriors s’han gestionat seguint l’establert en la metodologia: partint de la

seva avaluacio, s’ha decidit en cada cas si s’absorbia la carrega de treball per

a implementar-la en el proces de migracio, o si es capturava en un document

per a ser considerada en un projecte posterior a la migracio. Tot i aixo, com

s’ha esmentat anteriorment, en el proces de validacio poden apareixer noves

oportunitats de millora a gestionar.

Obj 3: Gestionar adequadament el risc del projecte.

ASSOLIT - En la Seccio 2 s’ha desenvolupat un analisi no nomes dels princi-

pals factors crıtics d’exit del projecte, sino tambe l’avaluacio dels seus riscos

associats en el seu context. Tanmateix, per cada un dels riscos, s’han especi-

ficat accions a desenvolupar dins la propia planificacio per tal de controlar-los

o minimitzar-ne el seu impacte. D’aquesta forma, els diferents sub-objectius

d’aquest punt poden considerar-se assolits.

150

6.2. CONTINUACIO DEL PROJECTE

6.2 Continuacio del projecte

En la finalitzacio del conveni de practiques establert per a la realitzacio del

present treball, el projecte es troba concretament en la primera iteracio del

proces de validacio amb els usuaris clau de l’empresa client. Per aquest motiu,

pel que a la continuacio del projecte es refereix, es consideren les seguents

etapes per a la seva total realitzacio:

1. Finalitzacio del proces de validacio: Seguint les directrius defini-

des en la Seccio 5.6, cal realitzar la totalitat de les quatre iteracions de

validacio del sistema migrat, desenvolupant corresponentment les solu-

cions requerides davant dels potencials problemes que s’hi identifiquin.

El resultat d’aquest proces ha d’assegurar que els processos de negoci

de l’empresa client es poden dur a terme en el nou sistema, mantenint la

integritat de les dades, per tal de complir amb els objectius del projecte.

2. Go-Live: Havent desenvolupat les validacions finals del sistema en

el servidor de migracio, cal dur a terme la migracio en el servidor de

produccio, en el qual resideix el sistema final utilitzat per l’empresa.

Sera important en aquesta fase considerar el temps requerit per a dur

a terme la migracio, en el qual el sistema no podra estar operatiu.

3. Suport Post-Desplegament: Tant punt s’hagi realitzat el desplega-

ment oficial de la migracio en l’entorn de produccio, es essencial i crıtic

oferir un suport directe al llarg de les primeres setmanes posteriors, tal

i com s’ha definit en la planificacio.

4. Projecte de millores: A partir de les millores identificades en el

proces de migracio que requereixen d’un desenvolupament amb major

complexitat, les quals s’han anat registrant al llarg d’aquest, es podran

implementar ja en el sistema oficialment migrat en un projecte poste-

rior. D’aquesta forma, aquests canvis identificats per a mantenir-ne la

seva tracabilitat poden considerar-se ja en un nou projecte per a evitar

la seva interferencia en l’abast i planificacio establerts pel present.

151

6.3. COMPETENCIES TECNIQUES

6.3 Competencies tecniques

En els seguents apartats es justifica resumidament el desenvolupament de les

competencies tecniques corresponents a l’especialitat del Grau en Enginyeria

Informatica en la que s’emmarca el present treball, de Sistemes d’Informacio,

a partir de la feina realitzada en el projecte.

CSI2.1: Demostrar comprensio i aplicar els principis i les tecniques

de gestio de qualitat i d’innovacio tecnologica a les organitzacions.

El desenvolupament del projecte, sobretot a nivell de la metodologia empra-

da, ha estat basat no nomes en assolir-ne la major qualitat sino tambe en

gestionar i minimitzar els principals riscos d’aquesta tipologia de projecte.

Dur a terme processos iteratius i incrementals, els quals permeten validar

els resultats i aportar valor per al client de forma mes frequent, son principis

tractats en varies assignatures de l’especialitat de Sistemes d’Informacio, i

que poden aplicar-se en molts mes ambits mes enlla del presentat en aquest

projecte. Tanmateix, tal i com s’ha identificat en els principals riscos del

projecte, la innovacio tecnologica a les organitzacions s’ha de gestionar tambe

des del punt de vista huma, en referencia als usuaris del sistema, pel que son

essencials les tasques de documentacio i formacio orientades a aquest aspecte.

Finalment cal considerar tambe els principis especıfics del sistema Odoo,

en referencia a les practiques comunes en el desenvolupament dels moduls

en base a l’estructura marcada pel propi framework, aixı com en les bones

practiques definides per la comunitat de la Odoo Community Association.

Aquestes han estat aplicades no nomes en la migracio dels moduls, sino

tambe en la migracio de la base de dades gracies al projecte OpenUpgrade.

152


CSI2.2: Concebre, desplegar, organitzar i gestionar sistemes in-

formatics, en contextos empresarials o institucionals, per tal de

millorar-ne els processos de negoci; responsabilitzar-se’n i liderar-

ne la posada en marxa i la millora contınua; valorar el seu impacte

economic i social.

La migracio del sistema desenvolupada en el present projecte te un impacte

directe en la millora dels processos empresarials del client:

• Operar amb una versio actualitzada del sistema permet aprofitar totes

les novetats i millores de rendiment ofertes per la nova versio, agilitzant

l’operativa diaria dels processos en l’ERP.

• A partir del proces de migracio, ja sigui amb la identificacio de punts a

millorar o noves funcionalitats a aprofitar, s’aconsegueix no nomes op-

timitzar processos actuals sino tambe millorar-los, aportant nous avan-

tatges competitius per a l’empresa.

Com s’ha vist al llarg del treball, el proces de migracio requereix analitzar

l’operativa actual del client, tant a nivell de negoci com tecnic, per tal d’a-

daptar la logica requerida en la nova versio. Tanmateix, dur a terme aquest

proces requereix del desplegament d’una infraestructura especıfica, definida

en la Seccio 5.1, i posteriorment caldra liderar la posada en marxa final en

el servidor de produccio.

Per altra banda, seguint les directrius de la gestio de projectes, s’ha valo-

rat l’impacte ambiental, economic i social del projecte, justificat en l’informe

de sostenibilitat.

153


CSI2.5: Demostrar coneixement i capacitat d’aplicacio dels siste-

mes d’informacio empresarial (ERP, CRM, SCM, etc.).

Aquesta competencia esdeve la mes inherent al llarg del treball, ja que l’ele-

ment central del projecte ha estat el sistema ERP Odoo. De fet, tot i les di-

verses nomenclatures que designen els diferents tipus de sistemes informatics

en l’ambit empresarial, cal tenir present que l’Odoo encapsula multiples apli-

cacions orientades a diverses arees de l’operativa de l’empresa. Aixı, no nomes

s’ha treballat amb un sistema ERP, sino que tambe s’ha tractat amb moduls

orientats a CRM o SCM, precisament usats en l’empresa involucrada en el

projecte.

Finalment, cal destacar que per a dur a terme el desenvolupament del

projecte ha estat essencial formar-se tant a nivell tecnic com funcional en el

sistema Odoo, aixı com en les seves aplicacions en un entorn empresarial.

CSI3.1: Demostrar comprensio dels principis de l’avaluacio de riscs

i aplicar-los correctament en l’elaboracio i l’execucio de plans d’ac-

tuacio.

Un dels objectius del treball era dedicar una part del seu desenvolupament a

l’avaluacio dels principals riscos associats a aquesta tipologia de projecte, per

tal d’identificar-los a priori i poder definir accions en la planificacio per tal de

minimitzar-los. Aquesta tasca s’ha documentat en la Seccio 2, identificant

els riscos en relacio als factors crıtics d’exit aplicables al projecte.

CSI4.1: Participar activament en l’especificacio dels sistemes d’in-

formacio i de comunicacio.

Tot i que aquesta competencia no s’ha tractat en profunditat, l’especificacio

dels moduls involucrats en el projecte s’ha pogut veure materialitzada en la

seva documentacio tecnica, aixı com en els processos en la orientada a la

formacio d’usuaris. Aquesta especificacio esta adaptada als diversos nivells

seguint el format requerit en cada una: per a la documentacio tecnica, s’ha

seguit el model comunament utilitzat pels moduls de la Odoo Community

Association, mentre que per la documentacio d’usuari s’ha seguit un esquema

orientat a un Standard Operating Procedure.

154


CSI3.3: Avaluar ofertes tecnologiques per al desenvolupament de

sistemes d’informacio i gestio.

Com s’esmenta en la definicio de la metodologia i rigor del treball, pels moduls

de tercers que formen part de la versio 10 del sistema, ha estat necessari en

algun cas avaluar alternatives a moduls que no estaven disponibles per a la

nova versio. Tanmateix, en altres casos, s’ha optat per a substituir moduls

privatius per moduls de la OCA, els quals tenen un suport constant per

part de tota la comunitat i potencien l’estandarditzacio i qualitat de les

caracterıstiques ofertes pels sistemes Odoo.

CSI3.4: Desenvolupar solucions de negoci mitjancant la implanta-

cio i la integracio de hardware i software.

Un projecte de migracio d’un sistema ERP esdeve, sobretot en casos com

el del present projecte, practicament una implementacio. Aquesta comple-

xitat es resultat de les diferencies tecniques entre les versions implicades,

juntament amb l’alta presencia de codi especıfic del client. D’aquesta forma,

el projecte s’ha basat en desenvolupar a nivell software tots els canvis ne-

cessaris per a dur a terme la migracio implementant i/o modificant el codi

dels moduls, aixı com dels corresponents scripts de migracio per a la base

de dades. Paral·lelament, tot aixo s’ha hagut de realitzar amb el suport

d’una infraestructura especıficament definida pel proces i amb els recursos

hardware involucrats en el projecte.

CSI3.5: Proposar i coordinar canvis per a millorar l’explotacio del

sistema i de les aplicacions.

Un dels objectius del projecte s’ha establert en la identificacio de punt de

millora, no nomes a nivell tecnic, sino tambe en els processos empresarials i

la seva execucio en el sistema. Tot i aixo, cal tenir present que es essencial

mantenir clarament definit l’abast del projecte, pel que l’objectiu no s’ha

establert unicament en identificar o proposar aquests canvis, sino tambe en

capturar-los, avaluar-ne la seva implementacio en el proces de migracio, i

gestionar la seva potencial consideracio en un projecte de continuacio futur.

155


CSI1: Demostrar comprensio i aplicar els principis i les practiques

de les organitzacions, de manera que puguin exercir d’enllac entre

les comunitats tecnica i de gestio d’una organitzacio, i participar

activament en la formacio dels usuaris.

En la identificacio dels principals factors crıtics d’exit del projecte, s’ha pogut

observar en les diferents mesures de control dels riscos que algunes de les mes

importants son el coneixement de negoci i la formacio d’usuaris.

Per una banda, es crıtic que dins de l’equip del projecte hi hagi una

bona alineacio entre les capacitats tecniques i el coneixement de negoci, amb

l’objectiu de minimitzar les desviacions en la captura dels requisits que els

diferents processos empresarials han de poder complir en el sistema. Per

aquest motiu, ha estat essencial dur a terme l’etapa d’analisi de processos

inicial involucrant en gran mesura el principals usuaris clau del client, aixı

com tambe a nivell personal la formacio especıfica en Odoo.

Per altra banda, el desenvolupament de material formatiu ha acabat sent

una tasca amb pes important dins del projecte, i juntament amb la docu-

mentacio permeten gestionar de forma efectiva el canvi que els usuaris del

sistema han d’afrontar amb el nou sistema actualitzat.

CSI4.2: Participar activament en el disseny, la implementacio i el

manteniment dels sistemes d’informacio i de comunicacio.

En la lınia del que s’ha comentat per les competencies CSI2.2 i CSI3.4, el pro-

jecte ha implicat tasques relacionades amb etapes d’analisi i d’implementacio

en el sistema, aixı com dels processos empresarials que s’hi desenvolupen, per

a posteriorment implementar els canvis requerits per assegurar-ne la compa-

tibilitat en la nova versio actualitzada. Finalment, en una etapa posterior

al desplegament final, caldra oferir un suport per assegurar-ne el correcte

manteniment davant potencials incidencies derivades del Go-Live.

156

6.4. CONCLUSIONS PERSONALS

6.4 Conclusions Personals

La realitzacio del present Treball de Final de Grau ha estat una experiencia

intensa i molt enriquidora, la qual ha permes no nomes posar en practica tots

els coneixements adquirits al llarg de l’etapa universitaria, sino tambe iniciar

el camı professional, ja que en finalitzar el conveni de cooperacio educativa

l’autor ha pogut incorporar-se a l’equip de ForgeFlow oficialment.

A nivell formatiu, el desenvolupament del projecte ha permes aplicar

molts dels coneixements adquirits en les diferents assignatures del grau en

Enginyeria Informatica. El perfil requerit per dur a terme projectes d’aquest

tipus ha de disposar no nomes de coneixements tecnics, els quals s’aprenen

en assignatures com Bases de dades o Programacio, sino tambe de l’ambit

organitzacional com els adquirits a Negoci Electronic o Sistemes d’Informacio

a les Organitzacions. Tot i aixo, estar involucrat en un cas real ha permes

veure i entendre de primera ma el funcionament de multiples arees d’una

empresa, i sobretot com un sistema informatic dona suport en cada una

d’elles.

A nivell de la realitzacio del Treball de Fi de Grau el seu desenvolupament

ha estat un repte, especialment en l’ambit enfocat a la gestio i planificacio,

degut a les caracterıstiques del projecte. Tanmateix, es important destacar

que aquesta tipologia de Treball no es molt comuna en el repositori de docu-

ments academics de la Universitat, pel que s’espera que aquest pugui ser un

exemple per a futurs estudiants en el marc de la seva especialitat.

Sense cap dubte l’experiencia resultant d’aquest projecte ha estat un gran

punt d’inflexio en tots els sentits. Es essencial aprofitar oportunitats com

les que la Universitat posa a disposicio dels estudiants amb els convenis de

cooperacio educativa, pel que personalment es voldria recomanar a tots els

lectors estudiants dur a terme, sigui en el format que sigui, almenys una

d’aquestes etapes.

Per ultim, pero de ben segur no menys important, agrair de tot cor a totes

les persones involucrades en el projecte, especialment al ponent Joan Antoni

Pastor, al director Jordi Ballester Alomar, i a tota la famılia de ForgeFlow.

157

Referencies

[1] ForgeFlow S.L. About Us — ForgeFlow. 2020. url: https://www.

forgeflow.com/aboutus (cons. 26-09-2020).

[2] Odoo S.A. About Us — Odoo. 2020. url: https://www.odoo.com/

es_ES/page/about-us (cons. 26-09-2020).

[3] Odoo S.A. Elige tus aplicaciones. 2020. url: https://www.odoo.com/

es_ES/trial (cons. 27-09-2020).

[4] Varis Autors. Odoo. 2020. url: https://es.wikipedia.org/wiki/

Odoo (cons. 26-09-2020).

[5] Odoo S.A. Odoo Apps. 2020. url: https://apps.odoo.com/apps/

modules/browse?order=Relevance (cons. 27-09-2020).

[6] Odoo Community Association. About us — Odoo Community Associ-

ation. 2020. url: https://odoo-community.org/page/About (cons.

27-09-2020).

[7] Odoo S.A. Compare Editions. 2020. url: https://www.odoo.com/es_

ES/page/editions (cons. 26-09-2020).

[8] Odoo S.A. Versiones con soporte. 2020. url: https://www.odoo.com/

documentation/user/13.0/es/support/supported_versions.html

(cons. 26-09-2020).

[9] Panorama Consulting. The 2020 ERP Report. Panorama Consulting

Group, 2020. url: https://cdn2.hubspot.net/hubfs/4439340/

Panorama-Consulting-Group-The-2020-ERP-Report.pdf.

[10] Digital.ai. 14th annual State Of Agile Report. Digital.ai Software, Inc,

2020. url: https://stateofagile.com/#ufh-i-615706098-14th-

annual-state-of-agile-report/7027494 (cons. 27-09-2020).

158

https://www.forgeflow.com/aboutus

https://www.forgeflow.com/aboutus

https://www.odoo.com/es_ES/page/about-us

https://www.odoo.com/es_ES/page/about-us

https://www.odoo.com/es_ES/trial

https://www.odoo.com/es_ES/trial

https://es.wikipedia.org/wiki/Odoo

https://es.wikipedia.org/wiki/Odoo

https://apps.odoo.com/apps/modules/browse?order=Relevance

https://apps.odoo.com/apps/modules/browse?order=Relevance

https://odoo-community.org/page/About

https://www.odoo.com/es_ES/page/editions

https://www.odoo.com/es_ES/page/editions

https://www.odoo.com/documentation/user/13.0/es/support/supported_versions.html

https://www.odoo.com/documentation/user/13.0/es/support/supported_versions.html

https://cdn2.hubspot.net/hubfs/4439340/Panorama-Consulting-Group-The-2020-ERP-Report.pdf

https://cdn2.hubspot.net/hubfs/4439340/Panorama-Consulting-Group-The-2020-ERP-Report.pdf

https://stateofagile.com/#ufh-i-615706098-14th-annual-state-of-agile-report/7027494

https://stateofagile.com/#ufh-i-615706098-14th-annual-state-of-agile-report/7027494

REFERENCIES

[11] Atlassian. Jira Software. 2021. url: https://www.atlassian.com/

es/software/jira (cons. 03-03-2021).

[12] OVHcloud. Servidores privados virtuales (VPS). 2021. url: https:

//www.ovhcloud.com/es-es/vps (cons. 10-11-2020).

[13] Odoo S.A. Developer Documentation. 2020. url: https://www.odoo.

com/documentation/13.0 (cons. 30-09-2020).

[14] Odoo S.A. Odoo Learn. 2020. url: https://www.odoo.com/es_ES/

slides (cons. 30-09-2020).

[15] Alejandro Aradas. Cuestiones Laborales — Como calcular la jornada

de trabajo. 2020. url: https://www.cuestioneslaborales.es/como-

calcular-la-jornada-de-trabajo/#:~:text=En%5C%20segundo%

5C%20lugar%5C%2C%5C%20hay%5C%20que,48%5C%20domingos%5C%

20y%5C%2014%5C%20festivos (cons. 10-10-2020).

[16] Inc. Glassdor. Sueldo: IT Project Manager. 2020. url: https://www.

glassdoor.es/Sueldos/it-project-manager-sueldo-SRCH_KO0,

18.htm (cons. 08-10-2020).

[17] Inc. Glassdor. Sueldo: Technical Consultant. 2020. url: https://www.

glassdoor . es / Sueldos / technical - consultant - sueldo - SRCH _

KO0,20.htm (cons. 08-10-2020).

[18] Google LLC. Planes de Precios. 2020. url: https : / / workspace .

google.es/intl/es/pricing.html (cons. 08-10-2020).

[19] Odoo S.A. Odoo 13 — Release Notes. 2019. url: https://www.odoo.

com/es_ES/odoo-13-release-notes#part_39 (cons. 11-10-2020).

[20] Jose Esteves i Joan Pastor. “Proyectos ERP exitosos como base de

ventajas competitivas”. A: Revista de Empresa Nº 9 (2004), pag. 32 -

43.

[21] The Standish Group. CHAOS Manifesto 2013. The Standish Group

International, Inc, 2013.

[22] The Standish Group. CHAOS Report 2015. The Standish Group Inter-

national, Inc, 2015. url: https://www.standishgroup.com/sample_

research_files/CHAOSReport2015-Final.pdf.

159

https://www.atlassian.com/es/software/jira

https://www.atlassian.com/es/software/jira

https://www.ovhcloud.com/es-es/vps

https://www.ovhcloud.com/es-es/vps

https://www.odoo.com/documentation/13.0

https://www.odoo.com/documentation/13.0

https://www.odoo.com/es_ES/slides

https://www.odoo.com/es_ES/slides

https://www.cuestioneslaborales.es/como-calcular-la-jornada-de-trabajo/#:~:text=En%5C%20segundo%5C%20lugar%5C%2C%5C%20hay%5C%20que,48%5C%20domingos%5C%20y%5C%2014%5C%20festivos




https://www.glassdoor.es/Sueldos/it-project-manager-sueldo-SRCH_KO0,18.htm



https://www.glassdoor.es/Sueldos/technical-consultant-sueldo-SRCH_KO0,20.htm



https://workspace.google.es/intl/es/pricing.html

https://workspace.google.es/intl/es/pricing.html

https://www.odoo.com/es_ES/odoo-13-release-notes#part_39

https://www.odoo.com/es_ES/odoo-13-release-notes#part_39

https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf

https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf

REFERENCIES

[23] Luis Felipe Mileo. Odoo Developer Training: From Basis to First Mo-

dule. 2020. url: https://kmee.github.io/oca-days-2020-odoo-

developer/latex/training.pdf.

[24] Odoo Community Association. FAQ — What you need to know about

the OCA. 2020. url: https://odoo-community.org/page/faq (cons.

07-11-2020).

[25] Odoo S.A. Keynote — Vision & Strategy. 2020. url: https://www.

youtube.com/watch?v=26IOIsRupIM#t=23m24s.

[26] Daniel Reis. Odoo 12 Development Essentials. 4a ed. Birmingham UK:

Packt Publishing, 2018.

[27] Odoo S.A. Odoo Guidelines. 2020. url: https://www.odoo.com/

documentation/13.0/reference/guidelines.html (cons. 05-12-2020).

[28] Odoo S.A. Legal — Licenses. 2020. url: https://www.odoo.com/

documentation/user/13.0/es/legal/licenses/licenses.html

(cons. 28-11-2020).

[29] Varis Autors. GNU Lesser General Public License. 2020. url: https:

//en.wikipedia.org/wiki/GNU_Lesser_General_Public_License

(cons. 28-11-2020).

[30] Git Community. Git — Acerca del Control de Versiones. 2020. url:

https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-

de-Versiones-Acerca-del-Control-de-Versiones (cons. 20-12-2020).

[31] Git Community. Git — About. 2020. url: https://git-scm.com/

about (cons. 15-12-2020).

[32] Docker Inc. What is a Container? 2020. url: https://www.docker.

com/resources/what-container (cons. 27-12-2020).

[33] Docker Inc. Overview of Docker Compose. 2020. url: https://docs.

docker.com/compose (cons. 27-12-2020).

[34] The OpenUpgrade Team. OpenUpgrade — Documentation. 2020. url:

https://doc.therp.nl/openupgrade/ (cons. 05-12-2020).

160

https://kmee.github.io/oca-days-2020-odoo-developer/latex/training.pdf

https://kmee.github.io/oca-days-2020-odoo-developer/latex/training.pdf

https://odoo-community.org/page/faq

https://www.youtube.com/watch?v=26IOIsRupIM#t=23m24s

https://www.youtube.com/watch?v=26IOIsRupIM#t=23m24s

https://www.odoo.com/documentation/13.0/reference/guidelines.html

https://www.odoo.com/documentation/13.0/reference/guidelines.html

https://www.odoo.com/documentation/user/13.0/es/legal/licenses/licenses.html

https://www.odoo.com/documentation/user/13.0/es/legal/licenses/licenses.html

https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License

https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License

https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Acerca-del-Control-de-Versiones

https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Acerca-del-Control-de-Versiones

https://git-scm.com/about

https://git-scm.com/about

https://www.docker.com/resources/what-container

https://www.docker.com/resources/what-container

https://docs.docker.com/compose

https://docs.docker.com/compose

https://doc.therp.nl/openupgrade/

REFERENCIES

[35] Odoo Community Association. Migration to version 11.0. 2019. url:

https://github.com/OCA/maintainer-tools/wiki/Migration-to-

version-11.0 (cons. 03-03-2021).



version-12.0 (cons. 03-03-2021).



version-13.0 (cons. 03-03-2021).

[38] The Python Software Foundation. unittest — Unit testing framework.

2021. url: https://docs.python.org/3/library/unittest.html

(cons. 13-03-2021).

161

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-11.0






https://docs.python.org/3/library/unittest.html

Annex

162

Apendix A

Planificacio i Gestio Economica

Inicial

A.1 Planificacio Inicial

A.1.1 Consideracions generals

Per tal d’introduir les principals tasques a realitzar en el projecte, es essencial

definir unes marques temporals claus que guien la seva planificacio:

• Inici del conveni:

22 de setembre de 2020

• Finalitzacio del conveni:

9 de marc de 2021

• Equip de treball:

7 persones

• Finalitzacio del treball:


• Data lectura del treball:


• Duracio temporal estimada

del projecte:

6 mesos

Degut a que els membres de l’equip no dedicaran la totalitat de la seva

jornada unicament el projecte, la dedicacio diaria de l’equip anira variant

en funcio de les necessitats, sempre amb l’objectiu de complir les dates lımit

establertes amb el client.

163

A.1. PLANIFICACIO INICIAL

A.1.2 Descripcio de les tasques

F1 — Gestio del treball

La gestio del projecte, des del punt de vista del Treball de Fi de Grau derivat,

s’estendra al llarg de tot el seu temps de vida.

T1.1 - Contextualitzacio i abast del projecte: Documentacio cor-

responent a la definicio de la contextualitzacio i abast del projecte.

T1.2 - Planificacio temporal: Documentacio de la planificacio i esti-

macio temporal del projecte, a partir de l’analisi inicial d’aquest.

T1.3 - Gestio economica i analisi de sostenibilitat: Documentacio

del pressupost i analisi de sostenibilitat associats al projecte, en

base a les tasques, estimacions i recursos definits en la planificacio

temporal.

T1.4 - Integracio final de la gestio: Integracio dels documents desen-

volupats en les tasques T1.1, T1.2 i T1.3, incorporant les modifi-

cacions derivades de la seva avaluacio.

T1.5 - Reunions de seguiment amb el director: Realitzacio de reu-

nions amb el director del projecte. Tot i que es realitzaran pe-

riodicament i a conveniencia, s’estima que es duguin a terme una

hora setmanalment.

T1.6 - Reunions de seguiment amb el ponent: Realitzacio de reu-

nions amb el ponent, recurrents al llarg de la seva duracio, per

al correcte seguiment del treball. Tot i que es realitzaran pe-

riodicament i a conveniencia, s’estima una dedicacio d’una hora

mensual.

F2 — Formacio inicial en el sistema Odoo

Fase especıficament orientada a la formacio inicial en el sistema, tant a nivell

funcional com tecnic.

T2.1 - Lectura de documentacio oficial: Lectura i comprensio de la

documentacio oficial de desenvolupament [13].

164


T2.2 - Desenvolupament tecnic i funcional: Realitzacio d’activitats

interactives a nivell funcional i de desenvolupament, en base a la

plataforma d’e-learning [14].

F3 — Estimacio inicial del projecte

Fase ja iniciada en el moment en que s’inicia el conveni, orientada a realitzar

l’analisi preliminar de la situacio actual del client.

T3.1 - Analisi inicial dels moduls: Identificacio i avaluacio inicial dels

moduls que s’han de migrar, estimant-ne la potencial complexitat

associada.

T3.2 - Proposta de planificacio de migracio: Estimacio fiable de la

planificacio temporal de la migracio, partint de l’avaluacio resul-

tant a la tasca anterior, per a la validacio per part del client de

la proposta final.

F4 — Gestio dels riscos del projecte

Fase especıficament orientada a la formacio inicial en el sistema, tant a nivell

funcional com tecnic.

T4.1 - Identificacio dels riscos: Identificacio dels principals riscos in-

volucrats en aquesta tipologia de projecte a traves d’un estudi

especıfic.

T4.2 - Avaluacio i control dels riscos: Analitzar l’impacte dels riscos

identificats i avaluar possibles accions per tal de contenir-los i/o

evitar-los.

F5 — Gestio del canvi

Fase orientada al control i la gestio dels potencials canvis del projecte, ja

siguin incidencies derivades o la captacio de nous requisits. Comprendra tot

el proces de desenvolupament del projecte, fins a la finalitzacio de la ultima

fase.

T5.1 - Reunions de seguiment amb el client: La gestio del projecte

ha d’incloure les principals parts interessades del projecte, pel que

165


la realitzacio de reunions sera constant al llarg d’aquest. Tanma-

teix aquesta tasca inclou potencialment la identificacio de nous

requisits, avaluacio de la seva viabilitat dins l’abast del projecte,

i modificacio de la planificacio a conveniencia.

F6 — Preparacio de la infraestructura

T6.1 - Setup del servidor de migracio: Contractacio i configuracio

del servidor utilitzat per al proces de migracio.

T6.2 - Setup del servidor de proves: Contractacio i configuracio del

servidor utilitzat per a la realitzacio de proves.

T6.3 - Backup de la base de dades: Realitzacio de la copia de la base

de dades del client per a utilitzar-la com a base en el proces de

migracio.

F7 — Proces de migracio

Fase principal del projecte, desenvolupada de forma iterativa i incremental.

Concretament, es realitzaran quatre iteracions d’aquesta, on en cada una el

percentatge de moduls migrats s’incrementara (20%, 40%, 70%, 100%).

T7.1 - Definicio de les modificacions: Analisi del funcionament i

disseny dels canvis requerits dels moduls coberts a la iteracio per

a migrar-los a la nova versio.

T7.2 - Migracio dels moduls: Desenvolupament dels scripts i imple-

mentacio de les modificacions requerides.

T7.3 - Proves unitaries i d’integracio: Creacio i realitzacio de proves

unitaries (assegurar el funcionament individual del modul) aixı

com d’integracio (assegurar la interoperabilitat entre moduls).

T7.4 - Proves funcionals: Realitzacio de proves a nivell funcional del

sistema, simulant els processos desenvolupats pels usuaris finals.

T7.5 - Validacio amb usuaris clau: El client validara la correcta mi-

gracio dels moduls a traves de proves end-to-end i donara el vist-

i-plau per a continuar amb la seguent iteracio.

166


F8 — Desplegament

Fase orientada a la finalitzacio de la migracio, i tancament de la part principal

del projecte.

T8.1 - Go-live: Desplegament de la migracio a l’entorn de produccio, es

a dir l’entorn final en el que accedeixen i operen els usuaris finals.

F9 — Suport Post Go-live

Fase de suport al client, immediatament posterior al desplegament final de

la migracio.

T9.1 - Formacio i suport d’usuaris: Suport en la formacio directa

d’usuaris clau del sistema en les modificacions derivades de la

migracio.

T9.2 - Resolucio d’incidencies: Resolucio de potencials incidencies

derivades del desplegament final de la migracio.

F10 — Documentacio del projecte

T10.1 - Documentacio del projecte: Desenvolupament de la documen-

tacio resultant de l’execucio del projecte, que es realitzara en pa-

ral·lel al llarg d’aquest. S’estima una dedicacio de dues hores

setmanals.

A.1.3 Recursos emprats

Un cop descrites les principals tasques del projecte, es defineixen els recursos

que facilitaran la seva realitzacio, associats a la Taula 13.

Humans

Els recursos humans emprats en el projecte son les principals parts implicades

en aquest:

• Equip de desenvolupament (DT): Grup de treball de ForgeFlow.

• Key users (KU): Usuaris clau del client involucrats en el projecte.

167


• Director del projecte / Project Manager (PM): Jordi Ballester

Alomar.

• Ponent del projecte (PP): Joan Antoni Pastor Collado.

Fısics

• Ordinador (PC): Eina principal de treball.

• Oficina (OF): Espai principal de treball amb acces a Internet.

Software

• Gsuite (GO): Eines d’ofimatica (Docs), emmagatzematge al nuvol

(Drive), correu electronic (Gmail) i videotrucades (Meet).

• Microsoft Teams (MT): Col·laboracio i comunicacio amb el client.

• Element (EL): Col·laboracio i comunicacio dins l’equip de ForgeFlow.

• Odoo (OD): Sistema base per a la migracio i la realitzacio de les

proves associades.

• Git-Lab (GL): Repositori per a la gestio del codi derivat del projecte.

A.1.4 Estimacio temporal

Partint de les tasques i fases definides en la seccio anterior, es representen en

la Taula 13 les estimacions temporals de les diverses tasques, discernint en-

tre el total d’hores realitzades per l’equip (T) i les realitzades per l’autor del

treball (P), les seves dependencies, i els recursos emprats per a la seva realit-

zacio. Posteriorment, a la Seccio B de l’annex, es pot trobar la representacio

grafica de la planificacio en format de Diagrama de Gantt.

168



F1 - Gestio del treball 90h - 90h

T1.1 - Contextualitzacio i abast del projecte 20h - 20h PC, GO —

T1.2 - Planificacio temporal 15h - 15h PC, GO T1.1

T1.3 - Gestio economica i analisi de sostenibilitat 15h - 15h PC, GO T1.1, T1.2

T1.4 - Integracio final de la gestio 10h - 10h PC, GO T1.1 - T1.3

T1.5 - Reunions de seguiment amb el director 24h - 24h PM, OF —

T1.6 - Reunions de seguiment amb el ponent 6h - 6h PP, PC, GO —

F2 - Formacio inicial en el sistema Odoo 112h - 112h

T2.1 - Lectura de documentacio oficial 56h - 56h PC, OF —

T2.2 - Desenvolupament tecnic i funcional 56h - 56h PC, OF, OD —

F3 - Estimacio inicial del projecte 56h - NA

T3.1 - Analisi inicial dels moduls 40h - NA DT, PM, PC, OF, GO, EL —

T3.2 - Proposta de planificacio de migracio 16h - NA PM, PC, OF, GO —

F4 - Gestio dels riscos del projecte 40h - 40h

T4.1 - Identificacio dels riscos 24h - 24h PC, GO —

T4.2 - Avaluacio i control dels riscos 16h - 16h PC, GO —

F5 - Gestio del canvi 24h - NA

T5.1 - Reunions de seguiment amb el client 24h - NA KU, DT, PM, PC, OF, MT T3.2

F6 - Preparacio de la infraestructura 40h - NA

T6.1 - Setup del servidor de migracio 16h - NA DT, PC, OF T3.2

T6.2 - Setup del servidor de proves 16h - NA DT, PC, OF T3.2

T6.3 - Backup de la base de dades 8h - NA KU, PM, PC, MT T3.2

F7 - Proces de migracio 280h - 84h (x4)

T7.1 - Definicio de les modificacions 60h - 20h (x4) DT, PM, PC, OF, GO, EL T3.1, T6.1, T6.3

T7.2 - Migracio dels moduls 80h - 24h (x4) DT, PC, OF, EL, OD, GL T7.1

T7.3 - Proves unitaries i d’integracio 60h - 20h (x4) DT, PC, OF, EL, OD, GL T6.2, T7.2

T7.4 - Proves funcionals 40h - 20h (x4) DT, PC, OF, EL, OD T7.3

T7.5 - Validacio amb usuaris clau 40h - NA (x4) KU, PM, PC, OF, MT, OD T7.4

F8 - Finalitzacio de la migracio 96h - 24h

T8.1 - Go-live 96h - 24h DT, KU, PM, PC, OF, MT, OD, GL T7.5

F9 - Suport Post Go-live 144h - 36h

T9.1 - Formacio i suport d’usuaris 72h - 24h DT, KU, PM, PC, OF, MT, EL, OD T8.1

T9.2 - Resolucio d’incidencies 72h - 12h DT, KU, PM, PC, OF, MT, EL, OD, GL T8.1

F10 - Documentacio del projecte 48h - 48h

T10.1 - Documentacio del projecte 48h - 48h PC, GO T3.2

TOTAL: 1,770h - 686h

Taula 13: Taula resum de les tasques del projecte. Font: Propia.

169

A.2. GESTIO ECONOMICA

A.2 Gestio economica

La viabilitat economica d’un projecte esdeve clau per assegurar-ne la seva

rendibilitat final, pel que es imperatiu gestionar correctament els costos deri-

vats de la seva realitzacio, identificant-los, estimant el seu valor, i assegurant

el seu control davant potencials desviacions.

A.2.1 Identificacio dels costos

Els principals costos del projecte estan associats als recursos necessaris per

a la seva implementacio, podent discernir-los en quatre categories.

A.2.1.1 Costos de Personal

Costos associats als principals rols de l’empresa involucrats en el projecte, es

a dir el Project Manager i l’equip de desenvolupament, format per Consultors

Tecnics i un Becari. Aquests, juntament amb el seu salari, es poden veure

especificats a la Taula 14.1

Rol Sou Brut (any) Sou Brut (h) Cost (h)

Project Manager 45,676.00 AC [16] 25.01 AC 32.52 AC

Consultor Tecnic 36,000.79 AC [17] 19.72 AC 25.63 AC

Becari — 9.00 AC 11.70 AC

Taula 14: Salaris dels rols involucrats al projecte. Font propia.

A.2.1.2 Costos de Hardware

Costos associats als principals dispositius fısics utilitzats en el projecte. A la

Taula 15, s’especifica el seu cost unitari2, juntament amb el total, tenint en

compte els 7 membres involucrats.

1Es consideren 1,826 hores laborals a l’any [15], aixı com un cost afegit del 30% referenta la cotitzacio de Seguretat Social.

2Costos aproximats a partir de fonts internes.

170


Per tal de definir la part del cost total que cal imputar al projecte, s’es-

pecifica la part proporcional d’aquest que s’hi ha destinat, considerant-ne

l’amortitzacio al llarg de la seva vida util. Aquesta s’estableix en 4 anys, i el

cost es calcula seguint la seguent formula:

CostImputable = 1, 770horestotals ×CostTotal

4anys × 250dieslaborables × 8hores/dia

(A.1)

Recurs Cost Unitari Cost Total Cost Imputable

Ordinador Lenovo 1,100.00 AC 7,700.00 AC 1,703.63 AC

Auriculars Sony 30.00 AC 210.00 AC 46.46 AC

Taula 15: Costos associats als recursos hardware. Font propia.

A.2.1.3 Costos de Software

Costos associats al programari involucrat en la realitzacio del projecte, es-

pecificats en la Taula 16.3 Els recursos dels quals s’utilitza la seva versio

gratuıta no s’especifiquen com a despesa.

Recurs Cost Unitari Cost Total

Gsuite 9.36 AC/usuari/mes [18] 393.12 AC

Taula 16: Costos associats als recursos software. Font propia.

A.2.1.4 Costos Generics

Costos associats als recursos generics requerits per a desenvolupar el projecte,

que s’especifiquen a la Taula 17.2 3

3Es consideren 6 mesos de projecte en base a la planificacio inicial (Seccio A.1).

171



Oficina (despeses incloses) 1,600.00 AC 9,600.00 AC

Taula 17: Costos associats als recursos generics. Font propia.

A.2.2 Estimacio dels costos totals

Per tal de justificar l’estimacio total dels costos de la Taula 19, cal definir

una serie de consideracions:

• Costos de Personal per Activitat: Els costos especificats a la Taula

18 estan desgranats en les hores dedicades pels diversos rols, seguint la

seguent nomenclatura:

– PM: Project Manager

– CT: Consultor Tecnic

– BE: Becari

• Costos de contingencia: Es defineix un marge de contingencia sobre

l’estimacio total dels costos del 15%.

• Imprevistos: Es consideren com a tasques amb el risc mes elevat les

involucrades en la F7: Proces de migracio, degut a que podrien requerir

un temps major a l’estimat ja sigui per una complexitat infravalorada,

o l’aparicio de nous requisits per part del client. Aquest risc s’estima al

20%, pel que comportaria l’increment en la dedicacio d’hores per part

d’un consultor tecnic en tota una iteracio de la Fase 7, traduint-se en

una imputacio extra de 224h.

Tots els imports de les despeses especificades a les Taules 18 i 19 inclouen

impostos i costos derivats de les cotitzacions a la Seguretat Social. Tanmateix,

els totals s’han arrodonit a l’alca per a facilitar-ne la comprensio.

172


ID - Tasca PM CT BE Import

T1.1 - Contextualitzacio i abast del projecte — — 20h 234.00 AC

T1.2 - Planificacio temporal — — 15h 175.50 AC

T1.3 - Gestio economica i analisi de sostenibilitat — — 15h 175.50 AC

T1.4 - Integracio final de la gestio — — 10h 117.00 AC

T1.5 - Reunions de seguiment amb el director — — 24h 280.80 AC

T1.6 - Reunions de seguiment amb el ponent — — 6h 70.20 AC

T2.1 - Lectura de documentacio oficial — — 56h 655.20 AC

T2.2 - Desenvolupament tecnic i funcional — — 56h 655.20 AC

T3.1 - Analisi inicial dels moduls — 40h — 1,025.21 AC

T3.2 - Proposta de planificacio de migracio 16h — — 520.30 AC

T4.1 - Identificacio dels riscos — — 24h 280.80 AC

T4.2 - Avaluacio i control dels riscos — — 16h 187.20 AC

T5.1 - Reunions de seguiment amb el client 24h — — 780.44 AC

T6.1 - Setup del servidor de migracio — 16h — 410.09 AC

T6.2 - Setup del servidor de proves — 16h — 410.09 AC

T6.3 - Backup de la base de dades — 8h — 205.04 AC

T7.1 - Definicio de les modificacions — 160h 80h 5,036.86 AC

T7.2 - Migracio dels moduls — 224h 96h 6,864.40 AC

T7.3 - Proves unitaries i d’integracio — 160h 80h 5,036.86 AC

T7.4 - Proves funcionals — 80h 80h 2,986.43 AC

T7.5 - Validacio amb usuaris clau 160h 160h — 9,303.82 AC

T8.1 - Go-live — 72h 24h 2,126.19 AC

T9.1 - Formacio i suport d’usuaris — 48h 24h 1,511.06 AC

T9.2 - Resolucio d’incidencies — 60h 12h 1,678.22 AC

T10.1 - Documentacio del projecte — — 48h 561.60 AC

Total CPA (Costos de Personal per Activitat) 41,288.00 AC

Taula 18: Costos de Personal per Activitat totals. Font propia.

173


Despesa Import Observacions

Ordinador Lenovo 1,703.63 AC —

Auriculars Sony 46.46 AC —

Gsuite 393.12 AC —

Oficina 9,600.00 AC —

Total CG (Costos Generics) 11,744.00 AC —

Total Costos 53,032.00 AC CPA + CG

Contingencia 7,954.80 AC Nivell del 15%

Imprevist Fase 7: Cost 224h CT 1,148.24 AC Risc: 20%

Total 62,135.00 AC Pressupost Total

Taula 19: Pressupost total del projecte. Font propia.

174


A.2.3 Model de control dels costos

En qualsevol planificacio s’estableixen el conjunt d’accions a realitzar per

assolir uns objectius, pero en un entorn realista cal considerar les poten-

cials desviacions que es produiran. Per aquest motiu, es necessari establir

un model de control sobre l’estimacio dels costos que s’ha realitzat, per tal

d’avaluar-ne les possibles variacions.

Partint dels costos identificats, el seu control es basara principalment en

les desviacions temporals de cada tasca, i s’establira amb els seguents models:

Desviacio d’Hores per Activitat

DesviacioHoresTasca = HoresEstimadesTasca −HoresRealsTasca

Desviacio dels Costos de Personal

DesviacioCostPersonal = CostEstimatPersonal − CostRealPersonal

Desviacio dels Costos de Hardware

DesviacioCostHardware = CostEstimatHardware − CostRealHardware

Desviacio dels Costos de Software

DesviacioCostSoftware = CostEstimatSoftware − CostRealSoftware

Desviacio dels Costos Generics

DesviacioCostosGenerics = CostEstimatGeneric − CostRealGeneric

Desviacio dels Costos Totals

DesviacioCostTotal = CostEstimatTotal − CostRealTotal

175


El control d’aquestes desviacions sobre l’estimacio inicial sera facilment

computable a traves d’una fulla de calcul, especıficament configurada pel

seguiment del projecte, en la qual els valors finals reals es puguin introduir

per tal que les desviacions es calculin automaticament. A la Seccio C de

l’annex, s’adjunten captures de les interfıcies que s’utilitzaran per a tal fi.

176

Apendix B

Diagrama de Gantt (Inicial)

177

Apendix C

Interfıcies pel Control dels

Costos

C.1 Desviacions Costos de Personal per Ac-

tivitat

178

C.2. DESVIACIONS COSTOS HARDWARE, SOFTWARE I GENERICS

C.2 Desviacions Costos Hardware, Software

i Generics

C.3 Desviacions Costos Totals

179

Apendix D

Diagrama de Gantt (Final)

180

Migraci o d’un sistema ERP per a una empresa del sector de ...

Documents

Transcript of Migraci o d’un sistema ERP per a una empresa del sector de ...