User:Jungledrew64/CS 1530 Software Engineering Document

The Prior version of this page has been moved to the discussion section under software plan! This page should now be dedicated to the Requirements Spec.

Product Overview and Summary

This program is a comprehensive testing center for students and instructors. It provides students with the ability to take mock exams as well as a secure environment in which to take actual exams. The software provides valuable feedback to the student by allowing them to view their progress on practice exams and saves the instructor valuable time by auto-grading the students' actual exams.

Instructors will be able to use SOTEC to keep an online roster of all the students they have in their classes. In addition to being able to see the names of the students in their classes, instructors will be able to view each students’ score and specific answers to questions. If the instructor wishes to see the average exam score of an entire class, SOTEC also provides this ability. Each class for which the student is enrolled will have a list of actual and real exams (provided the in-structor has made them available). As soon as the student submits a completed exam they will be able view their exam results as well as check their answers to each question on the exam.

Information Description

It is the goal of the SOTEC development team to make everything about our software as clear and well documented as possible. To aid the client and user we have compiled a small library of useful and relevant documents and diagrams. This compilation is found in the list below:

User Interface

Check out the great user's manual that we made!

High Level data flow diagram

Check out Ryan's Diagrams

Data Structure Representation

Exam Class

Fields

• Questions
  
• Course
  
• Exam Name
  
• Exam Creation Date
  
• Preamble

Methods

• Add Question
  
• Remove Question
  
• Show Question
  
• accessor/mutator methods for fields
  

Student Class

Fields

• ID
  
• First Name
  
• Last Name
  
• Password
  
• Class List
  
• Exam List
  
• Grades
  

Methods

• accessor/mutator methods for student class fields

Class Class

Fields

• Students
  
• Exams
  

Methods

• add/remove & accessor/mutator methods for fields
  

Question Class

Fields

• ID
  
• Question ID
  
• Description
  
• Choices
  
• Answer
  
• Picture
  
• Pictorial Choices
  
• Review Question
  
• Review Choices
  
• Question Type
  
• Points
  
• Deletion Flag
  
• Question Update Date/Time
  

Methods

• accessor/mutator functions for fields
  

Answer Class

Fields

• Answer
  
• Explanation
  
• Points
  

Methods

• accessor/mutator methods for fields

Data Elements Dictionary

We Need Something Here

Functional Description

The functional description breaks the main functions of SOTEC's software into two main categories. The first category describes the main student methods and the second category describes the main instructor methods. The following list describes in moderate detail the purposes and methods of each major function, of both student and instructor, within the SOTEC software.

Functions

IC Cards Need to be Completed

Processing Narrative

The processing narratives describes, on a function by function basis, what SOTEC is capable of accomplishing.

Student Functions

• The login function of SOTEC takes the information entered by the user (the information consists of the username and the password) and checks this information against the existing database of enrolled students. Once the information entered by the student is verified by the information in the database the student is logged into the system.
• The view exam function of SOTEC allows the student to check the status of his/her exams. If the exam has already been taken and graded the student may review the exam from the stored exams database. The student will be able see his/her answers and whether or not those answers were correct.
• The take exam function allows the student to access the desired exam and answer the questions in the time allotment provided. Once the student submits the exam it will be graded and updated as a "taken" exam.
• The submit exam function sends the exam to the grading utility for processing.
• The logout function suspends the student's ability to access the databases and exits the SOTEC software.

Instructor Functions

• The login function for the instructor is similar to that of the students' login with the exception that when the instructor's information is verified it will log in the user with the role and privileges of an instructor.
• The add student function gives the instructor the ability to add a student to the student database as well as set the username and password for that student.
• The add to class function allows the instructor to add a student to an existing class and will place that student into the selected class's roster.
• The remove student function allows the instructor to remove a student completely from the da-tabase of students.
• The remove from class method gives the instructor the ability to remove a student from a par-ticular class in which that student is enrolled.
• The view grade function permits the instructor to view the grade of a particular student on all exams taken so far by that student.
• The view course grades function allows the instructor to view the class's average grade for each exam taken so far.
• The add class function gives the instructor the ability to add a course to the existing courses da-tabase.
• The delete class function allows the instructor to remove a class from the classes database.
• The add exam function gives the instructor the ability to add an exam for a selected class to the exams database. Once in the database this exam will appear on the students list of exams.
• The view exam results function allows the instructor to view each of the questions in an exam taken by a student as well as the answers given by that student to each question.
• The create exam function allows the instructor to create, from scratch, a new exam. The instructor will be able to enter the desired question into a text field and then enter possible answers into labeled text fields. Once a question is completed it will be added to the new exam.

Design Constraint's

The design constraints describe functions that SOTEC does not handle.

• Only teacher has the authority to login a student. Student cannot enroll by himself to a particular course.
• The exam contains only multiple choose questions and true and false questions. Fill in the blanks and essay questions are not implemented in this program.
• The software can be used only by a single professor.
• The exam can only be taken at the specific time and date which the professor configures in the program.
• The exam questions are only questions in plain text. There are no questions with audio, video and multimedia properties.
• Complex statistical display of results with distributions and graphs is limited.

Diagrams

We Need to work on these

Performance Requirements

SOTEC was designed with the capability to be used with any size class. With the ability to house over one hundred thousand user profiles, space will never be an issue again. In addition to storage space, SOTEC can handle roughly five hundred users online at any time without any negative side-effects. With this potential instructors will find SOTEC more than able to accommodate any educational environment.

When it comes to data handling and processing SOTEC operates smoothly in all conditions. As the software shifts between screens and modes it will do so smoothly and instantly. Exams will be graded and the results made available to the student almost instantaneously. The information made available to the instructors regarding exam results is also immediate and any instructor using the SOTEC software will never have to deal with the inconvenience and time expense of manual grading again. The speed along with the simplicity of SOTEC makes our software some of the best in the field today.

Exception Conditions/Handling

The SOTEC system is designed to operate under many diverse conditions. Considering that users may be in any number of situations (taking a test while travelling and using a wireless connection, for example), irregular and even potentially hazardous events must be accounted for. Common causes of such exceptions include:

-A) Sudden loss of internet connection

-B) Unexpected or strange input of keyboard characters

-C) Program becomes unresponsive or “frozen”

-D) Multiple users trying to access the database

While such errors occur often and are not completely preventable, SOTEC is ensured to recover gracefully from these errors. In some cases, a graceful recovery is not possible, and the program is designed to then operate in the safest and most logical manner.

Sudden loss of internet connection

The loss of connection will be the most anticipated exception, and a great deal of preparation is involved in handling the connection loss. Any user using the SOTEC system who is not taking a test will find that if his or her internet connection is interrupted, the account is immediately signed out. An unfortunate side effect is that any new information that the user was entering during the outage is lost. This immediate sign out is designed for the security and protection of the user and the database. If an internet interruption occurs while taking a test, any previous an-swers that the user has entered are immediately uploaded to the database, and when the user returns, a notification appears saying that there is a test in progress. The user then re-enters the testing window, and picks up where the test left off.

Unexpected or strange input of keyboard characters

This occurs when the user tries (accidentally or purposefully) to enter keyboard characters that are not what the program is expecting. Unexpected characters include typing letters where numbers are appropriate or vice versa, or entering long words into small text fields in order to clutter the visual display. Strange input indicates characters that are not of the English language or numerical system, which often cannot be properly displayed in some machines. SOTEC has taken every precaution to prevent such exceptions from occurring in the first place. If numbers are entered where letters are appropriate and vice versa, the user will try to submit this information and the program will erase it and require re-input. Strange characters are not even registered in the program, i.e. if a user enters a strange character, nothing will happen.

Program becomes unresponsive or “frozen”

Occasionally an operating system will lock up. This happens for a variety of reasons, many of which have nothing to do with the software involved. When a program on such an operating system becomes unresponsive, it is often referred to as being “frozen.” The SOTEC program will keep the user logged on as long as the user’s internet con-nection remains, and the instance of the program remains open in the user’s computer. The moment either of these criteria is violated, the program performs exactly as specified in Sudden loss of internet connection).

Multiple users trying to access the database

With multiple users on the SOTEC server at once, collisions in database access may be problematic. In the SOTEC program, it is logically impossible for multiple students to write to the same data. However, if a teacher is modifying a student’s grade at the same time that a student is submitting a finished test (which also modifies the student’s grade), a race condition is prevented by temporarily suspending one client’s access to the database until the other has completed the action. As for the problem of, for example, a student viewing data while a student or teacher is modifying that data, the viewer will simply see the outdated information. Viewing an up to date class average to-the-second is not a high priority for SOTEC, and the developers anticipate the teacher will not try to edit tests while the students are taking them.

Implementation Priorities

Implementation priorities deals with the order of development of SOTEC. SOTEC development has been focused of three major advancements as detailed below:

Server/Database

The Server program is a program that both the Teacher Interface and Student Interface will communicate with. Neither interface will directly communicate with the Database. All Database communication will be done via the server program so that Data Encryption can be achieved. When the server receives a command from the client process it will first decipher the command, execute the proper action, and (if necessary) encrypt a message to send back to the client. Since both clients inherently depend on the Server program this will be our first priority.

Student GUI

The Student GUI refers to the portion of the program that the student will interact with. We put this ahead of the Teacher GUI because the databases can be updated manually if necessary mitigating the need for a Teacher Interface. However this would be a ver complicated procedure without a Teacher Interface and would be best left to a SOTEC System Programmer. Since the Teacher Interface is unnecessary if we must abandon the project after this step for some unforeseeable reason the client would still have usable software. The Student GUI is broken into 2 parts: The Shell and the Button Functions

Shell

The Shell refers to the portion of the Student interface that flips between different Screens. We must have all of the screens running and accessible in order to program all of the functions that each screen entails. Therefore the Shell will be finished before the Button Functions.

Button Functions

The Button Functions refers to the portion of the Student Interface that does actual work on the information. Since this is the last component left for a working GUI it will be the final step in completing the Student GUI

Teacher GUI

The Teacher GUI while very important is unnecessary. This is why it will be our last portion of the program to work on. Similarly to the Student GUI it will be broken down into 2 parts: The Shell and the Button Functions

Shell

We will first make sure that all Teacher Interface screens interact properly without providing any real functionality to the program.

Button Functions

Just as in the Student GUI section the Button Functions will be added in lastly to provide the client with a completed Teacher Interface and thus a complete program.

Foreseeable Modifications and Enhancements

VC Tool for communication between the student and the teacher: We would implement VC tool function to allow communication between the teacher and the student. The student may have doubts and questions regarding the questions in the practice exams or course material in general. The student does not have to meet with the teacher to get his questions clarified. The student can virtually interact with teacher using the VC tool. The VC tool also supports multiple students communicating with the teacher. There will a dialog in the software where the student can view if the teacher is available online in the VC tool. If the teacher is available then the student could launch the VC tool from the software and start discussing with the teacher. Using this tool the student can also discuss with other students regarding the courses and topics.

Support of mulitple teachers: We may provide support for multiple teachers to use the software. Currently only a single teacher can use the software. How ever there may be situations where multiple teachers may need to login into the software. Using this feature more than a single teacher can conduct tests, view test results and courses without any conflicts. However, when there are multiple teachers then only one teacher has control of viewing test results, conducting test and modifying the data in the software.

Acceptance Criteria

SOTEC will be tested by The SOTEC Development Team with a Minimum of 20 classes, with between 20-50 students per class, and between 2-6 Exams per class. During these test runs we will be checking that:

• All Exams are locked and unlocked at appropriate times
• All Questions are presented correctly to the student
• All Answers are correctly recorded in the Database
• Automatic Grading is correct
• All Teacher Users can correctly add/remove classes from the database with no residual data corruption
• All Teacher Users can correctly add/remove students from the database with no residual data corruption
• All Teacher Users can correctly add/remove exams from the database woth no residual data corruption
• All Data communication between the Client program and the Server Program is encrypted

Our Testing procedure will involve each developer and some testers administering at a minimum 1 class and at a maximum 30 classes as the instructor user. While the remaining developers and testers would make up the student body of the other developer's classes. This way we can ensure that every developer tests for Teacher bugs, and also tests for Student bugs with the rest of the testing team. The use of outside testers also allows us to see if someone with no knowledge of the actual code could cause our program to reach an error state.

Sources of Information

"Java Software Solutions: Foundations of Program Design, 5/E" by John Lewis and William Loftus

"Data Structures and Abstractions with Java" by Frank Carrano and Walter Savitch

"Algorithms in C++" by Robert Sedgewick

Revision History

September 25, 2008

Added Sections 1, 2.1, 2.2, 3.2 and 3.3.

October 2, 2008

Added Sections 2.3, 2.4, 3.1, 3.4, 4.0, 5.0, 5.1, 5.2, 5.3, 5.4, 6.0, 6.1, 6.2, 6.3, 7.0, 8.0, 9.0, 10.0