LOSE4GOOD.ORG (BY TEAM 08)

PROMOTE HEALTHY LIVING

2

TEAM MEMBERSPaul Charron (Client)

Ali Alotaibi

Ankit Kalwar

Arul Samuel

Manas Jog

Monil Parikh

Omkar Yerunkar

Shalini Srinivas

ALI ALOTAIBI

INDEPENDENT VERIFICATION AND VALIDATION

4

Team Strong Points

Operational ViewCooperative and enthusiastic

client

Collaborative team members.

cross-functional team.

Technical ViewStrong programming skills

Quick Learners

some members have work experience

5

Team Weak Points

Operational ViewSchedule conflicts.

Some cultural barriers

Technical ViewFurther training is needed for UI design

Some team members are not expert in Django!

6

Overall Project Evaluation▪ Exceptional work and relentless effort from team members to make this project

succeed.▪ It is not a course project anymore!

▪ C.R.A.C.K stakeholder.

▪ Interesting and ambitious project.

7

Changes In Requirements

• Forum, advertisement, motivation management are not developedProject Scope

• Goal creation and Deletion constrains• How to track Goal

• Benchmark mechanism

Goal management

• No login required• Option to receive updates• Option to refund

Sponsorship process

ANKIT KALWAR

OPERATIONAL CONCEPT DESCRIPTION

9

▪ Online application that potential weight-losers can use to stay motivated in their pursuit to lose weight.

▪ Motivation provided by sponsor who pledges donation to charity against weight-loser’s goal.

System Purpose

10

Benefits Chain Diagram

11

12

System Boundary Diagram

13

BUSINESS WORKFLOW DIAGRAM

14

15

Desired Capabilities and Goals

Organizational Goals

Capability Goals Priority Level

OC-1: Create and track weight loss goals Must Have

OC-2: Account management Must Have

OC-3: Donation Management Must Have

OC-4: Sponsor invitation Must Have

OC-5: Login using Facebook Must Have

Capability Goals Importance

OG-1: Motivate people to lose weight. 80%

OG-2: Make charitable donations 60%

OG-3: Promote healthy living. 100%

16

Level Of Service

Level of Service Goals Priority Level WinWin Agreements How to satisfy it

LOS-1: Payment Ease: The payment system will support monetary transactions in U.S. and Canada.

Should have WC_2751

PAYPAL supports the highest number of countries - 190(in and out of US) and auto refund feature

LOS-2: Uptime: The system will have at least 99 % uptime Should have WC_2749 Guaranteed by Heroku

LOS-3: Compatibility: The system will Support the following browsers: IE 8+, Chrome 25+, Mozilla Firefox 16+ and Safari 6+

Should Have WC_2748Usage of Bootstrap CSS framework - Assure that the site looks satisfactory in all the mentioned browsers.

PROTOTYPEMANAS JOG

18

CHANGES FROM LAST ITERATION

▪ Weight validation prototype removed

▪ Facebook login prototype implemented

▪ Mockups covering most win-win conditions added.

19

NAVIGATION FLOW

Lose4Good home page

Profile Page

Create Goal Page

Invite Sponsor Page Your Account Page

Financial Officer Page

Pending Transaction Page

Sponsor Donation Page Pledge money page Transaction Result Page

20

▪ Main website

▪ Sponsor Donation

▪ Monitor Payment

Mockups

ARCHITECTUREARUL SAMUEL RAJKUMAR

22

SYSTEM CONTEXT DIAGRAM (MODIFIED)

23

USE CASE DIAGRAM (MODIFIED)

24

▪ Django’s MVT Style

- Separation of Concerns

- Future Modification

Architectural Style

Model View Template

- Django’s version of the popular MVC style

Database

Server SideClient Side

Lose4Good.org

25

CLASS DIAGRAM

26

SEQUENCE DIAGRAM – LOGIN

27

ENTITY RELATIONSHIP DIAGRAM

28

Deployment Diagram

29

Design Patterns & Frameworks

Design Patterns - Wrapper Façade Pattern- provides implied interface for several operations

Python’s Django framework- Model class handles the ORM- Callback handling- OAuth Implementation

30

NCS

Architected Agile

PAYPAL provides cheap transaction fees (2.2% per transaction). provides packages for non-profit organization. provides extensive documentation for performing automatic refund. supports wide range of countries and has wide popularity and trust. has a REST API and hence provides a easy way to integrate with our system.

FACEBOOK API Allows users to directly login using their Facebook account. Allows access to their personal information REST API and provides a easy way to integrate with our system.

LIFE CYCLE PLANOMKAR YERUNKAR

32

577 A,B TEAM MEMBERSTeam Member Role Responsibilities

Omkar Yerunkar Project Manager,Implementer

Profile Management Module, Project plan

Ali Alotaibi Implementer,Architect

Goal Creation and Tracking Module

Arul Rajkumar Implementer,Architect

Donation Management Module

33

REQUIRED TEAM MEMBERSTeam Member Role Skills (Required)

Future Team Member(577b)

Implementer Jquery, Ajax, MySQL, JavaScript (Python-Django is a plus)

Future Team Member(577b)

Tester Unit testing, Integration Testing, Coding and debugging skills, Python, JavaScript

Future Team Member(577b)

Maintainer MySQL, Administrative skills, Critical Thinking, Debugging skills

34

35

36

ESTIMATION

▪ Available members:6 members on-campus

▪ Duration:10 weeks – 577b

▪ Efforts:15 hours per week

▪ COCOMO Estimated Effort:10.45 person-month most likelyStaff = 10.45/1.67 = 6.25

37

RE-BASELINE FOUNDATION (JAN 13- FEB 10)

▪ Rebaseline the project(Jan 13- Jan 24)▪ Prepare for development phase▪ Plan for testing▪ Prepare for Rebaselined development Commitment Iteration

▪ Work Products Preparation RDCR(Jan 24- Feb 07)

38

CONSTRUCTION ITERATION 1( FEB 10- MAR 26)

▪ Modules:- Profile Management – 80% Donation Management – 70% Goal Creation and Tracking – 70%

▪ Capabilities:- Achieve GoalCreate GoalRespond to the sponsorship request Invite sponsorAdd charity organizationUpdate weightLogin Register

39

DETAILED PLAN

40

CONSTRUCTION ITERATION 2(MAR 27- APR 14)▪ Modules:-

Profile Management – 100% Donation Management – 100% Goal Creation and Tracking – 100%

▪ Capabilities:- Login using Facebook Delete Goal Track Goal Monitor Payment

41

DETAILED PLAN

42

TRANSITION ITERATION DETAILED PLAN

FEASIBILITY ANALYSISSHALINI SRINIVAS

44

FEASIBILITY ANALYSIS

▪ Business Case Analysis

- Program model presented in FCR ARB

- Personnel cost has been presented in FCR ARB and revised.

- Hardware and software cost presented in FCR ARB

- Benefit Analysis has been revised after FCR ARB

- ROI Analysis has been revised after FCR ARB

▪ Risk Assesment

- Updated the risks – some risks’ magnitude has been reduced, new risks are added for the development phase

45

PERSONNEL COSTTHE CLIENT TIME IS CONVERTED TO COST BY TAKING $200 PER HOUR

46

HARDWARE AND SOFTWARE COST

47

BENEFIT ANALYSIS

48

ROI ANALYSIS

-1.5

-1

-0.5

0

0.5

1

1.5

2

2.5

2013 2014 2015 2016 2017

49

RISK ANALYSIS

50

ACCEPTANCE TEST PLAN AND CASES

▪ Test Strategy : Requirements-test traceability

▪ The test cases have been designed to insure that the implemented functionalities fulfill project requirements as captured in the Win-Win conditions.

51

TEST CASES▪ TC-01-01 Verify successful Login▪ TC-01-02 Verify successful Login using Facebook credentials▪ TC-01-03 Verify unsuccessful Login ▪ TC-01-04 Verify successful registration ▪ TC-02-01 Verify successful goal creation▪ TC-03-01 Verify goal tracking▪ TC-04-01 Verify weight updating▪ TC-05-01 Verify achieve Goal▪ TC-05-02 Verify delete Goal▪ TC-06-01 Verify sponsor's invitation▪ TC-07-01 Monitor payment for a valid transaction▪ TC-07-02 Verify invalid transaction

52

EXAMPLE OF TEST CASE: VERIFY ACHIEVE GOALTest Case Number TC-05-01 Verify achieve goal

Test Item The test case will check for goal completion for the target goal and within the target date.

Test Priority M (Must have)

Pre-conditions The user has already updated his goal.

Post-conditions The system automatically updates the goal status to completion in the database and allows the user to create a new goal.

Input Specifications User's goal details.

Expected Output Specifications The system displays a congratulatory message if the target goal is achieved and allows the user to share the message on Facebook if he wishes.

Pass/Fail Criteria Pass Criteria: - The system compares the user's current and the target goal.- The system should display a congratulatory message of the goals matches.- The system should ask the user to share the message on Facebook.- The system should connect to Facebook using the user's login details and allow the user to share the message on Facebook.Fail criteria:Any fail in the pass criteria.

QUALITY FOCAL POINTMONIL PARIKH

54

METRIC -1 PROGRESS INDICATOR

55

METRIC -2 REQUIREMENTS CHURN

56

TECHNICAL DEBTSDebt-1 (Self Assumption of Detailed Requirements)• Reason: In the use case descriptions, The team had made some assumptions without Ensuring

that the client understood and approve them(Verbal approval only) !• Result: Half through the semester, The team realized that the client view about the details of the

system is far from what the team has built!• Penalty: detailed mockups with all functionality using Balsamiq was created to ensure the client

understand them and based on that for the client The use case diagram and the entire descriptions had to be updated!

Debt-2 (Lack of synchronization between different documents).• Reason: The tight deadline forced the team to not ensure that the different documents are

synch and that all the changes are reflected on them• Result: Clear contradictions between documents, for example OCD and use case diagrams, and

FED.• Penalty: These contradictions cost the team some points in the last ARB and a lot of rework had

to be done to fix these issues, especially as it propagated to other documents .

57

Traceability Matrix

58

DOCUMENT VERSIONING

▪ Documents Naming Conventions.

Eg: FED_FCP_F13a_T08_Vx.y.docx = Phase Number.1VCP2FCP3DCR4RDCR….

We started with 1 when the semester started and will continue with phase four in the spring semester with phase # 4 for RDCR (Rebaselined Development Commitment Review).

Y=Revision NumberWe Increment of revision number every time the document is updated for

the current phase.

59

CODE QUALITY.

▪ Commenting.

▪ Readable variable names.

▪ Indentation.

▪ Code versioning using Github.

60

WHY VERSION CONTROL??▪ Made change to code and revert back for a known good state.

▪ Have to maintain versions of the code/documents.

▪ Wanted to see different versions of the same document.

▪ Wanted to see how long a bug existed.

▪ Wanted to experiment without interfering with working code.

61

GIT VERSION CONTROL▪ git init <directory-name>

▪ git add <file-name>

▪ git commit –m “<commit-message>”

▪ git push

▪ git clone

62

GITHUB ISSUE HANDLING.

63

QUALITY MANAGEMENT SUMMARY▪ Bugzilla.

▪ Dropbox.

▪ Peer Reviews.

▪ IIV & V.

▪ GitHub.

▪ Test Plan and Test Cases.