ITEC 4010: Systems Analysis and Design

II.

Lecture 4
System Development
Part III
Review

Professor Peter Khaiter

Topics
System Development Life Cycle Variations

Iterations in System Development Life Cycle

The Prototyping Approach to Development

CASE Approach to Development

Causes of failure in Software Development

Stats on Software Errors

Lecture 4 2
System Development Life Cycle
(SDLC) Variations
■ Traditional approach: “Waterfall method” –
only when one phase is finished the project
team drop down (fall) to the next phase
Fairly rigid approach – decisions at each phase
get frozen
Can’t easily go back to previous phases (each
phase would get “signed off”)
Good for traditional type of projects, e.g. payroll
system or system with clearly definable
requirements
Not as good for many of the new types of
interactive and highly complex applications
applications where it is hard to specify all requirements
once and for all

Lecture 4 3
SDLC Variations (cont.)

FIGURE 4-1 The waterfall model of the SDLS.

Lecture 4 4
SDLC Variations (cont.)

FIGURE 4-2 Life cycles with different names for phases.

Lecture 4 5
Differences in Approaches
Traditional approach include feasibility study at
beginning, with system investigation and systems
analysis as the Analysis phase
Information engineering includes earlier part of
cycle – information strategy planning, as first phase
The objectory model includes only four phases

Despite differences, the same overall tasks need to

be carried out – e.g. planning, analysis, design
and implementation

Lecture 4 6
Differences in Approaches
(cont.)
■ The pure waterfall approach is less used
now
■ The activities are still planning, analysis,
design and implementation
■ However, many activities are done now in
an overlapping or concurrent manner
■ Done for efficiency – when activities are not
dependent on the outcome of others they
can also be carried out

Lecture 4 7
Iteration in SDLC
Iteration assumes no one gets the right results the
first time
Do some analysis, then some design, then do some
further analysis, until you get it right
Idea: not always realistic to complete analysis
before starting design
Waterfall no longer applies - Phases become
blurred
Decisions are not frozen at the end of each phase
Good for projects where requirement specifications
are hard to arrive at
However, can lead to ambiguity
Harder to know how far you are along in the project
Could be hard to manage

Lecture 4 8
Iteration in SDLC
Iteration is the process of looping through the same
development activities multiple times, sometimes at
increasing levels of detail or accuracy
Information engineering can be done with iteration
Object-oriented approach considered to be highly iterative

Example: Iterative design and development of user

interfaces in health care – can cycle iteratively
through the following
Design interface
Test (evaluate) with users early on (video-based usability
testing)
Redesign, based on results of testing with users

Lecture 4 9
The “Classic” Waterfall Life Cycle

Project planning

Analysis

Design

Implementation

Lecture 4 10
 A newer method: rapid prototyping (with iteration)
Requirements
Gathering
(Analysis)
Quick
Design

Build
Prototype

Evaluate and
Refine Requirements

Engineer
Project

Lecture 4 11
Iteration in SDLC (cont.)

FIGURE 4-5
Iteration across
life cycle phases.
Lecture 4 12
The Prototyping Approach to
Development

FIGURE 4-6 A system

development approach based on
developmental prototypes.
Lecture 4 13
Prototyping Approach
(cont.)
Flexibility and power needed for fast development
WYSIWYG (“what you see is what you get”)
development of interface components
Generation of complete programs, program
skeletons etc.
Rapid customization of software libraries or
components
Sophisticated error-checking and debugging
capabilities

In example on next slide you can easily “draw” the

interface, by selecting buttons, menus etc. and
dragging onto the screen (e.g. Visual Basic)
Lecture 4 14
Prototyping Approach
(cont.)

FIGURE 4-7 Development of a user interface prototype

using WYSIWYG dialog box editor.
Lecture 4 15
The Spiral Approach to
Development
■ Project starts out small, handling few risks
■ Project expands in next iteration to address
more risks
■ Eventually the system is completed (all risks
addressed)
■ At the middle (start of the project) there is
low risk and project is still small easy to
manage
■ You work out from the middle, expanding
out your project

Lecture 4 16
Spiral life cycle (cont.)

FIGURE 4-8 The spiral life cycle model.

Lecture 4 17
Variations based on an emphasis
on people
Sociotechnical systems
Systems that include both social and technical subsystems
Both social and technical subsystems must be considered
User-centered design/Participatory design
Example in text: Multiview
Activity analysis (activity theory)
Actors and activities they do (not in text)
Diagram not just system functions but human activity as well

Main idea: Human activity must be studied in detail

(as well as technical aspects) – often forgotten!!
Example – study of activity in intensive care unit as basis for
system design (versus “expert system” approach)

Lecture 4 18
Multiview SDLC

FIGURE 4-9 Phases of the multiview SDLC

Lecture 4 19
Variations based on speed of
development
RAD – Rapid Application Development
Try to speed up activities in each phase
E.g. scheduling intensive meetings of key
participants to get decisions fast
Iterative development
Building working prototypes fast to get feedback
(can then be directly expanded to finished
system)
If not managed right can be risky

Lecture 4 20
Computer-Aided System
Engineering (CASE)
CASE tools: Software tools designed to help
system analyst complete development tasks
The CASE tool contains a database of information
called a repository
Information about models
Descriptions
Data definitions
References that link models together
Case tools can check the models to make sure they
are complete and follow diagramming rules
Also can check if the models are consistent
Adds a number of capabilities around the repository

Lecture 4 21
 CASE Approach (cont.)

FIGURE 4-10 A CASE tool repository contains all information about the system.

Lecture 4 22
Types of CASE tools
Upper CASE tools
Support analyst during the analysis and design phases
Lower CASE tools
Support for implementation – e.g. generating programs
Tools may be general, or designed for specific
methodology (like for information engineering – TIs’
IEF, CoolTools)
Examples of CASE tools
Visual Analyst for creating traditional models
Called “integrated application development tool”
Rational Rose for object-oriented modeling
Based on UML standard for object orientation
Allows for reverse-engineering and code generation (can be
integrated with other tools like Visual C++ etc.)
“Round trip engineering” – synchronized updating

Lecture 4 23
 Types of CASE tools (cont.)

FIGURE 4-11 The CASE tool Visual Analyst showing a data flow diagram.

Lecture 4 24
 Types of CASE tools (cont.)

FIGURE 3-23 The visual modeling tool Rational Rose showing diagrams from
the object-oriented approach
Lecture 4 25
 Types of CASE tools (cont.)

FIGURE 3-24 The round-trip engineering tool Together J showing a class

diagram with synchronized Java source code.
Lecture 4 26
What CASE can do to help
Help to make analysis and design process
more rigorous and complete, to reduce bugs
later
Examples of functions in tools:
Provide support for diagramming (for analysis and design)
Provide support for checking consistency of design
Provide graphing support to help users visualize an existing
or proposed information system (e.g. Data flow diagrams)
Detail the processes of your system in a hierarchical
structure
Produce executable applications based on your data flow
diagrams (which can be made from point and click
placements of icons)
Integrate specific methodologies into windowing
environments

Lecture 4 27
Evolution of Software Tools

CASE-
sophistication
Code generators

CASE-
Analysis +
Design

Debuggers

Compilers

Assemblers

Lecture 4 28
Current Status of CASE
A number of commercial products
Some aspects (e.g. diagramming support)
are widely applicable and useful
Other features such as code generation are
more specific
CASE tools not so successful for generic code
generation
However, specific code generation is now being
used for things such as user interface design
(e.g. Visual C++ allows you to “draw” the
interface and it generates the code)
As ideas become successful often no longer
called CASE
Lecture 4 29
Causes of failure (and symptoms) in software
development
Requirements Analysis
No written requirements
Incompletely specified requirements
No user interface mock-up
No end –user involvement (can happen – may have
talked to clients BUT not users!)

Design
Lack of, or insufficient, design documents
Poorly specified data structures and file formats
Infrequent or no design reviews

Lecture 4 30
Causes of failure (and symptoms) in software
development (cont.)
Implementation
Lack of, or insufficient coding standards
Infrequent or no code reviews
Poor in-line code documentation

Unit test and Integration

Insufficient module testing
Lack of proper or complete testing
Lack of an independent quality assurance group

Lecture 4 31
Causes of failure (and symptoms) in software
development (cont.)
Beta Test Release
Complete lack of a beta test
Insufficient duration for beta test
Insufficient number of beta testers
Wrong beta testers selected

Maintenance
Too many bug reports
Fixing one bug introduces new bugs

Lecture 4 32
Stats on Software Errors (large
systems)
■ Most software errors originate in the
Analysis and
Design phases (65%)
■ Unfortunately, less than one-third of these
errors are caught before acceptance testing
begins
■ About 35% of errors occur during coding
■ Cost of fixing an error goes up the later it is
caught!
■ This is basis for emphasis in CASE on
Analysis and Design
Lecture 4 33