...

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

The Some of the quantitative criteria may also become quality indicators.

...

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.

...

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

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.

Retrospection in quality assurance processes

stakeholders.

Retrospection in quality assurance processes

Based on the QA activities (reviews and tests), 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 avoiding identified issues in the future.

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

...

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

...

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

...

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.

...

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.

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

Planning and designing for maintainability

Maintenance-related requirements should be captured within requirements along with other customer and stakeholder requirements. Their addressing , and they should be started initiated 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 explicitly stated. The decisions on maintainability imply or impose affect the related QA parameters.

...

The development team should timely but also 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 - these may be minor but previously improperly resolved, issues or ones requiring a major refactoring or /an architectural change.
• Identify maintenance constraints imposed by the ongoing systems usage, users or intervention and support capabilities.
  

...

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

...

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

• Outline the options for maintenance solutions options.
• Define and weight 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 individual 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, especially in particular 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

...

• 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 through Development and Implementation.(see the "Design and implementation" Target Area)
  
• Review and accept or /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, quickly 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. Such Therefore, 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.

...