CSE3308/DMS/2005/2
Software Engineering: Analysis and
Design - CSE3308
David Squire
[email protected]
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
 9:00am noon to 11:00pm Wednesday, room EH2
 12:00 noon to 2:00pm Friday, room EH3
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 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:
[email protected]
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 detailed—the
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, 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, 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 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, 2005
Lecture 1A.16
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, 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



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, 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, 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, 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.
S iz e
E ffo rt
R e q u ire d
G ig a tro n
5 ,0 0 0
1
G ig a tro n 2
D e lu x e
5 0 ,0 0 0
20
CSE3308 - Software Engineering: Analysis and Design, 2005
E rro rs
a fte r
re le a s e
25
3 7 5 (1 5
tim e s
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 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, 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
Descargar

Software Engineering: Analysis and Design