Taylor’s professional Services Staffing request management system

1. Taylor’s professional ServicesStaffing request management system By Cale Coyle, Michael Kozy, Brian Maerhofer, Christopher Ozaetta, David Rigsby

2. Staffing Request Management System Taylor’s Professional Services (TPS) is a technical and engineering staffing service. TPS wants to provide a web site so that their clients can complete a staffing request over the internet. In addition, TPS wants to provide their clients with a list of potential candidates based on experience, education, salary, and location. The goal of this project is to create a web-based application that will fulfill the requirements and needs of TPS. The project lead will ensure that all goals are met throughout the course of the project. All of the other members have been assigned specific roles that they specialize in. Each member will assist one another to get each task completed. Milestones have been set and planed with the goal of ensuring that each task is completed at the appropriate time. Microsoft Project will be used to help control the scheduling. Assignments have been laid out to help show for which tasks each team member is responsible. Risk types have been set up to help show what could occur throughout the project. They are displayed by probability, impact, detection difficulty, and when it could possibly occur. This can help reduce a surprise at a later time. This is displayed on the risk assessment matrix. Throughout the plan software applications are listed as well as testing procedures that will be tested at all times to ensure quality is top notch. Standards and procedures will also be written to make certain that the program run smoothly one it is live. Project description

3. Team Members Team structure

4. Requirements Overview The system was designed to allow the maintenance and retrieval of three types of data: • Staffing Requests • Contracts • Staff Information Project Specifications: • Creation, modification, storage, and retrieval: • staffing request information • contract information • staff information • user access information • Allows a client: • enter a staffing request into the database. • retrieve staffing request information. • Allows the contract manager: • retrieve a staffing request from the database • retrieve contract information • validate the staffing request • close out the staffing request. • Allows a staff member to update their personal information, resume, availability, and picture. System details

5. Requirements Overview The goal of the system was to create an intuitive user interface with a clean look and feel that will allow the end users to easily navigate and utilize the Staffing Request Management System. The must also be easy to maintain, especially with regards to the access control creation and maintenance activities. As such, access controls were planned to allow flexibility in the definition of system roles and access permissions. The basic system defines four types of users: • Client • Staff • Contract Manager • System Administrator Each of these authenticated system roles will be granted access to features based on a matrix that associates roles to features of the system. Accordingly, public non-authenticated users will have limited access to the web site. System details

6. Design Overview The objective of the Design document was to detail the system functionality based on the requirements document. The system design document included the following items: • Definition of the major system features • A detailed data dictionary • Event Diagrams for each major feature • Use cases for each major feature • Pseudocode for central modules • Module usages (uses/used by) The system design document served as a basis for the construction phase of the project. As questions arose, the design document was consulted. As construction progressed and changes occurred, the system design was updated to reflect these changes. Data Storage System details • Records are being stored in a Microsoft Access Database. Considering the size of the application, the most efficient storage method would be with Access. The more records that are added could determine the change to more of an enterprise level database such as Oracle. • The database is structured using 3rd normal form • Each table includes unique primary and foreign keys (where needed), thus creating the relational schema. • Passwords stored within the database have been encrypted. The decrypted versions of the password are never sent to the web browser

7. Design Overview System Details • The System is divided into separate menus for easy navigation • Each type of user has different access abilities and adjusted appropriately for the job function required for daily use.

8. SYSTEM DETAILS Major Functions Request Creation • Clients will be able to make staffing requests by accessing the website. The client is asked to fill out fields for experience, education, salary and location. The information will then be linked up to match the best candidate located in the database. Request Modification • Modifications are made when the results come back from a matching candidate. Information can be modified and resubmitted if needed. Request Retrieval • All staffing requests will be viewed via a query with the current status of that request. The staffing requests are listed by it’s ID number.

9. SYSTEM DETAILS User Access User Modification • System Administrator creates all user accounts and grants access to each account. • All users are granted permissions to insert and select records. Only the system admin has full range on permissions. • Upper management has the same abilities as users with the exception of delete options therefore if a record has to be deleted, it must be verified by management

10. Construction Overview System Details

11. Testing Results System Details • Four types of tests were completed throughout the design profess for TPS. • Unit Testing Strategy • Integration and System Test Scripts • Basic Test Scripts • User Acceptance Test Plan • Below are the results and the amount of tests completed for each type of user group.

12. Problems and Lessons Learned Post Mortem • Lessons Learned: • Better preparation ahead of schedule to keep the tasks moving to allow more time for review. • To equal out the work load so that everyone pulls their portion of the project.

13. Application Demonstration Final Product