Spring 2008 Reflections & Are we ready for Summer? Bosch Buzzers Liang-Yun Wang (Mac) Yun-Yin Huang (Melody) Darpan Saini Vytesh Ramesh Yongjoon Choi

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


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


Context diagram


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


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


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


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


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


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



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.


Deployment View


High-level client C&C View


Pattern used:Call-returnImplicit invocation

Important quality attribute scenarios Flexibility


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


Posterboard module view



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


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


Are we ready for Summer ?


Preparation for Summer


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


Earned value


MOSP

Reflection on Earned Value


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.


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


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


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


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


Design, development and QA Process


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


Release plan


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


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 )


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


Get set go for summer

Thanks !


Backup Slides

Knowledge sharing process


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)


Review and inspection > Process


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



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


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

Documents

Spring 2008 Reflections & Are we ready for Summer? Bosch Buzzers Liang-Yun Wang (Mac) Yun-Yin Huang (Melody) Darpan Saini Vytesh Ramesh Yongjoon Choi