An Industrial Standard to Assure Dependability in Software Reuse

Fevzi Belli

Faculty of Computer Science, Electrical Engineering and Mathematics

University of Paderborn, Paderborn, Germany

Keywords: Software Reuse, Dependability, Test, Industrial Standardization.

Abstract: Whereas a software component may be perfectly suited to one application, it may prove to cause severe

faults in other applications. The pre-standard IEC/PAS 62814 (Dependability of Software Products Con-

taining Reusable Components – Guidance for Functionality and Tests), which has recently been released,

addresses the functionality, testing, and dependability of software components to be reused and products

that contain software to be used in more than one application. This paper introduces into this pre-standard

and give hints how to use it. The author, who chaired its realization that started in 2006, briefly summarizes

the difficult process to bring the industrial partners with controversial interests to a consensus.

1 INTRODUCTION

Software reuse is the process of creating software

systems from existing software rather than building

software systems from scratch. The vision of soft-

ware reuse is as old as software itself – it was intro-

duced already in 1968, in the year as the term

“Software Engineering” was coined during the con-

stitutional NATO conference in Germany (Naur and

Randell, 1968).

Many efforts to reuse software have succeeded;

there is an increasingly overwhelming number of

success stories available in literature. Almost all

major companies and institutions that deal with

information & communication technology practice

software reuse and report about their success, e.g.,

Nippon Electronic Company, GTE Corporation,

Raytheon, DEC, HP, NASA, and many more

(Mathur, 2008); (Mohagheghi, 2008); (Orrego and

Mundy, 2007).

Nevertheless, the promises of decreased cost and

increased dependability, and thus decreased risks,

are not always realized. The frightening news about

recent disasters definitely caused by careless soft-

ware reuse are still being warningly associated with

and attributed to all software reuse. The failure of

Therac-25 system, in which a software component

was carried over from a previous version of an X-ray

system, caused the machine to malfunction, resulting

in the loss of several lives in a terrible way; patients

were actually burned (Leveson, 1995).

In the Ariane project, failure of a reused software

component caused the loss of a rocket costing

around half a billion dollars (Lions, 1996).

These recent disasters as a consequence of bad

reuse on the one side and success stories as a conse-

quence of good reuse on the other side are the key

factors in deciding whether or not to enhance and

sustain continued provision of reuse from a lucrative

business perspective.

To sum up, before reusing a software compo-

nent, the context and domain it was built for should

be carefully compared with the context and domain

it is intended to be built in, including the hardware

and physical and organizational aspects (Mohammad

and Alagar, 2010). Figure 1 depicts the elements of

the reuse process which is the subject of this paper.

Standardization is the most efficient means to

bring research, industrial, commercial, and con-

suming parties with different roles, but participating

on the same objects and ethic objectives, e.g., to

protect environment, to save resources, etc. Stand-

ardization helps with understanding and unifying the

quality notion, also for reusing previously used

products. Standardization helps also prevent legal

problems that arise because reuse will be already

practiced tentatively and insecurely.

This paper is on standardization of software re-

use concerning its quality, test criteria etc., depend-

ing on the purpose of the software that will be re-

used.

The publicly available specification (PAS)

Belli F..

An Industrial Standard to Assure Dependability in Software Reuse.

DOI: 10.5220/0004510600580063

In Proceedings of the 8th International Joint Conference on Software Technologies (ICSOFT-EA-2013), pages 58-63

ISBN: 978-989-8565-68-6

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

IEC/PAS 62814 / Ed. 1: Dependability of Software

Products Containing Reusable Components – Guid-

ance for Functionality and Tests is a pre-standard

and addresses the functionality, testing, and

dependability of software components to be reused

and products that contain software to be used in

more than one application; that is, reused by the

same or by another development organization, re-

gardless of whether it belongs to the same or another

legal entity than the one that has developed this

software. IEC is the acronym of “International Elec-

trotechnical Commission” that is the world’s leading

organization that prepares and publishes Interna-

tional Standards for all electrical, electronic and

related technologies.

The present paper gives an introduction into the

PAS, which has been released in December 2012.

The author chaired its realization that started in 2006

62814, and will give hint how to use it.

Next section clarifies terminology and discusses

notions used in the practice. Section 3 introduces

one of the most notable aspects of the PAS, that is,

Reusability- & Dependability-Driven Software De-

velopment Technique. Recommended methods of

validation, re-validation, and reliability of software

reuse are summarizes in Section 4. Section 5

sketches the structure of the PAS, and explains and

discusses its scope, objectives, and usage. Conclud-

ing remarks and future work are included in Section

Figure 1: Elements of the reuse process.

2 NOTIONS AND PRACTICES

OF REUSE

Not each “copy and paste” action, which program-

mers do daily when they construct their programs,

forms a software reuse that PAS 62814 has in mind.

Also calling an internal or external function and

even a remote-procedure call is not necessarily a

reuse this PAS would regulate. All these examples

suggest that the context and domain of the called

software does not change. Therefore, there is no

need for them to consider this PAS and, for example,

perform pre-store and pre-use activities that are

described in PAS 62814 in detail.

2.1 What Reuse Really Is

Using a service in a service-oriented (SO) landscape

or in “Common Object Request Broker Architecture

(CORBA)” is of more interest to this PAS because

the context and domain of the software that delivers

a service might change. Indeed, SO and CORBA are

typical reuse constellations concerning constructing,

offering, selecting, and validating services repeat-

edly. A service has to be registered and “published”

before it will be offered. Infrastructural services are

offered to realize a broker, etc. (Belli and Linschulte,

2010).

2.2 Where Reuse Will Be Practiced

Examples given above clarify that software reuse is

not limited to the source or object code; it has,

moreover, to consider all of the information that is

related to the product generating processes, includ-

ing also requirements, analysis, design, documents,

and test cases apart from the code. Examples of

well-known, widely accepted practices of software

reuse are (Sommerville, 2007):

 Component-based development (CBD): Building

systems by integrating components that conform to

system’s specification.

 COTS integration: CBD using commercial compo-

nents.

 Service-oriented systems: Building systems by

linking shared services.

 Program generators: Embedding knowledge of a

particular type of application to produce compo-

nent(s) in that domain.

 Application product lines: Generalization of an

application around a common architecture so that

it can be used to produce different applications in

different domains for different customers.

AnIndustrialStandardtoAssureDependabilityinSoftwareReuse

 Object-oriented programming: Implementing

applications using "objects" that consist of data

structures, methods (algorithms) and their interac-

tions and computer programs.

 Aspect-oriented software development: Weaving

shared components into an application at different

places when the program is compiled, if separation

of concerns is feasible.

2.3 Software Reuse Has Many Faces

There is a great variety of reusing software, from ad-

hoc, unplanned to systematic. Following list at-

tempts to structure this variety.

1) Accidental (ad hoc or opportunistic) reuse de-

notes reuse without strategy, typically reusing

software components not designed for reuse.

2) Systematic (planned) reuse requires developing

software components intended for reuse and/or

building new applications from those reusable

components, following a formal plan of product

line.

3) Adaptive reuse uses previously developed

software that is modified only for portability,

e.g., a new application on a different operating

system.

4) Black-box reuse uses unmodified software

components, incorporating existing software

components into a new application without

modification.

5) White-box reuse modifies and integrates software

(function) blocks into new applications.

6) Vertical reuse uses components in the same

domain.

7) Horizontal reuse uses components in different

domains.

8) Internal (in-house) reuse uses components

developed within the company, or government

unit.

9) External reuse uses components of another

company, or government unit.

2.4 Software Reuse Has Also Many

Facets

The above discussion has identified practical and

relevant kinds of reuse. A general taxonomy of

software reuse is included in Table 1, which uses the

following six aspects for a thorough, exemplary

classification (Frakes and Terry, 1996), (Frakes and

Kang, 2005). Numbers in parentheses refer to the

numbering used in the listing in Section 2.3.

 Reuse assets and entities can be product-oriented

and, thus, concrete, such as components; they can

also be ideal, such as concepts, ideas, algorithms,

etc.

 Domain scope refers to application area (6 and 7).

 Development scope refers to origin of the compo-

nent (8 and 9).

 Additional work required prior to reuse is referred

to by modification (3, 4, and 5).

 Whether and which kind of work is to be done in

performing reuse is a managerial aspect (1 and 2).

 Reuse approach is compositional if existing

components are reused (such as the Unix

shell);

generative reuse requires application or code

generators (such as Refine and Meta tool).

 Direct reuse approach requires no "glue code" that

intermediates between the reusable component and

the receiving system, indirect reuse necessitates an

intermediate entity.

Note that Table 1 shows the summary of the

classification. It is possible to add further issues, for

Table 1: Summary of reuse classification.

Reuse Asset Reuse Entity

Domain

Scope

Development

Scope

Modification Management Approach

Ideas, concepts Architectures Vertical Internal

Adaptive

Accidental Compositional

Artefacts, com-

ponents

Requirements Horizontal External Black Box Systematic Generative

Procedures, skills Designs White Box Indirect

Specifications Direct

Source Code

Object Code

Test Cases

ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies

example, the issue of “Information to Reuse.” It

means that reused-based software development can

be required for the complete specification of the

reusable component.

3 SOFTWARE DEVELOPMENT

DRIVEN BY REUSABILITY

& DEPENDABILITY ASPECTS

Architecture is the key to software reuse. The ar-

chitecture of a system commits its structure to com-

bine the elements it is comprised of and their fea-

tures, and relations among those elements.

Typical structures are hierarchical, centralized

(star-form), or decentralized (network-form);

relations are defined as consists-of or neighboured.

Architectural elements can be event, state, or

service-oriented.

It is important for reuse that the software

architecture should allow a precise design and

specification of interfaces and their dependability-

critical features so that it enables evaluation,

selection, acquisition, and integration of reusable

components into the receiving system.

While planning substantial reuse of their soft-

ware components, software engineers are often

overly optimistic concerning how much reusable

functionality can be achieved. Reuse is not a ulti-

mate saver of costs, schedule, or dependability. Even

COTS deployment often satisfies only less than

40 % of the functionality of an industrial application.

Also important is the addressing of the critical

non-functional requirements, that is, dependability

and quality, which certainly result in schedule and

cost impacts, and, caused by poor dependability and

reliability, maybe invoke severe safety and security

risks.

Note that if the functional and interface re-

quirements are not fulfilled, glue code and wrappers

are to be planned, specified, designed, implemented,

and carefully tested.

Dependability methodologies include application

aspects and the organization of the reuse. Pre-store

and pre-use characteristics should be met and the

cases build-for reuse or build-by-reuse should be

distinguished.

Another point covers validation and reliability

aspects of the software. Also the assumptions and

rules to improve software dependability are de-

scribed and the hardware/software interaction is

taken into account.

“Software-by-reuse” is the use of existing appli-

cations or their components to build new applica-

tions.

It is widely accepted and convenient to consider

software reusability from the following viewpoints.

 Build-for-reuse enables planned production of

reusable components.

 Build-by-reuse attempts planned production of sys-

tems using reusable components.

Both of these viewpoints focus on characteristics

of reusability that are to be checked before storing

the component and before reusing it in a new prod-

uct.

Following recommendations do not address only

internal reuse; they can easily be adopted also for

external reuse.

4 VALIDATION,

REVALIDATION,

AND RELIABILITY

OF SOFTWARE REUSE

Software reuse involves redesign, reimplemen-

tation, and re-testing. Redesign arises if the existing

functionality does not fulfil the requirements of the

new task because it requires reworking to realize the

new function, and, prior to this, necessitates reverse

engineering to understand its current functionality.

The design change leads to reimplementation.

Exhaustive re-testing (as a kind of regression

testing) is necessary to validate the functionality of

the reused software in the new domain to determine

whether or not redesign and reimplementation are

needed.

Following undesirable events/situations, mostly

caused by managerial misjudgement, negatively

influence the dependability of software reuse:

 Failing to select the right component, or to favour

the wrong selection criteria;

 Failing to justify and adjust the need for and/or ex-

tent of the modification of the selected component

to fulfil operational or application requirements;

 Failing to justify and adjust the need for and/or ex-

tent of the maintenance of the selected component

during operational stage.

To avoid such events/situations, redesign, re-

implementation, and re-testing activities can be clus-

tered in following groups:

 Redesign

– Architectural design modification: Detection of

architectural design part(s) to be modified,

AnIndustrialStandardtoAssureDependabilityinSoftwareReuse

realization of the modification, re-validation of

the entire architectural design;

– Detailed redesign: Detection of design part(s) to

be modified, realization of the modification, re-

validation of the entire design;

– Reverse engineering: Detection of the part(s) to

be modified, which are not familiar to devel-

opers; understanding, modification, re-validation

of the entire component;

– Re-documentation: Detection of the part(s) to be

modified, modification, re-validation of the entire

document;

– Re-implementation requires re-coding, code re-

view, and unit testing (IEC 62628).

 Re-testing activities can be clustered in following

groups:

– Test re-planning

– Test procedures to be altered

– Re-integration testing

– Re-release and re-acceptance testing

– Test drivers/simulators to be altered

– Test reports to be rewritten

Fundamental facts influence dependability, espe-

cially reliability when using commercially available

components, e.g., COTS components for software

development.

 Very often no source code is available, thus there

is no way to correct a detected fault.

 This is a great restriction that prohibits application

of the most widely used reliability models that

require perfect correction of detected faults

(“reliability growth models”; see, for example,

AIAA R-013-1992, IEEE 1633-2008).

 If source code is available: Note that COTS soft-

ware is no longer COTS after its source code is

modified to correct a fault detected because the

COTS supplier no longer maintains the docu-

mentation and source code (just as electronics

equipment warranties are no longer valid after a

seal is broken).

 Furthermore, the modifications can violate the

original software design. From then on, modified

COTS software is to be handled as an accidental

reuse.

5 STRUCTURE OF IEC/PAS 62814

AND HOW TO USE IT

The international PAS 62814 introduces the concept

of assuring reused components and their usage

within new products. It provides information and

criteria about the tests and analysis required for

products containing such reused parts. The objective

is to support the engineering requirements for func-

tionality and tests of reusable software components

and composite systems containing such components

in evaluating and assuring reuse dependability

(Figure 2).

NORMATIVE PART

1 Scope

2 Normative references

3 Terms and definitions and abbreviations

4 Dependability of software reuse methodol-

ogy– reusability-driven software development

5 Software reuse dependability methodology

applications

6 Software reuse assurance

7 Warranty and documentation

INFORMATIVE PART- ANNEXES

A General remarks on software reuse

B Qualification and integration of reusable

software components

C Testing and integration of reusable software

components – Issues for industrial best prac-

tice

D Example of software pre-use

E Influence of reused software to hardware

components and products

Figure 2: Structure of IEC/PAS 62814.

Focus is on the dependability of software reuse and,

thus, this document complements IEC 62309:2005-

02 (Dependability of products containing reused

parts – requirements for functionality and test),

which exclusively considers hardware reuse. In

addition to this previous, hardware-related IEC

standard, the present PAS also crosses further, ap-

propriate software-related standards to be applied in

the development and qualification of software com-

ponents that are intended to be reused and products

that reuse existing components. In other words, this

present standard encompasses the features of soft-

ware components for reuse, their integration into the

receiving system, and related tests. Their perfor-

mance and qualification and the qualification of the

receiving system is subject to existing standards, for

example ISO/IEC 25000 and IEC 61508-3. The

process framework of ISO/IEC 12207 on systems

and software engineering and ISO/IEC 25000 on

system aspects of dependability on software engi-

neering apply to this present document.

The purpose of

IEC/PAS 62814 is to ensure

through analysis and tests that the functionality,

dependability and eco-friendliness of a new product

ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies

containing reused software components is

comparable to a product with only new components.

This would justify the manufacturer providing the

next customer with a warranty for the functionality

and dependability of a product with reused

components. As each set of hardware/software has a

unique relationship and is governed by its

operational scenario, the dependability determi-

nation has to consider the underlying operational

background. Dependability also influences safety.

Therefore, wherever it seems necessary, safety

aspects have to be considered the way IEC 60300-1

addresses safety issues. This PAS can also be

applied in producing product-specific standards by

technical committees responsible for an application

sector.

This paper could give only a brief introduction to

the major aspects of IEC/PAS 62814. Due to lack of

space nothing could be said about the informal part

that comprehensively explains the methods and

techniques for systematic reuse and its validation to

assure dependability, and includes numerous exam-

ples from the practice and for the practice.

6 CONCLUDING REMARKS,

FUTURE WORK

The most common form of reuse is using software

developed for one-use in a new application, which

is, accidental reuse. One of the major objectives of

the present PAS 62814 is to warn the managers that

this kind of unplanned reuse can be a potential

minefield because it can cause the inheritance of all

the problems of the pre-existing software in the

reaping of only a few of its benefits. Many

managers, while planning for software reuse, forget

that both the reused component and composite

system are to be tested in the new domain.

Experience reports say that reusable software can

cost 60 % more than one-use software, whereby a

good portion of additional costs goes to testing.

This paper gave a brief introduction into

IEC/PAS 62814 and which is a pre-standard, that is,

it is not yet a standard. Further work and much

energy are necessary to complete the work and

produce a standard.

REFERENCES

Belli, F., Linschulte, M., 2010. Event-Driven Modeling

and Testing of Real-Time Web Services, J. of Service

Oriented Computing and Applications, Vol. 4, No. 1,

pp. 3-15, Springer, Heidelberg.

Frakes, W.B., Terry, C., 1996. Software Reuse: Metrics

and Models, ACM Computing Surveys, Volume 28,

Issue 2, pp. 415-435, Available from http://dl.acm.org/

ft_gateway.cfm?id=234531&type=pdf&CFID=651787

75&CFTOKEN=89447410.

Frakes, W.B., Kang, K., 2005. Software Reuse research:

Status and Future, IEEE Transactions on Software

Engineering, Volume 31, Issue 7, pp. 529-536, Avail-

able from http://ieeexplore.ieee.org/stamp/stamp.jsp?

tp=&arnumber=1492369.

Leveson, N., 1995. Medical Devices: The Therac-25,

Appendix A in Safeware: System Safety and Comput-

ers, pp. 1-49, Addison-Wesley,Boston, Available from

http://citeseerx.ist.psu.edu/viewdoc/download;jsession

id=84A18B532CF53C4AEA6F64AA6038BFEF?doi=

10.1.1.39.704&rep=rep1&type=pdf.

Lions, J.L., 1996. Ariane 5 Flight 501 Failure, Available

from http://www.ima.umn.edu/~arnold/disasters/ariane

5rep.html.

Mathur, A.P., 2008. Foundations of software Testing.

Addison-Wesley Professional, Boston.

Mohagheghi, P., 2008. Ict, S., Conradi, R., An Empirical

Investigation of Software Reuse Benefits in a Large

Telecom Product, ACM Transactions on Software En-

gineering and Methodology, Volume 17, Issue 3, pp.

13:1-13:31, Available from http://dl.acm.org/

ft_gateway.cfm?id=1363104&type=pdf&CFID=82907

429& CFTOKEN=24134248.

Mohammad, M., Alagar, V., 2010. A component-based

development process for trustworthy systems, J. of

Software Maintenance and Evolution: Research and

Practice, Wiley InterScience, published online:

DOI: 10.1002/smr.472. Available from http:// online

library. wiley.com/doi/10.1002/smr.472/pdf.

Naur, P., Randell, B. (eds.), 1968. Software Engineering,

Report on a conference sponsored by the NATO Sci-

ence Committee, Garmisch, Germany, Available from

http://homepages.cs.ncl.ac.uk/brian.randell/NATO/

nato1968.PDF.

Orrego, A., Mundy, G., , 2007. SRAE: An Integrated

Framework for Aiding in the Verification and Valida-

tion of Legacy Artifacts in NASA Flight Control Sys-

tems”, Proc. 31

Ann. Intertnat’l. Comp. Softw. &

Applications Conf., IEEE Comp. Press, New York

Sommerville. I., 2007. Software engineering, Addison

Wesley Longman, Boston.

AnIndustrialStandardtoAssureDependabilityinSoftwareReuse