Introduc)on

to So,ware
Engineering

So,ware
So,ware refers to all the computer programs
and associated documenta)on involved in
achieving a par)cular tasks

So,ware
A<ributes of good so,ware includes:
Deliver the required func)onality
Provide acceptable performance
Maintainable through the life cycle of the
so,ware
Dependable
Usable among target users

So,ware
Product
Characteris/cs

Descrip/on

Maintainability

So,ware should be wri<en in such a way so that it can evolve

to meet the changing needs of customers.

Dependability and
Security

Dependable so,ware should not cause physical or economic

damage in the event of system failure. Malicious users should
not be able to access or damage the system.

Eciency

So,ware should not make wasteful use of system resources

such as memory and processor cycles. Eciency therefore
includes responsiveness, processing )me, memory u)liza)on,
etc.

Acceptability

So,ware must be acceptable to the type of users for which it

is designed. This means that it must be understandable,
usable, and compa)ble with other systems that they use.

So,ware
Four Fundamental ac)vi)es of so,ware
processes:
1. So,ware specica)on

Func)onality of the so,ware and constraints on its

opera)on must be dened

2. So,ware development

The so,ware to meet the specica)on must be produced

3. So,ware valida)on

The so,ware must be validated to ensure that it does

what the customer wants

4. So,ware evolu)on (modica)on)

The so,ware must be evolve to meet changing customer

needs

So,ware Engineering
So,ware engineering:
Is an engineering discipline that is concerned with
all aspects of so,ware produc)on
It is a systema)c approach to the produc)on of
so,ware that takes into account:
Prac)cal cost
Schedule
Dependability issues
Needs of so,ware customers and produces

So,ware Engineering
Dierent types of applica)ons require dierent S.E.
methods and techniques. Examples of the dierent
type of applica)ons include:
Stand-alone applica)ons
Interac)ve transac)on-based applica)ons
Embedded control systems
Batch processing systems
Entertainment systems
Systems for modeling and simula)on
Data collec)on systems

So,ware Engineering
Engineering so,ware solu)ons should
consider the following:
So,ware reuse is becoming the dominant
approach for developing complex systems
It is imprac)cal to specify all the requirements for
systems in advance. Systems should be developed
and delivered incrementally

So,ware Process Models

Waterfall Model: Takes the fundamental process ac)vi)es
of specica)on, development, valida)on and evolu)on and
represents them as separate process phases.

So,ware Process Models

Incremental Development: This approach interleaves the
ac)vi)es of specica)on, development and valida)on. The
system is developed as a series of increments, with each
version adding func)onality to the previous version

Increment 1

Increment 2

Increment 3

So,ware Process Models

Reuse-oriented so<ware engineering: This approach is
based on the existence of a signicant number of
reusable components. The system development
process focuses on integra)ng these components into
a system rather than developing them from scratch.

Waterfall Model

Requirements analysis and deni)on

System and so,wre design
Implementa)on and unit tes)ng
Integra)on and system tes)ng
Opera)on and maintenance

Waterfall Model
Requirements analysis and deni1on The
systems services, constraints, and goals are
established by consulta)on with system users.
They are then dened in detail and serve as a
system specica)on.

Waterfall Model
System and so4ware design The systems design
process allocates the requirements to either
hardware or so,ware systems by establishing an
overall system architecture. So,ware design
involves iden)fying and describing the
fundamental so,ware system abstrac)ons and
their rela)onships.

Waterfall Model
Implementa1on and unit tes1ng During this
stage, the so,ware design is realized as a set of
programs or program units. Unit tes)ng involves
verifying that each unit meets its specica)on.

Waterfall Model
Integra1on and system tes1ng The individual
program units or programs are integrated and
tested as a complete system to ensure that the
so,ware requirements have been met. A,er
tes)ng, the so,ware system is delivered to the
customer.

Waterfall Model
Opera1on and maintenance Normally (although
not necessarily), this is the longest life cycle
phase. The system is installed and put into
prac)cal use. Maintenance involves correc)ng
errors which were not discovered in earlier
stages of the life cycle, improving the
implementa)on of system units and enhancing
the systems services as new requirements are
discovered.

Waterfall Model
The following phase should not start un)l
previous phase has nished and one or mode
documents that are approved and signed o.

Incremental Development
Incremental development is
based on the idea of
developing an ini)al
implementa)on, exposing this
to user comment and evolving
it through several versions
un)l an adequate system has
been developed
Specica)on, development,
and valida)on ac)vi)es are
interleaved rather than
separate, with rapid feedback
across ac)vi)es.

Incremental Development
Incremental development is:
Be<er suited for business, web-based systems, e-
commerce and personal systems
Cheaper and easier to make changes in so,ware
as being developed
Easier to get customer feedback during
development process to ensure exact t to
customer requirements
Faster to deploy useful so,ware to customer even
if all of func)onality not included

Incremental Development
Incremental development:
Process is not visible. Managers depend on
deliverables to measure progress
Causes system structure to degrade as new
increments are added. (regular changes tend to corrupt

so,ware, unless deliberate eort is spent to refactor and improve

exis)ng code)

Re-use-oriented so,ware engineering

This o,en happens informally when people
working on the project know of designs or
code that are similar to what is required. They
look for these, modify them as needed, and
incorporate them into their system.

Re-use-oriented so,ware engineering

Component analysis Given the requirements
specica)on, a search is made for
components to implement that specica)on.
Usually, there is no exact match and the
components that may be used only provide
some of the func)onality required.

Re-use-oriented so,ware engineering

Requirements modica5on During this stage,
the requirements are analyzed using
informa)on about the components that have
been discovered. They are then modied to
reect the available components. Where
modica)ons are impossible, the component
analysis ac)vity may be re-entered to search
for alterna)ve solu)ons.

Re-use-oriented so,ware engineering

System design with reuse During this phase,
the framework of the system is designed or an
exis)ng framework is reused. The designers
take into account the components that are
reused and organize the framework to cater
for this. Some new so,ware may have to be
designed if reusable components are not
available.

Re-use-oriented so,ware engineering

Development and integra5on So,ware that
cannot be externally procured is developed,
and the components and COTS systems are
integrated to create the new system. System
integra)on, in this model, may be part of the
development process rather than a separate
ac)vity.

Re-use-oriented so,ware engineering

There are three types of so,ware component
that may be used in a reuse-oriented process:
Web services that are developed according to
service standards and which are available for
remote invoca)on.
Collec/ons of objects that are developed as a
package to be integrated with a component
framework such as .NET or J2EE.
Stand-alone so<ware systems that are congured
for use in a par)cular environment.

PROCESS ACTIVITIES

Process Ac)vi)es
There are four basic process ac)vi)es:
Specica)on
Development
Valida)on
Evolu)on (maintenance)

Process Ac)vi)es
The process ac)vi)es are applied dierently
based on the development model u)lized:
Waterfall process ac)vi)es are sequen)al
Incremental development process ac)vi)es are
interleaved

So,ware Specica)on
So,ware specica)on is the process of
understanding and dening what services are
required from the system and iden)fying the
constrains on the systems opera)on and
development
It is also commonly referred to as
requirements engineering

So,ware Specica)on
Four main ac)vi)es within the so,ware
specica)on:
Feasibility study (whether it is possible and if its cost-eec)ve)
Requirement elicita)on and analysis (understanding the
system to be specied, through observa)on, discussion and
documenta)on)

Requirement specica)on
User requirements abstract statements of the func)onality for
customer and end-user of the system
System requirements are more detailed descrip)ons of
func)onality to be provided

Requirement valida)on (checks requirements for realism,

consistency and completeness)

So,ware Specica)on

So,ware Design and Implementa)on

A so,ware design is a descrip)on of the
structure of the so,ware to be implemented
It includes the data models and structures used
by the system, the interfaces between system
components and, some)mes, the algorithms
used.

So,ware Design and Implementa)on

The implementa)on stage of so,ware
development is the process of conver)ng a
system specica)on and design into an
executable system.
It always involves processes of so,ware design
and programming but, if an incremental approach
to development is used, may also involve
renement of the so,ware specica)on.

So,ware Design and Implementa)on

So,ware Design and Implementa)on

Four ac)vi)es that are part of the design process
for informa)on systems:
Architectural design, where you iden)fy the overall
structure of the system, the principal components,
their rela)onships, and how they are distributed.
Interface design, where you dene the interfaces
between system components.
Component design, where you take each system
component and design how it will operate.
Database design, where you design the system data
structures and how these are to be represented in a
database.

So,ware Valida)on
So,ware valida)on or, more generally,
verica)on and valida)on (V&V) is intended
to show that a system both conforms to its
specica)on and that it meets the
expecta)ons of the system customer.

So,ware Valida)on
Stages in the tes)ng Process:
Development Tes)ng
System Tes)ng
Acceptance Tes)ng

So,ware Valida)on
Development tes5ng
The components making up the system are tested by the
people developing the system. Each component is tested
independently, without other system components.
Components may be simple en))es such as func)ons or
object classes, or may be coherent groupings of these
en))es. Test automa- )on tools, such as JUnit (Massol and
Husted, 2003), that can re-run component tests when new
versions of the component are created, are commonly
used.

So,ware Valida)on
System tes5ng

System components are integrated to create a

complete system. This process is concerned with
nding errors that result from unan)cipated
interac)ons between components and component
interface problems. It is also concerned with showing
that the system meets its func)onal and non-
func)onal requirements, and tes)ng the emergent
system proper)es. For large systems, this may be a
mul)-stage process where components are integrated
to form sub- systems that are individually tested
before these sub-systems are themselves integrated
to form the nal system.

So,ware Valida)on
Acceptance tes5ng
This is the nal stage in the tes)ng process before the
system is accepted for opera)onal use. The system is
tested with data supplied by the system customer
rather than with simulated test data. Acceptance
tes)ng may reveal errors and omissions in the system
requirements deni)on, because the real data
exercise the system in dierent ways from the test
data. Acceptance tes)ng may also reveal
requirements problems where the systems facili)es
do not really meet the users needs or the system
performance is unacceptable.

So,ware Valida)on

The diagram above illustrates how test plans are the link between
tes)ng and development ac)vi)es. This is some)mes called the V-
model of development

So,ware Evolu)on (Maintenance)

So,ware evolu)on involves ensuring that the
so,ware solu)on con)nues to remain
relevant through out its life cycle.
Maintenance can be several )mes the ini)al
cost for development