...

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.

Requirements engineering

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.

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, 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.

Analysis of requirements and their dependencies

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].

Traceability of requirements

There is a process for tracking dependencies from the needs to the requirements and among requirements.

Validation of requirements

Requirements are validated by stakeholders whether they properly reflect their needs and expectations.

Design and implementation

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.

...

[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.]

Handling of design alternatives

The design alternative solutions are identified, elaborated and analyzed.

...

• People tend to focus on low hanging fruits: of the shelf ones with perceived minimal risks despite low merits or that have been used before, as considering novel solutions requires much more effort.
• Unnecessary or unneeded optionalities present in one alternative may bias the judgement.
• Need to limit exploration period. Promise of several available and possibly even more undiscovered alternatives may lure us into an endless search. Searching for a silver bullet may reduce the available implementation time. There is a similar situation with two alternatives that are equally attractive, which results in an unreasonable vacillation.
• The comparison may be biased by the contrasts of alternatives (e.g. making one dull mass the other more attractive (https://www.linkedin.com/pulse/design-alternatives-madhu-parthasarathy), the comparison is based on a series of (pairwise) per-attribute comparisons (resulting in discarding after being worse in one or a number of collations), and not on the total values (https://www.sciencedirect.com/science/article/pii/S0010027714000456).

Documentation development and management

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.

• 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. (Generic hints: for all categories/document, for some, no responsibilities… By rules/roles, written (including tickets ownership), verbal, by default, assumed… How regularly you maintain the documentation, what triggers updates and how frequent are they? E.g., what is related or triggered by releases, requests, issues or is continuously updated…)
  
• Advanced: Parts of documentation that directly reflect the corresponding development, testing, configuration, or maintenance artifacts are automatically built from them (illustrative simple examples: conversion to PDF, Javadoc creation, publishing).
  
• Advanced: The produced documentation enables to evoke and detail all key events of product development and evolution (reports on the small events tracked by the tools that support the daily work do not qualify for this).

Technology assessment, validation and verification

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

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
  

Software and configuration changes

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.

• Software and configuration management solutions are applied, but there are no established policies and processes
• Process for management of multiple parallel versions of code, documentation and configuration artifacts
• Process for collaboration in a team
  
• Change review process exists
• Change review decisions and process are documented and process managed

Build, delivery and deployment

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

...

Paweł Sierota Please add some related notes on Bamboo here and elsewhere where appropriate, without specifically referring to Bamboo.

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.

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… 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.

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 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.

Quality assurance planning

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.

Determination of relevant quality characteristics

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.

Quality assurance verification criteria

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.

...

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).

Verification procedures and environments

Set up testing and verification procedures and testing environment:

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

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 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.

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.

...

It is not sufficient to have just a statement on QA and then disregard the emergent trends or actual quality parameters values.

Validation of product outcomes and quality

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/

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 avoidance of identified issues.

• Review and optimizations of the process.
• Review and improvement of testing and verification procedures.
  
• Extract and capture knowledge.
  
• Review related practices for further optimization and improvements.

Team organisation

Team skillset management

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

...

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.

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.

...

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

Decision-making in the team

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

...

Decisions made by the team and their rationales are recorded.

Schedules and assignments management

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

• Use of agreed communication channels and planning and coordination tools
• Teams are effectively aligning the planned work with available resources and time and adapting to disturbances or more precise needs.

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 sometimes resolved with explanations, use of alternative paths or workarounds.

...

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.

Planning and designing for maintainability

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.

Handling of maintenance issues

The development team should timely but also periodically:

...

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.

Assessment of modification options

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

...

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.

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.

...

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.

Software product management (DRAFT - only partially in WP9T2 scope)

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.

...

• 6.2 Market research
• 6.2 Concept or vision development
• 6.2 Participation in idea creation and generation
• 6.3 Collection and prioritisation of business requirements
• 6.2 Gathering and analysis of other offerings, user needs and market gaps and niches in order to develop and prioritise business or product requirements
• 6.3 Aligning the product with the market
• 6.3 Constructing and optimising the value chain
• 6.1 Interacting with or participating in or acting as marketing, sales, logistics, finance, procurement, customer service/service desk, installation, distribution...
• 6.3 Translation of business and marketing requirements to product and software requirements
• 6.3 (Participation in) management of business cases
• 6.3 (Participation in) management of product roadmap (related but different from software roadmap)
• 6.5 Soliciting/elicitating and analysing customer feedback and suggestions
  
• 6.5 Comparative analysis of the performance of the product on the market against competitive products
• 6.1 Contribution to product/service portfolio management

Liaison with product owner, sponsor or governing body (name this entity for GN?)

How to keep the product and team aligned with programme/organisational management. High-level planning, reporting and monitoring.

Market research, analysis and positioning

Strategic management

See above. Could limit to initial strategy and positioning, adjustments, opportunity discovery, product/market segmentation, roadmap management.

Dissemination and promotion

Including marketing strategy

Collecting customer feedback and product tuning

To maximise impact and value

...