end of semester presentation 05-07-2004
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 PresentationTRANSCRIPT
Team Dumbledore Spring EOSP
Team Dumbledore:Heng Chen, Myung-Joo Ko, Neel Mullick, Paulo Merson
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
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
4
Team Dumbledore Spring EOSP
What ArchE Does
Requirements Knowledge
Designer Architecture
System•QA scenarios•Functions
Codified as Jess rules
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
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)
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>>
8
Team Dumbledore Spring EOSP
Quality Attribute Elicitation
Most important quality attributes Modifiability Usability Performance
17 QA scenarios
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.
10
Team Dumbledore Spring EOSP
Agenda Team Dumbledore The ArchE System
ArchitectureArchitecture Process Accomplishments and plans Lessons learned
11
Team Dumbledore Spring EOSP
Architecture High-level C&C view
High-level module view
Eclipse plug-in deployment structure
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)
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
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)
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
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.
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
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
19
Team Dumbledore Spring EOSP
Trade-offs
Alternative 1 Alternative 2
Performance +
Data consistency + Unknown
20
Team Dumbledore Spring EOSP
Agenda Team Dumbledore The ArchE System Architecture
ProcessProcess Accomplishments and plans Lessons learned
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
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
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
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
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)
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
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
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
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
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
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
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
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
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.
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
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
37
Team Dumbledore Spring EOSP
Agenda Team Dumbledore The ArchE System Architecture Process
Accomplishments and plansAccomplishments and plans Lessons learned
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)
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
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
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
42
Team Dumbledore Spring EOSP
Agenda Team Dumbledore The ArchE System Architecture Process Accomplishments and plans
Lessons learnedLessons learned
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
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
45
Team Dumbledore Spring EOSP
Questions?
Presentation Complete !!!
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
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
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
49
Team Dumbledore Spring EOSP
Configuration Management
Migration from VSS to Perforce Preparation for summer semester
Website Renewal Improve usability Enhance maintainability
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
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
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
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
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
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