SRI GURU TEGH BAHADUR INSTITUTE OF

MANAGEMENT & INFORMATION

TECHNOLOGY

BCA
SUMMER TRAINING REPORT
{Synopsis File}
Submitted By: Submitted To:
NAME: LUCKY KUMAR JAISWAL Ms. Ayeena
CLASS: BCA 5D Professor (IT)
SNO TOPIC PAGE REMARKS
1  Objective
 Introduction
 Scope

2  Hardware Requirement
 Software requirement

3  Front End Description

4  Software Analysis
 Software development Life Cylcle
 Description of Used model
 Software Design
 Data Flow diagram
 Zero(0) Level Diagram
 Zero(1) Level Diagram
 ER Diagram

5  Snapshots of Output

6  TESTING
 BENEFITS
 LIMITATIONS
 FUTURE ENHANCEMENT
 CONCLUSION
 REFERENCES
 ABSTRACT
Our project student Management System includes registration of students , storing their details into the
system, I,e, computerized the whole process. Our software has the facility to give a unique id for every
student and stores the details of every student. It includes a search facility . it also search by name ,
contact and roll number. The data can be retrieved easily. The Interface is very UserFriendly. The data are
well protected for the personal use and makes the data processing very first.
 CHAPTER 1

INTRODUCTION
1.1: OBJECTIVE

Student Management System is a software which is useful for college as well as the school authorities . In
the current system all the activities are done manually .It is very time consuming and costly.Our Student
Management System deals with various activities related to managing student records. Our objective is
computerizing the process of student records management.

1.2 INTRODUCTION

This project is to automate the Student Management System .This project is developed mainly to
administrate the student records.The purpose of project entitled as STUDENT MANAGEMENT
SYSTEM is to computerize the Front Office Management of Student records in colleges, schools and
coaching center’s to develop software which is user friendly , simple, fast and cost- effective.
Traditionally it done manually.

The main function of the system is to register and store student details, retrieve these details as and when
required and also to manipulate these details meaningfully.

1.3 . SCOPE

The purposed software product is the Student Management System .The system will be used in any
school, College and coaching institute to get the information from the student and then storing the data for
future usage.

The current system in use is a paper-based system. It is too slow and cannot provide updated lists of
students within a reasonable timeframe. The intentions of the system are to reduce over-time pay and
increase the productivity.Requirements statements in this document are both functional and non-
functional.
 HARDWARE & SOFTWARE REQUIREMENT
2.1 HARDWARE REQUIREMENT

 PENTIUM 4 processor or higher

 128 MB RAM (or above)
 40 GB or more HARDDISK
 Mouse/Keyboard

2.2 SOFTWARE REQUIREMENT

 OS-Windows 8/9/10/11
 Python Interpreter
 VS Code
 XAMPP( For Mysql ) or Mysql Workbench
 TECHNICAL DESCRIPTION
3.1: FRONT END DESCRIPTION

LANGUAGE: Python

Python is widely general-purpose , high level programming language. It was initially designed by Guido
van Rossum in 1991 and developed by Python Software Foundation.It was mainly developed for
emphasis on code readability and its syntax allows programmers to express concepts in fewer lines of
code.

Python is a programming language that lets you work quickly and integrate systems more efficiently.

Python is dynamically typed and garbage-collected. It supports multiple programming paradigms,

including procedural , object-oriented, and functional programming. Python is often described as a
“batteries included” language due to its comprehensive standard library.

Tkinter

Tkinter is a Python binding to the Tk GUI toolkit. It is the standard Python interface to the Tk GUI
toolkit, and is Python’s de facto standard GUI. Tkinter is included with standard Linux, Microsoft
Windows and Mac OS X installs of Python.

The name Tkinter comes from Tk interface.Tkinter was written by Fredrik Lundh.
 SOFTWARE ANALYSIS AND DESIGN
4.1.1. Software Development Life Cycle

4.2.2 Description of Used Model

The Waterfall model is a sequential software development process, in which progress is seen as flowing
steadily downwards(like a waterfall) through the phases of Conception, Initiation, Analysis,
Design(validation), Construction, Testing and Maintenance.

To follow the Waterfall model , one proceeds from one phase to the next in a sequential manner.For
example, one first completes requirements specification, which after sign-off are considered “set in
stone.” When the requirements are fully completed, one proceeds to design .The software in question is
designed and a blueprint is drawn for implementors(coders) to follow—this design should be a plan for
implementing the requirements given. When the design is fully completed, an implementation of that
design is made by coders.Towards the later stages of this implementation phase, separate software
components produced are combined to introduce new functionality and reduced risk through the removal
of errors.
Thus the waterfall model maintains that one should move to a phase only when its preceding phase is
completed and perfected.However, there are various modified waterfall models (including Royce’s final
model) that may include slight or major variations upon this process.Time spent early in the software
production cycle can lead to greater economy at later stages. It has been shown that a bug found in the
early stages(such as requirements specification or design ) is cheaper in terms of money, effort and time ,
to fix than the same bug found later on in the process. To take an extreme example, if a program design
turns out to be impossible to implement , it is easier to fix the design at the design stage than to realize
months later, when program components are being integrated , that all the work done so far has to be
scrapped because of a broken design.

This is the central idea behind the waterfall model-time spent early on making sure that requirements and
design are absolutely correct will save you much time and effort later . Thus , the thinking of those who
follow the waterfall process goes , one should make sure that each phase is 100% complete and absolutely
correct before proceeding to the next phase of program creation . Program requirements should be set in
stone before design is started (otherwise work put into a design based on incorrect requirements is
wasted); the program’s design should be perfect before begin work on implementing the design
(otherwise they are implementing the wrong design and their work is wasted ), etc.

A further argument for the waterfall model is that it places emphasis on documentation (such as
requirements documents and design documents ) as well as source code . In less designed and
documented methodologies , should team members leave , much knowledge is lost and may be difficult
for project to recover from. Should a fully working design document be present (as is the intent of Big
Design Up Front and the waterfall model) new team members or even entirely new teams should be able
to familiarize themselves by reading the documents.

Basic principles of the waterfall model are :

Project is divided into sequential phases , with some overlap and splash back acceptable between phases .

Emphasis is on planning , time schedules , target dates , budgets and implementation of an entire system
at one time.

Tight control is maintained over the life of the project through the use of extensive written documentation
, as well as through formal reviews and approval/signoff by the user and information technology
management occurring at the end of most phases before beginning the next phase.

4.2 SOFTWARE DESIGN

4.2.1 Data Flow Diagram

The DFD takes an input-process-output view of a system .That is , data objects flow into the software ,
are transformed by the processing elements , and resultant data objects flow out of the software. Data
objects are represented by labeled arrows and transformations are represented by circles. The DFD is
represented in a hierarchical fashion. The first DFD represents the system as a whole. Subsequent data
flow diagrams provide increasing detail with each subsequent level.
The data flow diagram enables the software engineer to develop models of the information domain and
functional domain at the same time. As the DFD is refined into levels of greater detail, the analysts
perform an implicit functional decomposition of the system .Also DFD refinement results in a
corresponding refinement of data as it moves through the processes that embody the application.

DFD 0 :
DFD 1 :
ENTITY RELATIONSHIP DIAGRAM
Front Page:
Login page : This is the interface where users enter their credentials to access their accounts.
The data has been update
 TESTING
Testing is more than just debugging. The purpose of testing can be quality assurance, verification and
validation or reliability estimation. Correctness testing and reliability testing are two major areas of
testing. Software testing is a trade -off between budget, time and quality.

SOFTWARE TESTING

Software testing is the process of excuting a program or system with the intent of finding errors.Or it
involves any activity aimed at evaluating an attribute or capable or capability of a program or system and
determining that it meets its required results.Software is not unlike other physical processes where inputs
are received and outputs are produced.Where software differs is in the manner in which it fails .Unlike
most physical systems, most of the defects in software are design errors , not manipulating defects.

To improve quality

As computer and software are used in critical applications, the outcome of a bug can be severe. Bugs can
cause huge losses.

For Verification and Validation(V & V)

Another important purpose of testing is verification and validation(V & V).It is heavily used as a tool in
the V &V process. Testers can make claims based on interpretations of the testing results, which either the
product works under certain situations, or it does not work

Software Testing Types:

1. Black-Box testing

The Black-box approach is a testing method in which test data are derived from the specified functional
requirements without regard to the final program structure.It is also termed data-driven, input/output
driven or requirements-based testing. A testing method emphasized on executing the functions and
examination of their input and output data.

2. White-box testing

Contrary to black-box testing , software is viewed as a white-box , or glas-box in white-box testing, as the
structure and flow of the software under test are visible to the tester. This testing is based on knowledge of
the internal logic of an application’s code. Testing plans are made according to the details of the software
implementation, such as programming language, logic and styles. Test cases are derived from the program
structure . White-box testing is also called glass-box testing, logic-driven testing or design -based testing.

3. Unit testing

This involves testing of individual software components or modules.Typically done by the programmer
and not by the testers, as it requires the detailed knowledge of the internal program design and code.

4. System testing
Entire system is tested as per the requirements. Black-box type testing that is based on overall
requirements specifications, covers all combined parts of a system.

5. End-to-end testing

Similar to system testing , involves testing of a complete environment in a situation that mimics real-
world use, such as interacting with a database, using network communications, or interacting with other
hardware, applications , or systems if appropriate.

6. Usability testing

User-friendliness check application flow is tested, Can new user understand the application easily ,Proper
help documented whenever user stuck at any point. Basically system navigation is checked in this testing.

7. Install/uninstall testing

Testing for full, partial, or upgrade install/uninstall processes on different operating systems under
different hardware, software environment.

8. Recovery testing

Testing how well a system recovers from crashes , hardware failures or other catastrophic problems.

9. Security testing

Can system be penetrated by any hacking way. Testing how well the system protects against unauthorized
internal or external access Checked if system, database is safe from external attack.

10. Compatibility testing

Testing how well software performs in a particular hardware/software/operating system/network

environment and different combination of above.

11. Comparison Testing

Comparison of the product strengths and weaknesses with previous versions or other similar products.

12. Alpha testing

In house virtual user environment can be created for this type of testing. Testing is done at the end of
development. Still minor design changes may be made as a result of such testing.

13. Beta testing

Testing typically done by end-users or others. Final testing before releasing application for commercial
purpose.
 BENEFITS
 Software provides easy management of student records.
 Software has very user friendly interface which is very easy to handle and understand.
 Software provides security to private data by hiding them.
 Software uses very less memory and takes less time to startup.

LIMITATIONS
 Software is limited to desktop only.
 System requires python interpreter installed on the system.
 All options of student management are not included in current version.
 Security options provide only low level security against beginner attackers.
 GUI is English only.

FUTURE ENHANCEMENT
 This software can be made for all OS.
 Higher security features can be included in the software.
 Program scheduling can be included in the software.
 This software can be developed to use as tutorial to teach basic concepts of OS to new users.
 This system can be implemented with OS to reduce overhead of installing and running interface
of each and every tool at different place.
 Automatic shutdown through SMS service can be implemented in this.