working of the system and its technological in-
frastructure in production environments when the ap-
plication is deployed (Hertvik, 2014).
3
USED TECHNOLOGIES
In the discovery phase of the product, the “Power-
Point” tool has been used to develop and validate pro-
totypes. Although there are numerous alternatives, to
quickly prototype, we have chosen this tool for its
great flexibility. Using the pattern mode of this tool it
is possible to create templates of the interface of the
software to be developed, which can be later com-
pleted by adding the content that we want to validate
with clients or customers. In addition, this tool allows
you to add links between objects so that you can sim-
ulate navigation among the slides by using items that
simulates the buttons of the proposed final system.
This tool produced very precise results that allowed us
to make the designed prototypes quite realistic, that
were used to validate the solution proposal with the
users in some interviews. Given the fact that we know
about the Odoo interface, and the technological limi-
tations of the features that Odoo offers, we have gen-
erated realistic prototypes at low cost. This allowed us
to easily discard some alternatives that did not meet
user or customer expectations. This process could be
also be done with the Odoo Studio tool, a tool that
facilitates the generation of modules with a graphical
interface like Drag Drop. Despite it is fully integrated
with Odoo and allow autogenerating the module, we
did not contemplate this option because of the diffi-
culties it could introduce when reusing the generated
code. For G7Innovation it is not enough having a sin-
gle module, but also be able integrate it with third par-
ties APIs which to the best of our knowledge it is not
feasible with generated module with Odoo Studio.
Once the product is defined, the phase of a formal
definition of the requirements. The technical speci-
fication, within the development phase has been car-
ried out using NDT-Suite (García-García et al., 2014).
NDT-Suite is a set of tools that facilitates the use of
the NDT methodology, which is integrated on top of
the Enterprise Architect tool (Architect, 2019). With
this tool, and starting from the agreed prototype, we
have been able to define the system class diagrams,
actors, use cases with their interaction requirements
and some non-functional requirements.
Thanks to the ability to perform M2M (OMG,
2008a) and M2T (OMG, 2008b) transformations of-
fered by NDT-Suite we automatically obtained some
of these requirements, Python code that was used as
the basis for the construction phase and the documen-
tation of the test plan for verification and validation.
The code self-generated by the M2T transforma-
tions has been used as the basis for the construction.
However, it is still necessary to adapt some code con-
figuration parameters in Odoo to reach an integration
with the system. Nevertheless, given the fact that a
great proportion of the code has been generated auto-
matically the productivity is increased and the possi-
bility of human failures has been reduced.
The verification and validation of the system that
is generated is carried out using the Katalon tool, by
executing the system test plan that generates NDT
from the defined ones. It is important to note that the
integration tests of the autogenerated modules with
the existing ones have not been possible to be self-
generated with the use of these methodologies so far,
despite the importance these kinds of modular devel-
opments.
Once G7Innovation delivered the validated and
verified system to the responsible of the iMEDEA
project, the informatics team of the clinic was the re-
sponsible for carrying out the phase of operations.
Each one of the described phases is highly inde-
pendent from the others. This allow having work
teams that can be working in parallel.
4
CONCLUSIONS
The proposal of this methodology arises as a need to
facilitate communication with customers, and to al-
low a development that is user-friendly without im-
plying an increase in the costs.
After applying these methodologies, we have been
able to generate a product closer to the user and client
expectations, automating its construction which re-
duce human failures and increases productivity. The
prototypes defined using the Design Sprint methodol-
ogy were very realistic as we knew about the technol-
ogy features on which we wanted to develop the final
product and its technological limitations.
The use of these methodologies reduced the need
of code modifications in advanced project stages be-
cause of the validation with the customer’s needs dur-
ing the interviews on which they could test the proto-
type. Also, human errors are reduced since most of the
code was automatically generated. However, the
automated generation requires adapting the code and
execute more intensive integration tests to verify the
compatibility of the generated code with the already
deployed modules.
As result, using this combination of methodolo-
gies we produced a module in collaboration with the
startup G7Innovation.