Sunday, January 16, 2011

Software Engineering’s Challenges: Change and Complexity

Every engineering discipline starts off in response to some pressing problem. Software engineering confronts the problems of change and complexity.

The very nature of software—its plasticity—makes it amenable to a continuous cycle of change. It seems rather easy to accomplish. After all, tweaking one statement in a software program can radically alter the program’s behaviour. But such tweaking—little by itself, but considerable in conjunction—can end up
changing the intent of the program’s design in fundamental ways.

It is absurd to expect a car to fly or float. But very often a software system built for one context is expected to function in as drastically different contexts, with the same grace and efficiency. These expectations can be traced to our wide cognitive gap with the use of software. Decades and centuries of using cars and bridges respectively, and millennia of using houses has ingrained in our minds what cars, houses, and bridges can and cannot do. Accordingly, we tune our expectations as well as environmental factors to set the context for these systems to function. In comparison, the use of software amongst a large community of lay users has just begun. Our understanding of how and to what extent software can serve our needs is yet not complete. As a result, the problem of change for software comes primarily from changing user expectations, and also from changes in the environment—technological and social.

Complexity is a complex word and there is no one definition to cover its ken; even reaching a definition is fraught with difficulties. But we need to care about it in life as well as in software engineering as complexity arises out of simplicity, at times suddenly and surreptitiously. Think of a simple computer program of five lines of code. It is straightforward; by carefully reviewing each line, we can hope to have complete knowledge of the program’s structure and behaviour. Now what if, a loop is introduced in the program—a simple construct that executes a set of statements repetitively, until a condition holds. The number of execution paths through the program has significantly increased now, and it has become far more difficult to know for sure what happens in each step when the program runs. This example is just a watered down instance of the combinatorial complexity software systems customarily face. Then there are even more involved issues such as complexity of the problem domain, complexity in the interaction of the various forces—technological, commercial, political—that a software system has to balance to be successful.

A common feature of complex systems is that they are greater than the sum of their parts. Anyone who has worked on a course project to build a piece of software stretching across several files can appreciate the sense of this statement: A piece of software is made of individual files, but it delivers something that merely bunching the files together will not achieve. Now scale-up to a real world system—with hundreds, if not thousands of files; and thousands, if not millions of interfaces between them; perhaps simple by themselves, but certainly complex when functioning together. And this is just one, relatively less significant, facet of software complexity.

A central theme of software engineering is about framing an adequate response to the problems of change and complexity.


Anonymous said...

Its hard to see SE as another engg domain. Looking at the power of a small mistake,variable or condition which can change the behavior of whole process, SE seems to complicated enough to handle such things. SE cannot be simple.

When I think of s/w like SAP which are being built from last 2-3 decades. Every it is being contionously being updated by thousands of S/w Engg.
Clearly SE has been able to capture the difficulties of future. It involves lot of analysis to make s/w reusable, extensible etc.
Also dividing the module, among sevral engg throws light at 1 pt, Though SE is complicated process but when it involves lot of people honestly doing small part of it, it becomes simple and efficient way of doing work.

Philip Joseph said...

With advance in time and technology, changes are inevitable to any system; so is to software engineering. These changes will add to the complexity of the system. A system with command line interface will not make it to general public of this day. The interface has to be friendly and usability has to be attractive. These thoughts guide a designer while creating a new software system. This work is indeed complex.

Abiding to the environment, changes and complexity are the challenges of software Engineering.


Aditya (MT2010007) said...

Yes, complexity is a relative term and cannot be used freely in every context. I personally believe that software is 75% complex because it is really complex in nature (owing to the innumerous technologies, their features, libraries, interactions bw similar and dissimilar components, new infeasible but achievable requirements and enhancements, hardware and software limitations like scalability and reliability...) and the rest due to short dead lines (coz of customer pressure) and the developers less competency (he has to update himself to the newer technologies as they come in with more care to sustain).

To overcome all these parameters in an elagant manner, we need to for sure follow some of the meticulously planned standard processes which have come up as an engineers subject. Currently this is still a science. When it becomes an art, software may not seem to be as complex as it might seem today.

Aditya (MT2010007) said...

Just thought this might be some what apt to my point.. Dilbert

Manasa said...

Its not Complex if its not Complex and Change is a part of the Game.Its overwhelming to understand how Software Engineering tackles the challenges in the problem domain.Change and Complexity form a vicious circle ,the onus lies on the Software methodologies to transform it into a virtuous one so that it is not so Complex after all!


Nilesh said...

Nilesh Inamdar
The most important challenges for Software Engineering are to handle change and complexity. The complexity is a relative term. It means that if single person is working on a software development he may not find it that complex, but when some other persons or 'n' persons are working on a project then the same software development becomes complex for them.Because it is difficult to understand the work of other developers.So the system becomes complex and so it becomes difficult to change.Here software engineering comes into picture.Software engineering should establish a standard template in which each developer can put his work so that others can understand it in less time and reduce the complexity.Once a system is understood it can be easily changed.Engineering is to make the product human independent. Software must be developer independent. Software Engineering plays a key role in making it independent by setting standards that must be followed.

ravi_endla said...

It is some times possible that a system can be built as simple as possible ,with less LOC,files and understandable code.There might be no need of making it complex.For example a simple console calculator in c.Hardly it can have 20-30 LOC and it is very easy to understand.
But it is always up to the user to make the system complex or not.In above example if the user wants some thing like exception handling ,more functions and a GUI ,this makes the system more complex.
Still if the user wants some fast arithmetic calculation ...and so on,more and more features you add to the system ,the more complex it becomes.
Complexity might make the system with more LOC , might confuse the developer or might take more time to develop. But something good to know here is complexity will cover a wide range of user requirements.
Hence software being more complex is not bad all the times. But simplifying the same software with same functionality and requirements is appreciable.

Pratibha said...

So much of importance is given to processes / rules in software engineering is because SE is quite a new field, hence we humans have not been able to dissect it thoroughly. When compared to other fields like pure sciences, which has been around for centuries, SE is in its infancy. Hence, to understand its working, we tend to make everything into a process where everything is dictated by rules and hence make it easier for us to code.

--Pratibha (MT2010110)

Sandeep(MT2010128) said...

In software engineering,Software Configuration Management (SCM) is the task of tracking and controlling changes in the software. Configuration management practices include revision control and the establishment of baselines.

SCM concerns itself with answering the question like "Somebody did something, how can one reproduce it?" Often the problem involves not reproducing "it" identically, but with controlled, incremental changes. Answering the question thus becomes a matter of comparing different results and of analysing their differences.

Traditional configuration management typically focused on controlled creation of relatively simple products. Now, the implementers of SCM face the challenge of dealing with relatively minor increments under their own control, in the context of the complex system being developed.

Skanda Kumar [MT2010143] said...

The word software is being used in a more free manner than it used to be before the advent of the 'Web'. Software now caters to people across different boundaries ranging geographical, cultural, professional and so on. This diverse class of users puts a greater demand on the software eg: A business man would look at Microsoft Excel in a different perspective compared to a scientist. This demand along with market competition as added a new dimension to the software complexity.

Nitesh Kumar (MT2011093) said...

As a piece of software is made of individual modules, if the inter-dependencies between these module is high (tight coupling) then the complexity of the over all system will increase further.
Ideally modules must have loose coupling and high cohesion. Loose coupling will result into low inter-dependencies between modules and hence maintenance of the software will be easy. While high cohesion will guarantee that modules are focused in there respective responsibility.

Nitesh Kumar