Software Engineering – An Introduction

What is Software Engineering

Software Engineering is basically just an engineering approach to building software applications. However, a true definition for software engineering appeared in 1968 at the NATO Science Committee and it was meant to provoke thought regarding the current ‘software crisis’ at that time. They defined software engineering as:

"the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.” Alternatively, the IEEE standard 610-12 (1999) defines software engineering as "the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software."

cited: http://wiki.ercim.org/wg/SoftwareEvolution/index.php/Terminology#S

 

The question here is, why is Software Engineering so hard? Well here’s a few reasons as to why:

 

Size

Everyone, even you, can just sit at home and write a program. That program could contain 200 lines, heck, maybe even 1000 lines; however, in reality this is never the case.

For example, that last long-haul flight you went on, that airliner probably has around 10,000,000 lines of code written into it, and that’s probably just for the entertainment system!

Another example could be the Eurofighter's. Just for fuel management alone, that system probably has somewhere around 80,000 lines.

But, just to put this into context. Consider a Java Textbook around 10-20 years ago. The Java API had more methods than there were words in that one book. and that's HUGE! :D

 

Complexity

If you know algorithms pretty darned well, then you should realise that software that has a ridiculous amount of code in it will have bugs… lots and lots of icky bugs; and sadly bug spray won’t get rid of them :(
All Software Engineers would know this quote, which is the Embury’s Law:

This software has bugs in it, we just don’t know what they are yet.

 

Since code this big will obviously have different parts of the system interacting, then one solution is to use an Object-Oriented approach, sadly this is not always the case.

 

Requirements

We’ve all seen this, no matter how big our programs are. When you’re writing a software system you have never truly “finished” it because the requirements as to what the system must do always change – always.

The problem with requirements is that the number of outstanding requirements in your system will always increase. One way to show this is by using the Sargeant’s rule to calculate the total number of outstanding requirements:

• R  =  IR  +  Loc / K

Here we have 4 different variables:

1. R     -  the current number of outstanding requirements
2. IR    -  the initial number of requirements of the system
3. Loc -  the total number of lines of code within the system
4. K     -  a positive constant

SO from this, as more requirements are found, the total number of lines of code also increases, and since K never changes – constant – then R will always increase.