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, but it is important not to take their supposed solution or solution method for problem description. Perceived needs are used to identify real needs, which are then clearly expressed, prioritised and selected and real, retained and achievable needs.
The expectations and needs are transformed into requirements while considering the context, objectives and feasibility. Requirements are analysed with respect to their relationships and inter-dependencies and whether they truly reflect the specified needs. As people seldom know what they want until they get what they ask for, may require the use of various information, idea and requirements gathering techniques and even creation of models or prototypes [https://www.sebokwiki.org/wiki/Stakeholder_Needs_and_Requirements].
There is a process for tracking dependencies from the needs to the requirements and among requirements.
Requirements are validated by stakeholders whether they properly reflect their needs and expectations.
The technical governance the activities that are usually associated with software design, development and delivery; the relevant practices, elements of development environment and tools used by software developers.
Various selected elements of coding or software construction, encompassing the whole agile development lifecycle, unless directly 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.
[Capturing, documenting and publishing of the development environment, key resources and tools is also a significant topic here. Presumably, there is a concern that this segment is currently being addressed with GÉANT Software Catalog so therefore there no need for the SMM to emphasise this at the current point.]
The design alternative solutions are identified, elaborated and analyzed.
Notes about selecting alternatives and making choices in general:
The technical solution is supplemented and accompanied by adequate technical documentation that justifies and describes the decisions made at different stages of system elaboration and is capturing and providing the information to developers, users, maintainers and key stakeholders. 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 and successfully serves the intended purpose. Benefits of the capabilities outweigh the costs associated with its use. For example, this can be done by a small-scale pilot project. These technologies include used underlying/supporting platforms, modules, libraries, implementations, solutions...
Note: there are some commonalities with 2.1 on making choices
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 do not have to be versioned in an automated way, but still 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.
Candidates for further elaboration:
Configurations of all relevant environments and deployments are adequately managed.
Delivery may be combined with deployment?
Deployment and management of instances are closely related
Implementation hints
Details on what is available in term of tools, guidance or practices. One tool can support several target areas and specific goals.
Paweł Sierota Please add some related notes on Bamboo here and elsewhere where appropriate, without specifically referring to Bamboo.
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… It is focused on the delivery of a quality system, based on the established requirements and specification with the stakeholders. It 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 for the following aspects of development:
The identified risks are recorded and tracked through a risk register. It is shared with the stakeholders, and they are informed about risks that could not be tracked or managed by the team, and they are made responsible for updates on them.
Plan quality assurance activities: 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, identified requirements and the actual work process, quality-related characteristics that are relevant for the project are identified.
Quality standards for the produced artifacts are identified (if available) or defined and captured.
Define QA 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. Verification upon these criteria should ensure that the system is in line with the specifications and requirements that were captured and agreed.
This specific goal relates to the planning and design, but not the actual testing of QA parameters. The established criteria may be applied on to software, the team or the environment (e.g. used tools). They may be based on:
At certain levels, quantitative requirements such as those related to performance also become indications of quality. Similarly, characteristics that are directly linked to quality, such as function or compliance, may be measured with quantitative metrics (e.g. percentage of requirements that were met).
Set up testing and verification procedures and testing environment:
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 failure rates.
Continual and periodic reviews and tracking of established quality parameters and criteria for identification of degradation or improvement of quality parameters.
It is not sufficient to have just a statement on QA and then disregard the emergent trends or actual quality parameters values.
Review the achieved results and related QA activities with the customer and other stakeholders, on the specific parameters of interest to them and whether the system is in line with their expectations or, even better, needs.
NOTE: There are very useful illustrations at https://www.easterbrook.ca/steve/2010/11/the-difference-between-verification-and-validation/
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 avoidance of identified issues.
Team members' skills and knowledge are known, used, improved in line with the needs of the work, and spread to others.
Identify team skills and establish developer/member skill profiles, as there is a need for managing the skill set of the team, i.e., identification of strengths and weaknesses, planning the development of the skillset and accounting for possible changes due to staff turnover.
Duties of team members are aligned with their knowledge and experience.
Plan of training and knowledge building for the software development team. 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 purposes and actual uses of communication channels do not overlap.
The verbosity, disturbance by notifications, visibility and availability of ongoing and past conversations are adequate. All who should be involved or informed are usually involved in the conversations, with rate omissions or excessive inclusions.
The participants have the means to effectively convey their needs, ideas, results, problems and complaints.
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 positively 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 use of resources are conducted in an optimal way.
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 sometimes resolved with explanations, use of alternative paths or workarounds.
The development of actual maintenance solutions (those that are passed to software teams) and their verification are conducted within Development and Implementation and Quality Assurance target areas.
Tracking of discrepancies and validation of maintenance solutions are mostly done by operations and are there outside of SMM scope, except for the parts that concern development teams and are therefore integrated into their tools that are regularly used in Development and Implementation.
Maintenance-related requirements should be captured within requirements along with other customer and stakeholder requirements. Their addressing should be started during development. Predelivery maintenance may increase code testability and maintainability and develop and establish instruments, probes, tools, or infrastructure that will support maintenance and reduce the maintenance effort.
Even if maintainability is not of concern, that decision has to be decided and stated. The decisions on maintainability imply or impose the related QA parameters.
The development team should timely but also 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, perfect 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, especially those addressing technical debt, could be thoroughly investigated and planned and put in the roadmap. The recurring issues or difficulties in their addressing are often an indication of technical debt.
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. Such changes are therefore 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.
A number of aspects of software product management involve the software development team. This TA is traditionally not a part of the software governance responsibilities of software development teams, but as they are getting a more pronounced role in maximising the revenue or value of the software-driven product throughout its lifecycle by working together or interfacing with the product management business function. In the GN context, the role of the software project team is in this area is determined by the level of the involvement of the dedicated project and product management personnel, which may be limited for smaller software projects, but also the capacities of the software leadership in this field. Furthermore, here described subtopics may be strongly linked to the more traditional duties of software teams described in the preceding target areas.
See for inspiration:
Topics that could be placed into SGs:
How to keep the product and team aligned with programme/organisational management. High-level planning, reporting and monitoring.
See above. Could limit to initial strategy and positioning, adjustments, opportunity discovery, product/market segmentation, roadmap management.
Including marketing strategy
To maximise impact and value
