CSE3308/DMS/2001/2
Software Engineering: Analysis and
Design - CSE3308
David Squire
David.Squire@csse.monash.edu.au
Room 5.23A B Block, Caulfield
G12, Building 63, Clayton
9903 1033
(thanks to Martin Dick for initial development of course resources)
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.1
Lecture Outline
 Course
Outline
 What is Software Engineering?
 Why Bother with Software Engineering?
 Product and Process
 The Software Development Lifecycle
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.2
Course outline
 Objectives
 Assessment
 Passing
the Subject
 Lectures, the lecturer and consultation
 Recommended reading
 Assignment Work
 Web Pages
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.3
Objectives
 An
understanding of analysis and design
 A knowledge of the difficulties of specifying
and producing large software products
 An awareness of the problems of managing
large software development projects
 A knowledge of the tools used to analyse and
design systems
 Some knowledge of modern commercial
software engineering practice
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.4
Assessment and Passing
 This
will consist of two components:
 An examination worth 40% of the marks
 Assignments worth 60% of the marks
There will be two practical assignments:
» A group project worth 45%
» An individual assignment worth 15%
 You
need to achieve 50% in both the exam
and the assignments and achieve an overall
mark of 50%, i.e.
 You must get at least 20 marks out of 40 for the exam
 You must get 30 marks out of 60 for the assignments
 You must get 50 marks out of 100 overall
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.5
Lectures
 Lectures
will be held in lecture room S6 at
2:00pm on Wednesdays and C1 at 2:00pm on
Thursdays
 Notes for each week will be made available on
the subject web page in PowerPoint and
Postscript formats
 At some lectures notes will be distributed, when student
work on the notes is necessary
 It is your responsibility to ensure that you have copies of
all notes, including the assignments
 All
lecture material and assignment work is
examinable
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.6
Lecturer and Consulation
 Lecturer:
David Squire
Room 5.23A
Building B - Caulfield campus
Email: David.Squire@csse.monash.edu.au
Phone: 9903 1033
 Consultation times at Clayton campus:
 Wednesday
 Thursday
3pm - 5pm, building 63, room G.12
3pm - 5pm, building 63, room G.12
(note: these times may change - check subject web site)
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.7
Recommended Reading
 There
is no prescribed text. The following
books cover the basic material in the course:
 Booch, G., Rumbaugh, J., and Jacobson, I. The Unified
Modeling Language User Guide (1998) Hargrave Library:
005.12 B724U
 Yourdon, E.: Modern Structured Analysis (1989) Hargrave
004.21 Y81M
 The
lecture notes are long and detailed - the
intent is to give you the material you will need
 A list of further useful books is provided in
your course outline
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.8
Assignment work
 All
work submitted by a group must be solely
the work of that group
 All work submitted by an individual must
solely be the work of that individual
 This is not to mean that you may not consult with others,
but:
If you receive any help, you must specifically
acknowledge that person in your submitted work
 If any student or group of students submits work which is
not their own, they will be disciplined according to the
University and Faculty policies - see the subject web site
 Penalties range from exclusion from University to zero
marks for the subject
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.9
Web pages
 The
subject web site can be found at:
http://www.csse.monash.edu.au/courseware/cse3308/
 From week 2, information will include:
 Lectures (in Powerpoint and Postscript formats)
 Assignment specifications (in Microsoft Word and
Postscript formats)
 Links relevant to the subject
 You
should check the subject web site each
week
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.10
What is Software Engineering?
Group Exercise
 Break
into groups of 4 or 5 (i.e. your
neighbours, don’t move around the theatre)
 Take 5 minutes to write down a definition of
software engineering - this can be in point
form
 After 5 minutes, we will collect definitions
from the class
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.11
What is Software Engineering?
 Many




Definitions
“… the establishment and use of sound engineering
principles in order to obtain economically software that is
reliable and works efficiently on real machines.” (Bauer
1969)
“The application of science and mathematics by which
the capabilities of computer equipment are made useful
to man via computer programs, procedures, and
associated documentation.” (Boehm 1981)
“The application of a systematic, disciplined,
quantifiable approach to the development, operation and
maintenance of software; that is the application of
engineering to software.” (IEEE 1993)
Designing, building and maintaining large software
systems in a cost-effective way.
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.12
Why bother with Software
Engineering?
 Many
very successful projects don’t use
software engineering


examples - early Microsoft, Doom, Hotdog
but they are often not repeatable
 Many
more projects fail because they don’t
use software engineering. Failures occur
because:






of the size of the project relative to previous efforts
key personnel have left
of failure to understand requirements
the project delivers, but lacks the required quality
of the introduction of new technology
of many, many other reasons
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.13
Some classic disasters
 CS90
- How Westpac wasted $250 million
 Therac 25 - Radiation death courtesy of the
computer
 McKinsey’s PeopleNet
 New Jersey Department of Motor Vehicles
 Microsoft’s first database - Omega
 Australian Customs Service - Intelligence
Gathering System
 Denver International Airport
 London Metropolitan Ambulance System
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.14
From E-Trade to E-Grave







3rd largest on-line
stockbroking service in
the world
60,000 trades a day
February 3rd - 75
minutes downtime after
slow access
February 4th - More
downtime
February 5th - 29
minutes of downtime
Two class action law
suits
Stock price dropped
from US$62 to US$48
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.15
Some statistics
 One
in four systems miscarry
 20% turnover in staff is not uncommon
 Major corporations have up to a 30 month
backlog
 Large systems take 3 to 5 years to develop
 Corporations are spending up to 20% of
revenue on Information Technology
 Year 2000 problem took up to 50% of
resources in at least one bank in Australia.
Many of the systems were built in the 1980s
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.16
Product and Process
 Both
are key aspects in software engineering
 We move from an emphasis on product to
process, and back and forth





Structured programming - Product
Structured analysis and design - Process
Data encapsulation (OO languages) - Product
Capability Maturity Model/ISO9000 - Process
Next step?
 We
need to be able to deliver quality software
products to our customers with a consistent,
well-managed and cost-effective process
 Product and process are not a dichotomy
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.17
The Software Product
 Is
not the same as a hardware product



A
Software is developed or engineered, it isn’t
manufactured like a personal computer
Software doesn’t wear out
Most software is custom-built, rather than being
assembled from existing components
software product should






perform the required function
be reliable
be maintainable
be efficient
have an appropriate user interface
have an appropriate lifetime
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.18
A good software product?
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.19
The Software Product
 Is



composed of
Programs
Data
Documentation
 Two


main types of product
Generic - eg. Windows, Macintosh application software
Bespoke - Systems created for specific application areas
 Most
software expenditure is generic
 Most software development effort is bespoke
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.20
The Software Process
 The
set of activities and associated results
which produce a software product
 The sequence of steps required to develop
and maintain software
 Sets out the technical and management
framework for applying methods, tools and
people to the software task
 Definition:

The Software Process is a description of the process
which guides software engineers as they work by
identifying their roles and tasks.
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.21
Characteristics of a good process
 Understandability
 Visibility
 Supportability
 Acceptability
 Reliability
 Robustness
 Maintainability
 Rapidity
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.22
Two questions
Is
there a right process for
software engineers to
adopt?
Will having a good process
guarantee a good product?
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.23
When do we need process?
 We
always have some process!
 The larger the project, the greater the need for
a formal process
 Complexity of building a system when related
to size is not linear.
Size
Gigatron
5,000
Gigatron 2 50,000
Deluxe
Effort
Required
1
20
CSE3308 - Software Engineering: Analysis and Design, 2001
Errors
after
release
25
375 (15
times
Lecture 1A.24
Determining Process
 Several
Schemes
 US Department of Defense use the Project
Formality Worksheet
 Projects rate between 12 (minimal formality)
to 60 (maximum formality)
 Most student projects are well under 20 and
require very minimal formal process to be
successful
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.25
Steps in a Generic Software
Process
 Project
Definition
 Requirements Analysis
 Design
 Program Implementation
 Component Testing
 Integration Testing
 System Testing
 System Delivery
 Maintenance
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.26
Process Activities (1)
 Project


Definition
States the purpose of the project
Makes initial decision on political and technical feasibility
of the project
 Requirements

Analysis
High level definition of the functionality of the system,
primarily from the point of view of the users
 Design


Looks at the software requirements of the system and the
architecture of the system
Lower level design activities - data structures, interface
representations, procedural (algorithmic) details
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.27
Process Activities (2)
 Program

Implementation
Writing or generating the code to build the system
 Component

Testing of the individual components while they are being
built and after they have been completed
 Integration

Testing
Testing of the way individual components fit together
 System

Testing
Testing
Testing of the whole system usually in concert with the
users (acceptance testing)
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.28
Process Activities (3)
 System

Delivery
Implementation of the system into the working
environment and replacement of the existing system
 Maintenance



Corrective
Adaptive
Perfective
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.29
Types of Software Processes
 Traditional/Waterfall
 Prototyping
 Rapid
Application Development (RAD)
 Evolutionary



Incremental
Spiral
Component Assembly
 Formal
Methods
 Fourth Generation Techniques
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.30
The Waterfall Model
Project
Definition
Requirements
Analysis
Design
Program
Implementation
Component
Testing
Integration
Testing
System
Testing
System
Delivery
Maintenance
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.31
Waterfall Model
 Most
widely used
 Each step results in documentation
 May be suitable for well-understood
developments using familiar technology
 Not suited to new, different systems because
of specification uncertainty
 Difficulty in accommodating change after the
process has started
 Can accommodate iteration but indirectly
 Working version not available till late in
process
 Often get blocking states
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.32
Prototyping
 Specifying
requirements is often very difficult
 Users don’t know exactly what they want until
they see it
 Prototyping involves building a mock-up of
the system and using to obtain for user
feedback
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.33
Prototyping
Listen to
Customer
Build/Revise
Mock-up
Customer
test-drives
mock-up
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.34
Prototyping
 Ideally
mock-up serves as mechanism for
identifying requirements
 Users like the method, get a feeling for the
actual system
 Less ideally may be the basis for completed
product



prototypes often ignore quality/performance/maintenance
issues
may create pressure from users on deliver earlier
may use a less-than-ideal platform to deliver e.g Visual
Basic - excellent for prototyping, may not be as effective
in actual operation
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.35
Rapid Application Development
 Similar
to waterfall but uses a very short
development cycle (60 to 90 days to
completion)
 Uses component-based construction and
emphasises reuse and code generation
 Use multiple teams on scaleable projects
 Requires heavy resources
 Requires developers and customers who are
heavily committed
 Performance can be a problem
 Difficult to use with new technology
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.36
Rapid Application Development
Team 1
Team 2
Team 3
Business
modelling
Business
Business
modelling
modelling
Data
modelling
Data
modelling
Data
modelling
Process
modelling
Process
modelling
Process
modelling
Application
generation
Applicatio
n
Application
Testing
and
turnover
generation
generation
Testing and
turnover
CSE3308 - Software Engineering: Analysis and Design, 2001
Testing
and
turnover
Lecture 1A.37
Incremental Development
 Applies
an iterative philosophy to the
waterfall model
 Divide functionality of system into increments
and use a linear sequence of development on
each increment
 First increment delivered is usually the core
product, i.e only basic functionality
 Reviews of each increment impact on design
of later increments
 Manages risk well
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.38
Incremental Development
1st Increment
analysis
design
coding
testing
delivery
2nd Increment
analysis
design
coding
Project
Definition
testing
delivery
3rd Increment
analysis
design
coding
testing
delivery
4th Increment
analysis
CSE3308 - Software Engineering: Analysis and Design, 2001
design
coding
testing
Lecture 1A.39
delivery
The Spiral Model
 Development
cycles through multiple (3-6
task regions (6 stage version)






customer communication
planning
risk analysis
engineering
construction and release
customer evaluation
 Incremental


releases
early releases may be paper or prototypes
later releases become more complicated
 Models
software until it is no longer used
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.40
Spiral Model
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.41
Spiral Model
 Not
a silver bullet, but considered to be one
of the best approaches
 Is a realistic approach to the problems of
large scale software development
 Can use prototyping during any phase in the
evolution of product
 Requires excellent management and risk
assessment skills
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.42
Component Assembly
 Incorporates
features of the spiral model
 Usually based on object technologies, but not
necessarily e.g Visual Basic
 Compose applications from pre-packaged
software components
 Can greatly boost productivity and reuse
 Relies heavily on quality and robustness of
the software components
 Fits into the Engineering/Construction task
region of the spiral model
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.43
Component Assembly
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.44
Formal Methods
 Use
of mathematical techniques to specify
the requirements of the system e.g Z, VDM,
Object-Z
 Mainly used in life or mission-critical
applications, e.g heart pacemakers, NASA
 Can get very high quality software
 Problems



Time-consuming and expensive
Few developers have necessary skills, so extensive
training required
Difficult to use as a tool to communicate with users
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.45
Fourth Generation Techniques
 The
use of CASE and 4GL tools which let you
specify the software at a high-level
 Example: Hamilton-1 uses a formal
specification language to generate complete
system from requirements analysis ($100,000
per license)
 Use of 4GT has grown considerably in the last
decade
 Some indications of productivity
improvements for small and intermediate
applications
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.46
Fourth Generation Techniques
 Large
projects require as much or more
analysis, design and testing to achieve the
time gains from the elimination of coding
 Often problems with efficiency of
automatically generated code
CSE3308 - Software Engineering: Analysis and Design, 2001
Lecture 1A.47