Software Effort Estimation

Sponsored Links:

 Software effort estimation is the process:

“Educated guess which is based on the given facts.” Or “Estimation is that when you make your best guess.”  

When a deal is signed between the client and company then an estimated guess is made on which a project is build. To generate a sound estimate, a project manager must have:

-A work breakdown structure (WBS), or a list of tasks that, if completed, the final product
-An estimated effort for each task.
-A list of assumptions that is necessary for estimating.
-The consensus among the project team that the estimate is correct.

I: Estimation is always based on the application requirements
All estimates are based on what are tested, i.e. the application requirements. Typically, the application requirements have been established only by the development team without any or only a small input from the test team. After the specifications have been established and the project costs and period has been estimated, the development team wonders how long it would take to test the solution. The answer should be that immediately. Then, the application requirements should be read and understood by the test team, . Without the participation of the evidence, no serious estimation can be thought about. Experts in each requirement should tell you how long it would take for testing. The categories would help experts estimate the verification work necessary.

II: Estimate must be based on previous projects
All estimates are based on previous projects. If a new project has similar requirements of an earlier period, the estimate is based on that project.

III: Estimates are based on indicators
Organization should generate an OPD, Organization Method database, where project metrics are recorded. They must record two years ago metrics obtained from dozens of projects. The number of requirements is the basic information for the estimation of a test project. From it, my organization has metrics that guide us to estimate a test project. The following table shows the parameters used to estimate a test project. The team size is 01 test engineer.

IV: Estimating never forget the past
I have not fired the past. The test team is still using the elderly method and spreadsheet. After the estimation was made following the new rules, the testing team estimates again using the elderly method to compare both results. Normally, the results of the reappraisal method are cheaper and faster than the previous 20 to 25%. If the test team receives a different level, the computer returns to test the method in order to understand if something was lost.

V: Estimation shall be recorded
All decisions must be registered. It is important because if requirements change for any reason, the records would help the testing team to estimate back. The test team should not come back for all the steps and take the same decision again. Sometimes it is a chance to fine-tune the estimate made earlier.

VI: Estimate will be supported by tools
A new worksheet is created with the metrics that help them reach the speedy estimation. The spreadsheet automatically calculates the cost and period of each test phase. There is and a letter template that contains some sections such as: table of costs, risks, and release notes to be filled. This letter is sent to the client. It also shows the different options for the test that can help the client select what type of proof you require.

VII Estimated always test
Finally, all estimates must be verified. I created another worksheet to record the estimates. The estimate is compared with the previous recorded on a spreadsheet to see if they have similar trend.

No comments: