Team Dumbledore:

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
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 CC view
• High-level module view
• Eclipse plug-in deployment structure

12
High-Level CC 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
ACDM (Architecture-Centric Development Method)
23
ACDM (Architecture-Centric Development Method)

• Technical experiments

Paulo
Henry
Neel
Myung
High-Level CC 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 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

26
Requirement Management
Workflow of UI prototypes
27
Requirement Management

• Example

28
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
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
Requirement Management

• Reviewed by Requirement Manager
• Verified by clients
• Weekly client meeting every Friday 300500 pm

31
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
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
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
SRE (Software Risk Evaluation)
Rank
35
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
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
Progress - This Semester
SOW
SPMP with SRE (MOSP deliverable)
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 Plan
Test cases related to UI stories
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 clients 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
Requirement Management

• Example

47
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
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

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
Top 10 Risks
53
Risk Mitigation Plan
54
SRE (Software Risk Evaluation)
People in Charge
Rank
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.