Senior Design Parts, Expense, and Inventory Tracker. Project Plan Project Number: Dec Client: Iowa State University senior design

Transcription

1 Senior Design Parts, Expense, and Inventory Tracker Project Plan Project Number: Dec03-02 Client: Iowa State University senior design Faculty Advisors Professor John W. Lamont and Professor Ralph E. Patterson, III Team Members Daniel Balcauski Joseph Cody Jason Hill Matthew James Submitted: February 11,2003

2 Table of Contents Abstract... 1 Problem Statement... 2 Operating Environment... 3 Intended Users and Uses... 4 Assumptions and Limitations... 5 End Product Deliverables... 6 Proposed Approach Functional Requirements Constraint Considerations Technology Technical Approach Testing Requirements Security Considerations Intellectual Property Commercialization Possible Risks, Risk Management Proposed Project Milestones and Evaluation Criteria Project Tracking Statement of Work Estimated Resources Schedules Project Team Information Client Information Faculty advisor Information Project Team Information Closing Summary

3 Table of Figures List of Tables Fig Fig Fig Fig

4 List of Definitions HTML - Hypertext Markup Language, the authoring language used to create documents on the World Wide Web. Microsoft Access Microsoft s proprietary small business/home user relational database software. Easy to use and install, but only runs on Windows and does not support a large number of simultaneous users. Microsoft SQL Server Large enterprise-class database system. Developed to handle large amounts of data and high user traffic. Proprietary and only runs on Windows servers. MySQL - MySQL is an open source RDBMS (relational database management system) that relies on SQL (structured query language) for processing the data in the database. MySQL is most commonly used for Web applications and for embedded applications and has become a popular alternative to proprietary database systems because of its speed and reliability. MySQL can run on UNIX, Windows and Mac OS. Oracle9i Provides many of the powerful features of Microsoft s SQL Server, and also has the associated high cost. Built for reliability, security, and speed, it remains one of the best databases available, built by the company that invented SQL. Perl - Perl is a programming language especially designed for processing text. Because of its strong text processing abilities, Perl has become one of the most popular languages for writing CGI scripts. PHP - An open source, server-side, HTML embedded scripting language used to create dynamic Web pages. PHP can perform any task that any CGI program can do, but its strength lies in its compatibility with many types of databases. PostgreSQL - PostgreSQL is another powerful, well-known, open source database system. XML - Short for Extensible Markup Language. XML is designed especially for Web documents. It allows designers to create their own customized tags, enabling the definition, transmission, validation, and interpretation of data between applications and between organizations. XHTML - Extensible Hypertext Markup Language, a hybrid between HTML and XML. Java - A general purpose programming language with a number of features that make the language well suited for use on the World Wide Web. Small Java applications are called Java applets and can be downloaded from a Web server and run on your computer by a Java-compatible Web browser, such as Netscape Navigator or Microsoft Internet Explorer. 3

5 Abstract In any engineering project the ordering of parts and supplies is essential and also tedious. The same is true for the senior design program in computer engineering at Iowa State University. Keeping a centralized repository for ordering information and tracking overall costs of a single project are lost due to multiple orders from different suppliers. The project team proposes an online application tailored to the needs of the senior design program that will unify the process of parts and order tracking and provide those involved with up to date information. This will allow students to focus less on getting their parts and more on using them. Advisors will have the ability to efficiently monitor and control costs of all projects. With the successful application of our design, the overall effectiveness of the senior design program and its projects will be improved. 1

6 Problem Statement Currently the order system in senior design is performed through manual form submission. This system is not only inefficient in today s highly automated and interconnected environment, but also prevents easy order tracking by all involved parties. The automation of this order system should allow orders to be placed, tracked, and filled with improved efficiency as well as allowing improved communication between involved parties. Also, there is presently no standard way of tracking expenditures for teams, either individually or across all teams in senior design. This presents a problem for both faculty advisor and the course coordinators by affecting their ability to make informed decisions about new purchases. Clouding the issue further is that not all teams within senior design are allotted the same budgets. The system will streamline this by tracking expenditures per team and providing a mechanism to track all money spent in senior design over the course of a semester, year, or project. Finally, there exist many parts, tools, and measurement devices, which are used and purchased through senior design. It would be beneficial to the department, the students, and the course coordinators, if there were an easy and efficient way to track the ownership, location, and availability of these items throughout the course of the academic year. Also, many times teams find that after project completion, they are in possession of parts that would be reusable by other senior design teams in the future. The system will provide a mechanism to allow entry of these reusable parts into the overall senior design inventory. The project will be implemented so that it is easily accessible over the Internet, while at the same time remaining secure, to prevent unauthorized or malicious used. The database system used to track the state of the overall system will be stored on a university/department server and maintenance of that server shall be outside of the scope of this project. The final end product will also consist of end-user documentation for administrators, which will aid in future upgrades and maintenance of the system. 2

7 Operating Environment The operating environment the parts, expense and inventory tracker will be operating in is relatively safe. The final product will be a database that can be run from many different computers via the internet. The database is not anticipated to be exposed to any extreme conditions or other operating conditions that might impair the usage of the product. The intended environment is at risk from hackers for different security reasons. The database system may encounter fraudulent confirmation from any of the parties in the line of approval. Another security risk is people gaining access to the system and modifying their individual team account limit to receive more money. Also, the system is at risk if people bypass the system as a whole leaving undocumented expenses and untraceable materials. The overall environment should not hinder the performance of the system but the actions of hackers may have an impact. 3

8 Intended Users and Uses The main intended users are the senior design course coordinators at Iowa State University. They, along with some others including Gary Bridges and his employees, will be the main users that will maintain the database and keep it up to date. There are a few other users intended including project advisor(s) and the students checking out or ordering a part. These individuals are not necessarily using the database, but their actions and orders directly affect the database through the use of automatic e- mail approval responses and requests. Again, the coordinators of the senior design class will be the main intended user and they will be working directly with the parts, expense and inventory tracker. The intended use of the product is to track the parts and expenses of the senior design inventory at Iowa State University. This will give the senior design course coordinators a better idea of how much money is being spent and also a better handle on the location and users of different parts that were checked out for individual use. The idea being all parts will be accounted for with a known location and acquired upon completion of the project it was used for. The final goal is to track every action and money transaction that goes on in the senior design ordering process as well as the location of every part in an effort to cut loses of money and assets associated with senior design. 4

9 Assumptions and Limitations Assumptions The software will be used by web access only. No direct database connections will be allowed. The software will not be used for any other purpose than to track orders and inventory in the senior design program of Computer Engineering at Iowa State University The application will reside on a secure server that will provide the proper security levels. The maximum number of simultaneous users will be 5. The minimum web browser used to access the application must be Microsoft Internet Explorer 6.0 or greater. The course coordinators will serve as the Administrators of the application. The user role, student, will only be allowed to make requests for orders and inventory. The project adviser role will be allowed to request order and parts as well as approve requests from students. The course coordinator will provide the final approval for all requests. He/she will also have control of the status of all pending requests. The course coordinator will retrieve parts from inventory per the approval of a project team request. notices of pending application tasks will be sent to the appropriate users. This will include notices for pending order request approvals sent to course coordinators. Limitations The application effectiveness will depend on the willingness of participants (users) to avoid bypassing the system procedure. The level of security will be equal to that of the server chosen to host the application. The cost of the producing the application will not exceed $100. Auto-generated program announcements will be available to only those users who have access to . Failure or lateness to approve/disapprove order/inventory requests will impair the effectiveness of the application. 5

10 End Product Deliverables The parts, expense, and inventory tracking system will consist of several physical deliverables as well as online electronic deliverables. The application will exist in an online format and users of the system will need only an Internet connection and a web browser. The physical deliverables will be directed toward the managers of the application, as they will be necessary for reconfiguration or reinstallation. The physical deliverables are as follows: Installation/Help CD-ROM This disc will provide the managers of the system with a mechanism for installation should it be necessary. This will include all working and compiled code. Additionally, there will be help information archived on this disk. Administration Manual This documentation will provide administrators of the system all information necessary to maintain it. This will include but is not limited to information on creating new users, projects, and orders. In addition to the physical deliverables a working online version of the software will certainly be a deliverable. It will be configured to operate in the proper environment and will be ready for use. It will also contain the online help information that is similar to that found on the CD-ROM. Users will have access to this deliverable by following the URL that will be provided by the project team members. 6

11 Proposed Approach 1. Functional Requirements Currently the order system in senior design is performed through manual form submission. This system is not only inefficient in today s highly automated and interconnected environment, but also prevents easy order tracking by all involved parties. The automation of this order system should allow orders to be placed, tracked, and filled with improved efficiency as well as allowing improved communication between involved parties through the following requirements: System shall automate current paper forms. System shall handle standard ordering chain or direct purchase by senior design coordinators. System shall track order status by displaying location in purchasing chain. System shall allow adding of an ordered item to senior design inventory. System shall provide interface for adding and removing teams from the system. System shall provide lists of all outstanding orders by team or across all senior design teams. These lists shall be accessible by authorized individuals only. System shall provide vendor information for improved communication on order status. (Optional) System shall notify when a set dollar amount is reached for certain vendors (minimum order price requirements). (Optional) Shipping costs shall be added when order/invoice is received. In the senior design courses, there is presently no standard way of tracking expenditures for teams, either individually or across all teams in senior design. This presents a problem for both faculty advisor and the course coordinators by affecting their ability to make informed decisions about new purchases. Clouding the issue further is that not all teams within senior design are allotted the same budgets. By tracking expenditures per team and providing a mechanism to track all money spent in senior design over the course of a semester, year, or project, most of the problems associated with budget tracking should be eliminated. System shall provide yearly spending reports across all senior design teams. System shall record reimbursements to senior design by clients for parts. System shall track individual team budgets for approved expenditures. System shall allow teams to view total expenditures to date 7

12 System shall flag teams whose orders exceed their default $100 soft limit (or more if set by course coordinator). System shall provide interface for adding and removing teams from the system. The many parts, tools, and measurement devices used and purchased through senior design are the result of large capital expenditures. It would be beneficial to the department, the students, and the course coordinators, if there were an easy and efficient way to track the ownership, location, and availability of these items throughout the course of the academic year. Many times teams find that after project completion, they are in possession of parts that would be reusable by other senior design teams in the future. The system will meet these needs with the following requirements: System shall provide interface for adding and removing items from the system at ordering time or post project completion. System shall allow check in/ check out of all senior design measurement devices and hand tools through an ownership system. System shall allow viewing of current location/owner of all items in senior design Inventory. System shall facilitate the return of all checked out materials from senior design Inventory through an automated notification system. 2. Constraint Considerations This system will be used by many individuals who not only need to use it for senior design, but also should want to use it. For these two reasons, it is of the utmost importance that the team considers the following constraints in the design of the overall system. Ease of use for users - The system shall be easy for users to understand through the interfaces with the system. The system shall be easy to learn by adequate end user documentation. 3. Technology Security - Since account numbers and dollar amounts will be passed on the forms, all transmissions shall be secure, and all coding will need to be tested for security. Also the spoofing of approval by advisors will need to be checked. Before development can begin on the system, the project team will evaluate the technologies that are available. Development Platforms Considerations on this topic include whether if this project will be fully web-based or implemented as a stand-alone application with Internet access. Most web servers tend to be UNIX (or its variants) based and most PC s where stand-alone applications run, tend to be Windows based. Possibilities include: Windows UNIX Variants 8

13 Languages Considerations on this topic include proficiency of the team in writing the code, portability of the code, and ease of integration with a database. Possibilities include: PHP Perl HTML XML XHTML Java Database Types - Considerations on this topic include ease of use, ease of integration with selected programming language, availability, cost, and security. Other considerations may include ability to handle transaction processing appropriately and overall stability. Possibilities include: MySQL PostgreSQL Microsoft Access Microsoft SQL Server Oracle9i Servlets vs. CGI - An applet that runs on a server, usually written in Java. Increasingly used an alternative to CGI programs. The biggest difference between the two is that a Java applet is persistent. This means that once it is started, it stays in memory and can fulfill multiple requests. In contrast, a CGI program disappears once it has fulfilled a request. The persistence of Java applets makes them faster because there's no wasted time in setting up and tearing down the process. This may be a concern especially if the system is going to be used by a large number of individuals at once (e.g. peak ordering periods) as this relates to the above Ease of Use constraint. All technology decisions shall be based on speed, cost, compatibility, reliability, ease of use, and proficiency of administrators. 4. Technical Approach The team shall implement prototyping of all work in order to show iterative development steps to project advisors and to end-users. This will allow continual feedback to be integrated into the final product and help ensure that what is being built is as close as possible to what should be built. The prototyping done with the end-users shall mostly consist of user interface studies with senior design students, faculty advisors, and other end-users to aid in meeting the ease of use constraint. 9

14 5. Testing Requirements 6. Security Considerations In addition to prototyping, the team will take advantage of a sandwich integration approach. This approach incorporates both a top down and bottom up approach, which allows for flexibility and simultaneous development. The team will begin by designing a system diagram, at which point individual components and their interactions can be identified. After the individual components are defined, the team will be able to apply their skills to both the low-level modules of each component, as well as the interactions between the high-level components of the system. Although this approach is more difficult than either one of the above approaches alone, but in developing the project this way, major design flaws can be identified as soon as possible. Sandwich integration will also require that stubs and drivers are developed in order to test low-level components as well as inter-component communications. The testing of the end product shall include validation and verification testing. The validation testing will help determine if what has been built is what the client intended, as specified by the client s original project specification. The verification testing will determine if what has been built works as the team intended, as specified in the functional requirements. By performing these tests with the clients, the project can be evaluated objectively by all parties involved. Component based testing will be performed after individual program modules are completed. This component testing will test the interfaces between the different sub-systems, by stressing the communication methods established between components with various data entries, and verifying the resultant outputs. Also, as mentioned before, sandwich integration and testing will be performed. During early development, when high-level interfaces are being developed, the team will build low-level stubs to simulate proper working low-level modules. Likewise, when designing base helper functions, the team will implement high-level drivers to stress these methods to insure proper functionality. Since this project is being done specifically for the senior design course, there is little to no competition trying to determine the details, design, or expectation of this project. Therefore, the team sees no need to insure that the project s details are kept secret from anyone trying to gain competitive advantage. However, once the project has completed there are some major considerations regarding security that must be taken into account. The end product will be available online, thereby allowing access to hundreds if not thousands of users. In this possibly hostile environment, three main security considerations are present including protection of data, prevention 10

15 7. Intellectual Property 8. Commercialization of unauthorized use, and prevention of false authorizations for product orders. Protection of data is a primary concern in a project handling large orders and large numbers of individuals. It is important to all parties involved that names, orders, parts, and money do not mysteriously disappear from the database. The team will look into providing secure access to any points in the system where data can either be entered or removed from the system, including providing security on the back end code of the system. The previous point is directly tied to the second security consideration, which is access to the system by only authorized users. The system must be freely and easily available to those it was designed to help; however, those who should not be accessing the system for senior design related business should be kept out. The team will investigate ways to keep out unwanted users as the project progresses. The final security concern for this project is preventing authorized users (i.e. senior design students) from falsely authorizing orders. Since the old paper system of ordering required signatures, this system will have to provide some way of providing electronic signatures (or some other method) so that proper use of the system is maintained. Since this project is being done internally and more than likely open source programming languages and databases will be used, there is little concern for intellectual property at this time. Commercialization of this product is possible. Many organizations in the marketplace have need of inventory tracking systems that are tied in with budget tracking and order automation. The one problem with commercializing this product is its probability in succeeding. There already exist several major companies in the market that offer implementations of like systems, and the possibility of successfully marketing this project against the possible competitors seems slim at this point. 9. Possible Risks, Risk Management In a project this size, there are bound to be potential problems encountered along the way. Hopefully, through early identification and management of these risks, overall impact to the project can be minimized. The first problem that may occur is if the system components, namely, the automated ordering, inventory tracking, and budget tracking, do not integrate successfully. This problem may occur for any number of reasons, but the team will attempt to prevent this from happening by carefully considering the integration process at the beginning of the design and implementation phases. 11

16 A second risk that this project faces is user s not using system correctly. One of assumptions of the project is that all orders, authorizations, and reusable parts will be entered and tracked through the system. If parties involved in senior design fail to use the system, the system will fail, at least in the sense that the system will provide reports based on incomplete data. The team plans to manage this risk through the implementation of proper end-user documentation and the establishment of strict course policies, implemented through the course coordinators, which will mandate proper use of the system. A third risk is design restrictions imposed by the university or the EE/CPRE department (depending on who owns the server). This may include what level of security will be offered on the servers in the department and what will need to be developed by the team. Also, possible restrictions on what kind of software can be run on externally accessible servers may become an important design issue. The team should be able to manage these risks by researching the university s computer policies. Maintenance concerns are another major risk for this project. Since this system should be implemented long after the team is gone from Iowa State, proper documentation, comments in code, and other crucial system information will need to be readily available for those who will maintain and upgrade the system in the future. A final risk that the team faces is loss of a team member. This could happen for any number of reasons and regardless of why it happened, the project must still go on. The team will manage this risk by keeping full records of all activities that relate to the project in their logbooks. In case a member leaves the team, a new member, or the rest of the exiting members can pick up the leaving member s work right where the leaving member left off. This should help to minimize confusion about the state of the project and ease the transition to a smaller project team. 10. Proposed Project Milestones and Evaluation Criteria Table 1-1 Milestones and Relative Importance Number Milestone Overall Importance 1 Project definition High 2 Definition of requirements High 3 Definition of end uses and users Medium 4 Definition of constraints Medium 5 End-product design High 6 Technology selection Medium 7 Project reporting Medium 8 Sub-systems function properly Medium 12

17 9 End-product testing Medium 10 Demonstration planning Low 11 End-product documentation Medium 12 Research Medium 13 Prototype implementation Low 14 Final product implementation High 11. Project Tracking At the completion of the project, each milestone shall be evaluated individually and assigned a value from 1 to 10, where a 1 represents a milestone the team failed to meet and a 10 represents a milestone the team exceeded. After all milestones have been evaluated as such, they shall be multiplied by their overall importance ranking, with a High importance having a multiplier of 5, a Medium importance having a multiplier of 3, and a Low importance having a multiplier of 1. A total score equal to 75% or greater of the possible points will be judged a successful project. Project tracking will be maintained throughout the course of the year through the help of computer software, logbooks, and weekly s. Microsoft Project will be used to track deadlines for milestones and deliverables, as well as keeping tabs on the dependencies between those individual milestones and deliverables. The team s progress, decisions and reasons for those decisions, contacts outside the team, research performed, and labor hours will be tracked in individual members logbooks. These logbooks will be essential for noting progress on individual items as well as for overall team objectives, and will also serve as an aid in creating the administration documentation for the final system. The logbooks themselves may become part of the administrative documentation as they may give future team s insight into the overall design of the system. Finally, the team will correspond with the faculty advisors through weekly s. These s will detail all team expenditures, labor hours, activities completed, and planned activities for the upcoming week. These s will serve to keep the team meeting regularly, as well as provide regular goal setting for each individual member. 13

18 Statement of Work Task 1: Problem Definition Subtask 1a: Project Definition Completion Objective: The team shall complete research as to fully define and understand the problem. Approach: The team shall conduct meetings with the project s client to determine develop a deep sense of the problem to solve. Results: The result shall be a deeper understanding of the problem to solve, as well as the ability to report this in the project plan document. Subtask 1b: Identify End User(s) and End Use(s) Objective: The team shall determine the end use(s) and user(s) as to fully understand the user s needs for the system. Approach: The team shall conduct meetings with the project s client and consult the project s abstract given on the senior design website for the needed information. Results: The result of this subtask shall be a full understanding of the user(s) and use(s) for the system. Subtask 1c: Constraint Identification Objective: The team shall identify constraints on the system from external sources as to fully comprehend the limitations on the system. Approach: The team shall speak with the project advisors and pertinent individuals about the constraints defined in the constraints and limitations section of this report. Results: The result of this subtask shall be a listing and definition of all the constraints on the system. Task 2: Technology and Implementation Selection Subtask 2a: Create a list of technologies available Objective: The team shall define a list of technologies to be considered for implementing the system. Approach: Through prior knowledge and research a listing of technologies suited for the system shall be developed. Results: The result of this subtask shall be a list of technologies to be evaluated for use in the system. Subtask 2b: Create technology evaluation criteria Objective: The team shall define a set of criteria that all technologies will be evaluated against. Approach: These criteria shall be developed using prior knowledge and the knowledge gained in the Problem definition and Functional requirements stages. Results: The result of this subtask shall be the developed criteria for the technologies to be researched Subtask 2c: Research Technologies Objective: The team will research the list of technologies developed in subtask 2a, gaining knowledge to evaluate the technologies based on the criteria developed in subtask 2b. 14

19 Approach: Through product manuals, online references, and possibly from interactions with software manufacturers and retailers, the team will gain request information and begin to store that information for evaluation at a later time. Results: The results of this subtask shall be a stockpile of information, as well as the team members having gained more knowledge about the technologies. This subtask shall prepare the team to evaluate the technologies with the criteria developed previously. Subtask 2d: Choose Technology Objective: The main objective is to choose what technologies to use for the entire project. These decisions will be made based on the previously developed criteria on the information gathered in research. Approach: The team members shall evaluate each technology fairly based on the developed criteria and also on their experiences, if any, with the technology. Results: The result of this subtask shall be the chosen technology for the project. Task 3: End Product Design Subtask 3a: Design requirements definition Objective: In defining the requirements of the design, the team shall state the components needed to fulfill the intended use(s) of the system. Approach: The team shall develop use cases for the intended uses that detail the specific scenario that may take place within the system. This use case diagram will help aid in further development processes. Results: The team shall have developed use cases for all the intended use(s) for the system. Subtask 3b: Design Process Definition Objective: Defining the design process will allow the team to create a plan of attack before beginning the design of the project or subtask. This plan of attack will outline major concerns within the project or subtask, as well as list the needs of the particular project or subtask. Approach: The team shall use the use case diagrams do complete interaction diagrams. These interaction diagrams will detail the messages that will be sent between components, and dictate the flow of information through the system. Results: The result of this subtask shall be the developed interaction diagrams for the system. Subtask 3c: Document Design Objective: Documentation of the design is extremely important so that another group could duplicate the process. If necessary, another group should be able to read the documentation and create a system with the same functionality as the currently developed system. Approach: The team shall document their design considerations in logbooks, as well as publish their interaction and use case diagrams. Results: The results shall be a well-documented design process that could be repeated if needed. Task 4: End Product Prototype Implementation 15

20 Subtask 4a: Prototype Evaluation criteria definition Objective: Any successful project is judged but the criteria needs to be developed. In this subtask team members will create the criteria that will define a successful prototype system. Approach: The team shall look at the use case diagrams and develop a standard of acceptability for the task or project. This will serve as the criteria for evaluating success. Results: The result of this subtask shall be a listing of the criteria for success of the prototypes. Subtask 4b: Prototype Definition Objective: The team desires to have set benchmarks for a prototype system with functionality set before the prototype is developed. Approach: The team shall define what each prototype system s functionality will be based on their software development experience and the timeline of the project. Results: The result of this subtask shall be the definition of each prototype the team desires to develop. Task 5: End Product Testing Subtask 5a: Interface Testing Objective: The team desires testing of the interfaces to the system constructed during development. Approach: The team shall develop test data that will cover acceptable input and unacceptable input. In the case of unacceptable input, the error checking and reporting shall be noted before hand, and the results recorded. Results: The result of this subtask shall be the test data, notes, and relevant failures or successes related to the testing of interfaces to the system. Subtask 5b: Data Assurance Testing Objective: The team desires testing of data entered and manipulated by the system. Approach: The team shall develop sections of program code that will input data into the system, manipulate it, and check the output against a predetermined output to ensure correctness. If this test fails, re-implementation may be necessary on some systems. Results: The result of this subtask shall be the test data, notes, and relevant failures or successes related to data assurance testing. Subtask 5c: Security Testing Objective: The team desires to test the system for security. The criteria for security testing are defined in the security considerations section of this report (page XX). Approach: The team shall develop testing methodologies for attacking the security of the system. Results: The result of this subtask shall be the test data, notes, and relevant failures or successes of the system s security. Task 6: End Product Documentation Subtask 6a: Creation of Administrator s Manual 16

21 Objective: The team desires to create an administrators manual that will detail installing the system, setting up the system, and maintaining the system. Approach: The team shall document the main functionality, and any other uses listed in the use case diagrams in the administrator s manual. Results: The result of this subtask shall be the completed administrator s manual. Subtask 6b: Documentation of program code Objective: Today every programmer must document his/her code so that future individuals can maintain the code if the individual is no longer around to do so. Approach: During development team members shall place comments in their code that details the methodologies taken in solving the problem addressed by the software module. Results: Upon completion of the project the entire system shall be sufficiently documented to ease maintenance at a later date. Task 7: End Product Demonstration Subtask 7a: Demonstration to project advisors Objective: The team desires to demonstrate it s successful completion of the project s specified problem to the project advisors. Approach: Through the testing of the prototypes, interactions with the client, and a final test of the system, the team shall demonstrate full implementation of the desired functionality. Results: The result of this task shall be the demonstration of the completed system. Subtask 7b: Industrial Review Panel Presentation Objective: The team is required to present their design and final product to an industrial review panel upon the completion of the project. Approach: The team shall present its design through an oral report that may be aided by system screen shots, a full demonstration of the system s capabilities, and/or another form of electronic presentation. Results: The result of this subtask shall be the demonstration and presentation of the completed system to the industrial review panel. Task 8: Project Reporting Subtask 8a: Weekly Reporting of Project Status Objective: The team and its advisors desire to keep a close eye on the progress of the project s status. Approach: The team s communication coordinator shall send weekly messages to the team list detailing the progress of the last week of work, the financial status of the project, followed by any outstanding problems that exist. Results: The result of this subtask shall be the weekly s sent by the team s communication coordinator. Subtask 8b: Published Reports Objective: Throughout the design and implementation of the system, several published documents are required to be submitted. These documents define the project s plan, design, and successful completion. 17

22 Approach: Through careful planning and documentation, the team shall submit the reports to the senior design coordinators by the date due, fully completing each section to the best of their abilities. Results: The result of this subtask shall be the published reports, which may serve as further documentation of the overall system developed. 18

23 Estimated Resources Personnel Effort Requirements Personell Effort Requirements Task 1 Task 2 Task 3 Task 4 Task 5 Task 6 Task 7 Task 8 Total For Individual Dan Balcauski Joe Cody Jason Hill Matt James Other Resource Requirements Table 2-2 Other Resource Requirements Item Time Cost Meetings with CSG 10 Hours Time on secure server 25 Hours Financial Resource Requirements Table 2-3 Financial Resource Requirements Item Cost Project Poster $50.00 Total $

24 Schedules 20

25 Project Team Information Client Information Client: Iowa State University senior design Primary Contact: Professor John W. Lamont 324 Town Engineering Ames, IA Voice: (515) Fax: (515) Electronic Mail: Secondary Contact: Professor Ralph E. Patterson, III 326 Town Engineering Ames, IA Voice:(515) Fax:(515) Electronic Faculty advisor Information Professor John W. Lamont 324 Town Engineering Ames, IA Voice: (515) Fax: (515) Electronic Mail: Professor Ralph E. Patterson, III 326 Town Engineering Ames, IA Voice:(515) Fax:(515) Electronic 21

26 Project Team Information Jason Hill Computer Engineering 122 Shepard Street, Apartment 3 Gilbert, IA Voice: (515) Electronic Mail: jahill@iastate.edu Daniel Balcauski Computer Engineering 2136 Lincoln Way Ames, IA Voice: (515) Electronic Mail: dbalcau@iastate.edu Joseph Cody Computer Engineering 200 Stanton Avenue, Apartment 601 Ames, IA Voice: (515) Electronic Mail: joecody@iastate.edu Matthew James Computer Engineering 2312 Knapp Street Ames, IA Voice: (515) Electronic Mail: mjames@iastate.edu 22

27 Closing Summary The problem of order and inventory tracking within the senior design program at Iowa State University has many facets and is complicated to manage effectively by hand. The proposed solution will provide both an intuitive way for course coordinators, project advisors, students and support staff to handle the many orders that occur from semester to semester. By fully investigating the existing architecture and current technological constraints, the project team will provide a solution that fits within the bounds of the Iowa State environment. The many needs of the client will be met or even exceeded by the implementation of the final product. In the end, a fully tested and online order and inventory tracking application will be delivered that provides a comprehensive solution to the senior design program at Iowa State University. 23