MDM Course Work 1 - Proposal

Michail Chnarakis "MobileTours" Proposal 09/11/2004
CO32004 - MDM
Multimedia Development Methods
Michail Chnarakis
”MobileTours” Proposal
Client – Edinburgh Tourist Bureau
Napier University of Edinburgh

Department of Computing Science
CO32004 Department of Computing Science

Multimedia Development Methods -1- Napier University of Edinburgh
Contents
1 Brief Page 3
1.1 Purpose / Aims Page 3
1.2 Document Overview Page 3
2 Project Plan Page 4

2.1 Project Activities Page 4
2.2 Future Deliverables Page 4
3 Initial Requirements Specification Page 5

3.1 Technical Requirements Page 5
3.2 Context Of Use Page 5
3.3 Target Audience Page 6
3.4 Scope Of The Application (Risk Analysis) Page 6
4 Initial Design Documentation Page 8

4.1 Creative Strategy Page 8
4.2 Initial Navigation Map / Structure Chart Page 9
4.3 Storyboard For Initial Screen Designs Page 10
5 Test Documentation Page 14

5.1 Strategy Page 14
5.2 Test Data Page 14
6 Summary Page 15
6.1 Proposal Document’s Summary Page 15
Appendix 1 Page 16
References Page 16

1. Brief
1.1 Purpose / Aims
This document will present a proposal of the “MobileTours” system dedicated to the
Edinburgh Tourist Bureau (ETB). The application will be a mobile guide of the Old Town of
Edinburgh City. The “Mobile Tours” will be used from potential visitors of Edinburgh City to
help them find their way around the city and provide them with information for various
locations around the Old town of Edinburgh.
The “MobileTours” system will be an application intended for use on mobile devices, more
specifically on HP iPAQ devices, Personal Digital Assistant (PDA), which will be loaned from
the Edinburgh Tourist Bureau to visitors. The application could possibly be downloaded and
used from visitors on their own mobile phones and other mobile devices, in future.
The development of this application has been divided into three phases.
• Phase One - Proposal of the application
• Phase Two - Development of a small-scale prototype and plan for the development of
the fully functional system.
• Phase Three - Development of the fully functional application.
On this phase of the project, a proposal of the system will be described according to the initial
requirements from the client and discussion on the future activities for the project. On phase
two, a working small-scale prototype will be developed in relation to the proposal discussed
on the proposal document and the client’s feedback after the proposal. Also, a plan for the
fully functional system will be described, for the last phase of the project. On the last phase,
phase three, a fully functional system will be developed according to the previous plan and
the client’s feedback from the prototype of phase two. At phases two and three, testing will be
carried out to ensure minimal bugs on final system.
1.2 Document Overview
The proposal document consists of the following four parts:
Brief
Explains the overall aims of the project.
Project Plan
Explains the activities of the project their sequence and length. Also, the milestones and
deliverables of next phases.
Initial Requirements Specification

Consists of the following: technical requirements of the finished application, context of use,
target of audience and scope of application.
Design Documentation
Explains the ‘look and feel’
Consists of the following: creative strategy, initial navigation map/structure chart and
storyboard for initial screen designs (including sketches of screen contents for key screens).
Test Documentation
Explains the overview of the proposed test plan for the application.
Summary
Summary of the Proposal Document

2. Project Plan
2.1 Project Activities
The project has been divided into three phases and each phase into several activities. The
following table shows the activities to be carried out on each phase of the project.
Title Hours Allocated Completion

Phase One – Proposal (4hrs)
Proposal Document 4pm
4hrs
with sketches for key screens [MC] Tues. 09/11/2004
Phase Two – Small Scale Prototype & Phase Three plan (20hrs)
Prototype GUI Design [MC] 5hrs Tues. 16/11/2004
Prototype Implementation [MC] 8hrs Tues. 23//11/2004
Prototype Final Testing [MC] 2hrs Tues. 30/11/2004
Phase Three Plan [MC] 4hrs Tues. 07/12/2004
4pm
Phase Two Submission [MC] --
Tues. 14/12/2004
Demo Presentation [MC] 1hrs 06-08/01/2005
Phase Three – Fully Function Development (32hrs)

System GUI Revision [MC] 5hrs Mon. 31/01/2005
System Implementation [MC] 18hrs Fri. 08/04/2005
System Testing [MC] 7hrs Thurs. 25/04/2005
System Testing (client) [MC] 2hrs Thurs. 28/04/2005
Fully Functional System
-- Thurs. 02/06/2005
Submission [MC]
As stated already, the above table gives details on the several activities for each phase of the
project. Also, it is shown the duration for each activity, as each activity endures until the next
is to be started. Note that each of the activities described can be divided into other smaller
activities themselves but these are not shown as can been detailed at this phase of the
project. They will be described on later phases.
2.2 Future Deliverables
On each phase of the project, through the activities to be carried out, several deliverables
has to be produced and submitted to the client or the client’s representative. Each deliverable
has to have a specified quality as pre-agreed with the client (this will be detailed in a later
section of this document). Also, each deliverable has to be submitted on the date agreed with
the client.
The first deliverable, Phase One, is the Proposal Document (present documentation). This
document has to specify a detailed proposal for the “MobileTours” application. The next two
deliverables will be at the end of Phase Two. The first deliverable, of Phase Two, will be a
small-scale prototype of the “MobileTours” application. Secondly a detailed plan of Phase
Three of the application. Thirdly, a presentation of the demo produced for the “MobileTours”
application will be delivered to the client. On Phase Three, the fully functional application has
to be delivered, fully documented. All the above deliverables has to been delivered on agreed
dates with the client and with a specified quality as agreed and according to the requirements
of the application.

3. Initial Requirements Specification
3.1 Technical Requirements
The “MobileTours” fully functional system will be designed to run on mobile devises, such as
the HP iPAQ PDA. Also, the small-scale prototype, of Phase Two, will be build according, as
close as possible, to the specifications of such a devise. The following are the technical
requirements for running the fully functional system:
Technical Specifications
integrated • Integrated Bluetooth™ (ver. 1.1)
wireless • Wireless ready with the addition of SDIO WLAN 802.11b
card*
operating Powered by Microsoft® Windows® Pocket PC 2003 Premium

system
processor 400 MHz Intel® XScale™ technology-based processor
display • Type: Transflective type TFT colour with LED Backlight
• Number of Colours: 64K colour (65,536 colours) 16-bit
• Touch Screen: Yes
• Resolution (W x H): 240 x 320
• Viewable Image Size: 3.5 in (96 mm)
memory 64 MB SDRAM (56 MB main memory)

memory • SD Slot: SD, SDIO, and MMC support
expansion • CF Slot: Compact Flash Type I and II
audio Microphone, speaker, one 3.5 mm headphone jack, MP3 stereo

(through audio jack)
* A standard WLAN infrastructure, other Bluetooth-enabled devices, and a service contract with a wireless
airtime provider may be required for applicable wireless communication. Wireless Internet use requires a
separately purchased service contract. Check with service provider for availability and coverage in your
area. Not all web content available.
Brands and product names herein are trademarks or registered trademarks of their respective holders.
© 2003 Hewlett-Packard Company
The technology that will be used to develop the “MobileTours” application will be the
Macromedia Director MX. The research done on this area is that the best technology to use is
the Macromedia Flash, as mobile version of that is already in use. Although, it is considered
that by the time the fully functional application will be ready to be distributed, a mobile version
of Shockwave player will be available. So as there is already an experience on the use of
Macromedia Director MX this technology has been agreed to be used. Thought, on the next
phase of the project, the prototype will be developed for use on personal computers using the
above technology and with as much as possible of the above technical specifications
described above.
3.2 Context Of Use
The client in interested to an application for use on mobile devises such as PDAs and
possibly mobile phones as well. The application has to be engaging to the potential users.
That means that it has to overcome the use of traditionally papered maps and information
booklets and of ordinary websites. Given that the subsequent users will be the public which
means that the application needs to be easy to use and to navigate through, with enough but
not distractive, multimedia (videos, pictures, text). In addition the application should be able to
use the multimedia hardware (camera, microphone, speakers) of the devise that will be used
to. Currently, there is not a specific layout to be followed to design the prototype and the fully
functional system, on the later stages, but the application needs to use interactive multimedia

with all the advantages of the flexibility and richness they can provide. Thought, as already
mentioned, it needs to be clear and strait forward to navigate through the different stages of it.
The application needs to cover the Old Town of Edinburgh City with interactive maps and also
with audio-visual resources to specific areas of interest. Finally, the application will need to
provide the user with the facility to upload his personal resources that describe his experience
from his visit to the Edinburgh city and also submit his feedback about the places he has
visited for use from other future users of the application. On that said the use of a suitable
Database system needs to be linked to the application for the storage of all this data. This
approach will be used as a guideline for the design of the application and along with the
feedback from the client for the revision of the future versions.
3.3 Target Audience
The target audience of the “MobileTours” application is the wide public, any potential visitor of
the Edinburgh City and more specifically of the Old Town of the Edinburgh, and the places of
interest around that area. As the application has to be developed for the public, it needs to
cover the wide variety of users that might be from professional users to very beginners ones.
Saying that we could possibly divide the potential users into the following three categories:
• Professional Users:
Users with good knowledge and experience of interactive multimedia systems and the
use of mobile devices. These users should be able to understand well the navigation
approach, to be used, of the system and be aware of its functionality.
• Intermediate Users:
Users with some knowledge and experience on interactive multimedia systems and
mobile devices; more common from their experience on using the web and/or the
navigation of the web through their mobile phones or other mobile devices.
• Beginners Users (wide public):

Users with low or not knowledge or experience at all of interactive systems and with
possibly with low experience and knowledge of mobile devices as well. These users will
be the main target of approach of the development of the present application.
The use and the navigation of the fully functional system should be easy to use and strait
forward to navigate through from all the above categories of users.
3.4 Scope Of The Application
The scope of this application is to create an interactive multimedia site to be used on mobile
devices such as PDAs and possibly mobile phones. The application should help visitors of
Edinburgh City to find their way around Edinburgh and specifically to the Old Town and
provide them location-based information. It should cover the Old Town of Edinburgh City and
the various locations of interest and attractions around the area. The application is dedicated
to the Edinburgh Tourist Bureau (ETB).
On the first stages, the application will be only used on PDAs and more specifically to the HP
iPAQ PDAs that will be loaned from the Edinburgh Tourist Bureau to a limited number of
visitors. This will enable the client, the Edinburgh tourist Bureau, to assess the use and the
impact of such an application to the potential users, mainly the visitors of Edinburgh, before
the wider distribution of the application. In later stages it is considered that the application
would be used from any kind of mobile device, such as PDAs and mobile phones that have
the ability of connecting to the analogous web services and use interactive multimedia.
The initial technical and technological requirements of the prototype and the fully functional
application are described on a section above.

On the following catalogue you can see the detailed initial functional requirements of the fully
functional application. All or most of them will be available on the prototype of the application
but with not with the great variety that the final application will have. These should use the
advantages of the flexibility and the richness of the interactive multimedia technology. By
doing that, the application will be more engaging than the ordinary web-sites and the
traditional paper based maps and guides of the city. The application should consist of the
following functionality:
1. Cover the Old Town of Edinburgh and the nearby various locations of interest and
attractions around that area.
2. An interactive map-based navigation will be used to navigate the main functions of
the application. Also, other more traditional routes will be used for the navigation.
3. The application should include virtual tours of selected areas around the Old Town.
The user should aloud to stop, pause and play again any of these at any time he
wishes. For that purpose there is a possibility that an application already installed on
the mobile devise might be used; though, it mainly considered that the user will be
able to view the virtual tours directly through the “MobileTours” application.
4. Users should be able to submit their personal experience of the visit to the area
and/or specific locations and places the visited. This will be done by enabling the
users to submit their own reviews.
5. Users should be able to download and use the already submitted reviews of previous
visitors and some professional reviews about the various locations and places of the
area. This will enable the visitors what they would like to visit and what they do not
and also where to eat or what to avoid.
6. A search engine will be provided with frequently asked questions (FAQ) and search
facilities, in addition to the above navigation methods. That should enable the users
to look for something more specific than navigating the application to find it.
7. A ‘Tips’ section will be included in the application where there will be the option to get
tips through text or multimedia such as sound or video with sound. The tips should
provide the visitor with information such as how to get the bus and from where, what
places to visit, which places to avoid during the night hours and much more.
8. The application will be usable to a 3.5” screen, as described in the Technical
Specifications table.
9. A camera and microphone will be available with the loaned PDAs provided by the
Edinburgh Tourist Bureau. That will enable the users to take their own pictures,
videos, and record audio, either for submitting them wirelessly for future use in the
application or personal use, if they have the available facilities, such as a laptop
computer.
10. Finally, it is considered the option that the user will have option to download the main
functions and parts of the application to the mobile device and use the application
locally on the device and only connect for secondary resources; or be connected to
view the information provided. This is under thought to ensure that the user get the
most from the application and at the same time the mobile device can be used for
other functions simultaneously, such making a call and maintaining better use of the
battery life.
All the above functionality is the initial proposal for the application. Even though, in later stage
of development there might be technical, resources or other difficulties that might not allow
that all the above to be included in final application. The following table shows a risk analysis
of the development, the probability of a risk and its impact to the project:
Risk Probability Impact

Software development Team Inexperienced 50% 2
Lack of training of tools 35% 3
Customer will change requirements 99.9% 2
Delivery deadline will be tightened 10% 2
Technology not up to standard 30% 1
Impact values: 1 Catastrophic, 2 Critical, 3 Marginal, 4 Negligible

4. Initial Design Documentation
4.1 Creative Strategy
In the development of the “MobileTours” application the needs and the experience of the
potential users and the expected functionality along with the use of the available multimedia
methods and resources to be used, need to be balanced to provide a successful, useful and
usable application. A more detailed treatment of the design of the development of the project
follows.
To develop the application, the initial requirements have taken from the client. After that, a
proposal navigation map and sketches have been produced to give a better idea to the
developer what needs to be done. Afterwards, I small research has gone through about the
mobile devices that the client plans to use the application, to gain better understanding of the
technical specification of the project. Shortly after another research has been done of the
potential users; how much of experience and knowledge do they have on multimedia
systems. It was considered what multimedia needs to be used, pictures, audio, video, if all
these can be used on the devices the client wants to use the application on and if the users
will be ready and prepared for such an application. So, it has been decided that enough
multimedia will be used but not too much in order to create an application that will engage the
user in one hand, gut it will not destruct him from the real results of using the application that
the system is build for. After that, the initial requirements were broke down to obtain as much
as possible from these. That helped to update and revise the navigation map with the
intention of creating a more usable application. Of course, these might be slightly be changed
on the next phase by the development team, if it is believed that this needs to be done in
order to get an application that will bring more quality. Also, there was done an analysis of the
potential problems that the development team might get on its way and other constraints, in
order to get a Risk Analysis of the project and try to be prepared and avoid any future
inconvenience and misunderstanding with the client. The above has been done in
consideration of what the client wants the application to do and of what the users needs are
from such an application.
The navigation controls of the application have been designed in order to convey the look and
feel of an application of this type; but quite simple at same time to help inexperienced users to
use the application without any problems on understanding or not getting through the
navigation. That was decided because the client wants that the application will make an
immediate impact to the users and will be far more engaging of other traditional maps and
web-sites. The main menu links will be designed so that the user will not be more than one or
two actions away form the main menu.
Lastly, the screen layouts are designed to be consistent throughout and give the user a sense
of continuity.
Throughout the design progress, the development team efforts on creating an application that
will be using enough multimedia to be usable and engaging to the user and to keep balance
on these issues.

4.2 Initial Navigation Map / Structure Chart
The above shows the navigation map of the application. This one shows the more important
paths. Other ones might be inserted on the next phase of the project, if this is considered
important. The middle thick line means that all pages having arrows on that line they can all
communicate to each other.

4.3 Storyboard For Initial Screen Designs
Welcome page of the “MobileTours” application
Main Page

Multimedia Development Methods - 10 - Napier University of Edinburgh
Interactive Navigation Map
Virtual Tour Page

Tips Page / Location Description
FAQ / Search Page

The above pictures show examples of the navigation of the fully functional system on a
mobile device, more specifically on PDA. Please, note that the navigation structure might be
changed in a later phase of the project in order to gain better engagement of the potential
users.
The following table explains the layout and the contents of each screen identifying media and
interaction components:
First The First Screen is the first page that the users will see when visiting the
Screen “MobileTours” application. It is a welcome page that the user can see only once
each time he visits the application.
Second The Second Screen is the main page of the application. On the top left corner
Screen there is a logo, which most probably will be changed on the next phase. This
page consists of several links for the next pages and a small picture that
indicates to the user what to expect for the next page. This technique uses text
and picture in order to gain better communication with the user and to help him
to gain better understanding of what follows.
Screen 1 Screen 1 is an example of an interactive navigation map screen. A map with
labels is shown where the user will be able to click on a location’s label to view
location’s text description. It is considered the option that the user, by selecting
a label, to move to another very simple page that asks him what to see about
that location; text description, virtual tour, tips, etc. Doing that would look like
that the application gives more control to the user. Also, on that page there will
be a link to go to the main menu. If the map is not shown in full, arrows will be
displayed to scroll up and down accordingly.
Screen 2 Screen 2 shows a virtual tour’s page. Most of the screen is used for the video.
There are play, pause, stop buttons and move to previous / next (video) buttons,
as well. A slide bar most probably will be displayed to allow user to move to any
part the video he wishes.
Screen 5 Screen 5 shows a location’s text description. There is a small picture or drawing
of the attraction, as I virtual aid for the user, on the top left corner, under the
logo. This page could also be useful for the tips section.
Screen 6 Screen 6 shows the help page. The screen is divided into sections where the
user could either select to read the Frequently Asked Questions or type a
question in the search field. It is considered for the prototype to have the FQA
fully working, and the search engine only for display, because of time and
resources constraints.
The above ‘sketches’ are used here as an example for key screens from different sections. A
better understanding of the navigation can be gained from the previous section (navigation
map).

5. Test Documentation
5.1 Strategy
The application has to be tested from two points of view, the users view (Black Box Testing)
and the developers view (White Box Testing). Firstly, Test Cases will be identified for each of
the above testing ways of the application. On Black Box Testing, feedback will be taken from
the users, through questioners. Also, on White Box Testing, testing reports should be
produced. Each separate section will be tested from both the developer and the user. This will
be done by following the navigation maps of the application as described in above sections.
At the end of the testing a Testing Results Overview Document will be produced which will
contain all the Test Cases that have been carried out and their results (fail/pass). Also a Bugs
Documentation will be produced which will contain the bugs that have found from the
developer and if they have been fixed or not. Finally, please note that the client could possibly
play the role of the user. Also, testing will be carried out the whole time of the development
process from the developer, to ensure as little bugs and failures as possible and to ensure the
quality agreed with the client. All the above consist the System Test of the application. In
addition, a Performance Test will be performed, to ensure that the application will respond
within an acceptable time and also to check that the system could cope with the stored data.
5.2 Test Data
The Test Cases to be produced will contain all the data and all the sections of the application
to be tested. Though, these will be prioritised and the most important will be carried out first.
This will ensure that in case of time and/resources failure the most important activities of the
application will have been tested. Two tables follow. The first table shows the Test Cases in
general; these will be break down into more cases in a later phase of the project. The second
table shows in general the data to be tested (from both the user and the developer); again
these will be break down in later phase of the project.
Data to be Tested
Graphics General
Clear and legible Application is the correct resolution
Located correctly The information used was appropriate to the
topic
The information used was detailed enough
Text / Colour / Layout
Correct Spelling/Grammar/Punctuation
Correct Fonts/Alignments
Colour use in titles is consistent
Navigation
All navigation buttons work
Navigation’s conform to maps
Navigation’s are logical
Main Menu & Quit options appear on every
screen
Multimedia
Audio samples are correctly synchronised with
navigation and transition options
Audio samples are correctly synchronised with
movie clips
Movie clips run smoothly
Timing and placement of media is logical
Media used adds value

6. Summary
6.1 Proposal Document’s Summary
The present document introduced the Proposal of the “MobileTours” application, dedicated to
the Edinburgh Tourist Bureau. An application that will be used on mobile devices, such as
PDAs and probably to mobile phones on a later stage. “MobileTours” will be used from
potential visitors of Edinburgh City to help them find their way around the city and provide
them with information for various locations around the Old town of Edinburgh.
A proposal of the navigation and sketches of key screens have provided on this document.
Also, a detailed requirements section has been produced. A Risk Analysis has been
presented as well.
All, the above are a proposal to the client and any of the above can be considered under
discussion. Although, some parts might not be able to be revised because of technical or
other constraints.
Providing this Proposal Document we hope that we gained enough understanding of the
clients needs and that the development of the “MobileTours” application will start soon.

Appendix 1
References:
1. Elaine England &Andy Finney , “Managing Multimedia – Project Management

for Interactive Media” - Second Edition, Addison-Wesley,.
2. http://www.dcs.napier.ac.uk/~gregory/teaching/CO32004/resources/sample2/
3. http://www.dcs.napier.ac.uk/~gregory/teaching/CO32004/resources/sample2/
4. R. S. Pressman, “Software Engineering: A Practitioner's Approach” - Fifth Edition

(European Adaptation), McGraw-Hill (2000)
5. http://www.edinphoto.org.uk/0_maps/0_maps_of_edinburgh_old_town.htm
6. http://www.royalmile.com/
7. http://www.aboutscotland.com/edin/royal.html
8. http://welcome.hp.com/country/us/en/prodserv/handheld.html


MDM Course Work 1 - Proposal

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MDM Course Work 1 - Proposal

Uploaded by

Copyright:

Available Formats

Michail Chnarakis "MobileTours" Proposal 09/11/2004

Napier University of Edinburgh

CO32004 Department of Computing Science

2 Project Plan Page 4

3 Initial Requirements Specification Page 5

4 Initial Design Documentation Page 8

5 Test Documentation Page 14

CO32004 Department of Computing Science

1.1 Purpose / Aims

1.2 Document Overview

The proposal document consists of the following four parts:

Initial Requirements Specification

CO32004 Department of Computing Science

2.1 Project Activities

Title Hours Allocated Completion

Phase Three – Fully Function Development (32hrs)

2.2 Future Deliverables

CO32004 Department of Computing Science

3. Initial Requirements Specification

3.1 Technical Requirements

operating Powered by Microsoft® Windows® Pocket PC 2003 Premium

memory 64 MB SDRAM (56 MB main memory)

audio Microphone, speaker, one 3.5 mm headphone jack, MP3 stereo

3.2 Context Of Use

CO32004 Department of Computing Science

3.3 Target Audience

• Beginners Users (wide public):

3.4 Scope Of The Application

CO32004 Department of Computing Science

Risk Probability Impact

CO32004 Department of Computing Science

4. Initial Design Documentation

4.1 Creative Strategy

CO32004 Department of Computing Science

4.2 Initial Navigation Map / Structure Chart

CO32004 Department of Computing Science

4.3 Storyboard For Initial Screen Designs

Welcome page of the “MobileTours” application

CO32004 Department of Computing Science

Interactive Navigation Map

Virtual Tour Page

CO32004 Department of Computing Science

Tips Page / Location Description

FAQ / Search Page

CO32004 Department of Computing Science

CO32004 Department of Computing Science

5.2 Test Data

CO32004 Department of Computing Science

6.1 Proposal Document’s Summary

CO32004 Department of Computing Science

1. Elaine England &Andy Finney , “Managing Multimedia – Project Management

4. R. S. Pressman, “Software Engineering: A Practitioner's Approach” - Fifth Edition

CO32004 Department of Computing Science

You might also like