Learn software concepts - Cleanroom Software Engineering Cont...

The Cleanroom Software Engineering process is a software development process intended to produce software with a certifiable level of reliability. The focus of the Cleanroom process is on defect prevention, rather than defect removal. The name Cleanroom was chosen to evoke the cleanrooms used in the electronics industry to prevent the introduction of defects during the fabrication of semiconductors.

Central principles of Cleanroom Software Engineering :
- Software development based on formal methods
Cleanroom development makes use of the Box Structure Method to specify and design a software product. Verification that the design correctly implements the specification is performed through team review.
- Incremental implementation under statistical quality control
Cleanroom development uses an iterative approach, in which the product is developed in increments that gradually increase the implemented functionality. The quality of each increment is measured against pre-established standards to verify that the development process is proceeding acceptably. A failure to meet quality standards results in the cessation of testing for the current increment, and a return to the design phase.
- Statistically sound testing
Software testing in the Cleanroom process is carried out as a statistical experiment. Based on the formal specification, a representative subset of software input/output trajectories is selected and tested. This sample is then statistically analyzed to produce an estimate of the reliability of the software, and a level of confidence in that estimate.

Advantages of Cleanroom Approach :
- Proven Practice : Several major products have been developed using Cleanroom and delivered to customers.
- Low Error Rate, highly reliable code.
- Increased Productivity.
- Can Be Incorporated Within A Quality Management Program Such As CMM Or ISO 9000.

Why are Cleanroom Techniques Not Widely Used ?
- Some people believe cleanroom techniques are too theoretical, too mathematical, and too radical for use in real software development.
- Relies on correctness verification and statistical quality control rather than unit testing (a major departure from traditional software development).
- Organizations operating at the ad hoc level of the Capability Maturity Model, do not make rigorous use of the defined processes needed in all phases of the software life cycle.

Learn software concepts - Cleanroom software engineering

Cleanroom software engineering is a formal approach to software development that can lead to software that has remarkably high quality. It uses box structure specification (or formal methods) for analysis and design modeling and emphasizes correctness verification, rather than testing, as the primary mechanism for finding and removing errors. Statistical use testing is applied to develop the failure rate information necessary to certify the reliability of delivered software.

The cleanroom approach begins with analysis and design models that use a box structure representation. A "box" encapsulates the system at a specific level of abstraction. Black boxes are used to represent the externally observable behavior of a system. State boxes encapsulate state data and operations. A clear box is used to model the procedural design that is implied by the data and operations of a state box.

Correctness verification is applied once the box structure design is complete. The procedural design for a software component is partitioned into a series of sub-functions. To prove the correctness of the sub-functions, exit conditions are defined for each sub-function and a set of sub-proofs is applied. If each exit is condition is satisfied, the design must be correct.

Once correctness verification is complete, statistical use testing commences. Unlike conventional testing, cleanroom software engineering does not emphasize unit or integration testing. Rather, the software is tested by defining a set of usage scenarios, determining the probability of use for each scenario, and then defining random tests that conform to the probabilities. The error records that result are combined with sampling, component, and certification models to enable mathematical computation of projected reliability for the software component.

The cleanroom philosophy is a rigorous approach to software engineering. It is a software process model that emphasizes mathematical verification of correctness and certification of software reliability. The bottom line is extremely low failure rates that would be difficult or impossible to achieve using less formal methods.

Learn software concepts - Software Components

Components are the software units that are context independent, both in the conceptual and the technical domain. A component contain a self-contained entity that exports functionality to its environment and also imports functionality from its environment using well defined and open interfaces. Components may support their integration into the surrounding by providing mechanics such as configuration functionality.

Software components can also be characterized based on their use in the CBSE process. In addition to COTS components, the CBSE process yields :
- Qualified components: Assessed by software engineers to ensure that not only functionality, but also performance, reliability, usability, and other quality factors conform to the requirements of the system/product to be built.
- Adapted components: Adapted to modify (wrapping) unwanted or undesired characteristics.
- Assembled components: integrated into an architectural style and interconnected with an appropriate component infrastructure that allows the components to be coordinated and managed effectively.
- Updated components: replacing existing software as new versions of components become available.

Software Component :
A software component simply cannot be differentiated from other software elements by the programming language used to implement the component. The difference lies in how software components are used.

Component model :
A component model defines specific interaction and composition standards. A component model implementation is the dedicated set of executable software elements required to support the execution of components that conform to the model. The standards have to contain a set of elements or services which are shown in the following alignment :
- Interfaces: Specification of component behavior and properties; definition of Interface Description Languages (IDL).
- Naming: Global unique names for interfaces and components.
- Meta data: Information about components, interfaces, and their relationships; APIs to services providing such information.
- Interoperability: Communication and data exchange among components from different vendors, implemented in different languages.
- Customization: Interfaces for customizing components.
- Composition: Interfaces and rules for combining components to create larger structures and for substituting and adding components to existing structures.
- Evolution Support: Rules and services for replacing components or interfaces with newer versions.
- Packing and Deployment: Packing implementation and resources needed for installing and configuring a component.

Reuse of Components :
The main purpose of software components is software reuse. The main types of software reuse are white-box reuse and black-box reuse. White-box reuse means that the source of a software component is fully available. Black-box reuse is based on the principle of information hiding. Software components are reused in general through black-box reuse. Components hide the inner working as much as possible.

Learn software concepts - Component Based Software Engineering (CBSE)

Component based software engineering (CBSE) offers inherent benefits in software quality, developer productivity, and overall system cost. And yet, many roadblocks remain to be overcome before the CBSE process model is widely used throughout the industry. The benefits of object-oriented design and component-based development seem obvious:
- Reusing software saves money in the development phase of software projects, i.e., the more components you reuse, the less software you have to build.
- The more applications in which you use a given component, the more valuable that component becomes.
- Reusable components enable application developers to customize applications without high costs and long development cycles.
- Reused software components have fewer bugs because they are used more often, and errors are uncovered and corrected along the way.

Why CBSE?
The goal of component-based software engineering is to increase the productivity, quality, and time-to-market in software development thanks to the deployment of both standard components and production automation. One important paradigm shift implied here is to build software systems from standard components rather than "reinventing the wheel" each time. This requires thinking in terms of system families rather than single systems. CBSE uses Software Engineering principles to apply the same idea as OOPs to the whole process of designing and constructing software systems. It focuses on reusing and adapting existing components, as opposed to just coding in a particular style. CBSE encourages the composition of software systems, as opposed to programming them.
CBSE should, in theory, allow software systems to be more easily assembled, and less costly to build. Although this cannot be guaranteed, the limited experience of adopting this strategy has shown it to be true. The software systems built using CBSE are not only simpler to bold and cheaper – but usually turn out to be more robust, adaptable and updateable.
CBSE allows use of predictable architectural patterns and standard software architecture leading to a higher quality end result.

The CBSE Process :
CBSE is in many ways similar to conventional or object-oriented software engineering. A software team establishes requirements for the system to be built using conventional requirements elicitation techniques. An architectural design is established. Here though, the process differs. Rather than a more detailed design task, the team now examines the requirements to determine what subset is directly amenable to composition, rather than construction. For each requirement, the team will ask:
- Are commercial off-the-shelf (COTS) components available to implement the requirement?
- Are internally developed reusable components available to implement the requirement?
- Are the interfaces for available components compatible within the architecture of the system to be built?
The team will attempt to modify or remove those system requirements that cannot be implemented with COTS or in-house components. The CBSE process identifies not only candidate components but also qualifies each components’ interface, adapts components to remove architectural mismatches, assembles components into selected architectural style, and updates components as requirements for the system change.
There are two processes that occur in parallel during the CBSE process. These are:
* Domain Engineering
* Component Based Development