methodolgy lifecycle

Hassan Azimi Appendix A - Methodologies and Lifecycles

Academic Objective 1 – Methodologies and Lifecycles

A1 Analysis of the Methodology and Lifecycle to be Used

A1.1 Introduction..............................................................................................1A1.2 Waterfall Development Model..................................................................2Advantages......................................................................................................2Disadvantages..................................................................................................3A1.3 Prototyping...............................................................................................3Advantages......................................................................................................4Disadvantages..................................................................................................4A1.4 Prototyping Advances..............................................................................5A1.4.1 Spiral Development Process.................................................................5Advantages......................................................................................................6Disadvantages..................................................................................................6A1.4.2 Incremental Development.....................................................................6Advantages......................................................................................................7Disadvantages..................................................................................................7A1.4.3 Iterative Development Process.............................................................7Advantages......................................................................................................8Disadvantages..................................................................................................8A1.4.4: Rapid Application Development...........................................................8Advantages......................................................................................................9Disadvantages..................................................................................................9A1.4.5: Dynamic Systems Development Method (DSDM).............................10Advantages....................................................................................................12Disadvantages................................................................................................13A1.5 Structured Systems Analysis and Design Method (SSADM).................13Advantages....................................................................................................15Disadvantages................................................................................................16A1.6 Conclusions...........................................................................................16

A1.1 IntroductionThis section will analyse the different methodologies and lifecycles available in developing an information system. A methodology is defined as “…a system of ways of doing things especially regular and orderly procedures”1.This section discusses in depth the various merits and downfalls of different development strategies. Such strategies include that of Rapid Application Development, Prototyping, The Spiral Model, Dynamic Systems Development and Tom Gilb’s Incremental Development. There are also a number of other methodologies available such as Jackson Systems Development (JSD) and Effective Systems and Human Implementation of Computer based System (ETHICS). However, the objective is to evaluate those methodologies available to the developer, which are more suited to database applications, in order to select the most appropriate one for this projects development.

1 “Introduction to Methodologies and SSADM”

- 1 -


A1.2 Waterfall Development ModelAlso referred to as the Systems Development Life Cycle Model (SDLC).The focus of the waterfall model is to ensure that the internal architecture is well structured, to meet basic quality criteria and is described as “an approach to developing an information system… that is characterised by a linear sequence of steps that progress from start to finish without revisiting any previous step”2.The five common stages comprise (illustrated in figure 1.1):

1. AnalysisHere the system requirements are gathered and defined. Any existing systems can also be evaluated and any inefficiency can be highlighted.

2. DesignA design specification is derived from requirements analysis, where plans are made concerning physical construction, hardware, operating systems, programming, communications and security issues.

3. BuildUsing the design specification, the system is developed and components built. Additionally, the system will also be tested and user training will occur.

4. ImplementThe system is installed and implemented. This can be through either a gradual phased process or through a more cost effective launch of the complete system.

5. Operation and MaintenanceFor a system to remain effective it must be constantly monitored and evaluated. Regular maintenance will ensure the integrity of the system.

Fig. 1.1: Waterfall Development Model3

Advantages Easy to understand Quality built-in throughout Configuration management Clear and defined stages Forced to do analysis and design first

2 http://searchvb.techtarget.com/0,,sid8_gci755068,00.html3 Adapted from “Software Process Models”

- 2 -

http://searchvb.techtarget.com/0,,sid8_gci755068,00.html


Disadvantages Time between agreeing requirements and delivery of final product Risk in confirming customer requirements and user-interface, as there

is no revision Based on paper

A1.3 PrototypingPrototyping has been described as a primary “…aid to building the right software by the simple process of having more than one go at it and learning from the mistakes” (Tate, 1995). So the prime focus of prototyping is to ensure that both users and developers understand system requirements through requirements elicitation and validation, whereby users experiment with prototypes and consequently any errors or requirement omissions are revealed to developers. This can be conducted with all project deliverables, such as:

Specifications Models Code Interfaces

There are two distinct forms of prototyping (illustrated in figure 1.2):1. Evolutionary

Also known as exploratory, production, or operational prototyping, where real data is utilised producing real outputs. Evolutionary approaches use the same target language as the prototyping language, so that the components can be developed and refined further after testing. Each new prototype forms a functional part of the final delivered system. Development would start with well-understood requirements.

2. RevolutionaryAlso known as rapid, throwaway, or non-operational prototyping where the objective is to ensure that system requirements are understood through mock-ups or models. A revolutionary approach usually uses a different language to the target language, as the components are discarded once problems are identified. Thereby, reducing risk by experimentation and exploration before implementation into the final language. Development would start with poorly understood requirements.

Fig. 1.2: Distinguishing Outputs of the Two Approaches4

4 Adapted from Ian Somerville, 2000

- 3 -


Advantages Speedy Delivery

Development time is greatly reduced as several phases can be conducted simultaneously and an operational prototype can be produced in weeks rather than months, alleviating waiting times usually associated with the software process to provide a functional system.

Accurate SystemDue to the active user participation during design and development, along with constant constructive feedback, it is nigh on impossible to produce a system which does not meet requirements.

Reduces Risk and CostAgain, due to active user involvement, errors are detected early on. It has been reported by Gremillion and Pybern (1988) “… that total systems development costs by the prototype approach are usually less than twenty-five percent of the costs with the traditional approach”.

Satisfies UsersAs users are more involved they are more likely to commit to the system and its implementation if they can foresee a system emerging, which meet their specific requirements.

Omits Communication ProblemsCommunication errors usually associated with other system development methodologies are omitted as users can point out discrepancies easier with a working system rather than a paper-based system, ensuring that there are no misunderstandings.

Disadvantages Final System Does Not Evolve

As there are no end of stage reviews it may be difficult to contain the scope of the project and a final system may not emerge even after several attempts. Therefore good project management practice here is essential to avoid delays and meet deadline requirements.

Inadequate DocumentationAs the main emphasis is on producing prototypes, system documentation maybe neglected and is often missing or incomplete.

System IntegrityAgain, if too much focus is placed on prototype production, other system features such as backup, recovery, performance and security maybe become neglected.

- 4 -


A1.4 Prototyping AdvancesPrototyping principals have been developed further and now have modern descendants in the form of RAD, DSDM, and Incremental Development, which all provide their own principals and concepts for how prototyping can be conducted effectively. The remainder of this section will explore these options.

A1.4.1 Spiral Development ProcessBarry Boehm originally devised the spiral model in 1998 (see figure 1.3), and it’s based on an evolutionary prototyping approach coupled with the linear approach of the waterfall method (also referred to as the Evolutionary Spiral Process Model [ESP]).Each turn covers the same sequence of tasks:

Plan next phaseNext phase of the spiral is planned defining project information such as time and resources available.

Determine objectives, alternatives and constraintsAdditional objectives for a specific phase are determined.

Evaluate alternative solutions and resolve risksRisks are identified and alternate solutions may be sought to mitigate risk.

Develop and verify next-level productProducts are developed utilising any available methodologies.

Evaluation of resultsSoftware is evaluated and user feedback is sought.

Fig. 1.3: The Spiral Development Model5

5 Kathrin, M., 2002

- 5 -


As process path spirals outwards, each outward movement will accumulate costs. The main distinction between with the spiral and other methodologies is that “… risks are explicitly assessed and resolved throughout the process”6, this enables risks to be highlighted and resolved before committing to an erroneous system. At the end of each revolution decisions are made as to whether it is still viable and practical to continue with the project. The spiral approach is typically used where there is a large final system and there are unclear or vague requirements.

Advantages Focus is on risk elements, ensuring high development risk is avoided,

providing opportunities to abandon those projects early. Lots of reworking and testing ensures an adequate final system.

Disadvantages May be difficult to estimate cost and project closure times. Small projects will incur relatively high costs. Correct users must be involved in risk evaluation and testing

processes, otherwise information gained is deemed meaningless. Revolutionary prototype features may not be able to be converted into

final implementation language.

A1.4.2 Incremental DevelopmentTom Gilb devised incremental development to be used as a strategy for making progress in small steps to get early tangible results by combining elements from the traditional waterfall model and an iterative prototyping approach. Indeed, the approach may be used in conjunction with an iterative approach. Firstly, the linear sequence of the waterfall model is applied until increment one arrives; this process is then repeated until the next increment of the software is delivered, these processes can be conducted in parallel (see diagram 4). To help achieve this the problem would have to be partitioned into several sub-problems so they can be developed in turn. It is general practice to prioritise requirements, and those high priority requirements are usually incorporated into initial increments. As each partition becomes complete it is tested and integrated with other partitions. Although system requirements are fixed for each increment, the system can be evaluated at each stage to determine future partitions, which permits constant evolution of requirements. However, it is important that the project has milestones (critical dates for completion of major components), with timeboxes within it that clearly allocate resources.

Fig. 1.4: Incremental Development Process7

6 Sommerville, I., 20007 Adapted from Sommerville, I., 2000

- 6 -


Advantages Delivers tangible results towards the final system with each increment. Permits parallel development. Lower risk of project failure compared with other approaches. High priority requirements are usually delivered first, this guarantees

extensive testing of those vital requirements.

Disadvantages Early increments may not be flexible enough to add increments or

requirements; consequently the system architecture may need a complete overhaul.

In some instances it may be impossible to devise comprehensive system requirements.

A1.4.3 Iterative Development ProcessSome authors on occasion use the terms iterative and incremental interchangeably, however, “…they are distinct independent development strategies”8. Whilst incremental development focuses on developing a new system, in contrast, the purpose of iterative development is to allow reworking of part of a system to remove mistakes or to make improvements based on user feedback. After each iteration, an evaluation of the result and planning to improve the correctness of the system and the quality of design would need to occur. The number of iterations that would need to occur could be uncertain depending on how much of the system would need to be corrected, it may therefore be difficult to define an end to the project.

8 Kavanagh, M., 1998

- 7 -


Fig. 1.5: Iterative Development Cycle9

Advantages Any misapprehensions and inconsistencies in requirements are usually

discovered early, so reaction times are quicker, improving overall quality.

Each iteration is closely monitored and progression is tangible after each.

Disadvantages May be difficult to determine the end of a project lifecycle. Open to abuse, developers may provide substandard prototypes as

they can always improve upon it in future iterations.

A1.4.4 Rapid Application DevelopmentRapid Application Development (RAD) responds to the continuous changing requirements of a business in such a competitive world and it aims to deliver systems more rapidly, indeed its main objective is “…speeding up the development process”10. It achieves this through a collection of tools, techniques and methodologies, which actively involves user participation in development of a system in the form of Joint Application Development (JAD) workshops. JAD identifies important users early on and will involve group meetings (with users, stakeholders and developers) to analyse existing systems, collect data and identify new system requirements and solutions. It uses an evolutionary timebox approach rather than a traditional lifecycle approach. A timebox has been defined as a “…period during which work on that particular aspect of the system will be carried out”11. The timeframe is not subjective to change, rather functional requirements are prioritised within the timebox and less essential features may have to wait to be included and built into future iterations. However, RAD has been criticised for being a fairly unstructured approach and there is no commonly defined framework for its completion.

There are four main phases in RAD:

9 Hunger, M., 200010 Avison and Fitzgerald (1995)11 Dashwood, P.E.C. (2001), “Shoot The Rapids, Avoid The Waterfall”

- 8 -


1. Requirements PlanningDuring this phase requirements are defined either through JRP (Joint Requirements Planning) workshops, or through JAD workshops. The distinction between these workshops is somewhat blurred and many organisations now opt to combine the two, however it is vital that the correct users are selected to attend these workshops so that informed decisions and progress can be achieved.

2. User DesignAgain, JAD workshops are utilised in determining user design issues. For example, in the case of a database program, issues such as user interfaces, system processes, data entry methods, screen dialogues, and reports required can be defined. These will be confirmed through diagrams from CASE tools, prototyping techniques, and a repository is formed.

3. ConstructionThis phase follows on from user designs and functional prototypes are produced with detailed design and code generation. Here prototypes are developed, put into operation and then further refined and modified if necessary through a series of iterations using a timeboxing approach.

4. CutoverDuring this phase the new system will be phased-in in a parallel manner (alongside the old system), whilst users endure final training and testing ensuring system adequacy, eventually leading to the old systems demise.

Advantages Evolutionary Timebox Approach

This means speedier delivery of the system in relation to other approaches. In fact RAD aims to produce “…75 per cent of system functionality… in the first 90 day timebox”12. Consequently applications go into production and emerge sooner than with other approaches and due to the nature of constant refinement and re-evaluation, all functions are guaranteed to be accurate.

Forces Teamwork and Satisfies UsersRAD forces the interaction of both users and stakeholders, and as is the case with prototyping methods users feel more involved and they are more likely to commit to the system.

Disadvantages Training, Time and Intensity

Both developers and users will need to be trained in RAD techniques and tools otherwise the approach cannot be adopted. RAD takes up a higher percentage of users time compared with other approaches and there is also a danger to both developers and users of exhausting themselves due to the high intensity nature of workshops and stringent timeboxing methods.

May Lack 100% FunctionalityAll required functions may not be built in, unlike traditional approaches

12 Avison and Fitzgerald, 1995

- 9 -


where developers endeavour to ensure that all requirements are met, whilst RAD prioritises essential functions over desired functions.

Open to AbuseIf initial design is not quite right, there may be a tendency for users to just accept it and build upon it, rather than going back through a lengthy process of initial redesign. Developers may also have this trait.

A1.4.5 Dynamic Systems Development Method (DSDM)As stated in the above section, RAD is an unstructured approach and there is no clearly defined framework for its completion. To overcome this, in January 1994 “…a group of RAD users and suppliers have formed a consortium to define standards and a framework for RAD called Dynamic Systems Development Method (DSDM)” (Avison and Fitzgerald, 1995). DSDM has also been described as providing “… a framework of controls for building and maintaining systems that meet tight time constraints and provide a recipe for repeatable success”13.As is the case with RAD, DSDM also utilises a highly user participative approach which uses Joint Application Development workshops. Using traditional development methods, functionality requirements are usually defined and fixed early on in a project and the time needed and the resources required are variable, however with DSDM the time and resources are fixed and the functionality requirements of a system are allowed to change. Although traditional methods normally include timeboxes, again DSDM uses a unique approach of breaking these down even further, assisted through prioritisation. Each timebox is fixed and will have a set of requirements that will need to be met within it. These functionality requirements are allowed to be variable as they are prioritised using MoSCoW Rules:“Must Haves fundamental to the projects success oShould Haves important but the projects success does not rely on these Could Haves can easily be left out without impacting on the projectoWon't Have this time round can be left out this time and done at a later date”14

This ensures the likelihood of projects being completed on time. In fact DSDM includes a unique 80/20 rule whereby it aims to deliver 80% of functionality within 20% of the time (compared with other methodologies).Many methodologies are designed to support only particular CASE tools, however, DSDM is designed to use a multiplicity of development tools, and can support “…object-oriented or structured analysis and design approaches”, (Stapleton, 1998). A project team would usually consist of six members, including:

Project manager Senior programmer Junior programmer Ambassador user (represents entire user community)

The DSDM lifecycle consists of five stages (see figure 1.6):1. Feasibility Study

The suitability of the application for using a DSDM approach is

13 Saber Consulting14 DSDM Consortium, 1997

- 10 -


determined using a suitability filter of seven questions which takes weeks as opposed to months in other methods.

2. Business StudyHere the scope of the project is defined along with business and technical specifications, these are baselined and prioritised using Moscow rules. Again, this stage is relatively quick and should take no longer than a month.

3. Functional Model IterationFocuses on delivering prototypes which refine the high priority functional and informational needs, with a view to testing what has been produced for integration to occur into the final system through a series of increments. Therefore the system must be robust enough to conform with any non-functional requirements such as performance and reliability.

4. Design and Build IterationOnce a functional model is complete the focus then shifts on providing a solution which can be safely delivered to and tested by end users, this will also include as many non-essential features time permits.

5. ImplementationThis aims to deliver the latest increment solution to the intended audience. Users who have not been involved in testing procedures will need to undergo training. Any functions or requirements, which have not been catered for, may mean a return to the business study, functional model iteration, and design and build iteration phases.(All phases are undertaken using the unique timeboxing approach)

Fig. 1.6: DSDM Development Framework15

15 www.dsdm.org

- 11 -


AdvantagesThe DSDM consortium bases its fundamental successes on the nine key principals of software development, and these can all be considered advantages of DSDM:

1. Active user involvement is imperative.Users educated in DSDM, ensures users are more likely to commit to the system, training costs are also reduced.

2. DSDM teams must be empowered to make decisions.No decisions have to be verified, making the development process more efficient.

3. The focus is on frequent delivery of products.Visual and speedy progress.

4. Business suitability is the essential criterion for acceptance of deliverables.Meets business goals and objectives too.

5. Iterative and incremental development is necessary to converge on an accurate business solution.Initial design constantly improved.

6. All changes during development are reversible.No need to stick with unsatisfactory design.

7. Requirements are baselined at a high level.Ensures most important requirements are met.

8. Testing is integrated throughout the lifecycle.Ensures integrity of system.

9. A collaborative approach between all stakeholders is vital.Ensures all aims are catered for.

DisadvantagesIs costly to implement, as DSDM requires both developers and users to be trained to employ it effectively, therefore it may not be suitable for small organisations or one-off projects.

- 12 -


A1.5 Structured Systems Analysis and Design Method (SSADM)SSADM was first introduced in 1981 as a result of the collaboration between the Central Computing and Telecommunications Agency (CCTA) and UK based consultants Learmonth and Burchett Management Systems (LBMS), with the latest version SSADM 4+, released in 1995. SSADM has previously been used in a number of government applications.SSADM as the title suggests, is a method per se, and should not be confused with methodology. It only forms part of a methodology when its tools and techniques are used in conjunction with traditional methods such as the waterfall approach, due to the fact that SSADM “…excludes the steps which involve the construction, testing and implementation of the software”16. To oversee project management SSADM is also used in conjunction with a technique known as PRINCE (PRojects IN Controlled Environment).SSADM also considers the importance of the user role due to its user-oriented approach, and they are involved throughout the process through workbenches (similar to JAD workshops). Additionally, the approach is data-driven, is highly structured, with very detailed rules and guidelines, which must be adhered to. The whole process is clearly documented throughout with the emphasis on data modelling and the database. Data modelling is achieved through three key techniques which all view the system from three different angles which can be cross-referenced to check consistency:

1. Logical Data ModellingThe data requirements of the system are defined and documented in terms of which data should be stored and manipulated in a system. This is represented by the LDS (Logical Data Structure, traditionally referred to as an Entity-Relationship Diagram/Model in other methods), which contains data entities and items, and the relationships between them.

2. Data Flow ModellingThe informational flow of data around the system is represented by Data Flow Diagrams (DFDs), which concerns the input/output processes and activities of how information is allowed to be manipulated, and finally where the information flows to and where it will be stored. This gives a clear visual representation of functionality, opposed to data attributes (as implied by the title), and is also supported by textual descriptions, which form the “…basis for program specification”17.

3. Entity Event ModellingA process whereby business events that cause entity changes are modelled and documented through Entity Life Histories which shows how each entity is allowed to change, what causes change, and when it can change. For instance, a client entity can change if they moved address, or could be deleted if the client were to move their business elsewhere.

SSADM consists of five main stages, or modules that are in turn broken down into stages, steps and tasks:

16 “Structured Systems Analysis and Design Method (SSADM)” [online]17 www.cee.hw.ac.uk/ism/msc7/week6/ssadm/ssadm.doc

- 13 -

http://www.cee.hw.ac.uk/ism/msc7/week6/ssadm/ssadm.doc

http://www.cee.hw.ac.uk/ism/msc7/week6/ssadm/ssadm.doc


1. Feasibility StudyA single stage process involves high-level analysis of business to determine projects technical, operational, and financial feasibility. (DFD and LDS conducted here).

2. Requirements AnalysisA two-stage process whereby stage 1 investigates the current environment, and stage two investigates a series of business options available for the required system (Business System Options), the requirements from stage 1 are evaluated and their implications and benefits derived, additionally includes non-functional requirements (cost, time). (More detailed DFDs and LDS produced in these two stages).

3. Requirements SpecificationAgain a one-stage process where system requirements are determined developed, verified, and DFDs, LDS are finalised and ELHs constructed, forming the basis for the final two modules.

4. Logical System SpecificationComprises of two stages, Technical System Options (TSO) such as cost, facilities (development environment/applications), performance, and support expected from supplier are determined. Stage two, Logical Design defines the logical exchange of data, specifically, update processing and system dialogues.

5. Physical DesignSingle stage process which combines both the logical and technical system specifications to enable the physical design of the system to be formulated. This will include producing physical screen designs and program specifications.

Figure 1.7 shows the modules and stages of SSADM along with the outputs and lifecycle stage.

Fig. 1.7: The Structure of SSADM18

18 “The Stages of SSADM”

- 14 -


Advantages SSADM is a user-oriented approach, involving users throughout,

ensuring requirements are met, and are of higher quality (due to constant review).

Unique cross-referencing of techniques again ensures all requirements are met and ensures system integrity as it exposes fundamental design flaws.

May utilise any available CASE tools, not just those designed specifically for SSADM.

Disadvantages Development process is expensive and exhaustive; therefore it is vital

to ensure that enough funds, human resources, and time are available, making it unsuitable for projects of a small nature.

- 15 -


A1.6 ConclusionsFrom analysing the various methodologies available it clearly emerges that there is no one conquering methodology or lifecycle to ensure the success of systems development. Each method has its associated strengths and weaknesses. Although the methodologies are distinct and have distinguishing features, the methods remain relatively similar in structure and all have an element of re-evaluation (with the exception of the waterfall approach). There are patterns of work tasks and procedures which are identical (perhaps using different terminology) and some techniques can be used in conjunction with one another (for instance SDLC and SSADM). This insinuates that perhaps the tools and techniques from SSADM could also for instance, be combined with a prototyping approach, indeed there is no reason to suggest why not.Therefore in order to select the most appropriate methodology that best suits the product, its advisable to be selective on certain aspects and adjust each one. An amalgamation of tools and techniques from the various methods can be bought together to form a new development approach that best fits the product.Shaftesbury Junior School require the input of results of national tests, which take place in January, however some requirements are still vague, although it has already been acknowledged that it is a small system. Therefore, I would suggest an iterative and incremental approach, as this will deliver an early version, with only parts of the functionality they require at that time. This will also help to reduce risks and provide tangible results. Tools and techniques will also be utilised from other methodologies such as SDLC, SSADM, Prototyping and RAD.

- 16 -

methodolgy lifecycle

Documents

lifecycles a1 analysis

incremental development

spiral development process

iterative development

waterfall development

rapid application development

structured systems analysis

lifecycles academic