V Model and Water Model Software Life Cycle Diffrences!!

Pros & Cons of Water Fall Model

* Enforced discipline through documents.
* No phase is complete until the docs are done & checked by SQA group.
* Concrete evidence or progress.
* Testing is inherent in every phase.

* No fair division of phases in the life cycle.
* The following phase should not start until the previous phase has finished
* Document driven model as a result customers cannot understand these.
* Re-design is problematic.

Pros & Cons of V -Model

* Simple and easy to use.
* Each phase has specific deliverables.
* Higher chance of success over the waterfall model due to the development early on during the life cycle.
* Works well for small projects where requirements are easily understood.

* Very rigid, like the waterfall model.
* Little flexibility and adjusting scope is difficult and expensive.
* Software is developed during the implementation phase, so no early prototype software are produced.
* Model doesn’t provide a clear path for problems found during testing phases.

What are the documents prepared in Testing cycle ?

What are the documents prepared in Testing cycle ?

Testing cycle involves the following documents:

* FRS (Functional requriment specfication)
* SRS (Software requriment specfication)
* Design documents
Above documents needed to carry testing.

Apart form this

* Test Plan
* Test Case Matrix
* Traceability Matrix
* Issue Logs are prepared

Testing Process

The Test Planning Process


What is a Test Strategy? What are its Components?

Test Policy - A document characterizing the organization’s philosophy towards software testing.

Test Strategy - A high-level document defining the test phases to be performed and the testing within those phases for a programme. It defines the process to be

followed in each project. This sets the standards for the processes, documents, activities etc. that should be followed for each project.

For example, if a product is given for testing, you should decide if it is better to use black-box testing or white-box testing and if you decide to use both, when will

you apply each and to which part of the software? All these details need to be specified in the Test Strategy.

Project Test Plan - a document defining the test phases to be performed and the testing within those phases for a particular project.

A Test Strategy should cover more than one project and should address the following issues: An approach to testing high risk areas first, Planning for testing, How to

improve the process based on previous testing, Environments/data used, Test management - Configuration management, Problem management, What Metrics are

followed, Will the tests be automated and if so which tools will be used, What are the Testing Stages and Testing Methods, Post Testing Review process,

Templates.

Test planning needs to start as soon as the project requirements are known. The first document that needs to be produced then is the Test Strategy/Testing

Approach that sets the high level approach for testing and covers all the other elements mentioned above.


Usually, Testing is considered as a part of the System Development Life Cycle. With our practical experience, we framed this Test Development Life Cycle.
The diagram does not depict where and when you write your Test Plan and Strategy documents. But, it is understood that before you begin your testing activities
these documents should be ready. Ideally, when the Project Plan and Project Strategy are being made, this is the time when the Test Plan and Test Strategy documents are also made.

IN General - STLC (Software Testing Life Cycle)

SOFTWARE TESTING LIFE CYCLE


It contains 6 phases.


1. TEST PLANNING.
2. TEST ANALYSIS & DESIGN.
3. TEST EXECUTION. ------* Writing test cases
* Review test cases
* Executing test cases
4. RESULT ANALYSIS.
5. BUG TRACKING.
6. REPORTING.

Software Testing Life Cycle consist of six (generic) phases: 1) Planning, 2) Analysis, 3) Design, 4) Construction, 5) Testing Cycles, 6) Final Testing and Implementation and 7) Post Implementation. Each phase in the life cycle is described with the respective activities.

Planning. Planning High Level Test plan, QA plan (quality goals), identify – reporting procedures, problem classification, acceptance criteria, databases for testing, measurement criteria (defect quantities/severity level and defect origin), project metrics and finally begin the schedule for project testing. Also, plan to maintain all test cases (manual or automated) in a database.

Analysis. Involves activities that - develop functional validation based on Business Requirements (writing test cases basing on these details), develop test case format (time estimates and priority assignments), develop test cycles (matrices and timelines), identify test cases to be automated (if applicable), define area of stress and performance testing, plan the test cycles required for the project and regression testing, define procedures for data maintenance (backup, restore, validation), review documentation.

Design. Activities in the design phase - Revise test plan based on changes, revise test cycle matrices and timelines, verify that test plan and cases are in a database or requisite, continue to write test cases and add new ones based on changes, develop Risk Assessment Criteria, formalize details for Stress and Performance testing, finalize test cycles (number of test case per cycle based on time estimates per test case and priority), finalize the Test Plan, (estimate resources to support development in unit testing).

Construction (Unit Testing Phase). Complete all plans, complete Test Cycle matrices and timelines, complete all test cases (manual), begin Stress and Performance testing, test the automated testing system and fix bugs, (support development in unit testing), run QA acceptance test suite to certify software is ready to turn over to QA.

Test Cycle(s) / Bug Fixes (Re-Testing/System Testing Phase). Run the test cases (front and back end), bug reporting, verification, revise/add test cases as required.

Final Testing and Implementation (Code Freeze Phase). Execution of all front end test cases - manual and automated, execution of all back end test cases - manual and automated, execute all Stress and Performance tests, provide on-going defect tracking metrics, provide on-going complexity and design metrics, update estimates for test cases and test plans, document test cycles, regression testing, and update accordingly.

Post Implementation. Post implementation evaluation meeting can be conducted to review entire project. Activities in this phase - Prepare final Defect Report and associated metrics, identify strategies to prevent similar problems in future project, automation team - 1) Review test cases to evaluate other cases to be automated for regression testing, 2) Clean up automated test cases and variables, and 3) Review process of integrating results from automated testing in with results from manual testing.

Fish Model

Fish Model

Verification:

Verification is a process of checking conducted on each and every role of an organization in order to check whether he is doing his tasks in a right manner according to the guidelines or not. Right from the starting of the process tiles the ending of the process. Usually the documents are verified in this process of checking.

Validation
Validation is a process of checking conducted on the developed product in order to check whether it is working according to the requirements or not.

Advantages
As the verification and validation are done the outcome of a Fish Model is a quality product.

Drawbacks
Time consuming and costly model.

Evolutionary Model

Evolutionary Model

Advantages

Whenever the customer is revolving the requirements this is the best suitable model.


Drawbacks

Dead lines are not clearly defined
Project monitoring and maintenance is difficult.

Rapid Application Development (RAD) model

Rapid Application Development (RAD) model

RAD model makes heavy use of reusable software components with an extremely short development cycle.
The RAD is a linear sequential software development process that emphasizes an extremely short development cycle. The RAD software model is a "high speed"

adaptation of the linear sequential model in which rapid development is achieved by using a component-based construction approach. Used primarily for information

systems applications, the RAD approach encompasses the following phases
§ Business modeling
§ Data modeling
§ Process modeling
§ Application generation
§ Testing
RAD process emphasizes reuse many of the program components have already been tested, which minimizes the testing and development time.

Spiral - model

Spiral - model

§ This model of development combines the features of the prototyping model and the waterfall model. The spiral model is favored for large, expensive, and

complicated projects.
§ The spiral model is similar to the incremental model, with more emphases placed on risk analysis. The spiral model has four phases: Planning, Risk

Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral,

starting in the planning phase, requirements is gathered and risk is assessed. Each subsequent spiral builds on the baseline spiral.
§ Requirements are gathered during the planning phase. In the risk analysis phase, a process is undertaken to identify risk and alternate solutions. A

prototype is produced at the end of the risk analysis phase.
§ Software is produced in the engineering phase, along with testing at the end of the phase. The evaluation phase allows the customer to evaluate the

output of the project to date before the project continues to the next spiral.
§ In the spiral model, the angular component represents progress, and the radius of the spiral represents cost.

Advantages
§ High amount of risk analysis.
§ Risks are explicitly assessed and resolved throughout the process
§ Focus on early error detection and design flaws.
§ Good for large and mission-critical projects.
§ Software is produced early in the software life cycle.

Disadvantages
§ Can be a costly model to use.
§ Risk analysis requires highly specific expertise.
§ Project’s success is highly dependent on the risk analysis phase.
§ Doesn’t work well for smaller projects.

Strengths:
•It promotes reuse of existing software in early stages of development
•Allows quality objectives to be formulated during development
•Provides preparation for eventual evolution of the software product
•Eliminates errors and unattractive alternatives early.
•It balances resource expenditure.
•Doesn’t involve separate approaches for software development and software maintenance.
•Provides a viable framework for integrated Hardware-software system development.

Weakness:
•This process needs or usually associated with Rapid Application Development, which is very difficult practically.
•The process is more difficult to manage and needs a very different approach as opposed to the waterfall model (Waterfall model has management techniques like

GANTT charts to assess)

Prototype model

Prototype model
In this model, a prototype (an early approximation of a final system or product) is built, tested, and then reworked as necessary until an acceptable prototype is

finally achieved from which the complete system or product can now be developed.
Prototype paradigm begins with requirements gathering. Developer and customer meet and define the overall objectives for the software, identify whatever

requirements are known, and outline areas where further definition is mandatory.
A quick design occurs which leads to the construction of prototype.
The prototype is evaluated by the customer/user and used to refine the requirements for the software to be developed.
Iteration occurs as the prototype is tuned to satisfy the user requirements, while at the same time enabling developer to better understand what needs to be done.

Advantages:

When ever the customer with the requirements then this is the best model to gather the clear requirements.

Drawbacks:
It is not a complete model.
Time consuming model
Prototype has to be build company’s cost
The user may strict to the prototype and limit his requirements

Incremental/Iterative model

Incremental/Iterative model

This model does not attempt to start with full specification of requirements. Multiple development cycles take place here, making the life cycle a “multi-waterfall”

cycle. Cycles are divided up into smaller, more easily managed iterations. Each iteration passes through the requirements, design, implementation and testing phases.
A working version of software is produced during the first iteration, so you have working software early on during the software life cycle. Subsequent iterations build

on the initial software produced during the first iteration.

Key Points
§ Development and delivery is broken down into increments
§ Each increment delivers part of the required functionality
§ Requirements are prioritised and the highest priority requirements are included in early increments
§ Once the development of an increment is started, the requirements are frozen
§ Requirements for later increments can continue to evolve


Advantages
§ System functionality is available earlier and customer does not have to wait as long.
§ Early increments act as a prototype to help elicit requirements for later increments.
§ The highest priority functionalities tend to receive more testing.
§ More flexible – less costly to change scope and requirements.
§ Easier to test and debug during a smaller iteration.
§ Easier to manage risk because risky pieces are identified and handled during its iteration.
§ Each iteration is an easily managed milestone.

Disadvantages
§ Each phase of an iteration is rigid and do not overlap each other.
§ Problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle.

V Model

V - model

* This is the most common and classic of life cycle models, also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a
waterfall model, each phase must be completed in its entirety before the next phase can begin. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project. Unlike what we mentioned in the general model, phases do not overlap in a waterfall model.

The least flexible and most obsolete of the life cycle models. Well suited to projects that has low risk in the areas of user interface and performance requirements, but

high risk in budget and schedule predictability and control.

Advantages
§ Simple and easy to use.
§ Each phase has specific deliverables.
§ Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle.
§ Works well for small projects where requirements are easily understood.

Disadvantages
§ Very rigid, like the waterfall model.
§ Little flexibility and adjusting scope is difficult and expensive.
§ Software is developed during the implementation phase, so no early prototypes of the software are produced.
§ Model doesn’t provide a clear path for problems found during testing phases.

Waterfall Lifecycle Model/ Linear Sequential/ Classic Life Cycle Model

Water fall / Linear Sequential /Classic Life Cycle Model

The "waterfall model", documented in 1970 by Royce was the first publicly documented life cycle model. The model was developed to help with the increasing complexity of aerospace products.

This is the most common and classic of life cycle models, also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed in its entirety before the next phase can begin. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project. Unlike what I mentioned in the general model, phases do not overlap in a waterfall model.

The least flexible and most obsolete of the life cycle models. Well suited to projects that has low risk in the areas of user interface and performance requirements, but high risk in budget and schedule predictability and control.

Advantages
§ Simple and easy to use.
§ Easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.
§ Phases are processed and completed one at a time.
§ Works well for smaller projects where requirements are very well understood/stable.

Disadvantages
§ It’s difficult to respond to changing customer requirements.
§ Adjusting scope during the life cycle can kill a project
§ No working software is produced until late during the life cycle.
§ High amounts of risk and uncertainty.
§ Poor model for complex and object-orented projects.
§ Poor model for long run and ongoing projects.
Waterfall Model

Strengths:
•Emphasizes completion of one phase before moving on
•Emphasises early planning, customer input, and design
•Emphasises testing as an integral part of the life cycle •Provides quality gates at each life cycle phase

Weakness:
•Depends on capturing and freezing requirements early in the life cycle
•Depends on separating requirements from design
•Feedback is only from testing phase to any previous stage
•Not feasible in some organizations
•Emphasises products rather than processes

Various Software Life Cycle Models

What is Software Development Life Cycle (SDLC)?

The various activities that are undertaken when developing software are commonly modelled as a software development lifecycle. The software development lifecycle begins with the identification of a requirement for
software and ends with the formal verification of the developed software against that requirement.

The software development lifecycle does not exist by itself; it is in fact part of an overall product lifecycle. Within the product lifecycle, software will undergo maintenance to correct errors and to comply with changes to requirements. The simplest overall form is where the product is just software, but it can become much more complicated with multiple software developments, each forming part of an overall system to comprise a product.

There are a number of different models for software development lifecycles. Some of the more commonly used models are:

-> Waterfall Lifecycle Model/ Linear Sequential/ Classic Life Cycle Model
-> Modified Waterfall Lifecycle Model
-> V Lifecycle Model
-> Progressive Development Lifecycle Model
-> Iterative / Incremental Lifecycle Model
-> Spiral Lifecycle Model
-> Prototyping Model
-> RAD Lifecycle Model
-> Evolutionary Model
-> Fish Model
->Fourth Generation (4GT) Techniques

IN General - SDLC (Software Development Life Cycle)

SDLC (Software Development Life Cycle)

It contains 6 phases.

Ø INITIAL PHASE / REQUIREMENT PHASE.
Ø ANALYSIS PHASE.
Ø DESIGN PHASE.
Ø CODING PHASE.
Ø TESTING PHASE.
Ø DELIVERY AND MAINTENANCE PHASE.

Initial Phase
Task Interacting with the customer and gathering the requirements.
Roles BA (Business Annalist)
EM (Engagement Manager)
Process First of all the business analist will take an appointment from the customer, collects the templates from the company meats the customer on the appointed date gathers the requirements with the support of the templates and comeback to the company with a requirements documents. Then the engagement manager will check for the extra requirements if at all he fined any extra requirements he is responsible for the excess cast of the project. The engagement manager is also responsible for prototype demonstration in case of confused requirements.

Template It is defined as a pre-defined format with pre-defined fields used for preparing a document perfectly.

Prototype
It is a rough and rapidly developed model used for demonstrating to the client in order to gather clear requirements and to win the confidence of a customer.

Proof
The proof of this phase is requirements document which is also called with the following name
FRS - (Functional Requirement Specification)
BRS - (Business Requirement Specification)
CRS - (Client/Customer Requirement Specification)
URS - (User Requirement Specification)
BDD - (Business Design Document)
BD - (Business Document)

Note
Some company’s may the over all information in one document called as ‘BRS’ and the detailed information in other document called ‘FRS’. But most of the company’s will maintain both of information in a single document.

Analysis Phase

Task Feasibility study.
Tentative planning.
Technology selection.
Requirement A\analysis.

Roles System Annalist (SA)
Project Manager (PM)
Team Manager (TM)
Process
(I) Feasibility study It is detailed study of the requirements in order to check whether all the requirements are possible are not.
(II) Tentative planning The resource planning and time planning is temporary done in this section.
(III) Technology selection The lists of all the technologies that are to be used to accomplish the project successfully will be analyzed listed out hear in this section.
(IV) Requirement analysis
The list of all the requirements like human resources, hardware, software required to accomplish this project successfully will be clearly analyzed and listed out hear in this section.

Proof The proof of this phase is SRC (Software Requirement Specification).

Design phase

Tasks HLD (High Level Designing) LLD (Low Level Designing)

Roles HLD is done by the CA (Chief Architect). LLD is done by the TL (Technical Lead).

Process
The chief architect will divided the whole project into modules by drawing some diagrams and technical lead will divided each module into sub modules by drawing some diagrams using UML (Unified Modeling Language).The technical lead will also prepare the PSEUDO Code.

Proof The proof of this phase is technical design document (TDD).
Pseudo Code It is a set of English instructions used for guiding the developer to develop the actual code easily.

Module
Module is defined as a group of related functionalities to perform a major task.

Coding Phase

Task Programming / Coding.
Roles Developers / Programmers.
Process
Developers will develop the actual source code by using the PSUEDO Code and following the coding standards like proper indentation, color-coding, proper commenting and etc…

Proof The proof of this phase is SCD (Source Code Document).

Testing Phase

Task Testing.
Roles Test Engineer.
Process

q First of all the Test Engineer will receive the requirement documents and review it for under studying the requirements.

q If at all they get any doubts while understanding the requirements they will prepare the Review Report (RR) with all the list of doubts.

q Once the clarifications are given and after understanding the requirements clearly they will take the test case template and write the test cases.

q Once the build is released they will execute the test cases.

q After executions if at all find any defects then they will list out them in a defect profile document.

q Then they will send defect profile to the developers and wait for the next build.

q Once the next build is released they will once again execute the test cases

q If they find any defects they will follow the above procedure again and again till the product is defect free.

q Once they feel product is defect free they will stop the process.

Proof The proof of this phase is Quality Product.

Test case
Test case is an idea of a Test Engineer based on the requirement to test a particular feature.

Delivery and Maintenance phase

Delivery
Task Installing application in the client environment.
Roles Senior Test Engineers / Deployment Engineer.
Process
The senior test engineers are deployment engineer will go to the client place and install the application into the client environment with the help of guidelines provided in the deployment document.
Maintenance
After the delivery if at all any problem occur then that will become a task based on the problem the corresponding roll will be appointed. Based on the problem role will define the process and solve the problem.

Where exactly testing comes in to picture?
Which many sort of testing are there?

There are two sorts of testing.
1. Un conventional testing
2. Conventional testing
Un conventional Testing
It is a sort of testing in which quality assurance people will check each and every out come document right from the initial phase of the SDLC.
Conventional Testing
It is a sort of testing in which the test engineer will test the application in the testing phase of SDLC.
------------------------------------------------------
Also by simple explain
------------------------------------------------------
There are six main stages of SDLC.

1. Requirement
In this phase a techno team takes a requirements form a customer by meeting, what they actually want or what they need in their product.

2. Analysis
In this requirements are converted into documents and covers all the customer requirements called FRS (functional requirement specifications), Finally it will
approved by head or any senior persons of the customer side, After approval the requirements are nail down and the developing process is start right from there.

3. Design
In this phase the design of the product is prepared i.e. all the requirements are converted into the architecture design.(SRS : Software requirement specification is
prepared) .

This phase includes
* LLD - Low Level Design Documentation:
This level deals with lower level modules. The flow of diagram handled here is data Flow Diagram. Developers handle this Level.

* HLD - High Level Design Documentation: This level deals with higher-level modules. The flow of diagram handled here is ER - Entity Relationship. Both

Developers and Testers handle this Level.

4. Coding
In this phase all the requirements of the customer are converted into the code form.

5. Testing
In this phase the software under development is tested for quality of the product, that the product we are builting is error free or a quality product.

This phase includes 2 types of Testing:
i. Static Testing: Testing each and every phase completely is called as Static testing. It is also called as Reviews.
ii. Dynamic Testing: Testing after the completion of the entire project.

6. Maintance:
In this phase the Maintance of the product is carried out .