intelligent routine generator

SWERMS

Intelligent Routine Generator

BY

SHAHRAJ KHAN

ID. 103-35-143

MD. FARHAD HOSSAIN APU

ID 103-35-146

This Report Presented in Partial Fulfillment of the Requirements for the Degree of

Bachelor of Science in Software Engineering

Supervised By

MD. MIJANUR RAHMAN

Assistant Professor

Department of SWE Daffodil International University

DAFFODIL INTERNATIONAL UNIVERSITY

DHAKA, BANGLADESH

SEPTEMBER 2015

APPROVAL

This Project titled “SWERMS Intelligent Routine Generator”, submitted by Shahraj Khan, Md.

Farhad Hossain to the Department of Software Engineering, Daffodil International University, has

been accepted as satisfactory for the partial fulfillment of the requirements for the degree of B.Sc.

in Software Engineering and approved as to its style and contents.

BOARD OF EXAMINERS

Dr. Touhid Bhuiyan

Prof & Department Head Internal Examiner

Department of SWE Faculty of Science & Information Technology Daffodil International University

Md. Mijanur Rahman Assistant Professor Internal Examiner

Department of SWE Faculty of Science & Information Technology

Daffodil International University

Dr. Md. Rezaul Karim Professor External Examiner

Department of Computer Science & Engineering University of Dhaka Dhaka, Bangladesh

DECLARATION

We hereby declare that, this project has been done by us under the supervision of MD. MIJANUR

RAHMAN, Assistant Professor, Department of SWE Daffodil International University. We also

declare that neither this project nor any part of this project has been submitted elsewhere for award of any degree or diploma.

Supervised by:

Md. Mijanur Rahman Assistant Professor


Submitted by:

Shahraj Khan

ID: 103-35-143


Md. Farhad Hossain Apu

ID: 103-35-146 Department of SWE

Daffodil International University

Acknowledgement

“Success is to be measured not so much by the position that one has reached

in life, but as by the obstacle which he has had to overcome while trying to succeed.” In many ways it is, more difficult to acknowledge one’s but we express my deep sense of gratitude to each and every one whose support and co-operation helped me

to complete this project successfully, and without it the completion of this project would ever have been easier. We hereby take the pleasure of thanking my project

Advisor. We have truly benefited a lot from the constructive critics and suggestions given us by Md. Mijanur Rahman. Here are some special thanks to few special

people whose co-operation made this work really special. We also wish to thank our parents who always stand by us in our all decisions and without their help it was not

possible for us to reach at this place.

At last but not least we are very grateful to almighty Allah who provides meth energy and stamina to do some creative work which can help people doing their work

efficiently and with ease.

Abstract

Routines are the backbone of daily classroom life. They facilitate teaching and

learning. Routines don’t just make educational time easier, they save valuable classroom time. And what are most important, efficient routines make it easier for

students to learn and achieve more and helps the organization to operate smoothly. Most of the routines are being generated manually with help of third party software like ms excel, adobe pdf writer etc. Routines are also hand written. Generating

routine manually for a large organization always a crucial and complicated task. There are lots of problems being faced by the management, to generate an efficient

routine.

Proposed “SWERMS” routine management system will be perfect application for

generating routine automatically with all problems in mind. “SWERMS” will generate complete routines for any educational organizations. It will also generate

individual routines for sections/batches, individual routines for teacher & also helps the managements to maintain subjects, sections & teachers properly.

TABLE OF CONTENTS

Content Page

Approval………………………………………………………………………….

Declaration………………………………………………………………………..

Organogram………………………………………………………………………

Acknowledgement………………………………………………………………..

Abstract ………………………………………………………………………………………

II

III

IV

V

VI

1. Chapter One……………………………………………………………….. 1

1.1. Introduction……………………………………………………………………………. 1

1.2. Project Life Cycle ……………………………………………………………………. 2

1.2.1. Project initiation

1.2.2. Project execution

1.2.3. Project deployment

1.3. Objective of the Module……………………………………………………………… 3

1.4. Methodology…………………………………………………………………………. 4

1.5. System Development Life-Cycle…………………………………………………….. 4

1.6. Stack holders………………………………………………………………………… 5

2. Chapter Two: Project Execution and Analysis…………………………. 6

2.1. System Analysis……………………………………………………………………… 6

2.1.1. What is Routine Management?

2.1.2. Existing System

2.1.3. Propose System

2.1.4. Reasons of the changes and major expected benefits

2.2. Fact Finding Technique………………………………………………………………. 7

2.2.1. Interviews Structures

2.2.2. Observation

2.3. Project Phase analysis………………………………………………………… 8

2.3.1. Phase 1: Analysis the requirements of the project

2.3.1.1.1. Requirement Analysis

2.3.1.1.2. The method of collecting requirements

2.3.2. Phase 2: Module Analysis

2.3.3. Phase3: Develop Modules

2.3.4. Phase 4: Integrate Modules

2.3.5. Phase5: Test, bug finding and bug fixing

2.3.6. Phase 6: Use of the software

3. Chapter Three: System Design Model………………………………….... 11

3.1. Introduction…………………………………………………………………………… 11

3.1.1. Normal User

3.1.2. Administrator

3.2. Major web technologies used in the system…………………………………………. 11

3.2.1. About the design tools

3.2.1.1. PHP

3.2.1.2. MySQL

3.2.1.3. HTML

3.2.1.4. CSS

3.2.2. PHP + MySQL

3.2.3. Apache

3.3. Use case model…………………………………………………………………………

14

4. Chapter Fore: Software requirement specification (SRS)……………… 16

4.1. Functional Requirements…………………………………………………………….. 16

4.2. Non- Functional Requirements………………………………………………………. 18

4.3. State Transition Diagram……………………………………………………………. 20

4.4. ERD Diagram................................................................................................................ 21

4.5. DFD Context Diagram……………………………………………………………….. 22

4.6. Data modeling Diagram………………………………………………………………. 23

5. Chapter Five: Software layout…………………………………………… 24

5.1. How to Use…………………………………………………………………………… 24

5.2. LogIn………………………………………………………………………………….. 26

5.2.1. Phase 1…………………………………………………………………… 26

5.2.1.1. step1

5.2.1.2. step2

5.2.1.3. step3

5.2.2. Phase 2……………………………………………………………………. 29

5.2.2.1. Step1: Room management

5.2.2.2. Step2: Teacher management

5.2.2.3. Step3: Course management

5.2.2.4. Step4: Create normal routine

5.2.2.5. Step5: Create specialized routine

6. Chapter six: Design and Implantation…………………………………... 41

6.1. Project overview……………………………………………………………………… 41

6.2. Risks and control……………………………………………………………………... 41

6.3. Schedule and planning………………………………………………………………... 41

6.4. Gantt chart……………………………………………………………………………. 42

7. Chapter seven: Testing…………………………………………………… 43

7.1. Testing……………………………………………………………………………….. 43

7.2. Characteristics of good test………………………………………………………….. 44

7.3. Testing techniques…………………………………………………………………… 44

7.4. Test plan……………………………………………………………………………… 45

7.5. Taste case report…………………………………………………………………….. 45

8. Chapter eight: ……………………………………………………………. 54

8.1. Discussion…………………………………………………………………………… 54

8.2. Conclusion…………………………………………………………………………… 54

References………………………………………………………………………. 55

LIST OF FIGURES

CONTENT PAGE

Figure1: Agile model………………………………………………………………………….

Figure2: Use case diagram……………………………………………………………………

Figure3: State transition diagram………………………….…………………………………..

Figure4: ERD diagram of proposed…………………………………………………………..

Figure5: DFD Context diagram……………………………………………………………….

Figure6: Data modeling diagram……………………………………………………………...

Figure7: Application Interface………………………………………………………………..

Figure8: Application login success interface…………………………………………………

Figure9: select department……………………………………………………………………

Figure10: Department settings………………………………………………………………..

Figure11: department settings all of steps…………………………………………………….

Figure12: student management………………………………………………………………..

Figure13: student management all of steps…………………………………………………...

Figure14: Routine manual…………………………………………………………………….

Figure15: Room management………………………………………………………………...

Figure16: Room list, add room, edit room and delete room………………………………….

Figure17: Teacher management………………………………………………………………

Figure18: Teacher list with initial, off days, dept. and color ID……………….……………..

Figure19: Add, edit and delete teacher………..…………………..…………………………..

Figure20: Course Management process………………………………………………………

Figure21: Courses list with ID, name, type, teacher initial, term and section…………..…….

Figure22: Course list for individual semester………………………………………………...

4

15

20

21

22

23

25

26

27

27

28

28

29

30

30

31

32

32

33

34

34

35

Figure23: Add, Delete course name, delete course, delete course for selected term…………

Figure24: Add courses, Edit courses Information…………………………………………….

Figure25: Routine……………………………………………………………………………..

Figure26: Create specialized process…………………………………………………………

Figure27: color marks routine for all sections………………………………………………..

Figure28: color marks routine for all teachers………………………………………………..

Figure29: color marks routine for particular section………………………………………….

Figure30: color marks routine for particular teacher………………………………………….

Figure31: individual routine for sections/branch……………………………………………..

Figure32: individual routine for teacher………………………………………………………

Figure33: Gantt chart………………………………………………………………………….

35

36

37

38

38

39

39

40

40

40

42

CHAPTER 1

INTRODUCTION

1.1 Introductions:

Computer, the blessing of the modern world has been casing our day-to-day work

in various ways. The new inventions of cutting-edge hardware making the

computer system more powerful and computer software are utilizing this power to

make things easier for modern world. For this reasons our institution “Daffodil

International University (DIU)” want to make software, which is “University

Automation for DIU”.

Now we are in the age of automation. In this age, we feel the importance of

automation in all steps of daily jobs. We are trying to develop an automation

system which will provide lots of facilities to our University. The total automation

system divided into many modules , here our parts is “SWE Routine Management

System” .This is a small part of total automation System but The Routine

Management Section creates an environment which facilitate teachers, students and

everybody by the management of time scheduling. With the flow of development

we are going to introduce an on line Routine Management System that can be helpful

for our University. This online “SWERMS Intelligent Routine Generator”

intended to be our semester project Daffodil International University (DIU) under

the integrated project name “SWE Routine Management system” in care of Mr. Md.

Mijanur Rahman, senior lecturer, department of SWE, faculty of FSIT.

1.2 Project Life Cycle: The project life cycle includes various development phases

that occur in the life of project starting right from the inception of the project to its

final development at the client’s end. The three development phases in a project life

cycle are;

Project initiation

Project execution

Project deployment

1.2.1 Project initiation:

The project initiation phase is first phase of life cycle. This phase involves creating

a complete plan for the project, specifying various activities that will be performed

and assigning responsibilities to team members on the basis of their skill set.

1.2.2 Project execution:

After the project plan is made and the responsibilities assigned, the actual

development of the project starts. The phase in which the actual development of the

project takes place is known as the project execution phase. This is the most crucial

phase of any project and is subdivided into the following phases;

1. System analysis:

• Initial study

• Information gathering

• Feasibility study

2. System design:

• Design standard

• High level design & design tools

• Database design

• Logical design

• Construction

3. System implementation:

• integration & testing

• post implementation

1.2.3 Project development:

After the project execution phase, the final phase of a project life cycle is the project

development phase. In this phase, the deployed at the client side. This phase also

involves providing customer support to the client for some specified period of time.

When project is built it may possibly remain error les of more, because several type

of modification can take place several times. So for the very first time when we run

the database we found few problems in tools portions. We fixed this problem

including some minor problems immediately, and afterwards the application runs

properly.

1.3 Objective of the Module:

To make a proper time schedule for each of the department of our University, Which

is very much helpful for our teachers, students and all of the facilities?

To make a fully dynamic Routine.

To make a dynamic routine this is faster than the manual routine system.

We tried to make a dynamic routine which is error free.

We tried to make a dynamic routine which is user friendly.

Understand ethical & professional issues, which are important for software

engineering.

To learned methods of producing software in organized way.

1.4 Methodology:

Methodology is a collection of procedure, techniques, tools and documentation aids

that help the system development in their effort to implement a new information

system.

The proposed methodology is planned to meet the objective of Routine Management

System of DIU in an effective way.

1.5 System Development Life-Cycle:

Agile development model is also a type of Incremental model. Software is developed

in incremental, rapid cycles. This results in small incremental releases with each

release building on previous functionality. Each release is thoroughly tested to

ensure software quality is maintained. It is used for time critical

applications. Extreme Programming (XP) is currently one of the most well-known

agile development life cycle models.

Figure1: Agile model.

1.6. Stack holders

1. Teacher

2. Student

3. Coordinator

4. Department head

5. Guardian

6. University management body

7. Labe in charge

8. Hosing operator

http://istqbexamcertification.com/what-is-incremental-model-advantages-disadvantages-and-when-to-use-it/

http://istqbexamcertification.com/why-is-testing-necessary/

http://istqbexamcertification.com/what-is-software-quality/

http://istqbexamcertification.com/what-are-the-software-development-models/

CHAPTER 2

PROJECT EXECUTION AND ANALYSIS

2.1 System Analysis:

In this part we discuss all of the query and problem of the routine Management

system and try to finding the solution.

2.1.1 What is Routine Management?

Routine management simply means the proper management of any type of work or

resource used in an organization, that means which way the organization run, which

protocol it maintain and why, what is its time schedule etc.

Each and every Organization must follow a routine because, to complete their total

tasks in a sequential way .This process make all types of work so much easier

because it maintain a schedule. It makes all types of work faster.

2.1.2 Existing System:

Currently there is no such automated system exists like “SWERMS” that can

intelligently generate routine automatically. Although there is few system exists

those can help generate routine manually but not automatically.

2.1.3 Propose System:

But now we want to do it automatically. This will be so easier for Whole

University and it has some advantages as follows:

Dynamic System

Errors free

User Friendly

2.1.4 Reasons of the changes and major expected benefits:

In our university the courses are fixed, it is not easy to make a routine properly

because this process is done manually so it is not well developed and it is very slow,

and lost many time to make a routine. And in this manual system we must consider

all the information about our students, teachers and classrooms etc but when we try

to get the information instantly about anything like classroom availability or

teacher’s availability is not easy.

So present Routine Management system has many obligations and it cannot be easy

and time consume. If we can establish automation for Routine management system

we can able to remove most of the problem.

2.2 Fact Finding Technique:

In order to develop the process model of the new system at first the system analysis

the requirement analysis of the proposed system had to be done. During system

analysis and requirement analysis of our SWE Routine Management System we

have taken the following fact finding Techniques

Interviewing

Observation

2.2.1 Interviews Structures:

Our goal is to implement to a new system and to overcome the drawbacks of the

existing system. That’s way we have to go through an interview process which will

give necessary information about the project requirements and help to solve a

problems as well as fulfill in the user requirements

For this purpose we have to select the project to be interviewed as an interviewer we

must give priority to the users those who are involved with our Routine Management

System. In this regard, we discussed with them about our proposed Routine

Management System and wanted to know about the problems of existing Routine

Management System. We will also try to collect their opinions about the

development of our system, which will help us including new system or add new

features.

2.2.2 Observation:

As the student of DIU we were already familiar with some existing procedure. Yet

we communicated with the administrative level personnel to know all the specific

activities as stated.

• How the information are stored

• How the teacher information are stored

• How the subject information are stored

• How they store multiple tasks information’s

• what type of permission exist among the relations

2.3 Project Phase analysis:

Project phases

we divided our whole work of the project into the following developing phases.

2.3.1 Phase 1: Analysis the requirements of the project.

In this phase we basically analysis the requirements and develop our knowledge on

demand. We will sort out all the necessary tools that will be needed. We will grow

up the technological background to make workable the software in all environment

facilities.

2.3.1.1 Requirement Analysis:

We should need to analyze for the routine management the following things—

A teacher can take only one class at a time.

We must need to know the number of student for the individual Batch or

Semester

We need to consider how many class rooms are there and we must need to

know the capacity of the room.

We should need to arrange some common class which are similar for both

(SWE & CSE)

We should need to conscious about individual subjects credits which is not

equal for the different subjects. (Such as 4 credit course, 3 credit course).

The time duration of the different class will be different for their varying

different credit hours

2.3.1.2 The method of collecting requirements:

Every room must be used on every time slot.

No overlap for section/batch.

No continues class (more then 2) for each section/batch.

No overlap for teacher.

No continues class (more then 2) for teachers.

Lab class always is assigned to lab room & theory class always assigned

in normal room.

Class for each section/batch will not be assigned for more than 4 days a

week.

Not more than one class will be assigned for each subject in a day.

Each day, at least 2 slots will be reserved for emergency classes

2.3.2 Phase 2: Module Analysis:

In this phase we will analyses our module and fragment the overall module

in some small modules. Which help us to complete total system easily?

2.3.3 Phase3: Develop Modules:

We will make the task flow and code flow of each module in this phase. We

will write the row code to build up the modules.

2.3.4 Phase 4: Integrate Modules:

In this phase we will integrate all modules. The backbone of the software

will stand up in this phase and the software will be useable.

2.3.5 Phase5: Test, bug finding and bug fixing:

We will test the overall features of the software. By testing the features we

will find out the bugs. After that all the bugs will be solved.

2.3.6Phase 6: Use of the software:

This software will be use for Our University Automation System for routine

management

CHAPTER 3

SYSTEM DESIGN MODEL

3.1 System Design Model:

In our “SWERMS Intelligent Routine Generator” there are two types of User

models are shown

these are:

1. Student

2. Administrator

3. Major web technologies used in the system

3.1.1 Student:

A regular user is any kind of user like students, parents or anybody who uses the

system and can see the routine and get some information about the routine or time

schedule.

3.1.2 Administrator:

An admin user is a selected user who has the permissions to create a new routine or

edit the routine. The admin user also viewing the routine and get some information.

3.2 Major web technologies used in the system:

HTML, HTML Editor, Browser (Internet Explorer, Google chrome, Mozilla etc).

Client Side and Server Side Scripting:

1. PHP

2. Javascript

3. HTML

4. CSS

Database Used as Back End:

MySQL

Web Server Used:

Apache

3.2.1 About the Design Tools

3.2.1.1 PHP

PHP stands for PHP: Hypertext Preprocessor

PHP is a server-side scripting language, like ASP

PHP scripts are executed on the server

PHP supports many databases (MySQL, Informix, Oracle, Sybase, Solid,

PostgreSQL, Generic ODBC, etc.)

PHP is an open source software (OSS)

PHP is free to download and use

PHP files may contain text, HTML tags and scripts

PHP files are returned to the browser as plain HTML

PHP files have a file extension of ".php", ".php3", or ".phtml"

PHP runs on different platforms (Windows, Linux, UNIX, etc.)

PHP is compatible with almost all servers used today (Apache, IIS, etc.)

PHP is FREE to download from the official PHP resource:

http://www.php.net/

PHP is easy to learn and runs efficiently on the server side

3.2.1.2 MySQL:

MySQL is a small database server

MySQL is ideal for small and medium applications

MySQL supports standard SQL

MySQL compiles on a number of platforms

MySQL is free to download and use

3.2.1.3 HTML

The explosive growth of the World Wide Web is relatively unprecedented, although

it resembles the desktop publishing revolution of the early and mid-1980s. As

personal computers became more common in homes and offices, people began to

learn to use them for document creation and page layout. Although early word

processing programs were not terribly intuitive and often required memorizing

bizarre codes, people still picked them up fairly easily and managed to create their

own in-house publications.

Suddenly, the same kind of growth is being seen as folks rush to create and publish

pages of a different sort. To do this, they need to learn to use something called the

Hypertext Mark-up Language (HTML).

The HTML standard is maintained and debated by a group called the HTML

Working Group, which, in turn, is a creation of the Internet Engineering Task Force.

The Working Group was charged in 1994 with the task of defining the HTML

standard that was in widespread use on the Web at the time (known as HTML 2.0),

and then submitting proposals for future standards, including the HTML 5.0

standard.

3.3.1.4 CSS

Cascading Style Sheets (CSS) is a style sheet language used for describing the look

and formatting of a document written in markup. Although most often used to change

the style of web pages and user interfaces written in HTML and XHTML, the

language can be applied to any kind of XML document, including plain

XML, SVG and XUL. Along with HTML and JavaScript, CSS is a cornerstone

technology used by most websites to create visually engaging webpages, user

interfaces for web applications, and user interfaces for many mobile applications.

CSS is designed primarily to enable the separation of document content from

document presentation, including elements such as the layout, colors, and fonts. This

separation can improve content accessibility, provide more flexibility and control in

the specification of presentation characteristics, and enable multiple HTML pages to

share formatting by specifying the relevant CSS in a separate. CSS file, and reduce

complexity and repetition in the structural content, such as semantically insignificant

tables that were widely used to format pages before consistent CSS rendering was

available in all major browsers.

https://en.wikipedia.org/wiki/Style_sheet_language

https://en.wikipedia.org/wiki/Presentation_semantics

https://en.wikipedia.org/wiki/Presentation_semantics

https://en.wikipedia.org/wiki/Web_page

https://en.wikipedia.org/wiki/HTML

https://en.wikipedia.org/wiki/XHTML

https://en.wikipedia.org/wiki/XML

https://en.wikipedia.org/wiki/Plain_Old_XML

https://en.wikipedia.org/wiki/Plain_Old_XML

https://en.wikipedia.org/wiki/Scalable_Vector_Graphics

https://en.wikipedia.org/wiki/XUL

https://en.wikipedia.org/wiki/JavaScript

https://en.wikipedia.org/wiki/Web_applications

https://en.wikipedia.org/wiki/Separation_of_presentation_and_content

https://en.wikipedia.org/wiki/Separation_of_presentation_and_content

https://en.wikipedia.org/wiki/Page_layout

https://en.wikipedia.org/wiki/Color

https://en.wikipedia.org/wiki/Typeface

https://en.wikipedia.org/wiki/Accessibility

3.2.2 PHP + MySQL

PHP combined with MySQL are cross-platform (means that you can develop in

Windows and serve on a UNIX platform)

3.2.3 Apache

Apache is an HTTP server, originally designed for UNIX systems. This is the

version of Apache for Microsoft Windows 2000, NT, 98, and 95 systems. Like the

UNIX version, it includes many frequently requested new features, and has an API

that allows it to be extended to meet users' needs more easily. It also allows limited

support for ISAPI extensions.

Apache performs best, and is still most reliable on UNIX platforms. Over time the

performance, reliability and security for the Apache Win32 port has improved, and

continues to improve. Folks doing comparative reviews of web server performance

are still asked to compare against Apache running on a UNIX platform such as

Solaris, FreeBSD, or Linux.

3.3 Use case model

Overview of the use cases model of our proposed system “SWERMS Intelligent

Routine Generator”.

Figure2: Use case diagram of proposed SWERMS Intelligent Routine Generator

CHAPTER 4

SOFTWARE REQUIREMENT SPECIFICATION

4.1Functional Requirements:-

Requirement

no

Requireme

nt type

Details Priority

1. Functional System will have separate login panel for

students and admins and students can be

registered from registration page but admin

cannot be registered from UI.

High

2. Functional After successfully logged in students can

view routine for their respective departments.

High

3. Functional Students can also view their respective

courses and teachers.

Medium

4. Functional After successfully logged in admins can

access all admin pages.

High

5. Functional From student management menu admins can

view all registered students and also can edit

student’s information and delete any student

from the system.

High

6. Functional From Department management menu admins

can view all saved departments, add new

department, edit any department’s

information and also can delete any

departments.

High

7. Functional From Department selection page admins can

access routine management pages for any

department.

High

8. Functional From Room management menu admins can

add new rooms, view rooms, edit room info

and delete rooms for selected departments.

High

9. Functional From Teacher management menu admins can

add new teacher, view all teachers, edit

teacher info and delete teachers for selected

departments.

High

10. Functional From subject management menu admins can

add new subjects, view all subjects, edit

subject info and delete subjects for selected

departments.

High

11. Functional Admin can create/generate standard routine

for all sections/batches and teachers.

High

12. Functional System will generate color marked routine

for all sections/batches and teachers,

individual section/batch, individual teacher,

when routine update is required.

Medium

13. Functional Admin can also generate individual routine

for sections/batches and teachers based on

original routine.

High

14. Functional Admins can update/edit system generated

routine, store updated routine and also can

delete stored routines.

Medium

15. Functional Admins can view routine manual for using

the system.

Low

4.2Non-functional Requirements:-

Requirement

no

Requiremen

t type

Details Priority

1. Non-

functional

Proper room management, Every room must

be used on every time slot when generating

routine.

High

2. Non-

functional

No overlap for section/batch on any time

slot.

High

3. Non-

functional

Not more than 2 continue class will be

assigned for sections/batches.

High

4. Non-

functional

No overlap for teachers on any time slot. High

5. Non-

functional

Not more than 2 continues class will be

assigned for teachers.

High

6. Non-

functional

Theory class always be assigned to general

room and lab class always be assigned in lab

room.

High

7. Non-

functional

Class for each section/batch will not be

assigned for more than 4 days a week.

High

8. Non-

functional

Not more than one class will be assigned for

each subject in a day.

High

9. Non-

functional

Required class for any subjects

(Theory/Lab) will be assigned properly in

the routine.

High

10. Non-

functional

Extra slots will be generated automatically

for other/emergency classes.

High

11. Non-

functional

System will be user friendly to all kind of

user. (Admin and students).

Medium

12. Non-

functional

Browser friendly. (Should be working

properly in all windows OS without losing

functionality and performance).

Medium

13. Non-

functional

Faster loading capability. (Take shorter time

to load).

Medium

14. Non-

functional

Should be capable of handling large amount

of data without losing performance.

High

15. Non-

functional

Secured Database. (Sensitive information

must be safe from being hacked).

High

16. Non-

functional

Well-designed eye friendly user interface. Low

17. Non-

functional

Admin and user can excess additional web

page related to the “SWERMS” from the

system.

Medium

18. Non-

functional

SWERMS can be used from any device (PC,

Tab, and Smartphones).

Low

19. Non-

functional

All dynamic pages of the system will have

auto redirecting feature (when needed).

Medium

20. Non-

functional

All inputs of the “SWERMS” will have

proper validation before processing.

High

4.3 State Transition Diagram:

Figure3: State transition diagram

4.4 ERD Diagram:

Figure4: ERD diagram of proposed SWERMS Intelligent Routine Generator

4.5 DFD Context Diagram:

Figure5: DFD Context diagram of proposed SWERMS Intelligent Routine Generator

4.6 Data modeling Diagram:

Figure6: Data modeling diagram of proposed SWERMS Intelligent Routine Generator

CHAPTER 5

SOFTWARE LAYOUT

In this portion we describe the using process of the software.

5.1 How to Use

There are several options for using this “SWERMS Intelligent Routine

Generator”. The Input and Output of the section on this project are given bellow:

LogIn

Category Search

Insert information

Update Information

Delete

View

Log out

Figure7: Application Interface

5.2 LogIn

5.2.0 Output page (if login success):

5.2.1 Phase 1:

After signing in the administrator option the admin can do all type of access for

editing or updating the Department & student management.

Figure8: Application login success interface.

5.2.1.1 Step 1:

Figure9: select department.

5.2.1.2 Step 2:

Figure10: Department settings.

5.2.1.2.1

Figure11: department settings all of steps.

5.2.1.3 Step 3:

Figure12: student management

5.2.1.3.1

Figure13: student management all of steps.

5.2.2 Phase 2:

After completing the input Data an administrator easily can make a routine what

he/she wants.

In this part the administrative user select those data which essential for particular

department and particular semester which already inserted in data base.

Figure14: Routine manual.

5.2.2.1 Step 1: Room management:

In this step if the administrator thinks in the database there are some unnecessary

information he/she can view, add, edit and delete the information from the database

by using the following steps:

Figure15: Room management

Figure16: Room list, add room, edit room and delete room.

5.2.2.2 Step 2: Teacher Management:


information he/she can or this page will be display when we want to view, add, edit

and delete the information from the database by using the following steps:

Figure17:

Teacher management

Figure18: Teacher list with initial, off days, dept. and color ID.

Figure19: Add, edit and delete teacher.

5.2.2.3 Step 3: Course Management:


information he/she can or this page will be display when we want to add courses

name, view all course, add new course, edit course info, delete course, view distinct

course, delete courses name and delete all courses for selected term the information

from the database by using the following steps:

Figure20:

Course Management process.

Figure21: Courses list with ID, name, type, teacher initial, term and section.

Figure22: Course list for individual semester.

Figure23: Add, Delete course name, delete course, delete course for selected term.

Figure24: Add courses, Edit courses Information

5.2.2.4 Step 4: Create Normal routine:

After completing the input Data an administrator easily can make a routine what

he/she wants.

In this part the administrative user select those data which essential for particular

department and particular semester which already inserted in data base.

And then submit the data. After submitting a routine will be shown below:

Figure25: Routine

5.2.2.5 Step 5: Create Specialized Routine:

If the administrators think there is some problem in any routine he/she easily can

drop the routine for particular day or whole routine at a time.

In this step if the administrator thinks then he/she can or this page will be display

when we wants to color marks routine for all sections & teachers, color marks routine

for particular section & teacher and individual routine for sections/branch & teachers

by using the following steps:

Figure26: Create specialized process

Figure27: color marks routine for all sections.

Figure28: color marks routine for all teachers.

Figure29: color marks routine for particular section.

Figure30: color marks routine for particular teacher.

Figure31: individual routine for sections/branch

Figure32: individual routine for teacher.

CHAPTER 6

DESIGN AND IMPLEMENTATION

6.1. Project overview SWREMS intelligent routine generator system has followings stage:

6.1.1. Student movement:

View registered student list

Change student information’s

Delete student from system

6.1.2. Department settings:

View department list

Add new department

Change department information’s

Delete department

6.1.3. Main component:

Routine manual

Routine management

Teacher management

Course management

Create normal routine

Create specialized routine

Miscellaneous options

6.2. Risks and control As “SWERMS” is a completely web application. So it is has security issue.

Always it need to be secured from hacking. During development we added several security protection.

6.3. Schedule and planning Software project planning goal is to establish a pragmatic strategy for

controlling, tracking and monitoring a complex technical project. The purpose of project planning is to ensure that the end result is completed on time, within budget and exhibits quality. In this process we are arrange our

project plan.

Deliverables Submission date comment

SRS 08/07/2013 Complete on time

Logical design 12/10/2013 Submit on time Physical design 01/07/2014 Live in online

testing 11/10/2014 Add on final documentation Final documentation 20/10/2014 Complete on time

Table SCHEDULE AND PLANNING

6.4. SCHEDULE AND PLANNING (GANTT CHART):

We use Gantt chart for SWERMS. For planning and schedule we use Microsoft

project manager professional 2013.

Figure33: Gantt chart.

CHAPTER 7 TESTING

7.1. Testing:

Software testing involves more than just running a program to see whether it works.

A single test run reveals nothing about the program other than the obvious fact that

it can yield results for a particular set of inputs. Software testing should be treated

as an investigative exercise; one which systematically uncovers different classes of

errors within the code while demonstrating that the software behaves as expected.

Software testing is very much concern about two specific term validation and

verification. Validation process asks the question: Are we building the right

product? And on the other hand Verification process asks the question: Are we

building the product right?

Implementation is the process of completing the system and turning it over to the

user. The phase in the software life-cycle where the actual software is implemented.

The result of this phase consists of source code, together with documentation to

make the code more readable. This chapter discusses site preparation,

documentation preparation, personnel training, system cutover, and system release.

The developers’ concept of the definition and objectives of software testing plays

a major role in determining the efficacy of the activity. It influences the developers’

decision on what should be tested, and judgment on what is considered a

`successful’ test.

7.2. Characteristics of Good Test

An excellent test case satisfies the following criteria:

It has a reasonable probability of catching an error

You test to find errors. When searching for ideas for test cases, try working backwards from an idea of how the program might fail. If the program could

fail in this way, how could you catch it?

It is not redundant

If two tests look for same error, why run both?

It’s the best of its breed

In a group of similar tests, one can be more effective than the others; you

want the best of the breed, the one most likely to find the error.

It is neither too simple nor too complex

You can save testing time by combining two or more tests into one test case. But

don’t create a monster that’s too complicated to execute or understand or that takes

too much time to create. It’s often more efficient to run simpler tests. Be cautious

when combining invalid inputs. After rejecting the first invalid value, the program

might ignore all other further input, valid or not. At some point, you might want to

combine error cases to see what the program does when confronted with many

disasters at once. However, you should start with simple tests to check each of the

program’s error-handling capabilities on its own.

7.3. Testing Techniques

Because of the fallibility of its human designers and its own abstract, complex

nature, software development must be accompanied by quality assurance activities.

It is not unusual for developers to spend 40% of the total project time on testing.

For life-critical software (e.g. flight control, reactor monitoring), testing can cost 3

to 5 times as much as all other activities combined. The destructive nature of testing

requires that the developer discard preconceived notions of the correctness of

his/her developed software. The results of the tests have to be documented.

Testing is about validation and verification. The documentation contains a

comprehensive testing on different modules; we have conducted the black box

testing for the selected modules. We have conducted the test with the valid and

invalid data.

7.4. Test plan:

Select the modules to be tested

Select the test data

Determine the expected results

Test the module using results

Determine the actual results

Compare expected and actual results

Test module selection and planning sequence

7.5. Taste case report:

A set of test inputs, execution condition and expected results developed for a

particular objective such as to exercise a particular program path or to verify

compliance with specific requirement.

The test cases of proposed system are described for each module.

Test module: 01- Output page (If login success)

Test case ID: 1.1

System: SWERMS

Designed by: Md. Farhad Hossain Apu

Executed by: Shahraj Khan

Short Description: Test the adman login success

Test case name: Login success

Subsystem: Login

Design Date: 12/10/13

Execution date:15/10/13

Pre-conditions

After signing in the administrator option the admin can do all type of access for editing or updating the

Department & student management.

The system display the system configuration status.

Phane1/steps Action Expected system

response

Pass/fail comment

Step1 Select department Choose the

department to enter

ok RESPONSIVE

Step2 Department settings Add new department ok RESPONSIVE

Post-conditions

Data update successfully.

Test case ID: 1.2

System: SWERMS



Short Description: Test the adman login success

Test case name: Login success

Subsystem: Login



Pre-conditions

After signing in the administrator option the admin can do all type of access for editing or updating the

Department & student management.



response

Pass/fail comment

Step 1 Student management(if

Student registered

complete)

Selected student to

permanently delete

from “SWERMS”

ok RESPONSIVE

Edit student

information

ok RESPONSIVE

View all student list ok RESPONSIVE

Post-conditions


Test module: o2- Output page (If login success)

Test case ID: 2.1

System: SWERMS



Short Description: Test the adman Data entry Process

Test case name: Data entry

Subsystem: Login



Pre-conditions

After completing the input Data an administrator easily can make a routine what he/she wants. In this part

the administrative user select those data which essential for particular department and particular semester

which already inserted in data base.



response

Pass/fail comment

Step1 Routine manual Click on button ok RESPONSIVE

Post-conditions


Test case ID: 2.2

System: SWERMS





Subsystem: Login



Pre-conditions






response

Pass/fail comment

Step1 Room management Add new room ok RESPONSIVE

Edit room ok RESPONSIVE

Delete room ok RESPONSIVE

View all rooms ok RESPONSIVE

Post-conditions


Test case ID: 2.3

System: SWERMS





Subsystem: Login



Pre-conditions






response

Pass/fail comment

Step 1 teacher management Add new teacher ok RESPONSIVE

View all teachers ok RESPONSIVE

Edit teachers info ok RESPONSIVE

Delete teacher ok RESPONSIVE

Post-conditions


Test case ID: 2.4

System: SWERMS





Subsystem: Login



Pre-conditions





Phane2/steps Action Expected system response Pass/fail comment

Step 1 Course management Add courses name ok RESPONSIVE

Delete courses name ok RESPONSIVE

View all courses ok RESPONSIVE

View distinct course ok RESPONSIVE

Add new course ok RESPONSIVE

Edit course info ok RESPONSIVE

Delete course ok RESPONSIVE

Delete all courses for

selected terms

ok RESPONSIVE

Post-conditions


Test case ID: 2.5

System: SWERMS





Subsystem: Login



Pre-conditions






response

Pass/fail comment

Step 1 Create normal routine Click on button ok RESPONSIVE

Post-conditions


Test case ID: 2.6

System: SWERMS





Subsystem: Login



Phane2/steps Action Expected system response Pass/fail comment

Step 1 Create

specialized

routine

Color marked routine for all

section

ok RESPONSIVE

Color marked routine for all

teacher

ok RESPONSIVE

Color marked routine for

particular section

ok RESPONSIVE

Color marked routine for

particular teacher

ok RESPONSIVE

Individual routine for

sections/batches

ok RESPONSIVE

Individual routine for teachers ok RESPONSIVE

Post-conditions


Pre-conditions





CHAPTER 8

CONCLUSION

8.1 Discussion:

After implementing and testing the database software we found that it almost

fulfilled all of the requirements of our abstract and system designing considerations.

The application is working smoothly for all its users, such as see the routine of any

department for particular semester. Adding teacher, subject/courses and assign room

information.

To write discussion phase we should make one thing clear at the very beginning-

although the l structure of a routine system is very complex, we took a professional

approach, and designed the project in the best possible way so that it could be used

instantly by any interested organization.

8.2 Conclusion:

Complex system like “SWERMS Intelligent Routine Generator” development is

a continuous process. In near future there is a plan that this system will be a complete

dynamic routine generating system. Reduce vulnerability Ultimate destination for

the user to generate and maintain routine very easily.

At the end of this project we hardly request to the faculties of Software Engineering

(SWE) to approve our project.

References:

Lan Somerville, “project planning”, software engineering Pearson education,

Update 8th edition, 1989-1992

Lan Somerville, “software implementation and testing”, software

engineering, Update 6th edition, 1995-1997

PHP by MD. Mijanur Rahman Sinha

HTML5, CSS by MD. Mijanur Rahman Sinha

https://www.wikipedia.org/

http://www.infosolz.com/school-routine-software.php

http://codecanyon.net/item/ice-advanced-school-management-

system/10452009

http://www.educationoasis.com/instruction/cm/routines.htm

http://teacher.scholastic.com/classroom_management_pictures/

http://soft-project.blogspot.com/2009/01/routine-management-system.html


https://www.wikipedia.org/

http://www.infosolz.com/school-routine-software.php

http://codecanyon.net/item/ice-advanced-school-management-system/10452009

http://codecanyon.net/item/ice-advanced-school-management-system/10452009

http://www.educationoasis.com/instruction/cm/routines.htm

http://teacher.scholastic.com/classroom_management_pictures/

