B.

Sc IT SY Software Engineering

Unit I
Introduction to Software Engineering
1.1 The Evolving Role 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. Whether it resides within a cellular 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.
• 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). The role
of computer software has undergone significant change over a time span of little more
than 50 years. Dramatic improvements in hardware performance, profound changes in
computing architectures, vast increase in memory and storage capacity, and a wide
variety of exotic input and output options have all precipitated more sophisticated and
complex computer-based systems.

1.2 Software
• Definition of Software might take the following form:
• Software is (1) instructions (computer programs) that when executed provide desired
function and performance, (2) data structures that enable the programs to adequately
manipulate information, and (3) documents that describe the operation and use of the
programs.
1.3 Software Characteristics
• Software is a logical rather than a physical system element. Therefore, software has
characteristics that are considerably different than those of hardware:
• Software is developed or engineered, it is not manufactured in the classical sense:
Although some similarities exist between software development and hardware
B. Sc IT SY Software Engineering
manufacture, 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 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 means that software projects cannot be managed as if
they were manufacturing projects.
2 Software doesn't "wear out.”: Fig 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 (ideally, quite low) for some period of time. As time passes, however,
the failure rate rises again as hardware components suffer from the cumulative effects
of dust, vibration, extreme temperature, and many other environmental maladies. Stated
simply, the hardware begins to wear out.

Fig 1.1 Failure curve for hardware

• Software is not susceptible to the environmental maladies that cause hardware to
wear out. In theory, therefore, 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
 B. Sc IT SY Software Engineering
idealized curve is a gross oversimplification of actual failure models for software.
However, the implication is clear—software doesn't wear out.

Fig 1.2 Idealized and actual failure curves for software

• As changes are made, it is likely that some new defects will be introduced, causing the
failure rate curve to spike. 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.
3 Although the industry is moving toward component-based assembly, most software
continues to be custom built. : Consider the manner in which the control hardware for a
computer based product is designed & built. The design engineer draws a simple
schematic of the digital circuitry, does some fundamental analysis to assure that proper
function will be achieved, and then goes to the shelf where catalogs of digital components
exist. As an engineering discipline evolves, a collection of standard design components is
created. 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. (Same / similar components are used to create different
software)

CHARACTERISTICS OF GOOD SOFTWARE

While developing any kind of software product, the first question in any developer's mind is,
 B. Sc IT SY Software Engineering
“What are the qualities that good software should have?" Well before going into technical
characteristics, I would like to state the obvious expectations one has from any software.
First and foremost, a software product must meet all the requirements of the customer or
end-user. Also, the cost of developing and maintaining the software should be low. The
development of software should be completed in the specified time-frame.
Well these were the obvious things which are expected from any project (and software
development is a project in itself). Now lets take a look at Software Quality factors. These set
of factors can be easily explained by Software Quality Triangle.
The three characteristics of good application software are :-
1) Operational Characteristics

2) Transition Characteristics

3) Revision Characteristics

Characteristics of a Good Software

What Operational Characteristics should a software have ?

These are functionality based factors and related to 'exterior quality' of software. Various
Operational Characteristics of software are :
a) Correctness: The software which we are making should meet all the specifications
stated by the customer.
b) Usability/Learnability: The amount of efforts or time required to learn how to use
thesoftware should be less. This makes the software user-friendly even for IT- illiterate
people.
c) Integrity : Just like medicines have side-effects, in the same way a software may have a
side-effect i.e. it may affect the working of another application. But a
quality software should not have side effects.

d) Reliability : The software product should not have any defects. Not only this, it shouldn't
fail while execution.
 B. Sc IT SY Software Engineering
E)Efficiency : This characteristic relates to the way software uses the available resources. The
software should make effective use of the storage space and execute command as per
desired timing requirements.
f) Security : With the increase in security threats nowadays, this factor is gaining importance.

The software shouldn't have ill effects on data / hardware. Proper measures should be taken
to keep data secure from external threats.
g) Safety : The software should not be hazardous to the environment/life.

What are the Revision Characteristics of software ?

These engineering based factors of the relate to 'interior quality' of the software like
efficiency, documentation and structure. These factors should be in-build in any good
software. Various Revision Characteristics of software are :-
a) Maintainability : Maintenance of the software should be easy for any kind of user.
b) Flexibility : Changes in the software should be easy to make.

c) Extensibility : It should be easy to increase the functions performed by it.

d) Scalability : It should be very easy to upgrade it for more work(or for more number of
users).

e) Testability : Testing the software should be easy.

f) Modularity : Any software is said to made of units and modules which are independent
of each other. These modules are then integrated to make the final software. If the software
is divided into separate independent parts that can be modified, tested separately, it has
high modularity.
Transition Characteristics of the software :
a) Interoperability : Interoperability is the ability of software to exchange information
withother applications and make use of information transparently.
b) Reusability : If we are able to use the software code with some modifications for
different purpose then we call software to be reusable.
c) Portability : The ability of software to perform same functions across all environments
 B. Voc FY CBCS Software Engineering & Testing
and platforms, demonstrate its portability.
Importance of any of these factors varies from application to application. In systems where
human life is at stake, integrity and reliability factors must be given prime importance. In any
business related application usability and maintainability are key factors to be considered.
Always remember in Software Engineering, quality of software is everything, therefore try to
deliver a product which has all these characteristics and qualities.

1.4 Software Applications

• Today following categories of computer software present continuing challenges for
software engineers:
 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) process largely
indeterminate data.
 Application software: Application software consists of standalone programs that solve
a specific business need. Applications in this area process business or technical data in
a way that facilitates business operations or managements / 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).

 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.
 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.
Embedded software can perform very limited and esoteric functions (e.g., keypad
B. Voc FY CBCS Software Engineering & Testing
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).
 Product line software: Designed to provide 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,
personal and business financial applications)
 Web-based software: “WebApps” span 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 e-commerce and B2B
applications grow in importance. WebApps are evolving into sophisticated computing
environments that not only provide standalone features, computing functions and
content to the end user, but also are integrated with corporate databases and business
applications.

 Artificial intelligence software: Artificial intelligence (AI) software makes use of

nonnumerical algorithms to solve complex problems that are not amenable
(responsive) 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.

1.5 Software Crisis on the Horizon

• Software crisis is a term used in the early days of computing science for the difficulty
of writing useful and efficient computer programs in the required time. The software
crisis was due to the rapid increases in computer power and the complexity of the
problems that could not be tackled. With the increase in the complexity of the software,
many software problems arose because existing methods were insufficient.
• The major cause of the software crisis is that the machines have become several
orders of magnitude more powerful ! To put it quite directly: as long as there were no
machines, programming was no problem at all; when we had a few weak computers,
B. Voc FY CBCS Software Engineering & Testing
programming became a mild problem, and now we have vast computers, programming
has become an equally vast problem.
• The causes of the software crisis were linked to the overall complexity of hardware
and the software development process. The main cause is that improvements in
computing power had outpaced the ability of programmers to effectively utilize
those capabilities.
• Various processes and methodologies have been developed over the last few decades
to improve software quality management such as procedural programming and
object-oriented programming. However software projects that are large,
complicated, poorly specified, and involve unfamiliar aspects, are still vulnerable to
large, unanticipated (unexpected) problems.

1.6 Software Evolution

• The process of developing a software product using software engineering principles
and methods is referred to as Software Evolution. This includes the initial development
of software and its maintenance and updates, till desired software product is
developed, which satisfies the expected requirements.
• Evolution starts from the requirement gathering process. After which developers create
a prototype of the intended software and show it to the users to get their feedback at
the early stage of the software product development. The users suggest changes, on
which several consecutive updates and maintenance keep on changing too. This
process changes to the original software, till the desired software is accomplished.
• Even after the user has the desired software in hand, the advancing technology and the
changing requirements force the software product to change accordingly. Re-creating
software from scratch and to go one-on-one with the requirement is not feasible. The
only feasible and economical solution is to update the existing software so that it
matches the latest requirements.
B. Voc FY CBCS Software Engineering & Testing

Fig 1.3 Software Evolution

1.7 Software Myths
• There are three categories
 Management Myth
 Customer Myths
 Practitioners Myth
1.7.1 Management Myth
• Managers with software responsibility like mangers in most disciplines, are often under
pressure to maintain budgets, keep schedules from slipping, and improve quality. Like
a drowning person who grasp at a straw, a software managers often grasps at belief
in a software myth.
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 standard may very well exists, 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.”
2. Myth: My people have state-of-the-art software development tools, after all, we buy
them the newest computers.
• Reality: It takes much more than the latest model mainframe, workstation, or PC to do
B. Voc FY CBCS Software Engineering & Testing
high-quality software development. Computer Aided Software Engineering (CASE) tool
are more important than hardware for achieving good quality and productivity, yet the
majority of software developers still do not use them effectively.

3. 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. Adding
people to a late software project makes it later. 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 planned & well-coordinated manner.
4. Myth: If I decide to outsource the 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 always struggle when it outsources software projects.
1.7.2 Customer Myths
• The customer believes myths about software because software managers and
practitioners do little to correct misinformation. Myths lead to false expectations and
ultimately, dissatisfaction with the developer.
1. Myth: A general statement of objectives is sufficient to begin writing programs we can
fill in the details later.
• Reality: 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.
2. Myth: Project requirement continually change, but change can be easily
accommodated because software is flexible
• Reality: It true that software requirement change, but the impact of change varies with
the time at which it is introduced. Fig 1.4 illustrates the impact of change.
B. Voc FY CBCS Software Engineering & Testing

Fig 1.4 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 disturbance that requires
additional resources and major design modification, that is, additional cost.
• Changes in function, performance, interface, or other characteristics during
implementation (code & test) have separate impact on cost. Change, when requested
after software is in production, can be over an order magnitude more expensive than
the same change requested earlier.

1.7.3 Practitioner’s Myths

• Myths that are still believed by software practitioners have been fostered by 50 years
of programming culture. During the early days of software, programming was viewed
as an art form.
1. Myth: Once we write the program and get it to work, our job is done.
• Reality: Someone once said, “The sooner you begin ‘writing code’, the longer it will take
you to get done.” Industry data indicates 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
B. Voc FY CBCS Software Engineering & Testing
time.
2. Myth: Until I get the program “running” I have no way of assembling its quality.
• Reality: One of the most effective software quality assurance mechanism can be
applied from the inception of a project - the formal technical review. Software reviews
are a “qualify filter” that have been found to be more effective than finding certain
classes of software defects.
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. Documentation provides a foundation for successful engineering and,
more important, guidance for software support.
4. Myth: Software engineering will make us create voluminous and unnecessary
documentation and will always slow us down
• Reality: 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.