Police Database Design - DOC

Document Sample
Police Database Design - DOC Powered By Docstoc
					                      Evidence Inventory
                       Tracking System
                        Design Report
                                          Dec05-06


                                            Client:
                                 Boone Police Department

                                       Faculty Advisor:
                                    Dr. Thomas Daniels


                                      Team Members:
                                         Eric Hand
                                       Daniel Pruckler
                                      Thomas Brezinski
                                    Vignesh Vijayakumar


                                        April 27, 2005


                                         Disclaimer:
This document was developed as a part of the requirements of a computer engineering course at
Iowa State University, Ames, Iowa.        This document does not constitute a professional
engineering design document.      Although the information is intended to be accurate, the
associated students, faculty, and Iowa State University make no claims, promises, or guarantees
about the accuracy, completeness, quality, or adequacy of the information. The user of this
document shall ensure that any such use does not violate any laws with regard to professional
licensing and certification requirements. This use includes any work resulting from this student-
prepared document that is required to be under the responsible charge of a licensed engineer.
This document is copyrighted by the students who produced this document and the associated
faculty advisors. No part may be reproduced without the written permission of the senior design
course coordinator.    Some parts may also be copyrighted by the City of Boone Police
Department.
Table of Contents
1.  Introductory Material ........................................................................ 1
  1.1. Executive Summary ...........................................................................1
  1.2. Acknowledgement .............................................................................1
  1.3. Problem Statement and Solution .........................................................1
  1.4. Operating Environment ......................................................................2
  1.5. Intended User(s) and Intended Use(s) ................................................2
  1.6. Assumptions and Limitations ..............................................................3
  1.7. Expected End Product and Other Deliverables .....................................3
2. Approach Used ................................................................................... 4
  2.1. Design Objectives ..............................................................................4
  2.2. Functional Requirements ....................................................................4
  2.3. Constraints Considerations .................................................................5
  2.4. Technical Approach Considerations .....................................................6
  2.5. Testing Requirements Considerations ..................................................6
  2.6. Project Continuation ..........................................................................7
3. Detailed Design ................................................................................. 8
  3.1. User Interface Design ........................................................................8
  3.2. Database Design ............................................................................. 26
4.  Resource Requirements ..................................................................27
  4.1. Personal Effort Requirements ........................................................... 27
  4.2. Financial Requirements .................................................................... 29
  4.3. Schedules ....................................................................................... 30
5. Closing Materials .............................................................................35
  5.1. Project Team Information ................................................................ 35
  5.2. Closing Summary ............................................................................. 36
  5.3. References ...................................................................................... 36




                                                                                                          i
List of Figures
Figure   3.1.1.   System Flow Diagram ..................................................................8
Figure   3.1.2.   Login Page ..................................................................................9
Figure   3.1.3.   Home Page ............................................................................... 10
Figure   3.1.4.   Search Database ....................................................................... 11
Figure   3.1.5.   Quick Item Custody Transfer...................................................... 12
Figure   3.1.6.   Add New Case ........................................................................... 13
Figure   3.1.7.   Edit Current Case ...................................................................... 14
Figure   3.1.8.   Add New Evidence / Property ..................................................... 15
Figure   3.1.9.   Edit Evidence / Property ............................................................ 16
Figure   3.1.10.   Add File To Case ..................................................................... 17
Figure   3.1.11.   Reports System ....................................................................... 18
Figure   3.1.12.   Chain of Custody Report .......................................................... 19
Figure   3.1.13.   Inventory Report ..................................................................... 20
Figure   3.1.14.   Administration ......................................................................... 21
Figure   3.1.15.   Add Officer.............................................................................. 22
Figure   3.1.16.   Edit Officer.............................................................................. 23
Figure   3.1.17.   Backup Database ..................................................................... 24
Figure   3.1.18.   Restore Database .................................................................... 25
Figure 3.2.1. Database Design ....................................................................... 26
Figure 5.1. Original Project Schedule .............................................................. 32
Figure 5.3. Deliverables Schedule................................................................... 34




                                                                                                              ii
List of Tables
Table   4.1.1. Original Estimated Personal Effort Hours ...................................... 28
Table   4.1.2. Revised Estimated Personal Effort Hours ...................................... 28
Table   4.2.1 Original Financial Budget ............................................................. 29
Table   4.2.2 Revised Financial Budget ............................................................. 30




                                                                                                      iii
List of Definitions

       Term                                   Description
                   A list of where the select piece of evidence has gone and when,
Chain of custody
                   and who checked it out.
                   The documentary or oral statements and the material objects
Evidence
                   admissible as testimony in a court of law.
                   Megabyte: A unit of computer memory or data storage capacity
MB
                   equal to 1,048,576 (220) bytes.
                   An object-oriented programming language developed by Sun
Java               Microsystems. Java supports programming for the Internet in the
                   form of platform-independent Java applets.
MySQL              An open source database.
                   Open source, server side, embedded scripting language used to
PHP
                   create dynamic Web pages.
                   Graphical User Interface, A user interface based on graphics
GUI                instead of text; uses a mouse as well as a keyboard as an input
                   device.
                   Structured Query Language, a query language used in performing
SQL
                   operations on databases.
                   HyperText Transfer Protocol, a medium for accessing web pages
HTTP
                   through a browser.
GPL                General public license.




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

1.1. Executive Summary
      Evidence can be the key in convicting someone of a crime, or of acquitting
      a person of charges brought against them. It is important that evidence is
      handled carefully and documented accordingly. This cataloging system will
      include additions, searching, reporting, and printing.


      The police department will be able to search for evidence by many
      different constraints. This would be a very helpful tool for a diversity of
      applications, either for evidence or for writing a research document. This
      would help out the police department very much as it will help organize
      their data and reduce the clutter that paperwork causes.

1.2. Acknowledgement
      The team would like to acknowledge the Boone Police Department for
      committing significant time to revise the project specifications to their
      current needs.

1.3. Problem Statement and Solution
      The problem statement was provided by the client to the senior design
      team. The solution was created by the senior design team and approved
      by the client.


1.3.1. Problem Statement
      Evidence is crucial to court cases. It can contribute to the decision of
      whether a criminal goes to jail or goes free. Keeping track of the evidence
      can be a task though. Currently the chain of custody is stored on either
      the bag the evidence is stored in or a tag on the evidence. This system
      can create many problems. Should the tag on the evidence be lost it
      must be recreated from the memory of the officers. Also should an officer
      want to review the chain of custody or see where a piece of evidence is



                                                                               1
      currently located they must locate the information on the physical
      evidence.


1.3.2. Solution Approach
       The team will create a computer system which will replicate the
       information normally only stored on the evidence. Authorized officers will
       be able to view and update this information from any computer within the
       Boone Police Department.

1.4. Operating Environment
      The system will be restricted to the offices of the Boone Police
      Department. Restricting access to office computers only will be the
      responsibility of the computer consultant contracted by the Boone Police
      Department. Officers will be able to access the system from any
      computer system capable of running a modern web browser. A server will
      host the information for the client computers. The team recommends that
      with current software, a server system meeting at least the minimum
      specifications below should be utilized.


      Recommended Server Specifications:
           Pentium Class 1.0 GHz Processor
           256 Megabytes of RAM
           40 Gigabytes of hard drive space

1.5. Intended User(s) and Intended Use(s)
      The system will be used exclusively by the Boone Police Department for
      evidence inventory and tracking purposes.


1.5.1. Intended User(s)
       The intended users for this application are strictly the officers of the
       Boone Police Department. Even then only specific groups of people will
       have specific capabilities as specified by different access levels. No one
       outside the department would be allowed to have access to the system.
      The system will be user-friendly and have a minimal learning curve.




                                                                               2
1.5.2. Intended Use(s)
       This application will be used in the compiling, tracking and storage of
       evidence. It will create an object for each collected piece of evidence and
       store it in a database. It will allow for the search of the database using
       different search terms related to the evidence. Editing, updating, and
       fixing entries will be available options, although restricted to certain levels
       of users.

1.6. Assumptions and Limitations
       Taking into account the uses and users of the system the following
       assumptions and limitation of the system are listed below.


1.6.1. Assumptions
        The user has basic knowledge of the Microsoft Windows computing
          environment.
        The user has sufficient storage space to create a backup
          corresponding to the size of the database.
        The user has hardware appropriate to run the system.
        The user understands the English language fluently.
          The user understands the current manual process used for evidence
           tracking.


1.6.2. Limitations
        The system must be completed by December 2005.
        The maximum response time per query must be less than ten seconds.
        Server must have at least a 1.0 GHz Processor, 256 Megabytes of RAM
          and 40 gigabytes of storage space for application and data.

1.7. Expected End Product and Other Deliverables
       In this first semester the team has completed a number of deliverables.
       The project plan and design documents have been completed. Also
       several revisions of the prototype system screenshots have been delivered
       and reviewed by the client.

       In the second semester the team will be delivering and assisting in
       instillation of the final product. The final product will meet the client’s


                                                                                    3
       specifications which have been approved through the use of several
       detailed prototype screenshots. Also a detailed user manual will be
       delivered to the client for later reference.


       A final report will also be created detailing the final specifications and
       functionality of the system.      It will also review all the problems
       encountered in the implementation and their solutions. Also included will
       be an explanation of the system documentation that may be utilized to
       later expand the system.


2. Approach Used
   This section details the development approach and design of the end-
   product.

2.1. Design Objectives
   The end product shall be designed to provide:
    User Interface
      The system will have an easy to use graphical interface accessible
      through a modern web browser.

       Security
        The system will provide user authentication to restrict the system and
        specific functions to authorized users.

       Chain of Custody
        The system will be able to provide a printable chain of custody report
        for any piece of evidence in the system.

       Inventory Reports
        The system will be able to create custom inventory reports showing
        what is currently in the evidence lockup.

       Ease of Use
        Simplicity of the system is a major concern of the client. The system
        must be easy to use with little to no learning curve.


2.2. Functional Requirements
   The end product shall meet the following requirements:


                                                                                 4
      Database With 4-level Access Restriction
       A database will be created to store the system information. There will
       be four different access levels to the system. An “Administrator” will
       have full access to the system and all it’s functions. A “Standard” user
       will have access to all data entry and report screens but will not have
       access to the administration panel. A “Backup” user will only be able to
       access the database backup screen to create and download a
       compressed backup of the database. A “No-Access” user will be unable
       to login to the system but will be listed in dropdown menus of data entry
       screens. This is because while all officers will be collecting evidence
       only a select few will have access to add that evidence to the system.
      Ability to Attach Files to a Case
       The system will allow files to be attached to a case and be stored in the
       database. The database will support any file type.
      Searching the Database
       The user will be able to search the database for records based on
       multiple different fields.
      Limited Deletion
       For security reasons only files attached to cases may be removed. This
       is to facilitate file updates. Also the database size could be reduced by
       removing older unneeded attached files. All other information such as
       cases and evidence can not be removed.
      Easy Backup
       The system will provide a simple interface for making regular backups of
       the database.

2.3. Constraints Considerations
   The constraints on the end-product are:

      Database Size

       Database size shall only be constrained by the amount of physical
       storage space available on the server. An initial database with no
       evidence entries will require less than one megabyte of storage space.
      Computer Resource Usage
       Client computer will require only the resources required to run a modern
       web browser. Server computer will require adequate resources to run


                                                                                5
     the required database and web server software.
    Technical Support

     Since no technical support will be available to the client after the
     projects is complete, adequate documentation and support resources
     will be made available to the client.
    Budget Limitation

      The client will be expected to provide all computer hardware required to
      run the system.


2.4. Technical Approach Considerations
   The team considered using existing database solutions that can be bought
   commercially as well as creating the team’s own database system from
   scratch. An existing system would only require tweaking to the team’s
   specific application and building from scratch would take considerable
   research and programming hours. As such the team decided to use MySQL
   as the database system and PHP for the front-end solution as both are
   open-source and are easily modifiable. In addition both technologies have
   significant user bases around the globe which shows the maturities of the
   technologies. The web server will Apache as it is also open source and
   provides excellent integration of PHP and MySQL. The operating system
   will be Red Hat Linux. Linux usually provides a more stable system than
   Microsoft Windows and is a proven platform to integrate Apache, PHP, and
   MySQL on. While the Boone Police Department does not currently use
   Linux, their contracted computer consultant has agreed to support the
   platform.

2.5. Testing Requirements Considerations
   A detailed test plan shall be created when initial programming is near
   completion. This testing will include a through testing of all aspects of the
   system focusing on user input validation. Since the system is relatively
   simple and the programming team is significantly proficient in the language
   at project start, the team does not feel it necessary to test parts of the
   system before initial programming completion.




                                                                              6
   The system will be deployed for further testing by the Boone Police
   Department. During this testing phase the Boone Police Department will
   begin entering currently held evidence into the system. Newly collected
   evidence shall be entered into the system on a limited basis. Once stability
   and functionally of the system is fully confirmed it will immediately be
   available to the client for full use.

2.6. Project Continuation
   The team will be continuing the project as currently envisioned. Both the
   team and client are satisfied with the current design and as such the project
   will continue as currently scheduled.




                                                                              7
3. Detailed Design
     This section describes in detail how the software is designed. The software
     will consist of two main components: the graphic user interface (GUI) and
     database. 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.

3.1. User Interface Design
     After several revisions these screenshots of the user interface have been
     approved by the Boone Police Department for use in the final design.
     However additional features or enhancements may be added later as
     desired by the client or required by the design.


3.1.1. System Overview
       This figure provides an overview of the system layout and flow.

                                               Login




              Quick
  Search                            Reports                     Add Case               Adminisration
             Transfer



                                                                                 Add/Edit         System
                        Inventory                                                 User            Settings



                        Chain of
                        Custody
                                                        Edit Case




                                Add Evidence           Edit Evidence       Add File




                        Figure 3.1.1. System Flow Diagram




                                                                                                             8
3.1.2. Login Page
       This will be the first screen seen by all officers. Officers may login to the
       system using their three digit ID number and password.




                             Figure 3.1.2. Login Page




                                                                                  9
3.1.3. Home Page
       This is a prototype of the main homepage for the system. From here the
       officer can choose what task they would like to do. The administration
       selection will be hidden from officers who do not have access to that
       section.




                          Figure 3.1.3. Home Page




                                                                          10
3.1.4. Search Database
       From this form the officer can search the case and evidence inventory by
       many different criteria. When search by “Date of Recovery” is selected
       the criteria section will change to the second one shown. When
       “Recovered By” is selected the criteria will change to a dropdown box as
       shown in the third one.




                        Figure 3.1.4. Search Database




                                                                            11
3.1.5. Quick Item Custody Transfer
       This page will be most useful if the officer has the physical evidence tag
       with them. If the case number and item number are known, a custody
       transfer can be quickly recorded with this screen. The date and time will
       be automatically populated with the current date and time.




                   Figure 3.1.5. Quick Item Custody Transfer




                                                                              12
3.1.6. Add New Case
       From here the officer can add a new case to the system. The agency field
       will default to “Boone Police Department” but will be editable. After this
       screen the edit case screen will be displayed so that evidence and files
       can be added to the case.




                          Figure 3.1.6. Add New Case




                                                                              13
3.1.7. Edit Current Case
       This page is the main interface for a case. All items will be populated with
       the information currently in the database. It allows changes to all the
       items specified when the case was added. It also provides a listing of
       evidence and files attached to the case. The evidence list will display the
       date the item was recovered and the file list will display the date the file
       was posted. The description fields will be truncated to fit on one line in
       the space allowed. By clicking on a piece of evidence the user can bring
       up the screen to edit the evidence entry.




                         Figure 3.1.7. Edit Current Case


                                                                                14
3.1.8. Add New Evidence / Property
       From this screen the officer can add a new piece of evidence to a case.
       The “Item No” will automatically populate with the next available item
       number. The date and time will auto populate with the current date and
       time. The dropdown box for “Recovered By” is populated with a list of
       officers provided in the administration site. Evidence types may be edited
       in the administration site.




                   Figure 3.1.8. Add New Evidence / Property




                                                                              15
3.1.9. Edit Evidence / Property
       After evidence has been entered the officer can edit it via this screen.
       Unlike the add evidence screen this one will allow the addition of a chain
       of custody entry and disposition. Date and time fields on the change
       custody and disposition will automatically populate with the current date
       and time. To see reasons for transfers the officer will need to create a
       chain of custody report by clicking the “Create Report” button.




                     Figure 3.1.9. Edit Evidence / Property



                                                                              16
3.1.10. Add File to Case
        Using this screen the officer can add a file to a case. Simply click the
        browse button and select your file, enter a description, and click submit.




                         Figure 3.1.10. Add File To Case




                                                                               17
3.1.11. Reports System
        Using this screen an officer can generate a chain of custody or inventory
        report. For the chain of custody report both fields are required. For the
        inventory report the officer may enter any combination of the criteria
        options, however at least one will be required.




                         Figure 3.1.11. Reports System




                                                                              18
3.1.12. Chain of Custody Report
        This is the printable chain of custody report which can be generated for
        an item. It contains all the information located on the “Evidence /
        Property tag.” The disposition will be displayed if it exists.




                    Figure 3.1.12. Chain of Custody Report




                                                                             19
3.1.13. Inventory Report
        This screen will give a printable inventory report based on the criteria
        specified. The report may be resorted by clicking on any of the headers
        in the table.




                        Figure 3.1.13. Inventory Report




                                                                             20
3.1.14. Administration
        This is the system administration menu that will be available to
        administrators. From here the officer will be able to add or edit officers
        in the system and change system settings. Also the database can be
        backed up or restored.




                          Figure 3.1.14. Administration




                                                                               21
3.1.15. Add Officer
        From this screen an officer may be added to the system. The ID No.
        field will be the department assigned three digit ID number. There will
        be four access levels which are:

       Administrator – Full access officer who has access to all administration
        options and system content.
       Standard – Access to all system content and no access to any
        administration options.
       Backup Only – Officer will be sent directly to the backup database
        screen and will only have access to that screen. This way a secretary or
        other designated person can handle backups on a regular basis.
       No Access – Officer will not be able to login to the system. However
        they will be listed in all officer list dropdowns such as the ones on the
        case and evidence screens. For this access level a password does not
        need to be specified.




                           Figure 3.1.15. Add Officer



                                                                              22
3.1.16. Edit Officer
        From this screen an officer in the system may be edited. All fields will
        have the same specifications as the Add Officer screen. Officers may
        not be deleted from the system but may be changed to “No Access”.
        Since officers will have records associated with them, deleting an officer
        would cause problems.




                            Figure 3.1.16. Edit Officer




                                                                               23
3.1.17. Backup Database
        From this screen an officer may create a backup of the database which
        will then be downloaded to the officer’s computer for later storage on an
        external media such as a CD-Recordable disc.




                        Figure 3.1.17. Backup Database




                                                                              24
3.1.18. Restore Database
        From this screen an officer administrator may restore the database from
        a backup file. This process will clear all data currently stored in the
        database. This function is provided so that if the system must be moved
        to a different server the data can easily be restored to the new server.




                        Figure 3.1.18. Restore Database




                                                                             25
3.2. Database Design
   The main entity of the database will be the “Case”. It will rely on the
   “Items” table, which will store all the evidence/property information, and
   the “CaseFiles” which will store the files attached to the case. The items
   table will rely on four other tables. The “Users” table will store the
   information about all the officers registered in the system.               The
   “ChainOfCustody” table will store all the changes of custody for the
   evidence/property. The “EvidenceType” table will store the types that can
   be applied to the evidence/property such as alcohol or weapon. Last is the
   “Disposition” table which will store the disposition record after the evidence
   has been removed from inventory.

             Users                                           ChainOfCustody
      PK,FK1     _id                                         PK,FK1   _id

                 username                                             itemid
                 officerid                                            date
                 password                                             from
                 firstname                                            to
                 lastname                                             reason
                 active
                 admin
                 write
                 read                      Items              EvidenceType
                                  PK,FK1    _id              PK,FK1   _id

           Case                             caseid                    name
                                            itemnum                   active
      PK   _id                              description
                                            date
           casenum                          evidtype
           agency                           officerid          Disposition
           offense                          location         PK,FK1   _id
           suspect                          stored
           victum                           picture                   itemid
           comments                         comments                  result
                                                                      date
                                      CaseFiles

                                  PK,FK1    _id

                                            caseid
                                            name
                                            data
                                            comments

                             Figure 3.2.1. Database Design



                                                                               26
4. Resource Requirements
     This section shows the original and current estimates for the resources
     needed to complete the project.

4.1. Personal 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 Users and End Uses
   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


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 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
   Subtask 6b: Develop Instillation / Maintenance Manual




                                                                             27
Task 7: End-Product Demonstration
   Subtask 7a: Demonstration Planning
   Subtask 7b: Faculty Advisor 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, more detailed information on
these tasks may be found in 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 based on change of project scope.

Table 4.1.1. Original Estimated Personal Effort Hours

Names     Task 1    Task 2   Task 3    Task 4   Task 5      Task 6   Task 7   Task 8   Totals
Thomas          6        7       25        55       30          10        8      21       162
Eric            4        5       25        50       30          10        7      23       154
Vignesh         3        4       19        65       32          13        3      15       154
Daniel          2        4       21        60       33          12        4      14       150
Totals        15        20       90      230       125          45      22       73       620


Table 4.1.2. Revised Estimated Personal Effort Hours

Names     Task 1    Task 2   Task 3    Task 4   Task 5      Task 6   Task 7   Task 8   Totals
Thomas          6        7       15        15       10          10        8      30       101
Eric            4        5       11         5       30          10        9      25          99
Vignesh         3        4       10        50           5       13        3        7         95
Daniel          2        4         8       40           5       19        4        8         90
Totals        15        20       44      110        50          52      24       70       385




                                                                                        28
Changes:
Task 3 – 46 hours were removed to match actual time spent and account for
changes in the project scope.


Task 4 – 120 hours were removed to account for the simpler system design
desired by the client. Also since the bulk of the programming will be completed
by Vignesh and Daniel, the hours for Thomas and Eric have been reduced.


Tasks 5, 6, and 7 – 66 hours were removed to account for the reduced project
scope.


Task 8 – 3 hours were removed and work was redistributed to mainly Thomas
and Eric since Vignesh and Daniel will be completing the bulk of the system
programming.

4.2. Financial Requirements
       Table 4.2.1 shows the original financial budget estimation while Table 4.2.2
       shows the revised financial budget after taking into account completed
       tasks and modified estimations based on change of project scope.

Table 4.2.1 Original Financial Budget
Item                                       Without Labor            With Labor
Materials:
Signature Pad                              (purchased previously)   (purchased previously)
Barcode Scanner                            $200.00                  $200.00
Poster                                     $50.00                   $50.00
                                Subtotal   $250.00                  $250.00

Labor at $10.50 per hour:

Thomas Brezinski                                                    $1,701.00

Eric Hand                                                           $1,617.00

Vignesh Vijayakumar                                                 $1,617.00

Daniel Pruckler                                                     $1,575.00

                                Subtotal                            $6,510.00

                                   Total   $250                     $6,760.00




                                                                                        29
Table 4.2.2 Revised Financial Budget
Item                                       Without Labor         With Labor
Materials:
Poster Board                               $9.00                 $9.00
Misc Printing Costs                        $40.00                $40.00
                                Subtotal   $49.00                $49.00

Labor at $10.50 per hour:

Thomas Brezinski                                                 $1,060.50

Eric Hand                                                        $1,039.50

Vignesh Vijayakumar                                              $997.50

Daniel Pruckler                                                  $945.00

                                Subtotal                         $4,042.50

                                   Total   $49.00                $4,091.50


Changes:
Materials – signature pad and barcode scanner were removed since they will no
longer be components of the implementation. Poster cost was replaced with the
cost of the poster mounting board since the department printed the poster.
Miscellaneous printing costs were added to account for printing of deliverables
and other documents.


Labor – The total cost of labor was reduced 38% due to the changes in labor
requirements due to the change in scope.


4.3. Schedules
       The following schedules have been coordinated with the client to produce a
       successful project within the allocated time table.


4.3.1. Project Schedule
       The client would like to have the system       deployed in the early fall. Also
       the programming team has decided to            push back code completion to
       midsummer so they may concentrate on           finals. The team will complete
       their part of the testing by early fall when   the system will be deployed and


                                                                                   30
final testing will be done by the Boone Police Department.


The deliverables schedule has not changed.




                                                             31
Figure 5.1. Original Project Schedule




                                        32
Figure 5.2. Revised Project Schedule




                                       33
Figure 5.3. Course Deliverables Schedule



                                           34
5. Closing Materials
     Concluding this document is the project team information, closing summary,
     and reference materials.

5.1. Project Team Information
     The following is a list of people involved in the project along with their
     contact information.
Student Team Members:                   Advisor:

Eric Hand (CprE)                        Dr. Tom Daniels
200 Stanton Apt 205                     3222 Coover Hall
Ames, IA 50014                          Ames, IA 50011
(515) 291-1214                          (515) 294-8375
snokyguy@iastate.edu                    daniels@iastate.edu


Thomas Brezinski (CprE)
6115 Frederiksen Ct                     Client:
Ames, IA 50010
(515) 441-1941                          Boone Police Department
tbrezins@iastate.edu                    Chief William Skare
                                        (515) 432-3456
Vignesh Vijayakumar (CprE)              (515) 432-1564 fax
907 B North Dakota Ave
Ames, IA 50014
(515) 708-1238
vic@iastate.edu


Daniel Pruckler (CprE)
609 Meadow Place
Ames, IA 50011
(515) 290-4148
danien@iastate.edu




                                                                            35
5.2. Closing Summary
   This system will provide the Boone Police Department with a better way of
   tracking evidence. Currently the evidence process is very inefficient. By
   using this system the Boone Police Department will be able to streamline
   their evidence inventory management process which will allow them more
   time to protect and serve the City of Boone.

5.3. References
   The following are the websites for the software being used for the system:
   Apache – www.apache.org
   MySQL – www.mysql.com
   RedHat Linux – www.redhat.com
   PHP – www.php.net




                                                                            36

				
DOCUMENT INFO
Description: Police Database Design document sample