Chapter 2 SDS

TABLE OF CONTENTS

1. Introduction
1.1 Purpose ……………………………………………………Page No
1.2 Scope………………………………………………………Page No
1.3 Terms, Definitions, Acronyms and Abbreviations………..Page No
1.4 Overview of Document ……..……………………………..Page No

2. System Architectural Design

2.1 High Level Design Overview…………………………….. Page No

2.2) Detailed Description of Components

2.2.1) Structure Chart …………………………………... Page No

2.2.2) Data Flow Diagram………………………………………. Page No

3. Data Design
3.1 Database Description…………………………………Page No

3.2 E-R Diagram…………………………. ………………… Page No

4 User Interface Design

4.1Detailed Description of Components……………………… Page No

4.2 Screen images

5. TYPES OF TESTS (With Implementation)................................................. Page No

6. Appendices

7. References

1. Introduction

TOPIC- EXAM SEATING ARRANGEMENT SYSTEM

The main objective of the topic of the Exam Seating Arrangement System is to manage the
detailsof Exam,Seats,Student,Roll Number,Rooms. It manages all the information about
Exam, Incharge, Rooms, Exam. The project is totally built at administrative end and thus only
the administrator is guaranteed the access.

1.1 Purpose

The purpose of developing exam hall seating arrangement system is to computerize the traditional way of
conducting the exams. Another purpose for developing this software is to generate the seating
arrangement report automatically during exams at the end of the session or in between the session.

1.2 Scope

It may help in collecting the perfact Mnagement Details in a very sort perid of time.It hepls the students
to know the mangement of the passed year perfactly.To Utilize resource in an efficient manner by
increasing there productivity through automation.Delivered on the Schedule with perfact budget.

1.3 Terms, Definitions,Acronyms and Abbreviations

1) USER

2) lOGIN

3) ROOM

4) FLOOR

5) SEATS

6) EXAM

1) User –User can be our Student,Admin,Teacher who will login to the website
for registration.

2) Login – The login page will describe the user name and user password column
through which the user can login.

3) Room –Room will describe in thw website that which room is allocated to the
student or the teacher in exam.
4) Floor – Floor will describe in the web page that on which floor the room is
allotted to the student or teacher.

5) Seats – Seats will describe in the web page that which seat is allotted to the
student.

6) Exam -Exam will describe the ExamName ExamRollno.,ExamType,Examdate

and so on.

1.4 Overview

During exam period it is very hectic task to find out where is your examination hall and which seat would
allocate to a perticular student.This is a web application developed to help students to find out their
respective examination hall during semester exam. This would also shows the respective seat of a student
in a perticular row and also the schedule of their examination.

2. System Architectural Design

A system architecture is the conceptual model that defines the structure, behavior, and more views of a
system. An architecture description is a formal description and representation of a system, organized in a
way that supports reasoning about the structures and behaviors of the system.

2.1 High-level Design Overview

Introduce the various components and systems at a high conceptual level.

A Pictorial representation of the system architecture is presented.

2.2) Detailed Description of Components

The main actors of Exam Seating Management System in this Use Case Diagram are: Super Admin,
System User, Examiner, Student, who perform the different type of use cases such as Manage Student,
Manage Block, Manage Room, Manage Exam, Manage Seat, Manage Teacher,, Manage Users and Full
Exam Seating Management System

Examples:-

Data flow diagram (DFD)

Structure chart
Use Case diagram

Entity relationship diagram

Class diagram
Activity diagram
Sequence chart
Component and interface diagram

A detailed description of the input and output interfaces for the component is presented.
Component and processing detail
A detailed algorithmic description for each component is presented. A diagram showing the flow
of information through the function and the transformation it undergoes is presented. For
Example –

3) Structure and relationships

This subsection will make clear the interrelationships and dependencies between
modules/layers/components. Structure charts can be useful here. Another good idea is to use a simple
finite state machine that demonstrates the operation of the product you are designing. There should
always be explanatory text to help the reader understand any charts.

3.1) Data design

A description of all data structures including internal, global, and temporary data structures.
Temporary data structure
Files created for interim use are described.
3.2 Database description

Database(s) created as part of the application is (are) described. E-R Model should clearly specify the
data entities and relationship between them. After normalization, each table must be described with
purpose, methods using it, all its fields description, their data type, and integrity constraints.

4) User Interface Design

A description of the user interface design of the software is presented.
4.1 Description of the user interface
 A detailed description of user interface including screen images or prototype is presented .

4.2 Screen images

Representation of the interface form from the user's point of view.

4.3 Objects and actions

All screen objects and actions are identified. Describe each object’s purpose, data type, properties and
responses for different events
.
For Example –
The Execution Order Function

For Example –

The Execution Order Function

5. TYPES OF TESTS (With Implementation)

Unit Tests
Unit tests are most commonly done by developers on their own machines or on a common server that is
very volatile. It is not necessary that the unit test machines be the same platform and operating system as
the target deployment environment, but the movement from the unit test environment to other testing
environments should not require material code changes by developers. A plan for one machine per
developer plus one small server should be included in the overall system architecture.

System Tests

The system test environment allows multiple modules to be connected together and executed as in a
typical use-case scenario. The choice as to whether this is done on a separate machine from unit testing is
up to the implementation and test team. If the target deployment environment is different from the unit test
environment, the system test environment should contain a machine that matches the target environment.
Although the system test machine need not match the size of the deployment box, it should have the same
platform and operating system. A good rule of thumb is to prepare to add one more box for system tests of
a smaller size, but the same operating system as the target environment. Again, this will be a relatively
volatile environment, so it should not be viewed as a place to do industrial-strength testing by a large
team.

Integration or Regression Tests

To perform integration and regression tests, it is advisable to have a separate environment that is similar
to the target environment. Generally, one server will be enough at this point. However, the contents of
this server should be strictly controlled. Either the test coordinator or his or her designate should make
all software changes to this environment. Stability and auditability are essential to ensuring the accuracy
of test results. Plan for at least one more servers at this stage in testing.

Stress Tests

Stress tests should be done in an environment identical to the target hosting environment. In the
first development cycle, this can be done in the production site, before the cutover to production.
For subsequent development cycles, a separate environment will have to be maintained for stress
testing.
Plan to replicate the deployment environment as part of the test bed for at least the second development
cycle of the site. It has also been observed that the most common problem after performance in a high
stress environment is database deadlock due to improper programming.
Deadlocks are typically difficult to detect and fix and may not show up until the site is highly stressed in
production. So it is important that these conditions be stringently tested during the
stress test phase.

Acceptance Tests and Staging

Acceptance tests are generally performed in the same environment as the stress tests, so additional
hardware is not needed to support this phase of testing. Again, during the initial development cycle, the
production environment can be used to perform both acceptance testing and staging, but a new
environment should be created for subsequent development cycles.

6. Appendices

7. References

https://www.freeprojectz.com/premium-synopsis/synopsis-exam-seating-arrangement-
system#:~:text=The%20main%20objective%20of%20the,administrator%20is%20guaranteed
%20the%20access.

https://jpinfotech.org/exam-hall-seating-allotment-system/

https://www.ijert.org/automation-of-exam-hall-allotment-and-seating-arrangement

https://www.researchgate.net/figure/Seating-arrangement-in-the-school-
examination_fig1_309437382