Rapid Application Development (RAD) - Characteristics and Phases

Rapid Application Development is a software development methodology that focuses to decrease the time that is needed to design the software 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.

Characteristics of Rapid Application Development(RAD)

- It involves techniques like iterative development and software prototyping.
- Focused scope where the business objectives are well defined and narrow is well suited for RAD.
- Project data suitable for RAD is the data for the project already exists (completely or in part). The project largely comprises analysis or reporting of the data.
- Decisions can be made by a small number of people who are available and preferably co-located are suitable for RAD.
- A small project team (preferably six people or less) is suitable for RAD.
- In RAD, the technical architecture is defined and clear and the key technology components are in place and tested.

Phases of Rapid Application Development

RAD has a step by step process.
- Planning of Requirements: Developers meet with the project coordinator or manager to create specific objectives from the desired program. Strategies for development and tools for development are also laid out in a specific project.
- RAD Design Workshop: Using the agreed tools and interfaces, developers will start to create different programs based on the business need.
- Implementation Phase: Even though it has gone through hundreds or even thousands of testing and critique, the stage wherein the software is implemented in a larger scale is different hence new suggestions and bugs should be expected from different users.

Software Development Methodology - Joint Application Development (JAD)

- Joint Application Development(JAD)is a process that is originally used to develop computer based systems.
- Joint Application Development is a process that accelerates the design of information technology solutions.
- JAD uses customer involvement and group dynamics to accurately depict the user's view of the business need and to jointly develop a solution.
- JAD is thought to lead to shorter development times and greater client satisfaction because the client is involved throughout the development process.
- JAD centers around a workshop session that is structured and focused. Participants of these sessions would typically include a facilitator, end users, developers, observers, mediators and experts.
- In order to get agreement on the goals and scope of the project, a series of structured interviews are held.
- The sessions are very focused, conducted in a dedicated environment, quickly drive major requirements.

Concept of Joint Application Development

- User who do the job have the best understanding of that job.
- The developers have the best understanding of the technology.
- The software development process and business process work in the same way.
- When all groups work equal and as one team with a single goal, the best software comes out.

Principles of JAD Process

- Define session objectives.
- Prepare for the session.
- Conduct the JAD session.
- Procedure the documents.
JAD improves the final quality of the product by keeping the focus on the upfront of the development cycle thus reducing the errors that are likely to cause huge expenses.

Advantages of Joint Application Development

- JAD decreases time and costs associated with requirements elicitation process.
- The experts get a chance to share their views, understand views of others, and develop the sense of project ownership.
- The techniques of JAD implementation are well known as it is the first accelerated design technique.
- Easy integration of CASE tools into JAD workshops improves session productivity and provides systems analysts with discussed and ready to use models.
- Enhances quality.
- Creates a design from the customer's perspective.

Quick Glance : Sociability(Sensitivity) Tests, Tuning Cycle Tests, Protocol Tests, Thick Client Application Tests, Thin Client Application tests

SOCIABILITY(sensitivity) TESTS

Sensitivity analysis testing can determine impact of activities in one system on another related system. Such testing involves a mathematical approach to determine the impact that one system will have on another system. For example, web enabling a customer 'order status' facility may impact on performance of telemarketing screens that interrogate the same tables in the same database. The issue of web enabling ca be that it is more successful than anticipated and can result in many more inquiries than originally envisioned, which loads the IT system with one work than had been planned.

TUNING CYCLE TESTS

A series of test cycles can be executed with a primary purpose of identifying tuning opportunities. Tests can be refined and re-targeted on the fly to allow technology support staff to make configuration changes so that the impact of those changes can be immediately measured.

PROTOCOL TESTS

Protocol tests involve the mechanisms used in an application, rather than the applications themselves.For example, a protocol test of a web server will involve a number of HTTP interactions that would typically occur if a web browser were to interact with a web server - but the test would not be done using a web browser. LoadRunner is usually used to drive load into a system using VUGen at a protocol level so that a small number of computers can be used to simulate thousand of users.

THICK CLIENT APPLICATION TESTS

Thick clients, also called heavy clients, are full-featured computers that are connected to a network. While a thick client is fully functional without a network connection, it is only a "client" when it is connected to a server. The server may provide the thick client with programs and files that are not stored on the local machine's hard drive.
A thick client is a purpose built piece of software that has been developed to work as a client with a server. It often has substantial business logic embedded within it, beyond the simple validation that is able to be achieved through a web browser. A thick client is often able to be very efficient with the amount of data that is transferred between it and its server, but is also often sensitive to any poor communication links. Testing tools such as WinRunner are able to be used to drive a thick client, so that response time can be measured under a variety of circumstances within a testing regime.
Developing a load test based on thick client activity usually requires significantly more effort for the coding stage of testing, as VUGen must be used to simulate the protocol between the client and the server. That protocol may be database connection based, COM/DCOM based, a proprietary communications protocol or even a combination of protocols.

THIN CLIENT APPLICATION TESTS

An internet browser that is used to run an application is said to be a thin client. But even thin clients can consume substantial amounts of CPU time on the computer that they are running on. This is particularly the case with complex web pages that utilize many recently introduced features to liven up a web page. Rendering a page from after hitting a SUBMIT button may take several seconds even though the server may have responded to the request in less than one second. Testing tools such as WinRunner are able to be used to drive a thin client, so that response time can be measured from a users perspective, rather than from a protocol level.

Volume tests - Volume Testing of Batch Processing Systems

Capacity drivers in batch processing systems are also critical as certain record types may require significant CPU processing, while other record types may invoke substantial database and disk activity. Some batch processes also contain substantial aggregation processing, and the mix of transactions can significantly impact the processing requirements of the aggregation phase.

In addition to the contents of any batch file, the total amount of processing effort may also depend on the size and makeup of the database that the batch process interacts with. Also, some details in the database may be used to validate batch records, so the test database must match test batch files.


Before conducting a meaningful test on a batch system, the following must be known :
- The capacity drivers for the batch records.
- The mix of batch records to be processed, grouped by capacity driver.
- Peak expected batch sizes (check end of month, quarter and year batch sizes).
- Similarity of production database and test database.
- Performance Requirements.


Batch runs can be analyzed and the capacity drivers can be identified, so that large batches can be generated for validation of processing within batch windows. Volume tests are also executed to ensure that the anticipated numbers of transactions are able to be processed and that they satisfy the stated performance requirements.

Volume tests - Volume Testing of Messaging systems

Volume tests are often most appropriate to messaging, batch and conversion processing type situations. In a volume test, there is often no such measure as response time. Instead, there is usually a concept of throughput. A key to effective volume testing is the identification of the relevant capacity drivers. A capacity driver is something that directly impacts on the total processing capacity. For a messaging system, a capacity driver may well be the size of messages being processed.

Most messaging systems do not interrogate the body of the messages they are processing, so varying the content of the test messages may not impact the total message throughput capacity, but significantly changing the size of the messages may have a significant effect. However, the message header may include indicators that have a very significant impact on processing efficiency. For example, a flag saying that the message need not be delivered under certain circumstances is much easier to deal with than a message with a flag saying that it must be held for delivery for as long as necessary to deliver the message, and the message must not be lost. In the former example, the message may be held in memory, but in the later example, the message must be physically written to disk multiple times.

Before conducting a meaningful test on a messaging system, the following must be known:

- the capacity drivers for the messages.
- the peak rate of messages that need to be processed, grouped by capacity driver.
- the duration of peak message activity that needs to be replicated.
- the required message processing rates.


A test can then be designed to measure the throughput of a messaging system as well as the internal messaging system metrics while that throughput rate is being processed. Such measures would typically include CPU utilization and disk activity. It is important that a test be run, at peak load, for a period of time equal to or greater than the expected production duration of peak load.

What is the need to execute Network Sensitivity Tests?

The three principle reasons for executing network sensitivity tests are as follows:
- Determine the impact on response time of WAN link.
- Determine the capacity of a system based on a given WAN link.
- Determine the impact on the system under test that is under dirty communications load.
Execution of performance and load tests for analysis of network sensitivity require test system configuration to emulate a WAN. Once a WAN link has been configured, performance and load tests conducted will become Network Sensitivity Tests.

There are two ways of configuring such tests:
- Use a simulated WAN and inject appropriate background traffic
This can be achieved by putting back to back routers between a load generator and the system under test. The routers can be configured to allow the required level of bandwidth, and instead of connecting to a real WAN, they connect directly through to each other.
When back to back routers are configured to be part of a test, they will basically limit the bandwidth. If the test is to be realistic, then additional traffic will need to be applied to the routers. This can be achieved by a web server at one end of the link serving pages and another load generator generating
requests. It is important that the mix of traffic is realistic.

For example, a few continuous file transfers may impact response time in a different way to a large number of small transmissions. By forcing extra more traffic over the simulated WAN link, the latency will increase and some packet loss may even occur. While this is much more realistic than testing over a high speed LAN, it does not take into account many features of a congested WAN such as out of sequence packets.

- Use the WAN emulation facility within LoadRunner
The WAN emulation facility within LoadRunner supports a variety of WAN scenarios. Each load generator can be assigned a number of WAN emulation parameters, such as error rates and latency. WAN parameters can be set individually, or WAN link types can be selected from a list of pre-set configurations.

It is important to ensure that measured response times incorporate the impact of WAN effects both at an individual session, as part of a performance test, and under load as part of a load test, because a system under WAN affected load may work much harder than a system doing the same actions over a clean communications link.

How to execute Performance Tests?

Performance testing involves executing the same test case multiple times with data variations for each execution, and then collating response times and computing response time statistics to compare against the formal expectations. Often, performance is different when the data used in the test case is different, as different number of rows are processed in the database, different processing and validation come into play, and so on. By executing a test case many times with different data, a statistical measure of response time can be computed that can be directly compared against a formal stated expectation.

Network sensitivity tests are variations on load tests and performance tests that focus on the Wide Area Network (WAN) limitations and network activity. Network sensitivity tests can be used to predict the impact of a given WAN segment or traffic profile on various applications that are bandwidth dependent. Network issues often arise at low levels of concurrency over low bandwidth WAN segments. Very chatty applications can appear to be more prone to response time degradation under certain conditions than other applications that actually use more bandwidth. For example, some applications may degrade to unacceptable levels of response time when a certain pattern of network traffic uses 50% of available bandwidth, while other applications are virtually un-changed in response time even with 85% of available bandwidth consumed elsewhere.

This is particularly important test for deployment of a time critical application over a WAN. Also, some front end systems such as web servers, need to work much harder with dirty communications compared with clean communications encountered on a high speed LAN in an isolated load and performance testing environment.