Download - week01.ppt
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 1.1
Software Engineering: Analysis and Design - CSE3308
David Squire
Room 5.23A B Block, Caulfield 9903 1033
101A, Building 26, Clayton9905 3295
(thanks to Martin Dick for initial development of course resources)
CSE3308/DMS/2003/3
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 1.2
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.3
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.4
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.5
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.6
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.7
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.8
Practice Classes There will be two practice classes each week:
12.00 noon to 2:00pm Thursday, room EH2 11:00am to 1:00pm Friday, room EH2
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.9
Lecturer and Consulation
Lecturer:
David SquireClayton, Bldg. 26, Room 101A, Ph. 9905 3295
(Wed., Thu, & Fri., 1st semester)Caulfield, Bldg B, Room 5.23A, Ph. 9903 1033 Email: [email protected]
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.10
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.11
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.12
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.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, 2003 Lecture 1.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, 2003 Lecture 1.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, 2003 Lecture 1.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, 2003 Lecture 1.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, 2003 Lecture 1.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, 2003 Lecture 1.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, 2003 Lecture 1.20
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
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 1.21
A good software product?
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 1.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, 2003 Lecture 1.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, 2003 Lecture 1.24
Characteristics of a good process
Understandability Visibility Supportability Acceptability Reliability Robustness Maintainability Rapidity
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 1.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, 2003 Lecture 1.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 EffortRequired
Errorsafter
releaseGigatron 5,000 1 25
Gigatron 2Deluxe
50,000 20 375 (15times
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 1.27
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.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, 2003 Lecture 1.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, 2003 Lecture 1.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, 2003 Lecture 1.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, 2003 Lecture 1.32
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.33
The Waterfall ModelProject
Definition
System Delivery
Maintenance
Requirements Analysis
Design
Component Testing
Integration Testing
System Testing
Program Implementation
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 1.34
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.35
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.36
Prototyping
Listen to Customer
Build/ReviseMock-up
Customertest-drivesmock-up
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 1.37
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.38
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.39
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
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 1.40
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.41
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
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 1.42
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.43
Spiral Model
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 1.44
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.45
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.46
Component Assembly
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 1.47
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.48
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.49
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.50
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