Chapter 1

Software and Software Engineering

1
• Software engineering is the establishment and use of
sound engineering principles in order to obtain
economically software that is reliable and works
efficiently on real machines
--- Fritz
Bauer
• The application of a systematic, disciplined, quantifiable
approach to the development, operation and maintenance
of software; that is the application of engineering to
software.
--- IEEE
2
3
4
1. Software is developed or engineered; it is not
manufactured in the classical sense.
• Although some similarities exist between software
development and hardware manufacturing, the two
activities are fundamentally different.
• In both activities, high quality is achieved through
good design, but the manufacturing phase for
hardware can introduce quality problems that are
nonexistent (or easily corrected) for software

5
• Both activities are dependent on people, but the
relationship between people applied and work
accomplished is entirely different.
• Both activities require the construction of a “product,”
but the approaches are different.

6
2. Software doesn’t “wear out.”
• Figure 1.1 depicts failure rate as a function of time for
hardware.
• The relationship, often called the “bathtub curve,”
indicates that hardware exhibits 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 (hopefully, quite low) for some period
of time.

7
Failure curve for hardware

8
• As time passes, however, the failure rate rises again as
hardware components suffer from the cumulative
effects of dust, vibration, abuse, temperature
extremes, and many other environmental maladies.
Stated simply, the hardware begins to wear out.

9
• Software is not susceptible to the environmental
maladies that cause hardware to wear out.
• The failure rate curve for software should take the
form of the “idealized curve”
• Undiscovered defects will cause high failure rates
early in the life of a program. However, these are
corrected and the curve flattens as shown.
• The idealized curve is a gross oversimplification of
actual failure models for software. However, the
implication is clear—software doesn’t wear out. But it
does deteriorate!

10
Failure curves for software

11
• Software will undergo change.
• As changes are made, it is likely that errors will be
introduced, causing the failure rate curve to spike as
shown in the “actual curve”.
• Before the curve can return to the original steady-
state failure rate, another change is requested,
causing the curve to spike again.
• Slowly, the minimum failure rate level begins to rise—
the software is deteriorating due to change.

12
• Another aspect of wear illustrates the difference between
hardware and software.
• When a hardware component wears out, it is replaced by a
spare part.
• 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, the software maintenance tasks that accommodate
requests for change involve considerably more complexity than
hardware maintenance.

13
3. Although the industry is moving toward component-
based construction, most software continues to be
custom built.
• The reusable components have been created so that
the engineer can concentrate on the truly innovative
elements of a design, that is, the parts of the design that
represent something new.
• In the hardware world, component reuse is a natural
part of the engineering process.
• In the software world, it is something that has only
begun to be achieved on a broad scale.

14
• A software component should be designed and
implemented so that it can be reused in many different
programs.
• Modern reusable components encapsulate both data
and the processing that is applied to the data,
enabling the software engineer to create new
applications from reusable parts

15
THE NATURE OF SOFTWARE
• 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, by a network of computers
that are accessible by local hardware.
Whether it resides within a mobile phone or operates inside a
mainframe computer, software is an information transformer—
producing, managing, acquiring, modifying, displaying, or
transmitting information that can be as simple as a single bit or as
complex as a multimedia presentation derived from data acquired
from dozens of independent sources.

16
• 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).

17
Software delivers the most important product of our time
— information.
1. It transforms personal data (e.g., an individual’s
financial transactions) so that the data can be more
useful in a local context;
2. It manages business information to enhance
competitiveness;
3. It provides a gateway to worldwide information
networks (e.g., the Internet), and
4. Provides the means for acquiring information in all of its
forms.

18
Software engineering layers:
It is a layered technology
Any engineering approach(including software
engineering) must rest on an organizational
commitment to Quality
TQM, Six Sigma and similar philosophies foster
a continuous process improvement culture leads
to the development of increasingly more
effective approaches to SE.
The bedrock that supports software engineering
is a Quality Focus.
19
• Software engineering methods provide the
technical how-to’s for building software
methods include a broad array of tasks that
include:
 Requirements Analysis
 Design
 Program Construction
 Testing
 Support
20
• SE tools provide automated or semi automated
support for the process and the methods.
when tools are integrated so that the
information created by one tool can be used by
another system for the support of software
development called CASE is established.

21
A Layered Technology

22
THE SOFTWARE PROCESS
Activity Action Task
 An activity strives to It encompasses Focuses on a small, but
achieve a broad objective a set of tasks that produce a well-defined objective that
Ex: communication with major work product produces a tangible outcome
Ex: architectural design Ex:conducting a unit
stakeholders
model test
 It is applied regardless
of the application
domain, size of the
project, complexity of
the effort which
software engineering is
to be applied.

23
• “Process defines who is doing what, when and how to
reach a certain goal”.

Perform
People Software Process

Software
Responsible for Project
Produces

Product

24
 Software Process

Project 1 Project 2 Project 3 Project N

Product 1 Product 2 Product N

25
• A process framework establishes the foundation for a
complete software engineering process by identifying a
small number of framework activities that are
applicable to all software projects, regardless of their
size or complexity.
• In addition, the process framework encompasses a set
of umbrella activities that are applicable across the
entire software process.
• A generic process framework for software engineering
encompasses five activities:

26
What are the five generic process framework activities?
1. Communication
• It involves heavy communication and collaboration
with customer
• Other stakeholders are businessman, end-users,
software engineers, support people
• Includes requirements gathering and other related
activities.

27
2. Planning-
• Describes the technical task to be conducted
• The risks that are likely
• Resources that will be required
• Work products to be produced
• Work schedule

28
3.Modelling
• It includes the creation of models that allow the
developer and customer to better understand
software requirements and the design that will
achieve these requirements.
• Modelling activity is composed of two software
engineering actions
Analysis Design
It includes a set of work tasks It includes a work task
Example-Requirements gathering, Data design, architectural design,
Elaboration, Negotiation, Specification interface design, component level
and Validation design that creates a design model

29
4. Construction
• This activity combines code generation either
manual or automated
• Testing that is required to uncover errors in the code.
5. Deployment
• Software as a complete entity or partially completed
increment is delivered to the customer who evaluates
the delivered product and provides feedback based on
the evaluation

30
Five generic framework activities can be used during the
Development of small programs
Creation of large web applications
Engineering of large, complex computer based systems

31
• Software engineering process framework activities are
complemented by a number of umbrella activities. In
general, umbrella activities are applied throughout a
software project and help a software team manage and
control progress, quality, change, and risk. Typical
umbrella activities include:

32
1. Software project tracking and control—
 Allows the software team to assess progress against the project
plan and take any necessary action to maintain the schedule.
2. Risk management—
 Assesses risks that may affect the outcome of the project or
the quality of the product.
3. Software quality assurance —
 Defines and conducts the activities required to ensure software
quality.
4. Technical reviews —
 Assesses software engineering work products in an effort to
uncover and remove errors before they are propagated to the next
activity.
33
5. Measurement—
Defines and collects process, project, and product
measures that assist the team in delivering software that
meets stakeholders’ needs.
6. Software configuration management—
Manages the effects of change throughout the
software process.

34
• Reusability management—defines criteria for work
product reuse (including software components) and
establishes mechanisms to achieve reusable
components.
• Work product preparation and production—
encompasses the activities required to create work
products such as models, documents, logs, forms, and
lists.

35
SOFTWARE MYTHS
•Erroneous beliefs about software and the process that is
used to build it.
•It can be traced to the earliest days of computing.

36
Management myths.
Managers with software responsibility, like managers
in most disciplines, are often under pressure to
maintain budgets,
keep schedules from slipping, and
improve quality.

37
1. Myth: 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:
• 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 adaptable?
• 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.”
38
2. Myth: If we get behind schedule, we can add more programmers and
catch up
Reality:
Software development is not a mechanistic process like manufacturing.
•“adding people to a late software project makes it later.”
•At first, this statement may seem counterintuitive. However, as new people are
added, people who were working must spend time educating the newcomers,
thereby reducing the amount of time spent on productive development
effort.
•People can be added but only in a planned and well coordinated manner.

39
3. Myth: If I decide to outsource the software project
to a third party, I can just relax and let that firm build
it.
Reality:
•If an organization does not understand how to manage
and control software projects internally, it will invariably
struggle when it outsources software projects.

40
Customer myths.
•A customer who requests computer software may be a
person at the next desk, a technical group down the hall,
the marketing/sales department, or an outside company
that has requested software under contract.
•In many cases, the customer believes myths about
software because software managers and practitioners do
little to correct misinformation.
•Myths lead to false expectations (by the customer) and,
ultimately, dissatisfaction with the developer.

41
1. Myth: A general statement of objectives is sufficient to
begin writing programs—we can fill in the details later.
Reality:
•Although a comprehensive and stable statement of
requirements is not always possible
•Unambiguous requirements are developed only through
effective and continuous communication between
customer and developer.

42
2. Myth: Software requirements continually change, but change
can be easily accommodated because software is flexible.
Reality:
It is true that software requirements change, but the impact of
change varies with the time at which it is introduced.

When requirements changes are requested early (before design

or code has been started), the cost impact is relatively small.

However, as time passes, the cost impact grows rapidly—

resources have been committed, a design framework has been
established, and change can cause disturbance that requires
additional resources and major design modification.
43
Practitioner’s myths.
1. Myth: Once we write the program and get it to work,
our job is done.
Reality:
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.

44
2. Myth: Until I get the program “running” I have no way
of assessing its quality.
Reality:
•One of the most effective software quality assurance
mechanisms can be applied from the inception of a
project—the 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.

45
3. Myth: The only deliverable work product for a
successful project is the working program.
Reality:
•A working program is only one part of a software
configuration that includes many elements.
•A variety of work products (e.g., models, documents,
plans) provide a foundation for successful engineering
and, more important, guidance for software support.

46
4. Myth: Software engineering will make us create
voluminous and unnecessary documentation and will
invariably slow us down.
Reality:
•Software engineering is not about creating documents.
•It is about creating a quality product.
•Better quality leads to reduced rework.
•And reduced rework results in faster delivery times.

47