Chapter 1
Software and Software Engineering
CHAPTER OVERVIEW AND COMMENTS
The goal of this chapter is to introduce software and software engineering. Software is a “product” designed and built by software engineers. Software is important because it has an impact of virtually every aspect of our lives. Software engineers have a moral and ethical responsibility to ensure that the software they build does no serious harm and meets the needs of the people who request it and those who use it. 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 Nature of Software
The main point of this section is that software is an 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?
Many instructors choose to address software engineering ethics at this point. If you do this, have your students read and discuss Section 32.4 at the end of the book.
Ask your students: What makes software so important? And then have them list the ways that software impacts their lives. Have them list five non-computer related businesses where software has a significant, if ‘behind the scenes’ impact.
Select a book like Toffler’s PowerShift and note where he was right and wrong in predicting the “future.” Discuss the current state of the “programmer” in your country.
Spend some time talking about the questions posed at the end of this section.
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.
Spend some time talking about the three major characteristics noted in this section. The “wear” discussion is critical—be sure your students understand it.
Discuss why component-based development has benefit, but also discuss why it hasn’t worked as well as many believe it should.
1.3 The Unique Nature of WebApps
Some SEPA adopters argue that there really isn’t very much that is unique about WebApps when contrasted with “conventional” software, but I disagree. Spend some time going through the attributes discussed in this section, indicating how WebApps different from conventional software in both subtle and distinct ways.
1.3 Software Engineering
Recognize that any attempt to develop an all-encompassing definition of software engineering is an exercise in frustration. The point here is to emphasize that software engineering is a “layered” technology. If you have the time and the inclination, you might want to introduce your students to SWEBOK (http://www.swebok.org/) as another source of software engineering information.
1.4 Software Engineering Process
Even though it might seem to be a simple idea, many students struggle with the concept of a process, confusing process with methods and tools. Spend some time discussing the meaning of a process framework and the basic framework activities introduced here.
1.5 Software Engineering Practice
Polya’s work is pivotal to basic understanding of the software engineering approach. Spend time discussing his seminal ideas along with the questions that he posed at each step along the way.
1.6 Software Myths
The myths presented in this section provide a good source of material for class discussion. Ask “why” people believe these myths and whether there are grains of truth in each (there are). Ask you students to think of one or two software myths of their own.
1.7 How It All Starts
SafeHome is a useful case study that you’ll encounter throughout the book. It’s worth spending some time discussing how projects start in the real world.
Based on the sidebar, ask students to develop a list of 10 questions that they would need answered about SafeHome.
No comments:
Post a Comment