Post on 18-Jun-2022
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
36 Metode en versio 13. 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
39 Metode en versio 10. Font propia . . . . . . . . . . . . . . . . 121
40 Metode en versio 13. Font propia . . . . . . . . . . . . . . . . 121
41 Metode en versio 10. Font propia . . . . . . . . . . . . . . . . 122
42 Metode en versio 13. Font propia . . . . . . . . . . . . . . . . 122
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
55 Codi d’exemple d’un metode de prova. Font propia . . . . . . 138
56 Resultat d’execucio dels tests d’un modul. Font propia . . . . 139
57 Codi d’exemple d’un metode de prova. 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. CONTEXTUALITZACIO
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
1.1. CONTEXTUALITZACIO
• 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
1.4. METODOLOGIA I RIGOR
• 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. METODOLOGIA I RIGOR
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:
19 d’abril de 2021
• Data lectura del treball:
26 d’abril de 2021
• 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
ID - Fase/Tasca Temps T - P Recursos Dependencies
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. GESTIO ECONOMICA I DESVIACIONS
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. GESTIO ECONOMICA I DESVIACIONS
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
Recurs Cost Mensual Cost Total
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
1.6. GESTIO ECONOMICA I DESVIACIONS
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
1.6. GESTIO ECONOMICA I DESVIACIONS
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
1.6. GESTIO ECONOMICA I DESVIACIONS
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. SOSTENIBILITAT I COMPROMIS SOCIAL
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
1.7. SOSTENIBILITAT I COMPROMIS SOCIAL
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
2.1. PERSPECTIVA ORGANITZACIONAL
• 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
2.1. PERSPECTIVA ORGANITZACIONAL
• 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
2.1. PERSPECTIVA ORGANITZACIONAL
– 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
2.1. PERSPECTIVA ORGANITZACIONAL
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
2.1. PERSPECTIVA ORGANITZACIONAL
– 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
2.2. PERSPECTIVA TECNOLOGICA
• 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
2.2. PERSPECTIVA TECNOLOGICA
· 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
2.2. PERSPECTIVA TECNOLOGICA
• 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
2.2. PERSPECTIVA TECNOLOGICA
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
3.2. ARQUITECTURA TECNOLOGICA
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
3.2. ARQUITECTURA TECNOLOGICA
Figura 6: Arquitectura d’Odoo. Font propia
68
3.2. ARQUITECTURA TECNOLOGICA
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
3.2. ARQUITECTURA TECNOLOGICA
• 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
3.2. ARQUITECTURA TECNOLOGICA
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
3.2. ARQUITECTURA TECNOLOGICA
∗ 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
3.2. ARQUITECTURA TECNOLOGICA
• 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">
<!-- Implementaci o de l’element 0-->
<form class="oe_form_configuration">
<sheet >
<!-- Implementaci o de l’element 1-->
<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>
<!-- Implementaci o de l’element 2-->
<div class="oe_title">
<label for="name" string="Category name" class="
oe_edit_only"/>
<h1><field name="name" placeholder="e.g. Lamps"/> </h1 >
</div>
<!-- Implementaci o de l’element 3-->
<group name="first" col="2">
<field name="parent_id" class="oe_inline"/>
</group>
73
3.2. ARQUITECTURA TECNOLOGICA
</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
3.2. ARQUITECTURA TECNOLOGICA
• 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
3.2. ARQUITECTURA TECNOLOGICA
Llistat de codi 4: Exemple de creacio d’una instancia. Font propia
<?xml version ="1.0" encoding ="utf -8"?>
<odoo >
<data noupdate="1">
<!-- Declaraci o d’una inst a ncia del model -->
<record id="product_category_all" model="product.category">
<!-- Atributs de la inst a ncia -->
<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
3.2. ARQUITECTURA TECNOLOGICA
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
3.2. ARQUITECTURA TECNOLOGICA
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">
<!-- Implementaci o de l’element 1 -->
<h2>Price List </h2>
<!-- Implementaci o de l’element 2 -->
<div class="row mt32 mb32">
<div class="col -3">
<strong >Price List Name </strong >:<br/>
<span t-esc="data[’pricelist ’].name"/>
</div>
<div class="col -3">
<strong >Currency </strong >:<br/>
<span t-esc="data[’pricelist ’]. currency_id.name"
/>
</div>
<div class="col -3">
<strong >Print date </strong >:<br/>
78
3.2. ARQUITECTURA TECNOLOGICA
<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
3.2. ARQUITECTURA TECNOLOGICA
• 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
5.1. INFRAESTRUCTURA DE MIGRACIO
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. INFRAESTRUCTURA DE MIGRACIO
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
5.1. INFRAESTRUCTURA DE MIGRACIO
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
5.1. INFRAESTRUCTURA DE MIGRACIO
Figura 12: Fitxer Docker Compose de configuracio dels serveis utilitzats enel desplegament d’un sistema Odoo a un servidor. Font propia
91
5.1. INFRAESTRUCTURA DE MIGRACIO
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. INFRAESTRUCTURA DE MIGRACIO
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
5.2. ANALISI DE PROCESSOS
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
5.2. ANALISI DE PROCESSOS
• 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
5.2. ANALISI DE PROCESSOS
• 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
5.2. ANALISI DE PROCESSOS
• 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
5.3. MIGRACIO DE LA BASE DE DADES
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
5.3. MIGRACIO DE LA BASE DE DADES
• 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. MIGRACIO DE LA BASE DE DADES
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
5.3. MIGRACIO DE LA BASE DE DADES
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. MIGRACIO DE LA BASE DE DADES
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.
• Migracio de la base de dades V11 −→ V12.
• Migracio de la base de dades V12 −→ V13.
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
5.3. MIGRACIO DE LA BASE DE DADES
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
5.4. MIGRACIO DELS MODULS
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. MIGRACIO DELS MODULS
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
5.4. MIGRACIO DELS MODULS
• 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
5.4. MIGRACIO DELS MODULS
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
5.4. MIGRACIO DELS MODULS
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
5.4. MIGRACIO DELS MODULS
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. MIGRACIO DELS MODULS
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 git@gitlab.com: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
5.4. MIGRACIO DELS MODULS
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
5.4. MIGRACIO DELS MODULS
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
5.4. MIGRACIO DELS MODULS
• 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
5.4. MIGRACIO DELS MODULS
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
5.4. MIGRACIO DELS MODULS
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
5.4. MIGRACIO DELS MODULS
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
Figura 36: Metode en versio 13. 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
5.4. MIGRACIO DELS MODULS
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
5.4. MIGRACIO DELS MODULS
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.
Figura 39: Metode en versio 10. Font propia
Figura 40: Metode en versio 13. Font propia
121
5.4. MIGRACIO DELS MODULS
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.
Figura 41: Metode en versio 10. Font propia
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.
Figura 42: Metode en versio 13. Font propia
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
5.4. MIGRACIO DELS MODULS
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. MIGRACIO DELS MODULS
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
5.4. MIGRACIO DELS MODULS
• 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
5.4. MIGRACIO DELS MODULS
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
5.4. MIGRACIO DELS MODULS
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. MIGRACIO DELS MODULS
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
5.4. MIGRACIO DELS MODULS
Figura 48: Codi d’exemple d’un fitxer README. Font propia
129
5.4. MIGRACIO DELS MODULS
Figura 49: Visualitzacio d’un fitxer README a l’Odoo. Font propia
130
5.4. MIGRACIO DELS MODULS
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
5.4. MIGRACIO DELS MODULS
Figura 51: Visualitzacio d’un fitxer README a GitLab. Font propia
132
5.4. MIGRACIO DELS MODULS
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
5.4. MIGRACIO DELS MODULS
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
5.4. MIGRACIO DELS MODULS
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
5.4. MIGRACIO DELS MODULS
• 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
5.4. MIGRACIO DELS MODULS
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
5.4. MIGRACIO DELS MODULS
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.
Figura 55: Codi d’exemple d’un metode de prova. Font propia
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
5.4. MIGRACIO DELS MODULS
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.
Figura 57: Codi d’exemple d’un metode de prova. Font propia
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
5.5. DOCUMENTACIO I FORMACIO
• 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. DOCUMENTACIO I FORMACIO
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
5.5. DOCUMENTACIO I FORMACIO
• 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
5.6. PROCES DE VALIDACIO
• 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. PROCES DE VALIDACIO
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
5.6. PROCES DE VALIDACIO
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
6.3. COMPETENCIES TECNIQUES
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
6.3. COMPETENCIES TECNIQUES
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
6.3. COMPETENCIES TECNIQUES
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
6.3. COMPETENCIES TECNIQUES
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
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
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
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).
[36] Odoo Community Association. Migration to version 12.0. 2020. url:
https://github.com/OCA/maintainer-tools/wiki/Migration-to-
version-12.0 (cons. 03-03-2021).
[37] Odoo Community Association. Migration to version 13.0. 2020. url:
https://github.com/OCA/maintainer-tools/wiki/Migration-to-
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
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:
19 d’abril de 2021
• Data lectura del treball:
26 d’abril de 2021
• 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
A.1. PLANIFICACIO INICIAL
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
A.1. PLANIFICACIO INICIAL
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
A.1. PLANIFICACIO INICIAL
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
A.1. PLANIFICACIO INICIAL
• 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
A.1. PLANIFICACIO INICIAL
ID - Fase/Tasca Temps T - P Recursos Dependencies
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
A.2. GESTIO ECONOMICA
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
A.2. GESTIO ECONOMICA
Recurs Cost Mensual Cost Total
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
A.2. GESTIO ECONOMICA
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
A.2. GESTIO ECONOMICA
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. GESTIO ECONOMICA
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
A.2. GESTIO ECONOMICA
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
181