INDEX

Title Page No.

Chapter 1 Introduction

1.1 Motivation 1

1.2 Special Tools 1

Chapter 2 Software Requirements Specification

2.1 Requirements 2

2.1.1 Functional Requirements 3

2.1.2 Non- Functional Requirements 3

2.1.3 Safety Requirements
3
2.1.4 Security Requirements
6

2.2 Software Quality Attribute

2.2.1 Reliability 8

2.2.2 Maintainability 10

2.2.3 Usability 11

2.2.4 Portability 12

2.2.5 Correctness 13

2.2.6 Efficiency 14

2.2.7 Flexibility 15

2.3 Use Case Diagram 16

2.4 Deployment Diagram 19

Chapter 3 Implementation

3.1 Sequence Diagram 20

i
 Title Page No.
3.2 Normal Algorithm Technique 21

3.2.1 Dynamically Working of Our Project 21

3.2.2 How Mail System works 22

3.2.3 Assign Marks by Guide

3.3 Test Cases

3.3.1 White Box Testing 23

a. Whitebox Testing I 23

b. Whitebox Testing II 24

c. Whitebox Testing III 24

3.3.2 Blackbox Testing

a. Blackbox Testing I 25

b. Blackbox Testing II 29

3.4 Result 30

Chapter 4 Conclusion 31

ii
 List of Figure

Fig. No. Title Page No

2.3.1 Student Use Case 7

2.3.2 Project Registration 8

2.3.3 Project Code Generation 9

2.3.4 Admin and Guide 9

2.3.5 Guide Login page 10

2.3.6 Guide Dashboard (Internal) 11

2.3.7 Guide Dashboard (External) 11

2.3.8 Project Details in Guide Dashboard 12

2.3.9 Add Demo by Guide 12

2.3.10 Student Dashboard I 13
2.3.11 Student Dashboard II 13
2.4.1 Deployment Diagram 14
3.1.1 Project Submission Sequence Diagram 15
3.1.2 Guide Login Sequence Diagram 16
3.2.1 Home Screen 17
3.2.2 Mail System 19
3.2.3 Assign Marks Dashboard 21
Blackbox Testing on Title, Description &
3.5.1 27
Team
3.5.2 Project Code 28
3.6.1 Project Registered Home 30
3.6.2 Guide All 31

iii
 List of Table

Table No. Title Page No

3.3.1 Test Cases 22

3.5.2 Equivalence Class Partitioning I 25

3.5.3 Equivalence Class Partitioning II 27

iv
Chapter 1
Introduction
The project submission software is an application to the college, organization and company.
Basically, it is used to check the progress of project and if there is any correction is present then
by remotely guide will tell them correction. This application is able to hand the number of projects
and their progress report generation. Here is the summery of our application, the project leader
will register the projects with the details such as Project description, project title, technology used,
project members, their internal and external guide. Once the project has been registered, the Project
Id or a unique project code will generate. By using that project code, the project team can watch
their correction given by their respected guide.
Now Let’s look that how guide will make the correction or asses the projects. To become the guide,
first register as a guide on the portal. When project team select guide as an internal or as an external
then these things are reflected in the guide dashboard that these are the project teams under them.
And from the dashboard guide is able to correct or asses the project. If guide wants to give marks
then according to project parameter, he is able to give the marks such as project completion, design
and all.
The project incharge is monitoring on all these stuffs. Like everyone gives the project demo or not,
has everyone submit SRS or not, etc. Without project incharge permission projects will not
allowed. To avoid the redundancy and repetition of projects we made a function that projects are
only accepted if project incharge permit them. Also, project incharge can delete or add the guides.

1.1 Motivation
We have seen from past few years that these project works are manually done. Like to register the
projects from the students, create the google form copy those data and paste it in the excel file add
column and manually type the names of guides and print the sheet and hang on the notice board
and everyone is making the rush to see their team and the guide. It’s really a very hectic stuff and
we want a solution a platform to make these things are online. So, we have decided to make this
as a part of our academic project and contribute our small gift to college.

1.2 Special Tools

We have used the web framework which is Flask and the Jinja templates, HTML, CSS, Bootstrap.
The flask is the micro framework of the python and it is allowed to use and create the web
application such as ours. The database we have used is SQLite.

1
Chapter 2
Software Requirements Specification
A software requirements specification (SRS)is a description of a software system to be developed.
It is modeled after business requirements specification, also known as a stakeholder requirements
specification. The software requirements specification lays out functional and non-functional
requirements, and it may include a set of use cases that describe user interactions that the software
must provide to the user for perfect interaction.
Software requirements specification establishes the basis for an agreement between customers and
contractors or suppliers on how the software product should function (in a market-driven project,
these roles may be played by the marketing and development divisions). Software requirements
specification is a rigorous assessment of requirements before the more specific system design
stages, and its goal is to reduce later redesign. It should also provide a realistic basis for estimating
product costs, risks, and schedules. Used appropriately, software requirements specifications can
help prevent software project failure.
The software requirements specification document lists sufficient and necessary requirements for
the project development. To derive the requirements, the developer needs to have clear and
thorough understanding of the products under development. This is achieved through detailed and
continuous communications with the project team and customer throughout the software
development process. A good SRS defines the how Software System will interact with all internal
modules, hardware, communication with other programs and human user interactions with wide
range of real-life scenarios. Using the Software requirements specification (SRS) document on QA
lead, managers create test plan. It is very important that testers must be cleared with every detail
specified in this document in order to avoid faults in test cases and its expected results.

2.1 Requirements

2.1.1 Functional Requirements

• Purpose: -
To register a new project.

• Input: -
The required data for registration online project submission of a new student in the
database (Like Name, project name, project area, Team Members etc.)
• Output: -
A success message will be displayed on the screen and at the same time a confirmation
mail send to his registered e-mail id with a unique code by which project can be track its
status.

2
 2.1.2 Non-Functional Requirements

Non-functional requirements are requirements that are not directly concerned with the specific
functions delivered by the system. They may relate to emergent system properties such as
reliability, response time and store occupancy. They may specify system performance,
security, availability, and other emergent properties.

2.1.3 Safety Requirements

a. Backup, recovery & data continuity should ensure adequate back up of data as may be
required by their operations. Online Project Submission software should also have, well
documented and tested business continuity plans that address all aspects of the
software.

b. Both data and software should be backed up periodically.

c. An off-site back up is necessary for recovery from major failures /disasters to ensure
data continuity.

2.1.4 Security Requirements

a. Account ID and Password protection

b. Track the project in the real time by using Track ID.
c. User check the topic available or not.
d. The updates are notified on the registered mail.
e. Guide will see the students under him/her.
f. Guide will able to give the grades and remark on the basis of student performance and
student will see these grades in the student dashboard.
g. Guide will update the Project demo, Grades and Meetings.
h. Encryption

2.2 Software Quality Attributes

2.2.1 Reliability
Measure if product is reliable enough to sustain in any condition. Should give consistently correct
results. Product reliability is measured in terms of working of project under different working
environment and different conditions.

3
 2.2.2 Maintainability
Different versions of the product should be easy to maintain. For development, it’s should be easy
to add code to existing system, should be easy to upgrade for new features and new technologies
time to time. Maintenance should be cost effective and easy. System be easy to maintain and
correcting defects or making a change in the software.

2.2.3 Usability
This can be measured in terms of ease of use. Application should be user friendly. Should be easy
to learn. Navigation should be simple.

2.2.4 Portability
This can be measured in terms of Costing issues related to porting, Technical issues related to
porting; Behavioral issues related to porting.

2.2.5 Correctness
Application should be correct in terms of its functionality, calculations used internally and the
navigation should be correct. This means application should adhere to functional requirements.

2.2.6 Efficiency
To Major system quality attribute. Measured in terms of time required to complete any task given
to the system. For example, system should utilize processor capacity, disk space and memory
efficiently. If system is using all the available resources then user will get degraded performance
failing the system for efficiency. If system is not efficient then it cannot be used in real time
applications.

2.2.7 Flexibility
Should be flexible enough to modify. Adaptable to other products with which it needs interaction.
Should be easy to interface with other standard 3rd party components.

4
2.3 Use Case Diagram

Fig. 2.3.1 Student Use Case

Above use case figure is the access area of the student. The Student is the actor of the project
registration module. (Only project leader can register the project) In the above figure, the student
can able to register their project. After the registration of project, the unique code will get on their
registered e-mail address and by using that unique code they can see their progress report corrected
and assed by their respected guide.
Here are the web screenshots to specify more clearly the operations. To register the project, project
leader must go on http://mgmprojects.pythonanywhere.com/projectRegister and fill all the
parameters of the project. Project parameters are

• Project title
• Project Description
• Details of Team Members
• Team Name
• Team Leader Name
• Team Members Name
• Other Details
• Technology Used
• Select Guide (External and Internal)

5
Fig. 2.3.2 Project Registration

6
 Fig. 2.3.3 Project Code Generation

After the registration of project, the unique and auto generated project code will be assigned. This
code is useful to the correction and assessment given by the guide. These credentials are sent to
the mail Id of project leaders and members. Also guide will receive the email with subject ‘[Project
Assigned] Internal Guide | Department of CSE | MGM's College of Engineering | Nanded’.

Fig. 2.3.4 Admin and Guide

7
In the above use case figure, there are two actors namely Admin and Guide. Let’s have a look of
them, the project guide is the wizard that walks you through setting up a project, assigning
resources to the project, tracking progress, and reporting on progress. Guide can view the
submitted projects (He can check in his dashboard that how many projects in his internal and
external), set a deadline for the demo, set a meeting with the project teams, manipulate grades.
While admin is the one who is monitoring on all of these operations. The admin can see the total
registered projects, total guide registered, total student’s data also if guide wants, he can modify,
update and delete the guide and registered project if he found any issue. Here are the snapshots by
which you can easily understand.

Fig. 2.3.5 Guide Login Page

The above figure is the web page of guide login. By entering the credential, he is able to get the
internal and external projects under him. The dashboard of guide is look alike:

8
Fig. 2.3.6 Guide Dashboard (Internal Projects)

Fig. 2.3.7 Guide Dashboard (External Projects)

9
The above snapshots are the dashboard of guide in which the external as well as internal projects
are shown. By clicking any title of project guide can able to dee their project details, members and
all.

Fig. 2.3.8 Project details in Guide Dashboard

In the above web snapshot, the dashboard of guide contains all the project details and member
details and the guide details. Also, he is able to asses and give the marks according to the
parameters are as follows:

Fig. 2.3.9 Add Demo by Guide

10
In the above web snapshot, the guide asses the marks according to the above parameters. Once
guide lock the or click add demo the all data is instantly locked and reflected to the student
dashboard.

Fig. 2.3.10 Student Dashboard I

Fig. 2.1.11 Student Dashboard II

11
In the above web snapshot, the student can see their project status by just typing their project code.
If anyone forgotten the project code, it is already sent to their registered e-mail address. By using
this, they will get such updated dashboard.

2.4 Deployment Diagram

A deployment diagram is a UML diagram type that shows the execution architecture of a
system, including nodes such as hardware or software execution environments, and the
middleware connecting them. Deployment diagrams are typically used to visualize the
physical hardware and software of a system.

Fig. 2.4.1 Deployment Diagram

We have design and developed this application by using the python flask and to design the
front-end we use the jinja templates. Jinja is a web template engine for the Python
programming language. It is similar to the Django template engine but provides Python-like
expressions while ensuring that the templates are evaluated in a sandbox. Currently our
application is hosted on the www.pythonanywhere.com and it give us 512 MB space. The
database that we have used is SQLite. The website to visit our portal is:
http://mgmprojects.pythonanywhere.com/

12
 Chapter 3
Implementation

3.1 Sequence Diagram

The sequence diagram is a good diagram to use to document a system's requirements and to flush
out a system's design. The reason the sequence diagram is so useful is because it shows the
interaction logic between the objects in the system in the time order that the interactions take place.

Here are some sequence diagrams of our projects:

Fig. 3.1.1 Project Submission Sequence Diagram

13
 Fig. 3.1.2 Guide Login Sequence Diagram

The above Sequence Diagram is specifying the registration of the guide. The first step is to open
the project tracking portal on the web browser and click the register as guide. Fill all the attribute
and submit. Once you submit the confirmation mail is sent on your registered mail address. Once
you register as a guide the admin will check that the guide is exits or not and by permitting the
admin you will be successfully registered as a guide.

3.2 Normal Algorithm Technique

3.2.1 Dynamically Working of Our Project

The project tracking application is dynamically working. Those projects are registered they
will be appeared on the home screen. The best advantage of dynamic code is there is less
chance of modification of our code every time and it is reusable that means we can use this
code for the next registration and it is efficient. Dynamic Programming is mainly an
optimization over plain recursion. Wherever we see a recursive solution that has repeated
calls for same inputs, we can optimize it using Dynamic Programming. The idea is to
simply store the results of subproblems, so that we do not have to re-compute them when
needed later.

14
Here is a snippet of our project: -

How the registered project will dynamically show on the home screen.

{{form.projectTitle.label(class="form-control-label")}}
{% if form.projectTitle.errors %}
{{form.projectTitle(class="form-control is-invalid")}}
{% for error in form.projectTitle.errors %}
<span class="errorFeedback">{{ error }}</span>
{% endfor %}
{% else %}
{{form.projectTitle(class="form-control")}}
{% endif %}
</div>
<div class="form-group">
{{form.projectDescription.label(class="form-control-label")}}
{% if form.projectDescription.errors %}
{{form.projectDescription(class="form-control is-invalid")}}
{% for error in form.projectDescription.errors %}
<span class="errorFeedback">{{ error }}</span>
{% endfor %}
{% else %}
{{form.projectDescription(class="form-control")}}
{% endif %}
</div><hr />

Here is the snapshot reference of our application:

Fig. 3.2.1 Home Screen

15
3.2.2 How Mail System works

The e-mail system is the professional way of communicate. In our application we have
provided the mail system. When the user has registered his project the updated and credential
main has been sent to their e-mail address.

Here is the snippet of our mail system: -

mail_settings = {
"MAIL_SERVER": 'smtp.gmail.com',
"MAIL_PORT": 465,
"MAIL_USE_TLS": False,
"MAIL_USE_SSL": True,
"MAIL_USERNAME": 'demo@gmail.com',
"MAIL_PASSWORD": 'demo'
}

template = f"<b>Hi {project.team.members[0].name}!</b><br />

You have successfully registerd your Project - {project.title}. Please note this ID:
<b>{project.code}</b> to track your Project status. You will be soon assigned with a
guide!"

msg = Message(subject='Project Registration Successful | Department of

CSE | MGM College of Engineering | Nanded', sender='hello@gmail.com',
recipients=[project.team.members[0].email], html=template)
mail.send(msg)
flash('You have successfully registered your Project! Please note this ID: ' +
project.code + ' to track your Project status.', 'success')
return redirect(url_for('home'))
return render_template('ProjectRegistration.html', title='Project Registration',
form=form)

16
Here is the snapshot reference of our application:

Fig. 3.2.2 Mail System

3.2.3 Assign Marks by Guide

The main and challenging task in our application is to lock the marks given by guide and
display it at the same time on the student dashboard. We have used the jinja templates and
some bootstrap libraries.

Here is the snippet of our Assign Marks System:

Marks Parameter:

{% if form.parameter.errors %}
{{form.parameter(class="form-control form-control-sm is-invalid")}}
{% for error in form.parameter.errors %}
<span class="errorFeedback">{{ error }}</span>
{% endfor %}
{% else %}
{{form.parameter(class="form-control form-control-sm")}}
{% endif %}

17
Percentage Parameter

{{form.progress.label(class="form-control-label")}}
(In Percentage)<br/><small>
</td>
<td>

{% if form.progress.errors %}
{{form.progress(class="form-control form-control-sm is-invalid")}}
{% for error in form.progress.errors %}

<span class="errorFeedback">{{ error }}</span>

{% endfor %}
{% else %}

{{form.progress(class="form-control form-control-sm")}}
{% endif %}

Remarks Parameter

{{form.remarks.label(class="form-control-label")}}
{% if form.remarks.errors %}
</td>
<td>

{{form.remarks(class="form-control is-invalid")}}
{% for error in form.remarks.errors %}
</td>
<td>

<span class="errorFeedback">{{ error }}</span>

{% endfor %}
{% else %}

{{form.remarks(class="form-control")}}
{% endif %}

18
 Here is the snapshot reference of our application:

Fig. 3.2.3 Assign Marks Dashboard

3.3 Test Cases

A Test Case is defined as a set of actions executed to verify a particular feature or functionality
of the software application. A test case is an indispensable component of the Software Testing
Lifecycle that helps validate the AUT (Application Under Test).

While drafting a test case to include the following information

• The description of what requirement is being tested

• The explanation of how the system will be tested
• The test setup like a version of an application under test, software, data files, operating
system, hardware, security access, physical or logical date, time of day, prerequisites such
as other tests and any other setup information pertinent to the requirements being tested
• Inputs and outputs or actions and expected results
• Any proofs or attachments
• Use active case language
• Test Case should not be more than 15 steps
• An automated test script is commented with inputs, purpose and expected results
• The setup offers an alternative to pre-requisite tests

19
 Table No. 3.3.1 Test Case

Test
Test Case Expected
Case Test Data Actual Result Pass/Fail
Description Result
#

Project Title: Project

Tracking Portal
You have
Team Name: The
successfully
Incredible
registered your
project!
Leader Name: Abhishek
Project should
Bagate
be successfully Please note this
Check
registered! Id: 001-PROJ-
Response Team Member: Omkar
1 OMK Pass
when Project Deshpande
Project Id:001- To track your
Registration
PROJ-OMK project status.
Technology Used:
Python Flask, Jinja
Also check your
registered email
Select Internal: Dr. Mrs.
Id for more
M. Y. Joshi
details.
Select External: M. N.
Bhandare

Your Project Id
Dashboard
is correct and
Track Project Enter Your Project ID: Should be
2 your project Pass
Status 001-PROJ-OMK appeared on the
dashboard will
home screen.
display.
Name:
Dr. Mrs. M. Y. Joshi You have
successfully
E-mail: registered as a
Guide
joshi_my@mgmcen.ac.in Guide must be Guide!
3 Registration Pass
registered.
Form
Username: joshi_my Please check the
mail for your
Password: Demo credential.

20
Test
Test Case Expected
Case Test Data Actual Result Pass/Fail
Description Result
#

Username: joshi_my
Guide Login Login should be Successfully
4 Pass
Form successful. Logged in.
Password: Demo

Submit the Successfully

Enter Project Code: A text editor
5 project open the text Pass
001-PROJ-OMK should open.
abstract editor.

Admin Username: joshi_my

Login should be Login was
6 (Project Pass
successful. successful.
Incharge) Password: Demo

Email to (Checkbox):
-All Guides
-All BECSE A Students
-All BECSE B Students

Text Editor:
All the students from
BECSE I & BECSE II
The mail with
are hereby informed that
Add Notice notice should
your project report Successfully add
7 for all the sent to the Pass
should submit to the the notice.
Project Team selected
respected guide.
checkbox.
The last date of project
report submission is
07.11.2019

(Only Project Incharge

have authorization to
access this area)

21
3.3.1 White Box Testing

White Box Testing is defined as the testing of a software solution's internal structure, design,
and coding. In this type of testing, the code is visible to the tester. It focuses primarily on
verifying the flow of inputs and outputs through the application, improving design and
usability, strengthening security. White box testing is also known as Clear Box testing, Open
Box testing, Structural testing, Transparent Box testing, Code-Based testing, and Glass Box
testing. It is usually performed by developers.

It is one of two parts of the "Box Testing" approach to software testing. Its
counterpart, Blackbox testing, involves testing from an external or end-user type perspective.
On the other hand, Whitebox testing is based on the inner workings of an application and
revolves around internal testing.

1.Whitebox Testing I

class membersForm(FlaskForm):
class Meta:

csrf = False
memberName = StringField('Team Member',
validators=[Length(min=0, max=20)])

memberEmail = StringField('Email: ',

validators=[Email(), Optional()])

memberClass = SelectField(u'Class', choices=[('','Select Class'),('A', 'BE-CSE-

A'), ('B', 'BE-CSE-B')])

memberPhone = StringField('Phone: ',

validators=[Length(min=10, max=10), Optional()])

To exercise the statements in the above code, Whitebox test cases would be:

• Whitebox Cases I • Whitebox Cases II

Name: Omkar Deshpande Name: Abhishek Bagate

Email: edu.omkar98@gmail.com Email: dev.abhishek98@gmail.com

Class: BESCE I Class: BESCE I

Phone Number: 8805315385 Phone Number: 9511681791

22
2. Whitebox Testing II

class projectRegister(FlaskForm):
class Meta:
csrf = True
projectTitle = StringField('Project Title',
validators=[DataRequired(), Length(min=2, max=50)])
projectDescription = TextAreaField('Project Description',
validators=[DataRequired(), Length(min=150)])
teamName = StringField('Team Name',
validators=[DataRequired(), Length(min=2, max=50)])
members = FieldList(FormField(membersForm), min_entries=4)
technologyUsed = StringField('Technology Used',
validators=[Length(min=0, max=100)])
internalGuides = SelectField(u'Select your Internal Guide', coerce=int)
externalGuides = SelectField(u'Select your Enternal Guide', coerce=int)
submitProject = SubmitField('Register Project')

To exercise the statements in the above code, Whitebox test cases would be:
• Whitebox Cases I
Title: Project Tracking Portal
Description: Our project is capable of tracking the progress of project and handle it by
remotely to the assigned guides.
Team Name: The Incredible
Members: 1. Omkar Deshpande
2. Abhishek Bagate
Technology Used: Python Flask, Jinja Templates, Bootstrap, HTML, CSS
Internal Guide: Dr. Mrs. M. Y. Joshi
External Guide: Prof. M. N. Bhandare

23
• Whitebox Cases II

Title: Online Home Service Provider

Description: It is a web application that would provide platform and interaction between
customers and different service providers where, customers can find appropriate services
for their needs and demands such as house cleaning, car washing, event managements,
photographers etc. on this platform. It helps customers hire trusted professionals for their
service needs. Customers can also be able to see quotation for their event and choose the
suitable one for them. This platform eases finding professional service providers for users
as well as increases the productivity of service provider companies. This platform makes
a difference in the lives of people by catering to their service needs on their fingertips.
This application will be developed using Mysql, PHP for backend,HTML, CSS,javascript
,Jquery and Bootstrap for frontend technologies.
Team Name: Rada Boys
Members: 1. Anuj Chourange
2. Vipul Chinnawar
Technology Used: PHP, Bootstrap, HTML, CSS
Internal Guide: Mr. Shivprasad Titare
External Guide: Mr. Mohammed Aijaz Ahmed

• Whitebox Cases III

Title: Online Banking

Description: Developing a real demonstration transaction based offline banking system.
It is providing the real time net banking services with the best security and management.
Team Name: Rada Girls
Members: 1. Divya Bandewar
2. Mrunali Joshi
Technology Used: PHP, Bootstrap, HTML, CSS
Internal Guide: Mr. Suhas Salve
External Guide: Mr. Rahulsingh Bisen

24
3.3.2 Blackbox Testing
Black Box Testing is also known as behavioral, opaque-box, closed-box, specification-based
or eye-to-eye testing. It is a Software Testing method that analyses the functionality of a
software/application without knowing much about the internal structure/design of the item that
is being tested and compares the input value with the output value. The main focus in Black
Box Testing is on the functionality of the system as a whole.

The term ‘Behavioral Testing' is also used for Black Box Testing. Behavioral test design is
slightly different from the black-box test design because the use of internal knowledge isn't
strictly forbidden, but it's still discouraged. Each testing method has its own advantages and
disadvantages. There are some bugs that cannot be found using the only black box or only
white box technique. Majority of the applications are tested by Black Box method.

We need to cover the majority of test cases so that most of the bugs will get discovered by
a Black-Box method. This testing occurs throughout the software development and Testing
Life Cycle i.e. in Unit, Integration, System, Acceptance, and Regression Testing stages.

3.5.1 Blackbox Testing I

Fig. 3.5.1 Blackbox Testing on Title, Description & Team

As present in the above image, the “Project Title” field accept only number from 2 to 50. There
will be three set of classes or groups.
• Less than or equal to 1.
• Greater than or equal to 51.
• One valid class will be anything between 2 to 50.

25
 The “Project Description” field accept only number from 150 to 5000. There will be three set
of classes or groups.

• Less than or equal to 149.

• Greater than or equal to 5001.
• One valid class will be anything between 150 to 5000.

The “Team Name” field accept only number from 2 to 50. There will be three set of classes or
groups.

• Less than or equal to 1.

• Greater than or equal to 51.
• One valid class will be anything between 2 to 50.

Table No. 3.5.2 Equivalence Class Partitioning I

Sr. Attributes Invalid Valid Invalid

1 Project Title <=1 2 - 50 > = 51

2 Project Description < = 150 150 - 5000 > = 5001

3 Team Name <=1 2 - 50 > = 51

3.5.2 Blackbox Testing II

Fig. 3.5.2 Project Code

26
As shown in the above figure, the field is the “Enter Your Project-Id” in which we have to enter
the project Id which we get when the project was registered. This field having the unique logic that
is the first number is the Primary Key, the second 4-character from the title of the project and last
is the three character from the name of the project leader.

Let’s consider,

Project Title: Design of Deadlock Algorithm

Leader Name: Chetan Bhagat

And dynamically the project code will be generated and will be 005-DESI-CHE. There will be
three set of classes or groups.

• The title of the project should be less than or equal to 4

• The leader name should be less than or equal to 3
• While tracking the project status all character must be in uppercase.

Table No. 3.5.3 Equivalence Class Partitioning II

Sr. Attributes Invalid Valid Invalid

1 Leader Name <=2 3 – 50 > = 51

2 Project Title <=3 4 - 50 > = 51

3 Project Code 001-proj-omk 001-PROJ-OMK 1-PRoJ-Omk

4 Leader Name Om Omkar OD

5 Project Title AI Augmented Reality Be Power

27
3.4 Result
The Online project management system is the platform on which all the manual things of
project are shift to the online. From the registration of project to the completion of project with
the certificate of completion of project.

We have hoisted our website to the free domain of www.pythonanywhere.com. There are total
67 projects are registered from BECSE A & BECSE B.

Fig. 3.6.1 Project Registered Home

All the guides from the Computer Science Department are registered and they are used this as
a beginner and will familiar with this in few days and will use in next semester. Guide will
guide them as externally as well as internally.

28
 Fig. 3.6.2 Guide All
We have created an admin dashboard where he can monitor on all. If he found any type of issue
with any field, we have given the full authorization to modify, delete and update these field.

29
Chapter 4
Conclusion
After conducting the survey, we get to understand about the Project tracking Software. How it can
be and the function, features and more. If we want to generalize our project the we have to think
like the customer or the organization who need an such project. Initially, we thought about a
specific college and the specific department and the limitations of projects are to be made. We are
providing such features in our projects so that there is no need to change the backend every time.

30
31
32