...

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.

Analysis of requirements and their dependencies

The expectations and needs are transformed into requirements by considering the context, their objectives and feasibility and context. Requirements are analysed with respect to their relationships and inter-dependencies and whether they truly properly reflect the specified needs. As people seldom know what they want until they get what they ask for, it may require the use of various information, idea and requirements gathering techniques and even creation of models or prototypes.

Traceability of requirements

Traceability of requirements

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

Validation of requirements

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

Design and implementation

The technical governance the activities 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 Elements of coding or software construction, encompassing the whole entire agile development lifecycle , (unless directly 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.

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

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.
• There is a common and often used approach or procedure to investigate alternatives with clear.
• Evaluation and comparison results are recorded.
• The chosen solution and alternatives are reassessed upon changing needs, understanding, issues, obsolescence, technological or architectural advancements.

...

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

...

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.

...

Management of IPR and dependencies

...

• 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
  

...

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

...

• Building packaging for all target platforms and environments.
• Incorporation of quality standards verification, with possible automation.
• Incorporation of testing, with possible automation. (Quality checks and tests are performed and automated where and when appropriate.)
  
• Automation configuration management system to ease deployments in line with deployment policies.

...