Unit 1.

The Nature of Software & Software Engineering

Chapter includes:
The Nature of Software, The Changing Nature of Software, Defining the Discipline, Software
engineering process, Software engineering practice, Software Myths

The Nature of Software

Software is 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.
Now day’s software is playing a dual role, it acts as product and sometimes it act as vehicle for
delivering a product.

If we consider software as product, it gives the computing potential embodied by computer

hardware or sometimes we say by a network of computers that are accessible by local hardware.
Such a product may be in a mobile phone or installed within a mainframe computer.
If we consider software as a vehicle it is used to deliver the product. Software acts as operating
systems, networks, and is used for the creation and control of other programs. The most important
product delivered by the software is information.
Software transforms personal data so that the data can be more useful in a local context. The
software can be used to manage business information to enhance competitiveness. Software
provides a gateway to worldwide information networks for example Internet.
The role of computer software is tremendously changed in the last half – century. These changes
are due to dramatic improvements in hardware’s, changes in computing architectures, vast increase
in memory capacity, and availability of exotic input and output devices. All these together make
possible a more sophisticated and complex computer –based systems.

now the software industry become a dominant factor of economy in the industrial area because the
lone programmers are replaced by teams of software specialists, each focusing on one part of the
technology required to deliver a complex application and they have to answer the same questions
that are asked while designing modern computer-based systems.
• Why does it take so long to get software finished?
• Why are development costs so high?
• Why can’t we find all errors before we give the software to our customers?
• Why do we spend so much time and effort maintaining existing programs?
• Why do we continue to have difficulty in measuring progress as software is being developed and
maintained?

1
Definition of Software
Following are the definitions find in the books of software engineering.

1. Software is instructions (computer programs) that when executed provide desired features,
function, and performance.
2. Software is data structures that enable the programs to adequately manipulate information.
3. Software is descriptive information in both hard copy and virtual forms that describes the
operation and use of the programs.

Characteristics of Software

Software is a logical rather than a physical system element. Therefore, software has
characteristics that are considerably different than those of hardware:

1. Software is developed or engineered; it is not manufactured in the classical sense.

There are some similarities between software development and hardware manufacturing, but these
two things are different. In both activities, high quality is achieved through good design, but the
manufacturing of hardware can introduce quality problems that are not for software. 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. 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.”

Figure (a) show failure rate functioning of hardware against time. This graphical representation is
also known as “bathtub curve”. If we look at the graph we find that hardware is relatively high
failure rates early in its life. These failures are often due to design or manufacturing defects. These
defects are corrected and the failure rate drops to a somewhat steady-state level for some time. 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. And we say that, the hardware begins to wear out.

But in case of Software environmental maladies are not cause to wear out as in case of hardware.
Hence the failure rate curve for software should take the form of the “idealized curve” shown in
Figure (b). Undiscovered defects will cause high failure rates early in the life of software.
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!
This seeming contradiction can best be explained by considering the actual curve in figure (b).
During its life, software will undergo change. As changes are made, it is likely that errors will be

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

The difference between hardware and software is that, when a hardware component wears out, it
is replaced by a spare part. There are no software spare parts. The failure of software means 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.

Increased failure rate due

to side effects
Infromal
“Wear out”
mortality

Failure Rate
Failure Rate

Chang

Actual curve

Idealized curve

Time
Failure curve for hardware a Time
b
Failure curve for software

3. Although the industry is moving toward component-based construction, most software continues
to be custom built.
Engineering field discovered a collection of standard design components. Screw and off-the-shelf
are the only two integrated circuits out of thousands standard components that are used by
mechanical and electrical engineers while designing new systems. Purposefully the reusable
components are created and engineer can concentrate on the designing of innovative elements of
a design. Designing innovative elements is the part of hardware engineering. The reuse is a natural
part of the engineering process.

In case of the software, the concept of reusability is to be achieved on a broad scale. A software
component should be designed and implemented so that it can be reused in many different
programs. Modern reusable components involve both data and the processing that is applied to the
data, enabling the software engineer to create new applications from reusable parts. For example,
today’s interactive user interfaces are built with reusable components that enable the creation of
graphics windows, pull-down menus, and a wide variety of interaction mechanisms. The data
structures and processing detail required to build the interface are contained within a library of
reusable components for interface construction.

3
The Changing Nature of Software

Software Application Domains/ Types of computer Software

There are seven categories of computer software as listed below.
1. System Software
2. Application Software
3. Engineering/Scientific Software
4. Embedded Software
5. Product Line Software
6. Web Applications
7. Artificial intelligence software
System Software
A collection of programs written to service other programs is called system software. Some system
software like compilers, editors, and file management tasks processes complex, but determinate,
information structures. Other systems applications for example operating system components,
drivers, networking software, telecommunications processors process largely indeterminate data.
The systems software is characterized by the functions below.
1. Heavy interaction with computer hardware
2. Heavy usage by multiple users
3. Concurrent operation that requires scheduling
4. Resource sharing
5. Sophisticated process management
6. Complex data structures
7. Multiple external interfaces.

Application software
Stand-alone programs that solve a specific business need are called application software.
Applications in this area process business or technical data in a way that facilitates business
operations or management/technical decision making. In addition to conventional data processing
applications, application software is used to control business functions in real time (e.g., point-of-
sale transaction processing, real-time manufacturing process control).
Engineering/scientific software
Engineering software has 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

Embedded software
Resides within a product or system and is used to implement and control features and functions
for the end user and for the system itself. Embedded software can perform limited and esoteric
functions (e.g., key pad control for a microwave oven) or provide significant function and control
capability (e.g., digital functions in an automobile such as fuel control, dashboard displays, and
braking systems).

4
Product-line software
Product-line software designed to provide a specific capability for use by many different
customers. Product-line software can focus on a limited and esoteric marketplace (e.g.,
inventory control products) or address mass consumer markets (e.g., word processing,
spreadsheets, computer graphics, multimedia, entertainment, database management, and
personal and business financial applications).
Web applications
A Web application called “WebApps” this network-centric software category spans a wide
array of applications. In their simplest form, WebApps can be little more than a set of
linked hypertext files that present information using text and limited graphics. However,
as Web 2.0 emerges, WebApps are evolving into sophisticated computing environments
that not only provide stand- alone features, computing functions, and content to the end
user, but also are integrated with corporate databases and business applications.
Artificial intelligence software
Artificial intelligence software makes use of nonnumeric algorithms to solve complex
problems that are not amenable to computation or straightforward analysis. Applications
within this area include robotics, expert systems, pattern recognition (image and voice),
artificial neural networks, theorem proving, and game playing.

Defining the Discipline

It has been over thirty five years since the first organized, formal discussion of software
engineering as a discipline took place at the 1968 NATO (The North Atlantic Treaty
Organization) conference on Software Engineering. The term “Software engineering” is
now widely used in industry, government, and academia: hundreds of thousands of
computing professionals go by the title “Software engineering”; numerous publications,
groups and organizations, and professional conferences use the term software engineering
in their names; and there are many educational courses and programs on software
engineering. However, there are still disagreements and differences of opinion about the
meaning of the term.

The following definitions provide several views of the meaning and nature of software
engineering. Nevertheless they all possess a common thread, which states, or strongly
implies that software engineering is more than just coding. It includes quality, schedule,
and economics, and the knowledge and applications of principles and discipline.
[1] The discipline of software engineering is the ability to act in accordance with the standards
and best practices in the field of software engineering.
[2] Software engineering is a detailed study of engineering to the design,
development and maintenance of software.
[3] Software engineering was introduced to address the issues of low-quality software
projects. Problems arise when software generally exceeds timelines, budgets, and reduced
levels of quality.
It ensures that the application is built consistently, correctly, on time and on budget and
within requirements. The demand of software engineering also emerged to cater to the
immense rate of change in user requirements and environment on which application is
supposed to be working.

5
[4] Software engineering may be defined as the systematic design and development of
software products and the management of the software process. Software engineering has
as one of its primary objectives the production of programs that meet specifications, and
are demonstrably accurate, produced on time, and within budget.

Software engineering process

(A process is a collection of activities, actions, and tasks that are performed when some
work product is to be created.

An activity strives to achieve a broad objective (e.g., communication with stakeholders)

and is applied regardless of the application domain, size of the project, complexity of the
effort, or degree of rigor with which software engineering is to be applied.

An action (encompasses a set of tasks that produce a major work product (e.g., an
architectural design model).

A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that
produces a tangible outcome.

In the context of software engineering, a process is not a rigid prescription for how to build
computer software. Rather, it is an adaptable approach that enables the people doing the
work (the software team) to pick and choose the appropriate set of work actions and tasks.
The intent is always to deliver software in a timely manner and with sufficient quality to
satisfy those who have sponsored its creation and those who will use it

A generic process framework for software engineering encompasses five activities:

Communication
Before we start any technical work, it is critically important to communicate and
collaborate with the customer (and other stakeholders).The intent is to understand
stakeholders’ objectives for the project and to gather requirements that help to define
software features and functions.

Planning
Designing or building a software project is a complicated task, and the planning activity
creates a “map” that helps guide team how to proceed for completion of task. The map—
called a software project plan—defines the software engineering work by describing the

1. Technical tasks to be conducted,

2. The risks that are likely,
3. The resources that will be required,
4. The work products to be produced, and
5. A work schedule.

6
Modeling

Whether you’re a landscaper, a bridge builder, an aeronautical engineer, a carpenter, or an

architect, you work with models every day. You create a “sketch” of the thing so that you’ll
understand the big picture—what it will look like architecturally, how the constituent parts
fit together, and many other characteristics. If required, you refine the sketch into greater
and greater detail in an effort to better understand the problem and how you’re going to
solve it. A software engineer does the same thing by creating models to better understand
software requirements and the design that will achieve those requirements.

Construction
This activity combines code generation (either manual or automated) and the testing
that is required to uncover errors in the code.

Deployment. The software (as a complete entity or as a partially completed increment) is

delivered to the customer who evaluates the delivered product and provides feedback based
on the evaluation.

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:

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.

Risk management—assesses risks that may affect the outcome of the project or the quality
of the product.

Software quality assurance—defines and conducts the activities required to ensure

software quality.

Technical reviews—access software engineering work products in an effort to uncover

and remove errors before they are propagated to the next activity.

Measurement—defines and collects process, project, and product measures that assist the
team in delivering software that meets stakeholders’ needs; can be used in conjunction with
all other framework and umbrella activities.

Software configuration management—manages the effects of change throughout the

software process.
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.

7
Software engineering practice

The skeleton architecture for software engineering work is established with the help of the
activities - communication, planning, modeling, construction, and deployment—and
umbrella activities

The Essence of Practice

The book ‘How to Solve it’ by George Polya given the essence of software engineering
practice as
1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance).

Understand the problem. It’s sometimes difficult to admit, but most of us suffer from
hubris when we’re presented with a problem. We listen for a few seconds and then think,
Oh yeah, I understand, let’s get on with solving this thing. Unfortunately, understanding
isn’t always that easy. It’s worth spending a little time answering a few simple questions:

• Who has a stake in the solution to the problem?

• What are the unknowns? What data, functions, and features are required to properly
solve the problem?
• Can the problem be compartmentalized? Is it possible to represent smaller problems that
may be easier to understand?
• Can the problem be represented graphically? Can an analysis model be created?

Plan the solution. Now you understand the problem (or so you think) and you can’t wait to
begin coding. Before you do, slow down just a bit and do a little design:

• Have you seen similar problems before? Are there patterns that are recognizable in a
potential solution? Is there existing software that implements the data, functions, and
features that are required?
• Has a similar problem been solved? If so, are elements of the solution reusable?
• Can subproblems be defined? If so, are solutions readily apparent for the subproblems?
• Can you represent a solution in a manner that leads to effective implementation? Can a
design model be created?

Carry out the plan. The design you’ve created serves as a road map for the system you
want to build. There may be unexpected detours, and it’s possible that you’ll discover an
even better route as you go, but the “plan” will allow you to proceed without getting lost.
• Does the solution conform to the plan? Is source code traceable to the design model?
• Is each component part of the solution provably correct? Have the design and code been
reviewed, or better, have correctness proofs been applied to the algorithm?

Examine the result. You can’t be sure that your solution is perfect, but you can be sure that
you’ve designed a sufficient number of tests to uncover as many errors as possible.

8
• Is it possible to test each component part of the solution? Has a reasonable testing strategy
been implemented?
• Does the solution produce results that conform to the data, functions, and features that
are required? Has the software been validated against all stakeholder requirements? It
shouldn’t surprise you that much of this approach is common sense. In fact, it’s reasonable
to state that a commonsense approach to software engineering will never lead you astray.

Software Myths
Software myths are of three types as listed below.
1. Management Myths
2. Customer Myths
3. Practitioner ‘s Myths
1. 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. Like a
drowning person who grasps at a straw, a software manager often grasps at belief in a
software myth, if that belief will lessen the pressure (even temporarily).

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

Myth: If we get behind schedule, we can add more programmers and catch up (sometimes
called the “Mongolian horde” concept).
Reality: Software development is not a mechanistic process like manufacturing. In the words of
Brooks [Bro95]: “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.

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.

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.

9
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, an ambiguous “statement of objectives” is a recipe for disaster. Unambiguous
requirements (usually derived iteratively) are developed only through effective and
continuous communication between customer and developer.

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 upheaval that requires additional resources and major design modification.

Practitioner’s myths:
Myths that are still believed by software practitioners have been fostered by over 50 years
of programming culture. During the early days, programming was viewed as an art form.
Old ways and attitudes die hard.

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.

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 (described in
Chapter 15) are a “quality filter” that have been found to be more effective than testing for
finding certain classes of software defects.

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.

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.

Many software professionals recognize the fallacy of the myths just described. Regrettably,
habitual attitudes and methods foster poor management and technical practices, even when
reality dictates a better approach. Recognition of software realities is the first step toward
formulation of practical solutions for software engineering.

10