SYSTEM DESIGN

1 Introduction:

The purpose of System Design is to create a technical solution that satisfies the functional
requirements for the system. During analysis, the focus is on what needs to be done intendment
of how it is done. During design, decisions are made about how the problem will be solved, first
at a high level, then at increasingly detailed levels.

System design is the first stage in which the basic approach to solving the problem is
selected. During system designing the overall structure and style are decided. The system
architecture is the overall organization of the system into components called system. System
design deals with transforming the customer requirements, as described in the SRS document,
into a form that is implement able using the programming language. Certain items such as
modules, relationships among identified modules, data structures, relationships between the data
structures, and algorithms for implementation should be designed during this phase.

1.1 Overview:
This System Design provides the overall design of the Student Information Management
system implemented during this project, covering the purpose and reasoning behind the system's
major components.

1.2 Scope:

The main scope of the system design is :

 Organize the system into modules

 Organize sub-modules for each module
 Allocate tasks to processors
 Choose an approach to manage data store
 Handle access to global resources
 Choose implementation logic
 The basic idea behind System Design is to develop a software system incrementally,
allowing the developer to take advantage of what was being learned during the development of
earlier, incremental, deliverable versions of the system.

1.3 Background:

The Student Information System records basic student information, Examination

information, education information regarding student. Student management function involves :

 Manage student records

 Student Basic Information
 Manage course and specialty
 Manage semester and year
 Result management
 Subject management

In Student Management System, administrator has a Login ID and Password. Also all the
users have different permission rights to access the applications.

There are two main roles in the system. Admin and operator. Admin has complete access to the
whole system, while operator is the role that is responsible for the use of the system.

1.4 References:

Systems Analysis and Design

- Allan Dennis

St. Philomena College Database

1.5 Assumptions and constraints:

1.5.1 Assumptions:

 The system is not required to save generated reports.

 The code should be free with compilation errors/syntax errors.
 The details must have an interface which is simple enough to understand.

1.5.2 Constraints:
 Internet connection is required.
 The constraints of this project are the system must support the latest web browser and
must be able to run all the forms.
 Login and password is used for identification of administrator and there is no facility for
users.

2 Applicable documents-METHODOLOGY:

This web application is developed for managing student details, examination details and
attendance details. As the project is user friendly, it can be applied to large database with more
information. This software can use by any sanitary administrator to make their work simple.
They can get information quickly as possible. It can handle large volume of data and present
reports whenever required.

Structure of software Pacakage

The main functional components are

 Administrator/Operator login.
 Course details.
 Subject details.
 Student records.
 Examination details.
  Attendance records.
 Logout.

2.1 System Design Alternatives:

 Adobe Dreamweaver
 PHP Designer

2.2 Risks:

The risk factors are,

 In case the database lost because of some OS failure or because of Anti Virus actions the
software should have option for restore data.
 The restore is possible only if the backup maintained by the user is up to date.
 Otherwise the restore may failure or the restore point may not be up to date.

2.3 Updated Requirements Compliance Matrix:

Since we are using PHP 5.2 version and MySQL 5.0 version, if there is any updates, upgrade
Apache server to update PHP and MySQL.

3 Functional Decomposition-SYSTEM DESCRIPTION:

The software is decomposed into several modules for the convenience of the user. The
operator enters the student details, examination details, attendance details. In this all
information are already stored in access. Here we can add, delete or update the existing
records.
3.1 System Software Architecture:

PHP INI
Smarty

PHP

Apache Server

MySQL Web
MySQL Database Server

Internet Server

Fig 1.1 System Software Architecture

3.2 System Technical Architecture:

Apache Server MySQl Server

Web Server

Template engine
Database
Administrator

Fig 1.2 System Technical Architecture

3.3 System Hardware Architecture:
In engineering, hardware architecture refers to the identification of a system's physical
components and their interrelationships. This description, often called a hardware design
model, allows hardware designers to understand how their components fit into system
architecture and provides software component designers important information needed for
software development and integration.

Fig 1.3 System Hardware Architecture

3.4 External Interfaces:

A. Name of application

Student Information System

B. Details of interface

 Admin login into the application user name and password.

 After successful login enters the details of new students details, course details, subject
details, examination details, attendance details etc.
 Finally the details like students details examination reports, attendance details can be
viewed by students, parents, teachers etc.

C. Description of operational implications of data transfer, including security considerations

Operational implication of the data transfer is done through validation.

4 Description of Programs – Subsystem Specification:

4.1 CONTEXT FLOW DIAGRAM (CFD):

A Context Flow Diagram is a top level (also known as level 0) data flow diagram.
It only contains one process node (process 0) that generalizes the function of the
entire system in relationship to external entities. In context diagram the entire
system is treated as a single process and all its inputs, outputs, sinks and sources
are Identified and shown.
 Administrator Operator

Controls Manages records

Student Information
System

Information Report Reports

Students Examination Attendance

Fig 1.4 Context Flow Diagram

4.2 Data Flow Diagram(DFD):

A Data Flow Diagram (DFD) is a graphical representation of the "flow" of data
through an Information System. A data flow diagram can also be used for the
visualization of Data Processing. It is common practice for a designer to draw a
context-level DFD first which shows the interaction between the system and
outside entities. This context-level DFD is then "exploded" to show more detail of
the system being modeled.

A DFD represents flow of data through a system. Data flow diagrams are
commonly used during problem analysis. It views a system as a function that
transforms the input into desired output. A DFD shows movement of data through
the different transformations or processes in the system.

Dataflow diagrams can be used to provide the end user with a physical idea of
where the data they input ultimately has an effect upon the structure of the whole
system from order to dispatch to restock how any system is developed can be
determined through a dataflow diagram. The appropriate register saved in database
and maintained by appropriate authorities.
NOTATION DESCRIPTION

Processes or transform are represented

by circles in a DFD. This shows what
systems do. Each process has one or
more data inputs and produces one or
more data outputs. Each process has a
unique name which appear inside the
circle that represent the process in a
DFD.

The rectangle Is used to represent an

external entity, that is a system element
or another system that produces
information for transaction by the
software or receives the information
produced by the software.

An arrow represent one or data items or

data objects. A data flow shows the
flow of information from its source to
its destination.

A database is a holding place for

information within the system. It is
represented by cylindrical notation.
Data stores may be long-term files or
may be short-term.
4.2.1 Level 0:

Login Input
Admin/Operator Login
Database

Output

Fig 1.5 Level 0

2.2 Level 1(Top Level DFD):

Admin Login

Add Details Store

Admin Student Details Database
Edit Details
Data
SelectCourse
Course a Database
Admin
DeleteCourse
Store
SelectSubject
Admin Subject Database
DeleteSubject Data
a
Store
Stores
Admin Examination Database
Edit Details Data
Stores a e
Stor
Admin Attendance Database
Edit Details Data
Adds a e
Stor
Admin Semester Database
Delete Data
a

Fig 1.6 Level 1

4.2.3 Second Level DFD for Course and Subject:

Administrator
Stores in
Create operators

Operator
Add course Add
Course details
Retrieves

Add subject View Course

Subject

Subject
Fig 1.7 DFD for Course and Subject

4.2.4 Second Level DFD for Semester:

Upload student details Select course

Course
Operator

Student Details
Stores
Course
Select / student
update Update info
semester
details Student Details
Semester

Fig 1.8 DFD for Semester

4.2.5 Second Level DFD for Attendance:

Select course
Operator Course
View
Select semester
Course Details

Semester Select subject

Subject details
View

Add attendance
Subject
details

Attendance
Details Updates
Attendance

Attendance

Fig 1.9 DFD for Attendance

4.3 Description of components:
4.3.1 Functional component 1: Login

4.3.1.1 Input: Admin name and password.

4.3.1.2 Output: Allows administrator to enter into a new page.

4.3.1.3 File I/O interface: Functional components login when clicked after giving the username
and password correctly it takes us to a new page which is the home page, with other functional
components.

4.3.2 Functional component 2: Student details

4.3.2.1 Input: reg.no, first name, last name, dob, fathers name, sex, address, contact no, course,
semester.

4.3.2.2 Output: Details of each and every students.

4.3.2.3 File I/O interface: This module is not related to other functional components.

4.3.3 Functional component 3:Course details

4.3.3.1 Input: course id, course name, comment, course key.

4.3.3.2 Output: All the entered data will be stored in respective database and will be displayed in
the grid.

4.3.3.3 File I/O interface: This module is not related to other functional components.

4.3.4 Functional component 4:Subject details

4.3.4.1 Input: subject id, subject name, comment, course, subject type, semester.

4.3.4.2 Output: All the entered data will be stored in respective database and will be displayed in
the grid.

4.3.4.3 File I/O interface: This module is not related to other functional components.
4.3.5 Functional component 5:Examination details

4.3.5.1 Input: course, semester, internal type,marks.

4.3.5.2 Output: All the entered data will be stored in respective database and will be displayed in
the grid.

4.3.5.3 File I/O interface: This module is not related to other functional components.

4.3.6 Functional component 6:Attendance details

4.3.6.1 Input: course, semester, subject, total classes.

4.3.6.2 Output: All the entered data will be stored in respective database and will be displayed in
the grid.

4.3.6.3 File I/O interface: This module is not related to other functional components.
 Student Information System
Team code: 111201

Submitted by: Priya H J

(091540623)

Shruthi K

(091540643)

Submitted to: Mr. Vinayachandra

Department Of Computer Science

St.Philomena College, Puttur

External guidance by: Aravinda.M.V

Technopulse

City Light Building,

Balmatta Road, Mangalore – 575003

Date of submission: 06/01/2012