Chapter 23 – Project planning

Ian Sommerville,
Software Engineering, 9th Edition
Pearson Education, Addison-Wesley

Note: These are a modified version of Ch 23 slides available from the

author’s site [Link]

1
Topics covered

 Project planning
 Software pricing
 Plan-driven development
 Project scheduling
 Agile planning
 Estimation techniques

2
Project planning

 Project planning involves breaking down the work into

parts and assign these to project team members,
anticipate problems that might arise, and prepare
tentative solutions to those problems
 In a software project, one team member is assigned the login module and another handles the
payment module. This division and preparation form part of project planning.

 The project plan, which is created at the start of a

project, is used to communicate how the work will be
done to the project team and customers, and to help
assess progress on the project
 The project plan document may state – “Design phase: 2 weeks, Coding phase: 4 weeks,
Testing phase: 2 weeks.” This helps track progress and ensure the project stays on schedule .

3
Planning stages

 Planning is done:
 At the proposal stage, when you are bidding for a contract to
develop or provide a software system
 A client needs a hospital management system, and your company submits a proposal describing
the features, cost, and timeline to win the contract.
 During the project startup phase, when you have to plan who will
work on the project, how the project will be broken down into
increments, how resources will be allocated across your company,
etc.
 One team is assigned to design the database, another to develop the user interface, and a tester
is allocated to handle quality checks.
 Periodically throughout the project, when you modify your plan in
the light of experience gained and information from monitoring the
progress of the work
 If the testing phase takes longer than expected, you adjust the schedule or assign more
developers to complete it on time.

4
Proposal planning

 Planning may be necessary with only outline software

requirements
 The aim of planning at this stage is to provide
information that will be used in setting a price for the
system to customers
 Sometimes, only the basic or outline software requirements are available, not the full details. Still,
planning is necessary to make rough estimates of time, cost, and resources. Ex: A client says
they need an “online shopping website,” but hasn’t given full details like payment gateway or
product categories. Even with this limited information, you still plan roughly how long it might take
and what resources are needed.
 The main purpose of planning at this stage is to provide enough information to decide the price of
the system for the customer. Example: Based on the rough plan, you may estimate the total cost
as ₹2,00,000 and quote that price to the client for approval.

5
Software pricing

 Estimates are made to discover the cost, to the developer, of

producing a software system
 You take into account: hardware, software, travel, training, and effort
(work time) costs. Ex-When developing an e-commerce app, the developer estimates ₹50,000
for servers, ₹30,000 for developer time, ₹10,000 for testing tools, and ₹5,000 for training — making a
total estimated cost of ₹95,000.

 There is not a simple relationship between the development cost

and the price charged to the customer
 The cost of developing the software is not always equal to the price charged to the customer. The company
may charge more or less depending on business goals or competition. Ex: Even if the development cost is
₹95,000, the company might charge the customer ₹1,20,000 to include profit and overhead costs.

 Broader organizational, economic, political and business

considerations influence the price charged
 If there’s high competition in the market, the company might reduce the price to attract customers, even if the
cost of development is high.

6
 Factors affecting software pricing

Factor Description
Market opportunity A development organization may quote a low price because
it wishes to move into a new segment of the software
market. Accepting a low profit on one project may give the
organization the opportunity to make a greater profit later.
The experience gained may also help it develop new
products.
Cost estimate If an organization is unsure of its cost estimate, it may
uncertainty increase its price by a contingency over and above its
normal profit.
Contractual terms A customer may be willing to allow the developer to retain
ownership of the source code and reuse it in other projects.
The price charged may then be less than if the software
source code is handed over to the customer.
1.A new company develops a mobile banking app at a low price to gain recognition in the fintech
market. Later, it gets more profitable contracts from other banks.
3.A client allows a developer to reuse parts of an e-
[Link] a company is not sure how long testing will
learning platform in other projects, so the developer
take, it adds an extra 10% to the project cost to
charges ₹80,000 instead of ₹1,00,000.
stay safe.
7
Factors affecting software pricing

Factor Description
Requirements volatility If the requirements are likely to change, an organization
may lower its price to win a contract. After the contract is
awarded, high prices can be charged for changes to the
requirements.
Financial health Developers in financial difficulty may lower their price to
gain a contract. It is better to make a smaller than normal
profit or break even than to go out of business. Cash flow
is more important than profit in difficult economic times.
A client asks for a basic school management system.
The company gives a low quote to get the project. A startup struggling to pay salaries lowers its
Later, when the client requests adding online fee project price to get continuous work from clients.
payment and attendance tracking, the company Though profit is less, the steady income keeps the
charges extra for those new requirements. company running.

8
 Plan-driven development

 Plan-driven or plan-based development is an approach to

software engineering where the development process is planned
in detail.
 Plan-driven development is based on engineering project management
techniques and is the ‘traditional’ way of managing large software
development projects.
in a banking software project, all stages like requirements, design, coding, and testing are planned before
the project starts.

 A project plan is created that records the work to be done, who

will do it, the development schedule, and the work products. the
plan may specify: “The login module will be developed by Rajesh and completed within 2 weeks .”

 Managers use the plan to support project decision making and

as a way of measuring progress. The manager reviews the plan daily to check if each
module is on schedule and makes adjustments if delays occur
Plan-driven development – pros and cons

 The arguments in favor of a plan-driven approach are

that early planning allows organizational issues
(availability of staff, other projects, etc.) to be closely
taken into account, and that potential problems and
dependencies are discovered before the project starts,
rather than once the project is underway
 The principal argument against plan-driven development
is that many early decisions have to be revised because
of changes to the environment in which the software is to
be developed and used
For ex, if a company plans a school management software in detail before
starting, but later the education policy changes, the project plan and
requirements will have to be revised.

10
Project plans

 In a plan-driven development project, a project plan sets out

the resources (people, software, hardware, etc. and time schedule) available to
the project, the work breakdown and a schedule for carrying
out the work
 Plan sections
 Introduction: objectives and constraints
 Project organization: team, people, roles
 Risk analysis: risks, probabilities, strategies to address risks
 Hardware and software: resource requirements
 Work breakdown: overall project activities, milestones, deliverables
 Project schedule: dependencies among activities, people and time
allocated
 Monitoring and reporting: mechanisms and reports

11
Project plan supplements

Plan Description
Quality plan Describes the quality procedures and standards that
will be used in a project.
Validation plan Describes the approach, resources, and schedule used
for system validation.
Configuration management plan Describes the configuration management procedures
and structures to be used.
Maintenance plan Predicts the maintenance requirements, costs, and
effort.
Staff development plan Describes how the skills and experience of the project
team members will be developed.

ISO 9001 standard follow, code review and

Planning user acceptance testing
testing mandatory mention
(UAT) in the final phase using test
cases and a testing team to Using Git or SVN for version control to
validate the system. track and manage changes in source
12
code
The planning process

 Project planning is an iterative process that starts when

you create an initial project plan during the project
startup phase
 Plan changes are inevitable
 As more information about the system and the project team
becomes available during the project, you should regularly
revise the plan to reflect requirements, schedule and risk
changes
 Changing business goals also leads to changes in project plans.
As business goals change, this could affect all projects, which
may then have to be re-planned.

13
The project planning process

14
Step Description Purpose
Determine limitations such as time,
1. Identify To understand what factors may restrict project
budget, manpower, and resources
Constraints activities.
before starting the project.
Recognize possible risks like delays,
To be prepared for problems that could impact
2. Identify Risks technical issues, or requirement
success.
changes.
Specify major stages (milestones) and
3. Define Milestones To track progress and ensure each phase has
expected outputs (deliverables) for
and Deliverables measurable results.
each stage.
4. Define Project Use a project planner tool to create a
To organize the sequence and timing of all tasks.
Schedule detailed timeline for all activities.
Execute tasks according to the project
5. Do the Work To begin development or implementation.
plan.
Continuously track project progress
6. Monitor Progress To ensure the project stays on time and within
and compare it with the planned
Against Plan scope.
schedule.
7. Minor Problems If small issues or delays occur, make
To correct small deviations early.
and Slippages adjustments without major changes.
If major issues arise, take corrective
8. Serious Problems To prevent project failure or severe delays.
actions.
Apply strategies to reduce or control
9. Initiate Risk
risks (e.g., add resources, change To minimize impact of serious risks. 15
Mitigation Actions
methods).
Project scheduling

 Project scheduling is the process of deciding how the

work in a project will be organized as separate tasks,
and when and how these tasks will be executed
 You estimate the calendar time needed to complete
each task, the effort required, and who will work on the
tasks that have been identified
 You also have to estimate the resources needed to
complete each task, such as the disk space required on
a server, the time required on specialized hardware,
such as a simulator, and what the travel budget will be

16
Project scheduling activities

 Split project into tasks and estimate time and resources

required to complete each task
 Organize tasks concurrently to make optimal use of
workforce
 Minimize task dependencies to avoid delays
caused by one task waiting for another to complete
 Dependent on project managers intuition and experience

17
Point Explanation Purpose / Benefit

Divide the project into smaller,

Split project into tasks and
manageable tasks and calculate
estimate time and Helps in accurate planning and tracking of
how much time and how many
resources required to project progress.
resources (people, tools, money)
complete each task
are needed for each.

Arrange tasks so that multiple

Organize tasks
tasks can be done at the same Saves time and makes full use of the
concurrently to make
time (in parallel) instead of one available workforce.
optimal use of workforce
after another.
Minimize task
dependencies to avoid
Reduce situations where one task Prevents project delays and ensures
delays caused by one task
cannot start until another finishes. smooth workflow.
waiting for another to
complete
The quality of task organization
Dependent on project
and scheduling depends on the Good management decisions lead to
manager’s intuition and
project manager’s skill, better efficiency and fewer risks.
experience
knowledge, and judgment.

18
Milestones and deliverables

 Milestones are points in the schedule against which you

can assess progress, for example, the handover of the
system for testing
Example: The handover of the system for testing can be considered a milestone.
Milestones are key points in a project schedule that help you measure progress and
track how far the project has moved.
 Deliverables are work products that are delivered to the
customer, e.g. a requirements document for the system
Deliverables are the tangible outputs or Example: A requirements
work products that are given to the document or the completed
customer as part of the project. software system is a deliverable.

19
The project scheduling process

20
Step Activity Explanation Example
List all tasks that must be
completed in the project.
Designing UI, coding modules,
1 Identify Activities Activities are derived from
testing components, etc.
software requirements and
design information.
Determine the order of
Identify Activity Testing can start only after coding
2 tasks — find which activities
Dependencies is completed.
depend on others.
Estimate the resources
Estimate Resources for Coding may require 3 developers
3 needed for each task — like
Activities and 2 weeks.
time, manpower, and tools.
Assign team members to
Allocate People to Assign frontend developers for UI
4 specific activities based on
Activities design, testers for quality checks.
their skills.
Develop project schedules
(like Gantt charts) showing A bar chart showing all project
5 Create Project Charts
timelines, dependencies, phases and their timelines.
and responsibilities.

21
 Scheduling problems

 Estimating the difficulty of problems and hence the cost of

developing a solution is hard
 Productivity is not proportional to the number of people
working on a task
 Adding people to a late project makes it later because of
communication overheads
 The unexpected always happens. Always allow contingency
in planning.

22
No Point Explanation Example
It is difficult to correctly
Estimating the difficulty of
estimate how complex a A team plans to build an app in 2
problems and hence the cost
1 problem is and how much months, but due to hidden issues and
of developing a solution is
time or cost will be needed changes, it actually takes 5 months.
hard
before starting the project.
Adding more people doesn’t
One developer can complete a website
Productivity is not always increase
in 10 days, but adding 9 more doesn’t
2 proportional to the number productivity. Coordination
make it finish in 1 day because of
of people working on a task and communication reduce
coordination time.
efficiency.
When a project is already
Adding people to a late A project is 2 weeks late. The manager
delayed, bringing new
project makes it later adds 3 new people to help, but senior
3 members adds more delay
because of communication developers spend time teaching them,
since existing members
overheads so the project becomes 4 weeks late.
must train and guide them.
Unexpected problems A project is planned for 3 months with 2
The unexpected always
always occur, so always weeks buffer. When a server fails for a
4 happens. Always allow
keep some extra time and week, the team still finishes on time due
contingency in planning.
budget as backup. to backup time.

23
Schedule representation

 Graphical notations are normally used to illustrate the

project schedule
 These show the project breakdown into tasks. Tasks
should not be too small. They should take about a week
or two.
 Bar charts are the most commonly used representation
for project schedules. They show the schedule as
activities or resources against time.

24
 Tasks, durations, and dependencies

Task Effort (person-days) Duration Dependencies

(days) Explanation
T1 15 10 Task 1 starts first (no dependency). It need
days of work over 10 days.
T2 8 15
Task 2 also starts independently and takes
T3 20 15 T1 (M1) finish.
Task 3 depends on Task 1. So, T3 can start
T4 5 10 is finished.
Task 4 can start independently, takes 10 d
T5 5 10 T2, T4 (M3)
Task 5 can begin only after both T2 and T4
T6 10 5 T1, T2 (M4) complete.
Task 6 depends on both T1 and T2. It will s
T7 25 20 T1 (M1) both are done.

T8 75 25 T4 (M2) Task 7 starts after Task 1 finishes. It needs

days over 20 days.
T9 10 15 T3, T6 (M5) Task 8 depends on T4 completion. It’s a la
person-days).
T10 20 15 T7, T8 (M6)
Task 9 depends on both T3 and T6 comple
T11 10 10 T9 (M7) Task 10 can start after both T7 and T8 are

T12 20 10 T10, T11 (M8) Task 11 starts only after T9 finishes.

25
Task 12 is the final task — it depends on T
Activity bar chart

26
 Staff allocation chart

Jane is handling several core tasks — starts with T1, later takes T3 and T9, then moves to T10
27 and
Agile planning

 Agile methods of software development are iterative

approaches where the software is developed and
delivered to customers in increments
 Unlike plan-driven approaches, the functionality of these
increments is not planned in advance but is decided
during the development
 The decision on what to include in an increment depends on
progress and on the customer’s priorities
 The customer’s priorities and requirements change so it
makes sense to have a flexible plan that can
accommodate these changes

28
Concept Explanation Example
Agile methods are iterative approaches Example: Suppose you are
to software development — this means developing a food delivery app.
the project is done in small parts Instead of building the entire app at
Agile methods
(increments) instead of all at once. Each once, you first build the login
part adds new features that are tested module, then restaurant listing, then
and shown to the customer. order tracking, and so on.
In Agile, the exact features for each part Example: Initially, the team planned
Not planned
are not fixed at the beginning. The only “cash payment.” But after
fully in
team decides during development customer feedback, they add “UPI
advance
based on feedback and changing needs. payment” in the next increment.
Customer What goes into the next increment Example: The customer says tracking
priorities depends on the customer’s most is more important than offers, so the
decide the important needs and the project’s team works on order tracking before
features progress. discount coupons.
Example: If the customer later wants
Agile follows a flexible plan that can
“dark mode” or “voice ordering,” the
Flexible plan adjust to changes in requirements or
plan changes to include those in
priorities.
future increments.

29
Agile planning stages

 There are two stages in agile planning:

 Release planning, which looks ahead for several months and
decides on the features that should be included in a release of a
system
 Iteration planning, which has a shorter term outlook, and focuses
on planning the next increment of a system. This is typically 2-4
weeks of work for the team.
Example: In a food delivery app, the
This stage plans for the next few months. It
release plan may include: ➡Version 1 –
decides which major features or modules
Login, Restaurant list ➡ Version 2 – Order
will be developed and released to the
tracking, Payment system ➡ Version 3 –
customer.
Reviews and Ratings
Example: In the current 2-week iteration,
This stage plans short-term goals (2–4
the team may work only on the order
weeks). It focuses on what tasks will be
tracking feature — design screens,
done in the next iteration or sprint, like
implement code, test it, and show it to the30
coding, testing, or fixing a specific feature.
customer.
Planning in XP- Agile planning process

31
Stage Description Example (Online Food Delivery App)
Identify user stories — short Example: “As a user, I want to track
1. Story
descriptions of what the user wants my food order so that I know when it
Identification
the software to do. will arrive.”
The team estimates time and effort
2. Initial for each story (using story points, Example: “Order tracking feature”
Estimation days, etc.) to understand the may take 8 story points or 2 weeks.
workload.
Example: Release 1 – Login & Browse
Decide which stories or features will
3. Release Restaurants, Release 2 – Order &
go into each release (months
Planning Payment, Release 3 – Order Tracking
ahead).
& Feedback
Short-term (2–4 weeks) plan
Example: In this 2-week iteration →
4. Iteration focusing on which stories to
work only on Order Tracking screens
Planning complete in the next iteration or
& backend.
sprint.
Break each user story into smaller Example: For “Order Tracking”: •
technical tasks (like coding, testing, Design tracking screen • Connect to
5. Task Planning
UI design). Assign them to team GPS API • Write backend service •
members. Test feature

32
Story-based planning

 The system specification in XP is based on user stories that reflect

the features that should be included in the system
 The project team read and discuss the stories and rank them in
order of the amount of time they think it will take to implement the
story
 Release planning involves selecting and refining the stories that will
reflect the features to be implemented in a release of a system and
the order in which the stories should be implemented -next system
release (a version of the software that will be given to users).
 Stories to be implemented in each iteration are chosen, with the
number of stories reflecting the time to deliver an iteration (usually 2
or 3 weeks-a short development cycle), they choose a few stories
that can be completed within that time.

33
Estimation techniques

 Organizations need to make software effort and cost

estimates. There are two types of technique that can be
used to do this:
 Experience-based techniques The estimate of future effort
requirements is based on the manager’s experience of past
projects and the application domain. Essentially, the manager
makes an informed judgment of what the effort requirements are
likely to be.
 Algorithmic cost modeling a formulaic approach(mathematical
formula or model) is used to compute the project effort based
on estimates of product attributes (such as size) and process
characteristics (such as experience of staff involved).

34
Experience-based approaches

 Experience-based techniques rely on judgments based

on experience of past projects and the effort expended in
these projects on software development activities
 Typically, you identify the deliverables to be produced in
a project and the different software components or
systems that are to be developed
 You document these in a spreadsheet, estimate them
individually and compute the total effort required
 It usually helps to get a group of people involved in the
effort estimation and to ask each member of the group to
explain their estimate
35
Algorithmic cost modelling

 Cost is estimated as a mathematical function of

product, project and process attributes whose
values are estimated by project managers:
 Effort = A  SizeB  M
 A is an organization-dependent constant, B reflects the
disproportionate effort for large projects and M is a multiplier
reflecting product, process, and people attributes.
 The most commonly used product attribute for cost
estimation is code size
 Most models are similar but they use different values for
A, B and M.

36
Estimation accuracy

 The size of a software system can only be known

accurately when it is finished
 Several factors influence the final size
 Use of COTS and components
 Programming language
 Distribution of system
 As the development process progresses then the size
estimate becomes more accurate-early estimates are rough, and later
ones are closer to the actual value.

 The estimates of the factors contributing to B and M are

subjective and vary according to the judgment of the
estimator-Different managers or estimators may give different estimates based on their
experience and opinion.

37
Estimate uncertainty

Y-axis (Vertical): Represents the range of estimation error or uncertainty.

The middle line ($x$ or 1x) represents a perfect estimate (the actual value).
The curves show how far off the estimate might be.

X-axis (Horizontal): Represents the project phases or

time, progressing from left to right:

38
The COCOMO 2 model

 An empirical model based on real life project experience

 Well-documented, ‘independent’ model which is not tied
to a specific software vendor(like Microsoft, IBM, etc.).
 Long history from initial version published in 1981
(COCOMO-81) through various instantiations to
COCOMO 2
 COCOMO 2 takes into account different approaches to
software development, reuse, etc. (modern software
development methods consider)

39
COCOMO 2 models

 COCOMO 2 incorporates a range of sub-models that

produce increasingly detailed software estimates
 The sub-models in COCOMO 2 are:
 Application composition model. Used when software is
composed from existing parts.
 Early design model. Used when requirements are available but
design has not yet started.
 Reuse model. Used to compute the effort of integrating reusable
components.
 Post-architecture model. Used once the system architecture has
been designed and more information about the system is
available.

40
COCOMO estimation models- four different software effort estimation
models and the metrics they use, along with the specific scenarios for which each model is best

suited .

41
 Purpose/
Estimati
Metric (Input) Application Example Application
on Model
(Context)
Systems developed
Applicati using dynamic Estimating a low-code web portal
Number of on languages, DB where a visual builder is used to
application composit programming, etc. assemble $80\%$ of the components
points ion (suitable for (screens, database calls, reports)
model component-based rather than writing code manually.
assembly).
Initial effort
estimation based Calculating the complexity of a
Number of Early on system system based on its required inputs,
function design requirements and outputs, and stored data files to get a
points model design options preliminary effort estimate before
(used early in the any coding or detailed design begins.
lifecycle).
A new mobile application is planned
Effort to integrate to reuse a $20,000$-line
Number of
reusable authentication module from an
lines of code Reuse
components or existing project. The model estimates
reused or model
automatically the time needed to adapt, integrate,
generated
generated code. and test that existing code, not the
time to write it new.
Development effort After the architecture is finalized, the 42
Post- based on detailed team estimates the final product will
Number of
Key points

 The price charged for a system does not just depend on its estimated
development costs; it may be adjusted depending on the market and
organizational priorities
 Plan-driven development is organized around a complete project plan
that defines the project activities(task), the planned
effort(time&people), the activity schedule(start/finish) and who is
responsible for each activity
 Project scheduling involves the creation of graphical representations
the project plan. Bar charts show the activity duration and staffing
timelines, are the most commonly used schedule representations.
 The agile planning game involves the whole team in project planning.
The plan is developed incrementally and, if problems arise, is
adjusted. Software functionality(feature) is reduced instead of
delaying delivery of an increment.
43
Key points

 Estimation techniques for software may be experience-

based, where managers judge the effort required, or
algorithmic, where the effort required is computed from
other estimated project parameters.
 The COCOMO II costing model is an algorithmic cost
model that uses project, product, hardware and
personnel attributes as well as product size and
complexity attributes to derive a cost estimate.

44