It is strictly forbidden to reprint this column technology. This paper is made. This paper is filled from the software engineering expert network www.21cmm.com. Do not reprint without CBS license, thank you for the cooperation clean room software projects can be used as follows. : Incremental development under statistical process control, based on function specification, design and verification, and statistical testing and software certification. These techniques can be used separately or in use. These techniques can be used to improve the technical production process. Incremental Development Incremental Development under Statistical Process Control Based on the principle of controlled iteration in product development ------ control iteration. Incremental development does not use the entire development process as a whole, but divides it into a series of smaller, accumulated increments. Each increment is accumulated, that is, all previous increments plus new work and constantly accumulate. Incremental development is the basis for the development team to maintain project intelligence control. Because the team members only need to focus on the work in any time, not all things. Incremental development divides a clean room project into an ordered development cycle sequence. Complete some user features at each cycle. When each incremental development is completed, the product's functionality can be demonstrated. This customer has a real sense of understanding of the product, and they can re-confirm demand or make the demand clearer. This will minimize the product when the product is completed. The incremental development plan is driven by the system structure. In a mature production line, a reference structure can specify the structural and interface of the high-level, incremental will be reused, modified, or known location development assemblies in the architecture. In new development, the top structure either first increment, or be the first incremental object. Subsequent increments will complete the pile module in the structure. In an existing old system, the incremental plan can be consistent with a re-project plan, making the change not shaking but improves the system. In the maintenance environment, repair and enhancement see a continuation of incremental development, using the same process criterion used in new incremental development. A system structure is given, there are many factors to consider in incremental planning. In an embedded system, the progress coordination of hardware development is a feature to consider. In a graphical user interface (GUI) system, the first increment is usually developing a user interface prototype, and the most varying portion of the demand is discussed. Because incremental development avoids the overall framework, the functional dependence issues should always be considered when giving incremental development tasks. For example, when the marker in a file has other uses, the file must be analyzed. Other factors affecting incremental development are dangerous, complex, novel, reuse, and frequency of use. If possible, in an earlier increment, you need to include the most uncertain parts, which can understand the factors affecting progress as soon as possible. The advantage of intelligent control, customer feedback, risk management, and incremental development is to enable the project team effectively control the statistical process. At the end of each incremental development, the quality of the product is measured and compared to the quality goals of the team. The results of the comparison can determine if the project is tracked when the smaller deviation occurs, and the unacceptable deviation occurs. If the problem is determined, the team is going to make process adjustments to improve performance in the next increment. Function-based specifications, design and verification of the use of clean rooms not only have a solid theoretical basis, but also operability. Specifications from an external view (called state box), it is finally realized by a process (bright box). These forms are different, and the behavioral equivalent view is collectively referred to as a box structure. The box structure is object-based and supports the key principles of software engineering: information hidden and separated. The black box specification defines an external behavior of a system or its components from input to the output. Just define external behavior without having to describe internal status or implementation details. Black boxes only define a user view of a system or its components. The user here may be a person, hardware unit, or other program. The figure below is conceptually described with a black box, where SH represents Stimulus History, R represents the corresponding response (response).
A excitation sequence is a series of single inputs to the system. An incentive may be generated by the user (such as a button or mouse click), or the hardware (such as a clock pulse or signal from the sensor), or another software component (such as an operating system or database). A series of such incentives form a unique incentive sequence that must correspond to one response. The black box consists of all possible incentives, response lists, and mapping rules that are incentive to respond. Black box is a functional description with a state-independent, and the mapping must be complete, consistent, and trackable. The status cartridge specification is exported by the black box and is the first step of leading to implementation. The state box is defined as status data to obtain an external behavior specified by the black box. The status box defines the required behavior required by the system or its components as a mapping (transformation) from the current excitation and the old state to the corresponding response and new state. After defining status data, you don't have to consider motivation history. The following figure depicts the concept view of the status box. The status cartridge only describes the response and status update of the system or its components, and still does not include the process implementation details. Like the black box, the status box must meet the completeness, consistency, and tracking correctness. The cordial box specification is implemented for the corresponding state box. These processes realize the mapping rules of the status box, and it is also possible to introduce new black boxes representing the macro. The process must be sufficient to complete the necessary state updates and the required responses. The following figure depicts the concept view of the bright box, which controls the structure in order. Branches, cyclic and concurrent control structures can also appear in the bright box. The introduced black box will be detained in the subsequent refinement process into a state cartridge and a bright box. Like the black box and status box, the bright box must also meet complete, consistency, and trackable correctness. The bright box can be defined by the system's design language or target language. The correctness is verified in the box structure specification design, defining the black box to record the required behavior. The status box is the refinement of the black box, defines the required status data, the bright box is the refinement of the status box, defines the required process. Each box structure is verified by correctness during a group review. The team uses a functional reason to verify the correctness of each refinement step according to the previous step. In other words, the development team confirms that the excitation-response mapping rules defined in each step are held in the subsequent steps. For example, in the verification process verification, the correctness theorem of function theory is defined for the correct program (linger, mills, and witt 1979). The development team will verify the correctness of these conditions in the verification review. The bright box process may contain an unlimited path that is not possible to get all inspections by path-based review or software testing. But the correctness is defined based on the verification of a single control structure rather than the tracking path. Because the process includes a limited control structure, the correctness theorem will verify the inspection of a limited situation, and verify all possible usage from the logical personnel. All clean room development must pass the correctness verification based on the function theory before submitting the development group to the certification test group. A viable and powerful verification process enables the development group to completely verify the correctness of the software according to the specification. The verification step is very effective to delete errors, which is also the main factor in the net chamber improves software quality. The statistical test and software certification clean room test method adopts the basic principles of statistics, that is, when the overall is too large, the sample must be taken. First determine a model to represent all possible (generally unlimited) overalls. The test case is then generated by the model. Because the test case is a random sample of the overall, there is a valid statistical derivation of the system expected operation performance. Using a model refers to all possible situations in the system and the probability of occurrence thereof. The use model can be represented by many forms (including Markov models and formal syntax). In the Markov model, use the model, a state set is composed, and the state is connected by a transfer arc connection, the transfer arc refers to the system test, and there is a probability value corresponding to it. Probability refers to the likelihood of specific transfers from a given state. It has been tested examples from the starting state through the model to the end point. Figure 1.4 depicts a model. Among them, the arc representation is incentive, the node represents the status, and each arc is labeled incentives and probability.
