Monday, 11 January 2010
Working with Arrays in QTP
Dealing with Arrays in QTP
What are Arrays?
An array is a contiguous area in the memory referred to by a common name. It is a series of variables having the same data type. Arrays are used to store related data values. VBScript allows you to store a group of common values together in the same location. These values can be accessed with their reference numbers.
An array is made up of two parts, the array name and the array subscript. The subscript indicates the highest index value for the elements within the array. Each element of an array has a unique identifying index number by which it can be referenced. VBScript creates zero based arrays where the first element of the array has an index value of zero.
Declaring Arrays
An array must be declared before it can be used. Depending upon the accessibility, arrays are of two types:
· Local Arrays: A local array is available only within the function or procedure, where it is declared.
· Global Arrays: A global array is an array that can be used by all functions and procedures. It is declared at the beginning of the VBScript Code.
The Dim statement is used to declare arrays. The syntax for declaring an array is as follows:
Dim Array Name(subscript value)
Where, Array Name is the unique name for the array and Subscript Value is a numeric value that indicates the number of elements in the array dimension within the array.
Static and Dynamic Arrays:
VBScript provides flexibility for declaring arrays as static or dynamic.
A static array has a specific number of elements. The size of a static array cannot be altered at run time. A dynamic array can be resized at any time. Dynamic arrays are useful when size of the array cannot be determined. The array size can be changed at run time.
Ways to work with Arrays
The easiest way create an array is to simply declare it as follows
Dim strCustomers()
Another method is to define a variable and then set it as an array afterwards
Dim strStaff
strStaff = Array("Alan","Brian","Chris")
Yet another way is to use the split command to create and populate the array
Dim strProductArray
strProductArray = "Keyboards,Laptops,Monitors"
strProductArray = Split(strProductArray, ",")
To itterate through the contents of an array you can use the For Each loop
Dim strProductArray
strProductArray = "Keyboards,Laptops,Monitors"
strProductArray = Split(strProductArray, ",")
Dim i
For i=LBound(strProductArray) To UBound(strProductArray)
Msgbox strProductArray(i)
Next
This will itterate through the array backwards
Dim strProductArray
strProductArray = "Keyboards,Laptops,Monitors"
strProductArray = Split(strProductArray, ",")
For i = UBound(strProductArray) To LBound(strProductArray) Step -1
Msgbox strProductArray(i)
Next
To add extra data to an array use Redim Preserve
Dim strProductArray
strProductArray = "Keyboards,Laptops,Monitors"
strProductArray = Split(strProductArray, ",")
For i = UBound(strProductArray) To LBound(strProductArray) Step -1
Msgbox strProductArray(i)
next
Redim Preserve strProductArray(3)
strProductArray(3) = "Mice"
For i = UBound(strProductArray) To LBound(strProductArray) Step -1
Msgbox strProductArray(i)
next
To itterate through the contents of an array you can use the For Each loop
Dim strProductArray
strProductArray = "Keyboards,Laptops,Monitors"
strProductArray = Split(strProductArray, ",")
Dim strItem
For Each strItem In strProductArray
MsgBox strItem
Next
To store the contents of an array into one string, use Join
Dim strProductArray
strProductArray = "Keyboards,Laptops,Monitors"
strProductArray = Split(strProductArray, ",")
Msgbox Join(strProductArray, ",")
To delete the contents of an array, use the Erase command
Dim strProductArray
strProductArray = "Keyboards,Laptops,Monitors"
strProductArray = Split(strProductArray, ",")
Erase strProductArray
Msgbox Join(strProductArray, ",")
Virtual Objects In QTP
When QTP fails to identify an object in the application,virtual objects are used.It is a feature provided by QTP where we can define an area that is nonstandard object in the application to a class and methods can be applied.Now you must be thinking that way QTP doesn't recognise any object.It mainly happens because we don't have proper add ins.Using virtual Object Wizard we can map non standard objects to standard objects.
When you want QuickTest to recognize virtual objects during
recording, ensure that the Disable recognition of virtual objects while
recording check box in the General tab of the Options dialog box is cleared.
Tools-Option-General.
Group of Virtual Objects that i stored in the virtual Object Manager under a descriptive name is knows as virtual object collection.
Virtual Objects collection definitons are saved with .vot extensions under QTP\Dat\vo template folder.
If you want to copy virtual object collection from one computer to another then you have to copy the .vot file and paste it in the same location.
virtual objects can only be defined for objects on which you can click or double click.
QuickTest identifies a virtual object according to its boundaries. Marking an object’s boundaries specifies its size and position on a Web page or application window. When you assign a test object as the parent of your virtual object, you specify that the coordinates of the virtual object boundaries are relative to that parent object. When you record a test,QuickTest recognizes the virtual object within the parent object and adds its a test object in the object repository so that QuickTest can identify the object during the run session. QuickTest also recognizes the virtual object as a test object when you add it manually to the object repository.
Disadvantage:- When you assign a test object as virtual object through the wizard you specifiy the coordinates of the virtual object boundaries.virtual object loses its identification on resizing the page.
When you want QuickTest to recognize virtual objects during
recording, ensure that the Disable recognition of virtual objects while
recording check box in the General tab of the Options dialog box is cleared.
Tools-Option-General.
Group of Virtual Objects that i stored in the virtual Object Manager under a descriptive name is knows as virtual object collection.
Virtual Objects collection definitons are saved with .vot extensions under QTP\Dat\vo template folder.
If you want to copy virtual object collection from one computer to another then you have to copy the .vot file and paste it in the same location.
virtual objects can only be defined for objects on which you can click or double click.
QuickTest identifies a virtual object according to its boundaries. Marking an object’s boundaries specifies its size and position on a Web page or application window. When you assign a test object as the parent of your virtual object, you specify that the coordinates of the virtual object boundaries are relative to that parent object. When you record a test,QuickTest recognizes the virtual object within the parent object and adds its a test object in the object repository so that QuickTest can identify the object during the run session. QuickTest also recognizes the virtual object as a test object when you add it manually to the object repository.
Disadvantage:- When you assign a test object as virtual object through the wizard you specifiy the coordinates of the virtual object boundaries.virtual object loses its identification on resizing the page.
Saturday, 9 January 2010
Software Testing life cycle
Test Plan Preparation
The software test plan is the primary means by which software testers communicate to the product development team what they intend to do. The purpose of the software test plan is to prescribe the scope, approach, resource, and schedule of the testing activities. To identify the items being tested, the features to be tested, the testing tasks to be preformed, the personnel responsible for each task, and the risks associated with the plan.
The test plan is simply a by-product of the detailed planning process that’s undertaken to create it. It’s the planning that matters, not the resulting documents. The ultimate goal of the test planning process is communicating the software test team’s intent, its expectations, and its understanding of the testing that’s to be performed.
The following are the important topics, which helps in preparation of Test plan.
High-Level Expectations
The first topics to address in the planning process are the ones that define the test team’s high-level expectations. They are fundamental topics that must be agreed to, by everyone on the project team, but they are often overlooked. They might be considered “too obvious” and assumed to be understood by everyone, but a good tester knows never to assume anything.
People, Places and Things
Test plan needs to identify the people working on the project, what they do, and how to contact them. The test team will likely work with all of them and knowing who they are and how to contact them is very important.
Similarly, where documents are stored, where the software can be downloaded from, where the test tools are located, and so on need to be identified.
Inter-Group Responsibilities
Inter-Group responsibilities identify tasks and deliverables that potentially affect the test effort. The test team’s work is driven by many other functional groups – programmers, project manages, technical writers, and so on. If the responsibilities aren’t planned out, the project, specifically the testing, can become a worst or resulting in important tasks been forgotten.
Test phases
To plan the test phases, the test team will look at the proposed development model and decide whether unique phases, or stages, of testing should be performed over the course of the project. The test planning process should identify each proposed test phase and make each phase known to the project team. This process often helps the entire team from and understands the overall development model.
Test strategy
The test strategy describes the approach that the test team will use to test the software both overall and in each phase. Deciding on the strategy is a complex task- one that needs to be made by very experienced testers because it can determine the successes or failure of the test effort.
Bug Reporting
Exactly what process will be used to manage the bugs needs to be planned so that each and every bug is tracked, from when it’s found to when it’s fixed – and never, ever forgotten.
Metrics and Statistics
Metrics and statistics are the means by which the progress and the success of the project, and the testing, are tracked. The test planning process should identify exactly what information will be gathered, what decisions will be made with them, and who will be responsible for collecting them.
Risks and Issues
A common and very useful part of test planning is to identify potential problem or risky areas of the project – ones that could have an impact on the test effort.
Test Case Design
The test case design specification refines the test approach and identifies the features to be covered by the design and its associated tests. It also identifies the test cases and test procedures, if any, required to accomplish the testing and specifics the feature pass or fail criteria. The purpose of the test design specification is to organize and describe the testing needs to be performed on a specific feature.
The following topics address this purpose and should be part of the test design specification that is created:
Test case ID or identification
A unique identifier that can be used to reference and locate the test design specification the specification should also reference the overall test plan and contain pointers to any other plans or specifications that it references.
Test Case Description
It is a description of the software feature covered by the test design specification for example, “ the addition function of calculator,” “font size selection and display in word pad,” and “video card configuration testing of quick time.”
Test case procedure
It is a description of the general approach that will be used to test the features. It should expand on the approach, if any, listed in the test plan, describe the technique to be used, and explain how the results will be verified.
Test case Input or Test Data
It is the input the data to be tested using the test case. The input may be in any form. Different inputs can be tried for the same test case and test the data entered is correct or not.
Expected result
It describes exactly what constitutes a pass and a fail of the tested feature. Which is expected to get from the given input.
Test Execution and Test Log Preparation
After test case design, each and every test case is checked and actual result obtained. After getting actual result, with the expected column in the design stage is compared, if both the actual and expected are same, then the test is passed otherwise it will be treated as failed.
Now the test log is prepared, which consists of entire data that were recorded, whether the test failed or passed. It records each and every test case so that it will be useful at the time of revision.
Defect Tracking
A defect can be defined in one or two ways. From the producer's viewpoint, a defect is a deviation from specifications, whether missing, wrong, etc. From the Customer's viewpoint, a defect is any that causes customer dissatisfaction, whether in the requirements or not, this is known as "fit for use". It is critical that defects identified at each stage of the project life cycle be tracked to resolution.
Defects are recorded for following major purposes:
To correct the defect
To report status of the application
To gather statistics used to develop defect expectations in future applications
To improve the software development process
Most project teams utilize some type of tool to support the defect tracking process. This tool could be as simple as a white board or a table created and maintained in a word processor or one of the more robust tools available today, on the market, such as Mercury's Test Director etc. Tools marketed for this purpose usually come with some number of customizable fields for tracking project specific data in addition to the basics. They also provide advanced features such as standard and ad-hoc reporting, e-mail notification to developers and/or testers when a problem is assigned to them, and graphing capabilities.
At a minimum, the tool selected should support the recording and communication significant information about a defect. For example, a defect log could include:
Defect ID number
Descriptive defect name and type
Source of defect -test case or other source
Defect severity
Defect priority
Defect status (e.g. open, fixed, closed, user error, design, and so on) -more robust tools provide a status history for the defect
Date and time tracking for either the most recent status change, or for each change in the status history
Detailed description, including the steps necessary to reproduce the defect
Component or program where defect was found
Screen prints, logs, etc. that will aid the developer in resolution process
Stage of origination
Person assigned to research and/or correct the defect
Severity versus Priority
The severity of a defect should be assigned objectively by the test team based on pre defined severity descriptions. For example a "severity one" defects maybe defined as one that causes data corruption, a system crash, security violations, etc. In large project, it may also be necessary to assign a priority to the defect, which determines the order in which defects should be fixed. The priority assigned to a defect is usually more subjective based upon input from users regarding which defects are most important to them, and therefore should be fixed first.
It is recommended that severity levels be defined at the start of the project so that they intently assigned and understood by the team. This foresight can help test teams avoid the common disagreements with development teams about the criticality of a defect.
Some general principles
The primary goal is to prevent defects. Wherever this is not possible or practical, the goals are to both find the defect as quickly as possible and minimize the impact of the defect.
The defect management process, like the entire software development process, should be risk driven, i.e., strategies, priorities and resources should be based on an assessment of the risk and the degree to which the expected impact of risk can be reduced.
Defect measurement should be integrated into the development process and be used by the project team to improve the development process. In other words, information on defects should be captured at the source as a natural by-product of doing the job. People unrelated to the project or system should not do it.
As much as possible, the capture and analysis of the information should be automated. There should be a document, which includes a list of tools, which have defect management capabilities and can be used to automate some of the defect management processes.
Defect information should be used to improve the process. This, in fact, is the primary reason for gathering defect information.
Imperfect or flawed processes cause most defects. Thus, to prevent defects, the process must be altered.
verification and validation
In simpler terms, verification answers the question "have we built the product right", i.e. is it correct and free from errors, does it meet the specification whereas
Validation asks the question" is this the right product?" have the users got what they wanted. To help you remember this use the following:
Verification
Is it error free, does it do what was specified?
Validation
Is it valid, is this what you really, really want?
Verification requires several types of reviews, including requirements reviews, design reviews,code walkthroughs, code inspections, and test reviews. The system user should be involved in these reviews to find defects before they are built into the system.E.g are Shown in the given below table.
Validation is accomplished simply by executing a real-life function (if you wanted to check to see if your mechanic had fixed the starter on your car, you’d try to start the car).Examples of validation are shown
Validation asks the question" is this the right product?" have the users got what they wanted. To help you remember this use the following:
Verification
Is it error free, does it do what was specified?
Validation
Is it valid, is this what you really, really want?
Verification requires several types of reviews, including requirements reviews, design reviews,code walkthroughs, code inspections, and test reviews. The system user should be involved in these reviews to find defects before they are built into the system.E.g are Shown in the given below table.
Validation is accomplished simply by executing a real-life function (if you wanted to check to see if your mechanic had fixed the starter on your car, you’d try to start the car).Examples of validation are shown
What is a Process?
A process can be defined as a set of activities that represent the way work is performed. The outcome from a process is usually a product or service. Both software development and software testing are processes.There are two ways to visually portray a process.
One is the Plan Do Check Act (PDCA) cycle.
The other is a workbench.
The PDCA cycle is a conceptual view of a process, while the workbench is a more practical illustration of a process.
The PDCA View of a Process
P – Devise a Plan
Define your objective and determine the conditions and methods required to achieve your objective. Describe clearly the goals and policies needed to achieve the objective at this stage.Express a specific objective numerically. Determine the procedures and conditions for the means and methods you will use to achieve the objective.
D – Execute (or Do) the Plan
Create the conditions and perform the necessary teaching and training to execute the plan.Make sure everyone thoroughly understands the objectives and the plan. Teach workers the procedures and skills they need to fulfill the plan and thoroughly understand the job. Then perform the work according to these procedures.
C – Check the Results
Check to determine whether work is progressing according to the plan and whether the
expected results are obtained. Check for performance of the set procedures, changes in conditions, or abnormalities that may appear. As often as possible, compare the results of the work with the objectives.
A – Take the Necessary Action
If your checkup reveals that the work is not being performed according to plan or that results are not as anticipated, devise measures for appropriate action.
If a check detects an abnormality – that is, if the actual value differs from the target value – search for the cause of the abnormality and eliminate the cause. This will prevent the recurrence of the defect. Usually you will need to retrain workers and revise procedures to eliminate the cause of a defect.
The Workbench View of a Process
A process can be viewed as one or more workbenches.Each workbench is
built on the following two components:
Objective – States why the process exists, or its purpose.
Example: A JAD session is conducted to uncover the majority of customer requirements early and efficiently, and to ensure that all involved parties interpret these requirements consistently.
People Skills – The roles, responsibilities, and associated skill sets needed to execute a process. Major roles include suppliers, owners, and customers.
Each workbench has the following components:
Inputs – The entrance criteria or deliverables needed to perform testing.
Procedures – Describe how work must be done; how methods, tools, techniques,
and people are applied to perform a process. There are Do procedures and Check
procedures. Procedures indicate the “best way” to meet standards.
Deliverables – Any product or service produced by a process. Deliverables can be
interim or external (or major). Interim deliverables are produced within the
workbench, but never passed on to another workbench. External deliverables may
be used by one or more workbench, and have one or more customers. Deliverables
serve as both inputs to and outputs from a process.
Example: JAD Notes are interim and Requirements Specifications are external.
Standards – Measures used to evaluate products and identify nonconformance.
The basis upon which adherence to policies is measured.
Tools – Aids to performing the process.
Example: CASE tools, checklists, templates,
One is the Plan Do Check Act (PDCA) cycle.
The other is a workbench.
The PDCA cycle is a conceptual view of a process, while the workbench is a more practical illustration of a process.
The PDCA View of a Process
P – Devise a Plan
Define your objective and determine the conditions and methods required to achieve your objective. Describe clearly the goals and policies needed to achieve the objective at this stage.Express a specific objective numerically. Determine the procedures and conditions for the means and methods you will use to achieve the objective.
D – Execute (or Do) the Plan
Create the conditions and perform the necessary teaching and training to execute the plan.Make sure everyone thoroughly understands the objectives and the plan. Teach workers the procedures and skills they need to fulfill the plan and thoroughly understand the job. Then perform the work according to these procedures.
C – Check the Results
Check to determine whether work is progressing according to the plan and whether the
expected results are obtained. Check for performance of the set procedures, changes in conditions, or abnormalities that may appear. As often as possible, compare the results of the work with the objectives.
A – Take the Necessary Action
If your checkup reveals that the work is not being performed according to plan or that results are not as anticipated, devise measures for appropriate action.
If a check detects an abnormality – that is, if the actual value differs from the target value – search for the cause of the abnormality and eliminate the cause. This will prevent the recurrence of the defect. Usually you will need to retrain workers and revise procedures to eliminate the cause of a defect.
The Workbench View of a Process
A process can be viewed as one or more workbenches.Each workbench is
built on the following two components:
Objective – States why the process exists, or its purpose.
Example: A JAD session is conducted to uncover the majority of customer requirements early and efficiently, and to ensure that all involved parties interpret these requirements consistently.
People Skills – The roles, responsibilities, and associated skill sets needed to execute a process. Major roles include suppliers, owners, and customers.
Each workbench has the following components:
Inputs – The entrance criteria or deliverables needed to perform testing.
Procedures – Describe how work must be done; how methods, tools, techniques,
and people are applied to perform a process. There are Do procedures and Check
procedures. Procedures indicate the “best way” to meet standards.
Deliverables – Any product or service produced by a process. Deliverables can be
interim or external (or major). Interim deliverables are produced within the
workbench, but never passed on to another workbench. External deliverables may
be used by one or more workbench, and have one or more customers. Deliverables
serve as both inputs to and outputs from a process.
Example: JAD Notes are interim and Requirements Specifications are external.
Standards – Measures used to evaluate products and identify nonconformance.
The basis upon which adherence to policies is measured.
Tools – Aids to performing the process.
Example: CASE tools, checklists, templates,
Why Developers are not good testers?
Misunderstandings will not be detected, because the checker will assume that what
the other individual heard from him was correct.
Improper use of the development process may not be detected because the
individual may not understand the process.
The individual may be “blinded” into accepting erroneous system specifications
and coding because he falls into the same trap during testing that led to the
introduction of the defect in the first place.
Information services people are optimistic in their ability to do defect-free work
and thus sometimes underestimate the need for extensive testing.
Without a formal division between development and test, an individual may be
tempted to improve the system structure and documentation, rather than allocate
that time and effort to the test.
the other individual heard from him was correct.
Improper use of the development process may not be detected because the
individual may not understand the process.
The individual may be “blinded” into accepting erroneous system specifications
and coding because he falls into the same trap during testing that led to the
introduction of the defect in the first place.
Information services people are optimistic in their ability to do defect-free work
and thus sometimes underestimate the need for extensive testing.
Without a formal division between development and test, an individual may be
tempted to improve the system structure and documentation, rather than allocate
that time and effort to the test.
What is SDLC?
SDLC Stands for Systems/Software Development Life Cycle.Systems Development Life Cycle (SDLC) is any logical process used by a systems analyst to develop an information system, including requirements, validation, training, and user (stakeholder) ownership. Any SDLC should result in a high quality system that meets or exceeds customer expectations, reaches completion within time and cost estimates, works effectively and efficiently in the current and planned Information Technology infrastructure, and is inexpensive to maintain and cost-effective to enhance.
Model of SDLC
Planning->Analysis->Design->Implementation-maintenance
Computer systems have become more complex and often (especially with the advent of Service-Oriented Architecture) link multiple traditional systems potentially supplied by different software vendors. To manage this level of complexity, a number of systems development life cycle (SDLC) models have been created.They are
1) Waterfall Model
2) Spiral Model
3) RAD(Rapid Application Model)
4) Incremental Model
5) Prototype Modelling
6) Agile Model
7) Big Bang Model
8) V model
Strength and Weakness of SDLC
Waterfall Model
A project using waterfall model moves down a series of steps starting from an initial idea to a final product. At the end of each step, the project team holds a review to determine if they’re ready to move to the next step. If the project isn’t ready to progress, it stays at that level until it’s ready. Each phase requires well-defined information, utilizes well-defined process, and results in well-defined outputs. Resources are required to complete the process in each phase and each phase is accomplished through the application of explicit methods, tools and techniques.
The Waterfall model is also called the Phased model because of the sequential move from one phase to another, the implication being that systems cascade from one level to the next in smooth progression. It has the following seven phases of development:
The figure represents the Waterfall Model.
Notice three important points about this model.
There’s a large emphasis on specifying what the product will be.
The steps are discrete; there’s no overlap.
There’s no way to back up. As soon as you’re on a step, you need to complete the tasks for that step and then move on.
Spiral Model
The traditional software process models don't deal with the risks that may be faced during project development. One of the major causes of project failure in the past has been negligence of project risks. Due to this, nobody was prepared when something unforeseen happened. Barry Boehm recognized this and tried to incorporate the factor, project risk, into a life cycle model. The result is the Spiral model, which was first presented in 1986. The new model aims at incorporating the strengths and avoiding the different of the other models by shifting the management emphasis to risk evaluation and resolution.
Each phase in the spiral model is split into four sectors of major activities.
These activities are as follows:
Objective setting:
This activity involves specifying the project and process objectives in terms of their functionality and performance.
Risk analysis:
It involves identifying and analyzing alternative solutions. It also involves identifying the risks that may be faced during project development.
Engineering:
This activity involves the actual construction of the system.
Customer evaluation:
During this phase, the customer evaluates the product for any errors and modifications.
RAD Model
RAD (rapid application development) is a concept that products can be developed faster and of higher quality through:Also sometimes referred to as Rapid Prototyping, Rapid Application Development is a method of decreasing the time taken to design software systems. It uses incremental development and the construction of prototypes - and encourages constant feedback from users/customers by keeping lines of communication clear - with the end goal of expediting the development cycle.
* 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
Rapid Application Development encouraged the creation of quick-and-dirty prototype-style software which fulfilled most of the user’s requirements but not necessarily all. Development would take place in a series of short cycles, called time boxes, each of which would deepen the functionality of the application a little more. Features to be implemented in each time box were agreed in advance and this game plan rigidly adhered to. The strong emphasis on this point came from unhappy experience with other development practices in which new requirements would tend to be added as the project was evolving, caused massive chaos and disrupting the already carefully prepared plans and development schedules. Rapid Application Development methodology advocated that development be undertaken by small, experienced teams using CASE (Computer Aided Software Engineering) tools to enhance their productivity.
Prototype model
The Prototyping model, also known as the Evolutionary model, came into SDLC because of certain failures in the first version of application software. A failure in the first version of an application inevitably leads to need for redoing it. To avoid failure of SDLC, the concept of Prototyping is used. The basic idea of Prototyping is that instead of fixing requirements before the design and coding can begin, a prototype is to understand the requirements. The prototype is built using known requirements. By viewing or using the prototype, the user can actually feel how the system will work.
The prototyping model has been defined as:
“A model whose stages consist of expanding increments of an operational software with the direction of evolution being determined by operational experience.”
Prototyping Process
The following activities are carried out in the prototyping process:
The developer and die user work together to define the specifications of the critical parts of the system.
The developer constructs a working model of the system.
The resulting prototype is a partial representation of the system.
The prototype is demonstrated to the user.
The user identifies problems and redefines the requirements.
The designer uses the validated requirements as a basis for designing the actual or production software
Prototyping is used in the following situations:
When an earlier version of the system does not exist.
When the user's needs are not clearly definable/identifiable.
When the user is unable to state his/her requirements.
When user interfaces are an important part of the system being developed.
Bin – Bang Model
The Big- Bang Model is the one in which we put huge amount of matter (people or money) is put together, a lot of energy is expended – often violently – and out comes the perfect software product or it doesn’t.
The beauty of this model is that it’s simple. There is little planning, scheduling, or Formal development process. All the effort is spent developing the software and writing the code. It’s and ideal process if the product requirements aren’t well understood and the final release date is flexible. It’s also important to have flexible customers, too, because they won’t know what they’re getting until the very end.
Incremental Model
Incremental model is an evolution of waterfall model. The product is designed, implemented, integrated and tested as a series of incremental builds. It is a popular model software evolution used many commercial software companies and system vendor.
Incremental software development model may be applicable to projects where:
- Software Requirements are well defined, but realization may be delayed.
- The basic software functionality are required early.
Advantages are
- Generates working software quickly and early during the software life cycle.
- 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.
Disadvantages are
- 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
The V-Model, also called the Vee-Model, is a product-development process originally developed in Germany for government defense projects. It has become a common standard in software development. The V-Model gets its name from the fact that the process is often mapped out as a flowchart that takes the form of the letter V.
The development process proceeds from the upper left point of the V toward the right, ending at the upper right point. In the left-hand, downward-sloping branch of the V, development personnel define business requirements, application design parameters and design processes. At the base point of the V, the code is written. In the right-hand, upward-sloping branch of the V, testing and debugging is done. The unit testing is carried out first, followed by bottom-up integration testing. The extreme upper right point of the V represents product release and ongoing support.
The V-Model has gained acceptance because of its simplicity and straightforwardness. However, some developers believe it is too rigid for the evolving nature of IT (information technology) business environments.
The V-model consists of a number of phases. The Verification Phases are on the right hand side of the V, the Coding Phase is at the bottom of the V and the Validation Phases are on the left hand side of the V .
Verification Phases
Requirements analysis
In the Requirements analysis 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. See also Functional requirements, it is to develop in testing in now a days
System Design
Systems design is the phase where 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 are prepared in this phase.
Architecture Design
The phase of the design of computer architecture and software architecture can also be referred to 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.
Module Design
The module design phase can also be referred to as low-level design. The designed system is broken up into 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.
Validation Phases
Unit Testing
In the V-model of software development, unit testing implies the first stage of dynamic testing process. According to software development expert Barry Boehm, a fault discovered and corrected in the unit testing phase is more than a hundred times cheaper than if it is done after delivery to the customer.
It involves analysis of the written code with the intention of eliminating errors. It also verifies that the codes are efficient and adheres to the adopted coding standards. Testing is usually white box. It is done using the Unit test design prepared during the module design phase. This may be carried out by software developers.
Integration Testing
In integration testing the separate modules will be tested together to expose faults in the interfaces and in the interaction between integrated components. Testing is usually black box as the code is not directly checked for errors.
System Testing
System testing will compare the system specifications against the actual system. The system test design is derived from the system design documents and is used in this phase. Sometimes system testing is automated using testing tools. Once all the modules are integrated several errors may arise. Testing done at this stage is called system testing.
User Acceptance Testing
Acceptance testing is the phase of testing used to determine whether a system satisfies the requirements specified in the requirements analysis phase. The acceptance test design is derived from the requirements document. The acceptance test phase is the phase used by the customer to determine whether to accept the system or not. -to develop
Model of SDLC
Planning->Analysis->Design->Implementation-maintenance
Computer systems have become more complex and often (especially with the advent of Service-Oriented Architecture) link multiple traditional systems potentially supplied by different software vendors. To manage this level of complexity, a number of systems development life cycle (SDLC) models have been created.They are
1) Waterfall Model
2) Spiral Model
3) RAD(Rapid Application Model)
4) Incremental Model
5) Prototype Modelling
6) Agile Model
7) Big Bang Model
8) V model
Strength and Weakness of SDLC
Waterfall Model
A project using waterfall model moves down a series of steps starting from an initial idea to a final product. At the end of each step, the project team holds a review to determine if they’re ready to move to the next step. If the project isn’t ready to progress, it stays at that level until it’s ready. Each phase requires well-defined information, utilizes well-defined process, and results in well-defined outputs. Resources are required to complete the process in each phase and each phase is accomplished through the application of explicit methods, tools and techniques.
The Waterfall model is also called the Phased model because of the sequential move from one phase to another, the implication being that systems cascade from one level to the next in smooth progression. It has the following seven phases of development:
The figure represents the Waterfall Model.
Notice three important points about this model.
There’s a large emphasis on specifying what the product will be.
The steps are discrete; there’s no overlap.
There’s no way to back up. As soon as you’re on a step, you need to complete the tasks for that step and then move on.
Spiral Model
The traditional software process models don't deal with the risks that may be faced during project development. One of the major causes of project failure in the past has been negligence of project risks. Due to this, nobody was prepared when something unforeseen happened. Barry Boehm recognized this and tried to incorporate the factor, project risk, into a life cycle model. The result is the Spiral model, which was first presented in 1986. The new model aims at incorporating the strengths and avoiding the different of the other models by shifting the management emphasis to risk evaluation and resolution.
Each phase in the spiral model is split into four sectors of major activities.
These activities are as follows:
Objective setting:
This activity involves specifying the project and process objectives in terms of their functionality and performance.
Risk analysis:
It involves identifying and analyzing alternative solutions. It also involves identifying the risks that may be faced during project development.
Engineering:
This activity involves the actual construction of the system.
Customer evaluation:
During this phase, the customer evaluates the product for any errors and modifications.
RAD Model
RAD (rapid application development) is a concept that products can be developed faster and of higher quality through:Also sometimes referred to as Rapid Prototyping, Rapid Application Development is a method of decreasing the time taken to design software systems. It uses incremental development and the construction of prototypes - and encourages constant feedback from users/customers by keeping lines of communication clear - with the end goal of expediting the development cycle.
* 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
Rapid Application Development encouraged the creation of quick-and-dirty prototype-style software which fulfilled most of the user’s requirements but not necessarily all. Development would take place in a series of short cycles, called time boxes, each of which would deepen the functionality of the application a little more. Features to be implemented in each time box were agreed in advance and this game plan rigidly adhered to. The strong emphasis on this point came from unhappy experience with other development practices in which new requirements would tend to be added as the project was evolving, caused massive chaos and disrupting the already carefully prepared plans and development schedules. Rapid Application Development methodology advocated that development be undertaken by small, experienced teams using CASE (Computer Aided Software Engineering) tools to enhance their productivity.
Prototype model
The Prototyping model, also known as the Evolutionary model, came into SDLC because of certain failures in the first version of application software. A failure in the first version of an application inevitably leads to need for redoing it. To avoid failure of SDLC, the concept of Prototyping is used. The basic idea of Prototyping is that instead of fixing requirements before the design and coding can begin, a prototype is to understand the requirements. The prototype is built using known requirements. By viewing or using the prototype, the user can actually feel how the system will work.
The prototyping model has been defined as:
“A model whose stages consist of expanding increments of an operational software with the direction of evolution being determined by operational experience.”
Prototyping Process
The following activities are carried out in the prototyping process:
The developer and die user work together to define the specifications of the critical parts of the system.
The developer constructs a working model of the system.
The resulting prototype is a partial representation of the system.
The prototype is demonstrated to the user.
The user identifies problems and redefines the requirements.
The designer uses the validated requirements as a basis for designing the actual or production software
Prototyping is used in the following situations:
When an earlier version of the system does not exist.
When the user's needs are not clearly definable/identifiable.
When the user is unable to state his/her requirements.
When user interfaces are an important part of the system being developed.
Bin – Bang Model
The Big- Bang Model is the one in which we put huge amount of matter (people or money) is put together, a lot of energy is expended – often violently – and out comes the perfect software product or it doesn’t.
The beauty of this model is that it’s simple. There is little planning, scheduling, or Formal development process. All the effort is spent developing the software and writing the code. It’s and ideal process if the product requirements aren’t well understood and the final release date is flexible. It’s also important to have flexible customers, too, because they won’t know what they’re getting until the very end.
Incremental Model
Incremental model is an evolution of waterfall model. The product is designed, implemented, integrated and tested as a series of incremental builds. It is a popular model software evolution used many commercial software companies and system vendor.
Incremental software development model may be applicable to projects where:
- Software Requirements are well defined, but realization may be delayed.
- The basic software functionality are required early.
Advantages are
- Generates working software quickly and early during the software life cycle.
- 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.
Disadvantages are
- 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
The V-Model, also called the Vee-Model, is a product-development process originally developed in Germany for government defense projects. It has become a common standard in software development. The V-Model gets its name from the fact that the process is often mapped out as a flowchart that takes the form of the letter V.
The development process proceeds from the upper left point of the V toward the right, ending at the upper right point. In the left-hand, downward-sloping branch of the V, development personnel define business requirements, application design parameters and design processes. At the base point of the V, the code is written. In the right-hand, upward-sloping branch of the V, testing and debugging is done. The unit testing is carried out first, followed by bottom-up integration testing. The extreme upper right point of the V represents product release and ongoing support.
The V-Model has gained acceptance because of its simplicity and straightforwardness. However, some developers believe it is too rigid for the evolving nature of IT (information technology) business environments.
The V-model consists of a number of phases. The Verification Phases are on the right hand side of the V, the Coding Phase is at the bottom of the V and the Validation Phases are on the left hand side of the V .
Verification Phases
Requirements analysis
In the Requirements analysis 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. See also Functional requirements, it is to develop in testing in now a days
System Design
Systems design is the phase where 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 are prepared in this phase.
Architecture Design
The phase of the design of computer architecture and software architecture can also be referred to 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.
Module Design
The module design phase can also be referred to as low-level design. The designed system is broken up into 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.
Validation Phases
Unit Testing
In the V-model of software development, unit testing implies the first stage of dynamic testing process. According to software development expert Barry Boehm, a fault discovered and corrected in the unit testing phase is more than a hundred times cheaper than if it is done after delivery to the customer.
It involves analysis of the written code with the intention of eliminating errors. It also verifies that the codes are efficient and adheres to the adopted coding standards. Testing is usually white box. It is done using the Unit test design prepared during the module design phase. This may be carried out by software developers.
Integration Testing
In integration testing the separate modules will be tested together to expose faults in the interfaces and in the interaction between integrated components. Testing is usually black box as the code is not directly checked for errors.
System Testing
System testing will compare the system specifications against the actual system. The system test design is derived from the system design documents and is used in this phase. Sometimes system testing is automated using testing tools. Once all the modules are integrated several errors may arise. Testing done at this stage is called system testing.
User Acceptance Testing
Acceptance testing is the phase of testing used to determine whether a system satisfies the requirements specified in the requirements analysis phase. The acceptance test design is derived from the requirements document. The acceptance test phase is the phase used by the customer to determine whether to accept the system or not. -to develop
Subscribe to:
Posts (Atom)