1. Team Dumbledore Spring EOSP Team Dumbledore: Heng Chen, Myung-Joo Ko, Neel Mullick, Paulo Merson End of Semester Presentation 05-07-2004

2. Team Dumbledore Spring EOSP 2 Agenda Team Dumbledore   The ArchE System   Architecture   Process   Accomplishments and plans   Lessons learned

3. Team Dumbledore Spring EOSP 3 Team Dumbledore  The Team Heng Chen – Team lead, Risk Manager Myung-Joo Ko – Configuration Manager, Webmaster Neel Mullick – Client Manager, Process Manager Paulo Merson – Architect, Requirement Manager Alex Berendeyev – Contractor Namrata Malik – Technical Writer  Mentors Anthony Lattanze Ipek Ozkaya  Clients (SEI) Felix Bachmann, Len Bass, Mark Klein

4. Team Dumbledore Spring EOSP 4 What ArchE Does Requirements Knowledge Designer Architecture System QA scenarios Functions Codified as Jess rules

5. Team Dumbledore Spring EOSP 5 How ArchE Does It Requirements QA scenarios and functions refine applying tactics Goal: find design solution that meets requirements Model QA specific Quantifiable measures specifies evaluation Design

6. Team Dumbledore Spring EOSP 6 Context Diagram

7. Team Dumbledore Spring EOSP 7 Functional requirements

8. Team Dumbledore Spring EOSP 8 Quality Attribute Elicitation  Most important quality attributes Modifiability Usability Performance  17 QA scenarios

9. Team Dumbledore Spring EOSP 9 Quality Attribute Requirements  Examples After some user action, new values are generated by the model and are available in the rule engine (core); ArchE reads the results and reflects them in all relevant UI views within 500 ms. The user creates a big system (with ~10000 responsibilities). Time taken to update all UI views after data from the core changes is 500 ms. A developer familiar with ArchE incorporates a new security reasoning framework to work with ArchE by adapting existing views to security elements, adapting or creating new architectural design representation, defining new scenario types, interact with security rules/facts in Jess, display the security model, within 20 person days.

10. Team Dumbledore Spring EOSP 10 Agenda   Team Dumbledore   The ArchE System Architecture Architecture   Process   Accomplishments and plans   Lessons learned

11. Team Dumbledore Spring EOSP 11 Architecture  High-level C&C view  High-level module view  Eclipse plug-in deployment structure

12. Team Dumbledore Spring EOSP 12 High-Level C&C view

13. Team Dumbledore Spring EOSP 13 High-Level Module View Standard UML notation

14. Team Dumbledore Spring EOSP 14 Eclipse Plug-in Deployment Structure

15. Team Dumbledore Spring EOSP 15 ATAM  ATAM sessions 2 ATAM sessions led by outside evaluator 7 ATAM sessions done within the team  Usefulness of ATAM Helps evaluating architecture Helps in making architectural decisions Aids future maintainers to understand architecture decisions

16. Team Dumbledore Spring EOSP 16 Architecture Analysis  Performance/scalability scenarios: After some user action, new values are generated by the model and are available in the rule engine (core); ArchE reads the results and reflects them in all relevant UI views within 500 ms. The user creates a big system (with ~10000 responsibilities). Time taken to update all UI views after data from the core changes is 500 ms.

17. Team Dumbledore Spring EOSP 17 Alternative 1 Cache fact base and refresh after every change

18. Team Dumbledore Spring EOSP 18 Alternative 2 Access facts directly in the core Jess notifies changes

19. Team Dumbledore Spring EOSP 19 Trade-offs Alternative 1Alternative 2 Performance  + Data consistency+Unknown

20. Team Dumbledore Spring EOSP 20 Agenda   Team Dumbledore   The ArchE System   Architecture Process Process   Accomplishments and plans   Lessons learned

21. Team Dumbledore Spring EOSP 21 ACDM ( Architecture-Centric Development Method )   It suits studio projects Lightweight Small teams Short development cycles   It addresses risks at the architecture level   ArchE itself is about architecture   Clients are architecture-focused   Author is one of our mentors

22. Team Dumbledore Spring EOSP 22 ACDM ( Architecture-Centric Development Method ) Artifact Activity Decision Next step Produces Legend: Functional rqmts/constraints Paper prototypes Discover quality attribs. Create utility tree1 Prioritized utility tree Initial project plan Create notional architecture2 Architecture views Updated project plan Review architecture Analyze scenarios3 Risks, tradeoffs Ready to design & code? Evaluate risks/tradeoffs Create experiment plan 4 Experiment plan Updated project plan Execute experiments Revisit architecture 5 Refined architecture Updated project plan Create design Write test code/ write code/ review code 6 Detailed design Test code Source code Deploy/integrate or iterate 7 Discuss UI functions w/ clients 3’ UI detailed stories Yes No

23. Team Dumbledore Spring EOSP 23 ACDM ( Architecture-Centric Development Method ) Technical experiments High-Level C&C view Neel Henry Paulo Myung

24. Team Dumbledore Spring EOSP 24 Paulo : Eclipse Plug-in Development Did training session & developed UI codes Neel : Jess Rule Engine Did training session Myung : Design Export to Rose Developed codes creating xmi readable by Rose Henry : Java RMA Model Solver Developed & delivered codes to clients Experiment plan Current status ACDM ( Architecture-Centric Development Method ) Technical experiments

25. Team Dumbledore Spring EOSP 25  Lessons learned Conducting two hour workshop for architecture every week helped us a lot Carrying out technical experiments was a good mitigation strategy for technical risks Following ACDM for design phase was a good decision  Next steps Finish technical experiments Create detailed design Code ArchE1 ACDM ( Architecture-Centric Development Method )

26. Team Dumbledore Spring EOSP 26 Requirement Management Workflow of UI prototypes Review & Verification UI Paper Prototypes Tracking & Update UI Detailed Stories Summer semester Fall semester Spring semester

27. Team Dumbledore Spring EOSP 27 Requirement Management 1 2 3 4 5 6 7 9 8 10 12 14 11 13 15 161718 19 20   Example NoEventsResponses 2PageLoadShow all possible values of scenario types associated with active Reasoning Frameworks. OptionSelectedCase1: If the user selects “unknown”, show all the possible types of options in the six parts. Case2: If the user selects not “unknown”, show specific values based on the scenario type in each field of six parts. Case 3: When no scenario type is selected, user might choose two six part types which belong to different scenario type. ArchE will show this inconsistency in the dialog box. If one or more of the six part option is selected and the user selects a scenario type(not “unknown”),and if the selected scenario type is not consistent with the 6 parts options, then open a message box “Scenario Type is not consistent with option”. Example:1) Scenario type is “unknown”. 2) User selects “periodic” as the option for stimulus. 3) User selects “cost of modification” for response option 4) User selects “deadline” on the scenario type. 5) ArchE shows error msg on inconsistency between response and scenario type Review & Verification UI Paper Prototypes Tracking & Update UI Detailed Stories

28. Team Dumbledore Spring EOSP 28  Learned from “Methods of Software Development” course  Purpose Elicit functional requirements Define the structure of UI Define and verify usability requirements  Created the prototype of all key screens Out of 21 screens, 12 screens were selected and created Requirement Management UI Detailed Stories Review & Verification UI Paper Prototypes Tracking & Update

29. Team Dumbledore Spring EOSP 29 Requirement Management   Inspired by Extreme Programming “user stories”   Purpose Complement the UI paper prototypes   UI prototypes and detailed stories Guided creation of test cases Will be a basis for implementing screens Review & Verification UI Paper Prototypes Tracking & Update UI Detailed Stories

30. Team Dumbledore Spring EOSP 30 Requirement Management Review & Verification UI Paper Prototypes Tracking & Update UI Detailed Stories   Reviewed by Requirement Manager   Verified by clients Weekly client meeting every Friday 3:00–5:00 pm

31. Team Dumbledore Spring EOSP 31 Requirement Management Review & Verification UI Paper Prototypes Tracking & Update UI Detailed Stories  Manage status of UI detailed stories Identified Story reviewed by clients Story agreed upon  When requirements are changed Update UI paper prototypes and UI detailed stories Update UI status list in SRS Reviewed by the team Use CaseUI ScreenScreen TypeStatusOwnerComment Create project 1.New ArchE ProjectDialog box[1][1]Story agreed upon PauloMain menu option: File | New | Project 1.NavigatorStandard Eclipse navigator view Story agreed upon Paulo CRUD scenarios 1.ScenariosTable viewStory agreed upon Neel 1.Scenarios – static filterDialog boxIdentified 1.ScenarioDialog boxStory agreed upon Myung 1.Scenario Responsibility Mapping Table viewStory agreed upon Myung

32. Team Dumbledore Spring EOSP 32  Lessons learned UI paper prototypes were good media for communication with clients Weekly client meeting really helped  Next steps Review stories of 3 remaining screens Freeze UIs of ArchE1 Requirement Management Review & Verification UI Prototypes Tracking & Update UI Detailed Stories

33. Team Dumbledore Spring EOSP 33 SRE ( Software Risk Evaluation )  Mini-SRE (Software Risk Evaluation) with Ray Williams Picture of Success Conditions and consequences of risks Questionnaire on team process Mini-SRE Tracking & Update Top 5 risks & Mitigation plan

34. Team Dumbledore Spring EOSP 34 SRE (Software Risk Evaluation) DescriptionMitigation plan 1 We don’t have historical data about the productivity of the team; Might underestimate time required to do development. Individual time tracking to gather more information of team productivity. 2 ArchE has to interact with JESS and we don’t know what it will take to make that work; we might not make the JESS experiment work by April 30. Neel will talk to the Felix to discover the issues of ArchE’s interfacing with JESS; Keep progressing on JESS technical prototyping. 2 ArchE was to interact ACME studio or Rational Rose and We don’t know what it will take to make either one; Might not get either to work by April 30. The team should choose only one to implement in this stage. Myung has already done many researches on Rational Rose and we should persuade the client to agree. 2 ArchE core is still evolving and we need a stable core for our design; Could result in failure or a lot of rework at the end. This issue has already been brought up in a client meeting and the need for an intermediate data store has been realized and agreed upon as a means to mitigate this risk. 5 ArchE will be developed as Eclipse plug-ins and the team is not familiar with Eclipse plug-in development; we might not have tabular views with dynamic filters and dialog boxes in the Eclipse experiment by May 5 The technical prototyping and training should carry on. Everybody in the team should be familiar with the plug-in development environment. Mini-SRE Top 5 risks & Mitigation plan Tracking & Update Rank 5 ArchE will be developed as Eclipse plug-ins and the team is not familiar with Eclipse plug-in development; we might not have tabular views with dynamic filters and dialog boxes in the Eclipse experiment by May 5 The technical prototyping and training should carry on. Everybody in the team should be familiar with the plug-in development environment.

35. Team Dumbledore Spring EOSP 35 SRE (Software Risk Evaluation) Mini-SRE Top 5 risks & Mitigation plan Tracking & Update   Team Lead managed the top 10 risk list Revisited during the team meetings   When a risk needs to be changed Reprioritize risks within the team Update top 10 risk list & website

36. Team Dumbledore Spring EOSP 36 SRE (Software Risk Evaluation) Mini-SRE Top 5 risks & Mitigation Plan Tracking & Update   Lessons learned Could be done earlier Formulated risks with conditions and consequences Picture of success is food for thought   Next step Keep monitoring

37. Team Dumbledore Spring EOSP 37 Agenda   Team Dumbledore   The ArchE System   Architecture   Process Accomplishments and plans Accomplishments and plans   Lessons learned

38. Team Dumbledore Spring EOSP 38 Progress - This Semester Feb April 3 May SOW March 1 19 20 27 SPMP with SRE (MOSP deliverable) SRS v2.0 (MOSP deliverable) UI paper prototype Migration from VSS to Perforce UI Detailed stories (Phase I) Test Plan v1.0 SRS v2.1 16 19 20 Technical Experiment (Model Solver) 22 25 26 Technical Experiment (Export Design) New website launched Technical Experiment (JESS) 1 2 3 7 Technical Experiment (Eclipse plug-in) Architecture documentation UI Detailed stories (Phase II)

39. Team Dumbledore Spring EOSP 39   Iterations Each iteration will be a deployable unit One cycle = detailed design + development planning + development + unit testing + integration testing activities Development Plan ArchE1 Navigator View, Scenarios View, Scenario Dialog Box, Questions to User Dialog Box, Problems View, Structure of RF plug-ins (including RF configuration) ArchE2 Responsibilities View, Scenario Responsibility Mapping View, Relationships View, Export Design to Rose ArchE3 Static Filters, Functions View, Function Responsibility Mapping View, Display Model elements, Display Model relations

40. Team Dumbledore Spring EOSP 40 Test Plan  For functional requirements Test cases that trace back to the UI detailed stories Integration testing for each iteration  For quality attributes Focus on performance (response time) during technical experiments Architectural review

41. Team Dumbledore Spring EOSP 41 Test Plan April May 14 19 22 29 June 5 17 7 Test cases related to UI stories Architectural review Integration testing for ArchE1 Unit testing for ArchE1 Integration test cases for ArchE1 Performance testing Final test cases for ArchE1 NOW 3

42. Team Dumbledore Spring EOSP 42 Agenda   Team Dumbledore   The ArchE System   Architecture   Process   Accomplishments and plans Lessons learned Lessons learned

43. Team Dumbledore Spring EOSP 43 What is Good So Far  Sound architecture produced  UI prototypes and detailed stories process Weekly meeting with clients Tracking progress Freezing specification after client’s agreement  Technical experiments Planned in fall; initiated at the beginning of spring Helped defining the architecture Mitigated technical risks  Successful migration from VSS to Perforce  Better client interaction  Continuous risk management

44. Team Dumbledore Spring EOSP 44 What Could Go Better  Technical experiments Should have studied ArchE core earlier  Subcontracting issues Follow a process for subcontractor management Should schedule the interaction based on his need  Earlier Estimation Would help define the scope of the functions Could be better if we did it when we built UI stories

45. Team Dumbledore Spring EOSP 45 Questions? Presentation Complete !!!

46. Team Dumbledore Spring EOSP 46 Requirement Management 1 2 3 4 5 6 7 9 8 10 12 14 11 13 15 161718 19 20   Example Review & Verification UI Prototypes Tracking & Update UI Detailed Stories

47. Team Dumbledore Spring EOSP 47 Requirement Management Review & Verification UI Paper Prototypes Tracking & Update UI Detailed Stories  Manage status of UI detailed stories Identified Story reviewed by clients Story agreed upon  When requirements are changed Update UI paper prototypes and UI detailed stories Update UI status list in SRS Reviewed by the team

48. Team Dumbledore Spring EOSP 48 SRE (Software Risk Evaluation) DescriptionMitigation plan 1 We don’t have historical data about the productivity of the team; Might underestimate time required to do development. Individual time tracking to gather more information of team productivity. 2 ArchE has to interact with JESS and we don’t know what it will take to make that work; we might not make the JESS experiment work by April 30. Neel will talk to the Felix to discover the issues of ArchE’s interfacing with JESS; Keep progressing on JESS technical prototyping. 2 ArchE was to interact ACME studio or Rational Rose and We don’t know what it will take to make either one; Might not get either to work by April 30. The team should choose only one to implement in this stage. Myung has already done many researches on Rational Rose and we should persuade the client to agree. 2 ArchE core is still evolving and we need a stable core for our design; Could result in failure or a lot of rework at the end. This issue has already been brought up in a client meeting and the need for an intermediate data store has been realized and agreed upon as a means to mitigate this risk. 5 ArchE will be developed as Eclipse plug-ins and the team is not familiar with Eclipse plug-in development; we might not have tabular views with dynamic filters and dialog boxes in the Eclipse experiment by May 5 The technical prototyping and training should carry on. Everybody in the team should be familiar with the plug-in development environment. Mini-SRE Top 5 risks & Mitigation plan Tracking & Update Rank

49. Team Dumbledore Spring EOSP 49 Configuration Management  Migration from VSS to Perforce Preparation for summer semester  Website Renewal Improve usability Enhance maintainability

50. Team Dumbledore Spring EOSP 50  One subcontractor MSIT student Responsible for building ArchE Configurator  Lessons learned Passive interaction with subcontractor Not enough time to communicate with subcontractor  Next steps Major tasks that require interaction with the team  Functional requirements  QA requirements  Structure of RF configuration file  Discussion of communication process Examine post-mortem of teams that used contractors in the past Software Subcontract Management

51. Team Dumbledore Spring EOSP 51 Quality Assurance  Team review Documents  Architecture documentation  Test plan  SRS All team members  More constructive comments  Peer review Review process: one reviewer per team member Reduce flaws Efficient

52. Team Dumbledore Spring EOSP 52 1 We don’t have historical data about the productivity of the team; Might underestimate time required to do development. 2 ArchE has to interact with JESS and we don’t know what it will take to make that work; we might not make the JESS experiment work by April 30. 2 ArchE was to interact ACME studio or Rational Rose and We don’t know what it will take to make either one; Might not get either to work by April 30. 2 ArchE core is still evolving and we need a stable core for our design; Could result in failure or a lot of rework at the end. 5 ArchE will be developed as Eclipse plug-ins and the team is not familiar with Eclipse plug-in development; we might not have tabular views with dynamic filters and dialog boxes in the Eclipse experiment by May 5 6 We don’t agree on what development model were using; We might not define good milestones for next semester, or meet them. 7 We are not adequately tracking progress VS. plans; Miss milestones, unperceived schedule slips 8 We need to transfer the knowledge (especially Eclipse plug-in) among the team members; We might not be able to transfer enough knowledge before development, thus making the development more difficult or lowers productivity. 9 We don’t yet have a QA plan; If we don’t have one by May we Might start producing defective code 10 We have a requirement to work with larger amounts of data without degrading response time; Might be unable to meet this requirement Top 10 Risks

53. Team Dumbledore Spring EOSP 53 RankMitigation plan People in Charge 1 Individual time tracking to gather more information of team productivity. Team 2 Neel will talk to the Felix to discover the issues of ArchE’s interfacing with JESS; Keep progressing on JESS technical prototyping. Neel 2 The team should choose only one to implement in this stage. Myung has already done many researches on Rational Rose and we should persuade the client to agree. Myung 2 This issue has already been brought up in a client meeting and the need for an intermediate data store has been realized and agreed upon as a means to mitigate this risk. Team 5 The technical prototyping and training should carry on. Everybody in the team should be familiar with the plug-in development environment. Paulo 6 We need to come up with a high level development plan by the end of this semester Neel 7 Making more detailed plan and tracking the progress on every Wednesday meeting Henry 8 We need to think about how to use the limited time to transfer as much as possible. This requires each meeting be well prepared and efficient for everybody. Team 9 We need to seek mentors help to make a reasonable QA plan by the end of this semester Henry 10 We need to think about this within this semester by bring this to the client and doing technical experiment. Neel Risk Mitigation Plan

54. Team Dumbledore Spring EOSP 54 SRE ( Software Risk Evaluation ) DescriptionMitigation plan 1 We don’t have historical data about the productivity of the team; Might underestimate time required to do development. Individual time tracking to gather more information of team productivity. Team 2 ArchE has to interact with JESS and we don’t know what it will take to make that work; we might not make the JESS experiment work by April 30. Neel will talk to the Felix to discover the issues of ArchE’s interfacing with JESS; Keep progressing on JESS technical prototyping. Neel 2 ArchE was to interact ACME studio or Rational Rose and We don’t know what it will take to make either one; Might not get either to work by April 30. The team should choose only one to implement in this stage. Myung has already done many researches on Rational Rose and we should persuade the client to agree. Myung 2 ArchE core is still evolving and we need a stable core for our design; Could result in failure or a lot of rework at the end. This issue has already been brought up in a client meeting and the need for an intermediate data store has been realized and agreed upon as a means to mitigate this risk. Team 5 ArchE will be developed as Eclipse plug-ins and the team is not familiar with Eclipse plug-in development; we might not have tabular views with dynamic filters and dialog boxes in the Eclipse experiment by May 5 The technical prototyping and training should carry on. Everybody in the team should be familiar with the plug-in development environment. Paulo Picture of Success Top 5 risks & Mitigation plan Tracking & Update Rank People in Charge

55. Team Dumbledore Spring EOSP 55 SRE ( Software Risk Evaluation )  Minimum success of team Dumbledore ArchE meet at least the “minimal deliverable requirements” stated in SOW. The client is satisfied with ArchE and going to use it or continue to improve it. Eventually we find out a suitable process which we might want to repeat it in the future. All team members at the end believe that they have improved their personal and team skills. All team members at the end believe that they have improved the technical skills in at least one of the following: Java programming, Eclipse plug-in development, Java API to Jess. The cooperation after this year turns out be a nice memory for all team members. Picture of Success Tracking & Update Top 5 risks & Mitigation plan