INF3705_ summary notes.

CHAPTER 3 – PROCESSMODELS. 1.1 PRESCRIPTIVEMODELSORCONVENTIONALMODELS. Every software engineering organization should describe a unique set of framework activities for the software processes it adopts. It should populate each framework activity with a set of software engineering actions, and define each action in terms of a task set that identifies the work (and work products) to be accomplished to meet the development goals. It should then adapt the resultant process model to accommodate the specific nature of each project, the people who will do the work and the environment in which the work will be conducted. Regardless of the process model that is selected, software engineers have traditionally chosen a generic process framework that encompasses the following framework activities: • Communication – This framework activity involves heavy communication and collaboration with the customer (and other stakeholders) and encompasses requirements gathering and related activities. • Planning – This activity establishes a plan for the software engineering work that follows. It describes the technical tasks to be conducted, the risks that are likely, the resources that will be required, the work products to be produced, and a work schedule. • Modeling – this activity encompasses the creation of models that allow the developer and the customer to better understand software requirements and the design that will achieve those requirements. • Construction – This activity combines code generation (either manual or automated) and the testing that is required to uncover errors in the code. • Deployment – The software (as a complete entity or as a partially completed increment) is delivered to the customer who evaluates the delivered product and provides feedback based on the evaluation. We call these models prescriptive because they prescribe a set of process elements namely framework activities, software engineering actions, tasks, work products, quality assurance and change control mechanisms for each project. Each process model also prescribes a workflow that is, the manner in which the process elements are interrelated to one another. All software process models can accommodate the generic framework activities, but each applies a different emphasis to these activities and defines a workflow that invokes each framework activity (as well as software engineering actions and tasks) in a different manner. 1.2 THE WATERFALLMODEL. There are times when requirements of a problem are reasonably well understood, when work flows from communication through deployment in a reasonably linear fashion. This situation is sometimes encountered when well-defined adaptations or enhancements to an existing system must be made. It may also occur in a limited number of new development efforts, but only when requirements are well-defined and reasonably stable. The waterfall model, sometimes called the classic life cycle, suggest a systematic, sequential approach to software development that begins with customer specification of requirements and progresses through planning, modeling, construction, and deployment, culminating in on-going support of the completed software. The waterfall model is the oldest paradigm for software engineering. However, over the past two decades, criticism of this process model has caused even ardent supporters to question its efficacy. Among the problems that are sometimes encountered when the waterfall model is applied are: • Real projects rarely follow the sequential flow that the model proposes. Although the linear model can accommodate iteration, it does so indirectly. As a result, changes can cause confusion as the project team proceeds. • It is often difficult for the customer to state all requirements explicitly. The waterfall model requires this and has difficulty accommodating the natural uncertainty that exists at the beginning of many projects. • The customer must have patience. A working version of the program will not be available until late in the project time-span. A major blunder, if undetected until the working program is reviewed, can be disastrous. In an interesting analysis of actual projects it was found that the linear nature of the waterfall model leads to “blocking states” in which some project team members must wait for other members of the team to compete dependent tasks. In fact, the time spent waiting can exceed the time spent on productive work. The blocking state tends to be more prevalent at the beginning and end of a linear sequential process. Today, software work is fast-paced and subject to a never-ending stream of changes (to features, functions and information content). The waterfall model is often inappropriate for such work. However, it can serve as a useful process model in situations where requirements are fixed and work is to proceed to completion in a linear manner. 1.3 INCREMENTALPROCESSMODEL. There are many situations in which initial software requirements are reasonably well-defined, but the overall scope of the development effort precludes a purely linear process. In addition, there may be a compelling need to provide a limited set of software functionality to users quickly and then refine and expand on that functionality in later software releases. In such cases, a process model that is designed to produce the software in increments is chosen. 1.3.1 THE INCREMENTAL MODEL. The incremental model combines elements of the waterfall model applied in an iterative fashion. The incremental model applies linear sequences in a staggered fashion as calendar time progresses. Each linear sequence produces deliverable increments of the software. It should be noted that the process flow for any increment may incorporate the prototyping paradigm. When an incremental model is used, the first increment is often a core product. That is, basic requirements are addressed, but many supplementary features (some known, others unknown) remain undelivered. The core product is used by the customer (or undergoes detailed evaluation). As a result of use and or evaluation, a plan is developed for the next increment. The plan addresses the modification to the core product to better meet the needs of the customer and the delivery of additional features and functionality. This process is repeated following the delivery of each increment, until the complete product is produced. The incremental process model, like prototyping and other evolutionary approaches, is iterative in nature. But unlike prototyping, the incremental model focuses on the delivery of an operational product with each increment. Early increments are “stripped down” versions of the final product, but they do provide capability that serves the user and also provides a platform for evaluation by