Planning and Scheduling

Planning and Scheduling Objectives
Develop the necessary understanding and skills to produce and manage a simple project schedule.
Software Process Management
Planning and Scheduling 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.
Planning and Scheduling

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
All technical projects involve 100s of small tasks Some tasks do no affect the project completion Other tasks are critical for project completion Project manager must:
define all project tasks build a network that depicts their interdependence identify the critical tasks track the progress of these tasks recognize the delay one day at a time one

Two different Perspectives to view Scheduling
End date for completion has been finalized
Only Rough time-frame is given

Basic Principles for SE Scheduling
Compartmentalization define distinct tasks Interdependency- parallel and sequential tasks Interdependency Time allocation - assigned person days, start time, ending time) Effort validation - be sure resources are available Defined responsibilities people must be
assigned
Defined Outcomes- each task must have an output Outcomes Defined milestones - review for quality

People and Effort
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 Effort
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
Planning and Scheduling Effort Distribution
40-20-40
Front-end Analysis & Design
Coding
Back-end testing
Planning and Scheduling Effort Allocation

front end activities
4040-50% customer communication analysis design review and modification
1515-20%
construction activities
coding or code generation
3030-40%
testing and installation

unit, integration white-box, black box regression

Effort Distribution
(2-3%)
RA RA
(20-25%) Testing Testing (30 - 40%)
(20-25%) (15 -20%) Coding Coding SD
SD
Planning and Scheduling 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.
Planning and Scheduling 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.
Planning and Scheduling 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.
ACTIVITIES Feasibility study Requirements analysis Prototype development Design study Requirements specification
Feasibility report
Requirements definition
Evaluation report MILESTONES
Architectural design
Requirements specification
Planning and Scheduling 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 Types
Concept Development projects New Application Development Projects Application Enhancement Project Application Maintenance Project Reengineering Project
Planning and Scheduling Degree of Rigor

Casual Structured Minimum task set is Strict required Framework activities Quick Reaction Full process will be will be applied Umbrella tasks are applied Process framework minimized Umbrella tasks are of will be applied Degree discipline applied Documentation ensures high quality Only essential tasks requirements are Documentation and willactivities All umbrella be undertaken reduced measurement tasks Documentation will will be done will be applied Basic principles of in a streamlines manner workprovided after Robust be products SE are applicable product will be produced delivery

Adaptation Criteria
Size of the Project Number of potential users Mission criticality Application Longevity Stability requirements 1 Ease of communication Maturity of technology Performance constraints Embedded and non-embedded characteristics nonProject staff Reengineering factors

Task Set selector
Based on adaptation criteria, TSS is computed
TSS > 1.2
Casual
1.0 < TSS < 3.0
Structured
TSS > 2.4
Strict
Planning and Scheduling 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).
Planning and Scheduling 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.
Planning and Scheduling 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
Planning and Scheduling 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.
2
A 2d
C 2d
4
E 2d
1
B 2d
5
D 5d
Planning and Scheduling 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.
Planning and Scheduling 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
2
A 2d C 2d
4
E 2d
1
B 2d
5
D 5d

Project Scheduling
Program Evaluation and Review Technique
Critical Path Method
(PERT)
(CPM)

Project Scheduling
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

Project Scheduling
Both PERT and CPM provides quantitative tools to determine the critical path establish the most likely time estimated for individual tasks by applying statistical models calculate boundary time (window) for a particular task

Project Scheduling
Important boundary times for PERT and CPM

Earliest time a
task can begin when all preceding tasks are completed in shores possible time Total float - the amount of surplus time allowed in scheduling tasks so that the network critical path is maintained on schedule
Earliest finish - the sum of the

earliest start and the task duration
Latest time for

task initiation before the minimum project completion time is delayed
Latest finish - the

latest start time added to task duration
Planning and Scheduling 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:
Planning and Scheduling Project Table

Work Planned Tasks Start Actual Start Planned Complete Actual Person Complete Assigned Effort Needed Notes

Tracking 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
Planning and Scheduling 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)
Planning and Scheduling Tracking Earned Value

Example
Consider the following project
Planning and Scheduling 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%

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

We 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.
Planning and Scheduling 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

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

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

Project is on schedule and within budget
Project Tracking
Additional resources focussed on problem area Staff may be redeployed Project Schedule can be redefined
Problem diagnosed

Planning and Scheduling

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Planning and Scheduling

Hochgeladen von

Copyright:

Verfügbare Formate

Planning and Scheduling Objectives

Software Process Management