Login as root
/sbin/route delete default/sbin/route add default gw new_gateway_ip_address Wednesday, October 11, 2006
What is Risk Analysis?
Risk:Loss to the organization due to risk.
Risk Analysis:evaluation of risks,controls etc.
Risk in real scenarios could be in testing as follows:
1.Resource
2.New technology
3.Knowledge of product
4.lack of business scenarios
5.performance
6.security
7.file integrity etc
we need to identify the risks before hand about the
project/product and calculate the impact of the risk,
and find the reduction process for the risks.
formula for risk:
estimated frequency*loss per occurrence.
and find the solution to avoid the risk.
How to change the default gateway
Tuesday, October 10, 2006
What Business Can Learn from Open Source
Some interesting ideas on modeling a business. Although some ideas
are not practical overall it’s an interesting essay. You can find the authors
bio here:
A trivial tomcat installation issue
If you install a new Tomcat distribution on linux and find when starting tomcat it gives an error like below:
Just make sure that you give ‘executable’ file permissions to
Its quite trivial but it is something you can forget!
The BASEDIR environment variable is not defined correctly
This environment variable is needed to run this programJust make sure that you give ‘executable’ file permissions to
[tomcat_home]/bin/setclasspath.shIts quite trivial but it is something you can forget!
Verification and validation
I would like to add some points for Verification and Validation.
The Software Quality Assurance umberalla activities majorly fall into two categories, Verification and Validation. To explain the two terminologies in simple words, there is no other better sentance than what Roger Pressman quotes in his book on Software Engineering:
Verification answers the question, Are we doing the right job and Validation answers Are we doing the job right. Quite a confusing statement if you are beginning to learn the subject, but as you go on reading, you would understand what they mean.
What is Verification?
Let us suppose that you intend to build a house. What do you do?
1. Choose a piece of land.
2. Buy the land from the government.
3. Engage an Architect.
4. Explain what type of house you intend to build.
5. The Architect draws a sketch on paper and brings your explanation into a pictorial depiction, which can be more easily understandable for everyone.
6. You take this sketch and discuss with your family and take their opinions.
7. You again sit with the architect and explain what others feel and request him to make the necessary changes.
8. The architect makes the required changes and then again you discuss with your family.
9. After your family and you are satisfied with what the depiction of what you are going to build, you approach the government and request them to approve the sketch so that you can build a house.
10. After you get the approval, you engage a contractor and ask him to build the house basing on the sketch.
Oh! Quite a procedure before you build a house. Now, if you look at each step more in detail:
First, you are choosing a land. You check if this land is good for building a house. Are there the necessary facilities like water, telephone connection, electricity connection, good roads and market etc nearer to the land? These are few of the points which arise in your mind when you choose to buy a piece of land. Now, this is Verification. Verification is cross-checking each step which you are doing to perform a task.
On the similar grounds, let us see how we can apply this term when building a software:
1. You are asked to build a software application for maintaining an Inventory.
2. You note down the requirements from the customer.
3. You sit with your team and discuss if this can be built and how it can be built.
4. Your team aggress that you can build this software in such-an-such a manner.
5. You explain to the customer of how the software is going to come up.
6. The customer make few more clarifications and again you discuss the changes with your team.
7. You again sit with the customer and explain how the software would come out now.
8. The customer accepts your plan and gives you a go-ahead.
9. You instruct your team to build the software and your team gets to work.
During verifying a software being built, we do not have a sketch of physically how it would look, but you have a sketch of what would be built.
Verification has few techniques which we can use to check if we are building the system right. They are:
1. Review's,
2. Inspection's, and
3. Walkthrough' s.
While performing Review's, we have a checklist to verify each activity we are doing is moving in the right direction or not. For example, you are reviewing a piece of code, you have checklist similar to this:
1. Is the code written as per the Coding Standards?
2. Are the variables appropriately named?
3. Has the developer written comments at places where an explanation is required?
4. Do the loop constructs have a logical beginning and end?
5. Is the function or procedure strongly cohesive?
6. Is the function or procedure loosely coupled?
These are few of the points, which you cannot afford to miss while performing a code review. So, what are you achieving by doing a review is that, you check the quality of the code written even before you make it work.
An Inspection helps you inspect if the code you are writing is proper, good, readable and understandable. This is similar to the architect checking the building which is being built by the contractor, is being built as per his sketch or not. In software, an expert would inspect your code to cross check if you are utilizing the features of the language you are using to build the software in an appropriate manner or not.
A Walkthrough is performed by the subject expert. A senior member of the developer's would walkthrough the code written to check if the code being written is appropriate to the software which we are building.
As mentioned before, the Software Quality Assurance (SQA) is an umberalla activity. Inside the umberalla, you find many ways of approaching Quality. Software Testing is a part of the SQA activities which help us producing better quality Software. Usually we denote Software Testing and SQA terminologies synonymously. But, I put in SQA as umberalla activities for achieving quality and Testing as one part of activities which help in producing quality software. So, what are the other SQA activities?
1. Process.
2. Documentation.
3. Testing.
Please find the definition/Explanation for Verification and validation.
Verification is the process of evaluating a system to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase.
Validation is the process of evaluating a system or component during or at the end of development process to determine whether it satisfies specified requirements
Note: there are many ways to define above terminologies.
The Software Quality Assurance umberalla activities majorly fall into two categories, Verification and Validation. To explain the two terminologies in simple words, there is no other better sentance than what Roger Pressman quotes in his book on Software Engineering:
Verification answers the question, Are we doing the right job and Validation answers Are we doing the job right. Quite a confusing statement if you are beginning to learn the subject, but as you go on reading, you would understand what they mean.
What is Verification?
Let us suppose that you intend to build a house. What do you do?
1. Choose a piece of land.
2. Buy the land from the government.
3. Engage an Architect.
4. Explain what type of house you intend to build.
5. The Architect draws a sketch on paper and brings your explanation into a pictorial depiction, which can be more easily understandable for everyone.
6. You take this sketch and discuss with your family and take their opinions.
7. You again sit with the architect and explain what others feel and request him to make the necessary changes.
8. The architect makes the required changes and then again you discuss with your family.
9. After your family and you are satisfied with what the depiction of what you are going to build, you approach the government and request them to approve the sketch so that you can build a house.
10. After you get the approval, you engage a contractor and ask him to build the house basing on the sketch.
Oh! Quite a procedure before you build a house. Now, if you look at each step more in detail:
First, you are choosing a land. You check if this land is good for building a house. Are there the necessary facilities like water, telephone connection, electricity connection, good roads and market etc nearer to the land? These are few of the points which arise in your mind when you choose to buy a piece of land. Now, this is Verification. Verification is cross-checking each step which you are doing to perform a task.
On the similar grounds, let us see how we can apply this term when building a software:
1. You are asked to build a software application for maintaining an Inventory.
2. You note down the requirements from the customer.
3. You sit with your team and discuss if this can be built and how it can be built.
4. Your team aggress that you can build this software in such-an-such a manner.
5. You explain to the customer of how the software is going to come up.
6. The customer make few more clarifications and again you discuss the changes with your team.
7. You again sit with the customer and explain how the software would come out now.
8. The customer accepts your plan and gives you a go-ahead.
9. You instruct your team to build the software and your team gets to work.
During verifying a software being built, we do not have a sketch of physically how it would look, but you have a sketch of what would be built.
Verification has few techniques which we can use to check if we are building the system right. They are:
1. Review's,
2. Inspection's, and
3. Walkthrough' s.
While performing Review's, we have a checklist to verify each activity we are doing is moving in the right direction or not. For example, you are reviewing a piece of code, you have checklist similar to this:
1. Is the code written as per the Coding Standards?
2. Are the variables appropriately named?
3. Has the developer written comments at places where an explanation is required?
4. Do the loop constructs have a logical beginning and end?
5. Is the function or procedure strongly cohesive?
6. Is the function or procedure loosely coupled?
These are few of the points, which you cannot afford to miss while performing a code review. So, what are you achieving by doing a review is that, you check the quality of the code written even before you make it work.
An Inspection helps you inspect if the code you are writing is proper, good, readable and understandable. This is similar to the architect checking the building which is being built by the contractor, is being built as per his sketch or not. In software, an expert would inspect your code to cross check if you are utilizing the features of the language you are using to build the software in an appropriate manner or not.
A Walkthrough is performed by the subject expert. A senior member of the developer's would walkthrough the code written to check if the code being written is appropriate to the software which we are building.
As mentioned before, the Software Quality Assurance (SQA) is an umberalla activity. Inside the umberalla, you find many ways of approaching Quality. Software Testing is a part of the SQA activities which help us producing better quality Software. Usually we denote Software Testing and SQA terminologies synonymously. But, I put in SQA as umberalla activities for achieving quality and Testing as one part of activities which help in producing quality software. So, what are the other SQA activities?
1. Process.
2. Documentation.
3. Testing.
Please find the definition/Explanation for Verification and validation.
Verification is the process of evaluating a system to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase.
Validation is the process of evaluating a system or component during or at the end of development process to determine whether it satisfies specified requirements
Note: there are many ways to define above terminologies.