Aorta Life cycle, RAD, Incremental Build model,Evolutionary Development model.

                                                 Aorta Life Cycle Model

The aorta life cycle model is a software development method according to the waterfall model, but after each cycle is a feedback to the customer site.

 

History of the Aorta Life Cycle Model

In the eighties and nineties, many life cycle models were introduced. What these models have in common is that they have a shorter development cycle. By strict application of the ‘waterfall’ model, the customer only at the time of delivering what has become the final application. When using the other life cycle models are developed several cycles, where a customer gets feedback after each cycle. Any errors are thus more easily detected and the customer can directly indicate how he wants it. It is also important to make certain that each life cycle is completed without error. If an error is detected in a subsequent life cycle costs a lot of money to correct the error. Each previous cycle will be repeated for any new errors.

 

The Phases of the Aorta Life Cycle Model

The Aorta life cycle model includes nine steps to reach the final model to come. We start with the Orientation phase. In the orientation

Aorta Life Cycle ModelPhase is roughly mapped out the wishes of the user of the application are. Then comes the planning stage. During the planning phase, a project plan for the rest of the project. After these two phases beginning the concrete work, consisting of five key stages. In the model below, these phases appear along with their main product. The first letters of these phases form the word “Aorta”. This is the beating heart of a project. Finally, even the last two stages. The evaluation phase project to look back at the experience in identifying and then comes the final phase, the maintenance phase. In this final phase of maintenance on the delivered application. This is often distinction in a warranty and a maintenance period.Pros and Cons of the Aorta Life Cycle ModelAdvantages of the aorta life cycle modelIf in the beginning of the project failures are detected, it takes less effort (and therefore time and money) for this error. In the waterfall model phases to be properly sealed first before proceeding to the next stage. It assumes that the phases are correct before proceeding to the next phase.

In the waterfall model lay the emphasis on documentation. In the newer software development methodologies makes it less documentation. This means that when new people in the project, and people leave it is difficult to transfer knowledge. This disadvantage is not the waterfall method.

It is a clear and simple method. It is very obvious when certain steps are finished.

One can use this method of milestones.

The waterfall model is well known. Many people have experienced, so there might be easy to work.

Disadvantages of the Aorta Life Cycle Model

There are some disadvantages of this way to develop software.

Many software projects are dependent on external factors. The client is a very important external factor. Often the requirements during the course of the project change, because the client wants something different. It is a disadvantage that the waterfall method assumes that the requirements will not change during the project. Where the construction phase a requirement changed, a whole number of phases made again.

It is very difficult to time and cost estimate. The phases are very large, it is therefore very difficult to estimate how much each step cost.

In a number of new methods are almost all aspects of a software development project included. You can think of planning techniques, project management methods and how the project should be organized.

For many software projects, different people at different stages of the project. For example: the designers and builders. They all have a different view of the project as designers look at the project differently than the builders. Conversely, the builders often different from the design of the designers look than the designers themselves. Frequently, the design will be adjusted again. Here is the waterfall method is not made for that.

Within the project the team members often specialized. One team member will be only the first phase involved the design, while the only builders in construction helping to build the project. This can lead to waste of different sources. The main source is the time. An example: the designers are working on perfecting the design. The builders are in principle already start building, but because they work with the waterfall model, they should wait until the first phase is complete. This typical example of a waste of time.

When frequent portions of the software product to be delivered this gives the customer confidence but also the software development team.

Testing is done only in one of the last phases of the project. In many other software development methods will be tested once a specific sub-application is complete and is at last an integration test.

This is what you should know about the aorta life cycle model.

                                    RAD (Rapid Application Development)PurposeRapid application development (RAD) is a system development methodology that employs joint application design (to obtain user input), prototyping, CASE technology, application generators, and similar tools to expedite the design process.Inputs and related ideasRapid application development is an alternative to the traditional system development life cycle The RAD methodology incorporates joint application design and prototyping. CASE technologyis often used to speed the development process.

Concepts

Rapid application development (RAD) is a system development methodology that employs joint application design (to obtain user input), prototyping, CASE technology, application generators, and similar tools to expedite the design process. Initially suggested by James Martin, this methodology gained support during the 1980s because of the wide availability of such powerful computer software as fourth-generation languages, application generators, and CASE tools, and the need to develop information systems more quickly. The primary objectives include high quality, fast development, and low cost.

Components

Rapid application development focuses on four major components: tools, people, methodology, and management. Current, powerful computing technology is essential to support such tools as application generators, screen/form generators, report generators, fourth-generation languages, relational or object-oriented database tools, and CASE tools. People include users and the development team. The methodology stresses prototyping and joint application design.

A strong management commitment is essential. Before implementing rapid application development, the organization should establish appropriate project management and formal user sign-off procedures. Additionally, standards should be established for the organization’s data resources, applications, systems, and hardware platforms

Phases

Martin suggests four phases to implement rapid application development: requirements planning, user design, construction, and cutover.

A requirement planning is much like traditional problem definition and systems analysis. RAD relies heavily on joint application design (JAD) sessions to determine the new system requirements.

During the user design phase, the JAD team examines the requirements and transforms them into logical descriptions. CASE tools are used extensively during this phase. The system design can be planned as a series of iterative steps or allowed to evolve.

During the construction phase, a prototype is built using the software tools described earlier. The JAD team then exercises the prototype and provides feedback that is used to refine the prototype. The feedback and modification cycle continues until a final, acceptable version of the system emerges. In some cases, the initial prototype consists of screens, forms, reports, and other elements of the user interface, and the underlying logic is added to the prototype only after the user interface is stabilized.

The cutover phase is similar to the traditional implementation phase. Key activities include training the users, converting or installing the system, and completing the necessary documentation.

 

 

 

Variations

There are several variations and/or extensions to the rapid application development methodology.

Courbon et al. defines an evolutionary approach in which “progressive designs” go through “multiple, minimum-length cycles” in which “successive versions of the system under construction are utilized by the end user.” Courbon’s evolutionary approach⁵ is also called middle out, bread boarding, and the iterative design approach.

The essence of the evolutionary approach is to have the user (or the manager) and the builder agrees on a small but significant sub problem, and then to design and develop an initial system to support that immediate need. After a short period of use (a few weeks for instance), the system is evaluated, modified, and incrementally expanded. This cycle is repeated three to six times over the course of a few months until a relatively stable system that supports a cluster of related tasks evolves. The word relatively is important because, although the frequency and extent of system change will decrease or even cease, the system will never be truly stable. In effect, constant change is a conscious strategy.

Note that the evolutionary approach requires an unusual level of user (or management) participation. The user is actually the designer, and the system analyst merely implements required changes or modifications. Note also that this approach differs from traditional prototyping because the initial system is real, live, and usable, not just a pilot test.

Sprague and Carlson’s quick-hit approach is designed to take advantage of recognized high payoff application tasks for which a system can be built very quickly. The basic idea is to gain user cooperation and confidence by rapidly developing a highly usable system. For example, imagine that a company is losing market share to a rival. Imagine further that a preliminary study suggests that the primary factors contributing to the problem are product quality, after-sale service, and brand recognition. Perhaps a simulation model that focuses on those factors can be designed and constructed quickly, yielding information that can help management correct the problem. Note that the system is designed quickly to hit the main points; hence the name quick hit approach. According to Sprague, the quick-hit approach is low risk and has a high potential short run payoff.

Key terms

Application generator (generator, program generator) —

A program that starts with information in graphical, narrative, list, or some other logical form and generates the appropriate source or executable code.

CASE (computer-aided software engineering) —

A set of automated tools that assist in the entire software engineering process.

Construction phase —

The rapid application development phase during which a prototype is built, exercised, and modified based on user feedback.

Cutover phase —

The rapid application development phase during which the system is finalized and released to the user.

Evolutionary approach —

An approach to rapid application development in which progressive designs go through multiple, minimum-length cycles in which successive versions of the system under construction are utilized by the end user.

Fourth-generation language —

A non-procedural language that generates the appropriate source or executable code from a programmer’s definition or description of a logical operation.

Joint application design (JAD) —

A technique for quickly determining system requirements in an intensive session attended by a team consisting of major users, managers, and systems analysts.

Prototype —

A preliminary, working, physical model of a system, a subsystem, or a program.

Prototyping —

The act of creating a prototype.

Quick-hit approach —

An approach to rapid application development that takes advantage of recognized high payoff applications for which a system can be built very quickly.

Rapid application development (RAD) —

A system development methodology that employs joint application design, prototyping, CASE technology, application generators, and similar tools to expedite the design process.

Requirements planning —

The rapid application development phase during which the system requirements are defined using joint application design and other tools and techniques; this phase is similar to traditional problem definition and systems analysis.

User design phase —

The rapid application development phase during which the joint application design team examines the requirements and transforms them into logical descriptions.

Software

Many CASE products support prototyping. Screen painters, menu builders, report generators, fourth-generation languages, executable specification languages, spreadsheets, and database management programs are popular prototyping tools. There is no software specifically designed to support a JAD session. However, certain groupware, such as Lotus Notes, supports limited computer mediated conferencing.

Advantage

• Time to deliver is less.
• Changing requirements can be accommodated.
• Progress can be measured.
• Cycle time can be short with use of powerful RAD tools.
• Productivity with fewer people in short time.
• Use of tools and frameworks.

 Disadvantages

• Management complexity is more.
• Resource requirements may be more.
• Suitable for systems that are component based and scalable.
• Suitable only when requirements are well known.
• Requires user involvement throughout the life cycle.
• Suitable for project requiring shorter development times.

                         

                              Incremental build model

 

The incremental build model is a method of software development where the model is designed, implemented and tested incrementally (a little more is added each time) until the product is finished. It involves both development and maintenance. The product is defined as finished when it satisfies all of its requirements. This model combines the elements of the waterfall model with the iterative philosophy of prototyping.

The product is decomposed into a number of components, each of which are designed and built separately (termed as builds). Each component is delivered to the client when it is complete. This allows partial utilization of product and avoids a long development time. It also creates a large initial capital outlay with the subsequent long wait avoided. This model of development also helps ease the traumatic effect of introducing completely new system all at once. There are, overall, few problems with this model.

 

                             The Incremental Model

The incremental Model is an evolution of the waterfall model, where the waterfall model is incrementally applied.

The series of releases is referred to as “increments”, with each increment providing more functionality to the customers. After the first increment, a core product is delivered, which can already be used by the customer. Based on customer feedback, a plan is developed for the next increments, and modifications are made accordingly. This process continues, with increments being delivered until the complete product is delivered. The incremental philosophy is also used in the agile process model

 

 

 

Advantages

• Some working functionality can be developed quickly and early in the life cycle.
• Results are obtained early and periodically.
• Parallel development can be planned.
• Progress can be measured.
• Less costly to change the scope/requirements.
• Testing and debugging during smaller iteration is easy.
• Risks are identified and resolved during iteration; and each iteration is an easily managed milestone.
• Easier to manage risk – High risk part is done first.
• With every increment operational product is delivered.
• Issues, challenges & risks identified from each increment can be utilized/applied to the next increment.

Disadvantages

• More resources may be required.
• Although cost of change is lesser but it is not very suitable for changing requirements.
• More management attention is required.
• Each phase of iteration is rigid with no overlaps.
• System architecture or design issues may arise because not all requirements are gathered. up front for the entire life cycle.
• Does not allow iterations within an increment.
• Defining increments may require definition of the complete system.

     

Evolutionary Development Model – A software development life cycle model

 

The waterfall model is viable for software products that do not change very much once they are specified. But for software products that have their feature sets redefined during development because of user feedback and other factors, the traditional waterfall model is no longer appropriate.

 

– The Evolutionary EVO development model divides the development cycle into smaller, incremental waterfall models in which users are able to get access to the product at the end of each cycle.

 

– Feedback is provided by the users on the product for the planning stage of the next cycle and the development team responds, often by changing the product, plans, or process.

 

– These incremental cycles are typically two to four weeks in duration and continue until the product is shipped.

 

Benefits of Evolutionary Development Model

– Benefit not only business results but marketing and internal operations as well.

 

– Use of EVO brings significant reduction in risk for software projects.

 

– EVO can reduce costs by providing a structured, disciplined avenue for experimentation.

 

– EVO allows the marketing department access to early deliveries, facilitating development of documentation and demonstrations.

 

– Short, frequent EVO cycles have some distinct advantages for internal processes and people considerations.

 

– The cooperation and flexibility required by EVO of each developer results in greater teamwork.

 

– Better fit the product to user needs and market requirements.

 

– Manage project risk with definition of early cycle content.

 

– Uncover key issues early and focus attention appropriately.

 

– Increase the opportunity to hit market windows.

 

– Accelerate sales cycles with early customer exposure.

 

– Increase management visibility of project progress.

 

– Increase product team productivity and motivation.

 

 

 

 

Advantages

• Risk analysis is better.
• It supports changing requirements.
• Initial Operating time is less.
• Better suited for large and mission-critical projects.
• During life cycle software is produced early which facilitates customer evaluation and feedback.

Disadvantages

• Not suitable for smaller projects.
• Management complexity is more.
• End of project may not be known which a risk is.
• Can be costly to use.
• Highly skilled resources are required for risk analysis.
• Project’s progress is highly dependent upon the risk analysis phase.