ALAGAPPA UNIVERSITY

[Accredited with ‘A+’ Grade by NAAC (CGPA:3.64) in the Third Cycle

and Graded as Category–I University by MHRD-UGC]
(A State University Established by the Government of Tamil Nadu)
KARAIKUDI – 630 003

B.Com (Computer Application)

VI - Semester
123 61

SOFTWARE PROJECT
MANAGEMENT
Authors:
Dr. Bhavesh. M Patel, Ex Professor, XLRI (Xavier School of Management), Jamshedpur
Units: (2.0-2.2, 3.5, 4.4-4.9)
Prof. (Dr.) Siddhi Nath Rajan, Associate Professor, IMS Engineering College, Adhyatmik Nagar, Near Dasna, Ghaziabad
Units: (2.5-2.7, 4.3, 7.5-7.6, 10.3-10.5)
Rohit Khurana, Founder and CEO, ITL Education Solutions Ltd., New Delhi
Units: (4.0-4.2, 5, 6.3, 8, 10.0-10.2, 10.6-10.13, 11, 12, 13)
Vikas Publishing House, Units: (1, 2.3-2.4, 2.8-2.17, 3.0-3.4, 3.6-3.11, 6.0 - 6.2, 6.4 - 6.11, 7.0 - 7.4, 7.7 - 7.14, 9, 14)

"The copyright shall be vested with Alagappa University"

All rights reserved. No part of this publication which is material protected by this copyright notice
may be reproduced or transmitted or utilized or stored in any form or by any means now known or
hereinafter invented, electronic, digital or mechanical, including photocopying, scanning, recording
or by any information storage or retrieval system, without prior written permission from the Alagappa
University, Karaikudi, Tamil Nadu.

Information contained in this book has been published by VIKAS® Publishing House Pvt. Ltd. and has
been obtained by its Authors from sources believed to be reliable and are correct to the best of their
knowledge. However, the Alagappa University, Publisher and its Authors shall in no event be liable for
any errors, omissions or damages arising out of use of this information and specifically disclaim any
implied warranties or merchantability or fitness for any particular use.

Vikas® is the registered trademark of Vikas® Publishing House Pvt. Ltd.

VIKAS® PUBLISHING HOUSE PVT. LTD.
E-28, Sector-8, Noida - 201301 (UP)
Phone: 0120-4078900  Fax: 0120-4078999
Regd. Office: A-27, 2nd Floor, Mohan Co-operative Industrial Estate, New Delhi 1100 44
 Website: www.vikaspublishing.com  Email: [email protected]

Work Order No.AU/DDE/DE12-27/Preparation and Printing of Course Materials/2020 Dated 12.08.2020 Copies - 500
 SYLLABI-BOOK MAPPING TABLE
Software Project Management

BLOCK I: SOFTWARE DEVELOPMENT ORGANIZATION & PROJECT

UNIT-1: Software Development Organization and Roles - The Management Unit 1: Software
Spectrum - Organizational Structure - Types of Organizational Structures - Development Organization
Hierarchical Organizational Structure - Flat Organizational Structure - Matrix and Roles
Organizational Structure - Networked Organizational Structure - T-Form (Pages 1-21);
Organization - Job Roles in Software Development. Unit 2: Overview of Project
UNIT-2: Overview of Project Management - Project Management - Definitions - Management
Factors Influencing Project Management - Project Manager - Project Management (Pages 22-49);
Activities - Stakeholders - Project Communication - Project Development Phases Unit 3: Project Planning
- Project Charter - Statement of Work (SoW) - Project Management Associations. (Pages 50-71);
UNIT-3: Project Planning - Tasks in Project Planning - Work Breakdown Structures Unit 4: Estimation and
(WBS) - Planning Methods - Development Life Cycle Models - A Generic Project Budgeting of Projects
Model. (Pages 72-92)
UNIT-4: Estimation and Budgeting of Projects - Software Cost Estimation -
COCOMO Model - Budgeting.

BLOCK II: PROJECT SCHEDULING & RISK MANAGEMENT

UNIT-5: Project Scheduling - Scheduling Techniques - Program Evaluation and Unit 5: Project Scheduling
Review Technique (PERT) - Gantt Chart - Critical Path Method (CPM) - Automated (Pages 93-115);
Tools. Unit 6: Project Monitoring
UNIT-6: Project Monitoring and Controlling - Project Status Reporting - Project and Controlling
Metrics - Earned Value Analysis (EVA) - Project Communication Plan & (Pages 116-128);
Techniques - Steps for Process Improvement. Unit 7: Risk Management
UNIT-7: Risk Management - Concepts of Risks and Risk Management - Risk (Pages 129-147);
Management Activities - Effective Risk Management - Risk Categories - Aids for Unit 8: Configuration
Risk Identification - Potential Risk Treatments - Risk Components and Drivers - Management
Risk Prioritization. (Pages 148-170)
UNIT-8: Configuration Management - Software Configuration Management
(SCM) - Baselines - Software Configuration Items (SCI) - SCM Process -
Identification of Objects in the Software Configuration - Version Control - Change
Control - Configuration Audit - Status Reporting - Goals of SCM.

BLOCK III: SCM CONCEPTS & TEAM DEVELOPMENT

UNIT-9: Team Development and Conflict Management - Basic Concepts - Unit 9: Team Development
Organization Types - Centralized - Control Team Organization - Decentralized - and Conflict Management
Control Team Organization - Mixed-Control Team Organization - Case Study 1. (Pages 171-199);
Open-Source Development Team Organization - An Assessment of Team Unit 10: Software Quality
Organizations - Nokia Software Factories - Team Discipline; Conflict Management. Assurance
UNIT-10: Software Quality Assurance - Software Quality Assurance Activities - (Pages 200-223);
Software Qualities - Software Quality Standards - ISO Standards for Software Unit 11: Computer Aided
Organization - Capability Maturity Model (CMM) - Comparison between ISO Software Engineering (CASE)
9001 & SEI CMM - Other Standards. Tools
UNIT-11: Computer Aided Software Engineering (CASE) Tools - CASE Concepts (Pages 224-238)
- Classification of CASE Tools - Steps for CASE Tool Implementation - Integrated
CASE Environment - Architecture of CASE Environment.
BLOCK IV: FUNDAMENTALS OF SOFTWARE QUALITY ASSURANCE &
TESTING TECHNIQUES
UNIT-12: Testing Techniques - Software Testing Concepts - Types of Software Unit 12: Testing Techniques
Testing - Manual Testing - Automated Testing - Black Box Testing - White Box (Pages 239-300);
Testing Techniques. Unit 13: Software
UNIT-13: Software Reengineering - Software Maintenance Problems - Reengineering
Redevelopment vs. Reengineering - Business Process Reengineering - Software (Pages 301-328);
Reengineering Process Model - Technical Problems of Reengineering. Unit 14: Project Closure
UNIT-14: Project Closure - Project Closure Analysis - Infosys Project Closure (Pages 329-340)
Analysis Report - ACIC Project Closure Analysis Report.
 CONTENTS
BLOCK I: SOFTWARE DEVELOPMENT ORGANIZATION & PROJECT

UNIT 1 SOFTWARE DEVELOPMENT ORGANIZATION AND ROLES 1-21

1.0 Introduction
1.1 Objectives
1.2 The Management Spectrum
1.3 Organizational Structure
1.3.1 Hierarchical Organizational Structure
1.3.2 Flat Organizational Structure
1.3.3 Matrix Organizational Structure
1.3.4 Networked Organizational Structure
1.3.5 T-Form Organization
1.4 Job Roles in Software Development
1.5 Answers to Check Your Progress Questions
1.6 Summary
1.7 Key Words
1.8 Self Assessment Questions and Exercises
1.9 Further Readings

UNIT 2 OVERVIEW OF PROJECT MANAGEMENT 22-49

2.0 Introduction
2.1 Objectives
2.2 Project Management
2.3 Project Management Definitions
2.4 Factors Influencing Project Management
2.5 Project Manager
2.6 Project Management Activities
2.7 Stakeholders
2.8 Project Communication
2.9 Project Development Phases
2.10 Project Charter
2.11 Statement Of Work (SOW)
2.12 Project Management Associations
2.13 Answers to Check Your Progress Questions
2.14 Summary
2.15 Key Words
2.16 Self Assessment Questions and Exercises
2.17 Further Readings
UNIT 3 PROJECT PLANNING 50-71
3.0 Introduction
3.1 Objectives
3.2 Tasks in Project Planning
3.2.1 Purpose of a Project
3.2.2 Project Scope
3.2.3 Project Planning Process
3.3 Work Breakdown Structures (WBS)
3.4 Planning Methods
3.5 Development Life Cycle Models
3.6 A Generic Project Model
3.7 Answers to Check Your Progress Questions
3.8 Summary
3.9 Key Words
3.10 Self Assessment Questions and Exercises
3.11 Further Readings

UNIT 4 ESTIMATION AND BUDGETING OF PROJECTS 72-92

4.0 Introduction
4.1 Objectives
4.2 Software Cost Estimation
4.2.1 Expert Judgement
4.2.2 Constructive Cost Model
4.2.3 Basic Model
4.2.4 Intermediate Model
4.2.5 Advance Model
4.2.6 Halstead’s Software Science
4.3 COCOMO Model
4.4 Budgeting
4.5 Answers to Check Your Progress Questions
4.6 Summary
4.7 Key Words
4.8 Self Assessment Questions and Exercises
4.9 Further Readings

BLOCK II: PROJECT SCHEDULING & RISK MANAGEMENT

UNIT 5 PROJECT SCHEDULING 93-115

5.0 Introduction
5.1 Objectives
5.2 Scheduling Techniques
 5.3 Automated Tools
5.4 Answers to Check Your Progress Questions
5.5 Summary
5.6 Key Words
5.7 Self Assessment Questions and Exercises
5.8 Further Readings

UNIT 6 PROJECT MONITORING AND CONTROLLING 116-128

6.0 Introduction
6.1 Objectives
6.2 Project Status Reporting
6.3 Project Metrics
6.4 Earned Value Analysis (EVA)
6.5 Project Communication Plan and Techniques
6.5.1 Project Communication Techniques
6.6 Steps For Process Improvement
6.7 Answers to Check Your Progress Questions
6.8 Summary
6.9 Key Words
6.10 Self Assessment Questions and Exercises
6.11 Further Readings

UNIT 7 RISK MANAGEMENT 129-147

7.0 Introduction
7.1 Objectives
7.2 Concepts of Risks and Risk Management
7.3 Risk Management Activities
7.4 Effective Risk Management
7.5 Risk Categories
7.6 Aids for Risk Identification
7.7 Potential Risk Treatments
7.8 Risk Components and Drivers
7.9 Risk Prioritization
7.10 Answers to Check Your Progress Questions
7.11 Summary
7.12 Key Words
7.13 Self Assessment Questions and Exercises
7.14 Further Readings
UNIT 8 CONFIGURATION MANAGEMENT 148-170
8.0 Introduction
8.1 Objectives
8.2 Software Configuration Management (SCM)
8.3 Software Configuration Planning
8.4 Goals of Software Configuration Management (SCM)
8.5 Answers to Check Your Progress Questions
8.6 Summary
8.7 Key Words
8.8 Self Assessment Questions and Exercises
8.9 Further Readings

BLOCK III: SCM CONCEPTS & TEAM DEVELOPMENT

UNIT 9 TEAM DEVELOPMENT AND CONFLICT MANAGEMENT 171-199

9.0 Introduction
9.1 Objectives
9.2 Team Development and Conflict Management: Basic Concepts
9.2.1 Conflict Management
9.3 Organization Types and Control Systems
9.3.1 Centralized Control Team Organization
9.3.2 Decentralized Control Team Organization
9.3.3 Mixed Control Team Organization
9.4 Answers to Check Your Progress Questions
9.5 Summary
9.6 Key Words
9.7 Self Assessment Questions and Exercises
9.8 Further Readings

UNIT 10 SOFTWARE QUALITY ASSURANCE 200-223

10.0 Introduction
10.1 Objectives
10.2 Software Quality Assurance Activities
10.3 Software Quality
10.3.1 Data Analysis Techniques Applicable to Software Processes
10.3.2 Importance of Software Quality
10.4 Software Quality Standard
10.5 ISO Standards for Software Organization
10.6 Capability Maturity Model (CMM)
10.7 Comparison between ISO 9001 & SEI CMM
 10.8 Other Standards
10.9 Answers to Check Your Progress Questions
10.10 Summary
10.11 Key Words
10.12 Self Assessment Questions and Exercises
10.13 Further Readings

UNIT 11 COMPUTER AIDED SOFTWARE ENGINEERING (CASE) TOOLS 224-238

11.0 Introduction
11.1 Objectives
11.2 CASE Concepts
11.3 Architecture of CASE Environment
11.4 Answers to Check Your Progress Questions
11.5 Summary
11.6 Key Words
11.7 Self Assessment Questions and Exercises
11.8 Further Readings

BLOCK IV: FUNDAMENTALS OF SOFTWARE QUALITY ASSURANCE

& TESTING TECHNIQUES

UNIT 12 TESTING TECHNIQUES 239-300

12.0 Introduction
12.1 Objectives
12.2 Software Testing Concepts
12.2.1 Test Case Generation
12.3 Types of Software Testing
12.3.1 Software Testing Strategies
12.3.2 Levels of Testing
12.3.3 Unit Testing
12.3.4 Integration Testing
12.3.5 Validation Testing
12.3.6 System Testing
12.4 Automated Testing
12.5 Manual Testing
12.6 Testing Techniques
12.6.1 White Box Testing
12.6.2 Black Box Testing
12.6.3 Gray Box Testing
12.7 Answers to Check Your Progress Questions
12.8 Summary
12.9 Key Words
12.10 Self Assessment Questions and Exercises
12.11 Further Readings
UNIT 13 SOFTWARE REENGINEERING 301-328
13.0 Introduction
13.1 Objectives
13.2 Software Reengineering and Software Maintenance Problems
13.3 Redevelopment vs. Reengineering
13.4 Business Process Reengineering
13.5 Software Reengineering Process Model
13.6 Answers to Check Your Progress Questions
13.7 Summary
13.8 Key Words
13.9 Self Assessment Questions and Exercises
13.10 Further Readings

UNIT 14 PROJECT CLOSURE 329-340

14.0 Introduction
14.1 Objectives
14.2 Project Closure Analysis
14.3 Infosys Project Closure Analysis Report
14.4 ACIC Project Closure Analysis Report
14.5 Answers to Check Your Progress Questions
14.6 Summary
14.7 Key Words
14.8 Self Assessment Questions and Exercises
14.9 Further Readings
 Introduction

INTRODUCTION
A project is a well-defined task, specifically collection of several operations done
NOTES
in order to achieve a goal, for example software development and delivery. Every
project may has a unique and distinct goal with a start time and end time.
A ‘Software Project’ is the complete procedure of software development
from requirement gathering to testing and maintenance, carried out according to
the execution methodologies, in a specified period of time to achieve intended
software product. Software is said to be an intangible product. Most software
products are tailor made to fit client’s requirements. The most important is that the
fundamental technology changes and advances so frequently and rapidly that
experience of one product may not be applicable to the other product. Software
project management is, therefore, an art and science of planning and leading
software projects. It is a sub-discipline of project management in which software
projects are planned, implemented, monitored and controlled.
In the 1970s and 1980s, the software industry grew very quickly, as computer
companies quickly recognized the relatively low cost of software production
compared to hardware production and circuitry. To manage new development efforts,
companies applied the established project management methods, but project
schedules skated during test runs, especially when confusion occurred in the gray
zone between the user specifications and the delivered software. To avoid these
problems, software project management methods focused on matching user
requirements to delivered products, in a method known now as the waterfall model.
Analysis of software project management revealed that the most common
causes of software project failures include insufficient end-user involvement; poor
communication among customers, developers, users and project managers; unrealistic
or unarticulated project goals; inaccurate estimates of required resources; poorly
defined or incomplete system requirements and specifications; poor reporting of the
project’s status; poorly managed risks; use of immature technology; inability to handle
the project’s complexity, disordered development practices, stakeholder politics (e.g.,
absence of executive support or politics between the customer and end-users) and
commercial pressures. Specific software project management tools are useful and
often essential. Without a method, tools are worthless. Since the 1960s, several
proprietary software project management methods have been developed by software
manufacturers for their own use, while computer consulting firms have also developed
similar methods for their clients. Today software project management methods are
still evolving, but the current trend leads away from the waterfall model to a more
cyclic project delivery model that imitates a software development process.
A software development process is concerned primarily with the production
aspect of software development, as opposite to the technical aspect, such as software
tools. These processes exist primarily for supporting the management of software
development, and are generally skewed toward addressing business concerns. Many Self-Instructional
Material
Introduction software development processes can be run in a similar way to general project
management processes. Examples are interpersonal communication, conflict
management and resolution, risk management, requirements management, change
management, software configuration management and release management. Active,
NOTES frequent and honest communication is the most important factor in increasing the
likelihood of project success and mitigating problematic projects.
The purpose of project planning is to identify the scope of the project,
estimate the work involved, and create a project schedule. Project planning begins
with requirements that define the software to be developed. The project execution
is the process of completing the tasks defined in the project plan.
This book, Software Project Management, is divided into four blocks,
which are further subdivided into fourteen units. This book provides a basic
understanding of the subject and helps to grasp its fundamentals. In a nutshell, it
explains various aspects, such as software development organization and roles,
the management spectrum, types of organizational structures, project management,
factors influencing project management, project manager, project management
activities, project development phases, Statement of Work (SoW), project
management associations, project planning, Work Breakdown Structures (WBS),
development life cycle models, estimation and budgeting of projects, software
cost estimation, COCOMO model, project scheduling, scheduling techniques,
Program Evaluation and Review Technique (PERT), Gantt chart, Critical Path
Method (CPM), project monitoring and controlling, Earned Value Analysis (EVA),
project communication plan & techniques, steps for process improvement, risk
management, concepts of risks and risk management, effective risk management,
configuration management, Software Configuration Management (SCM), Software
Configuration Items (SCI), Goals of SCM, team development and conflict
management, centralized control team organization, decentralized control team
organization, mixed control team organization, software quality assurance, software
quality standards, ISO standards for software organization, Capability Maturity
Model (CMM), ISO 9001 & SEI CMM, Computer Aided Software Engineering
(CASE) tools, CASE concepts, integrated CASE environment, testing techniques,
software testing concepts, types of software testing, black box testing, white box
testing techniques, software reengineering, software maintenance problems,
redevelopment vs. reengineering, business process reengineering, software
reengineering process model, technical problems of reengineering, project closure,
project closure analysis, and Infosys project closure analysis report.
The book follows the Self-Instructional Mode (SIM) wherein each unit begins
with an ‘Introduction’ to the topic. The ‘Objectives’ are then outlined before going
on to the presentation of the detailed content in a simple and structured format.
‘Check Your Progress’ questions are provided at regular intervals to test the student’s
understanding of the subject. ‘Answers to Check Your Progress Questions’, a
‘Summary’, a list of ‘Key Words’, and a set of ‘Self-Assessment Questions and
Exercises’ are provided at the end of each unit for effective recapitulation.
Self-Instructional
Material
 Software Development
BLOCK - I Organization and Roles

SOFTWARE DEVELOPMENT ORGANIZATION

& PROJECT
NOTES

UNIT 1 SOFTWARE
DEVELOPMENT
ORGANIZATION AND
ROLES
Structure
1.0 Introduction
1.1 Objectives
1.2 The Management Spectrum
1.3 Organizational Structure
1.3.1 Hierarchical Organizational Structure
1.3.2 Flat Organizational Structure
1.3.3 Matrix Organizational Structure
1.3.4 Networked Organizational Structure
1.3.5 T-Form Organization
1.4 Job Roles in Software Development
1.5 Answers to Check Your Progress Questions
1.6 Summary
1.7 Key Words
1.8 Self Assessment Questions and Exercises
1.9 Further Readings

1.0 INTRODUCTION

In software engineering, the management spectrum describes the management of

a software project. The management of a software project starts from requirement
analysis and finishes based on the nature of the product, it may or may not end
because almost all software products faces changes and requires support. It is
about turning the project from plan to reality. The management spectrum is a
flowchart how to handle a software project or how to make a project successful.
People, product, method, and project are the four Ps that it focuses on. Here, the
project manager must keep track of all of these P’s in order to maintain a smooth
flow in the project’s development and achieve the target. An organizational
structure defines how activities, such as task allocation, coordination, and
supervision are directed toward the achievement of organizational aims.
Organizational structure affects organizational action and provides the foundation
on which standard operating procedures and routines rest. It determines which Self-Instructional
Material 1
Software Development individuals get to participate in which decision-making processes, and thus to
Organization and Roles
what extent their views shape the organization’s actions. Organizational structure
can also be considered as the viewing glass or perspective through which individuals
see their organization and its environment.
NOTES
A hierarchical organization is an organizational structure where every entity
in the organization, except one, is subordinate to a single other entity. This
arrangement is a form of a hierarchy. In an organization, the hierarchy usually
consists of a singular/group of power at the top with subsequent levels of power
beneath them. A flat organization (also known as horizontal organization) has
an organizational structure with few or no levels of middle management between
staff and executives. The T-Form organization structure offers benefits to both
internal and external customers. The characteristics of T-Form organizations include
electronic linking and communications; technological matrixing; delegation of tasks;
remote worksites; faster decision-making; lower overhead costs; and IT harvesting.
In this unit, you will study about the management spectrum, organizational
structure, hierarchical organizational structure, flat organizational structure, matrix
organizational structure, networked, organizational structure, T-Form organization,
and Job roles in software development.

1.1 OBJECTIVES

After going through this unit, you will be able to:

 Define the term management spectrum
 Understand the basics of organizational structure
 Elucidate on the hierarchical organizational structure
 Discuss about the flat organizational structure
 Explain the matrix organizational structure
 Analyse the networked organizational structure
 Define the T-Form organization
 Explain about the job roles in software development

1.2 THE MANAGEMENT SPECTRUM

In software engineering, the management spectrum describes the management of

a software project. The management of a software project starts from requirement
analysis and finishes based on the nature of the product, it may or may not end
because almost all software products faces changes and requires support. It is
about turning the project from plan to reality. Effective software project management
focuses on the four P’s: People, Product, Process, and Project. The order is not
arbitrary.
Self-Instructional
2 Material
 Fundamentally, the management spectrum is a flowchart how to handle a Software Development
Organization and Roles
software project or how to make a project successful. People, Product, Process,
and Project are the four P’s that it focuses on. Here, the project manager must
keep track of all of these P’s in order to maintain a smooth flow in the project’s
development and achieve the target. NOTES
The four P’s of management spectrum are discussed below.
The People
People of a project includes from manager to developer, from customer to end
user. But mainly people of a project highlight the developers. It is so important to
have highly skilled and motivated developers that the Software Engineering Institute
has developed a People Management Capability Maturity Model (PM-CMM),
‘To enhance the readiness of software organizations to undertake increasingly
complex applications by helping to attract, grow, motivate, deploy, and retain the
talent needed to improve their software development capability’. Organizations
that achieve high levels of maturity in the people management area have a higher
likelihood of implementing effective software engineering practices.
The Product
The product is the ultimate goal of the project. This is any types of software product
that has to be developed. To develop a software product successfully, all the
product objectives and scopes should be established, alternative solutions should
be considered, and technical and management constraints should be identified
beforehand.
Basically, any software that needs to be created is referred to as a ‘Product’.
Product goals and scope should be defined, potential solutions should be considered,
and technological and management constraints should be identified in order to evolve
successfully. Without this information, it is impossible to define reasonable and accurate
estimates of the cost, an effective assessment of risk, a realistic breakdown of project
tasks or a manageable project schedule that provides a meaningful indication of
progress. Figure 1.1 illustrates the four P’s of management spectrum.

Fig. 1.1 Management Spectrum

Self-Instructional
Material 3
Software Development The Process
Organization and Roles
A software process provides the framework from which a comprehensive plan
for software development can be established. A number of different tasks sets—
tasks, milestones, work products, and quality assurance points—enable the
NOTES
framework activities to be adapted to the characteristics of the software project
and the requirements of the project team. Finally, umbrella activities overlay the
process model. Umbrella activities are independent of any one framework activity
and occur throughout the process.
The Project
The project is the complete software project that includes requirement analysis,
development, delivery, maintenance and updates. The project manager of a project
or sub-project is responsible for managing the people, product and process. The
responsibilities or activities of software project manager would be a long list but
that has to be followed to avoid project failure.
A software project could be extremely complex and as per the industry
data the failure rate is high. It’s merely due to the development but mostly due to
the steps before development and sometimes due to the lack of maintenance.
The manager is required to perform certain duties in this situation. The project
covers the entire development process, and in order to prevent project failure, the
manager must take certain precautions, be aware of certain common alerts, and
so on.

1.3 ORGANIZATIONAL STRUCTURE

An organizational structure defines how activities, such as task allocation,

coordination, and supervision are directed toward the achievement of organizational
aims.
Organizational structure affects organizational action and provides the
foundation on which standard operating procedures and routines rest. It determines
which individuals get to participate in which decision-making processes, and thus
to what extent their views shape the organization’s actions. Organizational structure
can also be considered as the viewing glass or perspective through which individuals
see their organization and its environment.
Organizations are a variant of clustered entities.
An organization can be structured in many different ways, depending on its
objectives. The structure of an organization will determine the modes in which it
operates and performs. Organizational structure allows the expressed allocation
of responsibilities for different functions and processes to different entities, such as
the branch, department, workgroup, and individual.
Organizations need to be efficient, flexible, innovative and caring in order to
achieve a sustainable competitive advantage.
Self-Instructional
4 Material
 An organizational structure fundamentally outlines how certain activities can Software Development
Organization and Roles
be directed to accomplish the goals of an organization. Successful organizational
structures explain each employee’s specific job and how it adequately fits within
the overall system. Types of organizational structures include hierarchical, functional,
matrix, etc. NOTES
Following are the different types of organizational structures.
1.3.1 Hierarchical Organizational Structure
A hierarchical organization is an organizational structure where every entity in
the organization, except one, is subordinates to a single other entity. This
arrangement is a form of a hierarchy. In an organization, the hierarchy usually consists
of a singular/group of power at the top with subsequent levels of power beneath
them. This is the dominant mode of organization among large organizations;
most corporations, governments, criminal enterprises, and organized religions are
hierarchical organizations with different levels of management, power or authority.
For example, the broad, top-level overview of the general organization of
the Catholic Church consists of the Pope, then the Cardinals, then the Archbishops,
and so on.
A hierarchy is typically visualized as a pyramid, where the height of the
ranking or person depicts their power status and the width of that level represents
how many people or business divisions are at that level relative to the whole—the
highest-ranking people are at the apex, and there are very few of them; the base
may include thousands of people who have no subordinates. These hierarchies
are typically depicted with a tree or triangle diagram, creating an organizational
chart or organigram. Those nearest the top have more power than those nearest
the bottom, and there being fewer people at the top than at the bottom. As a
result, superiors in a hierarchy generally have higher status and command greater
rewards than their subordinates.
Members of hierarchical organizational structures chiefly communicate with
their immediate superior and with their immediate subordinates. Structuring
organizations in this way is useful partly because it can reduce the communication
overhead by limiting information flow.
Advantages of a Hierarchical Organizational Structure
1. It Creates a Defined Structure for Communication.
Within a hierarchical organizational structure, clear lines of communication are
established for everyone. Employees in entry-level positions would receive their
daily assignments from their direct supervisor. The direct supervisor is responsible
for interpreting orders coming from their supervisors. That process continues moving
upward until it reaches the top individual in the structure. This makes it easier to
plan and implement business strategies quickly, assuming employees stick to the
structure.

Self-Instructional
Material 5
Software Development 2. It Offers Multiple Layers of Authority within the Company.
Organization and Roles
A hierarchical organizational structure communicates to internal and external parties
about who holds what authority within the business. As more authority is granted,
more responsibilities are typically assigned. This creates a clear structure for
NOTES
reporting, allowing for consistent movement of information up and down the chain
of command. For those who are looking to advance their career, this chart creates
a path that they can follow.
3. It Establishes a Clear Picture of Authority.
Within the hierarchical organizational structure, there is a clear picture of who has
authority and who does not in the organization. This makes it easier to identify
which managers have the power to allocate resources, reward successes, or initiate
disciplinary action proceedings. There is no confusion about who is in charge and
who is not in charge, which can be very useful during crisis situations.
4. It Identifies Places Where Duplication may Exist.
The hierarchical organizational structure makes it possible to identify which teams
share resources. It finds places where there may be job responsibilities which
overlap, costing the organization money. Although this may cause employment
losses over time, it creates more efficiency within the financial profile of the company,
setting the stage for growth within an economy of scale over time.
5. It Allows for Specialization.
When there isn’t an outlined structure in place for an organization, it tends to
cause managers to be responsible for a variety of different tasks. That is especially
true for small businesses, where one manager might be responsible for marketing,
human resources, and purchasing. When there is a hierarchical organizational
structure in place, it allows managers to divide responsibilities to the people in a
logical way, creating an additional layer of efficiencies.
6. It Eliminates Issues of Indecisiveness.
Within the hierarchical organizational structure, there is always someone who is
held responsible for the actions or decisions that are made. There is no hiding
from this accountability, even if one manager attempts to assign blame to someone
else. There is clear communication about who is in charge of what projects. This
design also makes it easier to keep track of ongoing activities, the status of projects,
and the quality of work that is being completed.
7. It Takes the Pressure Off the Entry-Level Worker.
In this type of structure, the power of decision-making is consolidated at the top
of the company. That means owners, founders, CEOs, and similar positions are
responsible for making the organizational decisions which affect everyone. In theory,
these decisions should be made in consultation with a senior leadership team. For
the entry-level worker, that means the only stress placed on them are the deadlines
they are required to meet.
Self-Instructional
6 Material
Disadvantages of a Hierarchical Organizational Structure Software Development
Organization and Roles
1. It may Cause a Lack of Collaboration.
When there is a hierarchical organizational structure in place, teams tend to stay
within their defined structures. Collaboration within a team still happens. NOTES
Collaborating outside of a team silo can be difficult to accomplish. People tend to
stick together, competing for power, instead of working together as a whole to
advance the mission of the company.
2. It can Cause Managers to become Territorial.
Within the hierarchical organizational structure, managers often become territorial
about their power within the company. They become defensive if other managers
start trying to work with their employees. Instead of looking at an organization-
level issue with a clear mind, they might approach the situation from the perspective
of their department only. This creates a competition for power which can be
destructive for everyone involved.
3. It may Reduce Internal Innovation.
Clear reporting structures within a hierarchical organizational structure help a
company be able to keep information moving. It also creates a rigid structure
which may limit innovation. If an employee approaches their direct manager with
an idea, which is rejected out-of-hand, then it discourages the employee from
sharing further. If that idea would have been accepted at a higher level in the
organization, it could impact future revenues. That is why a bypass of the structure
for sharing ideas is essential to the success of this traditional structure.
4. It Centralizes the Power Structure.
The hierarchical organizational structure works extremely well for large companies.
It can be a challenge to implement it on the small business level. That is because
the structure can cause some owners to begin being involved in the decisions of
daily operations. It may encourage a lack of delegation, which reduces the overall
productivity that is available. Instead of putting leaders in charge of big-picture
decisions, it can encourage some to be involved in the real-time implementation of
needs.
5. It Creates a Lot of Bureaucracy that must be Managed.
When a business begins to grow, the hierarchical organizational structure must
also grow. When there is more bureaucracy, the pattern of growth tends to slow
down. In time, that can cause a company to become too top-heavy with their
organizational chart, which makes the organization less responsive when fast
decisions must be made. Requests are forced to travel up the chain of command,
then back down again, which can be destructive when dynamic movement is
required.
6. It may Create Communication Barriers.
Although the hierarchical organizational structure is intended to improve
communication, it may hinder it instead. Some companies do not permit workers Self-Instructional
Material 7
Software Development to skip layers within the chain of command. That may cause some workers to
Organization and Roles
avoid communicating at all because they distrust their direct supervisor. It can also
cause teams to create their own jargon, which makes it difficult to communicate
internally. It is not unheard of to have teams purposely withhold information because
NOTES it would benefit someone other than themselves.
1.3.2 Flat Organizational Structure
A flat organization (also known as horizontal organization) has an organizational
structure with few or no levels of middle management between staff and executives.
An organization’s structure refers to the nature of the distribution of the units and
positions within it, also to the nature of the relationships among those units and
positions. Tall and flat organizations differ based on how many levels of management
are present in the organization and how much control managers are endowed
with. In flat organizations, the number of people directly supervised by each manager
is large, and the number of people in the chain of command above each person is
small. A manager in a flat organization possesses more responsibility than a manager
in a tall organization because there is a greater number of individuals immediately
below them who are dependent on direction, help, and support. Moreover,
managers in a flat organization rely less on guidance from superiors because the
number of superiors above the manager is limited.
Advantages of a Flat Organizational Structure
1. It is Cost Efficient.
As mentioned, in this organizational structure, there are fewer (or no) manager
layers between the executive and the staff. This means that there are less wages,
fringe benefits, and so on, to pay for management. Salary-related expenses are
reduced, enabling the company to save money as well as provide better pay for its
workers.
2. It Promotes Faster Decision-Making.
Another advantage about a flat organizational structure is there are less decision-
making hoops. Fewer people have to be consulted about a decision, allowing the
management to provide rapid response to any issues or concern. It creates a
direct communication line between the person sitting behind the desk (the owner
or CEO) and the people on the front line (the workers).
3. It Allows Clear Communication.
What usually happens when information is passed on through a series of ears and
mouths is that it ended up either distorted, puffed up, or deflated. When
communication is passed across many management layers, there is a high chance
of miscommunication. Flat organizational structure helps avoid this by allowing the
upper management to take direct input from employees, and vice versa.

Self-Instructional
8 Material
4. It Requires Less Dominance and Supervision. Software Development
Organization and Roles
Many believe that a company’s head must be able to monitor and manage anything
and everything that is happening inside his or her organization, including the
employees. Some studies, however, show otherwise. This is because the less time
NOTES
managers have to helicopter and micromanage their employees, the more productive
employees can get in day as these can give them a higher sense of responsibility.
Disadvantages of a Flat Organizational Structure
1. Management can Easily Lose Control.
As mentioned above, this structure is ideal for startups and small business where
the number of employees is still manageable. The system can pose a problem to
the whole organization when the ratio of employees to managers become too out
of proportion. The management can easily lose control when there are less people
to put a brake to bad behaviors and less individuals to support or back them up on
their decisions.
2. Work-Relationship could Struggle.
When managers have too many people to manage every day, they may find it
difficult to connect with their employees on a personal level, which is crucial in
maintaining trust and in stepping up the baseline of employees’ responsibility and
accountability for the work and the organization as a whole. This con can have a
great impact on the issue of respect and morale of an organization on levels of
authority.
3. It can Create Power Struggle.
Under this organizational structure, it is observed that employees often lack a
specific boss to report to, especially when the owner or CEO is not around. This
can create confusion and possible power struggles among management employees.
4. It makes Employee Retention Difficult.
Who does not want a promotion? Excellent employees who are looking for an
improvement in their rank, aside from an increase in their salary, may find it hard to
find job satisfaction in this kind of organizational set up. They may end up looking
for a job somewhere else where they believe their efforts will be rewarded with a
promotion.
5. It may Hinder Growth.
Change is often times difficult and poses a lot of what ifs. Because of this,
management may decide against new opportunities in an effort to maintain the
structure which, as a result, may limit the long-term growth of the organization.
6. There is Less Motivation.
While a flat organization structure may lessen the problems caused by unhealthy
competition among employees, it makes it harder for ambitious workers to move
up the ladder as there is very little room up there. This could easily erode motivation,
giving people no reason to take the extra mile in their work.
Self-Instructional
Material 9
Software Development
Organization and Roles 1.3.3 MATRIX ORGANIZATIONAL STRUCTURE

A matrix organizational structure is normally used in the companies to distribute

NOTES resources and workers across multiple operations. This type of structure can have
both advantages and disadvantages within the workplace. Understanding the
benefits and shortcomings of a matrix organizational structure will help to determine
that can this type of structure is appropriate for the company.
Characteristically, every organization is structured in some way, and that
specific structure is determined by the organization’s objectives. The structure of
an organization specifies a standard for operating procedures and routines. It will
also determine who participates in what, and whatever project tools are best
suitable for the job at hand.
Matrix organizational structure is often used in project management because
it speaks to both the product of the project and the function of the management
producing it. Let’s take a closer look at this type of organizational structure to
determine its pros and cons in project management.
The matrix structure groups employees by both function and product
simultaneously. A matrix organization frequently uses teams of employees to
accomplish work, in order to take advantage of the strengths, as well as make up
for the weaknesses, of functional and decentralized forms. An example would be
a company that produces two products, ‘Product A’ and ‘’Product B’. Using the
matrix structure, this company would agonize functions within the company as
follows: ‘Product A’ sales department, ‘Product A’ customer service department,
‘Product A’ accounting department, ‘Product B’ sales department, ‘Product B’
customer service department, ‘Product B’ accounting department.
Matrix organizational structure is of following three types:
 Weak/Functional Matrix: A project manager with only limited
authority is assigned to oversee the cross- functional aspects of
the project. The functional managers maintain control over their resources
and project areas.
 Balanced/Functional Matrix: A project manager is assigned to
oversee the project. Power is shared equally between the project
manager and the functional managers. It brings the best aspects of
functional and projectized organizations. However, this is the most difficult
system to maintain as the sharing of power is a delicate proposition.
 Strong/Project Matrix: A project manager is primarily responsible for
the project. Functional managers provide technical expertise and assign
resources as needed.
There are advantages and disadvantages of the matrix structure. Some of
the disadvantages include tendencies towards anarchy, power struggles and
‘Sinking’ to group and division levels. Matrices increase the complexity of the chain
Self-Instructional
10 Material
of command, which can present problems because of the differentiation between Software Development
Organization and Roles
functional managers and project managers. This, in turn, can be confusing for
employees to understand who is next in the chain of command. An additional
disadvantage of the matrix structure is higher manager to worker ratio that results
in conflicting loyalties of employees. However, the matrix structure also has NOTES
significant advantages that make it valuable for companies to use. The matrix
structure may improve upon the ‘Silo’ critique of functional management in that it
aims to diminish the vertical structure of functional and create a more horizontal
structure which allows the spread of information across task boundaries to happen
much quicker. It aims to allow specialization to increase depth of knowledge and
allows individuals to be chosen according to project needs.
1.3.4 Networked Organizational Structure
In the network structure, managers coordinate and control relationships with the
firm that are both internal and external. An organization can be structured in various
ways that determine how it operates and performs. The network structure is a
newer type of organizational structure often viewed as less hierarchical (i.e., more
flat), more decentralized, and more flexible than other structures. In this structure,
managers coordinate and control relations that are both internal and external to
the firm.
The concept underlying the network structure is the social network—a social
structure of interactions. At the organizational level, social networks can include
intra-organizational or inter-organizational ties representing either formal or informal
relationships. At the industry level, complex networks can include technological
and innovation networks that may span several geographic areas and organizations.
From a management perspective, the network structure is unique among other
organizational structures that focus on the internal dynamics within the firm.
A network organization sounds complex, but it is at its core a simple concept.
Take, for example, a T-shirt design company. Because the company leaders are
mainly interested in design, they may not want to get too heavily involved in either
manufacturing or retail; however, both aspects of the business are necessary to
complete their operations. To maintain control of their product, they may rent
retail space through their network and purchase production capabilities from a
variety of partner organizations that have their own manufacturing facilities. While
the core company focuses mainly on designing products and tracking finances,
this network of partnerships enables it to be much more than just a design operation.
Advantages of a Network Structure
Proponents argue that the network structure is more agile compared to other
structures (such as, functional areas, divisions, or even some teams).
Communication is less siloed and flows freely, possibly opening up more
opportunities for innovation. Because the network structure is decentralized, it has
fewer tiers in its organizational makeup, a wider span of control, and a bottom-up
flow of decision-making and ideas. Self-Instructional
Material 11
Software Development Disadvantages of a Network Structure
Organization and Roles
On the other hand, this more fluid structure can lead to a more complex set of
relationships in the organization. For example, lines of accountability may be less
clear, and reliance on external vendors can be quite high. These potentially
NOTES
unpredictable variables essentially reduce the core company’s control over its
operational success.
1.3.5 T-Form Organization
At present, the technology is changing organizations structure. One impact of
Information Technology (IT), is the use of information technology design variables
to develop new organizational structures. The organization that is most likely to
result from the use of these variables is the T-Form or Technology-Form
organization, an organization that uses IT to become highly efficient and effective.
Information Technology (IT) is usually regarded as a supporting component
to organizational structure. Now some managers believe that IT design variables
can not only help an organization implement its chosen strategy, but also suggest a
strategy to the firm. Some organizations take the networked structure one step
further, and a different organization form, the T-Form organization come into being.
The T-Form organization has a flat structure through electronic linking and
communication. Its common features include electronic workflows and production
automation. T-Form organization minimizes the use of paper and relies extensively
on imaging devices and optical data storage.
The T-Form company’s technological infrastructure features networks of
computers. Individual’s client workstations connect over a network to larger
computers that act as servers. The networks has gateways to national and
international networks so members of the firm can connect with customers,
suppliers, and other with whom they need to interact.
T-Form organization performs a variety of tasks over electronic networks.
Technology like e-mail and groupware facilitates the work of the tasks. Most of
the benefits of the T-Form organization accrue to its flat structure, which allows
for faster decision-making and information processing. The T-Form organization
structure offers benefits to both internal and external customers. The characteristics
of T-Form organizations include electronic linking and communications;
technological matrixing; delegation of tasks; remote worksites; faster decision-
making; lower overhead costs; and IT harvesting.
The organization that is most likely to result from the use of these variables
is the T-Form or Technology-Form organization, an organization that uses IT to
become highly efficient and effective. Most T-Form organizations will use
communications technology to form temporary task forces focused on a specific
project. Technology like e-mail and groupware facilitate the work of these task
forces. These temporary workgroups may include employees of customers,

Self-Instructional
12 Material
suppliers and/or partner corporations. The T-Form organization is likely extensively Software Development
Organization and Roles
with customers and suppliers. There are numerous electronic customers / supplier
relationships. These linkages increase responsiveness, improve accuracy, reduce
cycle times, and reduce the amount of overhead when firms do business with each
other. Supplier’s access customer’s computers directly to know their needs for NOTES
materials, then deliver raw materials and assemblies to the proper location just as
they are required. Customers pay many suppliers as the customer consumes
materials, dispensing with invoices and other documents associated with a purchase
transaction.
The advantages of T-Form organizations include electronic workflows; flat
organization structure; strong IT management; electronic links to customers;
increased responsiveness; more efficient operations; and increased opportunities
for employee development.

1.4 JOB ROLES IN SOFTWARE DEVELOPMENT

The job role of a software developer engages in identifying, designing, installing

and testing a software system they have built for a company from the ground up. It
can range from creating internal programmes that can help businesses be more
efficient to producing systems that can be sold on the open market. Once software
developers have delivered the final software system, they will also help in
maintaining and updating the programme to ensure that all security problems are
fixed, and it operates with new databases. In a role of a software developer they
create the applications that allow people to do specific tasks on a computer or
mobile and others develop the underlying systems that control networks. Software
engineers design, develop, and test software and applications for computers. The
main duties and responsibilities of software engineers include directing and
participating in programming activities, monitoring, and evaluating system
performance, and designing and implementing new programs and features.
There are a variety of skills required to be a software developer, but these
skills can vary across jobs. Following are some of the skills and job roles that the
majority of employers look for in a software developer:
 Ability to use more than one development language
 Design, test and develop software to meet user needs
 Critical thinking
 Keen attention to detail
 Write and maintain software
 Strong problem solver
 Create complex databases for organisations
 Document application process for future maintenance and upgrades
Self-Instructional
Material 13
Software Development Responsibilities of a Software Developer
Organization and Roles
In the role of a software developer, one has to work in a variety of industries /
organisations which means that the software developer could work on a variety of
projects. It is likely that software developer will work closely with developers,
NOTES
product managers, graphic designers and business analysts to find out what clients
want and the most efficient way to achieve them. In addition, the software developer
will be responsible to work on either the replacement of a whole system or modifying
software and integrating it into existing networks. Using a number of programming
tools and languages, the daily tasks of software developer may include the following:
 Talking through requirements with clients
 Testing software and fixing problems
 Maintaining systems once they’re up and running
 Being a part of technical designing
 Integrate software components
 Producing efficient codes
 Writing program codes for reference and reporting
Software engineers design, develop, and test software and applications for
computers. The main duties and responsibilities of software engineers include
directing and participating in programming activities, monitoring, and evaluating
system performance, and designing and implementing new programs and features.
The job of a software developer, therefore, depends on the needs of the
company, organization, or team they are working for. Some build and maintain
systems that run devices and networks. Others develop applications that make it
possible for people to perform specific tasks on computers, cell phones, or other
devices.

Check Your Progress

1. What is management spectrum?
2. Define the term organizational structure.
3. How the organization can be structured?
4. Explain the term hierarchical organization structure.
5. State about the flat organization structure.
6. What are the three types of matrix organizational structure?
7. Elaborate on the networked organization structure.
8. Define the term T-Form organization.

Self-Instructional
14 Material
 Software Development
1.5 ANSWERS TO CHECK YOUR PROGRESS Organization and Roles

QUESTIONS

1. In software engineering, the management spectrum describes the management NOTES

of a software project. The management of a software project starts from
requirement analysis and finishes based on the nature of the product, it may
or may not end because almost all software products faces changes and
requires support. It is about turning the project from plan to reality. Effective
software project management focuses on the four P’s: People, Product,
Process, and Project. The order is not arbitrary.
2. An organizational structure defines how activities, such as task allocation,
coordination, and supervision are directed toward the achievement of
organizational aims. Organizational structure affects organizational action
and provides the foundation on which standard operating procedures and
routines rest. It determines which individuals get to participate in which
decision-making processes, and thus to what extent their views shape the
organization’s actions. Organizational structure can also be considered as
the viewing glass or perspective through which individuals see their
organization and its environment.
3. An organization can be structured in many different ways, depending on its
objectives. The structure of an organization will determine the modes in
which it operates and performs. Organizational structure allows the expressed
allocation of responsibilities for different functions and processes to different
entities, such as the branch, department, workgroup, and individual.
4. A hierarchical organization is an organizational structure where every entity
in the organization, except one, is subordinates to a single other entity. This
arrangement is a form of a hierarchy. In an organization, the hierarchy usually
consists of a singular/group of power at the top with subsequent levels of
power beneath them. This is the dominant mode of organization among
large organizations; most corporations, governments, criminal enterprises,
and organized religions are hierarchical organizations with different levels
of management, power or authority.
A hierarchy is typically visualized as a pyramid, where the height of the
ranking or person depicts their power status and the width of that level
represents how many people or business divisions are at that level relative
to the whole—the highest-ranking people are at the apex, and there are
very few of them; the base may include thousands of people who have no
subordinates. These hierarchies are typically depicted with a tree or triangle
diagram, creating an organizational chart or organigram.
5. A flat organization (also known as horizontal organization) has an
organizational structure with few or no levels of middle management between
staff and executives. Self-Instructional
Material 15
Software Development 6. Matrix organizational structure is of following three types:
Organization and Roles
• Weak/Functional Matrix: A project manager with only limited authority
is assigned to oversee the cross- functional aspects of the project. The
functional managers maintain control over their resources and project
NOTES
areas.
• Balanced/Functional Matrix: A project manager is assigned to oversee
the project. Power is shared equally between the project manager and
the functional managers. It brings the best aspects of functional and
projectized organizations. However, this is the most difficult system to
maintain as the sharing of power is a delicate proposition.
• Strong/Project Matrix: A project manager is primarily responsible for
the project. Functional managers provide technical expertise and assign
resources as needed.
7. In the network structure, managers coordinate and control relationships
with the firm that are both internal and external. An organization can be
structured in various ways that determine how it operates and performs.
The network structure is a newer type of organizational structure often
viewed as less hierarchical (i.e., more flat), more decentralized, and more
flexible than other structures. In this structure, managers coordinate and
control relations that are both internal and external to the firm. From a
management perspective, the network structure is unique among other
organizational structures that focus on the internal dynamics within the firm.
8. At present, the technology is changing organizations structure. One impact
of Information Technology (IT), is the use of information technology design
variables to develop new organizational structures. The organization that is
most likely to result from the use of these variables is the T-Form or
Technology-Form organization, an organization that uses IT to become highly
efficient and effective.

1.6 SUMMARY

 In software engineering, the management spectrum describes the

management of a software project.
 The management of a software project starts from requirement analysis
and finishes based on the nature of the product, it may or may not end
because almost all software products faces changes and requires support.
It is about turning the project from plan to reality.
 Effective software project management focuses on the four P’s: People,
Product, Process, and Project. The order is not arbitrary.
 Fundamentally, the management spectrum is a flowchart how to handle a
software project or how to make a project successful. People, Product,
Self-Instructional
16 Material
 Process, and Project are the four P’s that it focuses on. The project manager Software Development
Organization and Roles
must keep track of all of these P’s in order to maintain a smooth flow in the
project’s development and achieve the target.
 People of a project includes from manager to developer, from customer to
NOTES
end user. But mainly people of a project highlight the developers.
Organizations that achieve high levels of maturity in the people management
area have a higher likelihood of implementing effective software engineering
practices.
 The product is the ultimate goal of the project. This is any types of software
product that has to be developed.
 To develop a software product successfully, all the product objectives and
scopes should be established, alternative solutions should be considered,
and technical and management constraints should be identified beforehand.
 A software process provides the framework from which a comprehensive
plan for software development can be established. A number of different
tasks sets— tasks, milestones, work products, and quality assurance
points—enable the framework activities to be adapted to the characteristics
of the software project and the requirements of the project team.
 The project is the complete software project that includes requirement
analysis, development, delivery, maintenance and updates. The project
manager of a project or sub-project is responsible for managing the people,
product and process.
 An organizational structure defines how activities, such as task allocation,
coordination, and supervision are directed toward the achievement of
organizational aims.
 Organizational structure affects organizational action and provides the
foundation on which standard operating procedures and routines rest. It
determines which individuals get to participate in which decision-making
processes, and thus to what extent their views shape the organization’s
actions.
 Organizational structure can also be considered as the viewing glass or
perspective through which individuals see their organization and its
environment.
 An organization can be structured in many different ways, depending on its
objectives. The structure of an organization will determine the modes in
which it operates and performs.
 Organizational structure allows the expressed allocation of responsibilities
for different functions and processes to different entities, such as the branch,
department, workgroup, and individual.
 Organizations need to be efficient, flexible, innovative and caring in order to
achieve a sustainable competitive advantage. Self-Instructional
Material 17
Software Development  A hierarchical organization is an organizational structure where every entity
Organization and Roles
in the organization, except one, is subordinates to a single other entity. This
arrangement is a form of a hierarchy.
 In an organization, the hierarchy usually consists of a singular/group of power
NOTES
at the top with subsequent levels of power beneath them. This is the dominant
mode of organization among large organizations; most corporations,
governments, criminal enterprises, and organized religions are hierarchical
organizations with different levels of management, power or authority.
 A hierarchy is typically visualized as a pyramid, where the height of the
ranking or person depicts their power status and the width of that level
represents how many people or business divisions are at that level relative
to the whole—the highest-ranking people are at the apex, and there are
very few of them; the base may include thousands of people who have no
subordinates. These hierarchies are typically depicted with a tree or triangle
diagram, creating an organizational chart or organigram.
 A matrix organizational structure is normally used in the companies to
distribute resources and workers across multiple operations. This type of
structure can have both advantages and disadvantages within the workplace.
Understanding the benefits and shortcomings of a matrix organizational
structure will help to determine that can this type of structure is appropriate
for the company.
 Characteristically, every organization is structured in some way, and that
specific structure is determined by the organization’s objectives. The structure
of an organization specifies a standard for operating procedures and routines.
It will also determine who participates in what, and whatever project tools
are best suitable for the job at hand.
 In the network structure, managers coordinate and control relationships
with the firm that are both internal and external.
 An organization can be structured in various ways that determine how it
operates and performs. The network structure is a newer type of
organizational structure often viewed as less hierarchical (i.e., more flat),
more decentralized, and more flexible than other structures. In this structure,
managers coordinate and control relations that are both internal and external
to the firm.
 From a management perspective, the network structure is unique among
other organizational structures that focus on the internal dynamics within the
firm.
 At present, the technology is changing organizations structure. One impact
of Information Technology (IT), is the use of information technology design
variables to develop new organizational structures. The organization that is
most likely to result from the use of these variables is the T-Form or
Self-Instructional
18 Material
 Technology-Form organization, an organization that uses IT to become highly Software Development
Organization and Roles
efficient and effective.
 Information Technology (IT) is usually regarded as a supporting component
to organizational structure. Now some managers believe that IT design
NOTES
variables can not only help an organization implement its chosen strategy,
but also suggest a strategy to the firm.
 Some organizations take the networked structure one step further, and a
different organization form, the T-Form organization come into being.
 The T-Form organization has a flat structure through electronic linking and
communication. Its common features include electronic workflows and
production automation.
 T-Form organization minimizes the use of paper and relies extensively on
imaging devices and optical data storage.
 The job role of a software developer engages in identifying, designing,
installing and testing a software system they have built for a company from
the ground up. It can range from creating internal programmes that can help
businesses be more efficient to producing systems that can be sold on the
open market.
 The main duties and responsibilities of software engineers include directing
and participating in programming activities, monitoring, and evaluating system
performance, and designing and implementing new programs and features.

1.7 KEY WORDS

 Management spectrum: The management spectrum is a flowchart how

to handle a software project or how to make a project successful.
 Software process: A software process provides the framework from which
a comprehensive plan for software development can be established.
 Organizational structure: An organizational structure defines how
activities, such as task allocation, coordination, and supervision are directed
toward the achievement of organizational aims.
 Matrix organizational structure: The matrix structure groups employees
by both function and product simultaneously.
 Networked organizational structure: In the network structure, managers
coordinate and control relationships with the firm that are both internal and
external.
 T-Form organization: The organization that is most likely to result from
the use of these variables is the T-Form or Technology-Form organization,
an organization that uses IT (Information Technology) to become highly
efficient and effective.
Self-Instructional
Material 19
Software Development
Organization and Roles 1.8 SELF-ASSESSMENT QUESTIONS AND
EXERCISES

NOTES Short-Answer Questions

1. Explain the term management spectrum.
2. Why organizational structure is required?
3. What is hierarchical organizational structure?
4. Write the advantage of flat organizational structure.
5. Define the term matrix organizational structure.
6. Explain the disadvantage of networked organizational structure.
7. Write the definition of T-Form organizational structure.
8. What is the job roles in software developer?
Long-Answer Questions
1. Briefly explain the concept of management spectrum with the help of diagram
and examples.
2. Explain the significance of organizational structure giving appropriate
examples.
3. Discuss about the hierarchical organizational structure and its advantages
and disadvantages.
4. Describe the term flat organizational structure with the help of an example.
5. Why matrix organizational structure is used? Explain giving appropriate
examples.
6. Briefly explain the networked organizational structure giving appropriate
examples.
7. Discuss in details about the T-Form organizational structure.
8. Explain the job roles in software development.
9. Brief a note on skills, job roles and responsibilities of a software developer.

1.9 FURTHER READINGS

Hughes, Bob, Mike Cotterell and Rajib Mall. 2017. Software Project
Management (SIE), 6th Edition. New York: McGraw Hill Education.
Schach, Stephen R. 2005. Object Oriented and Classical Software Engineering.
New Delhi: Tata McGraw-Hill.

Self-Instructional
20 Material
Pressman, Roger S. 1997. Software Engineering, a Practitioner’s Approach. Software Development
Organization and Roles
New Delhi: Tata McGraw-Hill.
Somerville, Ian. 2001. Software Engineering. New Delhi: Pearson Education.
Ghezzi, Carlo, Mehdi Jazayeri, and Dino Mandriolli. 1991. Fundamentals of NOTES
Software Engineering. New Delhi: Prentice-Hill of India.
Jawadekar, Waman S. 2004. Software Engineering: Principles and Practice.
New Delhi: Tata McGraw-Hill.
Jalote, Pankaj. 1991. An Integrated Approach to Software Engineering. New
Delhi: Narosa Publishing House.

Self-Instructional
Material 21
Overview of Project
Management
UNIT 2 OVERVIEW OF PROJECT
MANAGEMENT
NOTES
Structure
2.0 Introduction
2.1 Objectives
2.2 Project Management
2.3 Project Management Definitions
2.4 Factors Influencing Project Management
2.5 Project Manager
2.6 Project Management Activities
2.7 Stakeholders
2.8 Project Communication
2.9 Project Development Phases
2.10 Project Charter
2.11 Statement Of Work (SOW)
2.12 Project Management Associations
2.13 Answers to Check Your Progress Questions
2.14 Summary
2.15 Key Words
2.16 Self Assessment Questions and Exercises
2.17 Further Readings

2.0 INTRODUCTION

Project management is the process of leading the work of a team to achieve goals
and meet success criteria at a specified time. The primary challenge of project
management is to achieve all of the project goals within the given constraints. This
information is usually described in project documentation, created at the beginning
of the development process. The primary constraints are scope, time, and budget.
The secondary challenge is to optimize the allocation of necessary inputs and apply
them to meet pre-defined objectives. Project management is the art of directing
and coordinating the human and material resources throughout the project by
using modern management techniques. The main purpose of project management
is to achieve the predetermined objectives of scope, cost, time, quality and the
satisfaction of the participant.
The main responsibility of a software project manager is to plan and schedule
software project development tasks. A software project manager is concerned
about whether the product meets the required standards and be finally available
for use after meeting the time and financial constraints. The task of a software
manager is the same as that of the project manager of other engineering disciplines.
Software project managers take the overall responsibility of steering a project to
Self-Instructional
22 Material
success. It is very difficult to objectively describe the job responsibilities of a Overview of Project
Management
project manager. The job responsibility of a project manager ranges from invisible
activities, such as building team morale to highly visible customer presentations.
Project Management Institute (1996), project communications management
NOTES
includes processes required to ensure timely and appropriate generation, collection,
dissemination, storage, and ultimate disposition of project information. Project
management is the process of leading the work of a team to achieve goals and
meet success criteria at a specified time. The primary challenge of project
management is to achieve all of the project goals within the given constraints.
Project charter is a statement of the scope, objectives, and participants in a project.
A Statement Of Work (SOW) is a document routinely employed in the field
of project management.
In this unit, you will study about the project management, project management
definitions, factors influencing project management, project manager, project
management activities, stakeholders, project communication, project development
phases, and project charter, Statement Of Work (SOW), and project management
associations.

2.1 OBJECTIVES

After going through this unit, you will be able to:

 Define the project management
 Explain the project management definitions
 Elucidate on the factors influencing project management
 Understand the basics of project manager
 Discuss about the project management activities
 Explain the stakeholders
 Analysis the project communication
 Elaborate on the project development phases
 Understand the basics of project charter
 Define the Statement Of Work (SOW)
 Elucidate on the project management associations

2.2 PROJECT MANAGEMENT

Project management is the art of directing and coordinating the human, and material
resources throughout the project by using modern management techniques. The
main purpose of project management is to achieve the predetermined objectives
of scope, cost, time, quality and the satisfaction of the participant.
Self-Instructional
Material 23
Overview of Project Project management includes developing and implementing a plan for the
Management
project while considering the available resources, such as manpower, material
and cost in the organization. Project management involves the following activities:
 Planning and analysing the objectives of the project
NOTES
 Measuring and controlling the risk-involved in the project
 Estimating the organizational resources required in the project
 Assigning tasks to the employees related to the project
 Directing and motivating employees to improve their performance
 Organizing project activities
 Formulating the project
 Forecasting trends in the project
 Completing the project on time
 Keeping up the quality of the project
Characteristics of Project Management
Project management is concerned with achieving a specific goal in a given time by
using the resources available for that specific period. Project management requires
attention for goal-oriented systems, the environment, sub-systems and their
relationships. This is what makes project management a ‘systems approach’ to
the management.
The application of principles and practices from the classical, behavioural
and systems viewpoints to the unique requirements of projects has led to a new
set of concepts which may be called the ‘Project Viewpoint’. Cleland and King
have identified the following characteristics of project management:
 The project manager is the single focal point for bringing together all the
necessary resources for achieving the project objectives. He/she formally
heads the project organization and operates independently the normal
chain of commands. The project organization reflects the cross-functional,
goal-oriented nature of the project.
 Since each project requires a variety of skills and resources, many
functional areas may perform the work in a combined form. The project
manager is responsible for integrating the people from different functional
disciplines working on the project.
 The project manager will negotiate directly with the functional managers
for support. The functional managers are responsible for the activities of
the individuals and for the personnel coming under the scope of their
functional groups. However, the project manager has to concentrate on
integrating all the project activities and overseeing the activities from the
beginning to end.
Self-Instructional
24 Material
  The project manager focuses on delivering a particular product or service Overview of Project
Management
at a certain point of time and cost to the satisfaction of the technical
requirements. In contrast, the functional units must maintain an ongoing
pool of resources to reach the ultimate organizational goals instead of
the limited project goals. Thus, conflicts may often arise between the NOTES
project and functional managers over the optimum allocation of resources
to a project.
 A project in an organizational structure has two chains of command.
One is the vertical, functional reporting relationship and the other is the
horizontal, project reporting mechanism.
 For rewarding incentives and distributing responsibilities, the decision-
making, accountability, outcomes and rewards should be shared among
all the members of the project team and the supporting functional units.
 Though the project organization is temporary, the functional units from
which it is formed are permanent. Thus, when a project ends, the project
team is scattered and the project personnel either return to their functional
units or they are reassigned to new projects. Projects may originate
from different areas of the organization. Product development and related
projects tend to emerge from marketing whereas technological
applications originate in Research and Development (R&D).
 Project management sets into motion numerous other support functions,
such as personnel evaluation, accounting and information systems.
Prerequisites for Successful Project Management
In order to reduce the cost of constructing a project, organizations should consider
various factors, such as cost and time for the successful competition among projects.
Following are the prerequisites for a successful project management:
 Adequate Project Formulation: Project formulation is the process of
converting project ideas into project proposals in a structured manner.
Generally, project formulation suffers from the following shortcomings:
o Use of informal methods for estimating the costs and benefits, such as
maintaining paper records instead of using computers
o Deliberate overestimation of benefits and underestimation of cost of
constructing a project
o Faulty judgements due to lack of experienced managers and employees
It is essential for an organization to avoid these shortcomings in order
to have adequate and meaningful project formulation.
 Project Organization: A sound organization possesses the following
characteristics:
o Proper working environment for employees
o Well-defined working methods and systems Self-Instructional
Material 25
Overview of Project o Proper rewards and penalties to employees for their performances
Management
and faults
 Implementation Planning: After taking investment-related decisions, it is
necessary for an organization to do proper implementation planning before
NOTES
commencing the actual implementation. Proper implementation planning
includes the following steps:
o Developing a plan for various activities, such as land acquisition, tender
evaluation, recruitment of the staff, construction of buildings and
creation of an industrial plant
o Estimation of the resource requirements, such as manpower, materials
and money in project
 Availability of Funds on Time: It is important to have funds on time for
taking advanced actions in the project activities. Timely availability of funds
facilitates the organization to negotiate the cost of the project with suppliers
and contractors.
 Effective Monitoring: In order to have a successful management of the
project, a project monitoring system must be established in the organization.
This is because effective monitoring helps in analysing the emerging problems
and taking corrective actions for the project activities. Following are the
factors that should be kept in mind while developing an effective system of
monitoring:
o It should emphasize all the critical aspects, such as the finance of the
project management.
o It should be simple and not overcomplicated as it may result in a lot of
documentation and wastage of resources.
Principles of Project Management
Successful project management can be achieved by proper application of principles
instead of implementing different kinds of techniques. Following are the seven
principles of project management:
 To identify the project type that is suitable for the business. One needs to
select the projects that are good for business.
 To understand the needs and expectations of the customers.
 To prepare the reasonable plans which defines the scope, cost and approach
of the project. This helps in reducing unplanned areas in the project.
 To establish a good team with a good leader. This principle conveys that
there should be proper working environment and communication flow
between the project managers and team members.
 To define the status of the project. This helps improving the project quality
and recognizing the various problems in it.
Self-Instructional
26 Material
  To make a proper assumption for the project. This principle focuses on the Overview of Project
Management
verification of the critical items used in the project in order to reduce the
risk.
 To take proactive actions in the problems of the project. This is because the
NOTES
problem usually gets worse over time which in turn increases the chances of
risk.
Scope of Project Management
The scope of a project is determined by using product scope and project scope.
Product scope explains all the functions and features that are to be included in a
product or service of the project. On the other hand, project scope deals with the
deeds to be done for delivering the needed product. The tools and techniques to
manage the product scope change with the nature of the project.
The project manager uses various tools and techniques, such as product
and cost-benefit analysis for developing the scope of a project. Once the project
has been selected, the project manager and the client jointly prepare the scope of
the project and deliverables.
Importance of Project Management
Organizations have to manage their projects effectively in order to create and
maintain their reputation in the market. Many organizations fail to manage their
projects properly due to the following reasons:
 Project is completed late or without fulfilling the demands of the client
 Project is not giving any valuable information
 Project lacks proper planning and organization of the activities
 The techniques and standards used are not advanced
A good project management offers various techniques and guidelines to manage
employees and workloads. Project management provides the following benefits in
an organization:
 Saving Cost: Project management offers a common methodology for
managing the project, i.e., if the processes and procedures are planned
once, then they can be used in all the future projects again. Consequently, it
helps in saving the cost and time required in completing the project.
 Improving Working Conditions: If the projects are successful, the client
will be more involved in the projects. This helps in improving the working
environment of the organization, which in turn encourages the morale and
confidence of the project team.
 Improving Financial Management: Better estimation of the actual costs
involved in the project helps in managing the budget of the organization.
This results in better financial predictability and cost control.
Self-Instructional
Material 27
Overview of Project  Resolving Problems: Team members in a project spend a lot of time and
Management
energy in dealing with project problems. This is because the project team
members do not know how to resolve the project problems. If the project
is properly managed and planned, then the process of project management
NOTES helps in solving the project problems quickly.
 Determining Risk: The process of project management helps in identifying
and managing risks in the near future.
 Improving the Product Quality: The process of project management helps
team members understand the needs of customers. Once customer needs
are recognized, team members can implement quality control and assurance
techniques to fulfil customer demands.
Need for Project Management
Modern project management ideas originated in the construction and aerospace
industries in the USA and Western countries. This was because the environment
and activities in those industries demanded flexible and imaginative forms of
management. The spread of project management ideas has come about due to
necessity rather than desire. The major reason for its slow growth can be attributed
to the reluctance in accepting new approaches and techniques. The major problems
identified by the managers, who attempted the new system, revolve around conflicts
in authority and resources. The three major problems identified are as follows:
 Project priorities and competition for talent would interrupt the stability of
the organization and interfere with its long-range interests by upsetting the
normal business of the functional organizations.
 Long-range planning would suffer if the company gets more involved in
meeting the schedules and fulfilling the requirements of temporary projects.
 Shifting people from project to project would disrupt the training of new
employees and specialists.
Let us briefly consider some of the organizational factors influencing the need for
project management.
(i) The first is the size of the organization. A small organization, such as a
consulting firm, an engineering office or a small contractor who has a budget,
a schedule and limited requirements to control quality and production could
get along without any formal project organizational system. However, the
quantitative methods and procedures of the project management approach
are still necessary. On the other hand, a large organization executing a
prestigious, complex, multi-disciplinary and capital-intensive project would
certainly require a formal project management organizational system as well
as quantitative techniques.

Self-Instructional
28 Material
 (ii) The second factor is the style of management needed to meet the complexities Overview of Project
Management
of a rapidly changing business environment. Most industrial, public service
and government organizations have solved the problem of complexity due
to a hierarchical management structure inherited from the military. The top
management has been very comfortable with the hierarchy because of its NOTES
simple ‘one boss’ reporting system. The hierarchy also lends itself to
convenient subdivision of the organization into groups or departments, each
of which represents a speciality, a discipline or a function.
While these so-called line, functional or disciplinary divisions often enhance
efficiency and maximize productivity, they suffer from the following flaws:
 The ability of a specialized organization to work together and coordinate
effectively with external agencies, such as the clients, vendors and
regulatory agencies is critical to the success of the project. Line
managers often suffer from ‘tunnel vision’ or lack of knowledge of the
overall organizational goals. In addition, competition between line
divisions may result in inefficiency or failure to communicate vital
information.
 The responsibility for important external coordination may become
mixed-up because of overlapping or inadequately defined roles. The
allocation of responsibility for a job that overlaps several functional
divisions in a project complicates the process of decision-making
affecting the entire project. This may increase the possibility of
inadequate or tardy responses to changing conditions which could
make all the differences between the success or failure of a project.
 As an organization grows in size and complexity, it becomes
increasingly difficult for the top management to connect itself with the
day-to-day problems of each project.
A chief executive may face a project failure for any of these reasons, and in
an attempt to determine the cause for the failure, the executive may find the divisional
managers blaming each other. It can be a very disturbing experience for the top
management to realize their inattentiveness over the official issues. A chief executive
needs a single point of information and control if complex projects are to be
successfully completed.
In determining the need for project management, one should examine the
project and organization carefully and ask the following questions:
 Is the job very large?
 Is the job technically very complex?
 Is the job a true system in which it has many separate parts or sub-
systems that must be integrated to complete the operation as whole?

Self-Instructional
Material 29
Overview of Project  Is the job a part of a larger system and must be closely integrated,
Management
especially if the larger system has a project-oriented organization?
 Does the top management really feel the need for a single point of
information and responsibility for the total job?
NOTES
 Are strong budgetary and fiscal controls required?
 Are tight schedules and budgetary constraints foreseen?
 Are quick responses to changing conditions necessary?
 Does the job cross many disciplinary and organizational boundaries?
 Will the proposed job drastically disrupt the present organizational
structure?
 Are more than two divisions involved? Is more than one division going
to deal directly with the client or customer?
 Are there other complex projects being conducted concurrently with
this one?
 Is there scope for a conflict between the line managers concerning this
project?
 Is the organization committed to a firm completion date?
 Is it likely that changing conditions may seriously affect the project before
its completion?
 Are there major items to be procured from outside the company?
 Are there major portions of the system which must be sub-contracted
outside the organization?
 Is it necessary to have the project reviewed or approved by government
regulatory agencies? Will these review processes and approvals generate
problems and controversy?
The answers to the above questions help in the various project management
considerations for an organization. From the above discussions, it can be concluded
that project management can be applied to any ad hoc undertaking. This includes
a broad range of activities, such as writing a research paper, remodelling a house
or constructing a children’s park. There are two situations in which project
management should be used:
 The more unfamiliar or unique the undertaking, the greater the need for
project management to ensure that nothing gets overlooked.
 The more numerous, interdisciplinary and interdependent activities in
the undertaking, the greater the need for a project manager to ensure
that everything is coordinated, integrated and completed.

Self-Instructional
30 Material
 Cleland and King have suggested five general criteria to decide when to use Overview of Project
Management
project management techniques and the corresponding organizational structures.
These criteria are briefly described below:
 Effort: The magnitude of the effort should be more when the job requires
more resources in an organization and for this purpose the project NOTES
management techniques are necessary. For example, the Atlas missile
programme requires major undertakings in the defence, aerospace,
space, energy and transportation sectors. However, micro-level industrial
activities may also need formal project management, e.g., in the case of
relocation of facilities, merger of two companies, placing of a new product
on the market, etc.
 Coordination: Even when a job lies primarily in one functional area, the
task of coordinating its work with the other functional area is necessary.
For example, the task of computer installation in a company may seem
to be the sole concern of the Electronic Data Processing (EDP)
department, as many corporate executives thought during the last two
decades in India. Only a few smart executives and organizations realized
early on in the game that during the process of computerization, there
will be a continuous meshing of policies, procedures and resources of
all the departments affected by computer installation. Often hundreds of
people may be involved and the required coordination and integration
might be more than what a single department, such as EDP can tackle
efficiently and effectively.
 Modification: A project always requires modifications from time to
time. Minor changes in products, such as annual automobile design
changes can usually be accomplished without setting up a project team.
On the other hand, undertaking the modernization of an automobile plant
calls for non-routine efforts, such as revising the facilities layout, modifying
the assembly line, replacing equipment, retraining employees and altering
policies and work procedures. For this, project management requires
to bring all the functional areas together. In a changing environment with
rapid changes taking place in the economic, social and technological
environment, more and more industrial organizations are seeking creative,
innovative and flexible forms of management. Companies that operate
in the computers, communications, electronics and pharmaceutical
sectors are exposed to high innovations, rapid product changes, shifting
markets and consumer behaviour. Other industries, such as those in
biotechnology, petrochemicals and ceramics, though less volatile, also
have highly competitive and dynamic environments.
 Changing Environment: Another aspect of the changing environment
that is particularly relevant for the Indian economy is the government’s
policy of liberalization and transition to the free market mode. Changing
environments present opportunities that organizations must capture swiftly.
Self-Instructional
Material 31
Overview of Project Project management provides flexibility and diversity needed to deal
Management
with changing goals and new opportunities. When a joint effort is
required, project management attempts to build lateral relationships
between functional areas in order to accelerate work and reconcile the
NOTES conflicts inherent in multi-functional and multi-disciplinary organizations.
The project manager links and coordinates the efforts of the divisions
within the parent organization as well as those of the outside: sub-
contractors, suppliers and customers.
 Reputation: The reputation of the undertaking and what is at stake
may determine the need for project management. An unsuccessful project
will result in either a loss of future contracts, damaged reputation, loss
of market share or, in the worst case, financial ruin; therefore, there is a
strong case for utilizing formal project management techniques and
organizational form. For example, in the launching of American
multinational Pepsi soft drinks and snack food operations in India or
introduction of its new 1000 c.c. car by Maruti Udyog Ltd. or setting
up of its joint venture in the form of Tata-IBM by IBM Corporation
formally, each of the undertakings warranted the adoption of a formal
project management approach. The obvious reason, in each of the above
cases, is that the likelihood of successfully completing the undertaking is
increased when a single competent individual is assigned responsibility
for overseeing it. The project manager, with the assistance of technical
support groups, can do much to reduce the problems inherent in large,
complex undertakings.

2.3 PROJECT MANAGEMENT DEFINITIONS

Project management is the application of processes, methods, skills, knowledge

and experience to achieve specific project objectives according to the project
acceptance criteria within agreed parameters. Project management has final
deliverables that are constrained to a finite timescale and budget.
Project management is the process of leading the work of a team to achieve
goals and meet success criteria at a specified time. The primary challenge of project
management is to achieve all of the project goals within the given constraints. This
information is usually described in project documentation, created at the beginning
of the development process. The primary constraints are scope, time, and budget.
The secondary challenge is to optimize the allocation of necessary inputs and apply
them to meet pre-defined objectives. The objective of project management is to
produce a complete project which complies with the client’s objectives. In many
cases the objective of project management is also to shape or reform the client’s
brief to feasibly address the client’s objectives. Once the client’s objectives are
clearly established they should influence all decisions made by other people involved
Self-Instructional
32 Material
in the project – for example project managers, designers, contractors and sub- Overview of Project
Management
contractors. Ill-defined or too tightly prescribed project management objectives
are detrimental to decision making.

NOTES
2.4 FACTORS INFLUENCING PROJECT
MANAGEMENT

The success of a project relies on several factors, such as the quality of product
and the availability of resources. Following are the factors that affect a project:
 Scope: This explains all the activities that one needs to perform in a project.
The scope of a project consists of target results, financial and human
resources.
 Quality: This is necessary for a project to satisfy the quality requirements
at the levels related to ‘product quality’ and ‘process quality’. The first
quality requirement is related the products resulting from the project and
the second is related to the management process. A comprehensive quality
management system helps in the effective utilization of the scarce resources
for achieving the project objectives.
 Time: This is one of the most important constraints in completing a project.
The client decides the time limit of the project and it is essential to complete
the project within that particular time. This is because there is an indirect
relationship between cost and time, that is, if the time to complete a project
increases, then the cost involved decreases and vice versa.
 Cost: Project cost consists of the monetary resources needed to complete
the activities mentioned in the scope of a project. Project costs are the cost
incurred on planning and implementing the activities of the project. The
client makes a budget on the basis of the costs of the activities involved
from which the project manager has to deliver the product.
 Resources: This includes people, financial and the physical resources.

2.5 PROJECT MANAGER

The main responsibility of a Software Project Manager is to plan and schedule

software project development tasks. A software project manager is concerned
about whether the product meets the required standards and be finally available
for use after meeting the time and financial constraints. (Brooks 1975)
The task of a software manager is the same as that of the project manager
of other engineering disciplines. But to some extent, the job of a software engineer
is considered to be different and difficult (Sommerville, 1998) from that of the
other types of engineers. The following are some reasons why a software project
manager differs from other engineers:

Self-Instructional
Material 33
Overview of Project 1. The intangible nature of a software product: As the software product
Management
does not have any physical appearance and can neither be seen nor be
touched, so, for a project manager it is difficult to monitor the progress.
The project manager has to rely on the documentation developed by others
NOTES to review the progress.
2. Lack of standard process: There are many software processes that
have been developed in the last few years and it is difficult to clearly
outline the relationship between the software process and the type of
product. It is difficult to clearly predict with certainty which process is
likely to cause problems in development.
3. Big difference in the new system: It is common for a new system to
be different from the previous projects in many ways. Because of this
‘one-off’ nature of projects, the extensive experience gained in the previous
project cannot be used in the new project to reduce uncertainties.
Thus, the objective of project management is to ensure that a software
product meets the quality specifications of the requirement definitions to be
produced on schedule and at an economically justifiable cost within the planned
resources (Royce 1998; Conte 1986).
Traditional project management has tasks grouped under three categories,
which are as follows:
 Planning—Planning comprises tasks such as setting up overall objectives
for the project; decomposing a task into smaller components; deciding
and planning the process, methodology and life cycle phases for the
purpose of construction of the software system; recruiting skilled people
required to work on the system, both internally and externally; assigning
tasks and responsibilities to the team members; developing quality project
plans and identifying logistics such as, hardware, development environment
and tools, long lead time items, and so on.
 Doing—It refers to enabling the project members to commence and
perform the tasks assigned to them.
 Monitoring and adjusting—It refers to the frequent collection of
progress reports, evaluation of the original as compared with the planned
report against the metrics and milestones as set. Post collection and
comparison, the required adjustments and corrections are made, if any.
Changes in the Management Framework Over the Years
Management framework has led to the evolution of many innovative and
breakthrough ideas over the years. Perceived needs lead to different ideas being
expressed at different times in accordance with the sentiments as prevalent in the
society. The process of evolution is continuous. Ideas and concepts change
frequently.
1. Management framework is like the philosophy of life. It helps an organization
to build a road map, a guide to deal with problems that arise along the
Self-Instructional
34 Material
 course of the project. The core function of a management framework is to Overview of Project
Management
provide direction and also chart the time at which activities need to be
performed.
2. Different management frameworks emphasize on different points. But they
NOTES
are usually compatible with each other. Most of the management approaches
do not believe in doing one thing at a time and exclude or neglect other
things in a project.
A comprehensive framework is one that covers all the vital areas that a
project manager needs to look into. A management framework approach is holistic
in all aspects and it must have all the five arts of business management framework
supporting each other. It is the ideal approach to address technical management
issues. It becomes even more effective when it is supplemented with other arts of
business management framework, related to the domain of a particular problem.
In the subsequent units, you will study:
 The usage and incorporation of principles and techniques, comprehensive
coverage of technical management related problems, inclusive of areas
such as people, process, technology leverage, organization and leadership.
 Emphasis on practices based on lessons from real-life case studies and
solutions therein.
 Being up-to-date on technical management knowledge that reflects current
technology and business reality (e.g., the importance of scripting language,
design pattern, and the reality of outsourcing).
 Greater emphasis on the approach that focuses on achieving long-term
success in projects by improving the process, people/team, infrastructures
and core knowledge.

2.6 PROJECT MANAGEMENT ACTIVITIES

Responsibilities of a Software Project Manager

Software project managers take the overall responsibility of steering a project to
success. It is very difficult to objectively describe the job responsibilities of a
project manager. The job responsibility of a project manager ranges from invisible
activities such as building team morale to highly visible customer presentations.
Most managers take responsibility for project proposal writing, project cost
estimation, scheduling, project staffing, software process tailoring, project monitoring
and control, software configuration management, risk management, interfacing with
clients, managerial report writing and presentations. These activities are varied
and difficult to enumerate, but they can be broadly classified into project planning
and project monitoring and control activities.

Self-Instructional
Material 35
Overview of Project Project planning activity is undertaken before the developer starts to plan
Management
the activities to be undertaken during development. Project monitoring and control
activities are undertaken once the development activities commence with the aim
of ensuring that development proceeds as per plan and changes are made in the
NOTES plan, whenever required, to cope up with the situation.
A project manager has to carry out the following major activities:
1. Project proposal writing
2. Project planning
3. Project scheduling
4. Project tracking
5. Personal selection and evaluation
6. Project report writing
1. Project proposal writing: Project proposal writing requires special skill
which is always gained by experience. The existence and growth of a
software organization depends on having enough project proposals
accepted and contracts awarded. There are no set guidelines for writing
a project and it depends mainly on the project manager’s skill to write a
project proposal in such a way that it is able to satisfy the customer in all
respects.
2. Project planning: Project planning is done to identify the activities,
milestones and deliverables produced in a project. There must be a clear
and a well defined plan to guide the development activities for the
achievement of project goals.
3. Project scheduling: Project Scheduling is the most critical task. Here,
the activity involves the total work of the project being divided into separate
tasks in order to visualize when these tasks will be completed. Some of
these tasks may go parallel to one another. In order to utilize the workforce
optimally, the project scheduler coordinates these parallel tasks and
organizes work accordingly.
4. Project tracking: Project tracking is a continuous work. This is also
known as project monitoring. The manager keeps track of the progress
of the project and compares actual and planned progress and cost.
5. Personnel selection and evaluation: Personnel selection and evaluation
requires special skill. A project manager is always bothered about the
proper selection of skilled and experienced staff to work on the project.
Sometimes, the project manager has to manage the show with some less-
skilled and experienced workforce.
6. Project report writing: Project report writing is the responsibility of the
project manager for both the client and contractor organizations. It is
always desirable to write concise, coherent documents that abstract critical
information from the detail project reports.

Self-Instructional
36 Material
Skills necessary for Software Project Management Overview of Project
Management
Theoretical knowledge of different project management techniques is certainly
necessary to become a successful project manager. However, effective software
project management frequently calls for good qualitative judgement and decision- NOTES
making capabilities. In addition to having a good grasp of the latest software,
project management techniques such as cost estimation, risk management,
configuration management, project managers need good communication skills and
the ability to get work done. However, some skills such as tracking and controlling
the progress of the project, customer interaction, managerial presentations, and
team building are largely acquired through experience. Nonetheless, the importance
of bearing sound knowledge of the prevalent project management techniques cannot
be overemphasized.
Sliding Window Planning
Project planning requires utmost care and attention since commitment to unrealistic
time and resource estimates result in schedule slippage. Schedule delays can cause
customer dissatisfaction and adversely affect team morale. It can even cause project
failure. However, project planning is a very challenging activity. Especially, in the
case of large projects, it is very difficult to make accurate plans. A part of this
difficulty is due to the fact that proper parameters, scope of the project, project
staff, etc., may change during the span of the project. In order to overcome this
problem, sometimes, project managers undertake project planning in stages.
Planning a project over a number of stages protects managers from making big
commitments too early. This technique of staggered planning is known as Sliding
Window Planning. In this technique, starting with an initial plan, the project is
planned more accurately in the successive development stages. At the start of a
project, project managers have incomplete knowledge about the details of the
project. Their information base gradually improves as the project progresses through
different phases. After the completion of every phase, project managers can plan
each subsequent phase more accurately and with increasing levels of confidence.

Check Your Progress

1. Explain the scope of project management.
2. Write the three major problem of project management.
3. Give the definition of project management.
4. Explain the main responsibility of project manager.
5. Write the major activity of project management.

Self-Instructional
Material 37
Overview of Project
Management 2.7 STAKEHOLDERS

Stakeholders are people who have stake or interest in a project. The project
NOTES manager should identify them at the earliest so that he can establish an adequate
communication channel with them right from the beginning. All the people who are
involved in the project have different kinds of expectation and motivation.
Although a project in general is defined by the desired end result and
technology used, it is the people who make a project different from another. A
software project management process is very much stakeholder-driven.
Stakeholders are people who have interest and are concerned about a project.
As a software project manager, one should identify and focus on the stakeholders:
their wishes and fears. A stakeholder can be a project team member, an employee
of the users’ organization or a member of the management group. In general, it can
be anyone, as long as the person has something to do with the project. It is
recommended that ‘The project manager can use stakeholder analysis to determine
the stakes and expectations of the stakeholders, and adopt the project organization
and feedback mechanism according to the desired outcome.’
The steps for stakeholder-analysis are
1. Identification of stakeholders
2. Expectations and interests of the stakeholders
3. Influence of the stakeholder and his role in the project
At the end of the analysis, we will have the following answers:
1. A list of all the stakeholders
2. An idea about each stakeholder’s relative importance and influence
3. Insight into what a stakeholder wants out of the project
4. Insight into what makes stakeholders tick
5. An idea about whether stakeholders will work against or for the project

2.8 PROJECT COMMUNICATION

As defined by the Project Management Institute (1996), project communications

management includes processes required to ensure timely and appropriate
generation, collection, dissemination, storage, and ultimate disposition of project
information. Communication and management are closely linked together. Since
communication is the process of information exchange of two or people and
management includes managers that basically gives out information to their people.
Moreover, Communication and Management literally go hand in hand. It is the
way to extend control; the fundamental component of project management. Without
the advantage of a good communications management system, the cycles associated
with the development of a task from start to finish can be genuinely compelled. It
also gives the fundamental project integrity needed to give an information help
Self-Instructional
38 Material
among all individuals from the team. This information must stream descending, Overview of Project
Management
upward and horizontally inside the association. Moreover, it is both Master and
servant of project control. It is the action component, the integrator of the process
toward assembling the project. As project management is both a craftsmanship
and a science, the project manager leads the multidiscipline of the plan and construct NOTES
team. The following communication processes are involved in Project
Communications Management are-
 Communication Planning – In this phase, the problems, needs and future
plans are being identified to ensure attainment of goals and objectives.
 Information Distribution – This involves disseminating of information
needed by the stakeholders and other members of the organization.
 Performance Reporting – This includes status reporting, progress
measurement, and forecasting for the future of the organization.
 Administrative Closure – This involves generating, gathering, and
disseminating information to formalize phase or project completion.

2.9 PROJECT DEVELOPMENT PHASES

Project management is the process of leading the work of a team to achieve goals
and meet success criteria at a specified time. The primary challenge of project
management is to achieve all of the project goals within the given constraints. This
information is usually described in project documentation, created at the beginning
of the development process. Traditionally (depending on what project management
methodology is being used), project management includes a number of elements:
four to five project management process phases, and a control system. Regardless
of the methodology or terminology used, the same basic project management
processes or stages of development will be used. Major process phases generally
include:
1. Initiation
2. Planning
3. Execution
4. Monitoring and Controlling
5. Closing
1. Initiation: The initiating processes determine the nature and scope of the
project. If this stage is not performed well, it is unlikely that the project will
be successful in meeting the business’ needs. The key project controls needed
here are an understanding of the business environment and making sure that
all necessary controls are incorporated into the project. Any deficiencies
should be reported and a recommendation should be made to fix them.

Self-Instructional
Material 39
Overview of Project The initiating stage should include a plan that encompasses the following
Management
areas. These areas can be recorded in a series of documents called Project
Initiation documents. Project Initiation documents are a series of planned
documents used to create order for the duration of the project. These tend
NOTES to include:
 Project proposal (idea behind project, overall goal, duration).
 Project scope (project direction and track).
 Product Breakdown Structure (PBS) (a hierarchy of deliverables /
outcomes and components thereof).
 Work Breakdown Structure (WBS) (a hierarchy of the work to be done,
down to daily tasks).
 Responsibility Assignment matrix (RACI) (roles and responsibilities
aligned to deliverables / outcomes).
 Tentative project schedule (milestones, important dates, deadlines).
 Analysis of business needs and requirements against measurable goals.
 Review of the current operations.
 Financial analysis of the costs and benefits, including a budget.
 Stakeholder analysis, including users and support personnel for the
project.
 Project charter including costs, tasks, deliverables, and schedules.
 SWOT analysis strengths, weaknesses, opportunities, and threats to
the business.
2. Planning: After the initiation stage, the project is planned to an appropriate
level of detail. The main purpose is to plan time, cost, and resources
adequately to estimate the work needed and to effectively manage risk
during project execution. As with the Initiation process group, a failure to
adequately plan greatly reduces the project’s chances of successfully
accomplishing its goals.
Project planning generally consists of-
 Determining the project management methodology to follow (e.g.,
whether the plan will be defined wholly up front, iteratively, or in rolling
waves).
 Developing the scope statement.
 Selecting the planning team.
 Identifying deliverables and creating the product and work breakdown
structures.
 Identifying the activities needed to complete those deliverables and
networking the activities in their logical sequence.
Self-Instructional
40 Material
  Estimating the resource requirements for the activities. Overview of Project
Management
 Estimating time and cost for activities.
 Developing the schedule.
 Developing the budget. NOTES
 Risk planning.
 Developing quality assurance measures.
 Gaining formal approval to begin work.
3. Execution: While executing we must know what are the planned terms
that need to be executed. The execution/implementation phase ensures that
the project management plan’s deliverables are executed accordingly. This
phase involves proper allocation, co-ordination and management of human
resources and any other resources such as material and budgets. The output
of this phase is the project deliverables.
 Project Documentation: Documenting everything within a project is
key to being successful. To maintain budget, scope, effectiveness and
pace a project must have physical documents pertaining to each specific
task. With correct documentation, it is easy to see whether or not a
project’s requirement has been met. To go along with that, documentation
provides information regarding what has already been completed for
that project. Documentation throughout a project provides a paper trail
for anyone who needs to go back and reference the work in the past. In
most cases, documentation is the most successful way to monitor and
control the specific phases of a project. With the correct documentation,
a project’s success can be tracked and observed as the project goes
on. If performed correctly documentation can be the backbone to a
project’s success.
4. Monitoring and Controlling: Monitoring and controlling consists of those
processes performed to observe project execution so that potential problems
can be identified in a timely manner and corrective action can be taken,
when necessary, to control the execution of the project. The key benefit is
that project performance is observed and measured regularly to identify
variances from the project management plan.
Monitoring and controlling includes:
 Measuring the ongoing project activities (‘Where we are’).
 Monitoring the project variables (cost, effort, scope, etc.) against the
project management plan and the project performance baseline (where
we should be).
 Identifying corrective actions to address issues and risks properly (How
can we get on track again).

Self-Instructional
Material 41
Overview of Project  Influencing the factors that could circumvent integrated change control
Management
so only approved changes are implemented.
5. Closing: Closing includes the formal acceptance of the project and the
ending thereof. Administrative activities include the archiving of the files and
NOTES
documenting lessons learned.
This phase consists of:
 Contract Closure: Complete and settle each contract (including the
resolution of any open items) and close each contract applicable to the
project or project phase.
 Project Close: Finalize all activities across all of the process groups to
formally close the project or a project phase.

2.10 PROJECT CHARTER

Project charter is a statement of the scope, objectives, and participants in a project.

It provides a preliminary delineation of roles and responsibilities, outlines the
project’s key goals, identifies the main stakeholders, and defines the authority of
the project manager.
A project charter should:
 Contain the essence of the project.
 Provide a shared understanding of the project.
 Act as a contract between the project sponsor, key stakeholders and
the project team.
The project charter is usually a short document that refers to more detailed
documents, such as a new offering request or a request for proposal.
In Initiative for Policy Dialogue (IPD), this document is known as the project
charter. In Customer Relationship Management (CRM), it is known as the project
definition report. Both IPD and CRM require this document as part of the project
management process.
The project charter establishes the authority assigned to the project manager,
especially in a matrix management environment. It is considered industry best
practice.
The purpose of the project charter is to document:
 Reasons for undertaking the project.
 Objectives and constraints of the project.
 Directions concerning the solution.
 Identities of the main stakeholders.
 In-scope and out-of-scope items.
Self-Instructional
42 Material
  Risks identified early on (A risk management plan should be part of the Overview of Project
Management
overall project management plan).
 Target project benefits.
 High level budget and spending authority. NOTES
The three main uses of the project charter are:
 To authorize the project - using a comparable format, projects can be
ranked and authorized by Return on Investment.
 Serves as the primary sales document for the project - ranking
stakeholders have a 1-2 page summary to distribute, present, and keep
handy for fending off other project or operations runs at
project resources.
 Serves as a focal point throughout the project. For example, it is a baseline
that can be used in team meetings and in change control meetings to
assist with scope management.

2.11 STATEMENT OF WORK (SOW)

A Statement Of Work (SOW) is a document routinely employed in the field

of project management. It is the narrative description of a project’s work
requirement. It defines project-specific activities, deliverables and timelines for a
vendor providing services to the client. The SOW typically also includes detailed
requirements and pricing, with standard regulatory and governance terms and
conditions. It is often an important accompaniment to a master service
agreement or Request For Proposal (RFP).
Many formats and styles of statement of work document templates have
been specialized for the hardware or software solutions described in the request
for proposal. Many companies create their own customized version of SOWs
that are specialized or generalized to accommodate typical requests and proposals
they receive. However, it is usually informed by the goals of the top management
as well as input from the customer and/or user groups.
In many cases the statement of work is a binding contract. Master service
agreements or consultant/training service agreements postpone certain work-
specific contractual components that are addressed in individual statements of
work. The master service agreement serves as a master contract governing the
terms over potentially multiple SOWs. Sometimes it refers to scope of work. For
instance, if a project is done on contract, the scope statement included as part of
it can be used as the SOW since it also outlines the work of the project in clear
and concise terms.

Self-Instructional
Material 43
Overview of Project
Management 2.12 PROJECT MANAGEMENT ASSOCIATIONS

The Association for Project Management (APM) promotes the disciplines

NOTES of project management and programme management in the UK, where it is the
largest professional body of its kind. APM received its Royal Charter in 2017.
Note, so far as the courts in England and Wales are concerned, project
management is not a specific profession (Pride Valley Foods Ltd. v Hall and Partners
(Contract Management) Ltd (2000)).
The Association for Project Management (APM) aims to develop and
promote the disciplines of project management and programme management,
through a programme called the ‘FIVE Dimensions of Professionalism’. APM
provides products and services including registered membership and qualifications,
events, publications and online services.
The Association for Project Management is a registered charity with over
22,000 individual and 550 corporate members, making it the largest professional
body in the United Kingdom. Its headquarters are located in Princes
Risborough in Buckinghamshire. APM is the certification body in the United
Kingdom for the International Project Management Association (IPMA).

Check Your Progress

6. Write the steps for stakeholder-analysis.
7. Define the term project communication.
8. Name the Project Development Phases.
9. What is project charter?
10. Define the term Statement Of Work (SOW).

2.13 ANSWERS TO CHECK YOUR PROGRESS

QUESTIONS

1. The scope of a project is determined by using product scope and project

scope. Product scope explains all the functions and features that are to be
included in a product or service of the project. On the other hand, project
scope deals with the deeds to be done for delivering the needed product.
The tools and techniques to manage the product scope change with the
nature of the project.
2. The three major problems identified are as follows:
o Project priorities and competition for talent would interrupt the stability
of the organization and interfere with its long-range interests by upsetting
the normal business of the functional organizations.
Self-Instructional
44 Material
 o Long-range planning would suffer if the company gets more involved in Overview of Project
Management
meeting the schedules and fulfilling the requirements of temporary
projects.
o Shifting people from project to project would disrupt the training of new
NOTES
employees and specialists.
3. Project management is the application of processes, methods, skills,
knowledge and experience to achieve specific project objectives according
to the project acceptance criteria within agreed parameters. Project
management has final deliverables that are constrained to a finite timescale
and budget.
4. The main responsibility of a Software Project Manager is to plan and schedule
software project development tasks. A software project manager is
concerned about whether the product meets the required standards and be
finally available for use after meeting the time and financial constraints.
5. A project manager has to carry out the following major activities:
 Project Proposal Writing
 Project Planning
 Project Scheduling
 Project Tracking
 Personal Selection and Evaluation
 Project Report Writing
6. The steps for stakeholder-analysis are
 Identification of stakeholders
 Expectations and interests of the stakeholders
 Influence of the stakeholder and his role in the project
7. Project Management Institute (1996), project communications management
includes processes required to ensure timely and appropriate generation,
collection, dissemination, storage, and ultimate disposition of project
information.
8. Five phase of project development are-
 Initiation
 Planning
 Execution
 Monitoring and controlling
 Closing
9. Project charter is a statement of the scope, objectives, and participants in a
project. It provides a preliminary delineation of roles and responsibilities,
Self-Instructional
Material 45
Overview of Project outlines the project’s key goals, identifies the main stakeholders, and defines
Management
the authority of the project manager.
10. A Statement Of Work (SOW) is a document routinely employed in the
field of project management. It is the narrative description of a project’s
NOTES
work requirement. It defines project-specific activities, deliverables and
timelines for a vendor providing services to the client. The SOW typically
also includes detailed requirements and pricing, with standard regulatory
and governance terms and conditions. It is often an important accompaniment
to a master service agreement or Request For Proposal (RFP).

2.14 SUMMARY

 Project management is the art of directing and coordinating the human and
material resources throughout the project by using modern management
techniques.
 The main purpose of project management is to achieve the predetermined
objectives of scope, cost, time, quality and the satisfaction of the participant.
 Project management is concerned with achieving a specific goal in a given
time by using the resources available for that specific period. Project
management requires attention for goal-oriented systems, the environment,
sub-systems and their relationships.
 The scope of a project is determined by using product scope and project
scope. Product scope explains all the functions and features that are to be
included in a product or service of the project. On the other hand, project
scope deals with the deeds to be done for delivering the needed product.
 Project management is the application of processes, methods, skills,
knowledge and experience to achieve specific project objectives according
to the project acceptance criteria within agreed parameters. Project
management has final deliverables that are constrained to a finite timescale
and budget.
 Project management is the process of leading the work of a team to achieve
goals and meet success criteria at a specified time.
 The primary challenge of project management is to achieve all of the project
goals within the given constraints.
 Scope explains all the activities that one needs to perform in a project. The
scope of a project consists of target results, financial and human resources.
 The main responsibility of a Software Project Manager is to plan and schedule
software project development tasks. A software project manager is
concerned about whether the product meets the required standards and be
finally available for use after meeting the time and financial constraints.
Self-Instructional
46 Material
 Software project managers take the overall responsibility of steering a project Overview of Project
Management
to success. It is very difficult to objectively describe the job responsibilities
of a project manager. The job responsibility of a project manager ranges
from invisible activities, such as building team morale to highly visible customer
presentations. NOTES
 Stakeholders are people who have stake or interest in a project. The project
manager should identify them at the earliest so that he can establish an
adequate communication channel with them right from the beginning.
 The Project Management Institute (1996), project communications
management includes processes required to ensure timely and appropriate
generation, collection, dissemination, storage, and ultimate disposition of
project information.
 Project management is the process of leading the work of a team to achieve
goals and meet success criteria at a specified time.
 The primary challenge of project management is to achieve all of the project
goals within the given constraints. This information is usually described in
project documentation, created at the beginning of the development process.
 Project charter is a statement of the scope, objectives, and participants in a
project. It provides a preliminary delineation of roles and responsibilities,
outlines the project’s key goals, identifies the main stakeholders, and defines
the authority of the project manager.
 A Statement Of Work (SOW) is a document routinely employed in the
field of project management. It is the narrative description of a project’s
work requirement.
 Statement Of Work (SOW) defines project-specific activities, deliverables
and timelines for a vendor providing services to the client.
 The SOW typically also includes detailed requirements and pricing, with
standard regulatory and governance terms and conditions. It is often an
important accompaniment to a master service agreement or Request For
Proposal (RFP).
 The Association for Project Management (APM) promotes the disciplines
of project management and programme management in the UK, where it is
the largest professional body of its kind. APM received its Royal Charter in
2017. Note, so far as the courts in England and Wales are concerned,
project management is not a specific profession (Pride Valley Foods Ltd. v
Hall and Partners (Contract Management) Ltd (2000)).
 The Association for Project Management (APM) aims to develop and
promote the disciplines of project management and programme
management, through a programme called the ‘FIVE Dimensions of
Professionalism’. APM provides products and services including registered
membership and qualifications, events, publications and online services.
Self-Instructional
Material 47
Overview of Project
Management 2.15 KEY WORDS

 Project management: Project management is the art of directing and

NOTES coordinating the human and material resources throughout the project by
using modern management techniques.
 Modification: A project always requires modifications from time to time.
 Reputation: The reputation of the undertaking and what is at stake may
determine the need for project management.
 Time: This is one of the most important constraints in completing a project.
 Resources: This includes people, financial and the physical resources.
 Stakeholders: Stakeholders are people who have stake or interest in a
project.
 Communication planning – In this phase, the problems, needs and future
plans are being identified to ensure attainment of goals and objectives.
 Initiation: The initiating processes determine the nature and scope of the
project.
 Project charter: Project charter is a statement of the scope, objectives,
and participants in a project.
 Statement Of Work (SOW): A Statement Of Work (SOW) is a document
routinely employed in the field of project management.

2.16 SELF ASSESSMENT QUESTIONS AND

EXERCISES

Short-Answer Questions
1. Explain the prerequisites for successful project management.
2. Write the principles of project management.
3. Define the term of quality in project management.
4. Explain the three categories tasks of project manager.
5. Elaborate on the responsibilities of a software project manager.
6. State about the sliding window planning.
7. What is project development?
8. Define the term project documentation in project development phases.
9. Write the purpose of project charter.

Self-Instructional
48 Material
Long-Answer Questions Overview of Project
Management
1. Briefly explain the project management and its characteristics giving
appropriate examples.
2. Describe in details need for project management. NOTES
3. Discuss about the factors influencing of project management.
4. Briefly explain the project manager and its reasons with the help of examples.
5. Discuss in details six major activities for project management.
6. Describe the mechanism for stockholders with the help of examples.
7. What is project communication process? Explain giving examples.
8. Briefly explain the project development phases giving appropriate examples.
9. Describe in details project charter and Statement Of Work (SOW).
10. Discuss about the project management associations with the help of
appropriate examples.

2.17 FURTHER READINGS

Hughes, Bob, Mike Cotterell and Rajib Mall. 2017. Software Project
Management (SIE), 6th Edition. New York: McGraw Hill Education.
Schach, Stephen R. 2005. Object Oriented and Classical Software Engineering.
New Delhi: Tata McGraw-Hill.
Pressman, Roger S. 1997. Software Engineering, a Practitioner’s Approach.
New Delhi: Tata McGraw-Hill.
Somerville, Ian. 2001. Software Engineering. New Delhi: Pearson Education.
Ghezzi, Carlo, Mehdi Jazayeri, and Dino Mandriolli. 1991. Fundamentals of
Software Engineering. New Delhi: Prentice-Hill of India.
Jawadekar, Waman S. 2004. Software Engineering: Principles and Practice.
New Delhi: Tata McGraw-Hill.
Jalote, Pankaj. 1991. An Integrated Approach to Software Engineering. New
Delhi: Narosa Publishing House.

Self-Instructional
Material 49
Project Planning

UNIT 3 PROJECT PLANNING

NOTES Structure
3.0 Introduction
3.1 Objectives
3.2 Tasks in Project Planning
3.2.1 Purpose of a Project
3.2.2 Project Scope
3.2.3 Project Planning Process
3.3 Work Breakdown Structures (WBS)
3.4 Planning Methods
3.5 Development Life Cycle Models
3.6 A Generic Project Model
3.7 Answers to Check Your Progress Questions
3.8 Summary
3.9 Key Words
3.10 Self Assessment Questions and Exercises
3.11 Further Readings

3.0 INTRODUCTION

Project planning is an organized and integrated management process, which focuses

on activities required for successful completion of the project. It prevents obstacles
that arise in the project, such as changes in projects or organization’s objectives,
non-availability of resources, and so on. Project planning also helps in better
utilization of resources and optimal usage of the allotted time for a project. Several
individuals help in planning the project. These include senior management and
project management team. Senior management is responsible for employing team
members and providing resources required for the project. The project management
team, which generally includes project managers and developers, is responsible
for planning, determining, and tracking the activities of the project. Software project
is carried out to accomplish a specific purpose, which is classified into two
categories, namely, project objectives and business objectives.
A project plan stores the outcome of project planning. It provides information
about the end date, milestones, activities, and deliverables of the project. In addition,
it describes the responsibilities of the project management team and the resources
required for the project. It also includes the description of hardware and software,
(such as, compilers and interfaces) and lists the methods and standards to be
used. These methods and standards include algorithms, tools, review techniques,
design language, programming language, and testing techniques. The ability of
managing projects successfully greatly depends upon the right understanding of
the phases and activities that create the project life-cycle. Because any kind of

Self-Instructional
50 Material
project is ‘A temporary endeavour undertaken to create a unique product or service’ Project Planning

(PMI 2000), it is planned, managed and delivered under a definite life-cycle, or

under the process of by which the project is implemented. The life-cycle
characterizes the constraint of time and defines how soon the project deliverables
(product/service) will be produced. NOTES
In this unit, you will study about the tasks in project planning, Work
Breakdown Structures (WBS), planning methods, development life cycle models,
a generic project model.

3.1 OBJECTIVES

After going through this unit, you will be able to:

 Define the tasks in project planning
 Elucidate on the Work Breakdown Structures (WBS)
 Understand the basics of planning methods
 Discuss about the development life cycle models
 Explain the a generic project model

3.2 TASKS IN PROJECT PLANNING

Before starting a software project, it is essential to determine the tasks to be

performed and properly manage allocation of tasks among individuals involved in
the software development. Hence, planning is important as it results in effective
software development.
Project planning is an organized and integrated management process, which
focuses on activities required for successful completion of the project. It prevents
obstacles that arise in the project, such as changes in projects or organization’s
objectives, non-availability of resources, and so on. Project planning also helps in
better utilization of resources and optimal usage of the allotted time for a project.
The other objectives of project planning are:
 It defines the roles and responsibilities of the project management team
members.
 It ensures that the project management team works according to the
business objectives.
 It checks feasibility of the schedule and user requirements.
 It determines project constraints.
Several individuals help in planning the project. These include senior
management and project management team. Senior management is responsible
for employing team members and providing resources required for the project.
Self-Instructional
Material 51
Project Planning The project management team, which generally includes project managers and
developers, is responsible for planning, determining, and tracking the activities of
the project. Table 3.1 lists the tasks performed by individuals involved in the software
project.
NOTES
Table 3.1 Tasks of Individuals Involved in Software Project
Senior Management Project Management Team
 Approves the project, employ  Reviews the project plan and implements
personnel, and provides resources procedures for completing the project.
required for the project.  Manages all project activities.
 Reviews project plan to ensure that it  Prepares budget and resource allocation plans.
accomplishes the business objectives.  Helps in resource distribution, project
 Resolves conflicts among the team management, issue resolution, and so on.
members.  Understands project objectives and finds ways
 Considers risks that may affect the to accomplish the objectives.
project so that appropriate measures  Devotes appropriate time and effort to achieve
can be taken to avoid them. the expected results.
 Selects methods and tools for the project.

Project planning should be effective so that the project begins with well-
defined tasks. Effective project planning helps to minimize the additional costs
incurred on the project while it is in progress. For effective project planning, some
principles are followed. These principles are listed below.
i. Planning is Necessary: Planning should be done before a project
begins. For effective planning, objectives and schedules should be
clear and understandable.
ii. Risk Analysis: Before starting the project, senior management and
the project management team should consider the risks that may affect
the project. For example, the user may desire changes in requirements
while the project is in progress. In such a case, the estimation of time
and cost should be done according to those requirements (new
requirements).
iii. Tracking of Project Plan: Once the project plan is prepared, it should
be tracked and modified accordingly.
iv. Meet Quality Standards and Produce Quality Deliverables: The
project plan should identify processes by which the project
management team can ensure quality in software. Based on the process
selected for ensuring quality, the time and cost for the project is
estimated.
v. Description of Flexibility to Accommodate Changes: The result
of project planning is recorded in the form of a project plan, which
should allow new changes to be accommodated when the project is
in progress.

Self-Instructional
52 Material
 Project planning comprises project purpose, project scope, project planning Project Planning

process, and project plan. This information is essential for effective project planning
and to assist the project management team in accomplishing user requirements.
Note: In software project, tasks and activities represent the tasks performed during
NOTES
software development. Hence, both the terms are used interchangeably throughout
this unit.
3.2.1 Purpose of a Project
A software project is carried out to accomplish a specific purpose, which is classified
into two categories, namely, project objectives and business objectives. The
commonly followed project objectives are listed below.
 Meet User Requirements: Develop the project according to the user
requirements after understanding them.
 Meet Schedule Deadlines: Complete the project milestones as described
in the project plan on time in order to complete the project according to the
schedule.
 Be Within Budget: Manage the overall project cost so that the project is
within the allocated budget.
 Produce Quality Deliverables: Ensure that quality is considered for
Business objectives ensure that the organizational objectives and requirements
are accomplished in the project. Generally, these objectives are related to
business process improvements, customer satisfaction, and quality
improvements. The commonly followed business objectives are listed below.
i. Evaluate Processes: Evaluate the business processes and make
changes when and where required as the project progresses.
ii. Renew Policies and Processes: Provide flexibility to renew the
policies and processes of the organization in order to perform the
tasks effectively.
iii. Keep the Project on Schedule: Reduce the downtime (period when
no work is done) factors such as unavailability of resources during
software development.
iv. Improve Software: Use suitable processes in order to develop
software that meets organizational requirements and provides
competitive advantage to the organization.
3.2.2 Project Scope
With the help of user requirements, the project management team determines the
scope of the project before the project begins. This scope provides a detailed
description of functions, features, constraints, and interfaces of the software that
are to be considered. Functions describe the tasks that the software is expected

Self-Instructional
Material 53
Project Planning to perform. Features describe the attributes required in the software as per the
user requirements. Constraints describe the limitations imposed on software by
hardware, memory, and so on. Interfaces describe the interaction of software
components (like modules and functions) with each other. Project scope also
NOTES considers software performance, which in turn depends on its processing capability
and response time required to produce the output.
Once the project scope is determined, it is important to properly understand
it in order to develop software according to the user requirements. After this,
project cost and duration are estimated. Lf the project scope is not determined on
time, the project may not be completed within the specified schedule. Project
scope describes the following information.
 The elements included and excluded in the project.
 The processes and entities.
 The functions and features required in software according to the user
requirements.
Note that the project management and senior management team should
communicate with the users to understand their requirements and develop software
according to those requirements and expected functionalities.
3.2.3 Project Planning Process
The project planning process involves a set of interrelated activities followed in an
orderly manner to implement user requirements in software and includes the
description of a series of project planning activities and individual(s) responsible
for performing these activities. In addition, the project planning process comprises
the following.
 Objectives and scope of the project.
 Techniques used to perform project planning.
 Effort (in time) of individuals involved in project.
 Project schedule and milestones.
 Resources required for the project.
 Risks associated with the project.
Project planning process comprises several activities, which are essential
for carrying out a project systematically. These activities refer to the series of
tasks performed over a period of time for developing the software. These activities
include estimation of time, effort, and resources required and risks associated
with the project. Figure 3.1 shows several activities of project planning which can
be performed both in a sequence and in a parallel manner.

Self-Instructional
54 Material
 Project Planning

NOTES

Fig. 3.1 Project Planning Activities

Project planning process consists of the following activities.

 Identification of Project Requirements: Before starting a project, it
is essential to identify the project requirements as identification of project
requirements helps in performing the activities in a systematic manner.
These requirements comprise information such as project scope, data
and functionality required in the software, and roles of the project
management team members.
 Identification of Cost Estimates: Along with the estimation of effort
and time, it is necessary to estimate the cost that is to be incurred on a
project. The cost estimation includes the cost of hardware, network
connections, and the cost required for the maintenance of hardware
components. In addition, cost is estimated for the individuals involved in
the project.
 Identification of Risks: Risks are unexpected events that have an
adverse effect on the project. Software project involves several risks
(like technical risks and business risks) that affect the project schedule
and increase the cost of the project. Identifying risks before a project
begins helps in understanding their probable extent of impact on the
project.
 Identification of Critical Success Factors: For making a project
successful, critical success factors are followed. These factors refer to
the conditions that ensure greater chances of success of a project.
Generally, these factors include support from management, appropriate
budget, appropriate schedule, and skilled software engineers.

Self-Instructional
Material 55
Project Planning  Preparation of Project Charter: A project charter provides a brief
description of the project scope, quality, and time, cost, and resource
constraints as described during project planning. It is prepared by the
management for approval from the sponsor of the project.
NOTES
 Preparation of Project Plan: A project plan provides information about
the resources that are available for the project, individuals involved in
the project, and the schedule according to which the project is to be
carried out.
 Commencement of the Project: Once the project planning is complete
and resources are assigned to team members, the software project
commences.
Once the project objectives and business objectives are determined, the
project end date is fixed. The project management team prepares the project plan
and schedule according to the end date of the project. After analyzing the project
plan, the project manager communicates the project plan and end date to the
senior management. The progress of the project is reported to the management
from time to time. Similarly, when the project is complete, senior management is
informed about it. In case of delay in completing the project, the project plan is re-
analyzed and corrective actions are taken to complete the project. The project is
tracked regularly and when the project plan is modified, the senior management is
informed.

3.3 WORK BREAKDOWN STRUCTURES (WBS)

Work breakdown structure is the process of dividing the project into tasks and
logically ordering them in a sequence according to their related tasks. It provides
a framework for keeping track of the progress of the project and for determining
the cost planned for these tasks. By comparing the planned costs and the actual
cost (cost that has been expended), the additional cost required can be controlled.
WBS specifies only the tasks that are to be performed and not the process
by which the tasks are completed. It also does not specify the individuals performing
that task. This is because WBS is based on requirements and not on the way in
which the tasks are carried out.
To break the tasks involved in a project, the following steps are used:
1. Break the project into general tasks: The project can be divided
into general tasks, such as analysis, design, testing, and so on.
2. The general tasks into smaller individual tasks: When the general
tasks are determined, they can further be divided into sub-tasks.
Design, for example, can further be divided into interface design,
modular design, and so on.

Self-Instructional
56 Material
 Figure 3.2 shows a work breakdown structure. Here, the project summary Project Planning

is divided into three tasks, namely design phase, programming phase and testing
phase. Also, each task contains several sub-tasks. The design phase, for example,
is further divided into two sub-tasks, namely first design phase and second design
phase. Note that in the figure each task is numbered to indicate the sequence of NOTES
tasks and sub-tasks. It also indicates the time taken and the cost involved to
complete these tasks and sub-tasks.

Fig. 3.2 Breakdown Structure

Note: The completion of each task is indicated with the help of a milestone.

Check Your Progress

1. What is project planning?
2. Write the project planning process.
3. Explain the term Work Breakdown Structures (WBS).

3.4 PLANNING METHODS

As stated earlier, a project plan stores the outcome of project planning. It provides
information about the end date, milestones, activities, and deliverables of the project.
In addition, it describes the responsibilities of the project management team and
the resources required for the project. It also includes the description of hardware
and software, (such as compilers and interfaces) and lists the methods and standards
to be used. These methods and standards include algorithms, tools, review
techniques, design language, programming language, and testing techniques.
A project plan helps a project manager to understand, monitor, and control
the development of software project. This plan is used as a means of communication

Self-Instructional
Material 57
Project Planning between the users and project management team. There are various advantages
associated with a project plan, some of which are listed below.
 It ensures that software is developed according to the user requirements,
objectives, and scope of the project.
NOTES
 It identifies the role of each project management team member involved
in the project.
 It monitors the progress of the project according to the project plan.
 It determines the available resources and the activities to be performed
during software development.
 It provides an overview to management about the costs of the software
project, which are estimated during project planning.
Note: That there are differences in the contents of two project plans depending
on the kind of project and user requirements. Atypical project plan is divided into
the following sections.
i. Introduction: Describes the objectives of the project and provides
information about the constraints that affect the software project.
ii. Project Organization: Describes the responsibilities assigned to the project
management team members for completing the project.
iii. Risk Analysis: Describes the risks that can possibly arise during software
development as well as explains how to assess and reduce the effect of
risks.
iv. Resource Requirements: Specifies the hardware and software required
to carry out the software project. Cost estimation is done according to
these resource requirements.
v. Work Breakdown: Describes the activities into which the project is divided.
It also describes the milestones and deliverables of the project activities.
vi. Project Schedule: Specifies the dependencies of activities on each other.
Based on this, the time required by the project management team members
to complete the project activities is estimated.
In addition to these sections, there are several plans that may be a part of or
‘Linked to a project plan. These plans include quality assurance plan, verification
and validation plan, configuration management plan, maintenance plan, and staffing
plan.
Quality Assurance Plan
The quality assurance plan describes the strategies and methods that are to be
followed to accomplish the following objectives.
 Ensure that the project is managed, developed, and implemented in an
organized way.
Self-Instructional
58 Material
  Ensure that project deliverables are of acceptable quality before they are Project Planning

delivered to the user.

Verification and Validation Plan
The verification and validation plan describes the approach, resources and schedule NOTES
used for system validation. The verification and validation plan, which comprises
the following sections.
i. General Information: Provides description of the purpose, scope, system
overview, project references, acronyms and abbreviations, and points of
contact. Purpose describes the procedure to verify and validate the
components of the system. Scope provides information about the procedures
to verify and validate as they relate to the project. System overview provides
information about the organization responsible for the project and other
information such as system name, system category, operational status of the
system, and system environment. Project references provide the list of
references used for the preparation of the verification and validation plan.
Acronyms and abbreviations provide a list of terms used in the document.
Points of contact provide information to users when they require assistance
from organization for problems such as troubleshooting and so on.
ii. Reviews and Walkthroughs: Provides information about the schedule
and procedures. Schedule describes the end date of milestones of the project.
Procedures describe the tasks associated with reviews and walkthroughs.
Each team member reviews the document for errors and consistency with
the project requirements. For walkthroughs, the project management team
checks the project for correctness according to Software Requirements
Specification (SRS).
iii. System Test Plan and Procedures: Provides information about the system
test strategy, database integration, and platform system integration. System
test strategy provides an overview of the components required for integration
of the database and ensures that the application runs on at least two specific
platforms. Database integration procedure describes how database is
connected to the Graphical User Interface (GUI).Platform system integration
procedure is performed on different operating systems to test the platform.
iv. Acceptance Test and Preparation for Delivery: Provides information
about procedure, acceptance criteria, and installation procedure. Procedure
describes how acceptance testing is to be performed on the software to
verify its usability as required. Acceptance criteria describes that software
will be accepted only if all the components, features and functions are tested
including the system integration testing. In addition, acceptance criteria checks
whether the software accomplishes user expectations, such as its ability to
operate on several platforms. Installation procedure describes the steps of
how to install the software according to the operating system being used.
Self-Instructional
Material 59
Project Planning Configuration Management Plan
The configuration management plan defines the process, which is used for making
changes to the project scope. Generally, the configuration management plan is
NOTES concerned with redefining the existing objectives of the project and deliverables
(software products that are delivered to the user after completion of software
development).
Maintenance Plan
The maintenance plan specifies the resources and processes required for making
the software operational after its installation. Sometimes, the project management
team (or software development team) does not carry out the task of maintenance.
In such a case, a separate team known as software maintenance team performs
the task of software maintenance.
The maintenance plan, which comprises the sections listed below.
i. Introduction and Background: Provides a description of software
to be maintained and the services required for it. It also specifies the
scope of maintenance activities that are to be performed.
ii. Budget: Specifies the budget required for carrying out software
maintenance and operational activities.
iii. Roles and Responsibilities: Specifies the roles and responsibilities
of the team members associated with the software maintenance and
operation. It also describes the skills required to perform maintenance
and operational activities. In addition to software maintenance team,
software maintenance comprises user support, user training, and
support staff.
iv. Performance Measures and Reporting: Identifies the performance
measures required for carrying out software maintenance. It also
describes how measures required for enhancing the performance of
services (for the software) are recorded and reported.
v. Management Approach: Identifies the methodologies that are
required for establishing maintenance priorities of the projects. For
this purpose, the management either refers to the existing methodologies
or identifies new methodologies. Management approach also
describes how users are involved in software maintenance and
operations activities as well as how users and project management
team communicate with each other.
vi. Documentation Strategies: Provides a description of the
documentation that is prepared for user reference. Generally,
documentation includes reports, information about problems occurring
in software, error messages, and the system documentation.
vii. Training: Provides information about the training activities.
Self-Instructional
60 Material
 viii. Acceptance: Defines a point of agreement between the project Project Planning

management team and software maintenance team after the completion

of implementation and transition activities. Once the agreement has
been made, the software maintenance begins.
NOTES
Staffing Plan
The staffing plan describes the number of individuals required for a project. It
includes selecting and assigning tasks to the project management team members.
It provides information about appropriate skills required to perform the tasks to
produce the project deliverables and manage the project. In addition, it provides
information of resources such as tools, equipment, and processes used by the
project management team.
Staff planning is performed by a staff planner, who is responsible for
determining the individuals available for the project. Other responsibilities of a
staff planner are listed below.
i. The staff planner determines individuals, who can be from existing
staff, staff on contract, or newly employed staff. It is important for the
staff planner to know the structure of the organization to determine
the availability of staff.
ii. The staff planner determines the skills required to execute the tasks
mentioned in the project schedule and task plan. In case staff with
required skills is not available, staff planner informs the project manager
about the requirements.
iii. The staff planner ensures that the required staff with required skills is
available at the right time. For this purpose, the staff planner plans the
availability of staff after the project schedule is fixed. For example, at
the initial stage of a project, staff may consist of a project manager
and a few software engineers whereas during software development,
staffs consists of software designers as well as the software developers.
iv. The staff planner defines roles and responsibilities of the project
management team members so that they can communicate and
coordinate with each other according to the tasks assigned to them.
Note that the project management team can be further broken down
into sub-teams depending on the size and complexity of the project.
The staffing plan comprises the following sections.
i. General Information: Provides information such as name of the
project and project manager who is responsible for the project. In
addition, it specifies the start and end dates of the project.
ii. Skills Assessment: Provides information, which is required for
assessment of skills. This information includes the knowledge, skill,
and ability of team members who are required to achieve the objectives
Self-Instructional
Material 61
Project Planning of the project. In addition, it specifies the number of team members
required for the project.
iii. Staffing Profile: Describes the profile of the staff required for the
project. The profile includes calendar time, individuals involved, and
NOTES
level of commitment. Calendar time specifies the period of time such
as month or quarter for which individuals are required to complete the
project. Individuals who are involved in the project have specific
designations such as project manager and the developer. Level of
commitment is the utilization rate of individuals such as work performed
on full-time and part-time basis.
iv. Organization Chart: Describes the organization of project
management team members. In addition, it includes information such
as name, designation, and role of each team member.

3.5 DEVELOPMENT LIFE CYCLE MODELS

The following are the various stages of the life cycle concept:
Theoretical Framework
During the planning stage, subcontracts are given, teams and sub-teams are formed,
team leaders are appointed, coordination is established, documentations are
designed and a reporting system is developed. Now is the time to execute the
projects. Project execution is a very active stage in project management. It involves
activities like actual construction of work packages, action and coordination and
monitoring and control.
Constructing Work Packages
A project team will start constructing different work packages (activities) as per
the network plan prepared in the detailed project report. The sub-teams in the
project, each with their own expertise, are engaged in the construction of work
packages. These activities are visible and create enthusiasm and excitement, which
may sometimes take the eyes off the scope of the project.
Action and Coordination
There are several sub-teams on the job at any given point in time. Progress on
their work together with resources consumed and required have a bearing on
what other sub-teams are doing and would do in the future. Someone has to
provide strong leadership for the effective coordination among all sub-teams and
subcontractors and also coordination for resource allocation on various sub-teams.
Monitoring and Control
Troubleshooting becomes a daily event, review of several configurations and
Self-Instructional activities takes place and the need for design change is felt. During implementation,
62 Material
there is always a very high chance that the project may go in the wrong trajectory Project Planning

due to the involvement of several people, difficulty in coordination or loss of focus

and the project may become unviable or may get delayed. Therefore, a project
control mechanism is extremely important. A good project control mechanism
would efficiently balance the cost, time and performance aspects, where NOTES
performance aspects cover quantitative as well as qualitative targets.

3.6 A GENERIC PROJECT MODEL

The ability of managing projects successfully greatly depends upon the right
understanding of the phases and activities that create the project life-cycle. Because
any kind of project is ‘A temporary endeavour undertaken to create a unique
product or service’ (PMI 2000), it is planned, managed and delivered under a
definite life-cycle, or under the process of by which the project is implemented.
The life-cycle characterizes the constraint of time and defines how soon the project
deliverables (product/service) will be produced.
Let’s learn more about the point in this Project Life-Cycle Template. We’re
going to talk about the definition of project life-cycle and provide an overview of
the key phases and activities of the generic model.
Defining Project Life-Cycle
If you’ve ever read the literature on PM, you probably know that in most PM
books there is widespread agreement about conventional or general phases of
project life-cycle. There are 5 general phases such as:
 Conceptualization
 Organization
 Development
 Implementation
 Evaluation
Some books give other classifications, but the key point remains the same:
any project that can be performed under an activity-based planning approach
will step through the 5 phases throughout its life-cycle. It actually means that if we
can plan our project as a series of activities and tasks to be undertaken in a certain
desired sequence during the preset period of time, then this project appears to
have the generic five-phase model.
Note that the planning approach serves as the key to defining what model
to use in a particular project. Along with activity-based planning that defines the 5-
phase life-cycle model there is also milestone-based planning that explores more
deepened and comprehensive models.

Self-Instructional
Material 63
Project Planning Here’s more about both approaches:
 Activity-Based Planning: It is used when projects are possible to
plan before launch (goals and methods are well defined at the very
beginning). This approach is best for engineering and construction
NOTES
projects.
 Milestone-Based Planning: It is used in projects in which milestones
(special progress flags that show project performance and deliverable
status) represent the completion of life-cycle. It is best fitted to product
development and software projects.
In this project life-cycle template we focus on the activity-based planning
approach. Please view the image given below. Figure 3.3 shows the 5 key phases
of the generic project life-cycle model.

Fig. 3.3 Generic 5-Phase Model of Project Life Cycle

Key Phases and Activities

Below in this project life-cycle template we describe the key phases by activities
to be undertaken by project manager in collaboration with the senior stakeholders
and experts. You can use this template as additional guidelines for planning your
activity-based project.
Phase 1 Conceptualization
Define and explain the project need (what’s required?) and purpose (why is this
required?)
i. State the problem to be solved by the project.
ii. Identify the project solution.
iii. List the benefits to be gained upon successful project completion.
iv. Develop the project concept.

Self-Instructional
64 Material
 v. Perform a feasibility analysis to prove the project is technically feasible and Project Planning

economically viable.
vi. Identify how the project relates to other dependent/child projects running in
parallel.
NOTES
vii. Set priority to the project.
viii. Explain business background and strategic content.
ix. Determine ethical considerations.
x. Define options (alternatives) to proposed solution.
xi. Perform an analysis to evaluate the options and prove the solution is
reasonable to choose.
xii. Make recommendations regarding project launch.
xiii. Develop a project proposal document and submit it for review to the sponsor.
Phase 2 Organization
i. Assign the Project Manager.
ii. Acquire and assemble the project team
iii. Perform stakeholder analysis to identify people affected by or interested in
the project, analyze their needs, and decide on involvement level (how the
stakeholders are allowed to influence project decision making)
iv. Determine broad scope, including:
o Constraints & assumptions
o Boundaries (inclusions & exclusions)
o Deliverables
o Requirement
o Establish project objectives and goals
o Identify the governance structure including
 Roles and responsibilities
 Functions
 Delegations
o Establish preliminary timeframes for project activities
o Perform a preliminary cost assessment to develop project cost estimate
o Undertake a preliminary risk assessment to identify expected risks and
threats affecting the project
o Develop a project organization document and submit it for review and
approval to the senior management

Self-Instructional
Material 65
Project Planning Phase 3 Development
Define the scope through decomposing project work into smaller action items,
such as tasks and activities-
NOTES i. Develop the project schedule based in activity duration estimates.
ii. Create the risk management plan based on the risk assessment.
iii. Identify types and quantity of resources (labor, funds, technology, inventories,
land, etc.) required for the project.
iv. Develop a budget sheet based on cost projections.
v. Create the communications plan.
vi. Determine the controls including tracking procedures, reporting rules, change
management process, issue/risk logging.
vii. Design the quality management plan.
viii. Develop the procurement plan.
ix. Write the handover plan that explains deliverable acceptance criteria and
how to hand over the product to the customer.
x. Prepare the project plan that is based on the data of the subsidiary plan.
Phase 4 Implementation
Start executing the project plan
i. Monitor and control changes made to the key parameters, such as:
o Scope
o Time (Schedule)
o Cost (Budget)
o Quality
o Issues/Risks
o Handover Plan
ii. Manage stakeholder expectations and communications.
iii. Report performance through status reports and meetings.
iv. Manage variance requests.
v. Confirm the planned results are produced.
Phase 5 Evaluation
Perform administrative closeout of the project and its activities-
i. Communicate with the customer to agree of the deliverables acceptance.
ii. Implement the handover plan (transferring the deliverables to the customer).
iii. Develop a handover report (whether the deliverables have successfully
Self-Instructional reached the customer).
66 Material
 iv. Conduct a post-project meeting to summarize the work and identify lessons- Project Planning

learned.
v. Undertake a business-benefits review to identify whether the expected
benefits have been gained upon project completion.
NOTES
vi. Announce project end and celebrate.
vii. Develop a project completion report and submit for approval to the senior
management team, (e.g., Steering Committee).
viii. Archive project documentation.

Check Your Progress

4. Define the term configuration management plan.
5. Explain the term staffing plan.
6. State about the constructing work packages.
7. Write the general phases of project life-cycle.

3.7 ANSWERS TO CHECK YOUR PROGRESS

QUESTIONS

1. Project planning is an organized and integrated management process, which

focuses on activities required for successful completion of the project. It
prevents obstacles that arise in the project, such as changes in projects or
organization’s objectives, non-availability of resources, and so on. Project
planning also helps in better utilization of resources and optimal usage of the
allotted time for a project.
2. The project planning process comprises the following.
 Objectives and scope of the project.
 Techniques used to perform project planning.
 Effort (in time) of individuals involved in project.
 Project schedule and milestones.
 Resources required for the project.
 Risks associated with the project.
3. Work breakdown structure is the process of dividing the project into tasks
and logically ordering then in a sequence according to their related tasks. It
provides a framework for keeping track of the progress of the project and
for determining the cost planned for these tasks. By comparing the planned
costs and the actual cost (cost that has been expended), the additional cost
required can be controlled.

Self-Instructional
Material 67
Project Planning 4. The configuration management plan defines the process, which is used for
making changes to the project scope. Generally, the configuration
management plan is concerned with redefining the existing objectives of the
project and deliverables (software products that are delivered to the user
NOTES after completion of software development).
5. The staffing plan describes the number of individuals required for a project.
It includes selecting and assigning tasks to the project management team
members. It provides information about appropriate skills required to
perform the tasks to produce the project deliverables and manage the
project. In addition, it provides information of resources such as tools,
equipment, and processes used by the project management team.
6. A project team will start constructing different work packages (activities)
as per the network plan prepared in the detailed project report. The sub-
teams in the project, each with their own expertise, are engaged in the
construction work packages.
7. There are 5 general phases such as:
 Conceptualization
 Organization
 Development
 Implementation
 Evaluation

3.8 SUMMARY

 Project planning is an organized and integrated management process, which

focuses on activities required for successful completion of the project.
 Several individuals help in planning the project. These include senior
management and project management team. Senior management is
responsible for employing team members and providing resources required
for the project.
 The project management team, which generally includes project managers
and developers, is responsible for planning, determining, and tracking the
activities of the project.
 Planning should be done before a project begins. For effective planning,
objectives and schedules should be clear and understandable.
 A software project is carried out to accomplish a specific purpose, which is
classified into two categories, namely, project objectives and business
objectives.

Self-Instructional
68 Material
 A project plan provides information about the resources that are available Project Planning

for the project, individuals involved in the project, and the schedule according
to which the project is to be carried out.
 Work breakdown structure is the process of dividing the project into tasks
NOTES
and logically ordering then in a sequence according to their related tasks. It
provides a framework for keeping track of the progress of the project and
for determining the cost planned for these tasks. By comparing the planned
costs and the actual cost (cost that has been expended), the additional cost
required can be controlled.
 A project plan helps a project manager to understand, monitor, and control
the development of software project. This plan is used as a means of
communication between the users and project management team.
 The verification and validation plan describes the approach, resources and
schedule used for system validation.
 The configuration management plan defines the process, which is used for
making changes to the project scope.
 Generally, the configuration management plan is concerned with redefining
the existing objectives of the project and deliverables (software products
that are delivered to the user after completion of software development).
 The maintenance plan specifies the resources and processes required for
making the software operational after its installation. Sometimes, the project
management team (or software development team) does not carry out the
task of maintenance. In such a case, a separate team known as software
maintenance team performs the task of software maintenance.
 The staffing plan describes the number of individuals required for a project.
It includes selecting and assigning tasks to the project management team
members.
 The staffing plan provides information about appropriate skills required to
perform the tasks to produce the project deliverables and manage the
project. In addition, it provides information of resources, such as tools,
equipment, and processes used by the project management team.
 The ability of managing projects successfully greatly depends upon the right
understanding of the phases and activities that create the project life-cycle.
 Activity-Based Planning is used when projects are possible to plan before
launch (goals and methods are well defined at the very beginning). This
approach is best for engineering and construction projects.
 Milestone-Based Planning is used in projects in which milestones (special
progress flags that show project performance and deliverable status)
represent the completion of life-cycle. It is best fitted to product development
and software projects.
Self-Instructional
Material 69
Project Planning  Project Life-cycle Template we describe the key phases by activities to be
undertaken by project manager in collaboration with the senior stakeholders
and experts.

NOTES
3.9 KEY WORDS

 Project planning: Project planning is an organized and integrated

management process.
 Risk Analysis: Before starting the project, senior management and the
project management team should consider the risks that may affect the
project.
 Work breakdown structure: The process of diving a project into tasks
and logically ordering them in a sequence according to their related.
 Verification and validation plan: It describes the approach, resources
and schedule used for system validation.
 Project staffing: The process o searching, evaluating and establishing a
working relationship amongst the personnel involved in a project.

3.10 SELF ASSESSMENT QUESTIONS AND

EXERCISES

Short-Answer Questions
1. Write the objectives of project planning.
2. Explain the purpose of the project.
3. What is planning method?
4. Explain the term theoretical framework.
5. Define the term quality assurance plan.
6. Give the definition of project life-cycle.
7. Elaborate on the term conceptualization.
Long-Answer Questions
1. Briefly explain the tasks in project management giving appropriate examples.
2. Discuss about the project planning activities with the help of diagram.
3. Describe the Work Breakdown Structures (WBS) with the help of diagram.
4. Briefly explain the staffing plan giving appropriate examples.

Self-Instructional
70 Material
 5. Describe briefly the development life cycle models giving appropriate Project Planning

examples.
6. Briefly in details five general phases of project life-cycle giving appropriate
examples.
NOTES

3.11 FURTHER READINGS

Hughes, Bob, Mike Cotterell and Rajib Mall. 2017. Software Project
Management (SIE), 6th Edition. New York: McGraw Hill Education.
Schach, Stephen R. 2005. Object Oriented and Classical Software Engineering.
New Delhi: Tata McGraw-Hill.
Pressman, Roger S. 1997. Software Engineering, a Practitioner’s Approach.
New Delhi: Tata McGraw-Hill.
Somerville, Ian. 2001. Software Engineering. New Delhi: Pearson Education.
Ghezzi, Carlo, Mehdi Jazayeri, and Dino Mandriolli. 1991. Fundamentals of
Software Engineering. New Delhi: Prentice-Hill of India.
Jawadekar, Waman S. 2004. Software Engineering: Principles and Practice.
New Delhi: Tata McGraw-Hill.
Jalote, Pankaj. 1991. An Integrated Approach to Software Engineering. New
Delhi: Narosa Publishing House.

Self-Instructional
Material 71
Estimation and
Budgeting of Projects
UNIT 4 ESTIMATION AND
BUDGETING OF PROJECTS
NOTES
Structure
4.0 Introduction
4.1 Objectives
4.2 Software Cost Estimation
4.2.1 Expert Judgement
4.2.2 Constructive Cost Model
4.2.3 Basic Model
4.2.4 Intermediate Model
4.2.5 Advance Model
4.2.6 Halstead’s Software Science
4.3 COCOMO Model
4.4 Budgeting
4.5 Answers to Check Your Progress Questions
4.6 Summary
4.7 Key Words
4.8 Self Assessment Questions and Exercises
4.9 Further Readings

4.0 INTRODUCTION

A cost estimate is the approximation of the cost of a program, project, or operation.

The cost estimate is the product of the cost estimating process. The cost estimate
has a single total value and may have identifiable component values. Cost of
estimating software varies according to the nature and type of the product to be
developed. The cost of estimating an operating system, for example, will be more
than the cost estimated for an application program. Thus, in the software cost
estimation process, it is important to define and understand the software which is
to be estimated. Depending upon the nature of the project to be estimated, different
project estimation techniques can be used.
Bohem’s COCOMO (COnstructive COst MOdel) model is very useful for
software estimation. Boehm postulated that any software development project
can be classified into one of the three categories based on the complexity of
development: organic, semi-detached and embedded. In order to classify a product
into the identified categories, Boehm not only considered the characteristics of the
product, but also those of the development team and development environment.
Cohesion is a measure of functional strength of a module. It is a well-established
theory that a good software design means clean decomposition of a problem into
modules. These modules are overall arranged in a hierarchy. After decomposition
of the problem, we finally get modules that have high cohesion and low coupling.
Self-Instructional
72 Material
 Project budget has two components in it, cost and cash flow. Cash flow Estimation and
Budgeting of Projects
budget is required for liquidity planning and for obtaining funds in time. A budget
offer has to work in close coordination with the technical staff who prepare project
network and with the procurement officers.
NOTES
In this unit, you will study about the software cost estimation, COCOMO
model, and budgeting.

4.1 OBJECTIVES

After going through this unit, you will be able to:

 Understand the basics of software cost estimation
 Discuss about the COCOMO model
 Explain budgeting

4.2 SOFTWARE COST ESTIMATION

To lower the cost of conducting business, the cost and schedule risk factors are
identified and monitored, and to increase the skills of key staff members, a software
cost estimation process is followed. This process is responsible for tracking and
refining cost estimates throughout the project life cycle. This process also helps in
developing a clear understanding of the factors which influence software
development costs.
Cost of estimating software varies according to the nature and type of the
product to be developed. The cost of estimating an operating system, for example,
will be more than the cost estimated for an application program. Thus, in the
software cost estimation process, it is important to define and understand the
software which is to be estimated. Depending upon the nature of the project to be
estimated, different project estimation techniques can be used.
Estimation techniques use derived formulas to predict effort as a function of
LoC (Lines of Code) or FP. In these techniques, cost of software project is
expressed in terms of effort required to develop the software successfully. These
techniques are broadly classified into three categories:
 Empirical techniques: Estimation in these techniques depends on the
prior experience and domain knowledge of project managers. These
techniques do not use mathematical equations to estimate the cost of
software project. The various empirical estimation techniques are expert
judgement, estimation by analogy and price to win.
 Heuristic techniques: Estimation in these techniques is performed with
the help of mathematical equations which are based on historical data
or theory. In order to estimate costs accurately, various inputs are
provided to these techniques. These inputs include software size and
Self-Instructional
Material 73
Estimation and other parameters. To provide accurate cost estimation, most of the
Budgeting of Projects
heuristic estimation techniques are calibrated to the specific software
environment. The various heuristic estimation techniques used are
COCOMO (Constructive Cost Model), COCOMO II and software
NOTES equation.
 Analytical techniques: Estimation in these techniques has a scientific
basis. In this technique, certain basics regarding the project to be
estimated are assumed to derive the required results. One common
example of analytical technique is Halstead’s software science.
Note: We will discuss expert judgement, COCOMO and Halstead’s software
science in this unit.
4.2.1 Expert Judgement
In expert judgement, experts use their knowledge and skill to estimate the cost of
software project. While estimating the cost, experts make several assumptions
and judgements about the cost involved in the project. Experts apply a combination
of logic, common sense and experience, and use historical data to estimate
meaningful and relevant effort, which is then translated into cost. However, experts
may be biased, thus hampering the process of effort estimation.
One of the major obstacles in expert judgement is the inconsistency involved
in estimating effort. Inconsistency arises as a result of difference in opinions between
different experts regarding the effort of software project. To estimate cost
accurately, inconsistency should be removed. The Delphi technique can be used
to remove inconsistency in order to reach consensus in expert judgement by
gathering opinion from experts as well as providing an accurate and unbiased
estimate.
To use the Delphi technique, a number of steps are followed:
1. The coordinator issues specification and estimation form to the experts.
2. The experts hold a meeting to discuss issues regarding product and
estimation.
3. The experts produce an independent cost estimate.
4. The estimates are returned indicating the average estimate.
5. The experts hold a meeting again to discuss the results.
6. Once the results are discussed in the second meeting, the experts
prepare a revised independent estimate.
7. To reach consensus among the panel of experts, steps 3-6 are repeated.
4.2.2 Constructive Cost Model
In the early 1980s, Barry Boehm developed a model called COnstructive COst
MOdel (COCOMO) to estimate the total effort required to develop a software
project. The COCOMO model is commonly used as it is based on the study of
Self-Instructional
74 Material
already developed software projects. While estimating the total effort for a software Estimation and
Budgeting of Projects
project, costs of development, management and other support tasks are included.
However, the costs of secretarial and other staff are excluded. In this model, size
is measured in terms of Thousands of Delivered Lines of Code (KDLOC).
NOTES
In order to estimate the effort accurately, the COCOMO model divides
projects into three categories.
 Organic projects: These projects are small in size (not more than 50
KDLOC) and thus easy to develop. In organic projects, small teams
with prior experience work together to accomplish user requirements
which are less demanding. Most people involved in these projects have
a thorough understanding of how the software under development
contributes to achieve the organization’s objectives. Examples of organic
projects include simple business system, inventory management system,
payroll management system and library management system.
 Embedded projects: These projects are complex in nature (size is more
than 300 KDLOC) and the organizations have less experience in
developing such type of projects. Developers also have to meet stringent
user requirements. These software projects are developed under tight
constraints (hardware, software and people). Examples of embedded
systems include software system used in avionics and military hardware.
 Semi-detached Projects: These projects are less complex as the user
requirements are less stringent compared to embedded projects. The
size of a semi-detached project is not more than 300 KDLOC. Examples
of semi-detached projects include operating system, compiler design
and database design.
The various advantages and disadvantages associated with COCOMO
model are listed in Table 4.1.
Table 4.1 Advantages and Disadvantages of COCOMO Model

Advantages Disadvantages
 Easy to verify the working involved in it.  Difficult to accurately estimate size, in the
 Cost drivers are useful in effort estimation early phases of the project.
as they help in understanding the impact of  Vulnerable to misclassification of the
different parameters involved in cost project type.
estimation.  Success depends on calibration of the
 Efficient and good for sensitivity analysis. model according to the needs of the
 Can be easily adjusted according to the organization. This is done using historic
organization’s needs and environment. data which is not always available.
 Excludes overhead costs, travel cost and
other incidental cost.

The constructive cost model is based on the hierarchy of three models,

namely basic model, intermediate model and advance model.

Self-Instructional
Material 75
Estimation and 4.2.3 Basic Model
Budgeting of Projects
In basic model, only the size of the project is considered while calculating effort.
To calculate effort, the following equation (known as effort equation) is used:
NOTES E = A×(size) B ... (1)
Here, E is the effort in person-months and size is measured in terms of
KDLOC. The values of constants ‘A’ and ‘B’ depend on the type of the software
project. In this model, values of constants (‘A’ and ‘B’) for three different types of
projects are listed in Table 4.2.
Table 4.2 Values of Constants for Different Projects

Project Type A B
Organic project 2.4 1.05
Semi-detached project 3.0 1.12
Embedded project 3.6 1.20
If, for example, the project is an organic project having a size of 30 KDLOC,
then effort is calculated using equation 1:
E = 2.4×(30)1.05
E = 85 PM
4.2.4 Intermediate Model
In the intermediate model, parameters like software reliability and software
complexity are also considered along with the size while estimating effort. To
estimate the total effort in this model, a number of steps are followed.
1. Calculate an initial estimate of development effort by considering the size in
terms of KDLOC.
2. Identify a set of fifteen parameters derived from attributes of the current
project. All these parameters are rated against a numeric value called
multiplying factor. Effort adjustment factor (EAF) is derived by multiplying
all the multiplying factors with each other.
3. Adjust the estimate of development effort by multiplying the initial estimate
calculated in step 1 with EAF.
To understand the above-mentioned steps properly, let us consider an
example. For simplicity reasons, an organic project whose size is 45 KDLOC is
considered. In the intermediate model, the values of constants (A and B) are listed
in Table 4.3. To estimate the total effort in this model, the steps listed below are
followed.
1. An initial estimate is calculated with the help of effort equation 1. This
equation shows the relationship between the size and the effort required
to develop a software project. This relationship is given by the following
equation:
Self-Instructional
Ei = A × (size) B ... (2)
76 Material
 Here, Ei is the estimate of initial effort in person-months and the size Estimation and
Budgeting of Projects
is measured in terms of KDLOC. The value of constants ‘A’ and ‘B’
depend on the type of software project (organic, embedded, and semi-
detached). In this model, values of constants for different types of
projects are listed in Table 4.3. NOTES
Table 4.3 Values of Constants for Different Projects

Project Type A B
Organic project 3.2 1.05
Semi-detached project 3.0 1.12
Embedded project 2.8 1.20

Using equation 2 and the value of constant for organic project, initial
effort can be calculated as follows:
Ei = 3.2 × (45)1.05 = 174 PM
2. Fifteen parameters are identified. These parameters are called cost
driver attributes which are rated as very low, low, nominal, high,
very high or extremely high. In Table 4.4, for example, reliability of a
project can be rated according to this rating scale. In the same Table,
the corresponding multiplying factors for reliability are 0.75, 0.88,
1.00, 1.15 and 1.40.
Table 4.4 Effort Multipliers for Cost Drivers

Self-Instructional
Material 77
Estimation and Next, the multiplying factors of all cost drivers considered for the
Budgeting of Projects
project are multiplied with each other to obtain EAF. For instance,
using cost drivers listed in Table 4.5, EAF is calculated as:
0.8895 (1.15×0.85×0.91×1.00)
NOTES
Table 4.5 Cost Drivers in a Project

Cost Drivers Rating Multiplying Factor

Reliability High 1.15
Complexity Low 0.85
Application experience High 0.91
Programmer capability Nominal 1.00
3. Once EAF is calculated, the effort estimates for a software project is
obtained by multiplying EAF with initial estimate (Ei). To calculate
effort use the following equation:
Total effort = EAF×Ei
For this example, the total effort will be 155 PM.
4.2.5 Advance Model
In the advance model, effort is calculated as a function of program size and a set of
cost drivers for each phase of software engineering. This model incorporates all
characteristics of the intermediate model and provides the procedure for adjusting
the phase-wise distribution of the development schedule.
There are four phases in the advance COCOMO model, namely
requirements Planning and Product Design (RPD), Detailed Design (DD), Code
and Unit Test (CUT) and integration and test (IT). In advance model, each cost
driver is rated as very low, low, nominal, high, and very high. For all these ratings,
cost drivers are assigned multiplying factors. Multiplying factors for analyst capability
(ACAP) cost driver for each phase of advanced model are listed in Table 4.6.
Note that multiplying factors yield better estimates because the cost driver ratings
differ during each phase.
Table 4.6 Multiplying Factors for ACAP in Different Phases

Rating RPD DD CUT IT

Very low 1.80 1.35 1.35 1.50
Low 0.85 0.85 0.85 1.20
Nominal 1.00 1.00 1.00 1.00
High 0.75 0.90 0.90 0.85
Very high 0.55 0.75 0.75 0.70

Self-Instructional
78 Material
 A software project (of organic project type), for example, with a size of 45 Estimation and
Budgeting of Projects
KDLOC and rating of ACAP cost driver as nominal is considered (that is, 1.00).
To calculate the effort for code and unit test phase in this example, only ACAP
cost drivers are considered. Initial effort can be calculated by using equation 2:
NOTES
Ei = 3.2×(45)1.05 = 174 PM
Using the value of Ei, the final estimate of effort can be calculated by using
the following equation:
E = Ei×1
i,e., E = 174 × 1 = 174 PM
4.2.6 Halstead’s Software Science
M. H. Halstead proposed the first analytic laws for computer science by using a
set of primitive measures which can be derived once the design phase is complete
and code is generated. These measures are:
n1 = Number of distinct operators in a program
n2 = Number of distinct operands in a program
N1 = Total number of operators
N2 = Total number of operands
By using these measures, Halstead developed an expression for overall
program length, program volume, program difficulty, development effort,
and so on.
Program length (N) can be calculated by using the following equation:
N = n1 log2 n1 + n2 log2 n2
Program volume (V) can be calculated by using the following equation:
V = N log2 (n1+n2)
Note that program volume depends on the programming language used,
and represents the volume of information (in bits) required to specify a program.
For a particular algorithm, minimum volume exists. Volume ratio (L) can be
calculated by using the following equation:
Volume of the most compact form of a program
L=
Volume of the actual program
where, value of L must be less than 1. Volume ratio can also be calculated
by using the following equation:
L = 2/n1*n2/N2
Program difficulty level (D) and effort (E) can be calculated by using the
following equations:
D = (n1/2)*(N2/n2)
E=D*V Self-Instructional
Material 79
Estimation and
Budgeting of Projects 4.3 COCOMO MODEL
Bohem’s COCOMO (COnstructive COst MOdel) model is very useful for
NOTES software estimation. COCOMO refers to a group of models. The basic COCOMO
model is built around the following equation:
Effort = c(size) k
Here, effort is measured in pm (person-month), and size is measured in
kbsi (thousands of delivered source codes instruction). c and k are constants
which depend on Boehm’s classification of the system as ‘Organic’, ‘Semi-
Detached’ and ‘Embedded’.
Table 4.7 COCOMO Constants

System Type c k

Organic 2.4 1.05

Semi-detached 3.0 1.12
Embedded 3.6 1.20

 Organic mode: This is when a small team develops a small system which
is an in-house development and the user environment is well known to the
developer. The interface requirement is flexible here.
 Embedded mode: In this mode, the product is to operate within very
tight constraints and it is a costly affair to make any changes in the system.
 Semi-detached mode: This is a combination of organic and embedded
modes and has a characteristic which comes in between the two modes.
Organic, Semidetached and Embedded Software Projects
Boehm postulated that any software development project can be classified into
one of the three categories based on the complexity of development: organic,
semi-detached and embedded. In order to classify a product into the identified
categories, Boehm not only considered the characteristics of the product, but also
those of the development team and development environment. Roughly speaking,
these three product classes correspond to application, utility and system programs,
respectively. Usually, data processing programs are considered to be application
programs. Compilers, linkers, etc., are utility programs. Operating systems and
real-time system programs are system programs. System programs directly interact
with hardware and typically involve meeting timing constraints and concurrent
processing.
Boehm’s [1981] definitions of organic, semidetached, and embedded
systems have been elaborated as follows:
Organic: A development project can be considered of the organic type, if
the project deals with developing a well-understood application program, size of
the development team is reasonably small, and team members are experienced in
developing similar types of projects.
Self-Instructional
80 Material
 Semi-detached: A development project can be considered to be of the Estimation and
Budgeting of Projects
semi-detached type, if the development consists of a mixture of experienced and
inexperienced staff. Team members may have limited experience with related
systems and may be unfamiliar with some aspects of the system being developed.
NOTES
Embedded: A development project is considered to be of embedded type,
if the software being developed is strongly coupled with complex hardware, or if
stringent regulations on the operational procedures exist.
Intermediate COCOMO Model
The basic COCOMO model assumes that effort and development time are
functions of the product size alone. However, a host of other project parameters
besides the product size affect the efforts required to develop the product as well
as the development time. Therefore, in order to obtain an accurate estimation of
the effort and project duration, the effect of all relevant parameters must be taken
into account. The intermediate COCOMO model recognizes this fact and refines
the initial estimate obtained using the basic COCOMO expressions by using a set
of fifteen cost drivers (multipliers) based on various attributes of software
development.
For example, if modern programming practices are used, the initial estimates
are scaled downwards on multiplication with a cost driver having a value less than
1. If there are stringent reliability requirements on the software product, this initial
estimate is scaled upwards. Boehm requires the project manager to rate these
fifteen different parameters for a particular project on a scale of one to three.
Then, depending on these ratings, he suggests appropriate cost driver values which
should be multiplied with the initial estimate obtained using the basic COCOMO.
In general, cost drivers can be classified as being attributes of the following items:
Product: The characteristics of the product that are considered include the
inherent complexity of the product, reliability requirements of the product, etc.
Computer: Characteristics of the computer that are considered include the
execution speed required, storage space required, etc.
Personnel: The attributes of development personnel that are considered
include the experience level of personnel, programming capability, analysis
capability, etc.
Development environment: Development environment attributes capture
the development facilities available to developers. An important parameter which
is considered in this regard is the sophistication of automation (CASE) tools used
for software development.
Complete COCOMO Model
A major shortcoming of both the basic and intermediate COCOMO models is
that they consider a software product as a single homogeneous entity. However,
most large systems are made of several smaller subsystems. These sub-systems
Self-Instructional
Material 81
Estimation and may have widely different characteristics. For example, some subsystems may be
Budgeting of Projects
considered as organic type, some semi-detached, and some embedded. Not only
that, the inherent development complexity of the subsystems may vary, for some
subsystems the reliability requirements may be high, for some the development
NOTES team might have no previous experience of similar software development, and so
on. The complete COCOMO model considers these differences as prevalent in
the characteristics of subsystems and estimates the effort and development time as
the sum of estimates for the individual subsystems. The cost of each subsystem is
estimated separately. This approach reduces the margin of error in the final estimate.
The following development project is an example application of the complete
COCOMO model. A distributed Management Information System (MIS) product
for an organization having offices at several places across the country can have the
following sub-components:
 Database part
 Graphical User Interface (GUI) part
 Communication part
Of these, the communication part can be considered as embedded software.
The database part could be semi-detached software, and the GUI part could be
organic software. The costs for these three components can be estimated separately,
and summed up to give the overall cost of the system.
Software Design Issues

Cohesion
Cohesion is a measure of functional strength of a module. It is a well-established
theory that a good software design means clean decomposition of a problem into
modules. These modules are overall arranged in a hierarchy. After decomposition
of the problem, we finally get modules that have high cohesion and low coupling.
The module with high cohesion and low coupling is said to be functionally
independent of other modules. By the term functional independence, we mean
that a cohesive module performs a single task or function. If the modules are
functionally independent then there is minimal interaction with other modules.
Classification of Cohesion

The following are the different classes of cohesion that a module may have:
Coincidental Logical Temporal Procedural Communicational Sequential Functional

Low High

Fig 4.1 Classification of Cohesion

Self-Instructional
82 Material
 Coincidental cohesion: Let us assume that we have a module which has Estimation and
Budgeting of Projects
some functions. It is possible that the functions have been put into the module,
without any thought, out of coincidence. Coincidental cohesion can be explained
as a module’s performance of a set of tasks that relate to each other on very loose
grounds. The module is said to contain a random collection of functions. Like, in NOTES
case of a Transaction Processing System (TPS), the get-input, print-error, and
summarize-members functions are grouped into one module. This grouping is not
of any relevance to the structure of the problem.
Logical cohesion: When all elements of a module perform similar and
logically-related operations, such as error handling, data input, data output, and
so on the module is said to have logical cohesion; for example, a situation where
a set of print functions generating different output reports are arranged into two
single modules.
Temporal cohesion: This refers to a set of functions of a module that are
executed in the same timespan. Say, a set of functions in a module that are related
to one another by way of concept, that they have to be executed at the same time.
For example, functions that are responsible for start-up and shutdown of some
processes show temporal cohesion.
Communicational cohesion: This type of cohesion is when all the functions
of a module refer to or update the same data structure, for example, the set of
functions defined on an array or a stack.
Procedural cohesion: This cohesion is when the set of functions of a module
are part of a procedure (an algorithm), in which steps have to be carried out in a
particular sequence for achieving an objective; for example, the algorithm for
decoding a message.
Functional cohesion: This cohesion is when different elements of a module
cooperate with each other to achieve a single function. For example, in case of an
employees’ payroll system, the module containing all the functions is required to
manage that.
Sequential cohesion: This type of cohesion is when the elements of a module
form the parts of a sequence, where the output from one element of the sequence
is input to the next. For example, in a TPS, the get-input, validate-input, sort-input
functions are grouped into a single module.
Coupling
Coupling is a measure of the degree of interdependence or interaction between
two modules. A module is said to have high cohesion and low coupling when it is
functionally independent. A reason for high level of independence could be due to
large amount of data interchanged between two modules. The complexity of
interfaces between two modules determines the degree of coupling between them.

Self-Instructional
Material 83
Estimation and Classification of Coupling
Budgeting of Projects
There is not really any particular technique to estimate coupling between two
modules accurately. To estimate the degree of coupling between modules, we
NOTES need to classify them. The following are the five types of coupling that occur
between any two modules.
Low High

Fig 4.2 Classification of Coupling

Data coupling: It refers to the communication between two modules through

a parameter; for example, when an elementary data item such as an integer, a float
or character is passed as a parameter between two modules. This data item should
be related to the problem. It should not be used for the purpose of control.
Stamp coupling: It refers to communication between two modules using a
composite data item, such as a record in PASCAL or a structure in C.
Control coupling: This type of coupling happens when one module directs
the order of instructions’ execution to another module; for example, a flag set in
one module that is tested in another module.
Common coupling: This type of coupling is when two modules share data
through data items that are global in nature.
Content coupling: When two modules share codes, then share code content
coupling is said to exist between them; for example, a branch from one module
into another module.
Functional independence
A module is said to be functionally independent of other modules if it has high
cohesion and low coupling. A cohesive module performs a single task of a function
and has minimum interaction with other modules.
Need for functional independence
The following are the reasons that outline why we need functional independence:
 Error isolation: Functional independence reduces the propagation of error
from one module to another. When a module is functionally independent, its
interaction with other modules is very less. So, if there is any error in a
functionally independent module, the error would not affect the other
modules.
 Scope of reuse: A functionally independent module is well defined and precise,
so its interaction with other modules is simple in nature and minimum in
frequency. This makes the reuse of a module possible.
 Understandability: Since modules function independently of each other,
this approach helps in reducing the complexity of a design. Different modules
Self-Instructional
are understood separately as they are independent of each other.
84 Material
Function-oriented design Estimation and
Budgeting of Projects
The features of a function-oriented design approach are as follows:
1. Every system performs a set of functions. These functions are divided into a
hierarchy of sub-functions. When we start from the top of the hierarchical NOTES
system, we find that each function branches out into a number of detailed
functions. For example, let us assume a function, ‘create-new-library-
member’. This function creates the record for every new member who
joins the library. It assigns a unique membership number to the member,
and prints a bill towards his membership charge. This function may consist
of the following sub-functions:
 Assign-number-for-membership
 Create-record-for-member
 Print-bill
Each of the above sub-functions can be partitioned into numerous sub-
functions.
2. Different functions share the system state. It is a centralized system. For
example, data such as member-records are available for reference along
with updates to several functions such as:
 Create-new-member
 Delete-member
 Update-member-record
Object-oriented design
In this design approach, we view the system as a collection of objects or entities.
State information is managed by each of the objects. The state is decentralized
among the objects.
For example, if we take the case of a library, each library member is treated
as an individual object with respect to the Library Automation Software. Every
member has its own set of data and has related functions to be performed on this
data. Also, the functions that are defined for a single object cannot change the
data of other objects. The state of an object is defined by its internal data. Objects
that exhibit similar characteristics are grouped into a class. Every object is a member
of a particular class. These classes inherit properties/features from a Super Class.
Objects communicate with each via message passing.
Function-oriented vs object-oriented design approach
The following are the differences between a function-oriented and an object-oriented
design (OOD):
 Unlike function-oriented design methods, the basic abstraction in OOD are
not real-world functions, such as sort, display, track, but real-world entities,
such as employee, picture, machine, radar system, Example: In OOD
Self-Instructional
Material 85
Estimation and approach, developing an employee pay-roll software does not just comprise
Budgeting of Projects
designing functions such as get-employee-address and update-employee-
record, but designing of objects such as employees, departments, and so
on. Grady Booch sums up this difference as, ‘Identify verbs if you are
NOTES after procedural design and nouns if you are after object-oriented
design’.
 In case of an OOD approach, there is distribution of state information
among the objects of the system which is not represented in a centralized
shared memory. For example, in a traditional programming system,
employee data such as their names, basic salary, date of birth, place of
posting, their code number , and so on are generally implemented as
global or common data; whereas in an object-oriented system the data
gets distributed among different employee objects that exist in the system.
Objects communicate with each other via message passing. So, on
interrogation, an object may discover another object’s state of information.
There is scope for many such cases wherein the real-world functions
should be implemented. Functions are usually associated with specific
real-world entities (objects); in an OOD, they access only part of the
system state information directly.
 An SA/SD group is a function-oriented technique group in nature. Such
groups function together if they constitute a higher-level function, as a group.
On the contrary, object-oriented techniques group functions together on
the basis of the data they operate on.
The following example will bring out the differences between object-oriented
and function-oriented design approaches:
Example 4.1: A Fire-Alarm System
If the owner of a large multi-stored building wants to install a computerized fire
alarm system for his building he would want smoke detectors and fire alarms to be
placed in each room of the building. A fire alarm system’s function should be to
monitor the status of the smoke detectors. If any of the smoke detectors report a
fire condition, the fire alarm system should locate the area where the fire condition
has been reported. Once the fire alarm detector has been able to spot it, it will
sound the fire alarm in the neighbouring locations. The fire alarm system should
flash an alarm message on the computer console too. This console is manned by
the fire fighting personnel round the clock. After a fire condition has been
successfully handled, the fire alarm system should support resetting the alarms by
the fire fighting personnel.
Function-Oriented Approach

/* Global data (system state) accessible by various

functions */
Self-Instructional
86 Material
 Estimation and
Budgeting of Projects
BOOL detector_status[MAX_ROOMS];
int detector_locs[MAX_ROOMS];
BOOL alarm_status[MAX_ROOMS];
NOTES
/* alarm activated when status is set */
int alarm_locs[MAX_ROOMS];

/* room number where alarm is located */

int neighbor-alarm[MAX_ROOMS][10];

/* each detector has at most 10 neighboring locations

*/
The functions which operate on the system state are:
interrogate_detectors();
get_detector_location();
determine_neighbor();
ring_alarm();
reset_alarm();
report_fire_location();
Object-Oriented Approach:
class detector
attributes:
status, location, neighbors
operations:
create, sense_status, get_location,
find_neighbors
class alarm attributes:
location, status
operations:
create, ring_alarm, get_location,
reset_alarm
An appropriate number of instances of the class detector and alarm should
be created. This is a feature of the ‘object-oriented program’. If we examine the
object-oriented program and function-oriented program, we can see that in the
function-oriented program, the system state is centralized and several functions
accessing this central data are defined. The state information is distributed among
various sensor and alarm objects in case of object-oriented program.
Self-Instructional
Material 87
Estimation and It is not compulsory to implement features of an object-oriented design
Budgeting of Projects
using only an object-oriented language. The function of an object-oriented language
is that it helps in facilitating the implementation of an OOD. The definition of all the
basic mechanisms of class, inheritance, objects, methods, etc., is further
NOTES strengthened by object-oriented languages such as Java, C++ support. They also
support all the key object-oriented concepts that have been discussed here. OOD
can be implemented using a conventional procedural language as well. Though, it
would take more effort that way than what it would take to implement it using an
object-oriented language.
The function-oriented and object-oriented approaches are two absolutely
different approaches to software design. But the approaches are complementary
in nature and not competitive to a great extent. For example, once the classes
have been identified, the top-down function-oriented technique is applied to design
the internal methods of a class. Externally, it would seem as if the system has been
developed on the lines of an object-oriented technique. But, internally, for each
class, it would be a hierarchy of functions designed in a top-down manner.

4.4 BUDGETING

Project budget has two components in it, cost and cash flow. Cash flow budget is
required for liquidity planning and for obtaining funds in time. A budget offer has to
work in close coordination with the technical staff who prepare project network
and with the procurement officers.
After a resource requirement list has been prepared, the next stage is to
map this to the activity plan to access the distribution of resources required over
the duration of the project. It is better to represent the activity plan as a bar chart
and use this to produce resource histogram for each resource.
In practice, resources have to be allocated to a project on an activity-by-
activity basis and finding the best allocation is time-consuming and difficult. As
soon as a member of the project team is allocated an activity, that activity acquires
a start and finish dates on the schedule. Thus, allocating a resource to one activity
limits the flexibility for resource allocation and scheduling for other activities.

Check Your Progress

1. Define the term software cost estimation.
2. Write the four phases for advance COCOMO model.
3. State about the intermediate COCOMO model.
4. What is cohesion?
5. Elaborate on the term coupling.
6. Explain the term budgeting.
Self-Instructional
88 Material
 Estimation and
4.5 ANSWERS TO CHECK YOUR PROGRESS Budgeting of Projects

QUESTIONS

1. Cost of estimating software varies according to the nature and type of the NOTES
product to be developed. The cost of estimating an operating system, for
example, will be more than the cost estimated for an application program.
Thus, in the software cost estimation process, it is important to define and
understand the software which is to be estimated. Depending upon the
nature of the project to be estimated, different project estimation techniques
can be used.
2. There are four phases in the advance COCOMO model, namely
requirements Planning and Product Design (RPD), Detailed Design (DD),
Code and Unit Test (CUT) and integration and test (IT). In advance model,
each cost driver is rated as very low, low, nominal, high, and very high.
3. The intermediate COCOMO model recognizes this fact and refines the
initial estimate obtained using the basic COCOMO expressions by using a
set of fifteen cost drivers (multipliers) based on various attributes of software
development.
4. Cohesion is a measure of functional strength of a module. It is a well-
established theory that a good software design means clean decomposition
of a problem into modules. These modules are overall arranged in a
hierarchy. After decomposition of the problem, we finally get modules that
have high cohesion and low coupling.
5. Coupling is a measure of the degree of interdependence or interaction
between two modules. A module is said to have high cohesion and low
coupling when it is functionally independent. A reason for high level of
independence could be due to large amount of data interchanged between
two modules. The complexity of interfaces between two modules determines
the degree of coupling between them.
6. Project budget has two components in it, cost and cash flow. Cash flow
budget is required for liquidity planning and for obtaining funds in time. A
budget offer has to work in close coordination with the technical staff who
prepare project network and with the procurement officers.

4.6 SUMMARY

 Cost of estimating software varies according to the nature and type of the
product to be developed. The cost of estimating an operating system, for
example, will be more than the process, it is important to define and
understand the software which is to be estimated. Depending upon the
nature of the project to be estimated, different project estimation techniques
can be used. Self-Instructional
Material 89
Estimation and  In expert judgement, experts use their knowledge and skill to estimate the
Budgeting of Projects
cost of software project. While estimating the cost, experts make several
assumptions and judgements about the cost involved in the project.
 Experts apply a combination of logic, common sense and experience, and
NOTES
use historical data to estimate meaningful and relevant effort, which is then
translated into cost. However, experts may be biased, thus hampering the
process of effort estimation.
 In the early 1980s, Barry Boehm developed a model called COnstructive
COst MOdel (COCOMO) to estimate the total effort required to develop
a software project.
 The COCOMO model is commonly used as it is based on the study of
already developed software projects. While estimating the total effort for a
software project, costs of development, management and other support
tasks are included. However, the costs of secretarial and other staff are
excluded. In this model, size is measured in terms of thousands of Delivered
Lines Of Code (KDLOC).
 In basic model, only the size of the project is considered while calculating
effort.
 In the intermediate model, parameters like software reliability and software
complexity are also considered along with the size while estimating effort.
 In the advance model, effort is calculated as a function of program size and
a set of cost drivers for each phase of software engineering. This model
incorporates all characteristics of the intermediate model and provides the
procedure for adjusting the phase-wise distribution of the development
schedule.
 There are four phases in the advance COCOMO model, namely
requirements Planning and Product Design (RPD), Detailed Design (DD),
Code and Unit Test (CUT) and Integration and Test (IT). In advance model,
each cost driver is rated as very low, low, nominal, high, and very high.
 Bohem’s COCOMO (COnstructive COst MOdel) model is very useful
for software estimation. COCOMO refers to a group of models.
 Boehm postulated that any software development project can be classified
into one of the three categories based on the complexity of development:
organic, semi-detached and embedded.
 The intermediate COCOMO model recognizes this fact and refines the
initial estimate obtained using the basic COCOMO expressions by using a
set of fifteen cost drivers (multipliers) based on various attributes of software
development.
 Cohesion is a measure of functional strength of a module. It is a well-
established theory that a good software design means clean decomposition
Self-Instructional
90 Material
 of a problem into modules. These modules are overall arranged in a Estimation and
Budgeting of Projects
hierarchy. After decomposition of the problem, we finally get modules that
have high cohesion and low coupling.
 Coupling is a measure of the degree of interdependence or interaction
NOTES
between two modules. A module is said to have high cohesion and low
coupling when it is functionally independent. A reason for high level of
independence could be due to large amount of data interchanged between
two modules. The complexity of interfaces between two modules determines
the degree of coupling between them.
 Object-oriented design approach, we view the system as a collection of
objects or entities. State information is managed by each of the objects.
The state is decentralized among the objects.
 Project budget has two components in it, cost and cash flow. Cash flow
budget is required for liquidity planning and for obtaining funds in time. A
budget offer has to work in close coordination with the technical staff who
prepare project network and with the procurement officers.

4.7 KEY WORDS

 Software cost estimation: Cost of estimating software varies according

to the nature and type of the product to be developed.
 Advance model: In the advance model, effort is calculated as a function of
program size and a set of cost drivers for each phase of software engineering.
 Cohesion: The measure of functional strength of a module.
 Coupling: A measure of the degree of interdependence or interaction
between two modules.
 Functional independence: Amodule having high cohesion and low coupling
is said to be functionally independent of other modules.
 Budgeting: Project budget has two components in it, cost and cash flow.

4.8 SELF ASSESSMENT QUESTIONS AND

EXERCISES

Short-Answer Questions
1. What is expert judgement?
2. Explain the term constructive cost model.
3. Define the term Halstead’s software science.
4. Write the features of function-oriented design.
5. Differentiate between function-oriented and object-oriented design approach.
Self-Instructional
Material 91
Estimation and Long-Answer Questions
Budgeting of Projects
1. Briefly explain the categories into which various cost estimation techniques
are classified.
NOTES 2. The COCOMO model is based on the hierarchy of three models, namely
the basic model, intermediate model and advance model. Explain these
models giving examples.
3. Discuss about the organic, semidetached and embedded software projects
giving appropriate examples.
4. Describe the relationship between cohesion and coupling in detail with
examples.
5. Briefly explain the budgeting giving appropriate examples.

4.9 FURTHER READINGS

Hughes, Bob, Mike Cotterell and Rajib Mall. 2017. Software Project
Management (SIE), 6th Edition. New York: McGraw Hill Education.
Schach, Stephen R. 2005. Object Oriented and Classical Software Engineering.
New Delhi: Tata McGraw-Hill.
Pressman, Roger S. 1997. Software Engineering, a Practitioner’s Approach.
New Delhi: Tata McGraw-Hill.
Somerville, Ian. 2001. Software Engineering. New Delhi: Pearson Education.
Ghezzi, Carlo, Mehdi Jazayeri, and Dino Mandriolli. 1991. Fundamentals of
Software Engineering. New Delhi: Prentice-Hill of India.
Jawadekar, Waman S. 2004. Software Engineering: Principles and Practice.
New Delhi: Tata McGraw-Hill.
Jalote, Pankaj. 1991. An Integrated Approach to Software Engineering. New
Delhi: Narosa Publishing House.

Self-Instructional
92 Material
 Project Scheduling
BLOCK - II
PROJECT SCHEDULING & RISK MANAGEMENT

NOTES
UNIT 5 PROJECT SCHEDULING
Structure
5.0 Introduction
5.1 Objectives
5.2 Scheduling Techniques
5.3 Automated Tools
5.4 Answers to Check Your Progress Questions
5.5 Summary
5.6 Key Words
5.7 Self Assessment Questions and Exercises
5.8 Further Readings

5.0 INTRODUCTION

Project scheduling essential to project perform scheduling to effectively manage

the tasks of the project. Project scheduling provides details, such as start date and
end date of the project, milestones and tasks for the project. In addition, it specifies
the resource, (such as people, equipment and facilities) required to complete the
project on each other. An appropriate project schedule prepared according to
project plain not only aims to complete the project on time but also helps t avoid
the additional cost incurred when the project is delayed.
The Program Evaluation and Review Technique (PERT) is a statistical tool
used in project management, which was designed to analyze and represent
the tasks involved in completing a given project. The Project Management Body
of Knowledge defines the work-breakdown structure as a ‘Hierarchical
decomposition of the total scope of work to be carried out by the project team to
accomplish the project objectives and create the required deliverables.’
The Critical Path Method (CPM), or Critical Path Analysis (CPA), is
an algorithm for scheduling a set of project activities. It is commonly used in
conjunction with the Program Evaluation and Review Technique (PERT). A critical
path is determined by identifying the longest stretch of dependent activities and
measuring the time required to complete them from start to finish. A Gantt chart is
a graphical representation of the project. It is used in project scheduling to depict
the activities of the project. This chart shows the start and end dates of each
activity in the project. Engineers can now have numerical control over automated
devices. The result has been a rapidly expanding range of applications and human
activities.
Self-Instructional
Material 93
Project Scheduling In this unit, you will study about the scheduling techniques, Program
Evaluation and Review Techniques (PERT), Gantt chart, Critical Path Method
(CPM), and automated tools.

NOTES
5.1 OBJECTIVES

After going through this unit, you will be able to:

 Define the tasks in scheduling techniques
 Elucidate on the Program Evaluation and Review Techniques (PERT)
 Understand the basics of Gantt chart
 Discuss about the Critical Path Method (CPM)
 Explain the automated tools

5.2 SCHEDULING TECHNIQUES

It is essential to perform project scheduling to effectively manage the tasks of the

project. Project scheduling provides details, such as start date and end date of the
project, milestones and tasks for the project. In addition, it specifies the resources
(such as people, equipment and facilities) required to complete the project and
the dependencies of tasks of the project on each another. An appropriate project
schedule prepared according to project plan not only aims to complete the project
on time but also helps to avoid the additional cost incurred when the project is
delayed.
There are various factors that delay project schedule. The common factors
are as follows:
 Unrealistic deadline: Project schedule is affected when the time
allocated for completing a project is impractical and not according to
the effort required for it. Generally, this situation arises when deadline is
established by inexperienced individual(s) or without the help of the
project management team. Here, the project management team is
constrained to work according to that deadline. The project is delayed
if the deadline is not met.
 Changing user requirements: Sometimes, project schedule is affected
when user requirements are changed after the project has started. This
affects the project schedule, and thus more time is consumed both in the
revision of project plan and the implementation of new user requirements.
 Underestimation of resources: If the estimation of the resources for
the project is not done according to its requirement, the schedule gets
affected. This underestimation of resources leads to delay in performing
tasks of the project.
Self-Instructional
94 Material
  Lack of consideration of risks: Risks should be considered during Project Scheduling

project planning and scheduling; otherwise, it becomes difficult for the

project management team to prevent their effect during software
development.
NOTES
 Lack of proper communication among team members: Sometimes,
there is no proper communication among the project management team
members to resolve the problems occurring during software
development. This in turn makes it difficult for the project management
team to understand and develop the software according to user
requirements and schedule.
 Difficulties of team members: Software projects can also be delayed
due to unforeseen difficulties of the team members. Some of the team
members, for example, may require leave for personal reasons.
 Lack of action by the project management team: Sometimes, the
project management team does not recognize that the project is getting
delayed. Thus, they do not take necessary action to speed up the software
development process and complete it on time.
Generally, the task of assigning the end date is done by the project sponsor
or the user. While preparing the project schedule, the project manager assists the
project sponsor by providing information about the project scope, deliverables
and resources. In addition, the project manager provides an estimate of the time
needed to complete the project tasks. Preparing an accurate project schedule is a
difficult task and requires thorough knowledge about the processes and time needed
to perform them. Once the project schedule is fixed, the project manager is
responsible for monitoring the progress of the project. If there is a need to revise
the project schedule, the project manager communicates with the project
management team members.
Principles of Project Scheduling
To carry out project scheduling appropriately, some principles are followed. These
principles help the project management team to prepare the project schedule. The
commonly followed principles are listed as follows.
 Compartmentalization: It divides the project into several tasks. The
purpose of compartmentalization is to make the project manageable. Thus,
it becomes easier to prepare the project schedule according to these tasks.
 Interdependency: It determines the interdependency of one or more
activities or tasks on each other. All the activities of the project are not
independent. There are various activities that are performed sequentially,
whereas some of the activities are executed together with other activities.
On the other hand, some activities cannot begin until the activity on which
they are dependent is complete.

Self-Instructional
Material 95
Project Scheduling  Time allocation: It determines the time to be allocated to each project
management team member for performing specified activities. However,
before allocating time, it is important to estimate the effort required by them
to complete the assigned task. In addition, the project management team
NOTES members should be assigned a start date and an end date according to the
work to be conducted on full-time or part-time basis.
 Effort validation: It ensures that the efforts required to perform the assigned
task are valid. In other words, it should verify that the task allocated to one
or more project management team members is according to the effort
required for each task. This is because every project management team has
defined number of team members. Hence, the project manager should
allocate the tasks according to the effort and time required to complete the
task.
 Defined responsibilities: It specifies the roles and responsibilities of every
project management team member. Hence, the task should be allocated
according to the skills and abilities of team members to perform the assigned
task.
 Defined outcomes: It specifies the outcomes of every task performed by
the project management team members. The outcome is achieved after
completion of a task. Generally, the outcome of a task is in the form of
product and these products are combined in deliverables.
 Defined milestones: It specifies the milestones when work products are
complete and reviewed for quality.
Milestones
Milestones are formal representations of the progress of a project. Generally,
milestones are planned when deliverables are provided. Milestones describe the
end point when software process activity is completed. After the completion of a
milestone, its output is described in the form of a document. This document
comprises information about the completion of a phase of the project. Note that
these documents are used as a reference for the project management team only
and are not delivered to the user.
It is difficult to keep in mind all the task(s) being performed during software
development. Hence, each task is recorded in documents which describe the
work being done in that phase. With the help of these documents, it becomes easy
for the project manager to check the status of the project. In addition, milestones
have several advantages.
 They help in the completion of the project according to schedule.
 They help in completing the project according to allocated budget.
 They report status of the project to the management.

Self-Instructional
96 Material
 Project Scheduling

NOTES

Fig. 5.1 Examples of Milestones

Figure 5.1 shows examples of milestones in requirements and design phases

of the project. ‘Milestone 1’, ‘Milestone 2’ and ‘Milestone 3’ represent the
completion of tasks in the requirements phase. Similarly, ‘Milestone 4’, ‘Milestone
5’, ‘Milestone 6’ and ‘Milestone 7’ represent the completion of tasks in the design
phase. Each milestone represents the completion of a specific task. ‘Milestone
1’, for example, represents the completion of feasibility study and ‘Milestone 2’
represents the completion of requirements definition. Similarly, in the design phase,
‘Milestone 4’ represents the completion of architectural design, and so on.
In project scheduling, there are several important aspects that are considered.
These include techniques of project scheduling, task network and tracking
the schedule. Techniques of project scheduling focus on checking the activities
that are completed according to project schedule. In addition, these techniques
describe the information about activities in graphical form so that it is easy for a
project management team to understand the time and effort required for each
activity. Task network focusses on how the entire software project can be broken
into several manageable tasks which are understandable by the project management
team. Tracking the schedule focusses on finding ways to complete the project
according to the schedule.
Techniques of Project Scheduling
Several techniques are used for keeping track of the project schedule. These
techniques are applied after information is collected from the project planning
activities. This information includes the estimation of effort, selection of suitable
process model, decomposition of tasks into multiple sub-tasks, and so on. The
commonly followed techniques for project scheduling include Gantt chart, PERT
chart and critical path method.

Self-Instructional
Material 97
Project Scheduling Gantt Chart
A Gantt chart is a graphical representation of the project. It is used in project
scheduling to depict the activities of the project. This chart shows the start and
NOTES end dates of each activity in the project. In addition, it shows the week, month, or
quarter required to complete each activity. Due to this fact, Gantt chart is also
known as timeline chart. It shows information about activities in the form of
horizontal bars. Generally, a Gantt chart is prepared on a graph paper. In case a
Gantt chart is big and complex, it is prepared using applications, such as Microsoft
Excel.
A Gantt chart helps the project manager by providing a graphical illustration
of the project schedule. It has the following advantages:
 It represents the project in graphical form.
 It reports the status of project by showing the progress of each activity.
 It keeps a record of the activities being performed in the project.
 It depicts milestones after completion of each activity.
 It describes the tasks which are assigned to the project management
team members.

Fig. 5.2 Gantt Chart

The schedule of two projects can vary from each other due to differences in
user requirements. Hence, the Gantt chart also varies according to the project
schedule. Figure 5.2 shows an example of Gantt chart for schedule of a project.
The horizontal bars depict the total time span of the project activities. This time
span is further divided into months, weeks and days. The time consumed to perform
a specific activity is shown in increments. The vertical axis depicts the activities
involved in the project. The tasks shown on the vertical axis, for example, are

Self-Instructional
98 Material
preliminary investigation, writing report, conducting interviews, and so on. Note Project Scheduling

that the shaded parts of horizontal bars show the parts of activities that are completed
while the unshaded parts show the part of activities that are not completed.
Horizontal bars vary in lengths depending on the amount of time required for the
completion of a specific activity. In addition, the activities can commence NOTES
sequentially, in a parallel manner, or after completion of one or more activities.
Hence, span of one or more activities can overlap each other. As the project
progresses, the unshaded bars are shaded accordingly to indicate the completion
of activities. The vertical line represents the report date.
PERT Chart
The Program Evaluation and Review Technique (PERT) chart is used to schedule,
organize and coordinate tasks within the project. The objective of PERT chart is
to determine the critical path which comprises critical activities that should be
completed on schedule. This chart is prepared with the help of information
generated in project planning activities, such as estimation of effort, selection of
suitable process model for software development and decomposition of tasks into
sub-tasks. The advantages of using PERT chart are as follows:
 It represents the project in graphical form.
 It provides information about the expected completion time of the project.
 It describes the probability of completion of project before the specified
date.
 It specifies the activities that form the critical path.
 It specifies the start and end dates of activities involved in the project.
 It describes the dependencies of one or more tasks on each other.
Figure 5.3 shows an example of a PERT chart. The milestones are numbered
as ‘1’, ‘2’, ‘3’, ‘4’, and ‘5’ and are represented by circles. When a milestone is
completed, it is assigned a greater number than the previous milestones. Each
milestone is linked with one or more arrows. The activities of the project are
represented by ‘A,’ ‘B’, ‘C’, ‘D’, ‘E’ and ‘F’. The direction of arrows determines
the sequence of activities. When activities are completed in sequence, they are
known as serial activities. Here activities ‘A’, ‘C’ and ‘F’ are performed in
sequence. Similarly, activities ‘B’ and ‘E’ are serial activities. On the other hand,
when two or more activities are performed simultaneously, they are known as
concurrent activities or parallel activities. Here, activities ‘A’ and ‘B’ and
activities ‘C’and ‘D’ are performed concurrently. Each activity is allocated a specific
amount of time which is depicted by ‘t’. Here, activity ‘A’ requires three weeks to
get completed, activity ‘B’ requires four weeks, and so on.

Self-Instructional
Material 99
Project Scheduling

NOTES

Fig. 5.3 PERT Chart

To create a PERT chart, the following steps are used.

1. Identify activities and milestones: In this step, the activities and
milestones that are required to complete the project are described.
Once the tasks and milestones are specified, it is easy to understand
the sequence and duration of each activity.
2. Identify sequence of activities: In this step, the sequence of activities
is determined. The sequence describes the dependency of one activity
on another. These activities can either be serial or concurrent. Based
on the sequence and dependency of activities, the relationships among
activities are depicted. Note that this step is sometimes combined
with step 1.
3. Prepare PERT chart: In this step, the PERT chart is prepared.
4. Estimate the time consumed in activities: In this step, the amount
of time required in carrying out each activity is specified. The time can
be estimated in months, weeks or days. Generally, the time estimates
followed to determine the time required in the activities are:
 Optimistic time: It is the shortest time in which an activity can
be completed.
 Most likely time: It is the completion time having the highest
probability.
 Pessimistic time: It is the longest time that an activity may require
for completion.
5. Determine critical path: In this step, the critical path for completion
of activities is specified. The critical path determines the calendar time
required to complete a series of activities according to the project
Self-Instructional
100 Material
 schedule. Note that the speed-up or delay in activities that are outside Project Scheduling

the critical path do not affect the total project time.

6. Update PERT chart: In this step, the PERT chart is modified as
changes take place in the project and on completion of each activity.
NOTES
This chart is also updated when there is a delay in the completion of
activities or when additional resources are required to complete the
project on time.
Critical Path Method (CPM)
Critical path method is a technique that determines those activities which have the
least scheduling flexibility (that is, critical activities). Note that if the critical activities
are delayed, the entire project is delayed. After determining these activities, CPM
specifies the project schedule according to the activities that lie on the critical path.
The advantages of using critical path method are as follows:
 It represents the project in graphical form.
 It predicts the time required to complete the project.
 It specifies the critical activities.
 It specifies how to speed up the project so that it is completed on schedule.
 It specifies the optimal plan for speeding up the project.

Fig. 5.4 CPM Diagram

Figure 5.4 shows the CPM diagram. It comprises activities and events which
form a network. The activities are shown in circles (also known as nodes) and
named as ‘A’, ‘B’, ‘C’, ‘D’, ‘E’ and ‘F’. The events begin from ‘start’ node and
end at ‘finish’ node. The lines (or arcs) between the activities show the events. The
time required to complete each activity is indicated along with it. First of all, activities
‘A’ and ‘B’ begin. Two activities, namely ‘C’ and ‘D’ are dependent on ‘A’.
Similarly, activity ‘E’ is dependent on ‘B’. In other words, the activities ‘C’, ‘D’
and ‘E’ cannot begin until the activities ‘A’ and ‘B’ are complete. After the activities
‘F’, ‘D’ and ‘E’ are complete, they reach the ‘finish’ node.

Self-Instructional
Material 101
Project Scheduling To create a CPM diagram, the steps mentioned below are followed.
1. Determine the individual activities: In this step, the activities
determined with the help of work breakdown structure are described.
NOTES 2. Determine the sequence of activities: In this step, the sequence of
activities and the time taken to complete each activity are described.
These activities are carried out both serially or in a parallel manner.
There are some activities which are dependent on other activities before
they can be carried out. For these activities the dependency is
determined according to which the sequence is specified.
3. Prepare the CPM diagram: In this step, the CPM diagram is
prepared after determining the activities and their sequence.
4. Estimate the activity completion time: The completion time of
each activity is estimated with the help of knowledge gained through
experience by the organization or individuals. This is essential because
estimation of completion time for the activity should be correct and
there should be no variation in the completion time.
5. Identify the critical path: Critical path is the path through the project
network where no activity is slack. The amount of time for which a
non-critical path activity can be delayed without delaying the project
is known as slack time. Slack time for an activity is the time between
its earliest start time and latest start time, or between its earliest finish
time and latest finish time. Critical path is identified by determining
certain parameters of each activity. These parameters are:
 Earliest start time (ES): It is the earliest start time when an
activity can begin. It is assumed that the previous activities on
which the activity depends are complete.
 Earliest finish time (EF): It is equal to the earliest start time for
the activity along with the time required to complete the activity.
 Latest finish time (LF): It is the latest time at which the activity
can be completed without delaying the project.
 Latest start time (LS): It is equal to the difference of the latest
finish time with the time required to complete the activity.
6. Update the CPM diagram: In this step, the information about the
actual completion time of tasks is included as the project progresses
or when changes take place in it. According to the time taken to
complete an activity, the CPM diagram is updated. In addition, CPM
can be updated when there is a new critical path in the project.
Example of CPM
Consider an example of developing software. Table 5.1 lists all the activities of
software development. It describes the start time of each activity along with its
Self-Instructional
102 Material
duration. In addition, the type of activity and the dependent activity are also Project Scheduling

specified.
Table 5.1 Activities of Software Development
NOTES

In Figure 5.5, events within the project are shown in circles. The circles are
numbered to identify each activity with the rest of the activities. An arrow between
two events shows an activity. The description of each activity is depicted above or
below the arrow. In addition, the duration of each activity is shown. Note that all
arrows are from left to right. Activities ‘2’ and ‘4’ (see Table 5.1), cannot begin
until activity ‘1’ is complete.

Fig. 5.5 CPM Diagram for Software Development

The numbers above and below the circles specify the time consumed in
completing the activities. These numbers show the latest finish time. The latest
finish time is calculated by starting from the last event (in this example, it is number
7) and moving backwards.

Self-Instructional
Material 103
Project Scheduling Event ‘4’ can be completed any time between ‘1.2 weeks’ and ‘7.8 weeks’.
The timing of this event is not critical since it is not on the critical path. It is essential
that events ‘1’ to ‘2’, ‘2’ to ‘3’, ‘3’ to ‘4’, ‘4’ to ‘5’, ‘5’ to ‘6’ and ‘6’ to ‘7’ are
started and completed on time so that the software development is completed in
NOTES ‘10 weeks’. This is known as ‘critical path’. The critical path activities should be
managed to ensure that they are completed on time. In case, the critical path
activities are delayed, proper measures should be taken to get the software
development back on schedule.
Similarities between PERT Chart and CPM Diagram
Sometimes, both PERT chart and CPM are used in combination and considered
as one technique known as PERT/CPM technique. They are used together as
they have the following similarities:
 They define the activities and tasks of the project. Both PERT and CPM
have a single ‘start’ and single ‘finish’ activities.
 They define relationships among the activities. In addition, both of them
specify the sequence of activities.
 They prepare a diagram connecting all the activities.
 They assign the time and cost estimates to each activity.
 They determine the critical path in the entire network.
 They use the diagram to plan, schedule, monitor, and control the project.
Task Network
Task network, also known as activity network, is a graphical representation of the
flow of tasks in a project. With the help of task network, the sequence and
dependency of tasks are determined. The tasks are divided according to the project.
Once the tasks are identified, the task dependency chart is prepared. After this,
the critical path of the project is determined. Table 5.2 lists the dependencies of
tasks in the CPM diagram, shown in Figure 5.2.
Table 5.2 Task Duration

Task Duration (in weeks) Dependency

A 3 None
B 4 None
C 1 A
D 2 A
E 2 B
F 3 C
To depict the hierarchy of tasks involved in the project, work breakdown
structure is used which provides information about the tasks along with their sub-
tasks.
Self-Instructional
104 Material
Work Breakdown Structure (WBS) Project Scheduling

Work breakdown structure is the process of dividing the project into tasks and
logically ordering them in a sequence according to their related tasks. It provides
a framework for keeping track of the progress of the project and for determining NOTES
the cost planned for these tasks. By comparing the planned costs and the actual
cost (cost that has been expended), the additional cost required can be controlled.
WBS specifies only the tasks that are to be performed and not the process
by which the tasks are completed. It also does not specify the individuals performing
that task. This is because WBS is based on requirements and not on the way in
which the tasks are carried out.
To break the tasks involved in a project, the following steps are used:
1. Break the project into general tasks: The project can be divided
into general tasks, such as analysis, design, testing, and so on.
2. Break the general tasks into smaller individual tasks: When the
general tasks are determined, they can further be divided into sub-
tasks. Design, for example, can further be divided into interface design,
modular design, and so on.
Figure 5.6 shows a work breakdown structure. Here, the project summary
is divided into three tasks, namely design phase, programming phase and testing
phase. Also, each task contains several sub-tasks. The design phase, for example,
is further divided into two sub-tasks, namely first design phase and second design
phase. Note that in the figure each task is numbered to indicate the sequence of
tasks and sub-tasks. It also indicates the time taken and the cost involved to
complete these tasks and sub-tasks.

Fig. 5.6 Work Breakdown Structure

Note: The completion of each task is indicated with the help of a milestone.

Self-Instructional
Material 105
Project Scheduling Tracking the Schedule
As the project progresses, the project manager understands the activities to be
completed and milestones to be tracked and controlled with the help of project
NOTES schedule. Tracking of project schedule is done in several ways.
 Conducting periodic meetings with team members: By conducting
periodic meetings, the project manager is able to distinguish between
completed and uncompleted activities or those that are yet to start. In
addition, the project manager considers the problems in the project as
reported by the team members.
 Assessing the results of reviews: Software reviews are conducted when
one or more activities of the project are complete or when a particular
development phase is complete. The purpose of conducting reviews is to
check whether the software is developed according to user requirements
or not.
 Determining the milestones: Milestones indicating the expected output
are described. These milestones check the status of a project by comparing
the progress of activities with the estimated end date of the project.
 Using earned value analysis to determine the progress of the project:
The progress of the project is determined quantitatively by the earned value
analysis technique. This technique provides an estimate for every task without
considering its type and the total hours required to accomplish the project.
Based on this estimation, each activity is given an earned value, which is a
measure of progress and describes the percentage of the activities that have
been completed.

Check Your Progress

1. What is project scheduling?
2. Explain the term milestones.
3. Give the definition of Gantt chart.
4. Write the advantage of critical path method.
5. Define the term work breakdown structure.

5.3 AUTOMATED TOOLS

Engineers can now have numerical control over automated devices. The result
has been a rapidly expanding range of applications and human activities. Computer-
aided technologies (or CAx) now serve as the basis for mathematical and
organizational tools used to create complex systems. Notable examples of CAx
include Computer-Aided Design (CAD software) and Computer-Aided
Self-Instructional
106 Material
Manufacturing (CAM software). The improved design, analysis, and manufacture Project Scheduling

of products enabled by CAx has been beneficial for industry.

Information technology, together with industrial machinery and processes,
can assist in the design, implementation, and monitoring of control systems. One
NOTES
example of an industrial control system is a Programmable Logic Controller (PLC).
PLCs are specialized hardened computers which are frequently used to synchronize
the flow of inputs from (physical) sensors and events with the flow of outputs to
actuators and events.
Human-Machine Interfaces (HMI) or Computer Human Interfaces (CHI),
formerly known as man-machine interfaces, are usually employed to communicate
with PLCs and other computers. Service personnel who monitor and control through
HMIs can be called by different names. In the industrial process and manufacturing
environments, they are called operators or something similar. In boiler houses and
central utility departments, they are called stationary engineers.
Different types of automation tools exist:
1. Artificial Neural Network (ANN) -Artificial Neural
Networks (ANNs), usually simply called Neural Networks (NNs),
are computing systems vaguely inspired by the biological neural
networks that constitute animal brains. An ANN is based on a collection
of connected units or nodes called artificial neurons, which loosely
model the neurons in a biological brain. Each connection, like
the synapses in a biological brain, can transmit a signal to other neurons.
An artificial neuron that receives a signal then processes it and can
signal neurons connected to it. The ‘Signal’ at a connection is a real
number, and the output of each neuron is computed by some non-
linear function of the sum of its inputs. The connections are called edges.
Neurons and edges typically have a weight that adjusts as learning
proceeds. The weight increases or decreases the strength of the signal
at a connection. Neurons may have a threshold such that a signal is
sent only if the aggregate signal crosses that threshold. Typically,
neurons are aggregated into layers. Different layers may perform
different transformations on their inputs. Signals travel from the first
layer (the input layer), to the last layer (the output layer), possibly
after traversing the layers multiple times.
2. Distributed Control System (DSS) -A Distributed Control
System (DCS) is a computerised control system for a process or plant
usually with many control loops, in which autonomous controllers are
distributed throughout the system, but there is no central operator
supervisory control. This is in contrast to systems that use centralized
controllers; either discrete controllers located at a central control room
or within a central computer. The DCS concept increases reliability

Self-Instructional
Material 107
Project Scheduling and reduces installation costs by localising control functions near the
process plant, with remote monitoring and supervision. Distributed
control systems first emerged in large, high value, safety critical process
industries, and were attractive because the DCS manufacturer would
NOTES supply both the local control level and central supervisory equipment
as an integrated package, thus reducing design integration risk. Today
the functionality of SCADA and DCS systems are very similar, but
DCS tends to be used on large continuous process plants where high
reliability and security is important, and the control room is not
geographically remote.
3. Human Machine Interface (HMI) -In the industrial design field
of human–computer interaction, a User Interface (UI) is the space
where interactions between humans and machines occur. The goal of
this interaction is to allow effective operation and control of the machine
from the human end, whilst the machine simultaneously feeds back
information that aids the operators’ decision-making process.
Examples of this broad concept of user interfaces include the interactive
aspects of computer operating systems, hand tools, heavy
machinery operator controls, and process controls. The design
considerations applicable when creating user interfaces are related
to, or involve such disciplines as, ergonomics and psychology.
Generally, the goal of user interface design is to produce a user interface
which makes it easy, efficient, and enjoyable (user-friendly) to operate
a machine in the way which produces the desired result (i.e.,
maximum usability). This generally means that the operator needs to
provide minimal input to achieve the desired output, and also that the
machine minimizes undesired outputs to the user.
4. Robotic Process Automation (RPA) -Robotic Process
Automation (or RPA) is a form of business process
automation technology based on metaphorical software robots (bots)
or on Artificial Intelligence (AI)/digital workers. It is sometimes
referred to as software robotics (not to be confused with robot
software).
In traditional workflow automation tools, a software
developer produces a list of actions to automate a task and interface
to the back-end system using internal Application Programming
Interfaces (APIs) or dedicated scripting language. In contrast, RPA
systems develop the action list by watching the user perform that task
in the application’s Graphical User Interface (GUI), and then perform
the automation by repeating those tasks directly in the GUI. This can
lower the barrier to use of automation in products that might not
otherwise feature APIs for this purpose.
Self-Instructional
108 Material
5. Supervisory Control and Data Acquisition (SCADA)-Supervisory Project Scheduling

Control and Data Acquisition (SCADA) is a control

system architecture comprising computers, networked data
communications and Graphical User Interfaces (GUI) for high-
level process supervisory management, while also comprising NOTES
other peripheral devices like Programmable Logic Controllers (PLC)
and discrete Proportional-Integral-Derivative (PID) controllers to
interface with process plant or machinery. The use of SCADA has
been considered also for management and operations of project-
driven-process in construction.
6. Programmable Logic Controller (PLC)-A Programmable Logic
Controller (PLC) or programmable controller is an industrial digital
computer that has been ruggedized and adapted for the control of
manufacturing processes, such as assembly lines, robotic devices, or
any activity that requires high reliability, ease of programming, and
process fault diagnosis.
PLCs can range from small modular devices with tens of Inputs and
Outputs (I/O), in a housing integral with the processor, to large rack-
mounted modular devices with thousands of I/O, and which are often
networked to other PLC and SCADA systems. They can be designed
for many arrangements of digital and analog I/O, extended temperature
ranges, immunity to electrical noise, and resistance to vibration and
impact. Programs to control machine operation are typically stored in
battery-backed-up or non-volatile memory.
PLCs were first developed in the automobile manufacturing industry
to provide flexible, rugged and easily programmable controllers to
replace hard-wired relay logic systems. Since then, they have been
widely adopted as high-reliability automation controllers suitable for
harsh environments.
7. Instrumentation-Instrumentation is a collective term for measuring
instruments that are used for indicating, measuring and recording
physical quantities. The term has its origins in the art and science
of scientific instrument-making.
Instrumentation can refer to devices as simple as direct-
reading thermometers, or as complex as multi-sensor components
of industrial control systems. Today, instruments can be found in
laboratories, refineries, factories and vehicles, as well as in everyday
household use (e.g., smoke detectors and thermostats).
8. Motion Control-Motion control is a sub-field of automation,
encompassing the systems or sub-systems involved in moving parts of
machines in a controlled manner. Motion control systems are

Self-Instructional
Material 109
Project Scheduling extensively used in a variety of fields for automation purposes,
including precision engineering, micro manufacturing, biotechnology,
and nanotechnology. The main components involved typically include
a motion controller, an energy amplifier, and one or more prime
NOTES movers or actuators. Motion control may be open loop or closed
loop. In open loop systems, the controller sends a command through
the amplifier to the prime mover or actuator, and does not know if the
desired motion was actually achieved.
9. Robotics-Robotics is an interdisciplinary field that integrates computer
science and engineering. Robotics involves design, construction,
operation, and use of robots. The goal of robotics is to design machines
that can help and assist humans. Robotics integrates fields
of mechanical engineering, electrical engineering, information
engineering, mechatronics, electronics, bioengineering, computer
engineering, control engineering, software engineering, among others.
Robotics develops machines that can substitute for humans and
replicate human actions. Robots can be used in many situations and
for many purposes, but today many are used in dangerous environments
(including inspection of radioactive materials, bomb
detection and deactivation), manufacturing processes, or where
humans cannot survive (e.g., in space, underwater, in high heat, and
clean up and containment of hazardous materials and radiation).
Robots can take on any form but some are made to resemble humans
in appearance. This is said to help in the acceptance of a robot in
certain replicative behaviors usually performed by people. Such robots
attempt to replicate walking, lifting, speech, cognition, or any other
human activity. Many of today’s robots are inspired by nature,
contributing to the field of bio-inspired robotics.
10. Host Simulation Software (HSS): It is a commonly used testing
tool that is used to test the equipment software. HSS is used to test
equipment performance concerning factory automation standards
(timeouts, response time, and processing time).

Check Your Progress

6. Define the term artificial neural network.
7. What is Distributed Control System (DCS)?
8. Explain the term motion control.

Self-Instructional
110 Material
 Project Scheduling
5.4 ANSWERS TO CHECK YOUR PROGRESS
QUESTIONS

1. Project scheduling essential to project perform scheduling to effectively NOTES

manage the tasks of the project. Project scheduling provides details, such
as start date and end date of the project, milestones and tasks for the project.
In addition, it specifies the resource, (such as people, equipment and facilities)
required to complete the project on each other. An appropriate project
schedule prepared according to project plain not only aims to complete the
project on time but also helps t avoid the additional cost incurred when the
project is delayed.
2. Milestones are formal representation of the progress of a project. Generally
milestones are planed when deliverables are provided. Milestones describe
the end point when software process activity is completed. After the
completion of milestone, its output describe in the form of a document. This
document comprises information about the completion of a phase of the
project.
3. A Gantt chart is a graphical representation of the project. It is used in project
scheduling to depict the activities of the project. This chart shows the start
and end dates of each activity in the project. In addition, it shows the week,
month, or quarter required to complete each activity is known as Gantt
chart.
4. The advantage of critical path method are as following-
 It represented the project in graphical form.
 It predicts the time required to complete the project.
 It specifies the critical activities.
 It specifies how to speed up the project so that it is completed on
schedule.
 It specifies the optimal plan for speeding up the project.
5. Work breakdown structure is the process of dividing the project into tasks
and logically ordering them in a sequence according to their related tasks. It
provides a framework for keeping track of the progress of the project and
for determining the cost planned for these tasks. By comparing the planned
costs and the actual cost (cost that has been expended), the additional cost
required can be controlled.
6. Artificial Neural Networks (ANNs), usually simply called Neural
Networks (NNs), are computing systems vaguely inspired by the biological
neural networks that constitute animal brains. An ANN is based on a
collection of connected units or nodes called artificial neurons.

Self-Instructional
Material 111
Project Scheduling 7. A Distributed Control System (DCS) is a computerised control system for
a process or plant usually with many control loops, in which autonomous
controllers are distributed throughout the system, but there is no central
operator supervisory control.
NOTES
8. Motion control is a sub-field of automation, encompassing the systems or
sub-systems involved in moving parts of machines in a controlled manner.
Motion control systems are extensively used in a variety of fields for
automation purposes, including precision engineering, micro
manufacturing, biotechnology, and nanotechnology.

5.5 SUMMARY

 Project planning is an organized and integrated management process, which

focuses on activities required for successful completion of the project.
 Several individuals help in planning the project. These include senior
management and project management team. Senior management is
responsible for employing team members and providing resources required
for the project.
 The project management team, which generally includes project managers
and developers, is responsible for planning, determining, and tracking the
activities of the project.
 Planning should be done before a project begins. For effective planning,
objectives and schedules should be clear and understandable.
 A software project is carried out to accomplish a specific purpose, which is
classified into two categories, namely, project objectives and business
objectives.
 A project plan provides information about the resources that are available
for the project, individuals involved in the project, and the schedule according
to which the project is to be carried out.
 Work breakdown structure is the process of dividing the project into tasks
and logically ordering then in a sequence according to their related tasks. It
provides a framework for keeping track of the progress of the project and
for determining the cost planned for these tasks. By comparing the planned
costs and the actual cost (cost that has been expended), the additional cost
required can be controlled.
 A project plan helps a project manager to understand, monitor, and control
the development of software project. This plan is used as a means of
communication between the users and project management team.
 The verification and validation plan describes the approach, resources and
schedule used for system validation.
Self-Instructional
112 Material
 The configuration management plan defines the process, which is used for Project Scheduling

making changes to the project scope. Generally, the configuration

management plan is concerned with redefining the existing objectives of the
project and deliverables (software products that are delivered to the user
after completion of software development). NOTES
 The maintenance plan specifies the resources and processes required for
making the software operational after its installation. Sometimes, the project
management team (or software development team) does not carry out the
task of maintenance. In such a case, a separate team known as software
maintenance team performs the task of software maintenance.
 The staffing plan describes the number of individuals required for a project.
It includes selecting and assigning tasks to the project management team
members.
 The staffing plan provides information about appropriate skills required to
perform the tasks to produce the project deliverables and manage the
project. In addition, it provides information of resources, such as tools,
equipment, and processes used by the project management team.
 The ability of managing projects successfully greatly depends upon the right
understanding of the phases and activities that create the project life-cycle.
 Activity-Based Planning is used when projects are possible to plan before
launch (goals and methods are well defined at the very beginning). This
approach is best for engineering and construction projects.
 Milestone-Based Planning is used in projects in which milestones (special
progress flags that show project performance and deliverable status)
represent the completion of life-cycle. It is best fitted to product development
and software projects.
 Project life-cycle template we describe the key phases by activities to be
undertaken by project manager in collaboration with the senior stakeholders
and experts.
 Engineers can now have numerical control over automated devices. The
result has been a rapidly expanding range of applications and human
activities. Computer-Aided technologies (or CAx) now serve as the basis
for mathematical and organizational tools used to create complex systems.
 Artificial Neural Networks (ANNs), usually simply called Neural
Networks (NNs), are computing systems vaguely inspired by the biological
neural networks that constitute animal brains. An ANN is based on a
collection of connected units or nodes called artificial neurons.
 A Distributed Control System (DCS) is a computerised control system for
a process or plant usually with many control loops, in which autonomous
controllers are distributed throughout the system, but there is no central
operator supervisory control.
Self-Instructional
Material 113
Project Scheduling  Robotic Process Automation (or RPA) is a form of business process
automation technology based on metaphorical software robots (bots) or
on Artificial Intelligence (AI)/digital workers. It is sometimes referred to
as software robotics (not to be confused with robot software).
NOTES
 A Programmable Logic Controller (PLC) or programmable controller is an
industrial digital computer that has been ruggedized and adapted for the
control of manufacturing processes, such as assembly lines, robotic devices,
or any activity that requires high reliability, ease of programming, and process
fault diagnosis.
 Instrumentation is a collective term for measuring instruments that are used
for indicating, measuring and recording physical quantities.
 Robotics is an interdisciplinary field that integrates computer
science and engineering. Robotics involves design, construction, operation,
and use of robots. The goal of robotics is to design machines that can help
and assist humans.

5.6 KEY WORDS

 Project planning: Project planning is an organized and integrated

management process.
 Risk analysis: Before starting the project, senior management and the
project management team should consider the risks that may affect the
project.
 Work breakdown structure: The process of diving a project into tasks
and logically ordering them in a sequence according to their related.
 Verification and validation plan: It describes the approach, resources
and schedule used for system validation.
 Project staffing: The process o searching, evaluating and establishing a
working relationship amongst the personnel involved in a project.
 Instrumentation-Instrumentation is a collective term for measuring
instruments that are used for indicating, measuring and recording physical
quantities.
 Host Simulation Software (HSS): It is a commonly used testing tool that
is used to test the equipment software.

Self-Instructional
114 Material
 Project Scheduling
5.7 SELF ASSESSMENT QUESTIONS AND
EXERCISES

Short-Answer Questions NOTES

1. Write the various factors of project scheduling.

2. Explain the techniques of project scheduling.
3. Write the advantage of Gantt chart.
4. What is Critical Path Method (CPM).
5. Define the term task network.
6. Write the schedule of tracking.
7. Give the definition of automated tools.
Long-Answer Questions
1. Briefly explain the principles of project scheduling giving appropriate
examples.
2. Discuss about the milestones with the help of diagram.
3. Describe the Gantt chart with the help of diagram.
4. Briefly explain the Program Evolution and Review Technique (PERT) chart
giving appropriate examples.
5. Describe briefly the Critical Path Method (CPM) with the help of diagram.
6. Briefly in details automated tools giving appropriate examples.

5.8 FURTHER READINGS

Hughes, Bob, Mike Cotterell and Rajib Mall. 2017. Software Project
Management (SIE), 6th Edition. New York: McGraw Hill Education.
Schach, Stephen R. 2005. Object Oriented and Classical Software Engineering.
New Delhi: Tata McGraw-Hill.
Pressman, Roger S. 1997. Software Engineering, a Practitioner’s Approach.
New Delhi: Tata McGraw-Hill.
Somerville, Ian. 2001. Software Engineering. New Delhi: Pearson Education.
Ghezzi, Carlo, Mehdi Jazayeri, and Dino Mandriolli. 1991. Fundamentals of
Software Engineering. New Delhi: Prentice-Hill of India.
Jawadekar, Waman S. 2004. Software Engineering: Principles and Practice.
New Delhi: Tata McGraw-Hill.
Jalote, Pankaj. 1991. An Integrated Approach to Software Engineering. New
Delhi: Narosa Publishing House.
Self-Instructional
Material 115
Project Monitoring and
Controlling
UNIT 6 PROJECT MONITORING
AND CONTROLLING
NOTES
Structure
6.0 Introduction
6.1 Objectives
6.2 Project Status Reporting
6.3 Project Metrics
6.4 Earned Value Analysis (EVA)
6.5 Project Communication Plan and Techniques
6.5.1 Project Communication Techniques
6.6 Steps For Process Improvement
6.7 Answers to Check Your Progress Questions
6.8 Summary
6.9 Key Words
6.10 Self Assessment Questions and Exercises
6.11 Further Readings

6.0 INTRODUCTION

A project status report is a document that summarizes a project’s overall progress

against the projected project plan. The goal of a project status report is to keep all
stakeholders informed of progress, to mitigate issues before they arise, and to ensure
that the project will land within the designated time frame. A project status report
helps to improve communication across an organization, as everyone is kept in the
loop on how the project is progressing. Project metrics enable the project managers
to assess current project, task potential risks, identify problem areas, adjust workflow
and evaluate the project team’s ability to control the quality of work products.
A project communication plan is an agreement between collaborators and
stakeholders that outlines what, when, and how information will be shared at key
intervals. Information like status updates, task-related questions, and meeting details
should all be included in this written guide. The goal is to define and streamline
team communications as much as possible. A project communication plan enables
project managers to monitor and manage communication with clients, team
members, and other project stakeholders. It serves as the standard operating
procedure for project communications and lays down in detail that’s responsible
for which type of communication, who needs to be looped in, and how the
information will be shared.
Process improvement involves the business practice of identifying, analyzing
and improving existing business processes to optimize performance, meet best
practice standards or simply improve quality and the user experience for customers
Self-Instructional
and end-users.
116 Material
 In this unit, you will study about the project status reporting, project metrics, Project Monitoring and
Controlling
Earned Value Analysis (EVS), project communication plan and techniques, and
steps for process improvement.

NOTES
6.1 OBJECTIVES

After going through this unit, you will be able to:

 Define the project status reporting
 Understand the basics of project metrics
 Elucidate on the Earned Value Analysis (EVS)
 Discuss about the project communication plan and techniques
 Explain the steps for process improvement

6.2 PROJECT STATUS REPORTING

A project status report is a document that summarizes a project’s overall progress

against the projected project plan. The goal of a project status report is to keep all
stakeholders informed of progress, to mitigate issues before they arise, and to
ensure that the project will land within the designated time frame.
A project status report helps to improve communication across an
organization, as everyone is kept in the loop on how the project is progressing. It
also helps to simplify the communication process with a single, formalized report
that everyone can refer to stay up to date.
Additionally, a project status report improves the organizational support for
your project by maintaining tight communication among team members to ensure
all goals and objectives are met.
The Purpose of Project Status Reports
One of the many benefits of using a project status report is that it forces an
organization to agree to certain project milestones and measures of progress at
the very beginning of that project. A project manager gathers those important
criteria and creates a project status report that will prove useful to everyone who
needs to see it.
Project status reports also facilitate the following:
 Create and enable buy-in from stakeholders.
 Provide transparency into the progress toward milestones.
 Help identify issues and risks, so course correction can happen quickly.
 Pinpoint the progress of work done by individuals, teams, and resources,
so you can rotate out and bring in staff in a timely manner. For example,
Self-Instructional
Material 117
Project Monitoring and UX designers start early in a web design project by mapping out the site
Controlling
architecture and wireframes. The work of copywriters and designers
follows, and so on.
 Provide a high-level gauge of project health.
NOTES
 Prevent unpleasant surprises (to team members, clients, and
stakeholders).
 Furnish a method for keeping project members and leaders accountable.
 Provide a paper trail.
 Prevent scope creep.
 Present the right information to the intended audiences.

6.3 PROJECT METRICS

Project metrics enable the project managers to assess current projects, track
potential risks, identify problem areas, adjust workflow and evaluate the project
team’s ability to control the quality of work products. Note that project metrics
are used for tactical purposes rather than strategic purposes used by the process
metrics.
Project metrics serve two purposes. One, they help to minimize the
development schedule by making necessary adjustments in order to avoid delays
and alleviate potential risks and problems. Two, these metrics are used to assess
the product quality on a regular basis and modify the technical issues if required.
As the quality of the project improves, the number of errors and defects are
reduced, which in turn leads to a decrease in the overall cost of a software project.
Applying Project Metrics
Often, the first application of project metrics occurs during estimation. Here, metrics
collected from previous projects act as a base from which effort and time estimates
for the current project are calculated. As the project proceeds, original estimates
of effort and time are compared with the new measures of effort and time. This
comparison helps the project manager to monitor (supervise) and control the
progress of the project.
As the process of development proceeds, project metrics are used to track
the errors detected during each development phase. For example, as software
evolves from design to coding, project metrics are collected to assess quality of
the design and obtain indicators that in turn affect the approach chosen for coding
and testing. Also, project metrics are used to measure production rate, which is
measured in terms of models developed, function points, and delivered lines of
code.

Self-Instructional
118 Material
 Project Monitoring and
6.4 EARNED VALUE ANALYSIS (EVA) Controlling

We give equal treatment for monitoring the project progress for all aspects and
components of a project. But when monitoring a project, all the components have NOTES
different priority levels.
The following is the list of priorities:
 Critical path activities: The activities on the critical path are very crucial.
Any delay of these activities cause a delay in the completion date for the
project. So, the activities on the critical path should have been given high
priorities for close monitoring.
 Activities with no free float: A delay in any activity with no free float
will delay at least some subsequent activities. If the delay is less than the
total float, it might not delay the project completion date. All such delays
have serious effects on our resource schedule.
 Activities with less than a specified float: We should monitor closely
those activities that has less than one week float.
 High risk activities: In the initial risk profiling exercise the set of high-
risk activities should have been identified. These activities are to be given
close attention because they are most likely to overrun or overspend.
 Activities using critical resources: There are some activities that are
critical because they are very expensive. Staff or other resources might
be available only for a limited period. Such activities require a high degree
of attention.

Check Your Progress

1. What is project status report?
2. Write the two purposes of project metrics.
3. Write the three basic parameters of EVA.

6.5 PROJECT COMMUNICATION PLAN AND

TECHNIQUES

A project communication plan is an agreement between collaborators and

stakeholders that outlines what, when, and how information will be shared at key
intervals. Information like status updates, task-related questions, and meeting details
should all be included in this written guide. The goal is to define and streamline
team communications as much as possible.
A project communication plan enables project managers to monitor and
manage communication with clients, team members, and other project stakeholders.
It serves as the standard operating procedure for project communications and
Self-Instructional
Material 119
Project Monitoring and lays down in detail that’s responsible for which type of communication, who needs
Controlling
to be looped in, and how the information will be shared. Done right, it keeps
everyone updated and nips rumors or misconceptions in the bud, before they
become harmful enough to cause confusion, conflict, or project derailment.
NOTES
A communication management plan is usually created at the start of a project,
during the project planning phase. Depending on the project, communication plans
can either be simple or complex. Some projects may even need to appoint a
public relations person to communicate updates and events to society at large.
Benefits of a Good Project Communication Plan
 The benefits of a good project communication plan include staying in line with
budget, timeline, and scope expectations, to name a few. The right strategy
can solve most major communication breakdowns before they even happen.
 Having a plan upfront makes it easier to focus on task completion instead
of forgetting who said what at the last meeting or having to sift through
dozens of email chains for the latest update.
 An effective project communication plan also saves you the effort of having
to answer individual ‘what’s the status” emails. When there is a plan to
ensure that all stakeholders are kept appropriately informed, your project
team can respond to change, manage clients, and maintain a good standard
of communication.
How to Write a Project Communication Plan
A communication plan can either be a simple overview or a more detailed plan. In
many cases, the overview is sufficient for small, simple projects. For complex
projects, more detail may be needed.
Below are the general steps to follow when developing a project
communication plan.
Step 1: Determine the Team’s Communication Needs
Different projects require different communication plans. Ask yourself, what does
this specific project need to succeed?
For example, a project in a highly regulated market may require someone
from the team to regularly communicate with a regulating body. On the other
hand, updating content on a company’s website may require input from customers
and material from contractors such as photographers and graphic designers.
Tips for Identifying Communication Needs
 Know What’s Involved Throughout the Project’s Life Cycle: Consider
all the tasks, activities, and resources needed from start to finish. From
there, you’ll be able to identify the project stakeholders you need to
communicate with.
Self-Instructional
120 Material
  Get Input from All Stakeholder Groups: Know their preferred Project Monitoring and
Controlling
communication channels or methods, how frequently they expect to receive
updates, etc.
Step 2: Define the Purpose of the Communication NOTES
There has to be a purpose behind each communication event. If you’re calling a
quick huddle just because, chances are you’re disrupting people’s ability to complete
tasks.
Tips for Defining Why You are Communicating
 Identify What Needs to be Achieved: This can be anything, but in general,
every communication item should update or educate stakeholders — and,
in some cases, obtain feedback. A virtual meeting prior to starting a project
may be ‘To discuss the project, answer any questions, establish rapport
among stakeholders, and obtain their support for the project.’
 Outline Meeting or Report Agendas: A basic outline can ensure meetings
are productive and don’t veer off course.
Step 3: Choose How to Communicate
The communication plan also determines which communication methods or styles
to use for certain communication items.
Tips for Choosing How to Communicate
 Keep Team Members in the Loop without Impacting
Productivity: For example, you don’t want to schedule a daily meeting or
stand-up presentation for updates that can be communicated via email or
the team’s virtual discussion board.
 Pick the Best Method for the Audience Type: Certain stakeholders,
such as the project sponsor, may prefer phone or video conference calls
over email or other communication styles.
 Certain Situations Call for Certain Communication Styles: When
delivering job performance feedback, a one-on-one, in-person meeting
works best. When celebrating milestones or conducting project post-mortem
analyses, a group meeting is appropriate. If your team is geographically
dispersed or includes team members who are constantly on the go, a cloud-
based communication system that works on any device is a necessity.
Step 4: Determine How Frequently to Communicate
Not enough communication is bad for projects, as is too much communication.
Case in point, if you send too many emails, people may overlook critical updates
because of a clogged inbox or too frequent irrelevant communications.

Self-Instructional
Material 121
Project Monitoring and Tips for determining communication frequency
Controlling
 The Goal is to Keep Everyone Updated: Monday emails recapping what
has been completed so far are okay, so are weekly status reports carried
NOTES out via a video conference call. The point is there are different ways to
establish a feedback loop and get everyone on the same page, so consider
what works best for your team.
 Consider Stakeholder Preference: The project sponsor may want to
receive daily updates, while the client may want weekly reports.
Step 5: Assign Communication Owners and Audiences
The project manager is normally responsible for relaying information — downwards
to team members, upwards to executives and senior management, and all around
to other project stakeholders. Some communication events, however, may have
to be delegated.
Tips for assigning communication owners:
 Clarify Who is Responsible for Which Communication Event: Doing
so establishes accountability and makes sure owners have ample time to
prepare.
 Identify the Audience for Each Communication Type: Send the right
message to the right audience, and no more. This is so you don’t bog people
down with unrelated and unnecessary information.
6.5.1 Project Communication Techniques
Let us look at some of the communication techniques that a project manager such
as Sally can employ.
 Different Information for Different Stakeholders - The client is probably
interested in learning about any delays, risks, issues, what percentage of the
project is complete, and some of the financial information. The team members
may require more information on the status of the project, such as the tasks
assigned and the percentage of tasks complete, the overall scope, any
changes to the project features, and so on.
In our example, Sally provides a simple status report and includes an
appendix with more detailed information.
 Project Health Indication - In some instances the project team and clients
are interested in learning about the health of the project. The health of the
project may include things like whether the project is on schedule and
on budget.
In our example Sally indicates the project health to be green due to the fact
that the schedule and budget are on track. If the project was slightly behind
track she would have indicated yellow, and if it was way behind then she
Self-Instructional would have indicated it as red.
122 Material
 Project Monitoring and
6.6 STEPS FOR PROCESS IMPROVEMENT Controlling

Process improvement involves the business practice of identifying, analyzing and

improving existing business processes to optimize performance, meet best practice NOTES
standards or simply improve quality and the user experience for customers and
end-users.
Process improvement can have several different names, such as Business
Process Management (BPM), Business Process Improvement (BPI), business
process re-engineering, Continual Improvement Process (CIP), to name a few.
Regardless of the nomenclature, they all pursue the same goal: to minimize errors,
reduce waste, improve productivity and streamline efficiency.
Five Stages of Process Improvement
1. Visualise-Karen Martin, author of The Outstanding Organization, has said
that ‘The ability to visualize non-visible work is an essential first step in
gaining clarity about and consensus around how work gets done.’ Mapping
out business processes, whether via value stream maps or detailed process
maps, is an important first step when planning to make process
improvements.
Key managers and experienced users of a process should be interviewed
to develop the maps and identify any known problem areas in the current
process. Ideally, this will be done in the work area to get the most accurate
picture of what tasks are performed. Use the questioning method of Why,
What, Where, Who and When. Key Performance Indicators, Policies and
Procedures that relate to that process should also be recorded.
2. Analyse- Analysing the processes for opportunities requires an
understanding of the concept that only a fraction of business activities usually
add value to the customer and the rest can be considered waste. Easy
improvements can be found when we seek to eliminate the unnecessary
steps in the process. Examples of waste could be activities that consume
time or resources but do not add any value to the customer. Consider
whether activities provide what the customer actually wants, whether they
change the product or service offered to the customer, and whether they
are required by law or regulatory bodies.
3. Evaluate- Evaluate the different solutions available for opportunities
identified during the Analyse stage. Solutions might be: (i) automation of a
manual task, (ii) a redesign of a business process that will improve efficiency
through better utilisation of ERP functionality, or even, (iii) process
transformation that affects how the company does business, for example by
utilising industry best-practice functionality supported by the ERP system.
4. Measure- Once solutions to improve business processes have been
identified, they can be assigned measurements in accordance with the Self-Instructional
Material 123
Project Monitoring and business benefit. According to H. James Harrington, leading adviser in
Controlling
performance improvement, ‘Measurement is the first step that leads to
control and eventually to improvement. If you cannot measure something,
you cannot understand it. If you cannot understand it, you cannot control it.
NOTES If you cannot control it, you cannot improve it.’
Improvements can be ranked on the basis of business benefit, impact of
existing risks and the costs of implementing the change. This will support
the business in deciding which improvements to implement.
5. Implement- Implementation of process improvements should be
approached like any other ERP change management project with Initiate,
Design, Configure, Test, Deploy and Cut Over phases. It is essential that
any process improvements implemented have a plan to evaluate the
effectiveness of the change after Go Live.

Fig 6.1 Stages for Process Implementation

Check Your Progress

4. What is project communication plan?
5. Explain the term process improvement.

6.7 ANSWERS TO CHECK YOUR PROGRESS

QUESTIONS

1. A project status report is a document that summarizes a project’s overall

progress against the projected project plan. The goal of a project status
report is to keep all stakeholders informed of progress, to mitigate issues
before they arise, and to ensure that the project will land within the designated
time frame.
2. Project metrics serve two purposes. One, they help to minimize the
development schedule by making necessary adjustments in order to avoid
delays and alleviate potential risks and problems. Two, these metrics are
used to assess the product quality on a regular basis and modify the technical
issues if required. As the quality of the project improves, the number of
errors and defects are reduced, which in turn leads to a decrease in the
overall cost of a software project.
Self-Instructional
124 Material
 3. Three basic parameters are taken into consideration during EVA- Project Monitoring and
Controlling
 The value of work which should have been accomplished to date.
 The value realized till date.
 The total expenditure till date. NOTES
4. A project communication plan is an agreement between collaborators and
stakeholders that outlines what, when, and how information will be shared
at key intervals. Information like status updates, task-related questions, and
meeting details should all be included in this written guide. The goal is to
define and streamline team communications as much as possible.
5. Process improvement involves the business practice of identifying, analyzing
and improving existing business processes to optimize performance, meet
best practice standards or simply improve quality and the user experience
for customers and end-users.

6.8 SUMMARY

 A project status report is a document that summarizes a project’s overall

progress against the projected project plan.
 The goal of a project status report is to keep all stakeholders informed of
progress, to mitigate issues before they arise, and to ensure that the project
will land within the designated time frame.
 A project status report helps to improve communication across an
organization, as everyone is kept in the loop on how the project is progressing.
It also helps to simplify the communication process with a single, formalized
report that everyone can refer to stay up to date.
 One of the many benefits of using a project status report is that it forces an
organization to agree to certain project milestones and measures of progress
at the very beginning of that project.
 Project metrics enable the project managers to assess current project, track
potential risks, identify problems areas, adjust workflow and evaluate the
project team’s ability to control the quality of work product.
 Project metrics serve two purposes. One, they help to minimize the
development schedule by making necessary adjustments in order to avoid
delays and alleviate potential risks and problems. Two, these metrics are
used to assess the product quality on a regular basis and modify the technical
issues if required.
 Earned Value Analysis (EVA) is based on assigning a value to each task or
work package based on the original expenditure forecasts. This assigned
value is the original budget cost for the item and is known as the Planned
Value (PV) or Budgeted Cost of Work Schedule (BCWS).
Self-Instructional
Material 125
Project Monitoring and  A project communication plan is an agreement between collaborators and
Controlling
stakeholders that outlines what, when, and how information will be shared
at key intervals. Information like status updates, task-related questions, and
meeting details should all be included in this written guide. The goal is to
NOTES define and streamline team communications as much as possible.
 A project communication plan enables project managers to monitor and
manage communication with clients, team members, and other project
stakeholders.
 A communication management plan is usually created at the start of a project,
during the project planning phase. Depending on the project, communication
plans can either be simple or complex. Some projects may even need to
appoint a public relations person to communicate updates and events to
society at large.
 The benefits of a good project communication plan include staying in line
with budget, timeline, and scope expectations, to name a few. The right
strategy can solve most major communication breakdowns before they even
happen.
 An effective project communication plan also saves you the effort of having
to answer individual ‘What’s the status” emails. When there is a plan to
ensure that all stakeholders are kept appropriately informed, your project
team can respond to change, manage clients, and maintain a good standard
of communication.
 In some instances the project team and clients are interested in learning
about the health of the project. The health of the project may include things
like whether the project is on schedule and on budget.
 Process improvement involves the business practice of identifying, analysing
and improving existing business processes to optimize performance, meet
best practice standards or simply improve quality and the user experience
for customers and end-users.
 Process improvement can have several different names, such as Business
Process Management (BPM), Business Process Improvement (BPI),
business process re-engineering, Continual Improvement Process (CIP),
to name a few. Regardless of the nomenclature, they all pursue the same
goal: to minimize errors, reduce waste, improve productivity and streamline
efficiency.
 Karen Martin, author of The Outstanding Organization, has said that ‘The
ability to visualize non-visible work is an essential first step in gaining clarity
about and consensus around how work gets done.’ Mapping out business
processes, whether via value stream maps or detailed process maps, is an
important first step when planning to make process improvements.

Self-Instructional
126 Material
  Analysing the processes for opportunities requires an understanding of the Project Monitoring and
Controlling
concept that only a fraction of business activities usually add value to the
customer and the rest can be considered waste.
 Once solutions to improve business processes have been identified, they
NOTES
can be assigned measurements in accordance with the business benefit.

6.9 KEY WORDS

 Project status report: A project status report is a document that summarizes

a project’s overall progress against the projected project plan.
 Project metrics: Project metrics enable the project managers to assess
current project.
 Earned Value Analysis (EVA): Earned Value Analysis (EVA) is based on
assigning a value to each task or work package based on the original
expenditure forecasts. This assigned value is the original budget cost for the
item. The total value credited to a project at any point is the earned value.
 Project communication plan: A project communication plan enables
project managers to monitor and manage communication with clients, team
members, and other project stakeholders.
 Process improvement: It involves the business practice of identifying,
analyzing and improving existing business processes to optimize performance,
meet best practice standards or simply improve quality and the user
experience for customers and end-users.

6.10 SELF ASSESSMENT QUESTIONS AND

EXERCISES

Short-Answer Questions
1. Write the goals of project status report.
2. What is the project metrics?
3. Give the definition of planned value.
4. Write the benefits of project communication plan.
5. Give the different names for process improvement.
Long-Answer Questions
1. Briefly explain the purpose project status report giving appropriate examples.
2. How to apply project metrics? Explain with the help of suitable examples.
3. Discuss in briefly Earned Value Analysis (EVA) giving appropriate examples.
Self-Instructional
Material 127
Project Monitoring and 4. How to write a project communication plan with the help of example.
Controlling
5. Briefly explain the project communication techniques.
6. Discuss in details five stages of process improvement with the help of diagram.
NOTES
6.11 FURTHER READINGS

Hughes, Bob, Mike Cotterell and Rajib Mall. 2017. Software Project
Management (SIE), 6th Edition. New York: McGraw Hill Education.
Schach, Stephen R. 2005. Object Oriented and Classical Software Engineering.
New Delhi: Tata McGraw-Hill.
Pressman, Roger S. 1997. Software Engineering, a Practitioner’s Approach.
New Delhi: Tata McGraw-Hill.
Somerville, Ian. 2001. Software Engineering. New Delhi: Pearson Education.
Ghezzi, Carlo, Mehdi Jazayeri, and Dino Mandriolli. 1991. Fundamentals of
Software Engineering. New Delhi: Prentice-Hill of India.
Jawadekar, Waman S. 2004. Software Engineering: Principles and Practice.
New Delhi: Tata McGraw-Hill.
Jalote, Pankaj. 1991. An Integrated Approach to Software Engineering. New
Delhi: Narosa Publishing House.

Self-Instructional
128 Material
 Risk Management

UNIT 7 RISK MANAGEMENT

Structure NOTES
7.0 Introduction
7.1 Objectives
7.2 Concepts of Risks and Risk Management
7.3 Risk Management Activities
7.4 Effective Risk Management
7.5 Risk Categories
7.6 Aids for Risk Identification
7.7 Potential Risk Treatments
7.8 Risk Components and Drivers
7.9 Risk Prioritization
7.10 Answers to Check Your Progress Questions
7.11 Summary
7.12 Key Words
7.13 Self Assessment Questions and Exercises
7.14 Further Readings

7.0 INTRODUCTION

Risk management is the identification, evaluation, and prioritization of risks

coordinated and economical application of resources to minimize, monitor, and
control the probability or impact of unfortunate events or to maximize the realization
of opportunities. Risks can come from various sources including uncertainty
in international markets, threats from project failures (at any phase in design,
development, production, or sustaining of life-cycles), legal liabilities, credit risk,
accidents, natural causes and disasters, deliberate attack from an adversary, or
events of uncertain or unpredictable root-cause. There are two types of events
i.e., negative events can be classified as risks while positive events are classified
as opportunities. Risk management standards have been developed by various
institutions, including the Project Management Institute, the National Institute of
Standards and Technology, actuarial societies, and ISO standards.
Effective risk management means attempting to control, as much as possible,
future outcomes by acting proactively rather than reactively. Therefore, effective risk
management offers the potential to reduce both the possibility of a risk occurring and
its potential impact. In the clinical context, establishing priorities aids in the rationale
and justification for the use of limited resources. Priority setting is influenced by time,
money, and expertise. A risk priority number assessment is one way to establish
priorities that may be difficult to establish in a health care setting.
In this unit, you will study about the concepts of risks and risk management,
risk management activities, effective risk management, risk categories, aids for
risk identification, potential risk treatments, risk components and drivers, and risk
prioritization. Self-Instructional
Material 129
Risk Management
7.1 OBJECTIVES

After going through this unit, you will be able to:

NOTES  Define the concepts of risks and risk management
 Elucidate on the risk management activities
 Understand the basics of effective risk management
 Discuss about the risk categories
 Explain the aids for risk identification
 Analysis the potential risk treatments
 Define the risk components and drivers
 Elaborate on the risk prioritization

7.2 CONCEPTS OF RISKS AND RISK

MANAGEMENT

In simple terms, risk is the possibility of something bad happening. Risk

involves uncertainty about the effects/implications of an activity with respect to
something that humans value (such as, health, well-being, wealth, property or the
environment), often focusing on negative, undesirable consequences. Many different
definitions have been proposed. The international standard definition of risk for
common understanding in different applications is ‘Effect of uncertainty on objectives’.
The understanding of risk, the methods of assessment and management, the
descriptions of risk and even the definitions of risk differ in different practice areas
(business, economics, environment, finance, information technology, health, insurance,
safety, security, etc.). The international standard for risk management, ISO 31000,
provides a common approach to managing any type of risk.
Risk Management
Uncertainty in financial markets, project failures, accidents, credit risks, natural
causes and disasters, legal liabilities as well as deliberate attacks from adversaries
are some of the common factors leading to the development of risks during project
development. There are several risk management standards that have been
developed. Risk Management involves recognizing, evaluating and prioritizing
risks in a project and followed by coordinating and economical application of
resources to minimize, monitor, and control the probability and/or impact of
unfortunate events.
Risks arise from uncertainty in financial markets, project failures, legal
liabilities, credit problems, accidents, natural causes and disasters as well as
deliberate attacks from an adversary. Several risk management standards have
Self-Instructional
130 Material
been developed. The methods, definitions and goals vary widely according to Risk Management

whether the risk management method is in the context of project management,

security, engineering, industrial processes, financial portfolios, actuarial assessments
or public health and safety.
NOTES
For the most part, these methodologies consist of the following elements,
performed, more or less, in the following order.
1. Identify, characterize and assess threats
2. Assess the vulnerability of critical assets to specific threats
3. Determine the risks, such as the expected consequences of specific types
of attacks on specific assets
4. Identify ways to reduce those risks
5. Prioritize risk reduction measures based on a strategy
The strategies to manage risk include transferring the risk to another party,
avoiding the risk, reducing the negative effect of the risk and accepting some or all
of the consequences of a particular risk.
The following steps are involved in establishing the context:
1. Identifying risk in a selected field of interest
2. Planning the remainder of the process
3. Mapping the following:
 The social scope of risk management
 The identity and objectives of stakeholders
 The basis upon which risks will be evaluated
 Constraints
4. Defining a framework for the activity and an agenda for identification
5. Developing an analysis of risks involved in the process
6. Mitigation of risks using available technological, human and organizational
resources
The next step involves source analysis and problem analysis.
 Source analysis: Sources of risk may be either internal or external to the
system. Examples include stakeholders of a project and employees of a
company.
 Problem analysis: Risks are related to identified threats. For example:
the threat of losing money, threat of abuse of privacy information or threat
of accidents and casualties are all risks. Threats may exist with various
entities, such as shareholders, customers and legislative bodies, including
the government. When either the source or the problem is known, the
events that a source may trigger or the events that can lead to a problem
can be investigated. For example: stakeholders withdrawing during a project
may endanger the funding of project or privacy information may be stolen
by employees even within a closed network.

Self-Instructional
Material 131
Risk Management
7.3 RISK MANAGEMENT ACTIVITIES

Risk management consists of three main activities, as shown in Figure 7.1.

NOTES

Fig 7.1 Risk Management Activities

1. Risk Assessment
The objective of risk assessment is to division the risks in the condition of their
loss, causing potential. For risk assessment, first, every risk should be rated in two
methods:
 The possibility of a risk coming true (denoted as r).
 The consequence of the issues relates to that risk (denoted as s).
Based on these two methods, the priority of each risk can be estimated:
p=r*s
Where p is the priority with which the risk must be controlled, r is the
probability of the risk becoming true, and s is the severity of loss caused due to the
risk becoming true. If all identified risks are set up, then the most likely and damaging
risks can be controlled first, and more comprehensive risk abatement methods
can be designed for these risks.
a. Risk Identification: The project organizer needs to anticipate the risk in
the project as early as possible so that the impact of risk can be reduced by
making effective risk management planning.
A project can be of use by a large variety of risk. To identify the significant
risk, this might affect a project. It is necessary to categories into the different
risk of classes.
There are different types of risks which can affect a software project:
 Technology Risks: Risks that assume from the software or hardware
technologies that are used to develop the system.
Self-Instructional
132 Material
  People Risks: Risks that are connected with the person in the Risk Management

development team.
 Organizational Risks: Risks that assume from the organizational
environment where the software is being developed.
NOTES
 Tools Risks: Risks that assume from the software tools and other
support software used to create the system.
 Requirement Risks: Risks that assume from the changes to the
customer requirement and the process of managing the requirements
change.
 Estimation Risks: Risks that assume from the management estimates
of the resources required to build the system
b. Risk Analysis: During the risk analysis process, you have to consider
every identified risk and make a perception of the probability and seriousness
of that risk.
There is no simple way to do this. You have to rely on your perception and
experience of previous projects and the problems that arise in them.
It is not possible to make an exact, the numerical estimate of the probability
and seriousness of each risk. Instead, you should authorize the risk to one
of several bands:
 The probability of the risk might be determined as very low (0-10%),
low (10-25%), moderate (25-50%), high (50-75%) or very high
(+75%).
 The effect of the risk might be determined as catastrophic (threaten the
survival of the plan), serious (would cause significant delays), tolerable
(delays are within allowed contingency), or insignificant.
2. Risk Control
It is the process of managing risks to achieve desired outcomes. After all, the
identified risks of a plan are determined; the project must be made to include the
most harmful and the most likely risks. Different risks need different containment
methods. In fact, most risks need ingenuity on the part of the project manager in
tackling the risk.
Following are the three main methods to plan for risk management:
 Avoid the Risk: This may take several ways such as discussing with
the client to change the requirements to decrease the scope of the work,
giving incentives to the engineers to avoid the risk of human resources
turnover, etc.
 Transfer the Risk: This method involves getting the risky element
developed by a third party, buying insurance cover, etc.

Self-Instructional
Material 133
Risk Management  Risk Reduction: This means planning method to include the loss due
to risk. For instance, if there is a risk that some key personnel might
leave, new recruitment can be planned.
Risk Leverage: To choose between the various methods of handling risk, the
NOTES
project plan must consider the amount of controlling the risk and the corresponding
reduction of risk. For this, the risk leverage of the various risks can be estimated.
Risk leverage is the variation in risk exposure divided by the amount of
reducing the risk.
(Risk Exposure before Reduction - Risk Exposure after Reduction)
Risk Leverage =
(Cost of Reduction)
a. Risk Planning: The risk planning method considers each of the key risks
that have been identified and develop ways to maintain these risks.
For each of the risks, you have to think of the behavior that you may take to
minimize the disruption to the plan if the issue identified in the risk occurs.
You also should think about data that you might need to collect while
monitoring the plan so that issues can be anticipated.
Again, there is no easy process that can be followed for contingency planning.
It rely on the judgment and experience of the project manager.
b. Risk Monitoring: Risk monitoring is the method king that your assumption
about the product, process, and business risks has not changed.

7.4 EFFECTIVE RISK MANAGEMENT

Effective risk management means attempting to control, as much as possible, future

outcomes by acting proactively rather than reactively. Therefore, effective risk
management offers the potential to reduce both the possibility of a risk occurring
and its potential impact.
Risk Analysis Process
Risk analysis is a qualitative problem-solving approach that uses various tools of
assessment to work out and rank risks for the purpose of assessing and resolving
them. Here is the risk analysis process:
1. Identify Existing Risks
Risk identification mainly involves brainstorming. A business gathers its employees
together so that they can review all the various sources of risk. The next step is to
arrange all the identified risks in order of priority. Because it is not possible to
mitigate all existing risks, prioritization ensures that those risks that can affect a
business significantly are dealt with more urgently.

Self-Instructional
134 Material
2. Assess the Risks Risk Management

In many cases, problem resolution involves identifying the problem and then finding
an appropriate solution. However, prior to figuring out how best to handle risks, a
business should locate the cause of the risks by asking the question, “What caused NOTES
such a risk and how could it influence the business?”
3. Develop an Appropriate Response
Once a business entity is set on assessing likely remedies to mitigate identified
risks and prevent their recurrence, it needs to ask the following questions: What
measures can be taken to prevent the identified risk from recurring? In addition,
what is the best thing to do if it does recur?
4. Develop Preventive Mechanisms for Identified Risks
Here, the ideas that were found to be useful in mitigating risks are developed into
a number of tasks and then into contingency plans that can be deployed in the
future. If risks occur, the plans can be put to action.

7.5 RISK CATEGORIES

A software project can be affected by a large variety of risks. It is necessary to

categorize risks into different classes in order to be able to systematically identify
the important risks which might affect a software project. Then it would be
convenient to the project manager to examine which risks from each class are
relevant to the project. The following are the three main categories of risks which
affect a software project:
Project risk: This category of risk is related to budgetary schedule,
personnel, resource, and customer-related problems. An important project risk is
schedule slippage. As software is an intangible entity, it is very difficult to monitor
and control a software project. It is very difficult to control something which cannot
be seen. For a manufacturing project, the project manager can see the product
taking shape. For example, in the manufacturing of a car the project manager sees
that the engine is fitted, after that the doors are fitted, the car is being painted, and
so on. Therefore, for him it is easy to assess the progress of the work and control
it. As the software product is invisible this is an important reason why many software
projects suffer from the risk of schedule slippage.
Technical risk: This type of risk is concerned with potential design,
implementation, interface, testing and maintenance problems. Technical risks also
include incomplete specification, ambiguous specification, technical uncertainty,
changing specification and technical obsolescence. The main reason for the
occurrence of technical risk is due to the development team’s insufficient knowledge
about the project.

Self-Instructional
Material 135
Risk Management Business risk: This type of risk occurs when the team wants to produce
an innovative product that no one wants. This causes losing the budgetary or
personnel commitments, etc.

NOTES Risk containment

After all the identified risks of a project are assessed, plans must be made to
contain the most damaging and most likely risks. Different risks require different
containment procedures. In fact, most risks require ingenuity on the part of the
project manager in tackling risks.
There are three main strategies to plan for risk containment:
 Avoid the risk: This may take several forms such as discussing with the
customer to change the requirements for reducing the scope of work,
giving incentives to engineers to avoid the risk of manpower turnover,
etc.
 Transfer the risk: This strategy involves getting the risky component
developed by a third party, buying insurance cover, etc.
 Risk reduction: This involves planning ways to contain the damage
due to a risk. For example, if there is risk that some key personnel might
leave, new recruitment may be planned.
Therefore risk management, change management and crisis management is
a big part of project management. In logistics the most important task is to anticipate
and manage risks. The level of changes has to be anticipated and then contingency
plans should be made for them.
There should be some margin and capacity to handle changes and for margin
of safety. For example, during a battle, all resources would not be committed
initially; rather it is an important military strategy to reserve some resources to be
put in action later in the combat. An important type of reserve employed in software
production is the use of overtime. It is a common practice to employ standby
machines in case a machine breaks down. This ensures that there is no loss of time
and productivity.
We can see that there are many software systems that are unnecessarily
complex. The risks involved in such systems can be reduced or nullified by simplifying,
standardizing and automating both software processes and software products. Some
of the related risks can be anticipated and thereby removed. One good example is
hardware failures, such as hardware system crash or data memory disk failures.
We would be required to perform regular disk backup and have copies of
data stored externally (in fire-proof building) to protect critical data. We could
have disaster recovery site for critical systems for even stricter requirement on
availability.
There are many different common risks which we should think about and
this includes personnel turnover, vacation, project termination or downsizing. Such
Self-Instructional
136 Material
risks can be taken care of by cross-training personnel in different tasks so that Risk Management

there will be personnel who will be able to take care in any situation. Comprehensive
and accurate system documentation is necessary to acclimatize fresh recruits to
the organization set-up. We should frequently provide training to new people and
assign mentors to new people. In case of major project redirection or downsizing, NOTES
upper management help will be needed to re-assign people to other projects. Do
not hesitate to ask for help when you have a need and at the same time try to
address all contingency issues within your project. You should make sure that the
system built is flexible, easy to maintain and scalable. This is also a kind of
contingency. Therefore, you should have good system architecture and stick to it.
Good systems will continue to grow in features and number of users. So to handle
higher usage volume without performance degradation you need a scalable
architecture. The architecture should be extensible so that it is easy to add new
features, without any drastic effects on existing customers.

Check Your Progress

1. Define the concept of risks.
2. Give the definition of risk management.
3. State about the risk control.
4. Explain the term effective risk management.
5. Write the three categories of risk

7.6 AIDS FOR RISK IDENTIFICATION

 Objectives-based risk identification: Organizations and project teams

have objectives. Any event that may endanger achieving an objective partly
or completely is identified as a risk.
 Scenario-based risk identification: Scenario analysis involves the creation
of various scenarios. These scenarios may be an alternative method to
achieve an objective, or an analysis of the interaction of forces in a market
or battle. Any event that triggers an undesired scenario alternative is identified
as a risk.
 Taxonomy-based risk identification: Taxonomy is the breakdown of
possible risk sources. A questionnaire is compiled based on taxonomy and
knowledge of best practices. The answers to the questions reveal risks.
 Common-risk checking: In several industries, lists of known risks are
available. Each risk in the list can be checked for its application to a particular
situation. An example of a known risk in the software industry is the common
vulnerability.

Self-Instructional
Material 137
Risk Management  Risk charting (risk mapping): This method combines the above
approaches by listing resources at risk, threats to those resources, modifying
factors which may increase or decrease the risk and consequences to avoid.
Creating a matrix under these headings enables a variety of approaches.
NOTES One can begin with resources and consider the threats to which they are
exposed and the consequences of each. Alternatively, one can start with the
threats and examine the resources these would affect, or one can begin with
the consequences and determine which combination of threats and resources
would be involved to bring these about.

7.7 POTENTIAL RISK TREATMENTS

Once risks have been identified and assessed, all techniques to manage the risk
fall into one or more of these four major categories:
 Avoidance (eliminate, withdraw from or not become involved)
 Reduction (optimize – mitigate)
 Sharing (transfer – outsource or insure)
 Retention (accept and budget)
Ideal use of these risk control strategies may not be possible. Some of them
may involve trade-offs that are not acceptable to the organization or person making
the risk management decisions. Another source, from the US Department of Defense,
Defense Acquisition University, calls these categories ACAT, for Avoid, Control,
Accept, or Transfer. This use of the ACAT acronym is reminiscent of another ACAT
(for Acquisition Category) used in US Defense industry procurements, in which
Risk Management prominently in decision making and planning.
Risk Avoidance
This includes not performing an activity that could present risk. Refusing to purchase
a property or business to avoid legal liability is one such example.
Avoiding airplane flights for fear of hijacking. Avoidance may seem like the answer
to all risks, but avoiding risks also means losing out on the potential gain that
accepting (retaining) the risk may have allowed. Not entering a business to avoid
the risk of loss also avoids the possibility of earning profits. Increasing risk regulation
in hospitals has led to avoidance of treating higher risk conditions, in favor of
patients presenting with lower risk.
Risk Reduction
Risk reduction or ‘Optimization’ involves reducing the severity of the loss or the
likelihood of the loss from occurring. For example, sprinklers are designed to put
out a fire to reduce the risk of loss by fire. This method may cause a greater loss
by water damage and therefore may not be suitable. Halon fire suppression systems
may mitigate that risk, but the cost may be prohibitive as a strategy.
Self-Instructional
138 Material
 Acknowledging that risks can be positive or negative, optimizing risks means Risk Management

finding a balance between negative risk and the benefit of the operation or activity;
and between risk reduction and effort applied. By effectively applying Health,
Safety and Environment (HSE) management standards, organizations can achieve
tolerable levels of residual risk. NOTES
Modern software development methodologies reduce risk by developing
and delivering software incrementally. Early methodologies suffered from the fact
that they only delivered software in the final phase of development; any problems
encountered in earlier phases meant costly rework and often jeopardized the whole
project. By developing in iterations, software projects can limit effort wasted to a
single iteration.
Outsourcing could be an example of risk sharing strategy if the outsourcer
can demonstrate higher capability at managing or reducing risks. For example, a
company may outsource only its software development, the manufacturing of hard
goods, or customer support needs to another company, while handling the business
management itself. This way, the company can concentrate more on business
development without having to worry as much about the manufacturing process,
managing the development team, or finding a physical location for a center.
Risk Sharing
Briefly defined as ‘Sharing with another party the burden of loss or the benefit of
gain, from a risk, and the measures to reduce a risk.’
The term of ‘Risk Transfer’ is often used in place of risk sharing in the
mistaken belief that you can transfer a risk to a third party through insurance or
outsourcing. In practice if the insurance company or contractor go bankrupt or
end up in court, the original risk is likely to still revert to the first party. As such, in
the terminology of practitioners and scholars alike, the purchase of an insurance
contract is often described as a ‘Transfer of Risk.’ However, technically speaking,
the buyer of the contract generally retains legal responsibility for the losses
‘Transferred’, meaning that insurance may be described more accurately as a
post-event compensatory mechanism. For example, a personal injuries insurance
policy does not transfer the risk of a car accident to the insurance company. The
risk still lies with the policy holder namely the person who has been in the accident.
The insurance policy simply provides that if an accident (the event) occurs involving
the policy holder then some compensation may be payable to the policy holder
that is commensurate with the suffering/damage.
Methods of managing risk fall into multiple categories. Risk retention pools
are technically retaining the risk for the group, but spreading it over the whole
group involves transfer among individual members of the group. This is different
from traditional insurance, in that no premium is exchanged between members of
the group up front, but instead losses are assessed to all members of the group.

Self-Instructional
Material 139
Risk Management Risk Retention
Risk retention involves accepting the loss, or benefit of gain, from a risk when the
incident occurs. True self-insurance falls in this category. Risk retention is a viable
NOTES strategy for small risks where the cost of insuring against the risk would be greater
over time than the total losses sustained. All risks that are not avoided or transferred
are retained by default. This includes risks that are so large or catastrophic that
either they cannot be insured against or the premiums would be infeasible. War is
an example since most property and risks are not insured against war, so the loss
attributed to war is retained by the insured. Also any amounts of potential loss
(risk) over the amount insured is retained risk. This may also be acceptable if the
chance of a very large loss is small or if the cost to insure for greater coverage
amounts is so great that it would hinder the goals of the organization too much.

7.8 RISK COMPONENTS AND DRIVERS

Three Risk Components

The relative risk assessment chart uses three risk components:
1. Values
2. Hazard
3. Probability
Each of these components is assessed independently. Then, the three outputs
are evaluated in a final step that provides the relative risk for the fire. Each risk
component is defined by three variables. One variable is located on the right and
one on the left side of the box and the third variable is defined by three interior
lines extending from top to bottom.
1. Values
Values are those ecologic, social, and economic resources that could be lost or
damaged because of a fire. Ecologic values consist of the following:
 Vegetation
 Wildlife species and their habitat
 Air and water quality
 Soil productivity
 Other ecologic functions
Social effects can include the following:
 Life, cultural and historical resources
 Natural resources

Self-Instructional
140 Material
  Artifacts Risk Management

 Sacred sites
Economic values can include the following:
 Property and infrastructure NOTES
 Economically valuable natural and cultural resources
 Recreation
 Tourism opportunities
2. Hazards
The hazard in wildland fire is composed of the following:
 Conditions under which the fire occurs and exists;
 Ability of the fire to spread and circulate;
 Intensity and severity the fire may present; and
 Spatial extent of the fire.
3. Probability
Probability refers to the likelihood of a fire becoming an active event with potential
to adversely affect values.
Relative Risk Considerations
 The breakdown of each aspect is not all inclusive and considerations can vary
by place and time.
 Users are expected to exercise their judgment in determining the ratings;
information is intended to provide both guidance in completion and flexibility
in determining exactly what the descriptions mean.
 Local information can and should be amended to the lists to better reflect
site-specific situations.
 Local, site-specific information concerning air quality and smoke
management must be amended into the Wildland Fire Relative Risk
Assessment to reflect variances in situations and local values and regulatory
concerns.
 Air-quality criteria should be reflected in the values assessment portion,
smoke production can be incorporated into the hazard descriptive list, and
descriptive information related to the probability of adverse smoke events,
if available, can be addressed as part of the probability assessment.
Risk Drivers
Preston Smith and Guy Merritt, in their book, Proactive Risk Management define
a Risk Driver as: ‘Something existing in the project environment that leads one to
Self-Instructional
Material 141
Risk Management believe that a particular risk would occur.’ We describe them as the specific
concerns which make us feel like this is a risk.

NOTES
7.9 RISK PRIORITIZATION

In the clinical context, establishing priorities aids in the rationale and justification
for the use of limited resources. Priority setting is influenced by time, money, and
expertise. A risk priority number assessment is one way to establish priorities that
may be difficult to establish in a health care setting.
In the risk prioritization step, the overall set of identified risk events, their
impact assessments, and their probabilities of occurrences are ‘Processed’ to derive
a most-to-least-critical rank-order of identified risks. A major purpose of prioritizing
risks is to form a basis for allocating resources.
Multiple qualitative and quantitative techniques have been developed for
risk impact assessment and prioritization. Qualitative techniques include analysis
of probability and impact, developing a probability and impact matrix, risk
categorization, risk frequency ranking (risks with multiple impacts), and risk urgency
assessment. Quantitative techniques include weighting of cardinal risk assessments
of consequence, probability, and timeframe; probability distributions; sensitivity
analysis; expected monetary value analysis; and modeling and simulation. MITRE
has developed the min- and max-average approaches (using a weighting scale
more heavily weighting the max or min value). Expert judgment is involved in all of
these techniques to identify potential impacts, define inputs, and interpret the data.

Check Your Progress

6. What is scenario identification?
7. Elaborate on the term Risk reduction
8. Define the term risk drivers.
9. Explain the term risk prioritization.

7.10 ANSWERS TO CHECK YOUR PROGRESS

QUESTIONS

1. In simple terms, risk is the possibility of something bad happening. Risk

involves uncertainty about the effects/implications of an activity with respect
to something that humans value (such as health, well-being, wealth, property
or the environment), often focusing on negative, undesirable
consequences. Many different definitions have been proposed. The
international standard definition of risk for common understanding in different
applications is ‘Effect of uncertainty on objectives’.
Self-Instructional
142 Material
 2. The methods, definitions and goals vary widely according to whether the Risk Management

risk management method is in the context of project management, security,

engineering, industrial processes, financial portfolios, actuarial assessments
or public health and safety known as risk management.
NOTES
3. Risk control process of managing risks to achieve desired outcomes. After
all, the identified risks of a plan are determined; the project must be made
to include the most harmful and the most likely risks. Different risks need
different containment methods. In fact, most risks need ingenuity on the
part of the project manager in tackling the risk.
4. Effective risk management means attempting to control, as much as possible,
future outcomes by acting proactively rather than reactively. Therefore,
effective risk management offers the potential to reduce both the possibility
of a risk occurring and its potential impact.
5. Three categories of risk are-
 Project Risk
 Technical Risk
 Business Risk
6. Scenario analysis involves the creation of various scenarios. These scenario
may be an alternative method to alternative method to achieve an objective,
or an analysis of the interaction of forces in a market or battle. Any event
that triggers an undesired scenario alternative is identifies as a risk.
7. Risk reduction or ‘Optimization’ involves reducing the severity of the loss
or the likelihood of the loss from occurring. For example, sprinklers are
designed to put out a fire to reduce the risk of loss by fire. This method may
cause a greater loss by water damage and therefore may not be
suitable. Halon fire suppression systems may mitigate that risk, but the cost
may be prohibitive as a strategy.
8. Preston Smith and Guy Merritt, in their book, Proactive Risk Management
define a Risk Driver as: ‘Something existing in the project environment that
leads one to believe that a particular risk would occur.’ We describe them
as the specific concerns which make us feel like this is a risk.
9. In the clinical context, establishing priorities aids in the rationale and
justification for the use of limited resources. Priority setting is influenced by
time, money, and expertise. A risk priority number assessment is one way
to establish priorities that may be difficult to establish in a health care setting.

7.11 SUMMARY

 In simple terms, risk is the possibility of something bad happening. Risk

involves uncertainty about the effects/implications of an activity with respect
Self-Instructional
Material 143
Risk Management to something that humans value (such as health, well-being, wealth, property
or the environment), often focusing on negative, undesirable consequences.
 The international standard definition of risk for common understanding in
different applications is ‘Effect of uncertainty on objectives’.
NOTES
 The understanding of risk, the methods of assessment and management, the
descriptions of risk and even the definitions of risk differ in different practice
areas (business, economics, environment, finance, information
technology, health, insurance, safety, security, etc.).
 The methods, definitions and goals vary widely according to whether the
risk management method is in the context of project management, security,
engineering, industrial processes, financial portfolios, actuarial assessments
or public health and safety known as risk management.
 The objective of risk assessment is to division the risks in the condition of
their loss, causing potential.
 Technology risks that assume from the software or hardware technologies
that are used to develop the system.
 People risks that are connected with the person in the development team.
 Organizational risks that assume from the organizational environment where
the software is being developed.
 Tools risks that assume from the software tools and other support software
used to create the system.
 Requirement risks that assume from the changes to the customer requirement
and the process of managing the requirements change.
 Estimation risks that assume from the management estimates of the resources
required to build the system
 Risk analysis process, you have to consider every identified risk and make
a perception of the probability and seriousness of that risk.
 Process control is the process of managing risks to achieve desired
outcomes. After all, the identified risks of a plan are determined; the project
must be made to include the most harmful and the most likely risks. Different
risks need different containment methods. In fact, most risks need ingenuity
on the part of the project manager in tackling the risk.
 Effective risk management means attempting to control, as much as possible,
future outcomes by acting proactively rather than reactively. Therefore,
effective risk management offers the potential to reduce both the possibility
of a risk occurring and its potential impact.
 Scenario analysis involves the creation of various scenarios. This scenario
may be an alternative method to alternative method to achieve an objective,
or an analysis of the interaction of forces in a market or battle. Any event
that triggers an undesired scenario alternative is identifies as a risk.
Self-Instructional
144 Material
  Risk reduction or ‘Optimization’ involves reducing the severity of the loss Risk Management

or the likelihood of the loss from occurring. For example, sprinklers are
designed to put out a fire to reduce the risk of loss by fire. This method may
cause a greater loss by water damage and therefore may not be
suitable. Halon fire suppression systems may mitigate that risk, but the cost NOTES
may be prohibitive as a strategy.
 Risk retention involves accepting the loss, or benefit of gain, from a risk
when the incident occurs. True self-insurance falls in this category.
 Risk retention is a viable strategy for small risks where the cost of insuring
against the risk would be greater over time than the total losses sustained.
All risks that are not avoided or transferred are retained by default. This
includes risks that are so large or catastrophic that either they cannot be
insured against or the premiums would be infeasible.
 Preston Smith and Guy Merritt, in their book, Proactive Risk Management
define a Risk Driver as: ‘Something existing in the project environment that
leads one to believe that a particular risk would occur.’ We describe them
as the specific concerns which make us feel like this is a risk.
 In the clinical context, establishing priorities aids in the rationale and
justification for the use of limited resources. Priority setting is influenced by
time, money, and expertise. A risk priority number assessment is one way
to establish priorities that may be difficult to establish in a health care setting.
 In the risk prioritization step, the overall set of identified risk events, their
impact assessments, and their probabilities of occurrences are ‘Processed’
to derive a most-to-least-critical rank-order of identified risks. A major
purpose of prioritizing risks is to form a basis for allocating resources.
 In the clinical context, establishing priorities aids in the rationale and
justification for the use of limited resources. Priority setting is influenced by
time, money, and expertise. A risk priority number assessment is one way
to establish priorities that may be difficult to establish in a health care setting.

7.12 KEY WORDS

 Risk: The international standard for risk management, ISO 31000, provides
a common approach to managing any type of risk.
 Risk management: Risk management method is in the context of project
management, security, engineering, industrial processes, financial portfolios,
actuarial assessments or public health and safety known as risk management.
 Risk assessment: Risk assessment is to division the risks in the condition
of their loss, causing potential.
 Risk analysis: Risk analysis process, consider every identified risk and
make a perception of the probability and seriousness of that risk.
Self-Instructional
Material 145
Risk Management  Risk reduction: Risk reduction or ‘optimization’ involves reducing the
severity of the loss or the likelihood of the loss from occurring.
 Values: Values are those ecologic, social, and economic resources that
could be lost or damaged because of a fire
NOTES
 Risk prioritization: In the risk prioritization step, the overall set of identified
risk events, their impact assessments, and their probabilities of occurrences
are ‘Processed’ to derive a most-to-least-critical rank-order of identified
risks.

7.13 SELF ASSESSMENT QUESTIONS AND

EXERCISES

Short-Answer Questions
1. What is risk?
2. Explain the term three main methods of risk management.
3. Define the term risk analysis process.
4. Elaborate on the term technical risk.
5. Define the term Risk Avoidance.
6. What are relative risk considerations for risk components?
7. Explain the term risk prioritization.
Long-Answer Questions
1. Briefly explain the risk management giving appropriate examples.
2. Describe in details risk management activities with the help of diagram.
3. Discuss about the effective risk management process giving appropriate
examples.
4. Briefly explain the risk containment with the help of examples.
5. Describe in details the risk identification.
6. Discuss about the potential risk treatments and also explain the four major
catteries.
7. Briefly explain the risks components and drivers with the help of examples.

7.14 FURTHER READINGS

Hughes, Bob, Mike Cotterell and Rajib Mall. 2017. Software Project
Management (SIE), 6th Edition. New York: McGraw Hill Education.
Schach, Stephen R. 2005. Object Oriented and Classical Software Engineering.
New Delhi: Tata McGraw-Hill.
Self-Instructional
146 Material
Pressman, Roger S. 1997. Software Engineering, a Practitioner’s Approach. Risk Management

New Delhi: Tata McGraw-Hill.

Somerville, Ian. 2001. Software Engineering. New Delhi: Pearson Education.
Ghezzi, Carlo, Mehdi Jazayeri, and Dino Mandriolli. 1991. Fundamentals of NOTES
Software Engineering. New Delhi: Prentice-Hill of India.
Jawadekar, Waman S. 2004. Software Engineering: Principles and Practice.
New Delhi: Tata McGraw-Hill.
Jalote, Pankaj. 1991. An Integrated Approach to Software Engineering. New
Delhi: Narosa Publishing House.

Self-Instructional
Material 147
Configuration
Management
UNIT 8 CONFIGURATION
MANAGEMENT
NOTES
Structure
8.0 Introduction
8.1 Objectives
8.2 Software Configuration Management (SCM)
8.3 Software Configuration Planning
8.4 Goals of Software Configuration Management (SCM)
8.5 Answers to Check Your Progress Questions
8.6 Summary
8.7 Key Words
8.8 Self Assessment Questions and Exercises
8.9 Further Readings

8.0 INTRODUCTION

Software Configuration Management (SCM) is the task of tracking and controlling

changes in the software, part of the larger cross-disciplinary field of configuration
management. SCM practices include revision control and the establishment
of baselines. If something goes wrong, SCM can determine what was changed and
who changed it. If a configuration is working well, SCM can determine how to
replicate it across many hosts. The acronym SCM is also expanded as source
configuration management process and software change and configuration
management.
Software configuration management is used to manage changes in the
intermediate products. Intermediate products, for example, developed in waterfall
model include requirement document, design document, program code, and so on.
In this model, the intermediate products undergo changes at different points of time.
The software design, for example, may change after testing phase or requirements
may change after the coding phase. SCM is used to control these changes by identifying
the intermediate products (which are likely to change) and establishing relationships
among them. Note that in software configuration management, changes to work
products should be made in such a manner that their integrity and traceability is
maintained. SCM is also responsible for auditing and reporting these changes. Other
objectives of software configuration management include planning the configuration
management activities, controlling changes identified in work products and identifying
the selected work products. Configuration identification as an element of configuration
management, consisting of selecting the configuration items for a system and recording
their functional and physical characteristics in technical documentation.
In this unit, you will study about the Software Configuration Management
Self-Instructional (SCM), baselines, and Software Configuration Items (SCI), SCM process, and
148 Material
identification objects in the software configuration, version control, change control, Configuration
Management
configuration audit, status reporting, and goals of SCM.

8.1 OBJECTIVES NOTES

After going through this unit, you will be able to:
 Understand the basics of Software Configuration Management (SCM)
 Define the baselines of Software Configuration Management (SCM)
 Discuss about the Software Configuration Items (SCI)
 Explain SCM process
 Elucidate on the identification objects in the software configuration
 Analyse the version control
 Define the change control
 Discuss about the configuration audit
 Understand the status reporting
 Elaborate on the goals of SCM

8.2 SOFTWARE CONFIGURATION

MANAGEMENT (SCM)

Changes occur during all the phases of software development. They arise when
user requirements are not understood properly or when new business or market
conditions cause changes in product requirement (Refer Figure 8.1). Various other
reasons for changes are:
 New user requirements demand modification of data or functions produced
by the software.
 Business growth or downsizing causes changes in project priorities.
 Cost and time constraints cause a redefinition of the system or product.

Fig. 8.1 Changes in Software Development Self-Instructional

Material 149
Configuration The changes in the work products should be done in a controlled manner.
Management
For this, software configuration management is used to manage changes in the
intermediate products. Intermediate products, for example, developed in waterfall
model include requirement document, design document, program code, and so
NOTES on. In this model, the intermediate products undergo changes at different points of
time. The software design, for example, may change after testing phase or
requirements may change after the coding phase. SCM is used to control these
changes by identifying the intermediate products (which are likely to change) and
establishing relationships among them. Note that in software configuration
management, changes to work products should be made in such a manner that
their integrity and traceability is maintained. SCM is also responsible for auditing
and reporting these changes. Other objectives of software configuration management
include planning the configuration management activities, controlling changes
identified in work products and identifying the selected work products.
IEEE defines software configuration management as the process of
identifying and defining components in a system, controlling the release and
change throughout the life cycle, recording and reporting the status of
components and change requests, and verifying the completeness and
correctness of system components.
 Identification: Identifying the structure of the product, its components
and their type, making them unique and accessible in some form.
 Control: Controlling the release of a product and changes to it
throughout the life cycle by having controls in place that ensure consistent
software via the creation of a baseline product.
 Status Accounting: Recording and reporting the status of components
and change requests, and gathering the vital statistics of the components
in the product.
 Audit and Review: Validating the completeness of a product and
maintaining consistency among the components by ensuring that the
product is a well-defined collection of components.
The software project that requires changes in the work product follows a
policy to implement software configuration management. This policy specifies that
the responsibility of each project should be assigned explicitly, as different projects
require different changes. In addition, this policy states that baselines and software
configuration activities should be audited on a regular basis. The software
configuration management provides significant benefits to all software projects
regardless of their size, scope and complexity. These benefits are as follows:
 It ensures that only approved changes are implemented in both new and
existing products.
 It verifies that the changes are implemented according to the desired
specifications.
Self-Instructional
150 Material
  It evaluates the impact of changes and communicates it to the project Configuration
Management
manager.
 It allows the overall system progress to be faster and efficient.
 It ensures that all updates are accurately shown in the documentation. NOTES
Note: To deal with the requirement changes, a separate process (Change
Management Process) is needed which is discussed after the software configuration
management process.
To implement the SCM in the software development, one must understand
the concept of software configuration items and baselines.
Software Configuration Items
Software Configuration Item (SCI) is the ‘Smallest Unit of Change’. IEEE defines
a configuration item as an aggregation of hardware, software, or both that is
designated for configuration management and treated as a single entity in
the configuration management process. Software configuration item is managed
with the combination of processes and tools to avoid the introduction of errors
and help to maintain high quality results. The configuration items act as input and
output to the SCM activities since changes to the software are done through
software configuration items.
A Software Development Life Cycle (SDLC) may produce one or more
software configuration items. Some of the configuration items managed in a software
engineering process are listed in Table 8.1.
Table 8.1 List of Software Configuration Items

Configuration Items Examples

Management plan Process plan, SCM plan, test plan and maintenance
plan
Specification Requirements, design and testing specification
Design Source code
Testing Test design, case, procedure and data generation
Support software Planning documents
Data dictionary Software requirement specification
Code Source, executable and requirement
Libraries Component and reuse libraries
Databases Audit database
Maintenance Listings, detailed design descriptions and measures

Baselines
When a change is required, a basis for the change should be clearly established
prior to making changes to the configuration items. This requires a clear
understanding of the configuration items to avoid undesirable results. As a result, a
baseline is established when the product is said to be in a stable state. A baseline
helps to control change without seriously effecting the justifiable change. IEEE

Self-Instructional
Material 151
Configuration defines a baseline as a specification or product that has been formally reviewed
Management
and agreed upon, that thereafter serves as the basis for further development,
and that can be changed only through formal change control procedure.
A baseline is referred to as a collection of software configuration items
NOTES
which have been approved after carrying out formal technical reviews. In the
design model, for example, errors have been detected and corrected after carrying
out the review process. After all the parts of this model have been reviewed,
corrected, and then approved, the design model can be referred to as a baseline.
Figure 8.2 shows the sequence of events that lead to a baseline. A
requirement baseline, for example, can consist of many software configuration
items (where each requirement is considered as an individual configuration item),
which are related to other (SCIs) in the requirement baseline.

Fig. 8.2 Baseline and SCI in a Project

A baseline can consist of many SCIs which should have a relationship among
them. This relationship should be considered before making any changes. If, for
example, SCI ‘A’ is dependent on SCI ‘B’, then any changes made to ‘B’ should
take place in ‘A’ also; making changes only to ‘B’ can make both ‘A’ and ‘B’
inconsistent. Thus, to keep the baseline consistent, relationship of one SCI with
other SCI should always be considered. Note that if two baselines are not related
to each other, then changes to them can be made independently.
The baselines are developed at every phase of software development. Once
the baselines are identified, changes can be applied on them. In a waterfall model,
for example, requirement document is established as a baseline once the requirement
phase is over and all the requirements are known. Different baselines produced
during the waterfall model are shown in Figure 8.3.

Self-Instructional
152 Material
 Configuration
Management

NOTES

Fig. 8.3 Baseline in Waterfall Model

Note: A baseline should be developed when the requirements are frozen

(requirements of the software are complete and final).
SCM and SDLC
Software configuration management is different from software development life
cycle in terms of handling changes. SDLC can handle only normal changes, like
changes in requirement during the requirement phase or changes in coding during
the coding phase. SCM on the other hand can handle various changes that take
place during different phases of SDLC (Refer Figure 8.4). SCM, for example,
can perform changes that occur in requirements during the coding phase and changes
that occur in software design during the testing phase in a controlled manner.
Thus, it can be said that SCM controls changes in products like requirement
document, design document and code document.

Fig. 8.4 Relationship between SDLC and SCM

Check Your Progress

1. Give the definition of software configuration management according to IEEE.
2. Define the term baselines.
Self-Instructional
Material 153
Configuration
Management 8.3 SOFTWARE CONFIGURATION PLANNING

The activities to be performed in software configuration management should be

NOTES planned in a proper manner. For this, a plan known as Software Configuration
Management Plan (SCMP) is developed in the early stages of software
development. This plan describes the standards and procedures used in SCM. It
also determines the SCM activities to be performed, schedule for those activities,
and assigns responsibilities and resources required including staff and various tools.
A software configuration plan should include a configuration database or
repository to keep a record of configuration information. Figure 8.5 shows a
software configuration management plan. This plan comprises various sections,
which are listed below:
 Introduction: Specifies information regarding the purpose, scope,
definitions, and the references of SCM activities. In addition, it includes
the steps and activities, which describe how configuration management
is to be performed for the work product. The definitions and abbreviations
used for software configuration are also described in this section.
 Software Configuration Management: Specifies the responsibilities
of the organization in configuration activities. It determines the relationship
between configuration management and SDLC.

Fig. 8.5 Software Configuration Management Plan

Self-Instructional
154 Material
 Software Configuration Management Activities: Specifies the Configuration
Management
configuration activities to be conducted. As shown in Figure 8.5, it comprises
the following subsections.
o Configuration Identification: Identifies the configuration items or
NOTES
the documents that require changes. The specification identification
describes the labeling and numbering scheme for the documents. In
addition, it describes how the identification scheme addresses versions
and releases. Project baselines identify different baselines used in the
project and keep track of whether the baseline requires the changes.
The library section specifies the plans and procedures for recovery
when loss occurs due to the changes made. For this, it determines the
number of libraries and their types utilized for SCM activities.
o Configuration Control: Describes the procedures for changing
baselines (as the procedures vary for each baseline) and for processing
of a change request. This can be implemented with change report
documentation. In addition, this section keeps a record of the
organizational responsibilities for change control as the changes occur
throughout the life cycle of a software project. The decisions regarding
changes are managed by the Configuration Control Board (CCB),
which is also known as Change Control Board. Beside this, the
section also describes automated tools, which are required to perform
the change control.
o Configuration Status Accounting: Stores all the information related
to software configuration activities. In this section, the status of the
configuration items and handling and release process is also described.
For this, the information needs to be stored in form of a report. Various
reports produced can be management reports, quality assurance
reports, configuration control board reports, and so on.
o Configuration Auditing: Specifies the number of audits to be
performed and the time when they are to be performed. The audit
provides information regarding the role of configuration management
in the audit. In addition, this section determines the documents to be
audited.
 CM Milestones: Specifies all the configuration management milestones
(such as, baselines, reviews, audits, and so on) and determines how these
milestones are according to the software development process. In addition,
it identifies the criteria to be utilized for achieving a milestone.
 Training: Specifies the kind and the amount of training (such as, orientation,
tools) to be provided to the individuals according to the software
configuration management activities.
 Subcontractor/Vendor Support: Specifies the vendor support and
interfacing, if applicable.
Self-Instructional
Material 155
Configuration Various individuals are associated with configuration management with each
Management
having some specific responsibilities. These individuals along with their
responsibilities are described below:
 Configuration Manager: Checks whether policies and procedures
NOTES
for creating and modifying the product are carried out successfully. For
this, he/she uses a mechanism for making a request for the changes.
These change requests are examined and approved by the configuration
manager. After the approval for change requests, information is collected
for determining the problematic components in the system.
 Software Engineer: Uses tools to develop a consistent product. To
maintain consistency, it is necessary that the software engineers do not
interfere unnecessarily in each other’s work while the code is being
created and tested. However, some interaction is important when the
work of engineers is dependent on each other. This interaction involves
discussing and consulting one another about the tasks that are required
and the tasks that are completed.
 Project Manager: Ensures that the project is developed within the
allotted time. For this, the project manager keeps track of the development
process and identifies as well as reacts to the problems.
 Users: Play a major role in software configuration management as the
product is developed for them. Users follow a specified procedure for
requesting changes and indicate the problems associated with the product.
Project Library
In the early days of software engineering, it was difficult to determine and manage
the configuration items (to be changed) and establish a relationship between them.
To solve this problem, the project library was introduced. Project library, also
known as project database or SCM repository, is used to keep track of all the
software configuration activities that are involved in SCM. The project library
comprises a set of mechanisms and data structures that help in managing changes
in an effective manner. Various functions performed by the project library are
listed below:
 Data Integrity: Changes to the related configuration items are automatically
made in the project library when change is implemented to a single
configuration item.
 Information Sharing: Allows sharing of information among different
developers and between different tools. The project library involves multi-
user access to the data and locks configuration items so that the changes in
it are not done unknowingly.
 Tool Integration: The project library establishes a data model, which is
accessed by various software tools. It also controls access to the data, and
performs appropriate configuration management functions.
Self-Instructional
156 Material
 In addition to the above mentioned functions, the project library describes Configuration
Management
the services that are to be provided to the stored configuration items and keeps
track of the tools that are to be used for software development. For this, the
repository used by the software team should integrate with the process management
functions. NOTES
The project library also comprises a tool set to provide support for the
following features of SCM:
 Versioning: Development of project involves creation of various
versions of the product as the project progresses. The major function of
the repository is to maintain a record of all the versions of a product to
enable effective management of product releases. Also, the repository
should help the developers to use the previous versions when testing
and debugging is performed.
 Tracking Dependency: The repository stores different configuration
objects and manages the relationship among them. It is essential to have
a record for these relationships as the work products are developed
according to these relationships, which results in improving the software
development process.
 Tracing Requirements: This function determines the ability to track
design and coding components and the work products that are derived
from the requirements specifications. These requirements are maintained
in the project library. In addition, it enables to trace which requirements
led to any given work product.
 Audit Trails: It provides information about why, when, and by whom
the changes have been made. The project library stores the information
regarding the source of changes as the attributes of specific objects in
the library.
Note: The project library is developed according to the size of the project where each software
project can have its own library to maintain its records.

Software Configuration Management Process

The major objective of software configuration management is to determine the
items that collectively manage changes in one or more configuration items. SCM
should also help in developing various versions of software and maintain the quality
of the software as the configuration evolves over time.
To accomplish these responsibilities, the SCM process is used. This process
addresses some critical issues related to the software configuration management,
which are listed below:
 Identifying discrete elements of software configuration
 Controlling changes in the software before and after its release
 Ensuring that the changes are according to requirements
Self-Instructional
Material 157
Configuration  Managing the existing versions of software to accommodate changes
Management
efficiently
 Specifying responsibility to approve and rank changes
NOTES These issues give rise to various activities or tasks to be performed for
software configuration. These activities include configuration identification,
change control, version control, configuration auditing and configuration
status reporting. All these activities are regarded as homocentric layers. In Figure
8.6, configuration items flow outwards all the way through these layers during
their useful life and in the end become part of the software configuration of one or
more versions of the product. As software configuration items move from one
layer to another, the actions performed by one layer may or may not be applicable.
For instance, whenever a new software configuration item is developed, it is essential
to identify the change. However, if the changes to the software configuration items
are not requested, the change control layer is not applicable.

Fig. 8.6 SCM Activities

Configuration Identification
Configuration identification refers to the process of uniquely identifying a selected
software component. IEEE defines configuration identification as An element of
configuration management, consisting of selecting the configuration items
for a system and recording their functional and physical characteristics in
technical documentation.
Configuration identification becomes the basis for controlling and
implementing changes to selected software components. The configuration
identification process comprises three steps, which are listed below:
 Selection: The software is divided into a set of configuration items.
Each of these items is developed and tested separately and finally all the
items are integrated together. The software is divided into configuration
items either as specified in the contract or in the early phase of
development, such as the analysis phase. The division of software into
configuration items may occur because of the reasons listed below:
Self-Instructional
158 Material
 o Software has stringent performance requirements. Configuration
Management
o Software is planned to be reused.
o Software encapsulates interfaces with other software items that
currently exist or are provided by other organizations. NOTES
o Software, after becoming operational, is likely to be changed more
than as expected.
 Identification: When the configuration items are separated, it is essential
to uniquely identify each item. This unique identification facilitates tracking
changes to be made, checking the status of the changes and reporting of
information related to the changes made in the configuration items.
 Description: The description of software components (such as, design
specification, software detail design specification, and interface control
documents) is elaborated as software development proceeds to software
design phase. This description serves as a base for the change control
and configuration status reporting and finally, in ensuring that the software
is complete and verified.
Effective configuration identification is a prerequisite for other configuration
management activities since all these activities use the products of configuration
identification. If configuration identification and their associated configuration
documentation are not properly specified, it is difficult to control the changes to
the configuration items, to establish accurate records and reports, or to validate
the configuration through audit. Also, accurate and complete configuration
documentation helps in avoiding schedule delays and higher maintenance costs
after delivery of the product. Other functions performed by the configuration
identification are listed below:
 Determining the hierarchical structure of a product and the organization
 Documenting the performance, interface, and other attributes of a product
 Modifying identification of product and documents to reflect
incorporation of major changes
 Maintaining release control of documents for baseline management
 Providing a reference point for defining changes and corrective actions
Note: In software configuration management, tasks and activities mean the same thing and
hence, are used interchangeably.

Change Control
Change control is a process used to describe, review, and support the changes
made to software under software configuration management. It ensures that the
intermediate product is changed according to the identified changes. Various
software configuration tools are used to manage changes so that they are done in
a controlled manner. The entire change process is shown in Figure 8.7.
Self-Instructional
Material 159
Configuration The decisions regarding changes to configuration items are taken by the
Management
configuration control board. The size of CCB depends on the size of the project.
The responsibilities of this board are listed below.
 Ensuring that changes are made in an organized and controlled manner
NOTES
 Managing changes from the initial requests to technical recommendations
in the activities
 Enhancing high business performance by identifying technically sound
improvements to have a high benefit to cost ratio
The control configuration board comprises individuals (or stakeholders)
who are responsible for making changes to the configuration items. These individuals
are listed in Table 8.2.

Fig. 8.7 Change Control Process

Self-Instructional
160 Material
 Table 8.2 Individuals in Configuration Control Board Configuration
Management
Roles Description
Change Manager/ Responsible for implementing the entire configuration process.
Configuration Manager Change manager plans and documents the configuration NOTES
management activities. In addition, he/she is also responsible
for making decisions related to change requests.
Originator Requests for changes in the items.
Evaluator Analyses the impact of the requested changes.
Modifier Responsible for making changes in an intermediate product. In
addition, the modifier updates the status of the request over a
period of time.

As shown in Figure 8.8, the configuration item under the development stage
is said to be in working state. This configuration item is independent of other
configuration items and is controlled by the developer. Once the developer is
satisfied that the configuration item is stable enough to be delivered to other users,
the SCI is given to the configuration manager for review and the item is said to
have entered the under review state.

Fig. 8.8 Life Cycle of SCI under SCM

The configuration manager reviews this SCI and if he approves it, the item
is recorded in the project library; otherwise, the change is rejected. Note that all
the procedures followed by the configuration control board are specified in the
software configuration management plan.
The changes to software configuration items under SCM are initiated by
Change Request (CR). When a request for change is made, configuration
manager evaluates the request by considering its impact on the project cost,
schedule, and quality. After the changes have been approved, the originator
implements them.
Change request is implemented with the help of a change request form. A
change request form contains request for change and the summary of other
information related to the change such as the items to be changed, their description,
Self-Instructional
Material 161
Configuration causes of change and request originator. In addition, it describes the status of the
Management
change. The configuration control board assigns a unique identifier to every change
request. In addition, it also determines the suggestions in the change request form
to improve the configuration items.
NOTES
The change request form defines a priority for each change request. The
configuration control board arranges the change requests according to high,
medium, and low priority. The change that needs to be made as soon as possible
is given the highest priority. The change required for missing functionality, is given
the medium priority. The change that leads to minor improvements to the
configuration items is given the low priority. Figure 8.9 shows the change request
form, which is sent to the configuration control board for its approval to the change
request.

Fig. 8.9 Change Request Form

Note: The most common reason for a change in the software is a fault. Change request
arising due to existence of a fault is made on a form known as Fault Report (FR). A fault
report is generally treated as high priority change request. In addition, it keeps track of the
status of the fault.

Self-Instructional
162 Material
Version Control Configuration
Management
Version control is a process of maintaining and tracking versions of the project.
This includes identification and managing configuration items, which change over
time. This control is essential because without this, it becomes difficult to maintain NOTES
a record of changes, version number, and its link with other configuration items.
Other benefits of version control are listed below:
 Comparing two versions of a file and highlighting the differences
 Forcing serialized changes to any given file and providing a locking mechanism
 Providing the ability to roll back to the previous version of a file in case any
failure occurs in the new version
 Helping in creating branches that allow parallel concurrent development
 Maintaining an instant audit trail on each and every file
 Allowing more than one developer to work on the code
Version control combines procedures and tools to manage different versions
of SCIs, which are created during SDLC. When the changes are incorporated, a
new version of configuration item is created. However, the new version does not
replace the older version of SCI. Instead, the record of different versions of SCI
is maintained that helps in providing the details of the latest as well as previous
versions. A delta (difference between previous and newer version) is created for
these configuration items rather than storing them in the project library. Two types
of deltas (Refer Figure 8.10) are used to store the versions of the configuration
item. These are listed below.

Fig. 8.10 Types of Deltas

 Forward Delta: This maintains the entire copy of the original file. When
a newer version is developed, the two versions are compared and a
delta report is produced. This delta report is stored instead of storing
the newer version. If there are many versions, more retrieval time is
Self-Instructional
Material 163
Configuration required. This is because the configuration manager will start with the
Management
original version and then apply delta one by one to create the latest
version.
 Reverse Delta: This specifies the most recent version of the file. This
NOTES
newer version is evaluated, compared with the earlier version and a
delta is developed. The older version of the module is deleted, and the
newer version is stored. The reverse delta storage method does not
require computation as it is stored in its full form. In case the latest
version of the module is required, reverse delta is considered to be
efficient.
Note: The decision on selecting forward delta or reverse delta is made on the basis of the
project size and its nature.

Configuration Audit
The configuration audit ensures that all change requests are accomplished and are
according to the established SCM processes and procedures. This audit affirms
whether the developed product is in accordance with the requirements and
conforms to the established standards. Auditing is performed by the auditor(s), as
a part of the review process in SCM. The auditor(s) evaluates previous changes
and ensures that they are in accordance with SCM procedures. These procedures
are evaluated to ensure that the SCM goals are met. The duration of audit can be
small in the initial stages; however, as the process becomes more stable, time
period increases. Auditing provides effective solutions to the problems arising during
software development. These problems are avoided by ensuring the following
points:
 A suitable software process is followed
 All related SCIs are properly updated
 All the changes are highlighted in the configuration item
To ensure whether the changes have been implemented properly,
configuration audit and formal technical reviews are carried out. The formal technical
review emphasizes on the technical correctness of SCI that has been modified
and is generally carried out for larger and critical changes.
Types of Configuration Audit
The configuration audits are of two types, namely, informal and formal. The
informal configuration audit is carried out during different phases of the software
life cycle. The formal configuration audit is performed before the release of a
product baseline. It is of two types.
 Physical Configuration Audit (PCA): This determines whether all items
identified as part of the configuration are present in the product baseline.
IEEE defines physical configuration audit as An audit conducted to verify
that a configuration item, as built, conforms to the technical
Self-Instructional
164 Material
 documentation that defines it. This audit should establish the accurate Configuration
Management
version of each part included in the product baseline and should correspond
to information in the configuration status reporting.
 Functional Configuration Audit (FCA): This ensures that all software
NOTES
items have been inspected to determine whether they satisfy the functions
defined in the specifications. IEEE defines functional configuration audit as
An audit conducted to verify that the development of a configuration
item has been completed satisfactorily, that the item has achieved the
performance and functional characteristics specified in the functional
or allocated configuration identification and that its operational and
support documents are complete and satisfactory.
An important aspect of these two audits is that all documentation (change
requests, test data, and reports) relevant to the release is current and complete.
Note that in large software projects, audits are necessary throughout the evolution
of a product to ensure conformity with planned configuration management actions
and to prevent significant problems that are encountered prior to the release of the
project.
Configuration Status Accounting
Configuration status accounting, also known as configuration status reporting,
refers to recording and reporting the changes to be incorporated in the work
product. IEEE defines configuration status accounting as An element of
configuration management consisting of the recording and reporting of
information needed to manage a configuration effectively. This information
includes a listing of the approved configuration identification, the status of
proposed changes to the configuration, and the implementation status of
approved (or disapproved) changes.
The objective of configuration status accounting is to maintain a continuous
record of the status of the configuration items and proposed changes to them. This
includes maintaining reports of traceability (ability to trace the application or location
of an item or activity by a means of recorded identification) of the changes to
baselines throughout software development. Configuration status accounting
specifies what changes are to be made to the system and how many files are
affected with the problem. It includes the following activities.
 Tracking the status of configuration items
 Generating the status report
 Determining the reports required
The configuration status reporting in SCM should consider some important
aspects while the report is being prepared. These aspects are described below:
 Status of a Configuration Item: This helps the developer to know
whether the baseline is approved. The project manager keeps track of
Self-Instructional
Material 165
Configuration the progress of the project as the baselines are reviewed, approved,
Management
tested and integrated.
 New Version of the System: As the project progresses, newer versions
of the product are developed. These versions include the document,
NOTES
which describes the changes such as enhancement of the previous version
of the product.

8.4 GOALS OF SOFTWARE CONFIGURATION

MANAGEMENT (Scm)

The goals of Software Configuration Management (SCM) are generally:

 Configuration Identification - Identifying configurations, configuration
items and baselines.
 Configuration Control - Implementing a controlled change process. This
is usually achieved by setting up a change control board whose primary
function is to approve or reject all change requests that are sent against any
baseline.
 Configuration Status Accounting - Recording and reporting all the
necessary information on the status of the development process.
 Configuration Auditing - Ensuring that configurations contain all their
intended parts and are sound with respect to their specifying documents,
including requirements, architectural specifications and user manuals.
 Build Management - Managing the process and tools used for builds.
 Process Management - Ensuring adherence to the organization’s
development process.
 Environment Management - Managing the software and hardware that
host the system.
 Teamwork - Facilitate team interactions related to the process.
 Defect Tracking - Making sure every defect has traceability back to the
source.

Check Your Progress

3. What is software configuration management plan?
4. Give the definition of configuration identification according to IEEE.
5. Explain the term change control.
6. Elaborate on the term version control.
7. Define the term Configuration status accounting.

Self-Instructional
166 Material
 Configuration
8.5 ANSWERS TO CHECK YOUR PROGRESS Management

QUESTIONS

1. IEEE defines software configuration management as the process of identifying NOTES

and defining components in a system, controlling the release and change
throughout the life cycle, recording and reporting the status of components
and change requests, and verifying the completeness and correctness of
system components.
2. Baseline as a specification or product that has been formally reviewed and
agreed upon, that thereafter serves as the basis for further development,
and that can be changed only through formal change control procedure.
3. The activities to be performed in software configuration management should
be planned in a proper manner. For this, a plan known as Software
Configuration Management Plan (SCMP).
4. IEEE defines configuration identification as an element of configuration
management, consisting of selecting the configuration items for a system
and recording their functional and physical characteristics in technical
documentation.
5. Change control is a process used to describe, review, and support the
changes made to software under software configuration management. It
ensures that the intermediate product is changed according to the identified
changes. Various software configuration tools are used to manage changes
so that they are done in a controlled manner.
6. Version control is a process of maintaining and tracking versions of the
project. This includes identification and managing configuration items, which
change overtime. This control is essential because without this, it becomes
difficult to maintain record of changes, version number, and its link with
other configuration items.
7. Configuration status accounting as an element of configuration management
consisting of the recording and reporting of information needed to manage a
configuration effectively. This information includes a listing of the approved
configuration identification, the status of proposed changes to the configuration,
and the implementation status of approved (or disapproved) changes.

8.6 SUMMARY

 Software configuration management as the process of identifying and defining

components in a system, controlling the release and change throughout the
life cycle, recording and reporting the status of components and change
requests, and verifying the completeness and correctness of system
components.
Self-Instructional
Material 167
Configuration  Configuration item as an aggregation of hardware, software, or both that is
Management
designated for configuration management and treated as a single entity in
the configuration management process.
 Baseline as a specification or product that has been formally reviewed and
NOTES
agreed upon, that thereafter serves as the basis for further development,
and that can be changed only through formal change control procedure.
 Software configuration management is different from software development
life cycle in terms of handling changes. SDLC can handle only normal
changes, like changes in requirement during the requirement phase or changes
in coding during the coding phase.
 The activities to be performed in software configuration management should
be planned in a proper manner. For this, a plan known as Software
Configuration Management Plan (SCMP).
 A software configuration plan should include a configuration database or
repository to keep a record of configuration information.
 The major objective of software configuration management is to determine
the items that collectively manage changes in one or more configuration items.
 SCM should also help in developing various versions of software and maintain
the quality of the software as the configuration evolves over time.
 IEEE defines configuration identification as an element of configuration
management, consisting of selecting the configuration items for a system
and recording their functional and physical characteristics in technical
documentation.
 Change control is a process used to describe, review, and support the
changes made to software under software configuration management. It
ensures that the intermediate product is changed according to the identified
changes. Various software configuration tools are used to manage changes
so that they are done in a controlled manner.
 Version control is a process of maintaining and tracking versions of the
project. This includes identification and managing configuration items, which
change over time.
 Version control is essential because without this, it becomes difficult to
maintain a record of changes, version number, and its link with other
configuration items.
 The configuration audit ensures that all change requests are accomplished
and are according to the established SCM processes and procedures. This
audit affirms whether the developed product is in accordance with the
requirements and conforms to the established standards conforms to the
established standards
 Auditing is performed by the auditor(s), as a part of the review process in
Self-Instructional SCM. The auditor(s) evaluates previous change and ensures that they are
168 Material
 in accordance with SCM procedures. These procedures are evaluated to Configuration
Management
ensure that the SCM goals are met.
 The configuration audits are of two types, namely, informal and formal. The
informal configuration audit is carried out during different phases of the
NOTES
software life cycle. The formal configuration audit is performed before the
release of a product baseline.
 IEEE defines functional configuration audit as an audit conducted to verify
that the development of a configuration item has been completed satisfactorily,
that the item has achieved the performance and functional characteristics
specified in the functional or allocated configuration identification and that
its operational and support documents are complete and satisfactory.
 IEEE defines configuration status accounting as an element of configuration
management consisting of the recording and reporting of information needed
to manage a configuration effectively. This information includes a listing of
the approved configuration identification, the status of proposed changes
to the configuration, and the implementation status of approved (or
disapproved) changes.
 Defect tracking making sure every defect has traceability back to the source.

8.7 KEY WORDS

 Software configuration item: The smallest unit of change.

 Baseline: A collection of software configuration items which have been
approved after carrying out formal technical reviews.
 Configuration identification: The process identifying configurations,
configuration items and baselines.
 Change control: A process or procedure used to describe, review and
support the changes made to software under software configuration
management.
 Version control: A process of maintaining and tracking versions of a project.
 Configuration status accounting - Recording and reporting all the
necessary information on the status of the development process.

8.8 SELF ASSESSMENT QUESTIONS AND

EXERCISES

Short-Answer Questions
1. Explain the term software configuration items.
2. Define the term software development life cycle.
Self-Instructional
Material 169
Configuration 3. Differentiate between SDLC and SCM.
Management
4. State about the project library.
5. What is configuration identification?
NOTES 6. State about the configuration status accounting.
Long-Answer Questions
1. Briefly explain the software configuration management with the help of
diagram.
2. Discuss about the baselines with the help of diagram.
3. Describe the change control with the help of diagram and examples.
4. Briefly explain the software configuration management plan with the help of
examples.
5. Differentiate between version control and change control giving appropriate
examples.
6. Briefly explain the configuration audit and its types giving appropriate
examples.
7. Discuss about the goals of Software Configuration Management (SCM).

8.9 FURTHER READINGS

Hughes, Bob, Mike Cotterell and Rajib Mall. 2017. Software Project
Management (SIE), 6th Edition. New York: McGraw Hill Education.
Schach, Stephen R. 2005. Object Oriented and Classical Software Engineering.
New Delhi: Tata McGraw-Hill.
Pressman, Roger S. 1997. Software Engineering, a Practitioner’s Approach.
New Delhi: Tata McGraw-Hill.
Somerville, Ian. 2001. Software Engineering. New Delhi: Pearson Education.
Ghezzi, Carlo, Mehdi Jazayeri, and Dino Mandriolli. 1991. Fundamentals of
Software Engineering. New Delhi: Prentice-Hill of India.
Jawadekar, Waman S. 2004. Software Engineering: Principles and Practice.
New Delhi: Tata McGraw-Hill.
Jalote, Pankaj. 1991. An Integrated Approach to Software Engineering. New
Delhi: Narosa Publishing House.

Self-Instructional
170 Material
 Team Development and
BLOCK - III Conflict Management

SCM CONCEPTS & TEAM DEVELOPMENT

NOTES
UNIT 9 TEAM DEVELOPMENT
AND CONFLICT
MANAGEMENT
Structure
9.0 Introduction
9.1 Objectives
9.2 Team Development and Conflict Management: Basic Concepts
9.2.1 Conflict Management
9.3 Organization Types and Control Systems
9.3.1 Centralized Control Team Organization
9.3.2 Decentralized Control Team Organization
9.3.3 Mixed Control Team Organization
9.4 Answers to Check Your Progress Questions
9.5 Summary
9.6 Key Words
9.7 Self Assessment Questions and Exercises
9.8 Further Readings

9.0 INTRODUCTION

Team management is the ability of an individual or an organization to administer

and coordinate a group of individuals to perform a task. Team management involves
teamwork, communication, objective setting and performance appraisals.
Moreover, team management is the capability to identify problems and resolve
conflicts within a team. There are various methods and leadership styles a team
manager can take to increase personnel productivity and build an effective team.
In the workplace, teams can come in many shapes and sizes who all work together
and depend on one another. They communicate and all strive to accomplish a
specific goal. Management teams are a type of team that performs duties, such as
managing and advising other employees and teams that work with them. Whereas
work, parallel, and project teams hold the responsibility of direct accomplishment
of a goal, management teams are responsible for providing general direction and
assistance to those teams.
Conflict management is the process of limiting the negative aspects of conflict
while increasing the positive aspects of conflict. The aim of conflict management is
to enhance learning and group outcomes, including effectiveness or performance
in an organizational setting. Properly managed conflict can improve group outcomes.
Self-Instructional
Material 171
Team Development and Conflict resolution involves the reduction, elimination, or termination of all forms
Conflict Management
and types of conflict. Five styles for conflict management, as identified by Thomas
and Kilmann, are competing, compromising, collaborating, avoiding, and
accommodating. Businesses can be benefited from appropriate types and levels
NOTES of conflict. Conflict management minimizes the negative outcomes of conflict and
promotes the positive outcomes of conflict with the goal of improving learning in
an organization. Properly managed conflict increases organizational learning by
increasing the number of questions asked and encourages people to challenge the
status quo.
There are three orientations to conflict, namely lose-lose, win-lose and win-
win. Basically, lose-lose orientation is a type of conflict that tends to end negatively
for all parties involved. A win-lose orientation results in one victorious party, usually
at the expense of the other. The win-win orientation is one of the most essential
concepts to conflict resolution. A win-win solution arrived at by integrative
bargaining may be close to optimal for both parties. This approach engages in a
cooperative approach rather than a competitive one.
Organizational conflict, or workplace conflict, is a state of discord caused
by the actual or perceived opposition of needs, values and interests between people
working together. Conflict takes many forms in organizations. There is the inevitable
clash between formal authority and power and those individuals and groups affected.
There are disputes over how revenues should be divided, how the work should
be done, and how long and hard people should work. There are jurisdictional
disagreements among individuals, departments, and between unions and
management. There are subtler forms of conflict involving rivalries, jealousies,
personality clashes, role definitions, and struggles for power and favor. There is
also conflict within individuals – between competing needs and demands – to
which individuals respond in different ways.
In this unit, you will study about the team development and conflict
management, basic concepts, organization types, centralized - control team
organization, decentralized - control team organization, mixed - control team
organization, case studies on open-source development team organization, Nokia
software factories, team discipline and conflict management.

9.1 OBJECTIVES

After going through this unit, you will be able to:

 Understand the concept of team development and conflict management
 Elaborate on the organization types
 Explain the basic concepts of control team organization for centralized,
decentralized and mixed organization types
 Analyse the concept based on case studies
Self-Instructional
172 Material
 Team Development and
9.2 TEAM DEVELOPMENT AND CONFLICT Conflict Management

MANAGEMENT: BASIC CONCEPTS

A team is a group of individuals (human or non-human) working together to achieve NOTES

their goal. As defined by Professor Leigh Thompson of the Kellogg School of
Management, “A team is a group of people who are interdependent with respect
to information, resources, knowledge and skills and who seek to combine their
efforts to achieve a common goal”. A group does not necessarily constitute a
team. Teams normally have members with complementary skills and generate
synergy through a coordinated effort which allows each member to maximize their
strengths and minimize their weaknesses. Naresh Jain (2009) claims, “Team
members need to learn how to help one another, help other team members realize
their true potential, and create an environment that allows everyone to go beyond
their limitations”.
Team building or team development is a collective term for various types of
activities used to enhance social relations and define roles within teams, often
involving collaborative tasks. Several team building exercises aim to expose and
address interpersonal problems within the group. Team development or building is
one of the foundations of organizational development that can be applied to groups,
such as sports teams, school classes, military units or flight crews. The formal
definition of team building includes aligning around goals, building effective working
relationships, reducing team members’ role ambiguity and finding solutions to team
problems. Subsequently, the team development or building is one of the most
widely used group development activities in the organizations.
The effectiveness of team building differs substantially from one organization
to another. The most effective efforts occur when team members are interdependent,
knowledgeable and experienced and when organizational leadership actively
establishes and supports the team. Effective team building incorporates an awareness
of team objectives. Teams must work to develop goals, roles and procedures. As
a result, team building is usually associated with increasing task accomplishment,
goal meeting, and achievement of results within teams.
Goal setting and role clarification have the greatest impact because they
enhance motivation, reduce conflict and help to set individual purposes, goals and
motivation. Team building in organizations is a common approach to improving
performance.
Team development and management is the ability of an individual or an
organization to administer and coordinate a group of individuals to perform a task.
Team management involves teamwork, communication, objective setting and
performance appraisals. Moreover, team management is the capability to identify
problems and resolve conflicts within a team. There are various methods and
leadership styles a team manager can take to increase personnel productivity and
build an effective team. In the workplace teams can come in many shapes and
Self-Instructional
Material 173
Team Development and sizes who all work together and depend on one another. They communicate and
Conflict Management
all strive to accomplish a specific goal. Management teams are a type of team that
performs duties such as managing and advising other employees and teams that
work with them. Whereas work, parallel, and project teams hold the responsibility
NOTES of direct accomplishment of a goal, management teams are responsible for
providing general direction and assistance to those teams.
Essentials of a Strong and Successful Team
Following are the significant elements of a strong and successful team.
Cohesive Leadership: In any functional team, cohesion amongst team
leaders and decision makers is vital. Cohesive leadership means that team leaders
act together as a unit and make decisions as a team instead of each branching off
into their own work and operating individually. Cohesive leadership will require
team leaders to have strong communication skills.
Effective Communication: There must be an effective channel of
communication from the top to the bottom of the chain of command and vice
versa. An effective channel of communication will allow messages to be transferred
accurately without delay to the intended recipient, which will speed up decision
making processes and the operations of the team.
Common Goal: When team members first come together they will each
bring different ideas; however, the key to a successful team is the alignment of its
objectives. It is essential that the team leader sets a common goal the entire team
is willing to pursue. In other cases, team members might divert themselves to other
tasks due to a lack of belief or interest in the goal.
Defined Team Roles and Responsibilities: Poorly defined roles are
often the biggest obstacle to a successful team. If team members are unclear what
their role is, their contributions will be minimal, therefore it is the team leader’s
duty to outline the roles and responsibilities of each individual within the team and
ensure that they work together as an integral unit. The leader identify the strengths
and weaknesses of the team members and assign roles accordingly. Individuals in
a team can take on different roles that have their own unique responsibilities.
Methods of Team Management
Following are some significant methods of team management:
Command and Control: The ‘Command and Control’ method as an
approach to team management is based on the concept of military management. It
was a commonly used system in the private sector during the 21st century. In this
method, the team leader instructs their team members to complete a task and if
they refuse, they will punish employees until they comply. The team leader has
absolute authority and utilises an autocratic leadership style.
Engage and Create: Due to the limitations and ineffectiveness of the
‘Command and Control’ method, managers developed an alternative management
strategy known as ‘Engage and Create’. In this method, team members are
Self-Instructional encouraged to participate in discussions and contribute. Furthermore, they are
174 Material
advised to engage with other team members to build a stronger sense of teamwork Team Development and
Conflict Management
and unity. This leads to increased productivity and accountability, driving the team
towards success.
Econ 101: In the ‘Econ 101’ method of team management, the team leader
NOTES
makes the baseline assumption that all team members are motivated by reward in
the form of money, and that the best way to manage the team is to provide financial
rewards for performance and issue punishments for failure. This method of team
management uses material gains in the place of intrinsic motivation to support and
motivate team members. This is analogous to Frederick Taylor’s theory of scientific
management which specifies that the key form of motivation for employees is
money. The main drawback of this method is that it does not take into account
other forms of motivation besides money, such as personal satisfaction and ambition.
The goal or aim of group development is to analyse why and how small
groups change over time. Basically, it specifies the quality of the output produced
by a group, the type and frequency of its activities, its cohesiveness, and the
existence of group conflict.
Tuckman’s Stages of Group Development
The ‘Forming–Storming–Norming–Performing’ model (Refer Figure 9.1) of group
development was first proposed by Bruce Tuckman in 1965, who said that these
phases are all essential and inevitable in order for a team to grow, face up to
challenges, tackle problems, find solutions, plan work and deliver results.

Fig. 9.1 Tuckman’s Stages of Group Development

Forming: The team meets and learns about the opportunities and challenges,
and then agrees on goals and begins to tackle the tasks. Team members tend to
behave quite independently. The meeting environment also plays an important role
to model the initial behavior of each individual. Self-Instructional
Material 175
Team Development and Storming: This is the second stage of team development, where the group
Conflict Management
starts to sort itself out and gain each other’s trust. This stage normally starts when
the team voice their opinions; conflict may arise between team members as power
and status are assigned. When group members start to work with each other they
NOTES start learning about specific member’s working styles.
Norming: Resolved disagreements and personality clashes result in greater
closeness and hence a spirit of co-operation develops. This happens when the
team is aware of competition and they share a common goal. In this stage, all team
members take responsibility and have the ambition to work for the success of the
team’s goals. They tolerate the whims and fancies of the other team members.
Performing: With group or team norms and roles established, group or
team members focus on achieving common goals, generally reaching an
unexpectedly high level of success. By this time, the team or group members are
motivated and knowledgeable. The team members become competent, autonomous
and able to handle the decision-making process without supervision. Dissent or
disagreement is expected and acceptable as long as it is channeled or directed
through the means acceptable to the team members.
Adjourning: In 1977, Tuckman, jointly with Mary Ann Jensen, added a
fifth stage ‘Adjourning’ to the existing four stages. Adjourning involves completing
the task and breaking up the team, in some texts referred to as ‘Mourning’. After
revisiting the original model and reviewing the literature, they concluded that a
significant step in the small group life cycle was the ultimate separation which
typically occurred at the end of this cycle.
9.2.1 Conflict Management
Conflict management is the process of limiting the negative aspects of conflict
whereas increasing the positive aspects of conflict. The aim of conflict management
is to enhance learning and group outcomes, including effectiveness or performance
in an organizational setting. Properly managed conflict can improve group outcomes.
Organizational conflict or workplace conflict, is a state of discord caused
by the actual or perceived opposition of needs, values and interests between people
working together. Conflict takes many forms in organizations. There is the inevitable
clash between formal authority and power and those individuals and groups affected.
There are disputes over how revenues should be divided, how the work should be
done, and how long and hard people should work. There are jurisdictional
disagreements among individuals, departments, and between unions and
management. There are understated forms of conflict involving rivalries, jealousies,
personality clashes, role definitions, and struggles for power and favour. There is
also conflict within individuals, between competing needs and demands, to which
individuals respond in different ways.
Definition of Conflict Management: Conflict management refers to
techniques and concepts specifically designed to reduce or decrease the negative
Self-Instructional effects of conflict and to enhance or improve the positive outcomes for all parties
176 Material
involved. Conflict management is, basically, the practice of being capable to identify Team Development and
Conflict Management
or recognize and handle conflicts reasonably, sensibly, properly, and efficiently.
Since conflicts in a business are a normal and expected part of the workplace, it is
significant that there are people in the organisation who comprehend conflicts and
recognize how to resolve them. NOTES
The techniques and concepts used depend on the type of conflict that needs
managing researchers differentiate between affective (relational) and substantive
(performance, process or task-specific) conflict, as well as inter-organisational
conflict (between two or more businesses) and intra-organisational (conflict within
organisations).
Conflict Resolution
Conflict resolution includes the decrease, abolition, elimination, end or termination
of all forms and types of conflict. Thomas and Kilmann had identified five styles
for conflict management, which are competing, compromising, collaborating,
avoiding and accommodating.
Conflict management minimizes or reduces the negative consequences or
outcomes of conflict and stimulates or promotes the positive consequences or
outcomes of conflict with the goal or aim of improving learning in an organization.
Appropriately managed conflict increases organizational learning by increasing the
number of questions asked and motivates or stimulates people to challenge the
status quo.
Organizational conflict at the interpersonal level includes disputes between
peers as well as supervisor-subordinate conflict. Party-Directed Mediation (PDM)
is a mediation approach particularly suited for disputes between co-workers,
colleagues or peers, especially deep-seated interpersonal conflict, multicultural or
multiethnic disputes. Some unique challenges are observed when organizational
disputes involve supervisors and subordinates. The Negotiated Performance
Appraisal (NPA) is a tool to improve communication between supervisors and
subordinates.
Orientations to Conflict
There are three orientations to conflict, which are referred as lose-lose orientation,
win-lose orientation, and win-win orientation. Typically, lose-lose orientation is a
type of conflict that tends to end negatively for all teams or groups involved. A
win-lose orientation results in one successful event, usually at the expense of the
other. The win-win orientation is one of the most essential concepts to conflict
resolution. A win-win solution attained at by integrative bargaining may be close to
optimal for the teams or groups. This approach engages in a cooperative approach
rather than a competitive one.
Conflict Management Models
Blake and Mouton (1964) first presented a conceptual system for classifying the
modes (styles) to handle interpersonal conflicts in five types, namely forcing,
withdrawing, smoothing, compromising and problem solving. Self-Instructional
Material 177
Team Development and In the 1970s and 1980s, researchers initiated using the intentions of the
Conflict Management
teams or groups involved to classify the styles of conflict management that they
included in their models.
Both Thomas (1976) and Pruitt (1983) put forth a model based on the
NOTES
concerns of the teams or groups involved in the conflict. The teams or groups are
concerned for their own interests, i.e., assertiveness and also concerned for their
cooperativeness yielded a specific conflict management style. Pruitt claims that
problem solving is the preferred method when seeking mutually beneficial options
(win-win).
Khun and Poole’s Model: Khun and Poole (2000) established an
analogous system of group conflict management. In the Khun and Poole system,
the Kozan’s confrontational model is split into two sub-models, namely the
distributive and the integrative. In the ‘Distributive’ model, the conflict is approached
as a distribution of a fixed amount of positive outcomes or resources, where one
side will end up winning and the other losing, even if they do win some concessions.
In the ‘Integrative’ model, the teams or groups utilising the integrative model
perceive or observe conflict as a chance to integrate the requirements and concerns
of teams or groups in order to obtain the best possible outcome or consequences.

9.3 ORGANIZATION TYPES AND CONTROL

SYSTEMS

Organizations can be structured in different ways. The structure of an organization

determines and regulates how the organization operates, functions and performs.
Additionally, to create an appropriate and proper organizational structure, the
competent and effective executing strategy is required which depends on the skillful
and expert use of organizational control systems. The executive members of the
organization create proper operational strategies in order to achieve their
organization’s vision, mission, and goals. The control systems in an organization
help the executives to track the performance of the organization, to identify areas
of concern or problems, and then accordingly decide the competent actions to
address the concerns or problems. Following are some significant control systems
which appropriately define that how each of the control systems of an organization
works for its smooth functioning.
9.3.1 Centralized Control Team Organization
Centralization is the process by which the activities of an organization, particularly
those regarding planning and decision-making, framing strategy and policies become
concentrated within a particular geographical location group. This moves the
important decision-making and planning powers within the center of the organization.
Centralized control team organization is considered as a standard
management technique which specifies assumed disciplines. In this mode of
Self-Instructional organization control system, several workers report to a supervisor who directly
178 Material
controls their tasks and is responsible for their performance. Centralized control is Team Development and
Conflict Management
based on a hierarchical organizational structure in which the supervisors directly
report to a ‘Second-Level’ manager, the second-level manager reports to the top
manager of the enterprise, and so on.
NOTES
In software development department, the centralize control of a software
development team is through chief programmer team. In this type of organization,
the control structure includes one engineer, known as the chief programmer, is
responsible for the design and all the technical details of the project.
The chief programmer reports to a peer project manager who is responsible
for the administrative aspects of the project. Other members of the team, such as
software programmers can be added to the team on a temporary basis when
required. Specialists may be called as consultants to the team. The need for
programmers and consultants, as well as what tasks they perform is determined
by the chief programmer, who initiates and controls all decisions.
Advantages of Centralized Control
The following are the advantages of centralized control.
Clear Chain of Command: A centralized organization works on a clear
chain of command because every employee within the organization knows who to
report to. The executives delegate the responsibilities to mid-level managers and
other employees such that there will be no overlap. A clear chain of command is
useful when the organization needs to execute decisions quickly and in a unified
manner.
Focused Vision: When an organization follows a centralized management
structure, it focuses on the success of its vision with ease. There are specific perfect
lines of communication and the senior executives communicate the organization’s
vision to employees and also guide them toward the achievement of the vision. In
the absence of centralized management, there will be inconsistencies in
communicating the message to employees because there are no specific perfect
lines of authority. Directing the organization’s vision from the top level of management
permits for a smooth implementation of its visions and strategies. The
organization’s stakeholders, such as customers, suppliers, and communities also
receive a uniform message.
Reduced Costs: A centralized organization adheres to standard procedures
and methods that guide the organization, which helps in reducing the office and
administrative costs. For example, the key decision-makers are accommodated
at the company’s head office or headquarters, and therefore, there is no need for
deploying more departments or sections to other respective branches. Furthermore,
the organization not requires to incur extra costs for hiring the specialists for its
branches since the critical decisions are first made at the head office and then
communicated to the other branches. This specific chain of command helps in
reducing the duplication of responsibilities that may result in additional costs to the
organization.
Self-Instructional
Material 179
Team Development and Quick Implementation of Decisions: In a centralized organization,
Conflict Management
decisions are made by a small group of people and then communicated to the
lower-level managers. Because only a few people are involved, hence the decision-
making process is more efficient since the executives can discuss the details of
NOTES each decision in one meeting. The final decisions are then communicated to the
lower levels of the organization for implementation.
Disadvantages of Centralized Control
The following are the disadvantages of centralized control.
Bureaucratic Leadership: Centralized management in the organization is
similar to an authoritarian form of leadership where employees are simply expected
to provide results according to the commands and assignments given to them by
the top executives. Employees do not contribute to the organization’s decision-
making process, but they are only implementers of the decisions that are made at
a higher level. This method has great disadvantage, because when the employees
have difficulties in implementing some of the decisions, then the executives are not
able to understand and guide them because they are only the decision-makers and
not the practical implementers of the decisions. Such actions have extreme declined
performance because the employees lack the motivation for implementing the
decisions taken by top-level managers without the input of lower-level employees,
who knows the practical real world problems.
Delays in Work: Centralized control results in delays in work due to the
reason that the records are sent to and from the head office. Employees depend
on the information communicated to them from the top level, which can cause loss
in man-hours if there is delay in sending the records. Consequently, the performance
and productivity of the employees will be less if they have to wait for long periods
to get guidance, direction and decisions on their projects.
Lack of Employee Loyalty: In the centralized control, the employees
have no initiative in work because the employees only perform tasks that is
conceptualized by top executives. This limits the creativity and loyalty of the
employee to the organization due to the rigidity of the work.
9.3.2 Decentralized Control Team Organization
Decentralization is the process by which the activities of an organization, particularly
those regarding planning and decision-making, are distributed or delegated away
from a central, authoritative location or group. In a decentralized control team
organization, decisions are made by consensus, and all work is considered group
work. Team members review each other’s work and are responsible as a group
for what every member produces. The patterns of control and communication
among team members in a decentralized control orga-nization. The ring like
management structure is intended to show the lack of a hierar-chy and that all
team members are at the same level. Such a ‘Democratic’ organization leads to
higher morale and job satisfaction and, therefore, to less turnover. The engineers
Self-Instructional
180 Material
feel more ownership of the project and responsibility for the problem, resulting in Team Development and
Conflict Management
higher quality in their work.
A decen-tralized control organization is more suited for long term projects,
because the amount of intragroup communication that it encourages leads to a
NOTES
longer develop-ment time, presumably accompanied by lower life cycle costs.
The proponents of this kind of team organization claim that it is more
appropriate for less understood and more complicated problems, since a group
can invent better solutions than a single individual can. Such an organization is
based on a technique referred to as ‘Egoless Programming,’ because it encourages
programmers to share and review one another’s work. On the negative side,
decentralized control team organization is not appropriate for large teams, where
the communication overhead can overwhelm all the engineers, reducing their
individual productivity.
Advantages of a Decentralized Control
Quick Decision and Response Times: It is important that the decisions
to be made and implemented in a timely manner. In order to remain competitive, it
is important for organizations to take advantage of opportunities that fit within the
organization’s strategy.
Improved Ability to Expand Company: It is important for organizations
to constantly explore new opportunities to expand the organization’s existing
structure and services in order to provide best quality goods and services to its
customers.
Skilled and/or Specialized Management: Organizations must endow in
developing highly skilled employees who are capable of making sound decisions
that help the organization in achieving its goals.
Increased Morale of Employees: The success of an organization depends
on its ability to acquire, improve and retain highly motivated employees.
Empowering employees for making correct decisions is the best way for increasing
the morale of the employee.
Link between Compensation and Responsibility: Promotional
opportunities of employees are generally linked with a corresponding increase in
compensation. In a decentralized organization, increase in compensation mostly
corresponds to a commensurate increase in the responsibilities associated with
learning new skills, increased decision-making authority, and supervision of other
employees.
Improved Lower and Middle Management: Many tasks are specifically
performed in order to achieve success in an organization. Decentralized
organizations often depend on the lower and middle level management to perform
most of the tasks. This helps managers in gaining valued experience, proficiency
and expertise in different areas.

Self-Instructional
Material 181
Team Development and Disadvantages of Decentralized Control
Conflict Management
Coordination Problems: It is significant for an organization to work toward
a common goal. Because in a decentralized organization, the decision-making is
delegated, hence it is normally difficult to ensure that all segments or departments
NOTES
of the company are working in a consistent manner in order to achieve the strategic
goals and objectives of the organization.
Increased Administrative Costs due to Duplication of Efforts: Because
similar decisions have to be made and the activities commenced across all divisions
or sections of an organization, hence the decentralized organizations are susceptible
to duplicating efforts, which results in inefficiency and increased costs.
Incongruity in Operations: In the decentralized organizations, when
autonomy is dispersed throughout the various divisions or sections of organization,
then the division managers can customize/alter the operations of the divisions or
sections to maximize the efficiency or proficiency that is best for the divisions or
sections. In decentralized structure, it is significant to ensure that the shortcuts
taken by one division or section of the organization do not conflict with or disrupt
the operations of another division or section within the organization.
Dependence on the Divisional or Department Managers: Because
divisions or sections within decentralized organizations have a high level of autonomy,
hence the division or section may become operationally isolated from other divisions
or sections within the organization, concentrating exclusively on the priorities of
the division or section. If divisional or departmental managers do not have a wide
breadth of experience or skills, then the division may be at a disadvantage due to
limited access to other expertise.
9.3.3 Mixed Control Team Organization
A mixed control team organization attempts to combine the benefits of centralized
control and decentralized control, however minimizing or avoiding their
disadvantages. Rather than considering all members the equivalent, as in a
decentralized organization or considering in single individual as the chief executive
as in a centralized organization, the mixed organization differentiates the engineers
into two categories as senior engineers and junior engineers. Each senior engineer
leads a group of junior engineers and the senior engineer reports to the project
manager. Control is vested in the project manager and senior programmers, while
communication is decentralized among each set of individuals, peers and their
immediate supervisors.
A mixed mode organization tries to limit communication to within a group
that is most likely to benefit from it. It also tries to realize the benefits of group
decision-making by vesting authority in a group of senior programmers or architects.
The mixed control organization is an example of the use of a hierarchy to master
the complexity of software development as well as organizational structure.

Self-Instructional
182 Material
Advantages of Mixed Control Team Development and
Conflict Management
 Mixed control model organizational structures optimize employee experience
and resources and work well for organizations or enterprises that are project
based.
NOTES
 The mixed control structure can improve lines of communication and provide
flexibility for working on multiple projects.
 Employees working on special projects still have links to their functional
departments and can refer back to the other members of their departments
for consultation and advice.
Disadvantages of Mixed Control
 A major disadvantage to the mixed control organization is that it requires a
great deal and more coordination effort than other structures.
 Employees who have to report to more than one division or section leader
may have conflicting accountability. This can lead to conflict and stress for
the employees involved.
 Project leaders of mixed control organizations must have good conflict-
solving skills to cope with these difficulties.

Check Your Progress

1. What is a team?
2. Explain the team development concept.
3. Define the term conflict management.
4. What are the three orientations to conflict?
5. Elaborate on centralized control team organization.
6. What is decentralization?

9.4 ANSWERS TO CHECK YOUR PROGRESS

QUESTIONS

1. A team is a group of individuals (human or non-human) working together to

achieve their goal. As defined by Professor Leigh Thompson of the Kellogg
School of Management, “A team is a group of people who are interdependent
with respect to information, resources, knowledge and skills and who seek
to combine their efforts to achieve a common goal”.
2. Team building or team development is a collective term for various types of
activities used to enhance social relations and define roles within teams,
often involving collaborative tasks. The formal definition of team building
includes aligning around goals, building effective working relationships,
reducing team members’ role ambiguity and finding solutions to team
Self-Instructional
Material 183
Team Development and problems. Subsequently, the team development or building is one of the
Conflict Management
most widely used group development activities in the organizations. Team
development and management is the ability of an individual or an organization
to administer and coordinate a group of individuals to perform a task. Team
NOTES management involves teamwork, communication, objective setting and
performance appraisals.
3. Conflict management is the process of limiting the negative aspects of conflict
whereas increasing the positive aspects of conflict. The aim of conflict
management is to enhance learning and group outcomes, including
effectiveness or performance in an organizational setting. Properly managed
conflict can improve group outcomes.
Conflict management refers to techniques and concepts specifically designed
to reduce or decrease the negative effects of conflict and to enhance or
improve the positive outcomes for all parties involved. Conflict management
is, basically, the practice of being capable to identify or recognize and handle
conflicts reasonably, sensibly, properly, and efficiently.
4. There are three orientations to conflict, which are referred as lose-lose
orientation, win-lose orientation, and win-win orientation. Typically, lose-
lose orientation is a type of conflict that tends to end negatively for all teams
or groups involved. A win-lose orientation results in one successful event,
usually at the expense of the other. The win-win orientation is one of the
most essential concepts to conflict resolution. A win-win solution attained
at by integrative bargaining may be close to optimal for the teams or groups.
This approach engages in a cooperative approach rather than a competitive
one.
5. Centralized control team organization is considered as a standard
management technique which specifies assumed disciplines. In this mode of
organization control system, several workers report to a supervisor who
directly controls their tasks and is responsible for their performance.
Centralized control is based on a hierarchical organizational structure in
which the supervisors directly report to a ‘Second-Level’ manager, the
second-level manager reports to the top manager of the enterprise, and so
on.
6. Decentralization is the process by which the activities of an organization,
particularly those regarding planning and decision-making, are distributed
or delegated away from a central, authoritative location or group. In a
decentralized-control team organization, decisions are made by consensus,
and all work is considered group work.

Self-Instructional
184 Material
 Team Development and
9.5 SUMMARY Conflict Management

 A team is a group of individuals (human or non-human) working together to

achieve their goal. NOTES
 As defined by Professor Leigh Thompson of the Kellogg School of
Management, “A team is a group of people who are interdependent with
respect to information, resources, knowledge and skills and who seek to
combine their efforts to achieve a common goal”.
 Teams normally have members with complementary skills and generate
synergy through a coordinated effort which allows each member to maximize
their strengths and minimize their weaknesses.
 Team building or team development is a collective term for various types of
activities used to enhance social relations and define roles within teams,
often involving collaborative tasks.
 The formal definition of team building includes aligning around goals, building
effective working relationships, reducing team members’ role ambiguity and
finding solutions to team problems. Subsequently, the team development or
building is one of the most widely used group development activities in the
organizations.
 Goal setting and role clarification have the greatest impact because they
enhance motivation, reduce conflict and help to set individual purposes,
goals and motivation. Team building in organizations is a common approach
to improving performance.
 Team development and management is the ability of an individual or an
organization to administer and coordinate a group of individuals to perform
a task.
 Team management involves teamwork, communication, objective setting
and performance appraisals. Moreover, team management is the capability
to identify problems and resolve conflicts within a team.
 In any functional team, cohesion amongst team leaders and decision makers
is vital. Cohesive leadership means that team leaders act together as a unit
and make decisions as a team instead of each branching off into their own
work and operating individually. Cohesive leadership will require team
leaders to have strong communication skills.
 The ‘Command and Control’ method as an approach to team management
is based on the concept of military management. It was a commonly used
system in the private sector during the 21st century.
 In ‘Command and Control’ method, the team leader instructs their team
members to complete a task and if they refuse, they will punish employees
until they comply. The team leader has absolute authority and utilises an
autocratic leadership style. Self-Instructional
Material 185
Team Development and  In the ‘Econ 101’ method of team management, the team leader makes the
Conflict Management
baseline assumption that all team members are motivated by reward in the
form of money, and that the best way to manage the team is to provide
financial rewards for performance and issue punishments for failure. This
NOTES method of team management uses material gains in the place of intrinsic
motivation to support and motivate team members.
 The ‘Forming–Storming–Norming–Performing’ model of group
development was first proposed by Bruce Tuckman in 1965, who said that
these phases are all essential and inevitable in order for a team to grow,
face up to challenges, tackle problems, find solutions, plan work and deliver
results.
 Conflict management is the process of limiting the negative aspects of conflict
whereas increasing the positive aspects of conflict. The aim of conflict
management is to enhance learning and group outcomes, including
effectiveness or performance in an organizational setting. Properly managed
conflict can improve group outcomes.
 Conflict management refers to techniques and concepts specifically designed
to reduce or decrease the negative effects of conflict and to enhance or
improve the positive outcomes for all parties involved.
 Conflict management is, basically, the practice of being capable to identify
or recognize and handle conflicts reasonably, sensibly, properly, and
efficiently.
 Since conflicts in a business are a normal and expected part of the workplace,
it is significant that there are people in the organisation who comprehend
conflicts and recognize how to resolve them.
 The techniques and concepts used depend on the type of conflict that needs
managing researchers differentiate between affective (relational) and
substantive (performance, process or task-specific) conflict, as well as inter-
organisational conflict (between two or more businesses) and intra-
organisational (conflict within organisations).
 Conflict management minimizes or reduces the negative consequences or
outcomes of conflict and stimulates or promotes the positive consequences
or outcomes of conflict with the goal or aim of improving learning in an
organization.
 There are three orientations to conflict, which are referred as lose-lose
orientation, win-lose orientation, and win-win orientation.
 Typically, lose-lose orientation is a type of conflict that tends to end negatively
for all teams or groups involved.
 A win-lose orientation results in one successful event, usually at the expense
of the other.

Self-Instructional
186 Material
 The win-win orientation is one of the most essential concepts to conflict Team Development and
Conflict Management
resolution. A win-win solution attained at by integrative bargaining may be
close to optimal for the teams or groups. This approach engages in a
cooperative approach rather than a competitive one.
NOTES
 Khun and Poole (2000) established an analogous system of group conflict
management. In the Khun and Poole system, the Kozan’s confrontational
model is split into two sub-models, namely the distributive and the integrative.
 In the ‘Distributive’ model, the conflict is approached as a distribution of a
fixed amount of positive outcomes or resources, where one side will end up
winning and the other losing, even if they do win some concessions.
 In the ‘Integrative’ model, the teams or groups utilising the integrative model
perceive or observe conflict as a chance to integrate the requirements and
concerns of teams or groups in order to obtain the best possible outcome
or consequences.
 Organizations can be structured in different ways. The structure of an
organization determines and regulates how the organization operates,
functions and performs. Additionally, to create an appropriate and proper
organizational structure, the competent and effective executing strategy is
required which depends on the skillful and expert use of organizational control
systems.
 The executive members of the organization create proper operational
strategies in order to achieve their organization’s vision, mission, and goals.
 The control systems in an organization help the executives to track the
performance of the organization, to identify areas of concern or problems,
and then accordingly decide the competent actions to address the concerns
or problems.
 Centralized control team organization is considered as a standard
management technique which specifies assumed disciplines. In this mode of
organization control system, several workers report to a supervisor who
directly controls their tasks and is responsible for their performance.
 Centralized control is based on a hierarchical organizational structure in
which the supervisors directly report to a ‘Second-Level’ manager, the
second-level manager reports to the top manager of the enterprise, and so
on.
 Decentralization is the process by which the activities of an organization,
particularly those regarding planning and decision-making, are distributed
or delegated away from a central, authoritative location or group.
 In a decentralized control team organization, decisions are made by
consensus, and all work is considered group work.

Self-Instructional
Material 187
Team Development and  A mixed control team organization attempts to combine the benefits of
Conflict Management
centralized control and decentralized control, however minimizing or avoiding
their disadvantages.
 Rather than considering all members the equivalent, as in a decentralized
NOTES
organization or considering in single individual as the chief executive as in a
centralized organization, the mixed organization differentiates the engineers
into two categories as senior engineers and junior engineers.
 Each senior engineer leads a group of junior engineers and the senior engineer
reports to the project manager. Control is vested in the project manager
and senior programmers, while communication is decentralized among each
set of individuals, peers and their immediate supervisors.

9.6 KEY WORDS

 Team: A team is a group of individuals (human or non-human) working

together to achieve their goal. As defined by Professor Leigh Thompson of
the Kellogg School of Management, “A team is a group of people who are
interdependent with respect to information, resources, knowledge and skills
and who seek to combine their efforts to achieve a common goal”.
 Team development: Team development and management is the ability of
an individual or an organization to administer and coordinate a group of
individuals to perform a task. Team management involves teamwork,
communication, objective setting and performance appraisals.
 Conflict management: Conflict management is the process of limiting the
negative aspects of conflict whereas increasing the positive aspects of conflict.
The aim of conflict management is to enhance learning and group outcomes,
including effectiveness or performance in an organizational setting. Properly
managed conflict can improve group outcomes.
 Win-win orientation: The win-win orientation is one of the most essential
concepts to conflict resolution. A win-win solution attained at by integrative
bargaining may be close to optimal for the teams or groups. This approach
engages in a cooperative approach rather than a competitive one.

9.7 SELF-ASSESSMENT QUESTIONS AND

EXERCISES

Short-Answer Questions
1. Explain the term team development.
2. Define the term effective communication.
3. What is conflict management?
Self-Instructional
188 Material
 4. What does conflict resolution includes? Team Development and
Conflict Management
5. Elaborate on the organization types.
6. State about the centralized control team organization.
7. Define about the decentralized control team organization. NOTES
8. What is mixed control team organization?
Long-Answer Questions
1. Briefly discuss the basic concept of team development giving appropriate
examples.
2. Explain the significant elements of a strong and successful team with the
help of examples.
3. Elaborate on the methods of team management.
4. Briefly discuss the Tuckman’s stages of group development.
5. Discuss in detail the concept and theories of conflict management.
6. Explain about the conflict resolution, orientations to conflict and conflict
management models giving appropriate examples.
7. Describe the basic concepts of organization types giving examples.
8. Elaborate on the centralized control team organization giving advantages
and disadvantages.
9. Discuss about the decentralized control team organization and mixed control
team organization giving advantages and disadvantages.

9.8 FURTHER READINGS

Hughes, Bob, Mike Cotterell and Rajib Mall. 2017. Software Project
Management (SIE), 6th Edition. New York: McGraw Hill Education.
Schach, Stephen R. 2005. Object Oriented and Classical Software Engineering.
New Delhi: Tata McGraw-Hill.
Pressman, Roger S. 1997. Software Engineering, a Practitioner’s Approach.
New Delhi: Tata McGraw-Hill.
Somerville, Ian. 2001. Software Engineering. New Delhi: Pearson Education.
Ghezzi, Carlo, Mehdi Jazayeri, and Dino Mandriolli. 1991. Fundamentals of
Software Engineering. New Delhi: Prentice-Hill of India.
Jawadekar, Waman S. 2004. Software Engineering: Principles and Practice.
New Delhi: Tata McGraw-Hill.
Jalote, Pankaj. 1991. An Integrated Approach to Software Engineering. New
Delhi: Narosa Publishing House.

Self-Instructional
Material 189
Team Development and
Conflict Management CASE STUDY

1. OPEN-SOURCE SOFTWARE DEVELOPMENT - TEAM

NOTES ORGANIZATION
Open-Source Software Development (OSSD) is the process by which open-
source software, or similar software whose source code is publicly available, is
developed by an open-source software project. These are software products
available with its source code under an open-source license to study, change, and
improve its design. Examples of some popular open-source software products
are Mozilla Firefox, Google Chromium, Android, LibreOffice and the VLC media
player.
In 1997, Eric S. Raymond wrote “The Cathedral and the Bazaar”. In this
book, Raymond makes the distinction between two kinds of software development.
The first is the conventional closed-source development. This kind of development
method is, according to Raymond, like the building of a cathedral; central planning,
tight organization and one process from start to finish. The second is the progressive
open-source development, which is more like “A great babbling bazaar of differing
agendas and approaches out of which a coherent and stable system could seemingly
emerge only by a succession of miracles”. The latter analogy points to the discussion
involved in an open-source development process.
Open Source
Open source is source code that is made freely available for possible modification
and redistribution. Products include permission to use the source code, design
documents, or content of the product. It most commonly refers to the open-source
model, in which open-source software or other products are released under an
open-source license as part of the open-source-software movement.
The open-source model is a decentralized software development model
that encourages open collaboration, meaning “Any system of innovation or
production that relies on goal-oriented yet loosely coordinated participants who
interact to create a product (or service) of economic value, which they make
available to contributors and non-contributors alike”. The key principle of open-
source software development is peer production, with products, such as source
code, blueprints, and documentation freely available to the public. The open-source
movement in software began as a response to the limitations of proprietary code.
The open-source model for software development inspired the use of the
term to refer to other forms of open collaboration, such as in Internet forums,
mailing lists and online communities. Open collaboration is also thought to be the
operating principle underlining a gamut of diverse ventures, including TEDx and
Wikipedia.

Self-Instructional
190 Material
Open-Source License Team Development and
Conflict Management
Open source promotes universal access via an open-source or free license to a
product’s design or blueprint, and universal redistribution of that design or blueprint.
Before the phrase open source became widely adopted, developers and producers
NOTES
used a variety of other terms. Open source gained hold in part due to the rise of
the Internet. The open-source software movement arose to clarify copyright,
licensing, domain, and consumer issues.
An open-source license is a type of license for computer software and
other products that allows the source code, blueprint or design to be used, modified
or shared (with or without modification) under defined terms and conditions. This
allows end users and commercial companies to review and modify the source
code, blueprint or design for their own customization, curiosity or troubleshooting
needs.
Open-source licensed software is mostly available free of charge, though
this does not necessarily have to be the case. Licenses which only permit non-
commercial redistribution or modification of the source code for personal use only
are generally not considered as open-source licenses. However, open-source
licenses may have some restrictions, particularly regarding the expression of respect
to the origin of software, such as a requirement to preserve the name of the authors
and a copyright statement within the code, or a requirement to redistribute the
licensed software only under the same license (as in a copyleft license). One popular
set of open-source software licenses are those approved by the Open Source
Initiative (OSI) based on their Open Source Definition (OSD).
Open-Source Software (OSS)
Open-Source Software (OSS) is computer software that is released under a license
in which the copyright holder grants users the rights to use, study, change, and
distribute the software and its source code to anyone and for any purpose. Open-
source software may be developed in a collaborative public manner. Open-source
software is a prominent example of open collaboration.
Open-source software development can bring in diverse perspectives
beyond those of a single company. A 2008 report by the Standish Group stated
that adoption of open-source software models has resulted in savings of about
$60 billion per year for consumers.
Model
Open-source software development can be divided into several phases. The phases
specified here are derived from Sharma et al. A diagram displaying the process-
data structure of open-source software development is shown below. In this
diagram, the phases of open-source software development are displayed, along
with the corresponding data elements. This diagram is made using the meta-modeling
and meta-process modeling techniques.

Self-Instructional
Material 191
Team Development and
Conflict Management

NOTES

Starting an Open-Source Project

Following are some ways using which an open-source project can be started:
 An individual who senses the need for a project announces the intent to
develop a project in public.

Self-Instructional
192 Material
  A developer working on a limited but working codebase, releases it to the Team Development and
Conflict Management
public as the first version of an open-source program.
 The source code of a mature project is released to the public.
 A well-established open-source project can be forked by an interested NOTES
outside party.
Eric Raymond observed in his essay “The Cathedral and the Bazaar” that
announcing the intent for a project is usually inferior to releasing a working project
to the public.
Open Source Project Management Tools for Agile Teams
A majority of organizations are using agile approaches, because the agile projects
are more successful than projects managed with traditional approaches. Following
are some open source project management tools for agile teams.
MyCollab

MyCollab is a suite of three collaboration modules for small and midsize

businesses: Project Management, Customer Relationship Management (CRM),
and Document Creation and Editing Software. There are two licensing options: a
commercial ‘Ultimate’ edition, which is faster and can be run on-premises or in the
cloud, and the open source ‘Community Edition’. The community edition does
not have a cloud option and is slower, due to not using query cache, but provides
essential project management features, including tasks, issues management, activity
stream, roadmap view, and a Kanban board for agile teams. While it does not
have a separate mobile app, it works on mobile devices as well as Linux, UNIX,
Windows, and MacOS.

Self-Instructional
Material 193
Team Development and OpenProject
Conflict Management

NOTES

OpenProject is a powerful open source project management tool that is

notable for its ease of use and rich project management and team collaboration
features. Its modules support project planning, scheduling, roadmap and release
planning, time tracking, cost reporting, budgeting, bug tracking, and agile and
Scrum. Its agile features, including creating stories, prioritizing sprints, and tracking
tasks, are integrated with OpenProject’s other modules. OpenProject also offers
options for paid hosting and support with an enterprise edition that adds features,
such as custom branding, easy Single Sign-On (SSO), additional metadata, and
several UX conveniences. OpenProject is licensed under GPLv3 with source
code available on GitHub.
Phabricator

Self-Instructional
194 Material
 Phabricator is a collection of web apps by Phacility, and it contains far more Team Development and
Conflict Management
tasks than the project advertises in its sales pitch. It is unusual for a company to
intentionally under sell their product. There is Manifest for bug and issue tracking,
Projects for Kanban workboards, Diffusion for Git hosting, Phame for blogging,
the Phriction wiki, Harbormaster for CI/CD, Conpherence for team chat, and NOTES
many more. Everything is intregrated, so no ‘Rewiring’ required to make the Kanban
board affect the bug tracker. Since, there is a dashboard for all of the data, hence
tracking progress can happen at every level.
An Assessment of Team Organization
Teams are the primary unit of many workplaces, and their problems are diagnosed
through team assessments. Teams need to be built; they are not automatically fully
formed and functional.
A team assessment is an exercise that allows you to evaluate a team’s
strengths and weaknesses. As a recognized management technique, team
assessments began attracting attention in the 1970s and 1980s, after American
organizational practice wholeheartedly embraced the idea of teamwork as a primary
driver of success (in professional sports, which has always emphasized teamwork,
different team assessments have been used for even longer.
Although even an informal assessment can be helpful, team assessment tools
have grown more sophisticated, applying principles from organizational theory
and human resource management. Today, specialized team assessments are
designed to measure multiple facets of team performance based on formal models
of how teams should operate.
Team assessments can be conducted in a lot of different ways: in-person
sessions, via email, or with tailor-made online surveys and apps. Many assessments
use specially designed worksheets.
Some team assessments are based on particular theories about what drives
effective teamwork. Other assessments focus on different measures of team
effectiveness, such as the quality of organizational support, clarity of goals, a team’s
ability to learn and grow, team diversity (not only in terms of culture, race, gender,
but also thinking styles and personalities), and most importantly, the ability to deliver
results.
Managers most commonly perform a team assessment to uncover problems
and shortcomings within teams. Weaknesses may be difficult to pinpoint if you are
closely involved with the team and have difficulty making an objective assessment.
2. NOKIA SOFTWARE FACTORY
The Collapse of Nokia’s Mobile Phone Business
Nokia’s loss of dominance in the mobile market after 2007 is one of the most
significant failures in modern business history. For Finland, this was an economic
catastrophe, when the largest company in the country lost grip on its core business.
In 2007, Nokia’s mobile division was the leading mobile device manufacturer in
Self-Instructional
Material 195
Team Development and the world, with a market share of about 40 (Cord, 2014). In 2011, its market
Conflict Management
share was only 25%, and the company started software collaboration with
Microsoft. In 2013, it was announced that Nokia would be selling its entire mobile
business to Microsoft. By this stage, the company’s market share was only 14%.
NOTES By 2015, the market share was a measly 1%. Microsoft, in turn, announced in
spring 2016 that it will stop manufacturing mobiles it inherited from Nokia.
Practically speaking, the company’s mobile phone business crashed from
the top position in the world to complete extinction within about eight years. A lot
has been written about Nokia’s hardship and ruin. People are passionate about
this topic, particularly in Finland: after all, this company was the country’s first real
world-class business, which at one point had the highest market value among
European corporations. The descriptions of Nokia’s failures are often ideologically
charged and tainted.
The focus is on the dynamics between different levels of wisdom in
organisational action and decision-making. Nokia’s situation around the year 2008
could simply be described by stating that there was a paradigmatic change under
way in the mobile business. The company had been successful by making reliable,
techno- logically advanced phones cost-efficiently. Nokia was strong particularly
in Europe and in developing countries. However, a significant thing happened in
2007; Apple launched the iPhone. This model was completely different from any
other product on the market at the time. It had a touch-screen and only one
function key. The phone was simple to use, and aesthetically unique. Apple was
able to offer a large amount of apps.
Another front also opened up in 2007: the search engine Google presented
their own operating system, Android, designed for smartphones. The Android
system was open; that is, all mobile manufacturers were able to use it, regardless
of their particular software resources. The appearance of Apple and Android on
the mobile market meant that companies that were previously developing computers
and internet services broke into an arena dominated by mobile device
manufacturers. With Steve Jobs at the helm, Apple had brought home computers
within everyone’s reach, and had recently also expanded into music distribution
through the iPod device and the iTunes online service. Google, in turn, had become
the king of Internet search engines.
Nokia’s mobiles were reliable, and always advanced technologically, but
now they looked pitifully old-fashioned, with their clumsy user interfaces and limited
range of services. A Nokia mobile was durable, but cumbersome. On the other
hand, Apple’s iPhone was a beautiful trendy product, which was easy to use and
whose touch-screen offered many innovative ways to use the phone; for example,
for gaming. The Android OS provided a strong basis for new smartphones, while
the capacity of Nokia’s own Symbian was starting to reach its limits in its current
format (Cord, 2014).

Self-Instructional
196 Material
 Nokia was unable to respond to iPhone’s challenge. It started losing market Team Development and
Conflict Management
share. The selected operating system, Windows, was not as intuitive as iOS, which
Apple had been developing for computers for a long time. In principle, however,
Nokia had every opportunity to accept the challenge of its new competitors. The
company had an extensive product development organisation and a stable financial NOTES
situation. It had already started developing a touch-screen in 2004. The technical
features of the iPhone were not considerably more advanced than those of their
competitors. Nokia had also been aware for a long time that the Symbian operating
system was coming to an end, and the company had been designing a new, substitute
software platform for some time (Cord, 2014).
From the perspective of traditional situational management theory, Nokia’s
technological operating environment was going through a sudden change, which
should have denoted an attempt to achieve greater flexibility in the operating method
and form of organisation. In the case of a stable operating environment, a company
can be successful with a hierarchical organisational structure, which functions
predictably and efficiently. In turn, in a turbulent situation, an organisation should
break rigid rules and the barriers between different departments and levels of
hierarchy, and aim towards unprejudiced interaction (Donaldson, 2001).
However, this did not happen. Nokia had become a faceless machine, with
information not flowing freely inside it and it therefore wasted energy on slow
decision-making and the wariness of middle management (Cord, 2014; Heikkinen,
2010; Nykänen & Salminen, 2014).
This explanation, which sounds credible in itself, is not surprising. Large
corporations can easily transform into bureaucratic mammoths, which can be
toppled during an extensive technological or market breakthrough due their inability
to adapt to the changed situation. Financially successful companies in particular
can easily sink into dangerous complacency. Nevertheless, the bureaucratisation
and expansion of an organisation does not explain why in Nokia’s case it became
the fate of the company. There are also many examples in economic histories
where corporations have been able to save their skin and invent new products or
services, or in some cases even focus their business operations on completely new
fields as old opportunities become obsolete. For example, the computer
manufacturer IBM sold its device production unit and focused instead on services
and software business. Previously known as the world’s most powerful computer
manufacturer, the company took a successful leap into a new life (Agarwal &
Helfat, 2009).
On the other hand, Nokia’s extended story could be interpreted as renewal.
As the mobile business collapsed, the company still had the field of e-commerce,
which was first expanded through collaboration with Siemens and later through
the acquisition of Lucent. Perhaps, in its own way, Nokia returned to its roots as
an industrial company, when it continued business operations in the field of phone

Self-Instructional
Material 197
Team Development and network technology. Recent years have shown that network business was the
Conflict Management
right choice: the mobile departments sold to Microsoft were not viable, and the
mobile industry has otherwise shown signs of saturation. Nokia’s background as
an engineer-driven company manufacturing industrial products seems to be suitable
NOTES for the regularities in the information network business.
However, the crash of the mobile business was a clear failure. If we wish to
explain that, we have to look for such factors and backgrounds that are related to
Nokia’s special characteristics: its history, culture and leadership. These will enable
us to better understand Nokia’s story and its unique dynamic. By addressing the
company’s own special background, we can also avoid the generalising and
popularising explanations that have been offered by previous observers.
Nokia’s Story - Conflict Management
In the 1980s, Nokia was a conglomerate that aimed to internationalise and become
independent from Finland’s closed economic system. Kari Kairamo, the charismatic
CEO of the company, envisioned an international or even global future for the
company. At the time, the Finnish economy was dominated by large companies in
the paper industry and profitable projects related to Soviet trade, and like continental
Europe, commercial banks were in control of industry (Häikiö, 2009).
Nokia attempted to detach itself from the Finnish economic system. It was
aiming towards the West, and away from the control of the big banks. Kairamo
had acquired consumer electronics businesses in Europe. At the same time, the
company was still manufacturing rubber boots and tissue paper. Nokia had recruited
a group of young, internationally minded talent, and it was considered to have a
different spirit than many other large corporations of its time. One of the recruits
was Jorma Ollila, who was hired as the Finance Manager.
Kari Kairamo was an energetic executive who enjoyed being in the public
eye. He also had a nationwide impact, and was active in the political sphere.
However, in 1988, Nokia’s pace slumped. Showy business acquisitions were a
strain on the balance sheet. Stocks dropped by 40%. Large banks were no longer
satisfied with Kairamo’s management style. Media publicity had also turned against
the company, as the former favourite of economic press was now branded a rabid
adventurer.
Kari Kairamo had been experiencing mental health problems. In 1988, the
situation started to become unbearable for him. In spring, Timo H. Koski, a gifted
manager and a close colleague of Kairamo, dies of a brain haemorrhage at a mere
40 years of age. The CEO Kairamo becomes depressed and ultimately commits
suicide in December 1988. At first, the company refers to it as a seizure, but
Helsingin Sanomat later reveals— for the first time in the Finnish journalistic circles—
that the cause of Kairmo’s death was suicide.
The coming few years are confusing for the company. There is a power
struggle among the top management, and the burden of debt is a strain on the
finances. There are dramatic changes in the environment: the Cold War ends and
Self-Instructional
198 Material
trade with the Soviet bloc crashes. Finland ends up in a recession. Finally, the Team Development and
Conflict Management
company’s management is rearranged. Jorma Ollila from the younger generation
is selected as the CEO, supported by Casimir Ehrnrooth, who becomes the
Chairman of the Board.
NOTES
Nokia had been developing mobile phones already in the 1980s. Now,
these became the main field of business the company started to focus on. Other
business operations were gradually sold off. Ollila surrounds himself with intelligent
and ambitious professionals from the same age bracket. The company clearly
turns towards the Anglo-American business model, where business operations
are carried out on the terms of the owners and investors. The mobile market is
growing rapidly, and Nokia’s previous development work, and the pioneering
role of the Nordic countries in the emerging mobile phone technology, is starting to
bear fruit.
Nokia rises from the bottom: in 1992, the earnings increase by 385%
compared to the previous year, and a staggering 510% in 1993 (Häikiö, 2009).
Soon, it is competing for the position of market leader. The monitoring of lower-
level operations was made more efficient, and sales forecasts were compiled more
carefully than before.
Some interesting conclusions can be drawn from Nokia’s story. To begin
with, the company has been through several crises, but has survived from the
predicaments by carrying out radical structural updates. The crisis in the late 1980s/
early 1990s led to a generational change in the corporate management. The old
national industrial generation gave way to a cohort of internationally oriented
strategic, finance and marketing experts.
Nokia’s rationalised management methods and mechanistic form of
organisation produced excellent results for a long time. There were no revolutionary
innovations on the mobile market; instead, phone features expanded gradually,
giving Nokia the opportunity to manufacture large volumes of products tailored
for different customers and markets, using what was essentially the same
technological-software template. The company’s phones were reliable,
technologically strong and effortless devices.

Self-Instructional
Material 199
Software Quality
Assurance
UNIT 10 SOFTWARE QUALITY
ASSURANCE
NOTES
Structure
10.0 Introduction
10.1 Objectives
10.2 Software Quality Assurance Activities
10.3 Software Quality
10.3.1 Data Analysis Techniques Applicable to Software Processes
10.3.2 Importance of Software Quality
10.4 Software Quality Standard
10.5 ISO Standards for Software Organization
10.6 Capability Maturity Model (CMM)
10.7 Comparison between ISO 9001 & SEI CMM
10.8 Other Standards
10.9 Answers to Check Your Progress Questions
10.10 Summary
10.11 Key Words
10.12 Self Assessment Questions and Exercises
10.13 Further Readings

10.0 INTRODUCTION

Software Quality Assurance (SQA) is a means and practice of monitoring

the software engineering processes and methods used in a project to ensure
proper quality of the software. It includes standards and procedures that managers,
administrators or even developers may use to review and audit software products
and activities to verify that the software meets quality criteria which link to standards.
Software quality assurance is a supporting process that provides the independent
assurance that all work products, activities and processes comply with the predefined
plans and quality strategies.
SQA encompasses the entire software development process,
including requirements engineering, software design, coding, code reviews, source
code control, software configuration management, testing, release
management and software integration. It is organized into goals, commitments,
abilities, activities, measurements, verification and validation. These activities are
concerned with verification and validation of the software process being followed
to accomplish the user requirements in the software. When SQA activities are
complete, a report describing the results is presented to the management. If the
report indicates that the software quality is not according to the user requirements
then the management takes necessary actions to improve the quality of the software.

Self-Instructional
200 Material
 Software Engineering Institute (SEI) has developed a process maturity Software Quality
Assurance
framework known as capability maturity model to improve the software process
in an organization. In this model, software process maturity indicates the extent to
which a particular process is defined, managed, and controlled. CMM identifies
the inadequacies in the organization and determines the processes to develop and NOTES
maintain the software. The International Organization for Standardization (ISO)
9000 standards describes the elements in quality assurance, which outline the
requirements of good quality product in an organization.
In this unit, you will study about the software quality assurance activities,
software quality, software quality standard, ISO standards for software organization,
Capability Maturity Model (CMM), and other standards.

10.1 OBJECTIVES

After going through this unit, you will be able to:

 Define the software quality assurance activities
 Elucidate on the software quality
 Understand the basics of software quality standard
 Discuss about the ISO standards for software organization
 Explain the Capability Maturity Model (CMM)
 Analysis the other standards

10.2 SOFTWARE QUALITY ASSURANCE

ACTIVITIES

To ensure that the software under development is in accordance with established

standards, Software Quality Assurance (SQA) activities are followed. These
activities are concerned with verification and validation of the software process
being followed to accomplish the user requirements in the software. When SQA
activities are complete, a report describing the results is presented to the
management. If the report indicates that the software quality is not according to
the user requirements then the management takes necessary actions to improve
the quality of the software. Broadly, software quality assurance activities are
classified into process quality assurance activity and product quality assurance
activity.
Process Quality Assurance Activity
This activity ensures that the processes that are defined for the project are followed.
In case the defined processes are not followed according to standards, suggestions
for those situations are provided to the management. A separate report is sent to
Self-Instructional
Material 201
Software Quality both the management and the SQA group. The SQA group examines associated
Assurance
problems occurring due to delay in schedule or increase in budget and reports
them to the management. The process quality is evaluated through software process
audits. These audits focus on checking the implementation of the defined processes
NOTES in software. Software process audits are conducted by quality analysts from time
to time. Various tasks involved in process quality assurance activity are listed below.
 Ensuring development of project plans and their review and approval
 Conducting software configuration reviews
 Establishing software quality plans, standards, and procedures for the project
 Establishing periodic reviews with the user
 Submitting a profile to the management about the adherence of defined
process throughout the software development process, by showing regular
improvement in the development process
 Ensuring regular submission of metrics and other required information to
the Software Engineering Process Group (SEPG).
Product Quality Assurance Activity
This activity identifies the processes in order to check whether they are carried out
properly to develop a product that conforms to the user requirements. Product
quality assurance activity concentrates on detection and elimination of errors as
early as possible during software development. As a result, there is reduction in
costs incurred during software maintenance and testing. Product quality assurance
comprises methods to conduct reviews and testing of the software. Reviews evaluate
the software before delivering it to the user. After software reviews are complete,
the quality analyst performs a final review. Final review is essential to verify that all
planned reviews or reported problems are followed. In addition to reviews, software
testing is performed to check errors in software and to verify whether the errors
are occurring due to non-conformance to the user requirements.
Auditing in Software Quality Assurance Activities
SQA activities follow several techniques to find errors in the software. Audit is a
fundamental technique used for both process quality assurance and product quality
assurance. It examines a process or product in detail and compares it with the
established standards. Audit is performed to examine the conformance of a
development process to procedures and standards. In addition, it examines the
records according to the defined process to determine whether the procedures
are followed correctly. The auditor performs audit to examine whether the records,
procedures, and management policies are executed properly. An auditor can be
internal—one of the employees of the organization—as well as external, which is
selected by the organization and SEPG.

Self-Instructional
202 Material
 Software Quality
10.3 SOFTWARE QUALITY Assurance

There are two measures to test software quality. These measures are the quality of
design and quality of conformance. The quality of design tells us that how well the NOTES
software is designed. It measures the validity of the design and requirements to
create a worthwhile product. The quality of conformance tells us how well the
software conforms to that design. It is concerned with implementation.
To make a product that meets the user’s requirements, it is necessary to
know the expectations of the customers. So there should be a proper mechanism
of getting input and feedback from customers and users. Once the requirements
and importance from the customer’s point of view are known, the standards can
be set. Metrics for evaluation have to be set and they have to be measured on a
periodic basis to monitor the level of conformance and quality. From the customer
and user perspective, the following are some factors that need to be considered
for quality:
Conform to Specification
 Fitness of use
 Low cost
 Reliability
 Ease of use and user-friendly interface
 Minimum variance
 High performance, high throughput, fast response time
10.3.1 Data Analysis Techniques Applicable to Software Processes
Benchmarking: It is easy to keep track of metrics after they have been defined.
Such metrics help one in reviewing the improvements over time or comparing the
results with similar projects. Performance, cost, quality, response time, features
are all very important in a software. It is very important to know what issues are
important for customers. Quality management of products and processes need to
be done for monitoring these important metrics and for checking the improvement
and whether customers’ expectations were met or not.
Pareto Analysis: It is a charting technique which helps in identifying the leading
contributors (attributes/properties) to a given metric. It is seen that attributes or
properties are distributed in a very non-uniform manner.
Trending: It is about keeping track with the changes in metrics. Such tracking
helps one to know if the process is improving or getting worse.
Scatter Plot: It is a very useful technique for studying the existence of any
relationship between two variables among the population of data measurements.
The two variables and their relationship could be defective density versus
Self-Instructional
Material 203
Software Quality productivity or functional points versus effort (person-hours). We can do a
Assurance
regression analysis in case of a linear relation for fitting the data points into a linear
curve and then we can use that equation as a basis for estimation in future projects.
The data sometimes can fall into multiple sub-populations, and for this it is also
NOTES known as a stratified scatter plot.
Decomposition: It is sometimes useful to further decompose the data to get the
finer details; for example, it is better to check the screening efficiency of each
software development life cycle phase rather than looking at the screening efficiency
of the overall software production process just before the product reaches the
customers. Quantifying the percentage of defects found at each phase where the
defects were introduced is important. It may sometimes happen that defects are
found at a later stage even though they were introduced earlier on in the lifecycle.
This gives an opportunity for improving the process as the cost of detecting and
fixing defects rises fast in later phases of the life cycle.
10.3.2 Importance of Software Quality
From the human point of view a software program or source code can be written
in a way that affects the effort needed to comprehend its behaviour. Many source
code programming style guides often stress readability. Usually, language-specific
conventions are aimed to reduce the cost of maintaining source code. Some of the
issues that affect the quality of the code are as follows:
 Readability
 Low complexity
 Ease of maintenance, testing, debugging, fixing, modifying and portability
 Low resource consumption
 Number of compilations or lint warnings
 Robust input validation and error handling, established by software fault
injection
A software quality factor is a non-functional requirement for a software program
that is not called upon by the customer’s contract, but nevertheless is a desirable
requirement that enhances the software program quality. Note that none of these
factors are binary. Rather, they are characteristics that one seeks to maximize in
one’s software to optimize its quality. So, rather than asking whether a software
product has such and such factor, ask instead the degree to which it does (or does
not) improve the program quality.
Some software quality factors are listed below.
Understandability: It signifies clarity of purpose. All the design and
user documentation must be written clearly for easy understanding. This is
obviously subjective in that the user context must be taken into account; for instance,
if the software product is to be used by software engineers, it is not necessary for
a layman to understand it.
Self-Instructional
204 Material
 Completeness: It signifies the presence of all constituent parts, with each Software Quality
Assurance
part fully developed. This means that if a subroutine is called by the code from an
external library, the software package must provide a reference to that library and
all required parameters must be passed. All required input data must also be available.
NOTES
Conciseness: It is about minimization of excessive or redundant information
or processing. This is important where memory capacity is limited, and it is generally
considered a good practice to keep the lines of code to a minimum. It can be
improved by replacing repeated functions with one subroutine or function. It also
applies to documents.
Portability: It signifies the ability of the software to run well and easily on
multiple computer configurations. Portability can mean that the software is able to
run in different types of hardware and different operating systems.
Consistency: There must be uniformity in notation, symbology, appearance
and terminology within the system.
Maintainability: It means the propensity of facilitating updates for satisfying
new requirements. Thus, a maintainable software product should be documented
well, it should not be complex, and should have spare capacity for memory, storage
and utilization of processor and other resources.
Testing: It signifies the disposition for supporting the acceptance criteria
and evaluating performance. Such a characteristic must be built-in during the design
phase if the product is to be easily testable; a complex design leads to poor testability.
Usability: It signifies convenience and practicality of use. This is affected
by such things as the human–computer interface. The software component that
has the major impact on this is the user interface, which for best usability is usually
graphical, i.e., a Graphical User Interface (GUI).
Reliability: It is the ability to perform its intended functions satisfactorily.
This implies a time factor in that a reliable product is expected to perform correctly
over a period of time. It also involves environmental considerations in that the
product is needed to perform correctly in whatever conditions it finds itself.
Structuredness: It signifies the organization of constituent parts in a definite
pattern. A software product written in a block-structured language such as Pascal
satisfies this characteristic.
Efficiency: It signifies the fulfilment of purpose without wasting resources
such as memory, space, network bandwidth, processor utilization and time.
Security: It is the ability of protecting data against unauthorized access and
withstanding malicious interference with its operations. Apart from the presence
of appropriate security mechanisms such as access control, authentication and
encryption, security also involves the ability to withstand malicious, intelligent
attackers.

Self-Instructional
Material 205
Software Quality
Assurance 10.4 SOFTWARE QUALITY STANDARD

ISO 9126 is an international standard for the evaluation of software quality. The
NOTES fundamental objective of this standard is to address some well-known human
biases that can badly affect the perception and delivery of a software development
project. These biases include changing priorities after beginning a project or not
having any clear definitions of success. Through clarification and agreement on the
priorities of the project and then through conversion of abstract priorities, output
data can be validated against schema X with zero intervention. ISO 9126 tries to
develop a common understanding of the objectives and goals of a project.
The standard is divided into four parts:
 Quality Models
 External Metrics
 Internal Metrics
 Quality in use Metrics
The quality model established in the first part of the standard, ISO 9126-1,
classifies software quality in a structured set of characteristics and sub characteristics
as follows:
 Functionality: A set of attributes that bear on the existence of a set of
functions and their specified properties. The functions are those that
satisfy the stated or implied needs, such as:
o Suitability
o Interoperability Compliance
o Accuracy
o Security
 Reliability: A set of attributes that bear on the capability of the software
in maintaining its performance level under stated conditions for a stated
period of time.
o Maturity
o Fault Tolerance
o Recoverability
 Usability: A set of attributes that bear on the effort required for using,
and on the individual assessment of such use, by a stated or implied set
of users.
o Learnability
o Operability
o Understandability

Self-Instructional
206 Material
  Efficiency: A set of attributes that bear on the relationship between the Software Quality
Assurance
performance level of the software and the amount of resources used,
under stated conditions.
o Resource Behaviour
NOTES
o Time Behaviour
 Maintainability: A set of attributes that bear on the effort required for
making particular modifications.
o Stability
o Changeability
o Analysability
o Testability

10.5 ISO STANDARDS FOR SOFTWARE

ORGANIZATION

Software quality is a multi-faceted and rather a vague concept. For any software
product, measures associated with its attributes should collectively reflect likely
user satisfaction with use of the product over its lifetime. All the software should
have three specifications:
1. Functional specification: The description about what the system is to do.
2. Quality (attribute) specification: It describes how well the functions are
operating.
3. Resource specification: It describes how much is to be spent on the
system.
We should define all the external and internal qualities of the software. All the
external qualities should be mapped to the internal factors of which the developers
would be aware.
A mere definition of quality is not enough; there should be some measures
to its quality. For each quality characteristic, there should be some measure to
access the degree of its perfection. The measures may be direct where we can
measure the quality directly or indirectly where the factor being measured is not
the quality itself but an indicator that the quality is present.
We should prepare quality specifications with the following minimum details:
1. Definition or description
2. Scale
3. Test
4. Minimally acceptable
5. Target range
6. Now Self-Instructional
Material 207
Software Quality There could be more than one measurement that is applicable to quality
Assurance
characteristics.
International Standards Organization (ISO) is a consortium of sixty-three
countries established to formulate and foster standardization. ISO published its
NOTES
9000 series of standards in 1987. ISO certification serves as a reference for contract
between independent parties. The ISO 9000 standard specifies the guidelines for
maintaining a quality system. We have already seen that the quality system of an
organization applies to all activities related to its product or service. The ISO
standard mainly addresses operational aspects and organizational aspects such as
responsibilities, reporting, and so on. In a nutshell, ISO 9000 specifies a set of
guidelines for repeatable and high quality product development. It is important to
realize that ISO 9000 standard is a set of guidelines for the production process
and is not directly concerned with the product itself.
Types of ISO 9000 Quality Standards
ISO 9000 is a series of three standards: ISO 9001, ISO 9002 and ISO 9003.
The ISO 9000 series of standards is based on the premise that if a proper process
is followed for production, then good quality products are bound to follow
automatically. The types of industries to which the different ISO standards apply
are as follows:
 ISO 9001 applies to the organizations engaged in design, development,
production, and servicing of goods. This is the standard that is applicable to
most software development organizations.
 ISO 9002 applies to those organizations which do not design products but
are only involved in production. This category of industries include steel
and car manufacturing industries that buy the product and plant designs
from external sources and are involved in only manufacturing those products.
Therefore, ISO 9002 is not applicable to software development
organizations.
 ISO 9003 applies to organizations that are involved only in installation and
testing of products.
Software products vs other products
There are mainly two differences between software products and other types of
products.
 Software is intangible in nature and therefore difficult to control. It is very
difficult to control and manage anything that is not seen in contrast to any
other industry such as car manufacturing industry where one can see a
product being developed through various stages such as fitting engine, fitting
doors, etc. Therefore, it is easy to accurately determine how much work
has been completed and estimate how much more time will it take.

Self-Instructional
208 Material
  During software development, the only raw material consumed is data. In Software Quality
Assurance
contrast, large quantities of raw materials are consumed during the
development of any other product.
Need for obtaining ISO 9000 certification NOTES
There is a mad scramble among software development organizations for obtaining
ISO certification due to the benefits it offers. Some benefits that can be acquired
by organizations by obtaining ISO certification are as follows:
 Confidence of customers in an organization increases when an organization
qualifies for ISO certification. This is especially true in the international
market. In fact, many organizations awarding international software
development contracts insist that the development organization have ISO
9000 certification. For this reason, it is vital for software organizations
involved in software export to obtain ISO 9000 certification.
 ISO 9000 requires a well-documented software production process to be
in place. A well-documented software production process contributes to
repeatable and higher quality of the developed software.
 ISO 9000 makes the development process focused, efficient and cost-
effective.
 ISO 9000 certification points out the weak points of an organization and
recommends remedial action.
 ISO 9000 sets the basic framework for the development of an optimal
process and Total Quality Management (TQM).

Check Your Progress

1. What is a software quality assurance activity?
2. Differentiate between quality of conformance and quality of design.
3. What are the issues that affect code quality?
4. List some software quality factors.
5. Write the types of standard.
6. Differentiate between the software products and other products.

10.6 CAPABILITY MATURITY MODEL (CMM)

Software Engineering Institute (SEI) has developed a process maturity framework

known as capability maturity model to improve the software process in an
organization. In this model, software process maturity indicates the extent to which
a particular process is defined, managed, and controlled. CMM identifies the
inadequacies in the organization and determines the processes to develop and
maintain the software.
Self-Instructional
Material 209
Software Quality This model helps the organization in selecting software process improvement
Assurance
strategies by describing issues of software quality and improving the process. CMM
is also used by an organization to plan improvements to the software process.
CMM is organized into five levels as shown in Figure 10.1, where each level
NOTES represents foundations for continuous process improvement. Each maturity level
provides a layer to improve the process in a step-by-step manner.

Fig. 10.1 Levels of CMM

Each maturity level comprises Key Process Areas (KPA) to identify the
areas that need improvements in the organization. Figure 10.2 shows KPAs that
exist in maturity levels. KPA determines a group of related activities, which are
performed collectively to achieve goals for establishing the process at that maturity
level. In achieving a maturity level, KPA is considered an important requirement.
Various KPAs present in the maturity levels have been summarized in Table 10.1.
Table 10.1 KPAs in CMM

Maturity Level Key Process Areas

Initial None
Repeatable Requirements management, software project planning,
software project tracking and oversight, software subcontract
management, software quality assurance, and software
configuration management
Defined Organization process focus, organization process definition,
training programme, integrated software management,
software product engineering, intergroup coordination, and
peer reviews
Managed Quantitative process management and software quality
management
Optimized Defect prevention, technology change management, and
process change management

Self-Instructional
210 Material
 Software Quality
Assurance

NOTES

Fig. 10.2 KPAs in CMM

Initial Level
This level is fundamentally ad hoc (unplanned) and has no formalized method for
any activity. It does not provide a stable environment to develop and maintain
software processes. Everything is managed on ad hoc basis. The capability of the
process depends on quality and capability of individual effort in an organization.
Improving the project management and quality assurance benefits the organizations
at these levels. There are no KPAs in this level.
Repeatable Level
This level defines the policies to manage the software project and its procedures.
In addition, it defines the methods to execute these policies. The process capability
of this level is summarized for planning and tracking the software project. Thus,
the plans based on the performance of previous projects are followed:
Key Process Areas
The KPAs for this level are listed below:
 Requirements Management: The objective is to establish an
understanding of user requirements to be included in the software project.
Thus, an agreement determining the requirements of the software project is
made with the user. This agreement contains the functional and non-functional
requirements, such as delivery dates. This agreement forms the basis for
estimating, planning and tracking the project activities throughout the software
development process. In case, requirements are changed, the affected
activities and plans are adjusted with the modified requirements.
 Software Project Planning: The objective is to establish formal plans to
manage the software project and perform the software engineering. Formal
plans that are established include software configuration plan, quality
assurance plan, and software development plan. Project planning develops
an estimate for the activities to be performed.
 Software Project Tracking and Oversight: The objective is to monitor
the actual process so that the management can take necessary steps if the
software project deviates from the plans laid down. This KPA involves
Self-Instructional
Material 211
Software Quality tracking procedures and reviews to check whether the software project is
Assurance
according to the user requirements. A documented plan is used as the basis
for tracking the software activities and revising the plans. These activities
are monitored by the management.
NOTES
 Software Subcontract Management: The objective is to select
subcontractors by establishing commitments with them and monitoring their
performance. To manage software subcontract, written organizational policy
is followed.
 Software Quality Assurance: The objective is to verify that software
complies with applicable procedures and standards. The SQA group works
with the software project during the early stages to determine plans and
standards to satisfy the constraints of the project and the policy of the
organization.
 Software Configuration Management: The objective is to maintain
integrity when changes are made to the software during its development.
For this software configuration management plan is prepared for each
software project according to the user requirements. The plan is prepared
in the early stages of software development process along with project
planning. It includes the activities that are to be performed, schedule of
activities, assigned responsibilities, and the resources that are required.
Defined Level
This level defines an organized, documented, and standardized set of activities in
an organization. In the process, each step is defined along with the methods to
perform it. The software processes for the organization are maintained by Software
Engineering Process Group (SEPG).
Key Process Areas
The KPAs for this level are listed below:
 Organization Process Focus: The objective is to determine the software
process activities, which are responsible for improving the overall software
process of the organization. It involves understanding the software processes
and coordinating activities to assess, develop, maintain, and improve the
processes.
 Organization Process Definition: The objective is to develop and maintain
a functional set of software process assets that improves the performance
of the process and provide benefits to the organization. The organization
maintains a written document for standard software process and related
process assets. Note that the information useful to standard software process
is collected and reviewed whenever needed.
 Training Program: The objective is to provide training to individuals in the
organization so that they perform their responsibilities efficiently. The training
Self-Instructional
212 Material
 can be formal such as classroom training or informal such as on job training. Software Quality
Assurance
For this, a training plan is prepared that describes details of how and for
whom the training is to be provided and when it is required. The training
plan is revised according to the software project. Training is performed
according to the organizational standards. The organization maintains records NOTES
of training.
 Integrated Software Management: The objective is to integrate the
management activities and software engineering activities into a logical and
defined software process. It is important to ensure that software processes
are customized according to the established software process. Hence, on
the basis of software process, the development plan describes how the
activities of the project are to be implemented.
 Software Product Engineering: The objective is to perform a well-defined
engineering process in a consistent manner. It integrates all the software
engineering activities to ensure that correct, effective and efficient software
product is developed. Software product engineering comprises various tasks.
These tasks include analysing the system requirements, identifying software
requirements, designing software, writing the software code, integrating the
software components and testing the software.
 Intergroup Coordination: The objective is to determine a means for the
software engineering group to participate with the other engineering groups
that satisfy the user requirements effectively and efficiently. The interactions
between groups are planned and managed to ensure quality and integrity of
entire system.
 Peer Reviews: The objective is to detect the errors in the software as
early as possible so that they can be prevented from recurring. It is conducted
as an integral part of the software development process.
Managed Level
This level sets quantitative goals for software and processes of the organization. It
allows an organization to predict trends in process and product quality within the
quantitative bounds of the limits. In case, the limit is exceeded, proper steps are
taken to correct the situation.
Key Process Areas
The KPAs for this level are listed below:
 Quantitative Process Management: The objective is to control the
process performance of the software projects quantitatively. Activities in
the quantitative process management are performed in conformity with the
quantitative process management plan. The plan consists of software tasks
or software activities that are analyzed and measured.

Self-Instructional
Material 213
Software Quality  Software Quality Management: The objective is to determine quality
Assurance
goals for the software, establish a plan to accomplish these goals and examine
these goals to meet the user requirements.

NOTES Optimized Level

This level focuses on the continuous improvement of the process in the organization.
The data are gathered and analyzed to improve the quality. Thus, the organizations
strengthen the processes by preventing occurrence of errors. The improvement of
process can be done in incremental advancements in the existing process by using
new technologies and tools.
Key Process Areas
The KPAs for this level are listed below:
 Defect Prevention: The objective is to identify the causes of defects and
prevent them from recurring. The defects prevention activities are planned.
They comprise plans and resources to prevent defects from occurring again.
These activities are implemented to improve processes and products in the
organization.
 Technology Change Management: The objective is to identify new
technologies, tools, methods and processes, and use them according to
requirements of the organization. It involves identifying, selecting and
evaluating new technologies, as well as incorporating effective technologies
into software in the organization.
 Process Change Management: The objective is to improve the software
processes in order to improve software quality, increase productivity and
reduce the amount of time required for software development. In addition,
it defines the process improvement goals and implements the improvements
according to the organizational standards.
Differences between ISO 9000 Standard and CMM
Both CMM and ISO 9000 are established approaches to review the effectiveness
of software quality system. Their common aim is to deliver quality with consistency
by preventing errors rather than correcting them. They also ensure that quality
assurance is a planned activity. In spite of similarities, there exist some differences
between ISO 9000 and CMM. ISO 9000 standards provide a ‘pass’ or ‘fail’
standard while CMM provides steps to achieve process maturity. The ISO 9000
documents in comparison to CMM are abstract in nature. The other differences
are listed in Table 10.2.

Self-Instructional
214 Material
 Table 10.2 Differences between ISO 9000 and CMM Software Quality
Assurance
Basis ISO 9000 CMM

Industry Applies to any type of industry Developed specifically for

software industry NOTES
Activities It addresses corporate business It primarily focuses on software
engineering activities
Requirements ISO 9000 specifies some It deals with the technical
minimum requirements and aspects of software engineering
restricts itself to what is required suggesting how to accomplish
user requirements
Steps Involved ISO 9000 does not specify the CMM is a step-by-step progress
number of steps required to through its successive levels
establish a quality system

Note: Six sigma can be used at any level of CMM.

10.7 COMPARISON BETWEEN ISO 9001 & SEI

CMM

ISO 9001
It is a set of International Standards on quality management and quality assurance
developed to help companies effectively document the quality system elements
needed to an efficient quality system.
SEICMM
SEI (Software Engineering Institute), Capability Maturity Model (CMM) specifies
an increasing series of levels of a software development organization.
ISO 9001 SEICMM
ISO 9001 is a set of international SEI (Software Engineering Institute),
standards on quality management and Capability Maturity Model (CMM)
quality assurance developed to help specifies an increasing series of levels of a
companies effectively document the software development organization.
quality system elements needed to an
efficient quality system.
Focus is customer supplier relationship, Focus on the software supplier to improve
attempting to reduce customer’s risk in its interval processes to achieve a higher
choosing a supplier. quality product for the benefit of the
customer.
It is created for hard goods It is created for software industry.
manufacturing industries.
ISO 9001 is recognized and accepted in SEICMM is used in USA, less widely
most of the countries. elsewhere.

Self-Instructional
Material 215
Software Quality
Assurance It specifies concepts, principles and CMM provides detailed and specific
safeguards that should be in place. definition of what is required for given
levels.
This establishes one acceptance level. It assesses on 5 levels.
NOTES Its certification is valid for three years. It has no limit on certification.
It focuses on inwardly processes. It focus outwardly.
It has no level. It has 5 levels:
(a) Initial
(b) Repeatable
(c) Defined
(d) Managed
(e). Optimized
It is basically an audit. It is basically an appraisal.
It is open to multi sector. It is open to IT/ITES.
Follow set of standards to make success It emphasizes a process of continuous
repeatable. improvement.

10.8 OTHER STANDARDS

The International Organization for Standardization (ISO) 9000 standards describe

the elements in quality assurance, which outline the requirements of good quality
product in an organization. The elements comprise organizational structure,
procedures and resources that are needed to implement quality assurance in the
software. These standards also provide auditing tools to make sure that they are
properly implemented according to the standards and meet the user requirements.
After implementing these standards, it is mandatory to audit the organization to
evaluate its effectiveness. After a successful audit, the organization receives a
registration certificate, which identifies the quality of the organization as being in
compliance with ISO 9000 standards. ISO 9000 series includes following three
models:
 ISO 9001: This quality assurance model applies to organizations that design,
develop, install and service its product. It discusses how to meet customer
needs effectively.
 ISO 9002: This quality assurance model applies to organizations that
produce, install and service products. This model is nearly identical to 9001,
except that it does not incorporate design and development.
 ISO 9003: This quality assurance model applies to organizations whose
processes are almost exclusive to inspection and testing of final products.
This model is currently limited to an inspection function.
One of the quality standards that are commonly used in practice is ISO
9001:2000. It is a quality management standard that is established for improving
the overall quality of the process and product in an organization. It can be achieved

Self-Instructional
216 Material
by using appropriate management policies and practices. The ISO 9001:2000 is Software Quality
Assurance
based on several management principles relating to different requirements. These
principles are discussed below:
 Management Responsibility: Describes a policy and regular reviews of
NOTES
management tasks and activities.
 Sales: Provides information, which is helpful in understanding customer
needs.
 Document Control: Provides information on manuals and documentation
prepared for an organization.
 Purchasing: Provides information to customers on how to make sure that
they are purchasing the required products.
 Identification and Traceability: Provides information on how to identify
products and services (particularly certified items).
 Inspection and Test: Provides information on how to test and inspect the
products.
 Corrective and Preventive Action: Provides information on how to detect
faults in the products and ways to manage them.
 Quality System: Consists of a quality manual, which shows whether the
manual applies to the management. It also examines the procedures and
processes of the product.

Check Your Progress

7. Give the definition of capability maturity model.
8. Differentiate between ISO 9001 and SEICMM.
9. What is ISO 9000 Quality Standards?

10.9 ANSWERS TO CHECK YOUR PROGRESS

QUESTIONS

1. To ensure that the software under development is in accordance with

established standards, SQA activities are followed. These activities are
concerned with verification and validation of the software process being
followed to accomplish the user requirements in the software. When SQA
activities are complete, a report describing the results is presented to the
management. If the report indicates that the software quality is not according
to the user requirements then the management takes necessary actions to
improve the quality of the software.

Self-Instructional
Material 217
Software Quality 2. Quality of design and quality of conformance. The quality of design tells us
Assurance
that how well the software is designed. It measures the validity of the design
and requirements to create a worthwhile product.
3. The issues that affect code quality are:
NOTES
 Readability
 Ease of maintenance, testing, debugging, fixing, modification and
portability
 Low complexity
 Low resource consumption
 Number of compilation or lint warnings
 Robust input validation and error handling, established by software fault
injection
4. Some software quality factors are:
 Understandability
 Completeness
 Conciseness
 Portability
 Consistency
 Maintainability
 Testing
5. The quality standard is divided into four parts:
 Quality Models
 External Metrics
 Internal Metrics
 Quality in use Metrics
6. There are mainly two types of differences between software products of
products.
 Software is intangible in nature and therefore difficult to control. It is
very difficult to control and manage anything that is not seen in contrast
to any other industry such as car manufacturing industry where one can
see a product being developed through various stages such as fitting
engine, fitting doors, etc. Therefore, it is easy to accurately determine
how much work has been completed and estimate how much more
time will it take.

Self-Instructional
218 Material
  During software development, the only raw material consumed is data. Software Quality
Assurance
In contrast, large quantities of raw materials are consumed during the
development of any other product.
7. Software Engineering Institute (SEI) has developed a process maturity
NOTES
framework known as capability maturity model to improve the software
process in an organization. In this model, software process maturity indicates
the extent to which a particular process is defined, managed, and controlled.
CMM identifies the inadequacies in the organization and determines the
processes to develop and maintain the software.
8. ISO 9001: It is a set of International Standards on quality management
and quality assurance developed to help companies effectively document
the quality system elements needed to an efficient quality system.
SEICMM: SEI (Software Engineering Institute), Capability Maturity Model
(CMM) specifies an increasing series of levels of a software development
organization.
9. The International Organization for Standardization (ISO) 9000 standards
describes the elements in quality assurance, which outline the requirements
of good quality product in an organization. The elements comprise
organizational structure, procedures and resources that are needed to
implement quality assurance in the software. These standards also provide
auditing tools to make sure that they are properly implemented according
to the standards and meet the user requirements.

10.10 SUMMARY

 To ensure that the software under development is in accordance with

established standards, SQA activities are followed. These activities are
concerned with verification and validation of the software process being
followed to accomplish the user requirements in the software.
 SQA activities are complete, a report describing the results is presented to
the management. If the report indicates that the software quality is not
according to the user requirements then the management takes necessary
actions to improve the quality of the software.
 Process Quality Assurance Activity ensures that the processes that are
defined for the project are followed. In case the defined processes are not
followed according to standards, suggestions for those situations are provided
to the management. A separate report is sent to both the management and
the SQA group.
 Product quality assurance activity concentrates on detection and elimination
of errors as early as possible during software development. As a result,
there is reduction in costs incurred during software maintenance and testing.
Self-Instructional
Material 219
Software Quality  Quality of design and quality of conformance. The quality of design tells us
Assurance
that how well the software is designed. It measures the validity of the design
and requirements to create a worthwhile product.
 Benchmarking is easy to keep track of metrics after they have been defined.
NOTES
Such metrics help one in reviewing the improvements over time or comparing
the results with similar projects. Performance, cost, quality, response time,
features are all very important in a software. It is very important to know
what issues are important for customers.
 Pareto analysis is a charting technique which helps in identifying the leading
contributors (attributes/properties) to a given metric.
 Trending is about keeping track with the changes in metrics. Such tracking
helps one to know if the process is improving or getting worse.
 A software quality factor is a non-functional requirement for a software
program that is not called upon by the customer’s contract, but nevertheless
is a desirable requirement that enhances the software program quality.
 Consistency must be uniformity in notation, symbology, appearance and
terminology within the system.
 Security is the ability of protecting data against unauthorized access and
withstanding malicious interference with its operations. Apart from the
presence of appropriate security mechanisms such as access control,
authentication and encryption, security also involves the ability to withstand
malicious, intelligent attackers.
 ISO 9126 is an international standard for the evaluation of software quality.
 The fundamental objective of this standard is to address some well-known
human biases that can badly affect the perception and delivery of a software
development project.
 These biases include changing priorities after beginning a project or not
having any clear definitions of success. Through clarification and agreement
on the priorities of the project and then through conversion of abstract
priorities, output data can be validated against schema X with zero
intervention. ISO 9126 tries to develop a common understanding of the
objectives and goals of a project.
 Software quality is a multi-faceted and rather a vague concept. For any
software product, measures associated with its attributes should collectively
reflect likely user satisfaction with use of the product over its lifetime.
 International Standards Organization (ISO) is a consortium of sixty-three
countries established to formulate and foster standardization. ISO published
its 9000 series of standards in 1987. ISO certification serves as a reference
for contract between independent parties.

Self-Instructional
220 Material
  Software Engineering Institute (SEI) has developed a process maturity Software Quality
Assurance
framework known as capability maturity model to improve the software
process in an organization. In this model, software process maturity indicates
the extent to which a particular process is defined, managed, and controlled.
CMM identifies the inadequacies in the organization and determines the NOTES
processes to develop and maintain the software.
 This model helps the organization in selecting software process improvement
strategies by describing issues of software quality and improving the process.
 Each maturity level comprises Key Process Areas (KPA) to identify the
areas that need improvements in the organization.
 The International Organization for Standardization (ISO) 9000 standards
describe the elements in quality assurance, which outline the requirements
of good quality product in an organization. The elements comprise
organizational structure, procedures and resources that are needed to
implement quality assurance in the software. These standards also provide
auditing tools to make sure that they are properly implemented according
to the standards and meet the user requirements.
 One of the quality standards that are commonly used in practice is ISO
9001:2000. It is a quality management standard that is established for
improving the overall quality of the process and product in an organization.
It can be achieved by using appropriate management policies and practices.
 Quality system consists of a quality manual, which shows whether the manual
applies to the management. It also examines the procedures and processes
of the product.

10.11 KEY WORDS

 Software quality assurance activity: Software quality assurance activities

are concerned with verification and validation of the software process being
followed to accomplish the user requirements in the software.
 Functionality: A set of attributes that bear on the existence of a set of
functions and their specified properties.
 Reliability: A set of attributes that bear on the capability of software to
maintain its level of performance under stated conditions for a stated period
of time.
 Usability: A set of attributes that bear on the effort needed for use, and on
the individual assessment of such use, by a stated or implied set of users.
 Efficiency: A set of attributes that bear on the relationship between the
level of performance of the software and the amount of resources used,
under stated conditions.
Self-Instructional
Material 221
Software Quality  Maintainability: A set of attributes that bear on the effort needed to make
Assurance
specified modifications.
 Portability: A set of attributes that bear on the ability of software to be
transferred from one environment to another.
NOTES
 Capability Maturity Model (CMM): This model is used to improve the
software process in an organization.
 ISO 9000 quality standards: The International Organization for
Standardization (ISO) 9000 standards describes the elements in quality
assurance, which outline the requirements of good quality product in an
organization.

10.12 SELF ASSESSMENT QUESTIONS AND

EXERCISES

Short-Answer Questions
1. Explain the term product quality assurance activity.
2. Give the definition of software quality.
3. Name the conform specification for software quality.
4. Explain the term ISO 9126.
5. Write the three specifications of ISO standard.
6. Explain the term KPAs in CMM.
7. Write the principles of ISO 9000 quality standards.
Long-Answer Questions
1. Discuss about the software quality assurance activities and its types.
2. Describe in details various data analysis techniques with the help of examples.
3. Briefly explain the software quality factors giving appropriate examples.
4. Discuss in details ISO 9126 and its characteristics giving appropriate
examples.
5. Briefly explain the ISO standards and its various types with the help of
examples.
6. Explains the different levels of capability maturity model with the help of
diagram.
7. Give the comparison between ISO 9001 and SEI CMM.
8. Briefly explain the three models of ISO 9000 quality standards.

Self-Instructional
222 Material
 Software Quality
10.13 FURTHER READINGS Assurance

Hughes, Bob, Mike Cotterell and Rajib Mall. 2017. Software Project
Management (SIE), 6th Edition. New York: McGraw Hill Education. NOTES
Schach, Stephen R. 2005. Object Oriented and Classical Software Engineering.
New Delhi: Tata McGraw-Hill.
Pressman, Roger S. 1997. Software Engineering, a Practitioner’s Approach.
New Delhi: Tata McGraw-Hill.
Somerville, Ian. 2001. Software Engineering. New Delhi: Pearson Education.
Ghezzi, Carlo, Mehdi Jazayeri, and Dino Mandriolli. 1991. Fundamentals of
Software Engineering. New Delhi: Prentice-Hill of India.
Jawadekar, Waman S. 2004. Software Engineering: Principles and Practice.
New Delhi: Tata McGraw-Hill.
Jalote, Pankaj. 1991. An Integrated Approach to Software Engineering. New
Delhi: Narosa Publishing House.

Self-Instructional
Material 223
Computer Aided Software
Engineering (CASE)
Tools UNIT 11 COMPUTER AIDED
SOFTWARE ENGINEERING
NOTES
(CASE) TOOLS
Structure
11.0 Introduction
11.1 Objectives
11.2 CASE Concepts
11.3 Architecture of CASE Environment
11.4 Answers to Check Your Progress Questions
11.5 Summary
11.6 Key Words
11.7 Self Assessment Questions and Exercises
11.8 Further Readings

11.0 INTRODUCTION

The software complexity is increasing day by day with the changing need of users.
However, developing complex software is expensive and time consuming, if all
the activities involved in software development—analysis, design, coding, testing
and maintenance—are to be performed manually. To speed up the software
development process, a need arises to automate these activities. This led to the
development of a new concept of software development called Computer-Aided
Software Engineering (CASE).
Computer-Aided Software Engineering (CASE) is the domain of software
tools used to design and implement applications. CASE tools are similar to and
were partly inspired by Computer-Aided Design (CAD) tools used for designing
hardware products. CASE tools are used for developing high-quality, defect-
free, and maintainable software. CASE software is often associated with methods
for the development of information systems together with automated tools that
can be used in the software development process. Computer-aided software
engineering can be as simple as a single tool that supports a specific software
engineering activity or it can be as complex as a complete “Environment” comprising
tools, people, hardware, operating systems, networking, database, and several
other components.
In this unit, you will study about the CASE concepts, classification of CASE
tools, steps for CASE tool implementation, integrated CASE environment, and
architecture of CASE environment.

Self-Instructional
224 Material
 Computer Aided Software
11.1 OBJECTIVES Engineering (CASE)
Tools

After going through this unit, you will be able to:

 Understand the basics of CASE concepts NOTES
 Discuss about the classification of CASE tools
 Explain steps for CASE tool implementation
 Define the integrated CASE environment
 Elucidate on the architecture of CASE environment

11.2 CASE CONCEPTS

The software complexity is increasing day by day with the changing need of users.
However, developing complex software is expensive and time consuming, if all the
activities involved in software development—analysis, design, coding, testing and
maintenance—are to be performed manually. To speed up the software
development process, a need arises to automate these activities. This led to the
development of a new concept of software development called Computer-Aided
Software Engineering (CASE).
CASE can be described as an engineering approach that takes computer
assistance in software development and maintenance. The term CASE is used for a
new generation of tools that applies rigorous engineering principles to the development
and analysis of software specifications. CASE provides the software engineers with
the ability to automate almost all the software development activities that were initially
performed manually. Various tools are available that assist software engineers in
different phases of software development process and in umbrella activities like project
management, configuration management, etc. They provide an integrated homogenous
environment for the development of complex software systems.
The advantages of CASE tools are listed below.
 They reduce the software development time and cost by automating
many repetitive manual tasks.
 They help in creating good quality documentation and thus, a better
quality product.
 They help in creating more maintainable software systems.
A successful CASE tool should have the following characteristics:
 It must support standard software development methodology and
modelling techniques.

Self-Instructional
Material 225
Computer Aided Software  It must provide an integrated environment for software development.
Engineering (CASE)
Tools Integrated environment means that if any change is made in any phase,
it should be reflected in other phases.
 It must be flexible enough to offer choice in use of editors’ development
NOTES
environment and other tools.
 It must support the reverse engineering process, that is, it must be able
to generate the design model from already existing code.
 It must support integration with automatic testing tools.
 It must provide an online help.
Building Blocks for CASE
Computer-aided software engineering can be as simple as a single tool that supports
a specific software engineering activity or it can be as complex as a complete
“Environment” comprising tools, people, hardware, operating systems, networking,
database, and several other components. All these form the building blocks of
CASE with tools placed at the top and environment architecture placed at the
bottom as shown in Figure 11.1. Each building block forms a foundation for the
next higher-level building block. The building blocks of CASE include the following.
 CASE Tools: CASE tools automate, manage, and simplify the development
process. These can include tools for:
o Process Modelling and Management
o Project Planning
o Project Management
o Risk Analysis
o Documentation
o Quality Assurance
o Software Configuration Management
o Analysis and Design
o Programming
o Integration and Testing
o Reverse Engineering
o Re-Engineering
 Integration Framework: It is a set of specialized programs that facilitates
communication among various CASE tools.
 Portability Services: A set of services that allow CASE tools and their
integration framework to migrate across different hardware and software
(operating systems) platforms without major adaptive maintenance.

Self-Instructional
226 Material
  Environment Architecture: It consists of hardware platform and system Computer Aided Software
Engineering (CASE)
support that lays the ground for CASE. System support includes networking Tools
software, database management, and object management services.

NOTES

Fig. 11.1 CASE Building Blocks

Classification of CASE Tools

CASE tools can be classified on the basis of the functions they perform, their role
and use in various phases of the software development process, the environment
architecture that supports them and their cost. This section discusses the classification
on the basis of their use in various phases of software development process.
Depending on their use in various phases of software development process,
the CASE tools are classified into the following categories:
 Upper CASE Tools: These tools mainly concentrate on the high-level
activities of SDLC including analysis and design. They include tools for
analysis modeling and reports and forms generation.
 Lower CASE Tools: These tools mainly focus on the implementation
of the system. They include tools for coding, testing, debugging,
integration of software components, maintenance and configuration
management, and re-engineering and reverse engineering activities.
 Integrated CASE Tools: These tools provide an association between
the upper and lower CASE tools. Integrated CASE tools help in creating
an interconnected and organized environment in which the lower CASE
tools automatically generate the code for the design developed by the
upper CASE tools.
CASE Tools
As discussed earlier, CASE provides various tools that help in automating the
software development process. This section discusses various CASE tools that
support different phases of software development process. It also discusses some
desirable features of each CASE tool.

Self-Instructional
Material 227
Computer Aided Software Documentation Tools
Engineering (CASE)
Tools
Documentation is required in every phase of software engineering, preparing a
requirements document in analysis phase, design document in design phase, code
NOTES documentation in coding phase, test report in testing phase, and maintenance
document in maintenance phase. Therefore, 20 to 30 per cent of the software
development effort spends on documentation. In addition, all these documents
should be well organized and easier to understand. For this reason, a CASE tool
for documentation provides opportunities to improve productivity by reducing the
time needed to produce documents. Moreover, it should have the following features:
 The documents should be able to incorporate text and diagrams from the
central repository.
 The CASE tool should integrate with one or more desktop publishing
packages.
 It should be possible to export text, graphics, tables, and data dictionary
reports to the DTP package in standard forms, such as PostScript.

Analysis Tools
The first phase in the development process is requirements analysis and the output
of this phase is SRS, which serves as the basis for further phases. This phase has
to be performed carefully because it has been observed that most of the rework in
the project occurs due to unclear, incomplete, inconsistent, and ambiguous
requirements. Thus, a CASE tool for analysis should have the following features:
 It should support documentation. The documents produced should be easily
understandable to the stakeholders and the development team.
 It should be capable to track user requirements during various phases of
software development life cycle.
 It should support the creation of both functional and non-functional
requirements with related quality attributes.
 It should provide features for the assessment of the quality of requirements.
Design Tools
In the design phase, the requirements specified in the specification phase are translated
into the system design. The design developed should completely and correctly
describe the system to be built. In addition, it should be easily understandable to the
software developer, since the design serves as the model for the overall system.
Thus, a CASE tool for design should have the following features:
 It should have a strong support for models, which help in proper design
architecture.

Self-Instructional
228 Material
  It should support making the complex design diagrams at various levels, Computer Aided Software
Engineering (CASE)
such as at block level and module level. Tools
 It should support completeness and consistency checking on the models.
 It should help in resolving conflicts and ambiguity among the models. NOTES
 It should also help in optimizing the models to create good design
architecture.
Some of the design tools supported by CASE are listed below:
 Flowcharts
 Database Design Tools
 Structured Charts
 Program Design Language (PDL)
Programming Tools
In the implementation phase, the logical system designed in the design phase is
converted into the workable system. For this, the detailed design is converted into
the source code using any programming language. The code developed should be
easy to understand and should fulfill all the requirements of the user. Coding should
be done with extra care, since it creates the actual product to be delivered to the
user. Thus, a CASE tool for coding should have the following features:
 It should support the creation of system forms and reports.
 It should support creation of module templates in one or more programming
languages.
 It should automatically generate records, structures, and class definition
based on the contents of the data dictionary.
 It should support creation of database tables from the design documents.
 It should generate code for the user interface from the prototype definitions
or windows-based applications.
Several programming tools are used along with the programming language
to simplify the tasks of writing software code. Note that programming tools vary
from one programming language to another as they are developed according to a
particular programming language. However, sometimes a single programming tool
can be used in more than one programming language. Generally, programming
tools comprise text editors, supporting tools for a specific programming language,
and the framework required to run the software code.
Integration and Testing Tools
In testing phase, various test cases are designed and executed in order to verify
the correctness of the code. Test cases should be designed in such a way that the

Self-Instructional
Material 229
Computer Aided Software probability of detecting errors is high. In addition, a large number of test cases are
Engineering (CASE)
Tools required to test the overall program, which consumes a lot of time. Thus, a CASE
tool for testing should have the following features:
 It should support creation of test cases, which verifies the conformance of
NOTES
code to user requirements.
 It should support all types of testing like chapter testing, integration testing,
regression testing, performance testing, etc.
 It should support local and remote test execution.
 It should create a log of report.
 It should also support other third party testing tools.
 It should generate meaningful reports at the completion of each test case.
Maintenance Tools
Maintenance is an on going activity throughout the life of project, after it is delivered
to the user. It involves almost all the activities that are performed during the
development of software. A CASE tool for maintenance should have the following
features:
 If the requirement of the user changes, it should automatically reflect this
change in further stages of development process.
 It should support version control when any change takes place in the software
product.
 It should keep track of all the changes and their effects on the system
components.
 It should support all types of maintenance, that is, corrective, adaptive,
perfective and preventive.
Tools for Project Management
Developing a complex large project involves a team of people including analysts,
designers, software engineers, programmers and testers. In addition, this team
may be working at geographically dispersed location. Thus, a need arises for
effective management of software projects. Project management is an umbrella
activity, which involves project planning, cost estimation, project scheduling,
management of people, and monitoring and controlling all the activities of software
development process.
CASE tools provide a great help in the project management. A case tool
for project management should have the following features:
 It should support cost estimation and project scheduling.

Self-Instructional
230 Material
  It should provide estimation tools which helps in estimating effort required Computer Aided Software
Engineering (CASE)
for the project, project duration and the number of people required. Tools
 It should enable the project manager to define all the project tasks,
create a network of task, represent task interdependencies and model
NOTES
the amount of parallelism possible.
 It should allow monitoring of project using GANTT or PERT chart.
 It should allow tracking of events and milestones during project
development.
Integrated Case Environment
As discussed above, there are various tools available to support software
engineering activities. They help software engineers a lot in each phase of the
software development process. Although, using CASE tool individually or separately
in the development process is advantageous, the real benefits of CASE tool can
be achieved through integration. Integration requires the ability of one CASE tool
to accept the input from another CASE tool. CASE tools can be integrated in two
ways—horizontally and vertically.
In horizontal integration, tools at the same stage of development process
are integrated. For example, integration among E-R modelling tool and DFD
modelling tool during the analysis phase. Since, both the tools support analysis
phase, the same information serves the purpose of input for both of them. Such
integration helps the designer to crosscheck the data in two tools.
In vertical integration, tools at different stages of development process
are integrated. For example, a tool can be used to translate an E-R model to a
relational model. In such type of integration, output of one tool becomes the input
for the next tool. A sequence of such integration may automate the entire
development process.
Future of CASE
The current CASE tools are often poorly integrated with other automatic tools.
These tools are based on the methods that are inadequate enough for computer
support. Moreover, these tools do not provide support for complex configuration
management and automatic code generation. Their analysis and verification support
is very limited and is not based on any rigid and well-formulated theory. For these
reasons, these tools are not suitable for every situation. Therefore, a need arises
for the improvement in the functionality of the CASE tools. One of the important
features of the next generation CASE tools is the direct support of any adapted
software development methodology. For this, every organization should have a

Self-Instructional
Material 231
Computer Aided Software CASE administrator, who can tailor the CASE tool to a particular methodology.
Engineering (CASE)
Tools Other desirable features are as follows:
 It should provide help to aesthetically and automatically lay out the diagrams.
NOTES  Methods on which the tools are based should be improved in such a way
that they make use of the available analytical power of the computer support.
 It must support customization, which means, the user is allowed to define
new types of objects and connections.
 New algorithms and implementation architectures need to be developed
that can support a variety of representation forms (graphics, text, etc.) as
well as new representation media (three dimensional representation,
visualization, etc.).

11.3 ARCHITECTURE OF CASE ENVIRONMENT

The term CASE stands for Computer Aided Software Engineering. It means,
development and maintenance of software projects with help of various automated
software tools.
An environment is a collection of CASE tools or workbenches that attempts
to support the complete software process. This contrasts with tools that focus on
one specific task or a specific part of the life-cycle.
The architecture or design of a typical trendy CASE environment is graphically
shown below in Figure 11.2. The vital elements of a contemporary CASE
environment are a user interface (computer programs), tool set, Object
Management System (OMS), and a repository.

Self-Instructional Fig.11.2 Architecture of a Modern CASE Environment

232 Material
User Interface: The user interface provides a regular framework for accessing Computer Aided Software
Engineering (CASE)
the various tools so creating it easier for the users to act with the different tools Tools
and reducing the overhead of learning however the different tools are used.
Object Management System (OMS) and Repository: Different case tools
NOTES
represent the product as a group of entities, such as specification, design, text
data, project planning, etc. The management system maps these logical entities
such into the underlying storage management system, the repository.
CASE environments are classified by Fuggetta as follows:
1. Toolkits: Loosely coupled collections of tools. These typically build on
operating system workbenches, such as the UNIX Programmer’s
Workbench or the VMS VAX set.
2. Fourth Generation: These environments are also known as 4GL standing
for fourth generation language environments due to the fact that the early
environments were designed around specific languages, such as Visual Basic
(VB). They were the first environments to provide deep integration of multiple
tools. Typically these environments were focused on specific types of
applications.
3. Language-Centered: Environments based on a single often Object-
Oriented Language (OOL), such as the Symbolics Lisp Genera environment
or Visual Works Smalltalk from Parcplace. In these environments all the
operating system resources were objects in the OOL.
4. Integrated: The integrated environments are an example of what most IT
people tend to consider whenever they use the CASE. Environments, such as
IBM’s AD/Cycle, Andersen Consulting’s FOUNDATION, the ICL CADES
system, and DEC Cohesion. These environments attempt to cover the
complete life cycle from analysis to maintenance and provide an integrated
database repository for storing all artefacts of the software process. The
integrated software repository was the defining feature for these types of tools.
5. Process-Centered: The process-centered is considered as the most
determined type of integration. These environments attempt to not just
formally specify the analysis and design objects of the software process but
the actual process itself and to use that formal process to control and guide
software projects. Examples include East, Enterprise II, Process Wise,
Process Weaver, and Arcadia. As per the standard definition, these
environments were tied to some secure methodology since the software
process itself is part of the environment and can control many phases of
tool invocation.

Self-Instructional
Material 233
Computer Aided Software
Engineering (CASE)
Tools Check Your Progress
1. Give the definition of case.
NOTES 2. Write the advantage of CASE tools.
3. Explain the term programming tools.
4. Define the term tools project management.
5. Explain the term user interface.

11.4 ANSWERS TO CHECK YOUR PROGRESS

QUESTIONS

1. The software complexity is increasing day by day with the changing need of
users. However, developing complex software is expensive and time
consuming, if all the activities involved in software development—analysis,
design, coding, testing and maintenance—are to be performed manually.
To speed up the software development process, a need arises to automate
these activities. This led to the development of a new concept of software
development called Computer-Aided Software Engineering (CASE).
2. The advantages of CASE tools are listed below.
 They reduce the software development time and cost by automating
many repetitive manual tasks.
 They help in creating good quality documentation and thus, a better
quality product.
 They help in creating more maintainable software systems.
3. Programming tool, in this implementation phase, the logical system designed
in the design phase is converted into the workable system. For this, the
detailed design is converted into the source code using any programming
language. The code developed should be easy to understand and should
fulfill all the requirements of the user. Coding should be done with extra
care, since it creates the actual product to be delivered to the user.
4. Developing a complex large project involves a team of people including
analysts, designers, software engineers, programmers and testers. In addition,
this team may be working at geographically dispersed location. Thus, a
need arises for effective management of software projects. Project
management is an umbrella activity, which involves project planning, cost
estimation, project scheduling, management of people, and monitoring and
controlling all the activities of software development process.

Self-Instructional
234 Material
 5. The user interface provides a regular framework for accessing the various Computer Aided Software
Engineering (CASE)
tools so creating it easier for the users to act with the different tools and Tools
reducing the overhead of learning however the different tools are used.

NOTES
11.5 SUMMARY

 CASE can be described as an engineering approach that takes computer

assistance in software development and maintenance.
 The term CASE is used for a new generation of tools that applies rigorous
engineering principles to the development and analysis of software
specifications.
 CASE provides the software engineers with the ability to automate almost
all the software development activities that were initially performed manually.
Various tools are available that assist software engineers in different phases
of software development process and in umbrella activities like project
management, configuration management.
 Computer-aided software engineering can be as simple as a single tool that
supports a specific software engineering activity or it can be as complex as
a complete “environment” comprising tools, people, hardware, operating
systems, networking, database, and several other components.
 CASE tools can be classified on the basis of the functions they perform,
their role and use in various phases of the software development process,
the environment architecture that supports them and their cost.
 CASE provides various tools that help in automating the software
development process.
 Documentation is required in every phase of software engineering, preparing
a requirements document in analysis phase, design document in design phase,
code documentation in coding phase, test report in testing phase, and
maintenance document in maintenance phase.
 The first phase in the development process is requirements analysis and the
output of this phase is SRS, which serves as the basis for further phases.
This phase has to be performed carefully because it has been observed that
most of the rework in the project occurs due to unclear, incomplete,
inconsistent, and ambiguous requirements.
 The logical system designed in the design phase is converted into the
workable system. For this, the detailed design is converted into the source
code using any programming language. The code developed should be easy
to understand and should fulfil all the requirements of the user. Coding should
be done with extra care, since it creates the actual product to be delivered
to the user.

Self-Instructional
Material 235
Computer Aided Software  Several programming tools are used along with the programming language
Engineering (CASE)
Tools to simplify the tasks of writing software code. Note that programming tools
vary from one programming language to another as they are developed
according to a particular programming language.
NOTES
 Maintenance is an on going activity throughout the life of project, after it is
delivered to the user. It involves almost all the activities that are performed
during the development of software.
 Project management is an umbrella activity, which involves project planning,
cost estimation, project scheduling, management of people, and monitoring
and controlling all the activities of software development process.
 Integration requires the ability of one CASE tool to accept the input from
another CASE tool. CASE tools can be integrated in two ways—horizontally
and vertically.
 In horizontal integration, tools at the same stage of development process
are integrated.
 In vertical integration, tools at different stages of development process are
integrated.
 The current CASE tools are often poorly integrated with other automatic
tools. These tools are based on the methods that are inadequate enough for
computer support. Moreover, these tools do not provide support for
complex configuration management and automatic code generation.
 The term CASE stands for Computer Aided Software Engineering. It means,
development and maintenance of software projects with help of various
automated software tools.
 An environment is a collection of CASE tools or workbenches that attempts
to support the complete software process. This contrasts with tools that
focus on one specific task or a specific part of the life-cycle.
 User interface provides a regular framework for accessing the various tools
so creating it easier for the users to act with the different tools and reducing
the overhead of learning however the different tools are used.
 The integrated environments are an example of what most IT people tend
to consider whenever they use the CASE. Environments, such as IBM’s
AD/Cycle, Andersen Consulting’s FOUNDATION, the ICL CADES
system, and DEC Cohesion.

Self-Instructional
236 Material
  The process-centered is considered as the most determined type of Computer Aided Software
Engineering (CASE)
integration. These environments attempt to not just formally specify the Tools
analysis and design objects of the software process but the actual process
itself and to use that formal process to control and guide software projects.
NOTES
11.6 KEY WORDS

 Computer-Aided Software Engineering (CASE): Computer-Aided

Software Engineering (CASE) development and maintenance of software
projects with help of various automated software tools.
 CASE tools: CASE tools automate manage, and simplify the development
process.
 Maintenance tools: Maintenance is an ongoing activity throughout the life
of project, after it is delivered to the user.
 Horizontal integration: In horizontal integration, tools at the same stage
of development process are integrated.
 Vertical integration: In vertical integration, tools at different stages of
development process are integrated.

11.7 SELF ASSESSMENT QUESTIONS AND

EXERCISES

Short-Answer Questions
1. Explain the term CASE.
2. Write the features of CASE analysis.
3. List the classifications of CASE.
4. Differentiate between horizontal and vertical integration.
5. What are the features of a CASE tool for testing?
Long-Answer Questions
1. Differentiate between upper CASE tools and lower CASE tools. How do
these tools interact with each other? Explain with the help of examples.
2. Briefly explain the desirable features that a CASE tool should have testing.
3. Discuss about the integration and testing tools with the help of examples.
4. Describe the architecture of CASE environment with the help of diagram.

Self-Instructional
Material 237
Computer Aided Software
Engineering (CASE) 11.8 FURTHER READINGS
Tools

Hughes, Bob, Mike Cotterell and Rajib Mall. 2017. Software Project
NOTES Management (SIE), 6th Edition. New York: McGraw Hill Education.
Schach, Stephen R. 2005. Object Oriented and Classical Software Engineering.
New Delhi: Tata McGraw-Hill.
Pressman, Roger S. 1997. Software Engineering, a Practitioner’s Approach.
New Delhi: Tata McGraw-Hill.
Somerville, Ian. 2001. Software Engineering. New Delhi: Pearson Education.
Ghezzi, Carlo, Mehdi Jazayeri, and Dino Mandriolli. 1991. Fundamentals of
Software Engineering. New Delhi: Prentice-Hill of India.
Jawadekar, Waman S. 2004. Software Engineering: Principles and Practice.
New Delhi: Tata McGraw-Hill.
Jalote, Pankaj. 1991. An Integrated Approach to Software Engineering. New
Delhi: Narosa Publishing House.

Self-Instructional
238 Material
 Testing Techniques
BLOCK - IV
FUNDAMENTALS OF SOFTWARE QUALITY
ASSURANCE & TESTING TECHNIQUES
NOTES

UNIT 12 TESTING TECHNIQUES

Structure
12.0 Introduction
12.1 Objectives
12.2 Software Testing Concepts
12.2.1 Test Case Generation
12.3 Types of Software Testing
12.3.1 Software Testing Strategies
12.3.2 Levels of Testing
12.3.3 Unit Testing
12.3.4 Integration Testing
12.3.5 Validation Testing
12.3.6 System Testing
12.4 Automated Testing
12.5 Manual Testing
12.6 Testing Techniques
12.6.1 White Box Testing
12.6.2 Black Box Testing
12.6.3 Gray Box Testing
12.7 Answers to Check Your Progress Questions
12.8 Summary
12.9 Key Words
12.10 Self Assessment Questions and Exercises
12.11 Further Readings

12.0 INTRODUCTION

Software testing is an investigation conducted to provide stakeholders with

information about the quality of the software product or service under test. Software
testing can also provide an objective, independent view of the software to allow
the business to appreciate and understand the risks of software implementation.
Test techniques include the process of executing a program or application with the
intent of finding failures, and verifying that the software product is fit for use.
Unit testing refers to tests that verify the functionality of a specific section of
code, usually at the function level. In an object-oriented environment, this is usually
at the class level, and the minimal unit tests include the constructors and destructors.
Integration testing is any type of software testing that seeks to verify the interfaces
between components against a software design. Software components may be
Self-Instructional
Material 239
Testing Techniques integrated in an iterative way or all together (‘Big BanG’). Normally the former is
considered a better practice since it allows interface issues to be located more
quickly and fixed. System testing tests a completely integrated system to verify
that the system meets its requirements.
NOTES
White-box testing (also known as clear box testing, glass box testing,
transparent box testing, and structural testing) verifies the internal structures or
workings of a program, as opposed to the functionality exposed to the end-user.
In white-box testing, an internal perspective of the system (the source code), as
well as programming skills, are used to design test cases. The tester chooses
inputs to exercise paths through the code and determine the appropriate
outputsBlack-box testing (also known as functional testing) treats the software as
a ‘Black Box’, examining functionality without any knowledge of internal
implementation, without seeing the source code. The testers are only aware of
what the software is supposed to do, not how it does it. Black-box testing methods
include: equivalence partitioning, boundary value analysis, all-pairs testing, state
transition tables, decision table testing, fuzz testing, model-based testing, use
case testing, exploratory testing, and specification-based testing.
In this unit, you will study about the software testing concepts, types of
software testing, manual testing, automated testing, black box testing, and white
box testing techniques.

12.1 OBJECTIVES

After going through this unit, you will be able to:

 Understand the basics of software testing concepts
 Discuss about the various types of software testing
 Explain the manual testing
 Know about the automated testing
 Define the black box testing
 Elucidate on the white box testing techniques

12.2 SOFTWARE TESTING CONCEPTS

Software testing is a process which is used to identify the correctness, completeness

and quality of a software. IEEE defines testing as ‘The process of exercising or
evaluating a system or system component by manual or automated means
to verify that it satisfies specified requirements or to identify differences
between expected and actual results.’

Self-Instructional
240 Material
Software testing is often used in association with the terms ‘verification’ and Testing Techniques

‘validation’. Verification refers to the process of ensuring that the software is

developed according to its specifications. For verification, techniques like reviews,
analysis, inspections and walkthroughs are commonly used. While validation refers
to the process of checking that the developed software meets the requirements NOTES
specified by the user. Verification and validation can be summarized as:
Verification: Are we developing the software right?
Validation: Are we developing the right software?
Software testing evaluates a software by manual and automated means to ensure
that it is functioning in accordance with user requirements. Various advantages
associated with testing are listed below (also refer Figure 12.1):
 It removes errors which prevent a software from producing outputs
according to user requirements.
 It removes errors that lead to software failure.
 It determines whether the system meets business and user needs.
 It ensures that the software is developed according to user requirements.
 It improves quality of the software by removing maximum possible errors
from it.

Fig. 12.1 Advantages of Software Testing

Software testing comprises a set of activities which are planned before testing
begins. These activities are carried out for detecting errors that occur during various
phases of SDLC. The role of testing in the software development life cycle is listed
in Table 12.1.

Self-Instructional
Material 241
Testing Techniques Table 12.1 Role of Testing in Various Phases of SDLC
Software Development Phase Testing
Requirements Phase  Determines the test strategy
 Determines adequacy of requirements
NOTES  Generates functional test conditions
Design Phase  Determines consistency of design with requirements
 Determines adequacy of design
 Generates structural and functional test conditions
Coding Phase  Determines consistency with design.
 Determines adequacy of implementation
 Generates structural and functional test conditions for
programs/units
Test Phase  Determines adequacy of the test plan
 Tests application system

Installation and Maintenance Phase  Places tested system into production

 Modifies and retests.

Bugs, Error, Fault, Failure

The purpose of software testing is to detect bugs, errors, faults, and failures present
in the software. Bug is defined as a logical mistake which is caused by a software
developer while writing the software code. Error is defined as the difference
between the outputs produced by the software and the output desired by the user
(expected output). Fault is defined as the condition that leads to malfunctioning of
the software. Malfunctioning of software is caused due to several reasons, such as
change in the design, architecture or software code. Defect that causes error in
operation or negative impact is called failure. Failure is defined as the state in
which software is unable to perform a function according to user requirements.
Bugs, errors, faults and failures prevent software from performing efficiently and
hence, cause the software to produce unexpected outputs. Errors can be present
in the software due to the following reasons:
 Programming errors: Programmers can make mistakes while developing
the source code.
 Unclear requirements: The user is not clear about the desired requirements
or the developers are unable to understand the user requirements in a clear
and concise manner.
 Software complexity: The complexity of the current software can be difficult
to comprehend for someone who does not have prior experience in software
development.
 Changing requirements: The user may not understand the effects of change.
If there are minor changes or major changes, known and unknown
dependencies among parts of the project are likely to interact and cause
problems. This may lead to complexity of keeping track of changes and
ultimately may result in errors.
Self-Instructional
242 Material
  Time pressures: Maintaining schedule of software projects is difficult. When Testing Techniques

deadlines are not met, the attempt to speed up the work causes errors.
 Poorly documented code: It is difficult to maintain and modify a code that
is badly written or poorly documented. This causes errors.
NOTES
Note: In this unit, ‘error’ is used as a general term for ‘bugs’, ‘errors’, ‘faults’, and
‘failures’.

Who Performs the Testing?

Testing is an organizational issue which is performed either by the software
developers (who originally developed the software) or by an independent test
group (ITG), which comprises of software testers. The software developers are
considered to be the best persons to perform testing as they have the best
knowledge about the software. However, since software developers are involved
in the development process, they may have their own interest to show that the
software is error free, meets user requirements, and is within schedule and budget.
This vested interest hinders the process of testing.
To avoid this problem, the task of testing is assigned to an independent test
group which is responsible to detect errors that may have been neglected by the
software developers. ITG tests the software without any discrimination since the
group is not directly involved in the development process. However, the testing
group does not completely take over the testing process, instead it works with the
software developers in the software project to ensure that testing is performed in
an efficient manner. During the testing process, developers are responsible for
correcting the errors detected by the testing group.
Generally, an independent testing group forms a part of the software
development project team. This is because the group becomes involved during
the specification activity and stays involved (planning and specifying test procedures)
throughout the development process.
To plan and perform testing, software testers should have the knowledge
about the function for which the software has been developed, the inputs and how
they can be combined, and the environment in which the software will eventually
operate. This process is time-consuming and requires technical sophistication and
proper planning on the part of the testers. To achieve the technical know-how,
testers must not only have good development skills but also possess knowledge
about formal languages, graph theory and algorithms. Other factors that should be
kept in mind while performing testing are:
 Time available to perform testing
 Training required to acquaint testers to the software
 Attitude of testers
 Relationship between testers and developers
Note: Along with software testers, customers, end-users, and management also play
an important role in software testing. Self-Instructional
Material 243
Testing Techniques Characteristics of Software Test
There are several tests (such as unit and integration) used for testing a software.
Each test has its own characteristics. The following points, however, should be
NOTES noted.
 High probability of detecting errors: To detect maximum errors, the
tester should understand the software thoroughly and try to find the possible
ways in which the software can fail. In a program to divide two numbers,
for example, the possible way in which the program can fail is when 2 and
0 are given as inputs and 2 is to be divided by 0. In this case, a set of tests
should be developed that can demonstrate an error in the division operator.
 No redundancy: Resources and testing time are limited in software
development process. Thus, it is not beneficial to develop several tests,
which have the same intended purpose. Every test should have a distinct
purpose.
 Choose the most appropriate test: There can be different tests that have
the same intent but due to certain limitations, such as time and resource
constraint, only few of them are used. In such a case, the tests that have the
highest probability of finding errors should be considered.
 Moderate: A test is considered good if it is neither too simple nor too
complex. Many tests can be combined to form one test case. However,
this can increase the complexity and leave many errors undetected. Hence,
all tests should be performed separately.
Test Plan
A test plan describes how testing would be accomplished. Test plan is a document
which is developed to specify the objectives, scope, method and purpose of
software testing. This plan identifies test items, features to be tested, testing tasks
and the persons involved in performing these tasks. It also identifies the test
environment and the test design and measurement techniques that are to be used.
Note that a properly defined test plan is an agreement between testers and users
describing the role of testing in software.
A complete test plan helps the people who are not a part of the test group
to understand why product validation is needed and how is it to be performed. An
incomplete test plan can result in a failure to check how the software works on
different hardware and operating systems or when the software is used with other
software. To avoid this problem, IEEE states some components that should be
covered in a test plan. These components are listed in Table 12.2.

Self-Instructional
244 Material
 Table 12.2 Test Plan Components Testing Techniques

Component Purpose
Responsibilities Assigns responsibilities and keeps people on track and focussed.
Assumptions Avoids misunderstandings about schedules.
Test Outlines the entire process and maps specific tests. The testing scope,
schedule, and duration are also outlined. NOTES
Communication Communication plan (who, what, when, how about the people) is
developed.
Risk Analysis Identifies areas that are critical for success.
Defect Reporting Specifies how to document a defect so that it can be reproduced, fixed, and
retested.
Environment Specifies the technical environment, data, work area, and interfaces used in
testing. This reduces or eliminates misunderstandings and sources of
potential delay.

Test Case Design

A test case provides the description of inputs and their expected outputs to observe
whether the software or a part of the software is working correctly or not. IEEE
defines test case as ‘A set of input values, execution preconditions, expected
results and execution post conditions, developed for a particular objective
or test condition, such as to exercise a particular program path or to verify
compliance with a specific requirement.’ Generally, a test case contains
particulars, such as test case identifier, test case name, its objective, test conditions/
setup, input data requirements, steps and expected results.
Incomplete and incorrect test cases lead to incorrect and erroneous test
outputs. To avoid this, a test case should be developed in such a manner that it
checks a software with all possible inputs. This process is known as exhaustive
testing and the test case which is able to perform exhaustive testing is known as
an ideal test case. Generally, a test case is unable to perform exhaustive testing.
Therefore, a test case that gives satisfactory results is selected. In order to select
a test case, certain questions should be addressed.
 How is a test case selected?
 On what basis are certain elements of a program included or excluded from
a test case?
To provide answers to these questions, a test selection criterion is used. For
a given program and its specifications, a test selection criterion specifies the
conditions that should be satisfied by a set of test cases. If, for example, the criterion
is that all the control statements in a program are executed at least once during
testing, then a set of test cases which ensures that the specified condition is met
should be selected.
12.2.1 Test Case Generation
The process of generating test cases helps in locating problems in the requirements
or design of the software. To generate a test case, initially a criterion that evaluates
a set of test cases is specified. Then, a set of test cases that satisfy the specified
criterion is generated. The following two methods are used to generate test cases.
Self-Instructional
Material 245
Testing Techniques  Code-based test case generation: This approach, also known as
structure-based test case generation, is used to analyse the entire software
code to generate test cases. It considers only the actual software code to
generate test cases and is not concerned with the user requirements. Test
NOTES cases developed using this approach are generally used for unit testing.
These test cases can easily test statements, branches, special values, and
symbols present in the unit being tested.
 Specification-based test case generation: This approach uses
specifications which indicate the functions that are produced by a software
to generate test cases. In other words, it considers only the external view of
the software to generate test cases. Specification-based test case generation
is generally used for integration testing and system testing to ensure that the
software is performing the required task. Since this approach considers
only the external view of the software, it does not test the design decisions
and may not cover all statements of a program. Moreover, as test cases are
derived from specifications, the errors present in these specifications may
remain uncovered.
Several tools known as test case generators are used for generating test
cases. In addition to test case generation, these tools specify the components of
the software that are to be tested. An example of test case generator is ‘astra
quick test’, which captures business processes in the visual map and generates
data-driven tests automatically.
Test Case Specifications
The test plan is not concerned with the details of testing a unit. Moreover, it does
not specify the test cases to be used for testing units. Thus, test case specification
is done in order to test each unit separately. Depending on the testing method
specified in a test plan, features of unit that need to be tested are ascertained. The
overall approach stated in the test plan is refined into specific test methods and
into the criteria to be used for evaluation. Based on test methods and criteria, test
cases to test the unit are specified.
For each unit being tested, these test case specifications provide test cases,
inputs to be used in test cases, conditions to be tested by tests cases and outputs
expected from test cases. Generally, test cases are specified before they are used
for testing. This is because, testing has many limitations and effectiveness of testing
is highly dependent on the nature of test cases.
Test case specifications are written in the form of a document because the
quality of test cases needs to be evaluated. To evaluate the quality of test cases, a
test case review is done for which a formal document is needed. The review of
test case document ensures that test cases satisfy the chosen criteria and are
consistent with the policy specified in the test plan. The other benefit of specifying
test cases formally is that it helps testers to select a good set of test cases.
Self-Instructional
246 Material
 Testing Techniques
12.3 TYPES OF SOFTWARE TESTING

12.3.1 Software Testing Strategies

NOTES
To perform testing in a planned and systematic manner, software testing strategy is
developed. A testing strategy is used to identify the levels of testing which are to
be applied along with the methods, techniques, and tools to be used during testing.
This strategy also decides test cases, test specifications, test case decisions, and
puts them together for execution.
Developing a test strategy, which efficiently meets the requirements of an
organization, is critical to the success of software development in that organization.
Therefore, a software testing strategy should contain complete information about
the procedure to perform testing and the purpose and requirements of testing.
The choice of software testing strategy is highly dependent on the nature of
the developed software. For example, if the software is highly data intensive then
a strategy that checks structures and values properly to ensure that all inputs given
to the software are correct and complete should be developed. Similarly, if it is
transaction intensive then the strategy should be such that it is able to check the
flow of all the transactions. The design and architecture of the software are also
useful in choosing testing strategy.
A Strategic Approach to Software Testing
A number of software testing strategies are proposed for the testing process. All
these strategies provide the tester a template, which is used for testing. Generally,
all testing strategies have certain characteristics, which are listed below:
 Testing proceeds in an outward manner. It starts from testing the individual
units, progresses to integrating these units, and finally, moves to system
testing.
 Testing techniques used during different phases of software development
are different.
 Testing is conducted by the software developer and by an ITG.
 Testing and debugging should not be used synonymously. However, any
testing strategy must accommodate debugging with itself.
An efficient software testing strategy includes two types of tests, namely,
low-level tests and high-level tests. Low-level tests ensure the correct
implementation of small part of the source code and high-level tests ensure that
major software functions are validated according to user requirements. A testing
strategy sets certain milestones for the software such as final date for completion
of testing and the date of delivering the software. These milestones are important
when there is limited time to meet the deadline.

Self-Instructional
Material 247
Testing Techniques Verification and Validation
Software testing is often used in association with the terms ‘verification’ and
‘validation’. Verification refers to the process of ensuring that the software is
NOTES developed according to its specifications. For verification, techniques like reviews,
analysis, inspections and walkthroughs are commonly used. While validation refers
to the process of checking that the developed software meets the requirements
specified by the user. Verification and validation can be summarized thus as given
here.
Verification: Is the software being developed in the right way?
Validation: Is the right software being developed?
Types of Software Testing Strategies
There are different types of software testing strategies, which are selected by the
testers depending upon the nature and size of the software. The commonly used
software testing strategies are listed below (also refer Figure 12.2).
 Analytic testing strategy: This uses formal and informal techniques to
access and prioritize risks that arise during software testing. It takes a
complete overview of requirements, design, and implementation of objects
to determine the motive of testing. In addition, it gathers complete information
about the software, targets to be achieved, and the data required for testing
the software.
 Model-based testing strategy: This strategy tests the functionality of
software according to the real world scenario (like software functioning in
an organization). It recognizes the domain of data and selects suitable test
cases according to the probability of errors in that domain.
 Methodical testing strategy: It tests the functions and status of software
according to the checklist, which is based on user requirements. This strategy
is also used to test the functionality, reliability, usability, and performance of
software.
 Process-oriented testing strategy: It tests the software according to
already existing standards, such as IEEE standards. In addition, it checks
the functionality of software by using automated testing tools.
 Dynamic testing strategy: This tests the software after having a collective
decision of the testing team. Along with testing, this strategy provides
information about the software, such as test cases used for testing the errors
present in it.
 Philosophical testing strategy: It tests software assuming that any
component of software can stop functioning anytime. It takes help from
software developers, users and systems analysts to test the software.

Self-Instructional
248 Material
 Testing Techniques

NOTES

Fig. 12.2 Types of Software Testing Strategy

Developing a Software Testing Strategy

A testing strategy should be developed with intent to provide the most effective
and efficient way of testing the software. While developing testing strategy, some
questions arise, such as: when and what type of testing is to be done? What are
the objectives of testing? Who is responsible for performing testing? And what
outputs are produced as a result of testing? The inputs that should be available
while developing testing strategy are listed below.
 Type of development project.
 Complete information about the hardware and software components that
are required to develop the software.
 Risks involved.
 Description of the resources that are required for the testing.
 Description of all testing methods that are required to test various phases of
SDLC.
 Details of all the attributes that software is unable to provide. For example,
software cannot describe its own limitations.
The output produced by the software testing strategy includes a detailed
document, which indicates the entire test plan, including all test cases used during
the testing phase. Testing strategy also specifies a list of testing issues that need to
be resolved.
Organizing for Software Testing
Testing is an organizational issue, which is performed either by the software
developers (who originally developed the software) or by an independent test
group (ITG), which comprises software testers. The software developers are
Self-Instructional
Material 249
Testing Techniques considered to be the best persons to perform testing as they have the best
knowledge about the software. However, since software developers are involved
in the development process, they may have their own interest to show that the
software is error-free, meets user requirements, and is within schedule and budget.
NOTES This vested interest hinders the process of testing.
To avoid this problem, the task of testing is assigned to an Independent
Test Group (ITG), which is responsible to detect errors that may have been
neglected by the software developers. ITG tests the software without any
discrimination since the group is not directly involved in the development process.
However, the testing group does not completely take over the testing process;
instead, it works with the software developers in the software project to ensure
that testing is performed in an efficient manner. During the testing process, developers
are responsible for correcting the errors uncovered by the testing group.
Generally, an ITG forms a part of the software development project team.
This is because the group becomes involved during the specification activity and
stays involved (planning and specifying test procedures) throughout the development
process.
Various advantages and disadvantages associated with ITG are listed in
Table 12.3.
Table 12.3 Advantages and Disadvantages of ITG

Advantages Disadvantages
 ITG can more efficiently find defects  ITG may perform some tests that have
related to interaction among different already been performed by the
modules, system usability and developers. This results in duplication of
performance, and many other special cases effort as well as wastage of time.
 ITG serves the better solution than leaving  It is essential for the test group to be
testing to the developers. This is because physically collocated with the design
the developers have neither training nor group; otherwise, problems may arise.
any motivation for testing.
 Test groups can have better perception of  Keeping a separate group for testing
how reliable is the software before results in extra cost to the organization.
delivering it to the user.

Note: Along with software testers, customers, end-users, and management also play an
important role in software testing.

12.3.2 Levels of Testing

From a procedural point of view, software testing consists of a series of four steps
(levels) that are performed sequentially. These steps are described as follows.
 Unit testing: This testing aims at testing the individual units of software. It
makes heavy use of testing techniques that exercise specific control paths
to detect errors in each software component individually.

Self-Instructional
250 Material
  Integration testing: Once the individual units are tested, they are integrated Testing Techniques

and checked for interfaces between them. The integration testing focuses
on issues associated with verification and program construction as
components begin interacting with one another.
NOTES
 Validation testing: This testing provides the assurance that the software
constructed validates all the functional, behavioral, and performance
requirements established during requirements analysis.
 System testing: This testing tests the entire software and the system elements
as a whole. It ensures that the overall system functions according to the user
requirements.
Strategic Issues
There are certain issues that need to be addressed for the successful implementation
of software testing strategy. These issues are listed below.
 In addition to detecting errors, a good testing strategy should also assess
portability and usability of the software.
 It should use quantifiable manner to specify software requirements such as
outputs expected from software, test effectiveness, and mean time to failure
which should be clearly stated in the test plan.
 It should improve testing method continuously to make it more effective.
 Test plans that support rapid cycle testing should be developed. The feedback
from rapid cycle testing can be used to control the corresponding strategies.
 It should develop robust software, which is able to test itself using debugging
techniques.
 It should conduct formal technical reviews to evaluate the test cases and
test strategy. The formal technical reviews can detect errors and
inconsistencies present in the testing process.
Test Strategies for Conventional Software
The test strategies chosen by most software teams for testing conventional software
generally fall between two extremes. At one extreme is the unit testing where the
individual components of the software are tested. While at the other extreme is the
integration testing that facilitates the integration of components into a system and
ends with tests that examine the integrated system.
12.3.3 Unit Testing
Unit testing is performed to test the individual units of software. Since the software
comprises various units/modules, detecting errors in these units is simple and
consumes less time, as they are small in size. However, it is possible that the
outputs produced by one unit become input for another unit. Hence, if incorrect
output produced by one unit is provided as input to the second unit then it also
Self-Instructional
Material 251
Testing Techniques produces wrong output. If this process is not corrected, the entire software may
produce unexpected outputs. To avoid this, all the units in the software are tested
independently using unit testing (refer Figure 12.3).

NOTES

Fig. 12.3 Unit Testing

Unit testing is not just performed once during the software development,
but repeated whenever the software is modified or used in a new environment.
Some other points noted about unit testing are listed below.
 Each unit is tested separately regardless of other units of software.
 The developers themselves perform this testing.
 The methods of white box testing are used in this testing.
Unit testing is used to verify the code produced during software coding and
is responsible for assessing the correctness of a particular unit of source code. In
addition, unit testing performs the following functions.
 It tests all control paths to uncover maximum errors that occur during the
execution of conditions present in the unit being tested.
 It ensures that all statements in the unit have been executed at least once.
 It tests data structures (like stacks, queues) that represent relationships among
individual data elements.
 It checks the range of inputs given to units. This is because every input
range has a maximum and minimum value and the input given should be
within the range of these values.
 It ensures that the data entered in variables is of the same data type as
defined in the unit.
 It checks all arithmetic calculations present in the unit with all possible
combinations of input values.

Self-Instructional
252 Material
Unit testing methods Testing Techniques

Unit testing is performed by conducting a number of unit tests where each unit test
checks an individual component that is either new or modified. A unit test is also
referred to as a module test as it examines the individual units of code that constitute NOTES
the program and eventually the software. In a conventional structured programming
language such as C, the basic unit is a function or subroutine while in object-
oriented language such as C++, the basic unit is a class.
Various tests that are performed as a part of unit testing are listed below
(also refer Figure 12.4).
 Module interface: This is tested to check whether information flows in a
proper manner in and out of the ‘unit’ being tested. Note that test of data-
flow (across a module interface) is required before any other test is initiated.
 Local data structure: This is tested to check whether temporarily stored
data maintains its integrity while an algorithm is being executed.
 Boundary conditions: These are tested to check whether the module
provides the desired functionality within the specified boundaries.
 Independent paths: These are tested to check whether all statements in a
module are executed at least once. Note that in this testing, the entire control
structure should be exercised.
 Error-handling paths: After successful completion of various tests, error-
handling paths are tested.

Fig. 12.4 Unit Testing Methods

Unit test case generation

Various unit test cases are generated to perform unit testing. Test cases are designed
to uncover errors that occur due to erroneous computations, incorrect comparisons,

Self-Instructional
Material 253
Testing Techniques and improper control flow. A proper unit test case ensures that unit testing is
performed efficiently. To develop test cases, the following points should always be
considered.
 Expected functionality: A test case is created for testing all functionalities
NOTES
present in the unit being tested. For example, an SQL query is given that
creates Table_A and alters Table_B. Then a test case is developed
to make sure that Table_A is created and Table_B is altered.
 Input values: Test cases are developed to check the various aspects of
inputs, which are discussed here.
o Every input value: A test case is developed to check every input value,
which is accepted by the unit being tested. For example, if a program is
developed to print a table of five, then a test case is developed which
verifies that only five is entered as input.
o Validation of input: Before executing software, it is important to verify
whether all inputs are valid. For this purpose, a test case is developed
which verifies the validation of all inputs. For example, if a numeric field
accepts only positive values, then a test case is developed to verify that
the numeric field is accepting only positive values.
o Boundary conditions: Generally, software fails at the boundaries of
input domain (maximum and minimum value of the input domain). Thus,
a test case is developed, which is capable of detecting errors that caused
the software to fail at the boundaries of input domain. For example,
errors may occur while processing the last element of an array. In this
case, a test case is developed to check if an error occurs while processing
the last element of the array.
o Limitation of data types: Variable that holds data types has certain
limitations. For example, if a variable with data type long is executed
then a test case is developed to ensure that the input entered for the
variable is within the acceptable limit of long data type.
 Output values: A test case is designed to determine whether the desired
output is produced by the unit. For example, when two numbers, ‘2’ and
‘3’ are entered as input in a program that multiplies two numbers, a test
case is developed to verify that the program produces the correct output
value, that is, ‘6’.
 Path coverage: There can be many conditions specified in a unit. For
executing all these conditions, many paths have to be traversed. For example,
when a unit consists of tested ‘if’ statements and all of them are to be
executed, then a test case is developed to check whether all these paths are
traversed.
 Assumptions: For a unit to execute properly, certain assumptions are made.
Test cases are developed by considering these assumptions. For example,
Self-Instructional
254 Material
 a test case is developed to determine whether the unit generates errors in Testing Techniques

case the assumptions are not met.

 Abnormal terminations: A test case is developed to check the behavior
of a unit in case of abnormal termination. For example, when a power cut
NOTES
results in termination of a program due to shutting down of the computer, a
test case is developed to check the behavior of a unit as a result of abnormal
termination of the program.
 Error messages: Error messages that appear when the software is executed
should be short, precise, self-explanatory, and free from grammatical
mistakes. For example, if ‘print’ command is given when a printer is not
installed, error message that appears should be ‘Printer not installed’ instead
of ‘Problem has occurred as no printer is installed and hence unable to
print’. In this case, a test case is developed to check whether the error
message displayed is according to the condition occurring in the software.
Unit testing procedure
Unit tests can be designed before coding begins or after the code is developed.
Review of this design information guides the creation of test cases, which are used
to detect errors in various units. Since a component is not an independent program,
the drivers and/or stubs are used to test the units independently. Driver is a module
that takes input from test case, passes this input to the unit to be tested and prints
the output produced. Stub is a module that works as a unit referenced by the unit
being tested. It uses the interface of the subordinate unit, does minimum data
manipulation, and returns control back to the unit being tested (refer Figure 12.5).

Fig. 12.5 Unit Testing Environment

Note: Drivers and stubs are not delivered with the final software product. Thus, they
represent an overhead.

12.3.4 Integration Testing

Once unit testing is complete, integration testing begins. In integration testing, the
units validated during unit testing are combined to form a subsystem. The integration
testing is aimed at ensuring that all the modules work properly as per the user
requirements when they are put together (that is, integrated).
Self-Instructional
Material 255
Testing Techniques The objective of integration testing is to take all the tested individual modules,
integrate them, test them again, and develop the software, which is according to
design specifications (refer Figure 12.6). Some other points that are noted about
integration testing are listed below.
NOTES
 It ensures that all modules work together properly and transfer accurate
data across their interfaces.
 It is performed with an intention to uncover errors that lie in the interfaces
among the integrated components.
 It tests those components that are new or have been modified or affected
due to a change.

Fig. 12.6 Integration of Individual Modules

The big bang approach and incremental integration approach are used
to integrate modules of a program. In the big bang approach, initially all modules
are integrated and then the entire program is tested. However, when the entire
program is tested, it is possible that a set of errors is detected. It is difficult to
correct these errors since it is difficult to isolate the exact cause of the errors when
the program is very large. In addition, when one set of errors is corrected, new
sets of errors arise and this process continues indefinitely.
To overcome this problem, incremental integration is followed. The
incremental integration approach tests program in small increments. It is easier
to detect errors in this approach because only a small segment of software code is
tested at a given instance of time. Moreover, interfaces can be tested completely if
this approach is used. Various kinds of approaches are used for performing
incremental integration testing, namely, top-down integration testing, bottom-
up integration testing, regression testing, and smoke testing.
Top-down integration testing
In this testing, the software is developed and tested by integrating the individual
modules, moving downwards in the control hierarchy. In top-down integration
testing, initially only one module known as the main control module is tested.

Self-Instructional
256 Material
After this, all the modules called by it are combined with it and tested. This Testing Techniques

process continues till all the modules in the software are integrated and tested.
It is also possible that a module being tested calls some of its subordinate
modules. To simulate the activity of these subordinate modules, a stub is written.
NOTES
Stub replaces modules that are subordinate to the module being tested. Once the
control is passed to the stub, it manipulates the data as least as possible, verifies
the entry, and passes the control back to the module under test (refer Figure
12.7). To perform top-down integration testing, the following steps are used.
1. The main control module is used as a test driver and all the modules that are
directly subordinate to the main control module are replaced with stubs.
2. The subordinate stubs are then replaced with actual modules, one stub at a
time. The way of replacing stubs with modules depends on the approach
(depth first or breadth first) used for integration.
3. As each new module is integrated, tests are conducted.
4. After each set of tests is complete, its time to replace another stub with
actual module.
5. In order to ensure no new errors have been introduced, regression testing
may be performed.

Fig. 12.7 Top-down Integration Module

Top-down integration testing uses either depth-first integration or

breadth-first integration for integrating the modules. In depth-first
integration, the modules are integrated starting from left and then move down
in the control hierarchy. As shown in Figure 12.8(a), initially, modules A1,
A2, A5 and A7 are integrated. Then, module A6 integrates with module A2.
After this, control moves to the modules present at the centre of control
hierarchy, that is, module A3 integrates with module A1 and then module A8
integrates with module A3. Finally, the control moves towards right, integrating
module A4 with module A1.
In breadth-first integration, initially all modules at the first level are
integrated moving downwards, integrating all modules at the next lower levels. As

Self-Instructional
Material 257
Testing Techniques shown in Figure 12.8(b), initially modules A2, A3, and A4 are integrated with
module A1 and then it moves down integrating modules A5 and A6 with module
A2 and module A8 with module A3. Finally, module A7 is integrated with module
A5.
NOTES

(a) Depth-first Integration (b) Breadth-first Integration

Fig. 12.8 Top-down Integration

Various advantages and disadvantages associated with top-down integration

are listed in Table 12.4.
Table 12.4 Advantages and Disadvantages of Top-down Integration

Advantages Disadvantages

 Behavior of modules at high level is  Delays the verification of behavior of

verified early. modules present at lower levels.
 None or only one driver is required.  Large numbers of stubs are required
 Modules can be added one at a time in case the lowest level of software
with each step. contains many functions.

 Supports both breadth-first method  Since stubs replace modules present

and depth-first method. at lower levels in the control
hierarchy, no data flows upward in
 Modules are tested in isolation from program structure. To avoid this,
other modules. tester has to delay many tests until
stubs are replaced with actual
modules or has to integrate software
from the bottom of the control
hierarchy moving upward.
 Module cannot be tested in isolation
from other modules because it has to
invoke other modules.

Bottom-up integration testing

In this testing, individual modules are integrated starting from the bottom and then
moving upwards in the hierarchy. That is, bottom-up integration testing combines
and tests the modules present at the lower levels proceeding towards the modules
present at higher levels of the control hierarchy.
Self-Instructional
258 Material
 Some of the low-level modules present in software are integrated to form Testing Techniques

clusters or builds (collection of modules). A test driver that coordinates the test
case input and output is written and the clusters are tested. After the clusters have
been tested, the test drivers are removed and the clusters are integrated, moving
upwards in the control hierarchy. NOTES

Fig. 12.9 Bottom-up Integration

Figure 12.9 shows modules, drivers, and clusters in bottom-up integration.

The low-level modules A4, A5, A6, and A7 are combined to form cluster C1.
Similarly, modules A8, A9, A10, A11, and A12 are combined to form cluster
C2. Finally, modules A13 and A14 are combined to form cluster C3. After
clusters are formed, drivers are developed to test these clusters. Drivers D1, D2,
and D3 test clusters C1, C2, and C3 respectively. Once these clusters are tested,
drivers are removed and clusters are integrated with the modules. Cluster C1 and
cluster C2 are integrated with module A2. Similarly, cluster C3 is integrated with
module A3. Finally, both the modules A2 and A3 are integrated with module A1.
Various advantages and disadvantages associated with bottom-up
integration are listed in Table 12.5.
Table 12.5 Advantages and Disadvantages of Bottom-up integration

Advantages Disadvantages

 Behavior of modules at lower levels  Delays in verification of modules at

is verified earlier. higher levels.
 No stubs are required.  Large numbers of drivers are required
 Uncovers errors that occur at the to test clusters.
lower levels in software.
 Modules are tested in isolation from
other modules.

Self-Instructional
Material 259
Testing Techniques Regression testing
Software undergoes changes every time a new module is integrated with the existing
subsystem (refer Figure 12.10). Changes can occur in the control logic or input/
NOTES output media, and so on. It is possible that new data-flow paths are established as
a result of these changes, which may cause problems in the functioning of some
parts of the software that was previously working perfectly. In addition, it is also
possible that new errors may surface during the process of correcting existing
errors. To avoid these problems, regression testing is used.

Fig. 12.10 Addition of Module in Integration Testing

Regression testing ‘re-tests’ the software or part of it to ensure that the

components, features, and functions, which were previously working properly, do
not fail as a result of the error correction process and integration of modules. It is
regarded as an important activity as it helps in ensuring that changes (due to error
correction or any other reason) do not result in additional errors or unexpected
outputs from other system components.
To understand the need of regression testing, suppose an existing module
has been modified or a new function is added to the software. These changes may
result in errors in other modules of the software that were previously working
properly. To illustrate this, consider the part of the code written below that is
working properly.
x: = b + 1 ;
proc (z);
b: = x + 2; x: = 3;
Now suppose that in an attempt to optimize the code, it is transformed into
the following.
proc(z);
b:= b + 3;
x:= 3;
Self-Instructional
260 Material
 This may result in an error if procedure proc accesses variable x. Thus, Testing Techniques

testing should be organized with the purpose of verifying possible degradations of

correctness or other qualities due to later modifications. During regression testing,
a subset of already defined test cases is re-executed on the changed software so
that errors can be detected. Test cases for regression testing consist of three different NOTES
types of tests, which are listed below.
 Tests that check all functions of the software
 Tests that check the functions that can be affected due to changes
 Tests that check the modified software modules.
The advantages and disadvantages associated with regression testing are
listed in Table 12.6.
Table 12.6 Advantages and Disadvantages of Regression Testing

Advantages Disadvantages

 Ensures that the unchanged parts of a  Time consuming activity.

software work properly.
 Ensures that all errors that have  Considered to be expensive.
occurred in the software due to
modifications are corrected and are
not affecting the working of software.

Smoke testing
Smoke testing is defined as an approach of integration testing in which a subset of
test cases designed to check the main functionality of software are used to test
whether the vital functions of the software work correctly. This testing is best
suitable for testing time-critical software as it permits the testers to evaluate the
software frequently.
Smoke testing is performed when the software is under development. As
the modules of the software are developed, they are integrated to form a ‘cluster’.
After the cluster is formed, certain tests are designed to detect errors that prevent
the cluster to perform its function. Next, the cluster is integrated with other clusters
thereby leading to the development of the entire software, which is smoke tested
frequently. A smoke test should possess the following characteristics.
 It should run quickly.
 It should try to cover a large part of the software and if possible the entire
software.
 It should be easy for testers to perform smoke testing on the software.
 It should be able to detect all errors present in the cluster being tested.
 It should try to find showstopper errors.
Generally, smoke testing is conducted every time a new cluster is developed
and integrated with the existing cluster. Smoke testing takes minimum time to detect Self-Instructional
Material 261
Testing Techniques errors that occur due to integration of clusters. This reduces the risk associated
with the occurrence of problems, such as introduction of new errors in the software.
A cluster cannot be sent for further testing unless smoke testing is performed on it.
Thus, smoke testing determines whether the cluster is suitable to be sent for further
NOTES testing. Other benefits associated with smoke testing are listed below.
 Minimizes the risks, which are caused due to integration of different
modules: Since smoke testing is performed frequently on the software, it
allows the testers to uncover errors as early as possible, thereby reducing
the chance of causing severe impact on the schedule when there is delay in
uncovering errors.
 Improves quality of the final software: Since smoke testing detects both
functional and architectural errors as early as possible, they are corrected
early, thereby resulting in a high-quality software.
 Simplifies detection and correction of errors: As smoke testing is
performed almost every time a new code is added, it becomes clear that
the probable cause of errors is the new code.
 Assesses progress easily: Since smoke testing is performed frequently,
it keeps track of the continuous integration of modules, that is, the
progress of software development. This boosts the morale of software
developers.
Integration test documentation
To understand the overall procedure of software integration, a document known
as test specification is prepared. This document provides information in the form
of a test plan, test procedure, and actual test results.

Fig. 12.11 Test Specification Document

Self-Instructional
262 Material
 Figure 12.11 shows the test specification document, which comprises the Testing Techniques

following sections.
 Scope of testing: Outlines the specific design, functional, and performance
characteristics of the software that need to be tested. In addition, it describes
NOTES
the completion criteria for each test phase and keeps track of the constraints
that occur in the schedule.
 Test plan: Describes the testing strategy to be used for integrating the
software. Testing is classified into two parts, namely, phases and builds.
Phases describe distinct tasks that involve various subtasks. On the other
hand, builds are groups of modules that correspond to each phase. Some
of the common test phases that require integration testing include user
interaction, data manipulation and analysis, display outputs, database
management, and so on. Every test phase consists of a functional category
within the software. Generally, these phases can be related to a specific
domain within the architecture of the software. The criteria commonly
considered for all test phases include interface integrity, functional validity,
information content, and performance.
In addition to test phases and builds, a test plan should also include the
following.
o A schedule for integration, which specifies the start and end date for
each phase.
o A description of overhead software that focuses on the characteristics
for which extra effort may be required.
o A description of the environment and resources required for the testing.
 Test procedure ‘n’: Describes the order of integration and the
corresponding unit tests for modules. Order of integration provides
information about the purpose and the modules that are to be tested. Unit
tests are performed for the developed modules along with the description
of tests for these modules. In addition, test procedure describes the
development of overhead software, expected results during integration
testing, and description of test case data. The test environment and tools or
techniques used for testing are also mentioned in a test procedure.
 Actual test results: Provides information about actual test results and
problems that are recorded in the test report. With the help of this information,
it is easy to carry out software maintenance.
 References: Describes the list of references that are used for preparing
user documentation. Generally, references include books and websites.
 Appendices: Provides information about the test specification document.
Appendices serve as a supplementary material that is provided at the end
of the document.

Self-Instructional
Material 263
Testing Techniques Test Strategies for Object-Oriented Software
Like conventional software, the software testing in object-oriented (OO) software
also aims to uncover maximum errors with minimum effort. However as the nature
NOTES of object-oriented software is different from that of conventional software, the
test strategies as well as testing techniques used for object-oriented software are
also differ.
Unit testing in OO context
In object-oriented environment, the concept of unit is different. Here, the focus of
unit testing is the class (or an instance of a class, usually called object), which is an
encapsulated package binding the data and the operations that can be performed
on these data together. But the smallest testable units in object-oriented software
are the operations defined inside the class. Since in OO environment, a single
operation may belong to many classes, it is ineffective to test any operation in a
standalone fashion, as we do in conventional unit testing approach; rather an
operation needs to be tested as a part of class. The class testing for object-oriented
software is equivalent to the unit testing of conventional software. However, unlike
unit testing of conventional software, it is not driven by the details of modules and
data across module interfaces. Rather, it focuses on the operations defined inside
the class and the state behavior of class.
Integration testing in OO context
The object-oriented software do not necessarily follow a hierarchical structure
due to which the conventional top-down and bottom-up integration approaches
are of little use for them. Moreover, conventional incremental integration approach
(which means integrating operations one at a time into a class) also seems impossible
because the operation being integrated into a class may need to interact directly or
indirectly with other operations that form the class. To avoid such problems, two
different integration approaches, including thread-based testing and use-based
testing, are adopted for the integration testing of OO software.
In thread-based testing approach, the set of classes that need to respond
an input or an event are determined. Each such set of classes is said to form a
thread. After determining the sets of classes forming threads, each thread is
integrated and tested individually. Regression testing is also performed to ensure
that no error occur as a result of integration. On the other hand, in use-based
testing approach, the integration process starts with the independent classes
(the classes that either do not or do have a little collaboration with other classes).
After the independent classes have been integrated and tested, the integration
testing proceeds to next layer of classes called dependent classes which make
use of independent classes. This integration procedure continues until the entire
system has been integrated and tested.

Self-Instructional
264 Material
Test Strategies for Web Applications Testing Techniques

The test strategy for Web applications (WebApps) conforms to the basic principles
used for all software testing and follows the strategy and testing tactics recommended
for object-oriented software. The steps followed in the strategic approach used NOTES
for WebApps are summarized below.
1. Examine the content model for the WebApp to reveal errors.
2. Examine the interface model for the WebApp to ascertain whether all the
use-cases can be conciliated.
3. Examine the design model for the WebApp to find out navigation errors.
4. Test the user interface to disclose errors in the presentation.
5. Perform unit testing for each functional component.
6. Test the navigation across the architecture.
7. Implement the WebApp in many different environmental configurations and
check whether it is compatible with each environmental configuration.
8. Conduct the security testing with an aim to exploit vulnerabilities within the
WebApp or in its environment.
9. Conduct the performance testing.
10. Make the WebApp tested by the end users and evaluate the results obtained
from them for content and navigation errors, performance and reliability of
WebApp, compatibility and usability concerns.
12.3.5 Validation Testing
After the individual components of a system have been unit tested, assembled as a
complete system, and the interfacing errors have been detected as well as corrected,
the validation testing begins. This testing is performed to ensure that the functional,
behavioral and performance requirements of the software are met. IEEE defines
validation testing as a ‘formal testing with respect to user needs, requirements,
and business processes conducted to determine whether or not a system
satisfies the validation criteria and to enable the user, customers or other
authorized entity to determine whether or not to accept the system’.
During validation testing, the software is tested and evaluated by a group of
users either at the developer’s site or user’s site. This enables the users to test the
software themselves and analyze whether it is meeting their requirements. To perform
acceptance testing, a predetermined set of data is given to the software as input. It
is important to know the expected output before performing acceptance testing so
that outputs produced by the software as a result of testing can be compared with
them. Based on the results of tests, users decide whether to accept or reject the
software. That is, if both outputs (expected and produced) match, the software is
considered to be correct and is accepted; otherwise, it is rejected.

Self-Instructional
Material 265
Testing Techniques The various advantages and disadvantages associated with validation testing
are listed in Table 12.7.
Table 12.7 Advantages and Disadvantages of Validation Testing
NOTES
Advantages Disadvantages

 Gives user an opportunity to ensure  The users may provide feedback

that software meets user without having proper knowledge of
requirements, before actually the software.
accepting it from the developer.
 Enables both users and software  Since users are not professional
developers to identify and resolve testers, they may not able to either
problems in software. discover all software failures or
 Determines the readiness (state of accurately describe some failures.
being ready to operate) of software to
perform operations.
 Decreases the possibility of software
failure to a large extent.

Alpha and beta testing

Since the software is intended for large number of users, it is not possible to
perform validation testing with all the users. Therefore, organizations engaged in
software development use alpha and beta testing as a process to detect errors by
allowing a limited number of users to test the software.
Alpha testing
Alpha testing is considered as a form of internal acceptance testing in which the
users test the software at the developer’s site (refer Figure 12.12). In other words,
this testing assesses the performance of the software in the environment in which it
is developed. On completion of alpha testing, users report the errors to software
developers so that they can correct them.

Fig. 12.12 Alpha Testing

Some advantages of alpha testing are listed below.

 It identifies all the errors present in the software.
 It checks whether all the functions mentioned in the requirements are
implemented properly in the software.
Self-Instructional
266 Material
Beta testing Testing Techniques

Beta testing assesses the performance of the software at user’s site. This testing is
‘live’ testing and is conducted in an environment, which is not controlled by the
developer. That is, this testing is performed without any interference from the NOTES
developer (refer Figure 12.13). Beta testing is performed to know whether the
developed software satisfies the user requirements and fits within the business
processes.

Fig. 12.13 Beta Testing

Note that beta testing is considered as external acceptance testing which

aims to get feedback from the potential customers. For this, the system and the
limited public tests (known as beta versions) are made available to the groups of
people or the open public (for getting more feedback). These people test the
software to detect any faults or bugs that may not have been detected by the
developers and report their feedback. After acquiring the feedback, the system is
modified and released either for sale or for further beta testing.
The advantages of beta testing are listed below.
 It evaluates the entire documentation of software. For example, it examines
the detailed description of software code, which forms a part of
documentation of software.
 It checks whether software is operating successfully in user environment or
not.
12.3.6 System Testing
Software is integrated with other elements such as hardware, people, and database
to form a computer-based system. This system is then checked for errors using
system testing. IEEE defines system testing as ‘A testing conducted on a complete,
integrated system to evaluate the system’s compliance with its specified
requirement.’
In system testing, the system is tested against non-functional requirements
such as accuracy, reliability, and speed. The main purpose is to validate and verify
the functional design specifications and to check how integrated modules work
together. The system testing also evaluates the system’s interfaces to other
applications and utilities as well as the operating environment.
Self-Instructional
Material 267
Testing Techniques During system testing, associations between objects (like fields), control
and infrastructure, and the compatibility of the earlier released software versions
with new versions are tested. System testing also tests some properties of the
developed software, which are essential for users. These properties are listed
NOTES below.
 Usable: Verifies that the developed software is easy to use and is
understandable.
 Secure: Verifies that the access to important or sensitive data is restricted
even for those individuals who have authority to use the software.
 Compatible: Verifies that the developed software works correctly in
conjunction with existing data, software and procedures.
 Documented: Verifies that the manuals that give information about the
developed software are complete, accurate and understandable.
 Recoverable: Verifies that there are adequate methods for recovery in
case of failure.
System testing requires a series of tests to be conducted because software
is only a component of computer-based system and finally it is to be integrated
with other components, such as information, people, and hardware. The test plan
plays an important role in system testing as it describes the set of test cases to be
executed, the order of performing different tests, and the required documentation
for each test. During any test, if a defect or error is found, all the system tests that
have already been executed must be re-executed after the repair has been made.
This is required to ensure that the changes made during error correction do not
lead to other problems.
While performing system testing, conformance tests and reviews can also
be conducted to check the conformance of the application (in terms of
interoperability, compliance, and portability) with corporate or industry standards.
System testing is considered to be complete when the outputs produced by
the software and the outputs expected by the user are either in line or the difference
between the two is within permissible range specified by the user. Various kinds of
testing performed as a part of system testing (refer Figure 12.14) are recovery
testing, security testing, stress testing, and performance testing.

Self-Instructional
268 Material
 Testing Techniques

NOTES

Fig. 12.14 Types of System Testing

Recovery testing
Recovery testing is a type of system testing in which the system is forced to
fail in different ways to check whether the software recovers from the failures
without any data loss. The events that lead to failure include system crashes,
hardware failures, unexpected loss of communication, and other catastrophic
problems.
To recover from any type of failure, a system should be fault-tolerant. A
fault- tolerant system can be defined as a system, which continues to perform the
intended functions even when errors are present in it. In case the system is not
fault-tolerant, it needs to be corrected within a specified time limit after failure has
occurred so that the software performs its functions in a desired manner.
Test cases generated for recovery testing not only show the presence of
errors in a system, but also provide information about the data lost due to problems
such as power failure and improper shutting down of computer system. Recovery
testing also ensures that appropriate methods are used to restore the lost data.
Other advantages of recovery testing are listed below.
 It checks whether the backup data is saved properly.
 It ensures that the backup data is stored in a secure location.
 It ensures that proper detail of recovery procedures is maintained.
Security testing
Systems with sensitive information are generally the target of improper or illegal
use. Therefore, protection mechanisms are required to restrict unauthorized access
to the system. To avoid any improper usage, security testing is performed which

Self-Instructional
Material 269
Testing Techniques identifies and removes the flaws from software (if any) that can be exploited by
the intruders and thus, result in security violations. To find such kind of flaws, the
tester like an intruder tries to penetrate the system by performing tasks such as
cracking the password, attacking the system with custom software, intentionally
NOTES producing errors in the system, etc. The security testing focuses on the following
areas of security.
 Application security: To check whether the user can access only those
data and functions for which the system developer or user of system has
given permission. This security is referred to as authorization.
 System security: To check whether only the users, who have permission
to access the system, are accessing it. This security is referred to as
authentication.
Generally, the disgruntled/dishonest employees or other individuals outside
the organization make an attempt to gain unauthorized access to the system. If
such people succeed in gaining access to the system, there is a possibility that a
large amount of important data can be lost resulting in huge loss to the organization
or individuals.
Security testing verifies that the system accomplishes all the security
requirements and validates the effectiveness of these security measures. Other
advantages associated with security testing are listed below.
 It determines whether proper techniques are used to identify security risks.
 It verifies that appropriate protection techniques are followed to secure the
system.
 It ensures that the system is able to protect its data and maintain its
functionality.
 It conducts tests to ensure that the implemented security measures are
working properly.
Stress testing
Stress testing is designed to determine the behavior of the software under abnormal
situations. In this testing, the test cases are designed to execute the system in such
a way that abnormal conditions arise. Some examples of test cases that may be
designed for stress testing are listed below.
 Test cases that generate interrupts at a much higher rate than the average rate
 Test cases that demand excessive use of memory as well as other resources
 Test cases that cause ‘thrashing’ by causing excessive disk accessing.
IEEE defines stress testing as ‘testing conducted to evaluate a system or
component at or beyond the limits of its specified requirements.’ For example,
if a software system is developed to execute 100 statements at a time, then stress

Self-Instructional
270 Material
testing may generate 110 statements to be executed. This load may increase until Testing Techniques

the software fails. Thus, stress testing specifies the way in which a system reacts
when it is made to operate beyond its performance and capacity limits. Some
other advantages associated with stress testing are listed below.
NOTES
 It indicates the expected behavior of a system when it reaches the extreme
level of its capacity.
 It executes a system till it fails. This enables the testers to determine the
difference between the expected operating conditions and the failure
conditions.
 It determines the part of a system that leads to errors.
 It determines the amount of load that causes a system to fail.
 It evaluates a system at or beyond its specified limits of performance.
Performance testing
Performance testing is designed to determine the performance of the software
(especially real-time and embedded systems) at the run-time in the context of the
entire computer-based system. It takes various performance factors like load,
volume, and response time of the system into consideration and ensures that they
are in accordance with the specifications. It also determines and informs the
software developer about the current performance of the software under various
parameters (like condition to complete the software within a specified time limit).
Often performance tests and stress tests are used together and require both
software and hardware instrumentation of the system. By instrumenting a system,
the tester can reveal conditions that may result in performance degradation or
even failure of a system. While the performance tests are designed to assess the
throughput, memory usage, response time, execution time, and device utilization
of a system, the stress tests are designed to assess its robustness and error handling
capabilities. Performance testing is used to test several factors that play an important
role in improving the overall performance of the system. Some of these factors are
listed below.
 Speed: Refers to the extent how quickly a system is able to respond to its
users. Performance testing verifies whether the response is quick enough.
 Scalability: Refers to the extent to which the system is able to handle the
load given to it. Performance testing verifies whether the system is able to
handle the load expected by users.
 Stability: Refers to the extent how long the system is able to prevent itself
from failure. Performance testing verifies whether the system remains stable
under expected and unexpected loads.
The outputs produced during performance testing are provided to the system
developer. Based on these outputs, the developer makes changes to the system in

Self-Instructional
Material 271
Testing Techniques order to remove the errors. This testing also checks the system characteristics
such as its reliability. Other advantages associated with performance testing are
listed below.
 It assess whether a component or system complies with specified
NOTES
performance requirements.
 It compares different systems to determine which system performs better.

Check Your Progress

1. Give the definition of software testing according to IEEE.
2. Define the term test plan.
3. What is unit testing?
4. Write the advantage of beta testing.

12.4 AUTOMATED TESTING

Program analysis tools, also known as software testing tools, are frequently used
to ensure consistency, thoroughness, and efficiency in testing software products
and to fulfil the requirements of planned testing activities. These tools may facilitate
unit (module) testing and subsequent integration testing (e.g., drivers and stubs) as
well as commercial software testing tools. Testing tools can be classified into one
of the following two categories:
Static Test Tools
Do not involve actual input and output; rather they take a symbolic approach to
testing, that is, static test tools do not test the actual execution of the software.
These tools include the following:
 Flow analysers: Ensure consistency in data flow from input to output.
 Path tests: Find unused code and code with contradictions.
 Coverage analysers: Ensure that all logic paths are tested.
 Interface analysers: Examine effects of passing variables and data
between modules
Dynamic Test Tools
Test the software system with ‘live’ data. Dynamic test tools include the following:
 Test driver: Inputs data into a module under test.
 Test beds: Simultaneously display source code along with the program
under execution.
 Emulators: Response facilities are used to emulate parts of the system
not yet developed.

Self-Instructional
272 Material
  Mutation analysers: Errors are deliberately ‘fed’ into the code in order Testing Techniques

to test fault tolerance of the system.

Testing tools can also be classified into manual testing and automated testing.
Manual testing is used to document tests, produce test guides based on data queries,
NOTES
provide temporary structures to help run tests, and measure the results of the test.
Manual testing is considered to be costly and time-consuming; therefore, automated
testing is used to cut down time and cost.
Automated Testing
In simple terms, automated testing is automating the manual testing process. It is
used to replace or supplement manual testing with a suite of testing tools. Automated
testing tools assist software testers to evaluate the quality of the software by
automating the mechanical aspects of the software testing task. Automated testing
tools vary in their underlying approach, quality and ease of use. The benefits of
automation include increased software quality, improved time to market, repeatable
test procedures and reduced testing costs.
However, if automation is not planned carefully, it may lead to poor quality of
testing. Therefore, while performing testing with automated tools, the following
points should be noted.
 Clear and reasonable expectations should be established in order to know
what can and what cannot be accomplished with automated testing in the
organization.
 There should be a clear understanding of the requirements that should be
met in order to achieve successful automated testing. This requires the
following:
o Technical personnel to use the tools effectively
o An effective manual testing process, which must exist before automation
begins
 The organization should have detailed, reusable test cases which contain
exact expected results and a standalone test environment with a restorable
database.
 Testing tool should be cost-effective. It should involve minimum technical
personnel and should ensure that test cases developed for manual testing
are also useful for automated testing.
 Select a tool that allows implementation of automated testing in a way that
conforms to the specified long-term testing strategy.
Many automated tools are available for performing the testing process in an
effective and efficient manner. Automated tools like Mothora are used to create
and execute test cases, measure test case adequacy, determine input-output
correctness, locate and remove faults or bugs, and control and document the test.
Similarly, Bug Trapper is used to perform white box testing. This tool traces the
Self-Instructional
Material 273
Testing Techniques path of execution and captures the bug along with the path of execution and the
different input values that resulted in the error. The other commonly used automated
tools are listed in Table 12.8.
Table 12.8 Software Testing Tools
NOTES
Manufacturer Testing Tools
Segue  SilkTest
 SilkPerformer
 SilkCentral
IBM/Rational  RequirementPro
 Robot
 ClearCase
Mercury Interactive  WinRunner
 LoadRunner
 TestDirector
Compuware  Reconcile
 QALoad
 QARun

Note: The challenges in successful automation lie in the selection of an appropriate test tool,
efficient and error-free scripting, proper time synchronization of testing, and automation of
activities.

12.5 MANUAL TESTING

Manual testing is the process of manually testing software for defects. It

requires a tester to play the role of an end user whereby they use most of the
application’s features to ensure correct behaviour. To guarantee completeness of
testing, the tester often follows a written test plan that leads them through a set of
important test cases.
Manual testing is a software testing process in which test cases are executed
manually without using any automated tool. All test cases executed by the tester
manually according to the end user’s perspective. It ensures whether the application
is working, as mentioned in the requirement document or not. Test cases are
planned and implemented to complete almost 100 percent of the software
application. Test case reports are also generated manually.
Additionally, the manual testing is one of the most fundamental testing
processes as it can find both visible and hidden defects of the software. The
difference between expected output and output, given by the software, is defined
as a defect. The developer fixed the defects and handed it to the tester for retesting.
Manual testing is essential because one of the software testing fundamentals is
“100% Automation is Not Possible”.

Self-Instructional
274 Material
 Manual testing is mandatory for every newly developed software before Testing Techniques

automated testing. This testing requires great efforts and time, but it gives the
surety of bug-free software. Manual testing requires knowledge of manual testing
techniques but not of any automated testing tool.
NOTES
A key step in the process is testing the software for correct behaviour prior
to release to end users.
For small scale engineering efforts (including prototypes), exploratory testing
may be sufficient. With this informal approach, the tester does not follow any
rigorous testing procedure, but rather explores the user interface of the application
using as many of its features as possible, using information gained in prior tests to
intuitively derive additional tests. The success of exploratory manual testing relies
heavily on the domain expertise of the tester, because a lack of knowledge will
lead to incompleteness in testing. One of the key advantages of an informal approach
is to gain an intuitive insight to how it feels to use the application.
Large scale engineering projects that rely on manual software testing
follow a more rigorous methodology in order to maximize the number of defects
that can be found. A systematic approach focuses on predetermined test cases
and generally involves the following steps:
 Choose a high level test plan where a general methodology is chosen,
and resources, such as people, computers, and software licenses are
identified and acquired.
 Write detailed test cases, identifying clear and concise steps to be taken
by the tester, with expected outcomes.
 Assign the test cases to testers, who manually follow the steps and record
the results.
 Author a test report, detailing the findings of the testers. The report is
used by managers to determine whether the software can be released,
and if not, it is used by engineers to identify and correct the problems.
A rigorous test case based approach is often traditional for large software
engineering projects that follow a Waterfall model.
Testing can be through Black-Box Testing, White- Box Testing or Grey-
Box Testing. In white-box testing the tester is concerned with the execution of the
statements through the source code. In black-box testing the software is run to
check for the defects and is less concerned with how the processing of the input is
done. Black-box testers do not have access to the source code. Grey-box testing
is concerned with running the software while having an understanding of the source
code and algorithms.
Static and dynamic testing approach may also be used. Dynamic testing
involves running the software. Static testing includes verifying requirements, syntax
of code and any other activities that do not include actually running the code of the
program.
Self-Instructional
Material 275
Testing Techniques Testing can be further divided into functional and non-functional testing. In
functional testing the tester would check the calculations, any link on the page, or
any other field which on given input the output may be expected. Non-functional
testing includes testing performance, compatibility and fitness of the system under
NOTES test, its security and usability among other things.
Stages of Manual Testing
Following are the stages of manual testing:
 Unit Testing: This initial stage in testing normally carried out by the developer
who wrote the code and sometimes by a peer using the white-box testing
technique.
 Integration Testing: This stage is carried out in two modes, as a complete
package or as an increment to the earlier package. Most of the time black-
box testing technique is used. However, sometimes a combination of black-
box testing and white-box testing is also used in this stage.
 System Testing: In this stage the software is tested from all possible
dimensions for all intended purposes and platforms. In this stage black-box
testing technique is normally used.
 User Acceptance Testing: This testing stage is carried out in order to get
customer sign-off of finished product. A ‘Pass’ in this stage also ensures
that the customer has accepted the software and is ready for their use.
 Release or Deployment Testing: Onsite team will go to customer site to
install the system in customer configured environment and will check for the
following points:
o Whether SetUp.exe is running or not.
o There are easy screens during installation.
o How much space is occupied by system on HDD (Hard Disk Drive).
o Is the system completely uninstalled when opted to uninstall from the
system.
Advantages of Manual Testing
Following are the advantages of manual testing:
 Low-cost operation as no software tools are used.
 Most of the bugs are caught by manual testing.
 Humans observe and judge better than the automated tools.
How Manual Testing is Performed?
Following are the essential steps for efficiently performing the manual testing:
Step 1: First, tester observes all documents related to software, to select testing
areas.
Self-Instructional
276 Material
Step 2: Tester analyses requirement documents to cover all requirements stated Testing Techniques

by the customer.
Step 3: Tester develops the test cases according to the requirement document.
Step 4: All test cases are executed manually by using black-box testing and white- NOTES
box testing.
Step 5: If bugs occurred then the testing team informs the development team.
Step 6: The development team fixes bugs and handed software to the testing team
for a retest.

12.6 TESTING TECHNIQUES

Once the software is developed it should be tested in a proper manner before the
system is delivered to the user. For this, two techniques that provide systematic
guidance for designing tests are used (refer Figure 12.15). These techniques are
as follows:
 Once the internal working of a software is known, tests are performed to
ensure that all internal operations of a software are performed according to
specifications. This is referred to as white box testing.
 Once the specified function for which a software has been designed is known,
tests are performed to ensure that each function is working properly. This is
referred to as black box testing.

Fig. 12.15 Testing Approaches

12.6.1 White Box Testing

White box testing, also known as structural testing is performed to check the
internal structure of a program. To perform white box testing, the tester should
have a thorough knowledge of the program code and the purpose for which it is
developed. The basic strength of this testing is that the entire software implementation
is included while testing is performed. This facilitates error detection even when
the software specification is vague or incomplete.

Self-Instructional
Material 277
Testing Techniques The objective of white box testing is to ensure that the test cases (developed by
software testers by using white box testing) exercise each path through a program,
that is, the test cases ensure that all internal structures in the program are developed
according to design specifications (refer Figure 12.16). The test cases also ensure
NOTES that:
 All independent paths within the program have been executed at least once.
 All internal data structures are exercised to ensure validity.
 All loops (simple loops, concatenated loops, and nested loops) are executed
at their boundaries and within operational bounds.
 All the segments present between the control structures (like ‘switch’
statement) are executed at least once.
 Each branch (like ‘case’ statement) is exercised at least once.
 All the branches of the conditions and the combinations of these conditions
are executed at least once. Note that for testing all the possible combinations,
a ‘truth table’ is used where all logical decisions are exercised for both true
and false paths.

Fig. 12.16 White Box Testing

The effectiveness of white box testing is commonly expressed in terms of test or

code coverage metrics which measure the fraction of code exercised by test cases.
The various types of testing, which occur as part of white box testing are basis
path testing, control structure testing and mutation testing (refer Figure 12.17).

Self-Instructional
278 Material
 Testing Techniques

NOTES

Fig. 12.17 Types of White Box Testing

Basis path testing

Basis path testing enables the software tester to generate test cases such that
every path of the program has been exercised at least once. This technique is used
to specify the basic set of execution paths that are required to execute all the
statements present in the program. Note that with the increase in the size of the
software the number of execution paths also increases, thereby degrading the
effectiveness of basis path testing.
Creating a flow graph
A flow graph is used to show the logical control flow within a program. To represent
the control flow, a flow graph uses a notation, which is shown in Figure 12.18.

Fig. 12.18 Flow Graph Notation

A flow graph uses different symbols, namely circles and arrows to represent various
statements and flow of control within the program. Circles represent nodes, which
are used to depict the procedural statements present in the program. A series of
process boxes and a decision diamond in a flowchart can be easily mapped into a
single node. Arrows represent edges or links which are used to depict the flow of
control within the program. It is necessary for every edge to end in a node
Self-Instructional
Material 279
Testing Techniques irrespective of whether it represents a procedural statement or not. In a flow
graph, the area bounded by edges and nodes is known as a region. While counting
regions, the area outside the graph is also considered as a region. A flow graph
can be easily understood with the help of a diagram. Figure 12.19(a) represents a
NOTES flow chart which has been represented as a flow graph in 12.19(b).

(a) Flow Chart (b) Flow Graph

Fig. 12.19 Creating a Flow Graph from a Flow Chart

Note that a node that contains a condition is known as predicated node which
contains one or more edges emerging out of it. In Figure 12.19(b), node 2 and
node 3 represent the predicated nodes.
Finding independent paths
A path through the program which specifies a new condition or a minimum of one
new set of processing statements is known as an independent path. In nested ‘if’
statements, for example, there are several conditions that represent independent
paths. Note that a set of all independent paths present in the program is known as
a basis set.
A test case is developed to ensure that all the statements present in the program
are executed at least once during testing. All the independent paths in Figure
12.19(b) are as follows:
P1: 1-9
P2: 1-2-7-8-1-9
P3: 1-2-3-4-6-8-1-9
P4: 1-2-3-5-6-8-1-9
Self-Instructional
280 Material
 Where ‘P1’, ‘P2’, ‘P3’ and ‘P4’ represent different independent paths Testing Techniques

present in the program.

The number of independent paths present in the program is calculated using
cyclomatic complexity, which is defined as the software metric that provides a
NOTES
quantitative measure of the logical complexity of a program. This software metric
also provides information about the number of tests required to ensure that all
statements in the program are executed at least once.
Cyclomatic complexity can be calculated by using any of the following three
methods.
1. The total number of regions present in the flow graph of a program represents
the cyclomatic complexity of the program. In Figure 12.19(b), for example,
there are four regions represented by ‘R1’, ‘R2’, ‘R3’, and ‘R4’; hence,
the cyclomatic complexity is four.
2. Cyclomatic complexity can be calculated according to the formula given
below:
CC = E – N + 2
Where, ‘CC’ represents the cyclomatic complexity of the program, ‘E’
represents the number of edges in the flow graph, and ‘N’ represents the
number of nodes in the flow graph. In Figure 12.19(b), for example,
‘E’ = ‘11’, ‘N’ = ‘9’. Therefore, CC = 11 – 9 + 2 = 4.
3. Cyclomatic complexity can be also calculated according to the formula given
below:
CC = P + 1
Where ‘P’ is the number of predicate nodes in the flow graph. For example,
in Figure 7.20(b), P = 3. Therefore, CC = 3 + 1 = 4.
Note: Cyclomatic complexity can be calculated manually for small program suites, but
automated tools are preferred for most operational environments.
Deriving test cases
In this, basis path testing is presented as a series of steps and test cases are
developed to ensure that all statements present in the program are executed during
testing. While performing basis path testing, initially the basis set (independent
paths in the program) is derived. The basis set can be derived using the steps
listed here:
1. Draw the flow graph of the program: A flow graph is constructed using
symbols previously discussed. For example, a program to find the greater
of two numbers is given below:
procedure greater;
integer: a, b, c = 0;
1 enter the value of a;
2 enter the value of b;
Self-Instructional
Material 281
Testing Techniques 3 if a > b then
4 c = a;
else
5 c = b;
NOTES
6 end greater
The flow graph for the above program is shown in Figure 12.20.

Fig. 12.20 Flow Graph to find the Greater between Two Numbers

2. Determine the cyclomatic complexity of the program using the flow

graph: The cyclomatic complexity for flow graph depicted in Figure 12.20
can be calculated as follows:
CC = 2 regions
Or
CC = 6 edges – 6 nodes + 2 = 2
Or
CC = 1 predicate node + 1 = 2
3. Determine all the independent paths present in the program using
the flow graph: For the flow graph shown in Figure 12.20, the independent
paths are listed below:
P1 = 1-2-3-4-6
P2 = 1-2-3-5-6
4. Prepare test cases: Test cases are prepared to implement the execution
of all the independent paths in the basis set. Each test case is executed and
compared with the desired results.

Self-Instructional
282 Material
Generating graph matrix Testing Techniques

Graph matrix is used to develop a software tool that in turn helps in carrying out
basis path testing. Graph matrix can be defined as a data structure which represents
the flow graph of a program in a tabular form. This matrix is also used to evaluate
NOTES
the control structures present in the program during testing.
Graph matrix consists of rows and columns that represent nodes present in
the flow graph. Note that the size of graph matrix is equal to the number of nodes
present in the flow graph. Every entry in the graph matrix is assigned some value
known as link weight. Adding link weights to each entry makes the graph matrix
a useful tool for evaluating the control structure of the program during testing.
The flow graph shown in Figure 12.21(a) is depicted as a graph matrix in
Figure 12.21(b). In Figure 12.21(a), numbers are used to identify each node in a
flow graph, while letters are used to identify edges in a flow graph. In Figure 12.21
(b), a letter entry is made when there is a connection between two nodes in the
flow graph. Node 3, for example, is connected to node 6 by edge ‘d’ and node
4 is connected to node 2 by edge ‘c’, and so on.

(a) Flow Graph (b) Graph Matrix

Fig. 12.21 Generating Graph Matrix

Control structure testing

Control structure testing is used to enhance the coverage area by testing various
control structures (which include logical structures and loops) present in the program.
Note that basis path testing is used as one of the techniques for control structure
testing. The various types of testing performed under control structure testing are
condition testing, data flow testing, and loop testing.
Condition testing
In condition testing, the test cases are derived to determine whether the logical
conditions and decision statements are free from errors. The errors present in
Self-Instructional
Material 283
Testing Techniques logical conditions can be incorrect Boolean operators, missing parenthesis in a
Boolean expression, error in relational operators, arithmetic expressions, and so
on.
The common types of logical conditions that are tested using condition testing are
NOTES
as follows:
 A relational expression, such as ‘E1 op E2’, where ‘E1’ and ‘E2’ are
arithmetic expressions and ‘op’ is an operator.
 A simple condition, such as any relational expression proceeded by a ‘NOT’
(~) operator. For example, (~ E1), where ‘E1’ is an arithmetic expression
and ‘~’ represents ‘NOT’ operator.
 A compound condition, which is composed of two or more simple
conditions, Boolean operators, and parenthesis. For example, (E1 & E2) |
(E2 & E3), where ‘E1’, ‘E2’, and ‘E3’ are arithmetic expressions and ‘&’
and ‘|’ represent ‘AND’ and ‘OR’ operators.
 A Boolean expression consisting of operands and a Boolean operator, such
as ‘AND’, ‘OR’, ‘NOT’. For example, ‘A | B’ is a Boolean expression,
where ‘A’ and ‘B’ are operands and ‘|’ represents ‘OR’ operator.
Condition testing is performed using different strategies, namely branch testing,
domain testing, and branch and relational operator testing. Branch testing executes
each branch (like ‘if’ statement) present in the module of a program at least once
to detect all the errors present in the branch. Domain testing tests relational
expressions present in a program. For this, domain testing executes all statements
of the program that contain relational expressions. Branch and relational operator
testing tests the branches present in the module of a program using condition
constraints. For example,
if a >10
then
print big
In this case, branch and relational operator testing verifies that the output produced
by the execution of the above code is ‘big’ only if the value of variable ‘a’ is
greater than ‘10’.
Data flow testing
In data flow testing, test cases are derived to determine the validity of variables’
definitions and their uses. This testing ensures that all variables are used properly
in a program. To specify test cases, data flow-based testing uses information,
such as location at which the variables are defined and used in the program.
To perform data flow-based testing, a definition-use graph is constructed
by associating variables with nodes and edges in the control flow graph. Once
these variables are attached with nodes and edges of control flow graph, test
cases can easily determine which variable is used in which part of a program and
Self-Instructional
284 Material
how data is flowing in the program. Thus, data flow of a program can be tested Testing Techniques

easily using specified test cases.

Loop testing
In loop testing, test cases are derived to determine the validity of loops present in NOTES
the program modules. Generally, there exist four types of loops (refer Figure 12.22),
which are:
 Simple loop: It refers to a loop that has no other loops in it. Consider a
simple loop of size ‘n’. Size ‘n’ of the loop indicates that the loop can be
traversed ‘n’ times, that is, ‘n’ passes are made through the loop. To test
simple loops, a number of steps are followed, namely:
1. Skip the entire loop.
2. Traverse the loop only once.
3. Traverse the loop two times.
4. Make ‘a’ passes through the loop, where ‘a’ is a number less than the
size of loop ‘n’.
5. Traverse the loop n-1, n, n+ 1 times.

Fig. 12.22 Types of Loops

 Nested loops: Loops within loops are known as nested loops. While testing
nested loops, the number of tests increases as the level of nesting increases.
The steps followed for testing nested loops are:
1. Start with the inner loop and set values of all the outer loops to minimum.
Self-Instructional
Material 285
Testing Techniques 2. Test the inner loop using the steps followed for testing simple loops
while holding the outer loops at their minimum parameter values. Add
other tests for values that are either out-of-range or are eliminated.
3. Move outwards, conducting tests for the next loop. However, keep the
NOTES
nested loops to ‘typical’ values and outer loops at their minimum values.
4. Continue testing until all loops are tested.
 Concatenated loops: It refers to the loops which contain several loops
that may or may not depend on each other. If the loops are independent of
each other, then steps in simple loops are followed. If the loops are
dependent on each other, then steps in nested loops are followed.
 Unstructured loops: This type of loop should be redesigned so that the
use of structured programming constructs can be reflected.
Mutation testing
Mutation testing is a white box method where errors are ‘purposely’ inserted into
a program (under test) to verify whether the existing test case is able to detect the
error or not. In this testing, mutants of the program are created by making some
changes in the original program. The objective is to check whether each mutant
produces an output that is different from the output produced by the original program
(refer Figure 12.23).

Fig. 12.23 Mutation Testing

Self-Instructional
286 Material
 In mutation testing, test cases that are able to ‘kill’ all the mutants should be Testing Techniques

developed. This is accomplished by testing mutants with the developed set of test
cases. There can be two possible outcomes when the test cases test the program
– either the test case detects the faults or fails to detect the faults. If faults are
detected, then necessary measures are taken to correct them. NOTES
When no faults are detected, it implies that either the program is absolutely
correct or the test case is inefficient to detect the faults. Therefore, it can be said
that mutation testing is performed to check the effectiveness of a test case, that is,
if a test case is able to detect these ‘small’ faults (minor changes) in a program,
then it is likely that the same test case will be equally effective in finding real faults.
To perform mutation testing, the following steps are used.
1. Create mutants of a program.
2. Check both program and its mutants using test cases.
3. Find the mutants that are different from the main program. A mutant is said
to be different from the main program if it produces an output which is
different from the output produced by the main program.
4. Find mutants that are equivalent to the program, that is, the mutants that
produce same outputs as produced by the program.
5. Calculate the mutation score using the formula given below:
M = D/(N – E)
Where M = Mutation score
N = Total number of mutants of the program
D = Number of mutants different from the main program
E = Total number of mutants that are equivalent to the main
program
6. Repeat steps 1 to 5 till the mutation score is ‘1’.
However, mutation testing is very expensive to run on large programs. Thus, certain
tools are used to run mutation tests on large programs. ‘Jester’, for example, is
used to run mutation tests on java code. This tool targets the specific areas of the
program code, such as changing constants and Boolean values.
12.6.2 Black Box Testing
Black box testing (or functional testing) checks the functional requirements and
examines the input and output data of these requirements (refer Figure 12.24).
The functionality is determined by observing the outputs to corresponding inputs.
For example, when black box testing is used, the tester should only know the
‘legal’ inputs and what the expected outputs should be, but not how the program
actually arrives at those outputs.

Self-Instructional
Material 287
Testing Techniques

NOTES

Fig. 12.24 Black Box Testing

The black box testing is used to find the following errors (refer Figure 12.25):
 Interface errors, such as functions, which are unable to send or receive
data to/from other software.
 Incorrect functions that lead to undesired output when executed.
 Missing functions and erroneous data structures.
 Erroneous databases which lead to incorrect outputs when the software
uses the data present in these databases for processing.
 Incorrect conditions due to which the functions produce incorrect outputs
when they are executed.
 Termination errors, such as certain conditions due to which a function enters
a loop that forces it to execute indefinitely.

Fig. 12.25 Types of Error Detection in Black Box Testing

In this testing, various inputs are exercised and the outputs are compared
against specifications to validate the correctness. Note that test cases are derived
from these specifications without considering implementation details of the code.

Self-Instructional
288 Material
The outputs are compared with user requirements and if they are as specified by Testing Techniques

the user, then the software is considered to be correct, else the software is tested
for the presence of errors in it.
The various methods used in black box testing are equivalence class
NOTES
partitioning, boundary value analysis and cause-effect graphing (refer Figure 12.26).
In equivalence class partitioning, the test inputs are classified into equivalence
classes such that one input checks (validates) all the input values in that class. In
boundary value analysis, the boundary values of the equivalence classes are
considered and tested. In cause-effect graphing, cause-effect graphs are used
to design test cases which provides all the possible combinations of inputs to the
program.

Fig. 12.26 Types of Black Box Testing

Equivalence class partitioning

This method tests the validity of outputs by dividing the input domain into different
classes of data (known as equivalence classes) using which test cases can be
easily generated (refer Figure 12.27). Test cases are designed with the purpose of
covering each partition at least once. If a test case is able to detect all the errors in
the specified partition, then the test case is said to be an ideal test case.

Fig. 12.27 Input Domain and Equivalence Classes

Self-Instructional
Material 289
Testing Techniques An equivalence class depicts valid or invalid states for the input condition. An
input condition can be either a specific numeric value, a range of values, a Boolean
condition, or a set of values. The general guidelines that are followed for generating
the equivalence classes are listed in Table 12.9.
NOTES
Table 12.9 Guidelines for generating Equivalence Classes
Input Condition Number of Equivalence Description
Classes
Boolean Two One valid and one invalid
Specific numeric Three One valid and two invalid
value
Range Three One valid and two invalid
Member of a set Two One valid and one invalid

To understand equivalence class partitioning properly, let us consider an example.

This example is explained in the series of steps listed below.
1. Suppose that a program ‘P’ takes an integer ‘X’ as input.
2. Now for this input we have ‘X’ < 0 and ‘X’ > 0.
3. If ‘X’ < 0, then the program is required to perform task T1 and if X > 0 then
task T2 is performed.
4. The input domain is as large as ‘X’ and it can assume a large number of
values. Therefore, the input domain (P) is partitioned into two equivalence
classes and all test inputs in the X < 0 and X > 0 equivalence classes are
considered to be equivalent.
5. Now, as shown in Figure 12.28 independent test cases are developed for
X < 0 and X > 0.

Fig. 12.28 Test Case and Equivalence Class

Boundary value analysis

In Boundary Value Analysis (BVA), test cases are derived on the basis of values
that lie on the edge of the equivalence partitions. These values can be input or
Self-Instructional
290 Material
output values either at the edge or within the permissible range from the edge of an Testing Techniques

equivalence partition.
BVA is used since it has been observed that a large number of errors occur
at the boundary of the given input domain rather than at the middle of the input
NOTES
domain. Note that boundary value analysis complements the equivalence
partitioning method. The only difference is that in BVA, test cases are derived for
both input domain and output domain while in equivalence partitioning, test cases
are derived only for input domain.
Generally, the test cases are developed in boundary value analysis using the following
guidelines:
 If an input consists of a range of certain values, then test cases should be
able to exercise both the values at the boundaries of the range and the
values that are just above and below boundary values. For the range –0.5
< X < 0.5, for example, the input values for a test case can be ‘–0.4’, ‘–
0.5’, ‘0.5’, ‘0.6’.
 If an input condition specifies a number of values, then test cases are
generated to exercise the minimum and maximum numbers and values just
above and below these limits.
 If an input consists of a list of numbers, then the test case should be able to
exercise the first and the last elements of the list.
 If an input consists of certain data structures (like arrays), then the test case
should be able to execute all the values present at the boundaries of the
data structures, such as the maximum and minimum value of an array.
Cause-effect graphing
Equivalence partitioning and boundary value analysis tests each input given to a
program independently. It means none of these consider the case of combinations
of inputs which may produce situations that need to be tested. This drawback is
avoided in cause-effect graphing where combinations of inputs are used instead of
individual inputs. In this technique, the causes (input conditions) and effects (output
conditions) of the system are identified and a graph is created with each condition
as the node of the graph. This graph is called cause-effect graph. This graph is
then used to derive test cases. To use the cause-effect graphing method, the
following steps are used.
1. Listing the causes (input conditions) and effects (outputs) of the program.
2. Creating a cause-effect graph.
3. Converting the graph into a decision table.
4. Modifying the decision table rules to test cases.
For generating test cases, initially all causes and effects are allocated unique
numbers which are used to identify them. After allocating numbers, the cause due
to which a particular effect occurred is determined. Next, the combinations of
Self-Instructional
Material 291
Testing Techniques various conditions that make the effect ‘true’ are recognized. A condition has two
states — ‘true’ and ‘false’. A condition is ‘true’ if it causes the effect to occur;
otherwise it is ‘false’. The conditions are combined using Boolean operators, such
as ‘AND’ (&), ‘OR’ (|) and ‘NOT’ (~). Finally, a test case is generated for all
NOTES possible combinations of conditions.
The various symbols used in the cause-effect graph are shown in Figure
12.29. The left side in the figure depicts the various logical associations among
causes ci and effects ei and the dashed notation on the right side indicates the
various constraint associations that can be applied to either causes or effects.

Fig. 12.29 Logical and Constraints Associations

Differences between Black Box and White Box Testing

Although white box testing and black box testing are used together for testing
many programs, there are several considerations that make them different from
each other. Black box testing detects errors of omission, which are errors occurring
due to non-accomplishment of user requirements. On the other hand, white box
testing detects errors of commission, which are errors occurring due to non-
implementation of some part of software code. The other differences between
white box testing and black box testing are listed in Table 12.10.

Self-Instructional
292 Material
 Table 12.10 Differences between White Box and Black Box Testing Testing Techniques

Basis White Box Testing Black Box Testing

Purpose  It is used to test the internal  It is used to test the functionality
structure of software. of software.
 It is concerned only with testing  It is concerned only with the NOTES
the software and does not testing specifications and does not
guarantee the complete guarantee that all the components
implementation of all the of software that are implemented
specifications mentioned in the are tested.
user requirements.  It addresses the validity,
 It addresses the flow and control behaviour and performance of
structure of a program. software.
Stage  It is performed in the early stages  It is performed in the later stages
of testing. of testing.
Requirement  Knowledge of the internal structure  No knowledge of the internal
of a program is required for structure of a program is required
generating test case. to generate test case.
Test Cases  Test cases are generated based on  The internal structure of modules
the actual code of the module to be or programs is not considered for
tested. selecting test cases.
Example  The inner software present inside  In this testing, it is checked
the calculator (which is known by whether the calculator is working
the developer only) is checked by properly or not by giving inputs
giving inputs to the code. by pressing the buttons in the
calculator.

12.6.3 Gray Box Testing

Gray box testing technique is often defined as a mixture of black box testing and
white box testing techniques. This technique is similar to white box testing in the
aspect that it requires limited knowledge of the internal details of the system under
test, in order to design the test cases. However, like the black box testing, the
system is treated as a ‘black box’ and is tested from the outside. In gray box
testing, test design is developed using the information such as state-based models
or the architecture diagrams of the system to be tested. In addition, the inputs are
applied to the system and the outputs are observed using the black box approach.
Gray box testing must not be confused with white box testing as in this
technique, the complete knowledge of the internal structure of the program is not
required;, rather partial knowledge of how the components of the program operate
and interact is sufficient. This testing technique is especially used in Web services
applications as these applications are built around loosely integrated components
that connect through relatively well-defined interfaces, even though the applications
are complex.
The main objective of gray box testing is to find those defects that occur
due to poor design or poor implementation of the system. This technique is designed
to derive test cases that are used to analyse the functioning of back-end components
throughout the execution of test cases. Now, two types of defects may occur
during the test case execution. First, one of the components meets a failure and
causes the operation being performed to be aborted. Second, the test case executes

Self-Instructional
Material 293
Testing Techniques successfully, but the result produced is incorrect because of the wrong processing
of data by some specific component.
The various advantages of gray box testing are listed as follows:
NOTES  It combines the advantages of both white box and black box testing. A
partial knowledge of technical workings of the product helps the tester to
derive more effective test cases. For example, consider a Web application
that requires a user name and password to enter into the website and matches
the name and password entered with what is in the database. Obviously,
this requirement leads the tester to generate a number of test cases. However,
if the tester comes to know that only first five characters of the name are
checked while determining the match, then the tester can design a different
set of test cases in accordance with that information.
 It does not require the tester to have access to the source code, thus
maintaining a separation line between the developer and tester. This also
helps in preventing any chance occurrence of conflict between the two.
 It allows a gray box tester to generate well-informed test scenarios
(specifically related to data type handling, exception handling, and
communication protocols) based on the limited knowledge about the internal
structure of the system under test.
Besides these advantages, gray box testing has some disadvantages too, which
are listed as follows:
 Since internal details are not fully known to the tester and the test cases are
designed using the limited information available, the code coverage is
constrained by the tester’s authoring skills.
 In case of distributed Web services applications, it is more difficult to identify
the potential defects. This depends only on how well the systems throw
exception and how well these exceptions propagate in a distributed
environment.
Some important points that must be noted in gray box testing are the following:
 Gray box testing is platform and language independent.
 The current implementation of gray box testing is heavily dependent on the
use of a host platform debugger(s) to execute and validate the software
under test.
 It can be applied in real-time systems.
 It utilizes automated software testing tools to facilitate the generation of test
cases.
 Module drivers and stubs are created by automation means, thus saving
time of testers.

Self-Instructional
294 Material
 Testing Techniques

Check Your Progress

5. Define the term software testing tools.
6. What is manual testing? NOTES
7. Explain the term white box testing.
8. What is mutation testing?
9. Elaborate on the term boundary value analysis.
10. Explain the term gray box testing.

12.7 ANSWERS TO CHECK YOUR PROGRESS

QUESTIONS

1. IEEE defines testing as ‘The process of exercising or evaluating a system

or system component by manual or automated means to verify that it
satisfies specified requirements or to identify differences between
expected and actual results.’
2. A test plan describes how testing would be accomplished. Test plan is a
document which is developed to specify the objectives, scope, method and
purpose of software testing. This plan identifies test items, features to be
tested, testing tasks and the persons involved in performing these tasks. It
also identifies the test environment and the test design and measurement
techniques that are to be used. Note that a properly defined test plan is an
agreement between testers and users describing the role of testing in software.
3. Unit testing is performed to test the individual units of software. Since the
software comprises various units/modules, detecting errors in these units is
simple and consumes less time, as they are small in size. However, it is
possible that the outputs produced by one unit become input for another
unit. Hence, if incorrect output produced by one unit is provided as input to
the second unit then it also produces wrong output. If this process is not
corrected, the entire software may produce unexpected outputs.
4. The advantages of beta testing are listed below.
 It evaluates the entire documentation of software. For example, it
examines the detailed description of software code, which forms a part
of documentation of software.
 It checks whether software is operating successfully in user environment
or not.
5. Program analysis tools, also known as software testing tools, are frequently
used to ensure consistency, thoroughness, and efficiency in testing software

Self-Instructional
Material 295
Testing Techniques products and to fulfil the requirements of planned testing activities. These
tools may facilitate unit (module) testing and subsequent integration testing
(e.g., drivers and stubs) as well as commercial software testing tools.
6. Manual testing is a software testing process in which test cases are executed
NOTES
manually without using any automated tool. All test cases executed by the
tester manually according to the end user’s perspective. It ensures whether
the application is working, as mentioned in the requirement document or
not. Test cases are planned and implemented to complete almost 100 percent
of the software application. Test case reports are also generated manually.
7. White box testing, also known as structural testing is performed to check
the internal structure of a program. To perform white box testing, the tester
should have a thorough knowledge of the program code and the purpose
for which it is developed. The basic strength of this testing is that the entire
software implementation is included while testing is performed. This facilitates
error detection even when the software specification is vague or incomplete.
8. Mutation testing is a white box method where errors are ‘purposely’ inserted
into a program (under test) to verify whether the existing test case is able to
detect the error or not. In this testing, mutants of the program are created
by making some changes in the original program. The objective is to check
whether each mutant produces an output that is different from the output
produced by the original program.
9. In Boundary Value Analysis (BVA), test cases are derived on the basis of
values that lie on the edge of the equivalence partitions. These values can
be input or output values either at the edge or within the permissible range
from the edge of an equivalence partition.
10. Gray box testing technique is often defined as a mixture of black box testing
and white box testing techniques. This technique is similar to white box
testing in the aspect that it requires limited knowledge of the internal details
of the system under test, in order to design the test cases.

12.8 SUMMARY

 Software testing is a process which is used to identify the correctness,

completeness and quality of a software.
 The process of exercising or evaluating a system or system component by
manual or automated means to verify that it satisfies specified requirements
or to identify differences between expected and actual results.
 Testing is an organizational issue which is performed either by the software
developers (who originally developed the software) or by an Independent
Test Group (ITG), which comprises of software testers. The software
developers are considered to be the best persons to perform testing as they
Self-Instructional have the best knowledge about the software.
296 Material
 A test plan describes how testing would be accomplished. Test plan is a Testing Techniques

document which is developed to specify the objectives, scope, method and

purpose of software testing. This plan identifies test items, features to be
tested, testing tasks and the persons involved in performing these tasks.
NOTES
 The ease with which a program is tested is known as testability. Testability
should always be considered while designing and implementing a software
system so that the errors (if any) in the system can be detected with minimum
effort.
 Set of input values, execution preconditions, expected results and execution
post conditions, developed for a particular objective or test condition such
as to exercise a particular program path or to verify compliance with a
specific requirement.
 A testing strategy is used to identify the levels of testing which are to be
applied along with the methods, techniques, and tools to be used during
testing.
 Software testing is often used in association with the terms ‘Verification’
and ‘Validation’.
 Unit testing is performed to test the individual units of software. Since the
software comprises various units/modules, detecting errors in these units is
simple and consumes less time, as they are small in size.
 Unit testing is performed by conducting a number of unit tests where each
unit test checks an individual component that is either new or modified. A
unit test is also referred to as a module test as it examines the individual units
of code that constitute the program and eventually the software.
 Unit tests can be designed before coding begins or after the code is
developed. Review of this design information guides the creation of test
cases, which are used to detect errors in various units.
 In integration testing, the units validated during unit testing are combined to
form a subsystem. The integration testing is aimed at ensuring that all the
modules work properly as per the user requirements when they are put
together (that is, integrated).
 Regression testing ‘Re-tests’ the software or part of it to ensure that the
components, features, and functions, which were previously working
properly, do not fail as a result of the error correction process and integration
of modules.
 Smoke testing is defined as an approach of integration testing in which a
subset of test cases designed to check the main functionality of software are
used to test whether the vital functions of the software work correctly.
 Beta testing assesses the performance of the software at user’s site. This
testing is ‘Live’ testing and is conducted in an environment, which is not
controlled by the developer.
Self-Instructional
Material 297
Testing Techniques  Performance testing is designed to determine the performance of the software
(especially real-time and embedded systems) at the run-time in the context
of the entire computer-based system.
 Program analysis tools, also known as software testing tools, are frequently
NOTES
used to ensure consistency, thoroughness, and efficiency in testing software
products and to fulfil the requirements of planned testing activities.
 Manual testing is a software testing process in which test cases are executed
manually without using any automated tool. All test cases executed by the
tester manually according to the end user’s perspective.s
 White box testing, also known as structural testing is performed to check
the internal structure of a program. To perform white box testing, the tester
should have a thorough knowledge of the program code and the purpose
for which it is developed.
 Mutation testing is a white box method where errors are ‘Purposely’ inserted
into a program (under test) to verify whether the existing test case is able to
detect the error or not.
 Black box testing (or functional testing) checks the functional requirements
and examines the input and output data of these requirements.
 In Boundary Value Analysis (BVA), test cases are derived on the basis of
values that lie on the edge of the equivalence partitions. These values can
be input or output values either at the edge or within the permissible range
from the edge of an equivalence partition.
 Gray box testing technique is often defined as a mixture of black box testing
and white box testing techniques. This technique is similar to white box
testing in the aspect that it requires limited knowledge of the internal details
of the system under test, in order to design the test cases.

12.9 KEY WORDS

 Software testing: A process which is used to identify the correctness,

completeness and quality of a software.
 Test plan: A document which is developed to specify the objectives, scope,
method and purpose of software testing.
 Validation testing: The process of evaluating software during the
development process or at the end of the development process to determine
whether it satisfies specified business requirements. Validation Testing ensures
that the product actually meets the client’s needs.
 Smoke testing: It is defined as an approach of integration testing in which
a subset of test cases designed to check the main functionality of software
are used to test whether the vital functions of the software work correctly.
Self-Instructional
298 Material
  Regression testing: It ‘Re-tests’ the software or part of it to ensure that Testing Techniques

the components, features, and functions, which were previously working

properly, do not fail as a result of the error correction process and integration
of modules.
NOTES
 Debugging: A process of analysing and removing the error.

12.10 SELF ASSESSMENT QUESTIONS AND

EXERCISES

Short-Answer Questions
1. Who performs the testing?
2. Write the advantage of software testing.
3. Give the definition of testing.
4. What is testability?
5. Define the term performance testing.
6. Differentiate between static and dynamic test tools.
7. What is testing approaches?
8. Elaborate on the term control structure testing.
9. Write the advantage of manual testing.
10. Define the term black box testing.
Long-Answer Questions
1. Discuss about the software testing and its characteristics giving appropriate
examples.
2. Briefly explain the test case design and test case generation giving appropriate
examples.
3. Describe the guidelines of software testing with the help of diagram.
4. Briefly explain the types of software strategies with the help of diagram.
5. Discuss about the automated testing giving appropriate examples.
6. Briefly explain the white box testing with the help of diagram.
7. Describe briefly types of white box testing with the help of diagram.
8. Discuss about the types of error detection in black box testing.
9. Differentiate between white box and black box testing and giving appropriate
examples.

Self-Instructional
Material 299
Testing Techniques 10. Explain the characteristics features of the following information system:
a) Test Case Design
b) Unit Testing Method
NOTES c) Integration Testing
d) Beta Testing
e) System Testing
f) Security Testing
g) Manual Testing

12.11 FURTHER READINGS

Hughes, Bob, Mike Cotterell and Rajib Mall. 2017. Software Project
Management (SIE), 6th Edition. New York: McGraw Hill Education.
Schach, Stephen R. 2005. Object Oriented and Classical Software Engineering.
New Delhi: Tata McGraw-Hill.
Pressman, Roger S. 1997. Software Engineering, a Practitioner’s Approach.
New Delhi: Tata McGraw-Hill.
Somerville, Ian. 2001. Software Engineering. New Delhi: Pearson Education.
Ghezzi, Carlo, Mehdi Jazayeri, and Dino Mandriolli. 1991. Fundamentals of
Software Engineering. New Delhi: Prentice-Hill of India.
Jawadekar, Waman S. 2004. Software Engineering: Principles and Practice.
New Delhi: Tata McGraw-Hill.
Jalote, Pankaj. 1991. An Integrated Approach to Software Engineering. New
Delhi: Narosa Publishing House.

Self-Instructional
300 Material
 Software Reengineering

UNIT 13 SOFTWARE
REENGINEERING
NOTES
Structure
13.0 Introduction
13.1 Objectives
13.2 Software Reengineering and Software Maintenance Problems
13.3 Redevelopment vs. Reengineering
13.4 Business Process Reengineering
13.5 Software Reengineering Process Model
13.6 Answers to Check Your Progress Questions
13.7 Summary
13.8 Key Words
13.9 Self Assessment Questions and Exercises
13.10 Further Readings

13.0 INTRODUCTION

Software reengineering is the analysis and alteration of a software to reconstitute

it in a new form. The principles of reengineering when applied to the software
development process is called software reengineering. It affects positively at
software cost, quality, service to the customer and speed of delivery. In software
reengineering, the software is redefined in more efficient and effective manner.
Software engineering is a discipline of engineering that is concerned with
the design, development, testing, maintenance, and deployment of a software
product. These preceding aspects are part of the Software Development Life
Cycle (SDLC) that a software undergoes before it is launched for clients and
users. ‘Software Reengineering’ is the process of updating software. This process
includes developing additional features on the software and adding functionalities
for better and more efficient software. As far as the definition goes, this process
also entails that the software product will have improved maintainability. Thus,
reengineering is a step towards continuous improvement of software for better
development and customer experience. Additionally, it is a way to make existing
products improve their service.
Software reengineering is an economical process for software development
and quality enhancement of the product. This process enables the software
developer to identify the useless consumption of deployed resources and the
constraints that are restricting the development process so that the development
process could be made easier and cost-effective (time, financial, direct advantage,
optimize the code, indirect benefits, etc.) and maintainable.

Self-Instructional
Material 301
Software Reengineering Software maintenance in software engineering is the modification of a
software product after delivery to correct faults, and to improve performance or
other attributes of the software. A common perception of maintenance is that it
merely involves fixing defects. This perception is perpetuated by users submitting
NOTES problem reports that in reality are functionality enhancements to the system.
Business process reengineering, also known as Business Process Redesign
(BPR) is a management approach that assesses, analyses, and examines processes
of a business and their interaction with each other in order to improve the efficiency
of these processes. For this, BPR uses a set of tools that helps in reconfiguring the
business process of an organization along with its method of operation. The
objective is to reinvent the processes, make changes to these processes and analyse
the specification and design of new business processes.
In this unit, you will study about the software reengineering, software
maintenance problems, redevelopment vs. reengineering, business process
reengineering and software reengineering process model.

13.1 OBJECTIVES

After going through this unit, you will be able to:

 Understand the basic concept of software reengineering
 Elaborate on the software maintenance problems
 Differentiate between redevelopment and reengineering
 Analyse the business process reengineering
 Explain software reengineering process model

13.2 SOFTWARE REENGINEERING AND

SOFTWARE MAINTENANCE PROBLEMS

Software engineering is a discipline of engineering that is concerned with the design,

development, testing, maintenance, and deployment of a software product. These
preceding aspects are part of the Software Development Life Cycle (SDLC) that
a software undergoes before it is launched for clients and users. ‘Software
Reengineering’ is the process of updating software. This process includes developing
additional features on the software and adding functionalities for better and more
efficient software. As far as the definition goes, this process also entails that the
software product will have improved maintainability. Thus, reengineering is a step
towards continuous improvement of software for better development and customer
experience. Additionally, it is a way to make existing products improve their service.
Software maintenance in software engineering is the modification of a
software product after delivery to correct faults, and to improve performance or
Self-Instructional
302 Material
other attributes of the software. A common perception of maintenance is that it Software Reengineering

merely involves fixing defects. However, the studies specify that over 80% of
maintenance effort is typically used for non-corrective actions. This perception is
perpetuated by users submitting problem reports that in reality are functionality
enhancements to the system. More recent studies specify that the software NOTES
maintenance includes the bug-fixing which approximately amount to 21%.
Importance of Software Maintenance
The key software maintenance issues are both managerial and technical. Key
management issues include alignment with customer priorities, staffing, which
organization does maintenance, estimating costs. Key technical issues include
limited understanding, impact analysis, testing, and maintainability measurement.
Software maintenance is a very broad activity that includes error correction,
enhancements of capabilities, deletion of obsolete capabilities, and optimization.
Because change is inevitable, mechanisms must be developed for evaluation,
controlling and making modifications.
Consequently any work done to change or enhance the software after it is
in operation is considered to be maintenance task. The purpose is to preserve the
value of software over the time. The value can be enhanced by expanding the
customer base, meeting additional requirements, becoming easier to use, more
efficient and employing newer technology. Maintenance may span for 20 years,
whereas development may be 1–2 years.
Software Maintenance Planning
An integral part of software is maintenance, which requires an accurate maintenance
plan to be constructed during the software development. It should specify how
users will request modifications or report problems. The budget should include
resource and cost estimates, and a new decision should be addressed for the
development of every new system feature and its quality objectives. The software
maintenance, which can last for 5+ years (or even decades) after the development
process, calls for an effective plan which can address the scope of software
maintenance, the tailoring of the post delivery/deployment process, the designation
of who will provide maintenance, and an estimate of the life-cycle costs.
Software Maintenance Processes
Following are the six software maintenance processes:
1. The implementation process contains software preparation and transition
activities, such as the conception and creation of the maintenance plan; the
preparation for handling problems identified during development; and the
follow-up on product configuration management.
2. The problem and modification analysis process, which is executed once the
application has become the responsibility of the maintenance group. The
maintenance programmer must analyse each request, confirm it (by

Self-Instructional
Material 303
Software Reengineering reproducing the situation) and check its validity, investigate it and propose
a solution, document the request and the solution proposal, and finally, obtain
all the required authorizations to apply the modifications.
3. The process considering the implementation of the modification itself.
NOTES
4. The process acceptance of the modification, by confirming the modified
work with the individual who submitted the request in order to make sure
the modification provided a solution.
5. The migration process, for example platform migration, is exceptional and
is not part of daily maintenance tasks. If the software must be ported to
another platform without any change in functionality, this process will be
used and a maintenance project team is likely to be assigned to this task.
6. The maintenance process is an event, i.e., when it does not occur on a daily
or regular basis, then the piece of software is considered appropriate.
Following are a number of processes, activities and practices that are unique
to maintainers:
 Transition: A controlled and coordinated sequence of activities during
which a system is transferred progressively from the developer to the
maintainer.
 Maintenance Agreement: Service Level Agreements (SLAs) and
specialized (domain-specific) maintenance contracts negotiated by
maintainers.
 Modification Request and Problem Report Help Desk: A problem-
handling process used by maintainers to prioritize, document, and route
the requests as and when they receive.
Categories of Software Maintenance
E.B. Swanson initially identified three categories of maintenance, namely corrective,
adaptive, and perfective. As per the IEEE 1219 standard, we can define the
categories of maintenance as follows:
Corrective Maintenance: Reactive modification of a software product
performed after delivery to correct discovered problems. Corrective maintenance
can be automated with automatic bug fixing.
Adaptive Maintenance: Modification of a software product performed
after delivery to keep a software product usable in a changed or changing
environment.
Perfective Maintenance: Modification of a software product after delivery
to improve performance or maintainability.
Preventive Maintenance: Modification of a software product after delivery
to detect and correct latent faults in the software product before they become
effective faults.
Self-Instructional
304 Material
 There is also a notion of pre-delivery/pre-release maintenance which is all Software Reengineering

the good things you do to lower the total cost of ownership of the software.
Things like compliance with coding standards that includes software maintainability
goals. The management of coupling and cohesion of the software.
NOTES
Need for Maintenance
Software maintenance must be performed in order to:
 Correct Faults.
 Improve the Design.
 Implement Enhancements.
 Interface with Other Systems.
 Accommodate Programs so that Different Hardware, Software, System
Features, and Telecommunications Facilities can be used.
 Migrate Legacy Software.
 Retire Software.

13.3 REDEVELOPMENT VS. REENGINEERING

Software development and software engineering are interrelated terms, but they
do not mean quite the same thing. A software engineer is responsible for the software
development; not all software developers, however, are engineers. Software
engineering means applying engineering principles to software creation.
In software engineering, the Software Development Life Cycle (SDLC),
also referred to as the application development life-cycle, is a process for planning,
creating, testing, and deploying an information system. Additionally, SDLC can
also be used for the ‘Redevelopment’ of existing software. The systems
development life cycle concept applies to a range of hardware and software
configurations, as a system can be composed of hardware only, software only, or
a combination of both. There are usually six stages in this cycle, namely requirement
analysis, design, development and testing, implementation, documentation, and
evaluation.
In the redevelopment process, a Systems Development Life Cycle (SDLC)
is composed of a number of clearly defined and distinct work phases which are
used by systems engineers and systems developers to replan, redesign, rebuild,
retest, and then again deliver the required information systems.
Software reengineering is one of the viable ways to mitigate issues with
legacy applications. The new software products often have increased functionality,
better performance, greater reliability, and are easier to maintain than their
predecessors. Business Process Reengineering (BPR) defines business goals,
evaluates existing business processes, and creates revised business processes that

Self-Instructional
Material 305
Software Reengineering better meet current goals. Software reengineering involves inventory analysis,
document restructuring, reverse engineering, program and data restructuring, and
forward engineering. Many reengineering work products are the same as those
generated for any software engineering process (analysis models, design models,
NOTES test procedures). The final product for any reengineering process is a reengineered
business process and/or the reengineered software to support it. Testing is used to
uncover errors in content, functionality, and interoperability.
Software reengineering is a process of software development which is done
to improve the maintainability of a software system. Reengineering is basically the
examination and alteration of a system to reconstitute it in a new form. This process
encompasses a combination of sub-processes like reverse engineering, forward
engineering, reconstructing, etc. The need for software reengineering is essential
and is considered as an integral part of improving the quality of the products.

13.4 BUSINESS PROCESS REENGINEERING

Business process reengineering, also known as Business Process Redesign

(BPR) is a management approach that assesses, analyses, and examines processes
of a business and their interaction with each other in order to improve the efficiency
of these processes. For this, BPR uses a set of tools that helps in reconfiguring the
business process of an organization along with its method of operation. The
objective is to reinvent the processes, make changes to these processes and analyze
the specification and design of new business processes. Other objectives of BPR
are described below:
 User Friendly: One of the objectives of BPR is to get a competitive edge
over other business organizations. The competition exists as organizations
strive to satisfy users’ requirements as well as increase their returns. However,
to satisfy users, it is important to accomplish their requirements. For this,
BPR focuses on developing software in a customized form, which suits the
requirements of users. For example, let us consider two car manufacturers,
namely, ‘A’ and ‘B’. Suppose ‘A’ manufactures cars for the common people
while ‘B’ specializes in manufacturing cars customized according to user
requirements. When a user approaches these car manufacturers to purchase
a car, there is more probability of purchasing a car from ‘B’ because user
requirements are being accomplished in the car. The same example is
applicable to software as users prefer to purchase software, which is
customized according to their requirements.
 Effectiveness: An organization can be successful if it provides effective
software with the required quality and according to user requirements.
Generally, it is observed that users are interested in purchasing high quality
and effective software in less amount of money. However, even if their

Self-Instructional
306 Material
 requirements are met by an ‘expensive quality-software’, there is the Software Reengineering

probability that users purchase it since they focus on quality and not money.
For example, let us consider two car manufacturers namely, ‘X’ and ‘Y’,
where ‘X’ is more expensive than ‘Y’. Also, ‘X’ is manufacturing according
to user requirements and is effective and reliable in performance. While ‘Y’ NOTES
is similar to other cars that provide common functions and features, users
will prefer car ‘X’ since it is more effective and reliable. This example is
applicable to software also as users prefer to purchase software, which is
effective and reliable.
 Efficiency: An organization can be efficient if it has thorough knowledge of
skills required in business. To make effective and user-friendly software, it
is important that efficiency is considered both during the software
development and at the management level. In case an organization does not
analyse its efficiency at the management level, there is a chance that problems
will arise while marketing the software. Hence, it is important to consider
efficiency at both the development and management levels to avoid problems,
such as future maintenance.

Fig. 13.1 Layers of Hierarchy

As shown in Figure 13.1, when business process reengineering is applied,
conventional hierarchy of an organization is changed by reducing the number of
layers in the hierarchy. This reduction in layers leads to a flattened organization,
which is produced when middle management is removed from the layers of
hierarchy. Note that the tasks performed by the middle management (such as
supervision and collection of information required for an organization) are then
shared among the remaining levels of hierarchy. Also, BPR puts the self-managing
teams to work according to the processes within an organization, which results in
an improved performance at various levels.

Self-Instructional
Material 307
Software Reengineering Principles of Business Process Reengineering
There are several principles that an organization follows to maximize benefits and
minimize the cost of business process reengineering. These principles are listed
NOTES below:
 Organize around Processes and Outcomes: Generally, it is observed
that organizations divide the reengineering tasks among several people. Due
to this, it is possible that documentation is not available to the concerned
person on time when it is transferred from one person to another in the
organization. This delay leads to errors and delays in the development of
the target system. To avoid this, the tasks should be divided so that only a
single person is responsible for an entire process instead of entrusting the
process to many individuals. In addition, each process assigned should have
an outcome such as a finished component or a process that is complete. To
accomplish this, sometimes organizations replace their functional departments,
such as manufacturing and marketing, with the teams that focus on completing
a specific business process.
 Include Skilled People for Reengineering: Generally, an organization
is split into various departments. Each department is different from the other
and comprises individuals with special skills to perform specific tasks. All
these individuals should be considered in the reengineering process.
 Integrate Parallel Activities: There are various tasks that are to be
performed during software reengineering. Some of these tasks are carried
out parallel to each other. By carrying out parallel activities, less time is
consumed in reengineering the existing system as compared to the time
required to carry out those tasks in a sequence. When these tasks are being
carried out, there should be proper communication among the team members
to determine each other’s task and hence, modify their processes according
to the requirements in a target system. Once all the tasks are completed,
they should be integrated to make the complete system. An organization
can save time and expense if reengineering is carried out by integrating
parallel activities.
 Empower People and Use Built-In Controls: Each individual who works
in an organization should be empowered with decision-making
responsibilities. The advantage is that it minimizes the layers of hierarchy in
an organization. Using this principle, faster responses are achieved for
problems occurring during reengineering and the quality of the task performed
is enhanced.

Self-Instructional
308 Material
Elements of Business Process Reengineering Software Reengineering

BPR comprises several elements, namely, strategies, processes, technology and

people (see Figure 13.2). The strategies and processes are used as a basis for
utilization of technologies and redesigning of the existing system, which is NOTES
developed by the people. All these elements are described below.
 Strategies: An organization follows several strategies for its business. These
strategies include organizational strategy, technological strategy, and
human resources strategy. It is important to consider all these strategies
according to the ‘market place’ where an organization is carrying out its
business. It is essential that these strategies are current and relevant to the
organization and include internal and external constraints of the organization.
 Processes: A business process is a set of logically related tasks, which are
performed in order to accomplish a defined business outcome. Various
business processes include designing for new software, purchasing services
for software, employing individuals for BPR, and so on. For performing
these processes, several requirements such as people, hardware, and
software resources are needed. Processes can be specified on different
levels within an organization. Note that the processes are not determined
by internal organizational requirements, but by the user requirements even
though the organizational constraints should be considered in the processes.
 Technology: Use of new technology is regarded as one of the important
considerations in organizations. Technology helps in supporting the process-
driven organizations by improving the existing processes within the organization.
 People: For performing reengineering, people are essential. Generally, it is
observed that it is easy for the top management to support reengineering as
compared to middle management. This is because the top management has
to simply accept or reject reengineering for its organization whereas the
middle management has to identify the probability of change and then perform
these changes. Note that it is essential for the people working in an
organization to work according to business strategies and organizational
environment.

Fig. 13.2 Elements of Business Process Reengineering

Self-Instructional
Material 309
Software Reengineering Business Process Methodology
Business process methodology has been developed to provide a structured
approach for the business processes and to facilitate the understanding of these
NOTES processes. As shown in Figure 13.3, this methodology comprises five activities,
namely, Preparation of BPR, Mapping and Analysis of As-Is Process, Designing
of To-Be Processes, Implementation of Re-Engineered Process and
Improvement of Re-Engineered Process Continuously. Each activity further
comprises several sub-activities.

Fig. 13.3 Business Process Methodology

Preparation of BPR
It is important to consider the requirements of reengineering before starting the
reengineering process for existing systems in an organization. This activity begins
with understanding the importance of reengineering. For this, an executive consensus
is made that describes the judgment and opinion about reengineering. A document
that includes official instruction about reengineering is prepared.
It is difficult to begin reengineering until there is a strategic direction from the
top management. In addition, it is essential to consider the impact of organizational
environment on the effort required in reengineering. By considering this impact, it
becomes easy to establish guidelines for the reengineering project. Another factor
that should be considered regarding the reengineering project is to understand the
expectations of users and identify the existing processes that are responsible for
not meeting the user requirements. Considering user requirements helps in identifying
the objectives to be accomplished in the target system. This in turn helps in achieving
the expected output from the software during the reengineering process.
Mapping and Analysis of As-Is Processes
It is important to understand the existing process of the organization, that is, the
analysis of ‘As-Is’ processes. ‘As-Is’ processes include existing processes, which
Self-Instructional
310 Material
should not be neglected when a new design for the process begins. For this purpose, Software Reengineering

mapping of the existing processes is necessary. Sometimes, it is observed that

organizations do not consider analysis of ‘As-Is’ processes as an important activity.
Because of this, too much time gets taken up and it leads to increased costs for
designing the ‘To-Be’ system. This in turn could mean developing the software NOTES
system that does not meet user requirements.
The objective of this phase is to identify the cause that prevents the process
from achieving the desired output. Other objective is to identify the problem that
results in lack of proper communication between organizations and the people.
Next, the amount of time consumed by each activity and the costs incurred in
terms of resources is calculated through Activity Based Costing (ABC) method.
Designing of To-Be Processes
This activity generates one or more alternatives for the current situation, which
accomplish the strategic objectives of an organization. For this purpose,
benchmarking is followed. Benchmarking is the process of comparing the
performance of processes of an organization and the ways in which they are
conducted with the relevant organizations in order to improve the processes. Note
that the organizations may or may not be in competition or have the same kinds of
business.
Once the potential improvement in the existing processes is known, the
‘To-Be’ model is developed using the modeling methods available. Many such
models are developed out of which the appropriate ‘To-Be’ model is selected
using the trade-off analysis method. Like the ‘As-Is’ model, this model also uses
simulation and ABC methods, in order to analyze the time and cost involved in the
design process. Note that this activity is iterative. Once the ‘To-Be’ models are
completed, they are validated for correctness.
Implementation of Re-Engineered Process
Once the design of ‘To-Be’ model is complete, the re-engineered process is
implemented. Next, planning is done to migrate to the target system. After
implementation, a transition plan is developed to migrate from the ‘As-Is’ process
to the redesigned process. This plan should be according to the structure of the
organization, information system, and the business policies and procedures of the
redesigned process. The pilot versions of the transition plan are designed and
demonstrated. Pilot versions are prototypes of the transition plan, which are
developed to provide a view of the transition plan that is to be finalized. Last of all,
the transition plan is validated with the help of prototyping and simulation techniques.
Improvement of Re-Engineered Process Continuously
To make the reengineering process successful, it is required to monitor the progress
of the actions that are performed during the process. The progress of action can

Self-Instructional
Material 311
Software Reengineering be identified by conducting surveys about the attitude of people related to re-
engineered process and user perceptions.
The performance tracking system ensures the continuous improvement of
the re-engineered process. This is also possible by applying problem-solving skills.
NOTES
Also, for continuous improvement, Total Quality Management (TQM) is used as
a tool in business process reengineering to manage various problems that occur
during BPR effort.
Business Process Reengineering Tools
Several tools are used to analyse and assess the existing business processes along
with the specification and design of new processes. Generally, these tools help in
assessing the inefficiencies related to the workflow within the organization. Some
of the BPR tools used in reengineering are listed in Table 13.1.
Table 13.1 Business Process Reengineering Tools
BPR Tools Features Operating Environment
Apache  Provides a range of approaches Apple Macintosh (4/40
upwards).
to map analyse, improve, and
automate processes.
Caddie  Provides object oriented Unix, X Windows, Sun SPARC.
approach.
 Provides open-distributed
multi-user architecture.
Bonapart  Helps in graphical representation. MS-DOS, Microsoft Windows
3.1  Provides representation of
(for GUI).
different views and levels of
abstraction.
 Provides simulation of
alternatives.
Ithink  Helps in constructing maps Apple Macintosh.
through graphical interface.

13.5 SOFTWARE REENGINEERING PROCESS

MODEL

The reengineering process absorbs a considerable amount of resources due to

which every organization uses a pragmatic strategy known as software
reengineering process model for performing software reengineering. This model
consists of five activities (see Figure 13.4), namely, inventory analysis, document
restructuring, reverse engineering, restructuring and forward engineering.
This model is also known as cyclical model since every activity in it can be
revisited.
Self-Instructional
312 Material
 Software Reengineering

NOTES

Fig. 13.4 Software Reengineering Process Model

Inventory Analysis
All organizations maintain an inventory of all their applications. An inventory is
the spreadsheet model, which provides information in the form of detailed
descriptions (like business issues, size) of every active application within the
organization. This information is classified according to criteria, such as business
criticality and current maintainability of inventory.
Once information is classified, a reengineering team is formed and resources
necessary for the reengineering process are allocated to the team. Note that it is
important to revisit the inventory on a regular basis since it is possible that the
status of application (such as, business criticality) changes over time, due to which
the priorities of reengineering may also change.
Document Restructuring
As stated earlier, in the legacy system, documentation is usually not properly
maintained. This creates problems when reengineering is performed. Hence it is
important to update the available documentation so that it contains complete
information on the existing system. There are various options for updating the
available documentation; an organization can choose the best available option
according to its requirements. The options for updating the documentation are
listed below.
 Documentation should not be Changed: Till a system works properly,
an organization may opt not to update or recreate the documentation
because it is not possible to recreate documentation for many (say,
hundreds) computer programs. Also, if the program is becoming obsolete
and is unlikely to change, then the organization may choose not to update
or recreate the document.
 Documentation should be Updated: When only some portions of the
software system are undergoing a change, it is not necessary to re-
Self-Instructional
Material 313
Software Reengineering document the application entirely. Instead, only the changed portions of
the application are documented, which over the time leads to useful and
relevant documentation.
 System should be Fully Re-Documented: When the system is
NOTES
business critical, then the entire application should be re-documented.
However, the documentation is kept to the necessary minimum.
Reverse Engineering
Reverse engineering is the process of analysing the program of the existing software
system, its documentation and behavior in order to develop a new program at a
higher abstraction level. Note that reverse engineering does not involve changes to
the system or creation of a new system; instead it is a process of examining the
system without changing its overall functionality.
The key objectives of reverse engineering are to generate alternative views,
recover lost information, detect side effects, synthesize higher abstractions and
facilitate reuse. Other objectives of reverse engineering are listed below.
 Removing access restrictions from the software system
 Customizing the existing system to recreate it into new form
 Analysing both good and bad features of the software system
 Improving the performance and features of the existing software system
 Duplicating an existing component or software system to understand
the security mechanism
 Updating obsolete software system and their old development processes
with better, effective and less expensive technologies
Reverse engineering is not only used in software engineering but also in
various other fields such as entertainment, consumer products, microchips,
electronics, and mechanical designs. Before starting reverse engineering, it is
essential that a well-planned life cycle analysis and cost-benefit analysis of the
software system is carried out.
Reverse engineering is a time consuming process. However, nowadays this
process has become easy due to present usage of Information Technology. The
reasons for using Information Technology for reverse engineering are listed below:
 Engineering techniques have become computerized. Due to this, the task
of preparing designs is done by computer, which makes it easier for the
reverse engineering team to recognize and interpret the future design of
the software system.
 Artificial intelligence techniques are being used for pattern recognition,
parsing, and interpretation in order to determine the structures along
Self-Instructional
314 Material
 with their location within the software system. Thus, it becomes easy Software Reengineering

and less time consuming to determine the structure of software during

reverse engineering.
Reverse Engineering Process NOTES
To perform reverse engineering, a reverse engineering team is formed, which
analyses the software system and generates information about it. Sometimes, it is
observed that the team, which was involved in developing the existing system, is
also involved in developing the new system. In such a case, it is difficult for the
team to avoid the assumptions or considerations of the existing system. This in
turn leads to generation of a system which is similar to the existing system. To
avoid this, the team is divided after specification, such as when the design and
code specification has been produced. However, before being divided, it is
important for the team to make the specification in an abstract manner.

Fig. 13.5 Reverse Engineering Process

As shown in Figure 13.5, the reverse engineering process begins by extracting

the requirements and detailed design information from the source code and the
documentation of legacy system. A requirements document is created and a high-
level design abstraction is extracted and expressed using data-flow and control-
flow diagrams. Next, the recovered design is reviewed for consistency and
correctness. Once the requirements and design information is achieved, the reverse
engineering documentation is generated.
Self-Instructional
Material 315
Software Reengineering Reverse Engineering to Understand Data
Reverse engineering occurs at various levels of abstraction, such as program level
and system level. At the program level, internal program data structures are reverse
NOTES engineered. At the system level, global data structures such as files and databases
are re-engineered to incorporate new database management paradigms. For
example, moving a relational database to an object oriented database system. The
data structures which are reverse engineered are listed below.
 Internal Data Structures: For internal program data, reverse
engineering is concerned with definition of classes of objects. For this
purpose, code of the program is analysed so that the program variables
related to each other can be grouped. Sometimes, it is observed that the
data organization in a program identifies abstract data types. For
example, files, lists, and other data structures used in program indicate
the classes made in the program.
 Database Structures: Generally, a database describes how the data
objects are defined in a program without considering the program
organization and its structure. In addition, the database provides
information about methods used for establishing relationships among
objects. Thus, it is essential to understand the existing objects and their
relationships in order to perform reengineering from one database to
another.
Reverse Engineering to Understand Processing
To understand processing in reverse engineering, it is important to understand and
determine the procedural abstractions of the source code. For this, code is analysed
at different levels of abstraction such as system level, program level, component
level, and statement level.
Note that the detailed information about the functionality of an existing system
should be collected before starting with a detailed reverse engineering process.
With the help of this information, further analysis of the new system is carried out.
This information also describes the interoperability issues among applications within
the system. Every program included in the application system describes the
functional abstraction at a high level of detail. Once the functional abstraction is
identified, a block diagram depicting the interaction between these functional
abstractions is created.
Every component of the function performs a sub-function and shows a
defined procedural abstraction. For each component, a component specification
is developed. However, in some cases, system, program, and component
specifications already exist. In such cases, the specifications are reviewed in order
to check their conformance with the existing code.

Self-Instructional
316 Material
 When software systems are large, reverse engineering process is carried Software Reengineering

out using a semi-automated approach. For this purpose, automated tools are used
to help the software engineer to understand the syntax and semantics of the existing
code. Finally, the output of reverse engineering is transferred to restructuring and
forward engineering tools to complete the reengineering process. NOTES

Reverse Engineering User Interfaces

Sophisticated Graphical User Interfaces (GUI) have become a requirement for
almost all computer-based systems. Thus, GUIs are redesigned. This practice has
become common and is considered as an important reengineering activity.
However, it is essential to carry out the reverse engineering process before
redeveloping a user interface. To perform reverse engineering on user interfaces,
the following points should be considered.
 Basic actions of user interfaces such as keystrokes and mouse clicks
 Brief description of the behavioral response of the system to these actions
 Requirement of replacement with new user interfaces
For the first two considerations, behavioral modeling notation is followed.
For this, it is important to observe the existing user interfaces. For the third
consideration, it may be desirable to develop new interaction metaphors, since
the new interface may not be similar to the old GUI interface. For example, in the
older interface a user may get three chances to log on while in the new interface
the user gets only one chance.
Restructuring
Restructuring modifies the source code and data in such a way that it can incorporate
future changes. Generally, restructuring does not modify the overall program
structure; rather, it concentrates on design details of individual modules of the
program. Restructuring occurs when the basic architecture of an application is
working correctly and only some parts of the software require restructuring. The
advantages of restructuring are listed below:
 Better quality and documentation of programs
 Reduction in effort required in software maintenance
 Ease of software testing and debugging
 Less complexity in programs and conformance to software engineering
practices and standards
Generally, restructuring is classified into two categories, namely, code
restructuring and data restructuring. Code restructuring is performed to analyze
the source code of the existing system while data restructuring is concerned
with the analysis of data objects in the source code.

Self-Instructional
Material 317
Software Reengineering Code Restructuring
Code restructuring is performed to achieve a design that performs the same functions
as the existing programs but with better quality. Generally, it is observed that the
NOTES legacy systems have efficient program architecture, but the individual modules are
difficult to understand, test and maintain. This may be because the codes in these
modules are very complex. In such cases, the code within these modules can be
restructured.
Figure 13.6 shows the process of code restructuring in a program. After
selecting a source code to be restructured, it is analysed with the help of an analyzer
and converted to a directed graph using a graph builder. The directed graph used
in code restructuring describes how control of code moves from one program to
another. Using directed graph, program generator writes the restructured code.
Techniques, such as simplification and transformation can be applied to the
directed graph without changing the semantics of the program code. These
techniques detect and remove the unreachable parts of the code. Statements written
using ‘go to’ control statements are replaced with ‘while’ loops and simple
conditional statements. Note that the code being restructured can be of any
programming language. An example of code restructuring is to convert a program
in ‘FORTRAN’ to a program in ‘C’ language.

Fig. 13.6 Code Restructuring

Self-Instructional
318 Material
Code restructuring when performed using automation may create problems. Some Software Reengineering

of these problems are listed below.

 Loss of Comments: Once the code restructuring process begins, the
comments used in the existing code are lost. This creates problems when
NOTES
the reengineering team requires understanding of the new code.
 Heavy Computational Demands: The algorithms embedded in
restructuring tools are complex. Sometimes, with faster hardware, a lot of
time is consumed to complete the restructuring process of large programs.
Note: Once the code restructuring is complete, the restructured code is reviewed and tested
to determine whether errors are present in it. In addition, the documentation is updated.

Data Restructuring
It is observed that a program with feeble data architecture is difficult to enhance
and maintain. Therefore, it is necessary to restructure the data architecture of such
programs. Before starting the data restructuring process, it is essential to analyse
the source code to extract information about data items and objects from the
code. This information helps in understanding the data-flow and data structures,
which are required to be implemented.
When the analysis is complete, the process of data redesign begins. To
achieve consistency among names of data items or data structures, mainly two
types of redesign are used, namely, data record standardization and data name
rationalization. Data record standardization specifies the data definitions of
data items in order to achieve consistency within an existing data structure. Data
name rationalization ensures that all the data naming conventions are as per
quality standards. This redesign also checks whether the aliases of data structures
and data items have been eliminated.
Forward Engineering
Forward engineering, also known as renovation or reclamation, is a conventional
process that recovers design information from the existing system and uses it to
modify or restructure the existing system in order to improve its overall quality.
Mostly, re-engineered software re-implements the functions of the existing system
by adding new functions and/or improves overall performance of the system.
In forward engineering, the target system is created by moving down from
high-level abstractions to logical design and then proceeding to the physical design
of a system. Note that as the abstraction level decreases, information is collected
about the existing system.

Self-Instructional
Material 319
Software Reengineering

NOTES

Fig. 13.7 Forward Engineering

It is important to note the difference between forward engineering and

reengineering. As shown in Figure 13.7, forward engineering begins with system
specification and focuses on design and implementation of the new system.
However, reengineering starts with an existing software system and progresses
towards understanding and transformation of the existing system to achieve a re-
engineered system. There are several principles, concepts, and methods of software
engineering, which are applied in forward engineering. The purpose of using these
principles, concepts, and methods is to recreate the existing application or the
software system. Note that the new system includes both new and existing functions
and features.
Forward Engineering for Client-Server Architecture
Various distributed environments can be designed using forward engineering. Over
the years, several mainframe applications have been re-engineered to conciliate
client-server architecture. A mainframe application, which is re-engineered into
client-server architectures, consists of the features listed below:
 Functionality of application is migrated to each client computer
 New GUIs are implemented at client computers
 The functions of database are assigned to server
 Specialized functionality such as compute-inventive analysis stays on server
side
 Communication, security and control requirements are established at both
server and client side
Forward engineering of client-server applications commences with detailed
analysis of business requirements of the system. For this purpose, three layers of
abstraction are used which are as follows:
 Database Layer: This layer is at the base of client-server architecture and
manages the transactions and queries from client applications. Note that
these transactions and queries are according to the business rules of the
organization. To redesign the database layer, the functions and architecture
Self-Instructional
320 Material
 of the existing database must be reverse engineered. When the client-server Software Reengineering

database is re-engineered, it ensures that transactions are carried out

consistently and that only authorized users make upgradations to the
database.
NOTES
 Business Rules Layer: This layer depicts the software, which is resident
both on client and server machines. This software carries out the control
and coordination tasks to ensure that communication and queries between
the client application and database are performed in conformance with the
business processes.
 Client Applications Layer: This layer implements those business functions,
which are required by a particular group of users. There are cases when
mainframe application is divided into a number of smaller and re-engineered
applications. Communication among these applications is controlled by the
business rules layer.
Forward Engineering for Object Oriented Architectures
Nowadays, many organizations use the object oriented paradigm to develop
software. However, the problem arises when the software, which is developed
using the conventional methods, is to be integrated into a large object oriented
system. To avoid this, the older systems need to be re-engineered.
For reengineering conventional software into object oriented architecture,
the existing software is reverse engineered in order to create a suitable data model,
functional model, and behavioral model. In case, the re-engineered system provides
more functionality or features than the existing system then use-cases are created.
Next, the data models, which are created during reverse engineering, are used
along with Class-Responsibility-Collaborator (CRC) modeling. This modelling
provides a way to identify and organize classes, which are required for the software.
In other words, CRC modeling helps in defining the classes. The object oriented
design begins once the class hierarchy, object-relationship models, and the object-
behavior models are defined.
As object oriented forward engineering progresses from analysis to design,
a Component-Based Software Engineering (CBSE) process model is prepared.
This model focuses on design and development of computer-based systems using
reusable software components. Note that the algorithms and data structures of the
existing application or software system can be used for those classes that are to be
re-engineered from the scratch. However, it is important that the application or
software system to be re-engineered is redesigned to conform to the object oriented
architecture.
Forward Engineering User Interfaces
A significant portion of all effort is expended when applications are changed from
mainframe to desktop. This is because the user always prefers graphical user
Self-Instructional
Material 321
Software Reengineering interfaces over character-based user interfaces as the former are interactive and
user friendly. Various models for reengineering user interfaces are as follows:
 Understand the Original Interface and Movement of Data: The
purpose of understanding the original interfaces and movement of data (that
NOTES
flow between GUI and the remaining program) is to identify how the elements
of a program interact with each other. It is essential for the newly developed
GUIs to be consistent with the data that moves between character-based
design and the program.
 Remodel the Behaviour of Existing Interface into Abstractions, which
are same as GUI: Generally, it is observed that mode of interaction in
older and new software systems varies; however, the business behavior
exhibited by both these systems should remain the same.
 Introduce Improvements that Make the Mode of Interaction more
Efficient: The existing interface should be properly analyzed in order to
determine the inadequacy in them. This helps to correct errors and improves
the design of new GUIs.
 Develop and Integrate New GUIs: The effort required to develop GUI
can be minimized if class libraries and automated tools exist. It is necessary
to ensure that GUI does not adversely affect the rest of the application.

Check Your Progress

1. What is software reengineering?
2. Define software maintenance with reference to software engineering.
3. What are the key software maintenance issues?
4. Explain the term business process reengineering.
5. What are the elements of business process reengineering?
6. Elaborate on software reengineering process model.
7. What is reverse engineering?

13.6 ANSWERS TO CHECK YOUR PROGRESS

QUESTIONS

1. ‘Software Reengineering’ is the process of updating software. This process

includes developing additional features on the software and adding
functionalities for better and more efficient software. As far as the definition
goes, this process also entails that the software product will have improved
maintainability. Thus, reengineering is a step towards continuous
improvement of software for better development and customer experience.
Additionally, it is a way to make existing products improve their service.
Self-Instructional
322 Material
2. Software maintenance in software engineering is the modification of a Software Reengineering

software product after delivery to correct faults, and to improve performance

or other attributes of the software. A common perception of maintenance is
that it merely involves fixing defects. However, the studies specify that over
80% of maintenance effort is typically used for non-corrective actions. This NOTES
perception is perpetuated by users submitting problem reports that in reality
are functionality enhancements to the system. More recent studies specify
that the software maintenance includes the bug-fixing which approximately
amount to 21%.
3. The key software maintenance issues are both managerial and technical.
Key management issues include alignment with customer priorities, staffing,
which organization does maintenance, estimating costs. Key technical issues
include limited understanding, impact analysis, testing, and maintainability
measurement.
4. Business process reengineering, also known as Business Process Redesign
(BPR) is a management approach that assesses, analyses, and examines
processes of a business and their interaction with each other in order to
improve the efficiency of these processes. For this, BPR uses a set of tools
that helps in reconfiguring the business process of an organization along
with its method of operation. The objective is to reinvent the processes,
make changes to these processes and analyse the specification and design
of new business processes.
5. Business process reengineering comprises several elements, namely,
strategies, processes, technology and people. The strategies and processes
are used as a basis for utilization of technologies and redesigning of the
existing system, which is developed by the people.
6. The reengineering process absorbs a considerable amount of resources
due to which every organization uses a pragmatic strategy known as software
reengineering process model for performing software reengineering. This
model consists of five activities, namely, inventory analysis, document
restructuring, reverse engineering, restructuring and forward engineering.
This model is also known as cyclical model since every activity in it can be
revisited.
7. Reverse engineering is the process of analysing the program of the existing
software system, its documentation and behaviour in order to develop a
new program at a higher abstraction level. Reverse engineering does not
involve changes to the system or creation of a new system; instead it is a
process of examining the system without changing its overall functionality.
The key objectives of reverse engineering are to generate alternative views,
recover lost information, detect side effects, synthesize higher abstractions
and facilitate reuse.

Self-Instructional
Material 323
Software Reengineering
13.7 SUMMARY

 Software engineering is a discipline of engineering that is concerned with

NOTES the design, development, testing, maintenance, and deployment of a software
product. These preceding aspects are part of the Software Development
Life Cycle (SDLC) that a software undergoes before it is launched for
clients and users.
 ‘Software Reengineering’ is the process of updating software. This process
includes developing additional features on the software and adding
functionalities for better and more efficient software.
 Software maintenance in software engineering is the modification of a
software product after delivery to correct faults, and to improve performance
or other attributes of the software.
 The key software maintenance issues are both managerial and technical.
Key management issues include alignment with customer priorities, staffing,
which organization does maintenance, estimating costs. Key technical issues
include limited understanding, impact analysis, testing, and maintainability
measurement.
 Software maintenance is a very broad activity that includes error correction,
enhancements of capabilities, deletion of obsolete capabilities, and
optimization. Because change is inevitable, mechanisms must be developed
for evaluation, controlling and making modifications.
 E.B. Swanson initially identified three categories of maintenance, namely
corrective, adaptive, and perfective.
 Software development and software engineering are interrelated terms, but
they do not mean quite the same thing.
 A software engineer is responsible for the software development; not all
software developers, however, are engineers. Software engineering means
applying engineering principles to software creation.
 In software engineering, the Software Development Life Cycle (SDLC),
also referred to as the application development life-cycle, is a process for
planning, creating, testing, and deploying an information system.
 The systems development life cycle concept applies to a range of hardware
and software configurations, as a system can be composed of hardware
only, software only, or a combination of both. There are usually six stages in
this cycle, namely requirement analysis, design, development and testing,
implementation, documentation, and evaluation.
 In the redevelopment process, a Systems Development Life Cycle (SDLC)
is composed of a number of clearly defined and distinct work phases which

Self-Instructional
324 Material
 are used by systems engineers and systems developers to replan, redesign, Software Reengineering

rebuild, retest, and then again deliver the required information systems.
 Business process reengineering, also known as Business Process Redesign
(BPR) is a management approach that assesses, analyses, and examines
NOTES
processes of a business and their interaction with each other in order to
improve the efficiency of these processes.
 BPR uses a set of tools that helps in reconfiguring the business process of
an organization along with its method of operation. The objective is to
reinvent the processes, make changes to these processes and analyse the
specification and design of new business processes.
 An organization can be successful if it provides effective software with the
required quality and according to user requirements.
 Generally, it is observed that users are interested in purchasing high quality
and effective software in less amount of money. However, even if their
requirements are met by an ‘expensive quality-software’, there is the
probability that users purchase it since they focus on quality and not money.
 Generally, an organization is split into various departments. Each department
is different from the other and comprises individuals with special skills to
perform specific tasks. All these individuals should be considered in the
reengineering process.
 BPR comprises several elements, namely, strategies, processes, technology
and people. The strategies and processes are used as a basis for utilization
of technologies and redesigning of the existing system, which is developed
by the people.
 Business process methodology has been developed to provide a structured
approach for the business processes and to facilitate the understanding of
these processes. This methodology comprises five activities, namely,
Preparation of BPR, Mapping and Analysis of As-Is Process, Designing of
To-Be Processes, Implementation of Re-Engineered Process and
Improvement of Re-Engineered Process Continuously. Each activity further
comprises several sub-activities.
 ‘As-Is’ processes include existing processes, which should not be neglected
when a new design for the process begins. For this purpose, mapping of the
existing processes is necessary.
 The reengineering process absorbs a considerable amount of resources
due to which every organization uses a pragmatic strategy known as software
reengineering process model for performing software reengineering. This
model consists of five activities, namely, inventory analysis, document
restructuring, reverse engineering, restructuring and forward engineering.
This model is also known as cyclical model since every activity in it can be
revisited.
Self-Instructional
Material 325
Software Reengineering  Reverse engineering is the process of analysing the program of the existing
software system, its documentation and behaviour in order to develop a
new program at a higher abstraction level.
 Reverse engineering does not involve changes to the system or creation of
NOTES
a new system; instead it is a process of examining the system without changing
its overall functionality.
 The key objectives of reverse engineering are to generate alternative views,
recover lost information, detect side effects, synthesize higher abstractions
and facilitate reuse.
 Restructuring modifies the source code and data in such a way that it can
incorporate future changes. Generally, restructuring does not modify the
overall program structure; rather, it concentrates on design details of individual
modules of the program.
 Restructuring occurs when the basic architecture of an application is working
correctly and only some parts of the software require restructuring.
 Generally, restructuring is classified into two categories, namely, code
restructuring and data restructuring. Code restructuring is performed to
analyse the source code of the existing system while data restructuring is
concerned with the analysis of data objects in the source code.
 Forward engineering, also known as renovation or reclamation, is a
conventional process that recovers design information from the existing
system and uses it to modify or restructure the existing system in order to
improve its overall quality.
 Mostly, reengineered software re-implements the functions of the existing
system by adding new functions and/or improves overall performance of
the system.
 In forward engineering, the target system is created by moving down from
high-level abstractions to logical design and then proceeding to the physical
design of a system. As the abstraction level decreases, information is
collected about the existing system.
 As object oriented forward engineering progresses from analysis to design,
a Component-Based Software Engineering (CBSE) process model is
prepared. This model focuses on design and development of computer-
based systems using reusable software components. The algorithms and
data structures of the existing application or software system can be used
for those classes that are to be reengineered from the scratch.

Self-Instructional
326 Material
 Software Reengineering
13.8 KEY WORDS

 Software engineering: Software engineering is a discipline of engineering

that is concerned with the design, development, testing, maintenance, and NOTES
deployment of a software product.
 Software reengineering: Software reengineering is the process of updating
software. This process includes developing additional features on the
software and adding functionalities for better and more efficient software.
 Software maintenance: Software maintenance in software engineering is
the modification of a software product after delivery to correct faults, and
to improve performance or other attributes of the software.
 Business process reengineering: Business process reengineering, also
known as Business Process Redesign (BPR) is a management approach
that assesses, analyses, and examines processes of a business and their
interaction with each other in order to improve the efficiency of these
processes.
 Reverse engineering: Reverse engineering is the process of analysing
the program of the existing software system, its documentation and behaviour
in order to develop a new program at a higher abstraction level.
 Restructuring: Restructuring modifies the source code and data in such a
way that it can incorporate future changes. Generally, restructuring does
not modify the overall program structure; rather, it concentrates on design
details of individual modules of the program.
 Code restructuring: Code restructuring is performed to analyse the source
code of the existing system.
 Data restructuring: Data restructuring is concerned with the analysis of
data objects in the source code.
 Forward engineering: Forward engineering, also known as renovation or
reclamation, is a conventional process that recovers design information from
the existing system and uses it to modify or restructure the existing system in
order to improve its overall quality.

13.9 SELF ASSESSMENT QUESTIONS AND

EXERCISES

Short-Answer Questions
1. What is software reengineering?
2. Explain the concept of software maintenance.

Self-Instructional
Material 327
Software Reengineering 3. Define the categories of software maintenance.
4. Differentiate between redevelopment and reengineering.
5. Elaborate on business process reengineering.
NOTES 6. What is reverse engineering?
7. Explain the software reengineering process model.
8. Define the concept of forward engineering.
Long-Answer Questions
1. Discuss the significance of software engineering and software reengineering
giving examples.
2. Explain software maintenance planning and the six software maintenance
processes giving appropriate examples.
3. Why software maintenance is required? Explain giving suitable examples.
4. Discuss the software redevelopment and software reengineering processes.
5. Briefly discuss about business process reengineering.
6. Elaborate on reverse engineering process giving examples.
7. Discuss in detail the software reengineering process model with the help of
examples.

13.10 FURTHER READINGS

Hughes, Bob, Mike Cotterell and Rajib Mall. 2017. Software Project
Management (SIE), 6th Edition. New York: McGraw Hill Education.
Schach, Stephen R. 2005. Object Oriented and Classical Software Engineering.
New Delhi: Tata McGraw-Hill.
Pressman, Roger S. 1997. Software Engineering, a Practitioner’s Approach.
New Delhi: Tata McGraw-Hill.
Somerville, Ian. 2001. Software Engineering. New Delhi: Pearson Education.
Ghezzi, Carlo, Mehdi Jazayeri, and Dino Mandriolli. 1991. Fundamentals of
Software Engineering. New Delhi: Prentice-Hill of India.
Jawadekar, Waman S. 2004. Software Engineering: Principles and Practice.
New Delhi: Tata McGraw-Hill.
Jalote, Pankaj. 1991. An Integrated Approach to Software Engineering. New
Delhi: Narosa Publishing House.

Self-Instructional
328 Material
 Project Closure

UNIT 14 PROJECT CLOSURE

Structure NOTES
14.0 Introduction
14.1 Objectives
14.2 Project Closure Analysis
14.3 Infosys Project Closure Analysis Report
14.4 ACIC Project Closure Analysis Report
14.5 Answers to Check Your Progress Questions
14.6 Summary
14.7 Key Words
14.8 Self Assessment Questions and Exercises
14.9 Further Readings

14.0 INTRODUCTION

A software project has two main activity dimensions: engineering and project
management. The engineering dimension deals with building the system and focuses
on issues, such as how to design, test, code, and so on. The project management
dimension deals with properly planning and controlling the engineering activities to
meet project goals for cost, schedule, and quality.
Project closure analysis is the key to learning from the past so as to provide
future improvements. To achieve this goal, it must be done carefully in safe
atmosphere so that instructions can be captured and used to improve the process
and future projects. Closing project or phase is the process of finalizing all activities
for the project, phase, or contract. The key benefits of this process are the project
or phase information is archived, the planned work is completed, and organizational
team resources are released to pursue new endeavors.
The Infosys Company is a software development company that has an
enviable track record of project execution. The aspects of Infosys project
management include planning, execution, and closure. Infosys has been assessed
at Level 5 (the highest level) of the Capability Maturity Model (CMM). By extracting
project management processes from the set of processes at Infosys, it can be
illustrated that how projects are managed in a high-maturity organization.
In this unit, you will study about the project closure, project closure analysis,
Infosys project closure analysis report and ACIC project closure analysis report.

Self-Instructional
Material 329
Project Closure
14.1 OBJECTIVES

After going through this unit, you will be able to:

NOTES  Discuss the significance of project closure
 Elaborate on project closure analysis
 Understand the Infosys project closure analysis report
 Define ACIC project closure analysis report

14.2 PROJECT CLOSURE ANALYSIS

The project closure phase is the last phase in the project life cycle. In this phase,
we formally close a project and then report its overall level of success to the
sponsor.
Project closure involves handing over the deliverables to the customer,
passing the documentation to the business, cancelling supplier contracts, releasing
staff and equipment, and informing stakeholders of the closure of the project.
After a project has been closed, a post implementation review is completed
to determine the project’s success and identify the lessons learnt.
A carefully structured project closure phase should ensure that the project
is brought to a controlled end. The project manager should prepare the end project
report, which details the main findings and outcome of the project and represents
a formal review of the project’s degree of success. The project manager should
organize the project closure meeting and draw up a list of who should attend. This
meeting is concerned with reviewing the project and ensuring the completeness of
all major project deliverables. It is the final formal control point, apart from the
post-implementation review; and should be attended by the project owner and
overall project manager. The basic question facing the attendees is: ‘Did the project
deliver its intended end-product within the time and budgetary limits set?’
Role of Closure Analysis
The objective of the post-mortem or the closure analysis is to determine what
went wrong, what went right, what worked, what did not and how it could be
made better the next time. Relevant information should be collected from the project
particularly for future use. The purpose is to make identified completion analysis
rather than just saying that the project is done. This exercise improves an organization
by leveraging the lesson learnt in the project.

Self-Instructional
330 Material
Performing Closure Analysis Project Closure

Project closure analysis is the key to learning from the past to provide future
improvements. To achieve this goal, it must be done carefully in an atmosphere of
safety so that lessons can be captured and used to improve the process and future NOTES
projects. Before we describe the details of the closure analysis report, we briefly
discuss the role of closure analysis and its implementation.
The data obtained during closure analysis is used to populate the Process
Database (PDB). The data from the PDB can be used directly by subsequent
projects for planning purposes. This information is also used in computing the
process capability, which is used by projects in planning and analysing trends. The
following Figure 14.1 illustrates the role of closure analysis.

Process Database
(PDB)

Closure Analysis Process Capability

Baseline

Project

Fig. 14.1 Role of Closure Analysis in a Project

Closure Analysis Report

The project manager should present the end project report to the project owner
at the project closure meeting. The project owner will need to study this report in
detail and should ensure that the project has successfully delivered its objectives,
as detailed in the project initiation document, before they formally close the project.
The project owner should schedule a future review of the overall outcome of the
project. This post-implementation review is an analysis of the operational
effectiveness of the project’s end-product some time, typically six months, after it
has been delivered. This process enables valuable lessons to be learned and applied
to future project-based work.

Self-Instructional
Material 331
Project Closure
14.3 INFOSYS PROJECT CLOSURE ANALYSIS
REPORT

NOTES Project management refers to discipline of planning, organizing, securing, managing,

leading, and controlling resources to achieve specific goals. A project is a temporary
endeavor with a defined beginning and end (usually time-constrained, and often
constrained by funding or deliverables), undertaken to meet unique goals and
objectives, typically to bring about beneficial change or added value. The temporary
nature of projects stands in contrast with ongoing business operations.
The Infosys Company is a software development company that has an
enviable track record of project execution. The project managers at Infosys use
the specific processes to successfully execute approximately 500 projects for
customers. The aspects of Infosys project management include planning,
execution, and closure. At Infosys the project managers estimate the project
cost, plan for managing risks, collect metrics data, set quality goals, use
measurements for monitoring a project, and so on.
Infosys has been assessed at Level 5 (the highest level) of the Capability
Maturity Model (CMM). By extracting project management processes from the
set of processes at Infosys, it can be illustrated that how projects are managed in
a high-maturity organization.
Processes and Project Management
A software project has two main activity dimensions: engineering and project
management. The engineering dimension deals with building the system and focuses
on issues, such as how to design, test, code, etc. The project management dimension
deals with properly planning and controlling the engineering activities to meet project
goals for cost, schedule, and quality.
If a project is small (say, a team of one or two working for a few weeks), it
can be executed somewhat informally. The project plan may be an e-mail specifying
the delivery date and perhaps a few intermediate milestones. Requirements might
be communicated in a note or even verbally, and intermediate work products,
such as design documents, might be scribbles on personal note pads.
These informal techniques, however, do not scale up for larger projects in
which many people may work for many months—the situation for most commercial
software projects. In such projects, each engineering task must be done carefully
by following well-tried methodologies, and the work products must be properly
documented to be reviewed later. The tasks in the project must be carefully planned
and allocated to project personnel and then tracked as the project executes. In
other words, to successfully execute larger projects, formality and rigor along
these two dimensions must increase.

Self-Instructional
332 Material
 Formality requires that well-defined processes be used for performing the Project Closure

various tasks so that the outcome becomes more dependent on the capability of
the processes. Formality is further enhanced if quantitative approaches are
employed in the processes through the use of suitable metrics.
NOTES
What is a Process?
Technically, a process for a task comprises a sequence of steps that should be
followed to execute the task. For an organization, however, the processes it
recommends for use by its engineers and project managers are much more than a
sequence of steps; they encapsulate what the engineers and project managers
have learned about successfully executing projects. Through the processes, the
benefits of experience are conferred to everyone, including newcomers in the
organization. These processes help managers and engineers emulate past successes
and avoid the consequences that lead to failures.
For a project, the engineering processes generally specify how to perform
engineering activities, such as requirement specification, design, testing, etc. The
project management processes specify how to set milestones, organize personnel,
manage risks, monitor progress, and so on.
In response to the question “Why should project managers follow
processes?” S.D. Shibulal — founder, director, and the head of customer delivery
at Infosys — sums it up using the following key points:
 Processes represent collective knowledge. Using the appropriate process
increases the chances of success.
 A process may have some extra steps, but it is not known beforehand
which ones are not needed, and hence it will increase the risks by taking
shortcuts.
 Without processes, one cannot predict much about the outcome of the
project.
 In the organization one cannot learn effectively without having defined
processes. Learning and improvement are imperative in today’s
knowledge-based world.
 Processes lower the anxiety level. The checklists inevitably cover 80
percent of what needs to be done. Hence, the continuing working task
reduces to remaining 20 percent.
Project Management at Infosys
Infosys executes hundreds of projects each year. Full responsibility for executing
a project rests with the project manager, who must make sure that the project
team delivers high-quality software to the customer on time and within cost. To
help the project manager fulfill this responsibility, support from the organization is
necessary.

Self-Instructional
Material 333
Project Closure Infosys is a software house headquartered in Bangalore, India. The stated
mission is “To be a globally respected corporation that provides best-of-
breed software solutions delivered by best-in-class people”. It employs the
global delivery model, in which the customer can be located anywhere in the
NOTES world and customer fulfillment can be provided from anywhere. In this model, the
customer is sought anywhere in the world where it provides the most value to the
company. For customer fulfillment, a combination of processes, technology, and
management is employed to segregate the work so that value can be added in the
most optimum locations and then re-aggregated for delivery to the customer.
Infosys is a highly respected company that has been rated as the best
managed and most respected company in India and one of Asia’s leading
Information Technology (IT) companies. It has bagged many awards, including
the Ramakrishna Bajaj award, which is modeled after the Malcolm Balridge award.
It can be safely said that Infosys is one of the best software services corporations
in the world.
Infosys provides a top-notch infrastructure so that its project managers can
better serve the needs of its worldwide customers. The company has provided
audio conferencing facilities to almost every group so that project managers can
interact easily with customers and with group members located in different sites.
Process orientation and improvement are a part of the Infosys work culture,
and processes are defined for most tasks that are performed regularly. For process
definition and improvement, Infosys first adopted the ISO 9000 framework and
got its ISO certification in 1993. To further improve the software process, Infosys
then adopted the CMM framework. It was first assessed at Level 4 in December
1997, and then at Level 5 in December 1999. In its pursuit of continuous
improvement, Infosys now employs the Malcolm Balridge framework for all-around
improvement and building leadership excellence in all areas of operation.
SEPG Support to Projects
The quality department at Infosys contains the Software Engineering Process Group
(SEPG). The SEPG is responsible for coordinating all the process activities,
including process definition, process improvement, and process deployment. It
also manages all information and data related to the use of processes (such as, the
process database and the process capability baseline). The SEPG helps to ensure
that the defined processes are implemented and become standard practice.
In addition, the SEPG provides a member who is associated with a project
as a software quality adviser. The quality adviser assists in defining and following
processes, ensures that the processes are followed, aids in analysing the data, and
provides any needed process training.

Self-Instructional
334 Material
The Project Management Process Project Closure

For a project team to successfully execute a project, it must perform hundreds of

tasks, many of them interdependent. Effectively managing this process is extremely
important for success. At Infosys, the set of activities executed by a project manager
NOTES
is specified in the project management process. It has the following three main
stages:
 Project Planning
 Project Execution
 Project Closure
In the project planning stage, the project manager reviews contractual
commitments and creates a plan to meet them. Creating a project plan involves
defining a life-cycle process to be followed, estimating the effort and schedule,
preparing a detailed schedule of tasks, and so on. It also includes planning for
quality and configuration management as well as risk management.
The second phase, project execution, involves executing the project plan,
tracking the status of the project, and making corrections whenever project
performance strays from the path laid down in the project plan. In other words, it
involves tracking and controlling the implementation of the project process. This
phase is the longest in the project management process, incorporating periodic
tasks, such as monitoring project status and quality and taking any needed corrective
steps.
The last stage of the project management process, project closure, involves
a systematic wind-up of the project after customer acceptance. The main goal
here is to learn from the experience so that the process can be improved. Post-
project data analysis constitutes the main activity; metrics are analysed, process
assets (materials, such as templates and guidelines, used to aid in managing the
process itself) are collected for future use, and lessons are recorded.

14.4 ACIC CLOSURE ANALYSIS REPORT

ACIC Corporation is a multibillion-dollar financial institution. Because Infosys

had successfully built some e-services for ACIC earlier in a project called Synergy,
ACIC employed Infosys to analyze the problem. The work was executed in Time
and Material (T&M) mode, i.e., the customer paid for the effort spent by Infosys
in doing the analysis. Based on the analysis output, Infosys made a successful bid
for the Web project, giving rise to the ACIC case study. The project successfully
released the new service in time, and the software has been in operation without
any problem.

Self-Instructional
Material 335
Project Closure The ACIC project illustrates the various project planning and monitoring
tasks undertaken in executing a project at Infosys. The outputs related to
management of the ACIC project include the following:
 The data from the Synergy project used by the ACIC project manager
NOTES
during planning.
 The project’s process plan.
 An analysis of the impact of a requirement change request.
 Effort estimates and the high-level schedule along with a description of
how they were obtained.
 The quality plan containing quality goals and plans for achieving them,
including plans for defect prevention and reviews.
 The risk management plan describing the major risks, their risk exposure
and impact, their prioritization, and the risk mitigation plans for the high-
priority risks.
 The measurement and tracking plan.
 The complete project management plan, including the team management
plan and the customer communication and escalation plan.
 The complete configuration management plan.
 Project tracking documents, including the defect log, the issues log, the
status report, and the milestone report.
 Details of defect prevention, including defect analysis results and the
impact on the project of the defect prevention plan.
 The complete closure report, which includes the metrics data on quality,
productivity, cost of quality, defect removal efficiency, and so on.

Check Your Progress

1. Define project closure phase.
2. What is project closure analysis?
3. What does project management refers to?
4. Explain about the Infosys Company.

14.5 ANSWERS TO CHECK YOUR PROGRESS

QUESTIONS

1. The project closure phase is the last phase in the project life cycle. In this
phase, we formally close a project and then report its overall level of success
to the sponsor. Project closure involves handing over the deliverables to
the customer, passing the documentation to the business, cancelling supplier
Self-Instructional contracts, releasing staff and equipment, and informing stakeholders of the
336 Material
 closure of the project. After a project has been closed, a post implementation Project Closure

review is completed to determine the project’s success and identify the

lessons learnt.
2. Project closure analysis is the key to learning from the past to provide
NOTES
future improvements. To achieve this goal, it must be done carefully in an
atmosphere of safety so that lessons can be captured and used to improve
the process and future projects. The data obtained during closure analysis
is used to populate the Process DataBase (PDB). The data from the PDB
can be used directly by subsequent projects for planning purposes. This
information is also used in computing the process capability, which is used
by projects in planning and analysing trends.
3. Project management refers to discipline of planning, organizing, securing,
managing, leading, and controlling resources to achieve specific goals.
4. The Infosys Company is a software development company that has an
enviable track record of project execution. The project managers at Infosys
use the specific processes to successfully execute approximately 500 projects
for customers. The aspects of Infosys project management include planning,
execution, and closure. At Infosys the project managers estimate the project
cost, plan for managing risks, collect metrics data, set quality goals, use
measurements for monitoring a project, and so on.
Infosys has been assessed at Level 5 (the highest level) of the Capability
Maturity Model (CMM). By extracting project management processes from
the set of processes at Infosys, it can be illustrated that how projects are
managed in a high-maturity organization.

14.6 SUMMARY

 The project closure phase is the last phase in the project life cycle. In this
phase, we formally close a project and then report its overall level of success
to the sponsor.
 Project closure involves handing over the deliverables to the customer,
passing the documentation to the business, cancelling supplier contracts,
releasing staff and equipment, and informing stakeholders of the closure of
the project.
 After a project has been closed, a post implementation review is completed
to determine the project’s success and identify the lessons learnt.
 A carefully structured project closure phase should ensure that the project
is brought to a controlled end.
 The project manager should prepare the end project report, which details
the main findings and outcome of the project and represents a formal review
of the project’s degree of success.
Self-Instructional
Material 337
Project Closure  Project closure analysis is the key to learning from the past to provide
future improvements. To achieve this goal, it must be done carefully in an
atmosphere of safety so that lessons can be captured and used to improve
the process and future projects.
NOTES
 The data obtained during closure analysis is used to populate the Process
DataBase (PDB). The data from the PDB can be used directly by subsequent
projects for planning purposes. This information is also used in computing
the process capability, which is used by projects in planning and analysing
trends.
 Project management refers to discipline of planning, organizing, securing,
managing, leading, and controlling resources to achieve specific goals.
 A project is a temporary endeavor with a defined beginning and end (usually
time-constrained, and often constrained by funding or deliverables),
undertaken to meet unique goals and objectives, typically to bring about
beneficial change or added value.
 The Infosys Company is a software development company that has an
enviable track record of project execution. The project managers at Infosys
use the specific processes to successfully execute approximately 500 projects
for customers.
 The aspects of Infosys project management include planning, execution,
and closure. At Infosys the project managers estimate the project cost,
plan for managing risks, collect metrics data, set quality goals, use
measurements for monitoring a project, and so on.
 Infosys has been assessed at Level 5 (the highest level) of the Capability
Maturity Model (CMM).
 By extracting project management processes from the set of processes at
Infosys, it can be illustrated that how projects are managed in a high-maturity
organization.
 A software project has two main activity dimensions: engineering and project
management.
 The engineering dimension deals with building the system and focuses on
issues, such as how to design, test, code, etc.
 The project management dimension deals with properly planning and
controlling the engineering activities to meet project goals for cost, schedule,
and quality.
 The quality department at Infosys contains the Software Engineering Process
Group (SEPG).
 The SEPG is responsible for coordinating all the process activities, including
process definition, process improvement, and process deployment. It also
manages all information and data related to the use of processes (such as,
Self-Instructional the process database and the process capability baseline).
338 Material
  The SEPG helps to ensure that the defined processes are implemented and Project Closure

become standard practice.

 ACIC Corporation is a multibillion-dollar financial institution. Because
Infosys had successfully built some e-services for ACIC earlier in a project
NOTES
called Synergy, ACIC employed Infosys to analyse the problem.
 The work was executed in Time and Material (T&M) mode, i.e., the customer
paid for the effort spent by Infosys in doing the analysis. Based on the
analysis output, Infosys made a successful bid for the Web project, giving
rise to the ACIC case study. The project successfully released the new
service in time, and the software has been in operation without any problem.

14.7 KEY WORDS

 Project closure phase: The project closure phase is the last phase in the
project life cycle. Project closure involves handing over the deliverables to
the customer, passing the documentation to the business, cancelling supplier
contracts, releasing staff and equipment, and informing stakeholders of the
closure of the project.
 Project closure analysis: Project closure analysis is the key to learning
from the past to provide future improvements. The data obtained during
closure analysis is used to populate the Process DataBase (PDB). The
data from the PDB can be used directly by subsequent projects for planning
purposes.
 Project management: Project management refers to discipline of planning,
organizing, securing, managing, leading, and controlling resources to achieve
specific goals.
 Project: A project is a temporary endeavor with a defined beginning and
end (usually time-constrained, and often constrained by funding or
deliverables), undertaken to meet unique goals and objectives, typically to
bring about beneficial change or added value.
 Infosys Company: The Infosys Company is a software development
company that has an enviable track record of project execution. The project
managers at Infosys use the specific processes to successfully execute
approximately 500 projects for customers. Infosys has been assessed at
Level 5 (the highest level) of the Capability Maturity Model (CMM).

14.8 SELF ASSESSMENT QUESTIONS AND

EXERCISES

Short-Answer Questions
1. What is project closure? Self-Instructional
Material 339
Project Closure 2. Define the term project closure analysis.
3. Why Software Engineering Process Group (SEPG) is used?
4. How Infosys analyses the project closure report?
NOTES 5. Who has built some e-services for ACIC?
Long-Answer Questions
1. Briefly discuss the significant properties of project closure.
2. Explain about the project closure analysis giving examples.
3. Elaborate on the project management process at Infosys.
4. At Infosys how project closure report is analysed?
5. Define the concept of ACIC project closure analysis report.

14.9 FURTHER READINGS

Hughes, Bob, Mike Cotterell and Rajib Mall. 2017. Software Project
Management (SIE), 6th Edition. New York: McGraw Hill Education.
Schach, Stephen R. 2005. Object Oriented and Classical Software Engineering.
New Delhi: Tata McGraw-Hill.
Pressman, Roger S. 1997. Software Engineering, a Practitioner’s Approach.
New Delhi: Tata McGraw-Hill.
Somerville, Ian. 2001. Software Engineering. New Delhi: Pearson Education.
Ghezzi, Carlo, Mehdi Jazayeri, and Dino Mandriolli. 1991. Fundamentals of
Software Engineering. New Delhi: Prentice-Hill of India.
Jawadekar, Waman S. 2004. Software Engineering: Principles and Practice.
New Delhi: Tata McGraw-Hill.
Jalote, Pankaj. 1991. An Integrated Approach to Software Engineering. New
Delhi: Narosa Publishing House.

Self-Instructional
340 Material