Overview of Performance Testing Tools

In client/server applications, many users access the server application simultaneously. In such a case, the software has to be tested for its performance.
The server application continues to run on the server but only one or a few clients will be running the client application but on these client machines, many virtual users are simulated, effectively simulating an environment in which 100 users access the database.
Today many enterprise applications such as ERP software, web services, web sites, CRM software etc. need to be tested for performance testing. Performance testing is also called load testing or stress testing. These tools display the performance of the application using graphs and charts so that analysis will become easy. You can plot a graph which shows the response time as a function of the number of simultaneous users who access the database.
WAPT 6.0 is a load and stress testing tool that provides you with an easy-to-use, consistent and cost-effective way of testing web sites, web servers, and intranet applications with web interfaces. WAPT has a set of features to test web sites with dynamic content and secure HTTPS pages. It provides informative test results through descriptive graphs and reports.
The performance tools that are widely used in the software industry are Mercury Interactive's LoadRunner and Apache's JMeter.

Functional/ Regression Testing Tools

In functional testing, the functionality of the software is tested without taking into consideration the source code and implementation details. For example. consider the standard calculator software. To test the functionality, some calculations will be done and check out whether the results are correct. If the expected results are same as the displayed results, the calculator software is working fine. While you are testing the software, you need to give test cases in such a way that all the buttons of the GUI are checked.
When the software is still in development phase, the software is not likely to work perfectly, and for some test cases you may get wrong results. During the course of development, you should check the software many times using the test cases. Doing it manually will take a lot of time, the functionality/regression testing tools are of immense use in such conditions.
Using these tools, GUI operations can be recorded. While running the tool, invoke the application and give all the test cases as input. Automatically, the testing tool will record your inputs like keystrokes and mouse clicks and then the tool will create a script. The script can be run subsequently and hence you are saved botheration of manually giving these inputs again and again.
testing tools provide a beautiful mechanism through data driven testing. In data driven testing, the username and password are considered as variables, the values that these variables can take can be obtained from a database and the testing is carried out. Data driven testing is one of the most important features of these testing tools. As a test engineer, the job is to create the test script with the variable names and then you can run the test in unattended mode.
While testing in unattended mode, suppose for an application, the user has to first login, then update a database table and then logout. You created test cases for all the three functions. If the software fails at login stage itself, should you continue or stop testing. The testing tools provide you an option either to continue or stop testing. The application can be made to recover automatically to a specified state.
The following tools used are Mercury Interactive's WinRunner, Segue Software's SilkTest, IBM Rational SQA Robot.

How are testing tools categorized ? - Part II

Embedded Software Testing Tools :
It is a very challenging task to test embedded software as the timing requirements for these applications are very stringent. The code has to be optimized so that it occupies the minimum memory. IBM Rational Test Real Time is the widely used test tool in this category.
Network Protocol Testing Tools :
Testing networking and communication software has attained a lot of importance in recent years as computer networks are becoming widespread. There are number of tools available for testing networking and communication protocols. ANVL(Automated Network Validation Library) is to test routers and other networking products. Agilent Technologies, Rhode and Schwartz etc supply protocol analyzers which generate the necessary protocols based on international standards such as ITU-T standards.
Configuration Management/Bug Tracking Tools
Configuration Management is a very important process. When test engineers report bugs, the managers have to track these bugs and ensure that all the bugs are removed. Bugzilla is an open source defect tracking system. Samba's Jitterbug is a freeware defect tracking system. IBM Rational Software's Clear DDTS is a change request management software. GNU's GNATS is a freeware bug tracking and change management software.
Software Testing Management Tools
These tools help in managing process oriented software testing. Using these tools, the QA manager can create a formal test plan, allocate resources, schedule unattended testing, track the status etc. AutoTester's AutoAdviser, Compuware's QA Director are such tools.

How are testing tools categorized ?

There is a wide variety of testing tools available to carry out different types of testing. the testing tools can be divided into the following categories :
- Source code Testing Tools
The tools that fall in this category check the source code of the application. the testing is white box testing and so the implementation details are considered. A number of tools are available to check line coverage, branch coverage, and path coverage. Tools are also available to test whether the source code is compliant to the standard coding guidelines and to generate the metrics.
- Functional/Regression Testing Tools
These tools are used to test the application software and web applications such as web sites. Applications involve Graphical User Interface, the tools test the GUI objects and functionality automatically. These tools carry out black box testing.
- Performance Testing Tools :
These tools are used to carry out performance testing or stress testing. These tools are very useful to test how the application works when multiple users access the application simultaneously. These tools simulate multiple users on a single machine and hence you do not need to have many machines and many test engineers can do performance testing. E.g. AutoTester's AutoController, Mercury Interactive's Load Runner, Apache JMeter, belong to this category.
- Java Testing Tools :
A number of tools are available exclusively for testing Java applications. These tools test the applications written in Java programming language and for testing java classes. Jemmy is an open source library to create automated tests for Java GUI applications.

What are the advantages of automated testing over manual testing ?

Manual testing is time consuming, error prone and requires lot of infrastructure and manpower. All these limitations can be overcome if the testing process becomes automated. There are many advantages in using these automated testing tolls :
- To improve the quality and reliability of the software, the functionality of software can be repeatedly tested using automated testing tools.
- Testing can be done during nighttime and during holidays i.e. testing can be done unattended using automated testing tools.
- The labor involved can be reduced using automated testing tools when the software has to be tested in different hardware platforms, different operating systems, using different browsers etc.
- Performance testing can be done without the need for many computers and many test engineers. The test tools simulate multiple users on a single machine. As compared to manual testing, finding out transaction response times when multiple users access the same application will be very easy.
- By effectively using the automated testing tools, testing process can be planned and managed effectively.
- Automated testing tools give a systematic approach to the testing process.
- There is a drastic reduction in time, effort and money spent on testing.
- There is an improvement in quality and reliability of the software after using automated testing tools.
- Even if the teams are at different geographical locations, there is efficient management of the testing process.
- Test reports can be generated automatically.
- Testing can be done using tools that are available to test not only generic applications but also for DLLs, VB programs, Siebel, Power builder software etc.

Manual Testing and what are its drawbacks/limitations.

Software testing is carried out manually in many organizations. The test team generates various test cases and manually tests each and every feature after the product is reached its completion stage. If defect is found, It is rectified and again the software is tested using the test cases. There are few drawbacks or limitations of manual testing.
- Manual testing is error prone because test engineers become bored when testing has to be done repeatedly. To test a we site, each and every link has to be checked.
- Manual testing is very time consuming. The same set of operations need to be done repeatedly.
- Regression testing has to be done to ensure that changes in one portion of the software have no ill effects on other portions of the software.
- To do performance testing, many resources are required, both computer and people. On the other hand, automated tools facilitate running the software from a single client machine.
- Even to manage the testing process is complicated as the testing has to be planned, bugs have to be tracked and reliability analysis has to be performed.

Manual testing is time consuming, error prone and requires lot of infrastructure and manpower, these limitations can be overcome if the testing process is automated. The testing tools reduce manual testing to a large extent and the testing can be done done automatically.

Testing Approaches: Functional Testing versus Structural Testing and Mutation testing

In functional testing, functionality of the module is tested and structure is not considered. Test cases based on specifications and internals of modules are not considered. This type of testing is also known as black box testing. The objective here is to ensure that `correct results'' are obtained when `good inputs'' are applied to the various parts of the design, and when `bad inputs'' are applied the design operates in a predictable manner. Functional testing can therefore be considered as concentrating on checking that the data paths operate correctly.

Structural testing is used to test the implementation of the program. Structural testing, also known as white box or open box testing, is normally applied to sequential HDL code and concentrates on checking that all executable statements within each module. Structural testing involves :
- Statement coverage : This ensures that each and every statement is tested. Software tools called profilers are used to carry this statement coverage.
- Branch coverage : Each and every condition is taken, and inputs are given in such a way that each branch is executed at least once.
- Path Coverage : To test loops, this is required. For example the statement
for(i=o;i<=100;i++) is executed 101 times.

Mutation testing is required to ensure that the software does not fail. It is a good debugging mechanism. The program is modified slightly to obtain mutants of the program. Different mutants are tested with the same test cases. If the mutant fails, and the actual program works correctly, confidence is gained in the program and test cases are considered good. To produce mutants, mutation operators are defined.
- Constant replacement
- Variable replacement
- Arithmetic operator replacement
- Relational operator replacement
- Goto label replacement

Testing Approaches: Top-down Approach versus Bottom-up Approach

In a large software project, it is impractical to integrate all the modules of the project together and test the software as whole. It should be build and tested in stages. There are different testing approaches.
Test Approach is the Strategy which describes the test team's approch to test the software, both overall and also in each phase.It gives better idea for the team to plan and execute the testing phase with perfection.

Top-down Approach versus Bottom-up Approach

In top-down approach, testing is done from top of hierarchy. Dummy routines called studs that simulate a module are introduced.
Advantage:
• Easy to visualize functionality.
• Sense of completeness in the requirement.
• Easy to show the progress of development.
Disadvantage:
• UI driven approach hence high possibility of redundant business logics.
• Since an UI is readily available no developer would write a Unit test cases.
• No Concrete layer to rely on, as both presentation & Business Logic keep evolving.
• Lack of concrete test suits to ensure one layer is tied up.

In bottom-up approach, testing is done from bottom of the hierarchy. Dummy routines called drivers are introduced that invoke the module.
Advantage:
• Solid Business Logic, hence zero redundancy
• Good Unit test case can be written to validate changes.
• Developer has only option to use unit testing tools to test the Logic.
• Easy to manage changes and modification.
Disadvantage:
• Effort involved to write test cases.
• Progress of implementation cannot be show very effectively.

How are the defects classified?

All defects are not the same type. Some defects may result in system crash. Some defects may be very minor. So, the defects need to be classified based on its impact on the functionality of the software. There are various ways in which we can classify.

Severity Wise

Major: A defect, which will cause an observable product failure or departure from requirements.
Minor: A defect that will not cause a failure in execution of the product.
Fatal: A defect that will cause the system to crash or close abruptly or effect other applications.

While recording the defects in a defect log sheet, the severity of the defects also needs to be noted. IF a critical defect is present in the code, then the software is not ready for delivery. Only a few major defects are allowed. Similarly, a threshold needs to be kept on the number of minor defects. As the threshold depends on the application, the project manager/test team member has to use the judgement in fixing the thresholds on major and minor defects. After analyzing the test report, the project manager needs to decide whether the software is ready for delivery or not.

International Standard Organization ISO 9001:2000 Clause 8

Clause 8: Measurement, Analysis and Improvements

Clause 8.1: General
Metrics for product quality and process quality has to be defined by the management as they play a very important role in process improvement. The process effectiveness and improvement can be checked by the use of these metrics.

Clause 8.2: Monitoring and Measurement

Clause 8.2.1: Customer Satisfaction
The management has to define the metrics to measure the customer satisfaction as it is the most important objective for any organization.
Clause 8.2.2: Internal Audit
For the proper implementation of the quality management system across the organization, an internal audit has to be formed. Necessary training has to be provided to the internal audit team on the auditing process.
Clause 8.2.3: Monitoring and measurement of processes
Using metrics, each process that is defined in the quality management system has to be monitored and its effectiveness is measured.
Clause 8.2.4: Monitoring and measurement of product
The information obtained from the metrics for each product can be analyzed to study the effectiveness of the product's processes.

Clause 8.3: Control of non-conforming product

Appropriate action needs to be taken to ensure that the product that is found to be non-conforming is not delivered to the customer.

Clause 8.4: Analysis of data

To ensure the effectiveness of the quality management system, the management has to collect the data that can be obtained from customers, suppliers, process metrics, product metrics etc for the study.

Clause 8.5: Improvement

Clause 8.5.1: Continual Improvement
For continually improving the organization's performance, the quality management system should be continuously improved based on the inputs such as customer feedback, external and internal audit reports, supplier's feedback etc.
Clause 8.5.2: Corrective action
The corrective action is to be taken to remove the defects when a product has non-conformities.
Clause 8.5.3: Preventive action
Potential non-conformities are identified and preventive action is taken. Records of corrective action provides good inputs to take preventive actions.

International Standard Organization ISO 9001:2000 Clause 7 Part II

Clause 7.4: Purchasing

Clause 7.4.1: Purchasing Processes
There should be some defined procedures for the selection of suppliers and verification of purchased products.
Clause 7.4.2: Purchasing Information
When you purchase a product, the manager has to specify the product specifications, the quality management system requirements and many other requirements such as installation, warranty, maintenance etc.
Clause 7.4.3: Verification of Purchased Product
The project manager has to specify the acceptance criteria for the proposed product and when the supplier gives the product, the verification has to be done as per procedure.

Clause 7.5: Production and Service Operations

Clause 7.5.1: Control of production and service provision
Proper planning has to be done to make multiple copies, installation, and later maintenance of the product when delivered to the customers.
Clause 7.5.2: Validation of processes for production and service provision
Process has to be established to obtain the feedback on the performance of the product from the customer in cases where the verification is not possible.
Clause 7.5.3: Identification and traceability
The product should be identified and traceable during all stages of production, delivery, and installation.
Clause 7.5.4: Customer Property
The customer may give some of its property to the developer. In such cases, the development organization has to take proper care of the customer's property.
Clause 7.5.5: Preservation of the product
A process has to be defined for identification of the product, packaging, storage, and protection.

Clause 7.6: Control of monitoring and measuring devices

It is necessary to ensure that the test and measuring instruments such as oscilloscopes, protocol analyzers etc uses to ensure that the product meets the requirements are working well.

International Standard Organization ISO 9001:2000 Clause 7 Part I

Clause 7: Product Realization

Clause 7.1: Planning of Product Realization
Quality manual gives the overall processes to be followed in the organization. A separate project plan is developed. The project plan gives the details of the quality objectives to be met, processes to be followed etc.

Clause 7.2: Customer Related Processes

Clause 7.2.1: Determination of requirements related to the product
A SRS document is maintained from the requirements that are to be obtained by the customer. This is done by the project team.
Clause 7.2.2: Review of requirements related to the product
The project team has to ensure that the requirements of the customer are well defined, documented and can be implemented. A written agreement should be there between the customer and the development organization on the requirements specifications.
Clause 7.2.3: Customer Communication A procedure for communication with the customer should be formalized by the project team.

Clause 7.3: Design and Development

Clause 7.3.1: Design and development planning
Interfaces should be defined, identify inputs and outputs, review process, verification and validation of design and controlling the design changes.
Clause 7.3.2: Design and development inputs Inputs that are required for design and development of the product should be identified.
Clause 7.3.3: Design and development outputs
The outputs of the design and development phase should include the product that meets the requirements, product acceptance criteria and user manuals.
Clause 7.3.4: Design and development review
To ensure that the work is progressing in the right direction and the end product is meeting all requirements as specified in SRS, the design and development has to be periodically reviewed.
Clause 7.3.5: Design and development verification
The project manager has to carry out the necessary verification of the design and development so that each and every requirement of the SRS is met.
Clause 7.3.6: Design and development validation
To ensure that the project is implemented as per plan, validation is done.
Clause 7.3.7: Control of design and development changes
During design and development, a number of changes are likely in SRS document are already prepared. Whenever a change is made, that change has to be estimated and conscious decision has to be taken.

International Standard Organization ISO 9001:2000 Clause 6

Clause 6: Resource Management

Clause 6.1: Provision of resources The resources that are necessary to implement the quality management system should be in place. This should be ensured by the management.

Clause 6.2: Human Resources

Clause 6.2.1: General By selecting the right people and by imparting the necessary training, the management has to ensure that the people have the necessary competence.
Clause 6.2.2: Competence, awareness and training:
The management has to ensure that each and every employee has the necessary understanding of the quality, development processes and the products.

Clause 6.3: Infrastructure

The management has to provide the necessary hardware , software, testing tools and also supporting services such as communication facilities, Internet access etc. so that the employees can carry out their responsibility to meet the quality requirements.

Clause 6.4: Work environment

A friendly work environment is a must to deliver quality products and the management has to provide such a work environment.

International Standard Organization ISO 9001:2000 Clause 5

Clause 5: Management Responsibility

Clause 5.1: management Commitment
The measurable quality objectives that are meant to meet customer requirements should be defined and communicated the quality objectives to employees.
Clause 5.2: Customer Focus
The management has to ensure that the customer's requirements are well understood and the customer is well satisfied with the product.
Clause 5.3: Quality Policy
The quality policy reflects the commitment of the management. The quality of the policy has to be signed by the Chief Executive Officer of the organization.

Clause 5.4: Planning

Clause 5.4.1: Quality Objectives
Quality objectives such as increasing productivity, reducing defects etc. has to be defined by the management based on the quality policy of the management.
Clause 5.4.2: Quality management system planning
A quality management system has to be planned by the management to meet the quality objectives. The details of the processes are to be defined.

Clause 5.5: Responsibility, Authority and Communication

Clause 5.5.1: Responsibility and Authority
The quality management system makes it compulsory that a proper and a clear organization chart is drawn, indicating the reporting structure and the responsibilities and authorities of each individual.
Clause 5.5.2: Management Representative
The management representative should be appointed who has the responsibility and authority to implement the quality management system.
Clause 5.5.3: Internal Communication
To avoid lack of communication among team members, a proper procedure for internal communication should be established so that all the employees are in unison.

Clause 5.6: Management Review

Clause 5.6.1: General
Quality policy, quality objectives and quality manual should be periodically reviewed to discuss the effectiveness and possible improvements.
Clause 5.6.2: Review Inputs
The inputs have to be obtained from customers, external auditors, and internal auditors.
Clause 5.6.3: Review output
The outputs will be the action points needed for effective quality management system implementation. This is done after the management review.

International Standard Organization ISO 9001:2000 Clauses 1-4

ISO 9001:2000 standard gives the requirements to develop a quality management system. The standard has eight clauses.

Clause 1: Scope
The first clause specifies the scope of the document which defines the quality management system to deliver a quality product.
Clause 2: Normative Reference
All the references to the document are specified in this clause.
Clause 3: Terms and Definitions
All the terms and conditions that are specified in ISO 9000:2000 are specified in this clause.
Clause 4.1: General Requirements
To deliver a quality product, the management should have a well-defined and documented quality management system that defines the processes to be followed. The processes should include both technical and managerial processes.
Clause 4.2: Documentation Requirements
Quality policy, Quality manual, Detailed definition of procedures mentioned in quality manual, Quality records are included in the documentation of quality management.
Clause 4.2.2: Quality Manual
All the processes that are to be followed for the entire software development life cycle should be described in quality manual. The quality manual can refer to other documents that gives details of the process definition.
Clause 4.2.3: Control of documents
A procedure should be established for controlling the documents as the documents related to the processes and projects will change time to time.
Clause 4.2.4: Control of records
It is necessary to maintain records to give evidence to the external auditing agencies that the quality system is being effectively operational.

ISO 9000:2000 - The International Quality Standard

To deliver the product that is in terms with the specifications given by the customer should be the main objective of the project manager, every team member as well as the senior management.
The management of every organization has to adapt quality standards so that quality is ensured in every product that is delivered. In any standardization process, metrics play an important role. For software engineering, ISO 9000 and Capability Maturity Model Integration are the most widely used international standards.
The quality management system to be developed as per ISO 9000 guidelines is used for quality assurance.
The ISO 9000 quality management system is generic in nature and applicable to
all companies, regardless of the type and size of the business, including small and
medium enterprises (SMEs), and they are applicable to all categories of products,
whether hardware, software, processed materials or services.

ISO 9000:2000
- It establishes a starting point for understanding the standards.
- It defines the fundamental terms and definitions used in the ISO 9000 family to avoid confusion in their use.
- The ISO-9000:2000, being process-oriented, can be applied to virtually any industry worldwide, and is certainly widely embraced in the semiconductor industry.
- This standard describes the concepts of a quality management system (QMS) and
defines the fundamental terms used in the ISO 9000 family.
- The standard also includes the eight quality management principles which were used to develop ISO 9001 and ISO 9004.
- This standard replaces ISO 8402:1994 and ISO 9000-1:1994.

Metrics in Software Development - Quality metrics

Software Quality Metrics focus on the process, project and product. By analyzing the metrics the organization the organization can take corrective action to fix those areas in the process, project or product which are the cause of the software defects.
The quality of the product is ensured by the following metrics :
- Number of defects found per KDSI (also known as defect density).
- Number of changes requested by the customer after the software is delivered.
- MTBF(Mean Time Between Failures).
- MTTR(Mean Time To Repair) i.e. the average time that is required to remove a detect after it has been detected.

Common software metrics include bugs per line of code, code coverage, cohesion, coupling, cyclomatic complexity, function point analysis, number of classes and interfaces, number of lines of customer requirements, order of growth,source lines of code, Robert Cecil Martin’s software package metrics.

To measure the quality of the output of a development phase, the SQA team has to define the metrics. For instance, during the requirements engineering phase, SRS document is written. Then design, implementation, and testing are done. While doing the design or implementation or while carrying out the testing, the SRS document may have to be changed. The number of changes made to the SRS document can be a metric to measure the quality of the requirements engineering process.
Although there are many measures of software quality, correctness, maintainability, integrity and usability provide useful insight.

Software Development Metrics : Product and Productivity Metrics

Metrics are needed to understand the level of process performance, project performance and product performance. They are needed to set goals and measure the trend and rate of improvement. Criteria for effective metrics are:
- Simple.
- Keep them to a minimum.
- Base them on business objectives and the business process - avoid those that cause dysfunctional behavior.
- Keep them practical.

Product Metrics

One accepted method of estimating the size of the product is using the metric KDSI (Kilo or Thousand Delivered Source Instruction) or Kilo Lines of Code (KLOC) - how many thousands of lines of code are required for the project excluding the comments. Based on KDSI, a project can be categorized as small, intermediate, medium, large or very large.
- Small <= 2 KDSI
- Intermediate >2 and <=8 KDSI
- Medium >8 and <=32 KDSI
- Large >32 and <=128 KDSI
- Very large >128 KDSI

Productivity Metrics

Another metric that can be used for measuring the productivity of the programmer is counting the number of lines that can be written by a programmer in one hour i.e. the Delivered Source Instructions (DSI) per hour.
Time required for execution of a project(in hours) = Total KDSI of the project/average KDSI per hour.

Synchronize and stabilize lifecycle model

The synchronize and stabilize lifecycle model defines an overall approach for developing and managing large-scale software systems.
Synchronize-and-stabilize (also called sync-and-stabilize) is a Systems Development Life Cycle methodology in which teams work concurrently on individual application modules. They frequently synchronize their code with that of other teams, and debug or “stabilize” their code regularly throughout the development process.
The special feature of this model is that the specification are complete only when the product is ready. This model has been used extensively by many innovative product development organizations.

Advantages of Synchronize-and-stabilize model

- The periodic system building approach paves way for testing the software for both functionality and performance.
- Project monitoring will be easy as there are intermediate milestones.
- The integration problems encountered in large projects using other models are eliminated in this model.
- Because of intermediate releases, the product can be made feature rich by incorporating the necessary feedback.

Disadvantages of Synchronize-and-stabilize model

- A parallel independent testing team needs to be in place.
- The detailed specifications document will be made available only at time of release.
- Periodic system builds require a rigorous process to be defined for integration of various modules.

Spiral Model - A type of software development life cycle model

Boehm proposed the spiral model in 1988. A useful model for projects involving high risks. each loop in spiral represents a development phase. Each loop is split into four sections which carry out a specific task.
- Determine the objectives, alternatives, and constraints.
- Analysis of risk and to evaluate alternatives.
- Execution of that phase of development.
- Planning the next phase.
For each round of spiral, one form is top be filled with information like :
- Objectives
- Alternatives
- Constraints
- Risk factors
- Risk resolution
- Results
- Plans
- Commitment
At the end of each spiral the management can review the status based on this form and decide the future course of action.

Advantages of Spiral Model

- Estimates become more realistic as work progresses.
- The model is designed to cope with the inevitable changes to the learning experience that will happen over the course of design and delivery.
- Multimedia producers can get their hands in and start working on a project earlier, and therefore shape the design process as well.

Disadvantages of Spiral Model

- Highly customized limiting re-usability.
- Applied differently for each application.
- Risk of not meeting budget or schedule.
- Risk of not meeting budget or schedule.

Prototyping Software Life Cycle Model - a type of SDLC Model

Prototyping model starts with requirements gathering.The basic idea here is that instead of freezing the requirements before a design or coding can proceed, a throwaway prototype is built to understand the requirements. Prototyping is an attractive idea for complicated and large systems for which there is no manual process or existing system to help determining the requirements.
- Prototype is generally developed at the cost of the developer and not at the cost of the client.
- A prototype is developed using prototyping tools such as scripting languages or Rapid Application Development.
- Prototyping is generally required to obtain user interface requirements.
- In hardware, prototyping is used to prove your design concepts.

Advantages of Prototyping Model

- It is good for developing software for users who are not IT-literate.
- Errors can be detected much earlier as the system is mode side by side.
- Quicker user feedback is available leading to better solutions.
- Reduced time and costs.
- An SRS will be frozen after obtaining the feedback from the user.

Disadvantages of Prototyping Model

- Development cost is borne by the developer.
- Customer could believe the prototype as the working version.
- Users can begin to think that a prototype, intended to be thrown away, is actually a final system that merely needs to be finished or polished.
- Excessive development time of the prototype.
- Expense of implementing prototyping.

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.