SE

Software Engineering
Subject Code:
MI 0033
Revised Edition II: Spring 2010
BKID B1965
Sikkim Manipal University

Directorate of Distance Education
Department of Management Studies
Board of Studies
Chairman
HOD Management Studies
SMU DDE
Mr. Pankaj Khanna

Director
HR, Fidelity Mutual Fund
Additional Registrar
SMU DDE
Mr. Shankar Jagannathan

Former Group Treasurer
Wipro Technologies Limited
Dean
SMU DDE
Mr. Abraham Mathew

Chief Financial Officer
Infosys BPO
Dr. T. V. Narasimha Rao

Adjunct Faculty and Advisor
SMU DDE
Ms. Sadhna Dash

Senior HR Consultant
Bangalore
Prof. K. V. Varambally
Director
Manipal Institute of Management, Manipal
Revised Edition II: Spring 2010
Printed: September 2014
This book is a distance education module comprising a collection of learning
materials for our students. All rights reserved. No part of this work may be
reproduced in any form by any means without permission in writing from Sikkim
Manipal University, Gangtok, Sikkim. Printed and Published on behalf of Sikkim
Manipal University, Gangtok, Sikkim by Manipal Global Education Services
Manipal 576 104.
Printed at Manipal Technologies Limited, Manipal.
Authors Profile:
Dr Jai Raj Nair holds a Bachelor's degree in Architecture from Bengal Engineering
College (University of Calcutta), PGDBM from IIM, Calcutta and Ph.D from
Symbiosis International University, Pune. He worked for 9 years in the business
domain of Engineering and Software Consultancy in reputed organizations like
Development Consultants Ltd. (Delhi and Calcutta), and Kirloskar Computer
Services Ltd. (Bengaluru) prior to joining the academic world. At reputed B-Schools,
he has taught IT-related subjects, pertinent for management, for over 12 years.
Dr Nair is a voracious reader and an avid writer. He has presented papers at
several national, regional and international conferences. Some of his papers were
selected for international conferences conducted in Thailand, Italy, Greece and
India. He has also published research papers and articles in management journals
of repute. His research interests include e-retailing, supply chain management and
retro-logistics, business process reengineering, technology-enabled retailing, to
name a few.
Reviewers Profile
Ramya S Gowda holds MS in Computer Science and Engineering and is pursuing
her post-graduation in management. She was working as Scientist C in Master
Control Facility, Department of Space Communication, ISRO, Hassan. She has
been associated with academics from 2006. She is presently working as a faculty
member in Sikkim Manipal University. She has published papers in various fields
like Pattern Recognition, E-Learning and Distance Education, Data mining,
Business intelligence, ecommerce, enterprise resource planning in national and
international Journals and conference such as International Conference on Digital
Factory (ICDF), National Conference on IT Enabled Practices and Emerging
management paradigms, International Conference on Computer Technology and
Development (ICCTD), emerging trends in computer science and information
technology (ETCSIT), international journal on computer science and information
technology (IJCSIT), International Journal Of Computational Engineering Research
(ijceronline.com), and Journal of Information Technology and Engineering.
In House Content Review Team
Dr. Sudhakar G. P.
HOD
Dept. of Management Studies
SMU DDE
Ms. Ramya S Gowda.

Assistant Professor
Dept. of Management Studies
SMU DDE
Contents
Unit 1
Software as a Product and Software Engineering
Unit 2
Software as a Process and Traditional Process Models
21
Unit 3
Agile Development Methodology
44
Unit 4
Software Requirements Analysis and the SRS
56
Unit 5
Software Project Management: Part 1
(Project Planning and Project Estimation)
73
Unit 6
(Project Scheduling, Tracking and Risk Management)
94
Unit 7
Software Reliability
118
Unit 8
System Engineering
143
Unit 9
Analysis Concepts and Principles
165
Unit 10
Software Design Concepts and Principles
189
Unit 11
Software Testing Techniques and
Technical Metrics
214
Unit 12
Software Testing Strategies
236
Unit 13
Software Verification
261
Unit 14
Capability Maturity Model for Software
279
Unit 15
CMM-Based Process Improvement
300
Unit 16
Software Quality Assurance
319
MI 0033
Course Description
Software Engineering refers to a set of theories, techniques and methods,
and tools which makes humans able to design, create and control large
software products in a reliable and cost effective manner. The term software
engineering was coined at NATO sponsored conferences held in Europe in
the 1960s to discuss the growing engineer crisis and the need to focus on
software development.
Today, every sector of the economy depends on computers to a great
extent as any sector uses computer-based information system. Business
have realised the importance of software in improving performance and to
gain competitive advantage. Like any other economic endeavour,
development of software requires a systematic approach that includes
comprehensive methods, better tools for efficient execution of these
methods and procedures for quality assurance, coordination and control. It
also involves people and their management. All the requirement aspects
relating to any development have combined together to evolve as a
discipline called software engineering. It is concerned with building quality
eng-ware within time and resource constraints.
The Self learning material (SLM) covers the process and product of
software engineering, including the process framework, different process
patterns, and different process models. Different project estimation
techniques and models, different phases of software risk management are
also discussed in this course. The concept of software reliability, system
engineering, various design concepts and principles, software testing
strategies are also covered in this course. The SLM throws light on software
verification, CMM and its improvement and software quality assurance.
Course Objectives
Software engineering is a discipline that connects the information system
and organisation together. With help of this discipline we can create and
manage various software in an industry. Since the aim of this SLM is to
introduce students to various concepts of software and its process, each
unit of this SLM will help the students to be equipped with required
knowledge.
After studying this course, the student should be able to:
explain the dual nature of software as a product and as a process
analyse why software researchers and practitioners are constantly
endeavoring to improve software process on a continuous basis
elucidate some of the important models of agile development
elaborate how requirements are elicited from customers and importance
of SRS
elucidate software project planning and scheduling
explain project tracking, control and risk management.
explain software reliability and software reliability metrics
describe the system architecture and its specifications
demonstrate software prototyping and software specification during
software analysis
illustrate architectural design and procedural design
list out the automated testing tools
elaborate the art of testing and debugging
describe about symbolic execution
elucidate the five maturity levels of Capability Maturity Model (CMM) for
software.
discuss the CMM based process improvement.
describe briefly about software quality assurance
This courseware comprises 16 units. A brief description of the units is given
below:
Unit 1: Software as a Product and Software Engineering
This unit provides you with an overview of software and software
engineering. This unit also covers the process and product of software
engineering, including the process framework, different process patterns,
and different process models.
Unit 2: Software as a Process and Traditional Process Models
This unit discusses software as a process and explains some of the
important software process models. This unit also analyses why software
researchers and practitioners are constantly endeavouring to improve
software process on a continuous basis.
Unit 3: Agile Development Methodology

This unit explains agility as the latest methodology for software
development. This unit also differentiates traditional software process
models and agile models. It explains why the software fraternity adopted the
agility philosophy. Some of the important models of agile development is
also covered in this unit.
Unit 4: Software Requirements Analysis and the SRS
This unit covers the importance of requirements engineering in the software
development process and tips to collect requirement of the customers. This
unit explains the importance of SRS and use case methodology as the
latest technique for specifying functionalities.
Unit 5: Software Project Management: Part 1 (Project Planning and
Project Estimation)
This unit discusses different project management processes, describes
about software project planning and explains project estimation techniques
and models.
Unit 6: Software Project Management: Part 2 (Project Scheduling,
Tracking and Risk Management)
This unit covers different project metrics such as size-oriented and functionoriented metrics, explains about software project planning, project
estimation techniques and models, project scheduling, tracking and control
and risk management.
Unit 7: Software Reliability
This unit explain various software reliability metrics, programming for
reliability with respect to fault avoidance and fault tolerance. This unit also
describes software quality metrics and software reuse.
Unit 8: System Engineering
This unit discusses on computer systems engineering and its types, system
analysis and architecture. This unit also explains system specification
review.
Unit 9: Analysis Concepts and Principles

This unit discusses on requirement analysis and tasks, describes the scope
of communication, explains the analysis principles, software prototyping and
software specification.
Unit 10: Software Design Concepts and Principles
This unit discusses the concept of software design, design process and its
fundamentals. This unit also explains the modular design and data design
and illustrates architectural design and procedural design. This unit brief
design documentation.
Unit 11: Software Testing Techniques and Technical Metrics
This unit describes software testing fundamentals, white box testing, black
box testing and discuss about the control structure testing. This unit
describes the testing of real-time system. The various automated testing
tools are listed in this unit.
Unit 12: Software Testing Strategies
This unit defines strategic approach to software design and describes
strategic issues. This unit also explains unit testing, integration testing,
validation testing and system testing. It covers the art of debugging.
Unit 13: Software Verification
This unit describes code reading, static analysis, symbolic execution,
proving correctness and code inspection.
Unit 14: Capability Maturity Model for Software
This unit discusses the levels of CMM for software, enlist the key process
areas of CMM and briefly describes common features of CMM.
Unit 15: CMM-Based Process Improvement
This unit describes management sponsorship, concepts of commitments
and management by fact, CMM-based process training and useful
processes and point out the customersupplier relationship in CMM-based
processes.
Unit 16: Software Quality Assurance
This unit explains quality concepts and quality movement. This unit also
describes software reviews and formal technical reviews and covers SQA
activities. It also explain SQA plan.
Unit 1
Unit 1 Software as a Product and Software Engineering

Structure:
1.1 Introduction
Objectives
1.2 The Rationale for a Software Engineering Discipline
1.3 Software
1.4 Software Engineering
Characteristics of software engineering
Objectives of software engineering
1.5 The Dual Role of Software
1.6 Industry Perspective
1.7 Software: The Product
Software programs versus software products
Evaluation of software product-ISO/IEC9126
1.8 Product Line Engineering
1.9 Summary
1.10 Glossary
1.11 Terminal Questions
1.12 Answers
1.13 Case Study
1.1 Introduction
If one were to pose a simple question to a layman on the street what is
software? chances are that a majority of the people would say software
is nothing but a collection of codes written in a programming language. This
typical response is a classic example of a half-truth. The full-truth is that
software is the resultant output that software professionals create and then
maintain till the end of the software lifespan. It encompasses not only the
programs per se but also content that is presented and generated as the
program executes. The documentation of the program in either physical
form or digital form is also considered as an integral part of the software.
It is a widely accepted notion that survival and prosperity of software
professionals, now and in the future, will depend on how well they can
deliver quality software at predicted cost and within committed time.
Possession of programming skills maybe only one of the conditions to attain
B1965
Page No. 1
Unit 1
that goal, but more importantly, the software development has to be carried
out in a highly disciplined manner.
Software Engineering is that scientific discipline that enables systematic
development of software and management of the developmental activities.
Over the past few decades, researchers and practitioners of this discipline
have developed frameworks, development strategies and methodologies for
achieving the above goal, about which you will learn in this course.
Objectives:
After studying this unit, you should be able to:
appreciate software holistically
describe the evolution of software engineering in to an important

discipline
differentiate between managing software projects and managing any

other kinds of projects and the reason behind it
explain the dual nature of software as a product and as a process
differentiate between software programs and software products
list the six quality characteristics of software as defined by ISO/IEC 9126

Model
describe the concept of product line engineering
1.2 The Rationale for a Software Engineering Discipline

Software is now an essential ingredient in many businesses, but all too
often the work is late, over budget, or of poor quality that fails to meet
requirements of the clients in its entirety. Current marketplace dynamics
requires that software be created by engineers who consistently use
effective methodologies. These learning have to take place right at the
academic level, so that the students like you can have an opportunity to
practice and perfect them during your period of formal education.
Typically, a student gets initiated into the software world by mastering a
programming language. They experiment on academic projects (that are
also called as dummy projects) and hone their technological skills and
techniques to handle issues at this dummy problem level. As they mature,
they learn to improvise on these methods and consequently, gain
confidence in their ability to develop large software programs in a short span
B1965
Page No. 2
Unit 1
of time. However, such learning is often insufficient as they do not impart a

sufficient foundation for handling the problems of real-world, large-scale
projects that require coordination of several professionals who maybe
geographically dispersed.
This is where a formal grinding in software engineering comes to the
rescue. We begin our journey by first defining software and software
engineering.
Self-Assessment Questions
1. __________________ is nothing but a collection of codes written in a
programming language.
2. __________________________ is that scientific discipline that
enables systematic development of software and management of the
developmental activities.
3. What are academic projects called as?
1.3 Software
Software is an umbrella term that refers to the different types of programs
that execute on computers and related devices such as cell phones,
washing machines, car engines, etc. At a very broad level, software is
classified into two types application software (e.g. Microsoft Office) and
system software (e.g. Windows Operating System). Middleware is an
expression that refers to software that acts as a go-between between two
dissimilar kinds of application software (e.g. making request from an
application in a Windows-based computer to a Linux-based computer,
where the operating systems are dissimilar).
We can purchase software or also obtain software in different formats such
as shareware, liteware, freeware and open source. Shareware software is
usually full-fledged software with all the features made available during a
free trial period. After this period gets over, the user has to purchase the
licence for continued use of the software. Liteware software is a category of
shareware where the concept is the same but all the features are not made
available during the trial period. Freeware software is always free, but may
have restrictions on the copyright. In open source software, the developer
furnishes the source code as well and the users who enhance the code
have to agree to continue sharing the enhanced code as well. Open source
B1965
Page No. 3
Unit 1
software has become a rage now and probably, Android is the most popular
open source software that is currently in vogue.
Traditionally, software used to be packaged on floppy disks, CD-ROMs and
DVDs. Today, most of the vendors prefer allowing the customer to
download the purchased software from their servers, in an attempt to
minimise piracy risks. Hence, in todays context, much of the purchased
software, shareware and freeware are downloaded over the Internet.
We present below a few general kinds of application software:
Personal productivity software (e.g. Microsoft Excel)
Presentation software (e.g. Corel Draw)
Graphics software (e.g. MS Office Picture Manager)
CAD/CAM software (e.g. AutoCAD)
Specialised scientific applications (e.g. SPSS)
Software for specific industries or verticals (pharmaceutical industry,

education industry), BFSI vertical (Banking, Financial Services,
Insurance)
Another method of classifying software would be as follows:
System software (e.g. UNIX, Windows)
Real-time software (e.g. Satellite Imaging Application)
Business software (e.g. Siebel CRM)
Engineering/scientific software (e.g. CAD/CAM)
Embedded software (e.g. Cell phones)
Personal Computer software (e.g. Word processors, DBMS, multimedia)
Artificial Intelligence software (e.g. software based on Data Mining,

Neural Networks)
Web applications (e.g. Python, Ajax)
Despite the multiple ways in which software can be classified, we need to

realise that these classifications are not watertight and there can be
overlaps (e.g. Microsoft Access, as a database, can be considered as
business software as well as a personal computer software).
B1965
Page No. 4
Unit 1
4. Software that has a free trial period but with limited features is called as
__________ software.
5. UNIX is an example for ___________________________.
6. Give an example for web applications.
1.4 Software Engineering

The term software engineering was coined way back in 1968 during the
proceedings of the North Atlantic Treaty Organization (NATO) Software
Engineering Conference held at Garmisch, Germany, and was intended to
trigger discussions regarding the perceived software crisis at that point in
time. The so-called crisis evolved around certain complexities in the
software developmental process like projects running late, projects running
beyond estimated cost, dubious quality of the software being created,
mismatch between customer requirements and the functionalities delivered
by the software and most importantly the fact that software projects had
become unmanageable and code was difficult to modify and upgrade!
Here are some real-life examples where major software projects floundered,
either in terms of time or cost overrun.
1. In 1983, the State of Oklahoma, USA, awarded the contract to a leading
accounting firm to develop a software system to handle the
compensation claims of its workers. The initial budget was half million
dollars. After 2 years, the software was still dysfunctional and it was
estimated that more than $2 million had been spent in those 2 years.
The software was finally delivered in 1987 after spending eight times the
estimated budget!
2. Bank of America (BoA) embarked on a new computerised financial
accounting software system. The budget was $23 million and the
estimated time for delivery was 5 years. The existing system was
abandoned and BoA spent $60 million more to make the new software
functional. Finally, the whole project was terminated and never saw the
light of the day.
3. In 1982, Allstate Insurance began developing an $8 million computer to
automate its business processes. The estimated 5-year period got
stretched to 11 years and the cost was in the region of $100 million!
B1965
Page No. 5
Unit 1
4. US Department of Defence installed the Airborne Self-Protection

Jammer (ASJP), an electronic air-defence system, in more than 2,000
navy fighters and attack planes finally after a cost overrun of $1 billion
and time overrun of 4 years!
5. The Federal Bureau of Investigators (FBI, USA) gave up midway the
development of an ambitious fingerprint-on-demand software system
and an information database on crime after spending over $500 million!
(Source: Neumann, P. G. (1993, October). System development woes.
Communications of the ACM, Vol. 36(10), pp. 146.)
Most of the above failures happened because of the lack of engineering
approach to software development. Thus, we see from the above examples
that several companies have lost massive amounts of money because the
software engineering approach was not followed! Such failures set the tone
for later generation software practitioners to adopt the software engineering
paradigm.
The Institute of Electrical and Electronics Engineers (IEEE), regarded as the
worlds largest professional association dedicated to advancing
technological innovation and excellence, has provided a formal definition for
software engineering:
Software engineering (SE) is the application of a systematic, disciplined,
quantifiable approach to the development, operation, and maintenance of
software, and the study of these approaches; that is, the application of
engineering to software.
In other words, software engineering is the application of engineering
principles to software development because it integrates certain engineering
practices into the methodology, for example, standard practices, standard
formats for documentations, standard quality checkpoints, etc. This explains
why software development is not considered as a craft but an engineering
process. Simply put, software engineering can be looked at as a process, a
set of methods, and an array of tools that are used for developing computer
software
7. When and where was the term software engineering coined?
B1965
Page No. 6
Unit 1
8. The Institute of Electrical and Electronics Engineers (IEEE), regarded

as the worlds largest professional association dedicated to advancing
technological innovation and excellence, has provided a formal
definition for software engineering. (True/ False)
Activity 1:
Assume that you are a software project consultant working in a software
company. You have been assigned the task of inculcating discipline into
the software approach in your company. How would you start your
work?
(Hint: Think of yourself as an evangelist, a change-champion!. Refer
section 1.2)
1.4.1 Characteristics of software engineering
Software Engineering promotes the idea that software should be developed
by adopting a systematic, standardized engineering approach. Software and
hardware are the two parts of a computer. However, there are major
differences when one compares the manner in which a software project is to
be conducted vis--vis a hardware project. Some of the important
differences are as follows:
Hardware is manufactured whereas software is engineered.
Hardware performance reduces over time due to the snowballing effects

of temperature extremes, humidity, dust, maltreatment and other
environmental ills whereas software performance deteriorates over time
due to the effect of introducing changes into the software code.
Hardware production is based on assembly-line production whereas

software is predominantly custom-built.
Hardware translates into a physical object whereas software is virtual.
Unlike hardware, spare parts are not available for software.
A typical hardware component is discarded in an environment-friendly

manner after its life-term gets over whereas in case of software, the
tendency has been to reuse the components so that re-coding can be
minimised. In fact, this philosophy of software reuse forms the
backbone for the object-oriented paradigm, explained in Appendix I.
B1965
Page No. 7
Unit 1
Example 1: In todays software, the Graphical User Interface (GUI) is built

using the reusable components such as message windows, pull down
menus and many more such components. The latest trend is to use in-built
components in the software. This practice of using in-built components is
popularly known as component engineering. The software requirements
specifications must be clear, unambiguous, correct and consistent. The
software requirements should not mention about the design and verification
details of software, unless specified by the stakeholders.
The description of performance, design, functionality and interfaces

must be clearly mentioned. There should not be any ambiguity or
conflicts between the requirements. To ensure unambiguity in the
requirements, a formal requirement specification language must be
used.
The response of the software system to different situations must be

noted.
The conformance about the software standard followed must be

mentioned clearly along with the details about the inappropriate
sections.
Labelling of details related to tables, figures, terms definitions,

references and the units of measure used must be mentioned.
The requirements must be traceable, so that one can trace the

references back to the requirements to know whether all the specified
requirements are met as per customer needs.
The requirements must be verifiable against the specifications.
1.4.2 Objectives of software engineering

As we are discussing about software and software engineering and have
already discussed about the features of software, let us have a look at the
objectives of software engineering.
Satisfy user requirement Understanding the needs and requirements

of the customer and developing the product according to the needs and
requirements is extremely important, as a product that does not cater to
the intended use will prove to be a failure.
High reliability A software product delivered to the customer must be

bug free and highly reliable.
B1965
Page No. 8
Unit 1
Low maintenance Maintenance of a software product is done when

fully developed software is delivered to the customer. A small change in
the structure of the software product should never end in restructuring
the entire software product, as it would cost money to the company.
Delivery on time A systematic approach needs to be adopted to

deliver the software products as per the contract agreement.
Low production costs The software product must be affordable/cost

effective.
High performance The developed software product must have an

optimum performance level.
Ease of reuse The software product must be user-friendly.
9. What are the two parts of a computer?
10. Hardware is manufactured whereas software is _______________.
11. The software product must be of high production cost in order to have
an optimum performance level. (True/ false)
1.5 The Dual Role of Software

Let us now discuss about the dual role of software.
At one level, we can consider software as a product (e.g. Microsoft
PowerPoint) and at another level we can consider software as a podium for
delivering another product (e.g. Microsoft Windows as an operating system).
We can also view software from a product perspective as well as from a
process perspective. In other words, software is both a product and a
process.
Software as a product The role of software as a product is basically
providing computing capabilities as well as accessibility to local hardware
through network computers. As a product, it produces, manages and
modifies the source of information.
Software as a process Software, as a process, is a framework for the
tasks that are required for building high-quality software. It is the process
perspective that makes software engineering such a challenging discipline.
Software as a process is covered in greater detail in Unit 2, where you will
be exposed to traditional process models such as Waterfall Model, Spiral
B1965
Page No. 9
Unit 1
Model, etc. In Unit 3, we will discuss about the latest developmental

approach in software engineering namely, the Agile Method.
Nowadays, we find a significant improvement in the role of software when
compared to the earlier decades.
The following are some of the factors that affect the role of software:
Changes in the field of computer architecture (Right from Pentium-I to
Supercomputers).
Improvement in hardware performance.
Massive improvement in computer processing capabilities at the same
or lower cost.
Wide variety of inputs and outputs (changing from simple text to
multimedia videos).
The increasing trend towards Natural User Interface (NUI) thereby
making computers even more user-friendly, as compared to GUI-based
computers.
We have seen the different roles of software over the past few decades.
These changes are due to the continuous development and improvement in
hardware performance as well as significant changes in computing
architecture.
The software development process can be divided into four eras:
Early era (19501960)
This era witnessed designing of custom-made software for each application
with limited distribution. Since it was batch oriented, the software developed
was used by the person who developed it.
Second era (19601972)
This era brought in new concepts in computer systems. It enabled human
machine interaction by developing new applications and new levels of
software and hardware. Real-time and multi-user software that could adapt
any kind of changes and could be operated by many users at the same time
was developed.
Third era (19731985)
This era saw the development of consumer-designed software. The cost of
the hardware became low and hence distribution of developed software
became economical.
B1965
Page No. 10
Unit 1
Fourth era (1985Till date)

This period has been very important for the growth of computer and
software technology. We have been seeing a humongous and sustained
growth, which has resulted in the development of powerful desktop systems,
computer networking, parallel computing, artificial intelligence and objectoriented technology.
12. Software, as a ___________________, is a framework for the tasks
that are required for building high-quality software.
13. Expand the acronym ______________ NUI.
14. Which era has witnessed massive growth in artificial intelligence?
1.6 Industry Perspective

By now you must be familiar with the evolving role of software. Let us try to
understand the industry perspective of software engineering.
During the early years of computing, it was found that the computer-based
systems were developed by using the hardware. Since the cost of the
hardware was high, technical standards and formal controls in the
development of hardware were put in place. Each time a product was built,
a thorough analysis of all the aspects involved in the design and
development of the product was made mandatory. Processes were
measured and analysed and suggestions for improvement were given.
Thus, this was the early phase of hardware engineering.
The software programming, on the other hand, was viewed as an art form.
In the field of software, there were very few systematic methods and
experienced people. The process of learning was based on trial and error
method rather than a defined method, as there were no formal set of
guidelines to be followed.
However, in todays world, the cost for the development of computer-based
system has drastically changed. Hardware which was once considered as
costly has become more cost effective and software has become costly.
The following are some of the reasons for the software to become costly:
Long-time taken to finish the program.
Unable to fix all the bugs in a software product.
B1965
Page No. 11
Unit 1
Unable to measure the progress of software development.
With the aforementioned reasons, developers felt that there has to be a

study that can help them to overcome the cost of software. This study is
known as software engineering.
15. In the early days of computing, it was found that the computer-based
systems were developed by using the _________.
16. In the early days of software programming, the learning was based on
the ___________ method.
Activity 2:
Trace the growth of software development across various eras. Try to
find out the latest trends in software development.
(Hint: Refer Section 1.6.)
1.7 Software: The Product

In this section, we will discuss about software as a product and the methods
of evaluating it. Apart from this, we will also differentiate between a software
program and a software product.
When the requirements are provided, a clear set of objectives are set and
the managers must decide the best model to be followed keeping in mind
the deadlines, budget, availability of people and the technicalities required
for the project. Without a defined requirement, it is impossible to estimate
the cost and time required for the completion of a project.
We now briefly describe how different types of software are used in different
products.
System software
System software is written to serve other programs. It refers to the collection
of files and programs that constitute a computers operating system.
Examples for files are the drivers for printers, library functions, system
services and configuration files. System software is installed while installing
the operating system. It can be updated by executing Windows update for
windows and cannot be run by the end user like an application program.
B1965
Page No. 12
Unit 1
Some of the examples for system software programs are assemblers,

debuggers and compilers. Since it runs at a very basic level of computer, it
is called as the Low-Level software and it acts as a user interface to
enable the interaction between the operating system and the hardware. The
system software always runs in the background. Artificial intelligence
software, a system software, designs are knowledge-based expert systems
that perform human-like operations. Robotics, artificial neural networks and
medical diagnostic equipments are some of the applications where artificial
intelligence software is used.
Application software
Application program is not involved in performing the task directly; instead, it
uses the capabilities of the computer in performing a single or multiple
tasks. Some of the examples of application software are the word
processors, spreadsheets, graphic software, accounting software and media
players. It is a subclass of computer software developed for a business
need and is supported by a database. It is a set of multiple applications
bundled together to perform a task. Embedded software is an example of
application software, that is, a program that is embedded/resides within a
system or product and is designed to perform a particular task that requires
very powerful set of processors.
1.7.1 Software programs versus software products
In the previous section, we have seen how different kinds of software are
used in different products. Let us now differentiate between a software
program and software product, as given in Table 1.1.
Table 1.1: Software Program and Software Product
Software program
Software product
A software program is developed by

a software engineer and has limited
functionality.
A software product is developed by

many software developers and has
much functionality.
A user interface is not very important

for a software program, as it is often
used only by the developer.
In a software product, the user

interface is very important, as the end
users of the product are not software
developers instead, the customer.
B1965
Page No. 13
Unit 1
A software program usually has very

little documentation.
A software product has usually has

extensive documentation, as it
contains the details of all the
processes involved in the
manufacturing of the software product.
A software program is developed on

the basis of a developers
requirement.
A software product is developed on

the basis of software engineering
principles.
A software program is for a single

user.
A software product is for multiple

users.
1.7.2 Evaluation of software product-ISO/IEC9126

The previous section gave us an idea about the differences between a
software program and a software product. In this section, we will learn how
a manufactured software product is evaluated by a particular standard.
The purpose of software engineering is to develop a good quality software
product, which is affordable by the common man. Therefore, it is necessary
to have high-quality products and ensure safety for human life.
Note that there are two different types of approaches followed to ensure
software quality.
Direct specification and evaluation of the quality of software.
Assuring high quality of the process by which the product is developed.
In todays corporate world, we see that multinational software companies
are following appropriate standards to produce quality software products for
different customers. The quality of a software product is defined by ISO/IEC
9126. This is an international standard for evaluating the quality of a
software product.
The International standard of ISO/IEC 9126 model consists of six quality
characteristics, which are discussed here.
Functionality Functionality is the ability of a software product to meet

the expected needs of the end-user. It has been observed that although
software is developed almost close to the requirements of the customer
needs, it may not function properly. In that case, the software product is
of no use.
B1965
Page No. 14
Unit 1
Efficiency Efficiency is the ability of a software product to perform

accurate operations as defined. It is to ensure that the software product
used in the system performs its best. The response time of the product
has to be as expected.
Usability A software product must be utilised to its maximum level, for

the purpose, for which it is chosen. You also need to check whether the
software developed is serving the purpose and has tolerance to errors.
Thus, documentation must be provided about the product with a better
understanding of the user interface.
Reliability Reliability of a software product is the performance level of

software under specified usage conditions.
Maintainability A software product is analysed on usage, changed

and tested for correctness, for maintainability. Maintainability is to make
sure that the corrected product does not affect the performance of the
other modules.
Portability It is the ease with which a software product can be moved

from one computing platform to another platform. Portability of software
can be found in high-performance computing platforms.
The standard ensures that the aforementioned six characteristics adhere to

the software quality of a product.
17. The quality of a software product is defined by ____________.
18. Making provision for allowing changes to the software reflects the
____________ quality feature.
19. Write once, run anywhere was the claim with which the programming
language Java was released in the late 1990s. Which of the software
quality features does this reflect?
Activity 3:
As a student of software engineering, try to think about the different
software products that a developer can design for a sophisticated health
care unit.
(Hint: Refer to Section 1.7, especially the quality characteristics.)
B1965
Page No. 15
Unit 1
1.8 Product Line Engineering

By now you must be familiar with the software development process, the
software product and the way to evaluate them. Now let us educate
ourselves about product line engineering.
Product line engineering is also known as product family engineering. It is
the synonym of domain engineering.
We can define the product line engineering as the process of studying the
product family. Product family refers to the architecture of the product
platform of an organisation. This study provides the necessary information
about the common and varying components of the product family.
The study of product family is considered as a latest approach for creating
new products. Its emphasis is more on the way to reuse the product in order
to reduce cost and time. Therefore, product line engineering is a concept of
reusing components and structures, thus saving cost and time. It is not a
technology; but rather it is the way of doing business.
Organisations that have tried to implement product line engineering have
benefited. Software product family is a way of satisfying the specific needs
of the customer by developing a product from a common set of assets in a
specified way. They are always viewed as business drivers as it is
considered as a low-risk and high-profit practice. So, companies today plan
to merge both the business and the technical approaches for their success.
Some of the benefits of product line engineering are listed below:
Higher productivity
Higher quality
Faster time-to-market
Lower labour needs
A new application of a proven concept
An innovative, growing concept in software engineering
Benefits
In todays corporate houses, attrition (constant reduction in the personnel) is
very high, so product line engineering helps to overcome problems related
to resource shortage. Organisations have started to implement product line
B1965
Page No. 16
Unit 1
engineering to realise its fruits. It was observed that, by using product line
engineering, organisations have benefited and some of these benefits are
listed below:
Improved productivity by as much as ten times.
Increased quality by as much as ten times.
Decreased cost by as much as 60%.
Decreased labour needs by as much as 87%.
Decreased time to market (to field, to launch) by as much as 98%.
Ability to move into new markets in months, not years.1
20. Product line engineering is also known as ________ ______________.
21. Product line engineering focuses on ______________ of software.
22. List down any one benefit of product line engineering.
1.9 Summary
Let us recapitulate the important concepts discussed in this unit:
Application of software engineering is required for development of

software as past experiences have proved that a sloppy approach to
software development can lead to time/cost overrun and underperformance issues. This provides the justification for treating software
engineering as a stand-alone discipline.
Software and hardware, though complementary, require different

approaches altogether. Hardware follows the assembly-line production
philosophy whereas software is mostly custom-built.
Software exhibits dual nature as a product and as a process.
There are six quality attributes for software as advocated by ISO/IEC

9126, namely, functionality, efficiency, usability, reliability, maintainability
and portability.
Product line engineering, as a concept, is extremely important in todays

world.
http://www.sei.cmu.edu/productlines/
B1965
Page No. 17
Unit 1
1.10 Glossary
Assembly-line production: An assembly line is a manufacturing process in
which parts are added to a product in a sequential manner using optimally
planned logistics to create a finished product much faster than with
handcrafting-type methods.
Natural User Interface (NUI): A Natural User Interface (NUI) is a system
for humancomputer interaction that the user operates through intuitive
actions related to natural, everyday human behaviour.
Programming language: An artificial language used to write instructions
that can be translated into machine language and then executed by a
computer.
Software crisis: Software crisis was a term used in the early days of
computing science to describe the impact of rapid increases in computer
power and the complexity of the problems that could be tackled. In essence,
it refers to the difficulty of writing correct, understandable and verifiable
computer programs.
Software piracy: Software piracy refers to the un-authorised duplication
and the use of computer software.

1. Define software engineering and briefly discuss about its evolution.
2. Differentiate between software and hardware.
3. Briefly explain the characteristics used for evaluating the software
quality.
4. Explain the objectives of software engineering.
5. Describe product line engineering, in brief.
6. Justify the need to have a separate discipline called as Software
Engineering.
1.12 Answers
1. Software
2. Software Engineering
B1965
Page No. 18
Unit 1
3. Dummy Projects
4. Liteware
5. System
6. Phython
7. In 1968 during the proceedings of the North Atlantic Treaty
Organization (NATO) Software Engineering Conference held at
Garmisch, Germany
8. True
9. Hardware and Software
10. Engineered
11. False
12. Process
13. Natural user interface
14. Fourth Era (1985Till Date)
15. Hardware
16. Trial and error
17. ISO/IEC 9126
18. Maintainability
19. Portability
20. Product family engineering
21. Reusability
22. Higher quality
Terminal Questions
1. (Refer to Section 1.4 for further information.)
2. (Refer to Section 1.4.1 for further information.)
B1965
Page No. 19
Unit 1
1.13 Case Study

From Hardware Business to a Software Business: The Challenges
Mr. Sub Jaanta is a successful entrepreneur who had set up a factory for
manufacturing computer hardware in 1990 at Basirhat in West Bengal. Two
decades later, his manufacturing unit was regarded as the best in Eastern
India and has won several awards for its exemplary manufacturing
processes.
Being an entrepreneur, Mr. Sub Jaanta wants to explore newer avenues to
carry his business forward. An obvious choice for him would be to consider
a software development company that would be the perfect complement to
his successful hardware business. He has a choice either to acquire an
existing software company or to start a new company from scratch.
The global recession clouds lifted in 2010, and ever since, Mr. Sub Jaanta
has been contemplating on setting up a software company as he believes
that with his superb experience in the hardware manufacturing industry, he
can easily pull off a software super-success story.
Discussion Questions:
1. Is it a better idea to acquire an existing software company or to start a
new software company? Justify your answer.
2. The fundamental belief for Mr. Sub Jaanta is that he can repeat the
success story as hardware and software are both complementary to
each other. Do you believe in his optimism? Justify your answer.
3. If you were appointed as an adviser to Mr. Sub Jaanta, how would you
advise him to take his new software venture ahead? Explain the
possible pitfalls and methods to bypass them.
References:
Aggarwal, K. K (2007), Software Engineering. New age International
publishers,
Pankaj Jalote. (2010). Software Engineering A Precise Approach.
Daryaganj, New Delhi : Wiley-India
Roger S Pressman. (2010). Software Engineering A Practitioner
Approach. McGraw-Hill Higher Education.
A. A. Puntambekar. (2007). Software Engineering. Pune: Technical
Publications
B1965
Page No. 20
Unit 2
Unit 2
Software as a Process and

Traditional Process Models
Structure:
2.1 Introduction
Objectives
2.2 Software Project Life Cycles
Process framework
Process patterns
2.3 Process Models
Linear sequential/waterfall model
V-shaped model
Prototype model
Spiral model
Incremental delivery model
Rational unified process (RUP)
Summary of the major process models
2.4 Using Process Models in Software Projects
2.5 Summary
2.6 Glossary
2.8 Answers
2.9 Case Study
2.1 Introduction
We discussed software as a product in Unit 1. In this unit, we will describe
software as a process and also explain some of the important software
development life cycle models that have been in existence over the last few
decades. These models have been collectively referred to as Traditional
Software Process Models.
A process can be defined as a set of things to be done when some work
product (called software artefacts) is to be produced. We can define a
software process as the manner in which software is developed. It is a stepby-step procedure of developing a complete software product. Each
organisation follows its own set of processes to develop software
development process, which are usually based on one or more of the
aforementioned traditional software process models. The process of
B1965
Page No. 21
Unit 2
software development, which involves highly sophisticated software

development tools and processes, is quite complex.
The use of software development processes ensures that developers follow
a systematic approach in developing the software and also incorporate the
company guidelines to complete their project schedules. In todays world,
software companies are looking for better processes to enhance their
quality and predictability of software development along with maintenance of
costs.
It is important to note that in the framework of software engineering, a
process is not a rigid directive for developing computer software. On the
contrary, it is a flexible methodology that allows the software practitioners
doing the work to select the relevant set of work activities and tasks. The
goal is always to deliver software on-time, on-cost and with the full set of
requirements as desired by the customer.
Objectives:
describe software as a process
explain some of the important software process models
analyse why software researchers and practitioners are constantly

endeavouring to improve software process on a continuous basis
2.2 Softrware Project Life Cycles

We can classify software development projects into various types based on
their business functional domain. In case a software company is interested
in specialising in only one product or service, it will need to understand that
particular function or domain thoroughly. Mere technical knowledge in how
to develop the software by writing lines of codes may not be sufficient. For
example, Kolkata-based UshaComm that has gained expertise in
telecommunications-billing solutions that are used all across the world. For
such companies, it is a prudent approach when they consider breaking
down the project into a broad series of phases that would enable them to
manage the project efficiently. The phases could be requirements in
engineering, analysis, design, coding, testing, implementation and
maintenance.
B1965
Page No. 22
Unit 2
As mentioned earlier, a software process can be defined as the step-by-step

manner in which software is developed. Each organisation tailors this into its
own set of processes to develop software development process.
The use of software development processes within the project life cycles
ensures that developers follow a systematic approach in developing the
software and also incorporate the company guidelines to complete their
project schedules. In todays world, software companies are looking for
better processes to enhance their quality and predictability of software
development along with maintenance of costs.
1. The use of software development processes within the project life
cycles ensures that developers follow a unstructured approach in
developing the software. True/false?
2. A software process can be defined as the __________________
manner in which software is developed.
3. UshaComm has gained expertise in which product worldwide?
Activity 1:
Can you identify other software companies like UshaComm that have
acquired the skill sets required for being single-product companies?
How are these companies different from the software giant, Infosys
Technologies Ltd.?
(Hint: Refer to Section 2.2. Try to find out about the kind of projects that
Infosys takes up.)
2.2.1 Process framework
After introducing you to the concept of software process, we will now
discuss about the process framework. The Capability Maturity Model (CMM)
is a standard process framework based on people and product and their
role in making a project successful. The CMM was propounded by
Software-Engineering Institute Carnegie Mellon University, USA. We will
discuss more about the CMM and its levels in Unit 12. The teams in an
organisation adopt their respective frameworks pertaining to the tasks
assigned.
B1965
Page No. 23
Unit 2
We will now briefly discuss about some process framework activities shown
in Figure 2.1.
Fig. 2.1: Process Framework Activities
We can bridge the gap between the customer and the company through
better communication, because the company interacts with the customer for
gathering the project requirements. After obtaining the customer
requirements, the project is planned. Then, the requirements are analysed
and the software is designed in the process of modelling. Afterwards, the
development of code and testing takes place in construction. Then, the
developed software is delivered to the customer and a feedback is obtained
for the product.
The umbrella activities shown in Figure 2.1 take place across the entire
software development work right from the requirements stage to the final
implementation at the customers premises. We can define umbrella
activities as the activities that focus on tracking and controlling the project,
and are undertaken through the entire process of software development. In
the process of software development, risks may take place. Such risks and
their impact on the quality are analysed, and corrective action is taken, in
the process of risk management. And, the process of ensuring that a
software system and its relevant documentation are wholly of sufficient
quality, for their purpose, is named as Software Quality Assurance (SQA).
We can define software configuration management as the process of
B1965
Page No. 24
Unit 2
managing the configuration involved in a project when there is a change in

the software. And, the activity of reusability management involves providing
information pertaining to the reuse of software product. Finally,
measurement takes place, to measure both the product and the process, to
ensure that the projects undertaken by the company are delivered per the
schedule.
2.2.2 Process patterns
We know that a process is a systematic activity in any project, where a
defined set of inputs are given to generate the required outputs. Now, we
will discuss process patterns that are involved in a software development
project.
The term pattern relates to the process of solving a problem using a
template. It helps an individual to know what to do, but not how to do. It is a
way of reaching a solution for a common problem. We can conclude that the
process pattern is a set of tasks and techniques used to develop objectoriented software. Process patterns help in the construction of software
processes in an organisation.
Let us briefly describe the three types of process patterns.
Task process pattern Task process pattern provides a step-by-step

procedure to do a specific task. For example, technical review, reuse of
first process patterns.
Stage process pattern It involves steps that are performed very

often/iteratively for a single project stage. We can consider the stage
process pattern as a high-level process pattern, which is included in
many task process patterns. This kind of process pattern finds its
presence in every stage of a software process like the object-oriented
software process in the program stage
Phase process pattern A phase process pattern gives us the details

pertaining to the interactions that occur between the stage process
patterns for a single project phase. For example, the initiate phase and
the delivery phase. The construct pattern is a combination /collection of
two or more stage process patterns. Most of the project phases are
done in a serial manner and are similar to the structure development
and object development, for example, the spiral model. In todays world,
B1965
Page No. 25
Unit 2
an object-oriented program is considered as iterative only in small pilot

projects whereas in the large projects, it is considered as a serial
process. Generally, a process pattern describes the following:
o
Complete process.
Important framework activity.
Task within the framework activity.
Let us have a look at the template of a process pattern given in Table 2.1.
Table 2.1: Process Pattern Template
Pattern name
Intent
Type
Initial context
Problem
Solution
Resulting context
Known uses
Table 2.1 gives us a brief idea about a process pattern template that defines
the following parts:
Pattern name
Nomenclature/naming must be done in a meaningful way and should be
simple so that an individual can guess its functionality from its name.
Intent
The intention/purpose/need of the pattern must be described.
Type
It specifies the type of pattern.
Initial context
For a process pattern to begin, it must have true initial conditions.
You must describe the following issues before the commencement of any
process pattern:
The set of organisational or team-related activities that have already

occurred.
B1965
Page No. 26
Unit 2
The list of entry state processed.
Already existing software engineering or project-related information.
Problem
After mentioning a problem, we need to describe the pattern to solve the
problem.
Solution
A problem, for which a pattern has been described, is always accompanied
by a solution.
For example, when there is insufficient information about the customer
requirements, we need to get back to the customer for the relevant missing
information and also must ensure that reviews are conducted, every time
there is a change in requirements. This helps the development team to plan
their activities before the actual start of development.
Resulting context
It gives detailed information about the results of a successful process
pattern. You must ensure that the following information is checked when a
process pattern ends.
The team-related or organisational activities that must have occurred.
Exit state for the process.
The software engineering information or project information that has

been developed.
4. CMM stands for ___________________________.
5. The gap between the customer and the software company can be
bridged through better ________________.
6. Development of software code and testing takes place in a phase
called as __________________.
7. Reusability management involves providing information pertaining to
the _________________ of the software product.
8. The term pattern relates to the process of solving a problem using a
__________.
B1965
Page No. 27
Unit 2
2.3 Process Models

We will now study the different software process models. We can define a
process model as a step-by-step, systematic approach for software
development. You must note that a distinct set of tasks are performed at
each step to provide a high-quality software product. They are known by
different names such as the generic software process model, the
prescriptive process model, and so on.
The process models discussed in this unit are listed below:
Linear sequential/waterfall model.
Prototype model.
V-shaped model.
Spiral model.
Iterative model.
Incremental delivery approach.
Rational unified process (RUP).
2.3.1 Linear sequential/waterfall model

This is perhaps the oldest model of the traditional process models. The
basic assumption is that the development of software progresses in a
sequential form, analogous to the manner in which water flows down a
waterfall. One can move to the next step only when the current step is
completely over. It is not possible to backtrack to the previous step. As an
example from the diagram below (Figure 2.2), we cannot move backwards
from the implementation to the design phase after the design phase is over.
Such a model is of little practical use in todays software environment as the
requirements are no longer simple and very often the client is unable to
articulate his/her full set of requirements at the very beginning of the project.
However, this model still has its utility in projects that are small and the
requirements are well understood in advance. An example would be
developing accounting software packages, where the requirements are in
general fixed over a long period of time.
B1965
Page No. 28
Unit 2
The Waterfall Model is depicted in Figure 2.2.
Fig. 2.2: Waterfall Model
We will now briefly describe these steps of the waterfall model.

1. Requirements phase In this phase, the requirements of the customer
like the functionalities and the constraints are collected accurately.
These requirements are analysed and checked if they can be
implemented. A document known as the requirement specification
document is prepared and this is used as the input to the next phase of
design.
2. Design/system design In this phase, the architectural design of the
product to be developed is defined. The user interfaces and the
components involved are also defined. The entire process is
documented and is known as the system architecture document, which
is the input to the next phase. Based on the system architecture
document, the software blocks are decided. Important system states like
start-up and shutdowns are considered and their behaviour is observed.
The details are gathered and documented and are called the software
design document. The output of this phase is a Software Design
Document, which is the basis for the implementation phase.
3. Implementation-coding On the basis of the software design
document, modules are developed using codes. To start with, a small
unit is developed and slowly they are integrated to form a complete
module.
4. Testing Software integration and verification: In this phase, the units
that have been developed are tested for their functionality. The modules
B1965
Page No. 29
Unit 2
are checked to verify that they meet the requirement specifications.

Tests are performed at the module interfaces and the internal code of
the software is also tested. Finally, all the units are integrated and tested
to check the performance of the entire system. Once all the units are
integrated, the system is tested against the requirements given by the
customer.
5. Deployment and maintenance Operation and Maintenance: In this
phase, the newly developed software is delivered to the customer and
the customer would be using the software product for the first time.
Therefore, the customer checks whether all the stated requirements are
implemented and also validates them. When changes are observed in
the system, developers fix the problem for the customer.
For software projects that are large and embrace newer technologies, it is
practically impossible to understand all the requirements upfront and then
proceed to the other phases. In such cases, the waterfall model is woefully
inadequate.
2.3.2 V-shaped model
After studying the waterfall model, we see that the major drawback of the
model is the inability to change the design whenever there is a change in
the requirements, which is inevitable. So, to overcome this drawback, the Vmodel was developed. The steps of the V-model are similar to the waterfall
model, but with a difference in the way in which the approach is made. In a
waterfall model, it is a cascading/linear approach, where each activity level
comes down, step by step. Whereas in the V-model, the figure looks like a
V and the coding phase is the vertex of the figure. The biggest advantage
of this model is the simultaneous development and testing methodology.
Hence, it is used in most of the software companies. There is no wastage of
time, as the activities of development and testing are done at the same time.
The tests are derived from the design and requirements phase. Since
traceability is easier, the requirements can always be traced back to the
design phase to verify that the task is done correctly and meets the
requirements. The operation and maintenance phase found in the waterfall
model is replaced by the validation of requirements phase. Whenever there
is a change in the requirements, changes could be made immediately and
validated as well.
B1965
Page No. 30
Unit 2
The different phases of the V model are illustrated in the Figure 2.3.
Fig. 2.3: V-Shaped Model
2.3.3 Prototype model

A software prototype is a working model/simulation of the final software
product to be delivered to the customer. It works very well when the
customer can explain his/her further requirements only after trying out a
simplified version of the product. In this model, the customer gives a very
sketchy image of his/her requirements. The developer creates a prototype
on this basis. The customer then test-drives the prototype and gives the
feedback, based on which the developer refines the prototype and adds
further enhancements. This process repeats iteratively till the final product is
delivered to the customer.
The advantages of prototype approach are as follows:
It enables all the stakeholders (including the customer and developer) to

envisage how the software would appear in terms of its interface with
the end-user. The customer can check the usability and functionality and
provide feedback for further development.
A prototype enables meaningful communication between the customer

and the developer the prototype helps the customer to envisage and
understand his requirements better in an iterative manner.
B1965
Page No. 31
Unit 2
Prototyping reduces software risks especially when the project is a

complex one. You will learn about software risks in Unit 9.
A variation to the above discussion is what is called as Quick & Dirty

Protocol (QDP). In QDP, the developed prototype acts only as a guideline
and cannot be iteratively evolved into the final product. It has to be
discarded in the end. The final product has to be engineered from the
beginning which could add to the cost of the project.
2.3.4 Spiral model
The spiral model was proposed by Barry Boehm, who is widely regarded as
the guru of software engineering for his pioneering efforts at trying to seek
order within a chaotic software industry. This model is very simplistic and
yet combines the iterative nature of the prototyping method and the
sequential nature of the waterfall method. In effect, this model is a series of
waterfall models following an iterative approach.
The spiral model is illustrated in Figure 2.4.
Fig. 2.4: Spiral Model
In this model, the software to be delivered is envisaged in the first prototype.

A waterfall model is applied here and the developers go through the entire
B1965
Page No. 32
Unit 2
life cycle, including analysis and design phases. At the end of the first
iteration, the first version of the software is delivered and then the process
repeats all over again till the second version is delivered. The new version
can have added functionalities or enhancements over the earlier versions.
This process can be repeated infinitely and hence, the term spiral model is
apt for it as a spiral can also be continued infinite times. Remember that it
starts at the centre and traverses in a clockwise direction. Each traversal
denotes a deliverable. The iterations/repetitive traversals denote the tasks
accomplished. For example, the first traversal may result in identifying the
objectives and constraints and the second stage may result in identifying
and resolving the risks, and so on. Finally, the last iteration will lead to the
end product.
As you can notice in Figure 2.4, there are four task regions in the spiral
model:
1. Determine objectives.
2. Identify and resolve risks.
3. Develop and test.
4. Plan the next iteration.
We can differentiate the spiral model from the other software models on the
basis of its risk evaluation task. The spiral model does not have fixed phase
for requirements, design and testing that are normally found in the other
software models (such as V-Shaped Model). It follows a step-by-step
approach, so the developers and customers interact after every step and
thus risks are detected very early in this life cycle and helps in
accomplishing the tasks.
This model is very handy where the stakeholders are unsure about the final
software solution to be developed. Both the customer and the developer can
take a relook at the functionality of the software developed till date in each
consecutive spiral loop.
2.3.5 Incremental delivery model
In this approach, the software developer develops the required software not
in a single burst but rather in a series of small increments. This methodology
has certain distinct advantages, namely:
B1965
Page No. 33
Unit 2
The customer and the developer can jointly decide on which features and
functionalities need to be given more priority so that the customers
business is least affected. This would lead to creation of a sequential
preference table based on which the features and functionalities would be
delivered in successive increments.
It enables the customer and the developer to reduce the scope to a smaller
and more manageable increment which is easier to comprehend.
It enables the developer to manage with lesser resources (like manpower
and monetary resources) as compared to the other approaches.
You may have realised by now that the incremental delivery approach to
software development is all about chopping up the overall software delivery
into a number of small units, which are to be delivered on a priority basis in
each increment.
The fundamental difference between the iterative and incremental
approaches is that incremental assumes the addition of newer modules over
time whereas the iterative approach successively enhances existing
functionality.
2.3.6 Rational Unified Process (RUP)
Rational Inc. was an object orientation company promoted by the three
Amigos of Object-Orientation Grady Booch, James Rumbaugh and Ivar
Jacobson. This company propounded the Rational Unified Process (RUP)
along with a set of tools such as Rational Rose to assist the software
development life cycle (SDLC). RUP breaks down a software project into
four phases Inception, Elaboration, Construction and Transition Phase.
Each of these phases is elaborated below.
6. Inception phase
This phase corresponds to the planning phase in the SDLC, which
constitutes around 10% of the total effort (usually stated in man-months).
This phase aims at laying down the broad scope of the product being
developed, develop a vision for the product, estimate the effort, estimate the
resources and assess the risks.
This phase comes to an end once the planning of work for the elaboration
phase finishes.
B1965
Page No. 34
Unit 2
7. Elaboration phase
This phase mainly elaborates the use cases. A use case is defined as a
sequence of actions that an end-user and the computer must perform to
fulfil a specified business task. This forms the basis for creating the
Software Requirement Specifications (SRS). You will learn more about use
cases and SRS in Unit 4: Software Requirements Analysis and the SRS.
The software architecture is finalised in this phase which is based on the
developers understanding of the customer requirements.
This phase also includes carrying out detailed estimates and risk analysis
for the project.
All the tasks in this second phase constitute about 20% of the total effort of
the project.
8. Construction phase
The actual construction of the software occurs in this third phase. Coding
and testing are the two most important activities in this phase that could
take up about 60% of the total effort.
The system development is by and large incremental and iterative in nature.
9. Transition phase
This is the phase where the software is implemented at the customers
premises.
This phase constitutes about 10% of the total effort and includes tasks like
completing the entire software, completing all the testing including the user
acceptance test, completing and handing over all documentation for the
user (either in hard copy or soft copy format) and making preparations for
training of the end-users.
The major advantages of the RUP are as follows:
RUP acknowledges the reality of changing requirements
RUP advocates splitting the project into smaller components. Hence, the
developers can focus early on the high-risk components, which lead to
early solution to problems whenever a risk becomes a reality.
RUP permits the developers to build up the software gradually in an

incremental fashion by allowing them to do planning, designing and
coding in small bursts.
B1965
Page No. 35
Unit 2
RUP promotes team integration by allowing all stakeholders to get

involved in the project in the initial stages itself.
RUP enables the software to progress over time, as opposed to the big
bang approach where the risk of total system failure is high.
2.3.7 Summary of the major process models

A brief summary of the strengths and weaknesses of important process
models discussed above is depicted in Table 2.2.
Table 2.2: Strengths and Weaknesses of Important Process Models
Model
Waterfall
model
Strengths
Simple
Easy to execute
Intuitive and logical
Easy contractually
Weaknesses
All or nothing
too risky
Requirements
frozen early
May choose
outdated
hardware/tech
Applicable types of
projects
Well-understood
problems,
Short duration
projects,
Automation of
existing manual
systems
Disallows
changes
No feedback
from users
Encourages
requirements
bloating
Prototyping
model
Helps requirements Possibly higher

elicitation
Reduces risk
Better and more
stable final system
cost and
schedule
Encourages
requirements
bloating
Disallows later
change
Spiral model
Regular deliveries,
Overhead of
leading to business
benefit
planning each
iteration
Can accommodate
Total cost may
changes naturally
Allows user
feedback
Avoids requirements
increase
System
architecture and
design may
suffer
B1965
Systems with novice

users; or areas with
requirements
uncertainty.
Heavy reporting
based systems can
benefit from UserInterface prototyping
For businesses
where time is
important; risk of
long projects cannot
be taken;
Requirements not
known and evolve
with time
Page No. 36
bloating
Naturally prioritises
Unit 2
Rework may
increase
requirements
Allows reasonable
exit points
Reduces risks
Rational
unified
process
(RUP)
All benefits of
iterative
Provides a flexible
framework for a
range of projects
For each project, Can be applied to a

one has to
design the
process
wide range of
projects as it allows
flexibility
9. The four phases of the RUP are inception, elaboration, communication,
and ___________________.
10. For a library management software, where the requirements are well
understood and are unlikely to change, the _____________ model is
well applicable
11. The V-Shaped Model is a rectification of flaws in the Spiral Model.
(True or False)
12. The founders of Rational Inc., the founders of the RUP, were
collectively referred to as the three __________.
Activity 2:
Compare and contrast the waterfall model and the spiral model. Can
you find any similarity between the two models? Can you say that the
introduction of Windows Operating System at different points in time
(like Windows 95, Windows 98, Windows XP, Windows Vista and
Windows 7) is an example of the spiral model? Justify your answer.
(Hint: Refer to Section 2.3.)
2.4 Using Process Models in Software Projects

Till now we have studied several development process models. An
important question that arises is that why do we need to have different
models like these? Remember, while developing software, the goal is not
only to develop software that fulfils the customer requirements but also to
B1965
Page No. 37
Unit 2
perform the development within estimated budget and committed time.

Additionally, there could be other restraints in a project that we may need to
address. In a scenario like this, it is important to choose a development
model that would enable us to deliver high-quality software. Let us consider
a couple of examples to illustrate this point.
Example 1:
Assume that a software company has been awarded the contract for
developing a web portal for a confectionery shop. The personnel at the
confectionery shop have agreed to spend a great deal of time at the
beginning of the project during the phase of requirements gathering and
analysis but they are clear that later on their availability for discussions will
be highly restricted and not guaranteed. The total time allotted for the
project is 6 months with no chance of negotiation for deadline extension. It
may be noted that some features of the web portal are absolutely
necessary, whereas there are some features that are desirable but not
essential to run the portal. Probably these could be accommodated in later
iterations/increments.
Keeping the above constraints in mind, we can easily rule out the waterfall
model as the all-or-nothing risk that it brings along is not acceptable due to
the non-extensible deadline. The iterative model is not applicable here as
the customer will not be available later on for discussions and finalisation of
requirements that will be filled in later. Incremental model is apt here where
the requirements can be frozen early on and the features and functionalities
can be prioritised in each incremental development. The RUP model that
allows phase-wise iterations can also be considered for this project.
Example 2:
Assume that a 40-year-old grocery store in your neighbourhood wishes to
get custom-built accounting software developed. In such a project, the
waterfall model would be ideal as the requirements are well understood due
to the experience in years of having handled the same accounting function
in a paper-and-pencil mode. Besides, the basic accounting principles do not
change and hence, there is no risk of major requirement changes during the
tenure of the project, which suits the waterfall model well.
B1965
Page No. 38
Unit 2
13. An accounting software package, where the requirements are well
understood and are unlikely to change can be developed using the
_______________ model.
14. It is important to choose a development model that that would enable
us to deliver __________ software.
15. The RUP Model allows ____________ iterations.
Activity 3:
Assume that you are working for a software company. Your company has
been assigned the task of carrying out THREE software projects, namely:
1)
A Library Automation Software for Sikkim Manipal University where

the requirements have to be jointly finalised by your company and
the University.
2)
A Management Information System Software for a medical store,

where the requirements are frozen in advance and there wont be
any more additional requirements
3)
An Inventory Management Software for a retail chain where the

customer would like to be closely involved with the development
process as he is not very clear about his requirements.
For each of the above three projects you have to decide on the software
process model to be applied. Which model will you apply in each case?
Justify your answers.
(Hint: Refer to Section 2.3.)
2.5 Summary
Software as a process is extremely important. Various process models,

called as traditional process models, have been adopted over the last
few decades in order to bring standardisation and order into the
software process, which would otherwise have become quite chaotic.
These include waterfall model, V-shaped model, spiral model, RUP, etc.
A newer developmental paradigm called Agile Methodology is now
becoming popular in the software world.
B1965
Page No. 39
Unit 2
A process is the collection of tasks that are done in some pre-defined

order so that we can achieve the desired outcomes. A development
process model is a general process specification that best fits the
situation under consideration.
The waterfall model is the oldest and the simplest of all the process
models where all the steps are performed in sequence. It is suitable only
for those kinds of problems where the requirements are very well
understood right at the beginning of the project. The V-shaped model
was added later to correct certain shortcomings in the waterfall model.
In the prototyping approach, a simple working model of the final

software, called prototype is created that precedes the actual software.
This is used to develop the requirements on a clearer understanding of
the project by the customer. Such an approach suits those kinds of
projects where all the requirements cannot be specified by the customer
upfront.
The spiral model is actually a series of waterfalls in an incremental

delivery mode.
One of the newer paradigms is the Rational Unified Process (RUP)

where there are four phases inception, elaboration, communication
and transition.
2.6 Glossary
Artefact: An object processed by a computer and is owned by the software
system. Examples of artefacts are documents (e.g. training manuals), lines
of code in the program, etc.
CMM (Capability maturity model): The Capability Maturity Model (CMM) is
a methodology used to develop and refine an organisation's software
development process.
SDLC (Software development life cycle): A framework that for the
activities performed at each phase of a software development project.

1. Explain why the waterfall model has very less utility in the modern
world.
B1965
Page No. 40
Unit 2
2. Provide three examples of projects that can be developed on the

prototyping model approach.
3. Explain the concept of software project life cycle with a suitable
example.
4. Explain how the V-shaped model is an enhancement of the waterfall
model.
5. Explain the four phases of the RUP.
2.8 Answers
1. False
2. Step-by-step
3. Telecom billing solutions
4. Capability Maturity Model
5. Communication
6. Construction
7. Reuse
8. Template
9. Transition
10. Waterfall
11. False
12. Amigos
13. Waterfall
14. High-quality
15. Phase-wise
Terminal Questions
B1965
Page No. 41
Unit 2
2.9 Case Study

Client Background
Arun Kumar founded the Signals and Systems in the year 2007. Signals and
Systems is a subsidiary of Cable and Network Signals. The Cable and
Networks Signals is owned by Yash Singhania. It is one of the leading
companies in Telecommunication equipments, embedded software
systems, medical equipments and computer networks holding operations in
many other countries.
Business Need
Signals and Systems was planning to adopt the software engineering
practices to ensure continuous improvement and wanted to get a Capability
Maturity Model Integration (CMMI) certification for its company, since
obtaining a CMMI certification is considered as a benchmark standard. To
achieve this, a lot of documentation and knowledge of tools were required.
Therefore, the company required a mentor who was specialised and had the
potential to train. Also software engineering practices were to be
implemented.
Cable and Networks Signals Solution Implementation
A formal training was given to the employees in the company with regard to
software testing concepts and techniques, object-oriented analysis and
design and configuration management along with the usage of several tools
related to software testing. Process models were introduced to have a
systematic approach.
Benefits
CMMI level 3 was achieved, which included the following:
A well-defined and documented standard process was established.
Improvements were observed over a period of time.
Consistent process performance was established in the organisation.
The employees in the organisation became confident and well-versed in
using the tools and also solved problems using the correct process
model.
B1965
Page No. 42
Unit 2
Discussion Question:
1. Discuss how the company followed a systematic approach in attaining
CMMI Level 3.
References/E-References:
References:
Aggarwal, K. K (2007), Software Engineering. New age International

publishers,
Pankaj Jalote. (2010). Software Engineering A Precise Approach.

Daryaganj, New Delhi : Wiley-India
Roger S Pressman. (2010). Software Engineering A Practitioner

Approach. McGraw-Hill Higher Education.
A. A. Puntambekar. (2007). Software Engineering. Pune: Technical

Publications
E-References:
www.ibm.com/software/awdtools/rup/. (Retrieved on 8th May 2012.)
B1965
Page No. 43
Unit 3
Unit 3
Agile Development Methodology
Structure:
3.1 Introduction to the Agility Concept
Objectives
3.2 Agile Development: The Manifesto
The agile process
Cost of change vis--vis traditional models
Extreme programming (XP) and agile processes
XP: In Summary
3.3 Other Agile Processes
3.4 Summary
3.5 Glossary
3.7 Answers
3.8 Case Study
3.1 Introduction to the Agility Concept

By now, we are familiar with several process models that have been in use
since the last few decades. However, the traditional models have not proved
to be entirely foolproof! They have been often described as highly
bureaucratic that has led to slowdown of several projects. This in turn has
led to time and cost overrun of several projects. Since the 1990s, software
researchers and practitioners have been working on an entirely different
paradigm called as agility. Ivar Jacobson, one of the three amigos of
object-orientation philosophy, has explained agility in his own words as
follows: Agility has become todays buzzword when describing a modern
software process. Everyone is agile. An agile team is a nimble team able to
appropriately respond to changes. Changes are what software development
is very much about. Changes in the software being built, changes to team
members, changes because of new technology, changes of all kinds that
may have an impact on the product they build or the project that creates the
product. Support for changes should be built-in everything we do in
software, something we embrace because it is the heart and soul of
software. An agile team recognizes that software is developed by individuals
working in teams and that the skills of these people, their ability to
collaborate is at the core for the success of the project.
B1965
Page No. 44
Unit 3
We can subject any software process to the philosophy of agility. The only
precondition for achieving is that we need to plan the process in such a
manner that would facilitate the software development team to alter the
work flow and keep them simple and lean enough, adopt a planning
paradigm that encourages the flexible nature of an agile development
approach and adopt a strategy of delivering software to the customer in an
incremental fashion, wherein each delivery will have new enhancements/
functionalities or modifications to the previous delivery. This way we can
ensure that the software gets live at the customer end more quickly than
what would have been possible in the traditional process methodologies.
Objectives:
Explain agility as the latest methodology for software development
differentiate between traditional software process models and agile
models
explain why the software fraternity adopted the agility philosophy
elucidate some of the important models of agile development
3.2 Agile Development: The Manifesto

Let us start this unit with a brief historical background that will set the tone
for the next set of discussions.
In 2001, Kent Beck and 16 other noted software developers, writers and
consultants (referred to as the Agile Alliance) signed the Manifesto for
Agile Software Development. It stated:
We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items
on the left more.
3.2.1 The agile process
Let us now study a bit more about the salient features of the agile process.
B1965
Page No. 45
Unit 3
An agile process is guided by scenarios (customer portrayal of the

requirements in story-board format), acknowledges that plans are not frozen
permanently and can be changed as and when required, builds software on
an iteration-basis and delivers the final software over several software
incremental deliveries, and adjusts to the changes that is bound to happen
during the entire duration of the project.
As mentioned earlier, agile approaches developed in the 1990s as a
reaction to document-driven approaches that were sometimes highly
bureaucratic. Most agile approaches have some common principles.
Working software is used as yardstick for measuring the progress of
software development.
The final software need to be delivered in multiple increments, with each
increment quite small.
The planning should be so adaptive that even changes desired during
the late stage of the project should also be accommodated.
Prefer face-to-face communications as opposed to relying mostly on
documentation.
Continuous response and continuous customer commitment and
enthusiasm are essential for an agile projects success.
Prefer simple design that evolves over time.
The software development team is authorised to determine the software
delivery dates. This is contrary to traditional methods, where typically a
top-management person may decide on the delivery dates and the
software development team have to then abide.
Thus, we can generalise and say that it is practically impossible to
predict in advance from a planning viewpoint all the aspects of analysis,
design, construction and testing.
You may have realised by now that we are talking of a process that can
manage unpredictability! We can achieve this only by being adaptable,
and that too incrementally, rather than being firm. Customer feedback is
essential in the agile process as also using an operational prototype that
will be iteratively developed.
3.2.2 Cost of change vis--vis traditional models
In traditional software developmental models, it has been observed that the
cost of change does not increase in a straight line pattern but rather in a
B1965
Page No. 46
Unit 3
non-linear fashion. The cost of change is minimal at the requirements

gathering stage and it is comparatively easier to accommodate a change
here as it is in the early stage of the project. However, as we move towards
the latter phases of the project we observe that the cost of change becomes
very high.
Proponents of the agile method have established that a well-designed agile
process can reduce the overall cost of change even in the later phases of
the project without significantly impacting cost and time.
3.2.3 Extreme programming (XP) and agile processes
Several agile methodologies have been introduced, some of which have
become very popular. Out of all these methodologies, Extreme
Programming (XP) is regarded as the most prevalent. Similar to other agile
approaches, it accepts the fact that changes will happen in the
requirements. Consequently, XP advocates that instead of belittling
changes as unwanted elements, the development ideology should be
evolved around the fact that changes are inevitable. Thus, the development
methodology needs to be flexible with the ability to respond quickly to
changes. Therefore, this method is based on development of software
iteratively, and sidesteps the problem of having to rely on comprehensive
and numerous documentation that are sometimes difficult to sustain and
maintain. This method encourages people-to-people communication to
make sure that the required changes are incorporated into the programs.
We will now briefly discuss the development process of XP which is by and
large a very good representation of a typical agile process.
The following points discuss the XP Planning in a nutshell:
Commences with the business analyst constructing user stories in
consultation with the customer.
The agile team members analyse each user story and estimate a cost to
it.
Next, the user stories are clustered together for the first and subsequent
incremental deliveries.
The agile team estimates the effort and sets the deadline for the
incremental delivery.
B1965
Page No. 47
Unit 3
Post-delivery of the first increment, estimates are worked out and

accordingly for other incremental deliveries, the delivery dates are
committed.
An XP project commences with user stories that are brief explanations
of the scenarios, which the customers and end-users want the
software to take care. This form is quite unlike the conventional
requirement specifications (explained later) mainly in explanation of the
details the user stories exclude thorough elaboration of the
requirements. Such detailing happens only at the time of construction,
thereby granting more time to the users for eliciting their requirements.
The authorised development team then makes an approximate
calculation of the time required to develop the user story into a software
increment. The estimates are expressed in weeks and are often
approximate figures that are imprecise. Once these estimates are ready
along with the user stories, the next step is to conduct release planning,
a step that finalises which of the user stories are to be incorporated in
which incremental delivery, and also delivery dates for each of these
deliveries. A series of frequent, small deliveries are preferred. The user
stories are also used to create the acceptance tests. Each incremental
delivery has to pass the acceptance test before final delivery to the
customer. The overall process is shown in Figure 3.1.
Fig. 3.1: The Overall Agile Process
Development takes place in a series of iterations where each iteration lasts

for about a few weeks. The first step in iteration is what is called as
iteration planning where we select the user stories to be incorporated in
that particular iteration. You should remember that those user stories that
are considered by the customer as having high-value and therefore, highrisk are given more importance and incorporated during the initial iterations.
There is always a possibility that in previous iterations there could have
been failed acceptance tests. Such failures are appropriately handled in
B1965
Page No. 48
Unit 3
subsequent iterations. The nitty-gritty details of the user stories are collected
and analysed during the iteration for developing the incremental delivery of
the software.
The developmental method adopted in the iterations follows certain
distinctive methods. First, development is taken up by pairs of programmers
(i.e. two programmers would be jointly developing code), instead of
individual programmers which is a very unique way of handling the software
project. Second, it encourages a reverse methodology wherein automated
unit tests are designed first even before writing the actual code. The actual
program that is written later should clear the first-written unit tests. This
methodology is called as test-driven development. As more and more
functionality gets added to the unit, the unit tests are also scaled up to
accommodate the new functionalities. After this step, the code is modified
so as to be able to clear the newly created unit tests. Third, because of the
inevitable changes, it is probable that the design developed earlier may
become inappropriate for further stages in the development. XP takes care
of this problem by encouraging a step called as refactoring. Refactoring is
employed to modify the design, after which the refactored program is
considered for the next level of development. While refactoring, only the
existing functionalities are considered and no new functionality is added.
The reason for this is that the design of the program under refactoring will
be greatly enhanced.
The discussion so far has provided us with a birds eye view of extreme
programming. Other rules for XP have also been framed that consider
matters like software developers and customers rights during the execution
of the project, interpersonal interactions among members of the team,
protocols for conducting meetings, etc.
The agile methods, including extreme programming, are appropriate only for
projects where the probability of frequent requirements change is very high,
leading to substantial requirements risks. Since such methods rely heavily
on continuous interactions among the team members, it is useful when
teams are preferably collocated and has relatively lesser number of
developers. Another point to be considered is that as agile methods
encourage continuous participation of the customer in the project for
deciding on important milestones, it is imperative that the customer should
B1965
Page No. 49
Unit 3
be made aware of the fact he must be willing to work as a pseudo-team

member and get involved at all stages of the project. Only then will the agile
methods be successful.
3.2.4 XP: In Summary
Strength
Weakness
Types of
projects
Agile and
responsive
Short delivery
cycles
Continuous
feedback can
lead to better
acceptance
Can tend to become

ad hoc
Lack of documentation
can be an issue
Continuous code
change is risky
Where
requirements
are changing
a lot, customer
is deeply
engaged in
development,
and where the
size of the
project is not
too large
1. In the spiral model, as we move from one phase to the other the cost of
change increases in a non-linear fashion. (True/False)
2. Agile process helps to manage certainty in a software project.
(True/False)
3. Which of the following models allow changes in later stages of the
software project - spiral, incremental, waterfall, agile?
4. XP commences with creation of _______ stories.
5. Which of the following process models would be most appropriate in a
situation where there the requirements risk is low spiral model/XP?
6. Agile methodology tends to give little or no importance to project
documentation. (True/ False)
7. The practice of using two programmers for jointly developing the code
is called as __________________.
8. During refactoring new functionalities are added. (True/False)
B1965
Page No. 50
Unit 3
Activity 1:
Imagine yourself as a project manager in a software company.
Describe how you would explain the concept of agile development to
your team. You will also need to explain to them how and why such an
approach is different from the other traditional approaches.
(Hint: Try to explain the differences by taking up a real-life situation.)
3.3 Other Agile Processes

We will now discuss very briefly about some of the other important agile
processes that are in existence. The processes that will be touched upon in
this section are the following:
Adaptive Software Development (ASD)
Dynamic Systems Development Method (DSDM)
Scrum
Crystal
Feature-Driven Development
Adaptive Software Development (ASD)
This method was originally proposed by Jim Highsmith. Some of the
distinctive features of the ASD are its mission-driven planning aspect,
component-based focus that helps in reusability and profuse use of timeboxing (a time management technique common in software planning where
the complete schedule is broken up into individual units referred to as timeboxes where each time-box has its own set of outputs, milestones and
budget). The other distinguishing features of the ASD include
comprehensive risk consideration and stresses on collaboration for
understanding requirements better. It also advocates that continuous
learning must happen throughout the project that can be used in future
projects to minimise risks.
Dynamic Systems Development Method (DSDM)
The DSDM methodology was promoted by the DSDM Consortium, created
in 1994 by a group of software engineering practitioners and software
vendors. The most important distinctive feature of DSDM is that it has nine
guiding principles, namely:
Active user involvement is imperative.
DSDM teams must be empowered to make decisions.
B1965
Page No. 51
Unit 3
The focus is on frequent delivery of products.

Fitness for business purpose is the essential criterion for acceptance of
deliverables.
Iterative and incremental development is necessary to converge on an
accurate business solution.
All changes during development are reversible.
Requirements are baselined at a high level.
Testing is integrated throughout the life cycle.
Communication and cooperation among all project stakeholders is
required to be efficient and effective.
Scrum
This is another popular agile methodology followed in the industry, originally
proposed by Schwaber and Beedle. The name scrum has been borrowed
from an activity in the game of rugby. Some of the distinctive features of the
scrum method are as follows:
The entire work is compartmentalised into packets.
Testing and documentation are simultaneous activities during the entire
phase of software development.
The development is taken up in sprints and the work to be done is
extracted from an accumulation of requirements to be fulfilled.
Very short duration meetings are conducted and sometimes in standing
position without the use of even chairs and tables.
Using the allotted time-box, simulations of the software are released to the
customer.
Crystal
This methodology was originally propounded by Cockburn and Highsmith.
Two of the distinctive features of this methodology are that there is a
provision of manoeuvrability based on problem characteristics and that it
emphasizes face-to-face communication.
Feature-Driven Development (FDD)
The FDD methodology was originally propounded by Peter Coad and
others. Two of the distinctive features of FDD are that the stress is on
defining features (a function that is valued by a customer and can be
B1965
Page No. 52
Unit 3
delivered in maximum 2 weeks) and that the design and construction

phases merge in FDD unlike other methodologies.
9. Which agile method gets its name from an act in the game of rugby?
10. DSDM stand for _____________________
11. Which of the following agile method suggests profuse use of the
concept of time-boxing
a. dynamic systems development method
b. adaptive software development method
c. scrum method
d. Feature driven development method
3.4 Summary
This unit introduced us to the latest methodology of software
development called agile methods. We understood why it became
necessary for software developers to adopt such an approach which
apparently goes against the philosophy of the traditional models that
stressed on documentations and other activities which often became
bureaucratic and slowed down the work. Agile methods tend to simplify
the process and also improve communication between the software
developers and the customers, deliver quick outputs and improve the
overall effectiveness of the development methodology.
While studying this unit, we also learnt about the important agile
methods such as XP, Scrum, DSDM, ASD, FDD and Crystal.
3.5 Glossary
Pair programming: Pair programming is a concept in extreme
programming where two software developers work together at a single
workstation. The developer who writes the code is called as the driver
whereas the other developer is called as the navigator. The navigator
checks each line of code as it is created by the driver. The two developers
swap their roles quite frequently.
B1965
Page No. 53
Unit 3
User stories: User stories, an integral part of extreme programming are

used to envisage the functionalities that a business system must provide,
and to help in understanding customer requirements better.

1. Explain how the philosophy of the agile software development
method is different from that of the traditional software development
methods.
2. There is a belief that Since agile methods attach little importance to
documentation there is always a risk that the process followed for
software development will be of low quality. Do you agree with this
statement? Justify your answer.
3. Explain three distinctive features of the agile process, as compared to
traditional methods.
4. Write short notes on the Scrum and DSDM approaches to Agile
Development.
3.7 Answers
1. True
2. False
3. Agile
4. User
5. Spiral Model
6. True
7. Pair Programming
8. False
9. Scrum
10. Dynamic Systems Development Method
11. b. Adaptive Software Development
Terminal Questions
B1965
Page No. 54
Unit 3
3.8 Case Study

A Dilemma Which Process Model to Use? (Part 2)
Let us once again consider the case study given in Unit 2. Assume that you
are working for a software company. Your company has been assigned the
task of carrying out THREE software projects, namely:
1. A Library Automation Software for Sikkim Manipal University where
the requirements have to be jointly finalised by your company and the
University.
2. A Management Information System Software for a medical store,
where the requirements are frozen in advance and there wont be any
more additional requirements
3. An Inventory Management Software for a retail chain where the
customer would like to be closely involved with the development process
as he is not very clear about his requirements.
1. Assume that in Unit 2, for each of the above three projects you had
decided on the software process model to be applied. Your project
manager analyses the projects and concludes that the Extreme
Programming approach would be suitable for all the above three
projects. Do you agree with his conclusion? Justify your answers.
References:
Jalote, P, Software Engineering A Precise Approach, Wiley India Pvt
Ltd, 2010
Pressman, Roger S. Software Engineering: A Practitioners Approach.
McGraw-hill Higher Education, 2010
E-References:
www.agilemanifesto.org (Retrieved on 30th April 2012)
www.agilemethodology.org (Retrieved on 30th April 2012)
B1965
Page No. 55
Unit 4
Unit 4
Software Requirements Analysis and the SRS
Structure:
4.1 Introduction
Objectives
4.2 Requirements Engineering
4.3 Software Requirements Specification (SRS)
Need and importance of the SRS
Roadmap to developing an SRS
Required characteristics of a good SRS
General layout and structure of a standard SRS
4.4 Use Case-Based Software Requirements
Fundamental concepts in use case methodology
An example of a detailed use case
Developing use cases
4.5 Summary
4.6 Glossary
4.8 Answers
4.9 Case Study
4.1 Introduction
A lot has been written about creating correct software systems that work
exactly as per the customer requirements. However, this is possible only if
the developer knows exactly what the customer needs and what the
software must do. Hence, a very important first step in building correct
software is to clearly define what the software must do. Identifying correct
and detailed user requirements is becoming even more important as the
world is moving towards more complex software systems with each passing
day.
In the software engineering context, requirements are used to create the
specification (in software parlance this is called as a software requirements
specification (SRS) that serves as the basis of contract between the
developer and the customer). Obviously, only when these requirements are
clearly specified in advance can we validate the developed software against
these requirements. In other words, keeping the SRS as a guidebook, it
becomes possible for every stakeholder to satisfy themselves whether or
B1965
Page No. 56
Unit 4
not the delivered software has satisfied all the requirements. The goal,
which is still proving to be extremely difficult to satisfy in totality, is to
develop such precise specifications for software requirements so that the
customer can precisely state what he requires and then validate the
delivered software.
Objectives:
describe the importance of requirements engineering in the software
development process
elaborate how requirements are elicited from customers
explain the importance of the SRS
elucidate use case methodology as the latest technique for specifying
functionalities
4.2 Requirements Engineering

Let us start our discussion by introducing you to the concept of
requirements engineering.
We will first try to understand the exact meaning of requirement as defined
by IEEE. It is defined as (a) a condition of capability needed by a user to
solve a problem or achieve an objective; (b) a condition or a capability that
must be met or possessed by a system to satisfy a contract, standard,
specification or other formally imposed document. Remember that in
requirements management we are aiming to detail out the requirements
and/or capabilities that a proposed software system has to deliver. We
discussed about several traditional process models and the agile model in
Units 2 and 3, respectively. All these models have this commonality that the
requirements have to be specified upfront. The only difference here is that in
case of agile models, detailed requirements are not required in the
beginning to start the project. As the project progresses, the requirements
are elicited by continuous interaction with the customer. Most of the
traditional approaches advocate the need for specifying requirements
precisely before the actual development work starts.
After understanding the concept of requirement, let us now try to
understand the concept of requirements engineering. Requirements
engineering can be defined as the act of understanding, structuring and
B1965
Page No. 57
Unit 4
accurately depicting the users requirements so that it can be correctly built

into the software systems that meet those requirements.
Requirements engineering is a very important element of the software
engineering process. Broadly, the entire activity of requirements engineering
can be split into six distinct steps, namely:
1. Plan the requirements engineering activities
2. Freeze the scope of the requirements
3. Extract requirements from the users
4. Analyse the requirements in terms of feasibility, and so on
5. Document the requirements
6. Verify requirements and seek user approval and obligation to the
documented requirements, as this forms the basis of contract
For the sake of brevity, we can consider the requirements engineering
process as consisting of three generic tasks requirements analysis,
requirements specification and requirements validation.
Requirements analysis Usually starts with a high-level problem
statement, that is, an expression of what the client is looking for as a
software-based solution to his problem. Remember that in this context,
problem need not be a problem at all; we can also consider requirements
for business enhancements, better output, and so on as a part of the
problem description. During the analysis phase, the problem domain and
the environment are simulated in order to understand the system behaviour,
constraints on the system, its inputs and outputs, and so on. The
fundamental purpose of this activity is to obtain a thorough understanding of
what the software needs to provide. Frequently, during analysis, the analyst
will have a series of meetings and interactions with the clients and
stakeholders. Through these interactions and scrutiny of documents
pertaining to the existing system, the analyst starts creating a picture of the
required system. The analysts understanding at each step is cross-verified
with the client and the end-users to reduce impedance mismatch so that
the analyst can be reasonably sure that he has understood the requirement
explained by the end-user clearly. The process of requirements analysis
ends when the analyst believes that all the requirements have been
understood by him.
B1965
Page No. 58
Unit 4
Requirements specification The next logical step in requirements

engineering, is formulated on the basis of the understanding obtained in the
previous phase of requirements analysis. Here the main focus is on
specifying the requirements in unambiguous terms. Another important focus
of this phase is to extract only those nuggets of useful information that need
to be addressed in the project. Usually the previous step leads to a lot of
information overload and filtering out the redundant information becomes
very important.
Requirements validation This process ensures that all the agreed-upon
client requirements have been included in the SRS. It also ensures that the
SRS is of high quality and conforms to the standard format.
The requirements engineering phase ends with the creation of a document
called software requirements specification (SRS). SRS illustrates only what
the proposed software should do. The implementation details of how it will
be done are not included in the SRS.
The SRS can be considered as a document that bridges the business
analysis team with the technical team that has to finally develop the
software.
Methods for eliciting and gathering requirements
Remember that defining user requirements involves understanding how an
existing system works and the problems that come associated with it. In this
section, we will examine some methods for collecting information in order to
develop such an understanding. There are several important issues to
consider in getting a holistic and clear picture of a system. One is to look at
the existing business processes in the system and uncover the tasks in
those processes. One can also start by probing specific system functions
and their tasks, which can then be examined in detail. Such examination
can reveal the users, who carry out the tasks, the interactions between the
users, the tools they use and the artefacts on which they operate. Thus, an
analyst must always take into account the users and their roles. How do the
users apply the artefacts? With whom do they interact? Where do they find
information? This has a significant influence on the way the system works.
Remember also that there is no such thing as a standard system as every
organisation is different and the manner in which work is done will vary from
one organisation to another. It is advisable, therefore, not to have
B1965
Page No. 59
Unit 4
preconceived ideas about a system and analysts must approach any study
with an open mind. There are four main ways of doing this, namely:
By asking questions By interviewing people in the system, through
surveys and questionnaires or by electronic means using e-mail or a
discussion board;
By observational studies By participating within the user
environment and ensuring that the analyst is also part of the typical work
life till the requirements engineering phase is over;
By prototyping In this case, we can prototype either the requirements
or the user interface; and
By formal sessions This includes structured workshops, group
discussions and facilitated teams.
Self Assessment Questions
1. Which of the following process models does not require detailed
requirements to be specified at the beginning of the project waterfall
model or agile model?
2. Requirements engineering consists of three generic tasks
requirements analysis, requirements ____________ and requirements
validation.
3. The requirements engineering phase ends with the creation of a
document called SRS. What does SRS stand for?
4. SRS bridges the ____________________ team with the technical
team.
4.3 Software Requirements Specification (SRS)

As explained earlier, a software requirements specification (SRS) is a
comprehensive description of the intended purpose and environment for
software under development. We shall study SRS in more detail in this
section. We begin by discussing the need and importance of the SRS.
4.3.1 Need and importance of the SRS
Typically, there are three sets of stakeholders in any software project: the
client (usually considered as the top management), the end-users
(employees of the client who will work hands-on on the software) and the
software developers. The needs are specified by the client, the software is
developed by the developers and the system is directly used by the endSikkim Manipal University
B1965
Page No. 60
Unit 4
user. Thus, we see that there is a clear disconnect between who requires
what and who develops it for them. This happens mainly because of a major
communication error usually the client does not understand software and
the software developers do not understand the business domain!
The fundamental need for the SRS is to bridge the communication gap so
that the client and the developer together have a joint and a shared vision of
the software proposed to be built.
The importance of the SRS can be gauged from the points given below
(extracted from IEEE 830 Standard):
SRS establishes the basis of agreement between the user and the
software developer.
o User needs have to be satisfied, but most probably the user may not
understand software.
o Developers will develop the system, but most probably may not be
an expert on the problem domain.
o Thus, SRS becomes the medium to bridge the communication gap
and specify user needs in a way in which both parties can
understand.
SRS provides clarity to the user regarding his own requirements.

o Typically, users do not always know their requirements.
o The requirements engineering process helps clarify needs.
SRS provides a reference for validation of the final product after it is

delivered.
o SRS provides an unambiguous understanding about what to expect
from the delivered software.
o SRS also helps in validating the delivered software by checking
whether the software satisfies the SRS.
High-quality SRS is essential for high-quality software.

o Requirement errors become apparent in the delivered software.
o A high-quality SRS will ensure that requirement errors are weeded
out before the development work starts. This will automatically lead
to a high-quality software.
B1965
Page No. 61
Unit 4
High-quality SRS reduces the development time and cost by guarding

against unnecessary rework that may have to be done at a later stage in
the project.
4.3.2 Roadmap to developing an SRS

Figure 4.1 shows the general process that is followed for developing a
typical SRS.
End-user
Requirements
Business
Domain
Requirements
Vision
Document
Non-functional
Requirements
Functional
Requirements
SRS
Fig. 4.1: General Process Followed for Developing SRS
In a nutshell, the general process is as follows: The understanding of the

business domain requirements coupled with the user requirements leads
the business analyst (who is an integral part of the software development
team) to create a vision document. A vision document is a summary
document created by a team in the early days of a project to build the case
for doing the project; agree upon the general scope and requirements at a
general from a customers viewpoint and obtain team alliance and seek their
agreement on the project definition. It serves as a base document for further
work on the project. This vision document sets the tone for defining the
functional and non-functional requirements that the software has to deliver.
An example of a functional requirement would be creating the balance
sheet and an example of a non-functional requirement would be voicebased interactivity in the software.
B1965
Page No. 62
Unit 4
These functional and non-functional requirements are what constitute a

major portion of the SRS. It has become a common practice in the recent
past to use use casebased specifications in the SRS, about which we will
study in Section 4.4.
4.3.3 Required characteristics of a good SRS
The IEEE standard specifies that the desirable characteristics of a good
SRS are as follows:
a) Correctness
b) Unambiguous
c) Completeness
d) Consistency
e) Ranked for importance and/or stability
f) Verifiability
These characteristics are explained briefly in the following paragraphs.
Correctness The SRS exhibits correctness only if every requirement

contained in the SRS portrays something required in the final software to
be delivered.
Unambiguous The SRS will be treated as unambiguous if, and only if,
every requirement stated therein can be interpreted in only one possible
manner. This is a major practical difficulty faced by software
practitioners as most of the words and sentences written in English are
susceptible to multiple interpretations that can cause major discord
between the customer and the development team.
Completeness The SRS exhibits completeness if everything the

software is supposed to do is specified in the SRS. A simple way of
checking this is to ascertain whether the contents of the SRS are
sufficient for the software designers to create the software.
Consistency The SRS exhibits consistency if there is no requirement

that contradicts another requirement. This is a common problem that
developers face.
Ranked for importance Very often a proposed new system has

requirements that are more of wish lists than having any practical value.
Some may not be achievable. It is useful to provide this information in
the SRS that will help the developers to prioritise the work based on
providing the most important functionalities first.
B1965
Page No. 63
Unit 4
Verifiability The SRS exhibits verifiability if, and only if, every stated
requirement is verifiable. As an example, it is useless to put in
requirements like: It should provide the user a fast response and The
system should never crash. Instead, it would make sense to provide a
quantitative requirement like: Every key tap should provide a user
response within 10 milliseconds.
4.3.4 General layout and structure of a standard SRS

In general, a typical SRS must specify requirements on the following:
Functionality
Performance
Design Constraints
Interfaces
The above points are briefly explained below:
Functionality This constitutes the core of the SRS document and

forms the bulk of the specifications. All the functionalities that the system
should support are specified. All data/information outputs for given
inputs and their relationship thereof are also specified. Furthermore, all
the operations the new system is expected to do are also to be specified
in the SRS. The behaviour for invalid inputs to the system is also
specified.
Performance This portion of the SRS deals with performance issues

of the software. Two types of performance requirements are
considered static and dynamic. The static requirements are also called
as capacity requirements and they do not inflict constraint on the
processing characteristics of the software system. Some examples of
capacity requirements are the number of simultaneous users to be
supported, number of website users that can log in simultaneously,
number of computer workstations to be supported, and so on. The
dynamic requirements typically contain response time and throughput
constraints on the software system. An example is every database
query should be answered within 1 second.
Design Constraints These constraints include the factors in the client

environment that restrict the choices. Some of these restrictions are
standard compliance and compatibility with other systems, hardware
B1965
Page No. 64
Unit 4
limitations, and issues of reliability, fault tolerance, backup and the most
important one security.
Interfaces These include all the interactions of the software with

various components of the software system, namely, people, hardware,
other software, database and network. User interface is often regarded
as most important because this is the direct zone of contact between
the user and the system. These days a lot of effort is being put on the
area of natural user interface, as explained in the earlier units.
A very broad general structure of the SRS is displayed below:

1.0 Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions and Abbreviations
1.4 References
1.5 Overview
2.0 Overall Description
2.1 Product Perspective
2.2 Product Functions
2.3 User Characteristics
2.4 General Constraints
2.5 Assumptions and Dependencies
3.0 Specific Requirements
3.1 External Interfaces
3.1.1 User Interfaces
3.1.2 Hardware Interfaces
3.1.3 Software Interfaces
3.1.4 Communication Interfaces
3.2 Functional Requirements
3.2.1 Mode 1
3.2.1.1 Functional Requirement 1.1
3.2.1.n Functional Requirement 1.n
3.2.x Mode x
3.2.x.1 Functional Requirement x.1
3.2.x.n Functional Requirement x.n
3.3 Performance Requirements
3.4 Design Constraints
B1965
Page No. 65
3.5
3.6
3.7
3.8
3.9
3.10
Unit 4
Attributes
Other Requirements
Behavioural Description
Validation and Criteria
Bibliography
Appendix
The above format has been standardised by IEEE. However, as per industry
practice, most software companies use their unique improvised version of
the IEEE format for the SRS.
Self- Assessment Questions
5. Whose viewpoint does a vision document contain the customer or
the software developer?
6. The SRS contains both functional and ________________ functional
requirements.
7. Sometimes in an SRS we notice that there are contradictory
requirements specified. Such an SRS will fail the test of ___________.
4.4 Use Case-Based Software Requirements

Traditionally, the approach for SRS has been functional specification,
wherein each function desired from the software is clearly specified. Use
Case Methodology, a relatively newer technique, has been developed for
specifying the functionality rather than the functions per se.
A use case, mostly in a story-board textual form, captures a contract
between a user and system about some functionality to be provided. This
story-telling mode has been found to be very effective as users are able to
understand the flow of the story and respond to it appropriately. Use case
diagrams portray the interactions between use cases (which symbolise
functionalities) and actors. Actors are stakeholders of the software system
and can be either actual people who interact with the system or any other
system that interacts with it. Figure 4.2 shows a use case diagram for an
ATM. There are two actors here (customer and bank manager) and four use
cases (withdraw cash, check balance, update e-mail ID and block issued
cheque). Note that the last use case, that is, block issued cheque, can be
initiated by both the customer and the bank manager. We can also add one
more actor to the diagram by the name of Credit Appraisal System, which
B1965
Page No. 66
Unit 4
would be part of another use case called Make Payment on Credit Card. In
this case also the new actor would be modelled as a stick figure.
Withdraw
Money
Update
Mobile No.
Check
Overdraft Limit
Make
Payment
on Credit
Card
Block
Issued
Cheque
Customer
Credit Appraisal
System
Bank
Manager
Fig. 4.2: Use Case Diagram for an ATM
A lot of information can be gathered from studying use case diagrams. This
is a very simple diagram and yet it shows the required functionality as
envisaged by the client. This is a very simple and yet powerful portrayal of
what a software system is supposed to deliver in terms of functionalities.
4.4.1 Fundamental concepts in use case methodology
As explained in the previous section, an actor is a person or a system that
interacts with the proposed system to achieve a goal. An example of a
goal is for a user of an ATM the goal could be to withdraw cash. We have
a terminology called primary actor the main actor who initiates the use
case. There is also a precondition that has to be fulfilled before the use
case can be realised.
A scenario is a group of actions executed to realise a goal under certain
conditions. A scenario can be subdivided into main success scenario and
alternative scenario. When things go normally and the goal is attained, we
call it as the main success scenario. When things go wrong and we fail to
attain the goals, we call it an alternate scenario.
B1965
Page No. 67
Unit 4
A use case is a collection of several such scenarios. The use cases specify
functionality by elucidating interactions between actors and system. The
focus is always on the external behaviour and we leave out the
implementation details completely. A very important point to be kept in mind
is that the use cases do not complete the SRS they only concentrate on
the functionality part.
4.4.2 An example of a detailed use case
Use case title - Online purchase
Primary actor - Online customer
Goal - Buy from the online store
Precondition - The online customer has logged into the website with his
login ID and password
Main Scenario
o The online customer selects items and drops them into the
shopping cart
o He proceeds to the checkout for payment
o He fills out his billing and shipping details
o System presents the pricing information along with shipping costs, if
any
o He types his credit card details along with the OTP (one-time
password, if applicable)
o The payment gateway authorises his credit card
o System confirms the purchase
o System sends a confirmatory e-mail along with e-invoice and informs
about the shipping time
Alternative scenarios
o 6a: Credit card approval unsuccessful
Allow the online customer to re-type credit card details up to a
maximum of three attempts
o 3a: For a regular online customer
The system displays the billing and shipping information. Seeks
permission from online customer to continue with it or change it
Proceeds to step 4
B1965
Page No. 68
Unit 4
4.4.3 Developing use cases

So far, we have understood that use case is an effective method of
specifying functional requirements as clients can respond to it better in
terms of understanding and comprehension. The other non-functional
requirements discussed in earlier sections need to be identified and
represented separately. A complete SRS will contain all the functional
requirements (in the form of use cases) along with other non-functional
requirements.
The use cases form a good platform for brainstorming and eliciting
requirements. As mentioned earlier, since the format is in the story-telling
manner, all the stakeholders can understand the flow quite easily. Typically,
the use cases are evolved in a stepwise manner where fine-tuning is done
at each step. The steps, as a quick summary, are as follows:
Identify the actors and the goals
Stipulate the main success scenarios
Stipulate the alternative scenarios (failure conditions)
Stipulate how to handle the alternative scenarios (i.e. failure-handling)
8. Traditional approach to SRS has been to specify __________.
9. Actors are either actual __________ or any other system that interacts
with the software system being developed.
10. Failure conditions are also called as __________.
4.5 Summary
Gathering and analysing requirements is a very challenging task for any

software development project. This is accomplished through the process
of requirements engineering, which is achieved in three generic stages:
requirements analysis, requirements specification and requirements
validation.
Requirements can be understood by a combination of the following

methods: asking questions, observation, prototyping and by formal
sessions.
B1965
Page No. 69
Unit 4
SRS forms the basis of agreement between the customer and the
developer where the functionalities to be provided by the software are
clearly laid out.
Traditionally, function-based specification was used to specify the

requirements in the SRS. Of late, it has become a common practice to
utilise use casebased specifications of functionalities.
The understanding of the business domain requirements coupled with

the user requirements leads the business analyst to create a vision
document. This vision document sets the tone for defining the functional
and non-functional requirements that the software has to deliver.
The IEEE has specified the desirable characteristics of a good SRS and
has also given a framework for creating the SRS document.
Use cases can be used very effectively to depict functionality. This is a

very simple way of presentation and very often the user can relate to it
easily as it is in a story-telling format.
4.6 Glossary
Business analyst: A person analysing a business at the business
functionality level.
Stick figure: A representation of an actor in a use case diagram.

1. Explain the concept of requirements engineering along with the three
generic tasks.
2. Explain the various methods we can employ in order to elicit
requirements from clients.
3. What is an SRS? Explain the need and importance for having such a
document.
4. What is a vision document? Explain the general process that is followed
for developing a typical SRS.
5. Describe the desirable characteristics of a good SRS.
6. What are the fundamental components of use case methodology?
Explain each one of them in detail.
B1965
Page No. 70
Unit 4
4.8 Answers
Self -Assessment Questions
1. Agile
2. Specification
3. Software requirements specification
4. Business analysis
5. Customer
6. Non-functional
7. Consistency
8. Functions
9. People
10. Alternative scenarios
Terminal Questions
4.9 Case Study

Use Cases for Fab Cabs
Fab Cabs is a small business that specialises in the manufacturing of
standard and custom office cabinets. When they started out a few years
ago, there were few enough jobs such that they could simply keep track of
the orders on paper. As their reputation grew, however, they started to
receive more and more orders. They began to hire new cabinetmakers, and
within 3 years had grown to a shop with over 100 employees.
Although it was still a relatively small company, Fab Cabs had grown just
too large to continue to rely on manual processes. Hence, the promoters
roped in a consultant to advise them on the system that would be needed
for the same.
From the discussions that emanated, the consultant was able to determine
that the proposed new system needed to support adding new orders,
B1965
Page No. 71
Unit 4
modifying existing orders, filling orders, checking current inventory levels

and restocking the inventory. When a new order is added, the system would
need to notify the accounting system, so that an invoice can be generated.
1. Assume that you are the consultant. You are required to identify at least
three use cases for the order processing system.
2. You are also required to elaborate each of the use cases identified,
clearly mentioning Primary Actor, Goals of Stakeholders,
Precondition, Main Success Scenario and Alternatives.
References:
Jalote, P, Software Engineering A Precise Approach, Wiley India Pvt
Ltd, 2010
Roger S Pressman, Software Engineering A Practitioners Approach,
E-References:
www.ieee.org (Retrieved on 4th May 2012)
B1965
Page No. 72
Unit 5
Unit 5

(Project Planning and Project Estimation)
Structure:
5.1 Introduction
Objectives
5.2 Project Management Process
Initiation phase
Planning and estimation phase
Scheduling and tracking phase
Tracking
Risk analysis phase
5.3 Software Project Planning
Project scope
Resources
Tools
5.4 Software Project Estimation
Estimation models
Empirical estimation model
The Constructive Cost Model (COCOMO)
COCOMO in a nutshell
Delphi model
Estimation techniques
5.5 Summary
5.6 Glossary
5.8 Answers
5.10 Case Study
5.1 Introduction
In Units 1, 2 and 3, you have studied some important concepts in the
software engineering process that include software as a product and a
process, important traditional software development process models and
the latest paradigm of development called the agile methodology. We have
also discussed about the requirements engineering and the most important
software document called software requirements specification (SRS) that
B1965
Page No. 73
Unit 5
lists out the functionalities to be provided by the software and also the other
non-functional requirements in Unit 4.
In this unit, we will study about the first part of software project management
including the project management process that has four phases (initiation
phase, software planning and estimation phase, scheduling and tracking
phase and risk analysis phase). We will also discuss about software project
planning and a very important aspect of project management called
software project estimation. We will study the Constructive Cost Model
(COCOMO) that helps us to estimate software projects in advance. This
helps in developing an initial budget and cost plan for the software project.
Objectives:
explain the different project management processes
describe about software project planning
elaborate on project estimation techniques and models
5.2 Project Management Process

We begin our discussion with Project Management Process as a first step
to understanding project management concepts. In order to understand the
process better, we will first try to answer a fundamental question What is
Project Management?
Very broadly, we can define project management as the first phase in the
software engineering process. It is generally called as a layer and not as an
activity or step, as it covers the entire software development process from
the beginning to the end.
When a software project is undertaken, you must understand the way in
which the task has to be done. Before starting your project, you must
proactively analyse some of the risks involved in starting the project such as
required resources, tasks to be accomplished, milestones to be tracked and
the schedule to be followed. All these will be discussed in Unit 6.
The project management process is generally driven by the Capability
Maturity Model Integration (CMMI) and is based on a series of several small
tasks that are executed depending on the requirement.
B1965
Page No. 74
Unit 5
The project management process or life cycle has four stages as shown in
Figure 5.1.
Fig. 5.1: Project Management Process
We will now describe the four phases portrayed in Figure 5.1, in the
following subsections. We will also discuss the details of software project
planning, software project estimation, software project scheduling, software
project tracking and control and software risk management in the
subsequent sections.
5.2.1 Initiation phase
The Initiation Phase is the first phase of software project management and
this is where all the information related to the requirements of a software
project is garnered. We have studied about this phase in Unit 4 under
requirements engineering. This is perhaps the most important phase, as
the scope of the project gets frozen based on the garnered information.
Before any project commences, it is imperative that we establish the
objectives and scope of the project. We must also identify the technical and
management constraints/difficulties to define accurate information related to
cost, break down of project tasks and project schedule and appointing
project teams. The objective of the project is to deliver the software under
consideration to the customer in such a manner where all the agreed-upon
requirements are fulfilled and there is no cost and/or time overrun. The
scope of the project is to identify the functionalities of the software. Without
understanding and freezing the scope of a project, it is not possible for us to
B1965
Page No. 75
Unit 5
achieve success and fulfil the customers requirements that he has

envisaged in the software.
Let us now understand the various activities performed under this phase, as
shown below:
Analysing business needs
Reviewing the current operations and the existing system
Analysing the financial costs and benefits including budget
Analysing stakeholder, including users and support personnel for the
project
5.2.2 Planning and estimation phase
This is the second phase of the project management process. In this
process, a project team that was appointed in the initiation stage, plans for
the next phase and sets up the vision to implement and achieve the goals
set for the project. The objectives and the scope of a project are considered
in the planning phase. We can make estimations of a project on the basis of
past experiences on a project using what we call as historical data. For this,
we can compare the new and an earlier project, and if they appear similar,
then we may conclude that the new project is more likely to require
approximately the same time duration (often expressed in calendar months)
and the same effort (often expressed in person-months). Person-month
costs for each level of software developer are usually calculated on a yearly
basis and simple multiplication of the effort with the person-month cost will
give us the approximate cost for the project. Using these base figures for
cost and time, we analyse the cost of the entire project and the time
required to complete the task along with the human resources involved. If
we falter in the estimation task, as a part of the planning phase itself, the
chances of project failure become high.
There are several software project estimation techniques such as Rayleigh
Model, Putnams Software Lifecycle Model (SLIM), COCOMO or Delphi
Technique, which have their own advantages and disadvantages. The
project manager decides the estimation techniques to be used. In typical
project estimation, the following attributes are most commonly followed:
Establishment of the project scope in advance
Usage of the past measurements of software metrics to make estimates
B1965
Page No. 76
Unit 5
Breakdown of project into small pieces which are estimated individually1
Planning phase consists of the following activities.

Creating a project plan
Creating a resource plan
Creating a financial plan
Creating a quality plan
Creating a risk plan
Creating an acceptance plan
Creating a communication plan
Creating a procurement plan
Contract with the suppliers
Perform phase review2
Sometimes, the management identifies the roles and responsibilities, and
the requirements of a project, by conducting several meetings.
5.2.3 Scheduling and tracking phase
After taking a birds-eye view of the planning and estimation phases of a
project, we will now discuss the next phase of project management process,
namely, scheduling. Every software project needs to be scheduled and
must have a scheduled start and end time to which we must adhere, in
order to fulfil our goal of delivering the software within the committed time. It
also involves budgeting for the project. Goals are set for the project teams
for which the team members have to achieve their targets on time. When a
project is identified, its various interdependent tasks are also identified and
analysed and a schedule is fixed for each of them. For completing each
task, the required resources including the number of people at various
designations (e.g. project manager, architect, programmer, tester,
configuration manager, etc.) are identified. Thus, it creates a task network
that provides details about the development of time schedule.
A project schedule defines the approach to be followed, by selecting the
appropriate template for a particular project. We break the respective tasks
assigned in a particular project into smaller tasks, and fix the date of
completion along with the cost involved for the task. We have to keep in
1
2
Software Engineering: A Practitioners Approach by Roger S. Pressman.

B1965
Page No. 77
Unit 5
mind the customers detailed requirements and follow the processes in a

systematic way as advised by the management. We will also need to take
care of the requirements of the project, related to software, hardware and
training resources, along with meeting the project schedules.
5.2.4 Tracking
When the development activities start in a project, we must start tracking
and controlling tasks simultaneously in the project. The tasks that are
mentioned in a task network are tracked by the project manager. Each time
a task is found to be lagging behind schedule, the manager will use
automated project scheduling tools to determine the impact of the schedule
slippage and how it can hamper the interdependent tasks and project
delivery dates. He will also need to work out the correction path so as to
bring the project back on track.
Despite the best efforts of the development team, tasks may sometimes lag.
Such lags can affect the project and some of the impact of a lagging
schedule could be redirection of resources, reordering of tasks, postponing
of delivery schedules/commitments, and so on. Nowadays, companies use
a lot of tracking methods to ensure that tasks are completed as set, and are
also prepared to handle tasks that are running behind schedule.
5.2.5 Risk analysis phase
This is the last phase in project management, but not the least, as risk
analysis is very essential in any project. The word risk means uncertainty.
So, when a software program is built for a particular project, there is some
amount of risk involved. Let us now see the different risks involved.
Was the customers need understood?
Can the tasks be implemented before project deadlines?
Will there be any hidden technical problem (not appearing to us, but
may appear to the customer)?
Will the changes made to a task, impact the other tasks and cause
programs to run off schedule?
Basically, risk management is a proactive method to ensure that if any of
our fears (uncertainty) regarding the project becomes a reality, we will not
be caught off-guard as we have taken sufficient precaution.
B1965
Page No. 78
Unit 5
Although risk analysis is the most crucial part of a project, many projects are
undertaken without any consideration of risk. Tom Gilb says, If you do not
actively attack (project and technical) risks, they will actively attack you.3
We can define risk analysis as a series of risk management steps that
enable us to attack risk. The different risk management steps are as follows:
Risk identification
Risk assessment
Risk prioritisation
Risk management strategies
Risk revolution
Risk monitoring
1. The four stages of project management life cycle are initiation, planning
and estimation, scheduling and tracking and ______________.
2. Rayleigh Model and COCOMO are project estimation techniques.
(True/False)
3. What does SLIM in Putnams SLIM model stand for?
Activity 1:
Imagine you are a project manager in a software company, explain how
you will plan a project and implement each steps mentioned in the above
section.
(Hint: Project management process. Refer section No. 5.2)
5.3 Software Project Planning

We will start our discussion with the concept of software project planning
which will help us to take our discussion forward.
As mentioned in the earlier sections, software project planning is the first
phase in the software management process. The process of planning
involves a detailed study of the software requirements specification
document that you learnt in Unit 4. After studying the document, a
framework for the entire software project is created that enables the project
manager to decide estimates related to cost, schedule and resources
3
B1965
Page No. 79
Unit 5
needed for the software project. In real-world software projects, the

estimates are usually not constant; rather they keep varying depending on
the progress of the software project.
The main goal of planning a software project is to establish/identify the
scope of the project. After identification of the project, it is divided into
smaller tasks for easier management. This enables successful completion
of the software project.
5.3.1 Project scope
We will now study about the scope of a software project.
Determining the scope of the software project is the first activity of project
planning and it is very important to identify the specific business goals that
must be achieved by the software.
The objective of the software-delivering project must always address the
business needs. The scope under which a project needs to be carried out
must be well defined before the commencement of the software project.
The executive team must ensure that the following steps are followed:
The project mission must be clear and concise.
The teams must understand the objectives throughout the project.
The overall timelines and schedules are established as part of the
goals.4
A software project must always have the following scope:
The functionality and the performance of the project must be
unambiguous and clear to both the management and the technical
teams.
All data related to the constraints, limitations of the software product,
product cost and algorithms must be described clearly.
The cost and schedule-related estimates should be defined.
A software project plan should have a well established and managed set
of goals and must be documented. When you start a project, you must
make sure that you dont move away from the set goals, as this can
make your project run off schedule and the budget might soar.
http://ezinearticles.com/?What-is-Project-Planning-and-Scope?&id=3895197
B1965
Page No. 80
Unit 5
5.3.2 Resources
We have already discussed about the first task of software project planning,
namely, scope of a software project. Now, we will discuss the second task
of software project planning, which comprises estimating the resources
required for a project. There are three different types of resources required
for a software project.
Human resources Estimation of human resources includes the selection
of the right skilled candidates, so that the project can be completed
successfully. We recruit professionals at various organisational positions
such as software project manager, software engineer and tester along with
the specified domains. The number of people required for a software project
is determined by the total effort required for the project expressed in personmonths or person-years.
Hardware resources We need to estimate the hardware components
required for the project. This includes estimation of all computer-related
peripherals used during the development of the software, the target
machine on which the software is executed, other hardware elements used
for software development, and so on.
Software resources Estimation of software resources means the
estimation of all the software required for the development of software under
consideration. This also includes licensing costs for various other software
that are required for the implementation, such as IBM Rational Rose, IBM
Rational Clearcase, Microsoft VSS, Microsoft Projects, and so on.
5.3.3 Tools
After the discussion on estimation of resources required for a project, let us
now familiarise ourselves with different types of tools used in software
project planning.
Table 5.1 gives a fair idea about the different tools.
Table 5.1: Tools for Software Project Planning
Tool
Description
Business Systems
Planning Tool
Provides information related to origin of critical business

data. It also provides more information pertaining to its
usage, the way it can be transformed through different
businesses.
B1965
Page No. 81
Unit 5
Helps the software developers to create information
systems that can route information to those who need it.
Enables quick transfer of data and delayed decision
making.
Project
Management Tool
Helps in generating estimates like effort, cost and duration

of a software project.
A work breakdown structure is defined.
Helps in planning a workable project schedule and
tracking them on a continuous basis.
Enables the project managers to collect the metrics that
can be used as a baseline for both software productivity
and software quality.
Support Tools
Include different tools such as documentation tools,

network system software, electronic mail and databases.
Used to control and manage the information that is
created during software development.
Analysis and
Design Tools
Helps the software developer to create a model of the

system that is to be built.
Evaluates the software models quality and aids in
performing consistency and validity checking on each
models.
Provides insight to software engineers to eliminate the
errors before they are encountered in a program.
Programming Tools
Editors, system software utilities come under this tool.

Powerful programming tools can also be added on to
them.
The object-oriented programming tool and advanced
database query systems fall under this category.
Maintenance Tools
The maintenance tools provide the software engineer with

insight, so that intuition, design sense and human
intelligence can be applied to complete the reverse
engineering process or re-engineer the application.
Framework Tools
Used to create an integrated project support environment.

These tools provide database management capabilities.
B1965
Page No. 82
Unit 5
4. ___________ team must ensure that the project mission is clear and
concise.
5. In real-world software projects, do the initial estimates change over
time?
6. The three different types of resources required for a software project
are hardware resources, software resources and _________
resources.
7. Which software project-planning tool helps software developers to
create information systems that can route information to those who
need it?
Activity 2:
Imagine yourself as a project manager and explain how you would plan
your project.
(Hint: Software project planning. Refer section No. 5.3.)
5.4 Software Project Estimation

In the previous section, we discussed about the software project planning
tasks. In this section, we will discuss some of the different software
estimation techniques and models used for estimating a software project.
Software project estimation is the first phase of project planning and it is the
process of predicting a cost for developing a software product and solving
the problem associated with the software project. Many technical and
environmental variables can affect the cost and the effort involved in a
software project. In order to ensure that we arrive at reliable cost and effort
estimates, we need to follow the below-mentioned steps:
Develop an empirical model for both cost and effort.
Use automated estimation tools.
Use simple decomposition techniques to generate project cost and effort
estimates.
5.4.1 Estimation models
Software is very expensive and estimation errors can make a huge
difference between profit and loss to the software vendor. Hence, software
estimation plays an important role in a software project management
B1965
Page No. 83
Unit 5
activity. Let us now discuss about the different estimation models involved in
a software project.
5.4.2 Empirical estimation model
The empirical estimation model uses empirically derived formulae in order to
predict the data required for software project planning. These empirical data
are derived from a sample taken from earlier projects. Hence, this model is
not very appropriate for all software development environments and must be
used only after analysing and deciding wisely.
5.4.3 The Constructive Cost Model (COCOMO)
We can consider the constructive cost model or COCOMO as a software
cost estimation model. This model, proposed by Barry Boehm, uses
historical data as well as the current project characteristics. In order to
estimate cost, effort and schedule in a project, we use COCOMO model.
There are three different types of COCOMO models as given in Figure 5.2.
Single Variable Model
COCOMO
MODEL
TYPES
Static Multi-Variable Model
Dynamic Multi-Variable Model
Fig. 5.2: Types of COCOMO Model
Single variable model We use single variable COCOMO, where a

quick and rough estimate of cost of a software project is to be done.
However, it is not very accurate.
Static multi-variable model The static multi-variable model takes
care of the cost drivers which could not be handled in the single variable
model.
Dynamic multi-variable model The dynamic multi-variable model
projects the resource requirements as a function of time. If the model is
derived empirically, then the resources are defined in a series of time
steps, which will allocate a percentage of effort to each step in the
software development process.
B1965
Page No. 84
Unit 5
A complete description of the COCOMO is beyond the scope of this course.

However, we present below the model in a nutshell so as to give you some
idea of how we do the software estimation even before starting a software
project.
5.4.4 COCOMO in a nutshell
Step # 1: Choose the COCOMO version
There are three versions of COCOMO.
Basic
Intermediate
Detailed
Step # 2: Choose the COCOMO mode
There are three software development modes.
Organic
Semi-detached
Embedded
PARAMETERS FOR IDENTIFYING THE COCOMO MODE:
Organic mode characteristics:
Small product size (<50 KLOC) {KLOC stands for thousands lines of
code}
Small, in-house development team
Development team experienced in application area
Relaxed (negotiable, informal) specifications on function and
performance requirements
Minimal communication overhead
Stable development environment
Minimal schedule pressure
Existing, proven technology used
Some examples are engineering, scientific and business applications,
inventory control system, and so on.
Semi-detached mode characteristics:
Size may range up to 300 KLOC
Development team personnel is a mix of experienced and inexperienced
in the application and development environment
B1965
Page No. 85
Unit 5
Mix of relaxed and rigid specifications

Lies between the organic and embedded mode
Moderate schedule pressure
Examples are DBMS, simple command and control systems

Embedded mode characteristics:
Size may vary from 20 to 1000 KLOC
Rigorous specifications
Product must operate within time constraints on internal and external
interface service, processing and interrupt service
Product must meet rigid, formal quality standards
Close coupling required among software, hardware and operators to
meet function and performance requirements
Extensive testing required
Leading edge technology required
Other system components developed concurrently with software
Strong schedule pressure
Examples are avionics software systems, operating systems and real-time
systems.
Step # 3: Calculate the nominal estimate of Effort (Enom) in person-months
(PM) using the formula
Enom = a * (KLOC)b
Table 5.2: COCOMO Multipliers and Exponents
Product type
Multiplier (a)
Exponent (b)
Basic
Intermediate
Organic
2.4
3.2
1.05
Semi-detached
3.0
3.0
1.12
Embedded
3.6
2.8
1.2
Step # 4 : Calculate the nominal development time (Td)

Organic : Td = 2.5 * (Enom)0.38
Semi-detached : Td = 2.5 * (Enom)0.35
Organic : Td = 2.5 * (Enom)0.32
If we are using the basic model, we have got the estimates and nothing
more needs to be done.
B1965
Page No. 86
Unit 5
Step # 5: Fine-tune the estimates by computing the Effort Adjustment

Multiplier (for Intermediate version only)
The 15 cost drivers are:
Product Attributes
RELY: Required Level Of Reliability
DATA: Size of database used by the system
CPLX: Complexity of software product
Computer Attributes
TIME: Execution Time constraints
STOR: Main storage constraints
VIRT: Virtual Memory Volatility
TURN: Computer Turnaround Time
Personnel Attributes
ACAP: Analyst capability
AEXP: Experience in the application area
PCAP: Programmer capability
VEXP: Experience with the host virtual machine
LEXP: Experience with the programming language
Project Attributes
MODP: Effect of modern programming practices
TOOL: Use of advanced software development tools
SCED: Schedule constraints
Next, categorise the cost drivers as low, very low, nominal, high, very high
and extra high.
Table 5.3: COCOMO Multipliers for Cost Drivers
Attributes
Very
low
Low
Nominal
High
Very
high
Extra
high
Product related
RELY
0.75
0.88
1.00
1.15
1.40
DATA
0.94
1.00
1.08
1.16
CPLX
0.70
0.85
1.00
1.15
1.3
1.65
B1965
Page No. 87
Unit 5
Computer related
TIME
1.00
1.11
1.30
1.66
STOR
1.00
1.06
1.21
1.56
VIRT
0.87
1.00
1.15
1.30
TURN
0.87
1.00
1.07
1.15
Personnel related
ACAP
1.46
1.19
1.00
0.86
0.71
AEXP
1.29
1.13
1.00
0.91
0.82
PCAP
1.42
1.17
1.00
0.86
0.70
VEXP
1.21
1.10
1.00
0.90
LEXP
1.14
1.07
1.00
0.95
MODP
1.24
1.10
1.00
0.91
0.82
TOOL
1.24
1.10
1.00
0.91
0.83
SCED
1.23
1.08
1.00
1.04
1.10
Project related
The product of the 15 values chosen will be the Effort Adjustment Multiplier
of the nominal effort and time calculated for the basic version above.
We will work out a numerical problem at the end of the next unit (Unit 6)
after you learn about function points. This will enable you to get a better
understanding of the COCOMO estimation method in tandem with function
point analysis.
5.4.5 Delphi model
The Delphi model is based on the expert opinion. This model follows a
systematic and interactive forecasting method and depends on a panel of
experts. A structured group of experts provide a more accurate solution
when compared to an unstructured group. The interaction is similar to faceto-face interviews/meetings. Hence, it is widely used for business
forecasting.
B1965
Page No. 88
Unit 5
5.4.6 Estimation techniques

After discussing about the estimation models, let us now discuss some
techniques used for estimating time and cost of a project.
We use estimation techniques to solve problems in a project. The common
problems that a software project can face are the problems related to cost
and effort. Therefore, it becomes very necessary to incorporate the cost and
the effort estimation techniques.
We can use the decomposition technique for project estimation. In the
decomposition technique, we divide a complicated problem in a project into
several smaller and manageable units. Appropriate estimation techniques
are used on the basis of the scope of the software to be built. Lines of
Code (LOC) and Function Points (FP) are two decomposition techniques
used for estimating the effort in a software project, as given in Table 5.4.
Table 5.4: Decomposition Techniques
Line of code
Function point
It
is
a
decomposition
technique used on the basis
of the size of line of code in
a software project.
The
line
of
code
decomposition
technique
uses all the intricate details
in a program.
A direct estimation is done in
the line of code method.
It is a decomposition technique
that uses the baseline metrics
collected from the previous
projects.
It uses only the macroscopic
details in a program.
It is determined indirectly by
estimating the number of inputs,
outputs, data files and external
interfaces.
By using data collected from the project, the project planner estimates
optimistic, pessimistic and most likely LOC or FP value for each function.
8. COCOMO stands for ____________________.
9. The three COCOMO modes are organic, semi-detached and
____________.
10. COCOMO was created by Bill Gates. (True/False)
B1965
Page No. 89
Unit 5
Activity 3:
Suppose you are working in a software company. Prepare a list of
estimation techniques and estimations models used in software project
estimation, in your company.
(Hint: Estimation technique and estimation models. Refer Section No.
5.4)
5.5 Summary
The project management process is the first phase in software
engineering. This phase includes several tasks such as measuring,
scheduling, tracking and analysing the risks involved in a project
management process.
The phases of software project planning indicate us about how we can
handle a project whenever we are assigned a new project/project task.
They enable us to correlate the various techniques and models and
implement them in a software project.
Software project estimation is an essential part of software project
management. This is very challenging because the estimate has to be
made at a very early stage of the project where the requirements are still
not totally clear. Errors in the estimation process can lead to two
situations: under-quoting for a project (that will lead to financial losses
for the developer) or over-quoting for the project (that may lead to losing
out on the project if it is in the tendering stage).
COCOMO is an effective model that helps us in estimating the effort
(measured in person-months) and also the time duration (in calendsmonths) required to complete a project from start to finish.
5.6 Glossary
Baseline: A line serving as a basis, as for measurement, calculation or
location.
CMMI (Capability Maturity Model Integrated): It is the certification given
by the Software Engineering Institute by the United States.
COCOMO (Constructive Cost Model): It is an algorithmic software cost
estimation model developed by Barry Boehm. The model uses a basic
B1965
Page No. 90
Unit 5
regression formula, with parameters that are derived from historical project
data and current project characteristics.
Delphi: It is a systematic, interactive forecasting method that relies on a
panel of experts. The experts answer questionnaires in two or more rounds

1. Define software project management process and briefly explain its
phases.
2. Explain the three resources used in project planning and describe the
different tools of planning.
3. Describe the COCOMO model and briefly discuss its types.
4. Explain the Delphi model.
5. Describe the various tools used for software project planning.
5.8 Answers
1. Risk analysis
2. True
3. Software Lifecycle Model
4. Executive
5. Yes
6. Human
7. Business Systems Planning Tool
8. Constructive Cost Model
9. Embedded
10. False

1.
2.
3.
4.
5.
(Refer to Section 5.2 for further information.)

B1965
Page No. 91
Unit 5
5.10 Case Study

Integrated Project Management System
The Indian Railways is considered to be the largest rail network in Asia
and the second largest under one management as it has a workforce of 2
million.
Challenge:
The Ahmedabad division managed the various construction projects for that
particular region. They were in need of an integrated application that would
help them to manage their project estimation, tendering, procurements and
tender evaluation process. Apart from this, the application also managed
several other systems such as project monitoring, financing, billing and
tracking and integration of the billing and accounting systems. It generated
various project status reports for submission to other authorities as well as
the internal reports.
Avalanche software solutions came up with a design and developed and
implemented an integrated project management system (IPMS) application.
The IPMS provided better project management facilities such as
tendering/bidding process, procurement assistance and tender evaluation
and contract management which included project tracking and billing and
produced customised reports. The most important part of the application
was its ability to manage and track actual project expenses, approving bills
and overall project accounting.
Technology used: VB 6.0, MS Access 2000, Adobe Photoshop 5.0, Crystal
Reports 8.05.
Explain the challenges faced by the construction group in Ahmedabad and
how they overcame it.
(Hint: Project management planning.)
References:
Haug, Michael, Olsen, Eric W., & Bergman, Lars. Software Process
Improvement: Metrics, Measurement, and Process Modelling.
4. http://www.indusa.com/government_casestudy4.php?action=microsoft
B1965
Page No. 92
Unit 5
Kan, Stephen H. Metrics and Models in Software Quality Engineering.

E-References:
www.softstarsystems.com/overview.htm (Retrieved on 17th May 2012)
B1965
Page No. 93
Unit 6
Unit 6

(Project Scheduling, Tracking and
Risk Management)
Structure:
6.1
Introduction
Objectives
6.2
Software Project Scheduling
Gantt chart
6.3
Software Project Tracking and Control
6.4
Software Risk Management
Risk analysis
Risk identification
Risk assessment
Risk analysis reports
Risk monitoring
6.5
Project Metrics
Size-oriented metrics
Function-oriented metrics
6.6
Summary
6.7
Glossary
6.8
Terminal Questions
6.9
Answers
6.10 Case Study
6.1 Introduction
By now, we have explained to you the important concepts in the software
engineering process. So far, we have discussed about software as a
product and a process, important traditional software development process
models and the latest paradigm of development called the agile
methodology. We have also discussed about requirements engineering and
the most important software document called the software requirements
specification (SRS) that lists out the functionalities to be provided by the
software and also the other non-functional requirements.
B1965
Page No. 94
Unit 6
In this unit, we will study about software project management, which

includes four phases, namely, initiation phase, software planning and
estimation phase, scheduling and tracking phase and risk analysis phase.
We will also discuss about project metrics and analyse the size-oriented
metrics and function-oriented metrics.
This unit will enable us to analyse how we can measure project
management activities using project metrics.
Objectives:
elaborate the different project management processes
describe project metrics (size-oriented and function-oriented metrics)
explain about software project planning
elucidate project estimation techniques and models
explain project scheduling, tracking and control
elaborate risk management
6.2 Software Project Scheduling

In Unit 5, we studied estimation models and techniques and how they help
in estimating a software project. Let us now understand how software
projects can be scheduled to ensure that the software project is on target.
A software project has to be scheduled accurately, as any kind of schedule
slippage can affect the cost and effort involved in the software project.
Therefore, while scheduling a project, we must adhere to the following
points:
Establish a bridge between chronological time and the human effort.
Use milestones to show progress.
Distribute effort throughout the software engineering process.
Check for availability of scheduling methods.
Represent the schedule and track the progress when a project

commences.
B1965
Page No. 95
Unit 6
When there are several people involved in a project, the tasks and
activities pertaining to the project are done in a parallel manner.
After we have analysed the requirements, we must review them, since

review is considered as the foundation for the activities and tasks that
need to be performed in a software project.
The technical reviews conducted by the software development teams

help us in analysing the design and reducing the errors that were not
detected during the initial/early stage of software development. These
reviews enhance the productivity and quality of a software product,
when it is delivered to the customer.
After all the units/modules of the software project are completed, they
are integrated and released to the customer after a validation testing.
We will now learn about a tool used to analyse and schedule complex
software projects called the Gantt Chart.
6.2.1 Gantt chart
The Gantt charts are tools used for analysing and scheduling complex
projects. We can use these charts to perform the following:
Plan out the task that has to be completed.
Provide scheduling details for the tasks that are to be carried out.
Plan the allocation of resources required to complete the project.
Work out the critical path for a project where a deadline is specified.
A Gantt chart uses two types of activities in scheduling a software

project:
Sequential activities
Activities that are dependent on other activities and need to be completed in
a sequence, where every stage is more or less completed before the
starting of the next activity, are called sequential activities. They are also
known as linear activities.
Parallel activities
Some of the activities are not dependent on other activities and tasks for
their completion and they can be accomplished any time before or after
reaching a particular stage, these are called nondependent activities or the
parallel activities. We can use the Gantt chart to monitor and check whether
B1965
Page No. 96
Unit 6
a project is on schedule. If the project is not on schedule, we can pinpoint

the remedial action necessary to put the project back on schedule.1
We can use Gantt charts for the following:
Planning and scheduling projects.
Assessing and determining the project duration, resources needed and

the order in which the tasks must be carried out.
Monitoring and checking whether a project is on schedule. If the project

is not on schedule, we can pinpoint the remedial action necessary to put
the project back on schedule.2
1. One tool that is used for analysing and scheduling complex projects is
___________.
2. The two types activities used in Gantt charts are sequential and
____________ activities.
3. While scheduling a project, we use ___________ to show progress
charts.
Activity 1:
Imagine that you have been assigned the task of scheduling a software
project. Explain how you will visualise the sequential and parallel activities
and check project schedule.
(Hint: software project scheduling. Refer section No. 6.2)
6.3 Software Project Tracking and Control

The previous section familiarised us with project scheduling. This section
will familiarise us with the way in which we can track and control a project.
Project tracking is the way in which projects are managed and it involves a
series of tracking activities that are both measured and reported. The
objective here is to ensure that we are able to monitor the projects progress
1
2
http://www.mindtools.com/pages/article/newPPM_03.htm
http://www.mindtools.com/pages/article/newPPM_03.htm
B1965
Page No. 97
Unit 6
and take corrective action in case it is going out of control in terms of

schedule slippage, and so on. Some of the activities that you can find in
software project tracking are a set of tasks and milestones (very important
events). These activities can be achieved by having a set of predefined
project results/goals.
Project tracking can be undertaken with project management software (like
Microsoft Projects), which automates the process of tracking project-related
activities.
Now, let us see the ways in which tracking can be achieved in an
organisation:
By conducting periodic status meetings, where the members of the team

report their progress and problems.
By evaluating results of all the reviews conducted throughout the

software engineering process.
By determining whether the formal tasks and milestones of the projects

have been achieved within the scheduled date and time.
By comparing the actual start date to the planned start date for each
project.
By conducting informal meetings with the practitioners and obtaining the

assessment details pertaining to the progress in a project and also
examining the problem areas where there is a delay in meeting
schedules.3
Control is the method used by a project manager to know the status of the
activities in a project. A simple way of tracking is to check the number of
hours spent by each resource on a task associated with the cost.
We can use various tools and techniques to track the projects. The project
management software tool is one of the most commonly used tools. This
tool helps us in managing, executing, tracking and closing the projects.
Automating the project management tasks helps us to have an access to
real-time analysis and also enables us to manage the resources efficiently.
B1965
Page No. 98
Unit 6
Therefore, we can say that project control enables us to know the status of
a project. Let us see some benefits of project control:
Project delivery is done as scheduled considering cost and time.
Accurate reports of the project status.
Able to spot deviations from plan and sort them out.
Potential future problems can be overseen and can be avoided.
4. Project tracking is the way in which projects are __________.
5. Project tracking can be undertaken with software like Microsoft
Projects, which is a _______________________ software.
6. Project control enables us to know the ________ of a project.
Activity 2:
Imagine you have been assigned the task of tracking and controlling a
project. Explain the steps you would take to track and control the project.
(Hint: Tracking and control. Refer Section No. 6.3)
6.4 Software Risk Management

After studying the importance of tracking a project and the way the tasks
can be controlled, we will now study about software risk management and
how it works.
We can define risk as the potential dangers that can occur in our simple
daily activities. By experience, we have learnt how to handle risks in our
lives.
In the same way, an organisation has several risks involved in the process
of software project development. In software risk management, an approach
is made to study about the experiences of both the successful and
unsuccessful projects, in order to have a better understanding about the
success or failure of projects. This gives us an idea about handling the
project under different scenarios.
Let us have a look at the top ten software risk items in a software project.
Personnel shortfalls
Scheduling and budgeting unrealistically
B1965
Page No. 99
Unit 6
Developing the wrong functions and properties
Developing the wrong user interface
Continuing stream of requirements change
Shortfalls in externally furnished components
Shortfalls in externally performed tasks
Real-time performance shortfalls
Straining computer-science capabilities
Gold-plating (Gold-plating is the method of pampering the customer by

adding new fancy features to the product and not billing them. This will
make the customer think that you are doing more work for free.)
Therefore, managing risk has become a matter of concern, as it involves

huge amount in costs. We can conclude that software risk management is a
proactive approach to minimise the uncertainty and potential loss
associated with a software project.
Let us now discuss four risk management activities as shown in Figure 6.1.
Risk Management Activities
Risk Analysis
Risk Identification
Risk Assessment
Risk Monitoring
Fig. 6.1: Risk Management Activities
6.4.1 Risk analysis

After a brief discussion about risk, we will now familiarise ourselves with
analysing risks associated with a software project.
Risk analysis is the process of analysing the dangers on an organisation or
an individual due to the adverse effects caused by nature or human-related
errors. Risk analysis comprises four different activities, as follows:
Risk identification
Risk projection
Risk assessment
Risk management
B1965
Page No. 100
Unit 6
We will study about these activities in the later sections. First we will discuss
in detail about the steps involved in risk analysis.
1. Identify threats While analysing risk, we face many threats from
individuals or organisations, illness or death, from disruption to supplies
and operations from loss of business partner, from failures of
accountability, internal system and controls, risks of cost overruns,
from business failure, from advances in technology to technical
failures, from weather, natural disaster, accident and disease, and so
on.
2. Estimate risk After identification of threats, we must realise and
assess its impact. To evaluate risk, we must multiply the probability of
the event occurring with the amount that would cost to set right thing.
3. Manage risk After the value of risk is worked out, you must start to
manage them. In order to manage risk, you must always ensure that
cost-effective approaches are followed and also ensure that the
amount spent must always be less than the cost of the event. Risks
can be managed by using existing assets, contingency planning and by
investing in new resources.
4. Reviews A review is done after completing the risk analysis and may
involve appropriate planning and system testing.
Risk analysis helps us to assess the various risks involved in a software
project and the countermeasures to be taken in order to minimise the
disruptions that can impact a scheduled plan in a project.
6.4.2 Risk identification
Let us now learn about identification of the risks in a software project.
Risk identification is a method of either determining the risks that exist or
those that are anticipated along with the details of time and their possible
outcomes. At times, it becomes impossible to eliminate or minimise risks.
So, before taking up a software project, we must identify all the potential
risks to the extent possible.
We can classify risk categories in many ways, some of them being:
1. Project risks It includes project schedules, staffing for the project/
personnel, project budget, requirements, resources and their impact on
a software project.
B1965
Page No. 101
Unit 6
2. Technical risks It covers the factors involving the design of a

software project, implementation, verification, interface and issues
related to maintenance. Factors such as technical uncertainty,
ambiguous specification and leading edge technology are also
considered as technical risks, as they are difficult to solve than we
thought it would be. Technological obsolescence also comes under
technical risk.
3. Business risks Business risks are perhaps the most harmful risks
and they unravel/bring out the details of the best software projects. The
five top business risks are as follows
o
Building an excellent product that no one really wants (market risk).
Building a product that no longer fits into the overall product strategy
for the company.
Building a product that the sales force does not understand how to
sell.
Losing the support of senior management, while starting a project

due to a change in the peoples focus.
Losing budgetary or personnel commitment (budget risk).4
Risks cannot be easily predicted and hence, a certain checklist must be

followed to identify risks. Risk identification is the first step in managing risk
and only then the concerned personnel work on them in the right manner.
To run a software organisation or a software project, we must follow a
structured risk management methodology in order to identify the risks.
Risk identification involves in understanding the project and documenting
the likely risk characteristics and also incorporating the possible threats. All
these can be done with the help of a risk table. Very briefly, the steps
required for erecting the risk table are as follows:
1. The project manager lists down all the risks, even the remotest one, in
consultation with the project team and other experts.
B1965
Page No. 102
Unit 6
2. From his/her experience, he/she figures out the probability for each of
the above risks, that a particular risk will become a reality (range is
from 1% to 100%).
3. He/she also lists down the impact of a risk becoming a reality on a
scale of 1 to 5 where 1 is negligible and 5 is catastrophic.
4. Next, he/she sorts the tableon probability descending (high to low)
and impact ascending (low to high).
5. He/she defines a cut-off (say 40%) below which he/she will not
consider any of the risks laid down.
6. All the risks that come above the cut-off probability will be considered.
The mitigation for each of these shortlisted risks will be specified in a
document called Risk Mitigation, Monitoring, and Management
(RMMM) Plan where we need to record each shortlisted risk
6.4.3 Risk assessment
After discussing the aspects of risk identification, we will now discuss risk
assessment.
Risk assessment is the first step towards risk management. Risk
assessment is examining the factors that can bring about risk in a software
project and also taking enough precautions to prevent the risks on the
project and the employees in a software company. Hence, risk is considered
as an uncertain event that can cause adverse effects on an organisation
that is working towards its set goals.
By analysing the risks, we arrive at risk assessment which is also called as
the Threat and Risk assessment. Threat can be defined as a harmful act
like illegal network penetration or a virus. Risk is the expected potential
damage it can cause to a software project.
In order to assess risk, we must first define the risk referent level. The three
risk referent levels of a software project are as follows:
Cost
Performance
Schedule
B1965
Page No. 103
Unit 6
These levels give us information about cost overrun, schedule slippage and
performance degradation (including insufficient requirements) and this in
turn leads a software project to be terminated. While performing risk
assessment, we must follow these steps:
Define the risk referent level for the project.
Attempt to develop a relationship between the referent levels.
Predict the set of referent points that define a region of termination,

bounded by a curve or area of uncertainty.
Try to predict how compound combinations of risks will affect a referent

level.
In order to assess risks, we must analyse the type of risk and determine
whether it is a quantitative risk or a qualitative risk. We will conclude our
discussion on risk assessment by briefly touching upon the subject of risk
analysis reports.
6.4.4 Risk analysis reports
A risk analysis report gives us a clear picture about how technology-related
objectives and business objectives are arranged. There are two types of risk
analysis reports.
Quantitative risk analysis
Quantitative risk analysis gives details about the statistical values pertaining
to the adverse effects and the likely losses for a particular software project.
In this type of risk assessment, two components are used to calculate risk:
the magnitude of the potential loss and the probability of occurrence of loss.
Qualitative risk analysis
Qualitative risk analysis does not involve numerical data. Instead, it defines
the various threats and the extent of damage that could occur, along with
the countermeasure plans.
The risk analysis report gives you the details about the vulnerability and the
cost of recovery caused due to a risk factor. Therefore, several defensive
measures are taken by organisations to counter risks whenever they
become realities.
B1965
Page No. 104
Unit 6
6.4.5 Risk monitoring

By now, you must have become familiar with the concepts involved in risk
analysis after learning the previous sections. Let us now have a brief
discussion on risk monitoring.
The entire process of software risk management is documented and is used
by a project manager as part of a project plan. The documented plan gives
you details about the risk monitoring and control methods used in the
project.
Risk monitoring is the tracking activity of a software project. The following
are the three main objectives of risk monitoring:
To assess whether a predicted risk does, in fact, occur.
To ensure that the risk avoidance steps are defined and are also being
properly applied.
To collect information that can be used for future risk analysis.5
Most of the problems that occur in a project can be traced back to the
risks that were predicted at the commencement of that software project.
The four ways in which risks can be reduced in a software project are given
below.
Risk avoidance Risk avoidance is basically shunning tasks that are risky.
Sometimes, it might reduce the possibility of gains, as you are avoiding risky
tasks.
Risk reduction In order to reduce risks, measures that can act against a
risk are introduced in the project.
Risk retention In risk retention, we must accept the consequences of a
risk involved in a software project. This type of risk proves to be costeffective to the company.
Risk transfer In risk transfer, a part of a task involved in a project might
be outsourced or given to a subcontractor.
B1965
Page No. 105
Unit 6
7. The act of outsourcing a part of the task is one form of risk reduction.
This is an example of _____________.
8. The ____________ levels give us information about cost overrun,
schedule slippage and performance degradation.
9. The two types of risk analysis reports are quantitative and
__________.
Activity 3:
Imagine yourself as a member in the risk analysis committee and explain
how you would handle risks in your project.
(Hint: Software risk management. Refer section No. 6.4)
6.5 Project Metrics

By now, we have become familiar with the concepts of project management
process. We will now study about Project Metrics.
Project metrics provides us an idea about the progress of the software along
with quality. In software engineering, it is a difficult task to measure and
evaluate the software process. Let us now try to understand the reasons for
measuring a software product:
To indicate the quality of the product.
To assess the productivity of the people who produce the product.
To assess the benefits (in terms of productivity and quality) derived from
new software engineering methods and tools.
To form a baseline for estimation.
To help justify requests for new tools or additional training estimation.
We can classify the process measurement in two ways, namely direct

measures and indirect measures, as shown in Figure 6.2.
B1965
Page No. 106
Unit 6
Fig. 6.2: Measurement of Process Metrics
Let us briefly understand these measures.

Direct measures The cost and efforts of software engineering process
come under the direct measures. The direct measures of the product are
lines of code (LOC) produced execution speed, memory size and defects
reported over a set period of time. It is easy to collect data related to cost,
effort in man-days and the lines of code only when the correct measuring
conventions are established.
Indirect measures These include the functionality aspects of a product
such as quality, complexity, efficiency, reliability and maintainability. The
maintainability and efficiency are difficult to assess.
6.5.1 Size-oriented metrics
We can use the size-oriented metrics for collecting the direct measures of
software engineering like defects and human effort related to a software
project. When a software company maintains a simple record, a table of
size-oriented metrics is created. This table will give you an idea about the
different software projects that were completed in the past years along with
the size-oriented data for that project. In Table 6.1, we see that the project
titled as aaa-01 had 12.1 KLOC (thousand (Kilo) lines of code), that were
developed with 24 person-months of effort at a cost of $168,000. This table
not only shows the cost and effort-related activities, rather it will provide
B1965
Page No. 107
Unit 6
details about analysis, design, testing and coding. The project aaa-01 has a
365-page documentation and 29 errors that occurred after the product was
released to the customer during the first year of operation.6
Table 6.1: Size-Oriented Metrics
Project
Effort
KLOC
pgs.doc
Errors
People
aaa-01
24
168
12.1
365
29
ccc-04
62
440
27.2
1,224
86
fff-03
43
314
20.2
1,050
64
iii-02
11
112
9.7
268
13
A simple size-oriented production and quality metrics can be developed for

each project and an average can be calculated for all other projects.
Productivity = KLOC/person-month
Quality = defects/KLOC
The cost and the documentation involved in the project can also be
calculated.
Cost = $/LOC
Documentation = Pages of documentation/KLOC
Due to the complexity of the size-oriented metrics, they are not accepted
universally and hence not used to measure the software development
process. Also, you will need to understand that brilliant programmers who
can create a program with much lesser number of LOC will actually be
penalised when we use LOC as the unit of measure! LOC is programming
language dependent and cannot adapt to non-procedural languages. In
order to estimate, you will require detailed data that are difficult to obtain.
Before completing the analysis and design state, you must estimate the
LOC.
Therefore, we can conclude from the above discussion that although sizeoriented metrics are widely used, the validity and applicability of such an
approach is still not proven.
B1965
Page No. 108
Unit 6
6.5.2 Function-oriented metrics

After familiarizing ourselves with size-oriented metrics, we will now study
about function-oriented metrics.
The function-oriented metrics are indirect software metrics. Instead of the
number of LOC, the emphasis is more on the functionality of the product.
The function-oriented metrics were first proposed by Albrecht. He suggested
a productivity measurement approach known as the Function point method.
In this method, function points are used. A function point is a relation that is
based on the countable measures of software information domain and
assessment of software complexity.
Let us see the structure of function-oriented metrics in Figure 6.3.
Fig. 6.3: Function-Oriented Metrics
Figure 6.3 depicts how the five information domain characteristics (number
of user inputs, number of user outputs, number of user inquiries, number of
files and number of external interfaces) are determined and the way in
which the counts are provided in the appropriate table location. Let us see
how these five information domain values are calculated.
Number of user inputs: For calculating the number of user inputs, each
user input that has a unique application-oriented data to the software is
counted. The inputs and the inquiries are separately counted.
B1965
Page No. 109
Unit 6
Number of user outputs For calculating the number of user outputs,

each user output that provides application-oriented information to the user is
counted. The output refers to the reports, screens and error messages.
Individual data items within a report are not counted separately.
Number of user inquiries For calculating the number of user inquiries,
each distinct inquiry is counted. We can define an inquiry as an online input
that results in the generation of some immediate software response in the
form of an online output. Such an output need not be stored in a database
as we would do with user outputs.
Number of files For calculating the number of files, each logical master
file, that is a logical grouping of data that may be one part of a large
database or a separate file, is counted.
Number of external interfaces For calculating the number of external
interfaces, all machine-readable interfaces (e.g. data file on tape or disk)
that are used to transmit information to another system are counted.
When all the aforementioned data pertaining to information domain are
collected, a complexity value is associated with each count. Organisations
can determine the type of entry with the help of function point methods
criteria.
Calculation of Function Points
You can calculate function points (FP) as follows:
Step 1: Calculate the unadjusted function points (UFP) by multiplying each
count of simple, average and complex counts with the corresponding
weights assigned to simple, average and complex.
Step 2: Calculate the degrees of influence (DOI). DOI is the sum total of the
values given to the 14 parameters used to assess DOI. The parameters are
as follows:7
o Data Communications
o Distributed Functions
o Performance
o Heavily Used Configuration
B1965
Page No. 110
o
o
o
o
o
o
o
o
o
o
Unit 6
Transaction Rate
Online Data Entry
End User Efficiency
Online Update
Complex Processing
Reusability
Installation Ease
Operational Ease
Multiple Sites
Facilitate Change
For each of the above parameters, the software professional has to assign a
value ranging from 0 to 6 (where 0 implies the least and 6 implies the
maximum).
Step 3: Calculate the value adjustment factor (VAF) using the formula: VAF
= 0.65 + (0.01 * DOI).
Step 4: Calculate the adjusted function points (AFP) using the formula: AFP
= UFP * VAF
It is also possible to calculate the corresponding KLOC from AFP and then
applying the COCOMO model to estimate the effort and time required for
the project. For this, we can refer to the standard FP to LOC conversion
table.
Let us now work out a problem that includes function points and the
COCOMO.
Problem:
Assume that for a software project, the following function point counts have
been established.
Table 6.2: FP Counts and Corresponding Weights for a Fictitious Software
Project
Item
Inputs
Outputs
Inquiries
Logical master files
External interface files
Simple
25
45
12
56
4
B1965
Average
12
14
10
48
2
Complex
7
19
8
21
0
Page No. 111
Unit 6
The values given to Degree of Influence attributes are as shown in Table

6.3.
Table 6.3: Values Given to Degree of Influence Attributes for a Fictitious
Software Project
Weighting factor
Item
Simple
Average
Complex
Inputs
Outputs
Inquiries
Logical master files
10
15
External interface files
10
Data Communications
Distributed Functions
Performance
Heavily Used Configuration
Transaction Rate
Online Data Entry
End User Efficiency
Online Update
Complex Processing
10
Reusability
11
Installation Ease
12
Operational Ease
13
Multiple Sites
14
Facilitate Change
You are required to compute the following:

1. Total unadjusted function points (UFP)
2. Total degrees of influence (DOI)
3. Value adjustment factor (VAF)
4. Total adjusted function points (AFP)
B1965
Page No. 112
Unit 6
Solution:
Step 1: Calculate the UFP as follows:
UFP = (25*3 + 12*4 + 7*6) + (45*4 + 14*5 + 19*7) + (12*3 + 10*4 + 8*6) +
(56*7 + 48*10 + 21*15) + (4*5 + 2*7 + 0*10) = 1,893
Step 2: Calculate the DOI as follows:
DOI = 5 + 5 + 2 + 2 + 0 + 5 + 5 + 3 + 5 + 5 + 0 + 5 + 5 + 5 = 52
Step 3: Calculate the VAF as follows:
VAF = 0.65 + (0.01*DOI) = 0.65 + (0.01*52) = 1.17
Step 4: Calculate the AFP as follows:
AFP = UFP*VAF = 1,893*1.17 = 2,215
That is, this software project has an estimated 2,215 function points.
Now, let us assume that the project is going to be developed in C++
language. For C++, the conversion rate is 59 LOC per function point.
Hence, we conclude that this project will have an estimated 59*2,215 =
130,685 LOC or 131 KLOC.
We further assume that the project follows the basic version and organic
mode of COCOMO (refer Unit 5, section 5.4: Software Project Estimation).
Let us now calculate the effort and calendar time required to finish the
project.
We will use the formula Enom = a * (KLOC)b
That is, Enom = 2.4 * (131)1.05 = 2.4 * 167.16 = 401 person-months.
For development time we can from the formula Td = 2.5 * (Enom)0.38
That is, Td = 2.5 * (401)0.38 = 2.5*9.75 = 24.4 calendar-months.
Thus, the project requires 401 person-months of effort, to be completed in
24.4 calendar months.
10. We can classify the process measurement into two ways, namely direct
measures and _________ measures.
11. KLOC stands for _______________.
B1965
Page No. 113
Unit 6
12. The raw count of function points are further fine-tuned using DOI and
VAF. The final result after the calculations is called as AFP that stands
for ______________.
Activity 4:
Imagine you have been assigned the task of measuring the software
product; explain how you would use the size-oriented and the functionoriented metrics in your task.
(Hint: Project metrics.)
6.6 Summary
Measurement of a project enables the professionals involved in a project

to have a better understanding about the process that is followed and
the product that is being developed. Metrics for quality and production
can be measured in various ways.
The need for monitoring and controlling a project is very important, since
it updates the team and the management about the progress status of
the project. If there is any kind of deviation noted, then the project
manager can take necessary corrective steps.
Risk is an important aspect of a software project. It is necessary to have

a written recovery plan that can address all the risks involved in a
software project. A written recovery plan provides comfort to a software
organisation in recovering from the disaster which can occur due to a
project off schedule and other contingencies.
In order to measure the process and the product, size-oriented and

function-oriented metrics are used. Size-oriented metrics are used for
measuring the lines of code and defects in a program while functionoriented metrics are used to assess the complexity of a problem.
Finally, in order to produce a quality software product, a software project

needs to be managed using systematic well-defined methods and tools
by meeting the objectives and goals set.
B1965
Page No. 114
Unit 6
6.7 Glossary
Financial analysis: It involves looking at financial statements to determine
if a company is healthy.
Stakeholder analysis: It is a tool that is used to assist in decision-making
situations where various stakeholders have competing interests, resources
are limited and stakeholder needs must be appropriately balanced. This tool
can be used for many types of decisions at all levels within an organisation.

1. Differentiate between scheduling and tracking.
2. Explain project metrics and its types in detail.
3. Describe software quality metrics and its measures.
4. Briefly describe the importance of integrating metrics within software
engineering.
5. Discuss Software project scheduling using Gantt charts.
6. Explain software project tracking and control.
7. Define software risk management and the ten software risk items of
software project and also explain the different systematic activities in
risk analysis.
6.9 Answers
1. Gantt Chart
2. Parallel
3. Milestones
4. Managed
5. Project management
6. Status
7. Risk transfer
8. Risk referent
9. Qualitative
10. Indirect
11. Kilo lines of code
12. Adjusted function points
B1965
Page No. 115
Unit 6
Terminal Questions
1. (Refer to Section 6.2, Scheduling and Tracking phase for further
information.)
2. (Refer to Section 6.5, for further information.)
3. (Refer to Section 6.6, Software Quality Metrics for further information.)
4. (Refer to Section 6.6, Software Quality Metrics for further information.)
6.10 Case Study

Central Portal System
A 20-member Sigma services department executes 60 jobs per week with
150 jobs open at any time. Their projects included four to five people from
designing, marketing and advertising. There were no proper scheduling and
planning techniques used while planning a project. Due to this, the staff
members at sigma services were very frustrated, as they had to meet
unrealistic project deadlines.
Resource load and deadlines were manually allocated without any updated
resource allocation system, which caused the employees to be dissatisfied.
The management found that a lot of time was spent on paper work.
Challenge:
The management needed a tool to manage and improve its project
planning, which would integrate the Microsoft office documents with a
project tracking system. They wanted to have a clear idea about the realtime project status and capacity planning, based on the resources used,
instead of making a guesswork.
Solution:
By using the Vertabase pro and the Gantt charts, every project could be
tracked. As the Vertabase pro was very user-friendly, it was used in most of
the tasks and assignments outside their planned workload. Currently, the
team uses a resource management report in order to complete more
projects ahead of schedule than before.
B1965
Page No. 116
Unit 6
Results:
Resource planning improved and thereby increased employee satisfaction.
Mangers could have a better control over their projects using Gantt charts,
which helped them in successful task completion.
An automated project management system was set, using the Vertabase
pro and the Gantt charts.
Future projects could be planned based on the past project details.
A clear documentation about the tasks completed along with the details of
date and time was available.
The central repository system helped them to know about daily tasks, send
automated e-mail notifications which were previously paper-based.
There was increased accountability to commitments and deadlines.
1. Discuss the problems faced by the sigma services and how they
overcame it.
(Hint: Project scheduling and tracking.)
References:
Chemuturi, Murali. Software Estimation Best Practices, Tools &

Techniques, J Ross Publishing (10 September 2009)
Roger S Pressman, Software Engineering A Practitioners Approach,

B1965
Page No. 117
Unit 7
Unit 7
Software Reliability
Structure:
7.1 Introduction
Objectives
7.2 Software Reliability Metrics
Software metrics
Software reliability models
7.3 Programming for Reliability
Fault avoidance
Fault tolerance
7.4 Software Quality Metrics
7.5 Software Reuse
Classification of software reuse
Advantages of software reuse
7.6 Summary
7.7 Glossary
7.9 Answers
7.10 Case Study
7.1 Introduction
By now, you have become familiar with different processes involved in
software project development, such as project planning, scheduling,
tracking and risk management.
In this unit, we will study about software reliability metrics, wherein we will
discuss about software metrics and software reliability models. We will study
about fault avoidance and fault tolerance, which will help us in
understanding how reliability is used in programming during the
developmental phase of a software product. In this unit, we will also discuss
the software quality metrics, which will help us in understanding the
integration of metrics within software engineering process. We will also have
a detailed discussion about how software can be reused by using the
artefacts that are already available from the previous projects. This is
indeed very cost effective and enhances the quality of the software system.
This unit will enable us to understand the use of appropriate software
metrics while developing a software product.
B1965
Page No. 118
Unit 7
Objectives:
elaborate software reliability metrics
explain programming for reliability with respect to fault avoidance and
fault tolerance
describe about software quality metrics
elucidate software reuse
7.2 Software Reliability Metrics

Let us start our discussion on software reliability with software reliability
metrics.
We can define reliability as the capability of being depended on; and
software reliability as the reliability/dependability of a particular software
product.
When we speak about the quality of a software product/system, software
reliability comes into picture. Several software reliability approaches are
used in the field of software engineering in order to have a reliable software
system. Due to the complexity in the software product, software reliability
becomes difficult at times.
Today, computers play a significant role in our day-to-day lives. It has
become impossible for us to engage in our daily activities without
computers, which are controlled by the software. As we depend more on the
software systems, it becomes very necessary for us to have reliable
software. The failure of a software system can cause loss of life or money
and sometimes even both. Thus, it is imperative for software systems to be
very reliable.
Let us take the example of the NASA Software Assurance Standard, NASASTD-8739.8, which defines software reliability as a discipline of software
assurance that
Defines the requirements for software-controlled system fault/failure
detection, isolation and recovery.
Reviews the software development processes and products for software
error prevention and/or reduced functionality states.
Defines the process for measuring and analysing defects and
defines/derives the reliability and maintainability factors.
B1965
Page No. 119
Unit 7
Let us have a look at the two types of software reliability techniques used,
which are shown in Figure 7.1.
Fig. 7.1: Software Reliability Techniques
1. Trending reliability Trending reliability technique is a software

reliability technique, which tracks the data of a software system that
have failed. The data collected are then used to develop a reliable
software system for a specified period of time. Trending reliability is
more suitable for the software industry. Based on the operations, we can
categorise the trending reliability into four types.
Error seeding This type of trending reliability involves assessing

the number of errors in a program using multi-stage sampling where
we can classify the errors into indigenous and induced (seeded)
errors. We can assess the number of anonymous indigenous errors
from the number of errors that are induced and the ratio of errors
obtained from debugging.
Failure rate We can define this type of trending reliability as the

method of studying the failure rate of programs per fault at failure
intervals. The failure rate of the program changes depending on the
change in the number of remaining faults.
Curve fitting Curve fitting is a type of trending reliability, which

uses the statistical regression analysis in order to study the
relationship between the complexity of software and the number of
faults in a program along with the failure rate.
B1965
Page No. 120
Unit 7
Reliability growth Reliability growth of trending reliability is used

to measure the improvements made in the software reliability
programs, and also predicts software reliability by incorporating a
process of software testing. The failure rate of a software system is
represented as a function of time or as test cases.
2. Predictive reliability Predictive reliability is another software reliability

technique, which predicts or anticipates the possibilities of operational
profile of a software system, and is more appropriate for hardware
After understanding the two software reliability techniques, we will now
study about the various software reliability metrics based on the way they
are measured.
The mathematical concept of reliability
We can define the concept of reliability mathematically by using the
following equations.
Reliability R(t) is the probability of a system to be successful during the time
interval ranging from 0 to t.
R(t) = P(T > t), t 0
Where T is a random variable denoting the time-to-failure or failure time.
In other words, F(t) is the failure distribution function. The following
relationship applies to reliability in general.
F(t) = P(T t), t 0.
The reliability, R(t), is related to failure probability F(t) by
R(t) = 1 F(t).
7.2.1 Software metrics
We have discussed about product metrics in the previous unit; let us now
familiarise ourselves with various software reliability metrics.
We can categorise software reliability metrics into certain distinct types as
shown in Figure 7.2.
B1965
Page No. 121
Unit 7
Fig. 7.2: Types of Software Reliability Metrics
Product metrics Product metrics involve instinctive method of

measuring the size of the software, on the basis of the lines of code
(LOC), or more practically thousand lines of code (KLOC). This is the
simplest method for measuring reliability and we generally use source
codes to measure the lines of code in order to determine the size of a
software product. We cannot use the product metrics to compare
software that is written in different programming languages.
Function point metrics We can use the function point for the
measurement of the functionality of a recommended software
development system based on functions such as count of inputs,
outputs, master files, inquires and interfaces. Once we identify these
functions, we can estimate the size of a software system. The
functionality metrics measure the functional complexity of a software
program, and they are independent of other programming languages.
Generally, we use the functional metrics in business systems, and not
much in the scientific applications.
Complexity metrics We can use complexity metrics for determining

the complexity of a software programs control structure. We can simplify
the complexity of the software program code by graphical
representation.
Test coverage metrics We can use test coverage metrics for

estimating the fault and reliability of a software program.
B1965
Page No. 122
Unit 7
Project management metrics We know that good management can

provide better quality products. Therefore, it is very necessary to
establish a synchronous relationship between the development process
and the ability to complete projects on time and within the budget, and
thereby meet quality objectives. When the development process is not
followed in a systematic manner, costs can increase and the software
project can run off-schedule. Thus, we can achieve high reliability by
using project management metrics.
Process metrics We can use process metrics for estimating,

monitoring and improving the reliability and quality of a software product.
Fault and failure metrics Fault and failure metrics are used for
measuring the number of faults found in the software system during the
testing phase (before delivering to the customer) and the failures
(reported by the customers) after the delivery of the software product.
Software reliability plays a key role in enhancing the quality of a software

product. We can classify the study of software reliability into three phases
as follows:
Modelling We can define software reliability modelling as the use of

appropriate models for solving a problem in a software system and
obtaining suitable results. There is no single model that can be used for
all situations in software systems.
Measurements We can say that software reliability measurement is

measuring the software quantitatively to know how good a software
product is. We cannot measure software reliability directly; instead, we
can measure other factors for estimating software reliability. The faults
and failures of the development process are the factors related to
software reliability.
Improvements It is difficult to have software reliability improvements

due to insufficient understanding of software reliability with regard to the
software characteristics. Time and cost constraints limit the effort put
into software reliability improvements.
7.2.2 Software reliability models

After familiarising ourselves with software reliability metrics, we will now
discuss about software reliability models.
B1965
Page No. 123
Unit 7
We know that a particular model can work well on certain software, while it
may not work at all on another. Typically, a software model contains
mathematical functions, assumptions and factors. The mathematical
functions contain exponential and logarithmic functions of higher order.
These modelling techniques are based on accumulating the failure data and
analysing them statistically by observance. Let us understand these
techniques by differentiating the two modelling techniques, as given in
Table 7.1.
Table 7.1: Prediction Modelling and Estimation Modelling
Prediction model
Estimation model
In the prediction model, we can

predict software reliability very
early in the software development
process, and thus can be used to
enhance reliability.
Estimation models include

exponential distribution models that
are known as the fault count/fault
rate estimation model.
The prediction model uses

historical data.
The estimation model uses data

from the current software
The prediction model predicts

reliability at some future point of
time.
The estimation model estimates

reliability at either the present or the
future time.
The prediction models are used

before the development or test
phase, and are sometimes used
in the concept phase.
The estimation models are not used

in the concept and developments
phase of software. They are used
after data are collected for
estimation.
Some of the typical software reliability improvement techniques are as

follows:
Utilising good engineering methods to improve software reliability.
Examining the software product, certifying, approving and checking
whether the customer requirements are met.
Testing the software product in an ad hoc manner to match the various
software development projects.
Utilising different analysis tools to minimise the existence of defects after
the release of the software product.
Studying and analysing the field data after assembling.
Minimising the occurrence of faults by using fault tolerance and fault
forecasting techniques.
B1965
Page No. 124
Unit 7
1. The two types of software reliability techniques are trending reliability
technique and _______________ technique.
2. Error seeding is a trending reliability technique. (True/False)
3. The two software modelling techniques are estimation and _________.
Activity 1:
Assume that you have joined as a project manager in a software
company. Explain how you would use software reliability metrics in your
project.
(Hint: Software reliability metrics.Refer Section No. 7.2 )
7.3 Programming for Reliability

In the previous section, we studied about the concept of software reliability,
and the various metrics involved in estimating and predicting software
reliability. In this section, we will discuss about programming for reliability
with respect to fault avoidance and fault tolerance.
We can define programming for reliability as the method of programming,
where the codes in the software are made more reliable. Let us have a look
at some of the concepts of programming for reliability.
Inconsistent assumptions Inconsistent assumptions are those
assumptions that are relatively avoided during the design phase of
writing codes. But, we cannot avoid these assumptions during code
maintenance. Code changes are made only to single functions or files;
however, assumptions are made throughout the code base. We can see
a lot of inconsistent assumptions related to conditions at the exit of a
loop, the entry and exit points for functions and error-handling code.
The static analysers are used to detect the bugs that are found in the source
code of a software program without execution.
Error-handling code Developers generally program with the intention
of implementing the functionality. This method involves handling errors
in codes. Sometimes, designing the test cases becomes difficult when
they have error paths. The code auditors must specify the need of errorchecking and must also emphasise on accuracy of error-handling. An
error could have occurred simply because the programmer forgot to free
B1965
Page No. 125
Unit 7
the memory. An error-exit approach could have been performed to clean

up the memory. Thus, the static analysers are once again used to
ensure that the rules of consistency are followed even when errors are
rarely executed during the phase of testing.
Avoiding mistakes Every time when a bug is found in the software

system by a tester, they are fixed by the developer. Sometimes the
same bug/error can re-occur many times. Static analysers can easily
find these repeated errors/bugs. The minor mistakes may appear as
different types of errors. Sometimes while finding one type of bug, we
might end up finding another type. This is a very common happening,
during the detection of dead code using static analyser. Dead codes
indicate problems in a software system. The static analysers are again
used efficiently to examine large volumes of code.
7.3.1 Fault avoidance

Since we are studying about the concept of programming for reliability, we
will now discuss fault avoidance in a software project.
We can define fault avoidance as the concept of avoiding faults from being
introduced into a software project. We can avoid faults in a software project,
by forecasting them, well in advance. The aim of fault avoidance is to
ensure that the software produced is fault free. In order to produce a faultfree software project, we follow several approaches. Let us briefly discuss
some general fault avoidance approaches shown in Figure 7.3.
Fig. 7.3: Fault Avoidance Approaches
Formal or precise specification method Formal or precise

specification method involves in eliminating the errors during the
requirements specification and design stages of software development.
B1965
Page No. 126
Unit 7
By following the formal specification method, it is possible to know how

codes can be matched and traced to the specifications thereby
enhancing accuracy in programming and reducing the defects. In formal
specification method, we use mathematical language like Z Language
for specifying the requirements. Using mathematical notations ensures
that there is absolutely no ambiguity in understanding the requirements,
because these notations are universal.
Verification and validation techniques Verification and validation

techniques help us to detect the defects that were not detected earlier in
the formal specification method. This method checks the software
program in terms of quality and efficiency.
Software testing Software testing involves testing of the software

program using automated tools and detecting the software bugs in the
program. In this approach of fault avoidance, the presence of faults is
detected rather than its absence. Apart from the software testing
activities, documentation of the entire software development process is
done.
The main objectives of fault avoidance are to:

Prevent the existence of faults in the operational system.
Limit the introduction of faults during system construction by following
fault prevention, fault removal and fault forecasting.
o Fault prevention Fault prevention involves preventing the faults
from intruding into a software system.
o Fault removal Fault removal is a method of finding and removing
all the causes related to the occurrence of errors.
o Fault forecasting Fault forecasting is to predict the errors before
their occurrence
Therefore, fault avoidance in a software program helps us to improve the
quality of a software system, by limiting the occurrence of faults during the
development phase of a software system.
By following the fault avoidance approaches/methodology, it is possible to
protect the software system against the impact of faults during its operation.
Sometimes, faults can occur due to constant use of a software system.
B1965
Page No. 127
Unit 7
7.3.2 Fault tolerance

By now you must have become familiar with the concept of fault avoidance;
let us now have a brief discussion on fault tolerance.
Fault tolerance is the capacity of a software system to withstand/tolerate the
faults that occur on it. We can say that basically the software system
accepts the faults.
In todays business world, the concern is not about a particular software
systems working; rather the concern is more about the accuracy of a
software system, working during mission-critical situations.
The fault tolerant techniques enable the software systems to tolerate fault,
which thereby enhances the reliability of the software system.
Fault tolerance is a concept where your software system will operate
accurately in the presence of unavoidable and undetectable faults. The
bugs that are found in your software system can be eliminated by
performing rigorous testing and debugging.
Let us have a quick overview of the two strategies of fault tolerance.
Error processing We can say that error processing is a method of

eliminating errors by using a substituted error-free state in an erroneous
state called error recovery or by using compensatory methods for
providing redundancy known as error compensation. Errors can be
recovered either through forward or backward recovery methods.
Fault treatment Fault treatment involves preventing faults from

creeping into the software system. Fault diagnosis and fault passivation
are the two steps used. In both these steps, the nature of the fault
details are well analysed and then the strategies are applied to the faults
in an effective manner.
Therefore, fault tolerance helps in improving the quality of a software

system.
4. Software testing involves testing of the software program using
________ tools.
5. The fault avoidance approaches followed in a software project are
_________, validation and verification and software testing.
6. The two strategies of fault tolerance are error processing and _______.
B1965
Page No. 128
Unit 7
Activity 2:
Imagine you are a software developer, and have been assigned the task
of writing codes as well as finding errors in the code, explain the steps
you would follow to check for code efficiency.
(Hint: Refer Section 7.3, Programming for Reliability.)
7.4 Software Quality Metrics

In Unit 6 (Software Project Management: Part 2), we learnt some of the
project metrics such as size-oriented metrics and function-oriented metrics.
In this section, we will learn the software quality metrics and how they are
used to measure the quality in a software organisation.
Right from the stage of software engineering process till the delivery of the
software product to the customer/end user, quality is measured. The metrics
that we derive from the software act as the baseline for making testing
decisions and design decisions. After a software product is delivered to the
customer, we measure the number of defects observed during the
maintainability of the system, using software quality metrics. The defect
details of the product can be known to the managers only after the product
is delivered to the customer.
Quality metrics play a key role in statistical quality assurance. The defects
are observed during the maintenance phase along with detailed information
about the cause of defect, so that right corrective action can be planned.
It is important to keep a balance between the sensitivity and the selectivity
of the quality measures undertaken. The quality of the software product that
is delivered to the customer is the main concern. In order to improve an
organisation, the software process followed must be enhanced by effective
planning, scheduling and tracking the software project along with analysing
the risks involved. We require appropriate metrics for knowing the health of
the process and the project in an organisation. Metrics actually check
whether the quality standards set by an organisation for a particular project
are being achieved in a systematic way or not.
B1965
Page No. 129
Unit 7
We can observe that different organisations follow different dimensions to

measure the software quality of their product. The most common software
metrics adopted by organisations are as follows:
Code coverage
Bugs per line of code
Cyclomatic complexity
Function point analysis
Number of classes and interfaces
Number of lines of customer requirements
Cohesion
Coupling
Order of growth
Source lines of code
Software quality metrics follow different dimensions to measure the quality
of a software product. Metrics help to analyse the defects and take
corrective actions to fix them. There are several measures of software
quality, but let us consider the most important ones among them:
Correctness We can define correctness as the accuracy of the

program with which it can work or perform the task assigned. A defect
per KLOC is the way of measuring the success of a program and the
testing team as well. We can do this by counting the number of lines of
code a program has. The customer/end-user generally reports the
defects after the usage of the software product.
Maintainability We can define maintainability as the ability of the

software to allow us to maintain the software (including enhancements,
etc.) after the software is delivered. When an error/bug is reported, we
can correct it easily. We can make corrections to the product on the
basis of customer request and environmental changes. Since
maintainability cannot be measured directly, indirect methods are used.
They are time-oriented metrics, so every time an error occurs in the
software product, there is a change request.
Integrity Integrity is the way in which a system protects itself from

virus attacks and hackers. A program, a software document or a data
B1965
Page No. 130
Unit 7
related to a software program can be attacked. Two parameters are

used in order to measure integrity. These parameters are as follows:
o Threat It is an estimation of a possibility of an attack and could be
either intentional or accidental.
o Security It is the precautions taken to repel the attack on the
software.
Usability A software product must be user-friendly. We can measure

usability in terms of four characteristics:
o The physical/intellectual skills required to learn the software product.
o Time required for becoming moderately efficient in using the
software product.
o The net increase in productivity by someone who is moderately
efficient.
o Subjective assessment (users opinion about the software product).
The standard that is used for evaluating software quality is ISO 9126. It
addresses different quality models and the metrics for software
Defect Removal Efficiency (DRE) It is the measure of counteracting
defects. When the DRE is found to be low during the design and
analysis phase, it simply means that a lot of time needs to be spent in
the technical reviews.
DRE = E / (E + D)
where E = Number of errors found before delivery of the software.
D = Number of errors found after delivery of the software.
When the DRE value is 1, it implies that there were no defects found in the
system and if the DRE is lower than 1, it implies that the system has some
defects.
Test coverage = Number of units (KLOC/FP) tested/total size of the system.
Quality of testing Number of defects found during testing/(No. of

defects found during testing + No. of acceptance defects found after
delivery) * 100.
B1965
Page No. 131
Unit 7
Integrating metrics within software engineering process

Although, most of the software developers do not find it necessary to have a
process of measuring, in todays world, the process of measuring a software
product plays a very important role in a software company.
It is a difficult task to implement software metrics in a company, but once
their benefits are realised, the task is worth it.
The way in which the software process and the software product are
developed must be measured, because without following a systematic
approach, it is not possible to ascertain/determine that the process followed
to develop a product is good. Measurement of any process or product is
mandatory, as it is proved to be very beneficial for a project from the
technical point of view. In order to improve the software engineering process
in an organisation, it is necessary to evaluate both productivity and quality of
the process and the product. When a process by which a software product
developed is improved, it proves to be of a greater value to the organisation
in building its business ties. Prior to implementing the goals for
improvement, we must understand the process of software development.
Thus, measurement helps us to establish a baseline for a software process
and helps in improving an organisations software engineering process.
The rigorous and time-consuming processes followed in the development
process of an organisation give very little time for other activities such as
strategic thinking. So, more emphasis is given to issues like project
estimation, production of high-quality products and adhering to right delivery
schedules.
A baseline for establishing the productivity and quality standards of an
organisation has to be followed in order to enable better management for
estimation. The quality metrics followed in an organisation help to fine-tune
the defects that have a greater impact in the software development process.
From a technical perspective, it is seen that when software metrics are
applied to the product, they provide immediate benefits. So, every time a
software product is developed by a software developer, he is very anxious
to know about the product that was developed and some of the questions
that arise are:
Which of the user requirements are most likely to change?
B1965
Page No. 132
Unit 7
Which module in the system is more prone to errors?

How much testing should be planned for each module?
How many errors can be expected when testing commences?
By answering all the above questions, it is possible for us to get information

on whether the technical guidelines were followed or not.
A baseline is a collection of data from the past developed software projects
and is a combination of both simple and complex templates. In addition to
the size-oriented and function-oriented metrics, baseline is supplemented by
quality metrics such as correctness, maintainability, integrity and usability.
Therefore, we can conclude from the above discussion that a baseline must
have the following characteristics.
Data accuracy There should be no guesswork made on the past
projects.
Data collection Mandatory collection of data for all the projects.
Data measurement Consistent measurements must be made, for
example if a line of code is used in a project, they must be interpreted.
The data required to establish a baseline are collected from the ongoing
project. Data collection is done based on the information garnered from
earlier projects. Computation of metrics can be done only after the data
have been collected. This collected data can range from LOC to function
point (FP). The data thus obtained are computed and evaluated and then
estimation is done. Data evaluation emphasises on the averages computed
and circumstances where data cannot be used. It is necessary for a
developer to make note of these points when addressing metrics data so
that they are not used blindly. It is not possible to collect all the data from a
project.
7. Threat and security are parameters used to test the metric called
____________.
8. The standard that is used for evaluating software quality is ISO 9216.
(True/False)
9. DRE stands for ____________.
B1965
Page No. 133
Unit 7
Activity 3:
Prepare a list of software quality metrics we can use for measuring the
quality of software.
(Hint: Refer Section 7.4, Software Quality Metrics.)
7.5 Software Reuse

In the previous section, we studied the concept of programming for
reliability, including fault avoidance and fault tolerance. In this section, we
will discuss the software reuse.
Software reuse is a new approach of building software, using the software
that already exists in a company, rather than building software systems from
scratch. Therefore, we can define software reuse as a process of
developing new software systems from predefined software components or
the existing software artefacts or assets. The requirements, specifications,
design and manuals along with the test cases, test suites and business
processes make up the software assets.
Let us try to answer a very important question in todays business world
Why is software reuse necessary in todays business world? A huge
investment is required every time a new project starts. After the completion
of the project, the assets of the project remain with the company, and they
are reused for other software projects. This way, a company does not have
to invest again and again in creating what was already created in earlier
projects; instead, for new projects it uses the concept of software reuse,
thereby minimising the amount of time required for developing software for
future projects. Hence, the risk involved is considerably reduced. So, we
can conclude that software reuse enhances quality, reliability and
productivity of a software product, and also reduces the cost and time
involved in accomplishing a project.
7.5.1 Classification of software reuse
We can classify software reuse into two categories, as shown in Figure 7.4.
B1965
Page No. 134
Unit 7
Fig. 7.4: Types of Software Reuse
Let us now discuss about the types of software reuse on the basis of the
reuse of the software.
Opportunistic reuse In opportunistic reuse, the members of the
software development team identify the assets that can be reused for
another software project. We can consider this type of reuse as a costeffective method. Scrapheap software development is a type of
opportunistic reuse, where the functionalities from the discarded project
and systems are reused. There are two types of opportunistic software
reuse.
o Internal reuse The software development team will reuse its own
software project components.
o External reuse The software development team buys a third-party
component for its development purposes. This is called the COST
(Commercial off-the-shelf), where a particular technology or a
software component is either leased out or sold.
Planned systematic reuse In this method of reuse, the software

development team actually designs components, so that they can be
used for the future projects.
After studying about the types of software reuse on the basis of reuse of the
software, we will now study about the two types of software reuse based on
the way the software assets are reused. Let us now have a better
B1965
Page No. 135
Unit 7
understanding between the horizontal reuse and the vertical reuse from
Table 7.2.
Table 7.2: Horizontal and Vertical Reuse
Horizontal reuse
Vertical reuse
Horizontal reuse refers to

software assets that are
used in most of your
applications, for example,
the codes used in
programming or GUI
(Graphical user interfaces)
functions.
Horizontal reuse also uses
the COTS technology,
where the software is
bought from a third party.
Most of the horizontal
reusable software codes
can be found at various
locations on the internet
today.
Vertical reuse refers to software assets that are

used by systems with similar functionality. Thus,
a new idea of study and application known as
domain engineering came into existence.
Domain engineering provides information
regarding the life cycle processes that an
organisation uses in order to enhance its strategic
business objectives.
Using domain engineering it is possible to
increase the production of application engineering
projects by standardising the product family and
the associated production process. Thus, we
come across the application engineering, the
counterpart of domain engineering.
Application engineering is a process of developing
products based on meeting customer
requirements.
The structure and form of application engineering
activity is done by domain engineering. Thus,
enabling the individuals working in a project and a
business group to have a better understanding
about their customers and deliver high-quality
products to their customers, which is cost effective
and is less prone to risk.
Domain engineering focuses more on creation
and maintenance of reuse of deposited functional
areas.
Application engineering emphasises more on the
reuse of implementation of new products.
Software reuse has become an important concept for every software

company, due to its potential benefits. It also enhances the quality of the
software product and decreases the cost and time involved in the
development of the software project. The software assets act as a baseline
for a software project development.
B1965
Page No. 136
Unit 7
7.5.2 Advantages of software reuse

We can consider software reuse as the most interesting concept in the field
of software development, as there are several advantages that an
organisation can benefit in the long run.
We will now study about some of these advantages of software reuse:
We can systematically develop the reusable components.
We can use the systematic reuse of these components as the building
block for creating new systems.
We can reduce software development time and costs.
We can increase software productivity.
We can shorten software development time.
We can improve software system interoperability.
We can develop software with fewer people.
We can move personnel more easily from project to project.
We can reduce software development and maintenance costs.
We can produce more standardised software.
We can produce better quality software and provide a powerful
competitive advantage
10. The methodology of using software assets from previous projects is
called as __________________.
11. Based on software assets, software reuse can be classified into
horizontal and ____________.
12. In ___________ method of reuse, the software development team
actually designs components, so that they can be used for the future
projects.
Activity 4:
Assume that you are put into a software project, where you have to
identify the software to be reused for your new project. How will you do
it?
(Hint: Refer Section 7.5, Software Reuse.)
B1965
Page No. 137
Unit 7
7.6 Summary
Let us now recapitulate the important concepts discussed in this unit:
Reliability is the capability to be relied upon and software reliability is the

degree to which we can depend on a particular software.
Software reliability models help us to measure and project the failure

rates of software. From the defect details collected, it will be possible for
us to define the reliability of the software. Thus, we defined software
reliability as a quality characteristic that quantifies the operational profile
of a system.
There are approaches followed for software fault avoidance such as

formal specification, validation and verification and software testing.
These help in reducing the occurrence of fault and also prevent faults in
both number and severity in a software system.
Software quality metrics focus more on the quality process involved in

both the software process and the software product. By using accurate
software quality metrics, it is possible to analyse and develop a
methodology that is used to correct the defects in a software
organisation. Some of the quality metrics in existence are correctness,
maintainability, integrity and usability.
In order to start/commence a metrics program in a software

organisation, the three implementation steps required are data
collection, metrics computation and data evaluation. Integrating metrics
in the field of software engineering is of paramount importance for any
software organisation.
Software reuse, the new approach, is a method wherein software

artefacts/assets created from earlier projects are reused in newer
projects. These provide several advantages to software companies like
reducing development time, increasing productivity, and so on.
Finally, we can conclude that software reliability is the need of todays

business world, as there is a great demand for more software products
that are reliable.
7.7 Glossary
Code auditors: Developers.
B1965
Page No. 138
Unit 7
Code base: An implementation of source code for an operating system or

application.
Dead code: Dead code is a computer programming term for code in the
source code of a program which is executed but whose result is never used
in any other computation. The execution of dead code retards the
computation time as its results are never used.
Development phase: Development phase involves the activities followed
during the process of development.
Functional testing: Functional testing is the process of checking whether
the functionality of the software product is working as per the requirements
specifications of the customer.
Static analysis (also called static code analysis): Static analysis is
method of detecting the errors in the software program without executing
the software program.
Test phase: Test phase involves the activities followed during the process
of software testing.

1. Define software reliability metrics and explain the different software
metrics based in a software development phase.
2. Explain fault avoidance and fault tolerance.
3. Describe software reuse.
4. List out the advantages of software reuse.
5. Describe the concepts involved in programming for reliability.
7.9 Answers
1. Predictive reliability
2. True
3. Prediction
4. Automated
5. Formal or precise specification
6. Fault treatment
7. Integrity
8. False
B1965
Page No. 139
9.
10.
11.
12.
Unit 7
Defect Removal Efficiency

Software reuse
Vertical
Planned systematic reuse
Terminal Questions
7.10 Case Study

Empirical Software Solutions
Empirical Software Systems is a small manufacture-based company with a
single product in the public access and security domain. The information
system that they possess gives details pertaining to the presence of
individuals at specific locations, and also checks and issues security
badges.
The software of the system is connected to specially designed hardware
peripherals along with a well-defined LAN network connection. The system
handles several aspects ranging from computing from database
manipulation, peripheral hardware to image handling. This company uses
both software and hardware, and incorporates latest technologies such as
networking and device drivers.
Due to the pressure from customers and the competition, they were in need
of a structured software process. There was no standardised development
process. Most of their work was based on customer requests. Every time a
new request from customer came in, more additions were made to the
product. A new version of the software was installed at the customers site
when requested by the customer. All the queries related to technical
support, modifications made to the system, were handled by the
development team. There was no specific design methodology followed and
each developer used his own method of working. Apart from the user
manual, there was no other documentation found held.
B1965
Page No. 140
Unit 7
Challenges:
Introduction of reuse framework and method into the company.
Gain support from the top management for the reuse program, as
introduction of a reuse program can affect all parts of the software
production process.
Suggestions were made to set up the reuse program along with the
associated cost and risk involved in setting up the reuse program.
Study the staff view point and the development process of the company.
Solution:
A structured process was followed for better future prospectus.
1. Planning and reviews Meetings were held on a regular basis, in
order to plan before the commencement of the project. As the project
advanced, meetings were more focused on technical issues to review
what is being done so far, and also plan ahead for the next steps
involved in the software project.
2. Design An object-oriented method of design was used to support
software reuse, as it has the provision for reusable design techniques
and components in software development and maintenance phase.
3. Resource Management The developers stored the reusable code in
the central reusable repository, which could be accessed by all the
employees in the company.
4. Documentation Documentation process was efficiently done and well
maintained to avoid discrepancies.
5. An incremental approach was carried out to introduce software reuse,
so that working practices could be slowly changed and at the same time
fulfil the requirements of their customers.
Advantages:
The effective techniques were identified for software development

process.
Code reviews were carried out and checked for reusability.
Developers could plan for their project and start writing their code in
advance, and also go back to the code, if any kind of restructuring in the
code is required, which will help their code to be more object-oriented
and reusable.
Developers had a clear picture of what they had to create.
B1965
Page No. 141
Unit 7
Instead of the original C++, Fotofile was developed in MS Access which

led to the development of another OLE server. Object linking and
embedding (OLE) helps in creating and editing documents which are
created by multiple applications.
The Fotofile was used to design and print the identification badges.
This will be of great benefit in maintenance, and will also allow the
developers, when going back to the code that they have written, to see
how the software is currently designed. This should help them to identify
useful abstractions which will be reusable
In the finished product, there was a total of just over 20,000 lines of
code. Of this code, 43% was inherited from the standard libraries
available through the Microsoft Foundation Classes. Of the remaining
57% of the code, 24% was automatically generated by the Visual C++
wizards. Of the remaining code which was written manually, 31% was
abstracted into reusable classes that were used more than once within
the application. This gives a total reuse factor of 70% for the whole
project.1
1. Explain the challenges faced by Empirical software solutions and how
did they overcome it.
2. Explain details regarding software code reuse.
(Hint: Refer Section 7.5, Software Reuse)
References:
Pullum, Laura L. Software Fault Tolerance Techniques and
Implementation. Artech House Publishers, September 30, 2001
E-References:
http://artofsoftwarereuse.com/2009/04/02/horizontal-and-verticalsoftware-assets/ (Retrieved on 15th May 2012)
http://portal.acm.org/citation.cfm?id=1478113 (Retrieved on 15th May
2012)
http://students.cs.byu.edu/~pbiggs/smallcomp.html
B1965
Page No. 142
Unit 8
Unit 8
System Engineering
Structure:
8.1 Introduction
Objectives
8.2 Computer System
8.3 Computer Systems Engineering
Hardware engineering
Software engineering
Human engineering
8.4 System Analysis
8.5 System Architecture
8.6 System Specification
8.7 Summary
8.8 Glossary
8.10 Answers
8.11 Case Study
8.1 Introduction
In the previous unit, we studied the software reliability and why it is so
important for software organisations to ensure that the software they deliver
to the customer are reliable, as software failures can lead to colossal losses,
not only in financial terms but also in terms of loss of human lives.
In this unit, we will study about system engineering. We will start our
discussion with a computer system. Then, we will discuss about computer
systems engineering (also called as computer engineering), which is an
amalgamation of many fields of engineering, wherein we will discuss about
hardware engineering, software engineering and human engineering.
Thereafter, we will study about system analysis. We will also familiarise
ourselves with system architecture and system architecture specification.
Then, we will have a brief discussion on system specification and system
specification review.
This unit will enable us to understand the different concepts covered in
system engineering.
B1965
Page No. 143
Unit 8
Objectives:
explain computer systems engineering and its types
elaborate system analysis
describe the system architecture and its specifications
explain system specification review.
8.2 Computer System

Let us start this unit with an overview about the computer system.
We can define a system as an arrangement of different components, to form
an integrated structure, in order to perform a defined task. The computer
system is considered as a working system, which includes both the software
and the hardware or the external peripherals such as the printer, scanner or
router with a common central storage system. The computers that are
connected to the central storage system operate independently, and are
also able to communicate with other computers. For a computer system to
function, the peripheral devices and the software are required.
For example, a computer system requires software, such as an operating
system, as well as the external peripheral device, a printer, in order to
perform the task of printing. So, we can define a computer system as a
basic functional unit, with a storage system that is used for executing either
part of the program or the entire program.
Basics of computer system
In todays world, we can get a better computer for a lesser price as
compared to the past years. This is due to the technological improvements.
So, every time we buy a computer, we must look into the requirements
aspect instead of buying the advanced computer system available in the
market. Therefore, we must always buy a computer that fits our needs. Let
us now have a quick overview of some of the basics of computers.
Central Processing Unit (CPU) The central processing unit is

considered as the brain of the computer, which performs all the tasks of
calculations and makes the programs in your computer work. If you
receive the results faster, then your CPU is considered to be fast.
B1965
Page No. 144
Unit 8
Random Access Memory (RAM) The random access memory is

called the temporary memory of the computer. The information that you
use to run the programs and applications in your computer are stored in
the random access memory. If your computer system has more RAM,
you will be able to run more number of applications at the same time
without affecting the other system operations.
Hard Disk Drive (HDD) The hard disk of the computer is the
permanent memory where all the data related to the computer system
are stored; for example, data files such as PowerPoint presentations,
spreadsheets and databases. If your hard disk is large, then you can
store large volumes of data in it. Although the size of the hard drive does
not have an impact on the speed of the program, the speed of your hard
drive can have an impact on the retrieval of the files.
Optical Disk Drive (ODD) These include optical drives such as CD,
CD-RW, DVD, DVD-RW and Blu-ray Disks. Out of these, the more
common ones are the Compact Disk (CD) drives and the Digital Video
Disk (DVD) drives. These drives make use of a laser in order to read the
data that are etched on the disk. The optical drives also come with the
CD-R, denoting recordable disk, where you can burn the information
only once on to the disk and no other editing can be done. The CD-RW
denotes a rewritable disk where data can be rewritten as many times as
possible, giving you the provision of deleting the old files and adding
new ones. You can also come across the CD-ROM, which denotes the
read only memory, where data cannot be modified. Blu-ray Disks are the
latest addition to the group.
Floppy Disk Drive (FDD) Floppy disk drives have very small storage
capacity (1.44 MB) and are basically used for transferring data from one
computer to another. Nowadays, floppy disk drives have become
obsolete in most of the computers. The cost of the floppy disk drive is
very meagre when compared to the cost of the compact disk drive. In
order to hold hundreds of megabytes of memory, the zip drives were
used in the past, but today they have been replaced by the CD-RW
disks due to less cost. The size of a standard floppy disk is 3.5.
Video card A video card enables you to have better graphical display
of the items on your display screen. The video card is inserted into the
B1965
Page No. 145
Unit 8
motherboard of the computer in order to enhance display capabilities. At

present, most of the video cards come with an in-built RAM and
processor to boost the graphical display. Sometimes, additional video
cards are used for multimedia purposes or playing video games.
Sound card Sound cards are also known as the audio cards, which
are the expansion boards, used to enhance the sound quality of the
system. Sometimes, computers come with sound chips, and hence
there is a requirement to add an additional sound card to improve the
sound quality.
1. The central processing unit acts as the ________ of the computer.
2. The compact disk and digital video disks are also known as the
_________ drives.
3. Spreadsheet is an example of an optical disk drive. (True/False)
Activity 1:
Imagine you are a trainer in a small software company. Explain how
you would train the new recruits from the college, about the basics of
computer and relate the practical use of computers.
(Hint: Refer to Section 8.2, Computer System.)
8.3 Computer Systems Engineering

In the previous section, you have studied the basics of computers, including
the various parts of a computer. In this section, we will study about the
different types of computer system engineering.
The challenge of designing a computer system involves building a system
that consists of both hardware and software components. The concept of
building a computer is similar to the task of building any other electronic
gadget like digital cameras, robots and embedded systems. In order to build
these electronic gadgets, we must first analyse them and then design them
as per our requirements. The various facets of design must be justified both
technically and economically. All these activities can be clubbed together
into a common discipline of study known as system engineering.
B1965
Page No. 146
Unit 8
Computer system engineering is an integration of many disciplines of

engineering such as electronics, electrical and computers. The engineers
are called computer system engineers, and they undergo training in
electronic engineering and the hardwaresoftware integration instead of just
undergoing training on software engineering.
System engineers are involved in several aspects of computing when it
comes to designing the hardware and software. The emphasis is more on
how the various components of both the hardware and the software are
integrated.
Computer engineers do a variety of tasks such as coding for the firmware
for embedded microcontrollers, designing operating systems and analogue
sensors. In the field of research and robotics, computer engineers depend
on digital control systems, and track and monitor the sensors and motors.
Today, there is an increase in demand for computer system engineers who
will be able to design firmware, hardware and also manage the various
computer systems used in an organisation.
The study of computer engineering involves both analogue and digital
circuitry. The prerequisite for the study of computer engineering is to have a
sound knowledge of mathematics and science. A computer systems
engineer also involves himself in the evaluation and installation of various
types of software and other hardware support equipments in the network
area of an organisation.
8.3.1 Hardware engineering
Since we are discussing about computer systems engineering, we will now
discuss about one of its types, namely, hardware engineering.
The branch of hardware engineering has become more and more advanced
considering the advancement in the field of software engineering. The field
of software engineering is ever changing, and so the hardware engineering
industry is also experiencing the same trend, and is considered to be under
a spell of boon.
Today, there is a huge demand for computer chips. Therefore, the hardware
engineers are constantly working in correlation with the software engineers
in developing highly capable and reliable computer chips.
B1965
Page No. 147
Unit 8
The branch of hardware engineering is based on developing and testing the

components involved in building a computer system. The hardware
engineers design and manufacture the new hardware components and
monitor the installation as per the Bureau of Labour Statistics. Components
like circuit boards and microchips are designed along with the other
accessories like printers and keyboards.
The main objective of computer hardware engineering is to bring about
improvement in the existing technology, and the systems manufactured
must function appropriately and meet the end-users needs. Today, most of
the hardware engineers work for software companies, as both hardware and
software are complementary and go hand-in-hand.
We select the hardware for a computer system on the basis of some
characteristics that are listed below:
Components packaged as individual building blocks.
Standardisation of interfaces among components.
Availability of numerous off-the-shelf alternatives.
Ability to determine performance, cost and availability very easily.
A hardware configuration evolves from a hierarchy of building blocks to
discrete components like integrated circuits and electronic components,
such as resistors, capacitors, and so on. They all are assembled as a
printed circuit board that performs assigned operations. The boards are
interfaced with the bus in order to form a system component, like a single
board computer, which in turn integrates to become the hardware
subsystem or hardware system element. The functions that were once
available on a set of PC boards with dozens of integrated circuits are now
available on a single chip.
8.3.2 Software engineering
Let us now study about another type of computer systems engineering,
namely, software engineering.
We can say that software engineering is a profession that involves
designing, modifying and implementing the software in order to obtain highquality, inexpensive, more reliable and cost-effective components. As
mentioned earlier, the term software engineering was coined in the year
1968 at the NATO Software Engineering Conference held in Germany. The
B1965
Page No. 148
Unit 8
software engineering conference was set up to overcome the software

crisis experienced during the early days. We use the term software crisis,
when we face difficulty in understanding, verifying and writing the correct
software programs. Some of the reasons for software crisis are complexity
in code and abrupt change in code. It was always thought that a blend of art
and science led to software development.
The IEEE Computer Societys Software Engineering Body of Knowledge
has defined software engineering as the application of a systematic,
disciplined, quantifiable approach to the development, operation and
maintenance of software, and the study of these approaches; that is, the
application of engineering to software.1
8.3.3 Human engineering
We are now familiar with hardware and software engineering. Next, we will
learn about human engineering. The need for learning human engineering is
due to the fact that there is a human interaction involved in most of the
system activities. The interaction can be as small as a dialog that drives the
unit function of the system.
In the early days, the users had to force themselves to understand and
communicate with the computer-based systems. However, in todays world,
the concept of user-friendliness is used quite often, in order to make the
software system appear less intimidating to the end-user who maybe a
novice at handling computers. The main approach here is to ensure that the
software system developed is user-friendly.
While developing a software system, utmost care is taken to ensure that the
software that is being developed is user-friendly. For example, when people
from different cultural backgrounds interact, the interaction becomes
smoother when a set of rules are followed by both the interacting parties.
However, when it comes to interaction between a machine and a human,
the interaction is sometimes not smooth, as there are no set rules.
Every time when a human interaction is required to perform a certain task or
a specific function, the system engineer allocates the required function. The
components of the human engineering system are well understood, so that
http://en.wikipedia.org/wiki/Software_engineering
B1965
Page No. 149
Unit 8
appropriate functions can be performed. Some of the components of human

engineering system are human memory, knowledge representation, thinking
and reasoning, visual perception and human dialog construction.
We can define human engineering as a multidisciplinary activity that puts
into us the knowledge inherited from psychology and technology to specify
and design HumanComputer Interaction (HCI) of high quality.
Let us now briefly describe the various steps involved in the human
engineering process:
Activity analysis In activity analysis, each activity that is allocated to

the human element is first evaluated as per its required interaction with
the other elements. Then, these activities are divided into tasks, which
are further analysed.
Semantic analysis and design In semantic analysis and design, the

exact meaning of every action required by the user and the
corresponding action produced by the machine are defined. The design
of a dialog brings out the appropriate meaning of the action.
Syntactic and lexical design In the syntactic and lexical design step,
the specific forms of actions and commands are identified, and then the
software and hardware are implemented, as per the action or command
designed.
User environmental design In this step, a user environment is

established with the help of hardware, software and other elements.
This environment will include both the HumanComputer Interaction
(HCI) and physical facilities like lighting and space management.
Prototyping In this step, prototyping takes place. A prototype is

required for specifying an HCI. Using the prototyping method, it is
possible to evaluate the HCI. Thus, prototyping helps us to evaluate the
repetitive applications of all the human engineering steps.
4. Computer system engineering is also known as ____________.
5. The prerequisite for the study of computer engineering is to have a
sound knowledge of ______________ and science.
B1965
Page No. 150
Unit 8
6. The term software engineering was coined in the year 1968 at the
NATO Software Engineering Conference. (True/False)
Activity 2:
Imagine you have been assigned the task of checking the various
integrated software engineering and humancomputer interfaces in your
software company. Explain how you will accomplish the task.
(Hint: Refer to Section 8.3, Computer Systems Engineering.)
8.4 System Analysis

The previous section familiarised us with different types of computer
systems engineering. This section will familiarise us with system analysis.
System analysis is an activity catering to most of the activities of computer
system engineering. System analysis mainly focuses on the elements of the
system, rather than the software.
We conduct a system analysis on the basis of the following objectives:
Determine the needs of the customer.
Assess the system concept for workability.
Carry out economic and technical analysis.
Distribute functions to hardware, software, people, database and other
elements of the system.
Set up cost and schedule constraints.
Create a system definition that makes the basis for all consecutive
engineering work.
In order to meet these objectives, the system engineer must be an expert in
the field of hardware, software and also database and human engineering. It
has been listed by the industry professionals that time and effort are the
most important factors in the system analysis stage, as they are considered
to bring out more profits to organisations in the long run.
Three important questions that arise while performing system analysis are
as follows:
How much effort should be expended on analysis and definition for
systems and software?
B1965
Page No. 151
Unit 8
Who does it?

Why is it so difficult?
Let us now understand some of the important steps used in system

analysis. They are as follows:
Identification of need Identifying the need is the first step in the

system analysis process. The analyst or the system engineer gathers
the requirements of the project. The customer needs and the
customer wants are differentiated appropriately. The features critical to
the systems success are the customer needs, while the features which
are just added and not really essential for the functioning of a system
are called the customers wants. The details gathered during this step
are specified in the system concept document.
Feasibility study Feasibility study deals with the evaluation of the

resources and time. Risk analysis is conducted to identify how various
types of risk can affect the software process so that appropriate steps
can be taken to enhance software quality.
Economic analysis Economic analysis deals with costbenefit

analysis so that correct assessment is made for the software project.
The costbenefit analysis brings out the cost involved for the software
project and also the benefits of the software system. The analysis is
based on the size of the project, which is to be developed along with the
desired investment and strategic plan of the organisation.
Technical analysis Technical analysis involves evaluating the

technical merits of software system and also in gathering information
related to performance, reliability and maintainability. Various technical
analysis tools such as probability, statistics and mathematical
techniques are used.
7. Industry professionals list out time and _________ as the most
important factors in the system analysis stage.
8. Economic analysis deals with __________ analysis so that correct
assessment is made for the software project.
B1965
Page No. 152
Unit 8
9. Technical analysis involves evaluating the _________ merits of

software system and also in gathering information related to
performance, reliability and maintainability.
Activity 3:
Suppose you are assigned the task to analyse the various factors
involved in your project. Explain how you will gather information and
proceed with the analysis task.
(Hint: Refer to Section 8.4, System Analysis.)
8.5 System Architecture

We studied system analysis in the previous section. Let us now study about
system architecture.
We can define system architecture as a conceptual structure and functional
behaviour of a computer system, which is used to determine the overall
organisation. It also describes the different components involved in building
the system architecture and the way in which they are combined.2
Once the various functionalities of a computer-based system are allocated,
we create a system model using an architecture template.
We can see that within a template, a system engineer allocates the system
elements to the five processing regions in the template, as shown in Figure
8.1.
Fig. 8.1: Architecture Template
http://www.answers.com/topic/computer-systems-architecture
B1965
Page No. 153
Unit 8
As per Figure 8.1, an architecture template enables the system engineer to

create a detailed hierarchy.
System architecture gives us an idea about how the various functionalities
and responsibilities of a particular system are divided and allocated to the
various components. Thus, each divided system performs the desired set of
functionality as defined. The topmost system level handles all major
responsibilities of the system.
The term system architecture is used to describe the overall design and
structure of a computer network or system.3 The need for system
architecture arose due to the requirement of consolidating all the physical
devices. At times, the term system architecture is also used to describe
very complex software tools that have several modules.
The complexity of a system varies from one system to another, and it
depends on factors such as user needs, business requirements, funding
and availability of resources. System architecture must always be flexible
and adhere to the ever changing needs quickly. If the structure is very rigid,
then it becomes difficult to assimilate any new hardware or software.
Let us now briefly learn about the four main components of system
architecture. These components are as follows:
Processing power The processing power depends on the computer

or the server. The correct processor must be selected and installed on
to a system. The selection of the processor is based on the software
specifications, number of concurrent users and the connection strength.
The processing power is considered to be the brain of the system.
During the design phase, it becomes difficult to scale the criticality of the
processor. Therefore, the system architecture must allow addition of
processors without any kind of obstruction.
Storage space Storage space is related to the capacity of the hard

drive along with the built-in device in the system. Cost becomes an
important factor because as the cost decreases, the capacity increases,
and this is basically due to the production process involved. From the
architecture point of view, when an element is added on to the process,
http://www.wisegeek.com/what-is-system-architecture.htm
B1965
Page No. 154
Unit 8
the storage capacity increases, which results in a change in the physical

shape.
Connectivity In a network, connectivity is considered as an important

aspect of the design of a system. The system performance can be
enhanced by correctly maintaining the connectivity between the various
aspects of the system. The performance of the system can be increased
by upgrading the network cable, switches and routers.
User experience User experience is the experience of the user, which

is based on both the system performance and system architecture. Only
when a system is well designed, it can respond to the needs of the user
and also support its operations in the long run.
System architecture specification

We are now familiar with the system architecture. Let us now familiarise
ourselves with the system architecture specification.
We can consider a system architecture specification as a high-level design
document. This document provides details pertaining to the users
requirements. The design solutions are bifurcated into hardware and
software modules, and the interaction between these modules is also
described. The system architecture specification acts as a model for the
development of detailed design.
We implement the system architecture specification in an organisation,
during the early stages of development so that the quality of the system and
the functionality are enhanced, thereby leading to increased assurance of
correctness.
When a particular component performs better than what was predicted in
the system architecture section, its details are discussed in the subsection
of system architecture section. Sometimes, the details might be specified in
the design documents. Also, discussions about the way the particular
component is divided and its interactions are mentioned. We must ensure
that the design document must always be consolidated in a proper format.
The specification documents give us a clear picture about the system
architecture, which satisfies the functions and operations of development
and also meets the business proposals. This document serves as an
B1965
Page No. 155
Unit 8
agreement, which states that the system architecture meets the

requirements and when changes occur during the development phase, the
change control request process has to be adopted.
10. The term _________ is used to describe the overall design and
structure of a computer network or system.
11. The system performance can be enhanced by correctly maintaining the
__________ between the various aspects of the system.
12. System architecture specification can be considered as a ______
design document.
Activity 4:
Imagine you have joined as a system engineer in a small company.
Explain how you would allocate the system elements in to a template.
(Hint: Refer to Section 8.5, System Architecture.)
8.6 System Specification

In the previous section, we learnt about system specification architecture
and its specification. We will now learn about system specification.
In order to define requirements, we have to establish the specifications. We
can consider the system specification as a document that is the
basis/foundation of hardware engineering, software engineering, database
engineering and human engineering.
The system specification gives us details pertaining to the function and
performance of a computer-based system, and also the constraints, which
govern during the software development process. These specifications are
bound by each system element. A software engineer can gather details
about the role played by the software in the entire system, and the various
subsystems from the system specifications. The system specifications will
give you an idea about the information, which is basically the data, and
control that is being input, and the corresponding output from the system.
Therefore, we must make sure that the system specification must be
considered as a system specification document. The details of the system
specifications will be indicated by the system engineering standards.
B1965
Page No. 156
Unit 8
If the correct requirements are not established, it will lead to problems of

ambiguity in the later part of the software development life cycle and thereby
lead to off-schedule problems and budgetary issues. Hence, it becomes
necessary for us to establish the requirements in a systematic way, so that
accuracy is achieved and quality is maintained.
Establishing the requirements and implementing the requirements can be
achieved only when an organisation has people with sound technical and
communication skills. When the requirements are weak, they can become a
threat to the dependable systems that are under the phase of development.
Thus, the requirements ensure that a system will not enter into an undefined
state.
Requirements are the first step in the designing process of software
development phase. These requirements must be clear and well
documented in order to generate the corresponding specifications. The
specification phase plays a vital role in the construction of mission-critical
systems. For example, errors that surface during the requirements and
specifications phase will lead to errors in the upcoming phases of
development. Each time when an error is discovered during the phase of
development, the engineers trace back to the specifications and fix the
errors/bugs. This may lead to wastage of time and other requirement
specification errors. Sometimes, we can cite incomplete implementation of
specifications or wrong assumptions as the main reasons for requirement
flaws.
Let us now have a better understanding of requirements and specifications.
We can define a requirement as a condition needed by a user to solve a
problem or achieve an objective; while a specification is a document that
specifies in a complete, precise, verifiable manner, the requirements,
design, behaviour or other characteristics of a system and often the
procedures for determining whether these provisions have been satisfied.4
To bring more clarity to the definition of requirements and specification, we
can take the example of a car. The requirement of a car could be a
maximum speed of at least 120 km/h and the specification for this
http://www.ece.cmu.edu/~koopman/des_s99/requirements_specs/
B1965
Page No. 157
Unit 8
requirement will include the technical information regarding specific design

aspects.
A common term we may come across during the software developmental
process is requirements specification, which we have comprehensively
discussed in Unit 4. As explained earlier, requirements specification is a
document that specifies the requirements of a system or a component. It
includes functional requirements, performance requirements, interface
requirements, design requirements along with the development standards.
Therefore, requirements specification is the documentation details of all the
phases involved in the software development life cycle.
System specification review
As we are discussing about system specification, we will also discuss about
system specification review.
The term system specification review means evaluating the accuracy of
the definitions that are contained in the system specification document.
Sometimes, the review phase may be ignored during the development
phase. This may lead to problems while writing the source code for the
system.
We can define review as a process of checking the details of a subject or
examining and verifying over and over, in order to ensure accuracy. A
review is generally conducted by the developer or the customer to make
sure that the following steps are adhered to:
The scope of the project must be correctly delineated/represented or
sketched.
Functions, performance and interfaces must be defined properly.
The system must be justified by analysis of environment and
development risk.
The developer and the customer must have the same perception about
the objectives of the system.
We will now briefly discuss about two segments of system specification
review shown in Figure 8.2.
B1965
Page No. 158
Unit 8
Fig. 8.2: Segments of System Specification Review
Management viewpoint Management viewpoint is the review that is

conducted based on management opinion, on the various business
aspects pertaining to software engineering process. The following
questions are generated for key management viewpoint:
o Has a firms business need been established? Does system
justification make sense?
o Does the specified environment (or market) need the system that
has been described?
o What alternatives have been considered?
o What is the development risk for each system element?
o Are resources available to perform development?
o Do cost and schedule bounds make sense?5
The aforementioned questions are periodically raised and answered on a

regular basis, during the analysis phase of tasks in the system specification
review.
Technical evaluation of system elements and functions Technical
evaluation review deals with the evaluation of various elements and
functions that are involved in the process of software engineering. The
details gathered during the technical stage of the system review and the
details gathered during the allocation task stage will differ from each
other due to the variation in the functions and the tasks assigned.
B1965
Page No. 159
Unit 8
Let us now consider some issues that must be addressed by a typical

review. These issues are as follows:
Does the functional complexity of the system agree with the
assessments of development risk, cost and schedule?
Is the allocation of functions defined with the required details?
Have interfaces among system elements and also with the environment
been defined in sufficient detail?
Are performance, reliability and maintainability issues addressed in the
specification?
Does the system specification provide sufficient foundation for the
hardware and software engineering steps that follow?6
When the system specification review is completed, other parallel path tasks
start. Thus, the various elements of system engineering such as software,
hardware, database elements and human elements are considered in the
technical evaluation review.
13. System specification is a document. (True/False)
14. The two segments of system specification review are __________ and
technical evaluation of system elements and functions.
15. A review is conducted by the developer or the _________.
Activity 5:
Imagine you are a developer in a small software company. Explain how
you will conduct a system specification review.
(Hint: Refer to Section 8.6, System Specification.)
8.7 Summary
Computer systems engineering has evolved from different engineering
fields such as electronic, electrical, and so on. Its types include
hardware engineering, software engineering and human engineering.
Software Engineering, A practitioners Approach By Roger S. Pressman
B1965
Page No. 160
Unit 8
Computer system engineering is considered as the first step in the

evolution of the modern computer-based system.
Considering system analysis as the basis, the system engineer can
identify the needs of the customer, determine the economic and
technical feasibility and also allocate performance and function to
software, hardware, people and the databases, which make up the key
system elements.
Architectural models of a system can be produced and developed from
each major subsystem. System specification and system specification
review contain the documentation details of the various phases involved
in the software engineering process.
We concluded that computer system engineering is a necessity, when it
comes to developing a software system.
8.8 Glossary
Analogue sensors: Analogue sensors measure information that is
continuous. The Get operation returns the present state of the sensor, while
the Update operation indicates the change state of the sensor.
Bus: A bus is a transmission channel through which signals are sent and
received at the point where a physical device is attached.
CASE (Computer-Aided Software Engineering): CASE tools help the
project managers in all the activities involved in the software process. The
CASE tools automate the project management activities. This tool helps us
analyse, design, code and test.
Firmware: Firmware is used to denote the small programs that are found in
electronic devices and are used to control the various activities of the
electronic device.
NATO: The North Atlantic Treaty Organisation is an intergovernmental
military alliance. This is a collective defence force, where the member states
have a mutual understanding for defence, in response to an attack, by an
enemy.
Processor (CPU): The processor is also known as the central processing
unit and all numeric data are processed.
RAM (Random Access Memory): Random access memory is a volatile
memory. It loses the stored information, when there is no power. It is
different from the non-volatile memory such as a hard disk.
B1965
Page No. 161
Unit 8

1. Explain the basics of computer system.
2. Define computer system engineering and also describe software
engineering, hardware engineering and human engineering.
3. Explain system analysis and how does it help in a development life
cycle.
4. Explain system architecture and describe specification of system
architecture.
5. Describe the system specification review.
8.10 Answers
1. Brain
2. Optical disk
3. False
4. Computer Engineering
5. Mathematics
6. False
7. Effort
8. Costbenefit
9. Technical
10. System architecture
11. Connectivity
12. High-level
13. True
14. Management viewpoint
15. Customer
Terminal Questions
4. (Refer to Sections 8.5 and 8.6 for further information.)
B1965
Page No. 162
Unit 8
8.11 Case Study

Computerised Physician Order Entry Systems for Medications
Nishant Health Care System
Background:
The Nishant Health Care System is a health care system, which is located
in the town of Satara. This health care system has several units, which
handle the various departments. Each of the unit has its predefined set of
goals and objectives, like the research unit, report unit, diagnosis unit and
consultation units. For example, the doctors and the research scientists
were unable to login to the cases at the same instance of time. The system
that is used at present slows down the process when simultaneous access
of data occurs. This was due to the other parallel tasks that are ongoing in
the system.
For example, when the patient information is printed in one of the units, the
system slows down and the other unit would not perform the requested
function and also when performing a task, there were no prompts and
instructions on the display screen, to proceed to the next step. All these
drawbacks had to be overcome, and hence an integrated system was
thought of. Thus, a Computerised Physician Order Entry (CPOE) System
was designed, which helped the health care system authorities to overcome
their drawbacks.
Issues:
Doctors had difficulty in communicating the case data to the research
scientists.
A common documentation was established across the health care system.
Method:
The authorities in the nursing home came up with the integration of
Software Engineering (SE) and HumanComputer Interface (HCI). Several
interesting models and activities were put to practice. The ergonomic
perspective of designing an user interaction equipment at the work place, in
order to make it more user-friendly, so that the problem which was faced
earlier by the health care system, does not repeat again. Also, the other
technicalities involved in designing the system were considered.
B1965
Page No. 163
Unit 8
A comparative study was made between the previous situations and the
present situation.
Results:
The latest techniques helped Nishant Health Care System with a common
work support.
The cases in the nursing home could be easily accessed by the research
scientists as well as the doctors simultaneously.
1. Explain how Nishant Health Care Systems, accomplished having an
integrated system of software engineering and human interface.
References:
B1965
Page No. 164
Unit 9
Unit 9
Analysis Concepts and Principles
Structure:
9.1
Introduction
Objectives
9.2
Requirement Analysis
Analysis tasks
9.3
Communication
Problem areas
Communication techniques
9.4
Analysis Principles
Understanding information domain
Creating models
Partitioning the problem
Processing information
9.5
Software Prototyping
Prototyping methods and tools
9.6
Software Requirements Specification
9.7
Summary
9.8
Glossary
9.9
Terminal Questions
9.10 Answers
9.11 Case Study
9.1 Introduction
In the previous unit, we discussed about system engineering wherein we
described the three types of computer systems engineering, namely,
hardware engineering, software engineering and human engineering. We
also discussed about system analysis and analysed the specifications of
system architecture.
In this unit, we will revisit requirement analysis in software engineering,
study various analysis principles and the scope of communication in
software engineering. We will also analyse the problem areas and
techniques of communication. We will discuss the importance of software
prototyping and various prototyping methods. The need for Software
Requirements Specification (SRS) will be reiterated, and we will also study
how the specification is reviewed.
B1965
Page No. 165
Unit 9
The unit will enable us to analyse the requirements of both the developer
and the user using various principles. We create prototypes or provide the
specification documentation to check the requirements.
Objectives:
explain requirement analysis and the analysis tasks
describe the scope of communication
explain the analysis principles
demonstrate software prototyping and software specification
9.2 Requirement Analysis

Let us start our discussion by revisiting the concept of requirement analysis.
Requirement analysis (or requirements engineering) is one of the tasks
performed under the analysis phase of software engineering. We will
discuss the other tasks performed under the analysis phase of software
engineering later in this section.
It is a process of analysing the customer requirements and prospects for a
new or changed product. All these requirements should be finite,
appropriate and comprehensive. This analysis is carried out through a
planned system. We can say that the requirement analysis is a process:
Initiated at the start of a project and it continues throughout the life cycle
by constantly undergoing modifications.
That recognises software needs and deals with them by using software
configuration management methods.
That adapts to the organisation and project background.
You must note that the requirement analysis is a vital aspect of project
management. The software requirement analysis links the gap between
software design and system engineering as shown in Figure 9.1.
Software
design
Software
System
requirement
engineering
analysis
Fig. 9.1: Requirement Analysis as a Bridge

B1965
Page No. 166
Unit 9
We must understand that requirement analysis is a group work that involves

both hardware and software and human factors who are experts in
engineering and have talent in dealing with people. The requirement
analysis offers you (as a software developer) with a representation of
information, function and behaviour that can be transformed to data,
architectural, interface and component-level designs. It is the means to
assess quality by both the client and the developer while the software is
being developed.
9.2.1 Analysis tasks
Now that we have recapitulated the requirement analysis phase of software
engineering, let us now discuss about the analysis tasks.
We know that analysis is an important phase of software engineering. In the
analysis phase, we concentrate on the information domain of the software,
its main functions, and so on, for analysing the nature of the program to be
developed. The main purpose of this phase is to determine the need and
specify the problem that is to be solved. Normally, the analysis phase
involves the following four tasks or operations.
Feasibility study This task or operation includes an elaborate study

of all the needs for determining the possibility to meet all these needs or
requirements. This process may involve a visit by the development team
to the clients premises for their system study. The team examines the
requirement for possible software automation within the ambit of the
given system.
Broad planning This task involves the creation of an outline

document depicting proper planning of available resources and time.
Technology selection It comprises identifying, analysing and

compiling different tools and technologies, which would be required for
the successful accomplishment of the project.
Requirement analysis This task includes the identification and

compilation of different needs of human resources, hardware and
software, which would be required for successful accomplishment of the
project.
B1965
Page No. 167
Unit 9
We can categorise software requirement analysis into five domains as

Fig. 9.2: Domains of Software Requirement Analysis
Let us now briefly describe the domains depicted in Figure 9.2.
Problem identification This is one of the main tasks performed

during the analysis phase. We study the system specification and the
software project plan in this task. It is necessary to understand software
in a system environment and to review the range of software that is
used to produce estimations of planning. After we identify the problem,
communication takes place. Communication for analysis is vital in
recognising the problem and confirming it. Our main aim is to identify the
basic issues as observed by the client/users.
Evaluation and synthesis In the next domain, we evaluate the issue

and propose a solution that turns out to be a great area of effort for
analysis. We must describe all visually observable data objects, validate
the flow and content of information, describe and explain in detail all
software functions, understand software behaviour in the framework of
events that affect the system, develop characteristics of system
interface and clearly explain the design constraints. All these tasks aid in
explaining the problem, so that we can propose a holistic solution.
Modelling Throughout the valuation and solution proposal activity, we

need to develop models of the system to have a better understanding of
the data and control flow, functional processing, operational behaviour
and information content. The model assists as a base for software
design and as the source for creation of specifications for the software.
B1965
Page No. 168
Unit 9
Specification After the analysis of the problem and the essentials, we

must detail the requirements in a document named as Software
Requirements Specification (SRS). This document consists of all the
function-related and performance-related requirements, the format for
inputs and outputs and all the existing design constraints. You have
already learnt in detail about the SRS in Unit 4.
Review This is the last task performed under the analysis phase.
Here, we review and validate the requirements detailed in the SRS. The
main purpose of this task is to ensure the presence of all the
requirements in the SRS document. We must perform a critical review of
the requirements specification. Usually, a group of people including
representatives of the client performs this task.
1. Requirement analysis is one of the tasks performed under the
__________ phase of software engineering.
2. The software requirement analysis links the gap between software
design and system engineering. (True/False)
3. ______________ for analysis is vital in recognising the problem and
confirming it.
9.3 Communication
In the previous section, we had an overview of one element of successful
software development, Requirement Analysis and its tasks. In this section,
we will discuss about another important element of successful software
development, namely Communication.
Communication helps us to gather and form relevant information, share
knowledge and create functioning products. Communication provides better
vision of the processes and products than a program or code.
9.3.1 Problem areas
As we are discussing about communication, let us have an overview of the
problematic areas associated with it.
You might have seen that an individual works in one or more projects that
are carried out in an organisational framework. Communication is very
B1965
Page No. 169
Unit 9
important for teams that are distributed and also for co-located interorganisational associations between various projects.
Software engineering and humancomputer interaction are the two
disciplines that lack communication, despite the fact that these two
disciplines work simultaneously on different software projects on a daily
basis. In both these disciplines, different terminologies are used for the
same tasks. In many cases, loss of efficiency takes place because of the
highly overlapping functions performed by engineers in these two
disciplines, often performed at twice the cost where the functions that can
be performed by only one person are performed by two or more persons.
Today, we all have acknowledged that the problems in communication are
the main reasons behind the delay and failure of software projects. As
extensive communication for conveying information both within the
development team and with the different stakeholders is expensive and time
consuming, therefore one-way communication is opted for in the form of
specification documents (such as SRS). Some people argue that this is an
ineffective form of communication as documentation does not clarify doubts
and misunderstandings.
Another communication problem that we notice is the presence of
organisational barriers that restrict communication among the development
teams. For example, in conventional software engineering, the processes
and functions to be carried out by various groups of developers/
programmers are classified into several phases. This can restrict the
effective and on-time communication among the groups working in different
phases.
If we try to solve these problems, we can successfully complete our
software projects on time and deliver the products to our clients without
brooking unnecessary delay if we make an attempt to solve the above
problems.
9.3.2 Communication techniques
We will now study the types of communications, namely informal and formal
communication and the associated techniques.
We can define formal communication as the communication through the
written specification documents, reports, status meetings, protocols, source
B1965
Page No. 170
Unit 9
code, and so on. The techniques involved in this form of communication are
as follows:
Group, directing group and breakthrough meetings where the entire

team (group) is summoned for meetings that are conducted regularly.
Status meetings where the personnel presents the status of the project
results.
Formal meetings using communication channels.
Formal documentation that is shared with all the team members and
associated people.
Informal communication is an explicit communication via diverse

communication channels like telephone, video and audio conference, voice
mail, e-mail and other verbal communications. The techniques involved in
this form of communication are as follows:
Face-to-face discussions such as informal group meetings.
Informal discussions using various communication channels like e-mails,

videoconferencing and others.
Any means of ad hoc communication.
We can describe the ad hoc activities as interactions forming a logical

communicative element, consisting of one or more sequences with internal
continuity. They do not have association with ambient process. Ad hoc
communication arises when a team member suddenly interrupts another
team member by asking questions or to provide unnecessary information
that is unwarranted.
4. __________ helps us in gathering and forming relevant information,
sharing knowledge and creating functioning product.
5. ___________ in communications are the main reasons behind the
delay and failure of software projects.
6. The two types of communication are formal and __________.
7. Communication is not important in software engineering. (True/False)
B1965
Page No. 171
Unit 9
Activity 1:
Imagine that you are the manager leading a group of software
developers.
Prepare a list of all the communication requirements that the team
member should possess.
What the basic problems you find in the communication of software
engineers?
(Hint: Refer to Section 9.3.1, Problem areas)
9.4 Analysis Principles

By now we have become familiar with analysis concepts. We will now
discuss analysis principles.
We can observe that many analysis modelling methods have been
developed over the past few years. Investigators have identified the analysis
issues and the causes for these issues. They have solved the issues by
continuously developing various modelling methods.
Note that the analysis methods are unique and are associated by a set of
operational principles. Let us have a look at these principles below:
Represent and understand the information domain of a problem.
Define the performance functions of the software.
Represent the behaviour of the software.
The hierarchy of the model should be clearly partitioned that depicts

information, function and behaviour.
The entire analysis process should go from necessary information

towards implementation aspect.
We must tackle a problem systematically by using the above principles. The

information domain is thoroughly studied to gain an in-depth understanding.
We must develop models to make others understand the features and
behaviour of function. The problems are partitioned to decrease the
complexity. It is necessary to understand the constraints of the software and
implementation aspects. The logical constraints are raised due to
processing requirements and the physical constraints are due to system
elements.
B1965
Page No. 172
Unit 9
We will now learn about these principles one by one.

9.4.1 Understanding information domain
Let us now briefly discuss the first principle, which is about understanding
information domain.
Software applications are collectively called data processing. Software is
developed to achieve the following.
Process data
Modify data from one form to another (input to output)
Generate output
Events are processed by software. An event is a representation of an

aspect of system control, which is a Boolean data (either on or off, true or
false, present or not present). For example, a temperature sensor detects
the temperature; when the temperature exceeds the threshold value, an
alarm signal is sent to the monitoring software. In this example, the event is
to control the system behaviour by the alarm signal. Both data and control
are constituents of the information domain.
You must consider few aspects for understanding the information domain.
The following are the aspects of information domains data and control and
each of these is processed by a software program:
Data model depicting information content and links
Flow of information/Information flow
Structure of information
Data model depicting information content and links

In the information domain, there needs to be a data model that signifies the
information content and links. The information content depicts individual
data and control objects, which comprises large collection of information
altered by the software.
We can refer the content of a control object as the termed system status. It
is defined by a bit pattern. Each bit corresponds to a different aspect of
information that represents whether a particular device is online or offline.
Data and control objects can be linked to other data and control objects.
B1965
Page No. 173
Unit 9
Flow of information/Information flow

The second aspect that we must consider is information flow which depicts
the way in which the data and control alter as each of them pass through a
system. You can see the input objects being transformed to output shown in
Figure 9.3.
Inputs
Transform 1
Intermediary data
and control
Store Data/Control
Transform 2
Outputs
Fig. 9.3: Pictorial Representation of Information Flow
We can add information along the transformation path which is available in

the store. The transformations added to the data are functions/sub-functions
that a program needs to execute.
Structure of information
This aspect of information structure depicts the internal organisation of
different data and control aspects. An assessment of information structure
answers all the queries related to information structure such as hierarchical
structure, link between different information, and so on.
9.4.2 Creating models
After discussing the principle of understanding the information domain, we
will now discuss the second principle of creating models.
Note that functional models are created to demonstrate the creation of
models for gaining better knowledge to build the actual entity. If the entity is
a physical object, we can create a model that is similar in form and shape to
the physical object but smaller in dimension. If the entity is software, the
model created should have the capability to represent the information that
software transforms, the functions that facilitate the transformation to
happen and the behaviour of the system as the transformation happens.
We will now briefly demonstrate two types of models: functional models and
behavioural models.
B1965
Page No. 174
Unit 9
Functional models
In functional models, information is transformed by software; to do so, the
software should perform three functions, namely: input, processing and
output. We should focus on functions specific to issues/problems when we
create a functional model of an application. The functional model starts with
naming the software. Along the process that is a series of repetitions more
details of the function are given. The details are given until a thorough
description of the entire system functionality is presented.
Behavioural models
The basis of the behavioural model is the response of software to the
events from the outside world (users). A computer program takes various
states (such as wait, compute, print), which can be externally observed, and
the state changes only when an event occurs. For example, software
continues to be in wait state until:
The internal clock indicates that time period has passed.
Interrupt is caused due to external event, or.
Signals or commands are given by an external system to the software to

execute in a given manner.
A behavioural model creates an illustration of the states of the software and

the events that facilitates the software to change state.
You might have noticed that the models created during requirements
analysis are very important. Let us analyse their importance from the belowmentioned points.
The model helps us to understand the information, function and

behaviour of a system. Hence, the requirements analysis task is made
easier and systematic.
The model becomes the vital point for review and thus provides solution
to determine the completeness, consistency and correctness of the
specifications.
The model becomes the base for design; the required representation of
the software that can be mapped into an implementation aspect is given
to the designer.
B1965
Page No. 175
Unit 9
9.4.3 Partitioning the problem

As we are discussing about the analysis principles and have already
discussed about the principle of understanding the information domain and
the principle of creating models, we will now discuss another principle,
namely, partitioning the problem.
Problems are always broad and complex to understand. To understand the
problem better, we partition the problems into parts for getting a clear
picture, and we also establish interfaces between the parts so that the entire
function can be accomplished. Theoretically, hierarchical representation is
first established and later the uppermost element is partitioned by the
following.
More details are found by moving vertically in the hierarchy. For example, if
we consider Figure 9.4, we can notice the sub-functions related to
SafeHome function, illustrated by representing the details vertically in
hierarchy.
Vertical partitioning
Observe
sensor
status
System
configuration
Sensor
event poll
SafeHome
software
Check type
of event
SensorActivate/
Deactivate
Sensors to
monitor
Activation
of alarm
function
Interaction
with
user
Activate
alarm
(sound)
Call dial
phone
number
Fig. 9.4: Vertical Partitioning
Decompose the problem functionally by moving horizontally in the hierarchy.

For example, if we consider Figure 9.5 where the horizontal decomposition
of SafeHome is illustrated, we will notice that the problem is partitioned,
showing the functions moving horizontally in the hierarchy.
B1965
Page No. 176
Unit 9
SafeHome software
System
Configuration
Sensors to
monitor
Interaction with
user
Horizontal Partitioning
Fig. 9.5: Horizontal Partitioning
9.4.4 Processing information

After the problem partition, we will now familiarise ourselves with the
principle of processing information.
There are two views related to information, namely, the essential view and
the implementation view. In the essential view, we must present the
functions to be accomplished and the information to be processed without
considering the implementation details. For example, the essential view of
the sensor is to only read the sensor status; it is not concerned about the
physical form of the data or the sensor used. The implementation view of
the software requirement is the depiction of the real world demonstration of
processing functions and information structures.
Let us consider an example of SafeHome, which is a device that consists of
sensors used to detect all situations. This device can be programmed by the
owner and will automatically call a monitoring agency when any situation
that requires monitoring is detected. For example, consider a SafeHome
input device which is a perimeter sensor. The sensor detects prohibited
entry by sensing a break in the electronic circuit. The general features of the
sensor should be observed as part of an SRS. We can identify the
constraints raised by predefined system elements that are sensors and
consider the implementation view of function and information when such a
view is relevant.
8. The basis of the behavioural model is the __________ of software to
the events from outside world (users).
B1965
Page No. 177
Unit 9
9. In the ___________ view, we must present the functions to be

accomplished and the information to be processed without considering
the implementation details.
10. In ___________ models, information is transformed by software.
9.5 Software Prototyping

After studying the analysis concepts and principles, we will now have a
discussion on Software Prototyping.
We can define software prototyping as the rapid development of software to
evaluate the requirements. Prototype is developed to facilitate you and
developers to understand the requirements for the system. Prototype is
necessary at the start of the analysis because creating models is the only
way through which requirements can be efficiently derived. The model then
grows into production software. Thus, the prototype is considered to reduce
risk which in-turn reduces requirements risks.
Let us have a quick overview of the benefits of establishing a prototype in
the software process as given below.
Confusions between software developers and users may be recognised

as the system functions are verified.
Missing user services may be spotted.
User services that are difficult to use or confusing can be detected and
corrected.
Software development team can find incomplete and/or inconsistent

needs as the prototype is established.
Though limited, a working system is readily available to determine the

possibility and effectiveness of the application to management.
The prototype offers basis for writing the specification for a production
quality system.
9.5.1 Prototyping methods and tools

As we are now familiar with the concept of prototyping, let us proceed
forward and have a discussion on prototyping methods and tools.
B1965
Page No. 178
Unit 9
A prototype is said to be effective when it is rapidly developed so that the

client or user assesses the results and mentions changes. We can follow
any of the techniques given below, to carry out rapid prototyping.
4GT This is the fourth generation technique that involves extensive

collection of database query and reporting languages, program and
application generators and other high level languages. 4GT is said to be
very ideal for rapid prototyping because it facilitates the software
engineer to develop an executable code rapidly.
Formal specification Many formal specification languages have been

developed replacing natural language specification techniques.
Currently, developers of formal languages are in the course of
developing interactive environments to enable us to interactively create
language-based specifications of a software or system, invoke
automated tools to modify language-based specifications into
executable code and facilitate the client/customer to use the prototype
executable code to polish and upgrade formal requirements.
Reusable software elements This method involves assembling a set

of available software elements instead of building a new prototype from
scratch. This method of merging prototyping and program element reuse
works if library system is developed so that the elements present can be
categorised and recovered. The software product that is available can
be utilised as a prototype to develop a new and improved product. This
is in a way a kind of reusability for software prototyping.
If we talk about tools, the tools facilitate designs to be easily explained,

shared for review and used to create the specification document. Let us see
the four types of tools used to create user interface prototypes.
Manual drawing using pen and paper This is a good method as it

gives the opportunity to anybody to get involved in the design process.
We can create layouts of designs not only on paper but also on
whiteboards computers are not involved at all. The hand-drawn
designs or pre-existing designs can be used to create a new design. We
can quickly create the designs but cannot easily modify them. It is better
to effectively utilise the time before laying out the design on paper.
During tests and reviews, you should present the effects of user actions
on a design.
B1965
Page No. 179
Unit 9
Drawing tools Drawing tools such as Microsoft Visio and others

consisting of stencils are used. Many tools are based on graphic
images. Graphic editors like Adobe Photoshop are used to create
interface mock ups. A wide range of graphic editors are found with web
designers. The results of drawing and graphic tools are a set of static
screen designs but there is no easy way to dynamically understand how
the parts work and the workflow between them. Records of techniques
are available to take care of the limitations. Printouts of the screens are
taken and are reviewed.
Development tools Development tools are optional. The advantage is

the ability to produce a completely working prototype that acts as a real
object even if some real and definite functionality is being simulated with
false data.
Specialised prototyping tools The benefits of drawing tools,

development tools and specialised prototyping tools like Graphical User
Interface (GUI an interface between a user and a computer system,
using the cursor on a mouse-controlled screen for making choices,
starting programs by clicking icons, and so on). Design Studio (a GUI
design tool for Microsoft Windows, which can be used for rapid creation
of demonstration prototypes excluding any coding or scripting) are
combined to create software prototypes with elements which allow the
interaction and workflow to be undertaken. They are explicit for the
design of user interfaces and are very easy to use as they do not require
any technical skills.
11. ____________ is a graphical user interface design tool for Microsoft
Windows that can be used for rapid creation of demonstration
prototypes excluding any coding or scripting.
12. The advantage of ___________ is the ability to produce a completely
working prototype that acts as a real object even if some real and
definite functionality is being simulated with false data.
13. 4GT stands for ___________.
B1965
Page No. 180
Unit 9
9.6 Software Requirements Specification

The previous section familiarised us with an important aspect of software
development, that is, software prototyping. Let us now recapitulate software
requirements specification that will help us to understand specifications
review.
Specification is a document that describes the requirements of a system
from the user point of view. SRS is a complete description of the function,
performance and environment for the software under development. SRS is
provided at the end of analysis task. SRS specifies functional description in
detail, represents system behaviour, performance requirements, design
constraints, relevant validation conditions and other information related to
the requirements such as security, maintainability, reliability, auditability,
and so on.
Almost all organisations have proposed their own formats for SRS. Let us
now briefly describe the sections of SRS (according to the typical format).
The sections are as follows:
Introduction The goals and objectives of the software are specified.

They are described in the context of the computer-based system.
Information description It gives you a detailed description of the

issues that the software should resolve. The information content, flow
and construction are mentioned. Both hardware and software along with
human interfaces are described for external system elements and
internal software functions.
Functional description In this section, we describe all the functions

required to solve the issue. We provide every function in a narrative way
and we also state design constraints, performance characteristics and
graphical representation of the structure of the software and other
system components.
Behavioural description This section specifies the external events

that are produced during examination of the operation of software. The
operation of the software is examined as a consequence of specification
of external events. This section also specifies the control characteristics
that are internally generated.
B1965
Page No. 181
Unit 9
Validation conditions This is the most important section of SRS. It

specifies certain conditions or measures as to how to identify a
successful implementation, the kinds of tests that should be conducted
to evaluate function, performance and constraints. This section is noted
to be neglected because completing it requires in-depth understanding
of system requirements which is something not available at this level.
However, specification of validation condition behaves as an implicit
review of other requirements.
Bibliography and Appendix References to all documents that relate

to the software are specified in bibliography. It also includes additional
software engineering documentation, technical references, vendorliterature and standards. The appendix includes information that
complements the specifications. It also includes detailed description of
algorithms, results additional information, tabular data, graphs and
others.
As explained in Unit 4, SRS should be proper, unambiguous, complete,

consistent, stable, ranked for importance, verifiable, modifiable and
traceable.
We may supplement SRS by an executable prototype, a paper prototype or
a preliminary user manual. The preliminary user manual gives importance
for user input and the corresponding output. The manual serves as a vital
tool for detecting issues at the humanmachine interface level.
9.6.1 Specifications review
After studying the sections of SRS, let us now briefly study about the
specifications review.
SRS is reviewed by both the software developer and the client. The
specification is the base of the development stage and we must take great
care in conducting the review.
The reviewers attempt to make sure that the specification is complete,
consistent and accurate by considering the overall information, functional
and behavioural areas. The reviewers can be specialists in reviewing,
invited experts, people interested in the product, people from same team or
other division of the organisation. Let us see the guidelines for any review,
as given below.
B1965
Page No. 182
Unit 9
1. Before review
o
Plan formal reviews as a part of project planning.
Keep all the reviewers in the loop.
Assure all participants prepare in advance.
2. During review
o
Review the product (author should not review) comments given

should be constructive, task-focussed and professional.
Go with the agenda any deviation should be thwarted by the

leader.
Limit debate and rebuttal issues are noted down for later
discussion.
Recognise the problems.
Record the proceedings.
3. After review
o
Review the complete process.
Generally, we follow a checklist too for specifications review. The checklist

consists of questions that produce a negative response. Following are few
questions specified in the checklist.
Do given goals and objectives for software remain consistent with the
system goals and objectives?
Have all data objects been explained?
Are design constraints realistic?
Are technological risks completely described?
Is the behaviour of the software consistent with the information it must

process and the functions it must execute?
Have functions been elaborated to a good level of detail?
Let us see an example of an extract of a checklist for minimum

requirements of an SRS in Table 9.1.
B1965
Page No. 183
Unit 9
Table 9.1: Checklist for SRS
Serial
no.
Yes/
No
1.
Is the project formally accepted by the client?
2.
Has the client accepted the final SRS

document?
3.
Are there any issues in the requirements?
4.
Can each requirement be tested and verified?
5.
Are interfaces with other hardware /software

systems completely specified in the SRS?
Remarks/Co
mments
The specification becomes the contract for software development. During

the review, changes can be recommended to the specification. It is difficult
to assess the global impact of a change. For example, it is difficult to assess
how the requirements of other functions are affected if there is a change in
one function. Modern software engineering environments use various tools
such as Computer-Aided Software Engineering (CASE) that have been
developed to solve these issues.
14. Behavioural description section in SRS specifies the external events
that are produced during ___________ of the operation of software.
15. _________ is a complete description of the function, performance and
environment for the software under development.
16. Software requirements specification is reviewed by both the software
developer and the client. (True/False)
17. During the review, changes cannot be recommended to the
specification. (True/False)
Activity 2:
Assume that you are a project manager for a library management
software project. Prepare a checklist for the SRS.
(Hint: Refer to section 9.6.1, Specifications review.)
B1965
Page No. 184
Unit 9
9.7 Summary
Let us now recapitulate the important concepts discussed in this unit:
Requirement analysis is the first step in the software process. A general

statement of scope of software is developed into a strong specification
at this stage which in turn, becomes the base for all software
engineering activities.
Requirement analysis specifies a step-wise use of principles, languages,

techniques and tools for efficient analysis, documentation and
accommodating the continuously growing needs of user, and the
specification of visible behaviour of a system with the end goal of
meeting the user requirements.
There are five domains of software requirements analysis, namely,

problem identification, evaluation and synthesis, modelling, specification
and review.
Communication is an integral element of successful software

development and can be done by formal as well as informal techniques.
There are two types of models in the context of analysis functional

model and behavioural model. Problems are always broad and complex
to understand. To understand the problem better, we partition the
problems into smaller parts for getting a clear picture, and we also
establish interfaces between the parts so that the entire function can be
accomplished. Structure illustrates the core of requirements and details
of implementation are developed later.
Prototyping facilitates an alternative method that results in an

executable model of the software from which requirements can be
developed. Special tools and techniques are used to carry out
prototyping, such as drawing tools like Visio, and so on.
The SRS is the final output of the analysis phase. Review is an

important aspect to assure that the developer and the client have similar
understanding of the system. This helps to reduce impedance
mismatch between these two.
B1965
Page No. 185
Unit 9
9.8 Glossary
CASE tool: It is a software tool, like a design editor or a program debugger,
which is used to support an activity in the software development process.
Human factors: Human factors are also called ergonomics. It is the study
of how humans act physically and psychologically in relation to particular
environments, products or services.
User interface design: The process of designing the method in which the
system users can access the system functionality and the information
generated by the system is displayed.
Validation: The method of checking that the system meets the
requirements and expectations of the client is validation.
Verification: The method of checking that the system meets its
specification is verification.

1. Explain requirement analysis.
2. Briefly describe the problem areas of communication.
3. Explain briefly the analysis principles.
4. What is software prototyping?
5. Explain the prototyping techniques and tools.
6. What is a software requirements specification? Explain with an example.
9.10 Answers
1. Analysis
2. True
3. Communication
4. Communication
5. Problems
6. Informal
7. False
8. Response
B1965
Page No. 186
Unit 9
9. Essential
10. Functional
11. Design studio
12. Development tools
13. Fourth generation technique
14. Examination
15. SRS
16. True
17. False
Terminal Questions
9.10 Case Study

Failure of a Mission-Critical Software
The maiden flight of the Ariane 5 was a failure, about 40 seconds after
initiation of the flight sequence. At a height of about 3,700 m above the
ground, the launcher deviated from its flight path, broke up and exploded.
The failure was due to entire loss of guidance and attitude information. The
failure report said the loss of information was because of specification and
design errors in the software of inertial reference system. Extensive
reviews and tests conducted during the launchers development programme
did not include sufficient analysis and testing of the inertial reference system
or of the entire flight control system (FCS).1 The program was reused from
Ariane 4 guidance system. The Ariane 4 has different flight features in the
first 30 seconds of flight and exception conditions were produced on both
inertial guidance system channels of the Ariane 5.
Case study referred from http://www.rvs.uni-bielefeld.de/publications/Reports/ariane.html
B1965
Page No. 187
Unit 9
The programming language was also considered. The documents of Ariane

5 were later thoroughly studied. The requirement specification and the
design specifications of Ariane 5 were not considered and that the program
of Ariane 4 was used which had different requirement specifications. The
failure was due to either requirement or design specifications.
The faults that caused the failure of the rocket were partly due to
programming, design errors and requirement errors. This case study
illustrates issues mainly related to requirement specifications, critical
systems validation and problems of software reuse. It shows that good
software engineering can have problems (reuse).
1. List the factors that led to the failure of the rocket.
2. According to you, what is the first step of the process (initial step) to
reuse the program from another system?
3. Illustrate a similar scenario or any software engineering issues around
you.
E-References:
http://www.itswtech.org/Lec/Rand%28SoftwareEng%29/Software%20
Engineerin%20%20%204.pdf (Retrieved on 15th May 2012)
http://www.rspa.com/checklists/reqspec.html (Retrieved on 15th May

2012)
http://microscotoolsinc.com/Howsrs.php (Retrieved on 15th May 2012)
B1965
Page No. 188
Unit 10
Unit 10
Software Design Concepts and Principles
Structure:
10.1 Introduction
Objectives
10.2 Software Design
Design concepts
10.3 Design Process
Stellar software design process
10.4 Design Fundamentals
Principles of design
10.5 Modular Design
Advantages and Disadvantages
10.6 Data Design
10.7 Architectural Design
Advantages of architectural design
10.8 Procedural Design
10.9 Design Documentation
Guidelines for improving design documentation
10.10 Summary
10.11 Glossary
10.13 Answers
10.14 Case Study
10.1 Introduction
In the previous unit, we studied analysis concepts and principles, wherein
we described the scope of requirement analysis and various analysis tasks,
importance of communication and different analysis principles. We also
discussed the importance of software prototyping and various prototyping
methods and tools, revisited software requirements specification and learnt
about specification review.
In this unit, we will discuss about software design and its aspects, the
design process and fundamentals and different design methods such as
modular design, data design, architectural design and procedural design.
B1965
Page No. 189
Unit 10
We will also analyse design documentation and learn some guidelines that
we need to follow while preparing the design documentation.
This unit will enable us to analyse the importance of software design, which
is the base for all the software engineering, and the steps to follow in order
to develop an appropriate design. This unit will familiarise you with the
concept of various design methods and their advantages such as how the
architectural design helps to develop structural model, subsystem
decomposition model, and so on. This unit also presents how the design
documentation should be developed which is a means to communicate and
record.
Objectives:
describe software design
explain the design process and its fundamentals
demonstrate modular design and data design
illustrate architectural design and procedural design
briefly explain design documentation
10.2 Software Design

Let us start our discussion with the concept of software design.
The process of depiction of how a particular software is to be developed is
called software design. The design also includes requirements, practices,
methods, life cycles and guidelines to develop a system. Software design is
a structured methodology. There are various methodologies that specify
complete set of standards, tools, procedures and documentation. The aim of
any methodology should be to establish:
A style and procedure for the way a system is developed or an
existing/available system is improved.
Management control should present milestones and checkpoints for the
development.
Quality of the product as per the specifications.
Software design is applied irrespective of the software process used. This is
the first technical task after the software requirements have been analysed
B1965
Page No. 190
Unit 10
and specified. The design is followed by generating code and testing of the
design.
Let us see the flow of software design model in Figure 10.1.
Fig. 10.1: Flow of Software Design Model
It is commonly known that design is always worthwhile. Yet, in most cases,

the product developed will be more or less altered from what was planned
earlier. It is not easy to say how much to plan and design and there are
various organisations to deal with such issues. Some individuals follow the
upfront design, others believe in coding first and then solving the problems
as and when they occur.
The decisions related to software design are made during the design phase,
which will ultimately affect the success of software development and
maintenance of the software. We can know the quality of the software by its
design. In software engineering, design is the stage where quality is
cultivated. The design symbolises software that can be assessed for quality.
The customers requirements can be converted into a product (software
end-product) through design. If a model is developed without design, there
is always a risk of developing an unstable model. This unstable model will
fail when even small changes are incorporated into the scheme of things.
Such unstable models are also difficult to test. The quality of such design
cannot be assessed until late in the software process.
B1965
Page No. 191
Unit 10
10.2.1 Design concepts

Let us have a brief discussion on the various concepts developed to
describe well-structured/designed object-oriented systems.
Separation of concerns We can define this concept as a process of
separating a program into individual features that coincide in
functionality. This is very important in the design phase.
Open closed principle, the single responsibility principle and the

Liskov substitution principle The open closed principle specifies
that an application can be structured by adding new functionalities with
minimum modification to an existing program. The single responsibility
principle facilitates writing small classes and methods, and each class
should implement a cohesive set of associated functions. The Liskov
substitution principle states that any implementation of an abstraction
can be used at any place which accepts that abstraction.
Responsibilities, cohesion and coupling The system is divided into

modules, each with its unique area of responsibility. Cohesion is a
measure of class, whether it is well defined, and specifies meaningful
responsibility. High cohesion is always preferred. Coupling defines how
the class is entangled or dependent with other classes. A loosely
coupled design means that classes can be broadly classified
independently from one another.
Orthogonal code We can define it as a process of writing codes

based on concepts of loose coupling and high cohesion.
Dependency inversion principle This principle is used to separate

one class from the actual implementation of its dependencies.
Composition is better than inheritance Composition is better than

inheritance because composition offers less coupling and good
flexibility. Composition also provides extra objects which can be
interconnected. The strategy objects can be dynamically changed at run
time in composition. In inheritance, the mix and match of the strategy
objects is not possible especially during run time.
1. Which principle is used to separate one class from the actual
implementation of its dependencies?
B1965
Page No. 192
Unit 10
2. The software design is applied irrespective of the software process

used. (True/False)
3. We can define _______________ as a process of writing codes based
on concepts of loose coupling and high cohesion.
10.3 Design Process

In the previous section, we discussed about software design and its
concepts. In this section, we will briefly discuss about the design process
and the process guidelines that help us to achieve a good design.
We can define software design as a repetitive (continuously changing)
process through which requirements are recognised and noted down, to
develop the software which is also called as blueprint. We know that
software design is a repetitive process, and in that process the requirements
are recognised and noted down. All these requirements that are noted down
together constitute the blueprint, which is used to develop the software.
Note that the blueprint illustrates a basic overall view of the software. As
design changes occur, subsequent changes (development) lead to design
representations at much lower levels of abstraction.
We should establish technical criteria for good design of the software and
the methods for evaluating the quality of a design representation. The
software design process encourages good design through the application of
fundamental design principles, systematic methodology and thorough
review. Let us have a look at the guidelines followed for good design.
A good design should:
Illustrate the architectural structure that has been developed using clear
and understandable design patterns. These design patterns are
composed of components that display good design characteristics, and
can be implemented in an evolutionary method. This will make
implementation and testing easy.
Be modular, that is, the software should be logically divided into

components that perform particular functions and sub-functions.
Include unique illustrations of data, architecture and modules.
Direct to data structures that are relevant for objects to be implemented

and are taken from specific data patterns. Address data structures that
B1965
Page No. 193
Unit 10
are appropriate for objects to be implemented. The data structures are

derived from specific data patterns.
Direct to elements that show independent functional characteristics.
Direct to interfaces that decrease the complexity of connections

between elements and with external environment.
Be derived using a recurring process which is taken by the information

that was obtained during software requirement analysis.
10.3.1 Stellar software design process

As we are studying the design process of software engineering, let us now
study the 12-step program that is followed to get the organisations back on
track, that is, to make them understand why their software didnt perform as
expected or why the users make errors unexpectedly:
1. Admit that there is a problem This is the first step in stellar software
design process. This step talks about the program. It is not always
possible to develop good usability program. It is preferable to carry out
informal customer interviews and to team up with technical support
staff. The designer should always think like the user.
2. Believe in a power greater than the designers power This is the
second step of the design process. This step is used to find out the
end-users the people who will use the final product. Sometimes, it so
happens that the actual end-users do not turn out to be from a
particular group for whom the design was originally developed.
3. A decision to be made to identify good design This is the third
step of the stellar software design process. This step talks about the
design. Design is not just what it looks like and feels like; design is how
it works.
4. To search and invent users experience shortcomings This is the
fourth step in the stellar software design process. This step talks about
how the design can be explained. We can use illustrations to explain
the design.
5. Admit to someone else (other than designers) the nature of
problems This is the fifth step of the design process. This step talks
about how the designer should think. The designers should talk as an
B1965
Page No. 194
Unit 10
equal to users more than getting feedbacks from the users. This helps
to sort out many issues.
6. To be ready to solve defects of character This is the sixth step of
the design process. This step specifies how a system should be
developed. We will need to develop the system in such a way that it
can accept changes without affecting the rest of the system.
7. Take help This is the seventh step of the design process. This step
talks about how designers should take help. It is always preferable to
ask for help from related people or other sources. There is no rule that
one has to only listen to the feedback given after reviewing. The
developers can take an extra step by their own.
8. Prepare a list of all the users who have been affected and then
their lives can be made better This is the eighth step of the design
process. This step specifies how to handle the issues. We can take this
step to scale from functional to reliable, then from usable to convenient
and finally agreeable to meaningful. The developer should be able to
assess where he has failed. This step is extremely difficult.
9. Make direct damages This is the ninth step of the design process.
This step talks about how a designer should act when sufficient
feedback is not obtained. It is difficult to get feedback from users. If
unable to deliver an improvement, it is better to prepare for the worst.
Always make failures consciously and undertake testing.
10. Continue the inventory This is the tenth step of the design process.
This step talks about the prior tasks of design. Usability testing is not a
one-time event but it is a cycle. Always observe, analyse and then
design.
11. Realise that without users, it does not matter This is the 11th step
of the design process. This step specifies how the attitude of
developers should be. Usability testing is not only important for users
but also equally important for the developers, as it is continuously
improved by developers.
12. Pay it forward This is the 12th step of the design process. A number
of resources are present in the software community for offer various
courses that can be learned.
B1965
Page No. 195
Unit 10
4. The software design process does not encourage good design through
the application of fundamental design principles, systematic
methodology and thorough review. (True/False)
5. ________ is the first step in stellar software design process.
6. The blueprint illustrates a basic _________ view of the software.
10.4 Design Fundamentals

We are now familiar with design concepts and process. We will continue our
discussion with the study of design fundamentals for developing a design
correctly.
The fundamental concepts of software design provide guidelines to get the
design right. Let us have a quick overview of the design fundamentals.
Abstraction In abstraction, the issues related to the design are
described using the levels of details/language. In software designing, we
use two types of abstraction:
o Data abstraction The representation of the data objects is called
data abstraction. In data abstraction, data objects are represented.
o Procedural abstraction The representation of instructions or
procedures is called procedural abstraction. In procedural
abstraction, instructions are represented.
Refinement - In refinement, we polish the design using top-down

strategy called as stepwise refinement. We begin with the highest level
of detail, and refine every step into detailed instructions.
Modularity In modularity, we divide the software into separate

components called modules. These modules are solved separately and
then integrated into the complete system.
Software architecture Software architecture describes the

hierarchical structure of procedural components and the structure of
data. We transform the analysis model into the design model.
Control hierarchy We can refer to it as Program structure. In the

control hierarchy, we organise the elements, which implies that we
describe a hierarchy of control, the metrics depth, width, and so on,
and provide visibility and connectivity.
B1965
Page No. 196
Unit 10
Data structure In data structure, we illustrate the links between

individual data elements using logical representations. It presents scalar,
sequential vector, array, linked list and hierarchical data structure.
Software procedure It specifies processing details of each element. It

provides precise specifications on sequence of events, decision points,
repetitive operations and data organisation.
Information hiding In information hiding, the elements should be

categorised by design decisions, and each element is hidden from all
the other elements. The elements are designed in a manner that the
information within an element is not accessible to other elements. This
defines and implements access restrictions.
10.4.1 Principles of design

We will now learn about the seven principles of design.
First Principle: The reason of its presence.
One reason for a software system to be present is to give value to its users.
We should keep this in mind while making all judgements. Prior to
specifying system requirements, system functionality, determining hardware
platforms or development processes, we should know the answer to the
question does this add real value to the system? If the answer is no, then
there is no point in doing it.
Second Principle: KISS Keep it simple, Stupid!
Software design is not a random process. In any design, we should consider
many factors. All the designs should be simple but not simpler. This helps to
have a system that can be easily understood and maintained. All the
elegant systems are simple in nature when observed. Simple design
consumes a lot of thought and work over several repetitions to simplify.
Consequently, it results in software which is more maintainable and less
vulnerable to error.
Third Principle: Maintain the vision.
A clear vision of the software is necessary to gain success in any software
project. If the vision towards the software is not clear then the project ends
up with low quality. If the project lacks conceptual integrity, it results in a
system which is a patchwork of incompatible designs held together
by wrong kind of connections. Conceptual integrity is one of the most
important considerations in the system design. Architectural vision of the
B1965
Page No. 197
Unit 10
software system is also important. If the architectural vision is weak then the
system fails though it is well designed. If the architect has a clear vision of
the software and implements compliance then the project becomes
successful.
Fourth Principle: What is produced will be consumed/used by
others.
According to this principle, a product developed is used, maintained and
documented by the users/clients, to understand the system. A product
should be developed such that the user should understand the
specifications,
design and
implementation.
Always
keep the
implementations in mind while designing. The code should be written with
concern for the individuals who maintain and extend the system. The code
developed is tested and debugged by the testers. If the work of testers is
made easier then further value is added to the system.
Fifth Principle: Be open to the future.
As per this principle, the system has more value if it has extensive lifetime.
In the present generation computing environments, the specifications of
hardware and software change rapidly and become outdated very fast. The
lifetime of software is measured in months. However, software that is truly
and industrially strong should last longer. To achieve that kind of system,
the system should be able to adapt to all changes. Systems that adapt
successfully are those that have been designed from the beginning to get
adapted easily. The systems should be created such that they solve all the
problems not just a particular problem. This results in a system that can be
reused entirely.
Sixth Principle: Plan in advance for reuse.
According to this principle, time and effort can be saved by reusing the
developed software. The reuse of programs and designs has been made
possible due to the use of object-oriented technologies. Various methods to
realise reuse at every phase of the system development process are
available. Communicating about the scope of reuse to others in the
organisation is vital. This principle also states that planning ahead for reuse
decreases the cost and increases the value of both the reusable elements
and the systems into which they are incorporated.
B1965
Page No. 198
Unit 10
Seventh Principle: Think.

As per this principle, placing clear, complete thought before action produces
better results. If the thought is right, then the action will also be right. We
can gain knowledge about how to do it again. Thinking helps us individuals
to learn how to identify solutions in a situation where the individual is
ignorant about something. He can thus find out the answer to that question.
The value of a system increases automatically when clear thought is applied
to it.
7. A clear vision of the software is necessary to gain success in any
software project. (True/False)
8. As per the _______ principle, the system has more value if it has
extensive lifetime.
9. A clear _______ of the software is necessary to gain success in any
software project.
Activity 1:
Create a flow chart for the principles followed for designing a software in
your company.
(Hint: Design Principles.)
10.5 Modular Design

As we are now familiar with software design, design concepts, its process
and fundamentals, let us discuss about modular design.
We can define a modular design as the design of any system made up of
separate modules that can be linked together. Modular design facilitates the
replacement or addition of any module without affecting the remaining
system. We can apply modular design to the hardware and software. It
refers to a design strategy in which a system is made up of comparatively
small and independent routines that fit together.
Let us study the criteria that help to evaluate a design method with
reference to its capability to define effective modular system1:
Meyer [MEY88]
B1965
Page No. 199
Unit 10
Decomposability An effective modular solution of decomposability is

achieved when a design method gives a systematic mechanism for
decomposing the problem into sub-problems. This reduces complexity
of the overall problem of the design.
Understandability If a module/component can be clearly understood

as an individual unit without any reference to other modules, it will result
in a module that is easy to develop and easy to modify.
Continuity If changes in the individual modules occur due to small

changes in the system requirements, rather than system-wide changes.
The effects of change due to the side effects will be decreased and will
be restricted to that module.
Composability We can achieve the modular composability as a result

of assembling of existing design components into a new system.
Protection The effect of error-induced side effects are reduced

whenever an unusual condition occurs within a module and the effects
are restricted within that module.
10.5.1 Advantages and Disadvantages

Now that we have learnt about modular design, let us study about the
advantages and disadvantages of modular design.
The advantages of modular design are as follows:
Stabilised design of modular element decreases the development of the
final product.
A significant range of products can be developed.
The designs can be brought out to market very quickly.
The designs are very flexible in nature.
The designs provide easy service; faults can be easily identified and can
be replaced.
Significant range of product.
High speed-to-market.
Significant flexibility in design.
Easy service, identification of fault and replacements.
Simplified material planning, less inventory due to easily available
modular sub-assemblies.
B1965
Page No. 200
Unit 10
Less paper work in record, as there is no need to maintain the records

of parts used in the modular sub-assemblies.
The disadvantages of modular design are as follows:

Development cost is more while making modules that can be reused in
other efforts.
For hardware, the product cost can increase whenever interconnects
between different modules increase.
The development cost and time are higher if modular libraries are being
developed as part of the development effort.
For hardware, interconnections between different modules as
subsystem often act as limits for overall performance of hardware.
The interfaces between different modules are frequently common
causes of failure.
10. A __________ design is the design of any system made up of separate
modules that can be linked together.
11. If modular libraries are being developed as a part of the development
effort, the development cost and time are higher. (True/False)
12. High speed-to-market is an advantage of ________.
10.6 Data Design

Till now, we have familiarised ourselves with software design, design
concepts, its process and fundamentals. Let us now learn about data
design.
Data design recognises the program elements that function on logical data
structures. The benefit of data design is that, it specifies good program
structure, effective modularity and decreased complexity. Let us briefly
mention the data specification principles.
Apply functional analysis principles to data.
Classify all data structures and associated operations.
Create a data glossary to describe data and program design.
Defer low-level data design decisions.
Illustration of data structure should only be known to elements with

direct use of data within the structure.
B1965
Page No. 201
Unit 10
Build up a library of useful data structures.

Language should support conceptual data types.
13. Data design recognises the program elements that function on
_______ data structures.
14. One of the data specification principles is to create a ___________ to
describe data and program design.
15. ________ should support conceptual data types is another data
specification principle.
10.7 Architectural Design

Having studied about data design in the previous section, let us now study
the architectural design.
The architectural design describes the link between major structural
elements of the software. The aim of architectural design is to develop a
modular program structure and depict the control association between
elements. It combines program and data structure by describing interfaces,
which allows data to flow throughout the program. It is known to be the
holistic view of the software.
We will now briefly describe the characteristics of architecture.
Performance The benefits of architectural design are the localisation
of critical operations and reduction in communication. Instead of using
fine components, this design uses large components.
Safety All the safety critical features are localised in small
subsystems.
Maintainability This design uses fine and replaceable elements.
Security This design is a layered architecture with critical properties in
its interior layers.
Availability The redundant elements and mechanisms for tolerance of
fault are available in the system.
We can refer to software architecture as a software systems blueprint which
illustrates its components, interactions between components and their
interconnections, informal descriptions including boxes and lines, and
informal prose (ordinary and understandable language), and a shared,
B1965
Page No. 202
Unit 10
semantically rich vocabulary consisting of remote procedure calls, client

server, layered, object oriented, and so on.
10.7.1 Advantages of architectural design
Like other designs, architectural design also has some advantages. Let us
study the advantages of architectural design:
The development philosophy is component based.
This design saves cost of architecture.
It is an explicit system structure.
This design provides a framework for fulfilling requirements of the
software design.
It can be effectively reused.
It provides technical basis for design.
It avoids architectural erosion.
The structure and interaction details outdo the decision of algorithms
and data structures in large or complex systems.
During the design process, we can develop various architectural models.
Each model consists of different perspectives on the architecture. Let us
briefly discuss these perspectives:
Dynamic process model This represents the process structure of the
system.
Static structural model This indicates all the important system
components.
Deployment model This represents the link between system
elements and hosts.
Interface model The subsystem interfaces are defined here.
16. ______ design recognises the program elements that function on
logical data structures.
17. The architectural design describes the link between ____ of the
software.
18. Software architecture can be referred to software systems blueprint.
(True/False)
B1965
Page No. 203
Unit 10
Activity 2:
Client-server is a popular distributed architecture. Server modules offer
services to client modules, and clients and servers exist on different
machines. An example would be a railway reservation system where
the booking clerk can view details that are essentially stored in the
server.
You are required to identify at least three other areas where client-server
can be observed.
(Hint: Client-server architecture.section No. 10.8 )
10.8 Procedural Design

In the previous section we studied about architectural design. Let us now
study about procedural design of software.
After data design, system architecture and interface design, procedural
design starts. It is essential for us to specify procedural detail after data and
program structure have been developed without uncertainty. The goals of
procedural design are as follows:
Least effort to complete the task.
Less number of statements to achieve the goal.
Reduced usage of resource so that the cost of resource is reduced.
High transparency.
Maximum output precision is achieved.
We can adopt the following methods for achieving the goals:
Coding, top-down and bottom-up In top-down coding approach, the

main module is programmed and implemented, and proceeds to lower
level in the hierarchy. In the bottom-up coding approach, the
programming begins at lowest level and moves up.
Structured programming The structure of design function and design

behaviour is provided in structured programming.
Use of information hiding principle If there is a change in the

structure or process, it is easy to maintain by using this principle.
Programming style Each individual has a style of coding. But one

has to follow certain standard rules while coding.
B1965
Page No. 204
Unit 10
Internal documentation within the program The entire process is

recorded in the documentation to help the developers and users
understand the process. For example, the document includes
functionality, roles and usage of parameters, characteristics of input, and
so on. The documentation should also include referential data such as
recent modified date, author of the program, and so on. The details
given in the documentation will facilitate modifications.
19. In bottom-up coding approach, the main module is programmed and
implemented, and goes to lower level in the hierarchy. (True/False)
20. All the process is recorded in the _______________ to help the
developers and users understand the process.
21. The _______ principle makes it easy to maintain if there is a change in
the structure or process.
10.9 Design Documentation

In previous sections, we discussed about various kinds of design methods.
Now let us now study about an important aspect of software design, Design
Documentation.
In general, the design document enables people to review the design and
improve it. It contains all the design decisions along with the reasoning. The
design process results in design documentation. The design documentation
explains the following.
Necessities used to guide the design process.
What system or part of the system this design document describes.
Explains the important problems that had to be solved.
The likely substitutes that were considered.
The final decision and the rationale for the decision.
Assures traceability by providing reference to the requirements that are
being implemented by this design.
Advises a designer to be clear and to consider the important issues
before starting implementation.
Now we will see the inclusions in typical design documentations, namely:
A pictorial representation of the design. The diagram helps the reader to
quickly get a basic idea of the design.
B1965
Page No. 205
Unit 10
The information its readers need to learn.

The rationale for the design which allows the reader to understand the
design better, helps reviewers to determine whether good decisions
were made, and helps the maintenance team determine how to change
the design.
We can define the design document as a kind of document that provides

reference to the requirements being implemented by this design. We should
write the design document for those who:
Will implement the design such as programmers.
Will need to modify the design in future.
Need to create systems or subsystems that interface with the system
being designed.
The design specification provides various concepts of design model and the
software representation of the designer. It describes the scope of design
effort. Description of database structure, external file structures, internal
data structures and cross references that connect data objects to specific
files are contained in it.
The architectural design shows that the program architecture is derived from
analysis model, and to indicate module hierarchy, structure charts are used.
The external and internal program interface designs are indicated and
humanmachine interface is described in detail. A GUI prototype is provided
wherever required.
Separate elements of software such as subroutines, functions, procedures
and others are described in narrative style. This narration describes the
procedural function of a module. We use the procedural design tool for
converting the procedural function into a structured description.
The design specification consists of cross reference. The use of cross
reference is to ascertain that all needs have been fulfilled by software
design, and to show which components are essential to the implementation
of specific requirements.
The initial step on the development of test documentation is also present is
the design document. After developing the program structure and interfaces,
guidelines for testing each module separately and the integration of the
complete entity can be developed.
B1965
Page No. 206
Unit 10
Design restrictions like physical memory limitations or requirement for a

particular external interface may dictate special requirements for assembling
or packaging of software. Special reflections caused by the need for
program overlay, virtual memory management, high-speed processing and
other factors may cause change in design derived from information flow or
structure. This also explains the approach we will need to use in order to
move software to a customer site.
The last part of the design documentation includes additional data. It
includes algorithm explanations, alternative procedures, data, results,
extracts from other documents, and other information as a note or separate
appendix. The preliminary operations or the installation manual can be
included in appendix of the design document.
10.9.1 Guidelines for improving design documentation
We know that the key to success of design documentation are good
organisation and clear writing. So, we should follow the below-mentioned
guidelines for improving the documentation:
1. Know the audience
The needs of the audience should be addressed by writing effective design
documentation. Before starting the documentation, the author should find
out what the audience wants and who the audience is.
The author should know how the audience is likely to use the
documentation and which the times it will be used. It is important to know
the language of the audience including the kinds of references they use and
in which manner. The medium of documentation in terms of suitability
should be decided whether hard copy paper documents, presentations or
other media. The document should integrate into the audiences culture but
should not disrupt it.
The author can start writing as soon as all the above criteria are known. In
the due course of writing, it is better to double check to ensure that the
writing is on track and that it will provide the audience with what they
require.
2. Narrate
The aim of the design documentation in the early stages of a project is to
educate its users about the value of the design and make them understand
B1965
Page No. 207
Unit 10
that the product is worth constructing and producing. To facilitate this, we

must narrate the concepts like a story. Narration is done using characters,
scenarios and walk-throughs.
3. Describe the foundation and inferences of the design
While documenting a design, it is not enough to explain the working of
product and how it looks; we should also explain the basis on which the
design was developed wherever feasible.
We must support the design decision or solution by understanding how it
serves the needs of users. We must also describe in detail how each
decision will facilitate the user requirement fulfil the user goal. While
providing the justifications for the decision made, we must answer the users
questions. We must be able to explain the design in terms of business
requirements. Design principles can be used to back up interface
behaviours to assure the programmers that their code is sensible.
4. Follow standard format
The layout of the document should be well organised. If the contents are not
readable though they are good, the effort goes waste. The format should be
visually clear and consistent in all pages. This is an important aspect of
documentation. To get started, templates that provide consistent page
layout grid can be obtained by applications such as InDesign, Adobe
FrameMaker and others.
5. Use active voice, present tense
The design documentation specifies about a product; the tone of writing
should convey what the product is. When the sentences are written with
conviction, the confidence and belief in the design is high and the same is
carried to the users and makes the design influential to the audience and
vice versa.
6. Review
After the documentation, the draft has to be reviewed and edited. The editor
should be familiar with the design and project. The editor can be a colleague
or a member of the development team.
Both the writer and the editor should analyse whether the design has been
correctly described, whether the key points have been covered, whether the
important technical implications have been addressed, and so on. A regular
B1965
Page No. 208
Unit 10
meeting with the editor is necessary. It becomes easier to deal with issues
when they occur during the early drafts. The main aim of editing is to get the
best design developed and reach the audience.
22. ______________ is the final outcome of the design process.
23. After the documentation, the draft need not be reviewed and edited.
(True/False)
24. The needs of the audience should be addressed by writing _______
design documentation.
10.10 Summary
Software design is the technical core of software engineering.
Continuous refinement of data structure, architecture, interfaces and

procedural detail of software elements are developed, reviewed and
documented during the design phase.
The results of design in the form of software can be measured for

quality.
Design principles help the software engineer as the design process

progresses. The basic criteria for design quality are provided by design
concepts.
Four types of design methods are important modular design, data

design, architectural design and procedural design.
Architectural and procedural designs have several advantages and

some disadvantages as well.
Design documentation is produced at the end of the design process.
Design documentation helps the user and developer to understand the

process holistically. Reviewers review the document and necessary
changes are incorporated.
Certain procedures exist for ensuring writing a good documentation; it

makes sense to adopt such procedures.
10.11 Glossary
Adobe FrameMaker: It is an application for desktop publishing and help
authoring. This is published by Adobe Systems.
B1965
Page No. 209
Unit 10
Architectural erosion: Architectural erosion is a phenomenon where the

initial architecture of an application is altered to such a point where its basic
properties no longer exist.
Design pattern: Design pattern is a generally a repeatable solution to a
commonly arising problem.
Explicit system structure: A clear structure of the system is established.
This kind of system avoids confusions.
InDesign: This application is used to create posters, brochures, flyers,
books and magazines. This is published by Adobe Systems.
Interface design: It is a process of establishing the structure and work flow
for a user interface in software engineering.
Module: Module is an individual unit of hardware or software.

1.
2.
3.
4.
5.
6.
7.
8.
What is a software design?

Briefly explain the design process.
Briefly explain the design fundamentals.
What is a modular design?
What is a data design?
Explain architectural design in detail.
Explain procedural design in detail.
Describe design documentation.
10.13 Answers
1. Dependency inversion principle
2. True
3. Orthogonal code
4. False
5. Admit that there is a problem
6. Overall
7. True
8. Fifth
9. Vision
10. Modular
B1965
Page No. 210
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
Unit 10
True
Modular design
Logical
Data glossary
Language
Data design
Major structural elements
True
False
Documentation
Use of information hiding
Design Documentation
False
Effective
Terminal Questions
10.14 Case Study

An Example Showing the Essentiality of a Software System
Movie World is a Delhi-based company in DVD rental business. It has 4,000
DVD titles covering all subjects and languages. Each title is originally
bought in 612 numbers depending upon its rating in the entertaining field.
The company has 14 branch libraries spread over the city. It is the policy of
the companys management to add over 150 titles every year, based on
reviews and feedback from the market.
The terms and conditions of the company are the following: Membership
subscription of Rs.4,500 per annum per head; if a member borrows a DVD
then the member has to pay Rs. 80 with the condition that the DVD is
B1965
Page No. 211
Unit 10
returned within 36 hours. The company has more than 8,000 members. The
business operations are as follows.
1. A person pays Rs.4,500 for 1 year and receives membership card after
filling in the form.
2. When a member wants a DVD, the member visits the branch and
requests for their choice. If it is available, it is given. If it is not present
then the member has to fill the reservation slip. The branch manager
handles all these situations.
3. If the DVD is collected and returned within 36 hours, an extra charge of
Rs.15 per hour is collected, before the next DVD is issued to the
member.
The method of returning the DVD is the member has to drop the DVD in a
drop box with the return coupon filled, which includes the membership
number, time of return and date. The staff regularly checks the drop box and
places back the DVD in its shelf. All titles are bar coded with complete data
about the DVD and main attributes such as language, rating and others.
The companys policy is to scrap the DVD if it is issued more than 60 times,
and new purchase of the DVD is automatically made. The basic systems of
registration, accounting, billing and recovery are functioning well. The
systems are independent. The systems are not integrated and decisions are
made based on summary of month end issued by individual system head.
Every branch has five desktops and a data server to meet transaction
processing and accounting. The management wants to take up the following
actions to improve the revenue.
1. Service to member is quicker and effective.
2. Titles are present when asked by the member.
3. The member should be able to select the title, check its availability and
make a request for home delivery.
4. Reservation system to book the title.
5. Improved accounting and analysis system should be set up for recovery
of membership fees, overdue, extra charges and others.
6. The company wants all the branches to be networked to facilitate
quicker movement of DVDs and for members to get their choice of titles
in less duration.
B1965
Page No. 212
Unit 10
1. Analyse the problems of the company.
2. Develop a software system solution to overcome the issues.
http://www.computerworld.com/s/article/9049262/12_steps_to_stellar_s
oftware_design (Retrieved on 15th May 2012)
http://www.cc.gatech.edu/classes/AY2000/cs3802_fall/Lecture6/index.ht
m (Retrieved on 15th May 2012)
http://www.c2.com/cgi/wiki?SevenPrinciplesOfSoftwareDevelopment
(Retrieved on 15th May 2012)
B1965
Page No. 213
Unit 11
Unit 11
Software Testing Techniques and

Technical Metrics
Structure:
11.1 Introduction
Objectives
11.2 Software Testing Fundamentals
Testing objectives
Test information flow
Test case design
11.3 White Box Testing
11.4 Control Structure Testing
11.5 Black Box Testing
11.6 Testing Real-Time Systems
11.7 Automated Testing Tools
11.8 Summary
11.9 Glossary
11.11 Answers
11.12 Case Study
11.1 Introduction
In the previous unit, we discussed about software design and its aspects,
the design process and fundamental and different design methods such as
modular design, data design, architectural design and procedural design.
We also analysed the design documentation and learnt some guidelines to
follow while preparing the design documentation.
In this unit, we will discuss about software testing fundamentals and its
objectives. We will analyse the process of test information flow and case
design. We will also discuss various testing methods such as white box
testing, black box testing and control structure testing. We will also discuss
briefly about various methods of testing real-time systems and various kinds
of automated testing tools.
This unit will enable us to use an appropriate method for software testing,
and the manner in which that particular method will help us in conducting
successful testing.
B1965
Page No. 214
Unit 11
Objectives:
describe software testing fundamentals
elaborate white box testing
explain black box testing
briefly discuss about control structure testing
describe the testing of real-time system
list out the automated testing tools
11.2 Software Testing Fundamentals

Let us start our discussion on software testing fundamentals by defining
software testing.
We can define software testing as the activity that aims at evaluating the
capability of a program or system. It finds out whether the program meets
the required results or not. It also identifies errors in the coding of the
application that have to be eventually fixed.
11.2.1 Testing objectives
Let us briefly describe the objectives of software testing.
Quality assurance The effects of bugs are very severe, especially in

critical software systems like the ones pertaining to avionics, health
care, and so on. Bugs or errors cause huge losses and disasters,
sometimes catastrophic. Some examples of bugs that have caused
major disasters are aircraft navigation failure resulting in mid-air collision
(e.g. the mid-air collision over Charkhi Dadri village in Haryana in 1996,
when two airplanes crashed into each other), stoppage of stock market
trading, and so on. The quality of software is a vital aspect in the
modern, computerised world, where our lives have been taken over
completely by computers. Quality is conformation to the specified design
requirement. Debugging is conducted to find out defects in design
developed by the programmers. It is not so easy for a developer to
develop a program that is error free. We ensure good quality by finding
the problems and fixing them by adopting a process called debugging.
Reliability estimation We can associate many aspects of software

including structure, and the amount of testing it has been subjected to,
with software reliability. Testing serves as a statistical sampling method
B1965
Page No. 215
Unit 11
to obtain failure data for reliability estimation based on operational

profile. Software testing is expensive, but the software used for testing is
more expensive. It is not easy to solve software testing problems. We
can never be sure that the software is correct and also the
specifications. There is no verification system that can verify each and
every correct program. And we can never be certain that a verification
system is correct.
Verification and validation We cannot test quality directly; so we test

related factors to make quality visible. Quality consists of certain factors.
Good testing evaluates all relevant factors. For the testing to be
effective, it should evaluate each relevant factor and thus compel quality
to become substantial and visible. Tests that aim at validating the
product are called clean tests or positive tests. A contrary method of
testing is negative tests, which aim at breaking the software or
showing that the program does not work. The software should have a
good number of handling capabilities in order to emerge victorious for a
significant level of negative tests.
11.2.2 Test information flow

As we have now become familiar with the term software testing and its
objectives, let us briefly discuss about the flow of test information. Test
information flow is an arrangement to check and maintain the right flow of
information during software testing.
In Figure 11.1, we feed the software and test configuration specifications to
the testing block that generates test results. Then, these test results are fed
into the evaluation block, along with the expected results and error rate
data. The expected results and the test results are compared and errors are
generated. These errors are then fed into the debug block. The debug block
corrects the errors and produces corrected results.
Let us see a typical test information flow shown in Figure 11.1.
B1965
Page No. 216
Unit 11
Expected results
Software configuration
Test
results
Testing
Evaluation
Errors
Debug
Corrections
Test configuration
Error rate
data
Reliability
Model
Predicted reliability
Fig. 11.1: Representation of Test Information Flow
11.2.3 Test case design

We will now study about a very important aspect called test case design.
We can define test case as a test that is designed to validate a case outline.
We define the process of testing, units to be tested and tools used during
different levels of testing in the test plan. The test cases are designed on the
basis of the method specified in the test plan, and the characters to be
tested. Let us see a test case design specification in Table 11.1.
Table 11.1: Example of Test Case Specifications
Requirement
number
Condition to be
tested
Test data and

settings
Likely output
We can add extra columns if necessary, such as an extra column to note

the result of different rounds of testing. Test case design is an important
activity in the testing process. We should select the test cases carefully for
proper testing, which will fulfil the required criteria and approach specified. A
test case design has the following benefits:
To assure that the set of test cases used is of good quality.
The entire testing of the unit and the effect of total set of test cases is
visible to the testers.
The test cases are optimised, as evaluation of test set might indicate
that few test cases are redundant.
B1965
Page No. 217
Unit 11
A design is said to be testable if we can validate and maintain it easily.

Testability is an important design rule for software development though
testing needs significant effort, time and cost. We can say that a test case is
good if it has a high possibility of finding the undiscovered error. Also, a test
is said to be successful if it discloses undiscovered error.
From the above discussion, we can conclude that the objective of test case
design is to find out errors in a program.
1. It is not easy for a developer to develop a program which is ______
______.
2. Test information flow is an ____________ to check and maintain the
right flow of information during software testing.
3. A design is said to be _________, if we can validate and maintain it
easily.
4. The objective of test case designs is to find out errors in a _______.
11.3 White Box Testing

In the previous section, we studied about software testing fundamentals. In
this section, we will study about a testing method called white box testing.
We can define white box testing as a kind of testing where the test groups
should have complete knowledge of the internal structure of the software.
White box testing is also called structural testing (and sometimes glass-box
testing). Structural testing is based on testing where the tests are derived
from knowledge of the softwares structure and implementation. We can
apply structural testing to small program units like subroutines, operations
related to objects, and so on. The tester analyses the program and uses the
knowledge about the structure of a component to get test data in this
method of testing. The number of test cases required to assure that all
statements in the program are executed at least once during the testing
process can be found out by analysing the code. It is important to note that
boundary conditions should be tested in white box testing for example, in
a for loop where the loop returns 20 times, we will need to execute the
program for the 19th and 20th loops. The white box testing is carried out on
the basis of knowledge of how the system is implemented. White box testing
needs access to the source code. However, white box testing can be done
B1965
Page No. 218
Unit 11
any time after the code is developed; it is a good practice to carry out the
test during the unit testing phase. White box testing is carried out to:
Validate code whether the code implementation follows intended design.
Validate applied security functionality.
Discover usable vulnerabilities.
Let us understand the requirements of white box testing now.
The basic requirement is to comprehend and analyse available design
documentation, source code and other related development artefacts.
The tester should think like an attacker for creation of tests and ensure
that he breaks apart the code in order to identify uncovered errors.
The testers should know the various tools and techniques present for
white box testing, so that they can perform testing effectively.
We will now briefly discuss the white box testing process shown in Figure
11.2.
Inputs
Activities
Outputs
Fig. 11.2: Process of White Box Testing
As per Figure 11.2, white box testing process includes three components.
Inputs The inputs to the white box testing include:
o
Source code Access to the source code is an important

requirement to carry out white box testing.
Design documentation We require this to enhance program

understanding and to establish effective test cases that evaluate
design decisions and assumptions. If the design document is not
available or insufficient, the test team should have direct access to
the design team for extensive question and answer sessions.
B1965
Page No. 219
Unit 11
Architectural and design risk analysis report This includes the

test plans, test case creation, test data selection, test technique
selection and test exit criteria selection. If risk analysis is incomplete
for the system, this should be the first task performed as a part of
white box testing.
Security specifications Security specifications are required to

understand and validate the security functionality of the software
which is under test. If the security specifications are not sufficient,
the test team should get this information from stakeholders, design
team and business owner of the software.
Security testers documentation The testers should have access

to quality assurance documentation to understand the softwares
quality with respect to its planned functionality. Test strategy, test
plans and error reports should be included in quality assurance
documentation.
Activities The second component, namely, activities include:

o
Risk analysis The white box testing is based on architecture and

design level risk analysis. White box testing should use a risk-based
approach, both in the systems implementation and the attackers
frame of mind and abilities.
Test strategy This is the first step developed on the basis of risk
analysis in planning white box testing. The test strategy is developed
to clarify major activities involved, key decisions made and
challenges faced in the testing effort.
Test plan The aim of the test plan is to organise the subsequent
testing process. The test plan includes test areas covered, test
technique implementation, test case and data selection, test cycles,
test results validation and others.
Test case development The test case details include

preconditions, generic or specified test inputs, expected results and
steps to execute the test. The aim of the test case is to note what the
specific test is designed to achieve. Risk analysis, test strategy and
test plan should monitor test case development.
Test automation They offer automated support for the process of

managing and executing tests, particularly for iterating past tests.
B1965
Page No. 220
Unit 11
White box testing needs software development to support executing

specific tests.
Test environment It is very important to establish and manage a

proper test environment. The test environment consists of computers
for basic applications and it can become very complex for enterprise
level software systems.
Test execution In test execution, the first step is to validate the

infrastructure required for running tests in the first place. This
infrastructure primarily involves the test environment and test
automation, and also stubs that may be required to run individual
components, artificial data used for testing databases that the
software need to run and other applications that interact with the
software.
Testing techniques and tools Various tools and techniques are

used to conduct the white box testing. The techniques are used to
understand the program and develop test cases and analyse other
features of the code. The tools are used to check the source code to
detect errors efficiently.
Outputs The aim of testing is to ensure that the software that is

undergoing testing meets the security goals of the system and is
capable of thwarting unwanted attacks. Various kinds of errors are
discovered during white box testing and are very context sensitive to the
software under test.
Let us look at some common errors discovered during testing.

Sensitive data being visible to unauthorised users.
Data inputs compromising security restrictions.
Design flaws not appearing to have emanated from the design
specification.
Inappropriate control flow compromising security.
Inappropriate implementation of security functionality.
Boundary constraints not appearing at the interface level.
White box testing improves overall test effectiveness and test coverage. It
enhances productivity in discovering bugs that are difficult to identify.
B1965
Page No. 221
Unit 11
Basis path testing

Let us now discuss basis path testing which is used for devising a white box
test case.
Basis path testing is a method for assuring that all independent paths
through a code module have been tested at least once. Any path through
the code that establishes at least one new set of processing statements or a
new condition is called an independent path. Basis path testing offers a
minimum, lesser bound on the number of test cases that need to be written.
The test paths in a basis set (a set of linearly independent paths that are
used to create any path through the program flow graph) fulfil the
requirements of branch testing and test all the paths that can be used to
create random path through the graph.
Let us see the four steps of basis path testing:1
1. The first step is to compute the program graph.
2. The second step is to calculate the cyclomatic complexity.
3. The third step is to select a basis set of paths.
4. The fourth step is to generate test cases for each of these paths.
We can depict any function as a control flow graph in a program. The
program statements are the nodes shown in the graph, and the flow of
control is the directed edges. We may connect two nodes by an edge in
either direction or by an edge in each direction. When we trace a path from
supply to destination, the edge leads back to a node that has already been
visited. We can call this as back-edge. A control flow graph contains one
supply node and one destination node. A supply/source node is a node that
has no incoming edges. A destination/sink node is a node with no outgoing
edges. Sometimes, a program may have more than one destination.
Let us see a simple control flow graph in Figure 11.3.
McCabe
B1965
Page No. 222
Unit 11
Source/Supply
a
Sink/Destination
Fig. 11.3: Control Flow Graph
In Figure 11.3, we see four edges: a, b, c and d. We represent the path bd

by the vector [0 1 0 1], and then combine the paths by adding or subtracting
the paths vector representations. We cannot form every path in the basis
set as a combination of other paths in the basis set, but can form any path
through control flow graph as a combination of paths in the basis set.
The complete flow graph does not have two edges going to the same sink.
A basis set for the figure is {ac, ad, bc}. The path bd may be constructed by
the combination bc + ad ac as shown in Table 11.2.
Table 11.2: Calculation of Path
Edge
bd
bc
bc + ad
bc + ad
ac
{ac, bd} is not a basis set, as there is no way to construct the path ad. The
set {ac, ad, bd} is basis set. Basis sets are not unique, and hence a flow
graph can have more than one basis set.
We can consider the decisions as independent in the basis path method. If
the decision is taken at the source node, it is irrespective of the impact
taken on a node further down the graph.
B1965
Page No. 223
Unit 11
5. Structured testing is applicable to large program. (True/False)
6. Test strategy is a management activity. (True/False)
7. The first step in basis path testing is to compute _____.
11.4 Control Structure Testing

As we are now familiar with the method white box testing, we will study
about a component of white box testing called control structure testing.
Control structure testing helps us to broaden the testing coverage area and
improve the quality of white box testing. Let us study about the methods of
control structure testing.
Condition testing It is a test construction method that aims at
exercising the logical conditions in a program module. The errors in the
condition are due to various errors such as Boolean, operator, variable,
parenthesis, relational operator and arithmetic expression. In multiple
conditions testing, the testing needs all truefalse combinations of
simple conditions to be run at least once. Hence all statements,
conditions and branches are considered in this manner.
Branch testing This is also called decision testing. For every decision
each branch should be executed at least once. The decision statements
are if, for, switch and while.
Loop testing Algorithms need loops and they are required to be
thoroughly checked. There are four types of loops, which are as follows:
o Simple In simple loop, n is the maximum number of allowable
passes through the loop.
o Nested Simple loop testing is carried out here.
o Concatenated Simple loop testing is used if the loops are
independent. If the loops are dependent, they are treated as nested
loops.
o Unstructured Here, the test is not conducted but the software is
redesigned.
Data flow testing This selects the test paths according to the location
of definitions and usage of variables. This is a refined technique and is
not practical for general use. The testing should be directed to modules
with nested if and loop statements.
B1965
Page No. 224
Unit 11
8. Control structure testing helps to improve the quality of white box
testing. (True/False)
9. Branch testing handles the implicit paths that result from _______.
10. Loop testing should be directed to modules with nested if and loop
statements. (True/False)
11.5 Black Box Testing

In the previous section, we discussed about white box testing. Let us now
discuss about another testing method, namely, black box testing.
Black box testing comes under unit testing. In unit testing, the components
are tested individually to assure that they operate correctly. The black box
testing depends on the specification of the component which is being tested
to draw test cases. It has concerned about the inputs and the outputs that
are produced as a result of the test. It is a functional testing process to
validate if the unit fulfils its requirements or not. The unit is black box, and
the behaviour is determined by learning its inputs and outputs.
Black box testing checks that necessary and correct functionality has been
built into the software, the interface works correctly, data structures behind
the interface work correctly, and the behaviour and performance of the
system are within the right boundaries. It also checks that the initialisation
and termination of the program are accurate. We use requirements to verify
the right outputs of black box testing. The test cases are used to validate
that the correct software is being developed. The different forms of black
box testing are integration testing, functional testing, system testing,
acceptance testing, beta testing and regression testing.
A minimum black box test group should consist of one test case for every
requirement of the application. Equivalent partitioning, boundary value
analysis, decision tables and diabolical test cases should be further created
to optimise testing.
We will now briefly discuss some basic black box test design techniques.
Decision table testing The decision tables are a specific and
compact method to model complex logic. The decision tables are
indicated in the form of flow charts, switch case and if-then-else
statements, and associate conditions with actions to perform.
B1965
Page No. 225
Unit 11
All pairs testing We can also call it as pair-wise testing. It is a

combinatorial software testing method where we conduct the tests on all
possible different combinations of parameters, for all pairs of input
parameters to a system.
State transition tables We can define these tables as tables that
represent what state a finite semi-automation or finite state machine will
move to, based on the present state and other inputs. We can define a
state table as a truth table where current state signifies the input, and
the next state signifies the output, along with other outputs.
Equivalence partitioning It is a software testing technique that
partitions the input data of the software unit into parts of data from which
the test cases can be drawn. This technique helps to define test cases
that discover classes of errors, thus decreasing the total number of test
cases that should be developed.
Boundary value analysis It is a software testing technique where the
tests are designed to include representatives of boundary values. The
values could be either input or output limits of a software component.
Since these boundaries are common, positions for errors that effect in
software failures they are often implemented in test cases.
Activity 1:
Create a flow for black box testing in your organisation.
(Hint: Black box testing techniques.Refer section 11.5)
11. Glass-box testing is another name for _________ testing.
12. _____________ is a software testing technique that partitions the input
data of the software unit into parts of data from which the test cases
can be drawn.
13. Regression testing is a _____________ testing method.
11.6 Testing Real-Time Systems

In the previous section, we studied about black box testing; let us now learn
about testing real-time systems.
B1965
Page No. 226
Unit 11
There is a rising awareness about software engineering practice as software

is becoming more and more complex with each passing day. We require
both formal verification techniques and testing techniques for handling the
growing complexity. This is predominantly true in areas such as embedded
systems used in consumer electronics, communication protocols from
telecommunication industry and time-dependent systems happening in
mission-critical systems such as avionics, health care, banking, stock
markets, and so on.
The real-time application presents a new and potentially difficult element to
testing. The test case designer should consider white box and black box test
cases along with interrupt processing, timing of the data and other factors.
In many circumstances, when a real-time system is present in one state and
the test data is given as input it leads to proper processing. When system is
in a different state, and if the same data is given as input, it may lead to an
error. Sometimes, the link that is present between real-time software and its
hardware environment leads to testing problems.
Let us briefly describe the strategies for test case design that have evolved
for real-time systems.
Task testing This is the first step of real-time software testing. This
method is used to test each task independently. White box and black
box tests are designed and executed for every task. During these tests,
each task is executed independently, and the errors are discovered in
logic and function. The timing and behaviour are not shown in task
testing.
Behavioural testing This is the second step of real-time software
testing. The behaviour of a real-time system is simulated using system
models and it is studied as a result of external events. All these analysis
activities serve as a basis for design of test cases. It is conducted when
real-time software is being built. It this testing, the behaviour of the
system model and the executable software are compared. The
behaviour of the software is inspected to uncover behaviour errors.
Inter-task testing This is the third step of real-time software testing.
After the isolation of errors in individual tasks and in system behaviour,
the testing process moves to time-related errors. Asynchronous tasks
that interact with one another are tested with various data rates and
processing load. This is done to determine if inter-task synchronisation
B1965
Page No. 227
Unit 11
errors are likely to occur. Also, the tasks that interact through a message
queue or data store are tested to discover errors in the sizing of these
data storage fields.
System testing This is the fourth step of real-time software testing.
The complete range of system tests are conducted on the integrated
hardware and software. This is done in an attempt to find out errors in
softwarehardware interface. Interrupts are mainly processed by realtime systems. Thus, testing the handling of these Boolean events is
important. The tester develops a list of all probable interrupts using state
transition diagram and control specification, and also the consequential
processing that arises as a result of interrupts.
A new framework for testing real-time systems has been proposed. The
steps of this framework are as follows:
A method for generating test sequences is proposed.
The constraints that guarantee the execution of test sequences are
determined.
Next, a procedure and test architecture to execute test sequences is
proposed.
14. The errors are discovered in logic and _______in task testing.
15. The behaviour of the system model and the executable software is
compared in inter-task testing. (True/False)
16. All probable interrupts are developed using _________ and control
specifications.
Activity 2:
Suppose you are assigned the task of testing real-time system in your
organisation. Write the steps you will follow for the same.
(Hint: Strategies of real-time testing. Refer section No. 11.6)
11.7 Automated Testing Tools

We discussed about testing real-time system in the previous section; let us
now discuss about automated testing tools.
B1965
Page No. 228
Unit 11
It is very important to use the appropriate testing tool at the right time in a
software project. The testing tool increases the efficiency of testing by
automating processes as it helps to increase communication, promote best
practices and reuse tests and test data. We can describe automated testing
as the process of running test cases where manual involvement is not
required to run each test case. Different tools are available for automated
testing process including commercial products, in-house tools, open source
tools and others. Open source tools are not updated regularly and do not
support present technology, and are less expensive. Commercial products
are based on present technology and trends. In-house tools are developed
for particular operations by the software organisation.
Let us have a quick overview of some available automated testing tools.
Automated Test Designer (ATD)
The tool is a Windows client and/or server tool intended to create test
cases, t data and automated test scripts.
Compuware TestPartner and QARun

Compuware provides automated, that is, computerised functional and
regression testing tools. TestPartner gives reasonable assurance that
testing efforts are complete when testing complex applications based on
Microsoft, Java and web-based technologies.
BSSE System and Software Engineering DARTT

It is a tool for automated, that is, computerised testing over subprogram
parameter range. We can use the DARTT tool (Dynamic Ada Random
Test Tool) for verification of software and for quality analysis of the
inspected code. This tool estimates the test results and produces
documents or graphical reports.
For subprogram testing, DARTT sets the test environment on
the basis of the subprograms condition. We can also use DARTT as
quality analysis tool, for identification of unhandled exceptions or
significant changes of output.
Hewlett-Packard Company Mercury TestDirector for Quality

Center
It offers a method for collection of requirements, planning and
scheduling of tests, analysis of results and management of defects and
problems.
B1965
Page No. 229
Unit 11
Hitex Development Tools GmbH Tessy

It is an automated unit testing tool, which computerises the unit testing
of embedded software written in C. The testing tool Tessy provides
code coverage and creates test documentation in different formats. It
also maintains some cross compilers and debuggers made for
embedded systems and hence is able to execute the tests on real
hardware. We can say that the tool is well suited for regression tests.
Mercury QTP and WinRunner

They provide a complete solution for functional test, GUI test and
regression test automation. These tools support almost every software
application and environment.
Odin Technology Axe

We can define Axe as a new class of process-oriented tools related to
business, which permit users (non-technical) to automate testing. It
offers a way to rapidly organise automated testing systems, which can
be used by workers without expert automation talent thereby reducing
training efforts and costs.
Reactive Systems, Inc Reactis Tester

It is a model-based automated testing tool, which produces test cases
for implementations from models. Then, we compare these outputs to
determine whether or not the code adapts to its model. We can specify
how extensive the testing should be. The tool removes the need for
producing test groups manually and decreases the time spent in testing
by assuring that unnecessary tests are avoided.
Software Research, Inc SMARTS

It is an automated test management tool, which is referred to as a
software preservation and regression test system functioning as a
stand-alone product or as part of the entirely integrated Test-Works or
Regression multi-platform set of testing tools. SMARTS computerises
and simplifies the testing process by organising tests into a hierarchical
tree. It provides the ability to automatically execute all or a subset of
tests, and generating a range of reports based on test results.
B1965
Page No. 230
Unit 11
17. It is very important to use the appropriate testing tool at the right time in
a software project. (True/False)
18. Commercial products for automated testing are based on
___________.
19. Which tool computerises the unit testing of embedded software written
in C?
Activity 3:
Prepare a list of commonly used automated testing tools.
Hint: Refer section No. 11.8
11.8 Summary
Software testing is an activity that aims at evaluating the capability of a

program or system. It finds out whether the program meets the required
results or not. It also identifies errors in the coding of the application that
have to be eventually fixed.
There are three important kinds of testing white box testing, black box
testing and control structure testing.
White box testing

effectiveness.
Black box testing is designed to validate functional requirements

irrespective of the programs internal working.
Control structure testing exercises logical conditions present in a

program unit.
Real-time systems, which are growing more and more complex, need
their own strategies for testing like task testing, behavioural testing,
inter-task tasking and system tasking.
Various kinds of automated testing tools have been introduced by

leading companies that can be effectively used for the purpose of testing
and uncovering unknown errors.
helps
in
ensuring
B1965
softwares
security
and
Page No. 231
Unit 11
11.9 Glossary
Acceptance testing: It is the testing performed on a system before the
system is delivered to a live environment.
Beta testing: It is the testing of a re-release of software product carried out
by customers.
Branch testing: It is a kind of testing where all branches in the code are
tested at least once.
Combinatorial software testing method: It addresses generation of test
cases for issues that involve multiple parameters and combinations.
Cyclomatic complexity: Software metric that is used to indicate the
complexity of the program. It calculates the number of linearly independent
paths through a source code.
Debugging: It is the process of identifying and fixing bugs in a software
code or hardware device.
Functional testing: It is a type of user interface testing where functionality
of application is tested.
Integration testing: It is a development process where the program units
are combined and tested as groups.
Interrupt processing: An event that changes the sequence in which the
processor executes instructions is called an interrupt. To handle interrupt,
methodical procedures are implemented. This activity is called interrupt
processing.
Regression testing: Retesting of an earlier tested program following
alterations that faults are not introduced or exposed as a result of
modifications made.
Stubs: Stubs are the name given to replacements for unavailable
components that the components being tested will call as part of the test.
System testing: In system testing, various tests are carried on system to
find out functionality or to find out problems.

1. Explain software testing fundamentals.
2. What is white box testing?
3. Explain in detail the black box testing.
B1965
Page No. 232
Unit 11
4. What is control structure testing?

5. Explain testing of real-time systems.
11.11 Answers
1. Error free
2. Arrangement
3. Testable
4. Program
5. False
6. True
7. Program graph
8. True
9. Compound conditionals
10. False
11. Black box
12. Equivalence partitioning
13. Black box
14. Function
15. False
16. State transition diagrams
17. True
18. Present technology and trends
19. Hitex Development Tools GmbHTessy
Terminal Questions
11.12 Case Study

Effective Implementation of Software Testing Technique
An organisation is involved in an online business. It was in the process of
establishing an online e-commerce website. In an effort to facilitate the
B1965
Page No. 233
Unit 11
customers to electronically and effectively transfer funds from customer

checking accounts to organisation accounts, the organisation outsourced its
payment processing to a third party, Internet enabled transaction payment
firm. This third party payments software gave customised interfaces to help
payment processing between customers and the organisation. A thorough
security risk analysis was carried on the system.
Problems faced:
Risk assessment recognised transactions processing between payments
interface and the application as one of the risks. The effect of false
transaction is severe for both the customer and the organisation. Because
of this, the customers might suffer financial loss resulting from unauthorised
transactions that can reduce account balances. The credibility and the
reputation of the organisation could be seriously damaged as a result of
false transactions.
A high-level white box testing was carried out on the modules using the
payments interface. The steps involved in this case are as follows:
1. All the component interfaces were recognised and depicted as interface
figures.
2. On the component interactions, the trust relationship boundaries were
laid.
3. Data flows between components were drawn.
Solution:
Misuse cases were established on the basis of this information. One of the
misuse cases stated to exercising the payments processing functionality as
an unidentified user. The data flow showed a way where inputs from all the
users were not validated or genuine. A test case was created to submit an
account transfer from an external account to the organisation account
anonymously and the account transfer was completed successfully, which is
a vital software error illegal transactions through false path were allowed.
The risk assessment also recognised a weak confirmation component in the
payment customer service component of the system. After the analysis and
testing, it was shown that an attacker could achieve direct access to the
organisation administrative accounts. With this access, an attacker could
readdress transactions from organisation account to another, nonorganisation account.
B1965
Page No. 234
Unit 11
With the use of above two described exploits, white box testers showed that
an attacker could obtain payments from unknowing customer to the
organisation account and then redirect the transaction from the organisation
account to a non-organisation account. The two bugs together form a
severe crack of security with major business impact.
The above discussed scenario shows that risk analysis produces businessrelated results and addresses specific exposed areas of the software.
1. Explain the scope of white box testing.
2. How are the bugs identified?
References/E-references:
http://www.answers.com/topic/black-box-testing
http://www.computer.org/portal/web/csdl/doi/10.1109/RTCSA.
2000.896424
B1965
Page No. 235
Unit 12
Unit 12
Software Testing Strategies
Structure:
12.1 Introduction
Objectives
12.2 A Strategic Approach to Software Testing
Verification and validation
Organising software testing
A software testing strategy
Criteria for completion of testing
12.3 Strategic Issues
12.4 Unit Testing
Unit test considerations
Unit test procedures
12.5 Integration Testing
Top-down integration
Bottom-up integration
Regression testing
Smoke testing
Comments on integration testing
Integration test documentation
12.6 Validation Testing
Validation test criteria
Configuration review
Alpha and beta testing
12.7 System Testing
Recovery testing
Security testing
Stress testing
Performance testing
12.8 The Art of Debugging
The debugging process
The psychological consideration
Debugging approaches
12.9 Summary
12.10 Glossary
12.12 Answers
12.13 Case Study
B1965
Page No. 236
Unit 12
12.1 Introduction
In the previous unit, we discussed about software testing fundamentals and
objectives. We also analysed the process of test information flow and case
design. We discussed various testing methods such as white box testing,
black box testing and control structure testing. We also studied various
methods of testing real-time systems and various kinds of automated testing
tools.
In this unit, we will study about strategic approach to software testing and
strategic issues. We will also discuss about different kinds of testing such as
unit testing, integration testing, validation testing and system testing. We will
also study the art of debugging along with its process and approaches.
This unit will enable us to get an overall view of software testing strategies
and approaches. It will also enable us to carry out testing successfully by
using various testing methods. It will also enable us to carry out debugging
correctly.
Objectives:
define strategic approach to software design
describe strategic issues
explain unit testing and integration testing
describe validation testing and system testing
elaborate the art of debugging
12.2 A Strategic Approach to Software Testing

Let us start our discussion with the concept of strategic approach to
software testing.
We can define testing as an activity which is planned and carried out
methodically. Prior to this, an outline for testing is defined. All the guidelines
in the outline are called as the testing strategies. These testing strategies
provide:
Incorporation of software test case design practices into a wellorganised set of steps. This results in successful software development.
Description about the steps to be carried out during testing and the
amount of effort, time and resources required.
B1965
Page No. 237
Unit 12
Specifications of test plan, case design, execution and resultant data

collection and evaluation.
Flexibility to support an adapted testing approach.
Strength to promote realistic planning and management tracking as the
project proceeds.
Various test practices that are combined to present a new approach and
philosophy.
The project manager, software engineers and testing experts develop the
strategy. Testing is very important in the life cycle of the software. Testing
needs more project effort than any other software engineering activity. If it is
carried out unsystematically, it leads to wastage of time and effort, and the
errors will escape from the tester without being detected. Later on, they can
surface as defects after delivery to the customer, which can not only result
in huge financial losses that will have to be rectified, but also cause quite a
bit of embarrassment for the software company.
Let us now have a brief discussion about some aspects of software testing
12.2.1 Verification and validation
Let us first discuss about verification and validation.
Validation and verification are important stages in testing. Validation is
basically checking whether the developers are developing the right product
or not. The software should function in the manner the user wants.
Verification is checking whether or not the developers are developing the
product right. The software should match its provided specifications.
Validation and verification should be implemented at every stage in the
software process.
The objectives of validation and verification are to:
Discover defects in the system.
Evaluate the system to check whether it is usable in operational
situations or not.
12.2.2 Organising software testing
We will now describe how to organise software testing, with the help of the
following steps:
1. The software engineer analyses models, and then develops a computer
program and its documentation. Testing is destructive according to the
B1965
Page No. 238
Unit 12
software engineers perception because testing attempts to break the

software which the engineer has developed.
2. Testing should not be done by a developer. It should be done without
any partiality. Testers should be involved when testing steps are about
to start in the project.
3. Eliminate related issues by allowing the developer who has developed
the product to do so.
12.2.3 A software testing strategy
After organising software testing, we will now learn about software testing
strategy.
We know that the software engineering process begins with system
engineering that describes the software as a part of the system, and
proceeds to software requirements analysis where the information domain,
function, behaviour, performance, limitations and validation criteria for
software are identified. After the validation criteria are recognised, the
design is established and finally the coding is done.
Following the coding work, we provide a plan for software testing. Software
testing includes four different types of testing unit testing, integration
testing, validation testing and system testing.
1. The first step is unit testing. Unit testing focuses on each unit
(components) of the code. This testing makes sure that the unit
functions correctly.
2. The second step is integration testing. All the components are integrated
to form a complete software package. Integration testing handles the
issues related with the dual problems of verification and program
construction. After the software is integrated, a set of high-order tests
are conducted.
3. The third step is validation testing. Validation criteria should be tested.
Validation testing offers final assurance that the software fulfils
functional, behavioral and performance requirements.
4. The fourth step is system testing. System testing verifies whether all
elements are interconnected correctly, and it checks whether the entire
system performance has been achieved or not.
12.2.4 Criteria for completion of testing
Let us now analyse the criteria for completion of testing.
B1965
Page No. 239
Unit 12
When to stop testing? is indeed a very difficult question to answer,

because there is no possibility of knowing whether the error detected is the
last error in the code. Thus, after sufficient testing is done, a software
engineer requires certain criteria to determine successfully the completion of
testing. By using statistical modelling and software reliability theory, we can
establish models of software failures as a function of execution time. These
failures are uncovered during testing.
The standard that is used to measure a test objective is called completion
criteria. The criteria can be quantitative or qualitative which needs to be
determined by the test team whenever a test objective is accomplished. For
each test objective, one or more completion criteria should be specified. The
following are the common criteria:
The testing is stopped when the planned time for testing expires.
The testing is stopped when all the test cases are unsuccessful, that is,
when all test cases have been executed without finding errors.
1. Unit testing focuses on ____ of the software as implemented in the
code.
2. The question Are developers developing the right product? pertains to
_____________.
3. Both validation and verification are same. (True/False)
12.3 Strategic Issues

After studying about a strategic approach to software testing, we will now
study about strategic issues.
The testing always starts at component level and moves upwards, that is,
towards testing the complete system. This is called the testing strategy. The
initial focus is on testing modules, and later the modules are integrated and
tested. A software developer conducts the testing and test groups assist the
software developer for big projects. Testing and debugging are different
actions. In any testing strategy, debugging should be included. There are
certain strategic issues which should be considered.
Let us have a look at some of these strategic issues.
We have to specify the product requirements in a measurable
manner before testing A good strategy assesses quality
B1965
Page No. 240
Unit 12
characteristics such as maintainability, portability and usability along

with finding errors.
We have to state testing objectives clearly Specific goals of testing
are mentioned such as test effectiveness, test coverage and the cost to
detect and solve defects.
We have to understand the user of the software and profile should
be developed for each Cases should be used to explain interaction
scenario for every class of user. This decreases testing effort by
focusing testing on the actual use of the product.
We should develop strong software which is designed to test itself
The method of designing software should be such that it uses antibugging methods. Software should be able to diagnose errors. The
design should include regression and automated testing.
Technical reviews should be conducted before testing Technical
reviews (called as walk-throughs) reduce testing effort needed to
construct high-quality software.
Continuous improvement approach should be developed Testing
strategy should be precise. The metrics gathered during testing should
be used as statistical process control approach for testing.
12.4 Unit Testing

The previous section familiarised us with strategic issues in testing. This
section will focus on unit testing. To understand unit testing, let us first
understand the meaning of unit.
The smallest building blocks of software are called units. Units are made up
of individual functions in a language like C. We can define unit testing as
the method of validating small basic blocks of a complicated system, before
testing an integrated big module or the whole system. We will now have a
quick overview of the benefits of unit testing. Unit testing is able to:
Test parts of a project without waiting for the other parts to be created.
Accomplish parallelism in testing, by being able to test and fix problems
simultaneously by several developers working in tandem.
Detect and remove errors at a much lower cost as compared to
removing them at later stages of testing. The cost comprises the effort
taken for organising the test cases, executing the test cases, analysing
the results and fixing the defects.
B1965
Page No. 241
Unit 12
Take advantage of a number of formal testing techniques present for

unit testing.
Simplify debugging by restricting to a small unit the probable code areas
in which to look for bugs.
Test internal conditions that cannot be reached easily by external inputs
in large integrated systems.
Accomplish high level of structural coverage of the code.
Prevent lengthy compile-build-debug cycles while debugging complex
problems.
12.4.1 Unit test considerations

Let us now learn about some unit test considerations.
The interface module is tested to check the information flow in and out of
the program. The local data structure is inspected to assure that the data
stored momentarily maintains its integrity in all steps in a codes execution.
To make sure that all statements in a module are executed at least once, all
independent paths through control structure are implemented. Finally, all
error handling paths are tested.
Before any other test starts, the data flow across a module interface should
be tested. During unit testing, the local data structures should be
implemented and the impact on global data should be determined.
During unit testing, selective testing of execution paths is an important task.
To uncover errors due to wrong computations, control flow and
comparisons, test cases should be designed. The two effective techniques
to discover path errors are basis testing and loop testing.
You must note that the common errors in computation are as follows:
Misunderstood or wrong arithmetic precedence.
Varied mode operations.
Wrong initialisation.
Wrong symbolic representation of an expression.
Test cases should discover errors, such as:
Evaluation of unlike data types.
Wrong logical operators or precedence.
Probability of equality when precision error makes equality improbable.
Improper comparison of variables.
B1965
Page No. 242
Unit 12
Incorrect or missing loop termination.

Failure to exit while divergent iteration has come across unexpectedly.
Incorrectly altered loop variables.
12.4.2 Unit test procedures

Let us now study about unit test procedures.
Usually, we consider unit testing as an addition to the coding stage. Unit
test case starts after source level code is developed, reviewed and verified
for association to component-level design. A review of design information
offers direction for establishing test cases. Each test case should be
combined with a set of expected results.
For every unit, test drivers and/or stubs are developed as the component is
not a separate program. Driver can be defined as a main program that
allows test case data to be passed to the component, and finally prints the
relevant results. Stubs act as replacement modules which are subordinate
to the components being tested. A stub or a dummy subprogram utilises the
subordinate modules interface, does minimum data manoeuvring, prints
verification of entry and returns control to the module.
Drivers and stubs are individual programs that are developed to test the
module but they are not delivered to the user. Thus, drivers and stubs
symbolise overhead. If the drivers and stubs are simple then overhead will
be comparatively low. We cannot test many components effectively with
simple overhead software. In these cases, complete testing is postponed till
the integration testing.
Unit testing is minimised when a unit with large cohesion is designed. When
the unit has one function, the number of test cases is minimised and errors
are easily expected and discovered.
4. A review of _____ offers direction for establishing test cases.
5. Unit testing is more ____ compared to the other stages of testing.
6. Boundary conditions are tested to assure that the module operated
correctly at __________ established to limit processing.
B1965
Page No. 243
Unit 12
Activity 1:
Consider a source code and document all the possible test cases for unit
testing in your organisation.
(Hint: Certain errors are identified by test cases. Refer Section No. 12.4)
12.5 Integration Testing

We studied about unit testing in the previous section; let us now study about
integration testing.
We can say that the integration testing is the logical extension of unit
testing, where we combine two tested units into a component and test the
interface between them. Practically, we combine many units into
components, which are aggregated into larger parts of the program. The
combinations of pieces are tested and finally the process is expanded to
test modules with other groups. Finally, all the modules making up a
process are tested together. If the program is made up of more than one
process, we should test them in pairs, instead of testing all at once.
Integration detects issues that arise when units are combined. The errors
discovered when combining units are mostly related to interface between
units. We have to follow the given steps for integration testing:
1. First, we create a test plan.
2. Next, we create test cases and test data.
3. We create scripts to run test cases, if required.
4. Then, test cases are executed after the integration of components.
5. In the next step, we fix the bug and retest the code.
6. The test cycle is repeated until the components are successfully
integrated.
12.5.1 Top-down integration
Let us now discuss one of the methods of integration testing, namely, topdown integration.
We can state an incremental approach to develop a program as top-down
integration. In top-down integration, we first recognise the control hierarchy.
This helps us to identify and categorise the modules. The modules that are
subordinate to the main control module are integrated to the bigger
structure. Depth-first or breadth-first approach is used for integrating.
B1965
Page No. 244
Unit 12
We first integrate all modules on a control path, in depth-first approach.

Modules that are directly subordinate at each level are integrated together in
breadth-first approach. Figure 12.1 explains the top-down approach.
Fig. 12.1: Top-Down Approach
In Figure 12.1, you can notice that the sequence of integration of depth-first
approach is (Module 1, Module 2, Module 4), Module 6, Module 8,
Module 5, Module 7 and Module 3; the sequence of integration of breadthfirst approach is (Module 1, Module 2, Module 3), (Module 4, Module 5),
Module 6, Module 7 and Module 8.
12.5.2 Bottom-up integration
After top-down integration testing, we will now study about bottom-up
integration testing.
The bottom-up integration test commences at the atomic module level. The
lowest levels in the program structure are atomic modules. In this approach,
stubs are not needed as modules are integrated from bottom-up, and
processing needed for modules which are subordinate to a given level is
always present. Let us have a look at the steps followed in bottom-up
integration:
1. Combine low-level modules forming clusters which execute particular
software sub-function. Clusters are also called builds.
2. Write control program to co-ordinate test case input and output.
3. Test the build.
B1965
Page No. 245
Unit 12
4. Remove drivers and combine the clusters moving upwards in the

program structure.
Figure 12.2 explains the program modules.
Fig. 12.2: Bottom-up Integration

Bottom-up integration implemented to program modules
12.5.3 Regression testing

Figure 12.2 illustrates bottom-up integration. The program structure
changes when a new model is added. This results in new data flow paths,
input/output, control logic and others. All these changes will affect the tested
modules. We conduct regression test to recognise the errors and ensure
that new errors have not crept into the units being tested.
The number of regression tests can increase as integration testing
continues. Hence, regression test set should be designed to include tests
that handle one or more errors in every major program functions.
B1965
Page No. 246
Unit 12
In the previous section, we discussed about bottom-up integration

technique; let us now discuss about another technique used in integration
testing, namely, regression testing.
Regression testing is done whenever an implementation is modified within a
program. It is conducted by rerunning available tests against the altered
code to verify the effects after modifications and new tests are written
wherever required. For regression test, small amount of time should be
spent without decreasing the possibility that the tester will find failures in the
code which is already tested. Let us see the following strategies and factors
that are considered during this process of regression testing.
Fixed bugs should be tested. The developer handles the symptoms, but
not the cause for the bug.
When the bugs are fixed, the side effects of it should be noted. This is
because new bugs can be created when the old ones are fixed.
For each bug fixed, regression test should be written.
When more than two tests are the same, identify which test is not
effective and remove it.
Recognise tests that the code consistently passes and record them.
Functional issues should be focused on and not on issues related to
design.
Modify data and identify resultant data corruption.
Effects of modifications on program memory should be traced.
The establishment of library of tests is an effective way to carry out
regression testing. The library of tests includes standard battery of test
cases which are run every time when a new version of the code is
developed. Few software development organisations incorporate only tests
which have found bugs. The issue in such a case is that the specific bug
may have been identified and fixed. To remove redundant or unnecessary
tests, the regression test library should be regularly reviewed.
12.5.4 Smoke testing
In the previous section we studied about regression testing. Let us now
study about smoke testing.
Smoke testing is basically related to the concept of project control, where
variations of the actual project outputs are compared with required outputs.
Time, cost and performance are the factors used in project control.
B1965
Page No. 247
Unit 12
The project outputs should be assessed frequently in projects where time is

the limitation. Smoke testing comes into the picture from here. The following
steps are followed to carry out smoke testing:
1. The first step in smoke testing is to design the built. Built is a functional
unit in smoke testing. It brings together code, data files and libraries that
work together to provide the functionality to the software product.
2. A series of tests are conducted to find out errors which have maximum
probability to interfere with properly functioning software. The tests are
carried out on modules.
Various modules are combined and functionality stability between intermodules is tested.
There are many benefits of smoke testing, especially for complex projects
where time is a limitation.
Smoke testing should be done on high testing frequency basis whereby the
errors will show up on time. The mid-level integration of different modules
reduces the risk of inappropriateness at later levels. As smoke testing is an
incremental approach, it helps to maintain the right schedule with respect to
time.
12.5.5 Comments on integration testing
Till now, we have studied about different techniques of integration testing;
let us now consider some important comments on integration testing.
Every strategy has its own advantages and disadvantages. The
disadvantage of top-down integration is that it requires stubs, which have
their own testing difficulties. The disadvantage of bottom-up integration is
that the code individually does not live till the last module is added.
Integration strategies should be selected on the basis of software characters
and project agenda. It is better to use a combined approach which uses topdown tests for upper levels and bottom-up tests for subordinate levels of the
program structure. Regression tests should take care on critical module
function.
12.5.6 Integration test documentation
After studying some important comments on integration testing, we will now
study about integration test documentation.
B1965
Page No. 248
Unit 12
Integration test documentation includes the entire plan for integration of

software and description of tests. The document includes test plan and
procedure. The document plays an important role in software configuration.
Test plan explains the entire strategy for integration. We can separate
testing into phases and builds, which specify particular functional and
behavioural characters of software. For all test phases, we apply the
following criteria:
Functional validity These are the tests conducted to discover
functional errors.
Performance These are the tests conducted to check performance
limits established during software design.
Interface integrity When each module is included into the program
structure, internal and external interfaces are tested.
Information content These are the tests conducted to find errors
related to local or global data structures.
Test Pla
also includes the timeline for integration, development of overhead software
and associated topics. Start and end dates of each phase and required test
environments and resources are explained. Hardware configurations,
special simulators and tools, and others are also described.
Test procedure needed to carry out the test plan is provided in detail. The
integration order and related tests at all integration levels are described. It
also includes test cases and results.
The test specification contains all the test results and problems. The
information provided in the specification is very important at the time of
software maintenance. It also includes references and appendices.
According to the organisations requirement the test specification format can
be created.
7. The logical extension of unit testing is the __________ testing.
8. The _________ is conducted by rerunning available tests against the
altered code.
9. Integration strategies should be selected based on software
characteristics and ___________.
B1965
Page No. 249
Unit 12
Activity 2:
Consider a source code of your choice, modify the implementation and
carry out regression testing. Generate the document after testing.
(Hint: Regression testing steps, Documentation criteria. Refer section
No. 12.5)
12.6 Validation Testing

In the previous section, we studied about integration testing and various
methods associated with it; let us now study about validation testing.
Validation testing is carried out after integration testing where software is
assembled and errors related to interface are discovered and fixed.
Validation works well when software functions in a way which can be
expected by the client.
12.6.1 Validation test criteria
We will start our discussion with validation test criteria.
Software validation is done by a set of black box tests which illustrates
conformity with requirements. It uses a test plan and test procedure. Test
plans and procedures are developed to assure that all functional
requirements are fulfilled, all behavioural characters, performance
requirements are attained, documentation is proper and human-engineered
and other requirements are fulfilled.
After every validation test that is conducted, any two possible conditions
exist either a deviation from the specification is discovered and a
deficiency list is generated or the function and performance features
conform to specifications and are accepted. Deviation or fault discovered at
this level in a project can sometimes be corrected before scheduled
delivery. It is required to negotiate with the client to establish a method to
resolve deficiencies.
12.6.2 Configuration review
Configuration review is an important element of validation process. The goal
of review is to ensure that all the elements of software configuration are
correctly developed and catalogued and it contains all the required
information to strengthen the support phase of software life cycle. The
configuration review is known as audit.
B1965
Page No. 250
Unit 12
12.6.3 Alpha and beta testing

Before releasing the software product into the market it should be tested.
For this a formal test strategy is planned and then executed. Alpha and beta
testing are conducted after completion of formal phases of testing.
Before the software is released for public use, alpha testing is conducted.
Alpha testing is carried out by using white box testing methods. The aim of
this is to simulate real users and carry out tasks and operations that a usual
user performs. Alpha testing is conducted in a lab environment and not in
usual work environments.
Beta testing is the next phase of testing. The goal of beta testing is to
perform a rationality check before the product is released. During this stage
errors can be found out, hence the software distribution is limited. Feedback
is usually taken from outsourced testing companies to fix the errors.
The techniques used in a public beta test are limited to black box testing
methods. This is because the common people do not have knowledge of the
software program under test.
10. Software validation is done by a set of ___________ which illustrates
conformity with requirements.
11. Alpha testing is conducted in a work environment. (True/false)
12. The goal of ________ is to perform a rationality check before the
product releases.
12.7 System Testing

In the previous section, we studied about validation testing; let us now study
about system testing.
The system testing is conducted based on unit and integration testing. It is a
very important step in quality management process. For system testing, the
following are the prerequisites:
Unit test should be conducted on all the components.
Integration testing is conducted after integration of all components.
Complete the testing.
Create an environment resembling the production environment.
B1965
Page No. 251
Unit 12
The following are the steps carried out to do system testing:

1. The first step is to create a test plan.
2. The second step is to create test cases.
3. The third step is to build data that are used as input for testing.
4. The fourth step is to create scripts if required to build environment and
to automate execution of test cases.
5. The fifth step is to execute test cases.
6. In the sixth step, bugs are fixed if present and code is retested.
7. In the seventh step, the test cycle is repeated.
12.7.1 Recovery testing
We will now discuss about the various techniques of system testing,
beginning with recovery testing.
Recovery testing is conducted to check how fast and better the application
can recover against any kind of crash or hardware failure, and others. The
objectives of recovery testing are:
To assure continuity of operations after failure.
To check recovery process and effectiveness of recovery process.
To ensure sufficient backup data are retained and secured.
Document recovery procedures.
Develop recovery tools and make them available.
The following are the methods to show how recovery tests are used:
To evaluate adequacy assess procedures, methods, tools and
techniques.
Failure can be introduced in the system after it is developed and verify
whether the system can recover.
A simulated disaster is conducted on particular aspects of the
application system.
12.7.2 Security testing
Let us now learn about another technique of system testing, namely,
security testing.
Computer-based systems that handle sensitive data or cause actions that
can harm individuals are often the target for illegal penetration. Illegal
penetration includes activities such as hacking, employees gaining access
to systems for malicious acts, and so on.
B1965
Page No. 252
Unit 12
Security testing is conducted to check the protection mechanisms built into

a system to see whether they will protect the system from illegal penetration
or not. In security testing, the tester will act as an attacker who attempts to
get into the system. The tester tries to get passwords through external
clerical ways, might attack the system with custom software, thereby
denying service to others, might deliberately cause system errors, get into
the system during recovery, browse through insecure data and hope to get
the key to system entry.
When sufficient time and resources are provided, a good security testing will
eventually penetrate the system. The system designer should make
penetration cost more than the value of the information that can be stolen in
acts of illegal penetration.
12.7.3 Stress testing
After security testing, we will now discuss about stress testing.
Stress testing is carried out to evaluate a system or component at or beyond
the boundaries of its particular requirements to determine the load under
which it fails and how. It finds defects whose consequences are certain but
which are hidden in complex code, and hence will be difficult to find when
inspecting. Stress testing involves thinking of what could go wrong without
really studying the software. Stress testing needs attention of the tester in
detail.
12.7.4 Performance testing
In the previous section, we discussed about stress testing; let us now study
about another technique of system testing, namely, performance testing.
Performance testing is carried out to understand the application or World
Wide Web sites scalability or to benchmark the performance in an
environment of third party products like servers and middleware for
purchase. This type of testing is specifically used to find out the
performance of restricted access in applications of high use. The testing
includes automated test set to allow easy simulation of normal, peak and
exceptional load conditions.
To test run-time performance of software within the background of an
integrated system, performance test is designed. Performance testing is
conducted throughout all the levels of testing process. But the true
B1965
Page No. 253
Unit 12
performance of a system can be ascertained only when all the system

elements are integrated.
Performance tests are combined with stress testing, and need hardware
and software instrumentation to measure resource utilisation in an executing
method. The tester can discover situations that result in degradation and
probable system failure by using instrumentations in a system.
13. The _________ is conducted to check how fast and better the
application can recover against any kind of crash or hardware failure.
14. To check the protection mechanisms built into a system ___________
testing is conducted.
15. To test run-time performance of software within the background of an
integrated system _____________ is designed.
Activity 3:
Prepare a list of techniques you can use in system testing. Give some
examples.
(Hint: System testing steps. Refer section no. 12.7 )
12.8 The Art of Debugging

In the previous section, we discussed about system testing, let us now study
about the art of debugging.
We can define debugging as the method of tracing and fixing errors in a
computer program or hardware device. To debug a program or hardware
device, we should start with a known problem, segregate the source of the
problem and later fix it. An important process in software or hardware
development process is debugging. Debugging is carried out regularly
throughout the process for complicated products. After debugging is
finished, the software program is released for general use. Though the
product is released after thorough debugging, debugging continues as a
maintenance practice for the products lifetime.
12.8.1 The debugging process
Let us now have a brief discussion about the debugging process.
B1965
Page No. 254
Unit 12
The debugging process includes many steps to fix the detected error and
check that the error does not appear again. The goal is to detect, classify,
fix and verify the error. The following are the five steps in the debugging
process in software.
1. The first step is to identify the problem. We check the presence of bug,
and describe the problem caused by the bug and verify what the code is
supposed to do.
2. The second step is to collect information. We gather all the comments
and feedback from the users and note down the personal observations.
We collect the test cases and also the environmental information.
3. The third step is to assess the problem and classify it. The theory behind
the causes of the problem should be developed. The code should be
reviewed. The problem is classified into categories such as syntax
errors, memory problem and others.
4. The fourth step is to fix the root cause of the problem or bug after
classifying the problem.
5. The fifth and final step is to test the software again to verify the fix.
12.8.2 The psychological consideration
In the previous section, we discussed about the debugging process; let us
now discuss about the psychological consideration while debugging.
Debugging ability is an inborn human characteristic. Some are good at
debugging and some are not. Shneiderman states on the human aspects of
debugging1debugging is one of the frustrating parts of programming. It
has elements of problem solving or brain teasers, coupled with annoying
recognition that you have made a mistake. Heightened anxiety and the
unwillingness to accept the possibility of errors increases the task difficulty.
Fortunately, there is a great sigh of relief and a lessening of tension when
the bug is ultimately corrected.
Though it is difficult to learn debugging, many approaches to the problem
are provided.
SHN80
B1965
Page No. 255
Unit 12
12.8.3 Debugging approaches

As we are discussing about the art of debugging, we will now discuss about
the approaches used by programmers, for debugging, as shown in Figure
12.3.
Fig. 12.3: Debugging Approaches
Brute Force Method The common method of debugging is the brute

force method. This method is not very efficient. This method includes
loading print statements into the program, and printing the intermediate
values. The results are printed to recognise the faulty statement. With
the use of symbolic debugger, this method becomes more systematic
since the values of various variables are checked easily, and break
points and watch points are set easily to test the values of variables.
Backtracking In this method, the source code is traced backwards

starting from the statement where an error symptom is identified till the
next error is found. Correspondingly, as the source lines to be tracked
backwards increases, the number of backward path also increases. The
number of paths may increase in this method.
Cause Elimination Method In this method, a list of causes that could

probably have contributed to the error symptom is identified, and tests
are conducted to remove each cause. A related technique of
identification of the error from the error symptom is the software fault
tree analysis.
Program Slicing Program slicing is similar to backtracking. Slices are

defined to reduce the search space. At a specific statement for a
specific variable, a slice of program is the set of source lines leading this
statement. The slice of program influences the value of that variable.
B1965
Page No. 256
Unit 12
16. The process of tracing and fixing errors in a computer software or
hardware is called __________.
17. The first step in debugging process is identifying the ______.
18. ________ method includes loading print statements into the program,
and printing the intermediate values.
12.9 Summary
Testing is an activity that is planned and carried out methodically. Prior
to the actual testing work, an outline for testing is defined. All the
guidelines in the outline are called the testing strategies.
Testing is a very important part of the software life cycle development.
Errors, if untraced due to inadequate testing, can surface as defects
later at the customer end, and this can lead to both financial losses and
embarrassments.
Verification and validation are two important concepts in testing.
Validation is checking whether the developers are developing the right
product or not. Verification is checking whether the developers are
developing the product right or not.
Testing, within the framework of software engineering, is done in a
series of four steps that are implemented successivelyunit testing,
integration testing, validation testing and system testing.
Debugging is a method of tracing and fixing errors in a computer
program or hardware device. The art of debugging is an important
criterion of software testing and is accomplished in five stepsidentify
the problem, collect information, assess the problem and classify it
appropriately, fix the root cause of the problem or bug and test the
software again to verify the fix.
Psychological consideration is very important during the debugging
process.
12.10 Glossary
Break point: It is a point in computer code at which execution can be held
for some time to allow manual or automated monitoring of a program.
B1965
Page No. 257
Unit 12
Hardware configuration: The arrangement of computer hardware for the

required specification is called hardware configuration.
Simulator: It is a tool, calculation or experiment, to reconstruct a particular
condition in test conditions to model or monitor the results.
Software fault tree analysis: It is a software failure analysis where an
unwanted state of a system in analysed using Boolean logic.
Symbolic debugger: Symbolic debugger is a source code debugger.

1.
2.
3.
4.
5.
6.
7.
Explain strategic approach to software debugging in detail.

What are strategic issues?
Explain unit testing.
Explain integration testing in detail.
What is validation testing?
Describe system testing.
Explain debugging and its approaches.
12.12 Answers
1. Each unit
2. Validation
3. False
4. Design information
5. Cost effective
6. Boundaries
7. Integration
8. Regression testing
9. Project agenda
10. Black box tests
11. False
12. Beta testing
13. Recovery testing
14. Security
15. Performance test
16. Debugging
B1965
Page No. 258
Unit 12
17. Problem
18. Brute force
Terminal Questions
12.13 Case Study

A Solution to Issues in Software Testing
An organisation with decentralised global IT operations wanted to decrease
operating expenses, while increasing efficiency and consistency within IT
and quality assurance organisations. Executive management directed
constant process improvement, but the environment required stable
processes or tools to manage.
Problem:
Software testing within this organisation was managed primarily at the
project level, without formal process, methodology, tools, metrics collection
or reporting. All testing was conducted in the organisation with significant
cost.
Solution:
The organisation took help from an organisation dedicated to provide testing
services. This service provider developed well-defined software testing
processes for the organisation, including estimation models, process road
maps and other necessary structures. The service provider was able to
decrease post-production errors through structured requirement analysis
and complete traceability to test cases. Regression test cycle times were
also minimised by automating test cases. The service provider also used
process improvement awareness to assist complete metrics gathering and
reporting. This improved perceptibility and appearance for IT and its
services.
B1965
Page No. 259
Unit 12
1. What were the steps taken to solve the issues of the organisation?
2. List out the benefits which the organisation gained.
E-References:
http://www.mobilein.com/WhitePaperonUnitTesting.pdf
http://www.exforsys.com/tutorials/testing/integration-testingwhywhathow.htmlhttp://www.aptest.com/testtypes.html
B1965
Page No. 260
Unit 13
Unit 13
Software Verification
Structure:
13.1 Introduction
Objectives
13.2
13.3
13.4
13.5
13.6
13.7
13.8
13.9
13.10
13.11
Code Reading
Static Analysis
Symbolic Execution
Proving Correctness
Code Inspection or Reviews
Summary
Glossary
Terminal Questions
Answers
Case Study
13.1 Introduction
We studied about strategic approach to software testing and strategic
issues in the previous unit. We also discussed about different kinds of
testing such as unit testing, integration testing, validation testing and system
testing. Furthermore, we also studied the art of debugging, its process and
approaches.
In this unit, we will study about the different techniques of software
verification such as code reading and the concept of static analysis. We will
also discuss about symbolic execution. We will also analyse the concept of
proving correctness. Finally, we will study about code inspection.
This unit will enable you to carry out software verification successfully by
analysing the verification techniques such as code reading, static analysis,
symbolic execution, proving correctness, code inspection and provide
guidelines to conduct software verification.
Objectives:
describe code reading
explain static analysis
describe about symbolic execution
B1965
Page No. 261
Unit 13
illustrate proving correctness

explain code inspection
13.2 Code Reading

As we are going to discuss about different techniques of software
verification, let us first discuss about the meaning of software verification.
We can define software verification as one of the disciplines of software
engineering that focuses on checking whether the software meets the
requirements completely or not. This discipline has different techniques
associated with it. Let us have a look at these techniques shown in Figure
13.1.
Fig. 13.1: Software Verification Techniques
In this section, we will discuss about the first technique of software

verification.
We can define code reading as the process where the reviewer carefully
reads the code to detect any divergence or disagreement between the
provided design specifications and the actual implementation. It is one of
the methods for code verification. The software engineer should know the
technique of code reading. Code reading involves the following two steps:
1. In the first step, we determine the abstraction of module.
2. In the second step, we compare the design specifications.
The process of code reading and designing is reverse in nature. In the code
reading technique, it is necessary to understand the documents, software
specifications and software design. This helps us to determine the
consistency and correctness of the code. In the code reading process, it is
preferable that the code is read beginning with the inner structure of module
and radiated outwards. In the code reading process, we have to first
determine the behaviour of the module abstract and then present the
B1965
Page No. 262
Unit 13
abstraction. The code reading process continues till the end of the module is
reached. The abstract behaviour of the module will be known to the reader
by the time the reader reaches the end of the module. Then, we compare
the specifications to determine the disagreement.
Code reading is very efficient because it has the ability to detect errors that
cannot be detected by testing. As reading is an approach of stepwise
abstraction, the code should also be programmed in a method favourable to
this process. This results in producing well-structured programs. Code
reading is performed to improve the software code, without completely
changing the program or with lesser disruption in the present functionality of
the program. This also focuses on inspecting the code and eliminating
errors.
Let us have a look at the general conventions we should follow while
reading the software code. The steps are as follows:
1. The first convention is to find out what is important. Importance should
be given to find out graphical techniques italics or bold, and positions
start and end of the software code while reading the code. The
necessary comments should be highlighted in the introduction or at the
end of the code. The level of details should be according to the
requirement of software code.
2. The second convention is to read what is important. The reading should
be done with the intention to check syntax and structure like loops,
brackets and functions instead of non-essentials like name of the
developer who has developed the code.
1. The abstraction of module is the first step in the _____ process.
2. Code reading is performed to improve the software code to completely
change the program or with disruption in the present functionality of the
program. (True/False)
3. Code reading is considered efficient because it has the ability to detect
______ that cannot be detected by testing.
B1965
Page No. 263
Unit 13
Activity 1:
Consider that you are a reviewer and you have to conduct a code reading
process for a program of your choice. Find out the conventions you will
follow for the same.
(Hint: Conventions.)
13.3 Static Analysis

After discussing about the code reading technique, we will now discuss
about another software verification technique, namely, static analysis.
We can define static analysis as an analysis of programs by sequentially
analysing the program text without executing the program. We can perform
static analysis by manual inspections, and also mechanically by using
software tools. In this analysis, the program text acts as input to the tools,
and the program is not executed. The goals of static analysis tools are to
find errors or to generate information about the structure of the program,
which can be helpful for documentation or to understand the program.
We can design different kinds of static analysis tools to perform different
types of analysis. Static analysis tools are used frequently. There are tools
that cannot detect errors, and the errors escape in the code. Hence, we use
static tools to prevent such omissions. Static analysis saves the effort of
detecting the error from the data, because the errors itself get detected.
Warnings are provided, if potential errors are present, and also a picture of
the programs structure is provided by the static analysis exercise. We use
static analysis to verify contraventions of local programming standards,
which are not detected by standard compilers.
There are two forms of static analysis, namely, limited static analysis (static
analysis that is performed on compilers) and data flow analysis. The data
flow analysis focuses on the data used by programs and detects data flow
irregularities. The irregularities are not errors but a symptom of errors, which
are caused due to carelessness in typing or error in coding. If a code has
data flow irregularities, it is a cause of concern which should be
appropriately handled. The main objectives of static analysis are as follows:
Proscriptive analysis It aims at detecting real or potential flaws in the

program.
B1965
Page No. 264
Unit 13
Descriptive analysis It provides explanations of what is going on in

the program.
Prerequisite for structural testing Static analysis is a prerequisite for

white box testing to find out parts of the program that are to be
exercised during testing.
Let us now briefly discuss about some static analysis tools. We use three
types of static analysis tools, and they are as follows:
Code-based testing tools In code-based testing tools, the source

code is the input. The tool accepts the input, carries out analysis and
finally test cases are generated. Using a description of program input
and procedural design as a guide, static testing tools derive test cases
using path coverage, condition testing and information flow criteria.
Specialised testing languages These languages help software

engineers to write detailed test specifications that describe each test
case and the logistics for its execution. Yet, such tools do not help tester
in designing test cases.
Requirements-based testing tools These tools isolate particular

user requirements and suggest test cases that will exercise the
requirements. To work correctly, the tools should have access to a
formal specification for the software.
All the static testing tools have the ability to document and they list out all
the tests conducted. They conduct comparisons of test output to see
differences between expected and actual results.
4. _________ is defined as analysis of programs by sequentially
analysing the program text without executing the program.
5. Static analysis is used to verify contraventions of _______ which are
not detected by standard compilers.
6. ________ tools isolate particular user requirements and suggest test
cases that will exercise the requirements.
B1965
Page No. 265
Unit 13
Activity 2:
Prepare a list of software analysis tools. Give examples of the companies
using those tools.
(Hint: Refer to Section 13.3, Static Analysis.)
13.4 Symbolic Execution

In the previous section, we discussed about static analysis; let us now study
about symbolic execution, which is also a software verification technique.
We can define symbolic execution as a process where the program is
executed by replacing real variable values with symbolic input values, and
to represent the values of program variables as symbolic expressions. As a
result, the output values computed by a program are expressed as a
function of the input symbolic values. The symbolic execution is carried out
just like a normal execution; the only difference is that the values are
symbolic formulae over the input symbols. Symbolic values of program
variables, program counter and path condition are the states of symbolically
executed program. Sometimes constraints are provided with which the
inputs should agree. This helps the path condition to specify the conditions
to execute the code in a specific path. The path condition is a Boolean
formula over the symbolic inputs. The next statement to be executed is
defined by the program counter. The execution paths tracked in symbolic
execution of programs are represented by a symbolic execution tree. The
program states are indicated as nodes and transitions between states are
indicated by arcs.
The path condition keeps track of constraints on symbolic values and
determines the control flow path yielding the state. For example, when a
conditional jump instruction is executed, to determine whether the jump
condition and its cancellation are met under the present path condition, a
decision procedure is raised. If both are met, we divide the present state
into two next states, and add the path condition of each, with the clause
determining which branch is executed. The symbolic execution of
conditional branch type statements is difficult to handle. The symbolic
execution along a path signifies unlimited numeric executions that may
occur along that path. The advantages of symbolic execution are as follows:
B1965
Page No. 266
Unit 13
It provides solid representation of the program state space, where large

set of numeric values are represented by symbols, potentially limiting
state explosion during analysis.
It allows analysis of software modules separately by initialising them

with symbolic values, thus performing modular verification.
We apply the symbolic execution to languages with numeric types. Symbolic

execution, when considering languages that allow references and dynamic
memory can be carried out with lazy initialisation. The probable initial values
of symbolic reference are calculated by lazy initialisation, only when it is
used first during execution. A large number of states are generated in later
phases of symbolic execution, when all probable values are used first.
Therefore, variants have been proposed to delay further the set of probable
values which should be considered to minimise state explosion.
Let us have a look at the symbolic execution tree shown in Figure 13.2.
Consider a code fragment that illustrates symbolic execution tree as shown
in Figure 13.2, which swaps the values of integer variables a and b,
when a is greater than b. Initially, path condition is true and a and b
have symbolic values A and B, respectively. Path condition is updated
with assumptions about the inputs at each branch point to help choose
between alternative paths.
We can use symbolic execution to determine conditions under which a
specific control flow path is taken. The symbolic execution in-turn helps to
identify impracticable program paths and also those forbidden paths that
should not be taken. It is basically to generate test data for the execution of
particular parts and paths in a program.
B1965
Page No. 267
Unit 13
Fig. 13.2: Symbolic Execution Tree
The effect of execution of deriving a logical representation is necessary to

be given in a methodical way, which helps to compare a programs probable
behaviour to a formal specification. However, the basic methods of formal
verification, including symbolic execution, support practical techniques in
software analysis and testing.
Let us now briefly discuss about few uses of symbolic execution and its
techniques. They are as follows:
Rigorous proofs of properties of critical subsystems, such as a safety

kernel of a medical device.
Formal verification of critical properties, which are specifically resistant

to dynamic testing.
Formal verification of algorithm descriptions and logical designs, which

are less complex than their implementations in program code.
The basis of symbolic execution is tracing execution with symbolic values

and expressions. When tracing execution with concrete values, it becomes
B1965
Page No. 268
Unit 13
clear as to what to do with a branch statement. For example, an if or

while test the test predicate is evaluated with the current values, and the
appropriate branch is taken. If the values bound to variables are symbolic
expressions, both the true and false results of decision may be possible.
We can trace execution through the branch in either direction, and interpret
the execution of the test as adding a constraint to record the outcome.
We can say that symbolic execution acts as a bridge from an operational
view of program execution to logical and mathematical statements. The
symbolic execution technique is based on hand-execution method, that is,
using symbols rather than concrete values. To use symbolic execution for
loops, procedure calls and data structures present in modules, symbols are
represented hierarchically that are continuous and without any break. This is
done by composing facts about small parts into facts about larger parts.
Symbolic execution is a basic technique that finds many different
applications. The symbolic execution technique is used for test data
generators to draw constraints on input data. Symbolic execution
techniques are used by many development tools to perform or check
program transformations, for example, re-factoring source code or unrolling
a loop for performance.
Software developers can rarely carry out symbolic execution of program
code in detail, but often use it for reasoning about algorithms and data
structure designs. The widely used approaches in programming are to
specify pre-conditions, post-conditions and invariants. All these are
supported by tools used for run-time checking assertions.
7. The process where the program is executed by replacing real variable
values with symbolic input values is called ________.
8. The states of symbolically executed program are program variables,
_______ and path condition.
9. The symbolic execution technique is based on ________ method.
13.5 Proving Correctness

After studying about the symbolic execution, we will now study about
another software verification technique, namely, proving correctness.
B1965
Page No. 269
Unit 13
Proving correctness is one of the techniques of formal verification of the

software. We can define proving correctness of a program as the process
of demonstrating the correctness of the program, by proving the codes
consistency with its specification. Theoretical and mathematical models are
used to prove the correctness of a program. It is carried out without
executing the program. Many verification conditions can be generated that
represent the correctness of the code mathematically. Once we use formal
proof systems, the correctness of the code with respect to the requirement
specification is guaranteed.
Let us take a look at the following points which are necessary conditions in
assuring correctness:
Development of program within a logical calculus is feasible.
It is methodically helpful to interpret programs as executable

specifications.
Computer-supported verification is practicable for middle-size programs.
The question of scaling up to large systems remains open and the levels
of exertion are high.
For software and system technology, the ability to develop software systems
that can be applied to a large scale and strive for correctness is of high
importance. It is not possible to assert correctness for complex,
heterogeneously constructed systems without the help of mathematical
methods. The quality assurance and evidence of correctness will become
increasingly important in the future years, when the demands for evidence
of a dependable software product will become part of the established
compulsory prerequisites. The correctness has to be proved for all steps
during development. The two benefits of attempting the proof are as follows:
If successful, the proof guarantees that the program, or part of it, is

indeed correct.
If failed, the proof may be a very effective tool for error detection,
particularly if carried out at the high design level.
Proving correctness of the program is the only reliable technique to show

the programs correctness. It should be used whenever correctness is of
utmost importance, as in mission-critical systems where human lives are at
stake. In the case of mission-critical systems, usually a small part of the
B1965
Page No. 270
Unit 13
code is responsible for its reliability, thus making the formal proof an
economically feasible task. It basically aims towards analysing objects that
are supposed to be correct or close to being correct. Sometimes individuals
think that proving correctness of program should be reserved for parts of the
program that are most likely to be incorrect and testing may be instrumental
in the identification of those parts.
10. We can define _____________ as the process of demonstrating the
correctness of the program, by proving the codes consistency with its
specification.
11. Proving correctness of the program is the only reliable technique to
show the programs correctness. (True/False)
12. Proving correctness technique uses ___________ and mathematical
models to prove the correctness of a program without executing the
program.
13.6 Code Inspection or Reviews

In the previous section, we discussed about proving correctness. Let us now
discuss about code inspection which is also called reviews.
We can define code inspection as one of the techniques of formal method
to review a software product. The goal of code inspection is to detect errors
caused due to typological mistakes and incorrect programming. Code
inspections are highly structured and require proper training for all
individuals. This kind of review is different from other reviews, such as peer
review and walk-throughs. Code inspection technique requires someone
else to learn and understand the material being presented, potentially giving
a different dimension and interpretation at the inspection meeting.
The individuals or the persons appointed to inspect the code are called
inspectors. Every inspector is given the task of reviewing the code from a
different point of view such as a user, a tester or a product support person.
This helps to get different views of the product under review and frequently
recognises the problem. To ensure that the material is covered evenly and
completely, one inspector is assigned with the task of reviewing the code
backwards that is, from end to start.
B1965
Page No. 271
Unit 13
The software is presented to project managers and users for their

comments and eventual agreement. The review and inspection teams
inspectors include a moderator who conducts meetings, checks errors and
makes sure that the inspection process is followed, a reader who translates
or interprets the operations of code, a recorder who records each error in
the code to help others to think thoroughly about the code without missing
anything, and the author who is a spectator and observes the code
inspection process.
An individual designated as the author should observe the code inspection
process silently and should intervene only when necessary. The author
should understand the errors detected in the code. A section of code from a
computer language is translated to a common language (English) by the
reader.
After a general inspection meeting, the inspectors meet again to discuss the
defects they had identified and to work with the moderator to prepare a
written report that identifies the rework necessary to address the problems.
The programmer then makes the modifications and the moderator verifies
whether the changes are being made correctly or not. Re-inspection may be
conducted depending on the scope and magnitude of changes and on how
critical the software is to find any remaining bugs.
As the main aim of review is to detect defects in code, one evident coding
defect is that the code fails to implement the design. There can be a
difference between the function implemented by a module and the function
actually specified. And also there can be difference between the interface of
modules and the interface specified in the design. Also the inputoutput
format assumed by a module may be inconsistent with the format specified
in the design.
We can classify other code defects into logic and control operations and
computations, and data operations and computations. Infinite loops,
incorrect predicate, improper nesting of loops and branches and others are
few logic and control defects. Incorrect access of array components,
improper initialisation, misuse of variables and others are few data defects.
Code inspections are very effective in finding bugs in a software product,
particularly in design documents. As organisations and product
B1965
Page No. 272
Unit 13
development teams have begun to realise the benefits of code inspection, it

is now becoming popular.
Let us see the steps followed to conduct code inspection.
1. Planning This is the first step of code inspection. The author submits
the findings to the moderator after compilation and after ascertaining the
absence of errors and warning messages in the code. Moderator then
forms an inspection team. Moderator gives out the listings and other
documents such as design documents to each team member after the
inspection team is formed. Inspection meetings are planned by the
moderator and he regularly co-ordinates with the team members.
2. Overview This is the second step in the process of code inspection.
This step is required when the inspection team members do not know
the functioning of the project. The author provides details to enable the
team members to understand the code.
3. Preparation This is the third step in code inspection. The code and its
related materials are examined by each inspection team member
individually. To make sure that each problem area is verified, the
members use a checklist. All the members maintain this checklist, where
all the problematic areas are stated.
4. Inspection meeting This is the fourth step in code inspection. This is
done to review the software code. The inspection meeting is conducted
with all the team members. The code under review is discussed with
inspection team members by the moderator. We can use two checklists
for recording the result of code inspection, which are code inspection
checklist and inspection error checklist. The summary of all different
kinds of errors seen in the software code is maintained in code
inspection checklist. This is used to understand the effectiveness of the
inspection process. The aspect of each error that needs rework is
maintained in the inspection error checklist (i.e. the details of errors that
necessitate the entire coding process to be repeated).
5. Rework This is the fifth step in code inspection process. In this step,
all the defects are corrected efficiently by the author.
6. Follow-up This is the sixth step in code inspection process. In this
step, the moderator or the entire team checks whether all the
B1965
Page No. 273
Unit 13
corrections are effective and that no other errors have been introduced
into the software.
In the inspection checklist, we categorise all the errors into major and minor
errors. If an error results in problems and the user comes to know of it later,
then the error is said to be major. Spelling errors and non-conformity with
standards are minor errors. The list of errors categorised helps us to deliver
the software to the user without missing anything and it helps us to review
all errors present in the code whenever we have less time to review and we
need to prioritize.
At the end of the code inspection meeting, decisions are taken on whether
the code should be accepted in the present form or sent back for rework.
The author makes all corrections, if the code requires rework and later the
code is compiled. The code is presented back to the moderator after the
reworked code appears to be error free. The reworked code is again
checked by the moderator. The inspection formally ends when the
moderator agrees to the sanctity of code without any conflicts.
Let us have a look at some points which we can include in the code review
checklist:
Are all loops terminated?
Are divisors tested for zero wherever applied?
Are imported data tested for validity?
Wherever required are the pointers set to NULL?
Are the branch conditions right?
Are actual and formal parameters matching?
Are initialisations of indexes right?
Is it possible to place the statements present within the loop outside?
13. The goal of _________ is to detect errors caused due to mistake and
incorrect programming.
14. During code inspection, the ________ translates or interprets the
operation of the code.
15. The first step of code inspection is _________.
B1965
Page No. 274
Unit 13
Activity 3:
Form a team in your organisation, categorise them as inspectors,
moderators, authors and recorders. Conduct a meeting to discuss about
issues related to software product available at your organisation. Prepare
a checklist for the same.
(Hint: Steps of code inspection, Checklist.)
13.7 Summary
Software verification can be conducted by various techniques such as

code reading, static analysis, symbolic execution, proving correctness
and code inspection.
Code reading is a software verification technique that helps us to read

the code efficiently by inspecting the code and removing the errors from
it.
Static analysis technique helps us to analyse the code without executing

it.
The three types of static analysis are code-based testing tools,

specialised testing languages and requirements-based testing tools.
Symbolic execution is a software verification technique that helps to

analyse the code by replacing real values with symbolic values.
Proving correctness is a software verification technique which is used

for proving the code correct.
Code inspection is a software verification method that helps us to

formally verify the code to detect errors caused due to wrong
programming methods.
Code inspection is conducted in a series of steps, namely, planning,

overview, preparation, inspection meeting, rework and follow-up.
All the software verification techniques help us to verify the program

code effectively.
B1965
Page No. 275
Unit 13
13.8 Glossary
Abstraction of module: It is the specification of problem that has been
extracted from the module which is essential and relevant information.
Peer reviews: It is a face-to-face discussion held between the programmer
and the reviewer.
Walk-throughs: This is an informal code analysis method. In this method,
all syntax errors are eliminated after a module is coded and compiled.

1. What is code reading?
2. Explain static analysis.
3. Describe symbolic execution.
4. What is proving correctness?
5. Describe code inspection.
13.10 Answers
1. Code reading
2. False
3. Errors
4. Static analysis
5. Local programming standards
6. Requirements-based testing
7. Symbolic execution
8. Program counter
9. Hand-execution
10. Proving correctness of a program
11. True
12. Theoretical
13. Code inspection
14. Reader
15. Planning
B1965
Page No. 276
Unit 13
Terminal Questions
13.11 Case Study

An Effective Tool to Identify the Software Bugs
ABC Company is known for developing complex software used in advanced
communications technologies. The program codes are written in C, C++,
Java and SDL, code length being 2 to 2.5 million lines long. The ABC
Company wanted the best testing solution to remove bugs early in the
development life cycle of software.
Challenge:
ABC Company wanted advanced testing solutions to detect and eliminate
software bugs from application code with complex software being
developed. The manager had to find appropriate tools that would assist with
early identification and removal of software bugs from code. This company
was struggling with usual quality issues such as writing bug-free code that
was easy to understand, maintain and extend. The manager looked for tools
that would help them to find defects early, not only source code defects but
also architectural problems, buffer overflows and security problems. There
was a requirement in this company to increase the quality of software that
the organisation company was developing, and increase developers
productivity by freeing them from expensive code reviews and inspections.
Solution:
ABC Company checked static analysis tool that found bugs within a very
short period of time. After analysing the results in detail, the company
concluded that the static analysis tool found more bugs than other tools.
The tool had good user interface and was completely featured tool than the
others.
ABC Companys software development team was very impressed with the
tool for a particular issue. The team had been struggling with a bug in the
B1965
Page No. 277
Unit 13
application that led to an infinite loop occurring under random, special

conditions. Several man-weeks of development effort had already been
allocated in order to track the problem down.
1. What were the issues faced by the ABC Company?
2. Why did ABC Company go for static analysis tool?
References:
Jalote, P. An Integrated Approach to Software Engineering.
Laski, J., & Stanley, W. Software Verification and Analysis.
E-References:
http://openseminar.org/se/modules/184/index/screen.do (Retrieved on
18th May 2012)
B1965
Page No. 278
Unit 14
Unit 14
Capability Maturity Model for Software
Structure:
14.1 Introduction
Objectives
14.2 Five Maturity Levels
Components of CMM
14.3 Key Process Areas (KPAs)
Common features
14.4 ISO 9000 Series of Standards for Quality Management Systems
14.5 Mapping ISO 9001 to the CMM
14.6 Summary
14.7 Glossary
14.9 Answers
14.10 Case Study
14.1 Introduction
In the previous unit, we studied about software verification, wherein we
studied about code reading, static analysis, symbolic execution, proving
correctness of the software and the inspection or review of code for our
software under development.
In this unit, we will study about Capability Maturity Model (CMM), which is
related to the area of software development. This model can be applied as a
generally applicable model to assist in gaining knowledge about the
process capability maturity of organisations in areas such as software
engineering, system engineering, project management, software
maintenance, risk management, system acquisition, information technology
(IT) and personnel management.
We will also study about the levels of CMM. This unit will also familiarise us
with the key process areas of CMM, wherein we will discuss about the
common features of CMM. We will have a brief discussion on the ISO 9000
series of standards for quality management. We will also analyse how to
map ISO 9001 to CMM.
This unit will enable us to use CMM for our software.
B1965
Page No. 279
Unit 14
Objectives:
elaborate the levels of CMM for software
enlist the key process areas of CMM
briefly describe the common features of CMM
14.2 Five Maturity Levels

In this section, we will study about the five maturity levels of CMM. But to
understand it in a better way, we will first understand what CMM is.
CMM can be defined as a unique model of organisational development and
change. It offers very effective guidance to software organisations for
creating programs for process improvement. The CMM comprises five
maturity levels. We can characterise each maturity level by the execution of
several clusters of practices (i.e. process areas) that add to the
development capability attained at that level. According to the SEI (Software
Engineering Institute, Carnegie-Mellon University, USA), Predictability,
effectiveness, and control of an organisations software processes are
believed to improve as the organisation moves up these five levels. While
not rigorous, the empirical evidence to date supports this belief.
Let us briefly discuss about the five levels in CMM, as given in Figure 14.1.
Fig. 14.1: Levels of CMM

B1965
Page No. 280
Unit 14
Level 1: Initial It is the starting point for using a new process. At this level,
the company has no standard process for software development. It is
undocumented and in a state of active change, which tends to be driven in
an unplanned, uncontrolled and reactive manner by users or events. Growth
processes are rarely defined, and sound practices are often neglected to
meet unreasonable schedules. In this level, organisations lack the capability
to meet commitments consistently. No company would like to be assessed
at this level and hence, companies wait for a few years for their processes
to stabilise before they attempt to get the CMM certification.
Level 2: Repeatable As per this second level of CMM, the organisation
creates policies based on software engineering techniques and successful
prior projects. In this, we establish the basic project management
processes, which help in tracking cost, schedule and functionality. Note that
there may not be any similarity between the processes or repetition for all
projects in the organisation. Here, the groups can deal with similar projects
based on their experiences. Thus, we can say that Level 2 attempts to
develop the capabilities of project managers for the following:
o Planning attainable assurance
o Creating control of requirement baselines
This is also not a preferred level of certification for software companies.
Level 3: Defined The basis for Level 3 is the organisations set of
standard processes, which are identified and improved over time. These
standard processes are used to ascertain reliability across the organisation.
You must note that the projects create their distinct processes by the
collection of standard processes according to guidelines of the organisation.
The management of the organisation creates the objectives of the process,
and on the basis of the organisations set of standard processes, ensures
that these objectives are properly addressed.
Only relatively newer companies will announce to the world that they have
been certified at Level 3. Older, established companies would not prefer to
be in this level of certification.
Level 4: Quantitatively managed According to this level, the tasks of
monitoring and controlling an organisation's processes are performed by the
organisation itself through data collection and analysis. Accurate measures
in management can efficiently control the software development attempt. At
B1965
Page No. 281
Unit 14
this level, a goal related to the quantitative quality is set by the organisation,
not only for software process but also for software maintenance. Subprocesses that considerably add to the overall process performance are
selected. We manage these selected sub-processes with the help of
statistical techniques and some other quantitative techniques.
Although software companies aspire to reach Level 5, certification at Level 4
is also a matter of pride.
Level 5: Optimising This level of CMM states that process management
comprises planned process optimisation or process improvement. This level
focuses on repeatedly improving the process performance through both
incremental and inventive technological improvements. Also, we identify the
quantitative process improvement goals for the organisation, revise them
frequently for reflecting the different business goals and use them as criteria
in managing process improvement. We measure and assess the effects of
organised process improvements against the quantitative process
improvement goals. The processes that are defined and the organisations
set of measured processes as well are targets of the improvement activities
that are assessable. Process improvements address common causes of
process difference and take the organisations processes to the next level.
They are identified, evaluated and deployed. Optimisation of the processes
that are quick, compliant and innovative is dependent on the involvement of
an authorised workforce, which is aligned with the business values and
goals of the organisation. The ability of the organisation to quickly respond
to changes and prospects is enhanced by finding ways to hone and share
learning.
As mentioned earlier, software companies endeavour to reach Level 5 as it
represents the highest certificate of process quality. The biggest benefit a
company draws from this Level 5 certification is that it can compete at par in
the global marketplace with all other established giants. It is interesting to
note that a majority of CMM Level 5 companies have their operations in
India.
14.2.1 Components of CMM
We can use a maturity model as a standard for assessment and as an aid to
analyse the maturity software process. For example, for relative assessment
of different organisations, where there is some commonality, the model can
B1965
Page No. 282
Unit 14
be utilised as a base for comparison. Like other models, CMM also has
some components, which include the following.
Maturity levels We can define maturity levels as well-defined levels,
which help in achieving a mature software process.1 The five maturity levels
provide the top-level structure of the CMM. In this structure, the uppermost
(5th) level is a theoretical ideal state where the processes are methodically
managed by an arrangement of process optimisation and non-stop process
improvement.
Process capability It refers to a variety of expected results that can be
attained by implementing software process. It provides a means to foresee
the possible results to be expected from the next software project that the
organisation undertakes.
Key Process Areas (KPAs) This is an important component of CMM. We
can define KPA as a cluster of related activities that, when performed
collectively, aids to attain a set of goals considered to establish process
capability at the maturity level.
Goals This component of CMM recapitulates the key practices of a KPA
and determines whether an organisation or project has effectively
implemented it or not. The goal signifies the scope and purpose of all the
KPAs.
Common features Common features of CMM are aspects which signify
whether the implementation of a KPA is capable, and can be done
repetitively while being sustainable. We can divide it into the following five
features:
o Commitment to perform
o Ability to perform
o Activities performed
Maturity software process: CMM delineates the characteristics of a mature, capable software process.
The progression from an immature, unrepeatable software process to a mature, well-managed software
process is also described in terms of maturity levels in the model.
B1965
Page No. 283
o
o
Unit 14
Measurement and analysis

Verifying implementation
1. CMM is a unique model of __________ and change.
2. Software development successes are repeatable. It is significant to
create a steady environment that aids the repetition of successful
practices. (True/False)
3. At maturity Level 4, developments are concerned with addressing
special causes of ______ and providing statistical predictability of the
results.
4. Common features of CMM are aspects that indicate whether the
implementation of a key process area is effective, repeatable and
lasting. (True/False)
5. At maturity Level 5, processes are concerned with addressing frequent
causes of ________ and altering the process.
Activity 1:
Assume that you are given a project on quality management
implementing CMM in it. Prepare a list of the levels of CMM.
(Hint: The five maturity levels. Refer section no. 14.2)
14.3 Key Process Areas (KPAs)

The previous section familiarised us with the CMM levels and its
components. This section will familiarise us with one of the important
components of CMM, namely, KPAs.
In CMM, the KPAs determine a collection of relevant actions which when
executed collectively accomplishes a set of goals acknowledged as
important for promoting the capability of the process. It contains goals that
must be achieved in order to improve software key practices.
After defining the KPA, you have to set up performance goals or objectives
for each KPA. CMM in general allocates two to four goals per KPA. As
every level of CMM has its own KPAs, the challenge is to accumulate two to
four performance goals of each KPA in your current level. Thus, it is
essential to have well-created KPAs in the current level before you get to
B1965
Page No. 284
Unit 14
the next level. You need to think in terms of the management for the defined
results.
Let us take a look at the levels of CMM and their relative KPAs. This is
As you can see in Figure 14.2, every level except Level 1 has some KPAs,
which signifies the areas requiring improvement for their respective software
processes.
Since KPAs at Level 1 are not discrete, getting to Level 2 is often an
obstacle in moving through CMM. To get to Level 2, an organisation needs
to have procedures that begin to experience repeatable success and
similarly, you begin to eliminate your failures.
Fig. 14.2: Key Process Areas

B1965
Page No. 285
Unit 14
14.3.1 Common features

We will now have a brief discussion on the common features component
of CMM. As discussed earlier, common features can be defined as aspects
that determine whether the execution and institutionalisation of a KPA is
capable, and whether it can be done repetitively while being sustainable.
We organise every KPA into five sections. These sections are called
common features of CMM. Let us have a quick overview of these five
features:
Performance commitment It (also known as commitment to

perform) details the actions that an organisation must perform for
ensuring that the process is created, and will continue. It comprises
practices on policy and leadership.
Performance ability It (also called ability to perform) details the

requirement that must exist in the project or organisation to execute the
software process proficiently. It comprises practices on resources,
organisational structure, training and tools.
Performed activities It (also called activities performed) details the

roles and events necessary to execute a KPA. It comprises practices on
plans, procedures, work performed, tracking and corrective action.
Measurement and analysis It details the need to measure the

processes and examine the measurements.
Verification of implementation It (also called verifying

implementation) explains the steps to ensure that the activities are
performed in line with the process that has been established. It
comprises preparation on re-assessment of management and audits.
6. Performance ability describes the requirement that must exist in the
project or organisation, to execute the software process proficiently.
(True/False)
7. Segmented consumer markets are easier for companies and marketers
to target with advertising and marketing strategies. (True/False)
8. Since KPAs at Level 1 are not discrete, getting to ______ is often an
obstacle in moving through CMM.
B1965
Page No. 286
Unit 14
Activity 2:
Imagine that you have opened a new outlet of fast-food restaurant. List
the steps you would take to implement the key practices that explain the
infrastructure and performances of your restaurant.
(Hint: Key Process Areas)
14.4 ISO 9000 Series of Standards for Quality Management

Systems
In the previous section, we studied about the two important components of
CMM, namely, KPAs and common features. In this section, we will study
about the ISO 9000 series of standards for quality management systems.
The basis of Quality System Requirements (QS) 9000 is the 1994 edition of
ISO 9001, but it comprises added needs that are specific to the automotive
industry. The ISO community of accreditation bodies and registrars
acknowledges these added needs as automotive interpretations. QS-9000
is related to suppliers of the following:
Production materials
Production and service parts
Heat treating
Painting and plating and other finishing services
Many truck companies have accepted QS-9000 and are signatories to the
document. Some other companies in the automotive industry are also
accepting QS-9000 as their supplier quality requirement, and nonautomotive industries are watching the implementation of QS-9000. They
are acknowledging its use as a model for evolving ISO 9001 on the basis of
requirements for their industries. For example, it is the common supplier
quality standard for DaimlerChrysler Corporation, Ford Motor Company and
General Motors Corporation.2
manage2020.com/down/qs9000.doc
B1965
Page No. 287
Unit 14
Standards are essential for ensuring the effective operation and control of
processes, because they define the criteria required to judge the
acceptability of the process capability and product quality. The standard
propels the organisation for putting a quality management system into
action in accordance with the requisites of ISO 9001. Thus, implementation
applies to the use and operation of the management system following its
construction and integration. Also, it is relevant to the routine operation of a
system that is already created, documented and is in perpetual operation.
The following are the quality concepts addressed by these standards:
An organisation should bring about and maintain the quality of the
product or service created, so as to meet the stated or implied needs of
the purchaser.
An organisation should show commitment to its own management that
the expected quality is being achieved and sustained.
An organisation should ensure to the purchaser that the planned quality
is being, or will be, achieved in the product or service given.
The ISO 9000 standard requires the organisation to make sure that the
mandatory information for assisting the operation and monitoring of the
identified processes should be available if required.
The standard requires very few (seven) procedures. These specific,
documented procedures are required for the following:
Document control It is an intrinsic part of every work process

because the inputs to every process pass through a number of stages,
each adding value to result in the success of defined objectives.
Control of records It is a basic part of every work process which is

similar to document control. These include preparation, storage, access,
maintenance and disposal tasks.
Conducting audits It is an activity with a defined objective. Without

the provision of able personnel and an appropriate environment, audits
will not achieve their goals no matter how many times the procedure is
implemented.
Non-conformity control It is a basic element of certain work

processes. The order of tasks is not in the form of a continuing series.
B1965
Page No. 288
Unit 14
The order may be determination, documentation, separation, review,

remedial action and disposal.
Corrective action It forms a part of every process rather than being a

separate process. It is an action in which the methods are diverse but
the outcomes are the same, that is, non-conformity is prohibited from
recurring. Many issues are thwarted from recurring by not implementing
a process, albeit by the designer, the producer, the supplier or a
manager. They identify the crises they had faced the previous time and
do it differently the next time, that is, they learn from their mistakes.
Preventive action This action is similar to corrective actions.

However, preventive actions are implemented. Preventive actions are
built into these processes, and similar to corrective action, they are part
of every process design.
ISO 9001 provides the organisation with guidelines for it to decide what it
needs for the effective operation and control of its processes.
14.5 Mapping ISO 9001 to the CMM

After studying about the ISO 9000 Series of Standards for Quality
Management Systems, we will now study about the mapping of ISO 9001 to
CMM.
There are similar concerns for CMM and ISO 9001 and they are interrelated. It consists of software development and maintenance, which
categorises the minimum requirements for a quality system. CMM caters to
software, while ISO 9001 caters to hardware, software, processed materials
and services. ISO 9001 has 20 clauses which are compared with the
practises in CMM.3 Let us now learn about them.
The comparison is based on an analysis of ISO 9001, ISO 9000-3, TickI and the TickIT training
materials [Lloyds 94].
B1965
Page No. 289
Unit 14
Clause 1: Management Responsibility

o In ISO 9001 It requires the organisation to define, document,
understand, implement and maintain quality. The responsibilities of all
personnel should be specific and monitored. The employees should be
trained and funded. An elected manager certifies that the quality
program is executed and maintained.
o In CMM It addresses management responsibility for quality policy and
verification activities. These are chiefly dealt with in Software Quality
Assurance, both Software Project Planning and Software Project
Tracking, and include activities that identify responsibilities for
performing all project roles. This includes the following:
Recognising accountability for implementing all project roles
Establishing a trained software quality assurance group
Assigning senior management
Clause 2: Quality System
o
In ISO 9001 It requires an organisation to document quality systems,

including procedures and instructions. ISO 9000-34 characterises this
quality system as an integrated process throughout the entire life cycle.
In CMM It deals with quality system activities. The methods that would
be implemented are spread throughout the KPAs in various performed
activities. The explicit events and principles that a software project
would use are specified in the software development plan described in
Software Project Planning. Software Product Engineering involves
defined tasks, and integrated and reliable performance, which syncs
directly with the ISO 9000-3 guidance for interpreting this clause.
ISO 9001 involves the suppliers quality system; it does not include the
connection between organisational support and project implementation.
ISO 9000-3 provides guidelines for applying ISO 9001 to the development, supply, and maintenance of
software.
B1965
Page No. 290
Unit 14
CMM includes all these things. ISO 9000-3, on the other hand, has two
sections on quality planning.
Clause 3: Contract Review
o
In ISO 9001 It requires organisations to review contract to determine

whether the requirements are sufficiently defined, agree with the bid and
can be implemented.
In CMM The organisation must review and document the customer

requirement allocated by the management. It evaluates the attainment of
software through subcontracting as described in Software Subcontract
Management. Contracts may be with an external customer or with a
subcontractor. Since the CMM is restricted to software viewpoint,
customer requirements are beyond the scope of the requirements.
The software organisation (supplier) ensures that the system requirements

assigned to software are standardised and reassessed, and that missing or
uncertain needs are clarified. Since the CMM is linked to the software
viewpoint, the customer requirements are beyond the scope of this KPA.
Software Project Planning explains the progress of a proposal, a report of
work and a software development plan, which are reassessed by the
software engineering group and by senior management, in establishing
external (contractual) commitments.
Clause 4: Design Control
o In ISO 9001 It requires an organisation to establish procedures to
control and verify designs, which include the following:
Planning
Designing activities
Identifying inputs and outputs
Verifying the design
Controlling design changes
ISO 9000-3 declares that the supplier must bring out re-evaluation to
make sure that the requirements are met and design methods are
correctly carried out.
o
In CMM It defines the life cycle activities of requirements analysis,

design, code and test that are described in Software Product
B1965
Page No. 291
Unit 14
Engineering. Planning these actions is explained in Software Project

Planning. Software Project Tracking and Oversight explains
management of these life cycle activities, and Software Configuration
Management describes configuration management of software work
products generated by these activities. Peer review is also included in it.
These reviews act as the KPA which supports the process throughout
the life cycle, from requirements analysis through testing.
Clause 5: Document Control
o In ISO 9001 It requires an organisation to distribute and modify
documents and data.
o In CMM It describes the configuration management practices that are
documented and controlled. The in-depth actions, standards and other
documents are scattered all over the KPAs.
Clause 6: Purchasing
o In ISO 9001 It needs organisations to guarantee that the purchased
products are in line with their specified requirements. This includes the
estimation of probable subcontractors and authentication of purchased
products.
o In CMM It is explained in Software Subcontract Management.
Assessment of subcontractors is in Clause 2 (Quality System), while
acceptance testing of subcontracted software clause is explained in
Clause 12 (Inspection and Test Status).
Clause 7: Purchaser-Supplied Product
o In ISO 9001 It requires that the purchaser-supplied material be verified
and maintained.
o In CMM It describes the use of identifying off-the-shelf or reusable
software as part of development. Integration of off-the-shelf and
reusable software is one of the areas where the CMM is weak. This
clause, especially as expanded in ISO 9000-3, cannot be considered
adequately covered by the CMM.
Clause 8: Product Identification and Traceability
o
In ISO 9001 It requires an organisation to identify and trace a product

during all stages of production, delivery and installation.
B1965
Page No. 292
Unit 14
In CMM It includes the clause chiefly at Level 2 in the perspective of

configuration management, but it states the need for reliability and
traceability between software work products at Level 3.
Clause 9: Inspection and Testing

o
In ISO 9001 It requires that the materials be inspected or verified

before use and that in-process inspection and testing be performed.
Final inspection and testing are performed prior to release of finished
product. Records of inspection and test are kept.
In CMM It explains testing of software product engineering. In-process

assessment in the software sense is addressed in peer reviews.
Clause 10: Inspection, Measuring and Test Equipment

o
In ISO 9001 It requires the organisation to assess the equipment used

to demonstrate conformance be controlled, regulated and maintained.
When test hardware or software is used, it is checked before use and
rechecked at prescribed intervals. The organisation must also perform
final inspection and testing before the finished product is released and
should also keep the inspection and test records.
In CMM It deals with issues surrounding the inspection of incoming

material. This has been explained in Clause 7.
Clause 11: Process Control

o
In ISO 9001 It requires an organisation to describe and hone its

manufacturing processes. This includes implementation of production
under controlled conditions according to documented instructions. If
organisations cannot assess the results of a procedure after the fact, it
must constantly monitor and control the development.
In CMM The specific procedures and standards used in the softwareproduction process are specified in the software development plan. The
definition and integration of software-production processes are
described at Level 2 and the tools to support these processes are
described at Level 3, and Level 4 addresses the quantitative aspect of
control, exemplified by statistical process control. However, an
organisation typically would not have to demonstrate this level of control
to satisfy this clause.
B1965
Page No. 293
Unit 14
Clause 12: Inspection and Test Status

o
In ISO 9001 It requires an organisation to maintain the status of

inspections and tests, for objects, as they shift during various processing
steps.
In CMM It tackles practices on problem reporting and arrangement

status at Level 2 and by testing practices at Level 3.
Clause 13: Control of Non-Confirming Product

o
In ISO 9001 It requires an organisation to control a non-conforming

product that does not satisfy particular requirements and to prevent
unplanned use or installation. ISO 9000-3 maps this concept to clauses
on design and implementation and configuration management.
In CMM It does not specifically address non-conforming products. In

ISO 9000-3, the control issue essentially disappears among a number of
related processes spanning the entire software life cycle.
Clause 14: Correction and Prevention5

o
In ISO 9001 It requires an organisation to recognise the causes of a

non-conforming product. Corrective action is aligned towards the
removal of the causes of definite non-conformities. Preventive action is
concentrated towards the removal of the causes of potential nonconformities.
In CMM Corrective action addresses non-compliance that is

recognised in an audit, be it external or internal. This explanation
compares to the CMMs Level 2 KPA, Software Quality Assurance.
Clause 15: Handling, Storage, Packaging, Prevention and Delivery

o
In ISO 9001 It requires organisations to create and sustain procedures

for handling, storage, packaging and delivery.
ISO 9001-3 quotes this clause verbatim with no elaboration.
B1965
Page No. 294
Unit 14
In CMM It does not cover replication, delivery and installation. It

addresses the creation and release of software products at Level 2, and
acceptance testing at Level 3.
Clause 16: Control of Quality Records

o
In ISO 9001 It requires an organisation to collect and maintain quality

records.
In CMM It includes the practices that define the preservation of quality

records. These records are circulated throughout the KPAs as part of
the activities performed common feature.
Clause 17: Internal Quality Audits

o
In ISO 9001 It requires an organisation to plan and perform audits.

The results of audits are passed onto the management and any
deficiencies that maybe found are corrected.
In CMM It describes the auditing process at Level 2. Auditing practices

help the organisations with the specified standards and procedures.
Clause 18: Training

o
In ISO 9001 It requires an organisation to recognise training needs,

provide training and maintain training records.
In CMM It identifies explicit training needs in the training and direction

practices in the ability to perform common feature. It explains the
common training infrastructure, including maintaining training records, at
Level 3.
Clause 19: Servicing

o
In ISO 9001 It requires an organisation to execute servicing activities

even when such activities are part of a specified requirement.
In CMM It is implemented in software development and maintenance

environments. The methods in CMM do not directly address the unique
features that symbolise the maintenance environment. Organisations
must precisely understand these practices in the development or
maintenance situation.
B1965
Page No. 295
Unit 14
Clause 20: Statistical Techniques

o
In ISO 9001 It requires that organisations must identify sufficient

statistical techniques and use them to verify the suitability of process
capability and product characteristics.
In CMM In CMM, product measurement is included into a variety of

practices within the performed activities common feature. Process
measurement is explained as a division of the measurement and
analysis common feature. Few auditors ask for an organisation-level
historical database and the use of simple statistical control charts.
9. In_________, a designated manager ensures that the quality program
is implemented and maintained.
10. Process measurement is described as part of the measurement and
analysis common feature. (True/False)
11. Inspection and Testing requires that the materials be __________ or
verified before use and that in-process inspection and testing be
performed CMM.
Activity 3:
Suppose that you are working as a Quality Manager in an organisation
and you are given the responsibility of creating the strategic planning
team to monitor the performance of CMM and ISO 9001 in the
organisation. Create a PowerPoint presentation based on mapping ISO
to CMM.
14.6 Summary
Many software organisations have poorly designed processes, which

are operated at high costs and often result in late delivery of projects. A
maturity model helps an organisation to develop and support its
processes. It also helps an organisation to accomplish its work with high
quality and low cost and to control complexity of todays huge systems.
There are five maturity levels of CMM, namely, initial level, repeatable
level, defined level, managed level and optimising level. We also
B1965
Page No. 296
Unit 14
discussed that each KPA is organised into five sections known as

common features.
CMM focuses strictly on software, while ISO 9001 includes hardware,

software, processed materials and services.
ISO 9001 has 20 clauses which can be compared against the practices
in CMM.
14.7 Glossary
Audit: It is an official examination and verification of an organisations
performance.
Benchmarking: It refers to a standard by which something can be
measured or judged.
Business process: It is a collection of related, structured activities or tasks
that produce a specific service or product.
Maturity model: It is a method used to expand and improve an
organisations software development process.

1.
2.
3.
4.
Explain the five-level maturity model.

Explain the components of CMM.
Explain the common features included in KPA.
Explain the procedures involved in ISO 9000 series.
14.9 Answers
1. Organisational development
2. True
3. Process variation
4. True
5. Process differences
6. True
7. True
8. Level 2
9. Management responsibility
10. True
11. Inspected
B1965
Page No. 297
Unit 14
Terminal Questions
14.10 Case Study

Success with CMM 9001
Company:
ABC Software Division, a Fortune 100 information services provider,
delivers products and services like semiconductor system design,
microcomputer systems, software development, network solutions,
consulting and systems integration. It leverages its process expertise to
conduct detailed research on the implementation of CMM Level 5, and on
the use of process automation tools for software process improvement in
the integrated environment.
Challenge:
The clients objective was as follows:
o Analyse ABC Software Divisions experience in the execution of CMM
Level 3 to Level 5, and implement it in their organisation.
o
Study the employment of Software Process Improvement (SPI) tools for

enhanced productivity, better data analysis and corrective action.
Solution:
This research assignment cut across functions to involve professionals from
the quality, delivery and support groups at ABC Software Division. The
research findings were documented to serve as project deliverables,
produced in both English and Japanese.
o Organisations processes for implementation of CMM Levels 3, 4 and 5,
as also the best practices adopted. This included the following: definition
of all key process area (KPAs); relationship between various CMM
levels; goals, benefits and methodology for defining/refining KPAs.
o Road map for transition from ISO 9001 framework to CMM Level 5.
o Organisation structure for CMM implementation, audit process, SQA
facilitation/review process and metrics.
B1965
Page No. 298
Unit 14
SPI tools that could be developed internally or purchased off-the-shelf to

fulfil the requirements of CMM. This included the methodology for tool
selection and deployment, and a study of features of popular
commercial off-the-shelf tools.
Benefits:
A practitioners approach to process improvement presented with a
research focus complemented well with quality journey of ABC Software
Division.
Clarity in the process integration exercise in respect of integration of various
quality frameworks and adoption of process automation.
Significant cost-benefits accrued from the offshore execution of the research
project.
1. What were the challenges faced by ABC Software Division?
2. What were the steps taken by the company to overcome it?
References/E-References
Burwick, Diane M. How to Implement the CMM, .Bps Pub; 2 edition
(March 20, 2001)
Paulk, Mark C., Weber, Charles V., Curtis, Bill, & Chrissis, Mary Beth.
The Capability Maturity Model: Guidelines for Improving the Software
Process, Pearson Education india, (2007)
B1965
Page No. 299
Unit 15
Unit 15
CMM-Based Process Improvement
Structure:
15.1 Introduction
Objectives
15.2 Management Role
Management sponsorship
Commitments and management by fact
15.3 Process Focus
15.4 Useful Processes
15.5 Training
15.6 Risk Management
15.7 CustomerSupplier Relationship
15.8 Peer Reviews
Types of peer reviews
Peer-review process
15.9 Summary
15.10 Glossary
15.12 Answers
15.13 Case Study
15.1 Introduction
In the previous unit, we discussed about the Capability Maturity Model
(CMM) for Software, which provides software organisations with assistance
on how to achieve control of their processes for developing and maintaining
software and how to advance towards a culture of software engineering and
management excellence.
In this unit, we will discuss about the CMM-based process improvement. We
will discuss about management sponsorship, which plays an important role
in such processes. We will also have a brief discussion about commitments
and management by fact. We will analyse the focus of CMM-based process,
which will also help us in analysing the objectives of CMM-based process.
We will also study about CMM-based useful processes in this unit including
the role of training in CMM-based processes. We will also study about the
role risk management plays in CMM-based processes. We will have a
B1965
Page No. 300
Unit 15
discussion on the customersupplier relationships in CMM-based

processes, wherein we will learn about the peer reviews, their types and
process.
This unit will enable us to appreciate the role of CMM-based processes.
Objectives:
After reading this unit, you should be able to:
describe management sponsorship
briefly describe the concepts of commitments and management by fact
elaborate CMM-based process training and useful processes
point out the customersupplier relationship in CMM-based processes
15.2 Management Role

We know that management plays an important role in all fields. So, we will
now discuss about the management role in CMM-based process
improvement by looking into two aspects, namely, management
sponsorship and commitments and management by fact.
Let us first discuss about management sponsorship and how it contributes
to CMM-based process improvement.
15.2.1 Management sponsorship
It is important to understand that obtaining senior management sponsorship
is a crucial component that is required in building the organisational
capability. This is because, you, as an individual, can practice
professionalism and discipline within your area of control. However, when
an organisation as a whole is to change its performance, then its senior
management needs to actively support the change. Effective sponsorship
can be achieved only when there is significant dissatisfaction with the
current status.
Some of the activities of sponsorship involve the setting up of policies and
providing resources for the process work. However, the most important
factor, according to the senior management involved in the strategic
importance of process improvement, is demonstration of support which is to
be achieved by paying attention. Let us look into how paying attention
improves the process. People tend to increase their efforts which in turn
improve the productivity and quality of work.
B1965
Page No. 301
Unit 15
If process improvement is the true priority, then the management will

monitor it closely. It is done by setting aggressive improvement goals. This,
however, requires a long-term commitment to continual process
improvement. CMM-based improvement is most effective when carried out
in a systematic approach. It is mandatory for the individuals involved in the
same to possess good interpersonal skills.
15.2.2 Commitments and management by fact
After discussing about management sponsorship, we will now discuss about
commitments and management by fact.
Management by fact is based on a measurement foundation for most
organisations. To make data analysis useful, you need to first understand
what the data mean. Only then is it possible to analyse the same
meaningfully.
People have a tendency to focus their efforts where the management pays
attention. If management pays attention only to schedule, then the quality is
likely to suffer. Thus, it is the responsibility of the management to ensure
that adequate attention is noticeably paid to all the critical aspects of the
project. This includes aspects that are difficult to measure and not just those
that are easy to measure and track.
You need to design an internal commitment process based on what you
know you can do. It is important for the management to seek worker
feedback when establishing commitments. This is because, once the
workers agree to a set of commitments, even if they are aggressive, they
develop a feeling of personal commitment towards the task. This not just
ensures the timely completion of the task but also instils a sense of
responsibility towards the commitment in the worker.
1. Effective sponsorship can be achieved only when there is significant
dissatisfaction with the status. (True/False)
2. CMM-based improvement is most effective when carried out in a
__________ approach.
3. Management by fact is based on a ____________ foundation for
most organisations.
B1965
Page No. 302
Unit 15
4. If management pays attention only to schedule, then nothing is likely to

suffer. (True/False)
15.3 Process Focus

In the previous section, we studied about the management role and
understood it by looking into two aspects, that is, management sponsorship
and commitments and management by fact. Let us look into the CMMbased process focus.
The first step involved in the CMM-based process focus is the formation of a
Software Engineering Process Group (SEPG). This is done in order to
harmonise process definition, improvement and deployment activities. The
SEPG should be formed early so as to hire staff for the same with both
managerial and technical skills. It is crucial that these individuals possess
good interpersonal skills. This is because the success of SEPG is
dependent on their ability to communicate, teach, negotiate and consult.
One of the reasons for dedicating resources to SEPG is to ensure followthrough on appraisal findings. Many improvement programs have failed
simply because no action resulted from the appraisal findings. Improvement
comes from the following:
Action planning.
Assigning individuals to do the task.
Piloting and deploying improved processes.
Maintaining a management oversight throughout.
It is important to keep in mind that software process improvement occurs in

a business perspective. It might happen that there may be many other
critical business issues being worked on simultaneously; there may even be
a Total Quality Management (TQM) initiative under way. CMM-based
improvement is an application of TQM principles to software. Hence, the
synergy of aligning these initiatives is inevitable. Most of the efficient
software process improvement programs have been operated under the
umbrella of a TQM initiative.
CMM process focuses on the standardisation of the software production,
which provides a standard to assess the maturity of software organisations,
provides an evolutionary framework with the form of ladder to advance the
B1965
Page No. 303
Unit 15
process capability of software organisations and then the software process

maturity will be escalated subsequent to this framework.
The Software Capability Maturity Model (CMM) being one of the most
sought-after standards of the software process management emphasises on
the advancement of the software development process and utilises efficient,
well-organised management and plans to constantly improve and enhance
the quality of software products.
To set up the organisational responsibility for software process functions
that improve the organisation as a whole, software process capability is one
of the focus areas of CMM-based organisational process focus.
5. The first step involved in the CMM-based process focus is the
formation of a ___________________.
6. ___________ is an application of TQM principles to software.
7. CMM process focuses on the standardisation of the software
production. (True/False)
15.4 Useful Processes

Now that we have gained insight into process focus, let us look into some of
the CMM-based useful processes.
To improve the maturity of software processes in terms of an evolutionary
path form ad hoc, chaotic processes to mature, disciplined software
processes; the CMM describes the principles and practises underlying
software process.
During the initial process (Level 1) of CMM, the professionals are driven
from crisis-to-crisis by unplanned priorities and unmanaged change. Such
groups are difficult to recognise. However, over time, they are easy to
identify because they generally do not meet commitments. Senior
management makes operating plans, and when one group does not meet
commitments, the total organisation misses its plan. When new plans are
successively missed, the managements frustration increases. For creative
professionals, the most frustrating part of an organisation is that the same
problem constantly recurs.
B1965
Page No. 304
Unit 15
It is important to realise that the CMM-based software process is complex

and involves a host of various activities, such as:
Planning models Software models can be helpful in making product

plans, but we should handle them with care. If we do not calibrate
models to the particular organisations experience, errors can occur in
varied ranges as shown by experts. When we use models to produce
software cost estimates, we often blindly accept their outcomes and do
not develop the project plan properly. The people in the organisation do
not understand the project, appreciate their roles or feel committed to
the plan.
Once the size and resource estimates have been made, it is necessary
to spread these resources over the planned schedule. The most
frustrating software processes are often caused by poor configuration
management.
The repeatable process After conducting an assessment, the

organisation is in a position to address its key improvement priorities.
The role of the management system is to ensure that projects are
successfully completed. It also needs a continuing management focus
on the progress of each project. The ground work for software project
management is the commitment discipline. This is supported by plans,
estimates, reviews and tracking systems, which focus on ensuring that
the organisation meets its commitments. Commitments are not met by
reviews, procedures or tools; however, they are met by committed
people.
The defined process We can say that a standard is a rule or

foundation for comparison that is used to assess the size, content, value
or quality of an object or activity. In software, two kinds of standards are
used to define the way the software is developed and maintained. One
class of standard describes the nature of the object to be produced,
while the other defines the way the work is to be performed. Procedures
are closely related to standards. There are many different ways to
establish standards for an organisation. A standard is appropriate when
no further judgement is needed. Standardisation makes sense when
items are arbitrary and must be done uniformly or when there is one
clear best alternative. Some standards are essential to the maintenance
of business or technical control. Therefore, we can say that a defined
B1965
Page No. 305
Unit 15
software process provides an organisation with a consistent process

framework while permitting adjustment to unique needs. Some
guidelines on developing and using process architecture are as follows:
o
Establish objectives.
Define the basic process architecture.
Make sure it meets the needs of the project.
Enforce it to an overall process framework.
8. After conducting an __________, the organisation is then in a position
to address its key improvement priorities.
9. In software, three kinds of standards are used to define the way the
software is developed and maintained. (True/False)
10. The ground work for software project management is the ___________
discipline.
Activity 1:
Imagine you are the manager of a software organisation. Explain the
CMM-based process involved in delivering a software product.
(Hint: Refer to Section 15.4, CMM-Based Useful Processes.)
15.1 Training
The previous section familiarised us with the CMM-based useful processes;
so let us now familiarise ourselves with the CMM-based process training.
Documented processes are of little value if they are not effectively
deployed. Training, by means of a broad variety of mechanisms, is crucial to
consistent and effective software engineering and management. The reason
for training employees in an organisation is to develop skills. Apart from
formal class room training, there are various training mechanisms that can
be effective in building skills. The one that needs serious consideration is
the formal mentoring problem.
Inefficient teams can cripple good teams; hence, it is important to provide
management training to all the teams. Individuals are generally promoted to
the managerial levels based on their technical skills. Hence, it is the
responsibility of the organisation to provide such individuals with necessary
B1965
Page No. 306
Unit 15
interpersonal skills. Software organisations are facing challenges to cut

down cost, enhance quality and enhance productivity and customer
satisfaction and also to accelerate access to data and information that will
enable stronger business processes.
The CMM was developed to assist organisations for getting better quality of
their processes through implementation of processes that are mature.
(These processes have a high predictability of results and low risk of
encountering unfamiliar variables or situations.) The CMM-oriented models
are used to measure how much an organisation uses defined processes to
manage some activity.
The training on CMM-based processes must be attended by the belowmentioned list of people:
Data governance professionals
Data custodians
Data architects
Enterprise architects
Data administrators
Business analysts
Project managers
IT professionals
Subject matter experts
The learning objectives of the training include the following:
Understanding the history and the purpose of CMM-based processes.
Learning about the CMM benefits.
Understanding the basic structure of the CMM and related maturity

models.
Understanding the CMM content and structure (key process areas, key
process indicators, levels, and so on).
Developing a basic plan for measuring maturity in the organisation for

data management, process improvement and governance.
Implementing activities within the organisation for CMM and related

maturity efforts.
B1965
Page No. 307
Unit 15
11. Documented __________ are of little value if they are not effectively
deployed.
12. The reason for training employees in an organisation is to _________.
13. The learning objectives of the training do not include learning about
CMM benefits. (True/False)
15.6 Risk Management

In the previous section, we studied about the CMM-based process training.
Let us study about the risk management involved in the CMM-based
process.
We can define risk management as the identification, assessment and
prioritisation of risks. This is followed by synchronised and economical
application of resources to reduce, monitor and manage the probability of
unfortunate events to maximise the realisation of opportunities. The
principles of risk management have been mentioned below:
Create value.
Be an essential part of organisational processes.
Be part of decision making.
Explicitly address uncertainty.
Be specific and structured.
Be based on the best available information.
Be tailored.
Take into account human factors.
Be transparent and inclusive.
Be dynamic, iterative and responsive to change.
Be capable of constant improvement and enhancement.
In case of project management, risk management includes the following

activities:
To plan as to how risk will be managed in the particular project. Plan

should include risk management tasks, responsibilities, activities and
budget.
Maintain live project risk database.
B1965
Page No. 308
Unit 15
Prepare mitigation plans for risks that are chosen to be mitigated.
Summarise planned and faced risks, effectiveness of mitigation activities

and effort spent for the risk management.
Some people in software companies always argue that software project

management is a risk. In one sense, the software CMM is about managing
risk. An attempt is always made to establish stable requirements so that we
can make an early plan to manage things effectively. However, business
changes rapidly and perhaps chaotically. Although processes that help in
managing the risks of a chaotic world can be established, a change needs
to be implemented.
Key processes or systems that are recognised as relevant to the
development effort for risk assessment must be documented along with
appropriate rationale for selection. For processes that dont require risk
assessment, a brief narrative describing the rationale for the decision must
be included in the software. If a contract demands the supplier to maintain a
specific level of maturity in relation to the CMM for software, the minimum
set of key processes identified or risk assessment will be those related with
that level along with any customer imposed tasks.
The new CMM model has elevated risk management to a complete process
area. This is a significant change for those organisations that currently use
the CMM for software. The purpose of risk management is to recognise
potential problems before they occur, to mitigate adverse impacts on
achieving objectives. Risk management is a constant, forward-looking
process, integral to both business and technical management. It
encompasses defining a risk management strategy, identifying and
analysing risks.
14. Software project management is a __________; this is always being
argued by some people in the organisation.
15. The new CMM model has elevated risk management to a complete
process area. (True/False)
16. The purpose of risk management is to _________ potential problems
before they occur, to mitigate adverse impacts on achieving objectives.
B1965
Page No. 309
Unit 15
Activity 2:
Briefly explain the process of risk management in CMM-based
processes.
(Hint: Refer to Section 15.6, Risk Management in CMM-Based
Processes.)
15.7 CustomerSupplier Relationship

In the previous sections, we have understood the focus, training and the risk
management involved in CMM-based processes. We shall look into some of
the customersupplier relationships involved in a CMM-based process in
this section.
Setting up a good, functional relationship with the customer and end-user is
based on open communication and integrity. This requires assistance from
the customer, and the danger of customer irrationality is always preset.
Building good customersupplier relationships is a long-term endeavour, but
if the organisation has (or wants to have) a stable customer base, the
customer must appreciate the complexities of software engineering, just as
the supplier must understand the application domain and business
environment for the software product.
In case of CMM-based processes, the teams do not talk to their customer.
One of the motives behind Software Capability Evaluations (SCE) is the
customers desire for predictable costs and schedules.
15.8 Peer Reviews

Peer review is one of the best kinds of review that you can benefit from. We
can define peer review as a tool for removing defects from the software
product early and efficiently. To spot the defects and areas where changes
are needed, a systematic examination of the software product by the
producers peers is involved. The explicit products that will experience a
peer review are recognised in the projects defined software process and
scheduled as part of the software project planning activities. The CMM
defines the goals of peer reviews to be as follows:
Plan review activities.
Identify and remove software defects early in the process.
B1965
Page No. 310
Unit 15
To execute peer reviews, the CMM requires that the project follow a written
organisational policy. In addition, sufficient resources and funding must be
provided for performing peer reviews on each software product to be
reviewed. Leaders obtain training as to how to lead peer reviews.
Reviewers, who take part, obtain the essential training in the objectives,
principles and methods of peer reviews. Peer reviews are planned and the
plans are executed as per a documented procedure. The data on the
conduct and results are recorded. We can make and use measurements to
determine the status of the peer-review activities. The activities and work
products for peer reviews undergo an audit or group review. This is done by
the software quality assurance group.
Peer reviews are often considered to be expensive and timely and as a
result, we often term them as not being worth the effort. In addition, they are
slow to evolve with a companys software process, and hence are reactive
instead of proactive.
15.8.1 Types of peer reviews
Since we are discussing about the peer reviews, let us have a brief
discussion on the different types of peer reviews. There are several types of
peer reviews currently in use. Each of these is conducted with the purpose
of locating software defects. A few of them involve significant investment
from the project teams, while others include a simple inspection of someone
elses code. The key to obtaining payback on a peer review is to choose the
appropriate method, depending on the magnitude of the project. The
method that we used in the past, to meet the peer-review requirement, has
been the traditional code-walk-through, where the programmer runs the
peers through a program code and justifies their process and data flow
creation. Such meetings are often expensive.
Any process should allow for the five implementation methods that have
been mentioned below. At the same time, these implementation methods
are dependent on project scope and their impact. The scope in software
development varies as drastically as that of constructing building. Let us
briefly discuss the five major peer-review techniques in use, identified from
a study.
Inspections
Structured walk-through
B1965
Page No. 311
Unit 15
Hybrid inspection or walk-through

Desk checking
Round-robin
We will now discuss these types of peer reviews in detail, as shown in

Figure 15.1.
Fig. 15.1: Types of Peer Reviews
Inspections - We can say that inspections are meticulous static

analysis techniques. These techniques involve the training of the
inspection team, well-defined roles that include a facilitator and the
complete measurement of defects encountered. We can cover many
software products including requirements, design, code, user
documentation, test plans and test cases by inspections. Let us have a
look at the advantages of inspection:
o It is the most efficient tool that is used to remove any form of defect.
o The only technique to achieve efficiencies of 75% or more in field
conditions and may be tailored for the project.
The disadvantage is that

o It is expensive and time consuming.
B1965
Page No. 312
Unit 15
Structured walk-throughs - These are static analysis techniques in

which a designer or programmer gives a walk through to the members
of the development team and other concerned parties through
documentation or code; the participants raise questions and make
comments about possible errors, violation of development standards
and other problems. We should find and log defects during the review
with the assigned action items. Upon the closure of the review, we take
a decision on how to proceed. After the review, we resolve the
uncovered errors along with tracking and communicate their status.
The advantages of structured walk-throughs are as follows:
o It is the second most efficient method for removing defects; it may be
tailored to the project.
o It is not as expensive as full inspection.
The disadvantage of structured walk-through is that
o It requires a moderate size group of reviewers.
The hybrid inspection or walk-through - This technique is a

customised approach in which a group of participants, consisting of the
author, the moderator and reviewers perform the review. Reviewers are
wrought in such a way that the anticipated benefits exceed the minimum
necessary support required by the individuals who are asked to
participate. Software review metrics are gathered and monitored so as
to determine the effectiveness of the reviews.
The advantages of this technique are as follows:
o
It requires a small group of reviewers.
The roles may be combined.
It endeavours on finding defects.
The disadvantage of this technique is that

o
It loses effectiveness if too much analysis is done on defect

evaluation.
Desk checking - This is a camouflaged review and debugging

methodology carried out by individual programmers and analysts who
were involved in the software product creation. Errors are found and
logged during the review.
B1965
Page No. 313
Unit 15

o It is inexpensive.
o It is easy to schedule and complete.
The disadvantages of this technique are as follows:
o It is typically the least effective review method.
o The effectiveness depends largely on the reviewer.
The round-robin review - This technique is a process of desk checking

by multiple peers in a chronological manner. The primary checker
makes his/her review, identifies and logs errors, then passes the folder
to the next reviewer who performs the review adding and logging any
additional error. This continues until all the reviewers have participated
and the folder is returned to the author.
o It is more efficient than simple desk checking.
o Multiple reviewers are involved.
o Roles can be assigned, typically a lower cost than other review
techniques.
The disadvantage of this technique is that
o It is not efficient as inspections.
15.8.2 Peer-review process

Now that we have understood the different types of peer reviews, let us look
into the process involved in peer review. In order to locate and remove the
software defects during the early stages, the organisation needs to ensure
that the steps provided below are followed. Let us look at these steps:
1. Identifying which software work products are to be reviewed.
2. Choosing the appropriate peer-review technique by weighing the
software work products scope and business impact with the amount of
time worthy to be spent on a peer review.
3. Documenting the peer-review plan, schedule and types.
4. Publishing the peer-review schedule during the project planning stage.
B1965
Page No. 314
Unit 15
17. ______________technique is a process of desk checking by multiple
peers in a chronological manner.
18. Which peer review is called as a concealed review?
19. Identification of the software products that are to be reviewed is the first
step in the peer-review process. (True/False)
Activity 3:
Suppose you have to conduct a peer review of a CMM-based process
in a software company. Briefly explain the process of peer review in
CMM-based processes.
(Hint: Refer to Section 15.8.2, Peer-review process.)
15.9 Summary
CMM-based improvement is the most effective systematic approach to

software process improvement.
Management by fact is a paradigm shift for most organisations which

must be based on a measurement foundation.
Management sponsorship is the most important element in the creation

of organisational capability. Commitments and management by fact play
an important role in every process, irrespective of whether it is a CMMbased process or not.
The main focus of CMM-based processes is standardisation of software

production. CMM-based processes are often difficult to understand.
Training is extremely important in CMM-based processes.
Software project management is always a risk from a practical

standpoint. It is prudent to minimise this risk by attempting to follow
CMM-based processes.
Building good customersupplier relationships is a long-term endeavour,

but if the organisation has (or wants to have) a stable customer base,
the customer must appreciate the complexities of software engineering,
just as the supplier must understand the application domain and
business environment for the software product.
B1965
Page No. 315
Unit 15
Peer review is the best type of review. Inspections, structured walkthrough, hybrid inspection, desk checking and round-robin review are
some of the types of peer reviews practiced by the software
organisations.
15.10 Glossary
Paradigm: A set of forms all of which contain a particular element.
Total Quality Management (TQM): A method by which management and
employees can get involved in the continuous improvement of the
production of goods.

1. Describe the CMM-based useful processes.
2. Briefly explain about the CMM-based process training.
3. Briefly explain risk management in CMM-based processes.
4. Explain the concept of peer reviews.
5. Explain in detail the types of peer reviews.
15.12 Answers
1. True
2. Systematic
3. Measurement
4. False
5. Software Engineering Process Group (SEPG)
6. CMM-based improvement
7. True
8. Assessment
9. False
10. Commitment
11. Processes
12. Develop skills
13. False
14. Risk
15. True
16. Recognise
B1965
Page No. 316
Unit 15
17. Round-robin review

18. Desk checking
19. True
Terminal Questions
15.13 Case Study

Improving the Quality of Software Development Process
XYZ Technologies are amongst the largest global IT services and product
engineering services. XYZ makes an ideal partner for organisations looking
at transformational IT solutions because of its core capabilities, vast human
resources, commitment to quality and the global infrastructure to deliver a
wide range of technology and business consulting solutions. XYZ is the
forefront of technological and business co-innovation and invention
disclosures.
Challenge:
A need for high degree of requirements was there along with ever-changing
requirements. The already existing requirement was not strong enough to
handle this. There was a soaring degree of post release defects handled by
the support team which was not being fed back to the development team.
The review process was also not sufficient enough to analyse the captured
review data. Any process adding-up or process improvement initiative was
looked upon as a cost to the product life cycle.
Response:
An early assessment was done to analyse the gaps in the existing system.
In project planning, new project management roles were defined. The
organisation focused on defect management rather than defect prevention.
A methodology for tracking effort was laid down and a tool was created to
implement track efforts. A new estimation methodology was also drafted.
B1965
Page No. 317
Unit 15
The XYZ consultants provided the necessary training and mentoring to the
process action team members as well as the practitioners.
The business benefits include that the specific pain areas identified by the
client were addresses and new processes were defined. The XYZ
consultants also identified gaps in the existing process with respect to
CMM-level requirements that helped the client in drawing up the future road
map.
1. Explain in detail the steps taken by XYZ Technologies to improve the
quality of the entire software development process.
Hunter, R. B. Process Improvement in Quality Management Systems by

Software Process Improvement, IEEE Computer Society, (2001)
Oivo, M., & Seija. Product Focused Software Process Improvement,

Springer- Verlag Berlin Heidelberg New York.(2002)
B1965
Page No. 318
Unit 16
Unit 16
Software Quality Assurance
Structure:
16.1 Introduction
16.2 Software Quality Assurance
16.3 Quality Concepts
16.4 Quality Movement
16.5 Reviews
Software review
Formal Technical Review (FTR)
16.6 Software Reliability
16.7 Background Issues
16.8 Software Quality Assurance Activities
16.9 SQA Plan
16.10 Summary
16.11 Glossary
16.13 Answers
16.14 Case Study
16.1 Introduction
In the previous unit, we discussed about Capability Maturity Model (CMM)based process improvement. We analysed that CMM-based improvement is
most effective within a systematic approach to software process
improvement.
In this unit, we will discuss about Software Quality Assurance (SQA),
wherein we will study about the standards and procedures of quality
assurance. We will also study about the various concepts related to quality
and the quality movement. We will also have a brief discussion on software
reviews and Formal Technical Reviews (FTRs). We will also study about the
tools used for formal technical reviews. This unit will also familiarise us with
software reliability. We will also analyse the background issues, and
activities related to quality assurance.
This unit will enable us to understand how to go about the task of software
quality assurance of a software product.
B1965
Page No. 319
Unit 16
Objectives
After reading this unit you should be able to:
explain quality concepts and quality movement
describe software reviews and formal technical reviews
enlist SQA activities
describe the SQA plan
16.2 Software Quality Assurance

We will first understand the meaning of Software Quality Assurance (SQA).
We often use the word quality and we know that quality can be good or
bad. Literally, quality assurance refers to the assurance of quality. Thus, we
can say that SQA means assurance of high software quality. It is a
combination of a means of monitoring the software engineering processes
and methods that are used to ensure quality. We can define SQA as a
planned and systematic approach to the evaluation of the quality and
solidarity to software product standards, processes and procedures. The
main role of SQA is assuring that standards and procedures are adhered to
and are followed all the way throughout the software development life cycle.
Quality assurance approval points are incorporated in the software
development and control processes, whereas an SQA evaluation of the
product may be done in connection to the applicable standards.
The two key principles that characterise SQA are the following:
Fit for purpose, that is, the product should be suitable for the intended
purpose.
Right first time, that is, mistakes should be eliminated.
You must note that SQA is a collection of activities like monitoring the
quality of raw materials, products and components, services linked to
production, management and inspection process. We can say that SQA is
an activity that gets more priority than just testing the quality aspects of a
product, service or facility; it also analyses the quality to ensure that it
conforms to particular requirements and complies with established plans
related to the project.
Standards and procedures
In case of software development, establishment of standards and
procedures is critical, since a framework is provided by the standards
B1965
Page No. 320
Unit 16
through which the software evolves. These standards are documentation

standards (standards related to the documentation of the project), design
standards (standards that indicate the type and content of the design of the
product) and code standards (standards that specifies the coding language
of the project). The software products are compared with established
standards. To develop software, procedures and standards, we need to
establish prescribed methods. The role of SQA is to make sure that the
existence and adequacy of these prescribed methods and standards are
proper in place. We know that a plan is important for every project.
Standards and procedures are also significant for every project as they add
value to the software project.
The two important bodies of quality standards are the Malcolm Baldrige
assessment and ISO 9000. We can define ISO 9000 as a set of standards
of quality management. ISO maintains these standards and certification
bodies administer them. ISO 9000 standards need the procedures that are
documented and cover all the parts of the organisation.
1. The software products are compared with standards which is a
traditional criterion. (True/False)
2. To develop________, procedures and standards establish the
prescribed methods.
3. Standards and procedures add value to the software project.
(True/False)
4. The two vital bodies of quality standards are the ________
___________ assessment and ISO 9000.
Activity 1:
Suppose you have been given an opportunity to be a SQA Engineer.
Which principles of SQA you will follow?
(Hint: Refer to Section 16.2, Software Quality Assurance.)
16.3 Quality Concepts

In the previous section, we studied about SQA and its standards and
procedures. Now we will study about certain quality concepts such as
B1965
Page No. 321
Unit 16
quality control, quality assurance and cost of quality. To understand these

concepts in a better way, we will first need to study the concept of quality.
Quality
We can define quality as a concept that aims at meeting the customers
requirements at all times in terms of factors such as cost, service and the
schedule of delivery. In the same manner, we can define software quality in
terms of factors such as failures, reliability and customer satisfaction.
We can say that a software product is of good quality, if:
Few failures occur, when it is used by the customer.
It is dependable, that is, reliable, which means that it rarely fails when
used by the customer.
It satisfies the needs of a huge number of customers.
Quality Control (QC)
We can define the concept of QC as a set of activities, namely, inspection of
the software product, review and testing the software product that is used
throughout the software process. The main focus of QC is on the techniques
that are operational, and on the activities that are used to meet and check
the quality requirements. Implementation of QC needs procedures,
practices and resources, which comprises the following:
A training program.
Policies and standards.
Review and audit procedure.
Dedicated and trained employees.
A program for measurement.
A process for planning.
Effective techniques and tools for testing.
Quality Assurance (QA)
We can define QA as a process of checking whether the product or service
that is being developed meets the requirements of the customer or not. QA
plan must be prepared beforehand. We know that QA covers all aspects
influencing the product or service quality, either individually or collectively.
Cost of quality
We can define this quality concept as the total cost incurred in maintaining
the quality of a product that meets the customers requirements. Cost of
quality includes three types of costs:
B1965
Page No. 322
Unit 16
Costs of prevention We can define these costs as the total cost of

activities that are undertaken for preventing bad quality. Examples are
costs of surveys for analysing supplier capabilities, costs incurred in
making quality plans, and so on.
Costs of appraisal We can define these costs as the sum of costs
that are related to the measurement, evaluation or trial of products or
services for assuring conformance to the standards of quality and the
requirements for good performance. Examples are costs of in-process
or final testing, costs incurred in the audits process, and so on.
Costs of failure We can define such costs as the aggregate costs
that result from those products or services that do not conform to the
needs of the customer. These costs may occur either before the delivery
of the product or service, or after the delivery of product or service.
Examples are costs of rework, costs of warranty claims, and so on.
5. Implementation of _____ needs procedures, practices, and resources.
6. Cost of failure may occur either before the delivery of the product or
service, or after the delivery of product or service. (True/False)
7. Costs of prevention are the total costs of activities that are particularly
for __________ bad quality.
8. QA plan must be prepared beforehand. (True/False)
16.4 Quality Movement

In the previous section, we discussed about the quality concepts. In this
section, we will discuss about the quality movement.
First, you must note that the movement of quality is not bound to any
specific industry. In the last few decades, there has been a more targeted
approach towards quality. The quality movement was established in North
America in 1940 and has grown and expanded since then having developed
through many milestones like quality circles and quality management.
Today, organisations such as the National Quality Institute (NQI) and the
American Society for Quality (ASQ) continue to advance individual,
organisational and community excellence through quality improvements,
learning and knowledge exchange.
B1965
Page No. 323
Unit 16
As per Gregory Watson, former president of ASQ, Total quality movement

is superior due to the reason of what we have studied, as initiatives have
been implemented. Motivation for performance excellence and business
results is the next focus for quality. We need to synthesize our efforts and
continue to build upon our quality book of knowledge.
In 1954, Dr. Joseph M. Juran stressed the importance of systemsthinking
that starts with product designs, prototype testing and accurate process
feedback. A move from Statistical Quality Control (SQC) (a term used to
describe the set of statistical tools used by quality professionals) to Total
Quality Control (TQC) conveys the importance of quality to customers.
In 1968, Kaoru Ishikawa, one of the fathers of TQC in Japan, had outlined
the elements of TQC management. They are as follows:
Quality comes first, not short-term profits.
The customer comes first, not the producer.
Decisions are based on facts and data.
Management is driven by cross-functional committees covering product
planning, production planning, purchasing, manufacturing and sales and
distribution.
One of the TQC methodologies developed in Japan is referred to as the
Ishikawa or Cause and Effect diagram, which is shown in Figure 16.1.
Fig. 16.1: Cause and Effect Diagram
As per Figure 16.1, materials frequently differ, when sources of supply or

size requirements vary. Equipment or machines also operate in a different
way based on variations in their own parts and they operate sufficiently for
B1965
Page No. 324
Unit 16
only part of the time. Processes or work methods have even superior
variations. Finally, measurement also varies.
9. In _____ the quality movement was established in North America.
10. One of the TQC methodologies developed in Japan is referred to as
the _________.
11. According to cost and effect diagram, measurement also varies.
(True/False)
16.5 Reviews
In the previous section, we discussed about the concept of quality
movement. In this section, we will discuss about software reviews. To start
with, let us first discuss about reviews. We know that generally reviews are
conducted to detect errors and correct them.
We can classify reviews into five types, namely, code review (review of
source code of the computer), technical review (review for examining the
suitability of the software product for its defined use), inspection (simple
review to find defects), walk-through (review, in which people ask questions,
and have a walk-through of the software product) and software review
(review of the software).
We can define software review as a process or a meeting during which a
software product is screened by project personnel, managers, users,
customers, user representatives or other concerned parties for comment or
approval.
If we talk about a software product we can refer to it as a technical
document or partial document, produced as a deliverable of a software
development activity. This may consist of documents such as contracts,
project plans and budgets, requirements documents, specifications,
designs, source code, user documentation and other types of specialist
work product.
16.5.1 Software review
We can consider software review as a process that is industry-proven, and
is used in the improvement of quality of the software product and reduction
in the time and costs of software development life cycle.
B1965
Page No. 325
Unit 16
We can divide software reviews into three categories. They are as follows:
Software peer reviews The author of the work product or one or
more colleagues of the author conduct these reviews for evaluating the
technical content and/or quality of the work.
Software management reviews Management representatives
conduct these reviews for evaluating the status of work done and for
taking decisions regarding downstream activities.
Software audit reviews Persons who are external to the software
project conduct these reviews for evaluating compliance with
specifications, standards, contractual agreements or other criteria
related to software reviews.
16.5.2 Formal Technical Review (FTR)
After discussing about software review, we will now discuss about another
type of review called formal technical review.
The term software inspection is sometimes used interchangeably to mean
FTR. Technical reviews must be done by a team of members. The
document is reviewed by the reviewer and also the person who prepares it.
The reviewer and the author of the document sit together and do the review
of the document.
To arrive at a technically superior version of the work, products must be
reviewed. FTR comes into the picture whenever there is a recommendation
for doing so, if any modification has been done, or there has been an
introduction of alternative methods.
Now, let us have a look at the participants whose inclusion is recommended
by IEEE 1028 to fill the following roles while performing a technical review.
The decision maker This is specially meant for the team that requires
mandatory technical review. This determines if the review objectives
have been met or not.
The review leader He/she is accountable for performing
administrative tasks pertaining to the review, making sure decorum is
maintained, and ensuring that the review meets its objectives.
The recorder He/she identifies anomalies, action items, decisions and
suggestions provided by the review team.
Technical staff They are active participants in the review and
evaluation of the software product.
B1965
Page No. 326
Unit 16
Management staff They may participate in the review for the purpose
of culling out issues that require management intervention.
Customer or user representatives They may fill roles determined by
the review leader prior to the review.
Tools for formal technical review

As we are discussing about FTRs, let us have a look at some tools that
support the FTR.
Code striker It is a Perl CGI script that supports collaborative code
review.
Instant QA It inspects applications for critical and failure-causing
defects.
Review Pro It is a commercial tool developed by Software
Development Technologies Corporation. This runs on windows and
UNIX platforms.
Check mate It enables a software inspection group to automatically
inspect C and C++ source code against predetermined coding policy.
Check mate is available for all windows platforms with UNIX/VMS.
Asynchronous/Synchronous Software Inspection Support Tool
(ASSIST) It is a common tool designed to permit the enforcement and
support of any inspection process.
12. A __________ is a process or a meeting during which a software
product is screened by project personnel, managers.
13. Software audit reviews are conducted by the persons who are external
to the software project. (True/False)
14. In case of software management ________, management
representatives conduct these reviews for evaluating the status of work
done.
15. The _________ is specially meant for the team that requires
mandatory technical review.
16. Code striker is a _____________ script that supports collaborative
code review.
17. _______ inspects applications for critical and crash causing defects.
18. Check mate is available for all windows platforms with ____________.
B1965
Page No. 327
Unit 16
19. The recorder determines anomalies, action items, decisions and

suggestions done by the review team. (True/False)
Activity 2:
Suppose you are given a task to review software. Enlist the types of
software reviews you can opt for doing the same.
(Hint: Refer to Section 16.5.1, Software review.)
16.6 Software Reliability

In the previous section, we discussed about FTRs. In this section, we will
revisit the concept of software reliability as studied in Unit 7Software
Reliability.
We can define software reliability as the chance of failure-free software
operation for a predetermined period of time in a proper environment.
Software reliability is an important factor affecting system reliability.
We can classify the software reliability techniques into two categories, as
Fig. 16.2: Software Reliability Techniques
Trending reliability techniques These reliability techniques refer to

the techniques that trace the failure data generated by the software
B1965
Page No. 328
Unit 16
system for evolving a reliability operational profile of the system over a

given time limit. These reliability techniques are more suitable for
software of a system. We can further classify these techniques as:
o Error seeding We use this technique for estimating errors in a
program. This technique uses multistage sampling in which we
classify the errors into primitive and seeded errors.
o Failure rate We use this technique for studying the rate of failure
of a program at the failure intervals.
o Curve fitting We use this technique for studying the relationship
between the complexity of software and the total number of program
faults or the failure rate. We do so with the help of statistical
regression analysis.
o Reliability growth We use this technique for measuring and
predicting the amendment of the programs related to reliability via
the testing process.
Predictive reliability It refers to the reliability that allocates
probabilities to the operational profile of a software system. This
reliability technique is more suitable for the hardware of a system.
20. _________technique is used for estimating errors in a program.
21. Trending reliability techniques are more suitable for ________ of a
system.
22. Predictive reliability technique is more suitable for the hardware of a
system. (True/False)
16.7 Background Issues

In the previous section, we studied about the concept of software reliability.
In this section, we will study about the background issues related to quality
assurance.
We know that the most essential activity for any business that produces
products to be used by others is quality assurance. Prior to the twentieth
century, the sole responsibility of the craftsperson who built a product was
quality assurance. In 1916 at Bell Labs, introduction of the first formal
quality assurance and control function took place which was swiftly spread
B1965
Page No. 329
Unit 16
across the manufacturing world. More formal approaches were suggested

during 1940.
Today, almost each and every organisation has mechanisms to ensure
quality in its products. In fact, explicit statements of an organisations
concern for quality have become a marketing joy during the past few
decades.
The record of quality assurance in software development goes hand in hand
with the record of quality in hardware manufacturing. It was in military
contract that software standards for quality assurance for software were
introduced. In more precise terms, we can define software quality as a
planned and systematic pattern of actions that are needed to ensure high
quality in software. The implication of software is that several members of
the development team have SQA responsibility. These include software
engineers, project managers, customers, salespeople and the individuals
who serve within an SQA group.
The SQA group serves as the customers in-house representative. This
means the people who execute SQA must look at the software from the
customers point of view.
23. The ________ group serves as the customers in-house
representative.
24. Today, almost every organisation has mechanisms to ensure
___________in its products.
25. The record of __________in software development goes hand in hand
with the record of quality in hardware manufacturing.
16.8 Software Quality Assurance Activities

In the previous section, we discussed about the background issues related
to quality assurance. In this section, we will discuss about software quality
assurance activities.
We know from the previous sections that SQA is conducted with a variety of
tasks linked with two different constituencies. These two different
constituencies are:
Software engineers who perform the technical work.
B1965
Page No. 330
Unit 16
SQA group that is responsible for quality assurance plans, oversight,

record maintenance and analysis and reporting.
Software engineers address quality by applying solid technical methods and

measures, conducting FTRs and performing well-organised software
testing.
SQA consists of a set of activities that address planning, record keeping,
analysis and reporting of quality assurance. Note that individual SQA groups
perform these activities. Let us have a quick overview of these activities.
Build up SQA plan for the project This is the first activity of SQA.
We have to create a plan for the software project. This plan covers the
identification of the evaluations to be carried out, audits and reviews to
be carried out, applicable standards to the project, error reporting and
tracking procedures and the documents which the SQA group has to
generate.
Take part in the software process description development of the
project This stage involves the software team picking out the software
process which is to be carried out. SQA group reviews this software
processs description.
Review In this stage, the software team reviews different activities of
software engineering such as analysis, design, construction, verification
and management to check their agreement with the process which was
defined in the previous activity.
Audit In this stage, SQA group also checks that mistakes have been
corrected and reports the result to their manager at specified intervals of
time.
Review for deviations In this stage, SQA group makes sure of the
documentation of the deviations occurring in the software project plan,
process description and applicable standards.
Recording In this stage, the SQA team records the non-compliance
items (items which do not conform to the project details) with evidence,
until they are resolved. The team also reports about non-conformities to
the manager.
B1965
Page No. 331
Unit 16
26. Software engineers address quality by applying solid technical
methods and measures, conducting formal technical reviews and
performing well-organised software testing. (True/False)
27. In _______, SQA group also checks that mistakes have been corrected
and reports the result to their manager at specified intervals of time.
28. While reviewing for deviations, SQA group makes sure of the
documentation of the deviations occurring in the software project plan,
process description and applicable standards. (True/False)
16.9 SQA Plan

As we are now familiar with the QA activities, let us study about SQA
planning, which is an important aspect of SQA. Depending on how well the
planning is done, the SQAs complete operation is estimated.
In smaller businesses, planning might not actually indicate the flow of SQA.
But in case of larger businesses, SQA planning plays the main role. Without
planning, each component or department that functions on the application
will be affected and will not function. We can say that SQA planning is not
only a document that describes who gets to do a particular task but also
includes different stages in the SQA plan.
In case of smaller organisations, planning may be limited to the particular
stage of the application. But, when the scenario changes, its only through
planning that everyone will know where they are currently and where they
are headed towards in terms of SQA. Let us have a look at what all we can
include in a SQA plan.
SQA plan content - An SQA plan is a detailed description of the project
and its approach for testing. We can divide an SQA plan into four phases,
as per certain standards (IEEE to be more specific). These four phases are:
SQA plan for software requirements In this first phase, the activities
connected to software requirements are written in detail. During this
phase, the team creates steps and phases on how the software
requirements are analysed. To ensure that the plan works out, the team
can refer to additional documents as well.
SQA plan for architectural design In this phase, the team analyses
in detail the preparation of the development team for detailed design of
B1965
Page No. 332
Unit 16
the plan. This stage is a rough presentation of the program, but it still
has to go through meticulous scrutiny before reaching the next stage.
SQA plan for detailed design and production This phase handles
the quality assurance plan for detailed design and actual product and is
probably the lengthiest among all phases. The tools and their
approaches are written by the SQA team in detail as per the plan. The
team starts planning on the transfer phase as well.
SQA plan for transfer The final stage is the QA plan for transfer of
technology to the operations. The process through which transfer of
technology through training and support are monitored as per the QA
plan.
29. In smaller businesses, planning might not actually indicate the flow of
SQA. (True/False)
30. The final stage of the SQA plan content is the QA plan for _________
of technology to the operations.
31. SQA plan can be divided into _____ phases.
Activity 3:
Imagine you are the manager of a software organisation. Design an
SQA plan to assure the quality of the product.
(Hint: Refer to Section 16.9, SQA Plan.)
16.10 Summary
SQA is a process of verifying whether the software product or service
meets the requirements of the customer or not.
There are three main quality concepts, namely, quality control, quality
assurance and cost of quality.
Software reviews are an important means of ensuring statistical quality
assurance. There are three types of software reviews, namely, software
peer reviews, software management reviews and software audit
reviews.
B1965
Page No. 333
Unit 16
FTRs or walk-throughs are another method of review where the author,

reviewer and other designated personnel come together and conduct
the review process jointly.
Software reliability helps us in analysing how much we can rely on
software. There are two types of software reliability techniques, namely,
trending reliability techniques and predicting reliability techniques.
SQA activities include building up the SQA plan for the project, taking
part in the software process description development of the project,
reviewing, auditing, reviewing for deviations and recording.
16.11 Glossary
Anomalies: An occurrence of the object that is strange.
IEEE: It is the worlds leading technical professional association for industrybased standards.
Statistical Regression Analysis: Techniques for modelling and analysing
different variables.

1.
2.
3.
4.
5.
Describe the concept of Software Quality Assurance.

Briefly explain quality concepts.
What are software reviews? Briefly explain.
Describe the tools used in case of formal technical reviews.
Briefly explain the SQA plan.
16.13 Answers
1. True
2. Software
3. True
4. Malcolm Baldrige
5. Quality control
6. True
7. Preventing
8. True
9. 1940
B1965
Page No. 334
Unit 16
10. Ishikawa or Cause and Effect diagram

11. True
12. Software review
13. True
14. Reviews
15. Decision maker
16. Perl CGI
17. Instant QA
18. UNIX/VMS
19. True
20. Error seeding
21. Software
22. True
23. SQA
24. Quality
25. Quality Assurance
26. True
27. Audit
28. True
29. True
30. Transfer
31. Four
Terminal Questions
16.14 Case Study

A Perfect Example of Achieving Product Quality
XYZ Technologies is a world renowned antivirus development company.
The company is headquartered in Lithuania. XYZ Technologies has several
companies on the group with more than 300+ specialists all over. The
services of XYZ Technologies are successfully used by all industry experts,
B1965
Page No. 335
Unit 16
leaders and IT start-up companies. They are able to do complex, scienceintensive projects with a lot of science and innovations involved, as well as
specialised projects.
One of the problems with which a client approached XYZ Technologies was
to perform QA activities on one of their products. The product was of webbased and was built on the advanced technologies.
The primary objective was to perform meticulous testing to make it ready for
launch within a scheduled timeline.
Challenge:
1. The client wanted a cost-effective and experienced input to boost their
QA work simultaneously with the deadlines.
2. The team had to get domain knowledge and product knowledge in the
absence of documentation.
3. Build a strong and efficient framework to communicate with the
development team as the task was time critical.
Response:
The XYZ team gathered business domain knowledge and product
understanding while spending strong 2 weeks with the development and
management team.
A communication framework development for bug reporting, build-update
was covered in the 2-week onsite and offsite effort. This was very essential
to integrate QA model developed by the XYZ team as per the clients
development team to minimise work and time together.
Actual strength in the model lies in its flexibility and flawless integration with
the client activities while completing the QA tasks remotely. This resulted in:
1. Elimination of the fixed costs of having a complete QA department.
2. Increase in the profits through the savings.
By combining the testing expertise with the development expertise of client,
several milestones were achieved effectively and on time. The quality team
of XYZ added substantial value to the product by giving suggestions in
cases of improvements in process flow, business flow and feature usability.
Thus, the XYZ team successfully avoided the cost overrun with a
satisfaction level regarding both product quality and services to the client.
B1965
Page No. 336
Unit 16
1. Briefly explain the challenges faced by XYZ and also the measures
taken by them to achieve the challenges.
References:
Gordon Schulmeyer, G. Software Quality Assurance. Artech House,
Incorporated, 2008
Granato, G. E. Data Quality objectives and Criteria for Basic
Information, Acceptable Uncertainty and Quality Assurance, U.S.
Department of the Interior, U.S. Geological Survey, 1998.
E-References:
http://www.scribd.com/doc/13926561/Quality-Concepts (Retrieved on
18th May 2012)
http://www.wisegeek.com/what-is-quality-assurance.htm (Retrieved on
18th May 2012)
____________________
B1965
Page No. 337

SE

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SE

Uploaded by

Copyright:

Available Formats

Software Engineering

Revised Edition II: Spring 2010

Sikkim Manipal University

Mr. Pankaj Khanna

Mr. Shankar Jagannathan

Mr. Abraham Mathew

Dr. T. V. Narasimha Rao

Ms. Sadhna Dash

Ms. Ramya S Gowda.

Unit 3: Agile Development Methodology

Unit 9: Analysis Concepts and Principles

Unit 1 Software as a Product and Software Engineering

appreciate software holistically

describe the evolution of software engineering in to an important

differentiate between managing software projects and managing any

explain the dual nature of software as a product and as a process

differentiate between software programs and software products

list the six quality characteristics of software as defined by ISO/IEC 9126

describe the concept of product line engineering

1.2 The Rationale for a Software Engineering Discipline

of time. However, such learning is often insufficient as they do not impart a

Personal productivity software (e.g. Microsoft Excel)

Presentation software (e.g. Corel Draw)

Graphics software (e.g. MS Office Picture Manager)

CAD/CAM software (e.g. AutoCAD)

Specialised scientific applications (e.g. SPSS)

Software for specific industries or verticals (pharmaceutical industry,

Another method of classifying software would be as follows:

System software (e.g. UNIX, Windows)

Real-time software (e.g. Satellite Imaging Application)

Business software (e.g. Siebel CRM)

Engineering/scientific software (e.g. CAD/CAM)

Embedded software (e.g. Cell phones)

Personal Computer software (e.g. Word processors, DBMS, multimedia)

Artificial Intelligence software (e.g. software based on Data Mining,

Web applications (e.g. Python, Ajax)

Despite the multiple ways in which software can be classified, we need to

Sikkim Manipal University

1.4 Software Engineering

4. US Department of Defence installed the Airborne Self-Protection

8. The Institute of Electrical and Electronics Engineers (IEEE), regarded

Hardware is manufactured whereas software is engineered.

Hardware performance reduces over time due to the snowballing effects

Hardware production is based on assembly-line production whereas

Hardware translates into a physical object whereas software is virtual.

Unlike hardware, spare parts are not available for software.

A typical hardware component is discarded in an environment-friendly

Sikkim Manipal University

Example 1: In todays software, the Graphical User Interface (GUI) is built

The description of performance, design, functionality and interfaces

The response of the software system to different situations must be

The conformance about the software standard followed must be

Labelling of details related to tables, figures, terms definitions,

The requirements must be traceable, so that one can trace the

The requirements must be verifiable against the specifications.

1.4.2 Objectives of software engineering

Satisfy user requirement Understanding the needs and requirements

High reliability A software product delivered to the customer must be

Sikkim Manipal University

Low maintenance Maintenance of a software product is done when

Delivery on time A systematic approach needs to be adopted to

Low production costs The software product must be affordable/cost

High performance The developed software product must have an

Ease of reuse The software product must be user-friendly.