Karnataka State Open University

Mukthagangothri, Mysore – 570 006.

Dept. of Studies and Research in Management

MBA IT Specialization
IV Semester
MBSC-4.1G Software Project Management

Block 1
 PREFACE

Computer software has become a driving force. It is the engine that drives business
decision making. It serves as the basis for modern scientific investigation and engineering
problem solving. It is a key factor that differentiates modern products and services. It is
embedded in systems of all kinds: transportation, medical, telecommunications, military,
industrial processes, entertainment, office products, . . . the list is almost endless. Software is
virtually inescapable in a modern world. And as we move into the twenty-first century, it will
become the driver for new advances in everything from elementary education to genetic
engineering.

When a computer software succeeds—when it meets the needs of the people who use
it, when it performs flawlessly over a long period of time, when it is easy to modify and even
easier to use—it can and does change things for the better. But when software fails—when its
users are dissatisfied, when it is error prone, when it is difficult to change and even harder to
use—bad things can and do happen. We all want to build software that makes things better,
avoiding the bad things that lurk in the shadow of failed efforts. To succeed, we need
discipline when software is designed and built. We need an engineering approach.

The whole material is organized into four modules each with four units. Each unit
lists the objectives of the study along with the relevant questions, illustrations and suggested
reading to better understand the concepts.

Wish you happy reading!!!

 KARNATAKA STATE OPEN UNIVERSITY
MUKTHAGANGOTRI, MYSURU-06
Dept. of Studies and Research in Management

MBA IT
IV SEMESTER
SOFTWARE PROJECT MANAGEMENT (4 Credits)

BLOCK 1:
UNIT-1: INTRODUCTION TO PROJECT MANAGEMENT 1-19
UNIT-2: TECHNOLOGY CONTEXT 20-40
UNIT-3: SOFTWARE PROJECT MANAGEMENT CONCEPTS 41-68
UNIT-4: SOFTWARE QUALITY MANAGEMENT 69-84
BLOCK 1 INTRODUCTION

A project is a group of tasks that need to complete to reach a clear result. A project also
defines as a set of inputs and outputs which are required to achieve a goal. Projects can
vary from simple to difficult and can be operated by one person or a hundred.

Software project management is an art and discipline of planning and supervising

software projects. It is a sub-discipline in which software projects are planned,
implemented, monitored and controlled.

Software is a non-physical product. Software development is a new stream in business

and there is very little experience in building software products. Most of the software
products are made to fit clients’ requirements. The most important is that the basic
technology changes and advances so frequently and rapidly that experience of one
product may not be applied to the other one. Such type of business and environmental
constraints increase risk in software development hence it is essential to manage software
projects efficiently. It is necessary for an organization to deliver quality products, keep the
cost within the client’s budget constrain and deliver the project as per schedule. Hence in
order, software project management is necessary to incorporate user requirements along
with budget and time constraints.

This block consists of four units and is organized as follows:

Unit 1 speaks about the past and the present Software Project Management methodology
and their pros and cons, the different phases and the process models of Software Projects.

Unit 2 focuses on the context of Information Technology in Software Projects.

Unit 3 emphasises on the major parameters of Software Project Management like People,
Product, Process, the Software Configuration Management and Testing Strategies.

Unit 4 highlights the Quality Management concepts in Software Project Management.

The different concepts, review techniques and quality assurance are underlined in this
unit.
UNIT-1: INTRODUCTION TO PROJECT MANAGEMENT

STRUCTURE

1.0 Objectives
1.1 Introduction
1.2 Introduction to project management
1.3 Project Management: Past and Present
1.4 Project Management Overview
1.3.1 Project Characteristics
1.3.2 Project Deadlines and Penalties
1.3.3 Project Budgets
1.3.4 Project Risk Register
1.3.5 Project Management Definition
1.3.6 Project Quality and Standards
1.5 Software Project vs Other Types
1.6 Software Project Lifecycle (Phases)
1.5.1 Requirement Collection
1.5.2 Feasibility Study
1.5.3 Design
1.5.4 Coding
1.5.5 Testing
1.5.6 Installation
1.5.7 Maintenance
1.7 Software Process Models
1.7.1 Waterfall Model
1.7.2 V Model
1.7.3 Incremental Model
1.7.4 Iterative Model
1.7.5 RAD Model
1.7.6 Spiral Model
1.7.7 Agile Model
1.8 Check your progress
1.9 Summary
1.10 Keywords

1
1.11 Questions for self-study
1.12 References

1.0 OBJECTIVES

After studying this unit, you will be able to:

 Understand the process and the need of SPM
 Explain the difference between the past and present system
 Recognize the different phases of project life cycle
 Discuss various Software Process Models

1.1 INTRODUCTION

In this unit, we are going to discuss about project management. Initially, past and the
present Software Project Management methodology and their pros and cons are discussed.
Further, conventional management types, the different phases and the process models of
Software Projects are discussed in detail.

1.2 INTRODUCTION TO PROJECT MODEL

Project management is the discipline of defining and achieving project goals while
optimizing for any resource constraints during the lifecycle of a project.
A subset of project management, Software Project Management is the practice of planning
and delivering software development projects within variables such as:
 Time
 Quality
 Cost
 The wider scope
Before getting into the process of Project Management, one has to be clearly aware of
Software Projects. A project is well-defined task, which is a collection of several operations
done in order to achieve a goal (for example, software development and delivery). A Project
can be characterized as:
Regardless, every project must have the following components:

 Goal: What are you trying to achieve?

 Timeline: When are you trying to achieve it by?

2
  Budget: How much will it cost to achieve?
 Stakeholders: Who are the major players who have an interest in this project?
 Project manager: Who is going to make sure everything that needs to be completed
gets completed?
A project is not something routine. Day-to-day operations or maintenance is not considered a
project because it does not have a definitive start and end.
Project management is the practice of applying knowledge, skills, tools, and techniques to
complete a project according to specific requirements. Understanding project management
comes down to identifying the problem, creating a plan to solve the problem, and then
executing on that plan until the problem has been solved. That may sound simple, but there is
a lot that goes into it at every stage of the process.

1.3 PROJECT MANAGEMENT: PAST AND PRESENT

Project management, as an idea, goes back a very long way. Thinking about all of the
things that have been built in the history of civilization, there are thousands of years of
project experience to learn from. A dotted line can be drawn from the software developers of
today back through time to the builders of the Egyptian pyramids or the architects of the
Roman aqueducts. For their respective eras, project managers have played similar roles,
applying technology to the relevant problems of the times. Yet today, when most people try
to improve how their web and software development projects are managed, it’s rare that they
pay attention to lessons learned from the past. The timeline we use as the scope for useful
knowledge is much closer to present day than it should be.

Four Periods in the Development of Modern Project Management

[1] Prior to 1958: Craft system to human relations. During this time, the evolution of
technology, such as, automobiles and telecommunications shortened the project schedule. For
instance, automobiles allowed effective resource allocation and mobility, whilst the
telecommunication system increased the speed of communication. Furthermore, the job
specification which later became the basis of developing the Work Breakdown Structure
(WBS) was widely used and Henry Gantt invented the Gantt chart. Examples of projects
undertaken during this period as supported by documented evidence include: (a) Building the
Pacific Railroad in 1850s; (b) Construction of the Hoover Dam in 1931-1936, that employed
approximately 5,200 workers and is still one of the highest gravity dams in the U.S.
generating about four billion kilowatt hours a year; and (c) The Manhattan Project in 1942-
3
1945 that was the pioneer research and development project for producing the atomic bomb,
involving 125,000 workers and costing nearly $2 billion.

[2] 1958-1979: Application of Management Science. Significant technology advancement

took place between 1958 and 1979, such as, the first automatic plain-paper copier by Xerox
in 1959. Between 1956 and 1958 several core project management tools including CPM and
PERT were introduced. However, this period was characterised by the rapid development of
computer technology. The progression from the mainframe to the mini-computer in the 1970s
made computers affordable to medium size companies. In 1975, Bill Gates and Paul Allen
founded Microsoft. Furthermore, the evolution of computer technology facilitated the
emergence of several project management software companies, including, Artemis (1977),
Oracle (1977), and Scitor Corporation (1979). In the 1970s other project management tools
such as Material Requirements Planning (MRP) were also introduced.

[3] 1980-1994: Production Centre Human Resources. The 1980s and 1990s are characterised
by the revolutionary development in the information management sector with the
introduction of the personal computer (PC) and associated computer communications
networking facilities. This development resulted in having low cost multitasking PCs that had
high efficiency in managing and controlling complex project schedules. During this period
low cost project management software for PCs became widely available that made project
management techniques more easily accessible.

[4] 1995-Present: Creating a New Environment. This period is dominated by the

developments related to the Internet that changed dramatically business practices in the mid
1990s. The Internet has provided fast, interactive, and customised new medium that allows
people to browse, purchase, and track products and services online instantly. This has
resulted in making firms more productive, more efficient, and more client oriented.
Furthermore, many of today's project management software have an Internet connectivity
feature. This allows automatic uploading of data so that anyone around the globe with a
standard browser can: (a) input the most recent status of their assigned tasks; (b) find out how
the overall project is doing; (c) be informed of any delays or advances in the schedule; and
(d) stay "in the loop" for their project role, while working independently at a remote site.

Current and Emergent Practices in Project Management

Between 2010 and 2020, we expanded our understanding of project management. PM's field
is diffuse and multi-disciplinary and offers a considerable body of literature in related areas

4
like agile project management, strategy execution, business analysis, and more. There are
various methods and frameworks, and we realized that we could build our hybrid methods.
But how?

Figure 1.1 – Disciplined agile toolkit (PMI)

Disciplined Agile (Figure 1.2) is a toolkit to help people and organizations to fully and truly
become agile by combining different execution approaches, including serial and agile, to the
other business processes in an integrated fashion. Describing DA in detail is beyond this
article's scope, but that leads us to "What's next?"

1.4 PROJECT MANAGEMENT OVERVIEW

Project management is the use of specific knowledge, skills, tools and techniques to
deliver something of value to people. The development of software for an improved business
process, the construction of a building, the relief effort after a natural disaster, the expansion
of sales into a new geographic market—these are all examples of projects.

5
All projects are a temporary effort to create value through a unique product, service or result.
All projects have a beginning and an end. They have a team, a budget, a schedule and a set of
expectations the team needs to meet. Each project is unique and differs from routine
operations—the ongoing activities of an organization—because projects reach a conclusion
once the goal is achieved.

The changing nature of work due to technological advances, globalization and other factors
means that, increasingly, work is organized around projects with teams being brought
together based on the skills needed for specific tasks.

Leading these projects are Project Professionals—people who either intentionally or by

circumstance are asked to ensure that a project team meets its goals. Project professionals use
many different tools, techniques and approaches to meet the needs of a project.

Some projects are needed to quickly resolve problems, with an understanding that
improvements will be made over a period of time. Other projects have a longer duration
and/or produce a product or other outcome that will not need major improvements outside of
projected maintenance, such as a highway.

Still others will be a mix of both of these types of projects. Project professionals use a variety
of skills and knowledge to engage and motivate others to reach a project’s goals. Project
professionals are critical to the success of projects and are highly sought after to help
organizations achieve their goals.

1.4.1 PROJECT CHARACTERISTICS

When considering whether or not you have a project on your hands, there are some things to
keep in mind. First, is it a project or an ongoing operation? Second, if it is a project, who are
the stakeholders? And third, what characteristics distinguish this endeavor as a project?

Projects have several characteristics:

 Projects are unique.

 Projects are temporary in nature.
 Projects have a definite beginning and ending date.
 Projects are completed when the project goals are achieved or it’s determined the
project is no longer viable.

A successful project is one that meets or exceeds the expectations of the stakeholders.

6
Project Management is not about managing people alone. Project management can be divided
into different process groups and knowledge areas. Process groups include initiating,
planning, executing, monitoring and controlling, and closing. Knowledge areas include
integration, scope, time cost, quality, human resources, communication, risk, procurement
and stakeholder management.

Figure 1.2 – Project Management Essentials

1.4.2 PROJECT DEADLINES AND PENALTIES

Often projects need to be completed by a set date and there is no leeway for example the
tasks for the birthday party will need to be completed by the day of the birthday. Other
projects may incur penalties if they are not completed on time for example the costs of flights
will increase as you get closer to the date of the flight.

1.4.3 PROJECT BUDGETS

The majority of projects have a budget for completing the project tasks. Using the decorating
a house example, there are many ways to decorate a house; some options will be more
expensive than others. Your final choice of décor will depend on how much money you have
to buy paint, wallpaper, tools etc.

1.4.4 PROJECT RISK REGISTER

A risk register contains a list of things which may hinder the project. The purpose of the risk
register is to identify which risks need to be actively managed in order to
1. Prevent the risk occurring and/or
2. To minimise the impact of a risk if its occurrence can't be prevented.

7
As the list of project risks could be quite long the project team may decide that it is
impractical to try and manage all of the risks; instead they may focus their attention on the
risks that are most likely to occur and the ones that will have the greatest impact on the
project.

1.4.5 PROJECT MANAGEMENT DEFINITION

In each of our examples there are:

1. A number of tasks to complete

2. A date by which the tasks need to be completed
3. A budget within which the project needs to be completed
Bearing each of these requirements in mind let’s define project management. Project
management is about ensuring that the tasks of a project are completed on time and within
budget.

1.4.6 PROJECT QUALITY AND STANDARDS

The standard to which the tasks are completed is very important, otherwise the project may
cause more problems than benefits. For example a badly decorated house will need to be
redecorated and a holiday that people do not enjoy will cause people stress and not relaxation.

There are a number of ways to manage a project but each method should state who is
responsible for each task and set a deadline for the completion of the task. The project
manager should regularly review how each task is progressing and take action if it is not on
track for completion by the deadline.

1.5 SOFTWARE PROJECT VS OTHER TYPES

Invisibility: When a physical artifact such as a bridge is constructed the progress can actually
be seen. With software, progress is not immediately visible. Software project management
can be the process of making the invisible visible.

Complexity: Per dollar, pound or euro spent, software products contain more complexity than
other engineered artifacts.

Conformity: The 'traditional' engineer usually works with physical systems and materials like
cement and steel. These physical systems have complexity, but are governed by consistent
physical laws. Software developers have to conform to the requirement of human clients. It is

8
not just that individuals can be inconsistent. Organizations, because of lapses in collective
memory, in internal communication or in effective decision making, can exhibit remarkable,
‘organizational-stupidity'.

Flexibility: That software is easy to change is seen as a strength. However, where the
software system interfaces with a physical or organizational system, it is accommodate the
other components rather than vice versa. Thus software systems are particularly subject to
change.

1.6 SOFTWARE PROJECT LIFECYCLE (PHASES)

With all the complex processes involved in software development, it’s easy to forget
the fundamental process for a successful software development life cycle (SDLC). The
SDLC process includes planning, designing, developing, testing and deploying with ongoing
maintenance to create and manage applications efficiently. When faced with the task of
producing high-quality software that meets a client’s expectations, requirements, time-frame,
and cost estimations; understanding the SDLC is crucial.

“SDLC methodologies” are used to create complex applications of varying sizes and scales,
such as Agile, Waterfall and Spiral. Each model follows a particular life cycle in order to
ensure success in the process of software development

1.6.1 Requirement Collection: - The first phase of the software development life cycle
process is requirement collection, where a business analyst will collect the business
needs of the customer in the form of requirement documents and planning for the
quality assurance requirements.
This stage gives a clear picture of the scope of the entire project and the anticipated
issues, opportunities, and directives, which triggered the project and need teams to get
detailed and precise requirements. It will help companies to finalize the necessary
timeline to finish the work of that system.
1.6.2 Feasibility Study: - In the second stage of the software development life cycle, based
on the requirements, a set of people sit and analysis if the project is Doable or not
Doable, which means that organization has enough resource, cost, time so that they
can deliver the product on time with the high -quality product. We can check the
feasibility in a different manner, i.e., Economic, Legal, Operation, feasibility,
Technical, Schedule.

9
1.6.3 Design: - In the third stage of the software development life cycle, once the feasibility
is done, prepare a blueprint of the application. The blueprint has flow charts, flow
diagrams, and decision tree and user interface components.

The Designer will design the document in two ways:

HLD (High-Level Design): In HLD, we have a brief description, name of each module,
interface relationship, dependencies between modules, database tables, and complete
architecture diagrams

LLD (Low-Level Design): In LLD, we have functional logic of the modules, Database
tables, which include type and size, pointing all kinds of dependency issues and listing of
error messages

1.6.4 Coding: - The fourth stage of the software development life cycle is coding, after the
complication of requirements and designing phase, the developer starts writing code
using the particular program language and, the developer needs to follow specific
predefined coding guidelines and used programming tools like compiler, interpreters,
debugger to generate and implement the code. Coding is the time taking process of
the Software Development Life Cycle process
1.6.5 Testing: - In the testing phase ofthe software development life cycle, once the coding
is completed, the application is handed over to the test engineers where they start
checking the functionality of an application according to the requirement. During the
testing process, we may encounter some bugs which need to be fixed by developers
and retested by the test engineers.
1.6.6 Installation: - In the installation phase, the process will continue until the application
is bug-free/ stable/ and works according to customer needs. The stable application is
handed over to the customer in the form of installation or deploying or rolls out.
1.6.7 Maintenance: - The last phase of software development life cycle, when a customer
starts using the software they may place some issues which need to be in-detail tested
& fixed and handover back to the customer and bug fixes, up-gradation, enhancement
is done under maintenance phase.
“All this phase is essential to make a good quality product or an application. Without
completion of any phase, it might not deliver a good quality product because all the phases
are connected.”

10
 Figure 1.3: Phases of Software Development Life Cycle

1.7 SOFTWARE PROCESS MODELS

Software Processes is a coherent set of activities for specifying, designing,

implementing and testing software systems. A software process model is an abstract
representation of a process that presents a description of a process from some particular
perspective. There are many different software processes but all involve:

 Specification – defining what the system should do;

 Design and implementation – defining the organization of the system and
implementing the system;
 Validation – checking that it does what the customer wants;
 Evolution – changing the system in response to changing customer needs.

11
Types of Software Process Model

Software processes, methodologies and frameworks range from specific prescriptive steps
that can be used directly by an organization in day-to-day work, to flexible frameworks that
an organization uses to generate a custom set of steps tailored to the needs of a specific
project or group. In some cases a “sponsor” or “maintenance” organization distributes an
official set of documents that describe the process.

Software Process and Software Development Lifecycle Model

One of the basic notions of the software development process is SDLC models which stands
for Software Development Life Cycle models. There are many development life cycle models
that have been developed in order to achieve different required objectives. The models
specify the various stages of the process and the order in which they are carried out. The most
used, popular and important SDLC models are given below:

 Waterfall model
 V model
 Incremental model
 RAD model
 Agile model
 Iterative model
 Spiral model
 Prototype model

1.7.1 WATERFALL MODEL

The waterfall model is a breakdown of project activities into linear sequential phases, where
each phase depends on the deliverables of the previous one and corresponds to a
specialisation of tasks. The approach is typical for certain areas of engineering design.

12
 Figure 1.4: Waterfall Model

1.7.2 V MODEL

The V-model represents a development process that may be considered an extension of the
waterfall model and is an example of the more general V-model. Instead of moving down in a
linear way, the process steps are bent upwards after the coding phase, to form the typical V
shape. The V-Model demonstrates the relationships between each phase of the development
life cycle and its associated phase of testing. The horizontal and vertical axes represent time
or project completeness (left-to-right) and level of abstraction (coarsest-grain abstraction
uppermost), respectively.

Figure 1.5: V Model

13
1.7.3 INCREMENTAL MODEL

The incremental build model is a method of software development where the model is
designed, implemented and tested incrementally (a little more is added each time) until the
product is finished. It involves both development and maintenance. The product is defined as
finished when it satisfies all of its requirements. Each iteration passes through the
requirements, design, coding and testing phases. And each subsequent release of the system
adds function to the previous release until all designed functionally has been implemented.
This model combines the elements of the waterfall model with the iterative philosophy of
prototyping.

Figure 1.6: Incremental Model

1.7.4 ITERATIVE MODEL

An iterative life cycle model does not attempt to start with a full specification of requirements
by first focusing on an initial, simplified set user features, which then progressively gains
more complexity and a broader set of features until the targeted system is complete. When
adopting the iterative approach, the philosophy of incremental development will also often be
used liberally and interchangeably.

In other words, the iterative approach begins by specifying and implementing just part of the
software, which can then be reviewed and prioritized in order to identify further
requirements. This iterative process is then repeated by delivering a new version of the
software for each iteration. In a light-weight iterative project the code may represent the
major source of documentation of the system; however, in a critical iterative project a formal
software specification may also be required.

14
 Figure 1.7: Iterative Model

1.7.5 RAD MODEL

Rapid application development was a response to plan-driven waterfall processes, developed

in the 1970s and 1980s, such as the Structured Systems Analysis and Design Method
(SSADM). Rapid application development (RAD) is often referred as the adaptive software
development. RAD is an incremental prototyping approach to software development that end
users can produce better feedback when examining a live system, as opposed to working
strictly with documentation. It puts less emphasis on planning and more emphasis on an
adaptive process.

RAD may resulted in a lower level of rejection when the application is placed into
production, but this success most often comes at the expense of a dramatic overruns in project
costs and schedule. RAD approach is especially well suited for developing software that is
driven by user interface requirements. Thus, some GUI builders are often called rapid
application development tools.

Figure 1.8: RAD Model

15
1.7.6 SPIRAL MODEL

The spiral model, first described by Barry Boehm in 1986, is a risk-driven software
development process model which was introduced for dealing with the shortcomings in the
traditional waterfall model. A spiral model looks like a spiral with many loops. The exact
number of loops of the spiral is unknown and can vary from project to project. This model
supports risk handling, and the project is delivered in loops. Each loop of the spiral is called a
Phase of the software development process.

The initial phase of the spiral model in the early stages of Waterfall Life Cycle that is needed
to develop a software product. The exact number of phases needed to develop the product can
be varied by the project manager depending upon the project risks. As the project manager
dynamically determines the number of phases, so the project manager has an important role
to develop a product using a spiral model.

Figure 1.9: Spiral Model

1.7.7 AGILE MODEL

Agile is an umbrella term for a set of methods and practices based on the values and
principles expressed in the Agile Manifesto that is a way of thinking that enables teams and
businesses to innovate, quickly respond to changing demand, while mitigating risk.
Organizations can be agile using many of the available frameworks available such as Scrum,
Kanban, Lean, Extreme Programming (XP) and etc.

16
 Figure 1.10: Agile Model

The Agile movement proposes alternatives to traditional project management. Agile

approaches are typically used in software development to help businesses respond to
unpredictability which refer to a group of software development methodologies based on
iterative development, where requirements and solutions evolve through collaboration
between self-organizing cross-functional teams.

The primary goal of being Agile is empowered the development team the ability to create and
respond to change in order to succeed in an uncertain and turbulent environment. Agile
software development approach is typically operated in rapid and small cycles. This results in
more frequent incremental releases with each release building on previous functionality.
Thorough testing is done to ensure that software quality is maintained.

Figure 1.11: Agile Method

17
1.8 CHECK YOUR PROGRESS

1. What is the objective of Software Project Management?

2. What is Software Process Model?
3. PM's field is diffuse and multi-disciplinary and offers a considerable body of literature in
related areas like --------------------, ----------------, ----------------, and more.
4. What is Conventional Software Management?
5. The exact number of phases needed to develop the product can be ----------- the project

Answers to check your progress:

1. Software project management focuses on developing a product that will have a positive
effect on an organization. Without project management, a software development team
may begin working on a project without any clear vision or guidance, resulting in more
frequent errors and confusion.
2. In software engineering, a software process model is the mechanism of dividing software
development work into distinct phases to improve design, product management, and
project management. It is also known as a software development life cycle.
3. like agile project management, strategy execution, business analysis
4. In the past, organizations used conventional software management. This management
utilized custom tools and process and virtually custom components built-in primitive
languages. Thus, the performance of the project was very much predictable in the
schedule, cost, and quality. It is a practically outdated technique and technology.
5. Varied

1.9 SUMMARY

In this Unit, past and the present Software Project Management methodology and their
pros and cons are discussed, conventional management types, the different phases and the process
models of Software Projects. Unit 2 focuses on the context of Information Technology in
Software Projects. Unit 3 emphasises on the major parameters of Software Project Management
like People, Product, Process, the Software Configuration Management and Testing Strategies.
Unit 4 highlights the Quality Management concepts in Software Project Management. The
different concepts, review techniques and quality assurance are underlined in this unit.

18
1.10 KEYWORDS

 Project: It is well-defined task, which is a collection of several operations done in order

to achieve a goal.
 Project management: It is the practice of applying knowledge, skills, tools, and
techniques to complete a project according to specific requirements.
 Coding: It is a computer programming language that helps to communicate with a
computer.
 Software maintenance: It is the process of changing, modifying, and updating software
to keep up with customer needs.
 Software Processes: It is a coherent set of activities for specifying, designing,
implementing and testing software systems.

1.11 QUESTIONS FOR SELF STUDY

1. The difference between the Project Management followed in the past and present.
2. Write an overview on the project management overview and its characteristics.
3. Describe the phases of Software Development Life Cycle.
4. Write the principles of Conventional and Current Software Management.
5. The difference and purpose of various software process models along with their diagrams.
6. What kind of evolution practices are followed in Software Economics?

1.12 REFERENCES

1. https://www.projectmanagement.com/
2. https://www.oreilly.com/
3. https://www.projectsmart.co.uk/
4. https://pressbooks.bccampus.ca/
5. https://www.pmi.org/
6. https://www.learnmanagement2.com/
7. https://www.tutorialandexample.com/
8. https://www.geeksforgeeks.org/
9. https://www.visual-paradigm.com/guide/software-development-process/what-is-a-
software-process-model/

19
UNIT-2: TECHNOLOGY CONTEXT

STRUCTURE

2.0 Objectives
2.1 Introduction
2.2 A System View of Project Management
2.3 Understanding Organizations
2.4 Stakeholder Management
2.5 Project Phases
2.6 The Context of Information Technology Projects
2.7 Recent Trends Affecting Information Technology Project Management
2.8 Check your progress
2.9 Summary
2.10 Key words
2.11 Questions for self-study
2.12 References

2.0 OBJECTIVES

After studying this unit, you will be able to:

 Understand the systems view of project management and how it applies to

information technology projects
 Analyze a formal organization using the structural, human resources, political, and
symbolic organizational frames
 Describe the differences among functional, matrix, and project organizational
structures
 Explain why stakeholder management and top management commitment are critical
for a project’s success
 Understand the concept, development, implementation, and close-out phases of the
project life cycle
 Distinguish between project development and product development
 Discuss the unique attributes and diverse nature of information technology projects
 List the skills and attributes of a good project manager in general and in the
information technology field

20
2.1 INTRODUCTION

In this unit, we are going to discuss about systems view of project management and
the application of Information Technology. The analysis helps the organization to provide the
perspectives of structural, hr and political frames. This also helps to understand the
conceptual, developmental, implementation and close-out phases of project life cycle. It also
provides the clarity between project and product development.

2.2 A SYSTEM VIEW OF PROJECT MANAGEMENT

Even though projects are temporary and intended to provide a unique product or
service, you cannot run projects in isolation. If project managers lead projects in isolation, it
is unlikely that they will ever truly serve the needs of the organization. Therefore, projects
must operate in a broad organizational environment, and project managers need to consider
projects within the greater organizational context. To handle complex situations effectively,
project managers need to take a holistic view of a project and understand how it relates to the
larger organization. Systems thinking describe this holistic view of carrying out projects
within the context of the organization.

The term systems approach emerged in the 1950s to describe a holistic and analytical
approach to solving complex problems that includes using a systems philosophy, systems
analysis, and systems management. Systems are sets of interacting components that work
within an environment to fulfil some purpose. For example, the human body is a system
composed of many subsystems, including the nervous system, the skeletal system, the
circulatory system, and the digestive system. Organizations are also systems, with people in
various roles working together to design, develop, deliver, and sell various products and
services. A systems philosophy is an overall model for thinking about things as systems.

Systems analysis is a problem-solving approach that requires defining the scope of the
system, dividing it into components, and then identifying and evaluating its problems,
opportunities, constraints, and needs. Once this is completed, the systems analyst then
examines alternative solutions for improving the current situation; identifies an optimum, or
at least satisfactory, solution or action plan; and examines that plan against the entire system.
Systems management addresses the business, technological, and organizational issues
associated with creating, maintaining, and modifying a system.

21
Using a systems approach is critical to successful project management. If top management
and project managers are to understand how projects relate to the whole organization, they
must follow a systems philosophy. They must use systems analysis to address needs with a
problem-solving approach. They must use systems management to identify key issues in
business, technological, and organizational spheres related to each project in order to identify
and satisfy key stakeholders and do what is best for the entire organization.

2.3 UNDERSTANDING ORGANIZATIONS

The systems approach requires that project managers always view their projects in the
context of the larger organization. Organizational issues are often the most difficult part of
working on and managing projects. In fact, many people believe that most projects fail
because of organizational issues like company politics. Project managers often do not spend
enough time identifying all the stakeholders involved in projects, especially the people
opposed to the projects. Also, project managers often do not spend enough time considering
the political context of a project or the culture of the organization. To improve the success
rate of IT projects, it is important for project managers to develop a better understanding of
people as well as organizations.

THE FOUR FRAMES OF ORGANIZATIONS

As shown in Figure 2.1, you can try to understand organizations better by focusing on
different perspectives. Organizations can be viewed as having four different frames:
structural, human resources, political, and symbolic.1

 The structural frame deals with how the organization is structured (usually depicted in
an organizational chart) and focuses on different groups’ roles and responsibilities to meet
the goals and policies set by top management. This frame is very rational and focuses on
coordination and control. For example, within the structural frame, a key IT issue is
whether a company should centralize the IT personnel in one department or decentralize
across several departments. You will learn more about organizational structures in the
next section.
 The human resources (HR) frame focuses on producing harmony between the needs of
the organization and the needs of people. It recognizes that mismatches can occur
between the needs of the organization and those of individuals and groups, and works to
resolve any potential problems. For example, many projects might be more efficient for

22
 the organization if employees worked 80 or more hours a week for several months.
However, this work schedule would conflict with the personal lives and health of many
employees. Important IT issues related to the human resources frame are the shortage of
skilled IT workers within the organization and unrealistic schedules imposed on many
projects.
Structural frame: Roles and Human resources frame: Providing harmony
responsibilities, coordination, and control. between needs of the organization and needs
Organizational charts help describe this of people.
frame.
Political frame: Coalitions composed of Symbolic frame: Symbols and meanings
varied individuals and interest groups. related to events. Culture, language,
Conflict and power are key issues. traditions, and image are all parts of this
frame.

Figure 2.1 – Perspective on Organizations

 The political frame addresses organizational and personal politics. Politics in

organizations take the form of competition among groups or individuals for power,
resources, and leadership. The political frame emphasizes that organizations are coalitions
composed of varied individuals and interest groups. Often, important decisions need to be
made about the allocation of scarce resources. Competition for resources makes conflict a
central issue in organizations, and power improves the ability to obtain those resources.
Project managers must pay attention to politics and power if they are to be effective. It is
important to know who opposes your projects as well as who supports them. Important IT
issues related to the political frame are the differences in power between central functions
and operating units or between functional managers and project managers.
 The symbolic frame focuses on symbols and meanings. In this frame, the most important
aspect of any event in an organization is not what actually happened, but what it means.
Was it a good sign that the CEO came to a kick-off meeting for a project, or was it a
threat? The symbolic frame also relates to the company’s culture. How do people dress?
How many hours do they work? How do they run meetings? Many IT projects are
international and include stakeholders from various cultures. Understanding those
cultures is also a crucial part of the symbolic frame.

ORGANIZATIONAL STRUCTURES

Many discussions of organizations focus on their structure. Three general classifications of

organizational structures are functional, project, and matrix. Many companies today use all

23
three structures somewhere in the organization, but using one is most common. Figure 2.2
portrays the three organizational structures. A functional organizational structure is the
hierarchy most people think of when picturing an organizational chart. Functional managers
or vice presidents in specialties such as engineering, manufacturing, IT, and human resources
report to the chief executive officer (CEO). Their staffs have specialized skills in their
respective disciplines. For example, most colleges and universities have very strong
functional organizations. Only faculty members in the business department teach business
courses; faculty in the history department teach history; faculty in the art department teach
art, and so on.

Figure 2.2 – Funtional, project and matrix organizational structures

24
A project organizational structure also is hierarchical, but instead of functional managers
or vice presidents reporting to the CEO, program managers report to the CEO. Their staffs
have a variety of skills needed to complete the projects within their programs. An
organization that uses this structure earns its revenue primarily from performing projects for
other groups under contract. For example, many defense, architectural, engineering, and
consulting companies use a project organizational structure. These companies often hire
people specifically to work on particular projects.

A matrix organizational structure represents the middle ground between functional and
project structures. Personnel often report both to a functional manager and one or more
project managers. For example, IT personnel at many companies often split their time
between two or more projects, but they report to their manager in the IT department. Project
managers in matrix organizations have staff from various functional areas working on their
projects, as shown in Figure 2-3. Matrix organizational structures can be strong, weak, or
balanced, based on the amount of control exerted by the project managers. Problems can
occur if project team members are assigned to several projects in a matrix structure and the
project manager does not have adequate control of their time.

Organizational Culture

Just as an organization’s structure affects its ability to manage projects, so does its culture.
Organizational culture is a set of shared assumptions, values, and behaviours that characterize
the functioning of an organization. It often includes elements of all four frames described
previously. Organizational culture is very powerful, and many people believe the underlying
causes of many companies’ problems are not in the organizational structure or staff; they are
in the culture. It is also important to note that the same organization can have different
subcultures. The IT department may have a different organizational culture than the finance
department, for example. Some organizational cultures make it easier to manage projects.

According to Stephen P. Robbins and Timothy Judge, authors of a popular textbook on

organizational behaviour, there are 10 characteristics of organizational culture:

1. Member identity: The degree to which employees identify with the organization as a
whole rather than with their type of job or profession. For example, project managers
or team members might feel more dedicated to their company or project team than to
their job or profession, or they might not have any loyalty to a particular company or

25
 team. As you can guess, an organizational culture in which employees identify more
with the whole organization are more conducive to a good project culture.

2. Group emphasis: The degree to which work activities are organized around groups or
teams, rather than individuals. An organizational culture that emphasizes group work
is best for managing projects.

3. People focus: The degree to which management’s decisions take into account the
effect of outcomes on people within the organization. A project manager might assign
tasks to certain people without considering their individual needs, or the project
manager might know each person very well and focus on individual needs when
assigning work or making other decisions. Good project managers often balance the
needs of individuals and the organization.

4. Unit integration: The degree to which units or departments within an organization are
encouraged to coordinate with each other. Most project managers strive for strong
unit integration to deliver a successful product, service, or result. An organizational
culture with strong unit integration makes the project manager’s job easier.

5. Control: The degree to which rules, policies, and direct supervision are used to
oversee and control employee behavior. Experienced project managers know it is
often best to balance the degree of control to get good project results.

6. Risk tolerance: The degree to which employees are encouraged to be aggressive,

innovative, and risk seeking. An organizational culture with a higher risk tolerance is
often best for project management because projects often involve new technologies,
ideas, and processes.

7. Reward criteria: The degree to which rewards, such as promotions and salary
increases, are allocated according to employee performance rather than seniority,
favouritism, or other non performance factors. Project managers and their teams often
perform best when rewards are based mostly on performance.

8. Conflict tolerance: The degree to which employees are encouraged to air conflicts and
criticism openly. It is very important for all project stakeholders to have good
communications, so it is best to work in an organization where people feel
comfortable discussing differences openly.

26
 9. Means-ends orientation: The degree to which management focuses on outcomes
rather than on techniques and processes used to achieve results. An organization with
a balanced approach in this area is often best for project work.

10. Open-systems focus: The degree to which the organization monitors and responds to
changes in the external environment. As you learned earlier in this chapter, projects
are part of a larger organizational environment, so it is best to have a strong open-
systems focus.

As you can see, there is a definite relationship between organizational culture and successful
project management. Project work is most successful in an organizational culture where
employees identify more with the organization, where work activities emphasize groups, and
where there is strong unit integration, high risk tolerance, performance-based rewards, high
conflict tolerance, an open-systems focus, and a balanced focus on people, control, and
means orientation.

2.4 STAKEHOLDER MANAGEMENT

Project stakeholders are the people involved in or affected by project activities.

Stakeholders can be internal or external to the organization, directly involved in the project,
or simply affected by the project. Internal project stakeholders include the project sponsor,
project team, support staff, and internal customers of the project. Other internal stakeholders
include top management, other functional managers, and other project managers. Projects
affect these additional internal stakeholders because they use the organization's limited
resources. Thus, while additional internal stakeholders may not be directly involved in the
project, they are still stakeholders because the project affects them in some way.

External project stakeholders include the project’s customers (if they are external to the
organization), competitors, suppliers, and other external groups potentially involved in the
project or affected by it, such as government officials or concerned citizens. Because the
purpose of project management is to meet project requirements and satisfy stakeholders, it is
critical that project managers take adequate time to identify, understand, and manage
relationships with all project stakeholders.

27
THE IMPORTANCE OF TOP MANAGEMENT COMMITMENT

People in top management positions, of course, are key stakeholders in projects. A very
important factor in helping project managers successfully lead projects is the level of
commitment and support they receive from top management. In fact, without top
management commitment, many projects will fail.

As described earlier, projects are part of the larger organizational environment, and many
factors that might affect a project are out of the project manager’s control. Several studies cite
executive support as one of the key factors associated with the success of virtually all
projects.

Top management commitment is crucial to project managers for the following reasons:
a) Project managers need adequate resources. The best way to kill a project is to withhold
the required money, people, resources, and visibility for the project. If project managers
have top management commitment, they will also have adequate resources and not be
distracted by events that do not affect their specific projects.
b) Project managers often require approval for unique project needs in a timely manner. For
example, on large information technology projects, top management must understand that
unexpected problems may result from the nature of the products being produced and the
specific skills of the people on the project team. For example, the team might need
additional hardware and software halfway through the project for proper testing, or the
project manager might need to offer special pay and benefits to attract and retain key
project personnel. With top management commitment, project managers can meet these
specific needs in a timely manner.
c) Project managers must have cooperation from people in other parts of the organization.
Since most information technology projects cut across functional areas, top management
must help project managers deal with the political issues that often arise in these types of
situations. If certain functional managers are not responding to project managers’ requests
for necessary information, top management must step in to encourage functional
managers to cooperate.
d) Project managers often need someone to mentor and coach them on leadership issues.
Many information technology project managers come from technical positions and often
are inexperienced as managers. Senior managers should take the time to pass on

28
 leadership advice and encourage new project managers to take classes to develop
leadership skills and allocate the time and funds for them to do so.
Information technology project managers work best in an environment in which top
management values information technology. Working in an organization that values good
project management and sets standards for its use also helps project managers succeed.

2.5 PROJECT PHASES

A project life cycle is a collection of phases. Phases break projects down into smaller,
more manageable pieces, which will reduce uncertainty. Some organizations specify a set of
life cycles for use in all of their projects, while others follow common industry practices
based on the types of projects involved. Project life cycles define what work will be
performed in each phase, what deliverables will be produced and when, who is involved in
each phase, and how management will control and approve work produced in each phase. A
deliverable is a product or service, such as a technical report, a training session, a piece of
hardware, or a segment of software code, produced or provided as part of a project.

In early phases of a project life cycle, resource needs are usually lowest and the level of
uncertainty is highest. Project stakeholders have the greatest opportunity to influence the final
characteristics of the project’s products, services, or results during the early phases of a
project life cycle. It is much more expensive to make major changes to a project during later
phases. During the middle phases of a project life cycle, the certainty of completing the
project improves as it continues and as more information is known about the project
requirements and objectives. Also, more resources are usually needed than during the initial
or final phase. The final phase of a project focuses on ensuring that project requirements were
met and that the project sponsor approves completion of the project.

The first two traditional project phases (concept and development) focus on planning, and are
often referred to as project feasibility. The last two phases (implementation and closeout)
focus on delivering the actual work, and are often referred to as project acquisition. Each
phase of a project should be successfully completed before the team moves on to the next
phase. This project life cycle approach provides better management control and appropriate
links to the ongoing operations of the organization.

Figure 2.3 provides a summary of the general phases of the traditional project life cycle. In
the concept phase, managers usually develop a business case, which describes the need for

29
the project and basic underlying concepts. A preliminary or rough cost estimate is developed
in this first phase, and an overview of the required work is created.
One tool for creating an overview of the required work is a work breakdown structure
(WBS). A WBS outlines project work by decomposing the work activities into different
levels of tasks. The WBS is a deliverable-oriented document that defines the total scope of
the project. In the concept phase, a WBS usually has only two levels.

Figure 2.3 – Phases of traditional Project Life Cycle

After the concept phase is completed, the next project phase—development—begins. In the
development phase, the project team creates more detailed project management plans, a more
accurate cost estimate, and a more thorough WBS.
The third phase of the traditional project life cycle is implementation. In this phase, the
project team creates a definitive or very accurate cost estimate, delivers the required work,
and provides performance reports to stakeholders.
The last phase of the traditional project life cycle is the close-out phase. In it, all of the work
is completed, and customers should accept the entire project. The project team should
document its experiences on the project in a lessons-learned report.
Many projects, however, do not follow this traditional project life cycle. They still have
general phases with some similar characteristics, but they are much more flexible. For
example, a project might have just three phases—the initial, intermediate, and final phases.
Or, there may be multiple intermediate phases. A separate project might be needed just to
complete a feasibility study. Regardless of the project life cycle’s specific phases, it is good

30
practice to think of projects as having phases that connect the beginning and end of the
process. This way, people can measure progress toward achieving project goals during each
phase and the project is more likely to be successful.

2.6 THE CONTEXT OF INFORMATION TECHNOLOGY PROJECTS

The project context has a critical impact on which product development life cycle will
be most effective for a particular software development project. Likewise, several issues
unique to the IT industry have a critical impact on managing IT projects. These include the
nature of projects, the characteristics of project team members, and the diverse nature of
technologies involved.

2.6.1 THE NATURE OF IT PROJECTS

Unlike projects in many other industries, IT projects are diverse. Some involve a small
number of people installing off-the-shelf hardware and associated software. Others involve
hundreds of people analyzing several organizations’ business processes and then developing
new software in a collaborative effort with users to meet business needs. Even for small
hardware-oriented projects, a wide diversity of hardware types can be involved—personal
computers, mainframe computers, network equipment, kiosks, laptops, tablets, or
smartphones. The network equipment might be wireless, cellular based, or cable-based, or
might require a satellite connection. The nature of software development projects is even
more diverse than hardware-oriented projects. A software development project might include
creating a simple, stand-alone Microsoft Excel or Access application or a sophisticated,
global e-commerce system that uses state-of-the-art programming languages and runs on
multiple platforms.
IT projects also support every possible industry and business function. Managing an IT
project for a film company’s animation department requires different knowledge and skills
than a project to improve a federal tax collection system or to install a communication
infrastructure in a third-world country. Because of the diversity of IT projects and the
newness of the field, it is important to develop and follow best practices in managing these
varied projects. Developing best practices gives IT project managers a common starting point
and method to follow with every project.

31
2.6.2 CHARACTERISTICS OF IT PROJECT TEAM MEMBERS

Because IT projects are diverse, the people involved come from diverse backgrounds and
possess different skills. The resulting diverse project teams provide a significant advantage
because they can analyze project requirements from a more robust systems view. Many
companies purposely hire graduates with degrees in other fields such as business,
mathematics, or the liberal arts to provide different perspectives on IT projects. Even with
these different educational backgrounds, however, there are common job titles for people
working on most IT projects, such as business analyst, programmer, network specialist,
database analyst, quality assurance expert, technical writer, security specialist, hardware
engineer, software engineer, and system architect. Within the category of programmer,
several other job titles describe the specific technologies used, such as Java programmer,
PHP programmer, and C/C++/C# programmer.
Some IT projects require the skills of people in just a few job functions, but some require
inputs from many or all of them. Occasionally, IT professionals move between these job
functions, but more often people become technical experts in one area or they decide to move
into a management position. It is also rare for technical specialists or project managers to
remain with the same company for a long time. In fact, many IT projects 65include a large
number of contract workers. Working with this “army of free agents,” as author Rob
Thomsett calls them, creates special challenges.

2.6.3 DIVERSE TECHNOLOGIES

Many of the job titles for IT professionals reflect the different technologies required to hold
those positions. Differences in technical knowledge can make communication between
professionals challenging. Hardware specialists might not understand the language of
database analysts, and vice versa. Security specialists may have a hard time communicating
with business analysts. People within the same IT job function often do not understand each
other because they use different technology. For example, someone with the title of
programmer can often use several different programming languages. However, if
programmers are limited in their ability to work in multiple languages, project managers
might find it more difficult to form and lead more versatile project teams.

Another problem with diverse technologies is that many of them change rapidly. A project
team might be close to finishing a project when it discovers a new technology that can greatly
enhance the project and better meet long-term business needs. New technologies have also

32
shortened the time frame many businesses have to develop, produce, and distribute new
products and services. This fast-paced environment requires equally fast paced processes to
manage and produce IT projects and products.

2.7 RECENT TRENDS AFFECTING INFORMATION TECHNOLOGY

PROJECT MANAGEMENT

Recent trends such as increased globalization, outsourcing, virtual teams, and agile
project management are creating additional challenges and opportunities for IT project
managers and their teams. Each of these trends and suggestions for addressing them are
discussed in this section.

2.7.1 GLOBALIZATION

IT is a key enabler of globalization. In 2014, more than 1.3 billion people were using
Facebook, spending an average of 21 minutes a day.17 Other social networks, such as Twitter
and LinkedIn, also continue to grow. In 2014, there were over 284 million Twitter users and
332 million LinkedIn users. According to LinkedIn’s website, in the third quarter of 2014, 75
percent of new members came from outside the United States. Globalization has significantly
affected the field of IT. Even though major IT companies such as Apple, IBM, and Microsoft
started in the United States, much of their business is global—indeed, companies and
individuals throughout the world contribute to the growth of information technologies, and
work and collaborate on various IT projects.

It is important for project managers to address several key issues when working on global
projects:

Communications: Because people work in different time zones, speak different languages,
have different cultural backgrounds, and celebrate different holidays, it is important to
address how people will communicate in an efficient and timely manner. A communications
management plan is vital. For details, see the plan described in Chapter 10, Project
Communications Management.

Trust: Trust is an important issue for all teams, especially when they are global teams. It is
important to start building trust immediately by recognizing and respecting others’
differences and the value they add to the project.

33
Common work practices: It is important to align work processes and develop a modus
operandi with which everyone agrees and is comfortable. Project managers must allow time
for the team to develop these common work practices. Using special tools, as described next,
can facilitate this process.

Tools: IT plays a vital role in globalization, especially in enhancing communications and

work practices. Many people use free tools such as Skype, Google Docs, or social media to
communicate. Many project management software tools include their own communications
and collaboration features in an integrated package. IBM continues to be the leader in
providing collaboration tools to businesses in over 175 companies, followed by Oracle in 145
countries, SAP in 130 countries, and Microsoft in 113 countries.18 Work groups must
investigate options and decide which tools will work best for their projects. Security is often a
key factor in deciding which tools to use.

2.7.2 OUTSOURCING

The term offshoring is sometimes used to describe outsourcing from another country.
Offshoring is a natural outgrowth of globalization. IT projects continue to rely more and
more on outsourcing, both within and outside their country boundaries.

In its simplest sense, Software Development Outsourcing describes an arrangement, in

which an organization chooses to hire an external software development agency to effectively
carry out all the tasks of a software development project, that could be done in-house instead.
Software outsourcing is about the practice of a company handing over the control of a certain
business process or project to a third-party vendor that is qualified and capable of handling
the required business tasks.

Outsourcing is cost-effective, and in particular - offshore software outsourcing helps lower

development costs which essentially translates to lower market price and enhances
competition. However, in recent years, according to a report by Deloitte and Dubai Outsource
City, companies are starting to look toward software outsourcing to achieve a variety of
business objectives, beyond just costs.

Modes of Software Outsourcing:

There are certain ways for businesses to outsource their software projects to vendors across
the globe, where the development centres can reside on-shore, offshore, and near-shore. Let’s
consider in detail as follow:

34
Onshore Software Outsourcing
Onshore outsourcing refers to the act of customer companies working with development
teams of software companies that are located in the same country. The advantage of onshore
outsourcing is that there are virtually no language barriers which make communication much
easier and eventually, making outsourcing more effective. However, in return, customers may
have to pay more for development costs.

Offshore Software Outsourcing

Offshore outsourcing means working with development teams in other countries. This is the
most cost-effective option due to low labour costs, and also online communications channels
(e.g. Emails, VoIP Phones, Zoom video conferences, etc.) making it possible to effectively
manage software projects remotely.

Nearshore Software Outsourcing

Nearshore outsourcing companies work with customers in neighbouring countries.

HOW TO OUTSOURCE SOFTWARE DEVELOPMENT EFFECTIVELY?

There are numerous factors that influence the likelihood of success when it comes to software
outsourcing. Among those, there are certain aspects which companies should keep in mind,
including:

 Establish clear goals for outsourcing

 Involve in project management and collaborate with remote teams.
 Have realistic expectations.
 Set milestones and frequently track progress to provide feedback

Again, there’s no way to guarantee that an outsourcing project will become a hundred percent
success. But there are certain things to do that can help companies improve the chance of
success. Furthermore, customer companies should opt for outsourcing partners who apply
agile methodology in managing their development projects in a flexible way, to allow for
better quality and more frequent release as well as improve collaborations. Additionally,
employing advanced tools for efficient project task management is also highly recommended
to help gain visibility into project progress.

35
2.7.3 VIRTUAL TEAMS

A virtual team (aka “virtual workgroup”) is a group of people who participate in common
projects by making collaborative efforts to achieve shared goals and objectives. These people
perform tasks and jobs in a virtual work environment created and maintained through IT and
software technologies.

Figure 2.4 – Virtual teams in the Organization

There are two types of virtual teams, such as follows:

 Global virtual team. As a rule, these teams are located in different countries and
cities all over the world. They can be employees of several companies which join their
efforts and resources (incl. people, technology, money) to perform shared outsourced
projects and achieve common goals.
 Local virtual team. Members of a local virtual workgroup usually belong to the same
company. That company is either big or small, and it has enough resources
(technology is essential) to establish and maintain virtual team workplaces and
organize its employees into a productive remote group.

Virtual team management includes, but not limited to, the following processes:

 Assembling. Probation periods are the first measurements to be applied when starting
with remote teamwork organization. The team leader should decide on those people
who meet all the requirements of probation periods.

36
  Training. During this process, the team leader sets expectations as to future virtual
teaming and then develops and applies a group training methodology to teach the
team members how to meet the expectations.
 Managing. This process means using telecommunication technologies to manage
ongoing tasks and jobs of remote group members.
 Controlling. The team leader establishes performance measures to assess and
evaluate team performance. This person needs to find out whether the team is on the
right track and can achieve project goals on schedule.

These are the major processes of virtual team management. However, there can be subsidiary
processes that allow for a better of understanding the virtual team’s phenomena.

Advantages and Dis-advantages of Virtual Team Management:

Some of the advantages of virtual team management are (but not limited to) the following:
 Reduced rents and technology savings
 Lower transportation costs and less time spent on commuting
 Instant communication and information exchange
Some of the disadvantages of virtual team management are (but not limited to) the
following:
 Poorer control of virtual groups (this may result in reduced trust in virtual teams),
because there are no direct control tools
 Problems to establish good virtual team leadership (comparing to “physical”
team leading)
 Unfitness to the projects which require on-site control and management

How to improve virtual team collaboration

As mentioned, virtual team management offers tangible benefits to your project or business;
still, you have to address some distinct challenges. Many project managers struggle to create
a truly “collaborative” virtual culture.

These two essential steps below can help you build a productive virtual team and improve
remote collaboration.

1. Use a single collaborative system for virtual team management

Make sure that everyone in your remote team uses the same virtual application and database
to manage inbox, chats, to-do lists, shared documents, spreadsheets, and other essentials of
your projects. For example, you can successfully manage your virtual team remotely from

37
anywhere with any device by adopting innovative cloud products such as Citrix
VDI and Cloud QuickBooks Hosting from Apps4Rent.
Remote employees often spread information across multiple systems and tools. For example,
using Gmail for emailing, Zoho for CRM, Slack for real-time communication, and Skype for
video conferencing can be okay to some extent.

However, as your projects grow and you onboard new remote workers, your team has to deal
with multiple data sources and various apps, which will ultimately create clutter and lack of
control of team performance.

2. Enable automation to get more things done faster

As artificial intelligence, IoT, edge computing, and other emerging technologies become
increasingly prevalent; project managers and team leaders seek ways to improve process
management and collaboration in virtual team environments.
Automation is among the simplest ways to help remote teams get rid of routine tasks and
focus on more value-adding activities. It allows for maximizing ROI on human capital
(including virtual teams), while reducing time and effort needed to get things done.
For example, let’s take online sales and lead generation. Here are at least three things that
workflow automation can offer for remote sales teams and marketers:

1. Simplify lead data capturing by enabling web forms and pop-up invitations as well as
automated follow-up emails and smart notifications for customers. Examples: Insightly CRM,
Zoho, Pipedrive.

2. Shorten total lead time by as much as 35% by allowing for chatbots and intelligent
virtual assistants to serve online prospects and customers. Examples: livechatinc.com,
Zendesk AI-powered chatbot, chatbot.com.

3. Delight customers by gamifying lead generation. The secret here is, instead of wasting
time on cold messages via phone, social media, or email, your sales reps will focus on
analysing customer data. Your team gets insights about what a given prospect is seeking and
what product or service is best to offer. Quizzes, video guides, and interactive HTML5 mini-
games are examples of how you can gamify lead generation and help your local and remote
teams get more deals.

38
2.8 CHECK YOUR PROGRESS

1. What are Systems approach, Systems philosophy and Systems analysis in Project
Management?
2. Which are the Four Frames of Organizations?
3. Name any 5 characteristics of organizational culture.
4. What are the key issues faced by Project Managers while working on global projects?
5. Which are the different modes of outsourcing?

Answers to check your progress:

1. Systems approach is a holistic and analytical approach to solving complex problems that
includes using a systems philosophy, systems analysis, and systems management.
Systems philosophy is an overall model for thinking about things as systems. Systems
analysis is a problem-solving approach that requires defining the scope of the system,
dividing it into components, and then identifying and evaluating its problems,
opportunities, constraints, and needs.
2. Structural frame, human resources (HR) frame, political frame, symbolic frame.
3. Member identity, Group emphasis, People focus, Unit integration, Control
4. Communications, Trust, Common work practices, Tools
5. Onshore Software Outsourcing, Offshore Software Outsourcing, Nearshore Software
Outsourcing.

2.9 SUMMARY

This unit focuses on the systems view of project management and the application of
Information Technology. The analysis helps the organization to provide the perspectives of
structural, hr and political frames. This also helps to understand the conceptual,
developmental, implementational and close-out phases of project life cycle. It also provides
the clarity between project and product development.

2.10 KEYWORDS

 Systems philosophy: It is an overall model for thinking about things as systems.

 Systems analysis: It is a problem-solving approach that requires defining the scope of the
system, dividing it into components, and then identifying and evaluating its problems,
opportunities, constraints, and needs.
39
 Political frame: It addresses organizational and personal politics.
 Matrix organizational structure: It represents the middle ground between functional
and project structures.
 Deliverable: It is a product or service, such as a technical report, a training session, a
piece of hardware, or a segment of software code, produced or provided as part of a
project.

2.11 QUESTIONS FOR SELF STUDY

1. Explain the four frames of organizations and their perspectives.

2. Explain Functional, project and matrix organizational structures with the help of a
diagram.
3. What are the characteristics of organizational culture according to Stephen P. Robbins
and Timothy Judge?
4. Why top management commitment is crucial to project managers?
5. Explain phases of traditional project life cycle with the help of a neat diagram.
6. What the key issues unique to IT industry that has a critical impact on managing IT
projects?
7. Write a brief note on recent trends affecting information technology project
management.

2.12 REFERENCES

1. https://ocw.ui.ac.id/pluginfile.php/13396/mod_resource/content/2/Schwalbe%208th%20-
%20Chapter%2002.pdf
2. https://www.tpptechnology.com/
3. https://mymanagementguide.com/

40
UNIT-3: SOFTWARE MANAGEMENT CONCEPTS

STRUCTURE

3.0 Objectives
3.1 Introduction
3.2 The Management Spectrum
3.2.1 The People
3.2.2 The Product
3.2.3 The Process
3.2.4 The Project
3.3 Software Configuration Management
3.3.1 SCM Scenario, Elements
3.3.2 SCM Process
3.3.3 Configuration Management for WebApps
3.4 Software Testing Strategies
3.4.1 A Strategic approach to software testing
3.4.2 Strategic Issues
3.4.3 Test Strategies for Conventional Software
3.4.4 Validation Testing
3.4.5 System Testing
3.4.6 The Art of Debugging
3.5 The Cleanroom Strategy
3.6 Check your progress
3.7 Summary
3.8 Key words
3.9 Questions for self-study
3.10 References

3.0 OBJECTIVES

After studying this unit, you will be able to:

 Explain the major focusing factors of the management, 4Ps – People, Process,
Product, Project

41
  Identify different kinds of people involved which are stake holders, team leaders,
software team, etc.
 Describe the scope of the project and the ability to decompose the problem
 Explain the SCM scenario with the example of WebApps
 Distinguish the different types of Software Testing Strategies and the implementation
need
 Discuss the debugging strategy and clean room strategy

3.1 INTRODUCTION

In this unit, we are going to discuss about software management concepts. The
Management Spectrum focuses on the four P’s: people, product, process, and project. It
emphasizes on the importance of these 4 parameters in building a successful and robust team
and process in software project management.

3.2 THE MANAGEMENT SPECTRUM

Effective software project management focuses on the four P’s: people, product, process,
and project. The order is not arbitrary. The manager who forgets that software engineering
work is an intensely human endeavor will never have success in project management. A
manager who fails to encourage comprehensive stakeholder communication early in the
evolution of a product risks building an elegant solution for the wrong problem. The manager
who pays little attention to the process runs the risk of inserting competent technical methods
and tools into a vacuum. The manager who embarks without a solid project plan jeopardizes
the success of the project.

3.2.1 THE PEOPLE

According to People Capability Maturity Model (pcmm), the people factor defines the key
factor areas in software development: staffing, communication and coordination, work
environment, performance management, training, compensation, competency analysis and
development, career development, workgroup development, team/culture development, and
others. Organizations that achieve high levels of People-CMM maturity have a higher
likelihood of implementing effective software project management practices.

42
3.2.1.1 THE STAKEHOLDERS

The software process (and every software project) is populated by stakeholders who can
be categorized into one of five constituencies:

1. Senior managers who define the business issues that often have a significant influence
on the project.
2. Project (technical) managers who must plan, motivate, organize, and control the
practitioners who do software work.
3. Practitioners who deliver the technical skills that are necessary to engineer a product or
application.
4. Customers who specify the requirements for the software to be engineered and other
stakeholders who have a peripheral interest in the outcome.
5. End users who interact with the software once it is released for production use.
Every software project is populated by people who fall within this taxonomy. To be effective,
the project team must be organized in a way that maximizes each person’s skills and abilities.
And that’s the job of the team leader.

3.2.1.2 TEAM LEADERS

Project management is a people-intensive activity, and for this reason, competent

practitioners often make poor team leaders. They simply don’t have the right mix of people
skills. According to Jerry Weinberg, the expected skills to be present in team leaders are,
 Motivation. The ability to encourage (by “push or pull”) technical people to produce
to their best ability.
 Organization. The ability to mold existing processes (or invent new ones) that will
enable the initial concept to be translated into a final product.
 Ideas or innovation. The ability to encourage people to create and feel creative even
when they must work within bounds established for a particular software product or
application.
 Problem solving. An effective software project manager can diagnose the technical
and organizational issues that are most relevant, systematically structure a solution or
properly motivate other practitioners to develop the solution, apply lessons learned
from past projects to new situations, and remain flexible enough to change direction if
initial attempts at problem solution are fruitless.

43
  Managerial identity. A good project manager must take charge of the project. She
must have the confidence to assume control when necessary and the assurance to
allow good technical people to follow their instincts.
 Achievement. A competent manager must reward initiative and accomplishment to
optimize the productivity of a project team. She must demonstrate through her own
actions that controlled risk taking will not be punished.
 Influence and team building. An effective project manager must be able to “read”
people; she must be able to understand verbal and nonverbal signals and react to the
needs of the people sending these signals. The manager must remain under control in
high-stress situations.

3.2.1.3 THE SOFTWARE TEAM

The “best” team structure depends on the management style of the organization, the number
of people who will populate the team and their skill levels, and the overall problem difficulty.
Mantei [Man81] describes seven project factors that should be considered when planning the
structure of software engineering teams:
 Difficulty of the problem to be solved
 “Size” of the resultant program(s) in lines of code or function points T
 ime that the team will stay together (team lifetime)
 Degree to which the problem can be modularized
 Required quality and reliability of the system to be built
 Rigidity of the delivery date
 Degree of sociability (communication) required for the project

3.2.2 THE PRODUCT

A software project manager is confronted with a dilemma at the very beginning of a software
project. Quantitative estimates and an organized plan are required, but solid information is
unavailable. A detailed analysis of software requirements would provide necessary
information for estimates, but analysis often takes weeks or even months to complete. Worse,
requirements may be fluid, changing regularly as the project proceeds. Yet, a plan is needed
“now!” Like it or not, one must examine the product and the problem it is intended to solve at
the very beginning of the project. At a minimum, the scope of the product must be established
and bounded.

44
3.2.2.1 SOFTWARE SCOPE

The first software project management activity is the determination of software scope. Scope
is defined by answering the following questions:
Context. How does the software to be built fit into a larger system, product, or business
context, and what constraints are imposed as a result of the context?
Information objectives. What customer-visible data objects are produced as output from the
software? What data objects are required for input? Function and performance. What function
does the software perform to transform input data into output? Are any special performance
characteristics to be addressed?
Software project scope must be unambiguous and understandable at the management and
technical levels. A statement of software scope must be bounded. That is, quantitative data
(e.g., number of simultaneous users, target environment, maximum allowable response time)
are stated explicitly, constraints and/or limitations (e.g., product cost restricts memory size)
are noted, and mitigating factors (e.g., desired algorithms are well understood and available
in Java) are described.

3.2.2.2 PROBLEM DECOMPOSITION

Problem decomposition, sometimes called partitioning or problem elaboration, is an activity

that sits at the core of software requirements analysis. During the scoping activity no attempt
is made to fully decompose the problem. Rather, decomposition is applied in two major
areas:
(1) The functionality and content (information) that must be delivered and

(2) The process that will be used to deliver it.

Human beings tend to apply a divide-and-conquer strategy when they are confronted with a
complex problem. Stated simply, a complex problem is partitioned into smaller problems that
are more manageable. This is the strategy that applies as project planning begins. Software
functions, described in the statement of scope, are evaluated and refined to provide more
detail prior to the beginning of estimation.

Example:

As an example, consider a project that will build a new word-processing product. Among the
unique features of the product are continuous voice as well as virtual keyboard input via a
multi-touch screen, extremely sophisticated “automatic copy edit” features, page layout

45
capability, automatic indexing and table of contents, and others. The project manager must
first establish a statement of scope that bounds these features (as well as other more mundane
functions such as editing, file management, and document production). For example, will
continuous voice input require that the product be “trained” by the user? Specifically, what
capabilities will the copy edit feature provide? Just how sophisticated will the page layout
capability be and will it encompass the capabilities implied by a multitouch screen?

As the statement of scope evolves, a first level of partitioning naturally occurs. The project
team learns that the marketing department has talked with potential customers and found that
the following functions should be part of automatic copy editing:

(1) Spell checking,

(2) Sentence grammar checking,
(3) Reference checking for large documents (e.g., Is a reference to a bibliography entry
found in the list of entries in the bibliography?),
(4) The implementation of a style sheet feature that imposed consistency across a
document, and
(5) Section and chapter reference validation for large documents.

Each of these features represents a sub-function to be implemented in software. Each can be

further refined if the decomposition will make planning easier.

3.2.3 THE PROCESS

The purpose of the process element is, the team must decide which process model is most
appropriate for

(1) The customers who have requested the product and the people who will do the work,
(2) The characteristics of the product itself, and
(3) The project environment in which the software team works.

When a process model has been selected, the team then defines a preliminary project plan
based on the set of process framework activities. Once the preliminary plan is established,
process decomposition begins. That is, a complete plan, reflecting the work tasks required to
populate the framework activities must be created.

46
3.2.3.1 PROCESS DECOMPOSITION

A software team should have a significant degree of flexibility in choosing the software
process model that is best for the project and the software engineering tasks that populate the
process model once it is chosen. Once the process model has been chosen, the process
framework is adapted to it.

Process decomposition commences when the project manager asks, “How do we accomplish
this framework activity?” For example, a small, relatively simple project might require the
following work tasks for the communication activity:

1. Develop list of clarification issues.

2. Meet with stakeholders to address clarification issues.
3. Jointly develop a statement of scope.
4. Review the statement of scope with all concerned.
5. Modify the statement of scope as required.

These events might occur over a period of less than 48 hours. They represent a process
decomposition that is appropriate for the small, relatively simple project.

3.2.4 THE PROJECT

In order to manage a successful software project, one has to understand what can go wrong so
that problems can be avoided. In an excellent paper on software projects, John Reel [Ree99]
defines 10 signs that indicate that an information systems project is in jeopardy:

1. Software people don’t understand their customer’s needs.

2. The product scope is poorly defined.
3. Changes are managed poorly.
4. The chosen technology changes.
5. Business needs change [or are ill defined].
6. Deadlines are unrealistic.
7. Users are resistant.
8. Sponsorship is lost [or was never properly obtained].
9. The project team lacks people with appropriate skills.
10. Managers [and practitioners] avoid best practices and lessons learned.

Reel [Ree99] suggests a five-part common sense approach to software projects:

47
1. Start on the right foot. This is accomplished by working hard (very hard) to understand
the problem that is to be solved and then setting realistic objectives and expectations for
everyone who will be involved in the project. It is reinforced by building the right team
and giving the team the autonomy, authority, and technology needed to do the job.

2. Maintain momentum. Many projects get off to a good start and then slowly disintegrate.
To maintain momentum, the project manager must provide incentives to keep turnover of
personnel to an absolute minimum, the team should emphasize quality in every task it
performs, and senior management should do everything possible to stay out of the team’s
way.

3. Track progress. For a software project, progress is tracked as work products (e.g.,
models, source code, sets of test cases) are produced and approved (using technical
reviews) as part of a quality assurance activity. In addition, software process and project
measures can be collected and used to assess progress against averages developed for the
software development organization.

4. Make smart decisions. In essence, the decisions of the project manager and the software
team should be to “keep it simple.” Whenever possible, decide to use commercial off-the-
shelf software or existing software components or patterns, decide to avoid custom
interfaces when standard approaches are available, decide to identify and then avoid
obvious risks, and decide to allocate more time than you think is needed to complex or
risky tasks (you’ll need every minute).

5. Conduct a post-mortem analysis. Establish a consistent mechanism for extracting lessons

learned for each project. Evaluate the planned and actual schedules, collect and analyze
software project metrics, get feedback from team members and customers, and record
findings in written form.

3.3 SOFTWARE CONFIGURATION MANAGEMENT

The output of the software process is information that may be divided into three broad
categories:
(1) Computer programs (both source level and executable forms),
(2) Work products that describe the computer programs (targeted at various
stakeholders), and
(3) Data or content (contained within the program or external to it).

48
The items that comprise all information produced as part of the software process are
collectively called a software configuration.

3.3.1 SCM SCENARIO

A typical CM operational scenario involves a project manager who is in charge of a software

group, a configuration manager who is in charge of the CM procedures and policies, the
software engineers who are responsible for developing and maintaining the software product,
and the customer who uses the product. In the scenario, assume that the product is a small
one involving about 15,000 lines of code being developed by a team of six people. (Note that
other scenarios of smaller or larger teams are possible, but, in essence, there are generic
issues that each of these projects face concerning CM.)

At the operational level, the scenario involves various roles and tasks. For the project
manager, the goal is to ensure that the product is developed within a certain time frame.
Hence, the manager monitors the progress of development and recognizes and reacts to
problems. This is done by generating and analyzing reports about the status of the software
system and by performing reviews on the system

The goals of the configuration manager are to ensure that procedures and policies for
creating, changing, and testing of code are followed, as well as to make information about the
project accessible. To implement techniques for maintaining control over code changes, this
manager introduces mechanisms for making official requests for changes, for evaluating them
(via a Change Control Board that is responsible for approving changes to the software
system), and for authorizing changes. The manager creates and disseminates task lists for the
engineers and basically creates the project context. Also, the manager collects statistics about
components in the software system, such as information determining which components in
the system are problematic.

For the software engineers, the goal is to work effectively. This means engineers do not
unnecessarily interfere with each other in the creation and testing of code and in the
production of supporting work products. But, at the same time, they try to communicate and
coordinate efficiently. Specifically, engineers use tools that help build a consistent software
product. They communicate and coordinate by notifying one another about tasks required and
tasks completed. Changes are propagated across each other’s work by merging files.
Mechanisms exist to ensure that, for components that undergo simultaneous changes, there is
some way of resolving conflicts and merging changes. A history is kept of the evolution of all

49
components of the system along with a log with reasons for changes and a record of what
actually changed. The engineers have their own workspace for creating, changing, testing,
and integrating code. At a certain point, the code is made into a baseline from which further
development continues and from which variants for other target machines are made.

The customer uses the product. Since the product is under CM control, the customer follows
formal procedures for requesting changes and for indicating bugs in the product.

Ideally, a CM system used in this scenario should support all these roles and tasks; that is, the
roles determine the functionality required of a CM system. The project manager sees CM as
an auditing mechanism; the configuration manager sees it as a controlling, tracking, and
policy making mechanism; the software engineer sees it as a changing, building, and access
control mechanism; and the customer sees it as a quality assurance mechanism.

SCM ELEMENTS

In her comprehensive white paper on software configuration management, Susan Dart

[Dar01] identifies four important elements that should exist when a configuration
management system is developed:

 Component elements—a set of tools coupled within a file management system (e.g., a
database) that enables access to and management of each software configuration item.
 Process elements—a collection of actions and tasks that define an effective approach to
change management (and related activities) for all constituencies involved in the
management, engineering, and use of computer software.
 Construction elements—a set of tools that automate the construction of software by
ensuring that the proper set of validated components (i.e., the correct version) have been
assembled.
 Human elements—a set of tools and process features (encompassing other CM elements)
used by the software team to implement effective SCM. These elements (to be discussed in
more detail in later sections) are not mutually exclusive.

For example, component elements work in conjunction with construction elements as the
software process evolves. Process elements guide many human activities that are related to
SCM and might therefore be considered human elements as well.

50
3.3.2 SCM PROCESS

The software configuration management process defines a series of tasks that have four
primary objectives:

1. To identify all items that collectively define the software configuration,

2. To manage changes to one or more of these items,
3. To facilitate the construction of different versions of an application, and
4. To ensure that software quality is maintained as the configuration evolves over time.

A process that achieves these objectives need not be bureaucratic or ponderous, but it must be
characterized in a manner that enables a software team to develop answers to a set of
complex questions:

 How does a software team identify the discrete elements of a software configuration?
 How does an organization manage the many existing versions of a program (and its
documentation) in a manner that will enable change to be accommodated efficiently?
 How does an organization control changes before and after software is released to a
customer?
 Who has responsibility for approving and ranking requested changes?
 How can we ensure that changes have been made properly?
 What mechanism is used to apprise others of changes that are made?

These questions lead to the definition of five SCM tasks—identification, version control,
change control, configuration auditing, and reporting—illustrated in Figure below.

Fig 3.1: Layers of SCM process

51
Referring to the figure, SCM tasks can viewed as concentric layers. SCIs flow outward
through these layers throughout their useful life, ultimately becoming part of the software
configuration of one or more versions of an application or system. As an SCI moves through
a layer, the actions implied by each SCM task may or may not be applicable. For example,
when a new SCI is created, it must be identified. However, if no changes are requested for the
SCI, the change control layer does not apply. The SCI is assigned to a specific version of the
software (version control mechanisms come into play). A record of the SCI (its name,
creation date, version designation, etc.) is maintained for configuration auditing purposes and
reported to those with a need to know. In the sections that follow, we examine each of these
SCM process layers in more detail.

3.3.3 CONFIGURATION MANAGEMENT FOR WEBAPPS

Content. A typical WebApp contains a vast array of content—text, graphics, applets, scripts,
audio/video files, forms, active page elements, tables, streaming data, and many others. The
challenge is to organize this sea of content into a rational set of configuration objects and
then establish appropriate configuration control mechanisms for these objects. One approach
is to model the WebApp content using conventional data modeling techniques attaching a set
of specialized properties to each object. The static/dynamic nature of each object and its
projected longevity (e.g., temporary, fixed existence, or permanent object) are examples of
properties that are required to establish an effective SCM approach. For example, if a content
item is changed hourly, it has temporary longevity. The control mechanisms for this item
would be different (less formal) than those applied for a forms component that is a permanent
object.

People. Because a significant percentage of WebApp development continues to be conducted

in an ad hoc manner, any person involved in the WebApp can (and often does) create content.
Many content creators have no software engineering background and are completely unaware
of the need for configuration management. As a consequence, the application grows and
changes in an uncontrolled fashion.

Scalability. The techniques and controls applied to a small WebApp do not scale upward
well. It is not uncommon for a simple WebApp to grow significantly as interconnections with
existing information systems, databases, data warehouses, and portal gateways are
implemented. As size and complexity grow, small changes can have far-reaching and

52
unintended effects that can be problematic. Therefore, the rigor of configuration control
mechanisms should be directly proportional to application scale.

3.3.3.1 WEBAPP CONFIGURATION OBJECTS

WebApps encompass a broad range of configuration objects—content objects (e.g., text,

graphics, images, video, audio), functional components (e.g., scripts, applets), and interface
objects (e.g., COM or CORBA). WebApp objects can be identified (assigned file names) in
any manner that is appropriate for the organization. However, the following conventions are
recommended to ensure that cross-platform compatibility is maintained: filenames should be
limited to 32 characters in length, mixedcase or all-caps names should be avoided, and the
use of underscores in file names should be avoided. In addition, URL references (links)
within a configuration object should always use relative paths (e.g.,
../products/alarmsensors.html).

All WebApp content has format and structure. Internal file formats are dictated by the
computing environment in which the content is stored. However, rendering format (often
called display format) is defined by the aesthetic style and design rules established for the
WebApp. Content structure defines a content architecture; that is, it defines the way in which
content objects are assembled to present meaningful information to an end user.

3.3.3.2 CONTENT MANAGEMENT

Content management is related to configuration management in the sense that a content

management system (CMS) establishes a process (supported by appropriate tools) that
acquires existing content (from a broad array of WebApp configuration objects), structures it
in a way that enables it to be presented to an end user, and then provides it to the client-side
environment for display.

The most common use of a content management system occurs when a dynamic WebApp is
built. Dynamic WebApps create Web pages “on-the-fly.” That is, the user typically queries
the WebApp requesting specific information. The WebApp queries a database, formats the
information accordingly, and presents it to the user. For example, a music company provides
a library of CDs for sale. When a user requests a CD or its e-music equivalent, a database is
queried and a variety of information about the artist, the CD (e.g., its cover image or
graphics), the musical content, and sample audio are all downloaded and configured into a

53
standard content template. The resultant Web page is built on the server side and passed to
the client-side browser for examination by the end user

In the most general sense, a CMS “configures” content for the end user by invoking three
integrated subsystems: a collection subsystem, a management subsystem, and a publishing
subsystem.

3.3.3.3 CHANGE MANAGEMENT

To implement effective change management within the “code and go” philosophy that
continues to dominate WebApp development, the conventional change control process must
be modified. Each change should be categorized into one of four classes:
Class 1— a content or function change that corrects an error or enhances local content or
functionality
Class 2—a content or function change that has an impact on other content objects or
functional components
Class 3—a content or function change that has a broad impact across a WebApp (e.g., major
extension of functionality, significant enhancement or reduction in content, major required
changes in navigation)
Class 4—a major design change (e.g., a change in interface design or navigation approach)
that will be immediately noticeable to one or more categories of user
Once the requested change has been categorized, it can be processed according to the
algorithm set.

3.3.3.4 VERSION CONTROL

In an uncontrolled site where multiple authors have access to edit and contribute, the
potential for conflict and problems arises—more so when these authors work from different
offices at different times of day and night. One may spend the day improving the file
index.html for a customer. After changes are done, another developer who works at home
after hours, or in another office, may spend the night uploading their own newly revised
version of the file index.html, completely overwriting previous work with no way to get it
back! To avoid it, a version control process is required…

1. A central repository for the WebApp project should be established. The repository
will hold current versions of all WebApp configuration objects (content, functional
components, and others).

54
 2. Each Web engineer creates his or her own working folder. The folder contains those
objects that are being created or changed at any given time

3. The clocks on all developer workstations should be synchronized. This is done to

avoid overwriting conflicts when two developers make updates that are very close to
one another in time.

4. As new configuration objects are developed or existing objects are changed, they are
imported into the central repository. The version control tool (see discussion of CVS
in the sidebar) will manage all check-in and check-out functions from the working
folders of each WebApp developer. The tool will also provide automatic e-mail
updates to all interested parties when changes to the repository are made.

5. As objects are imported or exported from the repository, an automatic, timestamped

log message is made. This provides useful information for auditing and can become
part of an effective reporting scheme.

The version control tool maintains different versions of the WebApp and can revert to an
older version if required.

3.3.3.5 AUDITING AND REPORTING

In the interest of agility, the auditing and reporting functions are deemphasized in Web
engineering work. However, they are not eliminated altogether. All objects that are checked
into or out of the repository are recorded in a log that can be reviewed at any point in time. A
complete log report can be created so that all members of the WebApp team have a
chronology of changes over a defined period of time. In addition, an automated e-mail
notification (addressed to those developers and stakeholders who have interest) can be sent
every time an object is checked in or out of the repository.

3.4 SOFTWARE TESTING STRATEGIES

3.4.1 A Strategic Approach to Software Testing

Testing is a set of activities that can be planned in advance and conducted systematically. For
this reason a template for software testing—a set of steps into which you can place specific
test case design techniques and testing methods—should be defined for the software process.

A number of software testing strategies have been proposed in the literature. A template is
provided and all have the following generic characteristics:

55
  To perform effective testing, one should conduct effective technical reviews. By
doing this, many errors will be eliminated before testing commences.
 Testing begins at the component level and works “outward” toward the integration of
the entire computer-based system.
 Different testing techniques are appropriate for different software engineering
approaches and at different points in time.
 Testing is conducted by the developer of the software and (for large projects) an
independent test group.
 Testing and debugging are different activities, but debugging must be accommodated
in any testing strategy.

A strategy for software testing must accommodate low-level tests that are necessary to verify
that a small source code segment has been correctly implemented as well as high-level tests
that validate major system functions against customer requirements. A strategy should
provide guidance for the practitioner and a set of milestones for the manager. Because the
steps of the test strategy occur at a time when deadline pressure begins to rise, progress must
be measurable and problems should surface as early as possible.

3.4.1.1 VERIFICATION AND VALIDATION

Verification refers to the set of tasks that ensure that software correctly implements a specific
function. Validation refers to a different set of tasks that ensure that the software that has
been built is traceable to customer requirements.

Verification and validation includes a wide array of SQA activities: technical reviews, quality
and configuration audits, performance monitoring, simulation, feasibility study,
documentation review, database review, algorithm analysis, development testing, usability
testing, qualification testing, acceptance testing, and installation testing. Although testing
plays an extremely important role in V&V, many other activities are also necessary.

3.4.1.2 SOFTWARE TESTING STRATEGY – THE BIG PICTURE

The software process may be viewed as the spiral illustrated in Figure 3.2. Initially, system
engineering defines the role of software and leads to software requirements analysis, where
the information domain, function, behaviour, performance, constraints, and validation criteria
for software are established. Moving inward along the spiral, you come to design and finally

56
to coding. To develop computer software, you spiral inward (counter clockwise) along
streamlines that decrease the level of abstraction on each turn.

Figure – 3.2 – Software Testing Strategy

A strategy for software testing may also be viewed in the context of the spiral (Figure 3.2).
Unit testing begins at the vortex of the spiral and concentrates on each unit (e.g., component,
class, or WebApp content object) of the software as implemented in source code. Testing
progresses by moving outward along the spiral to integration testing, where the focus is on
design and the construction of the software architecture. Taking another turn outward on the
spiral, you encounter validation testing, where requirements established as part of
requirements modeling are validated against the software that has been constructed. Finally,
arrives system testing, where the software and other system elements are tested as a whole.
To test computer software, you spiral out in a clockwise direction along streamlines that
broaden the scope of testing with each turn.

Considering the process from a procedural point of view, testing within the context of
software engineering is actually a series of four steps that are implemented sequentially.

The steps are shown in Figure 3.3. Initially, tests focus on each component individually,
ensuring that it functions properly as a unit. Hence, the name unit testing. Unit testing makes
heavy use of testing techniques that exercise specific paths in a component’s control structure
to ensure complete coverage and maximum error detection. Next, components must be
assembled or integrated to form the complete software package. Integration testing addresses
the issues associated with the dual problems of verification and program construction. Test
case design techniques that focus on inputs and outputs are more prevalent during integration,

57
although techniques that exercise specific program paths may be used to ensure coverage of
major control paths. After the software has been integrated (constructed), a set of high-order
tests is conducted. Validation criteria (established during requirements analysis) must be
evaluated. Validation testing provides final assurance that software meets all informational,
functional, behavioural, and performance requirements.

Figure 3.3 – Software Testing Steps

The last high-order testing step falls outside the boundary of software engineering and into
the broader context of computer system engineering. Software, once validated, must be
combined with other system elements (e.g., hardware, people, databases). System testing
verifies that all elements mesh properly and that overall system function/performance is
achieved.

3.4.2 STRATEGIC ISSUES

According to Tom Gilb a software testing strategy will succeed when software testers:

Specify product requirements in a quantifiable manner long before testing commences.

Although the overriding objective of testing is to find errors, a good testing strategy also
assesses other quality characteristics such as portability, maintainability, and usability. These
should be specified in a way that is measurable so that testing results are unambiguous.

State testing objectives explicitly. The specific objectives of testing should be stated in
measurable terms. For example, test effectiveness, test coverage, meantime-to-failure, the

58
cost to find and fix defects, remaining defect density or frequency of occurrence, and test
work-hours should be stated within the test plan.

Understand the users of the software and develop a profile for each user category. Use cases
that describe the interaction scenario for each class of user can reduce overall testing effort by
focusing testing on actual use of the product.

Develop a testing plan that emphasizes “rapid cycle testing.” Gilb recommends that a
software team “learn to test in rapid cycles (2 percent of project effort) of customer-useful, at
least field ‘trialable,’ increments of functionality and/or quality improvement.” The feedback
generated from these rapid cycle tests can be used to control quality levels and the
corresponding test strategies.

Build “robust” software that is designed to test itself. Software should be designed in a
manner that uses antibugging techniques. That is, software should be capable of diagnosing
certain classes of errors. In addition, the design should accommodate automated testing and
regression testing.

Use effective technical reviews as a filter prior to testing. Technical reviews can be as
effective as testing in uncovering errors. For this reason, reviews can reduce the amount of
testing effort that is required to produce high quality software.

Conduct technical reviews to assess the test strategy and test cases themselves. Technical
reviews can uncover inconsistencies, omissions, and outright errors in the testing approach.
This saves time and also improves product quality.

Develop a continuous improvement approach for the testing process. The test strategy should
be measured. The metrics collected during testing should be used as part of a statistical
process control approach for software testing.

3.4.3 TEST STRATEGIES FOR CONVENTIONAL SOFTWARE

A testing strategy that is chosen by most software teams falls between the two extremes. It
takes an incremental view of testing, beginning with the testing of individual program units,
moving to tests designed to facilitate the integration of the units, and culminating with tests
that exercise the constructed system. Each of these classes of tests is described in the sections
that follow.

59
UNIT TESTING

Unit testing focuses verification effort on the smallest unit of software design—the software
component or module. Using the component-level design description as a guide, important
control paths are tested to uncover errors within the boundary of the module. The relative
complexity of tests and the errors those tests uncover is limited by the constrained scope
established for unit testing. The unit test focuses on the internal processing logic and data
structures within the boundaries of a component. This type of testing can be conducted in
parallel for multiple components.

INTEGRATION TESTING

Integration testing is a systematic technique for constructing the software architecture while
at the same time conducting tests to uncover errors associated with interfacing. The objective
is to take unit-tested components and build a program structure that has been dictated by
design.

There is often a tendency to attempt non incremental integration; that is, to construct the
program using a “big bang” approach. All components are combined in advance. The entire
program is tested as a whole. And chaos usually results! A set of errors is encountered.
Correction is difficult because isolation of causes is complicated by the vast expanse of the
entire program. Once these errors are corrected, new ones appear and the process continues in
a seemingly endless loop.

Incremental integration is the antithesis of the big bang approach. The program is constructed
and tested in small increments, where errors are easier to isolate and correct; interfaces are
more likely to be tested completely; and a systematic test approach may be applied.

3.4.4 VALIDATION TESTING

Validation testing begins at the culmination of integration testing, when individual

components have been exercised, the software is completely assembled as a package, and
interfacing errors have been uncovered and corrected. At the validation or system level, the
distinction between conventional software, object-oriented software, and WebApps
disappears. Testing focuses on user-visible actions and user-recognizable output from the
system.

Validation can be defined in many ways, but a simple (albeit harsh) definition is that
validation succeeds when software functions in a manner that can be reasonably expected by

60
the customer. At this point a battle-hardened software developer might protest: “Who or what
is the arbiter of reasonable expectations?” If a Software Requirements Specification has been
developed, it describes all user-visible attributes of the software and contains a Validation
Criteria section that forms the basis for a validation-testing approach.

After each validation test case has been conducted, one of two possible conditions exists:

1. The function or performance characteristic conforms to specification and is accepted

or
2. A deviation from specification is uncovered and a deficiency list is created.

Deviations or errors discovered at this stage in a project can rarely be corrected prior to
scheduled delivery. It is often necessary to negotiate with the customer to establish a method
for resolving deficiencies.

3.4.5 SYSTEM TESTING

System testing is actually a series of different tests whose primary purpose is to fully exercise
the computer-based system. Although each test has a different purpose, all work to verify that
system elements have been properly integrated and perform allocated functions. In the
sections that follow, I discuss the types of system tests that are worthwhile for software-based
systems.

3.4.5.1 RECOVERY TESTING

Recovery testing is a system test that forces the software to fail in a variety of ways and
verifies that recovery is properly performed. If recovery is automatic (performed by the
system itself), re-initialization, check-pointing mechanisms, data recovery, and restart are
evaluated for correctness. If recovery requires human intervention, the mean-time-to-repair
(MTTR) is evaluated to determine whether it is within acceptable limits

3.4.5.2 SECURITY TESTING

Security testing attempts to verify that protection mechanisms built into a system will, in fact,
protect it from improper penetration. During security testing, the tester plays the role(s) of the
individual who desires to penetrate the system. Anything goes! The tester may attempt to
acquire passwords through external clerical means; may attack the system with custom
software designed to break down any defenses that have been constructed; may overwhelm
the system, thereby denying service to others; may purposely cause system errors, hoping to

61
penetrate during recovery; may browse through insecure data, hoping to find the key to
system entry.

Given enough time and resources, good security testing will ultimately penetrate a system.
The role of the system designer is to make penetration cost more than the value of the
information that will be obtained.

3.4.5.3 STRESS TESTING

Stress testing executes a system in a manner that demands resources in abnormal quantity,
frequency, or volume. For example, (1) special tests may be designed that generate ten
interrupts per second, when one or two is the average rate, (2) input data rates may be
increased by an order of magnitude to determine how input functions will respond, (3) test
cases that require maximum memory or other resources are executed, (4) test cases that may
cause thrashing in a virtual operating system are designed, (5) test cases that may cause
excessive hunting for disk-resident data are created. Essentially, the tester attempts to break
the program.

A variation of stress testing is a technique called sensitivity testing. In some situations (the
most common occur in mathematical algorithms), a very small range of data contained within
the bounds of valid data for a program may cause extreme and even erroneous processing or
profound performance degradation. Sensitivity testing attempts to uncover data combinations
within valid input classes that may cause instability or improper processing.

3.4.5.4 PERFORMANCE TESTING

Performance testing is designed to test the run-time performance of software within the
context of an integrated system. Performance testing occurs throughout all steps in the testing
process. Even at the unit level, the performance of an individual module may be assessed as
tests are conducted. However, it is not until all system elements are fully integrated that the
true performance of a system can be ascertained.

Performance tests are often coupled with stress testing and usually require both hardware and
software instrumentation. That is, it is often necessary to measure resource utilization (e.g.,
processor cycles) in an exacting fashion. External instrumentation can monitor execution
intervals, log events (e.g., interrupts) as they occur, and sample machine states on a regular
basis. By instrumenting a system, the tester can uncover situations that lead to degradation
and possible system failure.

62
3.4.5.5 DEPLOYMENT TESTING

In many cases, software must execute on a variety of platforms and under more than one
operating system environment. Deployment testing, sometimes called configuration testing,
exercises the software in each environment in which it is to operate. In addition, deployment
testing examines all installation procedures and specialized installation software (e.g.,
“installers”) that will be used by customers, and all documentation that will be used to
introduce the software to end users.

As an example, consider the Internet-accessible version of SafeHome software that would

allow a customer to monitor the security system from remote locations. The SafeHome
WebApp must be tested using all Web browsers that are likely to be encountered. A more
thorough deployment test might encompass combinations of Web browsers with various
operating systems (e.g., Linux, Mac OS, Windows). Because security is a major issue, a
complete set of security tests would be integrated with the deployment test.

3.4.6 THE ART OF DEBUGGING

Debugging is not testing but often occurs as a consequence of testing. Referring to Figure 3.4,
the debugging process begins with the execution of a test case. Results are assessed and a
lack of correspondence between expected and actual performance is encountered. In many
cases, the noncorresponding data are a symptom of an underlying cause as yet hidden. The
debugging process attempts to match symptom with cause, thereby leading to error
correction.

Figure 3.4 – Debugging Process

63
Below given are some of the characteristics of the bugs that would provide some clues:
1. The symptom and the cause may be geographically remote. That is, the symptom may
appear in one part of a program, while the cause may actually be located at a site that is
far removed. Highly coupled components exacerbate this situation.
2. The symptom may disappear (temporarily) when another error is corrected.
3. The symptom may actually be caused by non-errors (e.g., round-off inaccuracies).
4. The symptom may be caused by human error that is not easily traced
5. The symptom may be a result of timing problems, rather than processing problems.
6. It may be difficult to accurately reproduce input conditions (e.g., a real-time application
in which input ordering is indeterminate).
7. The symptom may be intermittent. This is particularly common in embedded systems that
couple hardware and software inextricably.
8. The symptom may be due to causes that are distributed across a number of tasks running
on different processors

3.4.6.1 CORRECTING THE ERROR

Once a bug has been found, it must be corrected. But, as we have already noted, the
correction of a bug can introduce other errors and therefore do more harm than good. Van
Vleck suggests three simple questions that you should ask before making the “correction”
that removes the cause of a bug:
 Is the cause of the bug reproduced in another part of the program? In many situations,
a program defect is caused by an erroneous pattern of logic that may be reproduced
elsewhere. Explicit consideration of the logical pattern may result in the discovery of
other errors.
 What “next bug” might be introduced by the fix I’m about to make? Before the
correction is made, the source code (or, better, the design) should be evaluated to
assess coupling of logic and data structures. If the correction is to be made in a highly
coupled section of the program, special care must be taken when any change is made.
 What could we have done to prevent this bug in the first place? This question is the
first step toward establishing a statistical software quality assurance approach
(Chapter 16). If you correct the process as well as the product, the bug will be
removed from the current program and may be eliminated from all future programs.

64
3.5 THE CLEANROOM STRATEGY

The philosophy behind cleanroom software engineering is to develop code increments

that are right the first time and verify their correctness before testing, rather than relying on
costly defect removal processes. Cleanroom software engineering involves the integrated use
of software engineering modeling, program verification, and statistical software quality
assurance. Under cleanroom software engineering, the analysis and design models are created
using a box structure representation (black-box, state box, and clear box). A box encapsulates
some system component at a specific level of abstraction. Correctness verification is applied
once the box structure design is complete. Once correctness has been verified for each box
structure, statistical usage testing commences. This involves defining a set of usage scenarios
and determining the probability of use for each scenario. Random data is generated which
conform to the usage probabilities. The resulting error records are analysed, and the
reliability of the software is determined for the software component.

Distinguishing Characteristics of Cleanroom Techniques

 Makes extensive use of statistical quality control

 Verifies design specification using mathematically-based proof of correctness

 Relies heavily on statistical use testing to uncover high impact errors

Cleanroom Strategy

 Increment planning. The project plan is built around the incremental strategy.
 Requirements gathering. customer requirements are refined for each increment.
 Box structure specification. Box structures isolate and separate the definition of
behaviour, data, and procedures at each level of refinement.
 Formal design. Specifications (black-boxes) are iteratively refined to become
architectural designs (state-boxes) and component-level designs (clear boxes).
 Correctness verification. Correctness questions are asked and answered and followed
by formal mathematical verification when required.
 Code generation, inspection, verification. Box structures are translated into program
language; inspections are used to ensure conformance of code and boxes, as well as
syntactic correctness of code; followed by correctness verification of the code.
 Statistical test planning. A suite of test cases is created to match the probability
distribution of the projected product usage pattern.

65
  Statistical use testing. A statistical sample of all possible test cases is used rather than
exhaustive testing.
 Certification. Once verification, inspection, and usage testing are complete and all
defects removed, the increment is certified as ready for integration.

3.6 CHECK YOUR PROGRESS

1. What is the process each manager follows during the life of a project is known as
A. Project Management
B. Project Management Life Cycle
C. Manager life cycle
D. All of the mentioned

2. What is the abbreviation of PM-CMM?

A. product management capability maturity model
B. process management capability maturity model
C. people management capability maturity model
D. project management capability maturity model

3. Software Configuration Management can be administered in several ways. These include

a) A single software configuration management team for the whole organization
b) A separate configuration management team for each project
c) Software Configuration Management distributed among the project members
d) All of the mentioned

4. The main aim of Software Configuration Management (SCM) is _____

a. Identify change
b. Control change
c. To ensure that the change is being properly implemented
d. All of these
e. None of these

5. Identify the term which is not related to testing?

a. Failure
b. Error
c. Test Case
d. Test Bot

66
6. Which of the following is not a valid phase of SDLC (Software Development Life
Cycle)?
a. Testing Phase
b. Requirement Phase
c. Deployment phase
d. Testing closure

Answers to check your progress:

1. B
2. C
3. A
4. D
5. D
6. D

3.7 SUMMARY

The Management Spectrum focuses on the four P’s: people, product, process, and
project. It emphasizes on the importance of these 4 parameters in building a successful and
robust team and process in software project management.
The software configuration management process identifies the functional and physical
attributes of software at critical points in time, and implements procedures to control changes
to an identified attribute with the objective of maintaining software integrity and traceability
throughout the software life cycle.
Software Testing Strategies include set of guidelines that explains test design and determines
how testing needs to be done. Also it includes Components of Test plan Test plan id, features
to be tested, test techniques, testing tasks, features pass or fail criteria, test deliverables,
responsibilities, and schedule, etc.

3.8 KEYWORDS

 Project scope: It is the common understanding among stakeholders about what goes into
a project and the factors that define its success.
 Problem decomposition: It is an activity that sits at the core of software requirements
analysis.
 Stakeholders: They are those with an interest in your project's outcome.
67
 Software Configuration Management: This is a process to systematically manage,
organize, and control the changes in the documents, codes, and other entities during the
Software Development Life Cycle.

3.9 QUESTIONS FOR SELF STUDY

1. Who are the different categories people who play a major role in Management spectrum?
Explain each one's role briefly.
2. Why is it important to define the scope of the product?
3. What are the steps to be followed while defining the process?
4. Explain five-part common sense approach to software projects
5. Describe explain SCM Scenario along with elements.
6. What are the four primary objectives of SCM?
7. Briefly explain the different phases of Configuration Management.
8. Define each of the topic given below:
a. Big Picture of Software Testing Strategies
b. Unit Testing and Integration Testing in OO context
c. Test Strategeis for WebApps
d. Distinguish between Recovery testing, Security Testing, Performance Testing,
Deployment Testing
e. The cleanroom strategy

3.10 REFERENCES

1. https://ocw.ui.ac.id/pluginfile.php/13396/mod_resource/content/2/Schwalbe%208th%20-
%20Chapter%2002.pdf
2. https://www.tpptechnology.com/
3. https://mymanagementguide.com/

68
UNIT-4: SOFTWARE QUALITY MANAGEMENT

STRUCTURE

4.0 Objectives
4.1 Introduction
4.2 Quality Concepts
4.2.1 Software Quality
4.2.2 Achieving Software Quality
4.3 Review Techniques
4.3.1 Cost Impact of Software Defects
4.3.2 Review Metrics and their Use
4.3.3 Informal Reviews
4.3.4 Formal Reviews
4.4 Software Quality Assurance - SQA
4.4.1 Elements of SQA
4.4.2 Statistical SQA
4.4.3 Software Reliability
4.4.4 ISO 9000 Quality Standards
4.5 Check your progress
4.6 Summary
4.7 Key words
4.8 Questions for self-study
4.9 References

4.0 OBJECTIVES

After studying this unit, you will be able to:

 Describe quality management processes, SQA concepts and principles

 Distinguish between various activities of quality planning, quality management and
quality control
 Understand the importance and standards of quality management process and their
impact on final products.

69
4.1 INTRODUCTION

In this unit, we are going to discuss about software quality management. A wide variety
of software quality dimensions and factors have been proposed over the years. All try to
define a set of characteristics that, if achieved, will lead to high software quality. McCall’s
and the ISO 9126 quality factors establish characteristics such as reliability, usability,
maintainability, functionality, and portability as indicators that quality exists.

4.2 QUALITY CONCEPTS

Software quality product is defined in term of its fitness of purpose. That is, a quality
product does precisely what the users want it to do. For software products, the fitness of use
is generally explained in terms of satisfaction of the requirements laid down in the SRS
document. Although "fitness of purpose" is a satisfactory interpretation of quality for many
devices such as a car, a table fan, a grinding machine, etc., for software products, "fitness of
purpose" is not a wholly satisfactory definition of quality.

Software Quality Assurance (SQA) is a planned and systematic pattern of activities that are
necessary to provide a high degree of confidence regarding quality of a product. It actually
provides or gives a quality assessment of quality control activities and helps in determining
validity of data or procedures for determining quality. It generally monitors software
processes and methods that are used in a project to ensure or assure and maintain quality of
software.

4.2.1 SOFTWARE QUALITY

The relevancy of Software quality in modern times is increasing like anything. Nowadays
software development companies are more focussed on deploying new codes into production
even on an hourly basis without any proper software testing. That’s creating a chaotic
environment in the market.

People often fail to understand that speed has minimal value if there is no quality. let’s learn
how to ensure software quality in every build

What is software quality? The quality of software can be defined as the ability of the software
to function as per user requirement. When it comes to software products it must satisfy all
the functionalities written down in the SRS document.

70
Key aspects that conclude software quality include,

 Good design – It’s always important to have a good and aesthetic design to please
users
 Reliability – Be it any software it should be able to perform the functionality
impeccably without issues
 Durability- Durability is a confusing term, In this context, durability means the
ability of the software to work without any issue for a long period of time.
 Consistency – Software should be able to perform consistently over platform and
devices
 Maintainability – Bugs associated with any software should be able to capture and
fix quickly and news tasks and enhancement must be added without any trouble
 Value for money – customer and companies who make this app should feel that the
money spent on this app has not done to waste.

ISO 9126 QUALITY FACTORS

The ISO 9126 standard was developed in an attempt to identify the key quality attributes
for computer software. The standard identifies six key quality attributes:
 Functionality. The degree to which the software satisfies stated needs as indicated
by the following sub attributes: suitability, accuracy, interoperability, compliance,
and security.
 Reliability. The amount of time that the software is available for use as indicated
by the following sub attributes: maturity, fault tolerance, recoverability
 Usability. The degree to which the software is easy to use as indicated by the
following sub attributes: understandability, learnability, operability.
 Efficiency. The degree to which the software makes optimal use of system
resources as indicated by the following sub attributes: time behavior, resource
behavior.
 Maintainability. The ease with which repair may be made to the software as
indicated by the following sub attributes: analysability, changeability, stability,
testability.
 Portability. The ease with which the software can be transposed from one
environment to another as indicated by the following sub attributes: adaptability,
installability, conformance, replaceability

71
Like other software quality factors discussed in the preceding subsections, the ISO 9126
factors do not necessarily lend themselves to direct measurement. However, they do provide a
worthwhile basis for indirect measures and an excellent checklist for assessing the quality of a
system.

TARGETED QUALITY FACTORS

The quality dimensions and factors focus on the software as a whole and can be used as a
generic indication of the quality of an application. A software team can develop a set of
quality characteristics and associated questions that would probe the degree to which each
factor has been satisfied.

For example, McCall identifies usability as an important quality factor. If you were asked to
review a user interface and assess its usability, how would you proceed? You might start with
the sub attributes suggested by McCall—understandability, learnability, and operability—but
what do these mean in a pragmatic sense? To conduct your assessment, you’ll need to address
specific, measurable (or at least, recognizable) attributes of the interface as given below:

Intuitiveness. The degree to which the interface follows expected usage patterns so that even
a novice can use it without significant training.
 Is the interface layout conducive to easy understanding?
 Are interface operations easy to locate and initiate?
 Does the interface use a recognizable metaphor?
 Is input specified to economize key strokes or mouse clicks?
 Does the interface follow the three golden rules?
 Do aesthetics aid in understanding and usage?

Efficiency. The degree to which operations and information can be located or initiated.
 Does the interface layout and style allow a user to locate operations and information
efficiently?
 Can a sequence of operations (or data input) be performed with an economy of
motion?
 Are output data or content presented so that it is understood immediately?
 Have hierarchical operations been organized in a way that minimizes the depth to
which a user must navigate to get something done?

72
Robustness. The degree to which the software handles bad input data or inappropriate user
interaction.
 Will the software recognize the error if data at or just outside prescribed boundaries is
input? More importantly, will the software continue to operate without failure or
degradation?
 Will the interface recognize common cognitive or manipulative mistakes and
explicitly guide the user back on the right track?
 Does the interface provide useful diagnosis and guidance when an error condition
(associated with software functionality) is uncovered?

Richness. The degree to which the interface provides a rich feature set.
 Can the interface be customized to the specific needs of a user?
 Does the interface provide a macro capability that enables a user to identify a
sequence of common operations with a single action or command?

4.2.2 ACHIEVING SOFTWARE QUALITY

Software quality doesn’t just appear. It is the result of good project management and solid
software engineering practice. Management and practice are applied within the context of
four broad activities that help a software team achieve high software quality: software
engineering methods, project management techniques, quality control actions, and software
quality assurance.

SOFTWARE ENGINEERING METHODS

If you expect to build high-quality software, you must understand the problem to be solved.
You must also be capable of creating a design that conforms to the problem while at the same
time exhibiting characteristics that lead to software that exhibits the quality dimensions and
factors.

PROJECT MANAGEMENT TECHNIQUES

The impact of poor management decisions on software quality is as follows: if (1) a project
manager uses estimation to verify that delivery dates are achievable, (2) schedule
dependencies are understood and the team resists the temptation to use short cuts, (3) risk
planning is conducted so problems do not breed chaos, software quality will be affected in a

73
positive way. In addition, the project plan should include explicit techniques for quality and
change management.

QUALITY CONTROL

Quality control encompasses a set of software engineering actions that help to ensure that
each work product meets its quality goals. Models are reviewed to ensure that they are
complete and consistent. Code may be inspected in order to uncover and correct errors before
testing commences. A series of testing steps is applied to uncover errors in processing logic,
data manipulation, and interface communication. A combination of measurement and
feedback allows a software team to tune the process when any of these work products fail to
meet quality goals.

QUALITY ASSURANCE

Quality assurance establishes the infrastructure that supports solid software engineering
methods, rational project management, and quality control actions—all pivotal if you intend
to build high-quality software. In addition, quality assurance consists of a set of auditing and
reporting functions that assess the effectiveness and completeness of quality control actions.
The goal of quality assurance is to provide management and technical staff with the data
necessary to be informed about product quality, thereby gaining insight and confidence that
actions to achieve product quality are working. Of course, if the data provided through
quality assurance identifies problems, it is management’s responsibility to address the
problems and apply the necessary resources to resolve quality issues.

4.3 REVIEW TECHNIQUES

Software reviews are a “filter” for the software process. That is, reviews are applied at
various points during software engineering and serve to uncover errors and defects that can
then be removed. Software reviews “purify” software engineering work products, including
requirements and design models, code, and testing data.

4.3.1 COST IMPACT OF SOFTWARE DEFECTS

Within the context of the software process, the terms defect and fault are synonymous. Both
imply a quality problem that is discovered after the software has been released to end users
(or to another framework activity in the software process). The term error depicts a quality

74
problem that is discovered by software engineers (or others) before the software is released to
the end user (or to another framework activity in the software process).

The primary objective of technical reviews is to find errors during the process so that they do
not become defects after release of the software. The obvious benefit of technical reviews is
the early discovery of errors so that they do not propagate to the next step in the software
process. A number of industry studies indicate that design activities introduce between 50 and
65 percent of all errors (and ultimately, all defects) during the software process. However,
review techniques have been shown to be up to 75 percent effective in uncovering design
flaws. By detecting and removing a large percentage of these errors, the review process
substantially reduces the cost of subsequent activities in the software process.

4.3.2 REVIEW METRICS AND THEIR USE

Technical reviews are one of many actions that are required as part of good software
engineering practice. Each action requires dedicated human effort, Since available project
effort is finite, it is important for a software engineering organization to understand the
effectiveness of each action by defining a set of metrics that can be used to assess their
efficacy.

Although many metrics can be defined for technical reviews, a relatively small subset can
provide useful insight. The following review metrics can be collected for each review that is
conducted:

Preparation effort, Ep—the effort (in person-hours) required to review a work product prior
to the actual review meeting

Assessment effort, Ea—the effort (in person-hours) that is expended during the actual review

Rework effort, Er—the effort (in person-hours) that is dedicated to the correction of those
errors uncovered during the review

Work product size, WPS—a measure of the size of the work product that has been reviewed
(e.g., the number of UML models, or the number of document pages, or the number of lines
of code)

Minor errors found, Err minor—the number of errors found that can be categorized as minor
(requiring less than some prespecified effort to correct)

75
Major errors found, Errmajor—the number of errors found that can be categorized as major
(requiring more than some prespecified effort to correct)

These metrics can be further refined by associating the type of work product that was
reviewed for the metrics collected.

4.3.3 ANALYZING METRICS

Before analysis can begin, a few simple computations must occur. The total review effort and
the total number of errors discovered are defined as:

Ereview = Ep + Ea + Er

Errtot = Errminor + Errmajor

Error density represents the errors found per unit of work product reviewed.

Error density = Errtot / WPS

For example, if a requirements model is reviewed to uncover errors, inconsistencies, and

omissions, it would be possible to compute the error density in a number of different ways.
The requirements model contains 18 UML diagrams as part of 32 overall pages of descriptive
materials. The review uncovers 18 minor errors and 4 major errors. Therefore, Errtot 22.
Error density is 1.2 errors per UML diagram or 0.68 errors per requirements model page.

If reviews are conducted for a number of different types of work products (e.g., requirements
model, design model, code, test cases), the percentage of errors uncovered for each review
can be computed against the total number of errors found for all reviews. In addition, the
error density for each work product can be computed.

Once data are collected for many reviews conducted across many projects, average values for
error density enable you to estimate the number of errors to be found in a new (as yet
unreviewed document). For example, if the average error density for a requirements model is
0.6 errors per page, and a new requirement model is 32 pages long, a rough estimate suggests
that your software team will find about 19 or 20 errors during the review of the document. If
you find only 6 errors, you’ve done an extremely good job in developing the requirements
model or your review approach was not thorough enough.

76
4.3.4 INFORMAL REVIEWS

Informal reviews include a simple desk check of a software engineering work product with a
colleague, a casual meeting (involving more than two people) for the purpose of reviewing a
work product, or the review-oriented aspects of pair programming.

A simple desk check or a casual meeting conducted with a colleague is a review. However,
because there is no advance planning or preparation, no agenda or meeting structure, and no
follow-up on the errors that are uncovered, the effectiveness of such reviews is considerably
lower than more formal approaches. But a simple desk check can and does uncover errors
that might otherwise propagate further into the software process

Pair programming can be characterized as a continuous desk check. Rather than scheduling a
review at some point in time, pair programming encourages continuous review as a work
product (design or code) is created. The benefit is immediate discovery of errors and better
work product quality as a consequence.

4.3.5 FORMAL TECHNICAL REVIEWS

A formal technical review (FTR) is a software quality control activity performed by software
engineers (and others).

The objectives of an FTR are:

 To uncover errors in function, logic, or implementation for any representation of the

software;
 To verify that the software under review meets its requirements; (
 To ensure that the software has been represented according to predefined standards;
 To achieve software that is developed in a uniform manner; and
 To make projects more manageable. In addition, the FTR serves as a training ground,
enabling junior engineers to observe different approaches to software analysis, design,
and implementation.

The FTR also serves to promote backup and continuity because a number of people become
familiar with parts of the software that they may not have otherwise seen. The FTR is
actually a class of reviews that includes walkthroughs and inspections. Each FTR is
conducted as a meeting and will be successful only if it is properly planned, controlled, and
attended. In the sections that follow, guidelines similar to those for a walkthrough are
presented as a representative formal technical review.

77
THE REVIEW MEETING

Regardless of the FTR format that is chosen, every review meeting should abide by the
following constraints:

 Between three and five people (typically) should be involved in the review.
 Advance preparation should occur but should require no more than two hours of
work for each person.
 The duration of the review meeting should be less than two hours.

Given these constraints, it should be obvious that an FTR focuses on a specific (and small)
part of the overall software. For example, rather than attempting to review an entire design,
walkthroughs are conducted for each component or small group of components. By
narrowing the focus, the FTR has a higher likelihood of uncovering errors.

The review meeting is attended by the review leader, all reviewers, and the producer. One of
the reviewers takes on the role of a recorder, that is, the individual who records (in writing)
all important issues raised during the review. The FTR begins with an introduction of the
agenda and a brief introduction by the producer. The producer then proceeds to “walk
through” the work product, explaining the material, while reviewers raise issues based on
their advance preparation. When valid problems or errors are discovered, the recorder notes
each.

At the end of the review, all attendees of the FTR must decide whether to:

(1) accept the product without further modification,

(2) reject the product due to severe errors (once corrected, another review must be
performed), or
(3) accept the product provisionally (minor errors have been encountered and must be
corrected, but no additional review will be required).

After the decision is made, all FTR attendees complete a sign-off, indicating their
participation in the review and their concurrence with the review team’s findings.

REVIEW REPORTING AND RECORD KEEPING

During the FTR, a reviewer (the recorder) actively records all issues that have been raised.
These are summarized at the end of the review meeting, and a review issues list is produced.
In addition, a formal technical review summary report is completed.

78
A review summary report answers three questions:

1. What was reviewed?

2. Who reviewed it?
3. What were the findings and conclusions?

The review summary report is a single page form (with possible attachments). It becomes
part of the project historical record and may be distributed to the project leader and other
interested parties.

The review issues list serves two purposes:

(1) To identify problem areas within the product and

(2) To serve as an action item checklist that guides the producer as corrections are made. An
issues list is normally attached to the summary report that should be ensured with follow up
procedure.

REVIEW GUIDELINES

Guidelines for conducting formal technical reviews must be established in advance,

distributed to all reviewers, agreed upon, and then followed. A review that is uncontrolled
can often be worse than no review at all.

The following represents a minimum set of guidelines for formal technical reviews:

1. Review the product, not the producer. An FTR involves people and egos. Conducted
properly, the FTR should leave all participants with a warm feeling of accomplishment.
Conducted improperly, the FTR can take on the aura of an inquisition. Errors should be
pointed out gently; the tone of the meeting should be loose and constructive; the intent
should not be to embarrass or belittle. The review leader should conduct the review
meeting to ensure that the proper tone and attitude are maintained and should
immediately halt a review that has gotten out of control.

2. Set an agenda and maintain it. One of the key maladies of meetings of all types is drift.
An FTR must be kept on track and on schedule. The review leader is chartered with the
responsibility for maintaining the meeting schedule and should not be afraid to nudge
people when drift sets in.

79
3. Limit debate and rebuttal. When an issue is raised by a reviewer, there may not be
universal agreement on its impact. Rather than spending time debating the question, the
issue should be recorded for further discussion off-line.

4. Enunciate problem areas, but don’t attempt to solve every problem noted. A review is not
a problem-solving session. The solution of a problem can often be accomplished by the
producer alone or with the help of only one other individual. Problem solving should be
postponed until after the review meeting.

5. Take written notes. It is sometimes a good idea for the recorder to make notes on a wall
board, so that wording and priorities can be assessed by other reviewers as information is
recorded. Alternatively, notes may be entered directly into a notebook computer.

6. Limit the number of participants and insist upon advance preparation. Two heads are
better than one, but 14 are not necessarily better than 4. Keep the number of people
involved to the necessary minimum. However, all review team members must prepare in
advance. Written comments should be solicited by the review leader (providing an
indication that the reviewer has reviewed the material).

7. Develop a checklist for each product that is likely to be reviewed. A checklist helps the
review leader to structure the FTR meeting and helps each reviewer to focus on important
issues. Checklists should be developed for analysis, design, code, and even testing work
products.

8. Allocate resources and schedule time for FTRs. For reviews to be effective, they should
be scheduled as tasks during the software process. In addition, time should be scheduled
for the inevitable modifications that will occur as the result of an FTR.

9. Conduct meaningful training for all reviewers. To be effective all review participants
should receive some formal training. The training should stress both process-related
issues and the human psychological side of reviews. Freedman and Weinberg [Fre90]
estimate a one-month learning curve for every 20 people who are to participate
effectively in reviews.

10. Review your early reviews. Debriefing can be beneficial in uncovering problems with the
review process itself. The very first product to be reviewed should be the review
guidelines themselves.

80
Because many variables (e.g., number of participants, type of work products, timing and
length, specific review approach) have an impact on a successful review, a software
organization should experiment to determine what approach works best in a local context.

4.4 SOFTWARE QUALITY ASSURANCE - SQA

Software quality assurance (SQA) encompasses

(1) An SQA process,
(2) Specific quality assurance and quality control tasks (including technical reviews and a
multitiered testing strategy),
(3) Effective software engineering practice (methods and tools),
(4) Control of all software work products and the changes made to them,
(5) A procedure to ensure compliance with software development standards (when
applicable), and
(6) Measurement and reporting mechanisms.

4.4.1 ELEMENTS OF SQA

Software quality assurance encompasses a broad range of concerns and activities that focus
on the management of software quality.

Standards. The IEEE, ISO, and other standards organizations have produced a broad array of
software engineering standards and related documents. Standards may be adopted voluntarily
by a software engineering organization or imposed by the customer or other stakeholders.
The job of SQA is to ensure that standards that have been adopted are followed and that all
work products conform to them.

Reviews and audits. Technical reviews are a quality control activity performed by software
engineers for software engineers. Their intent is to uncover errors. Audits are a type of review
performed by SQA personnel with the intent of ensuring that quality guidelines are being
followed for software engineering work. For example, an audit of the review process might
be conducted to ensure that reviews are being performed in a manner that will lead to the
highest likelihood of uncovering errors.

Testing. Software testing is a quality control function that has one primary goal—to find
errors. The job of SQA is to ensure that testing is properly planned and efficiently conducted
so that it has the highest likelihood of achieving its primary goal.

81
Error/defect collection and analysis. The only way to improve is to measure how you’re
doing. SQA collects and analyzes error and defect data to better understand how errors are
introduced and what software engineering activities are best suited to eliminating them.

Change management. Change is one of the most disruptive aspects of any software project.
If it is not properly managed, change can lead to confusion, and confusion almost always
leads to poor quality. SQA ensures that adequate change management practices have been
instituted.

Education. Every software organization wants to improve its software engineering practices.
A key contributor to improvement is education of software engineers, their managers, and
other stakeholders. The SQA organization takes the lead in software process improvement
and is a key proponent and sponsor of educational programs.

Vendor management. Three categories of software are acquired from external software
vendors—shrink-wrapped packages (e.g., Microsoft Office), a tailored shell that provides a
basic skeletal structure that is custom tailored to the needs of a purchaser, and contracted
software that is custom designed and constructed from specifications provided by the
customer organization. The job of the SQA organization is to ensure that high-quality
software results by suggesting specific quality practices that the vendor should follow (when
possible), and incorporating quality mandates as part of any contract with an external vendor.

Security management. With the increase in cyber crime and new government regulations
regarding privacy, every software organization should institute policies that protect data at all
levels, establish firewall protection for WebApps, and ensure that software has not been
tampered with internally. SQA ensures that appropriate process and technology are used to
achieve software security

Safety. Because software is almost always a pivotal component of human rated systems (e.g.,
automotive or aircraft applications), the impact of hidden defects can be catastrophic. SQA
may be responsible for assessing the impact of software failure and for initiating those steps
required to reduce risk.

Risk management. Although the analysis and mitigation of risk is the concern of software
engineers, the SQA organization ensures that risk management activities are properly
conducted and that risk-related contingency plans have been established.

82
In addition to each of these concerns and activities, SQA works to ensure that software
support activities (e.g., maintenance, help lines, documentation, and manuals) are conducted
or produced with quality as a dominant concern.

4.5 CHECK YOUR PROGRESS

1. What is software quality?

2. What are the methods to achieve software quality?
3. What is SQA?
4. What are the different review techniques followed to maintain software quality?

Answers to check your progress:

1. The quality of software can be defined as the ability of the software to function as per
user requirement. When it comes to software products it must satisfy all the
functionalities written down in the SRS document.
2. Software Engineering Methods, Project Management Techniques, Quality Control,
Quality Assurance.
3. Software quality assurance (SQA) encompasses
(1) an SQA process,
(2) specific quality assurance and quality control tasks (including technical reviews
and a multitiered testing strategy),
(3) effective software engineering practice (methods and tools),
(4) control of all software work products and the changes made to them,
(5) a procedure to ensure compliance with software development standards (when
applicable), and
(6) Measurement and reporting mechanisms.
4. The different review techniques are:
(1) Cost Impact of Software Defects
(2) Review Metrics and their Use
(3) Analyzing Metrics
(4) Informal Reviews
(5) Formal Technical Reviews
(6) The Review Meeting
(7) Review Reporting and Record Keeping

83
4.6 SUMMARY

A wide variety of software quality dimensions and factors have been proposed over
the years. All try to define a set of characteristics that, if achieved, will lead to high software
quality. McCall’s and the ISO 9126 quality factors establish characteristics such as reliability,
usability, maintainability, functionality, and portability as indicators that quality exists.

The intent of every technical review is to find errors and uncover issues that would have a
negative impact on the software to be deployed. The sooner an error is uncovered and
corrected, the less likely that error will propagate to other software engineering work
products and amplify itself, resulting in significantly more effort to correct it.

4.7 KEYWORDS

 Testing: It is a quality control function that has one primary goal to find errors.
 Technical reviews: This is a quality control activity performed by software engineers for
software engineers.
 Quality control: It encompasses a set of software engineering actions that help to ensure
that each work product meets its quality goals.
 Durability: It means the ability of the software to work without any issue for a long
period of time.

4.8 QUESTIONS FOR SELF STUDY

1. What are the key aspects that conclude software quality?

2. What are the targeted software quality factors?
3. Discuss any two major techniques to achieve software quality.
4. Explain any 4 review techniques.
5. Write a note on SQA elements.

4.9 REFERENCES

1. https://ocw.ui.ac.id/pluginfile.php/13396/mod_resource/content/2/Schwalbe%208th%20-
%20Chapter%2002.pdf
2. https://www.tpptechnology.com/
3. https://mymanagementguide.com/

84