Page 23 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Unit 1: Introduction to Software Engineering

There is no such obsession as a right or a wrong software process. Dissimilar software processes Notes
crumble these performances in different ways. The timing of the performance varies as does
the results of each activity different organizations use-different processes to produce the same
type of product. Different types of product may be produced by an organization using different
processes. However, some processes are more suitable than others for some types of application.
If the wrong process is used, this will probably reduce the quality or the usefulness of the
software product to be developed.
Because there is a variety of different process models used, it is impossible to produce reliable
figures for cost distribution across these activities. However, we do know that modifying
software usually takes up more than 60% of total software costs. This percentage is increasing
as more and more software is produced and has to be maintained. Designing software for
change is therefore essential. Software processes (like most business processes) are complex
and involve a very large number of activities. Like products, processes also have attributes or
characteristics it is not possible to optimize all process attributes simultaneously. For example:
plea, if a rapid development process is required then it may be necessary to reduce the process
visibility making a process visible means producing documents at regular intervals. This will
slow down the process.
Detailed software process models are still the subject of research but it is now clear that there
are a number of different general models or paradigms of software development:

The waterfall Approach
The first explicit model of the software growth process was unoriginal from other engineering
processes. This was passionately accepted by software project management. It offered a means
of making the expansion process more visible. Because of the cascade from one phase to another,
this model is known as the ‘waterfall model’ (Figure 1.10).development goes on to the following
stage.

Figure 1.10: The Software Life Cycle

Requirements
definition

System and
software design

Implementation
and unit testing

Integration and
system testing

Operation and
maintenance

There are frequent variations of this process model (which is sometimes called the software life
cycle). The principal stages of the model map onto the primary development activities:
• Requirements analysis and definition: The system’s services, constraints and goals are
established by consultation with system users. They are then defined in a manner which
is understandable by both users and development staff.

LOVELY PROFESSIONAL UNIVERSITY 17