Sayed Jamaluddin Afghani University

Faculty of Computer Science

Department of Software Engineering

Software Project Management (SPM)

Project Planning & Scheduling

Semester:
Lecture No.: 5th
Lecturer: Zakirullah Ezam
 1

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 and the effort
required, and you suggest who will work on the tasks that have been identified.

 You also have to estimate the hardware and software resources that are needed
to complete each task.
 2

Continue…

 Both plan-based and agile processes need an initial project schedule, although
less detail is included in an agile project plan. This initial schedule is used to
plan how people will be allocated to projects and to check the progress of the
project against its contractual commitments.

 In traditional development processes, the complete schedule is initially

developed and then modified as the project progresses.

 In agile processes, there has to be an overall schedule that identifies when the
major phases of the project will be completed. An iterative approach to
scheduling is then used to plan each phase.
 3

Continue…

 Scheduling in plan-driven projects, as shown in next figure, involves breaking

down the total work involved in a project into separate tasks and estimating the
time required to complete each task.

 Tasks should normally last at least a week and no longer than 2 months. The
maximum amount of time for any task should be 6 to 8 weeks. If a task will
take longer than this, it should be split into subtasks for project planning and
scheduling.
 4

Continue…

The Project Scheduling Process

 5

Schedule Presentation

 Project schedules may simply be documented in a table or spreadsheet showing

the tasks, estimated effort, duration, and task dependencies.

 However, this style of presentation makes it difficult to see the relationships

and dependencies between the different activities.

 For this reason, alternative graphical visualizations of project schedules have

been developed that are often easier to read and understand. Two types of
visualization are commonly used such as calendar-based bar charts and activity
networks.
 6

Types of Schedule Visualization

Calendar-based Bar Charts

 Calendar-based bar charts show who is responsible for each activity, the
expected elapsed time, and when the activity is scheduled to begin and end. Bar
charts are also called Gantt charts, after their inventor, Henry Gantt.

Activity Networks
 Activity networks show the dependencies between the different activities
making up a project. These networks are described in an associated web
section.
 7

Continue…

 Project activities are the basic planning element. Each activity has:
1) A duration in calendar days or months
2) An effort estimate, which shows the number of person-days or person-months
to complete the work
3) A deadline by which the activity should be complete
4) A defined endpoint, which might be a document, the holding of a review
meeting, the successful execution of all tests, or the like.
 8

Continue…

 When planning a project, you may decide to define project milestones. A mile
stone is a logical end to a stage of the project where the progress of the work
can be reviewed.

 Each milestone should be documented by a brief report (often simply an email)

that summarizes the work done and whether or not the work has been
completed as planned. Milestones may be associated with a single task or with
groups of related activities.
 9

Continue…

 Some activities create project deliverables. Project deliverables are the outputs
that are delivered to the software customer.

 Usually, the deliverables that are required are specified in the project contract,
and the customer’s view of the project’s progress depends on these
deliverables.

 Milestones and deliverables are not the same thing. Milestones are short reports
that are used for progress reporting, whereas deliverables are more substantial
project outputs such as a requirements document or the initial implementation
of a system.
 10

Project Planning Tools

 Normally, you should use a project planning tool, such as the Basecamp or
Microsoft project, to create, update, and analyze project schedule information.

 Project management tools usually expect you to input project information into a
table, and they create a database of project information. Bar charts and activity
charts can then be generated automatically from this database
 11

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 argument for this approach is that the customer’s priorities and
requirements change, so it makes sense to have a flexible plan that can
accommodate these changes.
 12

Continue…

 Agile development methods such as Scrum and Extreme Programming have

a two-stage approach to planning, corresponding to the startup phase in plan-
driven development and development planning:
1. Release planning, which looks ahead for several months and decides on the
features that should be included in a release of a system.
2. Iteration planning, which has a shorter term outlook and focuses on planning
the next increment of a system. This usually represents 2 to 4 weeks of work
for the team.
 13

Release Planning

 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.

 The customer has to be involved in this process. A release date is then chosen,
and the stories are examined to see if the effort estimate is consistent with that
date. If not, stories are added or removed from the list.
 14

Iteration Planning

 Iteration planning is the first stage in developing a deliverable system

increment. Stories to be implemented during that iteration are chosen, with the
number of stories reflecting the time to deliver a workable system (usually 2 or
3 weeks) and the team’s velocity.

 When the delivery date is reached, the development iteration is complete, even
if all of the stories have not been implemented.

 The team considers the stories that have been implemented and adds up their
effort points. The velocity can then be recalculated, and this measure is used in
planning the next version of the system.
 15

Scrum and Extreme Programming

 Scrum approach to planning is based on project backlogs and daily reviews of

work to be done. It is primarily geared to iteration planning.
 Another approach to agile planning, which was developed as part of Extreme
Programming, is based on user stories. The so-called planning game can be
used in both release planning and iteration planning.

 The basis of the planning game is a set of user stories that cover all of the
functionality to be included in the final system.

 The development team and the software customer work together to develop
these stories. The team members read and discuss the stories and rank them
based on the amount of time they think it will take to implement the story.
Some stories may be too large to implement in a single iteration, and these are
broken down into smaller stories.
 16

Continue…

The “Panning Game”

 17

Ranking Stories

 The problem with ranking stories is that people often find it difficult to estimate
how much effort or time is needed to do something. To make this easier,
relative ranking may be used.

 The team compares stories in pairs and decides which will take the most time
and effort, without assessing exactly how much effort will be required. At the
end of this process, the list of stories has been ordered, with the stories at the
top of the list taking the most effort to implement.

 The team then allocates notional effort points to all of the stories in the list. A
complex story may have 8 points and a simple story 2 points.
 18

Velocity Estimate

 Once the stories have been estimated, the relative effort is translated into the
first estimate of the total effort required by using the idea of “velocity.”

 Velocity is the number of effort points implemented by the team, per day. This
can be estimated either from previous experience or by developing one or two
stories to see how much time is required.

 Once you have a velocity estimate, you can calculate the total effort in person-
days to implement the system.
 19

Estimation Techniques

 Estimating project schedules is difficult. You have to make initial estimates on

the basis of an incomplete user requirements definition.

 The software may have to run on unfamiliar platforms or use new development
technology. The people involved in the project and their skills will probably not
be known.

 There are so many uncertainties that it is impossible to estimate system

development costs accurately during the early stages of a project. However,
organizations need to make software effort and cost estimates.
 20

Types of Estimation Techniques

 Two types of techniques can be used for making estimates:

1. 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.

2. Algorithmic Cost Modeling

In this approach, a formulaic approach is used to compute the project effort based
on estimates of product attributes, such as size, process characteristics, and
experience of staff involved.
 21

Continue…

 In both cases, you need to use your judgment to estimate either the effort
directly or the project and product characteristics. In the startup phase of a
project, these estimates have a wide margin of error.

 Based on data collected from a large number of projects, a research study

discovered that startup estimates vary significantly.

 If the initial estimate of effort required is x months of effort, they found that the
range may be from 0.25x to 4x of the actual effort as measured when the
system was delivered.

 During development planning, estimates become more and more accurate as

the project progresses.
 22

Continue…

Estimate Uncertainty
 23

Experience-based Technique

 Experience-based techniques rely on the manager’s experience of past projects

and the actual effort expended in these projects on activities that are related to
software development.

 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.
 24

Weakness of Experience-based Technique

 The difficulty with experience-based techniques is that a new software project

may not have much in common with previous projects.

 Software development changes very quickly, and a project will often use
unfamiliar techniques such as web services, application system configuration,
or HTML5.

 If you have not worked with these techniques, your previous experience may
not help you to estimate the effort required, making it more difficult to produce
accurate costs and schedule estimates.
 25

Continue…

 It is impossible to say whether experience-based or algorithmic approaches are

more accurate. Project estimates are often self-fulfilling.

 The estimate is used to define the project budget, and the product is adjusted so
that the budget figure is realized. A project that is within budget may have
achieved this at the expense of features in the software being developed.
 26

Algorithmic Cost Modeling

 Algorithmic cost modeling uses a mathematical formula to predict project costs

based on estimates of the project size, the type of software being developed,
and other team, process, and product factors.

 Algorithmic cost models are developed by analyzing the costs and attributes of
completed projects, then finding the closest-fit formula to the actual costs
gained.

 Algorithmic cost models are primarily used to make estimates of software

development costs.
 27

Formula for Effort Estimation

 However, some research studies demonstrated a range of other uses for these
models, such as the preparation of estimates for investors in software
companies, alternative strategies to help assess risks and to inform decisions
about reuse, redevelopment, or outsourcing.

 Most algorithmic models for estimating effort in a software project are based
on a simple formula:
 28

Continue…

 A: A constant factor, which depends on local organizational practices and the

type of software that is developed.

 Size: An assessment of the code size of the software or a functionality estimate

expressed in function or application points.

 B: Represents the complexity of the software and usually lies between 1 and
1.5.

 m: Is a factor that takes into account process, product and development

attributes, such as the dependability requirements for the software and the
experience of the development team.
 29

Drawbacks of Algorithmic Cost Models

 The idea of using a scientific and objective approach to cost estimation is an

attractive one, but all algorithmic cost models suffer from two key problems:

1) It is practically impossible to estimate Size accurately at an early stage in a

project, when only the specification is available.

2) The estimates of the complexity and process factors contributing to B and m

are independent. Estimates vary from one person to another, depending on their
background and experience of the type of system that is being developed.