Project PlanRev. 0.1Page 1
Project Bluebird
University of Portland / School of EngineeringPhone 503 943 73145000 N. Willamette Blvd.Fax 503 943 7316
Portland, OR97203-5798
Project Plan
Project Enterprise:
Biggerfoot Textbook Exchange
Contributors:
Andrew Elliott
Robert Insley
Brian Toole
Peter Wolf
Approvals
Name / Date / Name / DateDr. Ward / Dr. Lillevik
Mr. Todd Gentry / Mr. Brian Olsen
Insert checkmark (√) next to name when approved.
University of PortlandSchool of EngineeringContact: p. Wolf
Project PlanRev. 0.99Page 1
Project Enterprise
Revision History
Rev. / Date / Author / Reason for Changes0.9 / Oct 27, 2006 / Andrew Elliott,
Robert Insley,
Brian Toole,
Peter Wolf / Initial Draft
0.95 / Nov. 10, 2006 / Andrew Elliott,
Robert Insley,
Brian Toole,
Peter Wolf / Design updates
Advisor feedback
0.99 / Nov. 15, 2006 / Andrew Elliott,
Robert Insley,
Brian Toole,
Peter Wolf / Industry Representative feedback
University of PortlandSchool of EngineeringContact: p. Wolf
Project PlanRev. 0.99Page 1
Project Enterprise
Table of Contents
Summary
Introduction
Background
Product Overview
General Description
Deliverables
Initial Database
Theory of Operations
Book Searching System
Account Management System
Alpha Release
Prototype Release
Development Process
General Approach
Assumptions
Milestones
Project Plan 1.0
Graphic Site Design
Design Release Approval
Database Setup Complete
TOPS 1.0
Account Creation Complete
Searching/Buying Complete
Account Management Complete
Site-Wide CSS
Book Listings Complete
Alpha Release Complete
Prototype Release
Prototype Release Approval
Founder’s Day
Final Report 1.0
Risks/Contingencies
Unforeseen security issues
Learning curve of new technologies is greater than expected
Unable to find suitable hosting
UP deploys new web browser
Something disables a team member
Schedule
Resources
Personnel
Budget
Materials:
Services
Facilities
Conclusions
Appendices
Appendix A: Tasks and Requirements
University of PortlandSchool of EngineeringContact: p. Wolf
Project PlanRev. 0.99Page 1
Project Enterprise
List of Figures
Figure 1. Biggerfoot development stages.
Figure 2. Project Enterprise schedule (Part A).
Figure 3. Project Enterprise schedule (Part B).
Figure 4: Domain Price options
University of PortlandSchool of EngineeringContact: p. Wolf
Project PlanRev. 0.99Page 1
Project Enterprise
List of Tables
Table 1. Project Enterprise deliverables.
Table 2. Key Project Enterprise milestones.
Table 3. Project Enterprise risks.
Table 4. Project Enterprise Budget.
Table 5. Tasks and requirments
Table 6. Requirements summary
University of PortlandSchool of EngineeringContact: p. Wolf
Project PlanRev. 0.99Page 1
Project Enterprise
Chapter / Summary1
The objective of team Enterprise is to build a textbook exchange system for UP students. The system has been dubbed "Biggerfoot", in reference to a previous system of a similar name. Biggerfoot will allow UP students to list textbooks, search for books listed, and contact book sellers when a suitable book has been found. These features will be presented to users through a website hosted by a third party.
This document lays out the general approach, deliverables, milestones, risks/contingencies, schedule, budget, and equipment required by Enterprise to make Biggerfoot functional.
Enterprise's general approach to development is the waterfall method. We plan to implement Biggerfoot in a linear manner, starting with a top-down design driven primarily by the user interface and the system's database needs. The project will be implemented mostly on a screen-by-screen basis, due to the fact that our system is screen-oriented. In terms ofdeliverables, the system has been split into two main categories: the user account system, consisting of the functionality needed for account creation, account management, and book listings, and the searching system, consisting of the functionality needed for book searching and contacting sellers.
Our schedule is presented in detail in the Schedule section. We plan to have our database work done by the end of Fall semester; we also plan to complete our site’s visual design and have a working version of our Theory of Operations. Spring semester we plan to start development, beginning with the functionality for searching and user accounts. We plan to have an Alpha release on March 22 and a Prototype release on April 5. We intend to finish two weeks before Founder’s Day, April 17, giving us an opportunity to implement optional features.
Possible risks to the Biggerfoot project include unforeseen security issues, a greater-than-expected learning curve for key technologies, an inability to find suitable web hosting, new browser releases, and a tragic accident preventing one or more team members from further contributing to the project.
Contingency plans have been developed for each of the identified project risks. We have also built contingency time into our schedule, so we can reconfigure our schedule to accommodate certain situations that may arise. Other contingencies, such as software version changes or hosting problems have workarounds.
Our budget and resource requirements are fairly simple; most of all, we need a domain and hosting. We also plan on acquiring reference materials for some of the technologies we are using, and we have budgeted for printing costs. We do not anticipate spending more than the allocated $200.
University of PortlandSchool of EngineeringContact: p. Wolf
Project PlanRev. 0.99Page 1
Project Enterprise
Chapter / Introduction2
This document is intended to provide an outline of the development process for Team Enterprise. Upon completion of the document, readers should have gained enough information about the concepts of the development process that will be used for Project Biggerfoot, including what is necessary for the team to meet deadlines and other requirements. The intended audience includes faculty members of the University of Portland, team advisors and industry representatives, as well as developers on team Enterprise.
The document contains a discussion of assumptions prior to development, associated risks and a contingency plan for such risks, and a schedule of milestones. The schedule contains deadlines for versions and documents on a weekly basis. This will allow progress to be tracked and key points to be marked in the development process. The perspective of this document will be from a high level. Therefore, no details will be included concerning implementation, integration or testing. Following this section, background information and a brief overview of the Biggerfoot project will be presented. Then the main section of the document, entitled ‘Development Process’, will present in detail the general approach, assumptions, milestones, risks/contingencies, schedule, and resources for the project. The final section will be the conclusion, to tie up the document.
University of PortlandSchool of EngineeringContact: p. Wolf
Project PlanRev. 0.99Page 1
Project Enterprise
Chapter / Background3
At the University of Portland (UP), there is currently no simple way for students to connect with other UP students to buy and sell used textbooks. Previously, this need was met by a web application called Bigfoot, which is no longer available due to problems with administration and marketing. However, we believe that students can still benefit from an improved web application designed to allow them to list textbooks for sale and search for textbooks to be purchased. This application will be a convenient, cost-effective method of connecting students who wouldn’t otherwise be able to efficiently locate each other. A web application specific to UP will offer the advantages of speed and proximity over other currently available textbook trading resources, such as Half.com.
University of PortlandSchool of EngineeringContact: p. Wolf
Project PlanRev. 0.99Page 1
Project Enterprise
Chapter / Product Overview4
General Description
The goal of this project is to develop a web-based application that students at the University of Portland can use to buy and sell textbooks within the student body. The aim of this application is to provide a convenient and economic alternative to selling books back to the University's bookstore. A similar system was used in the past, and later closed for various reasons. This left students without a local alternative to the bookstore buyback, which they felt was not very useful since they received low return amounts.
The Biggerfoot application will allow users who are interested in finding a textbook for sale to search based on author, title, or ISBN. Users selling textbooks must create an account to list books. To create an account, the user must enter a University of Portland email address and a password. This information will be the only information about sellers collected and will not be visible to anyone else using the application. It will only be stored in a database and used internally by the system to generate emails. With an account, sellers will be able to log in to list textbooks for sale, edit and delete listed textbooks and re-list textbooks that have been unlisted. Buyers will be able to contact sellers through the web application to initiate a sale; an email will be sent to the seller with the information necessary to respond.
Deliverables
Our major deliverables are listed inTable 1. A detailed description of each follows.
Table 1. Project Enterprisedeliverables.
Number / Date / Technology / Deliverable1/25/07 / Software / Initial Database
1/26/07 / Documentation / Theory of Operations
3/1/07 / Software / Book Searching System
3/22/07 / Software / Account Management System
3/22/07 / Software / Alpha Release
4/5/07 / Software / Prototype
Initial Database
This is a complete and working database system, identical in structure to the final product’s database, containing the same tables and fields. The only difference between this and the final (past the prototype) database is that this database will be populated with test data instead of actual accounts and their listings. For active accounts, 3000 will be created (to approximate the number of active student email accounts at the University of Portland). At least four accounts will be used to test seller account functionality, including ten sample book listings per account.
Theory of Operations
Our Theory of Operations is a written document detailing how our project will work from a technical perspective.
Book Searching System
When the book searching system is complete, users will be able to use the website to search for and find close book matches (for more information about what constitutes a close match, see Project Enterprise Functional Specifications). They will also be able to contact the associated seller for payment and item receipt.
Account Management System
The account management system is an umbrella term for all the system components that allow users to log into their accounts and manage their password and inventory. This deliverable includes the ability to set up and confirm an account, as well as the ability to manage book inventory.
Alpha Release
This is the first integrated release of the Biggerfoot system, when all webpages and associated functionality are complete. The Alpha Release comes after module testing for each of the pages and backend systems has been completed, but before integration and system testing.
Prototype Release
The Prototype Release is the Alpha Release after problems discovered during integration and system testing have been fixed. The Prototype Release will be thoroughly tested and considered ready for Founder’s Day.
University of PortlandSchool of EngineeringContact: p. Wolf
Project PlanRev. 0.99Page 1
Project Enterprise
Chapter / Development Process5
General Approach
Team Enterprise will use the waterfall development model for project Biggerfoot. The system will be designed top-down, with the whole system design completed before coding begins. Individual module designs will be completed before they are developed. The modules will be developed in close to linear fashion. Each module will be tested independently as it is coded, and then assembled into an Alpha release when all modules are complete. The system will then be tested as a whole, and upgraded to Prototype status. The major project blocks and their development sequence are illustrated in Figure 1.
Figure 1. Biggerfoot development stages.
Assumptions
Team Enterprise has made a number of elementary assumptions for our project plan. We feel that these assumptions are reasonable and safe:
- Our product's users will have an active Internet connection
- Our product's users will have Microsoft Internet Explorer 6 available
- Adequate web hosting with necessary technologies will be available
- MySQL and PHP will provide the functionality we need
- Any version changes to the technologies will be backwards compatible with our system
Milestones
Table 2. Key Project Enterprisemilestones.
Number / Description / DateProject Plan 1.0 / 11/20/06
Graphic Site Design / 11/30/06
Design Release Approval / 12/8/06
Database Setup Complete / 1/25/07
TOPS 1.0 / 1/26/07
Account Creation Complete / 2/8/07
Searching/Buying Complete / 3/1/07
Account Management Complete / 3/1/07
Site-Wide CSS / 3/22/07
Book Listings Complete / 3/22/07
Alpha ReleaseComplete / 3/22/07
Prototype Release / 4/5/07
Prototype Release Approval / 4/13/07
Founder’s Day / 4/17/07
Final Report 1.0 / 4/30/07
Project Plan 1.0
This is the complete version of this document. It contains the project schedule, the project budget, and our contingencies for the identified project risks.
Graphic Site Design
The Graphic Site Design is a complete specification for the look and feel of the Biggerfoot web interface. It will define the look of all page elements and their visual layout, including all headers, footers, fonts, and colors.
Design Release Approval
Our design release has been reviewed by our industry representatives, instructor, and advisor and has been approved.
Database Setup Complete
At this point the database design has been finalized, it has been implemented on a web server, and it is populated with data suitable for testing.
TOPS 1.0
The Theory of Operations (TOPS) is a document that completely outlines the functionality of the system from a technical/implementation perspective. It will include a detailed plan for testing both the individual modules and the system as a whole. Although this milestone is not until mid February, having a working version completed in December is in our schedule and required for the Software Engineering course that three members of Team Enterprise are taking.
Account Creation Complete
At this milestone users can create a seller account and confirm it using the web interface. The account creation process has been thoroughly tested and debugged.
Searching/Buying Complete
At this point, users will be able to search for books, sort their search results, and send a message to a seller through the web interface. All modules for searching and buying have been tested.
Account Management Complete
After this milestone, each seller will be able to use the web interface to log into theirown account, view theirinventory, change their password, and log out. All functionality related to account management has been tested and debugged.
Site-Wide CSS
The Site-Wide CSS will globally define the appearance and layout of the web interface.
Book Listings Complete
When completed, sellers will be able to use the web interface to create and edit book listings while logged into their accounts. The code related to listing and editing has been tested and debugged.
Alpha Release Complete
All functionality, including account creation, account management, book listings, searching, and site-wide CSS will be complete at the Alpha Release, and all modules will have been individually tested.
Prototype Release
The Prototype Release is the Alpha Release after thorough debugging as well as integration, system, user, and load testing.
Prototype Release Approval
The Biggerfoot prototype has been approved by the advisor, instructor, and industry representatives for Founder’s Day.
Founder’s Day
Founder’s Day is the official unveiling and formal demonstration of all Computer Science and Electrical Engineering senior project prototypes, including that of Team Enterprise.
Final Report 1.0
This is the final project document, summarizing the work of Team Enterprise on Project Biggerfoot.
Risks/Contingencies
Table 3. Project Enterprise risks.
Number / Severity / Concern / Description1 / Medium / Risk / Unforeseen security issues
Contingency / Depending on severity, either ignore, redesign/recode, or develop workaround
2 / Medium / Risk / Learning curve of new technologies is greater than expected
Contingency / Slip schedule or drop features
3 / Low / Risk / We are unable to find suitable hosting
Contingency / Run on local machine
4 / Low / Risk / UP deploys a new web browser on the standard build that’s incompatible with our system
Contingency / Recode/workarounds
5 / Low / Risk / Something disables a team member
Contingency / Redistribute work, slip schedule
Unforeseen security issues
Although we have spent a great deal of time considering the various security issues that could arise with our system, it is always possible that we have overlooked something. There may be an unrecognized scenario in which our system or its data could be compromised. It is also possible that a tool, platform, or language we are using has an undiscovered bug or design flaw that compromises the security model of our system.
Unforeseen security issues could come from a number of sources, and the contingency response will depend on the severity and the source. If the security issue is extremely minor or low risk (e.g., a person is able to read all email addresses listed in our database), we may do nothing because the data we are protecting is of relatively minor importance. If a security issue is of moderate or high severity (e.g., a SQL attack that could destroy the database), then it will have to be addressed. If the problem came from an oversight in our design, then we will have to refactor our design and/or implementation to address the issue. If the problem lies with a tool, language, or platform we are using, developing a work-around will be our most likely solution.