1 Version 17 June 2015 Tom & Kai Gilb Slide 1 SW Quality Aimed at Technical Level Software...

Version April 18, 2023 www.Gilb.comTom & Kai Gilb

Slide 1

1

SW Quality

Aimed at Technical Level

Software Engineers, Univessity Students

50 Minute session 1500-1540


Slide 2

2

HOW TO DEFINE SOFTWARE QUALITY

3

Min:

QuickTime™ and aPhoto - JPEG decompressor

are needed to see this picture.

Monday Tuesday Wednesday Thursday Friday ToolsADDONS

8. Quality 8. Quality QuantificationQuantification

April 18, 2023 4

They Say Al SaidThey Say Al Said

“Not everything that can be counted counts,

and not everything that counts can be counted.”

Falsely attributed to Albert Einstein (according to Calaprice, Expanded Quotable Einstein, 2000)

I agree. But this does not include system qualities. Qualities can be quantified. Tom

8. Quantify

5

Min:




How to QuantifyHow to Quantify Quality Quality(how to find a Scale)(how to find a Scale)

Use known quantification ideas

Modify known quantification ideasto suit your current problems

Use your common sense and powers of observation to work out new measures

Learn early, learn often, adjust early definitions

Goal

Do

Study

Act

8. Quantify

CROSBY97: Alfred W. Crosby, The Measure of Reality. Quantification and Western Society 1250-1600, ISBN 0-521-63990-5 (paperback), 1997, Cambridge University Press, 245 pages

6

Min:




Define constraint & targets. Fail[next year] +0% <-not worse

Goal +5 years, ….] +30%<-TGWish [2004,…] +50%<-Marketing

Define benchmarks.Past[2001] +50% <-intuitive

Record [2001, ….] 0%Trend [2003,…] -30%

Give the quality a stable name tag

Environmentally FriendlyEnvironmentally FriendlyDefine approximately the target

Ambition:A degree of protection …….

Define a scale of measure:Scale: % change in environment

Decide a way to measure in practice.Meter: {scientific data…}

‘ ‘Environmentally Friendly’ Environmentally Friendly’ Quantification ExampleQuantification Example

8. Quantify

7

Min:




Exercise: Aspects of Love, orExercise: Aspects of Love, orLove is a many splendored thing!Love is a many splendored thing!

Make inventory of love’s many aspects

Quantify one requirements for love

Duration: 6 minutes

8. Quantify

8

Min:




Love AttributesLove Attributes

Kissed-ness

Care

Sharing

Respect

Comfort

Friendship

Sex

Understanding

Trust

Support

Attention

Passion <-Matheus

Satisfaction<-Mick Jagger

...

...

...

8. Quantify

9

Min:




TrustTrust [Caroline] [Caroline]

Other aspects of Trust:

Broken Agreements

Late Appointments

Late delivery

Gossiping to Others

Love.TrustTrust.Truthfulness

Ambition: NO LIES

Scale: Average Black lies/month from [defined sources].

Meter: independent confidential log from sample of the defined sources.

Past Lie Level:

Past [My Old Mate, 1999] 42 <-Bart

Goal [My Current Mate, Year = 2000] Past Lie Level/2

Black: Defined: Non White Lies

8. Quantify

Go to the Camaraderie Example

10

Min:




Devices to help quantifying quality ideas:Devices to help quantifying quality ideas:Standard Hierarchy of Concepts (& Scales)Standard Hierarchy of Concepts (& Scales)

from Gilb: Principles of Software Engineering Management.from Gilb: Principles of Software Engineering Management.

QUALITY

USABILITYWORK-

CAPACITYADAPT-ABILITY

AVAIL--ABILITY

MAINTAINABILITY RELIABILITY

1. PROBLEM RECOGNITION

6. QUALITY CONTROL

2. ADMINISTRATIVE DELAY

7. DO THE CHANGE

3. TOOLSCOLLECTION

8. TEST THECHANGE

4. PROBLEM ANALYSIS

9. RECOVERFROM FAULT

5. CHANGE SPECIFICATION

8. Quantify

11

Min:




Devices to help quantifying quality ideas:Devices to help quantifying quality ideas: ISO - 9126, Software Engineering - Product QualityISO - 9126, Software Engineering - Product Quality

Internal Metrics, External Metrics, Quality in Use MetricsInternal Metrics, External Metrics, Quality in Use Metrics

Functionality• Suitability• Accuracy• Interoperability• Security

• Compliance

Maintainability• Analyzability• Changeability• Stability• Testability

• Compliance

Usability • Understandability• Learnability• Operability• Attractiveness

• Compliance

Efficiency• Time behaviour• Resource Utilization

• Compliance

Portability• Adaptability• Installability• Replaceability• Co-existence

• Compliance

Reliability• Maturity• Fault Tolerance• Recoverability

• Compliance

8. Quantify

12

Min:




Devices to help quantifying quality ideas:Devices to help quantifying quality ideas: Using ‘Parameters’ when defining a Scale of Measure.Using ‘Parameters’ when defining a Scale of Measure.

The Scale is more flexible and re-usable!The Scale is more flexible and re-usable!

Using [qualifiers] in the Scale definition gives flexibility of detailed specification later.

Example

Scale: the % of [defined Users] using [defined system Components] who can successfully accomplish [defined Tasks]

Goal [ Users =NOVICES, Components = USER MANUAL, Goal [ Users =NOVICES, Components = USER MANUAL, Tasks = ERROR CORRECTIONTasks = ERROR CORRECTION ] 60% ] 60%

8. Quantify

13

Min:




Quality Quality QuantificationQuantification

14

Min:




How toHow to QuantifyQuantify any any Qualitative RequirementQualitative Requirement

SpecificationEstimation

QuantificationMeasurement

Diagram courtesy of Lindsey Brodie, Editor of Competitive Engineering. May 2000

8. Quantify

15

Min:




General HatmanshipGeneral Hatmanship:: Ambition: improve ability to have hats on head and nearbyAmbition: improve ability to have hats on head and nearby

Hatmanship On Head:Scale: hats on top of persons headPast [Me, This year] 10 <- GuessRecord [Guinness 96, UK] 15 <- GB RecordWish [Guinness Record, April] 20 <- TomHatmanship Nearby:Scale: hats not on head, but on, or near, body; within 10 meter radius. Past…. Goal……..etc.

A ‘Quality Quantification’ PrincipleA ‘Quality Quantification’ Principle0. THE PRINCIPLE OF

'BAD NUMBERS BEAT GOOD WORDS'

Poor quantification is more useful than none; at least it can be improved systematically.

He had a lot of hats. He wants to be best in hatmanship.

Scale: hats on his head.Scale: hats on his head.Past:3Past:3

Goal: 13Goal: 13

8. Quantify

16

Min:




10. Principles for Quality 10. Principles for Quality QuantificationQuantification

Some hopefully deep and useful guidelines

to help you quantify quality ideas

8. Quantify10PRIN

0. Bad numbers beat good words1. Quality Quantification: all qualities can be expressed quantitatively2. ‘Many splendor things’3. Scalar definition4. Threats are measurable5. Limits to detail6. Meters matter7. Horses for courses8. Benchmarks

9. Numeric future

17

Min:




0. THE PRINCIPLE OF 'BAD NUMBERS 0. THE PRINCIPLE OF 'BAD NUMBERS BEAT GOOD WORDS’ (re-visited!)BEAT GOOD WORDS’ (re-visited!)

Poor quantification is more useful than none;

at least it can be improved systematically.

State of the Art Flexibility

Enhanced Usability

Improved Performance

8. Quantify10PRIN

18

Min:




1. THE PRINCIPLE OF 'QUALITY 1. THE PRINCIPLE OF 'QUALITY QUANTIFICATION'QUANTIFICATION'

All qualities can be expressed quantitatively,

'qualitative' does not mean unmeasurable.

“If you think you know something about a subject, try to put a number on it. If you can, then maybe you know something about the subject. If you cannot then perhaps you should admit to yourself that your knowledge is of a meager and unsatisfactory kind.”

Lord Kelvin, 1893

8. Quantify10PRIN

19

Min:




2. THE PRINCIPLE OF 'MANY SPLENDORED THINGS'2. THE PRINCIPLE OF 'MANY SPLENDORED THINGS'

Most quality ideas are usefully broken into several

measures of goodness.

Usability:

Entry Qualification: Scale IQ, …….

Learning Effort: Scale: Hours to learn, …..

Productivity: Scale: Tasks per hour,…….

Error Rate: Faults per 100 tasks, …..

Like-ability: % Users who like the system, ….

8. Quantify10PRIN

20

Min:




3. THE PRINCIPLE OF 'SCALAR 3. THE PRINCIPLE OF 'SCALAR DEFINITION'DEFINITION'

A Scale of measure is a powerful practical definition of a quality

Flexibility:Scale: Speed of Conversion to New Computer Platform

8. Quantify10PRIN

21

Min:




4. THE PRINCIPLE OF 'THREATS ARE 4. THE PRINCIPLE OF 'THREATS ARE MEASURABLE'MEASURABLE'

If lack of quality can destroy your project

then you can measure it sometime;

the only discussion will be 'how early?'.

8. Quantify10PRIN

22

Min:




5. THE PRINCIPLE OF 'LIMITS TO DETAIL'5. THE PRINCIPLE OF 'LIMITS TO DETAIL'

There is a practical limit to the number of facets of quality you can define and

control,

which is far less than the number of facets that you can imagine might be relevant.

8. Quantify10PRIN

23

Min:




6. THE PRINCIPLE OF 'METERS MATTER’6. THE PRINCIPLE OF 'METERS MATTER’

Practical measuring instruments

improve

the practical understanding

and application of ‘Scales of measure’.

Portability:

Scale: Cost to convert/Module

Meter [Data] measure/1,000 words converted

Meter [Logic] measure/1,000 Function Points Converted

8. Quantify10PRIN

24

Min:




Why Meters in Requirements?Why Meters in Requirements?

Defines in practice how we intend or propose to measure and get feedback

Not absolutely necessary to state a requirement

Does help stakeholders ‘buy in’ to this level and cost of ‘testing’

Allows us to better estimate cost and time and people necessary for the necessary testing

Sends a message: ‘take this requirement seriously (in design etc) because we are really going to measure that it is delivered.

8. Quantify10PRIN

25

Min:




7. THE PRINCIPLE OF 'HORSES FOR COURSES'7. THE PRINCIPLE OF 'HORSES FOR COURSES'

Different quality-Scale measuring processes

will be necessary for

different points in time,

different events and

different places.

Availability:Scale: % Uptime for SystemMeter [USA, 2001] Test XMeter [UK, 2002] Test Y

8. Quantify10PRIN

26

Min:




8. THE PRINCIPLE OF 'BENCHMARKS'8. THE PRINCIPLE OF 'BENCHMARKS'

Past history and future trends help define words like

"improve" and "reduce".

Reliability

Scale: MTTF

Past [Brighton, 1999] 30,000 Hours

Trend [Nato Allies, 2003] 50,000 Hours

Goal [UK MOD, 2003] 60,000 Hours

8. Quantify10PRIN

27

Min:




9. THE PRINCIPLE OF 'NUMERIC FUTURE'9. THE PRINCIPLE OF 'NUMERIC FUTURE'

Numeric future requirement levels complete the quality definition of

relative terms like 'improved'.

Usability:

Scale: Time to learn average task.

Past [Old product, 1999] 20 minutes

Wish [New product, 2002] 2 minutes

Fail [End 2000, Students] 15 minutes

Goal [End 2003, Teachers] 5 minutes

8. Quantify10PRIN

28

Min:




A Corporate Quality Policy should include quantification A Corporate Quality Policy should include quantification (Ericsson)(Ericsson)

Ericsson Policy

1. QUANTIFYQUALITY

2. CONTROL MULTIPLE

DIMENSIONS

3. EVALUATERISK

4. CONFIGURATIONMANAGEMENT -TRACEABILITY

5. DOCUMENTQUALITY

EVALUATION

6. EVOLUTIONARY DELIVERYCONTROL

7. CONTINUOUSWORK PROCESSIMPROVEMENT

8. Quantify

29

Min:




(Real) Policy on QUANTIFICATION, (Real) Policy on QUANTIFICATION, CLARIFICATION AND TESTABILITY OF CLARIFICATION AND TESTABILITY OF

CRITICAL OBJECTIVES:CRITICAL OBJECTIVES:

“All critical factors or objectives (quality, benefit, resource)

for any activity (planning, engineering, management)

shall be expressed clearly, measurably, testably and unambiguously

at all stages of consideration, presentation, evaluation, construction and validation. “

<- (Quality Manual Source is) 5.2.2, 4.1.2, 4.1.5, 5.1.1, 6.1, 6.4.1, 7.1.1, 7.3 and many others.

8. Quantify


Slide 30

30

SOFTWARE TEMPLATES

31

Min:




Requirement Hierarchy and Scale TemplatesRequirement Hierarchy and Scale Templates

• These templates serve these purposes:• Instant Teaching• More intelligible than ‘Rules’• Reminds us of rules for specific spec types

• Example Scale/Benchmark/Targets/Constraints for Performance/Quality/Resource requirements

• Reminds us of opportunities (the Parameters)• Reminds us of exactly what specification is

required (<the hints> )• Reminds us of what we have not specified yet• Gives us a standard recognizable set of

parameters and parameter sequence

32

Min:




1. Performance: useful variable value deliverable to stakeholders

1.1 Qualities. ‘How well a system performs’

1.2 Capacity. ‘How much a system performs’

1.3 Savings. ‘How relatively cheaply a system performs’

SystemMission

Qualities (How well)

Savings(How much resource saved)

Capacities(How Much)

Resources

Performance Attributes

33

Min:




Performance. Concept *434. September 13, 2001Performance. Concept *434. September 13, 2001Performance is the set of attributes, for a function,

which describe its output characteristics before consequential effects on other systems are considered.

Related Concepts. Performance Levels: are the numeric levels, specified or observed, for any defined scalar

performance attribute. These are classed as Benchmarks or Targets.

Measures of Performance: MOPs: are the defined Scales of measure, we have defined, to describe the effectiveness of a system or function.

Workload (Synonym: Work Capacity) *459: ability of a system to do work in defined time or space.

Savings *429

Quantity *437: quantified measures of Workload and Saving, excluding Qualities *125. They describe ‘how much’ a system can do.

Qualities, *125: measures of performance which describe ‘how well’ they system performs. They include what most people would characterize as qualities, such as reliability, usability, security, adaptability.

Effectiveness *053

34

Min:




1.1 Qualities: 1st level subset(all are potentially Complex Attributes)

1.1.1 Availability: Scale: % of defined [Time Period] a defined [System] is [Available] for its defined [Tasks]

1.1.2 Adaptability: Scale: time needed to [Adapt] a defined [System] from a defined [Initial State] to another defined [Final State] using defined [Means].

1.1.3 Usability: Scale: Speed for defined [Users] to correctly accomplish defined [Tasks] when given defined [Instruction] under defined [Circumstances].

35

Min:




1.1.1 Availability: % ‘Up’ time. The readiness of a system to do its work.

1.1.1.1 Reliability: Scale:

Mean time for a defined [System] to experience defined [Failure Type] under defined [Conditions].

1.1.1.2 Maintainability:

Scale: Mean time to do a defined type of [Repair] to a defined [System] using defined [Repair Means] under given [Conditions].

1.1.1.3 Integrity:

Scale: Probability for a defined [System] to [Cope] with defined [Attacks] Cope= {e.g. detect, prevent, capture}. under defined [Conditions].

36

Min:




1.1.2 Adaptability: ‘The ease with which a system can be changed’

1.1.2.1 Portability: Scale:

the cost to transport a defined [System] from a defined [Initial Environment] to a [Target Environment] using defined [Means].

1.1.2.2 Extendability:

Scale: the cost to add to a defined [System] a defined [Extension Class] and defined [Extension Quantity] using a defined [Extension Means].

1.1.2.3 Improvability: Scale:

the cost to add to a defined [System] a defined [Improvement] and defined [Quantity] using a defined [Means].

37

Min:




1.1.3 Usability: ‘How easy a system is to use’

1.1.3.1 Entry Requirement: aka :Usability.Entry Requirement.Scale: the defined [Level of Knowledge] required to receive training or to use a defined [System].

1.1.3.2 Learning Requirements: Scale: the degree of training required for a defined [Type of person] to achieve a defined [Proficiency] with a defined [System]. 1.1.3.3 Handling Ability: Scale: a defined degree of [Proficiency] with a defined [System] by a defined class of [User].

1.1.3.4 Like-ability: Scale: the degree to which defined [Users] declare that they are pleased with defined [Aspects] of a System.

38

Min:




1.2 Capacity 1.2.1 Throughput:

Scale: the quantity of defined [Work Units] which can be successfully handled per [Time Unit].

1.2.2 Response:

Scale: the mean speed of defined [Reaction] to a defined [Impulse].

1.2.3 Space:

Scale: the capacity to store defined [Units] under defined [Conditions].

39

Min:




1.3 Savings 1.3.1 Financial Savings:

Scale:

net Financial savings planned or achieved

compared to a defined [Benchmark Amount].

1.3.2 Time Savings:

Scale:

net Time savings planned or achieved


1.3.2 Effort Savings:

Scale:

net Effort savings planned or achieved


1.3.3 Space Savings:

Scale:

net Space savings planned or achieved


40

Min:




Note:

a detailed treatment of these scale templates is presented in [Gilb88] chapter 19,

a copy of which will be found at www.result-planning.com.The copy has a lot more explanatory text and examples.

41

Min:




1.1.1.2 Maintainability:Performance.Quality.Availability.Maintainability.

Scale: Mean time to do a defined type of [Repair]to a defined [System] using defined [Repair Means] under given [Conditions].

42

Min:




A detailed view of Maintainability:

Maintainability: Type: Complex Requirement.

(so the following slides will define that detail structure)

43

Min:




Maintainability.Problem Recognition:

Type: Elementary Quality requirement.

Scale: Clock hours from defined [Fault Occurrence: Default: Bug Occurs in Any use or test of system]] until fault officially recognized by defined [Recognition Act: Default: Fault is Logged Electronically].

44

Min:




Maintainability.Administrative Delay:


Scale:

Clock hours from defined [Recognition Act]

until defined [Correction Action]

initiated

and assigned

to a defined [Maintenance Instance].

45

Min:




Maintainability.Tool Collection:


Scale:

Clock Hours for defined [Maintenance Instance: Default: Whoever is assigned.]

to acquire all defined [Tools: Default: all systems and information necessary to analyze, correct and QC correction]

46

Min:




Maintainability.Problem Analysis:


Scale:

Clock Time for the assigned [Maintenance Instance]

to analyze the fault symptoms

and be able to begin to formulate a correction hypothesis.

47

Min:




Maintainability.Correction HypothesisCorrection Hypothesis: :


Scale: Clock hours needed by defined [Maintenance

Instance] to fully and correctly describe the necessary

correction actions, according to current applicable standards for this.

Note [Scale]: this includes any additional time for corrections after QC and Tests.

48

Min:




Maintainability.Correction Spec Quality Control:


Scale:

Clock hours for the necessary correction-hypothesis quality-control;

against available-standards for the correction-activity.

49

Min:




Maintainability.Correction Activity: Correction Activity:


Scale: Clock Hours from beginning to correct ending,

to actually carry out the correction activity as planned.

Including any necessary corrections as a result of SQC or testing.

50

Min:




Maintainability.Unit test:


Scale: Clock Hours to carry out required unit tests for a single fault correction.

51

Min:




Maintainability.Integration Test:


Scale: Clock hours to carry out required integration tests

for a single-fault correction.

52

Min:




Maintainability.System Test:


Scale:

Clock hours to carry out required system tests

for a single-fault correction.

53

Min:




Maintainability.Beta Test: Beta Test:


Scale:

Clock hours to carry out required Beta tests

for a single-fault correction

before official release of the correction is permitted.

Source: the basic ‘Maintainability’ decomposition ideas were gleaned by me from Ireson, Editor, Reliability Handbook, McGraw Hill, 1966, and used in Gilb88. The above is an extension of those ideas.

54

Min:




Alternative Models for Usability:

The point of these 2 alternative models to the basic Usability model above is to emphasize that there is NOT one ‘correct model’.

All major projects need highly tailored models.

I also want to show some specific instances of usability sub-scales as a checklist or stimulant to the reader when building their own models.

55

Min:




Usability Alternative 1: From A Client Case about 1985 UK:

Usability: Type: Complex Quality Requirement.

56

Min:




Usability.Input/Output Media Integratedness:

Scale:

minutes to swap Input or Output device.

57

Min:




Usability. Training Need: Training Need:

Scale: hours to solo ability.

58

Min:




Usability.User productivity:

Scale: % user time lost due to our products faults or bad design.

59

Min:




Usability.User Error Rate:

Scale: % of user actions which they correct or change.

60

Min:




Usability.Users Minimum Qualification Level:

Scale: % correct answers to a defined [Qualifying Test] by a defined [User]

61

Min:




Usability.Userlessness:

Scale:

% of tasks which can run unattended.

62

Min:




Usability.Coherence:

Scale:

% of User Interface elements which are perceived as consistent with our product image.

63

Min:




Usability.User Opinion:

Scale: % of defined [User Types] who express positive feeling after using defined [System Components].

64

Min:




Usability.Customer Self-demonstratability:

Scale: Probability of successful self demonstration of product or component within 1 hour of arrival and attempt to use it.

Source of this example : Gilb88, pages 150 (Usability Example), and page 370 (the Self-Demonstratabilty requirement.

For basic models. Some enhancement of scale is made for this set of slides.

65

Min:




Example of actual definition:Example of actual definition: Usability.CUSTOMER SELF-DEMONSTRABILITYCUSTOMER SELF-DEMONSTRABILITY

Scale: ability of customer to solo self-demo any NPL product.

Meter: probability of successful completion of self-demo within one hour after arrival.

Fail: 95% to 97% <- Corporate Quality Policy

Goal: approaching 99%

Past [last year, us] less than 5% of the product line allows this now.

This example is arguably also an Adaptability sub-concept, and we will see it as such in slides below.

66

Min:




Usability Alternative 2:

SOURCE OF EXAMPLE: Europe Client 2001.

Usability:

Type Complex Quality Requirement.

(SEE FOLLOWING SLIDES FOR ELEMENTARY REQUIREMENT DETAIL TEMPLATES)

67

Min:




Usability.Entry Conditions

Scale:

<{Grade level, intelligence, experience, culture type}>

Many options, needs tailoring to system type.

68

Min:




Usability.Training Requirement:

Scale: Time needed to read any instructions or get any help in order to perform defined [Tasks]

successfully.

69

Min:




Usability.Computer Familiarity:

Scale: years of experience with computers

70

Min:




Usability.Web Experience level

Scale: years of experience with using the web

71

Min:




Usability.Productivity

Scale: ability to correctly produce defined [Work Units] default Completed Transactions

72

Min:




Usability.Error Rate:

Scale: number of erroneous transactions, requiring correction, per session.

73

Min:




Usability.Like-ability

Scale: opinion about degree of pleasure of using the system on scale of -10 to +10

74

Min:




Usability.Intuitiveness

Scale: Probability that a defined [User] can intuitively figure out how to do a defined [Task] correctly without any errors needing correction.

75

Min:




Usability.Intelligibility

Scale: Probability in % that a defined [User] will correctly interpret defined [Messages or Displays].

76

Min:




‘‘Performance.Quality.Performance.Quality.Adaptability’ Adaptability’ DetailedDetailed

Source: Gilb88, 370 (Adaptability Example) . For basic models. Some enhancement of scale is made for this set of slides.

(Photo the diagram)

77

Min:




A 7. ADAPTABILITYA 7. ADAPTABILITY

A7.1 Demonstrability Customer self-demonstrability 7.1.1 Our professional demonstrability 7.1.2

A7.2 Installability Customer 7.2.1 Professional on-site 7.2.2 Professional ex-works 7.2.3

A7.3 Interchangeability Replaceability 7.3.1 Movability 7.3.2 Interface 7.3.3

A7.4 Upgradability Node addability 7.4.1 Connection addability 7.4.2 Application addability 7.4.3 Subscriber addability 7.4.4

A7.5 Portability Data portability 7.5.1 Logic portability 7.5.2 Command portability 7.5.3 Media portability 7.5.4

A7.6 Connectability (see major objective 2)___________________________________________________________________

78

Min:




Example of actual definition: A 7.1.1 Example of actual definition: A 7.1.1

Customer Self-demonstrabilityCustomer Self-demonstrability

Scale: ability of customer to solo self-demo any NPL product.

Meter: probability of successful completion of self-demo within one hour after arrival.

Fail: 95% to 97% <- Corporate Quality Policy

Goal: approaching 99%

Past [last year, us] less than 5% of the product line allows this now.

Note: this was used by my real client as an adaptability requirement, but you might have noticed that I intentionally built it intothe Usability model example above. This is a matter of taste. The result is the same. TG

1 Version 17 June 2015 Tom & Kai Gilb Slide 1 SW Quality Aimed at Technical Level Software...

Documents

Transcript of 1 Version 17 June 2015 Tom & Kai Gilb Slide 1 SW Quality Aimed at Technical Level Software...