end of semester presentation 05-07-2004

55
Team Dumbledore Spring EOSP Team Dumbledore: Heng Chen, Myung-Joo Ko, Neel Mullick, Paulo Merson End of Semester Presentation 05-07-2004

Upload: umed

Post on 20-Jan-2016

38 views

Category:

Documents


0 download

DESCRIPTION

End of Semester Presentation 05-07-2004. Team Dumbledore: Heng Chen, Myung-Joo Ko, Neel Mullick, Paulo Merson. Agenda. Team Dumbledore The ArchE System Architecture Process Accomplishments and plans Lessons learned. Team Dumbledore. The Team Heng Chen – Team lead, Risk Manager - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: End of Semester Presentation 05-07-2004

Team Dumbledore Spring EOSP

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

End of Semester Presentation

05-07-2004

Page 2: End of Semester Presentation 05-07-2004

2

Team Dumbledore Spring EOSP

Agenda

Team DumbledoreTeam Dumbledore The ArchE System Architecture Process Accomplishments and plans Lessons learned

Page 3: End of Semester Presentation 05-07-2004

3

Team Dumbledore Spring EOSP

Team Dumbledore

The Team Heng Chen – Team lead, Risk Manager Myung-Joo Ko – Configuration Manager, Webmaster Neel Mullick – Client Manager, Process Manager Paulo Merson – Architect, Requirement Manager Alex Berendeyev – Contractor Namrata Malik – Technical Writer

Mentors Anthony Lattanze Ipek Ozkaya

Clients (SEI) Felix Bachmann, Len Bass, Mark Klein

Page 4: End of Semester Presentation 05-07-2004

4

Team Dumbledore Spring EOSP

What ArchE Does

Requirements Knowledge

Designer Architecture

System•QA scenarios•Functions

Codified as Jess rules

Page 5: End of Semester Presentation 05-07-2004

5

Team Dumbledore Spring EOSP

How ArchE Does ItRequirements QA scenarios and functions

refine applying tactics

Goal: find design solution that meets requirements

ModelQA specific

Quantifiablemeasures

specifies

evaluation

Design

Page 6: End of Semester Presentation 05-07-2004

6

Team Dumbledore Spring EOSP

Context Diagram

Rational Rose or

AcmeStudio

Designer

Scenarios, functions, responsibilities, relationships, parameters

Reasoning framework configuration: scenario types, parameter types,relationship types

Facts to the fact base

Exported design

Jess rule engine (ArchE core)Facts from the

fact base

Externalentity Process

Data flow

Key:(This is a context diagram using Gane-Sarson notation; it’s not an architectural diagram; therefore “process” is as defined in [Gane], it’s not a component)

ArchE configurator

Display scenarios, functions, responsibilities, relationships, parameters and model ArchE UI

(Studio project)

Page 7: End of Semester Presentation 05-07-2004

7

Team Dumbledore Spring EOSP

Functional requirementsArchE UI

Designer

CRUD scenarios

CRUD responsibilities

<<include>>

ArchE Corein Jess

Rational Roseor AcmeStudio

Display model

Export design

Interact with ArchE Core<<include>>

<<include>>

<<include>>

Create project

CRUD relationships

CRUD functions <<include>>

Page 8: End of Semester Presentation 05-07-2004

8

Team Dumbledore Spring EOSP

Quality Attribute Elicitation

Most important quality attributes Modifiability Usability Performance

17 QA scenarios

Page 9: End of Semester Presentation 05-07-2004

9

Team Dumbledore Spring EOSP

Quality Attribute Requirements

Examples After some user action, new values are generated by the

model and are available in the rule engine (core); ArchE reads the results and reflects them in all relevant UI views within 500 ms.

The user creates a big system (with ~10000 responsibilities). Time taken to update all UI views after data from the core changes is 500 ms.

A developer familiar with ArchE incorporates a new security reasoning framework to work with ArchE by adapting existing views to security elements, adapting or creating new architectural design representation, defining new scenario types, interact with security rules/facts in Jess, display the security model, within 20 person days.

Page 10: End of Semester Presentation 05-07-2004

10

Team Dumbledore Spring EOSP

Agenda Team Dumbledore The ArchE System

ArchitectureArchitecture Process Accomplishments and plans Lessons learned

Page 11: End of Semester Presentation 05-07-2004

11

Team Dumbledore Spring EOSP

Architecture High-level C&C view

High-level module view

Eclipse plug-in deployment structure

Page 12: End of Semester Presentation 05-07-2004

12

Team Dumbledore Spring EOSP

High-Level C&C view

Eclipse platform

ArchE configurator

Design export

UI views & control

Design tool

exported design

RF configurationnotify data change

Key:Softwarecomponent

External program

Supporting infrastructure

Java method call

File I/O

Comment

Call to Jess

Event send

File

Model solver tool

register views as observer of facts

Register to listen event

RF rules (.clp)

RF configuration

loader

ArchE core bridge

Persisted fact base (.txt)

Jess rule engine (ArchE Core)

Page 13: End of Semester Presentation 05-07-2004

13

Team Dumbledore Spring EOSP

High-Level Module View

SEI.ArchE.UI

<<plugin>>

SEI.ArchE.Lib

<<plugin>>

actions

export

<<interface>>

ExportDesign

ExportToAcme

ExportToRose

corebridgevo

ui

solveModel(tasks[])

RMAModelSolver

Jess Java APIExternal library

Not part of ArchE UI. Will be developed separately by Team Dumbledore for demo.

config

RFConfigLoader

Standard Standard UML UML notationnotation

Page 14: End of Semester Presentation 05-07-2004

14

Team Dumbledore Spring EOSP

Eclipse Plug-in Deployment Structure

org.eclipse.core.resources

org.eclipse.uiSEI.ArchE.Lib

SEI.RMA-RF

SEI.ArchE.UI SEI.ArchE.Configurator

Key:

Eclipse plugin

Extension point

Uses

actionSets

perspectives

popupMenus

views markersnewWizards

reasoningFramework

RF config (.xml)

File pa

File a is packaged in plugin p

RF rules (.clp)

SEI.Modif-RFRF config

(.xml)RF rules

(.clp)

Jess (.jar)

Main rules (.clp)

RMA model solver (.jar)

Modif model solver (.jar)

Page 15: End of Semester Presentation 05-07-2004

15

Team Dumbledore Spring EOSP

ATAM ATAM sessions

2 ATAM sessions led by outside evaluator 7 ATAM sessions done within the team

Usefulness of ATAM Helps evaluating architecture Helps in making architectural decisions Aids future maintainers to understand

architecture decisions

Page 16: End of Semester Presentation 05-07-2004

16

Team Dumbledore Spring EOSP

Architecture Analysis

Performance/scalability scenarios:

After some user action, new values are generated by the model and are available in the rule engine (core); ArchE reads the results and reflects them in all relevant UI views within 500 ms.

The user creates a big system (with ~10000 responsibilities). Time taken to update all UI views after data from the core changes is 500 ms.

Page 17: End of Semester Presentation 05-07-2004

17

Team Dumbledore Spring EOSP

Alternative 1

Cache fact base andrefresh after every change

Eclipse platform

UI views & controls

ArchE core bridge

views and editors

user cmd notify data

change (to

refresh UI)

Ec

lipse

UI e

ven

t m

anag

erArchE core

façade

Fact base in memory

set

handle user cmd

Jess rule engine (ArchE Core)

Key:Action handler

UI screenevent manager(part of Eclipse platform)

Java method call event send

event receive

software component

External program

plugin.xml in SEI.ArchE.UI

Register action handlers that will listen to views

xml file

dialog boxes

create/update/delete element

“ArchE

think”

Design export

Design tool

exported design

Supporting infrastructureFile I/O

Call to Jess AB is a sub-module of A

B

register views as

observer of facts

register to listen event

action handlers

Page 18: End of Semester Presentation 05-07-2004

18

Team Dumbledore Spring EOSP

Alternative 2

Access facts directly in the coreJess notifies changes

Eclipse platform

UI views & controls

ArchE core bridge

views and editors

user cmdnotify data change

(to refresh UI)

Ec

lipse

UI e

ven

t m

anag

erArchE core

façade

ArchE core listener

handle user cmd

Key:Action handler

UI screenevent manager(part of Eclipse platform)

Java method call event send

event receive

software component

External program

plugin.xml in SEI.ArchE.UI

Register action handlers that will listen to views

xml file

dialog boxes

create/update/delete element

“ArchE

think”

Design export

Design tool

exported design

Supporting infrastructureFile I/O

Call to Jess AB is a sub-module of A

B

register views as

listeners

register to listen event

action handlers

register to fact

changes

read

fa

cts

Jess rule engine (ArchE Core)

notify fact

change

Page 19: End of Semester Presentation 05-07-2004

19

Team Dumbledore Spring EOSP

Trade-offs

Alternative 1 Alternative 2

Performance +

Data consistency + Unknown

Page 20: End of Semester Presentation 05-07-2004

20

Team Dumbledore Spring EOSP

Agenda Team Dumbledore The ArchE System Architecture

ProcessProcess Accomplishments and plans Lessons learned

Page 21: End of Semester Presentation 05-07-2004

21

Team Dumbledore Spring EOSP

ACDM (Architecture-Centric Development Method)

It suits studio projectsLightweightSmall teamsShort development cycles

It addresses risks at the architecture levelArchE itself is about architectureClients are architecture-focusedAuthor is one of our mentors

Page 22: End of Semester Presentation 05-07-2004

22

Team Dumbledore Spring EOSP

ACDM (Architecture-Centric Development Method)

Artifact

Activity

Decision

Next step

Produces

Legend:

Functional rqmts/constraintsPaper prototypes

Discover quality attribs.Create utility tree 1

Prioritized utility treeInitial project plan Create notional

architecture 2Architecture viewsUpdated project plan

Review architectureAnalyze scenarios 3

Risks, tradeoffs

Ready to design& code?

Evaluate risks/tradeoffsCreate experiment plan 4

Experiment planUpdated project plan

Execute experimentsRevisit architecture 5

Refined architectureUpdated project plan

Create designWrite test code/write code/review code 6

Detailed designTest codeSource code

Deploy/integrateor iterate 7

Discuss UI functions w/clients 3’

UI detailedstories

Yes

No

Page 23: End of Semester Presentation 05-07-2004

23

Team Dumbledore Spring EOSP

ACDM (Architecture-Centric Development Method) Technical experiments

Eclipse platform

ArchE configurator

Design export

UI views & control

Design tool

exported design

RF configurationnotify data change

Key:Softwarecomponent

External program

Supporting infrastructure

Java method call

File I/O

Comment

Call to Jess

Event send

File

Model solver tool

register views as observer of facts

Register to listen event

RF rules (.clp)

RF configuration

loader

ArchE core bridge

Persisted fact base (.txt)

Jess rule engine (ArchE Core)

High-Level C&C view

Neel

Henry

Paulo

Myung

Page 24: End of Semester Presentation 05-07-2004

24

Team Dumbledore Spring EOSP

Paulo : Eclipse Plug-in Development Did training session & developed UI codes

Neel : Jess Rule Engine Did training session

Myung : Design Export to Rose Developed codes creating xmi readable by Rose

Henry : Java RMA Model Solver Developed & delivered codes to clients

Experiment plan Current status

ACDM (Architecture-Centric Development Method) Technical experiments

Page 25: End of Semester Presentation 05-07-2004

25

Team Dumbledore Spring EOSP

Lessons learned Conducting two hour workshop for architecture

every week helped us a lot Carrying out technical experiments was a good

mitigation strategy for technical risks Following ACDM for design phase was a good

decision Next steps

Finish technical experiments Create detailed design Code ArchE1

ACDM (Architecture-Centric Development Method)

Page 26: End of Semester Presentation 05-07-2004

26

Team Dumbledore Spring EOSP

Requirement Management

Identified Prototyped

Story draftedStory

reviewed by clients

Story agreed upon

Screen implemented

Prototype reviewed by

clients

Implementation reviewed by

clients

Note: “story” is the UI detailed story

Test cases created

Workflow of UI prototypes

Review & Verification

UI Paper Prototypes

Tracking & Update

UI Detailed Stories

Summer semester

Fall semester

Spring semester

Page 27: End of Semester Presentation 05-07-2004

27

Team Dumbledore Spring EOSP

Requirement Management

1

2

3 4

5 6

7

9

8

10

12

14

11

13

15 16 17 18 19

20

ExampleNo Events Responses

2 PageLoad Show all possible values of scenario types associated with active Reasoning Frameworks.

OptionSelected • Case1: If the user selects “unknown”, show all the possible types of options in the six parts.

• Case2: If the user selects not “unknown”, show specific values based on the scenario type in each field of six parts.

• Case 3: When no scenario type is selected, user might choose two six part types which belong to different scenario type. ArchE will show this inconsistency in the dialog box. If one or more of the six part option is selected and the user selects a scenario type(not “unknown”),and if the selected scenario type is not consistent with the 6 parts options, then open a message box “Scenario Type is not consistent with <part> option”.

Example:1) Scenario type is “unknown”.2) User selects “periodic” as the option for stimulus. 3) User selects “cost of modification” for response option4) User selects “deadline” on the scenario type.5) ArchE shows error msg on inconsistency between response and scenario type

Review & Verification

UI Paper Prototypes

Tracking & Update

UI Detailed Stories

Page 28: End of Semester Presentation 05-07-2004

28

Team Dumbledore Spring EOSP

Learned from “Methods of Software Development” course

Purpose Elicit functional requirements Define the structure of UI Define and verify usability requirements

Created the prototype of all key screens Out of 21 screens, 12 screens were selected and

created

Requirement ManagementUI Detailed Stories

Review & Verification

UI Paper Prototypes

Tracking & Update

Page 29: End of Semester Presentation 05-07-2004

29

Team Dumbledore Spring EOSP

Requirement Management

Inspired by Extreme Programming “user stories”

Purpose Complement the UI paper prototypes

UI prototypes and detailed stories Guided creation of test cases Will be a basis for implementing screens

Review & Verification

UI Paper Prototypes

Tracking & Update

UI Detailed Stories

Page 30: End of Semester Presentation 05-07-2004

30

Team Dumbledore Spring EOSP

Requirement ManagementReview & Verification

UI Paper Prototypes

Tracking & Update

UI Detailed Stories

Reviewed by Requirement Manager

Verified by clients Weekly client meeting every Friday 3:00–5:00 pm

Page 31: End of Semester Presentation 05-07-2004

31

Team Dumbledore Spring EOSP

Requirement ManagementReview &

VerificationUI Paper

PrototypesTracking & Update

UI Detailed Stories

Manage status of UI detailed stories Identified Story reviewed by clients Story agreed upon

When requirements are changed Update UI paper prototypes and UI detailed

stories Update UI status list in SRS Reviewed by the team

Use Case

UI Screen Screen Type Status Owner Comment

Create project

1.New ArchE Project Dialog box[1] Story agreed upon

Paulo Main menu option: File | New | Project

1.Navigator Standard Eclipse navigator view

Story agreed upon

Paulo

CRUD scenarios

1.Scenarios Table view Story agreed upon

Neel

1.Scenarios – static filter Dialog box Identified

1.Scenario Dialog box Story agreed upon

Myung

1.Scenario Responsibility Mapping

Table view Story agreed upon

Myung

Page 32: End of Semester Presentation 05-07-2004

32

Team Dumbledore Spring EOSP

Lessons learned UI paper prototypes were good media for

communication with clients Weekly client meeting really helped

Next steps Review stories of 3 remaining screens Freeze UIs of ArchE1

Requirement ManagementReview &

VerificationUI Prototypes Tracking & Update

UI Detailed Stories

Page 33: End of Semester Presentation 05-07-2004

33

Team Dumbledore Spring EOSP

SRE (Software Risk Evaluation)

Mini-SRE (Software Risk Evaluation) with Ray Williams

Picture of Success Conditions and consequences of risks Questionnaire on team process

Mini-SRE Tracking & Update

Top 5 risks & Mitigation plan

Page 34: End of Semester Presentation 05-07-2004

34

Team Dumbledore Spring EOSP

SRE (Software Risk Evaluation)

Description Mitigation plan

1We don’t have historical data about the productivity of the team; Might underestimate time required to do development.

Individual time tracking to gather more information of team productivity.

2

ArchE has to interact with JESS and we don’t know what it will take to make that work; we might not make the JESS experiment work by April 30.

Neel will talk to the Felix to discover the issues of ArchE’s interfacing with JESS; Keep progressing on JESS technical prototyping.

2

ArchE was to interact ACME studio or Rational Rose and We don’t know what it will take to make either one; Might not get either to work by April 30.

The team should choose only one to implement in this stage. Myung has already done many researches on Rational Rose and we should persuade the client to agree.

2

ArchE core is still evolving and we need a stable core for our design; Could result in failure or a lot of rework at the end.

This issue has already been brought up in a client meeting and the need for an intermediate data store has been realized and agreed upon as a means to mitigate this risk.

5

ArchE will be developed as Eclipse plug-ins and the team is not familiar with Eclipse plug-in development; we might not have tabular views with dynamic filters and dialog boxes in the Eclipse experiment by May 5

The technical prototyping and training should carry on. Everybody in the team should be familiar with the plug-in development environment.

Mini-SRETop 5 risks & Mitigation

plan

Tracking & Update

Rank

5

ArchE will be developed as Eclipse plug-ins and the team is not familiar with Eclipse plug-in development; we might not have tabular views with dynamic filters and dialog boxes in the Eclipse experiment by May 5

The technical prototyping and training should carry on. Everybody in the team should be familiar with the plug-in development environment.

Page 35: End of Semester Presentation 05-07-2004

35

Team Dumbledore Spring EOSP

SRE (Software Risk Evaluation)Mini-SRE Top 5 risks

& Mitigation plan

Tracking & Update

Team Lead managed the top 10 risk list Revisited during the team meetings

When a risk needs to be changed Reprioritize risks within the team Update top 10 risk list & website

Page 36: End of Semester Presentation 05-07-2004

36

Team Dumbledore Spring EOSP

SRE (Software Risk Evaluation)Mini-SRE Top 5 risks

& MitigationPlan

Tracking & Update

Lessons learned Could be done earlier Formulated risks with conditions and consequences Picture of success is food for thought

Next step Keep monitoring

Page 37: End of Semester Presentation 05-07-2004

37

Team Dumbledore Spring EOSP

Agenda Team Dumbledore The ArchE System Architecture Process

Accomplishments and plansAccomplishments and plans Lessons learned

Page 38: End of Semester Presentation 05-07-2004

38

Team Dumbledore Spring EOSP

Progress - This SemesterFebFeb

AprilApril

3

MayMay

SOWSOW

MarchMarch1

1920

27

SPMP with SRE (MOSP deliverable)SPMP with SRE (MOSP deliverable)

SRS v2.0 (MOSP deliverable)SRS v2.0 (MOSP deliverable)UI paper prototypeUI paper prototype

Migration from VSS to PerforceMigration from VSS to Perforce

UI Detailed stories (Phase I)UI Detailed stories (Phase I)

Test Plan v1.0Test Plan v1.0SRS v2.1SRS v2.1

16

1920

Technical Experiment (Model Solver)Technical Experiment (Model Solver)22

2526

Technical Experiment (Export Design)Technical Experiment (Export Design)New website launchedNew website launched

Technical Experiment (JESS)Technical Experiment (JESS)123

7

Technical Experiment (Eclipse plug-in)Technical Experiment (Eclipse plug-in)Architecture documentationArchitecture documentation

UI Detailed stories (Phase II)UI Detailed stories (Phase II)

Page 39: End of Semester Presentation 05-07-2004

39

Team Dumbledore Spring EOSP

Iterations

Each iteration will be a deployable unit One cycle = detailed design + development

planning + development + unit testing + integration testing activities

Development Plan

ArchE1 Navigator View, Scenarios View, Scenario Dialog Box, Questions to User Dialog Box, Problems View, Structure of RF plug-ins (including RF configuration)

ArchE2 Responsibilities View, Scenario Responsibility Mapping View, Relationships  View, Export Design to Rose

ArchE3 Static Filters, Functions View, Function Responsibility Mapping View, Display Model elements, Display Model relations

Page 40: End of Semester Presentation 05-07-2004

40

Team Dumbledore Spring EOSP

Test Plan For functional requirements

Test cases that trace back to the UI detailed stories

Integration testing for each iteration For quality attributes

Focus on performance (response time) during technical experiments

Architectural review

Page 41: End of Semester Presentation 05-07-2004

41

Team Dumbledore Spring EOSP

Test Plan

AprilApril

MayMay

14

19

22

29

JuneJune

5

17

7

Test cases related to UI storiesTest cases related to UI stories

Architectural Architectural reviewreview

Integration testing for ArchE1Integration testing for ArchE1

Unit testing for ArchE1Unit testing for ArchE1

Integration test cases for ArchE1Integration test cases for ArchE1

Performance Performance testingtestingFinal test cases for ArchE1Final test cases for ArchE1

NOWNOW

3

Page 42: End of Semester Presentation 05-07-2004

42

Team Dumbledore Spring EOSP

Agenda Team Dumbledore The ArchE System Architecture Process Accomplishments and plans

Lessons learnedLessons learned

Page 43: End of Semester Presentation 05-07-2004

43

Team Dumbledore Spring EOSP

What is Good So Far Sound architecture produced UI prototypes and detailed stories process

Weekly meeting with clients Tracking progress Freezing specification after client’s agreement

Technical experiments Planned in fall; initiated at the beginning of

spring Helped defining the architecture Mitigated technical risks

Successful migration from VSS to Perforce Better client interaction Continuous risk management

Page 44: End of Semester Presentation 05-07-2004

44

Team Dumbledore Spring EOSP

What Could Go Better

Technical experiments Should have studied ArchE core earlier

Subcontracting issues Follow a process for subcontractor management Should schedule the interaction based on his need

Earlier Estimation Would help define the scope of the functions Could be better if we did it when we built UI stories

Page 45: End of Semester Presentation 05-07-2004

45

Team Dumbledore Spring EOSP

Questions?

Presentation Complete !!!

Page 46: End of Semester Presentation 05-07-2004

46

Team Dumbledore Spring EOSP

Requirement Management

1

2

3 4

5 6

7

9

8

10

12

14

11

13

15 16 17 18 19

20

Example

Review & VerificationUI Prototypes Tracking &

UpdateUI Detailed

Stories

Page 47: End of Semester Presentation 05-07-2004

47

Team Dumbledore Spring EOSP

Requirement ManagementReview &

VerificationUI Paper

PrototypesTracking & Update

UI Detailed Stories

Manage status of UI detailed stories Identified Story reviewed by clients Story agreed upon

When requirements are changed Update UI paper prototypes and UI detailed

stories Update UI status list in SRS Reviewed by the team

Page 48: End of Semester Presentation 05-07-2004

48

Team Dumbledore Spring EOSP

SRE (Software Risk Evaluation)

Description Mitigation plan

1We don’t have historical data about the productivity of the team; Might underestimate time required to do development.

Individual time tracking to gather more information of team productivity.

2

ArchE has to interact with JESS and we don’t know what it will take to make that work; we might not make the JESS experiment work by April 30.

Neel will talk to the Felix to discover the issues of ArchE’s interfacing with JESS; Keep progressing on JESS technical prototyping.

2

ArchE was to interact ACME studio or Rational Rose and We don’t know what it will take to make either one; Might not get either to work by April 30.

The team should choose only one to implement in this stage. Myung has already done many researches on Rational Rose and we should persuade the client to agree.

2

ArchE core is still evolving and we need a stable core for our design; Could result in failure or a lot of rework at the end.

This issue has already been brought up in a client meeting and the need for an intermediate data store has been realized and agreed upon as a means to mitigate this risk.

5

ArchE will be developed as Eclipse plug-ins and the team is not familiar with Eclipse plug-in development; we might not have tabular views with dynamic filters and dialog boxes in the Eclipse experiment by May 5

The technical prototyping and training should carry on. Everybody in the team should be familiar with the plug-in development environment.

Mini-SRETop 5 risks & Mitigation

plan

Tracking & Update

Rank

Page 49: End of Semester Presentation 05-07-2004

49

Team Dumbledore Spring EOSP

Configuration Management

Migration from VSS to Perforce Preparation for summer semester

Website Renewal Improve usability Enhance maintainability

Page 50: End of Semester Presentation 05-07-2004

50

Team Dumbledore Spring EOSP

One subcontractor MSIT student Responsible for building ArchE Configurator

Lessons learned Passive interaction with subcontractor Not enough time to communicate with subcontractor

Next steps Major tasks that require interaction with the team

Functional requirements QA requirements Structure of RF configuration file Discussion of communication process

Examine post-mortem of teams that used contractors in the past

Software Subcontract Management

Page 51: End of Semester Presentation 05-07-2004

51

Team Dumbledore Spring EOSP

Quality Assurance Team review

Documents Architecture documentation Test plan SRS

All team members More constructive comments

Peer review Review process: one reviewer per team

member Reduce flaws Efficient

Page 52: End of Semester Presentation 05-07-2004

52

Team Dumbledore Spring EOSP

1We don’t have historical data about the productivity of the team; Might underestimate time required to do development.

2ArchE has to interact with JESS and we don’t know what it will take to make that work; we might not make the JESS experiment work by April 30.

2ArchE was to interact ACME studio or Rational Rose and We don’t know what it will take to make either one; Might not get either to work by April 30.

2ArchE core is still evolving and we need a stable core for our design; Could result in failure or a lot of rework at the end.

5ArchE will be developed as Eclipse plug-ins and the team is not familiar with Eclipse plug-in development; we might not have tabular views with dynamic filters and dialog boxes in the Eclipse experiment by May 5

6We don’t agree on what development model were using; We might not define good milestones for next semester, or meet them.

7We are not adequately tracking progress VS. plans; Miss milestones, unperceived schedule slips

8

We need to transfer the knowledge (especially Eclipse plug-in) among the team members; We might not be able to transfer enough knowledge before development, thus making the development more difficult or lowers productivity.

9 We don’t yet have a QA plan; If we don’t have one by May we Might start producing defective code

10We have a requirement to work with larger amounts of data without degrading response time; Might be unable to meet this requirement

Top 10 Risks

Page 53: End of Semester Presentation 05-07-2004

53

Team Dumbledore Spring EOSP

Rank Mitigation planPeople in

Charge

1 Individual time tracking to gather more information of team productivity. Team

2Neel will talk to the Felix to discover the issues of ArchE’s interfacing with JESS; Keep progressing

on JESS technical prototyping. Neel

2The team should choose only one to implement in this stage. Myung has already done many

researches on Rational Rose and we should persuade the client to agree. Myung

2This issue has already been brought up in a client meeting and the need for an intermediate data

store has been realized and agreed upon as a means to mitigate this risk. Team

5The technical prototyping and training should carry on. Everybody in the team should be familiar

with the plug-in development environment. Paulo

6 We need to come up with a high level development plan by the end of this semester Neel

7 Making more detailed plan and tracking the progress on every Wednesday meeting Henry

8We need to think about how to use the limited time to transfer as much as possible. This requires

each meeting be well prepared and efficient for everybody. Team

9 We need to seek mentors help to make a reasonable QA plan by the end of this semester Henry

10We need to think about this within this semester by bring this to the client and doing technical

experiment. Neel

Risk Mitigation Plan

Page 54: End of Semester Presentation 05-07-2004

54

Team Dumbledore Spring EOSP

SRE (Software Risk Evaluation)

Description Mitigation plan

1We don’t have historical data about the productivity of the team; Might underestimate time required to do development.

Individual time tracking to gather more information of team productivity.

Team

2

ArchE has to interact with JESS and we don’t know what it will take to make that work; we might not make the JESS experiment work by April 30.

Neel will talk to the Felix to discover the issues of ArchE’s interfacing with JESS; Keep progressing on JESS technical prototyping.

Neel

2

ArchE was to interact ACME studio or Rational Rose and We don’t know what it will take to make either one; Might not get either to work by April 30.

The team should choose only one to implement in this stage. Myung has already done many researches on Rational Rose and we should persuade the client to agree.

Myung

2

ArchE core is still evolving and we need a stable core for our design; Could result in failure or a lot of rework at the end.

This issue has already been brought up in a client meeting and the need for an intermediate data store has been realized and agreed upon as a means to mitigate this risk.

Team

5

ArchE will be developed as Eclipse plug-ins and the team is not familiar with Eclipse plug-in development; we might not have tabular views with dynamic filters and dialog boxes in the Eclipse experiment by May 5

The technical prototyping and training should carry on. Everybody in the team should be familiar with the plug-in development environment.

Paulo

Picture of Success

Top 5 risks & Mitigation

plan

Tracking & Update

Rank People in Charge

Page 55: End of Semester Presentation 05-07-2004

55

Team Dumbledore Spring EOSP

SRE (Software Risk Evaluation)

Minimum success of team Dumbledore

ArchE meet at least the “minimal deliverable requirements” stated in SOW. 

The client is satisfied with ArchE and going to use it or continue to improve it.

Eventually we find out a suitable process which we might want to repeat it in the future.

All team members at the end believe that they have improved their personal and team skills.

All team members at the end believe that they have improved the technical skills in at least one of the following: Java programming, Eclipse plug-in development, Java API to Jess.

The cooperation after this year turns out be a nice memory for all team members.

Picture of Success

Tracking & Update

Top 5 risks & Mitigation plan