Project Plan for Campus Locator

Iowa State University Senior Design May04-04Faculty Advisors: Dr. John Lamont & Prof. Ralph Patterson III

Client: Iowa State University

Justin Davis – Team CaptainGuy Howard - Communications

Rachel HadawayJustin Gruca

Submitted: October 13, 2003

Table of Contents

Revision History...................................................................................................................iTable of Contents................................................................................................................iiList of Figures.....................................................................................................................ivList of Tables.......................................................................................................................vIntroduction..........................................................................................................................11.1 Abstract....................................................................................................................11.2 Problem Statement...................................................................................................11.3 Operating Environment...........................................................................................11.4 Intended Users and Intended Uses...........................................................................11.4.1 Proposal Report...................................................................................................11.4.2 Specifications Report for Implementation...........................................................21.5 Assumptions and Limitations..................................................................................21.5.1 Assumptions........................................................................................................21.5.2 Limitations...........................................................................................................21.6 Expected End Product & Other Deliverables..........................................................22 Proposed Approach..................................................................................................42.1 Functional Requirements.........................................................................................42.1.1 Feasibility Studies................................................................................................42.1.2 Client Research....................................................................................................42.1.3 Recommendations................................................................................................42.2 Constraints Considerations......................................................................................42.3 Technology Considerations.....................................................................................42.4 Technical Approach Considerations........................................................................52.5 Testing Requirements/Considerations.....................................................................52.6 Security Considerations...........................................................................................52.7 Safety Considerations..............................................................................................52.8 Intellectual Property Considerations........................................................................52.9 Commercialization Considerations..........................................................................52.10 Possible Risks and Risk Management.....................................................................52.11 Proposed Milestones and Evaluation Criteria..........................................................62.12 Project Tracking Procedures....................................................................................63 Statement of Work...................................................................................................73.1 Review Prior Research............................................................................................73.2 Plan New Interviews................................................................................................83.2.1 Develop Contact List...........................................................................................83.3 Prepare for Interviews............................................................................................103.3.1 Questionnaires and Scripts................................................................................103.3.2 Personnel............................................................................................................123.4 Conduct Interviews................................................................................................133.4.1 Scheduling.........................................................................................................133.5 What CAN be done?..............................................................................................133.6 Follow-up Contact.................................................................................................133.7 Technology............................................................................................................143.7.1 Infrastructure......................................................................................................14

Page i

3.7.2 Maintenance Interface.......................................................................................143.7.3 Mapping.............................................................................................................143.8 Deployment............................................................................................................173.8.1 Fixed-Base.........................................................................................................173.8.2 Portable..............................................................................................................183.8.3 Methodology......................................................................................................193.9 End-Product: Requirements Report......................................................................203.10 End-Product: Proposal Report..............................................................................204 Resources...............................................................................................................214.1 Personnel................................................................................................................214.2 Financial Requirements.........................................................................................214.3 Deliverable Schedule.............................................................................................224.4 Working Schedule.................................................................................................235 Closure Materials...................................................................................................255.1 Project Team Information......................................................................................255.1.1 Client Information.............................................................................................255.1.2 Faculty Advisors................................................................................................255.1.3 Team Information..............................................................................................255.2 Closing Summary..................................................................................................255.3 References..............................................................................................................26

Page ii

List of Figures

Figure 1: Mapping on a Laptop........................................................................................14Figure 2: Direction finding on a GPS unit........................................................................15Figure 3: Real time location with a GPS unit...................................................................15Figure 4: Image rendering using a PocketPC...................................................................16Figure 5: Deliverable Schedule First Semester................................................................22Figure 6: Deliverable Schedule Second Semester............................................................22Figure 7: First Semester Schedule....................................................................................23Figure 8: Second Semester Schedule................................................................................24

Page iii

List of Tables

Table 1: Personnel Hours..................................................................................................21

Page iv

List of Definitions

3G Cell Phone: This is any cellular phone which is capable of high speed internet access, has a color screen, and is capable of running basic Java applications

Java: A modern standard computer programming language, which allows a single version of a program to run on many different types of devices.

Map Node: The code based representation of an intersection of sidewalks, streets, or other items such as utilities.

TabletPC: A new type of laptop computer, which uses a pen instead of a mouse and keyboard. Rather than being hinged and folding up, the screen is placed where the keyboard would be found on a traditional laptop.

SBB: (System Being Built) references the long term deliverable product generated by future design teams, or more simply, the actual campus locator system.

Page v

Introduction

1.1 Abstract

Iowa State University, being a large campus, would do well to implement an on-campus locator system. Right now it is very up in the air regarding how this system would take shape. Some factors include who would use it, how it could be used, and what hardware would be necessary. Because there are so many considerations, a senior design team, familiar with the process of software engineering, has been chosen to study the feasibility of such a system. They plan to thoroughly investigate all possible users and uses of an on-campus locator system, by first researching possible interested groups, and then interviewing representatives from those groups. Based on the interviewees input, the team’s own opinions and experiences, and research on various types of hardware, the team will prepare two reports on their findings. Each will be written for a different audience and have different purposes. The first, a proposal report, will be targeted at an administrative audience, to explain the system to them. The other, a specifications report, is aimed at the team that actually designs the system.

1.2 Problem Statement

Iowa State has received offers to design and implement an on-campus locator system, but the research into its feasibility is not there yet. A formal study of the requirements of such a system must first be completed. The team must use the knowledge of software engineering and the requirements process to elaborate and specify the design of a locator system.

1.3 Operating Environment

Currently, the operating environment is projected to be the World Wide Web, personal digital assistants, indoor/outdoor kiosks, and CD-ROMs.

1.4 Intended Users and Intended Uses

The deliverables for the team will be two reports. Each report will be tailored to a different audience (users) who will glean different information from each (uses). The following sections elaborate who these users are, and how they would use the report(s).

1.4.1 Proposal Report

The following is a list of people who would want to read the proposal report, including why they would read it.

The people who will fund the system, to decide if it is worth their money

Page 1 of 27

People who would consider implementing the system (admissions, et al), to decide if they want to use it

Anyone who wanted to learn about the system, because they need/want to know what is going on at Iowa State University

1.4.2 Specifications Report for Implementation

The following is a list of people who would read the specifications report, and what information they would get from it.

The team that will actually build the system, to know what is required of them

Users of the proposal report who want more technical info, to get the information they seek

1.5 Assumptions and Limitations

In any project it is helpful to have some boundaries before beginning. Assumptions are things that the entire group can agree upon as given. Limitations are factors that shape the scope of the project and are out of the group’s control.

1.5.1 Assumptions

The following is a list of items the group will use as a starting point for all further work.

There is an interest in implementing an on-campus locator system by one or more campus groups

There will be ways of funding this system

The readers of both reports will be able to read English

The users of the technical report will be skilled in the language and principles of software engineering

Other senior design teams will come after this team to carry on the actual implementation after they have finished the specs.

1.5.2 Limitations

The following are some constraints the group sees as placed on the project.

The team doesn’t know how much funding will be available for various implementations of the system.

They don’t know what the updatability of the system will be (how to account for demolished or newly constructed buildings)

Page 2 of 27

The team will have a limited time to complete the research – until May 2004

1.6 Expected End Product & Other Deliverables

The end product of this project will be two reports. One will be along the lines of a requirements document, but more fully a specifications document. The senior design team will tailor this document to a technical audience, specifically the team that comes after them to build the campus locator system. This report will contain the technical requirements of the system, specified in software engineering terminology.

The other report the group will create is a proposal report. This will be given to the people who have a non-technical interest in an on-campus locator system, such as those who might fund or implement it. The purpose of this report is to package or sell the on-campus locator system ideas to a wide audience. This report will contain examples of end-users of the system, to show the readers how the system will actually be used once it is implemented. It will also explain how the system will benefit the ISU community.

Page 3 of 27

2 Proposed Approach

2.1 Functional Requirements

This project is atypical in that the end result will be a specifications document, rather than a physical product. This project plan will be composed of a number of items, and chief among them will be feasibility studies, client research, and recommendations for future projects.

2.1.1 Feasibility Studies

The team will approach the project from the aspect of “how can it best be done”, followed by determining which is the best way it can be done. This includes looking at the technologies available, the practicality of doing the work needed, and the amount of time necessary to do the work. Included will be a general overview of the available and useable technology products for the project, as well as group recommendations. Additionally, cost projections for materials and labor will be included.

2.1.2 Client Research

The project has a number of expectations already, but the list of those expectations is incomplete. As such, a list of campus entities that may be able to make use of the final product will be compiled. Also, the group will be conducting interviews with those that are interested, in an effort to get a better idea what the project needs to do to be most effective and have the widest appeal.

2.1.3 Recommendations

Following the preceding two portions will be specific recommendations on the project, based on collected data. This may include breaking the project up into several subprojects; the creation of an ongoing project; or even whether or not labor should be contracted out for portions.

2.2 Constraints Considerations

As the deliverable for this product is a report, the only constraints will be the resources needed to produce the document. These include the amount of time available to be spent, available interviewees/contacts, and considerations for the audience.

The system being specified in the report will have a number of constraints, which will be investigated in the course of research for the document. These will likely include costs, technology, and management logistics.

Page 4 of 27

2.3 Technology Considerations

Again, as the deliverable is a report, them main considerations with regards to technology are almost entirely word-processor based. Other technology used in the creation of the reports may include the SourceSafe versioning system. Since there are four people in the group, all constantly adding to and improving the group’s documents, it is important that they have a way to track these changes.

2.4 Technical Approach Considerations

In collecting data to include in the report, there may be testing of various technologies to determine if and how they could be used for the project. Research methods will include Internet research and email correspondence, both necessitating a computer and an network connection. For interviews and follow-up interviews, the use of a voice recorder to keep an account of questions and answers for reference is likely. Additionally, various software may be used to best divide human resources for the report.

2.5 Testing Requirements/Considerations

The deliverable reports will be tested in the form of proofreading and review. Reviewers will include fellow student engineers, English Professors, as well as friends of the team who are not technically inclined. This review will consider the target audience, readability, and usability from the perspective of the end users. Based on this feedback, the report will be revised to address the issues found.

2.6 Security Considerations

The group uses a small fileserver to share files and resources, as well as host the versioning system. This server has been put behind a password as a security precaution. The SBB will require a significant security policy to be in place. Justin Davis will discuss this policy with Thomas Daniels as a possible future project for his students in “CPRE 531: Information System Security”

2.7 Safety Considerations

The deliverable will have no safety concerns, though all printed materials produced by the group will be laser printed, to avoid unsafe smearing at high moisture levels.

Naturally, the system described in the report will have safety considerations, but those are outside the scope of this plan.

2.8 Intellectual Property Considerations

There was a previous project based on the same premise as this one, and it may be used for inspiration and/or information. As such, it will be important that each instance of use is properly cited. Also, the report will be cited in future projects, so it is important to have all steps covered. The report should remain internal to Iowa

Page 5 of 27

State, though its status as intellectual property may mean little if a similar project is produced publicly.

2.9 Commercialization Considerations

The report’s subject may have possible commercialization opportunities, but the report itself will not. It is a document meant for possible clients to read and use as a decision-making tool.

2.10 Possible Risks and Risk Management

Risk management remains a part of planning; “backup plans” for such cases as time-related problems, unavailable group members, difficulties with computer lab access, unmet goals, and behind-time deliverables are in place.

2.11 Proposed Milestones and Evaluation Criteria

Evaluation criteria will be dependent on the completion and quality of the following milestones:

Completed review process of the project planThis milestone will have been achieved when all planning activities, including client review of the plan have been completed.

Interview planThis milestone will have been achieved when all plans for interviews have been made, including the list of who will be contacted, what questions will be asked, and the general techniques for interviewing each group have been determined.

Finished interview processThis milestone will have been achieved when all interviews have been completed. This includes compilation of all data from the interviews, intermediate analysis, as well as follow-up interviews.

Implementation/technology researchThis milestone will have been achieved when a significant portion of the hardware and software on the market has been investigated, and further investigation is yielding diminishing amounts of information.

Deployment recommendationsThis milestone will have been achieved when the team has combined all data collected from the interview process with the research of hardware and software technologies. This includes that portion of the deliverable reports which states the order in which features will be deployed, and what hardware platform will be used for deployment.

Methodology recommendations (languages, project dependencies)

Page 6 of 27

This milestone will have been achieved when the team has determined the recommended steps to be taken by future teams. This includes concurrent and dependent projects and suggested approaches to the design of the infrastructure.

2.12 Project Tracking Procedures

Group tracking procedures will be handled by project management software – specifically, Microsoft Project. Time estimates, team member project assignments, and schedules are all entered into the program. When tasks are completed, each portion of the task is marked as such in a checklist-like format. Hours required to complete the major tasks will be entered into the program so it may be used to show how well the project is meeting schedule for both time spent, and calendar time.

Page 7 of 27

3 Statement of Work

The work involved in this project is unconventional compared to traditional senior design projects. The end-product produced by this project shall be documents regarding the feasibility, and requirements of a system. This project is NOT building the product being described as the SBB, that task is left to future design teams

3.1 Review Prior Research

Objective: Since this project has been attempted previously, the information obtained should be reused to the extent applicable.

Approach: Using guidelines set by the client, review the final report produced by the previous project, recording relevant items which the team is presently unaware. The former project may be consulted at various points during the project, to make certain all previously collected data is not lost, and research does not have to be repeated.

Expected Results: The team should be provided with an initial point, from which research may be based. The team will also have a preliminary list of contacts for interviews, as well as possible uses to suggest to future contacts when brainstorming. The team will be able to recognize the need for very detailed information, which will assist in the project production.

Page 8 of 27

3.2 Plan New Interviews

This task is made up of two sub-tasks, Develop Contact List, and Prepare forInterviews

3.2.1 Develop Contact List

In developing a list of individuals to contact, several considerations must be made. Ideally, all groups would be represented, however time would not permit this. In order to obtain information as valuable and representative as possible, individuals of four main categories will be considered. This section has been divided into four sub-tasks, one for each category of individual to be interviewed.

3.2.1.1 Consideration of Departments

Objective: Each Department may have additional input for the project, and the departments being interviewed must be as diverse as possible.

Approach: Since time is limited, not all departments are able to be contacted for interviews. The design team will consider various criteria in selection of departments to interview. At least two departments from each college, as well as each major geographic location of campus must be selected.

Expected Results: The list of departments which must be contacted may be substantially decreased from the University directory. The team will have a group of contacts, which is diverse enough to represent most on campus users of the system.

3.2.1.2 Prioritize Campus Organizations

Objective: Many campus organizations may have differing interests. The organizations must be prioritized with regard to overall university impact, and which organizations must be contacted.

Approach: Campus organizations must be analyzed with regard to the type and purpose of the organization. The impact of the organization upon the overall university must be considered. In example, persons in the Cyclone Amateur Radio Club represent a very select type of individual and would provide less than ideal data. On the other hand, the Ames Area Free Unix Group, which includes many non Iowa Staters could serve to provide invaluable data to how the system might be used.

Page 9 of 27

Expected Results: A list of campus organizations which provide a diverse representation of the ISU community, while encompassing the majority of those who might use the system.

3.2.1.3 Student Clubs

Objective: Identify student clubs which may have an interest in using the system, or may contain members wishing to have direct involvement in the development of the system.

Approach: E-Mail consultation with club officers to provide information to users of the system. The club may be of the type which members could provide design and technical support to the design team, as well as user preferences. While unable to offer diverse data for usage, the Cyclone Amateur Radio Club may provide excellent advice for methods of direction finding to the end design team, and other clubs likely have similar interests and expertise.

Expected Results: Significant effort will be required by the team building the final product. Many clubs wish to get their name out, and show some community involvement, and the clubs might be willing to assist the future design team in their implementation of the project.

3.2.1.4 Third Party Involvement

Objective: Identify those persons within the ISU community which may not directly be affiliated with ISU, which would have a strong interest in such a project. These organizations may include businesses surrounding ISU.

Approach: The businesses in Campus town should be contacted regarding the possible development of a campus locator system. They should be asked as members of the community, what they would like Iowa Staters to know, and how they might be involved in such a system

Expected Results: This task is likely to yield significantly biased information. However, if a business takes an interest in the system, the business might prove an excellent source of sponsorship for the implementation of the project. Having an influence in the early stages is likely to shine with those who consider donations.

The information obtained from this task will not be used in the initial version of the Campus Locator. The information will be used in the consideration of infrastructure requirements for the Campus Locator system, and the items necessary to add features such as advertising at a later date.

Page 10 of 27

3.3 Prepare for Interviews

The task of interview preparation has been divided into two subtasks, developing the questionnaires or scripts to be used during the interviews, and determination of which team members are best suited to conduct such an interview.

3.3.1 Questionnaires and Scripts

The questionnaires and/or scripts to be used during interviews should be made generic for most cases. Exceptions do exist, since certain organizations will have significantly more input for the end product. The questionnaires must be tailored to the organization behind the person being interviewed.

3.3.1.1 Organization being Interviewed

Objective: Questions and interview scripts should be tailored to the organization being interviewed.

Approach: When forming questions to ask, biases of the individual or organization must be carefully worded to eliminate such biases to the extent possible. The questions must be carefully worded to avoid making any negative impressions of the Electrical and Computer Engineering Department.

Expected Results: By carefully preparing for interviews, more valuable information may be obtained from each organization, saving time for the organization as well as the team.

3.3.1.2 Users

Objective: To format questions such that the information requested is understood. The type of users within the organization should be generically considered to assist with the types of questions to be asked.

Approach: Identify the type of user likely to be involved in the organization. The users may be highly technical, of moderate technical ability, or completely non-technical.

Expected Results: The interviews will run more smoothly if terms do not have to be explained. The interviewee will be more receptive to the interviewer if he or she feels comfortable with the questions which are being asked.

Page 11 of 27

3.3.1.3 Features

Objective: Features should be suggested, in order to provoke thought which leads to other feature ideas from the interviewee.

Approach: Previously suggested features should be suggested in terms the individual understands.

Expected Results: New feature suggestions will be made, which have not been previously considered. These suggestions may or may not be possible to implement, and must be prioritized.

3.3.1.4 Benefits to the Organization

Objective: Obtain rational information behind feature requests. This information will be needed in order to solicit University wide support for features to be implemented.

Approach: Those selected for interviews must be knowledgeable of the needs of the organization. When suggestions are made, interviewers must be prepared to obtain the “whys” for implementing the suggestion.

Expected Results: The team will obtain the information necessary to create a request for proposal. The project will require a significant investment from the University, and documents must show how the project will help the university.

3.3.1.5 Future Investment

Objective: To determine if the organization is willing to invest in the future of the project.

Approach: Ask the organization, if required, what support they might be able to offer to the project. Such support may be provided in many forms, such as data collection, and is not limited to financial support.

Expected Results: The project, if implemented will require continuous maintenance to be of future use. This might come to require significant data resources, which an individual organization is ill-equipped to collect.

3.3.1.6 Update Process

Objective: To determine how the update process should function to incorporate the needs of the organization.

Approach: Based on features requested by the organization, the organization should be asked how frequently the data supporting the feature would change.

Page 12 of 27

Expected Results: This information will give the team a minimal concept of the infrastructure required to provide the feature to the system.

3.3.2 Personnel

Determination of which personnel to assign to which organization being interviewed must examine three criteria, each of which is defined under the subtasks below.

3.3.2.1 Team Member Affiliations

Objective: To assign team members to interviews based on the organizations that team member has a direct affiliation.

Approach: The team members provide a list of campus clubs and organizations with which they are involved. Those who have an involvement with an organization are placed on higher priority to interview that organization.

Expected Results: The individual from the organization being interviewed will feel more comfortable in the interview. Ideas which the individual might have reluctance to divulge are more likely to be stated to someone who is familiar.

3.3.2.2 Team Member Biases

Objective: Each team member has his or her own political, and social biases. By factoring these biases into interview assignments, these biases may be used to solicit additional information from the organization.

Approach: Finding common ground amongst interviewers and interviewees. Team members representing a minority culture should interact with clubs focusing within that culture. Gender biased organizations should be accommodated within the means of the team by biasing the interview team.

Expected Results: Recognizing common desires, team members as well as interviewees are more likely to yield valuable information. The chances of mistakes being made which might offend a culture are reduced.

3.3.2.3 Team Member Work-Load

Objective: Determine the amount of work each member of the team is performing, and attempt to keep it balanced.

Approach: Managing time using Microsoft Project, the task becomes trivial.

Expected Results: Team members should not be as likely to become overworked, and unable to effectively participate on the team.

Page 13 of 27

3.4 Conduct Interviews

Conducting the interviews, for obvious reasons will require more work in the area of scheduling than time spent conducting the actual interview.

3.4.1 Scheduling

Objective: Schedule interviews to be conducted

Approach: Using a group calendar of available times, find a time where team members are available to interview with the organization. Offer these available times to the organization, and allow them to decide upon the time of the interview.

Expected Results: The team is able to obtain information without placing unnecessary burdens upon the organization being interviewed.

3.5 What CAN be done?

Objective: Using the team engineering experience and knowledge, prioritize the features based on the feasibility of the feature.

Approach: Using research of technology, deployment methodology, and reasonable resource expectations for an implementation team, determine the priority of the features.

Expected Results: A brief description of what the system is capable of performing, as well as those requested features which it may not.

3.6 Follow-up Contact

Objective: By conducting follow-up interviews, and presenting the conclusions from 3.5, prioritization errors may be identified.

Approach: If possible, e-mail 3.5 to the organizations, reminding them of features they requested, and those which could not be included. Ask if the system would be useful if implemented in the proposed fashion.

Expected Results: The organizations are likely to be much more understanding of the final product. Prioritization errors which may have been made by the team will be discovered, and may be corrected before the wrong actions are taken by the implementation team.

Page 14 of 27

3.7 Technology

The following sections detail the technological issues will likely have to be addressed during the course of the project.

3.7.1 Infrastructure

Objective: For this project to succeed, the system will need to be accessible from virtually anywhere on campus. Any kind of real-time map software is fairly useless if it can not be accessed at any time and any place within its range. This will require significant infrastructure and a significant monetary investment.

Approach: The team will first try to get the necessary investments from campus organizations and university administration. Then, the team will decide on an implementation based on the funds the team receives. If possible the team will use existing wireless access points around campus to transmit necessary data.

Expected Results: The system will be usable and completely accurate from any position on campus, and show a map of the campus when the user is away from an access point. The map will be the one the system had when it last had access to the network.

3.7.2 Maintenance Interface

Objective: Buildings and roads are constantly being built, modified, and destroyed. For our system to be useful for more than a few months, it must be able to easily adapt to these changes. If the adaptation is not easy, the system will not be maintained. Customers will not be willing to pay higher prices to update it.

Approach: Decide on a method of maintenance that requires minimal effort from one or two people for one or two days per year. If the system can be maintained this easily, customers will not mind allocating these resources to the task.

Expected Results: The system will be maintainable easily and the university will assume the role of maintenance after the project is completed.

3.7.3 Mapping

Objective: The system must maintain an accurate campus map. This map must make it feasible to use Djikstra’s shortest path algorithm in real time, or the Floyd-Warshal algorithm in batch mode.

Page 15 of 27Figure 1: Mapping on a Laptop

Approach: The team will speak with individuals in the computer science and engineering departments about the best methods of mapping. The team will also research various mapping technologies and, by combining both sources, decide on a mapping method.

Expected Results: The system will be capable of computing path length algorithms, as well as plotting a course onto a user version map through the use of “map nodes”

3.7.3.1 Direction Finding

Objective: The system will quickly find shortest routes, most scenic routes, historical landmarks, most indoors routes (for bad weather days), and any other type of route requested by the users.

Approach: Well documented graph algorithms will be used to find routes requested. Graph study has been an important topic in many years and graph algorithms are very refined. There is no reason not to use existing algorithms.

Expected Results: The system will expeditiously return results of any query a user makes. This will make the system easy to use and convenient, as time is so important to college students.

3.7.3.2 Real-Time Location

Objective: A user should be able to stand anywhere on campus, activate the system, and get a map of his/her surroundings within seconds.

Approach: This will be dependent on the infrastructure of the system. If the team can build a strong infrastructure,

whenever a device is activated, the infrastructure will locate the device and then compare that with the map to find the user’s location.

Expected Results: Suggested methods for obtaining the user’s location will be enumerated to the follow-up design team. Location data may be provided for

Page 16 of 27

Figure 2: Direction finding on a GPS unit

Figure 3: Real time location with a GPS unit

objects in motion, such as buses, to inform students if buses are behind schedule. Technology may include GPS, Cell-Phone Location Service, Wireless Access Point (WAP) Triangulation, or custom hardware.

3.7.3.3 Image Rendering

Objective: The user should be able to point the device at any building on campus and see that building’s name as well as a picture of it, as illustrated in Figure 4. Information such as a map of the building and historical facts may also be displayed.

Approach: Using the real-time location feature mentioned above, and finding the direction that the user is pointing, the system will know what building you are pointing to. It will then access the applicable data for that building.

Expected Results: The user has a reliable method of finding out the name of a

building even when he/she is not near the name plaque, as well as interesting data about a building.

Page 17 of 27

Figure 4: Image rendering using a PocketPC

3.8 Deployment

The following sections list the methods of deployment for the system.

3.8.1 Fixed-Base

The fixed-base sections are stationary objects that will be placed on campus.

3.8.1.1 Permanent Signs

Objective: Have large stationary maps available to users as they walk around campus such that students without a laptop, PDA, or other portable device may still utilize the minimum functionality of the system without any interface.

Approach: Place stationary screens in highly traveled areas on campus. These signs will act as maps. The team will explore cost during interviews with customers and make a decision about whether these are feasible.

Expected Results: There will be permanent signs, similar to the campus maps that are in place now, but these signs will be dynamic monitors (LCD screen? Plasma?) that will change to show the campus as a whole and the surrounding area.

3.8.1.2 Kiosks

Objective: Create terminals around campus that are accessible to users at all times.

Approach: This will be similar to the permanent signs. The main differences are that these will be smaller and will have an interface for users. They will be similar to the computers on campus that allow students to use AccessPlus. There will also be considerations for weather conditions. These computers will be exposed to very extreme weather conditions during the course of a year, and there will have to be a method of dealing with this.

Expected Results: The system can be used with a minimal user interface. This will allow users to get customized data, without having to deal with the overhead of the full version of the system.

3.8.1.3 Lab PCs

Objective: Make the system available from PCs in most, if not all, computer labs around campus.

Approach: This could be done as a web based application, or a standard Windows application. It would probably be best done as a web based application because

Page 18 of 27

installing it on all PCs on campus would be exceedingly cumbersome and probably difficult to maintain.

Expected Results: Users are able to go to any computer lab on campus and access the system. They may then use the system’s full functionality.

3.8.2 Portable

Portable deployment methods are those that the user can carry with them and use at any time to gain access to the system.

3.8.2.1 Cell-Phone

Objective: Allow the user portable access to the system.

Approach: The team will explore the capabilities of cell-phones to find out how much of the system the team can implement on them. The team will also check on implementation costs, as they may be high with such hardware oriented devices.

Expected Results: The user can access some functionality of the system with his/her cell-phone.

3.8.2.2 PalmOS, PocketPC OS

Objective: The user should be able to use his/her Personal Data Assistant (PDA) to access most of the functionality of the system.

Approach: PDAs offer a platform that can easily support functionality nearly equivalent to that of a computer. The team believes that most of the functionality of the system can be implemented on PDAs.

Expected Results: Users can take tours of campus, find routes to classes, find historic sites, and countless others functions. Organizations such as admissions can loan them out to visitors of all sorts for self-guided tours.

3.8.2.3 Laptop, TabletPC

Objective: Users can carry a portable version of the system, even if they don’t have access to a PDA.

Approach: This will be much the same as the approach for a lab PC. Most laptops and tablets have enough processor speed, memory, etc. to implement the full system.

Page 19 of 27

Expected Results: The user has access to a portable version of the software that still has full functionality.

3.8.2.4 Custom Hardware

Objective: Build a customized device to act as a portable version of the system. It would have the size and functionality of a PDA, but it would be designed specifically for this system. This would make it more difficult for the user to exit the system and gain access to something he/she shouldn’t.

Approach: There would have to be a lot of research put into designing a piece of hardware like this. Additional funding would have to be acquired as well. This part of the project is unlikely because it would be so expensive, and the only benefit would be a little bit of usability.

Expected Results: Users would have a system that was a little bit more user-friendly, with the same degree of portability as a PDA.

3.8.3 Methodology

Objective: Decide on a specific set of technologies to use in the implementation of the system. Decisions such as what language to use and how to prioritize the implementation of the portable parts of the system are examples of those that must be made.

Approach: After the team has interviewed possible customers, the team will research available technology and make several decisions based on finances and technological data.

Expected Results: The team will have a prioritized implementation list as well as a recommended list of technologies for future design groups. These groups will have a strong foundation based on the information that the team provides them.

Page 20 of 27

3.9 End-Product: Requirements Report

Objective: Lay down a set of specifications such that when the time comes, this system can be built efficiently.

Approach: The team will research all facets of the projects. This includes things such as organizations willing to invest money, usable technology, and possible implementations to name a few. The team will then produce a document outlining requirements for the system.

Expected Results: The system can be built efficiently with little to no modification to the requirements report produced.

3.10 End-Product: Proposal Report

Objective: Document the feasibility of the project. Analyze the costs and benefits and find potential customers willing to invest in the project. Study the possibility that this system can be completed by a series of senior design groups in the future.

Approach: The team will interview potential customers to get an understanding for the functionality they want. Then, the team will research this functionality to find out the technological constraints on producing the system. Finally, the team will produce a requirements report detailing what must be done.

Expected Results: Future groups will have a strong baseline to start with when building this system. They will have a good idea of where they can get funding and how much funding they can get. They will also have a grasp on a set of technologies that they need to get familiar with to start building the system successfully.

Page 21 of 27

4 Resources

4.1 Personnel

Based on the current workload, the group estimated the number of hours required for each task – as well as the breakdown per-member – shown in Table 1. This estimate is expected to differ significantly from the end result, but it stands as a starting point from which to work.

Table 1: Personnel Hours

4.2 Financial Requirements

This project does not contain any financial requirements. Since the goals of this project are to create documents enabling the creation of the Campus Locator System, the only financial resources required are:

Team member labor (Rates based on prior work experience in industry)

Table 2: Cost of Team Labor

Paper/Ink for printed deliverable documents (Paid by Team through Senior Design Fees and Print Quotas)

Poster ($50, Paid by Team)

Page 22 of 27

4.3 Deliverable Schedule

Figure 5: Deliverable Schedule First Semester

ID Task Name

9 Practice Presentation

10 Final Report

11 IRP Presentation

12 Bound Final Report

13 Final Report to Website

12/17

4/13

4/27

5/5

5/5

9 16 23 30 7 14 21 28 4 11 18 25 1 8 15 22 29 7 14 21 28 4 11 18 25 2 9 16 23 30 6 13Nov '03 Dec '03 Jan '04 Feb '04 Mar '04 Apr '04 May '04 Jun '04

Figure 6: Deliverable Schedule Second Semester

Page 23 of 27

4.4 Working Schedule

Figure 7: First Semester Schedule

Page 24 of 27

Figure 8: Second Semester Schedule

Page 25 of 27

5 Closure Materials

5.1 Project Team Information

5.1.1 Client Information

Iowa State UniversityElectrical and Computer Engineering Senior Design

5.1.2 Faculty Advisors

Dr. John Lamont324 Town EngineeringAmes, IA 50011Office: 515-294-3600Home: 515-292-5541Fax: 515-294-6760Email: jwlamont@iastate.edu

Prof. Ralph Patterson III2215 CooverAmes, IA 50011Office: 515-294-2428Home: 515-232-9933Fax: 515-294-6760Email: repiii@iastate.edu

5.1.3 Team Information

Justin Davis (Captain), CPRE6214 Frederiksen CourtAmes, IA 50010Home: 515-572-7729Cell: 515-451-1156Email: justindd@iastate.edu

Guy Howard (Communications), CPRE1349 Eaton HughesAmes, IA 50012Home: 515-572-2647Cell: 678-778-6093Email: guy2@iastate.edu

Rachel Hadaway, CPRE2300 Mortensen #11Ames, IA 50014Home: 515-292-7296Cell: 515-450-8117Email: rah1@iastate.edu

Justin Gruca, CPRE826 Dickinson Ave #2Ames, IA 50014Home: 515-572-2647Cell: 515-292-1610Email: jgruca@iastate.edu

5.2 Closing Summary

At this point it is important to reiterate that the work of this group will not be to create the on-campus locator system. Their task is to fully research and specify the needs of such a system. Based on current insider information, their work will be very important because it will set in motion a chain of events that can lead to ISU’s becoming the top land grant university in the USA.

This team’s work will prove to be very important. Without a far-reaching study into the requirements of the system, it will not benefit as many end users, and could end up being a waste of everyone’s time and money. It is also crucial that this

Page 26 of 27

system has the support of the administration at ISU, hence the need for the proposal report to sell them on the idea. Finally, the need for the requirements document for the implementation team is substantial, because engineers need to talk to engineers in their own language. The current team will take the needs and wants of the end-users, and turn that into a blueprint for a functioning system.

The team’s plan of action involves talking to groups that might have an interest in this system, researching various types of hardware and software that might be used to implement it, and eventually selecting one or more approaches for the final specifications document. In addition to the specifications document, they will also create a proposal to sell their ideas for the locator system to a non-technical audience.

5.3 References

The report already completed by a previous team of students. This will be used more as a jumping off point, or a source of ideas. The group now wants to go much more in-depth than the past group did..

Iowa State University Directories will be indispensable in looking up contact info for various groups to interview.

Facilities Planning and Management has done extensive mapping of the ISU campus that the team can use in their research.

Page 27 of 27

6 Appendix A: Revision History

Version Date Author Change0.1 9/14/03 JDD Initial Document Framework0.2 9/15/03 JDD First ½ Statement of Work Added0.3 9/16/03 GMH Integration of Team Contributions0.4 9/16/03 JDD General Text Formatting0.5 9/16/03 GMH Completion of Statement of Work0.6 9/16/03 JDD Gantt Charts added to Resources Section, Title Page0.7 9/16/03 RAH Added Final Introduction0.8 9/17/03 JMG Added Final Proposed Approach1.0 9/18/03 JDD Draft Submitted for Review1.1 9/23/03 JDD Unbound Copy submitted for Grading1.2

Page 28 of 27