can clean pipes.pptx

7/29/2019 Can Clean Pipes.pptx

1/24

CAN CLEAN P PES

PRODUCE DIRTYWATER ?

By

Chandan Gautam

Water?


2/24

Outline

Analogy between software & water

Software quality methods

Process preoccupation

Product pessimism

Metrics mania

Fault injection solution

Behavioral paradigm


3/24

Of course they can.Clean pipes

can

Pipes can be attached to the wrong source

or

the original water source may infuse dirty

water into the pipeline.

There is complementary question :

Can dirty pipes produce clean water?

Once again the answer is yes.


4/24

Analogy between software &water

Proces

s

Softwar

e


5/24

Continue

Original water source : Original set ofrequirements

Each successive process applied to the

developing software

next link in the pipe

Each link in the pipe

is a process

Certain processes may

be reapplied during

development : pipeline may containredundant

links.


6/24

Continue

The quality of the pipeline does affect the

quality of the code, but

a. towhat degree and

b. at what cost can vary.

There is no guarantee that even the most

superb software development processes will

manufacture correct code.


7/24

Software quality methods

Two type :

1. Process oriented

2. Product-oriented.

Each method represents a different pipe link

Various ways of integrating these links; some

make sense, others are nonsense.

For example, it is

foolish to put the system-level testing link before a

link that checks the requirements for ambiguity.


8/24

Process-oriented standards include entities

such as

1. CMM,

2. DO178-B and

3. ISO-9003

Product oriented standards include

1. Software metrics and

2. System-level testing


9/24

PROCESS PREOCCUPATION

Focus more on achieving quality than assessing it.

DO-178B, Software Considerations in AirborneSystems and Equipment Certificationis a document

dealing with the safety of software used in airbornesystems.

The Capability Maturity Model (CMM) is adevelopment model.

ISO 9003 Modelfor quality assurance in finalinspection and testcovered only the final inspection offinished product, with no concern forhow the productwas produced.


10/24

The unfortunate effect of theprocess movement

The process movement has given theperception that

Clean pipes can produce only clean water

. Due to believing above perception, a myth

lives on in the minds of both novice and expertsoftware engineers :

Flawed software tools and flawed humanefforts

will somehow offset each other andproduce good

software.


11/24

PRODUCT PESSIMISM

In our pipelineanalogy,product orientedmethods would bevalves at differentlocations along the

pipe that allow thedeveloping software.


12/24

Continue

Product-oriented methods is specifically for

assessmentorcorrectness.

We can almost never know the true reliability

of a piece of software, most reliability models

use error history to predict failures.

Different error-history-based reliability models

can compute different reliability predictions forthe same data, making it impossible to

determine which model will work best for a

specific system.


13/24

Why does our industry seem morepreoccupied with quality processes thanquality products ?

The process-oriented methods would attempt

to ensure that the original requirements were

clean, and that every transformation through

the development cycle did not inject dirt.

Clearly, if the water is dirty at point A, then at

point B it will still be dirty and possibly dirtier,

unless you use a filter between A and B . Dirty water doesnt clean itself any more than

incorrect software corrects itself .


14/24

Continue

Exhaustive software testing is generally

infeasible.

Testing software to high levels of reliability is

intractable.

Software assurance models are often viewed

suspiciously.

Note : Most of us either cling to outdatedtechniques or decide that software assessment

is hopeless.


15/24

METRICS MANIA

Over 100 software metrics in widespread use

today mainly measure

structural or static properties,

while only a handful of approaches attempt to

measure

dynamic behavior.


16/24

Key problem with structural

metrics

It do not capture the essence of software.

Software defines a process by which an input

is transformed into an output through a

series of instructions.

Exactly what effect a particular instruction

has on the mapping between program inputs

and program outputs is determined by the1. Programs instructions &

2. Input distribution.


17/24

Continue

Structural metrics cannot capture this dynamic

aspect of software behavior.

This makes structural metrics especially poor

quality assessors.


18/24

FAULT INJECTION SOLUTION

Fault injection purposely messes up your

software during execution, then checks to see

how this affects your softwares output.

Analogy Since,fault injection operates directly on the

software, it lies near the pipeline exit and, in

some developments, will be the last pipe.


19/24

Continue

The fault-injection methods find that yoursoftware is

intolerant of internal faults or anomalies

that can attack it fromexternal sourcessuch as human-factor errors,

failed external hardware or

failed external software

Then you know that the other developmentprocesses failed to build in the necessaryfiltering mechanisms.


20/24

FAULT INJECTION say tous

Code must be designed with the proper

filtering systems to ensure that the pipe

produces crystal clear water.

If your software is incapable of producing thedesired outputs under even anomalous

circumstances, then you cannot claim the

pipes are clean.


21/24

BEHAVIORAL PARADIGM

Behavior is an intrinsic characteristic of

software and it can be viewed without regard

to the softwares development history.

Note :

Software development processes do not define

software quality; software behavior does.


22/24

Continue

Before we can have faith in software standards

and process models, they must show

a quantifiable relationship to the behavior of

the software produced according to thosestandards and models.

As David Parnas once said,

It seems clear to me that not only is a matureprocess not sufficient,it may not even be

necessary.


23/24

Conclusion

Unfortunately, the relationship between

development processes and the attainment of

some desired degree of product quality is not

well established. Performing the required processes does not

provide quantifiable confidence that the

software, when released, will have the requiredreliability.

In short, testing measures, the right thing

reliabilitybut it often cannot measure it to the

desired precision.


24/24

For audience..

Thank You.

Any query..

can clean pipes.pptx

Documents