End of Semester Presentation

1
End of Semester Presentation

• Team Phoenix
• May 6 2005

2
Agenda

• Project Introduction
• Project Dimensions
• Problem Definition
• Design
• Planning
• Operations
• Implementation
• Plan for the Summer Semester
• Conclusions

3
People
Project Introduction

• Team Phoenix
• Jinhee Lee
• Luis D. Maya
• Soumya Simanta
• Min Wang
• Mentors
• Grace Lewis
• Scott Hissam
• Technical Editor
• Yassen Kolarov

• Clients SEI
• Felix Bachmann
• Len Bass
• Mark Klein
• Clients Robert Bosch Corp.
• Charles Shelton

4
Roles
Project Introduction
5
What is ArchE?
Project Introduction
ArchE (Architecture Expert Design Assistant) is
the assistant tool that creates software
architecture with requirements and architectural
knowledge
Requirements
Architectural Knowledge
ArchE

• ArchE is an expert system
• ArchEs brain is a rule engine
• Architectural knowledge is codified as Jess rules

Software Architecture
6
Context Diagram ArchE System
Project Introduction
ArchE UI
ArchE-I
Software Architect
Architecture
ArchE Core
Architectural Knowledge Provider
Jess Rule Engine
Eclipse Platform
7
Business Drivers Requirements
Project Introduction
Business Drivers
Functional Requirements

• Allow architectural experts to easily and
  intuitively input their architecture design
  knowledge into ArchE without knowing Jess
• Help architects to understand the rationale
  behind ArchEs design decision
• Create a dynamic environment to test and debug
  the architectural rules
• Allow knowledge providers to share their
  architectural knowledge

• Abstract Rule Language (ARL) editor
• Rationale capability
• Abstract rule debugging environment
• Import/Export reasoning framework

8
Agenda

• Project Introduction
• Project Dimensions
• Problem Definition
• Design
• Planning
• Operations
• Implementation
• Plan for the Summer Semester
• Conclusions

9
What we proposed
Proposals Problem Definition

• Approach

• Evaluation

Domain analysis

• Domain object model

Functional req.

• Use case analysis

Quality attribute

• Quality attribute workshop

• Use case points
• Notional architecture
• Estimation

Project scope
User interface

• Paper prototyping

• Deliverables Activities

• Quality attribute workshop (QAW)
• Scope estimation and negotiation
• Software requirements specification
• User interface prototype

10
Scope Estimation and Negotiation
Best Practices Project Scope

• The team and the clients reached an agreement on
  the project scope based on our estimation and
  tracking data

Negotiated Scope
Estimation
Prioritized Features
Delphi Estimation

• Estimated Effort for each feature

1
Highly usable abstract rule language editor
Abstract Rule Editor
Suggestion from team

• Complexity Factors

2
At least implemented rationale capability
Rationale Capability

• Available Resources

3
Debugging Environment
At least stubs debugging feature
Tracking Data

• Estimation Variance

Discussion with clients
4
Import/Export RF
At least stubs import/export RF

• Data Adjustment

11
Paper Prototyping
Best Practices User Interface
1. Use paper and flip charts to sketch the user
interfaces
2. Discuss and review with clients
3. Finalize the user interface using PowerPoint
and Eclipse
4. Find new requirements to be added
12
Paper Prototyping
Best Practices User Interface
Benefits

• Helped us to identify functional requirements
• Helped us to discuss the detailed design
  concerns
• Helped us to verify technical feasibility
• Helped us to estimate the scope

Improvements

• Need to discuss on the usability issues
• Need to get more detailed and specific user
  interaction scenarios

13
Reflections on Problem Definition
Reflections Problem Definition

• What went well
• We successfully used most of the techniques we
  proposed
• We gained trust by using historical data to
  convince our clients during the scope negotiation
• We successfully used paper prototyping to
  facilitate the discussion about functional
  requirements
• What can be improved
• We misinterpreted the abstract rule language
  requirement. We started late

14
Agenda

• Project Introduction
• Project Dimensions
• Problem Definition
• Design
• Planning
• Operations
• Implementation
• Plan for the Summer Semester
• Conclusions

15
What we proposed
Proposals - Design

• Approach

• Evaluation

Architectural design

• Notional architecture
• Utility trees and quality scenarios
• Alternatives and tradeoffs

Detailed component design

• UML 2.0

• Deliverables

• Notional architecture
• Architecture document
• Detailed design document

16
Architectural Design Process
Best Practices Architecture Design
Based on ACDM
17
High-level Architecture (CC View)
Best Practices Architecture Design
RF Reasoning Framework
18
Quality Attribute Scenario Traceability
Best Practices Architecture Design
Scenario 10 Easy to attach/detach external
interface
The Bosch specific interface should flawlessly
integrate with the ArchE-II system without any
code changes. ArchE-II should be like a plug and
play component for the Bosch specific interface
Extensibility
Attribute
Concern
Easy to attach/detach new interface
Importance
Difficulty
High
High

• Can our clients from SEI selectively provide
  functional components to Bosch?
• Does our high-level architecture meet this
  high-priority scenario?

19
ArchE-II Bosch Integration
Best Practices Architecture Design
Eclipse Platform
Rule Editor Sub-system
ArchE-II Kernel
ArchE-II Kernel
Jess Rule Engine
20
Constraints
Best Practices Architecture Design
Constraints
Architectural Impact
1
ArchE-II should run independently of ArchE-I
This promotes loose coupling between ArchE-I and
ArchE-II
2
The user interface for the ArchE-II system should
be a plug-in for the Eclipse platform
MVC patterns was obvious pattern of choice for
the UI
3
New version supports JessML that is more
structured and hence makes transformation easier
The ArchE-II system should support new version of
the Jess rule engine
4
The ArchE-II system should be implemented in Java
21
Architectural Patterns Used
Best Practices Architecture Design
22
Reflections on Design
Reflections Design

• What went well
• Continuous architecture review and refinement
• Involve the clients in architecture reviews. They
  are informed and give early feedback
• Get advice from architecture and domain-specific
  knowledge experts
• Use of core courses to help us in design tasks
• What can be improved
• We need to do more experiments

23
Agenda

• Project Introduction
• Project Dimensions
• Problem Definition
• Design
• Planning
• Operations
• Implementation
• Plan for the Summer Semester
• Conclusions

24
What we proposed
Proposals Planning

• Approach

• Evaluation

Initial plan

• Defines resources
• Milestones, deliverables
• Task leads, WBS

Tracking Analysis

• Gantt chart tracking, Data collection
• Track milestone, Earned value
• Status report, Task prioritization

Estimation

• WBS, Delphi

• Deliverables

• Semester plan
• Estimation data
• Weekly status reports
• Studio project management plan (SPMP)

25
Milestones for Spring Semester
Best Practices Estimation and Tracking
M0.Project Plan is ready (01/21)
M5. Architectural Review (04/04)
M1. Approved SRS v2.0 (02/24)
M7. ARL Spec. Draft (04/30)
M2. Agreed scope with clients (02/28)
M3. Finished notional architecture (02/28)
M9. MOSP completed (03/04)
M6. Experiment Result report (04/22)
M8. Eclipse Training Workshop (03/13)
26
Estimated vs. Actual by Week
Best Practices Estimation and Tracking

• The team has tracked working hour weekly and
  analyzed the difference between estimated and
  actual efforts

Actual Efforts/week 67.29 hrs
Variance 7.3
Estimated Efforts/week 66.8 hrs
Variance (Actual Estimation)/Estimation
Effort in hours
Avg.
Time in Weeks
27
Estimated vs. Actual by Activity
Best Practices Estimation and Tracking

• Excluding two failed tasks, the variance
  between estimated and actual efforts increased

Total Actual 1200.97 hrs
Adjusted Variance 24.3
Total Estimated 966.26 hrs
Variance (Actual Estimation)/Estimation
Work Hour
28
Overall Earned Value
Best Practices Estimation and Tracking
Budget Cost 1,030.9 hrs
Earned Value 830.0 hrs
Actual Cost 1,076.8 hrs
Schedule Variance -200.9 hrs
Cost Variance -246.7 hrs
Cost (Hours)
Time in Weeks
29
Earned Value Break-down
Best Practices Estimation and Tracking
Ex) Architecture Design
CPI (Actual Earned Value))/Actual SPI
(Planned Earned Value)/Planned
30
Project Status Reports
Best Practices Estimation and Tracking

• 1. Dashboard to check overall status
• Status of overall tasks
• Status of milestones
• Status of deliverables

• 2. Check weekly-based project progress
• Project progress
• Resource/Task-based working hour

• 3. Continuous earned value tracking
• Earned value review
• Performance analysis

• 4. Checklist for next week
• WBS number for each task
• Highlight important tasks for next week

31
Reflection on Planning
Reflections Planning

• What went well
• We had clear goals and detailed plan from the
  first day
• Semester plan is ready before spring semester
  began
• Kickoff meeting set expectations
• The mentors and the team knew the status of the
  project all the time
• Detailed progress status report
• We made decisions based on our collected data
• What can be improved
• The reports take too much time to produce 2-3
  hours
• The project plan assumes we will work overtime
  every week
• Result we are always behind the schedule

32
Agenda

• Project Introduction
• Project Dimensions
• Problem Definition
• Design
• Planning
• Operations
• Implementation
• Plan for the Summer Semester
• Conclusions

33
What we proposed
Proposals Operations

• Approach

• Evaluation

• Establish and follow
• Training process
• Meeting process
• Configuration management process
• Risk management
• Track and review all the processes

• Deliverables

• Meeting process
• Training process
• Configuration management plan
• Risk mitigation plan
• Reflection updating proposals

34
Top 5 Current Risks
Best Practices - Operations
Mitigation Plans
Risks (Condition Consequence)

• Dedicate first two weeks of summer to
  detailed design
• Have a design workshop with our clients

We have not done detailed design yet this might
delay our summer schedule
1
Requirements have changed the negotiated scope
could be too broad for the summer

• Re-negotiate scope after detailed design

2

• Use analysis final project to start early
• Consult experts

We started the ARL late we may run into
implementation issues
3
Most team members are not Java experts our
productivity would be reduced

• Use pair programming for the first one month

4
Our four clients do not always agree decision
making can be time consuming

• Explicitly ask for approvals and inform the
  clients of the potential impact

5
35
Process Review Scorecard
Best Practices - Operations

• Gives overall status of our processes
• Shows status, goal, measure, target, and strategy
  in one line
• Tracks progress through time
• Forces us to think in simple metrics for each
  goal
• Requires short time to update
• Prioritizes the process-related tasks
• Reminds us to follow the proposals

36
Reflections on Operations
Reflections Operations

• What went well
• Meeting process
• Planned ahead all meetings at the beginning of
  this semester
• Helped clients to understand where we are and
  what is next step
• Scorecard
• Tracked the state of all processes directly
• Structured and prioritizes process-related tasks
• Reminded us to follow our proposals
• What can be improved
• Role task time tracking
• Add them to the project plan
• Plan and track them
• Action items tracking
• Use a better tool to track them
• Review them every week
• Can be only removed in the meeting

37
Agenda

• Project Introduction
• Project Dimensions
• Problem Definition
• Design
• Planning
• Operational
• Implementation
• Plan for the Summer Semester
• Conclusions

38
What we proposed
Proposals Implementation

• Approach

Pair programming Try pair programming in order to
bring all the team members up to speed with Java
and Jess Data collection and measurement Track
the time spent on coding, testing, and
reworking Coding standard Agree on one coding
standard Tools for defect tracking Select and use
a defect tracking and data collection tool, such
as Rational Clear Quest or Bugzilla
39
Agenda

• Project Introduction
• Project Dimensions
• Problem Definition
• Design
• Planning
• Operational
• Implementation
• Plan for the Summer Semester
• Conclusions

40
Summer Semester Goals Deliverables
Plan for the Summer Semester
Semester Goals
Complete and deliver the product and artifacts to
the customer on time by August 4
Deliver a high-quality software product and
report the results of software testing
Have a flawless customer relationship
Apply the knowledge from core courses for the
benefit of the ArchE system
Deliverables
Detailed component design
Executable package and source code
User manual and installation guide
Test suites and test results
41
Roles and Responsibilities
Plan for the Summer Semester

• Plan, track, assign, estimate Tasks
• Coordinate in project

Luis Maya
Team Leader

• Lead architectural and detailed design tasks

Chief Architect
Jinhee Lee

• Plan, document, execute test scenarios
• Coordinate technical experiments

Chief Scientist
Soumya Simanta
Requirement /Client Manager

• Manage SOW, SRS
• Schedule, organize client meetings

Soumya Simanta
Deployment Manager

• Manage packaging deliverables
• Coordinate documenting user guides

Min Wang

• Track, report, analyze defects and bugs
• Audit development process

Support Engineer
Min Wang

• Design, code, test components

Software Engineer
All Members
Configuration Manager

• Update website
• Manage version control for source code

Luis Maya
42
Draft Project Schedule for Summer
Plan for the Summer Semester
May
June
Aug
July
Phase
W4
W6
W7
W8
W10
W12
W9
W11
W5
W1
W2
W3
Production plan, approved rule language
Detailed design and experiments
Detaileddesign
Code delivery
Iteration 1
Code delivery
Detailed plan
Iteration 2
Code complete
Detailed plan
Iteration 3
Reflection
2nd reflection
3rd reflection
1st reflection
Presentations
MOSP
EOSP
Milestone
Work in this task
43
Agenda

• Project Introduction
• Project Dimensions
• Problem Definition
• Design
• Planning
• Operations
• Implementation
• Plan for the Summer Semester
• Conclusions

44
Project Accomplishments
Conclusion
Fall 2004

• Statement of work (SOW)
• Software requirement specification (SRS) draft
• Software project management plan (SPMP)
• Software risk evaluation workshop (SRE)
• Quality attribute workshop (QAW)

Spring 2005

• Software requirement specification (SRS)
• Project scope
• User interface paper prototype
• Architectural review
• Architecture design document
• Abstract Rule Language (ARL) specification draft

45
Best Practices
Conclusion
Defining Project Scope
A.

• We gained trust from our clients by using
  historical data to define the scope of the project

Good Project Management
B.

• Initial kickoff meeting and project plan
• Estimation and tracking of work hours and
  earned value
• Weekly status reports

Reviewing Process
C.

• Balanced scorecard to check our working
  processes
• Improved meeting process

Architectural Design
D.

• Continuous architecture review with clients and
  experts

46
Application of Core Courses
Conclusion
Fall 2004
Spring 2005
Summer 2005
Methods Use case modeling
Requirements and design
Methods Problem frames
Problem definition
MSD Negotiation
Project scope
Architectural concepts
High and low level design
Analysis techniques
ARL
Test definition
MSD Risk, WBS, EVT, estimation
Project management, tracking, and estimation
47
Phoenix Team
Conclusion
Background
Attitude
Team Spirit
48
Acknowledgements
Conclusion

• Team Phoenix acknowledges and thanks
• Jung-soo Kim
• Anthony Lattanze
• Paulo Merson
• Chris Metcalf
• Jaime Oviedo
• Yash Patodia
• Linda Pesante
• Prasanth Ramanand
• Ravi Ranjan
• Dave Root
• Nicholas Sherman

In alphabetical order