Public Driven Highways Maintenance Reporting System: Feasibility Study

Feasibility Study
Reference: QG12/HMRS/6/10.12.2010
Public Driven Highways

Maintenance Reporting
System
QG12
C Whiting | C Smith | A Dixon | A Williams
Feasibility Study
This feasibility study has been produced to look into the proposed Highways Maintenance Reporting
System for Shuddersfield Town Council. It is to assess whether such a project can produced,
technically, and theoretically and whether or not it can be delivered as per the specification set out by
Shuddersfield Council.
Key to this study is the investigation into free technologies which can be utilised to reduce
development costs. Furthermore this document will clearly set out the basic project specification, the
development team structure as well as “actions-on” solutions in the event of a problem. This
document will provide a formalisation of the development team’s intentions for the project and a
realisation of the goals and aims of the project.
Shuddersfield Council have contacted the University of Huddersfield to offer the contract to build the
proposed system. The contract also includes a 12 month maintenance contract effective on the date
of implementation. Current cost estimations put this contract’s worth at £120,000 for the University of
Huddersfield. This is inclusive of the 12 month maintenance agreement. This is however, excluding
additional licensing costs which may be incurred during the course of the project.
Within this document you will find;
o Introduction
o Project Initiation Document
o Appendices – Research Conducted
 Technical Research – C Whiting
 Google API Research – A Dixon
 User Interface Research – A Williams

Project Initiation Document
Public Driven Highways

Maintenance Reporting
System
Initiating Author: U0960625 CJ Smith

Department: BSc (Hons) Software Development – QG 12
Revision History
Date Version Description Changed by
16/10/2010 1 Initial Project Brief CS

27/10/2010 2 First Draft CS/CW
28/10/2010 3 Second Draft CS/CW/AD/AW
29/10/2010 4 Final Draft for Submission(Summative) CS/CW
11/11/2010 5 Corrections from Summative Feedback CS/CW/AW
Project Title: Highways Maintenance Reporting System
Contents
CONTENTS ......................................................................................................................................... 2
1. INTRODUCTION .......................................................................................................................... 3
2. PROJECT OBJECTIVES ............................................................................................................. 5
2.1 GOALS AND OBJECTIVES ......................................................................................................... 5
2.2 CRITICAL SUCCESS FACTORS .................................................................................................. 5
3. SCOPE ......................................................................................................................................... 6
3.1 ORGANISATIONAL SCOPE ........................................................................................................ 6
3.2 LOGICAL SCOPE ..................................................................................................................... 6
3.3 TEMPORAL SCOPE/PHASING .................................................................................................... 7
3.4 RELATED PROJECTS ............................................................................................................... 7
4. RISKS, CONSTRAINTS AND ASSUMPTIONS ........................................................................... 8
4.1 RISK MANAGEMENT APPROACH ............................................................................................... 8
4.2 RISKS .................................................................................................................................... 8
4.3 CONSTRAINTS......................................................................................................................... 9
4.4 ASSUMPTIONS ...................................................................................................................... 10
5. PROJECT ORGANISATION ...................................................................................................... 11
5.1 PROJECT STRUCTURE ........................................................................................................... 11
5.2 ROLES & RESPONSIBILITIES ................................................................................................... 12
6. PROJECT CONTROL ................................................................................................................ 14
6.1 ISSUE CONTROL.................................................................................................................... 14
6.2 CHANGE CONTROL................................................................................................................ 14
6.3 QUALITY ASSURANCE ............................................................................................................ 14
6.4 FINANCIAL CONTROL ............................................................................................................. 15
6.5 INFORMATION MANAGEMENT .................................................................................................. 15
7. REPORTING .............................................................................................................................. 16
7.1 REPORTING WITHIN THE PROJECT TEAM ................................................................................. 16
7.2 MANAGEMENT REPORTING .................................................................................................... 16
8. STAKEHOLDERS ...................................................................................................................... 17
8.1 IDENTIFICATION AND ANALYSIS ............................................................................................... 17
8.2 COMMUNICATION .................................................................................................................. 17
9. PLANNING ................................................................................................................................. 18
9.1 APPROACH ........................................................................................................................... 18
9.2 MILESTONE PLAN .................................................................................................................. 18
2 of 18
1. Introduction
Due to recent government spending cuts, Shuddersfield Council’s Road Maintenance Department has
had its budget slashed by 80%. To counter this they are looking at ways of improving efficiency and
productivity while reducing the amount of work hours dealing with road condition complaints that
currently go through the road maintenance’s department call centre. Currently the call centre employs
ten full time employees, with the department’s average salary sitting at £20,000 per employee. On
average the call centre receives 100 complaints a week, all of which require an employee to go out
and investigate. On average 60% of the complaints are determined to be non-critical with each report
taking an average two hours to locate, assess and the severity of the complaint.
Over the course of a week this collates to 120 wasted hours investigating complaints that are deemed
departmentally un-critical. Shuddersfield council have identified this as a potential area of saving.
Therefore Shuddersfield Council have requested an online reporting tool, to replace the current
complaints centre. Over the course of a five year period, Shuddersfield Council aims to cut the
complaint handling centre’s workforce by 50%, resulting in savings of approximately £500,000.
Once Developed the system will be an online interactive complaints form where road condition
complaints are added and logged. Using this data the system must be able to determine the level of
severity. The council currently employ 3 tier system to assess complaints; Critical (Needs immediate
repair), On Going (Causes no immediate danger but must be checked bi-weekly) and Non-Critical.
Using these safety condition levels, the system will look for keywords and phrases to determine the
order in which jobs should be allocated and accessed.
Members of the public who wish to report a road condition complaint will log onto an online web
interface and post using a user friendly form. Users can posts complaints creating an account, or
reporting as a guest user. The complaints can be accessed by department employees though an
online panel. Additional functionality will include developing an Android Mobile phone application that
will synchronise to a centralised data source giving employees information allowing them to assess
and verify the complaint on the move eliminating inefficient paper trails. Because of the extensive
functionality of the Android devices and operating systems, the application will be able to share
GEOData with the “Google Navigate” software, pre-installed on all Android devices.
Basic requirements of the system are:
 The web interface must be easy to use and navigate for all users of physical and technical
ability.
 Complaints will be batched into groups of 10, disturbed to employees and assessed.
Compliant locations will be no more than 10 miles apart
 Public Users who hold an account can have a “reliability” rating (Similar to eBay’s feedback
system) which will give them more functionality and elevated submission privileges than a
“guest user”. If a user has a 90+% “reliable” submission history after reporting 10 posts they
will be allowed to specify what they think is the level of severity. Those submissions will then
be automatically added to the list of jobs according to their level, by-passing the automated
system.
3 of 18
 If two or more condition complaints are deemed 95+% similar, they will be treated as one
report. The original report will then receive a special flag that is to indicate an almost identical
report was submitted and an alert sent to the administration panel for employee checking.
The newer complaint will be stored for one week before being automatically deleted unless it
is deemed to be a separate report therefore being re-entered into the system for analysis.
4 of 18
2. Project Objectives
2.1 Goals and Objectives
Goals Objectives
To help reduce council  Create a system that will reduce workforce over 5 years by 50%
expenditure and wasted saving upwards of £500,000 in salary.
hours spent reporting and
analysing local road  Improve productivity of road assessor by sending them to the
conditions.. most urgent reports first.
 Automate paper-trails using android devices.
To encourage the public to  Allows members of the public to report road conditions easily
take a more involved role in and for free, direct to the council.
local road way standards.
 Create an interface that is attractive, easy to use and accessible
for all users.
To use existing software and  Use open source technologies to enhance employee’s mobile
technologies as well as phone devices.
creating powerful and
efficient algorithms to create  To help improve department productivity, allowing better use of
a flexibly online system, council funds.
2.2 Critical Success Factors

By using Beta testing we will assess how accurately we have met the client’s specification. Using
members of the public of all ages we will test our system for usability and reliability. This will ensure
that it is fit for purpose as our testing population will have differing levels of computing experience. As
this service is intended for use by all ages and backgrounds it is critical that it is usable throughout.
We will also meet with the client during the test stage to run them through the system and check that it
is exactly what they want from their specification. This will also allow us to generate new ideas for
future development and extra features. By getting regular feedback from Shuddersfield Council we will
be able to monitor our progress and safely ensure the project is completed and deemed a success.
5 of 18
3. Scope
3.1 Organisational Scope
Shuddersfield Council will use a phased parallel roll out over 5 year. Over the course of the 5 years
Shuddersfield will gradually migrate all traffic to the online web complaints form.. Each year they will
reduce the workforce eventually reducing the workforce by 50% with all complaints being solely
handled by the online system
The road maintenance department at Shuddersfield council is responsible for the safety and upkeep
of local roads. They are responsible for maintaining the following categories
* Traffic lights: including failures and damages including vandalism.
* Road conditions: including road markings, signs, and road conditions.
* Removing obstacles: including road kill, foliage debris
* Weather issue; including snow, ice and standing water
In addition meetings will be periodically required with the Shuddersfield to update and refine the
specification. Lorraine Gearing has been appointed project liaison officer between the developers and
Shuddersfield.
Furthermore road maintenance employees will need to be trained in the use of the system upon
implementation to ensure competency and complete understanding of the new system and the
devices. We believe this will increase the productivity of the employee and have the added benefit of
improving the employee’s IT Literacy and confidence.
Finally, we the developers must develop and test the system frequently and extensively so that it
meets the guidelines and specification of Shuddersfield Council. We must also monitor and control the
design and implementation of the system to produce effective and thorough documentation and
support packages for training.
3.2 Logical Scope

* Complaints Catalogue
* User Accounts
* Submission Storage
* Submission Quality Checks (Captcha)
* Sort Processes
* Reporting Processes
* Navigation Tools
* Online Support
* Online Portal
* Android Application
* Reporting to External Bodies
* Management Information System
6 of 18
3.3 Temporal Scope/Phasing

 Analysis
o What does the customer want?
o Refine design until it is clear and concise
o Identify important dates
 Design
o What technologies to use?
o What functionality to implement, is it possible
 Productivity
o Start Project
o Monitor Project to completion
o
 Testing
o Beta
o White Box
o Black Box
o User Experience Feedback
o Clients Comments
3.4 Related Projects

Projects Expected
Completion
CIA2326 – Formal Aspects of Computer Science 4th Dec ‘10
CIS2344 – Algorithms, Processes and Data 21st Jan ‘11
CIS2343 – Object-Oriented Systems Development 11th Mar ‘11
CIS2360 – Relational Databases and Web Integration Unknown
CIS2390 – Operating Systems and Network Security 3rd April ‘11
7 of 18
4. Risks, Constraints and Assumptions

4.1 Risk Management Approach
In the event of a team conflict, the project manager will call a team meeting and will discuss the issues
to try and rectify the problems such as matters of conduct. If a solution cannot be found then the
problem will then be passed up to his superior.
Similarly in the event of absences due to unforeseen events such as illnesses, we have allocated
additional time where we as a team can attempt to bring development back on track. We have also
decided that we will have weekly meetings where we discuss what each member is doing to ensure
everybody is fully aware of the current status of development. In the event of a member being absent,
for a prolonged period of time the remaining developers will be able to take on various components of
the absentees work; therefore making the project structure independent to one individual.
Finally, in the event of computer malfunctions and loss of data, we as development team have
introduced a policy that requires the backing up of data periodically and also the uploading of any
major documentation to the Blackboard Group Page to allow for data recovery and redistribution
between developers.
4.2 Risks
 Absence due to external responsibilities.
 Team conflicts including disagreements with workload or effort.
 Unforeseen events such as illness or extreme weather which prevent developers from
attending meetings or completing tasks on time.
 Computer malfunction / Loss of data/work without creating backup copies of important files.
 Financial constraints such as the withdrawal of funds from the project or being prevented from
using licensed software due to not renewing previously held licences.
 Inexperience in a language or technology related to the project which could cause the project
to fall behind from its projected timeline.
 Additional work cannot begin until a previous section has been completed..
Developers complete their section but have to wait until another part of the project is complete
before being able to start their next stage.
8 of 18
4.3 Constraints
Firstly because of additional academic projects, we as a group may not be able to work exclusively on
this project. Unfortunately, there are other assignments that will be assigned concurrently to the
system’s development which may be deemed more important as deadlines approach. We also have
to contend with a 1 month Christmas break which may bring the development to a standstill unless
individuals are prepared to continue their work without face to face group meetings and discussions
with the project manager.
Secondly, some group members live 1 to 2 hours away. On average 25 hours a week will be lost in
commuting which could have been better spent working on the project. To combat this we are going
to have to ensure meetings are conducted efficiently and work is completed on time without additional
delays.
Similarly because of unavailability and financial restrictions, the system cannot be tested on all
Android Devices that are currently on the market. This may result in some user experience being
reduced as not all Android Device use the same screen size or resolution.
There are also several data constraints within this system, we will need to limit the user’s submission
so that any algorithms we develop are able to compute similarities and produce accurate reports. One
way to ensure this is by restricting the user’s ability to express themselves when submitting reports.
By forcing them to select predetermined values, any algorithms developed will be able to search for
key words and input without having to worry about unrelated jargon.
Furthermore, another constraint could be the methods of data storage. Is the system limited to basic
file storage or can a database be created and implemented which will allow effective data retrieval
and prevent update delete and insertion anomalies to ensure data integrity is maintained.
In additional to data constraints, computational power could be an issue depending on the complexity
of the algorithms implemented, it may not be physically possible to finish in a finite time. The algorithm
complexity and run time could be proved using Big O notation, to give a best and worst case scenario.
Penultimately there may be an API constraint in that Google Maps may not be appropriate for use
with our proposed system. This would mean the use of other alternatives which may not work on
Android or with the Google Navigate Software.
Finally, userbase may be a large problem with particular reference to choice in web browser and
online security. If they have disabled JavaScript or Cookies this may result in reduced or NO
functionality from the online complaints form. There may also be cross-browser compatibility issues
with certain browsers. Our web form design must be fluid because not all users use the same screen
resolution or browser. To counter this we need a detailed and flexible design which might take
additional time to develop.
9 of 18
4.4 Assumptions
Project Assumption
Group Members may need to refresh/train on the various languages.
Council workers have basic ICT knowledge
Open source technologies and API’s are available for use
Shuddersfield Council has a large enough area to populate dummy roads
Council have access to Android devices
Group have access to required technology, API’s and Test Data
Group is able to work effectively together
Individuals are able to work within their given areas with some level of competence
Each individual will be able to do a minimum of 250 hours work
The group has access to all the relevant technologies, hardware and software
The group is able to communicate properly
The group is able to meet regularly to discuss problems and check the status of the project
10 of 18
5. Project Organisation
5.1 Project Structure
11 of 18
5.2 Roles & Responsibilities

Title Project Manager
Role The person responsible for developing, in conjunction with the Client, a definition of the
project. The Project Manager then ensures that the project is delivered on time and to the
required quality standard (within agreed specifications).
Responsibilities
 Managing and leading the project team.

 Managing co-ordination of the working group engaged in project work.
 Developing and maintaining a detailed project plan.
 Recording and managing project issues and escalating where necessary.
 Monitoring project progress and performance.
 Final approval of the design specification.
Number of People 1 Days per Week 5 Total Months for 7
Project
Title Systems Design and Development (SDD)

Role The person responsible for designing and developing, the technical workings of the
project. The SDD will ensure that all code is tested to a functional level before being
released to a wider test audience.
Responsibilities
 Assisting other developers in the group on matters of programming and code

correctness.
 Algorithm Realisation.
 Ensuring code quality through-out the group.
 Developing Black and White box test plans.
 Assisting on the implementation of data and the launch of the system.
 Ensuring all parts of the system correctly fit together.
Project
12 of 18
Title Research and Algorithm Development (RAD)

Role The person responsible for researching existing technologies including API’s, operating
systems, navigation systems and mobile devices. Other responsibilities include algorithm
design and creation of the test plans and other documentation.
Responsibilities
 Creates test plans.

 Creates/Compiles User and Technical Documentation.
 Researching API’s and other Existing Technologies.
 Creation and design of logical, syntactical, and mathematical algorithms.
 Assists the developers with any of their research needs.
Project
Title Interface Design and Development (IDD)

Role The person responsible for designing and developing the public interface which must be
assessable to all members of the public regardless of computer ability or sight
accompaniment.
Responsibilities
 To ensure all interfaces are easy to use.

 To produce an attractive yet structured and informative website.
 To help launch the system onto the internet.
 To help the SDD design and implement the method of entering and view data into and
from the database.
 To assist the building of the council portal/application.
Project
13 of 18
6. Project Control
Each team member will not only follow the overall project timeline but will monitor the hours and tasks
that they complete on a separate Gant chart which is to be submitted to the Project Manager each
week to allow the projects progress to be tracked more accurately. The project chart can then be
updated in order to show exactly how long each task took to perform showing whether it took longer
or short than originally planned. This will help to keep the team on task, if a group member is seen to
be falling behind other group members can help out and get the development back on track. This will
enable us to have a better idea of how long tasks are going to take and if two tasks are dependent on
each other we can plan in enough time so one will flow straight into the other without waiting.
6.1 Issue Control

Any Issues that arise can be brought to attention either at the weekly meetings, during the day, or via
email. Other contact methods include text messaging, instant messaging and Voice Over IP software.
All problems should be forwarded to the Project manager so that if necessary the project timeline can
be altered to reflect changes in the progress of the project. If necessary, additional meeting time can
be arranged to discuss and resolve any problems which arise. A log will be kept of any major issues
and will detail the actions taken and also the implications on the project as a whole.
6.2 Change Control

Changes should be logged and separate copies of the new specification (if affected) or the plans
created with the changes highlighted. A Change log will be provided within the accompanying
technical documentation stating what, and why something was changed. Any changes which
represent a significant change to the final product should be cleared with the Client. This will ensure
that all team members as well as Shuddersfield council are fully up to date with the specification,
eliminating any issues which could make the end product unfit for its purpose.
The log will show specific details about whose initial idea it was to make the change, the date and
time in which the idea was initiated, group feedback on the idea, client feedback, the immediate
changes to the project, and the implications on the end product.
6.3 Quality Assurance

Our system at various stages will be tested against the main specification. UML and symbol tables will
be produced to allow all the developers to link their individual components together. Each Developer
is expected to extensively test their code as they complete each task. In January we plan to have a
midpoint review in which all code and paper work is reviewed, updated and checked by the group for
quality and accuracy. Before being released on public Beta, a test plan will have to been devised for
each component of the system. For each component developed tests will be carried out by group
member(s) who have had the least input on that specific section of the development cycle. We will
use focus groups with varying degrees of computer literacy to gain instant on the spot feedback. The
system will then be available for public Beta.
14 of 18
6.4 Financial Control

Shuddersfield Council have requested the development of the system to be as cost effective as
possible. Because of this, we have decided to steer away from commercially licensed products such
as ASP.NET and IIS1 in favour of open source products such as LAMP2. These products are licensed
under the GNU Open Source3 License.
Furthermore this product is going to be used as a university project therefore we will not be
charging Shuddersfield Council for the development of this product, however we will carefully log the
hours worked like any development house would do.
6.5 Information Management

All Information and Documents relating to this project can be found on the group’s Blackboard
Collaboration Page. All documents can be requested by email from the Project Manager. On
completion of this system, all documents will be rolled into either a technical documentation or
development documentation. Regular meetings are required with personal standards of 95%
attendance individually over the life of the project.
As a group we have introduced a policy that requires the backing up of data periodically and also the
uploading of any major documentation to the Blackboard Group Page to allow for data recovery if files
are lost due to data corruption.
1
ISS : http://en.wikipedia.org/wiki/Internet_Information_Services
2
Linux, Apaché, MySQL, PHP and Android.
3
http://www.gnu.org/licenses/gpl.html
15 of 18
7. Reporting
7.1 Reporting within the Project Team
Each team member will not only follow the overall project timeline but will monitor the hours and tasks
that they complete on a separate Gant chart which is to be submitted to the Project Manager each
week to allow the projects progress to be tracked more accurately.
Each team member will report their weekly/daily progress directly to the project manager. They will
need to produce a separate Gant chart to the overall project timeline. The project manager can then
compare the project timeline to the individual one to see how the individual has progressed compared
to how it was expected. It must include any major/critical developments in their specific project area.
This will eliminate any member of the team falling behind and enable time to be set aside in order to
get back on track. This is essential; if work is not caught up on it could escalate and possibly hamper
the success of the overall project.
If any team member is struggling to complete their specific task this should be flagged immediately to
the project manager. This can then be addressed by helping themselves or pointing the team member
in the direction of someone/something that can help. Again this will eliminate the issue growing until it
is at a stage where there is inadequate time to fix.
All team members should report their progress with the members their system section interacts with,
for example the web designer needs to communicate with the back end programmer so they both
know what parameters, fieldnames etc, are going to be used at both ends. This will prevent two
sections being developed simultaneously be incompatible with each other when asked to interact
together. This will also help keep the team on task as constant reporting on progress is required.
If any team member feels that another member isn’t on task this should be raised with the project
manager. The project manager can then investigate and decide if the issue raised is valid and help to
get the member back on track. All reports, absences, problems, illness/extenuating circumstances
should be reported to first the Project Managers and/or the entire team.
7.2 Management Reporting

The development team’s project manager should report to the Shuddersfield council as often as
possible including when major changes are in progress or structure/design of the system is required
because of time/computation constraints. This enables the client to remain involved with any
development/change in the project while also giving the project manager the opportunity to inform
them why changes are required. It is also a chance for the client to give their own feedback/opinions
on the proposed changes and other suggestions they feel should be added.
Furthermore, the project manager should be available on request to report the progress of the project
to the Shuddersfield. It may be that Shuddersfield request meetings at specific intervals throughout
the project. If this is the case, the project manager must be able to produce documentation to show
the progress of the report in comparison to the planned timeline. The report can be broken down into
different categories; for example design, development, testing in order to give Shuddersfield
representatives a much more detailed view of how the project is developing.
16 of 18
8. Stakeholders
8.1 Identification and Analysis
Members of the public may be confused about the new system and how to use it. This is an important
issue as the public form is the one and only source of data input into our system. Online
documentation and user friendly prompts will be provided to aid users in entering information
confidently and correctly.
Additionally, the council employees who are set to lose their jobs have interested in the system. While
some may attempt to sabotage or delay its planned roll out, others may see this as a new opportunity
as new roles will be created in managing the system.
Furthermore, Lorraine Gearing who is Shudderfield’s Council’s project liaison has an increased
interest in this project as she is the main point of contact for both developers and council members.
As the Council’s appointed representative and liaison, Lorraine will ensure the project is running on
time as well as bringing to the development team’s attention any new functionality that Shuddersfield
Council wish to add or conversely remove.
Finally, the development team is made up entirely of university student and will be developing the
system for purely academic purposes. The successful completion of the project is also in their best
interests as it can be used in future portfolios and give the development team a chance to enhance
personal and technical skills.
8.2 Communication
Stakeholders Expected Communications Frequency Media

Lorraine Status reporting In line with Project Generally, formal reports
Gearing Issues reporting milestones to be followed up by
Council Project Dependent on timing face-to-face contact
Liaison and priority where appropriate
Development Documentation and standards In line with plan Central repository,

Team Project knowledge managed by project
administration
Internal communications
Group e-mail
Team meetings
Public(Beta Informal communication of Whilst Testing/After Email to person
Testers) problems Implementation responsible for Testing.
Discussion of issues
Respond to issues raised
17 of 18
9. Planning
9.1 Approach
The project will be planned using Microsoft Project, this will enable us to include specific dates on
which given sections will be completed. It will give an outline on how much time is set aside for each
major task and also its given subtasks. Also as the tasks can be broken down into subtasks it will
allow each team member to see what they need to complete and by what specific date.
In order to incorporate unforeseen circumstances we have planned in contingency time in order to

catch up on any lost time. We also plan to have the project finished way before the final hand in date
as this will give us plenty of time to test and make any necessary changes required.
9.2 Milestone Plan

Using Microsoft Project, a Project Plan has been produced. Using reporting features and data held
within our Project file, the following report has been produced detailing the current Milestones we
have planned/met.
Mile Stone Report - MS Project
18 of 18
Feasibility Study
Reference: QG12/HMRS/6/10.12.2010 – C Whiting
Highways Maintenance Reporting System
Technical Research

Project Objective

Shuddersfield council have asked us to create an online portal where members of the public can log
on and report road conditions in their local area. They have also asked us to provide some way of
analysing the submissions, grouping similar issues together (those that are 95%+ similar) and using
the submitted data print a report of those submissions with the most urgent first in the list with the
least at the bottom.

After the report has been created, the system will provide directions to each location using
navigation software embedded on Andriodtm phones. If a user submission turns out to be reliable,
the user may be eligible for elevated privileges in the online portal. The elevation will allow him/her
to assess the urgency of the report for themselves, bypassing the system’s own severity assessment
and being positioned in the reporting queue based solely on the user’s submission.
Data
Data submission and data storage are critical if this system is to be used successfully. While almost
100% of data will eventually come from the user, Shuddersfield council must provide the user with
information to accurately describe where road conditions are questionable. Imagine this potential
submission.

“There is something on the road near the chippy, it’s a large black thing that has been
there for ages, it’s blocking a drain and stopping water.”
The submission above would be hard for a council employee to distinguish, let alone a computer
system. An open submission like that above doesn’t put any constraints on the post. It does not give
a specific location such as the road name/ road number, it does not give a detailed description of
the object which can be used to determine the severity of the complaint. The point of this system is
to help the council reduce spending while increasing employee productivity. However if submissions
like this are allowed it will require an employee to needlessly search for what could be a best case of
several minutes, a worse case of several hours.

One way we can limit the domain of submission is by requiring the user to specify where an incident
is being reported using fixed locations known to the council. Perhaps requiring the user to submit
the lamppost ID closest to the spot of damage. Giving the user the chance to pinpoint the location
on a. map directly, or by allowing them to select the road name the incident has occurred on or if it
has happened near a well know place such as a church, public place or local school.

The submitted data needs to be none‐redundant, concise and easy to compare to allow automated
decision making. Council specific information like road names in Shudderfield’s district or lamppost
identifiers must be stored somewhere where the application can access, either in its own data
storage medium or by being provided access to the councils own data storage system.

Christopher Whiting |
Feasibility Study

Restrictions on the data allowed in the system are needed for several reasons.
1) Simplifies the development of a search/report algorithm. Instead of relying on comparing
text patterns or length of submission we can look for key words/phrases as well as locations.
By restricting the domain we improve hardware use and efficiency.
2) Improves memory usage, allows a system to be developed and memory limitations can be
provisionally established.
3) Makes submissions direct and to the point.

Data Storage

Because of the nature of the World Wide Web, information sent to and from a client/server is
stateless; it is forgotten as soon as it is sent. This is a major flaw with the system as it currently
stands, everything from user login to submission requires some sort of information to be
remembered.

There are several ways to store data on the client’s computer including cookie and session data, this
type of functionality is available in most modern day scripting languages including
 PHP
 ASP.net

<?php
//set a cookie storing some information
//set to expire in one hour
setcookie(“cookie‐name”, “stored data”, time() * 3600 );
//check if the cookie is set
if (isset( $_COOKIE[“cookie‐name”] ) )
{ //display the stored data
echo $_COOKIE[“cookie‐name”]; //prints “stored data”
}
?>

However there still remains a problem, cookie/session data is not a permanent data storage source.
Cookies are set to expire after they are created unless you specify their time to live. While you can
force a cookie to remain for all eternity, the user may delete it manually using their web browser.
There are also security concern with cookies, they are notorious for allowing exploits to occur and
can be used (maliciously) to take over a user’s computer without them knowing. Despite this they
are still the most commonly used way of remember user state for the client, such as login details and
customised site authentication.

Although the majority of users will not want to create an account and report anonymously some
users might require an account. One way to do that is by physically adding a user’s name and
password to the login page and through some dynamic scripting check if the user has an account and
then set a cookie.

Feasibility Study

<?php
$listOfUsers = array(
“account1” => “E10ADC3949BA59ABBE56E057F20F883E”,
“account2”=> “8441C6AB9E88EE3764BD79B6D72269A1”
);
$userName = strtolower( $_POST[‘u_name’]);
$password = md5( $_POST[‘u_pass’]);
if( isset( $listOfUsers[ $userName] )
&& $listOfUsers[ $userName] == $password)
{
//do user authenticate stuff
}
else
{
//do anonymous user stuff
}

?>

While this is one way of achieving a “login” script, it is hard to maintain, is not flexible and does not
allow a user to create an account without contacting an admin who can hard code the new login
information into the page.

More importantly how will the system remember what the user has posted, of the two methods
discussed above neither are practical. Storing data inside cookie files allow the server to retrieve
data only when the user returns to the site and as mentioned above the data may be deleted once a
cookie expires. Even if a user returns to the site, how are members of the council able to use this
data to construct a report?

Modifying the second idea of “hardcoding” information into a file, is it possible for a user to submit
data to the server and then ask the server to write the data to an output file? The output file can
then act as an input to the sorting algorithm.

File Storage

As mentioned above another way of saving state is writing the user’s submission to a file and then
searching through the file, finding the information and performing the computation required.
<?php
$file =@fopen(“pathtofile.extension”, ‘a’);
$userData = $_POST[‘userpost’];
fwrite($file, $stringData);
fwrite($fh, $stringData);
fclose($fh);
?>

Feasibility Study
While this is a better way of storing the information it is not very portable, it also slow as it relies on
I/O from the underlying operating system which is time consuming, especially in high performance
applications.

Searching is also a problem, while it is possible to search a file for a given expression using
techniques such as delimiters or regular expressions it is also slow and difficult to achieve. The
proposed system needs to be flexible allowing things to be changed with a few clicks of the mouse.

Database
Finally the last and most practical solution for a system of this magnitude is storing the data in some
form of database. Databases give the most functionality and ease of use for storing, manipulating
and retrieving data. By using a database engine we don’t have to worry how and where the data is
stored, all we have to worry about is manipulating is using the DML (Database Manipulation
Language). SQL is a form of DML and is the main way clients access a database and the stored
information.

There are many vendors that provide database management systems; the most common are Oracle
and MySQL. MySQL is a free open source alternative to the Oracle suite which offers all the required
standards of SQL as well as many additional MySQL specific features.

Storing a user’s input in a database is as simple as using some web scripting language such as PHP,
evaluating the content, connecting to the required database and performing a query against it.
For example
<?php
// connecting to a MySQL database using the Mysqli database
connection library
// to save data to a database.
$dbc = new Mysqli(“HOST”, “USER”, “PASSWORD”, “DATABASE”);
$userInput = $_POST[‘userinput’];
$dbc‐>query( “INSERT INTO userInput( comment) VALUES (
‘{$userInptu}’) )”;
$dbc‐>close();
?>
Similarly it can then be retrieved and displayed on a web page using the following
<?php
// connecting to a MySQL database using the Mysqli database
connection library
// to save data to a database.
$dbc = new Mysqli(“HOST”, “USER”, “PASSWORD”, “DATABASE”);
$userInput = $_POST[‘userinput’];
$result = $dbc‐>query( “SELECT * FROM userInput)”;
while( $row = $result‐>fetch_object() ){
echo “<div><h1>New Post From User</h1></div><p>”;
echo $row‐>comment.”</p>”;
}
$dbc‐>close();
?>
Feasibility Study
By using simple SQL statements you can retrieve, insert and update information in a more
structured way that searching a file.
In conclusion I have found it is possible to store and remember data sent over the world wide
web, however some methods are more practical than others.
Feasibility Study
Reference: QG12/HMRS/6/10.12.2010 – A Dixon
Google API Research
Introduction
In our system we are planning to include Google Maps, this would enable the users
to easily pinpoint the location of a given fault. However we need to ensure that is it
both possible and if so whether the inclusion of this technology is feasible. This will
be done by researching the already available API’s which Google provide and see
how they can be used and manipulated in order to fit the purpose of our system.
How/where would it be used
The Google Maps technology would be used at multiple stages of our system. The
first of which would be for the user (member of public) to accurately determine the
location of a given fault. The second of which could be used when the system
produces the reports. When a report is generated the given location of the fault (in
latitude and longitude) can be send to the member of staff which will then enable
them to use their android devices as a navigational tool. It is therefore vital that we
can use the embedded Google Maps in order to export and import the correct details
for the system to work.
How it would interact with the system.
The usage of the Google Maps API would interact directly with both the user
interface and the database. As the map would be embedded onto the online form it
would be required to give the user an easy and hassle free experience in order to
specify a given location. This is why it is vital to implement the API in the correct
way. The output from the online form will interact directly with the database in order
to store the location of the issue in the form of co-ordinates. Again this would require
usage of the most relevant API to produce the required data.
Google Maps Data
Google Maps also provide a service called Google Maps Data which is used to allow
users to store placemarks. The Maps Data can be used as a personal tool for
planning and reporting on trips made. This could be implemented in order to store
the locations of the given issues in which need to be investigated. The stored
geodata is available across many platforms and devices including web, mobile
devices and command line. This makes the service very versatile and flexible in
order to meet the system requirements.
Feasibility Study
There are many examples of using the Google Maps Data API’s which could be
manipulated in order to suit our system. The first of which I have found from
researching the area is My Maps Editor which is designed specifically for the android
mobile phone. Although this is originally designed to plan out shopping routes by
marking down shops to visit it could be quickly adapted in order to indicate the
locations of issues in which need resolving. Also the system includes the ability to
colour code the given locations, this could be manipulated to show differing levels of
importance or different categories of road issue. When a site has been visited the
user can then change the colour of the site to indicate that it has been visited. This
could be used on the employee’s phones in order to plan out the route they need to
take in order to see to all the sites of reported issues. The major downside from this
is that a plan would have to be put together manually by the user and could therefore
only be used as a personal planning device.
Google Directions API
As said previously there are many different API’s available for use with the Google
Maps package. This means there are could be more than one available API to do a
specific job, therefore detailed research is required in order to find the most useful.
The first API I have looked at is the Google Directions API. This service calculates
directions between locations; these locations can be entered as text strings
(address/ street names) or as latitude/longitude coordinates. However the service is
not designed to incorporate user input after the locations have been inputted. As this
is a web based service it could also be used as a planning tool, however not as
visual as the previous example. It gives the results in an array of “steps” or directions
for example “Left onto Shudderfield Road”.
Google Geocoding API
Another useful service available is Google Geocoding this could be used to fix any
issues which come about from the format of location data. The API provided by
Google processes addresses and converts them into geographical coordinates. This
can also be done in reverse to change the coordinates back into address formal. The
Google Geocoding API provides a direct access to a geocoder via a HTTP request.
Google Maps Javascript API
In order to give the public access to these services in order to specify the location of
the given problem. In order to do this we need to embed the Google Maps onto the
web based form. This can be done using the Google Maps Javascript API, version 3
of this API has been designed to work as efficiently on both desktop browser as well
Feasibility Study
as mobile devices. Using this technology it would allow us to expand into a mobile
app using the same instance of Google Maps.
Alternatives to Google Maps
If this turns out to not be feasible we have to have some alternatives in place. An
alternative idea could be done using a basic map in which the user can simply
browse around, including zooming in/out on an area of choice. The online form could
simply then require the user to input a street name, the map is used to look up the
street name if the user does not already know it. However this is very basic and
would not allow the user to easily determine the exact location of the problem. If we
were to move away from the Google Maps idea completely there is also services
such as Bing maps (previously multimap).
Within the Bing maps tool there is an option to add “pushpins”, there way of
symbolising a specific location. When a location is specified it gives the user the
option to add information about the location. This in itself could be helpful for
reporting faults on road and would also allow the user to enter multiple issues at the
same time. The map can then be shared by email for others to view.
As with the Google Maps package Bing Maps also provide many API’s in order to
make the most of the service they provide. The API’s available from Bing enable you
to do very similar operations to the Google Maps API’s, for example embedding the
map on the webpage, producing maps with specific “pushpin” locations. They also
provide an API called Bing Maps SOAP Services, this enables you to integrate
maps. This would enable the council to put together all the maps sent in by the users
in order to create a “master” map. It also enables you to match addresses on the
maps which could be implemented in order to raise the importance level of a certain
area in the town. With driving directions and distance calculations also included this
would be an important API to master and implement if we were to go down the Bing
Maps route.
Bing Maps is based and created upon Navteq maps that provide maps for both
Yahoo! Maps and Garmin portable GPS devices among others. Another option
would be to use the Navteq maps directly using the API’s they provide. They provide
SDK’s, tutorials and API’s in order to implement the service in the correct way for
your own system.
How Feasible Using Google Maps is
As can be seen from the above research there are definitely services readily
available which would enable us to include all the given features where desire.
However just because the possibility to implement Google Maps in the required way
Feasibility Study
is there it is only when we begin to implement the coding when we find out if it is
feasibly within our time/ability constraints.
The first idea for implementing Google Maps was embedding it upon the online form.
This is definitely possible as shown by the Google Maps Javascript API above,
however it would only be when we start implementing the code when we find out
how easy or indeed difficult it is to execute. As we would require the service to be
able to pinpoint a specific location on a map we need to ensure that both the user
can easily select the given location and also the coordinates can be exported for
storage in our database. We will quickly get an idea as to how feasible using this is
when we start to put basic designs and symbol tables together which will give us
more of an idea what values are required through the system.

Feasibility Research

Reference: QG12/HMRS/6/10.12.2010 – A Williams
WEBSITE AESTHETICS, USABILITY AND ACCESIBILITY
During design and development of the website’s front‐end, http://www.w3.org/WAI/ ‐ w3c’s official guidelines
for web accessibility must be checked against our progress to ensure it complies with most or all the guidelines
given.
WEB LAYOUT
A clear and consistent design helps users navigate and extract information from the website much more easily
as it is easier to distinguish texts, links, images and navigation buttons from one another. It also makes the
website more recognisable so users know whether they are still on the right website and not been sent to
another. This also adds accessibility to people who have tunnel vision and ultimately benefits all users,
especially users with small screens i.e. small monitor’s mobile phones, net books, portable laptops, PDAs etc.
Another aspect of the web layout is the website width which should be looked at.
Here are some of the advantages of disadvantages of two possibilities for width used in a website.
Fixed width
Fixed resolution in terms of web design means that the page is locked within a certain resolution i.e. 1024
pixels.
Advantages
1. Easier to design because the original mock‐up design is going to look exactly the same or very close to
the implemented website, allowing the designer to have full control over the aesthetics of the
website.
Disadvantages
1. Cannot be viewed properly on mobile devices, will therefore have to make a separate CSS file for
mobile and printing devices.
2. Very high resolution screens with browser maximised may see more background than the actual web
page itself.
Fluid
Fluid means the website adapts depending on what resolution it is viewed at.
Advantages
1. Makes the website more portable as it adapts to the resolution of whatever it is being viewed from.
2. Never have to scroll sideways on any resolution.
3. If viewed in very high‐resolution, more information can be displayed on the screen all at once.
Disadvantages



1. Difficult to design due to having to think of ways of making the design not clutter and make it as
perfectly readable on any resolution.
2. Look and feel of website is affected by the devices resolution.
3. The implementation may or may not look close to the original mock‐up design.
4. Texts may clutter and make the website difficult to read on some low‐resolution screens due to the
gaps between elements being smaller that what it is originally designed in the mock‐up design and
can also make the website look quite dull on high‐resolution screens due to empty spaces it could
leave.
Apart from the two obvious solutions, another solution to this problem would be a JavaScript that detects
resolution and use JavaScript to select the CSS to fit the website into whatever screen used perfectly, the
major drawback of this method are that it can become time‐consuming and could be completely useless if the
visitor’s browser’s JavaScript is off.
The requirements of the Project states that the Website will have to be portable, which points to the fluid
solution due to its advantage of being able to adapt to any resolution well, however, it also has to be
accessible, and this is where it could get tricky as the it is difficult to make the website consistent and have
each part distinguishable from one another with good use spacing while being able to adapt to resolutions i.e.
imagine there was a table of texts being displayed on a low resolution screen, or imagine if there were many
different float elements which have specific widths, when these are viewed at very low resolution, some
elements may simply overlap or reposition itself to a position completely different from the original intended
position which could affect the websites overall usability and accessibility i.e. internet phone, the spacing
between all those data would make the texts too contracted making it difficult to read.
W3Cschools statistics shows, 96% of users have a screen resolution with 1024 pixel width, which should be not
be overlooked when making the final decision of if the decision points towards fixed width for the Project.
The Web Layout will directly impact the Websites usability and accessibility so should be planned out carefully.
COLOURS
Colours used in a website can affect its accessibility for people who have partial blindness. Colours near each
other should be easily distinguishable i.e. contrast between background and text should always be clearly
distinguishable from one other, imagine reading grey text on top of a black background, now wouldn’t that be
a pain?
W3C’s statistics shows that 100% of all users now have coloured displays, however, the requirement of the
Project is to be accessible and due to this, we will still have to consider how the website would look on black
and white for rare cases of fully colour‐blind people.
TYPOGRAPHY/FONTS AND SPACING



Typography is one of the elements of web pages that help it become more readable and aesthetically more
attractive to users. There are many techniques for making websites texts easier on the eyes. Simple
techniques such as base‐line grid for vertical rhythm and good combination of typefaces and font sizes can
help tremendously in how readable the website is i.e. distinguishable headers and emphasis from normal text,
small text for uninteresting (but could be useful) information etc.
Another matter that should be taken into consideration is good use of whitespace whenever appropriate i.e.
separating a different topic from another using more amount of whitespace compared to a continual
sentence.
This not only gives the website a better look and makes it easy on the eyes but also adds a bit to its
accessibility, especially for users who have dyslexia, poor eyesight or small screen.
IMAGES
Not all users have their browsers set‐up to show images that could be due to many reasons i.e. slow
connection, mobile device that does not allow images or simply want to speed up load‐time of websites,
therefore making it important to use alternative texts. These Alternative texts must be able to make sense to
make up for the lack of image missing.
This is critical to any website, which is why W3C validator suggests that it is required for latest HTML/XHTML
doctype to have alternative text for every IMG element for it to be a valid html markup.
JAVASCRIPT
According to w3c’s statistical figures, as of 2008, only 95% of users have JavaScript on. I am guessing however
as of now, that the figures for users that have JavaScript on would be very close to 100% due to increase in
available online applications that are becoming very widely used, such as Google, which now use
JavaScript/AJAX to suggest what to search as you type, Google maps, Facebook etc. this also implies that
JavaScript does not simply make a website look better and more interactive, but it also adds to the website’s
usability and ease of use i.e. distinguishable effects when a textbox, button etc. is selected, real‐time updates
etc.
For the purpose of this Project, it would be beneficial to use JavaScript for more usability; however, data
validation inputted by users must always be checked by the server as well due to obvious reasons.
One of the big disadvantages of AJAX however, is the fact that search engine crawlers do not crawl the
additional information that an AJAX function provides after request. A search engine crawler will only crawl
the initial information it sees after page load which could have some impact on the visibility of the public
website to our target audience.
CROSS‐COMPATIBILITY



One of the biggest issues web developers face is making every single web page for their website look very
much the same and achieve their main goals in their design as a whole irrelevant to what browser is viewing
the website.
To deal with this problem, research on bugs on all different browsers behavior must be made. There are many
websites that point out the bugs that do not meet w3c’s standards in terms of element properties and provide
work around to bugs, there will also have to be a lot of testing done by trying out the website itself with as
many browsers as possible.
However, testing a website to ensure its compatibility with every single browser available would be an
impossible task for the time given, so worrying about the most widely used browsers, which can be found at
W3Cschools website is the main thing to look into when deciding what browser should be used to test the
website on.
ANDROID UI
The official UI guidelines from android developers documentation which can be found at
http://developer.android.com/guide/practices/ui_guidelines/index.html provides a good overview of how to
create a UI with different layout and different UI elements built‐in to the Android API.
THE ANDROID API
The Android API for creating the GUI will be able meet the projects requirement of need for usability and
accessibility to some extent, as it allows you to change any property of any element of the UI i.e. font size, type
face, element size, position etc.
SCREEN RESOLUTION
One of the most important limitations that need to be considered when designing and implementing the User
Interface is the fact that most devices that use different screen resolutions and are generally a lot lower than
computer screens. This limit does not cripple the Android’s ability to create very usable User Interface.
Creating a UI that looks consistent throughout different screen resolutions will be one of the main challenge as
the layout will have to be well thought out and designed so that it is viewable on any resolution without some
parts of the UI missing. The problem does not affect high resolution devices so much if the app is developed
for a small resolution device as Android just puts black borders around pixels as shown in Fig 1. or at
http://developer.android.com/guide/practices/screens_support.html, this documentation also provides a well
detailed report on how Android can cope with different screen resolutions.



Fig. 1
USER EXPERIENCE
There are many different android devices with different ways of navigating and typing, so user experience will
not only depend on the Application’s usability itself, but also the device being used. Some Android devices are
more suited for certain group of people than others.
The Accessibility of any Android App is not so much limited by what UI Android app can do, but more of how
accessible the actual device the Android is being used in, which is out of our control.
WILL THE PROJECT REACH ITS AUDIENCE?
The main audience that this project will primarily target is drivers, which by statistical figures would most likely
have some form of computer with an internet connection at home (76%). We also have managed to find
statistical fact that 21% of adults in the UK have an android or some other internet enabled mobile device
available to them. From these statistical figures, we are capable of reaching almost every single one of our
target audience.
SUMMARY
The Project will prove challenging in making in trying to make it accessible to as many different types of
devices available, however, with the technologies and techniques included in this feasibility study proves, we
can develop this project in a way so that it is accessible and usable for our target audience and we have chosen
all the right technologies to use to have the capability to reach our primary audience and most of the general
public.



BIBLIOGRAPHY
Henry, Shawn Lawton. (1994-2010). WAI Guidelines and Techniques. Available:

http://www.w3.org/WAI/. Last accessed 24th Oct 2010.
Henry , Shawn Lawton and McGee, Liam. (2010). Accessibility. Available:

http://www.w3.org/standards/webdesign/accessibility. Last accessed 24th
Quinn, Liam . (n.d.). Accessibility Tips. Available: http://htmlhelp.com/design/accessibility/tips.html.

Last accessed 24th Oct 2010.
Quinn, Liam . (n.d.). Why write accessible pages. Available:

http://htmlhelp.com/design/accessibility/why.html. Last accessed 24th
Peck, Nigel. (2002). An Introduction To Accessible Web Design. Available:

http://articles.sitepoint.com/article/accessible-web-design. Last accessed
Unknown. (n.d.). Web Accessibility. Available:

http://webdesign.about.com/od/accessibility/Web_Accessibility.htm. Last accessed 24th Oct 2010.
Unknown. (2010). Browser Statistics. Available:

http://www.w3schools.com/browsers/browsers_stats.asp. Last accessed 24th Oct 2010.
BBC. (2007). UK 'slow' on ultra-fast internet. Available:

http://news.bbc.co.uk/1/hi/technology/7112373.stm. Last accessed 24th Oct 2010.
Patterson, Richard. (2008). Average UK broadband speed under 3 Mb. Available:

http://www.broadband-expert.co.uk/blog/be-broadband/average-uk-broadband-speed-under-3-
mb/7757. Last accessed 20th Oct 2010 .
Unknown. (2010). Supporting Multiple Screens. Available:

http://developer.android.com/guide/practices/screens_support.html. Last accessed 24th Oct 2010.
Unknown. (2010). Screen Sizes and Densities. Available:

http://developer.android.com/resources/dashboard/screens.html. Last accessed 24th Oct 2010.
Unknown. (2010). User Interface Guidelines. Available:

http://developer.android.com/guide/practices/ui_guidelines/index.html. Last accessed 24th Oct 2010.
Dolson, Joe. (2007). Improving Accessibility through Typography. Available:

http://accessites.org/site/2007/06/improving-accessibility-through-typography/. Last accessed 24th
Oct 2010.
Ofcom. (2010). Communications Market Report. Available:

http://stakeholders.ofcom.org.uk/binaries/research/cmr/753567/CMR_2010_FINAL.pdf
Ethan Watrall, 2008. Head First Web Design. 1 Edition. O'Reilly Media.

Public Driven Highways Maintenance Reporting System: Feasibility Study

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Public Driven Highways Maintenance Reporting System: Feasibility Study

Hochgeladen von

Copyright:

Verfügbare Formate

Feasibility Study

Public Driven Highways

Within this document you will find;

o Project Initiation Document

o Appendices – Research Conducted

 Technical Research – C Whiting

 Google API Research – A Dixon

 User Interface Research – A Williams

Public Driven Highways

Initiating Author: U0960625 CJ Smith

Date Version Description Changed by

16/10/2010 1 Initial Project Brief CS

Basic requirements of the system are:

2.2 Critical Success Factors

3.2 Logical Scope

3.3 Temporal Scope/Phasing

3.4 Related Projects

4. Risks, Constraints and Assumptions

 Team conflicts including disagreements with workload or effort.

5.2 Roles & Responsibilities

 Managing and leading the project team.

Title Systems Design and Development (SDD)

 Assisting other developers in the group on matters of programming and code

Title Research and Algorithm Development (RAD)

 Creates test plans.

Title Interface Design and Development (IDD)

 To ensure all interfaces are easy to use.

6.1 Issue Control

6.2 Change Control

6.3 Quality Assurance

6.4 Financial Control

6.5 Information Management

7.2 Management Reporting

Stakeholders Expected Communications Frequency Media

Development Documentation and standards In line with plan Central repository,

In order to incorporate unforeseen circumstances we have planned in contingency time in order to

9.2 Milestone Plan

Mile Stone Report - MS Project

Google API Research

How/where would it be used

How it would interact with the system.

Google Maps Data

Google Directions API

Google Geocoding API

Google Maps Javascript API

Alternatives to Google Maps

How Feasible Using Google Maps is

Henry, Shawn Lawton. (1994-2010). WAI Guidelines and Techniques. Available:

Henry , Shawn Lawton and McGee, Liam. (2010). Accessibility. Available:

Quinn, Liam . (n.d.). Accessibility Tips. Available: http://htmlhelp.com/design/accessibility/tips.html.

Quinn, Liam . (n.d.). Why write accessible pages. Available:

Peck, Nigel. (2002). An Introduction To Accessible Web Design. Available:

Unknown. (n.d.). Web Accessibility. Available:

Unknown. (2010). Browser Statistics. Available:

BBC. (2007). UK 'slow' on ultra-fast internet. Available:

Patterson, Richard. (2008). Average UK broadband speed under 3 Mb. Available:

Unknown. (2010). Supporting Multiple Screens. Available:

Unknown. (2010). Screen Sizes and Densities. Available:

Unknown. (2010). User Interface Guidelines. Available:

Dolson, Joe. (2007). Improving Accessibility through Typography. Available:

Ofcom. (2010). Communications Market Report. Available:

Das könnte Ihnen auch gefallen