CAN CLEAN P

PES

PRODUCE DIRTY Water WATER ? ?

By Chandan Gautam

Outline

Analogy between software & water Software quality methods Process preoccupation Product pessimism Metrics mania Fault injection solution Behavioral paradigm

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.

Analogy between software & water

Proces s

Softwar e

Continue

Original water source : Original set of requirements 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 contain redundant links.

Continue

The quality of the pipeline does affect the quality of the code, but a. to what degree and b. at what cost can vary. There is no guarantee that even the most superb software development processes will manufacture correct code.

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.

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

PROCESS PREOCCUPATION

Focus more on achieving quality than assessing it.

DO-178B, Software Considerations in Airborne Systems and Equipment Certification is a document dealing with the safety of software used in airborne systems. The Capability Maturity Model (CMM) is a development model. ISO 9003 Model for quality assurance in final inspection and test covered only the final inspection of finished product, with no concern for how the product was produced.

The unfortunate effect of the process movement

The process movement has given the perception that Clean pipes can produce only clean water . Due to believing above perception, a myth lives on in the minds of both novice and expert software engineers : Flawed software tools and flawed human efforts will somehow offset each other and produce good software.

PRODUCT PESSIMISM
In our pipeline analogy, product oriented methods would be valves at different locations along the pipe that allow the developing software.

Continue

Product-oriented methods is specifically for assessment or correctness. 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 for the same data, making it impossible to determine which model will work best for a specific system.

Why does our industry seem more preoccupied with quality processes than quality 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 .

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 outdated techniques or decide that software assessment is hopeless.

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.

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 the 1. Programs instructions & 2. Input distribution.

Continue

Structural metrics cannot capture this dynamic aspect of software behavior. This makes structural metrics especially poor quality assessors.

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.

Continue

The fault-injection methods find that your software is intolerant of internal faults or anomalies that can attack it from
external sourcessuch as human-factor errors,

failed external hardware or failed external software Then you know that the other development processes failed to build in the necessary filtering mechanisms.

FAULT INJECTION say to us

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 the desired outputs under even anomalous circumstances, then you cannot claim the pipes are clean.

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.

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 those standards and models. As David Parnas once said, It seems clear to me that not only is a mature process not sufficient,it may not even be necessary.

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 required reliability. In short, testing measures, the right thing reliabilitybut it often cannot measure it to the desired precision.

For audience..

Thank You. Any query..