Third National Conference on Next Generation Computing & Information Systems, NGCIS 2010,

December 18-19, 2010

Optimization of Software Reliability: Object Oriented Design and
Coding Approach
*Dr. G.N Purohit, Emeritus Professor, Dept. Of Mathematics, Banasthali University, Banasthali(Raj)

**Dr. Arun Mohan Sherry, Professor & Director (IMT-CDL), Institute of Management Technology Ghaziabad (U.P)

***Manish Saraswat, Asst. Prof. Geetanjali Institute of Technical Studies GITS, Udaipur, (Raj). Email: saraswat24@yahoo.com

Abstract

This paper includes some of the concepts of software reliability and software development process. A survey of employees of
software development companies was conducted to assess the reliability of large –scale program and findings of the same is
included in this paper. The findings of survey point out that one of the largest origins of software problems lies in communication
deficiencies. The quality of the development process ultimately determines the quality of the delivered software product. The
primary causes of customer problems often stem from difficulties in capturing true customer requirements. An additional
challenge is assuring strong integrated product team understanding and communications. This paper identifies structured
development process initiatives that assure the building of more reliable code. Then two of the more significant initiatives, object-
Oriented design and the defect prevention process, are discussed in length in this paper.

Key words: Software Reliability, Process, Defect Prevention Process, Object Oriented Design, and Tools.

1. Introduction • Sometimes lacked agreement on interpretation of

requirements e.g., as to what constituted adequate
The term software reliability can be defined as “Probability of failure verification of requirements. (4 comments on differing
free operation of software during specified period and in controlled interpretation of requirements)
environment”. The main focus of software reliability is often thought
to be the coding; whereas, in reality, coding is actually a minor • Proposal team lacked sufficient understanding of the
contributor to the reliability of the end product. A recent paper problem domain. (3 not understanding the customer’s
equates the coding to be like the paint applied to some structure [1]. problem domain)
The real integrity of the design is underlying the code. The code
reliability is truly a function of the development process. Software 3. Recommendations for Software Reliability
reliability has to be designed into the product. This is mainly
accomplished by good requirements analysis, planning, robust There are a set of design and assurance initiatives that can prevent
architecture, contingency analyses, design protocols, structured the problems which were reported above. These can be summarized
development process, and problem management. Software can also as
be refined by good test practices which entails testing the software in
a mode that simulates customer usage [2]. Problems are uncovered Development Approach Total At Delivery
and fixed. The code then Improves as each bug is removed. The
greater opportunity to develop reliable code still lies in the early • Traditional Approach 50-60 15-18
development process. A good program start is to learn from past • Bottom up Approach
programs and particularly attempt to avoid repeating the problems. • Unstructured code Design
This is best done by looking at the predecessor product’s problems. • Removal Through Testing
MODERN PRACTICE 2-4
2. Literature Survey and Data Analysis • Top down design 20-40

The following data was taken from a development effort that • Structured code
produced over 1/2 million lines of code before it was terminated after • Design/code inspections
five years of development. This prolonging of the development effort
Space Shuttle Code 6-12 0.1
intensified the problems. A survey of the program staff yielded many
FUTURE IMPROVEMENTS 0-20 0-1
comments. These comments were analyzed and categorized. The
categorized comments are shown below for those dealing with • Advanced software engineering
program requirement difficulties which accounted for 45 out of 156
total program comments.
• Verification practice

• Needed an operational concept, an agreed to architecture

and better understanding of the problem domain. (13
comments on front end planning)
• Too much requirements thrashing. We would spend
months on one design came implementing requirements
that were later dropped. (1 1 comments on requirements
changes)
• Some requirements were vague, ill defined, lost
traceability and unattainable. (8 poor requirements)
• Reliability measurement
Figure: 1 Code defect rate (defects/Lsloc) as a function of design
approach
3.1 Implement Good Requirement Concept
(a) If possible use a working model, because it provides the best
example of the realization of requirements.
(b) Provide customer experience with the design solution which may

Department of Computer Science & Engineering, CSE, MIET, Jammu, Jammu & Kashmir
 Third National Conference on Next Generation Computing & Information Systems, NGCIS 2010,
December 18-19, 2010
lead incremental growth capabilities in the organization.
(c) Promote deeper understanding habits in the requirement analysis
team of the s/w development company.
(d) Improve knowledge gathering skill of s/w development team by
giving proper training.
3.2 Enhance Design Approach
(a) Use Object Oriented Design: Promote the use of proven
building blocks and simplicity of program
implementation.
(b) Use high level language to enhance simplicity in program
coding.
(c) Use better design to minimize errors in software and
improve s/w reliability.
(d) Incorporate structured development technique and
provable design verification
(e) Reuse codes which may result in less errors and minimize
time and space complexity of s/w.
3.3 Selection of Process
(a) Cross program facilitation: cross functional teams
promote better communications and closure, and gives
design an input from the maintenance areas.
(b) Provide design specification which may result in fast
design process
(c) Use flexible design and don’t be rigid on one s/w design.
(d) Always have a contingency plan.
This paper only addresses the initiative that can be undertaken
to develop reliable codes. These initiatives are:
(a) Object Oriented Design and
(b) Defect Prevention process
4. Object Oriented Design
Object oriented Design techniques allow software to be created by
using objects with well defined behavior. An object encapsulates the
data and methods of manipulating the data that protect it from
manipulation. Classes of objects are designed so that they can be
used in other applications. The reusability feature of object oriented
design method enhances reliability and stability.
Reusability using object oriented design techniques are generally
above 80% which means less than 20% of the code is developed
from scratch. This reduces the overall fault content of a software
development project dramatically. In many cases, a 20-fold reduction
in fault content is common when reusability reaches 80%. Aside
from the cost and schedule benefits reusability has on the
development life-cycle, the drastic reduction in fault content also
reduces the maintenance costs.
Object oriented design simplifies the design of complex systems.
Programs tend to be built in smaller, more manageable modules that
are generally easier to create. A three- fold reduction in the code
complexity as measured by McCabey Cyclomatic Complexity Metric
Department of Computer Science & Engineering, CSE, MIET, Jammu, Jammu & Kashmir
[4] is common when organizations change from conventional s/w
development to object oriented development approach. This
reduction in complexity also has a corresponding reduction in fault
content. Simply reducing code complexity from above 10 to below it
typically results in a 20% decrease in fault content.
In conventional programming, the analysis of the problem at hand
uses a completely different paradigm than that used in the design
which, in turn, is different from that used in the implementation.
Analysts use functional decomposition to define the problem. These
functions are then designed using data flow diagrams which are then
implemented using the constructs of the particular programming
language. This often leads to communications break downs that are
the major source of defects. In object oriented design, the analysis,
design, and implementation use the exact same paradigm all centered
on the object.
4.1 Defect Prevention Process
Defect Prevention Process (DPP) is a process that utilizes causal
analysis to prevent defects rather than just eliminate them. Through
causal analysis, an evaluation is done to determine how an
undesirable condition (e.g. defect) occurred and how to prevent the
defect from occurring again in the fume. The causal analysis
evaluation can be performed at varying levels of formality and
structure as makes sense for the complexity of the process.
For example, a defect identified as originating in an individual’s
process would require little more than that individual (the process
owner) or a small group of team members to alter the process that led
to the defect, while a defect identified to originate from processes
that involve a cross-section of
organizations would require participation of many people from many
groups. Action teams are utilized in the latter case. Action teams are
teams comprised of representatives from all the Causal Analysis
teams that participate in the entire process.
A formal Defect Prevention Process can readily improve the code
reliability as it aims to not just eliminate defects, but to prevent
potential defects of similar cause from occurring in the future. The
benefits of a formal process increase with the complexity of the
process change being considered. Defect metrics arising from the
development process can be used by management as the basis for
informed decision making. Data typically collected and analyzed by
mature software organizations include defects found during design
and code inspections as well as test phases.
A measure of how good the software development process is can be
made through measurements of how many defects are discovered and
when they are discovered. Defect models are available that estimate
the number of project defects that are expected in later stages of
development based on the number of defects discovered in earlier
phases (defect discovery profile). Generally, process defects are not
employed in these defect models. Where defect metrics have been
measured and modeled by an organization and a historical database
has been obtained, defect discovery goals can be established as part
of the software management process, and expectations of process
improvement and availability objectives.
Third National Conference on Next Generation Computing & Information Systems, NGCIS 2010,
December 18-19, 2010
reliability modeling: An approach to early reliability
Figure: 2 Defect Discovery and Removal
prediction', IEEE Transactions on Reliability, vol. 47, no. 3,
Figure 2 shows an example of an expected defect discovery profile
for a software development project, and tolerance limits set around
the goal which could be used as a means for quality control. An pp. 268-278.
interesting measure of the quality of the software development
process is the ‘‘Leakage of Defects” from one phase of
[14] Xie, M., Hong, G.Y. & Wohlin, C. 1999, 'Software reliability
development to the next. Used in conjunction with the defect
discovery profile, a Defect Injection Profile can help manage
process improvements by quantifying the current process in terms prediction incorporating information from similar project',
of the number of defects created and the effectiveness of the defect
discovery or verification processes. If there were no leakage, the
number of errors created in a given phase of software development Journal of Systems and Software, vol. 49, no.
would be detected in that phase.
1, pp. 43-48.
5. Conclusion:
[15] Hu, Q.P., Xie, M. and Ng, S.H., 2006, ‘Software reliability
The term software reliability can be defined as “Probability of
failure free operation of software during specified period and in
controlled environment”. The findings of survey point out that one prediction improvement with prior information incorporated’,
of the largest origins of software problems lies in communication
deficiencies. The quality of the development process ultimately
in proceedings of the 12th ISSAT International Conference
determines the quality of the delivered software product. The
primary causes of customer problems often stem from difficulties
in capturing true customer requirements. An additional challenge is on Reliability and Quality in Design, 06, Chicago, USA, pp.
assuring strong integrated product team understanding and
communications. This paper identifies structured development
303-307
process initiatives that assure the building of more reliable code.

6. References: [16] Alexandre Alvaro, Eduardo Santana de Almeida, Silvio

[1] Robertson, Suzanne, “Visibility: the Key to Quality Lemos Meira, A Software Component Quality Model: A
Improvement”, lEEE Software, July 1995, pp. 95-97.
[2] Keene, S.J., Keller, Ted, Musa, John, “Developing Reliable
Preliminary Evaluation, euromicro,pp.28-37, 32nd
Software in the Shortest Cycle Time”, IEEE Educational
Activities (video tutorial), Piscataway, New Jersey, 1995.
[3] Keene, S.J., “Using Design of Experiments to Develop Better EUROMICRO Conference on Software Engineering and
Products”, Reliability Review, Vol. 13, No. 2, June 1993pp12-
18.
[4] King, Bob, “Better Designs in Half the Time”, GOAL/QPC Advanced Applications (EUROMICRO'06), 2006.
Publisher, 13 Branch Street, Methuen, MA 01844, 1989.
[5] Mays et al, “Experiences with Defect Prevention”, IBM [17] Ganesh J. Pai, Joanne Bechta Dugan, Empirical Analysis of
Systems Journal, Vol. 29, No.1, 1990, pp. 4-31.
[6] Deck, Michael, “Clean Room Software Engineering: Quality
Improvement and Cost Reduction”, presented at the Software Software Fault Content and Fault Proneness Using Bayesian
Quality Conference, Portland, OR, Oct.
[7] Mc Cabe, T.J., “A Complexity Measure”, IEEE Software Methods, IEEE Transactions on Software Engineering, vol.
Engineering SE-2, 1976, pp. 308-320.
[8] Chruscicki, A.J., and Gaffney, J.E.,Jr., 1995. “Toward a
Quality Inspection Method and Management”. Paper presented 33, no. 10, pp. 675-686, Jul., 2007.
at 2nd IEEE International Symposium and Forum on Software
Engineering Standards (ISESS95). [18] R. Moraes, J. Duraes, R. Barbosa, E. Martins, H. Madeira,
[9] Guo, P. & Lyu, M.R., 2004, 'A pseudoinverse learning
algorithm for feedforward neural networks with stacked
generalization applications to Experimental Risk Assessment and Comparison Using
software reliability growth data,' Neurocomputing, vol. 56,
pp. 101-121. Software Fault Injection, 37th Annual IEEE/IFIP
[10] Tian, L. & Noore, A., 2005, 'Evolutionary neural network
modeling for software cumulative failure time prediction,'
Reliability Engineering & System Safety, vol. 87, no. 1, pp. International Conference on Dependable Systems and
45-51.
[11] Xie, M., Hu, Q.P., Wu Y.P. and Ng, S.H., ‘A study of Networks (DSN'07), 2007.
software fault detection and correction modeling’, Quality and
Reliability Engineering International, accepted.
[12] Hu, Q.P., Xie, M., Ng, S.H., & Levitin, G., Robust ‘recurrent [19] Jorgen Boegh, A New Standard for Quality Requirements,
neural network modeling for software fault detection and
correction prediction’, Reliability Engineering and System IEEE Software, vol. 25, no. pp. 57-63, Mar/Apr, 2008.
Safety, in press
[13] Smidts, C., Stutzke, M. & Stoddard, R.W. 1998, 'Software
[20] Wangbong Lee; Boo-Geum Jung; Jongmoon Baik, Early

Department of Computer Science & Engineering, CSE, MIET, Jammu, Jammu & Kashmir
Third National Conference on Next Generation Computing & Information Systems, NGCIS 2010,
December 18-19, 2010
Reliability Prediction: An Approach to Software Reliability

Assessment in Open Software Adoption Stage, Secure System

Integration & Reliability Improvement, 14-17 July 2008

SSIRI, Page:226–227.
[21] Shibata, K.; Rinsaka, K.; Dohi, T.;PISRAT: Proportional

Intensity-Based Software Reliability Assessment Tool,

Dependable Computing, 2007. PRDC.

Department of Computer Science & Engineering, CSE, MIET, Jammu, Jammu & Kashmir