1. 206CDE
REAL WORLD PROJECT
UK MOVE DIRECT
MOBILE APPLICATION
TEAM MEMBERS:
Melinda Kaszoni
Lenor Sonkor
Sabina Begum
Razvan Balosin
Theo Charisis
Fozrul Islam

2. MELINDA KASZONI
PROJECT MANAGEMENT

3. HUMAN-RESOURCE PLAN
ROLES RESPONSABILITIES NAMES
PROJECT
MANAGER
- plan the staff
- authorize and approve all activities
- track the work done
- analyze requirements and forecast milestones
- report project status
- evaluate performance of all project team members
MELINDA KASZONI
INTERFACE
DESIGNER
- execute all visual design stages from concept to final hand-
off to engineering
- create wireframes, user flows to effectively communicate
interaction and design ideas
- conduct user research and evaluate user feedback
SONKOR LENOR
BEGUM SABINA

4. HUMAN-RESOURCE PLAN
ROLES RESPONSABILITIES NAMES
PROGRAMMER
- ensure implementation of software applications
- ensure completion of product in a timely manner
- run tests and implement client development processes
- work with existing requirements documentation
- conduct case studies to determine required
functionalities
- work within a legal and ethical framework
BALOSIN RAZVAN
CHARISIS THEODOROS
DATABASE
MANAGER
- create database
- ensuring all the data complies with legal regulations
- make sure the information is protected and backed-up
- monitor database performance
- monitor data entry procedures
ISLAM FOZRUL
TESTER
- run functional tests, customer scenario testing
- iron out any bugs and improve quality of the finished
product
ISLAM FOZRUL

5. INITIAL MILESTONES
DATE MILESTONES COMPLETED
14/11/2014 Initiate project YES
30/11/2014 Requirements gathering (Use case & Class Diagram) YES
5/12/2014 Complete design
5/12/2014 Database
12/12/2014 Complete design testing
30/01/2015 Complete programming
6/02/2015 Complete programming testing
13/02/2015 Evaluation and complete the First phase

6. MILESTONES
DATE MILESTONES COMPLETED
14/11/2014 Initiate project YES
12/12/2014
Requirements analysis YES
28/11/2014 Requirements gathering YES
12/11/2014 Requirements prioritization YES
16/01/2015
Complete design YES
19/12/2014 First stage of design YES
2/01/2015 Second stage of design YES
16/01/2015 Database YES
23/01/2015 Complete design testing & Evaluation of the first phase NO
27/02/2015
Complete programming NO
6/02/2015 First stage of programming NO
20/02/2015 Second stage of programming NO
6/03/2015 Complete programming testing & Evaluation of the second phase NO
20/03/2015 Evaluation and complete eventual changes NO
17/04/2015 Final report NO

7. REQUIREMENTS PRIORITIZATION
Requirement Priority Functionality
Log-in page medium yes
Properties page high yes
Details (Landlord and Tenant) high yes
Payment plan high yes
Payment details high yes
Help page medium yes
Upload evidence high yes
Issue refund high no
Release payment request high no
Pay via UKMD low no

8. REQUIREMENTS ANALYSIS
●Use Case Diagram
●Class Diagram

9. System
Landlord
View property details
View payment details
Check payment
View payment plan
Create receipt
Request early payment release
Issue refund
<<extend>>
<<extend>>
<<extend>>
Edit plan
Share plan
Print plan
<<extend>>
<<extend>>
<<extend>>
Create new payment plan
Tenant
Make payment
View receipt
via UKMD
Via other means
UKMD
Verify payment
<<include>>
Upload evidence
<<include>>
User
USE CASE DIAGRAM

10. User
+name
+address
+phoneNumber
+email
+sharePlan()
+printPlan()
+editPlan()
+viewPayment()
+viewReceipt()
Landlord
+landlordID
+createNewPlan()
+deletePlan()
+issueRefund()
+paymentRequest()
Tenant
+tenantID
+makePayment()
+uploadeEvidence()
Property
+propertyID
+address
+tenantName
+landlordName
+startDate
+endDate
+paymentMade
+setPropertyDetails()
Payment
+tennantDetails
+amountPaid
+viewPayment()
+editPayment()
Bank transfer
+accountDetails
+paymentOut()
+paymentIn()
Cash
+paymentIN()
UKMD
+approvePayment()
CLASS DIAGRAM

11. DESIGN
SABINA BEGUM
LENOR SONKOR

12.  Psychological experiments in memory capacity shows
humans can remember more items when they encapsulate
sets of them in groups than when they attempt to recall all
items individually – this concept has been proven by the
Gestalt law.

13.  When working on the designs the aspects that had to be
considered where:
 Culture - Aspects such as language
 Functionality - user should
 PACT analysis

14. THROWAWAY PROTOTYPE
 Shows what is required and how many pages exist and the functions
that are present.
 This has been done in the from of a throwaway prototype.
 Flow chart links together all the objects created in the interface and
organize the different information presented.
Primary requirements:
Payments need to be made
through the application.
Build prototype:
Low-fi prototype
Mid-fi-prototype
Hi-fi Prototype
Evaluate prototype:
User testing
Final requirement:
mobile payment
application
Adequate?No
Yes

15. LOW-FI PROTOTYPE
● This is a paper prototype in the from of a sketch. Enabling
early visualization of the design provoke innovation and
improvement.

16. MID-FI PROTOTYPE
● Based on a screen mock up of the final design.
● The software used is different from the final
software as it is only a mock up.
● Software used: www.fluidui.com

17. MID-FI PROTOTYPE

18. MID-FI PROTOTYPE

19. MID-FI PROTOTYPE

20. HI-FI PROTOTYPE
 More detailed and much more similar to the final
product.
 High-fidelity prototypes are the closest to the
final prototype.
 High-fidelity prototypes take you as close as
possible to a true representation of the user
interface

21. HI-FI PROTOTYPE

22. HI-FI PROTOTYPE

23. HI-FI PROTOTYPE

24. PROGRAMMING
VISUAL PART
(LOGIN SCREEN)
THEODOROS
CHARISIS

25. EARLY STAGES
 Creating a UML and use case diagram for a better view.
 First designs (so we can have a clear image of the design).
 Concluded in a programming language.
 Started programming.

26.  Split the work
 Visual parts
 Back end
 Create a log in menu
 Log in menu for data protection and ethical matters
 Connect the login menu with the back end parts (database)
so it could function.
 Adding the buttons on the bottom of the page but with no
functionality yet
 When you successfully log in, the welcome page shows up,
which grabs the email address used to log in and displays it to
you along with a welcome message.

27. SCREENSHOTS

28. CHALLENGES
 Without the design finished I had no idea of how I
should make it and what colors to include
 Connecting the back end parts with the visual parts

29. BACK END SET UP
PROGRAMMING
RAZVAN BALOSIN

30.  1. Why Angular?
 - MVC done right
 - A declarative user interface
 2. Set up local Angular server
 - Grunt (JavaScript Task Runner)
 - Bower (Package manager)
 3. Set up Heroku Server
 - Procfile
 - Node JS
 - Set Repository
 4. Set up Firebase database to handle user accounts
 5. Create App controller for the login system
 6. Connect Firebase API to UKMD App
 7. Create Sign In function

31. FOZRUL ISLAM
DATABASE

32. ● Before starting the task I needed to get some
knowledge on SQL
● I used Microsoft access to build the database
● The information given was dummy data

33. ● This is the print screen of the Landlord as the Landlord will have
many tenants

34. ● Here is the print screen of the tenants, this will determine on the
amount of clients the application can receive, so there data is
saved.

35. CHALLENGES
 Words overlapping in command line
 Learning the application
 Going from Microsoft access to SQL
 Time scale
 Learning a new implementing language

36. FUTURE PLANS
 Design testing – questionnaires and user testing
 First stage of programming
 Second stage of programming
 Eventual changes
 Testing of the app
 Final working app
 Evaluation and improvements

37. ANY QUESTIONS?
THANK YOU !