Computerized
Sign In/Sign Out System
10-14-03
Presentation Overview
► Client
► Concept
of Operations
► Requirements
► Specifications
► Project Management Plan
► Test Plan
► Questions & Answers
Client
► Jacqueline
A. Smith
 Director Minority Engineering & Computer Science
Programs
 jasmith@mail.ucf.edu
 (407) 823-5486
Concept of Operations
► Proposed






System
Description
Needs
Users & Modes of Operation
Operational Scenarios
Expected Impacts
Analysis
Proposed System: Description
►
The Minority Engineering Center of Academic Assistances lab would like a more
efficient way for students and tutors to sign in and out when entering the
lab. A way to keep track of the time that students and tutors spend in the lab
is needed. Also, a need for an administrator of the lab to quickly find certain
statistics such as the average amount of visitors to the lab, average time spent
in the lab, and what major are the majority of students enrolled in. Statistical
analysis will help show that the lab is indeed helping many students and is
beneficial to the school.
Proposed System: Needs
► More
efficient way to Login/Logout
► Accurate way to track lab usage time
► Provide statistical reports
 Avg. amount of visitors
 Avg. time spent
Proposed System: Users & Modes of
Operation
► Users
 UCF Students
 Tutors
 Administrators
► Modes
of Operation
 Normal
 Manual
Proposed System: Operational Scenarios
► Typical

Scenario
The student swipes there UCF I.D. card to login. There I.D. is found in the database and the
time is logged. The student than receives help from the tutor and prepares to leave the
lab. Once the student leaves the lab they will be asked to swipe there UCF I.D. and the time
shall be logged and the student shall be logged out.
► Atypical

Scenario
The student or tutor wishes to login. They are asked to swipe there UCF I.D. card but they
forgot it. On the screen will be a box for the student of tutor to enter there NID and login. After
the student or tutor enters there NID the time shall be logged in a database. Once the student
or tutor are ready to leave they shall enter there NID in the box on the screen and the time shall
be logged in a database.
Proposed System: Operational Features
► Features




Friendly user interface
Accurate way to record login/logout times
Card swipe reader for simple login/logout
View and print statistical reports
► Options
 Record subject student is tutored in
 Way to evaluate the tutors
 Send emails to students to evaluate the lab
Proposed System: Expected Impacts
► MECCA
lab will have user friendly system
► Login/logout will be easier/quicker
► Accurate log times kept
► Accurate & quicker report generation
Proposed System: Analysis
►
Expected Improvements
 Faster way for users to login/logout
 Accurate Statistical Reports
►
Disadvantages
 Client decreases report functionality for user friendly system
►
Limitations
 Time constraints
►
Risks
 Time to interface to card reader
►
Alternatives & Tradeoffs
 Develop system without card reader
 Improving the current computerized system
Specifications
► Overview
► Use
Cases
► Specific Requirements
Specification: Overview
► Assumptions
 Users will have UCD ID card in hand
 Users will remember NID
► Stakeholders
 Client: Jacqueline Smith
 Users
 Developers
Specification: Use Case
The students can either log in to
the system by swiping their UCF ID
or manually by clicking on the
“Login” button on the main screen
and entering their NID.
► The students may log out of the
system by swiping their UCF ID or
manually by clicking on the “Login”
button on the main screen and
entering their NID.
► The students may use the “Modify
Profile” button on the main screen
to update their information in the
user database.
►
Computerized Login/
Logout System
Login
Logout
Student
Modify Profile
Specification: Use Case
►
►
►
►
Administrators manually
log in to the system using
a password for
authentication.
Administrators may add
tutors using the tutor
manager page.
Administrators may
remove tutors using the
tutor manager page.
Administrators may
generate statistical reports
using the reports manager
Computerized Login/
Logout System
Login
Logout
Add Tutor
Administrator
Remove Tutor
Gererate Reports
Specification: Specific Requirements
►
Functional Requirements:
 System must log the times that the user logs in and out of the lab
 System must be able to generate statistical reports on the usage of the lab
►
Environment Requirements:
 Hardware
►
►
►
►
Pentium III or equivalent
128 MB Ram
250 MB free hard disk
Available serial port
 Software
►
►
►
Windows 98SE/ME/2000/XP
JRE
Extended Java COMM package
Project Management Plan
► Application Standards
► Team Organization
► Deliverables
► Software Lifecycle Process
► Tools & Computing Environment
► CM & QA
► Risk Management
► PERT Chart
► Metrics
PMP: Application Standards
► Coding
Standard
 Java Code Convention
(http://java.sun.com/docs/codeconv/)
► Documentation
Standard
 Hard & Soft copy format
 12pt, Times New Roman, Sections Headers
underlined and bolded
► Artifact
Size Metric Standard
 Original LOC vs. Modified LOC
 Milestones & Deadlines
PMP: Team Organization
► Group
Members
 Mike Bergandi
 Tommy Fulbright
 Kyle Hancock
► Group
Communication
 Email
 Online Messaging Services
PMP: Deliverables
Artifacts
Due Dates
Concept of Operations
10/03/03
Software Requirements Specification
10/03/03
Project Management Plan
10/03/03
Project Management Report
11/18/03
High-Level Design
10/21/03
Detailed Design
10/21/03
Test Plan
10/03/03
Test Results
11/18/03
User's Manual
11/18/03
Source Code
11/18/03
Build Instructions
11/18/03
Project Legacy
11/18/03
Final Presentation
11/18/03
PMP: Software Lifecycle Model
► Waterfall
 Proven Model
 Early Fault Detection
(Feed Back Loops)
PMP: Tools & Computing Environment
► Java




2 environment extended packages
Swing GUI development
JDBC
Access Database
COMM Port Functionality
PMP: CM & QA
► CM
 Version Control via naming convention
(Doc. Ex. FileName_Date.doc)
 Change Control via baselines
► QA
 Inspections
►Documentation
►Source
Code
PMP: PERT Chart
PMP: Metrics
►
Requirements Phase
 Number of requirements changes vs. number of requirements
►
Specifications Phase
 Number of requirements specified
►
Implementation Phase
 Number of classes, classes added/removed, number of loc vs.
modified loc
►
Integration Phase
 Number of code conflicts
►
Maintenance Phase
 Number of changes in overall project, including documentation and
source code
Test Plan
► Objective:
Find Errors
► Stopping Criteria
 Successful Scenario Test
 Client successful test
► Test
Cases
Test Plan: Individual Test Cases
Test
01
Cas
e#
Test Objective
Card Reader is being read
properly
Test Description
A student swipes his ID
and the data is
read from the card
Test
Conditio
n
Expected Results
See Test
Environme
nt
Student is either
prompted to
enter his
account
information or
is prompted
with a
"Welcome"
Initial Student Account setup
upon first login
A student swipes his ID
and the account is
not found
See Test
Environme
nt
Student is
prompted to
complete the
account
information
Subsequent Student logins
A student swipes his ID
and the account
record is found.
See Test
Environme
nt
Student is
prompted with
a “Welcome
Back” message
04
Time stamp is recorded when
student logs in
A student logs in and
the time is stored
in the database
See Test
Environme
nt
Student is
prompted with
a “Welcome”
message
05
Time stamp is recorded when
student logs out
A student logs out and
the time is stored
in the database
See Test
Environme
nt
Student is
prompted with
a “Thank You”
message
02
03
Question & Answer