Page 1 : Continuation:, Software Development Life, Cycle

Page 2 : Incremental Development Model (IDM),  the software is developed in, increment.,  first the requirements are split, into a set of increments.,  The first increment is a simple, working system implementing, only a few basic features.,  Over successive iterations,, successive increments are, implemented and delivered to, the customer until the desired, system is realized.

Page 3 : Life cycle activities of incremental development, model:, , , , the requirements of the software are first broken down into several modules or, features that can be incrementally constructed and delivered (see IDM, diagram)., , , , plan is made only for the next increment and no long-term plans are made., , , , The development team first undertakes to develop the core features of the, system., , , , Once the initial core features are developed, these are refined into, increasing levels of capability by adding new functionalities in successive, versions., , , , Each incremental version is usually developed using an iterative waterfall, model of development (see diagram)., , , , As each successive version of the software is constructed and delivered to, the customer, the customer feedback is obtained on the delivered version, and these feedbacks are incorporated in the next version., , , , Each delivered version of the software incorporates additional features over, the previous version and also refines the features that were already delivered, to the customer., , , , After the requirements gathering and specification, the requirements are split, into several increments. Starting with the core (increment 1), in each, successive iteration, the next increment is constructed using a waterfall model, of development and deployed at the customer site., , , , After the last (shown as increment n) has been developed and deployed at, the client site, the full software is developed and deployed (see diagram).

Page 4 : Advantages of Incremental Development Model (IDM),  Error reduction,  The core modules are used by the customer from the beginning and, therefore these get tested thoroughly. This reduces chances of errors in, the core modules of the final product, leading to greater reliability of the, software., ,  Incremental resource deployment,  This model obviates (prevents) the need for the customer to commit, large resources at one go for development of the system. It also saves, the developing organization from deploying large resources and, manpower for a project in one go.

Page 5 : Evolutionary Model, , , This model has many of the features of the incremental model. As in, case of the incremental model, the software is developed over a, number of increments. At each increment, a concept (feature) is, implemented and is deployed at the client site., , , , The software is successively refined and feature-enriched until the full, software is realized., , , , The principal idea behind the evolutionary life cycle model is conveyed, by its name., , , , In the incremental development model, complete requirements are first, developed and the SRS document prepared., , , , In contrast, in the evolutionary model, the requirements, plan, estimates,, and solution evolve over the iterations, rather than fully defined and, frozen in a major up-front specification effort before the development, iterations begin., , , , Such evolution is consistent with the pattern of unpredictable feature, discovery and feature changes that take place in new product, development., , , , Can also be viewed as an extension of the waterfall model, but it, incorporates a major paradigm shift that has been widely adopted in, many recent life cycle models. Due to obvious reasons, the evolutionary, software development process is sometimes referred to as design a little,, build a little, test a little, deploy a little model., , , , This means that after the requirements have been specified, the design,, build, test, and deployment activities are iterated (see diagram).

Page 6 : Advantages of Evolutionary Model, , Effective elicitation of actual customer, requirements, Easy handling change requests

Page 7 : Disadvantages of Evolutional Model, , Feature division into incremental parts can be, non-trivial, Ad hoc design

Page 8 : Evolutionary versus incremental model of, developments,  The evolutionary and incremental have several things in common, such as incremental, development and deployment at the client site., ,  However, in a purely incremental model, the requirement specification is completed before, any development activities start.,  Once the requirement specification is completed, the requirements are split into requirements.,  In a purely evolutionary development, the development of the first version starts off after, obtaining a rough understanding of what is required. As the development proceeds, more, and more requirements emerge., ,  The modern development models, such as the agile models are neither purely incremental,, nor purely evolutionary, but are somewhat in between and are referred to as incremental and, evolutionary model. In this model, the initial requirements are obtained and specified, but, requirements that emerge later are accommodated.

Page 9 : RAPID APPLICATION DEVELOPMENT (RAD), Model,  The rapid application development (RAD) model was proposed in the early, nineties in an attempt to overcome the rigidity of the waterfall model (and its, derivatives) that makes it difficult to accommodate any change requests from, the customer.,  It proposed a few radical extensions to the waterfall model. This model has the, features of both prototyping and evolutionary models.,  It deploys an evolutionary delivery model to obtain and incorporate the, customer feedbacks on incrementally delivered versions.,  In this model prototypes are constructed, and incrementally the features are, developed and delivered to the customer.,  But unlike the prototyping model, the prototypes are not thrown away but are, enhanced and used in the software construction.

Page 10 : The major goals of the RAD model are as, follows:, To decrease the time taken and the cost incurred, to develop software systems., To limit the costs of accommodating change, requests., , To reduce the communication gap between the, customer and the developers

Page 11 : Main motivation:,  In the iterative waterfall model:,  the customer requirements need to be gathered, analyzed, documented, and signed off upfront, before any, development could start. However, often clients do not know what they exactly wanted until they saw a working system.,  It has now become well accepted among the practitioners that only through the process commenting on an installed, application that the exact requirements can be brought out., ,  In the iterative waterfall model:,  the customers do not get to see the software, until the development is complete in all respects and the software has, been delivered and installed.,  Naturally, the delivered software often does not meet the customer expectations and many change request are, generated by the customer.,  The changes are incorporated through subsequent maintenance efforts. This made the cost of accommodating the, changes extremely high and it usually took a long time to have a good solution in place that could reasonably meet the, requirements of the customers., ,  In the Rapid Application Development model:,  The RAD model tries to overcome this problem by inviting and incorporating customer feedback on successively, developed and refined prototypes.

Page 12 : Working of RAD,  Development takes place in a series of short cycles or iterations.,  At any time, the development team focuses on the present iteration only, and therefore plans are, made for one increment at a time., ,  The time planned for each iteration is called a time box.,  Each iteration is planned to enhance the implemented functionality of the application by only a small, amount.,  During each time box, a quick-and-dirty prototype-style software for some functionality is developed.,  The customer evaluates the prototype and gives feedback on the specific improvements that may be, necessary.,  The prototype is refined based on the customer feedback., ,  The development team almost always includes a customer representative to clarify the requirements., This is intended to make the system tuned to the exact customer requirements and also to bridge the, communication gap between the customer and the development team.,  The development team usually consists of about five to six members, including a customer, representative.

Page 13 : How does RAD facilitate accommodation of change, requests?,  The customers usually suggest changes to a specific feature only, after they have used it., ,  Since the features are delivered in small increments, the customers, are able to give their,  change requests pertaining to a feature already delivered.,  Incorporation of such change requests just after the delivery of an, incremental feature saves cost as this is carried out before large, investments have been made in development and testing of a, large number of features.

Page 14 : How does RAD facilitate faster development?,  The decrease in development time and cost, and at the same time an increased flexibility, to incorporate changes are achieved in the RAD model in two main ways—minimal use of, planning and heavy reuse of any existing code through rapid prototyping., ,  The lack of long-term and detailed planning gives the flexibility to accommodate later, requirements changes. Reuse of existing code has been adopted as an important, mechanism of reducing the development cost.,  RAD model emphasizes code reuse as an important means for completing a project, faster. In fact, the adopters of the RAD model were the earliest to embrace objectoriented languages and practices.,  Further, RAD advocates use of specialized tools to facilitate fast creation of working, prototypes. These specialized tools usually support the following features:,  Visual style of development., ,  Use of reusable components.

Page 15 : Applicability of RAD Model, , Customized software, Non-critical software, Highly constrained project schedule, , Large software

Page 16 : Application characteristics that render RAD unsuitable, , Generic products (wide distribution), Requirement of optimal performance and/or reliability, Lack of similar products, , Monolithic entity

Page 17 : Comparison of RAD with Other, Models

Page 18 : RAD versus prototyping model,  In the prototyping model, the developed prototype is primarily used by the, development,  team to gain insights into the problem, choose between alternatives, and elicit, customer feedback.,  The code developed during prototype construction is usually thrown away. In, contrast, in RAD it is the developed prototype that evolves into the deliverable, software., ,  Though RAD is expected to lead to faster software development compared to, the traditional models (such as the prototyping model), the quality and reliability, would be inferior.

Page 19 : RAD versus iterative waterfall model,  In the iterative waterfall model, all the functionalities of a software are developed together.,  On the other hand, in the RAD model the product functionalities are developed incrementally, through heavy code and design reuse.,  Further, in the RAD model customer feedback is obtained on the developed prototype after, each iteration and based on this the prototype is refined. Thus, it becomes easy to, accommodate any request for requirements changes.,  However, the iterative waterfall model does not support any mechanism to accommodate any, requirement change requests.,  The iterative waterfall model does have some important advantages that include the following., Use of the iterative waterfall model leads to production of good quality documentation which, can help during software maintenance., ,  Also, the developed software usually has better quality and reliability than that developed using, RAD.

Page 20 : RAD versus evolutionary model,  Incremental development is the hallmark (trademark) of both, evolutionary and RAD models.,  However, in RAD each increment results in essentially a quick and, dirty prototype, whereas in the evolutionary model each increment, is systematically developed using the iterative waterfall model.,  Also in the RAD model, software is developed in much shorter, increments compared the evolutionary model. In other words, the, incremental functionalities that are developed are of fairly larger, granularity in the evolutionary model.

Page 21 : RAD Model, , , , , Requirements Planning Phase, , , This is the very first phase, it involves procuring requirements of the, software project under development., , , , For requirements elicitation, a wide array of techniques are used,, including brainstorming, FAST (Facilitated Application, Development Technique), form analysis, task analysis, and user, scenarios., , , , The requirements planning phase also includes the complete, structured plan. It describes: The critical data, The methods for, obtaining critical data, and The procedure of processing the, critical data to form the final model, , User Design Phase, , , , , Construction phase, , , , , The second phase, involves taking user feedback and then, building several prototypes of the project under development, using developer tools., , includes the refinement of the prototypes developed in the, previous phase. It also includes the use of powerful automated, tools for transforming processes and data models into the final,, operational product., , Cutover Phase, , , The last phase includes the finalization of the aesthetics, features,, functions, interface, and everything else related to the software, project. Interfaces between the various independent modules, require proper testing.

Page 22 : Other RAD Model Diagram: