IMS5006 - Information Systems
Development Practices
Quality and productivity issues in
information systems development:
RAD, application packages,
outsourcing
Quality and productivity
“solutions” include:
 user participation
 JAD (Joint Application Design)
 prototyping
 automated and other tools
 RAD (Rapid Application Development)
 Application packages
 outsourcing
 reuse
10.2
Rapid Application Development
(RAD)
Rapid Application Development (RAD) :
 A systems development methodology created to
radically decrease the time needed to design
and implement information systems
E.g.
James Martin (1991)
RAD methodology
10.3
Rapid Application Development
(RAD)
RAD claims to offer:
 a development lifecycle for much faster systems development
 better and cheaper systems
 more rapid deployment of systems as developers and users work
together in real time
RAD relies on:





extensive user involvement
JAD sessions
Prototyping
I-CASE tools (integrated CASE tools)
Code generators
10.4
Rapid Application Development
(RAD)
Evolution of RAD:
 Pressures for businesses to speed up and compete in a
changing, global environment
 Diffusion of high-powered prototyping and CASE tools:
Why wait 2 or 3 years to develop systems likely to be
obsolete upon completion?
10.5
Rapid Application Development
(RAD)
James Martin’s four pillars of RAD:




Tools
People
Methodology
Management
10.6
Rapid Application Development
(RAD)
Tools:
 I-CASE tools with prototyping and code generation
facilities,
 Visual development environments
People:
 Manager and user participation in JAD type
workshops,
 Developer roles:
Workshop leader, project leader, scribe, repository
manager, construction or SWAT (Skilled With
Advanced Tools) team
10.7
Rapid Application Development
(RAD)
 Methodology:
 to guide and control the use of RAD techniques
 Should be automated for ease of use, adaptabilty and
flexibility
 Management:
 Executive sponsor
 Facilities and support for the RAD team
10.8
Rapid Application Development
(RAD)
RAD lifecycle

Requirements planning phase (JRP)

User design phase (JAD)

Construction phase

Cutover phase
 Is evolutionary:
 Uses timeboxing
 Avoids “feature creep”
 Avoids requirements “gold plating”
10.9
Rapid Application Development
(RAD)
Martin’s (1991) RAD lifecycle
 Requirements planning phase
 managers, executives, key users determine requirements in terms
of business areas and business problems,
 JRP workshops to agree requirements, overall planning
 User design phase
 end users and IS personnel use I-CASE for rapid prototyping of
system design,
 JAD sessions to develop basis for physical design,
 users sign off on CASE-based design (no paper-based spec.)
10.10
Rapid Application Development
(RAD)
Martin’s (1991) RAD lifecycle
 Construction phase
 IS personnel now generate code using I-CASE tool,
 end users validate screens, design, etc.
 Cutover phase
 delivery of new system to users: testing, training, implementation,
 can be combined with construction in small systems
10.11
Rapid Application Development
(RAD)
 Uses timebox approach:
 system to be developed divided into components that can be
developed separately
 have the easiest and most important 75% of the system
functionality produced in the first timebox (90 day cycle)
 forces users to focus on the necessary and most well-defined
aspects
 Users experience this component first and other component
requirements may then change
 Functionality is trimmed: “gold plating” is avoided
 Avoids “feature creep”: more and more requirements creep in
during development than originally specified
10.12
Rapid Application Development
(RAD)
 Timeboxing vs traditional approach:
traditional approach every possible requirement is
implemented together leading to increased complexity
and long delays
 Martin claims RAD can produce a system in 6 months
that would take 24 months using traditional
development methods
 Small development teams are essential for RAD to work
10.13
Rapid Application Development
(RAD)
advantages
 quick development:
 cost savings,
 higher quality/improved performance as easier and most important
functions targeted first,
 avoids feature creep,
 aligned with business changes
disadvantages
 detailed business models/understanding neglected:
inconsistencies,misunderstandings
 programming standards, scalability, system administration issues
neglected e.g. database maintenance/reorganisation, backup/recovery,
distribution of system updates
10.14
Rapid Application Development
(RAD)
advantages
 quick development:
 cost savings,
 higher quality/improved performance as easier and most important
functions targeted first,
 avoids feature creep,
 aligned with business changes
disadvantages
 detailed business models/understanding neglected:
inconsistencies,misunderstandings
 programming standards, scalability, system administration issues
neglected e.g. database maintenance/reorganisation, backup/recovery,
distribution of system updates
10.15
Application packages
 purchasing or leasing a set of pre-written
application software programs that are
commercially available
 may range from simple PC systems to
complex mainframe systems
10.16
Choosing application packages:
Issues








Cost
Functionality
Vendor Support
Viability of Vendor
Flexibility
Documentation
Response Time
Ease of Installation
10.17
Choosing application packages :
Process
 identify products which may suit specified
requirements
 solicit, evaluate and rank vendor proposals
 select the best vendor proposal
 establish requirements for integrating the
vendor’s products
10.18
Choosing application packages:
Criteria
 Identify criteria by which to evaluate hardware and
software
 cost, functionality,vendor support, vendor viability, quality of
documentation, ease of learning, ease of use, ease of
installation, response time, throughput, version?, ease of
customisation, number of current installations, licensing
arrangement, training, internal controls, database size
limitation, maintenance contracts, customer references
 to help identify criteria you can use
 past experience, trade magazines and journals, information
services, potential vendors .. bias
10.19
Application packages
 Useful:
 when you need an information system for a common
company function eg. payroll
 when information systems resources for in-house
development are in short supply
 when the application software package is more cost
effective than in-house development
 because the most of the design and implementation tasks
are done .. significant time saving
 because the system and documentation are usually
maintained by the vendor
10.20
Application packages
 Useful:
 because the design specification is fixed, so no endless
reworking .. users have to accept it
 politically because:
 external work is often perceived as being superior to an inhouse effort .. easier to get new systems into the company
 easier to get management support because of fixed costs
 problems can be attributed to the package rather than internal
sources .. ends endless source of internal conflict
10.21
Application packages
 Limitations:
 very rare to find a package that can do everything well that a user
wants
 often need to develop specialised package additions because the
multi-purpose packages do not handle certain functions well
 conversion and integration costs can sometimes be so significant as
to render the project infeasible
 some vendors refuse to support packages which have been
customised by the users .. and most packages need some
customisation
 customisation can be so extensive that it would have been cheaper
to develop the system in-house
10.22
Application packages: ERP
 Enterprise Resource Planning (ERP) Systems
 A large scale application package: a series of
software modules for business processes
including financial, organisational (e.g. HR),
production, inventory functions etc
e.g. SAP is the market leader
 Fully integrated system enabling standardisation
and data integrity
 Internet and e-commerce technologies
 Software can be configured for industry sectors
e.g. banking, universities, airlines etc.
(Avison & Fitzgerald 2003, pp 131-132)
10.23
Application packages: ERP
Enterprise Resource Planning (ERP) Systems
 Disadvantages:
long implementation times, huge investment, impact of
widespread change, costs, tendency to change the
organisation’s processes to fit the software
Key differences from typical software package purchases:
 Complexity causes organisations to forego customisation
 Tends to be driven by top corporate managements
(Avison & Fitzgerald 2003, pp 131-132)
10.24
Outsourcing
 The practice of turning over some or all of
an organisation’s IS applications and/or
operations to an outside firm.
 Why?




May be cost-effective
May be specialist in your business area
To overcome operating problems
Running IS/IT is not part of core business
(core competencies)
 Need to be aware of the pros and cons
10.25
Outsourcing
Differing definitions of outsourcing e.g. :
The commissioning of a third party (or a number of third parties) to
manage a client organisation’s IT assets, people, and/or activities to
required results
Fitzgerald & Willcocks (1994)
 Focus is on the specified service, not on how the service is
to be carried out
 Growing tendency for organisations to outsource some or
all of their systems development
 Difficulties in gathering and accurately specifying
requirements in particular
 Issues and problems in defining and negotiating contracts
and responsibilities
 Growth of “offshore outsourcing”
10.26
Reuse
 reuse of code (software)
 reuse of analysis and design components
 reuse of application shells and templates
 reuse of project management modules
benefits:
-
lower costs
-
reduction in development time
-
increased quality
enterprise-wide planning for reuse is necessary
10.27
Reuse
 software reusability:
the ability to design software modules so that they can
be used again and again in different systems without
significant modification
 a repository of reusable components:
-
access mechanisms
–
modification mechanisms
-
integration mechanisms
 object-oriented technology facilitates reuse
 CASE tools facilitate reuse
10.28
Reuse
 methods of reuse:
-
adapt a generic design
-
building blocks
-
combination
 incorporating reuse techniques into SDMs,
e.g.
Information Engineering recommends reuse
in its later versions
10.29
References
 HOFFER, J.A., GEORGE, J.F. and VALACICH (2001) 3rd ed.,
Modern Systems Analysis and Design, Prentice-Hall
Chapter 19
 AVISON, D.E. & FITZGERALD, G. (2003). Information Systems
Development: Methodologies, Techniques and Tools. (3rd ed),
McGraw-Hill, London
Chapters 6.4, 22.1, 22.3, 22.4, 8
10.30