Software Process Management Planning and Scheduling Objectives Develop the necessary understanding and skills to produce and manage a simple project schedule

Software Process Management

Planning and Scheduling

Objectives

• Develop the necessary understanding and skills to produce and manage a simple project schedule.



Scheduling and Planning

• So far we have a project for which we have estimated duration and effort based on a high level understanding of what needs to be done.

• The majority of projects are 'completed' late, if at all. • A project schedule is required to ensure that required

project commitments are met.

• A schedule is required to track progress toward achieving these commitments.



Why Software Is Delivered Late?Why Software Is Delivered Late?

• An unrealistic deadline

• Changing but unpredicted customer requirements

• Underestimation of efforts needed

• Risks not considered at the project start

• Unforeseen technical difficulties

• Unforeseen human difficulties

• Miscommunication among project staff

• Failure to recognize that project is falling behind schedule



““One day a time”One day a time”

All technical projects involve 100s of small tasksSome tasks do no affect the project completionOther tasks are criticalcritical for project completionProject manager must:

define all project tasks build a network that depicts their interdependence identify the criticalcritical tasks track the progress of these tasks recognize the delay “one day at a time”one day at a time”



Two different Perspectives to view SchedulingTwo different Perspectives to view Scheduling

End date for completion has been finalized

End date for completion has been finalized

Only Rough time-frame is

given

Only Rough time-frame is

given



Basic Principles for SE SchedulingBasic Principles for SE Scheduling

• Compartmentalization – Compartmentalization – define distinct tasksdefine distinct tasks

• Interdependency- Interdependency- parallel and sequential tasksparallel and sequential tasks

• Time allocation - Time allocation - assigned person days, start time, assigned person days, start time, ending timeending time))

• Effort validation - Effort validation - be sure resources are availablebe sure resources are available

• Defined responsibilities Defined responsibilities — people must be people must be assignedassigned

• Defined Outcomes- Defined Outcomes- each task must have an outputeach task must have an output

• Defined milestones - Defined milestones - review for qualityreview for quality



People and EffortPeople and Effort

“If we fall behind schedule we can always add more programmers and catch to late in the project”

“If we fall behind schedule we can always add more programmers and catch to late in the project”

Has a disruptive effect on the project

Schedules slip even further



People and EffortPeople and Effort

The relationship between the number of people working in software project and

overall productivity is not linear

The relationship between the number of people working in software project and

overall productivity is not linear

Fewer people and longer time period is a better option for software

development

Fewer people and longer time period is a better option for software

development



Effort DistributionEffort Distribution

Front-end Analysis &

Design

40-20-4040-20-40

Back-end testing

Coding



Effort Allocation

40-50%40-50%

30-40%30-40%

• “front end” activities– customer communication– analysis– design– review and modification

• construction activities– coding or code generation

• testing and installation– unit, integration– white-box, black box– regression

15-20%15-20%



Effort DistributionEffort Distribution

RA

SD

Coding

PI

Testing

(2-3%)

(20-25%)

(15 -20%)

(20-25%)

(30 - 40%)

Testing

Coding

RA

SD



Scheduling and Planning

In order to make a schedule, the following tasks must be completed:• Identify manageable activities and tasks by decomposing the process and

the product. • Determine which tasks are dependent on the completion of others. (Which

activities must occur in sequence and which can occur concurrently.) • Allocate each task a number of work-units (often person-days), a start

date and a completion date. • Define responsibilities for the tasks (allocate them to a person or persons). • Define outcomes of the tasks (deliverables) and milestones for the

schedule. • Review the proposed tasks, their effort allocation and start and end dates

with the people involved to ensure there are no conflicts and over allocation.



Identifying Tasks

The first step :

identify the tasks required to be performed.

These tasks will comprise software engineering activities broken down for product functions.

A schedule is not a fixed entity and as such it will be refined as a project progresses. • Initially rough

a project schedule usually refers to the work tasks, deliverables and milestones for major software engineering activities and major product functions

• is refined in detail

as the project progresses to refer to specific tasks and activities that must be completed for those major activities and functions.



Selecting Project Tasks

No set of tasks is appropriate for all projects.

The set of tasks that are appropriate for a project depends on a number of factors. These include:• The process model selected. An iterative development model would require

different tasks, etc... than would a waterfall model or rapid application development model.

• The type of project. A new development project has a different set of tasks to a maintenance project or to a concept development.

• The size and complexity of the product.

• The rigor required in development. This is a factor generally determined by things like product size, mission criticality, stability of requirements, etc...




Many software engineering tasks have deliverables.For example, the Software Requirements Specification (SRS) might be the deliverable produced as a result of requirements analysis.

Milestones are objectively identifiable points in a project. They are generally associated with the completion of a major activity. It is often a good idea to associate them with deliverables. For example, a milestone might be established at initial requirements sign-off. This checkpoint will come after the requirements documents have been produced, inspected, corrected and signed off on. The only rule for establishing a checkpoint is that you must be able to objectively determine if that milestone

has been reached.




• Milestone = end-point of a specific, distinct software process activity or task (for each milestone a report should be presented to the management)

• Deliverable = project result delivered to the client • In order to establish milestones the phases of the software process phases

need be divided in basic activities/tasks.

EvaluationreportPrototypedevelopmentRequirementsdefinitionRequirementsanalysisFeasibilityreportFeasibilitystudy ArchitecturaldesignDesignstudyRequirementsspecificationRequirementsspecificationACTIVITIESMILESTONES



Defining Task Sets

• determine type of project

• assess the degree of rigor required– identify adaptation criteria– compute task set selector (TSS) value– interpret TSS to determine degree of rigor

• select appropriate software engineering tasks



Software Project TypesSoftware Project Types

• Concept Development projects Concept Development projects

• New Application Development Projects New Application Development Projects

• Application Enhancement ProjectApplication Enhancement Project

• Application Maintenance ProjectApplication Maintenance Project

• Reengineering ProjectReengineering Project



Degree of RigorDegree of Rigor

CasualCasual• Minimum task set is required•Umbrella tasks are minimized•Documentation requirements are reduced•Basic principles of SE are applicable

CasualCasual• Minimum task set is required•Umbrella tasks are minimized•Documentation requirements are reduced•Basic principles of SE are applicable

StructuredStructured•Framework activities will be applied•Umbrella tasks are applied•Documentation and measurement tasks will be done in a streamlines manner

StructuredStructured•Framework activities will be applied•Umbrella tasks are applied•Documentation and measurement tasks will be done in a streamlines manner

StrictStrict•Full process will be applied•Degree of discipline ensures high quality•All umbrella activities will be applied•Robust work products will be produced

StrictStrict•Full process will be applied•Degree of discipline ensures high quality•All umbrella activities will be applied•Robust work products will be produced

Quick ReactionQuick Reaction•Process framework will be applied•Only essential tasks will be undertaken• Documentation will be provided after product delivery

Quick ReactionQuick Reaction•Process framework will be applied•Only essential tasks will be undertaken• Documentation will be provided after product delivery



Adaptation CriteriaAdaptation Criteria

• Size of the ProjectSize of the Project

• Number of potential usersNumber of potential users

• Mission criticalityMission criticality

• Application Longevity Application Longevity

• Stability requirementsStability requirements

• Ease of communicationEase of communication

• Maturity of technologyMaturity of technology

• Performance constraintsPerformance constraints

• Embedded and non-embedded characteristicsEmbedded and non-embedded characteristics

• Project staffProject staff

• Reengineering factorsReengineering factors

5511



Task Set selectorTask Set selector

• Based on adaptation criteria, TSS is computedBased on adaptation criteria, TSS is computed

TSS > 1.2

StrictStrict

1.0 < TSS < 3.0

CasualCasual

TSS > 2.4

StructuredStructured



Activity Network Diagrams

An activity network diagram provides a notation for documenting • a network of tasks needed to complete a project,

• their interdependencies

• the times required for each task.

There are a number of activity network techniques which are similar in nature. The most commonly used include PERT (Project Evaluation and Review Technique) and CPM (Critical Path Method).



Pert Chart

A simple PERT chart comprises circles (nodes) to represent events within the development lifecycle

For example commencement / completion of tasks, and lines (edges) which represent the the tasks. The lines are additionally labeled by the estimated duration of the task.

Note: there are a number of variations to this notation. A real PERT chart shows earliest time to completion, latest time to completion, and slack in the circles also.



How to construct a PERT chart

The basic steps to constructing a PERT chart are:• Identify tasks and estimate duration of times

• Identify a single start and end event

• Arrange events in sequence (give events a unique number)

• Establish start and finish times of each task. Keep in mind the estimates made for duration and effort.

• Determine float

• Revise



Pert Chart

As an example of using a PERT chart, consider the following simple chart showing a project with tasks A,B,C,D and E

This diagram states that tasks A,B,C and E will take 2 days (assume d is abbreviation for days) and task D has a planned duration of 5 days.

Task D is dependent on completion of task B, etc.

1

2 4

5

3

A2d

B2d

C2d

E2d

D5d



The Critical Path

The critical path is the path between the start event and end event which takes the longest time.

Note that:• No task on the critical path can take longer without extending the end date

of the project.

• Tasks on the critical path are called critical tasks.

• No critical task can have any slack.

• Tasks on the critical path must be carefully monitored.



The Critical Path

In the example above the critical path can be described by events 1,3 and 5 or by tasks B,D. This is because the time to reach the end event (5) on this path is longer than any other path. This means that task B must take no longer than 2 days and task D no longer than 5 days or the end date for event E will need to be extended. The duration of the other path is 6 days. Because the critical path is 7 days, there is slack (or float) of one day on the other path. This means that this path can take 1 day longer than planned. That is, any one task on this path (A,C or E) can take 1 day longer than expected. Note this slack must be shared between the tasks on this other path. They can not all take an extra day

1

2 4

5

3

A2d

B2d

C2d

E2d

D5d



Project SchedulingProject Scheduling

Program Evaluation and Review Technique

(PERT)

Critical Path

Method (CPM)




Both techniques (PERT and CPM) are driven by information already developed in earlier project planning activities:– Estimates of efforts– Decomposition of product function– selection of appropriate process model and task set– Decomposition of tasks




• Both PERT and CPM provides Both PERT and CPM provides quantitative quantitative tools totools to

– determine the critical pathdetermine the critical path

– establish the most likely time estimated for establish the most likely time estimated for individual tasks by applying statistical modelsindividual tasks by applying statistical models

– calculate boundary time (window) for a particular calculate boundary time (window) for a particular tasktask




Important boundary times for PERT and CPMImportant boundary times for PERT and CPM

Earliest timeEarliest time a task can begin when all preceding tasks are completed in shores possible time

Latest timeLatest time for task initiation before the minimum project completion time is delayed

Earliest finish Earliest finish -- the sum of the earliest start and the task duration

Latest Latest finishfinish - the latest start time added to task duration

TTotal floatotal float - the amount of surplus time allowed in scheduling tasks so that the network critical path is maintained on schedule



Gantt Charts

GANTT charts are a project planning tool that can be used to represent the timing of tasks required to complete a project.

It describes similar information to a PERT chart.

Here is one that was produced automatically with a project management tool from

the PERT chart info above:



Project Table

WorkTasksPlannedStartActualStartPlannedCompleteActualCompletePersonAssignedEffortNeededNotes



Tracking the Project ScheduleTracking the Project Schedule

• It is a road map for the Software Project

• It defines the tasks and milestones

• Tracking can be done by:

– Conducting periodic project status meetings

– Evaluating the results of all reviews

– Determining whether milestones were reached by the scheduled date

– Compare actual start date to planned start date

– Meeting informally with professionals to get their subjective opinion

– Using earned value analysis



Tracking Earned Value

The earned value system provides a common value scale for every task, regardless of the type of work being performed.

The total hours to do the whole project are estimated, and every task is given an earned value based on its estimated percentage of the total.

Basically, earned value is useful as it provides a quantitative technique of assessing progress on the project as a whole (even when tasks are completed in an order that differs from the original schedule)



Tracking Earned ValueExampleConsider the following project



Calculating the planned Value

The planned value for a task is the estimated percentage of the planned duration of that task of the total planned duration of all tasks.

Planned ValueT = DT / TD

where T is a task, DT is the duration of T and TD is the total planned duration of all tasks.

Applying this formula we calculate the planned value for the planning task from the above table. We have estimated that planning will take 180 minutes. The total duration of all of our estimates for development is 2305 minutes. The planned value for the planning task by the formula above is, therefore, given by

Planned Value = 180/2305 ~ 7.81%



Calculating the planned ValueWe write this value in the planned value (unit) column for the planning task. We do the same for all of the tasks in the plan. The total of all of the unit planned values will be 100% if this is done correctly.



Calculating the planned ValueWe also wish to document when we expect each task to be completed.

In this example, this has been done by filling in the week number in the planned completion column. In order to track progress against this plan, we should have an idea of what percentage complete we expect to be at the end of each week. Notice that in the table below (most of) our tasks are listed in order of expected completion (not necessary, but advisable to start with). We keep a cumulative total of the planned value in the cumulative planned value column. We can use this column to determine what percentage of the project will be complete by the end of week 3, for example. We can see that the sum of all of the planned values for tasks planned to be complete before the end of week 3 is approx. 48.81% (because the tasks are in order, the cumulative planned value for the last week 3 entry gives us this number - if the tasks are listed unordered by completion date, the sum must be calculated by adding the planned values of all tasks due to be completed before the date in question). In the next section, we describe how to use this information to track progress.



Tracking a Project with Earned Value

Ok we have reached the end of the second week on this project and we need to know how our progress toward completion on time. We haven't done everything in the order in which it was planned, so this may not be easy to guess at. We can use the concept of an earned value. Earned value is assigned only to completed tasks. If I have completed a task with a planned value of p%, then the earned value for that task is p%. Incomplete tasks have no earned value.

In the example below, compiled at the end of the second week, we see that the group has completed the following tasks with their associated earned value:

– Planning - 7.81% – Scope - 2.64% – Product Features - 2.64% – User Profile - 1.98% – Assumptions - 2.64% – UI requirements - 5.21%

By summing the earned values for the completed tasks we determine that at the end of week 2, the cumulative earned value (the percent complete) is 7.81+2.64+2.64+1.98+2.64+5.21=22.91%.

Now, knowing the earned value the project group can determine if they are ahead, behind on on schedule to complete on time



Tracking a Project with Earned ValueLooking at the cumulative planned value in the table, we see that at the end of week 2 to be on schedule, the group should have been 33.19% complete. By the above calculation that they are actually only 22.91% complete, it appears that the project is falling behind schedule.



Tracking a Project with Earned Value

Knowing this allows the project team to take action.

Such action may involve – adjusting work practices,

– negotiating with the client for an extension to the deadline,

– etc...

It is argued that earned value provides accurate and reliable readings of performance as early as 15% into a project. This kind of quantitative project management is essential if projects are to be consistently delivered on time.




Administer Project

Resources

Cope with problems

Direct Project

staff

Control




Project is on schedule and within budget

Problem diagnosed

Additional resources focussed on problem area

Additional resources focussed on problem area

Project TrackingStaff may be redeployedStaff may be redeployed

Project Schedule can be redefinedProject Schedule can be redefined

Documents

Software Process Management Planning and Scheduling Objectives Develop the necessary understanding and skills to produce and manage a simple project schedule