Information Systems Development Literature Review Essay

1.0 INTRODUCTION

A methodology can be defined as a technique, utilised to collate information employing a sequential method to store data. A framework can be defined as hypothetical outline influenced by a philosophical theory interpreted by the developer/developers, adapted to their scenario to implement a development. An approach can be defined as a Method, System or Framework used to implement a development.

Since the 1960’s Methodologies, Frameworks, Approaches and CASE tools have evolved providing more effective and efficient strategies intended for systems development. During the evolutionary period which is still preceding today a shift within paradigms brought forth the ideas regarding Soft Systems Methodologies, which began to take into account the socio-technical, political and User involvement when developing systems. This idea withdrew from structured approaches which were seen as inflexible and impractical to manage the developments within present dynamic organisations.

Methodologies are still currently being used within organisations, however companies are developing more tailored approaches to suit their companies. This enables developers to respond quickly and efficiently within these dynamic environments. Methodologies evidently present a controlled condition in which complex systems can be developed.

2.0 LITERATURE REVIEW

2.1 Development Approaches

A choice of numerous development Methodologies, Approaches and Frameworks can be employed within systems development while conducting the several phases for example analysis, design, implementation and evaluation across the broad spectrum in which IT projects span. Through utilising a wide variety of resources a clear succint description of these has been provided, delineating philosophies and stating techniques adopted convey within table 2.1-1 located within appendix A.

2.2 Structured Methods

Refering to appendix A JSD, SSADM, YSM, Merise and IE can be described as structured approaches. Structured approaches provide “…the concepts for structured programming…applied to analysis and design, and techniques (such as data flow diagramming)…” Avison, D.E ; Fitzgerald, G. (2003). Enabling a meticulous, methodological process in which information systems can be developed involving a number of stages.

Throughout the 70s and 80s a number of manufactures marketed structure methodologies. One inparticular SSADM “…used in a number of government applications since 1987.” Avison, D. ; Fitzgerald, G. (2006). Information Engineering “…developed in Australia in the late 1970’s.” Avison, D. ; Fitzgerald, G. (2006). Also YSM pioneered in 1989 by Edwards Yourdon. “Of these, the most popular was the Yourdon/Demarco approach, which used data flow diagrams to represent user requirements, and a technique called functional decomposition the refine the model under construction.” Bowles, A. (1990).

YSM “…has attempted to move away from pure functional decomposition towards something called event partitioning… ” However this is debateable as techniques such as dataflow and entity relationship diagrams are still employed. This “…systematically guides the analysis process and provides much more rigor to the method” (Bowles, A., 1990).

A number of developments have been conducted within YSM establishing versions 1.0, 2.0 and 3.0. Bowles, A. (1990) “…recognized that the methods needed enhancements to cope with real-time systems demands, and extensions were developed…” Identifying three main orthogonal view points to illustrate systems development. YSM “…covers both the activities of the organisation…and the system itself” Avison, D. ; Fitzgerald, G. (2006).

2.3 Object-Oriented Approach

Within Appendix A, a brief outline has been provided of the Object-Oriented and the RUP approach. “Object-Oriented methods allow the developer to exploit the technology of distributed computing environments, Internet-based systems and communications software and tools.” Yeates, D. ; Wakefield, T. (2004).

RUP a derivative of the object-oriented approach “…is described as a ‘software engineering’ and a ‘configurable process framework’, referring to the fact that it can be modified to accommodate the specific needs, characteristics, constraints, and history of the organisation, culture, and domain in which it is used.” Fitzgerald, B., Russo, N.L. ; Stolterman, E. (2002).

RUP gained its acknowledgement through the standardisations of the Unified Modelling Language (UML) notation. As mentioned within appendix A, “…you also need to know how to use it…” Avison, D.E ; Fitzgerald, G. (2003). This was affectively where the methological process of RUP became widespread, identified as “…probably the most widely used methodology…” Grunner, S., Klopper, R. ; Kourie, D.G. (2007). Also supported by IBM stating, “In 2002 rational Software was acquired by IBM, including RUP…they purchased Rational because…These aspects complement and reflect IBM’s strategy…RUP has now become the IBM Rational Unified Process.” Avison, D.E ; Fitzgerald, G. (2003).

RUP identifies numerous advantages for instance, enabling code reuse, adapts readily to the current environment, effective documentation and open access to published and supported materials. This positive analysis is further supported stating “…a strategy for developing artefacts and deliverables, and also information on how to perform design and development tasks…” Fitzgerald, B., Russo, N.L. ; Stolterman, E. (2002). However RUP disregards sociological aspects within software development and can lead to unsystematic developments due to the procedures and level of difficulty involved. “Unless you have a real expert, it is unlikely that you will succed in adapting to this process.” Anwar, S., Khan, O.A., Pirzada, U.T. ; Shahid, N. (nd).

2.4 Soft Systems Methodology

Appendix A provides a brief outline of SSM. SSM philosophy proposes “…the whole is greater than the sum of the parts…” Avison, D. ; Fitzgerald, G. (2006). Implying system development should be created for entire organisations opposed to the departmental areas within. Checkland sort to argue both the philosophical and practical approach applied within SSM through numerous research projects stated within”…fully documented Checkland (1981, Wilson (1984), and modified format in Checkland and Scholes (1990)…” Conducted “…through ‘action research’ whereby the systems ideas are tested out in client organisations” Avison, D. ; Fitzgerald, G. (2006).

SSM “acknowledges the importance of people in an organisational context and attempts to make sense of complex human activity systems which are characterised by fuzzy or messy problem situations.” Avison, D. ; Fitzgerald, G. (2006). The shift in paradigms enables human activity and system development to communicate more effectively highlighting essential attitudes, objectives and perceptions.

3.0 LITERATURE REVIEW OF THE CASE TOOL

“Computer-assisted software engineering (CASE) tools are a set of programs and aids that assist analysts, software engineers, and programmers during all phases of the system development life cycle.” Barclay, S. et al. (nd). Furthermore they can be identified as a “…computerbased product aimed at supporting one or more techniques within a software development method.” Jarzabek, S. ; Huang R. (1998).

CASE tools are provided as a means to simplify the difficulties faced within system development. “CASE (computer-aided software engineering) tools have generated much interest among researchers and practitioners as potential means for easing the software development and maintenance burden threatening to overwhelm information systems (IS) departments.” Orlikowski, W.J. (1993). Also established “…to increase productivity, improve the software product quality and make Information Systems (IS) development a more enjoyable task.” Jarzabek, S. ; Huang R. (1998).

CASE tool development began within the 70s firstly providing basic tasks such as word processing, which further led to creation and manipulation of structured and software design techniques. “The seventies saw the introduction of graphical techniques and structured data flow diagrams…The introduction of CASE tools to aid this process allowed diagrams to be easily created and modified, improving the quality of software designs.” Barclay, S. et al. (nd). Throughout the 80s and 90s Case tools developed from providing specific analysis and design tools to incorporporating data dictionaries and system testing generating a development cycle instrument. “Eventually, graphic tools integrated with data dictionary databases to produce powerful design and development tools that could hold complete design cycle documents. As a final step, error checking and test case generators were included to validate software design.” Barclay, S. et al. (nd).

Within large organisations a number of CASE tools are used stated below:

* Select SSADM

* Oracle Designer

* Visual Paradigm for UML

* IBM Four-Gen CASE tool

Throughtout the years, numerous studies have been conducted to determine the significance and usefulness of CASE tools. It has been stated that “…prior studies have shown that CASE tools have little or no effect on productivity and a relatively weak effect on the quality of specifications produced.” Vessey, I. et al. (1992). However the choice of CASE tool employed in relation to the project being development is somewhat important as this can affect the overall outcome. “…the decision of which one will best fit your needs is not an easy one…failure or success of the tool is relative to your expectations…a clear understanding of the specifications and expectations of the CASE tool are of upmost necessity before beginning…” Barclay, S. et al. (nd).

In selecting the appropriate CASE tool a number of benefits can be established; Barclay, S. et al. (nd) states from a researched point of view that CASE tools:

“ensure consistency, completeness and conformance to standards…encourage an interactive, workstation environment…speeds up development process…allows precision to be replicated…reduces costs, especially in maintenance…increases productivity…makes structured techniques practical.”

Through further researched regarding the design aspect, “The archiving facility in the Case tool allows parts of designs to be stored in a form where they can be loaded in to another tool. This means that a library of commonly used parts of designs can be set up.” Batty, P. et al. (1994). This effectively provides independent simultaneous development providing “…two main benefits: firstly the development time for new applications is greatly reduced; secondly, the quality of developed applications is improved.” Batty, P. et al. (1994).

However research has indicated that “70% of the CASE tools are never used, 25% are used only by a limited number of people in the organisation, and 5% are widely used but not to capacity.” Campos, P. (nd)

Due to these findings a possible downside can be observed when employing a CASE tool

to development software/Information systems. “One drawback is that CASE tools do not necessarily prevent people from making bad designs.” Database Journal. (2005). Therefor no matter the proficientcy of a CASE tool, the outcome of a system also depends upon the level of competence and knowledge displayed by the developer. Database Journal. (2005).

Another potential “…drawback is the cost of using these tools.” Ice Breaker web designs. (2002). Complex CASE tools used within large organisation can range from a free limited trail package to $2000 in the US. Most large organisation would require complete functionality inevitably producing a large initial overhead charge. Many of the CASE tools utilised will require updates this again could potential incur extra changes to provide patches to improve the current operative versions.

4.0 THE CHOSEN IS DEVELOPMENT APPROACH

After conducting a thorough literature review critically evaluating methodologies and case tools. SSADM was selected to develop Positively VETTED Veterinary system, due to SSADM’s various prior successes and its ability to model information.

The rationale behind this decision was identified through the modelling perspective and techniques utilised to develop information systems identified below.

* Functions – “This is an attempt to capture the user’s view of system processing. Techniques used include data flow modelling”

* Events – “These are business activities that trigger processes to update system data. Techniques involved include entity life histories and effect correspondence diagrams”

* Data – “This is a description of the data used in the system utilising a logical data model.”

Rogerson, s. (nd).

Each perspective enables vital elements to be modelled identifying the various required components. Illustrating each aspect of a system effectively increases the accuracy and integrity in which systems are developed.

Within the five module framework which SSADM incurs, seven stages are included:

* Feasibility study

1. Economic and Technical feasibility study

* Requirements Analysis

2. Determine project scope

3. Establish IT Integration

4. Cost/benefit analysis

5. Project Viability

* Requirement Specification

6. Definition specification including, Objectives, Processes, Data modelled, Functions, Prototypes

* Logical System Specification

7. Technical Specification

8. Logical System Design

* Physical Design Module

9. Physical Design

SSADM provides a thorough approach to the analysis and design phases of systems development, however little has been stated in the way of implementation, testing and maintenance. Within the majority of projects these are focal areas which developers manage to examine, improve and increase information systems life span. Positively VETTED only requires modelling of the analysis and design phases to be represented therefore this approach is sufficient to display this criteria.

The techniques within SSADM were utilized to develop diagrammatical illustrations representing Positively VETTED Veterinary System:

* Business Activity Modelling

* Entity Matrix

* Context Diagram

* Data Flow Diagram (DFD)

* Logical Data Model (LDM)

* Entity Life History (ELH)

SSADM provides numerous advantages stated within an educational resource document identifying:

* Excellent level of user involvement

* Highly documented developments

* Differenciation bewteen logical and physical components

MIT Notes Home. (2007).

Nevertheless disadvantages are identified “Large, complex and highly detailed methodologies such as SSADM are sometimes known as monolithic, making them less attractive for small scale projects. Not only must the analysis team understand the documents but so too must the programmers themselves to be able to produce the system from the output of the methodology.” Therefore detailed processes may increse both time and reduce productivity factors within systems development. MIT Notes Home. (2007).

5.0 CONDUCTING THE ANALYSIS AND DESIGN

When developing a solution for Positively VETTED Veterinary System a number of techniques were used to understand and determine the necessary requirements.

Firstly a Business Activity Modelling was conducted “…in SSADM…the technique to find out what is going on in the environment of the system under investigation” Weaver, P et al. (2002). “These activities are the actions usually performed by humans, with or without the aid of systems, which deliver the organisations primary tasks.” Weaver, P et al. (2002). Therefor this process identifies each trigger and the subsequent events until the process is complete. This diagram can be located in appendix B.

Secondly the development of a Context Diagram “…a DFD that shows the entire system as a single process, with data flowing between it and the outside world as represented by external entities.” Weaver, P et al. (2002). Illustrating an overall view of this system successfully conveys the system boundaries identifying what inputs and outputs are required from Positively VETTED Veterinary System. This diagram can be located within appendix C.

Thirdly through utlising the Business activity Model and the Context Diagram a DFD was developed which “…enables a system to be partisioned (or Structured) into independent units of a desirable size so that they, and thereby the system, can be more easily understood.” Weaver, P et al. (2002). Through identify external entites, processes, data flows and data stores, these were then modelled within appendix D.

Fourthly an Entity Matrix was created “…to check all possible pairings of entities considered…” Weaver, P et al. (2002). This process effectively conveys a relationship between entities if conducted correctly and consistently utilising other documentation accomplished modelled within appendix E.

Fifthly a Logical Data Model (LDM) was created to decipher “what it is that the system actually holds data about and exactly how this data truly interrelates”. Weaver, P et al. (2002). The LDM constructed comprises of entities and relationships, Entities being “Any object or concept about which a system needs to hold information…” Weaver, P et al. (2002). Relationships indicating how each entity relates to another located in appendix F.

The sixth and final step involved the creation of an Entity Life History (ELH) diagram documenting “…all of the events that can affect an entity. They model the business rules applicable to the processing of a particular entity, and thus specify allowable sequences and combinations of events.” Weaver, P et al. (2002). ELH diagrams consists of three fundamental elements, Creation, Modification and Deletion, these principles have been illustrated within appendix G.

6.0 EVALUATION OF THE APPLICATION OF METHOD

Utilizing SSADM to develop Positively Vetted Veterinary system proposed a method whereby deliverables were produced through a number of techniques, to model the different functions, events and data present within this system, corectly stated by Rogerson, s. (nd).

The techniques included were very much successful identifying numerous inputs, processes and outputs, combined and intended to replicate the written case study provided, in a way sufficient for ISD.

Through diagramatically illustrating this system presents standardised documentation enabling several developers, understanding this notation to analyse and comprehend this information if they were to implement this system. However employing SSADM to develop this system nevertheless identified various drawbacks stated below.

* Structure

* Deliverables

The five modules included within SSADM outline the life cycle comprising of a significant amount of both written and diagrammatical deliverables. Due to the scope of this development being a small not a large scaled project which SSADM is originally intended for, a number of these weren’t conducted, e.g. the entire Feasibility study, elements of the Requirements analysis, Requirements catalogue etc. This methodology does include a detailed thorough account correctly stated by author MIT Notes Home. (2007).

During the development of this project a number of fundamentals were brought to light, highlighting the impact of utilizing SSADM as a development Methodology that also applies to most development methodologies. Methodologies have the ability to identify tasks conducted within each module however they fail to recognize and state how developers use this information to progress from one stage another with regards to actually carrying out the analysis, design stages etc. This is evident as SSADM futures five modules but no explanation with regards to how developers interact between these.

Evolutionary approaches have lead towards organisations employing “commercial methodologies adapted for in-house use” also “methodologies which they claim to be unique to their organisation…” Avison, D. & Fitzgerald, G. (2006). If an alternative approach had to be identified for this scenario, an evolutionary approach tailored to Positively Vetted would have been employed. Embracing the techniques within SSADM, due to the fact that developers tend to use techniques which they are readily familiar with. Also the political viewpoint of the Effective Technical and Human Implementation of Computer-based Systems (ETHICS), a People-oriented methodology and SSM, an Organisational-oriented methodology, encompassing a socio-technical perspective. These three methodologies would effectively broaden the perspective for the developers, ensuring they are well equipped to develop solutions from a well informed viewpoint, if these methodologies are conducted suitably. In addition to this numerous stakeholders would have an input improving their overall understanding of what and why particular systems are to be developed.

7.0 EVALUATION OF THE APPLICATION OF THE CASE

Oracle Designer was employed as the CASE tool to develop Positively Vetted information system. This CASE tool provided useful functions as this enabled the development of Business Process Models, Function Hierarchies, Data Flow Diagrams and Logical Data Models, which in turn can be transformed into a relational database. This CASE tool was satisfactory to illustrate each input, process and output required however, to combine these elements to effectively generate the database caused immense difficulty. Due to the functionalities and limitations of this tool my capabilities were minimised hindering the creation of this database.

The limitations discovered were within the Repository Navigator, as it became somewhat difficult to remove incorrect imputed information without understanding and utilizing SQL script commands within SQL Plus 11g. Oracle Designer automatically generates SQL script commands from the information entered within the user interface. Also when errors occurred when attempting to generate the database, this CASE tool doesn’t provide sufficient information to help you determine the root cause of the problem.

Barclay, S. et al. (nd) identifies that a CASE tool is utilized for specific reasons, to “…ensure consistency… precision…speeds up development process… increases productivity…” With regards to ensuring consistency the author is correct as any conflicting details were flagged and highlighted to the developer, nevertheless experience utilizing this CASE tool identified that this doesn’t increase productivity as the number of errors detected take time to debug or even can result in developers having to restart the development if they aren’t aware of how to rectify the issues presented. Utilizing SQL Plus 11g could alternatively be a better solution, as developers tend to understand their commands imputed better than automatically generated syntax including irrelevant information.

To conduct this development utilizing an alternative CASE tool Select SSADM would have been employed, “…providing advanced features to support systems development activities using SSADM techniques.” Select Business Solutions, INC. (2003). Select SSADM has the ability to provide consistency, intelligent integrated modelling supporting numerous SSADM modules, techniques and application objects. In addition Select SSADM enhances project management and application quality, meeting business requirements, improving application independence whilst reducing errors. Select Business Solutions, INC. (2003).

8.0 CONCLUSION AND RECOMMENDATIONS

It’s vitally important when engaging within ISD that any methods, methodologies, approaches or frameworks are tailored to the particular organisation in question. As identified that many of these are not fit for purpose, as they require adaptation proven within chapter 6.0, to fit the organisations culture, system users and technological developments. Pertaining to SSADM and ISD, this methodology can be seen as too complex for quickly adapting organisations. This concern potentially is problematic with regards to the current demands/requirements of present day system users, which they place on system developers. To implement solutions quickly and effectively due to the fast paste revolutionising dynamic enviorments in which they are employed.

Methods, Methodologies, Approaches or Frameworks most importantly need to incorporate a mangerial concept to ensure projects are controlled continuously, reducing time/budget overruns resulting in project failures due to a substandard management style. Identified within the Standish Group Reoport highlighting “…almost a third experienced cost overruns of 150 to 200%…over one-third also experienced time overruns of 200 to 300%.” The Standish Group. (1995).

A number of ISD’s have been introduced into organisations under estimating the technological requirements of system users. Evident within the London Ambulance System Computer Aided Dispatch (LASCAD) scrapped in 1992, costing �2.5 Million and resulting in the deaths of atleast 20 individuals. Therefore ISD should be implemented in a way whereby solutions should be developed progressively, departmentally conducting thourough quality assurance and system testing. To define problems which can then be rectified before an entire operation is made live, this can be trialed in many ways for example through the use of a pilot study. However while conducting thourough on going testing problems can still go undetected present within the “…marriott and Hilton Hotels…failed reservation system…” Standish Group. (1995).

CASE tools have been identified to increase ISD, however only if the relevant most compatible tool is employed acknowledged within chapter 7.0. Nonetheless if developers were entirely comfortable utilizing a CASE tool, given their provided with the right amount of training, they most inevitably will display an improve level of performance with regards to productivity. Consequently these are the underlying factors organisations need to consider when employing a CASE tool for ISD.

Another fundermental issue highlighted no matter what methodology is used to develop a project, this is only as effective as the developers. “…the fact that it is people, not methods, who develop systems” Rowlands, B.H. (2005). With regards to their personal skills, knowledge and technical abilities applied. Therefore no matter how well suited a methodology is to a development, this isn’t the only factor determining development success. As methods-in-action are affected and influence by the Development context, Developers, Formalised methods & Roles of Methods acknowledge by Fitzgerald et al 2002.

On the other hand SSADM doesn’t take into account the ability of the developers, the organisations culture identified via the Development context and the Roles of Method. Therefore how well can this methodology address the needs of all system stakeholders?

9.0 REFERENCES

Anwar, S., Khan, O.A., Pirzada, U.T. & Shahid, N. (nd). Rational Unified Process. Journal Title.[Online]. Available from: http://ovais.khan.tripod.com/papers/Rational_Unified_Process.pdf [Accessed: 16th April 2009].

Avison, D. & Fitzgerald, G. (2006). Information Systems Development methodologies, techniques & tools. Maidenhead:McGram-Hill Education.

Avison, D.E & Fitzgerald, G. (2003). Where Now for Development Methodologies?. Communication of the ACM. 46(1) pp.79-82.

Barclay, S. et al. (nd). CASE TOOLS. [Online]. Available from: http://educ.queensu.ca/~compsci/units/casetools.html [Accessed: 19th April 2009]

Batty, P. et al. (1994). USE OF INTEGRATED CASE TOOL FOR GIS CUSTOMISATION. Smallworld Systems LTD. 1(1) pp 852-859 [Online]. Avaliable from: http://libraries.maine.edu/Spatial/gisweb/spatdb/egis/eg94097.html [Accessed 20th April 2009].

Bowles, A.J. (1990). A note on the Yourdon Structured Method. Software Engineering Notes. 15(2) pp. 27.

Campos, P. (nd). User-Centered CASE Tools for User-Centered Information Systems. pp.1-1-

Database Journal. (2005). Making the Case for CASE Tools. [Online]. Available from: http://www.databasejournal.com/features/oracle/article.php/3525621/Making-the-Case-for-CASE-Tools.htm [Accessed 20th April 2009].

Fitzgerald, B., Russo, N.L. & Stolterman, E. (2002). Information Systems Development: Methods in Action. Maidenhead:McGram-Hill Education.

Grunner, S., Klopper, R. & Kourie, D.G. (2007). Assessment of a Framework to Compare Software Development Methodologies. ACM International Conference. 226(1) pp. 56-65.

Hutchings, T. (1996). Introduction to Methodologies and SSADM. [Online]. Available from: http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.html [Accessed: 13th April 2009].

Ice Breaker web designs. (2002). Database Answers. [Online]. Available from: http://www.databaseanswers.com/modelling_tools.htm [Accessed: 20th April 2009].

Jarzabek, S. & Huang, R. (1998). CASE tools need to become more useful if they are to be applied to the practice of software production. The CASE for User-Centered CASE Tools. 41(8). pp. 93-94. [Online]. Available from: http://portal.acm.org/citation.cfm?id=280338&coll=&dl=ACM&CFID=15151515&CFTOKEN=6184618 [Accessed 10th April 2009].

Lambrou, N., Walkley, M., & Weaver, P. (2002). Practical Business Systems Development Using SSADM: A Complete Tutorial Guide. Harlow: Pearson Education Limited.

MIT Notes Home. (2007). Methodologies and the SSADM methodology Chapter 2. Lifecycles and development methods. [Online]. Available form: http://www.cs.uct.ac.za/mit_notes_devel/SE/Latest/html/ch02s07.html [Accessed: 20th April 2009].

Orlikowski, W.J. (1993). CASE Tools as Organizational Change:

Investigating Incremental and Radical Changes in Systems Development. Management Information Systems Quarterly Best Paper of 1993. 17(3) pp 1-32 [Online]. Available from: http://www.misq.org/archivist/bestpaper/misq93.html [Accessed 15th April 2009].

Rogerson, s. (nd). An ethical review of information systems development and the SSADM approach. [Online]. Available from: http://www.ccsr.cse.dmu.ac.uk/staff/Srog/teaching/ssadm.htm [Accessed: 19th April 2009].

Rowlands, B.H. (2005). Grounded Theorising Applied to is Research – Developing a Coding Strategy. AJIS. 12(2) pp. 121-133.

Select Business Solutions, INC. (2003). SelectSSADM. [Online]. Avaliable from: http://www.selectbs.com/adt/images/stories/datasheets/ds_Select_SSADM_a4.pdf [Accessed: 7th June 2009].

The Standish Group. (1995). Chaos Report. The Standish Group Report. 1(1) pp. 1-8.

Vessey, I. et al. (1992). Implications of the findings. Evaluation of Vendor Products: CASE Tools as methodology companions. 35(4). pp. 100-101 [Online]. Available from: http://portal.acm.org/citation.cfm?id=129860&coll=&dl=ACM&CFID=15151515&CFTOKEN=6184618 [Accessed 14th April 2009].

Yeates, D. & Wakefield, T. (2004). Systems Analysis and Design. Essex: Pearson Education Limited.

10.0 Bibliography

Avison, D. & Fitzgerald, G. (2006). Information Systems Development methodologies, techniques & tools. Maidenhead:McGram-Hill Education.

Fitzgerald, B., Russo, N.L. & Stolterman, E. (2002). Information Systems Development: Methods in Action. Maidenhead:McGram-Hill Education.

Lambrou, N., Walkley, M., & Weaver, P. (2002). Practical Business Systems Development Using SSADM: A Complete Tutorial Guide. Harlow: Pearson Education Limited.

Tudor, D.J. & Tudor, I.J. (1997) Systems Analysis and Design. London: MACMILLAN PRESS LTD.

Yeates, D. & Wakefield, T. (2004). Systems Analysis and Design. Essex: Pearson Education Limited.