ST.MARTIN’S ENGINEERING COLLEGE
UNIT-5
UNIT-5
RISK MANAGEMENT
Risk: Risk is an uncertain event that may have positive or negative impact on project.
A risk is a probable problem- it might happen or it might not. There are main two characteristics
of risk
Uncertainty- the risk may or may not happen that means there are no 100% risks.
Loss – If the risk occurs in reality, undesirable result or losses will occur.
General reasons of risk in project:





Staff leaving
Change in organisation management
Requirement changes
Under estuation of cost and time and resources
Technologies changes
Risk Management: Risk management is the process of identifying, assessing, and prioritizing
the risks to minimize, monitor, and control the probability of unfortunate events.
The following tasks are included in risk management:

Determine the risks and the factors that cause them.

All risks should be classified and prioritized.

Create a plan that connects each risk to a mitigation strategy.

Throughout the project, keep an eye out for risk triggers.

If a risk occurs, take the appropriate mitigation measures.

Throughout the project, communicate the status of risks.
There are three main classifications of risks which can affect a software project:
1. Project risks
2. Technical risks
3. Business risks
1. Project risks: Project risks concern differ forms of budgetary, schedule, personnel, resource,
and customer-related problems. A vital project risk is schedule slippage. Since the software is
intangible, it is very tough to monitor and control a software project. It is very tough to control
something which cannot be identified. For any manufacturing program, such as the
manufacturing of cars, the plan executive can recognize the product taking shape.
Dept of CSE
Page 1
2. Technical risks: Technical risks concern potential method, implementation, interfacing,
testing, and maintenance issue. It also consists of an ambiguous specification, incomplete
specification, changing specification, technical uncertainty, and technical obsolescence. Most
technical risks appear due to the development team's insufficient knowledge about the project.
3. Business risks: This type of risks contain risks of building an excellent product that no one
need, losing budgetary or personnel commitments, etc.
Sub Categories of Risks:
1) Schedule Risk: Project schedules get slipped when project tasks and schedule release risks
are not addressed properly. Schedule risks mainly affect a project and finally on the company’s
economy and may lead to project failure.
Schedules often slip due to the following reasons:




Wrong time estimation.
Resources are not tracked properly. All resources like staff, systems, skills of
individuals, etc.
Failure to identify complex functionalities and time required to develop those
functionalities.
Unexpected project scope expansions.
2 ) Budget Risk: Budget related risks refers to the monetary risks mainly it occurs due to
budget overruns. Always the financial aspect for the project should be managed as per decided
but if financial aspect of project mismanaged then there budget concerns will arise by giving
rise to budget risks. So proper finance distribution and management are required for the success
of project otherwise it may lead to project failure.
Some reasons for Budget risks –





Wrong/Improper budget estimation
Unexpected Project Scope expansion
Mismanagement in budget handling
Cost overruns
Improper tracking of Budget
3) Operational Risks : Operational risk refers to the procedural risks means these are the risks
which happen in day-to-day operational activities during project development due to improper
process implementation or some external operational risks.
Dept of CSE
Page 2
Some reasons for Operational risks –








Insufficient resources
Conflict between tasks and employees
Improper management of tasks
No proper planning about project
Less number of skilled people
Lack of communication and cooperation
Lack of clarity in roles and responsibilities
Insufficient training
4) Technical Risks:
Technical risks generally lead to failure of functionality and performance.
Causes of Technical Risks are:




Continuously changing requirements
No advanced technology is available or the existing technology is in the initial stages.
The product is complex to implement.
Difficult project module integration.
5) Programmatic Risks:
These are external risks beyond the operational limits. These are all uncertain risks that are
outside the control of the program.
External events can be:




Running out of funds.
Market development
Changing customer product strategy and priorities.
Government rule changes.
Other risk categories:
1. Known risks: Those risks that can be uncovered after careful assessment of the project
program, the business and technical environment in which the plan is being developed, and
more reliable data sources (e.g., unrealistic delivery date)
2. Predictable risks: Those risks that are hypothesized from previous project experience (e.g.,
past turnover)
3. Unpredictable risks: Those risks that can and do occur, but are extremely tough to identify
in advance.
Dept of CSE
Page 3
PROJECT RISK MANAGEMENT:
Risk Management in Software Engineering primarily involves following activities:
Plan risk management
It is the procedure of defining how to perform risk management activities for a project.
Risk Identification
It is the procedure of determining which risk may affect the project most. This process involves
documentation of existing risks.
The input for identifying risk will be


















Risk management plan
Project scope statement
Cost management plan
Schedule management plan
Human resource management plan
Scope baseline
Activity cost estimates
Activity duration estimates
Stakeholder register
Project documents
Procurement documents
Communication management plan
Enterprise environmental factor
Organizational process assets
Perform qualitative risk analysis
Perform quantitative risk analysis
Plan risk responses
Monitor and control risks
The output of the process will be a

Risk register
Perform qualitative risk analysis:
It is the process of prioritizing risks for further analysis of project risk or action by combining
and assessing their probability of occurrence and impact. It helps managers to lessen the
uncertainty level and concentrate on high priority risks.
Plan risk management should take place early in the project, it can impact on various aspects
for example: cost, time, scope, quality and procurement.
The inputs for qualitative Project Risk Analysis and Management includes
Dept of CSE
Page 4





Risk management plan
Scope baseline
Risk register
Enterprise environmental factors
Organizational process assets
The output of this stage would be

Project documents updates
Quantitative risk analysis
It is the procedure of numerically analyzing the effect of identified risks on overall project
objectives. In order to minimize the project uncertainty, this kind of analysis are quite helpful
for decision making.
The input of this stage is






Risk management plan
Cost management plan
Schedule management plan
Risk register
Enterprise environmental factors
Organizational process assets
While the output will be

Project documents updates
Plan risk responses:
To enhance opportunities and to minimize threats to project objectives plan risk response is
helpful. It addresses the risks by their priority, activities into the budget, schedule, and project
management plan.
The inputs for plan risk responses are


Risk management plan
Risk register
While the output are


Project management plan updates
Project documents updates
Control Risks:
Control risk is the procedure of tracking identified risks, identifying new risks, monitoring
residual risks and evaluating risk.
Dept of CSE
Page 5
The inputs for this stage includes




Software Project management plan
Risk register
Work performance data
Work performance reports
The output of this stage would be





Work performance information
Change requests
Project management plan updates
Project documents updates
Organizational process assets updates
REACTIVE RISK MANAGEMENT:
 In Reactive Risk Management strategy corrective measures will be taken after
occurrence of risk into software.

No preventive will be taken initially.
 Software corrected only after occurrence of risk
 It is a older risk management approach
 If they are not solved as soon possible there will be danger to project
PROACTIVE RISK MANAGEMENT:
 In Proactive Risk Management strategy corrective measures will be taken before
occurrence of risk into software.
 Preventive will be taken initially.
 First we are identify the risks, then we assess impact of the risks on the software then
risks will be prioritised.
 Higher prioritised risk are manged first.
ACTIVITIES OF RISK MANAGEMENT:
1. Risk identification
2. Risk projection
3. Risk refinement
4. RMMM
Dept of CSE
Page 6
1. Risk identification:
Risk identification is a systematic attempt to specify threats to the project plan (estimates,
schedule, resource loading, etc.). By identifying known and predictable risks, the project
manager takes a first step toward avoiding them when possible and controlling them when
necessary.
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 at hand. To identify
product-specific risks, the project plan and the software statement of scope are examined and
an answer to the following question is developed: "What special characteristics of this product
may threaten our project plan?"
One method for identifying risks is
1. Create a risk item checklist.
2. Creating the risk components
1. Create a risk item checklist
The checklist can be used for risk identification and focuses on some subset of known and
predictable risks in the following generic subcategories:
• Product size—risks associated with the overall size of the software to be built or modified.
• Business impact—risks associated with constraints imposed by management or the
marketplace.
• Customer characteristics—risks associated with the sophistication of the customer and the
developer's ability to communicate with the customer in a timely manner.
• Process definition—risks associated with the degree to which the software process has been
defined and is followed by the development organization.
• Development environment—risks associated with the availability and quality of the tools to
be used to build the product.
• Technology to be built—risks associated with the complexity of the system to be built and
the "newness" of the technology that is packaged by the system.
Dept of CSE
Page 7
• Staff size and experience—risks associated with the overall technical and project experience
of the software engineers who will do the work.
2. Creating the risk components:
• Cost risk—the degree of uncertainty that the project budget will be maintained.
• Support risk—the degree of uncertainty that the resultant software will be easy to correct,
adapt, and enhance.
• Schedule risk—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.
2. Risk Projection:
To estimate the risk the following methods are used
 The probability that the risk is real
 The consequences of the problems associated with the risk, should it occur.
Steps involved:
Project planner, along with other managers and technical staff, performs four risk projection
activities:
(1) Establish a measure that reflects the perceived likelihood of a risk
(2) Enlist the consequences of the risk
(3) Estimate the impact of the risk on the project and the product
(4) Note the overall accuracy of the risk projection so that there will be no
misunderstandings.
Risk table provides a project manager with a simple technique for risk projection
Dept of CSE
Page 8
Risk Table
3. Risk Refinement:
 A risk may be stated generally during early stages of project planning.
 With time, more is learned about the project and the risk

May be possible to refine the risk into a set of more detailed risks
 Represent risk in condition-transition-consequence (CTC) format.
 Stated in the following form:
Given that <condition> then there is concern that (possibly) <consequence>
Using CTC format for the reuse we can write:
Given that all reusable software components must conform to specific design standards and
that some do not conform, then there is concern that (possibly) only 70 percent of the planned
reusable modules may actually be integrated into the as-built system, resulting in the need to
custom engineer the remaining 30 percent of components.
Dept of CSE
Page 9
This general condition can be refined in the following manner:
Subcondition 1. Certain reusable components were developed by a third party with no
knowledge of internal design standards.
Subcondition 2. The design standard for component interfaces has not been solidified and
may not conform to certain existing reusable components.
Subcondition 3. Certain reusable components have been implemented in a language that
is not supported on the target environment.
4. Risk Mitigation, Monitoring, And Management:
RMMM consists of three approaches
 Risk Mitigation
 Risk Monitoring
 Risk Management
Risk Mitigation:
Risk Mitigation means preventing the risks form occurrence.
The following steps need to follow for Risk Mitigation.
1. Communicate with staff and find the risks.
2. Eliminates the causes for risk before project starts.
3. Prepare a policy so that project will continue even if staff leaves in between.
4. Maintain all relevant documents.
5. Conduct reviews on time.
Risk Monitoring:
It is an activity used for project tracking.
Project manager should monitor the effectiveness of risk mitigation steps.
1. To check if predicted risks occur or not.
2. To ensure proper application of risk aversion steps defined for risk.
3. To collect data for future risk analysis.
4. To allocate what problems are caused by which risks throughout the project.
5. Behaviour of team as pressure.
6. Sprit of team work.
7. Cooperation among team members.
Dept of CSE
Page 10
Risk Management:
It assumes that the mitigation activity failed and the risk is a reality. This task is done by Project
manager when risk becomes reality and causes severe problems. If the project manager
effectively uses project mitigation to remove risks successfully then it is easier to manage the
risks.
Example:
Let us understand RMMM with the help of an example of high staff turnover.
Risk Mitigation:
To mitigate this risk, project management must develop a strategy for reducing turnover. The
possible steps to be taken are:

Meet the current staff to determine causes for turnover (e.g., poor working conditions,
low pay, competitive job market).

Mitigate those causes that are under our control before the project starts.

Once the project commences, assume turnover will occur and develop techniques to
ensure continuity when people leave.

Organize project teams so that information about each development activity is widely
dispersed.

Define documentation standards and establish mechanisms to ensure that documents
are developed in a timely manner.

Assign a backup staff member for every critical technologist.
Risk Monitoring:
As the project proceeds, risk monitoring activities commence. The project manager monitors
factors that may provide an indication of whether the risk is becoming more or less likely. In
the case of high staff turnover, the following factors can be monitored:

General attitude of team members based on project pressures.

Interpersonal relationships among team members.

Potential problems with compensation and benefits.

The availability of jobs within the company and outside it.
Dept of CSE
Page 11
Risk Management:
Risk management and contingency planning assumes that mitigation efforts have failed and
that the risk has become a reality. Continuing the example, the project is well underway, and a
number of people announce that they will be leaving. If the mitigation strategy has been
followed, backup is available, information is documented, and knowledge has been dispersed
across the team. In addition, the project manager may temporarily refocus resources (and
readjust the project schedule) to those functions that are fully staffed, enabling newcomers who
must be added to the team to “get up to the speed“.
Drawbacks of RMMM:

It incurs additional project costs.

It takes additional time.

For larger projects, implementing an RMMM may itself turn out to be another tedious
project.

RMMM does not guarantee a risk-free project, infact, risks may also come up after the
project is delivered.
RMMM PLAN: RMMM plan documents all work performed as part of risk analysis and is
Used by the project manager as part of the overall project plan.
Alternative to RMMM - risk information sheet (RIS)
RIS is maintained using a database system, so that creation and information entry, priority
ordering, searches, and other analysis may be accomplished easily.
Dept of CSE
Page 12
RISK INFORMATION SHEET
Project Name:
Risk ID:
Date:
Probability:
Impact:
Origin: From where risk has been started who identified.
Assigned to:(Name) who should rectify
Description: Summary about risk
Refinement/context: What are the external factors in which effect the risk.
Mitigation and Monitoring: List of Proposal actions which are the to be done to avoid the
risks.
Contingency plan/Trigger: Instructions to the project team.
Current status:
Originator:(Name) who identified the risk first
Closing date:
Dept of CSE
Page 13
RISK INFORMATION SHEET EXAMPLE
Dept of CSE
Page 14
QUALITY MANAGEMENT
Software Quality Management ensures that the required level of quality is achieved by
submitting improvements to the product development process. SQA aims to develop a culture
within the team and it is seen as everyone's responsibility.
Software Quality management should be independent of project management to ensure
independence of cost and schedule adherences. It directly affects the process quality and
indirectly affects the product quality.
Quality concepts:
1. Software Quality: Software Quality is the degree to which the correct software produced.
Quality software is reasonably bug or defects free, delivered on time and within budget, meets
requirements, expectations, and maintainable
There are two major types of quality
 Quality of Design: Design quality refers to the level of characteristics that the designers
specify for a product.
 Quality of Conformance: The degree to which the design specifications are followed
during manufacturing, this focuses on how well the implementation follows the design
and how well the resulting system meets its requirements
2. Quality Control: It involves a series of inspections, reviews, and tests used throughout the
software process, ensures that each work product meets the requirements placed on it. Also,
includes a feedback loop to the process that created the work product which is essential in
minimizing the errors produced.
Combines measurement and feedback in order to adjust the process when product
specifications are not met; requires all work products to have defined, measurable
specifications to which practitioners may compare to the output of each process.
3. Quality Assurance: It is a planned and systematic patterns of activities are done which are
needed to provide the high degree of reliability in software.
4. Cost of Quality: The “cost of quality” isn’t the price of creating a quality product or service.
It’s the cost of not creating a quality product or service. Every time work is redone, the cost of
quality increases. Cost of quality is the sum of various costs as that of appraisal costs,
prevention costs, external failure costs, and internal failure costs. It is generally believed that
Dept of CSE
Page 15
investing in prevention of failure will decrease the cost of quality as failure costs and appraisal
costs will be reduced. Understanding cost of quality helps organizations to develop quality
conformance as a useful strategic business tool that improves their product, services & brand
image. This is vital in achieving the objectives of a successful organization.
COQ is primarily used to understand, analyze & improve the quality performance. COQ can
be used by shop floor personnel as well as a management measure. It can also be used as a
standard measure to study an organization’s performance vis-à-vis another similar organisation
and can be used as a benchmarking indices.
Various types of Quality Costs are
Appraisal Costs: The costs associated with measuring, evaluating or auditing products or
services to assure conformance to quality standards and performance requirements. These
include the costs of

Inspection of software requirements

In-process and final inspection

Product and process audits
Prevention costs: Prevention Costs are any costs that are incurred in an effort to minimize
appraisal and failure costs. This category is where most quality professionals want to live. They
say an ounce of prevention is worth a pound of cure and they are what this category is all about.
This includes the activities that contribute to creation of the overall quality plan and the
numerous specialized plans. Examples are costs associated with Quality planning, formal
technical reviews, test equipment, training.
Failure costs: The costs resulting from products or services not conforming to requirements or
customer/user needs. Failure costs are divided into internal and external failure categories.

Internal failure costs: Incurred when an error is detected in a product prior to shipment;
Include rework, repair, and failure mode analysis

External failure costs: Involves defects found after the product has been shipped

Include complaint resolution, product return and replacement, help line support, and
warranty work.
Dept of CSE
Page 16
Examples of the various costs are

Prevention – Training Programme, Preventive Maintenance

Appraisal – Depreciation of Test/ Measuring Equipment, Inspection Contracts

Internal Failure – Scrap, Rework, Downtime, Overtime

External Failure – Warranty, Allowances, Customer Returns, Customer Complaints,
Product Liability, Lawsuits, Lost Sales
Software Quality assurance(SQA):
Software quality assurance (SQA) is a process that assures that all software engineering
processes, methods, activities, and work items are monitored and comply with the defined
standards. These defined standards could be one or a combination of any like ISO 9000, CMMI
model, ISO15504, etc.
OR
Software Quality Assurance (SQA) is simply a way to assure quality in the software. It is the
set of activities which ensure processes, procedures as well as standards are suitable for the
project and implemented correctly.
Software Quality Assurance is a process which works parallel to development of software. It
focuses on improving the process of development of software so that problems can be
prevented before they become a major issue. Software Quality Assurance is a kind of Umbrella
activity that is applied throughout the software process.
Software Quality Assurance has:
1. A quality management approach
2. Formal technical reviews
3. Multi testing strategy
4. Effective software engineering technology
5. Measurement and reporting mechanism.
Dept of CSE
Page 17
Following activities are performed by an independent SQA group:
1. Prepares an SQA plan for a project: The program is developed during project planning
and is reviewed by all stakeholders. The plan governs quality assurance activities performed
by the software engineering team and the SQA group. The plan identifies calculation to be
performed, audits and reviews to be performed, standards that apply to the project, techniques
for error reporting and tracking, documents to be produced by the SQA team, and amount of
feedback provided to the software project team.
2. Participates in the development of the project's software process description: The
software team selects a process for the work to be performed. The SQA group reviews the
process description for compliance with organizational policy, internal software standards,
externally imposed standards (e.g. ISO-9001), and other parts of the software project plan.
3. Reviews software engineering activities to verify compliance with the defined software
process: The SQA group identifies, reports, and tracks deviations from the process and verifies
that corrections have been made.
4.Audits designated software work products to verify compliance with those defined as a
part of the software process: The SQA group reviews selected work products, identifies,
documents and tracks deviations, verify that corrections have been made, and periodically
reports the results of its work to the project manager.
5. Ensures that deviations in software work and work products are documented and
handled according to a documented procedure: Deviations may be encountered in the
project method, process description, applicable standards, or technical work products.
6. Records any noncompliance and reports to senior management: Non- compliance items
are tracked until they are resolved.
Benefits of Software Quality Assurance (SQA):
1. SQA produces high quality software.
2. High quality application saves time and cost.
3. SQA is beneficial for better reliability.
4. SQA is beneficial in the condition of no maintenance for a long time.
Dept of CSE
Page 18
5. High quality commercial software increase market share of company.
6. Improving the process of creating software.
7. Improves the quality of the software.
Disadvantage of SQA:
There are a number of disadvantages of quality assurance. Some of them include adding more
resources, employing more workers to help maintain quality and so much more.
SOFTWARE REVIEWS: Software Review is systematic inspection of a software by one or
more individuals who work together to find and resolve errors and defects in the software
during the early stages of Software Development Life Cycle (SDLC). Software review is an
essential part of Software Development Life Cycle (SDLC) that helps software engineers in
validating the quality, functionality and other vital features and components of the software. It
is a whole process that includes testing the software product and it makes sure that it meets the
requirements stated by the client.
Usually performed manually, software review is used to verify various documents like
requirements, system designs, codes, test plans and test cases.
Objectives of Software Review:
The objective of software review is:
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:
1. Informal reviews: Informal reviews are applied many times during the early stages of the
life cycle of the document. A two person team can conduct an informal review. In later stages
these reviews often involve more people and a meeting. The goal is to keep the author and to
improve the quality of the document. The most important thing to keep in mind about the
informal reviews is that they are not documented.
Dept of CSE
Page 19

This meeting is generally scheduled during the free time of the team members.

There is no planning for the meeting.

If any errors occur, they are not corrected in the informal reviews.

There is no guidance from the team.

This review is less effective compared to the formal review.
2. Formal reviews: Formal reviews take place among a team of three to five members. In the
formal review, the members discuss the software model.

This meeting is scheduled beforehand. This gives the team members time to prepare.

This meeting consists of a professional team that identifies and corrects errors in the
model.

This meeting does not exceed two hours.
3. Formal Technical Review (FTR):
Formal Technical Review (FTR) is a software quality control activity performed by software
engineers.
Objectives of formal technical review (FTR): Some of these are:

Useful to uncover error 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 development in a uniform manner.

To makes the project more manageable.
In addition, the purpose of FTR is to enable junior engineer to observer the analysis, design,
coding and testing approach more closely. FTR also works to promote back up and continuity
become familiar with parts of software they might not have seen otherwise. Actually, FTR is a
class of reviews that include walkthroughs, inspections, round robin reviews and other small
group technical assessments of software. Each FTR is conducted as meeting and is considered
successful only if it is properly planned, controlled and attended.
Dept of CSE
Page 20
Steps involved in FTR:
1.The review meeting: Each review meeting should be held considering the following
constraints- Involvement of people
 Between 3, 4 and 5 people should be involve in the review.
 Advance preparation should occur but it should be very short that is at the most 2
hours of work for every person.
 The short duration of the review meeting should be less than two hour. Gives these
constraints, it should be clear that an FTR focuses on specific (and small) part of the
overall software.
At the end of the review, all attendees of FTR must decide what to do.
1. Accept the product without any modification.
2. Reject the project due to serious error (Once corrected, another app need to be
reviewed), or
3. Accept the product provisional (minor errors are encountered and should be corrected,
but no additional review will be required).
The decision was made, with all FTR attendees completing a sign-of indicating their
participation in the review and their agreement with the findings of the review team.
2.Review reporting and record keeping:1. During the FTR, the reviewer actively records all issues that have been raised.
2. At the end of the meeting all these issues raised are consolidated and a review list is
prepared.
3. Finally, a formal technical review summary report is prepared.
It answers three questions:1. What was reviewed ?
2. Who reviewed it ?
3. What were the findings and conclusions?
Dept of CSE
Page 21
3.Review guidelines :- Guidelines for the conducting of formal technical reviews should be
established in advance. These guidelines must be distributed to all reviewers, agreed upon,
and then followed. A review that is unregistered can often be worse than a review that does
not minimum set of guidelines for FTR.
1. Review the product, not the manufacture (producer).
2. Take written notes (record purpose)
3. Limit the number of participants and insists upon advance preparation.
4. Develop a checklist for each product that is likely to be reviewed.
5. Allocate resources and time schedule for FTRs in order to maintain time schedule.
6. Conduct meaningful training for all reviewers in order to make reviews effective.
7. Reviews earlier reviews which serve as the base for the current review being
conducted.
8. Set an agenda and maintain it.
9. Separate the problem areas, but do not attempt to solve every problem notes.
10. Limit debate and rebuttal.
Statistical software quality assurance:
Which Involves tracing each defects along with cause and making moves to correct them.
Statistical quality assurance implies the following steps:
1. Information about software defects is collected and categorized.
2. An attempt is made to trace each defect to its underlying cause (e.g., non-conformance to
Specifications, design error, violation of standards, poor communication with the customer).
3. Using the Pareto principle (80 percent of the defects can be traced to 20 percent of all
Possible causes), isolate the 20 percent (the "vital few").
4. Once the vital few causes have been identified, move to correct the problems that have
Caused the defects.
Software reliability:
Software Reliability means Operational reliability. It is described as the ability of a system
or component to perform its required functions under static conditions for a specific period.
Dept of CSE
Page 22
Software reliability is also defined as the probability that a software system fulfills its assigned
task in a given environment for a predefined number of input cases, assuming that the hardware
and the input are free of error.
Software Reliability is an essential connect of software quality, composed with functionality,
usability, performance, serviceability, capability, installability, maintainability, and
documentation. Software Reliability is hard to achieve because the complexity of software turn
to be high. While any system with a high degree of complexity, containing software, will be
hard to reach a certain level of reliability, system developers tend to push complexity into the
software layer, with the speedy growth of system size and ease of doing so by upgrading the
software.
Measures of Reliability and Availability:
Simple measure of reliability - meantime-between-failure (MTBF)
MTBF = MTTF + MTTR
MTTF - mean-time-to-failure MTTR - mean-time-to-repair
Software availability - the probability that a program is operating according to requirements at
a given point in time and is defined as
Availability = [MTTF/(MTTF + MTTR)] x 100%
MTBF reliability measure is equally sensitive to MTTF and MTTR.
Availability measure is more sensitive to MTTR, an indirect measure of the maintainability of
software
ISO 9000 Quality standards: ISO (International Standards Organization) is a group or
consortium of 63 countries established to plan and fosters standardization. ISO declared its
9000 series of standards in 1987. It serves as a reference for the contract between independent
parties. The ISO 9000 standard determines the guidelines for maintaining a quality system. The
ISO standard mainly addresses operational methods and organizational methods such as
Dept of CSE
Page 23
responsibilities, reporting, etc. ISO 9000 defines a set of guidelines for the production process
and is not directly concerned about the product itself.
Types of ISO 9000 Quality Standards
The ISO 9000 series of standards is based on the assumption that if a proper stage is followed
for production, then good quality products are bound to follow automatically. The types of
industries to which the various ISO standards apply are as follows.
1. ISO 9001: This standard applies to the organizations engaged in design, development,
production, and servicing of goods. This is the standard that applies to most software
development organizations.
2. ISO 9002: This standard applies to those organizations which do not design products
but are only involved in the production. Examples of these category industries contain
steel and car manufacturing industries that buy the product and plants designs from
external sources and are engaged in only manufacturing those products. Therefore, ISO
9002 does not apply to software development organizations.
3. ISO 9003: This standard applies to organizations that are involved only in the
installation and testing of the products. For example, Gas companies.
How to get ISO 9000 Certification?
An organization determines to obtain ISO 9000 certification applies to ISO registrar office for
registration. The process consists of the following stages:
Dept of CSE
Page 24
1. Application: Once an organization decided to go for ISO certification, it applies to the
registrar for registration.
2. Pre-Assessment: During this stage, the registrar makes a rough assessment of the
organization.
3. Document review and Adequacy of Audit: During this stage, the registrar reviews
the document submitted by the organization and suggest an improvement.
4. Compliance Audit: During this stage, the registrar checks whether the organization
has compiled the suggestion made by it during the review or not.
5. Registration: The Registrar awards the ISO certification after the successful
completion of all the phases.
6. Continued Inspection: The registrar continued to monitor the organization time by
time.
Dept of CSE
Page 25