Evidence Inventory and Tracking Program Project Plan



Evidence Inventory and Tracking System

Design Report

DEC 04-07

Client

Chief Dan Losada

Boone Police Department

Advisors

Prof. Thomas Daniels

Prof. Mani Mina

Team members

Andrew Bitterman

Jennifer Sanders

Miranda Lo

Royson Chong

Table of Contents

List of Figures ii

List of Tables iii

List of Definitions iv

1 Introductory Materials 1

1.1 Abstract 1

1.2 Acknowledgement 1

1.3 Problem Statement 1

1.4 Solution approach 1

1.5 Operating Environment 2

1.6 Intended Users 2

1.7 Intended Uses 3

1.8 Assumptions 3

1.9 Limitations 3

1.10 Expected End Product and Other Deliverable 3

2 Proposed Approach 4

2.1 Design Objectives 4

2.2 Functional Requirements 4

2.3 Constraints Considerations 5

2.4 Technology Considerations 6

2.5 Technical Approach Considerations 6

2.6 Testing Requirements Considerations 7

3 Detailed Design 8

3.1 User Level 8

3.2 Graphic User Interface (GUI) Design 13

3.3 Database Design 15

4 Resources Requirements 17

4.1 Personnel Effort Requirements 17

4.2 Financial Requirements 19

4.3 Schedules 21

Appendix A 25

Appendix B. 26

List of Figures

Figure 3-0. Overall architecture of the project software…………………………………………..8

Figure 3-1.1. Permitted actions for level-1 users……………………………………………….....9

Figure 3-1.2. Overall structure of level-2 users………………………………………………….11

Figure 3-2. Overview of the GUI………………………………………………………………...13

Figure 3-3. Architecture of the database…………………………………………………………15

Figure 4-3.1. Original Schedule………………………………………………………………….22

Figure 4-3.2. Modified Schedule………………………………………………………………...23

Figure 4-3.3. Project Datelines…………………………………………………………………..24

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

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

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

List of Tables

Table 1-1 Main Evidence Items Table…………………………………………………………...2

Table 1-2 Chain of Custody Table……………………………………………………………….2

Table 4-1.1. Original Estimated Personal Effort Hours…………..…………………….……..…18

Table 4-1.2. Revised Estimated Personal Effort Hours………………………………………….18

Table 4-2.1. Original Financial Requirements…………………….…………………...….…..…19

Table 4-2.2. Modified Financial Requirements………………………………………………….20

List of Definitions

Chain of custody – A list of where the selected piece of evidence has gone, when the selected piece of evidence was gone, 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

PHP Hypertext Preprocessor (PHP) – A server side scripting language which will be used to write the program.

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

1 Introductory Materials

This section will define the problem, operating environment, intended users and uses, assumptions and limitations, and expected end product of the project.

1.1 Abstract

Evidence can be the key to convicting someone of a crime, or acquitting a person of charges brought against them. As such, it is very important that the evidence is handled carefully, documented in detail and tracked

At the end of this project, the Boone 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 greatly assist the Boone Police Department as it will organize the data and reduce the clutter of paperwork.

1.2 Acknowledgement

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

1.3 Problem Statement

Evidence is crucial to court cases. It can contribute to the decision if a criminal goes to jail or goes free. Keeping track of the evidence, however, can be a tedious task. If the evidence does not have a complete chain of custody, it will not be admissible in court. The chain of custody is dire in the case of evidence. If a person checks out the evidence and that item is never returned, the authority will know who to question. Another problem is the organization of all the evidence. If there are too many pieces of evidence, they can be hard to keep track of. These factors must be taken into consideration when designing the program and the database.

1.4 Solution approach

To solve problems described in the problem statement, a database will be created. This database can not have entries deleted unless by an authorized figure. The program will also have its own form of a search engine to look for certain fields of the evidence (victim, suspect, evidence type, etc). This program will also have network capabilities so that a person in another room can be looking up evidence at the same time. The program will be written in PHP to allow easier compatibility with the SQL database and it allows network connect ability. The two table setup for the first prototype can be seen below:

Table 1-1. Main Evidence Items Table

|Item # |Case # |Date |Officer |Type of Evidence |

|11 |Sanders |Locker 3 |Sanders |012804/0809 |

|11 |Locker 3 |Shelf 55 |Adasol |020204/0727 |

| |  |  |  |  |

| |  |  |  |  |

Table 1-1 shows the main evidence item table. This is where all of the data pertaining to each item will be stored. Searching the table will be an option for the user. The user will be able to search the fields of the table using a search page; for example, a user could search by case number to find all of the evidence involved in that one case. Each item will have its own item number. Table 1-2 is the chain of custody table. This table will be sorted by the item number.

1.5 Operating Environment

Since this is a program that runs on a network of computers, which will be required to remain indoors, 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, the temperature will be cooler and the air will be damper, but we do not anticipate a computer to be in this location at this time.

1.6 Intended Users

The intended users for this program are strictly the people within the Boone Police Department. Even then, a controlled login will provide controlled access levels. 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 the interface will not 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.7 Intended Uses

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

1.8 Assumptions

□ The user has basic knowledge of Microsoft Windows XP.

□ The user has proper storage space for the backup of the database.

□ The information in the database will be stored for approximately two years or depending on the needs of the client which may change.

□ There will only be eight workstations running the program.

□ All users understand English.

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

1.9 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.10 Expected End Product and Other Deliverable

In the first semester, we shall deliver our Project Plan to the client. The client shall see if we understood the requirements or seek clarifications if needed. The team shall then work a the design that satisfies all needs of the client stated in the Project Plan. Upon completion, we shall once again deliver the Design Document to the client.

Before the end product is delivered to the client, a prototype will be presented 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.

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 as explained above), 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.

To facilitate ease of learning to use the end product, we will create a detailed user manual. for our client. We will ask a few personnel to use the product and see what difficulties they faced. If the issue is not covered in the user manual, we will make refinements. This will continue until we produced a comprehensive user manual.

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

This section provides the details of the approach and design that describe the process of developing the end product.

2.1 Design Objectives

The end product shall be designed to provide:

1 User Interface

The program will have an easy to use interface that is well laid out and easy to enter information into the database.

2 Login System

The program shall have a login system to identify who is using it.

3 Chain of Custody Access

The program shall effectively keep a chain of custody for each piece of evidence.

4 Internally Accessible

The program shall be easy to access within the internal local area network.

5 Easy Updating

Information about evidence shall be easy for officer and administrators to update.

2.2 Functional Requirements

The end product should entail:

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

. In order to ensure 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, date/time, 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.3 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). After approximately two years (or a time determined by the client), the information from the database will be copied into DVDs or other available storage components.

.

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.4 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 were 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++ were also considered. However, using C/C++ would require a platform to provide the GUI implementation. One possible choice would be Visual Studio .NET which would allow 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 have done research for the most suitable programming language and platform to be used for designing and implementing the end product based on the above deliberations and decided to use SQL for the database and PHP for the GUI. Research included 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 was 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 a particular language.

2.5 Technical Approach Considerations

In order to successfully develop 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 designed the details of the program based on the project plan and present it to the client. Changes were made after the presentation to the client as needed. 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. Approximately one month before the end product is due, the client will test the product and amendments shall be applied if needed. As such, 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.6 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 compared to changing them in the 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 also eliminate bugs in early development phases. 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 expected. Tests shall be run to check if the program can handle different exceptions (e.g. erroneous data input, abnormal operation condition, etc). Client testing will be conducted approximately by the first week of October. It is hoped that a fully working prototype is available by then. 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.

3 Detailed Design

This section describes in detail how the software is designed. The software will consist of two main components: the database and the graphic user interface (GUI). For each component, a detailed description and explanation will be provided and diagrams will be used for better understanding of the implementation of the component if necessary. Please note that this is the initial design of the project, the component’s details are subject to change and additional features and detail may be added along progression.

Here is the overall architecture of the software. The detail structure of each component will be described in the following subsections.

[pic]

Figure 3.0. Overall architecture of the project software

3.1 User Level

Due to security reasons, there will be two levels of users. Level-1 users are the basic users while level-2 users are permitted to inspect the database. Neither user levels are allowed to delete any item in the database. There will be no option as “delete” within the database or GUI. Although nothing can be deleted in the database, if the evidence is physically destroyed, there will be an option allowing that evidence to be listed under a different catalog (e.g. destroyed evidence, end-of-case evidence).

3.1.1 Level-1 users

All users in this level are permitted to view, search and add new items to the database. The following will be the overall structure for level-1 users.

[pic]

Figure 3.1.1. Permitted actions for level-1 users

As the user logs in, the system will search the user’s name or ID in the database and verify if he or she is a level-1 user. The system will then authorize the user and allow him or her to do the permitted actions.

For all actions or features not permitted to this user level, the action tab or menu bar will be disabled so that he or she cannot select them. If a level-1 user is trying to select an action which is restricted to only level-2 users, a warning sign will pop up and disallow that action to continue. All action taken by level-1 users will be recorded in a separated log table which only level-2 users can view.

Here is the detailed description of different features that a level-1 user can do:

Add item

The user can add new evidence to the database by selecting the option “Add evidence” in the GUI. The new page will pop up which allow the user to fill in the information needed for adding new evidence to the database (e.g. description of the evidence, location found, case involved, etc). The GUI will be form-based which will be similar to Figure B-1 and B-2 in Appendix B.

Add to Chain of Custody

In order to preserve the chain of custody, every time the evidence is handled (e.g. moved, checked out or sent to a lab) that action will be recorded and the user will have to add the action done into the database by clicking the button “Add to Chain of Custody”.

By clicking on the “Add to Chain of Custody” button, a separate window will pop up. This window will require the user to enter information about the evidence such as case number. After the evidence has been selected, the associated chain of custody will be shown. The user can then add the new information and click “Add”.

If the evidence is to be checked out by the user, he or she will have to register the information into the chain of custody and sign using the attached signature pad. An electronic copy of the signature will be stored in the database to confirm that this user has checked out this evidence at a certain time.

Search/View item

The user can view a piece of evidence or a group of similar evidence by searching through the database. By clicking “Search/View”, a form will pop up and the user can choose to fill in different information to do the search. For example, the user can search by typing the case number of the evidence. Then, all the evidence in that case will be shown. The user can also search by location of the case occurred, type of incident, type of evidence, etc. With different information provided, a different list of evidence will be provided. Sometimes, more than one piece of evidence may be presented.

After a piece of evidence is listed, the user can view the details of the evidence by clicking on that evidence. A list of description about the evidence will be shown in a separate window and the user can also view the chain of custody of that evidence by clicking on the “chain of custody” button.

Exit

By choosing “Exit”, the user will be logged out and the program will return to the log in page.

3.1.2 Level-2 users

All users in this level are given permission for all level-1 actions. Additional features are available in this user level such as viewing records of what has happened within the database (i.e. what item has been changed, which user had view what item). The following is the overall structure of the level-2 user.

[pic]

Figure 3.1.2. Overall structure of level-2 users

Most features available for the level-2 user are identical to those of level-1. However, some addition features are only available to level-2 users. Detailed descriptions are given as followed:

Supervising Database

Since the level-2 user has higher permission level than level-1 user (level-2 is usually assigned to supervisors or chiefs of department), therefore the system will allow the user to inspect the database and view action taken place within the database. There will be two options available after clicking “Inspecting Database”.

Add/delete user

To add a new user to the system, a form-based interface will be shown and the user will be asked to fill out information such as username, password, user ID (i.e. police officer ID), and assign the level of access to the new user.

Since nothing can be deleted in the database, no user can be deleted. If a police office is no longer serving the department, he or she will be removed from the user list and placed under a different catalog such as “deleted user”. All information of the user will be moved to that catalog and the user will no longer be able to log into the system.

View log history

Everything will be recorded and stored into a log table whenever an action has taken place such as viewing a piece of evidence, searching an evidence, checking out an evidence, etc. The description of the action, evidence involved and the user that conducted the action will be recorded. A level-2 user will be able to view the log history and see all the actions in the database. Although the level-2 user can view the log history, he or she will not be able to edit or delete anything.

View user action

Since the evidence and the chain of custody is a highly sensitive matter in the justice system, it is important for the supervisor of the department to be able to check what a user has done in the database. For example, a particular user has been looking at a specific piece of evidence and that evidence was later discovered to be missing. Then, the supervisor will have an idea of who to question regarding the lost evidence.

3.2 Graphic User Interface (GUI) Design

The following figure shows the structure of the GUI and how it interacts with the database and the users. Once the user logs in, it will interact with the user and the database providing communication between the two according to the user’s level-of-access.

[pic]

Figure 3.2. Overview of the GUI

For this project, the GUI will be written in PHP and SQL is used as the database. The GUI will display a window-like graphic interface for the interaction between users and the system. As the user logs in, the system will open a different interface for different user-levels and allow them to take different actions. Every time a user takes an action, the GUI will communicate with the database and provide a response such as a pop-up browser, warning, etc. Please refer to Figure 4 for an overview of the GUI.

The following are the components included in the GUI:

3.2.1 User login

A dialogue window will ask for the user’s username and password at login. After typing the required information, the GUI will pass the username and password to the database and search through the list of users to verify if the user exists. If user is in the database, the system will then display a different graphic interface according to the user level and allow different user actions. If the user is not in the database, a warning sign will pop-up and ask the user for correct username and password.

3.2.2 Level-1 user

The system will interact with the level-1 user and allow the permitted actions. The database will be updated as required. The user interface will allow user input in terms of textbox, checkbox, drop-down list, combo box, etc. Files can be attached to the database if necessary.

3.2.3 Level-2 user

The system will interact with the level-1 user and allow the associated permitted actions. The database will be updated as required. The user interface will allow user input in terms of textbox, checkbox, drop-down list, combo box, etc. Files can be attached to the database if necessary.

3.2.4 Exit

If “Exit” is selected at the login page, the system will prepare to exit and ask the user to reconfirm. The system will end after the confirmation. If “Exit” is selected after a user has logged in, the system will then log out that user.

3.3 Database Design

Since the software is used for preserving the chain of custody for the evidence, the database should be able to store and handle a large amount of data with a high level of security. The following is the architecture of the database.

[pic]

Figure 3.3. Architecture of the database

3.3.1 Description

For this project, the database will be constructed using SQL. Since SQL is a common database management programming language, it is not only easy to use but also easy to implement. The basic architecture of the database is shown in Figure 5 above.

The database will contain these two main tables:

Password-check table

This table will store all user information such as username and password. Each username is a unique key for this table. Every time a user logs in, the program will search through this table to check if the username exists and what level of access is allowed.

Evidence inventory table

This table will be used to store information about the evidence (description, case number, etc.) Since the case number is not unique, a unique “key number” will be assigned to each entry as the reference key. This key number can then be used to reference to a separated table storing the chain of custody of the particular evidence.

3.3.2 Security

In order to keep the database secure, the user will have to log in before having access to the database. The password-check table will store all the information of the users in the database including user ID (i.e. police officer ID), username for the software, user password and level of access. Electronic signature may be included as an added security feature. The user is required to sign electronically every time he or she checked out evidence. That signature will be stored in the database with the chain of custody. In some circumstances, the electronic signature stored with the user’s information may be compared with the signature in the chain of custody.

4 Resources Requirements

This section shows the original and current estimates for the resources needed to complete the project.

4.1 Personnel Effort Requirements

This section shows the original personnel effort estimation and revised personnel effort after taking into account completed tasks and modified estimations. The tasks referred in the tables below correspond to the tasks listed below:

Task 1: Problem Definition

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

Subtask 1b: Identify Project Constraints and Limitations

Task 2: Technology Considerations and Selection

Subtask 2a: Research existing systems

Subtask 2b: Research Existing Programming and Database Management

Languages

Task 3: End-Product Design

Subtask 3a: Automate Input Entry Procedure for Client

Subtask 3b: Break down project to facilitate implementation

Task 4: Prototype Implementation

Subtask 4a: Work delegation

Subtask 4b: Code Generation and Screenshot Mockups

Subtask 4c: Code documentation

Task 5: End-Product Testing

Subtask 5a: Individual Component Testing

Subtask 5b: Component Integration and Testing

Subtask 5c: Whole System Testing

Task 6: End-Product Documentation

Subtask 6a: Develop User’s Manual

Task 7: End-Product Demonstrations

Subtask 7a: Demonstration Planning

Subtask 7b: Faculty Advisors Presentation

Subtask 7c: Industrial Review Panel Presentation

Task 8: Project Reporting

Subtask 8a: Weekly E-mails of Project Status

Subtask 8b: Project Plan

Subtask 8c: Project Poster

Subtask 8d: Design Report

Subtask 8e: Final Report

These tasks were obtained from the Project Plan

Table 4.1.1 shows the original personnel effort estimation while Table 4.1.2 shows the revised personnel effort after taking into account completed tasks and modified estimations.

Table 4.1.1. Original 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 (147 hours) |  |$1,543.50 |

|Jennifer Sanders (149 hours) |  |$1,564.50 |

|Royson Chong (153 hours) |  |$1,606.50 |

|Yin-Cheung Lo (151 hours) |  |$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 ($75direct cost) |

Table 4.2.2. Modified Financial Requirements

|Item |With Labor |Without Labor |

|Materials: |  |  |

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

|Poster |$45.00 |$45.00 |

|Subtotal |$70.00 |$70.00 |

|Labor at $10.50 per hour: |  |  |

|Andrew Bitterman (148 hours) |  |$1,554.00 |

|Jennifer Sanders (151 hours) |  |$1,585.50 |

|Royson Chong (144 hours) |  |$1,512.00 |

|Yin-Cheung Lo (147 hours) |  |$1,543.50 |

|Subtotal |  |$6,195.00 |

|Additional Hardware (time permitting): |  |  |

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

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

|Subtotal |$260 |$260 |

|Total |$335 ($70 direct cost) |$6,455 ($70 direct cost) |

Changes:

Poster – The budget for the poster was initially overestimated. The actual cost of creating the poster was $45, a reduction of 10% ($5) from the original estimate of $50.

Labor – As less time is expected to complete the project, this factor affects the cost of labor. Therefore, the reduction of 2% ($105) is directly attributed to the modified work time (590 hours at $10.50/hour - $6195) compared to the original estimate (600 hours at $10.50/hour - $6300)

4.3 Schedules

This section shows the Gantt charts for the project. Gantt chart 1 shows the tasks and associated subtasks versus the proposed project calendar. Gantt chart 2 shows the tasks and associated subtasks versus the modified project calendar.

No changes were made to Gantt chart 3 as the project deliverables are determined by the client. Therefore, Gantt chart 2 is similar to the one presented in the Project Plan.

Changes:

Task 3b – An additional 25% (5 days) was needed. This factor was due to the additional time taken in breaking the project into modules suited to the skills of the team members.

Task 4 – An overall reduction of 20% (9 days) will occur. This is anticipated as the result of subtask 3b. As such, developing the module will take less time.

Task 7 – An additional 16% (1 day) is allocated so the team can implement the recommendations suggested by the faculty advisors from subtask 7b (Faculty Advisors Presentation).

Figure 4.3.1. Original Schedule

[pic]

Figure 4.3.2. Modified Schedule

[pic]

Figure 4.3.3. Project Datelines

[pic]

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]

-----------------------

User

Graphic User Interface

(GUI)

Database

Level-1 User

Add item

Search/View item

Add to Chain of Custody

Exit

Level-2 User

Add item

Search/View item

Add to Chain of Custody

Exit

Inspecting Database

View log history

View user action

Add/delete user

Database

Add

Add/delete user

Search/View

Evidence

Chain of custody

Log history

User action

Evidence

Chain of custody

Database

Graphic User Interface (GUI)

Session Control

Level-1 User

Level-2 User

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

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

Google Online Preview   Download