“Systems Analysis and Design, I”

LECTURE 2:
Approaches to System Development

1
Lecture Outline

 Systems Development Life Cycle

 Phases and Activities in the SDLC
 Variations of the SDLC models
 Selecting the appropriate model
 Methodologies of the SDLC
 Traditional Approach to SDLC
 Information Engineering Approach to SDLC
 Object-Oriented Approach to SDLC
 Rapid Application Development
 Current trends in the SDLC
 CASE Tools 2
Systems Development Life Cycle

 Systems development life cycle (SDLC)

 Provides overall framework for managing
systems development process
 Two main approaches to SDLC
 Predictive approach – assumes project
can be planned out in advance
 Adaptive approach – more flexible,
assumes project cannot be planned out in
advance
 All projects use some variation of SDLC 3
Predictive vs. Adaptive Approach
to the SDLC

4
Phases in SDLC

 Project planning – initiate, ensure

feasibility, plan schedule, obtain approval for
project
 Analysis – understand business needs and
processing requirements
 Design – define solution system based on
requirements and analysis decisions
 Implementation – construct, test, train
users, and install new system
 Support – keep system running and improve

5
Systems Development Life Cycle

6
Systems Life Cycle

7
Activities of Each SDLC Phase

 Predictive or adaptive approach use

SDLC
 Activities of each “phase” are
similar
 Phases are not always sequential
 Phases can overlap
 Activities across phases can be
done within an iteration
8
Activities of Project Planning

 Define business problem and scope

 Produce detailed project schedule

 Confirm project feasibility

Economic, organizational, technical, resource, and
schedule

 Staff the project (resource management)

 Launch project  official announcement

9
Analysis Activities

 Gather information to learn problem domain

 Define system requirements

 Build prototypes for discovery of requirements

 Prioritize requirements

 Generate and evaluate alternatives

 Review recommendations with management

10
Design Activities

 Design and integrate the network

 Design the application architecture
 Design the user interfaces
 Design the system interfaces
 Design and integrate the database
 Prototype for design details
 Design and integrate system controls 11
Implementation Activities

 Construct software components

 Verify and test
 Convert data
 Train
users and document the
system
 Install the system

12
Support Activities (SLC, not SDLC)

 Maintain system
Small patches, repairs, and updates
 Enhance system
Small upgrades or enhancements to
expand system capabilities
Larger enhancements may require
separate development project
 Support users
Help desk and/or support team 13
FIGUR
E 2-2
The
SDLC
Phases.
14
“Waterfall” Approach to the SDLC

15
“Waterfall” Approach

 Each life cycle phase is completed in

sequence and then the results of the
phase flow on to the next phase
 There is no going back once the phase
is completed (like a waterfall) or it is
extremely difficult to do
 The key deliverables for each phase are
typically produced on paper (hundreds of
pages in length)
 The decisions made at each phase are
frozen,
frozen i.e. they cannot be changed

16
Overlap of activities

17
“Waterfall” Approach: pros and
cons

The two key advantages of the waterfall model:

• Identifying system requirements long before programming begins
• It minimizes changes to the requirements as the project proceeds

The key disadvantages:

• The design must be completely specified on paper before programming begins
• A long time elapses between the completion of the system proposal in the analysis
phase and the delivery of the system (usually many months or years).
• A paper document is often a poor communication mechanism, so important
requirements can be overlooked in the hundreds of pages of documentation
• Users rarely are prepared for their introduction to the new system, which occurs long
after the initial idea for the system was introduced.
• If the project team misses important requirements, expensive post-implementation
programming may be needed.
• A system may require significant rework because of changes in business environment
since the time the analysis phase occurred. It means going back to the initial phases
and following the changes through each of the subsequent phases in turn.
18
The Parallel Model

 The Parallel Model attempts to address the

problem of long delays between the analysis
phase and the delivery of the system.
 Instead of doing the design and implementation
in sequence, it performs a general design for the
whole system and then divides the project into
series of distinct subprojects that can be
designed and implemented in parallel
 Once all subprojects are complete, the final
integration of the separate pieces is delivered

19
The Parallel Model

20
Parallel Model: pros and cons

Primary advantages:
 Can reduce the schedule time required to deliver
a system
 There is less chance of changes in the business
environment causing rework

Key disadvantages:
 Still suffers from problems caused by paper
documentation
 A new problem: sometimes the subprojects are
not completely independent; design made in one
subproject may affect another and the end of the
project may require significant integrative efforts
21
Newer Adaptive Approaches to the
SDLC

 Based on spiral model

Project cycles through development activities over
and over until project is complete
Prototype created by end of each cycle
Focuses on mitigating risk

 Iteration – Work activities are repeated

Each iteration refines previous result
Approach assumes no one gets it right the first time
There are a series of mini projects for each iteration
22
Spiral Model

 Breaks each project into smaller pieces, each with a

different type of risk (Sources of risk: undefined
requirements, complex technology, uncertain
competitive environment)
 The project begins in the center of the spiral where
project is still small, easy to manage and low in risk
 Then the project slowly expands
 The project starts out small, initially handling a few of
the risks
 Then the project expands in next iteration to address
more of the risks
 Eventually the system is completed (all risks
addressed)

Advantage:
 The iterative nature and focus on risk reduction 23
The Spiral Life Cycle Model

24
The Model with Iterations

Iteration: the process of looping through the same

development activities multiple times, sometimes at
increasing levels of details or accuracy
 Assumes no one gets the right results the first time
 Do some analysis, then some design, then some
implementation, then do some further analysis, etc 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

Applicability:
 Good for projects where requirement specifications are hard to
arrive at

25
Iteration of System Development
Activities

26
Phased Development Model

 Breaks the overall system into a series of versions that are

developed sequentially
 The analysis phase identifies the overall system concept.
The project team, users and system sponsors categorize the
requirements into a series of versions
 The most important and fundamental requirements are
bundled into the first version of the system. The analysis
phase then leads into design and implementation, but only
with the set of requirements identified for version 1
 Once version 1 is implemented, work begins on version 2.
Additional analysis is performed on the basis of the
previously identified requirements and combined with new
ideas and issues that arose from users’ experience with
version 1.
 Version 2 then is designed and implemented, and work
immediately begins on the next version. This process
continues until the system is complete
27
Phased Model

28
Phased Model: pros and cons

 Advantages: Quickly getting a useful

system into the hands of users. Although it
does not perform all the functions the
users need, it helps them sooner to identify
important additional requirements
 Disadvantages: The users begin to work
with systems that are incomplete. It is
critical to identify the most important and
useful features and include them in the
first version.

29
Just For Fun

http://www.funnyhumor.com/pictures/206.php

30
Prototyping model

 Performs analysis, design and implementation phases

concurrently, and all three phases are performed
repeatedly in a cycle until the system is completed.
 The basics of analysis and design are performed, and
work immediately begins on a system prototype (i.e.,
a ‘quick-and-dirty” program that provides a minimal
amount of features
 The first prototype is shown to the users and the project
sponsor, who provide comments, which are used to re-
analyze, re-design, and re-implement a second
prototype that provides a few more features
 This process continues in a cycle until the analysts,
users and sponsor agree that the prototype provides
enough functionality to be installed and used.
Refinement occurs until it is accepted as the new
system.
31
Prototyping SDLC

32
Prototyping model: pros and cons

The key advantages:

• Very quickly provides a system for users to interact
with. It reassures the users that the project team is
working on the system. The users can interact with the
prototype to better understanding what it can and
cannot do rather than attempting to understand a
system specification on paper.
The major disadvantages:
• Fast-paced system releases challenge attempts to
conduct careful, methodical analysis. Often the
prototype undergoes such significant changes that
many initial design decisions become poor ones. This
can cause problems in the development of complex
systems because fundamental issues and problems are
not recognized until well into the development process.
33
 Throwaway Prototyping

 Similar to the prototyping model in that it includes the development

of prototypes, however, they are done at a different point in the
SDLC
 Has a relatively thorough analysis phase that is used to gather
information and to develop ideas for the system concept. Many of
the features suggested by the users may not be well understood and
many technical issues may not be solved.
 Each of these issues are examined by analyzing, designing and
building a design prototype (it is not a working system; it only
represents a part of the system that needs additional refinement
and it contains only enough details to enable users to understand
the issues under consideration)
 Typically, several prototypes are used during analysis and design
phase. Each of them is used to minimize the risk of missing of
important issues before the real system is built.
 Once the issues are resolved, the project moves into design and
implementation. At this point, the design prototypes are thrown
away, what is a principal difference between this model and
prototyping, in which the prototypes evolve into the final system
34
Throwaway Prototyping Model

35
Throwaway Prototyping: pros and
cons

• Balances the benefits of well-through-out

analysis and design phases with the
advantages of using prototypes to refine
key issues before a system is built.
• It may take longer to deliver the final
system as compared with prototyping (as
far as the prototypes do not become the
final system), but this model usually
produces more stable and reliable
systems.

36
Criteria for Selecting the
Appropriate Model of SDLC

37
Criteria for Selecting

Clarify of user requirements Sometimes the user requirements are unclear or subject to
change. Prototyping and throwaway prototyping are more appropriate models for
such situations, because they provide prototypes for user to interact with at early
stages of the SDLC.
Familiarity with Technology When the system will use new technology, which is
unfamiliar for the analysts and programmers (e.g. the first Web-based project with
Java), it increases the risks. Application of the new technology as early as possible
will improve the chance of success. Throwaway prototyping is particularly
appropriate for this situation since it explicitly encourages the developers to develop
design prototypes for areas with high risks. Phased model is good as well because it
creates opportunities to investigate the technology in some depth before the design is
complete.
System Complexity Complex systems require careful and detailed analysis and design.
Throwaway prototyping is particularly well suited to such situation, but prototyping
is not. The traditional structured methodologies can handle complex systems, but
without the ability to get the system or prototypes into users’ hands early on, some
key issues may be overlooked. Even though the phased model enables users to
interact with the system early in the process.
38
Criteria for Selecting

Short time schedules Projects with short time schedules are well suited for RAD models as
far as they are designed to increase the speed of development. Prototyping and phases
development are excellent choices because they best enable the project team to adjust the
functionality in the system. If the project schedule starts to slip, it can be readjusted by
removing functionality from the version or prototype under development. The waterfall
model is the worst choice, because it does not allow for easy schedule changes.

Schedule visibility One of the greatest challenges in systems development is knowing

whether a project is on schedule. This is particularly true of the structured methods
because design and implementation occur at the end of the project. The RAD models
move many of the critical design decisions to an earlier point in the project to help project
managers to recognize and address risk factors and keep expectations in check.

39
Methodologies

 Methodologies
Comprehensive guidelines to follow for
completing every SDLC activity
Collection of models, tools, and techniques

40
Relationships Among Components
of a Methodology

41
Models

 Models
Representation of an important aspect of real world,
but not same as real thing
Abstraction used to separate out aspect

• physical (like a model of an airplane)

• abstract (e.g. in form of mathematical notation or
in graphical form)
Models in SDLC are graphical: diagrams and charts
Project planning and budgeting aids

42
Some Models Used in SDLC

43
Tools

 Tools
Software support that helps create models
or other required project components
Range from simple drawing programs to
complex CASE tools to project
management software

44
Some Tools Used in SDLC

45
Techniques

 Techniques
Collection of guidelines that help analysts
complete a system development activity
or task
Can be step-by-step instructions or just
general advice

46
Some Techniques Used in SDLC

47
Two Approaches to System
Development

 Traditional approach
Also called structured system development
Structured analysis and design technique
(SADT)
Includes information engineering (IE)
 Object-oriented approach
Also called OOA, OOD, and OOP
Views information system as collection of
interacting objects that work together to
accomplish tasks 48
Traditional Approach

 Structured programming
 Improves computer program quality
 Allows other programmers to easily read
and modify code
 Each program module has one beginning
and one ending
 Three programming constructs (sequence,
decision, repetition)

49
Three Structured Programming
Constructs

50
Top-Down Programming

 Divides complex programs into hierarchy

of modules
 The module at top controls execution by
“calling” lower level modules
 Modular programming
Similar to top-down programming
 One program calls other programs to
work together as single system
51
Top-Down or Modular Programming

52
Structured Design

 Technique developed to provide design

guidelines
What set of programs should be
What program should accomplish
How programs should be organized into a
hierarchy
 Modules are shown with structure chart
 Main principle of program modules
Loosely coupled – module is independent of
other modules
Highly cohesive – module has one clear task
53
Structure Chart Created Using
Structured Design Technique

54
Structured Analysis

 Define what system needs to do (processing

requirements)
 Define data system needs to store and use
(data requirements)
 Define inputs and outputs
 Define how functions work together to
accomplish tasks
 Data flow diagrams (DFD) and entity
relationship diagrams (ERD) show results of
structured analysis 55
Data Flow Diagram (DFD) Created
Using Structured Analysis
Technique

56
Entity-Relationship Diagram (ERD)
Created Using Structured Analysis
Technique

57
Structured Analysis Leads to
Structured Design and Structured
Programming

58
Weaknesses of the Structured
Approach

• Techniques address some but not all of the activities of

analysis and design
• Techniques make system development not enough formal
(not like an engineering discipline) but rather like an art.
• The transition from the data flow diagram (in structured
analysis) to the structure chart (in structured design) did not
work well in practice.
• data modeling using structure chart and ER diagram were
more important than modeling of processes (using dataflow
diagrams)
• However, the structured approach overall still made processes
rather than data the central focus of the system
• Many felt a strategic planning technique needed to be
included in the approach to determine which systems to be built
and to provide some initial requirements.
• As an alternative: information engineering. 59
Information Engineering (IE)

 Focus on strategic planning to identify all the organization

information needs (the application architecture plan), data
modeling, and automated tools
 More focused on data itself than the structured approach.
But just as the structural approach includes data
requirements, IE includes processes, too
 The processing model of information engineering, the
process dependency diagram, is similar to a data flow
diagram, but it focuses more on which processes are
dependent on other processes and less on data inputs and
outputs
 Provides more complete life cycle support through the use of
an integrated CASE tools (help to automate systems
development; final program code can be generated
automatically by the CASE tools)
 Became popular on large-mainframe systems in the 1980’s,
less used in the 1990’s on smaller desktop systems (but
concepts still used by planning and emphasis on data
modeling) 60
Structured Approach and IE

 Both approaches define information system

requirements, design and construct information
systems by looking at processes, data and the
interaction of these two
 Industry merged key concepts from structured
development and information engineering
approaches into traditional approach

 An object-oriented technology provides a

completely different perspective

61
Object-Oriented Approach

 Completely different approach to information

systems
 Views information system as collection of
interacting objects that work together to
accomplish tasks
Objects – things in computer system that can
respond to messages
Conceptually, no processes, programs, data
entities, or files are defined – just objects
 OO languages: Java, C++, C#, .NET, VB

62
Object-Oriented Approach to
Systems

63
Object-Oriented Approach
(continued)

 Object-oriented analysis (OOA)

Defines types of objects users deal with
Shows use cases are required to complete tasks
 Object-oriented design (OOD)
Defines object types needed to communicate with people and
devices in system
Shows how objects interact to complete tasks
Refines each type of object for implementation with specific
language of environment
 Object-oriented programming (OOP)
Writing statements in programming language to define what
each type of object does 64
Class Diagram Created During OO
Analysis

65
SDLC Variations

 Many variations of SDLC in practice

Based on variation of names for phases
No matter which one, activities/tasks are similar
 Some increase emphasis on people
User-centered design, participatory design
Sociotechnical systems
 Some increase speed of development
Rapid application development (RAD)
Prototyping
66
Rapid Application Development

Rapid application development (RAD) is one of the

variations of SDLC
Aims to speed up the development process.
Emerged in the 1990s as an attempt to address both
weaknesses of the waterfall development: long development
times and the difficulty in understanding a system from paper-
based description.
Methods:
• Tries to speed up the activities in each phase (e.g. speeding the
analysis phase by scheduling intensive meetings of key participants to
get information gathered and decisions made rapidly)
• Using iterative development (e.g., spiral life cycle model) to speed up
the process of getting to design and implementation
• Building prototypes of the system during analysis and design phases.
It improves understanding of the system requirements
• Using CASE (computer-aided system engineering) tools to speed up
the analysis, design and implementation phases 67
Current Trends in Development

 More adaptive approaches

 The Unified Process (UP)
 Extreme Programming (XP)
 Scrum
 Details on each in Chapter 17

68
The Unified Process (UP)

 Object-oriented development approach

 Offered by IBM / Rational
Booch, Rumbaugh, Jacobson
 Unified Modeling Language (UML) used primarily for
modeling
 UML can be used with any OO methodology
 UP defines four life cycle phases
Inception, elaboration, construction, transition
 Defines workflows within each phase: business modeling,
requirements modeling, analysis and design,
implementation, testing, development, configuration and
change management, and project management
 Involves roles of: designer, use case specifier, systems
analyst, implementer, architect
69
Unified Process Life Cycle

70
The Unified Process (UP)
(continued)

 Reinforces six best practices

Develop iteratively

Define and manage system requirements

Use component architectures

Create visual models

Verify quality

Control changes 71
Extreme Programming (XP)

 Recent, lightweight, development approach to keep

process simple and efficient

 Describes system support needed and required system

functionality through informal user stories

 Has users describe acceptance tests to demonstrate

defined outcomes

 Relies on continuous testing and integration, heavy

user involvement, programming done by small teams

72
Scrum

 For highly adaptive project needs

 Respond to situation as rapidly as
possible
 Scrum refers to rugby game
Both are quick, agile, and self-organizing
 Team retains control over project
 Values individuals over processes

73
Computer-Aided System
Engineering (CASE) Tools

 CASE tools are software tools designed to help

systems analyst complete development tasks
 The CASE tool contains a database of information
called a repository
 The repository stores information about the system,
including models, descriptions, and references that link
the various model together
 Information stored in repository can be used in a
variety of ways by the development team
 Every time a team member adds information about the
system, it is immediately available for everyone else
 CASE tools can check the models to make sure they
are complete and follow the correct diagramming rules
 CASE tools can check one model against another to
make sure they are consistent
74
Visual Modeling Tool Repository
Contains All System Information

75
CASE Tools: Examples

Microsoft Visio
• a drawing tool suitable for about any
system model
• comes with a collection of drawing
templates (incl. symbols used in a variety
of business and engineering applications:
flowcharts, DFDs, ERDs, UML diagrams)
• provides only a limited repository for
storing definitions and descriptions of
diagram elements, but not a complete
repository for a system development
project.
76
Visio for drawing a variety of
diagrams and charts

77
CASE Tools: Examples (cont’d)

Oracle Designer
• a tool set for recording definitions and automating
the rapid constructions of flexible, graphical
client-server applications
• integrated with Oracle Developer (a tool for
creating GUI applications)
• includes a complete repository, diagramming
and code-generating capabilities
• an integrated CASE tool that supports traditional
approach to system development (process
modeler, function-hierarchy diagrammer, data flow
diagrammer, entity-relationship diagrammer)
• Design Transformer and Design Editor produce
diagrams along with the database and application
logic 78
Oracle Designer: Front Panel
screen

79
Oracle Designer: Entity-
Relationship Diagrammer

80
 CASE Tools: Examples (cont’d)

TogetherSoft
• The most recent concept of round-trip
engineering
• allows synchronizing the graphical models
(such as class diagram) with generated
program code (automation in both directions
– round trip).
• If the program code is changed, the class
diagram is updated and contra versa, if the
class diagram is changed, the program code
is updated.
• Together uses UML diagrams with several
different programming languages 81
Together showing a class diagram
with synchronized Java source code

82
CASE Tools: Examples (cont’d)

Embarcadero Describe
• a new product that include modeling
and round-trip engineering features
• provides flexible UML modeling
capabilities for analysis and design
• provides round-trip engineering with
several Java development tools
(JBuilder and Sum Forte)

83
Embarcadero Describe with visual
modeling and round-trip
engineering

84
 Readings

Today’s lecture: Chapter 2 – “Approaches to

System Development”

! !!
o u
For next lecture: Chapter 3 – “They Analyst as a
n k
Project Manager” h a
T

85