Prescriptive Process Model
Perspective process model were originally proposed to bring order to the chaos of software development
• It defines a framework activities, s/w engineering actions, tasks, milestones, quality assurance and work products that are required to engineer high-quality software
• Each peocess model also prescribes a work flow, that is the manner in which the process element are interrelated to one another.
• The activities may be linear, incremental, or evolutionary
Waterfall Model
• It is also called classic life cycles, suggests a systemetic, sequential approach to s/w develoment,which begins with customer specification of requirements and progresses through planning,modeling,construction and deployment.
• It is the oldest software life cycle model and best understood by upper management
• It is used when requirements are well understood and risk is low.
• The work flow in waterfall model is in a linear (i.e., sequential) fashion
• It is used often with well-defined adaptations or enhancements to current software
Waterfall Model Problems:-
• It doesn't support iteration, so changes can cause confusion
• It is difficult for customers to state all requirements explicitly and up front
• It requires customer patience because a working version of the program doesn't occur until the final phase
• Problems can be somewhat solved in the model through the addition of feedback loops Waterfall Model with Feedback
•
• A variation in the representation of the waterfall model is called V-model.
The model shows the relationship of quality assurance actions and the actions associated with communication, modelling and construction activities.
As a s/w team move down to the left side of the V, the basic problem requirements are refined.
once code has been generated, the team moves up the right side of the V.
The V- model provide a way of visualizing how verification and validation actions are applied ro engineering work.
Incremental Model
• It is used when requirements are well understood
• In this model multiple independent deliveries are identified
• The work flow is in a linear (i.e., sequential) fashion within an increment and is staggered between increments
• It is iterative in nature; focuses on an operational product with each increment
• It provides a needed set of functionality sooner while delivering optional components later
It is useful also when staffing is too short for a full-scale development
Prototyping Model
• It follows an evolutionary and iterative approach
• It is used when requirements are not well understood
• It serves as a mechanism for identifying software requirements
• It focuses on those aspects of the software that are visible to the customer/user
• In this model Feedback is used to refine the prototype
Prototyping Model
(Potential Problems)
• The customer sees a "working version" of the software, wants to stop all development and then buy the prototype after a "few fixes" are made
• Developers often make implementation compromises to get the software running quickly (e.g., language choice, user interface, operating system choice, inefficient algorithms)
• Lesson learned
• Define the rules up front on the final disposition of the prototype before it is built
• In most circumstances, plan to discard the prototype and engineer the actual production software with a goal toward quality
Spiral Model
It is invented by Dr. Barry Boehm in 1988 while working at TRW
• It follows an evolutionary approach
• Used when requirements are not well understood and risks are high
• Inner spirals focus on identifying software requirements and project risks; may also incorporate prototyping
• Outer spirals take on a classical waterfall approach after requirements have been defined, but permit iterative growth of the software
• Operates as a risk-driven model…a go/no-go decision occurs after each complete spiral in order to react to risk determinations
• Requires considerable expertise in risk assessment
• Serves as a realistic model for large-scale software development
Rapid Application Development Model
Focuses on a SHORT DEVELOPMENT CYCLE.
Requirements are well-understood and project scope is constrained.
High-speed adaptation of the waterfall model , in which Rapid
development is achieved by using a component based construction
approach where each major function is completed in 60 to 90 days.
Maps into generic framework activities.
Communication : works to clearly understand the business problem.
Planning: imp. As multiple teams work in parallel on different
system functions.
Modeling: encompasses Business modeling, data modeling and
process modeling and establishes design representations.
Construction:
Deployment:
Incremental Model: As Increments or advancements are delivered
iteratively in every 60 to 90 days
Drawbacks:
For large, but scalable projects, RAD requires sufficient HR to
create the right number of RAD teams that will be working in
parallel.
If developers and customers are not committed to Rapid-Fire-
Activities necessary to complete the system, RAD projects fail.
If the system cannot be properly modularized, building the
Components necessary for RAD will be problematic.
If high performance is an issue, and performance is to be achieved
through tuning the interfaces to the subsystem components, then
RAD approach may not work.
RAD may not be appropriate when technical risks are high.
Evolutionary Development Models
Software like all complex systems , evolves over a period of time.
Business and product requirement often change as development
proceeds, making a straight line path to an end product unrealistic.
The set of core product / system requirements is well understood,
but the details of the product/ system extensions have yet to be
defined.
Evolutionary models are iterative.
They are characterized in a manner that software engineers to
develop increasingly more complete versions of the software.
Types of Evolutionary Models
• Prototyping
• Spiral Model
• Concurrent Development model
General Weaknesses of Evolutionary Process Models
• Prototyping poses a problem to project planning because of the uncertain number of iterations required to construct the product
• Evolutionary software processes do not establish the maximum speed of the evolution
• If too fast, the process will fall into chaos
• If too slow, productivity could be affected
• Software processes should focus first on flexibility and extensibility, and second on high quality
• We should prioritize the speed of the development over zero defect Extending the development in order to reach higher quality could result in late delivery
Prototyping:-
• It follows an evolutionary and iterative approach
• It is used when requirements are not well understood
• It serves as a mechanism for identifying software requirements
• It focuses on those aspects of the software that are visible to the customer/user
• In this model Feedback is used to refine the prototype
Prototyping Model (Potential Problems):-
• The customer sees a "working version" of the software, wants to stop all development and then buy the prototype after a "few fixes" are made
• Developers often make implementation compromises to get the software running quickly (e.g., language choice, user interface, operating system choice, inefficient algorithms)
• Lesson learned
• Define the rules up front on the final disposition of the prototype before it is built
• In most circumstances, plan to discard the prototype and engineer the actual production software with a goal toward quality
Spiral Model
It is invented by Dr. Barry Boehm in 1988 while working at TRW
• It follows an evolutionary approach
• Used when requirements are not well understood and risks are high
• Inner spirals focus on identifying software requirements and project risks; may also incorporate prototyping
• Outer spirals take on a classical waterfall approach after requirements have been defined, but permit iterative growth of the software
• Operates as a risk-driven model…a go/no-go decision occurs after each complete spiral in order to react to risk determinations
• Requires considerable expertise in risk assessment
• Serves as a realistic model for large-scale software development
The Spiral Model
One of the most generic of all the models presented by Boehm in 1985.
Most life cycle models can be derived as special cases of the spiral model.
The spiral uses a risk management approach to software development.
The spiral model is therefore iterative
In each iteration analyze the results of the previous iteration, determine the risk and build a prototype
During the first circuit, the objectives, alternatives and constraints
are defined.
The Engineering may follow the life cycle approach or a prototyping
approach. The customer evaluates the work and makes suggestions for modifications..
A Spiral Model, combines the iterative nature of prototyping with the controlled and systematic aspects of the Waterfall Model, therein providing the potential for rapid development of incremental versions of the software. A Spiral Model is divided into a number of framework activities, also called task regions. These task regions could vary from 3-6 in number and they are:
• Customer Communication - tasks required to establish effective communication between the developer and customer.
• Planning - tasks required to define resources, timelines and other project related information /items.
• Risk Analysis - tasks required to assess the technical and management risks.
• Engineering - tasks required to build one or more representation of the application.
• Construction & Release - tasks required to construct, test and support (eg. Documentation and training)
• Customer evaluation - tasks required to obtain periodic customer feedback so that there are no last minute surprises.
Advantages of the Spiral Model
• Realistic approach to the development because the software evolves as the process progresses. In addition, the developer and the client better understand and react to risks at each evolutionary level.
• Focus on early error detection and design flaws
• Gives an early focus to reusable software
• Can be used for hardware-software system development
• The model uses prototyping as a risk reduction mechanism and allows for the development of prototypes at any stage of the evolutionary development.
• It maintains a systematic stepwise approach, like the classic waterfall model, and also incorporates into it an iterative framework that more reflect the real world.
Disadvantages of the Spiral Model
• One should possess considerable risk-assessment expertise
• It has not been employed as much proven models (e.g. the Waterfall Model) and hence may prove difficult to ‘sell’ to the client.
Concurrent development model
Fig. One element of concurrent model
The concurrent process model defines a series of events that will trigger transition from state to state for each of the SW engineering activities, actions or tasks. All activities exist concurrently but reside in different states
E. g. The modelling activity which existed in none state while initial communication was completed now makes a transition into under development state. If customer indicates that changes in requirements must be made, modelling activity moves from under development state into awaiting changes state
Is applicable to all types of software development and provides an accurate picture of the current state of 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
General Weaknesses of Evolutionary Process Models
• Prototyping poses a problem to project planning because of the uncertain number of iterations required to construct the product
• Evolutionary software processes do not establish the maximum speed of the evolution
• If too fast, the process will fall into chaos
• If too slow, productivity could be affected
• Software processes should focus first on flexibility and extensibility, and second on high quality
• We should prioritize the speed of the development over zero defects
• Extending the development in order to reach higher quality could result in late delivery
A final word on evolutionary processes:-
Modern computer software is characterized by continual change, by very tight time lines and by an emphatic need for customer-user satisfaction.
Evolutionary process models were conceived to address these issues.
We have some concern with evolutionary model
• The first concern is that the prototyping poses a problem to project planning because of the uncertain number of cycles required to construct the product.
• Second, evolutionary software processes do not establish the maximum speed of the evolution.
• Third software processes should focused on flexibility and extensibility rather than on high quality.
The intend of evolutionary models is to develop high quality software in an iterative or incremental manner.
This comment has been removed by the author.
ReplyDelete