CSE3308/DMS/2005/2

Software Engineering: Analysis and

Design - CSE3308
David Squire
David.Squire@csse.monash.edu.au
Room 134, Building 75, Clayton
9905 8307
Room 5.23A B Block, Caulfield
9903 1033
(thanks to Martin Dick for initial development of unit resources)
CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 1A.1

Lecture Outline

Unit Outline
What is Software Engineering?
Why Bother with Software Engineering?
Product and Process

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 1A.2

Unit outline

Objectives
Assessment
Passing the unit
Lectures, practice classes, the lecturer and
consultation
Recommended reading
Assignment work
Web pages

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 1A.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, 2005

Lecture 1A.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, 2005

Lecture 1A.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, 2005

Lecture 1A.6

Lectures

Lectures will be held at:

3:00pm on Wednesdays, room S6
3:00pm on Thursdays, room R4

Lecture slides for each week will be made

available on the unit web site
Lecture slides are not lecture notes. Notes are what
you write during lectures.

All lecture material, worksheets and

assignment work is examinable
It is your responsibility to ensure that you have copies of
all such materials

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 1A.7

Practice Classes

There will be two practice classes each week:

9:00am noon to 11:00pm Wednesday, room EH2
12:00 noon to 2:00pm Friday, room EH3

Students are expected to attend at most one

practice class per week
During a practice class, students are
expected to work on practice problems and/or
activities, which will be distributed via the unit
web site, or on their assignments
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, 2005

Lecture 1A.8

Lecturer and Consulation

Lecturer: David Squire

Office:
Clayton, Bldg. 75, Room 134, Ph. 9905 8307
(mostly Mon, Wed, Thu, 1st semester)
Caulfield, Bldg B, Room 5.23A, Ph. 9903 1033
Email:
David.Squire@csse.monash.edu.au
Web:
http://www.csse.monash.edu.au/~davids/
Consultation
The primary time for consultation is during the practice classes
Other consultation at Clayton campus:
Thursday
11:00am 1:00pm, building 75, room 134
Preference will be given to students who make appointments.
In time of high demand, preference will be given to students who
did not have an appointment during the previous week.

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 1A.9

Recommended Reading

There is no prescribed text. The following

books cover the basic material in the unit:
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 slides are long and detailedthe

intention 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, 2005

Lecture 1A.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 unit

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 1A.11

Assignment work (2)

Extensions
If you believe that your assignment will be delayed because of
circumstances beyond your control, you must apply for an
extension before the due date
Medical certificates or certification supporting your
application may be required

Contributions to group work

Group members will rate the contributions of all other members
these ratings will modify the mark that each individual
receives, but not by more than 20%.
If a group is having trouble with an individual member and is
unable to resolve the problem themselves:
the group must approach the lecturer to assist in resolving
the problem as soon as it arises
A claim that a student did not contribute his or her fair share
will not be considered if it is made just prior to the
submission of the assignment, or after submission

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 1A.12

Web site

The unit web site can be found at:

http://www.csse.monash.edu.au/courseware/cse3308/

Information at the web site will include:

Lectures slides
Assignment specifications
Resources and links relevant to the unit
Anonymous feedback forum

You should check the unit web site each week

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 1A.13

What is Software Engineering?

Group Exercise

Break into groups of 4 or 5 (i.e. your

neighbours, dont 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, 2005

Lecture 1A.14

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, 2005

Lecture 1A.15

Why bother with Software

Engineering?

Many very successful projects dont use software

engineering, e.g.
early Microsoft
ID Softwares Doom
Sausages Hotdog
BUT they are often not repeatable

Many more projects fail because they dont 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, 2005

Lecture 1A.16

Some classic disasters

CS90 - How Westpac wasted $150 million

Therac-25 - Radiation death courtesy of the computer
McKinseys PeopleNet
New Jersey Department of Motor Vehicles
Microsofts first Windows database - Omega
Australian Customs Service - Intelligence Gathering
System
Denver International Airport
London Ambulance Service

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 1A.17

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, 2005

Lecture 1A.18

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, 2005

Lecture 1A.19

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, 2005

Lecture 1A.20

The Software Product

Is not the same as a hardware product

Software is developed or engineered, it isnt manufactured
like a personal computer
Software doesnt wear out
Most software is custom-built, rather than being assembled
from existing components

A 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, 2005

Lecture 1A.21

A good software product?

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 1A.22

The Software Product

Is composed of
Programs
Data
Documentation
requirements, analysis & design documents, walk-through
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, 2005

Lecture 1A.23

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, 2005

Lecture 1A.24

Characteristics of a good process

Understandability
Visibility
Supportability
Acceptability
Reliability
Robustness
Maintainability
Rapidity

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 1A.25

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, 2005

Lecture 1A.26

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, 2005

Errors
after
release
25
375 (15
times

Lecture 1A.27

Determining Process

Several Schemes
US Department of Defense use the Project
Formality Worksheet [McC1997]
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, 2005

Lecture 1A.28

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, 2005

Lecture 1A.29

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, 2005

Lecture 1A.30

Process Activities (2)

Program Implementation
Writing or generating the code to build the system

Component Testing
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 of the whole system usually in concert with the
users (acceptance testing)

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 1A.31

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, 2005

Lecture 1A.32

References

[Pre2000] Pressman, R., Software

Engineering: A Practitioner's Approach,
McGraw-Hill, 2000, (Chapters 1 and 2).
[McC1997] McConnell, S., Less is More:
Jump-Start Productivity with Small Teams,
Software Development, October 1997, pp. 2834.
http://www.stevemcconnell.com/articles/art06.htm

CSE3308 - Software Engineering: Analysis and Design, 2005

Lecture 1A.33