Computerization of the Process for Preparing Question Papers - Essay Example

Introduction The School of Technology at Oxford Brookes is undertaking the computerization of the process for preparing question papers for its various departments. The process involves communication between the Examination and Conferment Unit (ECU), module leaders, teaching staff, internal checkers, the exam secretary, and external examiners. The computerization project aims to improve the current system, which is considered quite tedious by the different parties involved. The new system, which shall be named “School of Technology Modular Examination and Coursework Preparation” (STMECP System), must address the issues associated with the current system while meeting quality assurance requirements in the preparation of question papers. An initial Requirements Elicitation and Specification has already been conducted. The project team elicited and analysed users’ requirements for the new system and identified both functional and non-functional requirements, as well as identified and analysed use cases and scenarios. The next step is to produce detailed requirements specifications using requirements modeling tools which help control the complexity, risk, and scope of the project. Requirements modeling also help and define goals and success criteria in an unambiguous manner for all the parties involved in the development and eventual use of the system. Complex requirements can be modeled with full traceability provided from each requirement, through to the final deliverables and system behavior (Sparx-Req Mgt, 2008). Functional Modeling As defined during Requirements Elicitation and Specification, the functional requirements of the new system are divided into two areas: 1) the preparation of questions, solutions and other exam and coursework materials, and 2) the preparation and update of the TEO forms. In the first area, the following functional requirements have been identified: 1) individual members of the teaching staff should be able to add a question to the designated question paper for a particular module according to the format prescribed by the ECU; 2) individual members of the teaching staff to be able to input or attach additional materials such as case studies, formula sheets, solutions and marking schemes to the particular questions formulated; 3) individual members of the teaching staff should be able to edit a question or additional material (add, change, delete) based on revision instructions or comments from internal checkers and external examiners; 4) the module leader should have browsing functionality for the questions and solutions inputted by the members of the teaching staff; 5) the internal checker should be able to input revision instructions and comments on the questions; 6) the external examiner should be able to input revision instructions and comments on the questions; 7) the module leader should be able to generate question paper and solution listings for the module and the related TEO form; and 8) the exam secretary should be able to generate question paper and solution listings for the module and the related additional materials and TEO forms, for submission to the ECU. For the second area, the following functional requirements have been identified: 1) the exam secretary should be able to prepare a TEO1 or TEO2 form as appropriate; 2) the exam secretary to be able to enter updates to the TEO forms; 3) the exam secretary should be able to send an information or reminder message to module leaders and external examiners related to the TEO forms, question papers and solutions; 4) the module leader should be able to enter updates to the TEO forms; 5) the internal checker should be able to enter updates to the TEO forms; and 6) the external examiner should be able to enter updates to the TEO forms. Use cases are goal-oriented sets of interactions between actors and the system. For the STMECP system, the actors are the exam secretary (ES), module leaders (ML), members of the teaching staff (TS), internal checkers (IC), and external examiners (EE). A use case is initiated by an actor with a particular goal in mind, and completes successfully when the goal is satisfied. The use case also describes the sequence of interactions between actors and the system necessary to deliver the service that satisfies the goal (Malan & Bredemeyer, 2001). Based on the functional requirements listed previously, the following use cases have been identified: Use Case Description Actors Scenarios Assumptions Steps 1-Prepare Detailed Exam/ Coursework Materials Preparation of all materials required for Modular Examinations and Coursework. These include exam/ coursework template, questions, solutions, examination rubric, case studies, formula sheets and all other materials need for exams or for the accomplishment of coursework. ML TS IC ES EE 1-Preparation of template. 2-Inputting of detailed components. 3-Checking of detailed components 4-Inputting revision instructions and comments. 1-The system can perform all tasks defined in “Steps”, as initiated by Actors. 2-All Actors have secure access to the system. 3-A TS cannot modify another TS’ work, only his/her own. 4-Only the ML can modify any part of the body of detailed Exam/ Coursework Materials. 5-Materials related to a particular module are accessible by module. 6-TS may not access modular materials, only details. 7-ML, IC, ES, EE may access modular materials. 8-The system includes a facility for sending reminder messages to different Actors when their actions are required for certain components of detailed materials. 1-ML prepares template. 2-TS inputs materials. 3-ML inputs revision instructions, comments. 4-TS revises materials. 5-IC inputs revision instructions, comments. 6-EE inputs revision instructions, comments. 2-Package Final Modular Exam/ Coursework Materials Packaging of all detailed materials into a complete modular exam/coursework material. ML IC ES EE 1-Checking for completeness of materials for a module. 2-Inputting of overall modular revision instructions, comments, if required. 1-Materials related to a particular module are accessible by module. 2-Modular materials are exactly the same as detailed materials. 3-A finalized package of modular materials cannot be modified unless through a special procedure. 1-ML initiates messages to TS, in case of incomplete or not yet submitted details. 2-IC and EE inputs modular revision instructions, comments. 3-ES initiates messages to ML, in case of incomplete or not yet submitted modular materials. 3-Preparation and Update of TEO Forms Preparation and update of TEO1 and TEO2 forms which are used to initiate and monitor the preparation of modular exam/ coursework materials. ES ML IC EE 1-Preparation of TEO forms. 2-Update TEO form. 1-The related TEO form is linked to the appropriate modular materials. 2-All Actors have secure access to the system. 3-An Actor who has confirmed his/her update of the form cannot modify his/her own update. A new update needs to be created. 1-ES prepares TEO forms. 2-ML updates TEO forms. 3-IC updates TEO forms. 4-ES updates TEO forms 5-EE updates TEO forms. A functional model is a structured representation of the functions, activities or processes within the modeled system (FIPS, 1993). The logic for such functions, activities or processes can be modeled using activity diagrams which capture the logic in each use case of usage scenario (Ambler-Activity Diagram, 2006). An activity diagram is used to display the sequence of activities and show the workflow from a start point to the finish point detailing the many decision paths that exist in the progression of events contained in the activity (Sparx Activity Diagram, 2008). The new STMECP system should be a network and browser-based system where databases for exam and courseware materials may be inputted according to prescribed format; checked, inspected, and commented on; and then revised by the designated system actors. To address the need of reducing the tedium for the Module Leader in standardizing formatting of materials, a pre-determined and prescribed format must be implemented by all members of the teaching staff who produce the detailed materials. These materials should be directly inputted into the system or converted to electronic format and then uploaded into the system. The current sequence of processes shall be maintained in the new system, but the current tediousness will be reduced if not altogether eliminated with the new system Use Case 1 - Prepare Detailed Exam/ Coursework Materials Module OK Leader Not OK Teaching Staff Internal OK Checker Not OK --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- OK Module Leader Not OK Teaching Staff --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Exam Secretary For ML For EE For ECU External Examiner The activity diagram for Use Case 1 – Preparation of Detailed Exam/ Coursework Materials shows that the entire process starts with initiation from the Module Leader of the template for the module. And then, a series of iterative processes are implemented for inputting, checking, revising and finally completing each detailed material component of the modular exam/ coursework materials. To duplicate the signoffs which are currently used in the existing semi-automated system, the new STMECP will have the facility for identifying the actor who has last accessed or updated any data component. As a form of control, each member of the teaching staff can input materials only for his/her assigned topics. Moreover, updates to materials can only be done by the assigned teaching staff member and the Module Leader. This is being done to help ensure that there will be no tampering of materials. On the matter of security, only designated users with specific access privileges are allowed in the system. Actors/users shall be held responsible for any misuse of their access privileges. Use Case 2 - Package Final Modular Exam/ Coursework Materials Module To ES Leader To IC Internal Checker To ML Exam Secretary To ECU To EE External Examiner The activity diagram for Use Case 2 treats the exam and courseware materials as one package per module. The process starts with the consolidation of the materials for a particular module by the Module Leader. When these materials are complete, the ML passes this on to the Internal Checker. The IC’s attention will be called using a message function triggered by the ML. Only complete materials will be passed on to the IC in this use case, as opposed to the previous one, where detailed material components may be submitted for review. It will be up to the users to determine if partial materials may be passed on to the reviewers. Use Case 3 - Preparation and Update of TEO Forms Exam To ECU Secretary To ML Module Leader To EE Internal Checker External Examiner The activity diagram for Use Case 3 deals with activities involving the TEO1 and TEO2 forms which are used to summarize the activities regarding the exam and coursework materials. The Exam Secretary initiates the process with the preparation of TEO form for a particular module. TEO1 is used for modules with final exams, while TEO2 is used for modules with coursework requirements. As a form of control, once an update is confirmed by a particular Actor, the update cannot be undone, even by the same Actor who created the update. In this case, a new update should be created. This measure will be implemented in order to prevent any tampering of the current status of materials preparation. Structural Modeling Object-oriented analysis is the study of interacting objects in order to understand and document their characteristics based on formal definitions of system data and behavior modeling. Object-oriented analysis modularizes the analysis using the same object boundaries that exist in the real world. It organizes knowledge about each object in a single logical location making it easier to locate and concentrates on the “what” rather than the “how”, which reduces the temptation to proceed to design before a thorough analysis is completed (Black et al, 1994). An object is something that exists in the real world, whether physical or not, has a unique identity and refers to a single object rather than a group of objects. A group or set of objects with similar characteristics or attributes are referred to as an object class. An object may also be composed of other objects, may be related to other objects by participating in a relationship, and/or may be a member of an object class (Black et al, 1994). For the STMECP system, the following are identified as objects and object classes, with their attributes. Class Objects Attributes Component Object/Class Exam Secretary Fiona Parker Name Module Leaders Individual module leader assigned per module Name Teaching Staff Members Individual members of the teaching staff Name Internal Checkers Individual internal checker assigned to a module Name External Examiner Individual external examiner assigned to a module Name Module Module Module Title Module Number Exam/Coursework Code Module Leader Teaching Staff Internal Checker External Examiner Exam/ Coursework Materials Component detailed exam/ coursework materials such as questions, solutions, exam rubric, case studies, formula sheets and other materials Name Module Title Module Number Teaching Staff Name (author of detailed material) Module Module Leader Internal Checker External Examiner TEO1 Forms Individual TEO1 form per module TEO1 Form Number Module Title Module Number Exam Secretary Module Exam/ Coursework Materials (for the module) TEO2 Forms Individual TEO2 form per module TEO2 Form Number Module Title Module Number Exam Secretary Module Exam/ Coursework Materials (for the module) Exam Secretary is an object which does not belong to an object class. A particular Module Leader belongs to the ML Object Class. A particular Teaching Staff member belongs to the TS Object Class, and so on and so forth for a particular Internal Checker or External Examiner. Specific ML, TS. IC, and EE objects are related to a specific Module. Also related to a specific module are specific component details of Exam/ Courseware Materials objects, as well as specific TEO1 or TOE2 forms. Object-Relationship Model for Module Object Class (6-ary) Object-Relationship Model for Module Leader Object Class (6-ary) Object-Relationship Model for Teaching Staff Object Class (Ternary) Object-Relationship Model for Internal Checker Object Class (Quarternary) Object-Relationship Model for External Examiner Object Class (Quarternary) Object-Relationship Model for Exam Secretary Object (6-ary) Object-Relationship Model for Materials Object Class (7-ary) Object-Relationship Model for TEO1 Object Class (6-ary) Object-Relationship Model for TEO2 Object Class (6-ary) As indicated by the preceding object-relationship models, all the object classes in the system have multiple relationships with other object classes. Below is a summary table of Relationship Arity, as well as relationship constraints. Cells with a constraint entry depict an existing relationship. The notation 1:” denotes a “one-is-to-many” participation constraint, referring to row:column. Class Module Module Leader Teaching Staff Internal Checker External Examiner Exam Secretary Materials TEO1 TEO2 Module 1:1 1:” 1:1 1:1 1:1 1:” 1:1 1:1 Module Leader 1:” 1:” 1:” 1:” 1:1 1:” 1:” 1:” Teaching Staff 1:” 1:” 1:” Internal Checker 1:1 1:1 1:” 1:1 1:1 External Examiner 1:1 1:1 1:1 1:” 1:1 1:1 Exam Secretary 1:” 1:” 1:” 1:” 1:” 1:” Materials 1:1 1:1 1:1 1:1 1:1 TEO1 1:1 1:1 1:1 1:1 1:1 1:” TEO2 1:1 1:1 1:1 1:1 1:1 1:” The table above shows that each module has 1 ML, multiple TS, 1 IC, 1 EE, multiple materials, 1 TEO1 and/or 1 TEO2. But, unless otherwise defined by users, a module leader may have multiple modules, multiple TS, IC, EE, materials and TEO forms. Similarly, a particular TS object may have multiple modules and materials to work on. However, only 1 ML, 1 IC, I EE, may be assigned to a particular module. One material object can relate to only 1, TS, 1 module, 1 ML, 1 IC and 1 EE. One TEO form is associated with only 1 module (and one object in each of the other object classes it is related to), but is associated with many materials belonging to the 1 module. Behavioural Modeling The sequence diagram shows the interactions between objects in the sequential order that the interactions occur. It is used as a requirements document to communicate requirements for a future system implementation. Sequence diagrams are used in the transition from requirements contained in the use cases to the next level of refinement (Bell, 2004). The sequence diagrams for the Use Cases depicted earlier are presented below: Note that in the Sequence Diagram (1), above, the Object Classes for Module and Materials are not depicted. This is because these Classes are already internal to the System. The diagram shows the sequence of actions from the topmost action which is “Prepare template” by the Module Leader, followed by “Input materials” by Teaching Staff, and so on. Again, the Object Classes for Module and Materials are not depicted in the Sequence Diagram (2), above, because they are imbedded in the System. Again, the Object Classes for Module and Materials are not depicted in the Sequence Diagram (2), above, because they are imbedded in the System. Just like the Module and Materials Object Classes, the TEO1 and TEO2 Object Classes are also internal to the system. Object-oriented analysis also focuses on how data and behavior relate to each other, and behavioral models coordinate what we call steps. In behavioural modeling; these steps are called states, actions or sub-activities. At least 2 questions need to be answered at each step: “When should each step be taken?” and “When are the inputs to each step determined?” One of the behavioural modeling tools is the state machine. A state machine diagram illustrates the behaviour of an object, specifying the sequence of events that an object goes through during its lifetime in response to events (Sparx-State Mach, 2008). Following are state machine diagrams for the Module/ Materials, Module Leader and Exam Secretary Object/ Object-Classes. The State Machine Diagram for Module/ Materials shows three states: 1) idle, 2) updating, and 3) checking. Idle state means nobody is accessing it. Updating state means one of several processes – accepting the template being created by the ML; accepting materials being created or uploaded by different TS; accepting revision instructions or comments from the IC or EE; or revising materials being done by the TS or ML. The checking state means that Module/ Materials are simply being viewed or browsed, without any updates being done. The State Machine Diagram for Module Leader shows five states: 1) idle, 2) updating module/materials, 3) updating TEO forms, 4) checking TEO forms, and 5) checking materials. Idle state means that the Module Leader is not logged on to the system. The Updating Module/Materials state means that the Module Leader is doing one of two processes – creating the module template or updating materials that he/she himself/herself had created or those created by TS under him/her who are assigned to the module. Updating materials is differentiated from updating TEO forms because each requires access to distinct and separate databases. Both checking TEO forms and checking materials mean that the Module Leader has accessed either forms or materials but is not doing any updates on them. The State Machine Diagram for Exam Secretary shows four states: 1) idle, 2) updating TEO forms, 3) checking TEO forms, and 4) checking materials. Idle state means that the Exam Secretary is not logged on to the system. The Updating TEO Forms state means that the Module Leader is doing one of two processes – creating a form or updating a form. Updates to be done by the ES on the forms include posting the appropriate routing dates and initialing the ES portion. Both checking TEO forms and checking materials mean that the Exam Secretary has accessed either forms or materials but is not doing any updates on them, merely browsing them. It is also presumed that the ES is not allowed to update Module/ Materials. Conclusion The object-oriented analysis (OOA) approach uses an integrated set of models to identify the conceptual entities or objects in the system, their behavior, and the required processing. OOA is a good analysis approach because it pays attention to real world issues. Verification of the analysis results is possible through simulation using the OOA models and it is a widely used approach to facilitate the transitions from analysis to design (Lee, 1999). Even with the development of various OOA models, there is a need to sustain the analysis effort. Problems and issues may arise such as confusion with OOA terminologies and diagrams and notations; incomplete models, difficulties with integrating models, as well as wavering of project sponsor support. These issues may be addressed by augmenting formal models with informal notes and diagrams, reviewing the models, and distinguishing between analysis and design facets. As the analysis proceeds, more and more are learned about the scope of the work and the rate at which it can be accomplished. All new information should be factored in and the plan suitable adjusted. References Ambler, S.W. 2006. UML 2 Activity Diagrams. Retrieved 10 November 2008, from http://www.agilemodeling.com/artifacts/activityDiagram.htm Bell, D. 2004. UML’s Sequence Diagram. IBM DeveloperWorks. Retrieved 10 November 2008, from http://www.ibm.com/developerworks/rational/library/3101.html Black, P. et al. 1994. An OSA Tutorial. Retrieved 10 November 2008, from http://osm7.cs.byu.edu/OSA/tutorial.html Federal Information Processing Standards. 1983. Integrated Definition for Function Modeling. Retrieved 10 November 2008, from http://www.itl.nist.gov/fipspubs/idef02.doc Lee, M.M. (1999). Object-Oriented Analysis in the Real World. Methods & Tools. Retrieved 20 October 2008, from http://www.methodsandtools.com/archive/archive.php?id=77 Malan, R. & Bredemeyer, D. 2001. Functional Requirements and Use Cases. Architecture Resources for Enterprise Advantage. Retrieved 20 October 2008, from http://www.bredemeyer.com Sparx Systems. 2008. Requirements Management and Modeling Tool. Retrieved 10 November 2008, from http://www.sparxsystems.com/platforms/requirements_management.html Sparx Systems. 2008. UML 2 Activity Diagram. Retrieved 10 November 2008, from http://www.sparxsystems.com.au/resources/uml2_tutorial/uml2_activitydiagram.html Sparx Systems. 2008. UML 2 State Machine Diagram. Retrieved 10 November 2008, from http://www.sparxsystems.com.au/resources/uml2_tutorial/uml2_statediagram.html Read More