Evidence Inventory and Tracking Program Project Plan



Evidence Inventory and Tracking Program Project Plan

Dec04-07

Client:

Boone Police Department

Advisors:

Thomas Daniels

Mani Mina

Team Members:

Andrew Bitterman

Royson Chong

Yin-Cheung Lo

Jennifer Sanders

February 10, 2004

Table of Contents

1 Introductory Materials iv

1.1 List of Figures iv

Table 5-2. Deliverable Table Error! Bookmark not defined.

1.3 List of Definitions vi

1.4 Abstract 1

1.5 Acknowledgement 1

1.6 Problem Statement 1

1.7 Solution approach 1

1.8 Operating Environment 2

1.9 Intended Users 2

1.10 Intended Uses 2

1.11 Assumptions 2

1.12 Limitations 2

1.13 Expected End Product and Other Deliverable 2

2 Proposed Approach 4

2.1 Functional Requirements 4

2.2 Constraints Considerations 5

2.3 Technology Considerations 5

2.4 Technical Approach Considerations 6

2.5 Testing Requirements Considerations 6

2.6 Security Considerations 7

2.7 Safety Considerations 7

2.8 Intellectual Property Considerations 7

2.9 Commercialization Considerations 8

2.10 Possible Risks and Risk Management 8

2.11 Project Proposed Milestones and Evaluation Considerations 9

2.12 Project Tracking Procedures 10

3 Statement of Work 11

4 Estimated Resource Requirement 19

4.1 Personal Effort Requirements 19

4.2 Financial Requirements 20

5 Schedules 21

5.1 Project Schedule 21

5.2 Deliverable Schedule 22

Table 5-2. Deliverable Table 22

6 Student Team Information 23

7 Closing Summary 24

References 24

Appendix A 25

Appendix B 26

1. Introductory Materials

1.1 List of Figures

Figure 5-1. Project Schedule………………….......………………………………………….….21

Figure 5-2. Deliverables Schedule………………………………………………………………22

Figure A-1. Property/Evidence Form……………………………………………………...…….25

Figure B-1. City Incident Report – Front…………………………………………………..……26

Figure B-2. City Incident Report – Back……………………………………………………...…27

1.2 List of Tables

Table 4-1. Estimated Personal Effort Hours…………..………………………..…….…………19

Table 4-2. Financial Budget…………………….………………………..……..…..…….…..…20

1.3 List of Definitions

Chain of custody – A list of where the select piece of evidence has gone and when, and who checked it out.

Evidence – The documentary or oral statements and the material objects admissible as testimony in a court of law.

Graphical user interface (GUI) – A user interface based on graphics instead of text; uses a mouse as well as a keyboard as an input device

Java – An object-oriented programming language developed by Sun Microsystems. Java supports programming for the Internet in the form of platform-independent Java applets.

Personal Digital Assistant (PDA) – A lightweight, hand-held, usually pen-based computer used as a personal organizer

1.4 Abstract

Evidence can be the key to convicting someone of a crime, or acquitting a person of charges brought against them. So it is very important that the evidence is handled carefully and is carefully documented and tracked exactly what the client wants to be included and then make the evidence tracking have those options. Then move on to the searching, reporting, and printing.

In the end the police department will be able to search for evidence via a network by storage location, victim's name, suspect's name, case number, date, or description. This would be a very helpful tool for many different applications, either for evidence or writing a research document. This would help out the police department very much as it will help organize the data and help with the clutter paperwork may cause.

1.5 Acknowledgement

Chief Dan Losada of the Boone Police Department has provided consultation and input into what is required and what exact specifications shall be. He has also provided forms for Incident Reports and for property/evidence. He has also given links to different websites to use as references.

1.6 Problem Statement

Evidence is crucial to court cases. It can contribute to the decision of if a criminal goes to jail or goes free. Keeping track of the evidence, however, can be a task, and if it doesn’t have a complete chain of custody, it won’t be admissible in court. The chain of custody is dire in the case of evidence. If a person checks out the evidence and it never shows back up again, you know who to turn to first. Another problem is the organization of all of the evidence. Sometimes there can be so much, things are hard to keep track of, or if something fell off a shelf and you don’t know where it goes, it could get misplaced. All of these factors must be taken into consideration when designing the program.

1.7 Solution approach

To solve these problems a database will be created. One that can’t have entries deleted unless by an authorized figure. The program will also have its own form of a search engine to search for certain fields of the evidence (victim, suspect, evidence type, etc). This will help with the problem of things falling on the floor (do a search on what was found). This program will also have network capabilities, so that a person in another room can be looking up evidence at the same time.

1.8 Operating Environment

Since this is a program run on a network of computers of which will be required to remain inside, the environment will remain static for the most part. The air temperature will range from 60-75 degrees Fahrenheit. If a computer is located in the lower level of the building, then the temperature will be cooler, and the air will be damper.

1.9 Intended Users

The intended users for this program are strictly the people within the Boone Police Department. And even then, only certain people will have certain capabilities. Nobody outside of the department would be allowed to have access to it. Since adults will use this, a higher level of language can be used and things won’t be required to be very basic (as for a child that would be required). However, this must not be too complicated because someone may be less knowledgeable about computers and still need to use it.

1.10 Intended Uses

This program will be used in the tracking of evidence. It will create an object for each collected piece of evidence and keep track of them. It will also allow for the search of certain key words to find out things about the evidence.

1.11 Assumptions

□ The user has basic knowledge of Microsoft Windows XP.

□ The user has proper storage space for backup.

□ There will only be eight workstations running the program.

□ All users understand English.

□ All users understand the current manual process for evidence tracking.

1.12 Limitations

□ The program must be complete by December 2004.

□ The program must be compatible with Microsoft Windows XP.

□ The max response time must be less than ten seconds.

□ The server computer must have a backup and restore capability.

1.13 Expected End Product and Other Deliverable

Before the end product is delivered to the client, a prototype will be given to them to see if it meets their needs and expectations. This prototype will include screenshots of what the final product will look like. It will also include explanations of what certain parts do and their operations. There will also be an explanation of how they would do all tasks they perform related to the program.

The final product will be the actual program written based off the prototype with all of the changes and corrections made. It will allow for officers to enter new evidence into the database, search the database for a particular item (via a few different specified fields), and even print off tags to go with the actual piece of evidence. The final program may offer some sort of compatibility with a signature pad or other identification piece of hardware. It may also offer compatibility with a PDA, but this is a low priority option which will be implemented only if there is enough time.

The PDA would be used down in the evidence room to look for a specific piece of evidence and to know exactly what that item entails. For example, if there was a bag with multiple items in it under one number, then the PDA would be able to tell what shall be in the bag, so the officer knows.

A final report will also be delivered to the client. This document will contain a manual for the end product, and describe the functions of the program. It should state all of the problems encounters and the solutions for each, a summary of the entire project, and any identification of future work that may be done on the program.

2. Proposed Approach

The proposed approach includes a definition of the functional requirements, constraints considerations, technology considerations, technical approach considerations, testing requirements considerations, security considerations, safety considerations, intellectual property considerations, commercialization considerations, possible risks and risk management, project proposed milestones and evaluation criteria, and project tracking procedures. All of the above are necessary for making the project successful.

2.1 Functional Requirements

The end product should entail:

1 Create a database with at least 2-level access restriction

. In order to insure security of the database, access to the program is limited. The first level of access allows all users to view, search through, and add to the database. The second level of access allows only authorized users to view the actions which have taken place within the database (such as who viewed which items, etc).

2 Be able to add evidence and attach file(s)

. On the first level any user can add new evidence with a description and details of the evidence. Also the user can attach any type of files (e.g. pictures, documents) to the evidence.

3 Be able to search through database with specific field

. On the first level any user can search through the database with case number, victim’s name, suspect’s name, evidence type, etc. A list of corresponding evidence will be found sorted by a specific field.

4 Nothing can be deleted within database

. For protection of the evidences, no item in the database can be deleted. Evidence that is no longer needed (i.e. case closed) may be physically destroyed, but the record shall still be kept in the database but will be listed under different catalog (e.g. destroyed evidence, end-of-case evidence).

5 Auto-log database activities

. All activities within the database will be recorded. Examples: add/change items, search/review items, any correction made to any item, who performed the action, etc.

6 Events notification

. The user will be notified for certain time-based events such as a deadline for a court trial (either auto-generated or under request). The notice will be provided in the format of either a pop-up notice or in a notice/announcement page.

7 Provide visual user interface

. A visual interface will be created for interaction between the program and user. The interface will be in a form-base format for user convenience.

8 Windows XP compatible and user friendly

. The program shall be designed for the Windows XP platform. It must also be user friendly in order for the user(s) to take best advantage of the program.

9 Allow easy backup

. The program shall be in a format that allows easy and frequent backup in order to protect important information in the database.

10 System failure must not affect database

. The program shall be stable running in Windows XP. If a system failure shall occur, the database must not be affect by it and data shall not be corrupted.

2.2 Constraints Considerations

The end product’s constraints are:

1 Database Size

. The database size shall be expandable and program shall be able to handle the increasing number of evidence entered.

2 Disk Space

. The database shall be designed to suit the disk space limits that the client currently has. If extra disk space is required, the client may be required to purchase an additional hard drive within an affordable budget. This size is hard to determine because the number of evidence is variable and each item is also variable (e.g. each piece may have many pictures, requiring more space).

3 Computer Resources Usage

. Since computer resources are limited, the program will efficiently manage the usage of computer resources and allow multi-tasking on the computer stations.

4 Technical Support

. Since there is no technical support available for the client, the program will be designed to be very stable and minimize the need of technical support.

5 Budget Limitation

. With the limited budget provided, any required hardware/software would need to be inexpensive and potentially donated and/or sponsored.

2.3 Technology Considerations

A number of programming languages and platforms could be used to develop the program. Since the program contains a large database, database languages such as SQL will be considered. SQL is a powerful database language that is easy to implement. Although it does not provide GUI implementation, it can be used with other general-purpose languages such as Java (e.g. JDBC, a hybrid of Java and SQL) to provide both database and GUI implementation.

Other languages such as C/C++ will also be considered. However, using C/C++ will require a platform to provide the GUI implementation. One possible choice would be Visual Studio .NET which allows the use of visual C/C++. The disadvantage of using Visual Studio would be the requirement for all client computers to have Visual Studio .NET installed in order to use the program the team created.

The team members will do research for the most suitable programming language and platform to be used for designing and implementing the end product based on the above deliberations. Research will include suggestions from project advisors and academic professors, Internet research for information about different programming languages and platforms, and personal experiences with each possible programming language and platform. The final decision will be made based on the ease of learning, ease of integration of a database with the particular programming language, and individual experience of team members on particular language.

2.4 Technical Approach Considerations

In order to be successful in developing the project, many software development techniques shall be applied. First of all, the team shall develop a detailed project plan with most of the requirements and considerations needed. The team shall design the details of the program based on the project plan and present it to the client. Changes shall be made after the presentation to the client if needed and more information may be added to the plan. Ideally, all details will be corrected at this point and by the end of the semester, a complete prototype will be created and will be presented to the client again. The prototype will show how all of the required functions work with the user (e.g. how to add a new item, and what the screen will look like. An example can be seen in Figure A-1 on page 22).

While working on the prototype in the first semester, some implementation may be developed. In the second semester, the team shall fully implement the rest of the program and shall get a draft of the end product finished by the middle of the second semester. If time and resources are permitted, the team will implement extra features to advance the program. By the end of the second semester, an end product shall be ready to be delivered and a final presentation shall be given to the client.

2.5 Testing Requirements Considerations

All functional and design requirements shall be reviewed before implementation begins to keep costs low. The cost and time required to change details in the design phase will be much less than changing them in development phase. The program will be tested by the team at periodic intervals during implementation in order to minimize the existence of bugs and errors and eliminate bugs in early development phases. This also will minimize the cost and time spent. This testing will be planned while designing the implementation, because the program will be amorphous during the implementation, due to bugs and addressed problems. The team will then know how to test that part of the program.

A large number of tests shall be run by the team on the final product before releasing it to ensure all features are working properly and all requirements are met. The client, aided by the team, will also test it to make sure there is ease of use, and it functions as they would like. Tests shall be run to check if the program can handle different exceptions (e.g. erroneous data input, abnormal operation condition, etc). The product shall be tested on a Windows XP platform to ensure proper performance. The final product shall be tested rigorously on the client’s computer to ensure stability, performance, and reliability.

2.6 Security Considerations

Since the program will be primarily developed for the record of the chain of custody for evidence, security is the most important factor within the program. Security features shall be added to the program in the later development phases after the basic structures of the database have been developed. Security features shall include a 2-level access restriction, as described in the functional requirements, and possible electronic signature pad and/or fingerprint scanner to require authentication for modifying the database and/or making changes to evidence entries.

For document security, all documents and code shall be saved in soft copy form in 2 different places, 1 soft copy in team ftp and at least 1 soft copy by the team member for their own portion of the document/code as backup. Hard copies shall be printed and kept in a safe place with at least one going to the project advisors. Backups shall be made every time there is a change made to the project or document and version control will be used.

2.7 Safety Considerations

This project, being a program, doesn't have any real safety considerations due to health and well being of team members or the client.

2.8 Intellectual Property Considerations

The end product shall be developed primarily for the Boone Police Department. However, the team will consider applying the free software license, GPL (general purpose license), on the product. GPL allows the product to be free for other users, and basically allow others to use it and do anything they want on it.

2.9 Commercialization Considerations

There is still consideration to move towards commercialization. If the product is well liked and has features that are able to compete with current commercial evidence inventory and tracking programs, then this option may become more plausible. However, if the final product’s features are specifically what the client wants, just enough for the program to be reliable and secure, then commercialization won’t be an option.

2.10 Possible Risks and Risk Management

With a project of this size, there are many risks involved. The potential risks for the project include:

1 Lack of professional expertise

. Because most of the team members are not familiar with database development and management, it will require time for those team members to learn the language chosen for the project. Underestimating this risk may result in a delay of the release of the product or incompletion of the project. This particular risk can be reduced with good time and task management.

.

2 Loss of team member

With any project, there is the possibility of losing a team member. To deal with this risk, each team member will be required to keep accurate and detailed information on their part(s) so the other team members can fully understand what is going on and can pick up where the lost member left off.

3 Loss of project data

. The risk of losing project data could have a huge impact on the project timeframe and completion. If data is lost, time spend on the project could double because previous effort will have been wasted. A possible solution to avoid such risk is to have multiple backups in different locations, both soft copy and hard copy. Backups shall be made regularly, and copies of backups shall be kept both in the project ftp folder and on individual team members’ computers. A hard copy shall be made and kept by an academic advisor and/or team members.

4 Resource availability

Due to the limited budget, resources must be restricted to low-cost software and hardware. Donations are another option to follow. If only a few of the more expensive items are donated, this would be a major help in keeping cost down. If certain features cannot be obtained cheaply, and the project goes over budget by quite a bit, the feature may be dropped or changed to get back under budget. Some risks of going over budget can be mitigated by planning ahead with clearly defined unknown variables, and also start searching for donors/sponsors ahead of time to give sufficient amount of time for alternative solutions if donors/sponsors are not available.

2.11 Project Proposed Milestones and Evaluation Considerations

To keep the program on schedule and to make the work easy to evaluate, milestone will be used. They are as follows:

1 Project statement and definition

. The project statement shall be well defined and all the needs from the client shall be included. Assumptions, limitations, and intended uses and users shall be stated clearly. This will give the team a starting point for the design and relationships within the program.

.

2 Proposed solution

. All functional requirements and considerations shall be clearly described in detail and reviewed by the client to make sure all requirements meet the client’s needs. This gives a better idea of how to implement the required functions for the program and sets some of the limitations the team can reach in design.

.

3 Design

For the design, the assumptions, limitations, requirements and considerations must be finalized. Some of these still may change, however, as tests are conducted and results are found. Actual ideas shall be formed and all unknown variables shall be now defined (e.g. programming languages and platform used), because detailed specifications are required for implementation phase. If this isn’t done, then the program won’t get off the ground and will be a failure.

4 Implementation

. Reviews shall be made regularly throughout coding to make sure the implementation fits the functional requirements and design requirements. This needs to happen frequently to make sure the program is going in the right direction and isn’t skewing off course. If not done correctly, then the client may end up with a program that doesn’t do what they want it to.

.

5 Testing

. The program shall be fully tested with different testing method. Tests shall be run to ensure stability, performance, reliability, quality, functionality, etc. If this part doesn’t occur, then the code will be full of bugs and unanticipated problems. This could forfeit the stability of the program and cause it to crash or cause other fatal problems. It is also important so that all of the functions are working correctly.

.

6 Demonstration

. The end product shall be fully tested and appear bug-free. The final product shall be presented to the class and client.

.

7 Final report

. Formal documentation on the project includes a summary of overall performance, cost, features, and implementations. This will also have a manual for the client so they know how to use the program if they don’t know already how to. The project should be completely finished by this time and be delivered to the client.

2.12 Project Tracking Procedures

The project plan will be the road map for project tracking. Weekly status report shall be used to track progress of project and difficulties/problems encountered. The project schedule shall be updated weekly and any tasks that are behind schedule shall be discussed and corrected at weekly meetings. If the team gets behind schedule, then extra meetings will be held to do extra work and get back on schedule.

3. Statement of Work

This section details the approach the team will use to complete the project. This section is broken into the categories shown below:

Task 1: Problem Definition

Subtask 1a: Identify End User(s) and End Use(s)

Objective: To understand the various features of the product.

Approach:

It is very important to know who the users will be and what they will use it for. The steps to understanding these are as follows:

• The client will be contacted as often as necessary to establish the users and how the users shall manipulate the system.

• The advisors will be consulted upon establishing a summary of anticipated users and how the users shall manipulate the system.

Expected results:

• The team shall fully understand how the client party will interact with the system.

Subtask 1b: Identify Project Constraints and Limitations

Objective: To understand the limitations of the product.

Approach:

Knowing the constraints and limitations for developing the program is crucial to the success of the project, because the team must know their boundaries. The steps to knowing these are:

• The team shall discuss with the advisors and decide which aspects of the project the team shall accomplish based on current skills and knowledge of the team members.

• The team shall inform the client on aspects of the project that could be implemented.

• The aforementioned portions will be implemented only if resources permit.

Expected results:

• The team shall narrow the focus of the project in a manner that satisfies the client’s needs but also fits the capabilities of the team.

Task 2: Technology Considerations and Selection

Subtask 2a: Research existing systems

Objective: To be able to choose the best platform and languages to use.

Approach:

Seeing other programs currently on the market is vital to having the program be competitive and successful. It also gives ideas on what features to include. To achieve success, the team will do the following:

• The team shall consult the client to find information about current commercial systems that cater to the client’s needs.

• The team shall conduct further research via the Internet or read through journals related to new technologies in the field of law enforcement.

• The team shall look into current commercial systems that mimic the needs of the client.

• The team shall try to understand how these systems function by manipulating these systems and interpret their results.

Expected results:

• The team shall have a clear idea on how to implement the project on a conceptual level.

Subtask 2b: Research Existing Programming and Database Management Languages

Objective: To have a good understanding of the available languages.

Approach:

Before the design the team must know the best languages to use for development. The steps to find the best one are:

• Each teammate shall state what programming and database management language(s) known.

• The team shall decide what programming and database management languages based on what the majority is familiar with.

• Additional programming and database management language(s) shall be considered if the benefits outweigh the time needed to learn.

Expected result:

• The team shall select the programming and database management language(s) that suits the capabilities of the team.

Task 3: End-Product Design

Subtask 3a: Automate Input Entry Procedure for Client

Objective: To ease entry of data and attachable files.

Approach:

Providing the right fields for input from the user is essential. To do this correctly the following must be done:

• The team shall contact the client to see if any input procedures can be automated by the project.

• The team shall obtain non-protected forms such as the ones presented in Appendices A and B.

• The team shall design the project in a manner that conveniences the client’s input entry procedures.

Expected result:

• The client requests that the team shall create a project that facilitates forms used for current input entry procedures.

• The functions to be performed will depend on the access level of the user. Anyone who is level one can add an item to the database, add data to an already existing item, and search the database for an item. A level two user can see what actions have taken place within the database. This is explained in the functional requirements section above.

Subtask 3b: Break down project to facilitate implementation

Objective: To allow for simultaneous work on different parts of the project.

Approach:

For the program to get done on time, it must be split up into parts, and each team member must have a good idea of what the relationships are between all of the objects. These steps will be used:

• The team shall identify key components to work on, e.g. information retrieval from the database or input entry from user.

• The components shall be decided based upon research of current technologies, limitations of selected programming and database management languages and the needs of the client.

• Every member shall know in detail how each component relates to the other, what each component needs as inputs and what each component will output.

Expected result:

• The team shall have a clear understanding of the different components needed to complete the project and how they interact with one another.

Task 4: Prototype Implementation

Subtask 4a: Work delegation

Objective: To make it clear to each team member what they are expected to do.

Approach:

Each member must know their role in the project and not to others work or not do their own work. To keep each individual on the right tasks these steps will be followed:

• Each teammate shall be assigned certain components to work on depending on the individual’s exposure, skill level, specialties and willingness.

• Each teammate will work on their parts and present updates during the weekly meetings.

• If any member has any concerns or clarifications, the entire team will look at the matter and decide on the best solution.

Expected results:

• Each team member shall be given an appropriate amount of work that is manageable according to the teammates’ competency.

• The team shall be able to complete the project within the allocated amount of time.

Subtask 4b: Code Generation and Screenshot Mockups

Objective: To provide a prototype that will allow the client to provide feedback.

Approach:

The client must know what they are getting for a program. Using individual prototypes throughout development will help keep both the client and team informed on what the project is to do and what it is to not do.

• A screenshot will be used to determine if the correct information is being stored and displayed. These will be created by various means and some functions will be coded to give an example of their workings.

Expected results:

• The client will use these mockups to give feedback on improvements that need to be made to the end product.

Subtask 4c: Code documentation

Objective: To make code readable and able to be modified easily.

Approach:

Code changes often, so the code must be easily changeable, readable and understandable.

• All members of the team shall use proper code documentation frequently.

• Every teammate shall code in a manner that is easy for other team members to understand if they need to view the code.

Expected results:

• The code written for the project shall be very readable.

Task 5: End-Product Testing

Subtask 5a: Individual Component Testing

Objective: To eliminate any bugs in each individual component.

Approach:

Each member must come up with their own testing of their components of the code as they progress through the implementation. This will allow for faster coding and testing in the long run. These steps will be used:

• Members shall separately test the components assigned to them.

• If anomalous output is detected, the member responsible for that component shall debug that code.

• The team shall continuously validate and verify that all components in the project execute as expected.

Expected results:

• Each component in the project shall be error-free and ready to be integrated into the final application.

• The testing will be planned as the implementation is planned, because the code will change often as will some of the design as snags are hit.

Subtask 5b: Component Integration and Testing

Objective: To further eliminate bugs in the interfaces between components.

Approach:

When a part of the program is finished and tested, it needs to be combined with other parts and then tested. The team will use the following steps:

• The team shall integrate the components that closely work together in smaller groups and conduct tests to ensure correct input and output

• If any problems surface, the team members assigned to write the specified components shall work together to rectify the code.

• The team shall repeat this process until all components have been successfully integrated.

Expected result:

• The team will successfully integrate all components together.

Subtask 5c: Whole System Testing

Objective: To fully test and ensure proper working of the system as a whole.

Approach:

Once the program is finished and each part is tested, then the entire program needs to be tested for problems that may not have occurred when the individual parts were tested. The steps for this are:

• The team shall create sets of input to test as many possible scenarios as possible.

• If any set of input causes the system to produce inaccurate output, the team shall look into the problem and rectify the code.

• The client, with the team’s aid, will test the code also to make sure it does they functions wished for.

Expected result:

• The team shall successfully complete the system that the client envisioned.

Task 6: End-Product Documentation

Subtask 6a: Develop User’s Manual

Objective: To provide a reference for the client if questions should arise.

Approach:

The client needs to know how to use the program if they are stuck. They also may need to have someone else look at it, and so that person will need to understand it too. Therefore the team must do the following:

• The team will document the usage of the system from the user’s point of view.

• The team will research manuals to determine the format to use for the project.

• The team and advisor will view the completed manual for proofreading purposes and to ensure ease of reading.

Expected result:

• The team will create a manual that the client can easily read and refer to.

• The manual will include information on how to install the program, instructions on how to do tasks, etc.

Task 7: End-Product Demonstration

Subtask 7a: Demonstration Planning

Objective: To prepare for presentations to various people/groups.

Approach:

The team will show the end product to the audience to show what the program can do. The steps to this preparation are as follows:

• The team shall decide who shall present which components of the project.

• All members shall prepare screenshots, diagrams, or any other visual aids to facilitate audience understanding of the subject matter.

Expected result:

• Each member shall know what aspect of the presentation to work on.

Subtask 7b: Faculty Advisors Presentation

Objective: To gain feedback and refine presentation.

Approach:

The presentation of the project is important to let people know what the team has accomplished. To give a good presentation, the team will:

• The team shall present the entire project to the advisors.

• Members shall note comments made by the advisors and improve their section based on those comments.

Expected result:

• The team shall practice and fine-tune its presentation.

Subtask 7c: Industrial Review Panel Presentation

Objective: To present a well planned presentation.

Approach:

This is a very important presentation and must be done very well, because people from the industry will actually see the project.

• The team shall present its project to the industrial review panel based on the recommendations given by faculty advisors.

Expected result:

• The team shall successfully present the project to the industrial review panel and note comments made.

• The comments made by the industrial review panel shall be included in the documentation for future work.

Task 8: Project Reporting

Subtask 8a: Weekly E-mails of Project Status

Objective: To inform team members, advisors, and client of weekly progress.

Approach:

To keep on track it is important that everyone involved in the project talk often. To do this the team will:

• There will be weekly meetings with the faculty advisors to discuss the progress of the project and any matters that may arise.

• There will be weekly e-mails to faculty advisors, team members and the client on the weekly progress summary.

Expected result:

• The report shall keep faculty advisors and the client aware of the progress made on the project.

Subtask 8b: Project Plan

Objective: To clearly define the objectives for the project.

Approach:

The planning of the project is important to getting the project off the ground. To do this there are a few things that need to be figured out first:

• Major details, such as the scope, need to be decided on to be included in the project plan.

Expected result:

• The report shall keep faculty advisors and the client aware of the progress made on the project.

Subtask 8c: Project Poster

Objective: To inform the public of the objective for the project.

Approach:

Having other people see what the project will entail is important. To do this, a visually appealing poster will be designed using these steps:

• The main features for the project need to be identified and pointed out in a professional and appealing manner to show the need for the program.

• The team will look at other posters from the past for ideas.

• The team will come up with a color scheme that is easy on the eyes, yet is appealing.

• Graphics will be used to draw attention to the poster, but will still serve a purpose in getting ideas about the project across to the audience.

Expected result:

• The poster will be informative to people not on working on the project and will visually attract attention.

Subtask 8d: Design Report

Objective: To clearly define the technical plan for the project.

Approach:

The design of the project is important to know how objects are going to work together. It is also important to the performance of the program.

• Each item and feature of the program will need to be looked at and then explained in detail, and an overall explanation of the program would also need to be included.

Expected result:

• The final program will be explained in a report in which people outside the program can understand.

Subtask 8e: Final Report

Objective: To evaluate and describe the final project.

Approach:

A final evaluation of the project is important to having an understanding of how well the program runs.

• Each individual feature and part of the program will need to be evaluated for functionality, security and usability.

• An overall evaluation would need to be done on the program.

Expected result:

• The final program will be evaluated and the results will be shown in the final report so people outside the program can understand what the data means.

4. Estimated Resource Requirement

These tables give an estimate of the time and money required to finish the project.

4.1 Personal Effort Requirements

An initial personnel effort budget plan is given below. The team will attempt to meet these estimated hours as closely as possible, but it is possible that this will not be attainable.

Table 4-1. Estimated Personal Effort Hours

|Names |Task 1 |Task 2 |

|Materials: |  |  |

|Barcode Scanner (1) |$25.00 |$25.00 |

|Poster |$50.00 |$50.00 |

|Subtotal |$75.00 |$75.00 |

|Labor at $10.50 per hour: |  |  |

|Andrew Bitterman |  |$1,543.50 |

|Jennifer Sanders |  |$1,564.50 |

|Royson Chong |  |$1,606.50 |

|Yin-Cheung Lo |  |$1,585.50 |

|Subtotal |  |$6,300.00 |

|Additional Hardware (time permitting): |  |  |

|Electronic Signature Pad (1) |$60 (donated) |$60 (donated) |

|PDA (1) |$200 (donated) |$200 (donated) |

|Subtotal |$260 |$260 |

|Total |$335 ($75 direct cost) |$6,560 |

5. Schedules

The following is a projected schedule for this project. It will be used to determine if the project is on, behind, or ahead of schedule.

5.1 Project Schedule

Figure 5-1. Project Schedule

[pic]

5.2 Deliverable Schedule

This Gantt chart shows when deliverables for the project are due.

Figure 5-2. Deliverables Schedule

[pic]

6. Student Team Information

The following is a list of people involved in the project along with their contact information.

Student Team Members:

Andrew Bitterman (CprE)

114 S. Hyland #6

Ames, IA 50014

(515) 460-2077

abitterm@iastate.edu

Jennifer Sanders (CprE)

614 Billy Sunday Rd. #107

Ames, IA 50010

(515) 292-5249

jennif@iastate.edu

Royson Chong (CprE)

2717 West Street, Apt #5

Ames, IA 50014

(515) 268-0588

royson@iastate.edu

Yin-Cheung (Miranda) Lo (CprE)

902 Pinon Dr. #3

Ames, IA 50014

(515) 292-3051

lolo@iastate.edu

Advisors:

Tom Daniels

3222 Coover Hall

Ames, IA 50011

(515) 294-8375

daniels@iastate.edu

Mani Mina

314 Durham Center

Ames, IA 50011

(515) 294-3918

mmina@iastate.edu

Client:

Boone Police Department

Chief Dan Losada

(515) 432-3456

(515) 432-1564 fax

dlosada@city.boone.ia.us

7. Closing Summary

The Boone Police Department is very concerned with the chain of custody of all evidence. This product will allow for an easy and reliable way to track the chain of custody as well as keep track of the item details and locations of all evidence in the police department’s custody. No deletions will be allowed so information entered into the database will be admissible in court. If time and budget permits, the use of a PDA for inventory purposes and a digital signature pad for tracking purposes will be incorporated.

References







Appendix A

Figure A-1. Property/Evidence Form

[pic]

Appendix B

Figure B-1. City Incident Report - Front

[pic]

Figure B-2. City Incident Report - Back

[pic][pic][pic][pic]

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download