Chapter 5

Part 2          Software Engineering Practice

Chapter 5

Practice: A Generic View

CHAPTER OVERVIEW AND COMMENTS

This intent of this chapter is to present the concepts and principles that serve as a foundation for software engineering practice. The concepts and principle presented in this chapter are applicable regardless of the specific process that is used, methods that are chosen or tools that are applied.

Note: In many cases, the concepts and principles discussed here should be revisited as each software engineering activity is presented during the course. For example, design concepts and principles can be revisited when the chapters on software design are covered.

5.1    The Essence of Practice

This section lists the generic framework (communication, planning, modeling, construction, and deployment) and umbrella (tracking, risk management, reviews, measurement, configuration management, reusability management, work product creation, and product) activities found in all software process models. Section 5.1.1 lists some of Polya’s problem solving heuristics adapted to software engineering. Section 5.1.2 lists seven core principles that focus on software engineering as a whole.

Emphasize that software engineering is really nothing more than a disciplined, common sense approach to problem solving. Polya’s guidelines are worth discussing. Ask your student how they interpret each.

The core principles in Section 5.1.2 are important, and KISS is the most important of them all. Emphasize that software engineering helps to achieve simplicity by providing a focused approach to problem solving. Also note that software engineering never retards creativity and can, if properly applied, enhance agility.

5.2    Communication Practices

Most students have had relatively little experience in this area—emphasize these principles with discussion and examples. If you have time, classroom role playing is a good idea. Be sure to indicate that communication failures can be fatal even if very smart people apply superior technology.

Students need to be aware that effective communication includes getting a response from the message recipient that indicates the correct message was received. You might think about using communications exercises with your students to help them appreciate the importance of this topic. For example, have group of students pass a message to each other by whispering the message to the student on his or her right. For another activity you might divide students into a groups and have a representative from each group carry detailed verbal instructions on completing some task from you to their group. In both cases, the message is likely to be distorted and misinterpreted by the message recipients.

Ask your students whether communication and negotiation are the same thing. Note the similarities. overlap, and differences.

Spend time on the communication task set with particular emphasis on how it might be modified for very small projects, very large project with many stakeholders, etc.

5.3    Planning Practices

Planning is described as the management and technical activities needed to define a roadmap to complete a software project. There will be two entire chapters devoted to project planning later in the text. Students might benefit from activities in which they try to develop user scenarios for hypothetical software projects.

Discuss project scope—a concept that may be hazy in the minds of many students. As them to write a statement of scope for some well known software product; then note how the various statements differ from one another.

If there is interest in agile development, discuss how different process models treat planning (either emphasizing or deemphasizing it). Also discuss the fact that even the best plan is developed iteratively and note the reasons why.

Discuss granularity within the context of planning. Have the students develop two plans—one with coarse granularity and another with fine (high) granularity.

Section 5.3.2 presents Boehm’s W⁵HH principle. Discuss the reason we ask each of the questions Boehm proposes.

Spend time on the planning task set with particular emphasis on how it might be modified for very small projects, very large project with many stakeholders, etc.

5.4    Modeling Practices

The process of developing analysis and design models is described in this section. The emphasis is on describing how to gather the information needed to build reasonable models, but no specific modeling notations are presented in this chapter. UML and other modeling notations are described in detail later in the text.

Students should be reminded that analysis and design are not often conducted a separate activities. Discuss the overall purpose of analysis and design models and how they different. Keep the conversation non-technical at this stage.

The principles for both analysis and design introduce concepts that you can choose to postpone until you cover these subjects in more detail. However, it’s not a bad idea to present each briefly, foreshadowing the material to be presented later in the course.

Emphasize that the agile modeling principles presented here are applicable to all software engineering modeling and represent best practice across the board.

I would not consider the task set for analysis and design modeling at this stage. Simply note them and indicate that each will be discussed during coverage of the topic later in the course.

5.5    Construction Practices

In this text “construction” is defined as being composed of both coding and testing. The coding principles should be a view of material students saw in their previous programming courses. Many students do not receive much information on systematic testing in their programming courses. The most important point in this section is that testing must be linked to the customer requirements. A second key point is that the purpose of testing is to uncover defects. Exhaustive testing is not possible so processing a few test cases successfully does not guarantee that you have bug free program. Unit testing of components and integration testing will be discussed in greater later in the text along with software quality assurance activities.

The only place that coding is discussed within SEPA is in section 5.5.1. [For those who object to this slight, I can only say that large systems rarely fail because developers are poor coders. Misunderstood or ambiguous requirements, poor design, and inadequate testing are the real culprits.] It’s worth spending some time addressing preparation principles, coding principles, and validation principles.

Although testing has received increased attention over the past decade, I still consider it the weakest part of software engineering practice for most organizations. Therefore, it’s worth considering these principles now, and again when you cover Chapters 13 and 14.

The Pareto principle is introduced in Section 5.5.2 and will reappear often within SEPA. Spend some time discussing it in the abstract, providing examples of everyday occurrences.

I would not consider the task set for testing at this stage. Simply note it and indicate that it will be discussed during coverage of the topic later in the course.

5.6    Deployment Practices

This section makes some important points about software delivery. Some of them will seem silly to your students (like removing known bugs before delivering products). Some of them will not be intuitively obvious to your students (like planning for user instruction and feedback mechanisms as part of the delivery package). Managing customer expectations and controlling feature creep are also mentioned in this section. It is important to make sure your students understand that software is not delivered and abandoned. Support and maintenance of software and documentation based on customer feedback is an ongoing process. This is especially true for agile software processes. These concepts will be discussed later in the text in the chapters dealing with software quality assurance and configuration management.

The vast majority of software engineering courses (and textbooks) spend relatively little time (or pages) discussing what happens after software is built. SEPA does discuss deployment here and considers maintenance and support issues in Chapters 1 and 31. However, coverage in this book is light.

Spend some class time discussing the principles discussed here, emphasizing that support and maintenance of software continues long after the team that built the system has moved on to other things. The people who do this support and maintenance work need the information contained in work products produced during the software process. In essence, these work products are a legacy left to those that follow.

Spend time on the deployment task set with particular emphasis on the meaning of the tasks noted.