Академический Документы
Профессиональный Документы
Культура Документы
CHAPTER 1
INTRODUCTION
1.1. PROJECT OVERVIEW
The project K.S.R.T.C MANAGEMENT maintains the arrival & departure of bus in
Calicut station. Application of bus management helps the station employees to do their
work in a simple and easy manner. The station master will have a record of the K.S.R.T.C
station employees which helps him /her to create the report efficiently. This project makes
the work in a K.S.R.T.C office more flexible and easier manner. He can assign the
employees to a trip after checking the availability of them.
1.2. OBJECTIVES
By doing this project the authorities of K.S.R.T.C can have the details of route
and time of the each bus in an easier and simple manner. This aims to:
Page 1
CHAPTER 2
SYSTEM ANALYSIS
2.1. EXISTING SYSTEM
There is no knowledge for station master about the duties of each employee by
checking existing system. He/she is unaware about the daily collections of each trip of
different bus to different route. It is very difficult to check the details of each employee for
updating, viewing and deleting the details.
2.1.1. Drawbacks
Some drawbacks for manual system
Time consumption
Error factor
Difficult to maintain
Less security
Robustness
Possibility of upgrading
Easy of usage
Page 2
Enhanced security
Operational feasibility
Technical feasibility
Economic feasibility
Page 3
Is there sufficient support for the project from the management? From users? If the
present system is well liked and used to extent that the persons will not able to see
reasons for a change, there may be resistance.
Are current business methods acceptable to the users? If they are not? Users may
welcome a change that will bring about a more operational and useful system.
Are the users been involved in the planning and development of the project? If
they are involved at the earlier stage of the project developed, the changes of
resistance can be possibly reduced.
Issues that appear to be quite minor at the earlier stage can grow into major
problems after implementation. Therefore, it is always advisable to consider
operational aspects carefully.
Page 4
Does the proposed equipment have the technical capacity to hold the data required
to use the new system?
Are there technical guarantees of accuracy, reliability, ease of access and security?
Page 5
CHAPTER 3
SYSTEM SPECIFICATION
Hardware and software requirements for the installation and smooth functioning of this
product could be configured based on the requirements needed by the component of the
operating environment that works as front-end system here we suggest minimum
configuration for the both hardware and software components.
Working off with this software is requirements concrete on system environments. It
includes three phases.
Hardware Requirements
Software Requirements
Pentium 4 processor
512 RAM
40 GB HDD
MYSQL
Page 6
CHAPTER 4
SOFTWARE DESCRIPTION
4.1. FRONT END: JAVA
.
Java is a general-purpose computer programming language that is concurrent, classbased, object-oriented, and specifically designed to have as few implementation
dependencies as possible. It is intended to let application developers "write once run
anywhere" (WORA), meaning that code that runs on one platform does not need to be
recompiled to run on another. Java applications are typically compiled to byte code that can
run on any java virtual machine (JVM) regardless of computer architecture. Java is, as of
2014, one of the most popular programming languages in use, particularly for client-server
web applications, with a reported 9 million developers. Java was originally developed by
James Gosling at Sun Microsystems (which has since merged into Oracle Corporation) and
released in 1995 as a core component of Sun Microsystems' java platform. The language
derives much of its syntax from C and C++, but it has fewer low level facilities than either
of them.
The original and reference implementation Java compiler, virtual machines, and class
libraries were originally released by Sun under proprietary licenses. As of May 2007, in
compliance with the specifications of the java community process, Sun relicensed most of
its Java technologies under the GNU general public license. Others have also developed
alternative implementations of these Sun technologies, such as the GNU compiler for
java (byte code compiler), GNU class path (standard libraries), and iced-tea-Web (browser
plug-in for applets).
4.1.1 Java platform
The main goal of Java is portability, which means that programs written for the Java
platform must run similarly on any combination of hardware and operating system with
adequate runtime support. This is achieved by compiling the Java language code to an
intermediate representation called java byte code, instead of directly to architecturespecific machine code. Java byte code instructions are analogous to machine code, but they
are intended to be executed by a virtual machine (VM) written specifically for the host
hardware. End users commonly use a java runtime environment (JRE) installed on their own
machine for standalone Java applications, or in a web browser for Java applets.
Standardized libraries provide a generic way to access host-specific features such as
graphics, threading and networking.
A major benefit of using byte code is porting. However, the overhead of interpretation
means that interpreted programs almost always run more slowly than programs compiled to
Page 7
Page 8
Page 9
CHAPTER 5
PROJECT DESCRIPTION
Page 10
CONTEXT LEVEL
LEVEL 1
Page 11
Page 12
Page 13
CHAPTER 6
SYSTEM TESTING
Test Plan
The Software Test Plan describes plans for qualification testing of Computer
Software configuration Items and software systems. It describes the Software test
environment to be used for the testing, identifies the test to performed, and provides
schedules for test activities.
Testing strategy
The overall strategy for Software testing is described in the following section. We
will use four different methods to test our software.
6.1. UNIT TESTING
In unit testing, the analyst tests the programs making up a system. This is also called
program testing. The software units that make up the system are modules and the routines,
which are assembled and integrated to perform a specific function in a large system. Many
modules at different levels are needed. Unit testing, independent of one another, focuses on
modules to locate error. This enables the tester to detect error in coding and logic that are
contained within that module alone. Those resulting from the interaction between modules
are initially avoided. Unit Test comprises the test of performed prior to integration of the
unit into the entire project. Four categories of test are performed on each unit.
Functional Test
The code is exercised with nominal input values for which the expected results are
shown, as well as boundary values (Minimum values, Maximum values) and values on
and just outside the functional boundaries and special values such as logically related
inputs.
Page 14
Performance Test
Performance test is done to determine the amount of execution time spent in various
parts of the unit, program throughput, and response time and device utilization by the
program unit. Some time is taken initially to link to the SQL.
Stress Test
Stress Test has been done to intentionally break the unit. This helps in the learning
about the strength and limitations of the program by examining the manner in which a
program unit breaks.
Structure Test
Structure test are done to test the internal logic of a program and traversing particular
exercise, deriving test data to exercise those paths, determining the test coverage criteria to
be used.
6.2. ACCEPTANCE TESTING
After the developers complete the system testing successfully acceptance testing is
done at the customer end. It is the customer or the end user who knows designs the test
cases. in this type of testing emphasis is on the usability of the product. Acceptance testing
is supported through alpha and beta testing. Alpha testing is done when the software is made
operational for the first time to be tested by the users at developers site. Hence it is possible
that it will involve making lot of changes to program code. Beta testing follows alpha testing
but now the testing is done at the customers site that validates the product after using it for
few days. At this stage few changes as compared to alpha testing would make to the product.
6.3. TEST CASES
The evaluation of test cases is done through test case review. And for any review, a
formal document or work product is needed. This is the primary reason for having the test
case specification in the form of document. The test case specification document is
reviewed, using a formal review process, to make sure that the test cases are consistent with
the policy specified in the plan, satisfies the chosen criteria, and in general cover the various
aspect of the unit to be tested.
Department of information technology
Page 15
Page 16
CHAPTER 7
SYSTEM IMPLEMENTATION
Implementation is the process of converting a new or revised system design into an
optional one. It is the key stage in achieving a successful new system because usually it
involves a lot of upheaval in the user department. It must therefore be carefully planned and
prepared. Once the software is fully developed and implemented, the department starts to
use the software. The department also grows and more divisions may be attached, or the
database of the department can grow in size. So after sometime the software, this has to be
installed need some modification. If the software need modification all the needed to
develop new software has to be executed. The need has to be studied, the design has to be
made and the coding has to be done. The new module has to be connected to the existing
software modules Even if the software working perfectly also we have to do routine testing
and new bug if found out, has to be fixed. No software ever developed will be bug free
forever.
Page 17
CHAPTER 8
APPENDIX
8.1 SCREEN SHOT
Page 18
Page 19
Page 20
Page 21
Page 22
Page 23
Page 24
Page 25
Page 26
Elements of system analysis -Fourth Edition, By Marvin Gore & John W Stubbe
Page 27