CSE 8314 - SW Measurement and Quality Engineering Copyright © 1995-2003, Dennis J. Frailey, All...

Preview:

Citation preview

version 3.09

Slide 1CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

SMU CSE 8314 / NTU SE 762-N

Software Measurement and Quality Engineering

Module 07

Attributes of a Quality Product, Part 2

version 3.09

Slide 2CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Attributes of a Quality Product

• Reliability• Maintainability• Verification• Validation• Testing and Evaluation• Safety• Supportability

version 3.09

Slide 3CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Attributes of a Quality Product

Safety

version 3.09

Slide 4CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Safety

A product is safe if it will not cause harm

• This may be hard to test• Human factors often play a big part• Software safety must be evaluated

from the perspective of the system that the software is a part of– e.g. safety issues in a word processor

vs. an aircraft system

version 3.09

Slide 5CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Software Safety

• Seldom addressed in Computer Science programs • But today, product problems are more and more

being attributed to software, and more of this is likely.

• This subject is covered in more depth in other SMU courses

version 3.09

Slide 6CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Software Liability• The day may soon come when

product liability is attributed to software developers.

Consider the software that controls a nuclear reactor. Who will be liable if it

fails and causes a major disaster?

version 3.09

Slide 7CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Principles of Professional Software Development

• These are still emerging• They are needed before software

engineering can be considered a professional discipline

version 3.09

Slide 8CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Is a Software Engineer an Engineer?

• It is illegal in many states to call yourself a software engineer unless you are a registered (licensed) professional engineer

• Several countries and at least one US State now license software engineers as professional engineers

version 3.09

Slide 9CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Is a Software Engineer an Engineer?

• CSAB/ABET has begun to accredit software engineering academic programs

• IEEE has introduced a certification program for software developers

• ASQ has a certification program for software quality engineers

• ACM and IEEE have endorsed a software engineering code of ethics

version 3.09

Slide 10CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Software Engineering Body of Knowledge

• IEEE Computer Society and eleven other sponsors have developed SWEBOK - a “guide” to the software engineering body of knowledge

www.swebok.org

• This guide is being used to define software engineering curricula in industry and academia

version 3.09

Slide 11CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

In Short ...• The time is coming when software

development professionals will be expected to adhere to recognize standards, to utilize accepted practices, and to know basic facts about their discipline

• The attorneys are educating themselves about these matters – Which means there will soon be legal

implications for unsafe software

version 3.09

Slide 12CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Attributes of a Quality Product

Supportability

version 3.09

Slide 13CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Supportability

Can it be readily supported?

• Can the software be updated (in the field)?

• Can the software be examined to determine its release, version, contents, etc.?

• Can the software be evaluated?• Can the software be tested?• etc.

version 3.09

Slide 14CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Supportability has Design Implications

• Providing access to the software– Data paths– Interfaces– Modes of operation that permit access

• Providing a means of modifying – ROM vs. RAM– Memory loading & verification/validation

• Organizing to facilitate upgrades– How are the components combined?

version 3.09

Slide 15CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Design for Supportability:Background for Example

• With defense systems (and most major commercial systems) you must designate individual “configuration items” or “products”.

• Each configuration item is a stand-alone element that has its own price, its own part number, perhaps its own contract, and requires its own documentation, maintenance procedures, etc.

version 3.09

Slide 16CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Background (2 of 3)

• Example: on a PC, the software configuration items might be the operating system, word processor, spreadsheet, database, and such.

• Alternate example: you could “bundle” the above into one configuration item - but that would mean you cannot upgrade the spreadsheet without upgrading all the others.

version 3.09

Slide 17CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Background (3 of 3)

• Alternate example: you could “unbundle” the spreadsheet into the user interface, macro processor, arithmetic processor, and other parts– But this would be needlessly complex

and expensive for the customer.

• Selection of configuration items is a major decision when designing a software system.

version 3.09

Slide 18CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Design for SupportabilityIFF System Example

Function: respond to a signal and identify yourself as a “friend”

Application: used on military vehicles in a combat zone to guard against accidental

attack by “friendly fire”

IFF System

Identify yourself!Friend or Foe?

Friend -- Here’s the Password

xxxxx

Platforms:

Airplanes -- All services, primarily USAF

Ships -- US Navy

Tanks, ATVs, etc. -- US Army

version 3.09

Slide 19CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Basic Architecture of IFF System

Common to All Platforms

Interface

(unique to each platform

)

Use of common elements saves money in development, testing and

production

version 3.09

Slide 20CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Basic Design of IFF Computer System

RAM(fast, but losescontents whenpowered down)

Low Speed ROM(large, low cost,

slow)

Note:

Three separate memory systems

Software is distributed as ROM memory chips

I/O

I/F

CPU

download at power

up

HIGH SPEED ROM(small, costly,read-only, but

retains contents)

version 3.09

Slide 21CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Three Versions of the Product

R

O

M

R

A

M

ARMY VERSION

AIR FORCE

VERSION

NAVY VERSION

I/FCOMMON

COMMON

COMMON

I/F I/F

version 3.09

Slide 22CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

How to Partition the Software? Option 1

• Three Configuration Items:

• Most of the software is common – saves money

ArmyVersion

NavyVersion

Air ForceVersion

version 3.09

Slide 23CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Issues with Option 1

• Supportability Problem: – Changing the common portion of any

one version requires changing (and re-testing) the other two -- or else losing the commonality

• Also: An upgrade requires changing two memory components - more costly

version 3.09

Slide 24CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Option 2 • Four configuration items:

• Can avoid requiring separate memory chips for common and interface by having a single chip contain two configuration items:– Common plus selected interface

Common ArmyI nterface

NavyI nterface

Air ForceI nterface

version 3.09

Slide 25CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Issues with Option 2

• Problem: – A change in the ROM part requires a

change in the RAM part as well (and vice versa)

– Must replace two memory components.

• Also– Two configuration items on one chip

causes complications in paperwork

version 3.09

Slide 26CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Option 3

• Six configuration items: – ROM & RAM part for each service

ArmyROM

NavyROM

Air ForceROM

ArmyRAM

NavyRAM

Air ForceRAM

version 3.09

Slide 27CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Issues with Option 3

• Problem: – Not a logical approach from a software

design perspective– A change to any one version requires

re-testing the common part – You still have paperwork problems

• But it is probably the most logical from a supportability perspective

version 3.09

Slide 28CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Option 4

• Eight Configuration Items:

CommonROM

ArmyROM

NavyROM

Air ForceROM

CommonRAM

ArmyRAM

NavyRAM

Air ForceRAM

version 3.09

Slide 29CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Issues with Option 4

• Many parts to stock and keep straight

• Excessive documentation cost• Marginal if any benefit over

option 3

version 3.09

Slide 30CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

An Additional Problem

• Military (and corporate) standards and policies generally dictate certain kinds of documentation, review processes, etc. for each configuration item.

• In order to avoid excessive cost, program managers often decide arbitrarily on a small number of configuration items.

version 3.09

Slide 31CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

A Preferred Approach

• Select the right number of configuration items and tailor out unnecessary documentation, reviews, etc.

• But that takes knowledge, time, preparation, planning, etc. -- i.e., MATURITY

version 3.09

Slide 32CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

Summary• There are many attributes associated

with product quality• Each of these attributes requires

effective planning and analysis• But addressing these elements results

in significant improvements in quality and savings in long term cost

• These must be addressed in the context of how people function and how people fail

version 3.09

Slide 33CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

References

• Marciniak and Evans. Software Quality Assurance and Management.

• Schulmeyer, G. Gordon and James McManus. Handbook of Software Quality Assurance, Second Edition. Van Nostrand Reinhold, New York, 1992. ISBN 0-442-00796-5.

version 3.09

Slide 34CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M07

END OFMODULE 07

Recommended