Chapter 2 – Processes and Models

Lesson 1
SOFTWARE ENGINEERING AND SOFTWARE PROCESSES

Objectives:
At the end of this chapter you should be able to:

• Define software engineering.

• Describe generic framework activities of the software engineering process.
• Describe various process models, such as the waterfall and prototyping models, in depth.
• Explain the difference between prescriptive and agile process models.
• Describe the main components of CASE tools, and how they can address system development
problems.

Readings:
The software crisis
There were many difficulties in the development of large software systems during the 1960s and 1970s.
The term “software crisis” dates from that time. The problems stemmed from an inability to apply the
techniques used to build small software systems to the development of larger and more complex
systems. The typical way to develop small systems can be described as “code-and-fix”.

The code-and-fix approach to software development

The “code-and-fix” approach to software development is not a proper life cycle (see later this unit).
Code-and-fix development occurs when software engineers come together with a vague set of
requirements and start producing software, fixing it, and changing it until the correct product appears.

Figure 2.1. The code-and-fix approach

ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 1

This is the simplest way to produce software and is invariably how every programmer learns to program.
But for anything other than small software projects, code-and-fix is a disaster for a number of reasons:

• There is no way to estimate time-scales or budgets.

• There is no assessment of possible risks and design flaws: you may come close to a finished
product only to find an insurmountable technical problem which sets the whole project back.

We only mention the code-and-fix approach in the context of life cycle models since it is a base-line
model which we should avoid. From a software engineer's point of view, code-and-fix is a worst-case
scenario.

Many project failures resulted from the inability to scale the techniques employed when developing
small software systems to handle larger, more complex systems. This failure leads to:

• never completed systems

• missed deadlines
• exceeded budgets
• a system that does not do all that is required of it
• a system that works but is difficult to use
• a system difficult to modify to meet changes in organizational needs and practices
• a loss of trust from users, who may experience many problems with using the software.

These problems were largely due to the lack of any framework for the planning and organization of
software development projects. Although some software projects were organized, and these were often
ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 2
the more successful ones, it was the luck of the draw whether a project manager had good intuitions
for software development, and whether or not problems arose due to misunderstandings between the
customers and the developers of the system. Likewise, there were no clear methods to monitor whether
a system was soon to go over budget or miss deadlines.

From some of these problems we can see that at some stage the system developers attempted (not
always successfully) to understand the requirements for the new system. We can now include in our
diagram of the process these specified requirements for the new system:

Figure 2.2. The process with requirements

Software engineering and the software process

Recognizing these problems, work was carried out to understand the process of software development
and to transform it into a reliable and rigorous discipline, like architecture or engineering. An
improved process should produce software that is correct, reliable, usable and maintainable. By
understanding the process, it should be possible to plan projects with more accurate predictions
of cost and time, and provide ways of monitoring intermediate stages of project progress, to be able
to react and re-plan if a project begins to go off budget or timescale.

Software engineering is exactly the discipline of producing such software. Fritz Bauer defined software
engineering to be: “the establishment and use of sound engineering principles in order to obtain
economically software that is reliable and works efficiently on real machines. ”

Much research has been put into the study of past systems that were both successful and unsuccessful.
This can be summarized as:

ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 3

 • Some software development activities appear to be common for all successful projects.
• Some activities need to occur before others.
• There is a need to both understand that requirements change, and to manage this change.
• Any existing systems need to be understood before working on the design of a new one.
• It is wise to delay decisions that will constrain the final system — this can be achieved by initially
designing an implementation-independent logical design (see the next chapter), before
committing to a detailed design for a particular physical set of hardware and software.

Analysis of such findings led to a model of what is called the software process, or system life cycle.
The software process is the process of engineering and developing software; a process model, or life
cycle model is a descriptive model giving the best practices for carrying out software development
(i.e., for carrying out the software process). However, a process model is often treated as
a prescriptive model that needs to be followed precisely, without any deviation. This should not be the
case. The specific model of the software process used should be tailored to meet the specific needs of
the project and the developers working on the project.

Note

The phrases “Software process”, “Software Life Cycle”, “System Development Life Cycle”, “System Life
Cycle”, “Development Life Cycle” are all used to describe the same concept.

The layers of software engineering

Software engineering is a discipline that can be pictured as being built up of layers

Figure 2.3. The layers of software engineering

ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 4

Software engineering demands a focus on quality. This should permeate throughout the rest of the
engineering discipline.

On top of this comes the foundation of software engineering: the software process. The process is the
framework on which the rest of software engineering is built. The process defines how management
occurs, what the required input and output products are, what milestones should be reached, and so
on. The process also describes how quality should be ensured.

On top of process, software engineering consists of methods. These describe how the various portions
that make up the software process should be carried out. For instance, how to communicate with
clients, how to test the software, to gather requirements, and so on. This makes up the process model.

And above all of this, and in support of the whole discipline, are the tools. The tools support the software
process. Such tools are called computer-aided software engineering tools.

A generic framework of the software process

A software process consists of the activities that are carried out during the development of every
software system. There are specific activities which are carried out at specific times, as well as activities
carried out throughout the project's lifetime. Such life-long activities are called umbrella activities.

A generic framework defining these activities for the software process can be given. It identifies
activities common to most of the models of the software process, although each model adapts the
activities to its own ends.

The activities are as follows:

• Communication - This activity involves the gathering of software requirements from the
customer, and related sub-activities.
• Planning - This is the activity of planning the work required to develop the software. This
includes risk management, listing the associated outputs, and producing a schedule for the
work.
• Modeling - This activity is involved with modelling both the requirements and the software
design, so that both the developers and the customers can better understand the work being
carried out.
• Construction - This is the development of the software. This activity also includes sub-activities
for testing the software.
• Deployment - The software is delivered, and the customer provides feedback on the software.

Self – Check Questionnaire 2

How well did you remember what you read? Answer the following questions briefly:

1. What are the layers of software engineering?

2. What are the activities of the generic software process?

ENGR. DENNIS C. TENERIFE, MSIT MODULE ON SOFTWARE ENGINEERING 5