Page | 9
Cleanroom Software Engineering: Overview of the Architecture Specification
David Golke
Software Engineering
University of Wisconsin – Platteville
Abstract
Cleanroom software engineering is a method of developing software that has minimum defects in order to maintain a very high level of reliability. The strategy of cleanroom software engineering is to prevent any defects, rather than remove them after they have already been produced. If done correctly, this process can essentially remove the need for most debugging, as all defects should have been prevented throughout the design and development of the system. Cleanroom software engineering also makes use of formal methods of software engineering. These are used as they normally would be to completely and accurately specify, design, and verify the system that is being developed. In this presentation and paper I will discuss the project flow used in cleanroom software engineering to produce a product while preventing all possible defects, as well as discuss some places that this process has been used before.
Introduction and History
The person who originally created cleanroom software engineering was Harlan Mills, although he did have help from some of his colleagues. It seems that this may have been developed directly for IBM, as Mills and the colleagues involved worked for IBM, and I have found several articles about Cleanroom Software Engineering from IBM. The name comes from the cleanrooms that are used with developing certain electronics. The cleanrooms used in developing electronics are exactly what you would expect. These are also used to reduce defects, although these defects are usually caused in a physical way. Cleanroom software engineering is different in the sense that the defects are not caused by any physical variable, but rather from the development process and the developers themselves. The main goal of the cleanroom software engineering process is high-quality via defect prevention. This is done by developing software that will not require defect removal in the future, because of the defect prevention that it provides [5].
This goal of defect prevention usually will be used with the goal of producing software without any defects, or software that has a high probability of having no defects [4]. Cleanroom software engineering still goes through many processes that are used in other software development concepts. This paper will focus on the life cycle/project flow that is used in cleanroom software engineering, specifically the architecture specification (See Figure 1) [1]. This architecture specification contains the analysis/specification process cycle, as well as everything that follows that portion of the process [1].
When using cleanroom software engineering it is likely there will also be some form of certification done to confirm that the product is up to the desired quality, and free of defects [1]. During the activities of software engineering mathematics and statistics are applied to the process to uphold the quality and prevent defects [1].
Figure 1: Cleanroom Reference Model
Requirements Analysis
Just like requirements analysis with any other software development model, it is all about figuring out what the customer wants. After the requirements of the customer are figured out, then these must be laid out in a specific way. Throughout the whole project, the requirements may be subject to change if the customer sees fit, and the change is not unreasonable to the terms that were previously agreed on. Although it seems like defining requirements may be very similar in all software development methods, with cleanroom it is somewhat different because we need to push for the prevention of defects. There is a specific way that cleanroom software engineering defines requirements [1] [5].
With cleanroom software engineering the requirements need to be laid out in a certain way so that the defect prevention is possible. With cleanroom software engineering, the requirements will need to be broken down into smaller pieces. This is necessary so that these new pieces can be verified, which aids in preventing defects later. This process is known as “tagging” requirements [1] [5]. An example of tagged requirements can be seen in Table 1. These tagged requirements are essential for later use in function specification. They will essentially be used as an input later in the process. Essentially the increment planning will use information from this and usage specification as sort of inputs to produce the plan for the increments [1] [2]. These will be seen later when the box structure development method is discussed with regards to function and usage specification [5]. The requirements specification is part of the Analysis/Specification Process Cycle, contained in the Architecture Specification.
Table 1: Example of tagged requirements
Function and Usage Specification
Function and Usage Specification both come directly after Requirements Analysis and all of these are part of the architecture specification. Function specification is basically a way to define how the whole system will function. Along with that, usage specification is a way to define how the user will interact with the system. This includes figuring out who the users are, what environments they may be using, and different scenarios of usage [1]. Both of these need to be done in a way that can ensure the prevention of defects, and maintain a very high quality for the system. Function and usage specification are both part of the cycle that is contained in the Analysis/Specification Process Cycle. This is a smaller part of the whole Architecture Specification. Also, both the function and usage specifications are made from the previously defined requirements.
Function Specification
Cleanroom software engineering makes use of a “Box Structure Development Method” [1] [5]. There are three main box development methods: black box, state box, and clear box. For a diagram showing the all box models and how they work together, see Figure 2 [2]. These may seem familiar to the black, grey, and white boxes discussed in previous courses, although they are different. They are similar in the sense that they are all used to prevent defects in software engineering. For function specification, a team must create a function specification document. To ensure the prevention of defects, as well as the high quality that is desired, these must be laid out correctly, and completely. To be correct, they must be mathematically and logically correct. Also, this must be done in a consistent manner [5]. In the case of these boxes, we will take the previously defined requirements as our input, or stimuli. The three boxes use these, as well as the previous input history to produce a result, or response [2] [5]. They are used together to create a “state box” which will essentially take all the previous inputs and map them together, and this all makes up “state data” [2]. It is important to remember that the function specifications are subject to change throughout the project.
Figure 2: Box Structures
Usage Specification
The usage specification is created by a team from the requirements and function specification. This is also used to make sure the function specifications are complete and accurate [1]. It may seem that this disagrees with Figure 1, but this is not the case. These seem to be concurrent, but the usage specification uses the function specification as it is being created and changed [1]. It can be used for many things including defining how much testing needs to be done, analyze probabilities of failure, determining how many resources will be needed. With cleanroom software engineering there is a usage history. This is used both as an input for the function specifications and for determining probabilities for failure [3] [5]. This can be used to represent the quality of the software as well, by using the history to determine the probability of failure, and how often failure occurs [3].
Increment Specification
In cleanroom software engineering the product is released over a period of time in smaller pieces, or increments, of the final system [3]. Because of this we must plan how these increments are released. This is what increment specification plan is the process that is done to attain the plan for this. The end result is an Increment Construction Plan that must be created by a team [1] [2]. This is subject to change just like the requirements and function specification. The increment specification plan is a plan of how these increments will be set up and released. The function specifications are used to determine the individual increments [1] [2]. These increments can be used to identify failures so that changes can be made to correct these failures. As these increments are released they slowly will form the final product [3]. The increments are made up of the previously mentioned box structures, so that this can be tested later for defects [1] [2] [5]. For an example of what an individual increment might look like, see Figure 3.
Figure 3: Increment Example with Box Structures
Software Reengineering
When using cleanroom software engineering it may be desirable to use or incorporate some old code/software into the system being developed. Because of the need for the prevention of defects, as well as the high quality, this can become a problem. If the software being reused was developed with cleanroom software engineering it is probably fine, but this is not always the case. Because of this we need to determine if we can reuse the software, which can only be done if we can be fairly certain that we can avoid any failures that may be caused by the old software.
This software must be certified, just like the product being created must eventually be certified. To do this there are many things that must be done. First the overall cost in time and resources must be calculated somehow. Once we know if the cost is reasonable for this old software we have to reengineer it if it is not up to our standards. This involves figuring out exactly what the functionality of the software is, modifying this to our needs, and then creating the new reengineered software to be used [1]. Obviously this can only be done if it is worth it in the long run, if it cannot be done within a reasonable time frame, with a reasonable budget, alternatives may be found.
Increment Design
Increment design is basically following through with the plan that was created from the increment planning. We have a plan for the increments, but not a design yet so this must be done. These increments will be continually developed and released until there are no increments left to release and the project is done [1] [3] [4] [5] . This design process involves both the design, and coding. It also makes use of the box methods mentioned previously and shown in Figure 2. The increment design most likely makes use of all three of the box methods: black box, state box, and clear box. All three of these are used to determine that the software is correct. Once again, these boxes may be used together, as the state box is made up of state box and clear box both contain black boxes. With that, they are going to be used later, during verification with respect to each other to prove this correctness [1].
Correctness Verification
The reason that we want the software to be correct is so that it will have prevented the defects, and also be a very high quality. This is done with both verification that is mathematical, and by statistical testing [1] [2] [5]. The statistical testing usually dealing with the statistics representing the chance of failures, based on statistics gotten from using incremental development [3].
Usage Modeling and Test Planning
Usage modeling and test planning are somewhat used together. The test planning relies on the usage model that is created from usage modeling. The model basically must set up every possible way the program can be used by the user. This is why we learned earlier that the usage also keeps track of the usage or input history. This is all taken into account to determine all possible “usages”. During test planning then, the usage model is used to create a test plan that will be used later to test all the possible usages. Once again, statistics is going to come into play with this and the usage model and test plan must be created in a way that they will be able to produce statistics that represent the correctness of the software as well as the failure rate which translates to the fact that defects have been prevented [1]. All of this will later be used by the testing and certification to determine that the software is up to the quality desired. An example of results from testing that may be done with cleanroom engineering can be seen in Table 2.
Table 2: Example of Quality Results from Cleanroom Engineering
Statistical Testing and Certification
Once again, this step will be directly related to the previous steps in cleanroom software engineering, and also directly depend on the correctness of the previous steps. This is the final step in a life cycle of cleanroom software engineering and it is also the final say in whether the software is defect free and also of a high enough quality to meet the desired standards. The certification may be different depending on the field that the software is targeted for, as many are different standards have been created over time. The statistical testing is going to make use of documents created in multiple previous steps of the process, as well as the certification, as this is the way it was designed to work so that we can be sure the resulting software is at a high enough quality [1].
Conclusion
Cleanroom software engineering seems to be a very unique practice in software engineering. We see that it always builds off of the previous process, which is not unlikely, but while doing this it must maintain a certain standard of quality and also remain defect free and make sure no failures occur. This is quite a hefty goal, and with it comes a lot of work that must always be done to a very high correctness. In my understanding if even one piece of one step in the process of cleanroom software engineering goes awry, it is likely that the resulting software may not meet the certification it requires in the final step. Therefore any team doing a project with cleanroom software engineering must be sure that along every step of the way they are going about the process correctly, and in a way that will later produce statistics that can be used to accurately show the quality and correctness of the system, as well as the fact that there are no defects or a very low probability of failure to occur. With this, it is probably likely that no project would be created using cleanroom software engineering, unless the project needs that reassurance that the probability of any failures is extremely low.
References