Date: December 4 , 2010

bewgrosseteteSoftware and s/w Development

Dec 13, 2013 (3 years and 7 months ago)

190 views

Date:


December 4
th
, 2010

To:


Dr. Charles Mawhinney

From:


Team Alpha

Subject:


Project 2

Our submission for Project 2 is enclosed. I hope you find

our solution acceptable. Please do not hesitate to contact
us if you have any further questions.








2010


Team Alpha


Kyle Coberly
Jacob Kennedy
Dustin Rotunda
Elliott Chhem


[
FEASIBILITY STUDY FO
R
REPLACING
THE CIS DEPARTMENT Q
UIZ SYSTEM
]

http://goteamawesome.wikidot.com

TABLE OF CONTENTS

Executive Summary

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

1

System Description

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

2

Use
-
Case Analysis

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

3

Use
-
Case Dia
gram

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

3

Use
-
Case Table

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

4

Use
-
Case Narratives

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

4

I/O Analysis
................................
................................
................................
................................
..............................

11

User Interface Analysis

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

11

Proc
essing Analysis
................................
................................
................................
................................
..................

13

Context Diagram

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

13

Level
-
0 Data Flows

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

14

Functional Decomposition Diagram
................................
................................
................................
....................

15

Data Flow Diagram

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

16

Process De
scriptions

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

16

Data Structures

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

17

Database Analysis

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

18

Entity
-
Relationship Diagram

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

18

Example data tables

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

19

Recommended Implementation

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

21

Development Strategy

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

22

Feasibility Analysis

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

23

Appendix

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

24

Revised Project Plan

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

25

Questionnaires

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

25

Interveiw with Dr. Charles Mawhinney 11/03/10

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

25

Interview with Annette Lege 11/10/10

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

26

Journal

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

28

Meeting Notes

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

28

Introductory Email 10/31/10 (Email from Kyle Coberly to group)

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

28

Website Built 11/3/10

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

29

Tentative Schedule 11/4/10 (Email from Kyle Coberly to Group)

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

29

Project Update 11/27/10 (Email from Kyle Coberly to Group)

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

29

In
-
Class Meeting 12/1/10

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

30

Documents Collected

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

31

IS Service Request

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

31

Problem An
alysis Matrix

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

32

Original Code

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

34



Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



1

EXECUTIVE SUMMARY

The
current
online quiz system is used for different courses in the CIS program. It has been in use for
approximately ten years, and many undocumented modifications have been made over time. There are at least
two different
versions of this system in presently in use. Many of the system processes are automated, but some
require manual entry and special technical expertise to perform. Several requests have been made to improve the
system and to make it less dependent on the tw
o individuals who serve as system administrators for the system.

The proposed quiz system has two functional areas
-

a student subsystem and a faculty subsystem. The student
subsystem is responsible for handling student quiz submissions. The faculty subsyst
em is responsible for handling
quiz and user maintenance. The new system uses a simple GUI
-
based system that simplifies user interactions, thus
eliminating the need for administrators to have special technical expertise.

The proposed system stores data abo
ut students and faculty members,
as well as housing a quiz
question bank.
Quizzes are assembled by adding questions to them from the question bank. When a student submits answers

to
the system
, verification is sent to the student, the quizzes are graded, a
nd the grade is stored in the system.
Instructors are able to use the GUI to retrieve grades from quizzes, and system administrators are able to use the
GUI to perform maintenance on both users and quizzes.

A possible implementation of this model involves
using Perl and XML to deliver the system online via a browser.
This keeps the technological requirements low for any user of the system, and doesn’t require any special software
installations. Rapid application development techniques can be used to deliver

prototypes for testing quickly, and
develop the final product around incremental improvements to the prototypes. When an acceptable version of the
application is completed, a “big
-
bang” roll
-
out can be used at the beginning of a new semester.

This solutio
n
satisfactorily meets
all six feasibility criteria.



It meets all user requirements



All stakeholders should find it culturally acceptable



The system is simple enough to use that it won’t require specialized knowledge or extensive training



It may be possibl
e to write or adapt the code using in
-
department talent



It can be implemented in a reasonable time
-
frame



There are no foreseeable legal issues

Team Alpha requests approval from the CIS department to begin the physical design and implementation of a new
qui
z system based on this plan.



Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



2




SYSTEM DESCRIPTION



Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



3

USE
-
CASE ANALYSIS

USE
-
CASE DIAGRAM




Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



4

USE
-
CASE TABLE

Actor

Use Case

Trigger

Responses

Student

Submits a quiz

Quiz completed

Grade submission

Store grade in database

Administrator

Sets up a new user

New student

Add new user to database

Administrator

Modifies a quiz

Quiz modification needed

Database updated

Administrator

Manually removes a quiz

Quiz not needed

Quiz deactivated

Administrator

Removes users

Student no longer in course

Delete student
from database

Administrator

Builds quiz

Quiz needed

Database updated

Administrator

Submits quiz question

Question needed

Question entered

Administrator

Posts a quiz

Quiz activation needed

Quiz activated

(time)

Automatically removes a quiz

(quiz end
time)

Quiz deactivated

Instructor

Generate grade report

Grades needed

Submission Verified

There are two subsystems being used: A student system which is designed to display quizzes and accept quiz
submissions, and a faculty system that interacts with
administrators and instructors. This system is where
instructions generate grade reports, quizzes are automatically removed based on an expiration date, and
administration perform user maintenance and quiz maintenance.

USE
-
CASE NARRATIVES

Use
-
Case Name:

Su
bmit Quiz


Use
-
Case ID:

SubmitQuiz

Priority:

High

Primary Business Actor:

Student

Other Participating Actors:

Web Server (External Server)

Other Interested Stakeholders:

Instructor
-

Needs grades from submitted quizzes

Description:

This use case
describes how a student accesses a posted quiz, answers
questions, and submits them.

Precondition:

The student requesting the quiz must be added to the quiz system

The quiz that the student wants to take must be added and enabled
.

Trigger:

The student mu
st access the system and select a quiz. The student answers
the questions in the quiz. The quiz is submitted when the student takes an
action (e.g., clicks a button) to submit it.

Typical Course of Events:

Actor Action

System Response

Step 1: The
student is authenticated
into the system
.

Step 3: The student selects a quiz
.

Step 5: The student selects answers
and submits them
.

Step 2: The system gives the student
a choice of quizzes to take
.

Step 4: The quiz is displayed to the
student
.

Step 6: The
system verifies the
submission to the student
.

Step 7: The system grades the
submission
.

Step 8: The system stores the
submission and the grade
.

Alternate Courses:

Alt
-
Step 2: The login information is incorrect, and the student is prompted
to reenter the
correct login information.

Conclusion:

The use
-
case concludes when a student submits a quiz and the submission
is verified, graded, and stored.

Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



5

Postcondition:

The submission and its grade are stored in the system.

Business Rules:

Students must be
authenticated
.

Students must select quizzes
.

Students choose answers using a form
.

Students submit the form
.

Implementation Constraints and
Specifications:

None specified.

Assumptions:

The student is enrolled in the course
.

The course has quizzes availab
le to take
.

Open Issues:

None.


Use
-
Case Name:

Setup New User


Use
-
Case ID:

SetupNewUser

Priority:

Medium

Primary Business Actor:

Administrator

Other Participating Actors:

Web Server (External Server)

Other Interested Stakeholders:

Instructor
-

Needs to be added to database

Student
-

Needs to be added to database

Administrator
-

Needs to be added to database

Description:

This use case describes how an administrator adds new users to the
system.

Precondition:

If the actor is a student, they must b
e enrolled in a CIS course.

Trigger:

The instructor must send an administrator a list of people to add to the
system that includes user names and passwords.

Typical Course of Events:

Actor Action

System Response

Step 1: The administrator is
authenticated into the system
.

Step 3: The administrator choose to
add new users
.

Step 5: The administrator enters
new user information.

Step 2: The system administrator a
choice of actions to take.

Step 4: The system prompts the
administrator to enter use
r
information.

Step 6: The system verifies the
submission to the administrator.

Alternate Courses:

Alt
-
Step 2: The login information is incorrect, and the student is prompted
to reenter the correct login information.

Alt Step 6: The data entered isn’t an
慰p牯p物慴e⁤慴愠瑹peH 慮T⁴he⁳祳瑥W
p牯mp瑳⁴he⁡Tm楮楳瑲W瑯爠瑯 en瑥爠捯牲r捴cv慬aeV.

Conclusion:

The use
-
case concludes a new user is added into the system.

Postcondition:

The new user is in the system.

Business Rules:

Students must be enrolled in a

CIS course
.

Faculty is either an instructor (Rank 2) or administrator (Rank 3)
.

Implementation Constraints and
Specifications:

None specified.

Assumptions:

There is an existing administrator able to carry out the actions.

Open Issues:

None.




Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



6

Use
-
Case Name:

Remove User


Use
-
Case ID:

RemoveUser

Priority:

Low

Primary Business Actor:

Administrator

Other Participating Actors:

Web Server (External Server)

Other Interested Stakeholders:

Instructor
-

Needs to be removed from the database

Student
-

Needs to be
removed from the

database

Administrator
-

Needs to be
removed from the
database

Description:

This use case describes how an administrator
removes users from

the
system.

Precondition:

The actors must no longer need to have access to
the system.

Trigger:

The instructor must send an administrator a list of people to
remove from

the system
.

Typical Course of Events:

Actor Action

System Response

Step 1: The administrator is
authenticated into the system
.

Step 3: The administrator choose to
remove

users
.

Step 5: The administrator
selects
users to remove.

Step 2: The system administrator a
choice of actions to take.

Step 4: The system prompts the
administrator to
select which users
to remove.

Step 6: The sys
tem verifies the
removal

to the administrator.

Alternate Courses:

Alt
-
Step 2: The login information is incorrect, and the student is prompted
to reenter the correct login information.

Alt Step 6: The data entered isn’t an appropriate data type, and the
VyV瑥W
p牯mp瑳⁴he⁡Tm楮楳瑲W瑯爠瑯 en瑥爠捯牲r捴cv慬aeV.

Conclusion:

The use
-
case concludes
when a user is removed from

the system.

Postcondition:

The user is no longer in the system.

Business Rules:

Students must be enrolled in a CIS course
.

Faculty
is either an instructor (Rank 2) or administrator (Rank 3)
.

Implementation Constraints and
Specifications:

None specified.

Assumptions:

There is an existing administrator able to carry out the actions.

Open Issues:

None.


Use
-
Case Name:

Modifies a Quiz


Use
-
Case ID:

ModifyQuiz

Priority:

Low

Primary Business Actor:

Administrator

Other Participating Actors:

Web Server (External Server)

Other Interested Stakeholders:

Instructor
-

May initiate a quiz modification

Description:

This use case describes

how an administrator

modifies an existing quiz.

Precondition:

The

quiz must need to be modified.

Trigger:

The instructor must send an administrator a list of changes to make or an
administrator must make a list of changes.

Typical Course of Events:

Act
or Action

System Response

Step 1: The administrator is
authenticated into the system.

Step 3:
The system administrator
chooses to modify a quiz.

Step 5: The administrator selects
a
Step 2: The system administrator a
choice of actions to take.

Step 4: The system prompts the
administrator to select which
quiz to
modify.

Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



7

quiz to modify.

Step 7: The administrator modifies a
quiz question
.

Step
8: The administrator confirms
changes
.

Step 6:
The system displays the quiz
questions
.

Step 9: The system
verifies th
e
modification.

Alternate Courses:

Alt
-
Step 2: The login information is incorrect, and the student is prompted
to reenter the correct login information.

Alt Step
9: The modification isn’t legal, and the administrator is prompted
瑯⁣ 牲r捴c瑨e⁣ 慮来.

Conclusion:

The use
-
case concludes when
the modification is finished.

Postcondition:

The
modified quiz is available to users.

Business Rules:

An administrator can modify an existing quiz.

Implementation Constraints and
Specifications:

None specified.

Assumptions:

The quiz to be modified already exists.

Open Issues:

None.


Use
-
Case Name:

Manually Remove Quiz


Use
-
Case ID:

ManuallyRemoveQuiz

Priority:

Low

Primary Business Actor:

Administrator

Other Participating Actors:

Web Server (External
Server)

Other Interested Stakeholders:

Instructor
-

May initiate a quiz removal

Description:

This use case describes how an administrator manually removes quizzes.

Precondition:

The quiz
must need to be removed.

Trigger:

The instructor must
request that

a quiz be removed

or an administrator
must choose to remove a quiz.

Typical Course of Events:

Actor Action

System Response

Step 1: The administrator is
authenticated into the system.

Step 3: The system administrator
chooses to
remove

a quiz.

Step 5: The administrator selects a
quiz to
remove.


Step 2: The system administrator a
choice of actions to take.

Step 4: The system prompts the
administrator to select which quiz to
remove
.

Step 6:
The system verifies the quiz
removal.

Alternate Courses
:

Alt
-
Step 2: The login information is incorrect, and the student is prompted
to reenter the correct login information.

Conclusion:

The use
-
case concludes when the
quiz is removed
.

Postcondition:

The
quiz is no longer active in the system.

Business
Rules:

If a quiz is no longer needed, an

administrato
r can remove a quiz.

Implementation Constraints and
Specifications:

None specified.

Assumptions:

The quiz to be
removed

already exists.

Open Issues:

None.




Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



8

Use
-
Case Name:

Build a Quiz


Use
-
Case
ID:

BuildQuiz

Priority:

High

Primary Business Actor:

Administrator

Other Participating Actors:

Web Server (External Server)

Other Interested Stakeholders:

Instructor
-

May request that a quiz be built

Description:

This use case describes how an
administrator builds quizzes.

Precondition:

A quiz needs to be built.

Trigger:

The instructor must request that a quiz be built or an administrator must
choose to build a quiz.

Typical Course of Events:

Actor Action

System Response

Step 1: The
administrator is
authenticated into the system.

Step 3: The system administrator
chooses to
build

a quiz.

Step

5: The administrator selects
questions to put into the quiz.

Step 6: The administrator submits
the assembled quiz.


Step 2: The system administra
tor a
choice of actions to take.

Step 4: The system prompts the
administrator to select
questions to
put into the quiz.

Step 7
: The system verifies the quiz
construction.

Alternate Courses:

Alt
-
Step 2: The login information is incorrect, and the student
is prompted
to reenter the correct login information.

Conclusion:

The use
-
case concludes when the quiz is
built.

Postcondition:

The quiz is
active in the system.

Business Rules:

If a quiz is
needed, an administrator can build
a quiz.

Implementation Con
straints and
Specifications:

None specified.

Assumptions:

The
re are questions in the question bank to build a quiz with.

Open Issues:

None.


Use
-
Case Name:

Post a Quiz


Use
-
Case ID:

PostQuiz

Priority:

High

Primary Business Actor:

Administrator

Other Participating Actors:

Web Server (External Server)

Other Interested Stakeholders:

Instructor
-

May initiate a quiz posting

Student
-

Needs a quiz to be posted before a quiz can be taken

Description:

This use case describes how an administrator
posts

quizzes.

Precondition:

The quiz
must be made available.

Trigger:

The instructor must request that a quiz be
posted

or an administrator must
choose to
post

a quiz.

Typical Course of Events:

Actor Action

System Response

Step 1: The administrator is
authenticated into the system.

Step 3: The system administrator
chooses to
post

a quiz.

Step 5: The administrator selects a
quiz to
post
.


Step 2: The system administrator a
choice of actions to take.

Step 4: The system prompts the
administrator to select
which quiz to
post
.

Step 6: The system verifies the quiz
posting
.

Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



9

Alternate Courses:

Alt
-
Step 2: The login information is incorrect, and the student is prompted
to reenter the correct login information.

Conclusion:

The use
-
case concludes when the quiz is
activated
.

Postcondition:

The quiz is
available to take in

the system.

Business Rules:

If a quiz is
needs to be available
, an administrator can
activate

a quiz.

Implementation Constraints and
Specifications:

None
specified.

Assumptions:

The quiz to be
activated already exists.

Open Issues:

None.


Use
-
Case Name:

Submit Quiz Question


Use
-
Case ID:

SubmitQuestion

Priority:

High

Primary Business Actor:

Administrator

Other Participating Actors:

Web Server
(External Server)

Other Interested Stakeholders:

Instructor
-

May initiate a quiz question submission

Description:

This use case describes how an administrator submits quiz questions.

Precondition:

The quiz questions must need to be added to the system.

Trigger:

The instructor must request that a quiz question be added or an
administrator must choose to add a quiz question.

Typical Course of Events:

Actor Action

System Response

Step 1: The administrator is
authenticated into the system.

Step 3: The
system administrator
chooses to submit a quiz question.

Step 5: The administrator enters in
question and answer text, selects a
correct answer.

Step 6: The administrator verifies
the submission.


Step 2: The system administrator a
choice of actions to take
.

Step 4: The system prompts the
administrator to enter in question
and answer text, and select a
correct answer.

Step 7
: The system verifies the quiz
question submission
.

Alternate Courses:

Alt
-
Step 2: The login information is incorrect, and the student
is prompted
to reenter the correct login information.

Alt
-
Step 7: The system prompts the user to correct an illegal data flow.

Conclusion:

The use
-
case con
cludes when the quiz question is added.

Postcondition:

The quiz
question is in the question bank.

Business Rules:

If a quiz
question needs to be added
, an administrator can
add a question.

Implementation Constraints and
Specifications:

None specified.

Assumptions:

None.

Open Issues:

None.


Use
-
Case Name:

Automatically Remove Quiz


Use
-
Case ID:

AutomaticallyRemoveQuiz

Priority:

Low

Primary Business Actor:

Time

Other Participating Actors:

Web Server (External Server)

Other Interested Stakeholders:

Instructor
-

May specify what day a quiz is to be removed

Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



10

Description:

This use case describes

how time automatically removes quizzes.

Precondition:

The quiz must already be posted.

The quiz must need to be removed.

Trigger:

A point in time must elapse.

Typical Course of Events:

Actor Action

System Response

Step 1: A specified point in time
elapses
.


Step 2: A quiz is deactivated.

Alternate Courses:

None.

Conclusion:

The use
-
case concludes when the quiz is removed.

Postcondition:

The quiz is no longer active in the system.

Business Rules:

A due date can be set, and a quiz is automatically

removed after that date.

Implementation Constraints and
Specifications:

None specified.

Assumptions:

The quiz to be removed already exists.

Open Issues:

None.


Use
-
Case Name:

Generate Grade Report


Use
-
Case ID:

GradeReport

Priority:

Medium

Primary Business Actor:

Instructor

Other Participating Actors:

Web Server (External Server)

Other Interested Stakeholders:

Student
-

Interested in their grade

Description:

This use case describes how an instructor generates grade reports.

Precondition:

There must be graded submission
s

to report.

Trigger:

The instructor must request that a quiz be removed or an administrator
must choose to remove a quiz.

Typical Course of Events:

Actor Action

System Response

Step 1: The
instructor

is
authenticated into the system.

Step 3: The instructor
chooses to
generate a grade report.

Step 5: The administrator selects a
quiz to
report
.


Step 2: The system
gives the
instructor

a choice of actions to
take.

Step 4: The system prompts the
instructor

to select which quiz to
report
.

Step 6: The system
displays the
grade report.

Alternate Courses:

Alt
-
Step 2: The login information is incorrect, and the student is prompted
to reenter the correct login information.

Alt
-
Step 6: The system inform
s the instructor that no grades currently exist
for that quiz
.

Conclusion:

The use
-
case concludes when the
report

is
generated
.

Postcondition:

The
report is displayed.

Business Rules:

An instructor views a grade report by generating it in the system.

Implementation Constraints and
Specifications:

None specified.

Assumptions:

The quiz to be report
ed

on

already exists.

Open Issues:

None.


Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



11

I
/O ANALYSIS

Inputs

Outputs

User ID

Student Grade

Password

Student ID

Quiz Selection

Course Section

Answer
Submission

Quiz Question

Class Selection

Administrator Name

Section S
election

Quiz Text

Answer Text

Quiz Text

Answer Text

USER INTERFACE ANALY
SIS



Figure
1
-

User Login

Figure
2
-

Student Quiz
Selection

Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



12





Figure
3
-

Student Quiz

Figure
4
-

Student Quiz Submission

Figure
5
-

Administrator Maintenance

Figure
6
-

Quiz Builder

Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



13



PROCESSING ANALYSIS

CONTEXT DIAGRAM


The system needs to interact with students, instructors, and administrators.
These

ar
e the
data flows in and out of
the system
.



Figure
7
-

Instructor Maintenance

Figure
8
-

Instructor Grade Viewer

Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



14

LEVEL
-
0 DATA FLOWS


The quiz system breaks down into a student
sub
system that handles

student data flows, and a faculty subsystem
that combines instructor and administrator data flows.



Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



15


FUNCTIONAL DECOMPOSI
TION DIA
GRAM



This diagram identifies each of the tasks the two subsystems must accomplish. The Faculty subsystem is further
broken down into its main functions
-

quiz maintenance, user maintenance, and grade generation.



Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



16

DATA FLOW DIAGRAM


This diagram identif
ies which actors initiate which processes, and how those processes interact with data stores.

PROCESS DESCRIPTIONS

Submits a Quiz

A student calls up a quiz and submits answers, which are verified and graded
.
The grade is stored in the data store quiz.

Builds/Modifies Quiz

A person with rank 3 (administrator) adds a quiz to the quiz data store, or
modifies a quiz currently in the quiz data store.

Manually Removes a Quiz

A person with rank 3 (administrator) deactivates a quiz that

is

stored in the
quiz d
ata store.

Automatically Removes a Quiz

A point in time deactivates a quiz that is stored in the quiz data store.

Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



17

Posts a Quiz

A person with rank 3 (administrator) activates a quiz that is stored in the quiz
data store.

Submits a Quiz

Question

A person
with rank 3 (administrator) enters a question in the question bank
data store.

Adds a New User

A person with rank 3 (administrator) adds a user to the person data store.

Removes a User

A person with rank 3 (administrator) removes a users from the person
data
store.

Generate a Grade Report

A person with rank 2 (instructor) or rank 3 (administrator) requests and
generates a report on all the stored grades for a quiz from the quiz data store.


DATA STRUCTURES

Submit a Quiz

1. If
a STUDENT requests to
submit a QUIZ

a. Store GRADE in the date store QUIZ

b. Verify submission to STUDENT


Build/Modify Quiz

1. If FACULTY

is R
ANK

3 and requests to Build or Modify QUIZ

a. Update
QUIZ

in the date store
QUIZ


Automatically Remove a Quiz

1. If
the DEADLINE for a
QUIZ expires

a. Deactivate
QUIZ

in the date store
QUIZ


Manually Remove a Quiz

1. If
FACULTY is
RANK

3 and requests to manually remove a QUIZ

a. Deactivate
QUIZ

in the date store
QUIZ


Post a Quiz

1. If
FACULTY is R
ANK

3 and requests to post a QUIZ

a.
Activat
e QUIZ in the date store QUIZ


Submit a Quiz Question

1
. If FACULTY is
RANK

3 and requests to submit a
QUESTION

a. Update
QUESTION in the date store QUESTION


Set up a New User

1. If
FACULTY is RANK 3 and requests to add a PERSON

a. Add a new user i
n the date store PERSON

b. Assign them a RANK


Remove a User

1. If
FACULTY is RANK 3 and

requests
to remove a PERSON

a. Remove
PERSON from the date store PERSON


Generate a Grade Report

Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



18

1. If FACULTY is RANK 2 or 3

and
requests
to generate a GRADE

r
eport

a. Request
GRADE

Report from data store
QUIZ

b. GRADE report is displayed to FACULTY


DATABASE ANALYSIS

ENTITY
-
RELATIONSHIP DIAGRAM


“Student” and “Faculty” both inherit most of their attributes from the “Person” supertype.
A “Student” is enrolled

in

a “Course”
, and may be taking more than one (Stu_Course is an associating table).
Each person has a
RANK
.

Rank
1



Partial Access



Granted to Student



Allows for access to quiz system to take quiz

Rank
2



Partial Access



Granted to Faculty



Allows a faculty us
er to access quiz grades and to view quizzes for courses taught

Rank 3



Full access



Granted to Administrators



Allows administrators to create and organize quiz's, along with questions and respective
Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



19

answers. An administrator can also make adjustments to
the quiz system, as one sees fit
(Faculty can also possess the role of an administrator)


Many students can submit many quizzes, but they only receive one grade per quiz submission. That grade is stored
in
the associating table “Stu_Quiz


in the S_GRADE attribute.

Quizzes are stored in “Quiz.” Each quiz is “owned” by
a faculty member. Currently, this is simply another identification for each quiz, but it leaves quizzes open to future
functionality (such as exclusive editing rights or sorti
ng quizzes by owner).
If the ACTIVE attribute in “Quiz”
is TRUE,
then a quiz is available to be taken. If the ACTIVE attribute is FALSE, the quiz may not be taken.
Quizzes are
comprised of questions (which are stored in “Question_Bank”), and many quizzes c
an contain many questions
(associated with “Quiz_Quest”). Structuring questions as separate from the quizzes makes it easy to reuse
questions for reviews, exams, or other courses they may be applicable to.

EXAMPLE DATA TABLES


Person

P_ID

FIRST

LAST

EMAIL

LOGIN

PASSWORD

RANK

S12

Amschel

Rothschild

arothsch1@mscd.edu

arothsch1

bullion1000

1

F3

Snoop

Dogg

sdogg213@mscd.edu

sdogg213

FOshizzel01

2

A1

Peter

Griffen

pgriffen68@mscd.edu

pgriffen68

HAPPYHolloween2006

3


Student

P_ID

1


Faculty

P_ID

2

3


Quiz_Quest

Q_ID

QUEST_ID

SORT_NUMBER

Q1

1

1

Q1

34

2


Course

C_
CRN

C_
COURSE

C_SEC

234
-
22

CIS2110

01

432
-
23

CIS2110

02

765
-
23

CIS3050

01




Quiz

Q_ID

Q_NAME

P_ID

ACTIVE

Q1

Quiz1_Ch1

A1

FALSE

Q2

Quiz2_Ch2

A1

FALSE

Q3

Quiz3_Ch3

A1

FALSE

Q4

Quiz4_Ch4

A1

TRUE

Q5

Quiz5_MidTermReview

A1

TRUE

Q6

Quiz6_Ch5

A1

FALSE

Q7

Quiz7_Ch6

A1

FALSE

Q8

Quiz8_Ch7

A1

FALSE

Q9

Quiz9_Ch8

A1

FALSE


Stu_Quiz

S_ID

Q_ID

GRADE

1

Q2

.72

1

Q3

.95


Stu_Course

P_ID

C_CRN

1

234
-
22

Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



20


Question_Bank

QUEST_ID

COR_ANS

STU_ANS

QUEST_TXT

A1_TXT

A2_TXT

A3_TXT

A4_TXT

A5_TXT

1

A

A

Which of
these is a CIS
course?

Systems
Analysis

Calculus

English

Ethics

French

2

B

A

Which is the
following is
blue?

Red

Blue

Green

Purple

Mauve

34

C

A

What state is
Denver in?

Delaware

Nevada

Colorado

Texas

Maine




Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



21




R
ECOMMENDED IMPLEMENT
ATION


Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



22

DEVELOPMENT STRATEGY

A new application can be developed
that replaces all of the functionality of the existing system while addressing its
limitations. By having a strong GUI for the system,

it will be easier to administer. Once the system is built, it will no
longer rely on knowledge of a particular coding language to administer. It will simple enough that it won’t require
extensive training to use.

In order for the quiz system to operate wi
th the content in database tables, the programming language Perl
should

be used. An object
-
oriented approach with Perl will organize each table (or in programming, the noun subject or
object)
.

Perl will be used to define methods or actions to use the conte
nt or attributes in the tables for user
interaction to occ
ur, such as a student accessing

and submitting a quiz.

The Perl language will also be used with XML language to encapsulate the database tables for use via an internet
browser. For a user to view co
ntent of the quiz system in an internet browser, a Graphic User Interface (GUI) must
be used in sufficing the intuitive ability for a user to comprehend the layout of a quiz and its content. This GUI must
display a logging in screen for users, the quiz for

students and faculty, grades for faculty, and an interface for
administrators to create, add, or edit quizzes and questions.

Rapid application development (RAD) should be used to draft quick prototypes of the application and modifying
them based on user i
nput from trial runs. Once a satisfactory application has been developed, a big
-
bang rollout
can be performed during a new semester.

Step 1

Assign people to project subteams
:

Representative T
eam

-

Consists of the team leaders of each individual task team

P
rogramming Team

-

Create
progra
m
ming code and make sure current code is compatible with

shell

Web Design T
eam
-

C
reate user interface and help with integration of the code and database

structure

Data Team

-

C
onstructs database model and hardware model for
system use


Each
sub
team create
s

an
individual schedule
. The representative

team meets and build
a
master schedule based

on the
individual team schedule
s.


Step 2

• Programming team creates additional classes for the quiz system and
manages
the

i
ntegration

of the current P
erl
code file and shell occurs.

• Data team
collects data,
integrate
s

hardware
,

and design
s

the data model

• Representative meeting


Step 3

• Web design team create
s

user interfaces


Web design team w
ork
s

with programming team for code in
tegration


Web design team w
ork
s

with data team for data and hardware integration

• Representative meeting


Step 4

Represe
ntative team tests

sy
stem functionality, debugs

any errors
, makes improvements consistent with a Rapid
Application Development (RAD)
strategy.



Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



23

FEASIBILITY ANALYSIS

Operational Feasibility

Performance
-

The system is small and agile, there should be no noticeable processing
time.

Information
-

Users can get all the information they need from the system.

Economy
-

This system will decrease

the time spent administering

the quiz system.

Control
-

This system will be as secure as the current system.

Efficiency
-

This system is easy enough that more people that would be classified as
instructors in the current system could also be classified as a
dministrators in the
proposed system.

Services
-

The GUI makes the system more straightforward to use. No reliability issues
are anticipated.

Cultural Feasibility

The current managers are unhappy with the st
r
ain that the current system places on
them. The
new system makes it feasible to have more administrators, thus relieving the
strain on the existing administrators.


The students shouldn’t notice a substantial difference between the systems, aside from
a slightly more attractive interface.


The current i
nstructors will have an easier means of accessing the grades they need.
However, since it’s feasible for more instructors to become administrators, some of
them may be resistant to the extra responsibilities. Others may enjoy having more
freedom with their

quizzes

Technical Feasibility

Since the system uses web browsers to implement, it is technically practical for all

actors.
The system can be implemented on the ROWDY servers that the department
currently has access too. The system requires no special ex
pertise to operate, although
some expertise will be required to code it.

Economic Feasibility

The only possible fixed costs involved with the system would be paying for people to
write the code. It is possible that faculty would be willing to write the
code for free, or
students would be willing to work on it as a project. There are no variable costs
associated with this system
-

since it operates on the ROWDY servers, the department
does not pay anything for each use of the system. The tangible benefits
will mostly be in
time savings for the current administrators, as well as a simplified process for activities.
The intangible b
enefits

would be increased system involvement among faculty
members and decreased workload on the current administrators.

Schedu
le Feasibility

No deadline was set for a rollout. Deployment is estimated at one person
-
month.

Legal Feasibility

No foreseeable issues.



Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



24




APPENDIX



Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



25

REVISED PROJECT PLAN


QUESTIONNAIRES

INTER
VEIW WITH DR. CHARLE
S MAWHINNEY

11/03/10

Why wasn't a COTS
solution used, specifically Blackboard?

1. Didn't start with Blackboard

2. Fundamental flaw is: Multiple sections, each thing must be entered manually

3. Fights the culture

4. Helps consistency

Uploading a file is possible in Blackboard.

How is data stored

in a database?

No, it's a file based system.

Differences between systems

More secure (didn't publish textbank stuff)

Didn't want to learn unix quiz
-
kill commands

Want something that auto
-
fills student stuff

Different codes are diverging

What are biggest c
omplaints?

Mostly administrative

Needing to do everything manually

Alphabetizing student names, for example

There is no common place to run each system

What are your biggest complaints with the system?


As Administrator: Need to have extensive knowledge of

the system. Too much manual input to set up the system.
Have to convert files Dos2Unix.

As Instructor: Would like system to display student names alphabetically

no student names in this version of the
system.

Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



26

Why are their two different quiz systems in pl
ace?

They started as one system and then due to creative differences between the quiz administrators the systems
evolved to what they are currently.

What exactly does the quiz administrator see or do when performing their job?

The adminis
trato
r when
dealing with the quiz system only deals with files which they upload through a secure FTP
program. No GUI is currently being used.

When the instructor logs in to get the student results can they see any of the quiz results?

Yes, the instructor after they l
og in can choose which quiz results they would like to see then they are given the
result of all of their students for that particular quiz.

INTERVIEW WITH ANNET
TE LEGE

11/10/10

What features would you like to have in the quiz system?

Some way of making
sure student quiz submissions end up in the right section.

What is a typical instructor interaction with the system?

At the beginning of a semester, the administrator asks for a list of student IDs and names. Administrators get a
password. They retrieve da
ta after things are submitted.

What are the biggest problems with the current system?

Lack of a visual interface.

What are the issues with Blackboard?

Interface is designed for non
-
experts, most of the things that make it feasible are very recent changes,
instructor
has fewer controls.

Would it be possible to switch to an object
-
oriented language to help support a GUI solution?

Yes.

What would you like to add or take away from the system?

I'm trying to figure out how to add a feature so the students end up
in the right section. Take 2010 for example,
some students may select the wrong section from a pull down menu. I would like to come up with some way to get
all students in the right section because I sort results by section. Some students pick the wrong in
structor.

How do you associate username with login name?

Select the section first and then the real name; 900 number; username can be listed. The login process uses a korn
shell script to search through a text file that contains userids associated with rea
l names.

Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



27

What interaction does a typical instructor have with the system?

Sends admin the student roster for the semester for each section

Gives personal instructor password to the admin

Logs in after the quiz deadline to retrieve the results (displayed on

a page individualized for each instructor)

Transcribes the results into a gradebook

(Assumption, not stated: Posts the gradebook somewhere online)

What tasks do you accomplish as the admin?

The admin posts the quizzes. Some person (currently Lege in 2110
and Fustos in 2010) is responsible for writing
the quizzes (they are sent to the admin as straight hmtl). In addition, the admin has to set up the system at the
beginning of each semester so that students and instructors can access it.

Do you see any major

or recurring problems from the instructor’s point of view?

None from the instructors. However, lack of interface for the admin makes the system more difficult to set up each
semester. A GUI to guide admins through the process would be beneficial.

What dra
wbacks from Blackboard have kept you from switching to that system?

When I was trained on the system I understood that each student would take a different quiz resulting from a
unique combination of questions from a test bank. I wanted them to take the sam
e quiz so we could review it
together in class, if needed.

Does the quiz system automatically send an email, grade the quiz and post the grades in the grade book after a
quiz is closed?

Yes,Yes and No.

What areas of the quiz system do you feel could and/or

should be automated?

Professor Lege has automated the posting of the solutions. She has also automated the removal of the quiz at a
certain time.

How is the time to take down a quiz set? In a data file?

Quiz take down time is scheduled in Linux scheduler,

as well as the time to post the quiz answers.

Do other people in the department know how to administer the quiz system?

Fustos, maybe. Mostly, no one else has the necessary skill set to administer the system, i.e. PERL.

What exactly does the quiz
administrator see or do when performing their job?

The administrator

when dealing with the quiz system only deals with files which they upload through a secure FTP
program. No GUI is currently being used.


Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



28

When the instructor logs in to get the student res
ults can they see any of the quiz results?

Yes, the instructor after they log in can choose which quiz results they would like to see then they are given the
result of all of their students for that particular quiz.

JOURNAL

Kyle Coberly (Project Manager):
Logical design, diagrams, writing, website maintenance

Jacob Kennedy: Database description, problem analysis matrix, GUI graphics, development strategy,
PowerPoint

Dustin Rotunda: Code analysis, process descriptions, GUI design, information systems service

request

Elliott Chhem: Code analysis, Gannt chart, diagrams, feasibility
, vent server

MEETING NOTES

INTRODUCTORY EMAIL
10/31/10 (
EMAIL F
ROM KYLE COBERLY TO
GROUP)

Hey all!


So here's the stats on our group / summary of our first meeting:

Kyle Coberly

/
kyle.coberly@gmail.com

/ 720.257.4330

Strengths: Databases, logical diagrams, writing

Weaknesses: Coding


Jacob Kennedy

/
jkenne33@mscd.edu

/ 303.2
56.8965

Strengths: Creativity, speaking, code

Weaknesses: Writing


Dustin Rotunda

/
drotunda@mscd.edu

/ 303.547.0553

Strengths: Code

Weaknesses: Writing


Elliott Chhem

/
echhem@mscd.edu

/ 720.427.6328

Strengths: Creativity, code, graphics

Weaknesses: Writing


Deliverables for Monday:

1.

3 questions for interviews. Might be a good idea to have some potential follow
-
up questions also.

2.

Does anyone have ex
perience with online project management software? If I have a server we can install it on,
but I've never used any of that stuff before. I was thinking that might be a good thing not just for coordination, but
also make this project a cooler portfolio piec
e. We can does something simple and HTML
-
y if we have to, but I
figured I'd ask first if anyone had ever used anything else.

3.
Look over the project requirements, and let's chat about some scheduling stuff.

Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



29


It's gonna be a great project
-

see you guys Mon
day!

WEBSITE BUILT 11/3/1
0

goteamawesome.wikidot.com

After reviewing different collaborative project management software, Dustin suggested that we use a Wiki. On the
night of 11/3/10, Dustin, Elliott, and Kyle worked on the building the initial website fra
mework.

TENTATIVE SCHEDULE
11/4/10
(
EMAIL F
ROM KYLE COBERLY TO
GROUP)

Working backward from the due date...


Written Presentation final draft (must complete by 12/9), duration 3 days, requires written presentation working
draft, all team members

Formal
Presentation final draft (with aids) (must complete by 12/6), duration 2 days, requires written presentation
working draft, Jacob

Written Presentation working draft, duration 5 days, all team members, requires all decision analysis completed
work completed
, Kyle

Decision Analysis (feasibility, costs/benefits, candidate solutions), duration 5 days, requires all logical design
completed, Dustin

Logical Design (context diagram, use case diagram/narrative, data flow diagram, functional decomposition
diagram, da
ta model), duration 7 days, Kyle

Problem Analysis (problem statement, improvement objectives, Identify business requirements), must complete
by 11/9, duration 5 days, Elliott


Elliott can throw this into a Gantt chart
-

can you also throw this in a table wi
th the individual components of each
of these phases? What I'm thinking is that we'll all help with each of the phases, but if each of us kind of "heads
up" a phase and can be familiar enough with what will need to be delegated out.


Can y'all plan on emai
ling me documents for this stuff by say, Friday night? I always like to plan a little buffer time
in so that we don't get caught with crashed computers or emergency room visits on Sunday night. I'll also post up
the assembled 2A thing up on the website so
we can all check it out and make any adjustments we need to.


Thanks!


-
Kyle


PROJECT UPDATE 11/27
/10 (
EMAIL F
ROM KYLE COBERLY TO
GROUP)

Hey gang,


Hope everyone had a great break! The deadline is closing in on this project, but we're closer to being done
than
Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



30

you might think. There's some new diagrams up (including a re
-
thought ERD) on the wiki
(
goteamawesome.wikidot.com
) under the "Phase B" section. We've got a week and change before we have to
do
the presentation, and 2 days later the written section is due. Here's what needs to get done:


Jacob:

-
Database analysis. Work from the ERD and build up some mock tables, and write a narrative of how the data is
stored. The only thing I really changed w
as combining students and faculty into the same table
-

they'll be
differentiated under the "role" attribute (student, instructor, administrator). Think of some supporting business
rules too (person must have the role of administrator to own a quiz, etc.)

-
Figure out a development strategy for us to use, and outline how it would apply to our specific project. I can clean
up the language, formatting etc., just get me the meat and potatoes.

-
Start thinking about what our presentation will be, powerpoint slides
, etc.


Elliott:

-
Great work on the diagrams! All you have left is to outline our feasibility analysis. I'm not sure we can answer all
six feasibility issues now, but fill in what you can and identify what we still need to figure out.


Dustin:

-
I/O and UI
stuff. The I/O should be pretty easy
-

just identify what our inputs and outputs are. Put some serious
thought into what a good UI for this would look like though
-

that was Lege's big thing on why it's so hard to
administer. Think about what each screen tha
t an instructor, administrator, or student might see, and where form
boxes, buttons, etc. would go.

-
This will depend on some of the feasibility stuff, but start getting an idea of what an implementation of all of this
would look like (phases, etc.)


Kyle:

-
Finish up the use
-
case models and narratives

-
Write the overall logical design narrative

-
Layout our written presentation


That's everything we have left to do! It would be awesome if we could have all of the underlined stuff done by
Monday. I know it's
a lot for a short period of time, but if we'll be basically back on schedule if we get that stuff
knocked out. Email or call (720.257.4330) if you have any questions.

IN
-
CLASS MEETING 12/1/1
0

Discussed final details of the project, selected first slot on
the first presentation day. Decided on business casual
for attire. Discussed feasibility of using new Perl functions.



Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



31

DOCUMENTS COLLECTED

IS SERVICE REQUEST

REQUESTED BY:

Team Alpha


DATE:

N
OVEMBER
4,

2010

DEPARTMENT:

Computer Information Systems



LOCATION:


Metropolitan State College of Denver



CONTACT:


Kyle Coberly, 720.257.4330




kyle.coberly@gmail.com

http://goteamawesome.wikidot.com





TYPE OF REQUEST:

URGENCY:


[ ] New System


[ ] Immediate

佰敲慴楯ns 慲攠imp慩a敤 or oppor瑵n楴y 汯st


[x] Sys瑥m Enhan捥ment


[x] Prob汥ls ex楳琠tu琠t慮 b攠work敤 慲ound


[ ] 卹s瑥m Error Corr散瑩tn


[ ] Bus楮敳s 汯sses 捡n b攠瑯汥l慴敤 un瑩氠new sys瑥m ins瑡t汥l

PROBLEM STATEMENT

The online quiz system is used for different courses in the CIS program. It has
been in use for approximately ten years, and many undocumented modifications
have been made over time. There are at least two different versions of this system
in presently in
use. Many of the system processes are automated, but some require
manual entry and special technical expertise to perform. Several requests have
been made to improve the system and to make it less dependent on the two
individuals who serve as system admini
strators for the system.


PROPOSED SOLUTION

We
intend

to take the two
existing
systems and combine them into one

to help
streamline the

p
rocesses the department uses. This will allow for a more rapid

implemen
tation of new material and modification

of old m
aterial
. This will also
reduce

redundancy
within the system and make it more secure
.
T
his system
enhanc
e
ment will lead to a better user,
instructor,

and administrator experience by
delivering better quality control and shared services over the network.


IS

LIAISON:

Dr. Charles Mawhinney


X









SPONSOR:

Dr. Abel Moreno



X














-

-

-

-

-

-

-

-

-

-

-

-

-

TO BE COMPLETED BY SYSTEMS PRIORITY BOARD
-

-

-

-

-

-

-

-

-

-

-

-

-

-


[ ] Request Approved


Assigned to:














Start date:









[
] Recommend Revision

[ ] Suggest User Development

[ ] Reject for reason:











Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



32

PROBLEM ANALYSIS MA
TRIX

Project:


Quiz System (Team Alpha)


Project Manager:

Kyle Coberly

Created by:


Team Alpha

Last Updated by:

Jacob Kennedy

Date Created:

11/3/10

Date Last Updated:

11/8/10


CAUSE AND EFFECT ANALYSIS

SYSTEM IMPROVEMENT OBJECTIVES

PROPOSED SOLUTION

Problem (Identify as B,O,D)*

Causes and Effects

System Objective

System Constraint

1. There are two versions of the
system
-
D













2. Some processes aren't automated
and require manual work requiring
special technical expertise
-

D
-
B



1.


This quiz system is
used for both upper
-
level, and lower
-
level
courses. The system is
designed with two
versions administered
by two instructors in
charge. One instructor
administers over lowe
r
-
level courses and the
other over upper
-
level
courses. The effect of
this occurrence causes
instances of automated
procedures and/ or
manual procedures in
the system via the
discretion of the
administrator.

2.

With having a system
that possesses some
automa
ted and/or
manual processes,
1.

To allow ease of access
and maintenance by
administrators.

2.

To allow ease of access
to student to take the
quiz and receive graded
score.

3.

To properly receive,
store, and protect
graded quiz data

4.

To provide graded quiz
information to the
student in a timely
manner



1.

Is used even when
the system is less
efficient and
effective than other
alternatives. ( A
major opportunity
cost)


1.

Combine both

quiz system versions
together

2.

Make a single quiz system that can
possess procedures that occur
automatically, if needed (can
change procedure settings from
manual to automated)

3.

Allow access to quiz system by a
student with custom password
creation
and
default Metro
-
connect
user name

4.

Use database tables to store
student, instructor, and quiz
information (can store all quizzes
for all sections and can be easily
updated)

5.

Upgrade system coding to be
object
-
oriented (Java or VB) with
the use of XML

6.

Make the

visual presence of the
system be aesthetically pleasing
(make the visual appearance of the
Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



33




3. The
system is very dependent on its
two administrators
-
D
-
O








error in quiz
administrating, grading,
and data storing may
occur

3.

With system activity
relying heavily upon
two administrators for
two system versions, if
an unexpected or
unforeseen occurrence
(physical accident,
health issue
) happens,
further system
administering by
another instructor may
not occur in an easy
transition

quiz system help with ease in
intuitively navigating the system via
system users
-

students)

7.











* B = Bug, O = Opportunity, D = Directive


Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



34

ORIGINAL CODE

QUIZ LOGIN SCRIPT

#!/usr/local/bin/perl


print "Content
-
type: text/html", "
\
n
\
n";


############################################################

# quizLogin.pl #

# by C. H. Mawhinney, 8/18/05

#

# Copyright 2005, all rights reserved. #

# This program checks student userid and password against #

# a password master file. It then calls the quiz #

# menu page.

#

# #

############################################################



require "cgi
-
lib.pl";


&ReadParse(*in);

&PrintHeader;


#######

# Init

#######

$thismonth = (January, February, March, Ap
ril, May, June, July, August,


September, October, November, December)[(localtime)[4]];

$thisday = (localtime)[3];

$thisyear = (localtime)[5];


$userid


=

$in{'userid'};

$password

=

$in{'password'};

$course

=

$in{'course'};

$instructor

=

$in{'instructor'};

$idfile


=

'/user6/mc/mawhinnc/pwz/' . $course . $instructor . '.pwf';

$redopage

=

'/user6/mc/mawhinnc/pwz/quizRedo.htm';

$nextpage

=

'/user6/mc/mawhinnc/pwz/' . $course . 'QuizMenu.htm';


########

# main #

########


&void_entry;

&read_i
dfile;

&check_entry;

&next_page;


########################

# Check for void entry #

########################

Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



35

sub void_entry {


if ($userid eq "") {



&redo;



exit;




}



if ($password eq "") {



&redo;



exit;


}

}


#################################

#
Open password file into array #

#################################

sub read_idfile {


open(PWORDS,$idfile) || die "Cannot open $idfile for reading";


@pwf = <PWORDS>;


close(PWORDS);


for($i = 0; $i < (@pwf); $i++) {



chomp($pwf[$i]);


}

}


###############
##############

# Check for userid/password #

#############################

sub check_entry {


if ($password ne $pwf[0]) {



&redo;



exit;


}


$flag = "f";


for($i = 1; $i < (@pwf); $i++) {



if ($userid eq $pwf[$i]){




$flag = "t";



}


}


if ($flag eq
"f") {



&redo;



exit;


}

}


#####################################################

# Call next page
--

inserts userid & faculty fields #

#####################################################

sub next_page {


$tokenline1 = '<INPUT TYPE=hidden NAME=userid V
ALUE= "' . $userid . '">' . "
\
n";


$tokenline2 = '<INPUT TYPE=hidden NAME=instructor VALUE= "' . $instructor . '">' . "
\
n";


$tokenline = $tokenline1 . $tokenline2;


$now_secs = time;


$now = localtime($now_secs);

Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



36


$nowline = '<CENTER>Student ' . $userid .

' logged in to WEPS: ' . $now . '</CENTER>' . "
\
n";



open(NEXTPAGE,$nextpage) || die "Cannot open $nextpage for reading";


@np = <NEXTPAGE>;


close(NEXTPAGE);



$hr = 0;


for($i = 0; $i < (@np); $i++){



if ((index($np[$i], '<HR>') !=
-
1)&& ($hr == 0)){




splice(@np, ($i+1), 0, $nowline);




$hr = 1;



}



if (index($np[$i], 'METHOD=POST>') !=
-
1){




splice(@np, ($i+1), 0, $tokenline);



}


}


for($i = 0; $i < (@np); $i++){



print $np[$i];


}

}


##############

# Redo Login #

##############

sub redo {


open(REDOPAGE,$redopage) || die "cannot open $redopage for reading";


while (<REDOPAGE>) {



print $_;


}


close(REDOPAGE);

}


EXAMPLE PASSWORD FIL
E (.PWF)

cis3050demof10

mawhinnc

bghosh

1Ansrkey

userid1

userid2

userid3

userid4

userid5


LOGIN PAGE

<
HTML
>

<
!
--
This file created 10:51 AM 11/3/2010 by Claris Home Page version 3.0
--
>

<
HEAD
>


<
TITLE
>CIS 3050 Quiz Menu</
TITLE
>

Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



37


<
META

NAME
=
GENERATOR
CONTENT
=
"Claris Home Page 3.0"
>


<
X
-
CLARIS
-
WINDOW

TOP
=
0
BOTTOM
=
845
LEFT
=
0
RIGHT
=
1112
>


<
X
-
CLARIS
-
TAGVIEW

MOD
E
=
minimal
>

</
HEAD
>

<
BODY

BGCOLOR
=
"#FFFFFF"
>

<
P
><
TABLE

BORDER
=
0
>


<
TR
>


<
TD

WIDTH
=
423
>


<
CENTER
><
IMG

SRC
="
http://clem.mscd.edu/~mawhinnc/wepshead.jpg
"
ALT
=
"MSCD WEPS We
b Exam
Presentation System"
X
-
CLARIS
-
USEIMAGEWIDTH X
-
CLARIS
-
USEIMAGEHEIGHT ALIGN
=
bottom
></
CENTER
>


</
TD
>


</
TR
>


<
TR
>


<
TD

WIDTH
=
423
>


<
H2
><
CENTER
><
BR
>


CIS 3050 Demo Quiz Menu</
CENTER
></
H2
>




<
CENTER
>(Revised

11/3/10)




<
P
>




<
HR
>




</
P
></
CENTER
>


</
TD
>


</
TR
>


<
TR
>


<
TD

WIDTH
=
423
>


<
CENTER
><
TABLE

BORDER
=
0
>


<
TR
>


<
TD

ALIGN
=
right
>


<
P
></
P
>


</
TD
>


</
TR
>


<
TR
>


<
TD

ALIGN
=
right
>


<
CENTER
><
A

HREF
="
http://rowdy.mscd.edu/~mawhinnc/cis3050/
10f/homework/hwans.htm
"><
IMG

SRC
="
http://rowdy.mscd.edu/~mawhinnc/cis3050/10f/buttons/l
-
arw4s.gif
"
X
-
CLARIS
-
USEIMAGEWIDTH X
-
CLARIS
-
USEIMAGEHEIGHT ALIGN
=
bottom
>


<
B
>Homework</
B
> <
B
>Answers</
B
></
A
><
IMG

SRC
="
http://rowdy.mscd.edu/~mawhinnc/cis3050/10f/buttons/new.gif
"
X
-
CLARIS
-
USEIMAGEWIDTH X
-
CLARIS
-
USEIMAGEHEI
GHT ALIGN
=
bottom
></
CENTER
>


</
TD
>


</
TR
>


<
TR
>


<
TD

ALIGN
=
right
>


<
P
></
P
>


</
TD
>


</
TR
>


<
TR
>


<
TD

ALIGN
=
right
>


<
CENTER
><
FORM

ACTION
=
"http://rowdy.mscd.edu/cgi
-
bin/cgiwrap/~mawhinnc/getQuizFrame.pl"
METHOD
=
POST
>

Quiz System Feasibility Study
-

Team Alpha

http://goteamawesome.wikidot.com



38


<
P
><
INPUT

TYPE
=
hidden
NAME
=
course
VALUE
=
cis3050demo
><
TABLE

BORDER
=
1
>


<
TR
>


<
TD

COLSPAN
=
3
>


<
CENTER
><
FONT

SIZE
=
"+2"
><
B
>Select


Quiz</
B
></
FONT
></
CENTER
>


</
TD
>


<
TD
>


<
P
></
P
>


</
TD
>



</
TR
>
<!
--



<TR BGCOLOR="#FFFFFF">



<TD VALIGN=bottom COLSPAN=4 BGCOLOR="#FF99FF">



<CENTER>&nbsp;<FONT COLOR="#000066"><B>Your




best 11 of the following 12 quizzes



will be counted.<BR>



Quiz #13 is a "bonus quiz" whose value



was discussed in



class.</B></
FONT></CENTER>



</TD>



</TR>