Gradational conception in Cleanroom Software Development

Transcription

1 Gradational conception in Cleanroom Software Development Anshu Sharma 1 and Shilpa Sharma 2 1 DAV Institute of Engineering and Technology, Kabir Nagar, Jalandhar, India 2 Lovely Professional University, Department of Computer Science and Engineering, Jalandhar, India Abstract: The aim of this paper is to lay down the idea and practical application of gradational conception in cleanroom software engineering process. Gradational development is based on the mathematical principle of referential transparency. Cleanroom software engineering process makes use of gradients or increments to develop the software product in sequence or series of additive subsets of user functions. The gradients are aggregated in the top down manner into the final product in the conception and the certification pipeline. The various factors that must be considered for the development of gradients understand of the requirements, complexity, reliability, requirement for sub system, clarity of user functions, dependencies between functions and reusability. Keywords: Gradient conception, cleanroom software engineering, software life cycle, referential transparency. 1. INTRODUCTION The main purpose of using cleanroom software engineering is to transform from individual craftsmanship to peered review engineering, sequential development to gradational development, individual unit testing to team correctness verification, unmeasured reliability to measured reliability. The central fundamental of cleanroom software process is the software development based on formal methods and control implementation under statistical quality measurement. The cleanroom software engineering process deals with various methods of software specification, design or verification/validation testing and finally to get quality certification. It starts up with small unit and end up with fully integrated product by using top-down methodology. The cleanroom strategy contains four parts i.e Part1 consists of incremental planning, requirement gathering, and box structure specification. Part2 consists of formal design and correctness verification. Part3 consists of code generation, inspection, verification and statistical testing and part4 contains statistical use testing and certification. Figure 1 Cleanroom Software Engineering Process [5] There are basically three teams to perform the various activities and they are: 1. Specification Team: It deals with the hardware/ software requirement definitions, design and implementation of the software gradients. 2. Certification Team: it deals with the quality assurance by using various methods. 3. Development Team: This team is responsible for developing and verifying the software. The code inspection is performed for the correctness.[1] 2. EASE OF USE 1. Proper Control on Each Process: This technique gives the proper control over gradation development of software through the properties of referential transparencies. It also deals with the state date and responses based on stimuli Volume 1, Issue 2 July-August 2012 Page 150

2 histories. By verifying the result with the previous result one can improve or control on each and every process. It combines many of formal methods and software quality methods to get better decision and help in developing the error free products. Figure 2 Control Process It also enables cleanroom team to perform various activities simultaneously. The product will undergo well proved increments and get the feedback. Many specifications and models help keep a product longer periods of time. 2. Zero failure in the field: this is the main objective of this paper. It gives less than five failures per KLOC. New teams should experience a productivity increase in their first project and continue the increase. Correctness questions are asked and answered then formal mathematical verification is done. 3. Implemented gradually with higher quality: The significant advantage of cleanroom software engineering is that it can be developed gradually. While the activities involved in cleanroom software engineering is very strict so it attain a higher quality. It deals with the deeper understanding of the requirements, design and code by all verifiers involved. 4. Deals with formal design: It works on the specifications that are iteratively refined to become the architectural designs and component level designs. Cleanroom software engineering uses the box structure specification to define the products. Figure 3 Formal Design Once the requirements are fixed then functional and behavior of each gradation must be defined. At the end of each process the teams should have design resembling structure programming of their language of choice [2]. 3. PROPOSED WORK The overall objective of the gradational development is to grow a system with each new gradient as an elaboration of the functions implemented in previous gradients. The new function in gradient should be plug-in to the previous gradient at predefined point in its structure and should satisfy the sub specifications associated with the processing requirements at those points. This process of function allocation is the practical implementation of referential transparency to gradational conception planning. Thus, logical allocation of functions to gradients based on relationship among functions and intrinsic functional dependencies will predominate in the definition of gradient content. In a database system, for example, functions to add data would typically precede functions to delete data. In a statistical system, functions to collect and enter data would ordinarily precede functions to analyze data and report results. 3.1 Cleanroom Software Engineering Cleanroom defines formal methods of requirement and design with statistical usage testing to produce software with nearly none or zero defects. Software engineering emphasizes following a process model that separates requirements, design, coding, testing and the other steps. The cleanroom process embeds software development and testing within a statistical quality control framework. Mathematically based software development processes are employed to create software that is correct by design and statistical usage testing processes are employed to provide inferences about software reliability. This systematic process of accessing and controlling software quality during development permits the certification of software fitness for use at delivery. Cleanroom management is based on development and certification of pipeline of user function gradients that execute in a system environment and accumulate top down into the final product. Cleanroom teams interact with the variety of peer organizations depending on organizational and project context. System engineering and system test organizations may be involved in embedded software projects, standards, procurement and quality assurance. Organizations may be involved in large projects, configuration management, documentation and organizational software engineering process. The customer is part of cleanroom team as well. The term customer may mean external institutional sponsor, internal organizational sponsor, end user or any other party that is appropriate for defining requirement and evaluating the evolving system. 3.2 Key ideas in Gradational Conception The purpose of Gradient Planning Process is to: Allocate customer requirements defined in function Volume 1, Issue 2 July-August 2012 Page 151

3 specification to a series of software gradients that satisfies software architecture. Define schedule and resource allocation for gradient development and certification. Obtain agreement with the customer on the gradient plan. Increments are designed and implemented as usage hierarchies through box structure decomposition. This process preserves referential transparency between successive decomposition to maintain intellectual control. Increments designs can be expressed in object, functions or any other form. Each increment is based on a prior specification. Increment specifications are expressed in stimulus history based black box and state based state box forms. Increment designs and implementations are expressed in procedure based clear box forms that can introduce new black boxes for further decomposition. Reused or reengineered components are incorporated as planned. Team reviews during the increment design process focus on issues such as clarity, maintainability, reuse and conformance to style. In the companion correctness verification process, the team focuses exclusively on correctness. Specifications, designs and implementation evolve during the increment design process and intended functions are embedded in clear box procedure decomposition to permit effective correctness verification. The team performs correctness verification as the last intellectual pass through the work. The development team does not execute the increment implementation. First execution is performed by the certification team in the statistical testing and certification process after the development team has completed verification in the correctness verification process. Cleanroom minimizes the risk of integration faults through development based on the mathematical principle of referential transparency. Referential transparency in box structure hierarchies requires that the black box specifications embedded in clear boxes at each level of decomposition into state and clear boxes. With referential transparency, intellectual control is maintained and independent work at lower levels can proceed without concern for functional interactions at higher level. 4. EQUATIONS The black box gives the transition rules that specify the product behavior as response to particular stimuli by using the concept of OO inheritance concept. SH (Stimulus History) R (response) It specifies the system properties and functions by mapping all possible stimulus histories to all possible response. State box encapsulates the information (state Data) and operations similar to an object, the stimuli (inputs) and response (output) are represented, the information must be fetched between transitions. The state is the encapsulation of the stimulus history. SH * SD R * SD Stimulus history * State Data Response * State Data Clear box contains the algorithm design of state box similar to the structure programming. It gives both data flow and control flow. It also allows updating the state data and response [3]. 5. THEORETICAL FOUNDATION OF GRADATIONAL CONCEPTION Cleanroom software development is based upon the mathematical principle of referential transparency. Referential transparency in box structure hierarchies requires that the black box specifications embedded in clear boxes at each level of decomposition precisely define the required functional behavior of their subsequent decompositions into state and clear boxes. With referential transparency, intellectual control is maintained and independent work at lower levels can proceed without concern for functional interactions at higher levels. Referential transparency is the special property of arithmetic mathematics that computes large and complex expressions at one goes and gives the correct answer. It deals with the concept that operands value matters a lot in the equation its operands can be changed with other but same in value within a specific range. Table 1: Referential transparency in various systems Once referential transparency has been established for a particular system or for a particular programming language, cleanroom incremental development and verification techniques are guaranteed to work for any application that is developed in that language. In applying cleanroom to object oriented development, the functional description of objects and their methods must be enhanced to establish referential transparency [4]. Referential transparency can be applied in a formal way to full scale system development projects. 6. PROCESS MODEL The gradational conception or we can say incremental development is the life cycle process model. It is the standardized format of planning, organizing and running the new development products. Cleanroom software Volume 1, Issue 2 July-August 2012 Page 152

4 development products usually deal with the fixed financial budget, time constraints and other product constraints. Figure 4 Project Constraints There are hundreds of life cycle models like waterfall model, spiral model, iterative model and many more. By changing the life cycle model, we can improve or tradeoff product quality, product visibility, development time, risk reduction etc. use best strategies to remove risk factors. The spiral is visualized as a process passing through some number of iterations, with the four quadrants that represents the following activities: A. Formulate plans to identify software targets selected to implement the program, clarify the project development restrictions. B. Risk analysis that is an analytical assessment of selected programs to consider how to identify and eliminate risk. C. The implementation of the project for the development and verification. Risk driven spiral model emphasizing the conditions of options and constraints in order to support software reuse, software quality can help as a special goal of integration into the product development. 6.3 Incremental Life Cycle Model It is also known as loop approach. In 1988 Boehm developed the iterative model which includes risk analysis and risk management. It takes the core part and adds the functionality after every successful iteration. The incremental model is an intuitive approach to the waterfall model. Multiple development cycles take place making a life cycle as multi waterfall cycle cycles are divided up into smaller, more easily managed iterations. Each iteration passes through the requirements, design, implementation and testing phases. The working version of the software is produced during the first iteration, so one can have working software early on during the software life cycle. Subsequent iterations build on the initial software produced during the first iterations. Figure 5 Software Development Life Cycle The various models that can be used for the gradational conception in cleanroom software development are as follows: 6.1 Waterfall Model It is easy to understand and work well matured products and weak team but it does not match real world. It is the theoretical model to understand the product properly. In a strict waterfall model, after each phase is finished, it proceeds to the next one. Reviews may occur before moving to the next phase which allows for the possibility of changes. Reviews may also be employed to ensure that the phase is indeed complete. The phase completion criteria are often referred to as a gate that the project must pass through to move to the next phase. Waterfall discourages revisiting and revising any prior phase once it s complete. 6.2 Spiral Life Cycle Model Since end user requirements are hard to obtain, it is natural to develop software in an experimental way and 7. CONCLUSION Cleanroom software engineering is an engineering and managerial process for the development of high quality software with certified reliability. The main aim is to prevent the software errors as they occur. Testing should not be the only place where the errors must be caught, but the design phase as well. One of the main components of the cleanroom software engineering is gradational development. In gradational conception process of cleanroom software engineering, each gradient is developed separately and tested in a simulated production environment. This way the test result will speak about the quality of sub system. If the gradient adheres to the pre defined quality standards, then the next gradient development process is started. If not then development is stopped and the process is fixed. The results of the gradients can use in the improvement of the quality of the next gradient. Gradient prototyping and spiral life cycle model are useful to manage the risks. Each gradient is a complete iteration in the life cycle. This makes the process more Volume 1, Issue 2 July-August 2012 Page 153

5 successful. The mathematical principle of referential transparency proved to be very useful in defining gradients that can be implemented as a sub system. References [1] Stacy J. Powell, Carmen J. Trammell, Richard C. Linger, Jessy H. Poore, Cleanroom software engineering: technology and process. [2] Carmen J. Trammell, Richard C. Linger, Cleanroom software engineering version 1 November [3] Carmen J. Trammell, Mark G. Pleszkoch, Richard C. Linger, Allan R. Hevner The Incremental Development Process in Software Engineering in Decision Support System 17 (1996) [4] Richard C. Linger, Carmen J. Trammel technical Report on cleanroom software engineering reference model November 1996 [5] Chaelynne M. Wolak, Taking the art out of Software Development an In-Depth Review of Cleanroom Software Engineering AUTHOR Anshu Sharma received the B.E degree in Computer Science and Engineering from Lovely Institute of technology in And currently perusing M.S. degrees in Computer Science and Engineering from DAV Institute of Engineering and Technology, Jalandhar. Shilpa Sharma received the B.E degree in Computer Science and Engineering from Lovely Institute of technology in And currently perusing M.S. degrees in Computer Science and Engineering from DAV Institute of Engineering and Technology, Jalandhar. Volume 1, Issue 2 July-August 2012 Page 154