Power of Software

It is not an exaggeration if we say that, the world will

come to a standstill if all the computers on the earth
stop working.
 Nowadays, computers are used in every walk of life .
i.e education, entertainment, transportation, banking,
healthcare, and of course in all business activities
 And, in all these applications, the software is very
complex, Millions of lines of code written by
hundreds of programmers are integrated into one
package.
 If there is a single mistake committed by one
programmer, it may lead to chaos.

NOTE:
Therefore, it is the software that has now become the
lifeline of systems.
The total money spent on computer hardware and
software in the world is exceeding in US$ one trillion
every year.
And, as more and more countries and people become
computer savvy, the expenditures on software will go up.
As automation has brought in revolutionary changes in
the quality of life, the demand for more software-driven
services and products is increasing.
Ex. The ubiquitous mobile phone
 Two decades ago, the mobile phone was only for the
elite of the society. Today, it is a necessary gadget in
everyone's hand.
 Today, mobile phone is a complex technology
gadget with nearly two millions of code residing in
it.
 As the users demand more and more services
through their mobile phones, it is expected that the
software will be about 10 million lines of code in the
next few years.
This indicates how the complexity of software is
increasing day by day, as users demand more and more
facilities in their existing services.
Challenges in Software Projects
The complexity of software projects is increasing
tremendously. Organization that have operations in
different locations in different countries need
sophisticated software to manage their operations.
Example:
 Bank account holders no longer wants to go to bank
during their working hours to do any transactions.
 They need ATMs, internet banking, mobile banking,
etc. making the banking software more and more
complex.

As crime continues to increase, software now needs

to provide good security features

 This is true for mobile phone software, banking

software, e-commerce portals, etc.
 It is necessary to provide foolproof security is a very
challenging task, as evident from the increase of
virus attacks, credit card information being stolen
from the Internet and the cyber-crime.
Developing mission-critical software for a number of
applications, such as bio-medical equipment, nuclear
plants, transportation control systems, which demand
zero-defect software, is highly challenging.
 As software is gaining more prominence, the demand
for software professionals is increasing
exponentially, but there has always been a shortage
of quality professionals
 As a result, employees jump from one organization to
another, that too in the middle of the project leading
to many projects getting into trouble halfway.
Manpower attrition is one of the main challenges to be
tackled in software organizations.

 As the demand for new software products and

services increases, there is an immense pressure on
the development organizations to deliver fast.
 The time pressure is so much that the organizations
and people are unable to cope up with it.
 Unfortunately, in many cases, this is leading to the
development of software full of bugs.
Though we all want every software project to be a great
success-good quality software delivered within the time
frame and within the budget-it happens rarely.

So our aim should be to make it happen every time for

every project.

The challenges in software development are as follows:

 developing zero-defect software,
 meeting severe time constraints,
 increased complexity of the projects and
 shortage of skilled people.

Software Fiascos
Software development is considered more of an art and
less of science or engineering.
To bring software development into the realm of
engineering, a lot of research has been carried out during
the last four decades.
In spite of the research in finding out ways and means of
developing quality software, the history shows that a large
number of projects are executed very badly.
We keep reading in the newspapers about the mobile
phones have been withdrawn from the market because of
a software problem.
And about the credit card fraud, and so on and all these
incidents are known as software fiascos.

NOTE:
There are many stories in the history of software
development that teach us very important lessons.
Here, are some famous stories that the test engineers
need to keep in mind.
1. Ariane 5
On June 4, 1996, European Space Agency launched the
Ariane 5 satellite launch vehicle.
Exactly 40 seconds after lift-off at an altitude of 3700
meters, the launcher exploded and became a ball of fire.
The project, which was uninsured, costed US$
500million.

Reason
In one of the embedded systems, a software exception
caused the problem.
A 64-bit floating-point number was to be converted into a
16-bit signed integer value.
During one calculation, the converted integer value was
more than the value that can be represented by a 16-bit
signed integer.
This caused an operand error. Yes, the software exception
was handled, but badly.
The specification of the exception handling routine was to
indicate the failure on the data bus, to store the context in
the EPROM and to shut down the processor. The
processor was shut down, and this created the chaos.
The mishap can be attributed to lack of enough testing as
well as flaw in the software design, particularly in
exception handling.
This error is known as 500 million dollar software error
in the software
 Interestingly, the software used in Ariane 4 was reused in
Ariane 5, but Ariane 4 was a successful launch. The only
difference is that in Ariane 5 this calculation was not at all
required……….
The failure of this project is a lesson for every software
engineer-one line of code can cause irreparable damage.
Ariane 5 project illustrates the dangers associated with
leaving some portions of the untested code in the
software.
The test engineers need to ensure that each and every
line of the code is tested before releasing the software.

2 Patriot Missile.
During the 1991 Gulf war, an Iraqi Scud missile hit an
American army barrack killing many soldiers. An
American Patriot missile could not track and intercept
Scud missile.
The Reason
A software bug in the Patriot missile.
 Whenever the tracking system of the Patriot was
switched on, it measured the elapsed time from an
internal clock in tenths of a second.
 This value was multiplied by 10 to the time in
seconds. The calculation was performed using 24-bit
fixed-point register.
 Hence, the value of 1/10 stored in a register was
truncated to 24 bits, whereas the exact value is
0.000110011001100110011001100.....
 When the value is truncated, an error introduced and
this error accumulated over a period of time.
 The Patriot missile was switched on for about 100
hours, and so the accumulated error was 0.34 second.
Scud travelled with a speed of 1,676 meters per second,
i.e. or more than half a kilometer in 0.34seconds.
As a result, the Patriot could not intercept the Scud. This
incident indicates the care that needs to be taken, while
designing and testing mission-critical systems.

The Patriot Missile example shows how a small software

bug-accumulation of error due to rounding off a
number-can lead to a catastrophe.
3. Mars Pathfinder
The NASA mission Pathfinder landed on Mars on 4 July,
1997. The mission was successful perfect launch, a
perfect landing on Mars and a lot of important data was
sent to Earth.
After a few days, the computing system started resetting
intermittently and the important data was not being
received on Earth.
Reason:
 The on-board computer used a real-time operating
system.
 Using an exact replica of the computer on Earth, the
debugging was done to find the fault.
 Three tasks were running on the system one with
high priority, one with low priority and one with
medium priority.
 Intermittently, the task with medium priority was
running for a long time, while the task with high
priority was waiting for the task with low priority to
complete.
 task with low priority was not getting the CPU time
because a higher priority task was running.
 Meanwhile, the watchdog timer, suspecting a
deadlock, used to reset the processor.

This problem was due to a bug in the inter-task

communication module. Of course, the story
ended in a positive note, as the engineers were
able to upload a modified file on to the Pathfinder.
The story of the Pathfinder teaches us many lessons in
software development. While doing the simulation
studies, the engineers noticed such a problem before the
launch of the Pathfinder, but they thought that the
problem was due to a hardware glitch as it was observed
only a very few times
NOTE : we should not set aside the occasional problems
The engineers on Earth could analyze and rectify the bug
only because the debug code was also running on the
computer of the Pathfinder
Sometimes the debug code is very important, we should
not think that debug code is only for development, it is
very useful for maintenance as well.
NOTE:
Mars Pathfinder is an excellent example to understand the
complexity involved in testing real-time systems.
The bad things are the bad design and the approach taken
by some engineers when a problem was encountered
while testing the software in the laboratory.
The marvel is that the problem could be solved without
someone flying to the Mars to upgrade the software in
the field!

4. CT Scanner
  In a Canadian hospital, suddenly a patient
undergoing the scanning died.
 The machine was rechecked thoroughly and then
again the scanning started.
 After scanning of a few patients was completed,
another patient died.
 Randomly, patients were dying and after the
death of more than 20 patients, the defect was
identified.

Reason:
A glitch in the hardware was resetting the software.
During the short time of that resetting, the patient was
exposed to large amounts of radiation because of lack of
control on the radiation.
As a result, the patient used to die.

NOTE: The CT scanner example shows how difficult it

is even to catch a defect. A hardware defect gives rise
to a software defect and that too, it occurs
intermittently. In safety critical applications,
compromising on quality results
in loss of life even.

5. The Great Bank Robbery

Long ago, in a bank automation project, a development engineer and a
bank employee together played a simple trick:
 while calculating the interest, truncate the value to two digits and
deposit the remaining value in their own account.
For example:
 Suppose interest is calculated at 3.5% on a deposit of US$ 124.25.
 The interest will be 4.34875.
 Out of this amount, $4.34 would be credited to the actual account
holder's account
 and the balance $0.00875 to their own account.

NOTE:
A simple trick ,since amount is very small no customer will
complain to the bank.

But amount would be substantial when millions of transactions

take place every month.

This crime could not be noticed for few years.

It was detected when suddenly account was closed fearing that

they would be caught.