KSRTCTickt RSRV

Mini Project Report
on
KSRTC TICKET RESERVATION

In the partial fulfillment of 4th semester of MCA
by
VANDANA A K
REG NO: 95570059
DEPARTMENT OF COMPUTER APPLICATIONS COCHIN UNIVERSITY OF SCIENCE AND TECHNOLOGY KOCHI-22
COCHIN UNIVERSITY OF SCIENCE AND TECHNOLOGY KOCHI 682022
Master of Computer Applications (MCA)
CERTIFICATE
This is to certify that the Project entitled KSRTC TICKET RESERVATION submitted to Cochin University of Science And Technology as a partial fulfillment of the requirement for the award of Master of Computer Applications is a bonafide record of the project work done by VANDANA A K (Reg no : 95570059) in the year 2010 under your supervision and guidance.
Examiner Signature: Place: Date:
[Type text]
Page 2
DECLARATION
I hereby declare that the work being presented in the project report KSRTC TICKET RESERVATION in partial fulfillment of the requirement of the degree of Master of Computer Application is authentic record of my own work carried out at College and not submitted anywhere else for any degree or diploma.
This to certify that above information is correct to the best of my knowledge.
VANDANA A K
[Type text]
Page 3
ACKNOWLEDGEMENTS
This Project itself is an acknowledgement to the inspiration, drive and technical assistance contributed by many individuals. This project would have never seen the light of this day without the help and guidance I have received.
I express my gratitude to Dr. K.V. Pramod, Head, Department of Computer Applications, Cochin University of Science And Technology, Cochin, Kerala for providing me with excellent infrastructure and awesome environment that laid potentially strong foundation for my professional life.
I also express my deep gratitude to my beloved teachers Ms. Malathi S, Dr. B. Kannan for their keen interest, timely suggestions and help for completing of this mini project. I extend my sincere thanks all non-teaching staffs for providing the necessary facilities. I extend my heartfelt thanks to my parents, friends and well wishers for their support and timely help.
VANDANA A K
[Type text]
Page 4
CONTENTS
TITLE
PAGE NO:
1. INTRODUCTION
1.1 PROJECT OVERVIEW 1.2 PROJECT OBJECTIVE 1.3. PROBLEM DEFINITION
2. SYSTEM ANALYSIS
2.1. PURPOSE 2.2. EXISTING SYSTEM 2.2.1 LIMITATIONS 2.3. FEASIBILITY 2.3.1 TECHNICAL FEASIBILITY 2.3.2 ECONOMIC FEASIBILITY 2.3.3 OPERATIONAL FEASIBILITY 2.4. FACT FIND TECHNIQUES 2.5. PROPOSED SYSTEM 2.5.1 ADVANTAGES
9 - 12
3. SYSTEM REQUIREMENTS SPECIFICATION

3.1 PURPOSE, SCOPE AND OVERVIEW 3.2. GENERAL DESCRIPTION 3.2.1. PRODUCT PERSPECTIVE
13- 16
[Type text]
Page 5
3.2.2. PRODUCT FUNCTIONS 3.2.3. USER CHARACTERICTICS 3.2.4. GENERAL CONSTRAINTS 3.3. FUNCTIONAL REQUIREMENTS 3.4. USER INTERFACE REQUIREMENTS 3.5. PERFORMANCE REQUIREMENTS 3.6. NON FUNCTIONAL REQUIREMENTS
5. SQA PLAN
5.1 PURPOSE 5.2 REFERENCE TASKS 5.3 SQA TASKS 5.4 STANDARDS, PRACTICES, CONVENTIONS, METRICS 5.5 TEST 5.6 TOOLS, TECHNIQUES AND METHODOLOGIES 5.7 APPENDIX
17- 26
6. SYSTEM ENVIRONMENT
6.1 HARDWARE SPECIFICATION 6.2 SOFTWARE SPECIFICATION 6.2.1. OPERATING SYSTEM 6.2.2. ABOUT THE LANGUAGE
27- 35
7. SYSTEM DESIGN
7.1. INTRODUCTION 7.2. INPUT DESIGN 7.3. OUTPUT DESIGN 7.4. SYSTEM MODULES 7.5. DATABASE DESIGN 7.6. TABLE DESIGN
36 54
[Type text]
Page 6
7.7. ARCHITECTURAL DESIGN
8. SYTEM TESTING
8.1. INTRODUCTION 8.2. TYPES OF TESTING 8.2.1 UNIT TESTING 8.2.2 INTEGRATION TESTING 8.2.3 VALIDATION TESTING 8.2.4 ALPHA TESTING 8.2.5 BETA TESTING 8.3. TEST CASES
55- 58
9. SYSTEM IMPLEMENTATION
9.1. INTRODUCTION 9.2. TRAINING 9.3. REVIEW
59 60
10. MAINTENANCE 11. CONCLUSION 12. SCREEN SHOTS 13. BIBLIOGRAPHY
61 62 63- 74 75
[Type text]
Page 7
1. INTRODUCTION
1.1 PROJECT OVERVIEW

A service, which provides information about the KSRTC bus timings. The proposed system is a web based application which provides information regarding the bus timings as per request of the user. The user enquires bus services from a particular source, specifying the date and time and details about the available buses can be viewed in a time sorted fashion. Also provides the facility to reserve tickets by online. If the reservation is successful, the server will send back a reservation code to the customer.
1.2 PROJECT OBJECTIVE The passengers can use the system for specifying their source place and destination place. They will be provided with the details of the next available services immediately so that they can plan their journey accordingly. The passengers can reserve tickets.
1.3 PROBLEM DEFINITION The current system to know the bus timings can be of three types: 1) The passengers must enquire directly 2) The passengers must make use of the telephone facility 3) The passengers must wait for their required bus.
[Type text]
Page 8
2. SYSTEM ANALYSIS
2.1 INTRODUCTION
Analysis can be defined as breaking up of any whole so as to find out their nature, function etc. a statement of these findings. It defines design as to make preliminary sketches of; to sketch a pattern or outline for plan. To plan and carry out especially by artistic arrangement or in a skillful way. System analysis and design can be characterized as a set of techniques and processes, a community of interests, a culture and an intellectual orientation. The various tasks in the system analysis include the following. Understanding application. Planning. Scheduling. Developing candidate solution. Performing trade studies. Performing cost benefit analysis. Recommending alternative solutions. Selling of the system. Supervising, installing and maintaining the system.
System analysis involves the study of an application area to fully understand the problem being posed. Activities are focused on developing a comprehensive knowledge of the existing system, its strengths and weaknesses and the reasons for the need to restructure, replace, or automate the existing system. Risk assessments and risk containment plan, cost estimation and plans for the remainder of the development are results usually prepared by the system analyst as a by-product of system analysis.
[Type text]
Page 9
2.2 EXISTING SYSTEM

Now a days in Kerala State Road Transport Corporation there is no online reservation
2.2.1 Limitations of Existing System The current system to know the bus timings can be of three types: Enquiry 1) The passengers must enquire directly: it is possible that the concerned staff will be not in his seat. 2) The passengers must make use of the telephone facility: telephone lines will be busy at times, or calls may be unattended. 3) The passengers must wait for their required bus: is a rather time consuming process, as it is possible that sometimes there would be no buses available to the desired place for a long period of time. Reservation 1) The passengers must reserve tickets directly. So they have to wait in long queue and reserve tickets. This will be time consuming. 2) The passengers must wait for their required bus without reserving: is a rather time consuming process ,as it is possible that some times there would be no buses available to the desired place for a long period of time.
2.3 FEASIBILITY STUDY

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 lime. This is where creativity and imagination are used. Analysts must think up new ways of doing things- generate new ideas. There is no need to go into the detailed system [Type text] Page 10
operation yet. The solution should provide enough information to make reasonable estimates about project cost and give users an indication of how the new system will fit into the organization. It is important not to exert considerable effort at this stage only to find out that the project is not worthwhile or that there is a need significantly change the original goal. Feasibility of a new system means ensuring that the new system, which we are going to implement, is efficient and affordable. There are various types of feasibility to be determined. They are, Technical feasibility Operational feasibility Economic feasibility
Technical feasibility This evaluation determines whether the technology needed for the proposed system is available and how it can be integrated within the organization .Technical evaluation must also assess whether the existing systems can be upgraded to use the new technology and whether the organization has the expertise to use it. Operational feasibility Operational feasibility covers two aspects. One is a technical performance aspect and the other is acceptance within the organization. Technical performance include issues such as determining whether the system can provide the right information for the organizations personnel, and whether the system can be organized so that it always delivers this information at the right place and on time. Acceptance revolves around the current system and its personnel. Operational feasibility must determine how the proposed system will fit in with the current operations and what, if any, job restructuring and retraining may be needed to implement the system. Economic feasibility This evaluation looks at the financial aspects of the project. It determines whether the investment needed to implement the system will be recovered. Economic feasibility concerns returns from the investments in a project. It determines whether it is worthwhile to invest the money in the proposed project or whether something else should be done with [Type text] Page 11
it. To carry out economic feasibility study, it is necessary to place actual money values against any purchases or activities needed to implement the project.
2.4 FACT FIND TECHNIQUES

The project team studied about the running system and discussed it with the concerned authorities and there by evolved a system that is feasible in every respect. The group accomplished these tasks by studying about the present scenario through various fact finding techniques that made it more clearly about the system to be developed. These techniques include interviews with the concerned authorities and also the observation made by the project team. The interview being accomplished between the authorities that made the authority to clearly specify the system that they propose to develop. The feature that must be included has been clearly specified at this stage. Also the observations of the present running technique were observed there by the limitations of the existing system being overcome.
2.5 PROPOSED SYSTEM

The project aims at relieving the user of the hardships, mentioned above in the existing system. The passengers can enquire about various bus services specifying their source place and destination place. They will be provided with the details of the next available services immediately so that they can plan their journey accordingly. It is an easy to use application and any person with an internet access can use it. The passengers can reserve tickets. 2.5.1 Advantages of Proposed System It is very simple to use. It is a relatively fast approach to know the bus timings. Is highly reliable, unless for network failure.
[Type text]
Page 12
3. SYSTEM REQUIREMENTS SPECIFICATION
3.1 PURPOSE,SCOPE AND OVERVIEW
Purpose:
To understand the nature of the program to be building the software
engineers must understand the information domain for the software. Here the document specifies the software requirements of automating the functions. The document gives different software and hardware requirements of the system. This will help the users to understand their own needs. It will be the validation of final project. Scope: This document is the only one that describes the requirements of the system
to be developed. The Software is helpful for both the administrator and the customers. This one is intended to provide facilities like bus details, depot details etc. Overview: The objective of the proposed system is to provide the organization a new
system that provides all the functionalities specified by the organization, that is more user friendly and less complex than the existing system. The administrator has options for adding items in to bus details, adding depot details. Security features are also enhanced in the system by checking the user name and password. The important functionalities of the proposed system are

Provision to know the entire bus details Updation of bus details, depot details, fare details Reserved Passengers Details
3.2 GENERAL DESCRIPTION
3.2.1 Product Perspective The existing system is manual. The details of different Bus Details, Depot details, Fare details and passenger reservation details are stored in different files. It is difficult to handle all these files. [Type text] Page 13
3.2.2 Product Functions Proposed systems are beneficial only if they can be turned into information system that will meet the organizations operating requirements. People are inheritably resistant to change and computers have been known to facilitate change. An estimate should be made to know how strong the reaction of a user staff is likely to have towards the development computerized system. Since this system is ready to use in the organization, this system operationally feasible. As this package is technically, economically and functionally feasible, the system is judged feasible. Viewing the collected information, recommendation and justification, conclusions is made of the proposed system. 3.2.3 User Characterictics The main users of this product are those who have the right to access this software. These users are sure to be literate with the computers. 3.2.4 General Constraints As the clients is not used to an automated environment they didnt impose any stringent constraints over the system. But they put they forth some important comment that is desirable for the proposed system. Server expected to run under administrative privilege system. Users shall use the functionality directly. The system shall permit only authorized members who having the appropriate right to update, edit and delete the information. It should be easy to upgrade the system.
3.3 FUNCTIONAL REQUIREMENTS Functional requirements are statement of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situation. The KSRTC Ticket Reservation System provides the following facilities [Type text] Page 14
Adding details of new Buses & Depots Updation of Bus, Depot details Passenger Reservation, Cancellation Details Updation of Fare Details
3.4 USER INTERFACE REQUIREMENTS The system should be designed in such a way that only authorized people should be allowed to access some particular modules. The records should be modified by only administrators and no one else. The user should always be in control of the application and not the vice versa. The user interface should be consistent so that the user can handle the application with ease and speed. The application should be visually, conceptually clear. Administrator module: Administrators Login Bus Details Depot Details Reservation Details Fare Details User module: Search Bus Availability Reservation Cancellation
3.5 PERFORMANCE REQUIREMENTS The system must have following characters: [Type text] Page 15
The system is developed keeping in mind both the users and the administrator. All the user requests are to be processed instantaneously thus enabling the results to be delivered on time. The administrators should be provided with a host of options to control the functioning of the system. The entire process related tools has to be automated thus providing the user with an option of taking up of their choice as and when required. Considering the interactive nature of the task the system must have the following characters. Minimum response time Efficient CPU utilization Less Memory space High reliability High flexibility User friendly 3.6. OTHER NON FUNCTIONAL REQUIREMENTS Nonfunctional requirements define system properties and constraints it arises through user needs, because of budget constraints or organizational policies, or due to the external factors such as safety regulations, privacy registration and so on. Nonfunctional requirements are: Security Reliability Maintainability Portability Extensibility Reusability Application Affinity/Compatibility Resource Utilization
[Type text]
Page 16
4. SQA PLAN
4.1 PURPOSE, SCOPE AND OVERVIEW The purpose of this plan is to define the Software Quality Assurance (SQA) for KSRTC TICKET RESERVATION SYSTEM, SQA tasks and responsibilities; provide reference documents and guidelines to perform the SQA activities; provide the standards, practices and conventions used in carrying out SQA activities; and provide the tools, techniques, and methodologies to support SQA activities, and SQA reporting. This plan establishes the SQA activities performed throughout the life cycle of the KSRTC TICKET RESERVATION SYSTEM. The goal of the SQA program is to verify that all software and documentation to be delivered meet all technical requirements. The SQA procedures defined herein shall be used to examine all deliverable software and documentation to determine compliance with technical and performance requirements.
4.2 REFERENCE TASKS The following documents were used or referenced in the development of this plan
IEEE STD 730-2002, IEEE Standard for Software Quality Assurance Plans Software Engineering Concepts Richard Fairley
4.3 SQA TASKS Good software practice requires a measure of independence for the SQA group. This independence provides a key strength to SQA; that is, SQA has the freedom, if the quality of the product is being jeopardized, to report this possibility directly above the level of the project. While in practice this rarely occurs, for almost all problems are correctly addressed at the project level, the fact that the SQA group can go above the project level gives it the ability to keep many of these problems at the project level.
[Type text]
Page 17
Figure below shows the SQA organization with relation to the project organization.
Program Management/ Line Management (Sponsor) IV &V SEPO
SQA
Project Management SCM
Systems Engineering
Software Development
Software Test
System Test
Logistics
Figure: KSRTC Ticket Reservation Organization
The following describes the functional groups that influence and control software quality. (a) Program Management/Line Management (Sponsor) is responsible for the following items:
Identifying an individual or group independent from the project to audit and report on the projects SQA function.
Identifying the quality factors to be implemented in the system and software.
(b) Project Management is responsible for: Resolving and following-up on any quality issues raised by SQA. Identifying, developing and maintaining planning documents such as the Program Management Plan. (c) System Engineering is responsible for: Implementing the engineering practices, processes, and procedures as defined in program/project planning documents. [Type text] Page 18
(d) Software Design/Development is responsible for: Identifying, implementing, and evaluating the quality factors to be implemented in the software. (e) Software Test is responsible for: Verifying , Implementing the software test practices, processes, and procedures as defined in program/project planning documents. (f) System Test is responsible for: Verifying the quality factors are implemented in the system (software and hardware). (g) Logistics is responsible for: Reviewing and commenting on the KSRTC Ticket Reservation System SQA Plan. Implementing the quality program in accordance with this SQA Plan. (h) Software Configuration Management (SCM) is responsible for: Implementing the SCM practices, processes, and procedures as defined in reference (e) and other program/project planning documents. (i) Independent Verification and Validation (IV&V) is responsible for: Implementing the practices, processes, and procedures as defined for IV&V in program/project planning documents. (j) Systems Engineering Process Office (SEPO) is responsible for: Maintaining the SQA Process. Ensuring SQA training availability. Providing assistance in software process engineering and software process improvement.
TASKS TO BE PERFORMED
An SQA task is performed in relationship to what software development activities are taking place. One or more SQA tasks can be performed concurrently until a task is completed. Evaluate System Requirements Analysis Process Evaluate System Design Process [Type text] Page 19
Evaluate Software Requirements Analysis Process Evaluate Software Design Process Evaluate Software Tools Evaluate Software Implementation and Unit Testing Process Evaluate End-item delivery Process Evaluate Configuration Management Process
DOCUMENTATION
This section identifies the minimum documentation governing the requirements, development, verification, validation, and maintenance of software that falls with in the scope of this software quality plan. Each document below shall be assessed (reviewed) by SQ personnel.
MINIMUM DOCUMENTATION REQUIREMENT

Quality Manual Software Assurance plan Software Management plan Configuration Management plan Software Requirements Specification Risk Management plan Software Safety plan Test Plans (Verification and Validation) Software Users Guide Software Maintenance plan Interface Control Document(s) Test Reports and Artifacts Software Version Description Document (VDD) Software Requirements Traceability Matrix Software Development Records Peer Review data packages
[Type text]
Page 20
4.4 STANDARDS, PRACTICES, CONVENTIONS AND METRICS To verify the delivery of a fully conforming, high-quality product, every individual assigned to the project will participate in quality assurance. This section describes the procedures used by SQA to verify that the quality assurance provisions of this SQA Plan and applicable standards, practices, conventions, and metrics are met. The following measurements will be made and used to determine the cost and schedule status of the SQA activities: SQA milestone dates (planned) SQA milestone dates (completed) SQA work scheduled (planned) SQA work completed (actual) SQA effort expended (planned) SQA effort expended (actual) SQA funds expended (planned)
SOFTWARE REVIEWS
This section identifies the number and type of system/subsystem reviews and engineering peer reviews that will be supported by the SQ Personnel. The Software Management plan (SMP), the project milestone chart, the projects Engineering Peer Review plan, and the SQ Personnel resource levels determine the reviews that are supported.
MINIMUM SOFTWARE REVIEWS
For each review, SQ will assess the review products to assure that review packages are being developed according to the specified criteria, the review content is complete, accurate, and of sufficient detail, and Requests for Action are captured, reviewed, and tracked to closure. In addition, SQ will assess the processes used to conduct the reviews to determine if appropriate personnel are in attendance, correct information is presented, entry and exit criteria are met, and appropriate documents are identified for update.
[Type text]
Page 21
The following software reviews may be assessed by SQ:

System Concept Review (SCR) Software Specification Review (SSR) Preliminary Design Review (PDR) Critical Design Review (CDR) Test Readiness Review (TRR) Acceptance Review (AR) Peer Reviews (EPR)
5.5 TEST
KSRTC TICKET RESERVATION SYSTEM testing activity includes
unit level testing, integration testing, performance testing (CI Qualification Testing), and acceptance testing (System Qualification Testing). Figure provides the Test Process Flow. SQA shall audit and verify that the software and test documentation is subject to configuration management control. SQA shall witness the tests and verify that test results are recorded and evaluated. SQA shall coordinate the maintenance of Problem/Change Report (P/CR), sometimes called Software Trouble Report (STR), logs with SCM and shall verify that software changes are controlled according to reference (e). SQA shall witness regression-testing resulting from P/CRs or STRs to verify the effectiveness of the correction.
[Type text]
Page 22
CM Controlled: SRS, Design Spec, Source Code
Testing
Test Results
Expected Results
Test Configuration: Test Plan, Test Cases, Test Procedures, Test Tools, Test Environment
Evaluation
Errors
Corrections
PROBLEM REPORTING AND CORRECTIVE ACTION
This section describes the reporting and control system used by SQA to record and analyze discrepancies and to monitor the implementation of corrective action. The forms utilized by SQA for reporting are the Process Audit Report, P/CR or STR, Software Tool Evaluation Report, and Facilities Evaluation Report. Each of these forms and their uses are discussed in the following section.
[Type text]
Page 23
5.6 TOOLS, TECHNIQUES, AND METHODOLOGIES Tools - SQA software tools include, but are not limited to, operating system utilities, debugging aids, documentation aids, checklists, structuring preprocessors, file comparators, structure analyzers, code analyzers, standards auditors, simulators, execution analyzers, performance monitors, statistical analysis packages, software development folder/files, software traceability matrices, test drivers, test case generators, static or dynamic test tools, and information engineering CASE tools. Techniques - techniques include review of the use of standards, software inspections, requirements tracing, requirements and design verification, reliability measurements and assessments, and rigorous or formal logic analysis. Methodologies - methodologies are an integrated set of the above tools and techniques. The methodologies should be well documented for accomplishing the task or activity and provide a description of the process to be used. Where applicable, SQA will use SEPO organizational processes and tailor the processes specific to the project.
CODE CONTROL
Code control includes the items listed below:

Identifying, labeling, and cataloging the software to be controlled Identifying the physical location of the software under control Identifying the location, maintenance, and use of backup copies Distributing copies of the code Identifying the documentation that is affected by a change Establishing a new version Regulating user access to the code.
[Type text]
Page 24
MEDIA CONTROL
Media control includes adequate protection from unauthorized access. Media control includes the items listed below:

Regularly scheduled backup of the media. Labeled and inventoried media filed in a storage area in accordance with security requirements and in a controlled environment that prevents degradation or damage to the media.
Adequate protection from unauthorized access.
SUPPLIER CONTROL
Prior to any purchase of software to support the development effort, SQA and project members will define and provide complete requirements to the supplier/vendor. The Software Tool Evaluation Process will be followed. Part of the evaluation process will require the supplier or vendor to describe their technical support, handling of user questions and problems, and software product upgrades. All supplier software has been operationally tested in the target system. No future supplier software is planned.
RECORDS COLLECTION, MAINTENANCE AND RETENTION
SQA activities are documented by records and reports that provide a history of product quality throughout the software life cycle. Measurement data collected will be reviewed for trends and process improvement. All SQA records will be collected and maintained in the SDL or archival storage for the life cycle of the product.
[Type text]
Page 25
5.7 APPENDIX AI CMM CRLCMP CI DBDD DCR DID FCA FQR IDD IEEE IRS IV&V KPA OJT PCA P/CR PDR PP&O PRR SCM SDD SDF SDP SDR SEI SEPO SME SPI SQA SRR Action Item Capability Maturity Model Computer Resource Life Cycle Management Plan Configuration Item Database Design Description Document Change Request Data Item Description Functional Configuration Audit Formal Qualification Review Interface Design Description Institute of Electrical and Electronics Engineers Interface Requirements Specification Independent Verification and Validation Key Process Area On-the-Job Physical Configuration Audit Problem/Change Report Preliminary Design Review Project Planning and Oversight Product Readiness Review Software Configuration Management Software Design Document Software Development File Software Development Plan System Design Review Software Engineering Institute Systems Engineering Process Office Software Management for Everyone Software Process Improvement Software Quality Assurance System Requirements Review
[Type text]
Page 26
6. SYSTEM ENVIRONMENT
6.1 HARDWARE SPECIFICATION Processor RAM Hard Disk Drive Monitor Keyboard Mouse CD ROM Drive : : : : : : : P4, 1GHz 256 MB memory 20 GB disk space Resolution 1024 x 768 101/102 Natural Keyboard PS/2Compatible 52x max
6.2 SOFTWARE SPECIFICATION Operating System Front End Back End Development Tools Other softwares Photoshop : : : : : Windows XP/ Vista J2EE SQL Server 2000 Netbeans IDE InternetExplorer, DreamWeaver,
6.2.1 OPERATING SYSTEM INFORMATION
WINDOWS XP OPERATING SYSTEM
The operating system used was Microsoft Windows XP. The Windows XP provides a suitable environment for the smooth functioning of the project. Windows XP makes personal computing easy. Power, performance, a bright new look and plenty of help when you need it-Windows XP has it all, along with unmatched dependability and security. [Type text] Page 27
Windows XP professional marks a new standard in business software combining enterprise-class performance and reliability with unprecedented ease of use. Built on the rock-solid foundation of Microsofts proven Windows 2000 technology, Windows XP Professional contains all the features of Microsoft Windows XP Home Edition, and includes new and enhanced features designed especially for business and advanced use. The all-new Help and Support Center in Windows XP is our one-stop shop for: Clear how-to instructions Engaging start-to-finish articles Troubleshooting advice. Special wizards give you step-by-step instructions to smooth the way when connecting new devices and running new software.
6.2.2 ABOUT THE LANGUAGE
JAVA
Java is a high level programming language. It is a language of choice fro developing both internet and internet applications. Software developers who use Java benefit by developing code only once, with no need to port their application to every software and hardware platforms. The Java programming language is indeed valuable for distributed network environments like web. However, it goes well beyond this domain to provide a powerful general-purpose language suitable for building a variety of applications that either does not depend on network features, or want them for different reasons. Java is used in this application to create JavaBeans. JavaBeans is a software component that can be inserted seamlessly into a larger software environment. A bean is nothing but a Java class. What makes a class become a bean is that it is written in a way that obeys some of all the programming conventions specified in Suns JavaBeans Specification Document.
[Type text]
Page 28
Java Environment: The java environment is composed of several separate entities. Java Language: This is a language that follows object-oriented concept used to create executable contents such as applications and applets. But Java is not pure object oriented language, it does not support multiple inheritance & Operator overloading. Java Runtime Environment: The runtime environment used to execute the code. It is made up of the java language and java virtual machine. It is portable and it is platform neutral. Java tools: It is used by the developers to create java code. They include java compiler, java interpreter, classes, libraries and applet viewer. Java Application: Applications are programs written in java to carry out certain tasks on stand alone local computer. Execution of a stand-alone program involves two steps. 1. Compiling the source code in to byte code using javac. 2. Executing byte code program using java interpreter Java Applets: Java applets are pieces of java code that are embedded in HTML document using the applet tag. When the browser encounters such code it automatically download it and execute it. Java Virtual Machine: It is a specification to which java codes must be written. All java code is to be compiled in this nonexistent virtual machine. Writing the code that compiles in JVM ensures platform independence. Advantages of Java Java is Robust Java is secure Java is Portable [Type text] Page 29
Java is small Java is garbage collected Java is dynamic
Reason for Using Java: It is required to explore systems running different operating system. In order to do so, there should be some way to connect to bridge those operating systems so that all the differences between them are solved and the functionalities are achieved. Also the functions performed in one system should be able to transfer to another and the result should be able to reflect there properly. Java serves as a bridge between these Operating systems. Also java is widely considered to be the best in developing network applications. The communication happens between Java Virtual Machines running on the systems. When the client wants to perform the functionalities in another system and see the result, a method in the remote system is invoked from the client. The corresponding method in the remote system performs the job and sends the results to the client that is reflected in its interface.
J2EE
Java Platform, Enterprise Edition or Java EE (formerly known as Java 2 Platform, Enterprise Edition or J2EE until the name was changed to Java EE in version 1.5), is a programming platformpart of the Java Platformfor developing and running distributed multi-tier architecture Java applications, based largely on modular software components running on an application server. The Java EE platform is defined by a specification. Similar to other Java Community Process specifications, Java EE is also considered informally to be a standard because providers must agree to certain conformance requirements in order to declare their products as Java EE compliant; albeit with no ISO or ECMA standard. Java EE includes several API specifications, such as JDBC, RMI, e-mail, JMS, web services, XML, etc, and defines how to coordinate them. Java EE also features some specifications unique to Java EE for components. These include Enterprise JavaBeans, servlets, portlets (following the Java Portlet specification), Java Server Pages and several web service technologies. This allows the developer to create an enterprise application that is [Type text] Page 30
portable between platforms and scalable, while integrating with legacy technologies. Other added bonuses are, for example, that the application server can handle the transactions, security, scalability, concurrency and management of the components that are deployed to it, meaning that the developers can concentrate more on the business logic of the components rather than infrastructure and integration tasks.
JAVA SERVER PAGES (JSP)
Java Server Pages or JSP make the web pages highly dynamic and customizable according to the user requirements and interests and make it highly interactive. It can reach into a vast database and present just the information you want. Like other technologies JSP mixes HTML tags with programming language code. The programming language code helps a computer decide what to do next. JSP is a server side technology, so a JSP document can share data among users, access database, and do all other things that require server intervention. Unlike other technologies JSP takes full advantage of the leverage provided by the Java programming language. Java is a powerful, general-purpose language with a huge collection of Application Programming Interfaces (APIs). JSP has a distinct advantage over many other technologies. Java is not a scripting language, so a JSP document does not get fully reinterpreted with each and every users visit. On first use, a JSP document gets compiled into a Java byte code and can be easily ported from one platform to another. JSP is all about generating dynamic content; content that differs based on user input, time of day, the state of an external system, or any other runtime conditions.
JAVA DATABASE CONNECTIVITY (JDBC)
JDBC is an API for the Java programming language that defines how a client may access a database. It provides methods for querying and updating data in a database. JDBC is oriented towards relational databases. The Java Database Connectivity (JDBC) API is the industry standard for database-independent connectivity between the Java programming language and a wide range of databases SQL databases and other tabular data [Type text] Page 31
sources, such as spreadsheets or flat files. The JDBC API provides a call-level API for SQLbased database access. The Java Platform, Standard Edition includes the JDBC API together with an ODBC implementation of the API enabling connections to any relational database that supports ODBC. JDBC technology allows you to use the Java programming language to exploit "Write Once, Run Anywhere" capabilities for applications that require access to enterprise data. With a JDBC technology-enabled driver, you can connect all corporate data even in a heterogeneous environment.
The JDBC API makes it possible to do three things: Establish a connection with a database or access any tabular data source Send SQL statements Process the results
ADVANTAGES OF JDBC TECHNOLOGY
Leverage Existing Enterprise Data With JDBC technology, businesses are not locked in any proprietary architecture, and can continue to use their installed databases and access information easily even if it is stored on different database management systems. Simplified Enterprise Development The combination of the Java API and the JDBC API makes application development easy and economical. JDBC hides the complexity of many data access tasks, doing most of the "heavy lifting for the programmer behind the scenes. The JDBC API is simple to learn, easy to deploy, and inexpensive to maintain. Zero Configuration for Network Computers With the JDBC API, no configuration is required on the client side. With a driver written in the Java programming language, all the information needed to make a connection is completely defined by the JDBC URL or by a Data Source object registered with a Java Naming and Directory Interface (JNDI) naming service. Zero configurations for clients supports the network computing paradigm and centralizes software maintenance.
[Type text]
Page 32
Key Features Full Access to Metadata The JDBC API provides metadata access that enables the development of sophisticated applications that need to understand the underlying facilities and capabilities of a specific database connection. No Installation A pure JDBC technology-based driver does not require special installation; it is automatically downloaded as part of the applet that makes the JDBC calls. Database Connection Identified by URL JDBC technology exploits the advantages of Internet-standard URLs to identify database connections. The JDBC API includes an even better way to identify and connect to a data source, using a Data Source object, which makes code even more portable and easier to maintain. In addition to this important advantage, Data Source objects can provide connection pooling and distributed transactions, essential for enterprise database computing. This functionality is provided transparently to the programmer.
JAVA SCRIPT & HTML
JavaScript is an object based scripting language that offers cross platform operation across the span of the WWW. JavaScript provides a means of embedding interactive paths and intelligence within HTML documents. The object-based nature of JavaScript offers programmers significant power and flexibility through the ability to create functions and new objects. Performing certain processing functions at the client side such as form validation and data retrieval from local data arrays-reduces the burden imposed on the server side and can provide a sense of greater responsiveness to a viewer an HTML document enhanced with JavaScript. As the term website development sounds unique language strikes is every ones mind, which is nothing but hypertext Markup Language. This language specifies all the function in a single sentence, which is called as Tag. This language has Built-in Tags to specify the contents of the Web Pages. The main advantage of this language is easy to learn and use. It does not state out the errors. Browser based software takes less memory and
[Type text]
Page 33
executes at faster rate. All browser based software executes at client side and hence in faster execution. HTML, stands for Hypertext Markup Language, is the predominant markup language for the creation of web pages. It provides a means to describe the structure of textbased information in a document so on by denoting certain text as headings, paragraphs, lists and
and to supplement that text with interactive forms, embedded images and other
objects. HTML is written in the form of labels (known as tags), surrounded by less-than (<) and greater than (>) signs. HTML can also describe, to some degree, the appearance and semantics of a document, and can include embedded scripting language code, which can affect the behavior of web browsers and other HTML processors. JavaScript is a scripting language most often used for client-side web development. Its standardized name is ECMA Script, though JavaScript is much more commonly used. JavaScript is actually Netscape Communications Corporations (and now the Mozilla Foundations) implementation of the ECMA Script standard. JavaScript is a dynamic, weakly typed, prototype-based language with first class functions. JavaScript was influenced by many languages and was designed to have a similar look to Java, but be easier for non-programmers to work with. The language is best known for its use in websites (as client-side JavaScript), but is also used to enable scripting access to objects embedded in other applications. Despite the name, JavaScript is unrelated to the Java programming language.
CSS
Cascading Style Sheets or CSS allow you to control the layout and look of your page easily. CSS tags or properties are easy to use and affect the look and feel or style of your pages. Cascading Style Sheets (CSS) is a style sheet language used to describe the presentation (that is, the look and formatting) of a document written in a markup language. Its most common application is to style web pages written in HTML and XHTML, but the language can be applied to any kind of XML document, including SVG and XUL.
[Type text]
Page 34
CSS is designed primarily to enable the separation of document content (written in HTML or a similar markup language) from document presentation, including elements such as the colors, fonts, and layout. This separation can improve content accessibility, provide more flexibility and control in the specification of presentation characteristics, enable multiple pages to share formatting, and reduce complexity and repetition in the structural content (such as by allowing for table less web design). CSS can also allow the same markup page to be presented in different styles for different rendering methods, such as on-screen, in print, by voice (when read out by a speech-based browser or screen reader) and on Braille-based, tactile devices. While the author of a document typically links that document to a CSS style sheet, readers can use a different style sheet, perhaps one on their own computer, to override the one the author has specified.
OTHER SOFTWARES PHOTOSHOP
The Photoshop includes the primary tools to work with graphics. These include the tools that let you use type, and select, paint, draw, sample, edit, move, annotate, and view images. Understand the difference between raster and vector graphics. Create images using Layers.
DREAMWEAVER
Dreamweaver is used because it provides a high quality design with ease of designing.
INTERNET EXPLORER
Internet is the Microsofts contribution to the Web browser community. The Internet Explorer is based on Microsofts ActiveX technology and is available for Windows, Windows NT, and Macintosh platforms. One significant capability of the Internet Explorer is that support the embedded intrinsic and ActiveX controls within the Web pages, with which JavaScript can interact.
[Type text]
Page 35
7. SYSTEM DESIGN
7.1 INTRODUCTION TO SYSTEM DESIGN
Software design involves external design, architectural design and detailed design. Architectural and detailed design is collectively known as the Internal Design. The designing phase identifies the functions, which have to be performed by the system. Techniques are manifestation of concepts. Techniques changes with technology, economic condition and social concerns, but the fundamental principle does not change. The fundamental concept on which the entire project is going to be built is: 1. Abstraction Abstraction is an intellectual tool that separates conceptual aspects of a system from implementation details. Three levels of abstraction are implemented in the entire process of the system. The user is forbidden from the various internal operation of the system. The logic that is applied for calculating various processes is hidden from the user. The user is also not aware of the different data type, which is used in the system. Abstraction also helps to maintain data integrity of the system. 2. Information Hiding The information provided by the user is hidden from other user. This will be to keep integrity of the information, which is provided by the user. In this approach, each module in the system hides the internal details of its processing activity and modules communicate only through well-defined interfaces. 3. Structured process Structure permits decomposition of a large system into small, manageable units with well-defined relationship to the other unit in the system. The structure procedure is implemented in this system by breaking down the detailed system into small structured [Type text] Page 36
sub-system. The sub-system is linked with the entire system by some relational operation procedure. So it is easy to develop and debug the system. 4. Modularity Modular system consists of well-defined, manageable units with well-defined interface among the units. The system has these modular qualities. a. Each unit is a processing abstraction. b. Each function in each abstraction has a single well-defined abstraction. c. Each function manipulates one major data structure. d. Functions that manipulate instance of abstract data type are encapsulated with the data structure being manipulated. The entire project is developed according to the above mentioned standards. The project layout is categorized into different design for easy understanding.
7.2 INPUT DESIGN
In Input Design part, it is decided how data are accepted for computer processing. The design of input also includes specifying the means by which end user and system operators direct the system in which action is to be taken. The placement of the data, heading and titles on display and source documents are also part of input design. The inputs are designed in such a way that entry is made easy with minimum number of data entry errors. Data Entry Methods For data entry, three methods are used: Fill in the form method It is the simplest and the most common approach. The screen resembles a printed form which prompts indicating what data is needed. The user enters data one field at a time, using tab key or mouse to move between the fields.
[Type text]
Page 37
List processing method In this method, user can select only one value from the list provided. This type of entry simplifies the validation checking since only valid data are shown in the list. Checkbox method In this method, user can select any number of values from the list provided. This simplifies the bulk data entry and validation simultaneously. Most data entry screens are given the same style using tables. Increased Throughput To increase the throughput, default values are provided for certain fields. Field prompts and Field display Each field in the data entry has a unique and easy understandable prompt. User cannot enter a data which is greater in size that the defined size of the field. When the user exceeds the limit specified, then the system will not accept the exceeded part of the data. Moving Between Fields The cursor normally starts at the first field. Then it is traversed to the subsequent fields. The user can move between the fields either by using the Tab Keys or Mouse pointer. Navigation buttons Several navigation facilities are implemented in the system for easy movement of user from page to page. The following are the commonly used buttons, links and interfaces used for easy page manipulation. Home: The hyper link HOME is provided for instantly loading the home page from any page. Back: The hyper link BACK is provided for instantly loading the previous page from the current page.
[Type text]
Page 38
Continue: The hyper links CONTINUE is provided to process the input data and to load the next page. Menu Design: The menu is designed to consist of various hyperlinks to move between different options available.
7.3 OUTPUT DESIGN
Output generally refers to the results and information that are generated by the system. Output is the main objective of any system and has to be in a presentable form. Almost all summaries and output are printed on the console in centrally aligned format. All buttons are provided at the bottom of the table. The output summary of the tables and fields are displayed in a table format and the respective heading of the table are printed in bold font. The table structure gives the output a pleasing look and it is legible that the user can understand it properly.
7.4 SYSTEM MODULES
The project is divided into two modules namely, Administrator Module User Module
Administrator Module The administrator is the person who is responsible for maintaining the database. He has the authority to store and manipulate data. He inserts new data into the database, updates existing data, remove unwanted data and view all data.
[Type text]
Page 39
In Administrator module there are three sub modules. 1. Bus Information Adds new bus information, modifying bus details, delete unwanted bus details and view all bus details. 2. Depot Information Adds new depot information, modifying depot details, delete depot details and view all depot details. 3. Reservation Details Checking Views the list passengers reserved for a particular bus.
User Module A user is anyone who uses the system. 1. Enquiry Module Online Enquiry By specifying the Source, Destination, Date, Type of bus , time, the system will generate a list of buses available satisfying user conditions. 2. Viewing Depot Details It is possible for user to view the details of any Depot. Details include Station master, Unit Officer and their phone numbers. 3. Reservation Module Online Reservation In on line reservation the customers can take print out of the ticket directly. Here user can select his seats. The user must have to enter credit card number and bus fare will be taken from his account. 4. Cancellation The Passengers can then cancel their tickets by entering the reservation code. For Mobile cancellation the passengers have to send reservation code. At the time of cancellation only Ninety percentage of total fare will be returned back to the passenger [Type text] Page 40
7.5 DATABASE DESIGN
Databases are the store houses of data used in the software system. A database is a collection of stored data organized in such a way that the data requirements are satisfied by the database. The data is stored in tables inside a database. The general theme of database design is to handle information as an integrated whole, with a minimum redundancy and improved performance. Regardless of the type of data structure used, the objectives of the database are accuracy and integrity and successful recovery from failure, privacy and security of data, and good overall performance. A table is designed as a collection of rows and columns, which are in turn called as tuples and attributes. Tuple is nothing but a record in the table. A record is a collection of one or more inter-related fields. The table is an object of Relational Database Management System (RDBMS), which is used to store and retrieve the data much easier and faster. The tables should be carefully designed because the efficiency of the software is based on the effective table design. Two essential settings for a database are Primary key - The field that is unique for all the record occurrences. Foreign key - The field used to set relation between tables. Normalization is a technique to avoid redundancy in the tables.
[Type text]
Page 41
7.6 ARCHITECTURAL DESIGN
7.6.1 TABLE STRUCTURE
Table 1: admin
Table 2: Bus_details
[Type text]
Page 42
Table 3: Depot_details
Table 4: Fare_details
Table 5: Reservation
[Type text]
Page 43
Table 6: Reserved_passengers
[Type text]
Page 44
Table 7: Cancelled_passengers
Table 8: Bank_details
[Type text]
Page 45
7.6.2
DATA FLOW DIAGRAMS
Introduction to DFD A data flow diagram (DFD) is a structured analysis and design tool that can be used for flow charting in place, or in association with, information oriented and process-oriented system flowcharts. A DFD is a network that describes the flow of data and the processes that change, or transform data throughout a system. This network is constructed by using a set of symbols. They are symbols that represent data sources, data flows, data transformations and data storage. Dataflow diagrams are divided in to two. 1. Logical DFD 2. Physical DFD Logical DFD is an implementation independent view of a system, focusing on the flow of data between processes without regard for the specific devices, storage locations or people in the system. In logical DFD the physical characteristics will not be listed. Physical DFD is an implementation dependant view of the current system, showing what tasks are carried out and how they are performed. Physical characteristics include names of people form and document names or numbers, names of departments, master and transaction file locations and names of procedures. The four basic symbols used to construct data flow diagrams are shown below.
[Type text]
Page 46
A double square represent a data source or destination
A directed arrow represents the flow of data
An enclosed figure represents a process that transforms data streams
An open-ended rectangle represents data storage.
[Type text]
Page 47
ADMINISTRATOR LEVEL DFD
Level 0 DFD
Administrator
Request Automated Transportation
Result
Administrator
Level 1: Administrator
Administrator Details Bus Information Accessing Username, Password Module Log in Depot Invalid Entry Accessing Module Details 3.0 Administrator Results Results
Administrator
[Type text]
Page 48
Level 2: Bus Information
Adding Bus Busno, Sfrom, To, category, btime, no of seats, path, distanc Busno, Sfrom, Information to, category, 2.1 Updating Busno, Bus Information 2.2 Deleting Bus Busno, source, date Information 2.3 btime, no of seats, path, Sfrom,to, distanc category,btime, no of seats, path, distanc Busno, source, date Busno, Sfrom, to, category, btime, no of seats, path. Bus details
Administrator
source, date Busno, source, date
Viewing
[Type text]
Page 49
Level 2: Depot Details
Adding Depot Depot name, code, unit officer, stationmaster, Std code, phno unit officer, phno station master Information 3.1 Updating Depot Administrator Depot Code Depot Code Deleting Depot Depot Code Information 3.3 Depot name, code, unit officer, stationmaster, Std code, phno unit officer, phno station master Information 3.2 Depot Code Depot details Depot name, code, unit officer, stationmaster, Std code, phno unit officer, phno station master Depot information
Viewing 3.4
[Type text]
Page 50
USER- LEVEL DFD
User level 0
User
Request Automated Transportation
Result
User
User Level 1
Enquiry Accessing Module Accessing User Module Reservation code Results User 1.0 Results
Reservation 2.0
Depot code
Cancellation 3.0
Depot name, stationmaster, ph no, unit officer, ph no.
Viewing Depot Details 4.0 Depot name, Station master, ph no, unit officer, ph no. Depot Details
[Type text]
Page 51
User Level 2 : Enquiry
Source, Destination, Time User Depot table selection
Schedule list Source Depot Table
Check Schedules
Return Schedule
User
[Type text]
Page 52
User Level 2 : Reservation
Source, User Destination Time, no of seats Depot Table Selection
Check Schedules
Schedule List
Depot Table
Reservation details
Bank details Fares Fare Bus type Reservation Process
Reservation details
distance Bus Details
Reserved passengers details User
Reservation details
[Type text]
Page 53
User Level 2: Cancellation
Reservation code User Cancellation
Reservation details
Credit card no Amount Details of Details of passengers account holders
Bank details
Reserved passengers details Details of Passengers
User
Cancelled passengers details
[Type text]
Page 54
8. SYSTEM TESTING
8.1 INTRODUCTION TO SYSTEM TESTING
Software testing is the process used to access the quality of computer software. Software testing is an empirical technical investigation conducted to provide stakeholders with information about the quality of the product or service under test, with respect to the context in which it is intended to operate. This includes, but is not limited to the process of executing a program or application with the intent of finding software bugs. Quality is not an absolute; it is value to some person. With that in mind testing can never completely establish the correctness of arbitrary computer software; testing furnishes a criticism or comparison that compares the state and behavior of the product against a specification. An important point is that software testing should be distinguished from the separate discipline of software quality assurance (or SQA) which encompasses all business process areas, not just testing. Over its existence, computer softwares has continued to grow in complexity and size. Every software product has a target audience. For eg: video game software has its audience completely different from backing software. Therefore, when an organization develops or otherwise in a software product, it presumably must access whether a software product will be acceptable to its end users, its target audience, its purchasers and other stakeholders. Software testing is the process of attempting too makes this assessment. In this phase the entire software system is tested. The reference document for this process is the requirements document, and the goal is to see whether the software meets the requirements. This is essentially a validation exercise, and in many situations it is only a validation activity. Testing focuses on the external behavior of the system. Software testing methods are traditionally divided into black box testing and white box testing. These two approaches are used to describe the point of view that a test engineer takes when designing test cases. Black box testing treats the software as a black-box without any understanding of internal behavior. It aims to test the functionality according to the requirements. Thus, the tester inputs data and only sees the output from the test object .This level of testing usually [Type text] Page 55
requires thorough test cases to be provided to the tester who then can simply verify that for a given input, the output value (or behavior) is the same as the expected value specified in the test case. Black box testing methods include: Equivalence partitioning, boundary value analysis, all pairs testing, fuzz testing, model-based testing, traceability matrix etc. White box testing, however, is when the tester has access to the internal data structures, code and algorithms. White box testing methods include creating tests to satisfy some code coverage criteria. For eg, the test designer can create test box all statements in the program to be executed at least once. Other egs. of White box testing are mutation testing and fault injection methods. White box testing includes all static testing .This testing is based on knowledge of the internal logic of an applications code. Also known as glass box testing. Internal; software and code working should be known for this type of testing. Tests are based on coverage of code statements, branches, paths, conditions.
8.2 TYPES OF TESTING
8.2.1 UNIT TESTING
In computer programming, Unit testing is a procedure used to validate that individual units of source code are working properly. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual program, function, procedure etc, while in object oriented programming the smallest unit is a method, which may belong to a base/super class, abstract class or derived/child class. Ideally, each test case is independent from the others; mock or fake objects as well as test harnesses can be used to assist testing a module in isolation. Unit testing is typically done by software developers to ensure that the code they have written meets software requirements and behaves as the developer intended. In this test we test each module individually but not integrate the whole system. It focuses verification efforts even in the smallest unit of software design in each module. This is also known as Module Testing. The testing is carried out in the programming style itself. In this testing each ,module is focused to work satisfactorily as regard to the expected output from the module .There are some validation checks for the fields.
[Type text]
Page 56
8.2.2 INTEGRATION TESTING
Integration testing (sometimes called, Integration and testing, abbreviated I&T) is the phase of software testing in which individual software modules are combined and tested as a group. It follows unit testing and precedes system testing. Integration testing takes as its input modules that have been unit tested groups them in larger aggregates, applies test defined in an integration test plan to those aggregates, and delivers as its output the Integrated system ready for system testing. Data can be lost across an interface, one module can have adverse effect on the other sub-functions, when combined may not produce the desired functions. Integration testing is the systematic testing to uncover the errors within the interface. This testing is done with simple data. The need for an integrated system is to find the overall performance. The purpose of Integration testing is to verify functional, performance and reliability requirements placed on major design items. These design items, ie, assemblages(or group of units),are exercised through their interfaces using black box testing, success and error cases being simulated via appropriate parameter and data inputs. Simulated usage of shared data areas and inter process communication is tested and individual subsystems are exercised through their input interface. Test cases are constructed to test that all components within assemblages interact correctly, for eg across procedure calls or process activations, and this is done after testing individual modules, ie, unit testing.
8.2.3 VALIDATION TESTING
At the culmination of black box testing (here the structure of program is not considered), software is completely assembled as a package. Interface errors have been uncovered and correct and final series of test, ie and validation test begins. The customer defines validation with a simple definition and validation succeeds when the software functions in manner than can be reasonably accepted.
8.2.4 ALPHA TESTING
Alpha testing refers to tests in which user or operator team from customer or client community comes to the developers environment and participates in the testing, sometimes on a separate system. The user or operator team frequently employs their own operational time lines and applications. The approach brings in additional test cases, new operators, and [Type text] Page 57
more operating time on the system. Failure occurrences are documented carefully and forwarded to the test team.
8.2.5 BETA TESTING
Beta testing involves delivery of one or more copies of the software or system to client/customer site(s). Those sites that are given the status of beta site must commit to reporting failures to the test team. Again with more users, with different operators, with more operational time lines, and with more CPU time on the system, more faults will be exposed.
8.3 TEST CASES Test case is an object for execution for other modules in the architecture does not represent any interaction by itself. A test case is a set of sequential steps to execute a test operating on a set of predefined inputs to produce certain expected outputs. There are two types of test cases:-manual and automated. A manual test case is executed manually while an automated test case is executed using automation In system testing , test data should cover the possible values of each parameter based on the requirements. Since testing every value is impractical, a few values should be chosen from each equivalence class. An equivalence class is a set of values that should all be treated the same. Ideally, test cases that check error conditions are written separately from the functional test cases and should have steps to verify the error messages and logs. Realistically, if functional test cases are not yet written, it is ok for testers to check for error conditions when performing normal functional test cases. It should be clear which test data, if any is expected to trigger errors.
[Type text]
Page 58
9.
SYSTEM IMPLEMENTATION
9.1 INTRODUCTION TO SYSTEM IMPLEMENTATION
In the implementation phase all the programs are written, database is created, user operational document is written, users are trained, and the system tested with operational data. The implementation is carried out with the results that have been obtained from the feasibility study and analysis. The system is implemented by finishing the project with the help of appropriate tools that been suggested and are loaded in to the server. Then the system is tested with appropriate data inputs to check the successfulness of the system. This being carried out by inputting data that are of rare to be inputted. Then the administrator will be trained of the operational functionalities to control and maintain system at a later stage. The third party users role is being carried out by the implementation team itself. There by it is made sure that the system meets the required standards. Installation procedure The installation Procedure is a set of steps that have to be carried out in a specific order for the proper installation of the developed system. Being a web application it requires a fixed space in the server. The first phase is the allocation of system in the space provided in the server. The system is stored in the root directory. This directory is uploaded into the server space that has been allocated. Implementation plan The first phase in the implementation of a system is the plan to make it implement. For proper implementation the plan is a pre-requisite and is known as pre-implementation activity. It is in these steps that various activities which are required for implementing a system are identified and their sequence and relation to each other is desired. In this step various other estimates like time required for each activity and cost estimates are also obtained. For the better description of the plan and implementation various tools like Gantt charts etc have been used. [Type text] Page 59
9.2 TRAINING Adequate user training is very important for the successful implementation of the system. The users may be identified and classified differently on the basis of the operations or functions performed by them. In the KSRTC Ticket Reservation system the administrator is the only person who needs training as he is the only person who needs proper training. Special training programs have been designed so that the administrator can work well in the system. Proper user training is an important factor in promoting the required culture and thus ensuring the acceptance of the new system which is necessary for successful completion.
In the implementation phase, the team builds the components either from scratch or by composition. Given the architecture document from the design phase and the requirement document from the analysis phase, the team should build exactly what has been requested, though there is still room for innovation and flexibility. For example, a component may be narrowly designed for this particular system, or the component may be made more general to satisfy a reusability guideline. The architecture document should give guidance. Sometimes, this guidance is found in the requirement document. The implementation phase deals with issues of quality, performance, baselines, libraries, and debugging. The end deliverable is the product itself. During the implementation phase, the system is built according to the specifications from the previous phases. This includes writing code, performing code reviews, performing tests, selecting components for integration, configuration, and integration.
[Type text]
Page 60
10. SYSTEM MAINTENANCE
The results obtained from the evaluation process help the organization to determine whether its information systems are effective and efficient or otherwise. As the organization existing in a dynamic and competitive environment evaluation is a continuing activity. On the basis of the feedback provided by the evaluation process the organization in order to keep its system at the highest levels of effectiveness and efficiency of course within cost constraints must respond by taking corrective actions. It may include removing errors and enhancing the existing system. The process of monitoring, evaluating and modifying of existing information systems to make required or desirable improvements may be termed as system maintenance. When the system is in maintenance phase, some people with in the system are responsible for collecting maintenance requests from users and other interested parties. The process of maintaining system is the process of returning to the beginning of system development phase until changes implemented. System maintenance is the activity that occurs following the delivery of the software product enhancement to software products adapting products to new environment and correcting errors. Software products enhancement may involve providing new functional capabilities improving user displays and modes of intersection or upgrading the performance characteristics of the system.
The maintenance includes three set of activities. Corrective. Adaptive. Perfective.
[Type text]
Page 61
11. CONCLUSION
Any system which has been in use for a number of years gradually decays and becomes less effective because of the change in environment to which has to adapt for a time it is possible to overcome problems by amendments and minor modification to acknowledge the need of fundamental changes. Computerization was proposed as a solution to the problem of being out dated with the fast present technologies. In this project, my aim to maximize my effort to computerize it accordingly that meet the entire passenger needs have successfully completed my project work on KSRTC ticket reservation system and the whole system has been done with sample data and output obtained is according to the requirements. In this project we have taken more care to bring this system well above there alms of the manual system. File Handling, processing like deletion, extraction, updating etc can easily achieved. The project has been successfully implemented and is found to replace the manual system efficiently and effectively. We hoped to make this system as user friendly and to use as possible. We tried to achieve this and other objectives to our best. The benefits expected from the developed system outweigh the implementation costs. Data security is provided. The system developed here can be upgraded or expanded, if necessary.
Almost all Processes of the proposed system KSRTC TICKET
RESERVATION SYSTEM have been completed.
Each and every phase in this project is developed keeping the goals in mind
as per as concerned.
Every project has its own limitations. Similarly this project also has its
limitations, which can be upgraded.
[Type text]
Page 62
12. SCREEN SHOTS

1. ADMINISTRATOR LOGIN
2.
ADMINISTRATOR HOME
[Type text]
Page 63
3.
ADMIN- INSERT NEW BUS DETAILS
4.
ADMIN- UPDATE BUS DETAILS
[Type text]
Page 64
5.
ADMIN- DELETE BUS DETAILS
6.
ADMIN- INSERT NEW DEPOT DETAILS
[Type text]
Page 65
7.
ADMIN- UPDATE DEPOT DETAILS
8.
ADMIN- DELETE DEPOT DETAILS
[Type text]
Page 66
9.
ADMIN- INSERT FARE DETAILS
10. ADMIN- UPDATE FARE DETAILS
[Type text]
Page 67
11. ADMIN- SEARCH RESERVATIONS OF A PARTICULAR BUS
12. ADMIN- VIEW DETAILS OF RESERVED PASSENGERS OF A PARTICULAR BUS
[Type text]
Page 68
13. USER- HOME
14. USER- ENQUIRE AVAILABILITY OF BUS SERVICE
[Type text]
Page 69
15. USER- BUS AVAILABILITY SEARCH RESULTS
16. USER- RESERVE TICKETS
[Type text]
Page 70
17. USER- RESERVE TICKETS (SELECT BUS FROM THE AVAILABLE CHOICES)
18. USER- SELECT SEATS FOR YOUR RESERVATION
[Type text]
Page 71
19. USER- ENTER PASSENGER DETAILS FOR RESERVATION
[Type text]
Page 72
20. USER- TICKET CANCELLATION
21. USER- VIEW FARE DETAILS
[Type text]
Page 73
22. USER- SEARCH DETAILS OF A PARTICULAR DEPOT
23. USER- VIEW DETAILS OF A PARTICULAR DEPOT
[Type text]
Page 74
13. BIBLIOGRAPHY
BOOKS [1] System Analysis and Design [2] Elements of System Analysis and design Stubbe [3] Java 2: The Complete Reference (5th Edition) [5] J2EE: The Complete References [6] SQL Server Complete Reference : : : Herbert Schildt Jim Keogh Coffman : : Elias M Awad Marvin Gore/John W
[7]Software Engineering -A Practical Approach, Fifth Edition [8]The Complete Reference HTML [9]Java Script [10]Java 2 Platform : : : : Roger.S.Pressman Kenny Chu Arman Dhanesh Jamie Jaworski
WEBSITES
www.google.com www.wikipedia.org
[Type text]
Page 75

KSRTCTickt RSRV

Uploaded by

Document Information

Original Description:

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

KSRTCTickt RSRV

Uploaded by

Copyright:

Available Formats

Mini Project Report

KSRTC TICKET RESERVATION

DEPARTMENT OF COMPUTER APPLICATIONS COCHIN UNIVERSITY OF SCIENCE AND TECHNOLOGY KOCHI-22

KSRTC TICKET RESERVATION

COCHIN UNIVERSITY OF SCIENCE AND TECHNOLOGY KOCHI 682022

Master of Computer Applications (MCA)

Examiner Signature: Place: Date:

KSRTC TICKET RESERVATION

This to certify that above information is correct to the best of my knowledge.

KSRTC TICKET RESERVATION

KSRTC TICKET RESERVATION

3. SYSTEM REQUIREMENTS SPECIFICATION

KSRTC TICKET RESERVATION

KSRTC TICKET RESERVATION

7.7. ARCHITECTURAL DESIGN

10. MAINTENANCE 11. CONCLUSION 12. SCREEN SHOTS 13. BIBLIOGRAPHY

KSRTC TICKET RESERVATION

1.1 PROJECT OVERVIEW

KSRTC TICKET RESERVATION

KSRTC TICKET RESERVATION

2.2 EXISTING SYSTEM

2.3 FEASIBILITY STUDY

KSRTC TICKET RESERVATION

KSRTC TICKET RESERVATION

2.4 FACT FIND TECHNIQUES

2.5 PROPOSED SYSTEM

KSRTC TICKET RESERVATION

3. SYSTEM REQUIREMENTS SPECIFICATION

3.1 PURPOSE,SCOPE AND OVERVIEW

To understand the nature of the program to be building the software

3.2 GENERAL DESCRIPTION

KSRTC TICKET RESERVATION

KSRTC TICKET RESERVATION

KSRTC TICKET RESERVATION

KSRTC TICKET RESERVATION

KSRTC TICKET RESERVATION

Project Management SCM

Figure: KSRTC Ticket Reservation Organization

Identifying the quality factors to be implemented in the system and software.

KSRTC TICKET RESERVATION

KSRTC TICKET RESERVATION

KSRTC TICKET RESERVATION

KSRTC TICKET RESERVATION

The following software reviews may be assessed by SQ:

KSRTC TICKET RESERVATION

CM Controlled: SRS, Design Spec, Source Code

PROBLEM REPORTING AND CORRECTIVE ACTION

KSRTC TICKET RESERVATION

Code control includes the items listed below:

KSRTC TICKET RESERVATION

Adequate protection from unauthorized access.

KSRTC TICKET RESERVATION

KSRTC TICKET RESERVATION

6.2.1 OPERATING SYSTEM INFORMATION

WINDOWS XP OPERATING SYSTEM

KSRTC TICKET RESERVATION

6.2.2 ABOUT THE LANGUAGE

KSRTC TICKET RESERVATION

KSRTC TICKET RESERVATION

Java is small Java is garbage collected Java is dynamic

KSRTC TICKET RESERVATION

JAVA SERVER PAGES (JSP)