This section describes the development process we try to use in the BASE project. It is not carved in stone and deviations may occur. For every new feature or enhancement the procure below should be followed. If you encounter any problems, arrange a group meeting. Someone else may have the solution! The text is biased towards adding new items to BASE, but it should be possible to use the general outline even for other types of features.
The group should have a short meeting and discuss the new or changed feature. Problem areas should be identified, not solved!
The person who is going to make the analysis, design and development is responsible for taking notes. They should be kept until the analysis and design phase has been finished.
A follow-up meeting should be held at the end of the analysis phase.
A single meeting may of course discuss more than one feature.
Create an diagram of the classes including their properties, links and associations. Use the already existing diagrams and code as a template. The diagram should have information about cache and proxy settings.
Write a short document about the diagram, especially things that are not obvious and explain any deviations from the recommendations in the coding guidelines.
Identify things that may affect backwards compatibility. For more information about such things read Section 29.1, “The Public API of BASE” and Section 31.3.3, “API changes and backwards compatibility”.
Identify what parts of the documentation that needs to changed or added to describe the new feature. This includes, but is not limited to:
User and administrator documentation, how to use the feature, screenshots, etc.
Plug-in and core developer documentation, code examples, database schema changes, etc.
If there are any problems with the existing code, these should be solved at this stage. Write some prototype code for testing if necessary.
Group meeting to verify that the specified solution is ok, and to make sure everybody has enough knowledge of the solution.
If step 2 is properly done, this should not take long.
Follow the coding guidelines in Section 31.3.4, “Data-layer rules”.
At the end of this step, go back and have a lock at the diagram/documentation from the analysis and design phase and make sure everything is still correct.
For simple cases this is also easy. Other cases may require more effort.
If needed, go back to the analysis and design phase and do some more investigations. Make sure the documentation is updated if there are changes.
Build on and use the existing test as much as possible.
Most likely, users and plug-in developers wants to know about the feature.
Do not forget to update the Appendix K, API changes that may affect backwards compatibility document if you have introduced any incomaptible changes.