Documentation Attributes


Attributes of quality represent our measurement goals and questions for the given context. Defining a custom quality model for your specific context is a foundational and highly recommended step in a quality assessment and improvement program, and to get the best out of Alambic. It is possible and much easier to rely on established standards and norms to formalise them, such as ISO 9126 and ISO 250xx for the product, CMMi for the process, and open-source quality models for the community.


  • Activity ( QM_ACTIVITY )

    The activity of the project's ecosystem, as measured on the mailing lists and configuration management system.

    An active project will provide a lot of information on the mailing lists, so when an user encounters an issue she will quickly find the information she needs, and has more chances to get answers if she asks. Fixes and improvements are added regularly.

  • Diversity ( QM_DIVERSITY )

    The diversity of the project's ecosystem, as measured on the mailing lists and configuration management system.

    If many different actors from different companies are involved in the project, then it improves its sustainability (by eliminating a single point of failure) and adaptability to different situations. Having developers and users with different contexts and perspectives on the project helps widening its scope and provide a more generic support.

  • Documentation ( QM_DOC )

    The maturity of code.

    Good code is vital for maintenance and evolution. It will encourage people to contribute, lower the number of bugs, and make a better product for the end-user as well as for the maintainers.

  • Ecosystem ( QM_ECOSYSTEM )

    The sustainability of the ecosystem evolving around the project.

    Sustainability is a key point for long term support. If there is a lot of activity, if people can get fast and complete answers, if many people from different companies contribute to the project, then it will have more chance to still be there in a few years, and to continue providing fixes and improvements.

    Ecosystem requirements have been discussed on the mailing list and during meetings, and have been further described on the Polarsys wiki.

  • Maintainability ( QM_MAINTAINABILITY )

    The Maintainability of the codebase, as defined in ISO-9126.

  • Process ( QM_PROCESS )

    The maturity of the process used to run the project.

    A sound process helps people to do things right and ease collaborative work. If the process is documented, has predictable output, helps enforcing good development practices, etc. then new comers will easily find the information to collaborate, test or change code, or participate in the community. A good process also helps producing a good product [< href="/documentation/references.html#Ing2003">Ing2003] -- although it is agreed that the process is not enough by itself.

    Process requirements have been discussed on the mailing list and during meetings, and have been further described on the Polarsys wiki. Some may also recognise CMMi Key Process Areas among the attributes.

  • Product ( QM_PRODUCT )

    The maturity of the product itself, from the code perspective.

    Considering the vast amount and diversity of the projects under the Eclipse umbrella, there must be no single definition of quality to fit them all. However, Eclipse has some recommended practices and concerns about product quality. Projects are then expected to extend this foundation. Major concerns identified for Eclipse products quality are linked to the development context of the foundation (open source, very large code base and thousands of contributor worldwide), and its architecture (modular stacks of components). It must be highlighted that product quality is not clearly defined on the public wiki, neither for its definition nor for how it may be assessed. Furthermore, almost all product-related rules (with a few exceptions, like for packages naming) are optional guidelines. .

    Ecosystem requirements have been discussed on the mailing list and during meetings, and have been further described on the Polarsys wiki.

  • Eclipse Maturity ( QM_QUALITY )

    The overall Maturity of the project.

    In the context of embedded software, Maturity is usually associated with some kind of reliability (most bugs have been already found) and functionality of code, sustainability of the project (will it still deliver fixes and improvements in a few years), and process predictability. Maturity in the PolarSys context has been further described on the wiki, and is actually precisely defined by the decomposition of this quality model.

  • Reliability ( QM_RELIABILITY )

    The Reliability of code, as defined in ISO-9126.

  • Build and Release Management ( QM_REL_ENG )

    Does the project apply best practices regarding Build and Release management?

  • Configuration Management ( QM_SCM )

    The maturity of the project regarding access and usage of the configuration management system.

    Configuration management is an essential part of the collaboration in the project. Access to the source should be documented and facilitated for new comers to easily come in.

  • Support ( QM_SUPPORT )

    The amount of knowledge provided when someone asks for support.

    Having many answers on a single question helps better understand how the product works in different conditions, and also provides help for people looking for a similar information later on, since mailing lists are archived and public.


Page generated by Alambic 3.3.3-dev on Mon Nov 12 17:32:23 2018.