Openbravo Design and Development Process
This document has been reviewed by Openbravo senior engineers and approved by Openbravo VP Product Software Engineer, as indicated in this section.
|Sr. Applications Engineer||Sandra Huguet Pérez||20/11/2018|
|VP SW Engineering||Dmitry Mezentsev||22/11/2018|
All changes to be made in this document will be discussed within Openbravo engineering team and approved by engineering management, as well as tracked within this section.
|Date||Author or editor||Description of change||Document status||Document version|
|April 2008||Paolo Juvara||Initial version||Draft||v 1.0|
|November 2018||Patricia San Juan||Overall content & Planning, Launch and Maintenance Phases update||Final||v 3.0|
|November 2018||David Miguélez||Construction Phase Update, Contributions and Collaborative Developments documentation, External Resources documentation||Final||v 3.1|
Openbravo is a software solution vendor that offers a global POS and retail management software with the aim of helping midsize and large business to successfully manage their retail operations.
“Openbravo Commerce Suite” is the Openbravo’s commercial offering for the Retail Industry. This suite offers a unique store solution or cash register system, composed by a set of modules that once installed on top of Openbravo, deliver the retail functionality provided by Openbravo and the technology to extend and create new retail functionality to adapt Openbravo as required.
Besides that, Openbravo Commerce Suite is backed by a complete back office functionality that is the Openbravo Business Suite. The Openbravo business suite offers a comprehensive business management solution with built-in ERP capabilities.
This document is intended to describe the Openbravo design and development process established, implemented and maintained to ensure the subsequent provision of the Openbravo product’s suites.
Openbravo Design and Development Process
The objectives of Openbravo design and development methodology are:
- Quality, by ensuring that market functional requirements are properly defined and met.
- Efficiency, by establishing reviews, verification activities and controls conducted to ensure that design and development outputs meet the input requirements
- Predictability, by communicating Openbravo product release cycle to all parties involved
- Transparency, by involving customer and users through every stage of the process
To achieve these objectives the Openbravo Development Process aims at being lean but formal and takes inspiration from iterative and agile development processes such as Scrum and the Agile Unified Process.
The above picture is a high-level representation of the overall process, which manages the full lifecycle of a release and it is composed of four stages, once Openbravo Product Roadmap is defined and therefore available:
- Planning: The purpose of the planning phase is to review product roadmap and:
- Identify the detailed list of feature candidates, either new features or improvements of existing ones, for the next release
- Plan design and development activities required within engineering teams.
- Construction: During the construction phase, each candidate feature is independently designed, developed and documented using an iterative approach. At the end, all the features are merged and the new release is packaged.
- Launch: The launch phase covers all the steps that are necessary to deliver a successful release to the market, including (but not limited to):
- quality assurance testing (Q&A)
- early adopters testing (Innovators program)
- and training
- Maintenance Maintenance stage covers all the activities that are required to support and upgrade a production release, together with training activities.
It is important to remark that Openbravo design and development process establishes internal reviews, therefore it is not possible to start working on the next stage in the process unless all parties involved agreed that the current one has been executed as required.
Finally, Openbravo solutions are released on a quarterly basis. In the case of the Openbravo Commercial Suite (Openbravo for Retail), releases are named as 3.0RRXXQY, where:
- XX is the year
- and QY the quarter of the year.
The duration of a release cycle is seven months. For instance, and in the case of Openbravo Commercial Suite 18Q4 design and development activities started dated on 1st June 2018 and will finish at release dated on December 31st, 2018.
For additional information, please review Launch stage.
Openbravo Design and Development Teams
Openbravo Product SW Engineering team is composed by below list of teams:
- Release Management
The Release management and Development teams are responsible of the release cycle of the Openbravo solutions, focused on coordinating and improving the creation of Openbravo official releases that include new features and bug fixing.
Besides that, Release Management team is also the official Openbravo responsible for many development tools and processes. It is also in charge of source code management and branching policies, as well as issue tracking system and code continuous integration.
Finally, Q&A team is responsible for every release quality assurance process, including automatic testing, and Cloud team is responsible for the Openbravo cloud deploy option, see the next section.
All of these engineering teams work in a close relationship with Product Management (PM) team that is in charge of defining and delivering product roadmap, and the Support team that is in charge of support and training activities.
Openbravo deploy options
There are two options to deploy Openbravo, Openbravo Cloud or self-hosted (on-premise or in the cloud of the customer´s choice):
- Openbravo cloud is a single-tenant platform as a service option that enables business to deploy Openbravo solutions on virtual servers in Amazon Web Services (AWS).
It can only be subscribed in combination with an Openbravo Professional or Enterprise edition. This is Openbravo recommended deployment option. If choosing Openbravo Cloud option Openbravo Cloud operations will be in charge of the complete technical operation (operating system, database, system software stack (server)).
- If an Openbravo client chooses to self-host Openbravo, that implies that Openbravo does not manage that instance, it is maintained by the customer. Therefore Openbravo is not responsible of backups and restoration policies within that environment, neither database access control procedures or database management.
Contributions and Collaborative Designs
In Openbravo, it is possible to collaborate in the development of new Features with both external partners and internal teams that are not inside the Engineering team. This can be done mainly with two different approaches.
A Contribution is a development designed and developed by a team that is external to Openbravo's Engineering Teams. This means it can be done by another Openbravo Team like Services team, or by an Openbravo Partner for which the corresponding partner agreement is in place.
A Collaborative Design is a collaboration between an Engineering Team and a partner or another Openbravo team. The Key difference between it and a Contribution is that the Engineering Team is involved earlier in the Construction Process.
Both approaches have the same result. The code developed will be included in Openbravo's Product and, starting at that moment, Openbravo will become the owner of this type of development, and the responsible for support and maintenance of it. That is the reason why it must follow the same quality controls established for internal developments, and it must follow a proper Development Process as described in the wiki page Contributions and Collaborative Designs.
Within Openbravo it is not unusual to work with External Resources. This can include external developers as well as external products or services.
When there is a need for it, Openbravo follows a process to select the most suitable candidate to fulfill its needs. It involves analyzing the requirements, research the market for the available solutions and decide the most suitable one.
As described in External Resources document, this process has several phases and involves different roles within Openbravo.