Senior Design Parts, Expense, and Inventory Tracker. End-Product Design Report Project Number: Dec Client: Iowa State University senior design

Transcription

1 Senior Design Parts, Expense, and Inventory Tracker End-Product Design Report 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: April 15, 2003 Revised: April 28, 2003

2 Table of Contents Table of Contents...i List of Tables... ii List of Figures...iiii List of Definitions...iv Abstract... 1 Acknowledgement... 2 Problem Statement... 3 Operating Environment... 4 Intended Users and Uses... 5 Assumptions and Limitations... 6 End Product Deliverables... 8 Approach Used Design objectives Functional requirements Design constraints Technical approach considerations and results Testing approach considerations Recommendations regarding project continuation or modifications Detailed Design Student role Faculty advisor role Course coordinator role Database design Resources and Schedules Proposed project milestones and evaluation criteria Project tracking Resource Requirements Schedules Project Team Information Client information Faculty advisor information Project team information Closing Summary i

3 List of Tables Table 1-1 Table 1-2 Table 2-1 Table 6-1 Table 6-2 Table 6-3 Table 6-4 Table 6-5 Table 6-6 Programming language analysis Database technology analysis.. Project milestones Original personnel effort requirements... Modified personnel effort requirements.. Original additional resource requirements... Modified additional resource requirements.. Original financial resources requirements Modified financial resource requirements ii

4 List of Figures Fig 2-1 Fig 2-2 Fig 2-3 Fig 2-4 Fig 2-5 Fig 3-1 Fig 3-2 Fig 3-3 Fig 3-4 Fig 4-1 Fig 4-2 Fig 4-3 Fig 4-4 Fig 4-5 Fig 4-6 Fig 4-7 Fig 4-8 Fig 4-9 Fig 5-1 Fig 6-1 Fig 6-2 Fig 6-3 Fig 6-4 Login subsystem Student orders parts flowchart. 17 Student tracking orders 17 Student requests inventory.. 18 Student tracks expenses of project Faculty advisor views inventory. 19 Faculty advisor tracks a student team s order. 19 Faculty advisor approves/disapproves an order.. 20 Faculty advisor views expenses by team Course coordinator orders parts/inventory.. 21 Course coordinator approves/disapproves an order 22 Course coordinator tracks an order. 22 Course coordinator approves/denies an inventory request.. 23 Course coordinator checks in/out an item from inventory.. 23 Course coordinator adds a user to the system. 24 Course coordinator removes a user from the system. 24 Course coordinator adds an item to inventory. 25 Course coordinator changes the status of an item in inventory 25 Database schema. 26 Original project deliverables.. 36 Modified project deliverables Original project tasks Modified project tasks iii

5 List of Definitions CGI Common Gateway Interface, is a standard for interfacing external applications with information servers, such as HTTP or Web servers. HTTP Hypertext Transmission Protocol a communication protocol developed for transmitting information via the Internet. 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. Kerberos A security program that authenticates a user against a protected list of usernames and passwords. It also is the system in which Iowa State University uses to validate all users of its systems. 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. Faculty advisor The student team s point of contact regarding the design and implementation of the project. The faculty advisor is a member of the faculty of Iowa State University. Project advisor Equivalent to faculty advisor. Course coordinator The senior design program has a course coordinator who is responsible for the course as well as the design of the course and the funding for the teams. The course coordinator is a faculty member and interfaces with the university as well as the students. Course coordinator s assistant This individual assists the course coordinator in his/her duties with respect to the course. This individual is also a member of the faculty of Iowa State. iv

6 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 the Electrical and Computer Engineering Department 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

7 Acknowledgement The senior design parts, expense, and inventory tracker project would like to acknowledge the Computer Support Group (CSG) of the Department of Electrical and Computer Engineering of Iowa State University. CSG has been extremely helpful in obtaining a server for the team s implemented system to run on. Without their assistance this project would not have progressed so quickly thus far. 2

8 Problem Statement Currently the ordering of parts for senior design student teams 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 ordering 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 student teams, either individually or across all teams in senior design. This presents a problem for both faculty advisor and the course coordinator 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 second phase of the project will streamline this evaluation 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 coordinator 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 use. The database system used to track the state of the overall system will be stored on a 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. 3

9 Operating Environment The operating environment the parts, expense and inventory tracker will be operating in is relatively safe. The final product will be a software solution that can be run from many different computers via the Internet. The project team does not anticipate 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. 4

10 Intended Users and Uses The main intended users are the senior design course coordinator and his/her assistant(s) at Iowa State University. They, along with Gary Bridges, his employees, and some other departmental staff will be the main users that will maintain the database and keep its information up to date. There are a few other users intended including faculty advisor(s) and the students checking out or ordering a part. These individuals are not necessarily using the database, but their actions directly affect the database through the use of automatic approval responses and requests. Again, the coordinator of the senior design class and his/her assistant(s) will be the main intended users 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 coordinator a clearer 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 main idea is that all parts will be accounted for with a known location and acquired upon completion of the project for which it was intended to be used. 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 assets associated with senior design. 5

11 Assumptions and Limitations All projects have limitations placed on them as well as assumptions made by their developers. This section of the report addresses those assumptions and limitations that were declared at the beginning of the project. Assumptions These assumptions will help to guide the project to successful completion. Without them the project could turn in a different and more costly direction leading to non-completion of the project goals. The software will be used by Internet 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 electrical and 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 coordinator will serve as the administrator of the application. The user role, student, will only be allowed to make requests for orders and inventory. The project advisor 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 after 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 the course coordinator and/or their assistant(s). The department shall provide a pre-established labeling/numbering infrastructure for the existing inventory. Items in inventory will be searchable by choosing from a list or category only. Since the Computer Support Group administers the computers in the senior design labs, and they are not intended as users of the system, there shall be no tracking of software maintained on the computers in the senior design labs. Multiple requests may be made for an item in senior design inventory. The expense tracking software shall not track any expenses before the system is used as the primary purchasing system for senior design. 6

12 Limitations The limitations listed below will also serve to speed the development of the project. These limitations will also help to evaluate the successfulness of the project at a later date. 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. 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. 7

13 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. 8

14 Approach Used 1. Design objectives The following objectives were created for the project after meetings with the client and faculty advisors. The end product shall provide an automated parts ordering procedure. Although one of the project s ultimate goals is to automate the ordering procedure, the system will not actually order the items for the course coordinators and staff. The system will automate the current paper system that is used by senior design to request ordering of parts and equipment for group projects as well as the senior design lab facilities. The end product shall provide a reliable and secure system that will be easy to use. This objective will improve the overall user experience by providing an intuitive user interface and implementation that has been tested to ensure stability. The end product shall provide budget tracking for all senior design related expenditures. By showing a faculty advisor or course coordinator the expenses that a project team has made to date, they can make an improved decision in regards to parts purchases of the design team. The expense tracking will also serve to evaluate the project team s budgeting for the project. The end product shall provide a management system for senior design supplies and reusable parts. The clients wish to have an easy to use interface for the large amount of supplies held by the senior design program. This includes items in the senior design labs as well as items that are checked out to student design teams for use in their projects. Users of the system will, at any time, be able to see what parts are available, and simultaneously be able to request parts for check out. 9

15 2. 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 will allow orders to be placed, tracked, and filled with improved efficiency as well as allowing improved communication between involved parties through the following requirements: Order tracking - System shall track order status by displaying location in purchasing chain. Outstanding order tracking - 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. Vendor information - System shall provide vendor information for improved communication on order status. Semester team updates - System shall provide an interface for adding and removing teams from the system. Daily notification System shall provide a daily reminder to the course coordinator and faculty advisors if the system is holding pending approvals that have yet to be acknowledged. (Optional) Vendor minimum order amount notification System shall notify the course coordinator when a set dollar amount is not reached for certain vendors (minimum order price requirements). (Optional) Shipping cost tracking Shipping costs shall be added when order/invoice is received. In the senior design program, 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 the faculty advisor and the course coordinator 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 will be eliminated. Yearly spending reports - System shall provide yearly spending reports across all senior design teams. Semesterly spending reports System shall provide spending reports across all senior design teams for the current academic semester. Reimbursement tracking - System shall record reimbursements to senior design by clients for parts. Team budget tracking - System shall track individual team budgets for approved expenditures and allow teams to view total expenditures to date. Budget ceiling tracking - System shall flag teams whose orders exceed their default $100 soft limit (or more if set by course coordinator). 10

16 3. Design constraints 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: Inventory update - System shall provide interface for adding and removing items from the system at ordering time or post project completion. Library-style borrowing system - System shall allow check in/ check out of all senior design measurement devices and hand tools through an ownership system. Also, a mechanism shall be provided by which a team may request an inventory item for a specified amount of time and the necessity of getting that item. Ownership tracking - System shall allow viewing of current location/owner of all items in senior design Inventory. Inventory tracking - System shall facilitate the return of all checked out materials from senior design inventory through an automated notification system. Team priorities System shall provide a mechanism by which the course coordinators can decide which team out of several receives an inventory item. Item grouping System shall provide several preset categories by which to search for and add items 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. Security - All transmissions and database data shall be secure, and all coding will need to be tested for security. Identification False approvals by advisors will need to be prevented. 11

17 4. Technical approach considerations and results Before development will begin on the system, the project team has evaluated the technologies that are available. All technology decisions were based on speed, cost, compatibility, reliability, ease of use, and proficiency of administrators. Development platforms Considerations on this topic included whether if this project would 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. The project team considered both Windows and UNIX variants while considering the development platform for the system. With the server given to the design team by the Computer Support Group, the development platform decision was made fairly simple. The server given to the design team has a UNIX variant called Red Hat Linux as an operating system and all of the future designs must be executable on this format. 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. The comparison of the technologies considered is tabulated below. Table 1-1 Programming language analysis Language Pro Con PHP Perl HTML XML Java ColdFusion Easily creates dynamic web pages; easily incorporates information from databases. Excellent text parsing abilities; common language used for CGI programming; well defined interfaces for interacting with common databases; easy to learn. Widely deployed formatting language used for browsing the World Wide Web. No underlying database framework needed. XML is a text based hierarchical structure. Servlet and JSP technology is much more efficient than CGI programming; known by every member of the group. Quick and efficient development platform for Web applications that integrates seamlessly with Dreamweaver. Not known by most of the team members; might be too basic for current project (i.e. carrying session data between multiple web pages). Not known by most of the team; CGI programming is not efficient on the server side because every time a new page needs to be loaded, the server needs to start a brand new process which is killed immediately after the script finishes running. Does not have the required decision making features of other computer languages (i.e. only used for formatting). Does not allow for transaction control and easy querying that comes with a standalone database. May require extensive research on implementing Servlet and JSP technologies as they are separate ways of using Java for Web applications. Expensive (Educational server costs $850). 12

18 Selected Technology The team has yet to decide on a specific technology, although careful consideration and research is being given to Java, Cold Fusion, and PHP. The team will base its final decisions on the criteria cited above. HTML will definitely be used for web page presentation and formatting as no real competition exists for performing that function. 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. The possible database technologies considered are tabulated on the following page. Table 1-2 Database technology analysis Database Pro Con MySQL PostgreSQL Microsoft Access Microsoft SQL Server Oracle9i Fully functional, stable open-source database; works well with PHP, Java, Perl, and Cold Fusion Fully functional, stable open-source database; works well with PHP Easy to implement quick database system Fully supported, enterpriseclass database system Fully supported, enterpriseclass database system Does not implement nested SELECT statements in current version Does not work with Cold Fusion Cannot be used on Red Hat Linux Very expensive; Proprietary; Cannot be implemented on Linux Very expensive Selected Technology The team has also not made a complete decision about the database technology although current research is focused on MySQL and PostgreSQL because they are free and fully functional database systems. Microsoft Access and Microsoft SQL Server were eliminated because they will not run on Linux and Oracle 9i was eliminated primarily because the price is too high and the design teams needs do not necessitate a high end database. 13

19 5. Testing approach considerations 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 the endproduct is as close as possible to what the clients envisioned. The prototyping done with the end-users shall consist of user interface studies with senior design students, faculty advisors, and other end-users to aid in meeting the ease of use constraint. 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. 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 highlevel drivers to stress these methods to insure proper functionality. 14

20 6. Recommendations regarding project continuation or modifications The project team s recommendation at the point is to continue the project as originally envisioned. The design team has had no complications that were not overcome in the areas of technologies that will be used, security, ability of the members of the group to perform, overall design, and the group s overall cooperation with each other and ability to work as a team. In all aforementioned possible complications, the group has solved any minor problem that has arisen and come up with a logical solution. The department is also cooperating by informing the project team as to what exactly our restrictions are for the server, and those restrictions can be defined by stating that the project team has secured a server and it is their responsibility to provide any and all software and security that are needed by the project team. From the successes of the project team thus far and the design that is detailed later in this document it is the recommendation of all the group members to continue with the project. 15

21 Detailed Design The design of the system consists of four major parts. Three of these are characterized by activity diagrams that describe the events this user will see. The fourth is a diagram of the data scheme being implemented. Together they show how the external design and internal design meet to satisfy the requirements of the project. Figure 2-1 Login subsystem When a user begins using the system, he/she must log in through the Kerberos Authentication method as shown in figure 2-1. The username will then be checked by the system to determine whether the user is a student, advisor, or coordinator. From this point, one of the three following activity diagrams will characterize the user s interactions with the system. Within all of these interactions, the underlying data scheme will be used to present the appropriate data. 1. Student Role Student ordering is currently handled with paper forms that must be submitted for approval to both the faculty advisor and the course coordinator. The new system, as shown in figure 2-2 on the next page, will perform this function completely electronically and alleviate the burden of physically taking an order form from one place to another merely to get an approval. This is major benefit especially if an order has to be placed multiple times because of corrections or adjustments. 16

22 The system will provide an order review screen for students to look over an order request before submitting it for advisor approval. This is a common implementation in many online shopping cart applications and was added by the project team to reduce and hopefully eliminate mistakes in an order through a typo, or by multiple submission of the same order. 6WXGHQW 0DLQ 0HQX 5HTXHVW 3DUWV 2UGHU <HV Each order submitted by a student will create a new order entry in the database which will then be used in queries related to approvals and order status tracking. This order ID will be unique for every order placed through the system, and will remain in the system indefinitely to allow for archival purposes. )RUPIRUHQWHULQJ SDUWV 6XEPLW <HV 1R 2UGHU5HYLHZ 6FUHHQ s will only be sent if a pending approval is not acted upon within a 24-hour period. Hopefully, this daily will act as an efficient reminder to advisors and the course coordinator, and allow orders to be processed in the shortest amount of time. &UHDWH2UGHULQ 'DWDEDVH Once the old order form had been submitted, the student team would have had no further information about the order until they received a notification from the course coordinator that it had arrived. With the new system, as shown in figure 2-3, the team shall be able to track any updates in the order status without involving the coordinators or the advisor. For security and ease of use, students will only have access to view orders that their own team places. This should make navigating the system an easier process by eliminating unnecessary clutter. 1R &UHDWH(QWU\LQ 2UGHU8SGDWHV ZLWK6WDWXV 6HQG(PDLO 2UGHU6XFFHVV 3DJH Figure 2-2 Student orders parts flowchart Figure 2-3 Student tracking orders The new inventory system will alleviate much of the confusion that currently exists with regards to ownership and availability of parts. The student will be able to see on one page all available items in the senior design labs as well as view the availability of each item. At that point, the team can then submit checkout requests to the course coordinators with a few clicks of a mouse. 17

23 The system, as shown in figure 2-4, will be modeled such that the check out request by a student does not immediately result in the requested item being changed to check out status. This is because multiple teams may make requests for the same item within a certain time period and the decision of which team has priority on the item will be left to the course coordinators. Hopefully, this situation will result in highly demanded items going to those who need them most, not just the first person who requests it. The system will also allow the student to specify what their personal priority is on the item. This will allow the coordinator to make more informed decisions, especially when one team requests an item as a nice to have priority, as opposed to a more severe have to have priority. Students will also be able to specify how long they need the item for. This will allow the course coordinator to inform other groups that are requesting the item of an approximate time they will receive it. 6XFFHVVIXO 5HTXHVW 6WXGHQW 0DLQ 0HQX &KHFNRXW 5HTXHVW 0HQX )RUPIRU UHTXHVWLQJ LQYHQWRU\ 6HQG(PDLO 6HW VWDWXVRI UHTXHVWHG LQYHQWRU\LWHP 6XEPLW <HV 1R Figure 2-4 Student requests inventory $UHILHOGV RND\" By providing expense tracking, teams should be able to get a better idea of where they can spend money, and where they need to budget. This should allow teams a quick and easy way to aid in purchasing decisions. The system, as shown in figure 2-5, will only show the student s team s expenses to avoid unnecessary clutter. This will also allow the teams to quickly and efficiently see what is most important to them with minimum hassle. Figure 2-5 Student tracks expenses of project 18

24 2. Faculty Advisor Role The faculty or project advisor can use the system for a variety of operations. For orders, the project advisor can approve, track, or create an order(s). The project advisor can also view all of the inventory items. Finally, the faculty advisor can view his/her group s entire itemized expense list. The various operations are explained in detail as to how the operation works and why the project advisor was granted this specific access. The project advisor will be able to view all inventory items and their current status. There will be a link available on the project advisor main menu as shown in figure 3-1. This will give the advisor an Figure 3-1 Faculty advisor views inventory opportunity to see what items are available overall and which items are available now for his/her teams use. It was unnecessary to include a request for an item in the inventory because the group members themselves can do that. Also, the project advisor will never check an item in or out so a view all was sufficient. The project advisor will be able to track the order of his/her group s orders and only his/her group s orders as shown in figure 3-2. This was decided because no other group s orders would be relevant to them. After viewing all of the orders, the project advisor can select a specific order and the details including the part ordered and the current status will be displayed. This order tracking will be useful because it will allow the advisor to monitor the progress of the ordered part to see if their group can move on to the next step in the actual implementation of the desired final product. Figure 3-2 Faculty advisor tracks student team s order 19

25 Figure 3-3 Faculty advisor approves/disapproves an order The project advisor will be able to approve the order of his/her group s orders as shown in figure 3-3. This is necessary because the project advisor is overseeing the project and knows what parts the group needs or doesn t need. The advisor s input it necessary to see if this order should be placed or not. After the advisor selects the approval menu from the project advisor main menu, his/her pending approvals will be displayed sorted by group. The name of a group will be the heading and under that will be the pending approval(s) for that group. If more than one group has a pending approval, these other groups will be listed as well. The advisor will then select a specific order and decide whether to approve or disprove the order. If the order is approved, it will continue on in the approval sequence and the appropriate s will be sent out as well as a time stamp added to the order for history and grouping purposes. If the approval is declined, the order process is stopped and the appropriate e- mails are sent out to notify the team that the order has been declined. The project advisor will be able to view the expenses of his/her groups as shown in figure 4-4. This is the only function that applies to the project advisor for the expenses because the advisor will do no modification to the expense tracking system and no other group s expenses are relevant to the advisor. After the advisor selects the expense link from the project advisor main menu, his/her groups will be displayed. The advisor may then select a specific group and that particular group s expenses will be displayed. This Figure 3-4 Faculty advisor views expenses by team includes the money already spent, the proposed order that is now considered pending money spent, and the total of these two. All expenses will be itemized and totaled at the end of the itemization. 20

26 3. Course Coordinator Role Ordering Parts If the course coordinator chooses to order parts from their main menu screen, they will be directed to the request parts order screen. On this screen they will be given a form to enter information about the parts they wish to order, and then asked to submit the information as shown to the left in Figure 4-1 Once they submit the information, the system will generate a review screen, at which time the course coordinator will have the opportunity to review the order for correctness information about the vendor, quantity, part numbers, etc. and then submit the request for an order to the system. The alternative here is that the course coordinator finds an error in the form and has to go back to change the data. A back option has been included so that the data that has already been entered will not be lost, and the course coordinator will not have to reenter the information again. After they course coordinator has successfully reviewed and submitted the order, the system will create the order in the database as well as create an entry in the order updates table of the database, inserting a status flag that will be used to identify who has approved the order in the chain of command. Figure 4-1 Course coordinator orders parts/inventory The system will then deliver the order to the send system and display the order success form. If there was a problem, the system will return the course coordinator to the form for entering parts and generate an error message that will be displayed to the course coordinator in the form they were directed to. Once the order success has been displayed the course coordinator will be prompted to return to the course coordinator main menu. This system seeks to deliver the order s approval status to the student in a timely fashion. 21

27 &RXUVH&RRUGLQDWRU0DLQ0HQX %DFNWR0DLQ0HQX 8SGDWHVHQGHPDLO Approval of requests As the course coordinator attempts to approve requests made by student teams they will login to the system and proceed to their main menu. Once there they will follow a link to the approve requests menu which will display the pending requests sorted by team. This is so that every team has their requests placed together not in a First In, First Out manner. The course coordinator then is required to choose a request to view and then is shown the detail of that request as detailed in Figure 4-2. The course coordinator then chooses to approve or deny the request and the system logs that choice. If the request is approved, the course coordinator is then required to identify the account from which the funds will be removed from to purchase the items in the order. The system then updates the information in the order status and send systems and directs the course coordinator back to the course coordinator main menu. If the request is denied, the order status is logged and the update order status and send systems are updated with this information. Order Tracking 8SGDWHRUGHU VWDWXV $FFRXQWWREH GUDZQIURP 2UGHU3DWK 3HQGLQJ DSSURYDOVVRUWHG E\WHDP $SSURYH 2UGHU,' 9LHZRUGHU $SSURYH'HQ\ 7KHSDWKWKDWWKHRUGHUFDQ WDNHFDQEHGHILQHGDV DU\%ULGJHVRUGHUVWKH SDUWVYLDDXQLYHUVLW\ SXUFKDVHRUGHU IDFXOW\DGYLVRURU FRXUVHFRRUGLQDWRUFDQ SXUFKDVHZLWKDFUHGLW FDUG 7KLVRSWLRQPXVW EHOLPLWHGLQ LW VXVH2QO\LQVSHFLILF FLUFXPVWDQFHVZLODQRUGHU EHSODFHGLQWKLVPDQQHU LWHPLVVHQWWR*DU\ %ULGJHVDQGLVIRXQGWRH[LVW ZLWKLQWKHXQLYHUVLW\ LQYHQWRU\DQGLVRUGHUHG IURP,RZD6WDWH8QLYHUVLW\ ' HQ\ Figure 4-2 Course coordinator approves/disapproves an order Figure 4-3 Course coordinator tracks an order At times it may be necessary for a course coordinator to track the status of an approved order. Once the course coordinator has logged into the system and received the main menu they will move into the Order Tracking system shown in Figure 4-3 The system will show the course coordinator all the orders that are not filled by the team that ordered them. The course coordinator will then choose an order to view the details of and the system will return that information to the course coordinator. They will then be given the option to go back to view another order or go to the course coordinator main menu. 22

28 Inventory Requests Often in the course of a semester the course coordinator may seek to grant a request for an item in the senior design inventory. They login to the system and see that there are pending requests for inventory. After reviewing the requests the course coordinator approves or denies the request for inventory and the system logs this choice and updates the status of the item. Also note that there can be multiple requests for an item and that the senior design course coordinator has final say in the priority of the group requesting the item. Figure 4-4 Course coordinator approves/denies an inventory request Check-in/Check-out of items When the students come to get the inventory they requested and the course coordinator approved, the course coordinator needs a way to show the physical assignment of the item to the project team. The checkin/check-out procedure allows the course coordinator to show that physical relationship within Figure 4-5 Course coordinator checks in/out an item from inventory the system. After imputing the item s ID number, the project team number, and the student s name and university ID number the status of the item is set to checked-out or checked-in depending on the submission type chosen by the course coordinator. The course coordinator is then directed back to the course coordinator main menu. 23

29 Add User Remove User $GG8VHU0HQX &RXUVH &RRUGLQDWRU,QSXW FRXUVH FRRUGLQDWRU LQIRUPDWLRQ 7KLVLQIRUPDWLRQLQFOXGHVWKH WHDPWKDWWKHIDFXOW\PHPEHU LVDQDGYLVRUIRU 6HOHFW 8VHU 7\SH )DFXOW\$GYLVRU,QSXW IDFXOW\ DGYLVRULQIRUPDWLRQ %DFNWR&RXUVH&RRUGLQDWRU0DLQ0HQX Figure 4-6 Course coordinator adds a user to the system 6WXGHQW,QSXW VWXGHQW LQIRUPDWLRQ 7KLVLQIRUPDWLRQLQFOXGHVWKH WHDPQXPEHUIRUWKHVWXGHQW 6LQFHNHUEHURV DXWKHQWLFDWLRQZLOEHXVHG RQO\WKHLQIRUPDWLRQZLOEH QHHGHG The course coordinator also wishes to have the ability to add and remove users from the system. To the left in Figure 4-6 is the flow of adding a user to the system. The course coordinator will choose to add a user from the main menu and will be prompted for the type of user they wish to add. They will then be asked to input information about those users and the system will create the user. Since the Kerberos Authentication System will be used, there is no need to identify a password for the user, and all passwords will then be considered secured. As the senior design course moves through the cycle of students, the need to remove users who are no longer in the course arises. From the course coordinator main menu, the coordinator chooses to remove users and then enters the id of the user to remove as shown in Figure 4-7. The system then removes the users account and directs the course coordinator back to the main menu. Figure 4-7 Course coordinator removes a user from the system 24

30 Add Inventory When an item is deemed durable and needs to be added to the inventory tracking system, the course coordinator selects the add inventory option from the main menu. There they will be asked to fill out information about the item and will be shown a check screen where they will be allowed to review the information and make changes if necessary. The action of viewing the check screen is shown in Figure 4-8. If the course coordinator has no problems with the information then they would then submit the item and the system will place it into the list of inventory. Figure 4-8 Course coordinator adds an item to inventory Remove/update status of an item The course coordinator has several things that they wish to do with an item in inventory. Figure 4-9 deals with the course coordinator s need to change the status of an item. For example the item may have been lost by the project team and need to be removed from inventory so that other project teams do not think that they could request the item at a later date. Another example would be an item that needs to be repaired because of a failure. The course coordinator would choose the option for updating the status of an item from the main menu. They would then choose the appropriate status for the item and would submit that to the system. The system would in turn log that status for the item and return the course coordinator to the main menu. Figure 4-9 Course coordinator changes the status of an item in inventory 25

31 4. Database design The database schema is designed to enable seamless integration of related data. Currently there is much to be gained by providing a mechanism to group related data together. As described above, a relational database model has been chosen to provide this grouping ability. The endresult will be a fully dynamic data scheme that will allow easy querying of specific information. As shown in figure 5-1 the schema has been set up to provide relations between different groupings of data. Logically, all data in the system will relate to a group. In that way, it is very easy to query for any piece of information by only using a group identifier. Groups will be an assortment of students, advisors, and course coordinators. Since all groups will relate to one set of course coordinators, querying by the course coordinator identifier will show all information in the system. Figure 5-1 Database Schema Functionally, both the order tracking and inventory tracking systems will be driven by a set of transactions. These will be stored in the OrderUpdates and InventoryUpdates tables. Every time there is an update to an order or inventory item, a record in the updates table will be made. This will allow orders to have a history and inventory items to be requested by multiply groups before an item is checked out. This is a key characteristic of the database schema design. It should be noted that the expense tracking will be drawn from the order table and subtables. The information needed to track expenses is already contained within the orders. Adding any additional expense information to the database will be redundant. 26

32 Resources and Schedules This section of the report deals with the resources the project team needs to fulfill the design as well as the schedule of the project. Estimated Resources The following section deals with the resources the project team feels are needed to complete the successful implementation of the design detailed in this report. Proposed Project Milestones and Evaluation Criteria Table 2-1 Project milestones 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 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 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. 27

33 Project Tracking Resource Requirements 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. The following section details the resources that the project team has defined for allocation to the completion of the design. Personnel effort requirements The following is a description of each individual task as was specified in the project plan. Each of these tasks needs to be completed in order to have a successful project. Table 6-1 below shows individual effort estimated for the following tasks as was specified in the project plan. The definitions of the tasks defined in this table are detailed on the following pages. Table 6-1 Original personal 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

34 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: Define requirements Objective: The team shall define the requirements of the system to the fullest extent possible. Approach: Through meetings with the client, the team shall determine the successful scenarios that are desired for the system. Results: The result of this subtask shall be the requirements of the system to be designed. Subtask 1c: 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 1d: 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 29

35 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. 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. 30

36 Task 4: Prototype implementation 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. Subtask 4c: Prototype implementation Objective: The team shall create a system prototype for evaluation of the project s milestones and goals. Approach: The team shall follow an iterative development methodology to create several prototype systems with increasing functionality Results: The result of this subtask shall be a prototype of the end product that can serve as an evaluation of the team s progress on the goals and milestones listed in this report. Task 5: Prototype Testing Subtask 5a: Basic functionality testing Objective: The team desires to test the functionality of the prototype. Approach: Through pre-developed sets of data, the team shall input the data to the system and determine if their implementation of the prototype is correct. Results: The result shall be a correct implementation of the basic functionality. Subtask 5b: Low level interface testing Objective: The team desires to test their implementation of the low level interfaces. Approach: Through pre-developed sets of data, the team shall input the data to the interfaces and log the results, checking that the data matches the pre-determined results. Results: The result of this testing shall be a correct implementation of the low level interfaces within the system. Subtask 5c: Data assurance testing Objective: The team wishes to check the prototype system s implementation for data correctness. Approach: Through pre-developed sets of data, the team shall input the data to the prototype and log the results, checking that the data matches the pre-determined results. Results: The result of this testing shall be a prototype that handles data correctly and stores it appropriately. 31

37 Task 6: Final product implementation Subtask 6a: Final product 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 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 entire system. Subtask 6b: Final product definition Objective: The team desires to have set benchmarks for the system. Approach: The team shall define the 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 the system team desires to develop. Subtask 6c: Final product implementation Objective: The team shall create the final system for evaluation of the project s milestones and goals. Approach: The team shall follow an iterative development methodology in conjunction with the prototypes developed to complete the system. Results: The result of this subtask shall be a prototype of the end product that can serve as an evaluation of the team s progress on the goals and milestones listed in this report Task 7: Final product testing Subtask 7a: 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 7b: 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 pre-determined 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. 32

38 Subtask 7c: 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 11). 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 8: End product documentation Subtask 8a: Creation of administrator s manual 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 8b: 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. The following describes the final two tasks that were added after the project plan as well as the revised totals for completed and future tasks. The revised personnel effort requirements are calculated in table 6-2 below and detailed on the following pages. Table 6-2 Modified personnel effort requirements Personnel Effort Requirements Task Number Individual Total Dan Balcauski Joe Cody Jason Hill Matt James Totals Task 9:End product demonstration Subtask 9a: Demonstration to project advisors Objective: The team desires to demonstrate its 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. 33

39 Subtask 9b: 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 10: Project reporting Subtask 10a: 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 10b: 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. 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. Other Resource Requirements In Table 6-3 the original additional required resources are described. These materials and time spent are required in order to complete the project. Table 6-3 Original additional resource requirements Item Team Hours Other Hours Cost Printing of project poster 0 0 $50.00 Totals 36 0 $50.00 These figures have been revised and updated to better meet the already accomplished tasks as well as the newly projected estimations. These numbers are specified in Table 6-4. Table 6-4 Modified additional resource requirements Item Team Hours Other Hours Cost Printing of project poster 0 0 $50.00 End User Documentation 0 0 $10.00 Software Literature 0 0 $50.00 Totals 36 0 $

40 Financial Resource Requirements Table 6-5 describes the amount of money that was estimated for parts and labor. A representation for how much the total cost would be if the laborers were paid at $10.50 per hour and also if the laborers were not paid. Table 6-5 Original financial resource requirements Item W/O Labor With Labor Parts and materials Poster $50.00 $50.00 Subtotal $50.00 $50.00 Labor at $10.50 per hour Balcauski, Dan $ Cody, Joe $ Hill, Jason $ James, Matt $ Subtotal $ Total $50.00 $ Table 6-6 describes the revised amount of money that was spent and will be spent for parts and labor. Again, this is a representation for how much the total cost would be if the laborers were paid at $10.50 per hour and also if the laborers were not paid. Table 6-6 Modified financial resource requirements Item W/O Labor With Labor Parts and materials Poster $50.00 $50.00 End User Documentation $10.00 $10.00 Software Literature $50.00 $50.00 Subtotal $ $ Labor at $10.50 per hour Balcauski, Dan $ Cody, Joe $ Hill, Jason $ James, Matt $ Subtotal $ Total $ $

41 Schedules This section of the report details the schedules for the completion of the project. Project Schedule The report now shall focus on the schedule of the project. The team developed a schedule of when the items in the statement of work will be completed based on an iterative software development methodology. Also note that this project spans a 3 month break in the course work at Iowa State University and our schedule takes into account no work during this summer break. Project Deliverables Detailed in Figure 6-1 are the deliverables for the Parts, Inventory, and Expense Tracker. These deliverables were created after detailed meetings with the project s client and deliberation among the team members. Many of the deliverables are published reports or presentations, and the proper time is allowed for completion of the deliverable. Figure 6-1 Original project deliverables Detailed in Figure 6-2 is the revised listing of deliverables for the Parts, Inventory, and Expense Tracker. A number of these deliverables have been accomplished and the actual dates in which they were accomplished are listed. The rest of the deliverables are listed in their revised estimated form based upon detailed meetings updating the original schedule. Figure 6-2 Modified project deliverables 36

42 Project Tasks Detailed in Figure 6-3 is the schedule for the project. This schedule was created with the tasks outlined in the statement of work and the semester schedule of Iowa State University as reference. The team decided it best that very little work occur during the week before finals week, also known as dead week. Students need to prepare for their final exams during this time. During the final semester of the project, the team will be giving their industrial review presentation during dead week, and preparations for this will be occurring throughout the final semester of the project. Figure 6-3 Original project tasks 37

43 Detailed in Figure 6-4 is the revised and updated schedule for the project tasks. This schedule was revised based upon the actual progress of the team and a better understanding of what it is going to take in order to successfully complete this project. Similar considerations were taken into effect regarding dead week as well as the groups overall ability to accomplish a certain task in the original amount of time. These, as well as other items, were all considered during the revision of the schedule. Figure 6-4 Modified project tasks 38