Design And Implementation Of A Spending Application

Problem Statement

This document discusses the design and implementation of a spending application which will help its users to track usages of their incomes to facilitate better spending habits and money saving habits. The document discusses the problem statement as well as presenting a feasibility study report to show and justify whether the project is feasible or not. The document also shows different models of the system which can be used to give both a conceptual and in depth view of the proposed application and at the final stages it discusses the possible design for the proposed application including the factors to consider while designing the application.

In the current times, many people do not keep track of their expenditures and income. This can be attributed to the fact that income is not as often as expenditures thus many people get an income for example every month but the expenditures that go in between the month from the day the person is paid until the time they get the next income are very many. Expenditures happen almost every moment of our life ranging from the smallest expenditures that require very little money to big expenditures that require a large amount of money. Due to lack of a tracking tool which people can use to track their expenditures people end up not knowing where their income is going except for the big projects which are easy to remember. When a person is not tracking their expenditures, it’s very hard for that person to save money and they end up using more money than they should use as a result of impulse buying and adapting spendthrift behaviors. An expenditure tracking application can help people who have a problem with spending money get an insight on where most of their money is going thus help them to adapt better spending behaviors and in the long run help the users to save some of their income.

Project objectives

The following will be the objectives of the project;

• Provide users with an interface when they can declare their source of incomes and what each source is generating within a given timeframe. This sources of income will automatically add the declared amount of income after every timeframe is reached.
• Provide users with an interface where they can add unofficial sources of income; for example money earned by the user and was not planned for.
• Provide users with an interface where they can add expenditures in a very easy way as expenditures are very frequent.
• Provide the users with an overview of how he or she is using their money. This can be a graph showing income against expenditure.
• Give users tips on how to save their money.
• Study user spending habits then use this data to predict if the user is overspending money thus generate a notification warning the user thus that they are going over their normal spending rates in a given timeframe. For example if a user spends approximately
• Show reports to the user of where most of the money is going to thus giving them a chart showing which activities are using up more money and which activities are using the least money.

The project is designed to help the user manage their income by providing a tool through which the users can declare their sources of income and record every expenditure in order to track the expenditure of the user. The application will help the user get an overview of how they are using their money. After a few months of using the application, the application should be able to learn how the user spends money by analyzing their spending patterns so as to provide recommendations when the user is using up more money than they should.

Scope of the Project

Project methodology is the approach that will be used to implement the project. For this project Agile approach will be used. Agile approach is a methodology where the application is developed in increments and delivered to the users in increments. The project will have the following stages. These stages can be thought of as the stages of the life cycle of the project.

• Requirements gathering and analysis
• Design
• Implementation
• Testing
• Deployment
• Maintenance

Requirements gathering and analysis is the process of gathering requirements through use of various methods of research like observation and interviews and then doing an analysis on the requirements to come up with the project specifications (Kossiakoff and Sweet, 2003)). Requirements gathering can be divided into;

• Requirements engineering- this is the collection of requirements. This stage includes of research to come up with user stories. An example of a user story for this project could be as follows;
• As a user of the application I want to be able to record all my sources of income
• As user of the application I want to be able to record all my expenditures easily
• As user of the app I would like to be able to see where my money is going by seeing which activities are using which amount of money. This can be done by use of a chart to show each activity against the money used within a given timeframe.
• As a user I want to be able to get notifications if am using more money that I usually use in a given timeframe as a tip to help me rethink my spending habits
• As user of the application I want to be able to get tips when am using the application to help me with my expenditures and my savings.
• Requirements analysis- This is process of analyzing the data collected either from user stories or observation or even other methods of doing research to come up with a specification documents. The specifications document is then used to in the design stage of the application.

The design stage of the project uses the specifications document gotten from the fist stage of the project life cycle. The specifications document guides the team of developers to come up with a design based on the specifications derived from user requirements

This stage can also be called the coding stage. This is the stage where the actual implementation of the application is done. Coding means provide a backend functionality to all the designs achieved in the design stage of the project life cycle.

For this project the implementation method to be used is scrum. Scrum is a methodology of development where the program is divided into smaller programs and the smaller programs sub divided into smaller parts called sprints. Each sprint is supposed to take a certain amount of time to develop.  A sprints are given to members of the team where by each member can “scrum” for the sprint which they are comfortable with and are they are sure they will be able to handle. For scrum to work, the team of developers have to ensure a high degree of communication. The communication should not only be high but very effective to make sure the sprints are implemented properly where by different sprints need to communicate with each other. For example a team member can be assigned a method which communicates with another method assigned to another team member. Because the two methods are communicating the two developers have to ensure communication for the two methods to be developed successfully.

The testing stage is used to test the implemented increments delivered as increments. Testing is done to make sure the increment performs according to its requirements before it’s released (Pittet, 2015). Testing in agile methodology involves testing every increment before it’s delivered. The following diagram shows the testing process in agile methodology where continuous integration is the key for agile development.

Project Objectives

Figure 1: Agile testing and continuous integration

The types of testing done are;

• Unit testing
• Integration testing
• System testing
• Regression testing
• Performance testing
• Usability testing
• Acceptance testing

Unit testing involves testing every unit before it is integrated with other units to form a component. In agile using scrum approach, the unit can be the sprints allocated to every team member which have to be tested before integration is done.

Integration testing is testing on the integration of units to make sure the units have been integrated successfully without any error. For example integration testing between two methods communicating between themselves can involve testing the parameters to determine of the data passed matches with the type of parameters.

System testing involves testing the whole system for bugs. Testing is done on all components to make sure that they have been integrated properly to from the whole system.

Regression testing involves running the system through tests to identify bugs. Regression testing is testing the system to fail so that the bugs can be identified before the system is deployed. Regression testing can be simulated with actual user data to see if the system will pass all the tests.

Usability testing is testing done to see whether the system is usable to the end users. Usability testing can use real users who will be using the application as subjects who will be using the application as a beta.

Acceptance testing involves testing to see whether the application is acceptable by the end users. This type of testing can be done by releasing a beta version of the application and asking for users using the application to provide feedback about their views of the application.

Deployment of the system is the release of the application to be used by end users. The proposed application will be an Android so it can be deployed by publishing it on the play store where users can download and install the application. The application can also be posted on a website designed specifically for the application where users can download the application from the website.

After the application is deployed, maintenance is done on the ready deployed application. Maintenance can involve releasing updates and patches of the application and also releasing consequent builds which have no bugs. The bugs can be identified by users while using the application thus the team of developers has to remove the bug and release a new update of the application.

 The resources required to undertake the project are physical resources that are going to be used to undertake the project. The resources range from labor and the physical resources like computers that will be used to do the implementation. The labor required should have the technical knowhow of what is required to undertake the project. For this project the design will have to be very good thus a team member who has skills of material design. The backend of the project will be done using Java thus the project requires more than one team member competent in java who will be in charge of the backend development. The project also requires a testing specialist who will be able to conduct all types of test. One of the team members will have to be delegated the role of quality assurance to ensure everything that is done is done to perfection.

Goals of the Project

The budget of the system is the estimated amount of money that will be used. The money includes the money for acquiring the resources that will be used during the development and the labor cost. For the proposed application the estimated budget is $5000.

The schedule of the project is the total amount of time that will be used and how it will be allocated (Makar, 2016). The following is the schedule for the proposed week.

Event	Estimated time	Deliverable
Requirement gathering and analysis	1 month	Requirements analysis document and software specifications document.
Design	1 months	A design of the system
Implementation	5 months	Fully working system
Testing	1 month	Test document
Deployment	1 week	Fully working application
Maintenance	Onwards	Updates and patches

Figure 2: Gantt chart

Feasibility study is the process of investigating whether the project is viable to be undertaken or not. Feasibility study involves doing a cost/benefit analysis to determine whether the benefits of the system weigh more than the cost of the system (MacDonough, 2013). This in other hand means analyzing to determine whether the cost of the project is worth the benefits of the project. There are different types of feasibility studies done for this project;

• Technical feasibility- this type of feasibility study is aimed at establishing whether the company has the technical capability to undertake the project. This includes investigating whether the company has the technology necessary to undertake the project. For the expenditure tacking application technical feasibility analysis shows that the company has the technical capability to undertake the project.
• Schedule feasibility- this type of feasibility aims at establishing whether the company has enough time and resources to undertake the project. For the proposed application, schedule was not a problem since the application was not a contract by a customer.
• Economic feasibility- Economic feasibility focuses on cost/benefit analysis where by an analysis of the benefit s of the system are done to see whether the benefits of the system are worth the cost. The benefit for the proposed application is the return on investment.

Functional requirements describe the core functionality of the proposed application. There are two types of functional requirements;

• Functional process requirements
• Data requirements

Functional process requirements describe what the project is intended to do especially for the end user (Constantinides, 2014). The following are the functional requirements of the proposed expenditure tracking application.

Functional requirement ID	Requirement description
1	Register
2	Login
3	Enter sources constant sources of income
4	Add expenditures
5	View income vs expenditure report and get a conceptual view through a graph
6	Enter other sources of income
7	Get notifications on expenditure usage if expenditure exceeds the limit
8	Get tips on expenditures

The following diagram shows the data flow diagram better illustrating the functional requirements of the system.

Figure 3: Data flow diagram

Data requirements describe the data the proposed application will deal with by showing how the data will be stored by showing tables and the structure of the database (Bahil and Dean, 1997). The database will be a relational diagram where by objects with different attributes are related to each other.

Figure 4: Entity relationship diagram

The proposed expenditure tracking application will have the following entities;

• User(userID, name ,email, phone, password, image)
• Income (incomeID,type,notes,amount,date,userID)
• Expenditure (expenditureID, type, notes, amount, date , userID)
• Notifications (notificationID, message, userID)
• Tips (tipID, message)

Entity	Attribute	Data Type	NULL	Constraint
User	userID	INT	NO	Constraint primary key (userID) auto increment
	Name	VARCHAR(100)	NO
	Email	VARCHAR(250)	NO
	Phone	VARCHAR(25)	NO
	Password	VARCHAR(500)	NO
	image	LONG BLOB	YES
Income	incomeID	INT	NO	Constraint primary key (incomeID) auto increment
	Type	VARCHR(50)	NO
	notes	TEXT	NO
	Amount	FLOAT	NO
	Date	TIMESTAMP	NO
	userID	INT	NO	Cosntraint foreign key (userID) references  user (userID)
Expenditure	expenditureID	INT	NO	Constraint primary key (expenditureID) auto increment
	Type	VARCHAR (50)	NO
	Notes	TEXT	NO
	Amount	FLOAT	NO
	Date	TIMESTAMP	NO
	userID	INT		Constraint primary key (expenditureID) auto increment

Operational requirements describe the non-functional requirements (Seymour and Biemer, 2014) of the proposed application. Nonfunctional functions are features that the user do not interact with but are used to make the user experience good and secure. The nonfunctional requirements are;

Security is one of the most important concerns for users who will be using the application. The application has to be developed to be secure to assure the user that his or her data is safe and secure from malicious users. The application should ensure that transmission of data between the client and the server side part of the application is safe. This is done by implementing encryption from end to end such that if a malicious man in the middle is able to intercept packets during the communication he/she is not able to decode the data. The database of the system should be hosted on a very secure server with the best security policies like firewalls.

Project Methodology

Data currency can be defined as the measure of how recent the data that the user interacts with is. The application should be designed and developed to run on a very compact database such that data fetched from the database is concurrent.

Reliability of the application can be defined as the robustness nature of the application and its ability to continue in the presence of errors without aborting the whole application. The application should be designed using code designs that ensure reliability of the application. This includes use of try and catch to catch exceptions that could cause the application to abort.

System availability of the proposed application is the time that the application is supposed to be up and running. This is majorly the servers because the user will be storing data on a remote database. The system should be up every time to ensure users can use the application anytime.

The application should use high performance servers to make sure the user interacts with the application in an efficient way. The server should be able to handle a large volume of data generated by many users using the application.

Use case modelling involves defining the possible use cases that will result as the user interacts with the application. The following use case diagram can be used to show the possible use cases.

Figure 5: Use case diagram

Use Case ID:	UC-1
Use Case Name:	Register

Actor:	User
Description:	User registration
Preconditions:	User must have a working email
Postconditions:
Priority:	High
Frequency of Use:	Once after downloading the application
Normal Course of Events:	Fill form and press submit
Alternative Courses:	User registers in the website
Exceptions:
Includes:
Special Requirements:
Assumptions:
Notes and Issues:	Every user has to register to use the application

Use Case ID:	UC-2
Use Case Name:	Login

Actor:	User
Description:	User login to access their profile through the application
Preconditions:	User must have already registered
Postconditions:
Priority:	High
Frequency of Use:	Frequently if log out are frequent
Normal Course of Events:	Fill form and press submit
Alternative Courses:
Exceptions:	User has not logged out
Includes:
Special Requirements:	Email and password
Assumptions:	The has an account and is not logged in to their profile
Notes and Issues:	Every user has to register to use the application

Use Case ID:	UC-3
Use Case Name:	Manage income

Actor:	User
Description:	Adding, editing or deleting sources of income
Preconditions:	User must be logged in
Post conditions:
Priority:	High
Frequency of Use:	Frequent
Normal Course of Events:	Fill form and press submit
Alternative Courses:
Exceptions:
Includes:	Add income, edit income, delete income
Special Requirements:	Income details
Assumptions:
Notes and Issues:	Income are added frequently

Use Case ID:	UC-4
Use Case Name:	Manage expenditure

Actor:	User
Description:	User adds, edits or deletes an expenditure
Preconditions:	User must be logged in
Postconditions:
Priority:	High
Frequency of Use:	Frequent
Normal Course of Events:	Fill form and press submit
Alternative Courses:
Exceptions:
Includes:
Special Requirements:
Assumptions:
Notes and Issues:	Expenditures are what the user is spending every time

Use Case ID:	UC-5
Use Case Name:	View notification

Actor:	User
Description:	User views system generated notifications
Preconditions:	User must be logged in
Postconditions:
Priority:	Medium
Frequency of Use:	Rarely
Normal Course of Events:	Open notification click on a specific notification to view
Alternative Courses:
Exceptions:	User has no notifications
Includes:
Special Requirements:
Assumptions:	The user has notifications
Notes and Issues:	A notification is generated if the user passes the expenditure limit

Use Case ID:	UC-6
Use Case Name:	View report

Actor:	User
Description:	User views report of income against expenditure
Preconditions:	User must be logged in
Postconditions:
Priority:	Medium
Frequency of Use:	Frequent
Normal Course of Events:	Opens report page
Alternative Courses:
Exceptions:	User has not added any income and any expenditures
Includes:
Special Requirements:
Assumptions:	The user has added incomes and expenditures
Notes and Issues:	Report is shown by use of a graph

Use Case ID:	UC-7
Use Case Name:	View tip

Actor:	User
Description:	User views expenditure tips
Preconditions:	User must be logged in
Postconditions:
Priority:	Low
Frequency of Use:	Rarely
Normal Course of Events:	Open on a tip
Alternative Courses:
Exceptions:
Includes:
Special Requirements:
Assumptions:
Notes and Issues:	Tips are automatically generated by the system

Overview

Unified modelling language (UML) is a standard technique that is used to visualize the design of a system.  UML uses diagram to show the architectural blueprint of a system and other elements of the system including;

• Activities in the system
• External users and how they interact it the system
• Different components making up the system
• Interaction between different components making u the system.

Modelling of a system involves showing two aspects of the system. These two aspects are;

• Static aspect – The static aspect of the system shows the static structure of a system by use of objects, their attributes, relationships and operations. The static aspect of a system can also be referred to as the structural view of the system
• Dynamic aspect- The dynamic aspect of the system shows the dynamic behavior of a system through showing the collaborations existing between objects and state changes that occur to objects internally. The dynamic aspect of a system can also be referred to as the behavioral view of the system

Based on the system views discussed above there are two types of UML diagram. i.e.

• Structural view UML diagrams- these show the static view of a system. They include;
  • Class diagrams_ class diagrams are used to show classes making up the system. The classes are objects which contain different attributes and operations and are interrelated. Class diagrams are used throughout the software development lifecycle.
  • Composite structure diagrams- A composite structure diagram is used to show the internal structure of classifiers that are structured by use of connectors, parts and ports. This diagram is mostly used in the implementation phase of the software development life cycle.
  • Component diagram- Component diagram is a UML diagram used to show components making up a system. The component diagram shows the architecture of the system. Component diagrams are mainly used in the design phase of the software development lifecycle.
  • Package diagram- These are UML diagrams that are used to show the organization of elements making up the system. Package diagrams are mostly used in the implementation phase of the software development lifecycle.
• Behavioral view UML diagrams- These type of UML diagrams are used to show the behavioral view of a system. They include;
  • Sequence diagrams- Sequence diagrams are UML diagrams that are used to show the sequence of interactions between objects making up a system Sequence diagrams are mainly used in the design and implementation phase of the software development life cycle.
  • Activity diagrams- The activity diagram is a UML diagram that is used to show the flow of activities in the system. The activity diagram is mainly used in the implementation phase of the software development life cycle.
  • State machine diagrams_ these are UML diagrams used to show states that a given object can achieve and how the object transitions from one state to another. These diagrams are mostly used in the implementation phase of the software development life cycle.
  • Use case diagram_ use diagrams are used to show external actors to the system and how they interact with the system while also showing some sequence in the way that actors interact with the system. Use cases are mainly used in requirements gathering and design phases of the software development life cycle.
  • Communication diagram- Communication diagrams are used to show the interaction between objects through use of sequenced messages that are in a free-form type of arrangement. They are mostly used in the design phase of the software development life cycle.

To analyze the system using objected oriented approach the following UML diagrams are used;

• Class diagram

Figure 6: class diagram

• Sequence diagram

Figure 7: sequence diagram

The class diagram shows the structural or static view of the system while the sequence diagram shows the behavioral or the dynamic view of the proposed system.

The design of the system will be done using the specification document gotten from requirements engineering and analysis. The design will have to adhere to principals of material design to make sure the end design is attractive and unique to the users. Apart from the appearance, interactivity should be a high priority where by user actions like touch are supposed to be considered as the application will be running on smart phones.

Conclusion

The expenditure tracking application will help many users to track their expenditures thus helping people to adapt good spending habits and in the long run the users will be able to save more of their money. The application will also help the users understand what activities are using up most of their income and which are not. For the application to be a success, the development team must follow the laid out specifications and use the agile approach to ensure that the end product is good for every user. The team has to follow the laid out plan to stick to the budge and to be able to follow the specified schedule. This will ensure overall project success.

References

Bahil, T., and F. Dean. (1997). The Requirements Discovery Process, SAND—96-2901C, Sandia National Laboratories, Albuquerque, NM.

Constantinides , C. (2014, July 25). Functional Requirements vs Non Functional Requirements. Retrieved August 20, 2017, from https://www.onedesk.com/functional-requirements-vs-non-functional-requirements/

Kossiakoff, A. and Sweet, N. (2003). Systems Engineering Principles and Practices, Hoboken, N.J., John Wiley & Sons.

MacDonough, M. (2013, April 30). Types of Feasibility Studies. Retrieved August 20, 2017, from https://www.brighthubpm.com/project-planning/56372-types-of-feasibility-studies/

Makar, A. (2016, May 17). How to Make Your Project Schedule Work for You. Retrieved August 20, 2017, from https://www.liquidplanner.com/blog/project-schedule-isnt-working/

Pittet, S. (2015). The different types of software testing. Retrieved August 20, 2017, from https://www.atlassian.com/continuous-delivery/different-types-of-software-testing

Seymour, and Biemer, S. M. (May 24, 2011). Systems Engineering Principles and Practice, 2nd Ed., Hoboken, N.J., John Wiley & Sons.

System Design. (2015, November 15). Retrieved August 20, 2017, from https://sebokwiki.org/wiki/System_Design

Types of Software Testing: List of 100 Different Testing Types. (2017, August 11). Retrieved August 20, 2017, from https://www.guru99.com/types-of-software-testing.html