This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
For the purpose of this lecture we define high quality software as that software that ranks very highly on measures of software product quality. Some of these we remember were:
It was also demonstrated in the previous lectures that the ability to rank high on these quality attributes was related to the defect content of the product; albeit the relationship was complex and ill-defined.
We also stated that there were two approaches to management of defect in a product, defect prevention, and defect identification and removal. In this lecture we mainly deal with the former of the two, techniques that are used to prevent introduction of defects. In doing so we concentrate on techniques inspired by the exactness of a mathematical syntax.
We will also look at development processes that are aimed at the production of high quality (low defect) software.
As stated before we can use the language of mathematics to specify our requirements (this is called Formal Specification). Specifying a set of requirements formally has the potential to increase precision and consistency and to reduce introduction of defects
We can then use this formal specification (which is assumed correct) as the basis for formal or informal design work. One type of formal design work is to use mathematical transformations to transform the formal specification into an equivalent form written in an executable language. This is called formal derivation.
Additionally, once we have both the specification and the formal
derivation, we can use principles of mathematics to show that the two artifacts are equivalent. Usually by showing that every step of the derivation is mathematically robust and provably allowed. This is called formal proof construction.
Program derivation and proof construction are complex activities and are well beyond the scope of this course. Therefore we shall concentrate mainly on the activity of formal specification which in itself is a useful activity, even though followed by a non-formal design stage.
We shall use the formal language Object-Z (object zed) for our purpose.
Use of formal approaches to design correct modules
Use of statistical testing techniques to certify the software product
The basis is that each transformation in a computer program can be thought of as a mapping from a domain set to a range set. All deterministic programs therefore may be specified through the definition of these mappings.
Cleanroom: a practical approach to high quality software
During Requirements Capture and Requirements Analysis a users requirements definition is obtained through conventional means (e.g. interviews and construction of usecases).
During the Functional Specification phase, this definition is then precisely captured in a formal language.
Various services are then allocated to different increments (through the process of Increment Planning) and are scheduled for development and certification.
Increment design takes an allocated increment and uses the stepwise approach of box structures to refine each increment – in progressive levels of granularity - until verifiably correct code for each lowest level is obtained.
Software re-engineering is the activity of coordinating the use of existing software with the current increment. This can be in the form of reuse or integration.
Correctness verification is done formally through correctness proving.
Usage modeling is performed parallel to the development set of processes and aims to identify and model interactions possible with the system or a sub-system. This model then assist with the design of effective statistical test suites that test not the individual function but a sub-system or system increment.
At the conclusion of testing the customer shall accept the system or provide feedback for requirements validation. Once the increment is deemed to meet all requirements it will be certified.