• PROJECT SCHEDULING AND TRACKING

• Basic concepts
• Relation between people and effort
• Defining task set for the software project
• Selecting software engineering task
• SOFTWARE CONFIGURATION MANAGEMENT
• Basics and standards
 USER INTERFACE DESIGN

• Rules
 COMPUTER AIDED SOFTWARE ENGINEERING TOOLS
• CASE building blocks
• Taxonomy of CASE tools
• Integrated CASE environment

Module VI 1
 • Basic concepts
• Relation between people and effort
• Defining task set for the software project
• Selecting software engineering task

PROJECT SCHEDULING
AND TRACKING 2
• Reasons for late delivery of software
• An unrealistic deadline
• Changing customer requirements
• underestimate of the amount of effort and/or the number
of resources that will be required to do the job.
• Predictable or unpredictable risks were not considered
• Technical difficulties could not have been foreseen in
advance.
• Human difficulties that could not have been foreseen in
advance.
• Miscommunication among project staff that results in
delays.
• A failure by project management to recognize that the
project is falling behind schedule

Basic concepts 3
• Unrealistic deadlines are the main issue of delivery
delay
• Eg: medical diagnosis s/w
• Demanded deadline: 9 months
• Estimated deadline:14 months
• If it is hard to refuse the demanded deadline,
following solutions can be applied

PROBLEM 4
• Perform a detailed estimate using historical data
from past projects.
• Determine the estimated effort and duration for the project.
 Develop a software engineering strategy using an incremental
process model
 This will deliver critical functionality by the
imposed deadline
• It delays other functionality
• Document the plan

SOLUTIONS 5
• Meet with the customer along the detailed estimate
• explain why the imposed deadline is unrealistic.
• Be certain to note that all estimates are based on
performance on past projects.
• indicate the percent improvement that would be
required to achieve the deadline
• Offer the incremental development strategy as an
alternative
• Provide options to achieve the unrealistic deadline
• Eg: Increase the budget
• Removing certain functionalities
• Compromising the quality

SOLUTIONS [2] 6
• Problem of late delivery can be overcome using
project scheduling
• Project manager must have a schedule that helps him
to control & monitor the progress of the project
• Software project scheduling
• it is an activity that distributes estimated effort
across the planned project duration by allocating
the effort to specific software engineering tasks.

PROJECT SCHEDULING 7
• Schedule evolves over time.
• During early stages of project planning, a
macroscopic schedule is developed.
• This identifies all major process framework
activities and the product functions
• As the project gets under way, each entry on the
macroscopic schedule is refined into a detailed
schedule.
• Here, specific software actions and tasks are
identified and scheduled.

Features of project
schedule 8
• Compartmentalization
• Interdependency
• Time allocation
• Effort validation
• Defined responsibilities
• Defined outcomes
• Defined milestones

BASIC PRINCIPLES 9
• The project must be compartmentalized into a
number of manageable activities and tasks.
• To accomplish compartmentalization, both the
product and the process are decomposed.

Compartmentalization 10
• The interdependency of each compartmentalized
activity or task must be determined.
• This is because
• Some tasks must occur in sequence
• Some others occur in parallel
• Some activities cannot commence until the work
product produced by another is available.
• Other activities can occur independently.

Interdependency 11
• Each task to be scheduled must be allocated with
some number of work units
• Each task must be assigned a start date and a
completion date
• This will be a function of the interdependencies,
• It depends based on whether work will be
conducted on a full-time or part-time basis.

Time allocation 12
• Every project has a defined number of people on the
software team.
• As time allocation occurs, you must ensure that no
more than the allocated number of people has been
scheduled at any given time.

Effort validation 13
• Every task that is scheduled should be assigned to a
specific team member.

Defined
responsibilities 14
• Every task that is scheduled should have a defined
outcome.
• The outcome is normally a work product or a part
of a work product.
• Work products are often combined in deliverables.

Defined outcomes 15
• Every task or group of tasks should be associated
with a project milestone.
• A Milestone is accomplished when one or more
work products has been reviewed for quality and has
been approved.

Defined milestones 16
SCHEDULING METHODS
17
• 2 types of scheduling methods are
• Program evaluation & review technique (PERT)
• Critical Path method (CPM)
• Both techniques are driven by information obtained
from project planning activities:-
• Estimates of effort
• A decomposition of product function
• Selection of appropriate process model & task set
• Decomposition of tasks

INTRODUCTION 18
• Tasks are also called as WBS
• PERT and CPM provide quantitative tools that allow
to
• Determine the critical path T1 T2 T3

• It is the chain of tasks that determines the

duration of the project,
• Establish “most likely” time estimates for
individual tasks
• Calculate “boundary times” that define a time
“window” for a particular task.

Work breakdown structure 19

• Software project schedule, planner begin with a set of
tasks
• If automated tools are used, Eg. JIRA
• the work breakdown is inputted as task network or
task outline.
• Effort, duration, and start date are given as input
for each task.
• In addition, tasks may be assigned to specific
individuals.

Timeline charts 20
• As a consequence of this input, a time-line chart, also
called a Gantt chart, is generated.
• A time-line chart can be developed for the entire
project.
• Alternatively, separate charts can be developed for
each project function or for each individual working
on the project.

Timeline charts 21
• Consider a timeline chart which shows the concept
scoping task of the word processing s/w
• All project tasks for concept scoping are listed in the
left-hand column.
• The horizontal bars indicate the duration of each
task.
• When multiple bars occur at the same time on the
calendar, task concurrency is implied.
• The diamonds indicate milestones.

Example 22
Timeline charts 23
• Once the information necessary for a time-line chart
has been inputted, software project scheduling tools
produce project tables
• It is a tabular listing of
• All project tasks,
• Planned start & end dates of the tasks
• Actual start and end dates of the tasks
• Variety of related information of the tasks
• They are used in conjunction with the time-line chart,
• project tables enable you to track progress.

Project tables 24
Project tables 25
• Project schedule defines the tasks and milestones to
be tracked and controlled as the project proceeds.
• Tracking can be accomplished in a number of
different ways:

TRACKING THE
SCHEDULE 26
• Conducting periodic project status meetings
• each team member reports progress and problems.
• Evaluating the results of all reviews conducted
• Determining whether formal project milestones have
been accomplished by the scheduled date.

Methods for project

tracking 27
• Comparing the actual start date to the planned start
date for each project task listed in the resource table.
• Meeting informally with practitioners
• to obtain their subjective assessment of progress
• To know problems on the horizon.
• Using earned value analysis to assess progress
quantitatively.

Methods for project

tracking [2] 28
RELATIONSHIP BETWEEN
PEOPLE & EFFORT

29
• If a software project is small,
• the effort of only a single person is required to
complete the project
• As size of project increases,
• effort of more people is required
• Common myth that is still believed by many
managers
• “If we fall behind schedule, we can always add
more programmers and catch up later in the
project.”

Introduction 30
• Adding people late in a project often has a disruptive
effect on the project,
• This causes schedules to slip even further.
• The people who are added must learn the system,
• People who teach them are the same people who were
doing the work.
• While teaching, no work is done,
• So the project falls further behind
• More people increase the no: of communication paths
and the complexity of communication
• Every new communication path requires additional
effort and therefore additional time

Introduction 31
• Project schedules are elastic
• It is possible to compress a desired project
completion date
• by adding additional resources to some extent.
• It is also possible to extend a completion date
• by reducing the number of resources

Elasticity of project
schedules 32
• The Putnam-Norden-Rayleigh (PNR) Curve
• This provides an indication of the relationship
between effort & delivery time for a software project.
• The curve indicates a minimum value to
• This specifies the least cost for delivery
• Ie the delivery time that will result in the least
effort
• As we move left of to, the curve rises nonlinearly
• i.e., as we try to accelerate delivery, effort required
increases

PNR curve 33
PNR curve 34
• Assume that a project team has estimated a level of effort
• Ed (effort) will be required to achieve a nominal delivery
time td.
• It is possible to accelerate delivery
• But the curve rises very sharply to the left of td .
• PNR curve indicates that the project delivery time cannot
be compressed much beyond 0.75 td
• If we attempt further compression,
• the project moves into “the impossible region”
• risk of failure becomes very high.
• The implication here is that delaying project delivery can
reduce costs significantly.

Example 35
• The number of delivered lines of code L, is related to effort and
development time by the equation:

• L = P x E1/3 t 4/3

• where E is development effort in person-months,

• P is a productivity parameter
• typical values for P range between 2000 and 12,000
• t is the project duration in calendar months.

• Rearranging this software equation, we can arrive at an expression

for development effort E:
• E= L3/ (P3t4 )
• E is the effort expended (in person-years)
• t is the development time in years.

Example 36
DEFINING A TASK SET FOR
SOFTWARE PROJECT

37
• An effective software process should define a
collection of task sets,
• A task set is a collection of
• Software engineering work tasks
• Related work products
• Quality assurance points
• Project milestones
• that must be accomplished to complete a particular
project.

DEFINING A TASK SET FOR

SOFTWARE PROJECT 38
• The task set must provide enough discipline to achieve high
software quality.
• It must not burden the project team with unnecessary work
• To develop a project schedule, a task set must be distributed on
the project time line.
• The task set will vary depending upon
DEFINING A TASK
• The project type
• And the degree of rigor with which the software team

SET FOR
decides to do its work.

SOFTWARE
PROJECT 39
• Concept development projects
• Projects that are initiated to explore some new business
concept or application of some new technology.
• New application development projects
• Projects that are undertaken as a consequence of a
specific customer request.
• Application enhancement projects
• Projects that occur when existing software undergoes
major modifications to
• function,
• performance,
Types of software
• interfaces that are observable by the end user.

projects 40
• Application maintenance projects
• Projects that correct, adapt, or extend existing software
in ways that may not be immediately obvious to the
end user.
• Reengineering projects
• Projects that are undertaken with the intent of
rebuilding an existing (legacy) system in whole or in
part.

41
 Factors that influence
task set
• Size of the project
• Number of potential users
• Mission criticality
• Application longevity
• Stability of requirements
• Ease of customer/developer communication
• Maturity of applicable technology
• Performance constraints
• Embedded and non embedded characteristics
• Project staff
• Reengineering factors.
• These factors provide an indication of
• the degree of rigor with which the software process
should be applied. 42
• Consider a tasks associated with concept development software
• Concept development projects are approached by applying the
following major tasks:
• Concept scoping
• determines the overall scope of the project.
• Preliminary concept planning
• establishes the organization’s ability to undertake the work implied
by the project scope.
• Technology risk assessment
• evaluates the risk associated with the technology to be implemented
as part of the project scope.
• Proof of concept
• demonstrates the viability of a new technology in the software
context.

Task set example 43

• Concept implementation
• implements the concept representation in a manner that
can be reviewed by a customer
• It is used for “marketing” purposes when a concept
must be sold to other customers or Management.
• Customer reaction
• Reaction to the concept solicits feedback on a new
technology concept
• targets specific customer applications.

Task set example 44

• The major tasks (i.e., software engineering actions)
described in the preceding section may be used to
define a macroscopic schedule for a project.
• However, the macroscopic schedule must be refined
to create a detailed project schedule.
• Refinement begins by taking each major task and
decomposing it into a set of subtasks (with related
work products and milestones).

Refinement of major
tasks 45
Example : concept
scoping 46
THANK YOU
47