2. Data modeling

The information flow defined as part of the business modeling phase is refined into a set of data objects that are needed to support the business. The characteristic (called attributes) of each object is identified and the relationships between these objects are defined.

3. Process modeling

 The data objects defined in the data-modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing the descriptions are created for adding, modifying, deleting, or retrieving a data object.

4. Application generation

The RAD model assumes the use of the RAD tools like VB, VC++, Delphi etc... rather than creating software using conventional third generation programming languages. The RAD model works to reuse existing program components (when possible) or create reusable components (when necessary). In all cases, automated tools are used to facilitate construction of the software.

5. Testing and turnover

Since the RAD process emphasizes reuse, many of the program components have already been tested. This minimizes the testing and development time

Describe the Waterfall method in software life cycle.

Waterfall is oldest best known methodology: a sequence of stages in which the output of each stage becomes the input for the next. These stages can be characterized and divided up in different ways, including the following:

Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals.

Systems analysis, requirements definition: Refines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.

Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.

Implementation: The real code is written here.

Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.

Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business.

Maintenance: What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever

Describe JAD model

Joint Application Development (JAD) is a process used in the Systems Development Life Cycle (SDLC) to collect business requirements while developing new information systems for a company. "The JAD process also includes approaches for enhancing user participation, expediting development, and improving the quality of specifications." It consists of a workshop where “knowledge workers and IT specialists meet, sometimes for several days, to define and review the business requirements for the system.[1]” The attendees include high level management officials who will ensure the product provides the needed reports and information at the end. This acts as “a management process which allows Corporate Information Services (IS) departments to work more effectively with users in a shorter time frame.”

Through JAD workshops the knowledge workers and IT specialists are able to resolve any difficulties or differences between the two parties regarding the new information system. The workshop follows a detailed agenda in order to guarantee that all uncertainties between parties are covered and to help prevent any miscommunications.

Miscommunications can carry far more serious repercussions if not addressed until later on in the process. (See below for Key Participants and Key Steps to an Effective JAD). In the end, this process will result in a new information system that is feasible and appealing to both the designers and end users

Describe the iterative Model

An iterative lifecycle model does not attempt to start with a full specification of requirements. Instead, development begins by specifying and implementing just part of the software, which can then be reviewed in order to identify further requirements. This process is then repeated, producing a new version of the software for each cycle of the model.

Consider an iterative lifecycle model which consists of repeating the following four phases in sequence:

- A Requirements phase, in which the requirements for the software are gathered and analyzed. Iteration should eventually result in a requirements phase that produces a complete and final specification of requirements.

- A Design phase, in which a software solution to meet the requirements is designed. This may be a new design, or an extension of an earlier design.

- An Implementation and Test phase, when the software is coded, integrated and tested.

- A Review phase, in which the software is evaluated, the current requirements are reviewed, and changes and additions to requirements proposed.

For each cycle of the model, a decision has to be made as to whether the software produced by the cycle will be discarded, or kept as a starting point for the next cycle (sometimes referred to as incremental prototyping). Eventually a point will be reached where the requirements are complete and the software can be delivered, or it becomes impossible to enhance the software as required, and a fresh start has to be made.

The iterative lifecycle model can be likened to producing software by successive approximation. Drawing an analogy with mathematical methods that use successive approximation to arrive at a final solution, the benefit of such methods depends on how rapidly they converge on a solution.

The key to successful use of an iterative software development lifecycle is rigorous validation of requirements, and verification (including testing) of each version of the software against those requirements within each cycle of the model. The first three phases of the example iterative model is in fact an abbreviated form of a sequential V or waterfall lifecycle model. Each cycle of the model produces software that requires testing at the unit level, for software integration, for system integration and for acceptance. As the software evolves through successive cycles, tests have to be repeated and extended to verify each version of the software

Describe V model

A variant of the waterfall model — the V-model — associates each development activity with a test or validation at the same level of abstraction. Each development activity builds a more detailed model of the system than the one before it, and each validation tests a higher abstraction than its predecessor

The V-model deploys a well-structured method in which each phase can be implemented by the detailed documentation of the previous phase

V- stands for Verification and Validation

 

Describe Prototyping Model

This is a cyclic version of the linear model. In this model, once the requirement analysis is done and the design for a prototype is made, the development process gets started. Once the prototype is created, it is given to the customer for evaluation. The customer tests the package and gives his/her feed back to the developer who refines the product according to the customer's exact expectation. After a finite number of iterations, the final software package is given to the customer. In this methodology, the software is evolved as a result of periodic shuttling of information between the customer and developer. This is the most popular development model in the contemporary IT industry. Most of the successful software products have been developed using this model - as it is very difficult (even for a whiz kid!) to comprehend all the requirements of a customer in one shot. There are many variations of this model skewed with respect to the project management styles of the companies. New versions of a software product evolve as a result of prototyping.

Describe Fountain Flow Model

The Fountain Model is highly iterative approach that is well suited for Object Oriented software development. These are the key points in Foutain Flow Model Support Incremental Development Recognizes that some activities can’t stand before others, yet there’s a considerable overlap of activities throughout the development cycle Parallelism among various phases and iteration within phases

Describe Spiral Model

Developed by Barry Boehm in 1988. it provides the potential for rapid development of incremental versions of the software. In the spiral model, software is developed in a series of incremental releases. During early iterations , the incremental release might be a paper model or prototype.

Each iteration consists of Planning, Risk Analysis, Engineering, Construction & Release & Customer Evaluation

The spiral Model is a SDLC methodology that combines the features of prototyping with waterfall methodology.

Steps in Spiral Model

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

1. 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.

2.A preliminary design is created for the new system.

3.A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.

4. 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.

5.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.

6.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.

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

8.The final system is constructed, based on the refined prototype. 9.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

Describe Build and Fix Model

Build and Fix is the least structured of the SDLC methodologies.It relies heavily on the expertise of the individual team members.With this model, developers write some code , then continue to modify it until it seems to work and the customer is satisfied. With poor planning , this is risky

Descibe Synchronize-and- Stabilize Model

Synchronize-and-stabilize (sometimes just called sync-and-stabilize) is a systems development life cycle model in which teams work in parallel on individual application modules, frequently synchronizing their code with that of other teams, and debugging (stabilizing) code regularly throughout the development process. The sync-and-stabilize model offers advantages over the older waterfall model, which is strictly sequential in nature. Because sync-and-stabilize development allows for changes at any point in the process, it can be flexible, and more easily able to respond to market requirement changes.

The sync-and-stabilize approach was created by David Yoffie of Harvard University and Michael Cusumano of MIT. Cusumano and Yoffie studied commonalities between processes Microsoft used in developing Internet Explorer and those Netscape Communications Corp. used in developing Netscape Communicator. The researchers found that, among other similarities, both companies compiled all the project code nightly. They both also brought together all the components and tried to stabilize code before it was released. Cusumano and Yoffie integrated the successful common strategies of the two projects into the sync-and-stabilize model

SDLC models Advantages & disadvantages

Advantages of Waterfall Model

1. Clear project objectives. 2. Stable project requirements. 3. Progress of system is measurable. 4. Strict sign-off requirements.

Disadvantages of Waterfall Model

1. Time consuming 2. Never backward (Traditional) 3. Little room for iteration 4. Difficulty responding to changes

Advantages of Spiral Model

1. Avoidance of Risk is enhanced. 2. Strong approval and documentation control. 3. Implementation has priority over functionality. 4. Additional Functionality can be added at a later date.

Disadvantages of Spiral Model

1. Highly customized limiting re-usability 2. Applied differently for each application 3. Risk of not meeting budget or schedule 4. Possibility to end up implemented as the Waterfall framework

Advantages of Prototype model

1. Strong Dialogue between users and developers 2. Missing functionality can be identified easily 3. Confusing or difficult functions can be identified 4. Requirements validation, Quick implementation of, incomplete, but functional, application 5. May generate specifications for a production application 6. Environment to resolve unclear objectives 7. Encourages innovation and flexible designs

Disadvantages of Prototype model

1. Contract may be awarded without rigorous evaluation of Prototype 2. Identifying non-functional elements difficult to document 3. Incomplete application may cause application not to be used as the full system was designed 4. Incomplete or inadequate problem analysis 5. Client may be unknowledgeable 6. Approval process and requirement is not strict 7. Requirements may frequently change significantly