Matthew Nieuwenhuys i7985441

Methodologies for the Creative Technology Industry Media Technology

Matthew Nieuwenhuys

i7985441

Methodologies for the Creative Technology Industry

Media Technology Analysis, Design and Applications for Themes

Matthew Nieuwenhuys I7985441

2

Matthew Nieuwenhuys

i7985441

Abstract
This report is an analysis of the 8 different methodologies for software development, the report begins by getting an accurate idea on what the term methodology means as it can often be used loosely. It will then look at the 8 approaches, their basic principles, strengths weaknesses, differences and come to conclusions on what they are most suitable for. In order to get a better idea of how some work, an example of how the methodology could be used within the media industry will be assessed. A conclusion on whether it would be successful to implement the methodologies within the industry will be drawn, and the tools and languages used.

Matthew Nieuwenhuys

i7985441

Acknowledgements
Thanks to Tim Orman and the Bournemouth University library staff for some external help on the report

Matthew Nieuwenhuys
Contents
Introduction What is a Methodology? Waterfall Approach Prototype Approach Incremental Approach Spiral Approach Rapid Application Development Agile Approaches Object-Oriented Approaches Unified Process Conclusion Comparison between 2 Methods within the Media industry References

i7985441

6 7 8-9 10 - 11 12 13 14-15 16-17 18-19 20-21 21 22-34 25-27

Table of Contents
Waterfall Approach Diagram Prototype Approach Diagram Incremental Approach Diagram Spiral Approach Diagram Rapid Application Development Diagrams Object-Oriented Diagram 8 10 12 13 14 - 15 18

Matthew Nieuwenhuys

i7985441

Introduction
This report will understand and analyse the different methodologies used within the creative technology industry. The first stage of the report is going to understand exactly what a methodology is, then define the word relating to the creative technology industry. Each method seems to be catered for a particular field, this report will assess which methods are best for the Media industry. The report will then go into further detail on 2 in particular, compare and contrast similarities, differences anddraw conclusions on which method works better and why. The Methodologies that will be analyzed in the report are: 1. 2. 3. 4. 5. 6. 7. 8. Waterfall Approach Prototyping Approach Incremental Approach Spiral Approach Rapid Application Development Agile Approaches Object-Oriented Approaches Unified Process

Once all 8 of the methodologies have been discussed, the report will go further into two assessing whether they can be used within the media industry. This will include going through the creation of a website using the Waterfall approach and the Unified Process, comparisons and strengths of both will be shown. A few other parts of the Media industry will be exampled such as movie making, and a final conclusion will be drawn on whether the software development methodologies can be implemented within the Media industry.

Matthew Nieuwenhuys
What is a Methodology?

i7985441

To begin, the term Methodology needs to be defined, below is the dictionary definition of the word: a set or system of methods, principles, and rules forregulating a given discipline, as in the arts or sciences (http://dictionary.reference.com/browse/methodology) The term is not well defined by practitioners and there is very little agreement on what it actually means.The dictionary definition above does not closely relate to the report in hand. Maddison came up with a definition of the word, which seems to be more tailored for this report. A recommended collection of philosophies, phases, procedures, rules, techniques, tools, documentation, management and training for developers of an information system (Maddison, 1983) Utilizing this definition suggests that a methodology has a number of different components which specify: y y y y y y y What tasks to be carried out at what stage What outputs are to be produced When, and under what circumstances, they are to be carried out What constraints are to be applied Which people should be involved How the project should be managed and controlled What support tools may be utilized

Why use a Methodology?

Methodologies are used within creating systems to primarily prevent project failure. If you re creating a system in an organized way, then mistakes are kept to a minimum. Complex systems require careful planning in order to come away with a successful solution. Methodologies are used to basically come up with a better end product.

Matthew Nieuwenhuys
1. The Waterfall Approach - Linear

i7985441

Fig. 1 Diagram of The Waterfall Approach(blogspot, 2010) The waterfall approach is a sequential development process only used within software production. It goes through each stage much like a waterfall; one stage must be completed before moving on to the next. Emphasis is on planning, target dates,time schedules, budgets and implementation, and tight control is maintained throughout, with little room of customizing the approach. Extensive written documentation as well as formal reviews needs to be approved by management before beginning the next phase of the process.The approach is mainly used within large-scale projects for big organizations, and is generally unsuitable for smaller projects, as it is very time consuming, costly and you cant move on to the next stage without doing the previous one. The waterfall model originates from the construction and manufacturing industries, where changes to the project can be extremely costly, if not impossible. In 1970 Royce proposed the Waterfall model as an initial concept, although he felt is was flawed. He felt the initial model had room for development into an iterative model, with each phase influencing previous stages, this relates to many of the other methodologies.
8

Matthew Nieuwenhuys
Strengths of the Waterfall Model

i7985441

y The waterfall approach is ideal for supporting less experienced project teams, as it is a very organized method that requires constant reviewing and a tight schedule. y Strict control is maintained throughout to ensure quality and reliability for the developed software. y Feedback loops have been introduced to allow the developer to revisit stages if errors are identified within the project. y Progress of the project is measurable as you know exactly what stage you are at throughout

Weaknesses of the Waterfall Model

y Isn t flexible and can be a slow process due to the strict control y It only progresses forward with very little backward movement, therefore it is difficult to respond to changes, changes that occur later in the life cycle can be very costly, and is often discouraged. y The method depends upon early identification on what is needed within the project, and it may hard to identify exactly what is needed so early on. y Missing system components and unexpected development needs are often discovered during the design and coding stages. y Believed to be impossible to get one phase of a software product s lifecycle perfected before moving on to the next phases y Requirements can always change y It is difficult to estimate time and cost y Only certain team members are qualified for each phase, this can lead to some team members being inactive

Matthew Nieuwenhuys
2. Prototyping Approach - Iterative

i7985441

Fig. 2 Diagram of the Prototyping Approach(CMS, 2010) The prototyping approach is basically a model that is made to test an idea, rather than becoming part of the final delivered software. It can be used as a gateway to other methodologies such as incremental, spiral and rapid application development, as the process itself generally doesn t create a final product. Once preliminary requirements are gathered, a simple working model of the system is made to visually show the users what their idea will be implemented into. In some situations the prototype idea can be developed into the final implementation, although normally the prototype is discarded. The user is also involved in the majority of the prototype approach, which in effect, increases the likelihood of the user accepting the final product. Prototyping is an iterative approach meaning changes can be made to earlier stages through the entire process. The prototyping method originated from engineering discipline, engineers often need to test their ideas before actually creating them. Prototypes within Engineering are used for Demonstration purposes, where you can show your idea before creating it, which in effect can be used for sales. Thisprototyping approach is used for developing asystem that requires extensive user dialog. It is also useful for when the objectives are unclear and the user isn t full knowledgeable, as it s only a tester rather than a final product. The different phases of development are identifying, agreeing, creating and finally reviewing.

10

Matthew Nieuwenhuys
Strengths of the Prototyping Approach:
y

i7985441

y y y y y y

Addresses the inability of many users to specify their information needs, and the difficulty of systems analysts to understand the user s environment, by providing the user with tentative system for experimental purposes at the earliest possible time (Janson and Smith, 1985) Can be used to realistically model important aspects of a system during each phase of the traditional life cycle (Huffaker, 1986) Design flaws can be detected before manufacture process is initiated The user gets a fair idea of what the final product will look like before it is actually created There is a lot of Communication between user and designer, which means there will be a clear expression of what the user wants Leads to other methodologies such as incremental and spiral, so you can go down different paths Encourages flamboyant designs and new innovations as they can be tested before created

Weaknesses of the Prototyping Approach

y It isn t a very organized methodology, meaning the final outcome can be poorly designed y Prototyping can be a waste of time, because the final product isn t actually being made y Can lead to false expectations of the product, the customer might feel the product is finished when in fact it isn t y May have minimal documentation, resulting in insufficient justification for the final product y Can be a waste of money because the prototype wont be used, but does use a lot of time

11

Matthew Nieuwenhuys

i7985441

3. Incremental Approach Linear and Iterative

The incremental approach is very similar to the prototype approach although the prototype isn t thrown away but developed into the final system. It is basically the waterfall and the prototyping approach combined. A series of mini-waterfalls are performed, each one making up a small segment of the final product. Each step could be incremental or prototyping, allowing the user to customize around the task in hand. The process groups the project into phases, inception, elaboration, construction and transition. The incremental approach is appropriate for large projects where requirements can be vague or have possible external changes to the needs of the user. An example of this could be a Web Information System (WIS). Fig 3. Diagram of the Incremental Approach(UFCG, 2010)

Strengths
y Over the life of the project control is maintained, due to written documentation on a regular basis. y Users can find out exactly where they are with the product at any given time y Knowledge gained from building earlier increments can be involved when the later increments are developed y Issues can be isolated quicker as your doing the whole project in smaller segments

Weaknesses
y As some parts are completed at such an early stage the design of the project has to be perfect y There is usually a lack of thought put into technical requirements in the earlier stages of the project

12

Matthew Nieuwenhuys
4. Spiral Approach Linear and Iterative

i7985441

y y y y

Fig. 4 Diagram of The Spiral Approach(Wikimedia, 2010) Analyzing aims, alternatives and constraints for the iteration Evaluate whether alternatives could be used and any constraints Verify and develop deliverables Plan what is going to happen in the iteration

The Spiral approach has the same four stages as the Waterfall approach, although a little bit of time is spent on each phase as its being developed. This minimizes risk as your building it up like a pyramid. The spiral approach minimizes risk, although it requires an accurate design to make sure there aren t many changes made throughout. The phases of the development are think a little, plan a little, implement a little, then test a little over the four different sections. Each section is broken down.

Each iteration can take anything from 6 months to 2 years so this approach is mainly aimed at larger projects. It is often used during game development, because the idea is accurate and precise and changes can be made throughout.

Strengths
y Minimal Risk y Can involve any of the above methodologies based on the risk of the overall project, very customizable

Weaknesses
y Can be an extremely long process as there are no firm deadlines y Can get very complex as its so customizable, meaning it requires an experienced project manager

13

Matthew Nieuwenhuys

i7985441

5. Rapid Application Development (RAD) Iterative

Fig. 5 Diagram of the RAD approach(Wysterdesir, 2010) The Rapid Application Development process aims for fast development at a low cost. It s very easy to customize throughout the project as it involves iterative development with the construction of prototypes. There is minimal planning involved allowing software to be written much quicker, and changing requirements is easier.It is key for constant user involvement as plans are vague. RAD was developed as a reaction to issues rose from traditional development, in particular long development times. James Martin first used the term in 1991, and it is often called the Martin RAD methodology. Some of the tools that RAD uses are Graphical User Interface (GUI) builders, Computer Aided Software Engineering (CASE) tools, Database Management Systems (DBMS) and Joint application Development (JAD).

14

Matthew Nieuwenhuys

i7985441

Fig. 6 Comparison between Traditional methodology approach and the RAD approach (etondigital, 2010)

Strengths to Rapid Application Development

y Generally produces systems at a lower cost due to the production being much quicker y Stakeholders are a lot more involved in the project due to the constant changes and specifications y A lot of focus is on what the user wants so the outcome can be much better y Developers get a good sense of satisfaction as they complete a series of systems rather than just one y Can change the project whilst the market changes as some markets are very competitive

Weaknesses to Rapid Application Development

y As the project is getting made quickly the quality may be of a lower standard y There can be a lack of attention to later system administration needs y Uses a lot of time not only for the developers but also for the stakeholders

15

Matthew Nieuwenhuys
6. Agile Approaches

i7985441

Agile methods break tasks down into smaller increments and with minimal planning, each increment taking either a few days or a maximum of 4 weeks. The approach is based on iterative and incremental development, and does not involve long term planning much like the RAD approach. The different phases of development are below: y Parts of the project are delivered frequently, so customers are often satisfied y Generally close relation between developers and customers, face to face conversation advised as ideas are better explained y Regular adaption to changing circumstances

This approach is generally used for smaller projects due to the development time, unlike the spiral approach where it is more long-term. Tools used within Agile Approaches: y y y y y y y y Agile Modelling Agile Unified Process (AUP) Dynamic Systems Development Method (DSDM) Open Unified Process (OpenUP) Scrum Velocity tracking Feature Driven Development (FDD) Extreme Programming (XP) (taken from the Methodologies notes located on myBU)

16

Matthew Nieuwenhuys
The Agile Manifesto

i7985441

In February 2001, software developers met at a ski resort in Utah, USA, to discuss the current situation of light ware development methods. Their aim was to create a manifesto that defined what is now know as Manifesto for Agile Software Development , it included 12 principles that described the approach. These principles included: y y y y Satisfy the customer through early and continuous delivery of valuable software Welcoming changing Requirements, allowing customers a competitive advantage Business people and developers must work together throughout the project At regular intervals, the team reflects on how to become more effective, the tunes and adjusts its behavior accordingly

Strengths
y Much quicker than other development methods y Customer satisfaction due to the constant updates on the project y The developers won t waste time or money and finally find that by the time they deliver the product, requirements or customer needs have changed y Developers know exactly what to make due to the constant communication between customer and developer y Generally a high quality outcome

Weaknesses
y y y y There isn t as much attention to detail with designing and documentation Project can get sidetracked as there is no overall plan The approach cant be used on bigger projects Can sometimes be hard to estimate the amount of time the overall project may take

17

Matthew Nieuwenhuys
7. Object-Oriented Approaches

i7985441

The object-oriented (OO) approach is different to other approaches investigated; it still involves the modeling of data, although rather than treating data and processes separately but encapsulates them into an object. The object resembles a physical object in the real world, such as a person. It includes data (such as what the person looks like), and also processes and actions (move forward, backward). The developer doesn t take interest of what the processes or data includes but just takes it as an object or, a person. The data and processes inside the object can still be changed without any issues, just it makes it easier for the developer to build the final solution.

(Live File store, 2010) Fig. 7, Diagram of what an OO may look like:

The idea of the Object-Oriented Approach follows on from the first generation methodologies, and the idea was developed in the 1990 s following the increase of languages such as C++ and Java. From a philosophical viewpoint, these methods adopt a realist ontology and empiricist epistemology . The OO approach is used for small or large projects only in programming as it s based on coding languages; the different phases of development are below. y y y y System Analysis System Design Object Design Implementation
18

Matthew Nieuwenhuys
Strengths of Object Oriented Approaches

i7985441

y Basing software descriptions on reality leads to a more natural final outcome y As its based on real life objects, developers get a better idea of what is required leading to fewer problems y Working from reality to description allows designers to form closed logical descriptions, which are easier to turn into code for programming y Object-Oriented software s and systems are easier to change, debug and maintain than other structured software and systems as they are highly modular y As the data is grouped into an individual object, ripple effects are isolated and easier to trace y The principle of reusing pieces of code is imbedded into the theory that underlies the approach

Weaknesses of Object Oriented Approaches

y The idea isn t completely foolproof, designers still have to tackle problems caused by incomplete descriptions y Once the description has been formed into reality the synchronization between the real life object and the code needs to remain y There aren t many trained programmers adept for the Object-Oriented Approach, this leads to personnel shortages and adds to the software development expense

19

Matthew Nieuwenhuys
8. Unified Process

i7985441

The Unified Process is an iterative and incremental software development methodology; the best-known refinement of the Unified Process is the Rational Unified Process (RUP), this was brought in by IBM to avoid issues such as trademark and infringement rights. The Unified Process is basically an extensive framework, which can be customized around the project wanted. The iterations are broken down into the Inception, Elaboration, Construction and Transition phases. The Inception Phase is the smallest of the project; if it were long then it would go against the idea of the Unified Process. The idea is to establish the project scope, outlines the key requirements and objectives, identifies any possible risks and finally creates a schedule and cost estimate. The Inception phase is only used on larger projects, as smaller ones don t need as much planning, During the Elaboration phase, the developers are expected to understand and capture the majority of the system requirements, understand any known risks and to establish and validate risk factors. The plan should be developed in this phase, using case diagrams and class diagrams. The construction phase is the largest phase of the project; this phase is the building of the majority of the system, using the planning of the Elaboration phase. Each iteration results in an executable release of the software. The final part of the project is the transition phase, feedback is received from the initial releases of software and change is made accordingly. The transition phase also include system conversations and user training. There are milestones to mark the end of each phase.

Fig.8 An example of the Unified Process (Ambysoft, 2005)

20

Matthew Nieuwenhuys
Strengths to the Unified Process

i7985441

y There is a lot of communication between developer and user during the transition phase, allowing changes to the final project therefore leading to a more successful product. This phase can be repeated a number of times y Stakeholders can see evidence of progress as the system is built during the construction phase

Weaknesses to the Unified Process

y There needs to be a good plan of the project, as the majority of this is done through outlines, requirements, schedules and objectives in the very first stage. If this is not achieved the developer could get the wrong impression creating more issues later on and wasting man hours y It is hard for the developer to estimate when the project is finished as their can be a lot of perfecting and not as many deadlines

Conclusions
What we can understand from all 8 methodologies is that they are all for software development, and are either iterative meaning the repetition of an action, or linear where you cant go back on previous work done, and in some cases both. The type of methodology should reflect on the project in hand, for example game development has be liable to change; therefore the methodology used has to be iterative. Not all methodologies lead to a final outcome, for example the prototyping approach leads to the incremental, spiral or RAD approach. y Spiral approach is suitable for Gaming y RAD is suitable for quickly developing software such as free downloadable applications i.eWinZIP, Iphone applications y Incremental Approach is good for creating Web Information Systems y Prototyping is generally used for things with a big budget, as testing costs money. Could be used with hardware and software, an example could be the iPad y The Waterfall approach is used for larger mainframes, such as a database in a hospital

21

Matthew Nieuwenhuys

i7985441

Comparison between 2 methodologies used within the Media Industry

In order to get a better scope on which methodology is potentially better than another, a comparison needs to take place as if a project was going ahead. The project example used within the report will be on the creation and development of a website. The 2 approaches used will be the Waterfall approach andthe Unified Process. As it is the creation of a website, the modeling language used throughout this process would be HTML. Both methodologies would use the same tools for the project, Adobe Photoshop and Dreamweaver. Adobe Photoshop would come at the development stage of both methodologies and Dreamweaver would come at the implementation stage. The waterfall approach would attain a detailed plan exactly of what theme the website needs, whether it is formal or informal, type of audience targeted, any information needed, pictures etc. Once the information is gathered, and the requirements have been forecast, and the customer is happy with what has been planned, only then can they move on to the next stage, which is designing the system.The developer designs the system with all information gathered, and the customer has no more involvement in the creation process. Once the Website is created it is coded, tested and implemented, and finally given back to the customer as a completed project.Once it is tested an all working the website can go live and maintenance is maintained throughout. y The waterfall approach is good, as the customer doesn t need to be involved once the design stage is completed; they just come away with a final website once it is done. y This would be good for the creation of a smaller website, where there isn t as much attention to detail. y More diagrams, descriptions and planning would go into the Waterfall approach, meaning they would have to have a completely solid idea on what they want their website to look like. y Progress is measurable so the customer knows when the product will be complete The first stage of the Unified Process would only be used during bigger projects, website design is generally a larger project so the inception phase would be included. The developer would establish the scope of the project, understand what its all about, and assess what needs

22

Matthew Nieuwenhuys

i7985441

to be included. Also any problems with the requirements would be noted in this process, estimates and schedules will be made on development time. Once the customer feels enough information has been given then they will move onto the next phase. The elaboration phase wouldn t need to be included as there isn t much risk in creating a website, and if there is, it would have been mentioned in the inception phase. The construction phase would be when the website developer goes ahead and makes the majority of the website. Finally, the transition phase would commence, where the developer would get any feedback from the customer. Any improvements needed on the website or any changes would be mentioned, and the developer is allowed to go back and change anything accordingly. The website then gets tested to make sure its online and working before being finished. y The Unified Process could take a lot longer to get the final outcome because the customer will be interfering more. y Although due to this customer input it could be argued that the outcome is better and more suitable for the customer, resulting in a better website. y The customer would be able to change content on the website if they need to keep up with competition in the market, for example, websites involving high end technology would need to keep up with new innovations. From this analysis, it could be said that the Unified Process caters much more for the needs of website development, as the customer input throughout helps a lot towards the final outcome. The waterfall approach would be much better for making a movie, as it requires much more attention to detail along the way, and a movie would have a higher budget. It could be said that most of the methodologies listed could be used for Website development. The prototyping method, leading onto the incremental approach could be very good with website development. The developer could show prototypes to the customer with what it looks like, and any issues could be raised, more prototypes would be made accordingly and a final website would eventually be created.

23

Matthew Nieuwenhuys
Conclusion

i7985441

When making comparisons between a creative technology project and a software engineering project, consideration towards the size of the project must be made aware. Something like a website is generally on a smaller scale in comparison to making software, where as making a movie is different. The stages of making a movie reflect a lot more to software engineering: y y y y y y Development of Brief (idea from the producer) Pre Production (Planning the movie, storyboards etc.) Production (Making the movie, cameras, lighting) Post-Production (Editing and Mastering using Final Cut Photoshop etc.) Distribution (Distributing the movie) Exhibition (showing the movie)

As the methodologies are normally in such a formal approach though, movie creation could be restricted as there is so much creativity behind them. Documentaries would work very well with the software engineering methodologies as it comes along a lot more formal and has a more definitive outline, much like the planning in software engineering. To conclude, Software development methodologies can be asserted into the media industry, although there are flaws in almost every one, as there not designed for the Media. The approach most suited for the media would be the Spiral approach for game development as changes can be made throughout and plans are often vague.

24

Matthew Nieuwenhuys
References
Websites and Articles
Agile Manifesto, 2010, Principles behind the manifesto (online) http://agilemanifesto.org/principles.html Date accessed: 15 December 2010

i7985441

Blogspot, 2010, Iterative and Incremental Methodology (online) http://qtp.blogspot.com/2010/01/iterative-incremental-methodology.html Date accessed: 15 December 2010 Chris Krimble, 2010, Subject Orientated Methodologies: The Next Generation (online) http://www.chris-kimble.com/Courses/sdm/Session_6.html Date accessed: 15 December 2010 Dictionary, 2010, Methodology (online) http://dictionary.reference.com/browse/methodology Date accessed: 15 December 2010 ETC, 2010, Prototyping Approach (online) http://wwetc.com/UoR/WhPp/Prototyping.html Date accessed: 15 December 2010 Hit, 2010, Object-Oriented concepts (online) http://qtp.blogspot.com/2010/01/iterative-incremental-methodology.html Date accessed: 15 December 2010 PR log, 2010, Prototype advantages and Rapid Prototyping Benefits (online) http://www.prlog.org/10086609-prototype-advantages-and-rapid-prototypingbenefits.html Date accessed: 15 December 2010 Selectbs, 2010, What is the Waterfall Model? (online) http://www.selectbs.com/adt/analysis-and-design/what-is-the-waterfall-model Date accessed: 15 December 2010

25

Matthew Nieuwenhuys

i7985441

Wikipedia, 2010, Agile Software Development (online) http://en.wikipedia.org/wiki/Agile_software_development Date accessed: 15 December 2010 Last modified 16 December 2010 at 12:06 Wikipedia, 2010, Waterfall Approach (online) http://en.wikipedia.org/wiki/Waterfall_model Date accessed: 14 December 2010 - Last modified 15 December 2010 at 09:15 Wikipedia, 2010, Software Development Methodology (online)http://en.wikipedia.org/wiki/Software_development_methodology Date accessed: 15 December 2010 - Last modified 1 December 2010 at 12:52

Book Reference
David Avison, 2006, Information Systems Development, methodologies, techniques and tools, 4th edition. page 389, 469 - 496

26

Matthew Nieuwenhuys
Diagram References
Ambysoft, 2005, Life Cycle Agile Approaches (online) http://www.ambysoft.com/artwork/lifecycleAgileUP.gif Date accessed: 15 December 2010

i7985441

Blogspot, 2010, Waterfall Diagram (online) http://1.bp.blogspot.com/_XssPkKcg3tc/TIzPh2WroAI/AAAAAAAAAMc/4vPbGPkgBAs/s1600/wate rfall_model1.png Date accessed: 15 December 2010 CMS, 2008, Selecting a Development Approach (online) http://www.cms.gov/SystemLifecycleFramework/ Date accessed: 15 December 2010 UFCG, 2010, Software Development (online) http://dsc.ufcg.edu.br/~ledo/softwareDevelopmentLifeCycle.jpg Date accessed: 16 December 2010 Wikimedia, 2010, Spiral Diagram (online) http://wysterdesir.com/blog/wp-content/uploads/2008/09/radanimated2.gif Date accessed: 15 December 2010 Wysterdesir, 2010, RAD Animated (online) http://wysterdesir.com/blog/wp-content/uploads/2008/09/radanimated2.gif Date accessed: 15 December 2010 Eton Digital, 2010, RAD Diagram (online) http://www.etondigital.com/wp-content/post-images/rad-diagram.gif Date accessed: 15 December 2010 Live File Store, 2010, Object-Oriented Diagram (online) http://5uaopw.blu.livefilestore.com/y1pfY5dRxfv3DgwjDXFXzMHSv6b4d8k5_Q1amxSBGv9TSamLO WqgfzA27drI6pt7-7SM-p1vH63q6c/Taxonomy%204.jpg Date accessed: 15 December 2010

27