ITEC 3010

Lecture 3

1
 Approaches to System Development

• System Development Methodology

– Comprehensive guidelines to follow for completing
every activity in the system development life cycle,
including specific models, tools and techniques
– May contain instructions about how to use models,
tools and techniques
– We will examine a number of different methodologies
for system development

2
• Models
– Model: A representation of some important aspect of the real
world
– Models used in system development include representations of
inputs, outputs, processes, data, objects, object interactions,
locations, networks, and devices etc.
– Most models are graphical – diagrams and charts
– Models of system components
• Flow chart
• Data flow diagram (DFD)
• Entity-relationship diagram (ERD)
• Structure chart
• Use case diagram
• Class diagram
• Sequence diagram
– Models to manage the development process
• PERT chart
• Gantt chart
• Organizational hierarchy chart 3
• Tools
– Tool: Supportive software that helps create models or
other components required in the project
– Examples of tools
• Project management application
• Drawing/graphics application
• Word processor/text editor
• Computer-aided system engineering (CASE) tools
• Integrated development environment (IDE)
• Database management application
• Reverse-engineering tool
• Code generator tool

4
• Techniques
– Technique: a collection of guidelines that help the
analyst complete a system development activity or task
– Examples of techniques
• Strategic planning techniques
• Project management techniques
• User interviewing techniques
• Data-modeling techniques
• Relational database design techniques
• Structured analysis technique
• Structured programming technique
• Software-testing techniques (e.g. usability testing)
• Object-oriented analysis and design techniques

5
6
 Two Approaches to System Development

• the basis of virtually all methodologies

• Approaches
– The structured approach
• System development using structured programming,
structured analysis, and structured design techniques
– Object-oriented approach
• An approach to systems development that views an
information system as a collection of interacting
objects that work together to accomplish tasks
7
 The Structured Approach

• The structured approach is made up of:

1. Structured programming
2. Structured design
3. Structured analysis
• Also known as SADT (Structured Analysis and
Design Techniques)
• Before late 90’s you’d probably learn “structured
programming” in your first programming course
• “structured analysis” evolved in the 1980’s (for
stage prior to programming)
8
 Structured Programming

• Structured program
– A program or program module that has one beginning
and one ending, and each step in the program execution
consists of one of the following
• Sequence (of program statements)
• Decision (where one set of statements or another executes)
• Repetition (of a set of statements)
– Related to concept of top-down programming
• Division of complex problems into a hierarchy of smaller, (more
manageable) program modules
• Top program “calls” lower-level modules
• Lower level modules deal with lower-level detail
• Makes programs much easier to write and understand
• Module: collection of instructions to accomplish some logical
function or task (“modular programming”) – e.g. 9
Procedures/functions in a programming language
10
11
 Structured Design
• Structured design
– A technique providing guidelines for deciding what the
set of programs should be, what each program should
accomplish, and how the programs should be organized
into a hierarchy
– Related to (similar principles) as structured
programming, but here looking at a larger level of how
program modules themselves are organized
– Top-down approach again
• start with highest level functions – top-level and break down
into lower level program modules (lower level details goes
below)
– Use of a structure chart helps
• A graphical model showing the hierarchy of program modules
produced in a structured design 12
13
 Notes on structured design

• By breaking a complex problem down into sub-

problems one can program very complex systems
(e.g. space shuttle launch)
– Can hand off modules to other teams (at other locations)
– Specify what want to go as input to the module and what
want the module to return
– The other team takes care of the details of their module(s)

14
 Structured Analysis

• Structured analysis – a techniques to help define

– What the system needs to do (processing requirements)
– What data the system needs to store and use (data
requirements)
– What inputs and outputs are needed
– How the functions work together to accomplish tasks

• Key graphical model used – data flow diagram

(DFD)
– Shows inputs, processes, storage and outputs and how
they function together
– Based on activities (processes) and data that flow in
and out of them 15
 BOOK DATA

Orders
HANDLE CUSTOMER DATA
CUST. Credit
ORDER
Invoices status
(with books)

Example of a data flow diagram

Source or destination Rounded Process which

Square Transforms flows
of data Rectangle
of data

Arrow Flow of data

Store of
Open-ended rectangle data
16
DFD symbols
17
• Another key graphical model – the
Entity-relationship diagram (ER diagram)
– Focuses on identifying types of “things” (entities)
which the system needs to store information about (e.g.
customers, items and details)
– Specifies relationships between these things or entities
– Used a lot for design of databases – you “carve up”
your business application into entities you will store
data about

18
19
 Weaknesses of the Structured Approach

• Techniques address some but not all of the

activities of analysis and design
• Critics want a more comprehensive set of
techniques
• Many thought data modelling using structure
chart and ER diagram were more important than
modelling processes (using dataflow diagrams)
• However, the structured approach overall still
made processes rather than data the central focus
• Many felt a strategic planning technique needed to
be included as well
20
21
 The Object-Oriented Approach

• Structured approach referred to in text as

“traditional approaches”
• Newer approach is object-oriented
– Really has swept through computer industry
– Application in many areas
• Object-oriented programming (OOP)
• Object-oriented database management system (OODBMS)
• Object-oriented analysis (OOA)
• Object-oriented design (OOD)

22
 Object-Oriented Approach
• Based on notion of “objects” – things in the
computer system (and the world) which have
behaviours and respond to “messages”
• Objects can be anything
– A menu bar, or window on the screen
– A car
– A house
– A number etc.!
• Can send a message to an object
– E.g. to a window to draw itself on the computer screen
– E.g. to a number to square itself!
• Can model very complex systems (e.g. a reactor)
23
24
 History of Object Orientation

• Object-oriented approach began with development

of Simula in the 1960’s
• In 1970, Smalltalk was developed
– Allowed for development of graphical user interfaces
(with menu, button, window etc. objects)
• More recently led to other object-oriented
programming languages
– C++, Java
• Also to Object-oriented databases and
“intelligent” databases
25
 Object Oriented Terms
• Class Diagram
– A graphical model that shows all the classes of objects in the system
– For every class (grouping of related objects) there may be
specialized subclasses
– Sublcasses “inherit” properties of classes above them
– Allows for reusability

26
27
 System Development Life Cycle (SDLC)
Variations
• Traditional approach: “Waterfall method” – only
when one phase is finished does 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
28
29
30
 Differences in Approaches

• Traditional approach include feasibility study at

beginning, with system investigation and systems
analysis as the Analysis 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
31
 The “Classic” Waterfall Life Cycle

Project planning

Analysis

Design

Implementation

32
33
 Prototyping tool requirements
• 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
34
dragging onto the screen (e.g. Visual Basic)
35
 Spiral life cycle

• 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

36
37
 SDLC Variations

• 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

38
 Iteration
• 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

39
Rational Unified Process

40
 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

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

41
42
 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

43
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
44
• 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
45
• 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
46
 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

47
200 x

Cost to
Repair

Analysis Design Code Unit Test Integration Maintenance

Test

Stage when the Error is found

48
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 49
50
 Types of CASE tools
• Upper CASE tools
– Support analyst during the analysis and design phases
• Lower CASE tools
– Support for implementation – eg. 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 Architect for object-oriented modelling
• Based on UML standard for object orientation
• Allows for reverse-engineering and code generation (can
integrate with other tools like Visual C++ etc.)
51
52
53
 Background: The case for CASE
• Why need CASE?
– As software systems get large and more complex they
have become prone to unpredictable behaviour and bugs
– Problem of systems that are not reliable, do not meet
requirements or that just plain don’t work!
– CASE tries to eliminate or reduce design and development
problems
– Ultimate goal of CASE is to separate the application
program’s design (and analysis) from the program’s code
implementation
• Generally, the more detached the design process is from actual
coding, the better
• Traditional software development emphasized programming and
debugging, CASE focuses on good analysis and design
54
 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 (eg. 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 55
 Evolution of Software Tools
CASE-
Code generators

CASE-
Analysis +
Design
sophistication
Debuggers

Compilers

Assemblers

56
 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

57