SCHEDULING

Root causes of failing of schedule

An unrealistic deadline established by someone outside the
software development group.
Changing customer requirements that are not reflected in
schedule changes.
An honest underestimate of the amount of effort and the
number of resources.
Predictable and unpredictable risks that were not
considered when project commenced.
Technical difficulties that could not have been foreseen in
advance
Miscommunication among project staff that result delays.
 Comments on “Lateness”
 Perform a detailed estimate using historical data from
past projects. Determine the estimated effort and
duration for the project.
 Using an incremental process model ,develop a software
engineering strategy that will deliver critical functionality
by the imposed deadline , but delay other functionality
until later.
 Meet with the customer and explain why the imposed
deadline is unrealistic. Be certain to note that all
estimates are based on performance on past projects.
 Offer the incremental development strategy as an
alternative (increase budget and bring additional
resource)
 Basic principles
 Compartmentalization – the project must be
compartmentalized into a number of
manageable activities and tasks. To accomplish
compartmentalization both the product and the
process are decomposed.
 Interdependency - the interdependency of each
compartmentalized activity or task must be
determined .some tasks must occur in sequence
while others can occur in parallel.
 Basic principles
 Time allocation - each task to be scheduled
must be allocated some number of work units.
in addition each must be assigned a start date
and a completion date .
 Effort validation - every project has a defined
number of staff numbers. As time allocation
occurs , the project manager must ensure that
no more than the allocated number of people
have been scheduled at any given time.
 Basic principles
 Defined responsibilities – every task that is
scheduled should be assigned to a
specific team member.
 Defined outcomes - every task that is
scheduled should have defined outcome.
 Defined milestones - every task or group
of tasks should be associated with a
project milestone.
 Defining a task set
 A task set is a collection of software engineering
work tasks , milestones and deliverables that must
be accomplished to complete a particular project.
 Task set are designed to accommodate different
types of projects and different degrees of rigor.
 Concept development projects - that are initiated to
explore some new business concept or application of
some new technology.
 New application development projects - that are
undertaken as a sequence of a specific customer
request.
 Defining a task set
 Application enhancement projects - that occur
when existing software undergoes major
modification to function, performance or
interface.
 Application maintenance projects - that
correct ,adapt or extent existing software in ways
that may not be immediately obvious to the end
user.
 Reengineering projects - that are undertaken
with the intent of rebuilding an existing system in
whole or in part.
 Degree of rigor
 Even for a project of a particular type , the
degree of rigor with which the software
process is applied may vary significantly.
The degree of rigor is a function of many
project characteristics.
 Casual-all process framework activities
are applied, but only a minimum task set is
required .
 Degree of rigor
 Structured - the process framework activities
are applied for this project. framework activities
and related tasks appropriate to the project type
will be applied and activities necessary to ensure
high quality.
 Strict - the full process will be applied for this
project with a degree of discipline that will
ensure high quality.
 Quick reaction - the process frame work will be
applied for this project , but because of
emergency situation only those tasks essential
to maintaining good quality will be applied.
 Adaptation criteria
 Adaptation criteria are used to determine the
recommended degree of rigor with which the
software process should be applied on a project.
Eleven Adaptation criteria are defined for
software projects:
 Size of project
 Number of potential users
 Mission criticality
 Application longevity
 Stability of requirements
 Adaptation criteria
 Ease of customer
 Maturity of application technology
 Performance constraints
 Embedded and non embedded
characteristics
 Project staff
 Reengineering factors
 scheduling
 Scheduling of a software project does not differ
greatly from scheduling of any multitask
engineering effort.
 PERT and CPM are two project scheduling
method that can be applied to software
development.
 Both PERT and CPM provide quantitative tools
that allow software planner to
 Determine the critical path (duration of project)
 Establish “most likely” time estimate for individual
tasks by applying statistical models
 scheduling
 Calculate “boundary time” that define a time
“window” for a particular task
 Important boundary times
 The earliest time that a task can begin
 The latest time for task initiation
 The earliest finishing time
 The latest finishing time
 The total float- the surplus time allowed in
scheduling tasks so that the network critical
path is maintained on schedule.