Chapter
1
The Product
CHAPTER OVERVIEW AND COMMENTS
The goal of this chapter is to introduce the notion of software as
a product designed and built by software engineers. Software is
important because it is used by a great many people in society.
Software engineers have a moral and ethical responsibility to
ensure that the software they design does no serious harm to
any people. Software engineers tend to be concerned with the
technical elegance of their software products. Customers tend to
be concerned only with whether or not a software product
meets their needs and is easy to use.
1.1
The Evolving Role of Software
The main point of this section is that the primary purpose of
software is that of information transformer. Software is used to
produce, manage, acquire, modify, display, and transmit
information anywhere in the world. The days of the lone
programmer are gone. Modern software is developed by teams
of software specialists. Yet, the software developer's concerns
have remained the same. Why does software take so long to
complete? Why does it cost so much to produce? Why can't all
errors be found and removed before software is delivered to the
customer?
1.2
Software
Software is not like the artifacts produced in most other
engineering disciplines. Software is developed it is not
manufactured in the classical sense. Building a software product
is more like constructing a design prototype. Opportunities for
replication without customization are not very common.
Software may become deteriorate, but it does not wear out. The
chief reason for software deterioration is that many changes are
made to a software product over its lifetime. As changes are
made, defects may be inadvertently introduced to other
portions of the software that interact with the portion that was
changed.
1.3
Software: A Crisis on the Horizon
Many people have written about the "software development
crisis". There seems to be an inordinate fascination with the
spectacular software failures and a tendency to ignore the large
number of successes achieved by the software industry.
Software developers are capable of producing software the
functions properly most of the time. The biggest problem facing
modern software engineers is trying to figure out how to
produce software fast enough to meet the growing demand for
more products, while also having to maintain a growing
volume of existing software.
1.4
Software Myths
The myths presented in this section provide a good source of
material for class discussion. Managers need to understand that
buying hardware and adding people does not spontaneously
solve all software development problems. Customers need to
understand that computer software does not make all their
other problems go away. If the customer can not define his or
her needs clearly, it is not possible to build a software product
to meet these needs. If a customer does not have defined
business processes without computer support, building
computer software will not create these processes automatically.
Software engineers must be committed to the concept of doing
things right the first time. Software quality does not happen on
its own after a product is finished. Quality must be built into
every portion of the software development process.
PROBLEMS AND POINTS TO PONDER
1.1. Classic examples include the use of "digital
automobile dashboards" to impart a high tech, high
quality images. Appliances that "think;" the broad
array of consumer electronics; personal computers
(today, differentiated more by their software
function than the hardware), industrial
instrumentation and machines. All e-commerce
applications are differentiated by software.
1.2. The apprentice/artist culture of the 1950s and
1960s worked fine for single person, well constrained
projects. Today, applications are more complex, teams
work on large projects, and software outlives
generations of developers. Yet, the culture
established in the early days dies hard, leading more
than a little resistance to more disciplined methods.
In addition (see Chapter 29), the new generation of
Web application developers is repeating many of the
same mistakes that programmer made during the circa
1965.
1.3. This is a good problem for classroom discussion
(time permitting). Rather than focusing on cliche'
ridden (albeit important) issues of privacy, quality
of life, etc., you might want to discuss
"technofright" and how software can help to
exacerbate or remedy it. Another interesting
possibility is to use Neumann's "Risks" column in SEN
to key discussion. You might also consider new
attempts at software-based ‘cash’ economies, new
modes of interactive entertainment, virtual reality,
e-commerce, etc.
1.5. There are literally dozens of real life
circumstances to choose from. For example, software
errors that have caused major telephone networks to
fail, failures in avionics that have contributed to
plane crashes, computer viruses (e.g., Michaelangelo)
that have caused significant economic losses. Attacks
on major e-commerce sites.
1.6. The two broadest categories encompass risks
associated with economic loss and risks to the wellbeing of people. You might suggest that each student
select five risks (culled from the sources noted) and
present them to the class. Encourage them to look for
humorous as well as serious risks.
1.7. To be honest, most professors do not assign
papers as part of software engineering courses that
use SEPA. Instead, a term project (or a number of
somewhat smaller projects) are assigned. However, you
might consider discussing software engineering issues
as they relate to the topics noted in this problem.
1.8
Another way to characterize this problem is to
suggest that each student describe a software myth
that he or she believed that has subsequently been
dispelled. From the student's point of view, myths
will likely be driven by programming projects that
they've attempted earlier in their career. To give
this problem a contemporary feel, you might consider
the myths that have evolved around the development of
Web-based applications.