cse 8314 - sw measurement and quality engineering copyright © 1995-2003, dennis j. frailey, all...

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


Attributes of a Quality Product

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

version 3.09



Safety

version 3.09


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


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


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


Principles of Professional Software Development

• These are still emerging• They are needed before software

engineering can be considered a professional discipline

version 3.09


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


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


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


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



Supportability

version 3.09


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


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


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


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


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


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


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


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


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


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


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


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



• 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


Option 3

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

ArmyROM

NavyROM

Air ForceROM

ArmyRAM

NavyRAM

Air ForceRAM

version 3.09



• 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


Option 4

• Eight Configuration Items:

CommonROM

ArmyROM

NavyROM

Air ForceROM

CommonRAM

ArmyRAM

NavyRAM

Air ForceRAM

version 3.09



• Many parts to stock and keep straight

• Excessive documentation cost• Marginal if any benefit over

option 3

version 3.09


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


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


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


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


END OFMODULE 07

cse 8314 - sw measurement and quality engineering copyright © 1995-2003, dennis j. frailey, all...

Documents