Minor Project: Investigation of Data Storage Techniques. (15%) (important for exam)

The scenario is that you have a task of writing a simple accounting cash-book application subject to your client's approval. To gain their approval you must produce a proposal which is supported by some research and working prototypes.

Your first step is to understand what is a "Cash Book" and how is it structured. How would you use a cashbook? Now write some requirements to describe a cashbook application written in Python. Write some use-cases that describe how you want the cashbook to work. These use cases can then be used to verify the design and then to test the cash book application and show that it meets requirements.

A key concern of the client is how data will be stored. To address this issue, you will need to investigate the difference between a SQL (relational) database, a NoSQL (non-relational) database, a spreadsheet (MS Excel) and a file system (using Pickle and Unpickle). Which storage method would you choose and why?

Having come up with a design and recommendations, you now need to do a "sanity check" on your proposed solution and answer the "will it work" questions clients will ask you. One way of doing this is to prototype the solution. Use Python for your code prototypes. Since this application will be a forms application, use TKinter or PyQT to explain any difficulties associated with data binding. You will need to prototype the recommended method of storing and retrieving data. You may like to comment about scoping issues (multi-user, and so on). Test your prototypes against your use cases and record the results. Prototypes will need to be well documented. Use flowcharts, UML diagrams, ER diagrams, flowcharts and pseudocode where appropriate.

Finally complete the report for marking in week 11. I can review your work in the tutorials and note progressive marks. Don't leave it to the last minute. The minimum detail required is based on your report being used by your client as a basis for a programming team to produce a "reasonable" application that meets the requirements of a cash book.Obviously, the more gaps you have in the report, the lower the mark.

Some Guidance.

A relational database management system (RDBMS) must support the ISO standards. There should be information for compliance that includes supported functions, unsupported functionality and language extensions. For example, https://msdn.microsoft.com/en-us/library/hh501587(v=sql.105).aspx shows Microsoft SQL server compliance. A spreadsheet is not a database although it may have some database like qualities - consider the structure. Do some research.

The report should be written as if the client will take your work and give this to a development team to implement your design and recommendations. In this scenario prototypes are very valuable as they become coding templates. The client will be upset if the team needs constant clarifications and finds things that are unworkable - this wastes time and money. The more options you consider, the less questions the client will ask. I will act as the client.

Prototyping is both a curse and a blessing. I have found the best way of prototyping is to do an end-to-end protype. For example, enter an item of data on the form, save it, retrieve it and redisplay it. This means the "plumbing" is in place and you can then build out from there using tested functions and code.