CSE3308/DMS/2003/3
Software Engineering: Analysis and
Design - CSE3308
David Squire
David.Squire@csse.monash.edu.au
Room 5.23A B Block, Caulfield
9903 1033
101A, Building 26, Clayton
9905 3295
(thanks to Martin Dick for initial development of course resources)
CSE3308 - Software Engineering: Analysis and Design, 2003
Lecture 1.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, 2003
Lecture 1.2
Course outline
 Objectives
 Assessment
 Passing
the Subject
 Lectures, practice classes, the lecturer and
consultation
 Recommended reading
 Assignment Work
 Web Pages
CSE3308 - Software Engineering: Analysis and Design, 2003
Lecture 1.3
Objectives (1)
 Knowledge
of the difficulties of specifying and
producing large software products, leading to
 an appreciation of the need for software engineering
methodologies
 understanding of the distinction between software
engineering and programming, and thus the distinction
between a software configuration and a program
 An
understanding of, and ability to apply, the
methods of analysis and design, including:
 structured analysis and design using Yourdon notation
» Context Diagram, Event Lists, Data-Flow Diagrams,
Entity-Relationship Diagram, State Transition Diagrams,
Process Specifications, Data Dictionary, Structure Chart
 object-oriented analysis and design using UML
» Use Cases, Class Diagrams, Interaction Diagrams, State
Diagrams, Package Diagrams, Activity Diagrams
CSE3308 - Software Engineering: Analysis and Design, 2003
Lecture 1.4
Objectives (2)
 Knowledge
of , and the ability to apply,
principles of user interface design such as
affordances, awareness of mental models,
visibility, mapping and feedback.
 An awareness of the problems of managing
large software development projects, and the
techniques used to address them, including
 Configuration management
 Software metrics
 Validation and verification techniques
 Quality management
CSE3308 - Software Engineering: Analysis and Design, 2003
Lecture 1.5
Assessment and Passing
 There
are two assessment 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, 2003
Lecture 1.6
Lectures
 Lectures
will be held at:
 2:00pm on Wednesdays, room S6
 2:00pm on Thursdays, room C1
 Notes
for each week will be made available on
the subject web page in PowerPoint and
Portable Document Format (PDF) formats
 It is your responsibility to ensure that you have copies of
all notes, including the assignments
 All
lecture material, worksheets and
assignment work is examinable
CSE3308 - Software Engineering: Analysis and Design, 2003
Lecture 1.7
Practice Classes
 There will be two practice classes each
 12.00 noon to 2:00pm Thursday, room EH2
 11:00am to 1:00pm Friday, room EH2
week:
 Students
are expected to attend at most one
practice class per week
 During a practice class, students are
expected to work on practice problems, or on
their assignments
 The lecturer and tutors will be available to
comment on, and help with, solutions during
the practice class.
 Practice classes start in week 2
CSE3308 - Software Engineering: Analysis and Design, 2003
Lecture 1.8
Lecturer and Consulation
 Lecturer:
David Squire
Clayton, Bldg. 26, Room 101A, Ph. 9905 3295
(Wed., Thu, & Fri., 1st semester)
Caulfield, Bldg B, Room 5.23A, Ph. 9903 1033
Email: David.Squire@csse.monash.edu.au
 Consultation
 The primary time for consultation is during the practice
classes
 Other consultation at Clayton campus (preferably by
appointment):
Wednesday
3:15pm - 5pm, building 63, room G.12
CSE3308 - Software Engineering: Analysis and Design, 2003
Lecture 1.9
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)
 Yourdon, E.: Modern Structured Analysis (1989)
 Pressman, R., Software Engineering: A Practitioner's
Approach, (2000)
 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
the unit outline. Copies of these books are on
reserve in the library.
CSE3308 - Software Engineering: Analysis and Design, 2003
Lecture 1.10
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 unit web site
 Penalties range from exclusion from University to zero
marks for the subject
CSE3308 - Software Engineering: Analysis and Design, 2003
Lecture 1.11
Web pages
 The
unit web site can be found at:
http://www.csse.monash.edu.au/courseware/cse3308/
 Information at the web site will include:
 Lectures (in Powerpoint and PDF formats)
 Assignment specifications (in Microsoft Word and PDF
formats)
 Resources and links relevant to the subject
 Anonymous feedback forum
 You
should check the subject web site each
week
CSE3308 - Software Engineering: Analysis and Design, 2003
Lecture 1.12
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, 2003
Lecture 1.13
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, 2003
Lecture 1.14
Why bother with Software
Engineering?

Many very successful projects don’t use software
engineering, e.g.
 early Microsoft
 ID Software’s Doom
 Sausage’s 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, 2003
Lecture 1.15
Some classic disasters








CS90 - How Westpac wasted $150 million
Therac-25 - Radiation death courtesy of the computer
McKinsey’s PeopleNet
New Jersey Department of Motor Vehicles
Microsoft’s first Windows database - Omega
Australian Customs Service - Intelligence Gathering
System
Denver International Airport
London Ambulance Service
CSE3308 - Software Engineering: Analysis and Design, 2003
Lecture 1.16
From E-Trade to E-Grave







3rd largest on-line
stockbroking service in
the world
60,000 trades a day
February 3rd, 1999 - 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, 2003
Lecture 1.17
Some statistics
 One
in four systems miscarry
 20% turnover in staff is not uncommon
 Major corporations have a backlog of up to a
30 months
 Large systems take 3 to 5 years to develop
 Corporations are spending up to 20% of
revenue on Information Technology
 Y2K 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, 2003
Lecture 1.18
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, 2003
Lecture 1.19
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, 2003
Lecture 1.20
A good software product?
CSE3308 - Software Engineering: Analysis and Design, 2003
Lecture 1.21
The Software Product
 Is



composed of
Programs
Data
Documentation
» requirements, analysis & design documents, walkthrough minutes, test plan, user manuals, etc.
often referred to as the “software configuration”
 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, 2003
Lecture 1.22
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, 2003
Lecture 1.23
Characteristics of a good process
 Understandability
 Visibility
 Supportability
 Acceptability
 Reliability
 Robustness
 Maintainability
 Rapidity
CSE3308 - Software Engineering: Analysis and Design, 2003
Lecture 1.24
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, 2003
Lecture 1.25
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, 2003
Errors
after
release
25
375 (15
times
Lecture 1.26
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, 2003
Lecture 1.27
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, 2003
Lecture 1.28
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, 2003
Lecture 1.29
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, 2003
Lecture 1.30
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, 2003
Lecture 1.31
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, 2003
Lecture 1.32
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, 2003
Lecture 1.33
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, 2003
Lecture 1.34
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, 2003
Lecture 1.35
Prototyping
Listen to
Customer
Build/Revise
Mock-up
Customer
test-drives
mock-up
CSE3308 - Software Engineering: Analysis and Design, 2003
Lecture 1.36
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, 2003
Lecture 1.37
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, 2003
Lecture 1.38
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, 2003
Testing
and
turnover
Lecture 1.39
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, 2003
Lecture 1.40
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, 2003
design
coding
testing
Lecture 1.41
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, 2003
Lecture 1.42
Spiral Model
CSE3308 - Software Engineering: Analysis and Design, 2003
Lecture 1.43
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, 2003
Lecture 1.44
Component Assembly
 Incorporates
features of the spiral model
 Usually based on object technologies, but not
necessarily e.g. Visual Basic (older versions)
 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, 2003
Lecture 1.45
Component Assembly
CSE3308 - Software Engineering: Analysis and Design, 2003
Lecture 1.46
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, 2003
Lecture 1.47
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, 2003
Lecture 1.48
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, 2003
Lecture 1.49
References
 Pressman,
R., Software Engineering: A
Practitioner's Approach, McGraw-Hill, 2000,
(Chapters 1 and 2).
 McConnell, S., Less is More: Jump-Start
Productivity with Small Teams, Software
Development, October 1997, pp. 28-34.
http://www.stevemcconnell.com/articles/art06.htm
CSE3308 - Software Engineering: Analysis and Design, 2003
Lecture 1.50