Part 1 The Software Process
Chapter 2
Process: A Generic View
CHAPTER OVERVIEW AND COMMENTS
This intent of this chapter is to establish a definition for software engineering and to present a generic software process model that can be used as a template for all other process models presented in Chapters 3 and 3. A process framework, encompassing five activities— communication, planning, modeling, construction, and deployment—is presented. In addition, the CMMI, process patterns, and personal and team oriented process models are discussed.
2.1 Software Engineering - A Layered Technology
Software engineering encompasses a process, the management of activities, technical methods, and use of tools to develop software products. Students need to become familiar with the principle that a focus on software quality is essential for any organization that wishes to develop better software products more efficiently.
Dissect the IEEE definition of software engineering with your students. Be certain that they understand that a “systematic, disciplined, quantifiable approach” does not mean a bureaucratic, document-laden approach. Spend some time on Figure 2.1, emphasizing that process serves as a foundation for methods and tools.
2.2 A Process Framework
Software process models can be prescriptive or agile, complex or simple, all-encompassing or targeted, but in every case, five key activities must occur. These “framework activities” should be emphasized. Note that the framework activities are applicable to all projects and all application domains, and they are a template for every process model discussed in this book.
Many students have trouble understanding “umbrella activities” and “task sets.” Be certain that you’ve discussed these concepts thoroughly. Spend some time on the first Task Sets sidebar, noting that a task set will vary depending on the characteristics of a project.
2.3 The CMMI
If your enrollment is mostly industry professionals, this section should be discussed in detail. If, however, your students are undergrads with little real-world experience, you should note that process “standards” do exist, that the CMMI is an important one, and that the levels noted provide an indication of an organizations process capability. Also note, that the success in building large software-based systems correlates with an organization’s capability level.
2.4 Process Patterns
The use of software patterns is becoming increasingly popular as organizations try to reduce costs by reusing both process and product artifacts in new projects. A generic pattern template is discussed in this section and students should be give a chance to see at least one example of a complete pattern from a real product.
This is the first appearance (of many) of “patterns” in this book. It might be worthwhile discussing patterns in general, their meaning, their intent, and the benefits of using them across many software engineering topics. If you are a patterns advocate, you might digress and discuss Alexander’s work, pattern templates and so on. If time permits, have your students suggest a pattern for a non-software engineering related process, say something in a fast food restaurant serving process.
2.5 Process Assessment
If your enrollment is mostly industry professionals, this section should be discussed in detail. You might even have each student run a min-assessment of his/her organization. If, however, your students are undergrads with little real-world experience, you should spend relatively little time on this subject, except to note that assessment techniques do exist.
2.6 Personal and Team Software Process
Two important process models (PSP and TSP) are discussed in this section. Your students may find it helpful for you to provide examples of the kinds of how development might proceed under each model. The PSP model is good from the perspective that an individual software engineer can use it to improve his or her personal productivity and work product quality. Both models are largely iterative or evolutionary in their approach to software development.
PSP and TSP are interesting, but are not pivotal to an understanding of process issues. If time permits and your students (or you) have an interest, a discussion is worthwhile. The key point to emphasize is that individuals and teams should measure their work and the errors they make and act to improve their approach so that the causes of errors are eliminated.
2.7 Process Technology
Acquire a process technology tool and demonstrate its capabilities. Emphasize that the key to success is a process that is tuned to the people, the project and the product. Tools help. But they are not a panacea.
2.8 Product and Process
I really enjoyed Davis’ piece when I first read it years ago. She nails many of the issues associated with “the duality of product and process.” Also note Benjamin Cardozo’s (a famous Supreme Court justice) quote. He’s talking about the legal code, but I thought his comments were a nice metaphor for process descriptions.
No comments:
Post a Comment