HeaderSIS.jpg

IS480 Team wiki: 2010T1 TouchPoint:TouckPoint Initial Wiki

From IS480
Jump to navigation Jump to search

TouchPointLogo.png

Project Deliverables

IS480 Team wiki: 2010T1 TouchPoint:TouckPoint Initial Wiki

IS480 Team wiki: 2010T1 TouchPoint:TouckPoint Mid term Wiki


IS480 Team wiki: 2010T1 TouchPoint:TouckPoint Final Wiki

TouchPoint

TouchPoint Team members

Name Email Role Responsibility
Sum Wai Yuan Hedren waiyuan.sum.2007@sis.smu.edu.sg Project Manager/ Liaison Officer
  • Manage time and resource
  • Identify, manage and mitigate risks
  • Setting expectation of the team and provide performance feedback
  • Client liaison
Dalaphone Pholsena d.pholsena.2007@sis.smu.edu.sg Business Analyst/ Lead Tester
  • Define client requirements
  • Define the scope of testing within the context of each release / delivery
  • Perform testing
  • Control quality of each features
Luong Thanh Khanh tk.luong.2007@sis.smu.edu.sg Lead Developer
  • Design software architecture
  • Choose methodology/techniques used in developing
  • Provide necessary training to the team
  • Developing the application
Nguyen Thank Khoa khoa.nguyen.2007@sis.smu.edu.sg Front-end Developer
  • Design and develop user interface
  • Ensure seamless user experience
  • Developing the application

Supervisor

TouchPoint supervisor: Prof. Chris Boesch (cboesch@smu.edu.sg)

Project Description

Overview

Team TouchPoint is developing a working prototype of the Mobile Amenities System for Hotels (MASH). The system will allow hotels to provide access to their amenities and services to their guests through the use of mobile platform. With a goal to value-add hotel guests’ experience, the solution will evolve around a Apple iPhone application to handle available amenities and services requests from hotel guests in a quick and convenient manner through their fingertips. The solution will minimize waiting time of guests and allow hotels to make and launch changes to their services and amenities (e.g. food menus, hotel facilities, etc.) quickly.

Stakeholders

Stakeholders Name and Designation Project Involvement
Sponsor Mr. Jean Philippe Lovotti

Rooms Division Manager Pan Pacific Singapore

• Work with team to produce requirements/vision/ business case/research case/etc. and expectation of the changes to these information

• Provide the necessary resources and content required from Pan Pacific Singapore

Clients (Hotel Staff) Relevant Hotel Staff of Pan Pacific • Provide feedback for improvement of CPS

• Participate in testing of system

Clients (Hotel Guests) Hotel Guests of Pan Pacific

MASH will be suitable to any hotel guests staying in Pan Pacific Singapore

Due to sensitivity concerns from the hotel, there will be no involvement for hotel guests. However, a group of sample audience, which may comprises of hotel staffs will participate in testing of the system.

Scope and Functionalities

MASH is an iPhone App that targets staying guests and non staying guests who owns an iPhone. This app aims to provide an additional advertising channel for the hotel as well as to provide hotelʼs guest an convenient access to the hotel services on the go.

Staying guest: A person who has checked in as a hotel guest. His status will be changed when he check out from the hotel.
Non-staying guest: a person who has not checked in as a hotel guest.

As for this IS480 FYP, the iPhone App will be developed as a working prototype using Apple iOS 4.0 SDK and XCode IDE. The app contains the following two key components:

  • MASH iPhone App
  • Back-end Server System

Fucntionality

Functionality.jpg

1. Facilities and service browsing
For both types of guests to browse for information on the following facilities and services:

  • Recreational
  • Culinary
  • Business

Available information includes operating hours, location and current promotions.

For guests to call the relevant hotel staff directly to make a booking, reservation or further enquiries


2. Room browsing and booking
Users can view details of different types of room and make a booking through hotel reservation centre or the hotel website. Guests will be able to view 360 degree picture of each type of room.


3. Requests
Guests can make requests to the housekeeping and order room service. This function is only available for staying guests.


4. My Profile
For Staying guests to:

  • Set his preferences
  • View all requests he has made

Non-staying guest who have made room reservation can view his booking details.

Resource and Reference

Project Management and Collaboration Tools

  • Dropbox
    • Project collaborative tool, repository for project documents (eg. Proposal, Reflection) and design artifacts (eg. UML Diagram, ER Diagram)


  • Webfaction Hosting Unfuddle
    • Testing host for server application
    • Online project management tool and Subversion server


System Development Resource

  • XCode and IPhone API
    • IDE for developing mobile application


  • Netbeans
    • IDE for developing PHP server application


Programming References and Training

  • iPhone API
    • For programming reference


  • Introduction of Hotel Room Facilities and Amenities by Hotel Staff
    • For initial understanding of the available facilities and hotel operations


Other Resources

  • Hotel Room Catalog
    • For project reference and content


  • Time from Hotel Staff
    • For UAT testing of application


User Interface

Version 1

ScreenCatalog.png
ScreenF&B.png
ScreenMyAccount.png

Version 2 sketches

Restaurant.jpg
Facilities.jpg
Spa.jpg
My Profile.jpg

Version 2

TP culinary.PNG
TPRooms.PNG
TPRoom.PNG


Project Management

Risks and mitigation steps

Project Risks Risk statement Mitigation strategy Status (as of mid term)
Communication breakdown in team Without proper documentation, team members might not be on the same page and do not have common understanding of the project.
  • Use “Unfuddle” to manage work allocation and deadline
  • Use drop box for file sharing
  • Take clear minutes and store in dropbox after each meeting for future review and for any absent member.
This probability of this risk changed from Likely to Unlikely. The mitigation strategy has shown positive results and team members are comfortable with the current communication methods, minimising the risk.
New to ObjectiveC Team members are new to iPhone development platform. The steep learning curve might delay the project schedule.
  • Ken and Khoa who have some expertise in programming will provide training and guidance to the team.
The probability of this risk remains as very likely. Hence the additional of the new risk of finding bugs in Apple API.
Misinterpret client requirement We might misunderstand client’s requirements and hence cannot meet their expectation.
  • Show the client a mock screen shots of the application to illustrate the process flow.
  • Give client the prototype earlier in the development stage to get feedback.
  • Meet client and review the progress at the end of each iteration.
This probability of this risk changed from Very Likely to Not Unlikely. With multiple mock-ups and regular reviews, the project sponsor is constantly keep aware of the team development and able to provide feedback is requirements is misunderstood at any point.
Unavailability of team member Due to unforeseen circumstances, team member might not be available.
  • Assign tasks in a way that at least two people is working on the same thing, so one can take over when the other is not available.
  • Clearly document the progress of each task on Unfuddle to update the rest of the team members.
This probability of this risk changed from Likely to Very Likely because one of our team member indeed faced some personal problems during the project. This therefore increased the probability of the risk.
Unable to connect to the hotel’s back end system For some features, we need to connect to the hotel, without hotel’s permission, we cannot implement those features.
  • Focus on features that do not require connection to hotel back end system in the earlier stage of the project. Without the permission, we still can have a workable project that will benefit hotel clients.
This is no longer valid as both the team and the project sponsor have come to an agreement that we will not be connecting to the backend system due to complications and concerns. The team will instead develop a mock-up of the backend system, comprises of the backend server and database.
Application is rejected by iTunes store iTunes store is our main distribution channel, allowing us to reach more users.
  • Team need to read and be familiarised with iTunes application guidelines before designing the application.
This risk is no longer valid as the project sponsor has decided to keep the final outcome of the project as a prototype.
Inexperience in the luxury hotel industry We might not understand hotel guests’ needs and expectation, hence unable to provide best user experience
  • We need to work closely with the client.
  • Do a walk through of the program with the client at every feedback gathering meetings.
This probability of this risk changed from Very Likely to Very Unlikely. During the development of this project, the team has acquired great understanding and industry knowledge from sharing with our project sponsor and fellow member, who is taking a module related to hospitality, known as World Travel and Tourism. The team also did regular walkthroughs of the program, minimising the impact of inexperience in the industry.
Different level of technical expertise in the team Some team members have more experience in programming than the others. This might hinder the efficiency of job allocation and different working pace.
  • More experienced member will guide the less experienced ones.
  • Allocate longer time for weaker coders when planning the project schedule.
The probability of this risk changed from likely to unlikely. Tasks are allocated according to the each member's strength. Up to the mid point of the project, we have not seen any problem arising due to this issue.

New risks discovered after project acceptance

Project Risks Risk statement Mitigation strategy Status (as of mid term)
Unavailability of Project Sponsor Due to commitments, our project sponsor may not be available to meet us.
  • Update project sponsor though emails with current developments, screenshots of application and upcoming developments
  • Install app with completed components into his iPhone.
This is a new risk discovered and it is Very Likely to happen.
Bugs in Apple iOS 4.0 SDK affecting development During development, some bugs are discovered within Apple iOS 4.0 SDK and awaiting updates from Apple which may affects the feasibility of some proposed app features.
  • Conduct a review of scope and specifications after each iteration
This is a new risk discovered and it is Very Likely to happen.

Project Schedule

Phase Start Date End date
Inception 07/06/10 14/06/10
Elaboration 1 08/06/10 28/07/10
Elaboration 2 07/06/10 12/08/10
Construction 1 12/08/10 08/09/10
Construction 2 09/09/10 01/10/10
Construction 3 01/10/10 20/10/10
Construction 4 21/10/10 28/10/10
Transition 29/10/10 08/11/10

For more detail, refer to "project schedule" file in dropbox and milestones on unfuddle.


Feedback from Client

The following feedbacks are excerpts from client emails.


20 Sept 2010 - After seeing the screenshots of the new UI

"The screenshots look great and I can't wait to see more about your project."

- Mr. Jean P. Lovotti


30 Sept 2010 - After UAT with Client

"The first development are promising, clear in the design and concept. The completion of the project will change the way both hotel associates and clients receive and share information. It will also open the gate to a wider spectrum of possibilities. Keep up the good job!"

- Mr. Jean P. Lovotti

Progress

Summer June

  • Gather project requirements from clients
  • Define project specification
  • User interface mock-up
  • Prepared Use case diagrams and descriptions

July

  • Refine user interface design(UI_version1)
  • Prepared diagrams (ER, Class diagram, logical diagrams)
  • Completed database design
  • Meet client to get feedback for mock up UI
  • Completed UI for functionality #1: Browse Services
  • Completed UI for Functionality #2: Browse Rooms

August

  • Project acceptance slides
  • Build user interface on device
  • Partially complete browse room and browse services functionalities
  • Discussed with client on possibility of integrating with the hotel back end system for "mobile booking" fucntion

Week 1:

  • Completed browse culinary use case
  • Completed browse business facilities use case
  • Preformed internal UAT 1

Week 2:

  • Refine User interface design for better user experience. It's really hard to pick the "right" UI.
  • Deploy new user interface design on iPhone device

Week 3:

  • Completed 'swipe' function for room browsing
  • Discussed on plan for the x-factor
  • Fixed bugs found during testing.
  • Add in extra information for Culinary services.
  • Implement 360 degree view for rooms.

Week 4:

  • Supervisor meeting: Update on the change of UI.
  • Chris pointed out the increase of risk as client is overseas and has not seen the new UI yet.
  • Reviewed and modified risk and mitigation
  • Fixed bugs found during testing.
  • Completed 360 degree view for rooms.
  • Work on UI of “ Requests” and “My Profile”

Week 5:

  • Email client the screenshot of the new UI
  • Worked on the UI for Request page
  • Completed “My profile” UI
  • Decided to put "mobile check-in" as a proposed feature

Week 6:

  • Supervisor meeting: Emphasis on changes of risk level and second path plan in case client does not want to put the app on iTune store. (Refer to minute on unfuddle for details)
  • Meeting with client to show the new UI
  • There are some changes in user requirement for the layout of the UI and more content. (Refer to client meeting minute on unfuddle)
  • Perform UAT with client
  • Ad-hoc built the application on client’s iPhone, so he can see immediate changes as we improve the app.
  • Refine reports and slides for mid term evaluation

Week 7:

  • Mid term evaluation


Week 8:

  • Evaluate on mid term evaluation, what went wrong.
  • Plan for the next half of the project. Shall we drop any feature?

Week 9:

  • Research on "Get direction" to the hotel

Week 10:

  • Research on "Get direction" to the hotel
  • Decided to draw the route ourselves, on top of the map.

Week 11:

  • Meet client
  • We really are dropping "requests" feature
  • Adding in "attraction" feature
  • Work on "get direction" to attractions
  • Finally get the function work. lalala.
  • Minor UI Changes

Week 12:

  • Working on the Poster
  • Implement "attractions" feature
  • Fix bugs on "get direction"
  • Fix more bugs
  • Minor UI tweaks.

Week 13:

  • Mug for exams.
  • Perform User feedback test
  • Consolidate results
  • Prepare slides for THE final presentation

Week 14:

  • Prepare for final presentation.
  • Work on the final report

Week 15:

  • Phewwwwwwww. It's over.
  • Back to normal. Enjoy life.