Report Internship

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 | 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 | 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

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

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.

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.

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,

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.

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

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

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.

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

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.

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

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

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

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.

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

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.

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.

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

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

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.

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.

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:




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

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.

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]

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

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.



Post-Condition Displays end of Payout Module.


Table 6: Description of Payout Module Requirement

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.


The Send Transaction should have been done.

Post-Condition Displays end of Cancel Transaction Module.


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.



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

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.




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.

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.

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.

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


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.

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


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.

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.

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.

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.

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

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:




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.

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

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]

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]

42 | P a g e

Figure 15: Level 1 DFD [D3]

43 | P a g e

Figure 16: Level 2 DFD for Agent Login [D4]

Figure 17: Level 2 DFD for Send Transaction [D5]

44 | P a g e

Figure 18: Level 2 DFD for Payout Transaction [D6]

Figure 19: Level 2 DFD for Cancel Transaction [D7]

45 | P a g e

Figure 20: Level 2 DFD for Top-Up [D8]

Figure 21: Level 2 DFD for Change Password [D9]

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

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


Description This function takes the receiver information..

Table 15: Input receiver Information

PSPEC 2.3: Input Payment Information

Input Payment Information


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

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

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


Description This function takes the reasons

Table 25: Reasons for cancellation


Input Information

Output Information

Description This function changes the transaction status to cancel.


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


Description This function takes the phone number to transfer amont. Table 28: Insert Phone Number

50 | P a g e

PSPEC 5.2: Insert Amount

Input Amount to transfer


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


Input Information

Output Information

Description This function gives the Top-Up 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

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

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).

53 | P a g e

4.4 Data Design

4.4.1 Schema Diagram

Figure 23: Schema Diagram [D10]

54 | P a g e

4.4.2 Data Dictionary

Figure 24: Agent Login

Figure 25: Account

Figure 26: Credentials

Figure 27: Remittance Account

55 | P a g e

Figure 28: Remittance

Figure 29: Remittance Token

Figure 30: Top Up

Figure 31: Top up Account

56 | P a g e

4.5 Functional Design

Figure 32: Flow of the system [D11]

57 | P a g e

Figure 33: Flow of the send Transaction [D12]

58 | P a g e

Figure 34: Flow of the Payout Transaction [D13]

59 | P a g e

Figure 35 Flow of the Cancel Transaction

60 | P a g e

Figure 36 Flow of the Top Up [D14]

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.

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]

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.

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.

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.

66 | P a g e

4.8 System Architecture

Cancel transaction

Log in Request

Login Status

TopUp transaction

View ReportsMobile Remittance

System

0

Send TransactionControl 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]

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

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

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

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

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

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

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.

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.

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


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

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


Output

Real

Output Remarks

19100581089 91075210882 Invalid Control

number False Error

91075210882 91075210882 Payment

details True

The control

number

matches

77 | P a g e

Chapter 7

7 Conclusion

7.1 Conclusion

7.2 Lesson Learnt

7.3 Recommendation

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 8 th

semester at Swift Technology, Industrial internship project work is great experienced and

opportunity to work in real environment and also timing is important.

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.

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.

81 | P a g e

APPENDIX A

8 SNAPSHOTS

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

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.

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.

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

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

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.

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

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.

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.

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.

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.

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.

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

Date post:	04-Dec-2014
Category:	Technology
Upload:	abisek123
View:	454 times
Download:	24 times