IMS3230 - Information Systems Development Practices

IMS3230 - Information Systems Development Practices

Quality and productivity issues in information systems development:

RAD, application packages, outsourcing

Semester 2, 2005

10.2

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, LondonChapters 6.4, 22.1, 22.3, 22.4, 8

10.3

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

Rapid Application Development (RAD) :

A systems development methodology created to radically decrease the time needed to design and implement information systemsE.g. James Martin (1991)

RAD methodology

Rapid Application Development (RAD)

10.5


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

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

James Martin’s four pillars of RAD:

Tools People Methodology Management


10.8

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

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

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


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

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

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

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

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

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

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

Choosing application packages: Issues

Cost Functionality Vendor Support Viability of Vendor Flexibility Documentation Response Time Ease of Installation

10.19

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

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

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

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 in-house 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.23

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

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 etce.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.25

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

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

OutsourcingDiffering 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.28

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

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

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

IMS3230 - Information Systems Development Practices

Documents

Transcript of IMS3230 - Information Systems Development Practices