Ch. 15 of the CommonKADS textbook

1. Project Management
balance between control & flexibility
work breakdown
risk analysis
project cycle planning

2. Project management 2
Overview
■ Project management approaches
■ CommonKADS spiral approach
■ How to do a risk analysis
■ Project planning and the concept of model states
■ Case Study: a project on reactor noise analysis
■ Experience: points of attention

3. Project management 3
Control versus Flexibility
■ knowledge projects often have learning character
■ structure of knowledge may turn out to deviate
■ requirements (even) more likely to change
➤ goals adjusted along project route

4. Project management 4
Waterfall project approach
S trategy
P hase
Information
Analysis
S ystem
Design
P rogram
and
Test
Operation
Maintenance

5. Project management 5
Merits and disadvantages of
waterfall LCM
■ strong handle for project control
■ early phases are document-oriented
➤ often need for operational (partial) results
■ changing needs and requirements difficult and costly
■ adequate for applications with clear route
➤ not often true for knowledge-intensive systems

6. Project management 6
Evolutionary or rapid
prototyping approach
Gather
E xpert
data
Implement
P rototype
Validate
Get
feedback
Iterate

7. Project management 7
Basic Ideas underlying
KBS Project Approach
■ It's not activities, but products that count
■ Project lifecycle must be configurable
■ Configuration is based on risk assessment
■ Quality is engineered in through (1) model suite
based development; (2) risk-based cyclic project
management
■ Development (1) and management (2) are linked
through the concept of model (product) states

8. Project management 8
Boehm's Spiral Model
R E VIE W
R IS KP L A N
MONIT OR
cycle-­‐0
cycle-­‐1
cycle-­‐2
cycle-­‐3

9. Project management 9
CommonKADS Spiral
Lifecycle Model
MONIT OR R E VIE W
R IS KP L A N
-­‐
monitor
development
work
-­‐
prepa re
a ccepta nce
a s s es s ment
-­‐
eva lua te
cycle
res ults
-­‐
review
prog res s
-­‐s et
cycle
objectives
-­‐
cons ider
cons tra ints
-­‐
inves tig a te
a lterna tives
-­‐
commit
-­‐
pla n
cycle
ta s ks
-­‐
a lloca te
res ources
-­‐
a g ree
a ccepta nce
criteria
-­‐
identify
ris ks
-­‐
ca rry
out
ris k
a s s es s ment
-­‐
decide
on
development
s teps

10. Project management 10
Project management cycle
1. Review
➤ current status of the project is reviewed
➤ objectives for upcoming cycle are established
➤ special case: cycle-0
– project plan + quality plan is developed
➤ ensure continued commitment of stakeholders
2. Risk
➤ obstacles identified
– significance assessed
➤ counteractions are decided upon

11. Project management 11
Project management cycle
3. Plan
➤ make detailed plan for next cycle
– work breakdown structure
– schedule of tasks
➤ allocating needed resources and personnel
➤ agreeing on acceptance criteria
4. Monitor
➤ evaluating outputs
➤ track progress
➤ meeting with stakeholders

12. Project management 12
How to do a
Risk Assessment
■ Risk = (Likelihood of Occurrence) x (Severity of
Effect)
■ Valuate both on a qualitative (five-point) scale
■ Subsequently rank all risks on this basis
■ Device countermeasures for each risk
■ Plan accordingly, and take the risks with high priority
rank first
■ Risk assessment: see Worksheet PM-1 (is part of
project documentation)

13. Project management 13
Quality feature tree
(used in risk assessment)
Reliability
Usability
Efficiency
Maintainability
Portability
Functionality
Quality
Feature
suitability
interoperability
accuracy
compliance
security
maturity
faulttolerance
recoverability
understandability
learnability
operability
timebehaviour
analyzability
changeability
stability
testability
adaptability
installability
conformance
replaceability
Knowledge
Usability
Knowledge
Capture
effectiveness
completeness
reliability
certainty
accessability
transferability
adequacy
structuredness
validity
coverage
testability

14. Project management 14
Knowledge-oriented quality
features
■ Knowledge capture:
➤ quality features of knowledge elicitation, modeling and
validation activities by knowledge engineers
■ Knowledge usability
➤ quality features of knowledge itself

15. Project management 15
The Concept of
Model States
■ Models are seen as (sub)products of KBS project
■ Project management: get products from one state
into another, desired next state
■ Qualitative range of state values: empty, identified,
described, validated, completed
■ Project planning is state transition based
➤ See Worksheet PM-2
■ May apply to separate models or even components,
depending on perceived risk

16. Project management 16
PM-2: Setting plan objectives
through model states
■ What model(s) are to be worked on in next cycle?
■ Which model component(s)?
■ To what degree?
➤ refers to model state
■ By what means, resources, development method or
technique?
■ Success condition
■ Quality metrics

17. Project management 17
CommonKADS Planning is
based on Model States
S et
objectiv es
Identify
ris ks
Define
targ et
model
s tates
R ev iew
objectiv es
Quality
C ontrol
current
model
=>
new
model
des cription
P lan
dev elopment
activ ities
-­‐
unders tand
current
s ituation
-­‐
problem
des cription
incomplete
O M:
problem
des cription
=
validated
O M:
s tructure
=
des cribed
T M:
decompos ition
=
des cribed
O M:
proces s
=
des cribed
T M:
time
load
=
des cribed
O M:
problem
=
des cribed
O M:
problem
=
validated
Dev elopment
P rojec t
Manag ement

18. Project management 18
Project Documentation
■ Project Plan
➤ Project motivation, background, scope, goals
➤ Project deliverables
➤ Work breakdown: cycles, resources
➤ Project organization
■ Quality Plan
■ Cycle Documentation
■ Project Close Down Report
➤ lessons learnt, recommendations and proposed guidelines
follow-up work, improvements

19. Project management 19
Case: a Project on Nuclear
Reactor Noise Analysis
steam generator
P
reactor vessel
core
neutron detectors
pumps

20. Project management 20
Task: expert interpretation of
noise spectra
Nuclear Charge 21
0.00E+00
1.00E-03
2.00E-03
3.00E-03
4.00E-03
5.00E-03
6.00E-03
11 24 140 285 463 579 672 781 861 980
boron
RMS

21. Project management 21
Risk: Cycle 1
Risk list (ranked in this order; see Table 12.9):
■ Knowledge engineer not acquainted with this (complex)
domain
– Countermeasure: do part of domain model first
■ Nature and complexity of noise interpretation task
unknown (classification, monitoring, assessment,
model-based diagnosis?)
– Countermeasure: scenario-based task modeling
■ Limited availability of the expert
– Countermeasure: develop contacts with other experts

22. Project management 22
Plan: Cycle 1 Gantt Chart
time
KM-­‐a T M-­‐b
T M-­‐a T M-­‐c
OM-­‐a OM-­‐b
840
88
24 60
C Y C L E -­‐1

23. Project management 23
Expectation Management!
From an interview transcript:
■ Knowledge engineer:
– Question (shows noise spectra): if the reactivity differs from
the expected value, is it possible to tell what the potential
causes are? Does it also show up in or affect other physical
parameters?
■ Expert:
– Answer: In what language are you going to implement the
system? On a VAX or a PC?

24. Project management 24
Conclusion of First Cycle;
Risk Analysis Second Cycle
■ Reactor noise interpretation is assessment task
(similar to credit card fraud or housing!)
➤ Hence: (1) feasible for KBS; (2) assessment task template
can be reused (and it did work!)
■ Perceived major risk in second cycle: detailed insight
needed in economic costs and benefits
➤ Hence, second-cycle plan: focus on organization and task
model, esp. value, resource and performance components

25. Project management 25
Gantt Chart Cycles 2 and 3
Further cycles were rather waterfall-like
time
KM-­‐b
DM
KM-­‐c KM-­‐e
2020
20
10time
T M-­‐d
OM-­‐c
40
40
C Y C L E -­‐2 C Y C L E -­‐3
KM-­‐d
20

26. Project management 26
KBS Cost Estimation
■ KBS economy similar to other complex information
systems. Rough figures (cf. Boehm: S/w Eng. Economics)
➤ Project management: 10%
➤ Organization/Task/Agent Models: 10%
➤ Knowledge modeling (information analysis): 30%
➤ Design and Communication Models: 20%
➤ Implementation and testing: 25%
➤ Quality assurance: 5%
■ Notes: (1) high variability; (2) exchanges
possible,depending on project and approach (e.g.
GUI prototyping)

27. Project management 27
Requirements Engineering
■ Requirements engineering in software is still
underestimated and underdeveloped
– cf. books like Sommerville: Software Engineering
■ CommonKADS Model Suite can be seen as a
method to structure the requirements elicitation and
capture process
■ Analogy between requirements and knowledge:
– Tacit vs. explicit
– What is said may not coincide with what is really used
– Context dependence, organizational environment
– The human factor

28. Project management 28
Experience-based project
management guidelines
■ Identify and interview stakeholders right at the
beginning; keep them informed and interested
■ Be prepared for different viewpoints and interests
■ Manage expectations all the time
■ Risks are often not of a technical nature!
■ Requirements have a life of their own: they emerge,
grow and change, multiply, and die
■ Use the universal 80/20% rules
■ Learn from our recipes for failure !