Cleanroom Software Engineering Research Articles

Ephemeral data handling in microservices with Tquery.

The adoption of edge and fog systems, along with the introduction of privacy-preserving regulations, compel the usage of tools for expressing complex data queries in an ephemeral way. That is, queried data should not persist. Database engines partially address this need, as they provide domain-specific languages for querying data. Unfortunately, using a database in an ephemeral setting has inessential issues related to throughput bottlenecks, scalability, dependency management, and security (e.g., query injection). Moreover, databases can impose specific data structures and data formats, which can hinder the development of microservice architectures that integrate heterogeneous systems and handle semi-structured data. In this article, we present Jolie/Tquery, the first query framework designed for ephemeral data handling in microservices. Jolie/Tquery joins the benefits of a technology-agnostic, microservice-oriented programming language, Jolie, and of one of the most widely-used query languages for semi-structured data in microservices, the MongoDB aggregation framework. To make Jolie/Tquery reliable for the users, we follow a cleanroom software engineering process. First, we define Tquery, a theory for querying semi-structured data compatible with Jolie and inspired by a consistent variant of the key operators of the MongoDB aggregation framework. Then, we describe how we implemented Jolie/Tquery following Tquery and how the Jolie type system naturally captures the syntax of Tquery and helps to preserve its invariants. To both illustrate Tquery and Jolie/Tquery, we present the use case of a medical algorithm and build our way to a microservice that implements it using Jolie/Tquery. Finally, we report microbenchmarks that validate the expectation that, in the ephemeral case, using Jolie/Tquery outperforms using an external database (MongoDB, specifically).

Using Statistical Usage Testing in Conjunction with Other Black Box Testing Techniques

Cleanroom methodology is a scrupulous incremental software development approach16 for the development of zero defect and high-reliability software using box structure specification, statistical quality control and certification.2 Statistical Usage Testing (SUT) technique is the testing technique defined it Cleanroom software engineering. It based on developing the usage models and then performing statistical tests on the usage models.15 The paper shows the usage of SUT in conjunction with other black box testing techniques. Other types of testing can be performed along with SUT depending on the requirement. Use of other testing techniques can be essential to show specific scenarios of use or to attain full usage model coverage with reduced test cases.17 The paper also presents the effectiveness of applying SUT in conjunction with other black box testing techniques by using various test cases. Other black box testing techniques used include Equivalence Class Partitioning (ECP), Boundary Value Analysis (BVA), Cause Effect Graphing (CEG), Use Case Testing (UCT) and Orthogonal Array Testing (OATS).

Improving Quality of Perception (QoP), Quality of Experience (QoE), and Quality of Service (QoS) in agile development using Cleanroom Software Engineering (CSE)

Pioneering ideas from the software engineering discipline have factually affected every sphere of life. Agile software development approach has been promoted since its commencement and stipulates strategies that improve the quality of software product. To consummate fast and reliable development processes, several agile approaches are charted and are quite popular. For quality improvement and to achieve defect free system, the concept of Cleanroom Software Engineering (CSE) is ingrained into agile development life cycle. For embedding users concerns, it is important to distinguish three approaches to quality: Quality of Service (QoS), User-perceived QoP, and Quality of Experience (QoE). QoS is technology centered approach, so by using Incremental Planning of CSE, it shall facilitate the customer's clarification of system requirements and will control the technical complexity. Usage Specification and Usage Modelling will be used during the Certification phase of CSE which will help to achieve QoP and QoE, being user centered approaches. Results collected from Survey conducted, explains above mentioned factors improvement.

Testing Apache OpenOffice Writer using statistical usage testing technique

Statistical usage testing (SUT) technique is the testing technique defined it cleanroom software engineering. It based on developing the usage models and then performing statistical tests on the usage models (Runeson and Wohlin, IEEE Trans Softw Eng 20:494–499, 1994). The failure data from testing is then used in a software reliability model to certify the reliability of the software. The main purpose of SUT is to test a software product from a user’s point of view. Hence, usage models are designed and then test cases are developed from the models (Prowell et al., Cleanroom software engineering technology and process, 1999). The paper tests Apache OpenOffice Writer using SUT Technique. The paper makes use of two software RAM Commander and ITEM toolkit for testing. In this paper, Markov chains are used to represent the usage models. The development of Usage Markov Chain, the Testing Markov Chain and incorporation of failure data is done using the same software. The paper also discusses the analytical results of applying SUT and its impact on software reliability.

A Novel Approach for Cleanroom Software Testing

The Cleanroom method of Software Engineering ensures high-quality software with certified reliability, which is an important aspect of every software product. The certification process needs a reasonable statistical user testing strategy to measure the software reliability. We propose a mechanism to reduce testing time as well as effort while performing statistical user testing so that software quality is not diluted as well as maintaining a high degree of software reliability. We also cover a brief history of cleanroom software engineering approach.

An Enhancement to Cleanroom Software Engineering using csUnit Tool

Clean-room software engineering is a technical and managerial process for the development of high-quality software for zero defects with certified reliability, which combines the correctness, verifications and statistical usage testing to certify the software fitness. This paper describes the clean-room software engineering along with its technology, processes, tools support and its comparison with other traditional approaches, advantages and disadvantages. In this paper is presenting the detail description of Clean-room Software Engineering and Object Oriented Technology and also the experimental study of collaborative engineering and mutation testing performed through csUnit tool integrated with Visual studio 2008, which have been introduced to enhanced or improved Clean-room Software Engineering..

The Verification and Validation of Embedded Systems Using Cleanroom Software Engineering

This paper have been removed due to plagiarism. The original appeared in Advance Computing Conference (IACC), 2010, “A Formal Framework for verification and validation of external behavioral models of Embedded Systems represented through Black Box Structures”, issue Date: 19-20 Feb. 2010, page(s): 430 – 435 http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5422902

Teaching cleanroom software engineering with object-oriented data abstraction

This paper describes the benefit of incorporating two ideas from Design-by-Contract [3] into the teaching of Cleanroom Software Engineering [4][5], namely the specification of method behavior in terms of inspector methods, and inheritance of method specifications. The inspectors serve as a specification of the transformation between the abstract data type represented by a class and its internal data representation. By inheriting method specifications, the behavior of augmented polymorphic methods can be specified. Pedagogical examples and student code are presented and discussed.

Quality, cleanroom and formal methods

We have proposed a new approach to software quality combining cleanroom methodologies and formal methods. Cleanroom emphasizes defect prevention rather than defect removal. Formal methods use mathematical and logical formalizations to find defects early in the software development lifecycle. These two methods have been used separately to improve software quality since the 1980's. The combination of the two methods may provide further quality improvements through reduced software defects. This result, in turn, may reduce development costs, improve time to market, and increase overall product excellence.Defects in computer software are costly. Their detection is usually postponed to the test phase, and their removal is also a very time consuming and expensive task. Cleanroom software engineering is a methodology which relies on preventing the defects, rather than removing them. It is based on incremental development and it emphasizes the development phase. An enhancement to this methodology is presented in this paper, which combines formal methods and cleanroom. The efficiency of the new model rests on an appropriate logical representation, to write the specification of the intended system. In the new model, design plans are formally verified before any implementation is done. The advantages of finding defects in the early stages are decreased cost and increased quality. Results show that, by using formal methods, a higher quality will be achieved and the software project can also benefit from the existing mechanized tools of these two techniques.

Combining the Box Structure Development Method and CSP for Software Development

In this paper, we combine the Box Structure Development Method (BSDM) [H.D. Mills, R.C. Linger, and A.R. Hevner. Principles of Information Systems Analysis and Design. Academic Press, 1986, S.J. Prowell, C.J. Trammell, R.C. Linger, and J.H. Poore. Cleanroom Software Engineering - Technology and Process. Addison-Wesley, 1998] and CSP [C.A.R. Hoare. Communicating Sequential Processes. Prentice Hall, 1985, A.W. Roscoe. The Theory and Practice of Concurrency. Prentice Hall, 1998], integrating them into industrial software development processes. BSDM was developed with practical software projects in mind and provides a framework for developing formal design specifications that are fully traceable to the informal requirements. It integrates well into an industrial setting and forms an ideal bridge between the actual system being developed and the abstract models used for formal analysis. CSP complements BSDM by providing the mathematical framework for formal verification, together with its model checker FDR. In this paper, we present generic algorithms for translating specifications from BSDM into CSP, illustrate how they can be formally verified using FDR and summarise an industrial case-study.

Cutting errors in software design

The software industry has entered a new era. Software defects are still costing the economy billions. The experts' skill lies in the creation of the formal model. Their skill is unlikely to extend into the knowledge required from various domain experts. How do the domain experts and formal-methods experts communicate with one another to provide critical input into the abstract model and the actual system? We have encountered this problem repeatedly when bringing in a formal methods expert to analyse a complex component. A design approach called analytical software design (ASD) tries to address these barriers by combining some elements of the Cleanroom Software Engineering technique pioneered by IBM Federal Systems with the framework based on communicating sequential processes (CSP). Experience has shown that applying ASD results in software with very low defect levels entering integration and system testing.

Formal methods software engineering for the CARA system

This paper discusses the application of formal methods software engineering (FMSE) to the development of the Computer Automated Resuscitation A (CARA) medical device at Walter Reed Army Institute of Research. Because this system is potentially life critical, a high level of quality was required. A formal engineering approach to the software development activities was chosen to satisfy this need. Specifically, a technique called sequence enumeration was applied to elicit and refine requirements while deriving a formal specification. The fundamentals of the specification process that was used on the project are described along with a brief summary of the project experience in the development and testing phases. The project employed recent advances in Cleanroom software engineering methods along with older box-structured development and usage-model-based statistical testing techniques.

Tailoring Cleanroom for industrial use

In a pilot process improvement program to move from CMM level 3 to level 5, a Raytheon group working on real-time embedded software decided to focus on Cleanroom software engineering technology. The article shares the group's encouraging lessons learned from tailoring Cleanroom to their specific needs. The author provides evidence to support their claims of success, but cautions readers who want to employ the same approach to their own organizations because concerns, issues, and barriers do exist.

Experience using cleanroom software engineering

The US Department of Defense spends the largest portion of its software budget on reengineering and maintenance. The project profiled in this article, the US Army's first attempt to improve these processes using cleanroom methods, resulted in greater productivity, improved job satisfaction, and a high return on investment.

The incremental development process in Cleanroom software engineering

The objective of this paper is to present the theoretical basis and practical application of incremental development in the Cleanroom software engineering process. Incremental development is based on the mathematical principle of referential transparency. Cleanroom uses incremental development to build systems in a succession of cumulative subsets of user function. The increments accumulate top-down into the final product in a development and certification pipeline. Increment planning occurs after top-level specification, and results in a construction plan for the software. Factors determining the composition of increments include clarity of requirements, usage probability of user functions, reliability requirements for subsystems, coordination with the hardware development schedule, dependencies between functions, complexity, reuse, or other factors that pose risks to the project. Each increment involves a complete development and certification cycle. The first increment is a minimal system, and the final increment is the complete system. User feedback on each increment is a gauge on whether the right system is being built, and quality measures in each increment are a gauge on whether the system is being built right. Benefits of incremental development include customer feedback on the evolving system, intellectual control of the technical work, and management control of the schedule and budget. While incremental development may be used with other development methods, it is particularly effective when used with the formal methods in the Cleanroom process.

Cleanroom software engineering-plan your work and work your plan in small increments

In the semiconductor industry, silicon chips are built in contaminant-free environments called cleanrooms. This helps prevent the injection of defects during the production process. Similarly, defect prevention is the primary concern of software-developers using cleanroom software engineering. The motivation is the same in both cases: defect prevention is much less expensive than defect removal. The traditional software development pattern relies heavily on testing and debugging after development to find and repair errors. With cleanroom, the goal is to construct software with no defects during development. Given high quality code, testers on a cleanroom project can focus on determining the reliability of the code. They can then improve it, if necessary, rather than spend time finding and fixing an indeterminate number of defects keeping fingers crossed that reliability will be satisfactory in production. These may sound like unattainable goals, however, numerous cleanroom teams have used cleanroom successfully. They have built a total of nearly two million lines of extremely high quality software during the past decade, while maintaining high productivity rates. Cleanroom software engineering is a managerial and technical process for developing ultra-high quality software with certified reliability. Cleanroom provides a complete disciplined structure within which software development teams can plan, specify, design, verify, code, test, and certify software.

Cleanroom process model

Cleanroom software engineering is a team-oriented process that makes development more manageable and predictable because it is done under statistical quality control. The philosophy behind cleanroom software engineering is to avoid dependence on costly defect-removal processes by writing code increments right the first time and verifying their correctness before testing. Its process model incorporates the statistical quality certification of code increments as they accumulate into a system. >

Adopting Cleanroom software engineering with a phased approach

Cleanroom software engineering is a theory-based, team-oriented engineering process for developing very high quality software under statistical quality control. The Cleanroom process combines formal methods of object-based box structure specification and design, function-theoretic correctness verification, and statistical usage testing for reliability certification to produce software approaching zero defects. Management of the Cleanroom process is based on a life cycle of development and certification of a pipeline of user-function increments that accumulate into the final product. Teams in IBM and other organizations that use the process are achieving remarkable quality results with high productivity. A phased implementation of the Cleanroom process enables quality and productivity improvements with an increased control of change. An introductory implementation involves the application of Cleanroom principles without the full formality of the process; full implementation involves the comprehensive use of formal Cleanroom methods; and advanced implementation optimizes the process through additional formal methods, reuse, and continual improvement. The AOEXPERT/MVS™ project, the largest IBM Cleanroom effort to date, successfully applied an introductory level of implementation. This paper presents both the implementation strategy and the project results.

A design language and the use of cleanroom methodology for knowledge-based system development

In an effort to improve the quality of knowledge-based systems, use of the Cleanroom Software Engineering Methodology was explored. the methodology emphasizes the use of stepwise refinement techniques and proofs of correctness to prevent errors early in the development process. This calls for the use of a well-defined design language and verification techniques to prove the correctness of the design. But practical design languages and verification methods for knowledge-based systems are not well understood. This article discusses a design language, associated verification techniques, and experience with their use in developing a knowledge-based system. the language is an extension of procedural design languages with representations for control and opportunistic knowledge, emphasizing typical knowledge-based programming ideas and ease of verification. It is intended for use with a stepwise refinement process that iteratively develops detailed designs from high-level specifications. the extensive use of structured English language specifications throughout the process makes the approach practical but limits the ability to verify designs using automated tools. the design language and associated processes were used in the development of a prototype flight replanner for future air traffic control systems—a large and complex application of knowledge-based technology. © 1994 John Wiley & Sons, Inc.

The automated production control documentation system

A prototype software system was developed for the U.S. Naval Underwater Systems Center(NUSC) as a demonstration of the Cleanroom Software Engineering methodology. The Cleanroom method is a team approach to the incremental development of software under statistical quality control. Cleanroom's formal methods of Box Structure specification and design, functional verification, and statistical testing were used by a four-person team to develop the Automated Production Control Documentation(APCODOC) system, a relational database application. As is typical in Cleanroom developments, correctness of design and code were ensured through team reviews. Eighteen errors were found during functional verification of the design, and nineteen errors were found during walkthrough of the 1820 lines of FOXBASE code. The software was not executed by developers prior to independent testing (i.e., there was no debugging). There were no errors in compilation, no failures during statistical certification testing, and the software was certified at the target levels of reliability and confidence. Team members attribute the ultimate error-free compilation and failure-free execution of the software to the rigor of the methodology and the intellectual control afforded by the team approach.