Software Engineering

Prof. Rajib Mall

Department of Computer Science and Engineering
Indian Institute of Technology, Kharagpur

Lecture – 02
Introduction- II

In the last lecture we discussed about very basic issues and debated whether program
writing is an art or engineering. We stated that, initially every technology starts in an art
form slowly becomes a craft and then graduates into an engineering approach.

Software is no different and in the engineering approach, the past experience of large
number of program developers is systematically investigated, documented and scientific
basis techniques is provided.

(Refer Slide Time: 01:20)

Exploratory software development is the software development practice of a Novice.

Consider someone who is starting to program, just learning programming and doing
small assignments; how will he be able to develop the program: that you call as the
exploratory software development or the build and fix style of development. This is the
same style which the early programmers used, because there were no other techniques,
they had to use their intuition and develop and that is called as a build and fix style.
In this style as soon as the problem statement is given based on the understanding the
programmer starts writing the program. Normally, it’s a dirty program in the sense that it
will have a lot of bugs. As you document this development style of the build and fix, in
the form of a schematic diagram, you will curate the diagram as follows :

(Refer Slide Time: 02:58)

As soon as the problem is provided, you do the initial coding and after the initial coding
is complete, start testing and find the large number of bugs getting reported. Maybe some
of them are crash or just large number of bugs & compilation errors. Again, compile test
and examine that the errors keep on this cycle: fixing the program and testing. Keep on
doing it until you find the requirement for the program.

This is the model of an exploratory style of development and as you proceed, you will
contrast this basic style of development with the engineering style of development.

You will use the exploratory style as most of the new programmers use to develop small
programs. But if the project is nontrivial, large and requires hundreds or thousands lines
of code, it will be very difficult to debug and never complete. Even if somebody really
puts lots of effort, he will come up with a very poor quality of software.

Let’s try to investigate, why the exploratory style does not work for the larger projects
but works easily for the trivial programs.
(Refer Slide Time: 05:45)

What is wrong with the exploratory style. Understanding the plot, as the programs size
increases you develop large and larger programs and still keep using the exploratory
style or the build and fix style. You will see that for small programs we are successful
but as the program size increases, the effort, time, cost all increase exponentially. Maybe,
to develop a 100-line program it took couple of hours but to develop a 1000-line program
it took several months.

But after some size, the exploratory style just breaks down. Even if you try your best
using the exploratory style still you cannot develop after a certain size whereas the
software engineering approaches comes into action. There is almost a linear increase in
the effort, time & cost compared to the program size. So, if a 1000 lines program took
couple of hours then a 10000 lines program will take only about 10 times of that not 100
times or 1000 times.

As if there exists a machine to which we can give the problem statement and which will
come up with the code.

One very basic thing you need to remember is that in the exploratory style, the cost-
effort time increases almost exponentially whereas using software engineering principles
it’s down to almost a linear increase.
(Refer Slide Time: 08:51)

The question naturally arises what is wrong with the exploratory style, why the cost
effort time to develop increase exponentially and also break down after certain size?

The other symptoms are that: the programs are poor quality, unmaintainable and it’s
quite difficult to use the exploratory style in the team development environment whereas
in using the software engineering principles we are able to overcome this.

(Refer Slide Time: 09:49)

That is a basic question. Why in the exploratory style, there is an exponential increase in
the effort, time, cost and you try to keep that down to a linear using software engineering
principles. Is it really working here for software engineering.

(Refer Slide Time: 10:25)

It’s a very fundamental principle. As, the software engineering works whereas the
exploratory style does not.

To understand this, you need to little bit understand the human cognitive mechanism.
The long back results from Miller 1956 said that human memory can be made of two
distinct parts: one which is short term memory and the other is a long-term memory. The
short-term memory is one where you remember something for only a small duration of
time, that is may be for several seconds or just minutes whereas in long term memory
remembers you remember it for months or years.
(Refer Slide Time: 11:26)

The working of the human cognition mechanism. Let look at the watch it is 10:10, how
many hours remaining today? The way the human mind will work is that its 10 AM and
that’s in the short-term memory and from your long term memory you will fix that one
day is of 24 hours then there will be a mental manipulation unit which will compute the
difference (24-10). That its 14 hours or 13 hour 50 minutes.

(Refer Slide Time: 12:37)

If you put that down in the form of a diagram, you will see that the long-term memory
holds larger number of items. Depending on the person it can hold billions, trillions of
items whereas a short-term memory can hold only few. These are then fixed from the
long-term memory, short term memory and from the observation looking at the clock. It
then gets into the processing center where some computation can be done and the answer
is given.

(Refer Slide Time: 13:26)

What exactly is the short-term memory, what it can store and for how long. An item
stored in a short-term memory gets lost with the time may be within several seconds,
minutes or hour. It gets lost from the short-term memory because there are too many new
information that has come into the short term memory or it just plays and decays with
time. The main thing is that it stays for very short time and depending on the new
information coming, the time duration can be even very short, typically for tens of
seconds.

But someone can remember longer by recycling the memory. For example, you went to
the market and wanted to buy few things, just keep on recollecting again and again that
you need to buy. Hence, we are were recycling in the short term memory.
(Refer Slide Time: 14:45)

Software memory stores items. An item can be a character, it can be a digit (like 5,6),
character (like a, b, etcetera). It can be a word, a sentence, a story and even a picture. If
somebody remember some numbers 5 9 7 etc and each one is considered one item. But if
there is a relation between them then it can be considered as a one item. Consider 1 to 9
(i.e.; 1 2 3 4 5 6 7 8 9). So, that is one item, because you recognized that there is a
relation (i.e;1 to 9).

Similarly, a word, an individual letter if there is no relation they will be separate items
but if they are related, they mean something then that is just one item. The sentence is
one item, story is one item and even a picture is one item as they occupy one place in the
short-term memory.

The conclusion which we can made here is that if you are remembering something and
you are able to build the relation between the things that you want to remember then it
becomes easier. That process is called as Chunking.

Example of chunking:
(Refer Slide Time: 16:27)

Let’s consider someone asks you to remember the number 110010101001. You will
struggle to remember this, because there are too many digits and then the relationship
among them is not so obvious.

But, then group these into three in the octal form, 6251 it becomes easier to remember.
That is because of the limitation of the human cognition mechanism that the short-term
memory can hold only 7 items.

And as long as you are able to build relations it becomes easier for remembering till it is
less than 7. So, this is the principle of chunking.
(Refer Slide Time: 18:09)

There are many day to day experience where the short term memory is evident. For
example: you looked up to a telephone number and found that you not able to dial it as
it’s busy. After few minutes you are almost able to remember the number. But, after
several days you will hardly remember anything.

(Refer Slide Time: 18:42)

As the number of items that someone can store in short term memory is about 7 and that
is known as the magical number 7. Any set of information which has 7 items in it for a
ordinary person it becomes easy to understand. But if the number of items are large
considering tens of thousands, let us just look at very trivial example: Consider, you met
5 people somewhere, you will almost remember each of them. But you met 10000 people
for 10 minutes you will hardly remember anybody. That is because of the number 7 as
the short-term memory capability is restricted to 7.

So, if the information has more than 7 items it becomes exceedingly difficult to
understand and to remember.

(Refer Slide Time: 20:18)

To understand a program, you must look at the variables as how do they interact.
Considering a small program having only a couple of variables, you can easily look
through the code and understand what is happening. But when you are looking at a
program which has thousands of variables and each variable is set by some programming
constructs being used. For the human mind it becomes extremely difficult to understand
it.

As, the number of independent variables in a program is small it becomes easy to

understand but as the number of variables in the code increases it becomes very difficult
to grasp and to understand & requires and unduly large effort to master the problem. If
the number of independent variables is more than 7 then it’s a large problem dealing with
many things. Then the question arises that how does the software engineering principles
contain the complexity of this problem.
(Refer Slide Time: 22:40)

For machines there is no such problem as short term memory, of course as they have
RAM, etc and the restrictions are not so severe. So, if the machine would like write the
code then the slope would be almost linear.

But how the software engineering principles contain the complexity. Because, as the
complexity increases the human mind by itself would take exponential time, effort to
understand to solve the problem.

(Refer Slide Time: 23:35)

There are two major techniques that are used to overcome the cognitive limitation of 7.
These two important principles are used in almost every technique: one is called as
abstraction and the other is called as decomposition.

Let’s try to investigate these two fundamental techniques to handle the complexity. As,
software engineering is after all developing programs efficiently. As, the size increases
you want to develop only with linear time, cost, effort and etc. For that you need to
effectively handle the increase in complexity. These two techniques to handle the
complexity are used in almost every software engineering principle.

(Refer Slide Time: 25:08)

Abstraction: In abstraction we focus our attention only on some aspect of the problem
and ignore the rest aspects & irrelevant details. This is also known as model building.

Consider you want to develop a large building and see how does it looks like. You will
ignore all other aspect like the strength, wall thickness, the internal plan and etc. You
will concentrate only on its frontal appearance and ignore everything to construct a
model of the frontal view of the building. Similarly, for the floor plan for a building, you
will just concentrate on that and don’t bother about how does it appear externally, the
thickness of the wall and etc.

Concentrating on the hitting requirement of a room; you will just look where is it
located, how much heat it is getting, etcetera and you will omit other unimportant
aspects. For, every problem we can construct and abstraction. The abstraction is also
called as a model building if you create a model, you concentrate on some aspect and
ignore the rest. Hence, Model building is the same as an abstraction. This is an important
technique in software engineering and you need to build models of everything that is the
requirements, design, code, etcetera and that is one way to tackle complexity.

Let’s continue with this abstraction decomposition in the next lecture and we will also
look at other issues in software engineering.

Thank you.