Spring 2008 Reflections &
Are we ready for Summer?
Bosch BuzzersLiang-Yun Wang (Mac)
Yun-Yin Huang (Melody)Darpan Saini
Vytesh RameshYongjoon Choi
Outline Project Overview Gathering the architecture drivers Creating the architecture Getting ready for summer Summary Q&A
04/21/23 2 Bosch Buzzers - EOSP Spring 2008
The team
04/21/23 Bosch Buzzers - EOSP Spring 20083
Role Team member
Managing Engineer Melody
Support EngineerQuality Manager
Darpan
Requirement Engineer, Client liaison
ChoiDarpan
Chief Scientist Vytesh
Chief Architect Mac
Software Engineer All
Clients, mentors & technical advisors Client
Robert Bosch LLC Research &Technology Center, North America Representatives:
Dr. Chris Martin Dr. Charles Shelton Dr. Marcelo Cataldo
Mentors Mel Rosso-Llopart Felix Bachmann
Technical advisor Dr. Jim Herbsleb Tony Lattanze
04/21/23 4 Bosch Buzzers - EOSP Spring 2008
Project goal
Short research report in GSD best practice Produce a prototype for software to assist in collaboration
and conformance checking during the design phase This prototype could later be extended by the client
04/21/23 5 Bosch Buzzers - EOSP Spring 2008
Context diagram
04/21/23 Bosch Buzzers - EOSP Spring 20086
Architecture centered processStage 1: Discover architecture drivers
Stage 2: Establish project scope
Stage 3: Create notional architecture
Stage 4: architecture review
5. Production Go? No-Go?
Stage 6: Experiment planning
Stage 7: Experiment executing and refine architecture
Stage 6: Production planning
Stage 7: Production
2008/3/7 7 Bosch Buzzers - MOSP Spring2008
Functional requirements stability
04/21/23 Bosch Buzzers - EOSP Spring 20088
Re-scope
Paper prototypes,Talking to experts
Collaboration experiment
Constraints Technical
Must plug into Eclipse Windows 2000 or XP should be used as the operating
system for development Business
Schedule – Initial delivery by August 15th
Resources – 5 member MSE team
112/04/21 Bosch Buzzers, MSE, CMU 2007-20089
04/21/23 Bosch Buzzers - EOSP Spring 200810
Mac: Looks goodMac: class1 blah blahMac: class 2 blah blahDarpan: sure doesDarpan: No class 3, I am not even looking at what you are saying man!!
MacDarpan
04/21/23 Bosch Buzzers - EOSP Spring 200811
Mac: Looks goodMac: class1 blah blahMac: class 2 blah blahDarpan: sure doesDarpan: No class 3, I am not even looking at what you are saying man!!
MacDarpan
04/21/23 Bosch Buzzers - EOSP Spring 200812
Mac: Looks goodMac: class1 blah blahMac: class 2 blah blahDarpan: sure doesDarpan: No class 3, I am not even looking at what you are saying man!!Darpan: Move this to the Whiteboard
MacDarpan
04/21/23 Bosch Buzzers - EOSP Spring 200813
Mac: Looks goodMac: class1 blah blahMac: class 2 blah blahDarpan: sure doesDarpan: No class 3, I am not even looking at what you are saying man!!Darpan: Move this to the Whiteboard
MacDarpan
The architecture Used Attribute Driven Design (ADD) to create the
architecture Architecture review Did experiments to answer questions in the architecture
Eclipse Graphical Editing Framework (GEF) Eclipse Modeling Framework (EMF) Java EE
04/21/23 Bosch Buzzers - EOSP Spring 200814
04/21/23 Bosch Buzzers - EOSP Spring 200815
QAW - HighID Quality
attributeAttribute concern
QA scenario
QA03 Flexibility New design views
A new view containing two different elements with properties and two different type of relations with properties and topology constraints and hooks to other views has to be created using the tool. The specification is executed by the tool with no errors. And the spec is added by someone familiar with the tool within 80 hours.
QA04 Flexibility Concepts Charles comes up with a new metric or analysis to evaluate the design, e.g. a new type of constraint between two views needs to be checked, should be added to the tool after the analysis has been implemented, within 8 hours.
2007/12/1316Bosch Buzzers - EOSP Fall2007
QAW - HighID Quality
attributeAttribute concern
QA scenario
QA07 Interoperability
Usage of artifact between different tools
A UML state chart U is edited and saved using Charles's tool. This chart U is readable by any other standard UML editor. The artifact produced is compliant to OMG (object management group) UML serialization standard.
QA08 Usability interactivity Consider a user in Germany makes a change to an artifact. If it violates a preselected constraint, tool give feedback in the form of a warning box. E.g. a box within triangle containing an exclamation mark (Triangle is in yellow color). Feedback appears to all users online within 2 seconds.
2007/12/1317Bosch Buzzers - EOSP Fall2007
Deployment View
112/04/21 Bosch Buzzers, MSE, CMU 2007-200818
High-level client C&C View
112/04/21 Bosch Buzzers, MSE, CMU 2007-200819
Pattern used:Call-returnImplicit invocation
Important quality attribute scenarios Flexibility
04/21/23 Bosch Buzzers - EOSP Spring 200820
Source End user, developer
Stimulus A new view containing two different elements with properties and two different types of relations with properties and topology constraints and hooks to other views has to be created using the tool
Artifact The PosterBoard
Environment Compile time
Response The new view is added to the tool without any errors
Response Measure The view is added to the tool within 80 hours
Architecture alternatives For UML modeling, the underlying tool we are going to
use is Papyrus (open source) Since it is off-the-shelf, we could
Either look into the code of Papyrus and modify it so that it presents a PosterBoard instead of standalone diagrams
Or write adapters, so that a generic PosterBoard understands it
04/21/23 Bosch Buzzers - EOSP Spring 200821
Posterboard module view
04/21/23 Bosch Buzzers - EOSP Spring 200822
04/21/23 Bosch Buzzers - EOSP Spring 200823
Client side
load
Legend
Component
Call-return
Session Event Bus
post querypost query
<<EJB Client>>Camel Client
update
UML Model Rules
<<EJB Client>>Conformance Manager
report
update
query
<<EJB Client>>Snapshot Manager
Session data models
component
Event Bus
Data provider
Data consumer
notify
Snapshot Retriver
Client side Client boundary
Technical risks
04/21/23 Bosch Buzzers - EOSP Spring 200824
Condition Consequence Mitigation
We don’t have enough knowledge of the UML editing tool
We may not know how to design the integrated solution
Conducted experiments to understand the underlying tool
We are unsure how to manage locks on UML diagrams
Might not be able to satisfy a must have requirement
Negotiated with client on the requirement
Experiment for free hand drawing using GEF not completed
May not be possible to fulfill that requirement conventionally using GEF
Before implementing the WhiteBoard module, this must be experimented and designed for
Reflection on creating the architecture The diagrams help the understanding of the system
among team members better But, it takes too long to write the text Some of us still think a connector and component is the
same thing The time needed to experiment is hard to estimate Architecture helped us identify technical risks
04/21/23 Bosch Buzzers - EOSP Spring 200825
Are we ready for Summer ?
04/21/23 Bosch Buzzers - EOSP Spring 200826
Preparation for Summer
04/21/23 Bosch Buzzers - EOSP Spring 200827
Estimation technique usedCategory Size Estimation
Small 20
Medium 50
Large 100Camel Server
Legend
Camel client+post(in ticket : Session Ticket, in events : event parcel)+query(in ticket : Session Ticket) : event parcel
«interface»Sync
UML, and default legend depicted in 5.1
«Entity»Collaboration Session
-lastSeenEventID
«Entity»Participant Cursor
Session Ticket
1 *
«Entity»Session Event
Event ID
1 1
«uses»
+post(in ticket : Session Ticket, in events : event parcel)+query(in ticket : Session Ticket) : event parcel
«Stateless Session Bean»Sync Manager
«uses»
«uses» Baseline estimation: 100 hours
Baseline estimation: 20 hours
Module 1 Module 2 Sum
Effort (hours) 100 20
REQ 1 √ √ 110
REQ 2 √ 10
04/21/23 28 Bosch Buzzers - EOSP Spring 2008
Earned value
04/21/23 Bosch Buzzers - EOSP Spring 200829
MOSP
Reflection on Earned Value
04/21/23 30 Bosch Buzzers - EOSP Spring 2008
To improve our earned value : Re-planning helped We planned for higher granularity of tasks We decided to prioritize our planned tasks over unplanned
tasks Increased time sheet tracking
Our earned value slipped at times during heavy load of core courses and electives.
Common time of studio members in cave helped
Risk Status (Top 3)Condition Consequence Mitigation
The estimation is not conducted using formal methodology
Might cause milestones to slip
We will use PSP Dashboard to measure time spent on each module in the first sprint, and calibrate the plan
We are not used to stringent schedule in the cave
Everyone might not put in the 48 hours
We are going to start working a week before summer officially begins and gradually apply more rigor
The QA and planning processes have not been tested yet, might cause chaos in the first release.
Might cause chaos in the first release.
We are going to run a micro project which can test these processes.
04/21/23 31 Bosch Buzzers - EOSP Spring 2008
Process for summer Iterative development
3 iterations of 4 weeks each Scrum approach to project management
Six sprints of two weeks each Daily standup meetings Product backlog using customer prioritization Burn down chart for progress tracking Sprint retrospective at the end of each sprint Three releases of four weeks each
Why Scrum ? Team has some experience Tracking using Scrum worked in Fall
04/21/23 Bosch Buzzers - EOSP Spring 200832
Team roles for SummerRoles Team member
Team Lead Darpan
Configuration manager & support manager
Choi
Quality assurance manager & Chief architect
Vytesh
Client liaison & Requirements manager Melody
Scrum master Mac
Risk manager Melody
Software developer Everyone
04/21/23 Bosch Buzzers - EOSP Spring 200833
Load balancing Going from 12 to 48
Start working a week in advance In the first month, there is no flexi time. Be in the cave at 10
AM everyday. (Big Boss’s order ) Weekly team activities to handle burnout
04/21/23 Bosch Buzzers - EOSP Spring 200834
Knowledge transfer sessions Experiments revealed that team needs more technological
training in Eclipse and related technologies We conducted knowledge transition within the team Some of them include, Eclipse plug-in, Java EE
04/21/23 Bosch Buzzers - EOSP Spring 200835
Design, development and QA Process
112/04/21 Bosch Buzzers, MSE, CMU 2007-200836
DesignDesign Design ReviewDesign Review
• Code
• Informal Code Review
• Code
• Informal Code Review
Create/runUnit Test
Create/runUnit Test
Create Smoke/Stress/
Functional Test Cases
Create Smoke/Stress/
Functional Test Cases
Formal Code inspection
Formal Code inspection
Critical modules only(assigned by chief-architect, based on complexity)
MODULEMODULE
Proposals Updated existing proposals
Planning proposal Operational proposal Problem definition proposal Statement of work
Created Design proposal Implementation proposal Quality assurance plan
04/21/23 37 Bosch Buzzers - EOSP Spring 2008
Release plan
04/21/23 Bosch Buzzers - EOSP Spring 200838
Chat Server, Command manager
Chat ClientChat Client Collaborative UML toolCollaborative UML tool
Collaborative PosterboardCollaborative Posterboard
Standalone WhiteBoardStandalone WhiteBoard
Collaborative WhiteboardCollaborative Whiteboard
PlaybackPlayback
Release 0.1 – 15%
Release 0.3 – 100%
Release 0.2 – 50%
Snapshot Manager
Administration
UML 2 Whiteboard transform
UML 2 Whiteboard transform
15th June 2008
13th July 2008
10th Aug 2008
Quality assurance plan Determined quality goals
Twenty or fewer defects per thousand lines of code after unit testing
Broken builds are not left unfixed overnight Plan for unit testing, integration testing and regression
testing in place Mantis to be used for defect tracking Atleast 80% code coverage to be achieved for junit
testing Plan for system testing should be ready during detailed
design
04/21/23 Bosch Buzzers - EOSP Spring 200839
Time allocation 20% operating and
planning Historical data from
previous team 16% buffered time
Nice to have functions & estimation calibration
Infrastructure setup Set up Wiki at http://buzzers.webhop.net/ Version control – Subversion Defect tracking – Mantis Development environment Ant for nightly builds Nightly backup (Don’t rely on SCS )
04/21/23 41 Bosch Buzzers - EOSP Spring 2008
Summer checklist
Stabilize requirements Risk assessmentProcess and rolesPlan. Implementation. Quality assurance. Release
Summary Accomplishments
Conducted SRE early this semester Scope negotiation Detailed requirements SRS delivered Proposals Architecture defined
04/21/23 Bosch Buzzers - EOSP Spring 200843
Get set go for summer
Thanks !
04/21/23 Bosch Buzzers - EOSP Spring 200844
Backup Slides
Knowledge sharing process
04/21/23 Bosch Buzzers - EOSP Spring 200846
Requirement change
Hermes EOSP (Summer 2007)
48
Time allocation from previous team
Development
QA AppraisalQA Fixing
Detailed design
Time allocation from previous team
Earned value (Actual hour spent included)
04/21/23 Bosch Buzzers - EOSP Spring 200850
Review and inspection > Process
112/04/21 Bosch Buzzers, MSE, CMU 2007-200851
Author Reviewer Phase
Before Meeting
Review Meeting
After Meeting
If rework
Preparing materialPreparing material
•Decide who should in the review•Distribute material•Decide who should in the review•Distribute material
Moderator
Preparing material Preparing material
Walkthrough Walkthrough
Ask questionGive suggestions Ask questionGive suggestions
Response Response
Scribe
Logging Logging
No
Make action items Make action items
Done
Yes
No
Rework Rework
Verify
Yes
No
DONE
Reflection on SCRUM
The subtasks were not defined with enough precision This made task tracking hard and inaccurate
Defining the exit criteria for tasks was not easy since we were writing a report
The earned value was 56% of planned value If we were to use SCRUM again
Make sure every task and subtask is well defined before entering the sprint
Make sure we are spending majority of our time on the project, e.g. the summer when we have 48 units
2007/12/1352Bosch Buzzers - EOSP Fall2007
04/21/23 Bosch Buzzers - EOSP Spring 200853
Legend
Camel client
Camel Server
Snapshot Manager
Conformance Manager
«interface»Persistence
«interface»Session Management
«interface»Team View
«interface»Assign Role
«interface»Sync
«interface»Playback
«uses»
«uses»
«uses»
«uses»
«uses»«uses»
«uses»
«uses»
«uses»
«uses»
«interface»Interface1
Package1
«uses»
«uses»
«interface»Interface2
Interface used by the editing client
Interface shared by the editing client, conformance and
snapshot managers
package
Web Admin
«interface»Admin
«uses»
«interface»Admin Administration
interface
Development and Release QA Process
112/04/21 Bosch Buzzers, MSE, CMU 2007-200854
2-week sprint 3-day release preparation
1-month release cycle 1-month release cycle
Stress TestFunctional TestRework
Fix for critical issues
Design ReviewUnit TestSmoke TestCode reviewCode inspection