Mehran University of Engineering and Technology,

Jamshoro
Department of Computer Systems Engineering

Software Engineering
(First Term Final Year, 07 Batch)

By
Prof Dr Mukhtiar Ali Unar

1
Books:
• Pressman R.S., "Software Engineering - A
Practitioner's Approach”, 7th Edition or Latest,
McGraw-Hill Inc., ISBN: 0073655783.
• Sommerville I., "Software Engineering", 8th
Edition or Latest, Pearson Education, ISBN:
978-0-321-31379-9.

(The soft copies of these books are available

with me. You may get one copy, if interested).

2
Chapter 01

Basic Concepts

3
 Basic Concepts
• Computer Software is the product that software
engineers design and build.
• Software is
– instructions (computer programs) that when executed
provide desired function and performance,
– data structures that enable the programs to adequately
manipulate information.
• Software engineers are concerned with
developing software products, i.e., software
which can be sold to a customer.

4
Software Engineering (IEEE Definition):
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).
• Software Engineering is a layered technology

tools
methods
life-cycle model
a “quality” focus
Software Products:
• Generic products: These are stand-alone systems that are
produced by a development organization and sold on the
open market to any customer who is able to buy them.
Examples of this type of product include software for PCs
such as databases, word processors, drawing packages and
project management tools.
• Customised (or bespoke) products: These are systems which
are commissioned by a particular customer. A software
contractor develops the software especially for that
customer. Examples of this type of software include control
systems for electronic devices, systems written to support a
particular business process and air traffic control systems.

6
Where we can find Software?

7
Where we can find Software?

8
Where we can find Software?

9
Where we can find Software?

10
 Software Engineering Life Cycle

The common software development phases are the

following:
• Specification / Requirements
Documenting the usage scenarios and
deriving the static domain model.
• Design
Assigning responsibilities to objects and
specifying the dynamics of their interactions
under different usage scenarios.

11
 Software Engineering LifeCycle (cont.)

• Implementation
Encoding the design in a programming
language.
• Testing
Individual classes/components (unit testing) and
entire system (integration testing).
• Operation and Maintenance
Running the system; Fixing bugs and adding new
features.

12
 The Role of Software
• Software has a dual role
– It is a product
– A 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.
• 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).

13
• Software Process: There are various software
development approaches defined and designed
which are used/employed during development
process of software, these approaches are also
referred as "Software Development Process Models".
Each process model follows a particular life cycle in
order to ensure success in process of software
development.
Process
Activities

Software Software Software Software

Specifications Development Validation Evolution
14
 Software Process Model
• A software process model (also called Life Cycle
Model) is a simplified description of a software
process that presents one view of that process.
• The General Model
– Software process models describe phases of the software
cycle and the order in which those phases are
executed. There are tons of models, and many companies
adopt their own, but all have very similar patterns. The
general, basic model is shown below:

Requirements Design Implementation Testing

15
– Each phase produces deliverables required by the next
phase in the life cycle. Requirements are translated into
design. Code is produced during implementation that is
driven by the design. Testing verifies the deliverable of the
implementation phase against requirements.

16
 Adaptability of Models

• A life-cycle model (but not build-and-fix) will

always be applied on every project
BUT
• The most suitable model and details of phases
(e.g. degree of rigor) will vary based on:
 Type of project (scientific, embedded, business, etc.)
 Characteristics of the project
 Common sense judgment
 Experience of the project team
• Processes can be lightweight or heavyweight
(little or lots of administration overhead and
control

17
 Software Development Paradigms (General
Models)
The Waterfall Model
• Waterfall Model (also known as Linear Sequential Model)
was first Process Model to be introduced and followed
widely in Software Engineering to ensure success of the
project.
• In "The Waterfall" approach, the whole process of software
development is divided into separate process phases.
• The phases in Waterfall model are: Requirement
Specifications phase, Software Design, Implementation and
Testing & Maintenance. All these phases are cascaded to
each other so that second phase is started as and when
defined set of goals are achieved for first phase and it is
signed off, so the name "Waterfall Model".
• All the methods and processes undertaken in Waterfall
Model are more visible.

18
Waterfall Model

19
 The Stages of Waterfall Model
Stage I: Requirement Analysis & Definition:
All possible requirements of the system to be developed
are captured in this phase. Requirements are set of
functionalities and constraints that the end-user (who
will be using the system) expects from the system.
The requirements are gathered from the end-user by
consultation, these requirements are analyzed for
their validity and the possibility of incorporating the
requirements in the system to be development is also
studied. Finally, a Requirement Specification
document is created which serves the purpose of
guideline for the next phase of the model.

20
 The Stages of Waterfall Model

Stage II: System & Software Design:

Before a starting for actual coding, it is highly important
to understand what we are going to create and what
it should look like? The requirement specifications
from first phase are studied in this phase and system
design is prepared. System Design helps in specifying
hardware and system requirements and also helps in
defining overall system architecture. The system
design specifications serve as input for the next
phase of the model.

21
 The Stages of Waterfall Model
• Phase III: Implementation & Unit Testing:
On receiving system design documents,
the work is divided in modules/units and
actual coding is started. The system is
first developed in small programs called
units, which are integrated in the next
phase. Each unit is developed and tested
for its functionality; this is referred to as
Unit Testing. Unit testing mainly verifies
if the modules/units meet their
specifications.
22
 The Stages of Waterfall Model
• Phase IV: Integration & System Testing:
As specified above, the system is first divided in units which are
developed and tested for their functionalities. These units are
integrated into a complete system during Integration phase
and tested to check if all modules/units coordinate between
each other and the system as a whole behaves as per the
specifications. After successfully testing the software, it is
delivered to the customer.

Phase V: Operations & Maintenance: This phase of "The

Waterfall Model" is virtually never ending phase (Very long).
Generally, problems with the system developed (which are not
found during the development life cycle) come up after its
practical use starts, so the issues related to the system are
solved after deployment of the system. Not all the problems
come in picture directly but they arise time to time and needs
to be solved; hence this process is referred as Maintenance.
23
 Advantages of the Waterfall Model
• Easy to explain to the user.
• Stages and activities are well defined.
• Helps to plan and schedule the project.
• Verification at each stage ensures early detection of
errors / misunderstanding.

24
 Disadvantages/limitations of the Waterfall
Model
• Requires that requirements are well-specified and
unchanging
• Assumes a sequential flow, which real projects rarely
follow.
• Working version becomes available very late (after
coding).
• Developers may have to wait due to dependent tasks.

Conclusion:
• When the requirements are well understood, it is
reasonable to use this approach.

25
 The Prototyping Model
• Often, a customer defines a set of general objectives
for software but does not identify detailed input,
processing, or output requirements. In these, and
many other situations, a prototyping paradigm may
offer the best approach.
• The prototyping paradigm begins with requirements
gathering. Developer and customer meet and define
the overall objectives for the software, identify
whatever requirements are known, and outline areas
where further definition is mandatory. A "quick
design" then occurs.

26
 The Prototyping Model
• The quick design leads to the construction of
a prototype. The prototype is evaluated by the
customer/user and used to refine
requirements for the software to be
developed. Iteration occurs as the prototype is
tuned to satisfy the needs of the customer,
while at the same time enabling the developer
to better understand what needs to be done.

27
Prototyping is comprised of the following steps:
– Requirements Definition/Collection. Similar to the
phase I of the Waterfall Model, but not as
comprehensive. The information collected is usually
limited to a subset of the complete system
requirements.
– Design. Once the initial layer of requirements
information is collected, or new information is
gathered, it is rapidly integrated into a new or
existing design so that it may be folded into the
prototype.
– Prototype Creation/Modification. The information
from the design is rapidly rolled into a prototype.
This may mean the creation/modification of paper
information, new coding, or modifications to existing
coding.

28
 The Prototyping Model
• Assessment. The prototype is presented to the
customer for review. Comments and suggestions
are collected from the customer.
• • Prototype Refinement. Information collected from
the customer is digested and the prototype is
• refined. The developer revises the prototype to
make it more effective and efficient.
• • System Implementation. In most cases, the system
is rewritten once requirements are understood.
Sometimes, the Iterative process eventually
produces a working system that can be the
cornerstone for the fully functional system.
29
30
The waterfall model with prototyping
31
Advantages of the Prototyping Model
• Misunderstandings, ambiguities and missing
functions may be identified.
• User sees the model at an early stage.
• The user may ask for the finished product via
“a few fixes” to the prototype.
Disadvantages of the Prototype Model:
• Prototyping can lead to false expectations.
• Prototyping can lead to poorly designed
systems.
32
 The Prototyping Model

Conclusion:
• When requirements are not well understood,
it may be reasonable to use this approach.
• A prototype’s purpose is to understand
requirements. A better (good quality) product
must be subsequently developed.

33
 Rapid Application Development (RAD)
• The main objective of RAD is to cut
development time and expense by involving
users in every phase of systems development.
• Because it is a continuous process, RAD allows
the development team to make necessary
modifications quickly, as the design evolves.

34
35
• Advantages of RAD:
– Systems can be developed more quickly with significant
cost savings.
– Automated tools are used to facilitate construction of the
software.
– Suitable for those projects which are scalable.
• Disadvantages of RAD:
– The system might work in the short time, but the
corporate and long term objectives of the system might
not be met.
– Accelerated time cycle might allow less time to develop
quality, consistency and design standards.
• Conclusion: RAD can be attractive if a business
application can be modularized. However, the
organization must understand the possible
risks.

36
 Evolutionary Models
• These models emphasize that the systems
should evolve with time.
• Evolutionary models are iterative. They are
characterized in a manner that enables
software engineers to develop increasingly
more complete versions of the software.
• Some popular Evolutionary models are:
– The incremental Model
– The Spiral Model
– The WINWIN spiral model
– The Concurrent Development Model
37
 The Incremental Model:
• The incremental model combines elements of the
Linear Sequential Model (applied repetitively) with
the iterative philosophy of prototyping.
• Delivers software in increments, each increment is a
working product and adds to the functionality of the
previous increment.
• When an incremental model is used, the first
increment is often a core product. That is, basic
requirements are addressed, but many
supplementary features (some known, others
unknown) remain undelivered. The core product is
used by the customer (or undergoes detailed
review). 38
 The Incremental Model:
• As a result of use and/or evaluation, a plan is
developed for the next increment. The plan
addresses the modification of the core
product to better meet the needs of the
customer and the delivery of additional
features and functionality. This process is
repeated following the delivery of each
increment, until the complete product is
produced.

39
The Incremental Model

40
 The Incremental Model
• The incremental process model, like prototyping and
other evolutionary approaches, is iterative in nature.
• But unlike prototyping, the incremental model
focuses on the delivery of an operational product
with each increment.
• Advantages:
– Business pressure may be met.
– Technical risks may be managed.
– Fewer resources may be used to proceed.
– Client does not have to pay for entire software
together.
41
 The Incremental Model
Disadvantages:
– Increments may be difficult to define.
– Software may be difficult to maintain.

Conclusion:
When the “core” product is well understood
and increments can be easily defined, it is
reasonable to use this approach

42
 Spiral Model
• The spiral model, originally proposed by Boehm (1988), is an
evolutionary software process model that couples the
iterative nature of prototyping with the controlled and
systematic aspects of the waterfall model.
• It provides the potential for rapid development of incremental
versions of the software.
• Using the spiral model, software is developed in a series of
incremental releases. During early iterations, the incremental
release might be a paper model or prototype. During later
iterations, increasingly more complete versions of the
engineered system are produced.

43
Spiral Model

44
 Spiral Model
• Advantages
• Risks are resolved before they become problematic.
• Good for large and mission-critical projects.
• Software is produced early in the software life cycle.
• Disadvantages:
• can be costly model to use.
• Risk analysis requires highly specific expertise.
• Project success is highly dependent on the risk analysis
phase.
• Does not work well for smaller projects.
Conclusion:
When risks are high and need to be resolved, it is
reasonable to use this approach.
45
 Spiral Model
Task Regions:
• Customer communication: tasks required to
establish effective communication between
developer and customer.
• Planning: tasks required to define resources,
timelines, and other project related information.
• Risk analysis: tasks required to assess both
technical and management risks.
• Engineering: tasks required to build one or more
representations of the application.
• Construction and release: tasks required to
construct, test, install, and provide user support
(e.g., documentation and training).
46
 Spiral Model
• Customer evaluation—tasks required to obtain
customer feedback based on evaluation of the
software representations created during the
engineering stage and implemented during the
installation stage.

47
 The WINWIN Spiral Model
• The spiral model discussed previously suggests a
framework activity that addresses customer
communication. The objective of this activity is to elicit
project requirements from the customer. In an ideal
context, the developer simply asks the customer what
is required and the customer provides sufficient detail
to proceed.
• Unfortunately, this rarely happens. In reality, the
customer and the developer enter into a process of
negotiation, where the customer may be asked to
balance functionality,
• performance, and other product or system
characteristics against cost and time to market. The
best negotiations strive for a “win-win” result.

48
49
 The Concurrent Development Model
• The concurrent process model can be represented
schematically as a series of major
technical activities, tasks, and their associated states.

Concurrent Process Model 50

 4th Generation Techniques
Requirements
Gathering
Design
Testing
Implementation
using 4GL

Testing

51
 The Formal Methods Model
• Formal methods enable a software engineer to
specify, develop, and verify a computer-based system
by applying a rigorous mathematical notation.
• Ambiguity, incompleteness, and inconsistency can
be discovered and corrected more easily.
• It is likely that the formal methods approach will gain
adherents among software developers who must
build safety-critical software (e.g., developers of
aircraft avionics and medical devices) and among
developers that would suffer severe economic
hardship should software errors occur.

52
 The Rational Unified Process (RUP)
• RUP is a software engineering process in that it
describes a framework for activities leading to a
software product.
However, it is different from the other generic
processes we have discussed.
Features of RUP:
– It is a software process
– It is the product sold by IBM (formerly by rational
software).
– Supported by a large array of tools.
– Configurable
– Regularly updated.

53
 Three perspectives of RUP

• Best Practices: A set of principles which are

integrated into the process.
• Dynamic Perspective: Phases, iterations, milestones
of the process which change over time.
• Static perspective: The aspects of the process which
are present in some form in all dymanic phases:
activities, artifacts, workflows.

54
 Phases of the RUP
• Inception Phase:
– The goal is to establish a business case for the system.
– Identify all external entities (people and systems) that will
interact with the system. Define these interactions.
– Use this information to access the contribution that the
system makes to the business.
• Elaboration Phase:
– Goals of this phase include:
• To understand the problem domain
• To establish an architectural framework for the system
• To develop the project plan.
• To identify key project risks.

55
 Phases of the RUP
• Construction Phase:
– It is concerned with system design, programming
and testing.
– Parts of the system are developed in parallel and
integrated.
• Transition Phase:
– Customer delivery and feedback
• Production Phase:
– Software monitoring and support.

56
 Component-based Software Engineering (CBSE)

• This technique assumes that parts of the system already

exist. The system development process focuses on
integrating these parts rather than developing them from
scratch.
• The technical framework for a component-based process
model is provided by the object oriented technologies. The
object oriented paradigm emphasizes the creation of classes
that encapsulate both data and the algorithms used to
manipulate the data. If properly designed and implemented,
object-oriented classes are reusable across different
applications and computer-based system architectures.
• The Component-Based Development (CBD) model
incorporate many of the characteristics of the spiral model.
However, the component-based
development model composes applications from pre-
packaged software components (called classes).
57
58
 Capability Maturity Model (CMM)
• developed by the Software Engineering
Institute (SEI).
• defines key activities required at different
levels of process maturity.
• provides a measure of the global effectiveness
of a company's software engineering
practices.
• establishes five process maturity levels
that are defined in the following slide:

59
 Capability Maturity Model (CMM)
• Level 1: Initial -- The software process is characterized as
adhoc, and occasionally even chaotic. Few processes defined.
• Level 2: Repeatable -- Basic project management processes
established to track cost, schedule and functionality.
• Level 3: Defined -- Process for both management and
engineering is documented, standardized and integrated.
• Level 4: Managed – Detailed measure of the process and
product quality collected. Both are quantitatively understood
and controlled.
• Level 5: Optimizing – Continuous process improvement
enabled by quantitative feedback and testing innovative
ideas.

60
 Capability Maturity Model (CMM)
• Maturity Level 2:
– Software Configuration Management
– Software Quality Assurance.
– Subcontract Management
– Project tracking and oversight
– Software Project Planning
– Requirements Management

61
 Capability Maturity Model (CMM)
• Maturity level 3:
– Peer reviews
– Intergroup Coordination
– Integrated Software Management
– Training Program
– Organization process definition
– Organization process focus.

62
 Capability Maturity Model (CMM)
• Maturity Level 4:
– Software Quality Management
– Quantitative Process Management
• Maturity Level 5:
– Process Change Management
– Technology Change Management
– Defect prevention

63
 Software Characteristics
• Software is developed or engineered, it is not manufactured
in the classical sense.
• Software does not "wear out."

Hardware Failure Rate versus Time

infant
wear
mortality
out
failure rate

time
Bath tub Curve (Hardware) 64
 Software Failure Curve (Ideal)

defect
removal
failure rate

residual
defects
(~constant)

time
65
 Software Failure Curve (Actual)

Huh?
failure rate

time 66
 Software Characteristics (cont.)

• Although the industry is moving toward

component based assembly, most software
continues to be custom-built.

67
 Software Engineering Crisis
• Software failures receive a lot more publicity
than software engineering success stories.
• The software crisis predicted thirty years ago
has never materialized and software engineering
successes now outnumber the failures.
• The problems that afflict software development
are more likely to be associated with how to
develop and support software properly, than
with simply building software that functions
correctly.
68
 Software Engineering Myths
• Software standards provide software
engineers with all the guidance they need.
• People with modern computers have all the
software development tools they need.
• Adding people is a good way to catch up
when a project is behind schedule.
• Giving software projects to outside parties to
develop solves software project management
problems.

69
 Software Engineering Myths

• A general statement of objectives from the

customer is all that is needed to begin a
software project.
• Project requirements change continually and
change is easy to accommodate in the
software design.
• Once a program is written, the software
engineer's work is finished.

70
 Software Engineering Myths

• There is no way to assess the quality of a

piece of software until it is actually running
on some machine. The only deliverable from
a successful software project is the working
program.
• Software engineering is all about the creation
of large and unnecessary documentation not
shorter development times or reduced costs.

71
 What is High Quality Software?
• It must be useful (to the original customer).
• It must be portable (work at all of the customer’s sites).
• It must be maintainable.
• It must be reliable.
• It must have integrity (produces correct results, with a high
degree of accuracy).
• It must be efficient.
• It must have consistency of function (it does what the user
would, reasonably expect it to do). It must be accessible (to
the user).
• It must have good human engineering (easy to learn and
easy to use).

72
 Applications
• System Software: System software is a collection of programs
written to service other programs.
– Some system software (e.g., compilers, editors, and file
management utilities) process complex, but determinate,
information structures.
– Other systems applications (e.g., operating system components,
drivers, telecommunications processors) process largely
indeterminate data.
• System software is characterized by:
– Heavy interaction with computer hardware.
– Heavy usage by multiple users
– Concurrent operation that requires scheduling,
resource sharing and sophisticated process
management, complex data structures and multiple
external interfaces.

73
• Real Time Software:
Software that monitors/analyzes/controls
real-world events as they occur is called
real time.
• Elements of Real Time Software include
the following:
– a data gathering component that
collects and formats information from
an external environment.
– an analysis component that
transforms information as required by
the application.
– a control/output component that
responds to the external environment.
– a monitoring component that
coordinates all other components so
that real-time response (typically
ranging from 1 millisecond to 1
second) can be maintained.

74
• Business Software
Business information processing is the
largest single software application area.
Discrete "systems" (e.g., payroll,
accounts receivable/payable, inventory)
have evolved into management
information system (MIS) software that
accesses one or more large databases
containing business information.
Applications in this area restructure
existing data in a way that facilitates
business operations or management
decision making. In addition to
conventional data processing
application, business software
applications also encompass interactive
computing (e.g., point of-sale
transaction processing).
75
• 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.
• Modern applications within the
engineering/scientific area are, however, 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.
76
• Embedded Software: Embedded software resides in
read-only memory and is used to control products
and systems for the consumer and industrial
markets.

77
• Personal Computer Software: The personal
computer software market has burgeoned
over the past two decades. Word processing,
spreadsheets, computer graphics, multimedia,
entertainment, database management,
personal and business financial applications,
external network, and database access are
only a few of hundreds of applications.

78
• 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., 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.
Hardware Software

CGI
Internet

79
• Artificial Intelligence Software: Artificial
intelligence (AI) software makes use of non-
numerical algorithms to solve complex
problems that are not amenable to
computation or straightforward analysis.

80
 Software Evolution
• Law of continuing change
– Systems must be continually adapted or they become
progressively unsatisfactory.
• Law of increasing complexity
– As system evolves its complexity increases unless work is
done to reduce the complexity.
• Law of self-regulation
– System evolution is self-regulating with its process and
product measures following near normal distributions.
• Law of conservation of Organizational Stability
– Average effective global activity rate for an evolving system
is invariant over the product lifetime.
• Law of conservation of familiarity
– As system evolves all stakeholders must maintain their
mastery of its content and behavior to achieve satisfactory
evolution

81
 Software Evolution (cont.)
• Law of continuing growth
– Functional content of system must be continually
increased to maintain user satisfaction over its lifetime.
• Law of declining quality
– System quality will appear to decline unless the system is
rigorously maintained and adapted to environment
changes.
• Feedback system law
– System evolution processes must be treated as multi-level,
multi-loop, multi-agent feedback systems to achieve
significant improvement.

82
 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.

83
 Costs of Software Engineering
• Cost of Software depends on:
– the process used
– the type of software that is being developed.
• In the waterfall approach, the costs of
specifications, design, implementation and
integration are measured separately.
– System integration and testing is the most
expensive development activity.

84
• If the software is developed using an iterative
approach, there is no hard line between
specification, design and development.
Specification costs are reduced because only a
high-level specification is produced before
development in this approach.
– Specification, design, implementation,
integration and testing are carried out in
parallel within a development activity.
However, you still need an independent
system testing activity once the initial
implementation is complete.
85
• On top of development costs, costs are also
incurred in changing the software after it has
gone into use. The costs of evolution vary
dramatically depending on the type of system.
For long-lifetime software systems, such as
command and control systems that may be
used for 10 years or more, these costs are
likely to exceed the development costs by a
factor of 3 or 4. However, smaller business
systems have a much shorter lifetime and
correspondingly reduced evolution costs.

86
 Computer Aided Software Engineering (CASE)
• It covers a wide range of different types of programs
that are used to support software process activities
such as requirements analysis, system modelling,
debugging and testing.
• The CASE tools may also include a code generator
that automatically generates source code from the
system model and some process guidance for
software engineers.

87
• Attributes of a good Software:
– Maintainability
– Dependability
– Efficiency
– Useability.

88
 Key Challenges:
• The heterogeneity challenge
• The delivery challenge
• The trust challenge

89
 Professional and Ethical Responsibility
1. Confidentiality You should normally respect the
confidentiality of your employers or clients irrespective of
whether a formal confidentiality agreement has been signed.
2. Competence You should not misrepresent your level of
competence. You should not knowingly accept work that is
outside your competence.
3. Intellectual property rights 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.
4. Computer misuse 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, say) to extremely serious (dissemination of
viruses).
90
 ACM/IEEE Code of Ethics
1. Public - Software engineers shall act consistently with the
public interest.
2. 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.
3. Product - Software engineers shall ensure that their
products and related modifications meet the highest
professional standards possible.
4. Judgment - Software engineers shall maintain integrity and
independence in their professional judgment.
5. Management - Software engineering managers and leaders
shall subscribe to and promote an ethical approach to the
management of software development and maintenance.

91
 ACM/IEEE Code of Ethics
6. Profession - Software engineers shall advance
the integrity and reputation of the profession
consistent with the public interest.
7. Colleagues - Software engineers shall be fair
to and supportive of their colleagues.
8. 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.

92