quiz system
TRANSCRIPT
System SpecificationIntroduction The quiz system comprises of set of questions and choices for each courses that is specified by the respective teacher to which the student can attend to it within the time limit and the reports are generated.
Goals and objectives One of the main goals of the system is automated marking, that is, teachers do not need to check the answer script as they do in manual quiz. It saves valuable time of a teacher. On the other hand, students can score according to his/her merit level and it will give feedback about a student in which course he/she is weak.
System statement of scope Any University,College or School can adopt the system where education system is omputerized.This system is used for their organization to take quizzes.
System context
Major constraints: As the front end of the software is developed using applet only client server
communication is possible.
The students can submit the page after answering each question and answers
are auto submitted if the time of the quiz ends.
Not more than one attempt is allowed.
Used only within the educational institution.
Functional and Data Description
Data Description
Major data objects
Relationships
Relationships among the data are described below:
• There is an one to many relationship between role and user object,ie one role can have many users and there exists one to one relationship between the user and the role object, ie one user can have only one role.
• There exists many to one relationship between user and department object,ie many users belongs to one department.
• There exists many to many relatinship between question and quiz objects,ie one question can be contained in many quiz.similarly many questions can be contained in one quiz.
• There exists many to many relationship between the question and answer choice, ie one question may have many choices and one choice may belong to many questions.
• There exists many to many relationship between the user and course, ie one user can access many courses and one course may have many users.
Interface Description
External interface
Human interface
Teachers specify the questions in Textfield. If it is multiple choice question then, Radio button is provided to choose any
one of the correct answer. In case of fill ups, textfield is specified. For match the following, drop down list box is provided.
Software Interface Operating System Web Server Database Web Browser jvm
Hardware Interface Network card
Project issues No security for codes. Lack of skill set during the start of project Lack of language skill for preparing documentation Lack of experience Lack of time
Project schedule Requirement analysis Planning Cost estimation Managing Designing Coding Project delivery Maintanence
SOFTWARE PROJECT PLAN
Introduction: This document conveys the plan followed to execute the system.
Project scope: The scope of the software project plan is to develop the quiz system such that the teachers can take quizzes and the participants performance is determined according to the marks they obtained.
Major software functions:Some of the software functions are
Attending the quiz for various courses using userId submitting the answers Generating the marks
Performance/Behavior issues: Only one attempts are allowed No negative marks are specified Quiz should be completed within the specified time and date.
Management and technical constraints: some of our constraints are
Time constraints Workload from other subjects Lack of understanding System corruption Lack of security as the documents are stored in common storage space Electricity problem. Database connectivity problem. Absence of team members.
Project Estimates: This section provides cost,effort and time taken to finish the project.Waterfall model is used for developing the Quiz system.
Function Point Analysis
Estimationtechnique applied and result:Type of component Complexity of the components
Low Average High Total
External Input 2*3 2*4 1*6 20
External Output 0*4 1*5 2*7 19
External Query 2*3 3*4 4*6 42
Internal Logical Files
3*7 1*10 2*15 61
External Logic Files
0*5 0*7 1*10 10
Total number of Unadjusted Function points 152
Adjustment factors: The fourteen general system characteristics of FPA
Specification
Level 0 Level 1 Level 2 Level 3 Level 4
Data communications
Distributed Data Processing
Performance
Heavily used configuration
Transcation rate
OnLine data entry
Enduser efficency
OnLine update
Complex processing
Reusability
Installation ease
Operational ease
Multiple sites
Facilitate change
Level 0 > SimpleLevel 1>Low
Level 2>AverageLevel 3>HighLevel 4>Extreme
14 VAF = 0.65 + [( ∑ Ci) / 100] i=1
=0.65+(37/100) =0.65+0.37 Value Adjustment Factor=1.02 Adjusted functional Factor = Unadjusted Function Points * Value Adjustment Factor =152*1.02 Adjusted functional Factor=155.04
Hour estimation:
Total hour required to complete the project = 10 * Adjusted functional Factor = 10 * 152 = 1520 man hours of ASP
Day estimation
Total days required to complete the project = 1520 / (4 * 8) = 48 days
Cost estimation:
The cost estimation of this project is 1:2 ratio =2*50,000 + 2 * 25000
= Rs. 1,50000Reconciled EstimateThe final cost, effort, time (duration) estimate for this project is listed below
Requirements Approx.Final Cost 3,363 USD
Unadjusted Function Points
152
Value Adjustment Factor
1.02
Adjusted Functional Factor
155.04
Total hours 1520
Total days 48
1 INR = 0.0224 USDProject resources: People
HardwareSoftwareJdk,Jdbc tools
Risk management: About project risk and the approach to managing them.
Project risk:
Risk Probability Impact on OQSTeam members leave or become sick
High High
Key team member becomes available
Medium Medium
Solution does not meet the business needs
Low Low
Insufficient participation from the business units and users
Medium nil
System failures High Medium
Technical solution has major flaws
Low Medium
Technical solution has operational flaws
High Medium
Users fail to use the new system effectively and efficiently
Medium Low
Overview of Risk Mitigation, Monitoring, Management:
Risk management activities are given below
Risk assesment risk control
Risk control: The degree to which we can change the outcome. Three stages are 1.avoiding the risk 2.transferring the risk 3.assuming the riskCost of reducing the risk: risk leverage = (risk exposure before reduction – (risk exposure after reduction) /(cost of risk reduction)
Project schedule
Requirement analysis
Planning
Cost estimation
Managing
Designing
Coding
Project delivery
Maintanence
Gannt chart
Staff OrganisationTeam structure: The team structure for our project is
1Developer 1Technical lead 1Project manager 1Document reviewer
Tracking and control mechanism:
Quality assurance and control: Review meetings Code reviews Project reviews Checkpoints Proper standards and procedures
SOFTWARE REQUIREMENTS SPECIFICATION
Introduction:
This SRS describes the function and performance requirements of our class project. These include an overview of the project description, functional requirements of systems the project will run on, and characteristics of target users.
Goals and object:
While doing quiz/question development it is worth keeping the following issues in mind. Irrespective of whatever else we do, we want Moodle to have these properties. If you like, you can think of them as meta requirements or nonfunctional requirements.
Statement of scope:
The scope of the system is creating the questions for each sessions,giving the choices,calculating the marks and obtaining the results.
Software context:
The lecture media files may be downloadable onto the client’s desktop with the appropriate protections that will prevent unauthorized viewing or distribution of the lecture material.
Major constraints:
1.Creating User Accounts 2.Disabling Accounts,Deleting UsersLogging In, Concurrent Logins,Setting a Quiz,Modifying and Deleting a Quiz,taking a Quiz,Retaking a quiz.
Usage scenario: This section provides a usage scenario for the software. It organized informationcollected during requirements elicitation into usecases.
User profiles:
Users are students each of them will login and attend the quiz.
Usecase:
Data Model and Description:
This section describes information domain for the software
Data Description:
• questions
• choices
Data objects:
The data objects are questions and choices and their attributes are question
id,question name,question descriptions,question number,marks,choice
number,chioce(Y/N).
Complete data model:
Functional Model and Description:
A detailed description of each software function is presented.A description of each major software function, along with data flow and block diagram is presented.
LOGINPROCESS
Quiz Process:
ADD QUESTION
EDIT QUIZ
FUNCTIONAL MODEL:
STAFF
Add quiz Edit quiz delete quiz
STUDENTS
attend the quiz Review the Quiz
Update Quiz Generate Report
Function n interface description: External Interface Requirements Mouse Keyboard Windows Network adapter Performance Issues:
General Operating system, message passing and other middleware, and programming language(s) used shall follow industry standards and be commonly available and widely used. Availability of source code for the OS will be very important.
1.internet connection 2.high response time
Design Constraints: our design constraints is that no negative marks are specified.
Software Interface Description:
The modules will utilise PHP 5 and rely on the standard elements of a Moodle installation, namely a MySQL DBMS and an Apache Web server. All interaction with Moodle occurs on the clientside by means of a Web browser.
External machine interfaces:
Within Moodle a resource might be a link to an external Web page. Clicking on this resource displays the external Web page within the Moodle frame.
External system interfaces:
Scientific Users Operational Users Maintenance Users Development Users
Human interface: student quiz master
Control flow description: Manual interface Initialize (including optional default state) all instrument parameters and hardware settings Request and initialize data processing and reduction functions
Behavioral Model and Description: A description of the behavior of the software is presented.
Description for software behavior:
Events: The quiz question given by the staff is wrong due to some mistake there will be a change of questions.
States: Here it states the purpose, security, systems overview, current business plan and evaluation methods which connect to the SRS and the end product.
Control specifications: Software quality is conformance to explicitly state functional and performance requirements, explicitly documented development standards and implicit characteristics that are expected of all professionally developed software. Quality software is reliable, efficient and is easy to learn and operate. The software should be easy to maintain and should include tasks for correcting faults in the original design and make improvements to adapt the functionality of the software to changing environments. Software quality is also determined by whether the software product is portable, reusable and also whether it can be expanded.
Restrictions, Limitations, and Constraints:
QUIZ RESTRICTIONS:
The quiz is purely time dependent i.e. Each question carries a mark.All student should have equal time to view and answer the question.
Validation Criteria: Confirming that a product or service meets the needs of its users.
Classes of tests: • GUI software testing • performance testing • scalability testing • reliability testing • maintenance testing • recovery testing
Expected software response:unit testing:
The unit test type of the Team System testing tools.Introduces the concepts of generating and authoring unit tests in Visual Studio, testing private methods, and using the Unit Testing Framework .
Creating unit testing: Provides links to topics about generating and authoring unit tests, including ASP.NET unit tests and datadriven unit tests.
Creating and running unit testing:
Leads you through the steps to create and customize unit tests, run them, and examine the test results.
Run test and viewing code coverage:
Builds on a previous walkthrough to show how to view code coverage data, which shows the proportion of your project's code that is being tested.
Performance bounds: The approach/document used to make sure all the requirements are covered when writing test cases
Test Matrix Checklist Test bed Traceablity Matrix
SOFTWARE DESIGN SPECIFICATION
IntroductionThe purpose of this Design Document is to present the system design at a level
that can be directly traced to the specific system objective along with providing more detailed about data, architectural, interface and componentlevel design for Quiz System.
Goals and objectives The goal of this system is to provide interface design models that are consistent, and will provide straightforward transitions through the various functions in the system.The objective is to provide an efficient, modular design that will reduce the system’s complexity, facilitate change, and result in an easy implementation.
Statement of scope:
Any University,College or School can adopt the system where education system is computerized.This system is used for their organization to take quizzes.
Software context: The lecture media files may be downloadable onto the client’s desktop with the appropriate protections that will prevent unauthorized viewing or distribution of the lecture material.
Major constraints:
Major constraints As the front end of the software is developed using applet only client server
communication is possible. The students can submit the page after answering each question and answers
are auto submitted if the time of the quiz ends. Not more than one attempt is allowed. Used only within the educational institution.
Data design
Internal software data structure The internal software data structure of the Quiz system (find user list) is through the array list to list all the users in the system. this field will interact with the database
DATA FLOW DIAGRAM FOR QUESTION MODULE
CREATE:
database sink
READ:
database sink
UPDATE:
database sink
DELETE:
database sink
dataCreate
function
Database connectivi
ty
Data Read
functionDatabase
connectivityRead
function
dataUpdatefunction
Databaseconnectivity
dataDelete
functionDatabase
connectivity
DATA FLOW DIAGRAM FOR USER MODULE
CREATE:
database sink
READ:
database sink
UPDATE:
database sink
DELETE:
database sink
data Createfunction
Database connectivi
ty
Data Read
functionDatabase
connectivityRead
function
dataUpdatefunction
Databaseconnectivity
dataDelete
function
Databaseconnectivit
y
Database description Database design for a Question details
Architectural and componentlevel design A description of the program architecture is presented.
Program Structure This project integrates many different aspects to bring it together. There is a server,a database, and a client program. The client sends messages to the server and the server sends messages back to the client. The server has access to the database, but the client does not. So any actions with the database must go through the server. The server allows for more accessibility between the different clients, by controlling the communication between the different clients. This allows for more options for the quiz system and more control over what happens to the users.
Architecture diagram
Alternatives
Instead of having the server communicate with the database, there could be a different design where the client could directly access the information in the database. For certain projects this setup makes more sense because it offers quicker access. For this project and most programs it makes more sense for the server to do all the database communication because it is safer. There is more chance for database corruption if the client software can edit/access the database.
Software Interface Description:External Machine Interface: This project uses JDBC (Java Database Connectivity) as an external interface.
Human Interface:This describes about the interfaces that a user will be interacting with i.e.
it uses java swings to provide an user interface.
USER INTERFACE SPECIFICATION
LOGIN
Username Textbox 15charecters Text
Password Textbox Min.15charecters/numbers
Submit Submit button Hyperlink
VIEW COURSE INFORMATION:Course_Id Dropdown box
Course_name Dropdown box
SETTING A QUIZ:Name Dropdown box
Type of Quiz Dropdown box
ATTEMPTS:Attempts allowed Dropdown box
Each attempts TextBox
Adaptive mode Dropdown box
GRADES:Grading method Dropdown box
Apply penalties Dropdown box
Decimal digits in grades Dropdown box
TIMINGS:Open the quiz Dropdown box
Close the quiz Dropdown box
Question per page Dropdown box
Shuffle questions Dropdown box
Shuffle within questions Dropdown box
EDITING THE QUIZ:Selecting the questions Check box
Add to quiz Hyperlink
Delete Hyperlink
STUDENTS PERFORMANCE:Name of the Quiz Textbox
Time taken Textbox
Marks Textbox
TAKING A QUIZ:Attempt quiz now Button
Answer Textbox
Submit Button
Marks Textbox
REVIEW:Name of the student Textbox
Quiz started on Textbox
Quiz completed on Textbox
Time taken Textbox
Marks Textbox
Grade Dropdown box
Screen images
SAVE:
FIND:
UPDATE:
DELETE:
Objects and Actions:
This use case diagram describes how the object interact with system and action performed. The objects involved are
Staff Student
Restrictions, limitations, and constraints:i).Negative marks are not specified .ii).Quiz should be attended only once.iii).Quiz master should declare marks for each question.iv).User should complete the quiz within the given time limit.
Testing Issues The testing will be performed for the system with defined specification such as validation and verification. The system need to attempt black box testing & white box testing to known the feedback in which condition system fails.
Expected software response: This system is used to monitor the entire quiz system ie) the no. Of quizes attended by the student and the time taken to complete the specified quiz. Performance bounds: In advance to the specified information the system need to get details to display with user permission.