INF3708 SUMMARY

2020
UNISA
Semester 1
 1

Contents
Chapter 1........................................................................................................................................ 4

*Characteristics that distinguish projects: [10] .............................................................. 4

*Characteristics of software projects which make them particularly difficult (as
identified by Fred Brooks): [4] ......................................................................................... 4
Successive processes that bring a new system into being: [3] ................................... 4
ISO 12207 Software Development Life Cycle: [13] ....................................................... 5
Types of Stakeholders: [3] ............................................................................................... 5
Software project objectives: [4] ..................................................................................... 6
Management Activities: [8] ............................................................................................ 6
Chapter 2........................................................................................................................................ 7

Business case (for a feasibility study) document contains: [10] .................................. 7

Key aspects of project portfolio management: [3] ..................................................... 7
Categories of direct costs: [3] ........................................................................................ 7
*Net Profit: ........................................................................................................................ 7
*Payback Period: ............................................................................................................ 7
*Return on Investment (ROI): .......................................................................................... 8
*Net Present Value (NPV): .............................................................................................. 8
Programme Management: ............................................................................................ 8
Different forms of programmes: [5]................................................................................ 8
Sections of a business case’s programme brief: [3] ..................................................... 8
Chapter 3...................................................................................................................................... 10

Step Wise: [11] ............................................................................................................... 10

Chapter 4...................................................................................................................................... 11

*Advantages of running off-the-shelf software: [3] .................................................... 11

*Disadvantages of running off-the-shelf software: [4]................................................ 11
Project characteristics: [6] ............................................................................................ 11
Types of uncertainties: [3] ............................................................................................. 11
The waterfall model: [8] ................................................................................................ 12
Types of prototypes: [2] ................................................................................................ 12
Advantages of prototypes: [9]..................................................................................... 12
Disadvantages of prototypes: [6] ................................................................................ 12
Types of changes during prototyping: [3] ................................................................... 13
 2

Advantages of incremental delivery: [8] .................................................................... 13

Disadvantages of incremental delivery: [3] ................................................................ 13
*Agile manifesto: [4]...................................................................................................... 13
Core Atern (Agile) principles: [8] ................................................................................. 13
Atern life-cycle phases: [4] ........................................................................................... 14
Importance of requirements (MoSCoW): [4] .............................................................. 14
XP principles: [4] ............................................................................................................ 14
XP practices: [12] .......................................................................................................... 14
XP limitations: [5] (p. 98 – 99) ........................................................................................ 15
Chapter 5...................................................................................................................................... 16

Difficulties of estimating effort: [6] ............................................................................... 16

Calculating estimated effort: ....................................................................................... 16
Laws for over- and under-estimates: [3] ...................................................................... 16
Bottom-up estimation: .................................................................................................. 16
Top-down estimation: ................................................................................................... 16
Euclidian distance: ........................................................................................................ 17
COnstructive COst MOdel (COCOMO): ..................................................................... 17
Stages of COCOMO II: [3] ............................................................................................ 17
COCOMO II: .................................................................................................................. 17
Chapter 6...................................................................................................................................... 19

Objectives of activity planning [5]............................................................................... 19

Approaches to identifying activities [3] ...................................................................... 19
Network planning models [3] ....................................................................................... 19
Precedence network (activity-on-node) rules [8] ...................................................... 19
Labelling conventions ................................................................................................... 20
Activity float [2] ............................................................................................................. 20
Activity-on-arrow rules [8] ............................................................................................. 20
Labelling conventions ................................................................................................... 21
Chapter 7...................................................................................................................................... 22

Lyytinen-Mathiassen-Ropponen risk framework (STAT) [4] ......................................... 22

*Framework for dealing with risks [4] ........................................................................... 22
Risk exposure ................................................................................................................. 22
Risk planning alternatives [4] ........................................................................................ 22
Risk Reduction Leverage (RRL)..................................................................................... 22
 3

*PERT ............................................................................................................................... 23
Steps for calculating the probability of meeting/missing target date ..................... 23
Chapter 8...................................................................................................................................... 24

Categories of Resources [7] ......................................................................................... 24

*Factors to consider when allocating individuals to tasks [5] .................................... 24
Categories of cost [3] ................................................................................................... 24
Chapter 9...................................................................................................................................... 25

Traffic-light method steps [5] ........................................................................................ 25

Earned Value Analysis................................................................................................... 25
*Prioritizing Monitoring [5] ............................................................................................. 26
*Ways to shorten the critical path [5] .......................................................................... 26
Bibliography.................................................................................................................................. 27
 4

CHAPTER 1
*Characteristics that distinguish projects: [10]1
❖ Non-routine tasks are involved.
❖ Planning is required.
❖ Specific objectives are to be met or a specified product is to be created.
❖ The project has a predetermined time span.
❖ Work is carried out for someone other than yourself.
❖ Work involves several specialisms.
❖ People are formed into a temporary work group to carry out the task.
❖ Work is carried out in several phases.
❖ The resources that are available for use on the project are constrained.
❖ The project is large or complex.

*Characteristics of software projects which make them particularly

difficult (as identified by Fred Brooks): [4]2
❖ Invisibility – When a physical artefact (e.g. a bridge) is constructed the progress
can actually be seen. With software, progress is not immediately visible.
❖ Complexity – Software products contain more complexity than other engineered
artefacts per dollar/pound/euro/rand spent.
❖ Conformity – ‘Traditional’ engineers work with physical systems and materials
which are governed by consistent physical laws. Software developers have to
conform to the requirements of human clients.
❖ Flexibility – Software is easy to change (which is one of its greatest strengths) and
must therefore change to accommodate the physical or organizational system it
interfaces with, not the other way around.

Successive processes that bring a new system into being: [3]3

1. Feasibility Study (Is it worth doing?)
2. Plan (How do we do it?)
3. Project Execution (Do it!)

1 p. 3
2 pp. 4-5
3 pp. 5-6
 5

ISO 12207 Software Development Life Cycle: [13]4

❖ Requirements:
o Requirements analysis.
o Architecture design.
o Requirements analysis.
❖ Design:
o Architecture design.
o Requirements analysis.
❖ Code and Test:
o Detailed design.
o Code and test.
o Integration.
o Qualification test.
o Integration.
o Qualification test.
❖ Installation/Acceptance Support:
o Installation.
o Acceptance Support.

Types of Stakeholders: [3]5

Organization

Project Team

A: Internal to the project team (and implicitly to the organization).

B: External to the project team, but within the same organization.
C: External to both the project team and the organization.

4 pp. 6-8
5 p. 11
 6

Well-defined objectives are described by: [5]6

SMART:

❖ Specific
❖ Measurable
❖ Achievable
❖ Relevant
❖ Time constrained

Software project objectives: [4]7

❖ The agreed functionality is delivered
❖ To the required level of quality
❖ On time
❖ Within budget

Management Activities: [8]8

❖ Planning – Deciding what is to be done.
❖ Organizing – Making arrangements.
❖ Staffing – Selecting the right people for the job.
❖ Directing – Giving instructions.
❖ Monitoring – Checking on progress.
❖ Controlling – Taking action to remedy hold-ups.
❖ Innovating – Coming up with new solutions.
❖ Representing – Liaising with clients, users, developer, suppliers and other
stakeholders.

6 p. 12
7 p. 14
8 p. 15
 7

CHAPTER 2
Business case (for a feasibility study) document contains: [10]9
1. Introduction and background to the proposal
2. The proposed project
3. The market
4. Organizational and operational infrastructure
5. The benefits
6. Outline implementation plan
7. Costs
8. The financial case
9. Risks
10. Management plan

Key aspects of project portfolio management: [3]10

❖ Portfolio definition
❖ Portfolio management
❖ Portfolio optimization

Categories of direct costs: [3]11

❖ Development costs – including development staff costs
❖ Setup costs – the costs of putting the system into place (new hardware, file
conversion, recruitment, staff training).
❖ Operational costs – cost of operating the system after installation.

*Net Profit12:
𝑁𝑒𝑡 𝑃𝑟𝑜𝑓𝑖𝑡 = 𝑇𝑜𝑡𝑎𝑙 𝐼𝑛𝑐𝑜𝑚𝑒 − 𝑇𝑜𝑡𝑎𝑙 𝐶𝑜𝑠𝑡𝑠

*Payback Period13:
The time it takes to break (or pay back) the initial investment (costs).

9 p. 22
10 p. 24
11 pp. 26-27
12 p. 28
13 p. 29
 8

*Return on Investment (ROI)14:

Compares the net profitability to the investment required.
Also known as Accounting Rate of Return (ARR).

𝑛𝑒𝑡 𝑝𝑟𝑜𝑓𝑖𝑡
𝑎𝑣𝑒𝑟𝑎𝑔𝑒 𝑎𝑛𝑛𝑢𝑎𝑙 𝑝𝑟𝑜𝑓𝑖𝑡 ( )
𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑦𝑒𝑎𝑟𝑠 𝑔𝑖𝑣𝑒𝑛
𝑅𝑂𝐼 = × 100 = × 100
𝑡𝑜𝑡𝑎𝑙 𝑖𝑛𝑣𝑒𝑠𝑡𝑚𝑒𝑛𝑡 𝑡𝑜𝑡𝑎𝑙 𝑖𝑛𝑣𝑒𝑠𝑡𝑚𝑒𝑛𝑡

Disadvantages:

❖ Takes no account of the timing of the cash flows.

❖ Bears no relationship to the interest rates offered or charged by banks.

*Net Present Value (NPV)15:

Takes into account the profitability of a project and the timing of the cash flows.

𝑣𝑎𝑙𝑢𝑒 𝑖𝑛 𝑦𝑒𝑎𝑟 𝑡
𝑃𝑟𝑒𝑠𝑒𝑛𝑡 𝑉𝑎𝑙𝑢𝑒 =
(1 + 𝑟)𝑡
Where 𝑟 = 𝑑𝑖𝑠𝑐𝑜𝑢𝑛𝑡 𝑟𝑎𝑡𝑒.

𝑁𝑃𝑉 = ∑𝑃𝑟𝑒𝑠𝑒𝑛𝑡 𝑉𝑎𝑙𝑢𝑒𝑠 = 𝑇ℎ𝑒 𝑠𝑢𝑚 𝑜𝑓 𝑒𝑣𝑒𝑟𝑦 𝑐𝑎𝑠ℎ 𝑓𝑙𝑜𝑤 ′ 𝑠 𝑝𝑟𝑒𝑠𝑒𝑛𝑡 𝑣𝑎𝑙𝑢𝑒

Programme Management16:
D.C. Ferns defined a programme as ‘a group of projects that are managed in a
coordinated way to gain benefits that would not be possible were the projects to be
managed independently’.

Different forms of programmes: [5]17

❖ Business cycle programmes
❖ Strategic programmes
❖ Infrastructure programmes
❖ Research and development programmes
❖ Innovative partnerships

Sections of a business case’s programme brief: [3]18

❖ Preliminary vision statement – Describes the new capacity that the organization
seeks.

14 p. 30
15 p. 31
16 p. 38
17 pp. 38-39
18 p. 41
 9

❖ The benefits that the programme should create – including when they are likely
to be generated and how they might be measured.
❖ Risks and issues.
❖ Estimated costs, timescales and effort.
 10

CHAPTER 3
Step Wise: [11]19
0. Select project
1. Identify project scope and objectives
2. Identify project infrastructure
3. Analyse project characteristics
4. Identify the products and activities
5. Estimate effort for each activity
6. Identify activity risks
7. Allocate resources
8. Review/Publicise plan
9. Execute plan
10. Lower-level planning

19 p. 51
 11

CHAPTER 4
*Advantages of running off-the-shelf software: [3]20
❖ Reduced cost per customer, because the supplier of the application can spread
the cost of development over a large number of customers.
❖ The software already exists, and so:
o It can be tested/examined before acquisition.
o There is no delay while the software is being developed.
❖ More reliable software, because most bugs have already been reported by
existing customers.

*Disadvantages of running off-the-shelf software: [4]21

❖ No competitive advantage, because other companies can use the same
software.
❖ Some work procedures may need to be adjusted, because although modern off-
the-shelf software is customizable, it is only customizable to a certain extent.
❖ You will not own the software, and therefore prevents you from changing it as
necessary.
❖ You may become a captive customer, where users rely heavily on the bought
software and are reluctant to switch to alternative options.

Project characteristics: [6]22

❖ Data-oriented vs. process-oriented
❖ General vs. application specific
❖ Concurrent processing | Knowledge-based | Computer graphic intensive
❖ Safety critical
❖ Predefined services vs. engaging & entertaining
❖ Nature of hardware/software environment

Types of uncertainties: [3]23

❖ Product uncertainty – How well are the requirements understood?

20 pp. 75-76
21 p. 76
22 pp. 77-78
23 p. 79
 12

❖ Process uncertainty – How well is the approach to meet these requirements

understood?
❖ Resource uncertainty – Which resources will be used to meet the requirements?

The waterfall model: [8]24

❖ Feasibility study
❖ User requirements
❖ Analysis
❖ System design
❖ Program design
❖ Coding
❖ Testing
❖ Operation

Types of prototypes: [2]25

❖ Throw-away (temporary)
❖ Evolutionary (much like the skeleton analogy where, after each iteration, more
and more flesh is added to the prototype and it eventually evolves into the full
system).

Advantages of prototypes: [9]26

❖ Learning by doing.
❖ Improved communication.
❖ Improved user involvement.
❖ Clarification of partially known requirements.
❖ Demonstration of consistency and completeness of a specification.
❖ Reduced need for documentation.
❖ Reduced maintenance costs.
❖ Feature constraint.
❖ Production of expected results.

Disadvantages of prototypes: [6]27

❖ Users can misunderstand the role of a prototype.
❖ Lack of project standards is possible.
❖ Lack of control.
❖ Additional expense.

24 p. 83
25 p. 85
26 p. 85-86
27 p. 86
 13

❖ Machine efficiency.
❖ Close proximity of developers.

Types of changes during prototyping: [3]28

❖ Cosmetic (UI changes)
❖ Local (to one part of the system)
❖ Global (to more than one part of the system)

Advantages of incremental delivery: [8]29

❖ Feedback from previous increments improves the quality of future increments.
❖ Possibility of changing requirements are reduced.
❖ Benefits are realized/felt earlier.
❖ Improved cash flow, because you get some return on investment early on.
❖ Smaller increments are easier to control and manage.
❖ Gold-plating (request for unnecessary features) is reduced, because users know
that it can be implemented later.
❖ The project can be temporarily abandoned.
❖ Increased job satisfaction.

Disadvantages of incremental delivery: [3]30

❖ Software breakage (later increments may require modifications of earlier
increments).
❖ Developers may be less productive working on smaller projects than larger ones.
❖ Conceptual integrity might be compromised.

*Agile manifesto: [4]31

❖ Value individuals and interactions over processes and tools.
❖ Value working software over comprehensive documentation.
❖ Value customer collaboration over contract negotiation.
❖ Value responding to change over following a plan.

Core Atern (Agile) principles: [8]32

❖ Focus on business need.
❖ Deliver on time.
❖ Collaborate.

28 p. 88
29 p. 89-90
30 p. 90
31 p. 93
32 pp. 93-94
 14

❖ Never compromise quality.

❖ Develop iteratively.
❖ Build incrementally from foundations.
❖ Communicate continuously.
❖ Demonstrate control.

Atern life-cycle phases: [4]33

❖ Feasibility/Foundation
❖ Exploration cycle
❖ Engineering cycle
❖ Deployment

Importance of requirements (MoSCoW): [4]34

❖ Must have
❖ Should have
❖ Could have
❖ Won’t have

XP principles: [4]35
❖ Communication and feedback
❖ Simplicity
❖ Responsibility
❖ Courage

XP practices: [12]36
❖ The planning exercise
❖ Small releases
❖ Metaphor
❖ Simple design
❖ Testing
❖ Refactoring
❖ Pair programming
❖ Collective ownership
❖ Continuous integration
❖ 40-hour weeks
❖ On-site customers

33 pp. 94-95
34 p. 95
35 pp. 95-96
36 pp. 96-98
 15

❖ Coding standards

XP limitations: [5]37 (p. 98 – 99)

❖ There must be easy access to users.
❖ Developers need to work in the same office.
❖ Communication problems might exist because users find out about how the
system will work only through working code (not visual interfaces)
❖ It must be possible to break the system functionality into small and self-contained
components.
❖ Large and complex systems may need significant architectural effort.

37 pp. 98-99
 16

CHAPTER 5
Difficulties of estimating effort: [6]38
❖ Complexity
❖ Invisibility
❖ The nature of estimation is subjective
❖ Political implications
❖ Changing technology
❖ Lack of homogeneity of project experience

Calculating estimated effort:

𝑆𝐿𝑂𝐶
𝐸𝑠𝑡𝑖𝑚𝑎𝑡𝑒𝑑 𝑤𝑜𝑟𝑘 𝑚𝑜𝑛𝑡ℎ𝑠 =
𝑂𝑣𝑒𝑟𝑎𝑙𝑙 𝑆𝐿𝑂𝐶 𝑝𝑒𝑟 𝑚𝑜𝑛𝑡ℎ

𝑆𝐿𝑂𝐶
𝑂𝑣𝑒𝑟𝑎𝑙𝑙 𝑆𝐿𝑂𝐶 𝑝𝑒𝑟 𝑚𝑜𝑛𝑡ℎ = ∑
𝑤𝑜𝑟𝑘 𝑚𝑜𝑛𝑡ℎ𝑠

Laws for over- and under-estimates: [3]39

❖ Parkinson’s Law – Work expands to fill the time available.
❖ Brooks’ Law – Putting more people on a late job makes it later.
❖ Weinberg’s zeroth law of reliability – If a system does not have to be reliable, it
can meet any other objective.

Bottom-up estimation40:
The project is (recursively) broken up into smaller component tasks that should typically
take a week or two for an individual to complete. The calculated effort for each activity
is then added up to get an overall estimate, hence the “Bottom-up”.

Top-down estimation41:
The top-down approach is normally associated with parametric (or algorithmic) models.
A simple example would be:
𝑒𝑓𝑓𝑜𝑟𝑡 = (𝑠𝑖𝑧𝑒) × (𝑝𝑟𝑜𝑑𝑢𝑐𝑡𝑖𝑣𝑖𝑡𝑦)

38 p. 104
39 p. 107
40 p. 109
41 pp. 111-112
 17

Where 𝑠𝑖𝑧𝑒 is typically measured in KLOC (thousands of lines of code), and 𝑝𝑟𝑜𝑑𝑢𝑐𝑡𝑖𝑣𝑖𝑡𝑦
may be measured as 𝑑𝑎𝑦𝑠 𝑝𝑒𝑟 𝐾𝐿𝑂𝐶.
From the above expression, we could use simple arithmetic to obtain:
𝑒𝑓𝑓𝑜𝑟𝑡
𝑝𝑟𝑜𝑑𝑢𝑐𝑡𝑖𝑣𝑖𝑡𝑦 =
𝑠𝑖𝑧𝑒
A slightly more complex example would be to use historical statistics and least squares
regression to derive an equation of the form:
𝑒𝑓𝑓𝑜𝑟𝑡 = 𝛼 + 𝛽(𝑠𝑖𝑧𝑒)
Where 𝛼 and 𝛽 are constants.

Euclidian distance42:
The Euclidian distance formula could be used to measure how closely two projects are
related to each other:
𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 = √(𝑡𝑎𝑟𝑔𝑒𝑡1 − 𝑠𝑜𝑢𝑟𝑐𝑒1 )2 + … + (𝑡𝑎𝑟𝑔𝑒𝑡𝑛 − 𝑠𝑜𝑢𝑟𝑐𝑒𝑛 )2

COnstructive COst MOdel (COCOMO)43:

𝑒𝑓𝑓𝑜𝑟𝑡 = 𝑐(𝑠𝑖𝑧𝑒)𝑘
Where 𝑒𝑓𝑓𝑜𝑟𝑡 is measured in pm (person-months), 𝑠𝑖𝑧𝑒 is measured in kdsi (thousands of
delivered source code instructions), 𝑐 and 𝑘 are constants such that:

System type c (increments of 0.6) k (increments of (0.08)

Organic 2.4 1.05
Semi-detached 3.0 1.12
Embedded 3.6 1.20

Stages of COCOMO II: [3]44

❖ Application composition
❖ Early design
❖ Post architecture

COCOMO II45:
𝑝𝑚 = 𝐴(𝑠𝑖𝑧𝑒)𝑠𝑓 × (𝑒𝑚1 ) × (𝑒𝑚2 ) × … × (𝑒𝑚𝑛 )
Where:
𝐴 = 2.94
𝐵 = 0.91

42 p. 113
43 pp. 120-121
44 p. 122
45 p. 122
 18

𝑠𝑓 = 𝑠𝑐𝑎𝑙𝑒 𝑓𝑎𝑐𝑡𝑜𝑟 = 𝐵 + 0.01 × ∑(𝑒𝑥𝑝𝑜𝑛𝑒𝑛𝑡 𝑑𝑟𝑖𝑣𝑒𝑟 𝑟𝑎𝑡𝑖𝑛𝑔𝑠)

 19

CHAPTER 6
Objectives of activity planning [5]46
❖ Feasibility assessment
❖ Resource allocation
❖ Detailed costing
❖ Motivation
❖ Coordination

Approaches to identifying activities [3]47

❖ Activity-based approach – A list of all the activities is created along with a Work
Breakdown Structure (WBS).
❖ Product/Deliverable-based approach – A Product Breakdown Structure (PBS)
and Product Flow Diagram (PFD) is created.
❖ Hybrid approach – A WBS with the levels listed below, based on the project’s
products is created:
o Project
o Deliverables
o Components
o Work-packages
o Tasks

Network planning models [3]48

❖ Program Evaluation Review Technique (PERT) – Activity-on-arrow
❖ Critical Path Method (CPM) – Activity-on-arrow
❖ Precedence Networks – Activity-on-node

Precedence network (activity-on-node) rules [8]49

❖ Only one start node.
❖ Only one end node.
❖ A node has a duration.
❖ Links have no duration.

46 pp. 130-131
47 pp. 133-136
48 p. 139
49 pp. 141-142
 20

❖ Precedents are the immediate preceding activities.

❖ Time moves from left to right.
❖ A network may not contain loops.
❖ A network should not contain dangles.

Labelling conventions50

WHEN CARRYING OUT A FORWARD PASS:

IF A NODE HAS MORE THAN ONE PRECEDENT, CHOOSE THE EARLIEST
START DATE AS THE LARGEST OF THE EARLIEST FINISH DATES
WHEN CARRYING OUT A BACKWARD PASS:
USE THE SMALLEST OF THE LATEST START DATES AS THE LATEST FINISH DATE

Activity float [2]51

❖ Free float – The time by which an activity may be delayed without affecting any
subsequent activity.
𝑓𝑟𝑒𝑒 𝑓𝑙𝑜𝑎𝑡 = 𝐸𝑎𝑟𝑙𝑖𝑒𝑠𝑡 𝑠𝑡𝑎𝑟𝑡 𝑑𝑎𝑡𝑒 𝑜𝑓 𝑠𝑢𝑐𝑐𝑒𝑠𝑠𝑜𝑟 − 𝐸𝑎𝑟𝑙𝑖𝑒𝑠𝑡 𝑓𝑖𝑛𝑖𝑠ℎ 𝑑𝑎𝑡𝑒
❖ Interfering float – How much the activity may be delayed without delaying the
project end date.
𝑖𝑛𝑡𝑒𝑟𝑓𝑒𝑟𝑖𝑛𝑔 𝑓𝑙𝑜𝑎𝑡 = 𝑡𝑜𝑡𝑎𝑙 𝑓𝑙𝑜𝑎𝑡 − 𝑓𝑟𝑒𝑒 𝑓𝑙𝑜𝑎𝑡

Activity-on-arrow rules [8]52

❖ Only one start node.
❖ Only one end node.
❖ A link has a duration.
❖ Nodes have no duration.
❖ Time moves from left to right.

50 p. 144
51 p. 150
52 pp. 152-153
 21

❖ Nodes are numbered sequentially.

❖ A network may not contain loops.
❖ A network may not contain dangles.

Labelling conventions53

53 p. 157
 22

CHAPTER 7
Lyytinen-Mathiassen-Ropponen risk framework (STAT) [4]54
❖ Structure – Management structures and systems.
❖ Technology – Technology used for implementation and that imbedded in
procedures.
❖ Actors – All people involved in development.
❖ Tasks – The work planned.

*Framework for dealing with risks [4]55

❖ Risk identification
❖ Risk analysis and prioritization
❖ Risk planning
❖ Risk monitoring

Risk exposure56
𝑟𝑖𝑠𝑘 𝑒𝑥𝑝𝑜𝑠𝑢𝑟𝑒 = (𝑝𝑜𝑡𝑒𝑛𝑡𝑖𝑎𝑙 𝑑𝑎𝑚𝑎𝑔𝑒) × (𝑝𝑟𝑜𝑏𝑎𝑏𝑖𝑙𝑖𝑡𝑦 𝑜𝑓 𝑜𝑐𝑐𝑢𝑟𝑟𝑒𝑛𝑐𝑒)

Risk planning alternatives [4]57

❖ Risk acceptance – The risk is accepted and nothing is done about it.
❖ Risk avoidance – The risk is avoided by avoiding hazardous situations.
❖ Risk reduction/mitigation – The probability of the risk occurring is lowered
(reduction). The impact of the risk is also lessened when it occurs (mitigation).
❖ Risk transfer – The risk is transferred somewhere else (e.g. an insurance company)

Risk Reduction Leverage (RRL)58

(𝑅𝐸𝑏𝑒𝑓𝑜𝑟𝑒 − 𝑅𝐸𝑎𝑓𝑡𝑒𝑟 )
𝑟𝑖𝑠𝑘 𝑟𝑒𝑑𝑢𝑐𝑡𝑖𝑜𝑛 𝑙𝑒𝑣𝑒𝑟𝑎𝑔𝑒 =
𝑐𝑜𝑠𝑡 𝑜𝑓 𝑟𝑖𝑠𝑘 𝑟𝑒𝑑𝑢𝑐𝑡𝑖𝑜𝑛

Where 𝑅𝐸𝑏𝑒𝑓𝑜𝑟𝑒 is the risk exposure before risk reduction actions and 𝑅𝐸𝑎𝑓𝑡𝑒𝑟 is the risk
exposure after risk reduction action.

54 p. 165
55 p. 166
56 p. 168
57 p. 172
58 p. 174
 23

*PERT59
❖ 𝑚 = 𝑚𝑜𝑠𝑡 𝑙𝑖𝑘𝑒𝑙𝑦 𝑑𝑢𝑟𝑎𝑡𝑖𝑜𝑛
❖ 𝑎 = 𝑜𝑝𝑡𝑖𝑚𝑖𝑠𝑡𝑖𝑐 𝑑𝑢𝑟𝑎𝑡𝑖𝑜𝑛
❖ 𝑏 = 𝑝𝑒𝑠𝑠𝑖𝑚𝑖𝑠𝑡𝑖𝑐 𝑑𝑢𝑟𝑎𝑡𝑖𝑜𝑛
𝑎+4𝑚+𝑏
❖ 𝑒𝑥𝑝𝑒𝑐𝑡𝑒𝑑 𝑑𝑢𝑟𝑎𝑡𝑖𝑜𝑛 = 𝑡𝑒 = 6
𝑏−𝑎
❖ 𝑎𝑐𝑡𝑖𝑣𝑖𝑡𝑦 𝑠𝑡𝑎𝑛𝑑𝑎𝑟𝑑 𝑑𝑒𝑣𝑖𝑎𝑡𝑖𝑜𝑛 = 𝑠 =
6
2 2
❖ 𝑒𝑣𝑒𝑛𝑡 𝑠𝑡𝑎𝑛𝑑𝑎𝑟𝑑 𝑑𝑒𝑣𝑖𝑎𝑡𝑖𝑜𝑛 = √(𝑠𝑝𝑎𝑡ℎ 1 ) + (𝑠𝑝𝑎𝑡ℎ 2 )
𝑇− 𝑡𝑒
❖ 𝑧= , where 𝑇 = 𝑡𝑎𝑟𝑔𝑒𝑡 𝑑𝑎𝑡𝑒
𝑠

Steps for calculating the probability of meeting/missing target

date60
❖ Calculate the standard deviation of each project event
❖ Calculate the z-value for each event that has a target date
❖ Convert z-values to probabilities

59 pp. 176 - 180

60 p. 179 - 180
 24

CHAPTER 8
Categories of Resources [7]61
❖ Labour
❖ Equipment
❖ Materials
❖ Space
❖ Services
❖ Time
❖ Money

*Factors to consider when allocating individuals to tasks [5]62

❖ Availability
❖ Criticality
❖ Risk
❖ Training
❖ Team building

Categories of cost [3]63

❖ Staff costs
❖ Overheads
❖ Usage charges

61 p. 194
62 p. 203
63 p. 206
 25

CHAPTER 9
Traffic-light method steps [5]64
❖ Identify the key (first level) elements for assessment.
❖ Break key elements into constituent elements (second level).
❖ Assess each second-level element according to:
o Green – on target.
o Amber – not on target, but recoverable.
o Red – not on target, and recoverable only with difficulty.
❖ Review all second-level assessments to arrive at first-level assessments.
❖ Review first- and second-level assessments to produce an overall assessment.

Earned Value Analysis65

❖ PV (Planned Value) = Original budgeted cost for an item.
❖ EV (Earned Value) = Total value credited to a project.
o A task’s EV is initialized to 0. When it is finished, it is accredited to 100% of its
PV (depending on which method of allocation has been used).
❖ AC (Actual Cost) = The actual cost of each task.
❖ SV (Schedule Variance) = EV – PV = The degree to which the value of completed
work differs from that planned. (If SV < 0, the project is behind schedule).
❖ TV (Time Variance) = The difference between the time when the achievement of
the current EV was planned to occur and the time now.
❖ CV (Cost Variance) = EV – AC (If CV < 0, the project is over cost/budget).
𝐸𝑉
❖ CPI (Cost Performance Index) = 𝐴𝐶
o CPI and SPI are value-for-money indices. If CPI or SPI > 1, then work is
being completed better than planned.
𝐵𝐴𝐶
❖ SPI (Schedule Performance Index) = 𝐶𝑃𝐼
❖ BAC (Budget at Completion) = the current project budget.
𝑆𝐴𝐶
❖ TEAC (Time Estimate at Completion) = 𝑆𝑃𝐼
❖ SAC (Schedule at Completion) is the planned total duration.

64 pp. 217 - 218

65 pp. 223 - 228
 26

*Prioritizing Monitoring [5]66

❖ Critical path activities
❖ Activities with no free float
❖ Activities with less than a specified float
❖ High-risk activities
❖ Activities using critical resources

*Ways to shorten the critical path [5]67

❖ Add resources
❖ Increase use of current resources
❖ Reallocate staff to critical activities
❖ Reduce scope
❖ Reduce quality

66 p. 229
67 p. 230
 27

Bibliography
Hughes, B., & Cotterell, M. (2009). Software Project Management. Berkshire: McGraw-Hill.