Chapter 3

Chapter 3

Prescriptive Process Models

CHAPTER OVERVIEW AND COMMENTS

This intent of this chapter is to present process models used by professional software developers to manage large-scale software projects.  No software process works well for every project. However, every project needs to conform to some systematic process in order to manage software development activities that can easily get out of control. Software processes help to organize the work products that need to be produced during a software development project. Ultimately the best indicator of how well a software process has worked is the quality of the deliverables produced. A well-managed process will produce high quality products on time and within budget.

3.1    Prescriptive 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 simple 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 Chapter 2 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.

3.2    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.

3.3    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.

3.4    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 3.5), the software moves closer to completion. In the extreme, the spiral flow can be applied across the entire lifecycle, from product inception to maintenance.

3.5    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. At this stage, you may choose not to consider the FM  and AOSD models, postponing any discussion until advanced topics are considered late in the course.

3.6    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 Chapter 2. 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.