Information systems development literature review. Since the 1960s Methodologies, Frameworks, Approaches and CASE tools have evolved providing more effective and efficient strategies intended for systems development.

Authors Avatar

Comparative Information Systems Development                                            Hayewood Barnett C05300856


Contents

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
  1. Determine project scope
  2. Establish IT Integration
  3. Cost/benefit analysis
  4. Project Viability
  • Requirement Specification
  1. Definition specification including, Objectives, Processes, Data modelled, Functions, Prototypes
  • Logical System Specification
  1. Technical Specification
  2. Logical System Design
  • Physical Design Module
  1. 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.

Join now!

  • 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 ...

This is a preview of the whole essay