Software Engineering: Analysis and Design CSE3308

1
Software Engineering Analysis and Design -
CSE3308
CSE3308/DMS/2004/3

• David Squire
• David.Squire_at_csse.monash.edu.au
• Room 134, Building 75, Clayton9905 8307
• Room 5.23A B Block, Caulfield 9903 1033
• (thanks to Martin Dick for initial development of
  unit resources)

2
Lecture Outline

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

3
Unit outline

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

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

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

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

7
Lectures

• Lectures will be held at
• 200pm on Wednesdays, room S6
• 200pm on Thursdays, room C1
• 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

8
Practice Classes

• There will be two practice classes each week
• 12.00 noon to 200pm Thursday, room EH2
• 1100am to 100pm 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 and/or activities,
  which will be distributed via the unit web site,
  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

9
Lecturer and Consulation

• Lecturer David SquireOffice Clayton, Bldg. 75,
  Room 134, Ph. 9905 8307 (mostly Tue, Wed, Thu
  Fri, 1st semester) Caulfield, Bldg B, Room
  5.23A, Ph. 9903 1033 Email David.Squire_at_csse.mon
  ash.edu.auWeb http//www.csse.monash.edu.au/dav
  ids/
• Consultation
• The primary time for consultation is during the
  practice classes
• Other consultation at Clayton campus Wednesday 3
  15pm - 5pm, 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.

10
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.

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 unit

12
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

13
Web site

• The unit web site can be found athttp//www.css
  e.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

14
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

15
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.

16
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

17
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

18
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 US62 to US48

19
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

20
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

21
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

22
A good software product?
23
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

24
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.

25
Characteristics of a good process

• Understandability
• Visibility
• Supportability
• Acceptability
• Reliability
• Robustness
• Maintainability
• Rapidity

26
Two questions

• Is there a right process for software engineers
  to adopt?
• Will having a good process guarantee a good
  product?

27
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.

28
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

29
Steps in a Generic Software Process

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

30
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

31
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)

32
Process Activities (3)

• System Delivery
• Implementation of the system into the working
  environment and replacement of the existing
  system
• Maintenance
• Corrective
• Adaptive
• Perfective

33
References

• Pre200 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. 28-34.http//www.s
  tevemcconnell.com/articles/art06.htm