Page 19 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Unit 1: Introduction to Software Engineering

5. ......................... is a collection of programs written to service other programs. Notes
( a) Information determinacy (b) System software

( c) Real-time software (d) Business software

1.8 Software Myths

There are number of myths connected with software growth neighbourhood. Some of them
really affect the way, in which software development should take place. In this, we list few
myths, and discuss their applicability to standard software development [PIER99, LEVE95].
• Software is easy to change: It is true that source code files are easy to edit, but that is quite
dissimilar than saying that software is easy to change. This is misleading exactly because
source code is so easy to alter. But making changes without introducing errors is extremely
difficult, predominantly in organizations with poor process prime of life. Every change
requires that the complete system be re-verified. If we do not take proper care, this will
be an extremely tedious and expensive process.

• Computers provide greater reliability than the devices they replace: It is true that software does
not fail in the conventional sense. There are no restrictions to how many times a given
piece of code can be executed before it “wears out”. In any event, the simple expression
of this myth is that our general ledgers are still not perfectly accurate, even though they
have been computerized. Back in the days of manual accounting systems, human error
was a fact of life. Now, we have software error as well.

• Testing software or ‘proving’ software correct can remove all the errors: Testing can only show
the presence of errors. It cannot show the absence of errors. Our aim is to design effective
test cases in order to find maximum possible errors. The more we test, the more we are
confident about our design.
• Reusing software increases safety: This myth is particularly troubling because of the false
sense of security that code re-uses can create. Code re-use is a very powerful tool that
can yield dramatic improvement in development efficiency, but it still requires analysis
to determine its suitability and testing to determine if it works.
• Software can work right the first time: If we go to an aeronautical engineer, and ask him
to build a jet fighter craft, he will quote us a price. If we demand that it is to be put in
production without building a prototype, he will laugh and may refuse the job. Yet,
software engineers are often asked to do precisely this sort of work, and they often accept
the job.

• Software can be designed thoroughly enough to avoid most integration problems: There is an
old saying among software designers: “Too bad, there is no complier for specifications”
This points out the fundamental difficulty with detailed specifications. They always have
inconsistencies, and there is no computer tool to perform consistency checks on these.
Therefore, special care is required to understand the specifications, and if there is an
ambiguity, that should be resolved before proceeding for design.

• Software with more features is better software: This is, of course, almost the opposite of the
truth. The best, most enduring programs are those which do one thing well.

• Addition of more software engineers will make up the delay: This is not true in most of the cases.
By the process of adding more software engineers during the project, we may further delay
the project. This does not serve any purpose here, although this may be true for any civil
engineering work.

LOVELY PROFESSIONAL UNIVERSITY 13