Transcript Document

Introduction
ECE 417/617:
Elements of Software Engineering
Stan Birchfield
Clemson University
Why does this course exist?
• Software is becoming more and more
– important
– complex
• Software is everywhere, at multiple levels: System,
application, scientific, embedded, ubiquitous, web, AI, …
• We still do not know how to do it
• Techniques that we have been using for 60 years are
inadequate
• Software engineering is an attempt to solve this problem
• Expect several generations for new
habits/principles/procedures to be
– discovered
– transmitted (education)
– Adopted (replacing old habits)
The Software Crisis
• Standish Group (1995) studied S/W
projects:
– 16% successful
(fully functional, on-time, and on-budget)
– 53% challenged
(reduced functionality, late, over-budget)
– 31% failed
(cancelled)
• More recent data (2006) suggests an
improvement: 35%, 46%, and 19%
Famous Bugs
•
1999: Mars Climate Orbiter
–
–
•
2004: Mars rover Spirit
–
–
–
–
•
–
–
–
Microsoft server timed to shut down automatically every 49.7 days to prevent
data overload
Technicians normally reboot system every 30 days to avoid this
One technician forgot  system shut down on its own
800 planes were left in the air without contact; 5 near misses
2005: Toyota Prius
–
•
Just after launch (June 2003), bug found in S/W, new version uploaded
This caused side-effect, so another version uploaded
After a few days, rover went into infinite reboot
Longest trial for file system testing was 9 days
2004: Air traffic controller in Southern California
–
•
Smashed into planet because units were not converted from English to metric
$125 million spacecraft lost
Bug caused gasoline engine to stall, often on highway
1995: Denver airport automated baggage system software
What is Software Engineering?
• The IEEE Computer Society defines software
engineering as:
– (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)
• If you do not find this helpful, you are not alone
• A better definition: “S/W engineering is applying
sound engineering principles to develop reliable,
efficient, economic S/W” – Pressman
What is S/W engineering?
•
S/W engineering is about managing complexity and
change
–
complexity – many different conflicting objectives, lack of
modularity
change – requirements updated when developers/clients
get better understanding of application, staff turn-around is
high, time b/w technological changes shorter than duration
of project
“The only constant is change”
–
•
S/W engineering
–
–
focuses on quality (foundation)
involves
•
•
•
Process – defines framework in which S/W is developed and
managed
Methods – activities involved
Tools – support the work
What is S/W engineering?
• Modeling – one of the basic methods of science
• Problem solving – lack of fundamental theory
leads to empirical methods to find solutions
• Knowledge acquisition – knowledge acquisition
is a non-linear process; addition of new piece of
knowledge may invalidate all previous
knowledge; all activities are interrelated
• Rationale-driven – assumptions change
continually; must capture context in which each
decision was made
Product and process
•
•
•
•
Product – end result
Process – how to get there
Often seen as dichotomy (either-or).
Field has vascillated back and forth over
the years between the two.
In truth, there is a duality. Both are true,
both are important, need to keep them in
balance [Margaret Davis]
Balance, balance, balance!
• If you learn nothing else, remember this: Balance
– Lone-ranger mentality has a tendency to reject
discipline (distrust theory)
– Academia has a tendency to over-emphasize discipline
(theory more important than practice)
• Common sense usually works
• Be wary of absolutes (in software)
• Even very good programmers can be trapped by
adherence to rules rather than focusing on the
end product
The Controversy
• The term S/W engineering originated in 1968 at a
conference in Germany
• But is the term meaningful?
• S/W is fundamentally different from traditional engineering
disciplines
– Not bound by laws of physics
– Nearly anything can change (plans, people, funding,
milestones requirements, designs, tests)
– Metrics have no atomic units and are highly subjective
• Software development is more akin to movie production
– Produces complex web of intellectual property
– Limited only by vision and creativity
• It is a blend of science and art
• Some prefer software development, or software economics
[Walter Royce, Successful Software Management Style: Steering and Balance, IEEE Software, 20(5):40-47, 2005 ]
Other differences
•
Unlike traditional engineering,
–
–
–
–
•
S/W is developed, not manufactured
Most S/W is still custom-built, not
component-based construction
S/W does not ‘wear out’, but it does
deteriorate
H/W failure curve vs. S/W failure curve
S/W projects cannot be managed as if
they were manufacturing projects
S/W Engineering is
Management
• S/W Engineering is about instilling discipline into
the development process
– Will make you a better programmer (self-management)
– Is necessary for managing teams of programmers
(especially large teams)
• S/W Engineering is a collection of
– management techniques
– wisdom and advice gained from past projects
(successes and failures)
– abstractions to mediate between low-level code and
high-level human language
What, A Management Course?
• No, you will not be able to manage a large
S/W project with hundreds of people by
the end of this course
• Management skills take years to develop
• But, if we are successful, you will
– Be better able to manage your own code
development
– Be equipped to work in (and perhaps lead) a
small team of programmers
– Be alert to the struggles and issues faced by
software managers
The Purpose of this Course
•
Encounter the concepts / terms / methods of S/W Engineering
– Some of these are useful
– Even those that are not: You should be familiar with them, because
you will encounter them
– Almost all are subject to change / disagreements
– Understanding the historical context and key players is important
•
Gain practical experience
–
–
–
–
•
Only way to master a craft is to do it – “Learning by doing”
(Imagine a painting class without paint)
Apply concepts as needed
Non-linear learning (“just in time learning”): Many concepts will not
be taught until after you need them
Develop proficiency with some additional tools
– C++, VC++, CVS, …
•
Learn to learn
– Field is constantly changing
– Habit and ability to continue learning is essential to success
Course Mechanics
• Entire class will work on one project
– Students will work in pairs (pair programming)
– Initially, pairs will self-organize into groups
– Some random shuffling will occur
• Weekly meetings in class
– Each group will present progress, issues
– Other groups will offer suggestions
– Code will be inspected, reviewed
• Individually,
– Attendance expected
– Bi-weekly “Learning reports” document non-linear learning
(e.g., suggested readings, on-line references you encounter
during project, etc.)
– Final exam will cover primarily “textbook” knowledge; like
certification exam (pass/fail)