Minor Project Report On Projectoscope PDF

PROJECTOSCOPE
Minor Project submitted
towards partial fulfilment of the
degree of Bachelor of Engineering
Year 2017 - 2018
Department of Computer Science and Engineering
Guided By : Submitted By:

Mrs. Archana Choubey 1. Aayushi Bharti (0802CS151003)
(Assistant Professor, CSE Dept.) 2. Ambika Depale (0802CS151015)
3. Apoorva Phatak (0802CS151025)
Shri Vaishnav Institute of Technology and Science, Indore

Shri Vaishnav Institute of Technology and Science,
Indore
Certificate
This is to certify that Aayushi Bharti, Ambika Depale and Apoorva Phatak Working in a
Group have satisfactorily completed the minor project titled “Projectoscope” towards the
partial fulfillment of the degree in Bachelor of Engineering (Computer Science &
Engineering) Awarded by Rajiv Gandhi Proudyogiki Vishwavidyalaya, Bhopal for the
academic year 2017 – 2018.
Project Guide Head of Department
Mrs. Archana Choubey Dr. Anand Rajawat
Internal External
ii
Acknowledgement
Every endeavour we undertake calls for the need of some support and blessing. In the spirit
of the undying support that we have been fortunate enough to have, we would like to heartily
thank our subject teacher and guide, Mrs. Archana Choubey, for her guidance and for the
expertise that she lent us throughout the project. We would also like to thank the Head of
Department (Computer Science and Engineering), Dr. Anand Rajawat for providing us with
the help and the resources that we so direly needed. Our thanks and appreciation would also
be for our parents, friends and all those who contributed towards the fulfilment of this
project.
Date: Aayushi Bharti (0802CS151003)

Ambika Depale (0802CS151015)
Apoorva Phatak (0802CS151025)
iii
Abstract
In today’s world, man struggles to make his life easier. As part of university curriculum, the
engineering students are supposed to execute a minor and a major project. While executing
this project it is observed that there is absolute lack of synchronization among the various
student groups and their project guides on account of their diverse primary roles and different
priorities. The need for tracking the progress of any project has assumed high importance
because of varied and diverse resources such as time. In large institutes, where the man-
power is high, people are not always in their classrooms or cabins. They have to wander from
classroom to classroom, floor to floor, lab to lab, libraries etc. to perform their work. In such
cases, it becomes extremely difficult to keep a track of people and find them and
communicate with them when it is needed.
Solution for the above problem is to deploy an effective monitoring system which can track a
project progress and raise timely alarms. A system which could provide automated reminders
to all concerned and the project guides whereby they can track each and every live project
with information that would suffice their need.
It is observed that there exists an unforced communication gap between the project guide and
the students of 3rd and 4th year regarding minor and major project work, triggering a delay in
group formation and project selection.
Our aim is to come up with a system that will eliminate the delay in finalizing groups as well
as work-areas for minor and major projects. In order to facilitate smooth communication
among the project guides and student groups and monitor individual and comparative
progress for a batch. And above all provide one stop project monitoring facilities for entire
institute demography.
iv
LIST OF TABLES
Table No. Figure Name Page No.

4.2.2.1 Master top sheet – Subject Master 33
4.2.2.2 Master validation sheet– Subject Master 34
4.2.2.3 Master top sheet – Class Master 36
4.2.2.4 Master validation sheet – Class Master 37
4.2.2.5 Master top sheet – Student Master 39
4.2.2.6 Master validation sheet–Student Master 40
4.2.2.7 Master top sheet – Faculty Master 42
4.2.2.8 Master validation sheet – Faculty Master 43
4.2.2.9 Master top sheet – Standard Project Stages 45
4.2.2.10 Master validation sheet – Standard Project Stages 46
4.2.2.11 Transaction top sheet-Register Group 48
4.2.2.12 Transaction validation sheet-Register Group 50
4.2.2.13 Transaction top sheet-Approve Group 52
4.2.2.14 Transaction validation sheet-Approve Group 53
4.2.2.15 Transaction top sheet-Deregister Group 55
4.2.2.16 Transaction validation sheet-Deregister Group 56
4.2.2.17 Transaction top sheet – Propose Project 58
4.2.2.18 Transaction validation sheet-Propose Project 59
4.2.2.19 Transaction top sheet – Report Project Progress – 62
Approve Projects
4.2.2.20 Transaction validation sheet –Approve Projects 63
4.2.2.21 Transaction top sheet – Report Project Progress 66
4.2.2.22 Transaction validation sheet – Report Project Progress 67
4.2.2.23 Transaction top sheet – Authenticate Project Progress 70
4.2.2.24 Transaction validation sheet – Authenticate Project 71
Progress
4.2.2.25 Transaction top sheet – Send Intimation 74
4.2.2.26 Transaction validation sheet – Send Intimation 75
4.2.2.27 Transaction top sheet – Generate Reminders 77
4.2.2.28 Transaction validation sheet – Generate Reminders 78
4.2.2.29 Subject Master List 80
4.2.2.30 Class Master List 82
4.2.2.31 Student Master List 84
4.2.2.32 Faculty Master List 86
4.2.2.33 Standard Project Stage Master List 88
4.2.2.34 Faculty wise Project List 90
4.2.2.35 Class wise Project List 92
4.2.2.36 Subject wise Project List 94
4.2.2.37 Status wise Project List 96
4.2.2.38 Active Project List 98
4.2.2.39 Overdue Project List 100
v
LIST OF FIGURES
Figure No. Figure Name Page No.

4.1.1.3.1 Use case for Register Group 14
4.1.1.3.2 Use case for Approve Group 16
4.1.1.3.3 Use Case for Deregister Group 18
4.1.1.3.4 Use Case for Propose project 20
4.1.1.3.5 Use Case for Approve Project 22
4.1.1.3.6 Use Case for Report Progress 24
4.1.1.3.7 Use Case for Authenticate Progress 26
4.1.1.3.8 Use Case for Send Intimation 28
4.1.1.3.9 Use Case for Generate Reminders 30
4.2.2.1 Subject Master Layout 35
4.2.2.2 Class Master Layout 38
4.2.2.3 Student Master Layout 41
4.2.2.4 Faculty Master Layout 44
4.2.2.5 Standard Project Stages Layout 47
4.2.2.6 Register Group Layout 51
4.2.2.7 Approve Group Layout 54
4.2.2.8 Deregister Group Layout 57
4.2.2.9 Propose Project Layout 61
4.2.2.10 Approve Projects Layout 65
4.2.2.11 Report Project Progress Layout 69
4.2.2.12 Authenticate Project Progress Layout 73
4.2.2.13 Send Intimation Layout 76
4.2.2.14 Generate Reminders Layout 79
4.2.2.15 Subject Master List 81
4.2.2.16 Class Master List 83
4.2.2.17 Student Master List 85
4.2.2.18 Faculty Master List 87
4.2.2.19 Standard Project Stage List 89
4.2.2.20 Faculty wise Project List 91
4.2.2.21 Class wise Project List 93
4.2.2.22 Subject wise Project List 95
4.2.2.23 Status wise Project List 97
4.2.2.24 Active Project List 99
4.2.2.25 Overdue Project List 101
4.2.3.1 Detailed Class Diagram 102
4.2.3.2.1 Sequence Diagram 103
4.2.3.2.2 Collaboration Diagram 104
4.2.3.3 State Diagram 104
4.2.3.4 Activity Diagram 105
4.2.3.5 Object Diagram 106
4.2.3.6 Deployment Diagram 106
5.1.1.1 Waterfall Model 107
5.2.2.1 Snapshot 1 113
5.2.2.2 Snapshot 2 120
vi
vii
INDEX
# Title Page i
# Certificate ii
# Acknowledgement iii
# Abstract iv
Tables of Content
# List of Tables v
# List of Figures vi
Contents
1. Introduction 1-3
1.1 Problem Statement 1
1.2 Scope 1
1.3 Objective 2
1.4 Platform Specifications 2
1.4.1 Hardware Requirements 2
1.4.2 Software Requirements 2
1.4.3 Implementation Language 3
2. Feasibility Study 4-5

2.1 Economic Feasibility 4
2.2 Operational Feasibility 4
2.3 Technical Feasibility 5
3. Literature Survey 6-9

3.1 Work Done by Others 6
3.2 Benefits 6
3.3 Proposed Solution 6
3.4 Technology Used 7
4. Requirement Analysis and Design 10 -106

4.1 Requirement Analysis 10
4.1.1 Software Requirement Specification 10
4.1.1.1Glossary 11
4.1.1.2Supplementary Specification 11
4.1.1.3Use Case Model 11
4.1.2 Conceptual Level Class Diagram 31
4.1.3 Conceptual Level Sequence Diagram 31
4.1.4 Conceptual Level Activity Diagram 31
4.2 Design 32
4.2.1 Design Concept 32
4.2.2 Design Technique 32
4.2.3 Modelling 102
4.2.3.1 Detailed Class Diagram 102
4.2.3.2 Interaction Diagram 103
4.2.3.2.1 Sequence Diagram 103
4.2.3.2.2 Collaboration Diagram 104
4.2.3.3 State Diagram 104
4.2.3.4 Activity Diagram 105
4.2.3.5 Object Diagram 106
4.2.3.6 Deployment Diagram 106
5. Methodology and Implementation Phase 107-121

5.1 Methodology 107
5.1.1 Description 107
5.1.2 Advantages and Disadvantages 108
5.1.3 Reason for Use 109
5.2 Implementation Phase 109
5.2.1 Language Used Characteristics 109
5.2.2 Coding 110
5.2.3 Code Efficiency 120
5.2.4 Optimization of Code 121
5.2.5 Validation Check 121
6. Testing 122-124
6.1 Test Objectives 122
6.2 Testing Methods and Strategies 122
7. Conclusion and Future Work 125 -126

7.1 Achievements 125
7.2 Limitations of Project 126
7.3 Difficulties Encountered 126
7.4 Future Enhancement Suggestions 126
8. References 127
8.1 Reference Books 127
8.2 Other Documentation and Resources 127
1. Introduction
As per university requirements, engineering students are supposed to undertake project work in
3rd and 4th year as part fulfillment of their course. In 3 rd year students are supposed to take up
Minor Project work and in final year they have to take up Major Project work.At first, students
have to divide themselves into groups of maximum four people and inform faculty accordingly.
After that, students are supposed to present their ideas before of the faculty. Faculty may
suggest some amends in ideas. After the idea or the topic is finalized, again a presentation about
the final topic takes place. Basically, these presentations aim at informing the faculty or project
guide about the progress of the projects that are undertaken by different student groups. At the
end, students are required to submit their projects along with documentation before the
submission deadline.
All this work is carried out manually and hence prone to manual errors. Leisurely attitude of
students towards forming groups and coming up with ideas for the project often delays the
overall process. Also, communication gap between faculty, project guide and students also adds
up to delay.
System allows easy monitoring of project from the guide’s end. Manual management of project
does not allow comparative analysis of different projects. But the system developed overcomes
this limitation as well.
All the requirements were analyzed and taken care of while developing the system, thus the
developed system successfully overcomes all the problems and promises to provide required
solution.
1.1 Problem Statement

There was a communication gap between the Guide and the students of 3 rd and 4th year
regarding minor and major project work, due to which there was a delay in group formation and
project selection. And also the guide was unable to examine the progress of the project.
1.2 Objectives
Our aim is to come up with a system that will eliminate the delay in finalizing groups as well as
work-areas for minor and major projects. To facilitate easy communication from the project
guides and monitor individual and comparative progress for a batch.
1
1.3 Scope
The Projectoscope addresses the management of software projects by providing the framework
for organizing and managing resources in such a way that these resources deliver all the work
required to complete a software project within defined scope, time and cost constraints.
The system applies only to the management of software projects and is a tool that facilitates
decision making; the Projectoscope does not make decisions.
1.4 Platform Specification

1.4.1 Hardware Requirements:
Processor : Intel Core i3
Hard Disk : 1TB
Pointing Device : Mouse
RAM : 4GB
1.4.2 Software Requirements:

: Platform : Windows 10
Web Browser : Google Chrome
Web Server : Apache version 2.4.27
Database : MySQL version 5.7.19
Scripting Language : Pre-processor Hypertext (PHP version 7.0.9)
Front end : HTML5, Bootstrap, JavaScript, jQuery
2
1.4.3 Implementation Language:
PHP:
PHP is an acronym for "PHP: Hypertext Pre-processor". It is a widely use open source
scripting language. Scripts are executed on server. PHP is free to download and use.
What Can PHP Do?
 PHP can generate dynamic page content

 PHP can create, open, read, write, delete, and close files on the server
 PHP can collect form data
 PHP can send and receive cookies
 Using PHP, one can add, delete, modify data in your database
 PHP can be used to control user-access
 PHP can encrypt data
Why PHP?
 Various platforms such asWindows, Linux, Unix, Mac OS X, etc. support PHP.
 PHP is compatible with almost all servers used today (Apache, IIS, etc.)
 A wide range of databases is supported by PHP.
 PHP is free and it can be download from the official PHP resource: www.php.net
 It is easy to learn PHP. It runs efficiently on the server side.
3
2.Feasibility Study
Feasibility study is done to check that whether the new system will be operational or not.
Feasibility analysis begins once the goals are defined. It starts by generating broad possible
solutions, which are possible to give an indication of what the new system should look like.
This is where creativity and imagination are used. Analysis must think up new ways of doing
things-generate new ideas. There is no need to go into the detailed system operation yet.
The feasibility study is a major factor which contributes to the analysis and development of the
system. The decision of the system analyst whether to design a particular system or not depends
on its feasibility study.
Study of requirement analysis is done through different feasibility study. Feasibility study is
undertaken whenever a possibility of probability of improving the existing system or designing
new system. Feasibility study helps to meet user requirements.
It enables us to determine the potential of existing system and improving it. It helps to develop
a technically and economically feasible system. It helps to know what should be embedded in
the system. It also helps to develop a cost-effective system. We can make better utilization of
available resources.
In the feasibility study we have:
 Economic Feasibility
 Operational Feasibility
 Technical Feasibility
2.1 Economic Feasibility

Areas considered in the economic feasibility-
 The benefits of existing system
 Cost associated with the existing system
 The benefits of proposed system
 Cost associated with the proposed system
2.2 Operational Feasibility
Operational Feasibility means that the system which we are developing will be able to be used
by the users for whom the system is made. It means it should be easy to use. No special training
should be given to the users of the system. We are making this project application based, so it
will act like application software. It is easy to use them. So we can say that the software we are
making is operational feasible also.
4
The system working is quite easy to use and learn due to its simple but attractive interface. User
requires no special training for operating the system. Technical performance includes issues
such as determining whether the system can provide the right information, and whether the
system can be organized so that it always delivers this information at the right place and on
time using intranet services. Acceptance revolves around the current system and its personnel.
It satisfies all the conditions of the feasibilities; all three feasibilities are satisfied. That is why
we can say that the project is feasible.
2.3 Technical Feasibility

It is a measure of the how practical solutions are and whether the technology is already
available within the organization. If the technology is not available to the firm, technical
feasibility also looks at whether it can be acquired.
Technical feasibility centers around the existing system and to what extent its support can be
extended to the proposed system. This project is technically feasible and to maximum extent the
existing systems support the proposed system.
5
3.Literature Survey
With fast evolving technology, machines have minimized human efforts and made it easy to
manage things efficiently. This has also led to reduce in time delays which are bound to take
place when all the things are handled manually. Managing and monitoring student project is a
hectic task for any project guide. This prompted the need for a system that effectively handles
maximum tasks that are to be undertaken during the course of project.
3.1 Work Done by Others

Project Monitoring is the process of keeping track of all project-related metrics including team
performance and task duration, identifying potential problems and taking corrective actions
necessary to ensure that the project is within scope, on budget and meets the specified
deadlines. In other simple words, project monitoring is overseeing all tasks and keeping an eye
on project activities to make sure you’re implementing the project as planned. At present the
group registration and progress tracking are a manual task. Earlier no computerized system was
there to track, authorize and authenticate the project guide. This caused inefficient monitoring
of projects and delayed progress.
3.2Benefits
Various benefits of this project monitoring system Projectoscope are:
 Efficient monitoring of team performance.

 Regular status and progress reports.
 Providing recommendations and suggestion.
 Ensuring that recommended actions are implemented.
 Reduced delays at all stages.
 Easy Communication.
3.3 Proposed Solution

In the proposed system, project guide need not to go to each and every group personally to
convey schedules and also he can effectively monitor the progress of their projects. Guide has
facility to send intimations and reminders to the groups via email. Guide can convey the
schedules via email and students can update their project status online which has to be verified
by the project guide.
6
3.4 Technology Used
HTML
HTML is a language used to create hypertext documents that have hyperlinks embedded in
them .You can build web pages. It is only a formatting language and not a programming
language. Hyperlinks are underlined or emphasized words or locations in a screen that lead to
other documents. WWW is a global, interactive, graphical, hypertext information system. The
motive behind hypertext is that instead of reading text in rigid liner structure you can easily
jump from point to another point .You can navigate through the information based on your
interest and preferences.
Platform Independency:
If you can access Internet, you can access WWW, irrespective of your OperatingSystem and the
Operating System of Web Server you are accessing .All you require isto view and download the
HTML files, which are on the WWW, are browser andInternet connections.HTML is a
language for describing structured documents. HTML describes thestructure of documents -
lists, heading, and paragraph, etc. Elements of web documentare through the usage of HTML
tags. It is tags that describe documents. Anything thatis not a tab is part of a document itself.
Advantages:
An HTML document is a small and hence easy to send over the net. It is small because it does
not include format information. HTML documents are cross platform compatible and device
independent. You only need HTML readable browser to view them. Font names, locations etc.
are required.
BOOTSTRAP
Bootstrap, originally named Twitter Blueprint, is a free and open-source front-end library for
designing websites and web applications. HTML- and CSS-based design templates
for typography, forms, buttons, navigation and other interface components are used. It also has
optional JavaScript extensions.Bootstrap concerns itself with front-end development only. The
latest versions of the Google Chrome, Firefox, Internet Explorer, Opera, and Safari (except on
Windows) are supported by Bootstrap. Since its 2.0 release, Bootstrap supports responsive web
design. This means the layout of web pages adjusts dynamically according to the device on
which the web page is opened. From its version 3.0, Bootstrap adopted a mobile-first
design philosophy, emphasizing responsive design by default. Fourth version 4.0 alpha release
provides Sass and flexbox support.
7
JAVASCRIPT
JavaScript, often abbreviated as JS, is a high-level, interpreted programming language. It is
characterized as dynamic, weakly typed, prototype-based and multi-paradigm.
Along with HTML and CSS, JavaScript is one of the three core technologies of the World Wide
Web. We can make dynamic interactive web pages with JS. The majority of websites employ
itand all modern web browsers support it without the need for plug-ins by means of a built-
in JavaScript engine. JS has many engines and each of them represent a different
implementation of JavaScript, all based on the ECMA Script specification, with some engines
not supporting the spec fully, and with many engines supporting additional features beyond
ECMA.
As a multi-paradigm language, JavaScript supports event-
driven, functional,and imperative (including object-oriented and prototype-based) programming
styles. It has an API for working with text, arrays, dates, regular expressions, and basic
manipulation of the DOM, but the language itself does not include any I/O, such as networking,
storage, or graphics facilities, relying for these upon the host environment in which it is
embedded.
JQUERY
jQuery is a JavaScript library. It is a lightweight, “write less do more” library. The sole purpose
of jQuery is to make the use of JavaScript easy on website. jQuery takes a lot of common tasks
that require many lines of JavaScript code to accomplish, and wraps them into methods that you
can call with a single line of code.
HTML/DOM manipulation, CSS manipulation, HTML event methods, Effects and animations,
AJAX, utilities are some of the features of jQuery
PHP
PHP is a server side scripting language. It is a weakly typed language. The PHP software
works with the web server, which is the software that delivers web pages to the world. When
URL is typed into theaddress bar of the web browser, a message is sent to the web server at that
URL, asking it to send an HTML file. In response, the web server sends the requested file. The
HTML file is read by the browser and web page is displayed.
When a link on a web page is clicked, it also sends the request to the web server. Also, the web
server processes a file when a web page button that submits a form is clicked. Essentially, this
process is same when PHP is installed. When PHP is installed, the web server is configured to
expect certain file extensions to contain PHP language statements. These extensions are.php or
.phtml, but any extension can be used. When the web server gets a request for a file with the
8
designated extension, it sends the HTML statements as is, but PHP statements are processed by
the PHP software before they’re sent to the requester.
MySQL
A database can be defined as a separate application for the purpose of storing a collection of
data. One or more distinct APIs for creating, accessing, managing, searching and replicating
the data is available for each database.
Other kinds of data stores, such as files on the file system or large hash tables in memory can
also be used but these systems would make data fetching and writing, a difficult and slow task.
Nowadays relational database management systems (RDBMS) to store and manage huge
volume of data. It is called relational database because all the data is stored into different
tables. Relations between these tables are established using primary keys or foreign keys.
MySQL is a fast, easy-to-use RDBMS being used for many small and big businesses. It was
developed, marketed and supported by MySQL AB, Swedish company. MySQL is becoming
so popular because of many good reasons −
 MySQL is an open-source relational database management system. So you have nothing to
pay and it is free to use.
 MySQL is a very powerful program in its own right. It handles a large subset of the
functionality of the most expensive and powerful database packages.
 MySQL uses a standard form of the well-known SQL data language.
 MySQL works on many operating systems and with many languages including PHP,
PERL, C, C++, JAVA, etc.
 Even with large data sets, MySQL works very quickly.
 MySQL is very friendly to PHP, the most appreciated language for web development.
 MySQL supports large databases, up to 50 million rows or more in a table. The default file
size limit for a table is 4GB, but you can increase this (if your operating system can handle
it) to a theoretical limit of 8 million terabytes (TB).
 MySQL is customizable. The open-source GPL license allows programmers to modify the
MySQL software to fit their own specific environments.
9
4.Requirement Analysis and Design
4.1 Requirement Analysis
4.1.1 Software Requirement Specification
What is SRS?
Software Requirement Specification (SRS) is the starting point of the software developing
activity. As system grew more complex, it became evident that the goal of the entire system
cannot be easily comprehended. Hence the need for the requirement phase arose. The SRS is
the means of translating the ideas of the minds of clients (the input) into a formal document (the
output of the requirement phase.)
The SRS phase consists of two basic activities:
 Problem/Requirement Analysis:
The process is order and more nebulous of the two, deals with understand the problem, the goal
and constraints.
 Requirement Specification:
Here, the focus is on specifying what has been found giving analysis such as representation,
specification languages and tools, and checking the specifications are addressed during this
activity.
The requirement phase terminates with the production of the validate SRS document. Producing
the SRS document is the basic goal of this phase.
This requirement specification must have the system properties. Conceptually every SRS
should have the components:
 Functionality
 Performance
 Design constraints imposed on an implementation and
 External interfaces
Role of SRS
The purpose of the Software Requirement Specification is to reduce the communication gap
between the clients and the developers. Software Requirement Specification is the medium
through which the client and user needs are accurately specified. It forms the basis of software
development. A good SRS should satisfy all the parties involved in the system.
10
Purpose
The purpose of this document is to describe all external requirements and the interfaces for the
system.
4.1.1.1 Glossary
 PHP: It is a server side scripting language. PHP stands for Pre Processor Hypertext.
 USER: The term user is used to denote all end user of the system.
 HTML: HTML means Hyper Text Mark-up Language.
 CSS: CSS means Cascading style sheet which is used to design the web application.
 JS: JS is commonly used to refer to JavaScript which can be used for front end
designing.
4.1.1.2 Supplementary Specifications
 End user specification:To avail the functionality of the website, existing user has to login to
enter into the website. A new user will first have to register themselves.
 Usability: No special training is required to run the software.
 Reliability: Software will be able to run all time.
4.1.1.3 Use Case Model

WHAT IS USE CASE?
A use case is a methodology used in system analysis to identify, clarify, and organize system
requirements. The use case is made up of a set of possible sequences of interactions between
systems and users in an environment and related to a particular goal here in our case related to
the Project Monitoring comprising of monitoring and administering. It consists of a group of
elements (for example, classes and interfaces) that can be used together in a way that will have
an effect larger than the sum of the separate elements combined. All the use cases represented
in this chapter can be thought of as a collection of possible scenarios related to creation of
groups, allotment of project, monitoring progress of the project.
Every use case included here shall be guided by certain case description parameters. The
parameters shall aid the reader in understanding the use case scenario in itstotality. These
parameters include:
a. Purpose
b. Actors Involved
11
c. Pre Condition
d. Normal Scenario Description
e. Post Actions, and
f. Deviation Treatment.
USE CASES COVERED IN PROJECTOSCOPE – A PROJECT MONITORING TOOL

The various use cases included in the Project Progress Monitoring tool are as enlisted below:
a. Register Group
b. Approve Group
c. Deregister Group
d. Propose Project
e. Approve Project
f. Report Project Progress
g. Authenticate Project Progress
h. Send Intimations
i. Generate Reminders.
USE CASE DESCRIPTIONS

Use Case: Register Group
1. This use case detail out the procedure proposed to be adopted when a group of students
want to intimate the formation of Project Execution Group.
1.1 Purpose: To capture details related to a proposed group. This is a simple process of
updating basic records into the Projectoscope database. This is applicable for those
students who have decided to form a group for executing the project. The record created
here shall be treated as the Group Composition proposed to the Project Guide seeking
his/her approval for the group so that they can proceed with next stage i.e.
conceptualizing and proposing the project.
1.2 Actor(s) Involved

(a) Students
1.3 Pre-condition:
a. All the class id for which the group entry is valid should have been identified in master
prior to entry of data here.
b. All the students are identified by their roll numbers and class id, the master information
of which should have been existing in the system.
12
1.4 Normal Use Case:
a. Students intending to propose their formation of group for executing any project shall
invoke this transaction.
b. They will select the class to which they belong and which is identified for project
execution
c. They shall enter their roll numbers in detail table. Once the roll number is entered it
shall be validated from student master for its existence for the class id entered.
d. Once roll number is validated then all student information like name, email id, mobile
number shall be displayed. While validating it shall be validated that the said roll number
is not part of any other group.
e. Students shall be required to select only one roll number who will be identified as the
group leader. Two leaders cannot be selected and there has to be at least one leader.
f. The group Id shall be generated as combination of 4digit Year+ class ID+3 digit running
serial
g. All the data demanded in this transaction is mandatory
h. The record shall be saved with Status = “NEW”.
i. Unless approved, the transaction can be edited i.e. the record with status = “NEW” can be
edited to amend the group participants.
1.5 Post Actions:

a. Once saved the record shall be eligible for approval by the project guide.
1.6 Deviation treatment : No deviation shall be entertained.
13
Figure 4.1.1.3.1 : Use case for Register Group
14
Use Case: Approve Group
2. This use case detail out the procedure proposed to be adopted when the project guide
wants to approve a group of students as intimated.
2.1 Purpose: To capture approval of the faculty for group formation alongwith its
participants. This is a simple processofupdating basic records into the Projectoscope
database. The students shall approach the project guide (faculty) to approve their group. If
felt okay on all norms (not in this application), the project guide shall approve the group.
No new record shall be created here, but the record created earlier by the students shall be
displayed and approved by the project guide. Once approved the group can proceed to the
next stage i.e. conceptualizing and proposing the project.

(a) Students
(b) Project Guide
2.3 Pre-condition:
a. All the group id intimated by the students should exist in the database with the status
as “NEW”

a. Students intending to seek approval for their group for executing any project shall
contact the project guide for approval process and intimate their group id. (
b. The project guide enter group id. It shall be validated for its existence with
status=”NEW”.
c. The project guide before approval may instruct students to reform the group or change
any group member. Once approved the group will have to be de-registered and recreated.
d. Th project guide shall approve the group.
e. Once approved an email intimation to group leader with this information will be
generated.
f. All the data demanded in this transaction is mandatory
h. The record shall be updated with Status = “APPROVED”.
2.5 Post Actions:

a. Once saved the record shall be eligible for proposing the project.
2.6 Deviation treatment

a. No deviations shall be entertained for approval of student group record.
15
Figure 4.1.1.3.2 : Use case for Approve Group
16
Use Case: Deregister Group
wants to deregister a group of students.
3.1 Purpose: If the faculty has found that progress of the group is not up to date or for some
disciplinary or administrative reasons, group needs to be reconstituted.

(a) Project Guide
3.3 Pre-condition:
a. The group id identified by the project guide(faculty) should exist in the database with
the status as “APPROVED”

a. Faculties intending to deregister a group for executing any project shall identify the
group with their group id.
b. The project guide enter group id. It shall be validated for its existence with
status=”APPROVED”.
c. The project guide while deregistration may instruct students to reform the group or
change any group member.
d. The project guide shall deregister the group.
e. Once deregistered an email intimation to group leader with this information will be
generated.
f. All the data demanded in this transaction is mandatory
h. The record shall be updated with Status = “DEREGISTERED”.
3.5 Post Actions:

a. Once saved the group shall be deactivated for any further activity.

a. No deviations shall be entertained for approval of student group record.
17
Figure 4.1.1..3.3 : Use Case for Deregister Group
18
Use Case: Propose Project
want to propose their project idea to the faculty.
4.1 Purpose: To capture project proposals from approved groups.

This is a simple process of capturing an intent of the student group regarding what project
they want to execute, under whose guidance they would be executing, and what is going
to be their project execution schedule.

(a) Students
4.3 Pre-condition:
The group Id entered must have the status “APPROVED”.

a. Approved Student Groups intending to propose any project shall invoke this
transaction.
b. They will enter their group code for validation.
c. Once validated they are required to key in subject, semester, title of their project, name
of their project guide, select the class to which they belong and which is identified for
project execution.
d. They are also supposed to declare the project duration along with the various project
stages, specific deliverable and its schedule.
Default help on project stages and deliverable shall be variable to them as default selection.
4.5 Post Actions:

a. Once saved the record shall be eligible for proposing project the project guide.
b. All the projects proposed shall be created in the system with status as “NEW”. The
record created here shall be treated as the project proposed to the Project Guide seeking
his/her approval for the project so that they can proceed with next stage.

a. No deviations shall be entertained for creation of project proposal record.
19
Use Case: Propose Project
Information
On Group
Group details for

proposing project
STUDENT
Progress
<<Propose Project>>
Propose
Project
Project
proposal for
approval
PROJECT GUIDE
Figure 4.1.1.3.4 : Use Case for Propose project
20
Use Case: Approve Projects
wants to approve project proposal by groups.
5.1 Purpose: To approve details related to a proposed project. This is a simple process of
approving the basic records created by students on behalf of a group, proposed into the
Projectoscope database. This is applicable for faculty (project guide) who are supposed to
approve a proposed by the group.

(a) Project Guide
(b) Students
5.3 Pre-condition:
The group Id entered must have the status “APPROVED”

a. The students on behalf of a group shall approach the faculty (project coordinator or
project guide) to inform the project proposedwith the group code allotted to them by the
system.
b. The faculty or project guide intending will in return evaluate the project synopsis and then
either approve the project or shall ask to amend the contents.
c. In case the proposal is accepted by faculty then the faculty shall enter group code.
d. Once the group code is validated from the project proposed database, the rest of the
project information shall be displayed on the screen.
e. The faculty shall then mark “Approve” on the record. The record status shall be changed
from “NEW” to Status = “APPROVED”.
5.5 Post Actions:

a. Once approved the project cannot be amended, it can only be terminated by deregistration
of the group.
b. No record shall be created here. Only status update is allowed.

a. No deviations shall be entertained for approval of project proposal record.
21
Use Case: Approve Project
ProgressProject
Proposal
STUDENT
Information
On Group
ReportedProject
Proposal
PROJECT
GUIDE
Project
<<Approval of Project Proposal>> Approval
Approval of
Group
Intimation
Project
Approval
STUDENT
Figure 4.1.1.3.5 : Use Case for Approve Project
22
Use Case: Report Project Progress
want to report their progress on the project.
6.1 Purpose: To capture details related to a proposed group. This is a simple process of
updating basic records into the Projectoscope database. This is applicable for those groups
whose project proposal has been approved by the project guide. Students The record
created here shall be treated as the Project Progress intimated to the Project Guide seeking
his/her verification so that they can proceed with next stage i.e. reporting update of next
stage as specified.

(a) Students
6.3 Pre-condition:
a. All the group ids for which the group entry is valid should have been identified in
master prior to entry of data here.
b. All the groups are identified by their group ids, the master information of which should
have been existing in the system.

a. Groups intending to report their progress of project shall invoke this transaction.
b. They shall enter their group id in detail table. Once the group id is entered it shall be
validated from master for its existence.
c. Once group id is validated then all progress related information like stage number,
project stage name, deliverables, check marks and completion dates of previous
reporting(if any) shall be displayed.
d. They will tick mark the project stage till where they have completed the project.
e. All the data demanded in this transaction is mandatory
f. The record shall be saved with Status = “NEW”.
g. Unless approved, the transaction can be edited i.e. the record with status = “NEW” can
be edited i.e. the stage can be unchecked.
6.5 Post Actions:

a. Once saved the record shall be eligible for approval by the project guide.

a. No deviations shall be entertained for reporting project progress.
23
Use Case: Report Progress
Information
On Group
Group details for

proposing project
STUDENT
Group id.
<<Report Progress>>
Report
Progress
Project
progress for
verification
PROJECT GUIDE
Figure 4.1.1.3.6 : Use Case for Report Progress
24
Use Case: Authenticate Project Progress
7. This use case detail out the procedure proposed to be adopted when project guide wants to
authenticate the progress the projects.
7.1 Purpose To authenticate project stage wise status of approved projects from approved
groups. This is a simple process of approving stage wise completion of various projects as
reported by various student groups.

(a) Students
(b) Project Guide
7.3 Pre-condition:
The projects with status as “REPORTED” or “AUTHENTICATED” must exist.

a. Unauthenticated Project Status reported by Approved Student Groups with approved
projects, intending to report progress of the project shall serve as the basis this
transaction.
b. The faculty will enter their group code for validation.
c. Once validated they are required to key in the date and authentication against first
project stage eligible for status update.
d. For all project stages for which the project stages are already marked completed and
further authenticated shall be displayed as read only and cannot be edited.
7.5 Post Actions:

a. The project stage row for a given project marked as completed shall be stored with the
status “AUTHENTICATED”. All the projects progress authenticated here shall be treated
as the project status approved by the Project Guide mentioning his/her approval for the
same so that groups can proceed with next stage.

a. No deviations shall be entertained for reporting project progress.
25
Use Case: Authenticate Progress
Report
STUDENT
Information
On Group
Progress
PROJECT
GUIDE
Authenticate
<<Authentication of Project Progress>>
Authenticating
Progress
Progress
Authentication
Figure 4.1.1.3.7 : Use Case for Authenticate Progress
26
Use Case: Send Intimation
8.1 Purpose: To send any intimation to all approved groups.

This is a simple process of sending any notice/circular/intimation to all approved
groups.

(a) Project Guide
8.3 Pre-condition:
a. All the class id for which the group entry is valid should have been identified in
master prior to entry of data here.
b. All the students are identified by their roll numbers and class id, the master information
of which should have been existing in the system.

a. The faculty shall select at least one group to which any intimation needs to be sent.
c. Once validated, the group description, class id, class description etc. shall be
displayed. The intimation text shall be captured.
d. Further all the other groups which belongs to same class shall be default displayed in
the detail table. If selected, then the same message shall also be sent to the selected
group also.
8.5 Post Actions:

a. Intimation message will be sent to selected groups.

a. No deviations shall be entertained for sending intimations.
27
Use Case: Send Intimation
Information
On Group
Group details for

for sending
intimation PROJECT GUIDE
Selecting groups.
<<Send Intimation>>
Send
Intimation
Intimation
Delivered
Figure 4.1.1.3.8 : Use Case for Send Intimation
28
Use Case: Generate Reminders
9.1 Purpose: To send any reminders to all approved groups who have overshot their project
deadlines.
This is a simple process of sending a reminder to all approved groups executing project
regarding lapse of submission date.

(a) Project Guide
9.3 Pre-condition:
Approved Groups having missed deadlines must exist.

a. The faculty shall select at least one group to which any reminder needs to be sent.
c. Once validated, the group description, class id, class description etc. shall be
displayed. The default reminder text shall be displayed. Any amendments or additions
shall be captured.
d. Further all the other groups which belongs to same class shall be default displayed in
the detail table who have missed submission deadlines with default selection. If
selection not removes, then the same message shall also be sent to the selected group
also.
9.5 Post Actions:

a. Reminders will be sent to the groups that have missed the deadlines.

a. No deviations shall be entertained for generating and sending reminders.
29
Use Case: Generate Reminders
Information
On Group
Group details for

for generating
reminders PROJECT GUIDE
Selecting groups.
<<Send Reminder>>
Send
Reminder
Reminder
Delivered
Figure 4.1.1.3.9 : Use Case for Generate Reminders
30
4.1.2 Conceptual Level Class Diagram
Class diagram is a static diagram. It represents the static view of an application. Class diagram
is not only used for visualizing, describing, and documenting different aspects of a system but
also for constructing executable code of the software application.
Class diagram describes the attributes and operations of a class and also the constraints
imposed on the system. The class diagrams are widely used in the modeling of objectoriented
systems because they are the only UML diagrams, which can be mapped directly with object-
oriented languages.
4.1.3 Conceptual Level Sequence Diagram

A sequence diagram simply depicts interaction between objects in a sequential order i.e. the
order in which these interactions take place. We can also use the terms event diagrams or event
scenarios to refer to a sequence diagram. Sequence diagrams describe how and in what order
the objects in a system function. These diagrams are widely used by businessmen and software
developers to document and understand requirements for new and existing systems.
4.1.4 Conceptual Level Activity Diagram

An activity diagram is a UML diagram that models the dynamic aspects of a system. It is a
simplification of the UML state chart diagram for modeling control flows in computational and
organizational processes. It allows you to represent a functional decomposition of a system
behavior. An activity diagram provides a complete specification of a behavior and not, like the
interaction diagrams, a single possible scenario.
Whereas a state chart diagram focuses on the implementation of operations in which most of
the events correspond precisely to the end of the preceding activity, the activity diagram does
not differentiate the states, the activities and the events.
The activity diagram gives a simplified representation of a process, showing control flows
(called transitions) between actions performed in the system (called activities). These flows
represent the internal behavior of a model element (use case, package, classifier or operation)
from a start point to several potential end points.
31
4.2 Design
4.2.1 Design Concept
The purpose of the design phase is to plan a solution of the problem specified by the
requirement of the problem specified by the requirement document. This phase is the first step
in moving from the problem domain to the solution domain. In other words, starting with what
is needed; design takes us towards how to satisfy the needs. The design of system is the most
critical factor affecting the quality of the software and has major impact on testing and
maintenance. The output of this phase is the design document.
4.2.2. Design Technique

System Design
System design provides the understandings and procedural details necessary for implementing
the system recommended in the system study. Emphasis is on the translating the performance
requirements into design specifications. The design phase is a transition from a user-oriented
document (System proposal) to a document oriented to the programmers or database personnel.
32
DETAILED DESIGN
PROJECTOSCOPE TRANSACTION SPECIFICATIONS:
MASTER TOP SHEET – SUBJECT MASTER
Table 4.2.2.1
System : Projectoscope
Master Name : Subject Master
Purpose : To capture Unique Subjects that are allowed for

execution of any of the minor / major project
Prepared By : Data Administrator in consultation with Faculty
Brief Description : This master shall contain the details of all the valid
subjects that are being taught and which are eligible
as being selected for execution of any minor, major or
both types of Projects
Pre-Requisites : None
Remarks : -
33
MASTER VALIDATION SHEET – SUBJECT MASTER
Table 4.2.2.2
Field Name Field Field Attributes Critical Validation/ Remarks

Type Length
Subject Code C 5 E/M/K Should be Unique
Must be entered
Primary Key
Subject VC 50 E/M Mandatory Field
Description
34
LAYOUT
Figure 4.2.2.1 : Subject Master Layout
35
MASTER TOP SHEET - CLASS MASTER
Table 4.2.2.3
Master Name : Class Master
Purpose : To capture data for various classes and the Subjects

taught in those classes that are allowed for execution
of any of the minor / major project
Brief Description : This master shall contain the details of all the classes
for which the students belonging to them need to
execute any minor/major project and the valid
subjects that are being taught and which are eligible
as being selected for execution of any minor, major or
both types of Projects
Pre-Requisites : Subject codes should have been defined in Subject

Master
Remarks : This master established the relationship between

classes and the various subjects that are being taught
for the class
36
MASTER VALIDATION SHEET – CLASS MASTER
Table 4.2.2.4

Type Length
Class Code C 5 E/M/K Should be Unique
Must be entered
Primary Key
Class VC 50 E/M Mandatory Field
Description
Department VC 50 E/M Mandatory Field
Institute Name VC 50 E/M Mandatory Field
DETAIL TABLE
Subject Code C 5 E/M Should be Unique in detail table
Should be valid as per Subject
Master
Subject VC 50 D Displayed for the subject code
Description entered
37
LAYOUT
Figure 4.2.2.2 : Class Master Layout
38
MASTER TOP SHEET – STUDENT MASTER
Table 4.2.2.5
Master Name : Student Master
Purpose : To capture data for various students who are enrolled

for a particular class and to further specify the various
semesters along with their calendar duration
Brief Description : This master shall contain the details of all the students
and information on their class to which they belong.
It specifies calendar wise duration in various
semesters they shall be studying
Pre-Requisites : Class codes should have been defined in Class Master
Remarks : The email id and mobile number captured here shall

be used to communicate with the students regarding
matters related to project and subsequent follow-ups.
39
MASTER VALIDATION SHEET – STUDENT MASTER
Table 4.2.2.6

Type Length
Roll no. C 10 E/M/K Should be Unique
Must be entered
Primary Key
Student VC 50 E/M Mandatory Field
Name
Gender C 6 E/M Mandatorily select form List
Choice values “Male/Female”
Class Code C 5 E/M Should be valid as per Class
Master
Class VC 50 D Displayed from Class Master for
Description valid class code entered
Mobile Number N 10 E/M Should not be blank
all 10 digits should be entered
first digit cannot be 0 (zero)
(Should be > 999999999)
Email Id VC 50 E/M Should not be blank
Group Id C 12 D Not entered here
Shall be displayed if data
available for record (student)
DETAIL TABLE
Semester N 1 E/M Should be mandatorily entered
Valid Range is greater than 0
(zero) and Less than 9
From Date D 10 E/M Should be a valid Date
To Date D 10 E/M Should be a valid date
Should be greater than from date
entered
40
LAYOUT
Figure 4.2.2.3 : Student Master Layout
41
MASTER TOP SHEET – FACULTY MASTER
Table 4.2.2.7
Master Name : Faculty Master
Purpose : To capture the data for various faculties who are

eligible to guide a project for a particular class and
subject combination.
Brief Description : This master shall contain the details of all the
faculties eligible to act as Project Guide for a Class +
Subject combination.
Pre-Requisites : Class codes and subject codes should have been
defined in Class Master
Remarks : The email id and mobile number captured here shall

be used to communicate with the students regarding
matters related to project and subsequent follow-ups.
42
MASTER VALIDATION SHEET - FACULTY MASTER
Table 4.2.2.8

Type Length
Faculty Id. C 5 E/M/K Should be Unique
Must be entered
Primary Key
Faculty VC 50 E/M Mandatory Field
Name
Gender C 6 E/M Mandatorily select form List
Choice values “Male/Female”
Mobile Number N 10 E/M Should not be blank
all 10 digits should be entered
first digit cannot be 0 (zero)
(Should be > 999999999)
Email Id VC 50 E/M Should not be blank
DETAIL TABLE
Master
Subject Code C 5 E/M Should be Unique combination
with Class code in detail table
Should be valid as per Class
Master for the class code entered
Description entered from subject master
43
LAYOUT
Figure 4.2.2.4 : Faculty Master Layout
44
MASTER TOP SHEET – STANDARD PROJECT STAGES
Table 4.2.2.9
Master Name : Standard Project Stages
Purpose : To serve as the default value suggestions to students

to state project schedule while proposing a project.
Brief Description : This master is basically a configuration parameter

master holding a data shall contain the details standard
project stages along with their specific deliverables,
for a Class + Subject + Project Type combination.
Pre-Requisites : Class codes and subject codes should have been
defined in Class Master
Remarks : -
45
MASTER VALIDATION SHEET – STANDARD PROJECT STAGES
Table 4.2.2.10

Type Length
Master
Subject Code C 5 E/M Should be valid as per Class
Master for the class code entered
Description entered from subject master
Project Type C 5 E/M Mandatorily select form List
Choice values “Minor/46ajor”
Standard N 5 E/M Should be >0
Project Must be entered
Duration (In
Days)
DETAIL TABLE
Stage No. N 2 G Generated as Row Number
Project Stage VC 50 E/M Mandatorily Entered
Deliverable VC 50 E/M Mandatorily Entered
Req. No. Of N 5 E/M Mandatorily Entered
Days Should be > 0
Sum of all rows = Standard

Project Duration defined in
Header
46
LAYOUT
Figure 4.2.2.5 : Standard Project Stages Layout
47
TRANSACTION TOP SHEET - REGISTER GROUP
Table 4.2.2.11
Transaction Name : Register Group
Purpose : To capture details related to a proposed group. This is
a simple process of updating basic records into the
Projectoscope database. This is applicable for those
students who have decided to form a group for
executing the project.
Prepared By : Student
Brief Description : a. Students intending to propose their formation of
group for executing any project shall invoke this
transaction.
b. They will select the class to which they belong and
which is identified for project execution
c. They shall enter their roll numbers in detail table.
Once the roll number is entered it shall be validated
from student master for its existence for the class id
entered.
d. Once roll number is validated then all student
information like name, email id, mobile number shall
be displayed. While validating it shall be validated
that the said roll number is not part of any other
group.
e. Students shall be required to select only one roll
number who will be identified as the group leader.
Two leaders cannot be selected and there has to be at
least one leader.
f. The group Id shall be generated as combination of
4digit Year+class ID+3 digit running serial
g. All the data demanded in this transaction is
mandatory
h. The record shall be saved with Status = “NEW”.
i. Unless approved, the transaction can be edited i.e.
the record with status = “NEW” can be edited to
amend the group participants.
Pre-Requisites : All the class id for which the group entry is valid
should have been identified in master prior to entry of
48
data here.
All the students are identified by their roll numbers
and class id, the master information of which should
have been existing in the system
Remarks : The record created here shall be treated as the Group
Composition proposed to the Project Guide seeking
his/her approval for the group so that they can proceed
with next stage i.e. conceptualising and proposing the
project
49
TRANSACTION VALIDATION SHEET - REGISTER GROUP
Table 4.2.2.12

Type Length
Group Id C 10 G Generated as combination of 4
digits of Year+Class Id+3 digit
running serial
Group VC 50 E/M Should not be empty
Description
Class Id C 5 E/M Should be valid as per Class
Master
Description the Class Id entered
Detail Table
Sr.no. N 2 G Generated as Row Number
Roll Number C 12 E/M Should be valid as per student
Master for the Class Id Entered
Student Name VC 50 D Displayed form Student Master
for the Roll Number Entered
Email Id VC 50 D Displayed form Student Master
Mobile No. N 10 D Displayed form Student Master
Leader Y/N C 1 E/M Default Value is Set to “N”,
Before Saving the record, At least
one row to have value “Y”
50
LAYOUT
Figure 4.2.2.6 : Register Group Layout
51
TRANSACTION TOP SHEET - APPROVE GROUP
Table 4.2.2.13
Transaction Name : Approve Group
Purpose : To approve details related to a proposed group. This is
a simple process of approving the basic records
created by students as groups proposed into the
ProjectoScope database. This is applicable for faculty
(project guide) who are supposed to approve a group
formed by the students.
Prepared By : Faculty (Project Coordinator or Project Guide)

Brief Description : a. The students shall approach the faculty
(project coordinator or project guide) to inform
the project group constitution and the group
code allotted by the system.
b. The faculty or project guide intending will in
return evaluate the group constituent students
and then either approve the group or shall ask
to shuffle some of members.
c. In case the formation is accepted by faculty
then the faculty shall enter group code.
d. Once the group code is validated the rest of the
group information shall be displayed on the
screen.
e. The faculty shall then mark “Approve” on the
record. The record status shall be changed
from with Status = “APPROVED”.
f. Once approved the group cannot be amended,
it can only be deregistered.
Pre-Requisites : All the groups proposed for the approval should have
been entered the system first with status = “NEW”
Remarks : No record shall be created here. Only status update is
allowed.
52
TRANSACTION VALIDATION SHEET – APPROVE GROUP
Table 4.2.2.14
Type Length
Group Id C 10 E/M Should be valid as per Register
Group Transaction with Status =
‘NEW’
Group VC 50 D Displayed from the Group Master
Description for the Group Displayed
Class Id C 5 D Displayed for the Valid Group Id
entered
Description the Class Id Displayed
Detail Table
Sr.no. N 2 D Displayed for the Valid Group Id
entered
Roll Number C 12 D Displayed for the Valid Group Id
entered
Student Name VC 50 D Displayed for the Valid Group Id
entered
Email Id VC 50 D Displayed for the Valid Group Id
entered
Mobile No. N 10 D Displayed for the Valid Group Id
entered
Leader Y/N C 1 D Displayed for the Valid Group Id
entered
53
LAYOUT
Figure 4.2.2.7 : Approve Group Layout
54
TRANSACTION TOP SHEET - DEREGISTER GROUP
Table 4.2.2.15
Transaction Name : Deregister Group
Purpose : To capture deregistration information of an active
approved group. This is a simple process of
deregistering the existing approved groups into the
Projectoscope database. This is applicable for faculty
(project guide) who are supposed to deregister a an
approved group.

Brief Description : a. Either the students shall approach the faculty
or the faculty may decide the deregistration of
group
b. The faculty or project guide has to simply
select a group for deregistration.
c. Once deregistered, the group can not be made
alive again with same group id.
d. Once the group code is validated the rest of the
group information shall be displayed on the
screen.
e. The faculty shall then mark “Deregistered” on
the record. The record status shall be changed
from with Status = “DEREGISTERED”.
f. Once approved group is deregistered it can
only be recreated.
Pre-Requisites : All the groups proposed for the deregisteredshould
have been existing in the system first with status =
“APPROVED”
allowed.
55
TRANSACTION VALIDATION SHEET – DEREGISTER GROUP
Table 4.2.2.16

Type Length
‘APPROVED’
Class Id C 5 D Displayed for the Valid Group Id
entered
Description the Class Id Displayed
Detail Table
entered
Roll Number C 12 D Displayed for the Valid Group Id
entered
Student Name VC 50 D Displayed for the Valid Group Id
entered
Email Id VC 50 D Displayed for the Valid Group Id
entered
Mobile No. N 10 D Displayed for the Valid Group Id
entered
Leader Y/N C 1 D Displayed for the Valid Group Id
entered
56
LAYOUT
Figure 4.2.2.8 : Deregister Group Layout
57
TRANSACTION TOP SHEET – PROPOSE PROJECT
Table 4.2.2.17
Transaction Name : Propose Project
Purpose : To capture project proposals from approved groups.
This is a simple process of capturing an intent of the
student group regarding what project they want to
execute, under whose guidance they would be
executing, and what is going to be their project
execution schedule.
Prepared By : Student Group

Brief Description : a. Approved Student Groups intending to propose
any project shall invoke this transaction.
c. Once validated they are required to key in
subject, semester, title of their project, name of
their project guide, select the class to which they
belong and which is identified for project
execution.
d. They are also supposed to declare the project
duration along with the various project stages,
specific deliverable and its schedule.
e. Default help on project stages and deliverable
shall be variable to them as default selection.
Pre-Requisites : The group Id entered must have the status
“APPROVED”
Remarks : All the projects proposed shall be created in the
system with status as “NEW”. The record created here
shall be treated as the project proposed to the Project
Guide seeking his/her approval for the project so that
they can proceed with next stage.
58
TRANSACTION VALIDATION SHEET – PROPOSE PROJECT
Table 4.2.2.18

Type Length
‘APPROVED’
Project Type C 5 E/M Mandatorily select form List
Choice values “Minor/maJor”
Subject Code C 5 D Mandatorily entered
Should be valid as per Class
Master for Class Id of Group
Subject VC 50 D Displayed from Subject Master
Description for the Subject Code Displayed
Semester N 1 E/M Should be mandatorily entered
Should be valid as per Student
Master for students belonging to
this group Id for from date and to
date mentioned (outside period
are invalid)
Valid Range is greater than 0
(zero) and Less than 9
Project Guide C 5 E/M Should be Valid as per Faculty
Master for the Class and Subject
combination for the Group
Must be entered
Project Guide VC 50 D Displayed form Faculty Master

Name for the Faculty Id (Project Guide
Code) Entered
Project Title VC 100 E/M Mandatorily Entered
No specific validation
Project Start D Date E/M Should be valid date between
Date semester period mentioned in
Student Master for Students of
Group Id Entered
Project D Date E/M Should be valid date between
59
Completion semester period mentioned in
Date Student Master for Students of
Group Id Entered
Should also be greater than
Project Start Date
Duration N 3 C Calculated as completion date –
start date
Detail Table
entered
Project Stage C 12 E/M Displayed for the Valid Group Id
entered
Can be entered, Value in the field
is Mandatory
Deliverable VC 50 E/M Displayed for the Valid Group Id
entered
Can be entered, Value in the field
is Mandatory
Start Date D Date E/M Mandatorily Entered
Should be Less than equal to end
date mentioned in header and
First row value should be equal to
the Project Start Date in Header
Completion D Date E/M Mandatorily Entered
Date Should be greater than equal to
start date
Last row value should be equal to
the Project End Date in Header
Days Proposed N 3 C Calculated and Displayed as
Completion Date – Start Date
60
LAYOUT
Figure 4.2.2.9 : Propose Project Layout
61
TRANSACTION TOP SHEET – APPROVE PROJECT
Table 4.2.2.19
Transaction Name : Approve Project
Purpose : To approve details related to a proposed project. This
is a simple process of approving the basic records
created by students on behalf of a group, proposed
into the Projectoscope database. This is applicable for
faculty (project guide) who are supposed to approve a
proposed by the group.

Brief Description : a. The students on behalf of a group shall approach
the faculty (project coordinator or project guide) to
inform the project proposedwith the group code
allotted to them by the system.
b. The faculty or project guide intending will in
return evaluate the project synopsis and then either
approve the project or shall ask to amend the
contents.
c. In case the proposal is accepted by faculty then the
faculty shall enter group code.
d. Once the group code is validated from the project
proposed database, the rest of the project
information shall be displayed on the screen.
e. The faculty shall then mark “Approve” on the
record. The record status shall be changed from
“NEW” to Status = “APPROVED”.
f. Once approved the project cannot be amended, it
can only be terminated by deregistration of the
group.
Pre-Requisites : All the projects proposed for the approval should have
been entered the system first with status = “NEW”
allowed.
62
TRANSACTION VALIDATION SHEET – APPROVE PROJECT
Table 4.2.2.20

Type Length
Project Transaction with Status =
‘NEW’
Project Type C 5 E/M Displayed from the Project
Transaction for the group code
displayed
Subject Code C 5 D Displayed from the Project
displayed
Semester N 1 E/M Displayed from the Project
displayed
Project Guide C 5 D Displayed from the Project
displayed
Code) Displayed
Project Title VC 100 E/M Displayed from the Project
displayed
Project Start D Date E/M Default value Displayed from the
Date Project Transaction for the group
code displayed
Should be valid date between
semester period mentioned in
Group Id Entered
Project D Date E/M Default value Displayed from the
Completion Project Transaction for the group
Date code displayed
63
Should be valid date between
semester period mentioned in
Group Id Entered
Should also be greater than
Project Start Date
Duration N 3 C Calculated and Displayed as
completion date – start date
Detail Table
Sr.no. N 2 D Default value Displayed from the
Project Transaction for the group
code displayed
Project Stage C 12 E/M Displayed for the Valid Group Id
entered
Can be edited, Value in the field
is Mandatory
Deliverable VC 50 E/M Displayed for the Valid Group Id
entered
Can be edited, Value in the field
is Mandatory
Start Date D Date E/M Displayed for the Valid Group Id
entered
Mandatorily Entered
Should be Less than equal to end
date mentioned in header and
First row value should be equal to
the Project Start Date in Header
Completion D Date E/M Displayed for the Valid Group Id
Date entered
Mandatorily Entered
Should be greater than equal to
start date
Last row value should be equal to
the Project End Date in Header
Days Proposed N 3 C Calculated and Displayed as
Completion Date – Start Date
64
LAYOUT
Figure 4.2.2.10 : Approve Projects Layout
65
TRANSACTION TOP SHEET – REPORT PROJECT PROGRESS
Table 4.2.2.21
Transaction Name : Report Project Progress
Purpose : To capture project stage wise status of approved
projects from approved groups.
This is a simple process of capturing stage wise
completion of various projects as reported by various
student groups.
Prepared By : Student Group

Brief Description : a. Approved Student Groups with approved
projects, intending to propose progress of the
project shall invoke this transaction.
c. Once validated they are required to key in the
date and completion against first project stage
eligible for status update.
d. For all projects for which the project stages are
already marked completed and further
authenticated shall be displayed as read only and
cannot be edited.
Pre-Requisites : The project stage row for a given project marked as

completed shall be stored with the status
“COMPLETED”
Remarks : All the projects progress reported here shall be treated
as the projectstatus proposed to the Project Guide
seeking his/her approval for the same so that they can
proceed with next stage.
66
TRANSACTION VALIDATION SHEET – REPORT PROJECT PROGRESS
Table 4.2.2.22

Type Length
‘APPROVED’
Project Type C 5 D Displayed from the Project
transaction for the Group Id
Selected
Subject Code C 5 D Should be valid as per Class
Master for Class Id of Group
Semester N 1 D Displayed from the Project
Selected
Project Guide C 5 D Displayed from the Project
Selected
Code) Entered
Project Title VC 100 D Displayed from the Project
Selected
Project Start D Date D Displayed from the Project
Date transaction for the Group Id
Selected
Project D Date D Displayed from the Project
Completion transaction for the Group Id
Date Selected
Duration N 3 D Displayed from the Project
Selected
67
Detail Table
Sr.no. N 2 D Displayed from the Project
Selected
Deliverable VC 50 E/M Displayed from the Project
Selected
Mark Checkbox E Only unauthenticated single
Completion (first) or successive stages can be
checked here by collection
Completion D Date D/E/M Displayed from the Project
Selected for authenticated status
Else
Mandatorily Entered
max(last authenticated
completion date)
68
LAYOUT
Figure 4.2.2.11 : Report Project Progress Layout
69
TRANSACTION TOP SHEET – AUTHENTICATE PROJECT PROGRESS
Table 4.2.2.23
Transaction Name : Authenticate Project Progress
Purpose : To authenticateproject stage wise status of approved
projects from approved groups.
This is a simple process of approving stage wise
completion of various projects as reported by various
student groups.
Prepared By : Faculty (Project Guide or Project Coordinator)

Brief Description : a. Unauthenticated Project Status reported by
Approved Student Groups with approved projects,
intending to report progress of the project shall
serve as the basis this transaction.
b. The faculty will enter their group code for
validation.
c. Once validated they are required to key in the
date and authentication against first project stage
eligible for status update.
d. For all project stages for which the project stages
are already marked completed and further
authenticated shall be displayed as read only and
cannot be edited.
Pre-Requisites : The projects with status as “REPORTED” or

“AUTHENTICATED” must exist
Remarks : The project stage row for a given project marked as
completed shall be stored with the status
“AUTHENTICATED”. All the projects progress
authenticated here shall be treated as the project status
approved by the Project Guide mentioning his/her
approval for the same so that groups can proceed with
next stage.
70
TRANSACTION VALIDATION SHEET – AUTHENTICATE PROJECT PROGRESS
Table 4.2.2.24

Type Length
Group Id C 10 E/M Should be valid as per Report
ProjectStatus Transaction with
Status = ‘REPORTED”
Group VC 50 D Displayed from the Group Table
Project Type C 5 D Displayed from the Project Status
Selected
Subject Code C 5 D Displayed from the Project Status
Selected
Semester N 1 D Displayed from the Project Status
Selected
Project Guide C 5 D Displayed from the Project Status
Selected
Project Guide VC 50 D Displayed from the Project Status
Name transaction for the Group Id
Selected
Project Title VC 100 D Displayed from the Project Status
Selected
Project Start D Date D Displayed from the Project Status
Selected
Project D Date D Displayed from the Project Status
Completion transaction for the Group Id
Date Selected
Duration N 3 D Displayed from the Project Status
Selected
71
Detail Table
Sr.no. N 2 D Displayed from the Project Status
Selected
Project Stage C 12 E/M Displayed from the Project Status
Selected
Deliverable VC 50 E/M Displayed from the Project Status
Selected
Mark Checkbox E Only unauthenticated single
Authentication (first) or successive stages can be
checked here by collection
Authentication D Date D/E/M Displayed from the Project
Selected for authenticated status
Else
Mandatorily Entered
max(last authenticated
completion date)
72
LAYOUT
Figure 4.2.2.12 : Authenticate Project Progress Layout
73
TRANSACTION TOP SHEET – SEND INTIMATION
Table 4.2.2.25
Transaction Name : Send Intimation
Purpose : To send any intimation to all approved groups.
This is a simple process of sending any
notice/circular/intimation to all approved groups,

Brief Description : a. The faculty shall select at least one group to which
any intimation needs to be sent.
b. The faculty will enter their group code for
validation.
c. Once validated, the group description, class id,
class description etc. shall be displayed. The
intimation text shall be captured.
d. Further all the other groupswhich belongs to
same class shall be default displayed in the detail
table. If selected, then the same message shall
also be sent to the selected group also.
Pre-Requisites : Approved Groups must exist

Remarks :
74
TRANSACTION VALIDATION SHEET – SEND INTIMATION
Table 4.2.2.26

Type Length
Group Id C 10 E/M Should be valid as per Group
Transaction with Status Not
Equal to “NEW”

Class Id C 5 D Displayed from the Group
Selected
Description the Subject Code Displayed
Intimation Text VC 200 E/M Should not be blank
DETAIL TABLE
Group Id C 10 D All groups belonging to same
class with Status Not Equal to
“NEW” shall be displayed for
which tick mark selection shall be
done
Group Selection Check Box Tick mark selection shall be

accepted and the message shall be
replicated to all the leaders of the
Group by email to group leaders
75
LAYOUT
Figure 4.2.2.13 : Send Intimation Layout
76
TRANSACTION TOP SHEET - GENERATE REMINDERS
Table 4.2.2.27
Transaction Name : GenerateReminder(s)
Purpose : To send any reminders to all approved groups who
have overshot their project deadlines.
This is a simple process of sending areminder to all
approved groups executing project regarding lapse of
submission date.

Brief Description : e. The faculty shall select at least one group to
which any reminder needs to be sent.
f. The faculty will enter their group code for
validation.
g. Once validated, the group description, class id,
class description etc. shall be displayed. The
default reminder text shall be displayed. Any
amendments or additions shall be captured.
h. Further all the other groups which belongs to
same class shall be default displayed in the detail
table who have missed submission deadlines with
default selection. If selection not removes, then
the same message shall also be sent to the
selected group also.
Pre-Requisites : Approved Groups having missed deadlines must exist

Remarks :
77
TRANSACTION VALIDATION SHEET – GENERATE REMINDERS
Table 4.2.2.28

Type Length
Group Id C 10 E/M Should be valid as per Group
Transaction with Status Not
Equal to “NEW” AND Not Equal
to “APPROVED”

Class Id C 5 D Displayed from the Group
Selected
Description the Subject Code Displayed
Reminder Text VC 200 E/M Standard Text Displayed as
“Dear Group Members You have
missed project submission
deadline. Please expedite the
submission and inform your
guide”.
Should not be blank
Any change to this or addition to
this shall be accepted
DETAIL TABLE
Group Id C 10 D All groups belonging to same
class with Status Not Equal to
“NEW” and status not equal to
“APPROVED” shall be displayed
for which tick mark selection
shall be done as default, the
faculty may deselect some.
Group Selection Check Box Tick mark selection shall be

accepted and the message shall be
replicated to all the leaders of the
Group by email to group leaders
78
LAYOUT
Figure 4.2.2.14 : Generate Reminders Layout
79
OUTPUT TOP SHEET
Table 4.2.2.29
Output Name: : Subject Master List

Frequency: : As and When
Generated By: : Database Administrator
Distribution: : Faculty (Project Guide), Students
Selection Criteria: : -
Grouped On : Subject Code
Sorting Sequence : Subject Code
Remarks : This report lists out all the subject codes along-with their
descriptions, which can be considered for conceptualizing
and executing any minor/major project.
80
Figure 4.2.2.15 : Subject Master List
81
OUTPUT TOP SHEET
Table 4.2.2.30
Output Name: : Class Master List

Grouped On : Class Code
Sorting Sequence : Class Code, Subject Code
Remarks : This report lists out all the class codes along-with their
descriptions, department, institute etc. and the subject
codes allowed for that class which can be considered for
conceptualizing and executing any minor/major project.
82
Figure 4.2.2.16 : Class Master List
83
OUTPUT TOP SHEET
Table 4.2.2.31
Output Name: : Student Master List

Grouped On : Student Code
Sorting Sequence : Student Code, Class Code
Remarks : This report lists out all the student codes along with their
personal details such as roll number, gender, semester,
class, email, mobile number etc. These details shall be
used while formation of the group in transactions.
84
Figure 4.2.2.17 : Student Master List
85
OUTPUT TOP SHEET
Table 4.2.2.32
Output Name: : Faculty Master List

Grouped On : Faculty Code
Sorting Sequence : Faculty Code, Class Code, Subject Code
Remarks : This report lists out all the faculty codes along with their
personal details such as gender, email, mobile number,
classes and subjects which they teach, etc. These details
shall be used while capturing details of the project and its
progress in transactions.
86
Figure 4.2.2.18 : Faculty Master List
87
OUTPUT TOP SHEET
Table 4.2.2.33
Output Name: : Standard Project Stage Master List

Distribution: : Faculty (Project Guide)
Sorting Sequence : Class Code, Subject Code,
Remarks : This report lists out all the stages defined for a project
Which shall be followed to track the progress of the
project.
88
Figure 4.2.2.19 : Standard Project Stage List
89
OUTPUT TOP SHEET
Table 4.2.2.34
Output Name: : Faculty wise Project List

Selection Criteria: : All / Specific Faculty
Grouped On : Faculty Code
Sorting Sequence : Class Code, Group, Subject Code,
Remarks : This report lists out all the projects for all or specific
faculties with its status along with class, group, subject
etc.
90
Figure 4.2.2.20 : Faculty wise Project List
91
OUTPUT TOP SHEET
Table 4.2.2.35
Output Name: : Class wise Project List

Selection Criteria: : All / Specific Classes
Sorting Sequence : Faculty Code, Group, Subject Code,
classes with its status along with faculty, group, subject
etc.
92
Figure 4.2.2.21 : Class wise Project List
93
OUTPUT TOP SHEET
Table 4.2.2.36
Output Name: : Subject wise Project List

Selection Criteria: : All / Specific Subject(s)
Grouped On : Subject Code
Sorting Sequence : Class Code, Group, Faculty Code,
subjects with its status along with class, group, faculty
etc.
94
Figure 4.2.2.22 : Subject wise Project List
95
OUTPUT TOP SHEET
Table 4.2.2.37
Output Name: : Status wise Project List

Selection Criteria: : All / Specific Semester(s), Class(es), Subject(s),
Facult(y/ies)
Grouped On : Semester, Class, Subject, Faculty
Sorting Sequence : Group, Stage
Semester(s), Class(es), Subject(s), Facult(y/ies) with its
status along with group.
96
Figure 4.2.2.23 : Status wise Project List
97
OUTPUT TOP SHEET
Table 4.2.2.38
Output Name: : Active Project List

Facult(y/ies)
status along with group. Only approved and Running
projects shall qualify to be included here.
98
Figure 4.2.2.24 : Active Project List
99
OUTPUT TOP SHEET
Table 4.2.2.39
Output Name: : Overdue Project List

Facult(y/ies)
status along with group. Only approved and Running
projects for which a project stage exists for which end
date has lapsed and neither student has marked
completion and/or faculty has not authenticated the same
shall qualify to be included here.
100
Figure 4.2.2.25 : Overdue Project List
101
4.2.3. Modeling
4.2.3.1. Detailed Class Diagram
Figure 4.2.3.1 : Class Diagram
102
4.2.3.2 Interaction Diagram
4.2.3.2.1 Sequence Diagram
Figure 4.2.3.2.1: Sequence Diagram
103
4.2.3.2.2 Collaboration Diagram
Figure 4.2.3.2.2: Collaboration Diagram
4.2.3.3 State Diagram
Figure 4.2.3.3: State Diagram
104
4.2.3.4 Activity Diagram
Figure 4.2.3.4 : Activity Diagram
105
4.2.3.5 Object Diagram
Figure 4.2.3.5 : Object Diagram
4.2.3.6 Deployment Diagram
Figure 4.2.3.6 : Deployment Diagram
106
5. Methodology and Implementation Phase
5.1 Methodology
Projectoscope is developed using Waterfall Model.
5.1.1 Description
The first process model to be introduced was Waterfall Model. It is a linear-sequential life cycle
model. It is an easy to understand model and can be used with ease. In a waterfall model, before
starting new phase, it is necessary that its preceding phase is complete. Also, there is no scope
for overlap of two phases in Waterfall model. The outcome of a phase serves as input for the
next phase that too sequentially.
This type of model is suitable forprojects which are small and do not have uncertain
requirements. End of each phase is followed by a review. This review determines if the project
is on correct path and is it okay to continue with it or should the project be discarded. Testing
takes place only after the development is complete.
Each phase of The Waterfall model is quite precise well defined because development of one
phase starts only when the previous phase is complete. Since the phase’s falls from higher level
to lower level, like a water fall, it’s named as waterfall model.
Figure 5.1.1.1 : Waterfall Model
107
Following are the sequential phases of waterfall model:
 Requirement Gathering and analysis: All the possible requirement of the system, that
has to be developed, are gathered in this phase and collectively form a requirement
specification document.
 System Design: The requirement specifications from the previous phase are studied in
this phase and design for the system is prepared. System Design is helpful for specifying
hardware and system requirements and also helps in defining overall system architecture.
 Implementation: With inputs from system design, the system is first developed in
small programs called units, which are integrated in the next phase. After this Unit Testing is
carried out where every single unit is developed and its functionality is tested.
 Integration and Testing: All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system is tested for
any faults and failures.
5.1.2. Advantage & Disadvantages

Advantage
 This model is simple and easy to understand and use.

 It is easy to manage due to the rigidity of the model – each phase has specific deliverables
and a review process.
 In this model phases are processed and completed one at a time. Phases do not overlap.
 Waterfall model works well for smaller projects where requirements are very well
understood.
 The entry and exit criteria are well defined, so it easy and systematic to proceed with
quality.
 Results are well documented.
Disadvantage
 After an application enters the testing stage, It is very difficult to go back and change
something that was not well-thought out in the concept stage.
 Final working model can be seen only when we approach the end of life cycle. There is
no working software in initial or middle phases. Thus, this increases the probability of
risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Delivery of the final product is late as there is no prototype which is demonstrated
intermediately.
108
 Not suitable for the projects where requirements are changed frequently.
 Since the testing is done at later stage, it does not allow identifying the challenges and
risks in the earlier phase so the risk mitigation strategy is difficult to prepare.
 Not suitable for the projects where requirements are at a moderate to high risk of
changing.
5.1.3. Reasons for use

 Requirements are very clear and fixed.
 There are no ambiguous requirements.
 The project is short.
 It is good to use this model as the technology is well understood.
 Product definition is stable.
 Ample resources with required expertise are available freely
5.2 Implementation Phase

5.2.1. Language Used Characteristics
 Simple
It is very simple and easy to use, compare to other scripting language it is very simple
and easy, this is widely used all over the world.
 Interpreted
It is an interpreted language, i.e. there is no need for compilation.
 Faster
It is faster than other scripting language e.g. asp and jsp.
 Open Source
Open source means you no need to pay for use php, you can free download and use.
 Platform Independent
PHP code will be run on every platform, Linux, Unix, Mac OS X, Windows.
 Case Sensitive
PHP is case sensitive scripting language at time of variable declaration. In PHP, all
keywords (e.g. if, else, while, echo, etc.), classes, functions, and user-defined functions
are NOT case-sensitive.
109
5.2.2. Coding
The implementation of the designs involved coding and use of some tools that allow faster
development of software. The coding languages used were:
HTML: Scripting tool. It is used to develop the front interface for the project.
PHP: Used to create the logical part of the system.
Bootstrap : Used for developing responsive web pages.
JavaScript: Scripting tool for code validation.
CSS: Used for uniformity of the system pages.
MYSQL: Used to develop back end part of the system (Database).
Sample Code 1:
<?php
$uri_segment = $this->uri->segment(1).'/'.$this->uri->segment(2);
//$uri_segment = $this->uri->segment(1);
$dashboard = '';
$master = '';
$subject = '';
$class = '';
$student = '';
$faculty = '';
$standardProjectStage = '';
$reports = '';
$subjectList = '';
$classList = '';
$studentList = '';
$facultyList = '';
$standardProjectStageList = '';
switch ($uri_segment) {
case 'master/subject';
case 'master/addSubject';
case 'master/editSubject';
$subject = "class = 'active'";
break;
case 'master/class';
case 'master/addClass';
case 'master/editClass';
$class = "class = 'active'";
110
break;
case 'master/student';
case 'master/addStudent';
case 'master/editStudent';
$student = "class = 'active'";
break;
case 'master/faculty';
case 'master/addFaculty';
case 'master/editFaculty';
$faculty = "class = 'active'";
break;
case 'master/standardProjectStage';
case 'master/addProjectState';
case 'master/editProjectState';
$standardProjectStage = "class = 'active'";
break;
case 'reports/subjectList':
$reports = "class = 'active'";
$subjectList = "class = 'active'";
break;
case 'reports/classList':
$classList = "class = 'active'";
break;
case 'reports/studentList':
$studentList = "class = 'active'";
break;
case 'reports/facultyList':
$facultyList = "class = 'active'";
break;
case 'reports/standardProjectStageList':
$standardProjectStageList = "class = 'active'";
break;
default:
111
$dashboard = ' class="active"';
break;
}
?>
<aside>
<div id="sidebar" class="nav-collapse ">
<ul class="sidebar-menu" id="nav-accordion">
<li>
<a <?php echo $dashboard ?> href="<?php echo baseUrl() ?>admin">
<i class="fa fa-dashboard"></i>
<span>Dashboard</span>
</a>
</li>
<li>
<a <?php echo $subject ?> href="<?php echo baseUrl() ?>master/subject">
<span>Subject</span>
</a>
</li>
<li>
<a <?php echo $class ?> href="<?php echo baseUrl() ?>master/class">
<span>Class</span>
</a>
</li>
<li>
<a <?php echo $student ?> href="<?php echo baseUrl() ?>master/student">
<span>Student</span>
</a>
</li>
<li>
<a <?php echo $faculty ?> href="<?php echo baseUrl() ?>master/faculty">
<span>Faculty</span>
</a>
</li>
<li>
<a <?php echo $standardProjectStage ?> href="<?php echo baseUrl()
?>master/standardProjectStage">
112
<span>Standard Project Stage</span>
</a>
</li>
<li class="sub-menu">
<a href="javascript:;" <?php echo $reports ?>>
<i class="fa fa-file"></i>
<span>Reports</span>
</a>
<ul class="sub">
<li <?php echo $subjectList ?>><a href="<?php echo baseUrl()
?>reports/subjectList">Subject Master</a></li>
<li <?php echo $classList ?>><a href="<?php echo baseUrl()
?>reports/classList">Class Master</a></li>
<li <?php echo $studentList ?>><a href="<?php echo baseUrl()
?>reports/studentList">Student Master</a></li>
<li <?php echo $facultyList ?>><a href="<?php echo baseUrl()
?>reports/facultyList">Faculty Master</a></li>
<li <?php echo $standardProjectStageList ?>><a href="<?php echo baseUrl()
?>reports/standardProjectStageList">Standard Proj. Stage Master</a></li>
</ul>
</li>
</ul>
</div>
</aside>
Snapshot 1:
Figure 5.2.2.1 : Snapshot 1
113
Sample Code 2:
<?php $this->load->view('projectGuide/sideBar') ?>
<section id="main-content">
<section class="wrapper" style="min-height: 551px;">
<div class="row">
<div class="col-lg-12">
<ul class="breadcrumb">
<li><a href="<?php echo baseUrl() ?>admin"><i class="fa fa-home"></i>
Dashboard</a></li>
<li class="active">Deregister Group</li>
</ul>
</div>
</div>
<?php alert() ?>
<input type="hidden" id="hiddenGroupId">
<div class="row">
<div class="col-lg-12">
<section class="panel">
<div class="panel-body">
<?php //echo form_open_multipart(current_url(), array('role' => 'form')); ?>
<div class="row">
<div class="col-md-2">
<div class="form-group">
<label for="txtGroupCode">Group code</label>
<input type="text" name="txtGroupCode" id="txtGroupCode" class="form-control
input-sm" value="<?php //if(!empty($data[0]->groupId)) echo $data[0]->groupId; ?>"
disabled>
</div>
</div>
<label for="txtGroupDesc"> </label>
<input type="text" name="txtGroupDesc" id="txtGroupDesc" class="form-control
input-sm" value="<?php //if(!empty($data[0]->groupDescription)) echo $data[0]-
>groupDescription; ?>" disabled>
</div>
</div>
</div>
<div class="row">
<label for="classCode">Class code</label>
<input type="text" name="classCode" id="classCode" class="form-control input-
sm" value="<?php //if(!empty($data[0]->classCode)) echo $data[0]->classCode; ?>" disabled>
</div>
</div>
114
<label for="classDesc"> </label>
<input type="text" name="classDesc" id="classDesc" class="form-control input-
sm" value="<?php //if(!empty($data[0]->classDescription)) echo $data[0]->classDescription;
?>" disabled>
</div>
</div>
</div>
<div class="row">
<div class="table-responsive">
<table class="table table-bordered table-hover">
<thead>
<tr>
<th>Sr. No.</th>
<th>Roll No.</th>
<th>Student Name</th>
<th>Email Id</th>
<th>Mobile No.</th>
<th>Leader(Y/N)</th>
</tr>
</thead>
<tbody id="tbodyGrpupDetails">
</tbody>
</table>
</div>
</div>
</div>
<div class="row">
<button type="button" class="btn btn-danger pull-right" style="margin-left: 5px;"
onclick="goBack()">Cancel</button>
<button type="button" class="btn btn-primary pull-right" id="submit"
onclick="Deregister()">Deregister</button>
</div>
</div>
<?php //echo form_close(); ?>
</div>
</section>
</div>
</div>
</section>
</section>

<div id="Modal" class="modal fade" role="dialog">
115
<div class="modal-dialog modal-lg">
<div class="modal-content">
<div class="modal-header">
<button type="button" class="close" data-dismiss="modal">×</button>
<h4 class="modal-title">Group Details</h4>
</div>
<div class="modal-body">
<div class="row">
<div class="table-responsive">
<table class="table table-bordered table-hover">
<thead>
<tr>
<th>#</th>
<th>Group code</th>
<th>Group Description</th>
<th>Class code</th>
<th>Class Description</th>
<th class="text-center">Action</th>
</tr>
</thead>
<tbody id="tbodyGroup">
<?php /*
if(!empty($all)){
foreach ($all as $key => $value) {
?>
<tr>
<td><?php echo ($key+1); ?></td>
<td><?php echo $value->groupId; ?></td>
<td><?php echo $value->groupDescription; ?></td>
<td><?php echo $value->classCode; ?></td>
<td><?php echo $value->classDescription; ?></td>
<td class="text-center">
<a class="btn btn-info btn-xs" href="javascript:void(0)" data-toggle="tooltip"
title="View Details" onclick="getData(<?php echo $value->id; ?>)"><i class="fa fa-
eye"></i></a>
</td>
</tr>
<?php } } */ ?>
</tbody>
</table>
</div>
</div>
</div>
</div>
<div class="modal-footer">
116
<button type="button" class="btn btn-default" data-dismiss="modal">Close</button>
</div>
</div>
</div>
</div>
<script>
$(document).ready(function(){
getModal();
});
function getModal() {
$.ajax({
type:"POST",
cache:false,
url:"<?php echo baseUrl();?>projectGuide/deregisterGetAll",
//data:{ groupId:groupId },
beforeSend: function(){
$(".spinner").show();
},
success: function (response) {
debugger;
var jsonData = JSON.parse(response);
if(jsonData.length > 0){
$("#Modal").modal("show");
var tbody = $("#tbodyGroup");
tbody.empty();
var html = "";
$.each(jsonData, function (Index, Object) {
html += '<tr>'
html += '<td>'+(Index+1)+'</td>';
html += '<td>'+Object.groupId+'</td>';
html += '<td>'+Object.groupDescription+'</td>';
html += '<td>'+Object.classCode+'</td>';
html += '<td>'+Object.classDescription+'</td>';
html += '<td class="text-center"><a class="btn btn-info btn-xs"
href="javascript:void(0)" data-toggle="tooltip" title="View Details"
onclick="getData('+Object.id+')"><i class="fa fa-eye"></i></a></td>';
html += '</tr>'
});
tbody.append(html);
$(".spinner").hide();
}else{
//alertCustom("Data not found.");
$("#Modal").modal("hide");
}
117
}
});
}
function getData(id){
$("#Modal").modal("hide");
$("#hiddenGroupId").val(id);
$.ajax({
type:"POST",
cache:false,
url:"<?php echo baseUrl();?>projectGuide/getGroupData",
data:{ id:id },
},
debugger;
//alertCustom(response);
var jsonData = JSON.parse(response);
if(response == 0){
//alertCustom("Data not found.")
}else{
$("#txtGroupCode").val(jsonData.result1[0].groupId);
$("#txtGroupDesc").val(jsonData.result1[0].groupDescription);
$("#classCode").val(jsonData.result1[0].classCode);
$("#classDesc").val(jsonData.result1[0].classDescription);
var tbody = $("#tbodyGrpupDetails");

tbody.empty();
var html = "";
$.each(jsonData.result2, function (Index, Object) {
html += '<tr>'
html += '<td>'+(Index+1)+'</td>';
html += '<td>'+Object.rollNo+'</td>';
html += '<td>'+Object.studentName+'</td>';
html += '<td>'+Object.emailId+'</td>';
html += '<td>'+Object.mobileNo+'</td>';
html += '<td>'+Object.leader+'</td>';
html += '</tr>'
});
tbody.append(html);
}
}
});
118
}
function Deregister(){
var groupId = $("#hiddenGroupId").val();
debugger;
$.ajax({
type:"POST",
cache:false,
url:"<?php echo baseUrl();?>projectGuide/deregister",
data:{ groupId:groupId },
},
if(response == 1){
alertCustom("Deregister approved.");
$("#hiddenGroupId").val("");
clear();
}else{
alertCustom("Something went wrong.");
}
}
});
}
function clear(){
$("#txtGroupCode").val("");
$("#txtGroupDesc").val("");
$("#classCode").val("");
$("#classDesc").val("");
var tbody = $("#tbodyGrpupDetails");
tbody.empty();
getModal();
}
</script>
119
Snapshot 2:
Figure 5.2.2.2 : Snapshot 2
5.2.3. Code Efficiency
Code efficiency is a broad term used to depict the reliability, speed and programming
methodology used in developing codes for an application. Code efficiency is directly linked
with algorithmic efficiency and the speed of runtime execution for software. It is the key
element in ensuring high performance. The goal of code efficiency is to reduce resource
consumption and completion time as much as possible with minimum risk to the business or
operating environment. The software product quality can be accessed and evaluated with the
help of the efficiency of the code used.
Following things were taken care off to ensure code efficiency:
 All unnecessary code or code that goes to redundant processing was removed.
 Optimal memory and non volatile storage were used
 Best speed or run time was ensured for completing the algorithm
 Use of reusable components was done wherever it was possible.
 Error and exception were handling at all layers of software, such as the user interface, logic
and data flow
 A programming code that ensures data integrity and consistency was created
 A programming code that's compliant with the design logic and flow was developed
 Coding practices applicable to the software were used
 Use of data access and data management practices was optimized
 Best possible keywords, data types and variables, and other available programming
concepts, related to the algorithm were implemented
120
5.2.4. Optimization of Code
Code optimization is any method of code modification to improve code quality and efficiency.
A program may be optimized so that it becomes a smaller size, consumes less memory,
executes more rapidly, or performs fewer input/output operations.
The basic requirements optimization methods should comply with, is that an optimized program
must have the same output and side effects as its non-optimized version. This requirement,
however, may be ignored in the case that the benefit from optimization, is estimated to be more
important than probable consequences of a change in the program behavior.
Optimization can be performed by automatic optimizers, or programmers. An optimizer is

either a specialized software tool or a built-in unit of a compiler. We manually optimized the
code and high efficiency was ensured.
5.2.5. Validation Check

The process of evaluating software during the development process or at the end of the
development process to determine whether it satisfies specified business requirements.
Validation Testing ensures that the product actually meets the client's needs. It can also be
defined as to demonstrate that the product fulfills its intended use when deployed on
appropriate environment.
Following criteria were considered while performing validation check:
1. Functional Correctness and Completeness
2. Data Integrity
3. Data Conversion
4. Usability
5. Performance
6. Timeliness
7. Confidentiality
8. Upgradability
9. Scalability
10. Documentation
121
6.Testing
6.1. Testing Objectives
The development of Software system involves a series of production activities. There is a
chance of errors to occur at any stage. Because of human inability to perform and communicate
with perfection, a Quality Assurance Activity accompanies software development.
Software testing is a critical element of software quality assurance and represents the ultimate
review of specification, design and code generation.
The increasing visibility of software as a system element and the costs associated with software
failure are motivating forces for well planned, thorough testing.
Unit Testing
The resultant system after the integration of the modules was tested to ascertain its correctness
in terms input, processing and output. This was done by executing prepared test scenarios. The
unit testing focused on the internal processing logic and data structures within the boundaries of
a component. More than often, the developer had to keep editing a module severally until each
module was complete and correct.
Security testing
Security testing attempted to verify that protection mechanism of the system. It is protected
against unauthorized access. There was deliberate inputting of username with a password and
the reaction of the system were checked.
6.2. Testing Methods & Strategies used along with test data and the error
listed for each test case for each function provided by the system
Different types of testing are
 Boundary Condition Testing

 Integration Testing
 Black Box Testing
 Validation Testing
 User Acceptance Testing
During the implementation for the system each module of the system is tested separately to
uncover errors within its boundaries. User interface is used as a guide in this process. The
validations have been done for all the inputs using Java Script.
122
For example, to check whether the work allotted among the database correctly without
exceeding the schemes which are not validated thoroughly and the internal database has to
check the reflections in the database.
Boundary conditions Test:

Boundary conditions as in case of generating sequences were tested to ensure that the module
operates properly at boundaries establish to limit or restrict processing also it is able to handle
incorrect out of the boundary values properly.
Integration Test:
The objective of Integration Test is to take the tested modules and build a program structure
that has been defined in the design. We have done top down integration, which is constructing
and testing small segments where errors are easier to isolate, and correct. The integration
process was performed in three steps:
 The main control was used as test driver.

 Test was conducted as each module was integrated.
 Regression testing to ensure that new errors have not been introduced due to the
corrections.
Black Box Testing:

It focuses on functional requirements of the software. Block box testing attempts to find errors
in the following categories.
 Incorrect or missing function

 Interface error
 Errors in external device access
 Performance error
 Initialization and termination errors
The above testing was successfully carried out for the developed system.
Validation Testing:
At the culmination of integration testing, software is completely assembled as a package,
interfacing errors have been uncovered and corrected, and a final series of software tests
namely validation tests are performed. Validation succeeds when the software functions in the
manner that can be easily accepted by the customer.
123
After validation test has been conducted, one of the possible conditions are satisfied. The
functions or performance characteristics confirmed to specifications are acceptable. The
deviation from specifications are uncovered and a note of what is lacking is made. The
developed system has been tested satisfactorily to ensure its performance is satisfactory and it is
working efficiently.
User Acceptance Testing:

User acceptance of a system is a key factor for the success of any system. The system under
consideration was tested for user acceptance constantly, by keeping the users informed of the
progress and incorporating changes suggested, at the development time itself.
Test Case Report:

Here we specify all the test cases that are used for system testing. The different conditions that
need to be tested along with the test case used for testing those conditions and the expected
outputs are given. The goal is to test the different functional requirements. Test cases have
been selected for both valid and invalid inputs.
124
7.Conclusion and Future Work
The project entitled Projectoscope was completed successfully.
The system has been developed with much care and free of errors and at the same time it is
efficient and less time consuming.The purpose of this project was to develop an online system
to monitor the progress of minor and major projects and provide an easy communication
between students and project guides.This project has greatly helped us in gaining valuable
information and practical knowledge on several topics like designing web pages using html,
bootstrap, JavaScript, jQuery, usage of responsive templates,using PHP as scripting language
and management of database using MySQL. The entire system is secured. Also the project
helped us understanding about the development phases of a project and software development
life cycle. We learned how to test different features of a project. This project has given us great
satisfaction in having designed a solution which can be used by any of the engineering
departments of our college to monitor the progress of student projects of various batches. There
is a scope for further development in our project to a great extent.In future, a number of features
can be added to this system.
7.1 Achievements
Through the project:
 The students can register and log in successfully in the system.

 Other users i.e. project guide and admin can log in successfully in the system.
 The system allows students to update their progress online.
 The system allows admin to manage and view all transactions.
 The system allows project guide to send reminders and intimations to the student groups
 The system provides an efficient way in which project guide can track progress of various
groups.
The developer did learn:
 Skills of using CSS for uniformity and JavaScript for validation.

 Skills of using Bootstrap for designing responsive web pages.
 Skills in writing of term papers and reports.
 We learnt to independently design a system and schedule project related activities.
125
7.2 Limitation of Project
There are some limitations for the current system to which solutions can be provided as a future
development:
 No interaction with server scheduler services.

 No feature to create repository of projects.
 System cannot be accessed on mobile phones right now.
7.3 Difficulties Encountered

 Poor requirements-In case of poorly stated, ambiguous and non-testable requirements,
problems will arise during designing the system.
 Unrealistic Schedule-if too much work is given in too little time, problems are inevitable if
too much work is assigned in a comparatively short duration of time.
 Inadequate testing-if system is not properly tested, it is at high risk of failing. Also, client
feedback plays an important role combating the shortcomings of the system.Futurities-
request to pile on new features after development is underway; extremely common.
 Miscommunication-if developers do not know what’s needed or customers have wrong
expectations, problem are assured
7.4 Future Enhancement Suggestions

The project made here is just to ensure thatstudents register their groups timely and keep
reporting their progress upon the undertaken project work, which will be verified by their
project guides.In near future, we will work towards improving the overall efficiency of the
system and on present limitations as well.
The following discusses the work that will be implemented with future releases of the software:
 Facility to upload pdf presentations to elaborate stage wise progress.

 Integration with SMS gateways.
 Android Application of the above system.
 Project repository for students to access
126
8.References
8.1 Reference Books
Books:
 Software Engineering, A practitioner’s Approach by Roger S. Pressman, McGrawHill

International Edition, 6th Edition.
 Software Engineering by Sommerville, Pearson Education.
 O'Reilly Media, Head First PHP and MySQL by Lynn Beighley and Michael Morrison
8.2 Other Documentation and Resources

Video Tutorials:
 PHP- The Bad Tutorials

 Object Oriented PHP – Derek Banas
 Front end development- The complete web developer course by Rob Perceival
 Codeigniter by Traversy Media
Websites:
 http://www.w3schools.com/html/defualt.asp
 www.Capterra.com
 www.softwareadvise.com
 www.slideshare.com
127

Minor Project Report On Projectoscope PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Minor Project Report On Projectoscope PDF

Uploaded by

Copyright:

Available Formats

PROJECTOSCOPE

Minor Project submitted

towards partial fulfilment of the

degree of Bachelor of Engineering

Year 2017 - 2018

Department of Computer Science and Engineering

Guided By : Submitted By:

(Assistant Professor, CSE Dept.) 2. Ambika Depale (0802CS151015)

3. Apoorva Phatak (0802CS151025)

Shri Vaishnav Institute of Technology and Science, Indore

Project Guide Head of Department

Mrs. Archana Choubey Dr. Anand Rajawat

Date: Aayushi Bharti (0802CS151003)

Table No. Figure Name Page No.

Figure No. Figure Name Page No.

2. Feasibility Study 4-5

3. Literature Survey 6-9

4. Requirement Analysis and Design 10 -106

5. Methodology and Implementation Phase 107-121

7. Conclusion and Future Work 125 -126

1.1 Problem Statement

1.4 Platform Specification

1.4.2 Software Requirements:

Web Browser : Google Chrome

Web Server : Apache version 2.4.27

Database : MySQL version 5.7.19

Scripting Language : Pre-processor Hypertext (PHP version 7.0.9)

Front end : HTML5, Bootstrap, JavaScript, jQuery

What Can PHP Do?

 PHP can generate dynamic page content

2.1 Economic Feasibility

2.2 Operational Feasibility

2.3 Technical Feasibility

3.1 Work Done by Others

 Efficient monitoring of team performance.

3.3 Proposed Solution

4.1.1.2 Supplementary Specifications

4.1.1.3 Use Case Model

USE CASES COVERED IN PROJECTOSCOPE – A PROJECT MONITORING TOOL

USE CASE DESCRIPTIONS

1.2 Actor(s) Involved

1.5 Post Actions:

1.6 Deviation treatment : No deviation shall be entertained.

2.2 Actor(s) Involved

2.4 Normal Use Case:

2.5 Post Actions:

2.6 Deviation treatment

3.2 Actor(s) Involved

3.4 Normal Use Case:

3.5 Post Actions:

3.6 Deviation treatment

4.1 Purpose: To capture project proposals from approved groups.

4.2 Actor(s) Involved

4.4 Normal Use Case:

4.5 Post Actions:

4.6 Deviation treatment

Group details for

5.2 Actor(s) Involved

5.4 Normal Use Case:

5.5 Post Actions:

5.6 Deviation treatment

6.2 Actor(s) Involved

6.4 Normal Use Case: