ArchE Arch itecture E xpert Design Assistant

1. End of Semester Presentation, Fall 2003 ArchEArchitecture Expert Design Assistant Dumbledore Team Heng Chen, Myung-Joo Ko, Neel Mullick, Paulo Merson 1

2. Understanding of the project from the client’s perspective Project description 2

3. Project description Premises • Quality attributes have dominant influence on architecture • Architectural expertise can be codified as rules • Quality attributes can be expressed as scenarios 3

4. Project description Objectives & business drivers • Objectives • Refine a collection of quality attributes as scenarios • Process scenarios using extensible set of rules • Generate architectural model • Business drivers • Demonstrate viability of automated architecture modeling • Generate interest in commercial & academic communities 4

5. Project description Context diagram Facts, Rules Jess Rule Engine Requirements Designer Rules Design Architecture Design Tool ArchE Modified Design Model Model Analysis Tool System Maintainer Configuration Analysis Legend Gane-Sarson Notation Data Flow Process External Entity 5

6. The Fall 2003 Effort 6

7. Methods & technical approaches Lessons learned Next steps Project status The Fall 2003 Effort The plan The processes 7

8. Requirements Management 8

9. Requirements Management Methods & technical approaches Requirements elicitation Methods & technical approaches Paper prototyping Functional requirements Task analysis Customer interviews Architecture-centric methodology Quality requirements 9

10. Requirements Management Methods & technical approaches Methods & technical approaches Requirements expression Functional requirements Use case modeling Feature list State charts Quality attribute scenarios Quality requirements 10

11. Requirements Management State chart for scenario 11

12. Requirements Management Methods & technical approaches Methods & technical approaches Requirements validation Paper prototyping Functional requirements Feature list - Prioritization Use case validation Quality requirements Cognitive walkthrough 12

13. Requirements Management Project status Method & technical approaches Status Use cases Completed for “requirements” Paper prototyping 3 cycles for model generation Feature list Prioritized for model generation Architecture modeling 1 cycle of notional architecture Quality attribute scenarios 1 cycle of quality requirements 13

14. Requirements Management Use case modeling status Facts, Rules Jess Rule Engine Requirements  Designer Rules Design Architecture Design Tool ArchE Modified Design Model Model Analysis Tool System Maintainer Configuration Analysis Legend Gane-Sarson Notation Data Flow Process External Entity 14

15. Requirements Management Paper prototyping status  Facts, Rules Jess Rule Engine Requirements   Designer Rules Design Architecture Design Tool ArchE Modified Design  Model Model Analysis Tool System Maintainer Configuration Analysis Legend Gane-Sarson Notation Data Flow Process External Entity 15

16. Requirements Management Lessons learned Lessons learned Methods & technical approaches Use cases Tradeoff; need to strike a balance Paper prototyping Feature list Valuable exercise Architecture modeling Must proceed in parallel Quality attribute scenarios Must be defined 16

17. Requirements Management Next steps Methods & technical approaches Next steps Use cases & paper prototyping • Balance between the two • Decide based on detailed design • Trace requirements progression Feature list Grade complexity of implementation • Refine notional architecture • Understand entity relationships Architecture modeling Quality attribute scenarios Refine quality attributes 17

18. Spread ourselves too thin Decide best-fit technique Decide progression to detailed design Set exit criteria for requirements scoping SUMMARY: Requirements Management 18

19. Risk Management 19

20. Risk Management Methods & technical approaches Risk management Methods & technical approaches Risk discovery Brainstorming Architecture-centric method Risk categorization Risk tracking & monitoring Risk mitigation & response 20

21. Risk Management Risks & mitigation plans Risks status (scores) Mitigation plan Extensive interoperability (10) Training plan Feature rich user interface (10) Prototyping; prioritized feature list Undefined quality attributes (7) Priority for next semester Lack of precedents for estimation (7) Changed basis for time tracking Evolving core of ArchE (6) Evaluation of intermediate data store 21

22. Focus on architecture modeling as an important source Implement risk review & analysis cycle SUMMARY: Risk Management 22

23. Team members = 4 Weeks = 12 (assumption) Hours per week = 48 Total person-hours (for summer) = 2304 Estimation 23

24. Estimation Project estimates Project estimates Methods & technical approaches Categorize use case points (UCP) • Simple (4) • Medium (3) • Complex (8) Estimate category times (CTE) Wideband delphi & Clark's method • Simple (29 person-hours) • Medium (58 person-hours) • Complex (94 person-hours) Rank technical factors (TF) • Complexity (0.5) • Ease of use (0.25) • Reusability (0.25) • Ease of change (0.25) • Interdependence (0.5) • TOTAL = 1.75 24

25. Estimation Project estimates Methods & technical approaches Project estimates • Requirements stability (0.75) • Team’s technical capabilities (0.75) • TOTAL = 1.5 Rank environment factors (EF) Compute adjusted use case points AUCP = UCP * TF * EF • Simple (10.5) • Medium (7.875) • Complex (21) Compute effort estimates AUCP * CTE • Simple (302 person-hours) • Medium (440 person-hours) • Complex (1983 person-hours) • TOTAL = 2725 person-hours AVAILABLE = 2304 person-hours 25

26. Estimation Lessons learned & next steps Lessons learned Next steps Use cases - inappropriate basis Change basis to features Incorrect bases for time tracking Change time tracking bases Narrow focus on implementation “Mine” data to revise estimates 26

27. Change estimation basis to feature list Change time tracking bases Revise estimates SUMMARY: Estimation 27

28. Quality Assurance 28

29. Quality Assurance Methods & technical approaches Project phases Methods & technical approaches Requirements & analysis Prototype walkthroughs Peer review cycle Architecture & design Notional architecture walkthroughs Architecture tradeoff analysis Implementation & testing Code walkthroughs during pilot tests Reviews & inspections Unit & system tests 29

30. Quality Assurance Objectives Priority Use case category RF DD 2 / KLOC 95 % Simple 5 4 / KLOC 4 95 % 2 / KLOC Medium 5 90 % 4 90 % 4 / KLOC Complex 5 90 % 3 / KLOC 4 90 % 5 / KLOC RF: Requirements Fulfillment DD: Defect Density 30

31. Quality Assurance Lessons learned & next steps Lessons learned Next steps Use cases – inappropriate basis Change basis to features Defects – ill defined • Defect definition • nature of defects • intensity of defects • source of defects Objectives to be exit criteria • Recording mechanisms for metrics • Quality assurance responsibilities 31

32. Refine quality assurance plan Make implementation lightweight and practical SUMMARY: Quality Assurance 32

33. Training Plan 33

34. Training Plan Required skills Required skills Responsibility Eclipse All team members All team members Java Paulo Merson Acme Studio Heng Chen TimeWiz Myungjoo Ko Rational Rose Neel Mullick Jess 34

35. Training Plan Milestones Milestones Date (initiation / completion) Licensing issues December 10, 2003 (completion) Installation documentation December 10, 2003 (completion) Integration issues January 10, 2004 (completion) Pilot testing & technical prototyping January 10, 2004 (initiation) Code & help documentation January 10, 2004 (initiation) Code walkthroughs January 31, 2004 (initiation) 35

36. The Path Forward 36

37. The Path Forward Software development tasks Software development tasks Next steps Technical prototyping • Identify features to be prototyped • Set objectives for exercise • Define exit criteria • Identify knowledge sharing process Development & testing • Define development & testing tasks • Outline task sequence • Outline roles & responsibilities • Outline milestones & exit criteria • Refine quality assurance processes 37

38. The Path Forward Roles progression Spring 2004 Fall 2003 Team lead Quality assurance manager Process manager Requirements manager Configuration & support manager Planning manager Customer manager Software architect Risk manager Developer 38

39. The Path Forward Project milestones Milestones Date (initiation / completion) January 19, 2004 (initiation) Pilot development February 08, 2004 (completion) Development plan February 08, 2004 (completion) Quality assurance plan (refined) April 11, 2004 (completion) Requirements specification & scoping May 15, 2004 (completion) User interface prototyping (evolutionary) April 30, 2004 (completion) Software architecture & design June 01, 2004 (initiation) Implementation 39

40.   The Path Forward Minimal deliverable scope  Facts, Rules Jess Rule Engine Requirements   Designer Rules Design Architecture Design Tool ArchE Modified Design Model Model Analysis Tool System Maintainer Configuration Analysis Legend Gane-Sarson Notation Data Flow Process External Entity 40

41. 41

42. Appendix 42

43. The Dumbledore Team Vision • Vision • Create a vision of ArchE that that pleases the client when using it, and at the same time, is very well architected, documented, implemented and hence, highly modifiable. • Should learn and grow together as a team, thriving on each other’s strengths, helping overcome each other’ shortcomings, and come out as better individuals, team players and software engineers. 43

44. The Dumbledore Team Goals • Goals • Work no more than 12 hours per week during fall and spring semesters and 48 hours per week during summer and get an A or A+ grade. • Team’s deliverables should be used as a precedent for excellence next year. 44