Tester 'll Never " Satisfied "

Introduction

There are various software development approaches defined and designed which are

used/employed during development process of software, these approaches are also referred as

"Software Development Process Models". Each process model follows a particular life cycle

in order to ensure success in process of software development.

Waterfall Model

Waterfall approach was first Process Model to be introduced and followed widely in Software

Engineering to ensure success of the project. In "The Waterfall" approach, the whole

process of software development is divided into separate process phases. The phases in

Waterfall model are: Requirement Specifications phase, Software Design, Implementation and

Testing & Maintenance. All these phases are cascaded to each other so that second phase is

started as and when defined set of goals are achieved for first phase and it is signed off,

so the name "Waterfall Model". All the methods and processes undertaken in Waterfall Model

are more visible.

n 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:

An iterative model

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.

V-Model

The V-model is a software development model which can be presumed to be the extension of

the waterfall model. Instead of moving down in a linear way, the process steps are bent

upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the

relationships between each phase of the development life cycle and its associated phase of

testing.

v-model

Verification Phases

1. Requirements analysis:In this phase, the requirements of the proposed system are

collected by analyzing the needs of the user(s). This phase is concerned about establishing

what the ideal system has to perform. However, it does not determine how the software will

be designed or built. Usually, the users are interviewed and a document called the user

requirements document is generated. The user requirements document will typically describe

the system’s functional, physical, interface, performance, data, security requirements etc

as expected by the user. It is one which the business analysts use to communicate their

understanding of the system back to the users. The users carefully review this document as

this document would serve as the guideline for the system designers in the system design

phase. The user acceptance tests are designed in this phase.

2. System Design:System engineers analyze and understand the business of the proposed

system by studying the user requirements document. They figure out possibilities and

techniques by which the user requirements can be implemented. If any of the requirements

are not feasible, the user is informed of the issue. A resolution is found and the user

requirement document is edited accordingly.

The software specification document which serves as a blueprint for the development

phase is generated. This document contains the general system organization, menu

structures, data structures etc. It may also hold example business scenarios, sample

windows, reports for the better understanding. Other technical documentation like entity

diagrams, data dictionary will also be produced in this phase. The documents for system

testing is prepared in this phase.

3. Architecture Design:This phase can also be called as high-level design. The baseline

in selecting the architecture is that it should realize all which typically consists of the

list of modules, brief functionality of each module, their interface relationships,

dependencies, database tables, architecture diagrams, technology details etc. The

integration testing design is carried out in this phase.

4. Module Design:This phase can also be called as low-level design. The designed system

is broken up in to smaller units or modules and each of them is explained so that the

programmer can start coding directly. The low level design document or program

specifications will contain a detailed functional logic of the module, in pseudocode -

database tables, with all elements, including their type and size - all interface details

with complete API references- all dependency issues- error message listings- complete input

and outputs for a module. The unit test design is developed in this stage.

Spiral Model

History

The spiral model was defined by Barry Boehm in his 1988 article A Spiral Model of Software

Development and Enhancement. This model was not the first model to discuss iterative

development, but it was the first model to explain why the iteration matters. As originally

envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with

a design goal and ends with the client (who may be internal) reviewing the progress thus

far. Analysis and engineering efforts are applied at each phase of the project, with an eye

toward the end goal of the project.


The Spiral Model

The spiral model, also known as the spiral lifecycle model, is a systems development method

(SDM) used in information technology (IT). This model of development combines the features

of the prototyping model and the waterfall model. The spiral model is intended for large,

expensive, and complicated projects.

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.



Applications

For a typical shrink-wrap application, the spiral model might mean that you have a

rough-cut of user elements (without the polished / pretty graphics) as an operable

application, add features in phases, and, at some point, add the final graphics. The Big

Bang Model

Let's review the observational evidence:

* Distance/velocity relationship: distant galaxies are moving away from us, with speeds

which increase linearly with distance
* Chemistry: the universe is almost entirely hydrogen and helium, in a mixture of

roughly 12 H atoms to 1 He atom
* Cosmic Microwave Background: no matter where we look in the universe, we see radio

waves which look like those radiated by a blackbody at about 2.7 degrees above absolute

zero. There are tiny (one part in 10,000) variations in the brightness of this radiation on

scales of a degree or so

Is there any way to tie all these pieces of data together? Yes! One model which can explain

them all is called the Big Bang model. The name was coined by a scientist who didn't like

the theory and tried to make it sound silly.

RAID Model

Introduction

RAD is a linear sequential software development process model that emphasis an extremely

short development cycle using a component based construction approach. If the requirements

are well understood and defines, and the project scope is constraint, the RAD process

enables a development team to create a fully functional system with in very short time

period.

What is RAD?

RAD (rapid application development) is a concept that products can be developed faster and

of higher quality through:

* Gathering requirements using workshops or focus groups
* Prototyping and early, reiterative user testing of designs
* The re-use of software components
* A rigidly paced schedule that defers design improvements to the next product version
* Less formality in reviews and other team communication

Some companies offer products that provide some or all of the tools for RAD software

development. (The concept can be applied to hardware development as well.) These products

include requirements gathering tools, prototyping tools, computer-aided software

engineering tools, language development environments such as those for the Java platform,

groupware for communication among development members, and testing tools. RAD usually

embraces object-oriented programming methodology, which inherently fosters software re-use.

The most popular object-oriented programming languages, C++ and Java, are offered in visual

programming packages often described as providing rapid application development.

Development Methodology

The traditional software development cycle follows a rigid sequence of steps with a formal

sign-off at the completion of each. A complete, detailed requirements analysis is done

that attempts to capture the system requirements in a Requirements Specification. Users are

forced to "sign-off" on the specification before development proceeds to the next step.

This is followed by a complete system design and then development and testing.

But, what if the design phase uncovers requirements that are technically unfeasible, or

extremely expensive to implement? What if errors in the design are encountered during the

build phase? The elapsed time between the initial analysis and testing is usually a period

of several months. What if business requirements or priorities change or the users realize

they overlooked critical needs during the analysis phase? These are many of the reasons why

software development projects either fail or don’t meet the user’s expectations when

delivered.

RAD is a methodology for compressing the analysis, design, build, and test phases into a

series of short, iterative development cycles. This has a number of distinct advantages

over the traditional sequential development model.

RAD Model Phases

RAD model has the following phases:

1. Business Modeling: The information flow among business functions is defined by

answering questions like what information drives the business process, what information is

generated, who generates it, where does the information go, who process it and so on.
2. Data Modeling: The information collected from business modeling is refined into a set

of data objects (entities) that are needed to support the business. The attributes

(character of each entity) are identified and the relation between these data objects

(entities) is defined.
3. Process Modeling: The data object defined in the data modeling phase are transformed

to achieve the information flow necessary to implement a business function. Processing

descriptions are created for adding, modifying, deleting or retrieving a data object.
4. Application Generation: Automated tools are used to facilitate construction of the

software; even they use the 4th GL techniques.
5. Testing and Turn over: Many of the programming components have already been tested

since RAD emphasis reuse. This reduces overall testing time. But new components must be

tested and all interfaces must be fully exercised.

Advantages and Disadvantages

RAD reduces the development time and reusability of components help to speed up

development. All functions are modularized so it is easy to work with.

For large projects RAD require highly skilled engineers in the team. Both end customer and

developer should be committed to complete the system in a much abbreviated time frame. If

commitment is lacking RAD will fail. RAD is based on Object Oriented approach and if it is

difficult to modularize the project the RAD may not work well.

Prototype Model

Introduction

A prototype is a working model that is functionally equivalent to a component of the product.

In many instances the client only has a general view of what is expected from the software product. In such a scenario where there is an absence of detailed information regarding the input to the system, the processing needs and the output requirements, the prototyping model may be employed. This model reflects an attempt to increase the flexibility of the development process by allowing the client to interact and experiment with a working representation of the product. The developmental process only continues once the client is satisfied with the functioning of the prototype. At that stage the developer determines the specifications of the client’s real needs.

Types of Prototyping

Software prototyping has many variants. However, all the methods are in some way based on two major types of prototyping: Throwaway Prototyping and Evolutionary Prototyping.
Throwaway prototyping

Throwaway or Rapid Prototyping refers to the creation of a model that will eventually be discarded rather than becoming part of the finally delivered software. After preliminary requirements gathering is accomplished, a simple working model of the system is constructed to visually show the users what their requirements may look like when they are implemented into a finished system.

Rapid Prototyping involved creating a working model of various parts of the system at a very early stage, after a relatively short investigation. The method used in building it is usually quite informal, the most important factor being the speed with which the model is provided. The model then becomes the starting point from which users can re-examine their expectations and clarify their requirements. When this has been achieved, the prototype model is 'thrown away', and the system is formally developed based on the identified requirements.

The most obvious reason for using Throwaway Prototyping is that it can be done quickly. If the users can get quick feedback on their requirements, they may be able to refine them early in the development of the software. Making changes early in the development lifecycle is extremely cost effective since there is nothing at that point to redo. If a project is changed after a considerable work has been done then small changes could require large efforts to implement since software systems have many dependencies. Speed is crucial in implementing a throwaway prototype, since with a limited budget of time and money little can be expended on a prototype that will be discarded.

Another strength of Throwaway Prototyping is its ability to construct interfaces that the users can test. The user interface is what the user sees as the system, and by seeing it in front of them, it is much easier to grasp how the system will work.

…it is asserted that revolutionary rapid prototyping is a more effective manner in which to deal with user requirements-related issues, and therefore a greater enhancement to software productivity overall. Requirements can be identified, simulated, and tested far more quickly and cheaply when issues of evolvability, maintainability, and software structure are ignored. This, in turn, leads to the accurate specification of requirements, and the subsequent construction of a valid and usable system from the user's perspective via conventional software development models.

Prototypes can be classified according to the fidelity with which they resemble the actual product in terms of appearance, interaction and timing. One method of creating a low fidelity Throwaway Prototype is Paper Prototyping. The prototype is implemented using paper and pencil, and thus mimics the function of the actual product, but does not look at all like it. Another method to easily build high fidelity Throwaway Prototypes is to use a GUI Builder and create a click dummy, a prototype that looks like the goal system, but does not provide any functionality.

Not exactly the same as Throwaway Prototyping, but certainly in the same family, is the usage of storyboards, animatics or drawings. These are non-functional implementations but show how the system will look.

Advantages of Prototyping

There are many advantages to using prototyping in software development, some tangible some abstract.

Reduced time and costs: Prototyping can improve the quality of requirements and specifications provided to developers. Because changes cost exponentially more to implement as they are detected later in development, the early determination of what the user really wants can result in faster and less expensive software.

Improved and increased user involvement: Prototyping requires user involvement and allows them to see and interact with a prototype allowing them to provide better and more complete feedback and specifications. The presence of the prototype being examined by the user prevents many misunderstandings and miscommunications that occur when each side believe the other understands what they said. Since users know the problem domain better than anyone on the development team does, increased interaction can result in final product that has greater tangible and intangible quality. The final product is more likely to satisfy the users desire for look, feel and performance.