David Patel
Appendix A - Methodologies and Lifecycles
Academic Objective 1 – Methodologies and Lifecycles
A1 Analysis of the Methodology and Lifecycle to be Used
A1.1 Introduction .............................................................................................. 1
A1.2 Waterfall Development Model.................................................................. 2
Advantages ...................................................................................................... 2
Disadvantages ................................................................................................. 3
A1.3 Prototyping .............................................................................................. 3
Advantages ...................................................................................................... 4
Disadvantages ................................................................................................. 4
A1.4 Prototyping Advances .............................................................................. 5
A1.4.1 Spiral Development Process ................................................................ 5
Advantages ...................................................................................................... 6
Disadvantages ................................................................................................. 6
A1.4.2 Incremental Development ..................................................................... 6
Advantages ...................................................................................................... 7
Disadvantages ................................................................................................. 7
A1.4.3 Iterative Development Process ............................................................. 7
Advantages ...................................................................................................... 8
Disadvantages ................................................................................................. 8
A1.4.4: Rapid Application Development ........................................................... 8
Advantages ...................................................................................................... 9
Disadvantages ................................................................................................. 9
A1.4.5: Dynamic Systems Development Method (DSDM) ............................. 10
Advantages .................................................................................................... 12
Disadvantages ............................................................................................... 13
A1.5 Structured Systems Analysis and Design Method (SSADM) ................. 13
Advantages .................................................................................................... 15
Disadvantages ............................................................................................... 16
A1.6 Conclusions ........................................................................................... 16
A1.1 Introduction
This 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-
David Patel
Appendix A - Methodologies and Lifecycles
A1.2 Waterfall Development Model
Also 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. Analysis
Here the system requirements are gathered and defined. Any existing
systems can also be evaluated and any inefficiency can be highlighted.
2. Design
A design specification is derived from requirements analysis, where
plans are made concerning physical construction, hardware, operating
systems, programming, communications and security issues.
3. Build
Using the design specification, the system is developed and
components built. Additionally, the system will also be tested and user
training will occur.
4. Implement
The 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 Maintenance
For 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
Analysis
Design
Build
Implement
Operation and Maintenance
Advantages
 Easy to understand
 Quality built-in throughout
 Configuration management
 Clear and defined stages
 Forced to do analysis and design first
2
3
http://searchvb.techtarget.com/0,,sid8_gci755068,00.html
Adapted from “Software Process Models”
-2-
David Patel
Appendix A - Methodologies and Lifecycles
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 Prototyping
Prototyping 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. Revolutionary
Also 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
Evolutionary
Prototyping
Delivered System
Revolutionary
Prototyping
Executable Prototype
& System Specification
Outline Requirements
4
Adapted from Ian Somerville, 2000
-3-
David Patel
Appendix A - Methodologies and Lifecycles
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 System
Due 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 Cost
Again, 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 Users
As 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 Problems
Communication 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 Documentation
As the main emphasis is on producing prototypes, system
documentation maybe neglected and is often missing or incomplete.
 System Integrity
Again, if too much focus is placed on prototype production, other
system features such as backup, recovery, performance and security
maybe become neglected.
-4-
David Patel
Appendix A - Methodologies and Lifecycles
A1.4 Prototyping Advances
Prototyping 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 Process
Barry 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 phase
Next phase of the spiral is planned defining project information such as
time and resources available.
 Determine objectives, alternatives and constraints
Additional objectives for a specific phase are determined.
 Evaluate alternative solutions and resolve risks
Risks are identified and alternate solutions may be sought to mitigate
risk.
 Develop and verify next-level product
Products are developed utilising any available methodologies.
 Evaluation of results
Software is evaluated and user feedback is sought.
Fig. 1.3: The Spiral Development Model5
5
Determine objectives, alternatives
and constraints
Evaluate alternatives, identify
and resolve risks
Plan next phase
Develop and verify next level
product
Kathrin, M., 2002
-5-
David Patel
Appendix A - Methodologies and Lifecycles
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 Development
Tom 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.
6
Sommerville, I., 2000
-6-
David Patel
Appendix A - Methodologies and Lifecycles
Fig. 1.4: Incremental Development Process7
Define system
requirements
Design system
architecture
Specify system
increment
Build system
increment
Validate
increment
Validate system
Integrate
increment
NO
Deliver final
system
System
complete?
YES
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 Process
Some 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.
7
8
Adapted from Sommerville, I., 2000
Kavanagh, M., 1998
-7-
David Patel
Appendix A - Methodologies and Lifecycles
Fig. 1.5: Iterative Development Cycle9
Plan and Elaborate
Build
Development Cycle
1
Refine Plan
Synchronise
Artifacts
Deploy
Development Cycle
2
Analyse
...
Design
Build
Test
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 Development
Rapid 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.
9
Hunger, M., 2000
Avison and Fitzgerald (1995)
11
Dashwood, P.E.C. (2001), “Shoot The Rapids, Avoid The Waterfall”
10
-8-
David Patel
Appendix A - Methodologies and Lifecycles
There are four main phases in RAD:
1. Requirements Planning
During 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 Design
Again, 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. Construction
This 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. Cutover
During 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 Users
RAD 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.
12
Avison and Fitzgerald, 1995
-9-
David Patel


Appendix A - Methodologies and Lifecycles
May Lack 100% Functionality
All required functions may not be built in, unlike traditional approaches
where developers endeavour to ensure that all requirements are met,
whilst RAD prioritises essential functions over desired functions.
Open to Abuse
If 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
o
Should Haves important but the projects success does not rely on these
Could Haves can easily be left out without impacting on the project
o
Won'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)
13
14
Saber Consulting
DSDM Consortium, 1997
- 10 -
David Patel
Appendix A - Methodologies and Lifecycles
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
determined using a suitability filter of seven questions which takes
weeks as opposed to months in other methods.
2. Business Study
Here 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 Iteration
Focuses 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 Iteration
Once 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. Implementation
This 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)
- 11 -
David Patel
Appendix A - Methodologies and Lifecycles
Fig. 1.6: DSDM Development Framework15
Advantages
The 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.
15
www.dsdm.org
- 12 -
David Patel
Appendix A - Methodologies and Lifecycles
Disadvantages
Is 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.
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 Modelling
The 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 Modelling
The 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 Modelling
A 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
16
17
“Structured Systems Analysis and Design Method (SSADM)” [online]
www.cee.hw.ac.uk/ism/msc7/week6/ssadm/ssadm.doc
- 13 -
David Patel
Appendix A - Methodologies and Lifecycles
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:
1. Feasibility Study
A single stage process involves high-level analysis of business to
determine projects technical, operational, and financial feasibility.
(DFD and LDS conducted here).
2. Requirements Analysis
A 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 Specification
Again 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 Specification
Comprises 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 Design
Single 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.
- 14 -
David Patel
Appendix A - Methodologies and Lifecycles
Fig. 1.7: The Structure of SSADM18
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.
18
“The Stages of SSADM”
- 15 -
David Patel
Appendix A - Methodologies and Lifecycles
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.
A1.6 Conclusions
From 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 -