UNIT-5

Metrics for Process and Products:

 Product metrics measure the success of the products themselves, while process metrics
describe the quality and functionality of software under development
 It describes the characteristics of the product such as size, complexity, design features,
performance, and quality level.

 Process metrics define quantitative and qualitative measures related to a process, its
performance and its evolution. These characteristics can be used to improve the
development and maintenance activities of the software.

 Project metrics describe the project characteristics and execution. Examples include the
number of software developers, the staffing pattern over the life cycle of the software,
cost, schedule, and productivity.

Software Quality: The overall goal of software engineering is to produce a high-quality system,
application, or product within a time frame that satisfies a market need. To achieve this goal,
software engineers must apply effective methods coupled with modern tools within the context
of a mature software process.

Software quality metrics:

Conformance to explicitly stated functional and performance requirements, explicitly

documented development standards, and implicit characteristics that are expected of all
professionally developed software.
Factors that affect software quality can be categorized in two broad groups:

1. Factors that can be directly measured (e.g. defects uncovered during testing)
2. Factors that can be measured only indirectly (e.g. usability or maintainability)

The measures of software quality are correctness, maintainability, integrity, and

usability. These measures will provide useful indicators for the project team.

Correctness: Correctness is the degree to which the software performs its required
function. The most common measure for correctness is defects per KLOC, where a
defect is defined as a verified lack of conformance to requirements.
 Maintainability: Maintainability is the ease with which a program can be corrected if
an error is encountered, adapted if its environment changes, or enhanced if the
customer desires a change in requirements. A simple time-oriented metric is mean-
time-to-change (MTTC), the time it takes to analyze the change request, design an
appropriate modification, implement the change, test it, and distribute the change to
all users.

Integrity: Attacks can be made on all three components of software: programs, data,
and documents. To measure integrity, two additional attributes must be defined.
Threat and Security
Threat is the probability (which can be estimated or derived from
empirical evidence) that an attack of a specific type will occur within a given time.
Security is the probability (which can be estimated or derived from empirical
evidence) that the attack of a specific type will be repelled. The integrity of a system
can then be defined as

Integrity = Σ [1-(threat x (1- security))]

Usability: Usability is an attempt to quantify user-friendliness.

Risk management:
What is a Risk? --- A risk is a probable problem- it might happen or it might not.
There are two main characteristics of a risk
1. Uncertainty- the risk may or may not happen that means there are no 100% risks.
2. Loss – If the risk occurs in reality, undesirable result or loss will occur.

Reactive and Proactive Risk Strategies: What’s the Difference?

Reactive risk management: [to be ready to react or respond to something]

 Preventing potential risks from becoming incidents
 Mitigating damage from incidents
 Stopping small threats from worsening
 Continuing critical business functions despite incidents
 Evaluating each incident to solve its root cause
 Monitoring to assure that the incident does not re-occur.

Proactive risk management: [proactive, make things happen, instead of waiting for them to
happen]
  Identifying existing risks to the enterprise, business unit, or project
 Developing a risk response
 Prioritizing identified risks according to the magnitude of their threat
 Analyzing risks to determine the best treatment for each
 Implementing controls necessary to prevent hazards from becoming threats or incidents
 Monitoring the threat environment continuously
Risk management is a sequence of steps that help a software team to understand,
Analyze and manage uncertainty. Risk management consists of:

1. Risk Identification
2. Risk analysis
3. Risk Planning
4. Risk Monitoring

There are mainly 3 classes of risks that may have an effect on software Project.

1. Project Risks
2. Technical Risks
3. Business Risks

Project Risks: Threaten the project plan. That is, if project risks become real, it is likely that
project schedule will slip and that costs will increase.

Technical risks: Threaten the quality and timeliness of the software to be produced. If a
technical risk becomes a reality, implementation may become difficult or impossible. Technical
risks identify potential design, implementation, interface, verification, and maintenance
problems.

Business risks: Threaten the viability of the software to be built. Business risks often jeopardize
the project or the product. Few business risks are :

 Building a excellent product or system that no one really wants (market risk),
 Building a product that no longer fits into the overall business strategy for the company
(strategic risk),
 1. RISK IDENTIFICATION:

Risk identification is a systematic attempt to specify threats to the project plan. There are two
distinct types of risks.

Generic risks and product specific risks.

Generic risks are a potential threat to every software project.

Product-specific risks can be identified only by those with a clear understanding of the
technology, the people, and the environment that is specific to the project that is to be built.

Risk Components and Drivers:

The risk components are defined in the following manner:

Performance risks the degree of uncertainty that the product will meet its requirements and be
fit for its intended use.

Cost risks the degree of uncertainty that the project budget will be maintained.

Support risks the degree of uncertainty that the resultant software will be easy to correct, adapt,
and enhance.

Schedule risks the degree of uncertainty that the project schedule will be maintained and that the
product will be delivered on time.

The impact of each risk driver on the risk component is divided into one of four impact
categories— negligible, marginal, critical, or catastrophic [a tragic event]

RISK PROJECTION

Risk projection, also called risk estimation, attempts to rate each risk in two ways—the
likelihood or probability that the risk is real and the consequences of the problems associated
with the risk, should it occur.

The project planner, along with other managers and technical staff, performs four risk projection
activities: establish a scale that reflects the perceived likelihood of a risk, delineate the
consequences of the risk, estimate the impact of the risk on the project and the product, and note
the overall accuracy of the risk projection so that there will be no misunderstandings.
 Risk Probability Impact RMMM

Risk Mitigation,
Monitoring and
Management.

Three factors affect the consequences that are likely if a risk does occur:
1. Nature,
2. Scope,
3. Timing.

 The nature of the risk indicates the problems that are likely if it occurs.
 The scope of a risk combines the severity (just how serious is it?) with its overall
distribution.
 Finally, the timing of a risk considers when and for how long the impact will be felt.

The overall risk exposure, RE, is determined using the following relationship
RE = P x C
Where P is the probability of occurrence for a risk, and C is the cost to the project should the risk
occur.

Risk refinement:

Process of restating the risks as a set of more detailed risks that will be easier to mitigate,
monitor, and manage. One way for risk refinement is to represent the risk in <condition-
transition-consequence> (CTC) format is a good representation for detailed risks.

The RMMM Plan:

A risk management strategy can be included in the software project plan or the risk management
steps can be organized into a separate Risk Mitigation, Monitoring and Management Plan.

The RMMM plan documents all work performed as part of risk analysis and used by the project
manager as part of the overall project plan.

Risk monitoring is a project tracking activity with three primary objectives:

1. To assess whether predicted risks do, in fact, occur;
2. To ensure that risk aversion steps defined for the risk are being properly applied; and
3. To collect information that can be used for future risk analysis. Determining which risks
caused which problems.
Software Quality
Software quality product is defined in term of its fitness of purpose. That is, a quality product
does precisely what the users want it to do. For software products, the fitness of use is generally
explained in terms of satisfaction of the requirements laid down in the SRS document. Although
"fitness of purpose" is a satisfactory interpretation of quality for many devices such as a car, a
table fan, a grinding machine, etc.for software products, "fitness of purpose" is not a wholly
satisfactory definition of quality.

Example: Consider a functionally correct software product. That is, it performs all tasks as
specified in the SRS document. But, has an almost unusable user interface. Even though it may
be functionally right, we cannot consider it to be a quality product.

The modern view of a quality associated with a software product several quality methods such as
the following:

Portability: A software device is said to be portable, if it can be freely made to work in various
operating system environments, in multiple machines, with other software products, etc.

Usability: A software product has better usability if various categories of users can easily
invoke the functions of the product.

Reusability: A software product has excellent reusability if different modules of the product
can quickly be reused to develop new products.

Correctness: A software product is correct if various requirements as specified in the SRS

document have been correctly implemented.

Maintainability: A software product is maintainable if bugs can be easily corrected as and when
they show up, new tasks can be easily added to the product, and the functionalities of the product
can be easily modified, etc.

Software Reviews: A software review is "a process or meeting during which a software
product is examined by a project personnel, managers, users, customers, user representatives, or
other interested parties for comment or approval".
Objectives of Software Reviews:

1. To improve the productivity of the development team.

2. To make the testing process time and cost effective.

3. To make the final software with fewer defects.

4. To eliminate the inadequacies.

Types of Software Reviews:

There are mainly 3 types of software reviews:

1. Software Peer Review:

Peer review is the process of assessing the technical content and quality of the
product and it is usually conducted by the author of the work product along with some
other developers. Peer review is performed in order to examine or resolve the defects in
the software, whose quality is also checked by other members of the team. Peer Review
has following types:
a. Code Review:
Computer source code is examined in a systematic way.

b. Pair Programming:
It is a code review where two developers develop code together at the same
platform.

c. Walkthrough:
Members of the development team is guided by author and other interested
parties and the participants ask questions and make comments about defects.

d. Technical Review:
A team of highly qualified individuals examines the software product for its
client’s use and identifies technical defects from specifications and standards.

e. Inspection:
In inspection the reviewers follow a well-defined process to find defects.

2. Software Management Review:

Software Management Review evaluates the work status. In this section

decisions regarding downstream activities are taken.
 3. Software Audit Review:

Software Audit Review is a type of external review in which one or more critics,
who are not a part of the development team, organize an independent inspection
of the software product and its processes to assess their compliance with stated
specifications and standards. This is done by managerial level people.

Formal Technical Review (FTR):

It is a software quality control activity performed by software engineers.

Objectives of formal technical review (FTR):

Useful to uncover errors in logic, function, and implementation for any

representation of the software.
 The purpose of FTR is to verify that the software meets specified
requirements.
 To ensure that software is represented according to predefined standards.
 It helps to review the uniformity in software that is developed in a uniform
manner.
 To make the project more manageable.

 In addition, the purpose of FTR is to enable junior engineers to observe the

analysis, design, coding, and testing approach more closely.

Software Reliability:

Reliability in software is software that has no failure and works in a special time
period with a special environment.

 Software reliability is the probability that the software will operate failure-
free for a specific period of time in a specific environment. It is measured
per some unit of time.
 Software Reliability starts with many faults in the system when first created.
  After testing and debugging enter a useful life cycle.
 Useful life includes upgrades made to the system which bring about new
faults.
 The system needs to then be tested to reduce faults.
 Software reliability cannot be predicted from any physical basis, since it
depends completely on the human factors in design.
A simple measure of reliability is meantime-between-failure (MTBF), where
MTBF = MTTF + MTTR
The acronyms MTTF and MTTR are mean-time-to-failure and mean-time-
to-repair, respectively.

ISO 9000 quality standards:

 A quality assurance system may be defined as the organizational structure,

responsibilities, procedures, processes, and resources for implementing
quality management
 ISO 9000 describes quality assurance elements in generic terms that can be
applied to any business regardless of the products or services offered.
 ISO 9001:2000 is the quality assurance standard that applies to software
engineering. The standard contains 20 requirements that must be present for
an effective quality assurance system. Because the ISO 9001:2000 standard
is applicable to all engineering disciplines, a special set of ISO guidelines
have been developed to help interpret the standard for use in the software
process.
The requirements delineated by ISO 9001 address topics such as management
responsibility, quality system, contract review, design control, document and data
control, product identification and traceability, process control, inspection and
testing, corrective and preventive action, control of quality records, internal quality
audits, training, servicing and statistical techniques. (Such as Mean, Standard
deviation, Regression etc., Methods)

In order for a software organization to become registered to ISO 9001, it must

establish policies and procedures to address each of the requirements just noted
(and others) and then be able to demonstrate that these policies and procedures are
being followed
ISO 9001 standards address topics such as:

• management responsibility,
• quality system,
• contract review,
• design control,
• document and data control,
• product identification and traceability,
• process control,
• inspection and testing,
• corrective and preventive action,
• control of quality records,
• internal quality audits, training, servicing and
• statistical techniques. (Such as Mean, Standard deviation, Regression etc.,
Methods)

Why ISO Certification required by Software Industry?

There are several reasons why software industry must get an ISO certification.
Some of reasons are as follows:

• This certification has become a standards for international bidding.

• It helps in designing high-quality repeatable software products.
• It emphasis need for proper documentation.
• It facilitates development of optimal processes and totally quality
measurements.

Advantages of ISO 9000 Certification:

Some of the advantages of the ISO 9000 certification process are following:

• Business ISO-9000 certification forces a corporation to specialize in “how

they are doing business”. Each procedure and work instruction must be
documented and thus becomes a springboard for continuous improvement.
• Employees morale is increased as they’re asked to require control of their
processes and document their work processes
• Better products and services result from continuous improvement process.
• Increased employee participation, involvement, awareness and systematic
employee training are reduced problems.