Full file at http://testbanksolutions.org/Instructor-Manual-for-Software-Engineering-A-Practitioner-Approach-7th-Edition-Roger-Pressman
Part 1 The Software Process
Chapter 2
Process Models
CHAPTER OVERVIEW AND COMMENTS
This intent of this chapter is to present a generic software process model that can be used as a template for all other process models presented in this book. 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 A Generic Process Model
Because so many process models are in existence, it’s a good idea to provide a common way of looking at them. The generic process model presented here is a simple, yet effective tool for considering more complex models discussed in this and other chapters. It’s important to note that my selection of the five framework activities, although representative, is not “industry standard” (there is no such thing). Therefore, you can, if you choose, select other terminology. Regardless, it’s very important to emphasize this section.
2.2 Process Assessment and Improvement
Software process assessment and improvement are important issues but a detailed discuss have been delayed until Chapter 30. I foreshadow the topic here for completeness. You can choose to expand upon it by using content from Chapter 30 now.
If your enrollment is mostly industry professionals, this section can be discussed in detail at this point. If, however, your students are undergrads with little real-world experience, you should note that process “standards” do exist, and that the CMMI is an important one. Also note, that the success in building large software-based systems correlates with an organization’s capability level.
2.3 Prescriptive Process Models
Many people (and not a few professors) believe that prescriptive models are “old school”—ponderous, bureaucratic document-producing machines. Disabuse your students of this notion. Every prescriptive process presented in this chapter can be streamlined (made agile). Note that “prescriptive” simply means that the process model identifies a set of process elements—framework activities, software engineering actions, tasks, work products, quality assurance and change control mechanisms—for each project.
It is easy for students to become so lost in the details of the various process models that they fail to see the features the models have in common with each other. Refer back to Section 2.1 to emphasize generic similarities. Another difficulty students have is their belief that each activity within the process is performed completely independently of the other activities. The reality is that there tends to be lots overlap among these activities.
2.3.1 The Waterfall Model
Many people dismiss the waterfall as obsolete and it certainly does have problems. But this model can still be used in some situations. Be certain your students understand where it can and cannot be used and why.
2.3.2 Incremental Process Models
The process models in this category tend to be among the most widely used (and effective) in the industry. Be certain your students understand the conditions under which such models should be used and what an “increment” means in terms of project work and delivery. Have them take a look at a popular software package and describe how they would plan increments over the production cycle.
2.3.3 Evolutionary Process Models
Be sure your students understand the subtle difference between an evolutionary model and an incremental model and that fact that an evolutionary process flow can still implement an incremental delivery. Discuss the pros and cons of prototyping and how it differs from the spiral. Note that the spiral I present here is somewhat different than Boehm’s original work, which emphasized a risk-driven process to an even greater extent. It’s also important to note that as workflow moves outward along the spiral (Figure 2.7), the software moves closer to completion. In the extreme, the spiral flow can be applied across the entire lifecycle, from product inception to maintenance.
2.4 Specialized Process Models
Be certain your students understand that the component-based development (CBD) model incorporates many of the iterative characteristics of the spiral model. The main difference is that in CBD the emphasis is on composing solutions from prepackaged software components or classes. This CBD emphasizes software reusability. Further discussion of CBD can be found in Chapter 10.
At this stage, you may choose not to consider the FM and AOSD models, postponing any discussion until Chapter 21 (if you choose to consider the topics at all).
2.5 The Unified Process
I’ve included the UP in this chapter for completeness and because I use UML as a modeling notation throughout this book. The phased approach noted can be mapped nicely into the generic framework introduced in earlier in this chapter. If you consider the UP, you should discuss what use-cases are (this is covered in detail in later chapters) and why a “use-case driven process” has merit.
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.