Collection Inventory Software Project Plan

Collection Inventory Software Project Plan Team Dec04-01 Client David Stuart Faculty Advisors John Lamont & Ralph Patterson III Team Members Matthew Ring, Neil Kronlage, Brian Ross & Allan Hammell Submission Date February 10, 2004

Table of Contents 1. INTRODUCTORY MATERIAL 1 1.1 Abstract 1 1.2 Acknowledgements 1 1.3 Problem Statement and Solution 1 1.3.1 Problem Statement 1 1.3.2 Problem Solution 2 1.4 Operating Environment 2 1.5 Intended Users and Intended Uses 2 1.5.1 Intended Users 2 1.5.2 Intended Uses 3 1.6 Assumptions and Limitations 3 1.6.1 List of Assumptions 3 1.6.2 List of Limitations 3 1.7 Expected End-Product and Deliverables 4 2. PROPOSED APPROACH AND STATEMENT OF WORK 4 2.1. Proposed Approach 4 2.1.1. Functional Requirements 4 2.1.2. Constraint Considerations 6 2.1.3. Technology Considerations 7 2.1.4. Technical Approach Considerations 8 2.1.5. Testing Requirements Considerations 8 2.1.6. Security Considerations 8 2.1.7. Safety Considerations 9 2.1.8. Intellectual Property Considerations 9 2.1.9. Commercialization Considerations 9 2.1.10. Possible Risks and Risk Management 9 2.1.11. Project Proposed Milestones and Evaluation Criteria 10 2.1.12. Project Tracking Procedures 12 2.2. Statements of Work 13 3. ESTIMATED RESOURCES AND SCHEDULE 19 3.1. Personnel Effort Requirements 19 3.2. Financial Requirements 21 3.3. Project Schedules 21 4. CLOSURE MATERIALS 24 SD Dec04-01 Project Plan i

4.1. Project Team Information 24 4.1.1. Client Information 24 4.1.2. Faculty Advisors Information 24 4.1.3. Team Members Information 25 4.2. Closing Summary 25 4.3. References 25 SD Dec04-01 Project Plan ii

List of Figures Figure 1: Illustration of Database Item with Attributes... v Figure 2: Illustration of Categorical Field... v Figure 3: Gantt Chart of Project Schedule... 22 Figure 4: Gantt Chart of Project Deliverables... 23 SD Dec04-01 Project Plan iii

List of Tables Table 1: Fields of Common Collection Templates... 6 Table 2: Evaluation Scores for Milestone Completion... 10 Table 3: Estimated Personnel Efforts (in Hours)... 20 Table 4: Estimated Project Costs... 21 SD Dec04-01 Project Plan iv

List of Definitions Attribute: The specific data of an element s field. Categorical Field: A field that is limited to a fixed set of choices. Collection: A list of records containing information about a collected item. CVS: Concurrent Versions System. Software tool to coordinate concurrent development of software, including version control. Field: User supplied data associated with each element in the collection. GUI: Graphical User Interface HTML: HyperText Markup Language. Code used in creating web pages. IDE: Integrated Development Environment. Software tool that provides a source code editor, compiler, and debugger. PDA: Personal Digital Assistant. Examples include Palm Pilot or PocketPC XML: extensible Markup Language. Code that contains database-like information in a single easy-to-read file. CD Name Date Item Attributes Figure 1: Illustration of Database Item with Attributes Figure 2: Illustration of Categorical Field SD Dec04-01 Project Plan v

1. Introductory Material This section provides an overview of the project, including abstract, acknowledgements, problem statement and solution, operating environment, intended users and uses, assumptions and limitations, and expected end-product and deliverables. 1.1 Abstract People love to collect things, whether it s books, music, coins, or lawn gnomes. Currently, there is no readily available program designed to dynamically handle any type of collection. Some people create and maintain hand-written inventory lists, while other, computer-savvy individuals create spreadsheets with limited functionality and no easy interface for controlling their collections. The project will implement a computerized inventory system that will allow collectors to easily organize and maintain any collection. The system must be simple enough for computer novices, yet easily customizable to any collection type. The system will provide templates for movie, music, book, stamp, coin, and paper money collections but any collection from lawn gnomes to ornate doorstops can be managed. The software program will run on many popular platforms, including Windows, MacOS, Linux, and PalmOS. The system will use an attractive GUI to manage the collection. With this software, collectors will have an easy way to manage their collections no matter how unique. This program will allow any type of collector control of their collection inventory, thus enabling greater enjoyment of their respective hobby. 1.2 Acknowledgements The team would like to thank Prof. John Lamont and Prof. Ralph Patterson for their contributions to defining the project as well as lending continued support through its completion. The team would also like to thank Prof. David Stuart for providing a set of criteria to design the system and testing the software with his collection of music. 1.3 Problem Statement and Solution This section defines the problem and an overview of the project solution. 1.3.1 Problem Statement Thousands of individuals enjoy collecting things. Some individuals have only one type of collection, but most individuals who spend time building collections, do so with a variety of different things. An example may be a person who collects sports SD Dec04-01 Project Plan 1

memorabilia, but also has a vast music and movie collection. As collection size increases, managing the collection becomes difficult. The solution for many people is to start hand-written lists, a labeled storage system, or a custom spreadsheet. These methods are tedious and inflexible. Many software programs exist that cater to specific collections. These systems can only be used to manage one type of collection, such as sports cards, or music collections. There exists a need for a collection inventory program that can be run on multiple computer platforms. It should be simple to use and flexible to manage any type or size of collection. 1.3.2 Problem Solution A standalone collection inventory software application will be produced that will incorporate both attractive GUIs for managing and updating collections as well as a database system that will be mainly hidden from the typical user. This database will hold all of the entered information including category names, item names, numbers, and any other information that the collector will enter in order to manage their collections. The collection inventory software will need to be easily configurable by the user to be applicable to every type of collection. Generic templates or wizards will be generated to enable the user to quickly begin to manage their first collections, and then customize these collection inventories later. 1.4 Operating Environment The primary operating environment will be the user s personal computer. The target platforms include the current versions of Windows, MacOS, and Linux operating systems. The secondary operating environment will be the user s PDA device. The PDA must be a Palm derivative with PalmOS 3.5.1 or higher operating system. 1.5 Intended Users and Intended Uses This section defines the intended users and uses of the project. 1.5.1 Intended Users The intended users for the collection inventory system are collectors of music, movies, books, stamps, coins, or paper money. Other collectors can customize the software to manage their collections. These collectors will be English-speaking. No other restrictions are placed on the target audience. SD Dec04-01 Project Plan 2

1.5.2 Intended Uses The collection inventory system will be intended primarily for home and personal use. The exception to the home and personal use would be small businesses that wish to use the system solely for its inventory features, as no provisions for conducting sales, purchasing, and other business functions will be integrated. The collection inventory system will allow users to categorize and organize any inventory of items that they wish to collect; items could include music, books, movies, and sports memorabilia, among countless others. Users will be able to enter new items into both existing and new collections quickly and easily. The collection inventory system will allow users to check the contents of their collections, update and manage their collections, and make notes of their collections or individual items within them. In addition, users can search and sort their collections efficiently according to any of the fields. 1.6 Assumptions and Limitations This section lists the initial assumptions and limitations of the project. Additional assumptions and limitations will be added as the project progresses. 1.6.1 List of Assumptions Types of data the user may enter into the inventory fields will be limited to text, numerical values, image files, sound files, and category lists. This program will run on Windows, MacOS, and Linux platforms. Currency data must be U.S.-based (i.e. any foreign currency will have to be entered into the inventory fields with its U.S. equivalent). Both English and metric standards will be accepted. All users of the collection inventory system will be proficient with the English language. Any PDA implementations will be tested for the PalmOS only. No PocketPC devices are available for development and testing purposes. The program will require PalmOS 3.5 or a higher version. All PDA implementations will be secondary to the completion of the primary collection inventory system. Multiple users can use the program on one computer with different collections. One user can store multiple separate collections. Data from the PDA will overwrite the desktop data when uploading from the PDA to the desktop software. 1.6.2 List of Limitations The collection inventory system will be limited by the amount of memory in the user s computer because the collection data must be able to fit in main memory. SD Dec04-01 Project Plan 3

The size of the collection inventory is dependent upon the user s available memory. The level of computer expertise displayed by the users will range from novice to advanced users. The time allocated to this project is set at two semesters. This may require some minor features to be passed over to allow for on-time delivery of an initial release. The project budget cannot exceed $150.00. 1.7 Expected End-Product and Deliverables The project will result in a standalone software application consisting of an easy to use interface for managing of collections and a database system to hold the entered data. The software will run on any computer platform and thus will be available as a download or installation CD. Along with this software application, a help tutorial will be integrated in order to allow the user to easily familiarize themselves with the features and applications included in their new collection inventory software. This software application will be delivered on or before the due date at the conclusion of the fall 2004 semester. Along with the aforementioned standalone software, a stripped-down version of the collection inventory software will be produced that can be run on a PDA device. This will be a stripped-down version in that it will have less functionality, a limited GUI, and limited record lists. Its data entry will be limited to mainly inventory checklists and simple textual data entry. The software for PDA implementation will be delivered on or before the due date at the conclusion of the fall 2004 semester. Documentation will accompany the aforementioned collection inventory software that will describe all of its functionality, menu functions, help topics, installation methods, technical specifications, etc. This document will be delivered on or before the due date at the conclusion of the fall 2004 semester and shall cover the full collection inventory software and will include the stripped-down version available for PDA implementation. 2. Proposed Approach and Statement of Work The proposed approach and statement of work expand the project proposal. These two sections will detail the components and activities necessary to ensure project success. 2.1. Proposed Approach This section will outline the requirements, considerations, risks, evaluations, and tracking procedures for the project. 2.1.1. Functional Requirements SD Dec04-01 Project Plan 4

The following defines exactly what the proposed software should and should not do. 2.1.1.1 The software shall allow the user to create a new collection of items. 2.1.1.2 The software shall allow the user to add new items to the collection. 2.1.1.3 The software shall allow the user to remove existing items from the collection. 2.1.1.4 The software shall allow the user to copy an item in the collection. 2.1.1.5 The items in a collection shall contain fields describing the characteristics of the item. 2.1.1.6 The software shall allow the user to edit attributes of an item. 2.1.1.7 The software shall allow the following types of fields: strings of text, numbers, images, sound files, and categorical lists. 2.1.1.8 Each field shall have a name (string of text) describing the data in the field. For example, a field storing the author of a book would have name Author. 2.1.1.9 The software shall allow new fields to be defined for existing collections. 2.1.1.10 If the user adds a new field to an existing collection, the software shall allow the user to define a default value for that field to be applied to all existing items in the collection. 2.1.1.11 The software shall allow the user to define default values for fields that are applied when creating a new item in the collection. 2.1.1.12 The user shall have the option of creating the new collection from a blank collection or from a template of common collection types. 2.1.1.13 The blank collection shall define no fields or items. 2.1.1.14 The software shall allow the user to search the collection for items by field. 2.1.1.15 The software shall offer templates for the following common collections with fields defined in Table 1: music, movies, books, coins, paper money, and stamps. 2.1.1.16 The software shall allow the user to sort the items by a specified field in ascending or descending order. 2.1.1.17 The software shall allow the user to save a collection as an HTML file for display on the internet. 2.1.1.18 The software shall allow the textual portion of the inventory to be downloaded to a PDA. 2.1.1.19 The PDA implementation shall allow the user to view the downloaded collection. SD Dec04-01 Project Plan 5

2.1.1.20 The PDA implementation shall allow the user to modify fields of existing items. 2.1.1.21 The PDA implementation shall allow the user to add new items to the collection. 2.1.1.22 The software shall allow the user to import data from the PDA implementation into an existing collection. 2.1.1.23 The software shall offer help and tutorial functions. Field Music Movies Books Coins Paper Money Stamps Title X X X Coin/Money/Stamp X X X Mint X Proof/Uncirculated/Circulated X Type X Size X X Face Value X X X Format X X X X X X Version/Edition/Series X X X X Production Date X X X X X X Performer/Actors/Character X X X Composer/Director/Author X X X Producer X X Publisher X Designer/Signature X X X Copyright X X X Label/Series X X Location X X X X X X Watched/Played/Read X X X Duration/Time X X Value X X X X X X Description X X X X X X Comments X X X X X X Table 1: Fields of Common Collection Templates. 2.1.2. Constraint Considerations The constraints are non-functional requirements the software must meet. 2.1.2.1 The software shall run on Windows and Macintosh computers. 2.1.2.2 The saved collections shall be compatible with all versions of the software. SD Dec04-01 Project Plan 6

2.1.2.3 The user interface shall be English. 2.1.2.4 The currency data shall be U.S.-based. 2.1.2.5 English and metric measurements shall be accepted. 2.1.2.6 The PDA implementation shall run on PalmOS 3.5 or higher. 2.1.2.7 The number of fields in a collection shall not be limited by the program but by storage limitations. 2.1.2.8 The number of items in a collection shall not be limited by the program but by storage limitations. 2.1.2.9 The software shall be produced within the $150.00 budget. 2.1.2.10 The software shall be produced within two semesters. 2.1.3. Technology Considerations This section presents several technology alternatives and the criteria to evaluate each alternative. The software program is required to run on multiple platforms and the software must either be programmed in a platform independent language or multiple versions of the program must be written. The platform independent language Java and platform dependent versions of C++ or C# will be considered. The decision of programming language must account for time to learn language, time to develop the software for that language, and the software tools and support for that language. The final decision shall include the reasons for accepting or rejecting each of the language alternatives. The software program needs to store large amounts of data. Generic databases, such as Access or MySQL, and customized XML are common methods of storing data. The team will research the capabilities of both types of data storage techniques. The decision of the data storage method will depend on the computer resource requirements, licensing restrictions, customizability, and application to this type of data storage. The final decision shall include the reasons for accepting or rejecting each of the data storage alternatives. Designing software can benefit from helpful text editors, compilers, and debuggers. There are several integrated development environments (IDE s) that simplify the task of writing programs. This project will have the choice between NetBeans or Eclipse for Java development and Visual Studio for C++ development. The choice of IDE will depend on the development language chosen, source control features, development features, compiling features, debugging features, and overall ease of use. The final decision shall include the reasons for accepting or rejecting each of the IDE alternatives. SD Dec04-01 Project Plan 7

2.1.4. Technical Approach Considerations This section outlines the methodologies used in completing the project. The software project will be created using a waterfall method. The project plan document is the first step in the development of the software. This plan sets the goal of the project, the schedule of the project, and the budget for the project. The next step is to create a detailed design of the solution. This design will describe in detail how the software should be created. The design will determine the exact functionality and components of the software. With the complete design, the team will be able to create the software. The software will first be prototyped to test major functionality and usability. Then the software will be refined. Throughout the development, the software will be tested. As the software nears completion, more time will be devoted to testing the product. After the software is revised, the help file, tutorial, and maintenance documentation will be created. 2.1.5. Testing Requirements Considerations The software will be tested to ensure it meets the functional requirements from 2.1.1. The functional testing will be automated so regression testing can be performed after revisions to the software. Each of the functional requirements shall have one or more automated tests associated with it. All features of the program must be tested through either automated testing or human testing. GUI features will need to be tested by humans. Errors found in testing will require debugging and code changes. The software will also be tested by providing preliminary copies to the faculty advisors and the client. They will test the usability of the program and ensure that the software meets their expectations of the project. Errors found in this testing may require changes to the design document. 2.1.6. Security Considerations This section describes security concerns during the development of the product and the operation of the product by the end user. During the development of the product, the design team may have access to the client and faculty advisors collections. The contents of these collections will be kept private at the request of the client or faculty advisors. The end-product will store the collection data in an unencrypted database. Thus, the collection software should not be used to store protected information. The software will not report any data, such as usage or error data, to the development team without the express consent of the user. SD Dec04-01 Project Plan 8

2.1.7. Safety Considerations The collection inventory software is designed for personal use on individuals collections and should not be used in safety critical applications. The licensing agreement will exempt the team from any damage or loss of information resulting from the use of the software. 2.1.8. Intellectual Property Considerations The software project will be developed without the use of proprietary information. Any code segments used as reference during the development of the software shall be in the public domain or open source. The use of open source software may restrict distribution methods of the end-product. From the restrictions inherited by using open source software, the team will make every effort to develop its own software whenever possible. 2.1.9. Commercialization Considerations The software has the potential to be marketed to hobbyist collectors and course instructors. The product will not be designed as a commercial product. If the end result performs well and there is a demand for the product, the team will investigate commercialization. 2.1.10. Possible Risks and Risk Management The team has risks during the development of the project that will jeopardize the successful completion of the project. This section will outline potential risks and ways to minimize the effect of each risk should it occur. The project schedule shall allot extra time in case any of the risks occurs. 2.1.10.1 Risk: The project will lose a team member. Assessment: As of this writing, the team has lost member Allan Hammell to a broken leg. To minimize the impact of losing a team member, logs of all activities must be kept by all team members. Source code must only be submitted to the repository if there are proper comments so other members can continue the work. Remaining team members may need to work additional hours to complete project deliverables and meet milestones. 2.1.10.2 Risk: The project will lose important data, source files, or documentation. Assessment: All electronic project data and documentation shall be stored on a EE/CprE server in a CVS repository. This repository tracks all changes to data and allows the team to revert to a previous edition of the data. The EE/CprE department stores copies of the data every night. SD Dec04-01 Project Plan 9

2.1.10.3 Risk: The project will not meet the expectations of the client. Assessment: Any major design deficiencies discovered at the end of the project will require much more time to fix than if discovered early in the development timeline. The client will review the project definition, project plan, and project design documents and provide feedback on features desired. Additionally, the client will review prototypes of the software and provide comments on the progress of the software. 2.1.10.4 Risk: The technology need to complete the project will be difficult to learn. Assessment: Each member of the team has a different background in computer programming and database design. Extra time must be allotted for learning the computer language and technologies necessary for the completion of the project. 2.1.11. Project Proposed Milestones and Evaluation Criteria This section describes the milestones for the project and the criteria used to evaluate the success of the completed project. For each milestone, the evaluator will determine the score from Table 2 based on the evaluation criteria. At the completion of the project, the team will add the scores for all milestones multiplied by its overall importance metric to get a final score for the project. A final score greater than 85% will be considered a success. Evaluation Result Numerical Score Greatly Exceeded 100 % Exceeded 100 % Met 100 % Almost Met 90 % Partially Met 80 % Did Not Meet 40 % Did Not Attempt 0 % Table 2: Evaluation Scores for Milestone Completion 2.1.11.1 Milestone: Project Definition Description: The project must be adequately defined before work on it can begin. An accurate definition ensures all team members know the scope and desired functionality of the project Evaluator: Client and Faculty Advisors Evaluation Criteria: The evaluators will determine how well the project definition meets their expectations and assign a score from Table 2. Overall Importance: 15% SD Dec04-01 Project Plan 10

2.1.11.2 Milestone: Technology Considerations and Selection Description: The project team members must research available software technologies such as tools, languages, databases, and IDE s. From these, the team must select the technologies that will help produce software that meets all functional requirements in the shortest amount of time with minimal amount of errors. Evaluator: Team Members Evaluation Criteria: The evaluators will determine how well all options for technology were considered. The evaluators will determine how well the selected technologies meet the requirements of the project. From these, the evaluators will assign a score from Table 2. Overall Importance: 10% 2.1.11.3 Milestone: End-Product Design Description: The end-product design will detail all components of the final product. This will expand the functional requirements to include architectural details of the software and implementation level design choices. The design will provide interface specifications for software modules and classes. Evaluator: Team Members and Faculty Advisors Evaluation Criteria: The evaluators will determine how well the design accomplishes the functional requirements and the ease of implementing the design. The evaluators will assign a score from Table 2. Overall Importance: 20% 2.1.11.4 Milestone: End-Product Implementation Description: The prototype is the realization of the product design in actual software. Evaluator: Team Members, Faculty Advisors and Client Evaluation Criteria: The evaluators will determine how well the prototype conforms to the functional requirements and design. The evaluators will assign a score from Table 2. Overall Importance: 8% 2.1.11.5 Milestone: End-Product Testing Description: The end-product testing ensures that the product is free of bugs and errors. Evaluator: Team Members Evaluation Criteria: The evaluators will determine the quality, usability, and lack of bugs of the software. The evaluators will assign a score from Table 2. Overall Importance: 15% SD Dec04-01 Project Plan 11

2.1.11.6 Milestone: End-Product Documentation Description: The end-product documentation will provide a user manual and tutorial for the software. Evaluator: Client and Faculty Advisors Evaluation Criteria: The evaluators will determine how clearly the end-product documentation describes the usage of the system. The evaluators will assign a score from Table 2. Overall Importance: 8% 2.1.11.7 Milestone: End-Product Demonstration Description: The final software will be presented to the client. The client will be informed of the use of the software and initial maintenance begins. Evaluator: Client, Faculty Advisors, and Industrial Review Panel Evaluation Criteria: The evaluators will determine how well endproduct solved the intended purpose of the project. The evaluators will assign a score from Table 2. Overall Importance: 10% 2.1.11.8 Milestone: Project Reporting Description: The team will create several documents as the project progresses. These include the project definition, project plan, product poster, end-product design, and final report. The final reporting for the project will describe all aspects of the system and include maintenance documentation that details the implementation of the project. The final report will be the longest surviving record of the project implementation and must account for any changes to functional requirements, design, and architecture made through the development of the end-product. Evaluator: Faculty Advisors Evaluation Criteria: The evaluators will measure how well the final report captures all salient aspects of the project for future reference. The evaluators will assign a score from Table 2. Overall Importance: 14% 2.1.12. Project Tracking Procedures For anything but the smallest projects, project tracking is essential to project success in terms of time and budget constraints. The team will create a Gantt chart in Microsoft Project and track the progress using this software. The Microsoft Project chart will be constantly updated as milestones are accomplished and deadlines met. The team will use the milestones and statement of work to track project advancement and plan for future work. SD Dec04-01 Project Plan 12

The team will also keep record of the budget, including labor hours, of the project. If problems arise, the team will decide the method for the project to continue and meet the schedule and budget. 2.2. Statements of Work Task No. 1 Project Definition Task Objective: To completely define the problem by addressing each of the subtasks listed below. Task Approach: The team shall discuss each of the subtasks listed below and define each individually. The team will discuss with the faculty advisors and client what is to be expected out of the end-product including what features are desirable and what operating environment is applicable. Task Expected Results: The team will produce a preliminary project description. Subtask No. 1a Project Definition Completion Subtask Objective: To complete the problem definition. Subtask Approach: The team will conduct primary research into different types of collections, existing collection software programs, and possible choices of software languages. The team will also conduct preliminary meetings with faculty advisors and client in order to cement a problem definition. Subtask Expected Results: The team will produce a written problem definition that will be included in various reports throughout the life of the project. Subtask No. 1b End-User(s) and End-Use(s) Identification Subtask Objective: To identify all assumed users and uses of the collection software. Subtask Approach: The team will brainstorm a list of possible users and possible uses of the end-product as well as accepting suggestions from faculty advisors and the client. Subtask Expected Results: The team will produce a written list of both the assumed users and uses of the end-product. Subtask No. 1c Constraint Identification Subtask Objective: To identify all constraints (technological, financial, and otherwise) that are applicable to the project. Subtask Approach: The team will conduct preliminary research into different software languages in order to identify possible constraints that will have to be enforced to move forward with a realizable product. The team will also brainstorm possible limitations as well as assumptions. Subtask Expected Results: The team will produce a written list of assumptions, limitations, and possible project constraints. SD Dec04-01 Project Plan 13

Task No. 2 Technology Research and Selection Task Objective: To consider various software languages and existing software programs applicable to collection inventories and select the most appropriate means. Task Approach: The team will identify possible technologies to use in the development of the software. The team will determine criteria for technology selection and measure technologies by the criteria. The team will select technologies best fitting the criteria. Task Expected Results: The team will pick select technologies to use in the final product. Subtask No. 2a Identification of Possible Technologies Subtask Objective: To identify all the possible software languages that the product can be written in as well as consider all platforms on which the product will be run. Subtask Approach: The team will consider technologies that can be used to produce the end-product. These technologies include databases, programming languages, software development tools, and operating platforms. Subtask Expected Results: The team will create a list of potential technologies to use in the collection inventory software. Subtask No. 2b Identification of Selection Criteria Subtask Objective: To produce selection criteria for the list of possible technologies. Subtask Approach: The team will discuss the criteria for determining which technologies will be best for accomplishing the end-product. These will include considerations such as requirements to use a particular technology on different platforms, working knowledge of the technology, and features of the technology. Subtask Expected Results: The team will produce metrics to judge each technology. Subtask No. 2c Technology Research Subtask Objective: To research the technologies advantages and disadvantages. Subtask Approach: Each team member will conduct research on the technologies to learn their abilities, limitations, compatibility, and uses. Subtask Expected Results: The team will gain a good understanding of which software technologies will work best for the production of the collection inventory software. Subtask No. 2d Technology Selection Subtask Objective: To select the software language(s) that the program will be written in as well as select which tools and technologies to use in development. Subtask Approach: Using the selection criteria, the team will select the software technologies to use in the end-product. Subtask Expected Results: The team will select the databases, programming languages, software development tools, and operating platforms to use in the collection inventory software. Task No. 3 End-Product Design Task Objective: To produce the design plans of the collection inventory software system. Task Approach: The team will map out the development of the software code including SD Dec04-01 Project Plan 14

functional blocks, flow charts in order to layout the design path, and sketches of possible screenshots for the different GUIs of the program. Task Expected Results: The team will produce documentation detailing all aspects of the software development phase. Subtask No. 3a Identification of Design Requirements Subtask Objective: To identify all of the design requirements for the project. Subtask Approach: The team will discuss and list all the ways in which the program will be used. This will produce a list of features that the software will need to encompass, which will lead to the design requirements. Subtask Expected Results: The team will produce a list of the design requirements of the collection inventory software. Subtask No. 3b Design Process Subtask Objective: To map out the design process. Subtask Approach: The team will do preliminary planning of how to begin the software development. After the initial development is underway, the team will continue to update and rethink their plans of how to best implement their problem solution. The design process will be partitioned into sections mainly correlating with the different functional blocks of the software program. Subtask Expected Results: The team will produce a design process map or flowchart to show the different functional blocks associated with the software program. Subtask No. 3c Documentation of Design Subtask Objective: To provide a detailed documentation of the design for the software implementation phase. Subtask Approach: The team will determine the classes, interfaces, modules, and functions needed in the final software implementation. Subtask Expected Results: The team will produce a written document detailing the design of the collection inventory software. The document will completely describe the software architecture and interfaces. Task No. 4 End-Product Implementation Task Objective: To develop the end-product from the design document. Task Approach: The team will implement the software from the design document. All commenting will be updated to ensure thorough code documentation. Task Expected Results: The software will be implemented from the design document. Subtask No. 4a Identification of Product Limitations and Substitutions Subtask Objective: To identify any product limitations and alternative implementations to meet the client s expectations. Subtask Approach: The team will review the design document for any aspects that will be difficult to implement with the selected technologies. The team will then determine alternative methods of implementing these aspects. Subtask Expected Results: The team will create a list of all the limitations of the product and alternative technologies to overcome these limitations. SD Dec04-01 Project Plan 15

Subtask No. 4b Implementation of End-Product Subtask Objective: To complete the end-product code. Subtask Approach: The team will translate the design document into computer software. The development may overlap with testing of individual modules or units. Subtask Expected Results: The code will be completed and unit tests will be performed. Task No. 5 End-Product Testing Task Objective: To test the software for functional requirement and constraint requirement conformance. The team will test for bugs and software defects. Task Approach: Testing will consist of test planning, test development, test execution, test evaluation, and test documentation. Task Expected Results: Testing will be used to gauge the quality of the software. Subtask No. 5a Test Planning Subtask Objective: To create a plan for the testing of the software. Subtask Approach: The team will review the desired functionality and constraints of the software and design tests to measure its conformance. Subtask Expected Results: The team will create a document listing all testing operations to perform on the software. The document should thoroughly test all aspects of the code. The plan will determine if each test should be automatically or manually tested. Subtask No. 5b Test Development Subtask Objective: To develop automated tests from the test plan. Subtask Approach: The team will write driver software to test the functionality of individual modules in a bottom-up approach. Subtask Expected Results: All automated tests will be written. Subtask No. 5c Test Execution Subtask Objective: To test the software using automated and manual tests. Subtask Approach: The team will run automatic tests and the manual tests on the software. The team will use regression testing to ensure that fixed bugs do not introduce errors in previously passed tests. Subtask Expected Results: The tests should locate and remove all bugs from the system. Subtask No. 5d Test Evaluation Subtask Objective: To gauge the effectiveness of the tests and the estimated amount of bugs left in the software. Subtask Approach: The team will record the number of bugs discovered during testing. These values and the size of the code will allow the team to estimate the number of remaining bugs in the code. Subtask Expected Results: The team will use the test evaluation to determine when to release the software (i.e. when the number of remaining bugs is small enough). SD Dec04-01 Project Plan 16

Subtask No. 5e Documentation of Testing Subtask Objective: To document the testing approach and results. Subtask Approach: The testing plan will be expanded to include any additional tests performed and the results of the tests. Subtask Expected Results: The results of the testing can be used in future projects to make estimations on error amounts per line of code. Task No. 6 End-Product Documentation Task Objective: To document the software for the user (help files and tutorials) and future development (maintenance and support documentation). Task Approach: The team will develop help files, tutorials, maintenance, and support documentation by reviewing previous material of the project. Task Expected Results: The team will produce documentation that details every aspect of the system from a user's perspective and a developer's perspective. Subtask No. 6a Development of End-User Documentation Subtask Objective: To create a help manual and tutorial for end-users of the project. Subtask Approach: The team will organize explanations of all functions of the program in a document that can easily be referenced while running the program. The tutorial will be written to provide a step-by-step explanation of setting up the inventory system for a new user. Subtask Expected Results: The team will produce user-friendly documentation that will allow a novice user to run the program. Subtask No. 6b Development of Maintenance and Support Documentation Subtask Objective: To create documentation detailing the design and implementation of the source code. Subtask Approach: The team will analyze the source code and architecture specifications. The team will document what portions of code implement what features of the program. Subtask Expected Results: The team will produce documentation that other developers can use to understand the workings of the program for maintenance and support reasons. Task No. 7 End-Product Demonstration Task Objective: To demonstrate the completed project to the faculty advisors, client and industrial review panel. Task Approach: The team will create a presentation showing the design problem, design solution, and the completed project. Task Expected Results: The complete project will meet or exceed the expectations of the reviewers. Subtask No. 7a Demonstration Planning Subtask Objective: To plan the presentation for each of the reviewers. Subtask Approach: The team will create a PowerPoint presentation to sell the SD Dec04-01 Project Plan 17

project to the reviewers. Subtask Expected Results: The team will have a customizable presentation that can be shown to the faculty advisors, client, and industrial review panel. Subtask No. 7b Faculty Advisor(s) Demonstration Subtask Objective: To present the completed project to the faculty advisors. Subtask Approach: The presentation will be customized to the faculty advisors needs. The team will present the information and project to the advisors. Subtask Expected Results: The completed project will exceed the expectations of advisors. The advisors will use the project to organize their personal collections. Subtask No. 7c Client Demonstration Subtask Objective: To present the completed project to the client. Subtask Approach: The presentation will be customized to the client s needs and modified from faculty advisors suggestions. The team will present the information and project to the client. Subtask Expected Results: The completed project will exceed the expectations of clients. The client will use the project to organize his music collection. Subtask No. 7d Industrial Review Panel Demonstration Subtask Objective: To present the completed project to the industrial review panel. Subtask Approach: The presentation will be customized to the review panel s needs and modified from client s suggestions. The team will present the information to the industrial review panel. Subtask Expected Results: The team will receive industrial assessment for future business presentations. Task No. 8 Project Reporting Task Objective: To provide project direction and measure project progress. Task Approach: The team will create a project plan, a poster, a design report, a final report, and weekly emails. Task Expected Results: The team will stay on course for finishing the project on time and on budget. Subtask No. 8a Project Plan Development Subtask Objective: To define the direction of work for this project. Subtask Approach: The team discussed the expected course of work for the project and wrote this document. Subtask Expected Results: This document that defines the project, proposed approach, schedule of work, and estimated resources. Subtask No. 8b Project Poster Development Subtask Objective: To present the project in a constrained space to develop effective communication skills. Subtask Approach: The team will design the content, visuals and layout of the poster. SD Dec04-01 Project Plan 18

Subtask Expected Results: The team will have a project poster displayed in Coover hall that provides a visually appealing overview of the project. Subtask No. 8c End-Product Design Report Development Subtask Objective: To specify the detailed design of the software program. Subtask Approach: The team will develop the architecture for the software and specify the interfaces between modules. Subtask Expected Results: The team will have a modular software design that can be implemented concurrently by several developers. The design will result in software the meets the specified functional requirements and constraints. Subtask No. 8d Project Final Report Development Subtask Objective: To provide a lasting document of the project s design, activities, and results. Subtask Approach: The team will expand previous documents and include changes made as the project progressed. The team will document all parts necessary for the maintenance, support, and operation of the software. Subtask Expected Results: The team will have a final document that contains all relevant information about the project. Subtask No. 8e Weekly E-mail Reporting Subtask Objective: To provide routine updates on the progress of the project. Subtask Approach: The team writes an email to the client, faculty advisors, and team members. The email includes the completed activities from the previous week, the planned activities for the current week, the resources used for the previous week, and continuing problems of the group. Subtask Expected Results: All people relevant to the project are informed of the progress of the team. 3. Estimated Resources and Schedule This section discusses the proposed efforts required by the individual team members as well as the costs of production and required resources. It also provides a detailed schedule of product development. At the time of this printing, the Senior Design team as already lost a team member, Allan Hammell, due to personal injury. The following tables include Hammell s initial work on the project to credit his involvement. 3.1. Personnel Effort Requirements The following table illustrates the estimated number of hours that each individual team member will contribute to the tasks defined in Section 2.2. SD Dec04-01 Project Plan 19

Problem Definition Tech. Considerations and Selection End-Product Design End-Product Implementation End-Product Testing End-Product Documentation End-Product Demonstration Project Reporting Total Matthew Ring 8 8 49 86 25 20 14 30 240 Neil Kronlage 10 12 49 95 25 16 10 28 245 Brian Ross 8 10 45 83 38 25 10 25 244 Allan Hammell 6 5 - - - - - - 11 Total 32 35 143 264 88 61 34 83 740 Table 3: Estimated Personnel Efforts (in Hours) All team members will play an active role in shaping the design of the project as well as the technical aspects and problem solutions. Each member will contribute to the problem definition, technical considerations and selections, and end-product design. The team will then split remaining tasks among members with the greatest qualifications. As computer engineers, Neil and Matthew will oversee design of the software. This will allow for the most efficient use of time in the product implementation stage. Brian will perform much of the testing phase. His feedback will improve the quality of the software. The hours spent on the problem definition and project plan were used to estimate the hours spent on other documentation and reports for the project. The design will require more planning than the other documents since it details all aspects of the project. From previous experience in software development, the team expects the implementation to require the most time of the project. The hours devoted to testing will be after the product is implemented and will not include unit testing done during implementation. SD Dec04-01 Project Plan 20

3.2. Financial Requirements This following describes the estimated expenses for the project. The project will have a budget of $150 for parts and reference manuals without labor. Parts and Materials a. Reference Manuals b. Project Poster c. PDA (PalmOS) d. Development Tools W/o Labor With Labor $45.00 $50.00 Donated No Cost $45.00 $50.00 Donated No Cost Subtotal $95.00 95.00 Labor at $11.00/hr Matthew Ring $2,739.00 Neil Kronlage $2,695.00 Brian Ross $2,618.00 Allan Hammell $121.00 Subtotal $8,173.00 Total $95.00 $8,268.00 Table 4: Estimated Project Costs The team will require $50 to cover the cost of the project poster, as well as an estimated $45 to cover the cost of any printed reference material that would be beneficial to developing the software. Matthew Ring will provide a Palm m505, running PalmOS 4.1, for testing purposes. All software development tools will be available through the Engineering Department or accessible via open source groups. 3.3. Project Schedules Figure 3 is a Gantt chart illustrating the team s proposed schedule. Figure 4 is another Gantt chart illustrating the team s project deliverables. This chart provides a schedule of when major documents and reports will be completed. By the end of the first term, the team plans to have a completed product design and will begin implementation of the software. The second term will be spent on completing product development and testing. The coding will be complete by mid-october and testing will begin mid-september, before the completion of coding. Testing will overlap with coding to ensure project completion by the final deadline. The final deliverable will be presented to the review panel, the faculty advisors, and the client before the end of the second term. SD Dec04-01 Project Plan 21

Figure 3: Gantt Chart of Project Schedule SD Dec04-01 Project Plan 22

Figure 4: Gantt Chart of Project Deliverables SD Dec04-01 Project Plan 23

4. Closure Materials This section contains information about the team members responsible for this project, their faculty advisors, and the product s client. It also contains an overall summary of the project plan and any reference material the project team used in designing the product. 4.1. Project Team Information Below is the contact information for the client, faculty advisors and the student team members. 4.1.1. Client Information Professor David Stuart 241 Music Ames, IA 50011 (515)294-2924 (Phone) (515)294-6409 (Fax) dstuart@iastate.edu 4.1.2. Faculty Advisors Information Professor John W. Lamont 324 Town Engineering Ames, IA 50011 (515)294-3600 (Phone) (515)294-6760 (Fax) jwlamont@iastate.edu Prof. Ralph Patterson III 326 Town Engineering Ames, IA 50011 (515)294-2428 (Phone) (515)294-6760 (Fax) repiii@iastate.edu SD Dec04-01 Project Plan 24

4.1.3. Team Members Information Matthew Ring (Project Leader) CprE/ComS 2300 Mortensen Pkwy. #25 Ames, IA 50014 (515)268-1695 mring82@iastate.edu Neil Kronlage (Communications Coordinator) CprE 203 Jewel Dr. #7 Ames, IA 50010 (515)707-8873 nkron@iastate.edu Brian Ross EE 153 N. Hyland Ave. #14 Ames, IA 50014 (515)292-0546 bfross@iastate.edu Allan Hammell CprE 2035 Sunset Dr. Ames, IA 50014 (515)292-6551 ahammell@iastate.edu 4.2. Closing Summary Individuals who have difficulty keeping track of their growing collections will now have a solution that is easy-to-use, platform independent, and completely customizable. The endproduct will provide collectors with a program to keep track of their unique collections easily and efficiently, while giving them the most control over inventory management. Windows, Mac, and Linux/UNIX users alike will have access to the software, with an interface they find familiar in their other computer applications. 4.3. References http://java.sun.com/ - Java Developers Source Page http://hsqldb.sourceforge.net/ - Developer s resources for an Open Source Java Database engine. Arnold, Ken, et al. The Java Programming Language, 3 rd Edition. Boston: Addison- Wesley Co. 2002. SD Dec04-01 Project Plan 25