LOSE4GOOD.ORG (BY TEAM 08) PROMOTE HEALTHY LIVING
Feb 25, 2016
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 ServiceLevel 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 FLOWLose4Good 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 requestInvite 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.