1 / 55

End of Semester Presentation 05-07-2004

End of Semester Presentation 05-07-2004. Team Dumbledore: Heng Chen, Myung-Joo Ko, Neel Mullick, Paulo Merson . Agenda. Team Dumbledore The ArchE System Architecture Process Accomplishments and plans Lessons learned. Team Dumbledore. The Team Heng Chen – Team lead, Risk Manager

umed
Télécharger la présentation

End of Semester Presentation 05-07-2004

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Agenda Team Dumbledore • The ArchE System • Architecture • Process • Accomplishments and plans • Lessons learned

  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. ArchE What ArchE Does Requirements Knowledge System • QA scenarios • Functions Codified as Jess rules Designer Architecture

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

  6. Context Diagram

  7. Functional requirements

  8. Quality Attribute Elicitation • Most important quality attributes • Modifiability • Usability • Performance • 17 QA scenarios

  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. Agenda • Team Dumbledore • The ArchE System Architecture • Process • Accomplishments and plans • Lessons learned

  11. Architecture • High-level C&C view • High-level module view • Eclipse plug-in deployment structure

  12. High-Level C&C view

  13. High-Level Module View Standard UML notation

  14. Eclipse Plug-in Deployment Structure

  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. 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. Alternative 1Cache fact base andrefresh after every change

  18. Alternative 2Access facts directly in the coreJess notifies changes

  19. Trade-offs

  20. Agenda • Team Dumbledore • The ArchE System • Architecture Process • Accomplishments and plans • Lessons learned

  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. Functional rqmts/constraintsPaper prototypes Discover quality attribs.Create utility tree 1 Prioritized utility treeInitial project plan Create notionalarchitecture 2 Architecture viewsUpdated project plan Review architectureAnalyze scenarios 3 Risks, tradeoffs Discuss UI functions w/clients 3’ Ready to design& code? No Evaluate risks/tradeoffs Create experiment plan 4 UI detailedstories Yes Experiment planUpdated project plan Legend: Create design Write test code/ write code/ review code 6 Artifact Activity Decision Next step Produces Execute experimentsRevisit architecture 5 Detailed designTest codeSource code Refined architectureUpdated project plan Deploy/integrateor iterate 7 ACDM (Architecture-Centric Development Method)

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

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

  25. ACDM (Architecture-Centric Development Method) • Lessons learned • Conducting two hour workshop for architecture every week helped us a lot • Carrying out technical experimentswasa 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

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

  27. Review & Verification UI Paper Prototypes Tracking & Update UI Detailed Stories 6 2 3 4 1 9 7 8 20 5 16 10 12 11 13 14 17 19 18 15 Requirement Management • Example

  28. UI Paper Prototypes Review & Verification Tracking & Update UI Detailed Stories Requirement Management • 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

  29. UI Detailed Stories Review & Verification Tracking & Update UI Paper Prototypes 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

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

  31. Tracking & Update Review & Verification UI Paper Prototypes UI Detailed Stories Requirement Management • 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

  32. Review & Verification Tracking & Update UI Detailed Stories UI Prototypes Requirement Management • 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

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

  34. Top 5 risks & Mitigation plan Tracking & Update Mini-SRE SRE (Software Risk Evaluation) Rank

  35. Top 5 risks & Mitigation plan Tracking & Update Mini-SRE SRE (Software Risk Evaluation) • 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. Top 5 risks & Mitigation Plan Tracking & Update Mini-SRE SRE (Software Risk Evaluation) • Lessons learned • Could be done earlier • Formulated risks with conditions and consequences • Picture of success is food for thought • Next step • Keep monitoring

  37. Agenda • Team Dumbledore • The ArchE System • Architecture • Process Accomplishments and plans • Lessons learned

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

  39. Development Plan • Iterations • Each iteration will be a deployable unit • One cycle = detailed design + development planning + development + unit testing + integration testing activities

  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. Test cases related to UI stories Test Plan Architectural review April 14 May 3 Final test cases for ArchE1 Integration test cases for ArchE1 Performance testing 7 NOW Unit testing for ArchE1 17 Integration testing for ArchE1 19 22 29 June 5

  42. Agenda • Team Dumbledore • The ArchE System • Architecture • Process • Accomplishments and plans Lessons learned

  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. 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. Questions? Presentation Complete !!!

  46. Review & Verification Tracking & Update UI Detailed Stories UI Prototypes 6 2 3 4 1 9 7 8 20 5 16 10 12 11 13 14 17 19 18 15 Requirement Management • Example

  47. Tracking & Update Review & Verification UI Paper Prototypes UI Detailed Stories Requirement Management • 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. Top 5 risks & Mitigation plan Tracking & Update Mini-SRE SRE (Software Risk Evaluation) Rank

  49. Configuration Management • Migration from VSS to Perforce • Preparation for summer semester • Website Renewal • Improve usability • Enhance maintainability

  50. Software Subcontract Management • 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

More Related