Software Engineering – Introduction

Dr. ir. N. Goga

 SE - Introduction
Introduction
· ··The Software Crisis.
Why the need for a Software Engineering discipline arose.
· ··What is Software Engineering.
Some definitions of the term Software Engineering.
· ··Some Software Failures.
· ··The Programming Systems Product.
There is a large difference between a small software program to be used by its
author only and a product that is going to be used by others.
· ··Software Characteristics.
What is so special about software: it is a logical rather than a physical product.
· ··Documentation and Life Cycle.
The process of constructing software creates all kinds of documents.
The actual code is only one of these documents.
· ··The ESA Software Engineering Standards.
The mandatory documents to be delivered by each project.
· ··The ESA Life Cycle.
An overview of its phases, main activities and deliverables.
 SE - Introduction

 The Software Crisis

During the years 1960/1970 it became clear that:
· The construction of large programs is much more problematic than for small
programs.
· The effort increases more than linearly compared to the size of a program.
· Hardware is no longer the most important factor.
· Do-it-yourself programming is not the same as the development of a product
to be used by or adapted by others.
· A program is not a static entity, but it evolves in time due to changes in
requirements and environment.
Software is no longer specialized problem-solving, but an industry in itself.
Hence a discipline to provide a framework for building software with a higher
quality is needed: Software Engineering.
 SE - Introduction

 Some Definitions of Software Engineering

There exist a lot of definitions of the term Software Engineering.
One of the earliest was given by Bauer in 1969:
The establishment and use of sound engineering principles in
order to obtain economically software that is reliable and works
efficiently on real machines.

Another quite common one is the IEEE 1993 definition:

The application of a systematic, disciplined, quantifiable approach
to the development, operation and maintenance of software; that
is the application of engineering to software.
Also: the study of such approaches.
 SE - Introduction
 Some Software Failures
The Therac-25
The Therac-25, a computerized radiation therapy machine, massively overdosed patients
at least six times between June 1985 and January 1987. Each overdose was several
times the normal therapeutic dose and resulted in the patient's severe injury or even
death. Overdoses, although they sometimes involved operator error, occurred
primarily because of errors in the Therac-25's software and because the manufacturer
did not follow proper software engineering practices.

The Ariane-5
On 4 June 1996 the maiden flight of the Ariane 5 launcher ended in a failure, about 40
seconds after initiation of the flight sequence. The failure was caused by specification
and design errors in the software of the inertial reference system. The extensive
reviews and tests carried out during the Ariane 5 development program did not include
adequate analysis and testing of the inertial reference system or of the complete flight
control system, which could have detected the potential failure.

Denver Airport
Problems with an automated baggage-handling system controlled by more than 100
computers have severely delayed the opening of Denver's new airport in 1994. On a
tested transit of 429 bags from the Continental ticket counters, 38 were lost in the
system, and an additional 15% had to have their bar-coded tags scanned twice. The
airport eventually opened in 1995, 16 months late, with delay costs over $300 million,
and with a mainly manual baggage system. The system suffered from problems in two
basic areas: software and mechanical.
 SE - Introduction
 The Programming Systems Product
Writing a large software product takes a lot of time.
The reported productivity lies in the order of a few lines of code per hour!

A program | A programming system

----------------------------------------------------------------------------------
A programming product | A programming systems
product *3

*3

Crossing the horizontal border or the vertical border each multiplies the effort
with a factor 3.
· Program: do-it-yourself.
· Product: something that is used by and/or maintained by others.
Complicating factors are: Generalization, testing, documentation,
maintenance.
· System: a collection of interacting programs/modules.
Complicating factors are: Interfaces, system integration.
 SE - Introduction

Software Characteristics
Software production does not lead to a physical product (like a car, VLSI chip,
building), the results are logical products.
Some typical characteristics are:
· Software is developed or engineered. It is not manufactured in the classical
sense.
· For hardware the manufacturing phase can introduce quality problems that
are not existent for software.
· Furthermore, a separate manufacturing process has to be developed.
· Software development costs are concentrated in engineering.
· Software only suffers from design errors.
· Software does not wear out.
Hardware follows the "bathtub" curve:
 SE - Introduction

Software does not suffer from wearing out, so it

should follow the following curve:
 SE - Introduction
But, due to changes during its life-time it deteriorates:

Most software is custom-built, rather than being assembled

from existing components.
 SE - Introduction

The ESA Software Engineering Standards
The ESA has published a set of standards defining the
mandatory documents to be delivered for each project.
The product documents are the following:
· URD - User Requirements Document
· SRD - Software Requirements Document
· ADD - Architectural Design Document
· DDD - Detailed Design Document
· Code
· SUM - Software User Manual
· STD - Software Transfer Document
· PHD - Project History Document
 SE - Introduction
ESA life cycle model
The production process or life cycle is divided into
six phases. These phases of the ESA life cycle
roughly correspond to the construction of one of
the above documents.
Explaining this model will introduce us to the
important activities and key terms in Software
Engineering activities!

·
SE - Introduction
 SE Introduction

The procedures to be followed are divided into four management

activities. Each activity has its corresponding project document.
Project Management.
The process of planning, organizing, staffing, monitoring, controlling,
and leading a software project.
All project management activities are documented in the SPMP, the
Software Project Management Plan of a project.
* Configuration Management.
The control of documentation and code.
The purpose is to plan, organize, control, and coordinate the
identification, storage and change of software through development,
integration and transfer.
These activities are defined in the SCMP, the Software Configuration
Management Plan of a project.
 SE - Introduction
* Verification and Validation.
-These activities check the software against its
specifications, during every phase of its development life
cycle.
-System testing: it is verified if the system satisfy the
requirements defined in Software Requirement Document
- Acceptance Testing: it is verified if the system satisfy the
requirements defined in Users Requirement Document;
done by an independent team including users; alpha/beta
testing
-They are defined in the SVVP, the Software Validation and
Verification Plan of a project.

* Quality Assurance.
-To ensure that all products and procedures conform to
standards and plans.
-These activities are defined in the SQAP, the Software
Quality Assurance Plan.
 SE - Introduction

• Once we introduced the basic activities and

terms through ESA software standards, let's us
introduce other models.
 SE - Introduction
Some common life cycles are:
· The waterfall model (that is the base also for ESA standards even if
little different)
Also called the classic life cycle or linear sequential model and the
oldest one.
The model defines a process that starts at the system level and
progresses - step by step - via analysis, design, code, test to
maintenance.
SE - Introduction
 SE - Introduction
• Advantages:
– Time spent early in the software production cycle can lead to greater economy at
later stages. It has been shown that a bug found in the early stages (such as
requirements specification or design) is cheaper in terms of money, effort and time,
to fix than the same bug found later on in the process
– A further argument for the waterfall model is that it places emphasis on
documentation
– Better management: planing and cost estimation
• Disadvantages:
– clients may not be aware of exactly what requirements they need before reviewing a
working prototype and commenting on it; they may change their requirements
constantly
– a working version of the program is not available until late in the project
– All the risks are present in just one cycle
– The feedback exists only on the transition between phases because the model is
sequential
• Where to use it: big organizations, projects in which the requirements are well understood
from the beginning;
• The experience shows that it is of a real value!
 SE - Introduction
The V-model is a software development process which can be
presumed to be the extension of the waterfall model. Instead of
moving down in a linear way, the process steps are bent upwards
after the coding phase, to form the typical V shape. The V-Model
demonstrates the relationships between each phase of the
development life cycle and its associated phase of testing.

The V-model deploys a well-structured method in which each phase can

be implemented by the detailed documentation of the previous phase.
Testing activities like test designing start at the beginning of the
project well before coding and therefore saves a huge amount of the
project time.
 SE - Introduction
• Prototype modeling
 SE - Introduction
The incremental model.
A number of linear sequences are applied that each deliver
a working part.
Each increment delivers a fully operational product, that is
a "stripped" version of the final product.
This is unlike prototyping, which only delivers something that
is used to identify requirements.
SE - Introduction
 SE - Introduction
• Advantages
– Generates working software quickly and early during the software life cycle.
– More flexible - less costly to change scope and requirements.
– Easier to test and debug during a smaller iteration.
– Easier to manage risk because risky pieces are identified and handled during its
iteration.
– Each iteration is an easily managed milestone.
– User Feedback given on the whole development time
• Disadvantages
– Each additional build has somehow to be incorporated into the existing structure
without degrading the quality of what has been build to date.
– Addition of succeeding builds must be easy and straightforward.
– The more the succeeding builds are the source of enexpected problems, the more
the existing structure has to be reorganized, leading to inefficiency and degrading
internal quality and degrading maintainability.
– The incremental models can easily degenerate into the build and fix approach.
– Design errors become part of the system and are hard to remove.
– Clients see possibilities and want to change requirements.
 SE - Introduction
· Rapid Application Development (RAD) is an
incremental model that emphasizes a very short
development cycle (1-3 months). It is used primarily for
information systems.
Each major system function is addressed by a
separate RAD team.
It is not usable if a system cannot be properly
modularized.
Two life cycle models currently attract a lot of interest:
· The Rational Unified Process (IBM) is an
incremental model that relies on extensive tool support.
 SE - Introduction
Agile software development refers to a group of software development methods based
on short iterative development (1-4 weeks)
Iterations are short time frames ("timeboxes") that typically last from one to four weeks.
Each iteration involves a team working through a full software development cycle
including planning, requirements analysis, design, coding, unit testing, and
acceptance testing when a working product is demonstrated to stakeholders. This
helps minimize overall risk, and lets the project adapt to changes quickly.
At the end of an iteration the team evaluates the priorities of the project
Agile methods emphasize face-to-face communication over written documents when the
team is all in the same location. When a team works in different locations, they
maintain daily contact through videoconferencing, voice, e-mail, etc.
Team composition in an agile project is usually cross-functional and self-organizing
Extreme Programming (XP)- one of the most used agile methods - is a lightweight
incremental model that emphasizes short iterations, extensive testing and simplicity. It
is intended for small teams in an environment of rapidly-changing requirements.
 SE - Introduction
• The predictive methods focus on the detailed
planing of activities and time
• The adaptive methods focus on quick
adaptation to changes
 SE - Introduction
• The spiral model is a software development process combining elements of both design and
prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. It
is made from more cycles.

• Each cycle consysts from the following phases:

• 1. The new system requirements are defined in as much detail as possible: definition of the
product, scopes, etc.

• 2. A preliminary design (risk analysys, prototyping) is created for the new system.

• This phase is the most important part of "Spiral Model".

• 3. A first prototype of the new system is constructed from the preliminary design: detailed design,
production, unit testing, integration ..

• 4. A second prototype is evolved by a fourfold procedure:

– evaluating the first prototype in terms of its strengths, weaknesses, and risks;
– defining the requirements of the second prototype;
– planning and designing the second prototype;
– constructing and testing the second prototype.
SE - Introduction