Module 6 - SCM, QA & Maintenance

Risk Analysis & Management: Risk Mitigation

Risk is a potential problem that might or might not happen, concerning future happenings and involving change and uncertainty. Software risks involve two primary characteristics: Uncertainty (there are no 100% probable risks) and Loss (unwanted consequences will occur if the risk becomes reality).

Risk Analysis in project management is a sequence of processes to identify factors that may affect a project's success. It is a pro-active rather than a reactive process. Risk Management aims at reducing the impact of all kinds of risks by identifying, analyzing, and managing them to avoid disaster or heavy losses.

Risk Mitigation / Avoidance

If a software team adopts a proactive approach to risk, avoidance is always the best strategy. Risk Mitigation means preventing the risks from occurring. The following steps are taken for mitigating risk:

Monitoring and Management Plan (RMMM)

Risk Monitoring

In the risk monitoring process, the project manager must monitor several factors as the project progresses:

• The approach or behavior of team members as the pressure of the project varies.
• The degree to which the team performs with the spirit of "team-work" and cooperation.
• The type of problems that are occurring.
• Availability of jobs within and outside the organization (to monitor turnover risk).

The primary objectives of risk monitoring are:

1. To assess whether the predicted risks do, in fact, occur.
2. To ensure that risk aversion/mitigation steps defined for the risk are being properly applied.
3. To collect information that can be used for analyzing future risks.

Risk Management

Risk management and contingency planning assume that mitigation efforts have failed and that the risk has become a reality. If the project manager successfully applied mitigation steps earlier, managing the risk becomes much easier.

The RMMM Plan

The RMMM plan may be a part of the overall software development plan. It documents all work performed as part of risk analysis and is used by the project manager. Once documented and the project begins, risk mitigation (problem avoidance) and monitoring (project tracking) steps commence.

Drawbacks of RMMM:

• Incurs additional project costs and takes additional time.
• For larger projects, implementing an RMMM may itself turn out to be a tedious project.
• Does not guarantee a risk-free project; risks may still come up after delivery.

Risk Information Sheet (RIS)

Some software teams do not develop a formal RMMM document. Instead, each risk is documented individually using a Risk Information Sheet (RIS). In most cases, RIS is maintained using a database system so that creation, priority ordering, and searches can be accomplished easily.

Standard RIS Components
Identification	Risk ID, Date, Probability (%), and Impact level (e.g., high).
Description	A clear statement detailing the exact risk.
Refinement / Context	Specific sub-conditions or contexts that make the risk likely.
Mitigation / Monitoring	The actionable steps taken to prevent the risk and track it.
Management / Contingency / Trigger	Calculated Risk Exposure (RE), backup plans, and the specific date/event that "triggers" the contingency plan.
Administrative	Current Status, Originator of the report, and the person Assigned to handle it.

Quality Concepts

Quality is a complex concept that means different things to different people and is highly context-dependent. It can be understood through five different views:

Software Quality Management (SQM)

Software Quality Management guarantees that the required level of software is achieved to satisfy users. SQM includes three main activities:

• Quality Planning: Choosing applicable procedures, actions, and standards for a project.
• Quality Assurance (QA): A planned and systematic pattern of activities to provide a high degree of confidence in the product's quality, consisting of reporting and auditing functions.
• Quality Control: A series of inspections, reviews, and tests used throughout the software process to ensure each work product meets requirements. It includes a feedback loop to tune the process and minimize defects.

Cost of Quality

The cost of quality is the total cost required to obtain quality in the product and conduct quality-related activities. It is divided into three categories:

• Prevention Cost: Required for conducting quality planning, formal technical reviews, test equipment, and training.
• Appraisal Cost: Required for gaining insight into the product, including in-process/inter-process inspection, maintenance, and testing.
• Failure Cost: Required to remove defects before delivering it to the customer.
  • Internal Failure Cost: Cost of defects occurring before delivery (e.g., rework, repair, failure mode analysis).
  • External Failure Cost: Cost of defects occurring after delivery to the customer (e.g., complaint resolution, product returns, help line support, warranty work).

McCall's Quality Model (1977)

This model classifies software requirements into 11 software quality factors, organized into three primary product quality categories:

Category	Focus	Quality Factors
1. Product Operation	Requirements directly affecting the daily operation, performance, and usage of the software.	Correctness: Meets requirements spec. Efficiency: Hardware resources/code needed. Integrity: Controls unauthorized access. Reliability: Performs without failure. Usability: Effort required to learn/operate.
2. Product Revision	Requirements for testing, maintenance, and future flexibility.	Maintainability: Effort to fix errors. Flexibility: Effort to improve the program. Testability: Effort to verify requirements.
3. Product Transition	Allows the software to adapt to changing environments, platforms, or technologies.	Portability: Effort to transfer to a new platform. Re-usability: Extent code can be reused elsewhere. Interoperability: Effort to integrate with other systems.

Software Quality Assurance (SQA) & Metrics

Software Quality Assurance (SQA) is the process in which conformance to the requirements of the product is made. It is composed of a variety of tasks associated with two different constituencies:

• Software Engineers: Perform the technical work, develop the product, and address quality by applying technical methods, conducting formal technical reviews, and performing well-planned software testing.
• SQA Group: An independent group whose role is to assist the software team in achieving a high-quality end product through planning, oversight, record keeping, analysis, and reporting.

Role of the SQA Group

The SQA group performs (or facilitates) the following key activities:

The SQA Plan

The SQA Plan provides a road map for instituting software quality assurance, serving as a template for SQA activities. The IEEE standard recommends a structure that identifies:

• Purpose and scope of the plan.
• Description of all software engineering work products.
• Applicable standards and practices.
• SQA actions, tasks, reviews, and audits.
• Tools and methods supporting SQA.
• Software Configuration Management (SCM) procedures.
• Methods for safeguarding SQA records.
• Organizational roles and responsibilities.

Software Quality Metrics

To produce high-quality software, project managers evaluate the software using quality metrics to improve QA and control activities. These metrics include work product errors per function, errors found per review hour, and errors found in testing.

Parameters for Measuring Software Quality

Metric	Description
1. Code Quality	Measures both quantitative (lines of code, complexity, bugs rate) and qualitative (readability, clarity, maintainability) aspects to ensure bug-free code.
2. Reliability	Checks if the software provides exact service at the right time in different conditions.
3. Performance	Determines if the software fulfills user requirements by analyzing time and resource utilization.
4. Correctness	Checks whether the system is working correctly without any error, giving the degree of service each function provides.
5. Integrity	Measures how easy it is to integrate with other software and the control against unauthorized software (cyberattacks).
6. Usability	Checks whether the program is user-friendly and if the end-user is happy using it.
7. Maintainability	Includes time required to adapt to new features (Mean Time to Change), and performance in changing environments.
8. Security	Assures there are no unauthorized changes or fear of cyber attacks when the software is in use.

Software Safety & Six Sigma

Software Safety is a QA activity where potential hazards (which may bring total system failure) are identified and assessed early so they can be eliminated or controlled. Steps include identifying hazards, using techniques like fault-tree analysis or Petri-net models to assign severity, specifying safety requirements, and indicating the software's role in managing undesirable events.

Six Sigma is a methodology for producing high-quality output where 99.99966% of all products are free from defects. It uses two primary methodologies:

• DMAIC (Define, Measure, Analyze, Improve, Control): Used to enhance an existing business process.
• DMADV (Define, Measure, Analyze, Design, Verify): Used to create new product designs or process designs.

Formal Technical Reviews (FTR)

A Formal Technical Review (FTR) is a software quality control activity performed by software engineers. It encompasses a class of reviews that includes walkthroughs, inspections, round-robin reviews, and other small-group technical assessments of software.

Steps in a Formal Technical Review

Each FTR is conducted as a meeting and is considered successful only if it is properly planned, controlled, and attended.

1. The Review Meeting: Focuses on a specific (and small) part of the overall software. It is constrained by three rules:
   • Involvement should be between 3 and 5 people.
   • Advance preparation should take no more than 2 hours of work per person.
   • The review meeting duration should be less than two hours.
2. Decision Making: At the end of the review, attendees must sign off on one of three decisions:
   • Accept the product without any modification.
   • Reject the product due to serious errors (requires another review once corrected).
   • Accept provisionally (minor errors are encountered and must be corrected, but no additional review is required).
3. Review Reporting and Record Keeping: The reviewer actively records all issues. A formal technical review summary report is prepared answering three questions: What was reviewed? Who reviewed it? What were the findings and conclusions?.

FTR Guidelines

Guidelines must be established in advance, distributed, agreed upon, and followed to keep the review on track:

• Review the product, not the producer (manufacturer).
• Take written notes for record purposes.
• Limit the number of participants and insist upon advance preparation.
• Develop a checklist for each product likely to be reviewed.
• Allocate resources and schedule time for FTRs.
• Conduct meaningful training for all reviewers.
• Review earlier reviews which serve as a base for the current one.
• Set an agenda and maintain it.
• Limit debate and rebuttal; do not attempt to solve every problem noted during the meeting.

Walkthroughs vs. Inspections

An FTR generally takes the form of either an informal walkthrough or a highly structured inspection.

Software Reliability

Software Reliability is defined in statistical terms as "the probability of failure-free operation of a computer program in a specified environment for a specified time". A failure in this context indicates non-conformance to the software requirements.

Measures of Reliability and Availability

Reliability is typically evaluated using specific time-based metrics:

Software Configuration Management (SCM)

In Software Engineering, Software Configuration Management (SCM) is a set of activities carried out for identifying, organizing, and systematically controlling changes throughout the life cycle of a computer system. The primary goal is to increase productivity with minimal mistakes and ensure changes are properly implemented and reported.

Software Configuration Items (SCI)

A software configuration item is information created as part of the software engineering process. The elements that comprise all information produced are collectively called a software configuration. Examples of SCIs include:

• Computer Programs: Source programs and executable programs.
• Documents: Technical manuals, user manuals, project plans, and design documents.
• Data: Program components, external data, and file structures.

SCIs must be separately named and identified as objects using an object-oriented approach. These objects are categorized as Basic Objects (a single unit of information, like a part of source code) and Aggregate Objects (a collection of basic/essential objects, like a Design Specification).

The SCM Process & Key Tasks

To prevent uncontrolled change from causing chaos in a well-running project, the SCM process involves several critical tasks:

Note: The remaining critical SCM tasks—Change Control and Version Control—are detailed in the next section.

Version Control & Change Control

Change Control Management

Change control is a procedural method which ensures quality and consistency when changes are made to a configuration object. While changes may enhance system capabilities, uncontrolled changes create a lot of chaos. Requests for change may arise due to detecting bugs, improving processes, adding features, business needs, or expanding the system's scope.

The "Checked-in" and "Checked-out" mechanism requires two critical elements:

Version Control

A version is an instance of a system which is functionally distinct in some way from other system instances. Version Control combines procedures and tools to manage different versions of configuration objects created during the software process. It implements four major capabilities:

• A project database that stores all relevant configuration objects.
• A version management capability that stores all versions of a configuration object.
• A make facility that enables the software engineer to collect all relevant configuration objects.
• The ability to construct a specific version of the software.

Change Sets & System Modeling

Version control systems establish a "Changes set"—a collection of all changes applied to a baseline configuration required to create a specific software version. It captures all changes to files, the reasons for changes, who made them, and when. This allows engineers to construct a version by simply specifying the named change set.

To accomplish this, a system modeling approach is applied, which contains:

• A template including a component hierarchy and build order describing how the system must be constructed.
• Construction rules.
• Verification rules.

Types of Software Maintenance

Software does not wear out or get tired, but it needs to be upgraded and enhanced to meet new user requirements. Software maintenance is the process of changing, modifying, and updating software after it has launched to keep up with customer needs, correct issues or bugs, and boost performance.

The Four Types of Software Maintenance

A given piece of software may undergo one or all of these maintenance types throughout its lifespan:

Re-Engineering

Software Re-Engineering is a software development process performed to improve the maintainability of a software system. It involves the examination and alteration of a system to reconstitute it in a new form, restructuring or rewriting part or all of a system without changing its functionality.

Advantages & Economics

Re-engineering positively affects software cost, quality, customer service, and delivery speed. The primary advantages over developing entirely new software are:

• Reduced Risk: New software development carries high risks (development, staffing, and specification problems) which re-engineering avoids.
• Reduced Cost: The cost of re-engineering is often significantly less than the costs of developing new software.

The Cost Benefit is calculated by evaluating the cost of maintenance (annual operation cost over the application's lifetime) against the cost of reengineering (predicted return on investment reduced by implementation costs and risks).

The Re-Engineering Lifecycle

A complete Software Re-Engineering lifecycle includes the following phases:

Reverse Engineering

Reverse Engineering is the process of taking apart an object to see how it works in order to duplicate or enhance it. In software, it involves reversing a program's machine code back into the source code using programming language statements. It is essentially a reverse SDLC model: designers look at the code to deduce the design, and from the design, they deduce the system specifications, moving from lower abstraction levels to higher ones.

Reasons for Reverse Engineering

Software and hardware are reverse-engineered for a variety of strategic, technical, and business reasons: