Model Framework

The GÉANT software maturity model is not only focused on processes, despite the most maturity models are most processes oriented – it ends to provide a framework for all aspects of target practice and their maturity. A similar integrative and multifaceted view is used in other frameworks or methodologies used in other domains.

Multi-faceted view, refine a maturity model through the work on mutually supporting and complementing concerns. Examples from other domains:

• In relation to IT systems, processes and organisations in the telecommunication industry, TMF Frameworx elaborates business processes, information, tools (seen through applications identified by TMF) and associations between them (specifically, APIs used to catty the information through processes and between systems).
• In healthcare, HL7 deals with the standards for the transfer of data between IT systems, healthcare providers, their integration and content harmonisation. HL7 Development Framework establishes and sometimes reuses the metamodels, vocabularies, rules, views, tools, techniques and procedures for addressing of needs and requirements, harmonisation of the content, development of specifications, and their actual implementation. All these practices and resulting specifications are supported with related resources and schemes for communication, coordination, education, conformance, validation and certification.

When it comes to software maturity model for GÉANT teams, it should directly address the areas relevant for software development, subject to various GÉANT specific constraints. However, having a wider perspective is crucial for effective and meaningful practical work. In addition, such a perspective should also facilitate reuse of the elements of the existing maturity models relevant to the selected target areas.

Key elements of the GÉANT maturity model framework are:

framework comprises several items:

• Maturity levels are Maturity levels are generalised, progressing well-rounded descriptions of maturity that could be detailed and elaborated for any specific field or target area. By elaborating a maturity model, this generic scale is adapted for a field or target area, by analysing and detailing the related subjects, goals, processes, common stages, practices, tools and so on. having a common, shared, and consistent scale (actually idealised descriptions) of maturity levels make it easier to match the maturity across areas or to more easily align with other existing maturity models that use a compatible scale. This approach also allows relating maturity levels to different applications of maturity models, or to match the developed instruments against the corresponding maturity levels. The proposed generic scale has five levels that can be easily identified and matched in other developed maturity models, even if the characteristics of levels are expressed in terms that are specific for some topic.
• Target areas are thematic subjects that need to be determined in order to refine the field of interest and focus the work on the improvement of teams or software development projects, their processes and practices, and development of related instruments that should direct, support or measure the advancement. These areas should be cohesive, relevant at the specific point in time, complete, fine-grained and independent, while individual elements and goals in them should be close to each other. It would be difficult to capture the maturity in a wide area, so the coverage would have to be either vague or sparse. If the target area comprises a wide spectrum of elements and goals, it is quite likely the resulting recommendations would not be actionable and that the teams will not be able to master all elements, but rather intentionally focus on just a few. The selected target areas should be already recognised as relevant and hopefully familiar to the audience. Whether they should be thematically close or not or how detailed they should be is determined by the practical needs. If close, they support each other in terms of maturity and mutual dependence. These areas may be already identified or acknowledged in other maturity models when those models should be reused or adapted if suitable. The Guide to the Software Engineering Body of Knowledge (SWEBOK Guide) maintained by the IEEE Computer Society provides a suitable taxonomy of the field. It can be used as a frame of reference, but the actual names and scopes of areas should be rather expressed in the terms aligned with the actual understanding of the target audience, in this case, software developers. The actual scope of used areas should be narrowed down the relevant and attainable goals. Most maturity models focus on one target area.
• Relevant subjects – (conceptual cloud/vocabulary - (used to be parameters)) - Relevant subjects, topics and concepts - a wider range of elements pertaining to the individual domain and its areas) – could be also presented and described for individual or several target areas, but may also come from various frameworks, guidelines a maturity models’ subjects etc. The listed items may include sub-disciplines, processes, practices, team characteristics, tools, success indicators, quality attributes, etc. or even stand for several of these at the same time. Various classifications could be developed as needed for those “things”, but this is not necessary as long as they are used as a reference checklist for the identification and development of maturity elements. As long as the list is manageable, it may be associated with several areas. The relevant subjects may also come from a  reference taxonomy used to identify target areas, but should primarily consist of lower level items in the taxonomy.
• Specific goals are concerns associated with one target area that may be observed and analysed across several or all levels of the maturity model. Sometimes these goals may be similar in nature across several areas or closely related. The existing maturity models often analyse one or several closely related goals. In order to identify and develop these goals, it may be useful to observe the goals established for nearby areas. Often, elements from various maturity levels that aim at one specific goal are progressively dependent - in order to be able to meet some maturity element and a certain level, a corresponding element from the preceding level must be met. The simplest maturity models collapse target areas and specific goals into one and observe their subject without further thematic decomposition, which results in a one-dimensional maturity scale instead of maturity matrix. Other explicitly address them by listing and elaborating each specific goal in every cell of maturity matrix (that is, as an element of maturity level).
• Common stages and elements are higher-order common phases and sub-phases of work and are therefore quite useful in the development of process-related maturity models. The example provided here lists the stages such as preparing, design, delivery and closing, with each of them comprising of several elements. In addition to relevant subjects, which are very specific and only occasionally useful, stages and elements can be used to refine specific goals in almost any target area. They actually represent a simple model of how the things are usually done, and as such can be even related to PRINCE2 or PMBoK project decomposition. The actual coverage of elements with specific goals for a given target area may be sparse or localised, as only some stages or elements may be relevant and thus present. Stages and their elements are not performed executed in a waterfall manner, may partially overlap or be repeated in iterative loops. Stage elements may be executed in a slightly different order. Since only the work of the team observed, they do not include handover or management of external work.
• Elements of maturity levels (within specific target areas) are the elements that are indicative for specific levels of maturity within one target area. They are actualisations of maturity levels the specific target areas, in which the generic descriptions of levels are replaced with direct explanations that use subjects and specific goals of the target area, such as "linkage of code changes to requirements, features, or detected or addressed defects". They can be interpreted as concrete and direct recommendations, indicators, assessment criteria, or even maturity prerequisites. If not present, they become detailed goals associated with a specific maturity level. They are developed by analysing what concrete elements of the target area should be associated with individual maturity levels as defined in a more general way. In order to simplify this analysis, the individual elements could be sought by observing how each specific goal should be satisfied at each level. They may be also formulated by looking at the adjacent levels and related target areas and by referring to the list of relevant subjects. Since some specific goals or concepts present in several target areas may be shared or similar, it is also possible for elements of levels from various target areas to be mutually dependent or related. In most maturity models they are these elements are expressed as individual items, bullets or short statements within the maturity matrix.
• Maturity matrix is the pivotal element of most maturity models and all the above elements serve to develop this one. Its rows are maturity levels, whereas each row represents one target area. In their intersections are elements of maturity levels for each specific target area, expressed in bullets or short statements; further details can be explained separately.

...

All repetitive tasks are automated to up to the limits of feasibility and technology. Processes are continuously updated on the base of obtained feedback. There is ongoing self-remediation, self-learning and optimisation.

SMM target areas

The previously identified most relevant target areas are:

• Requirements Engineering
• Design and Implementation
• Quality Assurance
• Team Organization
• Software Maintenance

They can be mapped to the SWEBOK Guide taxonomy in the following way:

Requirements engineering

• Chapter 1: Software requirements - The elicitation, analysis, specification, and validation of requirements for software.

Design and implementation

...

.

...

Quality assurance

• Chapter 4: Software testing - An empirical, technical investigation conducted to provide stakeholders with information about the quality of the product or service under test.
• Chapter 10: Software quality

Team organisation -  JUST SOME OF THESE?:

• Chapter 7: Software engineering management - The application of management activities—planning, coordinating, measuring, monitoring, controlling, and reporting—to ensure that the development and maintenance of software is systematic, disciplined, and quantified.
• Chapter 8: Software engineering process - The definition, implementation, assessment, measurement, management, change, and improvement of the software life cycle process itself.
• Chapter 9: Software engineering models and methods - Structure on software engineering with the goal of making that activity systematic, repeatable, and ultimately more success-oriented
• Chapter 11: Software engineering professional practice - The knowledge, skills, and attitudes that software engineers must possess to practice software engineering in a professional, responsible, and ethical manner

Software maintenance

• Chapter 5: Software maintenance - The totality of activities required to provide cost-effective support to software.

Unassigned - what about those?

...