PROCESS MODELS

CHAPTER III

TOPICS COVERED

• Prescriptive Models• The Waterfall Model• Incremental Models (RAD)• Evolutionary Process Models (Prototyping, spiral

, Concurrent)• Specialized Process Models( Component based

models)• Unified Process Models• Case Study• Conclusion

Prescriptive (conventional) Process Models

• What is it ?• PP Models defines a distinct set of activities ,

actions , tools , milestones and work product that are required to engineer high quality software.

• These models are always not perfect.• But then they are useful roadmap for software

engineering work.

Contd..

• What are the steps ?• The process guides a software team

through a set of framework activities to be followed.

• The terminology and details of each process model is different but they provide a generic set of framework activities i.e communication , planning , modeling , construction , deployment.

The Waterfall Model

• The waterfall model sometimes called as LINEAR SEQUENTIAL OR CLASSIC LIFE CYCLE suggests a systematic sequential approach to software development.

• It is the oldest paradigm of software engineering

Contd…

• There are times when the problems are reasonably well understood, when work flows in reasonably sequential manner- from communication to deployment.

• It is used when well defined adaptations or enhancements are to be made but only when requirements are well defined and reasonably stable

Contd….

Communication Planning- Estimating Scheduling

tracking Modeling- Analysis Design

Deployment- Delivery Support Feedback

Construction- Code Test

Problems Encountered

• Real projects rarely follow the sequential flow that the model proposes.

• Changes can cause confusion as project team proceeds.

• It is often difficult for the customer to state all the requirements explicitly in the beginning.

• The customer must have patience as the working version of the program will not be available until the cycle completes.

Incremental Process Models

• There are many situations when there is 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 situations a process model that is designed to produce the software in increments are chosen.

The Incremental Model

Increment 1

Increment 2

Increment 3

Delivery of 1st increment

Delivery of 2nd increment

Contd..

• The incremental model delivers a series of releases called increments, that provide progressively more functionality for the customer as each increment is delivered.

• When an incremental model is used , the first increment is only the core product the basic .

Suggestions

• If your customer demands a delivery by a date that is impossible to meet suggest delivering one or more increments by that date and the rest of software later.

• The incremental model is iterative in nature • Increments can be planned to manage technical

risks. – for eg a major system might require the availability of new hardware that is under development and whose delivery date is uncertain. It might be possible to plan early increments without that h/w .

The RAD Model

• Rapid Application Development (RAD) is an incremental software process model that emphasizes a short development cycle.

• The RAD model is a high speed adaptation of the waterfall model in which rapid development is achieved using component based construction approach.

The RAD Model

comm

plan

model

const

model

const

model

const

Team #1

Team #2

Team #3

Deployment

60-90 days

Contd

• If a business application can be modularized in a way that enables each major function to be completed in less than three months It is a candidate for RAD.

• Each major function can be addressed by a separate RAD team and then integrated to form a whole.

Drawbacks of RAD

• For large but scalable projects RAD requires sufficient human resources to create the right number of RAD teams.

• If developers and customers are not committed to the rapid fire activities necessary to complete the system in much abbreviated time frame RAD projects will fail.

• If a system cannot be properly modularized the RAD will be problematic

• RAD may not be appropriate when technical risks are high.

Evolutionary Process Model Prototyping

• Evolutionary process models produce an increasingly more complete version of the software with each iteration.

• Evolutionary models are iterative in nature.• When a customer defines a set of general objectives for

software , but does not identify detailed input , processing or output requirements

• When the developer may be unsure about the efficiency of algorithm the adaptability of operating system

• In these and many other situations a prototyping paradigm may offer a best solution.

Steps

• Communication

• Quick Plan

• Modeling quick Design

• Construction of Prototype

• Deployment Delivery & Feedback

Contd..

• The prototyping begins with communication. The software Engineer and customer meet and 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 quick design occurs.

• The quick design leads to the construction of prototype.

• The prototype is deployed and evaluated by the customer.

Contd..

• Feedback is used to refine requirements for the software.

• Iteration occurs as the prototype is tuned to satisfy the needs for the customer while at the same time abling the developer to better understand what needs to be done.

Suggestions

• When your customer has a legitimate need but is clueless about the details develop a prototype first.

• In most projects the first system built is barely usable. It may be to slow , too big , awkward in use or all three. Then there is no alternative but to start again. ….. When a new design system or a new technology is used , one has to build a system to throw away for even the best planning is not so as to get it right the first time.

Contd…

• The management question therefore is not whether to built a pilot system and to throw it away. The only question is whether to plan in advance to build a throwaway or to promise to deliver the throwaway to customers.

Drawbacks

• Resist pressure to extend a rough prototype into a production product . Quality almost suffers as a result.

• The developers often makes implementation compromises in order to get a prototype working quickly.

Conclusions

• Although problems can occur prototyping can be a effective paradigm for software engineering .

• The key is to define the rules of game at the beginning that is the customer and developer must both agree that a prototype is built to serve as a mechanism for defining requirements.

• It is then discarded and the actual software is engineered with an eye towards quality.

The Spiral Model

• The problem with the conventional model is that they do not deal sufficiently with the uncertainty , which is inherent to software projects.

• Important software projects have failed because project risk were neglected and nobody was prepared when some unforeseen happened .

Contd…

• Barry Boehm recognized this and tried to incorporate the “project risk factor” into a life cycle model.

• The result is the spiral model which was presented in 1986

• This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive, and complicated projects.

•

Detailed Description

• The radial dimensions of the model represents the cumulative cost.

• Each path of the spiral is indicative of increased cost.

• The angular Dimension represent the progress made in completing each cycle.

Contd..

• Each loop of the spiral from x axis clockwise through 360 degree represents one phase.

• One phase is split roughly into four sectors of major activities.

Contd….

• Planning: Determination of objectives , alternatives and constraints.

• Risk Analysis : Analyze alternatives and attempts to identify and resolve risk involved.

Contd..

• Development : Product development and testing products.

• Assessment : customer evaluation

Contd..

• During the first phase planning is performed , risks are analyzed , prototypes are built and customer evaluate the prototype.

• During the second phase a more refined prototype is built , requirements are documented and validated customers are involved in assessing the new prototype.

Contd…

• By the time third phase begins risks are known and somewhat more tradition approach is taken.

• The focus is the identification of problems and classification of these into different level of risks the aim being to eliminate high risk problem before they threaten the software operation or cost.

Contd..

• An important feature of spiral model is that each phase is completed and reviewed by the people concerned with the project (designers and programmers).

• This review consist of a review of all the products developed up to that point and includes plans for the next cycle.

• If the plan for the development fails, then the spiral is terminated . Otherwise it terminates with the initiation of new or modified software.

• The steps in the spiral model can be generalized as follows:

• The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.

• A preliminary design is created for the new system. • A first prototype of the new system is constructed from

the preliminary design. • A second prototype is evolved by a fourfold procedure:

(1) evaluating the first prototype in terms of its strengths, weaknesses, and risks; (2) defining the requirements of the second prototype; (3) planning and designing the second prototype; (4) constructing and testing the second prototype.

Summarization

Contd…• At the customer's option, the entire project can be aborted if the risk

is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product.

• The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above.

• The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.

• The final system is constructed, based on the refined prototype. • The final system is thoroughly evaluated and tested. Routine

maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime

Advantages

• Estimates (i.e. budget, schedule, etc.) get more realistic as work progresses, because important issues are discovered earlier.

• It is more able to cope with the (nearly inevitable) changes that software development generally entails.

• Software engineers (who can get restless with protracted design processes) can get their hands in and start working on a project earlier.