Diversity in the software development process

Hilford, V.; Lyu, Michael R.; Čukić, Bojan; Jamoussi, A.; Bastani, Farokh B.

doi:10.1109/words.1997.609943

Cited by 6 publications

(3 citation statements)

References 15 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…A summary of results and discussion for supporting the SOA architect on choosing fault tolerance techniques is presented in the following. A detailed discussion in the context of a literature review of existing solutions is presented in Section 4.2. www.jserd.com/content/2/1/13 Review the adjudicator and availability of variants Firstly, it is essential to check the availability of variants that are sufficiently diverse in order to decrease the probability of occurrence of coincident failures (Eckhardt et al 1991;Hilford et al 1997;Knight and Leveson 1986;Lyu et al 1994;Nascimento et al 2012a). Regarding the judgement on the result acceptability, the adjudicator would run its decision-making algorithm on the results and determine which one (if any) to output as the presumably correct result.…”

Section: Review the Feasibility And Refine The Specificationmentioning

confidence: 99%

Designing fault-tolerant SOA based on design diversity

Nascimento

Rubira

Burrows

et al. 2014

J Softw Eng Res Dev

View full text Add to dashboard Cite

Background: Over recent years, software developers have been evaluating the benefits of both Service-Oriented Architecture (SOA) and software fault tolerance techniques based on design diversity. This is achieved by creating fault-tolerant composite services that leverage functionally-equivalent services. Three major design issues need to be considered while building software fault-tolerant architectures based on design diversity: (i) selection of variants; (ii) selection of an adjudication algorithm to choose one of the results; and (iii) execution of variants. In addition, applications based on SOA need to function effectively in a dynamic environment where it is necessary to postpone decisions until runtime. In this scenario, control is highly distributed and involves conflicting user requirements. We aim to support the software architect in the design of fault-tolerant compositions. Methods: Leveraging a taxonomy for fault-tolerant systems, this paper proposes guidelines to aid software architects in making key design decisions. The taxonomy is used as the basis for defining a set of guidelines to support the architect in making decisions related to fault tolerance in SOA. The same taxonomy is used in a systematic literature review of solutions for fault-tolerant composite services. The review investigates how existing approaches for fault-tolerant composite services address design diversity issues and also specific issues related to SOA. Results: The contribution of this work is twofold: (i) a set of guidelines for supporting the design of fault-tolerant SOA, based on a taxonomy for fault tolerance techniques; and (ii) a systematic literature review of existing solutions for designing fault-tolerant compositions using design diversity. Conclusion: Although existing solutions have made significant contributions to the development of fault-tolerant SOAs, there is a lack of approaches for fault-tolerant service composition that support strategies with diverse quality requirements and encompassing sophisticated context-aware capabilities. This paper discusses which design issues have been addressed by existing diversity-based approaches for fault-tolerant composite services. Finally, practical issues and difficulties are summarized and directions for future work are suggested.

show abstract

Section: Review the Feasibility And Refine The Specificationmentioning

confidence: 99%

Designing fault-tolerant SOA based on design diversity

Nascimento

Rubira

Burrows

et al. 2014

J Softw Eng Res Dev

View full text Add to dashboard Cite

show abstract

“…Examples include replication and voting [Cristian, 1991], design diversity [Hilford et al, 1997] and program self-checking methods (e.g. [Harman and Danicic, 1995]).…”

Section: Introductionmentioning

confidence: 99%

Autonomous recovery from hostile code insertion using distributed reflection

Kennedy

Sloman

2003

Cognitive Systems Research

View full text Add to dashboard Cite

In a hostile environment, an autonomous cognitive system requires a reflective capability to detect problems in its own operation and recover from them without external intervention. We present an architecture in which reflection is distributed so that components mutually observe and protect each other, and where the system has a distributed model of all its components, including those concerned with the reflection itself. Some reflective (or "meta-level") components enable the system to monitor its execution traces and detect anomalies by comparing them with a model of normal activity. Other components monitor "quality" of performance in the application domain. Implementation in a simple virtual world shows that the system can recover from certain kinds of hostile code attacks that cause it to make wrong decisions in its application domain, even if some of its self-monitoring components are also disabled.

show abstract

“…In N-version programming, which is commonly used to produce fault tolerant software for critical computing systems, independent programming teams, often from independent companies, produce software from the same set of requirements [1,8]. The software produced by each programming team is used as one of the redundant components.…”

Section: Introductionmentioning

confidence: 99%

Orthogonal Evolution of Teams: A Class of Algorithms for Evolving Teams with Inversely Correlated Errors

Soule

Komireddy

Genetic Programming Theory and Practice IV

View full text Add to dashboard Cite

Summary. Several general evolutionary approaches have proven quite successful at evolving teams (or ensembles) consisting of cooperating team members. However, in this paper we demonstrate that the existing approaches have subtle, but significant, weaknesses. We then present a novel class of evolutionary algorithms (orthogonal evolution of teams (OET)) for evolving teams that overcomes these weaknesses. Specifically it is shown that a typical algorithm from the OET class of algorithms successfully generates team members that have fitnesses comparable to those evolved independently and that have inversely correlated errors, which maximizes the teams' overall performance. Finally it is shown that the OET approach performs significantly better than the standard evolutionary approaches.

show abstract

Diversity in the software development process

Cited by 6 publications

References 15 publications

Designing fault-tolerant SOA based on design diversity

Designing fault-tolerant SOA based on design diversity

Autonomous recovery from hostile code insertion using distributed reflection

Orthogonal Evolution of Teams: A Class of Algorithms for Evolving Teams with Inversely Correlated Errors

Contact Info

Product

Resources

About