IMS3230 - Information Systems Development Practices Quality and productivity issues in

IMS3230 - Information Systems
Development Practices
Quality and productivity issues in
information systems development:
CASE tools and prototyping
Semester 2, 2005
9.1
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, PrenticeHall, New Jersey, Chapter 4
9.2
Quality and productivity
“solutions” include:
 user participation
 JAD (Joint Application Design)
 prototyping
 automated and other tools
 RAD (Rapid Application Development)
 reuse
9.3
Quality and productivity
 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?
9.4
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.5
Prototyping
 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
9.6
Prototyping
 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
9.7
Prototyping
 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
9.8
Prototyping
 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
9.9
Prototyping
 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
9.10
Prototyping
 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
9.11
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.12
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.13
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.14
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.15
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.16
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.17
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.18
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.19
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.20
Components of CASE Tools






diagramming tools
screen and report generators
analysis tools
a central repository
documentation generators
code generators
9.21
Components of CASE Tools
 diagramming tools
enable graphical representation of system data,
processes, and control structures
 screen and report generators
help to prototype how systems “look” and “feel” to users
help to identify data and process requirements
 analysis tools
automatic checking for correctness, completeness, and
consistency of specifications in diagrams, reports, forms
9.22
Components of CASE Tools
 a central repository
enables integrated storage of systems specifications
and project management information
 documentation generators
help to produce both technical and user documentation
in standard formats
 code generators
automatic generation of program and database definition
code directly from the design documents, diagrams,
reports and forms
9.23
CASE tools: the CASE repository
 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
9.24
Types of CASE tools
 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)
9.25
CASE tool usage
 Cross lifecycle CASE
CASE 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
9.26
Implementing CASE tools
in organisations
 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
9.27
Implementing CASE tools in
organisations
 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)
9.28
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.29
Selecting CASE tools
 compatible with systems development
methodology/approach
 compatible with technology architecture
 development and application environment
 organisational culture
 implementation strategy
 vendor support
9.30
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.31
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
9.32