How Do We Build Correct Systems ?

To produce a correct software system, the way the software development process is handled is an essential ingredient. The ultimate goal is of providing users with products that meet their needs and expectations.

The recognition of the software crisis led to the birth of software engineering which, in turn, led to structured models for describing the software life cycle in order to make the process predictable and controllable – resulting in the production of a correct software system.

Software development process needs three transformation

• from the needs in the real world, to the problem statements
• from the problem statement to a detailed implementation statements
• from the implementation statement to an operational system

There are various methodologies available for software development. A Methodology is composed of a Software Development Model used in conjunction with one or more Software Development Techniques. The correct choice of methodology plays a crucial role for the delivery of reliable and correct software products. The chosen methodology must match the characteristics of the problem domain.

Three models widely used today are

• Waterfall Method first proposed by W.W Royce
• Spiral Model first proposed by Barry Boehm
• Evolutionary Model first proposed by T. Gilb

• Prototyping
• Cleanroom
• Object-Oriented Technologies & Software Reuse

• CASE Tools
• Formal Methods

The Waterfall Model
 

The waterfall model is a linear progression of project activities, where an input is received by an activity, processed, and the output is delivered to the next sequential activity as the input to that activity. The final output being the product for delivery to the customer.

The Spiral Model

The spiral model bends the planning, requirements, and design activities of the waterfall back around itself three times to allow these three activities to be injected with activities of evaluation, risk, verification, and planning based on the results of the previous spiral. The implementation activities of the spiral process returns to sequential activities as in the waterfall model.

The Evolutionary Model

The evolutionary model is where each development activity feeds output both forward as the waterfall, but also backwards to any activity as necessary to correct or improve the product being developed. This can be compared to a sort of two steps forward one step back dance. When needed this process can go all the way back to the beginning to re-evaluate and rework itself.

In all three of these models the same basic software development activities are taking place. Bersoff explains that these activities may be implemented differently, their relationship to other activities may change, and the process models themselves offer their own unique management issues but the general software development function of these activities remains unchanged.
 

The following software development activities are common to all development models
 

• Initialisation
• Requirements analysis and specification
• Design
• Implementation
• Integration and Test
• Maintenance

Since software is always part of a larger system, work begins by establishing requirements for all system elements and then allocating some subset of the requirements to software.

The System Specification – describes the function and performance of the compute-based system and the constraints that will govern its development. It serves as the foundation for the engineering of hardware, software, database and humans.

This system view is essential when software must interface with other system. It provides the software engineer with an indication of the role of software within the context of the system as a whole.

The whole process must be well planned. A Software Project Plan is produced at the culmination of the initial planning and provides a baseline cost and scheduling information that will be used throughout the software engineering process. The system must be rigorously planned to be correct in all of its aspects. The plan must
 

• Communicate scope and resources to software management, technical staff and customer
• Define risks and suggest risk management techniques
• Define cost and schedule for management review
• Provide overall approach to software development for all people associated in the project
• Outline how utility will be assured and change ill be managed

Requirements specifications play a key role in the software development process. It is used to gather information needed to give an insight into the product, its functionality, its design and its implementation procedure.

Requirements Specifications should be
 

• Clear
• Unambiguous
• Understandable
• Consistent
• Complete
 

Obtaining the above characteristics is crucial for successful systems and software development. Numerous studies have repeatedly shown that the majority of defects have their root cause in problems with the requirements specification. In one study quoted by James Martin, over 50% of all software defects are caused by incomplete, incorrect, inaccurate, and/or ambiguous requirements and over 80% of the costs of defects have their roots in requirements based errors. Another study established that a defect found in production is 270 times more expensive to fix than the same error if found at the requirements stage of the project. The major opportunity for improving the way software systems are tested lies in improving the process in which requirements specifications are developed and functional tests are designed.

Requirements analysis start by studying the system specification and the software project plan to understand software in the context system and ends with a Requirements Specification Document. This document describes the entire scope of the product. It puts the product in perspective, with other existing products and reviews, the infrastructure and resources needed for developing the product including the required technical skills of the developing team and of the end users.

Its purpose is twofold…
 

• Analysed and confirmed by the customer in order to verify whether it captured all of the customer’s expectations

• Used by the software engineer to develop a solution that meets the requirements.

When specifying a system, we need to find a balance for the formality of the specification. It is rather difficult to describe formally what a system must accomplish for two reasons –

• neither the customer nor the developer have a clear idea what they expect from the system
• the developer has a different perception of the system from that of the customer because of their background

A precise and unambiguous specification ensures that one can clearly understand the specifications and can therefore produce a program that conforms to the specifications. The system may be described on several levels of abstraction, from a rough general sketch of the system down to a very precise description, which may be "transcribed" to a programming. Too much rigor, makes the mathematical techniques clumsy, weak, and difficult to carry out without making errors. On the other hand, too little rigor permits errors of reasoning. The most appropriate level of rigor must be learned through experience, and is the region where the combined errors of reasoning from too little and too much detail are minimised.

Informal Specifications are unlikely to be accurate or complete. A natural language specification is likely to contain many ambiguities. Explanations in English are problematic in that they are subject to interpretation, unwritten assumptions and various ambiguities. Informal specifications are often little more than an initial bargaining offer.

Semi-Formal Specifications are by developed by using many diagrammatic, logic and algebraic notations without insisting on completely precise semantics. Amongst the most used diagrammatic notations are Data Flow Diagrams, Finite State Machine, Petri Nets and Entity Relationship Diagrams.

Formal Specifications - are high-level specifications describing the behaviour of the computer system and its components, written in a language that has a well-defined semantics. In other words, the specification can be compared against or executed by a computer program. A formal specification is very precise and while it may be more difficult to understand, at first sight, than an informal one, it can be reasoned with and understood exactly.

Therefore, formal specifications written using a formal specification language can facilitate the verification of the correctness of the implemented software by using automated reasoning techniques.

Formal specification of software systems have gained more and more importance in the software development process by striving for better software quality, i.e., by guaranteeing correctness and reliability.

  Specification Review

Both the developer and the customer conduct the review of the specifications. The use of CASE tools and prototypes can help in the review. Extreme care must be taken during the review as the specification is the foundation of all the subsequent activities and to ensure the developer and the customer, have the same perception of the system. The requirements document should be revised for completeness and accuracy, for traceability to higher level documents, and to assure that a sufficient base is provided for the software design. This is essential to develop a correct system. Once the review is complete, the requirements specification is signed by both the developer and the customer.

• Defined concept is evaluated to determine whether it satisfies user needs and project objectives in terms of system performance requirements, feasibility, completeness, and accuracy.
• Requirements evaluated for accuracy, completeness, consistency, correctness, testability, and understandability.
• Requirements are assessed to determine to well they accomplish the system and software objectives.

Once the Requirements Specification Document is ready, the software developer has a clear description of what functions the software system must provide. The information in the Requirements Specification Document is used to decompose the system into modules and describing what each module is intended to do and the relationship among the modules – in other words, producing a description of the software architecture.

Design can be divided into

• Architectural (Preliminary) Design
• Detailed Design

The detailed design should follow exactly the base-lined higher level design, and should be inspected for the same characteristics. The design should also be inspected for satisfaction of software quality engineering standards.

The design is documented in the Design Specification Document. This document, must be reviewed in the same way as the Requirement Specification document was.

During the implementation, the software is coded and unit tested. All documentation is produced in quasi-final form, including internal code documentation. Code verification should check for technical accuracy and completeness of the code, verify that it implements the planned design, and ensure good coding practices and standards are used. Documents should be inspected for accuracy, completeness, and traceability to higher level documents.

During this phase the software units are integrated into a completed system; non-conformances are detected, documented, and corrected; and it is demonstrated that the system meets its requirements. The integration and test plan is executed, the software documentation is updated and completed, and the products are finalised for delivery.

The final version of the Acceptance Test Plan should be verified to detect defects in the definition of test cases and to verify that each test case will verify the requirements with which it is associated.
 

During this phase, the software is used to achieve the objectives for which it was developed and acquired. Corrections and modifications are made to the software to sustain its operational capabilities and to upgrade its capacity to support its users. Software changes may range in scope from simple corrective action up to major modifications that require a full life cycle process.

The degree of correctness of a system may decrease as time passes. The user requirements or the system environment can instantly change, affecting the system. The developer must all the time be aware that the system requirements will change during the development, as they will change when the system is being used. The system modules must therefore be designed to be as flexible as possible, so that they are easy to change and adapt. The developer must always anticipate what the customer may need later on but is not yet aware of.

Often, the customer defines a set of general objectives for the software but does not identify detailed input, processing, or output requirements or else the developer is not sure that the customer requirements ere ell understood. These situations can never lead to a final correct system because the final system has no chance of being 100% as the customer wanted it.

Prototyping can be of great help in such situations. From the general objectives of the customer, a quick and dirty partial solution (prototype) is constructed representing mainly the input and output formats of the system.

It used as the starting point for:

• verifying that requirements are complete and accurate
• assessing the quality of the design
• completing the implementation

Not all systems are amenable to prototyping. In ‘Application Prototyping’, B. Boar suggests that a number of prototyping candidacy factors exist –

• Application area
• Application complexity
• Customer characteristics
• Project characteristics

Two Approaches To Prototyping

Throwaway Prototyping – prototype serves only as a rough demonstration of the requirements and then discarded.

Evolutionary Prototyping – prototype is further refined and each time re-evaluated – it is the first evolution of the final system.

In ‘Rapid Application Development’, S. Andriole suggests a set of questions that will assist in the selection of the prototyping approach. He also suggests 3 classes of methods and tools to conduct rapid prototyping which is a must in the effective use of prototyping. The classes are
 

• Fourth Generation Techniques
• Reusable Software Components
• Formal Specification

The cleanroom approach to software development, proposed by H.D. Mills together with M. Dyer and R. Linger in their paper “ Cleanroom Software Engineering”, emphasizes the need to build correctness into software as it is being developed. It is based on the notion that defects in software should be avoided rather than detected and repaired.

In their paper, "Adopting Cleanroom Software Engineering With A Phased Approach" , P. A. Hausler, R. C. Linger, and C. J. Trammell describe cleanroom as a theory-based, team-oriented engineering process for developing very high quality software under statistical quality control which combines formal methods of object-based box structure specification and design, function-theoretic correctness verification, and statistical usage testing for reliability certification to produce software approaching zero defects.

In their book, ‘Cleanroom Software Engineering Practices’ (1996), Shirley A.Becker and James Whittaker, present Cleanroom as a set of techniques and practices for the development of software-intensive systems.

Diagram

• quality is emphasized from the beginning
• formal methods for specification are used
• formal inspections are conducted
• proof of correctness is applied to all code that is developed
• statistically based independent testing is conducted

There are four characteristics of cleanroom software development.

1.Incremental development - The software is partitioned into increments, which are developed separately using the cleanroom process.

2.Formal specification - The software to be developed is formally specified.

3.Static verification - The developed software is statically verified using mathematically-based correctness arguments. There is no unit or module testing.

4.Statistical testing - The integrated software increment is tested statistically to determine its reliability.

The cleanroom approach is reportedly no more expensive than conventional development and testing but it results in software with very few errors. It suggests that the use of static verification is cost-effective. Defects are discovered before execution and are not introduced into the developed software. Overall development costs are not increased because less effort is required to test and repair the developed software.
 

Object Technologies reflect a natural view of the world. Objects are categorised into classes and class hierarchies. Each class contains a set of attributes that describe it and a set of operations that define its behaviour.

Object technologies lead to reuse, and reuse of components leads to faster software development and higher degree of correctness. OO Software is easier to maintain because its structure is inherently decoupled. This leads to fewer side effects hen changes have to be made. In addition, OO systems are easier to scale – large systems can be created by assembling reusable subsystems.

The reuse of a software component, which as verified to be correct and reliable, introduces less risk than redesigning and recoding the same component for each new application. Also, ‘reinventing the wheel’ in terms of a software component can be considered as a waste of time and resources.

W.C Lim reports in his paper "Effects OF Reuse On Quality, Productivity, And Economics" that in a study conducted at Hewlett-Packard in 1994, the defect rate of reused code is 0.9 defects per KLOC, while the rate for newly developed software is 4.1 defects per KLOC. For an application that was composed of 68% reused code, the defect rate was 2 defects per KLOC- a 51% improvement from the expected rate, had the application been developed without reuse

According to Professor M. T. Harandi, it is now a general understanding that improved software product quality and development productivity can best be achieved by new paradigms that incorporate software reusability: the creation and reuse of software building blocks.

Formal methods is a collection of techniques and languages based the use of (mathematical) logic and abstract modelling to logically state and assess the requirements in a format which is
 

• Clear
• Precise
• Consistent
• Unambiguous
• Can be checked mechanically
• Open to proof
 

Considering the above, when used well, a formal method should yield specifications that have significant advantages over natural language documents.

Any stage of the development lifecycle can benefit from the use of formal methods. From the specification through a refinement process, all the steps are mathematically proved, generally with the help of automatic tools such as provers. The rigour and clarity required for its effective use open the way for :

• more effective requirements capture and analysis
• earlier error detection
• cleaner and more robust architectures, designs and structures
• provably correct software
• better documentation
• enhanced maintainability
• projects completed on budget and on schedule

Formal methods supplement testing because testing can not test all cases on medium to large software. However, formal methods are not a guarantee of program correctness, and do not replace testing. The ‘Myths of Formal Methods’ have been a hot topic during the 1990s.

Computer-Aided Software Engineering tools have the aim of automating activities involved in software engineering. The tools for managing, specifying, programming, verifying, etc. are all integrated in the same environment so that information created by one tool can be used by another.

"Automating the software process phases in an integrated environment can give a great push towards a higher degree of software correctness."

CASE Tool characteristics that sustain the above statement are that a CASE tool…

• Can accept incremental formality – accepting partially specified objects and on-line modifications and incrementally checking their consistency and tolerating the remaining incompleteness.

• is (should be) based on a set of sound methods.

• Is very user friendly

• Can support different languages and paradigms

• Supports modularization as a major mechanism for structuring complex objects

• Can support group work