1 By Go5 Team A - PLUS 1. 2 Project Overview Process Project Management Reflections Demo Agenda 2

1

By

Go5 Team

A - PLUS

1

2

• Project Overview

• Process

• Project Management

• Reflections

• Demo

Agenda

2

3

MENTOR

CLIENTSGo5

People Overview Process Project Management Reflections Demo

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


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


9


• Process


• Reflections

• Demo

Agenda

9

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


11


• Process


• Reflections

• Demo

Agenda

11

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


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





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

Earned Value Chart

14

15

Scenario Chart Overview Process Project Management Reflections Demo

15

No

of s

cena

rios

Week

• 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


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


If exit criteria is not met

18


• Process


• Reflections

• Demo

Agenda

18

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


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


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


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


24

24

Mentor’s Feedback

ONE OF THE BEST TEAMS I HAVE MENTORED. Customer focus is really good. Team cohesion is great.


25

Demo

25

26

26

Our Special Thanks to

• Gil Taran

• Eduardo Miranda

• Felix Bachmann

27

27

28

28

Back up Slides

29

29

About USAP

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

31

Effort Distribution for Spring Overview Process Project Management Reflections Demo

31

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


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.


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

Architecture

36

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(+)

Earned Value

42

Requirements

Existing Prototype

Use case Scenarios

SRS Sign off

UI Specification

New scenarios

were added

Scope Negotiation

Fall 08 Spring 09

43


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


48

49

Microsoft Office Excel 97-2003 Worksheet

Process Matrix

49

50

Risk Process

Software Risk Evaluation

Multi Voting

Risk Mitigation

Revisited Every Iteration

50

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


51

52

Database Design – Color Code

52

53

Domain Model

53

54

CMS Analysis

Microsoft Office Excel 97-2003 Worksheet

54

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

57

Detailed Design

57

58

PMWB

58

59

59

Sprintometer

60

60

Issue Tracker

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

Metrics

62

Effort Distribution for Categories

Iteration 0

63

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

Time spent per activity

67

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

Defect Analysis (Spring)

69

70

Risk Management

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


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



The team lacks implementation knowledge in

Ajax ;will affect the reliability quality

attribute when implementing

Saving of Notes


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


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



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



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

Documents

1 By Go5 Team A - PLUS 1. 2 Project Overview Process Project Management Reflections Demo Agenda 2