Quality%20and%20productivity%20issues%20in%20information%20systems%20development:

1
IMS3230 - Information Systems Development
Practices

• Quality and productivity issues in information
  systems development
• CASE tools and prototyping
• Semester 2, 2005

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

3
Quality and productivity

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

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

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

6
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

7
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

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

10
Prototyping

• Limitations
• tends to skip through analysis and design phases
  too quickly --gt 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

11
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

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

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

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?

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

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

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

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

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

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

21
Components of CASE Tools

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

22
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

23
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

24
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

25
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)

26
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

27
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

28
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)

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

30
Selecting CASE tools

• compatible with systems development
  methodology/approach
• compatible with technology architecture
• development and application environment
• organisational culture
• implementation strategy
• vendor support

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

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 developers instructions
  to create new systems