The QAG was created by Digitalis Informatica as a guide to validate all technological software projects.
The QAG focuses on a number of indicators, best practices, and technologies that are used to provide a pattern of quality to all projects that state to be QAG compliant.
Let's see all items that the QAG specifies
QAG specifies that a number of software products must be used for determined goals by all QAG compliant projects.
Maven is a technical project management tool. It allows to automate a set of steps in project building, deploying, documentation and quality assurance.
Maven adds to projects a set of conventions to every project it manages.
In regard do the QAG it is relevant to name the automation of Unit tests in every build, and the code coverage report.
All JUnit implemented tests are ran at every build after compilation, and before the build process.
A build will only be generated if the test suite ran successfully. This provides an early and automated quality check to every change a developer makes to the project.
The code coverage report (Cobertura), can be generated along with the documentation site for the project.
This report shows in detail the percentages of code coverage in a top down view starting in main packages and drilling down to inner packages, classes and every line of code within the project classes.\n This helps the developer to build tests that validate every line of code that the project has, and thus, map every functionality proper behavior after each code change.
These are mandatory best practices that QAG forces the projects to comply.
All code must be carefully commented. The best practices defined for JavaDoc documentation generation should be validated, and all relevant code logic must also be documented. \n All the main Java IDEs allow us to configure them to consider missing of erroneous JavaDoc comments to be considered as errors. It's usage is highly encouraged! \n The Eclipse bundled in the Digitalis SDK allows automatic validation of all JavaDoc tags.
Several others patterns and best practices are very much advised by QAG. These are not mandatory for all projects since, now and again, common sense and practicality weight more than the use of some of these points. Nevertheless they must be taken very seriously on all QAG projects and are used in the majority of them.
It's definition can be viewed here.
Maven imposes this, witch is another advantage of it's use. It does so mainly through the following features or imposed limitations:
These features act as constant monitoring automated tasks that prevent the commonly called Spaghetti code.
It's definition is simple:
public ISomeFuncionality getFunc() {
return new FuncionalityFirstImpl();
};
Inversion of Control and Dependency Injection are the glue that binds all modules and functionalities together. It is a vast topic, which you can read more in the IoC Utils project, our IoC implementation wrapper.
The use of Maven is very much present is this section of QAG.
Several of Maven's reports are mandatory by the definition of QAG.
Here is the full list of them:
Other than the previous automatically generated Maven reports a few sections must always exist in QAG projects.
Complete instructions of what the project provides, and how to use it.
For simple projects a single page may suffice. For complex APIs and other large projects, a complete multi-paged User Guide, complete with all relevant features usage description should be published.
The typical Frequently answered Questions.
Easy access to the current and relevant previous versions.
By means of the Digitalis Maven Repository, all existing versions are always accessible and this should be referenced in the page.
All projects that represent an API or reusable component or library, should include a sample application to download and try out.
According to the difficulty of use of the project's functionalities, so should the sample application be more or less thorough.
Naturally that, if the API is simple enough to configure, deploy and use, simple instructions can suffice, and a sample application is replaces by a sample usage section.
As stated in the download item, all distribution versions should be available. Here we state that so should the projects code, when we speak of an open-source project.
All code for all releases and other functionalities, a Version Control system should be provided.
The latest release code should be directly available in zip format, in the download page, for easy access.
The latest release should be directly available, in the download page, for easy access.