Prescriptive process model were originally proposed to bring order to the chaos of software development. Prescriptive process model define a prescribed set of process elements and a predictable process work flow.
“prescriptive” because they prescribe a set of process elements framework activities, software engineering actions, tasks, work products, quality assurance, and change control mechanisms for each project.
The Waterfall Model
The waterfall model, sometimes called the classic life cycle, suggests a systematic, sequential approach to software development that begins with customer specification of requirements and progresses through planning, modeling, construction, and deployment.
A variation in the representation of the waterfall model is called the V-model. Represented in following figure. The V-model depicts the relationship of quality assurance actions to the actions associated with communication, modeling, and early construction activities.
As a software team moves down the left side of the V, basic problem requirements are refined into progressively more detailed and technical representations of the problem and its solution.
Once code has been generated, the team moves up the right side of the V, essentially performing a series of tests that validate each of the models created as the team moved down the left side. The V-model provides a way of visualizing how verification and validation actions are applied to earlier engineering work.
The waterfall model is the oldest paradigm for software engineering. The problems that are sometimes encountered when the waterfall model is applied are: Prescriptive Process Model
- 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(s) will not be available until late in the project time span.
This model is suitable when ever limited number of new development efforts and when requirements are well defined and reasonably stable.
Incremental Process Models
The incremental model delivers a series of releases, called increments, that provide progressively more functionality for the customer as each increment is delivered.
The incremental model combines elements of linear and parallel process flows discussed in before section. The incremental model applies linear sequences in a staggered fashion as calendar time progresses.
Each linear sequence produces deliverable “increments” of the software in a manner that is similar to the increments produced by an evolutionary process flow.
For example, word processing software developed using the incremental paradigm might deliver basic file management, editing, and document production functions in the first increment; more sophisticated editing and document production capabilities in the second increment; spelling and grammar checking in the third increment; and advanced page layout capability in the fourth increment.
When an incremental model is used, the first increment is often a core product. That is, basic requirements are addressed but many supplementary features remain undelivered.
The core product is used by the customer. As a result of use and/or evaluation, a plan is developed for the next increment. The plan addresses the modification of 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.
Incremental development is particularly useful when staffing is unavailable for a complete implementation by the business deadline that has been established for the project.
Early increments can be implemented with fewer people. If the core product is well received, then additional staff (if required) can be added to implement the next increment. In addition, increments can be planned to manage technical risks.
Evolutionary Process Models
Evolutionary models are iterative. They are characterized in a manner that enables you to develop increasingly more complete versions of the software with each iteration. There are two common evolutionary process models.
Prototyping Model : Often, a customer defines a set of general objectives for software, but does not identify detailed requirements for functions and features.
In other cases, the developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system, or the form that human-machine interaction should take.
In these, and many other situations, a prototyping paradigm may offer the best approach.
Although prototyping can be used as a stand-alone process model, it is more commonly used as a technique that can be implemented within the context of any one of the process models.
The prototyping paradigm begins with communication. You meet with other stakeholders to define the overall objectives for the software, identify whatever requirements are known, and outline areas where further definition is mandatory.
A prototyping iteration is planned quickly, and modeling (in the form of a “quick design”) occurs. A quick design focuses on a representation of those aspects of the software that will be visible to end users.
The quick design leads to the construction of a prototype. The prototype is deployed and evaluated by stakeholders, who provide feedback that is used to further refine requirements.
Iteration occurs as the prototype is tuned to satisfy the needs of various stakeholders, while at the same time enabling you to better understand what needs to be done.
The prototype serves as a mechanism for identifying software requirements. If a working prototype is to be built, you can make use of existing program fragments or apply tools that enable working programs to be generated quickly.
The prototype can serve as “the first system.” Prototyping can be problematic for the following reasons:
- Stakeholders see what appears to be a working version of the software, unaware that the prototype is held together haphazardly, unaware that in the rush to get it working you haven’t considered overall software quality or long-term maintainability.
- As a software engineer, you often make implementation compromises in order to get a prototype working quickly. An inappropriate operating system or programming language may be used simply because it is available and known; an inefficient algorithm may be implemented simply to demonstrate capability.
Although problems can occur, prototyping can be an effective paradigm for Prescriptive Process Model software engineering.
The Spiral Model : Originally proposed by Barry Boehm, the spiral model is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model.
It provides the potential for rapid development of increasingly more complete versions of the software. Boehm describes the model in the following manner.
The spiral development model is a risk driven process model generator that is used to guide multi stakeholder concurrent engineering of software intensive systems. It has two main distinguishing features.
One is a cyclic approach for incrementally growing a system’s degree of definition and implementation while decreasing its degree of risk. The other is a set of anchor point milestones for ensuring stakeholder commitment to feasible and mutually satisfactory system solutions.
Using the spiral model, software is developed in a series of evolutionary releases. During early iterations, the release might be a model or prototype.
During later iterations, increasingly more complete versions of the engineered system are produced.
A spiral model is divided into a set of framework activities defined by the software engineering team. As this evolutionary process begins, the software team performs activities that are implied by a circuit around the spiral in a clockwise direction, beginning at the center.
Risk is considered as each revolution is made. Anchor point milestones are a combination of work products and conditions that are attained along the path of the spiral are noted for each evolutionary pass.
The first circuit around the spiral might result in the development of a product specification; subsequent passes around the spiral might be used to develop a prototype and then progressively more sophisticated versions of the software. Each pass through the planning region results in adjustments to the project plan.
The spiral model can be adapted to apply throughout the life of the computer software. Therefore, the first circuit around the spiral might represent a “concept development project” that starts at the core of the spiral and continues for multiple iterations until concept development is complete.
The new product will evolve through a number of iterations around the spiral. Later, a circuit around the spiral might be used to represent a “product enhancement project.”
The spiral model is a realistic approach to the development of large scale systems and software. Because software evolves as the process progresses, the developer and customer better understand and react to risks at each evolutionary level.
It maintains the systematic stepwise approach suggested by the classic life cycle but incorporates it into an iterative framework that more realistically reflects the real world.
Concurrent Models
The concurrent development model, sometimes called concurrent engineering, allows a software team to represent iterative and concurrent elements of any of the process models.
The concurrent model is often more appropriate for product engineering projects where different engineering teams are involved.
These models provides a schematic representation of one software engineering activity within the modeling activity using a concurrent modeling approach.
The activity modeling may be in any one of the states noted at any given time. Similarly, other activities, actions, or tasks (communication or construction) can be represented in an analogous manner.
All software engineering activities exist concurrently but reside in different states. Concurrent modeling defines a series of events that will trigger transitions from state to state for each of the software engineering activities, actions, or tasks.
This generates the event analysis model correction, Prescriptive Process Model which will trigger the requirements analysis action from the done state into the awaiting changes state.
Concurrent modeling is applicable to all types of software development and provides an accurate picture of the current state of a project.
Each activity, action, or task on the network exists simultaneously with other activities, actions, or tasks. Events generated at one point in the process network trigger transitions among the states.
| Read More Topics |
| Software engineering a layered technology |
| Image processing |
| Software requirement and quality assurance |
| The Domain Name System (DNS) |
