LECTURE 5 SOFTWARE PROJECT MANAGEMENT

1
LECTURE 5SOFTWARE PROJECT MANAGEMENT
2
PLANNING AND PROCESS

• A Process is a sequence of activities undertaken
  to achieve some purpose or goal.
• Our aim here is to learn how to Design processes
  to meet goals and then to Implement the process.

3
PEOPLE, PROCESSES AND TECHNOLOGY
To start planning out a project we need to
understand the relationship between People,
Processes, and Technology. If we change one of
the parameters of a task - one of the sides of
the triangle - we may well need to adjust the
other two sides to compensate.
4
PROJECT SCHEDULING

• Processes are the foundations on which to build
  Project Plans.
• Intuitively the activities that make up the
  process need to be decomposed further and made
  concrete with descriptions of actual tasks,
  start dates, finish dates and durations.

5
PROJECT ANALYSIS

• Step 1 - Conceptual understanding of the project.
  The aim here is to understand the goals, risks,
  constraints, context and features to be
  delivered. Note that you may need a short burst
  of requirements gathering to start off!
• Step 2 - Choose an approach or lifecycle model to
  develop the system.
• Step 3 - For each of the phases in the approach a
  Work Breakdown structure to complete the task.

6
PROJECT ANALYSIS BY WORK BREAKDOWN STRUCTURES
7
WORK BREAKDOWN - THE 100 RULE

• The 100 Rule...states that the WBS includes 100
  of the work defined by the project scope and
  captures all deliverables - internal, external,
  interim -in terms of the work to be completed,
  including project management.

8
DEPENDENCIES
Tasks and sub-tasks have dependencies based on
their sequencing - that is, starting one task
will depend on the completion of another task.
Consider the task of developing a concept -
composed of three component a, b and c - to show
to a client.
9
SCHEDULING

• So far we have broken our project down into tasks
  and have worked out the dependencies between
  tasks.
• Two questions now need to be answered.
• How long will the system take to develop?
• How much will it cost?
• To answer is a complete Schedule. We already have
  part of the schedule in the tasks and the
  dependencies. What we require are the time
  estimates for each of the tasks.

10
WHY SCHEDULING IS HARD

• Estimating the complexity and effort of
  implementing certain requirements is hard.
• Productivity is not proportional to the number of
  people working on a task.
• Simply adding people to a late project does not
  improve your chances of meeting deadlines.
• The unexpected always happens. Always allow
  contingency in planning.

11
BAR CHARTS AND ACTIVITY NETWORKS

• Graphical notations are used to show the project
  schedule. They show project breakdown into tasks
  and sub-tasks.
• Activity Charts show the dependencies between
  tasks and the the Critical Path.
• Bar Charts show the schedule of tasks against
  calendar time.

• Note Tasks should not be too small for example
  on a six month project they should typically take
  about a week or two.

12
GANTT CHARTS
13
GANTT CHARTS

• Gantt charts are bar charts used to track project
  schedules and progress. Gantt charts provide us
  with information about durations, criticality.
• They come, essentially, directly from the work
  breakdown structures.

14
PERT CHARTS

• PERT (Program Evaluation and Review Technique)
  charts represent the project schedule as an
  activity network.
• The original PERT charts were designed for
  projects with uncertainty and so are ideal for
  the early stages of project planning.

15
PERT CHARTS

• We require some terminology.
• A Milestone is an event that takes zero time. It
  is often used to represent the completion of an
  activity or the delivery of something.
• An Activity is part of a project that requires
  resources and time.
• Optimistic time (O) the minimum possible time
  required to accomplish a task, assuming
  everything proceeds better than is normally
  expected.
• Pessimistic time (P) the maximum possible time
  required to accomplish a task, assuming
  everything goes wrong (but excluding major
  catastrophes).
• Most likely time (M) the best estimate of the
  time required to accomplish a task, assuming
  everything proceeds as normal.
• Expected time (TE) the best estimate of the time
  required to accomplish a task, assuming
  everything proceeds as normal

16
CONSTRUCTING AN ACTIVITY NETWORK

• Identify Goals, Activities and Milestones
• Determine the dependencies between activities and
  the sequence of activities to meet goals and
  achieve milestones
• Construct the network diagram
• Estimate activity times
• Optimistic time
• Most likely time
• Pessimistic time.
• Determine the critical path

17
TASK DURATIONS AND DEPENDENCIES
18
ACTIVITY BAR CHART
19
ACTIVITY NETWORK OR PERT
20
CRITICAL PATHS

• For each activity we need to estimate
• ES Earliest start time
• EF Earliest finish time
• LS Latest start time
• LF Latest finish time
• The length of each path is calculated by adding
  up the optimistic, expected and pessimistic
  durations of each activity on the path.
• The LONGEST path in the project is the CRITICAL
  PATH.

21
CRITICAL PATHS

• Delays on the critical path will delay the
  project.
• For the activity network above
• T1 T3 T9 T11 T12 55 days CRITCIAL
  PATH
• T1 T6 T9 T11 T12 45 days
• T1 T7 T10 43 days
• T2 T6 T9 T11 T12 52 days
• T2 T5 T10 40 days
• T4 T8 35 days

22
MAXIMUM DELAY TIMES

• Q How much time can an activity be delayed
  before it affects the project schedule?
• A As much time as possible before it delays a
  task on the critical path!

23
MAXIMUM DELAY TIMES
24
Staff allocation