What is the Evolutionary Process Model

Zia

2 Followers

Follow

May 20, 2024

-

0 sec read

418

0

0

0

Evolutionary Process Model

There is a growing recognition that software, like all complex systems, evolves over a while. Business and product requirements often change as development proceeds, making a straight-line path to an end product unrealistic; tight market deadlines make completion of a comprehensive software product impossible, but a limited version must be introduced to meet competitive or business pressure; a set of core products or system requirements is well understood, but the details of product or system extensions have yet to be defined. In these and similar situations, software engineers need a process model that has been explicitly designed to accommodate a product that evolves.

The linear sequential model is designed for straight-line development. In essence, this Waterfall approach assumes that a complete system will be delivered after the linear sequence is completed. The prototyping model is designed to assist the customer (or developer) in understanding requirements. In general, it is not designed to deliver a production system. The evolutionary nature of software is not considered in this classic software engineering paradigm.

Evolutionary models are iterative. They are characterized in a manner that enables software engineers to develop increasingly more complete versions of the software. The basic difference between the traditional waterfall model and the iterative process is how the project tasks are contained in the plan. In the Waterfall model, they are functionally contained, while in the iterative model, they are time-based.

1. Iterative Approach

Unlike the Waterfall model, the iterative model does not start with all the requirements upfront. Development begins by determining and implementing a part of the software project, which is then reviewed to identify further requirements. The process is then repeated and a new version of the software is created for each model cycle.

in an iterative process, a portion of the overall requirements is considered for implementation. Successive iterations of the implementation help in software upgradation and evolution of different Versions until the final products are implemented and deployed. Such a process helps to identify results in an early stage and also obtain timely feedback from the users. Every iteration acts like a mini Waterfall model due to feedback from one phase being fed as input to the next phase.

At the end of each iteration, working software is delivered which is f fed to the next iteration.

The key to successful use of an iterative software development life cycle is correct validation of requirements, verification, and testing of each version of the software against the requirements in each cycle of the model.

The main features of iterative development are as follows:

• Time-boxed phases
• Test early, test often
• Deliver early, deliver often
• Production quality
  
  
  

2. Benefits of Iterative Approach

An iterative approach is generally superior to a linear or Waterfall approach for many different reasons: 

• It tolerates changing requirements - The reality is that normal requirements change. Requirement change and requirements 'creep' have always been a primary source of project trouble, leading to late delivery, missed schedules, unsatisfied customers, and frustrated developers.
  
  
• Elements are integrated progressively - Integration is not one 'big bang' at the end. The iterative approach is almost a continuous integration. What used to be a long uncertain and troublesome time, taking up to 40% of the total effort at the end of a project, is now broken into six to nine smaller integrations that begin with fewer elements.
  
  
• Risks are mitigated earlier - Integration is generally the only time risk factors are discovered or addressed. As we unroll the early iterations we go through all core process workflows, exercising many aspects of the project: tools, off-the-shelf software, people skills, and so on, Some perceived risks may prove not to be risks at all, and new, unsuspected risks may emerge.
  
  
• It allows the organization to learn and improve - Team members can learn along the way, and the various competencies and specialties are more fully employed during the whole life cycle. Testers start testing early, technical writers write early, and so on. In non-iterative development, the same people will wait to begin their work, make plans, and hone their skills. Training needs or the need for additional (perhaps external) help is spotted early on during assessment reviews.
  
  
• It facilitates reuse - Design reviews in early iterations, allows architects to identify unsuspected potential reuse, and develops and matures common code in subsequent iterations.
  
  
• It results in a more robust product - As we are correcting errors over several iterations. Flaws are detected even in the early iterations as the product moves beyond inception. Performance bottlenecks are discovered when they can still be addressed, instead of on the eve of delivery. The outcome is a higher level of quality.
  
  
• It tolerates tactical changes in the product - For example, to compete with existing products. We can decide to release a product with reduced functionality earlier to counter a move by a competitor, or we can adopt another vendor for a given technology.
  
  
• The process itself can be improved and refined along the way - The assessment at the end of an iteration not only looks at the status of the project from a product and schedule perspective, but also analyzes what should be changed in the organization, and in the process to perform better in the next iteration.
  
  A customer once said: "With the Waterfall approach, everything looks fine until near
  
  the end of the project, sometimes up until the middle of integration. Then everything
  
  falls apart. With the iterative approach, it is very difficult to hide the truth for very long". Unfortunately, project managers often resist the iterative approach, seeing it as a kind of endless 'hacking'.
  
  
• Accommodates changes - It allows us to take into account changing requirements. Users will change their minds along the way. This is part of human nature. Forcing the users to accept the system as they originally imagined it is wrong. They change their mind because the context changes, they learn more about the environment and the technology, and they see an intermediate demonstration of the product, as it is being developed.
  
  
• It allows technological changes on the way - If the technology changes it becomes a Standard, or new technology appears, the project can take advantage of it. This is particularly true for platform changes or lower-level infrastructure changes.
  
  
• Increasing reuse - It facilitates reuse, because it is easier to identify common parts as they are partially designed or implemented, compared to identifying all commonalities up front. It is difficult to identify and develop reusable parts.
  
  
• Design reviews in early iterations allow architects to identify unsuspected, potential reuse, and subsequent iterations allow us to develop and mature this common code.
  
  
• It is easier to take advantage of Commercial-Off-the-Shelf (COTS) products - We have several iterations to select them, integrate them, and validate that these fit into the architecture.
  
  
• Learning - The developers can learn along the way, and the various competencies and specialties are fully employed during the whole life cycle. Testers and technical writers can start testing and documentation work earlier, rather than waiting for a long time, and simply making plans and honing skills. The need for additional training or external help can be detected in the early iteration assessment reviews.
  
  The process itself can be improved and refined as it develops. The assessment at the end of iteration not only looks at the status of the project from a product-schedule perspective, but also analyzes what should be changed in the organization, and the process to perform better in the next iteration.
  
  
• It results in a more thoroughly tested product - The critical functions have had many opportunities to be tested over several iterations. The tests themselves and any test software will have had time to mature, as opposed to tests run once toward the end of the project.
  
  
  
  

3. Problems with Iterative Approach

The critical milestone in evolutionary development is the initial release: a package of software with sufficient capability to serve as a basis for user exercise, evaluation, and evolutionary improvement.

However, this 'initial release' milestone frequently has the following problems:

• Inflexible point-solutions:-
  Frequently, the initial release is optimized for initial demonstration mode and exploratory mode success. For example, it may store everything in the main memory to provide rapid response time. Then, when users want to transition to large-scale use, the initial point solution architecture will not scale up.
  
  
• High-risk downstream capabilities:-
  Frequently, the initial release will defer such considerations as security, fault-tolerance, and distributed processing to provide early functionality and user interface capabilities. The users may like the results, and expect the deferred considerations to be delivered equally rapidly. Usually, this puts the project in big trouble because the initial release's architecture cannot be easily extended to support the desired security, fault tolerance, distributed processing, or other key considerations.
  
  
• Off-target initial release:-
  Evolutionary developers often begin by saying, "Let us find out what the user needs by building an initial release and seeing what the users want improved." The lack of initial user activity analysis frequently leads to an initial release, which is so far from user needs that the users never bother learning and using it.