The document outlines a proposal for an RFID card time entry and resource access solution. It describes the old paper-based system and proposes a new RFID badge system that provides more flexibility and simplifies processes like time tracking and access management. The new system would use RFID badges for secure building access and time tracking through badge swipes that are logged. This allows for easy reporting, access removal for terminated employees, and time calculations. The proposal discusses stakeholders, requirements, costs, benefits, and project methodology to implement the new RFID badge system.

1. RFID CARD TIME ENTRY &
RESOURCE ACCESS SOLUTION
TEAM MEMBERS: STEVEN NAVA
MARTY MORADIAN
KERI KING

2. PROJECT OVERVIEW
Our project involved upgrading a corporate office to a digital time card and resource access system. We will outline
the current (old) system before we describe the new system and its implementation.
OLD SYSTEM
The current setup for the corporate office uses paper time cards to manage employees’ payroll. These paper time
cards are then entered into spreadsheets to perform the necessary calculations by the payroll department.
To access resources employees currently use physical keys and locks. A few keyholders throughout the building are
responsible for resource access and there is no log of access.
NEW SYSTEM
The new system uses RFID badges for resource access and time card punches. This provides more flexibility and
simplifies many processes. Termination of access is easer, resource access can be more granular and time cards are
much easier to manage.

3. SDLC PHASE 2: ANALYSIS – A SYNOPSIS

4. SKILLS AND PROJECT ROLES
• Steven Nava
• Project Manager
• Application Development Analyst
• Marty Moradian
• Business Analyst
• Network Analyst
• Keri King
• System Analyst
• Change Management Analyst

5. SYSTEM REQUEST
Project Name: RFID Badges for Secure Access and Employee Identification
Project Sponsor:
Name: Will Wheaton
Department: Office Manager
Organization: Enterprise Marketing Services
Phone: 877-867-5309
E-mail: Will.Wheaton@EMS.biz
Business Need:
The corporate office needs a more efficient way for employees and visitors
to gain entry to the office and to necessary resources. There is also a need
for a streamlined, less error-prone method of time tracking.
Functionality:
• Access readers allow entry by use of proximity badge
• Proximity badge allows use of dear resources, such as copy and fax
machines
• Software logs all entry swipes for each user
• Access logs may be easily compiled into reports on a per-user, per-
department or per-office basis
• Employee access may be easily revoked by an administrator
• Waving badge over particular sensor clocks employee in/out
• Time tracking software automatically calculates hours worked using
access logs

6. SYSTEM REQUEST CONTINUED..
Expected Value:
Tangible:
• Costs saved by reduction of guard labor force
• Costs saved by less time wasted by employees waiting
for resources to become available
• Costs saved from not having to rekey doors every time
an employee is terminated
• Costs saved from obsolescence of paper time cards and
their management/mismanagement
Intangible:
• Productivity gained from employees having immediate
access to all needed resources
• Productivity gained from faster and easier employee
access termination procedures
• Labor saved by front desk employees no longer needing
to open door for all employees/visitors
• Better business image due to modernization of office
space
• Improved quality of life for employees due to better
perception of management and feelings of greater
personal agency
Special Issues or Constraints:
• Procedures needed to handle lost badges
• Employees should be able to clock in/out if they have
misplaced their badge
• Procedures needed to handle badges not returned on
termination of employee – revoke access and reorder
cards when stock low
• If not developed in-house, time tracking software
must be compatible with RFID access system
• Look for a way to detect unauthorized access by RFID
spoofing -- most likely candidates are analysis of
access logs, and review of surveillance footage
• Must decide if the system fail open or closed in case
of power outages, and if closed, how/if access will be
possible; otherwise, need extra security procedures in
event of failed open system
• See if all interruptions of service be prevented by a
UPS and/or backup generator
• Prevent tailgating into secure areas by way of
mantraps and CCTV surveillance
• Procedures needed to protect the integrity of all
surveillance footage and access logs

7. ECONOMIC FEASIBILITY
2017 2018 2019 2020 2021 Totals
BENEFITS
Tangible start-up! 86,855.00 86,855.00 86,855.00 86,855.00 347,420.00
TOTAL BENS. 86,855.00 86,855.00 86,855.00 86,855.00 347,420.00
PV of BENS 82,719.05 78,780.05 75,028.61 71,455.82 307,983.53 PV=CashFlow/(1+intRate)^year
COSTS
Installation
software 64,902.00 64,902.00
hardware 81,153.50 81,153.50
vendor labor 42,300.00 42,300.00
employee labor 26,932.50 26,932.50
Operational
hardware 7,339.33 7,339.33 7,339.33 7,339.33 29,357.33
labor 15,244.00 15,244.00 15,244.00 15,244.00 60,976.00
TOTAL COSTS 150,386.00 22,583.33 22,583.33 22,583.33 22,583.33 240,719.33
BENS-COSTS (150,386.00) 64,271.67 64,271.67 64,271.67 64,271.67 106,700.67
Cum. Net Cash (150,386.00) (86,114.33) (21,842.67) 42,429.00 106,700.67
PV of COSTS 150,386.00 21,507.94 20,483.75 19,508.33 18,579.36 230,465.38 PV=Cost/(1+intRate)^year
NPV 77,518.15 NPV=PVBens-PVCosts
ROI 44% ROI=(TotalBens-TotalCosts)/TotalCosts
Break-Even Pt. (0.66) BEP=(YearlyNetCash-CumNetCash)/YearlyNetCash

8. COST ANALYSIS SUMMARY
Total Hardware
• $81,153.50
Total Services
• $42,300.00
Total Software
• $64,902.00
Total Development
• $222,000.00
Total Labor
• $26,932.50
Total Setup
• $437,288.00
Hardware Maintenance (Annual)
• $7,339.33
Labor Maintenance (Annual)
• $15,244.00

9. PROJECT METHODOLOGY
Waterfall Methodology
Reasons we chose this methodology:
• Project is highly structured and will not change
throughout its life.
• Project is small in size and scope and does not
involve many complex moving parts.
• Software requirements are straightforward-we
know exactly what is needed
• Once past the planning phase, any changes will
be very costly due to necessary changes in
hardware
• Easy to distinguish milestones throughout the
project

10. GANTT CHART BADGE & TIME CLOCK SYSTEM

11. SDLC PHASE 2: ANALYSIS – A SYNOPSIS

12. HIGH LEVEL BUSINESS REQUIREMENTS
• The ability to securely access rooms/resources.
• Log date/time as well as who accessed.
• Report generation by user and/or resource.
• The ability to securely punch in/punch out.
• Collect date/time stamp of in/out punches.
• Type of punch must be able to be differentiated (in, out,
break, lunch)
• Allow secure editing of incorrect/missing punches
(require manager sign off on changed punches).
• Employees must be able to access and modify time cards
from any device.
• Report generation by user/department/organization.
• Time card generation at end of pay period to calculate
total hours worked.

13. FUNCTIONAL REQUIREMENTS
Access Resources / Rooms
• Ability to securely access rooms or resources.
• User access to resources must be able to be modified. (in the event of role changes or job
requirement changes)
• User access to resources must be able to be revoked remotely. (in the case that the user
becomes no longer employed by the organization or role changes)
Log Access to Rooms/Resources
• Log and statistics must be created for user access that include: date/time, employee name,
and name of resource.
• Logs must be stored for needed length to be determined by audit requirements.
• Logs should be able to be filtered and sorted by user, department and organization.
Manage Time Card
• Users must be able to securely punch in and out.
• Type of punches must be able to be differentiated with/determined: punch in, punch out,
lunch, break, etc.
• Pay period hours worked must auto-sum; clocked in hours must determine cumulatively
automatically.
• Users must be able to submit edits/modifications to their own time cards (in the event that
a user misses a punch or has to work late after logging out).
• Time cards will be automatically generated at end of pay period.
• Time cards will require approval by employee and also by supervisor.
Log Time Card Activities
• Time cards should be stored in system/database for audit purposes specified by audit
length.
• All edits and approvals/rejections of edits will be stored in the system for a length of time
to be determined by audit requirements.
• If an edit is rejected by a manager then the rejection reason will also be stored in the
system.
Time Card Notifications
• Notifications will automatically be sent to managers for: time card edits to be processed
and time card submissions.
• Notifications will automatically be sent to users for: time card edit approval or rejections
and time card approvals and rejections.

14. NON-FUNCTIONAL REQUIREMENTS
Security Requirements
• Only employees and employees’ managers can view their time cards.
• Only employees can submit changes to their own time cards.
• Authentication is required for access to time card system.
• Notifications for time card updates/time card modifications and time card
approvals/denials are sent to the user.
Performance Requirements
• Real time acceptance/rejection of employee access to resources.
• Access log must be updated in real time.
• Any updates to user access to resources take effect in real time.
• Real time authentication of employee for time card access (web portal access).
• Time card punches must update time card in real time.
• Notifications for time card submissions must be sent to managers in real time.
• Notifications for time card approvals/denials must be sent to users in real time.
Operational Requirements
• Access management software must run on the Windows platform.
• Web portal for time card management can be accessed from any web browser.
• RFID access badges must be able to be printed for users on the first day of
employment.
• Logs must able to be stored for the required audit timeframe (Sarbanes Oxley,
COBIT, etc.)
Product
Properties
Attributes
Difficult
To
Capture
Not
Mandatory

15. BUSINESS REQUIREMENTS
After we completed the Interview/Observation/Questionnaire process, we found that that at
a high level, the business requirements for the system would include the following:
 The ability to securely access rooms/resources.
 Log date/time as well as who accessed.
 Report generation by user and/or resource.
 The ability to securely punch in/punch out.
 Collect date/time stamp of in/out punches.
 Type of punch must be able to be differentiated (in, out, break, lunch)
 Allow secure editing of incorrect/missing punches (require manager sign off on changed
punches).
 Employees must be able to access and modify time cards from any device on the domain.
 Report generation by user/department/organization.
 Time card generation at end of pay period to calculate total hours worked.

16. TIME CARD USE CASES
These use cases take explain how the actors and use cases for the
time card system interact with one another. There are three
main actors: the employees, the security associates,
and the management.
The employees represent anyone that is not a manager or a member
of the security team. These are the end users that are clocking in
and out. They also submit punch modifications when needed.
In cases where a manager or security associate is clocking in/out or
requesting a punch modification for themselves they are considered
an employee.
The managers are the users that are hiring employees, reviewing
punch modifications, and when needed requesting termination of
time card access.
Lastly, the security associates are the users that actually provide the
end users with access to the time cards and create the users’ RFID
badges. These users also process any access terminations generated
by management.

17. RESOURCE ACCESS USE CASES
These use cases take explain how the actors and use cases for the
resource access system interact with one another. There are three
main actors: the employees, the security associates,
and the management.
The employees represent anyone that is not a manager or a member
of the security team. These are the end users that are requesting
access to the resources and are accessing them a majority of the
time. In cases where a manager or security associate is requesting
access to resources or accessing resources they are considered an
employee.
The managers are the users that are requesting the initial system
access, approving any access changes, and if needed, requesting
the termination of access. In this way they oversee and shape
what resource access users have.
Lastly, the security associates are the users that actually provide the
end users with access and remove access when it is no longer
needed. The diagram on the right shows how each of the actors
Interact with the various use cases.

18. ACTIVITY DIAGRAM – REVIEWING
EMPLOYEE PUNCHES
The diagram to the right shows the activity diagram for reviewing
time punches.
The normal flow of events requires the manager to log into the
web portal and then review punches. At this point the manager
can either approver or reject the punch. If approved, an approval
e-mail will be sent to the user. If rejected a rejection reason would
be entered in and a rejection email would be sent to the user.
If the manager does not remember their password then a subflow
is entered that allows the manager to reset their password. They
would attempt to answer their security questions and if correct
they would be able to enter a new password. At that time they
would begin the normal process.
If not, then they would submit a request to HR to reset their
account password.

19. ACTIVITY DIAGRAM – REVIEWING
EMPLOYEE PUNCHES
The diagram to the right shows the activity diagram for accessing
Resources with an RFID badge.
The flow of events requires the user to scan their badge
at the access reader. If the user is approved to access the resource
then they will be granted access and it will be signified on the
access reader. At this point the access will be logged in the access
database (a database of access, not Microsoft Access).
If the user is not approved to access the resource then the access
will be denied and signified on the access reader. The access
access attempt will then be logged in the database.

20. CLASS DIAGRAM
TIME CARD SYSTEM
CLASSES
• Company - Includes Time Clocks
class and User Class.
• User – This comprises all users and
has classes Security Associate and
Manager that inherit from it.
• Time Card – This represents the
employees’ time cards. The class
Time Punch inherits from this class.
• Punch Modification – This class
represents a modified time punch.
• Time Clocks – These represent the
physical time clocks that have
several methods that they can call.

21. CLASS DIAGRAM
RESOURCE ACCESS
CLASSES
• Company - This represents the entire
company and includes Authorized
Resource Management User and
Resources classes.
• Resource– This represents any resource
that can be accessed and the Storage
Closet, Printers and Scanners, and
Rooms classes inherit from it.
• User Account – This class represents the
account for any users that only access
resources and do not manage them.
• Access List – This class represents the
accessible resources for each individual
user.

22. REQUIREMENTS GATHERING STRATEGIES
• Problem Analysis
Managers and business owners were interviewed to uncover the
key features that they thought should be included and highlight any
issues with the previous system.
• Root Cause Analysis
All ‘root causes’ were addressed to create requirements for the new
system. This was chosen as the project is multi-faceted and the end
result was to create something that met both the business’s fiscal
needs as well as the need of end users and managers.
In developing the new system, two different
requirements gathering strategies were used:

23. REQUIREMENTS ANALYSIS TECHNIQUES
• JAD (Joint Application Development)
A large round table meeting was held as a way of gathering data
from all members of management and the executive staff. In this
forum decisions were made on goals for the new system.
• Questionnaires
Any members of management or executive members that could not
be present at the roundtable meeting were sent questionnaires to
gather their thoughts and incorporate those into the requirements
analysis.
• Document Analysis
Document analysis was used to utilize the previous system and
determine what parts of the system could be reused.
Many different requirements analysis
techniques were used in the development of
the new system:

24. DESIGN STRATEGY
Our chosen design strategy was a mixture of commercial off-the-shelf products and in-house development. The
hardware is all COTS, as is the server and database management system. The time tracking software is all
developed in house. This provides the following advantages:
• The time tracking software is fully customizable – we can change or add features as needed. That flexibility
would be impossible with COTS software.
• The end-users can easily communicate their needs to the development team, and technical support is
available in-house.
• We save on licensing, maintenance, support, and upgrade fees versus COTS software.
• We don’t require the expertise or tools (and costs) to develop RFID tags, readers, writers, and door
controllers.
• We don’t have to develop our own server or database management software, which would be very time
consuming, costly, and difficult.

25. DESIGN STRATEGY
Risks mitigated by our design strategy:
• We do not need to trust external companies with our sensitive employee data
• There are no third-party code updates to apply – we can write our own updates and easily roll back to an
older version if we encounter problems
• We do not suffer the lack of support we would face if our hypothetical vendor went out of business or had
limited support hours (especially a problem for overseas vendors)
• We do not have to rely on a vendor to fix their software
Risks we accept because of our design strategy:
• When IT employees leave, they take knowledge of proprietary systems with them
• Support will be scarce when employees are all on vacation
• IT supports multiple systems, and we will have to choose which is most important to fix right now

26. SDLC PHASE 3: DESIGN – A SYNOPSIS

27. ACQUISITION ALTERNATIVE MATRIX
This table shows our alternatives for time-tracking software.
Product Meets Exact Business Needs Scalable for future needs
Management/Support
In-house
No need for additional add-
ons and license fees
Provides added skills value to IT
Custom In-house
Solution
    
TimePilot 
BioEnable  
MagiCard  
AlphaCard
Advanced
 

28. DATABASE DESIGN
• Restricted rooms, printers, storage
closets, and RFID time clock panels
are all considered resources
• Logging can be toggled on
resources, and resources may be
turned off electronically
• The Access List is consulted to see
if a user has access to a resource
• All access attempts are logged
Resource User
Access List
Time Clock
Resource
Access Attempt
Room
Storage Closet
Printer/Scanner
User ID uintPK
User Name string
Resource ID uintFKPK
User ID uintFKPK
Resource ID uintFKPK
Location string
Resource ID uintPK
Resource Type uint
Resource Description string
Attempt Date dateTimePK
Access Granted bool
User ID uintFK
Department Name string
Meeting Room Name string
Location string
Location string
Hostname string
Resource ID uintFK
Resource ID uintFKPK
Resource ID uintFKPK Resource ID uintFKPK
Department uintFK
Password string
Logged? bool
Reset Password? bool
Enabled? bool

29. DATABASE DESIGN
• It may be necessary to give
RFID access cards to guests,
such as vendors
• Therefore, the department and
company a resource user
works for is recorded
• The tables for Role and
Permission allow us to
configure the things a user is
allowed to do
• Example roles: admin,
manager, security
• Three security questions and
answers are stored for each
user, so they can recover their
account
Company
Resource UserDepartment
User RoleRole
Permission
Role Permission
Security Question
Security Answer
Company ID uintPK
Company Name string
Company Address string
User ID uintPK
User Name string
Department ID uintPK
Department Name string
Location string
Company ID uintFK
Department uintFK
Password string
User ID uintFKPK
Role Name stringFKPK
Role Name stringPK
Description string
Permission Name stringPK
Description string
Role Name stringFKPK
Permission Name stringFKPK
Question Text stringPK
Question Text stringFKPK
User ID uintFKPK
Answer string
Reset Password? bool

30. DATABASE DESIGN
• Time Cards are made up of Time
Punches
• Each row in Time Punch represents
the time work started or began
• Every time an employee clocks in or
out with a time card panel, a row is
added to Time Punch
• When an employee modifies their
time punches in the time-tracking
application, an entry is added to
Punch Modification
• The employee’s manager will
approve or reject each Punch
Modification, but the records will
remain in the database for 7 years
Time Card
Resource User
Time Punch
Punch Modification
Employee
Pay Period uintPK
Employee ID uintFKPK
User ID uintPK
User Name string
Punch Creation Time dateTimePK
Punch In? bool
Punch Modification Time dateTimePK
Approved? bool
Employee ID uintPK
Title string
Department uintFK
User ID uintFK
Password string
Pay Period uintFK
Approved? bool
Employee ID uintFK
Rejection Reason string
Punch Creation Time dateTimeFK
Punch In? bool
Time uint
Time uint
Employee Making
Change
uintFK
Reset Password? bool
New punch? bool

31. RESOURCE ACCESS MOCKUP

32. RESOURCE ACCESS MOCKUP

33. TIME TRACKING MOCKUP – EMPLOYEE VIEW

34. TIME TRACKING MOCKUP – MANAGER VIEW

35. ARCHITECTURE – RESOURCE ACCESS
• Both resource access servers are virtual
and run on Windows Server 2016
Enterprise. Each virtual server instance
runs on our pre-existing server blades.
• We have two HPE ProLiant BL660c
blades, each with 256GB RAM, 16TB
storage (SATA), and 4 Xeon E5 4620 (8-
core, 2.2 GHz) processors.
• We chose Microsoft SQL Server 2016
for our DBMS, as it integrates well with
our company environment
• All door access readers are Kantech
P325XSF readers with green and red
indicator lights
Corporate Office
Door Access Reader x 100
Kantech P325XSF
<<private>>
Cisco WS-C3850-48T-S
Switch x 1 (Door Access
Controllers Only)
<<private>>
Shared
Storage
<<private>>
Shared Storage (72TB)
HPE D3600 – 12 Bay Rack Enclosure
(MSSQL Resource Access DB) – RAID
10 Setup
Resource Access Primary
Server – Win Server 2016
(Virtual Blade)
Resource Access Mirror
Server – Win Server 2016
(Virtual Blade)
Failover Connection
Door Access
Controller
Access
Reader
<<private>>
Door Access Controller x 25
Kantech KT-400
Note: Each door access controller
manages 4 door access readers and
communicates with the servers
through a managed switch.
New Hardware/Software
(Failover Cluster)
Existing Hardware
Cisco WS-C3850-48T-S
Switch x 1 (Servers/Shared Storage)
<<private>>

36. ARCHITECTURE – TIME TRACKING
• The web application interface will be built in
house using C# and .NET and housed on our
existing MS Windows Servers, set up in a
load balancing cluster with IIS server roles.
• This enables high availability, uses existing
hardware and software, and keeps costs
down.
• A pre-existing 1GB T1 connection will be
used for SQL database mirroring.
• Our pre-existing switch will be used for the
virtual server instances and connected to a
new switch that we will use to manage all
the time clocks.
• All time clocks are Lathern LC600s, which
allow for RFID badge use.
Off Site Disaster Recovery Location
Corporate Office
Time Clock x 25
Lathem LC600
<<private>>
Cisco WS-C3850-48T-S
Switch x 1 (Time Clocks Only)
Cisco WS-C3850-48T-S
Switch x 1 (Servers/Shared Storage)
Shared
Storage
<<private>>
Shared Storage (72TB)
HPE D3600 – 12 Bay Rack Enclosure
(MSSQL Time Clock DB) – RAID 10
Setup
Failover Connection
Storage w/
Backup DB
Backup Database (72TB)
HPE D3600 – 12 Bay Rack Enclosure
(MSSQL Time Clock DB) – RAID 10
Setup [used for restoring primary
only]
Time Clock Primary
Server – Win Server 2016
(Virtual Blade)
<<private>>
<<private>>
Time Clock Primary
Server – Win Server 2016
(Virtual Blade)
Time Clock Mirror
Server – Win Server 2016
(Virtual Blade)
Load Balancing
Connection
Existing Hardware/Software
(Load Balancing Cluster)
Existing Hardware
Time Clock Mirror
Server – Win Server 2016
(Virtual Blade)
Failover
Connection

37. SDLC PHASE 4: IMPLEMENTATION – A SYNOPSIS

38. USER DOCUMENTATION
We decided to go with a wiki page for all the user
documentation.
This page can be pulled up from any of the domain
connected PCs.
The wiki page will have a search field that will pull up
the correct documentation when it is searched for.
This page will be categorized by type and the how-to
documents will show users how to complete each task.

39. CONVERSION PLAN
Conversion Style
For this project two conversion styles were used: Parallel Conversion and Direct Conversion.
Parallel Conversion Syle
This conversion style was chosen for the time card conversion part of the system. The time card system
deals with sensitive data and employee payroll; for these two things it is very important to get them
right. The digital RFID time card system will be used in conjunction with the old system for one month
to see if there are any inconsistencies in the data output. If there are not then the new system will fully
replace the old system.
Direct Conversion Style
The hardware for the RFID resource access system requires that the physical locks be replaced with
digital locks. This makes it highly illogical for the parallel conversion style to be used for this conversion.
For that reason, the direct conversion method was chosen for the resource access portion of the
conversion plan.

40. CONVERSION PLAN
Conversion Location - Simultaneous Conversion Location
This project will convert the entire system at one time, utilizing the simultaneous conversion location.
Converting the entire location at one time will simplify the conversion for the end users as they won’t
have to keep track of different conversion phases or which system to use currently. It will also make it
easier on payroll and management associates as otherwise they would have to differentiate the
employees and determine which are on the new system and which are not. Lastly, it is also a better
choice for security as there will be fewer keys in the environment for access, which will take on less
risk.
Conversion Module – Whole System Module
Due to the fact that the new system is very interdependent and can’t truly be broken down while
maintaining functionality, the whole system module was chosen. As the system isn’t very complex, the
whole system module method shouldn’t pose an issue.

41. TEST PLAN – UNIT TESTS
The unit testing for the system will be performed concurrently with development utilizing a test-first
approach. This involves writing a failing test first and then writing the minimal amount of code to
make the test pass. Any time there is a change in the code, the tests are re-run to make sure the code
is still valid.
Integration Testing
User Interface Testing
Since the time clock application is a web application, user interface testing for it will be much
more simple than for a web application. All output will be validated individually and then all the
links will be verified to ensure that they are not broken.
Use Case Testing
Use case testing will be performed for each iteration of the time tracking web application. Use
case testing will be performed before each iteration of user interface testing.
System Interface Testing
The database will be tested using the database management software. Testing will be completed
to make sure that the RFID readers can write valid data to the databases and that they can
properly validate input against the database.

42. TEST PLAN – CONTINUED
System Testing
Requirements Testing
The system will be tested to ensure that all functional requirements have been met. This will occur
at each major system change.
Usability Testing
An interactive evaluation will be performed at each iteration of the time card UI. The UI will
meet all of the Web Content Accessibility Guidelines and satisfy Jakob Nielsen’s 10 Usability
Heuristics.
Documentation Testing.
After each major system update, the documentation will be checked to ensure that it is still valid.
Also, since a wiki is being used, a talk page will be implemented for feedback after each major
change.
Performance Testing
Once all network components have been installed stress testing on the network will take place.
The database and the server will be tested separately from the network and will allow for 20
concurrent connections from each user and just as many database transactions.

43. TEST PLAN – CONTINUED
System Testing
Security Testing
All physical components will be tested to ensure that installation was carried out in a way that
they can not be tampered with. All methods of authentication will be tested to ensure that they
can not be bypassed. Vulnerability scans and penetration testing will be carried out by an
experienced third party security company. Lastly, backup and restoration procedures will be tested
before full deployment and after each major change. If no major changes are made then it will be
tested once per year.
Acceptance Testing
Alpha Testing
Alpha testing will be carried out once the time tracking application has passed use case and user
interface testing. Mock data will be used to carry out the tests.
Beta Testing
Beta testing will be carried out once all other tests have been completed and prior to deployment.
Both the time tracking and the RFID application will be tested by the users.

44. POST IMPLEMENTATION
Maintaining the System
Training will be conducted for on-site staff so that they can fully support, maintain and manage the system.
Regular updates for the in-house time card solution and for the COTS resource access management
application will be deployed and installed regularly.
End User Training
End user training will be carried out in small groups. The same usage and on the job functionality training will
be carried out for each group. All documentation will also be available for download for the associates.
Training Topics Special Topics
• Benefits and Features
• System Enrollment
• Entering/Editing Time
• Password Changes
• Lost or damaged Cards
• Security Best Practices
• Requesting Changes or Additional
Features
• How to Get Help
• Management: Editing Employees’ Time
• Management: Auditing Employees’ Hours
• HR: New Hires/Terminations
• IT: System Management – Hardware
• IT: System Management – Software
• IT: System Management - Database

45. SYSTEM REVIEW
System reviews will be completed at multiple intervals after implementation, specifically at 30,
60, and then 90 days.
These reviews will focus on:
• The end user’s happiness with the new solution
• Any pain points in the new system
• Any further improvements that can be made to the system
Once the system review has been completed, any changes identified will be implemented to
further improve the system.

46. WHAT WORKED (LESSONS LEARNED)
In this project there were a lot of things that had to be coordinated among a team and a lot of these things were new to
us. We learned a lot about systems analysis and design and what we were good at and what we thought we were good
at. Here are the things that we did well.
• Models and any design aspect – We found that once we got to the design phase and things were visual that
things made more sense to us and were easier to work with.
• Communication – Overall we did a great job of communicating with one another and coordinating tasks. Any
changes were communicated between each an efficient and professional manner.
• Helping each other learn – We all have different backgrounds and this was obvious when we were completing
tasks. Keri, for instance has a background in networking and security. Marty has a solid understanding of
programming structures and databases. Steven has a background in client/server management. Utilizing these
different backgrounds we were able to really help each other out with some of the assignments in this project.

47. WHAT WAS DIFFICULT (LESSONS LEARNED)
Several times in this project there were difficulties that had to be overcome for us to continue. Here are some of the
lessons we learned that we would apply if we had to do this again.
• Plan earlier – The timeline for the project seemed to get tighter and tighter as it went along. Some of the
aspects of the project had to be more fully planned or discussed so we could get a better understanding of
what we were doing before we proceeded.
• Seek clarification – Some of the tasks, especially with us being new to this, seemed vague. There were times
where it felt like we either didn’t have enough information or knowledge to go off of and had to discuss among
ourselves to come up with a plan.
• Get a very concrete planning phase in place before tackling the rest of the project – Everything builds off of the
planning phase – everything. Most of the tasks in the other phases use input from the planning phase in one
shape or another – whether it be the functional requirements or the GANTT chart. With a solid concrete
understanding of the system in the planning phase many of the other phases will be easier.
• It will take you longer than you think – Almost every task that was completed took longer than we thought it
would take, whether that be Powerpoint presentations, UML diagrams, or system requests.