THE REFLECTIONS OF COMENIUS PROJECT IN PRIVATE OZCAN PRIMARY SCHOOL
1 By Go5 Team A - PLUS 1. 2 Project Overview Process Project Management Reflections Demo Agenda 2.
-
Upload
john-higgins -
Category
Documents
-
view
215 -
download
0
Transcript of 1 By Go5 Team A - PLUS 1. 2 Project Overview Process Project Management Reflections Demo Agenda 2.
4
USABILITY SUPPORTING
ARCHITECTURAL PATTERN
•Identify architecturally sensitive usability
scenarios•Identify responsibilities that should be addressed
by the architecture to satisfy the usability
scenarios
•Identify architecturally sensitive usability
scenarios•Identify responsibilities that should be addressed
by the architecture to satisfy the usability
scenarios
4
System Architecture
Usability of the system
Project Background Overview Process Project Management Reflections Demo
5
5
Business Problem
We are going to address the usability
concerns that are architecturally
sensitive
We can achieve this through USAPs which
enable the architects to evaluate their
architecture
No Persistence of data
Poor UI
Lack of provision for selecting the
applicable USAPs
Overview Process Project Management Reflections Demo
6
6
• A- PLUS, a web based tool
• Built using a Content Management System, Drupal
How A-PLUS addresses these issues?
• Persistence of data through USAP database
• Rich and interactive User Interface
• An interface to select applicable USAPs which relieves the architect from going through the entire list
• An aid to evaluate architecture against usability concerns
A-PLUS Overview Process Project Management Reflections Demo
7
System Context
Authoring
A-PLUS Architect
A-PLUS Requirements
Filter and CombineUSAP Author
Software Architect Evaluate Architecture
Feed USAPs
Components
Database
Overview Process Project Management Reflections Demo
System EnvironmentLegend
7
Data flow
User interactionUsers Database
8
• Deliver all the must-have features (validated and
accepted) to the client by the end of Spring, 2009
• Learn and apply risk management techniques that are new to the team.
• Learn and apply planning and tracking techniques effectively
Goals
8
Overview Process Project Management Reflections Demo
10
Go5 Process
Negotiated Scope
Client’s Priorities
Team’s Estimates
Design Code
Test
Client Acceptance
Plan
PM Risk
Architecture
Weekly Deliverable List
Scen
ario
Lis
t
Overview Process Project Management Reflections Demo
12
Estimation - Specialization based estimation
Tracking - Earned Value Tracking
Highlights:
• ETVX
• Breaking up of tasks longer than 8 hours
• Setting Triggers
• Check Schedule Performance Index (SPI) every week. Take appropriate action 12
Project Management Overview Process Project Management Reflections Demo
13
13
Spring Semester - Progress
Implement ‘Filter and Combine’
Implement ‘Filter and Combine’
Spring 2009JanuaryJanuary FebruaryFebruary MarchMarch AprilApril
ImplementationImplement ‘A-PLUS Architect’Implement ‘A-PLUS Architect’
Testing Test ‘A-PLUS Architect’Test ‘A-PLUS Architect’
Design Revisit ‘Database Design’
Revisit ‘Database Design’
Model of ‘Filter and Combine’
Model of ‘Filter and Combine’
ArchitectureRevisit
ArchitectureRevisit
Architecture
Process &Project
Management
Revisit RiskRevisit Risk
Planning, Scheduling and Earned Value TrackingPlanning, Scheduling and Earned Value Tracking
Revisit RiskRevisit Risk
Test ‘Filter and Combine’
Test ‘Filter and Combine’
Model of ‘A-PLUS
Requirements’
Model of ‘A-PLUS
Requirements’
Implement ‘Authoring Module’
Implement ‘Authoring Module’
Test ‘A-PLUS Requirements’Test ‘A-PLUS Requirements’
Revisit Architecture
Revisit Architecture
Revisit Architecture
Revisit Architecture
Revisit RiskRevisit Risk
Test Database
Test Database
Implement ‘A-PLUS Requirements’Implement ‘A-PLUS Requirements’
Test ‘Authoring Module’
Test ‘Authoring Module’
Model of ‘Authoring
Module’
Model of ‘Authoring
Module’
13
Integration testingIntegration testing
• Unit testing, Integration testing, UAT
• Help from other experts
• Traceability Matrix
• Self and Peer reviews
• Setting up coding standards
• ETVX for every task
Quality Assurance
16
Overview Process Project Management Reflections Demo
17
Risk Management Process
If trigger doesn’t get activated
Risk Identification using SRE
Risk prioritization through multi-voting Mitigation Strategy for
1.Reducing impact2.Eliminating condition3.Reducing probability4.Extending time frame
Choose a mitigation strategy and set up triggers (deadlines)
See if the exit criteria is met
Choose another mitigation strategy
Risk is mitigated
If trigger is activated
Overview Process Project Management Reflections Demo
If exit criteria is not met
19
Reflections…
Things that went well
• Scope Negotiation
• ETVX was defined for every task and dependencies between tasks were identified
• Risk Management was done effectively
• EV tracking gave good insights into tracking and estimation
• Team cohesion
• Issue Tracker
• Minutes Of Meeting - Client
• Disciplined common hours and daily status meeting
Overview Process Project Management Reflections Demo
19
20
Reflections
Scope for improvement
• Testing – Testing with extensive data could have been done earlier
– Compatibility testing in browsers and testing in MAC OS were not smooth
• Configuration control – Crash & Recovery
• Specializations of resources -> Peer reviews not effective
• Individuals productivity was not tracked
Overview Process Project Management Reflections Demo
20
21
Deliver all the must-have features (validated and
accepted) to the client by the end of Spring, 2009 Client acceptance Understood USAP domain Learned Drupal
Learn and apply risk management techniques that are new to the team Risks gradually decreased and finally all risks were mitigated
Learn and apply planning and tracking techniques effectively Schedule Performance Index was mostly lying between 0.95 to 1.05
Goals Overview Process Project Management Reflections Demo
21
22
Learning by Doing
Course Techniques most useful in our project
MSD General project management, Process – Agile Methodologies, Estimation, Planning & Tracking (EV), Client management, Risk management
Methods Requirements gathering as Use cases, User Scenarios
Architecture Quality attributes, Architectural Styles, Tactics, Design decisions and tradeoffs
Analysis of Artifacts
Peer reviews, Unit testing, Integration testing, Acceptance testing
Overview Process Project Management Reflections Demo
22
23
Client’s Feedback
23
I AM THRILLED. I asked something to be done and it was done yesterday.
Better than a lot of professional teams I have worked with. You guys have great attitude and attitude matters ! PROCESS WISE TEAM PROGRESSED REALLY WELL
GREAT STUFF EXCELLENT, but could have followed better configuration control
Overview Process Project Management Reflections Demo
24
24
Mentor’s Feedback
ONE OF THE BEST TEAMS I HAVE MENTORED. Customer focus is really good. Team cohesion is great.
Overview Process Project Management Reflections Demo
30
• USAP contains– A brief scenario that describes the usability problem
– Conditions under which usability problem description applies
– Responsibilities necessary to implement a solution
– Rationale for these responsibilities
• USAPs are documented using Architecture Pattern Language in the USAP Document
• Helps the architects to evaluate a system’s architecture based on usability concerns
Usability Supporting Architecture Pattern Overview Process Project Management Reflections Demo
30
32
Business Problem
CURRENT SCENARIO PROBLEM SOLUTION
USAP information is hardcoded in the prototype
Process is tedious
No Persistence of data
Provide interface for the USAP author’s to enter data
Provide a common repository
No provision for choosing the USAP’s that are applicable to a project Architects are evaluating the system’s architecture using the prototype
Have to go through the entire list of USAPs to answer the relevant questions
Poor UI
No filtered view of the responsibilities
Provide an interface for selecting the USAP’s
Rich UI which makes the research more usable
Provide a way for filtering of responsibilities
Overview Process Project Management Reflections Demo
32
33
• Drawbacks of the prototype used by the client– Hard-coding of USAPs
– No persistence
– Poor UI Specification
– Lack of provision for selecting applicable USAPs
• Client’s testing of with architects in the real world(PUT cartoon)
33
Business Problem
34
Project Management
Planning Process
• Based on deliverable list and the client’s priorities, the team identifies the scenarios to be delivered in a week.
• A scenario is broken down into sub tasks (output is the creation of a WBS). ETVX is defined for each task.
• Tasks are estimated based on specialization.
• Triggers are defined for tasks that attribute to risks in the project.
Overview Process Project Management Reflections Demo
34
35
No Observations Inference Decisions
1 Actual Cost > PV Team has put in more effort but gaining only less value
Need to revisit the estimates.
2 Actual Cost > EV and EV < PV
We put in more effort but the task is not done
There were tasks which had earned value hours greater than 8
Break the tasks down so that we can track better. Do not allow tasks as huge as 8 or more
3 EV increases much greater than the Actual Cost
We have overestimated some tasks
Analyze why it was estimated to be so high
Revisit Estimation of similar type of tasks
`4 Team was lagging by about 60 to 70 earned
value hours
Team cannot meet the scope at the end of the project
Negotiate the scope with the client or find alternate solutions
to address the same problem
5 Actual Cost > PV and EV Deployment server configurations and testing took the team more
effort than expected
Do not postpone the deployment testing towards the end of the
project
Earned Value Chart
Business DriversQuality Attribute Scenarios Priority
Reliability If the system loses information, the loss of data should not be more than one responsibility
(H, H)
Maintainability Bonnie should be able to implement a change in the user interface such as adding an extra checkbox or an area to specify some text within a day
(H, M)
UsabilityUndo for the text editing should be done within one second. There is no undo necessary for things like radio buttons and check boxes
(M, L)
The system must be able to give a filtered view of the responsibility list based on the options selected
(H, H)
Browser Compatibility All the functionalities of the system should work according to their specification with regard to the browsers Firefox 3.0, Internet Explorer 6.0 and Safari 3.0
(H, H)
38
Architecture – CC View
APLUS DATABASE
APLUS
Legend
Components
Connectors
Call Return Conn
Data Access
PortUse port
Provide port
Output portInput port
APLUS RequirementsAPLUS Architect
Filter and Combine
APLUS Authoring
Drupal Core
38
APLUS
Drupal Core
Database
Custom modules
39
Drupal module
A B A uses B
3rd party Package
Module File & CSS Files
BA
Legend
Filter and Combine
F&C Module file
APLUS Database
DB Module file
APLUS Requirements
Requirements Module file
CSS File
Aplus Architect
Architect Module file
CSS File
Authoring
Authoring Module file
JS Files
Themes
Architecture – Module View
A contains B
Scenario AnalysisReliability
If the system loses information, the loss of data should not be more than one responsibility (Priority – High)
Architectural Decisions Trade Off
For every responsibility evaluated, use asynchronous calls to update the
database on the current evaluation status
Reliability (+)Usability(+) Performance(-)
For every responsibility evaluated, save the data to the database and reload the
page.
Reliability (+)Performance(-) Usability(-)
Scenario Analysis
Usability The system must be able to give a filtered view of the responsibility list based on the options
selected(Priority- High)
Architectural Decisions Trade Off
For every responsibility evaluated, get their applicability and filter it using client side with progress feedback and without page
refresh by using asynchronous calls
Usability(+) Performance(-)
For every responsibility evaluated, reload the entire responsibility list by interacting with
server side and refresh the page.
Usability(-) Performance(+)
Requirements
Existing Prototype
Use case Scenarios
SRS Sign off
UI Specification
New scenarios
were added
Scope Negotiation
Fall 08 Spring 09
43
Overview Process Project Management Reflections Demo
ETVX
Entry Criteria Task Exit Criteria
Functional requirements
Requirements Software Requirement Specifications
Requirement for that module
Modeling Model validated by the client
Functional and Non Functional
requirements
Architecture Views of the Architecture
Model for the modules
Coding Code
Code Testing Acceptance test from the client
44
45
RequirementsLevel 1 ID Description Priority
Document Parser
SR6 Parse USAP document and persist them in the database High
Delivery ToolSR1 The system shall register a project for setting up the project. High
SR2 The system shall register a project group which would consist of one or more projects.
Low
SR3 The system shall view the project information from the existing project list. Medium
FR 3.2.1 Authorization of the users HighFR 3.2.2 Choosing a project to evaluate its architecture HighFR 3.2.3 Choosing a set of end user USAPs that are relevant to the project High
FR 3.2.4 Displaying all the responsibilities based on the selected USAP’s High
FR 3.2.5 Scrolling and hiding all the responsibilities which have been considered High
FR 3.2.6 Recording all the information regarding architecture evaluation High
FR 3.2.7 Viewing of responsibilities based on grouping options HighFR 3.2.8 Generating a to-do list based on evaluation of architecture High
FR 3.2.9 Error message explicitly dismissed MediumFR 3.2.10 Shortcut keys LowFR 3.2.11 Progress Feedback MediumFR 3.2.12 Change size of display text MediumFR 3.2.13 Supporting different views Medium
45
46
Prioritization stack
Prioritization stack
Integration and Acceptance testing
Document the model
Detailed Modeling
Implement
Modeling for the next high priority
feature
Iteration 1..N
Get the model validated by
the client
Refine the Architecture if
needed
Review and Rework if any
Legend
Starting Point
Go5 Development Process - Fall
46
47
Requirements envisioning
Requirements envisioning
Prioritization of requirements
Prioritization of requirements
Technology AnalysisTechnology Analysis
Go5 Process ..(2)
Iteration – 0 High level requirements from Client
High level requirements from Client
Use Case AnalysisUse Case Analysis
Review by ClientReview by Client
User Prototype TestingUser Prototype Testing
Refinement of Use Cases
Refinement of Use Cases
Overview Process Project Management Accomplishments Reflections Plan for Spring
47
48
Modeling high priority requirement
Modeling high priority requirement
Review of model by the client
Review of model by the client
Implement the requirement
Implement the requirement
Acceptance testingAcceptance testing
Unit testing Unit testing
Integrate with existing code structure and subsequent testing
Integrate with existing code structure and subsequent testing
Architecture Envisioning and Refinement
Architecture Envisioning and Refinement
Go5 Process ..(3)
Iteration – 1..N
Overview Process Project Management Accomplishments Reflections Plan for Spring
48
51
Problem DescriptionProblem Description
Entity Relationship Diagram
Entity Relationship Diagram
Database SchemaDatabase Schema
Database Design Process
Review from clientsReview from clients
Implementation of database
Implementation of database
Overview Process Project Management Accomplishments Reflections Plan for Spring
51
55
Quality Attribute ScenariosPriority
Maintainability Bonnie should be able to implement a change in the user interface such as adding an extra checkbox or an area to
specify some text within a day
(H, M)
Reliability The system should not lose any information that is not part of the session information. Losing the session data is
acceptable by the user. If the system loses information ,the loss of data should not be more than one responsibility
(H, H)
UsabilityUndo for the text editing should be done within one second. There is no undo necessary for things like radio buttons and
check boxes
(M, L)
Cancel Operation should be able to be done by the user at any point prior to the completion of the command. The
system should be reset to the extent possible to its state prior to the issuance of the command
(M,M)
Browser Compatibility All the functionalities of the system should work according to their specification with regard to the browsers Firefox 3.0,
Internet Explorer 6.0 and Safari 3.0
(H, H)
Utility Tree
55
56
Page Name Module Hooks
USAP uploadDocument Parser TBD
Login Login TBD
End-User USAP Selection
Evaluate Architecture hook_auth, hook_validate, hook_menu, hook_block
Architecture Evaluation
Evaluate Architecture
hook_menu, hook_help, hook_perm, hook_call, hook_theme, theme_evaluateArchitecture, hook_form
Create/Edit/Delete Project Projects Hook_menu,hook_auth,hook_perm,
To-Do ListEvaluation Results TBD
Delivery Home Page
Delivery Tool TBD
Architecture –Page Module View
56
FALL 2008 - To Do List
Deliverables Necessity Level
Content Management Analysis Must have
Database design Must have
Architecture Must have
Model for ‘Evaluate Architecture’ Must have
Code for ‘Evaluate Architecture’ Nice to have
61
Estimation process
• Assigning Specializations• Estimation of tasks by specialized resources,
team’s experiments, team’s knowledge from the past ..Else… Planning poker.
64
Task estimation processWeek begins
WBS
Experienced task owner may override the team
estimation
Average taken
Planning meeting
Team estimates for all tasks
65
Planning process
What we did:1) Based on deliverable list, client priorities we identify
the scenarios to be delivered in a week.2) Break the scenario into sub activities(create WBS);
Define ETVX for each task.3) Estimate based on specialization.4) Defining triggers for tasks that attribute to risks in
the project.
66
Tracking Process-EV
• Daily status meetings - SprintometerMonitor the status of the trigger based on the
deadlineUpdate earned value ( 0 or 100) based on the
exit criteria of each taskUpdate actual cost based on the hours spent
68
Risk Statement Trigger Deadline Trigger status Risk Status Exit Criteria for the risk
Mitigation Strategy Chosen
The team lacks implementation knowledge in
Ajax ;will affect the reliability quality
attribute when implementing
Saving of Notes
The Individual responsible must
complete the basic infrastructure for Ajax Database Interaction by
setting up URL and mapping that to database updates 2-18-2009 Passive Mitigated
The notes get saved in the database and
survive browser crash
Allow the assigned resource to conduct experiments with Drupal and Ajax
The team has ambiguity in
deciding on the checked status of checkboxes and how they change
with the rules in the database; This will
affect a medium priority usability
scenario
The Individual responsible must
complete the basic infrastructure for
Rules(That is make recursive checking
of hierarchical checkboxes based
jQuery 3-26-2009 Passive Mitigated
Based on the rules that get store in the
database, the hierarchical
checkboxes get checked
Allow the resource to conduct
experiments with Hierarchical
Checkbox handling.
Risk Management Overview Process Project Management Reflections Demo
71
Risk Management
Risk Identification using SRE
Risk prioritization based on multi voting
Write Mitigation Strategies 1.Strategy for reducing Impact2.Strategy for eliminating condition 3.condition Strategy for reducing probability4.Strategy for extending time frame
Pick a mitigation strategy and setup of Triggers (deadlines)
If Trigger fires
If Trigger does not fire
Choose another mitigation Strategy
See if the exit criteria is met
Risk is mitigated
72
Risk Statement Trigger Deadline Trigger status Risk Status Exit Criteria for the risk
Mitigation Strategy Chosen
The team lacks implementation knowledge in
Ajax ;will affect the reliability quality
attribute when implementing
Saving of Notes
The Individual responsible must
complete the basic infrastructure for Ajax Database Interaction by
setting up URL and mapping that to database updates 2-18-2009 Passive Mitigated
The notes get saved in the database and
survive browser crash
Allow the assigned resource to conduct
experiments with Drupal and Ajax
The team has ambiguity in
deciding on the checked status of checkboxes and how they change
with the rules in the database; This will
affect a medium priority usability
scenario
The Individual responsible must
complete the basic infrastructure for
Rules(That is make recursive checking
of hierarchical checkboxes based
jQuery 3-26-2009 Passive Mitigated
Based on the rules that get store in the
database, the hierarchical
checkboxes get checked
Allow the resource to conduct
experiments with Hierarchical
Checkbox handling.
73
Risk Statement Trigger Deadline Trigger status Risk Status Exit Criteria for the risk
Mitigation Strategy Chosen
The Team is unsure of all the steps involved in the Filter and Algorithm; This will affect the implementation of the Filter and Combine
The resources working on Filter and Combine must get the Filter and Combine Algorithm Signed off by the client 4-7-2009 Active Active
The Evaluation_Responsibility table and Evaluation_Option_Result table get filled with data based on the end user usaps and conditions selected
Write the sequence of steps and do a manual verification of theses steps with the Architecture Pattern Language Document
The team is unsure if the Pdf module would be able to fetch the data from the Drupal Content Pane; Will affect the delivery of the Pdf module
The resource working on it must be able to fetch some data specific to Drupal display region and convert that to Pdf 3-29-2009 Passive Mitigated
The data in the centre content pane of Drupal is saved in Pdf format
Conduct experiments with Interaction of the Pdf module with Drupal
74
Risk Statement Trigger Deadline Trigger status Risk Status Exit Criteria for the risk
Mitigation Strategy Chosen
The Team is unsure if the Filtering of responsibilities can be implemented using JQuery Library; Affects two usability scenarios and To-do List Feature
The resource working on the feature must be able to implement filtering of rows in tables using JQuery . 3-24-2009 Passive Mitigated
The responsibility list gets filtered based on the view options selected
Conduct experiments with the Filtering of responsibilities using JQuery Library
The Team is concerned about the client acceptance of all features; Will affect threshold of success of the team
Create a template for client acceptance and get team acceptance 3-21-2009 Passive Mitigated
The clients give a signoff on the template and agree to treat this as feature acceptance
Show a template of the client acceptance and get it verified by the client
75
Maintainer’s view – URL – Authorized User
Page NameURL Authorized Users
Add/Edit Usaps
http://localhost/usapdrupal/authoring
USAP Authors
End-User USAP Selection
http://localhost/usapdrupal/delivery/aplusrequirements
Requirement analyst
Architecture Evaluation
http://localhost/usapdrupal/delivery/aplusarchitect Architects
To-Do List
http://localhost/usapdrupal/delivery/aplusarchitect Architects
Database
http://localhost/usapdrupal/delivery/Go5_DB Administrators
76
Maintainer’s view – Page – Module to be turned On
Pages Modules Modules to be turned on Blocks to be turned on
Add/Edit USAP Author USAP Authoring Tool
Login Login Login
End-User USAP Selection APlusRequirementsAPlusRequirements,
APlusArchitect
NavigationPane
Responsibilities List APlusArchitect APlusArchitect
Navigation Pane
To-Do List APlusArchitect APlusArchitect
View Options Pane
77
Maintainer’s view – Page – Database Field Mapping
Evaluation _Responsibility Table
Current_Name
Child_Name
Rationale
Implemetation details
78
Feature Use Case NumberArchitecture Component Code Files
User Acceptanc
e Test Case
Number Risk Id
Saving of Options in Responsibility
List UC2 APlusArchitectaplusarchitect.js
aplusarchitect.moduleAT3,AT4,AT5,AT6 R1
Saving of Comments with
time in Responsibility List UC3 APlusArchitect
aplusarchitect.js aplusarchitect.module
AT 7,8,9,
Open of Rationale FieldSet UC11 APlusArchitect
aplusarchitect.moduleAT 10,11
Close of Rationale FieldSet UC12 APlusArchitect
aplusarchitect.module AT 12
Open of Implementation
FieldSet UC 13 APlusArchitectaplusarchitect.module
AT13,14 Close of
Implementation FieldSet UC14 APlusArchitect
aplusarchitect.module AT15
Hierrarchical checkbox Rules UC15 APlusArchitect
aplusarchitect.js aplusarchitect.module
AT16 R2
79
Feature Use Case NumberArchitecture Component Code Files
User Acceptance Test Case Number Risk Id
Navigation Pane on the left side UC 10 Navigation Pane
aplusarchitect.module,aplusarchitect.js
SEE Left Hand Side Navigation Pane Test Cases
Filtering of Options in the View Options
Pane UC8
ViewOptions Pane aplusarchitect.module ,aplusarchitect.js
RT 1-8 R5
Rationale -All UC5 ViewOptions Paneaplusarchitect.js
RT 9
Rationale - None UC4 ViewOptions Paneaplusarchitect.js
RT 10,11 Implementation -
All UC6 ViewOptions Paneaplusarchitect.js
RT 12
Implementation - None UC7 ViewOptions Pane
aplusarchitect.js
RT 13,14 Generate Report UC9 ViewOptions Pane aplusarchitect.js RT17 R4
Selection of Applicable End
user Usaps UC1APlus
Requirements aplusrequirements.module ARQ3,ARQ4 Selection of
Conditions in the end user usaps UC1
APlus Requirements aplusrequirements.js ARQ5
Filter and Combine UC16 Filter and Combine Filter and combine.module FC R3
80
Scenario Analysis
1. The system should not lose any information that is not part of the session information. Losing the session data is acceptable by the user. If the system loses information, the loss of data should not be more than one responsibility (Priority – High)
Architectural Decisions Risk Sensitivity Point Trade Off
For every responsibility evaluated, use
asynchronous calls to update the
database on the current evaluation
status
1,2 1,2 1
For every responsibility evaluated, save the data to the database and reload the page.
2 1,2 2
At the end of the evaluation, make call and update database
values
3
81
Scenario Analysis (cntd..)
I. Risks:
I. Risk due to lack of knowledge of implementing Ajax.
II. Risk due to slow response time:
III. Risk due to loss of data:
II. Sensitivity Points:
I. The decision provides persistence of data. (+)
II. It also ensures the reliability of data (as the system commits data using asynchronous calls)(+)
III. Trade-Offs
I. Reliability (+),Persistence(+) vs. Performance(-)
II. Reliability (+),Persistence(+) vs. Performance(-) ,Usability(-)
82
Scenario Analysis (cntd..)2. The Conditions applicable for a particular evaluation of a responsibility list must be
persisted (Priority – High)
Architectural Decisions Risk Sensitivity Point Trade Off
For every condition selected based on
the end user usaps ,store them in
the database
1 1,2 1
For every condition selected based on
the end user usaps ,store them
and pass the information using
Session or Cookies
2
For Every Condition selected based on
the end user usaps, pass the information using Hidden Fields
3
83
Scenario Analysis (cntd..)
I. Risks:
1. Risk due to the fact that there is no table in the current database design to support storing of conditions
2. Risk due to lack of persistence and loss of data
3. Risk due to loss of data and increase the number of fields(one per condition)
II. Sensitivity Points:
1. The decision provides persistence of data. (+)
2. It also ensures the reliability of data (as the system commits data using asynchronous calls)(+)
III. Trade- Offs:
1. Reliability (+),Persistence(+) vs. Performance(-)
2. Performance(+) vs. Reliability (+),Persistence(-)
3. Performance(+) vs. Reliability(-) ,Modifiability(-)
84
85
• A - PLUS is a web based thinking tool that generates To-Do List based on decisions made by the architect
• Agile Methodologies was followed to get immediate feedbacks on the models
• The team has completed database design, architecture of the system and detailed design of a high priority requirement
• The team will follow best practices from XP and Scrum in Spring for more visibility into the project
• Our sincere thanks to our mentors and clients for giving us feedbacks for continuous improvement
Summary Overview Process Project Management Accomplishments Reflections Plan for Spring
85