MaturityDefinition

This article holds reference information about the definition of maturity, as understood in the context of Polarsys and/or Eclipse. For clarity some stuff has been removed from this page to be put in separate pages:

• Eclipse Quality Requirements identifies quality requirements relevant to Eclipse and Polarsys contexts.
• Eclipse Quality Model proposes a quality model, from its decomposition into quality attributes down to the metrics used.
• Eclipse Metrics describes the metrics we are able to gather, and how they are computed.

Context

Maturity in a generic meaning refers to the state gained after the youth. It usually involves concepts of reliability, mastership, absence of common errors, predictability.

However in the context of critical embedded software it has a specific semantic. After a few discussions with Pierre Gaufillet and others around me, here is what maturity could induce:

• Some sort of reliability: the software product has been enough exercised to detect and correct the most frequent or critical bugs. Considering Reliability Growth Models, the number of bugs discovered in a mature project is decreasing.
• Some sort of functionality: the software product is fully able to deliver its functionalities, it is usable and complete.
• Some sort of maintainability: it should be easy to modify and improve the software, even if developers change.
• Some sort of process predictabilitiy: the project delivers products with constant quality and at planed dates.
• Some sort of documentation and support: manuals are easily available for the different actors involved in the product usage (user, administrator, installation, upgrade, customisation..), and there is enough support to get answers in a timely and complete fashion. Support can be provided by the community, or a public or privately held company.
• Some sort of process traceability: there are publicly available documents tracking decisions, contributions, or important things. This part is especially useful for the certification.

It should be noted that Maturity is a sub-characteristic of reliability in the ISO 9126 / SQuaRE standards. The definition given for it is:

• ISO9126: the capability of the software product to avoid failure as a result of faults in the software.
• SQuaRE: degree to which a system, product or component meets needs for reliability under normal operation.

The SQuaRE standard adds an interesting note to this definition: "The concept of maturity can also be applied to other quality characteristics to indicate the degree to which they meet required needs under normal operation."

Reference to standards

As much as possible, we want to reference recognised standards when defining the quality model. In that spirit, many product-related characteristics use definitions from the ISO9126 or SQuaRE standard. Process areas are mapped, when the concepts were close enough, to CMMi Key Process Areas. When considering the ecosystem quality attributes, we relied on published open-source quality frameworks like SQO-OSS, QualiPSo and QualOSS.

Conclusion

The maturity of a software project is thereby defined in our context as the overall combination of these characteristics. It is further defined in depth by the quality model itself and its associated quality attributes.