Project thesis management_system_in_context_of_iiuc

i | P a g e
International Islamic University Chittagong
Department of Computer Science and Engineering
A Project Report on
Project-Thesis Management System in Context of IIUC
Submitted by
MD Zahid Hasan Tuhin - C133073
Nayan Pal - C141005
Irfanul Karim - C141001
Supervised by
Dr. Abdul Kadar Muhammad Masum
Associate Professor
Dept. of CSE
International Islamic University Chittagong (IIUC)
______________________
Approval of the Supervisor

ii | P a g e
DECLARATION
We hereby announce that the system has been totally developed independently
under the steady supervision of Dr. Abdul kadar Muhammad Masum, Associate
Professor, Department of Computer Science and Engineering, International Islamic
University Chittagong. No section of the work encased in this task has been
submitted in help of any application for some other degree or capability of this or
some other college or organization of learning.
Signature of students:
______________________
(MD Zahid Hasan Tuhin )
______________________
(Nayan Pal)
______________________
(Irfanul Karim)

iii | P a g e
CERTIFICATE OF APPROVAL
The task entitled as "Project-Thesis Management System in Context of IIUC"
presented by MD Zahid Hasan Tuhi(C133073), Nayan Pal(C141005) and Irfanul
Karim(C141001), to the Department of Computer Science and Engineering (CSE)
of International Islamic University Chittagong (IIUC) has been acknowledged as
tasteful for the incomplete satisfaction of the prerequisites for the Degree of
Bachelor in Computer Science and Engineering.

iv | P a g e
DEDICATION
THIS PROJECT IS DEDICATED TO OUR PARENTS
&
ALL OF OUR LOVED ONES

v | P a g e
ACKNOWLEDGEMENT
At first, we are thankful to Almighty Allah(SWT), most gracious, more excusatory
for giving us enough strength to accomplish this project successfully. We would
like to express our best regards, deepest appreciation to our cherished and
honorable supervisor Dr. Abdul kadar Muhammad Masum, Associate Professor of
Dept. of CSE at International Islamic University Chittagong, for steady
supervision, motivating guidance, worthy suggestions and formative criticism
throughout whole epoch of our project work. We also express our best regards and
thanks to Mr Tanveer Ahsan, Associate Professor and chairman of Dept. of CSE
at International Islamic University Chittagong, for giving us convenience to do this
project

vi | P a g e
ABSTRACT
Our Project “Project-Thesis Management System in Context of IIUC” is deals
with thesis and project management. This is a web based system that can manage
thesis & project easily. We are the first in Bangladesh that going to use this type of
system to manage thesis and project. Our System focuses is to make easier
management system so that the students of our university can operate actions about
thesis/project spontaneously.

vii | P a g e
CONTENTS
DECLARATION---------------------------------------------------------------------------- II
CERTIFICATE OF APPROVAL---------------------------------------------------------III
DEDICATION------------------------------------------------------------------------------IV
ACKNOWLEDGEMENT------------------------------------------------------------------V
ABSTRACT---------------------------------------------------------------------------------VI
CHAPTER ONE------------------------------------------------------------------------------1
INTRODUCTION---------------------------------------------------------------------------1
1.1Objectives of the System-------------------------------------------------------------1
1.2 Overview of the present system----------------------------------------------------1
1.3 Proposed System----------------------------------------------------------------------1
1.4 Project Deliverables2
CHAPTER TWO-----------------------------------------------------------------------------3
LITARATURE REVIEW------------------------------------------------------------------3
2.1 Introduction---------------------------------------------------------------------------3
2.2 Review of Related Work------------------------------------------------------------3
2.3 Comparisons of our System--------------------------------------------------------4
2.4 Objectives of the study--------------------------------------------------------------4
CHAPTER THREE--------------------------------------------------------------------------5
METHODOLOGY--------------------------------------------------------------------------5
3.1 Necessity of the Methodology----------------------------------------------------------------------5
3.2 Software Development Life Cycle (SDLC) ------------------------------------------------------5
3.3 Feasibility Study--------------------------------------------------------------------------------------6
3.3.1 Technical Feasibility-------------------------------------------------------------------------------7

viii | P a g e
3.3.2 Economic Feasibility----------------------------------------------------------------------------7
3.3.3 Operational Feasibility--------------------------------------------------------------------------7
3.3.4 Schedule Feasibility-----------------------------------------------------------------------------8
3.4 Objects list of system------------------------------------------------------------------------------8
3.4.1 Method name of system------------------------------------------------------------------------8
3.4.2 Method Related Objects of system-----------------------------------------------------------8
CHAPTER FOUR-------------------------------------------------------------------------9
REQUIREMENT DEFINITON---------------------------------------------------------9
4.1 User list of system---------------------------------------------------------------------------------9
4.1.1 End User------------------------------------------------------------------------------------------9
4.1.2 Administrator ------------------------------------------------------------------------------------9
4.2 Functional Requirements of system-------------------------------------------------------------9
4.3 Interface Requirements of System--------------------------------------------------------------10
4.3.1 Hardware Requirements-----------------------------------------------------------------------10
4.3.2 Software Requirements------------------------------------------------------------------------10
CHAPTER FIVE--------------------------------------------------------------------------11
SYSTEM SPECIFICATION & DESIGN---------------------------------------------11
5.1 User Panel-------------------------------------------------------------------------------------------11
5.2 Admin Panel-----------------------------------------------------------------------------------------12
5.2.1 Team Dashboard----------------------------------------------------------------------------------12
5.3 Design Specification--------------------------------------------------------------------------------13
5.3.1 Use Case Diagram--------------------------------------------------------------------------------13
5.3.2 Use case--------------------------------------------------------------------------------------------13
5.3.3 Use Case Diagram Symbols---------------------------------------------------------------------13
5.3.4 Use Case Diagram--------------------------------------------------------------------------------15
5.4 Activity Diagram------------------------------------------------------------------------------------16
5.4.1 Activity Diagram Symbol------------------------------------------------------------------------16
5.4.2 Activity Diagram of System---------------------------------------------------------------------17
5.4.3 Sequence Diagram--------------------------------------------------------------------------------18

ix | P a g e
5.4.4 Sequence Diagram Symbols---------------------------------------------------------------------18
5.4.5 Sequence Diagram for Login--------------------------------------------------------------------19
5.4.6 Sequence Diagram for Student------------------------------------------------------------------20
5.4.7 Sequence Diagram for Teacher/Supervisors---------------------------------------------------21
5.4.8 Sequence Diagram for Admin-------------------------------------------------------------------22
5.5 Database Design--------------------------------------------------------------------------------------23
5.5.1 E-R Diagram--------------------------------------------------------------------------------------23
5.5.2 E-R Diagram Symbols---------------------------------------------------------------------------23
5.5.3 E-R Diagrams of Project Thesis Management System in Context of IIUC-----------24
5.5.4 E-R Diagram without Attributes----------------------------------------------------------------25
5.5.5 E-R Diagram with Attributes-------------------------------------------------------------------26
5.5.6 Normalized E-R Diagram-----------------------------------------------------------------------27
5.6 Data Flow Diagram----------------------------------------------------------------------------------28
5.6.1 Data Flow Diagram Symbols-------------------------------------------------------------------28
5.6.2 Context Diagram---------------------------------------------------------------------------------29
5.6.3 Level 0 Data Flow Diagram--------------------------------------------------------------------30
CHAPTER SIX----------------------------------------------------------------------------31
SOFTWARE DESIGN & TESTING---------------------------------------------------31
6.1 Tools Used in Design---------------------------------------------------------------31
6.1.1 Front End--------------------------------------------------------------------------31
6.1.2 Back end---------------------------------------------------------------------------31
6.1.3 Server------------------------------------------------------------------------------31
6.1.4 Editor------------------------------------------------------------------------------31
6.1.5 PHP--------------------------------------------------------------------------------31
6.1.6 MySQL----------------------------------------------------------------------------32
6.1.7 HTML-----------------------------------------------------------------------------32
6.1.8CSS 32
6.1.9 JAVASCRIPT---------------------------------------------------------------------32

x | P a g e
6.2 Logical Schema----------------------------------------------------------------------33
6.3 Tables of System----------------------------------------------------------------34-40
6.4 Testing---------------------------------------------------------------------------------41
6.4.1 Unit Testing-------------------------------------------------------------------------41
6.4.1.1 Test Plan--------------------------------------------------------------------------41
6.4.2 White Box Testing-----------------------------------------------------------------42
6.4.3 Black Box Testing-----------------------------------------------------------------43
6.4.3.1 Test Result-------------------------------------------------------------------------43
CHAPTER SEVEN
IMPLEMENTATION, MAINTENANCE & SECURITY----------------------44-69
CHAPTER EIGHT
SUMMARY & CONCLUSION
8.1 Summary--------------------------------------------------------------------------------70
8.2 Conclusion------------------------------------------------------------------------------70
8.3 Project outcomes-----------------------------------------------------------------------70
8.4 Project Limitations---------------------------------------------------------------------70
8.5 Future Plan------------------------------------------------------------------------------71
CHAPTER NINE
REFERENCES----------------------------------------------------------------------------------------------72

xi | P a g e
LIST OF FIGURES
Fig 3.1: Software Development Life Cycle (SDLC) -------------------------------------------------6
Fig 5.1: Use case diagram of “Project-Thesis Management System in Context of IIUC”-15
Fig 5.2: Activity diagram of “Project-Thesis Management System in Context of IIUC”—17
Fig 5.3: Sequence Diagram for Login-------------------------------------------------------------------19
Fig 5.4: Sequence Diagram for Student-----------------------------------------------------------------20
Fig 5.5: Sequence for Teachers/Supervisors------------------------------------------------------------21
Fig 5.6: Sequence Diagram for Admin------------------------------------------------------------------22
Fig 5.7: Entity Relationship Diagram Without Attributes--------------------------------------------25
Fig 5.8: Entity Relationship Diagram with Attributes-------------------------------------------------26
Fig 5.9: Normalized Entity Relationship Diagram-----------------------------------------------------27
Fig 5.10: Context Diagram--------------------------------------------------------------------------------29
Fig 5.11: Level 0 DFD-------------------------------------------------------------------------------------30
Fig 6.1: Black Box Testing--------------------------------------------------------------------------------43
Fig 6.2: Black Box Testing--------------------------------------------------------------------------------43
Fig 7.1: Login Page-----------------------------------------------------------------------------------------44
Fig 7.2: Student Registration------------------------------------------------------------------------------45
Fig 7.3: Teacher Registration-----------------------------------------------------------------------------46
Fig 7.4: Student Dashboard--------------------------------------------------------------------------------47
Fig 7.5: Teacher profile-------------------------------------------------------------------------------------48
Fig 7.6: Team Profile----------------------------------------------------------------------------------------49
Fig 7.7: Searching-----------------------------------------------------------------------------------------50
Fig 7.8: Request for Supervisor-------------------------------------------------------------------------50
Fig 7.9: Create Team--------------------------------------------------------------------------------------51
Fig 7.10: Show Team Request---------------------------------------------------------------------------51
Fig 7.11: Notification-------------------------------------------------------------------------------------53

xii | P a g e
Fig 7.12: Messaging--------------------------------------------------------------------------------------53
Fig 7.13: Student List------------------------------------------------------------------------------------54
Fig 7.14: Team task list----------------------------------------------------------------------------------54
Fig 7.15: Team Approval-------------------------------------------------------------------------------55
Fig 7.16: Team Dashboard -----------------------------------------------------------------------------56
Fig 7.17: File Upload and Messaging -----------------------------------------------------------------57
Fig 7.18: Student profile--------------------------------------------------------------------------------58
Fig 7.19: Student profile setting-----------------------------------------------------------------------59
Fig 7.20: Teacher Profile-------------------------------------------------------------------------------60
Fig 7.21: Teacher Publication--------------------------------------------------------------------------61
Fig 7.22: Update Teacher Profile----------------------------------------------------------------------62
Fig 7.23: Inbox-------------------------------------------------------------------------------------------63
Fig 7.23: Notice Board----------------------------------------------------------------------------------64
Fig 7.25: Assign batch-----------------------------------------------------------------------------------64
Fig 7.26: Team Limit------------------------------------------------------------------------------------65
Fig 7.27: Assign Admin---------------------------------------------------------------------------------65
Fig 7.28: Assign Admin---------------------------------------------------------------------------------66
Fig 7.29: Working Area---------------------------------------------------------------------------------67
Fig 7.30: Admin List------------------------------------------------------------------------------------67
Fig 7.31: Approve Student-----------------------------------------------------------------------------68
Fig 7.32: Team List-------------------------------------------------------------------------------------68
Fig 7.33: Assign to thesis committee-----------------------------------------------------------------69

xiii | P a g e
LIST OF FIGURES
Table 5.1: Entity Relationship Diagram Symbols-------------------------------------------------------23
Fig 5.2: Data Flow Diagram Symbols--------------------------------------------------------------------28
Table 6.3.1: student_profiles-------------------------------------------------------------------------------34
Table 6.3.2: permissions------------------------------------------------------------------------------------34
Table 6:3:3: tasks--------------------------------------------------------------------------------------------34
Table 6.3.4: team_task--------------------------------------------------------------------------------------35
Table 6.3.5: teacher_profiles-------------------------------------------------------------------------------35
Table 6.3.6 domains-----------------------------------------------------------------------------------------35
Table 6.3.7 domains-----------------------------------------------------------------------------------------35
Table 6.3.8: Users-------------------------------------------------------------------------------------------36
Table 6.3.9: Project_thesis---------------------------------------------------------------------------------36
Table 6.3.10: batches---------------------------------------------------------------------------------------37
Table 6.3.11: role_user-------------------------------------------------------------------------------------37
Table 6.3.12 Roles------------------------------------------------------------------------------------------37
Table 6.3.13 books------------------------------------------------------------------------------------------37
Table 6.3.14: message---------------------------------------------------------------------------------------38
Table 6.3.15 teams------------------------------------------------------------------------------------------38
Table 6.3.16: password_resets----------------------------------------------------------------------------38
Table 6.3.17: migrations-----------------------------------------------------------------------------------38
Table 6.3.18: quotas----------------------------------------------------------------------------------------39
Table 6.3.19: user_request--------------------------------------------------------------------------------39
Table 6.3.20: publications---------------------------------------------------------------------------------39
Table 6.3.21: permission_user----------------------------------------------------------------------------39
Table 6.3.22: files------------------------------------------------------------------------------------------40
Table 6.3.23: permission role----------------------------------------------------------------------------40

1 | P a g e
CHAPTER ONE
INTRODUCTION
“Project-Thesis Management System in Context of IIUC” is a platform that where our
teachers, supervisors and students can manage thesis or project related process easily. In this
system teacher, supervisor and students have different module. These particular modules manage
particular issue based on their access in the system. This platform gives up the opportunity to
interact teachers and students easily with each other. They can share their idea also. It gives
opportunity to select supervisor or select student for final thesis or project. This platform builds
interaction so that thesis-project management in the department can be easier for teachers and
students both.
1.1 Objectives of the System
The main objective of this system to make easy project & thesis management on the context of
Dept. of CSE, IIUC. The system has also following objectives-
• To amalgamate all of our respected teachers and students in a common platform that
research process of our dept can be easier.
• To increase the communication between supervisor and students which makes the
project/thesis management faster.
• To store our teacher workings records and interests so that a student can easily find their
supervisor according to his interest field.
1.2 Overview of the present system
Actually this type of project/thesis management system does not use by any university. We the
first in Bangladesh are going to use this type of project/thesis management software to handle
project/thesis management in our university. Most of the university in Bangladesh handle this
project/thesis management manually which is very complex and take more time. In the present
system perspective a student has to collaborate with teacher physically, has to wait for the
decision of teacher, has to searching the interest area of teachers who are matched according to
his research interest.
1.3 Proposed system
The Proposed System is a web based project thesis management system that which handle all
actions that to complete project/thesis from start to end. The system has separate profile for
teachers and students. There is a head admin who has overall access of this system. Students can
login in the system and get limited access in this system as he need like requesting to a teacher,
sending request to create a team etc. Teachers have multi-access in the system like approval of
team, rejecting of a student request, accepting of a student request etc. Most attractive feature
that student and teacher can collaborate with each other by messaging them through the system.

2 | P a g e
1.4 Project Deliverables
• Our “Project-Thesis Management System in context of IIUC” is created for taking
every measure to make the thesis/project process more informative.
• It is developed for making the existing process faster and accurate.
• It gives continuous data which is required whenever and anyplace.
• Collaborate with teachers and students for making a decent administration for its users.
• Easy to use interface so that students and teachers can easily manage this software.

3 | P a g e
CHAPTER TWO
LITERATURE REVIEW
2.1 Introduction
A literature review is a critical and in depth evaluation of previous work It is a rundown and
outline of a specific region of work, permitting anyone investigating the framework to build up
why you are seeking after this specific work. A decent writing audit develops the purposes for
choosing a specific work question. Writing audit isn't just an ordered inventory of every one of
your sources, however an assessment. All sides of a contention must be obviously clarified, to
maintain a strategic distance from inclination, and territories of understanding and contradiction
ought to be featured. A review may casing and essential bit of the examination system or may
contain an investigation adventure in itself. In the going with composing study we will discuss
some present system which are for the most part like our framework.
In this segment we will make a correlation of the accompanying system with our system. In the
past segment we saw that the system has issues with different substance, for example, proposal
framework, correspondence and so forth.
2.2 Review of Related Work
Before building up our system, we had considered few systems which are halfway identified
with our system. There is a system which is partially common of our system but features are
different.
UMEXPERT Review:
UMEXPERT is an academic portal of the University of Malaya. Students can search to find their
teachers in the system if student want to know about a specific teacher. Every teacher has
personal profile which is decorated with his recent publications, publish books, his research
interest, his personal info like email etc. There are four types of searching available in the
UMEXPERT. User can search based on name, expertise area, publications and research which
makes this system more user friendly. There are there specific portion of home page of this
portal represents recent applications, publication date and latest awarded grant. Recent
publications part consists of all publications of university teachers whose publish recently. As a
result it is possible to look all publications at a glance. Similarly publication date portion
represents all of pares publication date.
Login button is the gate for entering into internal system. To log into the system user must be
provide valid id and password. This feature ensures the security of this system. It also proved
that without valid person an anonymous person can not enter into the system. Using this system
teacher can partially monitoring the students not fully. By using this system teachers can see the
progress of students belonging with him/her.
Finally, UMEXPERT used as an official portal of University of Malaya and after login into
system it also helps to partially monitoring of student.

4 | P a g e
2.3 Comparisons of our System
UMEXPERT is the portal of the University of Malaya. It represents all information about
students and teachers. On the contrary our system is created based on project thesis management
system of our department. There are partially common features of two systems . The common
features are searching based on specific keyword, publication records, personal profiles of every
teachers. This profile consists of personal information of teachers, his publication records, his
interest area, his expertise area etc.
UMEXPERT cannot operate mandatory monitoring on students. On the contrary our system can
operate every major issues of project/thesis management of the students and teachers. This
system also represents as a portal which consists of all information about project/thesis. Because
all information about project/thesis can be find in the system. Using this system a supervisor can
monitor his team, can operate with student, share important resources with students.
UMEXPERT has not these features.
Finally this system can be used as an portal about project/thesis related issues and it also used as
the monitoring software for handling all project/project management.
2.4 Objectives of the study
• To provide security in the system.
• To make user friendly system.
• To provide best monitoring system about project/thesis management.
• To overcome the constraints of existing system.
• To give best service to the user.
• To find out the problems that whose should be solved.
• To get best output.

5 | P a g e
CHAPTER THREE
METHODOLOGY
A Methodology refers to planning, structuring of works and controlling the procedures of
building up a system. To make programming, engineers need to seek after some framework. In
our endeavor we seek System Development Life Cycle (SDLC) approach. Since using this
methodology we can do our function admirably requested and arranged quickly. System
Development Life Cycle (SDLC) is a strategy of perceiving how a structure can be maintained if
business needs, plan the system, making it and passing on it to customers. It fuses five phases
which are:
• Planning
• Analysis
• Design Physical
• Design Logical Design
• Implementation
• Maintenance.
3.1 Necessity of the Methodology
Picking methodology is one of the main choices you'll need to make as a task chief. Distinctive
venture the board systems have their very own advantages and disadvantages for various task
types. Some are intended for speed, some for extensiveness. Approach is required for
programming so it makes with limit. We will demonstrate a levelheadedness which contains the
techniques for stirring up our errand subordinate upon proposed framework. To build this
“Project-Thesis Management System in Context of IIUC” we also require a approach and
System Development Life Cycle (SDLC) is the best approach.
3.2 Software Development Life Cycle (SDLC)
The software development life cycle (SDLC) is a structure characterizing undertakings
performed at each progression in the software development process. SDLC is a structure pursued
by an advancement group inside the product association. It comprises of plan arrangement
portraying how to create, keep up and supplant explicit programming. The existence cycle
characterizes a procedure for enhancing the nature of programming and the general advancement
process. For “Project-Thesis Management System in Context of IIUC” we pursue SDLC to make
explicit for the users.

6 | P a g e
Fig 3.1 : Software Development Life Cycle (SDLC)
3.3 Feasibility Study
A feasibility study is an analysis used in measuring the ability and likelihood to complete a
project successfully including all relevant factors. It must account for factors that affect it such as
economic, technological, legal and scheduling factors. Examination and delivering
considerations in regards to another structure does this.
Adventures in attainability examination:
• For an undertaking group.
• Create framework flowchart.
• Enumerate potential proposed framework.
• Defined and assess execution and financially savvy of each proposed framework. Select
best proposed framework.
• Prepare and report last task direct to the executives.

7 | P a g e
3.3.1 Technical Feasibility
Investigations of assets accessibility that may influence the capacity accomplish an adequate
system. The technical needs of the system may include:
Front end determination
• Feasibility
• Robustness
• Easy to investigate and keep up
• Must have a GUI that helps client who isn't from IT foundation.
• Scalability and extensibility
We have chosen HTML, CSS, JavaScript, JQuery and Bootstrap as our front end.
Back end determination
• Efficiently information taking care of
• Efficient information recovery and support
• Easy to introduce
• Compatible
We have chosen PHP(Laravel), MySQL as our back end.
3.3.2 Economic Feasibility
For any system if the normal advantages rise to or surpass the normal costs, the system can be
made a decision to be monetarily achievable. In economic feasibility, cost benefit analysis is
done in which expected expense and advantages are assessed. Economic analysis is used for
assessing the viability of the proposed system. In economic feasibility, the most essential is Cost
advantage examination. As the name recommends, it is an examination of the expenses to be
brought about in the framework and advantages logical out of the system.
3.3.3 Operational Feasibility
Operational feasibility is mainly concerned with issues like whether the system will be used if it
is developed and implemented. It alludes to the proportion of taking care of issues with the
assistance of another proposed system. It helps in exploiting the chances and satisfies the
prerequisites as recognized amid the improvement of the task. It takes care that the
administration and the user support the project.

8 | P a g e
3.3.4 Schedule Feasibility
A time feasibility study will take into account the period in which the project is going to take upto its
completion. A project will fail it takes too long to be in any way finished before it is helpful.
Regularly this implies assessing to what extent the system will take to create, and on the off
chance that it very well may be finished in a given timespan utilizing a few techniques like
recompense period. Schedule feasibility is a proportion of how sensible the task timetable is. Our
system Schedule feasibility is exact time accommodation of the framework.
3.4 Objects list of system
Objects allude to cases of class that used to decorate of our system and programs.
• Latest Web Browser
• Documents(Files)
• Software
• User
• Administrator
3.4.1 Method name of system
• Login
• Registration
• Selection
• Validity Checking
• Approval
• Generating Notifications
• Uploading Documents
• Messaging
• Monitoring team progress
• Multi Authentication
• Progress monitoring
3.4.2 Method Related Objects of system
• Approval is related with administrator and user in this system.
• Selection is linked with administrator and user in this system.
• Uploading Documents related with Documents in this system.
• Multi Authentication is linked with administrator and user in this system.
• Login and registration are linked with administrator and user in this system.
• Messaging is linked with user.
• Team progress is linked with user.

9 | P a g e
CHAPTER FOUR
REQUIREMENT DEFINITON
Requirement definition is the critical component of every project implementation, irrespective of
project type, i.e. a new system development or re-engineering of an existing one It envelops the
undertakings to address business issues by thinking about the prerequisites from related partners
for the framework. Necessity definition must guarantee that prerequisites are noteworthy,
quantifiable and testable as requirements. Customarily, necessities were characterized before
framework advancement. Be that as it may, the benefits of the "assess and-adjust" approach have
resulted in businesses now shifting towards an agile methodology in software development.
4.1 User list of system
Users are two types in this system-
• End User
• Administrator
4.1.1 End User
User can added into the system by login. He should be register to get all features. User can store
their documents and share with each other. User can produce request based on his needs like for
creating a team or find team member he can send team request. In order to collaborate user can
chatting with each other. Features of end users are limited in this system. User can also maintain
and manage his own files.
4.1.2 Administrator
Most of the features of this system are accessible by admin. Admin can add team member, user,
assign a user different roles. Admin can provide approval decisions whose are created by end
user. Admin can take any action against anybody at any time at this system. Admin can generate
the progress bar of a specific task. Administrator can maintain the software efficiently. Finally
admin can maintain overall activity of the systems.
4.2 Functional Requirements of system
The software must supply following functionalities:
• User can share documents.
• User can download documents.
• User can communicate with each other by messaging.
• User can listed as a member of this system by registration.
• User can delete unnecessary documents.
• User can search as he need.
• Admin select the valid user.
• Admin approve the sued request.
• Admin can assign user in different roles in the system if need.
• Admin can generate add, delete, edit operation.
• User can generate add and delete but he can not edit.

10 | P a g e
4.3 Interface Requirements of System
4.3.1 Hardware Requirements
Processor Disk Ram
Pentium II, Pentium III,
Pentium IV and higher
100 MB 50 MB or Higher
Table: 4.1 Hardware requirements
4.3.2 Software Requirements
Database Operating System
MySQL Windows XP, Windows 7, Windows 8.1, Windows
10,LINUX or any other Operating System.
Table: 4.2 Software requirements
.

11 | P a g e
CHAPTER FIVE
SYSTEM SPECIFICATION & DESIGN
A system specification describes the detailed statement of the effects that a system is required to
achieve. A good specification gives a total statement of what the system is to do, without making
any responsibility regarding how the system is to do it. The system detail is made after the
system prerequisite archives. It gives more subtleties data and activities about those elements that
whose are portrayed in the system prerequisites area. Ordinarily, the practical determination for
an application program with a progression of intelligent windows and exchanges with a client
would demonstrate the visual appearance of the UI and portray every one of the possible user
input activities and the program reaction activities. Functional specification describes about the
functionalities but it does not describe about the actions of implementation.
5.1 User Panel
In this segment we observe observes students as users.
Login: User has to provide his valid id and password to enter into the system.
Registration: New users can registration or sign up in this segment.
Search: User can search based on specific area in this segment.
Team: In this page user can get all news and actions button to perform any action about team.
Create Team: In this page user can create a team to fill up a form that which takes all necessary
information to create a team from user.
My Team: In this page user can see about his team.
All Team: This page represents all team lists.
Student Lists: This page show all the student lists.
Teachers Info: This page have two subpage like Teacher Lists and Thesis-Committee member.
Teacher lists: In this page user can see all the teachers.
Thesis Committee Member: This page shows the thesis committee members information.
Notice: In this page user can see all the notices.
Notification: If user has any notification user can see it from this page.
Message: User can collaborate with each other by using this page.
Profile: It shows the user personal profile.
Settings: Using this page user can edit his personal information.
Working Field: This page contains some article about the different types of working topics.
Download Media: User can download necessary documents.
Upload Media: In this page user can upload necessary files.

12 | P a g e
5.2 Admin Panel
Team Approval: Admin and Thesis committee can approve a team after from supervisor.
Student Approval: Final Approval of a student done by Admin. After verifying student can
access the system.
Teacher Approval: Admin will approve user as a teacher. As a result teacher can access specific
features in the system.
Assigning role: Admin can set the roles of a user. Admin can assign teacher in thesis committee
and in admin panel.
Add Notice: Admin can add valuable notice in the system.
Control Registration Process: Admin can control the registration process of the system.
Control Team Limit: Admin can set team limit against to supervisor for a specific batch.
Create Teacher Working Domain: Admin can add the working area of teachers.
Monitoring team: Admin and thesis committee can monitor of a team progress and assigned the
team in the next stage based on its performance.
5.2.1 Team Dashboard
Show team details: Team members can show members details of his/her team, team members
also can see the team progress.
Upload Media: Team members can upload media files.
Group Message: For collaborating with each other team members can message others.
Approve Status: Team members can see the approve status of the team.

13 | P a g e
5.3 Design Specification
Design Specifications describe how a system performs the requirements outlined in the
Functional Requirements. Depending on the system,, this can incorporate guidelines on testing
explicit prerequisites, arrangement settings, or survey of capacities or code. All necessities laid
out in the practical detail ought to be tended to.
Great necessities are objective and testable. Structure Specifications may include::
Specific inputs, including information types, to be gone into the framework
•Calculations/code used to achieve characterized prerequisites
•Outputs produced from the framework
•Explaining specialized measures to guarantee framework security
•Identify how the framework meets material administrative necessities
5.3.1 Use Case Diagram
A Use Case Diagram (UML) at its simplest is a representation of a user's interaction with the
system that shows the relationship between the user and the different use cases in which the user
is involved. A use case diagram can distinguish the distinctive kinds of clients of a framework
and the diverse use cases and will regularly be joined by different sorts of charts too. The use
cases are spoken to by either circles or ovals. A use-case diagram can help give a larger amount
perspective of the framework. It has been said before that "Use case diagrams are the diagrams
for your system". They give the improved and graphical portrayal of what the system should
really do.
5.3.2 Use Case
A use case is a methodology used in system analysis to identify, clarify, and organize system
requirements. The use case is comprised of a lot of conceivable successions of communications
among system and users in a specific domain and identified with a specific objective. It
comprises of a gathering of components (for instance, classes and interfaces) that can be utilized
together such that will have an impact bigger than the entirety of the different components
consolidated.
5.3.3 Use Case Diagram Symbols
Actors: An actor portrays any entity (or entities) that perform certain roles in a given system.
The different roles the actor represents are the actual business roles of users in a given system.
An actor in a use case diagram interacts with a use case.

14 | P a g e
Package: Package is used to group elements, and to provide a namespace for the grouped
elements.
Use Case: Use case is a list of steps, typically defining relations between an actor and a system,
to achieve a goal.
Notes: Notes have comments or textual information.

15 | P a g e
5.3.4 Use Case Diagram
Use Case Diagram describes all using cases of admin, students, teachers & supervisors of system
Fig 5.1: Use case diagram of “Project-Thesis Management System in Context of IIUC

16 | P a g e
5.4 Activity Diagram
Activity diagrams are graphical representations of workflows of stepwise activities and actions
with support for choice, iteration and concurrency. In the Unified Modeling Language, activity
diagrams are proposed to demonstrate both computational and authoritative procedures (i.e.,
work processes), as well as the data flows crossing with the related exercises. Although activity
diagrams primarily show the overall flow of control, they can also include elements showing the
flow of data between activities through one or more data stores.
5.4.1 Activity Diagram Symbols
Start Symbol: Used to represent the starting point or the initial state of an activity.
Activity Symbol: Used to represent the activities of the process.
Connector Symbol: Used to represent the flow of control from one action to the other.
End Symbol: Used to mark the end of all control flows within the activity.
Decision Symbol: This symbol is represented with a diamond shape, which represents branching
of control flows.

17 | P a g e
5.4.2 Activity Diagram of System
User has to first login or registration in the system. After checking validity there are three
segment such as Student, Teacher or Admin. Accessibility of users depends on his role in the
system. Student has limited accessibility. Admin can access every feature in this system.
Fig 5.2: Activity diagram of “Project-Thesis Management System in Context of IIUC”

18 | P a g e
5.4.3 Sequence Diagram
Sequence Diagrams are interaction diagrams that detail how operations are carried out. They
catch the cooperation between articles with regards to a joint effort. Sequence Diagrams are time
center and they demonstrate the request of the connection outwardly by utilizing the vertical hub
of the outline to speak to time what messages are sent and when
5.4.4 Sequence Diagram Symbols
Objects: Objects that are involved in interactions are placed on the x-axis. Objects are senders
and receivers of messages in the sequence diagram.
Lifeline Symbol: Represents the passage of time as it extends downward. This dashed vertical
line demonstrates the successive occasions that jump out at an article outline procedure.
Activation Box: Activation boxes represent the time an object needs to complete a task. At the
point when an article is caught up with executing a procedure or sitting tight for an answer
message, utilize a thin dark square shape set vertically on its helps.
Messages: There are different types of messages in the sequence diagram.

19 | P a g e
Synchronous Message: It's usually drawn using a line with a solid arrowhead pointing from one
object to another.
Asynchronous Message: Asynchronous messages don't need a reply for interaction to continue.
Like synchronous messages.
5.4.5 Sequence Diagram for Login
To access in system user must be follow some sequences. At the beginning user must be login in
the system to access the features. There are three types of login such as StudentLogin,
TeacherLogin and AdminLogin. If the user can not provide valid information it shows error
message.
Fig 5.3: Sequence Diagram for Login

20 | P a g e
5.4.6 Sequence Diagram for Student
Student has to fill up some sequential page to perform his action properly in the system. After
registration and login he has to decorate his profile. Completing the profile functionality student
has to request for selecting supervisors, team creation, topic selection etc.
Fig 5.4: Sequence Diagram for Student

21 | P a g e
5.4.7 Sequence Diagram for Teachers/supervisors
Teacher has to be registered to access as a teacher to get specific features for teachers. Teachers
must be provide information about his research interest to get request from students topic
selection. Teacher will be assign as a supervisor after approval of a student.
Fig 5.5: Sequence for Teachers/Supervisors

22 | P a g e
5.4.8 Sequence Diagram for Admin
Admin has to perform some actions sequentially. Admin will generate notice for users. Admin
finally assign a teacher as a supervisor against of teams. Admin will provide final approval of a
research team with supervisor. Admin can manage students that whose are not get any team and
supervisor yet.
Fig 5.6: Sequence Diagram for Admin

23 | P a g e
5.5 Database Design
Database Design is a collection of processes that facilitate the designing, development,
implementation and maintenance of enterprise data management systems. It helps create
database system that meet the necessities of the clients have superior. The primary targets of
database planning are to deliver intelligent and physical structures models of the proposed
database system.
5.5.1 E-R Diagram
E-R Diagram stands for Entity Relationship Diagram (ERD). An Entity Relationship Diagram
(ERD), otherwise called an element relationship demonstrate, is a graphical portrayal of a data
framework that delineates the connections among individuals, objects, spots, ideas or occasions
inside that framework. An ERD is an information demonstrating procedure that can help
characterize business forms and be utilized as the establishment for a social database.
5.5.2 E-R Diagram Symbols
Table 5.1: Entity Relationship Diagram Symbols

24 | P a g e
5.5.3 E-R Diagrams of Project Thesis-Project Management System in Context of IIUC
Attributes: Attributes of E-R Diagram are- id,user_id, role_id, permission_id, team_id,
teacher_id, student_id, migration, batch, gender, address, photo, password,cell_no,created_date,
update_date, created_at, updated_at, display_name, token, user_type, activation_code, status,
project_name, description, title, file, message, docum, varsity_id etc.
Entities: Entities of E-R Diagram are permission_role, migration, teacher_profile, roles,
permission, users, password_resets, teams, team_profile, permission_user, role_user, notice,
student_profiles, project_thesis, message, tagged_messages, Tags.
Relationship type: Relationship Types are set, create, do, view, can, see.

25 | P a g e
5.5.4 E-R Diagram without Attributes
In this diagram represents about the relationship between entities and entity types of this system.
From this diagram reviewer can specify clear relationship entities and entity types.
Fig 5.7: Entity Relationship Diagram Without Attributes

26 | P a g e
5.5.5 E-R Diagram With Attributes
Attributes are the properties of entities. Attributes are represented by means of ellipses. Every
ellipse represents one attribute and is directly connected to its entity (rectangle). ERD with
attributes represent connections of attributes with diagram.
Fig 5.8: Entity Relationship Diagram with Attributes

27 | P a g e
5.5.6 Normalized E-R Diagram
Normalization is a mechanistic approach, based on the set theory underlying normalization, to
achieving normalized data. The weakness is that inexperienced users apply it without fully
understanding the context of the data ‘the business rules’. ERD is a more top down approach
based on the business rules but which delivers normalized data.
Fig 5.9: Normalized Entity Relationship Diagram

28 | P a g e
5.6 Data Flow Diagram
A data flow diagram (DFD) maps out the flow of information for any process or system. It
utilizes characterized images like square shapes, circles and bolts, in addition to short content
names, to demonstrate information inputs, yields, stockpiling focuses and the courses between
every goal. Information flowcharts can extend from straightforward, even hand-drawn process
reviews, to inside and out, staggered DFDs that dive logically more profound into how the
information is dealt with. They can be utilized to break down a current framework or model
another one. Like all the best graphs and outlines, a DFD can frequently outwardly "say" things
that would be difficult to clarify in words, and they work for both specialized and nontechnical
groups of onlookers, from engineer to CEO.
5.6.1 Data Flow Diagram Symbols
There are several types of symbols.
Fig 5.10: Data Flow Diagram Symbols

29 | P a g e
5.6.2 Context Diagram
The Context Diagram demonstrates the system under thought as a solitary abnormal state process
and after that demonstrates the relationship that the framework has with other outside elements
(frameworks, authoritative gatherings, outer information stores, and so on). Another name for a
Context Diagram is a Context-Level Data-Flow Diagram or a Level-0 Data Flow Diagram.
Since a Context Diagram is a specialized version of Data-Flow Diagram, understanding a bit
about Data-Flow Diagrams can be helpful.
Fig 5.10: Context Diagram

30 | P a g e
5.6.3 Level 0 Data Flow Diagram
A level 0 data flow diagram (DFD) shows a data system as a whole and emphasizes the way it
interacts with external entities. This DFD level 0 example shows how such a system might
function within a typical project thesis management.
Fig 5.11: Level 0 DFD

31 | P a g e
CHAPTER SIX
SOFTWARE DESIGN & TESTING
To build and design of this system we used some programming languages.
6.1 Tools Used in Design
6.1.1 Font End:
• HTML5
• CSS3
• JavaScript
• Bootstrap
6.1.2 Back End:
• PHP
• MYSQL
6.1.3 Server: XAMPP v7.2.12
6.1.4 Editor:
• Sublime Text
• JetBrains PhpStorm
6.1.5 PHP
PHP is a content dialect and translator that is uninhibitedly accessible and utilized fundamentally
on Linux Web servers. PHP, initially got from Personal Home Page Tools, presently represents
PHP: PHP executes on the server, while a tantamount option, JavaScript, executes on the
customer. PHP is an option in contrast to Microsoft's Active Server Page (ASP) innovation.
Likewise with ASP, the PHP content is inserted inside a Web page alongside its HTML. Before
the page is sent to a client that has asked for it, the Web server calls PHP to decipher and play
out the activities called for in the PHP content. Like ASP, PHP can be thought of as "dynamic
HTML pages," since substance will shift dependent on the consequences of translating the
content.

32 | P a g e
6.1.6 MySQL
MySQL is the world's most well known open source database, empowering the savvy
conveyance of solid, elite and adaptable Web-based and installed database applications. It is a
coordinated exchange protected, ACID-agreeable database with full submit, rollback, crash
recuperation, and column level locking capacities. MySQL conveys the usability, versatility, and
superior, just as a full suit of database drivers and visual instruments to encourage engineers and
DBAs manufacture and deal with their business-basic MySQL applications.
6.1.7 HTML
HTML is the World Wide Web's core markup language. Initially, HTML was fundamentally
structured as a dialect for semantically depicting logical reports. Its general plan, be that as it
may, has empowered it to be adjusted, over the resulting years, to portray various different kinds
of archives and even applications.
6.1.8 CSS
CSS is the language for describing the presentation of Web pages, including colors, layout, and
fonts. It enables one to adjust the introduction to various sorts of gadgets, for example, vast
screens, little screens, or printers. CSS is autonomous of HTML and can be utilized with any
XML-based markup dialect. The division of HTML from CSS makes it less demanding to look
after locales, share templates crosswise over pages, and tailor pages to various conditions. This is
alluded to as the division of structure (or: substance) from introduction.
6.1.9 JAVASCRIPT
JavaScript is a programming language for the web. It is bolstered by most internet browsers
including Chrome, Firefox, Safari, web Explorer, Edge, Opera, and so on. Most versatile
programs for PDAs bolster JavaScript as well. It is fundamentally used to upgrade site pages to
accommodate a more easy to understand involvement. These incorporate progressively
refreshing website pages, UI upgrades, for example, menus and exchange boxes, activitys, 2D
and 3D designs, intuitive maps, video players, and more. This mode of JavaScript usage in the
web browser is also referred to as client-side JavaScript.

33 | P a g e
6.2 Logical Schema
• student_profiles(id, user_id, profile_photo, address, gender, contact_no, semester,
batch, cgpa, contact_hour, created_at, updated_at)
• permissions(id, name, display_name, description, cerated_at, updated_at)
• tasks(field, id, task, progress_value)
• domains(id, name, descriptions)
• team_task( id, team_id, task1, task2, task3, task4, task5, created_at, updated_at)
• permission_role( permission_id, role_id)
• role_user(role_id, user_id, user_task, user_type, team_id)
• publications( id, title, descriptions, published_on, paper_link, teacher_id, year)
• teacher_profilesid, teacher_id, profile_photo, address, gender, contact_no, working_field,
cv, designation, created_at, updated_at)
• batches(id, batch, reg_status, created_at, updated_at)
• users(id, name, varsity_id, email, password, activatiocode, status, remember_token,
created_at, updated_at)
• books( id, descriptions, book_link, teacher_id, year)
• project_thesis(id, team_id, title, subjet, description, documentation, project_title,
supervisor_id, project_status, type, created_at, updated_at)
• domains(id, user_id, domain_id)
• roles(id, name, display_name, description, created_at, updated_at)
• permission_user(permission_id, user_id, user_type, team_type)
• messages(id, subject, messages, sender_id, receiver_id, team_id, role_id, read_status,
archeived, conversation_id, created_at, updated_at)
• user_request(id, sender_id, receiver_id, team_id,, approve)
• files(id, team_id, user_id, role_id, file, subject, created_at, updated_at)
• teams(id, name, description, project_idea, approve_status, progress, batch, created_at,
updated_at)
• quotas(teacher_id, batch, team_limit, created_at, updated_at)
• password_resets(email, token, created_at)
• migrations(id, migration, batch)
• Permission_role(permission_id, role_id)

34 | P a g e
6.3 Tables of System
It is related with student info. Store related data.
Table 6.3.2: permissions
store data of progress report.
Table 6.3.1: student_profiles
Table 6:3:3: tasks
student_profiles
field type
id Int(10)
user_id Int(10)
profile_photo varchar(191)
address varchar(191)
gender tinyint(4)
contact_no varchar(191)
semester tinyint(4)
batch tinyint(4)
cgpa float
contact_hour float
created_at timestamp
cpdated_at timestamp
permissions
field type
id int(10)
name varchar(50)
display_name varchar(100)
description text
updated_at timestamp
tasks
field type
id int(10)
task text
progress_value int(10)

35 | P a g e
Consists of all task information. Store teachers profile page data.
Table 6.3.4: team_task
Table 6.3.5: teacher_profiles
Store id with description. Store data based on domains table id
Table 6.3.6 domains Table 6.3.7 domains
team_task
field type
id int(10)
team_id int(11)
task1 int(11)
task2 int(11)
task3 int(11)
task4 int(11)
task5 int(11)
teacher_profiles
field type
id Int(10)
teacher_id Int(10)
profile_photo varchar(191)
address varchar(191)
gender tinyint(4)
contact_no varchar(191)
working_field tinyint(4)
cv tinyint(4)
designation float
domains
field Type
id int(10)
name Text
descriptions Text
domains
field type
id int(10)
user_id int(10)
domain_id int(10)

36 | P a g e
Users info with activation code with status. This table stores all Project_thesis id.
Table 6.3.8: Users
Table 6.3.9: Project_thesis
users
field type
id int(10)
name varchar(50)
versity_id varchar(11)
email varchar(11)
password varchar(11)
activation_code varchar(11)
status tinyint(11)
remember_token varchar(100)
Project_thesis
field type
id int(10)
team_id int(10)
title text
subject varchar(50)
description text
documentation varchar(191)
project_file varchar(191)
supervisor_id int(10)
project_status tinyint(10)
type varchar(50)

37 | P a g e
This tables stores batches related data. Assigning user according to roles by this table.
Table 6.3.11: role_user
Table 6.3.10 : batches
This table helps to create roles in system. Books record that uploaded by system
.store in this table.
Table 6.3.12 Roles Table 6.3.13 books
batches
field type
id int(10)
batch int(10)
reg_status int(10)
role_user
field type
role_id int(10)
user_id int(10)
user_type varchar(100)
team_id int(10)
Roles
field type
id int(10)
name varchar(50)
display_name varchar(50)
description text
books
field type
id int(10)
title varchar(191)
descriptions text
book_link varchar(30)
teacher_id int(11)
year date

38 | P a g e
Store sender & receiver id for chatting feature. Team approval info mainly stored in this table
Table 6.3.15 teams
Table 6.3.14:message
Resetting password store in this table. Shifting of batches stored into this table.
Table 6.3.16: password_resets Table 6.3.17: migrations
messages
field type
id int(10)
subject varchar(191)
messages text
sender_id int(10)
receiver_id int(10)
team_id int(10)
role_id int(10)
read_status int(10)
archieved int(10)
conversation_id int(10)
teams
field type
Id int(10)
name varchar(50)
description text
project_idea varchar(50)
approve_status int(10)
progress varchar(50)
batch tinyint(10)
migrations
field type
id int(10)
migration varchar(10)
batch int(10)
password_resets
field type
email varchar(191)
token varchar(191)

39 | P a g e
Info about team limits stored in this table. Requests are generate by using sender &
receiver info from this table.
Table 6.3.18: quotas Table 6.3.19: user_request
Document published date and paper linking Permission get based on roles of user that
information stored into this table stored in the table
Table 6.3.21: permission_user
Table 6.3.20: publications
quotas
field type
id int(10)
teacher_id int(10)
batch int(10)
team_limit int(10)
updated_at imestamp
user_request
field type
id int(10)
sender_id int(10)
receiver_id int(10)
team_id int(10)
approve tinyint(10)
publications
field type
id int(10)
title varchar(191)
descriptions text
published_on varchar(10)
paper_link varchar(30)
teacher_id int(11)
year date
permission_user
field type
Permission_id int(10)
user_id int(10)
user_type varchar(191)
team_id int(10)

40 | P a g e
Who uploaded files in the system can be see from system. Files related all info such as
team_id, user_id, role_id stored in the table.
Table 6.3.22: files
Permission related user data based on the role stored in the table.
Table 6.3.23: permission role
files
Field type
Id int(10)
team_id int(10)
user_id int(10)
role_id int(10)
File varchar(191)
Subject varchar(191)
permission_role
field type
permission_id int(10)
role_id int(10)

41 | P a g e
6.4 Testing
Software testing is an activity to check whether the actual results match the expected results and
to ensure that the software system is Defect free. It includes execution of a product segment or
framework segment to assess at least one properties of intrigue. Programming testing
additionally recognizes mistakes, holes or missing prerequisites in spite of the real necessities. It
very well may be either done physically or utilizing robotized apparatuses.Testing methods for
testing system are given below:
• Unit Testing
• Black Box Testing
• White Box Testing
6.4.1 Unit Testing
Unit testing is a software development process in which the smallest testable parts of application,
called units, are individually and independently scrutinized for proper operation. It includes
execution of a product segment or system segment to assess at least one properties of intrigue.
Programming testing additionally recognizes mistakes, holes or missing prerequisites in spite of
the real necessities. It very well may be either done physically or utilizing robotized apparatuses.
6.4.1.1 Test Plan
Objectives: Ensure about the information entered into the login form is valid and null value
cannot accepted.
Test Case 1:
Interface Name Field Name Input Value
User_id/name Nayan
Login password
Result: Login Failed!
Test Case 2:
User_id/name
Login password
Result: Login Failed! Enter Username and Password.

42 | P a g e
Test Case 3:
User_id/name Nayan
Login password password
Result: Congratulations! Login Successful.
6.4.2 White Box Testing
White Box Testing (also known as Clear Box Testing, Open Box Testing, Glass Box Testing,
Transparent Box Testing, Code-Based Testing or Structural Testing) is a software testing method
in which the internal structure/design/implementation of the item being tested is known to the
tester. In this system pick inputsto practice ways through the code and decides the fitting yields.
We effectively tried this white box testing through our code and advised that worked
consummately.
6.4.3 Black Box Testing
Black Box Testing is testing method that interior structure/plan/execution of the thing being tried
isn't known to the analyzer. This technique is named so on the grounds that the product program,
according to the analyzer, resembles a black box; inside which one can't see. This strategy
endeavors to discover blunders in the accompanying classifications:
• Interface errors
• Errors in data structures or external database access
• Behavior or performance errors
• Initialization and termination errors

43 | P a g e
6.4.3.1 Test Result
➢ Failing to provide right password here user applying for resetting the password. To reset
password user must be provide email address.
Fig 6.1: Black Box Testing
➢ If user s information is not valid it shows the message user doest not exist.
Fig: 6.2: Black Box Testing

44 | P a g e
CHAPTER SEVEN
IMPLEMENTATION, MAINTENANCE & SECURITY
7.1 User Panel
7.2 Login
Login form for both teachers and students. By using this form teachers and students can get into
the system.
Fig 7.1: Login Page

45 | P a g e
7.3 Registration
7.3.1 Student Registration
Student Registration Form. Here new student can. Register by fulfilling the require fields to
complete their thesis/project by creating team & selecting supervisor.
Fig 7.2: Student Registration

46 | P a g e
7.3.2 Teacher Registration
Teacher Registration Form. Here teachers can register for supervising thesis-project team under
his supervision.
Fig 7.3: Teacher Registration

47 | P a g e
7.4 Dashboard
Student home page here student can search a teacher by his name or by his working criteria as
the interest of the students. Student can also see the previous works of the teacher.
Fig 7.4: Student Dashboard

48 | P a g e
7.5 Profile
7.5.1 Teacher Profile
From the teachers profile a student can contact with the respected teachers for any kinds of
information that he needs for his thesis-project works.
Fig 7.5: Teacher profile

49 | P a g e
7.5.2 Team Profile
Team profile represents overall information about team. If the team is not approved it shows
pending. Request information also have against of a team in its profiles.
Fig 7.6: Team Profile

50 | P a g e
7.6 Searching
Students can find the teacher and see the details of a teacher by visiting the respected teachers
profile. Students can also see the research works of the teachers.
Fig 7.7: Searching

51 | P a g e
7.7 Request Supervisor
Team members can also send request to respected supervisor if supervisor’s slot is available for
that batch.
Fig 7.8: Request for Supervisor

52 | P a g e
7.8 Create Team
A registered student can create team by choosing team name & team member by selecting their
batch.
Fig 7.9: Create Team
7.9 Show Team Request
Student can accept or reject team member request sent by other team for being member.
Fig 7.10: Show Team Request

53 | P a g e
7.10 Notifications
Student can see team request by push notifications shown on the top of their profile.
Fig 7.11: Notification
7.11 Message
Students can directly message their respected teachers or the supervisor of their thesis-project
Works.
Fig 7.12: Messaging

54 | P a g e
7.12 Show Student List
Team leader of a team can send team member request to maximum three students & the students
can accept the request if they are not belongs to any other team.
Fig 7.13: Student List
7.13 Team Task List
This section represents the list of team pending team tasks. Supervisor can approve this task.
Team progress of a team depends on the approval.
Fig 7.14: Team task list

55 | P a g e
7.14 Team Approval
Thesis Committee can approve a team after verifying team details.
Fig 7.15: Team Approval

56 | P a g e
7.15 Team Dashboard
This section has details of a team members and total team information.
Fig 7.16: Team Dashboard

57 | P a g e
7.16 File Upload and Messaging
Members can upload files and can message with one another.
Fig 7.17: File Upload and Messaging

58 | P a g e
7.17 Student profile
Student profile has all information of student. Other user can contact with a student from this
section.
Fig 7.18: Student profile

59 | P a g e
7.18 Student profile setting
Student can update his information as needed.
Fig 7.19: Student profile setting

60 | P a g e
7.19 Teacher profile
Teacher profile has all information of teacher. User can download CV of teacher.
Fig 7.20: Teacher Profile

61 | P a g e
7.20 Teacher Publication
Teacher can add his publications records.
Fig 7.21: Teacher Publication

62 | P a g e
7.21 Update Teacher Profile
Teacher can update his information from his profile section.
Fig 7.22: Update Teacher Profile

63 | P a g e
7.22 Inbox
This is the messaging system of this software. From here all users of this system can
communicate with each other.
Fig 7.23: Inbox

64 | P a g e
7.23 Notice Board
User can see all notices provided by teachers and admin.
Fig 7.23: Notice Board
7.24 Assign batch
Admin can create new batch and open/close registration process.

65 | P a g e
Fig 7.25: Assign batch
7.25 Team Limit
Admin can assign teachers and set team limit for a batch.
Fig 7.26: Team Limit
7.26 Assign Admin
Admin can assign a teacher as a new admin.
Fig 7.27: Assign Admin

66 | P a g e
7.27 Team Task
Admin create team task and task value .
Fig 7.28: Assign Admin

67 | P a g e
7.28 Working Domain
Admin can add topics of teachers working area..
Fig 7.29: Working Area
7.29 Admin List
Admin can see the admin list and assign super admin.

68 | P a g e
Fig 7.30: Admin List
7.30 Approve Student
Admin can approve all pending students.
Fig 7.31: Approve Student
7.31 Team List
Admin can see the team list

69 | P a g e
Fig 7.32: Team List
7.32 Team List
Admin can teacher to the thesis-committee.
Fig 7.33: Assign to thesis committee

70 | P a g e
CHAPTER EIGHT
SUMMARY & CONCLUSION
8.1 Summary
This system has developed to create a common platform that where our teachers, supervisors and
students can manage thesis or project related process easily. In this system teachers, supervisors
and students have different module. These particular modules manage particular issue based on
their access in the system.
This platform gives up the opportunity to interact teachers and students easily with each other.
They can share their idea also. It gives opportunity to select supervisor or select student for final
thesis or project. This system helps to create enthusiasm among teachers and students because of
its effectiveness.
8.2 Conclusion
This system has been tried continuously circumstance and the essential point of this work has
been achieved. The system was structured and built up a common platform for amalgamating all
of our respected teachers and students that research process of our dept can be easier. We are
categorical about the fruitfulness of this system.
8.3 Project Outcomes

71 | P a g e
• This System only for IIUC respected teachers and students of CSE department.
• This system only accessible for teachers so that they can manage all thesis and project
related issues easily.
• In this system student can access limited access as they need.
• It helps the department to overcome the limitation of managing thesis-project system.
• It helps the department to avoid thesis-project related session jam.
• It helps teachers and students both.
• Teachers can approve students or students can select teachers via this system instead of
initial physically meeting of teachers and students.
8.4 Project Limitations
In spite of every effort provide in building a system, there must be some problems and bugs i.e
that actions that system is not capable to perform. Some of the limitations of our developed
system are shown below:
• Notification system cannot be updated without refreshing .
• Messaging system of this system is not hundred percent real-time.
• No android version of this system is available.
8.5 Future Plan
We have some plan about this system to make this software more dynamic and more user
friendly. We will add more features to this system.
• Make mobile version of this system.
• Messaging system will be more real time.
• User interface will more dynamic
Finally, we would like to end the six months while we were performing of this project. We faced
many problems to build this and also restored. We learned many new technologies which help us
to make new system and face new problems without any fear. With due respect, we want to
thanks to all who helped us to make this journey easy by their support.

72 | P a g e
CHAPTER NINE
REFERENCES
Books
• Laravel Design Patterns and Best Practices by Arda Kilicdagi & H. Ibrahim YILMAZ.
• Learning Laravel’s Eloquent by Franceso Malatesta.
• Database ManagementSystems by Raghu Ramakrisnan, Johannes Gehrke.
• Learning PHP, MySQL, JavaScript, and CSS by O’REILLY
• PHP Bible: Tim Converse, Joyce Park
Online
• https://laravel.com/
• https://stackoverflow.com/questions/41547856/laravel-inter-user-messaging-system.
• https://codepen.io/
• https://laravel.com/docs/5.7
• https://getbootstrap.com/
• http://talhatraining.com/laravel-professional-training
• https://www.techopedia.com/
• https://www.guru99.com
• https://en.wikipedia.org

73 | P a g e
• https://www.youtube.com/

Project thesis management_system_in_context_of_iiuc

More Related Content

Similar to Project thesis management_system_in_context_of_iiuc (20)

Recently uploaded (20)

Project thesis management_system_in_context_of_iiuc