Software Engineering: An Introduction

Software Engineering
An Introduction
Srikanta Murthy.K Department of IS & Engg

What is software?
 Computer programs and associated documentation
 Software products may be developed for a particular customer or

may be developed for a general market
 Software products may be

 Generic - developed to be sold to a range of different
customers
 Bespoke (custom) - developed for a single customer
according to their specification

Engineering
The science concerned with putting

scientific knowledge to practical use.
 Webster’s Dictionary
Physics versus Electrical Engineering

What is software engineering?
Software engineering is an engineering discipline
which is concerned with all aspects of software production
Software engineers should
 adopt a systematic and organised approach to their
work
 use appropriate tools and techniques depending on
 the problem to be solved,
 the development constraints and
 the resources available

Software Engineering
The science concerned with putting

computer science knowledge to practical
use.
Computer Science versus Software
Engineering

Software Engineering - IEEE
The application of a systematic, disciplined,

quantifiable approach to the development,
operation, and maintenance of software; that
is, the application of engineering to software.

Basic Activities of Software Engineering
 defining the software development process to be

used
 managing the development project
 describing the intended software product
 designing the product
 implementing the product
 testing the parts of the product
 integrating the parts and testing them as a whole
 maintaining the product

The Four P’s of Software Engineering
 Project – the task at hand

 People – by whom it is done
 Process – the manner it is done
 Product – the artifacts produced

Well-Engineered Software
 Provides the required functionality

 Maintainable
 Reliable
 Efficient
 User-friendly
 Cost-effective

Well-Engineered Software - contd.
 These requirements may be conflicting:

 Cost vs. Efficiency
 Cost vs. Reliability
 Efficiency vs. User-interface
 Law of diminishing returns.
 Challenge is to balance these
requirements.
History
 The field of software engineering was
born in 1968 in response to chronic
failures of large software projects to
meet schedule and budget constraints
 Recognition of "the software crisis"
 Term became popular after NATO
Conference in Garmisch Partenkirchen
(Germany), 1968
Software Life-Cycle Models
 The way you organize your activities

 The steps through which the product
progresses
– Requirements phase
– Specification phase
– Design phase
– Implementation phase
– Integration phase
– Maintenance phase
– Retirement

Role of software engineer
 Programming skill not enough
 Software engineering involves "programming-
in-the –large"
 understand requirements and write specifications
 derive models and reason about them
 master software
 operate at various abstraction levels
 member of a team
 communication skills
 management skills

What is the difference between software
engineering and computer science?
Computer Science Software Engineering

is concerned with
 theory  the practicalities of developing
 fundamentals  delivering useful software
Computer science theories are currently insufficient to act

as a complete underpinning for software engineering, BUT
it is a foundation for practical aspects of software
engineering

Relationships between
SE and other CS disciplines
 Programming languages
 Operating systems
 Data bases
 Artificial intelligence
 Theory

Relationships between
SE and other disciplines
 Management science
 Systems engineering
 Others

What is the difference between software
engineering and system engineering?
Software engineering is part of System engineering

 System engineering is concerned with all aspects of
computer-based systems development including

 hardware,
 software and
 process engineering
 System engineers are involved in
system specification,
architectural design,
integration and deployment
What is CASE ?
(Computer-Aided Software Engineering)
Software systems which are intended to provide

automated support for software process activities, such
as requirements analysis, system modelling, debugging
and testing
 Upper-CASE
 Tools to support the early process
activities of requirements and design

 Lower-CASE
 Tools to support later activities such as
programming, debugging and testing

What are the attributes of good software?
The software should deliver the required functionality and
performance to the user and should be maintainable, dependable and
usable
 Maintainability
 Software must evolve to meet changing needs
 Dependability
 Software must be trustworthy
 Efficiency
 Software should not make wasteful use of system resources
 Usability
 Software must be usable by the users for which it was
designed
What are the key challenges
facing software engineering?
Software engineering in the 21st century faces three

key challenges:
 Legacy systems
 Old, valuable systems must be maintained and updated
 Heterogeneity
 Systems are distributed and include
a mix of hardware and software

 Delivery
 There is increasing pressure
for faster delivery of software

Some Software Characteristics
engineered or
developed, not
manufactured in
the traditional
sense.
Software does not
wear out in the
same sense as
hardware.
Right: hardware
failure rate
In theory, software
does not wear out
at all.
BUT,
Hardware
upgrades.
Software upgrades.
Right: failure curve for
software

Reality is more like

this.
Most serious corporations
control and constrain
changes.
Most software is
custom built, and
customer never really
knows what she/he
Wants
Right: actual failure
rate for software

Software Myths
Myth: It’s in the software. So, we can easily

change it.
Reality: Requirements changes are a major cause of
software degradation.
Myth: We can solve schedule problems by
adding more programmers.
Reality: Maybe. It increases coordination efforts and
may slow things down.
Myth: While we don’t have all requirements in
writing yet, we know what we want and can
start writing code.
Reality: Incomplete up-front definition is the major
cause of software project failures.
Software Myths
Myth: I can’t tell you how well we are doing until I get
parts of it running.
Reality: Formal reviews of various types both can give good
information and are critical to success in large projects.
Myth: The only deliverable that matters is working code.
Reality: Documentation, test history, and program configuration
are critical parts of the delivery.
Myth: I am a (super) programmer. Let me program it,
and I will get it done.
Reality: A sign of immaturity. A formula for failure. Software
projects are done by teams, not individuals, and success
requires much more than just coding.

Software Myths
Myth: Writing
code is the major
part of creating a
software product.
Reality: Coding
may be as little
as 10% of the
effort, and 50 -
70% may occur
after delivery.
Below: Impact of
change.

What are the costs of software engineering?
 Roughly 60% of costs are development costs, 40%

are testing costs. For custom software, evolution costs often
exceed development costs
 Costs vary depending on the type of system being developed

and the requirements of system attributes such as performance
and system reliability
 Distribution of costs depends on the development model that is

used

What is a software process?
 A set of activities whose goal is the development or

evolution of software
 Generic activities in all software processes are:
 Specification - what the system should do and its
development constraints
 Development - production of the software system
 Validation - checking that the software is what the
customer wants
 Evolution - changing the software in response to
changing demands

What is a software process model?
A simplified representation of a software process,
presented from a specific perspective
 Examples of process perspectives:
Workflow perspective represents inputs, outputs and dependencies
Data-flow perspective represents data transformation activities
Role/action perspective represents the roles/activities of the
people involved in software process
 Generic process models
 Waterfall
 Evolutionary development
 Formal transformation
 Integration from reusable components

Software Development Lifecycle
Waterfall Model
Requirements
Design
Implementation
Integration
Validation
Srikanta Murthy.K Department of IS & Engg Deployment

Waterfall model problems
 Inflexible partitioning of the project into distinct
stages makes it difficult to respond to changing
customer requirements.
 Therefore, this model is only appropriate when the
requirements are well-understood and changes will
be fairly limited during the design process.
 Few business systems have stable requirements.
 The waterfall model is mostly used for large systems
engineering projects where a system is developed at
several sites.
Evolutionary development
 Exploratory development
 Objective is to work with customers and to evolve
a final system from an initial outline specification.

Should start with well-understood requirements
and add new features as proposed by the
customer.
 Throw-away prototyping
 Objective is to understand the system
requirements. Should start with poorly understood

requirements to clarify what is really needed.
Concurr ent
activities
Initial
Specification version
Outline Intermedia te
Development versions
description
Final
Valida tion version

 Problems
 Lack of process visibility;
 Systems are often poorly structured;
 Special skills (e.g. in languages for rapid
prototyping) may be required.

 Applicability
 For small or medium-size interactive systems;
 For parts of large systems (e.g. the user interface);

For short-lifetime systems.

Component-based software
engineering
 Based on systematic reuse where systems are
integrated from existing components or COTS
(Commercial-off-the-shelf) systems.
 Process stages
 Component analysis;
 Requirements modification;
 System design with reuse;
 Development and integration.
 This approach is becoming increasingly used as

component standards have emerged.

Reuse-oriented development
Requirements Component Requirements System design

specification analysis modification with reuse
Development System
and integ ration validation

Iterative Development Process
Two types of Model
 Incremental delivery
Specification, Design, and implementation

are broken in to series of increments and
done in turn.
 Spiral development
Process is represented as a spiral. Each loop of
the spiral show a phase of software processes
(e.g.: feasibility , requirement gathering).

Process iteration
 System requirements ALWAYS evolve in the course of
a project so process iteration where earlier stages are
reworked is always part of the process for large
systems.
 Iteration can be applied to any of the generic process
models.
 Two (related) approaches
 Incremental delivery;
 Spiral development.

An Iterative Development process
Cycle
Iterative Development Process model

Advantages of using Iterative process
 User engagement with system.
 Users of the system have to provide feedback
to the development team for the each

increments they .
 Accelerated delivery of customer.
 Normally early increments are high priority
Functions, so customers a get value from the

system early in its development also can
specify changes.

Incremental delivery
 Rather than deliver the system as a single delivery, the
development and delivery is broken down into
increments with each increment delivering part of the
required functionality.
 User requirements are prioritised and the highest
priority requirements are included in early increments.
 Once the development of an increment is started, the
requirements are frozen though requirements for later
increments can continue to evolve.

Incremental development
Define outline Assign requirements Design system

requirements to increments architectur e
Develop system Valida te Integ rate Validate

increment increment increment system
Final
system
System incomplete

Incremental development advantages
 Customer value can be delivered with each
increment so system functionality is available
earlier.
 Early increments act as a prototype to help
elicit requirements for later increments.
 Lower risk of overall project failure.
 The highest priority system services tend to
receive the most testing.

Extreme programming
 An approach to development based on the
development and delivery of very small
increments of functionality.
 Relies on constant code improvement, user
involvement in the development team and
pairwise programming.

Spiral development
 Process is represented as a spiral rather than as a
sequence of activities with backtracking.
 Each loop in the spiral represents a phase in the
process.
 No fixed phases such as specification or design -
loops in the spiral are chosen depending on what is
required.
 Risks are explicitly assessed and resolved throughout
the process.

Software Development Lifecycle
Spiral Model
Evaluate alternatives,
Determine objectives identify, resolve risks,
alternatives, constraints develop prototypes
Develop, verify
Plan next phases
Srikanta Murthy.K Department of IS & Engg next-level product
Spiral model of the software process
Deter mine objecti ves,
Evalua te alterna tives,
alterna tives and
identify, resolv e risks
constr aints Risk
anal ysis
Risk
anal ysis
Risk
Oper a-
anal ysis
Pr ototype 3 tional
Prototype 2 protoype
Risk
REVIEW anal ysis Proto-
type 1
Requir ements plan Simula tions , models , benchmar ks
Life-cy cle plan Concept of
Oper a tion S/W
requir ements Product
design Detailed
Requir ement design
De velopment
plan valida tion Code
Unit test
Integ ra tion Design
V&V Integ ra tion
and test plan
Plan ne xt phase test
Acceptance
Service test De velop , verify
ne xt-le vel pr oduct
Spiral model sectors
 Objective setting
 Specific objectives for the phase are identified.
 Risk assessment and reduction

 Risks are assessed and activities put in place to
reduce the key risks.

 Development and validation
 A development model for the system is chosen
which can be any of the generic models.

 Planning
 The project is reviewed and the next phase of the
spiral is planned.
Rapid Application Development
(RAD)

Development Methodology
 RAD (Rapid application development)
 Compressing the analysis, design, build, and
test phases into a series of short, iterative
development cycles.
 JAD (Joint Application Development )
 Methodology that involves the client or end user in the
design and development of an application, through a
succession of collaborative workshops called JAD
sessions.

Fundamental Characteristics of RAD
 Process specification ,design and implantation is done
Concurrently.
 System development is done in a Series of increments.
 User interfaces are often developed using Interactive

development systems. (RAD uses specialized tools that support
interface development)

Problems addressed by RAD
 With conventional methods, there is a long delay before
the customer gets to see any results.
 With conventional methods, development can take so

long that the customer's business has fundamentally
changed by the time the system is ready for use.
 With conventional methods, there is nothing until 100%
of the process is finished, then 100% of the software is
delivered.

Why should we use RAD?
 to converge early toward a design acceptable to the customer
and feasible for the developers
 to limit a project's exposure to the forces of change
 to save development time, possibly at the expense of
economy or
product quality
 You should NOT use RAD to
 to prevent cost overruns
 to prevent runaway schedules
Tradeoffs faced in RAD
 Tradeoffs between Schedule, Product and
economy is inevitable
 RAD focuses on Schedule more, thus Product

quality and Economy must be traded off

What cannot be achieved through RAD?
A Product with
 the fewest possible defects
 the highest possible level of customer

satisfaction
 the lowest development costs

When to use RAD
 The application will be run standalone.
 Major use can be made of preexisting components
 Performance is not critical.
 Product distribution will be narrow (in-house).
 Reliability is not critical.
 System can be split into several independent modules.

When not to use RAD
 Application must interoperate with existing programs.
 Few plug-in components are available.
 Optimal performance is required.
 Product development can't take advantage of high-

end tools (e.g., 4GLs).
 Product distribution will be wide (mass market).

Advantages of RAD
 Early visibility
 Greatly reduced manual coding
 Increased user involvement
 Possibly fewer defects
 Possibly reduced cost
 Shorter development cycles
 Standardized look and feel

Disadvantages of RAD
 Buying corporate software components could be costly
 Application is less efficient and less precise
 May accidentally empower a return to the uncontrolled practices
of the early days of software development
 More defects possible
 Reduced features
 Reliance on third-party components may ...
 sacrifice needed functionality
 add unneeded functionality
 create legal problems
 Standardized look and feel
 Successful efforts difficult to repeat

And finally…. An brief overview of the
essential aspects!
 Tools
 People
 Methodology
 Management

Software Engineering: An Introduction

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering: An Introduction

Uploaded by

Copyright:

Available Formats

Software Engineering

Srikanta Murthy.K Department of IS & Engg

 Software products may be developed for a particular customer or

 Software products may be

according to their specification

The science concerned with putting

Srikanta Murthy.K Department of IS & Engg

 the problem to be solved,

 the development constraints and

 the resources available

Srikanta Murthy.K Department of IS & Engg

The science concerned with putting

Srikanta Murthy.K Department of IS & Engg

The application of a systematic, disciplined,

Srikanta Murthy.K Department of IS & Engg

 defining the software development process to be

Srikanta Murthy.K Department of IS & Engg

 Project – the task at hand

Srikanta Murthy.K Department of IS & Engg

 Provides the required functionality

Srikanta Murthy.K Department of IS & Engg

 These requirements may be conflicting:

 The way you organize your activities

Srikanta Murthy.K Department of IS & Engg

Srikanta Murthy.K Department of IS & Engg

Computer Science Software Engineering

Computer science theories are currently insufficient to act

Srikanta Murthy.K Department of IS & Engg

Srikanta Murthy.K Department of IS & Engg

Srikanta Murthy.K Department of IS & Engg

Software engineering is part of System engineering

computer-based systems development including

 System engineers are involved in

Software systems which are intended to provide

activities of requirements and design

programming, debugging and testing

Software engineering in the 21st century faces three

a mix of hardware and software

for faster delivery of software

Srikanta Murthy.K Department of IS & Engg

Reality is more like

Srikanta Murthy.K Department of IS & Engg

Myth: It’s in the software. So, we can easily

Srikanta Murthy.K Department of IS & Engg

Srikanta Murthy.K Department of IS & Engg

 Roughly 60% of costs are development costs, 40%

 Costs vary depending on the type of system being developed

 Distribution of costs depends on the development model that is

Srikanta Murthy.K Department of IS & Engg

 A set of activities whose goal is the development or

 Validation - checking that the software is what the

Srikanta Murthy.K Department of IS & Engg

 Integration from reusable components

Srikanta Murthy.K Department of IS & Engg

Srikanta Murthy.K Department of IS & Engg Deployment

a final system from an initial outline specification.

requirements. Should start with poorly understood

Srikanta Murthy.K Department of IS & Engg

 Systems are often poorly structured;

 Special skills (e.g. in languages for rapid

prototyping) may be required.

 For parts of large systems (e.g. the user interface);

Srikanta Murthy.K Department of IS & Engg