SMM focuses on five target areas (TAs) that have been found to be essential for successful software development, addressing also the GÉANT specifics. Further, each TA includes several specific goals (SGs), which are individual concerns within them.

1. Requirements engineering

1.1. Identification and overall management of stakeholders

All relevant perspectives of the system, including the users, developers, maintainers, testers and providers, are identified. Each perspective is represented by a stakeholder capable of making binding decisions.

1.2. Eliciting needs of stakeholders

Expectations of the stakeholders (expressed in any way) are identified. Typically, they are further elaborated and detailed by domain experts and representative users.

1.3. Analysis of requirements and their dependencies

The expectations and needs are transformed into requirements by considering their objectives and feasibility and context. Requirements are analysed with respect to their inter-dependencies and whether they properly reflect the specified needs.

1.4. Traceability of requirements

There is a process for tracking the dependencies from the needs to the requirements (vertically) and among the requirements (horizontally).

1.5. Validation of requirements

Requirements are validated by stakeholders to verify if they properly reflect their needs and expectations.

2. Design and implementation

Activities that are usually associated with software design, development and delivery; the relevant practices, elements of development environment and tools used by software developers.

Elements of coding or software construction, encompassing the entire agile development lifecycle (unless explicitly covered in other target areas).

The actual coding is currently not elaborated here but may be added in relation to addressing of secure coding or in relation to privacy-related requirements. Integration of QA tools in the work of the development team, external consultancy or reviews and other QA related practices, tools, and measures.

2.1. Handling of design alternatives

The design alternative solutions are identified, elaborated and analyzed.

• There is a common and often used approach to investigate possible alternative solutions for the design and implementation problems.
• Evaluation and comparison results are recorded.
• The chosen solution and alternatives are reassessed upon changing needs, understanding, issues, obsolescence, technological or architectural advancements.

2.2. Documentation development and management

The technical solution is accompanied by adequate technical documentation that describes the decisions made at different stages of the development process. The documentation helps to capture and convey the knowledge but also tracks technical decisions and checkpoints.

• There is a well-known categorisation of documents that should be produced and it is clear what they should contain. For example:
  

  • Design/implementation: use cases, ideas, decisions, software architecture, technical solutions, code

  • Operations: installation, administration

  • Usage: end-user installation, end-user usage

• Visibility is set for each document type and each part of the documentation (e.g. internal, with partner groups, entire GEANT community, public...).
  

• Documentation records and elaborates technical decisions made.

• A standard set of tools and practices is applied for documenting. These include various tools, platforms or formats used to create, store and share documentation.
  
• Responsibilities for the documentation are upheld and ensured that it is up to date.
  

2.3. Technology assessment, validation and verification

The technology chosen for elaborating the system is appropriate for the purpose. Benefits of the capabilities outweigh the costs associated with its use.

Technologies are verified and documented for suitability, readiness for production usage, maintainability, support, licensing. They are periodically reassessed, not just initially.

2.4. Management of IPR and dependencies

Review and manage the intellectual property rights for the developed product and used libraries and supporting components.

• Building awareness and recognition of the concerns and significance and impact
  
• IPR of components are known
• Dependencies and components are assessed and reviewed before and during their use within the product
• Documentation of IPR for the product and its components
• IPR and licenses are properly addressed within the product (license files are provided, used licenses are compatible)
  
• Management and review process, GÉANT IPR resources and support are consulted
  

2.5. Software and configuration changes

A version control system is used to manage artifacts. Changes of some elements of operated development, testing and production environments should be controlled, recorded and reversible. Rules for change management are defined and operationalised.

• Software and configuration management solutions are applied
• Process for management of multiple parallel versions of code, documentation and configuration artifacts
  
• Change review process exists
• Change review decisions and process are documented and managed

2.6. Build, delivery and deployment

Frequently performed procedures triggered by software development and changes are optimised and, where possible and appropriate, automated.

• Building packaging for all target platforms and environments.
• Incorporation of quality standards verification, with possible automation.
• Incorporation of testing, with possible automation.
  
• Automation configuration management system to ease deployments in line with deployment policies.

2.7. Management of implementation and development issues

Issues reported by stakeholders, developers or testers are documented, stored and managed in a controlled way using tools such as request and issue trackers. Possible characteristics include:

• Issues are managed without applying an established framework and best practices.
• There is a process for issues with categorization and handling through a defined workflow.
• There are clear and uniquely assigned responsibilities.
• Issue resolution performance, outcomes and times are tracked and analysed.
• There are management and maintenance of issue categories, attributes and workflow.

3. Quality assurance

Quality assurance activities provide a general and integral quality-focused perspective, across all target areas and shared concerns such as maintainability, reliability, security etc. It is focused on the delivery of a quality system, based on the established requirements and specification with the stakeholders.

Quality should be considered early and embedded into requirements, planning, design, costs, internal culture, ethics, managerial approaches and incentives for the team members. It should make sure that the agreed parameters of quality remain in the focus of the development team and are the subject of tracking and evaluation.

Quality assurance should also build assurances and controls for the software and processes that document them and ensure that quality-related claims are satisfied.

3.1. Management of risks, threats and vulnerabilities

Identify and analyse risks, threats and vulnerabilities: Identification of risks, threats and vulnerabilities is started upfront and regularly reviewed during development.

The identified risks are recorded and tracked through a risk register that is shared with the stakeholders.

3.2. Quality assurance planning

Quality assurance activities are planned. The plan is updated, based on the risks identified during the development of the project.

This plan should also define how new requests or risks updates from stakeholders are handled.

3.3. Determination of relevant quality characteristics

Identify relevant quality characteristics, based on the risk analysis, identified requirements, quality needs, and the actual work process.

Quality standards for the produced artifacts are identified (if available) or defined.

3.4. Quality assurance verification criteria

For each requirement and relevant performance or quality characteristic, verification criteria are defined and expressed in a measurable way and made SMART, covering key aspects of all target areas and processes.

This specific goal relates to the planning and design of criteria, but not to the actual testing. The established criteria may be applied on to software, the team or the environment (e.g. used tools).

Some of the quantitative criteria may also become quality indicators.

3.5. Verification procedures and environments

Testing and verification procedures are set up:

• Plans for tests, peer reviews or other verification procedures are established.
  
• Artifacts subject to review are identified.
• Testing environment is established and maintained.
• Test cases, scenarios and data are designed and developed.
• It is defined how successful or failed verification are distinguished, solutions confirmed and regressions avoided.
  
• Responsibilities are set and upheld.

3.6. Verification and actionable recommendations

Verification of results by assessing the relevant artifacts such as code, documentation, executables, expected and actual test outcomes and outputs of other verification procedures. Ensuring that the validation outputs are useful in the rectification of the product and the development process in order to adequately support individual corrections, but also to enable learning from mistakes and reduce the failure rates.

• Perform reviews, audits, inspections or tests, employ analytical tools and produce logs and tool outputs and reports in accordance with the plan.
• Analyse the produced outputs.
• Review and, if needed, reassess the risks.
• Record issues and link them to tests or corresponding locations in tools outputs so that that dealing with identified issues could be tracked.

3.7. Monitoring of quality parameters

Continual and periodic reviews and tracking of established quality parameters and criteria for identification of degradation or improvement of quality parameters.

• Continual monitoring of whether the parameters are within planned or expected boundaries.
• Periodic internal reviews of the quality parameters by the development team.
  
• Periodic reporting on the state of QA.
• Adjust the QA processes to address the trends or changes in quality parameters.
  

3.8. Validation of product outcomes and quality

Review the achieved results and related QA activities with stakeholders.

3.9. Retrospection in quality assurance processes

Based on the QA activities (reviews and tests), retrospection sessions are conducted with a focus on improvement and optimisation of the development process and overcoming or avoiding identified issues in the future.

• Reviewing and optimizing the process.
• Reviewing and improving the testing and verification procedures.
  
• Extracting and capturing the knowledge.
  
• Reviewing related practices for further optimization and improvements.

4. Team organisation

4.1. Team skillset management

Team members' skills and knowledge are known, used, improved in line with the needs of the work, and spread to others. 

Duties of team members are aligned with their knowledge and experience.

Plan of training and knowledge building for the software development team exists. Diversification and capture of experience, expertise and knowledge through collaboration, tutoring and role switching. People are proactively prepared for their forthcoming assignments and possible changes within the team.

4.2. Effective communication channels

There are defined communication channels (on-line/off-line, text/voice/VC, whiteboards, dashboards, collaborative editing tools) for specific purposes that are known and available to respective users. These channels cover both internal (in-team) and external (with stakeholders) communication.

The critical channels are backed up. Communication on selected channels can be archived and processed.

The verbosity, disturbance by notifications, visibility and availability of ongoing and past conversations are adequate.

The established channels support handling of:

• Schedules and calendars
• Coordination, task and assignments
• Official statements and public commitments
• Operational communication
• Internal discussions

4.3. Decision-making in the team

There is an agreed, approved and effective method of making decisions within the team.

The decision-making process incorporates the feedback and suggestions from the members of the team. There is an effective way to influence the new decisions or rectify those already made.

Team members' work is usually within the preset boundaries of performance and they have an adequate level of autonomy.

Decisions made by the team and their rationales are recorded.

4.4. Schedules and assignments management

Individual plans, commitments and assignments of team members are managed, so that the work and the use of resources are conducted in an optimal way.

Information is disseminated using agreed communication channels.

Teams are effectively aligning the planned work with the available resources and time and adapting to disturbances or more precise needs.

5. Software maintenance

The focus of the software development team is proper planning and validation of the changes that will be conducted within maintenance, as they are additional concerns that are not directly related to software development. The issues are resolved with explanations, the use of alternative paths or workarounds.

The development of actual maintenance solutions and their verification are conducted within Development and Implementation and Quality Assurance target areas.

5.1. Planning and designing for maintainability

Maintenance-related requirements should be captured with other customer and stakeholder requirements, and they should be initiated during development.

Even if maintainability is not of concern, that decision has to be decided and explicitly stated. The decisions on maintainability affect the related QA parameters.

5.2. Handling of maintenance issues

The development team should periodically

• Manage the inflow of maintenance-related requests and faults.
• Identify maintenance issues and those that could hinder system maintenance.
• Review whether the received issues are captured in a clear, relevant, addressable and, if possible, reproducible way and prioritise them.
  
• Monitor and review long-standing issues reported in the issue tracker to in order prune or prioritise them.
• Review the backlog and related issues with an overall perspective, and group the related items together.
• Identify latent faults or root causes of recurring issues or groups of related issues or ones requiring a major refactoring/an architectural change.
• Identify maintenance constraints imposed by the ongoing systems usage, users or intervention and support capabilities.
  

If there is dedicated a help or service desk, it may use its own user-facing ticketing system, the items of which are linked to the developers' issue tracking system.

Some maintenance modifications respond to the need to establish additional interfaces to other systems, adapt to a different platform or environment, optimize existing functions, improve security, prevent performance degradation, or prepare the system for retirement.

Through this specific goal, technical debt is collected and reported. It may be related to the usage of legacy components or platforms or software maintainability.

5.3. Assessment of modification options

Consider, review and assess available options and choose what to do:

• Outline the options for maintenance solutions.
• Define and weigh the alternatives: a workaround may suffice, it may need to be later replaced with a more permanent solution requiring a major refactoring or intersecting intervention.
• Consider the consequences and side effects of alternatives.

• Determine who should implement and evaluate them; the involved may include developers, operations, support, customers, end-users…

• Select those that are most appropriate in current circumstances, considering the impact and cost of the issues they address and the complexity, cost and impact of solutions.
• Determine whether the solution requires the involvement of the development team, and schedule its development and addressing.
• Check whether maintenance constraints are satisfied and how the selected approach could impact the production systems.

The development team should not be immediately made responsible for addressing maintenance issues, but often needs to be consulted while they are addressed. When the problem is passed to them, they make the changes into the software that distributed as patches (out-of-band releases) or delivered through the regular maintenance release cycle. Some changes, in particular those addressing technical debt, could be thoroughly investigated and planned and put in the roadmap.

5.4. Implementation of modifications

Develop and deliver maintenance changes into the supported environment in a controlled, non-damaging, non-disturbing and reversible way that meets maintenance constraints, especially considered for live/operational systems. Therefore, in addition to what is usually done in software development, there may be some additional steps and checks that coordinate the work of development, operations and support teams, obtain customer and user confirmations, and address their concerns and constraints.

• Set up channels to operations, customers or end-users, agreements between the teams, and adjust the development team's procedures and tools that are used in Development and Implementation.
• Coordinate with the operations and support.
• Produce and verify modifications (see the "Design and implementation" Target Area)
  
• Review and accept/reject the modification; although it was verified during development, it should be validated from at the operational, maintenance and support level before the deployment
• Plan deployment and teams' availability, so that the possible disruption caused by modifications and duration of post-modification corrective actions are minimised.
  
• Deliver and integrate modifications into the supported system.
• If needed, revert (rollback) conducted modifications.

Technical debt is often handled separately from standard changes or emergency changes, as the related modifications may require changes at a number of places and may impose greater risks and have a larger impact on the operation of the system. Therefore, such changes are often separately planned within the roadmap, handled in separate branches, and may even include an operating environment, piloting period or early life support of their own, and include dealing early adopters and gradual migration of users. All this may result in additional requirements and concerns for software teams.