CHAPTER-2

SYSTEM ANALYSIS AND DESIGN

2.1 Physical Design

2.1.1 Block Diagram

2.1.2 Use Case Diagram

2.1.3 E-R Diagram

2.1.4 DFD

2.1.4.1 0-level

2.1.4.2 1-level

2.1.4.3 2-level

2.1.5 Flow Chart

2.2 Logical Design/ Database Design

 PHYSICAL DESIGN

Physical system produces the working systems by define the design specifications

that tell the programmers exactly what the candidate system must do. It includes the

following steps.

• Design the physical system.

• Specify input and output media.

• Design the database and specify backup procedures.

• Design physical information flow through the system and a physical design

Walk through.

• Plan system implementation.

• Determine procedures, courses and timetable.

 BLOCK DIAGRAM

A block diagram is a visual representation of a system that uses simple, labeled

blocks that represent single or multiple items, entities or concepts, connected by

lines to show relationships between them. Block diagrams are a generalized

representation of a concept and are not intended to display complete information in

regard to design or manufacture. Unlike schematics, blueprints and layout diagrams,

block diagrams do not portray the necessary detail for physical construction. Block

diagrams are made simple so as not to cloud concepts.

Faculty management system Block diagram describes the structure of a faculty

management system classes, their attribute, operations, and the relationship among

objects. The main classes of the faculty management system are leave, faculty,

student, teacher, course, subject.

Daily Entry Check Salary

Subjects Database Teachers

Admin
Add Teachers

Add
subjects UpdateTeacher
Check Time- Details
Report
Table
Update
Subjects
Delete Details

Weekly Consolidate
 USE CASE DIAGRAM

Use case diagrams are usually referred to as behavior diagrams used to describe a set of

actions (use cases) that some system or systems can perform in collaboration with one or

more external users of the system (actors). Each use case should provide some observable

and valuable result to the actors of the system.

Use case diagrams are used to specify:

• (external) requirements, required usages of a software under design or analysis - to

capture what the software is supposed to do;

• the functionality offered by a software – what the software can do;

• requirements the specified software poses on its environment - by defining how

environment should interact with the software so that it will be able to perform its

services.

This Use Case Diagram is a graphic depiction of the interactions among the element

of faculty management system. It represents the methodology used in system

analysis to identify, clarify, and organize system requirements of faculty

management system. The main actor of faculty management system in this Use

Case Diagram are: super admin, system user, Faculty, who perform the different

type of use cases such as manage leave, manage faculty, manage student, manage

timecard, manage teacher, manage course, manage subject, manage users and full
faculty management system operation. Major elements of the UML use case

diagram of Faculty Management System are shown on the picture below

 Apply for Leave
Manage Faculty

Check Salary

(Admin)
Login

Update Profile

Change Password
(Database)

Check Attendance Manage Leave

(System

User)
Print Salary Slip Manage Courses
a

Check Timetables
 E-R DIAGRAM

An entity-relationship diagram (ERD) is a data modelling technique that graphically

illustrates an information system’s entities and the relationships between those

entities. An ERD is a conceptual and representational model of data used to

represent the entity framework infrastructure.

The elements of an ERD are:

• Entities

• Relationships

• Attributes

Steps involved in creating an ERD include:

1. Identifying and defining the entities

2. Determining all interactions between the entities

3. Analyzing the nature of interactions/determining the cardinality of the

relationships

4. Creating the ERD

Faculty Management System entities and attributes:

• Leave Entity: Attributes of leave are Leave_id, leave_employee, leave_type,

leave_status, leave_to, leave_from, leave_description.

• Faculty Entity: Attribute of faculty are faculty_id, faculty_teacher_id,

faculty_name, faculty_room, faculty_type, faculty_description.

• Student Entity: Attribute of student are student_id:int, student_college_id:int,

student_name:string, student_mobile:int, student_email:string,

student_address:string, student_username:string,

student_password:string.
• Teacher Entity: Attribute of teacher are teacher_id, teacher_exam_id,

teacher_name, teacher_mobile, teacher_email, teacher_username,

teacher_password, teacher_address.

• Course Entity: Attributes of course are course_id, course_student_id,

course_registration, course_name, course_type, course_year,

course_description.

Subject Entity: Attribute of subject are subject_id, subject_course_id,

subject_student_id, subject_name, subject_type, subject_description.

Login Usernam
#Login role id e
id

Password
LOGIN

Userna #user_id #Roll_id

me

U_mobile USERS HAS ROLES Roll_na

me

U_email
Roll Desc
U_address
#per_id

Per_roll_id

Permission
Per_mod
ule

Per_Name

Manage

Lv_ID
#S_id S_add
Sub_std_id
Lv_Desc
S_Name Leave
#sub_id
Lv_type
Student
Subject
S_Mobile
Sub_na
Lv_emp_id
me

S_Email S_Pass Sub_type Sub_desc

HAS

FACUILTY
Fac_desc

#Fac_id Fac_Type
 DATA FLOW DIAGRAM (DFD)

DFD graphically representing the functions, or processes, which capture,

manipulate, store, and distribute data between a system and its environment

and between components of a system. The visual representation makes it a

good communication tool between User and System designer. Structure of

DFD allows starting from a broad overview and expand it to a hierarchy of

detailed diagrams. DFD has often been used due to the following reasons:

• Logical information flow of the system

• Determination of physical system construction requirements

• Simplicity of notation

• Establishment of manual and automated systems requirements

Faculty management system Data flow diagram is often used as a preliminary

step to create an over view of the faculty management without going into

great detail, which can later be elaborated. It normally consist of overall

application dataflow and processes of the faculty management process. It

contains all of the userflow and their entities such all the flow of leave, faculty,

student, timecard, teacher, course, subject. All of the below diagram has been

used for visualization of data processing and structured design of the faculty

management process and working flow

 Zero Level Data Flow Diagram (0 level DFD) Faculty Management
System

This is the Zero Level DFD of faculty management system, where we have
elaborated the high level process of faculty management. It’s basic overview
of the whole faculty management system or process being analysed or
modeled. It’s designed to be at a glance view of teacher, course and subject
showing the system as a single high level process, with its relationship to its
external entities of leave, faculty and student. It should be easilye understood
by a wide audience including leave, student and teacher in Zero level DFD of
faculty management system, we have describe the high level flow of the
faculty management system.

High Level Entities and Process Flow of faculty management system:

• Managing all the leave
• Managing all the faculty
• Managing all the student
• Managing all the timecard
• Managing all the teacher
• Managing all the course
• Managing all the subject

Time Card
Management

Salary Management
Leave
Management Faculty
Managemet
System System User
Faculty
Management
Management

Login
Management
 First Level Data Flow Diagram (1st level DFD) Faculty

Management System
First level DFD of faculty management system shows how the system is

divided into sub system , each of which deals with one or more of the data

flows to or from an external agent, and which together provide all of the

functionality of the faculty management system as whole. It also identify

internal data stores of subject, course, teacher, timecard, student that must be

present in order for the faculty management system to do its job and show the

flow of data between the various parts of the leave, student, course, subject,

teacher of the system. DFD Level 1 provides more detail breakdown pieces of

the 1st level DFD.

first level

Admin

Faculty
management
system

Login

faculty students

Voter Candidate
Database Database
 Second Level Data Flow Diagram (2nd level DFD) Faculty

Management System

DFD Level 2 then goes one step deeper into parts of Level 1 of faculty

management system. It may require more functionalities of faculty

management functioning. First Level DFD of faculty management shows how

the system is divided into sub system. The 2nd level DFD contains more detail

of subject, course, teacher, timecard, student, faculty, leave.

Second level

Forgot
Password

Admin

Login

Manage Report

faculty’s
Details Class’s
edetial
students’s Details
Details

Add Delete
Update Delete
Data Data
Data Data
Delete Add Update
Data Data Data
Add Update
Data Data

faculty’s Database
class’s Database
students’s Database

Data Fetching
Data Fetching
Data Fetching
 FLOW CHART

Admin is registered

Admin

Login ID and password

Check
Invalid
Login ID
Login/password
Password

Login to the system

successfully

Set userlevel and

permission

Access the internal

functionalities
according to
permission
 LOGICAL DESIGN/DATABSE DESIGN

- The details of Leave are store into the leave tables respective with all tables

- Each entity (Subject, Student, Course, Faculty, Leave) contains primary key and

unique keys.

- The entity student, course has binded with leave, faculty entities with foreign key.

- There is one-to-one and one-to-many relationships available between course,

teacher, subject, leave.

- All the entities leave, course, student, subject, are normalized and reduce duplicacy
of records.

- We have implemented indexing on each tables of Faculty Management System

tables for fast query execution.

Database Design:

Leave Entity

Leave_ Leave_emp Leae_ty Leav_stat Leave_fr Leave_ Leave_descrip

id _id pe us om to tion

Faculty Entity

Faculty Faculty_teach Faculty_na Faculty_ro Faculty_t Faculty_descri

_id er_id me om ype ption

 Student Entity

Student Student_colle Student_n Student_m Student_e Student_add

_id ge_id ame obile mail ress

Teacher Entity

Teacher Teacher_n Teacher_m Teacher_e Teacher_add Teacher_user

_id ame obile mail ress name

Course Entity

Course_ Course_na Course_y Course_studen Course_descrip Course_ty

id me ear t_id tion pe

Subject Entity

Subject_id Subject_course_id Subject_student_id Subject_name Subject_type Su

ject
 CHAPTER 3
SUMMARY
CHAPTER 1
Our project is only a humble venture to satisfy the needs to manage their project
work. Several user-friendly coding has also adopted. This package shall prove to be
powerful package in satisfying all the requirements of the school. The objective of
software planning is to provide a framework that enables the manager to make
reasonable estimate made within a limited time frame at the beginning of the
software project and should be updated regularly as the project progresses.

At the end we have concluded that we have made efforts on followings: -

➢ At first, we define the problem on which we are working in the project. We

have described the system that has been in use. Then we figure out problem

in the following system and figure out that system in early use was not

advance as compare to the systems now a days being use. Also, we increase

the trans piracy between institution and the faculty members.

➢ Then we had described purpose, objective, aim and scope of our project. Our

objective was to manage faculty, students, lectures and leaves properly and

our purpose was to make the system friendlier for both administration and for

the faculty to use. Our aim was to make the system perform all the CRUD

operation. In scope we describe all the module or function that are being to be

made in the software.

➢ After that we have describe the model or the type of system we are working

upon, to which we have decided to use waterfall system. In this we are

following an order where first we are going to analyse the requirement, then

designing, then coding, then testing and at last maintenance.

 ➢ At last we have analysed our requirements (software and hardware) that we

will be needed to prepare the faculty management system. In this we have

decide that we are required 7 software and 6 hardware to make the program.

CHAPTER 2
In second chapter we discussed about physical design ,where we discuss whole

structure and the flow and connectivity between front end user and back end user

with the help of block diagram, use case diagram, E.R diagram, D.F.D diagram, flow

chart and logic design.

➢ Block diagram:
Block diagram describes the structure of a faculty management system

classes, their attribute, operations, and the relationship among objects. The

main classes of the faculty management system are leave, faculty, student,

teacher, course, subject.

➢ Use case diagram:

It represents the methodology used in system analysis to identify,

clarify, and organize system requirements of faculty management system.

➢ E.R. diagram:
An ERD is a conceptual and representational model of data used to

represent the entity framework infrastructure.

➢ D.F.D diagram:
Faculty management system Data flow diagram is often used as a

preliminary step to create an over view of the faculty management without

going into great detail, which can later be elaborated. It normally consist of

overall application dataflow and processes of tELOhe faculty management

process. It contains all of the userflow and their entities such all the flow of

leave, faculty, student, timecard, teacher, course, subject.

➢ Flow chart

A flowchart is a type of diagram that represents an algorithm, workflow or

process. The flowchart shows the steps as boxes of various kinds, and their

order by connecting the boxes with arrows. This diagrammatic representation

illustrates a solution model to a given problem.

➢ Logical design:

A logical design is a conceptual, abstract design. You do not deal with the

physical implementation details yet; you deal only with defining the types of

information that you need. The process of logical design involves arranging

data into a series of logical relationships called entities and attributes.

 FACULTY
MANAGEMENT
SYSTEM
SOFTWARE DEVELOPMENT SKILLS