Project Title: Campus Connect
Start Date: mm/dd/yyyy
End Date: 6-18 months after the start date
Project Manager:
Project Sponsor: Sunflower Software of Kansas
Customer: UMKC Campus Welcome Center
Users: Prospective UMKC Students and their parents
Purpose (Problem or opportunity addressed by the project):
Prospective students and their parents often visit the UMKC campus to learn more about
the University before applying. One of the best ways to experience the sights and sounds
of UMKC is to take a walking tour of the campus. During the day the UMKC Welcome
Center offers personal tours of the campus. However, these tours have to be scheduled in
advance and can be cut short or cancelled by
inclement weather. Visitors are always
welcome to roam alone, possibility with the
aid of a map, but that can be cumbersome and
confusing.
The purpose of this project is to provide an
alternative to the guided walking tour for
learning about the UMKC campus. We
envision giving visitors a GPS enabled device
that they carry with them as they stroll the
campus. As they come into the vicinity of a
building or notable structure, the GPS device
will provide a brief audio introduction to the
building or structure.
A second problem or opportunity address by
the proposed project is more indirect and
subtle. The number of high-school students
entering math and science in the US is
dangerously low compared to other countries. The US risks loosing its competitive edge
unless more high-school students pursue careers in math and science. An innovative use
of technology as described here might persuade some visiting high school students to
pursue a career in information technology.
Goals and Objectives: The general goal of the project is to create software that will turn
an ordinary GPS-enabled Pocket PC into a portable campus tour guide. More
specifically:




The device should be useful. It should educate and inform visitors about the campus
and more generally the university.
The device should be convenient and easy to use. It should require no prior
computer experience and be usable after a brief 1-minute introduction. Use of the
device should not cause frustration or confusion.
The device should offer at least two modes: a location sensitive narration mode and
a “rainy day” mode. In the location sensitive mode the user will carry the device as
he or she walks the campus and the device will provide audio narration on buildings
and structures in the immediate vicinity of the user. In the rainy day mode users
comfortable using the PDA's stylus can scroll a map of the campus and click
buildings and structures to get the same audio information that is delivered during
an actual walking tour.
The application should demonstrate the ability to deliver a personalized experience
tailored to such things as the temperament and language preference of the user. In
the initial release (the project defined by this project charter) it's enough to
demonstrate this capability without fully implementing it for the full range of user
preferences. The design and implementation should make it easy to fully implement
this feature in the future.
Schedule Information (Major milestones and deliverables): The following milestones
are planned. The dates are very rough estimates. They should not be made public outside
of the immediate project team. Rough estimate for project duration is 6-18 months. The
schedule below is based on a 12-month project life cycle.
mm/dd/yyyy - Project Charter Approved
mm/dd/yyyy - Preliminary Requirements Complete
mm/dd/yyyy - Product Feature Set Baselined
mm/dd/yyyy - Preliminary Project Plan Complete
mm/dd/yyyy - Candidate Architecture Complete
mm/dd/yyyy - Technical Risks Resolved (Deliverable: technical prototype
that demonstrates programming elements needed to implement desired
functionality)
mm/dd/yyyy - Iteration #1 Complete
mm/dd/yyyy - Architecture Complete
mm/dd/yyyy - Iteration #2 Complete
mm/dd/yyyy - Iteration #3 Complete
mm/dd/yyyy - User Guide and System Administration Manual Complete
mm/dd/yyyy - System Test Complete
mm/dd/yyyy - Product Released
Financial Information (Cost estimate and budget information): The initial project
budget is $10,000. The project manager and lead programmer are being compensated for
their efforts with a 10% equity stake (each) in the final result. They will not draw a salary
from the main project budget.
Project Priorities and degrees of freedom: There is very little elasticity in the schedule
and budget. The project end date is fixed because the project manager and lead
programmer will be transferring to a new project on mm/dd/yyy. Regarding the budget,
no new funds are expected. However, if the results of early iterations show promise, it
may be possible to secure additional funding. There is very little flexibility with respect
to quality. The software must be easy to use and reliable. In a worst-case scenario,
maintainability and evolvability may be compromised if it’s the only way to have all
high-priority features implemented by the absolute end date.
Approach: An iterative and incremental approach is planned. The highest priority
features will be implemented first such that after the first iteration there will always be a
usable product. Speculative architecture and design will be kept to a minimum. No
iteration will favor technical “infrastructure” over usable functionality.
The programmers have little experience with the technologies being used. This creates
significant technical risks (outlined below). In order to resolve these risks in a timely
manner, a "technical prototype" will be created early in the project (see schedule
information above). The technical prototype may not have any usable product
functionality but it will exercise programming constructs needed for the actual
implementation. Among other things, it will demonstrate reading current longitude and
latitude from the GPS device, scrolling an image in a picture box, and playing an audio
file in a separate thread.
Constraints: The final solution should not rely on any third-party licensed software
(beyond the operating system). We want to maintain distribution flexibility and minimize
dependencies and added expense.
Assumptions: We assume that the customer and a few of the users will be available to
participate in 1-2 initial requirements gathering meetings. We also assume that the
customer will be available during the requirements phase to answer questions.
Turnaround time on questions should be no longer than 2 days. Feedback on all three
iterations is needed from both the customer and user representatives.
The Welcome Center will provide appropriate written material on campus buildings and
structures. The project team will create audio narrations based on this written material.
The device does nothing to ensure its own physical security. The person or organization
loaning the device is responsible for the device's physical security.
On the technical side, we assume the device isn't required to work from a car, indoors, or
under an enclosed structure such as a sheltered walkway.
Success Criteria: Product success is defined in a separate document titled: Campus
Connect Product Success Criteria. In short, a user satisfaction survey will be used to
determine product success. A survey will be given to a group of impartial testers of
various skill levels. If the aggregate survey feedback score from all testers is above a
certain threshold (specified in the document), the product will be deemed a success.
The overall project will be deemed a success if the product success criteria is met by the
scheduled project end date without exceeding the allocated budget.
Scope: Adding and editing content on campus structures may require a programming
change. The application isn't required to provide a simple user interface for updating
content.
As mentioned in the goals section above, the delivered product should demonstrate the
ability to deliver content tailored to the user’s preferences, but a complete
implementation of this feature is beyond the scope of the current project.
Risks and obstacles to success: The programming staff has little experience developing
Pocket PC apps with the Compact Framework. They are also unfamiliar with interfacing
with a GPS receiver. We are assuming they can become familiar with the programming
environment and technologies during the first few months of the project. This lack of
first-hand experience also makes it difficult to estimate programming effort with any
precision.
There may not be enough memory on the device to hold all of the audio content at the
desired quality level.
The solution almost certainly will require a multi-threaded implementation. Debugging a
multi-threaded program is difficult and unpredictable. One or two hard-to-find defects
could easily extend the testing phase beyond the scheduled project end date.
Signatures
__________________________________
Project Manager
__________________________________
Project Sponsor
__________________________________
Customer
__________________________________
Technical Lead