MOBILE MUSIC APPLICAION
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.