Openbravo Design and Development Process/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.
For getting that done it is importat to register
Each user story is to be completed in the “done is done” logic of Scrum, so it must cover all aspects of functionality, including documentation and testing.
This way we can release chunks of functionality as they are completed, which greatly simplifies the launch phase.
As changes to the plan occur and problems are found, parts of this sequence repeat, since development is done using agile methodologies.
The sequence of work can be split in three stages:
Analysis and Design
During this phase each feature request is analyzed and as a result a complete and comprehensive design document is produced. This document should clearly state what is the design need to get to the results defined in the Functional Specification, therefore Product Manager needs to review it and sign off.
The Analysis and Design is always done by the most senior team members based on the existing functional specifications. When it is completed it is possible to provide a more accurate effort estimation and resources can be allocated accordingly.
If after the Analysis and Design phase the resulting estimation deviates significantly from what was initially planned it is informed to the Product Manager to be able to reallocate resources accordingly.
With the final Design Document, the development can be assigned to the most convenient team member.
The Analysis should consider two important topics, and the design should propose a solution that does not create a problem with those:
- Critical functionality
If the functionality that is going to be implemented is related to critical operational functionality (functionality that involves real time response, for example) or is going to affect critical or sensible functionality, the design should take this factor into account. For example, the test plan should be more extensive and more focused in these areas as well as to include automated testing, that can be re-run whenever require to ensure code stability, that is nonconforming outputs found if any are corrected, and conforming ones have not been affected.
Besides that, the design should be shared with any team that might have a relation to it to ensure that no corner cases are missing from the Analysis.
As for performance, this is a critical requirement to consider always. When Analyzing the functionality, it is important to state the performance impact that it might have. In case that it is performance sensible, then it should be tested with high volumes of data. In the cases in which the functionality is going to have an important performance impact, it must also include specific automated tests.
The tasks done in this phase are:
- Transform feature requests into user stories and acceptance criteria, supported by Functional Specifications using the Style guide
- Design a solution to the user story requested and write technical specifications
- Write documentation for the designed solution using the Documentation Style Guide
- Write test plan for the designed solution to make sure the given acceptance criteria are met
With the design in place, the development of the required functionality is done based on the previous document.
This task is done by the most suitable member of the team, taking into account knowledge of the related functional flows and availability.
The development of new functionalities follows the Test Driven Development approach. This is done in order to ensure a higher quality of the code and a more usable API.
As a side effect, once the development is finished, it should have all the required automated tests already in place.
For new developments a new branch is created in our Central Code Repository. The developer will push the changes into this repository so it can be reviewed before merging it with the main branch.
Another task for the developer is to write the required documentation. This can include:
- User Documentation
- Installation and Configuration Manual
- Document Tests in TestLink
- Test automation
- Document API changes if those happen as a consequence of the development
In short, the list of tasks to be done in this phase are:
- Implement solution using Test Driven Development and Unit testing
- Create or update the required documentation
- Push changes into a new branch
This is the last phase of this process. The end goal of it is to ensure the quality of the results.
This phase is always done by a senior member of the team and consists on reviewing the result of the development phase.
The review that needs to be done is focused on three areas:
- Functional Testing
- Code Review
The Documentation created previously is reviewed to ensure that is properly written and it is easy to understand.
The functionality is tested, looking for corner cases, to find possible bugs even before entering the QA process of the development. Since developers should be familiar with both the functionality and the code, it brings a lot of value that they are the first one to do the testing. However, this testing does not replace QA testing, since it is important that someone not familiar with the code tests the functionality too.
Code Review is done to ensure proper quality of code. This is done to verify that the code created is highly maintainable and easily extensible. To achieve it, the code must be easy to read and to understand and it must follow generic conventions. Code reviews are done using this guide The guide is based on the shared knowledge in Openbravo as well as on the Clean Code book of Robert C. Martin.
All items included in that list will have to be correct. If a nonconforming output is found, it will be corrected by the developer and once more reviewed by a senior development to ensure that the nonconforming output has been corrected.
Also, performance impact should be reviewed based on the Analysis and Design done previously. In case there are tests defined, those should be executed with high volumes of data.
After the Review has been done, the document created with the adjustments to be made is shared with the original developer. All of the points of the document must be fixed or discussed and discarded to complete this phase. While there are open topics the Review phase can not be considered as complete.
There are some severe problems that are not tolerated. If a developer submits a development with any of this problems, it is immediately rejected until it is fixed:
- No automated tests
- Development makes the system unable to compile in any of the stacks supported by Openbravo
- Development does not fulfill functional specification
- Severe functional bugs
- Very poorly written code
- Very poorly written documentation
- Unacceptable performance with large volumes of data
Note: Large volumes of data are defined per development basis as it depends on the functionality that is going to be reviewed, and it is done based on volumes of existing clients. Acceptable performance is also defined as per development basis since also some functionalities tolerate more degradation than others.
When the Review is done the branch including the new Code can be merged into the main Repository. After the merge the new code will be taken into account in the new executions of Continuous Integration (a set of instances that are running continuously all the automated tests of the system), this execution must be successful. If not, the problems that arise must be fixed before the development can be considered done.
Distribution of work to teams
Inside the team the feature requests are analyzed and the effort to complete them is distributed based on knowledge and availability of the different team members.
It is also possible that the development phase is done by an external developer in some specific scenarios. In this case, the final responsible of the development is the senior developer who has executed the Analysis and Design phase and should also be the one to execute the Review phase.
An external developer does not have access to all the repositories and information as the senior developer has. It is also the responsibility of the senior developer to enable the external developer and to also control the access that needs to be given. If the situation is not clear enough, this topic can be discussed with a Product Manager.
Since all the Code is centralized in our Central Repository, it is easy to distribute the work between team since the code and the changes of it are easily shared and traceable internally.
As part of the Construction Phase, a number of collaterals need to be produced, therefore all the information required to get client's successfull deployments is provided.
In particular, the following collaterals needs to be updated:
- On line help
- User Documentation
- Functional Documentation
- Installation Guide
- Database model diagram
- Training to the support team
Additionally, the following software artifacts need to be developed:
- Upgrade documentation and tools: documentation and scripts that allow users of the previous release to move to the current one. The tools needs to be developed before the completion of QA test cycle in order to allow existing customers to start maturation cycle as described in Release Phases wiki article.
Finally, the following dissemination artifacts need to be developed:
- Demo scripts for the most important new functionality
- Demo recordings (viewlets) of the most important new functionality (optional)
- The datasheet must be updated
The final iteration of collateral development must be complete before QA Approved release.
Development cut-off before launch
Two criteria are defining the behavior preceding the launch phase:
- Release defining features
- Development cut-off date
Release defining features have been decided during the feature request scheduling or Planning phase.
Development continues to contribute features to a new release at least until release defined features have been completed sufficiently.
Then at a set cut-off date, all features completed until this point move into the launch process while the ongoing development continues in PI for later releases.
The cut-off date is 6 months before the desired release date, leaving a safe amount of time for the launch process.
If during the approach of the cut-off-date it becomes clear that a release defining feature cannot be completed in time, the responsible Product Owner must flag this at the earliest possible point.
It then needs to be decided whether the launch date has to move or the feature needs to be cut back.