Software

Project Management Chapter 2

4th Edition

Step Wise:
An approach to
planning
software projects

1
‘Step Wise’ - aspirations
• Practicality
– tries to answer the question ‘what do I do
now?’

• Scalability
– useful for small project as well as large

• Range of application
• Accepted techniques
– e.g. borrowed from PRINCE etc
2
‘Step Wise’ - an overview
0.Select
1. Identify project 2. Identify project
project objectives infrastructure

3. Analyse
project
characteristics
Review
4. Identify products
and activities

5. Estimate effort
Lower for activity For each
level activity
detail 6. Identify activity
risks
10. Lower level
7. Allocate
planning
resources

8. Review/ publicize
9. Execute plan plan 3
A project scenario
• Hardware/software engineering
company (C++ language of choice)

• teams are selected for individual

projects - some friction has been found
between team members

• HR manager suggests psychometric

testing to select team
4
Project scenario - continued
• Software package to be used to test
staff

• Visual basic suggested as a vehicle for

implementation

• usability is important - decision to carry

out usability tests
5
Step 1 establish project
scope and objectives
• 1.1 Identify objectives and measures of
effectiveness
– ‘how do we know if we have succeeded?’

• 1.2 Establish a project authority

– ‘who is the boss?’

• 1.3 Identify all stakeholders in the project and

their interests
– ‘who will be affected/involved in the project?’
6
Step 1 continued
• 1.4 Modify objectives in the light of
stakeholder analysis
– ‘do we need to do things to win over
stakeholders?’

• 1.5 Establish methods of

communication with all parties
– ‘how do we keep in contact?’

7
Back to the scenario
• Project authority
– should be a project manager rather than
HR manager?

• Stakeholders
– project team members to complete on-
line questionnaires: concern about
results?

• Revision to objectives
– provide feedback to team members on
results 8
Step 2 Establish project
infrastructure
• 2.1 Establish link between project and
any strategic plan
– ‘why did they want the project?’

• 2.2 Identify installation standards and

procedures
– ‘what standards do we have to follow?’

• 2.3. Identify project team organization

– ‘where do I fit in?’
9
Step 3 Analysis of project
characteristics
• 3.1 Distinguish the project as either
objective or product-based.

• 3.2 Analyse other project characteristics

(including quality based ones)
– what is different about this project?

10
Step 3 continued
• Identify high level project risks
– ‘what could go wrong?’
– ‘what can we do to stop it?’
• Take into account user requirements
concerning implementation
• Select general life cycle approach
– waterfall? Increments? Prototypes?
• Review overall resource estimates
– ‘does all this increase the cost?’
11
Back to the scenario
• Objectives vs. products
• Some risks
– team members worried about implications
and do no co-operate
– project managers unwilling to try out
application
– Developer not familiar with features of VB
• Answer? - evolutionary prototype?

12
Step 4 Identify project
products and activities
4.1 Identify and describe project
products - ‘what do we have to
produce?’
Usability A product breakdown structure
testing (PBS)

Selected Testing Change

Test results
subjects arrangements requests

Booked Questionnaire Completed Analysis

PC design questionnaire report

13
Products
• The result of an activity

• Could be (among other things)

– physical thing (‘installed pc’),
– a document (‘logical data structure’)
– a person (‘trained user’)
– a new version of an old product (‘updated
software’)

14
Products
• The following are NOT normally
products:
– activities (e.g. ‘training’)
– events (e.g. ‘interviews completed’)
– resources and actors (e.g. ‘software
developer’) - may be exceptions to this
• Products CAN BE deliverable or
intermediate

15
Product description (PD)
• Product identity • Relevant standards
• Description - what • Quality criteria
is it?
• Derivation - what is
it based on? Create a PD for ‘test
• Composition - what data’
does it contain?
• Format

16
Step 4 continued
Testing plan

4.2 document Selected Questionnaire Booked

subjects
Generic
design machine

product
flows
Completed Test results
questionnaire

Analysis report

Change
requests
17
Step 4.3 Recognize product
instances
• The PBS and PFD will probably have
identified generic products e.g.
‘software modules’
• It might be possible to identify specific
instances e.g. ‘module A’, ‘module B’ …
• But in many cases this will have to be
left to later, more detailed, planning
18
4.4. Produce ideal activity
network
• Identify the activities needed to create
each product in the PFD
• More than one activity might be needed
to create a single product
• Hint: Identify activities by verb + noun
but avoid ‘produce…’ (too vague)
• Draw up activity network

19
An ‘ideal’ activity
Select
subjects

Plan Design Conduct Analyse Draft change

testing questionnaire tests results requests

Book
machine

20
Step 4.5 Add check-points if needed
Design Code
module A module A

Design Design Code

system Test
module B module B system

Design Code put in a

module C module C check point

Design Code
module A module A

Design Design Code

system Check-point Test
module B module B system

Design Code
module C module C
21
Step 5:Estimate effort for
each activity
• 5.1 Carry out bottom-up estimates
– distinguish carefully between effort and
elapsed time
• 5.2. Revise plan to create controllable
activities
– break up very long activities into a series
of smaller ones
– bundle up very short activities (create
check lists?)
22
Step 6: Identify activity risks
• 6.1.Identify and quantify risks for
activities
– damage if risk occurs (measure in time lost
or money)
– likelihood if risk occurring

• 6.2. Plan risk reduction and contingency

measures
– risk reduction: activity to stop risk
occurring
– contingency: action if risk does occur 23
• 6.3 Adjust overall plans and estimates
to take account of risks
– e.g. add new activities which reduce risks
associated with other activities e.g.
training, pilot trials, information gathering

24
Step 7: Allocate resources

• 7.1 Identify and allocate resources to

activities

• 7.2 Revise plans and estimates to take

into account resource constraints
– e.g. staff not being available until a later
date
– non-project activities

25
Gantt charts
LT = lead tester
TA = testing assistant
Week
APRIL
commencing MARCH
5 12 19 26 2 9 16

Plan testing LT
Select subjects
TA
Design
questionnaire LT

Book machine TA

Conduct tests
TA
Analyse results
LT

Draft changes
LT
26
Step 8: Review/publicise
plan
• 8.1 Review quality aspects of project
plan
• 8.2 Document plan and obtain
agreement

Step 9 and 10: Execute plan

and create lower level plans
27