Transcript Engineering Quality Software

1
SYST30009
Engineering Quality Software
Jerry Kotuba
SYST30009-Engineering
Quality Software
Agenda
2




Course Overview & Introduction
Timetable-Schedule
Textbooks
Case Tool
 System

Architect
SLATE
 Evaluation
 Course
Materials
 Contact Info
 Roster Check-in
Jerry Kotuba
SYST30009-Engineering
Quality Software
Outcomes (High level)
3
1. List elements of software quality and discuss implications of poor
software quality.
2. Propose and document an appropriate class model for a system using
UML class diagrams.
3. Interpret a written business scenario and properly extract
classes, attributes and methods from the scenario description.
4. Interpret a written business scenario and using a class model
properly document the message passing between objects using sequence
diagrams.
5. Interpret a written business scenario and properly document the
state changes of an object with non-trivial behavior using
state charts.
6. Discuss different strategies for testing software systems.
Jerry Kotuba
SYST30009-Engineering
Quality Software
Outcomes (High level)
4
7. Competently use terminology associated with testing including
alpha-testing, beta-testing, regression testing, user acceptance
testing, smoke testing and unit testing.
8. Use techniques associated with white box testing in the design of a
test suite given source code.
9. Use techniques associated with black box testing in the design of a
test suite given a specification.
10. List motivations and advantages of using design patterns in
system design.
11. Explain object transactions and relations of at least one
design pattern...”Use Case Controller” Pattern.
Jerry Kotuba
SYST30009-Engineering
Quality Software
Strategies
5


Learn some of the “Best Practices”.
Use the Unified Process (UP) – industry best practice
Jerry Kotuba
SYST30009-Engineering
Quality Software
Symptoms of Software Development Problems
6









User or business needs not met
Requirements not addressed
Modules not integrating
Difficulties with maintenance
Late discovery of flaws/Defects (which can lead to failure)
Poor quality of end-user experience
Poor performance under load
No coordinated team effort
Build-and-release issues
Jerry Kotuba
SYST30009-Engineering
Quality Software
Systems Development Life Cycle a.k.a.
(SDLC)
7
Jerry Kotuba
SYST30009-Engineering
Quality Software
Testing is Too Late.
8




If you wait until the testing phase to ensure quality, it is too
late.
Poor requirements definitions could result in properly
implemented code that satisfies specs but not actual user
needs.
Poor design could cause a host of problems including
software that is difficult to change or very slow.
Poor implementation could result in software that produces
incorrect results, crashes or is insecure.
Jerry Kotuba
SYST30009-Engineering
Quality Software
Testing is Too Late!
9

If the requirements, design and implementation
application phases ignore quality, there may be so
many faults by the time testing starts that testing is
only used to identify which faults to live with and
which to fix.
Jerry Kotuba
SYST30009-Engineering
Quality Software
10
Jerry Kotuba
SYST30009-Engineering
Quality Software
Features of Quality Software
11





Useful and usable: good software makes peoples lives
easier or better.
Reliable: good software has few bugs.
Flexible: User’s request changes over time. Bugs are
discovered over time. The software must be flexible
enough to accommodate changes necessary for new user
requests and bug fixes.
Affordable: This pertains to both the initial cost and
maintenance cost.
Available: Software is not of much use if it is down much of
the time.
Modified from Stevens and Pooley, P.2.
Jerry Kotuba
SYST30009-Engineering
Quality Software
Effects of Software failures.
12




Cost overruns.
Late delivery.
Decreased productivity within a company or
organization.
Death.
Jerry Kotuba
SYST30009-Engineering
Quality Software
Famous Software Failures
13




Ariane 5
Denver Baggage Handling.
London Ambulance System.
Therac-25
Jerry Kotuba
SYST30009-Engineering
Quality Software
NASA Mars Climate Orbiter
14


Incident Date: 9/23/1999 Price Tag: $125 million WASHINGTON (AP) -For nine months, the Mars Climate Orbiter was speeding through space and
speaking to NASA in metric. But the engineers on the ground were replying in
non-metric English. It was a mathematical mismatch that was not caught until
after the $125-million spacecraft, a key part of NASA's Mars exploration
program, was sent crashing too low and too fast into the Martian atmosphere.
The craft has not been heard from since.
Noel Henners of Lockheed Martin Astronautics, the prime contractor for the
Mars craft, said at a news conference it was up to his company's engineers to
assure the metric systems used in one computer program were compatible with
the English system used in another program. The simple conversion check was
not done, he said.
Jerry Kotuba
SYST30009-Engineering
Quality Software
Software’s Chronic Crisis

These are not isolated incidents:
 IBM
survey of 24 companies developing distributed
systems:
 55%
of the projects cost more than expected
 68% overran their schedules
 88% had to be substantially redesigned
What is this?
First Computer Bug




In 1947, Grace Murray Hopper was working on the Harvard
University Mark II Aiken Relay Calculator (a primitive
computer).
On the 9th of September, 1947, when the machine was
experiencing problems, an investigation showed that there was
a moth trapped between the points of Relay #70, in Panel F.
The operators removed the moth and affixed it to the log. The
entry reads: "First actual case of bug being found."
The word went out that they had "debugged" the machine and
the term "debugging a computer program" was born.
18
Jerry Kotuba
SYST30009-Engineering
Quality Software
19
Jerry Kotuba
SYST30009-Engineering
Quality Software
20
Jerry Kotuba
SYST30009-Engineering
Quality Software
21
Jerry Kotuba
SYST30009-Engineering
Quality Software
Why Model Visually?
23






Captures structure and behaviour
Shows how system elements fit together
Keeps design and implementation
consistent
Hides or exposes details as appropriate
Promotes unambiguous communication
The UML provides one language for all practitioners
Jerry Kotuba
SYST30009-Engineering
Quality Software


24
The layered model approach
not only applies to software
but a variety of products.
In particular, products that
support a wide variety of
user tasks.
© 2006-2007 Jeff Patton, All rights reserved,
www.agileproductdesign.com
Let’s Look At a Product We All Use:
The Place We Live
Surface
Skeleton
Structure
Scope
Strategy
25
goals:
• live comfortably
• eat well
• stay clean
• be healthy
• keep up with Jones’s
• …
user constituencies:
• me
• spouse
• child
• …
usage contexts:
• suburban neighborhood
• near good schools
• near shopping
• …
© 2006-2007 Jeff Patton, All rights reserved,
www.agileproductdesign.com
What might I do to reach my goals?
Surface
Skeleton
Structure
user tasks:
• store food
• prepare food
• eat food
• sleep
• bathe
• store changes of clothing
• stay out of rain
• entertain guests
• entertain self
• …
Scope
Strategy
26
© 2006-2007 Jeff Patton, All rights reserved,
www.agileproductdesign.com
Arranging tasks by affinity allows me to think about contexts that best support
tasks. Contexts in a home have common names we all know.
Surface
Skeleton
Structure
Scope
Strategy
27
© 2006-2007 Jeff Patton, All rights reserved,
www.agileproductdesign.com
When designing a particular interaction context –
a kitchen for instance – I optimize layout and tool choices to support tasks I’ll do there.
Surface
Skeleton
Structure
Scope
Strategy
28
© 2006-2007 Jeff Patton, All rights reserved,
www.agileproductdesign.com
I’m going to spend a lot of time here, I want my experience to be as pleasant
as possible…
Surface
Skeleton
Structure
Scope
Strategy
29
© 2006-2007 Jeff Patton, All rights reserved,
www.agileproductdesign.com
30
Jerry Kotuba
SYST30009-Engineering
Quality Software
31
Jerry Kotuba
SYST30009-Engineering
Quality Software
32
Jerry Kotuba
SYST30009-Engineering
Quality Software
The Waterfall Approach to the SDLC
Predictive versus adaptive approaches to the SDLC
The Spiral Life Cycle Model
35
Jerry Kotuba
SYST30009-Engineering
Quality Software
The Unified Process System Development Life Cycle
36
Jerry Kotuba
SYST30009-Engineering
Quality Software
Relationships of Models, Tools, and Techniques in a System
Development Methodology
37
Jerry Kotuba
SYST30009-Engineering
Quality Software
What is UML?
38
Jerry Kotuba
SYST30009-Engineering
Quality Software
The Unified Modeling Language
39

UML is the industry standard for:
 Specifying
 Visualizing
 Constructing
 Documenting


UML simplifies the process of making a blueprint for
construction
Website: http://www.omg.org/
Jerry Kotuba
SYST30009-Engineering
Quality Software
The Unified Modeling Language
40

Combination of all diagrams depicts the system as a whole
Jerry Kotuba
SYST30009-Engineering
Quality Software
Use Case Diagram
41
Jerry Kotuba
SYST30009-Engineering
Quality Software
Class Diagram
42
Jerry Kotuba
SYST30009-Engineering
Quality Software
Sequence Diagram
43
Jerry Kotuba
SYST30009-Engineering
Quality Software
State Chart
44
Jerry Kotuba
SYST30009-Engineering
Quality Software
Tools
45
Jerry Kotuba
SYST30009-Engineering
Quality Software
A Case Tool Repository Contains All Information About the System
46
Jerry Kotuba
SYST30009-Engineering
Quality Software
Techniques
47
Jerry Kotuba
SYST30009-Engineering
Quality Software
The Unified Process System Development Life Cycle
48
Jerry Kotuba
SYST30009-Engineering
Quality Software
The Unified Process
49

Four key stages.
 Inception.
 Elaboration
 Construction
 Transition
SYST30009 - Engineering Quality Software
J.N.Kotuba
Unified Process:Inception
50



Go ahead on project.
Scope determined.
Business case developed for project.
SYST30009 - Engineering Quality Software
J.N.Kotuba
Unified Process: Elaboration
51



Basic architecture of the system developed.
Construction plan is approved.
Risks are identified.
SYST30009 - Engineering Quality Software
J.N.Kotuba
Unified Process: Construction.
52


Iterative approach to developing software.
Product will be a beta.
SYST30009 - Engineering Quality Software
J.N.Kotuba
Unified Process:Transition
53

Beta product is introduced to users and information
is collected from users during roll-out.
SYST30009 - Engineering Quality Software
J.N.Kotuba
54
SYST30009 - Engineering Quality Software
J.N.Kotuba
55
Let’s Begin the Modelling Process
Jerry Kotuba
SYST30009-Engineering
Quality Software
T
Exercise
Hospital
Pharmacy System
56
Jerry Kotuba
SYST30009-Engineering
Quality Software
Your turn…
57

Construct a context diagram…
 External




Entities…
People
Organizations
Systems
Other things outside our system that either provide data to it
or draw data from it
Jerry Kotuba
SYST30009-Engineering
Quality Software
Modeling
58


Software development is the production of
‘executable models’.
These models often are abstractions of the original
problem with classes added to solve the user’s
problems.
SYST30009 - Engineering Quality Software
J.N.Kotuba
Different Types of Models
59



Use Case Model. The system from the users point of
view.
Static Model. The elements of the system and how
they relate to one another.
Dynamic Model. Outlines the behaviour of the
system in the context of Object interactions.
SYST30009 - Engineering Quality Software
J.N.Kotuba
What is the UML?
60



The Unified Modeling language is (UML) a
language for development object-oriented models
and system designs.
It provides a complete set of graphical diagrams to
specify use cases, class diagrams and the dynamic
model (object interactions) of a system.
Can be used with different programming
languages.
SYST30009 - Engineering Quality Software
J.N.Kotuba
Use Case Model
61

A use case is a script:


A step-by-step description
of how a user might make
use of the system to do a
task
It is a “case of the usage
of the system.”
Jerry Kotuba
SYST30009-Engineering
Quality Software
Discovering Use Cases
62

Event – in the real world
Event occurs when something happens


Events drive or trigger all processing that a system does.
 What events occur that will affect the system being studied?
 What events occur that will require the system to respond in some
way?
Black Box view – focus on “what” not “how”
Jerry Kotuba
SYST30009-Engineering
Quality Software
Events – (affecting a system)
External event checklist
64
Jerry Kotuba
SYST30009-Engineering
Quality Software
Temporal Event Checklist
65
Jerry Kotuba
SYST30009-Engineering
Quality Software
Listing events
66


When analyzing a system we must list all events
Identify other information about each of them
Jerry Kotuba
SYST30009-Engineering
Quality Software
Event table
“Process”  Use Case
The Pharmacy System
68



Finalize the Event Table
Identify the Actors
Build the Use Case Diagram
SYST30009 - Engineering Quality Software
J.N.Kotuba
Using System Architect
69

Create the UC for Pharmacy System
SYST30009 - Engineering Quality Software
J.N.Kotuba
Identifying the Actors
70

Where do you look?



Context Diagram
Existing system documentation (our case)
Ask the following questions





Who or what provides inputs,such as forms, voice commands, fields on input
screens, etc to the system?
Who or what receives outputs, such as email notifications, reports, voice
messages , etc from the system?
Are interfaces required to other systems?
Are there any events that are automatically triggered at a predetermined
time?
Who (User) will maintain the information system?
SYST30009 - Engineering Quality Software
J.N.Kotuba
Use Case - Actors
71




An actor is always outside the automation boundary of the
system but may be part
of the manual portion of the system
an actor is not always the same as
the source of the event in the event table.
A source of an event is the initiating person,
such as a customer, and is always external to the system,
including the manual system.
an actor in use case analysis is the person who is actually
interacting (hands-on) with the computer system itself.
SYST30009 - Engineering Quality Software
J.N.Kotuba
Your Turn…
72


See SLATE I-C-E-01
Develop
 Context
Diagram
 Event table
 Use Case Diagram

System Architect
SYST30009 - Engineering Quality Software
J.N.Kotuba
.Summary Developing the Requirements Model:
The Use Case Model
73


Use Cases are an informal description of the system;

They do not give information about how the system does things

Or any other details internal to the system.
They just tell us


what the system will do for the users.
Concentrating on what rather than how makes them more a tool for analysis
than design, but. . .
They do give us a good starting point for both
 Testing the system, and
 Prototyping the user interface.
SYST30009 - Engineering Quality Software
J.N.Kotuba
Recap Lesson
75

Learning outcomes for today
 Develop
the requirements model
 Use cases
 Use case diagrams
 Use case narratives
SYST30009 - Engineering Quality Software
J.N.Kotuba
What comes next?
76

Next Class
 Use
Cases Activity Diagrams
SYST30009 - Engineering Quality Software
J.N.Kotuba