Software engineering

Software engineering 1/36

Bibliography

1. Gamma E. et al.: Design patterns, WNT, Warszawa 2005

2. Miles R., Hamilton K.: Learning UML 2.0, Helion, Gliwice 2007
3. Pressman R. S.: Software Engineering: A Practitioner’s Approach,
WNT, Warszawa 2004
4. Sommerville I.: Software Engineering, WNT, Warszawa 2003

Software engineering 2/36

Course Outline

Lecture content:
I Introduction to software engineering
I Software development with UML
I Advanced software engineering
I Software testing
I Software processes
I Software management

Software engineering 3/36

Course Information

I Contact:
I mail: robert.dyja@icis.pcz.pl
I webpage: http://icis.pcz.pl/˜dyja
I Attending lectures — recommended
I Attending laboratories — required

Software engineering 4/36

Importance of software engineering

I National infrastructures are controlled by computer based

systems
I More and more systems require reliable software
I Software engineering is about theory, methods and tools used
in software development
I Software development is an important part of economy in
every developed country

Software engineering 5/36

Software costs

I Software costs are often major part of computer system price

It even happens sometimes that value of software installed on
a computer is higher than hardware
I Cost of maintenance is usually higher than cost of
development Multi-year maintains can even cost much more
than development
I Software engineering tries to find effective methods of
software development and implementation.

Software engineering 6/36

Software definition

I The software is computer programs, all associated

documentation and configuration data
I Kinds of software products:
I generic products – sold on open market
I customized products – commissioned by a particular customer

Software engineering 7/36

Software Characteristics

I Software processes data

I The importance of software increased during last 50 years
I Software is developed or engineered, but it is not
manufactured in the classical sense
I There is no manufacture phase (or problems during
manufacture are easy to correct)
I Software costs are concentrated in engineering

Software engineering 8/36

Software Characteristics – cont.

Software doesn’t ”wear out”

Increased failure rate

due to side effects

„Infant „Wear out”

mortality”

Wear
Wear

Change

Actual curve

Idealized curve

Time
Time

Figure: Failure curve for software

Figure: Failure curve for hardware

Software engineering 9/36

Software Characteristics – cont.

I Although the industry is moving toward component-based

assembly, most software continues to be custom built
I As an engineering discipline evolves, a collection of standard
design components is created
I In 1960-s, first libraries of reusable subroutines were created.

Software engineering 10/36

Software Applications

I System software
I Real-time software
I Business software
I Engineering and scientific software
I Embedded software
I Personal computer software
I Web-based software

Software engineering 11/36

Essential attributes of good software

I The specific set of attributes depends on its application,

however it is possible to present generalized set of attributes.
I Maintainability
I Software should be written in such a way so that it can evolve
to meet the changing needs of customers
I Dependability and security
I Software should not cause physical or economic damage in the
event of system failure.
I Efficiency
I Software should not make wasteful use of system resources
such as memory and processor cycles.
I Acceptability
I Software must be acceptable to the type of users for which it
is designed

Software engineering 12/36

Software Crisis

I Failures get more attention than successes

I The software crisis predicted 30 years ago never seemed to
materialize
I The set of problems that are encountered in the development
of computer software is not limited to software that ”doesn’t
function properly”, but rather how we support a growing
volume of existing software

Software engineering 13/36

Software Myths
Management myths
I We already have a book that is full of standards and
procedures for building software
I People have state-of-the-art software development tools,
because they work on newest computers
I If we get behind schedule, we can add more programmers and
catch up.
I If I decide to outsource the software project to a third party, I
can just relax and let that firm build it
I A general statement of objectives is sufficient to begin writing
programs
I Project requirements continually change, but change can be
easily accommodated because software is flexible

Software engineering 14/36

Software Myths

Practitioner’s myths
I Once we write the program and get it to work, our job is done
I Until I get the program ”running” I have no way of assessing
its quality
I The only deliverable work product for a successful project is
the working program
I Software engineering will make programmers create
voluminous and unnecessary documentation and will invariably
slow them down

Software engineering 15/36

Software engineering definition

I Software engineering is an engineering discipline that is

concerned with all aspects of software production from the
early stages of system specification through to maintaining
the system after it has gone into use
I Software engineers adopt a systematic and organized approach
to their work, as this is often the most effective way to
produce high-quality software

Software engineering 16/36

What is the difference between software engineering
and computer science?

I Computer science focuses on theory and fundamentals;

software engineering is concerned with the practicalities of
developing and delivering useful software
I Software engineer should know all the necessary theory, but on
the other hand theory doesn’t always keep up pace with reality

Software engineering 17/36

The software process

I The systematic approach that is used in software engineering

is called a software process
I There are four fundamental activities that are common to all
software processes:
I Software specification
I Software development
I Software validation
I Software evolution

Software engineering 18/36

Software engineering methods

I Software engineering methods are systematic approach to the

software process, which includes:
I Descriptions of system models
I For example: object model, data flow model, etc.
I Rules
I Constraints, that are applied to the system
I Recommendations
I Heuristics, that define good practices
I Advice
I Actions, that need to be performed

Software engineering 19/36

Software process models

Software process model

I A software process model is a simplified representation of a
software process
I Examples of software process models (paradigms):
I the waterfall model
I the prototyping model
I exploratory programming
I incremental development
I reuse-oriented software engineering
I the spiral model

Software engineering 20/36

The waterfall model

Requirements
Definition

Design

Implementation

Testing

Maintenance

Figure: The waterfall model (linear sequential)

Software engineering 21/36

The waterfall model – advantages and disadvantages

Disadvantages:
I High cost of mistakes made in early phases
I Long time between client contact
I Enforces software developers strict order of phases

Software engineering 22/36

The prototyping model

Phases:
I defining the overall objectives for the software
I ”quick design” and construction of prototype
I evaluation by the customer/user
I identification of software requirements
I the actual software is engineered with use of the waterfall
model

Software engineering 23/36

The prototyping model – advantages and
disadvantages

Advantages:
I better understanding of consumer needs
I possibility of demonstration working system early
I possibility of future users training before full version is finished

Disadvantages:
I additional cost of prototype preparation
I necessity of waiting for a full version after the prototype is
accepted

Software engineering 24/36

Methods of prototype preparation

I partial implementation
I high-level languages
I reusable components
I quick-and-dirty programming
I user interface generators
I exploratory programming

Software engineering 25/36

The exploratory programming

Basic System
requirements implementation
definition

System Disadvantages:
testing

I It is impossible to hold a
sound system structure
System
Yes No
I Testing is only possible by
Does it work?
delivery
client

Figure: The exploratory

programming paradigm

Software engineering 26/36

The incremental development

Requirements
specification

Iterative
Outline
process
description

Choosing features
of nth version

Design, implementation
and testing of nth version

Delivery of
nth version

Figure: The incremental development paradigm

Software engineering 27/36

The incremental development – advantages and
disadvantages

Advantages:
I Short time between contacts with client
I Client can use finished fragments of system before full system
is finished
I It is easy to react when delays occurs

Disadvantages:
I Additional cost when it is not possible to isolate set of
independent requirements

Software engineering 28/36

Reuse-oriented software engineering

It is based on:
I libraries
I fourth generation languages
I standalone applications

Methods of acquiring reusable components:

I buying from external sources
I appropriate development of current projects, so their parts can
be reused in future projects

Software engineering 29/36

Reuse-oriented software engineering – advantages
and disadvantages
Advantages:
I high reliability
I reduction of risk
I effective use of resources
I enforcement of standards
I potential cost reduction

Disadvantages:
I additional cost of preparation reusable components
I risk of high dependence on component supplier
I shortcomings of tools

Software engineering 30/36

The spiral model

Planning Risk
assessment

Validation Developing

Figure: The spiral model paradigm

Software engineering 31/36

CASE – Computer-Aided Software Engineering

I CASE covers a broad range of tools used during software

process like notation editors, code generators, etc.
I upper-CASE
I Used during early phases of software process
I lower-CASE
I Used during implementation and testing

Software engineering 32/36

Challenges of software engineers

I Challenge of legacy
I Maintenance and modification of large, running systems with
important business functions
I Challenge of diversity
I Software runs on very diverse systems; from large scale
distributed systems to hand-held computers
I Challenge of delivery
I Requirement of delivery working software in deadline without
loose of quality

Software engineering 33/36

Software engineering ethics

I Confidentiality
I You should normally respect the confidentiality of your
employers or clients irrespective of whether or not a formal
confidentiality agreement has been signed.
I Competence
I You should not misrepresent your level of competence. You
should not knowingly accept work that is outside your
competence.

Software engineering 34/36

Software engineering ethics

I Intellectual property rights

I You should be aware of local laws governing the use of
intellectual property such as patents and copyright. You should
be careful to ensure that the intellectual property of employers
and clients is protected.
I Computer misuse
I You should not use your technical skills to misuse other
people’s computers. Computer misuse ranges from relatively
trivial (game playing on an employer’s machine) to very serious
(dissemination of viruses or other malware).

Software engineering 35/36

Bibliography

I Pressman R. S.: Software Engineering: A Practitioner’s

Approach, WNT, Warszawa 2004,
I Sommerville I.: Software Engineering, WNT, Warszawa 2003

Software engineering 36/36