Send money module  Receive money module  Withdraw module  Balance enquiry 2.7 Specific Problem Analysis The specific problem analysis was done to understand the existing system and to identify the problems in the current system. The analysis was done by observing the existing system, interacting with the users and taking their feedback. The key problems identified were: - Lack of mobility - Dependency on computer systems - Network connectivity issues - Resource problems like electricity - High transaction costs - Delay in transaction processing - Lack of security and privacy - Limited coverage and reach To address these problems, the following goals were defined for the new proposed system: 

1. 1 | P a g e
Table of Contents
INTRODUCTION.......................................................................................................................................1
1.1 Introduction to Internship........................................................................................................2
1.2 Background..............................................................................................................................3
1.3 Objectives of project ................................................................................................................4
1.4 Introduction to industry ...........................................................................................................4
1.5 Introduction to Organization....................................................................................................5
1.5.1 Goals of the Organization .................................................................................................5
1.5.2 Organizational Structure Hierarchy...................................................................................6
1.5.3 Decision Making Process ..................................................................................................7
2 ANALYSIS OF ACTIVITIES DONE ........................................................................................................9
2.1 METHODOLOGY OF STUDY.....................................................................................................10
2.2 Organization Selection ...........................................................................................................10
2.3 Placement/Activities ..............................................................................................................11
2.4 Duration.................................................................................................................................11
2.5 Work Schedule.......................................................................................................................12
2.6 Work Division.........................................................................................................................13
2.7 Specific Problem Analysis.......................................................................................................13
2.7.1 Understanding the existing system.................................................................................14
2.7.2 Development of project Goals ........................................................................................15
2.8 Development Strategies.........................................................................................................15
2.8.1 Alternative solutions ......................................................................................................15
2.8.2 Evaluate Feasibility.........................................................................................................16
2.9 Environment Analysis.............................................................................................................17
2.10 Testing and Implementing Strategies .....................................................................................19
2.10.1 Testing ...........................................................................................................................19
3 Requirement Specification and Analysis.........................................................................................21
3.1 Introduction...........................................................................................................................22
3.1.1 Rationale........................................................................................................................22
3.1.2 Current System Architecture ..........................................................................................22
Avishek Bansal
Avisek

2. 2 | P a g e
3.2 Data Requirements ................................................................................................................23
3.3 Functional Requirement.........................................................................................................25
3.3.1 Use Case Diagram...........................................................................................................25
3.3.2 Sequence Diagram..........................................................................................................29
3.4 System Requirement..............................................................................................................34
3.5 Interface Requirement [R13]..................................................................................................35
3.6 Non Functional Requirement .................................................................................................35
3.7 Behavioral Requirement.........................................................................................................36
3.7.1 System States.................................................................................................................36
3.7.2 Events and Actions .........................................................................................................36
3.8 Testing Requirement..............................................................................................................37
3.9 System Architecture...............................................................................................................37
4 System Design ...............................................................................................................................39
4.1 High Level Diagram ................................................................................................................40
4.2 Low Level Design (Data Flow Diagram)...................................................................................41
4.3 Design Constraints .................................................................................................................51
4.4 Data Design............................................................................................................................53
4.4.1 Schema Diagram.............................................................................................................53
4.4.2 Data Dictionary...............................................................................................................54
4.5 Functional Design...................................................................................................................56
4.6 Interface Design.....................................................................................................................61
4.7 Class Diagram.........................................................................................................................63
4.8 System Architecture...............................................................................................................66
4.9 Traceability Matrix .................................................................................................................67
5 Implementation Strategy...............................................................................................................68
5.1 Introduction...........................................................................................................................69
5.2 Platform Selection..................................................................................................................69
5.3 Configuration Management ...................................................................................................70
5.4 Hardware Requirement..........................................................................................................70
5.5 Software Requirement...........................................................................................................71
5.6 Network Requirement............................................................................................................71
6 Test Document ..............................................................................................................................72

3. 3 | P a g e
6.1 Overview of testing................................................................................................................73
6.2 Test Plans...............................................................................................................................73
6.3 Test Strategies .......................................................................................................................74
6.3.1 Unit Testing....................................................................................................................74
6.3.2 Integration Testing .........................................................................................................74
6.3.3 System Testing ...............................................................................................................74
6.3.4 Acceptance Testing.........................................................................................................74
6.4 Test Cases ..............................................................................................................................75
7 Conclusion.....................................................................................................................................77
7.1 Conclusion .............................................................................................................................78
7.2 Lesson Learnt.........................................................................................................................79
7.3 Recommendation...................................................................................................................79
8 SNAPSHOTS ...................................................................................................................................81
9 References and Bibliography..........................................................................................................94

4. 1 | P a g e
Chapter 1
INTRODUCTION
1.1.Introduction to Internship
1.2.Background
1.3.Objective of the Project
1.4.Introduction to Industry
1.5.Introduction to Organization
1.5.1. Objectives/Goals
1.5.2. Organizational Hierarchy
1.5.3. Decision making process

5. 2 | P a g e
1.1 Introduction to Internship
The Bachelors of Information Management (BIM) is a professional course which includes
management education with recent developments in information system. The BIM program
will allow students to expand skills in information technology, and at the same time add to
their executive competence by making them able to be aware of the specialized work done
by the IT professionals.
With the completion of the BIM program, the students will be exposed to wide variety and
choices of employment opportunities and further degrees. BIM program provides the
students with manifold future prospects for advance studies and rewarding employment.
In addition, BIM graduates can find jobs in almost every field. The diversity of
opportunities that exist for them include Software Engineers, Programmers/Analysts,
System Designers, Network Managers, Database Managers and many others. On the other
hand, the graduates aspiring for advanced education have significant advantages. For years
of study of the comprehensive syllabus helps them to get straight entry into the Master
Degree Program in any of the recognized universities worldwide.
The internship is assigned six credit hours for evaluation. The Internship project is good
for students to understand the real world implications building up on the foundation laid
upon by the knowledge gained in college. The knowledge gained in the college serves as a
base and the internship organizations familiarize students with the additional knowledge
required by the professional standards. The internship in specialized field provides us in-
depth understanding about the field, market exposure, and help to identify the potential
career opportunities. The primary objective of the internship is to provide us with the
opportunity for learning as well as developing our managerial skills to tackle the real
world problems arising in the organization.
The internship has given us the real world exposure to the professional life and
shown us the wider exploration of the career opportunities in management, information
technology and information management.

6. 3 | P a g e
1.2 Background
This is the extended version of remittance. A traditional remittance system assists in
sending and payment of transaction from country to country through the computer that is
connected on network. But there was mainly a resource problem resides on it.
Some problems are:
 Have to provide resources (i.e. a computer) to Agent.
 Load shedding problem in Nepal.
 Backup of electricity supply.
The main objective of the Mobile Remittance is to help customer to provide service
of remittance worldwide via internet connection through mobile which should be JAVA
enabled. This system benefits many banks and financial institution for providing a service
of remittance. A particular bank can easily adopt this system by providing this system to its
agents to provide services to its customer in rapid manner.
A mobile remittance is a system that helps banks and financial institution for
exchanging of money from one country to another with the help of mobile device. Country
like ours can take advantages with this system when there was a problem of load shedding.
In this version of the system, bank agent use this system by filling form in the mobile as
prescribed on the information contain in the physical form filled by certain customer (i.e.
money sender) when he comes at that point. Then the control number is generated and
given to this sender. Sender phone to the intended receiver and give him control number.
After that receiver goes to the certain financial institution or bank who uses this system.
Then he gives that control number to the agent and gets his payment or cash.
Due to these problems that were found in current system the new system has been
developed to overcome the problem.

7. 4 | P a g e
1.3 Objectives of project
Considering the problems stated in background, the internship project is aimed to:
DEVELOPED A REMITTANCE APPLICATION FOR MOBILE PLATFORM
The objective could be more precisely listed as follows:
 For partial fulfillment of Internship Project as per final year requirement assigned
by the university
 To analyze the current remittance system and to propose mobile remittance system.
 To design the system as per the client’s requirements along with complete
documentation.
 To gain an experience of solving the real world problems in the real world
environment.
1.4 Introduction to industry
The use of mobile phones today in Nepal as well as in other developing countries lends
itself as a formidable medium to bring formal financial services to all, right at their door
steps. With a push of a few buttons, users can not only deposit, withdraw and transfer
cash from their mobile phones, but also use the stored cash value to make purchases at
shops and stores. The mobile banking system requires a good ecosystem of agents and
merchants in order to effectively serve the customer base. This method of banking is truly
disruptive as it will bring down the barriers and cost of banking to everybody in Nepal.
The biggest advantage Mobile Banking provides to the banks is that it helps to cut down the
costs as it's even more economic than providing tele-banking facilities where banks have to
keep hundreds of tele-callers. Additionally, Mobile Banking helps banks to upgrade the
quality of services and nature of customer relationship management. Using Mobile
Banking, banks can communicate to the defined cluster of clients. Through this
revolutionary service, the bank plans to deliver financial services in a new and innovative
way to all Nepalese, including those that do not have access to banking services, in a fast,

8. 5 | P a g e
secure and low cost manner. The bank stresses that one does not have to have a bank
account at all to use this service.
The first of its kind in Nepal, this service pioneers the “mobile wallet” concept, which
allows users to store cash balances in their mobile phones. Users are then able to deposit
and withdraw cash from their mobile phones, and use the stored cash value to remit to
anyone, anytime, anywhere, with the push of a few buttons. At present, this service is
available through all of Kumari Bank’s 28 branches and their growing number of
authorized agent locations nationwide.
1.5 Introduction to Organization
Swift Technology Private Limited is a national full service, full life-cycle management and
information technology consulting firm. It provides ICT strategy, applications, network and
infrastructure solutions and enterprise resource planning (ERP) across medium to large
size institutions and banks. It offers a wide range of custom ICT programming services. It
has an outstanding experience in custom database development, desktop and distributed
application design as well as various custom software components and web-project
programming. It delivers on-time, on-budget results. Working together every step of the
way, the project is organized and scheduled by expert managers and delivered by trained
professional.
1.5.1 Goals of the Organization
 To expand their workforces in all divisions.
 To deliver cost effective and high-quality software solutions for a wide range of
industries and domains
 To get the projects done on time and within budget.
 To ensure its customers that they receive reliable and friendly support at any
time of day or night.

9. 6 | P a g e
CEO
Technical
Department
Project
Development
Project Manager
Senior Officer
Junior Officer
System
Administration
Senior Officer
Junior Officer
Administration
Department
Account/Finance
Department
Officer
HR Department
Officer
1.5.2 Organizational Structure Hierarchy
Figure 1: Organizational hierarchy

10. 7 | P a g e
Strategic Decision
Making
Tactical Decision
Making
Operational
Decision Making
1.5.3 Decision Making Process
The hierarchy of decision making process in the organization is depicted in the diagram
below:
Figure 2: Decision making chart
The level of managerial decisions making that is supported by information technology in
the STPL are as follows
 Strategic Management: Typically, a board of directors and an executive
committee of the CEO and top executives develop overall organizational
goals, strategies, policies and objectives as part of a strategic planning
process. They also monitor the strategic performance of the organization and
its overall direction on the political, economic, and competitive business
environment.
 Tactical Management: Increasingly, business professionals in self directed
teams as well as business unit managers develop short and medium range
plans, schedules, budget and specify the policies, procedures, and business

11. 8 | P a g e
objective for their subunits of the company. They also allocate resources and
monitor the performance of their organizational subunits, including
departments, divisions, process teams, project teams and other workgroups.
 Operational Management: The members of the self-directed teams or
operating managers develop short range plans. They direct the use of
resources and the performance of tasks according to procedures and within
budgets and schedules they establish for the teams and other workgroups of
the organization.

12. 9 | P a g e
Chapter 2
2 ANALYSIS OF ACTIVITIES DONE
2. Analysis of activities done.
2.1.Methodology of the Study
2.2.Organization Selection
2.3.Placement/Activities
2.4.Duration
2.5.Work Schedule
2.6.Work Division
2.7.Specific Problem Analysis
2.7.1. Understanding the existing system
2.7.2. Development of Project Goals
2.8.Development Strategies
2.8.1. Alternative Solution
2.8.2. Evaluate Feasibility
2.9. Environment Analysis
2.10. Testing and Implementing Strategies
2.10.1. Testing
2.10.2. Implementation

13. 10 | P a g e
Initial Requirement
Gathering
Feasibility Study
Requirement Analysis
and Specification
System Design
System
Implementation
System Maintenance
2.1 METHODOLOGY OF STUDY
During my nearly three months of internship project, I was supposed to develop
application for remittance. The application for IME Financial Institute had to be completely
web based system. After completion of the requirement analysis and feasibility study I
prepared a system design using DFD, Schema Diagram, Event Flow diagrams and flow
charts. I was totally responsible for the coding part. In case of some errors or problems
regarding the project I was guided by my supervisors Er. Suraj Chettry.
Figure 3: Software Development Cycle (SDC)
2.2 Organization Selection
Selection of better organization is one of the important parts of industrial attachment
project. The better organization gives better exposure to the real work environment. The
priority was the selection of an organization that has sufficient resources and well
established. It was Swift Technology Pvt. Ltd., an IT company that develops software for
national and international companies, which provided me new experience besides my
studies.

14. 11 | P a g e
2.3 Placement/Activities
I was as an internee in Swift Technology. The duration of internship was about 11 weeks. In
my internship period, I learned many things about core java, java2 micro edition, and web
based system along with database.
I was involved in several activities in the organization like coding, analyzing, evaluating,
observing etc. for the real world exposure. I was given a task of developing online mobile
Remittance for the organization. I worked under the supervision of Mr. Suraj Chettey,
Senior Project Manager. To become familiar to the organization I asked several questions
and he gave all the necessary information. The first two weeks, I observed many of the
mobile remittance systems which really helped me to do my analysis. After one month of
analysis and design I started coding for the system and completed the given task in
allocated time, knowledge gained in the BIM helped me to manage time and task in my
internship period.
2.4 Duration
Table 1: Internship Duration
Start date 8th April, 2012
End date 13th July, 2012
Total duration 3 months and more
Position Mobile apps developer
Supervisor Er. Suraj Chettry and Er.
Binay Rai
Office hour 11:00 am – 5:00 pm

15. 12 | P a g e
2.5 Work Schedule
The software process model that we followed was Waterfall model as all the requirements
were collected at the very beginning of the project with which we initiated our work. The
work schedule and the various procedures undergone during the two months of internship
are depicted through the Gantt chart as shown below. Gantt chart shows the time period of
the various activities performed during internship. The work procedure is guided by the
software development cycle. The activities performed as per the life cycle starting from the
initial investigation to the documentation of the final project. In order to perform the
allotted task on time, 11 weeks was divided as:
1st and 2nd week: System Analysis.
3rd and 4th week: Designing
5th, 6th, 7th and 8thweek: Coding and debugging
9th, 10th and 11th week: Testing and Implementation
Figure 4: Gantt chart

16. 13 | P a g e
2.6 Work Division
Mobile Remittance is an output of team-effort. It is developed by team of two people, me
and my intern colleague. Although we collaborated on the same project, the tasks have
been divided into three major divisions. The task division for each of the developer has
been divided as follows:
Assignee Module
Avishek Bansal
 Send money module
 Top up module
 Cancel request module
Prabin Lal Shrestha
 Payout module
 Electronic recharge card module
Bijay Shahi (Sr. Programmer)
 Integration of system with core banking
system.
 ERP of the system.
Table 2: Work Division
2.7 Specific Problem Analysis
There was lots of problem that were analyzed while developing Core Mobile Remittance
with Top up. The major problem was to understand the existing remittance procedure and
then match it exactly to the current system being developed. The next big challenge was to

17. 14 | P a g e
maintain the confidentiality and reliability of banking transaction. The banking
transactions needs to be complete and accurate and the small bugs would have made the
whole system failure. There was a lot of risk involved. The security and security was our
concern. The existing system was studied on detail with reference to the Software
Requirement Specification, Detail Design Documentation and with the several
communications and the queries to the developer, tester and the project manager.
The first two week of the internship was scheduled for the initial investigation of the
project. To have an overview of how the system needs to be build, our team analyzed the
requirements of the different companies and the users. There were lots of brainstorming
during this period.
With the help of all the requirements we build Use Case Diagram. Further we
analyzed the important users that are going to use the system. We categorized them as
Bank’s Administrator who will look after the overall system’s activities, and finally an agent
who is responsible for performing transaction. Then these categories were equally divided
into tasks for me and my friend.
2.7.1 Understanding the existing system
The main goal of our project was to develop the existing system in Mobile Platform. The
detail study of the existing system was done. Hence, it is very important to understand and
analyze the existing system carefully.
Observation, Questionnaire, and detail research was the main way to under the existing
system. Various related documents were studied to understand the existing system from
core. It helped to understand the system in more detail and provided an aid to find the
solution to the existing problems. It was an efficient move to understand the user
requirement and its respective mapping with the system. It was the basic step for the
problem definition and the analysis was done very promptly and efficiently.

18. 15 | P a g e
2.7.2 Development of project Goals
After Analyzing and understanding the existing system the detail overview of existing
system was conceptualized. The areas where the system needs to be improved were
known. After understanding the existing system, instead of these deficiencies were
eventually developed as further project goals that were to be achieved. We also figured out
that the clients had the changing requirements as per the changing time so; various
modifications and development were required. One of the biggest challenges was the
creation, updating, integration and management of the system along with core banking
logic. However, the main goal is to make the system a dynamic one so that it changes or
customizes itself frequently and automatically, based on certain criteria. Understanding the
existing system led to the identification of various problems which must be set as a goal of
the project to be solved.
2.8 Development Strategies
After the requirement was analyzed and designed of the system was done the main and the
most challenging task was started that is development of the system. The development of
the system is never easy because the technical scope of the system can only be known in
development phase. The development phase of the system has unpredictable time because
of the bugs and error that occur while developing the system. Therefore a detail strategy
for developing of the system was made with the guidelines of senior level manager.
2.8.1 Alternative solutions
A system may be developed in many ways. The selection of the best alternatives
determines the degree of the success in developing the new proposed system according to
the customer’s requirement and criteria. Many alternatives were identified by discussion
on the system. In order to achieve this, extensive research has to be carried out. Hence, at

19. 16 | P a g e
last the best and optimal alternative of the solution should be achieve considering all the
aspects of the system.
2.8.2 Evaluate Feasibility
Development of the proposed system first requires a system study procedure for feasibility
analysis. This feasibility study helps to determine whether the project is sufficiently
feasible enough to be carried out. It answers whether the proposed system is worth
developing. We have to find out if the developed system would sufficiently pay-off in the
end. Hence, evaluation of feasibility or the feasibility analysis helps us to know the worth of
the new system to be developed.
 Technological Feasibility
The technological feasibility of the system was analyzed in order to observe
whether the system is suitable to develop or not. The available technology
can meet the requirement or not.
 Economical Feasibility:
Economic feasibility includes the analysis of cost and benefit from the
system. This tool helps to determine the benefits that can be obtained from
the system by comparing them with the various costs. If the benefits are
higher than the cost then the system is considered to be economically
feasible to be developed. Else we can easily understand that the system is not
economically feasible and certain things are to be worked out and modified
in order to acquire the desired economical feasibility.
 Operational Feasibility:
Operational feasibility is a measure of how well a proposed system solves the
problems, and takes advantage of the opportunities identified during scope
definition and how it satisfies the requirements identified in the
requirements analysis phase of system development.

20. 17 | P a g e
 Schedule feasibility:
A project will fail if it takes too long to be completed before it is useful.
Typically this means estimating how long the system will take to develop,
and if it can be completed in a given time period using some methods like
payback period. Schedule feasibility is a measure of how reasonable the
project timetable is. Given our technical expertise, are the project deadlines
reasonable? Some projects are initiated with specific deadlines. You need to
determine whether the deadlines are mandatory or desirable.
 Resource Feasibility:
This involves questions such as how much time is available to build the new
system, when it can be built, whether it interferes with normal business
operations, type and amount of resources required, dependencies.
2.9 Environment Analysis
The working environment of the organization was very good. The company focused on the
team work. Discussions and meetings were held on a regular basis where the expert senior
personnel used to be present. Daily performance in the tasks undertaken were also
analyzed and consulted with the expert help and various suggestions and guidelines were
provided. The SWOT analysis of the organization is analyzed and presented below:
Strength:
 The company has huge experience in Core banking system
 Integration of core banking with interface system is efficient.
 The amount of experience in Business Logic is huge.
 Affiliation to many banks
 Customer feedback and service is efficient.

21. 18 | P a g e
 Provides wide varieties of IT services
 Motivated and competent working environment
 Good public relationship management
Weakness:
 Currently have a small customer base with few customers with time to analyze their data.
 Less Number of employees.
 Small working space
 Employee turnover
Opportunities:
 Capable of taking product globally.
 Can expand their market to other corporate houses.
 Expansion in terms of employees can be done.
 Various other banks projects are on hand.
Threats:
 Competition with the other similar firms
 Political Instability
 Economic problem of the country
 Economic recession in the outsourced countries
 Unconvincing IT policies in Nepal

22. 19 | P a g e
2.10 Testing and Implementing Strategies
2.10.1 Testing
 Unit testing
For Unit testing Black box testing has been implemented in order to examine and
test the system.
 Acceptance testing
The bank itself has tested the system by using the system.
2.10.2 Implementation
 Tools Used
 Net Beans
Net Beans is an integrated development environment (IDE) from Oracle. It is used to
develop console and graphical user interface applications of many programming
Languages along with java. The j2me platform is used to develop this project. It
consists inbuilt j2me libraries and API to developed a mobile based project
 Java Development Kit
The Java Development Kit (JDK) is an Oracle Corporation product aimed at Java
developers. It is the Software development tool kit for Java developers. It consists of
java, jaavc, applet viewer, apt, jar.
The JDK also comes with a complete Java Runtime Environment, usually called a
private runtime

23. 20 | P a g e
 Rest Client
REST Client is a Java application to test Restful web services. It can be used to test
variety of HTTP communications
 SVN (Server side: Tortoise SVN and Client Side: Ankh SVN)
SVN is a program which keeps track of all the different versions of our source files.
Tortoise SVN is a Subversion client, implemented as a Microsoft Windows shell
extension. It is free software released under the GNU General Public License.
 JSON Extensions
JSON extensions are the format used to transfer the data from client to server and
vice versa. The JSON extension tool is used in this project to format the data in Http
Connection.

24. 21 | P a g e
Chapter 3
3 Requirement Specification and Analysis
3. Requirement Analysis and Specification
3.1.Introduction
3.1.1. Rationale
3.1.2. Current System Architecture
3.2.Data Requirement
3.3.Functional Requirement
3.3.1. Requirement Specification
3.3.2. Use Case Diagram
3.3.3. Interaction Diagram
3.4.System Requirement
3.5.Interface Requirement
3.6.Non Functional Requirement
3.7.Behavioral Requirement
3.7.1. System States
3.7.2. Events and Actions
3.8.Testing Requirement
3.9.System Architecture.

25. 22 | P a g e
3.1 Introduction
3.1.1 Rationale
This document aims to provide the detail overview of System Requirement Specification
which was provided directly by the client and collected by some research works. The SRS
document should be thoroughly analyzed before developing a system. The software
requirement specification document enlists all necessary requirements for project development.
3.1.2 Current System Architecture
Agent
Computer based
Remittance System
$
Bank
Transaction
Figure 5: Current system Architecture
A traditional remittance system assists in sending and payment of transaction from country
to country through the computer that is connected on network. But there was mainly a
resource problem resides on it.
Some problems are:
 Have to provide resources (i.e. a computer) to Agent.
 Load shedding problem in Nepal.
 Backup of electricity supply.

26. 23 | P a g e
3.2 Data Requirements
Entity Relation Diagram
It is an abstract and conceptual representation of data. We can express the overall logical
structure of the database graphically with an ER diagram. E-R Diagram consists of the
following components:
Rectangles Represent entity sets
Ellipses Represent attributes.
Underline Ellipses Represent Primary Key
Diamonds Represent relationship sets.
Lines Link attributes to entity sets, entity sets to relationship sets.
Entities Attributes
Credentials User_id, name, street, city, country, phone_no
Agent User_id, agentCode, Username, password, a/c_no
AgentAccount a/c_no, balance, acc_type
Remittance txn_id, txn_type, payment_amt, service_amt, delivery_method, payout
loc, user_id
Remittance_token txn_id, control_no
topUp t_id, amount, mobile, user_id
Table 3: Entities with their description

27. 24 | P a g e
Figure 6: E-R Diagram [R1]
In figure 5, the rectangular boxes show the entities and the diamonds show the
relationships between the entities. The agent does the remittance as well as top up. The
credentials of agent is also recorded in credentials table. The remittance generates the
control number and each transaction has its own control number. The remittance then is
also associated with the account as the remaining balance of the account if affected by each
transaction. There is a one to many relationships between agent and remittance or top up
because one agent can do many transactions.

28. 25 | P a g e
3.3 Functional Requirement
3.3.1 Use Case Diagram
A use case diagram is a type of behavioral diagram defined by the Unified Modeling
Language (UML) whose aim is to present a graphical overview of the functionality provided
by a system on terms of actors, their goals (represented as use cases), and many
dependencies between those use cases.
Figure 7: Use Case Diagram [R2]

29. 26 | P a g e
In the above figure 7 it is shown that there are only two categories of actors which are
agent and customer. The agent is the person who controls the Remittance system and the
customer is the persons who sends and receive money from one place to another
Therefore the overall requirement of the system classified by actors and roles are
 Login Module
 Send Transaction Module
 Payout Module.
 Cancel Transaction Module.
 Change Password Module.
 Top Up Module
Description of Use Case
Login Module [R3]
Description This module should authenticate the agent login. The data is sent to
web server for authentication.
Input Username of Agent, Password of Agent, User ID of Agent and Agent
Code.
Output The Reply that shows the Login failure or successful message to
Agent.
Pre-Condition The application is installed and opened.
Post-Condition The Agent is redirected to home page
Alternative Course Can cancel the login process and exit.
Table 4: Description of Login Module Requirement

30. 27 | P a g e
Send Transaction Module [R4]
Description This module will allow user to send money from one place to
another. The Agent will have to send the transaction in order to
initiate the remittance process.
Input Information of Sender such as name, phone number, Id type.
Information of Receiver such as name, phone number, Id type.
Information regarding amount, fee charges, delivery method.
Output Control Number i.e Token number to sender.
Pre-Condition The Agent login should be authenticated.
The Client side verification should be done.
Post-Condition Displays end of Send Transaction Module
Alternative Course Can cancel the entry process and exit.
Table 5: Description of Send Transaction Module Requirement
Payout Module [R5]
Description This module will allow user to receive money from one place to
another. The Agent will have to entry the information in order to get
payment details and do the payment to receiver.
Input Information of Receiver such as name, phone number, Id type.
Control Number for that Transaction.
Output Payment details for the transaction such as Amount, Charges etc.
Pre-Condition The Agent login should be authenticated.
The Client side verification should be done.
Post-Condition Displays end of Payout Module.
Alternative Course Can cancel the entry process and exit.
Table 6: Description of Payout Module Requirement

31. 28 | P a g e
Cancel Transaction Module [R6]
Description This module will allow agent to cancel the transaction requested. The
Agent will have to entry the control number in order to cancel the
particular transaction.
Input Control Number for that Transaction which is to be cancelled.
Output Reply from the system regarding success or failure.
Pre-Condition The Agent login should be authenticated.
The Send Transaction should have been done.
Post-Condition Displays end of Cancel Transaction Module.
Alternative Course Can cancel the entry process and exit.
Table 7: Description of Cancel Transaction Module Requirement
Change Password Module [R7]
Description This module will allow the agent to change the password of login.
The agent can change the password for security purpose.
Input Username of Agent, Password of Agent, User ID of Agent , Agent Code
and New Password.
Output Reply from the system regarding success or failure.
Pre-Condition The Agent login should be authenticated.
Post-Condition The Agent is redirected to login page.
Alternative Course Can cancel the change password process and exit.
Table 8: Description of Change Password Module Requirement

32. 29 | P a g e
Top Up Module [R8]
Description This module will allow agent to transfer the mobile balance to a
mobile user. The Agent will have to send the login in order to initiate
the top up process.
Input Transfer amount, Destination Mobile number.
Output Reply from the system regarding success or failure.
Pre-Condition The Agent login should be authenticated.
The Client side verification should be done.
Post-Condition Displays end of Top-up Module
Alternative Course Can cancel the process and exit.
Table 9: Description of Top up Module Requirement
3.3.2 Sequence Diagram
A sequence diagram (also called interaction diagram) is a UML construct of a Message
Sequence Chart. It shows how processes operate one with another and in what order.
Sequence diagram describe interactions among classes on terms of an exchange if
messages over time. It shows a detailed flow for a specific use case or even just part of a
specific use case.
They are almost self explanatory; they show the calls between the different objects in their
sequences and can show, at a detailed level, different alls to different objects. It is an
interaction diagram that details how operations are carried out, what messages are sent
and when. Sequence diagrams are organized according to time. A sequence diagram shows,
as parallel vertical lines, different processes or objects that live simultaneously, i.e. shows
the object instances to which the messages are sent. And, as horizontal arrows, the
messages exchanged between them, in the order in which they occur i.e. shows the
sequence of messages/calls in the time order that they occurs. This allows the specification
of simple runtime scenarios in a graphical manner.

33. 30 | P a g e
Figure 8: Interaction diagram to Send Money [R9]
In the figure 8 the interaction between agent, system and database while sending the
transaction is shown. At first the agent should login to the system input is verified in the
system by accessing the database. Then the feedback is sent to agent. After that the agent
interacts to the system by entering the transaction details and after the details are verified
the data is entered into database and control number is given as a response to agent
generated by database.

34. 31 | P a g e
Figure 9: Interaction diagram to Payout Transaction [R10]
Figure 9 shows sequence diagram of payout transaction. The agent logins to the system the
login is authenticated and agent enters the control number and receiver identity to the
system which is mapped with database record and if the control number is found the
transaction details is send.

35. 32 | P a g e
Figure 10: Interaction diagram to cancel transaction [R11]
In the figure 10 the interaction between agent, system and database while cancelling the
transaction is shown. At first the agent should login to the system input is verified in the
system by accessing the database. Then the feedback is sent to agent. Then the agent
interacts to the system by entering the control number of the transaction and after the
control number is verified the transactions are cancelled.

36. 33 | P a g e
Figure 11: Interaction diagram to Top up [R12]
In the figure 11 the interaction diagram between agent, system and database while Topup
transaction is shown. At first the agent should login to the system input is verified in the
system by accessing the database. Then the feedback is sent to agent. Then the agent
interacts to the system by entering the amount and mobile number for top up transaction
and after the data is verified the transactions are completed.

37. 34 | P a g e
3.4 System Requirement
The functions that will be carried out by the system for the user are as follows:
 Agent Login
The agent must login to the system and the system must authenticate the login
by making response to database. The warning should be given for unauthorized
login to system.
 Verify Sender Information at client side
The system should verify the sender information at client side. The information
verification includes Blank field check, Number format check.
 Manage Control Number
The unique control number should be generated and should be provided to
customer.
 Payout Transaction
The payment should be made by another agent by verifying the control number.
 Cancel Transaction
The agent should be able to cancel the transaction by cancelling the control
number.
 Top up
The Top Up is used so that the customer can transfer the amount to another
user.
 Change password for Agent
The agent should be able to change the password.

38. 35 | P a g e
3.5 Interface Requirement [R13]
For the efficient use of the system, the users must be provided with the following features:
 Data entry components:
The users must be provided with a text boxes and text areas where they can
enter the required data and a button which saves the data.
 Data Selection components:
The system must provide the data selection feature so as to let the users select
the most acceptable data. Data selection can be done by using various dropdown
lists, checkboxes and radio buttons, date selection tools, etc.
 Data reporting components:
Tables are used to generate various types of reports.
 Security Components:
A Secure Payment system is provided to the customers and agent.
3.6 Non Functional Requirement
 Compatibility
The system should be compatible with every java enabled mobile. There may be
mobile with different size, memory and processing system and there should be
system for all such platform. The basic non function requirement was to make
system for java as well as android based mobile.

39. 36 | P a g e
 Response Time
The response time of the system was also one of the factors. The delivery of the
system has to be made within 15 weeks.
 Maintainability
The system developed system should be maintained whenever any issue arises.
 Modifiability
The technology is now rapidly changing therefore if required the modification in
the system should be available. Therefore the system should be flexible.
 Documentation
The detail guidelines to the system should be done maintained in and user
manual should be created.
3.7 Behavioral Requirement
3.7.1 System States
 Normal state: System accepts all the inputs and provides the outputs.
 Stand by state: System is waiting for the user to enter the list of inputs to
provide the output.
 Pending state: System is in pending state when the system has accepted the
inputs but it is yet to display the output.
3.7.2 Events and Actions
 If the data format is not matching then at the error message is generated.
 While inserting into database if all the fields are not filled then the error message
is generated and the previous filled form is shown with empty spaces.

40. 37 | P a g e
 While updating the validation should be done.
 There will be expiry of session if it’s not used for certain interval of times.
 If certain processes are carried by user without specific permissions, error
message is generated.
3.8 Testing Requirement
Various test cases will be generated for the purpose of testing the software. With the help
of these test cases the functionality of the system can be validated and verified as well.
Hence for such testing purpose integration testing and system testing is selected.
The integration testing will be done by us, the developers. For system testing, acceptance
testing is selected and hence our user is given the product for the acceptance testing.
3.9 System Architecture
Figure 12: New System Architecture

41. 38 | P a g e
This is the extended version of remittance. A traditional remittance system assists in
sending and payment of transaction from country to country through the computer that is
connected on network. But there was mainly a resource problem resides on it.
Some problems are:
 Have to provide resources (i.e. a computer) to Agent.
 Load shedding problem in Nepal.
 Backup of electricity supply.
The main objective of the Mobile Remittance is to help customer to provide service of
remittance worldwide via internet connection through mobile which should be JAVA
enabled. This system benefits many banks and financial institution for providing a service
of remittance. A particular bank can easily adopt this system by providing this system to its
agents to provide services to its customer in rapid manner.
A mobile remittance is a system that helps banks and financial institution for exchanging of
money from one country to another with the help of mobile device. Country like ours can
take advantages with this system when there was a problem of load shedding. In this
version of the system, bank agent use this system by filling form in the mobile as
prescribed on the information contain in the physical form filled by certain customer (i.e.
money sender) when he comes at that point. Then the control number is generated and
given to this sender. Sender phone to the intended receiver and give him control number.
After that receiver goes to the certain financial institution or bank who uses this system.
Then he gives that control number to the agent and gets his payment or cash.

42. 39 | P a g e
Chapter 4
4 System Design
4. System Design
4.1. High Level Design
4.2. Low Level Design
4.3. Design Constraints
4.4. Data Design
4.4.1. Schema Diagram
4.4.2. Data Dictionary
4.5. Functional Design
4.6. Interface Design
4.7. Class Diagram
4.8. System Architecture
4.9. Traceability Matrix

43. 40 | P a g e
The design of the system was developed keeping in mind the MVC Model. Design covered
all the requirements given by IME Finance Limited and tried to integrate the different
requirements of the Company into one system
4.1 High Level Diagram
High level software design, also called software architecture is the first step to analyze and
consider all requirements for a software and attempt to define a structure which is able to
fulfill them. For this also the non-functional requirements have to be considered, such as
scalability, portability and maintainability
Figure 13: High level Design [D1]

44. 41 | P a g e
4.2 Low Level Design (Data Flow Diagram)
A data flow diagram looks at how data flows through a system. It concerns things like
where the data will come from and go to as well as where it will be stored. DFD usually
begins with drawing a context diagram, a simple representation of the whole system. To
elaborate further from that, it is drill down to a level 1 diagram with additional
information about the major functions of the system. This could continue to evolve to
become a level 2 diagram when further analysis is required.
Figure 14: Context Level DFD [D2]

45. 42 | P a g e
Figure 15: Level 1 DFD [D3]

46. 43 | P a g e
Figure 16: Level 2 DFD for Agent Login [D4]
Figure 17: Level 2 DFD for Send Transaction [D5]

47. 44 | P a g e
Figure 18: Level 2 DFD for Payout Transaction [D6]
Figure 19: Level 2 DFD for Cancel Transaction [D7]

48. 45 | P a g e
Figure 20: Level 2 DFD for Top-Up [D8]
Figure 21: Level 2 DFD for Change Password [D9]

49. 46 | P a g e
Program Specifications (PESPEC) for the Data Flow Diagrams (DFD)
PSPEC 1: Agent Login
Input Username and password
Output Admin access
Description This function checks for the validity of the username and the
password. If they are valid then allows the agent to enter the system
Table 10: Agent Login
PSPEC 1.1: Input username and password
Input Username and password
Output Information
Description This function takes the input from the admin.
Table 11: Input user name and password
PSPEC 1.2: Match username and password
Input Information
Output Information
Description This function matches the username and password with the
database and results the respective user access.
Table 12: Match Username and Password
PSPEC 2: Send Transaction
Input Sender/Receiver/Payment data
Output Add to database and generate control number
Description This function allows user to send money. The Agent will have to
send the transaction in order to initiate the remittance process.
Table 13: Send Transaction

50. 47 | P a g e
PSPEC 2.1: Input Sender Information
Input Sender Information
Output Verify and add to database
Description This function takes the sender information..
Table 14: Input Sender Information
PSPEC 2.2: Input Receiver Information
Input Receiver Information
Output Verify and add to database
Description This function takes the receiver information..
Table 15: Input receiver Information
PSPEC 2.3: Input Payment Information
Input Payment Information
Output Verify and add to database
Description This function takes the payment information..
Table 16: Input Sender Information
PSPEC 2.4: Generate Control Number
Input Information
Output Control number
Description This function outputs the control number to agent.
Table 17: Generate Control Number
PSPEC 3: Payout Transaction
Input Control number/Receiver data
Output Add to database and verify the control number and give details
Description This module will allow user to receive money The Agent will have to
entry the information in order to get payment details and do the
payment to receiver.
Table 18: Payout Transaction

51. 48 | P a g e
PSPEC 3.1: Insert Control Number
Input Control number
Output Add to database.
Description This function takes the control number.
Table 19: Insert Control Number
PSPEC 3.2: Insert Receiver Information
Input receiver data
Output Add to database.
Description This function takes the receiver data.
Table 20: Insert Receiver Information
PSPEC 3.3: View payment Details
Input Information
Output Information
Description This function will allow viewing payment information.
Table 21: View payment Details
PSPEC 3.4: Transaction status
Input Information
Output Information
Description This function changes the transaction status to pay.
Table 22: Transaction status
PSPEC 4: Cancel Transaction
Input Control number/reasons
Output Add to database and Transaction status
Description This function will allow agent to cancel the control number and also
must provide reasons for cancellation.
Table 23: Cancel Transaction

52. 49 | P a g e
PSPEC 4.1: Control Number Verification
Input Control number
Output Add to database
Description This function takes the control number
Table 24: Control Number Verification
PSPEC 4.2: Reasons for cancellation
Input Reasons for cancellation
Output Add to database
Description This function takes the reasons
Table 25: Reasons for cancellation
PSPEC 4.3: Transaction status
Input Information
Output Information
Description This function changes the transaction status to cancel.
Table 26: Transaction status
PSPEC 5: Top Up
Input Mobile number/amount
Output Add to database and Transaction status
Description This function will allow agent to transfer amount to a mobile
number.
Table 27: Cancel Transaction
PSPEC 5.1: Insert Phone Number
Input Phone Number for a user
Output Add to database
Description This function takes the phone number to transfer amont.
Table 28: Insert Phone Number

53. 50 | P a g e
PSPEC 5.2: Insert Amount
Input Amount to transfer
Output Add to database
Description This function takes amount in figures.
Table 29: Insert Amount
PSPEC 5.3: Verification
Input Information
Output Information
Description This function verifies amount and mobile number.
Table 30: Verification
PSPEC 5.4: Transaction status
Input Information
Output Information
Description This function gives the Top-Up transaction status.
Table 31: Transaction status
PSPEC 6: Change password
Input Username ,password and new password
Output Information
Description This function checks for the validity of the username and the
password. If they are valid then changes the old password.
Table 32: Agent Login Password Change
PSPEC 6.1: Input username, password and new password
Input Username , password and new password
Output Information
Description This function takes the input from the admin.
Table 33: Input user name and password

54. 51 | P a g e
PSPEC 6.2: Match username and password
Input Information
Output Information
Description This function matches the username and password with the
database and after that changes the old password with new.
Table 31: Match Username and Password
4.3 Design Constraints
Mobile remittance System required the system to be based on the MVC (Model – View –
Controller) model of designing the system. MVC is a classic design pattern often used by
applications that need the ability to maintain multiple views of the same data. The MVC
pattern hinges on a clean separation of objects into one of three categories:
Figure 22: MVC Pattern

55. 52 | P a g e
 Model:
A model in MVC pattern is use to store the data temporarily. It mainly interacts with the
database and stores the data send by controller. A model when interacts with view is
domain specific. Many applications use a persistent storage mechanism (such as a
database) to store data. MVC does not specifically mention the data access layer because it
is understood to be underneath or encapsulated by the Model. In this project each and
every data is under the rules of MVC and stored via model.
 View:
A view is some form of visualization of the state of the model. It renders the model into a
form suitable for interaction, typically a user interface element. Multiple views can exist for
a single model for different purposes. It is used for displaying all or a portion of the data.
 Controller:
It processes and responds to events, typically user actions, and may invoke changes on the
model. It is basically responsible for handling events that affect the model or view(s)
Because of this separation, multiple views and controllers can interface with the same
model. Even new types of views and controllers that never existed before can interface
with a model without forcing a change in the model design. A controller can send
commands to its associated view to change the view's presentation of the model (for
example, by scrolling through a document). It can send commands to the model to update
the model's state (e.g. editing a document).

56. 53 | P a g e
4.4 Data Design
4.4.1 Schema Diagram
Figure 23: Schema Diagram [D10]

57. 54 | P a g e
4.4.2 Data Dictionary
Figure 24: Agent Login
Figure 25: Account
Figure 26: Credentials
Figure 27: Remittance Account

58. 55 | P a g e
Figure 28: Remittance
Figure 29: Remittance Token
Figure 30: Top Up
Figure 31: Top up Account

59. 56 | P a g e
4.5 Functional Design
Figure 32: Flow of the system [D11]

60. 57 | P a g e
Figure 33: Flow of the send Transaction [D12]

61. 58 | P a g e
Figure 34: Flow of the Payout Transaction [D13]

62. 59 | P a g e
Figure 35 Flow of the Cancel Transaction

63. 60 | P a g e
Figure 36 Flow of the Top Up [D14]

64. 61 | P a g e
4.6 Interface Design
The user interface has been designed to be as instinctive and easy to use as possible, with
the least number of steps for an agent to complete the transaction. Since the transaction
will be from mobile the number of interface is kept as minimum as possible.
Figure 37: Interface Diagram 1 [D15]
Figure 37 shows the interface diagram for agent when application is run. Agent has the
choice of login into the system by inserting username and password. The agent has also the
option of log out from the system.

65. 62 | P a g e
Choice
1
Remittance payout
Send
cancel
TopUp
Amount
Mobile
ERC
product
product type
amount
Options
Change
password
Change deials
Figure 38: Interface Diagram 2 [D16]

66. 63 | P a g e
4.7 Class Diagram
Figure 39: Class Diagram of Model
Figure 39 shows the class diagram of all the model class of MVC framework in which
various classes inherits the features of Abstract Model.

67. 64 | P a g e
Figure 40: Class Diagram of view
Figure 40 shows the class diagram of all the view class of MVC framework in which various
classes inherits the features of Abstract view.

68. 65 | P a g e
Figure 41: Class Diagram of controller
Figure 41 shows the class diagram of all the model class of MVC framework in which
various classes inherits the features of Abstract Model.

69. 66 | P a g e
4.8 System Architecture
Cancel transaction
Log in Request
Login Status
TopUp transaction
View Reports
Mobile Remittance
System
0
Send Transaction
Control Number
Payout
Payment details
Transaction status
Top Up status
Log out request
Logout status
Manage schemes
Schemes status
Agent status
Manage agents
Reports response
agent
Bank
Figure 42: System Architecture [D17]

70. 67 | P a g e
4.9 Traceability Matrix
D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12 D13 D14 D15 D16 D17
R1 √ √
R2 √ √ √
R3 √
R4 √
R5 √
R6 √
R7 √
R8 √
R9 √ √
R10 √ √
R11 √
R12 √ √
R13 √ √
Table 34: Traceability matrix

71. 68 | P a g e
Chapter 5
5 Implementation Strategy
5. Implementation Strategy
5.1. Introduction
5.2. Platform Selection
5.3. Configuration Management
5.4. Hardware Requirement
5.5. Software Requirement
5.6. Network Requirement

72. 69 | P a g e
5.1 Introduction
Development phase of Mobile Remittance was crucial. The project began with the analysis
of the requirement and the conceptual pattern was designed. After the overall analysis of
the system, designing of the database, tables and user interface was started. After that the
coding for the system was done along with its testing. After completion of coding and
debugging the system was implemented.
5.2 Platform Selection
To run the system smoothly, proper platform of software and hardware must be selected.
Following are the specification of operating system and other applications for the proper
functioning of the system.
 Net Beans
Net Beans is an integrated development environment (IDE) from Oracle. It is used to
develop console and graphical user interface applications of many programming
Languages along with java. The j2me platform is used to develop this project. It
consists inbuilt j2me libraries and API to developed a mobile based project
 Java Development Kit
The Java Development Kit (JDK) is an Oracle Corporation product aimed at Java
developers. It is the Software development tool kit for Java developers. It consists of
java, jaavc, applet viewer, apt, jar. The JDK also comes with a complete Java Runtime
Environment, usually called a private runtime
 Rest Client
REST Client is a Java application to test Restful web services. It can be used to test
variety of HTTP communications

73. 70 | P a g e
 SVN (Server side: Tortoise SVN and Client Side: Ankh SVN)
SVN is a program which keeps track of all the different versions of our source files.
Tortoise SVN is a Subversion client, implemented as a Microsoft Windows shell
extension. It is free software released under the GNU General Public License.
 JSON Extensions
JSON extensions are the format used to transfer the data from client to server and
vice versa. The JSON extension tool is used in this project to format the data in Http
Connection.
5.3 Configuration Management
The Mobile that run the application must be java enabled mobiles. The minimum
configuration for CLDC is 1.0 and minimum configuration of MIDP is 2.0. The Minimum
memory required to install and run the app is 512 KB.
5.4 Hardware Requirement
 133 MHZ processor in minimum
 1 GB RAM (Minimum) 2 GB RAM (Recommended),
 Hard-disk(10GB or more)
 100 Mbps Network Interface Card, Switch or Hub for Internet
 JAVA enabled mobile device

74. 71 | P a g e
5.5 Software Requirement
 NetBeans
 Microsoft SQL Server
 HTTP service
 Web Browser (RestClient)
 Standard OS(linux) which supports the above requirement.
5.6 Network Requirement
 100 Mbps Network (Recommended)10 Mbps (Minimum)
 Microsoft Windows Server 2003
 GPRS Support
 Wifi enabled devices needed

75. 72 | P a g e
Chapter 6
6 Test Document
6. Test Document
6.1. Overview of Testing
6.2. Test Plan
6.3. Test Strategies
6.3.1. Unit Testing
6.3.2. Integration Testing
6.3.3. System Testing
6.3.4. Acceptance Testing
6.4. Test Cases

76. 73 | P a g e
6.1 Overview of testing
Testing is a process for executing a program with the intent to cause and discover errors.
The goal of testing is:
1. To force a program to work efficiently.
2. To discover the causes of these errors.
3. To revise the program code to eliminate errors.
Testing is a destructive process. However, having discovered conditions under which
program fail, the project team can devise constructive solution to improve software quality.
It is impossible to design a piece of software to meet all contingencies, forcing and
unforeseen, so it is impossible to design test that can causes all the unforeseen processing
problem a program can encounter during its entire useful life. Therefore part of the
challenge of testing design lies establishing practical limits on the amount of testing to be
done and the cost to be borne for the function. Consequently, to make testing as possible,
strategies need to ensure identification of the error most likely to occur. Testing provides a
final measure of quality assurance for software product during the later phase of the
systems development cycle. Testing is a final step in a series of checkpoint applies to assure
the quality of software development.
6.2 Test Plans
Testing is one of the crucial stages in Software Development Life Cycle. Testing is a
mechanism of checking the functioning and usability of a system. Test plans are made as
soon as the coding work was started. Each new component developed would first undergo
unit testing and on success integration testing would be done.

77. 74 | P a g e
6.3 Test Strategies
6.3.1 Unit Testing
Under this testing phase each of the functions used in the development of the system were
tested. The mistakes were corrected and modifications were made as required. Unit
Testing is done to ensure that a component (unit) is behaving as intended and working well
as a system in its own.
6.3.2 Integration Testing
With the collection and integration of variety of functions, modules were developed which
again had to be tested in order to recognize the mistakes underlying when being
integrated. This was also done during the coding phase after which the working of each
module was presented to the supervisors for their comments so that further modifications
could be made or could be thought of. The supervisor’s advice was taken into consideration
and further correction and modification was made.
6.3.3 System Testing
As the unit and integrated testing was done the system was created. The system testing
was done and the errors were identified and rectified as and when required. Further
modifications were made as per the suggestions of the supervisor.
6.3.4 Acceptance Testing
To determine whether the developed system is accepted and liked by the client, acceptance
testing was carried out. This will be done by the client at the testing site. Finally changes
will be made according to the client response.

78. 75 | P a g e
6.4 Test Cases
Test case 1
Function Name: Agent Login
Description: Accepts username and password and verifies it.
Table 35: Test Case for Admin Login
Test case 2
Function: All input fields
Description: Test the Blank field submission for all the input fields.
Table 36: Test Case for Blank Field
Input Data Real Data Expected
Output
Real
Output
Remarks
Username Password Username Password
Abisek Bansal
admin Admin
Valid
Admin
False
Error box
displays in
screen
Admin Admin True Admin Login
Input Data Real Data
Expected
Output
Real
Output
Remarks
- Any text or number
Please fill the
blank the
fields
False
Error at
client side
Any text or number Any text or number
Form
Submitted
True
Request id
send and
waits for
response

79. 76 | P a g e
Test case 3
Function: Control number verification
Description: Test the control number for payout the transaction .
Table 37: Test Case for Control Number
Input Data Real Data
Expected
Output
Real
Output
Remarks
19100581089 91075210882
Invalid Control
number
False Error
91075210882 91075210882
Payment
details
True
The control
number
matches

80. 77 | P a g e
Chapter 7
7 Conclusion
7.1 Conclusion
7.2 Lesson Learnt
7.3 Recommendation

81. 78 | P a g e
7.1 Conclusion
Mobile Remittance is application software that basically focuses in the transfer of money
from one customer (Sender) to another (Receiver) on the behalf of bank Agent of bank or
other financial institution. This is the extended version of Remittance which is portable and
effective. The actual need of this application is useable when there was load shedding
problem while having services of Remittance provided by certain bank especially in Nepal.
So when customer comes at the point of Bank’s Agent they fill up the form and Bank agent
transmit the money required to send to particular person. Hence it works as the helper or
supporter for remittance services of the bank through JAVA enabled mobiles.
As per the requirement of TU and BIM courses we have done our internship program in 8th
semester at Swift Technology, Industrial internship project work is great experienced and
opportunity to work in real environment and also timing is important.

82. 79 | P a g e
7.2 Lesson Learnt
Some of the lesson that I have learnt during my internship are:
 To cope with the real world and practical environment.
 The importance of time; working within the time constraints is a very important and
difficult in the real world.
 Always keep the contingency plans as a backup, since they may be useful in the future
whenever requirements of the clients changes.
 I got the chance to implement a lot of things that I learnt during my BIM courses in the
practical world.
 The exposure to the practical environment has increased my experience and confidence
to deal with the real world problems.
 We have to consider time and limitations/boundaries every time we take a new step
towards our destination.
 I learnt to have good communication skills.
7.3 Recommendation
7.3.1 To Organization
The environment that I got in swift technology was motivating and friendly. Each and every
senior programmer was helpful and without them the project would not have been
completed. The Mobile Remittance is a live project for IME Finance institute and the
projects has many other areas to improve.

83. 80 | P a g e
7.3.2 To Internship Program
The internship program which is brought by Tribhuwan University for BIM scholars is
helpful of the students to know how the works are done in real world. The students can
integrate their theory knowledge with their practical skills. But I would like to recommend
university to make the internship program wise. The time that is provided to student for
intern is very much less and the university expects the students to complete the project
within that short period and moreover a real world system is difficult to develop in 2-3
months. Therefore if university wants to see the students make more advance projects then
the remaining pressure of the studies should be reduced.
7.3.3 To College
St.xavier’s College provided us support and guidance through the internship period. The
department of Bachelor in Information Management was always there for supervision. I
would like to recommend the department to motivate the students so that we can be
influenced to so the work without feeling pressure.

84. 81 | P a g e
APPENDIX A
8 SNAPSHOTS

85. 82 | P a g e
1) Login interface
Figure 43: Snapshots of Login Form
Figure 43 shows the interface of login. It consists of username, password, agent code and
user Id. It also consists of button for login and exit

86. 83 | P a g e
2) Main Form (Home Interface)
Figure 44: Snapshots of Home page
Figure 44 shows the menu page of the application. It consists of all the menus in list that an
agent can perform.

87. 84 | P a g e
3) Remittance Menu
Figure 45: Snapshots of Remittance Menu
Figure 45 shows the remittance menu of the application . It consists of send payment and
cancel transactions.

88. 85 | P a g e
4) Sender Information Entry Form for Send Transaction
Figure 46: Snapshots of Sender Information for send transaction
Figure 46 shows sender information entry page for send transaction of the application. It
consists of mobile number, full name, Id type and Id number of sender

89. 86 | P a g e
5) Receiver Information Entry Form
Figure 47: Snapshots of Receiver Information for send transaction
Figure 47 shows receiver information entry page for send transaction of the application. It
consists of mobile number, full name, Id type and Id number of sender

90. 87 | P a g e
6) Payout Information Entry Form
Figure 48: Snapshots of payout Information for send transaction
Figure 48 shows payout information entry page for send transaction of the application. It
consists of form number, payout location, amount and payment type.

91. 88 | P a g e
7) Send Transaction Summary Information
Figure 49: Snapshots of Send Transaction Summary
Figure 49 shows send transaction summary for send transaction of the application. It
consists of conformation menu for making the transaction

92. 89 | P a g e
8) Control Number Generation
Figure 50: Snapshots of Control Number
Figure 50 shows control number generation page after send transaction of the application.
It consists of control number for the transaction.

93. 90 | P a g e
9) Payout Transaction Information Entry Page
Figure 51: Snapshots of payout information entry page
Figure 51 shows control payout information entry for the transaction of the application. It
consists of control number for the transaction, and receiver information.

94. 91 | P a g e
10) Payout Summary Page
Figure 52: Snapshots of payout summary page
Figure 52 shows control summary for the transaction of the application. It consists of menu
for making the choice for the transaction.

95. 92 | P a g e
11) Cancel Transaction Page
Figure 53: Snapshots of cancel transaction page
Figure 53 shows cancel transaction of the application. It consists of control number and
reasons for cancellation.

96. 93 | P a g e
12) Cancel Transaction Summary
Figure 54: Snapshots of cancel transaction summary page
Figure 54 shows summary for the cancel transaction of the application. It consists of menu
for making the choice for the transaction.

97. 94 | P a g e
APPENDIX B
9 References and Bibliography
1) Highes, B. and Cotterell, M., Software Project Management, McGraw Hill, 1999.
2) Kathy sierra and Bert Bates, Head First Java.
3) James Keogh, J2ME: The Complete Reference.
4) Jonathan Knudsen, J2ME from Novice to Professional.
5) http://developer.nokia.com/java
6) http://developers.sun.com/mobility/
7) http://stackoverflow.com