There are 4 basic process activities that are applicable to all software processes.
1) Software specification:
The software must define functionality of the software and constraints on its operation.
2) Software development:
The software must be developed according to its specification.
3)Software validation:
The software must perform all the function that customer wants.
4)Software evolution:
The software must develop to meet changing customer requirements.
In software process there is no such thing as a ‘right’ or ‘wrong’ case. Different software processes divide these activities in different ways. The timing and result of the each activity varies as per software process. Using different processes different types of software product may be produced by an organization. However, it may possible that for particular application some processes are more suitable than others type of processes. If the wrong process is used, this will probably decreases the quality or the usefulness of the software product to be developed.
Because there are a number of different processes models are used, it is impossible to produce reliable figures for cost distribution across these activities. However, changing software usually takes up more than 60% of total software costs. This percentage is rising as more and more software is produced and has to be maintained. Designing software for change is vital.
Complex software processes involve a variety of activities. Processes have following attributes or characteristics:
1)Understandability :
To what level is the process explicitly defined and how easy is it to understand the process definition?
2)Visibility:
Does the process activity culminate in clear results so that the progress if the process is externally visible.
3)Supportability:
To what level can be process activities be supported by CASE tools
4)Acceptability:
Is the process acceptable to and usable by the engineers responsible for producing the software product?
5)Reliability
Is the process developed in such a way that process errors are avoided or trapped before they result in product errors?
6)Robustness :
Can the process carry on in spite of unexpected problems?
7)Maintainability:
Can the process progress to reflect changing organizational requirements or identified process improvements?
8)Rapidity:
How fast can the process of transferring a system from the given specification be completed
It is impossible to optimize all process attributes simultaneously. If a rapid development process is needed then it may be necessary to decrease the process visibility, making a process visible means producing documents at regular intervals. This will slow down the process.
There are varieties of different general models or paradigms of software development:
1) The waterfall approach:
This takes the above actions and represents them as separate process phase such as requirements specification, software design, implementation, testing and so on. After each stage is specified it is ‘signed off’ and development goes on to the following stage.
This is first explicit model of the software development process was derived from other engineering process. This was enthusiastically accepted by software project management. It offered a means of making the development process more visible. Because of cascade from one phase to another, this model is known as the ‘waterfall model’.
2) Evolutionary development:
This approach interleaves the actions of specification, development and validation. An initial system is rapidly developed from very abstract definitions. This is then defined with customer input to produce a system which satisfies the customer’s need. The system may then be transported. Alternatively, it may be re-implemented using a more planned approach to produce a more robust and maintainable system.
Evolutionary development based on the idea of designing an initial implementation, exposing this to user comment and refining these through many versions until an adequate system has been developed. Rather than have separate specification, development and validation actions, these are carried out concurrently with rapid feedback across these activities.
3) Formal transformation:
This approach is based on developing a formal mathematical system specification and transforming this specification, using mathematical methods to a program. These conversions are ‘correctness preserving’, this means that can be sure that the developed program meet its specification.
4) System assembly from reusable components:
This technique supposes that parts of the system already exist. The system development process concentrates on integrating these parts rather than developing them from scratch.
The fist two of these approaches, namely waterfall approach and evolutionary development are now widely used for practical systems development. Some systems have been built using correctness-preserving transformations but this is still an experimental process.
