MOSP from Bosch Buzzers (Spring 2008)

MOSP from Bosch Buzzers(Spring 2008)

Darpan SainiYongjoon Choi

Vytesh RameshLiang-Yun(Mac) Wang

Yun-Yin(Melody) Huang

Outline Project Overview Process and Semester Plan Architecture Driver and Scope Architecture and Experiment Risk Analysis Detailed Plan and Execution Conclusion and Q&A

2008/3/7 2 Bosch Buzzers - MOSP Spring2008

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 as a research tool


The project


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


ACDM stagesStage 1: Discover architecture drivers Stage 1: Discover architecture drivers

Stage 2: Establish project scope

Stage 3: Create notional architecture

Stage 4: architecture reviewStage 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

Complete

ProcessingProcessing

Incomplete


The team

Role Team member

Managing Engineer Melody

Support EngineerQuality Manager

Darpan

Requirement Engineer ChoiDarpan

Chief Scientist Vytesh

Chief Architect Mac

Software Engineer All


First Half

112/04/21 Bosch Buzzers, MSE, CMU 2007-20088

JanJan

FebFeb

Later Half


MayMay

MarMar

AprApr

Architecture driver and Scope Techniques used to stabilize the requirements

Academic paper survey Existing tool survey and demonstration Paper prototype Expert opinion


Scope Refinement and Requirement Stabilization Nov 07

Build a prototype tool to assist communication and conformance checking during the design phase

Dec 07 A UML-aware, shared whiteboard Conformance checking

Jan 08 Survey of design collaboration Several paper prototyping sessions and existing tool demonstration Meetings with Jim and Marcelo

Feb 08 Poster board with individual view ports


Requirements stability

2008/3/7 Bosch Buzzers - MOSP Spring200812

Architecture driver - Paper Prototyping 1


Architecture driver - Paper Prototyping 2

Poster boardPoster board

chatchatChatChat

vytesh

UML diagram is saved as XML formatWhiteboard is saved as jpeg, gif format


Architecture driver - Paper Prototyping 3 Conformance part was risky from the beginning How did we stabilize this?

Reduced the scope by negotiating with client Paper prototyping


Reflection on Paper Prototyping Quick feedback Clients appreciate the results of paper prototyping Both clients and team gain more understanding about

the tool Need customer’s involvement to get detail requirements


Architecture and Experiment Use ADD to make sure the quality attributes are

answered and requirements filled


ADD - 1


QA-08 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.

H M

ADD - 2


QA-13 RELIABILITY

LOSS OF COMMUNICATION/CONNECTION

Scenario same as 5. During the session there is a network failure and connection is lost (at the host) between network sites, After the connection is restored, the model which was being worked on is not lost. There should be no data loss and latest model is updated.

H H

ADD - 3


Collaboration Server (C)

Session File Repository (D)

Client (A) with Facilitator’s Right

Client (B)

Client (B)

Team Version Controlled File Repository

Link A

Link A

Link A

Link B

Management console (E)Link C

Runtime object

Communication

Boundary of tool

ADD - 4


UML Model

UML Editing tool

Link A

Link B

Poster boardWhiteboard

Graphical Subsystem

Runtime object

Communication

Experiment and Exploration Openfire Jazz UML Editing tool


Papyrus Topcased eUML2 (Free) UML2 ToolsPopularity High High High N/AReview of general users

High High Med N/A

Functionality UML, OCL, and lots more

Roughly the same as Pap

Class + Sequence

UML

Product Life Stable Merge with Papyrus

Moving to commercial

Example

Extensibility GEF and EMF N/A N/A GMF

Risk Analysis SRE (Small Team Risk Evaluation) Threshold of success: 5 Duration: 5 hours Total risks identified: 23 Define mitigation for top 3 risks

Taxonomy Count

Product Engineering 13

Development Environment 7

Program Constraints 3


Risk Status (Top 3)

Condition Consequence

Sometimes the team doesn’t spend 60 hours on studio

might delay artifact delivery and slip our schedule

We are currently evaluating two tools (server/client) which we aren't sure are compatible

might have to drop Jazz and implement the desired functionality ourselves

We haven't measured the size & complexity of the system

might have to conduct more architectural experiments than planned to assess feasibility


Risk mitigation Team members to spend 3 afternoons per week in the

cave as common team time. We dropped evaluation of Openfire, and put the freed

resource on evaluating Jazz. Had eclipse plug-in development knowledge sharing

session.


Detailed Plan and Execution Short-term plan

Use two weeks as an iteration Managing engineer assigned main task and responsibilities Team members define subtasks and exit criteria Quality manager assures the quality of subtask


Earned Value


Proposals Update

Planning proposal Operational proposal Problem definition proposal

Created Design proposal (for architecture)

Planned Design proposal (for detail design) Implementation proposal


Workspaces Set up Wiki website on http://128.2.188.131/

Requirement document Architecture document Meeting minutes Cross reference for traceability Maintain change history

Set up SVN server Version control Timesheet Semester/short-term plan Action item/task tracking form


Conclusion Accomplishment

SRS delivered Notional architecture SRE

Preparation Started knowledge transfer Experiment plan


Questions to mentors How do we know our progress on architecture? How do we estimate the time we require to finish

architecture and detail design? Whether the evaluation of tools and technology can be

treated as experiment in ACDM? Is there any tool for requirement and architecture

traceability? Is there any better way to trace if we are following ACDM

process?


Happy Spring Break!

Backup Slides

Local hard drive

Eclipse platform

Case 0: Work Alone


UML Editing Tool

Subclipse

Subversion serverversion controlled file repository (remote)

UML Model

1,8

2,10

3,9

4, 6

5,7

1 Update from svn

2 Download

3 Update local file

4 Fire UML tool

5 Load model

6 Edit and check conformance through tool

7 Save model

8 Commit back to svn

9 Load file

10 Upload to svn

Conformance Manager

Local hard drive

UML Model

Case 1: Initiate Session


Eclipse platform

UML Model

1 Open session console

2 Read descriptor

3 Request session list

4 Create session with model files

5 Create session object

6 Connect to session

7 Load model files into local cache

8 Upload into session

9 Fire UML tool

Camel Server

Server Descriptor file

Client Session

Model FilesModel Files

2

37

UML Editing Tool (E)

9

Session Console

1,4

5

6,8

Case 2: Join and Continue


Eclipse platform

Camel Server

Server Descriptor file

Session Console

Client Session

Model FilesModel Files

Whiteboards

Client Status

Chat Log


2 Load server descriptor

3 Request session list

4 Join/continue session

5 Create session

6 Download latest snapshots and/or history

7 Fire up poster board

1,4

2

3

5

6 UML Editing Tool (E)

7

Case 3: Playback



2 Select playback

3 Create session

4 Read session files

5 Fire up UML tool

Client (A)


Client Session (G)

Model FilesModel Files (F)

Whiteboards (H)

Client Status (J)

Chat Log (L)

Local/network hard drive

Session files

Session Console1,2

5

3

4

Server Side (Logic View)


Java EE Application Server (A)

Server Session (B)

Model FilesModel Files (C)

Whiteboards (D)

Client Status (E)

Chat Log (F)

Client Session (G)

Web Server (I)

Management Console (J)

Client Cache of Chat Log, Model Files, Whiteboards, and Client Status (H)

Link A

Link B

Link C

Client Side (Logic View)


Client (A)

Server Session (P)

Session Data: Chat Log, Model Files, Whiteboards, and Client Status (Q)


Client Session (G)

Model FilesModel Files (F)

Whiteboards (H)

Client Status (J)

Chat Log (L)

Poster board view (K)

Whiteboard view (I)

Chat view (M)

Conformance Manager (C) RuleRule (D)Model Files (B)

Graphical Encapsulation (N)

Graphical Subsystem (O)

Link A Link B

Link DLink E

Link C

Link F

Link GLink H

Link I

Link J

Link K


Basic architecture for conformance checking

UML Editing Tool

Conformance Manager

Graphical Encapsulation

Rule (D)Model Files Rule

Graphical Encapsulation


WBS and Assigned Value

Operating model(10pt)

Client Architecture(45pt)

Server ArchitectureConnection(40pt)

Monitor Console (5pt)

Basic architecture (5pt)

Live session data sync (20pt)

Session management (5pt)

Persistence of session data (5pt)

Basic architecture (5pt)

Whiteboard (15pt)

Poster board integration (15pt)

Playback (5pt)

Session Management (5pt)

Effort distribution


Time spent for each week


Earned Value - semester


Initial Plan for next semester

2007/12/1346Bosch Buzzers - EOSP Fall2007

Review process


Knowledge sharing process


MOSP from Bosch Buzzers (Spring 2008)

Documents

Transcript of MOSP from Bosch Buzzers (Spring 2008)