Top Banner
CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.1 Software Engineering: Analysis and Design - CSE3308 David Squire [email protected] Room 5.23A B Block, Caulfield G12, Building 63, Clayton 9903 1033 (thanks to Martin Dick for initial development of course resources) CSE3308/DMS/2001/2
47
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.1

Software Engineering: Analysis and Design - CSE3308

David Squire

[email protected]

Room 5.23A B Block, CaulfieldG12, Building 63, Clayton

9903 1033

(thanks to Martin Dick for initial development of course resources)

CSE3308/DMS/2001/2

Page 2: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.2

Lecture Outline

Course Outline What is Software Engineering? Why Bother with Software Engineering? Product and Process The Software Development Lifecycle

Page 3: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.3

Course outline

Objectives Assessment Passing the Subject Lectures, the lecturer and consultation Recommended reading Assignment Work Web Pages

Page 4: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.4

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

Page 5: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.5

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

Page 6: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.6

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

Page 7: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.7

Lecturer and Consulation

Lecturer:

David SquireRoom 5.23A Building B - Caulfield campusEmail: [email protected] Phone: 9903 1033

Consultation times at Clayton campus: Wednesday 3pm - 5pm, building 63, room G.12 Thursday 3pm - 5pm, building 63, room

G.12

(note: these times may change - check subject web site)

Page 8: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.8

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

Page 9: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.9

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

Page 10: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.10

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

Page 11: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.11

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

Page 12: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.12

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.

Page 13: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.13

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

Page 14: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.14

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

Page 15: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.15

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

Page 16: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.16

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

Page 17: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.17

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

Page 18: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.18

The Software Product

Is not the same as a hardware product 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

A software product should perform the required function be reliable be maintainable be efficient have an appropriate user interface have an appropriate lifetime

Page 19: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.19

A good software product?

Page 20: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.20

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

Page 21: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.21

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.

Page 22: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.22

Characteristics of a good process

Understandability Visibility Supportability Acceptability Reliability Robustness Maintainability Rapidity

Page 23: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.23

Two questions

Is there a right process for software engineers to adopt?

Will having a good process guarantee a good product?

Page 24: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.24

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 EffortRequired

Errorsafter

releaseGigatron 5,000 1 25

Gigatron 2Deluxe

50,000 20 375 (15times

Page 25: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.25

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

Page 26: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.26

Steps in a Generic Software Process

Project Definition Requirements Analysis Design Program Implementation Component Testing Integration Testing System Testing System Delivery Maintenance

Page 27: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.27

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

Page 28: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.28

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)

Page 29: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.29

Process Activities (3)

System Delivery Implementation of the system into the working

environment and replacement of the existing system

Maintenance Corrective Adaptive Perfective

Page 30: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.30

Types of Software Processes

Traditional/Waterfall Prototyping Rapid Application Development (RAD) Evolutionary

Incremental Spiral Component Assembly

Formal Methods Fourth Generation Techniques

Page 31: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.31

The Waterfall ModelProject

Definition

System Delivery

Maintenance

Requirements Analysis

Design

Component Testing

Integration Testing

System Testing

Program Implementation

Page 32: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.32

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

Page 33: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.33

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

Page 34: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.34

Prototyping

Listen to Customer

Build/ReviseMock-up

Customertest-drivesmock-up

Page 35: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.35

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

Page 36: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.36

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

Page 37: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.37

Rapid Application Development

Business

modelling

Data modelling

Process modelling

Application

generation

Testing and turnover

Business

modelling

Data modelling

Process modelling

Application

generation

Testing and

turnover

Business

modelling

Data modelling

Process modelling

Application

generation

Testing and

turnover

Team 1 Team 2 Team 3

Page 38: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.38

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

Page 39: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.39

Incremental Development

analysis deliverydesign coding testing

analysis deliverydesign coding testing

analysis deliverydesign coding testing

analysis deliverydesign coding testing

1st Increment

2nd Increment

3rd Increment

4th Increment

Project Definition

Page 40: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.40

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

Page 41: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.41

Spiral Model

Page 42: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.42

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

Page 43: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.43

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

Page 44: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.44

Component Assembly

Page 45: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.45

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

Page 46: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.46

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

Page 47: Lectures 1A and 1B

CSE3308 - Software Engineering: Analysis and Design, 2001 Lecture 1A.47

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