By mark the activities within software development

By mark the activities within software development

In this text we mark the important tasks of software development. The bulk of this book describes techniques for running out these tasks. As part of the story, we clarify the nature of two important activities that take place throughout software development – validation and verification. If you have ever written a program, there a number of activities that you know you are going to have to run out, for example, testing. The same is true of larger developments, but for big programs and large software systems, there are additional elements.

The activities are:

 1.    A viability study

  2.     Requirements engineering

3.     User interface design

4.    Architectural design

5.    Detailed design

6.     Programming

7.     System integration

8.    Validation

9.    Verification (testing)

10.  Production

11.  Documentation

12.  Maintenance

13.  Project management.

A method model is a plan that makes provision for all these required activities and seeks to include the stages in a methodical way. At the end of this chapter, we introduce the idea of method model, which is an overall trick for accomplishing software development. However, while it may seem obvious that they are carried out in a certain order, we shall see that this is not always the best trick. For example, it may not be ideal to run out validation as final step. Similarly, not all method models included the activities as unique actions.

A viability study

Before anything else is done, a viability study establishes whether or not the project is to proceed. It may be that the system is unnecessary, too expensive or too risky. One method to a viability study is to perform cost-benefit analysis. The cost of the recommended system is about, which may involve new hardware as well as software, and compared with the cost of likely savings. This comparison then determines whether the project goes ahead or not.

Requirements engineering

At the start of a project, the developer finds out what the user (client or customer) wants the software to do and records the requirements as clearly as possible. The product of this stage is a requirements specification.

User interface design

Most software has a graphical user interface, which must be carefully designed so that it is easy to use.

Architectural design

A software system may be large and complex. It is sometimes too large to be written as one single program. The software must be constructed from modules or substance. Architectural or large-scale design breaks the overall system down into a number of simpler modules. The products of this activity are an architectural design and module specifications.

Detailed design

The design of each module or component is carried out. The products are detailed designs of each module

Programming

The detailed designs are converted into instructions written in the programming language. There may be a choice of programming languages, from which one must be selected. The product is the code.

System integration

The individual substance of the software is combined together, which is sometimes called the build. The product is the complete system.

Validation

This seeks to ensure that the software meets its users’ needs. According to Beerbohm, validation answers the question: Are we building the right product? Validation is to do with the client’s view of the system, the external view of the system. It is no use creating a piece of software that works completely (that is tested to perfection) if it doesn't do what its users want. An important example of a validation activity is acceptance testing. This happens at the end of the project when the software is deemed complete, is displayed to its client and accepted by them as satisfactory. The inputs to acceptance testing are the client and the apparently complete software. The products are either a sign-off document and an accepted system or a list of faults. The outcome is that the system complies with the requirements of the client or it does not. Current evidence suggests that many computer systems do not meet the needs of their users, and that therefore successful validation is a major problem in software engineering today. It is a common experience that users think they have articulated their needs to the software engineer. The engineer will then spend months or even years developing the software only to find, when it is displayed, that it was not what the user wanted. This is not only demoralizing for both users and developers, but it is often massively costly in terms of the try needed to correct the deficiencies. As an extreme alternative the system is abandoned. It is too easy to nag the requirements analysis stage of development, when in reality the basic problem is the quality of the communication between users and developers. Users do not know (and usually do not care) about technicalities, since the software engineer expects detailed instructions. Worst of all is the problem of some common language for accurately describing what the user wants. The users are probably happiest with natural language (e.g. English), since the software engineer would probably prefer some more rigorous language that would be unknowable to the users. There is a cultural gap.