Your SlideShare is downloading. ×
CommonKADS project management
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

CommonKADS project management

166

Published on

Ch. 15 of the CommonKADS textbook

Ch. 15 of the CommonKADS textbook

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
166
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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 !

×