MOBILE MUSIC APPLICAION

profileAmericaCool
mo-bank_proposal_week2.docx

Abstract

Mo-Bank is a mobile based application that will be implemented in mobile based languages. The application is aimed at minimizing the problems that are incurred in banking industry. The application will be supported by the database of choice that will see a good management of customer data. The application will be composed of the following parts:

i. Customer registration. This is the part in which every customer that will be using the system is registered. This will involve the input of the detailed customer information and giving the customer a username and password.

ii. Group registration: this is the part in which the detailed information of a group is registered and hence being given the password and username. This will see them being able to access their accounts.

iii. Employee registration. This is the point in which the employee’s information is keyed in. This will result the provision of rights, username and password and hence making the employee to access the account.

iv. Administration: this is the part that will mostly deal with the administration of the whole system. This will involve the addition of roles and rights to employees and also the overall management of the system

Table of Contents Abstract i CHAPTER ONE 1 1.0 Introduction 1 1.1 Problem Statement 1 1.2 Objective 1 1.2.1 General Objective 1 1.2.1 Specific Objectives 1 1.3 Problem justification 2 1.4 Scope of the Project and Application of the project 2 CHAPTER TWO 3 2.0 Methodology 3 2.1 Fact findings 3 2.2 Mo-Bank requirements 3 2.2.1 Login credentials 3 2.2.2 User information 3 2.2.3 Amount to send to bank 4 2.2.4 Withdraw from bank 4 2.2.5 Loan 4 2.2.6 Bank balance 4 2.2.7 Mini statement 4 2.2.8 Reliability 4 2.2.9 Safety 4 2.2.10 Response time 4 2.3 Functional requirements 4 2.4 Non-functional requirements 5 2.5 Software development phases. 5 2.5.1 System Requirements &Analysis 6 2.5.2 System Design 7 2.5.3 System Coding & Testing 7 2.5.4 System Implementation 7 2.5.5 System Maintenance 7 2.6 system architecture 8 2.6.1 Component diagram 8 2.6.2 Class diagram 8 2.6.3 Use case diagram 9 2.6.4 Main screen of the application 10 CHAPTER THREE 11 3.1 Resources 11 3.2 Schedule 12 3.3 Budget 13 3.4 Risk 13 4.0 References 14

CHAPTER ONE

1.0 Introduction

A research that was conducted recently by some group of researchers, clearly pinpointed the myriad range of problems that the customers encounter in the banking industry. The problems range from the long time and bureaucracy involved in accessing their accounts and also their bank balances. This has seen a further decline of new customers joining the banking industry and also individuals resorting to the old methods of money saving.

All these reasons has boosted the creation of the Mo-Bank mobile application that will see an end to all this problems as it will enhance the customers to access their accounts directly from their phones. The customers can be able to transact like paying bills and can also print their account statement plus checking their balance.

1.1 Problem Statement

Various measures have been put in place to enhance the reduction of the pain experienced by the customers by the banking industry. However, the process as proved futile as many customers continue experiencing many challenges in the sector. These challenges may include among the following:

i. The customers have difficulties in accessing their accounts in good time.

ii. There’s a lot of bureaucracy involved before they access their accounts and do some transaction.

iii. There information is not well up to date and hence cannot continue to make any meaningful transactions.

iv. They experience major delays when the network is down and hence cannot access their banks.

v. They usually travel long distances to locate the banks and hence making it a tedious process.

1.2 Objective

1.2.1 General Objective

To develop a mobile application that will ease the customer services in the banking industry.

1.2.1 Specific Objectives

i. To develop a system that will enable customers to manage their accounts from their mobile phones directly.

ii. To reduce their bureaucracy involved in the banking industry as they can check their balances and make transactions just from their phones.

iii. To reduce the long travel of the customers by enabling them manage their accounts directly from their mobile devices.

1.3 Problem justification

Due to the many problems that the customers face, I therefore recommend a mobile application that will see the farmers managing their accounts in the most efficient ways ever. The benefits that will accrue from the same include:

i. Reduce bureaucracy. The process involved in accessing the balance and also doing some transaction will be highly reduced as they will be able to access their accounts directly from their mobile devices.

ii. Reduce time and distance. The time involved in accessing their accounts will be minimized significantly as they will be involved in long distance travel. This is because accessing their bank details will just be a click away.

iii. Avoiding network problems. The customers will fully be exempted from the network issues as they will not encounter any since they will be using their mobile devices to access the account details and services.

1.4 Scope of the Project and Application of the project

The project will be applicable to most banking sectors and hence enabling to gain much profits as expected. The application will spearhead the full implementation of customer managing their accounts from the mobile application and hence enhancing the bank growth.

The system will be developed using a mobile based language and will be supported by a powerful database that will reduce the throughput and response time. The application will work in such a way that the person can login using the password and username provided and hence accessing the services that he/she is supposed to see.

CHAPTER TWO

2.0 Methodology

2.1 Fact findings

This chapter outlines the methods that I will use to collect data for this research project (Shelly & Rosenblatt, 2009).

Methods used:

2.1.1 Questionnaire

I will design both open - ended and closed- ended questionnaires and later administer them to various respondents including bank accounts working in various stations. The aim of the open ended questions will be to capture detailed opinions from the respondents on the area of interest. The closed- ended question will capture the views of the respondents concerning a particular specific area. The respondents will not be subjected to any influence and the questionnaires will be self-administered to the respondents.

2.1.2 Observation

Various bank sectors will be visited and observe their day to day operation and challenges they encounter with their jobs. The information gathered will be useful in design of the proposed system.

2.1.3 Interview

Interviews will be conducted to a good sample of bank accounts and hence gaining much information on the system proposed to be developed.

2.1.4 Record View More information related to the project will be gathered from various published sources such as newspapers, magazines, journals, documents etc. This will provide valuable information about the proposed system.

2.2 Mo-Bank requirements

2.2.1 Login credentials

This is the most critical has it is used in securing the system. This is enhanced by using the rights property in which every user registered is given the rights in the places he or she can access. This is important in protecting the information from being reached by unknown people.

2.2.2 User information

This is the information of the client of the bank including his/her personal details and the kind of transactions that he/she does with the bank. This is important has it will aid the user in logging in and also monitoring his/her transactions.

2.2.3 Amount to send to bank

This is the part in which the user can send the amount he or she wants to bank. This is of importance as the user does not need to travel to bank.

2.2.4 Withdraw from bank

This is the amount that the user can withdraw from his/her account. It is also of importance as the user does not need to queue for him/her to withdraw.

2.2.5 Loan

This is the point in which the bank can allow an individual to take a loan depending on some specified conditions. The same is just allowed in many banks over the counter which includes many constraints.

2.2.6 Bank balance

This is the point in which the users are allowed to check their account balances. This is well organized since it helps the individual to have the balance instantly.

2.2.7 Mini statement

This is point in which the user is allowed to have a report on the kind of transactions that he/she has carried out over a certain period of time.

2.2.8 Reliability

This is the point in which the users can trust the system and hence can carry out transaction with it. This can be measured over a period of time and hence determining whether it is reliable or not.

2.2.9 Safety

This is the assurance that the system even if it is down, cannot make gravious mistakes on the user’s side. The system should be safe and hence allowing the customers to truly trust it and hence investing in it.

2.2.10 Response time

This is the time in which a user makes a request and the time he/she gets it. This is critical and should be kept as low as possible and hence not making the customers lose patience.

2.3 Functional requirements

A functional requirement defines what the system is supposed to do. This may include among the following:

i. Login details

ii. User information

iii. Amount to send to bank

iv. Amount to withdraw and many more from our requirements

2.4 Non-functional requirements

This are the requirements which specify the criteria that can be used in judging the operation of the system. This may include among the following:

i. Safety

ii. Response time

iii. Reliability and many more.

2.5 Software development phases.

Sashimi Waterfall model will be used in the system design

Requirements

Specification and analysis

System Design

Development & Coding

System

Testing

System

Implementation

System Maintenance

The sashimi model is also referred to as the “waterfall model with overlapping phases” or “the waterfall model with feedback”. Since phases in the sashimi model overlap, information of problem spots can be acted upon during phases that would typically, in the pure waterfall model, precede others. For example, since the design and implementation phases will overlap in the sashimi model, implementation problems may be discovered during the design and implementation phase of the development process. This iterative method helps alleviate many of the problems associated with the traditional philosophy of the waterfall model (MALL, 2009).

2.5.1 System Requirements &Analysis

User requirements shall be gathered at this stage.

2.5.2 System Design

An outline of the final product will be set at this stage. This will involve coming up with context diagrams, Data flow diagrams.

2.5.3 System Coding & Testing

This stage will involve system coding and development. All components will be tested to functionality before integration to each other. System testing will be a continuous exercise until the final product is produced (Jalote, 1997).

2.5.4 System Implementation

This is the phase of the project where the developed software is installed (or deployment scripts are delivered), documentation is written or cleaned up (as documentation should be written as an ongoing part of the development process), and sometimes client training will occur. Implementation is the only phase that will sometimes overlap backwards two phases (between Deployment and Development) since there are sometimes things that are caught between Implementation and Testing phases that require additional development to resolve.

2.5.5 System Maintenance

After the project is released into the world, bad things can happen. This is why it is important that continued maintenance and support is addressed within any software development process. With the needs of clients and technology itself changing constantly, this support becomes an evolving process and is essential to make sure that the software continues to perform as expected.

2.6 System architecture

2.6.1 Component diagram

2.6.2 Class diagram

2.6.3 Use case diagram

2.6.4 Main screen of the application

CHAPTER THREE

3.1 Resources

The Mo-Bank mobile application will require both hardware and software resources which include:

Hardware resources

· Laptop/desktop computer

· Hard disk 80GB

· RAM 1GB

· Digital camera.

· Printer

Software resources

· Operating system(window xp,windows 7,windows 8,ubuntu)

· SQL database

· Adobe Dreamweaver CS6.

· Foxit reader

3.2 Schedule

Below is the schedule to be followed during development.

TASK

JULY

AUG

AUG

AUG

SEPT

SEPT

SEPT

OCT

PROPOSAL

WRITING

SYSTEM ANALYSIS & REQUIREMENTS

 

 

 

 

 

SYTEM

DESIGN

 

 

 

 

 

SYSTEM CODING & TESTING

 

 

 

 

 

SYSTEM IMPLEMENTATION

 

 

 

 

 

SYSTEM MAINTENANCE

SYSTEM DOCUMENTATION

A Gantt chart for the Mo-Bank mobile application.

3.3 Budget

This is the approximated estimates of the financial requirements needed to develop the Mo-Bank mobile application (Rasmussen & Eichorn, 2000).

ITEM

UNIT

PRICE PER UNIT (KSH)

COST

(KSH)

COMPUTER/LAPTOP

1

45000

45000

DIGITAL CAMERA

1

15000

15000

PRINTER

1

10000

10000

SQL SERVER

1

2000

2000

ECLIPSE SDK

1

3000

3000

FOXIT READER

1

500

500

PROPOSAL PRINTING

3

200

600

INTERNET FOR RESEARCH

8

1000

8000

TRANSPORT

3

200

600

DOCUMENTATION PRINTING& BINDING

3

1000

3000

TOTAL COST

87,700

3.4 Risk

Compatibility issues may arise with one or more operating system such as Symbian, Windows, Android, iOS. General public though wants to let go of queuing up in banks, acceptance of this application will definitely make it simpler for the public but they may consider it non-secure and unsafe to do transaction.

Project may be delayed if some developer moves out or we face some problems with the hardware.

4.0 References Jalote, P. (1997). An Integrated Approach to Software Engineering. Springer, 1997. MALL, R. (2009). FUNDAMENTALS OF SOFTWARE ENGINEERING. PHI Learning Pvt. Ltd., 2009. Rasmussen, N., & Eichorn, C. J. (2000). Budgeting: technology, trends, software selection, and implementation. J. Wiley, 2000. Shelly, G., & Rosenblatt, H. J. (2009). Systems Analysis and Design. Cengage Learning, 2009.