Evidence Inventory and Tracking Program Project Plan



Evidence Inventory and Tracking Application

Project Plan

Dec05-06

Client:

William Skare

Boone Police Department

Advisor:

Thomas Daniels

Team Members:

Eric Hand

Daniel Pruckler

Thomas Brezinski

Vignesh Vijayakumar

March 1, 2005

Table of Contents

1. Introductory Materials iii

1.1 List of Figures iii

1.2 List of Tables iv

1.3 List of Definitions 1

1.4 Abstract 1

1.5 Acknowledgement 2

1.6 Problem Statement 2

1.7 Solution Approach 2

1.8 Operating Environment 2

1.9 Intended Users 3

1.10 Intended Uses 3

1.11 Assumptions of the user 3

1.12 Limitations of the system 3

1.13 Expected End Product and Other Deliverables 3

2. Proposed Approach 5

2.1 Functional Requirements 5

2.2 Constraints Considerations 6

2.3 Technology Considerations 7

2.4 Technical Approach Considerations 7

2.5 Testing Requirements Considerations 8

2.6 Security Considerations 8

2.7 Safety Considerations 8

2.8 Intellectual Property Considerations 8

2.9 Commercialization Considerations 9

2.10 Possible Risks and Risk Management 9

2.11 Project Proposed Milestones and Evaluation Criteria 10

2.12 Project Tracking Procedures 11

3. Statement of Work 12

4. Estimated Resource Requirement 20

4.1 Personal Effort Requirements 20

4.2 Financial Requirements 20

5. Schedules 21

5.1 Project Schedule 22

6. Student Team Information 24

7. Closing Summary 25

References 25

Addendum 26

Appendix A 27

Appendix B 28

Appendix C 30

1. Introductory Materials

1.1 List of Figures

Figure 5-1. Project Schedule 22

Figure 5-2. Deliverables Schedule 23

Figure A-1. Property/Evidence Form 27

Figure B-1. City Incident Report - Front 28

Figure B-2. City Incident Report - Back 29

Figure C-1. Application Environment Topography 30

1.2 List of Tables

Table 4-1. Estimated Personal Effort Hours 20

Table 4-2. Financial Budget 20

1.3 List of Definitions

|Term |Description |

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

|MB |Megabyte: A unit of computer memory or data storage capacity equal to 1,048,576 (220) bytes. |

|Java |An object-oriented programming language developed by Sun Microsystems. Java supports programming for the|

| |Internet in the form of platform-independent Java applets. |

|MySQL |An open source database. |

|PHP |Open source, server side, embedded scripting language used to create dynamic Web pages. |

|GUI |Graphical User Interface, A user interface based on graphics instead of text; uses a mouse as well as a |

| |keyboard as an input device. |

|SQL |Structured Query Language, a query language used in performing operations on databases. |

|HTTP |HyperText Transfer Protocol, a medium for accessing web pages through a browser. |

|GPL |General public license. |

1.4 Abstract

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.5 Acknowledgement

According to the previous team’s logbooks, former Chief Dan Losada of the Boone Police Department provided initial consultation and input into what he believed was required and what the exact specifications should be to the previous design group. He also provided forms for Incident Reports and for property/evidence. This is currently what is available until the Boone Police Department is able to find the time to discuss the project with the current design group and clarify doubts or questions and add any additions or modifications to project specifications.

1.6 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, however, can be a task, and if the complete chain of custody is not present, the evidence ceases to be admissible in court. The chain of custody is critical in the case of evidence. If a person checks out the evidence in question and never returns, there will be a trail to follow in the system. Another problem is the organization of the evidence. This will be done with a barcoding system. Along with the barcode, other information can be put into the system such as the whereabouts of the evidence(lab, court, evidence room, etc.). All of these factors must be taken into consideration when designing the application / system.

1.7 Solution Approach

To solve these problems a restrictive database application will be created. This database will primarily allow users of the application to only add entries, and allow entries to be appended when approved by the 3rd level user (a supervisor). The application will also have its own search engine to query for evidence and chain of custody. This will help with the problem of things being misplaced by querying the database for information. This application will also have network capabilities, so that a client in another room can be looking up evidence at the same time as other evidence may be handled from another client.

1.8 Operating Environment

Since this is a application run on a network of computers which will be required to remain inside, the environment will remain static for the most part. The air temperature will range from 60-80 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. A secure network is, but security precautions will be built-in incase of security issues.

1.9 Intended Users

The intended users for this application are strictly the employees of the Boone Police Department. Even still, only specific groups of people will have specific capabilities as different levels of users. No one outside the department would be allowed to have access to it. The system is tailored to that of adults operating it, and uses language and organization for the appropriate user, but does not assume any technical competence and will be completely user-friendly.

1.10 Intended Uses

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 also be available options, although restricted to certain levels of users.

1.11 Assumptions of the user

□ The user has basic knowledge of the Microsoft Windows computing environment.

□ The user has sufficient storage space for backup.

□ The user understands the English language fluently.

□ The user understands the current manual process used for evidence tracking.

1.12 Limitations of the system

□ 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 128mb of RAM and 1gb of storage space for application.

1.13 Expected End Product and Other Deliverables

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 and 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 application.

The final product will be the actual system based off the prototype with all of the changes and corrections applied. It will allow for users to enter new evidence into the database, search the database for a particular item (via different specified fields), and even print off tags to go with the actual piece of evidence. The final application may offer some sort of compatibility with a signature pad or other identification verification piece of hardware. Use of a barcode system is intended.

A final report will also be delivered to the client. This document will contain a manual and documentation for the end product, and describe the functions of the application. It will state all of the problems encountered and the solutions for each, a summary of the entire project, and identification of any future work that may be done on the application. It will also contain suggestions for backup timetables and server maintenance with licensed personnel.

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 A database with 3-level access restriction

. In order to ensure the confidentiality and integrity of the database, access to the system is limited. The first level of access allows all users to search and view the database entries. The second level of access allows authorized users to add and append entries to the system. Appending rights would have to be authorized by a third level user. The third level of access allows for second level rights to the database with the ability to authorize appending to it. These levels would be assigned by the Police Chief to tailor the needs of the department.

.

2 Ability to add evidence and attach files

. A second level and higher user can add new evidence with a description and details. The user can also attach useful and relevant electronic files (e.g. pictures, documents) to the evidence.

.

3 Ability to search through database querying specific field

. A first level and higher user can search through the database by case number, item number, description, serial, brand, model, value, location, initiating officer, suspect, disposition, and status. A list of corresponding evidence will be found sorted by a specific field.

.

4 Inability to delete anything from the database

. For protection of the evidence, 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 will still be kept in the database. It will only have its status changed according to its current status. The possibility of a separate storage database for closed cases will be considered.

.

5 An automatic log of all database access

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

.

6 A useful easy-to-use graphical user interface

. A visual interface will be created for interaction between the system and user. The interface will be in a form-base format for user convenience and viewable through any standard Web Browser.

.

2.2 Constraints Considerations

The end product’s constraints are:

1 Database Size

. The database size will be dynamic and based upon the amount of records entered into the system.

.

2 Disk Space

. The amount of disk space required on the server is directly proportional to the number of records the client wishes to track. Client machines will require less than 100 MB of browser caching space and drivers or plug-ins.

.

3 Computer Resources Usage

. Since this is a server-client implementation, the clients function as “thin-clients”, since the server offloads most of the load on itself.

.

4 Technical Support

. Since the application will be coded from open-source software, maintainability will be very easy. Adequate documentation will be provided that will allow for the next developer that works on the system to be able to troubleshoot and/or expand on the current setup.

.

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 application. Since the application uses a large database, databases based on SQL will be considered as they provide a fast implementation. Since virtually all programming languages have connectivity suites that allow for connecting to SQL servers, the team chose SQL. The team went with MySQL in particular because it is free for the environment the team will be using it in due to its open-source nature, and because of it’s capability in handling large loads.

Other languages such as C/C++ will not be considered because of their limited capabilities when programming a network based application, and because of their limited support for MySQL. Moreover, C/C++ are not easy to troubleshoot.

After careful research and consideration, the team has decided upon PHP as the implementation language for its ease of programming and troubleshooting, and for it’s versatility in connection to and performing operations on MySQL databases.

2.4 Technical Approach Considerations

In order to be successful while developing the project, many software development techniques shall be applied. First of all, the team will develop a detailed project plan with most of the requirements and considerations detailed. The team will design the details of the application based on the project plan and present it to the client. Changes shall be made after the presentation and more requirements may be added to the plan as required. 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 demonstrate all of the required and necessary functionality to the client.

While working on the prototype in the first semester, some implementation may be developed as well. In the second semester, the team will fully implement the rest of the system and get a draft of the end product finished by the middle of the second semester. If time and resources permit, the team will implement extra features to expand on the system. By the end of the second semester, an end product shall be delivered and a final presentation will be given to the client demonstrating the end-product functionality.

2.5 Testing Requirements Considerations

All functional and design requirements will be reviewed before implementation begins so as 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 application will be tested by the team at periodic intervals during implementation in order to remove bugs in the early development stages. This also minimizes the time/cost factor.

The end-product will be extensively tested by the team before release to ensure that all features are functional and all requirements are met. The client, aided by the team, will also run tests to make sure that it is user-friendly, and that it functions as they would like. Tests shall be run to check if the application can handle different exceptions (e.g. erroneous data input, abnormal operation condition, etc). The final product will be tested rigorously on the client’s computer to ensure stability, performance, and reliability. The client’s testing will be supported with input from the Boone Police Department when the near-final product is available for test implementation.

2.6 Security Considerations

Since the application will be primarily developed for recording the chain of custody for producing the evidence in court, security and integrity are of paramount importance. Security features shall be added early in development so that as we work more and more on the system, it will only become more secure. Security features shall include a 3-level access restriction as described in the functional requirements, a username/password restriction to access the system itself, and all access to the database shall be over a secure HTTP connection.

2.7 Safety Considerations

As this is a software implementation, there are no physical safety concerns.

2.8 Intellectual Property Considerations

The end product will be developed primarily for the Boone Police Department. However, the team will consider applying a GPL on the product. GPL allows the product to be free for the public and anything deemed specific to the Boone Police Department would be completely removed from all aspects of the system. This will require the approval of the Boone Police Department.

2.9 Commercialization Considerations

Being that the system is being created for a government entity and that this work officially belongs to Iowa State University, no commercialization considerations have been made.

2.10 Possible Risks and Risk Management

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

1 Loss of team member

With any project, there is the possibility of losing a team member. To deal with this risk, each team member is required to keep accurate and detailed information on their parts so the other team members can fully understand what is going on and can pick up where the lost member left off. Weekly meetings will also keep other members up to date on progress with logbooks being maintained as well as up-to-date documentation being stored at a central, secure location.

2 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 would increase because previous effort will have been wasted. A possible solution to avoid such risk is to have multiple backups in different locations, both an electronic copy and a hard copy. Backups shall be made periodically, 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 the academic advisor and the team members.

3 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 Criteria

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

1 Project Outline

. Requirements, specifications, assumptions and the general project plan will be outlined in the project to be used as reference throughout the lifecycle of the application.

.

2 Design

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

3 Implementation

. Reviews shall be made regularly throughout coding to make sure the implementation fits the functional requirements and design requirements. These reviews need to happen frequently to make sure the application is going in the right direction and is not off course. If not done correctly, then the client may not be satisfied and may not find the end-product useful.

.

4 Testing

. The application shall be fully tested with different testing methods. Tests shall be run to ensure stability, performance, reliability, quality, functionality, security, etc. If this part doesn’t occur, then the code may be bug-ridden and have unanticipated problems. This could forfeit the stability of the system and cause it to not function properly.

.

5 End-product Documentation

. 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 the system can be operated. 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 reports shall be used to track the progress of the project and that of 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 additional work to get back on schedule. A Microsoft Project Gantt chart is also being used to track the project delivery 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

To complete the problem definition the team must identify the end users and end uses of the system and identify the project constraints and limitations.

Subtask 1a: Identify End Users and End Uses

Objective: To understand the various features of the product.

Approach: It is very important to know who the users will be and how they wish to use the end-product.

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 will be using the system.

• The advisor will be consulted upon establishing a summary of anticipated users and how the users will use the system.

Expected results: The team will fully understand how the client party will interact with the system. This will be documented and used as the basis for the end-product.

Subtask 1b: Identify Project Constraints and Limitations

Objective: To understand the limitations of the product.

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

• Discussing with the advisor and deciding on which aspects of the project the team will accomplish based on current skills and knowledge of the team members.

• Informing the client on aspects of the project that can be implemented.

Expected results: The team will narrow the focus of the project in a manner that satisfies the client’s needs but also fits the capabilities of the team. The focus of the project will be maintained in dated documentation to provide reference in the future.

Task 2: Technology Considerations and Selection

In order to select technology for the project the team must complete several subtasks. The team will research currently existing systems and research existing programming and database management languages.

Subtask 2a: Research existing systems

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

Approach: To achieve success, the team will do the following:

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

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

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

Expected results: The team will have a clear idea on how to implement the project on a conceptual level. This plan will be documented in an outline and be followed according to the project schedule

Subtask 2b: Research Existing Programming and Database Management Languages

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

Approach: Before the design, the team must know the best language(s) 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 will decide on the programming and database management languages based on what the team is able to implement.

• Additional programming and database management language(s) shall be considered if the benefits outweigh the time required to beat the learning curve.

Expected result: The team will select the programming and database management language(s) that suits the capabilities of the team and the needs of the client.

Task 3: End-Product Design

The team will layout the plan for the prototype implementation of the system in the following steps.

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 will contact the client to see if any input procedures can be automated by the project.

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

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

Expected result:

• The client requests that the team will 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 two can add an item to the database, add data to an already existing item, and search the database for an item. A level three user can see what actions have taken place within the database. This is explained in the functional requirements section.

Subtask 3b: Break down project to facilitate implementation

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

Approach: For the application to get completed 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 will 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 will 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 will have a clear understanding of the different components needed to complete the project and how they interact with each another.

Task 4: Prototype Implementation

The team will complete the prototype in several steps including work delegation and coding and then code documentation.

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. 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 sets and specialization.

• 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 as a whole 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’ skill level.

• The team will complete the project within the allocated amount of time.

Subtask 4b: Code documentation

Objective: To make code readable and easily modifiable and make changes easily visible.

Approach: Code changes often, so it must be easily changeable, readable and understandable to future person(s) that man work with the system.

• All members of the team will 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 will be easily maintainable while being efficient and reliable.

Task 5: End-Product Testing

The team must complete extensive testing to ensure stability and functionality of the system since data reliability is of critical importance to the police department. The following subtasks will ensure that complete testing of the system is completed.

Subtask 5a: Individual Component Testing

Objective: To eliminate any bugs in each individual component.

Approach: Each member must come up with tests for 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 section of the code.

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

• The team will seek approved outside volunteers for testing the systems reliability, security, and efficiency from a fresh perspective.

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.

• End-product will be tested to full extent of the team’s resources.

Subtask 5b: Component Integration and Testing

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

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

• The team will 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 will 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 application is finished and each part is tested, then the entire application needs to be tested for problems that may not have occurred when the individual parts were tested. The steps for this are:

• The team will 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 will 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. Interacting directly with the client, the team will make observations and suggestions to get full testing.

Expected result:

• The team will successfully complete the system that the client envisioned. By following a testing outline the system should be complete.

Task 6: End-Product Documentation

For any system to be useful there must be a user’s manual. The team will develop a comprehensive user’s manual documenting all parts of the system.

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 application if they encounter a problem. They also may need to have someone else look at it, and so that person will need to understand it as well. 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 and use standard methods of documentation.

• 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 refer to when needed.

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

Task 7: End-Product Demonstration

The team will demonstrate the project to various people/groups to demonstrate the success of the project.

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 application can do. The steps to this preparation are as follows:

• The team will 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 they are responsible for developing.

Subtask 7b: Faculty Advisor 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 will present the entire project to the advisor.

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

Expected result: The team will practice and fine-tune its presentation. Class presentation will go well as planned.

Subtask 7c: Industrial Review Panel Presentation

Objective: To present a well planned presentation.

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

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

Expected result:

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

• The comments made by the industrial review panel will be considered for inclusion in the documentation.

Task 8: Project Reporting

The team will complete project reporting tasks to demonstrate that progress on the system is being made on schedule.

Subtask 8a: Weekly E-mails of Project Status

Objective: To inform team members, advisor, 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:

• Hold weekly meetings with the faculty advisor to discuss the progress of the project and any matters that may arise.

• Send weekly e-mails to faculty advisor, team members and the client on the weekly progress summary.

Expected result:

• The report shall keep the faculty advisor 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 determined first:

• Major details such as the scope need to be determined-- to be included in the project plan.

• Milestones will be set to ensure the objectives can be sorted.

Expected result:

The report shall keep the faculty advisor 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 application.

• 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 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. This will also make the poster visually appealing.

Expected result: The poster will be informative to people not working on the project.

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 application. Each item and feature of the application will need to be looked at and then explained in detail, and an overall explanation of the application would also need to be included.

Expected result: The final application will be explained in a report in which people outside the application 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 application runs. Each individual feature and parts of the application will need to be evaluated for functionality, security and usability. An overall evaluation would need to be done on the application as well.

Expected result: The final application will be evaluated and the results will be shown in the final report so people not on the team can understand what the data means.

4. Estimated Resource Requirement

These tables give an estimate of the projected 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: |  |  |

|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 |

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

[pic]

Figure 5-1. Project Schedule

5.2 Deliverable Schedule

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

[pic]

Figure 5-2. Deliverables Schedule

6. Student Team Information

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

Student Team Members:

Eric Hand (CprE)

200 Stanton Apt 205

Ames, IA 50014

(515) 291-1214

snokyguy@iastate.edu

Thomas Brezinski (CprE)

6115 Frederiksen Ct

Ames, IA 50010

(515) 441-1941

tbrezins@iastate.edu

Vignesh Vijayakumar (CprE)

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

Advisor:

Tom Daniels

3222 Coover Hall

Ames, IA 50011

(515) 294-8375

daniels@iastate.edu

Client:

Boone Police Department

Chief William Skare

(515) 432-3456

(515) 432-1564 fax

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.

References

MySQL –

PHP –

ePad Signature Pad –

Addendum

On February 25th, 2005 the team met with Chief Skare and his officers who will be utilizing the system. It was discovered that the previous design was created by Chief Losada without input from his officers that will be using the system. Chief Skare’s officers expressed that should the previous system design have been completed by the last team they would have not been happy with it. Instead the officers requested the team design a simpler system tailored to their more immediate needs. For the initial system design the barcode scanner and digital signature pad functionality will be omitted. The ability to attach files to a case and enter general notes will be required functionality of the system per their request. While this system is less complex it fills the immediate needs of the Boone Police Department and still allows for enhancement later.

Appendix A

[pic]

Figure A-1. Property/Evidence Form

Appendix B

[pic] Figure B-1. City Incident Report - Front

[pic] Figure B-2. City Incident Report - Back

Appendix C

[pic]

Figure C-1. Application Environment Topography

[pic][pic][pic]

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

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

Google Online Preview   Download