1. What is project scheduling&tracking?
The partitioning of the total work of a project in tasks, which deliver defined products.
The planning of those tasks in calendar time.
The allocation of resources to these tasks.
Tracking:
Following of the progress of the tasks in the course of a project.
Adapting the schedule according the latest developments.

2. Why software is delivered late?
Unrealistic deadline established outside the team
Changing customer requirements not reflected in schedule changes
Underestimating the resources required to complete the project
Risks that were not considered when project began
Technical difficulties that have not been predicted in advance
Human difficulties that have not been predicted in advance
Miscommunication among project staff resulting in delays
Failure by project management to recognize project falling behind schedule and failure to take corrective action
people, process, technology

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

4. Relationship Between People and Effort
Common management myth: If we fall behind schedule, we can always add more programmers and catch up later in the project
This practice actually has a disruptive effect and causes the schedule to slip even further
The added people must learn the system
The people who teach them are the same people who were earlier doing the work
During teaching, no work is being accomplished
Lines of communication (and the inherent delays) increase for each new person added

5. Effort Applied vs. Delivery Time
There is a nonlinear relationship between effort applied and delivery time (Ref: Putnam-Norden-Rayleigh Curve)‏
Effort increases rapidly as the delivery time is reduced
Also, delaying project delivery can reduce costs significantly as shown in the equation E = L3/(P3t4) and in the curve below
E = development effort in person-months
L = source lines of code delivered
P = productivity parameter (ranging from 2000 to 12000)‏
t = project duration in calendar months
Impossible
region
Effort
cost
Development time
t optimal
t theoretical
E optimal
E theoretical
t minimum

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

7. Putnam’s conclusion
Beginning – small number of engineers to carry out the planning and specifications.
Project progresses – detailed work- more people.
Team size should be increased and decreased based on requirements.
Constant manpower throughout – leads to wastage of effort and increase time and efforts.
Indicates extreme penalty for schedule compression and reward for expanding the schedule.

8. Effort distribution
Use the data on the organization’s historical experience with similar projects
When such data is not available, publicly available factors can be used for guidance.
The rule (a rule of thumb):
40% front-end analysis and design
20% coding
40% back-end testing
Generally accepted guidelines are:
02-03 % planning
10-25 % requirements analysis
20-25 % design
15-20 % coding
30-40 % testing and debugging

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

10. Basic principles for scheduling
Compartmentalization
decomposition of both the product and the process
the work is divided in tasks (work-breakdown structure)
each delivers (possible in combination with other tasks) a part of the product.
Interdependency
minimize the dependency between tasks
which products of other tasks are needed to start a task
sequential and parallel tasks
Time allocation for each task
How much work is needed in e.g. person-days
Determine whether this will be part-time of full-time
Assign a start and completion date (not assigned yet to a person).

11. …continued Matching total time with available resources
Are the needed resources (persons, tools, hardware) available? (not assigned yet to a person).
Defining responsibilities
Every task should be the responsibility of a person.
Defining outcomes of tasks
Each task should have a defined outcome. (SMART)
More than 1 of these work products may be grouped into a deliverable.
Defining milestones
the milestones of the project: a moment in time on which a (group of) deliverables should be finished.

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

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

14. Con..
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.

15. determine type of project assess the degree of rigor required
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

16. Software Project Types
Concept Development projects: Application of new technology.
New Application Development Projects : Specific customer requirement.
Application Enhancement Project: When existing software undergoes modification.
Application Maintenance Project: Correct, adapt existing software.
Reengineering Project: Rebuilding existing system in whole or in part.

17. Degree of Rigor Function of project characters
Small, non- business critical projects
Large, business critical projects
High quality deliverables
Etc.

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

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

20. Task Set selector Based on adaptation criteria, TSS is computed Casual
Structured
1.0 < TSS < 3.0
Strict
TSS > 2.4

22. Purpose of a Task Network
Also called an activity network
It is a graphic representation of the task flow for a project
It depicts task length, sequence, concurrency, and dependency
Points out inter-task dependencies to help the manager ensure continuous progress toward project completion
The critical path
A single path leading from start to finish in a task network
It contains the sequence of tasks that must be completed on schedule if the project as a whole is to be completed on schedule
It also determines the minimum duration of the project

23. Where is the critical path and what tasks are on it?
Example Task Network
Task F 2
Task G 3
Task H 5
Task B 3
Task N 2
Task A 3
Task C 7
Task E 8
Task I 4
Task J 5
Task M
Task D 5
Task K 3
Task L 10
Where is the critical path and what tasks are on it?

24. Example Task Network with Critical Path Marked
Task F 2
Task G 3
Task H 5
Task B 3
Task N 2
Task A 3
Task C 7
Task E 8
Task I 4
Task J 5
Task M
Task D 5
Task K 3
Task L 10
Critical path: A-B-C-E-K-L-M-N

25. Work-Breakdown Structure
A detailed breakdown of the product into manageable work elements.
A method for breaking down work within a project into logical steps:
Product WBS:
Work is broken down by system, subsystem, modules & the structure of the software product.
Activity WBS:
Work is broken down by activities of the project members such as management, requirements analysis, design & programming.

26. Product WBS

27. Activity WBS

28. Work-breakdown structure
Example
Main phases of an information system based on
software packets on the market.
Phase 1
Develop
Blueprint
Phase 2
Design
Information
system
Phase 3
Realize
Information
system
Phase 4
Implement
Information
system

29. Example Task Run time in workdays Dependencies (milestone) T1 8 T2 15
T1 (M1) T4 10 T5 19
T2, T4 (M2) T6 5
T1, T2 (M3) T7 20 T8 25
T4 (M5) T9
T3, T6 (M4)
T10
T5, T7 (M7)
T11 7
T9 (M6)
T12
T11 (M8)

30. Activity network Insight in parallel and sequential tasks
+ dependencies
15 days
14/7/99 T3
15 days
8 days M1
4/8/99 T9 T1 M4
4/7/99
25/7/99
5 days
25/8/99 M3 M6
Start T6
15 days
7 days T2
20 days
T11 T7
25/7/99
10 days
5/9/99 M2
11/8/99 T4 T5 M8 M7
10 days
18/7/99
15 days
10 days M5
T10
25 days
T12 T8
End
19/9/99

31. Critical path Start End www.educlash.com T3 M1 T9 M4 M3 M6 T2 T11 T7
15 days
14/7/99 T3
15 days
8 days M1
4/8/99 T9 T1 M4
4/7/99
25/7/99
5 days
25/8/99 M3 M6
Start T6
15 days
7 days T2
20 days
T11 T7
25/7/99
10 days
5/9/99 M2
11/8/99 T4 T5 M8 M7
10 days
18/7/99
15 days
10 days M5
T10
25 days
T12 T8
= Critical Path
End
19/9/99

32. Bar chart (Gantt chart)
4/7
18/7
11/7
1/8
25/7
8/8
22/8
15/8
29/8
5/9
12/9
19/9
26/9
Start T4 T1 T2 M1 T7 T3 M5 T8 M3 M2 T6 T5 M4 T9 M7
T10 M6
T11 M8
T12
End

33. Extra time www.educlash.com 4/7 18/7 11/7 1/8 25/7 8/8 22/8 15/8 29/8
5/9
12/9
19/9
26/9 T4 T1 T2 T7 T3
T12
End T9 T8 T5 T6
T10
T11 M1 M5 M8 M7 M4 M2 M3 M6
Start

34. Allocation of persons to tasks and time
Software Engineer T1
Jan T2
Carolien T3 T4
Frank T5
Isabel T6 T7
Jim T8 T9
T10
T11
T12
4/7
18/7
11/7
1/8
25/7
8/8
22/8
15/8
29/8
5/9
12/9
19/9
26/9
Frank
Jan
Carolien
Jim
Isabel T5 T2
T12
T11 T8 T4 T9 T3 T1 T7
T10 T6
Resources can influence the critial path,
e.g. Frank with T8-T11

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

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

37. 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 A 2d B C E D 5d

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

39. The Critical Path www.educlash.com
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

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

41. Both PERT and CPM provides quantitative tools to
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

42. Project Scheduling
Important boundary times for PERT and CPM
Total float - the amount of surplus time allowed in scheduling tasks so that the network critical path is maintained on schedule
Earliest time a task can begin when all preceding tasks are completed in shores possible time
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