Anda di halaman 1dari 8

(IJCNS) International Journal of Computer and Network Security, 7

Vol. 1, No. 3, December 2009

Statistical Analysis of Defect Amplification Index in


Domain Variant Commercial Software Application
Development through Fault Injection Patterns
Mr. P Mohammed Shareef1, Dr. M V Srinath2 and Dr.S.Balasubramanian3
1
Trimentus Technologies, Vibras Castle, Flat G-2, # 10, 5th Street,
Chowdry Nagar, Valasaravakkam, Chennai - 600087, India
pmshareef@gmail.com
2
Mahendra Engineering College, Department Of Computer Science Engineering,
Mahendrapuri, Tiruchengode - 637 503, Tamil Nadu, India
sri_induja@rediffmail.com
3
Anna University-Coimbatore, # 117, West Ramalinga Road
RS Puram, Coimbatore – 641002, Tamil Nadu, India
s_balasubramanian@rediffmail.com

determine its response. It has proven to be an effective


Abstract: Fault injection involves the deliberate insertion of method for measuring and studying response of defects,
faults or errors into software in order to determine its response validating fault-tolerant systems, and observing how systems
and to study its behaviour. Fault Injection Experiments have behave in the presence of faults. In this study, faults are
proven to be an effective method for measuring and studying injected in key phases of software development of business
response of defects, validating fault-tolerant systems, and application following a typical water fall software life cycle
observing how systems behave in the presence of faults. This viz., SRS, Design and Source code.
approach can offer both accuracy of fault injection results
transparency of the system dynamics in the presence of faults. 2. Literature Review
The objectives of this study are to measure and study defect
The literature review consolidates the understanding on
leakage, analyse amplification of errors and study “Domino”
effect of defects leaked. The approach for fault injection fault injection, associated topics and subsequent studies to
patterns presented in this research is validated by two emphasis the need to fault injections in business software
approaches taken to arrive at the Amplification Index (AI) that application. It also crystallizes the need for awareness, tools
represents the effect caused by defects in subsequent phases of and analyzes defect leakage/amplification.
software development in business applications. The approaches Even after 20 years of existence the awareness of fault
endeavour to demonstrate the phase wise impact of leaked injection and associated modelling with tools are very rarely
defects, through statistical analysis of defects leakage and used and understood in the commercial software industry
amplification patterns of systems, built using domain and used. The usefulness in the defect modelling and
(education, e-governance, retail, systems) variants under same building fault tolerant software systems are not properly
technology (C#.Net) , and also through a causal analysis done preached and/or practiced. Added, the availability of
on the defects injected.
appropriate literature and software tools is very few and not
Keywords: Amplification Index (AI), Defect Leakage, used in commercial and business application design and
Domino’s Effect, Fault Injection testing.
After a detailed review by the researcher it was concluded
1. Introduction that there is an industrious interest software fault injection
in the software industry to develop commercially reliable
Formulating reliable and fault tolerant software is difficult software.
and requires discipline both in specifying system
functionality and in implementing systems correctly. 3. Approach
Approaches for developing highly reliable software include In recent years there has been much interest in the field of
the use of formal methods [1], [2], [3], and rigorous testing software reliability and fault tolerance of systems and
methods [4]. commercial software. This in turn has resulted in a wealth
Testing cannot guarantee that commercial and business of literature being published around the topic, such as the
software is correct, and verification requires enormous Fault Injection in the form of the ‘Marrying Software Fault
human effort and is subject to errors. Automated support is Injection Technology Results with Software Reliability’ by
necessary to help ensure software correctness and fault Jeffrey Voas, Cigital Norman Schneidewind.
tolerance. Many critical business computer applications require
Fault injection modelling involves the deliberate insertion “fault tolerance," the ability to recover from errors or
of faults or errors into a computer system in order to exceptional conditions. Error free software is very difficult
8 (IJCNS) International Journal of Computer and Network Security,
Vol. 1, No. 3, December 2009

to create and creating fault tolerant software is an even Throughout the literature certain questions reoccur,
greater challenge. Fault tolerant software must successfully which one would anticipate when a new field emerges in
recover from a multitude of error conditions to prevent commercial software fault tolerance. People are interested,
harmful system failures. and want to understand and define commercial software
Software testing cannot demonstrate that a software reliability and fault tolerance, so the following questions
system is completely correct. An enormous number of which are recurrent throughout the literature are not
possible executions that must be examined in any real-world surprising:
sized software system. Fault tolerance expands the number Why study Fault Injection Modelling?
of states (and thus execution histories) that must be tested, Why study business software fault tolerance requirements?
because inconsistent or erroneous states must also be tested. Why are they called ‘Fault Injection & Error Seeding’?
Mailing lists, websites, research and forums have been Why review Software Implemented Fault Injection (SWIFI)?
created in which all aspects of this fresh new niche software What work was performed, current status and work
engineering area are discussed. People are interested, partly proposed?
because it is a new area but also because the whole field of These questions will be expanded upon throughout the
commercial software reliability is in itself so interesting; as research, and seek to bring clarity to those who want to find
it holds so many wide ranging disciplines, perspectives and the answers to the above, or to see if there truly are any
logic at its core. Software reliability engineering is uniting answers!
professionals in disciplines that previously had little to do
with one another, it is creating more opportunities for
4.2 Background Concepts
employment in the online environment, and it is changing
the face and structure of all information that we seek out on A fault is a hardware or software defect, inconsistency,
the web. In the era of economic recession, customer transient electrical field, or other abnormal circumstance.
demands reliable, certified and fault tolerant commercial An error is an invalid internal state, which may or may not
and business software applications. be detected by the system.
In this research, the focus is on software testing A failure is an invalid output. Thus a fault or error
techniques that use fault injection. Several potentially becomes a failure when it propagates to the output. There is
powerful existing systems have drawbacks for practical a natural progression from fault to error to failure. Recovery
application. We first examine existing fault injection code is the part of a program that is designed to respond to
techniques and evaluate their potential for practical error states. Recovery code executes after the program
application in commercial and business software recognizes that some erroneous or abnormal state has been
applications. Available and accessible literature entered. This code should gracefully restore the system to a
infrastructure including premium subscribed IEEE and valid state before a failure occurs.
ACM resources were studied and summarized for literature Figure 1 shows the progression from faults to errors and
review from 1986 (20 years). finally to failures. The recovery code should serve as a safety
net to prevent the progression from error to failure. A fault
4. Fault Injection Modeling tolerant system should never fail, even if it has faults.
Fault Injection Modelling (FIM) involves the deliberate
insertion of faults or errors into a computer system in order
to determine its response. It has proven to be an effective
method for measuring and studying response of defects,
validating fault-tolerant systems, and observing how systems
behave in the presence of faults. In this study, faults are
injected in all phases of Software Development Life Cycle
viz., Requirements, Design and Source Code.

4.1 Objectives
The key objective of this research is to understand and Figure 1. Fault Tolerance Terms
statistically analyze the behaviour of faults and defects
pattern by injecting known defects in business software Testing recovery code requires the modeling of bad states
applications artifacts (Software Requirements Specification, that accurately simulate exceptional situations. As much as
Design, Source Code) to study the “Amplification Index”, 50% of a fault tolerant program can consist of recovery
Domino Effect and defect leakage in key Software code. Although testing might include invalid data that
Development Life Cycle (SDLC) phases (Requirements, executes some of the recovery code, often much of this code
Design, Coding, Testing) of business application is never executed during normal testing.
development, with domain variants (education, e- Any recovery code testing technique must be based upon
governance, retail, systems) build on same technology(C an assumed fault model [7]. We assume that all faults will
#.Net). behave according to some specific rules. Any fault model
The goal of this research is to understand the behaviour of can only consider a subset of all possible faults.
faults and defects pattern in commercial and business
software application and defect leakage in each phase of
application development.
(IJCNS) International Journal of Computer and Network Security, 9
Vol. 1, No. 3, December 2009

For example, a common debugging practice is to insert a system behaviour in presence of errors. All of the injection
series of \print" statements in key positions. This debugging failures methods are based on concrete hardware or software
practice assumes a particular fault model. characteristics associated to systems which are applied,
Faults will cause the program to execute in the incorrect then, to realize generalizations is a very complicated task.
order and will be demonstrated
Figure 2: Taxonomy of Fault Injection Techniques in the
4.3 Prior Work on Fault Injection
printed output. Clearly, not all faults will adhere to this
model. Fault injection can be used to modify either a program's
source code text or the machine state of an executing
program. Figure 2 shows taxonomy of the key methods of
fault injection. Fault injection techniques based on static
analysis -program source modification - are modelled by the
left sub tree.
The most common static fault injection is mutation
testing. The right sub tree in Figure 2 models dynamic fault
injection techniques where changes are made to an actively
running program's state. Much of the recent fault injection
research is concerned with dynamic injection.

4. 4 Domino’s effect
Domino’s effect is the cascading effect of defects from the
initial stages of the project to all the subsequent stages of the
software life cycle. Errors undetected in one work product
are ‘leaked’ to the child work product and amplifies defects
Figure 2. Taxonomy Of Fault Injection Techniques
in the child work product. This chain reaction causes an
No one fault model will fit all faults. However, a fault exponential defect leakage. E.g.: undetected errors in
model can be very effective in detecting faults that fit the requirements leak and cause a significant number of defects
model. in design which, in turn, causes more defects in the source
Fault Injection technique of fault injection dates back to code. The result of this study is to arrive at an
the 1970s when it was first used to induce faults at a “Amplification Index” which will characterize the extent of
hardware level. This type of fault injection is called impact or damage of phase-wise defects in subsequent
Hardware Implemented Fault Injection (HWIFI) and Software Development Life Cycle (SDLC) phases.
attempts to simulate hardware failures within a system. The The defect components in a work product and leakage
first experiments in hardware fault injection involved into subsequent phases is illustrated below:
nothing more than shorting connections on circuit boards
and observing the effect on the system (bridging faults). It
was used primarily as a test of the dependability of the
hardware system. Later specialised hardware was developed
to extend this technique, such as devices to bombard specific
areas of a circuit board with heavy radiation. It was soon
found that faults could be induced by software techniques
and that aspects of this technique could be useful for
assessing software systems. Collectively these techniques are
known as Software Implemented Fault Injection (SWIFI) [8].
Martin defines software fault injections as faults which
are injected at the software level by corrupting code or data.
So faults are applicable at the implementation phase when
the code of the system is available, and it can be applied on Figure 3. Fault Injection Patten
an application to simulate either internal or external faults.
Internal faults represent design and implementation
5. Trimentus Approach For Fault Injection
faults, such as variables/parameters that are wrong or not
initialized, incorrect assignments or condition checks. Experiments
External faults represent all external factors that are not Defects were deliberately injected into each phase (work
related to faults in the code itself but that alter the system's product) in the software development life cycle of a typical
state. application development project and the effect of the defects
The injection of failures can discover errors that normal injected was studied subsequently. The injected defects are
procedures cannot. First, it tests the mechanisms of typical defects that are characteristic of the software systems
exception and treatment of failures that in normal of a commercial application developed in the following
circumstances are not sufficiently proven and, helps to domains;
evaluate the risk, verifying how much defective can be the
10 (IJCNS) International Journal of Computer and Network Security,
Vol. 1, No. 3, December 2009

are also relevant, especially if they could be automatically


Table 1: Application and Domain generated. Unfortunately, manual rewriting of sections of
code is prohibitive in a large system.

6. WHY STUDY FAULT INJECTION MODELLING?


Fault Injection Modelling has gradually crept into
prominence over the last decade as one of the new buzz
words in software design.
However, as Martin observes:
‘The main characteristic of fault injection software is that it
is capable of injecting failures into any functional
An approach was adopted towards studying the impact of addressing unit by means of software, such as memory,
defect amplification in a software system was causal analysis registers, and peripherals. The goal of the fault injection
of the defects occurring in subsequent phases caused due to software is to reproduce, in the logical scope, the errors that
injected defects. are reproduced after failures in the hardware. A good
Fault injection can occur in several ways: characterization of failure model should be allowed that this
Additional code can be linked to the target program and one was as versatile as possible, allowing a major number of
executed synchronously with the program flow. combinations among the location, trigger conditions, kind of
A separate process can perform the injection fault and duration, so that the coverage was maximum.
asynchronously with the flow of the target process. Recent days, the Fault Injection technique has been
Separate hardware can directly access the memory to considered as a very useful tool to monitor and evaluate the
modify the state, thus not affecting the timing characteristics behaviour of computing systems in the presence of faults.
of the target process. It’s because the tool tries to produce or simulate faults
Overlay faults occur when a program writes into an during an execution of the system under test, and then the
incorrect location due to a faulty destination operand. behaviour of the system is detected [9].
Chillarege and Bowen claim that overlay faults account for The Carnegie Mellon Software Engineering Institute1
34% of the errors in systems programs. The experiment reports that at least 42-50 percent of software defects
involved the use of failure acceleration, decreasing fault and originate in the requirements phase.
error latency and increasing the probability that a fault will The Defence Acquisition University Program Manager
cause an error. The experiment applied failure acceleration Magazine2 reports that a Department of Defence study that
by corrupting a large region of memory in a single injection. over 50 percent of all software errors originate in the
To inject an overlay fault, all bits in an entire page of requirements phase.
physical memory are set to one. Because the page is in
physical memory, the probability that the latency will be
short is further increased. About 16% of the faults
immediately crashed the system; about 14% caused a partial
loss of service, which was usually recovered from soon after.
Half of the faults did not cause failures. These potential
hazards are failures waiting to occur. The injection process
used was manual and only 70 faults were injected during the
entire experiment.
Software faults introduced include:
Initialization faults: incorrectly or uninitialized variables.
They are modelled by dynamically replacing the initializing
assembly instructions with incorrect values or no-ops.
Assignment faults: incorrect assignment statements.
Variable names on the right hand side are changed by
dynamically mutating the assembly code. Figure 4. Relative Cost to Fix Defects Vs Development
Condition check faults: missing condition checks, for Phases
example, failure to verify return values. Condition checks
are either entirely overwritten with no-ops, or replaced an 1. MSDN (November, 2005) “Leveraging the Role of
incorrect condition check. Testing and Quality Across the Lifecycle to Cut Costs and
Function faults: Invalid functions. The assembly code for Drive IT/Business Responsiveness “
a function is dynamically replaced with the assembly code 2. Direct Return on Investment of Software Independent
from a manually rewritten alternate version. Verification and Validation: Methodology and Initial Case
Initialization faults can be caught statically with a good Studies, James B. Dabney and Gary Barber, Assurance
compiler. The assignment and condition check faults are Technology Symposium, 5 June 2003.
clearly relevant to the testing of recovery code, since an
incorrect assignment or condition can be a condition that
should force the execution of recovery code. Function faults
(IJCNS) International Journal of Computer and Network Security, 11
Vol. 1, No. 3, December 2009

to FIM had different varied domain implementation and


knowledge for the application was high; it can be
7. Description of software systems developed independently managed and developed; it covers the entire
A Library Management System (LMS) help in automating development life cycle; and the technology used is typical of
functions of the library. It helps in reducing the time spent current commercial applications and technologies in vogue.
in record keeping and management effectively. The SDLC, technology, exclusiveness allows different types of
management information system application was used to faults to be injected at various phases without bias and
conduct the fault injection experiments. The same enables direct comparison.
application was developed in the following technologies in In this paper, the system contains injected defects common
3G languages; across all projects. The same count of defects (5 numbers)
were introduced in each phase of SDLC. The defect review
Table 2: LMS efficiency was assumed to independent of application
domain and same technology based defect removal
efficiency was considered across all applications.
8. Results of the experiments
A Post Office Management System (POMS) help in
automating functions of the post office and e-Governance. 8.1 Requirements Review
Post Office management System is an application which is SRS (Software Requirement Specification) document was
created for the use of an automated system all over the prepared and used as the basis for development of for all the
country. The information system application was used to projects. However, after the review of SRS, defects were
conduct the fault injection experiments. The same injected into the same document. The SRS containing the
application was developed in the following technologies in defects were base lined by project team respectively to be
3G languages; used as basis for the design.
Table 3: POMS 8.2 Design Phase Analysis
Design document prepared with (fault injected) SRS as
basis. There were several defects observed with “source” as
SRS. The Injected defects are major cause for design defects.

A Point Of Sales (POS) is retail systems for recording 8.2.1 Design Review
sales and billing at a cash counter of typical establishment.
POS is developed to automate the operations and billing Table 6: SRS And Design Of The Four Applications
applications of super markets. The information system
application was used to conduct the fault injection
experiments. The same application was developed in the
following technologies in 3G languages;

Table 4: POS

An Audit Tracking System (ATS) is a systems application 8.2.2 Design Defect Amplification: Domain Variant
used to conduct the fault injection experiments. The The following chart represents the comparison of
application chosen was the Audit Tracking System (ATS) amplification index between the applications developed on
that is used to automate the process for recording, same technology. The amplification of design defects caused
communicating and monitoring all the audit findings that due to the injected requirement defects in the application is
take place within the organization. The same application evidenced in all domains and least prominent in retail
was developed in the following technologies in 3G application.
languages;
AI Trend - Application Wise

Table 5: ATS 0.5 0.5 0.5 0.5


0.5
0.4
0.4
0.3 0.3
AI

0.3
0.2
0.2

The four applications were simultaneously developed by 0.1


0.1
different project team and were made mutually exclusive. 0.0
LMS POMS POS ATS
The application development for the projects followed the Design Phase - Application
same process as described in the quality management system
for software development of Trimentus. Applications chosen Figure 5. Amplification Index Trend - Design
12 (IJCNS) International Journal of Computer and Network Security,
Vol. 1, No. 3, December 2009

Analysis: The R square value for the prediction equation is


8.2.3 Calculation of Amplification Index (AI) 0.19. So the Correlation is not strengthened. So the R
The following methodology was used to calculate Square test Failed.
Requirement Amplification Index (Table 7) (i.e. impact of Test 2 : Significance F test
Requirements defects on Design) Condition: It is Generally Accepted that if the p-value is
less than 0.05, the input variable is Significant
Table 7: Methodology Used To Calculate Requirement Analysis: The Significance F Value is 0.55, which is Greater
Amplification Index than 0.05.So Significance F test failed
To conclude, by the statistical failure of two tests, it is
concluded that there is no correlation between the
Amplification Index (AI) of Requirement and Design across
domains.

8.3 Coding Phase Analysis


Coding was performed with (fault injected) design as basis.
There were several defects observed with “source” as Design
and Requirements. The Injected defects were the major
cause for Code defects detected in Code review.

8.2.4 Defects in Design 8.3.1 Code Review of Applications


Various types of known design defects were introduced after
design review:
Table 9: SRS, Design And Code
8.2.5 Statistical Analysis and Relationship
Based on the AI derived from the above requirement data
analysis, a statistical study was carried out understand and
analyse the statistical significance and relationship of AI
across domains.
A regression analysis using was carried out to under the
relationship between a dependent variable, i.e., Design AI to
independent variable i.e., Requirement AI.
Minitab tool was used to analyse the data set of
Amplification Indexes.
Analysis Results:

Table 8: AI Derived From Requirement Data Analysis


8.3.2 Code Defect Amplification: Domain Variant
The following chart represents the comparison of
amplification index between different applications
developed on same technology. The amplification of coding
defects caused due to the injected design defects in
applications is evidenced in all domains and more
prominent in education domain.
AI Trend - Application Wise

1.0 0.9
0.9
0.8
0.7 0.6
0.6 0.5 0.5
0.5
AI

0.4
0.3
0.2
0.1
0.0
LMS POMS POS ATS
Coding Phase - Applications

Figure 6. Amplification Index Trend – Code


Test 1: R Square Test
Condition: The larger is the R Square value the better is
the model (It would range from 0 (Poor) to 1 (Excellent)
(IJCNS) International Journal of Computer and Network Security, 13
Vol. 1, No. 3, December 2009

8.3.3 Amplification Index for Code Test 2 : Significance F test


The following methodology was used to calculate Design Condition: It is Generally Accepted that if the p-value is
Amplification Index (i.e. impact of Design defects on Code) less than 0.05, the input variable is Significant
Analysis: The Significance F Value is 0.10, which is Greater
Table 10: Methodology Used To Calculate Design than 0.05.So Significance F test failed.
Amplification Index To conclude, by the statistical analysis by the failure of
Significance F test, it is concluded that there is no positive
correlation between the Amplification Index (AI) of Design
and Code across domains.

9. CONCLUSIONS
9.1 AI Trend Analysis
The Amplification Index indicates the extent of damage
caused by a defect in various phases of the project. The
index increases with every step in the life cycle of the
project in all domains. Initial analysis of these defects in the
education domain application shows substantial increase in
the amplification index across phases compared other
application domains.
Within the experimentation limits, it was concluded and
8.3.4 Statistical Analysis and Validation validated statistically that there is no statistically significant
Similarly, based on the AI derived from the above design relationship, and correlation between defects amplification
data analysis, a statistical study was carried out to index on requirements vs design and design vs code on
understand and analyse the statistical significance and applications developed under different domains under a
relationship of AI across design phases. common technology
A regression analysis using was carried out to under the
relationship between a dependent variable, i.e., Code AI to AI Trend - Application Wise
independent variable i.e., Design AI.
Minitab tool was used to analyse the data set of 1.9
2.0
Amplification Indexes.
Analysis Results: 1.8
1.6
Table 11: AI Derived From Design Data Analysis 1.4 LMS
1.2 1.1
0.9 PMOS
1.0 0.8
AI

0.8 0.6 POS


0.5 0.5 0.6
0.6 0.5 0.5 0.5 ATS
0.4 0.3
0.2
0.0
Req Design Coding
Phases

Figure 7. Amplification Index Trend – Application wise

9.2 Defect Leakage and Distribution Analysis

The defect leakage analysis emphasizes the importance of


thorough and systematic reviews in the early stages of a
software project with an emphasis on defect prevention. The
analysis indicates a high increase of cost and effort to
Test 1: remove the defects at later stages. The number of defects
R Square Test increases exponentially as a direct result of defects leaked
Condition: The larger is the R Square value the better is from previous stages.
the model (It would range from 0 (Poor) to 1 (Excellent)
Analysis: The R square Value for the Prediction equation is
0.79. A Positive Correlation is identified.
14 (IJCNS) International Journal of Computer and Network Security,
Vol. 1, No. 3, December 2009

editors, Computer Program Testing, pages 13-24.


Defect Leakage - Application Wise North-Holland, 1981.
16
[6] R. DeMillo, R. Lipton, and A. Perlis. Social processes
14
and proofs of theorems and programs. Communications
14
12 of the ACM, 22(5):803-820, May 1979.
LMS
10 9 10
[7] Barry W. Johnson. Design and Analysis of Fault-
D e fe c ts

POMS
8 87
Tolerant Digital Systems. Addison-Wesley,
7 POS
6 6 Massachusetts, 1989.
5 ATS
4 4 45 [8] Daniel Dreilinger, Lijun Lin. Using Fault Injection to
3
2 Test Software Recovery Code, November 1995
0 [9] Leme, Nelson G. M.; Martins, Eliane; Rubira, Cecilia
Req Design Coding Testing
M. F. “A Software Fault Injection Pattern System”.
Phases Proceedings of the IX Brazilian Symposium on Fault-
Tolerant Computing. Florianópolis, SC, Brazil, March
Figure 8. Defect Leakage – Application Wise
5th-7th, 2001, pages 99-113.

10. Future Experiments


Authors Profile
Currently, the study is being extended to analyse the effect
of the defects and amplification index in the development Mr. Paloli Mohammed Shareef, CISA,
phases of the different technologies based projects developed CISM, CGEIT, PMP, is the Executive
with same product. Vice President and Principal Consultant
Guidelines for review time and effort estimation are being of Trimentus Technologies, is a research
computed by analysing and defining the review and test stop scholar at Anna University – Coimbatore
criteria. Error seeding during testing can be carried out to with over 12 years of experience in
define the test stop criteria. Software Engineering, Quality
Management and Information Security.
He has special interest in software
11. Limitations of Experiments reliability and information security management. He has authored
The following are the limitations of the experiments: 15 technical papers and made presentations in forums and
Causal analysis is relatively subjective to understand the institutions such as CSI, SPIN, Anna Universities, and
cause of amplified defect. This required detailed review and Professional Engineering Colleges.
discussion with project team and technical/technology
experts.
Dr. M V Srinath, PhD, is the Professor,
Defect removal efficiency percentage used for Mahendra Engineering College,
experiments in same technology is based on a test in a Namakkal, with over 12 years of
sample requirement, design and code with known defects experience in Multimedia Instructional
provided to project members and review efficiency Design and Delivery and Principles and
percentage derived from the defects detected. Practices of Software Engineering and
It is verified that the skill set and domain knowledge of Web Engineering. He has special interest
the analysts and programmers working in the projects are in Instructional Materials and Media. He
same and/or similar. has authored over 50 technical/journal
papers and the resource person for the
courses organized and conducted by National Institute of Technical
References Teachers Training and Research (NITTTR) for the teachers of
Polytechnics and Engineering colleges.
[1] A. Hall. Seven myths of formal methods. IEEE
Software, 7(5):11-19, September 1990. Dr. S Balasubramanian, PhD, is the
Former Director – IPR, Anna University –
[2] C.B. Jones. Systematic Software Development Using Coimbatore with over 18 years experience
VDM. Prentice-Hall International, London, 1986. in Industrial Engineering and Software
[3] S.J. Garland, J.V. Guttag, and J.J. Horning. Debugging Engineering. He has special interest in
larch shared language specifications. IEEE Trans. research and educational initiatives. He
Software Engineering, 16(9):1044-1057, September has authored and published over 25
1990. technical and managerial papers. He is the
authority in IPR and Trademark
[4] W. Howden. A functional approach to program testing management. He is also the technical reviewer and academic
and analysis. IEEE Trans. Software Engineering, SE- council member for various professional institutions and
12(10):997-1005, October 1986. universities.
[5] L. J. White. Basic mathematical de_nitions and results
in testing. In B. Chandrasekaran and S. Radicchi,