This document is a project report on a Passport Automation System submitted by K. Sheryl Hladini to fulfill requirements for a Master's degree in Computer Applications. It discusses problems with the existing manual passport system and proposes developing a new automated system to streamline the passport application process. The report outlines various sections of the new system including problem definition, feasibility study, software requirements, UML diagrams, testing plans, and conclusions. The feasibility study evaluates the technical, operational, and economic feasibility of the new automated passport system.

1. A PROJECT REPORT ON
PASSPORT AUTOMITION SYSTEM
Project work submitted in partial fulfilment of the requirements for the
award of degree of
MASTER OF COMPUTER APPLICATIONS
Submitted By
K. Sheryl Hladini
(Regd.No.xxxxxxxxxx)
Under the Esteemed Guidance of
Mrs. CH.LAKSHMI M.sc, M. Tech
DEPARTMENT OF COMPUTER SCIENCE
DR.C.S.RAO.P.G.CENTRE:SRI.Y.N.COLLEGE
(Affiliated to Adikavi Nannaya University)
(ACCREDITED BY NAAC WITH ‘A’ GRADE with CGPA 3.40)
(“College with potential for excellence” awarded by UGC)
NARSAPUR- 534275, W.G. District
2016-19
DR.C.S.RAO.P.G.CENTRE: SRI Y.N.COLLEG
(Affiliated to Andhra University)

2. (ACCREDITED BY NAAC WITH ‘A’ GRADE with CGPA 3.40)
(“College with potential for excellence” awarded by UGC)
NARSAPUR- 534275
CERTIFICATE
This is to certify that Ms. K. Sheryl Hladini, Regd No: 1686951021 has
developed software project titled “PASSPORT AUTOMITION SYSTEM” for as a partial
fulfilment for the award of the Degree of MASTER OF COMPUTER APPLICATIONS in
the Department of Computer Science, Dr.C.S.Rao P.G.Centre, Narsapur. This work is not
submitted to any University for the Award of any Degree/Diploma.
INTERNAL GUIDE HEAD OFTHE DEPARTMENT
------------------------------- - ----------------------------
Submitted for the practical examination & viva-voice held on---------------
Internal Examiner External Examiner
---------------------------- -----------------------

3. S.NO CONTENTS PAGE.NO
1.
2.
3.
4.
5.
6.
PROBLEM DEFINITION
FEASIBILITY STUDY
2.1.TECHNICALFEASIBILITY
2.2.ECONOMICALFEASIBILITY
2.3.OPREATIONALFEASIBILITY
SOFTWARE REQUIREMENTS
SPECIFICATIONS
ESTIMATION OF PROJECT METRICS
E-R DIAGRAM
UML-DIAGRAMS
1. USECASE
2. CLASS
3. SEQUENCE
4. COLLABORATION
5. ACTIVITY
6. STATE CHRT
1 - 3
4 - 5
6 - 10
11 - 12
13 – 14
15 - 26

4. 7.
8.
9.
10.
TEST COVERAGE
CONCLUSION AND FUTUR SLOPE
GLOSSARY
REFERENCES
27 - 38
39
40 - 42
43

5. ABSTRACT:
The project “Passport Automation System” is used in the effective dispatch of passport
to all of the applicants. This system adopts a comprehensive approach to minimize the
manual work and schedule resources, time in a cogent manner. The core of the system is to
get the online registration form (with details such as name, address etc.,) filled by the
applicant whose testament is verified for its genuineness by the Passport Automation System
with respect to the already existing information in the database.
It aims at improving the efficiency in the Issue of Passport and reduces the complexities
involved in it to the maximum possible extent.

6. CHAPTER-1
PROBLEM
SPECIFICATION

8. 1. INTRODUCTION
1. PROBLEM DEFINITION:
Passport Automation System is used in the effective dispatch of passport to all of the
applicants. This system adopts a comprehensive approach to minimize the manual work and
schedule resources, time in a cogent manner. The core of the system is to get the online
registration form (with details such as name, address etc.,) filled by the applicant whose
testament is verified for its genuineness by the Passport Automation System with respect to
the already existing information in the database.
This forms the first and foremost step in the processing of passport application. After the
first round of verification done by the system, the information is in turn forwarded to the
regional administrator's (Ministry of External Affairs) office. Then the applications processed
manually based on the report given by the system, and any forfeiting identified can make the
applicant liable to penalty as per the law.
EXISTING SYSTEM:
The existing system is not providing secure registration and profile management of all
the users properly. This manual system gives us very less security for saving data and some
data may be lost due to mismanagement. In the previous management system all the details
required were taken manually in the form of documents. In this system every individual had
to stand in a queue which involved individuals in huge numbers.
Hence maintaining of documents submitted for passport registration was a tedious work
as many no of individual apply for registration. In this the individual has to go through the
passport office for registering of a passport through a govt .Agent. The Govt. Agent who is
the mediator, is responsible for registration of passport and any mistake made by the agent
makes it a major concern for the individual. These agents demanded a huge amount of money
and were not mainly concerned about maintaining the details of every individual in a
confidential and secured manner. Hence the existing system is more time consuming and
involves more manpower.

9. PROPOSEDSYSTEM:
The development of this new system contains the following activities, which try to
automate the entire process keeping in the view of database integration approach. User
friendliness is provided in the application with various controls provided by system rich user
interface. This system makes the overall project management much easier and flexible.
Various classes have been used for maintain the details of all the users and catalog.
Authentication is provided for this application only registered users can access. Report
generation features is provided using to generate different kind of reports. In this system the
individual fills all the information or details required for passport reservation through online.
The individuals have to fill all the details and can’t leave any field as blank.
IMPLEMENTATIONMODULES:
1. Admin
2. Consumer (user)
ADMIN MODULE:
This module provides administrator related functionalities. Administrator can view the all
applicant requirement.
USER MODULE:
This module is about users of this portal. By using this module user can lodge any complaint
about process. User must be registered with the system

10. FUNCTIONALREQUIREMENTS:
This application comprises of six modules. They are
1. Passport infor mat io n
2. Apply for passport
3. Document uploading
4 . P a y m e n t
5 . V e r ific a t io n
6. Authent ica t io n
7. Status verification and feedback/complaints
1. Passport information:
Description: This module is helpful for the people to move to other states or countries
for their needs. There are 3 ways to apply for the passport. They are -New passport, Attala
and Renewal passport.
2. Applying for passport:
This module is used for how to apply for the passport and which certificates we need to
submit for the particular type of passport.
3. Document uploading:
In this module we have to submit the documents.
4. Payment:
This module is used to pay the fee in different ways
5. Verification module:
In this module different department have to verify all the certification offline and they
change the status.
6. Authentication:
This module is used to check the valid user or not.
7. Status verification and feedback/complaints:
This module is used to check the status of verification process and delivery of passport

11. CHAPTER-2
FEASIBILITY
STUDY

12. 2. FEASIBILITY STUDY
Preliminary investigation examine project feasibility, the likelihood the system will be
useful to the organization. The main objective of the feasibility study is to test the Technical,
Operational and Economical feasibility for adding new modules and debugging old running
system. Any system is feasibility if there are unlimited resources and infinite time. There are
aspects in the feasibility study portion of the preliminary and investigation.
 Technical Feasibility
 Operational Feasibility
 Economical Feasibility
2.1 TECHINICAL FEASIBILITY:
The technical issue usually raised during the feasibility stage of the investigation
includes the following:-
 Does the necessary technology exist to do what is suggested?
 Do the proposed equipments have the technical capacity to hold the data required to
use the new system?
 Will the proposed system provide adequate response to inquiries, regardless of the
number or location of users?
 Can the system be upgraded if developed?
 Are there technical guarantees of accuracy, reliability, ease of access and data
security?
Earlier no system existed to cater to the needs of ‘Secure Infrastructure Implementation
System’. The current system developed is technically feasible. The database’s purpose is to
create, establish and maintain a workflow among various entities in order to facilitate all
concerned users in their various capacities or roles specified.

13. The work for the project is done with the current equipment and existing software
technology. Necessary bandwidth exists for providing a fast feedback to the users irrespective
of the number of users using the system
2.2 OPERATIONALFEASIBILITY:
Proposed projects are beneficial only if they can be turned out into information
system. That will meet the organization’s operating requirements. Operational feasibility
aspects of the projects are to be taken as an important issues raised to test operational
feasibility of a project includes the following:-
 Is there sufficient support for the management from the users?
 Will the system be used and worked properly if it is being developed and
implemented?
 Will there be any resistance from the user that will undermine the possible application
benefits?
This system is targeted to be in accordance with the above-mentioned issues.
Beforehand, the management issues and user requirements have been taken into
consideration. So there is no question of resistance from the users that can undermine the
possible application benefits.
The well planned design would ensure the optimal utilization of the computer
resources and would help in the improvement of performance status.
2.3 ECONOMICALFEASIBILITY:
A system can be developed technically and that will be used if installed must still
be a good investment for the organization. In the economical feasibility, the development cost
in creating the system is evaluated against the ultimate benefit derived from the new systems.
Financial benefits must equal or exceed the costs.

14. The system is economically feasible. It does not require any additional hardware or
software. Since the interface for this system is developed using the existing resources and
technologies, there is nominal expenditure and economical feasibility for certain.
CHAPTER-3
SOFTWARE REQUIREMENTS
Specification

15. 3. SOFTWARE REQUIREMENT SPECIFICATION
3.1.1 Whatis SRS?
Software Requirement Specification (SRS) is the starting point of the software
developing activity.
As system grew more complex it became evident that the goal of the entire
system cannot easily comprehend. Hence the need for the requirement phase arose. The
software project is initiated by the client needs. The SRS is the means of translating the
ideas of the minds of clients (the input ) into a formal document (the output of the
requirement phase).
The SRS phase consists of two basic activities:
1. Problem / Requirement Analysis:
The process is order and nebulous of the two, deals with understanding the
problem, goal and constraints.
2. Requirement Specification:
Here, the focus is on specifying what has been giving analysis such as
representation, specification language and tools, and checking specifications that are
addressed during this activity. Producing SRS is the basic goal of this phase.
3.1.2 Role ofSRS:

16. The purpose of the Software Requirement Specification is to reduce the
communication gap between the clients and the developers. Software Requirement
Specification is the medium through which the client and the user needs are
accurately specified. It forms the basis of software development. A good SRS satisfies the
parties involved in the system.
3.1.3 Systemspecifications:
S. No Requirement
ID
Description
1 PRS_UR_01 Login
2 PRS_UR_02 Passport details
3 PRS_UR_03 Passport type

17. 3.1.4 Systemfeature description passport automationsystem:
4 PRS_UR_04 Location
5 PRS_UR_05 Current status
6 PRS_UR_06 Feedback to user
7 PRS_UR_07 Mail to user
8 PRS_UR_08 Post updates
9 PRS_UR_09 Add new user as admin
Requirement ID PRS_UR_02
Title PASSPORT AUTOMATION SYSTEM
Description PASSPORT DETAILS

18. 3.1.5 TotalRequirement Lookup Table:
S. no Requirement
ID
Requirement
Name
Source Stable
(Y/N)
Priority Verifiable
(Y/N)
1 PRS_UR_01 Login Passport Y Medium Y
Participating Actors Member
Input Name, Email id, passport type
Flow events Start
Login
Enter username and password
Runs login module
Login’s
End
Entry condition:
Exit condition:
Member select the login option
Member get the successful message
Special instruction NA

19. 2 PRS_UR_02 Passport
reporting
Passport Y Medium Y
3 PRS_UR_03 Search Passport Y Medium Y
4 PRS_UR_04 Message to
admin
Passport Y Medium Y
5 PRS_UR_05 Send request Passport Y Medium Y
6 PRS_UR_06 Accept request Passport Y Medium Y
7
PRS_UR_07 Mail to user Passport Y Medium Y
8 PRS_UR_08 Post updates Passport Y Medium Y
9 PRS_UR_09 Add new user
as admin
Passport Y Medium Y
3. 2 Non-functional Requirements:
Non-functional requirements describe aspects of the system that are not directly related
to the functional behaviour of the system. Non-functional requirements include a broad
variety of requirements as given below:
Usability:

20. It is the ease with which a user can learn to operate, prepare inputs for, and interpret
outputs of a system or component. Often, clients address usability issues by requiring the
developer to follow user interface guidelines on colour schemes, logos, and fonts.
Reliability:
It is the ability of a system or component to perform its required functions under stated
conditions for a specified period of time. More recently, this category is often replaced by
dependability, which is the property of the computer system such that reliance can justifiably
be place on the service it delivers. Dependability includes reliability robustness, and safety.
Performance:
Performance requirements are concerned with the quantifiable attributes of the system
such as response time, throughput, availability and accuracy
Supportability:
Supportability requirements are concerned with the case of changes to the system after
deployment, including adaptability, maintainability, and internationalization.

21. CHAPTER-4
Estimation
Of
Project metrics

22. 4. ESTIMATION OF PROJECT METRICS
ProjectEstimation Metrics:
Estimation of various project parameters is a basic project planning activity. The
important project parameters that are estimated include:
 Project size: What will be problem complexity in terms of the effort and time required
to develop the product?
 Cost:How much is it goingto cost to developthe project?
 Duration:How longisit goingto take to complete development?
 Effort: How much effort would be required?
COCOMO:
COCOMO (Constructive Cost Estimation Model) was proposed by Boehm. According to
him, any software development project can be classified into one of the following three
categories based on the development complexity: organic, semidetached, and embedded. The
classification is done considering the characteristics of the product as well as those of the
development team and development environment. Usually these three product classes
correspond to application, utility and system programs, respectively. Data processing
programs are normally considered to be application programs. Compilers, linkers, etc., are
utility programs. Operating systems and real-time system programs, etc. are system
programs.
The definition of organic, semidetached, and embedded systems are elaborated below.
 Organic: A development project can be considered of organic type, if the project
deals with developing a well understood application program, the size of the
development team is reasonably small, and the team members are experienced in
developing similar types of projects.

23.  Semidetached: A development project can be considered of semidetached type, if the
development consists of a mixture of experienced and inexperienced staff. Team
members may have limited experience on related systems but may be unfamiliar with
some aspects of the system being developed.
 Embedded: A development project is considered to be of embedded type, if the
software being developed is strongly coupled to complex hardware, or if the stringent
regulations on.
Fig. 11.1: Precedence ordering among planning activities

24. CHAPTER-5
ENTITY-RELATIONSHIP
DIAGRAMS

25. 5. ENTITY RELATIONSHIP DIAGRAM

26. Definition - What does Entity-Relationship Diagram(ERD) mean?

27. An entity-relationship diagram (ERD) is a data modeling technique that graphically
illustrates an information system’s entities and the relationships between those entities. An
ERD is a conceptual and representational model of data used to represent the entity
framework infrastructure.
The elements of an ERD are:
 Entities
 Relationships
 Attributes
Steps involved in creating an ERD include:
 Identifying and defining the entities
 Determining all interactions between the entities
 Analyzing the nature of interactions/determining the cardinality of the relationships
 Creating the ERD
An entity-relationship diagram (ERD) is crucial to creating a good database design. It is
used as a high-level logical data model, which is useful in developing a conceptual design for
databases.
An entity is a real-world item or concept that exists on its own. Entities are equivalent to
database tables in a relational database, with each row of the table representing an instance of
that entity.
An attribute of an entity is a particular property that describes the entity. A relationship is
the association that describes the interaction between entities. Cardinality, in the context of
ERD, is the number of instances of one entity that can, or must, be associated with each
instance of another entity. In general, there may be one-to-one, one-to-many, or many-to-
many relationships.
For example, let us consider two real-world entities, an employee and his department. An
employee has attributes such as an employee number, name, department number, etc.
Similarly, department number and name can be defined as attributes of a department. A
department can interact with many employees, but an employee can belong to only one

28. department, hence there can be a one-to-many relationship, defined between department and
employee.
In the actual database, the employee table will have department number as a foreign key,
referencing from department table, to enforce the relationship.

29. CHAPTER-6
UML-DIAGRAMS

30. 6. UML DIAGRAMS
When object is used in analysis as well as design, the boundary between OOA and
OOD is blurred. This is particularly true in methods that combine analysis and designing.
One reason for this blurring is the similarity of basic constructs (i.e., objects and classes) that
are used in OOA and OOD. Though there is no agreement about what parts of the object –
oriented development process belongs to analysis and what to design; there is some general
agreement about the domains of the two activities.
The fundamental difference between OOA and OOD is that former models the problem
domain, leading to an understanding and specification of the problem, while the latter models
the solution to the problem. That is, analysis deals with the problem domain, while design
deals with the solution domain. However, in OOAD subsumed in the solution domain
representation. That is, the solution domain by OOA.
The separating line is matter of perception, and different people have different views on
it. The lack of clear separation between analysis and design can also be considered one of the
strong points of the object oriented approach the transition from analysis to design is
“seamless”. This is also main reason OOAD methods –where analysis and design are both
performed. The main difference between OOA and OOD, due to the different domains of
modeling, is in the type of objects that come out of the analysis and design process.
6.1 The Genesis ofUML:
Software engineering has slowly become part of our everyday life. From washing
machines to compact disc player, through cash machines and phones, most our daily

31. activities use software, and as time goes by the more complex and costly this
software becomes.
The demand for sophisticated software greatly increases the constraints imposed
on development teams, software engineer are facing a world growing complexity due
to the nature of applications, the distributed and heterogeneous environments, the size
of programs the organization of software development teams, and the end-users
ergonomic expectations.
To surmount these difficulties, software engineers will have to learn not only
how to do their job, but also how to explain their work to others, and how to
understand when others work is explained to them. For these reasons, they have (and
will always have) an increasing need for methods.
6.2 TOWARDS A UNIFIED MODELING LANGUAGE:
The unification of object-oriented modeling methods became possible as
experience all owed evolutions of the various concepts proposed by existing methods.
Based on the face that differences between the various methods were becoming
smaller, and that method was did not move object-oriented technology forward any
longer, James Rum Baugh and Grady Booch decided at the end of 1994 to unify
their work within a single method: the Unified Method. A year later Ivar Jacobson,
the father of use cases, a very efficient technique determination of requirements,
joined them.
Booch, Rumbaugh and Jacobson adopted four goals:
 To represent complete systems (instead of only the software portion) using
object oriented concepts.
 To establish an explicit coupling between concepts and executable code to take
into account the scaling factors that are inherent to complex and critical
systems.
 To creating a modeling language usable by both humans and machines.

32. Software design is a process that gradually changes as various new, better and
more complete methods with a broadest understanding of the whole problem in
general come into existence.
There are various kinds of methods in software design namely.
 Use case Diagram
 Class Diagram
 Sequence Diagram
 Collaboration Diagram
 Activity Diagram
 Start chart Diagram
The system verifies the username and password by crosschecking the entries in
databases
1. The project leaders can add/update/delete the task. He can also assign the task;
view the task assigned, and reschedule the task assigned.
2. The project developer can view the task assigned to him and update the
comments.
6.3 INFORMATION IN SPECIFIC TO MODULES:
6.3.1 DocumentUser Requirements (URD):
The User Requirements Documents (URD) is a document used in software engineering
that specifies the requirements the user expects from software to be constructed in software to
be constructed in a software project.
An important a difficult step of designing a software product is determining what the
customer actually wants it to do. This is because often the customer is not able to
communicate the entirely of their needs and wants, and the information they provide mat also
be incomplete, inaccurate and self-conflicting. The responsibility of completely
understanding what the customer wants then falls on the providers of the product.

33. Once the required information is completely gathered it is documented in a URD, which is
meant to spell out exactly what the software must do and becomes part of the contractual
agreement. A customer cannot demand features not in the URD without renegotiating and a
developer cannot claim the product is ready if it does not meet an item of the URD.
The URD can be used as a guide to planning cost, timetables, milestones, testing, etc. The
explicit nature of the URD allows customers to show it to various stakeholders to make sure
all necessary features are described.
Formulating a URD requires negotiation to determine what is technically and
economically feasible. Preparing a URD is one of those skills that lie between a science and
an art, requiring both software technical skills and interpersonal skills.

34. 1. Use Case Diagram:

35. USER CHARACTERISTICS
Applicant
Applicant
Fill and Submit the Form
Authority
Login
Verification
Enquiry
Local Police
Update
Issue the Passport
System admin
Check Status

36. These are the person who desires to obtain the passport and submit the information to the
database.
Administrator
He has the certain privileges to add the passport status and to approve the issue of
passport. He may contain a group of persons under him to verify the documents and give
suggestion whether or not to approve the dispatch of passport.
Police
He is the person who upon receiving intimation from the PAS, perform a personal
verification of the applicant and see if he has any criminal case against him before or at
present. He has been vetoed with the power to decline an application by suggesting it to the
Administrator if he finds any discrepancy with the applicant. He communicates via this PAS
Additional Features:

37. certificate
photograph
checking original document
enquiry
reappointment
scanning document
passport officer
verification
applicant
<<extend>>
<<include>>

38. 2. Class Diagram:
Name of use case Report
Participating actors Applicant, Passport officer, Local Police and
System Admin
Flow of Events 1: The applicant activates function of this
terminal.
2: System admin gives the form to applicant.
3: The user enters the details of the
application like passport type and resources
needed and submits the form
4: Local police enquires and verify about the
applicant.
5: The system admin check the status and
update the applicant details.
Entry condition The applicant is logged into the passport
automation system.
Exit condition The applicant receives an acknowledgement
and response from the dispatcher or the
passport officer.
Receives an explanation indicating why the
transaction could not be processed.
Quality requirements The applicant report is acknowledged within
time.

39. 3. Sequence Diagram:

40. 4. Collaboration:
Applicant LogiCass AppointmentClass
RegistrationClass DatatBase
UI
Create Login
Enter username/pwd
Check username/pwd
Save username/pwd
get username/pwd
Check username/pwd
show Registration Form
Enter applicant information
check applicant information
save applicant information
get date and time
save date and time
show applicant ID,Date& time

41. 5. Activity Diagram:
applicant passport
administrator
regional
administrator
police database
9: verify the details 12: verify details
15: verify details
Passport Registration
Website
4: validate
19: issue passport
1: registeer
3: login
17: Check Passport Current Status
6: Fill the Application From
5: Validated
18: Display the Current Status
10: update verified details
8: Get the Details
14: get details
16: update verified details
11: Get Details
13: update verified details
2: store the Details
7: Store the Details

42. 6. State Chart Diagram:
Login
Registration
Appointment
Verification
approved
dispatch
passport
police Enquiry
rejected
valid document not satisfied
Valid Document invalid Document

44. CHAPTER-7
TEST COVERAGE

45. 7. TESTING
Software testing is the process used to assess 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.
Testing is a “fault detection technique that tries to create failures or erroneous states in a
planned way”. This allows the developer to detect failures in the system before it is released
to the customer.
Testing furnishes a criticism or comparison that compares the state and behavior of the
product against a specification. The software faults occur through the following process. A
programmer makes an error (mistake), which results in a defect (fault, bug) in the software
source code. If this defect is executed, in certain situations the system will produce wrong
results, causing a failure.
There are many approaches to software testing, Reviews, walkthroughs or inspections are
considered as static testing, whereas actually running the program with a given set of test
cases in a given development stage is referred to as dynamic testing.
Software testing is used in association with verification and validation:
Verification : Have we built the software right?
Validation : Have we built the right software?
Software testing can be done by software tester. The development process involves
various types of testing. Each test type addresses a specific testing requirement. The most
common types of testing involved in the development process are: These approaches are used
to describe the point of view that a test engineer takes when designing test cases.
Usability Testing:

46. Testing that tries to find the faults in the user interface design of the system. Often
systems fail to accomplish their intended purpose simply because their users are confused by
the user interface and unwillingly introduce erroneous data.
Unit Testing:
The first test in the development process is the unit test. The source code is normally
divided into modules, which in turn are divided into smaller units called units. These units
have specific behavior. The test done on these units of code is called unit test. Unit test
depends upon the language on which the project is developed. Unit test ensure that each
unique path of the project performs accurately to the documented specifications and contains
clearly defined inputs and expected results.
Integration Testing:
Testing of finding faults when testing the individual components together. Structural
Testing is the finale integration testing involving all components of the system. Integration
tests and Structural tests exploit knowledge from the SDD using an integration strategy
described in the TP (Test Plan).
System Testing:
Several modules constitute a project. If the project is long-term project, several
developers write the modules. Once all the modules are integrated, several errors may arise.
The testing done at this stage is called system test. System testing ensure that the entire
integrated software system meets requirements. It tests a configuration to ensure known and
predictable results. System testing is based on process descriptions and flown, emphasizing
pre-driven process links an integration points.
Functional Testing:
Functional test can be defined as testing two or more modules together with the intent
of finding defects, demonstrating that defects are not present, verifying that the module
performs its intended functions as stated in the specification and establishing confidence that
a program does what it is supposed to do. Functional testing tests the requirements from the
RAD and the User manual.

47. Performance Testing:
Performance test checks the non-functional requirements and additional design goals
from the SDD (System Design Document). Functional & Performance testing are done by
developers.
Acceptance Testing:
Testing the system with the intent of confirming readiness of the product and customer
acceptance. Acceptance testing is the phase of testing used to determine whether a system
satisfied the requirements specified in the requirements analysis phase. The acceptance test
design is derived from the requirements document. The acceptance test phase is the phase
used by the customer to determine whether to accept the system or not.
Acceptance testing and installation testing check the system against the project
agreement and is done by the client, if necessary, with help by the developers.
Black BoxTesting:
Testing software without any knowledge of the inner workings, structure or language of
the module being tested. It aims to test the functionality according to the requirements. Thus,
the tester inputs data and only sees the output from the test object.
White Box Testing:
Testing in which the software tester has knowledge of the inner workings, structure and
language of the software, or at least its purpose. White box testing methods include creating
tests to satisfy some code coverage criteria (describes the degree to which the source code of
a program has been tested). White Box testing methods can also be used to evaluate the
completeness of a test suite that was created with black box testing methods.
Alpha Testing:
Testing after code is mostly complete or contains most of the functionality and prior to
users being involved. Sometimes a select group of users are involved. More often this testing
will be performed in-house or by an outside testing firm in co-operation with the software
engineering department.

48. Beta Testing:
Testing after the product is code complete. Betas are often widely distributed or even
distributed to the public at large in hopes that they will buy the final product when it is
released.
After completing the code generation for each diagram. Select the tool menu under
quality architect performs unit testing and scenario testing for each code.
Testing activities are made several types of testing is carried on.
7. 1 Design of User Interface & Implementation of Domain & Technical
Services Layer
Form:

56. CHAPTER-8
CONCLUSION
AND
FUTUR Scope

58. 8. CONCLUSION AND FUTURE SCPOE
Thus, the above project for passport automation system has been successfully executed
and codes are generated.
SCOPE:
details and submit the necessary documents (may be by scanning).
workload and process the application in a speedy manner.
verification of applicant's information.
must subject themselves for manual document verification.

59. CHAPTER-9
GLOSSARY

60. 9. GLOSSARY
9.1 DEFINITIONS
Administrator - Refers to the super user who is the Central Authority with the privilege to
manage the entire system. It can be any higher official in the Regional Passport Office of
Ministry of External Affairs.
Applicant - One who wishes to obtain the Passport.
PAS - Refers to this Passport Automation System.
HTML - Mark-up Language used for creating web pages.
J2EE - Java 2 Enterprise Edition is a programming platform java platform for developing
and running distributed java applications.
HTTP - Hyper Text Transfer Protocol.
TCP/IP - Transmission Control Protocol/Internet Protocol is the communication protocol
used to connect hosts on the Internet.

61. 9.2 ACRONOYMS & ABBREVATIONS
HLD : High Level Design
OOA : Object-Oriented Analysis
OOD : Object-Oriented Design
RAD : Requirements Analysis Design
SDD : System Design Document
SRS : Software Requirements Specification
TP : Test Plan
UML : Unified Modelling Language
URD : User Requirements Document

62. 9.2 BIBLIOGRAPHY
 Software Engineering
A practitioner’s Approach
Sixth Edition
- Roger S. Pressman
 The Unified Modelling Language User Guide
The ultimate tutorial to the UML from the original designers
- Grady Booch
James Rumbaugh
Ivar Jacobson
 Object –Oriented Software Engineering
Using UML Pattern and Java
Second Edition
Bernd Bruegge
Allen H. Dutoit
 www.rspa.com/spi
 www.software-engin.com
- For Software Engineering
 www.springerlink.com
- For Object-Oriented Software Engineering
 www.ibm.com/software/rational/
 www.osalt.com/rational-rose
 www.brothersoft.com/downloads/rational-rose.html
- For Rational Rose

63. -
FOR OOSE SOFTWARES
 www.rspa.com/spi/
 www.software-engin.com
 www.springerlink.com
 www.ibm.com/software/rational
 www.osalt.com/rational-rose
 https://www.techopedia.com/definition/1200/entity-relationship-diagram-erd
CHAPTER-10
REFERENCES

65. 10. REFERENCES
1. IEEE Software Requirement Specification format
2. https://www.slideshare.net/meghasahu14/passport-automation-system-82657707
3.http://www.sourcecodesolutions.in/2011/04/uml-diagrams-passport-automationsystem.html
4. https://www.vidyarthiplus.com/vp/attachment.php?aid=24303