Chapter 32

Chapter 32

The Road Ahead

CHAPTER OVERVIEW AND COMMENTS

The intent of this chapter is to provide a peek into the future of software engineering practice. Like any attempt at crystal ball gazing, my projections may be off the mark, but the general trends outlined in this final chapter of SEPA are likely to emerge as in the years ahead.

In addition to prognostication, this chapter presents a brief discussion of software engineering ethics. You may choose to cover this material very early in a software engineering course, although I think it’s best to wait until a student has substantial knowledge of just what software engineering is. In any event, this is a very important topic and should be covered, even if time is short.

32.1     The Importance of Software—Revisited

This section revisits the importance of computer software. The key aspect of this discussion is "software as differentiator." It is interesting to have your students come up with examples of software as a differentiator for products and services.

32.2     The Scope of Change

The technologies noted in the sidebar are worth discussing. You might also have your student visited Wired magazine’s on-line site (www.wired.com) for many interesting articles and projections about future technologies.

32.3     People and the Way They Build Systems

People and cultures change very slowly. In this section, I make the argument that ad evolving software engineering environment may have as much or more to do with people issues (in software engineering) than the people themselves. As tools, interaction mechanisms, and methodology mature, the culture for building software may change accordingly.

32.4     The New Software Engineering Process

The agile, incremental process model is discussed. If you did not emphasize Chapter 4, you might assign it now. Otherwise, focus on the milieu the “forces” many software teams to adopt this process model.

32.5     New Modes of Representing Information

Students spend much time thinking about data and program architectures, algorithms and the like. They spend very little time considering the intent of the data that is processed. This section considers the relationship between data, information, knowledge and wisdom.

You might relate some of this discussion to data mining in general and specific applications that span multiple data bases.

32.6     Technology as a Driver

Review the technology trends noted in the sidebar in this section.

32.7     The Software Engineering Responsibility

Software engineers should abide by a code of ethics that guides the work that they do and the products that they produce. The Software Engineering Code of Ethics and Professional Practices is well worth discussing with your students. To make the discussion more meaningful, you should pose specific business or personal situations and have your students indicate how they would react to them.

see >> Chapter 33

Chapter 31

Chapter 31

Reengineering

CHAPTER OVERVIEW AND COMMENTS

Reengineering became ‘corporate chic’ during the 1990s. At the corporate level, entire business processes were reengineered to make them more efficient and more competitive (at least in theory!). These changes had a trickle down effect on information systems. As business processes changed, the information technology that supported them also had to change.

         The intent of this chapter is to introduce business process reengineering (BPR) and discuss the management and technical aspects of software reengineering. The basic principles of BPR are introduced and an overall model for reengineering the business is discussed briefly. In reality BPR is a topic that is beyond the scope of most courses that use SEPA. It is introduced in this chapter because it is the driving force behind most software reengineering activities.

         The discussion of software reengineering begins with the “maintenance iceberg.” Even after almost 40 years, this metaphor rings true, and yet, many students have virtually no appreciation of the burden that maintenance places on the software community. The steps of the software reengineering process model are considered in some detail. A model for assessing the economics of software reengineering is presented at the conclusion of the chapter.

Critical Points:  BPR extends beyond the scope of software to the entire business. Yet the results of BPR can have a profound impact on information systems that service a business. Software maintenance is a significant burden for all software organizations. The software reengineering process encompasses inventory analysis, restructuring, reverse engineering, and forward engineering.

31.1     Business Process Reengineering

             

This section presents an overview of BPR with an emphasis on its impact, basic BPR principles and the tasks that define the BPR model. Be sure to spend a moment on Section 31.1.4. There is significant hype associated with BPR and the ramifications of this should be discussed for your students.

If time permits you might have the student conduct a BPR exercise by reengineering some process (e.g., registration) at your university. Follow the process outlined in this section

31.2     Software Reengineering

It’s worth spending substantial time discussing software maintenance (Section 30.2.1) and its impact on the software community. The basic activities that are performed when software is to be reengineered are discussed in Section 30.2.2. The discussion begins with software maintenance and then continues into an overview of the software reengineering process model. Each task performed as part of the model is discussed briefly.

31.3     Reverse Engineering

This section considers reverse engineering activities and identifies key concepts that must be understood as information is extracted from an existing program. Reverse engineering techniques for processing, data, and user interfaces are all discussed. If time permits, distribute two undocumented pieces of code, one well structures and designed, the other a kludge. Have your students attempt to reverse engineer each and then draw conclusions from their experience.

31.4     Restructuring

Section 31.4 presents a brief overview of restructuring techniques for code and data. If time permits have students research one or more restructuring tools (see the sidebar in this section) and then discuss how they work on existing code.

31.5     Forward Engineering

This section presents an overview of forward engineering approaches for client/server systems, OO systems, and user interfaces.

31.6     The Economics of Reengineering

This section presents a simple cost-benefit model for reengineering. Not every application should be reengineered. The model presented in this section enables your students to compute the projected cost benefit of a reengineering activity.

see >> Chapter 32