UNIT-III: Project Monitoring and Control

Dimensions of Project Monitoring & Control, Earned Value Analysis, Earned

Value Indicators: Budgeted Cost for Work Scheduled (BCWS), Cost Variance
(CV), Schedule Variance (SV), Cost Performance Index (CPI), Schedule
Performance Index (SPI), Interpretation of Earned Value Indicators, Error
Tracking, Software Reviews, Types of Review: Inspections, Deskchecks,
Walkthroughs, Code Reviews, Pair Programming.

Monitoring & Controlling is made up of two components; tracking current

status and future prediction .
What a project manager does to monitor and control: Measure, on a regular
basis, the project's process and product Evaluate current status vs. planned
progress Predict project completion schedule, cost and quality Adjust your
planning as needed.

Earned Value Management Systems

1.0 Overview
1.1 Background
In the midst of a typical project, it is often desirable to estimate such
quantities as “how much time is left?” or “how much of the work is
complete?” or “how much money will the project spend before it is
complete?” If these remind you of trips in the family car where the children
are wondering “are we there yet?”, it is not surprising. Just as the
passengers on a trip wonder how long it will take to get to the destination,
so managers have a responsibility to understand how long a project will take
to get to its destination - and what it will cost. Those working on the project
usually want to know this too.

Earned Value Analysis (EVA) is a way to measure the amount of work

actually performed on a project (i.e., to measure its progress) and to
forecast a project’s cost and date of completion. The method relies on a key
measure known as the earned value (also known as the “budgeted cost of
worked performed” or BCWP). This measure enables one to compute
performance indices for cost and schedule, which tell how well the project is
doing relative to its original plans. These indices also enable one to forecast
how the project will do in the future.

Earned value actually uses three data values, which are computed each
week, month, or whatever other period you wish to use. We use the term
“analysis date” to refer to the date when the three values are analyzed.
________________________________________________________________________________________________________--
Software Project Management-Mrinal Singh Rawat Page 1
Thus if we measure these values monthly, an analysis date of October 31
would include all values from project inception until the end of October.

The three values are:

Budgeted Cost of Work Performed (BCWP).

Budgeted Cost of Work Scheduled (BCWS).
Actual Cost of Work Performed (ACWP).

1.2 Definition of the Three Basic Values

BCWP or Budgeted Cost of Work Performed or Earned Value

This is the cost originally budgeted to accomplish the work that has been
completed as of the analysis date. It answers the question “how much work
has actually been completed?”.

BCWS or Budgeted Cost of Work Scheduled or Plan

This is the total budgeted cost up to the analysis date. It answers the
question “how much did we plan to spend as of this date?” A variant of this
question is “how much work should have been completed by this date?”
BCWS can be computed from the project’s plans, as illustrated in the sequel,
or it can be approximated by multiplying the total budget by the fraction of
total project duration at the analysis date. Thus, for example, if the project
budget is $100 and 20% of the project’s time has elapsed, the approximate
BCWS is $20.

ACWP or Actual Cost of Work Performed

This is what it actually cost to accomplish all the work completed as of the
analysis date. It answers the question “how much have we actually spent?”.
This is usually determined from the organization’s accounting system, or
can often be approximated by multiplying the number of people by the
number of hours or days or weeks worked.

________________________________________________________________________________________________________--
Software Project Management-Mrinal Singh Rawat Page 2
1.3 Derived Metrics

Four measures can be computed from the basic values described above:

• Schedule Variance (SV) = BCWP - BCWS

If it is 0, you are right on schedule. If it is negative, you are behind

schedule. If it is positive, you area ahead of schedule.

• Schedule Performance Index (SPI) = BCWP / BCWS

If it is 1, you are right on schedule. If it is less than 1, you are behind
schedule. If it is greater than 1, you are ahead of schedule.

• Cost Variance (CV) = BCWP - ACWP

If it is 0, you are right on budget. If it is negative, you are over

budget. If it is positive, you area under budget.

• Cost Performance Index (CPI) = BCWP / ACWP

If it is 1, you are right on budget. If it is less than 1, you are over

budget. If it is greater than 1, you are under budget.

________________________________________________________________________________________________________--
Software Project Management-Mrinal Singh Rawat Page 3
2.0 Using EVA to Determine Where you Are
2.1 Units
There are many ways to measure “cost”. For example, we could measure
actual money spent. However it is common in a work environment to
measure cost in terms of labor - that is in work hours or work days spent.
Thus the budget for a project could be $30,000 or it could be 300 labor
hours, and the amount spent so far could be $4,500 or it might be 45 labor
hours. EVA can be used with any measure of cost, but it is important to
decide which one to use. We will use an example in dollars in this section
and an example in work days in the sequel.

2.2 An Example using Dollars

Suppose you are making cookies for a large party to be held tomorrow.
Suppose the following are your plans:

Plans:
• 40 cookies per batch
• 5 batches per hour (200 cookies)
• Schedule: 5 hours to make a total of 1000 cookies
• Budgeted cost per cookie is $0.05
• Total budget is $50.00 for cookie ingredients, or $10 per hour

We'll use earned value to examine our progress.

Progress Report at End of Hour 1:
• 150 edible cookies have been made (some were burnt and had to be
thrown away)
• Total actual cost of ingredients used so far is $9.00 (ACWP)

Analysis:
BCWS = $10.00
BCWP = $7.50 (Earned Value) [150 cookies x .05 per cookie]
ACWP = $9.00 [from above]

Therefore:
SV = BCWP - BCWS = -$2.50 (you are behind schedule)
SPI = BCWP / BCWS = 0.75 (you are running at 75% of the planned
schedule)
CV = BCWP - ACWP = $7.50 - $9.00 = -$1.50 (you are $1.50 over budget)
CPI = BCWP / ACWP = 0.833 (you are running over budget by about 17%)

3.0 Using EVA to Forecast

3.1 Additional Terminology and Definitions

Five additional terms will be used in forecasting:

________________________________________________________________________________________________________--
Software Project Management-Mrinal Singh Rawat Page 4
• BAC - Budget At Completion = Total Original Budgeted Cost
This is the same as BCWS at completion
• EAC - Estimate At Completion = your estimate of the amount of money
you will spend on the project. This is based on your judgment.
• IEAC - Independent Estimate At Completion = Projected final cost of the
project, based on performance so far. IEAC can be forecast using the
following formula:
IEAC = BAC / CPI
• ISAC - Independent Schedule At Completion = Projected duration of the
project, based on performance so far. ISAC can be forecast using the
following formula:
ISAC = Schedule / SPI
• VAC - Variance At Completion = Forecast of final cost variance
= BAC - IEAC or, if you prefer, VAC = BAC - EAC

3.2 Forecasting the Cookie Budget and Schedule

IEAC = BAC / CPI = $50 / 0.833 = $60

VAC = BAC - IEAC = $50 - $60 = -$10 ($10 over budget)
ISAC = 5 / SPI = 5 / 0.75 = 6.67 hours

In other words, you forecast that it will take 6 2/3 hours and $60 to make
the cookies, if your success at making them does not improve. Stripped of
all the verbiage, imagine someone telling you “at the rate you are going, it
is going to take you all day and it will cost more than you bargained for.”
EVA enables you to say that in more precise terms.

Perhaps for making cookies, such precision is not essential (although if the
prediction was 44 hours, you would have something to worry about!). But
for running an expensive project, EVA can be very helpful, even essential.

4.0 Can we Catch Up?

4.1 To-Complete Performance Index

Once we report that our project is behind schedule or over budget, the next
question is usually “can we do something to get back on track?” Can we
meet the desired schedule and budget despite the fact that we are running
behind? Two indices are computed to help determine this. The “To-
Complete” performance index is an indication of how we must perform for
the duration of the project in order to meet our desired cost goal. If TCPI is
greater than 1, we must perform better than planned in order to meet the
goal; and if less than 1 we can get by with performing under our plan.

• TCPI = (Budget-BCWP)/ (EAC-ACWP)

where EAC is the amount we estimate we will spend. Looking closely we see
that the numerator is how much work is left to do and the denominator is
how much we have left to spend. Note too that if EAC is simply IEAC, then
________________________________________________________________________________________________________--
Software Project Management-Mrinal Singh Rawat Page 5
the TCPI is the same as the CPI - i.e., it indicates that if we do not change
our performance, IEAC is the correct estimate of our final cost. (Exercise for
the reader: prove mathematically that if EAC = IEAC then CPI = TCPI.)

We mentioned two indices. A schedule index can also be developed. (This is

left as an exercise for the reader).

4.2 Application to the Cookie Example

In the cookie example, suppose we want to finish at exactly the $50 budget.
Then TCPI = (50.00-7.50) / (50.00-9.00) = 42.50/41.00 = 1.036. This means
that we must perform at 103.6% of the originally planned performance in
order to do this. I.e., 3.6% higher performance than originally planned. This
may be reasonable because we were able to get the first 200 cookies in the
oven for only $9 instead of the budgeted $10. But if TCPI had been 1.5, we
would know that we were in budget trouble unless we can somehow get our
supplies at a substantial discount over the plan!

5.0 Using EVA on a Project

5.1 The Micro Schedule - Identifying the Tasks
There are many ways to use EVA on a project, but the method we will
illustrate here is one of the easiest and must useful. We begin with a micro
schedule - a schedule of small tasks whose duration can be measured in
days or weeks. Typically a micro schedule applies to a portion of a project
and is estimated by those doing the work, often just before they begin that
portion of the project (figure 1).

Top Level Schedule

Phase 1 - Design
Phase 2 - Code
Phase 3 - Shakedown

Micro Schedule for Micro Schedule is

the Next Phase the locally-
managed schedule,
defined by those
doing the work

Figure 1 - EVA Micro Schedule

The micro schedule represents the work tasks ("inchstones") required to do

the job as well as who is assigned to do each task and their estimates of the
effort required. Each task must have
• objective completion criteria so you really know when they are
done;
________________________________________________________________________________________________________--
Software Project Management-Mrinal Singh Rawat Page 6
 • "budgets" or "values" (usually represented as person days of effort
or dollars of cost) ;
• planned completion dates so you know when you expect them to
be done.

Table 1 illustrates a typical micro schedule:

Table 1 - Micro Schedule for Coding Phase, Project XXX

Estimated Responsible
Effort Planned Completion Software
Task (work days) Date (week #) Developer(s)
Set Up 3 1 Joe
Get Specs 2 2 Mary
Design Output 10 5 Pete & Joe
Plan Tests 3 6 Joe
Write Code 5 7 Mary
Unit Test 3 8 Joe
Integrate 2 9 Mary
Beta Test 3 10 Pete
TOTAL 31

(The approach illustrated above relies on the judgment of the participants

but if the organization is at SEI CMM level 1 or 2, it may not utilize any
information from past projects other than the experience of the
participants. In an organization at CMM level 3, the micro schedule
might be defined by using the organization's (tailored) process. At
level 4 or higher, it might be defined by using the process, the
judgment of the participants, and past performance data.)

5.2 Computing the Effort Planned (BCWS)

The effort planned is determined by calculating, from the micro schedule,
how much work will be completed by the end of each week. Table 2
illustrates a typical BCWS chart.

________________________________________________________________________________________________________--
Software Project Management-Mrinal Singh Rawat Page 7
 Table 2 - BCWS for Coding Phase, Project XXX
Shorthand
Week Total Value that we Plan to Earn by That BCWS
Week (Total/week #)
1 3 3
2 5 6
3 7 (*) 9
4 11 (*) 12
5 15 15
6 18 19
7 23 22
8 26 25
9 28 28
10 31 31
(*) Assumes partial progress on “design output” task

5.3 Collecting Earned Value Each Week

Each week during the project, the team needs to indicate, at the end of the
week, which tasks are complete and, therefore, how much value has been
earned. The example shown in Table 3 gives partial credit for some tasks.
It is recommended that partial credit only be allowed for larger tasks and
then only in large chunks ( ½ , 1/3 , or maybe ¼).

Table 3 - Earned Value Data, Week ending Oct 29, 1999, Project
XXX
Task Effort (value) (work days) % Earned
Complete
Set Up 3 100 3
Get Specs 2 50 1
Design 10 25 2.5
Output
Plan Tests 3 0 0
Write Code 5 0 0
Unit Test 3 0 0
Integrate 2 0 0
Beta Test 3 0 0
TOTAL 31 6.5 (BCWP)

BCWP or earned value is the total of the “earned” column on the right hand
side. Table 3 is recomputed each week, whereas tables 1 and 2 need only
be done once. BCWP will increase each week as the project progresses. At
any given week, you have the BCWS from table 2 and the BCWP from table
3. ACWP is whatever number of person-days of work have actually been
paid for. This is simply the week number multiplied by 5 (total days worked)
multiplied by the number of people, if everyone works full time on just this
project. If people share their time between projects or work on non-project
activities, their “actual” work hours spent on the project must be
determined proportionally.

________________________________________________________________________________________________________--
Software Project Management-Mrinal Singh Rawat Page 8
5.4 Analyzing the Sample Project
Suppose table 3 represents the results at the end of week 3 on the sample
project. Suppose the staff did not work 100% on this project, so that only a
total of 10 work days have actually been spent on the project. Then:

BCWS = 7 work days (from table 2)

BCWP = 6.5 work days (from table 3)
ACWP = 10 work days (from paragraph above)

Then:
SV = BCWP - BCWS = -.50 (you are behind schedule)
SPI = BCWP / BCWS = 0.928 (you are running at about 93% of the
planned schedule)
CV = BCWP - ACWP = 6.5 - 10 = -3.50 (you are 3.5 staff days over
budget)
CPI = BCWP / ACWP = 0.65 (you are running over budget by about 35%)

Forecasts:
IEAC = BAC / CPI = 31/0.65 = 47.7 work days
VAC = BAC - IEAC = 31 - 48 = -17 (17 work days over budget)
ISAC = 10 / SPI = 10 / 0.928 = 10.7 work weeks

In short, your project looks like it will come in about a week late and 35%
over budget. What should you do now?

At this point, things look pretty dismal for meeting the cost budget. You
need to ask yourself these questions:
• Why is it taking more effort than planned?
• Did they underestimate the job?
• Are they losing too much productivity because they are being
shared between this project and something else?
• Were there unforseen obstacles and, if so, have they been
corrected?
• Is there some other reason?
• Was work performed on other tasks, but not enough to claim partial
credit yet on table 3? Maybe things aren’t quite as bad as they look

The key point here is that EVA enables you to spot a potential problem early
in the project and do something to correct the situation. You can also re-
estimate the total project duration and cost at this point, or negotiate
changes in the project with your management.

6.0 A Problem with SPI

6.1 The Problem

If a project runs longer than originally scheduled, cost estimating portions of
EVA continue to be useful but the schedule estimation portions begin to fail
-- the definitions of SV, SPI, and SAC do not work as described above.
Instead, they begin to converge toward "on schedule" values and, when the
________________________________________________________________________________________________________--
Software Project Management-Mrinal Singh Rawat Page 9
project is complete, they show values of SPI = 1, SV = 0, and SAC =
whatever the actual schedule turns out to be. This flaw in earned value
analysis results from the fact that the schedule estimates are based on
budgets rather than independent evaluations of the schedule.

6.2 Possible Solutions

One option is to use the values of SV, SPI, and SAC only until the originally
scheduled completion date and not use them afterwards. This option is
simple and it works well in many cases when the main concern is budget
overruns rather than schedule overruns, or when the schedule overruns are
not very large.

Another option is to re-estimate the schedule and base all future

calculations on this new schedule. (In effect, this is what automatically
happens with EVA -- in the end, the new schedule is whatever the actual
schedule happens to be.) Of course with this approach you never have a
very good method of predicting how much the schedule overrun will be.
A third option is to develop a new index, DPI or Delivery Performance Index,
as an alternative to SPI. DPI is based on the original completion schedules of
the individual work tasks. The specific terms and formulas are as follows:

• Actual Time - the time actually spent so far, in calendar days.

• Days Ahead - how many days ahead of schedule you are (negative if
behind schedule). This can be derived from the original schedules of the
individual work tasks.
• DPI - delivery performance index:
DPI = (Actual Time + Days Ahead) / Actual Time

This is harder to do and many accounting systems do not have a mechanism

for keeping track of the necessary information.

Software Review

A review is any activity in which a work product is distributed to reviewers

who examine it and give feedback.
• Reviews are useful not only for finding and eliminating defects, but
also for gaining consensus among the project team, securing approval
from stakeholders, and aiding in professional development for team
members
• Reviews help teams find defects soon after they are injected making
them cost less to fix than they would cost if they were found in test.
• All work products in a software project should be either reviewed or
tested.• Software requirements specifications, schedules, design
documents, code, test plans, test cases, and defect reports should all
be reviewed.

________________________________________________________________________________________________________--
Software Project Management-Mrinal Singh Rawat Page 10
________________________________________________________________________________________________________--
Software Project Management-Mrinal Singh Rawat Page 11
________________________________________________________________________________________________________--
Software Project Management-Mrinal Singh Rawat Page 12
Types of Review:
Formal inspections
“Formal” reviews are usually called “inspections.” In general, a “formal”
review refers to a heavy-process review with three to six participants
meeting together in one room with printouts and/or a projector.
 Someone is the “moderator” or “controller” and acts as the organizer,
keeps everyone on task, controls the pace of the review, and acts as
arbiter of disputes. Everyone reads through the materials beforehand
to properly prepare for the meeting.
 Each participant will be assigned a specific “role.” A “reviewer” might
be tasked with critical analysis while an “observer” might be called in
for domain-specific advice or to learn how to do reviews properly.
 A “reader” looks at source code only for comprehension – not for
critique – and presents this to the group. This separates what the
author intended from what is actually presented; often the author
himself is able to pick out defects given this third-party description.
 When defects are discovered in a formal review, they are usually
recorded in great detail. Besides the general location of the error in
the code, they include details such as severity (e.g. major, minor),
type (e.g. algorithm, documentation, data-usage, error handling), and
phase-injection (e.g. developer error, design oversight, requirements
mistake).
 Typically this information is kept in a database so defect metrics can
be analyzed from many angles and possibly compared to similar
metrics from QA. Formal inspections also typically record other
metrics such as individual time spent during pre-meeting reading and
during the meeting itself, lines-of-code inspection rates, and problems
encountered with the process itself.
 These numbers and comments are examined periodically in process-
improvement meetings.

Drawback:
When you have many people spending lots of time reading code and
discussing its consequences, you are going to identify a lot of defects. And
there are plenty of studies that show formal inspections can identify a large
number of problems in source code. But most organizations cannot afford to
tie up that many people for that long. You also have to schedule the
meetings – a daunting task in itself and one that ends up consuming extra
developer time. Finally, most formal methods require training to be
effective, and this is an additional time and expense that is difficult to
accept, especially when you aren’t already used to doing code reviews.
After all, if you can get all the proven benefits of formal in-spections but
occupy 1/3 the developer time, that’s clearly better.

________________________________________________________________________________________________________--
Software Project Management-Mrinal Singh Rawat Page 13
Deskchecks
A deskcheck is a simple review in which the author of a work product
distributes it to one or more reviewers. Deskchecks can be used as
predecessors to inspections. In many cases, having an author of a work
product pass his work to a peer for an informal review will significantly
reduce the amount of effort involved in the inspection.
Desk checking is a manual (non computerized) technique for checking the
logic of an algorithm. The person performing the desk check effectively acts
as the computer, using pen and paper to record results. The desk checker
carefully follows the algorithm being careful to rigidly adhere to the logic
specified. The desk check can expose problems with the algorithm.
Desk checks are useful to check an algorithm (before coding) thereby
confirming that the algorithm works as expected and saves time possibly
writing a program that doesn't do what was intended. Another benefit of a
desk check is that it confirms to the programmer/designer that the
algorithm performs as intended.
A desk check is normally done as a table with columns for:
1. Pseudo code line number column (Pseudo code doesn't normally have
lines numbers, but these are necessary in a desk check to specify the
line(s) being executed)

2. One column per variable used. The columns should be in

alphabetical order on variable name with the variable name at the top
of the column. As the algorithm is executed, the new values of the
variables are put in the appropriate column. Show working for
calculations. If variable names consist of a number of words it is
permissible to put a space between each word in the name so that the
name fits better in the column by wrapping to the next line. e.g. the
variable column heading discount Price could be used rather than the
actual variable name discountPrice.

3. A condition column. The result of the condition will be true (T) or

false (F). As the algorithm is executed, conditions are evaluated and
the details are recorded in the column. Show working when evaluating
the conditions. This is used whenever a condition is evaluated - IF
WHILE or FOR statements all have explicit or implicit conditions.

4. An Input/Output column is used to show what is input by the user

and displayed by the program. Show inputs with: the variable name, a
"?" and the value input e.g. price ? 200. Show outputs with the
variable name, an =, and the value displayed (or just the value
displayed) e.g. discountPrice= 180 .
Normally portrait page layout would be used for the desk check, however if
the table is too wide, landscape layout may be used.
Desk Checks vs Test Plans

________________________________________________________________________________________________________--
Software Project Management-Mrinal Singh Rawat Page 14
A Desk Check concentrates on the value of variables and the logic i.e. what
is the value of variable x after statement n; what is the next statement to be
executed? A Test Plan focuses on the values of inputs and outputs required
to test a program without concern for the internal workings i.e. are the
results (outputs) correct for the inputs?
Example 1
Problem Description: Calculate the discounted price of an item purchased.
(Note: a problem description is not normally specified in a desk check, it is
only included to assist in understanding the problem.)
The following example shows desk checking involving sequence, executing
instructions one after the other.Sequence involves executing all instructions
once, from top to bottom, one after the other.
Algorithm (with line numbers added for the Desk Check)
1 calcDiscountPrice()
2 Input price, discountPercent
3 discount = price * discountPercent / 100
4 discountPrice = price - discount
5 Display discountPrice
6 STOP

Desk Check
Test Data
Inputs: price = $200, discountPercent = 10%.
Correct results: discount = $20, discountPrice = $180.
Line discount discount pri
discount Input/Output
Number Percent Price ce
1
price ? 200;
2 10 200
discountPercent ? 10
200 * 10 /
3
100 = 20
200 - 20 =
4
180
5 discountPrice = 180
6

Example 2
Problem Description: Calculate the discounted price of an item purchased.
Customers receive a discount of 15% on an item if the purchase price of
the item is over $100.
The following example shows desk checking involving selection using an IF.

________________________________________________________________________________________________________--
Software Project Management-Mrinal Singh Rawat Page 15
For an IF without an ELSE, if the condition evaluates to True then execution
continues to the next line and the lines between the IF and ENDIF are
executed (inclusive), otherwise (the condition is False) execution jumps from
the IF to the ENDIF.
Algorithm (with line numbers added for the Desk Check)
1 calcPrice()
2 Input price
3 IF price > 100 THEN
4 discount = price * 15 / 100
5 price = price - discount
6 ENDIF
7 Display price
8 STOP
Desk Check
Inputs: price = $200
Correct results: price = $170.
Line Input/Outp
discount price Conditions
Number ut
1
2 200 price ? 200
200 > 100 ?
3
is T
200 * 15 / 100
4
= 30
200 - 30 =
5
170
6
7 price = 170
8
Inputs: price = $50
Correct results: price = $50.
Line disco pri Condition Input/Outp
Number unt ce s ut
1
2 50 price ? 50
50 > 100 ?
3
is F
6
7 price = 50
8

________________________________________________________________________________________________________--
Software Project Management-Mrinal Singh Rawat Page 16
Example 3
Problem Description: Display whether a student passed or failed a subject
depending on their mark.
The following example shows desk checking involving selection using an IF-
ELSE. For an IF-ELSE, if the condition evaluates to True, execution continues
to the next line after the IF and the lines up to but excluding the ELSE are
executed, then execution jumps to the ENDIF. If the condition is False,
execution jump from the IF to the ELSE, and the lines from the ELSE to the
ENDIF (inclusive) are executed.
Algorithm (with line numbers added for the Desk Check)
1 displayGrade()
2 Input mark
3 IF mark >= 50 THEN
4 grade = "Pass"
5 Display "Well done"
6 ELSE
7 grade = "Not pass"
8 ENDIF
9 Display grade
10 STOP
Desk Check
Inputs: mark = 75
Correct results: grade = "Pass", "Well done"
Line gra ma Input/Outp
Conditions
Number de rk ut
1
2 75 mark ? 75
75 >= 50 ?
3
is T
4 Pass
5 "Well done"
8
9 Pass
10
Desk Check
Inputs: mark = 40
Correct results: grade = "Not pass"
Line ma Input/Outp
grade conditions
Number rk ut
1
2 40 mark ? 40
40 >= 50 ?
3
is F
________________________________________________________________________________________________________--
Software Project Management-Mrinal Singh Rawat Page 17
6
Not
7 "Well done"
pass
8
9 Not pass
10

Walkthrough: Method of conducting informal group/individual review is

called walkthrough, in which a designer or programmer leads members of
the development team and other interested parties through a software
product, and the participants ask questions and make comments about
possible errors, violation of development standards, and other problems or
may suggest improvement on the article, walkthrough can be pre planned
or can be conducted at need basis and generally people working on the
work product are involved in the walkthrough process.
The Purpose of walkthrough is to:
Find problems Discuss alternative solutions. Focusing on demonstrating how
work product meets all requirements. IEEE 1028 recommends three
specialist roles in a walkthrough:
Leader: who conducts the walkthrough, handles administrative tasks, and
ensures orderly conduct (and who is often the Author)
Recorder: who notes all anomalies (potential defects), decisions, and action
items identified during the walkthrough meeting, normally generate minutes
of meeting at the end of walkthrough session.

Author: who presents the software product in step-by-step manner at the

walk-through meeting, and is probably responsible for completing most
action items.

Walkthrough Process:
Author describes the artifact to be reviewed to reviewers during the
meeting. Reviewers present comments, possible defects, and improvement
suggestions to the author. Recorder records all defect, suggestion during
walkthrough meeting. Based on reviewer comments, author performs any
necessary rework of the work product if required. Recorder prepares
minutes of meeting and sends the relevant stakeholders and leader is
normally to monitor overall walkthrough meeting activities as per the
defined company process or responsibilities for conducting the reviews,
generally performs monitoring activities, commitment against action items
etc.

Code Review

________________________________________________________________________________________________________--
Software Project Management-Mrinal Singh Rawat Page 18
The purpose of a code review is for someone other than the programmer
to critically go through the code of a module to ensure that it meets the
functional and design specifications, is well written and robust. An incidental
benefit is that the reviewer may learn some new programming techniques,
and more people in the team become familiar with the module. The
reviewer should not try to fix any bugs or improve the code. S/he should
merely inform the programmer about potential bugs and possible
improvements. The responsibility for actually making the changes and
testing them lies with the programmer.

Steps in Code Review

1. Obtain printouts of the specs and design documents, and of the code.
Write your comments neatly on the printouts, with your name, date and
other relevant details.
2. Read through the specs and design documents to get an understanding of
the purpose of the code and how it achieves this purpose.
3. Compare the class hierarchy and/or function call-tree from the design
document with the actual code. Note any discrepancies.
4. Identify the important data structures from the design document. Check
this against the actual code. Note any discrepancies.
5. Check for adherence to the project's coding standard (DONlab Coding
Standard in the case of TeNeT Group projects).
6. Check the style and correctness of each of the following:
(a) each file
(b) each class
(c) each function/method
7. Check the handling of exceptions and errors [
8. Check the user interaction
9. Look for common errors
10.Read the test plan. Verify that it checks the software limits.
________________________________________________________________________________________________________--
Software Project Management-Mrinal Singh Rawat Page 19
Pair-Programming
Most people associate pair programming with XP and agile development in
general, but it’s also a development process that incorporates continuous
code review. Pair programming is two developers writing code at a single
workstation with only one developer typing at a time and continuous free-
form discussion and review

Studies of pair programming have shown it to be very effective at both

finding bugs and promoting knowledge transfer. And some developers really
enjoy doing it. There’s a controversial issue about whether pair
-programming reviews are better, worse, or complementary to more
standard reviews. The reviewing developer is deeply involved in the code,
giving great thought to the issues and consequences arising from different
implementations. On the one hand this gives the reviewer lots of inspection
time and a deep insight into the problem at hand, so perhaps this means the
review is more effective. On the other hand, this closeness is exactly what
you don’t want in a reviewer; just as no author can see all typos in his own
writing, a reviewer too close to the code cannot step back and critique it
from a fresh and unbiased position.

Some people suggest using both techniques – pair-programming for the

deep review and a follow-up standard review for fresh eyes. Although this
takes a lot of developer time to implement, it would seem that this technique
would find the greatest number of defects. We’ve never seen anyone do
this in practice.
The single biggest complaint about pair programming is that it takes too
much time. Rather than having a reviewer spend 15-30 minutes reviewing a
change that took one developer a few days to make, in pair programming
you have two developers on the task the entire time.
Some developers just don’t like pair -programming; it depends on the
disposition of the developers and who is partnered with whom. Pair
programming also does not address the issue of remote developers.

________________________________________________________________________________________________________--
Software Project Management-Mrinal Singh Rawat Page 20