Understanding Software Engineering

Securing your knowledge

The ultimate security is your
understanding of reality.
—H. Stanley Judd
Is software engineering real engineering?

1
Introduction
 Status and Problems of
Software Engineering (1)

• Any matured science and engineering discipline

has a stable pyramid structure among its
foundations, education, and
practices/applications.
Relationship Between SW Engineering Foundations,
Education, & Practices/Applications
 Status and Problems of
Software Engineering (2)
• Software engineering as a discipline demonstrates an upside down
pyramid, where the whole field is driven by industrial practice and
technical innovations.
• Theories and fundamental research in software engineering,
particularly the laws that constrain software behaviors and software
engineering practice, have been left behind or overlooked, if not
been ignored or perceived inexist.
• As a consequence, software engineering educators had no solid and
durable theoretical framework to base in teaching. Instead, they
were busy explaining an extremely wide variety of practices,
techniques, and tools as in a fashion industry.
 Status and Problems of
Software Engineering (3)
• It is observed that the average half-life of most
software engineering techniques is only about
two to three years .
• That is, after every year, 15% to 25%
techniques one has acquired in software
engineering practice will be obsolete.
• What a young field where techniques had
never been durable!
How do software engineers spend
their time on the job?
• Software engineers probably spend less
than 10% of their time writing code. The
other 90% of their time is involved with
other activities that are more important than
writing code.
90% of Software Engineer Activities:
1. Eliciting requirements 8. Developing test strategies and test
2. Analyzing requirements cases
3. Writing software requirements 9. Testing the software and recording
documents the results
4. Building and analyzing prototypes 10. Isolating problems and solving them
5. Developing software designs 11. Learning to use or installing and
6. Writing software design configuring new software and
documents hardware tools
7. Researching software engineering 12. Writing documentation such as
techniques or obtaining users manuals
information about the application 13. Attending meetings with colleagues,
domain customers, and supervisors
14. Archiving software or readying it for
distribution
Misconceptions about
Software Engineering
Why is software so buggy and unreliable?
• It is unclear if software is more unreliable than any other complex
engineering endeavor. While there are sensational examples of
failed software, there are just as many examples of failed engineered
structures, such as bridges collapsing, space shuttles exploding,
nuclear reactors melting down, and so on. It seems that software
gets a bad rap. Oftentimes when a project fails, software engineering
is blamed, not the incompetence of the managers, inadequacy of the
people on the project, or the lack of a clear goal. In any case, you
have to prove that software is more unreliable than any other kind
of engineering system, and I have seen no compelling evidence to
support that contention; everything I have seen or heard is
anecdotal.
I write software as part of my job; does that
make me a software engineer?

• No! Anyone can call himself a software engineer if he

writes code, but he is not necessarily practicing
software engineering. To be a software engineer,
you need more than a passing familiarity with
most of the concepts of software engineering.
But isn’t software system development primarily
concerned with programming?

• As mentioned before, 10% or less of the software

engineer’s time is spent writing code. Someone who
spends the majority of his or her time generating
code is more aptly called a “programmer.” Just as
wiring a circuit designed by an electrical engineer is
not engineering, writing code designed by a software
engineer is not an engineering activity.
Can’t software tools and development
methods solve most or all of the problems
pertaining to software engineering?
• This is a dangerous misconception. Tools,
software or otherwise, are only as good as the
wielder. Bad habits and flawed reasoning can just
as easily be amplified by tools as corrected by
them. While software engineering tools are
essential and provide significant advantages, to
rely on them to remedy process or engineering
deficiencies is naïve.
Isn’t software engineering productivity a
function of system complexity?

▫ While it is certainly the case that system

complexity can degrade productivity, there are
many other factors that affect productivity.
Requirements stability, engineering skill, quality
of management, and availability of resources are
just a few of the factors that affect productivity.
Once software is delivered, isn’t the job
finished?
• No. At the very least, some form of documentation
of the end product as well as the process used
needs to be written. More likely, the software
product will now enter a maintenance mode after
delivery in which it will experience many recurring
life cycles as errors are detected and corrected and
features are added.
 Aren’t errors an unavoidable side effect of
software development?
• While it is unreasonable to expect that all errors can be
avoided (as in every discipline involving humans), good
software engineering techniques can minimize the
number of errors delivered to a customer. The attitude
that errors are inevitable can be used to excuse sloppiness
or complacency, whereas an approach to software
engineering that is intended to detect every possible error,
no matter how unrealistic this goal may be, will lead to a
culture that encourages engineering rigor and high quality
software.
Myths On Software Engineering
Software engineering has no theoretical foundation since
mathematics had not played a central role in programming.
Software engineering is not an engineering discipline rather than a
branch of art, because there were few scientific laws to follow.
Everybody can do programming; Kids even do it better sometimes.
When one can get a program run in a programming language that
displays the classical greeting “Hello world,” one is then confident to
claim that he/she is a programmer.
Do we need software engineering? Whether software engineering is a
faculty of empirical best practices or a system of essential theories?
Is software engineering an
engineering discipline?
Software?
Engineering?
Software + Engineering = ?
 Friedrich L. Bauer (1968)
“The establishment and use of sound engineering principles in order
to obtain economical software that is reliable and works efficiently
on real machines.”

• A solution to the so called software crisis.

• No explaination what the sound engineering principles are and
which of them are applicable to software engineering.
▫ That is why, after 40 years, professionals are still arguing what software
engineering is and whether it makes sense to speak the engineering of
software development.
IEEE Standard 610.12 (1990)

1. The application of a systematic, disciplined,

quantifiable approach to the development,
operation, and maintenance of software; that is,
the application of engineering to software.
2. The study of approaches as in (1).
 J.A. McDermid (1991)

“Software engineering is the science and art of

specifying, designing, implementing and
evolving – with economy, timeliness and
elegance – programs, documentation and
operating procedures whereby computers can be
made useful to man”
 Y. Wang and G.King (2000)
A discipline that adopts engineering approaches,
such as established methodologies, processes,
measurement, tools, standards, organisation
methods, management methods, quality
assurance systems and the like, in the
development of large-scale software seeking to
result in high productivity, low cost, controllable
quality, and measurable development schedule.
Contrast of Representative Definitions of Software
Engineering
 Cat Theory (NASA,2000)
• Mechanical engineering is like looking for a
black cat in a lighted room.
• Chemical engineering is like looking for a
black cat in a dark room.
• Software engineering is like looking for a
black cat in a dark room in which there is no
cat.
• System engineering is like looking for a
black cat in dark room in which there is no
cat and one yells, “I got it!”
Revised Definition (Wang, 2008)

An engineering discipline that studies the nature

of software, approaches and methodologies of
large-scale software development, and the
theories and laws behind software behaviors and
software engineering practices.
Are software developers
engineers or craftsmen?
 Engineers?
“Engineers carry out a task by making a series of
decisions, carefully evaluating options, and
choosing an approach at each decision-point that
is appropriate for the current task in the current
context. Appropriateness can be judged by
tradeoff analysis, which balances costs against
benefits”
 Engineers?

“Engineers measure things, and when

appropriate, work quantitatively; they
calibrate and validate their measurements;
and they use approximations based on
experience and empirical data”
 Engineers?
“Engineers emphasize the use of a disciplined
process when creating a design”

“Engineers can have multiple roles: research,

development, design, production, testing,
construction, operations, management, and
others such as sales, consulting, and teaching”
 Engineers?

“Engineers use tools to apply process

systematically. Therefore, the choice and
use of appropriate tools are key to
engineering”
 Engineers?

“Engineering disciplines advance by the

development and validation of principles,
standards, and best practices”

“Engineers reuse designs and design artifacts”