lose4good.org (by team 08) promote healthy living
TRANSCRIPT
2
TEAM MEMBERSPaul Charron (Client)
Ali Alotaibi
Ankit Kalwar
Arul Samuel
Manas Jog
Monil Parikh
Omkar Yerunkar
Shalini Srinivas
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
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
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.
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
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
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.
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
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
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
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
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.
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 .
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