Todays lecture/tutorial focused on using an application that I have never used before called Zoho Creator. Zoho allows the user to create a database online, then use a code generator to make the system much more advanced and also meet user requirements. Zoho Creator is a very simple package that allows the creator to build simple databases (up until the coding is incorporated).

The advantage of using Zoho Creator is that it already had all the layout, templates and colour schemes built into the online system, therefore creating the basics and also a professionally styled interface is very easy. All of these features are found as templates which can be selected from the "Customize" tab which is located towards the top of the page. It is likely that if required, coding could be entered into the Script View to make the layout even more professional, but due to the fact that today was the first time I and many others in the class had used the software, we stuck to the basic layouts already embedded into the system.

The coding aspect within Zoho Creator was much harder for me personally, and I struggled to get an exact copy of the coding which I should have recieved compared to the result I actually got. Instead of having to write the code for the system though, Zoho Creator generates all the code manually via the use of tabs along the left hand side of the page which can be added onto the screen. For me personally, I dont like to write code, although if required, the Code View allows pure code to be written, and from here it will be automatically converted into buttons and other features within the User View.

As mentioned earlier, today was the first time I have used Zoho, and it looks like quite a basic application to use, apart from having to create/edit code. If I need to create a simple database that isnt based for a large professional company, then I may use Zoho Creator to store the data inside this application, although due to my knowledge of using Microsoft Access, I still think I will use this piece of software, due to the professional features that can be incorporated - although saying that Zoho Creator impressed me vastly today due its simpleness and easiness for creating a basic database system. The range of features available within Zoho Creator were quite advanced too, as the system allows me to include:

• Single Line Fields
• Multiple Line Fields
• Phone Numbers
• E-Mail Addresses
• Option Fields (Favourite Color - Red OR Green OR Blue etc.)
• Date/Time
• Number

All of these features should be useful for me to create a simple but effective database, which meets a high standard.

Despite the fact that this application is very easy to create, when it comes to entering the information, all entries have to be entered manually. As a result, this takes a very long time to do, therefore entering information takes a very long time and as a result this isnt a professional approach for either a company/individual to use, due to its time cocsumption. In the future, if I were feeling more confident with coding, I may use Zoho to base my case study around, although due to the fact that this application relies heavily on code creation/editing, then I think I will give this application a miss.

Below is an image of a sample view I created throughout the second Zoho Creator Tutorial:

Within todays lecture we recapped the work we completed last week in relation to RAD (Rapid Application Development) and UML (Unified Modelling Language). Firstly we reminded each other of the different approaches to project management, then we looked at what the customer actually recieves as the project progresses. These were the outcomes:

• Phased Development - Customer uses a basic version (version 1) and additional upgrades (new version) are added constantly. There is a very quick devliery time using this version due to the initial version been produced at a basic level.
• Prototyping - Customer gets to use a version briefly and feedback is given back to the producer/team for upgrades and improvements.
• Throaway Prototyping - Customer only gets a design of what the system will look like, meaning they never actually get the final version, until the "Throwaway" stage is made.

Based upon how quickly the customer needs the system can often depend on which method to use in order to meet the customer needs, hence, the importance of choosing which approach to use is vital.

Prioritising Functions:

Two Functions - Version release to customer as early and possible, and if expectations are high BUT the budget is low, the product must contain essential elements. This basically means that when it comes to prioritising the elements within the database, either one of, or both of these aspects need to be taken into account prior to the build. If the company/person requesting the system is short of money, then the most important elements must be included first, so that the company/customer gets complete satisfaction.

Problems When Creating A System:

• When speaking to the customer, it is likely the customer will want EVERY aspect they require within the first version of the system, meaning that prioritising becomes a much harder job. This means that the creator of the system needs to stress that as later versions of the system are released (Phased Approach), then the less important features will be incorporate later. This can often be hard for the user to choose the key aspects of the system they want now and later.
• It can be very difficult to get customer to organise/create priorities. This often results in a long list of features within the system being handed to the creator, and the creator mapping out which features shoul be incorporated first. Occasionally, this can result in the person/company requiring the system to become nervous towards whether or not the system will fully meet their needs or not.
• Some functionality in the system may inter-link (i.e. independant). Sometimes functionality is inter-linked and can't be separated.

Prioritising Categories - Requirements Scales:

Following the list of features being handed to the customer, or the creator creating a list of features to be included within the system, a priority scale must be created so that the features can be released in an order that the most important features are included first, and the least important features last. The features that the user requires within the system must fit into one of the following categories depending on their importance:

• High Priority - Product is not acceptable without this function/feature. Sometimes the phrase "Mission Critical" is used as another name for the feature that MUST be included. The features/functions that are included in this category will be released in v1.0.
• Medium Priority - Supports necessary operation. Required eventually but not immediately (e.g. something that must be in the system, but can wait - Reporting Facilities etc.). Would enhance the system once included. The features/functions that are included in this category will be released in v2.0.
• Low Priority - It is nice to have these features within the system, if the budget allows us to include them (e.g. a newsletter that can be sent out to the customers/public etc.). The features/functions that are included in this category will be released in v3.0.
• Any later features will be released in versions 4.0 and above.

Steps To Follow To Prioritising

In order to reach the final result for prioritising features, the following steps must be taken:

1. Go through the case study and/or the project and list all the functions/features contained in the requirements.
2. Go through the list of functions/features and associate each of these with one of the prioritising categoires mentioned above (High, Medium, Low), AND state a reason why.
3. Set the list into descending order of importance, meaning that all the important features (everything in version 1.0) will be first.
4. Agree the list with the client.
5. Group features/functions into versions of release.

Within today's lecture we were given information towards the method that have been used between the 1980's-1990's and then from the 1990's onwards for Rapid Application Development (RAD). Within the 1980's a method called Structured Design was used to attempt to erase all problems that happened before this time. Within the Structured Design section there are 2 different types of project management methods that were produced in order to try and make project management easier. These 2 methods include:

• Waterfall Method
• Parallel Process

Within each type of process, there are 4 steps that are used to manage the application development and these are:

• Planning
• Analysis
• Design
• Implementation

Both of these methods differ to each other vastly, and contain their positive and negative factors.

1. Waterfall Process

The Waterfall Process is a sequential life cycle, which in other words means that one thing happens after the other, and runs in a sequence where once one section has been created, it cannot be returned too. With the Waterfall method, in exceptional circumstances, if mistakes are made in later sections of the process of the project management then earlier sections can be revisited, although this is rare and isn't recommended. The Waterfall process does have one major negative effect - designing the documents upfront means they can be very hard to understand due to their length.

2. Parallel Process

The Parallel Process is generally used for splitting the project once the "Design Phase" has been created. The Planning and Analysis section are created respectively in order, but once the Design phase is reached an initial Design section is created, followed by 2+ splits. These splits are used for work to be carried out on different sections of the Design process, so that the progress of the project can actually be viewed and evidence is provided. The 2+ splits for the Design process lead onto an Implementation process to be carried out for each of the splits. Once all of these Implementation processes have been completed then they merge back together to form an Integration section which eventually leads onto the final system been produced. Generally, by using this process, the project management is shortened, however a negative factor to bear in mind when using this process is that there will be 2+ different "mini phases" been carried out, therefore there is a high risk of mistakes been carried out in the different phases, and when the convergence stage occurs, these mistakes will be integrated.

Following these 2 methods been created within the 1980's, and the mistakes that were been created within these processes been recognised, 3 more processes were created in the 1990's to reduce mistakes and errors that could potentially arise. The aim was to try and respond to the problems by ensuring a quicker delivery and also less paperwork.

1. Phased Development

Phased Development was created so that the different phases were completed in order of importance, meaning that the project is completed in phases/versions so that the user can constantly receive updates towards the system they want to use. Aid of a diagram is much better to explain this process, although in basic terms the process runs like this:

Planning > Analysis > Analysis (Version 1) > Design (Version 1) > Implementation (1st Version) > System Created (Version 1) > Analysis (Version 2) > Design (Version 2) > Implentation (Version 2) > System Created (Version 2) > Analysis (Version 3) > Design (Version 3) > Implemenntation (Version 3) > System Created (Version 3).

This version has lots of positive features:

• Customer receives "something" very quickly, despite it not been fully created.
• While customer uses version 1, work is carried out on version 2 - therefore constant implementation.
• If problems are located within the first version then the system upgrade process can be used to erase these issues.
• Saves having to wait for the entire system to be fully created, then errors are found and erased.
• Documentation is much smaller, as there are small systems for continuously created systems.

2. Prototyping

Prototyping allows the customer to have a "play" or a "trial" with the version created, and notes/feedback is given to the creator for faults that many be found. Within this version the following process is carried out:

Planning, Analysis Design and Implementation (Carried out at once) > System Prototype (Not a fully working version) > A loop is then created going back to the Analysis Design and Implementation sections so that errors found can be erased. This process is carried out until all problems have been found then the final Implementation process can be carried out, followed by the system been fully produced.

With this method though, there is a major disadvantage that if any initial problems are found in the first version, they are usually carried out in the later versions. If a problem occurs in the Analysis section, then the customer may not realise it, and it means that the same errors are looped over and over for many versions. Another negative is that no guarantee can be made that the customer will be happy, as feedback is not always exact.

3. Throwaway Prototyping

Throwaway Prototyping is exactly the same as prototyping apart from the early versions are not created, and only a design prototype is created. The process used for Throwaway Prototyping runs as follows:

Planning > Analysis (Thorough Analysis) > Analysis, Design and Implementation > Design Prototype (Not a System Prototype) > A loop is then created going back to the Analysis Design and Implementation sections so that errors found can be erased. This process is carried out until all problems have been found then the final Implementation process can be carried out, then a stem is created coming from the Analysis Design and Implementation section for the Final Design section to be completed > Implementation > System Produced.

Design prototypes continuously made until all problems that may arise are made. "Throwaway" means the Final Design flies away from the rest of the system created so far. This method is a way of creating a Final Design with all other problems that COULD arise been solved. A negative effect for this process is that the client/customer may not want this process to be carried out, as evidence of the work been produced isn't seen, only Design Prototypes are made.

Within this weeks lesson we looked at Normalisation in a deeper aspect, and following the catch-up work I had to do, this session also didnt appear to be to bad. I believe that last week the class only looked at normalising data from only one form, whereas today we looked at normalising data from more than one form at once (e.g. invoice and a purchase order form). The process that was carried out today follows the same stages that were carried out when using Normalisation last week, apart from one more stage is added at the end to remove any repeating entities that occur.

Below are a list of websites that I found that show how normalisation works, and some more information towards how/why the process is useful.
http://www.getahead-direct.com/gwentrel.htm - this website shows how the Entity Relationship diagram can be established once normalisation has being carried out. This website looks as though it could be quite useful to me as I sometimes get confused with the "crows-feet" method.
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.db29.doc.admin/db2z_entitynormalization.htm - this website is similar to the first one that I found, as it explains how the different normalisation forms work.
http://www.troubleshooters.com/littstip/ltnorm.html - this website shows another guide for how Normalization works, and the process used to obtain the final results.

Following an absence last week, I have only just learnt about Normalisation today. Normalisation doesnt generally seem like a hard task, and it seemed much easier compared against Entity Relationship diagrams.
Todays lesson was quite enjoyable and I learnt quite a lot through the use of the 5 steps that are used to complete the tasks given out today. The 5 steps that are portrayed for normalisation are as follows:

• List the un-normalised data, and identify repeating groups by placing them in brackets - the replacing groups are usually those that could be written down more than once, for example Item Number.
• Choose a key for the main group - this is usually the first entity found from the section, e.g. Customer Number within an Order Form.
• Extract the repeating groups, and give that a key - this could be for example, Item Number. Due to the fact that the repreated groups will have been found earlier, usually, the key for the group is the first in the brackets.
• Identify and extract partial dependencies.
• Identify and extract non-key dependencies.

Normalisation for me personally gets quite confusing towards the end of the process, when identifying and extracting the dependencies happens.

The Objectives behind Normalisation is to try and separate the items that are initially listed, so that the long list that is originally found can be broken down and split into small sections. Within the last step, eradicating some of the items will help to make the overall form easier to process when implemented into a computer program. Normalisation generally breaks down the list of entities given at the start of an invoice or purchase order form so that when later submitted into a database system, entities that are repeated can be removed - generally, the purpose is to save time for when the data needs to be entered into the fields at a later date.

When carrying out normalisation, the process if broken down into 3/4 steps, and these are often abbreviated into the form of 0NF, 1NF, 2NF, 3NF - these stages are used to represent the stages carried out when the 5 steps are being implenented on a set of entities. A breakdown of the list of stages is show below.

• 0NF - Zero Normalisation Form - This is the stage where all the entities from within the invoice or order form are listed into one large table. Commonly they will be seperated if there is more than one form present.
• 1NF - First Normalisation Form - This is the stage where the repeated entities are broken down into a sublist of entities. When this stage is carried out, 2 keys will be applied to each of the new sublists created.
• 2NF - Second Normalisation Form - This is the stage where the partial keys are identified and extracted. Within this stage, this is usually the time when the list of entities/sub-lists of enties is the longest.
• 3NF - Third (Final) Normalisation Form - This stage is where the list of entities/sub-lists is reduced vastly, where repeated partial keys can be removed if repeated. The non-key dependencies are extracted in this stage to give the overall list of entities and sub-lists for the given forms/invoices.

Overall, normalisation is a topic that doesnt look too confusing, and I feel quite confident carrying out work based upon this topic.