Transcript Introduction to Software Engineering

Introduction to
Software Engineering
“Software is hard.”
---Donald Knuth
Context and motivation for course topics
Software is pervasive throughout
our economy and culture
• Modern civilization runs on software.
• Nearly all of the products, services and
innovations that power the industrialized
world depend on software.
• If you aren’t amazed by the extent to which
our economy and culture depend on
software, I’ll forgive you because software
is largely invisible. You can’t see it. You
can only experience it indirectly. Let’s
make it tangible.
For Example
• Did you know there is a ton of software in
the average luxury car?
• No, I mean that literally. The average
luxury car contains almost 100 million lines
of code.
• Printed and bound,
100 million lines of
code weighs over
3,000 lbs or 1.5 tons!
Printed out, the software contained in a premium automobile
is enough to fully cover a two-lane highway for 13.5 miles
The Demand for Software is
Strong and Growing
•
•
•
•
•
Moore’s Law
Software replacing hardware
Product differentiation with software
Open Source
Growing interest in mobile devices (smart
phones, tablet computers, etc.) (Post-PC
era)
Average Industry Performance
Isn’t Flattering
Results from the 2011 Standish Survey
Project performance by
methodology
Industry Progress
Larger projects are much more prone
to failure than smaller ones
Defects by application size
Spectacular Failures are
Particularly Worrisome
• Ariane-5 • Denver International Airport baggage
handling system • Patriot Missile • Therac-25 –
• Add to this list the terrible tragedy of _____
in 20__.
Why do projects fail?
• Estimation error. Projects that are estimated
poorly are doomed from the start.
• Performance failure
–
–
–
–
Poor planning (bad methodology choice)
Incorrect and optimistic status reporting
Unrealistic schedule pressure
New and changing requirements during
development
– Inadequate quality control
– Poor communication
Why do projects fail? [Cont]
• Perceived failure is the sum of estimation
failure and performance failure.
Rushing to Code
• Rushing to code is the tendency to begin to
code as soon as you have some notion of
what is needed is tempting. Developers like
it because writing the code is probably the
most enjoyable part of software engineering
and offers immediate feedback. Managers
like it because it gives the allusion of
progress.
• The opposite of rushing to code is spending
time upfront on understanding project
requirements, project planning and software
design.
The difficulties in software development are
rooted in the fundamental nature of software
• Intangibility – software is not far removed from pure
thought stuff [Brooks].
• Complexity
– Software is dynamic
– Software automates complex processes (lower bound for
complexity)
– Software has a greater number of discrete states than any other
human artifact and transitioning between these states is not a
smooth and continuous process [tbd: find Fred Brooks ref]
– Software complexity and project complexity grows more than
linearly with size of product and size of team (see next slide)
• Changeability – software is soft which leads to change
requests
• Scalability – projects don’t scale up easily.
Software complexity and project complexity grows
more than linearly with size of product and size of team
Software is not constrained by physical laws or the properties
of materials. The software equivalent of the following is just
the starting point for many applications.
No Silver Bullet
• In 1987 Fred Brooks wrote an influential paper
entitled “No Silver Bullet—Essence and
Accidents of Software Engineering”.
• In this paper he argues, “there is no single
development, in either technology or management
technique, which by itself promises even one order
of magnitude [tenfold] improvement within a
decade in productivity, in reliability, in simplicity”
Silver Bullet Syndrome
• Silver Bullet Syndrome = expecting exceptional
productivity gains from one tool or technique.
–
–
–
–
–
–
–
Switch from batch programming to online terminals
3Rd generation languages
Case Tools
AI
OOP
Ruby on Rails
Process improvement initiatives and methodologies
(CMMI, Agile Methods, TQM, etc.)
– Software Craftsmanship
Essence and Accidents
• To make his point, Fred Brooks, makes the distinction
between two types of difficulties associated with software
development:
– Essential Difficulties
– Accidental Difficulties
• Most of what software engineers now do is devoted to the
essential.
• Essential complexities aren’t easily resolved. For example,
you can address accidental complexity of memory leaks by
switching to a language that supports garbage collection.
There is no instant resolution to the problem of eliciting
requirements or creating a flexible design.
Essential Complexities
• Essential complexities are inherent in the
problem. They can’t be avoided.
• Examples:
– Defining precisely what to build
– Coming up with the conceptual construct of the
solution
– Validating the problem definition and solution
construct
Accidental Complexities
• The accidental complexities of software development are
consequential to the tangible form of the solution, what
you might call self-inflicted problems. If you choose Java
as your implementation language, you will have to deal
with the complications—large and small—that go along
with programming in Java (e.g. how to convert a string to
an int, how to read data from a file, etc.).
• Examples of accidental complexities:
– Expressing conceptual constructs with a programming language
– Learning to use IDE’s such as Visual Studio and Eclipse
– Learning to use configuration management tools such as SVN and
ant.
– Testing the fidelity of the representation
– Special tricks need to get C preprocessor macros to work correctly.
For example, needing to wrap do { … }while(0) around statements
in a macro definition in order to preserve the semantics when a
semicolon is added after the macro use.
Simple Quiz for better
understanding accidental and
essential complexities.
• For each of the following 4 quotes, indicate
whether it was a statement made during the
1968 conference on software engineering or
the 2011 conference on software
engineering.
A. “The discussions were recorded by several reporters and
most were also recorded on magnetic tape.”
B. “There is probably no single ‘correct’ order in which to
take a series of design decisions, though some orderings
can usually be agreed to be better than others. Almost
invariably some early decisions, thought at the time to
have been clearly correct, will turn out to have been
premature.”
C. “Few large systems have been written in high-level
languages. This is not surprising since there are inevitable
penalties in size and performance of compiled code, and
these factors have been paramount in people’s minds.”
D. “Users are interested in systems requirements and buy
systems in that way. But that implies that they are able to
say what they want. Most of the users aren’t able to.”
History of Software Engineering
1968 NATO Conference on Software Engineering
Success with Software is Possible
• There are organizations that are succeeding
with their software development efforts.
Being successful with software means:
– Having the ability to give accurate estimates
that get more precise over time
– Delivering on schedule and within budget
– Being able to control software quality
– Satisfied customers
– High morale among staff members
– High productivity
No Universal Solutions
• No one solution is appropriate for all
projects
Important Factors in Project Success
•
•
•
•
•
•
•
•
•
•
•
•
Management experience
Technical staff experience
Appropriate quality control measures
Stable requirements
Component reuse
Use of specialists
Use of appropriate methodologies
Use of appropriate estimating techniques and tools
Use of appropriate planning techniques and tools
Formal progress tracking
Experienced clients
Adequate tools
Software Engineering
Software
• “Computer programs, procedures, and
possibly associated documentation and data
pertaining to the operation of a computer
system.”
Software Engineering
• Software engineering is “the application of
a systematic, disciplined, quantifiable
approach to the development, operation, and
maintenance of software, that is, the
application of engineering to software”
[IEEE]
What is Engineering?
• Engineers apply science and technology to develop costeffective solutions to practical problems.
• The Accreditation Board for Engineering and Technology
(ABET) defines Engineering as:
“The profession in which a knowledge of the
mathematical and natural sciences gained by study,
experience, and practice is applied with judgment to
develop ways to utilize, economically, the materials and
forces of nature for the benefit of mankind”
• Engineering disciplines have a core body of knowledge or
underlying science that can be used to solve practical
problems. For example, chemical engineering has
chemistry and electrical engineering has math and physics.
Stop here
Characteristics of successful practice
looks a lot like engineering
•
•
•
•
Disciplined
Systematic
Quantitative
Growing body of knowledge that can be
applied in a systematic way
• Applying well-understood knowledge to
solve practical problems
Economic value of software to
companies
• Companies invest in software in order to:
– Reduce cost, and/or
– Increase revenue
Software Categories
• It is important to be aware of the different types of
software. A technique or methodology that works
well for the development of one type of software
could be a disaster when used in the production of
another type of software. The categories are:
–
–
–
–
–
Shrink-wrapped or packaged software
Custom or bespoke software
Consultingware
Embedded software
Throwaway or one-off programs