ArchE Architecture Expert Design Assistant

1
ArchEArchitecture Expert
Design Assistant
End of Semester Presentation, Fall 2003

• Dumbledore Team
• Heng Chen, Myung-Joo Ko, Neel Mullick, Paulo
  Merson

1
2
Understanding of the project from the clients
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
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
Use case modeling
Functional requirements
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
Cognitive walkthrough
Quality requirements
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
Brainstorming
Risk discovery
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)
• Teams 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

• Defect definition
• nature of defects
• intensity of defects
• source of defects

Defects ill defined
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 others 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.
• Teams deliverables should be used as a
  precedent for excellence next year.

44