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.
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.
Expectations of the stakeholders (expressed in any way) are identified. Typically, they are further elaborated and detailed by domain experts and representative users.
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.
There is a process for tracking the dependencies from the needs to the requirements (vertically) and among the requirements (horizontally).
Requirements are validated by stakeholders to verify if they properly reflect their needs and expectations.
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.
The design alternative solutions are identified, elaborated and analyzed.
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.
Design/implementation: use cases, ideas, decisions, software architecture, technical solutions, code
Operations: installation, administration
Usage: end-user installation, end-user usage
Documentation records and elaborates technical decisions made.
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.
Review and manage the intellectual property rights for the developed product and used libraries and supporting components.
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.
Frequently performed procedures triggered by software development and changes are optimised and, where possible and appropriate, automated.
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:
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.
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.
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.
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.
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.
Testing and verification procedures are set up:
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.
Continual and periodic reviews and tracking of established quality parameters and criteria for identification of degradation or improvement of quality parameters.
Review the achieved results and related QA activities with stakeholders.
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.
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.
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:
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.
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.
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.
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.
The development team should periodically
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.
Consider, review and assess available options and choose what to do:
Determine who should implement and evaluate them; the involved may include developers, operations, support, customers, end-users…
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.
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.
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.