Develop Contact List
Upcoming SlideShare
Loading in...5
×
 

Develop Contact List

on

  • 415 views

 

Statistics

Views

Total Views
415
Views on SlideShare
415
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Develop Contact List Develop Contact List Document Transcript

    • Project Plan for Campus Locator Iowa State University Senior Design May04-04 Faculty Advisors: Dr. John Lamont & Prof. Ralph Patterson III Client: Iowa State University Justin Davis – Team Captain Guy Howard - Communications Rachel Hadaway Justin Gruca Submitted: October 13, 2003
    • Table of Contents Table of Contents.................................................................................................................i List of Figures...................................................................................................................iii List of Tables.....................................................................................................................iv Introduction.........................................................................................................................1 0.1 Abstract..........................................................................................................................1 0.2 Problem Statement.........................................................................................................1 0.3 Operating Environment..................................................................................................1 0.4 Intended Users and Intended Uses.................................................................................1 0.4.1 Proposal Report...........................................................................................................1 0.4.2 Specifications Report for Implementation..................................................................2 0.5 Assumptions and Limitations........................................................................................2 0.5.1 Assumptions................................................................................................................2 0.5.2 Limitations..................................................................................................................2 0.6 Expected End Product & Other Deliverables................................................................3 1 Proposed Approach...........................................................................................................4 1.1 Functional Requirements...............................................................................................4 1.1.1 Feasibility Studies.......................................................................................................4 1.1.2 Client Research...........................................................................................................4 1.1.3 Recommendations.......................................................................................................4 1.2 Constraints Considerations............................................................................................4 1.3 Technology Considerations...........................................................................................5 1.4 Technical Approach Considerations..............................................................................5 1.5 Testing Requirements/Considerations...........................................................................5 1.6 Security Considerations.................................................................................................5 1.7 Safety Considerations....................................................................................................5 1.8 Intellectual Property Considerations..............................................................................5 1.9 Commercialization Considerations................................................................................6 1.10 Possible Risks and Risk Management.........................................................................6 1.11 Proposed Milestones and Evaluation Criteria..............................................................6 1.12 Project Tracking Procedures........................................................................................7 2 Statement of Work............................................................................................................8 2.1 Review Prior Research...................................................................................................8 2.2 Plan New Interviews......................................................................................................9 2.2.1 Develop Contact List..................................................................................................9 2.3 Prepare for Interviews..................................................................................................11 2.3.1 Questionnaires and Scripts........................................................................................11 2.3.2 Personnel...................................................................................................................13 2.4 Conduct Interviews......................................................................................................14 2.4.1 Scheduling.................................................................................................................14 2.5 What CAN be done?....................................................................................................14 2.6 Follow-up Contact.......................................................................................................14 2.7 Technology..................................................................................................................15 2.7.1 Infrastructure.............................................................................................................15 2.7.2 Maintenance Interface...............................................................................................15 Page i
    • 2.7.3 Mapping....................................................................................................................15 2.8 Deployment..................................................................................................................18 2.8.1 Fixed-Base................................................................................................................18 2.8.2 Portable.....................................................................................................................19 2.8.3 Methodology.............................................................................................................20 2.9 End-Product: Requirements Report............................................................................21 2.10 End-Product: Proposal Report..................................................................................21 3 Resources........................................................................................................................22 3.1 Personnel......................................................................................................................22 3.2 Financial Requirements...............................................................................................22 Deliverable Schedule........................................................................................................23 3.3 Working Schedule........................................................................................................24 4 Closure Materials............................................................................................................26 4.1 Project Team Information............................................................................................26 4.1.1 Client Information.....................................................................................................26 4.1.2 Faculty Advisors.......................................................................................................26 4.1.3 Team Information.....................................................................................................26 4.2 Closing Summary.........................................................................................................26 4.3 References....................................................................................................................27 5 Appendix A: Revision History......................................................................................28 Page ii
    • List of Figures Figure 1: Mapping on a Laptop........................................................................................15 Figure 2: Direction finding on a GPS unit........................................................................16 Figure 3: Real time location with a GPS unit...................................................................16 Figure 4: Image rendering using a PocketPC...................................................................17 Figure 5: Deliverable Schedule First Semester................................................................23 Figure 6: Deliverable Schedule Second Semester............................................................23 Figure 7: First Semester Schedule....................................................................................24 Figure 8: Second Semester Schedule................................................................................25 Page iii
    • List of Tables Table 1: Personnel Hours .................................................................................................22 Table 2: Cost of Team Labor............................................................................................22 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 iv
    • Introduction 0.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. 0.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. 0.3 Operating Environment Currently, the operating environment is projected to be the World Wide Web, personal digital assistants, indoor/outdoor kiosks, and CD-ROMs. 0.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). 0.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 0.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 0.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. 0.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. 0.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. Page 2 of 27
    • • They don’t know what the updatability of the system will be (how to account for demolished or newly constructed buildings) • The team will have a limited time to complete the research – until May 2004 0.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
    • 1 Proposed Approach 1.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. 1.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. 1.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. 1.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. 1.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
    • 1.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. 1.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. 1.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. 1.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” 1.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. 1.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. 1.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. 1.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. 1.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 plan This milestone will have been achieved when all planning activities, including client review of the plan have been completed. • Interview plan This 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 process This 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 research This 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 recommendations This 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. 1.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
    • 2 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 2.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
    • 2.2 Plan New Interviews This task is made up of two sub-tasks, Develop Contact List, and Prepare for Interviews 2.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. 2.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. 2.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. 2.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. 2.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
    • 2.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. 2.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. 2.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. 2.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
    • 2.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. 2.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. 2.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. 2.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. 2.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. 2.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. 2.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. 2.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
    • 2.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. 2.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. 2.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. 2.6 Follow-up Contact Objective: By conducting follow-up interviews, and presenting the conclusions from 2.5, prioritization errors may be identified. Approach: If possible, e-mail 2.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
    • 2.7 Technology The following sections detail the technological issues will likely have to be addressed during the course of the project. 2.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. 2.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. 2.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 27 Figure 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” 2.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 Figure 2: Direction algorithms. finding on a GPS unit 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. 2.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, Figure 3: Real whenever a device is activated, the infrastructure will time location with locate the device and then compare that with the map to a GPS unit 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 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. Page 16 of 27
    • 2.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 Figure 4: Image rendering using a interesting data about a building. PocketPC Page 17 of 27
    • 2.8 Deployment The following sections list the methods of deployment for the system. 2.8.1 Fixed-Base The fixed-base sections are stationary objects that will be placed on campus. 2.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. 2.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. 2.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. 2.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. 2.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. 2.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. 2.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. 2.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. 2.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
    • 2.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. 2.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
    • 3 Resources 3.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 Methodology Recommendations Deployment Recommendations Ind. Rev. Panel Presentation Implementation/Technology Practice Presentation Project Management Meeting w/ Advisor Interview Process Team Meetings Design Report Interview Plan Final Report Project Plan Research Poster Totals Class Justin Davis 25 30 35 65 20 10 25 30 45 20 15 15 7 3 10 355 Justin Gruca 10 30 35 65 15 10 10 20 35 20 15 5 3 3 10 286 Rachel Hadawa 10 15 15 50 15 28 15 20 30 15 15 10 10 3 25 276 Guy Howard 15 15 15 50 10 10 30 15 50 15 10 5 10 5 20 275 Totals 60 90 100 230 60 58 80 85 160 70 55 35 30 14 65 1192 3.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 Hours Rate Total Justin Davis 355 15 $5,325.00 Justin Gruca 286 11.5 $3,289.00 Rachel Hadaway 276 11.5 $3,174.00 Guy Howard 275 11.5 $3,162.50 Totals 1192 N/A $14,950.50 • 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
    • Deliverable Schedule ID Task Name Finish Aug '03 Sep '03 Oct '03 Nov '03 Dec '03 24 31 7 14 21 28 5 12 19 26 2 9 16 23 30 7 14 21 28 1 Project Preferences Thu 8/28/03 8/28 2 Project Plan Tue 9/23/03 9/23 3 Bound Plan Tue 10/7/03 10/7 4 Plan to website Tue 10/7/03 10/7 5 Poster Tue 10/21/03 10/21 6 Design Report Tue 11/18/03 11/18 7 Bound Design Report Wed 12/17/03 12/17 8 Design Report to Website Wed 12/17/03 12/17 Figure 5: Deliverable Schedule First Semester ID Task Name Nov '03 Dec '03 Jan '04 Feb '04 Mar '04 Apr '04 May '04 Jun '04 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 13 9 Practice Presentation 12/17 10 Final Report 4/13 11 IRP Presentation 4/27 12 Bound Final Report 5/5 13 Final Report to Website 5/5 Figure 6: Deliverable Schedule Second Semester Page 23 of 27
    • 3.3 Working Schedule ID Task Name Duration August 2003 September 2003 October 2003 November 2003 28 31 3 6 9 12 15 18 21 24 27 30 3 6 9 12 15 18 21 24 27 30 2 5 8 11 14 17 20 23 1 Project Announcement 0 days 2 Information from Advisor 1 hr 9/10 9/10 3 Prepare First Team Mtg. 3.5 hrs 9/11 9/11 4 Update Website 2.5 hrs 9/16 9/16 5 Project Plan 38.81 days 6 Initial Project Plan 10.5 days 77 Publish Plan on Website 1 day 9/23 9/23 78 Advisor & Client Review 1 wk 9/27 9/30 79 Project Plan Corrections 2 hrs 10/1 10/1 80 Project Plan Binding 3 hrs 10/1 10/1 81 Review Prior Research 1 day 9/16 9/17 82 Plan New Interviews 62.75 days 83 Develop Contact List 37.75 days 84 Consideration of Departments 3 wks 9/17 10/7 85 Prioritize Campus Orgs 3 wks 9/17 10/7 86 Student Clubs 3 wks 9/17 10/7 87 Third Party Involvement 3 wks 9/17 10/7 88 Prepare for Interviews 20 days 89 Questionaires/Scripts 18 days 96 Personnel 2 days 100 Conduct Interviews 91.19 days 101 Scheduling & Conducting 2.5 mons 10/20 102 What CAN be done? 1 mon 103 Followup Contact 45.94 days 105 Technology 50 days 112 Deployment 24 days 124 Poster 1 wk 10/7 10/10 125 Design Report (Interview Results) 1 wk 11/15 11/18 Figure 7: First Semester Schedule Page 24 of 27
    • ID Task Name Duration Nov '03 Dec '03 Jan '04 Feb '04 Mar '04 Apr '04 May '04 Jun '04 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 13 20 27 100 Conduct Interviews 91.19 days 101 10/20 Scheduling & Conducting 2.5 mons 12/26 102 What CAN be done? 1 mon 12/29 1/23 103 Followup Contact 45.94 days 104 Scheduling & Conducting 1 mon 1/26 2/20 105 Technology 50 days 106 Infrastructure 1 mon 2/20 3/1 107 Maintenance Interface 3 wks 3/1 3/9 108 Mapping 15 days 109 Direction Finding 1 wk 3/9 3/12 110 Real-Time Location 1 wk 3/12 3/14 111 Image Rendering 1 wk 3/14 3/17 112 Deployment 24 days 113 Fixed-Base 2 days 114 Permanent Signs 1 day 3/17 3/18 115 Kiosks 0.5 days 3/18 3/19 116 Lab PCs 0.5 days 3/19 3/19 117 Portable 7 days 118 Cell-Phone 1.5 days 3/19 3/19 119 PalmOS, PocketPC OS 1.5 days 3/19 3/20 120 Laptop, TabletPC 1.5 days 3/20 3/20 121 Desktop 1.5 days 3/20 3/21 122 Custom Hardware 1 day 3/21 3/21 123 Methodology 3 wks 3/21 3/30 124 Poster 10/7 10/10 1 wk 125 Design Report (Interview Results) 11/15 1 wk11/18 126 End-Product: Proposal Report 3 wks 3/30 4/7 127 End-Product: Requirements Report 3 wks 4/7 4/15 128 Review Panel Presentation 2 wks 4/16 4/20 Figure 8: Second Semester Schedule Page 25 of 27
    • 4 Closure Materials 4.1 Project Team Information 4.1.1 Client Information Iowa State University Electrical and Computer Engineering Senior Design 4.1.2 Faculty Advisors Dr. John Lamont Prof. Ralph Patterson III 324 Town Engineering 2215 Coover Ames, IA 50011 Ames, IA 50011 Office: 515-294-3600 Office: 515-294-2428 Home: 515-292-5541 Home: 515-232-9933 Fax: 515-294-6760 Fax: 515-294-6760 Email: jwlamont@iastate.edu Email: repiii@iastate.edu 4.1.3 Team Information Justin Davis (Captain), CPRE Rachel Hadaway, CPRE 6214 Frederiksen Court 2300 Mortensen #11 Ames, IA 50010 Ames, IA 50014 Home: 515-572-7729 Home: 515-292-7296 Cell: 515-451-1156 Cell: 515-450-8117 Email: justindd@iastate.edu Email: rah1@iastate.edu Guy Howard (Communications), CPRE Justin Gruca, CPRE 1349 Eaton Hughes 826 Dickinson Ave #2 Ames, IA 50012 Ames, IA 50014 Home: 515-572-2647 Home: 515-572-2647 Cell: 678-778-6093 Cell: 515-292-1610 Email: guy2@iastate.edu Email: jgruca@iastate.edu 4.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. 4.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
    • 5 Appendix A: Revision History Version Date Author Change 0.1 9/14/03 JDD Initial Document Framework 0.2 9/15/03 JDD First ½ Statement of Work Added 0.3 9/16/03 GMH Integration of Team Contributions 0.4 9/16/03 JDD General Text Formatting 0.5 9/16/03 GMH Completion of Statement of Work 0.6 9/16/03 JDD Gantt Charts added to Resources Section, Title Page 0.7 9/16/03 RAH Added Final Introduction 0.8 9/17/03 JMG Added Final Proposed Approach 1.0 9/18/03 JDD Draft Submitted for Review 1.1 9/23/03 JDD Unbound Copy submitted for Grading 1.2 Page 28 of 27