Unit 1

Chapter 2: Software Processes

Introduction
Process means, a particular method of doing something, generally involving
several operations. In software engineering, the phrase software process refers to the
method of developing the software. A software process is a set of activities together
with proper ordering to build a high-quality software with low cost and small cycle-
time.

2.1 Software Process

The process that deals with the technical and management issues of software
development is called a software process. Clearly, many different types of activities
need to be performed to develop software. As different types of activities are
performed by different people, a software process consists of many components each
consisting of many activities.

2.1.1 Processes, Projects and Products

A software process defines a method for developing software. A software
project is a development project in which a software process is used. Software
products are the outcomes of a software project. Each software development process
starts with some needs and ends with some software that satisfies those needs. A
software process specifies how the abstract set of activities that should be performed
to go from user needs to final product. There can be many projects for a process (i.e.,
many projects can be done using a process), and there can be many products produced
in a project. This relationship is shown in the Figure 1.

Software Process

... ...
Project1 Projecti Projectn

...
Product1 Product2 Productm

Figure 1: Processes, projects, and products

The process specifies the activities at an abstract level that are not project
specific. It is a generic set of activities and does not provide a detailed roadmap for a
particular project. The process also specifies the order in which the activities of a
project are carried out.

5th Sem BCA / Software Engineering/Unit 1/ Software Processes -1-

2.1.2 Components of Software Process
There are three major components in a software process. They are
• Development process
• Management process
• Software configuration management process
The development process specifies the development and quality assurance
activities that need to be performed. Management process specifies how to plan and
control these activities, so that project objectives are met.
The development and management processes aim at satisfying cost and quality
objectives of a project. Any software project has to deal with the problem of change
and rework satisfactorily. This change cannot be handled by the development
process. To handle the change and rework issues, another process called software
configuration control process is used. The objectives of this process are to deal with
managing changes so that cost and quality objectives are met and the integrity of the
project is not violated due to the change requests.
Project management process and configuration control process depend on
development process. The main objectives of these processes are to produce a desired
product. So, they can be called as product engineering processes. Software is not
static; it is dynamic because it must change to adapt newer technologies and tools.
Due to this, a process to manage a software is needed. It is called process
management process.
The main objectives of process management are to improve the software process.
Improvement means that the capability of the process to produce high-quality s/w at
low cost.

Software Process

Product
Engineering Process
Process management
Process

Development Project Software

Process Management Configuration
Process Management
Process

Figure 2: Software Processes

5th Sem BCA / Software Engineering/Unit 1/ Software Processes -2-

2.2. Characteristics of a Software Process
The fundamental objectives of software processes are optimality and
scalability. Optimality means that the process must be able to produce high quality
software at low cost and small cycle time. Scalability means that, it should also be
applicable for large software projects. To achieve these objectives, the process must
have some properties. Some characteristics of the software processes are listed below.

2.2.1. Predictability
Predictability of a process determines how accurately the outcome of following
a process in a project can be predicted before the project is completed. Predictability
is a fundamental property of any process. Effective management of quality assurance
activities largely depend on the predictability of the process. A predictable process is
also said to be under statistical control. A process is said to be under statistical
control if following the same process produces similar results. Statistical control
implies that most projects will be within a bound around the expected value. Any
data beyond the line implies that the data and the project should be examined and
followed to pass through only if clear evidence is found that this is a statistical
aberration.
Property of interest



Projects

Figure 3: Process under statistical control

2.2.2. Support Maintainability and Testability

Software products are not only easily maintainable because of the development
process which is used for developing the software does not contain maintainability as
a clear goal. Developers are made responsible for maintenance at least for a couple of
years after developing the software.
Many examples show us that, programming is not a major activity where
programmer spends his time. Testing consumes most resources during development.
The goal of the process should not be to reduce the effort of design and coding but to
reduce the effort of testing and maintenance. Both testing and maintenance depend

5th Sem BCA / Software Engineering/Unit 1/ Software Processes -3-

heavily on design and coding and these costs are considerably reduced if the software
is designed and coded make testing and maintenance easy.

2.2.3. Early Defect Removal and Defect Prevention

If there is a greater delay in detecting the errors, it becomes more expensive to
correct them. As the figure given below shows, an error that occurs in the
requirement phase, if corrected during acceptance testing, can cost about 100 times
more than correcting the error in the requirement phase. To correct errors after
coding, both the design and code are to be changed; there by changing the cost of
correction. All the defect removal methods are limited in their capabilities and can
not detect all the errors that are introduced. Hence it is better to provide support for
defect prevention.

1000
Relative
cost to
fix errors 100

50

10
5

Requirements Design Coding Development Acceptance Operation

Test Test

Phases in which error was detected

Figure 4: Cost of correcting errors

2.2.4. Process Improvement

Improving the quality and reducing the cost are the fundamental goals of the
software engineering process. This requires the evaluation of the existing process and
understanding the weakness in the process.

Having process improvement as a fundamental objective requires that the

software process be a closed – loop process. That is, the process must learn from
previous experiences, and each project done using the existing process must feed
information back into the process itself, which can then use this information for self –
improvement.

2.3. Software Development Process

5th Sem BCA / Software Engineering/Unit 1/ Software Processes -4-

 Software development process focuses on the activities related to the
production of the software. For example: design, coding, testing. A development
process model specifies some activities that according to the model should be
conducted. It also gives the order in which the activity to be performed.

2.3.1. A Process Step Specification

A production process is a sequence of steps. The output of one step will be the
input to the next one. The process model will just specify the steps and their order.
There are some practical issues such as when to initiate a step, when to terminate a
step will not be given by any process model. There must be some verification and
validation (V&V) at the end of each step in order to detect the defects. This implies
that, there is an early defined output of a phase which can be verified by some means
and can form the input to the next phase such products are called work products.
[Example: Requirement document, design document, code prototype etc.] Having too
many steps results in too many work products each requiring V&V can be very
expensive. Due to this, the development process typically consists of a few steps
producing few documents for V&V.
The major issues in development process are when to initiate and when to
terminate a phase. This is done by specifying an entry criteria and exit criteria for a
phase. The entry criteria of a phase specifies the conditions that the input to the
phase should satisfy in order to initiate the activities of that phase. The output
criteria specifies the conditions that the work product of current phase should satisfy
in order to terminate the activities of the phase.

Control Information to
Management Process

Process Step V&V Output

Input (Exit Criteria)
(Entry Criteria)

Figure 5: A step in a development process

Besides the entry and the exit criteria for the input and the output a
development step needs to produce some information for the management process.
The goal of management process is to control the development process.

2.3.2. Waterfall Model

Waterfall model is the simplest model which states that the phases are
organized in a linear order. In this model, a project begins with feasibility analysis.
On successfully demonstrating the feasibility of a project, the requirement analysis

5th Sem BCA / Software Engineering/Unit 1/ Software Processes -5-

and project planning begins. The design starts after the requirement analysis is
complete and the coding begins after the design is complete, once the programming is
complete, the code is integrated and testing is done. On successful completion of
testing, the system is installed. After this, the regular operations and maintenance
take place as shown in the Figure 6.

Each phase begins soon after the completion of the previous phase.
Verification and validation activities are to be conducted to ensure that the output of
a phase is consistent with the overall requirements of the system. At the end of every
phase there will be an output. Outputs of earlier phases can be called as work
products and they are in the form of documents like requirement document and
design document. The output of the project is not just the final program along with
the user manuals but also the requirement document, design document, project plan,
test plan and test results.

Project Outputs of the Waterfall Model

• Requirement document
• Project plan
• System design document
• Detailed design document
• Test plan and test report
• Final code
• Software manuals
• Review report.
Reviews are formal meetings to uncover deficiencies in a product. The review reports
are the outcomes of these reviews.

5th Sem BCA / Software Engineering/Unit 1/ Software Processes -6-

 System Requirements
Feasibility Feasibility
Analysis & Project
Validation Report Planning
Validation

Requirements Document& Project Plan

System Detailed
Design System Design Document Design
Verification Verification

Detailed Design Document

Coding
Testing and Integration
Verification Programs

Test Plan, Test Report, &

Manuals

Operations and
Installation Installation Report Maintenance

Figure 6: The waterfall model

Limitations of Waterfall Model

1. Waterfall model assumes that requirements of a system can be frozen before the
design begins. It is difficult to state all the requirements before starting a
project.
2. Freezing the requirements usually requires choosing the hardware. A large
project might take a few years to complete. If the hardware stated is selected
early then due to the speed at which the hardware technology is changing, it will
be very difficult to accommodate the technological changes.
3. Waterfall model stipulates that the requirements be completely specified before
the rest of the development can proceed. In some situations, it might be
desirable to produce a part of the system and then later enhance the system.
This can’t be done if waterfall model is used.
4. It is a document driven model which requires formal documents at the end of
each phase. This approach is not suitable for interactive applications.
5. In an interesting analysis it is found that, the linear nature of the life cycle leads
to “blocking states” in which some project team members have to wait for other

5th Sem BCA / Software Engineering/Unit 1/ Software Processes -7-

 team members to complete the dependent task. The time spent in waiting can
exceed the time spent in productive work.
6. Client gets a feel about the software only at the end.

2.3.3. Prototype Model

The goal of prototyping is to overcome the limitations of waterfall model. Here
a throwaway prototype is built to understand the requirements. This prototype is
developed based on the currently known requirements. Development of the prototype
undergoes design, coding and testing, but each of these phases is not done very
thoroughly or formally. By using the prototype, the client can get actual feel of the
system because the interaction with the prototype can enable the client to better
understand the system. This results in more stable requirements that change less
frequently. Prototyping is very much useful if there is no manual process or existing
systems which help to determine the requirements.
Initially, primary version of the requirement specification document will be
developed and the end-users and clients are allowed to use the prototype. Based on
their experience with the prototype, they provide feedback to the developers
regarding the prototype. They are allowed to suggest changes if any. Based on the
feedback, the prototype is modified to incorporate the changes suggested. Again
clients are allowed to use the prototype. This process is repeated until no further
change is suggested.

Requirement
Analysis

Design Design Code Test

Code

Test

Requirement Analysis

Figure 7: The prototyping model

This model is helpful when the customer is not able to state all the
requirements. Because the prototype is throwaway, only minimum documentation is
needed during prototyping. For example design document and test plan etc. are not
needed for the prototype.
Problems
This model much depends on the efforts required to build and improve the prototype
which in turn depends on computer aided prototyping tools. If the prototype is not
efficient, too much effort will be put to design it.

5th Sem BCA / Software Engineering/Unit 1/ Software Processes -8-

2.3.4. Iterative Enhancement Model

Design 0 Design 1 Design n

Implement 0 Implement 1 …… Implement n

Analysis 0 Analysis 1 Analysis n

Figure 8: The iterative enhancement model

This model tries to combine the benefits of both prototyping and waterfall
model. The basic idea is, software should be developed in increments, and each
increment adds some functional capability to the system. This process is continued
until the full system is implemented. An advantage of this approach is that, it results
in better testing because testing each increment is likely to be easier than testing the
entire system. As prototyping, the increments provide feedback from the client, which
will be useful for implementing the final system. It will be helpful for the client to
state the final requirements.
Here a project control list is created. It contains all tasks to be performed to
obtain the final implementation and the order in which each task is to be carried out.
Each step consists of removing the next task from the list, designing, coding, testing
and implementation and the analysis of the partial system obtained after the step
and updating the list after analysis. These three phases are called design phase,
implementation phase and analysis phase. The process is iterated until the project
control list becomes empty. At this moment, the final implementation of the system
will be available.
The first version contains some capability. Based on the feedback from the
users and experience with the current version, a list of additional features is
generated. And then more features are added to the next versions. This type of
process model will be helpful only when the system development can be broken down
into stages.

Disadvantage
This approach will work only if successive increments can actually put into operation.

2.3.5. Spiral Model

5th Sem BCA / Software Engineering/Unit 1/ Software Processes -9-

 As the name suggests, the activities of this model can be organized like a spiral
that has many cycles as shown in the Figure 9. Each cycle in the spiral begins with
the identification of objectives for that cycle; the different alternatives that are
possible for achieving the objectives and the constraints that exist. This is the first
quadrant of the cycle. The next step is to evaluate different alternatives based on the
objectives and constraints. The focus is based on the risks. Risks reflect the chances
that some of the objectives of the project may not be met. Next step is to develop
strategies that resolve the uncertainties and risks. This step may involve activities
like prototyping.

Figure 9: The spiral model

The risk-driven nature of the spiral model allows it to suit for any applications.
The important feature of spiral model is that, each cycle of spiral is completed by a
review that covers all the products developed during that cycle; including plans for
the next cycle.
In a typical application of spiral model, one might start with an extra round-
zero, in which the feasibility of the basic project objectives is studied. In round-one a
concept of operation might be developed. The risks are typically whether or not the
goals can be met within the constraints. In round-2, the top-level requirements are
developed. In succeeding rounds the actual development may be done. In a project,
where risks are high, this model is preferable.

Problems

5th Sem BCA / Software Engineering/Unit 1/ Software Processes - 10 -

 1) It is difficult to convince the customers that the evolutionary approach is
controllable.
2) It demands considerable risk-assessment expertise and depends heavily on this
expertise for the success.
3) If major risks are uncovered and managed, major problems may occur.

2.4. Project Management Process

To meet cost, quality and schedule objectives, the resources have to be allocated for
each activity of the project. The basic task of management process is to plan the
detailed implementation of the process for the particular project and then ensure that
the plan is followed. Proper management is essential for the success of any project.

2.4.1. Phases of Management Process

The activities of management process are grouped into three phases- planning,
monitoring and control and termination analysis. Planning is the largest
responsibility of the project management. The goal of this phase is to develop a plan
for the software development. A software plan is usually produced before the
development activities begin. The major activities during planning are cost
estimation, schedule determination, project staffing, quality control etc.

Termination
Planning Monitoring and control analysis
Management
process

Development
Metrics Process
Values

Management
Control

Time

Figure 10: Temporal relationship between development and management process

Project monitoring and control phase includes all activities that the project
management has to perform while development is going on to ensure that project
objectives are met and the development process proceeds according to the plan. If the
objectives are not met, then this phase exerts suitable actions to control development
activities. Monitoring requires proper information about the project. This information
is obtained by the management process from the development process.

5th Sem BCA / Software Engineering/Unit 1/ Software Processes - 11 -

 Termination analysis is performed when the development phase is over. The
basic reason for performing termination analysis is to provide information about the
development process. The ideal relationship between development process and
management process is given in the figure above. It shows that, planning is done
before starting the development process and termination analysis is conducted after
the development is over. During development process, quantitative information flows
to the monitoring and control phase of the management process which uses the
information to exert control on the development process.

2.4.2 Metrics, Measurement, and Models

For effective project monitoring, the information coming from the development
process to the management process should be objective and quantitative data about
the project. The need for quantitative data from the process requires that software
metrics be used.

Software metrics are quantifiable measure that could be used to measure

different characteristics of a software system or the software development process.
Values for some metrics can be directly measured; others might have to be deduced
by other measurement (an analogy could be that the distance between two points can
be deduced by measuring the speed of a vehicle and measuring the time it takes to
traverse the given distance). If a metric is not measured directly, we call the metric
indirect. It has to be estimated from other measurements that are possible.

For estimating, models are needed. A model is a relationship of the predicted

variable (the property of interest) that other variables that can be measured. That is,
if there is some metric of interest which cannot be measured directly, then we build
models to estimate the metric value based on the value of some other metrics that we
can measure.

It should be clear that metrics, measurement, and models go together. Metrics

provide a quantification of some property, measurement provide the actual value for
the metrics, and models are needed to get the value for the metrics that cannot be
measured directly ( i.e., provide the measurement indirectly by using a model ).

2.5. Software Configuration Management Process [SCM]

The IEEE defines SCM as “SCM is a process of identifying and defining the
items in the system, controlling the change of these items throughout their life-cycle,
recording and reporting the status of item and change request and verifying the
completeness and correctness of these items.” SCM is independent of development
process. Development process handles normal changes such as change in code while
the programmer is developing it or change in the requirement while the analyst is
gathering the information. However it can not handle changes like requirement
changes while coding is being done. Approving the changes, evaluating the impact of
change, decide what needs to be done to accommodate a change request etc. are the

5th Sem BCA / Software Engineering/Unit 1/ Software Processes - 12 -

issues handled by SCM. The development is brought under the configuration control
process, so that changes are allowed in a controlled manner, as shown in the figure
below, for a waterfall type development process.

Configuration Management

Phase Phase Phase

1 2
... n

Figure 11: Configuration management and development process.

SCM has beneficial effects on cost, schedule and quality of the product being
developed.
It has three major components:
1. Software configuration identification
2. Change Control
3. Status accounting and auditing.

2.5.1. Configuration Identification

When a change is done, it should be clear, to what, the change has been
applied. This requires a baseline to be established. A baseline forms a reference point
in the development of a system and is generally defined after the major phases in the
development process. A software baseline represents the software in a most recent
state. Some baselines are functional or requirement baseline, design baseline and the
product baseline or system baseline. Functional or requirements baseline is generally
the requirements document that specifies the functional requirements for the
software. Design baseline consists of the different components in the software and
their designs. Product or system baseline represents the developed system. It should
be clear that a baseline is established only after the product is relatively stable. Only
when the requirements are “frozen”, is the baseline is established.
Though the goal of SCM is to control the establishment and changes to these
baselines, treating each baseline as a single unit for the change is undesirable,
because the change may be limited to a very small portion of the baseline. For this
reason, a baseline can consist of many software configuration items [SCI’s]. A
baseline is a set of SCIs and their relations.
Because a baseline consists of SCIs and SCI is the basic unit for change
control, the SCM process starts with identification of the configuration items. Once
the SCI is identified, it is given a name and becomes the unit of change control.

2.5.2. Change Control

Once the SCIs are identified, and their dependencies are understood, the
change control procedures of SCM can be applied. The decisions regarding the change

5th Sem BCA / Software Engineering/Unit 1/ Software Processes - 13 -

are generally taken by the configuration control board [CCB] headed by configuration
manager [CM].
When a SCI is under development, it has considered being in working state. It
is not under SCM and can be changed freely. Once the developer is satisfied with the
SCI, then it is given to CM for review and the item enters to ‘under review’ state. The
CM reviews the SCI and if it is approved, it enters into a library after which the item
is formally under SCM. If the item is not approved, the item is given back to the
developer. This cycle of a SCI is given in the figure below.

Rejected

Working Under Under SCM

Review
Developer
Satisfied Approved

Figure 12: SCM life cycle of an item

Once the SCI is in the library, it can not be modified, even without the permission of
the CM. An SCI under SCM can be changed only if the change has been approved by
the CM. In such case, the SCI is checked out of the library, the change made to the
SCI, and then the modified SCI is given back to the CM, who reviews it again to
ensure that the change is properly done and then checks the item back in the library.
This aspect of SCM is sometimes called library management and can be done with
the aid of tools. Frequently, the changed SCI does not replace the old copy; instead a
new version of the SCI is created. With multiple versions of SCIs and multiple
versions of systems using different versions of SCIs, version management becomes
extremely important.
A change is initiated by a change request (CR). The reason for change can be
anything. The CM evaluates the CR primarily by considering the effect of change on
the cost schedule and quality of the project and the benefits likely to come due to this
change. Once the CR is accepted, project manager will take over the plan and then
CR is implemented by the programmer. One of the most common reasons for a CR is
the discovery of some bug or problem in the software. Frequently, the change
requests originating due to faults are made on a different form called a fault report
(FR).

2.5.3. Status Accounting and Auditing

The aim of status accounting is to answer the question like what is the status of the
CR (approved/rejected), what is the average and effort for fixing a CR and what is the
number of CR. For status accounting, the main source of information is CR.
Auditing has a different role. In general, an audit for a process is performed by
auditors. The main objective of an audit is to determine if the specified process is
being followed and whether the specified process satisfies the goals of the process.

5th Sem BCA / Software Engineering/Unit 1/ Software Processes - 14 -

The same is done for SCM auditing. Records of past changes are evaluated by the
auditor to determine if the SCM procedures are being followed, and the procedures
are evaluated to ensure that the SCM goals are met.

2.6. Process Management Process

A software process is not a static entity – it has to change to improve so that the
products produced using the process are of higher quality and are less costly.
Reducing cost and improving quality are fundamental goals of engineering. For
producing software it implies that the software process must continually be
improved, as cost and quality of products are determined to a great extent by the
process. This is the objective of the process management process. It should be
emphasized that process management is quite different from project management. In
process management the focus is on improving the process that improves the general
quality and productivity for the products produced using the process. In project
management the focus is on executing the current project and ensuring that the
objectives of the project are met. The time duration of interest for project
management is typically the duration of the project, while process management
works on a much larger time scale as each project is viewed as providing a data point
for the process. One aspect of process management is process improvement and
maturity.
2.6.1. Process Improvement and Maturity
Process improvement requires understanding the current process and its
deficiencies and then taking actions to remove the deficiencies. This is possible only if
the current process is under statistical control. Two frameworks have been used by
various organizations to improve their process.

Capability Maturity Model

To improve its software process, an organization needs to first understand the
status of the current status and develop a plan to improve the process. It is generally
agreed that changes to a process are best introduced in small increments and it is not
possible to totally revolutionize a process.
If we agree that changes to a process must be introduced in small increments, the
next question is out of a large set of possible enhancements to a process, in what
order should the improvement activities be undertaken? Or what small change
should be introduced first? This depends on the current state of the process. Deciding
what activities to undertake for process improvement is a function of the current
state of the process. Once some process improvement takes place, the process state
may change, and a new set of possibilities may emerge. This concept of introducing
changes in small increments based on the current state of the process has been
captured in the Capability Maturity Model (CMM) framework. The CMM framework
provides a general roadmap for process improvement.
Software process capability describes the range of expected results that can be
achieved by following the process. A maturity level is a well- defined evolutionary

5th Sem BCA / Software Engineering/Unit 1/ Software Processes - 15 -

level toward achieving in a mature software process. The CMM suggests that there
are five well – defined maturity levels for a software process. These are initial(level
1), repeatable, defined, managed, and optimizing (level 5). The CMM framework says
that as process improvement is best incorporated in small increments, processes go
from their current levels to the next higher level when they are improved. Hence,
during the course of process improvement, a process moves from level to level until it
reaches level 5. This is shown in Figure 13.

Optimizing
Continuously (5)
Improving
Process

Managed
Predictable (4)
Process

Defined
Standard, (3)
Consistent
Process

Repeatable
Disciplined
(2)
Process

Initial
(1)

Figure 13: Capability maturity Model

The initial process (level 1) is essentially an adhoc process that has no formalized
method for any activity. Basic project controls for ensuring that activities are being
done properly and that the project plan is being adhered to are missing.
Organizations at this level can benefit most by improving project management,
quality assurance, and change control.
In a repeatable process (level 2), policies for managing a software project and
procedures to implement those policies exist. That is project management is well
developed in a process at this level.
At the defined level (level 3) the organization has standardized on a software process,
which is properly documented.

5th Sem BCA / Software Engineering/Unit 1/ Software Processes - 16 -

At the managed level (level 4) quantitative goals exist for process and products. Data
is collected from software processes, which is used to build models to characterize the
process. Hence, measurement plays an important role in a process at this level.
At the optimizing level (level 5), the focus of the organization is on continuous process
improvement. Some of the key process areas of the different levels are shown in
Figure 14.

LEVEL 5 – OPTIMIZING
• Process change management
• Technology change management
• Defect prevention

LEVEL 4 – MANAGED
• Software quality management
• Quantitative process management

LEVEL 3 – DEFINED
• Organization process definition
• Training program
• Peer reviews
• Integrated software management

LEVEL 2 – REPEATABLE
• Software requirements management
• Software configuration management
• Project planning
• Project monitoring and control

Figure 14: Some key process areas

Quality Improvement Paradigm and GQM

A somewhat different approach for improving a process is taken by the Quality
Improvement Paradigm (QIP). QIP does not specify levels or what areas to focus on
for improvement. It gives a general method for improving a process, essentially
implying that what constitutes improvement of a process depends on the organization
to which the organization to which the process belongs and its objectives. The basic
idea behind this approach is to understand the current process, set objectives for

5th Sem BCA / Software Engineering/Unit 1/ Software Processes - 17 -

improvement, and then plan and execute the improvement actions. The QIP consists
of six basic steps:
o Characterize. Understand the current process and the environment it operates
in.
o Set Goals. Based on the understanding of the process and the environment and
objectives of the organization, set quantifiable goals for performance
improvement. The goals should be reasonable.
o Choose Process. Based on the characterization and goals, choose the
component processes that should be changed to meet the goals.
o Execute. Execute projects using the processes and provide feedback data.
o Analyze. Analyze the data at the end of each project. From the analysis,
determine problems and recommendations for improvements to be applied on
future objects.
o Package. Based on the experience gained from many projects, define and
formalize the changes to be made to processes and expectation from the new
processes.

For collecting proper data that will serve the purpose of process improvement,
the Goal/Question/Metrics (GQM) paradigm is frequently used. The GQM
paradigm suggests a general framework for collecting data from projects that
can be used for a specific purpose.

******

5th Sem BCA / Software Engineering/Unit 1/ Software Processes - 18 -