9.1

Quality and productivity issues in information systems development:CASE tools and prototyping

Semester 2, 2005

IMS3230 - Information Systems Development Practices

9.2

References

Prescribed text:

Avison, D.E. & Fitzgerald, G. (2003). Information Systems Development: Methodologies, Techniques and Tools. (3rd ed), McGraw-Hill, London.

Chapters 9.2, 18, 6.1, 6.2, 6.3

HOFFER, J.A., GEORGE, J.F. and VALACICH (2002) 3rd ed., Modern Systems Analysis and Design, Prentice-Hall, New Jersey, Chapter 4

9.3

Quality and productivity

“solutions” include:

user participation JAD (Joint Application Design) prototyping automated and other tools RAD (Rapid Application Development) reuse

9.4

in what ways have system development methodologies been influenced by these initiatives?

how have techniques and tools relating to these initiatives been incorporated into system development methodologies?

Quality and productivity

9.5

Prototyping

Prototype a working model of some aspect(s) of an information

system

Prototyping an iterative process of quickly building an

experimental system, for demonstration and evaluation so that users can dynamically determine their information requirements and explore and test the design of the system

9.6

Can be used in various phases of the SDLC Initiation - to test the feasibility of a particular

technology that might be applied for an IS Analysis - to discover users’ requirements by

‘painting’ screens and reports to solicit feedback Design - to simulate the ‘look and feel’ of the

system and evaluate how easy it is to use and learn

Implementation - prototype evolves directly into the production system, to train users

Prototyping

9.7

A prototype is designed with an expectation of change - expect to get it wrong the first time!

Need appropriate technology Types of prototypes

features eg external design mock-up throw-away evolutionary

Prototyping

9.8

Useful when there is uncertainty about requirements

or design solutions can capture requirements in concrete, rather than

verbal or abstract form users are more likely to be able to state their

detailed requirements when they see and use a prototype

users are more likely to get what they want

Prototyping

9.9

Useful when there are several stakeholders

convenient display method for multiple parties

because it encourages user participation user can relay feedback immediately changes can be made interactively

because it is easier to identify behavioural issues when users are using the prototype the designer can interactively accommodate the

way the user ‘uses’ the interface

Prototyping

9.10

Limitations tends to skip through analysis and design phases too

quickly --> lack of thorough understanding of the problems

checks in the SDLC are bypassed so tendency to gloss over essential tasks eg. feasibility, standardisation, documentation, testing, security, etc. which can then make the system more difficult to develop into a production system

can discourage consideration of a wide range on alternative design options .. tendency to go with the first one that the user likes

Prototyping

9.11

Limitations often lacks flexibility, technical efficiency and

maintainability because of hasty construction not suitable for large applications which have large

amounts of data and multiple users - hard to control often built as stand-alone systems, thus ignoring

issues of data sharing and interactions with other existing systems

can become too specific to the user representative and difficult to adapt to other potential users

Prototyping

9.12

Prototyping

prototyping as a technique:

can be incorporated into a systems development methodology (analysis, design, construction)

prototyping as basis for a system development methodology:

uses an iterative lifecycle model e.g.

requirements analysis

build prototype

evaluate prototype

refine prototype

construct system using prototype as part of the specification

9.13

Prototyping

Potential advantages of prototyping: users see something concrete early on improved understanding and learning/discovery make changes quickly and easily

Potential disadvantages of prototyping: poorly documented systems incomplete systems unrealistic user expectations project management difficulties

9.14

Prototyping and ISD methodologies

for information systems development methodologies (ISDMs):

changed view of the lifecycle less emphasis on paper-based documentation widespread acceptance:

ISDMs need to keep up-to-date with latest trends in technology

has prototyping improved system development?

9.15

Prototyping and evolutionary development

Evolutionary development (vs traditional, linear SDLC)incremental approach delivering a system in stages: the system evolves (is built) over time

Each delivery achieves something usable, useful but not necessarily complete: a series of development efforts (see Fig 6.1 Avison & Fitzgerald 2003, p. 86)

Approach: Design does not have to be perfect, but something is delivered Accommodate future change Does not have to be comprehensive

Appropriate for situations with unclear requirements: system is developed as more is learned about the problem situation

Evolutionary prototyping uses an evolutionary development approach where the prototype evolves into the final system

9.16

What are CASE tools?

computer-aided software tools that provide automated support for some portion of the systems development process

provide an engineering-type discipline to improve productivity and increase the quality of information systems

CASE tools may run on various mini and mainframe systems, but the PC is the dominant CASE workstation

9.17

CASE tools

CASE (Computer Assisted Software Engineering) tools

Objective of CASE tool usage:

higher quality systems, a less expensive and more productive system development process

“automated and integrated software development tools, techniques and methodologies that add significant value by increasing the productivity of the application development process and the quality of the applications that they're used to develop”

Stone (1993) p.8

9.18

CASE tools

Objectives to improve the quality of the systems developed: e.g.

better and more complete specifications and designs to improve the productivity of systems development: less

people and faster to ease and improve consistency of specifications,

conformity of designs, and testing through automated checking

to improve the integration of development activities via the use of common methodologies and techniques

to improve the quality and completeness of documentation

9.19

CASE tools

Objectives

to improve the management and control of projects to promote consistency across projects within the

organisation to promote consistency and quality of systems across

the organisation to promote resuability to reduce maintenance effort

9.20

CASE tools

core CASE tool functionality: graphical facilities for diagrams and modelling data dictionary automated documentation

additional functionality: code generation from system specifications and models automatic audit trail of changes project management facilities enforced diagramming and documentation standards

9.21

diagramming tools screen and report generators analysis tools a central repository documentation generators code generators

Components of CASE Tools

9.22

diagramming toolsenable graphical representation of system data, processes, and control structures

screen and report generatorshelp to prototype how systems “look” and “feel” to users help to identify data and process requirements

analysis toolsautomatic checking for correctness, completeness, and consistency of specifications in diagrams, reports, forms

Components of CASE Tools

9.23

a central repositoryenables integrated storage of systems specifications and project management information

documentation generatorshelp to produce both technical and user documentation in standard formats

code generatorsautomatic generation of program and database definition code directly from the design documents, diagrams, reports and forms

Components of CASE Tools

9.24

the repository is central to the CASE tool for integration to allow sharing between tools and SDLC activities

a centralised database containing all form and report definitions, diagrams, data definitions (data flows, entities etc), process flows, functions, process logic, other organisational and system components

common terminology, notations, methods to support integration

potential benefits:

supports co-ordination of team members and effort

promotes reusability

CASE tools: the CASE repository

9.25

Upper CASE

designed to support the earlier lifecycle phases:

IS planning, project identification and planning, systems analysis, design

Lower CASE

designed to support the implementation and maintenance phases of systems development

I-CASE (integrated CASE)

“seamless” integration of products and tools across lifecycle phases via a common repository

(see Avison & Fitzgerald 2003, Chapter 18)

Types of CASE tools

9.26

Cross lifecycle CASECASE tools used to support activities that occur across multiple phases of the SDLC

e.g. project management:

developing estimates of time and resources, scheduling, monitoring project progress

production of documentation

the repository and document generators are used across multiple lifecycle phases

CASE tool usage

9.27

the adoption of CASE is closely related to the use of a formal, standardized systems development process or methodology:

many CASE tools force or encourage analysts to follow a specific methodology

organizations without a widely used methodology or an approach that is compatible with a CASE tool will have difficulties

CASE adoption has been slower than expected due to several factors including:

cost, training needs, front end lifecycle effort

Implementing CASE tools in organisations

9.28

startup costs

I-CASE costs per analyst: $5,000 to $50,000

only large-scale system builders can spend this

smaller organisations use tools with less functionality

training

for every dollar spent on tools, half to double that spent on training

front end lifecycle effort

the big benefits come in later lifecycle phases: construction, testing, implementation, maintenance

early phases lengthened by up to 40%

(see Hoffer et al 2002, chapter 4)

Implementing CASE tools in organisations

9.29

Why organisations resist CASE tools

common resisting organisational factors for CASE adoption:

high cost of purchasing high cost of training personnel low organisational confidence in the IT department to

deliver high quality systems on time and within budget lack of methodology and standards CASE seen as a threat to job security lack of confidence in CASE products

9.30

Selecting CASE tools

compatible with systems development methodology/approach

compatible with technology architecture development and application environment organisational culture implementation strategy vendor support

9.31

Systems development using CASE tools

changes in work practices focus on analysis and design rather than later phases “automatic” documentation generation easier to maintain designs modifications to analysis and design products are easier project team structures may change task structures/roles may change

9.32

Evolution and future of automated tools

Visual development tools: rapidly build interfaces, reports etc using visual tools e.g.

Visual Basic, Powerbuilder and instantly test the look of the design (development and programming environments)

Embed AI into development environments use of intelligent agents (programs) residing in a

computer to carry out developer’s instructions to create new systems