An Introduction to Software

Engineering
 Objectives
To introduce software engineering and to explain its
importance
To set out the answers to key questions about software
engineering
To introduce ethical and professional issues and to
explain why they are of concern to software engineers
 Importance of Software
The economies of ALL developed nations are
dependent on software.
More and more systems are software controlled
Software engineering is concerned with theories,
methods and tools for professional software
development.
Expenditure on software represents a
significant fraction of GNP in all developed countries.
 Software costs
Software costs often dominate computer system costs.
The costs of software on a PC are often greater than
the hardware cost.
Software costs more to maintain than it does to
develop. For systems with a long life, maintenance
costs may be several times development costs.
Software engineering is concerned with cost-effective
software development.
 Evolving Role of Software

 Early Years  Fourth Era

 Batch orientation  Desktop systems
 Custom software  Object Oriented
Technologies
 Second Era
 Expert Systems
 Multi-user, Real-time
 AI, neural networks
 Database
 Parallel computing
 Product software
 Network computers
 Third Era
 Distributed systems
 Low cost hardware
 Software Engineering and “Bugs”


QUESTION: What’s the difference between
hardware and software ?…
• buy some hardware and you get a warranty, buy
some software and you get a disclaimer

The software crisis:
• always late
• always over-budget
• always buggy
• always hard to maintain
• always better the next time round … but never is!
When code goes bad … learning by
example

There are 1000s of software horror stories
(many of them untrue)

They are often memorable because of their
comic nature

They can also be tragic

Some are trivial to explain to a non-engineer

Some are very complex to understand, even for
software engineers

The most important thing is that they make us
think, and that we can learn from them.
 Some Cases

Case 1

Case 2

Case 3

Case 4
 Gemini V


Problem:
• Gemini V landed 100 miles off course

Reason:
• Some programmer was a bit weak on physics. The correct elapsed distance
(the key variable in this case) should have been calculated by using the Sun
as a fixed reference point and not a point on the Earth. The programmer
instead used elapsed time, thinking the reference point on Earth returns
every 24 hours. (The value of 24 is ~ 1.00273790935 of the correct value).
This difference results in only a few hundred miles in our solar system!

Analysis:
• The chief software engineer stated that none of his team knew about the
inaccuracy of the 24-hour day … and had coded it as an exact integer!

Who was to blame:
• The scientists who should have made this estimate clear to the engineers
and provided a more precise figure.
 Weather Forecasting


Problem:
• My aunt’s car got crushed by a tree because she was too lazy to park in her
garage after she listened to the 9o’clock news and weather forecast

Reason:
• On October 15, 1987, Michael Fish of the London Weather Center, made the
following pronouncement: ``Of course there won't be a hurricane in England.''
A few hours later the worst storm since 1703 hit, at speeds of around 100
mph (160 kph).

Analysis:
• A spokesman from the UK Meterological Office was reported in Computer
News, October 22, 1987, as saying, ``The Cyber 205 is not an easy machine
to work with but computers are fallible.'' The computer had mis-predicted the
storm track by 160 km.

Who was to blame:
• My uncle for not cutting down his tree the previous weekend when he was
asked to do so!
 World War 3 ?


Problem:
• On October 5, 1960, the North American Defense Command
(NORAD) went to 99.9% alert … just minutes from a defensive
counter strike

Reason:
• Programmers forgot that the moon rises and would show on radar.

Analysis:
• The moon did not even appear in the requirements model … why
would we want to shoot at the moon?

Who was to blame:
• The US government for being complacent about the risk involved …
the incompetent engineers should never have been put in such a
position
 The Americans (again)


Problem:
• On July 3, 1988, the U. S. Aegis cruiser Vincennes - jammed to the gunnels
with computers, radars and the fanciest equipment afloat - shot down an
Iranian airliner that had complied with every restriction placed on a civilian
aircraft in the area.

Reason:
• It appears that the crew panicked and misinterpreted the information
presented -- in effect, they drowned in information. The one man who needed
the information, Captain Rogers, could not get a clear picture of what was
going on because there was no one computer station that had the complete
picture.

Analysis:
• Reverse engineering the scenario showed that the data across different
machines was inconsistent … no wonder the poor man made a bad decision!

Who was to blame:
• Everyone, at every level of development and management (yet the captain
was criticised more than anyone)
 Australian Commonwealth Bank


Problem:
• 1.5 million bank accounts had data corrupted and a whole day’s transaction
had to be re-entered by hand … some complaints were still not resolved 5
years later and court cases cost millions of dollars.

Reason:
• On the night of February 25, 1988, the Australian Commonwealth Bank
doubled all debits and credits.

Analysis:
• A simple spurious 0 in a data file was not picked up and resulted in credits
being multiplied by 2 … to compensate, debits were also multiplied. This
prompted the manager to make the now famous-in-folk-lore comment: `
“The effects of software errors are limited only by the
imagination..”

Who was to blame:
• The chief software engineer whose invariant tested only that the credits and
debits balanced!
 Ariane 5


Problem:
• At 39 seconds after launch, as the rocket reached an altitude of two and
a half miles, a self-destruct mechanism finished off Ariane 5, along with
its payload of four expensive and uninsured scientific satellites.  This
disintegration had begun an instant before, when the spacecraft swerved
off course under the pressure of the three powerful nozzles in its
boosters and main engine. The rocket was making an abrupt course
correction that was not needed, compensating for a wrong turn that had
not taken place.

Reason:
• A 16-bit integer was used to perform a 32-bit calculation.

Analysis:
• Due to over-zealous re-use of code from Ariane 4 (which never
exploded!)

Who was to blame:
• The configuration testers who assumed that because the re-used
component worked in the old environment that it would work in the new
one as well
 Other Reports


How many of you have heard the following
stories:
• Hospital Scanner
• Social Security Pay Cheques
• Bank Auto-tellers
• Surface to air missile
• A German Car manufacturer’s ABS problems
• etc …?
 What is software?
 Software is
 Computer programs that when executed provide desired function and
performance
 Data structures to enable programs to manipulate information
 Documentation such as requirements, design models and user manuals.
 Today, software takes on a dual role. It is a product and, at the
same time, the vehicle for delivering a product.
As a product,
• it delivers the computing potential embodied by computer
hardware or, more broadly, a network of computers that are
accessible by local hardware. Whether it resides within a
cellular phone or operates inside a mainframe computer,
software is an information transformer
 
As the vehicle used to deliver the product,

software acts as the basis for the control of the computer
(operating systems), the communication of information
(networks), and the creation and control of other programs
(software tools and environments).

 Software delivers the most important product of our time—

information
 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 e.g. PC
software such as Excel or Word.
 Bespoke (custom) - developed for a single customer according to their
specification.
 New software can be created by developing new programs,
configuring generic software systems or reusing existing
software.
 The lone programmer of an earlier era has been replaced by a
team of software specialists, each focusing on one part of the
technology required to deliver a complex application. And yet,
the same questions asked of the lone programmer are being
asked when modern computer-based systems are built:
 • Why does it take so long to get software finished?
 • Why are development costs so high?
 • Why can't we find all the errors before we give the software to customers?
 • Why do we continue to have difficulty in measuring progress as software
is being developed?
These, and many other questions, are a manifestation
of the concern about software and the manner in which
it is developed—a concern that has lead to the
adoption of software engineering practice.
 History of Software Engineering
The term is 35 years old: NATO Conferences
Garmisch, Germany, October 7-11, 1968
Rome, Italy, October 27-31, 1969
The reality is it is finally beginning to arrive
Computer science one of the scientific basis
• Years of studies/experience/statistics provide basis too
Many aspects have been made systematic
• Methods/methodologies/techniques
• Languages
• Tools
• Processes
 Why Engineer Software ?
 The problem is complexity
 Many sources, but size is a key:
Mozilla contains 3 Million lines of code
UNIX contains 4 million lines of code
Windows 2000 contains 108 lines of code
 Second is role and combinatorics of “state”
 Third is uncertainty of “inputs” and their timing
 Fourth is the continuing changing “environment” and demands.

Software engineering is about managing

all the sources of complexity to
produce effective software.
 What is software engineering?
Software engineering is an engineering discipline that
is concerned with all aspects of software production.
Software engineers should adopt a systematic and
organised approach to their work and use appropriate
tools and techniques depending on the problem to be
solved, the development constraints and the resources
available.
 Software Engineering in a Nutshell
Development of software systems whose
size/complexity warrants team(s) of engineers
multi-person construction of multi-version software
[Parnas 1987]
Scope
study of software process, development/management
principles, techniques, tools and notations
Goal
production of quality software, delivered on time, within
budget, satisfying customers’ requirements and users’ needs
Definition of Software Engineering

 Classic Definition (1969)

“The establishment and use of sound engineering principles in

order to obtain economically software that is reliable and works
efficiently on real machines.”

 IEEE Definition (1993)

“Software Engineering: (1) The application of a

systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that
is, the application of engineering to software. (2) The
study of approaches as in (1).”
 Characteristics of Software
(difference with hardware)
1. Software is developed or engineered, it is not
manufactured in the classical sense.
Software costs are concentrated in engineering. This means
that software projects cannot be managed as if they were
manufacturing projects.
2. Software doesn't "wear out.“
3. Software is complex
Failure Curve for Hardware
 Hardware Characteristics
Relatively high failure rates early in its life (these failures
are often attributable to design or manufacturing
defects);
Defects are corrected and the failure rate drops to a
steady-state level (ideally, quite low) for some period of
time.
As time passes, the failure rate rises again as hardware
components suffer from the cumulative affects of dust,
vibration, abuse, temperature extremes, and many other
environmental maladies - hardware begins to wear out.
When a hardware component wears out, it is replaced
by a spare part. Availability of spare parts affect the
cost of maintenance.
Usually failure or breakdown is caused by component
or subsystem becoming faulty; not normally due to
design error.
Idealized and Actual Failure Curves for Software
 Software Characteristics
Not susceptible to the environmental maladies. In
theory, therefore, the failure rate curve for software
should take the form of the “idealized curve” shown.
Undiscovered defects will cause high failure rates early
in the life of a program. However, these are corrected
(ideally, without introducing other errors) and the curve
flattens as shown.
However, the implication is clear—software doesn't
wear out. But it does deteriorate!
There are no software spare parts. Every software
failure indicates an error in design or in the process
through which design was translated into machine
executable code. Therefore, software maintenance
involves considerably more complexity than hardware
maintenance
 Although the industry is moving toward component-
based assembly, most software continues to be custom
built.
In standard engineering discipline, a collection of standard
design components is created. Standard screws and off-the-
shelf integrated circuits are only two of thousands of standard
components that are used by mechanical and electrical
engineers as they design new systems. The reusable
components have been created so that the engineer can
concentrate on the truly innovative elements of a design. In the
hardware world, component reuse is a natural part of the
engineering process.
 Difference between software
engineering and computer science
Computer science is concerned with theory and
fundamentals; software engineering is concerned with
the practicalities of developing and delivering useful
software.
Computer science theories are still insufficient to act as
a complete underpinning for software engineering
(unlike e.g. physics and electrical engineering).
 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
 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
Software Engineering vs Traditional
Engineering

The main differences in software engineering compared
to other engineering disciplines : [BSI, 1995]
• It is difficult for a customer to specify requirements
completely.
• It is difficult for the supplier to understand fully the customer
needs.
• In defining and understanding requirements, especially
changing requirements, large quantities of information need
to be communicated and assimilated continuously.
• Software is seemingly easy to change.
• Software is primarily intangible; much of the process of
creating software is also intangible, involving experience,
thought and imagination.
• It is difficult to test software exhaustively
 Difficulties of SE
SE is a unique brand of engineering
Software is malleable
Software construction is human-intensive
Software is intangible and generally invisible
Software problems are unprecedentedly complex
Software directly depends upon the hardware
• It is at the top of the system engineering “food chain”
Software solutions require unusual rigor
Software “state” means behaviors can depend on history.
Software has discontinuous operational nature
 Software Engineering ≠ Software
Programming
Software programming
Single developer
“Toy” applications
Short lifespan
Single or few stakeholders
• Architect = Developer = Manager = Tester = Customer = User
One-of-a-kind systems
Built from scratch
Minimal maintenance
Software engineering
Teams of developers with multiple roles
Complex systems
Indefinite lifespan
Numerous stakeholders
• Architect ≠ Developer ≠ Manager ≠ Tester ≠ Customer ≠ User
System families
Reuse to amortize costs
Maintenance accounts for 60%-80% of overall
development costs
 Understanding the Problems


Considering the problems in software
development and the goals that software
development seeks to achieve. These are:
• Meeting the user’s needs
• Low cost of production
• High performance
• Portability
• Low cost of maintenance
• High reliability
• Delivery on time
 Understanding the Problems


Meeting the User’s Needs
• A piece of software must do what its users want of it (Obvious)
• However,
• software not always used quite as intended
• Different people have different (conflicting) requirements
• Communicating Requirements is fraught with difficulties
“When a passenger of foot heave in sight,
tootle the horn. Trumpet him melodiously
at first, but if he still obstacles your
passage tootle him with vigor."
From a brochure at a Tokyo car rental firm
• Deduce from this that a large proportion of systems do not meet the
needs of their users.
• Main problem of software development seems to lie in requirements
analysis and design
 Understanding the Problems


The Cost of Software Production :
• Programmer Productivity = 10 to 20 lines of code a day
• Predicting Software Costs
• how long it will take to write a piece of software?
• common for time scale to be underestimated by up to 50%
• Hardware v Software Costs
• In 1955 software cost typically only about 10% of a project, now it
is the hardware that is only 10% (or much less)
• The Impact of the Personal Computer
• Cheap, Available
• Software Packages
• Off the shelf solutions.
• The IT Revolution
• Software increasing in complexity.
 Understanding the Problems

The Cost of Software Production

How is the Cost Made Up? Detected in
testing

Detected on
compilation

Helpful to know where errors arise

Possibly
Detected
after
installation
Relative Costs of Fixing Software
Faults
200

30

10
3 4
1 2
Requirements Specification Planning Design Implementation Integration Maintenance
 Understanding the Problems


Meeting Deadlines :
• This has always been a major problem in software
production.
• Surveys have shown that this is the worst problem faced by
IT managers
• The problem is related to the difficulty of predicting how long
it will take to develop something.
• If we don’t know how long its going to take, we cannot hope
to meet any deadline.

Software Performance :
• Often we are concerned to make sure that:
• In interactive system responds within a reasonably short time;
• A control signal is output to a plant in sufficient time;
• batch job is not taking 12 hours when it should take 1.
 Understanding the Problems


Portability :
• Ideally, software should be easy to port
• High-level languages and international standards, assist
prospects.
• However, market forces have dominated the situation.
• Suppliers attract customers by offering extra facilities ON the
standard language, which may lessen the work of software
development.
• Programmers can be tied to particular suppliers.
• Recent years have seen the emergence of Java technologies
• Does this change the portability issue?
 Understanding the Problems


Maintenance :
• There are two types of maintenance:
• remedial maintenance is the time spent fixing bugs;
• adaptive maintenance is altering software to meet changing user
• needs or to accommodate new hardware and OS constraints.
• Managers regard maintenance as a nuisance - because they
need to ensure sufficient people to do it.
• Programmers regard it as the least interesting work.

Reliability :
• You can never assume that a piece of software is ever bug
free.
• Therefore, every large piece of software contains errors
 How to do SE?

Lawrence Chung Software Engineering: Introduction 50

 Mythical Man-Month
by Fred Brooks
 Published in 1975, republished in 1995
Experience managing development of OS/360 in 1964-65
 Central argument
Large projects suffer management problems different in kind than
small ones, due to division in labor
Critical need is the preservation of the conceptual integrity of the
product itself
 Central conclusions
Conceptual integrity achieved through chief architect
Implementation achieved through well-managed effort
“software developers” are not interchangeable work units.
Brooks’ Law
Adding personnel to a late project makes it later
 How to do SE?

Lawrence Chung Software Engineering: Introduction 52

 How to do SE?

Lawrence Chung Software Engineering: Introduction 53

 How to do SE?

Lawrence Chung Software Engineering: Introduction 54

 How to do SE?

Lawrence Chung Software Engineering: Introduction 55

 How to do SE?

Lawrence Chung Software Engineering: Introduction 56

 How to do SE?

Lawrence Chung Software Engineering: Introduction 57

 How to do SE?

Lawrence Chung Software Engineering: Introduction 58

 How to do SE?

Lawrence Chung Software Engineering: Introduction 59

 Understanding the Problems


A Software Crisis ? :
• We have covered various perceived problems with software
• It fails to do what the users want it to do
• It is expensive
• It is not always fast enough
• Its not always easily ported
• Maintenance is expensive
• Its is unreliable
• It is often late

Meeting user’s needs, reducing costs, improving
reliability, and delivery on time are the most important
problems
 A Solution - Software Engineering:


Greater emphasis on systematic development.

Computer assistance for software development (CASE)

A concentration on finding out the user’s requirements

Formal/Semi Formal specification of the requirements
of a system

Demonstration of early version of a system
(prototyping)

Greater emphases on trying to ensure error free code
 Software Applications
System software.
System software is a collection of programs written to service
other programs.
Real-time software.
Software that monitors/analyzes/controls real-world events as
they occur is called real time.
Business software.
Business information processing is the largest single software
application area.
 Software Applications
Engineering and scientific software.
Engineering and scientific software have been
characterized by "number crunching" algorithms.
Applications range from astronomy to volcanology,
from automotive stress analysis to space shuttle orbital
dynamics, and from molecular biology to automated
manufacturing. However, modern applications within
the engineering/scientific area are moving away from
conventional numerical algorithms. Computer-aided
design, system simulation, and other interactive
applications have begun to take on real-time and even
system software characteristics.
 Software Applications
Embedded software.
Intelligent products have become commonplace in
nearly every consumer and industrial market.
Embedded software resides in read-only memory and
is used to control products and systems for the
consumer and industrial markets.
Personal computer software.
The personal computer software market has
burgeoned over the past two decades.
 Software Applications
Web-based software.
The Web pages retrieved by a browser are software
that incorporates executable instructions (e.g., CGI,
HTML, Perl, or Java), and data (e.g., One of the most
comprehensive libraries of shareware/freeware can be
found at www.shareware.com hypertext and a variety
of visual and audio formats). In essence, the network
becomes a massive computer providing an almost
unlimited software resource that can be accessed by
anyone with a modem.
 Software Applications
Artificial intelligence software.
Artificial intelligence (AI) software makes use of
nonnumerical algorithms to solve complex problems
that are not amenable to computation or
straightforward analysis.
 Software—New Categories

Ubiquitous computing—wireless networks

Netsourcing—the Web as a computing engine
Open source—”free” source code open to the
computing community (a blessing, but also a
potential curse!)
Also
Data mining
Grid computing
Cognitive machines
Software for nanotechnologies
 Legacy Software

Why must it change?

• software must be adapted to meet the needs of new
computing environments or technology.
• software must be enhanced to implement new business
requirements.
• software must be extended to make it interoperable with
other more modern systems or databases.
• software must be re-architected to make it viable within a
network environment.
 Software Myths
Management myths.
 Myth 1: We already have a book that's full of standards
and procedures for building software, won't that provide my
people with everything they need to know? Reality 1
 Myth 2: My people have state-of-the-art software
development tools, after all, we buy them the newest
computers. Reality 2
 Myth 3: If we get behind schedule, we can add more
programmers and catch up (sometimes called the
Mongolian horde concept). Reality 3
 Myth 4: If I decide to outsource the software project to a
third party, I can just relax and let that firm build it. Reality 4
next
 Software Myths
Customer myths
 Myth 5: A general statement of objectives is sufficient to
begin writing programs—we can fill in the details later.
Reality 5

 Myth 6: Project requirements continually change, but

change can be easily accommodated because software
is flexible.
Reality 6

next
 Software Myths
Practitioner's myths
 Myth 7: Once we write the program and get it to work,
our job is done. Reality 7
 Myth 8: Until I get the program "running" I have no way
of assessing its quality. Reality 8
 Myth 9: The only deliverable work product for a
successful project is the working program. Reality 9
 Myth 10: Software engineering will make us create
voluminous and unnecessary documentation and will
invariably slow us down. Reality 10

next
 Reality 1
 Reality 1: The book of standards may very well exist, but
is it used? Are software practitioners aware of its
existence? Does it reflect modern software engineering
practice? Is it complete? Is it streamlined to improve time
to delivery while still maintaining a focus on quality? In
many cases, the answer to all of these questions is "no.“

back
 Reality 2
 Reality2: It takes much more than the latest model
mainframe, workstation, or PC to do high-quality software
development. Computer-aided software engineering
(CASE) tools are more important than hardware for
achieving good quality and productivity, yet the majority
of software developers still do not use them effectively.

back
 Reality 3
 Reality 3: Software development is not a mechanistic
process like manufacturing. In the words of Brooks
[BRO75]: "adding people to a late software project makes
it later.

back
 Reality 4
 Reality 4: If an organization does not understand how to
manage and control software projects internally, it will
invariably struggle when it outsources software projects.

back
 Reality 5
 Reality 5: A poor up-front definition is the major cause of
failed software efforts. A formal and detailed description
of the information domain, function, behavior,
performance, interfaces, design constraints, and
validation criteria is essential. These characteristics can
be determined only after thorough communication
between customer and developer.

back
 Reality 6
 Reality 6: It is true that software requirements change, but the
impact of change varies with the time at which it is introduced. Figure
below illustrates the impact of change. If serious attention is given to
up-front definition, early requests for change can be accommodated
easily. The customer can review requirements and recommend
modifications with relatively little impact on cost. When changes are
requested during software design, the cost impact grows rapidly.
Resources have been committed and a design framework has been
established. Change can cause upheaval that requires additional
resources and major design modification, that is, additional cost.
Changes in function, performance, interface, or other characteristics
during implementation (code and test) have a severe impact on cost.
Change, when requested after software is in production, can be over
an order of magnitude more expensive than the same change
requested earlier.
Impact of Change on Cost back
 Reality 7
 Reality 7: Someone once said that "the sooner you begin
'writing code', the longer it'll take you to get done."
Industry data indicate that between 60 and 80 percent of
all effort expended on software will be expended after it is
delivered to the customer for the first time.

back
 Reality 8
 Reality 8: One of the most effective software quality
assurance mechanisms can be applied from the inception
of a project—the formal technical review. Software
reviews are a "quality filter" that have been found to be
more effective than testing for finding certain classes of
software defects.

back
 Reality 9
 Reality 9: A working program is only one part of a
software configuration that includes many elements.
Documentation provides a foundation for successful
engineering and, more important, guidance for software
support.

back
 Reality 10
 Reality 10: Software engineering is not about creating
documents. It is about creating quality. Better quality
leads to reduced rework. And reduced rework results in
faster delivery times.

back
 Professional and ethical
responsibility
Software engineering involves wider responsibilities
than simply the application of technical skills.
Software engineers must behave in an honest and
ethically responsible way if they are to be respected as
professionals.
Ethical behaviour is more than simply upholding the
law.
Issues of professional responsibility
Confidentiality
Engineers should normally respect the confidentiality of their
employers or clients irrespective of whether or not a formal
confidentiality agreement has been signed.
Competence
Engineers should not misrepresent their level of competence.
They should not knowingly accept work which is outwith their
competence.
Issues of professional responsibility
 Intellectual property rights
 Engineers should be aware of local laws governing the use of intellectual
property such as patents, copyright, etc. They should be careful to ensure
that the intellectual property of employers and clients is protected.
 Computer misuse
 Software engineers should not use their technical skills to misuse other
people’s computers. Computer misuse ranges from relatively trivial (game
playing on an employer’s machine, say) to extremely serious
(dissemination of viruses).
 ACM/IEEE Code of Ethics
The professional societies in the US have cooperated
to produce a code of ethical practice.
Members of these organisations sign up to the code of
practice when they join.
The Code contains eight Principles related to the
behaviour of and decisions made by professional
software engineers, including practitioners, educators,
managers, supervisors and policy makers, as well as
trainees and students of the profession.
 Code of ethics - preamble
 Preamble
 The short version of the code summarizes aspirations at a high level of the
abstraction; the clauses that are included in the full version give examples
and details of how these aspirations change the way we act as software
engineering professionals. Without the aspirations, the details can become
legalistic and tedious; without the details, the aspirations can become high
sounding but empty; together, the aspirations and the details form a
cohesive code.
 Software engineers shall commit themselves to making the analysis,
specification, design, development, testing and maintenance of software a
beneficial and respected profession. In accordance with their commitment
to the health, safety and welfare of the public, software engineers shall
adhere to the following Eight Principles:
 Code of ethics - principles
 PUBLIC
 Software engineers shall act consistently with the public interest.
 CLIENT AND EMPLOYER
 Software engineers shall act in a manner that is in the best interests of their
client and employer consistent with the public interest.
 PRODUCT
 Software engineers shall ensure that their products and related
modifications meet the highest professional standards possible.
 Code of ethics - principles
 JUDGMENT
 Software engineers shall maintain integrity and independence in their
professional judgment.
 MANAGEMENT
 Software engineering managers and leaders shall subscribe to and
promote an ethical approach to the management of software development
and maintenance.
 PROFESSION
 Software engineers shall advance the integrity and reputation of the
profession consistent with the public interest.
 Code of ethics - principles
COLLEAGUES
Software engineers shall be fair to and supportive of their
colleagues.
SELF
Software engineers shall participate in lifelong learning
regarding the practice of their profession and shall promote an
ethical approach to the practice of the profession.
 Ethical dilemmas
Disagreement in principle with the policies of senior
management.
Your employer acts in an unethical way and releases a
safety-critical system without finishing the testing of the
system.
Participation in the development of military weapons
systems or nuclear systems.
 What is a software process?
A process may be defined as a method of doing or
producing something. Extending this to the specific
case of software, we can say that a software process
is a method of developing or producing software.
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.
 The purpose of process

Effectiveness.
Not to be confused with efficiency. An effective process must
help us produce the right product. If it isn't what the customer
wanted, or required, it's no good. The process should therefore
help us determine what the customer needs, produce what the
customer needs, and, crucially, verify that what we have
produced is what the customer needs.
 Maintainability.
One of the goals of a good process is to expose the designers'
and programmers' thought processes in such a way that their
intention is clear. Then we can quickly and easily find and
remedy faults or work out where to make changes.
• None of this is made any easier if, when a problem is discovered, everybody
stands around scratching their heads saying "Oh dear, the person that wrote this
left the company last week" or worse, "Does anybody know who wrote this code?"
Predictability.
It is important to predict accurately how long it will take to
develop the software product. That means estimating
accurately how long it will take to produce each part of it. A
good process will help us do this. The process helps lay out
the steps of development. Furthermore, consistency of process
allows us to learn from the designs of other projects.
Repeatability.
If a process is discovered to work, it should be replicated in
future projects. Ad-hoc processes are rarely replicable unless
the same team is working on the new project. A closely related
issue, is that of process re-use. It is a huge waste and
overhead for each project to produce a process from scratch. It
is much faster and easier to adapt an existing process
Quality.
Quality in this case may be defined as the product's fitness for
its purpose. One goal of a defined process is to enable
software engineers to ensure a high quality product. The
process should provide a clear link between a customer's
desires and a developer's product.
Improvement.
No one would expect their process to reach perfection and
need no further improvement itself. A goal of our defined
process must then be to identify and prototype possibilities for
improvement in the process itself.
Tracking.
A defined process should allow the management, developers,
and customer to follow the status of a project. Tracking is the
flip side of predictability. It keeps track of how good our
predictions are, and hence how to improve them.
 What is a software process model?
 A simplified representation of a software process, presented from
a specific perspective.
 Examples of process perspectives are
 Workflow perspective - sequence of activities;
 Data-flow perspective - information flow;
 Role/action perspective - who does what.
 Generic process models
 Waterfall;
 Iterative development;
 Component-based software engineering.
 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.
Activity cost distribution
Waterfall model
0 25 50 75 100

Specification Design Development Integ ration and testing

Iterative development

0 25 50 75 1 00

Specification Iterative development System testing

Component-based software eng ineering

0 25 50 75 1 00

Specification Development Integ ration and testing

Development and evolution costs for long-lifetime syst ems

0 10 200 30 400

System development System evolution

 Product development costs

0 25 50 75 100

Specification Development System testing

 What are software engineering
methods?
 Structured approaches to software development which include
system models, notations, rules, design advice and process
guidance.
 Model descriptions
 Descriptions of graphical models which should be produced;
 Rules
 Constraints applied to system models;
 Recommendations
 Advice on good design practice;
 Process guidance
 What activities to follow.
What is CASE (Computer-Aided Software
Engineering)
 Software systems that are intended to provide automated
support for software process activities.
 CASE systems are often used for method support.
 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 acceptable.
 Maintainability
 Software must evolve to meet changing needs;
 Dependability
 Software must be trustworthy;
 Efficiency
 Software should not make wasteful use of system resources;
 Acceptability
 Software must accepted by the users for which it was designed. This
means it must be understandable, usable and compatible with other
systems.
 Software Qualities
Qualities are goals in the practice of software
engineering, and directly relate to many of the guiding
principles.

External vs. Internal qualities

Product vs. Process qualities
 Software Qualities
Critical Quality Attributes Other Attributes
Correctness  Completeness
Maintainability  Compatibility

Dependability  Portability
 Internationalization
Usability
Understandability
Reliability
 Scalability
 Robustness
 Testability
 Reusability
 Customizability
 Efficiency
 External vs. Internal Qualities
External qualities are visible to the user
reliability, usability, efficiency (maybe), robustness, scalability

Internal qualities are the concern of developers

they help developers achieve external qualities
verifiability, maintainability, extensibility, evolvability, adaptability,
portability, testability, reusability
 Product vs. Process Qualities
Product qualities concern the developed artifacts
maintainability, performance, understandability,
Process qualities deal with the development activity
products are developed through process
maintainability, productivity, predictability
 Some Software Qualities
Correctness
ideal quality
established w.r.t. the requirements/specification
absolute

Reliability
statistical property
probability that software will operate as expected over a given
period of time/inputs
relative
 Some Software Qualities (cont.)
Robustness
“reasonable” behavior in unforeseen circumstances
subjective
a specified requirement is an issue of correctness;
an unspecified requirement is an issue of robustness
Usability
ability of end-users to easily use software
extremely subjective
 Some Software Qualities (cont.)
Understandability
ability of developers to easily understand produced artifacts
internal product quality
subjective

Verifiability
ease of establishing desired properties
performed by formal analysis or testing
internal quality
 Some Software Qualities (cont.)
Performance
equated with efficiency
assessable by measurement, analysis, and simulation

Evolvability
ability to add or modify functionality
addresses adaptive and perfective maintenance
problem: evolution of implementation is too easy
evolution should start at requirements or design
 Some Software Qualities (cont.)
Reusability
ability to construct new software from existing pieces
must be planned for
occurs at all levels: from people to process, from
requirements to code
Interoperability
ability of software (sub)systems to cooperate with others
easily integratable into larger systems
common techniques include APIs, distributed programming
interfaces (CORBA, DCOM), plug-in protocols, etc.
 Some Software Qualities (cont.)
Scalability
ability of a software system to grow in size while maintaining
its properties and qualities
assumes maintainability and evolvability
goal of component-based development
 What are the key challenges facing
software engineering?
 Heterogeneity, delivery and trust.
 Heterogeneity
 Developing techniques for building software that can cope with
heterogeneous platforms and execution environments;
 Delivery
 Developing techniques that lead to faster delivery of software;
 Trust
 Developing techniques that demonstrate that software can be trusted by its
users.
 Key points
 Software engineering is an engineering discipline that is
concerned with all aspects of software production.
 Software products consist of developed programs and
associated documentation. Essential product attributes are
maintainability, dependability, efficiency and usability.
 The software process consists of activities that are involved in
developing software products. Basic activities are software
specification, development, validation and evolution.
 Methods are organised ways of producing software. They include
suggestions for the process to be followed, the notations to be
used, rules governing the system descriptions which are
produced and design guidelines.
 Key points
 CASE tools are software systems which are designed to support
routine activities in the software process such as editing design
diagrams, checking diagram consistency and keeping track of
program tests which have been run.
 Software engineers have responsibilities to the engineering
profession and society. They should not simply be concerned
with technical issues.
 Professional societies publish codes of conduct which set out the
standards of behaviour expected of their members.
THANK YOU