CONTENTS 1.
Project Proposal ...................................................................................................................................................... 6 1.1 Overview .................................................................................................................................................................. 6 1.2 The End Product ................................................................................................................................................... 7
2.
Requirements ........................................................................................................................................................... 8 2.1 Determining Requirements.............................................................................................................................. 8 2.2 Who will use the product? ................................................................................................................................ 8 2.3 System Overview .................................................................................................................................................. 8 2.4 Overall Functionality .......................................................................................................................................... 9 2.4.1 Invoices ............................................................................................................................................................ 9 2.4.2 Estimates ......................................................................................................................................................... 9 2.4.3 Clients ............................................................................................................................................................... 9 2.4.4 Summary ...................................................................................................................................................... 10 2.4.5 Reports .......................................................................................................................................................... 10 2.4.6 Expenses ....................................................................................................................................................... 10 2.4.7 Settings .......................................................................................................................................................... 11
3.
Research Documents .......................................................................................................................................... 12 3.1 Existing Applications ....................................................................................................................................... 12 3.1.1 Ballpark ......................................................................................................................................................... 12 3.1.2 FreshBooks .................................................................................................................................................. 12 3.1.3 Clarity Accounting .................................................................................................................................... 13 3.2 Data Mining and Web Crawling ................................................................................................................... 14 3.2.1 What is it?..................................................................................................................................................... 14 3.2.2 What are the uses? ................................................................................................................................... 14 3.2.3 What are the benefits to my project?................................................................................................ 14 3.3 Object Oriented PHP ........................................................................................................................................ 16 3.3.1 Frameworks ................................................................................................................................................ 16 3.3.2 Php Data Objects ....................................................................................................................................... 17 3.4 Relational Databases ........................................................................................................................................ 18 3.5 Modern Technologies on the Web.............................................................................................................. 19 3.5.1 AJAX and Javascript.................................................................................................................................. 19 3.5.2 HTML5 ........................................................................................................................................................... 20 3.5.3 CSS ................................................................................................................................................................... 21
3.5.4 XHTML ........................................................................................................................................................... 22 3.6 Security on the Web ......................................................................................................................................... 24 3.7 Development Life Cycles ................................................................................................................................ 25 3.7.1 Extreme Programming (XP) ................................................................................................................. 25 3.7.2 DSDM.............................................................................................................................................................. 25 3.8 4.
Rapid Application Development .......................................................................................................... 27
Requirements Analysis ...................................................................................................................................... 28 4.1 Set Up ..................................................................................................................................................................... 28 4.2 Generating Invoices and Estimates............................................................................................................ 28 4.3 Saving Drafts ....................................................................................................................................................... 28 4.4 Listing Items and Sorting ............................................................................................................................... 28 4.5 Emailing Invoices .............................................................................................................................................. 29 4.6 Exporting Files.................................................................................................................................................... 29 4.7 Adding Clients ..................................................................................................................................................... 29 4.8 Rating System ..................................................................................................................................................... 29 4.9 Calculations.......................................................................................................................................................... 29 4.10 Payment Gateways ......................................................................................................................................... 30
5.
Gantt Chart.............................................................................................................................................................. 31
6.
Project Plan ............................................................................................................................................................ 32 6.1 Model in use......................................................................................................................................................... 32 6.2 Design..................................................................................................................................................................... 32 6.3 Development ....................................................................................................................................................... 33 6.3.1 Databases ..................................................................................................................................................... 33 6.3.2 Login System ............................................................................................................................................... 33 6.3.3 Creating Invoices and Expenses ......................................................................................................... 33 6.3.4 Exporting to PDF ....................................................................................................................................... 34 6.3.5 Generating Graphs .................................................................................................................................... 34 6.3.6 Payment Methods ..................................................................................................................................... 34 6.4 Documentation ................................................................................................................................................... 35 6.5 Testing ................................................................................................................................................................... 35
7.
Testing Strategy .................................................................................................................................................... 36 7.1 Initial Testing ...................................................................................................................................................... 36 7.2 Design Testing .................................................................................................................................................... 36 7.3 Development Testing ....................................................................................................................................... 36 7.3.1 File Generation........................................................................................................................................... 36 7.3.2 Accessibility ................................................................................................................................................ 36 7.3.3 Development Testing .............................................................................................................................. 37
8.
Plan ............................................................................................................................................................................ 38 8.1 What Needs Designing? .................................................................................................................................. 38 8.2 Design Tools ........................................................................................................................................................ 38
9.
Visual Design.......................................................................................................................................................... 39 9.1 Concept .................................................................................................................................................................. 39 9.2 Version 1 ............................................................................................................................................................... 39 9.3 Feedback ............................................................................................................................................................... 40 9.4 Version 2 ............................................................................................................................................................... 41 9.5 Feedback ............................................................................................................................................................... 41
10.
Product Design ................................................................................................................................................. 42
10.1 Page Structure.................................................................................................................................................. 42 10.1.1 The Public Site ......................................................................................................................................... 42 10.1.2 The Private Area ..................................................................................................................................... 42 11.
UML ....................................................................................................................................................................... 43
11.1 Class Diagram ................................................................................................................................................... 43 11.2 Use Case Diagram ........................................................................................................................................... 44 11.3 Sequence Diagrams ........................................................................................................................................ 45 11.3.1 Logging In ....................................................................................................................... 45 11.3.2 Registering ..................................................................................................................... 45 11.3.3 Creating Invoice ............................................................................................................. 46 11.3.4 Creating Client................................................................................................................ 46 12.
Databases ........................................................................................................................................................... 47
12.1 Structure............................................................................................................................................................. 47 12.2 Normalisation................................................................................................................................................... 47 12.2.1 0th NF ........................................................................................................................................................... 47 12.2.2 1st NF............................................................................................................................................................ 48 12.2.3 2nd NF........................................................................................................................................................... 49 12.2.4 3rd NF ........................................................................................................................................................... 50 13.
Entity Relationship Diagram ...................................................................................................................... 51
14.
Database Testing ............................................................................................................................................. 52
14.1 Inserting to Database .................................................................................................................................... 52 14.2 Selecting from Database .............................................................................................................................. 53 14.3 Updating Database ......................................................................................................................................... 54 15.
Registration ....................................................................................................................................................... 55
16.
Login ..................................................................................................................................................................... 57
17.
Forgotten Passwords ..................................................................................................................................... 58
18.
Invoice and Estimate Design ...................................................................................................................... 60
18.1 Design Rationale ............................................................................................................................................. 60 19.
Invoice and Estimate Development ......................................................................................................... 61
20.
Invoices ............................................................................................................................................................... 62
20.1 Invoice Creation .............................................................................................................................................. 62 21.
Expenses ............................................................................................................................................................. 65
21.1 Design .................................................................................................................................................................. 65 21.2 Development .................................................................................................................................................... 65 21.3 Testing................................................................................................................................................................. 65 22.
List Modifications ............................................................................................................................................ 67
22.1 Archiving ............................................................................................................................................................ 67 22.2 Resending Invoices ........................................................................................................................................ 67 22.3 Deleting ............................................................................................................................................................... 68 22.4 Status Change ................................................................................................................................................... 68 23.
Sorting Lists....................................................................................................................................................... 69
24.
Clients .................................................................................................................................................................. 70
24.1 Design .................................................................................................................................................................. 70 24.2 Client Creation ................................................................................................................................................. 71 24.3 Client Profiles ................................................................................................................................................... 72 24.4 Client Modification ......................................................................................................................................... 73 24.5 Rating Clients ................................................................................................................................................... 74 25.
Settings ................................................................................................................................................................ 76
26.
Users Homepage .............................................................................................................................................. 78
26.1 Account Options .............................................................................................................................................. 78 26.2 Income Overview ............................................................................................................................................ 78 26.3 Clients Overview ............................................................................................................................................. 78 26.4 Overdue Invoices ............................................................................................................................................ 79 27.
Accounts.............................................................................................................................................................. 80
27.1 Income + Expenses......................................................................................................................................... 80 27.2 Forecasts ............................................................................................................................................................ 80 27.3 Other Data.......................................................................................................................................................... 80 28.
Accounts Development ................................................................................................................................. 81
28.1 Income + Expenses Graphs ......................................................................................................................... 81 28.2 Forecasts ............................................................................................................................................................ 84 28.3 Other Data.......................................................................................................................................................... 85 28.3.1 Quick Summary ....................................................................................................................................... 85 28.3.2 Client Summary....................................................................................................................................... 86 29.
Confirmation Boxes ........................................................................................................................................ 87
30.
Paying Invoices ................................................................................................................................................ 88
31.
Scheduled Jobs ................................................................................................................................................. 89
32.
Accessibility Testing ...................................................................................................................................... 90
32.1 Browser Support............................................................................................................................................. 90 32.2 Web Standards ................................................................................................................................................. 90 32.3 Screen Readers ................................................................................................................................................ 91 32.4 Resizing............................................................................................................................................................... 91 33.
Evaluation .......................................................................................................................................................... 92 33.1 What Requirements Were Met? ........................................................................................................... 92 33.2 Changes in Design ...................................................................................................................................... 93 33.3 Project Planning ......................................................................................................................................... 93 33.4 Future Developments............................................................................................................................... 93
34.
Conclusion .......................................................................................................................................................... 94
35.
Bibliography ...................................................................................................................................................... 95
36.
Appendix............................................................................................................................................................. 97 36.1 Figure 1.............................................................................................................................. 97 36.2 Figure 2.............................................................................................................................. 98 36.3 Chart 1 ............................................................................................................................... 99 36.4 Chart2.............................................................................................................................. 100 36.5 Chart 3 ............................................................................................................................. 101
1. PROJECT PROPOSAL Student: Richard Edwards Project Title: Invoice and Accounts Management System Supervisor: Harry Aspinall Course: Software Development with Multimedia
1.1 OVERVIEW After discussion with two small scale companies in the IT industry, it came to light that there is only a small amount of applications available to them which offer simple to use account management tools and invoice tracking. This is due to little funds available to spend on an expensive product, which is often too complex and big for a smaller business to need. My project therefore is to develop an application which will assist them in keeping track of records such as: Invoices, Expenses, Estimates and Accounts. Having come across this problem, I took a look at what was currently available, and my findings were surprising. There are many companies out there which will offer services to deal with your accounts for you, however there were very few available applications available which one could use themselves, most of which only addressed one problem, or were years out of date. This quickly caught my attention and I went on to address other issues linked into this. The results of my research into the same issue proved that this was indeed an unfilled gap in the market, this was becoming more obvious to me when other people I know that run small business or freelance said they had similar issues. This has made me quite interested in the topic, and has motivated me to develop a solution. The product being developed is to have the following key aims: • • • • •
To be able to generate Invoices in PDF format. Ready to email or print. To allow the user to add his/her own expenses into the application. To aid the user in calculating their accounts based on income and expenses. To give the user estimates and ratings on their clients, to aid them in future decisions when picking clients. To give reports and statistics of their accounts.
Since research has been done into the areas of security and PDF generation, these tasks will not be as difficult as originally thought. The PDF generation can be done using the Zend framework. By undertaking this project, I have already learnt a lot and feel I will learn a lot more about the development of large scale web applications, which is an area I am very interested in and an area I wish to take to more than a hobby.
6
To be successful in this project, research is key. My core research areas have included: • • • • • • • •
Object oriented web programming. Modern technologies on the web, such as AJAX, HTML5 and CSS3. File generation methods. Security on the web. Development Life cycles Data Mining and Web Crawling Relational Databases UML (Unified Modelling Language)
Although heavily web-based, the overall application will relate well to both sides of my course. The application will make use of the skills I have attained in programming throughout the last 3 years. It will also require a lot of project management skills to assist myself in doing the project and to offer some project management support in the application itself. Finally, the product will be web-based, meaning my multimedia and design modules will come to light when designing and considering usability on the web, and data will be stored in a database utilizing my SQL knowledge. All of this will group together to improve my own project management skills and understanding of how large scale applications work. I will have acquired new knowledge in the area of web development and usability.
1.2 THE END PRODUCT The end product of the project will offer full support in sending invoices and adding expenses to what could potentially be an entire accounts system. Features will include:
Creating new Invoices and Estimates to email to clients.
Searching and filtering invoices, estimates, expenses, clients.
Add new clients and contractors.
A clients and contractors estimations and ratings system.
Reports on profit and loss, expenses and client costs.
Tax calculations, including tax returns required.
Settings allowing customization of invoices and estimates.
There will not be a high level requirement to run the application. It will be made usable for IE6+ browsers, and require JavaScript to be enabled. To make use and download PDF files, it would be suggested Adobe Acrobat be installed. It will not be resource heavy or graphically heavy, meaning system requirements will be very low. An ideal screen resolution would be 1024x720. The design of the application will be simple, easy to use, and heavily focused on usability for the user. This will be done using CSS. Other technologies I will use include Ajax, PHP and JavaScript. This is a result of research and deciding on the best language options to use for each part of the website. 7
2. REQUIREMENTS 2.1 DETERMINING REQUIREMENTS Having discussed the potential of the product with the two interested parties previously mentioned, a list of requirements will be drawn up. These requirements will be ranked using the MoSCoW prioritization method.
2.2 WHO WILL USE THE PRODUCT? The outcome of this development will be a browser-based accounts management system. The idea for this development came from two potential clients. Both of these clients run small businesses, both in the computing industry. They stated that they look for simple to use invoice generating and book keeping tools which are not filled with loads of content which does not apply to the smaller business. The two clients mentioned both run their own businesses. These are both small businesses, one of which is a Web Designer (PixelPixel) and the other runs an IT Solutions company (Gwyddon). Both clients have similar views on what they would desire to be a part of the application. PixelPixel finds that their clients are often late paying invoices, and struggle to keep track of all their clients as a single person. Gwyddon are well established in their local area and has a few more employees, but do all their accounts with standard PC software and keeping track of income and salaries can be difficult. I spent time discussing the application with both clients, who both had the same overall desire, but a few unique ideas cropped up which when mentioned to the other party, both agreed would be beneficial.
2.3 SYSTEM OVERVIEW The application itself will have two options of use. Option 1 – The user may download a package which they can install on their own machines and use locally, this would be done via an installation page asking for database details and other important information to set it up. This would mean only a few select users, possibly even just the one, would have access to the application at any one time. This is not required but could be considered. Option 2 – The user may request an account to gain access to a server which hosts the application for them. This would mean that multiple users would be using the same server and files at any one time; the amount able to do this varies depending on server capabilities. The users in Option 1 will require some familiarity with MySQL databases and how to fix issues around databases and hosting. Whereas those users who fit into Option 2 will not require as much experience, they will need basic computing skills so they can access the site and navigate themselves around. 8
2.4 OVERALL FUNCTIONALITY 2.4.1 INVOICES These must be viewable in a list, which may be sorted by date, value and customer name. This is important so that the user can find invoices with ease. In the list of invoices, the user must be able to mark each invoice based on its status, such as Payment Received. This is an essential part, due to its effect on other functional areas, such as the reports. The user must be able to create a new invoice. The user inputs data into a form, including each task and the cost for the task; which upon submitting can be converted into a PDF file or saved as a draft for use at a later date. This is an essential addition to the application. Clicking on a draft will allow the user to view what is currently in it, and then allow them to convert it into a PDF file and email it as required. Sending reminders will be automated and not an essential addition however it would be nice to notify people by email that they have a payment to make in X amount of days. A button to allow the user to delete an invoice is also required, this will prevent invoices piling up that are either mistakes, or were no longer needed. This is also an essential feature.
2.4.2 ESTIMATES Estimates will have the same functionality as invoices, but will not be linked in with any of the reports or statistics. Estimates will be specified as an estimate when it is sent to a client via email.
2.4.3 CLIENTS Adding a client will be done via a menu where the user inputs client information such as contact details. This is not vital to the project, but would be very useful to save time on sending invoices on frequent occasions. A client rating system will be integrated to allow the user to rate their clients for each transaction and service. This will allow the user to know which clients are not performing well for them, or are often late paying. This would be a nice to have feature and would aid the user in improving their business. A list of clients able to be sorted based on certain criteria such as rating. This list is vital as it allows the user to view all their clients and aid in picking one to use. Deleting a client needs to be a feature which is included so that clients no longer dealt with can be removed to keep the lists tidy.
9
2.4.4 SUMMARY The summary section of the site needs to include overall figures and information. These sets of data and quick links are to give the user a simple overview of their accounts. These are all preferred features to be in the application. Listed below are the features to be shown: Links to: Create Invoice Create Estimate Add Expense Add Invoice Add Client Statistics: Total Income Total Expenses Profit over time Total clients Top clients
2.4.5 REPORTS The reports category is all very important to be included into the application, without this the application would just be storing invoices without providing any useful information to the user. The reports will cover multiple areas of a business including profit and loss charts, income over time and a breakdown of costs. Profit and loss graphs will show the profit of the company over a selected time period. Total sales per month will show purely the income from all invoices. Total outstanding payments will show the cumulative total of all invoices which are yet to be paid. Outstanding expenses will display the total of any debts of payments you still have to pay. The user will be able to export all the data in the following media formats: PDF and Printed.
2.4.6 EXPENSES Very similar to Invoices but with a few differences; the differences are that the expenses are negative income, which means the totals need to be treated differently in reports and instead of being linked to a client, they will be linked to a category of costs (i.e. Rent, Utilities) The main difference is that if the expenses are the result of work for a client, then the user may wish to turn them into an Expenses Invoice to be sent to the client, this will be possible by the click of a button. However this is not a vital feature, the user can just delete the expense or not include it if they plan to charge it to the client. 10
2.4.7 SETTINGS A settings section will be included, as an important part, to provide an interface for the user to personalise their use of the application. This includes the following features. Uploading company logo will be possible by a simple upload form accepting useable image types (png, gif, bmp, jpg). This logo is what will be displayed on the invoice headers and in the website header of their account. This feature must be included. When sending emails with the invoices in them, the user may wish to customise what this says, this can be done in the settings section of the website and is a feature I would like to include, however not important. A section of the site will be a form where the user can put in information, or edit information, about their business. This needs to be included as this information needs to be on the invoices. The user will have access to payment portals such as PayPal, they will need to specify their PayPal email address somewhere so the payment goes to the right place. This is a feature which does not affect the application itself, but would be a nice addition to speed up payment times.
11
3. RESEARCH DOCUMENTS 3.1 EXISTING APPLICATIONS The online idea of an online accounts system is a very niche area. There are only a handful of such web based products available. The reasoning for this I believe is that; large scale corporations will have other companies deal with their accounts, or have a unique system built for them and smaller companies and freelancers will most likely be doing a lot of it by hand with available software, or using multiple different software products. Looking into what existing online systems there are was a shock; there are two main products out at this time, one of which is called Ballpark and the other FreshBooks. These are both US based services.
3.1.1 BALLPARK This product is less of an accounts management system, but heavily focused on the ability to send Invoices and Estimates to clients. Much more focused at the smaller scale company or freelancer. It also allows other staff within the company, once supplied with an account, to comment on the invoices and estimates before they can be sent. Offering PayPal as a payment method allows them to track when a payment is sent so the user can be notified that they have been paid. However this appears to be the only way which it can track payments, other payment methods could be added to allow clients to pay via other methods such as WorldPay. The site also does not offer any management tools or much statistics. www.getballpark.com
3.1.2 FRESHBOOKS Freshbooks offers a complete accounts management system, as well as a small range of project management tools. The ability to send reminders and recurring invoices makes this product different from others. They accept multiple payment methods, all of which are traceable. When a client receives an invoice, they can view it online along with other invoices of theirs. Time tracking functionality is included. This allows the user to input time spent on certain projects and on which day it was. This assists with producing reports on the time a projects taken and its costs. The category of Expenses allows you to note any expenses and whether they need to be billed to a client or not. This application is very complete in functionality, however is targeted to the larger business. Some aspects of this may be considered for my application, however the main features have already been identified within the requirements. www.freshbooks.com 12
3.1.3 CLARITY ACCOUNTING This is a developed accountancy application, and does not deal with generating invoices or sending of quotes and costs. It relies on you to enter all the data of funds received and payments expected. It does however; generate a lot of data and graphs to show profits, loss, balances and transaction information. www.clarityaccounting.com
13
3.2 DATA MINING AND WEB CRAWLING 3.2.1 WHAT IS IT? Data Mining and Web Crawling are methods to retrieve data from the internet’s wide range of site and databases. Think of it as a way to provide data from one location, to many other locations. There is a difference between the two methods: “A web crawler is a relatively simple, automated program, or script, that methodically scans or "crawls" through Internet pages to create an index of the data it's looking for” (Kaefer, H. 2009). Whereas data mining is when; “algorithms that employ techniques from statistics, machine learning and pattern recognition are used to search large databases automatically” (Anissimov, M. 2009). Data mining is sometimes referred to as ‘Knowledge Discovery in Databases’ (KDD), this is the same process just with a different name.
3.2.2 WHAT ARE THE USES? Web crawling is used in search engines. They are designed to search the entire internet that they know to exist and pull up and display the pages which they feel suits your search criteria best. Web crawlers are also known as spiders or bots, these bots visit sites on a frequent basis to gather the latest information, well known bots include one of Google’s which is often found reading forums and websites to store information regarding the content of the sites. Other uses include research needs, such as to search the internet for patterns of developments or uses of data and can be used to predict future patterns. Data mining on the other hand is used more locally. To search a local database for a website, such as a retail website, to suggest items to the client which it believes they may also be interested in. This is a great way to achieve more sales and is often very accurate.
3.2.3 WHAT ARE THE BENEFITS TO MY PROJECT? Within my proposed project there are a few possibilities of including data mining and web crawling methods. This includes such features as:
Currency conversion on invoices based on the location of the client. So if you enter £100 as the cost of services, when generating the invoice it would look up the current exchange rate for your clients currency and display it in that currency. This makes evaluating costs much easier for your clients. Tax costs vary depending on the country you live in. Other software dealing with invoices often requires you to enter the tax yourself, or has a fixed tax cost. If tax values could be found based on the users location, it would save them having to enter this value. However this can easily be replicated by having the user enter the tax values in a settings page and store this for future use. 14
I believe this could be a great addition to my application to develop my skills within the area, however due to the complexity and further research required in order to successfully achieve this; I feel it would take up too much time and suggest it as a further improvement after the project is completed.
15
3.3 OBJECT ORIENTED PHP Object Oriented PHP (OOPHP) is an object based method of developing PHP applications. PHP is very often used in standard means without being Object Oriented. This is acceptable; however by using object oriented methods development can be much easier. PHP5, released 2004, allowed the use of objects in PHP. “Object Oriented Programming in any language is the use of objects to represent functional parts of an application and real life entities.” Argerich, L. (2003), These functional parts as they are named by Argerich could be considered the construction of invoices, creation of users and reports within my project. OO PHP can be said to be better than standard PHP in that the use of objects make the code much easier to modify and understand. Much like the same reasons OO programming languages have increased in popularity. PHP will be the key language used in the project; this is due to the new developments in object oriented use of PHP and an area in which I wish to develop my own skills within.
3.3.1 FRAMEWORKS PHP alone is a powerful language for web development; however there are additional frameworks to make using PHP much easier. One of them being the Zend Framework. Zend was developed to “provide a lightweight, loosely-coupled component library”[1]. It offers Ajax support and has been thoroughly tested to make sure it is safe to use and easy to use. The libraries include such aspects as; Mail, Web Services, Authentication, Session Management and Localization. One key section of the Zend Framework that I will find very useful to my application development is the Zend_PDF component. This will allow me to create the PDF format invoices from the information supplied by the user. Another common framework is CakePHP. Like other frameworks, it is built to make development easier and faster in PHP applications. “CakePHP is a rapid development framework for PHP that provides an extensible architecture for developing, maintaining, and deploying applications. Using commonly known design patterns like MVC and ORM within the convention over configuration paradigm, CakePHP reduces development costs and helps developers write less code.”[2] CakePHP will not be required for my project as Zend covers the functionality I need. On top of the PDF generation in Zend, there is another library which makes PDF generation easier. This library is FPDF. Although not a very well supported library it will do everything I need to do to generate a styled invoice.
16
3.3.2 PHP DATA OBJECTS Using a MySQL database with PHP has, in the past, been considered to not be that secure. This was due to the way queries were completed frequently without the developer making sure the input data was exactly as it should be. With PHP Data Objects (PDO’s) this has become a little more secure and is considered the best way to deal with database communications within PHP. PDO’s require PHP5’s Object Oriented features to work. PDO’s allow the ability to connect to different types of database. PDO’s allow a multitude of different features which are a benefit over the previous connection methods. This includes stored procedures and transaction management, which could both be highly beneficial to a development like OAMS.
17
3.4 RELATIONAL DATABASES “A relational database consists of a collection of tables that store particular sets of data.” Powell, K (2009) Relational databases are just like any other database, but the structure differs slightly. This difference is that tables in a relational database have a ‘relationship’ with others, such that an Item in a table may have an Item ID, this Item ID will then be used in another table to link the two together without actually being joined as one. In theory this makes looking for the right data easier and more precise. Relational databases have been about since the early days of databases within businesses. The use of them in internet applications today is seen as standard. Some people believe the relational database is becoming less popular and that non-relational databases are actually more efficient with the scale of them in today’s World Wide Web. Tony Bain (2009) states "if you want vast, on-demand scalability, you need a non-relational database”. This statement is recent, looking back a few years ago; it was said by Gilfillan, I (2002) that “large databases can easily get out of hand when badly designed, leading to poor performance”. However databases can now be designed well without the need to be relational. Relational databases will be required for my projects development; this is due to the type of data and the frequency of its use in reports being generated by the application. Instead of storing all account data in one table, it would be more efficient to store them in their own relevant tables and link them together by the user whose data it is.
18
3.5 MODERN TECHNOLOGIES ON THE WEB 3.5.1 AJAX AND JAVASCRIPT “AJAX is not a new programming language, but a new technique for creating better, faster, and more interactive web applications.” W3Schools.com (2009) By using Ajax you can improve the speed of an application, as it reduces the amount of requests sent to the server. So instead of refreshing an entire page, just one section of the page will be updated. This fast loading of sections of a website cause a greater feeling of having improved interaction with the site, you can create drag and drop windows, auto complete forms and tabs to content without much complication. “With AJAX, your JavaScript communicates directly with the server, through the JavaScript XMLHttpRequest object.” W3Schools.com (2009) Ajax uses the JavaScript XMLHttpRequest to send a request to the server for information without the browser refreshing the page. The reply is often then updated on the html page by picking an object on the page and updating its contents. Ajax is used frequently in Web 2.0 applications; these are applications which offer fast and efficient interactivity. The iGoogle (http://www.google.com/ig) website takes advantage of this, allowing the user to personalize their view of it by dragging and dropping windows into whatever order they prefer. Ajax is also used for shopping carts on websites. By clicking the ‘Add to Cart’ button, without even reloading the page, it will add the selected item to your cart, and notify the user it has been added. Web applications are becoming more user friendly due to the popular interest in Ajax. Why work through 3 pages to purchase something, when it can be done with one click? Because of this, less work needs to be done to create the applications, which decreases the time taken to develop them. For those who are hosting websites which are rich in Ajax less bandwidth is required for each request. This is due to the fact that the content to update a part of the site is going to be less than sending that data along with the rest of the web page contents. Thus allowing more synchronous users at anyone time to be using the site, without difference in the pressure on the server. This would be a benefit to me when building my new application, if I did not have to reload the images on the site and all the menus every time a page is changed, it would speed up the production of data to the user. There are weaknesses though. If an application requests something from the server without the browser reloading the page, you will struggle to navigate back to where you were using the back button. There are new ways being developed which will allow you to make use of the back button, one popular way, is that when you click a link instead of calling the JavaScript right away, attach a # and a number onto the end of the URL in the link, this will stop the page from reloading, but a JavaScript script can pick up this suffix and deal with it as it needs to, and allows a user to make use of the back button. This method is supported by many users of Ajax including Adrian Gondelle (2008) who states:
19
“Another big problem that anchor navigations fixes, is the use of back button in your browser. Browsers don’t save the AJAX petitions in the history, so you can’t navigate to the back or next sections. However, with the anchor navigation method you can do it. ” If a user does not have JavaScript enabled, the Ajax components simply won’t work, they can click links all day and it will do nothing. This would pose as a severe issue if I was to incorporate Ajax into my development; I would have to develop a non-JavaScript based link system for those with JavaScript disabled. There are new libraries being built to support Ajax theory all the time. A popular one is ‘jQuery’. John Resig of jQuery.com states: “jQuery is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. jQuery is designed to change the way that you write JavaScript.” These developments offer easy to build rich applications for website. This includes shopping carts, sliding images, Ajax searching methods and many more Ajax based applications. jQuery provides a user interface library known as jQueryUI. This library, or framework, provides a large number of useful interface widgets which will be useful in the application. One in particular is the calendar which will allow users enter dates in the correct format and it also provides the user with an easy way to find the correct date. As well as using JavaScript for data manipulation, graphs need to be generated from statistics. Originally Flash was to going to be used; however due to researching into other ways to draw graphs from dynamic data two other libraries proved a better choice. One of these libraries was gRaphael, this library provides many graphical functions from drawing tables to drawing images of any shape. gRaphael is suitable for the requirements, however another library known as Flot is an add-on for jQuery which is purpose built for drawing graphs and offers additional functionality such as time based axis’ and legends which would be hugely beneficial to the project.
3.5.2 HTML5 HTML5 is the next development of HTML and is the core mark-up language of the internet, where a mark-up language is a language used to display content to the end user. The aims of HTML5 are to turn HTML into a richer means of development than it currently is. HTML has become less and less used due to jQuery and CSS developments. With a new HTML version, it will mean content such as Flash and other RIA (Rich Internet Applications) will be reduced. HTML5 is to offer new elements to be used, which will not replace, but be another option to, the current elements. An example are new elements such as <footer> and <audio> to specify that the elements belong to that category, instead of using CSS to place a footer, and embedding audio the current way. The syntax proposed in HTML5 is not based on the same markup methods as previous HTML which was SGML (Standard Generalized Markup Language), it will however be compatible with previous HTML versions. 20
HTML5 is still under development, however some aspects work in current browsers such as Firefox and Google Chrome. Due to this nature of the language, it will not be suitable to use it within my project currently.
3.5.3 CSS Before HTML 4.0 all page styling had to be done within HTML tags, which was not an efficient way of doing styling of a website. CSS was then developed by the World Wide Web Consortium. CSS is a separate file with the extension ‘.css’ which contains all the formatting and styling details of content on the website. CSS2 is the current standard for CSS development, however CSS3 is being developed and will provide many more features which developers have been wanting for a long time, and these include improved opacity options and multiple background images within one style. The main ways of using CSS are to style particular sections of a website by making use of ‘classes’ and ‘ids’ of tags. For example, instead of using a table to align content, a ‘div’ may be given certain dimensions and placements for the content to be placed where it is desired. // The CSS for an ID named ‘divclass’ #divclass { Float: left; Width: 400px; Height: 100px; }
//HTML to place in the html file <div class=”divclass”> content to go in the div </div> The result of the two will be an area of size 400x100 pixels which sits at the left of its container, in this case the browser. The content within this area will read ‘content to go in the div’. As previously mentioned, you can make use of ‘ids’ as well as classes. There is a difference between the two. This difference is that an ID is a unique identifier of the object it is linked with. Having two tags making use of the same ID will cause problems with such things as forms and JavaScript. If you wish to use the same styling variables more than once per page, then you should use classes.
21
As an example, to define a Class based style, the CSS would look like so: .divclass { ... } And the HTML: <div id=”divclass”> content to go in the div </div> If you wish to redefine HTML tags such as <p> (paragraph) or <hr> (horizontal rule) or even <b> (bold),<i> (italic) and <u> (underlined), then you do so without a ‘.’ Or ‘#’ before the tags name. p{ Line-height: 300%; } The above would make the line height within a paragraph by 300%. Any CSS for a defined tag will override the default styling. CSS should be used on any website which includes its own unique styles. My project will be web based and therefore require CSS to develop the layout and styling of individual elements on the website.
3.5.4 XHTML XHTML (Extensible HyperText Markup Language) is based around use of XML and HTML. It follows rules from XML, such as case sensitivity. It is in summary a strict version of HTML. XHTML 1.0 is equivalent to that of HTML 4, and will be used as a standard through the development of HTML 5, so that HTML 5 will contain the same features that XHTML does, and that XHTML 2 would have. XHTML requires that all elements are closed. HTML will allow the opening of a new paragraph using <P> without requiring it to be closed, where as with XHTML you must close it with a </p> tag. XHTML also requires that all elements are nested correctly, in that elements should not overlap, an example of this is: HTML - <p>This is an <i>Italic Word.</p></i> XHTML - <p>This is an <i>Italic Word.</i></p> Attributes in XHTML but be wrapped within quotes. HTML allows ‘color=red’ however in XHTML this must read ‘color=”red”’. Any elements on the page which are empty, often ‘<br></br>’ for a break in the page, must be closed off within one statement, such that it should read ‘<br />’. 22
These requirements are not in place to make the language any better, nor to improve functionality, but to force users to develop code which is complete and marked up in the right way. XHTML 2.0 was beginning to be developed, offering much richer features, which have been mentioned in the HTML5 research, this is due to the XHTML 2.0 development being halted and being included into HTML5. The XHTML 2.0 developments included XForms which are XML based and display differently based on the device viewing it. Events in the DOM (Document Object Model) are to be replaced by XML Events and frames to be replaced by XFrames. Navigation list types, changes to alternative text in images and headings which automatically decide which level to use based on their position in element nesting. The HTML on my website will be written to meet the criteria of XHTML 1.0 Transitional. This covers code being in order and closed properly, along with using the correct element attributes.
23
3.6 SECURITY ON THE WEB There are multiple risks that have to be considered when developing application to be distributed on the World Wide Web. This covers a wide range of interception attacks; a transmission of data being intercepted by an unwelcome party, browser risks; insecure versions of java environments for example, and issues with the server itself which may be open to unauthorized users. With consideration to the operating system of the server being used for the development of my application, the W3 organisation says “the more powerful and flexible the operating system, the more open it is for attack through its Web (and other) servers.”. The results of their findings say that the less features and less powerful a machine is; the less points of access to get into a system. The operating system of the server to be used is Linux, which W3 would consider more of a risk than some others; however it is very uncommon to see servers available which are not Linux or Windows based. Cookies may be stored on a user’s PC to store login details to a website, or even personal details. This information can be intercepted when it is transferred to the server for checking. To prevent this, a method known as hashing is used to encrypt the information before it is sent. It is encrypted using a key which is only known by the server and the person sending the information (in this case defined in the script doing the hashing). This means if the data is intercepted, the false receiver will not be able to decrypt it. Other ways of encryption would be to make use of an SSL certificate, which offers improved encryption and security for the transmission of data. This is commonly seen on e-commerce websites and may prove beneficial for the sale of my end product, however this would be a future development and not part of the project itself. The use of JavaScript can cause a lot of issues with the functionality of your site. It is possible to read JavaScript in the page source code, so anyone can get an understanding of what it is doing, assuming it is not communicating with a server, the user may put JavaScript code into the browsers URL bar and run it, this acts as if it is running on your website and can cause the modification of form data and so on, not a severe issue as it is client-side, but it could have a knock on effect to your websites functionality. A DDoS (Distributed Denial of Service) attack is when a large amount of requests are sent to a server to disable it from functioning correctly. This is usually done by one machine which communicates with a large number of machines at one time and all these machines send requests to the web server. This causes the server to run exceptionally slow, usually resulting in a time-out error being returned. This type of attack is not possible to prevent as it is externally based. SQL injections are popular ways to damage a database where use input can be entered. Such injections include attempting to append “OR 1=1” to a select query so that all information from the database is selected and potentially displayed to the user. A more severe situation would be where the user can force data to be inserted into a database, which could potentially be displayed to all visitors of the site causing malicious code to be run. It is imperative with my project application that the database is secure, I must ensure all data entered into the database is stripped of any html tags, this prevents code from being run when it should not be. 24
3.7 DEVELOPMENT LIFE CYCLES Development life cycles define the way that software will be built; incorporating planning, development, testing, fixing and releasing. Over the years new life cycles have come about and some of the older ones are still a lot better to use for some types of software. It is better to choose a life cycle to suit the software being developed than to stick to one life cycle and risk the quality or security of the software.
3.7.1 EXTREME PROGRAMMING (XP) XP is an Agile Method life cycle, it is one of the earliest to be devised and is one of the most common to use. XP is heavily team based; everyone within the team has a role just as vital as everyone else. It begins by the client and a potential end user designing the requirements they wish the application to have. The programmers will predict how long it will take based on the complexity. The process is very client focused, the client must tell the programmers exactly what they want and provide a plan for the project. This puts the project itself in the hands of the client. Throughout the development of an application testing is done frequently and at all stages. The product is released to the client when it matches their requirements, if the client then decides more needs to be done they must say what and how and the teams will include this and return it to the client and so on. Design is continuously improved to suit the requirements of the software being built. As an agile method, it is often used to improve upon already working code, so that fixes and releases can be given out quickly. Little documentation is done with the software itself, code may be commented but core documentation is not necessary.
3.7.2 DSDM DSDM is used for projects which have set time frames and budgets. The DSDM life cycle consists of three phases. These phases act as a structure to which the project will follow. These are:
Pre-project – this stage ensures that funding is available and that the time frame given is reasonable. Project life cycle – made up of four stages. These stages are: o Study – Checks for suitability of the life cycle, provides a project plan and a requirements specification. o Functional Model – The outcome of this stage is to provide a functional version of the program, or a prototype. o Design and Build – This stage includes the designing of the application and testing methods to be used and tested. o Implementation – The final implementation is given once user feedback has been received.
25
Post-project – Maintenance of the product and keeping track of it to make sure there are no errors which may arise in the future.
To provide a product that is exactly what the user wants, the users work with the developers to provide decisions when they are needed. Contrary to this the team need permission to make decisions if there is an issue that is detrimental to the project. Like XP, the software is released when it is thought that it is ok to do so, this allows frequent testing and feedback from the users which can be used in the next development. Any changes which have been made should be made reversible in a case that the user changes their mind about a particular feature. DSDM makes use of multiple techniques which assist in make sure the project goes as planned. One of which is Timeboxing. Timeboxing is the act of separating the project into manageable chunks which each have a cost and time limit. This makes sure a product is completed in time. MoSCoW is a way of measuring parts of the project by importance. These are:
MUST have SHOULD have COULD have WOULD have
The positive aspects of a DSDM model are that the users have a lot of interaction with the development of the product and that the product will be delivered on time. Negatives would include that some requirements may not be included due to them not being seen as must have or should have parts of the MoSCoW method.
26
3.8
RAPID APPLICATION DEVELOPMENT
The RAD life cycles promotes user involvement, lots of testing at every stage whenever possible and like DSDM, the reversibility of developments. The steps taken to develop an application using RAD are:
Prototype software – a functional but not fully implemented application to give the user an overview of what the end product will look like. Implementation – an implementation of the actual software. User training – the users of the software are trained in how to use it. Review – gather feedback from the users of the application Implementation – If the user’s feedback is negative, or need improvements, then the implementation step is revisited.
The members of a team which use the RAD life cycles must all be experts in their field. They have to be confident in the work they are doing and understand well how the RAD life cycle works. This is vital to getting the software produces rapidly. The team members must have the authority to make decisions when necessary. Teams are smaller than that of XP methods, but may include owners of the company who will take part in development and testing instead of just overlooking the project. Users of the end product will also be a part of the team to give advice and decisions. The team is considered as a whole team, no individual members will gain any praise over others for their work, and this keeps the entire team motivated and co-operative with each other. RAD is focused more towards projects which can be split up into smaller sections and separated between teams, or small projects which one small team can handle. Projects are time fixed and do not contain a strict list of requirements, as much as possible is done in the time frame. RAD is not suitable for safety critical applications, this is because of the set time frame, and such applications need to be complete and fully tested multiple times to make sure the application will function as required. RAD’s fast development and small time scales would pose a severe risk to such applications.
27
4. REQUIREMENTS ANALYSIS 4.1 SET UP To begin making use of the application, the user must follow some set up instructions. This is so that the environment can be custom built to suit their needs. The initial stages of this will require the user to enter information such as business information and contact details. The user may also upload a company logo which will be put on the invoices when they are generated. To store this information, I will be making use of PHP and MySQL to input the data into a database on the server.
4.2 GENERATING INVOICES AND ESTIMATES To create an invoice to estimate, the user must choose to do so; the user then inputs information about the cost of items or services and the client’s information. This can be auto filled from picking an existing client from a drop down box; done using Ajax technology to save the page from having to be refreshed and potentially emptying other contents of the form. Once the input fields are complete, verified by use of JavaScript to confirm the required fields are filled in, the user may generate a PDF of the invoice or estimate. The PDF will be generated using the Zend Framework as this was found as a feature of the Zend Framework during research into PHP frameworks. Once the PHP script has ran and created a PDF, it will be saved in a temporary folder which the user may then view it and chose to send it, save it or delete it.
4.3 SAVING DRAFTS Saving as a draft for later use will move the file form the temporary folder into a drafts folder. This PDF file will be given a unique name, created by generating a random string of 12-16 characters inclusive of both numbers and letters. This name will be stored in the database using PHP along with the client’s details and invoice details so that it can be later found and sent, edited or deleted.
4.4 LISTING ITEMS AND SORTING Each of the clients, invoices, estimates and expenses sections of the application will require that the user may view the items in a list format, and be able to search through them. This will be done using PHP to retrieve the information and display it accordingly. To edit or refine what is shown to the user, a drop down box will be used to specify any limitations or categories that the user wishes to refine by, an example would be ‘sort by client name’. When highlighted a JavaScript function will be called to sort the information in the list based on the name of the client. This could potentially be done using the jQuery framework as it would provide Ajax like functionality and allow communication with the database.
28
4.5 EMAILING INVOICES When a user decides to send an invoice to the end user, then the use of a function known as ‘mail()’ will be used. This function belongs to the PHP library and can be passed parameters containing information for the subject, who to send it to, whom to specify it being from and the body of the email itself. The Zend framework offers emailing functions which will make structuring and adding attachments to the email much easier. Zend has an inbuilt object known as Zend_Mail, creating a new object of this allowed me to pass information to default variables of the object, such that I could use the function “addAttatchment($var)” to simply attach the file stored in the variable $var.
4.6 EXPORTING FILES If a user requests to save any information to their PC and wishes to not save a PDF file, they will be able to export to an XML file using the Zend Framework. This xml file can be viewed in such applications as Excel. This feature would be beneficial to exporting tabular data or reports regarding the profit and loss of the company.
4.7 ADDING CLIENTS Adding clients to the users account will provide them with multiple additional tools. The client is stored in a database linked to the user using PHP. The client is also part of a bigger system used for rating clients based on their performance.
4.8 RATING SYSTEM Once a client is added to the database and linked with a user of whom they are a client of, the user may rate their client after each transaction. This rating will provide an average performance rating; allowing the user to pick and choose clients more suited to the type of project required. Once a transaction is complete, the user may rate the client on some key variables in the success of a project. These are: Time taken, Budget, Communication, Quality of product. When rated the existing information is retrieved and included to provide an average rating which is displayed to the user. This assists them in picking future clients.
4.9 CALCULATIONS Using PHP, information will be taken from the database and displayed to the user in a table based display. This will sum up all costs and income, providing this information will allow a calculation to be done which will tally up the total profit or loss of the company over a specified time; one week, one month or one year.
29
4.10 PAYMENT GATEWAYS When a user sends an invoice to the client, a button will be displayed allowing the client to pay by Paypal instantly. This could persuade the client to pay there and then due to its simplicity, allowing transactions to be processed quickly. Paypal supply an API and files which will receive a response from a specified Paypal account that a payment has been sent, it will also email you to confirm success or failure of payment transactions. The users Paypal account must be set up to use these files.
30
5. GANTT CHART To plan the project accurately and to provide an estimate of regular completion dates, a Gantt Chart will be used. The chart shows each small task which needs to occur to result with the end product. The tasks are split up into categories and dependencies are added so that a timeline can be built. The initial Gantt chart can be found in the Appendix (See Chart1).
31
6. PROJECT PLAN 6.1 MODEL IN USE It is a difficult choice between two development life cycles, Rapid Application Development (RAD) or Dynamic Systems Development Method (DSDM). The two both offer some similar aspects, and also some very differing aspects which would both fit into what I aim to do. RAD suggests that there is not a strict list of requirements, and that as much as possible is done within a time constraint, which is true for the project being undertaken, however DSDM requires that there is a lot of communication between the developer and the client so that the product is built to a standard that the client is happy with, and is involved throughout the process. Both of these are true for my development process. Due to the nature of the project, the chosen life cycle will be DSDM, this will ensure my end product meets the clientâ&#x20AC;&#x2122;s needs and is also finished on time. DSDM allows the project to be split up into smaller parts which is ideal for a small team or individual.
6.2 DESIGN The design of the projects product comes in multiple stages. The initial stage will be to model the product using UML notation. This notation will demonstrate communication between each class, or file, and what functionality the class or file will have. This method provides advantages over simply writing the files and building it as the development goes along, as it can allow the developer to forecast any problems that may arise and deal with them in the design stages instead of having to face them half way through development. The secondary stage of design is the visual design of the application. This includes webpage design, the flow of the website by use of navigation and structure of folders and files. This stage is based upon the UML modeling in that the file structure should be based upon the requirements specified in the UML diagrams. The UML diagrams will be constructed using the application Eclipse. Eclipse is to be used as it contains many features and support for the development code that I will be using. This will assist me in making any changes and speeding up the process in which changes are made as all code and design diagrams will be within one single application. Eclipse also has additional plugins which assists in the development of code from a UML diagram, and vice versa. Secondary stage design will consist of use of Adobe Photoshop to design the web layout and colour schemes. This stage will require some time to get the right appearance for the application. The design needs to impose feelings of trustworthiness, authoritativeness and professionalism as well as ensure the user that it is a secure, safe and functional application to use. The site and internal pages of the application need to be easy to navigate around and simple to understand what is being displayed. The design process is to be completed by mid-January to allow adequate time for development and testing over the following 8 weeks.
32
6.3 DEVELOPMENT 6.3.1 DATABASES The databases used in the application will be developed in MySQL. This form of SQL has been chosen as it provides more functionality with PHP that some other database types. MySQL is usually very insecure, however in PHP there has been recent development of PHP Data Objects (PDO’s) which are used to connect to a MySQL database in a secure manner. These PDO’s also offer transaction management features as demonstrated in my research, which will prevent issues if the application is used by a large number of users. Databases need not be built until they are required; however a brief plan of the core tables needs to be prepared to provide a plan to work towards. These will be created using the PHPMyAdmin interface provided with my hosting provider, allowing fast and easy table creation and editing.
6.3.2 LOGIN SYSTEM The login system, like much of the site, will be built using PHP. This is to allow the use of PDO’s to connect to the database and check credentials in a secure manner; this will be accompanied with md5 hashing. All these features will be added to provide the best possible security when logging in. Users of the application will want all their financial details to be as secure as possible. The login system could be developed using AJAX technology, however it is not required here for any benefits so will not be used. The time this development step will take will be minimal; to be completed and fully functional should take no more than two days.
6.3.3 CREATING INVOICES AND EXPENSES To create invoices and expenses, the user will be presented with a form. This form is built using HTML; however functionality will be validated and modified using JavaScript. The user by default is to be presented with a form containing fields for address details, contact details, costs, VAT and totals. The user may wish to include an extra cost field if more than one item is to be added, this will be done using AJAX to input an additional field. This method is used as if the user requires several new rows of data, refreshing the page every time can be time consuming and cause delay to the user; simply adding a new row and not reloading any data is much more efficient. On filling in one of these forms, the user may select Estimate or Invoice; this will mark the entry as the respective type. Invoices are to be included in all sorts of costs and calculations to provide statistics in other areas, where as estimates are to be excluded from this. These are entered into the database using PDO’s commit functions to include transaction management. This provides a fast and secure creation of invoice data. The list which contains all the current invoices and their status is to be built using the JavaScript JQuery library. This library provides a lot of AJAX support and functionality to suit my 33
requirements. This list is populated using a PHP function to get data from the invoices table and fill the list with it. Using JavaScript and PHP this list can then be sorted by status, value or name of the invoice. The list will provide buttons to mark invoices as completed or due. This will update the database using PHP. If an invoice is overdue, an email will be sent to the client notifying them. This will be done using a cronjob which will run every 24 hours. This function will find all overdue invoices in the database, find the client which they are linked to and then send an email to the provided email address.
6.3.4 EXPORTING TO PDF If the user requires an invoice to be emailed to a client, or to be saved for printing purposes, then the user may do so. If the user wants to send the invoice in an email, then by simply completing the invoice and clicking Email will do the conversion and save the document in the userâ&#x20AC;&#x2122;s directory, a link to this PDF will be sent to the client to view. For additional security, the client must enter their email address to which the email was sent to view the file. This will be done using the Zend framework which provides a set of functions to build PDF files. This will be used over other PDF builders as it is part of a trusted framework, which will be used in other aspects of the application.
6.3.5 GENERATING GRAPHS To create a dynamic and real time set of graphs to go along with tabular data, the graphs will be developed using the JQuery library. The graphs will actively get data from the databases and display it in graphical form. The type of graphs to be used will most likely be line graphs, showing a valueâ&#x20AC;&#x2122;s change over time. This is to be done using JQuery as the library offers AJAX functionality and the graphs will be much quicker to alter if required. The graphs may be changed by editing the time period in which the user wishes to view the graphs. There are few other ways to draw graphs from database data, but other ways of doing it are not as advanced as the JQuery graphs.
6.3.6 PAYMENT METHODS PayPal offers an API which allows the integration of payments to be made. These payments then return a message to the server notifying it a payment has been made and if it was successful, this can be used to modify the status of the invoices and whether they have been paid or not automatically. This can save the user a lot of time and possible confusion over whether the client has paid or not and when.
34
6.4 DOCUMENTATION Each step of development and design will be recorded. Both will be recorded in change logs which will be updated at any changes in either design or development, as well as updated when new additions are made. This will provide me with an overall, true, timeline of what happened and when. This documentation will be written in Microsoft Word as the file types are widely recognised and the application is widely used, making it a safe way to assure documents can be opened.
6.5 TESTING Testing will be done in multiple stages, throughout the project to ensure all sections are working as required. Testing will be taken out by three parties. These parties are I as the developer, once satisfied with my own testing, I will pass the product onto one client and request that they test it for the functionality they require, this will then be repeated with a second client, who may have different needs for each section. The method used here will return test data from three separate test cases for everyone. This is more likely to pick up errors that one person may miss. The testing periods will be shorts but frequent, followed by a longer testing period at the end of the products development. This is the period that will involve all three parties testing.
35
7. TESTING STRATEGY 7.1 INITIAL TESTING For my application to be fully functional in aspects of Object Oriented PHP, the server hosting the website must have a minimum of PHP version 5 installed. This can be tested by using the inbuilt PHP function phpinfo(). This will return a tabled format of all the PHP settings on the server, it will also specify the PHP version. If the version is not above 5 then the host will need to be contacted to arrange an upgrade; otherwise the development can begin.
7.2 DESIGN TESTING Once a final design has been decided, and once it has been marked up into XHTML and CSS, the layout must be tested in a wide range of browsers to make sure it is compatible with all of them, if it is not, then changes in the CSS will have to be made to make sure it is browser compatible. The browsers that would require testing are: Internet Explorer 6 7 and 8, Firefox 3+, Google Chrome and Safari. These are the four most widely used browsers today.
7.3 DEVELOPMENT TESTING 7.3.1 FILE GENERATION File generation can only be tested in one way, and that is to use the code from the Zend Framework and pass test data into it to simulate a userâ&#x20AC;&#x2122;s input. If the file is generated successfully and with the correct data in the correct place, then it can be considered fully functional. If data is not as expected, repeated testing will be done until success is achieved.
7.3.2 ACCESSIBILITY A key factor in the development of an internet site is that it is made accessible to people using particular devices to aid them in the reading of the site. Such examples are screen readers for blind users of a website. How to test this would be to set up a screen reader myself, and confirm that it can read the content on the site. This must be done before the larger stages of development as to not place myself in a position which means editing a large amount of code to fix this. For persons with poor eyesight, the user may wish to increase font size on the page using the default browser tools to do this; I must make sure the site does not appear broken or illegible when this is done. There are online tools to check for the testing of accessibility features, broken links and general issues with browsers, however they may not be 100% accurate, they will assist me in confirmation. The tool which may be used is SortSite, which can be found at the following domain: http://try.powermapper.com/demo/sortsite.aspx 36
7.3.3 DEVELOPMENT TESTING Throughout development, a tool known as FireBug will be used. The tool is an add-on for the Firefox web browser which provides information on current scripts and code being run on the viewed page. The add-on also provides information regarding returned data and sent data. By being able to view this information at all stages of a script being ran, I can determine if anything is running correctly or sending incorrect data. This will be done almost repeatedly throughout the projects development every time a line of code is changed to confirm it is working as required. Due to the excessive use of this tool, only key uses of it will be documented.
37
8.
PLAN
8.1 WHAT NEEDS DESIGNING? To create a successful product, which is to be web-based, the visual design is a powerful influence on the products success. If a website looks visually out-dated or sore on the eyes, then the visitor will soon leave to find an alternative. Whilst considering visual design, the flow of the content needs to be taken into consideration too. A site in which it is difficult to navigate around will also deter the visitor from staying at the site. With navigation and visuals in mind, accessibility needs to be designed into these. Creating an image heavy site will make it difficult to resize text or use screen readers for the visually impaired.
8.2 DESIGN TOOLS There are many design applications available to deal with the design of websites. These range from drag and drop images, to image creation tools. Imaging tools include GIMP and Photoshop, which would both be entirely suitable for the scope of my product; I will require minimal background images and a single logo. Between the two, Photoshop will be used. They both offer almost identical functionality; however Photoshop being part of the Adobe Creative Suite provides better support and help if it is required. GIMP is open source but has a lot of support; however I have less practice with using it. For the layout design of the website, inclusive of navigation, tools such as Dreamweaver often crop up. Dreamweaver provides functionality such as auto complete and real-time error checking in your code. Although this is available for me to use, I will be writing the CSS to design the layout using my FTP client CuteFTP. This does not have the error checking and auto complete functionality, but upon saving it will automatically upload the files; which is also possible in Dreamweaver, however I have found in the past files being over written by older versions or becoming corrupt when using Dreamweaver.
38
9. VISUAL DESIGN 9.1 CONCEPT OAMS is to provide a modern yet professional service to its users. Users could range from freelancers right up to large scale businesses where each account may be a single department within the business. As stated in the design plan, due to the application being web-based, it needs to be eye catching and modern in look and feel, else there is a risk of the user leaving the site without going deep into it.
9.2 VERSION 1 A use of grey scale colours imposes a look of professionalism. A page width header using gradient colours fits in with modern web designs; this shows the user that this is a newer site and they may look further into the application itself to see what it offers in its entirety. The font is Gill Sans MT, a san-serif font, which also makes the application appear modern and robust.
39
9.3 FEEDBACK Once the design was completed, it was shown to two clients for feedback on the design and structure of the site. Colours
Font
Layout
Navigation
Images
Client #1 Although they work well together, colours do not invite me into the site. Font suits the colour and layout ok. Logo font is a little too small. Overall Good. Central section is clear and attracts attention.
Navigation is too bulky compared to the rest of the design. No comment.
Client #2 Too dull. I would prefer something a little more colourful if I had to use it frequently. Suitable.
Easy to focus on the area required, without too many separated areas to confuse the user. Not very clear at first glance.
The image on the home page looks modern but does not come across as accountancy or invoicing to me.
40
9.4 VERSION 2 Based upon the feedback received for the first design, some slight changes have been made, which improved the design. The first step was to introduce some colour and step away from black backgrounds. The new colours breathe some life into the site; a bright green also increases the feel of a modern web application. The same font was used in the body of the site as previous, however the logoâ&#x20AC;&#x2122;s font size increased with the addition of a slogan underneath. Navigation was reduced in size and given a simple change in colour when hovering; improving the feel of interactivity.
9.5 FEEDBACK Colours
Font Layout Navigation
Images
Client #1 Colours still work well together and much more inviting. I feel like Iâ&#x20AC;&#x2122;d like to look further into what the site offers. Logo font is much clearer. No additional comments. Much more concise, provides a clear yet not too dominating navigation menu. Also does not interfere with the content. No comment.
Client #2 Much better and much more defined than previous design.
No additional comments. No additional comments. Much easier to see the navigation and distinguish between the links and what page is being viewed. The image is much more suitable than the last one.
41
10. PRODUCT DESIGN 10.1 PAGE STRUCTURE Now the website design has been completed, the sites navigation can be completed and pages constructed for each section of the site. This will require overlooking the requirements again to make sure everything has its place within the application. The application will be split up into two core sections. These sections are to be the public website and the private area which is the application itself. This is due to users needing to register and log in to access the site.
10.1.1 THE PUBLIC SITE
Home
Contact
Login
About
Register
Tour
About
10.1.2 THE PRIVATE AREA
User Home
Clients
View Clients
Modify Client
Add Client
Expenses
List Expenses
Add Expense
Invoices
Archive
List Invoices
List Estimates
View Invoice
View Estimate
Accounts
Create New
Archive
View Accounts
This structure of web flow creates a simple to use application, instead of hunting through multiple pages to create a new invoice the user simply navigates to the invoice section and creates a new one. Research shows that the quicker and easier to use that navigation on a site is, the more likely the user will prefer it to somewhere with more complex navigation.
42
11. UML 11.1 CLASS DIAGRAM The class diagram shows what classes are required by the application and what information each class needs to hold. This information is used to store in the database or session data for use around the site.
43
11.2 USE CASE DIAGRAM The use case diagram shows possible actions the user may desire to take within the application.
44
11.3 SEQUENCE DIAGRAMS The below sequence diagrams show in more detail what occurs in certain situations.
11.3.1 LOGGING IN
11.3.2 REGISTERING
45
11.3.3 CREATING INVOICE
11.3.4 CREATING CLIENT
46
12. DATABASES 12.1 STRUCTURE The product under development requires a database built from multiple tables, ranging from simple user information tables to tables holding information regarding saved invoices or expenses sheets. To link all this stored information together, the databases will be developed as relational databases. This method means that tables are linked together with an ID or another unique identifier. This allows multiple types of data to be retrieved quicker; relational databases also means that there is no duplication of data in multiple tables, each bit of information should only be stored in one place, and be accessible from other tables by use of foreign keys.
12.2 NORMALISATION To create a database which performs at its best, it is desired that it conforms to the rules of third normal form. The process of Normalisation is that of turning a list of data into a well structured form by following the different levels of normal form. These levels follow through 0th, 1st, 2nd and 3rd normal form (NF).
12.2.1 0 TH NF The 0th Normal Form consists of sets of data that is required for each entity. My product has five key entities which are Users, Invoices, Estimates, Expenses and Clients. These are what builds the functionality of the product. Each entity is assigned a table name (bold) and a primary key (PK). If any attributes are used more than once within the entity, then these are indented to show.
47
12.2.2 1 ST NF The 1st Normal Form step is the process of removing those attributes which may exist more than once within the entity in which they belong. These are put into their own table, along with the Primary Key of the table they were removed from; creating a link between the two, and their own unique Primary Key.
48
12.2.3 2 ND NF Once the tables are created in 1st NF, the step of moving any attributes which value is dependent upon just part of the composite primary key. In my created tables, each InvoiceItem has a Name, Cost and Amount. Within this set of attributes, the Cost and Name of an Item is dependent upon the ItemID, as each itemâ&#x20AC;&#x2122;s Name and Cost will be related to a single ItemID. These two attributes are moved into their own table taking the Primary Key of the table they are linked to, in this case ItemID.
49
12.2.4 3 RD NF Now each table created is in 2nd Normal Form, the next step is to make sure there is no attributes which are dependent upon other non-key attributes. In the case of my tables, there is the Client and User information within an Invoice, Estimate or Expense. These are already available in other tables, so a single attribute is created to link to these other tables, know as a Foreign Key.
50
13. ENTITY RELATIONSHIP DIAGRAM
51
14. DATABASE TESTING There are constant additions to the database throughout the application; every time an invoice is made, a client is added or a user registers, data is being passed to and from the database. Being heavily database driven, testing is required at all stages multiple times to be sure that connections and storage in the database are working as intended. For testing purposes, an account called ‘db_test’ will be used containing sample information in all aspects.
14.1 INSERTING TO DATABASE To begin with the registration form is filled in with valid information.
Clicking ‘Register’ will submit the form and create the user in the database, as seen below, as well as log them in. When logging in the user will be given a unique session so they may freely browse the internal application. The user’s information is now stored in the database.
Here we can see that all the data has been input correctly into the Users table. If a user does not input data into any field they will not be allowed to register as can be seen further on. 52
14.2 SELECTING FROM DATABASE Having created some sample invoices for the user, they can be listed on the index page of the invoices section. This is how the list appears:
As we can see, the fields ‘InvoiceID’, ‘Client’, ‘Notes’ and ‘Value’ are all retrieved successfully. ‘Status’ and ‘Options’ do not contain any unique information; however ‘Due Date’ should contain the date entered but does not. This is because the field in the database is currently set to take a Date, and the invoice creation form still needs to be tweaked to provide a correct date format to store in the database. After the Date was corrected we can see it works as required.
53
14.3 UPDATING DATABASE Updating tables is required in all areas of the application, this modification provides a quick and easy way to update details or move items about to different areas. One example of this is archiving an invoice. By clicking the archive button on the invoice list, the invoice will be marked as being archived.
The invoice can now be viewed in the archives page, showing the data that is now relevant.
This confirms updating the database is functional and works as desired.
54
15. REGISTRATION To make use of the application, the user must register to the site; this will provide them with an account in which they can log in with. The registration form is to take in details of the user, such as contact details and a username and password. These details will be validated using JavaScript. The required fields for the registration form will be: Username Password Email Address Town Country Phone Number Company Name Each field will be validated as the user enters data. This is done using AJAX; the data entered is picked up at every key stroke within the field and checked whether the fields value is valid. If a field is empty, it is considered invalid.
If a username is already in use, this is considered invalid.
If a password is too short, or the confirmation password does not match, then an error is also given.
Once all fields are filled in and pass the validity tests, it is then submitted to a server side script; this script will add the user to the database. After the user has been successfully added to the database, the script calls another function which creates default files and folders for the user. Each user has their own personal folder within the application, this is where all their PDF files will be stored, and will allow external access to their clients to view their invoices. For example, a PDF for user ‘administrator’ will be stored in ‘/app/Users/administrator/pdf’. This directory has read and write permissions so that the user may create and save invoices and estimates at any time. 55
User ‘administrator’ stored in the database.
Personal directory created for the user ‘administrator’.
Inside this folder is the ‘pdf’ folder where the users PDF’s are stored.
56
16. LOGIN Once the user is registered they may log in with the details they provided. The required fields for the login form will be: Username Password Unlike the registration form, validation is not done on the fly using AJAX. The form is submitted directly to the server which does the validation. If a username does not exist or a password is incorrect, the user will be made aware that they may have mistyped it.
If the user logs in sucessfully then they are given a session from the server and directed into the application. This can be seen by the smaller header and change in navigation on the page.
57
17. FORGOTTEN PASSWORDS Often a user will forget their password, if this is the case, the last thing they want to be doing is emailing to request their password be changed and having it take a long time to do this. To request a new password the user need to simply click â&#x20AC;&#x2DC;Forgotten Passwordâ&#x20AC;&#x2122; on the login page.
This will take the user to a page where they enter their username to get a new password sent to the linked email address.
When the user clicks the button to request their new password, an email will be sent to them containing this information.
58
The user will be notified that the password has been sent by a pop up alert and be taken back to the login page.
The user can now instantly log in with this new password. To change it to something else, the user can log in and access the Settings sections of their account.
59
18. INVOICE AND ESTIMATE DESIGN 18.1 DESIGN RATIONALE Invoices require to be designed to look professional, as if from a well established company. This can be vital to the reputation of the business using the application. Missing information can cause problems when trying to pay an invoice or get in touch with the company, these problems can deter clients from using your services again. The invoices need to be printable, so it would be ideal to design them using the Zend greyscale colour variable instead of full colour. This prevents difficult to read invoices when printed if the client does not possess a colour printer. The invoices need to clearly state what is being invoiced, who the invoice is to and from and the total that is due to be paid. The issue date and payment dates also need to be made clear to the invoiced person. Two designs are required as a minimum to provide a choice to the users; this provides the users the ability to use invoices which better suit their needs. The two designs can be found in the appendix (Figures. 1 & 2)
60
19. INVOICE AND ESTIMATE DEVELOPMENT Invoices are built using the Zend Framework. This framework has a library called Zend_PDF which provides a selection of functions which assist in building PDF’s. Invoices are built when a user submits the form. When submitting the user has two options, these are ‘Invoice Client’ and ‘Send Estimate’. Both options will create a PDF file and email the PDF to the client; however it will state whether it is an invoice or estimate. If the document is created as an invoice, it will be included in the accounts reports; if it is an estimate it won’t. Estimates can later be modified to become an invoice and be sent as one, this will then be included in the accounts. The PDF generation itself is a long but simple process. Each drawn line on the invoice has to be drawn, either by drawing a box or an individual line, these need to be told the exact location for each corner within the document using an x and y axis. This process is similar for text and images. To begin with a new page is created in the PDF; any number of pages can be created, these pages can be passed multiple parameters such as page layout and size. In this case invoices will be A4 Portrait pages. Once the page is added, the style chosen by the user (in their settings page) is retrieved from the database to determine which document style to use. Once determined, the PDF is built, using the data entered into the previous form. The PDF is then saved in the user’s personal directory to be able to view it at any time. Once saved, the PDF is then sent in an email as an attachment to the client; the client may view the invoice and possible payment methods in the email. The email is sent using the Zend_Mail library. This provides simple to use mail functions which are similar to the normal PHP mail() function. The email is created and a HTML formatted body can be written as the body of the email; the PDF is then attached using the createAttachment() function. This email is then sent to the email linked with the client that the invoice was built for. This also applies to estimates.
61
20. INVOICES 20.1 INVOICE CREATION When beginning the creation of an invoice, the user must fill in a form. This form includes auto updating fields for the client they pick to send the invoice to. When a client is picked, the corresponding fields should be filled in.
Once the fields are filled in, the user may continue filling in the form. The user will then be asked to provide a date the invoice needs to be paid by, this is done using a jQuery date picker. If a date is successfully picked, the date is entered into the corresponding box.
62
To add new items to the invoice, the user makes use of a button which adds new elements to the page, which can be filled in. Past testing showed the elements becoming cleared when new ones were added; however with use of a jQuery function this problem was sorted and data remained in the fields when adding new ones. To add a new field click the â&#x20AC;&#x2DC;+Itemâ&#x20AC;&#x2122; button to create a new field.
Once the user fills in the items and decides whether to send the document as an invoice or an estimate, the PDF is generated.
63
This invoice is also emailed to the clients email address with payment options.
64
21. EXPENSES 21.1 DESIGN Expenses are simple inputs which include a cost and what the expense was for. For this reason, the expenses section is to be designed to take this information along with a date and additional comments. The expenses are to be business expenses instead of expenses clients should be paying for. This is to be built using a simple form and adding the data to the database.
21.2 DEVELOPMENT Expenses are created in a similar way to Invoices and Estimates; however no PDF will be created. This is because all the required information from an estimate can be seen in list form. Each estimate will have the following fields: Personal Reference Total Cost Date Notes The fields are similar to the Invoice ones, where the date is chosen using a popup date picker. The data is then added to the database, linked to the user who created it, ready to be listed in the users account.
21.3 TESTING To test the functionality of the Expenses creation and listing a sample expense can be created. Filling in the form:
65
Submitting the form will add the expense to the database:
This also allows the user to view the expense in their list:
66
22. LIST MODIFICATIONS 22.1 ARCHIVING The archives in each section of the site contain all the invoices, estimates or expenses which the user no longer has a need for, but does not wish to delete. This allows the user to still see these items, but they do not get in the way of items which are important or still active. When a user wishes to archive an item, they can do so by clicking the ‘A’ under Options in any list. This should update the item in the database to say that the user has requested it to be archived. The item will then be visible in the archives section. To test that this process works, an invoice has been created which will be archived. 1. Click ‘A’ for the invoice we wish to archive.
2. See the invoice is no longer listed in the invoices list.
3. Go to Archives to see the item has been moved.
If a user wishes to undo the archiving process, they can click ‘U’ under options in the archive list and have the invoice returned to its normal status.
22.2 RESENDING INVOICES Sometimes, emails may get lost during sending, or automatically trashed by the clients email server. If this is the case, the user may wish to resend an invoice. This can be done by clicking the ‘R’ icon under Options. This will send an email to the client with all the required information. A popup message will confirm that the email was sent successfully.
67
22.3 DELETING If a user wishes to delete an invoice, due it being incorrect or no longer required; then the user can choose to delete it. To delete an invoice the user needs to click the â&#x20AC;&#x2DC;Dâ&#x20AC;&#x2122; icon; this can be used from all lists, inclusive of archives. This will delete the invoice from their personal storage folder and also from the database so it is no longer accessible or viewable.
22.4 STATUS CHANGE At this stage the status of an item can be modified manually. The plan is to deal with this automatically once PayPal payments are incorporated. For now, and for basic testing purposes, the user may edit the status, and will continue to be able to after the integration of PayPal in case anything goes wrong. To set the status, the user simple clicks the desired status icon; P for paid, U for unpaid and O for overdue.
When the user clicks this the status for that invoice will be modified in the database. The user will also be made aware of the change by an alert.
The new status will be instantly visible to the user in the list and instantly able to be sorted if required.
This new status is now saved and will in turn modify changes in the accounts area of the application. 68
23. SORTING LISTS To help the users make use of the lists within each area of the site; the ability to sort the information by certain criteria can improve the user experience. The users may wish to sort data in both ascending and descending orders, so this ability needs to be implemented also. The user will be able to sort their lists by clicking the heading for each column that has data they may be sorted.
By clicking on an example column, in this case ‘Ratings’ of a client the list will be sorted by the Overall Rating a client has. This is done by sending the list’s contents type along with the field that needs to be sorted to a JavaScript, which uses the jQuery Ajax function to get a new set of results from a PHP script which is sorted.
By clicking on the heading again, the data will be sorted the opposite way round.
All lists can be sorted; this includes Invoices, Estimates, Expenses and Clients. All fields which contain specific data may be sorted; this excludes Notes, Address and Options. 69
24. CLIENTS 24.1 DESIGN To send an invoice, a user will be required to add a client. This is to prevent the user having to type in clientâ&#x20AC;&#x2122;s details repeatedly and to prevent possible mistakes being made in the details. The client will be created using a simple form within another area of the site; this area will list all the current clients, allow the creation of new clients, modifying of clients, rating of clients and deletion of clients. Clients only require some basic information about who they are, where they are located and contact details. The information to be gathered within the form is: Name Address Line 1 Address Line 2 Postcode Country Email Phone Number The complete form design looks like the following:
70
24.2 CLIENT CREATION To create a user, the form must be filled in with as much information as possible. The user is not required to fill in all information, however the more they do the bigger benefits they will see in regards to automated functionality such as emailing and sorting.
Once the form has been filled in the user submits it. This action will add the clientâ&#x20AC;&#x2122;s details to the database, linking it with the user using the users UserID.
This saving of a client also allows the user to view them in the main clientâ&#x20AC;&#x2122;s page along with other users.
This client will now be selectable in the invoice and estimate creation process.
71
24.3 CLIENT PROFILES By clicking on the client’s name, the user may view a more detailed profile of the client, including invoices and estimates currently linked with that client. This means the user has more options when looking for invoices; it works like a ‘filter by client’ function. When a user selects a profile to view, they will be directed to the profile page.
As shown, the user can view all the client’s details, ratings, invoices and estimates. This gives a quick, but detailed overview of each client. In this example there has not been an invoices or estimates created. If a user tries to view a client which does not belong to them, they will receive an error message.
72
24.4 CLIENT MODIFICATION If a client’s details change then the user may wish to update them instead of creating a whole new client. This feature saves the user a lot of time and loss of information or any links to current documents. To modify a client, the user simply double clicks on the field which they wish to edit. This interaction will replace the text with a field in which the user can modify the client’s information, for visibility the font size is increased.
To save the changes, the user needs to simply click outside of the field.
This action will cause an Ajax request to be created which will send the new information to a PHP script, which in turn updates the database. This single update will change all occurrences of this client’s details across the site.
73
To delete a client from the system, in the bottom right of the profile page is a Delete Client button.
Clicking this will remove the client entirely from the database. Anything linked to them will be replaced with null data. In this example â&#x20AC;&#x2DC;Business Twoâ&#x20AC;&#x2122; is being deleted. Invoice ID 4 is linked with Business Two.
A better way to represent this loss is to replace any null data with some informational data.
The user is now made aware that the client linked to that document no longer exists.
24.5 RATING CLIENTS The user ratings are also done on the modification page shown previously. The user simply selects a rating for each category based on a recent transaction or communication (whatever the user feels like rating). This will then be used to calculate a new average for each category by factoring in a total number of ratings and the current ratings.
When the user submits their rating an Ajax function is used to send the new data. The previous ratings are gathered and multiplied by the total number of ratings. This is so when the new rating gets included, it will balance out correctly. The old and new ratings are added up and then divided by the total ratings, inclusive of the new rating. This gives a new average rating for all categories which is updated in the database. To initially make the user aware they have been saved, a popup window is used. This prevents the user from becoming confused as to whether 74
the rating was accepted or not; when a user has submitted a lot of ratings, a single rating may make little difference.
At this point the ratings are successfully saved in the database. Upon clicking â&#x20AC;&#x2DC;OKâ&#x20AC;&#x2122; the ratings on the page will be updated automatically.
75
25. SETTINGS A user has a small, but effective set of settings which they may alter to improve their experience within the application. The first setting available is the ability to upload a custom logo for their invoices and estimates. This is at a maximum size of 550x140 pixels. This is so that it will fit properly within the invoice designs. The second option available is the invoice style. This choice will determine which invoice style will be used when the user creates a new invoice, it will not affect previous invoices. The third and final option is to change the userâ&#x20AC;&#x2122;s password; this is done by filling in both fields with matching passwords and saving the settings.
When the user clicks save, their details are updated in the database providing they filled in the corresponding fields. This prevents users from overwriting old settings without the intention to do so. After details are updated the user is made aware that it was successful by an alert.
For password validation here if the user inputs a password which does not match, they will be faced with an error alerting them this is the case.
76
If the password does not meet the 6-18 character length rules similar to when they registered, they will also be made aware.
The user may instantly begin using their new password once they have changed it. Their logo will be used on any invoices created from this point onwards, and the same for their invoice style selection.
77
26. USERS HOMEPAGE 26.1 ACCOUNT OPTIONS This section of the user’s homepage contains links to logout and to edit the user’s settings.
26.2 INCOME OVERVIEW This section displays the current overview of the user’s accounts. This shows the current income gained from all invoices, the total cost of all invoices that have not yet been paid or are overdue and the total value of all invoices sent out. As well as just income, this section displays the total expenses of the user and provides an estimated total profit by subtracting this from the total income.
26.3 CLIENTS OVERVIEW This section provides details of the three top rated clients, providing a direct link to the client’s profile. This provides a quick and easy way to find clients which will be best for the jobs required. This also shows the total number of clients.
78
26.4 OVERDUE INVOICES This is simply a quick view of all invoices which are overdue, these can also be seen in the Invoices section of the application, however due to being overdue the users may desire to see these as soon as they log in so they are aware. This was suggested by one of my own clients.
79
27. ACCOUNTS Each user will require a point in which they can view the status of their accounts, inclusive of income, expenses, profit and loss and forecasts. The accounts section of the application is there to provide this.
27.1 INCOME + EXPENSES The income of a user is to be demonstrated using a JavaScript built graph. This graph is built using the jQuery framework with an add-on package called Flot. There is another entire framework used for graphical requirements called jsRapael; however jQuery + Flot were considered better for the job. When the page is first loaded, all the main page content is to be provided and then using Ajax the graphs will be populated with all the data the user has created from invoices and expenses. This provides the client side application the ability to manipulate the graphs without having to make multiple calls to the server, this increases speed and interaction possibilities of the graphs. The graphs are to show the income or expenses over a period of time. This time period will be selectable by the user so they can see information for whichever period they want to.
27.2 FORECASTS Users are often interested to see statistics which provide a rough estimate of potential profit and loss. For this reason, several forecasting statistics will be provided. These will not be using graphs as the data is not stored and may become unclear. Instead the forecasts will be tabular data which will be made clear to see and provide more details as to how they forecasts were created. The forecasts and statistics which are to be shown are: Average Income expected each month. Average Expenses expected each month. Average Monthly Profit/Loss. Average Yearly Profit/Loss. Predicted Annual Profit.
27.3 OTHER DATA As well as the aforementioned information, a collection of other data which may be useful to the users will be provided. This information will contain: Overall Income. Overall Expenses. Overall Profit. Overall Outstanding Payments. Payments Due Next Month. 80
28. ACCOUNTS DEVELOPMENT 28.1 INCOME + EXPENSES GRAPHS The graphs are specifically developed using JavaScript and by default use JavaScript arrays to populate the graphs. As the data required for the graphs is in a database on the server side, the population function was wrapped inside an Ajax function. This function collects the relevant data (Invoice or Expense) from the database and returns it as a long string of values each separated by a comma; the data is collected only for paid invoices and if more than one value appear on the same day they are added together.
This was done as passing the whole array back into JavaScript did not output the correct format. Having got the string back into JavaScript inside the success stage of the Ajax function, the string was split between each value. To convert the individual values back into an array two values in a row were added to the same key of the array. Now the data is readable by the graph population script the graph can be built.
To allow the user to manipulate the data, the Flot package provides functions to modify the graphs axis by time. By providing a set of options for the user, they may pick anything from the entire history of their account, to a decade or a single year. This is done by selecting an item from a drop down box and clicking the respective â&#x20AC;&#x2DC;Goâ&#x20AC;&#x2122; button.
81
Income over a decade.
Income over a year.
This graph is identical for Expenses, but using data collected from the Expenses database table. If a new invoice is created, for this example an Invoice that was paid on 20th September 2009 with a value of ÂŁ4000, then the graph may be viewed to see the changes overall and over just the year.
82
Overall:
2009:
2010:
83
28.2 FORECASTS The forecasts are built using functions stored in the main functions.php file so that they can be used by a simple function call. The first set of information provided to the user is that of estimated income and expenses expected each month. This is made up from all income or expenses within any given month in any year. This allows the user to compare the current month with the average.
The next set of information found here are the average monthly and yearly values.
The final bit of information is the predicted Income and Expenses for the current year. This is calculated based on the average improvement or loss during the current year so far in comparison to the average.
84
The users may also compare the current year with the average year in graph form. The graph plots two lines using average data and current year data.
28.3 OTHER DATA The other data is built using functions stored in the main functions.php file so that they can be used by a simple function call. An example can be seen on the userâ&#x20AC;&#x2122;s homepage. This section is split into two, a quick overview of the userâ&#x20AC;&#x2122;s current account status and an overview of the top clients in different categories.
28.3.1 QUICK SUMMARY
Quick summary provides overall statistics for the users account. The values are considered since the creation of the account.
85
28.3.2 CLIENT SUMMARY
The client summary shows the overall top rated clients based upon their average rating in the database, this is the same table found on the users home page. The unique section here is the top clients based on each individual criterion. This was placed here so that the user may the fastest, best quality or best value client depending on their requirements.
86
29. CONFIRMATION BOXES After the core parts of the application had been developed it was brought to my attention by a client that there was a lack of confirmation on what could be crucial changes. To prevent these changes taking place by mistake, confirmation boxes were added at all modification points to double check the user is sure of their decision. Now when a user goes to modify an item, for example an invoice, they will be presenting with an option box in which they must click OK to continue with the changes.
87
30. PAYING INVOICES When a client wishes to pay an invoice, they can do so by an automated payment. This would be done using PayPal as a third party, however for the simulation of this a simple payment link has been added to the email the client receives to pay the invoice. By clicking this link the user is directed through a script which marks the payment as paid (assuming the payment is confirmed)
If the payment is successful then the users are made aware.
This updates the invoice as being â&#x20AC;&#x2DC;Paidâ&#x20AC;&#x2122; and is instantly included in the accounts profile.
88
31. SCHEDULED JOBS Also known as â&#x20AC;&#x2DC;cronjobsâ&#x20AC;&#x2122; this script is automatically ran by the server at a specified time. In this case the script is run at midnight every day to modify any unpaid invoices that are now overdue. The script finds all invoices with an Unpaid status, where the due date of the invoice is before today. This means the invoice is overdue and is marked to say so. These overdue invoices will show up on the users homepage when they log in so they can see any new overdue invoices.
89
32. ACCESSIBILITY TESTING To provide the best service to customers of the site and the interested clients, the accessibility of the site needs to be tested.
32.1 BROWSER SUPPORT Browser support was tested using Sort Site. This tool checks for any issues that may occur in other browsers. The site came out fine with no reported errors.
32.2 WEB STANDARDS The site meets XHTML web standards as required by W3.
The site also meets CSS standards requirements.
Sort Site also checks all these for validation.
90
32.3 SCREEN READERS Having used an online tool known as Sort Site, I was made aware that there were issues with screen readers, in particular with the labels in my forms. It stated how some screen readers will not read labels unless they have a â&#x20AC;&#x2DC;FORâ&#x20AC;&#x2122; attribute assigned to them. So this was added in to them. There is still reports of accessibility issues on Sort Site, this is to do with XHTML mark-up but the same pages pass the W3 validation checks and I was unable to find these errors.
32.4 RESIZING Resizing text on the site can be important to anyone with visual impairment. For a site to be suitable to resize, the text must increase in size without damaging the layout of the site. The OAMS website conforms to this and there are no errors or corruption when zooming in or enlarging text.
91
33. EVALUATION OAMS in its current state, I would not say is a finished product; however it meets all of the requirements that were said to be ‘must haves’ and the majority of those said to be ‘should haves’. This could be considered as a completed project and is fully functional in its own rights. The proposal was met in that the system provides invoice, expense and accounts functionality.
33.1 WHAT REQUIREMENTS WERE MET? By looking through the requirements specification that was drawn up at the beginning of the year, I am pleased to see that most of the requirements had been met, there were however some requirements that were unfortunately not met due to certain reasons. One of these requirements, which was completely left out was the option to create Draft invoices. These were designed to initially be able to be saved and modified, or added to as and when needed before sending the final invoice, so that the users could be entirely sure that everything was on the invoice. The main reason for this not being put into development was that it would have taken an additional 1-2 weeks of development and testing which due to the slow start of the project was not going to be possible and was the only section of the project which could be cut out based on its requirement level. This being removed did not have any effect on other parts of the application either. Another large requirement which was excluded was one which from the start I believed might be unreasonable. This was the development of a self-installing version of the application that someone could download and install on their computer. This was not very well thought through on my own back; I did not consider how a lot of the application would need modifying to consider the dynamic setup configurations and different file structures some users may have, as well as operating systems. Due to this the option for a downloadable package was not met, this was decided early on in the project that it would just not be feasible within the time scale. Other, smaller requirements which were not met, but could have been within the time scale all fall under the ‘could have’ requirements. This means that they were not desired, but would improve the experience of the application. These includes such things as sending email reminders of due/overdue invoices, which would not have been difficult to implement, but the remaining time was used to refine other aspects of the application. Also being able to export the data into XML files was not included, however all files could be exported into PDF. Other optional requirements were payment portals such as PayPal. Due the inability to set this up, being unable to set up additional accounts to test, this was ultimately simulated using a set of links to demonstrate what would happen if the PayPal API was in between. This particular requirement being missing was the one that let me down the most, having used similar methods before I really wanted to get this integrated so that invoices could be paid for using my application so the system could be considered more complete. It was also mentioned that the login system would incorporate an SSL certificate, however this was left out due to excessive costs to get a full secure certificate, however it was looked into and agreed upon by the clients.
92
All other requirements that were met were met to a very satisfactory level and function just as imagined and requested by the clients at the beginning of the projects development. There were also no unexpected additions to the requirements.
33.2 CHANGES IN DESIGN There was a change in the database design part way through the project. This was due to the fact that it was agreed that it would be unsuitable to store individual items of an invoice in the database. These were designed to hold a price for each item, but due to the dynamic aspect of these fields, this would prove to be too excessive for what it provides. Each user would be able to see all their past invoice items in an auto-complete manner. However if a user does a wide array of work, or wishes to uses client-specific item names, then this becomes overly excessive and a rarely used feature. Due to this change, several database tables were dropped and no longer used. This includes all â&#x20AC;&#x2DC;Itemsâ&#x20AC;&#x2122; based tables and any tables which distinctly relate them to their parent types. The class diagram drawn up for the project also changed, this was due to such things as forms and lists requiring different attributes than previously assumed. Otherwise it remained pretty much the same.
33.3 PROJECT PLANNING The project was planned out initially using a Gantt chart (Chart1). This chart was following very accurately until the end of the research stages, when more and more research areas were added due to previous research done. This delayed the project by close to two weeks. This is reflected upon in the more recent Gantt chart (Chart2). The development stages also suffered from this delay, and their own delays in such things as getting clients to test the product at multiple intervals, which proved to be a longer process than envisioned. This set the project back another two to three weeks. This reflection is made in the Gantt chart modified in late March (Chart3). However, even with these delays, the product was completed to more than a satisfactory level based on the requirements that were requested and what was included.
33.4 FUTURE DEVELOPMENTS Now that the product is complete, there are many aspects which I would like to integrate in the future; this includes the missing draft and payment requirements. I also understand that there is a lot more to accounts and profit and loss information that is currently included, so all the additional tools and figures would need to be incorporated to make it a more useful and complete tool.
93
34. CONCLUSION In conclusion of the project, a lot of achievements were met and a lot was learnt. To begin with, I had never used my object oriented knowledge with PHP before. Throughout the project I used my knowledge of both areas to create my very first object oriented application, which happened to be a lot bigger than imagined. Although not perfectly built as an object oriented system, it has furthered my confidence and productivity in building object oriented applications. This is something that will help me greatly in the future, and has inspired me to improve my OO PHP skills over the coming months so it is something I can offer to employees. This is both an achievement and a lesson learned upon reflection. This was the first project of mine, which was heavily client and requirement focused. In the past I have mainly done work based on just an outline of requirements and met them to the best I could. With clients involved, it makes life a slight bit harder, waiting on them or trying to keep them happy without ruining the functionality of the product. I have learnt a lot throughout the project process. Mainly this was in relation to project planning and the problems that can disrupt a project. I came across multiple delays in my project which were caused by many reasons which I did not even consider could be a possibility when planning. The biggest delay was due to clients not getting back to me, or being unavailable when I needed to test features or to confirm designs, this is a lesson well learnt, to predefine points at which the client may be required so they are available. As well as this, other delays were due to additional research and requirements which kept cropping up throughout, this was expected so a little leeway was given in the project plan to accommodate this, however it was not enough. In future projects I know now that every stage of a project needs to consider the implications of delays in previous stages.
94
35. BIBLIOGRAPHY (2009). Retrieved November 8, 2009, from CakePHP: http://www.cakephp.org/ (2009). Retrieved November 8, 2009, from FPDF Library: http://www.fpdf.org/ About Zend. (2009). Retrieved November 8, 2009, from Zend: http://framework.zend.com/about/overview Ajax. (2009). Retrieved November 3, 2009, from W3 Schools: http://www.w3schools.com/Ajax/ CSS Introduction. (2009). Retrieved November 10, 2009, from W3 Schools: http://www.w3schools.com/css/css_intro.asp DSDM Consortium. (2009). Retrieved November 20, 2009, from DSDM: http://www.dsdm.org Anissimov, M. (2009). What is a data mining? Retrieved November 1, 2009, from Wisegeek: http://www.wisegeek.com/what-is-data-mining.htm Argerich, L. (2003). Object Oriented Programming in PHP. Retrieved November 5, 2009, from Dev Articles: http://www.devarticles.com/c/a/PHP/Object-Oriented-Programming-inPHP Bain, T. (2009, February). Is the Relational Database Doomed? Retrieved November 16, 2009, from Read Write Web: http://www.readwriteweb.com/enterprise/2009/02/is-therelational-database-doomed.php Daswani, N., Kern, C., & Kesavan, A. (n.d.). Foundations of Security: What Every Programmer Needs To Know. Retrieved December 12, 2009, from Google: http://code.google.com/edu/submissions/daswani/index.html Furlong, W. (2008). PHP Data Objects. Retrieved March 16, 2010, from Slide Share: http://www.slideshare.net/wezfurlong/php-data-objects Gervasio, A. (2007, May 29). Using PHP Data Objects. Retrieved March 16, 2010, from Dev Shed: http://www.devshed.com/c/a/PHP/Using-PDO-Objects-in-PHP-5/ Gilfillan, I. (2002). Introduction to Relational Databases. Retrieved November 16, 2009, from Database Journal: http://www.databasejournal.com/sqletc/article.php/1469521/Introduction-toRelational-Databases.htm Gondelle, A. (2008). Creating AJAX websites based on anchor navigation. Retrieved November 15, 2009, from Yens Design: http://yensdesign.com/2008/11/creating-ajax-websitesbased-on-anchor-navigation/ Harold, E. (2007, August). New elements in HTML5. Retrieved November 12, 2009, from IBM: http://www.ibm.com/developerworks/library/x-html5/?ca=dgr-lnxw01NewHTML Hegaret, P., & Jacobs, I. (2009, July). Frequently Asked Questions (FAQ) about the future of XHTML. Retrieved October 29, 2009, from W3: http://www.w3.org/2009/06/xhtml-faq.html
95
Hickson, I. (2009, October). HTML5 at Last Call. Retrieved November 16, 2009, from What WG: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-October/023849.html Hickson, I., & Hyatt, D. (2009, August). HTML5. Retrieved November 16, 2009, from W3: http://www.w3.org/TR/html5/ James Garrett, J. (2005). Ajax: A New Approach to Web Applications. Retrieved October 20, 2009, from Adaptive Path: http://www.adaptivepath.com/ideas/essays/archives/000385.php Jeffries, R. (2001, August). What is Extreme Programming? Retrieved December 12, 2009, from X Programming: http://www.xprogramming.com/xpmag/whatisxp Kaefer, H. (2009). What is a web crawler? Retrieved November 1, 2009, from Wisegeek: http://www.wisegeek.com/what-is-a-web-crawler.htm Newman, C. (2009). Rapid Application Development. Huddersfield: School of Computing. Palace, B. (1996). UCLA. Retrieved November 03, 2009, from Data Mining: http://www.anderson.ucla.edu/faculty/jason.frand/teacher/technologies/palace/data mining.htm Pemberton, S. e. (2002, August). XHTMLâ&#x201E;˘ 1.0 The Extensible HyperText Markup Language (Second Edition) . Retrieved October 29, 2009, from W3: http://www.w3.org/TR/xhtml1/#xhtml Powell, K. (2009, February). What is a relational database? Retrieved November 16, 2009, from Wisegeek: http://www.wisegeek.com/what-is-a-relational-database.htm Resig, J. (2009). jQuery. Retrieved November 8, 2009, from jQuery: http://jquery.com/ Stein, L., & Stewart, J. (2003, February). The World Wide Web Security FAQ. Retrieved December 12, 2009, from W3: http://www.w3.org/Security/Faq/ Stephens, M., & Rosenberg, D. (2003). Extreme Programming Refactored: The Case Against XP Apress.
96
36. APPENDIX 36.1 FIGURE 1
97
36.2 FIGURE 2
98
36.3 CHART 1 Gantt chart representing the initial plan.
99
36.4 CHART2 Gantt chart representing the plan modified at the beginning of 2010.
100
36.5 CHART 3 Final Gantt chart as of March and end of project.
101